特許法第30条第2項適用 (1)2018年2月22日~2018年5月18日 ゲーム「ドラゴンプロジェクト」に関する情報を公式YouTubeチャンネルにおいて公開 (2)2017年12月9日~ ゲーム「ドラゴンプロジェクト」に関する情報を公式Twitterにおいて公開 (3)2017年12月14日~2018年8月29日 ゲーム「白猫プロジェクト」に関する情報を公式YouTubeチャンネルにおいて公開 (4)2017年12月9日~ ゲーム「白猫プロジェクト」に関する情報を公式Twitterにおいて公開 (5)2017年12月14日~2018年8月28日 ゲーム「ドラゴンプロジェクト」を、Apple社が運営するiOS端末向けのダウンロードサービス(AppStore)、及びGoogle社が運営するAndroid端末向けのダウンロードサービス(Google Play)において公開 (6)2017年12月13日~2018年8月9日 ゲーム「白猫プロジェクト」を、Apple社が運営するiOS端末向けのダウンロードサービス(AppStore)、及びGoogle社が運営するAndroid端末向けのダウンロードサービス(Google Play)において公開
本開示に係るゲームシステムは、複数のユーザにゲームを提供するためのシステムである。以下、ゲームシステムについて図面を参照しつつ説明する。なお、本発明はこれらの例示に限定されるものではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が本発明に含まれることが意図される。以下の説明では、図面の説明において同一の要素には同一の符号を付し、重複する説明を繰り返さない。
<ゲームシステム1のハードウェア構成>
図1は、ゲームシステム1のハードウェア構成を示す図である。ゲームシステム1は図示の通り、複数のユーザ端末100と、サーバ200とを含む。各ユーザ端末100は、サーバ200とネットワーク2を介して接続する。ネットワーク2は、インターネットおよび図示しない無線基地局によって構築される各種移動通信システム等で構成される。この移動通信システムとしては、例えば、所謂3G、4G移動通信システム、LTE(Long Term Evolution)、および所定のアクセスポイントによってインターネットに接続可能な無線ネットワーク(例えばWi-Fi(登録商標))等が挙げられる。
サーバ200(コンピュータ、情報処理装置)は、ワークステーションまたはパーソナルコンピュータ等の汎用コンピュータであってよい。サーバ200は、プロセッサ20と、メモリ21と、ストレージ22と、通信IF23と、入出力IF24とを備える。サーバ200が備えるこれらの構成は、通信バスによって互いに電気的に接続される。
ユーザ端末100(コンピュータ、情報処理装置)は、スマートフォン、フィーチャーフォン、PDA(Personal Digital Assistant)、またはタブレット型コンピュータ等の携帯端末であってよい。ユーザ端末100は、ゲームプレイに適したゲーム装置であってもよい。ユーザ端末100は図示の通り、プロセッサ10と、メモリ11と、ストレージ12と、通信インターフェース(IF)13と、入出力IF14と、タッチスクリーン15(表示部)と、カメラ17と、測距センサ18とを備える。ユーザ端末100が備えるこれらの構成は、通信バスによって互いに電気的に接続される。なお、ユーザ端末100は、タッチスクリーン15に代えて、または、加えて、ユーザ端末100本体とは別に構成されたディスプレイ(表示部)を接続可能な入出力IF14を備えていてもよい。
また、図1に示すように、ユーザ端末100は、1つ以上のコントローラ1020と通信可能に構成されることとしてもよい。コントローラ1020は、例えば、Bluetooth(登録商標)等の通信規格に従って、ユーザ端末100と通信を確立する。コントローラ1020は、1つ以上のボタン等を有していてもよく、該ボタン等に対するユーザの入力操作に基づく出力値をユーザ端末100へ送信する。また、コントローラ1020は、加速度センサ、および、角速度センサ等の各種センサを有していてもよく、該各種センサの出力値をユーザ端末100へ送信する。
なお、ユーザ端末100がカメラ17および測距センサ18を備えることに代えて、または、加えて、コントローラ1020がカメラ17および測距センサ18を有していてもよい。
ユーザ端末100は、例えばゲーム開始時に、コントローラ1020を使用するユーザに、該ユーザの名前またはログインID等のユーザ識別情報を、該コントローラ1020を介して入力させることが望ましい。これにより、ユーザ端末100は、コントローラ1020とユーザとを紐付けることが可能となり、受信した出力値の送信元(コントローラ1020)に基づいて、該出力値がどのユーザのものであるかを特定することができる。
ユーザ端末100が複数のコントローラ1020と通信する場合、各コントローラ1020を各ユーザが把持することで、ネットワーク2を介してサーバ200などの他の装置と通信せずに、該1台のユーザ端末100でマルチプレイを実現することができる。また、各ユーザ端末100が無線LAN(Local Area Network)規格等の無線規格により互いに通信接続する(サーバ200を介さずに通信接続する)ことで、複数台のユーザ端末100によりローカルでマルチプレイを実現することもできる。1台のユーザ端末100によりローカルで上述のマルチプレイを実現する場合、ユーザ端末100は、さらに、サーバ200が備える後述する種々の機能の少なくとも一部を備えていてもよい。また、複数のユーザ端末100によりローカルで上述のマルチプレイを実現する場合、複数のユーザ端末100は、サーバ200が備える後述する種々の機能を分散して備えていてもよい。
なお、ローカルで上述のマルチプレイを実現する場合であっても、ユーザ端末100はサーバ200と通信を行ってもよい。例えば、あるゲームにおける成績または勝敗等のプレイ結果を示す情報と、ユーザ識別情報とを対応付けてサーバ200に送信してもよい。
また、コントローラ1020は、ユーザ端末100に着脱可能な構成であるとしてもよい。この場合、ユーザ端末100の筐体における少なくともいずれかの面に、コントローラ1020との結合部が設けられていてもよい。該結合部を介して有線によりユーザ端末100とコントローラ1020とが結合している場合は、ユーザ端末100とコントローラ1020とは、有線を介して信号を送受信する。
図1に示すように、ユーザ端末100は、外部のメモリカード等の記憶媒体1030の装着を、入出力IF14を介して受け付けてもよい。これにより、ユーザ端末100は、記憶媒体1030に記録されるプログラム及びデータを読み込むことができる。記憶媒体1030に記録されるプログラムは、例えばゲームプログラムである。
ユーザ端末100は、サーバ200等の外部の装置と通信することにより取得したゲームプログラムをユーザ端末100のメモリ11に記憶してもよいし、記憶媒体1030から読み込むことにより取得したゲームプログラムをメモリ11に記憶してもよい。
以上で説明したとおり、ユーザ端末100は、該ユーザ端末100に対して情報を入力する機構の一例として、通信IF13、入出力IF14、タッチスクリーン15、カメラ17、および、測距センサ18を備える。入力する機構としての上述の各部は、ユーザの入力操作を受け付けるように構成された操作部と捉えることができる。
例えば、操作部が、カメラ17および測距センサ18の少なくともいずれか一方で構成される場合、該操作部が、ユーザ端末100の近傍の物体1010を検出し、当該物体の検出結果から入力操作を特定する。一例として、物体1010としてのユーザの手、予め定められた形状のマーカーなどが検出され、検出結果として得られた物体1010の色、形状、動き、または、種類などに基づいて入力操作が特定される。より具体的には、ユーザ端末100は、カメラ17の撮影画像からユーザの手が検出された場合、該撮影画像に基づき検出されるジェスチャ(ユーザの手の一連の動き)を、ユーザの入力操作として特定し、受け付ける。なお、撮影画像は静止画であっても動画であってもよい。
あるいは、操作部がタッチスクリーン15で構成される場合、ユーザ端末100は、タッチスクリーン15の入力部151に対して実施されたユーザの操作をユーザの入力操作として特定し、受け付ける。あるいは、操作部が通信IF13で構成される場合、ユーザ端末100は、コントローラ1020から送信される信号(例えば、出力値)をユーザの入力操作として特定し、受け付ける。あるいは、操作部が入出力IF14で構成される場合、該入出力IF14と接続されるコントローラ1020とは異なる入力装置(図示せず)から出力される信号をユーザの入力操作として特定し、受け付ける。
<各装置のハードウェア構成要素>
プロセッサ10は、ユーザ端末100全体の動作を制御する。プロセッサ20は、サーバ200全体の動作を制御する。プロセッサ10および20は、CPU(Central Processing Unit)、MPU(Micro Processing Unit)、およびGPU(Graphics Processing Unit)を含む。
プロセッサ10は後述するストレージ12からプログラムを読み出し、後述するメモリ11に展開する。プロセッサ20は後述するストレージ22からプログラムを読み出し、後述するメモリ21に展開する。プロセッサ10およびプロセッサ20は展開したプログラムを実行する。
メモリ11および21は主記憶装置である。メモリ11および21は、ROM(Read Only Memory)およびRAM(Random Access Memory)等の記憶装置で構成される。メモリ11は、プロセッサ10が後述するストレージ12から読み出したプログラムおよび各種データを一時的に記憶することにより、プロセッサ10に作業領域を提供する。メモリ11は、プロセッサ10がプログラムに従って動作している間に生成した各種データも一時的に記憶する。メモリ21は、プロセッサ20が後述するストレージ22から読み出した各種プログラムおよびデータを一時的に記憶することにより、プロセッサ20に作業領域を提供する。メモリ21は、プロセッサ20がプログラムに従って動作している間に生成した各種データも一時的に記憶する。
本実施形態においてプログラムとは、ゲームをユーザ端末100により実現するためのゲームプログラムであってもよい。あるいは、該プログラムは、該ゲームをユーザ端末100とサーバ200との協働により実現するためのゲームプログラムであってもよい。なお、ユーザ端末100とサーバ200との協働により実現されるゲームは、一例として、ユーザ端末100において起動されたブラウザ上で実行されるゲームであってもよい。あるいは、該プログラムは、該ゲームを複数のユーザ端末100の協働により実現するためのゲームプログラムであってもよい。また、各種データとは、ユーザ情報およびゲーム情報などのゲームに関するデータ、ならびに、ユーザ端末100とサーバ200との間または複数のユーザ端末100間で送受信する指示または通知を含んでいる。
ストレージ12および22は補助記憶装置である。ストレージ12および22は、フラッシュメモリまたはHDD(Hard Disk Drive)等の記憶装置で構成される。ストレージ12およびストレージ22には、ゲームに関する各種データが格納される。
通信IF13は、ユーザ端末100における各種データの送受信を制御する。通信IF23は、サーバ200における各種データの送受信を制御する。通信IF13および23は例えば、無線LAN(Local Area Network)を介する通信、有線LAN、無線LAN、または携帯電話回線網を介したインターネット通信、ならびに近距離無線通信等を用いた通信を制御する。
入出力IF14は、ユーザ端末100がデータの入力を受け付けるためのインターフェースであり、またユーザ端末100がデータを出力するためのインターフェースである。
入出力IF14は、USB(Universal Serial Bus)等を介してデータの入出力を行ってもよい。入出力IF14は、例えば、ユーザ端末100の物理ボタン、カメラ、マイク、または、スピーカ等を含み得る。サーバ200の入出力IF24は、サーバ200がデータの入力を受け付けるためのインターフェースであり、またサーバ200がデータを出力するためのインターフェースである。入出力IF24は、例えば、マウスまたはキーボード等の情報入力機器である入力部と、画像を表示出力する機器である表示部とを含み得る。
ユーザ端末100のタッチスクリーン15は、入力部151と表示部152とを組み合わせた電子部品である。入力部151は、例えばタッチセンシティブなデバイスであり、例えばタッチパッドによって構成される。表示部152は、例えば液晶ディスプレイ、または有機EL(Electro-Luminescence)ディスプレイ等によって構成される。
入力部151は、入力面に対しユーザの操作(主にタッチ操作、スライド操作、スワイプ操作、およびタップ操作等の物理的接触操作)が入力された位置を検知して、位置を示す情報を入力信号として送信する機能を備える。入力部151は、図示しないタッチセンシング部を備えていればよい。タッチセンシング部は、静電容量方式または抵抗膜方式等のどのような方式を採用したものであってもよい。
図示していないが、ユーザ端末100は、該ユーザ端末100の保持姿勢を特定するための1以上のセンサを備えていてもよい。このセンサは、例えば、加速度センサ、または、角速度センサ等であってもよい。ユーザ端末100がセンサを備えている場合、プロセッサ10は、センサの出力からユーザ端末100の保持姿勢を特定して、保持姿勢に応じた処理を行うことも可能になる。例えば、プロセッサ10は、ユーザ端末100が縦向きに保持されているときには、縦長の画像を表示部152に表示させる縦画面表示としてもよい。一方、ユーザ端末100が横向きに保持されているときには、横長の画像を表示部に表示させる横画面表示としてもよい。このように、プロセッサ10は、ユーザ端末100の保持姿勢に応じて縦画面表示と横画面表示とを切り替え可能であってもよい。
カメラ17は、イメージセンサ等を含み、レンズから入射する入射光を電気信号に変換することで撮影画像を生成する。
測距センサ18は、測定対象物までの距離を測定するセンサである。測距センサ18は、例えば、パルス変換した光を発する光源と、光を受ける受光素子とを含む。測距センサ18は、光源からの発光タイミングと、該光源から発せられた光が測定対象物にあたって反射されて生じる反射光の受光タイミングとにより、測定対象物までの距離を測定する。測距センサ18は、指向性を有する光を発する光源を有することとしてもよい。
ここで、ユーザ端末100が、カメラ17と測距センサ18とを用いて、ユーザ端末100の近傍の物体1010を検出した検出結果を、ユーザの入力操作として受け付ける例をさらに説明する。カメラ17および測距センサ18は、例えば、ユーザ端末100の筐体の側面に設けられてもよい。カメラ17の近傍に測距センサ18が設けられてもよい。カメラ17としては、例えば赤外線カメラを用いることができる。この場合、赤外線を照射する照明装置および可視光を遮断するフィルタ等が、カメラ17に設けられてもよい。これにより、屋外か屋内かにかかわらず、カメラ17の撮影画像に基づく物体の検出精度をいっそう向上させることができる。
プロセッサ10は、カメラ17の撮影画像に対して、例えば以下の(1)~(5)に示す処理のうち1つ以上の処理を行ってもよい。(1)プロセッサ10は、カメラ17の撮影画像に対し画像認識処理を行うことで、該撮影画像にユーザの手が含まれているか否かを特定する。プロセッサ10は、上述の画像認識処理において採用する解析技術として、例えばパターンマッチング等の技術を用いてよい。(2)また、プロセッサ10は、ユーザの手の形状から、ユーザのジェスチャを検出する。プロセッサ10は、例えば、撮影画像から検出されるユーザの手の形状から、ユーザの指の本数(伸びている指の本数)を特定する。プロセッサ10はさらに、特定した指の本数から、ユーザが行ったジェスチャを特定する。例えば、プロセッサ10は、指の本数が5本である場合、ユーザが「パー」のジェスチャを行ったと判定する。また、プロセッサ10は、指の本数が0本である(指が検出されなかった)場合、ユーザが「グー」のジェスチャを行ったと判定する。また、プロセッサ10は、指の本数が2本である場合、ユーザが「チョキ」のジェスチャを行ったと判定する。(3)プロセッサ10は、カメラ17の撮影画像に対し、画像認識処理を行うことにより、ユーザの指が人差し指のみ立てた状態であるか、ユーザの指がはじくような動きをしたかを検出する。(4)プロセッサ10は、カメラ17の撮影画像の画像認識結果、および、測距センサ18の出力値等の少なくともいずれか1つに基づいて、ユーザ端末100の近傍の物体1010(ユーザの手など)とユーザ端末100との距離を検出する。例えば、プロセッサ10は、カメラ17の撮影画像から特定されるユーザの手の形状の大小により、ユーザの手がユーザ端末100の近傍(例えば所定値未満の距離)にあるのか、遠く(例えば所定値以上の距離)にあるのかを検出する。なお、撮影画像が動画の場合、プロセッサ10は、ユーザの手がユーザ端末100に接近しているのか遠ざかっているのかを検出してもよい。(5)カメラ17の撮影画像の画像認識結果等に基づいて、ユーザの手が検出されている状態で、ユーザ端末100とユーザの手との距離が変化していることが判明した場合、プロセッサ10は、ユーザが手をカメラ17の撮影方向において振っていると認識する。カメラ17の撮影範囲よりも指向性が強い測距センサ18において、物体が検出されたりされなかったりする場合に、プロセッサ10は、ユーザが手をカメラの撮影方向に直交する方向に振っていると認識する。
このように、プロセッサ10は、カメラ17の撮影画像に対する画像認識により、ユーザが手を握りこんでいるか否か(「グー」のジェスチャであるか、それ以外のジェスチャ(例えば「パー」)であるか)を検出する。また、プロセッサ10は、ユーザの手の形状とともに、ユーザがこの手をどのように移動させているかを検出する。また、プロセッサ10は、ユーザがこの手をユーザ端末100に対して接近させているのか遠ざけているのかを検出する。このような操作は、例えば、マウスまたはタッチパネルなどのポインティングデバイスを用いた操作に対応させることができる。ユーザ端末100は、例えば、ユーザの手の移動に応じて、タッチスクリーン15においてポインタを移動させ、ユーザのジェスチャ「グー」を検出する。この場合、ユーザ端末100は、ユーザが選択操作を継続中であると認識する。選択操作の継続とは、例えば、マウスがクリックされて押し込まれた状態が維持されること、または、タッチパネルに対してタッチダウン操作がなされた後タッチされた状態が維持されることに対応する。また、ユーザ端末100は、ユーザのジェスチャ「グー」が検出されている状態で、さらにユーザが手を移動させると、このような一連のジェスチャを、スワイプ操作(またはドラッグ操作)に対応する操作として認識することもできる。また、ユーザ端末100は、カメラ17の撮影画像によるユーザの手の検出結果に基づいて、ユーザが指をはじくようなジェスチャを検出した場合に、当該ジェスチャを、マウスのクリックまたはタッチパネルへのタップ操作に対応する操作として認識してもよい。
<ゲーム概要>
ゲームシステム1は、ゲームにおいてプレイ可能なイベントをユーザに付与するゲームを実行するシステムである。ここで、プレイ可能なイベントの付与とは、イベントをプレイする権利を表す権利アイテムを、ユーザに関連付けてメモリに記憶することである。
本実施形態では、ゲームシステム1は、ユーザによって操作される操作キャラクタを敵キャラクタと戦闘させるゲームを実行するシステムである例について説明する。また、この場合に、イベントの一例が、共闘戦闘である例について説明する。共闘戦闘とは、操作キャラクタが他のキャラクタと共に、特定の敵キャラクタ(例えば、ボスキャラクタ)と戦闘することを含む。以降、ユーザに権利アイテムが関連付けられたイベントを、ユーザによって保有される共闘戦闘、とも記載する。
なお、ゲームシステム1は、特定のジャンルに限らず、あらゆるジャンルのゲームを実行するためのシステムであってもよい。例えば、テニス、卓球、ドッジボール、野球、サッカーおよびホッケーなどのスポーツを題材としたゲーム、パズルゲーム、クイズゲーム、RPG、アドベンチャーゲーム、シューティングゲーム、シミュレーションゲーム、育成ゲーム、ならびに、アクションゲームなどであってもよい。
また、ゲームシステム1は、特定のプレイ形態に限らず、あらゆるプレイ形態のゲームを実行するためのシステムであってもよい。例えば、単一のユーザによるシングルプレイゲーム、および、複数のユーザによるマルチプレイゲーム、また、マルチプレイゲームの中でも、複数のユーザが対戦する対戦ゲーム、および、複数のユーザが協力する協力プレイゲームなどであってもよい。
<ゲームシステム1の機能的構成>
(サーバ200の機能的構成)
図2は、サーバ200の機能的構成を示すブロック図である。サーバ200は、ゲームを実現するために必要な各種データおよびプログラムを、各ユーザ端末100に提供する機能を有する。サーバ200は、各ユーザ端末100からゲームに関するデータを収集し管理する機能を有する。サーバ200は、複数のユーザ端末100間の同期処理を行う機能を有する。
なお、本実施形態では、サーバ200は事前に登録されたゲームのアカウントで各ユーザおよびユーザ端末100を識別する。アカウントの登録方法は特に限定されない。例えば、ユーザ端末100またはパーソナルコンピュータ等の他の装置が、ユーザの操作に従って、ユーザのアカウントの登録に必要な情報をサーバ200に送信すればよい。そして、サーバ200は、受信した情報に基づいて各ユーザのアカウントを作成および保存すればよい。
ユーザ端末100がいずれかのアカウントを用いてゲームシステム1のネットワーク2にログインすると、サーバ200はログインしたユーザ端末100を認識する。なお、ログインの方法およびログインに係る処理については特に限定しない。サーバ200およびユーザ端末100は、従来知られたログインの方法およびログインに係る各種処理を行えばよい。
サーバ200は、プロセッサ20、メモリ21、ストレージ22、通信IF23、入出力IF24等の協働によって、制御部210および記憶部220として機能する。
記憶部220は、制御部210が使用する各種データを格納する。記憶部220はゲームプログラム221と、ゲーム情報222と、ユーザ情報223とを格納している。
ゲームプログラム221は、ゲームを実現するためのプログラムである。ゲーム情報222およびユーザ情報223は、ゲームプログラム221が実行されるときに参照されるデータである。
なお、ゲームプログラム221は、サーバ200側で実行するゲームプログラムに加えて、ユーザ端末100に送信しユーザ端末100側で実行するプログラム(後述するゲームプログラム121)を含んでいてもよい。もしくは、記憶部220は、サーバ200側で実行するゲームプログラム221と、ユーザ端末側で実行するプログラムとの両方を格納していてもよい。
ゲーム情報222は、アカウント間で共通の情報である。ゲーム情報222は、例えば各種ゲーム空間を規定するための情報を含み得る。「ゲーム空間」とは、ユーザが操作可能な操作キャラクタのオブジェクトが配置される空間である。ゲーム情報222は、ゲーム空間内に配置される木・岩・建物等の背景オブジェクトやノンプレイヤキャラクタ(non player character:NPC)のオブジェクトの配置位置、大きさ、色、形状等、アカウント間で共通のオブジェクトに関する各種設定情報を含み得る。ゲーム情報222は、ノンプレイヤキャラクタの各種パラメータの設定値を含み得る。ゲーム情報222はクエストに係る情報を含み得る。ゲーム情報222は、ゲーム空間内において行われる抽選の当選確率に関する情報を含み得る。クエストとは、達成条件が設定されたゲーム内のイベントである。クエスト毎に、達成条件が設定されていてもよい。なお、クエストには達成条件に加え失敗条件が設定されていてもよい。また、以下では、ゲーム空間に配置されたキャラクタのオブジェクトを指して、単に「キャラクタ」と呼称する場合がある。
ユーザ情報223は、ゲームのアカウント毎に管理される情報である。ユーザ情報223は例えば、操作可能なキャラクタ(以下、操作キャラクタと称する)に関する情報、保有資産に関する情報、ゲームの進行度合いを示す情報、およびゲームに含まれる抽選において付与された共闘戦闘(イベント)をプレイする権利の保有状況に関する情報等を含み得る。ここで、保有資産の例としては、例えばゲーム内通貨、アイテム、キャラクタの装備品などが挙げられる。共闘戦闘とは、例えば、ゲーム空間内において操作キャラクタが特定の敵キャラクタ(例えば、ボスキャラクタ)と戦闘することを含むイベントである。
制御部210は、記憶部220に格納されたゲームプログラム221を実行することにより、ゲームに関する各種処理を制御する。制御部210は、ゲームプログラム221を実行することにより、送受信部211、データ管理部213、およびサーバ処理部212として機能する。
送受信部211は各種データを送受信する。例えば、送受信部211は、ユーザ端末100からの各種データおよびプログラムの送信要求や、マルチプレイ機能に対応するための同期の要求および同期のためのデータ等を受信し、サーバ処理部212に送る。例えば、送受信部211は、サーバ処理部212からの指示に従って、ユーザ端末100に各種データおよびプログラムを送信する。
本実施形態において「マルチプレイ機能」とは、複数のアカウントにおけるゲームの進行を同期させた状態でゲームを進行させる機能である。ゲームシステム1のサーバ200およびユーザ端末100は、ゲームシステム1にログインしているアカウントが複数存在する場合には、マルチプレイ機能に対応するための各種処理を行う。
サーバ処理部212は、ゲーム進行に係る各種判定処理を行う。サーバ処理部212は、ゲームを提供するために必要な演算処理を行う。サーバ処理部212は、ユーザ端末100からの要求等に応じて、ゲームプログラム221に記述された演算処理を実行する。
例えば、サーバ処理部212は、データ管理部213にゲーム情報222またはユーザ情報223のレコードの追加、更新、または削除を指示する。例えば、サーバ処理部212は送受信部211に各種データまたはプログラムの送信を指示する。例えば、サーバ処理部212は、送受信部211を介しユーザ端末100からマルチプレイ機能に対応するための同期の要求および同期のためのデータを受け取ると、同期処理部214にマルチプレイ機能に対応するための同期処理を行うよう指示する。
データ管理部213は、記憶部220に格納されている各種データをサーバ処理部212の指示に従って管理する。例えば、データ管理部213は、サーバ処理部212からの指示に応じてゲーム情報222またはユーザ情報223のレコードを、追加、更新、または削除する。
例えば、データ管理部213は、サーバ処理部212からの指示に従って、ゲーム情報222およびユーザ情報223の少なくとも一方を記憶部220から読み出し、送受信部211を介しユーザ端末100に送信する。
例えば、データ管理部213は、サーバ処理部212からの指示に従って、ゲームプログラム221のうち、ユーザ端末100側で実行する分のプログラムを記憶部220から読み出し、送受信部211を介しユーザ端末100に送信する。
同期処理部214は、サーバ処理部212の指示に従って、ゲームのマルチプレイ機能に対応するための同期処理を行う。同期処理部214は、各アカウントに対応するユーザ端末100から受信する何らかの情報を、他のユーザ端末100に送信することでユーザ端末間の同期を行う。同期処理部214はサーバ200から複数のユーザ端末100に何らかの情報を送信する場合も、各ユーザ端末100に同期して情報を送信する。なお、同期処理部214は、同期のタイミングや同期すべき情報等をサーバ処理部212から受信すればよい。これにより、例えばあるユーザ端末100において行われた入力操作によって引き起こされるゲーム内の作用が、他のユーザ端末100において同期されて示される。
(ユーザ端末100の機能的構成)
図3は、ユーザ端末100の機能的構成を示すブロック図である。ユーザ端末100は、ユーザの入力操作を受け付ける入力装置としての機能と、ゲームの画像や音声を出力する出力装置としての機能を有する。ユーザ端末100は、プロセッサ10、メモリ11、ストレージ12、通信IF13、および入出力IF14等の協働によって、制御部110および記憶部120として機能する。
記憶部120は、ゲームプログラム121と、ゲーム情報122と、ユーザ情報123とを格納する。ゲームプログラム121は、ユーザ端末100側で実行するゲームプログラムである。ゲーム情報122は、制御部110がゲームプログラム121を実行する際に参照するデータであって、サーバ200のゲーム情報222と同様の情報を含んでいる。ユーザ情報123は、ユーザ端末100のユーザのアカウントに関するデータであって、サーバ200のユーザ情報223と同様の情報を含んでいる。
制御部110は、記憶部120に格納されたゲームプログラム121を実行することにより、ユーザ端末100を統括的に制御する。例えば、制御部110は、ゲーム情報122に記憶された、ゲーム空間を規定するための情報を参照してゲーム空間を規定する。制御部110は、各種データを送受信する。例えば、制御部110はサーバ200から各種データ、プログラム、およびマルチプレイ機能に対応するための同期のためのデータ等を受信する。例えば、制御部110は、ゲーム情報122またはユーザ情報123の一部または全部や、マルチプレイ機能に対応するための同期の要求をサーバ200に送信する。
制御部110は、ゲームプログラム121の記述に応じて、ゲーム進行処理部111、入力操作受付部112、カメラ配置制御部113、表示制御部114、オブジェクト制御部115、抽選制御部116およびポイント管理部117として機能する。
入力操作受付部112は、入力部151に対するユーザの入力操作を検知し受け付ける。入力操作受付部112は、タッチスクリーン15およびその他の入出力IF14を介したコンソールに対してユーザが及ぼした作用から、いかなる入力操作がなされたかを判別し、その結果を制御部110の各要素に出力する。
例えば、入力操作受付部112は、入力部151に対する入力操作がなされた場合、入力位置の座標および操作の種類を検知する。例えば、入力操作受付部112は、タッチ操作、スライド操作、スワイプ操作、およびタップ操作等を検知する。入力操作受付部112は、連続して検知されていた入力が途切れると、タッチスクリーン15から接触入力が解除されたことを検知する。
ゲーム進行処理部111は、ゲームの進行に係る各種処理を行う。例えば、ゲーム進行処理部111は、入力操作受付部112が受け付けた入力操作の入力位置の座標と操作の種類とから示されるユーザの指示内容を解釈する。例えば、ゲーム進行処理部111は、ゲーム情報122またはユーザ情報123の追加、更新、または削除を行う。例えば、ゲーム進行処理部111は、ゲームの進行に係る各種判定処理を行う。
また、ゲーム進行処理部111は、次の処理を行うことにより、ゲームを進行する。次の処理とは、(イ)所定条件が満たされた場合に、ユーザに共闘戦闘を付与する処理、(ロ)付与した共闘戦闘の完了に応じて、ユーザに第1の報酬又は第2の報酬を付与する処理、(ハ)付与した第1の報酬又は第2の報酬に基づいて、共闘戦闘で用いることが可能なオブジェクトを生成又は有利に変化させる処理である。(イ)共闘戦闘を付与する処理については、詳細を後述する抽選制御部116を用いて実行される。ここでは、(ロ)第1の報酬又は第2の報酬を付与する処理、(ハ)オブジェクトを生成又は有利に変化させる処理について順次説明する。
ゲーム進行処理部111は、共闘戦闘に対して設定された第1の条件が満たされた場合に、ユーザに対して第1の報酬を付与する。付与された第1の報酬は、ユーザに関連付けて記憶部120に記憶される。第1の条件とは、共闘戦闘のプレイに基づく条件であり、例えば、共闘戦闘のプレイにより敵キャラクタの討伐に成功することである。
また、ゲーム進行処理部111は、共闘戦闘に対して設定された第2の条件が満たされた場合に、ユーザに対して第2の報酬を付与する。付与された第2の報酬は、ユーザに関連付けて記憶部120に記憶される。第2の条件とは、共闘戦闘のプレイによらない操作に基づく条件である。
第2の条件は、例えば、当該共闘戦闘を、第2の報酬を得る対象として選択する操作が行われることを含む。また、第2の条件は、例えば、ユーザによって保有される共闘戦闘のうち、第2の報酬を得る対象として選択された共闘戦闘について、定められた時間が経過することを含む。また、第2の条件は、例えば、第2の報酬を得る対象として選択された共闘戦闘について、他の共闘戦闘のプレイに基づく条件が満たされることを含む。
具体的には、第2の条件は、第2の報酬を得る対象として選択されたイベントについて蓄積される討伐ポイントが、閾値に達することであるものとする。以降、第2の報酬を得る対象として選択することを、「討伐ポイントの蓄積対象として登録する」、とも記載する。また、討伐ポイントが到達すべき閾値を、必要討伐ポイント、とも記載する。登録された共闘戦闘に応じて、必要討伐ポイントが設定される。登録された共闘戦闘について討伐ポイントが付与され、付与された討伐ポイントは、当該共闘戦闘に付与済みの討伐ポイントに加算されることにより蓄積される。例えば、討伐ポイントは、時間の経過に伴い付与される。また、例えば、討伐ポイントは、他の共闘戦闘のプレイに基づき付与される。討伐ポイントに関連する処理は、後述のポイント管理部117によって実行される。ゲーム進行処理部111は、ポイント管理部117から討伐ポイントが閾値に達したことを通知されると、第2の報酬を付与する処理を実行する。
また、第1の報酬は、第2の報酬より、ゲームを有利に進める上での価値が高い。ここで、価値が高いとは、より多くの種類の報酬を含むことであってもよい。また、価値が高いとは、より多くの個数の報酬を含むことであってもよい。また、価値が高いとは、希少度が設定された種類の報酬がある場合に、より希少度の高い報酬を含むことであってもよい。例えば、第1の報酬の一部が、第2の報酬であってもよい。また、第1の報酬が、第1のアイテム及び他の種類のアイテムを含んでおり、第2の報酬が、第1のアイテムのみを含んでいてもよい。また、第1の報酬及び第2の報酬とも、第1のアイテム及び他の種類のアイテムを含むが、他のアイテムの種類、個数、希少度について、第1の報酬のほうが第2の報酬より高く設定されていてもよい。
なお、第1の報酬及び第2の報酬は、当該共闘戦闘が付与されたユーザに対して、確定的に第1のアイテムを含む。また、第1の報酬は、当該共闘戦闘に参加した他のキャラクタを操作する他のユーザに対して、確率的に第1のアイテムを含んでもよい。
つまり、ユーザは、共闘戦闘をプレイしても、プレイしなくても、何らかの報酬を得ることができるが、プレイする方が、より価値の高い報酬を得ることができる。その結果、ユーザは、保有する全ての共闘戦闘について、プレイしない手法のみを利用して報酬を得ることなく、興味のある共闘戦闘についてプレイを楽しむことができる。
ここで、第1のアイテムとは、共闘戦闘で利用可能なオブジェクトを生成するためのアイテムであってもよい。本実施形態では、第1のアイテムは、そのようなオブジェクトを生成するために必須のアイテムであり、他のアイテムと組み合わせてオブジェクトを生成可能であるものとする。以降、第1のアイテムを、必須の素材アイテムとも記載する。また、他のアイテムを、単に素材アイテムとも記載する。また、共闘戦闘で利用可能なオブジェクトとは、例えば、操作キャラクタに装備可能な武器、防具等であってもよい。以降、共闘戦闘で利用可能なオブジェクトを、装備アイテムとも記載する。ゲーム進行処理部111は、必須の素材アイテムを他の素材アイテムと組み合わせて、装備アイテムを生成する。
また、ゲーム進行処理部111は、必須の素材アイテムに基づいて、装備アイテムを有利に変化させる。以降、装備アイテムを有利に変化させることを、装備アイテムを強化する、とも記載する。装備アイテムを強化するために用いることができる必須の素材アイテムは、当該装備アイテムの生成に用いた必須の素材アイテムではなく、ユーザに付与されてまだ用いられていない他の必須の素材アイテムである。例えば、ゲーム進行処理部111は、必須の素材アイテムを、装備アイテムを強化するための消費アイテムに変換し、変換した消費アイテムの所定量を用いて、装備アイテムを強化してもよい。また、強化に必要な消費アイテムの所定量は、装備アイテムに応じて定められていてもよい。
例えば、ある共闘戦闘について第1の条件が満たされた場合に付与される第1の報酬は、当該共闘戦闘の希少度に応じた価値を有する必須の素材アイテムを含む。ゲーム進行処理部111は、必須の素材アイテムの価値が高いほど、より価値の高い装備アイテムを生成する。装備アイテムの価値が高いほど、その強化に必要な消費アイテムの所定量が多くてもよい。
また、必須の素材アイテムは、その価値が高いほど、装備アイテムを強化する上で価値の高い消費アイテムに変換可能であってもよい。例えば、より価値の高い必須の素材アイテムは消費アイテムHに変換可能であり、より価値の低い必須の素材アイテムは消費アイテムLに変換可能であるとする。この場合、ある装備アイテムを強化するために必要な消費アイテムLが20個である場合に、同一の装備アイテムを強化するために必要な消費アイテムHは5個であってもよい。
また、ユーザに付与される共闘戦闘には、希少度が設定される。希少度については詳細を後述する。第2の条件は、共闘戦闘の希少度に応じて設定される。例えば、共闘戦闘の希少度が高いほど、難易度の高い第2の条件が設定されてもよい。第2の条件の難易度がより高いとは、例えば、必要討伐ポイントがより高いことであってもよい。
また、ゲーム進行処理部111は、第1の条件又は第2の条件が満たされた場合に、共闘戦闘を完了させる。すなわち、共闘戦闘において敵キャラクタの討伐に成功した場合、又は、共闘戦闘について討伐ポイントが閾値に達した場合に、当該共闘戦闘を完了させる。以降、共闘戦闘が完了することを、討伐が完了する、と記載することもある。
つまり、ユーザは、共闘戦闘をプレイしても、プレイしなくても、討伐を完了させることができるが、プレイする方が、より価値の高い報酬を得ることができる。その結果、ユーザに対して、保有する全ての共闘戦闘について、プレイしないで討伐を完了させる手法のみを利用することなく、興味のある共闘戦闘についてプレイにより討伐を完了させることを楽しむよう、促すことができる。また、ユーザにとって、プレイにより第1の条件を満たすことが難しい共闘戦闘を、プレイによらずに完了させるよう、促すことができる。その結果、ユーザは、プレイにより第1の条件を満たすことが難しい共闘戦闘からも、少なくとも必須の素材アイテムを得ることができ、当該必須の素材アイテムを用いて、装備アイテムを生成または強化して、次の共闘戦闘をプレイすることができる。
また、ゲーム進行処理部111は、討伐が完了すると、当該共闘戦闘をプレイするための権利アイテムと、ユーザとの関連付けを、記憶部120において解消する。解消するとは、例えば、当該ユーザに関連付けた権利アイテムを表す情報を記憶部120から削除することであってもよい。換言すると、共闘戦闘は、討伐が完了していない場合、再度プレイ可能であり、討伐が完了すると、プレイ可能でなくなる。
これにより、ユーザによって保有される共闘戦闘が増加することを軽減でき、共闘戦闘が多いことによるユーザの負担感が軽減される。
また、ゲーム進行処理部111は、第2の条件が満たされた後、第2の報酬の受け取りを指示するユーザ操作に応じて、第2の報酬をユーザに関連付けて記憶部120に記憶させてもよい。その場合、ゲーム進行処理部111は、当該ユーザ操作が、第2の条件が満たされてから所定期間内に受け付けられた場合には、第2の報酬に加えて追加の報酬を、ユーザに関連付けてメモリに記憶させてもよい。追加の報酬は、本願における第3の報酬の一例に相当する。これにより、そのプレイによらない手法で討伐が完了した共闘戦闘が、ユーザにより放置されることを防止または抑止できる。
カメラ配置制御部113は、ゲーム空間のうちユーザに提示する領域を指定するための仮想カメラを規定する。カメラ配置制御部113は、仮想カメラのゲーム空間内での位置および向きを規定することにより、仮想カメラをゲーム空間に仮想的に配置する。さらに、カメラ配置制御部113は、仮想カメラで規定される視野領域および当該視野領域に配置されているオブジェクトを描画した画像を作成するよう、表示制御部114に指示する。
なお、カメラ配置制御部113は、仮想カメラの位置および向きを、ゲーム空間毎に適宜決定してよい。例えば、カメラ配置制御部113は特定のオブジェクトの位置や向きを基準として、当該オブジェクトが特定の向きで視野領域の中央に写るように、当該オブジェクトから一定の方向、距離、および角度で仮想カメラを配置してもよい。特定のオブジェクトとは、例えばユーザ端末100で操作キャラクタのオブジェクトであってもよいし、ノンプレイヤキャラクタ等他のキャラクタを示す動的なオブジェクトであってもよいし、建物や木、石などを示す静的なオブジェクトであってもよい。ここで、ゲーム空間における動的なオブジェクトには、ゲームプログラム121および221に基づいて動作するキャラクタ(例えば、ノンプレイヤキャラクタ、敵キャラクタなど)とユーザによる操作に基づいて動作する操作キャラクタとが含まれる。
表示制御部114は、表示部152に画像を表示させる。例えば、表示制御部114は、ゲーム空間のうち、カメラ配置制御部113が規定する仮想カメラの視野の領域と、当該領域に存在するオブジェクトとを描画した画像を生成し、表示部152に表示させる。さらに、表示制御部114は、このような画像に、アイコン、ボタン、各種パラメータを示すメニュー等、ゲームの種々の操作に必要なUI(user interface)に係るオブジェクトを重畳して描画してもよい。
オブジェクト制御部115は、ゲーム情報122に含まれる、オブジェクトの設定情報に基づきゲーム空間にオブジェクトを配置する。オブジェクト制御部115は、ゲーム空間に配置したオブジェクトを制御する。例えば、オブジェクト制御部115は、オブジェクトのゲーム空間内での位置、向き、形状、色等を変更したり、オブジェクトに所定の一連の動作を行わせたりする。
抽選制御部116は、ゲーム情報122に格納されている複数の共闘戦闘の中から、抽選に参加する操作キャラクタの能力に応じた難易度の共闘戦闘を決定する。ここで、難易度とは、共闘戦闘に含まれるボスキャラクタとの戦闘に勝利することの困難さの度合いを示す指標である。難易度は、例えば、ボスキャラクタのレベルの高低、討伐すべきボスキャラクタの数などに基づいて設定され得る。なお、抽選制御部116が決定する共闘戦闘毎に当選確率が設定されている。この当選確率は、例えば、ゲーム情報122に含まれている。抽選制御部116は、この当選確率に基づいて、1または複数の共闘戦闘を決定する。抽選制御部116によって決定された共闘戦闘は、ゲーム進行処理部111によって、この操作キャラクタに関連付けてユーザ情報123に登録される。
ポイント管理部117は、共闘戦闘について蓄積される討伐ポイントを管理する。例えば、討伐ポイントを管理する処理は、ユーザにプレイする権利が付与されている共闘戦闘のうち、ユーザによって選択された共闘戦闘を、討伐ポイントの蓄積対象として登録する処理を含む。また、討伐ポイントを管理する処理は、討伐ポイントの蓄積対象として登録された共闘戦闘について、付与条件が満たされると討伐ポイントを付与する処理を含む。また、討伐ポイントを管理する処理は、討伐ポイントの蓄積対象として登録された共闘戦闘について、付与された討伐ポイントの累計値が、閾値に達したかを判定する処理を含む。
ここで、希少度が高い共闘戦闘ほど、必要討伐ポイントが大きく定められるので、討伐ポイントの蓄積による討伐完了までに、多くの経過時間、または、多くの他の共闘戦闘のプレイを必要とする。その結果、ユーザに対して、希少度が高い共闘戦闘については、討伐ポイントの蓄積対象として登録するより、共闘戦闘空間でのプレイを楽しむことを促すことができる。また、ユーザに対して、希少度が低い共闘戦闘については、プレイするよりも討伐ポイントの蓄積対象として登録することを促すことができる。
一方で、希少度が高い共闘戦闘ほど、第1の条件の難易度が高く設定されるとする。すなわち、希少度が高い共闘戦闘ほど、プレイにより敵キャラクタを討伐することが難しくなっている。この場合、ユーザは、プレイにより敵キャラクタを討伐することが難しい共闘戦闘について、討伐ポイントの蓄積対象として登録することにより、討伐を完了させて第2の報酬を得ることができる。その結果、ユーザは、希少度が高い共闘戦闘に関する第2の報酬から得られた必須の素材アイテムを用いて装備アイテムを生成・強化し、次の共闘戦闘をプレイすることができる。
なお、ゲームシステム1は、ユーザ端末100が備える機能の少なくとも一部をサーバ200が備えるように構成されていてもよい。ゲームシステム1は、サーバ200が備える機能の少なくとも一部をユーザ端末100が備えるように構成されていてもよい。さらに、ユーザ端末100およびサーバ200以外の他の装置をゲームシステム1の構成要素とし、該ハードウェアにゲームシステム1における処理の一部を実行させてもよい。すなわち、本実施形態においてゲームプログラム121および221を実行するコンピュータは、ユーザ端末100、サーバ200、および他の装置の何れであってもよい。
(ゲームの進行とゲーム空間の遷移)
図4は、ゲームシステム1の提供するゲームの進行とゲーム空間の遷移例とを示す図である。
制御部110は、ゲームの進行に応じてゲーム空間を遷移する。以下では、準備空間、戦闘空間、および共闘戦闘空間という複数のゲーム空間が規定されている場合を例に挙げて説明する。図4には、準備空間から戦闘空間への遷移t1、戦闘空間から共闘戦闘空間への遷移t2、準備空間から共闘戦闘空間への遷移t3、および共闘戦闘空間から準備空間への遷移t4が示されている。
準備空間は、敵キャラクタが出現しないゲーム空間である。準備空間は、ユーザにクエストの準備を行わせるためのゲーム空間である。制御部110が準備空間においてゲームを進行させているときに、ユーザによりクエストの開始指示を示す入力操作がなされると、制御部110は、ゲーム空間を準備空間から戦闘空間へと遷移させる(遷移t1)。
準備空間は、操作キャラクタによって共闘戦闘をプレイする権利を取得するための操作を受け付けるためのゲーム空間でもある。制御部110が準備空間においてゲームを進行させているときに、入力操作受付部112がユーザによる抽選参加希望の入力操作を受け付けた場合、制御部110は、準備空間から、準備空間に含まれる別のゲーム空間である抽選空間へ遷移させてもよい。
制御部110は、準備空間においてクエストおよび共闘戦闘のゲームクリアに成功した場合等に与えられる報酬の受け取りを行わせてもよい。制御部110は、準備空間において入力操作受付部112がマップ移動操作などの所定の入力操作を受け付けた場合、クエストを開始させないままゲーム空間を戦闘空間に遷移させてもよい。制御部110は、ユーザにより共闘戦闘の開始指示がなされた場合は、ゲーム空間を準備空間から共闘戦闘空間へと遷移させてもよい(遷移t3)。
戦闘空間は、操作キャラクタと敵キャラクタとが遭遇して戦闘するためのゲーム空間である。操作キャラクタと敵キャラクタとの戦闘については後で詳述する。
サーバ200は同期処理部214により、またはユーザ端末100からの情報を受信して、所定の条件が満たされたと判定した場合、この条件を満たしたユーザ端末100に、ゲーム空間を戦闘空間から共闘戦闘空間に遷移させるよう指示する。この指示を受け、各ユーザ端末100の制御部110は、ゲーム空間を戦闘空間から共闘戦闘空間へと遷移させる(遷移t2)。戦闘空間から共闘戦闘空間へ遷移するための所定の条件は、例えば、特定の敵キャラクタ(例えば、ボスキャラクタ)の出現条件が満たされたことであってもよい。
共闘戦闘空間は、マルチプレイ機能に対応した戦闘が行われる戦闘空間である。共闘戦闘空間は、1または複数の操作キャラクタおよびノンプレイヤキャラクタと、特定の敵キャラクタ(例えば、ボスキャラクタ)とが戦闘するためのゲーム空間である。以降、同一の共闘戦闘空間にオブジェクトとして配置された1または複数の操作キャラクタおよびノンプレイヤキャラクタをまとめて「味方キャラクタ」と称する。共闘戦闘空間における共闘戦闘において味方キャラクタが敗北したり、勝利したりすると、その戦闘が終了する。共闘戦闘空間における共闘戦闘が終了すると、ゲーム空間を共闘戦闘空間から準備空間へと遷移させる(遷移t4)。特定の敵キャラクタとの共闘戦闘に勝利した場合、その共闘戦闘に参加した各ユーザは、特定の報酬を獲得し得る。この特定の報酬は、操作キャラクタが装備する装備アイテム、装備アイテムを取得するための素材アイテム、および装備アイテムを強化するための強化アイテム、の少なくとも何れかを含む。特定の報酬は、例えば、準備空間において、共闘戦闘に参加した操作キャラクタごとに付与される。
オブジェクト制御部115は共闘戦闘空間に、操作キャラクタと、少なくとも1体のボスキャラクタとを配置する。特定の敵キャラクタと戦闘する味方キャラクタの数は予め定められた数であってもよい。以下では、味方キャラクタの数が4体である場合を例に挙げて説明するが、これは単なる例であり、2体、3体、9体、11体など任意に設定され得る。
本実施形態においてオブジェクト制御部115は、共闘戦闘空間に遷移した際に操作キャラクタが4体未満である場合、味方キャラクタが合計4体となるようにノンプレイヤキャラクタを配置する。すなわち、共闘戦闘空間における共闘戦闘に参加するユーザの操作キャラクタの数が所定数(例えば4体)に満たない場合、オブジェクト制御部115は、不足分を、ゲームプログラムに基づいて動作するノンプレイヤキャラクタで補う。
共闘戦闘空間は戦闘空間と同じゲーム空間であってもよい。換言すると、制御部110は、ゲーム空間を戦闘空間から共闘戦闘空間へと遷移させるのではなく、戦闘空間において仮想カメラのカメラワークと、UI表示とを共闘戦闘空間としてのカメラワークおよびUI表示に変更することで、共闘戦闘空間を実現してもよい。
ゲーム進行処理部111が、味方キャラクタがボスキャラクタの討伐に成功したと判定した場合、制御部110は、ゲーム空間を共闘戦闘空間から戦闘空間または準備空間へと遷移させる。なお、制御部110は、ゲーム進行処理部111がボスキャラクタの討伐に成功したと判定してから一定時間が経過した後に、ゲーム空間を戦闘空間または準備空間へと遷移させてもよい。制御部110は共闘戦闘空間においてゲームを進行させているときにマップ移動など所定の移動動作を受け付けた場合、ゲーム空間を共闘戦闘空間から準備空間あるいは戦闘空間に遷移させるようにしてもよい。
本実施形態では、各ユーザ端末100はサーバ200と協働することで、マルチプレイ機能に対応するためのゲームの処理を行う。ユーザ端末100の制御部110が規定するゲーム空間には、そのユーザ端末100からログインしたアカウントに対応する操作キャラクタと、他のユーザ端末100からログインしたアカウントに対応する操作キャラクタとが配置され得る。以下では、図1~図3を参照しつつ、ゲーム空間の遷移に関するいくつかの処理例について具体的に説明する。
オブジェクト制御部115は、制御部110が規定したゲーム空間に操作キャラクタを含む各種オブジェクトを配置する。ユーザにより入力操作がなされると、オブジェクト制御部115は入力操作に応じて操作キャラクタを随時動かす。これにより、制御部110は操作キャラクタを介しユーザにゲーム空間内を探索させることができる。
サーバ200は、各ユーザ端末100にゲーム空間を共闘戦闘空間に遷移させる指示を送信する際、1または複数の操作キャラクタおよびノンプレイヤキャラクタを所定の条件に基づき、敵キャラクタと戦闘するグループとしてまとめてもよい。例えば、サーバ200は、レベルが高い操作キャラクタから順に4体の操作キャラクタを、敵キャラクタと戦闘するグループとしてまとめてもよい。サーバ200は、グループ毎に識別番号(識別No)を割り当ててもよい。同期処理部214は、グループに含まれるすべての操作キャラクタが同一の共闘戦闘空間に遷移するように、操作キャラクタを操作するために用いられる各ユーザ端末100に指示を送信する。
サーバ処理部212は、戦闘空間から共闘戦闘空間に遷移させるための所定の条件が満たされたか否かの判定を行う。例えば、サーバ処理部212は、ユーザ端末100からの同期に係る情報から、戦闘空間において所定の条件が満たされたか否かを判定すればよい。ここで、同期に係る情報とは、操作キャラクタが配置されている戦闘空間を一意に示す識別子や、戦闘空間における操作キャラクタの位置、ユーザ端末100の制御部110がゲーム空間を戦闘空間に遷移させてからの経過時間などである。
なお、戦闘空間において所定の条件が満たされたか否かの判定は、ユーザ端末100のゲーム進行処理部111が行ってもよい。この場合、制御部110は判定結果を示す情報をサーバ200に送信する。
同期処理部214は、同じ共闘戦闘空間に遷移させるユーザ端末100の最大数、すなわち共闘戦闘空間における味方キャラクタの最大数を制限してもよい。最大数を示す情報はゲーム情報122および222の少なくともいずれかに含まれる。
オブジェクト制御部115は、サーバ200からの指示とゲーム情報122とを参照し、味方キャラクタの最大数に応じて、共闘戦闘空間に操作キャラクタを配置する。オブジェクト制御部115は、共闘戦闘空間に遷移した際に味方キャラクタの数が最大数に満たない場合、最大数に不足している数だけノンプレイヤキャラクタを配置してもよい。
(操作キャラクタと敵キャラクタとの戦闘)
戦闘空間および共闘戦闘空間における戦闘について、詳細に説明する。本実施形態に係るゲームにおける「戦闘」では、ユーザおよび他のユーザの操作キャラクタと敵キャラクタとが、互いに攻撃動作を行う。なお、戦闘に係る各種処理や表示は、戦闘空間における敵キャラクタとの戦闘と、共闘戦闘空間におけるボスキャラクタとの戦闘とで共通であるから、以下では敵キャラクタとの戦闘について説明する。
操作キャラクタおよび敵キャラクタには、少なくとも体力値を含む各種パラメータ(例えば攻撃力、防御力など)の値が設定されている。操作キャラクタのパラメータの設定値はユーザ情報123に含まれ、敵キャラクタのパラメータの設定値はゲーム情報122に含まれる。
戦闘空間において、オブジェクト制御部115は、入力操作受付部112が受け付けた入力操作に応じて、ユーザが使用するユーザ端末100のアカウントに対応する操作キャラクタに、攻撃動作を行わせる。そして、ゲーム進行処理部111は、ユーザの操作キャラクタの攻撃がいずれかの敵キャラクタに当たったか否か、すなわち攻撃が成功したか否かを判定する。さらに、ゲーム進行処理部111は、ユーザの操作キャラクタの攻撃が成功したと判定した場合、攻撃対象とされた敵キャラクタに与えるダメージ値の算出を行う。さらに、ゲーム進行処理部111は、算出したダメージ値を敵キャラクタの体力値から減算する。もしくは、ゲーム進行処理部111は、算出したダメージの値を含む、敵キャラクタへのダメージの総計と、敵キャラクタの体力値とを比較する。
敵キャラクタの体力値が0以下になった場合、または敵キャラクタへのダメージの総計が敵キャラクタの体力値以上になった場合、ゲーム進行処理部111は敵キャラクタが討伐されたと判定する。
戦闘空間において、オブジェクト制御部115は、敵キャラクタに攻撃動作を行わせる。ゲーム進行処理部111は、敵キャラクタによる攻撃動作についても、操作キャラクタの攻撃動作と同様に攻撃の成否判定を行い、操作キャラクタに対する攻撃が成功した場合にはダメージ値の算出も行う。
操作キャラクタの体力値が0以下になる、または操作キャラクタへのダメージの総計が操作キャラクタの体力値以上になった場合、ゲーム進行処理部111は操作キャラクタが戦闘不能になったと判定する。この場合、入力操作受付部112が操作キャラクタに係る入力操作を受け付けても、オブジェクト制御部115は入力操作に対応する動作を操作キャラクタに行わせない。
(準備空間の具体例)
図5は、準備空間を描画した表示画面例を示す。図5の状態(A)は、準備空間の表示画面の一例を示す。図5の状態(B)は、準備空間においてクエストの一覧リストL1を含むウィンドウW1を表示させたときの表示画面の一例を示す。図5の状態(C)は、準備共闘戦闘の一覧リストL2を含む。
図5の状態(A)には、準備空間の背景に加えて、ユーザの操作キャラクタx、および、他のユーザの操作キャラクタy1、y2が表示されている。また、図5の状態(A)には、ゲームプログラム121および221に基づいて動作するノンプレイヤキャラクタz1およびノンプレイヤキャラクタz2が表示されている。ノンプレイヤキャラクタz1およびノンプレイヤキャラクタz2はそれぞれ、準備空間から戦闘空間への遷移t1、および準備空間から共闘戦闘空間への遷移t3を開始する所定の入力操作を受け付ける。図5の(A)に示す例では、抽選空間への入り口を示すオブジェクトz3が設けられている。オブジェクトz3は、準備空間から抽選空間への遷移を開始する所定の入力操作を受け付ける。
オブジェクト制御部115は、準備空間に、ユーザ端末100でログインしているアカウントに対応する操作キャラクタx、を配置している。オブジェクト制御部115は、準備空間に、他のユーザ端末100の操作キャラクタy1およびy2を配置している。さらに、オブジェクト制御部115は、準備空間に、ノンプレイヤキャラクタz1、ノンプレイヤキャラクタz2、およびオブジェクトz3を配置している。ノンプレイヤキャラクタz1およびz2は、クエストの選択、開始、および共闘戦闘の選択、開始を指示する入力操作を受け付けるためのオブジェクトである。オブジェクトz3は、共闘戦闘をプレイする権利を取得するための抽選に操作キャラクタを参加させるための入力操作を受け付けるオブジェクトである。
カメラ配置制御部113は、準備空間において、操作キャラクタxの位置および向きを基準として仮想カメラの位置および向きを決定する。例えば、カメラ配置制御部113は操作キャラクタxが視野中央やや下に写り、かつ、操作キャラクタxの後方(背面)斜め上から見下ろすような位置および向きで仮想カメラを配置する。操作キャラクタxの位置または向きを変更する操作がユーザにより行われた場合、オブジェクト制御部115は操作キャラクタxを変更後の位置および向きで配置する。またカメラ配置制御部113は、仮想カメラの位置および向きを変更後の操作キャラクタxの位置に応じた位置および向きに変更する。そして、表示制御部114は、変更後の位置に変更後の向きで配置された仮想カメラの視野領域内の準備空間および操作キャラクタxを描画する。他のユーザによる操作によって動作する操作キャラクタy1およびy2の位置および向きについても同様である。
図5の状態(A)には、メニューM1が表示されている。メニューM1には、ユーザの操作キャラクタxの現在のレベル「Lv.40」および体力値V1が表示されている。この他に、図5の状態(A)には、ユーザの入力操作のためのUIであるボタンB1、およびB2が表示されている。
このように、表示制御部114は、上述した準備空間および準備空間内のオブジェクトを描画した画像に、ユーザの入力操作のためのUIを重畳した画像を作成してもよい。例えば表示制御部114は、図5に示すようにボタンB1およびB2の画像を準備空間および上述した各種オブジェクトの画像に重畳させた画像を作成してもよい。ボタンB1は、ユーザによるゲームの設定や通知の表示指示を受け付けるためのボタンであり、ボタンB2は、ユーザによるマップ移動や装備変更等を受け付けるためのボタンである。
ユーザ端末100がノンプレイヤキャラクタz1を選択すると、ゲーム進行処理部111は表示制御部114に、ユーザが選択可能なクエストの一覧リストL1を含むウィンドウW1を描画するよう指示する。一覧リストL1に含まれているクエストは、ユーザにプレイする権利が付与されているクエストである。表示制御部114は、図5の状態(B)に示すように、ウィンドウW1を準備空間およびオブジェクトの画像に重畳した画像を作成し、表示部152に表示させる。図5の状態(B)に示す例では、ウィンドウW1の一覧リストL1には、3つのクエストが含まれている。そして、各クエストについて、クエストの名称(「モンスターAAの討伐」など)、達成条件(「モンスターAA:0/3」など)、マップ名(「草原1」など)、および報酬(「報酬:銅版」など)が記載されている。なお、一覧リストL1における各クエストの内容の表示は一例であり、同図の記載に限られない。
ここで、達成条件「モンスターAA:0/3」とは、討伐すべきモンスターAAの数が3体であることを示している。なお、クエストの達成条件の内容は特に限定されない。例えば、クエストの達成条件は、特定の敵キャラクタを特定の数だけ討伐すること、特定の敵キャラクタの討伐により得られるアイテムを特定の個数収集すること等であってもよい。
マップ名とは、クエストを選択した場合に遷移する戦闘空間または共闘戦闘空間の名称を示す。報酬とは、クエスト達成によりユーザの操作キャラクタまたはアカウントに付与する、ゲームをより有利に進行させることが可能になる物品、機能、または情報などを示す。例えば、報酬はゲーム内通貨やアイテム、操作キャラクタの能力を向上させる装備品、ならびに操作キャラクタのスキルなどであってよい。
ユーザ端末100がノンプレイヤキャラクタz2を選択すると、ゲーム進行処理部111は表示制御部114に、ユーザがプレイ可能な共闘戦闘の一覧リストL2を含むウィンドウを表示部152に表示するよう指示する。一覧リストL2に含まれている共闘戦闘は、抽選制御部116によって決定された共闘戦闘として、操作キャラクタxに関連付けてゲーム情報122に登録されている。言い換えれば、一覧リストL2に含まれている共闘戦闘は、操作キャラクタxを操作するユーザにプレイする権利が付与されている共闘戦闘である。図5の状態(C)に示す例では、一覧リストL2には共闘戦闘J1~J4の4つのクエストが含まれている。そして、各共闘戦闘について、ボスキャラクタK1の名称(「モンスターK1」など)、ボスキャラクタのレベル(「Lv.50」など)、共闘戦闘の難易度(「難易度:m1」など)が記載されている。なお、一覧リストL2における各共闘戦闘の内容の表示は一例であり、同図の記載に限られない。
ここで、共闘戦闘J1~J4は、操作キャラクタが抽選に参加し、その抽選で引き当てた共闘戦闘である。この共闘戦闘は、特定のボスキャラクタとの戦闘を含むものである。抽選制御部116は、抽選に参加する操作キャラクタxの現在のレベルに応じたレベルのボスキャラクタとの戦闘を含む共闘戦闘を決定する。ボスキャラクタのレベルは、例えば、操作キャラクタxの現在のレベルを含む所定の範囲に含まれるレベルであってもよい。該所定の範囲は、例えば、「現在の操作キャラクタxのレベル値」±「所定値」の範囲であってもよい。図5の(C)に示す例では、抽選制御部116は、レベルLv.40の操作キャラクタxに対して、レベルLv.30~50の範囲に含まれるレベルのボスキャラクタとの戦闘を含む共闘戦闘を決定している。
共闘戦闘において戦闘する各ボスキャラクタには、抽選において引き当てられる当選確率が設定されている。すなわち、ボスキャラクタには、当選確率が高いものと、当選確率が低いものとがある。図5の状態(C)に示す例では、各共闘戦闘において対戦するボスキャラクタに関する情報に加えて、抽選における当選確率の高低を示す表示Rを表示している。表示Rには、当選確率を示す情報が表示される。当選確率を段階的に示す情報として、高いものから順に、D、C、B、A、S、SSなどの表現を用いてもよい。
図5の状態(C)に示す例において、共闘戦闘J3は、レベルLv.44のボスキャラクタK3との戦闘を含む共闘戦闘であり、共闘戦闘J4は、レベルLv.16のボスキャラクタK3との戦闘を含む共闘戦闘である。共闘戦闘J4は、Lv.18のときに参加した抽選において引き当てたものであり、共闘戦闘J3は、Lv.40のときに参加した抽選において引き当てたものである。
(戦闘空間の具体例)
図6は、戦闘空間を描画した表示画面の一例を示す。図6の状態(A)は表示部152が縦向きの場合の表示画面を、図6の状態(B)は表示部152が横向きの場合の表示画面を示している。なお、表示部152が縦向きの場合の表示画面を縦画面、表示部152が横向きの場合の表示画面を横画面と称する。
図6に示す例では、戦闘空間の他に、メニューM2が表示されている。メニューM2には、ユーザの操作キャラクタxの現在のレベル「Lv.40」および総体力値「327」と体力値V1が表示されている。
カメラ配置制御部113は、戦闘空間において、準備空間と同様に、操作キャラクタxの位置および向きを基準として仮想カメラの位置および向きを決定する。ただし、カメラ配置制御部113は、縦画面と横画面とで視野領域が異なる仮想カメラを規定する。例えば、カメラ配置制御部113は、縦画面における仮想カメラの視野領域を、横画面における仮想カメラの視野領域よりも縦長としてもよい。他のアカウントに対応する操作キャラクタが自端末と同じマップ名の戦闘空間に配置される、または後から同じマップ名の戦闘空間に配置される場合、オブジェクト制御部115は当該戦闘空間に他のアカウントに対応する操作キャラクタy3を同期して配置する。
オブジェクト制御部115は、戦闘空間にユーザおよび他のユーザの操作キャラクタが戦闘可能な敵キャラクタe1を1つ以上配置する。表示制御部114は、当該操作キャラクタがいずれの敵キャラクタを攻撃の対象としているかを示すターゲットマーカt1を敵キャラクタに重畳して表示させてもよい。そして、ユーザの操作キャラクタが敵キャラクタを討伐した場合、ゲーム進行処理部111は、当該操作キャラクタに対応するアカウントに何らかの報酬を取得させてもよい。
なお、戦闘空間は複数のゲーム空間で構成されていてもよい。戦闘空間が複数のゲーム空間から成る場合、表示制御部114は、ユーザによる他の戦闘空間への移動指示を受け付けるためのオブジェクトアイコンC2等を表示してもよい。
戦闘空間でゲームが進行しているときに、入力操作受付部112が所定の操作を受け付けると、表示制御部114は、タッチスクリーン15における所定の操作が入力された位置に、所定の操作が入力されたことを示すオブジェクトを表示させる。所定の操作とは、操作キャラクタxを移動させるためのドラッグ操作(以下、「移動操作」という。)や、操作キャラクタxに攻撃動作を行わせるためのタップ操作(以下、「攻撃操作」という。)等である。入力操作受付部112は、タッチスクリーン15の任意の位置における移動操作や攻撃操作を受け付けることができる。これにより、ユーザの指などの指示体によって、操作キャラクタxや敵キャラクタの視認が妨げられることを回避できる。
表示制御部114は、入力操作受付部112が移動操作を受け付けた場合に、移動操作の方向を示すオブジェクトをタッチスクリーン15に表示させてもよい。図6の状態(A)において、表示制御部114は、位置p1を中心とする弾性オブジェクトw1を表示させている。位置p1は、入力操作受付部112がタッチオン操作を受け付けた位置である。タッチオン操作とは、タッチスクリーン15に対して指示体を接触または近接させる操作である。指示体はユーザの指などであってもよいし、スタイラスペンなどであってもよい。
ここで、ユーザが、指示体を位置p1から位置p2に移動させる移動操作を行うと、入力操作受付部112が、指示体が位置p1から位置p2に移動したことを検出する。この検出結果に基づいて、表示制御部114は、弾性オブジェクトw1を位置p2まで引き伸ばすように変形させた弾性オブジェクトw2をタッチスクリーン15に表示させる。これにより、タッチスクリーン15が検出した移動操作の方向をユーザに認識させることができる。
入力操作受付部112がドラッグ操作の入力を受け付けると、オブジェクト制御部115は、操作キャラクタxをドラッグされた方向にドラッグされた時間または距離に応じて移動させる。入力操作受付部112がタップ操作を受け付けると、オブジェクト制御部115は操作キャラクタxに攻撃動作を行わせる。そして、ゲーム進行処理部111は、操作キャラクタxの攻撃の成否判定や、ダメージ値の算出を行う。
図6に示す例では、ユーザの入力操作のためのUIであるボタンB1、B2、B3、B4、B5、およびB6が表示されている。
このように、表示制御部114は、上述した戦闘空間および戦闘空間内のオブジェクトを描写した画像に、ユーザの入力操作のためのUIを重畳して描画してもよい。ボタンB3は、操作キャラクタxの特殊攻撃を指示するための特殊攻撃ボタンである。ボタンB4は「回復ボタン」であり、操作キャラクタxの体力の回復を指示するためのものである。ボタンB5は「チャットボタン」であり、同じ戦闘空間内に配置された操作キャラクタに対応するアカウント間でチャットを行うためのものである。ボタンB6は「武器切替ボタン」であり、操作キャラクタxが装備する武器の切り替えを行うためのものである。
本実施形態では、操作キャラクタxが所持できる武器として、片手剣、両手剣、槍、双剣、弓矢が用意されている。また、それぞれの武器には、予め定められた複数種類のタイプのうちのいずれかのタイプが設定されている。ある両手剣にはバーストタイプが設定されており、当該バーストタイプの両手剣は、敵キャラクタe1を斬る機能と、敵キャラクタe1に向けて弾を射出する機能とを備えている。なお、当該バーストタイプの両手剣に充填可能な弾の総数(最大充填弾数)は、操作キャラクタxのアビリティやステータスに基づいて決定される。
戦闘空間における操作キャラクタxの向きと、当該操作キャラクタxが所持している武器の種別とは、図7に示す操作支援テーブル301によって管理される。ここで、操作キャラクタxの向きは、真北を0°とし、時計回り方向に1回転することで360°まで増大する角度で表現される。また、当該操作キャラクタxが所持している武器がバーストタイプの両手剣であれば、当該両手剣の最大充填弾数および現時点の残弾数が、操作支援テーブル301によって管理される。
この結果、操作キャラクタxが真西を向いていれば、操作支援テーブル301に設定された当該操作キャラクタxの向きは、270°を示す。また、当該操作キャラクタxがバーストタイプの両手剣を所持しており、当該両手剣の最大充填弾数が7発であり、現時点の残弾数が3発であれば、操作支援テーブル301に設定された武器種別は、バーストタイプの両手剣を示し、操作支援テーブル301に設定された最大充填弾数および残弾数はそれぞれ、7発および3発を示す。
表示制御部114は、ユーザの操作に応じた操作キャラクタxの行動に合わせてメッセージを表示させてもよい(図示せず)。例えば、表示制御部114は、操作キャラクタxが準備空間から戦闘空間へ移動した場合や、操作キャラクタxがアイテムを入手した場合に、その旨をユーザに知らせるメッセージを表示させてもよい。
なお、表示制御部114は、上述したUIに係る各種表示物(ボタン、メニュー、およびメッセージ)は、仮想カメラの位置および向きに関わらず、表示部152の表示画面において固定位置に描画することが望ましい。表示制御部114は、UIに係る各種表示物は、操作キャラクタの移動、攻撃、回復等の指示の入力を妨げないように、表示部152の表示画面の周縁部に描画することが望ましい。表示制御部114は、上述したUIに係る各種表示物の描画位置を、縦画面と横画面とで変更することが望ましい。
図8は、戦闘空間を描画した表示画面の他の一例を示す。この例では、操作キャラクタxは、バーストタイプの両手剣bb1を所持している。当該両手剣bb1の残弾数が0発であれば、即ち操作支援テーブル301に設定された残弾数が0発であれば、操作キャラクタxの向きと、両手剣bb1の最大充填弾数および残弾数とを報知するボタンB7が、操作支援テーブル301の設定に基づいて、操作キャラクタxの周囲に表示される。
図9を参照して、ボタンB7は、操作キャラクタxを囲む円形画像IM1と、操作キャラクタxの向き(弾の射出方向)を示す矢印画像IM2と、両手剣bb1の最大充填弾数および現時点の残弾数を示す弾数報知画像IM3とによって構成される。
ここで、矢印画像IM2および弾数報知画像IM3はいずれも、円形画像IM1の外側に表示される。また、弾数報知画像IM3は、最大充填弾数と同じ数(図9の例では7つ)の矩形状のアイコンによって構成される。さらに、当該アイコンは、円形画像IM1を挟んで矢印画像IM2とは反対の位置に、円形画像IM1の中心から放射状に広がるように描かれる。
ボタンB7が表示されている状態で当該ボタンB7に対するタップ操作が行われると、タップ操作毎に1発ずつ弾がリロードされる。具体的には、操作支援テーブル301に設定されている残弾数が1発ずつ増大される。また、残弾数の増大に伴って、弾数報知画像IM3を構成するアイコンのうち当該残弾数と同じ数のアイコンに色が付される。この結果、3回のタップ操作によって残弾数が0発から3発に増大されると、弾数報知画像IM3の表示態様は、図10(A)に示す態様から図10(B)に示す態様に変化する。即ち、アイコンに色を付する処理は、操作キャラクタxの前方に向かって左側のアイコンから順に実行される。
一方、表示画面のうちボタンB2~B7と異なる画像上でタップ操作が行われると、両手剣bb1を振りかざす動作が操作キャラクタxにより行われる。また、表示画面のうちボタンB2~B7と異なる画像上でフリック操作が行われると、操作キャラクタxにより回避行動が行われる。具体的には、操作キャラクタxは、しゃがみこんで横に転がる。
なお、両手剣bb1の振りかざし動作は、敵キャラクタe1を斬るために行われ、回避行動は、敵キャラクタe1の攻撃を回避するために行われる。タップ操作によって弾を1発ずつリロードしている途中で振りかざし動作または回避行動に迫られ、対応する操作が行われると、ボタンB7が非表示となる。この結果、リロードのためのタップ操作は受付けられなくなる。
両手剣bb1の残弾数が0発の状態で、表示画面のうちボタンB2~B7と異なる画像上でロングタップ操作(タッチ時間が所定時間T1(例えば0.2秒)を上回るタップ操作)が行われると、当該ロングタップ操作が継続している期間に、弾が両手剣bb1にリロードされる。
具体的には、弾は、所定時間T2(例えば1.0秒)が経過する毎に1発ずつリロードされる。操作支援テーブル301に設定されている残弾数と、弾数報知画像IM3を構成するアイコンのうち色が付されているアイコンの数とは、当該リロードに伴って増大する。ボタンB7は、当該ロングタップ操作が解除されたときに非表示となる。なお、ボタンB7は、当該ロングタップ操作が解除されてから所定時間(例えば0.5秒)が経過したときに非表示とするようにしてもよい。
また、当該ロングタップ操作が継続している状態でフリック操作が行われると、操作キャラクタxにより回避行動が行われる。具体的には、操作キャラクタxは、しゃがみこんで横に転がる。ボタンB7は、フリック操作の後に非表示となる。
両手剣bb1に1発以上の弾が充填されていれば、ボタンB7が常時表示されることはない。この場合は、表示画面のうちボタンB2~B6と異なる画像上でロングタップ操作が行われたときに、ボタンB7が表示される。ユーザは、操作キャラクタxが両手剣bb1から弾を射出する射出動作を実行可能な状態であるか否かや、当該射出動作を実行可能な状態であれば射出可能な弾数を、当該ボタンB7を構成する弾数報知画像IM3の表示態様に基づいて確認することができる。
ロングタップ操作に応じてボタンB7が表示されると、操作キャラクタxが敵キャラクタe1を向くように(敵キャラクタe1がロックオンされるように)、当該操作キャラクタxの向きが調整される。具体的には、操作支援テーブル301に設定されている操作キャラクタxの向きが、敵キャラクタe1の向きに更新される。また、ボタンB7の表示態様は、操作キャラクタxの向きの調整に対応して更新される。具体的には、矢印画像IM2は敵キャラクタe1を向くように表示され、弾数報知画像IM3は円形画像IM1を挟んで矢印画像IM2と反対側の位置に表示される。
表示画面に対する操作態様がロングタップ操作からスワイプ操作に遷移すると、操作キャラクタxの向きが変更される。具体的には、操作支援テーブル301に設定されている操作キャラクタxの向きが、スワイプ操作により指定された向きに更新される。また、ボタンB7の表示態様は、操作キャラクタxの向きの調整に対応して更新される。具体的には、矢印画像IM2はスワイプ操作により指定された方向を向くように表示され、弾数報知画像IM3は円形画像IM1を挟んで矢印画像IM2と反対側の位置に表示される。
表示画面に対する操作態様がロングタップ操作からフリック操作に遷移すると、操作キャラクタxにより回避行動が行われる。具体的には、操作キャラクタxは、しゃがみこんで横に転がる。ボタンB7は、フリック操作の実行により非表示となる。
両手剣bb1に1発以上の弾が充填されている状態でロングタップ操作が行われ、その後に当該ロングタップ操作が解除されると、コンボ条件が成立しているか否かが判定される。ここで、コンボ条件は、ボタンB2~B6と異なる画像上での2回のタップ操作およびロングタップ操作が所定時間内に連続して行われ、かつ当該ロングタップ操作が解除されることにより、成立する。
コンボ条件が成立していると判定されれば、両手剣bb1に充填されている弾を全て射出する全弾射出動作が実行される。残弾数レジスタ301に登録されている残弾数は全弾射出動作により0となり、弾数報知画像IM3を構成するアイコンの色は全て消される。ボタンB7は、色を消す処理が完了した後、引き続き表示される。
一方、コンボ条件が成立していると判定されなければ、両手剣bb1に充填されている弾を1発だけ射出する1発射出動作が実行される。残弾数レジスタ301に登録されている残弾数は1発だけ減じられ、弾数報知画像IM3を構成するアイコンのうちの1つのアイコンの色が消される。ボタンB7は、色を消す処理の後に非表示となる。
全弾射出動作および1発射出動作のいずれが実行された場合でも、射出方向に存在する全ての敵キャラクタがダメージを受ける。ただし、全弾射出動作により敵キャラクタが受けるダメージの大きさは、1発射出動作により敵キャラクタが受けるダメージの大きさよりも大きくなる。
(共闘戦闘空間の具体例)
図11は、共闘戦闘空間を描画した表示画面の一例を示す。図11の状態(A)は表示部152が縦向きの場合の表示画面を、図11の状態(B)は表示部152が横向きの場合の表示画面を示している。オブジェクト制御部115は共闘戦闘空間には、操作キャラクタxとともに、ボスキャラクタK1のオブジェクトを配置する。
共闘戦闘空間では、カメラ配置制御部113は、仮想カメラの位置および向きを、ボスキャラクタK1と、操作キャラクタxとの位置関係に基づき規定してもよい。例えば、カメラ配置制御部113は、ボスキャラクタK1が視野中央に写り、かつ、操作キャラクタxが写るような角度で仮想カメラを配置する。ボスキャラクタK1または操作キャラクタxの位置が変わると、カメラ配置制御部113は仮想カメラの位置および向きを変更後のボスキャラクタK1および操作キャラクタxの位置に応じた位置および向きに変更する。そして、表示制御部114は、変更後の仮想カメラの位置および向きに基づき共闘戦闘空間および各オブジェクトを描画する。
図11の例では、オブジェクト制御部115は、操作キャラクタxとともにボスキャラクタK1と戦闘する味方キャラクタとして、他のアカウントに対応する操作キャラクタg1およびg2、ノンプレイヤキャラクタy6が表示されている。図11において、ノンプレイヤキャラクタy6の近傍に表示された体力値には、このキャラクタy6がノンプレイヤキャラクタであることを示す[NPC]という表示が付いている(例えば、[NPC]y6)。ここでは、操作キャラクタx、g1、g2を操作するそれぞれのユーザが、同じ共闘戦闘に参加する例を示したが、これに限定されない。操作キャラクタx以外のすべての味方キャラクタがノンプレイヤキャラクタであってもよい。
共闘戦闘空間において、ボスキャラクタK1が視野中央に写り、操作キャラクタxが写るような角度で仮想カメラを配置する場合、操作キャラクタxを移動させる操作を戦闘空間とは異ならせてもよい。例えば、上方向への移動操作を、操作キャラクタxをボスキャラクタK1に向けて前進させる操作とし、下方向への移動操作を、操作キャラクタxをボスキャラクタK1から後退させる操作としてもよい。
味方キャラクタがボスキャラクタK1に予め定められた体力値を0以下にした、またはボスキャラクタK1の体力値を超えるダメージを与えた場合、ゲーム進行処理部111はボスキャラクタK1の討伐が完了したと判定する。なお、ゲーム進行処理部111は、ボスキャラクタK1を討伐したと判定した場合、操作キャラクタまたは操作キャラクタに対応するアカウントに、通常の敵キャラクタとは異なる特別な報酬を付与してもよい。この場合、報酬は戦闘に参加した操作キャラクタ間で異なっていてもよい。
表示制御部114は、表示部152に表示させる共闘戦闘空間の画像においても、図6に示した戦闘空間の画像と同様に、ユーザの入力操作のためのUIを描画してもよい。表示制御部114は、味方キャラクタ、またはボスキャラクタの行動に応じたメッセージを表示させてもよい。例えば、表示制御部114は、ゲーム進行処理部111が、操作キャラクタがボスキャラクタの弱点を突く攻撃を成功させたと判定した場合や、味方の操作キャラクタまたはノンプレイヤキャラクタが戦闘不能となったと判定した場合に、その旨を通知するメッセージを表示させてもよい。または、表示制御部114は、ゲーム進行処理部111がボスキャラクタが行動不能等の特殊な状態に陥ったと判定した場合に、その旨を通知するメッセージを表示させてもよい。
なお、表示制御部114は、上述したUIに係る各種表示物(ボタン、メニュー、およびメッセージ)は、仮想カメラの位置および向きに関わらず、表示部152の表示画面において固定位置に位置するよう描画することが望ましい。表示制御部114は、UIに係る各種表示物は、操作キャラクタの移動、攻撃、回復等の指示の入力、ならびに味方キャラクタの位置、ボスキャラクタの攻撃動作、ボスキャラクタの弱点部位の表示など、ボスキャラクタとの戦闘における重要な情報の表示を妨げないように、表示部152の表示画面の周縁部に描画することが望ましい。表示制御部114は、上述したUIに係る各種表示物の描画位置も、表示部152の向きに応じて変更することが望ましい。
<処理フロー及び画面例>
ユーザ端末100が、ゲームプログラム121に基づいて実行する処理のうち、敵キャラクタe1を攻撃する処理の流れについて、図12~図14に示すフローチャートを用いて説明する。なお、この処理は、操作キャラクタxがバーストタイプの両手剣bb1を所持(装備)しているときに、ゲーム進行処理部111、入力操作受付部112、表示制御部114、オブジェクト制御部115等によって実行される。また、以下の説明において、フローチャートを用いて説明する一連の処理ステップの流れは、ユーザ端末100によって実行されるものとして記載しているが、これらの処理ステップの少なくとも一部が、サーバ200によって実行されてもよい。
図12を参照して、ステップS01では、両手剣bb1の残弾数が0であるか否かを、操作支援テーブル301に基づいて判定する。当該残弾数が0であると判定されると、ステップS02に進み、操作支援テーブル301に基づいて操作キャラクタxの周囲にボタンB7を表示する。これにより、操作キャラクタxがバーストタイプの両手剣bb1を所持(装備)しているときであって残弾数が0のときには、残弾数が0である旨を示す態様でボタンB7を表示することができる。一方、当該残弾数が0であると判定されなければ、ステップS03に進み、当該ボタンB7を非表示とする。ステップS02または03の処理が完了すると、ステップS04に進み、表示画面がタッチされたか否かをタッチスクリーン15に対する入力操作に基づいて判定する。
当該表示画面がタッチされたと判定されなければステップS04に戻り、当該表示画面がタッチされたと判定されればステップS05に進む。ステップS05では、当該表示画面に対するタッチ操作はタップ操作に該当するか否かを、タッチスクリーン15に対する入力操作に基づいて判定する。当該タッチ操作はタップ操作に該当すると判定されれば、ステップS06に進み、タップ位置はボタンB7上であるか否かをタッチスクリーン15に対する入力操作に基づいて判定する。
当該タップ位置はボタンB7上であると判定されると、ステップS07に進み、両手剣bb1に弾を1発だけリロードする。具体的には、操作支援テーブル301に設定されている残弾数を1発だけ増大させる。ステップS08では、当該残弾数の増大に応じてボタンB7の表示態様を更新する。この結果、弾数報知画像IM3を構成するアイコンのうち色が付されているアイコンの数が1つだけ増大する。ステップS08の処理が完了すると、ステップS04に戻る。ステップS04に戻ることで、残弾数が1発以上となった後もボタンB7は表示され続ける。これによって、タップ操作毎に1発ずつ弾をリロードすることができる。
なお、ステップS07およびS08の処理が繰り返されることにより、残弾数が最大充填弾数に達すると、ボタンB7に対するタップ操作にかかわらず、ステップS07およびS08の処理は行われない。
一方、当該タップ位置はボタンB7上であると判定されなければ、ステップS09に進み、当該タップ位置はボタンB2~B6上であるか否かをタッチスクリーン15に対する入力操作に基づいて判定する。当該タップ位置はボタンB2~B6上であると判定されると、ステップS10で他の処理を実行し、その後にステップS04に戻る。一方、当該タップ位置はボタンB2~B6上であると判定されなければ、ステップS11に進み、両手剣bb1を振りかざす動作を操作キャラクタxに実行させる。ステップS11の処理が完了すると、ステップS01に戻る。
ステップS05において、当該表示画面に対するタッチ操作はタップ操作に該当すると判定されなければ、ステップS13に進み、表示画面のうちボタンB2~B7と異なる画像上でフリック操作が行われたか否かをタッチスクリーン15に対する入力操作に基づいて判定する。当該フリック操作が行われたと判定されたときは、ステップS14に進み、操作キャラクタxに回避行動を行わせる。具体的には、操作キャラクタxをしゃがみこませて横に転がらせる。ステップS14の処理が完了すると、ステップS01に戻る。
ステップS13において当該フリック操作が行われたと判定されなければ、ステップS15に進む。ステップS15では、表示画面のうちボタンB2~B7と異なる画像上でロングタップ操作(タッチ時間が所定時間T1(例えば0.2秒)を上回るタップ操作)が行われたか否かを、タッチスクリーン15に対する入力操作に基づいて判定する。ロングタップ操作が行われたと判定されなければステップS05に戻り、ロングタップ操作が行われたと判定されるとステップS16に進む。ステップS16では、両手剣bb1の残弾数は0発であるか否かを、操作支援テーブル301に基づいて判定する。
当該残弾数は0発であると判定されると、両手剣bb1に弾を1発ずつリロードする状態に移行する。まず、ステップS17で両手剣bb1に弾を1発だけリロードする。具体的には、操作支援テーブル301に設定されている残弾数を1発だけ増大させる。ステップS18では、当該残弾数の増大に応じてボタンB7の表示態様を更新する。この結果、弾数報知画像IM3を構成するアイコンのうち色が付されているアイコンの数が1つだけ増大する。
ステップS19では、残弾数が最大充填弾数と一致するか否かを操作支援テーブル301に基づいて判定する。残弾数が最大充填弾数と一致すると判定されると、ステップS20に進み、ロングタップ操作が解除されたか否かをタッチスクリーン15に対する入力操作に基づいて判定する。当該ロングタップ操作が解除されたと判定されなければステップS20に戻り、当該ロングタップ操作が解除されたと判定されればステップS01に戻る。
ステップS19において、残弾数が最大充填弾数と一致すると判定されなければ、ステップS21に進む。ステップS21では、前回のリロードから所定時間T2(例えば1.0秒)が経過したか否かを、ステップS17およびS22の処理結果に基づいて判定する。
当該所定時間T2が経過したと判定されれば、ステップS22に進み、両手剣bb1に弾を1発だけリロードする。ステップS23では、当該リロードに応じてボタンB7の表示態様を更新する。ステップS23の処理が完了すると、ステップS24に進む。なお、ステップS21において、当該所定時間T2が経過したと判定されなければ、ステップS22およびS23の処理を行うことなく、ステップS24に進む。
ステップS24では、フリック操作が行われたか否かをタッチスクリーン15に対する入力操作に基づいて判定する。当該フリック操作が行われたと判定されたときは、ステップS25に進み、操作キャラクタxに回避行動を行わせる。具体的には、操作キャラクタxをしゃがみこませて横に転がらせる。ステップS25の処理が完了すると、ステップS01に戻る。
ステップS24においてフリック操作が行われたと判定されなかったときは、ステップS26に進み、ロングタップ操作が解除されたか否かをタッチスクリーン15に対する入力操作に基づいて判定する。当該ロングタップ操作が解除されたと判定されなければステップS19に戻り、当該ロングタップ操作が解除されたと判定されれば、ステップS01に戻る。
ステップS16において、両手剣bb1の残弾数は0発であると判定されなければ、ステップS27に進み、ボタンB7を操作キャラクタの周囲に表示する。ステップS28では、操作キャラクタxが敵キャラクタe1を向くように(敵キャラクタe1がロックオンされるように)、当該操作キャラクタxの向きを調整する。具体的には、操作支援テーブル301に設定されている操作キャラクタxの向きを、敵キャラクタe1の向きに更新する。
ステップS29では、操作キャラクタxの向きの調整に対応して、ボタンB7の表示態様を更新する。具体的には、敵キャラクタe1を向くように矢印画像IM2を表示し、円形画像IM1を挟んで矢印画像IM2と反対側の位置に弾数報知画像IM3を表示する。
ステップS30では、ロングタップ操作が解除されたか否かを、タッチスクリーン15に対する入力操作に基づいて判定する。ロングタップ操作が解除されたと判定されなかったときは、ステップS31に進み、フリック操作が行われたか否かをタッチスクリーン15に対する入力操作に基づいて判定する。
当該フリック操作が行われたと判定されなかったときは、ステップS32に進み、スワイプ操作が行われたか否かをタッチスクリーン15に対する入力操作に基づいて判定する。当該スワイプ操作が行われたと判定されなかったときは、ステップS30に戻り、当該スワイプ操作が行われたと判定されたときは、ステップS33に進む。
ステップS33では、当該スワイプ操作で指定された方向を向くように、当該操作キャラクタxの向きを調整する。具体的には、操作支援テーブル301に設定されている操作キャラクタxの向きを、スワイプ操作で指定された向きに更新する。
ステップS34では、操作キャラクタxの向きの調整に対応して、ボタンB7の表示態様を更新する。具体的には、スワイプ操作で指定された方向を向くように矢印画像IM2を表示し、円形画像IM1を挟んで矢印画像IM2と反対側の位置に弾数報知画像IM3を表示する。ステップS34の処理が完了すると、ステップS30に戻る。
ステップS31においてフリック操作が行われたと判定されたときは、ステップS35で操作キャラクタxに回避行動を行わせる。具体的には、操作キャラクタxをしゃがみこませて横に転がらせる。ステップS35の処理が完了すると、ステップS01に戻る。
ステップS30においてロングタップ操作が解除されたと判定されたときは、ステップS36に進み、コンボ条件が成立しているか否かをステップS09の処理結果に基づいて判定する。当該コンボ条件が成立していると判定されると、ステップS37に進み、両手剣bb1に充填されている弾を全て射出する全弾射出動作を実行する。即ち、ボタンB2~B6と異なる画像上での2回のタップ操作およびロングタップ操作が所定時間内に連続して行われ、かつ当該ロングタップ操作が解除されると、全弾射出動作が実行される。ステップS38では、操作支援テーブル301に設定されている残弾数を0に更新する。
ステップS36において、コンボ条件が成立していると判定されなければ、ステップS39に進み、両手bb1に充填されている弾を1発射出する1発射出動作を実行する。ステップS40では、操作支援テーブル301に設定されている残弾数を1発だけ減少させる。
ステップS38またはS40の処理が完了すると、ステップS41に進み、操作支援テーブル301に設定されている残弾数の変動に対応してボタンB7の表示態様を更新する。この結果、ステップS38の処理が実行されたときは、弾数報知画像IM3を構成する全てのアイコンの色が消される。また、ステップS40の処理が実行されたときは、弾数報知画像IM3をアイコンのうちの1つのアイコンの色が消される。ステップS41の処理が完了すると、ステップS01に戻る。
<本実施形態の効果>
本実施形態によれば、両手剣bb1から弾を射出する射出動作は、残弾数が1発以上の状態でのロングタップ操作に応じて実行可能となる。また、ボタンB7は残弾数が1発以上の状態であるか否かを特定可能なボタンである。これを踏まえて、当該ボタンB7は、残弾数が1発以上の状態でのロングタップ操作に応じて、当該射出動作が実行されるまでの所定タイミングから、操作キャラクタxの周囲に表示される。これによって、残弾数を考慮して実際に射撃を行うべきか否かを思考するといった面白みを提供することができる。また、ボタンB7が操作キャラクタxの周囲に表示されることで、ユーザは、操作キャラクタxに注目してゲームを進めることができる。
また、本実施形態によれば、残弾数が0発の状態では、タッチスクリーン15に対する操作にかかわらず、ボタンB7が操作キャラクタxの周囲に継続的に表示される。これによって、操作にかかわらず、リロードが必要な状況であることを報知できる。
さらに、本実施形態によれば、残弾数が0発の状態では、表示画面上でのロングタップ操作およびボタンB7に対するタップ操作のいずれによっても、両手剣bb1へのリロードが実行される。これによって、敵キャラクタが少なく落ち着いてリロードできる状況ではロングタップ操作を行って最大充填弾数までリロードし、敵キャラクタが多く回避行動が頻繁に求められる状況ではフリック操作の合間でボタンB7に対するタップ操作を行って1発だけリロードする等のように、リロードのための操作を戦況やユーザの好みに応じて使い分けることができる。また、リロードをユーザに促すことができる。
また、本実施形態によれば、上述した所定タイミングは、ロングタップ操作により射出動作が実行可能となるタイミングである。これによって、実際に射撃を行うべきか否かを思考する機会がユーザに与えられ、ゲームの興趣を向上させることができる。
さらに、本実施形態によれば、ボタンB7は、両手剣bb1の現時点の残弾数を報知する弾数報知画像IM3を含む。これによって、敵キャラクタをどのように攻撃するかを思考する機会がユーザに与えられ、ゲームの興趣を向上させることができる。
また、本実施形態によれば、ボタンB7は、弾の射出方向を報知する矢印画像IM2を含み、ボタンB7が表示された後のスワイプ操作に応じて射出方向および矢印画像IM2の向きが変更される。これによって、射出動作が実行可能となった後に、戦況に応じて射出方向を調整することができる。
本実施形態によれば、射出動作は、残弾数が1発以上の状態でロングタップ操作が行われたときに実行可能となり、リロード動作は、残弾数が0発の状態でロングタップ操作が行われたときに実行可能となる。即ち、射出動作およびリロード動作のいずれも、共通の操作により実行可能となる。これによって、操作の簡易化が図られ、ゲームの興趣の低下を防止することができる。
また、本実施形態によれば、残弾数が0発の状態でのロングタップ操作により残弾数が増えるため、再度のロングタップ操作により射出動作が実行可能となる。これによって、残弾数が0発となったときでも、ユーザは、慌てることなくリロード動作と射出動作とを実行することができる。
さらに、本実施形態では、ロングタップ操作により射出動作が実行される毎に残弾数が減少する。次回のロングタップ操作により実行される動作は、減少後の残弾数に基づいて、射出動作およびリロード動作のうちから決定される。このため、ロングタップ操作が繰り返されると、残弾数に基づきながら、射出動作またはリロード動作が連続して実行される。これによって、操作の簡易化が図られ、ゲームの興趣の低下を防止することができる。
また、本実施形態では、ボタンB2~B6と異なる画像上での2回のタップ操作およびロングタップ操作が所定時間内に連続して行われ、かつ当該ロングタップ操作が解除されると、コンボ条件が成立し、全弾射出動作が実行される。この結果、ゲームの興趣が向上する。
さらに、本実施形態では、ロングタップ操作に応じたリロード動作は、残弾数が0発の状態でしか実行可能とならない。また、当該リロード動作では、所定時間T2が経過する毎に1発ずつしか弾が充填されない。このため、リロード動作のためのロングタップ操作を行うタイミングは注意深く見極める必要があり、この結果、ゲームの興趣が向上する。
また、本実施形態では、ロングタップ操作に応じたリロード動作の途中でフリック操作が行われると、当該リロード動作が停止され、操作キャラクタxの回避行動が実行される。この結果、敵キャラクタe1による予期しない攻撃が行われたときは、リロード動作に優先して回避行動が実行される。これによって、ゲームの興趣の低下を防止することができる。
<変形例>
以上説明した実施形態の変形例などを以下に列挙する。
(1) 上記実施形態においては、残弾数が0発の状態でロングタップ操作が行われたときに弾をリロードする処理を実行し、残弾数が1発以上の状態でロングタップ操作が行われたときに弾を射出する処理を実行するようにしている。即ち、リロード処理および射出処理はいずれも、ロングタップ操作に応じて実行される。しかし、リロード処理および射出処理はいずれも、ロングタップ操作が解除された後のタップ操作に応じて実行するようにしてもよい。この場合、リロード処理では、タップ操作が行われる毎に1発ずつ弾が充填される。また、弾を射出する処理では、残弾数を上限として、ロングタップ操作が解除されてから所定時間経過するまでのタップ操作毎に1発ずつ弾を射出するようにしてもよい。
(2) 上記実施形態においては、リロード処理はロングタップ操作の継続中に実行され、射出処理はロングタップ操作の解除に応じて実行される。しかし、リロード処理は、ロングタップ操作の解除に応じて実行するようにしてもよい。この場合、弾は最大充填弾数まで一斉に充填されるようにしてもよい。
(3) 上記実施形態においては、弾数報知画像IM3は円形画像IM1を挟んで矢印画像IM2とは反対の位置に表示され、矢印画像IM2と弾数報知画像IM3との位置関係は固定的である。しかし、弾数報知画像IM3は、弾が1発リロードされる毎に時計回り方向に回転させ、1発射出動作が行われる毎に反時計回り方向に回転させるようにしてもよい。この場合、色が付されたアイコンのうち反時計回り方向における端部のアイコンが、矢印画像IM2との関係で常に同じ位置(例えば操作キャラクタxの真後ろ)に表示される。
(4) 上記実施形態によれば、ロングタップ状態でスワイプ操作が行われたときに操作キャラクタxに回避行動(しゃがみこんで横に転がらせる行動)を行わせるようにしている。しかし、ロングタップ状態でスワイプ操作が行われたときに、操作キャラクタxをスワイプ方向に歩かせたり、走らせるようにしてもよい。
(5) 上記実施形態によれば、残弾数が0発の状態でロングタップ操作が行われたとき、当該ロングタップ操作が継続する時間に応じた数の弾を両手剣bb1にリロードするようにしている。しかし、ロングタップ操作が開始される直前の所定時間に操作キャラクタxが両手剣bb1を振りかざした回数を特定し、当該回数に応じた数の弾を両手剣bb1にリロードするようにしてもよい。
(6) 上記実施形態によれば、残弾数が0発のときに表示されるボタンB7上でのタップ操作に応じて、弾を1発ずつ両手剣bb1にリロードするようにしている。しかし、当該ボタンB7上での1回のタップ操作に応じて、弾を一斉に両手剣bb1にリロードするようにしてもよい。
(7) 上記実施形態によれば、両手剣bb1に弾をリロードするとともに残弾数報知画像IM2を構成するアイコンに色を付すことにより、リロードが実行中である旨をユーザに報知するようにしている。しかし、弾を両手剣bb1にリロードする動作(具体的には、両手剣bb1に弾を込める動作)を操作キャラクタxに行わせることにより、リロードが実行中である旨をユーザに報知するようにしてもよい。
(8) 上記実施形態によれば、両手剣bb1の最大充填弾数は、操作キャラクタxのアビリティまたはステータスにより決定するようにしている。しかし、武器を作製する工房において当該両手剣bb1のアビリティを強化できるようにし、当該アビリティにより当該両手剣bb1の最大充填弾数を決定するようにしてもよい。
(9) 上記実施形態においては、第1動作として射出動作を例示し、第2動作としてリロード動作を例示し、特定操作としてロングタップ操作を例示した。しかし、第1動作、第2動作、および特定操作は、これに限るものではない。例えば、第1動作は、ユーザにとって有利な効果を奏するスキルを発動させる動作であって、第2動作は、スキル発動に要するパラメータを増大させる動作であってもよい。また、第1動作は、キャラクタをジャンプさせる動作であって、第2動作は、ジャンプさせるための体力を増大させる動作であってもよい。また、特定操作は、複数の操作を所定の順番で行う操作(例えば、所定時間内にタップ操作→スワイプ操作→フリック操作を行う操作)などであってもよい。
(10) 上記実施形態においては、残弾数が1以上であるときには、射出処理を実行可能となるロングタップ操作と同じ操作が行われたタイミング(図12のステップS15でYES)で、状態画像としてのボタンB7を表示する例について説明した。しかし、残弾数が1以上であるときに状態画像としてのボタンB7を表示するロングタップ操作は、射出処理を実行可能となるロングタップ操作よりも短い時間により成立する操作であってもよい。これにより、射出処理を実行可能となるまでに残弾数を確認することができるため、戦略を立てる時間に余裕を持たせることができる。
(11) 上記実施形態によれば、ボタンB7上でタップ操作が行われる毎に1発ずつ弾をリロードするようにしているが、タップ操作を受付ける時間間隔については、最短値を予め設定するようにしてもよい。この場合、最短値を例えば0.5秒に設定すれば、0.5秒よりも短い間隔で行われたタップ操作は無効となる。この結果、極端に短い時間で残弾数が最大充填弾数に達するのを防止することができる。また、当該最短値は、上述した所定時間T2(ロングタップ操作に応じたリロードの時間間隔)と同じであってもよく、また所定時間T2と異なってもよい。
(12) 上記実施形態によれば、操作キャラクタxの周囲に弾数報知画像IM3を表示することで、残弾数を報知するようにしている。しかし、例えば、残弾数を示す数値をメニューM2に表示するなどの方法で、残弾数を報知するようにしてもよい。
<付記>
以上の各実施形態で説明した事項を、以下に付記する。
(付記1):
本開示に示す一実施形態のある局面によれば、プロセッサ、メモリ、およびタッチスクリーンを備えるコンピュータ(図1のユーザ端末100)において実行されるゲームプログラムであって、前記ゲームプログラムは、前記プロセッサに、仮想空間に配置されたキャラクタによる第1動作(射出動作)が許容される許容状態(残弾数>0)であるか否かを特定する第1ステップ(図14のS38、S40)と、前記タッチスクリーンに対する特定操作(ロングタップ操作)に応じて、前記第1ステップにより前記許容状態であることが特定されているときには前記第1動作を実行可能とする一方、前記第1ステップにより前記許容状態であることが特定されていないときには前記第1動作とは異なる第2動作(リロード動作)を実行可能とする第2ステップ(図12のS16)とを実行させる。
(付記2):
(付記1)において、前記第2動作は、前記許容状態にするための動作である。
(付記3):
(付記1)または(付記2)において、前記第1ステップは、前記許容状態において前記第1動作を実行可能な回数を特定し、前記第1動作が実行される毎に当該実行可能な回数までの残り回数を更新し、当該残り回数に基づいて前記許容状態であるか否かを特定し、前記第2動作は、前記残り回数を増加させるための動作である。
(付記4):
(付記3)において、前記ゲームプログラムは、前記プロセッサに、前記タッチスクリーンに対する前記特定操作とは異なる操作(タップ操作)に応じて第3動作(剣を振りかざす動作)を実行する第3ステップ(図12のS11)を実行させ、前記第2ステップは、前記第3動作を実行するための操作が行われてから所定期間が経過するまでに前記特定操作が行われることに応答して、前記残り回数に応じた第4動作を実行可能とする。
(付記5):
(付記4)において、前記第2ステップは、前記キャラクタに行わせる前記第4動作として、前記残り回数だけ前記第1動作を繰り返し実行可能とする。
(付記6):
(付記1)において、前記ゲームプログラムは、前記プロセッサに、前記タッチスクリーンに対する前記特定操作とは異なる操作に応じて第3動作(剣を振りかざす動作)を実行する第3ステップ(図12のS11)を実行させ、前記第2ステップは、前記第3ステップにおける当該操作により前記キャラクタに前記第3動作を開始させてから所定期間が経過するまでに前記特定操作が行われることに応答して、前記第3動作に続いて前記キャラクタに前記第1動作を行わせる。
(付記7):
(付記6)において、前記特定操作とはロングタップ操作であり、前記特定操作とは異なる操作とは、タップ操作であり、前記第3動作は、前記キャラクタに攻撃をさせる動作であり、前記第3ステップは、前記タップ操作を繰り返し受け付けることにより、前記キャラクタに攻撃をさせる動作を複数段にわたって実行させるものであり、前記第2ステップは、前記タップ操作による前記キャラクタに攻撃をさせる動作を開始させてから所定期間が経過するまでに前記ロングタップ操作を受け付けることにより、前記複数段にわたる攻撃動作の最終段に続いて前記第1動作を行わせる。
(付記8):
(付記1)から(付記7)のいずれかにおいて、前記第1動作は、前記仮想空間における攻撃対象に対する特定の攻撃動作であり、前記第2動作は、前記特定の攻撃動作を実行可能な残り回数を所定タイミング毎に1ずつ増加させるための動作である。
(付記9):
(付記1)から(付記8)のいずれかにおいて、前記ゲームプログラムは、前記プロセッサに、前記第2ステップにより前記第2動作が実行されているときであっても、前記タッチスクリーンに対する前記特定操作とは異なる操作(フリック操作)に応じて、当該第2動作を停止して第4動作(回避行動)を実行する第4ステップ(図13のS25)を実行させる。
(付記10):
(付記1)から(付記9)のいずれかにおいて、前記第2ステップは、前記第1ステップにより前記許容状態であることが特定されているときにおいて前記タッチスクリーンに対する特定操作が行われた後、当該特定操作の解除後に受け付けた特定指示(ロングタップ操作解除後のタップ操作)に基づいて、前記第1動作を実行する。
(付記11):
(付記1)から(付記10)のいずれかにおいて、前記第2ステップは、前記第2動作に対応する態様で前記キャラクタを動作させる(キャラクタに弾込め動作をさせる)ことにより、当該第2動作実行中である旨を報知する。
(付記12):
本開示に示す一実施形態のある局面によれば、プロセッサ、メモリ、およびタッチスクリーンを備えるコンピュータ(図1のユーザ端末100)により実行されるゲーム方法であって、前記ゲーム方法は、前記コンピュータが、仮想空間に配置されたキャラクタによる第1動作(射出動作)が許容される許容状態(残弾数>0)であるか否かを特定する第1ステップ(図14のS38、S40)と、前記タッチスクリーンに対する特定操作(ロングタップ操作)に応じて、前記第1ステップにより前記許容状態であることが特定されているときには前記第1動作を実行可能とする一方、前記第1ステップにより前記許容状態であることが特定されていないときには前記第1動作とは異なる第2動作(リロード動作)を実行可能とする第2ステップ(図12のS16)とを備える。
(付記13):
本開示に示す一実施形態のある局面によれば、情報処理装置(図1のユーザ端末100)であって、ゲームプログラムを記憶する記憶部(図3の120)と、前記ゲームプログラムを実行することにより、前記情報処理装置の動作を制御する制御部(図3の110)とを備え、前記制御部は、仮想空間に配置されたキャラクタによる第1動作(射出動作)が許容される許容状態(残弾数>0)であるか否かを特定する第1ステップ(図14のS38、S40)と、前記タッチスクリーンに対する特定操作(ロングタップ操作)に応じて、前記第1ステップにより前記許容状態であることが特定されているときには前記第1動作を実行可能とする一方、前記第1ステップにより前記許容状態であることが特定されていないときには前記第1動作とは異なる第2動作(リロード動作)を実行可能とする第2ステップ(図12のS16)とを実行する。
〔ソフトウェアによる実現例〕
制御部210の制御ブロック(特に、送受信部211、サーバ処理部212、データ管理部213および同期処理部214)と、制御部110の制御ブロック(特に、ゲーム進行処理部111、入力操作受付部112、カメラ配置制御部113、表示制御部114、オブジェクト制御部115、抽選制御部116およびポイント管理部117)とは、集積回路(ICチップ)等に形成された論理回路(ハードウェア)によって実現してもよいし、CPU(Central Processing Unit)を用いてソフトウェアによって実現してもよい。
後者の場合、制御部210または制御部110、もしくはその両方を備えた情報処理装置は、各機能を実現するソフトウェアであるプログラムの命令を実行するCPU、上記プログラムおよび各種データがコンピュータ(またはCPU)で読み取り可能に記録されたROM(Read Only Memory)または記憶装置(これらを「記録媒体」と称する)、上記プログラムを展開するRAM(Random Access Memory)などを備えている。そして、コンピュータ(またはCPU)が上記プログラムを上記記録媒体から読み取って実行することにより、本発明の目的が達成される。上記記録媒体としては、「一時的でない有形の媒体」、例えば、テープ、ディスク、カード、半導体メモリ、プログラマブルな論理回路などを用いることができる。また、上記プログラムは、該プログラムを伝送可能な任意の伝送媒体(通信ネットワークや放送波等)を介して上記コンピュータに供給されてもよい。なお、本発明の一態様は、上記プログラムが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。
本発明は上述した各実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。