(57)【特許請求の範囲】
【請求項１】
ゲームに参加する複数のプレイヤそれぞれのゲーム端末間で情報を送受信する送受信部と、
前記ゲーム端末に入力される登録要求操作に基づき、プレイヤが操作可能な操作対象オブジェクトを参加オブジェクトとして登録し、前記操作対象オブジェクトの登録数が所定数未満の場合、コンピュータ制御に基づいて動作する未操作オブジェクトを前記参加オブジェクトとして登録する登録部と、
前記操作対象オブジェクトと、該操作対象オブジェクトを操作可能なプレイヤとを対応させ、前記未操作オブジェクトをいずれかのプレイヤに対応させるプレイヤ設定部と、
前記ゲーム中に前記ゲーム端末に入力される操作またはコンピュータ制御に基づいて、継続可能状態の前記参加オブジェクトを動作させ、前記参加オブジェクトが継続不可能状態であれば、該参加オブジェクトの動作を不可能とするゲーム実行部と、
前記継続不可能状態となった前記参加オブジェクトを前記継続可能状態に復活させる復活処理の上限回数である復活可能回数を、前記ゲームに参加するプレイヤごとに設定する回数設定部と、
前記ゲーム中に前記参加オブジェクトが前記継続不可能状態となった場合、該参加オブジェクトに対応するプレイヤに設定された前記復活可能回数の範囲内で、該参加オブジェクトの前記復活処理を実行可能とする復活処理実行部と、
してコンピュータを機能させる情報処理プログラム。
【請求項２】
前記ゲームは、一のプレイヤでプレイするソロプレイが可能であり、
前記登録部は、前記ソロプレイが実行される場合にも、前記未操作オブジェクトを前記参加オブジェクトとして登録し、
前記回数設定部は、前記ソロプレイにおいて、前記参加オブジェクトごとに前記復活可能回数を設定する、
請求項１に記載の情報処理プログラム。
【請求項３】
前記ゲームには、前記参加オブジェクトの登録数の上限である定員数が設けられており、
前記登録部は、前記定員数と、前記操作対象オブジェクトの登録数との差分だけ、前記未操作オブジェクトを前記参加オブジェクトとして登録する、
請求項１または２に記載の情報処理プログラム。
【請求項４】
前記復活処理実行部は、
前記未操作オブジェクトが対応付けられたプレイヤについて、対応する全ての前記参加オブジェクトが前記継続不可能状態となった場合に、前記復活処理を実行する、
請求項１から３のいずれか1項に記載の情報処理プログラム。
【請求項５】
ゲーム端末、および、前記ゲーム端末と通信可能なサーバのいずれか一方または双方が実行する情報処理方法であって、
ゲームに参加する複数のプレイヤそれぞれの前記ゲーム端末と情報の送受信を行うステップと、
前記ゲーム端末に入力される登録要求操作に基づき、プレイヤが操作可能な操作対象オブジェクトを参加オブジェクトとして登録し、前記操作対象オブジェクトの登録数が所定数未満の場合、コンピュータ制御に基づいて動作する未操作オブジェクトを前記参加オブジェクトとして登録するステップと、
前記操作対象オブジェクトと、該操作対象オブジェクトを操作可能なプレイヤとを対応させ、前記未操作オブジェクトをいずれかのプレイヤに対応させるステップと、
前記ゲーム中に前記ゲーム端末に入力される操作またはコンピュータ制御に基づいて、継続可能状態の前記参加オブジェクトを動作させ、前記参加オブジェクトが継続不可能状態であれば、該参加オブジェクトの動作を不可能とするステップと、
前記継続不可能状態となった前記参加オブジェクトを前記継続可能状態に復活させる復活処理の上限回数である復活可能回数を、前記ゲームに参加するプレイヤごとに設定するステップと、
前記ゲーム中に前記参加オブジェクトが前記継続不可能状態となった場合、該参加オブジェクトに対応するプレイヤに設定された前記復活可能回数の範囲内で、該参加オブジェクトの前記復活処理を実行可能とするステップと、
を含む情報処理方法。
【請求項６】
ゲーム端末と、前記ゲーム端末と通信可能なサーバとを備える情報処理システムであって、
前記ゲーム端末および前記サーバのいずれか一方または双方が、
ゲームに参加する複数のプレイヤそれぞれのゲーム端末間で情報を送受信する送受信部と、
前記ゲーム端末に入力される登録要求操作に基づき、プレイヤが操作可能な操作対象オブジェクトを参加オブジェクトとして登録し、前記操作対象オブジェクトの登録数が所定数未満の場合、コンピュータ制御に基づいて動作する未操作オブジェクトを前記参加オブジェクトとして登録する登録部と、
前記操作対象オブジェクトと、該操作対象オブジェクトを操作可能なプレイヤとを対応させ、前記未操作オブジェクトをいずれかのプレイヤに対応させるプレイヤ設定部と、
前記ゲーム中に前記ゲーム端末に入力される操作またはコンピュータ制御に基づいて、継続可能状態の前記参加オブジェクトを動作させ、前記参加オブジェクトが継続不可能状態であれば、該参加オブジェクトの動作を不可能とするゲーム実行部と、
前記継続不可能状態となった前記参加オブジェクトを前記継続可能状態に復活させる復活処理の上限回数である復活可能回数を、前記ゲームに参加するプレイヤごとに設定する回数設定部と、
前記ゲーム中に前記参加オブジェクトが前記継続不可能状態となった場合、該参加オブジェクトに対応するプレイヤに設定された前記復活可能回数の範囲内で、該参加オブジェクトの前記復活処理を実行可能とする復活処理実行部と、
を備える情報処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理プログラム、情報処理方法および情報処理システムに関する。
【背景技術】
【０００２】
従来、特許文献１に示されるように、チームを構成する複数のプレイヤが協力して敵キャラクタとバトルを行うゲームが知られている。こうしたゲームにおいては、プレイヤが操作可能な操作対象キャラクタにＨＰが設定されており、ＨＰが０になるまでの間は、プレイヤの操作によって操作対象キャラクタを動作させることができる。一方、操作対象キャラクタのＨＰが０になると、継続不可能状態となり、以後、操作対象キャラクタの動作が不可能となる。
【０００３】
また、特許文献１に示されるゲームでは、継続不可能状態となった操作対象キャラクタが、他のプレイヤの協力によって、継続可能状態に復活する所謂復活処理が実行される。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１９−１５５１６８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
複数のプレイヤが協力してプレイするゲームにおいては、定員数のプレイヤが集まるまでに長時間を要することがある。そこで、参加するプレイヤが定員数未満の場合に、ＮＰＣ（Non player character）を参加させることで、定員数未満のプレイヤでも開始することができるゲームが知られている。
【０００６】
しかしながら、ＮＰＣを参加させることで、例えば、上級者等は、定員数のプレイヤが揃うのを待たずにゲームを開始してしまう可能性が高くなる。その結果、複数のプレイヤが協力してプレイするゲームの醍醐味が損なわれるおそれがある。
【０００７】
本発明は、複数のプレイヤが協力してプレイするゲームの興趣を高めることが可能な情報処理プログラム、情報処理方法および情報処理システムを提供することを目的としている。
【課題を解決するための手段】
【０００８】
上記課題を解決するために、情報処理プログラムは、ゲームに参加する複数のプレイヤそれぞれのゲーム端末間で情報を送受信する送受信部と、ゲーム端末に入力される登録要求操作に基づき、プレイヤが操作可能な操作対象オブジェクトを参加オブジェクトとして登録し、操作対象オブジェクトの登録数が所定数未満の場合、コンピュータ制御に基づいて動作する未操作オブジェクトを参加オブジェクトとして登録する登録部と、操作対象オブジェクトと、該操作対象オブジェクトを操作可能なプレイヤとを対応させ、未操作オブジェクトをいずれかのプレイヤに対応させるプレイヤ設定部と、ゲーム中にゲーム端末に入力される操作またはコンピュータ制御に基づいて、継続可能状態の参加オブジェクトを動作させ、参加オブジェクトが継続不可能状態であれば、該参加オブジェクトの動作を不可能とするゲーム実行部と、継続不可能状態となった参加オブジェクトを継続可能状態に復活させる復活処理の上限回数である復活可能回数を、ゲームに参加するプレイヤごとに設定する回数設定部と、ゲーム中に参加オブジェクトが継続不可能状態となった場合、該参加オブジェクトに対応するプレイヤに設定された復活可能回数の範囲内で、該参加オブジェクトの復活処理を実行可能とする復活処理実行部と、してコンピュータを機能させる。
【０００９】
また、ゲームは、一のプレイヤでプレイするソロプレイが可能であり、登録部は、ソロプレイが実行される場合にも、未操作オブジェクトを参加オブジェクトとして登録し、回数設定部は、ソロプレイにおいて、参加オブジェクトごとに復活可能回数を設定してもよい。
【００１０】
また、ゲームには、参加オブジェクトの登録数の上限である定員数が設けられており、登録部は、定員数と、操作対象オブジェクトの登録数との差分だけ、未操作オブジェクトを参加オブジェクトとして登録してもよい。
【００１１】
また、復活処理実行部は、未操作オブジェクトが対応付けられたプレイヤについて、対応する全ての参加オブジェクトが継続不可能状態となった場合に、復活処理を実行してもよい。
【００１２】
上記課題を解決するために、情報処理方法は、ゲーム端末、および、ゲーム端末と通信可能なサーバのいずれか一方または双方が実行する情報処理方法であって、ゲームに参加する複数のプレイヤそれぞれのゲーム端末と情報の送受信を行うステップと、ゲーム端末に入力される登録要求操作に基づき、プレイヤが操作可能な操作対象オブジェクトを参加オブジェクトとして登録し、操作対象オブジェクトの登録数が所定数未満の場合、コンピュータ制御に基づいて動作する未操作オブジェクトを参加オブジェクトとして登録するステップと、操作対象オブジェクトと、該操作対象オブジェクトを操作可能なプレイヤとを対応させ、未操作オブジェクトをいずれかのプレイヤに対応させるステップと、ゲーム中にゲーム端末に入力される操作またはコンピュータ制御に基づいて、継続可能状態の参加オブジェクトを動作させ、参加オブジェクトが継続不可能状態であれば、該参加オブジェクトの動作を不可能とするステップと、継続不可能状態となった参加オブジェクトを継続可能状態に復活させる復活処理の上限回数である復活可能回数を、ゲームに参加するプレイヤごとに設定するステップと、ゲーム中に参加オブジェクトが継続不可能状態となった場合、該参加オブジェクトに対応するプレイヤに設定された復活可能回数の範囲内で、該参加オブジェクトの復活処理を実行可能とするステップと、を含む。
【００１３】
上記課題を解決するために、情報処理システムは、ゲーム端末と、ゲーム端末と通信可能なサーバとを備える情報処理システムであって、ゲーム端末およびサーバのいずれか一方または双方が、ゲームに参加する複数のプレイヤそれぞれのゲーム端末間で情報を送受信する送受信部と、ゲーム端末に入力される登録要求操作に基づき、プレイヤが操作可能な操作対象オブジェクトを参加オブジェクトとして登録し、操作対象オブジェクトの登録数が所定数未満の場合、コンピュータ制御に基づいて動作する未操作オブジェクトを参加オブジェクトとして登録する登録部と、操作対象オブジェクトと、該操作対象オブジェクトを操作可能なプレイヤとを対応させ、未操作オブジェクトをいずれかのプレイヤに対応させるプレイヤ設定部と、ゲーム中にゲーム端末に入力される操作またはコンピュータ制御に基づいて、継続可能状態の参加オブジェクトを動作させ、参加オブジェクトが継続不可能状態であれば、該参加オブジェクトの動作を不可能とするゲーム実行部と、継続不可能状態となった参加オブジェクトを継続可能状態に復活させる復活処理の上限回数である復活可能回数を、ゲームに参加するプレイヤごとに設定する回数設定部と、ゲーム中に参加オブジェクトが継続不可能状態となった場合、該参加オブジェクトに対応するプレイヤに設定された復活可能回数の範囲内で、該参加オブジェクトの復活処理を実行可能とする復活処理実行部と、を備える。
【発明の効果】
【００１４】
本発明によれば、複数のプレイヤが協力してプレイするゲームの興趣を高めることができる。
【図面の簡単な説明】
【００１５】
【図１】図１は、情報処理システムの概略的な構成を示した説明図である。
【図２】図２Ａは、プレイヤ端末のハードウェアの構成を説明する図である。図２Ｂは、サーバのハードウェアの構成を説明する図である。
【図３】図３Ａおよび図３Ｂは、パーティ編成画面の一例を説明する図である。
【図４】図４Ａは、クエスト選択画面の一例を説明する図である。図４Ｂは、プレイモード選択画面の一例を説明する図である。図４Ｃは、パーティ選択画面の一例を説明する図である。
【図５】図５Ａは、クエスト開始画面の一例を説明する図である。図５Ｂは、ソロプレイによるバトルゲーム中のバトルゲーム画面の一例を説明する図である。図５Ｃは、スキルゲージおよび竜化ゲージの一例を説明する図である。図５Ｄは、竜化を説明する図である。
【図６】図６Ａは、ソロプレイにおける復活処理を説明する第１の図である。図６Ｂは、ソロプレイにおける復活処理を説明する第２の図である。図６Ｃは、ソロプレイにおける復活処理を説明する第３の図である。図６Ｄは、ソロプレイにおける復活処理を説明する第４の図である。
【図７】図７Ａは、復活時のバトルゲーム画面の一例を説明する図である。図７Ｂは、プレイヤの勝利時のバトルゲーム画面の一例を説明する図である。図７Ｃは、報酬画面の一例を説明する図である。
【図８】図８Ａは、基礎報酬抽選テーブルの一例を説明する図である。図８Ｂは、復活回数報酬抽選テーブルの一例を説明する図である。
【図９】図９Ａは、ルーム選択画面の一例を説明する図である。図９Ｂは、ルーム待機画面の一例を説明する図である。図９Ｃは、プレイヤと未操作キャラとの対応関係を説明する第１の図である。図９Ｄは、プレイヤと未操作キャラとの対応関係を説明する第２の図である。
【図１０】図１０Ａは、ルームの満室状態を説明する図である。図１０Ｂは、準備完了状態を説明する図である。
【図１１】図１１Ａは、４人プレイにおける復活処理を説明する第１の図である。図１１Ｂは、４人プレイにおける復活処理を説明する第２の図である。図１１Ｃは、４人プレイにおける復活処理を説明する第３の図である。図１１Ｄは、４人プレイにおける復活処理を説明する第４の図である。
【図１２】図１２Ａは、３人プレイにおける復活処理を説明する第１の図である。図１２Ｂは、３人プレイにおける復活処理を説明する第２の図である。図１２は、３人プレイにおける復活処理を説明する第３の図である。図１２は、３人プレイにおける復活処理を説明する第４の図である。
【図１３】図１３Ａは、クエストごとの復活可能回数を説明する図である。図１３Ｂは、マルチプレイに参加するプレイヤ数と、各プレイヤの復活可能回数とを説明する図である。
【図１４】図１４は、プレイヤ端末およびサーバの機能的構成を説明する図である。
【図１５】図１５は、プレイヤ端末およびサーバにおけるソロプレイに係る処理を説明するシーケンス図である。
【図１６】図１６は、プレイヤ端末におけるクエスト開始処理を説明するフローチャートである。
【図１７】図１７は、プレイヤ端末におけるソロプレイ実行処理を説明する第１のフローチャートである。
【図１８】図１８は、プレイヤ端末におけるソロプレイ実行処理を説明する第２のフローチャートである。
【図１９】図１９は、プレイヤ端末におけるソロプレイ時の復活判定処理を説明するフローチャートである。
【図２０】図２０は、プレイヤ端末およびサーバにおけるマルチプレイに係る処理を説明する第１のシーケンス図である。
【図２１】図２１は、プレイヤ端末およびサーバにおけるマルチプレイに係る処理を説明する第２のシーケンス図である。
【図２２】図２２は、プレイヤ端末およびサーバにおけるマルチプレイに係る処理を説明する第３のシーケンス図である。
【図２３】図２３は、サーバにおけるキャラクタ設定処理を説明するフローチャートである。
【図２４】図２４は、サーバにおける同期処理を説明するフローチャートである。
【図２５】図２５は、ゲスト端末におけるゲストマルチプレイ実行処理を説明する第１のフローチャートである。
【図２６】図２６は、ゲスト端末におけるゲストマルチプレイ実行処理を説明する第２のフローチャートである。
【図２７】図２７は、プレイヤ端末におけるマルチプレイ時の復活判定処理を説明するフローチャートである。
【図２８】図２８は、ホスト端末におけるホストマルチプレイ実行処理を説明する第１のフローチャートである。
【図２９】図２９は、ホスト端末におけるホストマルチプレイ実行処理を説明する第２のフローチャートである。
【発明を実施するための形態】
【００１６】
以下に添付図面を参照しながら、本発明の実施形態の一態様について詳細に説明する。かかる実施形態に示す数値等は、理解を容易とするための例示にすぎず、特に断る場合を除き、本発明を限定するものではない。なお、本明細書および図面において、実質的に同一の機能、構成を有する要素については、同一の符号を付することにより重複説明を省略し、また本発明に直接関係のない要素は図示を省略する。
【００１７】
（情報処理システムＳの全体の構成）
図１は、情報処理システムＳの概略的な構成を示した説明図である。情報処理システムＳは、プレイヤ端末１（ゲーム端末）と、サーバ１００と、通信基地局２００ａを有する通信ネットワーク２００とを含む、所謂クライアントサーバシステムである。
【００１８】
本実施形態の情報処理システムＳは、プレイヤ端末１およびサーバ１００がゲーム装置Ｇとして機能する。プレイヤ端末１およびサーバ１００には、それぞれゲームの進行制御の役割分担がなされており、プレイヤ端末１とサーバ１００との協働によって、ゲームが進行可能となる。
【００１９】
プレイヤ端末１は、通信ネットワーク２００を介してサーバ１００との通信を確立することができる。プレイヤ端末１は、サーバ１００と無線もしくは有線による通信接続が可能な電子機器を広く含む。プレイヤ端末１としては、例えば、スマートフォン、携帯電話、タブレット装置、パーソナルコンピュータ、ゲーム機器等が挙げられる。本実施形態では、プレイヤ端末１として、スマートフォンが用いられる場合について説明する。
【００２０】
サーバ１００は、複数のプレイヤ端末１と通信接続される。サーバ１００は、管理サーバ１００Ａと、バトルゲームサーバ１００Ｂとを含む。管理サーバ１００Ａは、ゲームをプレイするプレイヤごとに各種の情報（プレイヤ情報）を蓄積する。また、管理サーバ１００Ａは、主に、プレイヤ端末１から入力される操作に基づき、蓄積された情報の更新や、プレイヤ端末１に対して画像や各種情報をダウンロードさせる等の処理を遂行する。
【００２１】
また、情報処理システムＳは、複数のプレイヤが協力して敵キャラクタと対戦するバトルゲームを実現する。バトルゲームサーバ１００Ｂは、主に、バトルゲームを遂行するためのルームの作成、ルームへのプレイヤの割り振り、ルームに接続された複数のプレイヤ端末１との情報の送受信、複数のプレイヤ端末１の同期化等、バトルゲームの進行制御を行うための処理を遂行する。
【００２２】
以下では、情報処理システムＳにより提供されるゲームのうち、バトルゲームをインゲームと呼び、バトルゲーム以外のゲームをアウトゲームと呼ぶ。管理サーバ１００Ａは、主にアウトゲームに係る処理を遂行し、バトルゲームサーバ１００Ｂは、主にインゲームに係る処理を遂行する。
【００２３】
通信基地局２００ａは、通信ネットワーク２００と接続され、プレイヤ端末１と無線による情報の送受信を行う。通信ネットワーク２００は、携帯電話網、インターネット網、ＬＡＮ(Local Area Network)、専用回線等で構成され、プレイヤ端末１とサーバ１００との無線もしくは有線による通信接続を実現する。
【００２４】
（プレイヤ端末１およびサーバ１００のハードウェアの構成）
図２Ａは、プレイヤ端末１のハードウェアの構成を説明する図である。また、図２Ｂは、サーバ１００のハードウェアの構成を説明する図である。図２Ａに示すように、プレイヤ端末１は、ＣＰＵ(Central Processing Unit)１０、メモリ１２、バス１４、入出力インタフェース１６、記憶部１８、通信部２０、入力部２２、出力部２４を含んで構成される。
【００２５】
また、図２Ｂに示すように、管理サーバ１００Ａおよびバトルゲームサーバ１００Ｂは、ＣＰＵ１１０、メモリ１１２、バス１１４、入出力インタフェース１１６、記憶部１１８、通信部１２０、入力部１２２、出力部１２４を含んで構成される。
【００２６】
なお、管理サーバ１００Ａおよびバトルゲームサーバ１００ＢのＣＰＵ１１０、メモリ１１２、バス１１４、入出力インタフェース１１６、記憶部１１８、通信部１２０、入力部１２２、出力部１２４の構成および機能は、それぞれ、プレイヤ端末１のＣＰＵ１０、メモリ１２、バス１４、入出力インタフェース１６、記憶部１８、通信部２０、入力部２２、出力部２４と実質的に同じである。したがって、以下では、プレイヤ端末１のハードウェアの構成について説明し、管理サーバ１００Ａおよびバトルゲームサーバ１００Ｂについては説明を省略する。
【００２７】
ＣＰＵ１０は、メモリ１２に記憶されたプログラムを動作させ、ゲームの進行を制御する。メモリ１２は、ＲＯＭ(Read Only Memory)またはＲＡＭ(Random Access Memory)で構成され、ゲームの進行制御に必要となるプログラムおよび各種のデータを記憶する。メモリ１２は、バス１４を介してＣＰＵ１０に接続されている。
【００２８】
バス１４には、入出力インタフェース１６が接続される。入出力インタフェース１６には、記憶部１８、通信部２０、入力部２２、出力部２４が接続されている。
【００２９】
記憶部１８は、ＤＲＡＭ(Dynamic Random Access Memory)等の半導体メモリで構成され、各種プログラムおよびデータを記憶する。プレイヤ端末１においては、記憶部１８に記憶されたプログラムおよびデータが、ＣＰＵ１０によってメモリ１２（ＲＡＭ）にロードされる。
【００３０】
通信部２０は、通信基地局２００ａと無線により通信接続され、通信ネットワーク２００を介して、サーバ１００との間で各種データおよびプログラムといった情報の送受信を行う。プレイヤ端末１においては、サーバ１００から受信したプログラム等が、メモリ１２または記憶部１８に格納される。
【００３１】
入力部２２は、例えば、プレイヤの操作が入力される（操作を受け付ける）タッチパネル、ボタン、キーボード、マウス、十字キー、アナログコントローラ等で構成される。また、入力部２２は、プレイヤ端末１に設けられた、あるいは、プレイヤ端末１に接続（外付け）された専用のコントローラであってもよい。さらには、入力部２２は、プレイヤ端末１の傾きや移動を検知する加速度センサ、または、プレイヤの音声を検知するマイクで構成されてもよい。すなわち、入力部２２は、プレイヤの意思を、識別可能に入力させることができる装置を広く含む。
【００３２】
出力部２４は、ディスプレイ装置およびスピーカを含んで構成される。なお、出力部２４は、プレイヤ端末１に接続（外付け）される機器でもよい。本実施形態では、プレイヤ端末１が、出力部２４としてディスプレイ２６を備え、入力部２２として、ディスプレイ２６に重畳して設けられるタッチパネルを備えている。
【００３３】
（ゲーム内容）
次に、本実施形態の情報処理システムＳ（ゲーム装置Ｇ）により提供されるゲームの内容について、一例を用いて説明する。プレイヤは、所謂ガチャと呼ばれる抽選により獲得したキャラクタや、運営側から配布されたキャラクタを所有することができる。プレイヤは、所有するキャラクタ（以下、所有キャラという）から複数（ここでは４体）を選択してパーティを編成することができ、編成したパーティを用いて敵キャラクタと対戦するバトルゲームをプレイすることができる。
【００３４】
図３Ａおよび図３Ｂは、パーティ編成画面の一例を説明する図である。アウトゲーム中、ディスプレイ２６の下部には、メニューバー３０が表示される。メニューバー３０には、パーティ編成選択部３０ａおよびクエスト選択部３０ｂを含む複数の選択部が設けられている。パーティ編成選択部３０ａがタップされると、図３Ａに示すように、パーティ編成画面が表示される。パーティ編成画面には、プレイヤが編成したパーティ情報が表示される。
【００３５】
プレイヤは、４体の所有キャラを選択して１つのパーティを登録する。パーティ編成画面では、登録されているパーティを構成するキャラクタ（以下、パーティ編成キャラという）の情報が横並びに表示される。具体的には、プレイヤは、１つのパーティに対して、４体の所有キャラを、第１パーティ編成キャラ、第２パーティ編成キャラ、第３パーティ編成キャラ、第４パーティ編成キャラとして登録することができる。パーティ編成画面では、左から順に、第１パーティ編成キャラ、第２パーティ編成キャラ、第３パーティ編成キャラ、第４パーティ編成キャラに係る情報が表示される。
【００３６】
パーティ編成キャラの各情報が表示されている領域をタップしてパーティ編成キャラが選択されると、不図示の所有キャラ一覧画面が表示される。プレイヤは、この所有キャラ一覧画面において、いずれかの所有キャラを選択することで、パーティ編成キャラを入れ替えることができる。
【００３７】
なお、パーティ編成画面において、最も左側に表示される第１パーティ編成キャラは、当該パーティのリーダーとして登録される。パーティ編成画面では、例えば、第１パーティ編成キャラをタップした後、他のパーティ編成キャラをタップすることで、リーダーを入れ替えることもできる。つまり、プレイヤは、パーティ編成画面において、リーダーとなるパーティ編成キャラを登録することができる。
【００３８】
また、プレイヤは、複数のパーティを予め登録しておくことができる。ここでは、最大で９つのパーティを登録することができる。パーティ編成画面において、左右方向のフリック操作が入力されると、表示されるパーティ情報が切り替わる。例えば、図３Ａに示すように、第１パーティに係るパーティ情報が表示された状態で左方向のフリック操作が入力されると、図３Ｂに示すように、第２パーティに係るパーティ情報が表示される。
【００３９】
パーティ編成画面にパーティ情報が表示されているパーティは、プレイヤの選択中パーティとして登録される。例えば、図３Ｂに示すように、第２パーティに係るパーティ情報が表示された状態で、メニューバー３０の他の選択部がタップされてパーティ編成画面の表示が終了したとする。この場合、パーティ編成画面の終了時にパーティ情報が表示されていた第２パーティが、選択中パーティとして登録されることとなる。
【００４０】
なお、各キャラクタには、ヒットポイント（以下、ＨＰという）や攻撃力等のパラメータが設定されている。プレイヤは、所有キャラを育成することができ、所有キャラのレベルを上げることで、各種のパラメータを高めることができる。パーティ編成画面に表示されるパーティ情報には、各パーティ編成キャラのパラメータが表示される。
【００４１】
また、詳しい説明は省略するが、パーティ編成画面では、各パーティ編成キャラに、武器等の装備品、および、ドラゴンを装備することができる。プレイヤは、装備品を装備することにより、バトルゲームに参加しているパーティ編成キャラ（以下、参加キャラという）のＨＰや攻撃力等のパラメータを高めたり、敵キャラクタのパラメータを下げたりする等、バトルゲームを有利に進めることができる。
【００４２】
また、ドラゴンは、参加キャラが変身可能なキャラクタである。バトルゲーム中に所定条件が成立すると、プレイヤは、所定時間に限り、参加キャラを、装備中のドラゴンに変身させることができる。ドラゴンは、敵キャラクタに大きなダメージを与えることができるため、参加キャラをドラゴンに変身させることで、バトルゲームを有利に進めることが可能となる。
【００４３】
さらに、各所有キャラや装備品には、予めスキルが設定されている。スキルというのは、バトルゲーム中に所定条件が成立することで使用可能となる特殊能力であり、スキルを使用することで、プレイヤはバトルゲームを有利に進めることができる。一例として、スキルの使用により、敵キャラクタにダメージを与える、参加キャラの攻撃力を高める、参加キャラのＨＰを回復する、敵キャラクタの攻撃力を下げる等、各種のパラメータを変化させることができる。パーティ編成画面に表示されるパーティ情報には、各パーティ編成キャラの装備品およびドラゴンの装備情報や、スキルに係る情報も表示される。
【００４４】
図４Ａは、クエスト選択画面の一例を説明する図である。図４Ｂは、プレイモード選択画面の一例を説明する図である。図４Ｃは、パーティ選択画面の一例を説明する図である。メニューバー３０のクエスト選択部３０ｂがタップされると、図４Ａに示すクエスト選択画面が表示される。ここで、クエストと言うのは、バトルゲームの種別を示すものであり、バトルゲームの内容とも言える。本実施形態では、複数のクエストが設けられており、クエスト選択画面には、複数のクエスト選択操作部３２が表示される。
【００４５】
プレイヤは、クエスト選択操作部３２をタップすることで、いずれか１のクエストを選択してバトルゲームをプレイすることができる。クエスト選択操作部３２がタップされると、図４Ｂに示すプレイモード選択画面が表示される。プレイモード選択画面には、ソロプレイ選択部３４ａと、マルチプレイ選択部３４ｂとが表示される。各クエストは、プレイヤ端末１を操作するプレイヤが１人でプレイするソロプレイと、複数のプレイヤ端末１が通信接続され、各プレイヤが協力してプレイするマルチプレイとを選択可能である。
【００４６】
なお、ここでは、ソロプレイとマルチプレイとの双方を選択可能なクエストについて説明するが、ソロプレイのみが可能なクエストと、マルチプレイのみが可能なクエストとが設けられてもよい。プレイヤは、ソロプレイ選択部３４ａをタップすることで、プレイモードとしてソロプレイを選択可能であり、マルチプレイ選択部３４ｂをタップすることで、プレイモードとしてマルチプレイを選択可能である。以下では、バトルゲームの具体的な内容について説明するが、ここでは、まず、ソロプレイによるバトルゲームについて説明し、その後に、マルチプレイによるバトルゲームについて説明する。
【００４７】
（ソロプレイ）
プレイモード選択画面において、ソロプレイ選択部３４ａがタップされると、図４Ｃに示すパーティ選択画面が表示される。パーティ選択画面には、図示のように、パーティ情報が表示されるが、パーティ選択画面への遷移時には、登録されている選択中パーティに係るパーティ情報が表示される。このパーティ選択画面においては、例えば、プレイヤが左右方向にフリック操作を行うことで、ディスプレイ２６に表示されるパーティ情報を切り替えることができる。パーティ選択画面においてパーティ情報が切り替えられると、登録されている選択中パーティも変更される。つまり、プレイヤは、パーティ選択画面において、選択中パーティを変更することができる。
【００４８】
また、パーティ選択画面には、リターンボタン３６ａとスタートボタン３６ｂとが表示される。リターンボタン３６ａがタップされると、図４Ｃに示すパーティ選択画面から、図４Ｂに示すプレイモード選択画面に画面が遷移する。一方、スタートボタン３６ｂがタップされると、登録されている選択中パーティを用いたソロプレイによるバトルゲームが開始される。
【００４９】
図５Ａは、クエスト開始画面の一例を説明する図である。バトルゲームの開始時には、図５Ａに示すように、クエスト開始画面が表示される。クエスト開始画面には、開始されるクエスト（バトルゲーム）に関する情報（クエスト情報）が表示される。ここでは、クエスト情報として、クエストをクリアするためのクリア条件（プレイヤの勝利条件ともいう）、コンティニューの可否、復活可能回数が表示されている。
【００５０】
各クエストには、クリア条件が設定されており、ここでは、一例として、敵キャラクタのうち、ボスキャラを制限時間内に倒すことがクリア条件として設定されている。なお、クリア条件はクエストごとに予め設定されており、クリア条件の他の例としては、敵キャラクタを全滅させること等が挙げられる。
【００５１】
また、各クエストには、コンティニューの可否ならびにコンティニューの可能回数が設定されている。本実施形態では、ソロプレイによるバトルゲームにおいて、全ての参加キャラが継続不可能状態になったこと、すなわち、参加キャラが全滅したことを条件として、プレイヤの敗北となる。
【００５２】
なお、ここでは、参加キャラのＨＰが０になった状態を継続不可能状態とし、参加キャラのＨＰが０ではない状態を継続可能状態とする。継続可能状態の参加キャラは、プレイヤ端末１に入力される操作またはコンピュータ制御に基づいて動作するが、継続不可能状態の参加キャラは動作が不可能となる。
【００５３】
コンティニュー可能なクエストにおいては、参加キャラが全滅した場合に、所定のゲーム内通貨を消費することで、コンティニューするか否かをプレイヤが選択することができる。プレイヤがコンティニューを実行すると、全ての参加キャラが、継続不可能状態から継続可能状態に復帰し、クエスト（バトルゲーム）を継続させることができる。
【００５４】
つまり、コンティニューが可能な状態であれば、参加キャラが全滅した時点では、プレイヤの敗北が確定していない。したがって、プレイヤは、コンティニューを実行することで、敗北を回避することができる。一方で、コンティニューを実行しなかった場合や、コンティニューを実行できない場合には、参加キャラが全滅した時点でプレイヤの敗北が確定する。
【００５５】
また、各クエストには、復活の可否ならびに復活可能回数が設定されている。ここで、バトルゲームにおける「復活」とは、復活条件が成立した場合に、上記のコンティニューと同様、継続不可能状態となった参加キャラを、継続可能状態に復帰させることを言う。ソロプレイによるバトルゲームでは、参加キャラごとに復活可能回数が設定されており、参加キャラが全滅し、かつ、復活可能回数が１以上の参加キャラがいる場合に、復活条件が成立したと判定される。
【００５６】
つまり、復活可能なクエストにおいては、参加キャラが全滅したとしても、復活可能回数が１以上の参加キャラがいれば、プレイヤの敗北が回避される。一方で、参加キャラが全滅した際に、復活可能回数が１以上の参加キャラが存在せず、かつ、コンティニューを実行しない、あるいは、コンティニューを実行できない場合に、その時点で、プレイヤの敗北が確定する。
【００５７】
ただし、本実施形態においては、コンティニューおよび復活が以下の点で相違する。すなわち、コンティニューは、その実行可否をプレイヤが選択可能であるが、復活は、復活条件が成立した際に、強制的に実行される。また、コンティニューは、ゲーム内通貨を消費するが、復活は、ゲーム内通貨を消費することがない。さらに、コンティニューと復活とでは、継続可能状態に復帰した際に設定される参加キャラのパラメータが異なる。例えば、継続可能状態に復帰した際、コンティニューでは、参加キャラのＨＰが最大値に設定されるが、復活では、参加キャラのＨＰが、最大値に対して所定の割合（例えば３０％）に設定される。このように、復活は、コンティニューに比べて、プレイヤにとって不利な条件が設定されている。ただし、復活とコンティニューとで、設定される条件が同じであってもよい。
【００５８】
本実施形態では、コンティニューおよび復活の双方が可能なクエスト、コンティニューおよび復活の双方が不可能なクエスト、コンティニューおよび復活のいずれか一方のみが可能なクエストが設けられるが、以下では、復活のみが可能なクエストについて詳述する。
【００５９】
図５Ｂは、ソロプレイによるバトルゲーム中のバトルゲーム画面の一例を説明する図である。図５Ｃは、スキルゲージ４８ａ、４８ｂ、４８ｃおよび竜化ゲージ５０の一例を説明する図である。図５Ｄは、竜化を説明する図である。バトルゲームが開始され、図５Ａに示すクエスト開始画面が所定時間表示されると、図５Ｂに示すようにバトルゲーム画面が表示される。バトルゲーム画面においては、仮想のゲームフィールドが表示されるとともに、このゲームフィールド内に、参加キャラである第１参加キャラ４０ａ、第２参加キャラ４０ｂ、第３参加キャラ４０ｃおよび第４参加キャラ４０ｄと、ボスキャラ４２とが表示される。なお、第１参加キャラ４０ａから第４参加キャラ４０ｄは、それぞれ第１パーティ編成キャラから第４パーティ編成キャラである。したがって、第１参加キャラ４０ａは、リーダーに登録されている参加キャラである。
【００６０】
バトルゲームにおいては、４体の参加キャラのうちのいずれか１体が、プレイヤが操作可能な操作対象キャラに設定される。つまり、操作対象キャラというのは、プレイヤ端末１に対する操作入力に基づいて動作する参加キャラである。バトルゲームの開始時には、リーダーに登録されている参加キャラ、すなわち、第１参加キャラ４０ａが、操作対象キャラに設定されている。
【００６１】
プレイヤは、バトルゲーム画面のうち、ゲームフィールドが表示されている領域をタップすることで、操作対象キャラに攻撃動作を行わせたり、スライド操作やフリック操作を行うことで、操作対象キャラを操作方向に移動させたりすることができる。一方で、操作対象キャラ以外の３体の参加キャラは、コンピュータ制御に基づいて動作する。以下では、コンピュータ制御に基づいて動作する参加キャラを、未操作キャラと呼ぶ。
【００６２】
プレイヤは、バトルゲーム中、操作対象キャラを変更することができる。具体的には、バトルゲーム画面には、キャラ情報表示部として、第１キャラ情報表示部４４ａ、第２キャラ情報表示部４４ｂ、第３キャラ情報表示部４４ｃ、第４キャラ情報表示部４４ｄが表示される。第１キャラ情報表示部４４ａから第４キャラ情報表示部４４ｄは、それぞれ第１参加キャラ４０ａから第４参加キャラ４０ｄに対応しており、対応する参加キャラの情報を表示している。
【００６３】
プレイヤは、キャラ情報表示部をタップすることで、操作対象キャラを切り替えることができる。例えば、第１参加キャラ４０ａが操作対象キャラに設定されている状態で、第４キャラ情報表示部４４ｄがタップされると、第４参加キャラ４０ｄが操作対象キャラに設定され、第１参加キャラ４０ａが未操作キャラに設定される。これにより、プレイヤは、プレイヤ端末１への操作入力によって、第４参加キャラ４０ｄを動作させることができる。
【００６４】
なお、各キャラ情報表示部には、対応する参加キャラを識別できるように、キャラクタ画像が表示されており、また、対応する参加キャラのＨＰを示すＨＰメータ４４ｘが表示されている。さらに、各キャラ情報表示部には、対応する参加キャラの復活可能回数を示す復活情報４４ｙが表示されている。ここでは、復活情報４４ｙとして、復活可能回数と同数のハートマークが表示されている。ただし、復活情報４４ｙは、復活可能回数を識別可能であれば、その表示態様は限定されない。したがって、例えば、復活情報４４ｙとして、復活可能回数を数値で表してもよい。
【００６５】
また、バトルゲーム画面の左下部には、キャラ情報表示部とは別に、操作対象キャラ表示部４６が表示される。操作対象キャラ表示部４６は、現在、操作対象キャラに設定されている参加キャラ、および、操作対象キャラのＨＰを報知するものである。
【００６６】
さらに、バトルゲーム画面には、３つのスキルゲージ４８ａ、４８ｂ、４８ｃが表示される。上記したように、キャラクタや装備品には、使用可能なスキルが予め設定されている。スキルゲージ４８ａ、４８ｂ、４８ｃは、操作対象キャラが使用可能なスキルの内容と、スキルの使用可否ならびにスキルを使用可能になるまでの残りのゲージ値とを報知する。
【００６７】
具体的には、各スキルには、使用可能になるための必要ゲージ値が予め設定されている。スキルゲージ４８ａ、４８ｂ、４８ｃのゲージ値は、例えば、操作対象キャラがボスキャラ４２等に与えた与ダメージ値に応じて増加する。ゲージ値が必要ゲージ値未満の状態では、当該スキルを使用することができず、ゲージ値が必要ゲージ値以上になると、当該スキルを使用可能となる。ゲージ値は、スキルごとに管理されており、スキルが使用不可能な状態では、図５Ｂに示すように、スキルゲージ４８ａ、４８ｂ、４８ｃの一部または全部がグレーアウトしている。そして、ゲージ値が増加し、必要ゲージ値に近づくにつれて、図５Ｃに示すように、グレーアウトした面積が小さくなっていく。
【００６８】
図５Ｃには、スキルゲージ４８ａに対応するスキルが使用可能であり、スキルゲージ４８ｂ、４８ｃに対応するスキルは使用不可能な状態を示している。図５Ｃに示す状態において、プレイヤは、スキルゲージ４８ａをタップすることで、スキルゲージ４８ａに対応するスキルを使用することができる。スキルが使用されると、当該スキルに対するゲージ値が０となり、当該スキルが使用不可能となる。このように、スキルゲージ４８ａ、４８ｂ、４８ｃは、スキルを使用するための操作部としても機能する。
【００６９】
また、バトルゲーム画面には、竜化ゲージ５０が表示される。上記したように、各参加キャラには、ドラゴンを装備することができる。竜化ゲージ５０は、操作対象キャラが装備しているドラゴンと、当該ドラゴンへの変身可否ならびにドラゴンに変身可能になるまでの残りのゲージ値とを報知する。
【００７０】
具体的には、各ドラゴンまたは各参加キャラには、ドラゴンに変身可能になるための必要ゲージ値が予め設定されている。竜化ゲージ５０のゲージ値は、例えば、操作対象キャラがボスキャラ４２等に与えた与ダメージ値に応じて増加する。ゲージ値が必要ゲージ値未満の状態では、ドラゴンに変身することができず、ゲージ値が必要ゲージ値以上になると、ドラゴンに変身可能となる。ドラゴンの変身に必要となるゲージ値は、上記の各スキルとは別に管理されており、ドラゴンに変身不可能な状態では、図５Ｂに示すように、竜化ゲージ５０の一部または全部がグレーアウトしている。そして、ゲージ値が増加し、必要ゲージ値に近づくにつれて、グレーアウトした面積が小さくなっていく。
【００７１】
図５Ｃには、操作対象キャラが装備するドラゴンに変身可能な状態を示している。図５Ｃに示す状態において、プレイヤは、竜化ゲージ５０をタップすることで、操作対象キャラをドラゴンに変身させることができる。例えば、図５Ｃに示す状態で竜化ゲージ５０がタップされると、図５Ｄに示すように、操作対象キャラ（ここでは第１参加キャラ４０ａ）がドラゴンに変身する。この状態では、操作対象キャラ表示部４６および操作対象キャラに対応するキャラ情報表示部（ここでは第１キャラ情報表示部４４ａ）にドラゴンが表示され、プレイヤ端末１への操作入力により、ドラゴンを動作させることができる。
【００７２】
ドラゴンに変身すると、ドラゴンに対するゲージ値が０となり、再度、ドラゴンへの変身が不可能となる。ドラゴンに変身している間は、竜化ゲージ５０が図５Ｄに示すように表示される。ドラゴンに変身可能な時間（変身可能時間）は予め設定されており、変身可能時間が経過すると、図５Ｂに示すように、ドラゴンから元の参加キャラ（ここでは第１参加キャラ４０ａ）に戻り、竜化ゲージ５０がグレーアウトして表示される。
【００７３】
なお、詳しい説明は省略するが、未操作キャラについても、ドラゴンに対するゲージ値と、各スキルに対するゲージ値とが管理されている。ただし、未操作キャラについては、コンピュータ制御によりスキルが使用されることはあるが、ドラゴンに変身することはない。
【００７４】
また、バトルゲーム画面の上部には、ボスキャラ４２のＨＰを示すボスキャラＨＰメータ４２ｘと、制限時間、すなわち、バトルゲーム終了までの残り時間とが表示される。各バトルゲームには、クリア条件（勝利条件）および敗北条件（クリア条件の未達成）が予め設定されており、バトルゲームにおいて勝利条件が成立するとプレイヤの勝利となり、敗北条件が成立するとプレイヤの敗北となってバトルゲームが終了する。ここでは、ボスキャラ４２のＨＰが０になることが勝利条件として設定されており、ボスキャラ４２のＨＰが０になると、プレイヤの勝利となる。一方、本実施形態では、参加キャラが全滅し、かつ、全ての参加キャラの復活可能回数が０となることが敗北条件として設定されている。以下では、継続不可能状態の参加キャラを、継続可能状態に復帰させる復活処理について説明する。
【００７５】
図６Ａは、ソロプレイにおける復活処理を説明する第１の図である。図６Ｂは、ソロプレイにおける復活処理を説明する第２の図である。図６Ｃは、ソロプレイにおける復活処理を説明する第３の図である。図６Ｄは、ソロプレイにおける復活処理を説明する第４の図である。例えば、４体の参加キャラのそれぞれに２回の復活可能回数が設定されたバトルゲームにおいて、第１参加キャラ４０ａが操作対象キャラに設定されているとする。
【００７６】
この状態で、図６Ａに示すように、操作対象キャラである第１参加キャラ４０ａのＨＰが０になり、継続不可能状態になったとする。このように、操作対象キャラが継続不可能状態となったときに、継続可能状態の未操作キャラが存在している場合には、いずれかの未操作キャラが操作対象キャラに設定される。図６Ｂに示す例では、第１参加キャラ４０ａが継続不可能状態になったときに、第２参加キャラ４０ｂが操作対象キャラに設定されている。操作対象キャラの変更に伴い、操作対象キャラ表示部４６、スキルゲージ４８ａ、４８ｂ、４８ｃ、および、竜化ゲージ５０が、第２参加キャラ４０ｂに対応する表示態様に変更される。
【００７７】
その後、４体の参加キャラが全滅すると、復活条件の成立となり、図６Ｃに示すように、ディスプレイ２６の中央に「５」と表示され、参加キャラが復活するまでのカウントダウンが開始される。ここでは、復活条件の成立から、復活処理が行われるまでの時間である復活待機時間が５秒に設定されている。この復活待機時間中は、全ての参加キャラが継続不可能状態に維持される。そして、図６Ｄに示すように、復活待機時間が経過して、ディスプレイ２６の中央に「０」と表示されると、復活可能回数が１以上の参加キャラについて復活処理が行われる。
【００７８】
図７Ａは、復活時のバトルゲーム画面の一例を説明する図である。図７Ｂは、プレイヤの勝利時のバトルゲーム画面の一例を説明する図である。図７Ｃは、報酬画面の一例を説明する図である。復活処理が行われると、継続不可能状態の参加キャラが復活する復活アニメーションが表示される。また、このとき、図７Ａに示すように、復活した参加キャラのＨＰが所定値（ここでは各参加キャラの最大ＨＰの３０％）に設定される。さらに、各キャラ情報表示部においては、復活情報４４ｙにより、復活可能回数が１つ減少したことが報知される。
【００７９】
なお、図７Ａに示すように、復活処理では、各スキルに対応するゲージ値は０に設定されるが、ドラゴンに対応するゲージ値は、継続不可能状態になったときの値に設定される。ただし、復活処理で設定されるゲージ値はこれに限らず、例えば、一部または全部のゲージ値を、０または最大値に設定してもよいし、継続不可能状態になったときの値に設定してもよい。
【００８０】
また、復活処理が行われると、リーダーとして登録されている参加キャラが操作対象キャラに設定される。そして、復活アニメーションが終了すると、プレイヤ端末１に対する操作入力またはコンピュータ制御に基づいて、各参加キャラが動作可能となる。ここでは、復活処理において、復活した参加キャラに対して無敵時間が設定される。復活処理が行われてから無敵時間が経過するまでの間、復活した参加キャラはダメージを受けなくなる。
【００８１】
そして、ボスキャラ４２のＨＰが０になると、図７Ｂに示すように、プレイヤの勝利を報知する画像が表示され、バトルゲームが終了となる。その後、図７Ｃに示すように、報酬画面が表示され、クエストの成功、すなわち、バトルゲームの勝利によって獲得した報酬が報知される。プレイヤが獲得可能な報酬は、クエストごとに異なり、また、コンティニュー回数や復活回数によっても異なる。
【００８２】
図８Ａは、基礎報酬抽選テーブルの一例を説明する図である。図８Ｂは、復活回数報酬抽選テーブルの一例を説明する図である。ソロプレイによってクエストに成功（クリア条件の達成）すると、クエスト終了情報がサーバ１００に送信される。クエスト終了情報には、成功したクエストの種別、および、プレイヤが実行した復活回数を識別する情報が含まれる。サーバ１００では、クエスト終了情報を受信すると、プレイヤに付与する報酬が抽選により決定される。
【００８３】
具体的には、サーバ１００には、図８Ａに示す基礎報酬抽選テーブル、および、図８Ｂに示す復活回数報酬抽選テーブルが設けられている。基礎報酬抽選テーブルによれば、プレイヤに付与する報酬の選択比率がクエストごとに設定されている。また、復活回数報酬抽選テーブルは、クエストごとに設けられている。各復活回数報酬抽選テーブルによれば、プレイヤに付与する報酬の選択比率が復活回数ごとに設定されている。ここでは、復活回数、すなわち、復活処理を実行した回数が少ないほど、希少価値の高い報酬が獲得できるように選択比率が設定されている。
【００８４】
サーバ１００においては、クエスト終了情報を受信すると、基礎報酬抽選テーブルを用いた基礎報酬抽選、および、復活回数報酬抽選テーブルを用いた復活回数報酬抽選がそれぞれ実行される。つまり、プレイヤは、クエストに成功すると、復活回数に拘わらず、共通の報酬として基礎報酬を獲得することができ、かつ、復活回数に応じた報酬である復活回数報酬を追加的に獲得することができる。
【００８５】
なお、プレイヤに付与される報酬の決定方法は一例に過ぎない。例えば、復活回数報酬は必須ではなく、復活回数に拘わらず、共通の基礎報酬のみが決定されてもよいし、復活回数に応じて、基礎報酬の抽選回数を異ならせてもよい。例えば、復活回数が少ないほど、基礎報酬の抽選回数が多くなってもよい。また、例えば、復活回数報酬は、抽選により決定されるものではなく、予め設定された所定の復活回数報酬が、復活回数に応じて付与されてもよい。
【００８６】
（マルチプレイ）
次に、マルチプレイによるバトルゲームについて説明する。図９Ａは、ルーム選択画面の一例を説明する図である。図９Ｂは、ルーム待機画面の一例を説明する図である。図９Ｃは、プレイヤと未操作キャラとの対応関係を説明する第１の図である。図９Ｄは、プレイヤと未操作キャラとの対応関係を説明する第２の図である。図４Ｂに示すプレイモード選択画面において、マルチプレイ選択部３４ｂがタップされると、図９Ａに示すルーム選択画面が表示される。ルーム選択画面には、ルーム作成ボタン５２ａと、ルーム検索ボタン５２ｂとが表示される。
【００８７】
プレイヤは、ルーム作成ボタン５２ａをタップすることで、自らルームを作成することができ、ルーム検索ボタン５２ｂをタップすることで、他のプレイヤが作成したルームを検索し、ルームが見つかった場合に、そのルームに入室することができる。なお、本実施形態において、ルームとは、バトルゲームが行われる仮想空間と、バトルゲームサーバ１００Ｂにおいてバトルゲームを管理するための処理領域との両方を示す。
【００８８】
ルーム作成ボタン５２ａがタップされると、バトルゲームサーバ１００Ｂにおいてルームが作成される。ルームが作成されると、バトルゲームサーバ１００Ｂにおいて、ルームを作成したプレイヤ（以下、ホストプレイヤという）に係る情報が、入室者情報として、当該ルームに対応して登録される。なお、詳しい説明は省略するが、ホストプレイヤは、入室可能なプレイヤの条件である入室条件を設定してルームを作成することもできるし、入室条件を設定せずにルームを作成することもできる。入室条件としては、例えば、パーティの戦闘力等が挙げられる。入室条件が設定された場合には、入室条件を満たすプレイヤのみがルームに入室可能であり、入室条件が設定されない場合には、ルームの検索開始が早いプレイヤから順に、ルームが割り当てられる。
【００８９】
ここでは、ルーム作成ボタン５２ａがタップされたときに、ホストプレイヤのプレイヤ端末１（以下、ホスト端末という）において設定されている選択中パーティに係るパーティ情報がバトルゲームサーバ１００Ｂに送信される。バトルゲームサーバ１００Ｂでは、ホスト端末から受信したパーティ情報が、ホストプレイヤおよびホスト端末と対応付けて、入室者情報として登録される。また、バトルゲームサーバ１００Ｂにおいては、ホスト端末から受信したパーティ情報のうち、リーダーに設定されているパーティ編成キャラを、参加キャラおよび操作対象キャラ（第１操作対象キャラ）として、ホストプレイヤ（ホスト端末）と対応付けて登録する。
【００９０】
ホスト端末には、図９Ｂに示すルーム待機画面が表示される。ルーム待機画面には、第１プレイヤ情報表示部５４ａ、第２プレイヤ情報表示部５４ｂ、第３プレイヤ情報表示部５４ｃおよび第４プレイヤ情報表示部５４ｄが表示される。第１プレイヤ情報表示部５４ａには、ホストプレイヤの操作対象キャラ（第１操作対象キャラ）に係る情報が表示される。なお、第２プレイヤ情報表示部５４ｂ、第３プレイヤ情報表示部５４ｃおよび第４プレイヤ情報表示部５４ｄには、「ｗａｉｔｉｎｇ」と表示され、他のプレイヤの入室待機中であることが報知される。
【００９１】
なお、ホスト端末に表示されるルーム待機画面には、解散ボタン５４ｅと開始ボタン５４ｆとが設けられる。ホストプレイヤにより解散ボタン５４ｅがタップされると、ルームが消滅し、開始ボタン５４ｆがタップされると、バトルゲームが開始される。ただし、ホストプレイヤ以外のプレイヤがルームに入室していない場合には、バトルゲームを開始することができず、開始ボタン５４ｆが無効化されている。開始ボタン５４ｆが無効化されている状態では、図９Ｂに示すように、開始ボタン５４ｆがグレーアウトしている。
【００９２】
一方、他のプレイヤのプレイヤ端末１において、図９Ａに示すルーム選択画面でルーム検索ボタン５２ｂがタップされ、ルームが見つかったとする。この場合、ルーム検索ボタン５２ｂをタップしたプレイヤ（以下、ゲストプレイヤという）がルームに入室することとなる。すなわち、ルーム検索ボタン５２ｂがタップされたときに、ゲストプレイヤのプレイヤ端末１（以下、ゲスト端末という）において設定されている選択中パーティに係るパーティ情報がバトルゲームサーバ１００Ｂに送信される。
【００９３】
バトルゲームサーバ１００Ｂでは、ゲスト端末から受信したパーティ情報が、ゲストプレイヤおよびゲスト端末と対応付けて、入室者情報として登録される。また、バトルゲームサーバ１００Ｂにおいては、ゲスト端末から受信したパーティ情報のうち、リーダーに設定されているパーティ編成キャラを、参加キャラおよび操作対象キャラ（ここでは第２操作対象キャラ）として、ゲストプレイヤ（ゲスト端末）と対応付けて登録する。
【００９４】
例えば、図９Ｂに示す状態において、１人のゲストプレイヤ（第１ゲストプレイヤ）がルームに入室したとする。この場合、図９Ｃに示すように、ホスト端末のルーム待機画面において、第１ゲストプレイヤの操作対象キャラ（第２操作対象キャラ）に係る情報が第２プレイヤ情報表示部５４ｂに表示される。
【００９５】
ここで、マルチプレイによるバトルゲームには、参加キャラの登録数の上限である定員数（ここでは４）が設けられている。ゲストプレイヤが１人以上入室している場合、バトルゲームサーバ１００Ｂにおいて、操作対象キャラの登録数と定員数との差分だけ、未操作キャラが参加キャラとして登録される。したがって、例えば、ホストプレイヤと、１人のゲストプレイヤとが入室した状態では、２体の未操作キャラが登録される。
【００９６】
ここでは、図９Ｃに示すように、ホストプレイヤのパーティ情報に基づいて、一体のパーティ編成キャラが、参加キャラおよび未操作キャラ（第１未操作キャラ）として登録され、第１ゲストプレイヤのパーティ情報に基づいて、一体のパーティ編成キャラが、参加キャラおよび未操作キャラ（第２未操作キャラ）として登録される。このとき、第１未操作キャラは、ホストプレイヤに対応付けられ、第２未操作キャラは、第１ゲストプレイヤに対応付けられている。
【００９７】
このとき、図９Ｃに示すように、ルーム待機画面において、第３プレイヤ情報表示部５４ｃに、第１未操作キャラに係る情報が表示され、第４プレイヤ情報表示部５４ｄに、第２未操作キャラに係る情報が表示される。また、この状態では、開始ボタン５４ｆが有効化され、ホストプレイヤは、バトルゲームを開始することができる。
【００９８】
また、この状態においても、さらに他のゲストプレイヤの入室が可能となっている。したがって、例えば、他のゲストプレイヤ（第２ゲストプレイヤ）がルームに入室すると、図９Ｄに示すように、第２ゲストプレイヤの操作対象キャラ（第３操作対象キャラ）に係る情報が第３プレイヤ情報表示部５４ｃに表示される。
【００９９】
また、この状態では、操作対象キャラの登録数と定員数との差分が１となる。この場合、ホストプレイヤのパーティ情報に基づいて、一体のパーティ編成キャラが、参加キャラおよび未操作キャラ（第１未操作キャラ）として登録される。したがって、図９Ｄに示すように、ルーム待機画面において、第４プレイヤ情報表示部５４ｄに、第１未操作キャラに係る情報が表示されることとなる。
【０１００】
本実施形態では、ホストプレイヤおよび第１ゲストプレイヤの２人のプレイヤが入室している場合、ホストプレイヤの第１パーティ編成キャラが第１操作対象キャラとして登録され、ホストプレイヤの第２パーティ編成キャラが第１未操作キャラとして登録される。そして、第１ゲストプレイヤの第１パーティ編成キャラが第２操作対象キャラとして登録され、第１ゲストプレイヤの第２パーティ編成キャラが第２未操作キャラとして登録される。
【０１０１】
また、ホストプレイヤ、第１ゲストプレイヤおよび第２ゲストプレイヤの３人のプレイヤが入室している場合、ホストプレイヤの第１パーティ編成キャラが第１操作対象キャラとして登録され、ホストプレイヤの第２パーティ編成キャラが第１未操作キャラとして登録される。そして、第１ゲストプレイヤの第１パーティ編成キャラが第２操作対象キャラとして登録され、第２ゲストプレイヤの第１パーティ編成キャラが第３操作対象キャラとして登録される。
【０１０２】
さらに、ホストプレイヤ、第１ゲストプレイヤ、第２ゲストプレイヤおよび第３ゲストプレイヤの４人のプレイヤが入室している場合、ホストプレイヤの第１パーティ編成キャラが第１操作対象キャラとして登録され、第１ゲストプレイヤの第１パーティ編成キャラが第２操作対象キャラとして登録され、第２ゲストプレイヤの第１パーティ編成キャラが第３操作対象キャラとして登録され、第３ゲストプレイヤの第１パーティ編成キャラが第４操作対象キャラとして登録される。
【０１０３】
図１０Ａは、ルームの満室状態を説明する図である。図１０Ｂは、準備完了状態を説明する図である。図１０Ａに示すように、ルームに４人のプレイヤが入室すると、ルームが満室状態となり、さらなるプレイヤの入室が不可能となる。図示は省略するが、ゲスト端末で表示されるルーム待機画面は、解散ボタン５４ｅおよび開始ボタン５４ｆの代わりに、退室ボタンおよび準備完了ボタンが表示される。
【０１０４】
ゲスト端末において、退室ボタンがタップされると、バトルゲームサーバ１００Ｂに登録された当該ゲストプレイヤに係る情報が削除される。これにより、退室ボタンをタップしたゲストプレイヤは、ルームから退室することとなる。したがって、例えば満室状態のルームからゲストプレイヤが退室すると、再度、当該ルームに対してゲストプレイヤが入室可能となる。
【０１０５】
また、ルーム待機画面では、所定の操作を行うことで、参加キャラ（操作対象キャラおよび未操作キャラ）を変更することができる。プレイヤ端末１において、参加キャラを変更する操作が行われると、変更後のパーティ情報等がバトルゲームサーバ１００Ｂに送信され、新たな参加キャラ、操作対象キャラ、未操作キャラが登録されることとなる。この場合、他のプレイヤのプレイヤ端末１には、変更後の参加キャラに係る情報が表示される。
【０１０６】
そして、ゲスト端末において、準備完了ボタンがタップされると、ルームに接続されている全てのプレイヤ端末１に対して準備完了情報が送信される。準備完了情報を受信したプレイヤ端末１では、準備完了ボタンがタップされたゲスト端末に対応するプレイヤ情報表示部に、図１０Ｂに示すように、「ＯＫ」と記された準備完了表示が重畳される。なお、第１プレイヤ情報表示部５４ａには、ルーム作成時から準備完了表示がなされている。このように、準備完了表示により、参加キャラを変更する意思がないことを他のプレイヤに伝達することができる。
【０１０７】
次に、マルチプレイによるバトルゲームについて説明する。なお、バトルゲームの基本的な内容は、マルチプレイとソロプレイとで同じである。したがって、ここでは、マルチプレイとソロプレイとの相違点について説明する。以下では、まず、４人のプレイヤによるマルチプレイ（以下、４人プレイという）について説明し、その後、３人のプレイヤによるマルチプレイ（以下、３人プレイという）について説明する。
【０１０８】
図１１Ａは、４人プレイにおける復活処理を説明する第１の図である。図１１Ｂは、４人プレイにおける復活処理を説明する第２の図である。図１１Ｃは、４人プレイにおける復活処理を説明する第３の図である。図１１Ｄは、４人プレイにおける復活処理を説明する第４の図である。４人プレイにおいては、第１参加キャラ４０ａがホストプレイヤの操作対象キャラ（第１操作対象キャラ）に設定され、第２参加キャラ４０ｂが第１ゲストプレイヤの操作対象キャラ（第２操作対象キャラ）に設定され、第３参加キャラ４０ｃが第２ゲストプレイヤの操作対象キャラ（第３操作対象キャラ）に設定され、第４参加キャラ４０ｄが第３ゲストプレイヤの操作対象キャラ（第４操作対象キャラ）に設定される。
【０１０９】
例えば、図１１Ａに示すように、第１参加キャラ４０ａのＨＰが０になり、第１参加キャラ４０ａが継続不可能状態になったとする。この場合、ホスト端末のバトルゲーム画面には、図１１Ｂおよび図１１Ｃに示すように、上記したソロプレイと同様にカウントダウンが表示される。そして、復活待機時間が経過すると、図１１Ｄに示すように、第１参加キャラ４０ａに対して復活処理が行われ、第１参加キャラ４０ａが継続可能状態に復帰する。
【０１１０】
なお、図示は省略するが、復活処理が行われるプレイヤ端末１では、上記のようにカウントダウンが実行されるが、この間、他のプレイヤ端末１では、復活処理の待機中であることが識別可能な表示がなされる。このとき、ゲームの妨げとならないように、例えばキャラ情報表示部等において、カウントダウンがなされるとよい。
【０１１１】
上記したように、ソロプレイにおいては、参加キャラごとに復活可能回数が設定されている。また、ソロプレイにおいては、全ての参加キャラが１のプレイヤに対応しており、参加キャラが全滅するまで、復活処理が行われない。一方で、マルチプレイにおいては、参加プレイヤごとに復活可能回数が設定されている。特に４人プレイにおいては、１のプレイヤに１の参加キャラが対応しており、プレイヤに対応する操作対象キャラが継続不可能状態になったところで、復活処理が行われる。
【０１１２】
図１２Ａは、３人プレイにおける復活処理を説明する第１の図である。図１２Ｂは、３人プレイにおける復活処理を説明する第２の図である。図１２は、３人プレイにおける復活処理を説明する第３の図である。図１２は、３人プレイにおける復活処理を説明する第４の図である。上記したように、３人プレイにおいては、ホストプレイヤの第１操作対象キャラおよび第１未操作キャラと、第１ゲストプレイヤの第２操作対象キャラと、第２ゲストプレイヤの第３操作対象キャラとが、それぞれ参加キャラとして登録される。このとき、第１操作対象キャラが第１参加キャラ４０ａに設定され、第１未操作キャラが第２参加キャラ４０ｂに設定され、第２操作対象キャラが第３参加キャラ４０ｃに設定され、第３操作対象キャラが第４参加キャラ４０ｄに設定される。つまり、３人プレイにおいては、ホストプレイヤに、１体の操作対象キャラと、１体の未操作キャラとが対応して登録されている。
【０１１３】
例えば、図１２Ａに示すように、第１操作対象キャラである第１参加キャラ４０ａのＨＰが０になり、第１参加キャラ４０ａが継続不可能状態になったとする。この場合、ソロプレイと同様に、ホストプレイヤの操作対象キャラが、第１未操作キャラである第２参加キャラ４０ｂに変更される。このように、定員数（４人）よりも少ないプレイヤでバトルゲームを開始した場合には、バトルゲームの開始時から、いずれかのプレイヤに未操作対象キャラが設定される。未操作対象キャラが設定されたプレイヤは、ソロプレイと同様に、自身に対応している参加キャラの中で、操作対象キャラを変更することができる。また、操作対象キャラが継続不可能状態となった場合には、操作対象キャラが自動的に変更される。
【０１１４】
したがって、図１２Ａに示すように、第１参加キャラ４０ａが継続不可能状態になると、図１２Ｂに示すように、第２参加キャラ４０ｂがホストプレイヤの操作対象キャラに設定される。その後、第２参加キャラ４０ｂが継続不可能状態になると、復活条件が成立し、ホスト端末のバトルゲーム画面において、図１２Ｃに示すようにカウントダウンが表示される。そして、復活待機時間が経過すると、図１２Ｄに示すように、第１参加キャラ４０ａおよび第２参加キャラ４０ｂに対して復活処理が行われ、第１参加キャラ４０ａおよび第２参加キャラ４０ｂが継続可能状態に復帰する。
【０１１５】
上記したように、定員数未満のプレイヤで開始されたマルチプレイにおいては、１のプレイヤに、複数の参加キャラが対応し得る。そして、マルチプレイにおいても、複数の参加キャラが対応しているプレイヤについては、対応する参加キャラが全滅するまで、復活処理が行われない。
【０１１６】
また、上記したように、ソロプレイにおいては、参加キャラごとに復活可能回数が設定されるのに対して、マルチプレイにおいては、プレイヤごとに復活可能回数が設定される。ここでは、全てのプレイヤに同数（２回）の復活可能回数が設定されている。したがって、１体の参加キャラのみが対応している第１ゲストプレイヤおよび第２ゲストプレイヤは、２回の復活可能回数が１体の参加キャラに設定されることになる。一方で、２体の参加キャラが対応しているホストプレイヤは、２回の復活可能回数が２体の参加キャラに割り振られて設定される。その結果、ホストプレイヤに対応する第１参加キャラ４０ａおよび第２参加キャラ４０ｂには、それぞれ１回の復活可能回数が設定されることになる。
【０１１７】
図１３Ａは、クエストごとの復活可能回数を説明する図である。図１３Ｂは、マルチプレイに参加するプレイヤ数と、各プレイヤの復活可能回数とを説明する図である。図１３Ａに示すように、各クエストには、ソロプレイにおいて各参加キャラに設定される復活可能回数と、マルチプレイにおいて各プレイヤに設定される復活可能回数とが予め設定されている。バトルゲームの開始時には、バトルゲームサーバ１００Ｂにおいて、開始されるクエストの種別、プレイモード、参加人数に基づいて、復活可能回数がセットされる。プレイヤ端末１は、バトルゲームサーバ１００Ｂから復活可能回数を受信し、参加キャラに対応付けて記憶する。
【０１１８】
ここでは、全ての参加キャラまたはプレイヤに同数の復活可能回数が設定されるが、参加キャラまたはプレイヤによって、異なる復活可能回数が設定されてもよい。例えば、参加キャラのステータス（キャラレベルやランク）や、プレイヤのステータス（プレイヤレベルや、当該クエストのクリア経験の有無等）に応じて、異なる復活可能回数が設定されてもよい。
【０１１９】
また、マルチプレイにおいては、参加するプレイヤ数に応じて、図１３Ｂに示すように、各参加キャラがプレイヤに対応付けられる。具体的には、参加人数が４人の４人プレイでは、４人のプレイヤそれぞれに、１体の参加キャラが対応付けられる。したがって、例えば、各プレイヤに設定される復活可能回数が２回のクエストでは、各参加キャラの復活可能回数が２回となる。
【０１２０】
また、参加人数が３人の３人プレイでは、ホストプレイヤに２体の参加キャラが対応付けられ、他の２人のゲストプレイヤに、それぞれ１体の参加キャラが対応付けられる。上記したように、マルチプレイでは、プレイヤの参加人数に拘わらず、各プレイヤに復活可能回数が設定される。したがって、各プレイヤに設定される復活可能回数が２回のクエストでは、ホストプレイヤに２回の復活可能回数が設定される。その結果、ホストプレイヤに設定される２回の復活可能回数は、ホストプレイヤに対応する２体の参加キャラに、それぞれ１回ずつ割り振られる。
【０１２１】
また、参加人数が２人の２人プレイでは、ホストプレイヤおよび１人のゲストプレイヤに、それぞれ２体の参加キャラが対応付けられる。したがって、各プレイヤに設定される復活可能回数が２回のクエストでは、ホストプレイヤおよびゲストプレイヤに、それぞれ２回の復活可能回数が設定される。その結果、４体の参加キャラには、それぞれ１回の復活可能回数が割り振られることとなる。
【０１２２】
このように、定員数未満のプレイヤでバトルゲームを開始すると、定員数のプレイヤでバトルゲームを開始する場合に比べて不利な状態となる。これにより、定員数未満のプレイヤでバトルゲームを開始することが可能である一方で、参加するプレイヤが定員数に達するまでバトルゲームの開始を待つ可能性を高めることができる。その結果、プレイヤの参加率が向上し、マルチプレイの興趣をプレイヤに付与することができる。
【０１２３】
なお、ここでは、マルチプレイにおいて各プレイヤに設定される復活可能回数が、自動的に参加キャラに割り振られることとした。ただし、復活させる参加キャラをプレイヤが選択可能であってもよい。
【０１２４】
また、詳しい説明は省略するが、マルチプレイは、複数のプレイヤ端末１が通信接続されることで実現する。複数のプレイヤ端末１は同期させる必要があるため、所定時間に亘って通信が切断されたプレイヤは、マルチプレイを続行することができない。この場合、通信が切断されたプレイヤは、マルチプレイから切り離され、ソロプレイに切り替わる。このとき、ソロプレイに切り替わったプレイヤ端末１には、各参加キャラの情報や、ボスキャラの情報が記憶されており、他のプレイヤに対応していた参加キャラは、以後、コンピュータ制御により動作する。
【０１２５】
つまり、通信切断により、マルチプレイからソロプレイに切り替わった場合には、他のプレイヤに対応していた参加キャラが、通信切断したプレイヤ端末１のプレイヤに対応付けられる。ただし、この場合には、他のプレイヤに対応付けられていた参加キャラの復活処理が制限される。すなわち、通信切断した場合には、複数の参加キャラがプレイヤに対応していたとしても、通信切断後に対応付けられた参加キャラについては、復活処理を行うことができない。換言すれば、プレイヤは、バトルゲームの開始時に対応していた参加キャラに限りに、復活処理を実行させることができる。
【０１２６】
一方、上記のように、通信切断によりプレイヤが離脱したとしても、通信が確立しているプレイヤ間ではマルチプレイが継続される。この場合、離脱したプレイヤに対応していた参加キャラは、マルチプレイを継続している他のいずれかのプレイヤに対応付けられる。例えば、４人プレイで開始されたバトルゲームから、１人のプレイヤが通信切断により離脱したとする。この場合、離脱したプレイヤに対応付けられていた参加キャラは、ホストプレイヤに対応付けられ、以後、ホストプレイヤの未操作キャラとしてコンピュータ制御される。ただし、離脱したプレイヤに対応付けられていた参加キャラは、ホストプレイヤではなく、他のゲストプレイヤに対応付けられてもよい。
【０１２７】
このように、マルチプレイを継続している場合であっても、離脱したプレイヤに対応付けられていた参加キャラについては、上記と同様に、復活処理が制限される。すなわち、複数の参加キャラがプレイヤに対応していたとしても、バトルゲームの開始後に対応付けられた参加キャラについては、復活処理を行うことができず、バトルゲームの開始時に対応していた参加キャラに限りに、復活処理を実行させることができる。
【０１２８】
例えば、４人プレイでバトルゲームを開始した後、全ての参加キャラの復活可能回数が２回残っている状態で、第３ゲストプレイヤのプレイヤ端末１が通信切断されたとする。この場合、第３ゲストプレイヤのプレイヤ端末１では、マルチプレイからソロプレイに切り替わる。このとき、第３ゲストプレイヤの操作対象キャラである第４参加キャラ４０ｄについては、２回、復活させることができるが、事後的に対応付けられた他の３体の参加キャラについては、復活させることができない。
【０１２９】
また、上記のように、第３ゲストプレイヤが離脱したとしても、ホストプレイヤ、第１ゲストプレイヤおよび第２ゲストプレイヤについては、マルチプレイが継続される。この場合、ホストプレイヤに第４参加キャラ４０ｄが対応付けられ、第４参加キャラ４０ｄがホストプレイヤの未操作キャラとして設定される。このとき、ホストプレイヤの操作対象キャラである第１参加キャラ４０ａについては、２回、復活させることができるが、事後的に対応付けられた第４参加キャラ４０ｄについては、復活させることができない。
【０１３０】
以下に、上記のバトルゲームを実行するための情報処理システムＳの機能的構成（機能部）と、各機能部が遂行する処理のうち、主に復活処理に係る処理について詳述する。
【０１３１】
（情報処理システムＳの機能的構成）
図１４は、プレイヤ端末１およびサーバ１００の機能的構成を説明する図である。プレイヤ端末１のメモリ１２には、ゲームを進行するためのプログラムが格納されている。プレイヤ端末１のＣＰＵ１０は、各プログラムを動作させることで、プレイヤ端末１を、送受信部６０、登録部６２、プレイヤ設定部６４、クエスト実行部６６（ゲーム実行部）、回数設定部６８、復活処理実行部７０、ルーム表示部７２として機能させる。
【０１３２】
また、バトルゲームサーバ１００Ｂは、各プログラムを動作させ、送受信部１６０、登録部１６２、プレイヤ設定部１６４、同期処理部１６６、回数設定部１６８、ルーム生成部１７０として機能する。また、管理サーバ１００Ａは、各プログラムを動作させ、プレイヤ情報記憶部１８０、報酬決定部１８２として機能する。
【０１３３】
なお、図１４に示す機能部は一例に過ぎず、この他にも多数の機能部が設けられる。また、各機能部は、プレイヤ端末１、管理サーバ１００Ａ、バトルゲームサーバ１００Ｂのいずれに設けられてもよい。また、同一の役割を担う機能部が、プレイヤ端末１、管理サーバ１００Ａ、バトルゲームサーバ１００Ｂに重複して設けられてもよい。
【０１３４】
送受信部６０、１６０は、プレイヤ端末１とサーバ１００との間で各種の情報を送受信する。また、送受信部１６０は、ゲームに参加する複数のプレイヤのプレイヤ端末１間で情報を送受信する。
【０１３５】
登録部６２、１６２は、プレイヤ端末１に入力される登録要求操作に基づき、プレイヤが操作可能な操作対象キャラを参加キャラとして登録し、操作対象キャラの登録数が所定数未満の場合、コンピュータ制御に基づいて動作する未操作キャラを参加キャラとして登録する。すなわち、登録部６２、１６２は、定員数と、操作対象キャラの登録数との差分だけ、未操作キャラを参加キャラとして登録する。また、登録部６２は、ソロプレイが実行される場合にも、未操作キャラを参加キャラとして登録する。
【０１３６】
プレイヤ設定部６４、１６４は、操作対象キャラと、操作対象キャラを操作可能なプレイヤとを対応させ、未操作キャラをいずれかのプレイヤに対応させる。
【０１３７】
クエスト実行部６６は、バトルゲーム中にプレイヤ端末１に入力される操作またはコンピュータ制御に基づいて、継続可能状態の参加キャラを動作させ、参加キャラが継続不可能状態であれば、参加キャラの動作を不可能とする。また、クエスト実行部６６は、敵キャラクタおよび参加キャラの被ダメージ値、ＨＰ、各種パラメータを演算、更新する等、バトルゲーム全体を進行制御する。
【０１３８】
回数設定部６８、１６８は、マルチプレイにおいて、継続不可能状態となった参加キャラを継続可能状態に復活させる復活処理の上限回数、すなわち、復活可能回数を、バトルゲームに参加するプレイヤごとに設定する。また、回数設定部６８、１６８は、ソロプレイにおいて、復活可能回数を参加キャラごとに設定する。
【０１３９】
復活処理実行部７０は、マルチプレイにおいて、バトルゲーム中に参加キャラが継続不可能状態となった場合、参加キャラに対応するプレイヤの復活可能回数の範囲内で、参加キャラの復活処理を実行可能とする。また、復活処理実行部７０は、未操作キャラが対応付けられたプレイヤについて、対応する全ての参加キャラが継続不可能状態となった場合に、全ての参加キャラの復活処理を実行する。
【０１４０】
ルーム表示部７２は、ルーム選択画面およびルーム待機画面の表示制御を行う。
【０１４１】
同期処理部１６６は、マルチプレイによるバトルゲーム中、参加する複数のプレイヤのプレイヤ端末１を同期させる処理を行う。
【０１４２】
ルーム生成部１７０は、ルームの作成、ルームの検索、マッチング、ルームへのプレイヤの入室等に係る処理を行う。
【０１４３】
プレイヤ情報記憶部１８０は、プレイヤに係る全ての情報をプレイヤ情報として記憶部に記憶させる。プレイヤ情報としては、例えば、所有キャラに係る情報、パーティ情報、所持アイテム情報、クエストのクリア回数、プレイヤのニックネーム等が含まれる。
【０１４４】
報酬決定部１８２は、クエストに成功した場合に、プレイヤに付与する報酬を決定する。
【０１４５】
次に、情報処理システムＳの処理の一例を説明する。ここでは、まず、ソロプレイによるバトルゲームを実現するための処理の一例について説明し、その後、マルチプレイによるバトルゲームを実現するための処理の一例について説明する。
【０１４６】
（ソロプレイに係る情報処理システムＳの処理）
図１５は、プレイヤ端末１およびサーバ１００におけるソロプレイに係る処理を説明するシーケンス図である。ログイン操作がプレイヤ端末１に入力されると、送受信部６０がログイン情報をサーバ１００に送信する処理が実行される（Ｐ１）。サーバ１００の送受信部１６０がログイン情報を受信すると、プレイヤＩＤに対応付けて記憶されている各種のプレイヤ情報がセットされる（Ｓ１）。プレイヤ端末１は、サーバ１００からプレイヤ情報を受信すると、アウトゲームに係るゲーム画像をディスプレイ２６に表示する。
【０１４７】
そして、クエスト選択画面（図４Ａ参照）でクエストが選択された後、プレイモード選択画面（図４Ｂ参照）でプレイモードとしてソロプレイが選択され、パーティ選択画面（図４Ｃ参照）でクエスト開始操作（スタートボタン３６ｂのタップ）が入力されると、プレイヤ端末１からサーバ１００にクエスト開始情報が送信される（Ｐ２）。このクエスト開始情報には、選択中パーティに係るパーティ情報、選択されているクエストの種別が含まれる。
【０１４８】
サーバ１００がクエスト開始情報を受信すると、回数設定部１６８が、クエストの種別に基づいて、復活可能回数情報をセットする（Ｓ２）。プレイヤ端末１では、復活可能回数情報を受信すると、クエスト開始処理（Ｐ３）が実行される。
【０１４９】
図１６は、プレイヤ端末１におけるクエスト開始処理を説明するフローチャートである。クエスト開始処理では、登録部６２が、選択中パーティのパーティ情報に基づき、第１パーティ編成キャラから第４パーティ編成キャラを、それぞれ第１参加キャラ４０ａから第４参加キャラ４０ｄに設定する（Ｐ３−１）。また、ここでは、登録部６２が、第１パーティ編成キャラを操作対象キャラに設定し、その他のパーティ編成キャラを未操作キャラに設定する。
【０１５０】
また、回数設定部６８は、受信した復活可能回数情報に基づき、第１参加キャラ４０ａから第４参加キャラ４０ｄのそれぞれに対応付けて復活可能回数を記憶する（Ｐ３−２）。そして、クエスト実行部６６は、クエスト開始画面（図５Ａ参照）をディスプレイ２６に表示する（Ｐ３−３）。図１５に戻り、クエスト開始処理が終了すると、クエスト実行部６６が、ソロプレイ実行処理を開始する（Ｐ４）。
【０１５１】
図１７は、プレイヤ端末１におけるソロプレイ実行処理を説明する第１のフローチャートである。図１８は、プレイヤ端末１におけるソロプレイ実行処理を説明する第２のフローチャートである。なお。以下のソロプレイ実行処理は、ソロプレイが終了するまでの間、プレイヤ端末１のフレーム単位（画像の更新間隔）で繰り返し実行される。また、本実施形態では、ボスキャラに係る処理について説明し、ボスキャラ以外の敵キャラクタに係る処理については説明を省略する。
【０１５２】
クエスト実行部６６は、参加キャラを識別するための処理対象識別値を所定値にセットする（Ｐ４−１）。例えば、処理対象識別値として００Ｈから０３Ｈの４つの値が設定されており、００Ｈは第１参加キャラ４０ａに対応し、０１Ｈは第２参加キャラ４０ｂに対応し、０２Ｈは第３参加キャラ４０ｃに対応し、０３Ｈは第４参加キャラ４０ｄに対応する。ここでは、所定値として００Ｈがセットされる。
【０１５３】
クエスト実行部６６は、処理対象キャラ（処理対象識別値に対応する参加キャラ）が生存キャラであるか否かを判定する（Ｐ４−２）。そして、処理対象キャラが生存していない場合（Ｐ４−２のＮＯ）には、処理対象識別値が最大（ここでは０３Ｈ）であるかが判定される（Ｐ４−１５）。処理対象識別値が最大であれば（Ｐ４−１５のＹＥＳ）、すなわち、全ての参加キャラに対する処理が終了すれば、後述するＰ４−２１に処理が移る。処理対象識別値が最大でなければ（Ｐ４−１５のＮＯ）、すなわち、全ての参加キャラに対する処理が終了していなければ、処理対象識別値をインクリメントし（Ｐ４−１６）、Ｐ４−２から処理を繰り返す。
【０１５４】
処理対象キャラが生存していれば（Ｐ４−２のＹＥＳ）、処理対象キャラが操作対象キャラであるかを判定する（Ｐ４−３）。処理対象キャラが操作対象キャラであれば（Ｐ４−３のＹＥＳ）、プレイヤ端末１に操作入力があるかを判定する（Ｐ４−４）。操作入力がなければ（Ｐ４−４のＮＯ）、Ｐ４−１５に処理が移る。また、処理対象キャラが操作対象キャラであり、操作入力がある場合（Ｐ４−４のＹＥＳ）、および、処理対象キャラが未操作キャラである場合（Ｐ４−３のＮＯ）には、処理対象キャラが動作中であるかを判定する（Ｐ４−５）。処理対象キャラが動作中であれば（Ｐ４−５のＹＥＳ）、Ｐ４−１５に処理が移る。
【０１５５】
一方、処理対象キャラが動作中でなければ（Ｐ４−５のＮＯ）、クエスト実行部６６が処理対象キャラの動作を決定する（Ｐ４−６）。例えば、処理対象キャラが操作対象キャラであれば、入力された操作に基づいて、処理対象キャラの攻撃動作、移動動作、スキル使用、竜化等を決定する。また、例えば、処理対象キャラが未操作キャラであれば、所定の未操作キャラの動作プログラムに基づいて、処理対象キャラの攻撃動作、移動動作、スキル使用等を決定する。
【０１５６】
クエスト実行部６６は、決定された動作が攻撃関連動作であるか否かを判定する（Ｐ４−７）。決定された動作が攻撃関連動作でなければ（Ｐ４−７のＮＯ）、必要に応じて、各種のパラメータを更新し（Ｐ４−８）、Ｐ４−１５に処理が移る。なお、攻撃関連動作は、攻撃動作に加えて、ボスキャラにダメージを与えるスキルの使用も含まれる。攻撃関連動作が決定された場合（Ｐ４−７のＹＥＳ）、クエスト実行部６６は、攻撃がボスキャラに衝突したかを判定する衝突判定処理を行い（Ｐ４−９）、ボスキャラに与えるダメージを演算し（Ｐ４−１０）、演算されたダメージをボスキャラのＨＰから減算してボスキャラのＨＰを更新する（Ｐ４−１１）。
【０１５７】
クエスト実行部６６は、更新したボスキャラのＨＰが０以下であるか否かを判定する（Ｐ４−１２）。ボスキャラのＨＰが０以下でなければ（Ｐ４−１２のＮＯ）、Ｐ４−１５に処理が移る。一方、ボスキャラのＨＰが０以下であれば（Ｐ４−１２のＹＥＳ）、復活した回数、すなわち、復活の実行回数を示す復活回数情報をセットし（Ｐ４−１３）、クエストを終了するためのクエスト終了処理を行う（Ｐ４−１４）。クエスト終了処理では、クエストの終了を示すクエスト終了情報がセットされる。
【０１５８】
全ての参加キャラについての処理が終了すると（Ｐ４−１５のＹＥＳ）、図１８に示すように、クエスト実行部６６が、ボスキャラの動作中であるかを判定する（Ｐ４−２１）。ボスキャラの動作中であれば（Ｐ４−２１のＹＥＳ）、ディスプレイ２６のゲーム画面すなわちフレームを更新し（Ｐ４−２９）、ソロプレイ実行処理が終了する。ボスキャラの動作中でなければ（Ｐ４−２１のＮＯ）、所定のボスキャラの動作プログラムに基づいて、ボスキャラの動作を決定する（Ｐ４−２２）。
【０１５９】
クエスト実行部６６は、決定された動作が攻撃関連動作であるか否かを判定する（Ｐ４−２３）。決定された動作が攻撃関連動作でなければ（Ｐ４−２３のＮＯ）、必要に応じて、各種のパラメータを更新し（Ｐ４−２４）、Ｐ４−２９に処理が移る。なお、攻撃関連動作は、通常の攻撃動作に加えて、参加キャラにダメージを与える特殊攻撃動作も含まれる。攻撃関連動作が決定された場合（Ｐ４−２３のＹＥＳ）、クエスト実行部６６は、攻撃が参加キャラに衝突したかを判定する衝突判定処理を行い（Ｐ４−２５）、参加キャラが受けるダメージを演算し（Ｐ４−２６）、演算されたダメージを、攻撃がヒットした参加キャラ（被ダメージキャラ）のＨＰから減算して被ダメージキャラのＨＰを更新する（Ｐ４−２７）。なお、同時に複数の参加キャラに攻撃がヒットすることがあり、この場合には、複数の被ダメージキャラのＨＰが減算される。
【０１６０】
クエスト実行部６６は、更新した被ダメージキャラのＨＰが０以下であるか否かを判定する（Ｐ４−２８）。被ダメージキャラのＨＰが０以下でなければ（Ｐ４−２８のＮＯ）、Ｐ４−２９に処理が移る。一方、被ダメージキャラのＨＰが０以下であれば（Ｐ４−２８のＹＥＳ）、復活処理実行部７０が復活判定処理（Ｐ４−１００）を実行する。
【０１６１】
図１９は、プレイヤ端末１におけるソロプレイ時の復活判定処理を説明するフローチャートである。復活処理実行部７０は、生存キャラ、すなわち、ＨＰが０ではない参加キャラが存在しているか否か判定する（Ｐ４−１０１）。生存キャラが存在している場合（Ｐ４−１０１のＹＥＳ）、復活処理実行部７０は、操作対象キャラのＨＰが０であるか否かを判定する（Ｐ４−１０２）。操作対象キャラのＨＰが０である場合（Ｐ４−１０２のＹＥＳ）、操作対象キャラを変更する（Ｐ４−１０３）。
【０１６２】
一方、復活処理実行部７０は、生存キャラが存在しない場合（Ｐ４−１０１のＮＯ）、すなわち、参加キャラが全滅した場合、復活可能回数が０よりも多い参加キャラを抽出する（Ｐ４−１０４）。復活可能回数が０よりも多い参加キャラがいなければ（Ｐ４−１０５のＮＯ）、クエストを終了するためのクエスト終了処理を行う（Ｐ４−１０６）。クエスト終了処理では、クエスト終了情報がセットされる。復活可能回数が０よりも多い参加キャラがいれば（Ｐ４−１０５のＹＥＳ）、復活させる参加キャラの復活可能回数をデクリメントする（Ｐ４−１０７）。また、復活処理実行部７０は、復活させる参加キャラのＨＰ等のパラメータをセットし（Ｐ４−１０８）、復活待機時間をセットし（Ｐ４−１０９）、無敵時間をセットする（Ｐ４−１１０）。
【０１６３】
以上の処理により、ソロプレイによるバトルゲームでは、復活可能回数の設定、および、復活処理が、参加キャラごとに実行されることとなる。
【０１６４】
（マルチプレイに係る情報処理システムＳの処理）
図２０は、プレイヤ端末１およびサーバ１００におけるマルチプレイに係る処理を説明する第１のシーケンス図である。図２１は、プレイヤ端末１およびサーバ１００におけるマルチプレイに係る処理を説明する第２のシーケンス図である。図２２は、プレイヤ端末１およびサーバ１００におけるマルチプレイに係る処理を説明する第３のシーケンス図である。ルーム選択画面（図９Ａ参照）においてルーム作成操作（ルーム作成ボタン５２ａのタップ）がプレイヤ端末１（ホスト端末）に入力されると、送受信部６０がルーム作成要求情報をサーバ１００に送信するルーム作成要求処理が実行される（Ｈ１１）。なお、ルーム作成要求情報には、ホストプレイヤが選択したクエストの種別、パーティ情報、プレイヤ情報、端末情報等が含まれる。
【０１６５】
サーバ１００の送受信部１６０がルーム作成要求情報を受信すると、ルーム生成部１７０が、バトルゲームサーバ１００Ｂにおいてルームを作成するルーム作成処理を実行する（Ｓ１１）。また、ここでは、登録部１６２が、プレイヤ情報を登録するとともに、パーティ情報に基づいて、第１パーティ編成キャラを、第１参加キャラ４０ａおよび操作対象キャラとして登録する。つまり、ルーム作成操作は、プレイヤが操作可能な操作対象キャラを参加キャラとして登録するよう要求する登録要求操作と言える。そして、プレイヤ設定部１６４は、操作対象キャラと、ホストプレイヤとを対応させて記憶する。
【０１６６】
ルームが作成されると、ホスト端末が、ルームに係るルーム情報を受信する。ホスト端末では、受信したルーム情報に基づいて、ルーム表示部７２がルーム待機画面を表示するルーム待機画面表示処理を実行する（Ｈ１２）。
【０１６７】
また、ホスト端末とは異なるプレイヤ端末１（ゲスト端末）において、入室要求操作（ルーム検索ボタン５２ｂのタップ）が入力されると、送受信部６０が入室要求情報をサーバ１００に送信する入室要求処理が実行される（Ｇ１１）。なお、入室要求情報には、ゲストプレイヤが選択したクエストの種別、パーティ情報、プレイヤ情報、端末情報等が含まれる。
【０１６８】
サーバ１００の送受信部１６０が入室要求情報を受信すると、ルーム生成部１７０が、バトルゲームサーバ１００Ｂに作成されているルームであって、入室要求情報に条件が合致する、満室ではないルームを検索、特定する（Ｓ１２）。いずれかのルームが特定されると、キャラクタ設定処理（Ｓ５０）が実行される。
【０１６９】
図２３は、サーバ１００におけるキャラクタ設定処理を説明するフローチャートである。このキャラクタ設定処理は、プレイヤの入室時と退室時とで共通のモジュールがコールされて実行される。登録部１６２は、ルームにプレイヤが入室したか、あるいは、ルームからプレイヤが退室したかを判定する（Ｓ５０−１）。プレイヤの入室時であれば（Ｓ５０−１のＹＥＳ）、登録部１６２が、プレイヤ情報を登録し（Ｓ５０−２）、パーティ情報に基づいて、第１パーティ編成キャラを、参加キャラおよび操作対象キャラとして登録する（Ｓ５０−３）。また、ここでは、プレイヤ設定部１６４が、操作対象キャラと、ゲストプレイヤとを対応させて記憶する。
【０１７０】
登録部１６２は、操作対象キャラが定員数であるか否かを判定する（Ｓ５０−４）。そして、操作対象キャラが定員数であれば（Ｓ５０−４のＹＥＳ）、更新されたルーム情報をセットする（Ｓ５０−６）。一方、操作対象キャラが定員数でなければ（Ｓ５０−４のＮＯ）、登録部１６２が、ホストプレイヤまたはゲストプレイヤのパーティ情報に基づき、ＮＰＣ（未操作キャラ）を登録するとともに、プレイヤ設定部１６４が、ＮＰＣと、いずれかのプレイヤとを対応させて記憶する（Ｓ５０−５）。ＮＰＣが登録された場合にも、更新されたルーム情報がセットされる（Ｓ５０−６）。
【０１７１】
また、プレイヤの退室時であれば（Ｓ５０−１のＮＯ）、登録部１６２が、プレイヤ情報を削除し（Ｓ５０−７）、退室したプレイヤに対応する参加キャラを削除する（Ｓ５０−８）。登録部１６２は、ルーム内にいるプレイヤが２人以上であるか否かを判定する（Ｓ５０−９）。ルームに２人以上のプレイヤが残っていれば（Ｓ５０−９のＹＥＳ）、Ｓ５０−５に処理が移り、ルームに２人以上のプレイヤが残っていなければ（Ｓ５０−９のＮＯ）、登録されているＮＰＣを削除する（Ｓ５０−１０）。ＮＰＣが削除された場合にも、更新されたルーム情報がセットされる（Ｓ５０−６）。
【０１７２】
図２０に戻り、サーバ１００でセットされたルーム情報は、ホスト端末およびゲスト端末の双方で受信される。ホスト端末およびゲスト端末では、受信したルーム情報に基づいて、ルーム表示部７２がルーム待機画面を表示するルーム待機画面表示処理を実行する（Ｈ１３、Ｇ１２）。
【０１７３】
また、ゲスト端末において、準備完了操作（準備完了ボタンのタップ）が入力されると、ゲスト端末からサーバ１００に準備完了情報が送信される準備完了処理が実行される（Ｇ１３）。サーバ１００に送信された準備完了情報は、ルームに接続されている全てのプレイヤ端末１によって受信可能にサーバ１００にセットされる（Ｓ１３）。準備完了情報を受信したプレイヤ端末１では、ルーム表示部７２が、準備完了ボタンがタップされたゲスト端末に対応するプレイヤ情報表示部に、準備完了表示（図１０Ｂ参照）を重畳するルーム待機画面表示処理を実行する（Ｈ１４、Ｇ１４）。
【０１７４】
また、プレイヤは、ルーム待機画面において、プレイヤ端末１に登録要求操作を入力することで、参加キャラ（操作対象キャラ）を変更することができる。図２１に示すように、ホスト端末またはゲスト端末において、登録要求操作が入力されると、各端末においてパーティ情報変更処理（Ｈ２１、Ｇ２１）が実行される。パーティ情報変更処理では、登録部６２が、選択中パーティを変更するとともに、変更後のパーティ情報を登録要求情報としてサーバ１００に送信する。サーバ１００では、受信した登録要求情報に基づき、登録部６２が、参加キャラ、操作対象キャラ、未操作キャラ等を登録し、ルーム情報を更新する（Ｓ２１）。
【０１７５】
ルーム情報が更新されると、ホスト端末およびゲスト端末が更新後のルーム情報を受信し、受信したルーム情報に基づいて、ルーム表示部７２がルーム待機画面を更新するルーム待機画面表示処理を実行する（Ｈ２２、Ｇ２２）。
【０１７６】
また、ホスト端末において、解散要求操作（解散ボタン５４ｅのタップ）が入力されると、ホスト端末からサーバ１００に解散要求情報が送信されるルーム解散要求処理が実行される（Ｈ２３）。サーバ１００では、解散要求情報を受信すると、ルーム生成部１７０がルームを消滅させるルーム解散処理を実行する（Ｓ２２）。ルーム解散処理が実行されると、ホスト端末およびゲスト端末が解散情報を受信し、ルーム表示部７２がルーム待機画面を更新表示するルーム待機画面表示処理を実行する（Ｈ２４、Ｇ２３）。
【０１７７】
また、ルームに入室中のゲスト端末において、退室要求操作（退室ボタンのタップ）が入力されると、ゲスト端末からサーバ１００に退室要求情報が送信される退室要求処理が実行される（Ｇ２４）。サーバ１００では、退室要求情報を受信すると、上記したキャラクタ設定処理（Ｓ５０）が実行される。そして、ホスト端末およびゲスト端末では、更新されたルーム情報を受信するとともに、受信したルーム情報に基づいて、ルーム表示部７２がルーム待機画面を更新表示するルーム待機画面表示処理を実行する（Ｈ２５、Ｇ２５）。
【０１７８】
また、図２２に示すように、ホスト端末において、クエスト開始操作（開始ボタン５４ｆのタップ）が入力されると、プレイヤ端末１からサーバ１００にクエスト開始情報が送信される（Ｈ３１）。サーバ１００がクエスト開始情報を受信すると、回数設定部１６８が、クエストの種別およびプレイヤの参加人数に基づいて、復活可能回数情報をセットする（Ｓ３１）。ホスト端末およびゲスト端末では、復活可能回数情報を受信すると、クエスト開始処理（Ｈ３２、Ｇ３１）が実行される。なお、マルチプレイに係るクエスト開始処理では、上記したソロプレイに係るクエスト開始処理（図１６）と同じ内容の処理が実行される。ただし、ソロプレイに係るクエスト開始処理では、回数設定部６８が、参加キャラに対応付けて復活可能回数を記憶するが、マルチプレイに係るクエスト開始処理では、参加キャラに対応付けることなく、復活可能回数を記憶する。ただし、マルチプレイとソロプレイとで、クエスト開始処理を完全に共通化してもよい。
【０１７９】
そして、ホスト端末では、ホストマルチプレイ実行処理（Ｈ１００）が開始され、ゲスト端末では、ゲストマルチプレイ実行処理（Ｇ１００）が開始され、サーバ１００では、同期処理（Ｓ１００）が実行される。以下では、理解を容易にするため、同期処理（Ｓ１００）、ゲストマルチプレイ実行処理（Ｇ１００）、ホストマルチプレイ実行処理（Ｈ１００）の順に詳述する。
【０１８０】
図２４は、サーバ１００における同期処理を説明するフローチャートである。同期処理部１６６は、ルームに接続されているプレイヤ端末１からの受信情報を確認する（Ｓ１００−１）。同期処理部１６６は、受信情報がクエスト終了情報であるか否かを判定する（Ｓ１００−２）。クエスト終了情報を受信すると（Ｓ１００−２のＹＥＳ）、クエスト終了処理（Ｓ１００−３）を実行する。また、同期処理部１６６は、ルームに接続されているプレイヤ端末１のうち、通信切断中のプレイヤ端末１がある否かを判定する（Ｓ１００−４）。通信切断中のプレイヤ端末１があれば（Ｓ１００−４のＹＥＳ）、通信切断時間を計時し（Ｓ１００−５）、所定時間が経過したか否かを判定する（Ｓ１００−６）。所定時間が経過した場合（Ｓ１００−６のＹＥＳ）、通信切断したプレイヤ端末１がホスト端末であるかを判定する（Ｓ１００−７）。
【０１８１】
ホスト端末が通信切断した場合（Ｓ１００−７のＹＥＳ）、同期処理部１６６は、全てのプレイヤ端末１に対して、マルチプレイをソロプレイに切り替えるソロプレイ切換処理を実行する（Ｓ１００−８）。また、ゲスト端末が通信切断した場合（Ｓ１００−７のＮＯ）、プレイヤ設定部１６４が、通信切断したプレイヤに対応する参加キャラを、他のプレイヤに対応させて記憶する（Ｓ１００−９）。そして、プレイヤ設定部１６４は、参加キャラとプレイヤとの対応関係の変更を示す対応要求情報をセットする（Ｓ１００−１０）。
【０１８２】
また、同期処理部１６６は、プレイヤ端末１から受信した情報を、所定のプレイヤ端末１に受信させるように、送信コマンドをセットする（Ｓ１００−１１）。ここでは、プレイヤ端末１から受信する参加キャラの位置情報、竜化したことを示す竜化情報、スキルの使用を示すスキル情報が、全てのプレイヤ端末１に向けてセットされる。また、参加キャラが受けた被ダメージ情報、および、敵キャラクタに与えた与ダメージ情報は、ホスト端末に向けてセットされる。なお、各情報の送受信先は一例に過ぎず、各情報が送受信されるプレイヤ端末１は適宜設定可能である。
【０１８３】
図２５は、ゲスト端末におけるゲストマルチプレイ実行処理を説明する第１のフローチャートである。図２６は、ゲスト端末におけるゲストマルチプレイ実行処理を説明する第２のフローチャートである。なお。以下のゲストマルチプレイ実行処理は、マルチプレイが終了するまでの間、ゲスト端末のフレーム単位（画像の更新間隔）で繰り返し実行される。
【０１８４】
クエスト実行部６６は、処理対象識別値を所定値（ここでは００Ｈ）にセットする（Ｇ１００−１）。クエスト実行部６６は、処理対象キャラ（処理対象識別値に対応する参加キャラ）が生存キャラであるか否かを判定する（Ｇ１００−２）。そして、処理対象キャラが生存していない場合（Ｇ１００−２のＮＯ）には、処理対象識別値が最大であるかが判定される（Ｇ１００−１２）。処理対象識別値が最大であれば（Ｇ１００−１２のＹＥＳ）、すなわち、当該プレイヤに対応する全ての参加キャラに対する処理が終了すれば、後述するＧ１００−２１に処理が移る。処理対象識別値が最大でなければ（Ｇ１００−１２のＮＯ）、すなわち、当該プレイヤに対応する全ての参加キャラに対する処理が終了していなければ、処理対象識別値をインクリメントし（Ｇ１００−１３）、Ｇ１００−２から処理を繰り返す。
【０１８５】
処理対象キャラが生存していれば（Ｇ１００−２のＹＥＳ）、処理対象キャラが操作対象キャラであるかを判定する（Ｇ１００−３）。処理対象キャラが操作対象キャラであれば（Ｇ１００−３のＹＥＳ）、プレイヤ端末１に操作入力があるかを判定する（Ｇ１００−４）。操作入力がなければ（Ｇ１００−４のＮＯ）、Ｇ１００−１２に処理が移る。また、処理対象キャラが操作対象キャラであり、操作入力がある場合（Ｇ１００−４のＹＥＳ）、および、処理対象キャラが未操作キャラである場合（Ｇ１００−３のＮＯ）には、処理対象キャラが動作中であるかを判定する（Ｇ１００−５）。処理対象キャラが動作中であれば（Ｇ１００−５のＹＥＳ）、Ｇ１００−１２に処理が移る。
【０１８６】
一方、処理対象キャラが動作中でなければ（Ｇ１００−５のＮＯ）、クエスト実行部６６が処理対象キャラの動作を決定する（Ｇ１００−６）。クエスト実行部６６は、決定された動作が攻撃関連動作であるか否かを判定する（Ｐ１００−７）。決定された動作が攻撃関連動作でなければ（Ｇ１００−７のＮＯ）、必要に応じて、各種のパラメータを更新し（Ｇ１００−８）、Ｇ１００−１１に処理が移る。攻撃関連動作が決定された場合（Ｇ１００−７のＹＥＳ）、クエスト実行部６６は、衝突判定処理を行い（Ｇ１００−９）、ボスキャラに与えるダメージを演算する（Ｇ１００−１０）。また、クエスト実行部６６は、演算した与ダメージ情報や、他のパラメータ情報等をセットして、サーバ１００に送信する（Ｇ１００−１１）。
【０１８７】
当該プレイヤに対応する全ての参加キャラについての処理が終了すると（Ｇ１００−１２のＹＥＳ）、図２６に示すように、クエスト実行部６６が、ボスキャラの動作を示す動作情報を受信したかを判定する（Ｇ１００−２１）。ボスキャラ動作情報を受信していなければ、ディスプレイ２６のフレームを更新し（Ｇ１００−２９）、サーバ１００に送信する送信コマンドをセットし（Ｇ１００−３０）、ゲストマルチプレイ実行処理が終了する。
【０１８８】
ボスキャラ動作情報を受信すると（Ｇ１００−２１のＹＥＳ）、ボスキャラのアニメーションをセットする（Ｇ１００−２２）。クエスト実行部６６は、ボスキャラの動作が攻撃関連動作であるか否かを判定する（Ｇ１００−２３）。ボスキャラの動作が攻撃関連動作でなければ（Ｇ１００−２３のＮＯ）、必要に応じて、各種のパラメータを更新し（Ｇ１００−２４）、Ｇ１００−２９に処理が移る。ボスキャラの動作が攻撃関連動作であれば（Ｇ１００−２３のＹＥＳ）、クエスト実行部６６は、衝突判定処理を行い（Ｇ１００−２５）、当該プレイヤに対応する参加キャラが受けるダメージを演算し（Ｇ１００−２６）、演算されたダメージを、被ダメージキャラのＨＰから減算して被ダメージキャラのＨＰを更新する（Ｇ１００−２７）。クエスト実行部６６は、被ダメージキャラのＨＰが０以下であるか否かを判定する（Ｇ１００−２８）。被ダメージキャラのＨＰが０以下であれば（Ｇ１００−２８のＹＥＳ）、復活処理実行部７０が復活判定処理（Ｇ１０１）を実行する。
【０１８９】
図２７は、プレイヤ端末１におけるマルチプレイ時の復活判定処理を説明するフローチャートである。復活処理実行部７０は、生存キャラ、すなわち、ＨＰが０ではない参加キャラが存在しているか否か判定する（Ｇ１０１−１）。生存キャラが存在している場合（Ｇ１０１−１のＹＥＳ）、復活処理実行部７０は、操作対象キャラのＨＰが０であるか否かを判定する（Ｇ１０１−２）。操作対象キャラのＨＰが０である場合（Ｇ１０１−２のＹＥＳ）、操作対象キャラを変更する（Ｇ１０１−３）。なお、詳しい説明は省略するが、通信切断した他のプレイヤに対応していた参加キャラが、後から対応付けられた場合、当該参加キャラを操作対象キャラとして操作することはできない。したがって、後から対応付けられた参加キャラのみが生存キャラとして存在している場合には、操作対象キャラが変更されることはない。ただし、後から対応付けられた参加キャラが操作対象キャラに設定されてもよい。
【０１９０】
復活処理実行部７０は、生存キャラが存在しない場合（Ｇ１０１−１のＮＯ）、すなわち、当該プレイヤに対応する参加キャラが全滅した場合、復活可能回数をロードする（Ｇ１０１−４）。復活処理実行部７０は、復活可能回数が０より多いか否か判定する（Ｇ１０１−５）。復活可能回数が０であれば（Ｇ１０１−５のＮＯ）、被ダメージキャラを継続不可能状態に設定する（Ｇ１０１−６）。これにより、以後、被ダメージキャラが動作不能となる。
【０１９１】
一方、復活可能回数が０よりも多ければ（Ｇ１０１−５のＹＥＳ）、復活処理実行部７０が、復活可能回数をデクリメントする（Ｇ１０１−７）。また、復活処理実行部７０は、復活させる参加キャラのＨＰ等のパラメータをセットし（Ｇ１０１−８）、復活待機時間をセットし（Ｇ１０１−９）、無敵時間をセットする（Ｇ１０１−１０）。
【０１９２】
以上の処理により、マルチプレイによるバトルゲームでは、復活可能回数の設定、および、復活処理が、プレイヤ単位で実行されることとなる。
【０１９３】
図２８は、ホスト端末におけるホストマルチプレイ実行処理を説明する第１のフローチャートである。図２９は、ホスト端末におけるホストマルチプレイ実行処理を説明する第２のフローチャートである。なお。以下のホストマルチプレイ実行処理は、マルチプレイが終了するまでの間、ホスト端末のフレーム単位（画像の更新間隔）で繰り返し実行される。
【０１９４】
クエスト実行部６６は、図２８に示すＨ１００−１からＨ１００−１３の処理を実行する。これらの処理は、ホストプレイヤに対応する参加キャラに係る処理であり、ゲストマルチプレイ実行処理のＧ１００−１からＧ１００−１３の処理と同じである。ホストプレイヤに対応する全ての参加キャラについての処理が終了すると（Ｈ１００−１２のＹＥＳ）、図２９に示すように、クエスト実行部６６が、ボスキャラのＨＰを更新する（Ｈ１００−２１）。
【０１９５】
なお、ここでは、サーバ１００から受信する与ダメージ情報に基づいて、ボスキャラのＨＰが減算される。つまり、本実施形態では、ボスキャラに与える与ダメージ値、および、ボスキャラから受ける被ダメージ値は、各プレイヤ端末１で演算される。このうち、ボスキャラからダメージを受けて、参加キャラのＨＰを減算する処理は、各プレイヤ端末１で行われる。一方、ボスキャラのＨＰの管理は、ホスト端末で行われる。ここでは、サーバ１００、すなわち、他のゲスト端末から送信された与ダメージ情報に基づいて、ボスキャラのＨＰが更新される。
【０１９６】
クエスト実行部６６は、ボスキャラのＨＰが０以下であるか否かを判定する（Ｈ１００−２２）。ボスキャラのＨＰが０以下になると（Ｈ１００−２２のＹＥＳ）、クエスト実行部６６は、復活可能回数情報をセットし（Ｈ１００−２３）、クエスト終了処理を実行する（Ｈ１００−２４）。なお、ゲスト端末で復活可能回数が減算されると、更新された復活可能回数情報が他のゲスト端末とホスト端末とに送信され、各端末で全てのプレイヤの復活可能回数が共有される。ホスト端末でセットされる復活可能回数情報には、全てのプレイヤの復活可能回数が含まれている。
【０１９７】
ボスキャラのＨＰが０以下でなければ（Ｈ１００−２２のＮＯ）、クエスト実行部６６は、ボスキャラの動作中であるかを判定する（Ｈ１００−２５）。ボスキャラの動作中であれば（Ｈ１００−２５のＹＥＳ）、参加キャラが全滅したかを判定する（Ｈ１００−３４）。参加キャラが全滅していれば（Ｈ１００−３４のＹＥＳ）、所定のクエスト終了処理を実行し（Ｈ１００−３５）、ホストマルチプレイ実行処理を終了する。参加キャラが全滅していなければ（Ｈ１００−３４のＮＯ）、ディスプレイ２６のフレームを更新し（Ｈ１００−３６）、サーバ１００に送信する送信コマンドをセットし（Ｈ１００−３７）、ホストマルチプレイ実行処理が終了する。
【０１９８】
一方、ボスキャラの動作中でなければ（Ｈ１００−２５のＮＯ）、所定のボスキャラの動作プログラムに基づいて、ボスキャラの動作を決定し（Ｈ１００−２６）、ボスキャラ動作情報をセットする（Ｈ１００−２７）。ここでセットされたボスキャラ動作情報は、送受信部６０によりサーバ１００に送信され、サーバ１００を介して各ゲスト端末に送信される。
【０１９９】
また、クエスト実行部６６は、決定されたボスキャラの動作が攻撃関連動作であるか否かを判定する（Ｈ１００−２８）。決定された動作が攻撃関連動作でなければ（Ｈ１００−２８のＮＯ）、必要に応じて、各種のパラメータを更新し（Ｈ１００−２９）、Ｈ１００−３４に処理が移る。攻撃関連動作が決定された場合（Ｈ１００−２８のＹＥＳ）、クエスト実行部６６は、攻撃が、ホストプレイヤに対応する参加キャラに衝突したかを判定する衝突判定処理を行い（Ｈ１００−３０）、参加キャラが受けるダメージを演算し（Ｈ１００−３１）、演算されたダメージを、被ダメージキャラのＨＰから減算して被ダメージキャラのＨＰを更新する（Ｈ１００−３２）。
【０２００】
クエスト実行部６６は、被ダメージキャラのＨＰが０以下であるか否かを判定する（Ｈ１００−３３）。被ダメージキャラのＨＰが０以下でなければ（Ｈ１００−３３のＮＯ）、Ｈ１００−３４に処理が移る。一方、被ダメージキャラのＨＰが０以下であれば（Ｈ１００−３３のＹＥＳ）、復活処理実行部７０が復活判定処理（Ｈ１０１）を実行する。なお、ホスト端末で実行される復活判定処理（Ｈ１０１）は、ゲスト端末で実行される復活判定処理（Ｇ１０１）と同じである。
【０２０１】
以上のように、同期処理（Ｓ１００）、ゲストマルチプレイ実行処理（Ｇ１００）、ホストマルチプレイ実行処理（Ｈ１００）が、それぞれサーバ１００、ゲスト端末、ホスト端末で同時並行して行われることで、マルチプレイによるバトルゲームが実現される。
【０２０２】
図２２に戻り、マルチプレイによるバトルゲームが終了すると、サーバ１００においては、報酬決定部１８２が報酬抽選処理（Ｓ３２）を実行する。報酬決定部１８２は、基礎報酬抽選テーブル（図８Ａ参照）を用いて基礎報酬を決定し、クエスト終了時に送信される復活可能回数情報に基づき、復活回数報酬抽選テーブル（図８Ｂ）を用いて復活回数報酬を決定する。プレイヤ情報記憶部１８０は、決定された報酬をプレイヤに付与したり、クエストのクリア情報等を更新したりするべく、サーバ１００のプレイヤ情報を更新する（Ｓ３３）。ホスト端末およびゲスト端末では、サーバ１００から受信した報酬情報に基づいて、報酬画面（図７Ｃ参照）を表示する報酬画面表示処理を実行し（Ｈ３３、Ｇ３２）、クエストを終了する（Ｈ３４、Ｇ３３）。
【０２０３】
以上、添付図面を参照しながら実施形態の一態様について説明したが、本発明は上記実施形態に限定されないことは言うまでもない。当業者であれば、特許請求の範囲に記載された範疇において、各種の変形例または修正例に想到し得ることは明らかであり、それらについても当然に技術的範囲に属するものと了解される。
【０２０４】
上記実施形態において、プレイヤ端末１とサーバ１００とで行われる処理の分担は一例に過ぎない。例えば、上記実施形態では、衝突判定やダメージ値の演算等がプレイヤ端末１で実行されることとしたが、サーバ１００で実行されてもよい。いずれにしても、上記した各処理は、プレイヤ端末１およびサーバ１００の少なくともいずれかで実行されればよいものであり、その実行タイミングや、実行する装置は特に限定されない。
【０２０５】
上記実施形態では、参加キャラのＨＰが０以下になると、継続不可能状態となって動作が不可能となり、参加キャラのＨＰが０よりも大きい場合に、継続可能状態として動作が可能であることとした。しかしながら、継続可能状態および継続不可能状態と判定する条件はこれに限らない。例えば、参加キャラに所定数のライフ値が設定され、敵キャラクタの攻撃を受けると、ライフ値が減少するゲーム性であって、ライフ値が０になった場合に、継続不可能状態としてもよい。
【０２０６】
いずれにしても、ゲーム中にプレイヤ端末１に入力される操作またはコンピュータ制御に基づいて、継続可能状態の参加キャラ（参加オブジェクト）を動作させ、参加キャラ（参加オブジェクト）が継続不可能状態であれば、この参加キャラ（参加オブジェクト）の動作を不可能とすればよく、ゲーム性は特に限定されるものではない。
【０２０７】
また、上記実施形態では、未操作キャラ（未操作オブジェクト）が対応付けられたプレイヤについて、対応する全ての参加キャラ（参加オブジェクト）が継続不可能状態となった場合に、復活処理が実行される。しかしながら、例えば、対応する参加キャラが継続不可能状態となった場合に、他の参加キャラが継続不可能状態になるのを待たずに、復活処理が実行されてもよい。
【０２０８】
また、上記実施形態では、マルチプレイにおいて、参加キャラ（参加オブジェクト）の登録数の上限である定員数が設けられているが、定員数は設定されなくてもよい。また、上記実施形態では、定員数と、操作対象キャラ（操作対象オブジェクト）の登録数との差分だけ、未操作キャラ（未操作オブジェクト）が参加キャラ（参加オブジェクト）として登録されることとした。しかしながら、未操作キャラは、上記の差分に拘わらず、例えば、所定数を上限として設定されてもよいし、未操作キャラの登録有無や登録数を、プレイヤが選択可能としてもよい。
【０２０９】
また、上記実施形態では、ソロプレイが可能である場合について説明したが、ソロプレイは必須ではない。
【０２１０】
なお、上記実施形態における処理を実行するための情報処理プログラムは、コンピュータが読み取り可能な記憶媒体に格納され、記憶媒体として提供されてもよい。さらには、この記憶媒体を含むゲーム端末装置が提供されてもよい。また、上記実施形態は、各機能およびフローチャートに示すステップを実現する情報処理方法としてもよい。
【産業上の利用可能性】
【０２１１】
本発明は、情報処理プログラム、情報処理方法および情報処理システムに利用することができる。
【符号の説明】
【０２１２】
１  プレイヤ端末（ゲーム端末）
６０、１６０  送受信部
６２、１６２  登録部
６４、１６４  プレイヤ設定部
６６  クエスト実行部（ゲーム実行部）
６８、１６８  回数設定部
７０  復活処理実行部
Ｓ  情報処理システム
【要約】
【課題】複数のプレイヤが協力してプレイするゲームの興趣を高める。
【解決手段】プレイヤが操作可能な操作対象キャラを参加キャラとして登録し、操作対象キャラの登録数が定員数未満の場合、コンピュータ制御に基づいて動作する未操作キャラを参加キャラとして登録する。操作対象キャラおよび未操作キャラは、いずれかのプレイヤに対応付けられる。参加キャラは、継続可能状態で動作可能であり、継続不可能状態になると動作が不可能となる。ゲームに参加するプレイヤには、それぞれ復活可能回数が設定される。参加キャラが継続不可能状態となった場合、参加キャラに対応するプレイヤに設定された復活可能回数の範囲内で、参加キャラの復活が可能である。
【選択図】図１３【図１】
0006745421.tif 000002
【図２】
0006745421.tif 000003
【図３】
0006745421.tif 000004
【図４】
0006745421.tif 000005
【図５】
0006745421.tif 000006
【図６】
0006745421.tif 000007
【図７】
0006745421.tif 000008
【図８】
0006745421.tif 000009
【図９】
0006745421.tif 000010
【図１０】
0006745421.tif 000011
【図１１】
0006745421.tif 000012
【図１２】
0006745421.tif 000013
【図１３】
0006745421.tif 000014
【図１４】
0006745421.tif 000015
【図１５】
0006745421.tif 000016
【図１６】
0006745421.tif 000017
【図１７】
0006745421.tif 000018
【図１８】
0006745421.tif 000019
【図１９】
0006745421.tif 000020
【図２０】
0006745421.tif 000021
【図２１】
0006745421.tif 000022
【図２２】
0006745421.tif 000023
【図２３】
0006745421.tif 000024
【図２４】
0006745421.tif 000025
【図２５】
0006745421.tif 000026
【図２６】
0006745421.tif 000027
【図２７】
0006745421.tif 000028
【図２８】
0006745421.tif 000029
【図２９】
0006745421.tif 000030