JP7702093B2 - ゲームプログラム、ゲームシステム、ゲーム装置、およびゲーム処理方法 - Google Patents

Description

本開示は、ユーザの情報処理端末においてゲームを実行するためのゲーム処理に関する。

従来から、複数のゲーム機間で通信してゲーム状況を同期させて、ユーザが他のユーザと一緒にゲームを進行させるマルチプレイモードを含むゲームシステムが知られている（例えば、特許文献１）。

特開２０２１－１３３１３８号公報

上記のゲームシステムは、例えばレースゲーム等で通信対戦プレイを行う場合には適したシステムと言える。しかしながら、ゲームの性質やジャンルによっては、リアルタイムで他のゲーム機と通信してゲームの進行状況を同期しながら、複数プレイヤ間で同じゲームを進行させることが難しいものがあった。

それ故に、本開示の目的は、リアルタイムでゲームの進行状況を同期しながら、同じゲームを進行させることが難しい性質のゲームでもマルチプレイが楽しめるゲームプログラム、ゲームシステム、ゲーム装置、およびゲーム処理方法を提供することである。

上記目的を達成するために、例えば以下のような構成例が挙げられる。

（構成１）
構成１は、ユーザの情報処理端末においてゲームを実行するためのゲームプログラムであって、当該情報処理端末のコンピュータを、第１ゲーム開始手段と、第１ゲーム進行手段と、第１送信手段と、第２ゲーム開始手段と、第２ゲーム進行手段と、第２送信手段として機能させる。第１ゲーム開始手段は、ユーザによる第１開始指示入力に基づいて、予め定められた初期設定データに基づくゲームであって、当該ユーザのユーザキャラクタを用いる当該ゲームを開始する。第１ゲーム進行手段は、第１開始指示入力によって開始されたゲームを、ユーザの操作入力に基づいて進行させる。第１送信手段は、第１開始指示入力によってゲームが開始された後の第１タイミングにおいて、当該ゲームの進行を終了させ、当該第１タイミングにおける当該ゲームの進行状況を示す進行状況データをサーバに送信する。第２ゲーム開始手段は、ユーザの第２開始指示入力に基づいて、当該ユーザとは異なる他ユーザの他の情報処理端末によってサーバに送信され、ユーザの情報処理端末が当該サーバから取得した進行状況データに基づくゲームであって、当該他ユーザによって当該ゲームにおいて用いられていた他ユーザキャラクタと、当該ユーザのユーザキャラクタとを用いる当該ゲームを開始する。第２ゲーム進行手段は、第２指示入力に基づいて開始されたゲームを、ユーザの操作入力に基づいて進行させる。第２送信手段は、第２指示入力に基づいてゲームが開始された後の第２タイミングにおいて、当該ゲームの進行を終了させ、当該第２タイミングにおける当該ゲームの進行状況を示す進行状況データをサーバに送信し、当該第２タイミングが到来するまでに当該ゲームの勝利条件を満たした場合は、当該勝利条件を満たしたときまでの当該ゲームの進行状況を示す進行状況データを当該サーバに送信する。

上記構成例によれば、複数の情報処理端末間でリアルタイム通信を行わずとも、協力して同じゲームを進行させることができる。また、第２開始入力に基づき開始されるゲームにおいては、自身の所有するキャラクタに加え、他のユーザのキャラクタも利用できる。これにより、例えば戦力不足による不利なゲーム展開を覆すことも可能となり、戦術性を向上させ、ゲームの興趣性も向上できる。

（構成２）
構成２は、上記構成１において、ゲームはターン制ストラテジーゲームであってもよい。そして、第１タイミングは、第１開始指示入力によるゲーム開始から第１のターン数のターンが経過したタイミングであってもよく、第２タイミングは、第２開始指示入力によるゲーム開始から第２のターン数のターンが経過したタイミングであってもよい。

上記構成例によれば、ターン制ストラテジーゲームにおいて、協力プレイをユーザに楽しませることができる。特に、ターン制ストラテジーゲームでは１マップのプレイ時間が長くなる傾向があるところ、非同期で協力プレイを可能とするため、ユーザは各自のペースでゲームに参加し、協力プレイを楽しむことができる。

（構成３）
構成３は、上記構成２において、第１ゲーム進行手段および第２ゲーム進行手段は、上記ゲームにおいて、ユーザの手番のときは、当該ユーザの操作に基づいてゲームを進行させ、相手方の手番のときは、ＡＩ制御に基づいたコンピュータの操作に基づいてゲームを進行させ、ユーザの手番および相手方の手番がそれぞれ１ターン分終わったことで、第１のターン数および第２のターン数のカウントにおける１ターンが経過したものと判定してもよい。

上記構成例によれば、ターン制ストラテジーゲームにおいて、ＡＩ制御される相手方の手番に対し、ユーザ側の手番を複数のユーザで分担して進めるという形の協力プレイが提供できる。これにより、複数ユーザで力を合わせて（ＡＩ制御による）相手方に立ち向かっていくという楽しみ方を提供できる。

（構成４）
構成４は、上記構成１～３のいずれかにおいて、第１ゲーム進行手段は、ユーザの操作入力に基づいて、仮想空間内のユーザキャラクタを制御することでゲームを進行させ、第２ゲーム進行手段は、ユーザの操作入力に基づいて、仮想空間のユーザキャラクタおよび他ユーザキャラクタを制御することでゲームを進行させてもよい。

上記構成例によれば、自身が所有するキャラクタに加えて他のユーザのキャラクタも操作できるため、他のユーザのキャラクタをも利用した戦い方を行うことができ、ゲームの戦略性・戦術性を向上させることができる。

（構成５）
構成５は、上記構成４において、第２ゲーム開始手段は、取得した前行状況データに基づいて決定される仮想空間内の所定の位置にユーザのユーザキャラクタを配置した上で、ゲームを開始してもよい。

上記構成例によれば、第２ゲーム開始の際の、ユーザキャラクタの出現位置を、ゲームの進行状況に応じて異ならせることができる。これにより、ユーザキャラクタを前線に速やかに投入することも可能となる。

（構成６）
構成６は、上記構成５において、第２ゲーム開始手段は、ユーザキャラクタが配置することが可能な位置として予め定められている加勢可能位置にユーザキャラクタを配置し、加勢可能位置の数は、ゲームの進行状況に応じて変化し得るようにしてもよい。

上記構成例によれば、ユーザキャラクタを配置できる位置をある程度制限しつつ、ゲームの進行状況に応じて、当該位置の数を徐々に増やしていくというゲーム展開が提供できる。これにより、どこにでもキャラクタが配置可能とすることでゲームバランスが崩れてしまうことを防ぎ、適度なバランスとすることができる。また、途中からゲームに参加した場合でも、ユーザキャラクタを前線に速やかに投入することができる。

（構成７）
構成７は、上記構成１において、第１ゲーム進行手段および／または第２ゲーム進行手段は、ゲームの進行を終了させた際に、予め用意された複数の選択肢をユーザに提示してもよい。そして、第１送信手段、および／または、第２送信手段は、複数の選択肢からいずれかの選択肢がユーザによって指定された場合は、当該指定された選択肢に関する選択肢データを進行状況データに対応づけてサーバに送信し、第２ゲーム開始手段は、サーバから取得した当該進行状況データに対応づけられる選択肢データがある場合、当該選択肢データに基づく画像を出力してもよい。

上記構成例によれば、自身のプレイの後にプレイする他のユーザに対して、選択肢から選んだ応援メッセージ等の形で、何らかの意思を伝えることができる。また、自身がプレイする際に、前任者からの意思を確認することができる。これにより、ユーザ間で簡易なコミュニケーションを図ることができ、ゲームの興趣性を向上できる。

（構成８）
構成８は、上記構成１～７のいずれかにおいて、第２ゲーム開始手段は、サーバから取得した進行状況データに基づいて、第１タイミングまたは第２タイミングまでの当該ゲームの経過を示すリプレイを、ゲームの開始より前に出力してもよい。

上記構成例によれば、今回プレイするまでにおけるゲーム展開をユーザに把握させることができる。また、他のユーザのプレイ内容が見れるため、自身のプレイの参考にすることができる。

（構成９）
構成９は、上記構成８において、第２ゲーム開始手段は、サーバから取得した進行状況データに基づいて、第１タイミングまたは第２タイミングまでの当該ゲームの経過を示すリプレイを、ゲームの開始より前に出力してもよい。

上記構成例によれば、ゲームの開始前に、リプレイによってゲーム展開を詳細に把握させることができる。また、ユーザは、リプレイでこれまでゲーム展開を把握したうえで、その続きからプレイするか否かを選択できる。

（構成１０）
構成１０は、上記構成１～９のいずれかにおいて、第１ゲーム進行手段または第２ゲーム進行手段によるゲーム進行が終了した後、ユーザによる進行状況確認指示入力があった場合、当該入力に応じて進行状況データをサーバから取得し、当該進行状況データに基づいて、当該ゲームの経過を示すリプレイを出力してもよい。

上記構成例によれば、自身が参加したゲームがその後のどのような結果になったのかを確認できる。また、他のユーザのプレイ内容が見れるため、自身のプレイの参考にすることができる。

（構成１１）
構成１１は、上記構成１～１０のいずれかにおいて、ゲームプログラムは、第２タイミングまでにゲームの勝利条件を満たす場合、当該ゲームの勝利条件を満たしたことに基づく第１報酬をユーザに付与する第１報酬付与手段と、ユーザの情報処理端末がゲームに基づく進行状況データをサーバに送信した後、他ユーザによる当該ゲームの進行状況が当該ゲームの勝利条件を満たした場合、当該ユーザに第１報酬よりも価値が低い第２報酬を付与する第２報酬付与手段としてコンピュータを更に機能させてもよい。

上記構成例によれば、ユーザが自身のプレイにおいて勝利条件を満たした場合、より良い報酬が貰えるため、勝利条件達成に向けてのユーザのモチベーションを高めることができる。

（構成１２）
構成１２は、上記構成１１において、第２送信手段は、第２タイミングまでに敗北条件を満たす場合、当該敗北条件を満たしたときまでの進行状況データをサーバに送信してもよい。そして、ゲームプログラムは、第２タイミングまでにゲームの敗北条件を満たす場合、当該ゲームの当該敗北条件を満たしたことに基づく、第１報酬よりも価値が低い第３報酬をユーザに付与する第３報酬付与手段としてコンピュータを更に機能させてもよい。

上記構成例によれば、ゲームに敗北した場合でも、ゲームに参加していれば報酬を貰えるため、ゲームに参加することへのユーザの動機付けを提供できる。

（構成１３）
構成１３は、上記構成１～１２のいずれかにおいて、ゲームプログラムは、第１ゲーム開始手段または第２ゲーム開始手段により開始されるゲームと、当該ゲームとは異なるゲームであって、ユーザキャラクタを育成可能な育成ゲームとを含むゲームアプリケーションをコンピュータに実行させてもよい。そして、第１ゲーム開始手段、および、第２ゲーム開始手段は、育成ゲームにおいて育成されたユーザキャラクタを用いるゲームを開始してもよい。

上記構成例によれば、ユーザが育成ゲームで育てたキャラクタを他ユーザに使ってもらうことができる。また、逆に、他人が育てたキャラクタを自身のプレイにおいて利用できる。これにより、各ユーザが育てたキャラクタをユーザ間で見せ合うような楽しみを提供できる。また、他人が育てたキャラクタを使ってゲームを進めることが可能となり、例えば成長後のキャラクタの性能等を確認し、そのユーザ自身が所有するキャラクタの育成に対するモチベーションを高めることも可能となる。

（構成１４）
構成１４は、上記構成１３において、第２ゲーム開始手段は、他ユーザによって当該ゲームにおいて用いられていた他ユーザキャラクタの数が所定数に達している場合、ユーザのユーザキャラクタをゲームに登場させないで当該ゲームを開始、または、当該他ユーザキャラクタと当該ユーザキャラクタとを交代させて当該ゲームを開始してもよい。

上記構成例によれば、利用（登場）可能なキャラクタの数を所定数以下に抑えることで、数的な制限無しでキャラクタが使えることによってゲームバランスが崩れることを防ぎ、適正なバランスに保つことができる。

（構成１５）
構成１５は、上記構成１において、第１ゲーム開始手段は、複数のユーザキャラクタのうち、ユーザが選択したユーザキャラクタを用いるゲームを開始し、第２ゲーム開始手段は、他ユーザがゲームに用いていた他ユーザキャラクタと、複数のユーザキャラクタのうち当該他ユーザキャラクタとは異なるユーザキャラクタとを用いる当該ゲームを開始してもよい。

上記構成例によれば、同じゲーム内で同一の（重複する）キャラクタが用いられることを防ぐことができる。これにより、例えば強力な性能を有する（同一）キャラクタばかりが登場するようなゲーム展開をなることを防ぎ、性能、個性の異なる様々なキャラクタを用いる機会を増やすことができる。

（構成１６）
構成１６は、第１送信手段は、進行状況データを取得できる他ユーザの範囲をユーザの操作入力に基づいて指定したうえで、当該進行状況データを当該サーバに送信してもよい。

上記構成例によれば、例えば、ある程度ゲームに慣れている人をフレンドとしている場合に、自身がプレイした後に、ゲームがクリアされる可能性を高めることができる。

本開示によれば、複数の情報処理端末間でリアルタイムに通信してゲームの進行状況を同期せずに、複数ユーザ間で協力して同じゲームを進行させることができる。

本実施形態に係る情報処理システムの全体像を示す模式図 サーバ１のハードウェア構成を示すブロック図 ゲーム装置２のハードウェア構成を示すブロック図 ゲーム画面の一例 本実施形態におけるリレーバトルの全体的な通信および処理の流れを示す図 出撃準備画面の一例 ターンの経過と操作可能なユニット数との関係の一例 加勢ポイントおよび加勢可能マスの一例 加勢ポイントおよび加勢可能マスの一例 加勢ポイントおよび加勢可能マスの一例 加勢ポイントおよび加勢可能マスの一例 加勢ポイントおよび加勢可能マスの一例 コメント選択画面の一例 サーバ１の記憶部１２に記憶される各種データの一例を示すメモリマップ リレーバトルデータ５０２のデータ構成の一例 バトルログデータ５１６のデータ構成の一例 ゲーム装置２の記憶部２２に記憶される各種データの一例を示すメモリマップ 自発・引継履歴データ６０７のデータ構成の一例 送信用結果データ６０８のデータ構成の一例 リレーバトル管理処理の詳細を示すフローチャート リレーバトル関連処理の詳細を示すフローチャート リレーバトルメニューの一例 自発バトル処理の詳細を示すフローチャート ＴＢＳＧ処理の詳細を示すフローチャート ＴＢＳＧ処理の詳細を示すフローチャート 引き継ぎバトル処理の詳細を示すフローチャート 引き継ぎバトル処理の詳細を示すフローチャート 進捗確認処理の詳細を示すフローチャート 進捗確認処理の詳細を示すフローチャート

以下、本発明の一実施形態について説明する。図１は、本実施形態に係る情報処理システム（ゲームシステム）の全体像を示す模式図である。本実施形態の情報処理システム１００は、サーバ１と、複数の情報処理端末２とを含む。サーバ１と、情報処理端末２とは、インターネット等のネットワーク１０を介して通信可能に構成されている。本実施形態では、このような構成で、情報処理が実行されるが、以下では、当該情報処理の一例として、ゲーム処理を例として説明する。具体的には、情報処理端末２上にゲームプログラムがインストールされ、必要に応じてサーバ１と通信を行いながら実行されるゲーム処理を例示する。

［サーバのハードウェア構成］
次に、上記サーバ１のハードウェア構成について説明する。図２は、サーバ１のハードウェア構成を示すブロック図である。サーバ１は、プロセッサ１１と、記憶部１２と、通信部１３とを少なくとも備えている。プロセッサ部１１は、サーバ１を制御するための各種プログラムを実行する。記憶部１２には、プロセッサ部１１によって実行される各種プログラムおよび利用される各種データが格納される。通信部１３は、有線、または無線通信によってネットワークと接続し、上記情報処理端末２または他のサーバ（図示せず）との間で所定のデータを送受信する。

［情報処理端末のハードウェア構成］
次に、上記情報処理端末２について説明する。当該情報処理端末２は、例えばスマートフォン、据置型または携帯型のゲーム装置、タブレット端末、携帯電話、パーソナルコンピュータ、ウェアラブル端末等である。また、本実施形態にかかる情報処理は、上記のようなゲーム装置等と、所定のサーバとから構成されるゲームシステムにも適用可能である。本実施形態では、据置型ゲーム装置（以下、単にゲーム装置と呼ぶ）を情報処理端末２の一例として説明する。

図３は、本実施形態に係るゲーム装置２のハードウェア構成の一例を示すブロック図である。図３において、ゲーム装置２は、プロセッサ２１を備える。プロセッサ２１は、ゲーム装置２において実行される各種の情報処理を実行する情報処理部であって、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）のみから構成されてもよいし、ＣＰＵ機能、ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）機能等の複数の機能を含むＳｏＣ（Ｓｙｓｔｅｍ－ｏｎ－ａ－ｃｈｉｐ）から構成されてもよい。プロセッサ２１は、記憶部２２に記憶される情報処理プログラム（例えば、ゲームプログラム）を実行することによって、各種の情報処理を実行する。なお、記憶部２２は、例えば、フラッシュメモリやＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等の内部記憶媒体であってもよいし、図示しないスロットに装着される外部記憶媒体等を利用する構成でもよい。

また、ゲーム装置２は、ゲーム装置２が他のゲーム装置２や所定のサーバ装置と無線通信を行うための無線通信部２３を備える。当該無線通信としては、例えば、インターネット通信や近距離無線通信が用いられる。

また、ゲーム装置２は、ゲーム装置２がコントローラ４と有線または無線通信を行うためのコントローラ通信部２４を備える。

また、ゲーム装置２には、画像音声出力部２５を介して表示部５（例えば、テレビ等）が接続される。プロセッサ２１は、（例えば、上記の情報処理の実行によって）生成した画像や音声を、画像音声出力部２５を介して表示部５に出力する。

次に、コントローラ４について説明する。図示は省略するが、本実施形態のコントローラ４は、縦長の形状のハウジングを有しており、縦長となる向きで把持されることが可能である。当該ハウジングは、縦長となる向きで把持される場合に片手で把持可能な形状および大きさをしている。

コントローラ４は、方向入力デバイスの一例であるアナログスティック４２を少なくとも１つ備える。当該アナログスティック４２は、方向を入力することが可能な方向入力部として用いることができる。ユーザは、アナログスティック４２を傾倒することによって傾倒方向に応じた方向の入力（および、傾倒した角度に応じた大きさの入力）が可能である。また、コントローラ４は、各種操作ボタンを含むボタン部４３を備える。例えば、コントローラ４は、上記ハウジングの主面上に複数個の操作ボタンを備えていてもよい。

また、コントローラ４は、慣性センサー４４を備える。具体的には、コントローラ４は、慣性センサー４４として、加速度センサー、角速度センサーを備えている。本実施形態においては、加速度センサーは、所定の３軸方向に沿った加速度の大きさを検出する。また、角速度センサーは、所定の３軸回りの角速度を検出する。

また、コントローラ４は、上記コントローラ通信部２４と有線または無線通信を行うための通信部４１も備える。上記アナログスティック４２に対する方向入力内容、ボタン部４３の押下状態を示す情報、および、慣性センサー４４による各種の検出結果は、適宜のタイミングで繰り返し通信部４１へ出力され、ゲーム装置２に送信される。

［本実施形態で想定するゲームについて］
次に、本実施形態で実行されるゲーム処理について説明するが、その前提として、本実施形態で想定するゲームの概要を説明する。本実施形態で想定するゲームは、ターン制ストラテジータイプのシミュレーションゲーム（以下、ＴＢＳＧと呼ぶ）である。また、本実施形態では、自軍と敵軍とが１つずつの、合計２つの軍で戦闘が行われるＴＢＳＧを想定する。本ＴＢＳＧでは、シミュレーションゲームにおける駒のことを「ユニット」と呼ぶ。更に、自軍のユニットについては「自軍ユニット」、敵軍となるユニットは「敵軍ユニット」と呼ぶ。

図４に、本ゲームにおける戦闘画面の一例を示す。図４に示すように、本ゲームでは、仮想３次元空間を仮想カメラで撮像したゲーム画像が表示される。また、仮想３次元空間の地面が矩形のマス目で区切られており、ユーザは、各ユニットをマス目単位で移動させることができる。なお、ゲーム空間となる仮想空間は２次元空間であってもよい。また、本ゲームでは、自軍ユニット、敵軍ユニットはそれぞれ人型のキャラクタである。そして、本ゲームは、各ユニットは所定の武器を装備しており、この武器を用いてユニット同士で戦闘を行うＴＢＳＧとなっている。なお、本ゲームでは、自軍ユニットである各キャラクタについては、重複するキャラクタ（同一キャラクタ）は存在しないものとする。すなわち、各キャラクタは「別人」であるものとする。なお、重複するキャラクタの判別は、例えば、キャラクタの名称が同一であるか否かや、キャラクタに割り当てられているＩＤ等の内部データが同一であるか否かで判別してもよい。

［第１ゲームモードについて］
また、本ゲームでは、ユーザが１人でゲームを進めることができる第１ゲームモードと、１つのマップを複数のユーザでプレイ可能な第２ゲームモードがある。第１ゲームモードでは、ユーザは、所定のストーリーに沿ってゲームを進めることができる。また、ユーザは、ストーリーを進めることで、ユーザが所有する自軍ユニットの数を増やすことができる。また、本ゲームにおける自軍ユニットには成長要素があり、第１ゲームモードにおいて、各ユニットを育成することができる。具体的には、個々のユニットには「ユニットレベル」が設けられており、第１ゲームモードにおいて、同じユニットを繰り返し出撃させる等で、経験値を稼ぎ、ユニットレベルを上げていくことができる。ユニットレベルが上がることで、そのユニットの性能も強化・向上する。

［第２ゲームモードについて］
一方、第２ゲームモードは、予め用意された所定のマップについて、複数のユーザがそれぞれ数ターンずつ、同じ「自軍」として、リレー形式でプレイを引き継ぎながらゲームを進めていくというゲームモードである。これは、ＴＢＳＧにおいて、今までに無い新規なマルチプレイをユーザに提供しようとするものである。例えば、ＴＢＳＧにおいて、所定のマップを用いてネットワーク経由でマルチプレイを行おうとした場合、レースゲームや格闘ゲームで通信対戦するときのように、複数のゲーム機をネットワーク経由で接続し、リアルタイムで同期を取りながらの通信プレイを行うことも考えられる。しかし、ＴＢＳＧの場合、一般的に１マップのプレイ時間が比較的長くなると考えられる。また、ＴＢＳＧは自軍フェイズ（手番）と敵軍フェイズとを交互に進めていく形式であることから、敵軍フェイズにおいてはユーザの待ち時間が発生することになる。このような、１マップのプレイ時間の長さや敵軍フェイズにおける待ち時間の存在等も考慮すると、ＴＢＳＧについては、特段の工夫がない場合、リアルタイムでの通信プレイは適さないと考えられる。そこで、本実施形態では、１つのマップについて、自軍のフェイズを所定のターンずつ複数のユーザが別々に操作を担当することで、そのマップのクリアを目指す、という形の（非同期での）協力プレイを提供する（なお、敵軍フェイズはＡＩ制御となる）。つまり、各ユーザは自分が操作を担当するときだけネットワーク接続すればよいことになる。以下、第２ゲームモードにおけるＴＢＳＧのことを「リレーバトル」と呼ぶ。

また、当該リレーバトルでは、上記ユニットは経験値は入手できず、成長させることはできないものとする。換言すれば、第２ゲームモードは、第１ゲームモードで成長させた自軍ユニットを活躍させるための場を提供するようなゲームモードという側面もある。以下、当該リレーバトルの概要について説明する。

なお、以下の説明において、「１ターン」とは、自軍フェイズの１ターンと敵軍フェイズの１ターンとを１セットで捉えたものを意図する。例えば、「１ターン経過」と言うときは、自軍フェイズと敵軍フェイズがそれぞれ１ターンずつ経過したことを指すものとする。

［リレーバトルの全体的な流れについて］
図５は、本実施形態におけるリレーバトルの全体的な通信および処理の流れを示す図である。ここでは、一例として、第１ユーザが操作する第１ゲーム機と、第２ユーザが操作する第２ゲーム機がある場合を想定する。そして、第１ユーザが開始したリレーバトルを第２ユーザが引き継いでプレイするという流れを例示する。なお、以下の説明では、第１ユーザがリレーバトルを開始することを「自発する」と言う。また、自発下ユーザのことを「自発ユーザ」と呼ぶ。また、本実施形態では、各ユーザは同じリレーバトルに対しては１度しか引継ぎ（参加）できないものとする。また、自発したユーザは、そのリレーバトルを自分で引継ぐことはできないものとする。以下の説明では、他ユーザの自発したリレーバトルを引き継いだ各ユーザのことを総称して「引継ユーザ」と呼ぶ。

図５において、まず、プロセスＰ１として、第１ゲーム機で第１ユーザがリレーバトルを自発する。例えば、第１ユーザはリレーバトル用に予め用意されている複数のマップの中から所定のマップを選択する。そして、第１ユーザは、当該マップを使用するリレーバトルの開始を指示する。その後、当該リレーバトルの「出撃準備画面」が表示される。図６に、当該出撃準備画面の一例を示す。出撃準備画面では、今回のリレーバトルで用いられるマップ（表示範囲の変更が可能）と、出撃準備メニューとが表示されている。第１ユーザは、当該画面において所定の操作を行うことで、自身の所有するユニットから、当該リレーバトルに出撃させるユニットを選択し、リレーバトルに係るマップ上に配置する（ユニットが配置できる位置に関しては別途後述する）。なお、本実施形態では、第１ユーザ（自発ユーザ）が出撃させることができるユニットの上限数は５体までであり、第２ユーザ以降（引継ユーザ）が出撃させることができるユニットの上限数は２体までであるとする。他の実施形態では、各ユーザの出撃上限数はこれ以外の値としてもよい。

図５に戻り、次に、プロセスＰ２として、第１ユーザは、既定のターン数だけリレーバトルをプレイする。本実施形態では、既定のターン数は２であるとする。なお、当該既定ターン数は一例であり、他の実施形態では、他の値を用いてもよい。

次に、プロセスＰ３として、第１ゲーム機から、第１ユーザのプレイに係る結果データがサーバに送信される。当該結果データには、各ターンにおける自軍・敵軍ユニットの行動内容や戦闘結果を示すログデータ等が含まれている。換言すれば、当該結果データは、各ユーザのプレイに係るゲームの進行状況を示すデータである。

次に、プロセスＰ４として、サーバにおいて、第１ゲーム機から受信した結果データに基づいて、第１ユーザが自発したリレーバトルに係るリレーバトルデータが新規登録される。

次に、プロセスＰ５として、第２ゲーム機において、第２ユーザがリレーバトルの「引き継ぎ」の指示操作を行う。すなわち、第２ユーザから見て他のユーザが自発したリレーバトルを引き継いでプレイすることを示す操作を行う。これに応じて、第２ゲーム機からサーバに、引き継ぎ可能なリレーバトルのデータの要求が送信される。

次に、プロセスＰ６として、サーバにおいて、第２ゲーム機からの要求に応じて、この時点で引き継ぎ可能なリレーバトルのデータが所定数選択され、第２ゲーム機に送信される。ここでは上記第１ユーザが自発したリレーバトルのデータも、所定数選択されたリレーバトルのデータの中に含まれているものとする。

次に、プロセスＰ７として、第２ゲーム機において、サーバから受信したデータに基づいて引き継ぎ可能なリレーバトルの一覧が提示される。第２ユーザは、このリストから所定のリレーバトルを選択して、そのリレーバトルに係る情報を参照することができる。なお、本実施形態では、当該情報の一つとして、第２ゲーム機において、当該リレーバトルのデータ（上記結果データ）に基づいて、これまでのプレイ内容・ゲームの経過（進行状況）が「リプレイ」として再生される。例えば、第１ユーザのリレーバトルが選択された場合、実際のＴＢＳＧの画面が表示され、１ターン目から順に、第１ユーザが用いた各ユニットの行動や戦闘内容が再現される。これにより、第２ユーザは第１ユーザがどのようにゲームを進めたのかを知ることができる。なお、第１ユーザのような自発ユーザからデータを引き継ぐ場合とは異なり、自発ユーザからデータを引き継いでリレーバトルをプレイした引継ユーザ、または、引継ユーザからデータを引き継いでリレーバトルをプレイした次の引継ユーザがいるようなリレーバトルのように、自身より前にプレイしたユーザ（以下、前任者と総称する）が複数いる場合は、前任者全ての分のプレイ内容が順番にリプレイされる。

次に、プロセスＰ８として、第２ゲーム機において、上記リストから引き継ぐリレーバトルを決定する操作が行われる。ここでは一例として、引継ぎ可能なリレーバトルとして第２ユーザに提示されたもののうち、第１ユーザが自発したリレーバトルが引継ぎ決定されるものとする。この操作に応じて、サーバ１に、引継ぎ決定通知が送信される。

次に、プロセスＰ９として、サーバ１において、第２ユーザのプレイ中は上記第１ユーザが自発したリレーバトルが「引き継ぎ可能」なリレーバトルとして扱われないように、当該リレーバトルに係るデータを一時的にロックする処理が行われる。

次に、プロセスＰ１０として、第２ゲーム機において、出撃準備画面が表示され、第２ユーザは、自身の所有するユニットから、当該リレーバトルに出撃させるユニットを（２体まで）選択および配置する。

次に、プロセスＰ１１として、第２ゲーム機において、第２ユーザは既定ターン数（本例では２ターン）プレイを行う。この際、第２ユーザは、自身が出撃させた自軍ユニットだけでなく、第１ユーザが出撃させた自軍ユニット（以下、前任者ユニット）も操作することができる。例えば、第１ユーザが５体のユニットを出撃させ、第２ユーザは２体だけユニットを出撃させた場合は、第２ユーザは合計７体の自軍ユニットを操作することができる。

次に、プロセスＰ１２として、第２ゲーム機から、第２ユーザのプレイに係る結果データがサーバに送信される。

次に、プロセスＰ１３として、サーバ１において、第２ゲーム機からの結果データが受信される。そして、サーバ１において、当該結果データに基づいて、第１ユーザが自発したリレーバトルのデータが更新される。併せて、当該リレーバトルのデータにかけられていたロックも解除される。これにより、更新後のリレーバトルのデータが引き継ぎ可能なリレーバトルとして扱われるようになる。

これ以降、更に、引継ユーザとして第３のユーザ、第４のユーザ等、他のユーザが参加すれば、各ユーザ毎に上記プロセスＰ５～Ｐ１３の処理が繰り返される。そして、当該リレーバトルに設定されている所定の勝利条件（例えばボスキャラクタの撃破）または敗北条件（例えば自軍の全滅）が満たされることで、当該リレーバトルが終了することになる。そして、リレーバトルが終了すれば、（後述する進捗確認の操作によって）そのリレーバトルの参加者に所定の報酬が付与される。

上記のように、本実施形態のリレーバトルは、ＴＢＳＧにおける自軍の操作を、複数のユーザで既定ターン数毎に引き継ぎながら行うものとなっている。そして、上記のように、当該リレーバトルでは、各ユーザは、前任者ユニットも操作可能である。そのため、ユーザは、引き継ぎタイミング（リレーバトル開始からのターン数）が遅くなるほど、より多くの自軍ユニットを用いたプレイが可能になり得る。図７に、ターンの経過と操作可能なユニット数との関係の一例を示す。図７では、ユーザ１～ユーザ５の５人のユーザが参加したリレーバトルを想定している。また、各ユーザはそれぞれ２ターン分の操作を行っている例である。また、当該マップでは自軍ユニットの出撃上限数が設けられており、その数が１０であるとする。図７において、自発者であるユーザ１は、５体のユニットを出撃させている。そのため、ユーザ１が操作可能なユニットは当該５体のユニットである。次に、この後に引き継いだユーザ２は、２体のユニットを出撃させている。そのため、ユーザ１のユニットと併せて合計７体のユニットが操作可能である。また、この後に引き継いだユーザ３も２体のユニットを出撃させており、ユーザ３は、前任者ユニットを合わせて、合計９体のユニットが操作可能である。

次に、この後ユーザ４がリレーバトルを引き継いだ場合、既に９体のユニットが出撃している（マップ上に存在している）ため、基本的には１体のユニットしか出撃させることができない。但し、出撃上限数が最大に達する場合は、既存のユニットと「交代」させるような形でユーザ４が所有するユニットを更に出撃させることも可能である。図７では、交代の一例として、ユーザ１が出撃させたユニットであるユニット４をユーザ４のユニットに交代させた例を示している（ユーザ４は自身のユニットを合計２体出撃させたことになる）。この結果、ユーザ４は、前任者ユニットと合わせて合計１０体のユニットが操作可能である。

ここで、ユーザ４によるプレイにおいて、ユニット１が敵に撃破された場合を想定する（７ターン目で撃破された場合）。この場合、当該ユニット１はマップ上に存在しなくなり、８ターン目の時点では、自軍ユニットの数は９体となっている。この後、ユーザ４からユーザ５に引き継がれると、ユーザ５は、基本的には１体のユニットしか出撃させることができない。しかし、上記のように、出撃上限数に達した場合は、既存のユニットと「交代」することで、ユーザ５の所有するユニットを更に出撃させることができる。図７の例では、先ほど撃破されたユニット１としてユーザ５が所有のユニットを出撃させると共に、ユニット６として、ユーザ２のユニットと交代させてユーザ５のユニットを出撃させる例を示している。その結果、ユーザ５も、前任者ユニットと合わせて合計１０体のユニットが操作可能となる。

このように、ユーザがリレーバトルを引き継ぐ際に、各引継ユーザは、自身の所有するユニットを、マップ毎に設けられている出撃上限数を超えない範囲で（２体まで）出撃させることができる。そのため、ユーザは、自身のプレイスタイルなどに応じて、リレーバトルが自発されてから早い段階で参加（引き継ぎ）するという楽しみ方と、ある程度ターンが経過した段階で参加する楽しみ方との２つの楽しみ方を選ぶことも可能となる。前者の場合は、操作対象となるユニット数が少ないため、ゲームプレイに費やす時間も少なく、気軽に参加することも可能である。そのため、例えばじっくりゲームをプレイする時間が取りにくいユーザは、早い段階で参加して手早く（自分担当分の）ゲームを終わらせ、その後クリア報酬を待つ、というプレイができる。一方、じっくりゲームをプレイする時間があるユーザや、ＴＢＳＧに慣れているユーザ等は、あえて遅い段階のリレーバトルに参加することもできる。これにより、より多数のユニットを操作できるため、じっくりとゲームを楽しむ（操作可能ユニット数が多い方が、ゲームの戦略性もより高まる）ことができる。更には、自身のプレイ中にマップの勝利条件を満たすことで、そのリレーバトルをクリアし、前任者から感謝されることを期待する、という楽しみ方もできる。特に、本実施形態では上記のように各ユニットには成長要素がある。そのため、初心者が自発したリレーバトル（ユニットレベルが低く、クリアが困難な戦況）に対して、複数の上級者が引き継ぎに際して高レベルユニットを出撃させていくことで、戦況が覆り、クリアまでこじつける、ということも可能となる。このように、本実施形態のリレーバトルでは、ユーザのプレイスタイルに応じた異なる楽しみ方を提供することも可能となっている。

［リレーバトルに関する各種の処理概要について］
また、本実施形態のリレーバトルでは、更に、以下に示すような各種の制御も行うことで、ユーザの利便性やゲームの興趣性を向上させている。

［自発または引き継ぎ後の進捗確認機能］
まず、本実施形態では、ユーザが自発または引き継ぎしてプレイし終えた後のゲームの進捗状況を確認することができる。例えば、リレーバトルを自発した自発ユーザであれば、自分のプレイが終わった後、「進捗確認」のための所定の操作を行うことで、その時点でのリレーバトルのデータをサーバから取得し、その時点までのリプレイが再生される。これにより、自発ユーザは、自分が自発したリレーバトルがその後どうなっているのかを確認できる。例えば、引継ぎユーザがいる場合は、当該自発ユーザのプレイに係るリプレイに続けて、引継ユーザそれぞれのリプレイが順番に再生される。また、ユーザ自身が引継ユーザとなった場合も同様である。すなわち、自発ユーザの分のリプレイに続けて、自身を含む引継ユーザのリプレイが順番に再生されていくことになる。これにより、自身のプレイ後の進捗が確認できると共に、他のユーザのプレイを確認することもできるため、他のユーザの戦い方を参考にして今後のプレイに活かすことも可能である。なお、自発ユーザが進捗確認の操作を行った時点で、まだ他のユーザに引き継がれていない場合は、自発ユーザの分のリプレイのみが再生されることになる。更に、進捗確認した結果、勝利条件または敗北条件が満たされてリレーバトルが終了していた場合は、所定の報酬が、当該進捗確認を行ったユーザに付与される。

［加勢ポイントについて］
次に、自軍ユニットの配置位置（出撃位置）に関して説明する。まず、自発ユーザが自軍ユニットを配置する位置（初期配置位置）については、リレーバトルに用いるマップ毎に予め決められている。自発ユーザは、当該決められた初期配置位置のいずれかに自軍ユニットを配置できる。一方、引継ユーザが自軍ユニットを配置可能な位置は、「加勢ポイント」が設定されているマス、および、これに隣接する周囲の４マスとなる。以下、これらのマスのことを総称して「加勢可能マス」と呼ぶ。図８に、加勢ポイントおよび加勢可能マスの一例を示す。また、図８は、本実施形態のＴＢＳＧに係る仮想空間の一部を俯瞰したものを示す模式図である。図８では、丸印で示される加勢ポイントが４カ所、設定されている。当該加勢ポイントは、マップ毎にその位置が予め設定されている。また、当該加勢ポイントは、「アクティブ」と「非アクティブ」のいずれかの状態に設定される。リレーバトル開始直後は、複数の加勢ポイントのうち一部だけアクティブであり、残りは非アクティブ、というような状態である。図８では、アクティブな加勢ポイントのほうを黒色で示しており、アクティブな加勢ポイントが２カ所、非アクティブな加勢ポイントも２カ所ある状態を示している。そして、ゲームを進め、図９に示すように、自軍ユニットが非アクティブの加勢ポイントのあるマスに移動して「待機」（行動終了）することで、加勢ポイントの状態が非アクティブからアクティブに変化する。自軍ユニットが配置できるのは、この「アクティブ」な加勢ポイントのマスと、これに隣接する周囲の４マスとなる。

このような加勢ポイントを設けているのは、ゲームの状況（リレーバトルのゲームの進行度合い）に応じて、出撃可能位置を変化（拡張）させるためである。例えば、上記図８において、仮に、加勢ポイントが４つあるうちの左下の１つだけだったと仮定する。そして、ゲームが進行して戦いの前線が図８でいう上端付近となっている場合を想定する。この場合、引き継ぎでリレーバトルを開始した際に、自軍ユニットを前線に投入することが難しい場合がある。例えば、自軍ユニットを左下の加勢ポイントの位置に出撃させても、そのユーザのプレイ中（例えば２ターン分のプレイ）には自軍ユニットが前線となっている位置に移動しきれない場合もあり得る。その一方で、例えば図８の４つの加勢ポイントが全てゲームの初期段階から利用可能とすると、リレーバトルの開始からまだ間もない時点で、引継ぎユーザが例えば敵軍の大将キャラクタ（ボスキャラクタ）の近く等に自軍ユニットを配置することも可能となる。その結果、ゲームバランス等の観点から好ましくない展開にもなり得ることも考えられる。そこで、本実施形態では、ある程度離して配置された複数の加勢ポイントを用意し、ゲームの進行につれてアクティブな加勢ポイントを徐々に増やしていくことが可能なように構成している。これにより、ゲームバランスを適正なものにできる。例えば、リレーバトルの序盤からボスキャラクタに攻撃ができてしまうような展開を避け、徐々に前線を押し上げていくようなゲーム展開にすることができる。また、ある程度進行したゲームを引き継いだユーザも、前線近くの加勢ポイントがアクティブになっていれば、自身の所有するユニットを速やかに前線に送ることが可能となり、自身が出撃させたユニットを前線で戦わせる等で、リレーバトルを十分に楽しませることができる。

［引継ぎユーザの配置操作について］
次に、引継ぎユーザが自身の所有するユニットを配置する場合の具体例を説明する。まず、出撃準備画面において、引継ぎユーザが出撃させるユニット（以下、加勢ユニットと呼ぶ）を選択すると、一旦、空いている加勢可能マスのいずれかに自動的に配置される（例えば図１０参照）。その後、ユーザの操作に基づき、空いている加勢可能マスの間で配置位置を手動で変更できる（図１１参照）。そして、出撃指示をユーザが行うと、加勢ユニットが最初からマップ上（所定の加勢可能マス上）に配置された状態で、自軍フェイズが開始することになる。この点につき、他の実施形態では、出撃準備画面の段階では、マップ上への加勢ユニットの実際の配置は行わずに、出撃させるユニットを指定するだけとしてもよい。そして、今回のプレイにおける最初の自軍フェイズの開始直後（出撃指示の直後）に実際の配置が行われてもよい。あるいは、最初の自軍フェイズの開始直後のタイミングではなく、２ターン目の自軍フェイズになった時点等、数ターン経過後に配置を行うようにしてもよい。また、更に他の実施形態では、出現するタイミング（ターン）をユーザが指定できるようにしてもよい。これにより、出現させるタイミングを戦略に含めてユーザに考えさせることができ、ゲームの戦略性をより向上できる。

ここで、加勢可能マスに他のユニットが存在している場合は、その加勢可能マスは空いていない（埋まっている）ものとして扱われ、そのマスには加勢ユニットは配置できない。例えば、図１２に示すように、５つの加勢可能マスのうち４つが埋まっている場合は、引継ぎユーザは、例えば５体まで自身の所有ユニットを出撃させることが可能であっても、１体しか加勢ユニットを出撃させることができないことになる。また、仮に全ての加勢可能マスが埋まっている場合は、引継ユーザは自身が所有する自軍ユニットを加勢ユニットとして出撃させることができないことになる（前任者ユニットのみ用いてプレイすることになる）。

次に、上記「交代」に関して補足する。上記のように、マップ上の自軍ユニットが出撃上限数に達した場合は、「交代」によって既存の自軍ユニットを引継ぎユーザのユニットと入れ替えることができる。この際、交代するユニットの出現位置（配置位置）は、空いている加勢可能マスのいずれかとなる。例えば前任者ユニットＡと加勢ユニットＢとを交代する場合は、前任者ユニットＡのいるマスに加勢ユニットＢが出現するのではなく、空いている加勢可能マスに加勢ユニットＢが出現する。そのため、加勢可能マスがすべて埋まっている場合、交代する加勢ユニットＢを出現させるマスがないため、この場合は「交代」はできないことになる。

また、「交代」が実際に行われるタイミングについても補足する。本実施形態では、出撃準備画面においては交代するユニットを指定するだけであり、実際に交代が行われるのは、出撃して最初の自軍フェイズが開始した直後に行われるものとする。この点、他の実施形態では、例えば出撃後２ターン目等の、出撃直後以外のタイミングで「交代」が行われてもよい。

また、本実施形態では、上記のようにユニットは人型のキャラクタであり、重複するキャラクタは存在しない。そのため、引継ユーザが所有しているユニットであっても、既にマップ上に存在しているキャラクタと同一キャラクタについては出撃させることはできないものとする。この点、他の実施形態では、同一キャラクタについては、上記「交代」によって出撃可能としてもよい。すなわち、他のユーザのキャラクタと、これと同一である、自身の所有キャラクタと入れ替えることは可能としてもよい。

［コメント機能について］
次に、コメント機能について説明する。本実施形態に係るリレーバトルでは、各ユーザが各自のプレイを終了した際に、後に引き継いでくれるユーザ（または引き継ぐ可能性のあるユーザ）に向けてコメントを残すことができる。そして、引継ユーザは、それまでにプレイしたユーザ（以下、前任者）からのコメントを見ることができる。具体的には、実際にプレイを開始する前の、上記リプレイの再生が終了したタイミングで、当該コメントが表示される。ここで、本実施形態では、当該コメントは、予め用意された定型文から選択できる（換言すれば、ユーザは自由にはコメント入力できない）。具体的には、各ユーザが、既定のターン数のプレイを終了した後に、例えば図１３に示すようなコメント選択画面が表示される。当該コメント選択画面では、複数の定型文が、選択肢としてユーザに提示される。そして、ユーザが、この中から所定の定型文を選択することで、その選択結果を含む上記結果データがサーバに送信される。

なお、上記コメントを表示するタイミングは一例であり、他の実施形態では、リプレイに併せて表示することに限らない。例えば、引継ユーザが出撃したタイミング（引継ユーザの最初の自軍フェイズの開始時）で、前任者のコメントをまとめて表示するようにしてもよい。あるいは、リレーバトルの情報を提示するときの各種情報の一つとして、当該コメントを表示するようにしてもよい。

また、他の実施形態では、コメントとして設定する内容について、上記の定型文の他、複数の所定の画像（アイコンやスタンプ画像）を選択肢として提示し、定型文と組み合わせてユーザが選択可能としてもよい。

［報酬について］
次に、上述した、リレーバトルの終了に伴う報酬に関して補足する。本実施形態では、リレーバトルが終了することで、そのリレーバトルに参加したユーザ全員に報酬が付与される。この報酬のグレードは、勝利条件を満たして終了した場合（つまり、勝利した場合）と、敗北条件を満たして終了した場合（つまり、敗北した場合）とで異なるものとなっている。具体的には、勝利した場合のほうが、敗北した場合よりもグレードの高い報酬が付与される。なお、具体的な報酬内容の決定は抽選によって行われてもよい。例えば、勝利報酬については、敗北報酬よりもグレードの高いアイテムのグループから抽選で決定してもよい。また、報酬自体のグレードを異ならせるほか、報酬を付与する数や量を異ならせるようにしてもよい。例えば、報酬自体は同じアイテムやゲーム内通貨であっても、勝利報酬のほうが敗北報酬よりも数や量が多くなるようにしてもよい。また、敗北報酬の内容に関しては、抽選で決定する他、参加者全員に一律に同じ内容の報酬を付与してもよい。このように、勝利報酬、敗北報酬の双方を用意することで、リレーバトルへの積極的な参加を促すことができ、リレーバトルに誰も参加せずに放置されるという状況を起こりにくくすることができる。

また、勝利報酬については、更に、自身の担当したプレイにおいて勝利条件を満たしたユーザと、自身のプレイでは勝利条件は満たせなかったユーザとで、その報酬のグレードが異なっている。本実施形態では、自身の担当したプレイにおいて勝利条件を満たしたユーザには、他のユーザよりもグレードの高い報酬が付与される。つまり、最終的に勝利条件を確定したユーザはより良い報酬を貰えることになる。これにより、自身の手で勝利条件を達成するということの動機付けをユーザに提供できる。すなわち、ある程度ゲームが進行した状態のリレーバトル（戦力や戦局が整い、勝利条件を満たせる可能性が高くなっていると考えられる）に積極的に参加することへの動機付けをユーザに提供できる。

［本実施形態のゲーム処理の詳細］
次に、図１４～図２８を参照して、本実施形態におけるゲーム処理についてより詳細に説明する。

［使用データについて］
まず、本実施形態で用いられる各種データに関して説明する。ここでは、先に、サーバ１で用いられるデータについて説明し、その後、ゲーム装置２で用いられるデータについて説明する。

［サーバ１に記憶されるデータについて］
図１４は、サーバ１の記憶部１２に記憶される各種データの一例を示すメモリマップである。記憶部１２には、管理用プログラム５０１、リレーバトルデータ５０２等が記憶されている。

管理用プログラム５０１は、本実施形態に係るゲーム処理においてサーバが担当する各種機能を実現させるためのプログラムである。具体的には、後述する図２０のフローチャートに係る処理を実行するためのプログラムである。

リレーバトルデータ５０２は、サーバ１において上記リレーバトルを管理するためのデータベースである、図１５に、リレーバトルデータ５０２のデータ構成の一例を示す。リレーバトルデータ５０２は、図１５に示すように、リレーバトルデータ５０２は、バトルＩＤ５１１、最終更新日時５１２、マップＩＤ５１３、ロックフラグ５１４、終了フラグ５１５、バトルログデータ５１６の項目を少なくとも含むレコードの集合で構成されるデータベースである。

バトルＩＤ５１１は、各リレーバトルを一意に識別するためのＩＤである。最終更新日時５１２は、そのレコードの最終更新日時を示す情報である。マップＩＤ５１３は、そのレコードに係るリレーバトルで用いられているマップを特定するための情報である。本実施形態では、リレーバトル用のマップが数種類予め用意されているため、これらのいずれかを特定するＩＤがマップＩＤ５１３として記憶される。

ロックフラグ５１４は、そのレコードに係るリレーバトルが所定のユーザによってプレイされている状態か否かを示すフラグである。ロックフラグ５１４がオンの場合は、所定のユーザによってプレイされている状態であることを示す。ロックフラグ５１４の初期値はオフであるとする。終了フラグ５１５は、そのレコードに係るリレーバトルが終了条件を満たしたものであるか否かを示すフラグである。終了フラグ５１５がオフの場合は、そのリレーバトルはまだ終了条件を満たしておらず、引継ぎ可能なリレーバトルとして選択され得ることをしめす。終了フラグ５１５がオンの場合は、そのリレーバトルは終了しているため、引継ぎ可能なリレーバトルとしては選択されないことになる。また、終了フラグ５１５の初期値はオフであるとする。

バトルログデータ５１６は、そのレコードに係るリレーバトルにおけるプレイ内容（進行状況）を示すデータである。また、バトルログデータ５１６は、各ゲーム装置２から送信される上記結果データの集合でもある。図１６に、バトルログデータ５１６のデータ構成の一例を示す。バトルログデータ５１６は、ユーザＩＤ５２１、結果データ５２２、登録日時５２３の項目を少なくとも含むレコードの集合で構成されるデータベースである。結果データ５２２は、各ユーザのプレイ内容等を示すデータであり、ゲーム装置２から送信された、後述の送信用結果データ６０８を記憶したものである。ユーザＩＤ５２１は、当該結果データ５２２を送信したユーザを特定するためのＩＤであり、登録日時５２３は、そのレコード（結果データ５２２）の登録日時である。

その他、図示は省略するが、ゲーム装置２に送信するための各種データ等も必要に応じて適宜生成され、記憶部１２に記憶され得る。また、ゲーム装置２から受信した各種データも一時的に記憶部１２に記憶され得る。

［ゲーム装置２に記憶されるデータについて］
次に、ゲーム装置２に記憶されるデータについて説明する。図１７は、ゲーム装置２の記憶部２２に記憶される各種データの一例を示すメモリマップである。ゲーム装置２の記憶部２２には、ゲームプログラム６０１、マップマスタデータ６０２、ユニットマスタデータ６０３、所有ユニットデータ６０４、コメントマスタデータ６０５、リレーバトル管理データ６０６、操作データ６１１等が記憶されている。

ゲームプログラム６０１は、本実施形態に係るゲーム処理を実行するためのプログラムである。具体的には、後述する図２１のフローチャートにかかる処理を実行するためのプログラムである。

マップマスタデータ６０２は、上記第１ゲームモードで用いられるＴＢＳＧのマップと、第２ゲームモードで用いられるＴＢＳＧのマップの構成を定義したデータである。具体的には、各マップの大きさ（マスの数）、各マスの地形を示す情報やその外観、地形効果等、マップを構築するための各種情報が含まれている。その他、マップマスタデータ６０２には、各マップにおける勝利条件や敗北条件を定義した情報等も含まれている。

ユニットマスタデータ６０３は、本ゲームに登場する全ての自軍ユニットについて定義したデータである。ユニットマスタデータ６０３には、例えば、各ユニット毎に、ユニットＩＤ、キャラクタ名称、各種ステータス情報、ユニットレベル、外観を示す情報等が定義されている。

所有ユニットデータ６０４は、ユーザが所有しているユニットを示すデータである。

コメントマスタデータ６０５は、上述したようなコメントとして用いられる定型文を複数記録したデータである。

リレーバトル管理データ６０６は、ゲーム装置２においてリレーバトルに係る処理を実行する際に用いられるデータである。リレーバトル管理データ６０６には、自発・引継履歴データ６０７、送信用結果データ６０８、受信バトルログデータ６０９、ＴＢＳＧ処理用データ６１０が少なくとも含まれる。

自発・引継履歴データ６０７は、ユーザが自発したリレーバトル、および、引き継ぎした（参加した）リレーバトルの履歴を示すデータである。図１８は、自発・引継履歴データ６０７のデータ構成の一例である。自発・引継履歴データ６０７は、履歴番号６２１、日時データ６２２、バトルＩＤ６２３、報酬フラグ６２４の項目を少なくとも含むレコードの集合で構成されるデータベースである。履歴番号６２１は、各レコードを一意に識別するためのＩＤである。日時データ６２２は、リレーバトルを自発または引き継ぎした日時を示すデータである。バトルＩＤ６２３は、自発または引き継ぎしたリレーバトルを特定するための情報であり、上記リレーバトルデータ５０２のバトルＩＤ５１１に対応する情報である。報酬フラグ６２４は、そのリレーバトルについての報酬が付与済みか否かを示すフラグであり、付与済みであればオンが、未付与の場合はオフが設定される。

図１７に戻り、次に、送信用結果データ６０８は、サーバ１に送信するためのデータであり、そのゲーム装置２でユーザによって進行されたＴＢＳＧのプレイ内容を示すデータである。当該送信用結果データ６０８（の少なくとも一部）が、上記バトルログデータ５１６の結果データ５２２としてサーバ１に記憶されることになる。図１９に、送信用結果データ６０８のデータ構成の一例を示す。送信用結果データ６０８には、ユーザ情報６３１、バトルＩＤ６３２、ＴＢＳＧログデータ６３３、指定コメントデータ６３４が少なくとも含まれる。ユーザ情報６３１は、当該送信用結果データ６０８を送信したユーザを特定するための情報である。バトルＩＤ６３２は、ユーザが自発または引き継ぎしたリレーバトルを特定するための情報であり、上記リレーバトルデータ５０２のバトルＩＤ５１１に対応する情報でもある。ＴＢＳＧログデータ６３３は、ＴＢＳＧにおけるプレイ内容を示すデータである。例えば、そのユーザが担当したターンを示す情報や、ユーザの操作内容、各ユニットの行動内容、戦闘の結果等を示す情報が含まれる。指定コメントデータ６３４は、ユーザが選択した上記コメントを特定するための情報である。その他、送信用結果データ６０８には、リレーバトルに使用しているマップを特定する情報や、送信日時等を示す情報も含まれ得る。

図１７に戻り、次に、受信バトルログデータ６０９は、サーバ１から受信した上記バトルログデータ５１６を記憶したものである。

ＴＢＳＧ処理用データ６１０は、ゲーム装置２でリレーバトルに係るＴＢＳＧの処理を行う際に用いられるデータである。当該データは、マップ上における各ユニットの位置や、各ユニットの状態を管理するためのユニットリストデータ等が含まれる。なお、当該ユニットリストデータの生成に関して、リレーバトルを引き継いでプレイする場合は、受信バトルログデータ６０９に基づいて既存のユニットの位置等が決定されることになる。

次に、操作データ６１１は、プレイヤがコントローラ４に対して行った操作内容を示すデータである。所定の時間間隔でコントローラ４からプロセッサ２１に送信されるデータであり、各種ボタンの押下状態を示す情報やアナログスティックに対する入力内容を示す情報等が含まれている。

その他、図示は省略するが、ユーザが所有するアイテム等のデータや、上記第１ゲームモードに関するデータ等、ゲーム処理に必要な各種データも記憶部２２に記憶される。

次に、本実施形態におけるゲーム処理の詳細を説明する。ここでは先にサーバ１に関する処理を説明し、その後、ゲーム装置２に関する処理を説明する。なお、本実施形態では、１以上のプロセッサが１以上のメモリに記憶された上記プログラムを読み込んで実行することにより、以下に示すフローチャートが実現される。また、当該フローチャートは、処理過程の単なる一例にすぎない。そのため、同様の結果が得られるのであれば、各ステップの処理順序を入れ替えてもよい。また、変数の値や、判定ステップで利用される閾値も、単なる一例であり、必要に応じて他の値を採用してもよい。

［サーバ１で実行される処理について］
図２０は、サーバ１で実行されるリレーバトル管理処理の詳細を示すフローチャートである。図２０において、まず、ステップＳ１で、サーバ１のプロセッサ１１は、所定のゲーム装置２から、上記送信用結果データ６０８を受信したか否かを判定する。当該判定の結果、受信した場合は（ステップＳ１でＹＥＳ）、ステップＳ２で、プロセッサ１１は、受信したデータに基づいてリレーバトルデータ５０２を更新する。具体的には、プロセッサ１１は、受信した送信用結果データ６０８が自発されたリレーバトルに係るものであれば、当該受信したデータに基づき、そのリレーバトルに係る新たなレコードを生成してリレーバトルデータ５０２に新規登録する。なお、本実施形態では、リレーバトルが自発された場合は、ゲーム装置２側でバトルＩＤが生成され、これが送信用結果データに含まれるものとする。またこの際、ゲーム装置毎に固有の端末固有番号やユーザＩＤ等を用いて、一意なＩＤとなるようにバトルＩＤが生成されるものとする。そのため、サーバ１は、当該バトルＩＤがリレーバトルデータ５０２に存在していない場合は、自発されたリレーバトルに係る結果データであると判定することができる。一方、受信した送信用結果データ６０８が引き継ぎされたリレーバトルに係るものであれば、当該受信したデータに基づき、リレーバトルデータ５０２の内容が更新される。具体的には、プロセッサ１１は、当該受信したデータに基づきバトルＩＤ５１１を特定する。そして、プロセッサ１１は、当該特定したバトルＩＤ５１１に係るリレーバトルのバトルログデータ５１６に、当該受信したデータに基づいた新たなレコードを追加する。また、プロセッサ１１は、当該送信用結果データ６０８に基づき、リレーバトルが終了したか否か（勝利条件または敗北条件が満たされたか）を判定し、終了している場合は、終了フラグ５１５にオンを設定する。更に、プロセッサ１１は、受信した送信用結果データ６０８に対応するリレーバトルがロックされている場合は、そのロックを解除する。すなわち、プロセッサ１１は、ロックフラグ５１４にオフを設定する。

一方、ステップＳ１の判定の結果、送信用結果データ６０８を受信していない場合は（ステップＳ１でＮＯ）、上記ステップＳ２の処理はスキップされる。

次に、ステップＳ３で、プロセッサ１１は、所定のゲーム装置２から、引き継ぎ可能なリレーバトルのデータ要求（リクエスト）を受信したか否かを判定する。当該判定の結果、当該要求を受信した場合は（ステップＳ３でＹＥＳ）、ステップＳ４で、プロセッサ１１は、リレーバトルデータ５０２を参照し、上記終了フラグ５１５がオフであるリレーバトル（引き継ぎ可能なリレーバトル）を所定数選択する。なお、選択手法はどのようなものでもよい。そして、選択したリレーバトルに係るデータを上記要求の送信元のゲーム装置２に送信する。

一方、ステップＳ３の判定の結果、引き継ぎ可能なリレーバトルのデータ要求を受信していない場合は（ステップＳ３でＮＯ）、上記ステップＳ４の処理はスキップされる。

次に、ステップＳ５で、プロセッサ１１は、所定のゲーム装置２から、引継ぎ決定通知を受信したか否かを判定する。当該通知は、所定のユーザが所定のリレーバトルを引き継ぐことを決定する操作によって、所定のゲーム装置から送信されてくる通知である。当該判定の結果、引継ぎ決定通知を受診していない場合は（ステップＳ５でＮＯ）、後述のステップＳ９に処理が進められる。一方、引継ぎ決定通知を受信した場合は（ステップＳ５でＹＥＳ）、次に、ステップＳ６で、プロセッサ１１は、当該通知において引き継ぎ対象として指定されているリレーバトルが、現在ロックされているか否かを上記ロックフラグ５１４に基づいて判定する。これは、例えば、別々のユーザがほぼ同じタイミングでリレーバトルの引継ぎ決定を行った場合を想定したものである。また、例えば、あるユーザが所定のリレーバトルに係る情報を確認（リプレイ視聴等）している間に、他のユーザが当該リレーバトルの引継ぎを決定した場合を想定したものである。当該判定の結果、ロックされている場合は（ステップＳ６でＹＥＳ）、ステップＳ７で、プロセッサ１１は、引継ぎ不可通知を、上記引継ぎ決定通知の送信元に送信する。その後、後述のステップＳ９に処理が進められる。

一方、ロックされていない場合は（ステップＳ６でＮＯ）、ステップＳ８で、プロセッサ１１は、引継ぎ決定通知で指定されているリレーバトルに係る上記ロックフラグ５１４にオンを設定する。更に、プロセッサ１１は、引継ぎ可能通知を上記引継ぎ決定通知の送信元に送信する。

次に、ステップＳ９で、プロセッサ１１は、所定のゲーム装置２から、進捗確認要求を受信したか否かを判定する。当該進捗確認要求は、上述したような進捗確認のためのデータの要求である。当該判定の結果、当該進捗確認要求を受信した場合は（ステップＳ９でＹＥＳ）、ステップＳ１０で、プロセッサ１１は、当該進捗確認要求で指定されているリレーバトルに係るデータをリレーバトルデータ５０２から取得する。そして、プロセッサ１１は、当該データを上記要求の送信元のゲーム装置２に送信する。その後、上記ステップＳ１に戻り、処理が繰り返される。

一方、ステップＳ９の判定の結果、進捗確認要求を受信していない場合は（ステップＳ９でＮＯ）、上記ステップＳ１０の処理はスキップされる。

以上で、サーバ１で実行される処理の説明を終了する。

［ゲーム装置２で実行される処理について］
次に、ゲーム装置２で実行される処理について説明する。ここでは、上記リレーバトルに関する処理（リレーバトル関連処理）についてのみ説明し、その他のゲーム処理についての説明は割愛する。

図２１は、ゲーム装置２で実行されるリレーバトル関連処理の詳細を示すフローチャートである。まず、ステップＳ２１で、ゲーム装置２のプロセッサ２１は、例えば図２２に示すようなリレーバトルメニューを表示する。

次に、ステップＳ２２で、プロセッサ２１は、操作データ６１１を取得する。続くステップＳ２３で、プロセッサ２１は、操作データ６１１に基づき、リレーバトルメニューにおいて、リレーバトルを自発する操作が行われたか否かを判定する。当該判定の結果、自発操作が行われた場合は（ステップＳ２３でＹＥＳ）、ステップＳ２４で、プロセッサ２１は、自発バトル処理を実行する。

図２３は、自発バトル処理の詳細を示すフローチャートである。まず、ステップＳ３１で、プロセッサ２１は、マップマスタデータ６０２に基づき、リレーバトル用として指定されているマップを一覧表示したマップ選択画面を表示する。

次に、ステップＳ３２で、プロセッサ２１は、操作データ６１１を取得する。続くステップＳ３３で、プロセッサ２１は、操作データ６１１に基づき、いずれかのマップが選択されたか否かを判定する。選択されていない場合は（ステップＳ３３でＮＯ）、上記ステップＳ３１に戻り処理が繰り返される。

一方、いずれかのマップが選択された場合は（ステップＳ３３でＹＥＳ）、ステップＳ３４で、プロセッサ２１は、当該選択されたマップを用いるＴＢＳＧ処理を実行する。図２４～図２５は、当該ＴＢＳＧ処理の詳細を示すフローチャートである。まず、ステップＳ４１で、プロセッサ２１は、当該選択されたマップのデータをマップマスタデータ６０２から読み込み、これに基づいて出撃準備画面（図示は省略）を生成して表示する。この際、引き継ぎでプレイする場合は、受信バトルログデータ６０９に基づき、引き継いだときの戦況（自軍、敵軍ユニットの位置等）を反映した出撃準備画面が生成される。

次に、ステップＳ４２で、プロセッサ２１は、操作データ６１１を取得する。更に、プロセッサ２１は、操作データ６１１で示される操作内容に基づいて、出撃準備にかかる各種処理を実行する。具体的には、出撃させるユニットを決定する処理や、その配置位置を決定する処理等が実行される。なお、配置位置に関しては、上述したように、一旦加勢可能マスに自動的に配置され、その後、ユーザの操作に基づき配置位置が変更され得る。

次に、ステップＳ４３で、プロセッサ２１は、操作データ６１１に基づき、出撃準備画面において出撃指示が行われたか否かを判定する。出撃指示が行われていない場合は（ステップＳ４３でＮＯ）、上記ステップＳ４１に戻り、処理が繰り返される。

一方、出撃指示が行われた場合は（ステップＳ４３でＹＥＳ）、ステップＳ４４で、プロセッサ２１は、出撃準備画面を終了し、ＴＢＳＧに係る画面（上記図４参照）を表示する。この際、自発の場合は、自軍、敵軍ユニットは予め設定されている初期配置位置に配置された画面（出撃準備画面での操作内容を反映した画面）が表示される。一方、引き継ぎの場合は、引き継いだ時点の戦況（自軍、敵軍ユニットの位置等）を受信バトルログデータ６０９に基づいて反映した内容に、上記出撃準備画面での操作内容を更に反映した画面が表示される。

次に、ステップＳ４５で、プロセッサ２１は、操作データ６１１を取得し、その操作内容に基づいて、自軍フェイズの処理を実行する。具体的には、プロセッサ２１は、操作データ６１１に基づいて自軍ユニットを移動させる処理や、所定の敵軍ユニットと戦闘させる処理等を実行する。また、プロセッサ２１は、後に送信用結果データ６０８を作成するために、自軍フェイズにおけるユーザの操作内容や自軍ユニットの行動内容（操作ログ、行動ログ）等を一時的に記憶部２２に記憶しておく。また、プロセッサ２１は、上記の操作内容に基づく処理を反映したゲーム画面（戦闘シーン等）も適宜生成して表示する。

次に、ステップＳ４６で、プロセッサ２１は、現在プレイ中のマップに設定されている終了条件（勝利条件または敗北条件）が満たされたか否かを判定する。終了条件が満たされていない場合は（ステップＳ４６でＮＯ）、ステップＳ４７で、プロセッサ２１は、敵軍フェイズの処理を実行する。具体的には、プロセッサ２１は、ＡＩ制御によって、敵軍ユニットを行動させる。また、プロセッサ２１は、後に送信用結果データ６０８を作成するために、敵軍フェイズにおける敵軍ユニットの行動内容等を一時的に記憶部２２に記憶しておく。

次に、ステップＳ４８で、プロセッサ２１は、上記終了条件が満たされたか否かを判定する。終了条件が満たされていない場合は（ステップＳ４８でＮＯ）、ステップＳ４９で、プロセッサ２１は、今回のプレイが開始してから既定のターン数が経過したか否かを判定する。本実施形態では既定のターン数が２である場合を例としているため、自発ユーザまたは引継ユーザがそれぞれプレイを開始してから２ターン分のプレイが終了したか否かが判定される。当該判定の結果、既定のターン数が経過していない場合は（ステップＳ４９でＮＯ）、上記ステップＳ４４に戻り、処理が繰り返される。一方、既定のターン数が経過した場合は（ステップＳ４９でＹＥＳ）、後述するステップＳ５１に処理が進められる。

一方、上記ステップＳ４６、またはステップＳ４８の判定の結果、終了条件を満たしたと判定された場合は（ステップＳ４６、またはステップＳ４８でＹＥＳ）、ステップＳ５０で、プロセッサ２１は、当該終了条件を満たしたユーザに、プレイの結果に応じた所定の報酬を付与する。具体的には、当該ユーザが所有するアイテムを示すデータが更新されることになる。なお、プレイの結果に応じた報酬、すなわち、付与される報酬のグレードについては上述の通りである。その後、後述のステップＳ５１に処理が進められる。

次に、図２５のステップＳ５１で、プロセッサ２１は、ＴＢＳＧの画面を終了し、コメント選択画面（上記図１３参照）を表示する。次に、ステップＳ５２で、プロセッサ２１は、操作データ６１１を取得し、その操作内容に基づいて、コメント選択画面から所定のコメントを選択する。

次に、ステップＳ５３で、プロセッサ２１は、上記送信用結果データ６０８を生成して、サーバ１に送信する。具体的には、プロセッサ２１は、上記ステップＳ４５、Ｓ４７において一時的に記録したデータに基づき、自軍フェイズおよび敵軍フェイズにおける各ユニットの行動内容やユーザの操作内容等を示すＴＢＳＧログデータ６３３を生成する。なお、今回のプレイにおいて終了条件を満たした場合も、その終了条件に至るまでのプレイ内容を示すデータがＴＢＳＧログデータ６３３として生成されることになる。更に、プロセッサ２１は、上記選択されたコメントに基づいて指定コメントデータ６３４も生成する。また、今回のＴＢＳＧのプレイが自発である場合は、プロセッサ２１は、例えば端末固有番号やユーザＩＤを用いて（一意なＩＤとなるように）バトルＩＤ６３２を生成する。一方、引き継ぎによるプレイである場合は、受信バトルログデータ６０９に含まれるバトルＩＤの情報をそのまま流用する。そして、プロセッサ２１は、ユーザ情報６３１を適宜設定して、送信用結果データ６０８を生成し、サーバ１に送信する。その後、プロセッサ２１は、ＴＢＳＧ処理を終了する。

図２３に戻り、次に、ステップＳ３５で、プロセッサ２１は、自発・引継履歴データ６０７を更新する。具体的には、プロセッサ２１は、新たな履歴番号６２１と、今回自発したリレーバトルを示すバトルＩＤ６２３が設定されたレコードを生成し、自発・引継履歴データ６０７に追加する。この際、今回のプレイにおいて上記ステップＳ５０で報酬が付与されている場合は、プロセッサ２１は、報酬フラグ６２４にオンを設定したうえで、レコードを追加する。逆に、付与されていない場合は、プロセッサ２１は、報酬フラグ６２４にオフを設定したうえで、レコードを追加する。その後、プロセッサ２１は、自発バトル処理を終了する。

図２１に戻り、自発バトル処理が終われば、上記ステップＳ２１に戻り、処理が繰り返される。

一方、上記ステップＳ２３の判定の結果、自発操作が行われていない場合は（ステップＳ２３でＮＯ）、ステップＳ２５で、プロセッサ２１は、操作データ６１１に基づき、リレーバトルメニューから、リレーバトルを引き継ぐ操作が行われたか否かを判定する。当該判定の結果、引き継ぎ操作が行われた場合は（ステップＳ２５でＹＥＳ）、ステップＳ２６で、プロセッサ２１は、引き継ぎバトル処理を実行する。

図２６～図２７は、引き継ぎバトル処理の詳細を示すフローチャートである。まず、ステップＳ６１で、プロセッサ２１は、引き継ぎ可能なリレーバトルのデータ要求をサーバに送信する。次に、ステップＳ６２で、プロセッサ２１は、上記要求に応じてサーバ１から送信されてきたリレーバトルのデータを受信する。更に、プロセッサ２１は、当該受信したデータに基づき、受信バトルログデータ６０９を生成する（例えば、受信したデータに含まれる各バトルログデータ５１６を受信バトルログデータ６０９にコピーする）。

次に、ステップＳ６３で、プロセッサ２１は、上記受信したリレーバトルのデータに基づき、上記受信したリレーバトルのリストを生成して表示する。

次に、ステップＳ６４で、プロセッサ２１は、操作データ６１１を取得し、リストで表示されているいずれかのリレーバトルも引き継がないことを決定する操作が行われたか否かを判定する。当該判定の結果、いずれのリレーバトルも引き継がない操作が行われた場合は（ステップＳ６４でＹＥＳ）、プロセッサ２１は、引継ぎバトル処理を終了する。なお、他の実施形態では、この場合は、上記ステップＳ６１に戻り、他のリレーバトルのデータを要求するようにしてもよい（つまり、リストを更新する処理を行ってもよい）。

一方、いずれのリレーバトルも引き継がない操作が行われていない場合は（ステップＳ６４でＮＯ）、次に、ステップＳ６５で、プロセッサ２１は、操作データ６１１を取得し、リストの中から、いずれかのリレーバトルの情報を参照する操作が行われたか否かを判定する。当該判定の結果、情報を参照する操作が行われていない場合は（ステップＳ６５でＮＯ）、上記ステップＳ６３に戻り、処理が繰り返される。一方、情報を参照する操作が行われていた場合は（ステップＳ６５でＹＥＳ）、ステップＳ６６で、プロセッサ２１は、受信バトルログデータ６０９に基づき、選択されたリレーバトルに関する情報を表示する。具体的には、それまでに進行したターン数や出撃している自軍・敵軍ユニットの情報、加勢ポイントの状態等が表示される。更に、受信バトルログデータ６０９に基づき、それまでのゲーム進行のリプレイも表示される。また、各前任者に係るリプレイが終了したタイミングで、各前任者が設定した上記コメントも表示する。例えば、前任者が３人いる場合で、既定ターン数が２である場合は、リレーバトルが開始してから１～２ターンのリプレイ終了時に１人目の前任者のコメントが表示され、３～４ターンのリプレイ終了時に２人目の前任者のコメントが表示され、５～６ターンのリプレイ終了時に３人目の前任者のコメントが表示される。

次に、ステップＳ６７で、プロセッサ２１は、上記リレーバトルのいずれか一つを引き継ぐことを決定する操作が行われたか否かを操作データ６１１に基づいて判定する。当該判定の結果、引き継ぐことを決定する操作が行われていない場合は（ステップＳ６７でＮＯ）、上記ステップＳ６３に戻り、処理が繰り返される。一方、引き継ぐことを決定する操作が行われた場合は（ステップＳ６７でＹＥＳ）、図２７のステップＳ６８で、プロセッサ２１は、引き継ぎすることが決定されたリレーバトルを指定する情報を含む引継ぎ決定通知をサーバ１に送信する。

次に、ステップＳ６９で、プロセッサ２１は、サーバ１から引継ぎ可能通知を受信したか否かを判定する。当該判定の結果、サーバ１から引継ぎ可能通知を受信していない（上記引継ぎ不可通知を受信した）場合は（ステップＳ６９でＮＯ）、ステップＳ７２で、プロセッサ２１は、引継ぎができない旨を表示する。その後、上記ステップＳ６１に戻り、処理が繰り返される。

一方、引継ぎ可能通知を受信した場合は（ステップＳ６９でＹＥＳ）次に、ステップＳ７０で、プロセッサ２１は、ＴＢＳＧ処理を実行する。当該処理は、上述したステップＳ３４の処理と同様であるため、説明は省略する。

次に、ステップＳ７１で、プロセッサ２１は、自発・引継履歴データ６０７を更新する。具体的には、プロセッサ２１は、今回引き継ぎしたリレーバトルを示すバトルＩＤ６２３が設定されたレコードを生成し、自発・引継履歴データ６０７に追加する。また、上記同様に、今回のプレイにおいて報酬が付与されている場合は、プロセッサ２１は、報酬フラグ６２４にオンを設定したうえで、レコードを追加する。その後、プロセッサ２１は、引き継ぎバトル処理を終了する。

図２１に戻り、引き継ぎバトル処理が終了すれば、上記ステップＳ２１に戻り、処理が繰り返される。

一方、上記ステップＳ２５の判定の結果、リレーバトルを引き継ぐ操作が行われていない場合は（ステップＳ２５でＮＯ）、ステップＳ２７で、プロセッサ２１は、操作データ６１１に基づき、上記リレーバトルメニューから、進捗確認の操作が行われたか否かを判定する。当該判定の結果、進捗確認の操作が行われた場合は（ステップ２７でＹＥＳ）、ステップＳ２８で、プロセッサ２１は、進捗確認処理を実行する。

図２８は、上記進捗確認処理の詳細を示すフローチャートである。まず、ステップＳ８１で、プロセッサ２１は、自発・引継履歴データ６０７を参照し、そのユーザが自発、あるいは引き継いだ、１以上のリレーバトルのバトルＩＤ６２３を指定した進捗確認要求をサーバ１に送信する。

次に、ステップＳ８２で、プロセッサ２１は、上記要求に応じてサーバ１から送信されたリレーバトルのデータを受信する。

次に、ステップＳ８３で、プロセッサ２１は、上記受信したリレーバトルのデータに基づいて、進捗確認したいリレーバトルの選択画面を生成して表示する。図示は省略するが、当該画面では、そのユーザが自発あるいは引き継いだリレーバトルが一覧表示される。なお、当該リレーバトルの一覧表示を行う際に、報酬が未付与のリレーバトルと、報酬付与済みのリレーバトルと、まだ終了していないリレーバトルとをユーザが判別できるように、所定の画像（アイコン等）を各リレーバトルを示す画像に付加して表示してもよい。

次に、ステップＳ８４で、プロセッサ２１は、操作データ６１１を取得し、その操作内容に基づいて、いずれかのリレーバトルのリプレイ開始を指示する操作が行われたか否かを判定する。当該判定の結果、リプレイ開始の指示が行われていた場合は（ステップＳ８４でＹＥＳ）、ステップＳ８５で、プロセッサ２１は、ユーザが選択したリレーバトルのデータに基づき、リプレイ処理を行う。

次に、ステップＳ８６で、プロセッサ２１は、上記ステップＳ８５におけるリプレイ処理が終了したか否かを判定する。例えば、リプレイを最後まで再生した場合、あるいは、リプレイの途中でユーザからリプレイをキャンセルする指示を受け付けた場合、リプレイ処理が終了したと判定される。当該判定の結果、終了していない場合は（ステップＳ８６でＮＯ）、プロセッサ２１は、上記ステップＳ８５に戻り、リプレイ処理を継続する。一方、終了した場合は（ステップＳ８６でＹＥＳ）、上記ステップＳ８３に戻り、処理が繰り返される。

一方、上記ステップＳ８４の判定の結果、リプレイ開始の指示が行われていない場合は（ステップＳ８４でＮＯ）、ステップＳ８７で、プロセッサ２１は、操作データ６１１を取得し、その操作内容に基づいて、いずれかのリレーバトルの報酬を確認する指示が行われたか否かを判定する。当該判定の結果、報酬の確認指示が行われていない場合は（ステップＳ８７でＮＯ）、次に、ステップＳ８８で、プロセッサ２１は、操作データ６１１に基づき、進捗確認処理の終了操作が行われたか否かを判定する。当該終了操作が行われていない場合は（ステップＳ８８でＮＯ）、上記ステップＳ８３に戻り、処理が繰り返される。終了操作が行われた場合は（ステップＳ８８でＹＥＳ）、プロセッサ２１は、当該進捗確認処理を終了する。

一方、上記ステップＳ８７の判定の結果、報酬の確認指示が行われた場合は（ステップＳ８７でＹＥＳ）、図２９のステップＳ８９で、プロセッサ２１は、上記報酬確認指示が行われたリレーバトルが、終了条件が満たされたリレーバトルであるか否かを、上記終了フラグ５１５に基づき判定する。当該判定の結果、まだ終了条件が満たされていないリレーバトルである場合は（ステップＳ８９でＮＯ）、ステップＳ９３で、プロセッサ２１は、当該リレーバトルはまだ終了していない旨を表示する。その後、上記ステップＳ８３の処理に戻る。

一方、終了条件が満たされたリレーバトルの場合は（ステップＳ８９でＹＥＳ）、ステップＳ９０で、プロセッサ２１は、上記報酬確認指示が行われたリレーバトルが報酬はまだ付与されていないリレーバトルであるか否かを、上記報酬フラグ６２４に基づき判定する。当該判定の結果、報酬がまだ付与されていないリレーバトルの場合は（ステップＳ９０でＹＥＳ）、ステップＳ９１で、プロセッサ２１は、報酬を付与する処理を実行する。この処理では、上記ステップＳ５０と同様の処理が実行される。なお、当該報酬の付与の前提となる勝利／敗北の判定については、上記受信したリレーバトルデータ５０２のバトルログデータ５１６に基づいて判定すればよい。この点、他の実施形態では、リレーバトルが終了した際、勝利による終了であるのか、敗北による終了であるのかを示す情報を送信用結果データ６０８に含めて送り、サーバ１に登録するようにしてもよい。この場合、リレーバトルの終了状態を示す情報として、上記終了フラグ５１５の代わりに、例えば、「未終了」「勝利」「敗北」のいずれかを示す「終了状態データ」を用いてもよい。そして、ステップＳ８７の処理において、プロセッサ２１は、当該終了状態データを参照することで、勝利報酬を付与するか敗北報酬を付与するかを判定してもよい。

次に、ステップＳ９２で、プロセッサ２１は、自発・引継履歴データ６０７を更新する。具体的には、プロセッサ２１は、上記報酬確認指示が行われたリレーバトルに係る報酬フラグ６２４にオンを設定する。

一方、上記ステップＳ９０の判定の結果、報酬を付与済みのリレーバトルである場合は（ステップＳ９０でＮＯ）、ステップＳ９４で、プロセッサ２１は、報酬は付与済みである旨を表示する。その後、上記ステップＳ８３の処理に戻る。

図２１に戻り、上記進捗確認処理が終了すれば、上記ステップＳ２１に戻り、処理が繰り返される。

一方、上記ステップＳ２７の判定の結果、進捗確認操作が行われていない場合は（ステップＳ２７でＮＯ）、ステップＳ２９で、プロセッサ２１は、操作データ６１１に基づき、リレーバトルメニューを終了する操作が行われたか否かを判定する。当該判定の結果、リレーバトルメニューの終了操作が行われていない場合は（ステップＳ２９でＮＯ）、上記ステップＳ２１に戻り処理が繰り返される。リレーバトルメニューの終了操作が行われた場合は（ステップＳ２９でＹＥＳ）、プロセッサ２１は、リレーバトル関連処理を終了する。

以上で、本実施形態のゲーム処理の詳細説明を終了する。

このように、本実施形態では、ＴＢＳＧにおいて、１つのマップについて、自軍フェイズを所定ターンずつ別々のユーザが操作してクリアを目指すという協力型マルチプレイを提供している。いわば、戦場における指揮官が交代しながら戦いを繋いでいくというような、新規なマルチプレイを提供している。これにより、複数のユーザで協力して、例えば強大な敵を倒す、という楽しみ方をユーザに提供できる。

また、上記リレーバトルに参加する際、引継ぎユーザは、上記第１のゲームモードで成長させた、自身が所有するユニットを出撃させることができる。これにより、各ユーザが成長させた各自の所有ユニットを複数のユーザどうして見せ合って楽しむという楽しみ方も提供できる。

更に、本実施形態では、リレーバトルを引き継いでプレイすることができるため、例えば自発ユーザがＴＢＳＧが得意ではないユーザであっても、ＴＢＳＧが得意な引継ユーザが引き継いでプレイしたり、引継ユーザがより強力なユニットを出撃させたりすること等によって、最終的にクリアする（そして、勝利報酬を得る）ことも可能である。そのため、ＴＢＳＧと得意でないユーザや初心者のユーザであっても、気軽に参加してＴＢＳＧを楽しんでもらうことが可能となる。また、ユーザ同士の対戦は苦手であるというユーザも、協力プレイという形式であるため、複数ユーザによるゲームプレイを楽しんでもらうことも可能となる。

また、仮に、ユーザが、他ユーザとゲーム状況を同期せずに、他ユーザがプレイしたゲームをそのまま引き継いでプレイする場合、ゲームの進行状況によっては、今後のゲームの展開が他ユーザのプレイによって方向づけられており、ユーザがゲームの進行に介入できる余地が少ないと考えられる。この点、本実施形態であれば、上記のように引き継ぎの際に自身の所有ユニットを追加で出撃させることができる。そのため、他ユーザのプレイによって方向付けられていたゲームの展開を大きく変える余地が生まれる。これにより、ユーザが採り得る戦術が増え、ゲームの興趣性を向上できる。

また、本実施形態では、リレーバトルを引き継ぐ際に、それまでの戦いをリプレイで提示している。そのため、リレーバトルに途中参加する場合であっても、どのようなユニットを出撃させることが適切であるか等、その後の戦略や戦術等をユーザが判断可能である。これにより、ＴＢＳＧにおける戦略性を向上し、その興趣性を向上できる。また、リレーバトルに参加した後も、上記のリプレイでその後の経過を確認することもできる。このようなリプレイ機能により、他のユーザの戦い方（プレイ）を見ることができるため、新たな発見や気付き等を得る可能性も高まる。このような新たな発見や気付きを得ることで、ユーザは新たな戦い方を試す等で、ゲームの興趣性を更に向上できる。

また、上記のように、リレーバトルが自発されてから早い段階で参加するという楽しみ方と、ある程度ターンが経過した段階で参加する楽しみ方との２つの楽しみ方を提供できる。これにより、ユーザのプレイスタイルに応じた適切な楽しみ方を提供できる。

［変形例］
なお、上記実施形態では、リレーバトルを自発した後、どのようなユーザでも引継ぎ可能な例を挙げている。他の実施形態では、自発したリレーバトルをサーバ１に登録する際、引継ぎ可能なユーザを限定するようにして登録してもよい。例えば、上記結果データをサーバ１に送信する際に、自発ユーザの所定の操作に基づき、当該自発ユーザが「フレンド」登録している他のユーザのみが引継ぎ可能、という設定を加えて、当該結果データを送信できるようにしてもよい。また、その他、自発したリレーバトルにパスワードを設定して、結果データを送信してもよい。そして、リレーバトルが引継がれる際に、引継ぎユーザに当該パスワードの入力を求めるようにすればよい。

また、上記実施形態では、リレーバトルを自発した後、既定のターン数経過でゲームの進行を一旦終了し、結果データを送信する例を示した。この点につき、他の実施形態では自発でリレーバトルを開始した後、例えば、１０分等の所定時間が経過したタイミングでゲームの進行を終了させてもよい。あるいは、所定のゲーム内イベントが発生したタイミングでゲーム進行を終了させてもよい（換言すれば、所定のゲーム内イベントを発生させないようにすれば終了条件を満たすまでプレイ可能としてもよい）。所定のゲーム内イベントの一例としては、マップに配置される中ボスキャラクタの撃破や、マップに配置される所定位置にキャラクタを配置することであってもよい。

また、ゲーム進行を終了させる処理と上記結果データを送信する処理の処理順番は、上述の例に限らず、いずれを先に処理してもよいし、並行して処理を進めてもよい。また例えば、結果データに関しては、１ターン終了する毎に送信するようにしてもよい。

また、上記実施形態において、リレーバトルを自発した後、誰にも引き継ぐことなくその自発者がゲームをクリア（または敗北）可能なリレーバトル（のマップ）が用意されていてもよい。そして、誰にも引き継ぐことなくゲームが終了した場合は、報酬の付与は行われるが、結果データのサーバ１への送信処理は省略してもよい。引き継ぐ必要が無いため、結果データの送信の必要性もないためである。

また、上記実施形態では、引継ぎユーザは同じリレーバトルに対して１度しか引継ぎできず、自発ユーザも自身で引継ぐことはできない場合を例として説明した。他の実施形態では、連続する引継ぎでなければ、同じユーザが複数回引継ぎ可能としてもよい。例えば、ユーザＡが自発したリレーバトルをユーザＢが引き継ぎ、更に、ユーザＣが引継いだ後、ユーザＢが再度引き継ぐことができるようにしてもよい。また、自発したユーザＡについても、ユーザＢやユーザＣ等の他のユーザの引継ぎが発生していれば、これを引き継ぐ形で、自身が自発したバトルを自身で引継ぎ可能としてもよい。

また、上記実施形態では、引継ぎ可能なリレーバトルとして選ばれないようにリレーバトルデータを一時的にロックするタイミングについて、ゲーム装置２から引継ぎ決定通知を受信したタイミングとする例を示した。この点、他の実施形態では、例えば、リストアップした複数のリレーバトルデータをゲーム装置２に送信するタイミングで、当該リストアップしたリレーバトルデータの全てをロックするような制御を行ってもよい。また、所定のゲーム装置２から引継ぎ決定通知を受信したとき、当該通知で指定されるリレーバトルを引継ぎ可能なリレーバトルの候補として送信済みのゲーム装置に対して、当該リレーバトルが引継ぎ不可となったことを示す通知を送信するようにしてもよい。そして、当該通知を受信したゲーム装置では、受信後、速やかにその旨を表示するようにしてもよい。例えば、ユーザが所定のリレーバトルのリプレイを見ている間に、他のユーザが当該リレーバトルの引継ぎを決定した場合、「このリレーバトルは他のユーザによって引き継がれました」等の表示をポップアップ表示する等してもよい。

また、上記のようにリレーバトルデータがロックされた後、上記の既定ターン数が経過しないまま放置されているような場合（結果データがいつまで経っても送信されてこない場合）に備え、ロックされる時間に制限を設けるようにしてもよい。例えば、あるリレーバトルについて、ロックされてから２４時間以上経過している場合は、上記ロックフラグ５１４を強制的にオフに設定するような処理を行ってもよい。なお、このようなリレーバトルが放置される場合としては、例えば、上記既定ターン数のプレイが終わる前に、ゲーム装置２のバッテリー切れ等でプレイが中断し、プレイの結果が送信できない、というような場合等が考えられる。

また、上記実施形態では、上記前任者ユニットもユーザ自身が操作可能な例を挙げたが、他の実施形態では、前任者ユニットについてはＡＩ制御にしてもよい。これにより、前任者ユニットを操作する手間を省くことができ、ユーザの利便性を向上できる。

また、上記実施形態では、各ユーザのプレイが終了した際にコメントを残すことができる例を挙げた。当該コメントについては、残すことを必須としてもよいし、任意で残すことができるようにしてもよい。

また、上記実施形態では、自発者がプレイするターン数と引継ユーザがプレイするターン数（上記既定ターン数）が同じである例を挙げたが、両者は異なるターン数であってもよい。例えば、自発者は５ターン、引継ユーザは３ターンだけプレイ可能としてもよい。

また、上記実施形態では、ユーザが育成可能なキャラクタを用いたＴＢＳＧをゲームの一例として説明した。当該ゲームの種類について、例えば、将棋、囲碁、チェスのような、手番を交代しながら進めるゲームにも上記のような協力プレイの処理は適用可能である。但し、ゲームによっては、引継ぎ時に、ユーザの所有するキャラクタ（駒）等の追加はできないこともある。

また、上記実施形態においては、リレーバトル関連処理自体は単一のゲーム装置２で実行される場合を説明した。他の実施形態においては、上記リレーバトル関連処理を複数の情報処理端末からなる情報処理システムにおいて実行されてもよい。例えば、端末側装置と、当該端末側装置とネットワークを介して通信可能なサーバ側装置とを含む情報処理システムにおいて、上記リレーバトル関連処理のうちの一部の処理がサーバ側装置によって実行されてもよい。更には、端末側装置と、当該端末側装置とネットワークを介して通信可能なサーバ側装置とを含む情報処理システムにおいて、上記一連の処理のうちの主要な処理がサーバ側装置によって実行され、当該端末側装置では一部の処理が実行されてもよい。また、上記情報処理システムにおいて、サーバ側のシステムは、複数の情報処理端末によって構成され、サーバ側で実行するべき処理を複数の情報処理端末が分担して実行してもよい。また、いわゆるクラウドゲーミングの構成としてもよい。例えば、ゲーム装置２は、ユーザの操作を示す操作データを所定のサーバに送り、当該サーバにおいて各種ゲーム処理が実行され、その実行結果が動画・音声としてゲーム装置２にストリーミング配信されるような構成としてもよい。

２ ゲーム装置
４ コントローラ
５ 表示部
２１ プロセッサ
２２ 記憶部
２３ 無線通信部
２４ コントローラ通信部
２５ 画像音声出力部

Claims (18)

1. ユーザの情報処理端末においてゲームを実行するためのゲームプログラムであって、
   当該情報処理端末のコンピュータを、
   前記ユーザによる第１開始指示入力に基づいて、予め定められた初期設定データに基づく前記ゲームであって、当該ユーザのユーザキャラクタを用いる当該ゲームを開始する第１ゲーム開始手段と、
   前記第１開始指示入力によって開始された前記ゲームを、前記ユーザの操作入力に基づいて進行させる第１ゲーム進行手段と、
   前記第１開始指示入力によって前記ゲームが開始された後の第１タイミングにおいて、当該ゲームの進行を終了させ、当該第１タイミングにおける当該ゲームの進行状況を示す進行状況データをサーバに送信する第１送信手段と、
   前記ユーザとは異なる他ユーザが操作する他の情報処理端末によって前記サーバに送信され、当該サーバから当該ユーザの前記情報処理端末が取得した前記進行状況データに基づく前記ゲームであって、当該他ユーザによって当該ゲームにおいて用いられていた他ユーザキャラクタと、当該ユーザの前記ユーザキャラクタとを用いる前記ゲームを当該ユーザの第２開始指示入力に基づいて開始する第２ゲーム開始手段と、
   前記第２開始指示入力に基づいて開始された前記ゲームを、前記ユーザの操作入力に基づいて進行させる第２ゲーム進行手段と、
   前記第２開始指示入力に基づいて前記ゲームが開始された後の第２タイミングにおいて、当該ゲームの進行を終了させ、当該第２タイミングにおける当該ゲームの進行状況を示す進行状況データを前記サーバに送信し、当該第２タイミングが到来するまでに当該ゲームの勝利条件を満たした場合は、当該勝利条件を満たしたときまでの当該ゲームの進行状況を示す進行状況データを当該サーバに送信する第２送信手段として機能させ、
   前記ゲームはターン制ストラテジーゲームであり、
   前記第１タイミングは、前記第１開始指示入力による前記ゲーム開始から第１のターン数のターンが経過したタイミングであって、
   前記第２タイミングは、前記第２開始指示入力による前記ゲーム開始から第２のターン数のターンが経過したタイミングであり、
   前記ゲーム進行状況データは、前記第１タイミングまでの前記ゲームの経過を再現することが可能なデータであり、
   前記第２ゲーム開始手段は、前記第１タイミングにおけるゲームの進行状況を再現した状態で前記ゲームを開始する、ゲームプログラム。
2. 前記第１ゲーム進行手段および第２ゲーム進行手段は、
   前記ゲームにおいて、前記ユーザの手番のときは、当該ユーザの操作に基づいてゲームを進行させ、相手方の手番のときは、ＡＩ制御に基づいた前記コンピュータの操作に基づいて前記ゲームを進行させ、
   前記ユーザの手番および相手方の手番がそれぞれ１ターン分終わったことで、前記第１のターン数および前記第２のターン数のカウントにおける１ターンが経過したものと判定する、請求項１に記載のゲームプログラム。
3. 前記第１ゲーム進行手段は、前記ユーザの操作入力に基づいて、仮想空間内の前記ユーザキャラクタを制御することで前記ゲームを進行させ、
   前記第２ゲーム進行手段は、前記ユーザの操作入力に基づいて、前記仮想空間の前記ユーザキャラクタおよび前記他ユーザキャラクタを制御することで前記ゲームを進行させる、請求項１に記載のゲームプログラム。
4. 前記第２ゲーム開始手段は、前記取得した前記進行状況データに基づいて決定される前記仮想空間内の所定の位置に前記ユーザの前記ユーザキャラクタを配置した上で、前記ゲームを開始する、請求項３に記載のゲームプログラム。
5. 前記第２ゲーム開始手段は、前記ユーザキャラクタが配置することが可能な位置として予め定められている加勢可能位置に前記ユーザキャラクタを配置し、
   前記加勢可能位置の数は、前記ゲームの進行状況に応じて変化し得る、請求項４に記載のゲームプログラム。
6. 前記第１ゲーム進行手段および／または前記第２ゲーム進行手段は、前記ゲームの進行を終了させた際に、予め用意された複数の選択肢を前記ユーザに提示し、
   前記第１送信手段、および／または、前記第２送信手段は、前記複数の選択肢からいずれかの選択肢が前記ユーザによって指定された場合は、当該指定された選択肢に関する選択肢データを前記進行状況データに対応づけて前記サーバに送信し、
   前記第２ゲーム開始手段は、前記サーバから取得した当該進行状況データに対応づけられる前記選択肢データがある場合、当該選択肢データに基づく画像を出力する、請求項１に記載のゲームプログラム。
7. 前記第２ゲーム開始手段は、前記サーバから取得した前記進行状況データに基づいて、当該進行状況データで示される、前記ゲームの進行が終了されたタイミングまでの前記ゲームの経過を示すリプレイを、前記ゲームの開始より前に出力する、請求項１に記載のゲームプログラム。
8. 前記第２ゲーム開始手段は、前記リプレイの出力後、前記ユーザの前記第２開始指示入力があった場合に、前記ゲームを開始する、請求項７に記載のゲームプログラム。
9. 前記第１ゲーム進行手段または第２ゲーム進行手段によるゲーム進行が終了した後、前記ユーザによる進行状況確認指示入力があった場合、当該入力に応じて前記進行状況データを前記サーバから取得し、当該進行状況データに基づいて、当該ゲームの経過を示すリプレイを出力する、請求項１に記載のゲームプログラム。
10. 前記ゲームプログラムは、
    前記第２タイミングまでに前記ゲームの前記勝利条件を満たす場合、当該ゲームの勝利条件を満たしたことに基づく第１報酬を前記ユーザに付与する第１報酬付与手段と、
    前記ユーザの前記情報処理端末が前記ゲームに基づく前記進行状況データを前記サーバに送信した後、前記他ユーザによる当該ゲームの進行状況が当該ゲームの勝利条件を満たした場合、前記第１報酬よりも価値が低い第２報酬を当該ユーザに付与する第２報酬付与手段として前記コンピュータを更に機能させる、請求項１に記載のゲームプログラム。
11. 前記第２送信手段は、前記第２タイミングまでに敗北条件を満たす場合、当該敗北条件を満たしたときまでの進行状況データを前記サーバに送信し、
    前記ゲームプログラムは、前記第２タイミングまでに前記ゲームの前記敗北条件を満たす場合、当該ゲームの当該敗北条件を満たしたことに基づく、前記第１報酬よりも価値が低い第３報酬を前記ユーザに付与する第３報酬付与手段として前記コンピュータを更に機能させる、請求項１０に記載のゲームプログラム。
12. 前記ゲームプログラムは、前記第１ゲーム開始手段または第２ゲーム開始手段により開始される前記ゲームと、当該ゲームとは異なるゲームであって、前記ユーザキャラクタを育成可能な育成ゲームとを含むゲームアプリケーションを前記コンピュータに実行させ、
    前記第１ゲーム開始手段、および、前記第２ゲーム開始手段は、前記育成ゲームにおいて育成されたユーザキャラクタを用いる前記ゲームを開始する、請求項１に記載のゲームプログラム。
13. 前記第２ゲーム開始手段は、前記他ユーザによって当該ゲームにおいて用いられていた他ユーザキャラクタの数が所定数に達している場合、前記ユーザの前記ユーザキャラクタを前記ゲームに登場させないで当該ゲームを開始する、または、当該他ユーザキャラクタと当該ユーザキャラクタとを交代させて当該ゲームを開始する、請求項１２に記載のゲームプログラム。
14. 前記第１ゲーム開始手段は、複数のユーザキャラクタのうち、前記ユーザが選択したユーザキャラクタを用いる前記ゲームを開始し、
    前記第２ゲーム開始手段は、前記他ユーザが前記ゲームに用いていた前記他ユーザキャラクタと、前記複数のユーザキャラクタのうち当該他ユーザキャラクタとは異なるユーザキャラクタとを用いる当該ゲームを開始する、請求項１に記載のゲームプログラム。
15. 前記第１送信手段は、前記進行状況データを取得できる前記他ユーザの範囲を前記ユーザの操作入力に基づいて指定したうえで、当該進行状況データを当該サーバに送信する、請求項１に記載のゲームプログラム。
16. サーバと、複数の情報処理端末を有するゲームシステムであって、
    第１の情報処理端末のコンピュータは、
    第１ユーザによる第１開始指示入力に基づいて、予め定められた初期設定データに基づく前記ゲームであって、当該第１ユーザのユーザキャラクタを用いる当該ゲームを開始する第１ゲーム開始手段と、
    前記第１開始指示入力によって開始された前記ゲームを、前記第１ユーザの操作入力に基づいて進行させる第１ゲーム進行手段と、
    前記第１開始指示入力によって前記ゲームが開始された後の第１タイミングにおいて、当該ゲームの進行を終了させ、当該第１タイミングにおける当該ゲームの進行状況を示す進行状況データを前記サーバに送信する第１送信手段と、
    前記第１ユーザとは異なる第２ユーザが操作する第２の情報処理端末によって前記サーバに送信され、当該サーバから前記第１の情報処理端末が取得した前記進行状況データに基づく前記ゲームであって、当該第２ユーザによって当該ゲームにおいて用いられていた第２ユーザのユーザキャラクタと、当該第１ユーザの前記ユーザキャラクタとを用いる前記ゲームを当該第１ユーザの第２開始指示入力に基づいて開始する第２ゲーム開始手段と、
    前記第２開始指示入力に基づいて開始された前記ゲームを、前記第１ユーザの操作入力に基づいて進行させる第２ゲーム進行手段と、
    前記第２開始指示入力に基づいて前記ゲームが開始された後の第２タイミングにおいて、当該ゲームの進行を終了させ、当該第２タイミングにおける当該ゲームの進行状況を示す進行状況データを前記サーバに送信し、当該第２タイミングが到来するまでに当該ゲームの勝利条件を満たした場合は、当該勝利条件を満たしたときまでの当該ゲームの進行状況を示す進行状況データを当該サーバに送信する第２送信手段とを備え、
    前記ゲームはターン制ストラテジーゲームであり、
    前記第１タイミングは、前記第１開始指示入力による前記ゲーム開始から第１のターン数のターンが経過したタイミングであって、
    前記第２タイミングは、前記第２開始指示入力による前記ゲーム開始から第２のターン数のターンが経過したタイミングであり、
    前記ゲーム進行状況データは、前記第１タイミングまでの前記ゲームの経過を再現することが可能なデータであり、
    前記第２ゲーム開始手段は、前記第１タイミングにおけるゲームの進行状況を再現した状態で前記ゲームを開始する、ゲームシステム。
17. ゲーム装置であって
    ユーザによる第１開始指示入力に基づいて、予め定められた初期設定データに基づくゲームであって、当該ユーザのユーザキャラクタを用いる当該ゲームを開始するゲーム開始手段と、
    前記第１開始指示入力によって開始された前記ゲームを、前記ユーザの操作入力に基づいて進行させる第１ゲーム進行手段と、
    前記第１開始指示入力によって前記ゲームが開始された後の第１タイミングにおいて、当該ゲームの進行を終了させ、当該第１タイミングにおける当該ゲームの進行状況を示す進行状況データをサーバに送信する第１送信手段と、
    前記ユーザとは異なる他ユーザが操作する他の情報処理端末によって前記サーバに送信され、当該サーバから前記ユーザの前記情報処理端末が取得した前記進行状況データに基づく前記ゲームであって、当該他ユーザによって当該ゲームにおいて用いられていた他ユーザキャラクタと、当該ユーザの前記ユーザキャラクタとを用いる前記ゲームを当該ユーザの第２開始指示入力に基づいて開始する第２ゲーム開始手段と、
    前記第２開始指示入力に基づいて開始された前記ゲームを、前記ユーザの操作入力に基づいて進行させる第２ゲーム進行手段と、
    前記第２開始指示入力に基づいて前記ゲームが開始された後の第２タイミングにおいて、当該ゲームの進行を終了させ、当該第２タイミングにおける当該ゲームの進行状況を示す進行状況データを前記サーバに送信し、当該第２タイミングが到来するまでに当該ゲームの勝利条件を満たした場合は、当該勝利条件を満たしたときまでの当該ゲームの進行状況を示す進行状況データを当該サーバに送信する第２送信手段とを備え、
    前記ゲームはターン制ストラテジーゲームであり、
    前記第１タイミングは、前記第１開始指示入力による前記ゲーム開始から第１のターン数のターンが経過したタイミングであって、
    前記第２タイミングは、前記第２開始指示入力による前記ゲーム開始から第２のターン数のターンが経過したタイミングであり、
    前記ゲーム進行状況データは、前記第１タイミングまでの前記ゲームの経過を再現することが可能なデータであり、
    前記第２ゲーム開始手段は、前記第１タイミングにおけるゲームの進行状況を再現した状態で前記ゲームを開始する、ゲーム装置。
18. ユーザの情報処理端末のコンピュータに実行させるゲーム処理方法であって、
    前記コンピュータに、
    前記ユーザによる第１開始指示入力に基づいて、予め定められた初期設定データに基づく前記ゲームであって、当該ユーザのユーザキャラクタを用いる当該ゲームを開始させ、
    前記第１開始指示入力によって開始された前記ゲームを、前記ユーザの操作入力に基づいて進行させ、
    前記第１開始指示入力によって前記ゲームが開始された後の第１タイミングにおいて、当該ゲームの進行を終了させ、当該第１タイミングにおける当該ゲームの進行状況を示す進行状況データをサーバに送信させ、
    前記ユーザとは異なる他ユーザが操作する他の情報処理端末によって前記サーバに送信され、当該サーバから当該ユーザの前記情報処理端末が取得した前記進行状況データに基づく前記ゲームであって、当該他ユーザによって当該ゲームにおいて用いられていた他ユーザキャラクタと、当該ユーザの前記ユーザキャラクタとを用いる前記ゲームを当該ユーザの第２開始指示入力に基づいて開始させ、
    前記第２開始指示入力に基づいて開始された前記ゲームを、前記ユーザの操作入力に基づいて進行させ、
    前記第２開始指示入力に基づいて前記ゲームが開始された後の第２タイミングにおいて、当該ゲームの進行を終了させ、当該第２タイミングにおける当該ゲームの進行状況を示す進行状況データを前記サーバに送信し、当該第２タイミングが到来するまでに当該ゲームの勝利条件を満たした場合は、当該勝利条件を満たしたときまでの当該ゲームの進行状況を示す進行状況データを当該サーバに送信させ、
    前記ゲームはターン制ストラテジーゲームであり、
    前記第１タイミングは、前記第１開始指示入力による前記ゲーム開始から第１のターン数のターンが経過したタイミングであって、
    前記第２タイミングは、前記第２開始指示入力による前記ゲーム開始から第２のターン数のターンが経過したタイミングであり、
    前記ゲーム進行状況データは、前記第１タイミングまでの前記ゲームの経過を再現することが可能なデータであり、
    前記第２開始指示入力によるゲームの開始では、前記第１タイミングにおけるゲームの進行状況を再現した状態で前記ゲームを開始する、ゲーム処理方法。

Images