JP7089742B2 - ゲームシステム、サーバ装置、プログラム - Google Patents

Description

本発明は、ゲームシステム、サーバ装置、及びプログラムに関する。

複数のゲーム実行部がネットワークを介して接続される対戦型のゲームシステムにおいて、各ゲーム実行部が、ネットワークを介して操作部から得られる操作情報を交換しながらゲームを進行し、進行したゲームのゲーム状況を表すゲーム状況情報を記憶するシステムが知られている。各ゲーム実行部は、同じ操作情報を用いてゲームを進行するため、各ゲーム実行部より実現されるゲーム状況は同じになり、記憶するゲーム状況情報も同じになる。

特開２０１７－０７７３５０号公報

しかしながら、ゲームの終了の際のゲーム状況情報間において不整合が生じることがある。このような不整合が生じる原因は、例えば、単なるバグや、いわゆる同期ずれと呼ばれる類のバグ、キャッシュの不具合、ゲーム中の電源の遮断（電源オフ操作）等が考えられる。

ゲームの終了の際のゲーム状況情報間の不整合が生じると、対戦したユーザに違和感を与えるおそれがある。

そこで、１つの側面では、本発明は、複数のゲーム実行部によりそれぞれ記憶されるゲーム状況情報間における不整合に起因した不都合を低減することを目的とする。

１つの側面では、互いに通信可能な第１ゲーム実行部及び第２ゲーム実行部を含むゲーム用のゲームシステムであって、
前記第１ゲーム実行部は、第１ユーザ情報に関連付けられた第１指示情報と、前記第１ユーザ情報とは異なる第２ユーザ情報に関連付けられた第２指示情報であって前記第２ゲーム実行部から通信により取得した第２指示情報とに基づいて、前記ゲームを進行し、進行した前記ゲームのゲーム状況を表す第１ゲーム状況情報を第１記憶部に記憶する第１進行処理を実行し、
前記第２ゲーム実行部は、前記第１ゲーム実行部から通信により取得した前記第１指示情報と、前記第２指示情報とに基づいて、前記ゲームを進行し、進行した前記ゲームのゲーム状況を表す第２ゲーム状況情報を第２記憶部に記憶する第２進行処理を実行し、
前記ゲームの終了の際の前記第１ゲーム状況情報及び前記ゲームの終了の際の前記第２ゲーム状況情報を比較し、比較結果に応じて、前記ゲームの終了の際の前記第１ゲーム状況情報及び前記ゲームの終了の際の前記第２ゲーム状況情報のうちの、一方のゲーム状況情報を、他方のゲーム状況情報に整合するように修正する修正処理を実行する修正部を更に含む、ゲームシステムが提供される。

１つの側面では、本発明によれば、ゲームの終了の際の前記第１ゲーム状況情報及び前記ゲームの終了の際の前記第２ゲーム状況情報を比較し、比較結果に応じて、前記ゲームの終了の際の前記第１ゲーム状況情報及び前記ゲームの終了の際の前記第２ゲーム状況情報のうちの、一方のゲーム状況情報を、他方のゲーム状況情報に整合するので、ユーザに違和感を与えるといった不都合を回避することが可能となる。

一実施例によるゲームシステムの全体構成を概略的に示す図である。 ゲーム端末のハードウェア構成の一例を概略的に示す図である。 サーバ装置のハードウェア構成の一例を概略的に示す図である。 ２台のゲーム端末の機能の一例と、サーバ装置の機能の一例とを示す図である。 ゲーム状況情報の説明図である。 ゲームデータ記憶部内のゲームデータの一例の説明図である。 ２台のゲーム端末及びサーバ装置の３者間でのデータ（情報）のやり取りを概略的に示す図（その１）である。 ２台のゲーム端末及びサーバ装置の３者間でのデータ（情報）のやり取りを概略的に示す図（その２）である。 ２台のゲーム端末及びサーバ装置の３者間でのデータ（情報）のやり取りを概略的に示す図（他の例）である。 比較例の説明図である。 ２台のゲーム端末及びサーバ装置の３者間でのデータ（情報）のやり取りを概略的に示す図（他の例）である。 ２台のゲーム端末及びサーバ装置の３者間でのデータ（情報）のやり取りを概略的に示す図（他の例）である。 サーバ装置の具体的な構成例を示す図である。 ゲーム端末におけるソフトウェアプロセス構成を示す図である。 サーバ装置におけるソフトウェアプロセス構成を示す図である。 ゲームが正常に終了する場合のゲーム画面の遷移態様を概略的に示す図である。 ゲームが強制的に終了する場合のゲーム画面の遷移態様を概略的に示す図である。 ゲームアプリによるメイン処理を示すフローチャートである。 ゲームアプリによる各種割り込み処理を示すフローチャートである。 ＳＴＡＴＵＳの種類を示す図である。 ＳＴＡＴＵＳに係る状態遷移図である。 ゲームメイン処理（Ｓ１２０）のフローチャートである。 タイトル処理（Ｓ１２０２）のフローチャートである。 ユーザ認証処理（Ｓ１２０６）のフローチャートである。 マップ処理（Ｓ１２１０）のフローチャートである。 復元処理（Ｓ１２１０４）のフローチャートである。 マップメイン処理（Ｓ１２１０８）のフローチャートである。 ゲーム処理（Ｓ１２１４）のフローチャートである。 ゲーム初期化処理（Ｓ１２１４２）のフローチャートである。 ゲーム進行処理（Ｓ１２１４６）のフローチャートである。 ゲーム状況情報の他の例を示す図である。 対戦処理（Ｓ１２１４６０）のフローチャートである。 通常ゲーム進行処理（Ｓ１２１４６０２）のフローチャートである。 投球待ち処理（Ｓ１２１４６０６）のフローチャートである。 投球入力待ち処理（Ｓ１２１４６１０）のフローチャートである。 打撃待ち処理（Ｓ１２１４６１４）のフローチャートである。 ゲーム後処理（Ｓ１２１８）のフローチャートである。 ゲートサーバプロセスのフローチャートである。 認証サーバプロセスのフローチャートである。 ロビーサーバプロセスのフローチャートである。 サブロビーサーバプロセスのフローチャートである。 ゲームデータ記憶部に記憶されるゲームデータの一例を示す図である。 ゲームサーバプロセスのフローチャートである。 ゲーム終了判定処理（Ｓ４７２）のフローチャートである。 切断判定処理（Ｓ４７４）のフローチャートである。 切断検知処理（Ｓ４７４６）のフローチャートである。 切断確認処理（Ｓ４７５０）のフローチャートである。

以下、添付図面を参照しながら各実施例について詳細に説明する。

＜概要＞まず、図１～図６Ｃ、図６Ｅ、及び図６Ｆを参照して、一実施例によるゲームシステム１の概要について説明する。

図１は、一実施例によるゲームシステム１の全体構成を概略的に示す図である。

ゲームシステム１は、例えば対戦型のゲームに用いるものである。対戦型とは、第１プレイヤと第２プレイヤとが相対して戦うタイプであるが、第１プレイヤと第２プレイヤとが１対１で対峙する形態に限らず、１対複数や、複数対複数等の形態であってよい。例えば、１対複数の場合、第１プレイヤと第２プレイヤ及び一人以上の他のプレイヤとが対峙する形態、又は、第１プレイヤ及び一人以上の他のプレイヤと第２プレイヤとが対峙する形態であり、複数対複数の場合、第１プレイヤ及び一人以上の他のプレイヤと第２プレイヤ及び一人以上の他のプレイヤとが対峙する形態である。なお、１対複数の場合、複数で協力して共通の敵と戦う形態（共闘の形態）である。１対１の場合、第１プレイヤ及び第２プレイヤのいずれか一方に関連付けられた操作は、コンピュータにより実現されてもよい。また、１対複数の場合、いずれかのプレイヤに関連付けられた操作は、コンピュータにより実現されてもよい。以下、ユーザとは、第１プレイヤ又は第２プレイヤが人である場合、当該人を指す。また、第１プレイヤにとっては、第２プレイヤは対戦相手であり、第２プレイヤにとっては、第１プレイヤは対戦相手である。また、プレイヤは、ユーザ（人間）とコンピュータを含む概念である。

以下では、主に野球ゲームに適用したゲームシステム１について説明するが、野球ゲーム以外の対戦型の各種ゲーム、例えばサッカーゲームのような他の球技のゲームや、格闘ゲーム、アクションゲーム等に適用できる。

ゲームシステム１は、ゲーム端末群１０と、サーバ装置３０とを含む。ゲーム端末群１０及びサーバ装置３０とは、ネットワークＮを介して接続される。ネットワークＮは、例えば、携帯電話の無線通信網、インターネット、ＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、有線ネットワーク、又はこれらの任意の組み合わせ等を含んでもよい。

ゲーム端末群１０は、複数のゲーム端末１０－１、１０－２、１０－３、・・・、１０－ｎを含む。これら複数のゲーム端末１０－１、１０－２、１０－３、・・・、１０－ｎは、ネットワークＮを介して互いに通信可能になっている。

ゲーム端末１０－１は、図１に示すようなスマートフォン等の携帯電話の形態であってもよいし、他の形態であってもよい。例えば、ゲーム端末１０－１は、タブレット型コンピュータ）や、ウェアラブル端末、パーソナルコンピュータ、携帯ゲーム機、据置ゲーム機、業務用ゲーム機、情報処理機能を備えた多機能型テレビジョン受像機（スマートテレビ）等の形態であってもよい。これは、他のゲーム端末１０－２、１０－３、・・・、１０－ｎについても同様である。

サーバ装置３０は、複数のゲーム端末１０－１、１０－２、１０－３、・・・、１０－ｎと協動して、各種処理（後述）を実行する。サーバ装置３０は、コンピュータの形態であり、複数のサーバコンピュータにより協動して実現されてもよい。例えば、サーバ装置３０は、機能ごとに異なるサーバコンピュータを含んでよい（後出の図７参照）。

図２Ａは、ゲーム端末１０－１のハードウェア構成の一例を概略的に示す図であり、図２Ｂは、サーバ装置３０のハードウェア構成の一例を概略的に示す図である。なお、ここでは、ゲーム端末１０－１のハードウェア構成について説明するが、他のゲーム端末１０－２、１０－３、・・・、１０－ｎについても同様であってよい。

ゲーム端末１０－１は、制御部１１、記憶部１２、通信部１３、操作部１４、表示部１５、及び音声出力部１６を含む。

制御部１１は、少なくとも一つのマイクロプロセッサ（ＣＰＵ：Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）を含み、記憶部１２に記憶されたオペレーティングシステムやその他のプログラムに従って情報処理を実行する。記憶部１２は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）やＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等の主記憶部や、フラッシュメモリ（不揮発性の半導体メモリ）等の補助記憶部を含む。記憶部１２は、プログラムやデータを記憶する。なお、例えば、ゲーム端末１０－１がパーソナルコンピュータ等である場合、補助記憶部は、例えばハードディスクドライブ又はソリッドステートドライブ等であってよい。通信部１３は、ネットワークＮを介して他の装置とデータ通信する。通信部１３は、通信モジュールや通信インタフェースを含んでよい。

操作部１４は、ユーザが各種操作を行うユーザインタフェースである。操作部１４は、例えばタッチパネルや、ボタン（キー）、レバー（スティック）、マウス、タッチパッド等を含む。操作部１４は、ユーザが音声又はジェスチャによって操作を行うためのものであってもよい。すなわち、操作部１４は、ユーザが音声又はジェスチャによって入力操作を行うためのマイクやカメラを含んでもよい。表示部１５は、各種画面画像を表示するためのものであり、例えば液晶ディスプレイ又は有機ＥＬ（Ｅｌｅｃｔｒｏ Ｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイ等である。

音声出力部１６は音声データを出力するためのものであり、例えばスピーカ又はヘッドホン等である。

なお、操作部１４、表示部１５、及び音声出力部１６はゲーム端末１０－１自体に設けられていてもよいし、ゲーム端末１０－１に接続された外部装置として設けられてもよい。

サーバ装置３０は、制御部３１、記憶部３２、及び通信部３３を含む。制御部３１、記憶部３２、及び通信部３３は、ゲーム端末１０－１の制御部１１、記憶部１２、及び通信部１３と同様である。なお、記憶部３２は、リレーショナルデータベースサーバやＮｏＳＱＬサーバのようなデータベースサーバにより実現されてもよい。

記憶部１２又は記憶部３２に記憶されるプログラムやデータは、例えば、ネットワークＮを介してゲーム端末１０－１又はサーバ装置３０に供給されてよい。なお、情報記憶媒体（例えば光ディスクや、メモリカード等）に記憶されたプログラムやデータを読み取るための構成要素（例えば光ディスクドライブや、メモリーカードスロット等）がゲーム端末１０－１又はサーバ装置３０に備えられてもよい。そして、プログラムやデータが情報記憶媒体を介してゲーム端末１０－１又はサーバ装置３０に供給されてもよい。

図３は、ゲーム端末１０－１の機能の一例と、ゲーム端末１０－２の機能の一例と、サーバ装置３０の機能の一例とを示す図である。なお、ここでは、ゲーム端末１０－１、１０－２の機能について説明するが、他のゲーム端末１０－３、・・・、１０－ｎについても同様であってよい。図４は、ゲーム状況情報の説明図である。なお、図４において、説明用に、ゲーム状況情報の各情報項目の属性が示されているが、属性は、ゲーム状況情報の要素ではない。図５は、ゲームデータ記憶部３２０内のゲームデータの一例の説明図である。

ゲーム端末１０－１及びゲーム端末１０－２は、それぞれ、ゲーム実行部１１０と、修正指示処理部１１６と、ゲーム状況情報記憶部１２０とを含む。ゲーム実行部１１０及び修正指示処理部１１６は、制御部１１が記憶部１２内のプログラムを実行することで実現できる。また、ゲーム実行部１１０は、通信部１３を利用することで通信を行い、表示部１５に映像を表示し、音声出力部１６を利用して音声出力を行うことができる。ゲーム状況情報記憶部１２０は、記憶部１２により実現できる。

サーバ装置３０は、強制終了処理部３０１と、判定処理部３０２と、ゲームデータ記憶部３２０とを含む。強制終了処理部３０１及び判定処理部３０２は、制御部３１が記憶部３２内のプログラムを実行することで実現できる。ゲームデータ記憶部３２０は、記憶部３２により実現できる。

以下では、一例として、ゲーム端末１０－１（第１ゲーム端末の一例）とゲーム端末１０－２（第２ゲーム端末の一例）とサーバ装置３０とが協動してゲーム用の各種処理を実行する場合を想定する。ただし、本実施例は、３つ以上のゲーム端末とサーバ装置３０とが協動してゲーム用の各種処理を実行する場合にも適用可能である。

ゲーム端末１０－１のゲーム実行部１１０（第１ゲーム実行部の一例）、及び、ゲーム端末１０－２のゲーム実行部１１０（第２ゲーム実行部の一例）は、それぞれ、進行処理部１１１と、操作情報送受信処理部１１２と、結果通知処理部１１３と、ゲーム状況情報送信処理部１１４と、更新処理部１１５と、通信処理部１１８とを含む。なお、本実施例においては、ゲーム端末１０－１の修正指示処理部１１６（第１修正指示処理部の一例）、ゲーム端末１０－２の修正指示処理部１１６（第２修正指示処理部の一例）、サーバ装置３０の判定処理部３０２が、修正部２００を形成する。

以下では、主にゲーム端末１０－１のゲーム実行部１１０について説明するが、ゲーム端末１０－２のゲーム実行部１１０について、各種情報の送信先や送信元が逆のゲーム端末１０－１になりかつ修正対象の情報が第２ゲーム状況情報（後述）になるだけであり、実質的に同様である。

ゲーム端末１０－１の進行処理部１１１は、第１操作情報（第１指示情報の一例）と、第２操作情報（第２指示情報の一例）とに基づいて、ゲームを進行し、ゲームのゲーム状況を表すゲーム状況情報を、ゲーム端末１０－１のゲーム状況情報記憶部１２０に記憶する進行処理を実行する。

以下、区別のため、ゲーム端末１０－１の進行処理部１１１が生成及び記憶するゲーム状況情報を、「第１ゲーム状況情報」と称し、ゲーム端末１０－２の進行処理部１１１が生成及び記憶するゲーム状況情報を、「第２ゲーム状況情報」と称する。また、区別のため、ゲーム端末１０－１の進行処理部１１１が実行する進行処理を、「第１進行処理」と称し、ゲーム端末１０－２の進行処理部１１１が実行する進行処理を、「第２進行処理」と称する。

第１操作情報は、第１プレイヤ情報に関連付けられた操作情報である。第１プレイヤ情報とは、例えば第１プレイヤに固有の情報であり、例えば第１プレイヤの識別情報である。操作情報は、操作部１４を介して入力される。例えば、ゲーム端末１０－１で動作中のゲームアプリ（ゲームシステム１に係るゲーム用アプリケーション）に第１プレイヤがログインしている場合に、ゲーム端末１０－１の操作部１４を介して入力される操作情報は、第１プレイヤ情報に関連付けられた操作情報となる。

第１操作情報は、操作に応じて操作部１４で発生する信号データ自体（生データ）の形態であってもよいし、生データを加工して得られる形態であってもよい。これは、第２操作情報についても同様である。例えば、野球ゲームの場合、第１操作情報は、生データを加工して得られる形態の投球情報や打撃情報を含む。

第２操作情報は、第２プレイヤ情報に関連付けられた操作情報である。第１操作情報と同様に、例えば、ゲーム端末１０－２で動作中のゲームアプリに第２プレイヤがログインしている場合に、ゲーム端末１０－２の操作部１４を介して入力される操作情報は、第２プレイヤ情報に関連付けられた操作情報となる。

ゲーム端末１０－１の進行処理部１１１は、ネットワークＮを介して第２操作情報をゲーム端末１０－２から取得できる。例えば、ゲーム端末１０－１の進行処理部１１１は、サーバ装置３０を介してゲーム端末１０－１の操作情報送受信処理部１１２が第２操作情報を受信することで、第２操作情報をゲーム端末１０－２から取得してよい。この場合、ゲーム端末１０－２は、サーバ装置３０に第２操作情報を送信する。

ゲームを進行する処理は、第１操作情報と第２操作情報とに基づく任意の態様であってよく、例えば、第１操作情報と第２操作情報と後述するチーム情報とに基づいて実行されてよい。また、ゲームを進行する処理は、例えば、不確定要素によるゲーム性を高めるために、乱数による抽選処理を含んでよい。例えば、野球ゲームの場合、打球の飛ぶコースや角度、投球のコースや球威といった各種不確定要素が抽選により決定されてもよい。この場合、第１進行処理と第２進行処理とで同じ乱数シードを用いることで、第１進行処理と第２進行処理との間でのゲームの進行態様の整合性を確保できる。すなわち、第１進行処理と第２進行処理においてそれぞれのタイミングで利用される乱数が同じになり、例えば空振りや、ファール、ヒット、エラー等の結果は、第１進行処理と第２進行処理とで同じになる。

ゲーム状況とは、進行されるゲームの状況（ありさま）である。ゲーム状況は、ゲームに登場するゲームオブジェクトの状態を含む。ゲームオブジェクトとは、ゲームに登場するオブジェクトであり、例えば、カードや、フィギュア、アイテム等のことである。野球ゲームの場合、ゲームオブジェクトは、選手を表す。なお、第１プレイヤ情報に関連付けられた各ゲームオブジェクトは、第１操作情報に基づき、第２プレイヤ情報に関連付けられた各ゲームオブジェクトは、第２操作情報に基づき、ゲーム中で野球の試合を行うように描画される。

第１ゲーム状況情報は、進行処理部１１１が進行させたゲームの状況を表す。本実施例では、一例として、第１ゲーム状況情報は、属性（種類）の異なる情報として、対戦結果関連情報（第１情報の一例）と対戦能力情報（第２情報の一例）とを含む。

対戦結果関連情報は、ゲームに係る対戦結果に影響する対戦結果関連パラメータ（第１パラメータの一例）の値を含む。対戦結果とは、勝敗又は引き分けとして現れる結果であり、得点の状態を含んでよい。対戦結果関連パラメータは、例えば得点である。野球ゲームの場合、対戦結果関連パラメータは、各イニングにおける得点である。図４に示す第１ゲーム状況情報Ｄ１０１では、対戦結果関連パラメータは、自チームの得点と、相手チームの得点である。

対戦結果関連パラメータは、ゲームが進行されると値が変化する。例えば野球ゲームの場合、得点が入ると、得点が変化し、イニングが変わると、直前のイニングの得点が確定する。

対戦能力情報は、終了したゲームに起因して値が変化しかつ対戦能力に影響する対戦能力パラメータ（第２パラメータの一例）の値を含む。対戦能力情報は、例えばチーム情報（後述）に含まれる情報である。例えば、野球ゲームの場合、対戦能力パラメータは、各選手の能力に影響する。選手の能力は、野手の場合、パワー、守備力、肩の強さ、走力、ミート力等であり、投手の場合、制球力、スピード、球威、キレ等である。対戦能力パラメータは、疲労度合いに応じて値が変化するスタミナである。例えば、ある選手のスタミナが低下すると、当該選手の能力が低下する。なお、ある選手のスタミナは、当該選手を休ませたり、回復アイテムを使ったりすることで回復可能とされてよい。なお、以下では、一例として、スタミナを例に挙げて説明するが、スタミナに代えて、疲労度合いのような他の同等のパラメータが使用されてもよい。例えば、疲労度合いの場合、ある選手の疲労度合いが増加すると、当該選手の能力が低下する。図４に示す第１ゲーム状況情報Ｄ１０１では、対戦能力パラメータは、選手ごとのスタミナである。なお、対戦能力パラメータは、選手ごとのスタミナに代えて又は加えて、チーム全体としてのスタミナを含んでもよい。

対戦能力パラメータは、ゲームが進行されるに伴って値が変化するパラメータを含んでもよい。例えば、ある選手に係るスタミナの値は、ゲーム中における当該選手の運動量に関する情報（例えば当該選手が投手であれば投球数、野手であれば出場イニング数）等に基づいて更新される。この場合、スタミナの値は、選手の運動量が大きいほど低下する態様で更新される。従って、ある選手の能力は、ゲーム中の当該選手のスタミナの値の変化に応じてゲーム中に変化する。

対戦能力パラメータは、ゲームが進行されても値は変化しないパラメータを含んでもよい。ゲームが進行されても値は変化しないパラメータである場合、当該パラメータは、ゲームの終了の際又はゲームの終了後に（次のゲームの開始時までに）更新（変化）される。以下、ゲームが進行されても値は変化しないパラメータであってゲームの終了の際又はゲームの終了後に更新されるパラメータを、「ゲーム後更新パラメータ」とも称する。

ゲーム後更新パラメータは、例えば選手の怪我（故障）の有無等である。図４に示す第１ゲーム状況情報Ｄ１０１では、ゲーム後更新パラメータは、選手ごとの能力値と、チーム経験値である。能力値は、例えば、“Ｓ”の方が“Ａ”より高く、“Ａ”の方が“Ｂ”より高い。また、能力値は、同じ“Ｓ”であっても、そのあとに付されている数値が大きいほど高い。ある選手に係る能力値は、ゲームの終了の際の第１ゲーム状況情報のうちの、当該選手の活躍や貢献に関する情報（例えば当該選手が投手であれば、投球成績、当該選手が野手であれば、打撃成績）等に基づいて更新される。この場合、ある選手に係る能力値は、当該選手の活躍度合いが大きいほど増加する態様で更新される。チーム経験値は、例えば勝敗や、得点差、チーム全体としての打撃成績及び投球成績等に応じて算出及び加算される値であってよい。なお、図４では、打撃成績及び投球成績は、値が大きいほど良好な成績であることを意味する。なお、変形例では、スタミナがゲーム後更新パラメータであってもよい。

以下では、第１ゲーム状況情報の対戦能力情報のうちの、ゲーム後更新パラメータの値を表す情報を、第１ゲーム後更新情報（第１所定情報の一例）と称する。また、区別のため、第２ゲーム状況情報の対戦能力情報のうちの、ゲーム後更新パラメータの値を表す情報を、第２ゲーム後更新情報（第２所定情報の一例）と称する。

なお、変形例では、第１ゲーム状況情報の対戦能力情報は、第１ゲーム後更新情報を含まず、第２ゲーム状況情報の対戦能力情報は、第２ゲーム後更新情報を含まない。この場合、後述の更新処理部１１５は不要となる。

第１ゲーム状況情報は、その他、ゲームに係る対戦結果に影響しないパラメータの値を含んでよい。例えば、野球ゲームの場合、ゲームに係る対戦結果に影響しないパラメータは、安打数、失点、四死球の数、エラーの数等である。図４に示す第１ゲーム状況情報Ｄ１０１では、ゲームに係る対戦結果に影響しないパラメータは、選手ごとの打撃成績及び投球成績と、チーム全体としての打撃成績及び投球成績である。打撃成績は、安打数等に応じて算出される値であってよく、投球成績は、防御率や奪三振数等に応じて算出される値であってよい。

また、第１ゲーム状況情報は、その他、ゲームに係るプレイヤに関する情報（以下、「プレイヤ状況情報」と称する）を含んでよい。プレイヤ状況情報は、プレイヤのランクやポイントであってよい。図４に示す第１ゲーム状況情報Ｄ１０１では、プレイヤ状況情報は、プレイヤポイントの加点値と、現在のランク値である。

進行処理部１１１は、任意のタイミングで第１ゲーム状況情報を、ゲーム端末１０－１のゲーム状況情報記憶部１２０に記憶してもよい。例えば、進行処理部１１１は、ゲーム状況が変化するごとに、変化後のゲーム状況を表す第１ゲーム状況情報を、ゲーム状況情報記憶部１２０に記憶してもよい。なお、第１ゲーム状況情報は、例えば、記憶部１２のうちの、揮発性メモリ（図示せず）に記憶されてから、記憶部１２のうちの、不揮発性メモリ（ゲーム状況情報記憶部１２０）に転送される態様で記憶される。なお、第１ゲーム状況情報は、最新のものを更新していく記憶方式でゲーム状況情報記憶部１２０に記憶されてよい。

なお、進行処理部１１１は、第１ゲーム状況情報のうちの、属性の異なる情報を、異なるタイミングで更新してもよい。

操作情報送受信処理部１１２は、ネットワークＮを介して第１操作情報をゲーム端末１０－２に送信する操作情報送信処理を実行する。例えば、操作情報送受信処理部１１２は、サーバ装置３０に第１操作情報を送信し、サーバ装置３０が第１操作情報をゲーム端末１０－２に送信する。また、操作情報送受信処理部１１２は、ネットワークＮを介して第２操作情報をゲーム端末１０－２から受信する操作情報受信処理を実行する。例えば、ゲーム端末１０－２の操作情報送受信処理部１１２は、サーバ装置３０に第２操作情報を送信し、サーバ装置３０が第２操作情報をゲーム端末１０－１に送信し、ゲーム端末１０－１の操作情報送受信処理部１１２が第２操作情報を受信する。

結果通知処理部１１３は、通知タイミングで、ゲーム終了の際の第１ゲーム状況情報に基づいて、終了したゲームに係る対戦結果を出力する結果通知処理を実行する。例えば、結果通知処理部１１３は、対戦結果を表示部１５に出力する。通知タイミングは、ゲーム終了の際のタイミングであり、例えば、サーバ装置３０から通信処理部１１８が結果通知指示を受信したタイミングに対応する。なお、サーバ装置３０が結果通知指示を送信するタイミングと結果通知処理が実行されるタイミングは、通信時間や処理時間等があるので厳密には同じでないが、実質的に同じである。以下、区別のため、ゲーム端末１０－１の結果通知処理部１１３に係る通知タイミングを、「第１通知タイミング」と称し、ゲーム端末１０－２の結果通知処理部１１３に係る通知タイミングを、「第２通知タイミング」と称する。

対戦結果の出力は、勝ち負け（又は引き分け）を表す態様であり、更に得点の関係を表す態様であってもよい。例えば、結果通知処理は、得点の関係を表す態様として、第１プレイヤ情報に関連付けられた得点と、第２プレイヤ情報に関連付けられた得点とを出力してもよい。

本実施例では、一例として、結果通知処理部１１３は、ゲームが正常に終了した場合は、得点の関係を表す対戦結果画面を出力し、ゲームが強制的に終了した場合は、得点の関係を表すことなく勝ち負け（又は引き分け）を表す対戦結果画面を出力する。ゲームが正常に終了する場合とは、予め決められたゲームのルールに従って終了する場合である。例えば、野球のゲームの場合、例えば９イニング制で延長なしの場合、９回の裏の攻撃が終了したときに、ゲームが終了する。ゲームが強制的に終了する場合とは、ゲームが正常に終了しない場合であり、後述のリタイアによるゲームが終了する場合を含む。

ゲーム状況情報送信処理部１１４は、ゲームの終了の際に、ゲーム端末１０－１のゲーム状況情報記憶部１２０に記憶される第１ゲーム状況情報をサーバ装置３０に送信する第１ゲーム状況情報送信処理を実行する。ゲーム状況情報送信処理部１１４は、結果通知処理部１１３による結果通知処理よりも前に第１ゲーム状況情報送信処理を実行する。

本実施例では、一例として、ゲーム状況情報送信処理部１１４は、ゲームの終了の際を除いて、ゲーム端末１０－１のゲーム状況情報記憶部１２０に記憶される第１ゲーム状況情報をサーバ装置３０に送信することはない。従って、ゲーム端末１０－１の進行処理部１１１は、ゲーム端末１０－２の進行処理部１１１が生成及び記憶する第２ゲーム状況情報を取得することなく、第１進行処理を実行し、ゲーム端末１０－２の進行処理部１１１は、ゲーム端末１０－１の進行処理部１１１が生成及び記憶する第１ゲーム状況情報を取得することなく、第２進行処理を実行する。

更新処理部１１５は、ゲームの終了の際の第１ゲーム状況情報のうちの第１ゲーム後更新情報以外の情報に基づいて、第１ゲーム後更新情報を更新する更新処理を実行する。以下、区別のため、ゲーム端末１０－１の更新処理部１１５が第１ゲーム後更新情報を更新する更新処理を、「第１更新処理」と称し、ゲーム端末１０－２の更新処理部１１５が第２ゲーム後更新情報を更新する更新処理を、「第２更新処理」と称する。

第１ゲーム後更新情報は、上述のように、第１ゲーム状況情報の対戦能力情報のうちの、ゲーム後更新パラメータの値を表す。

なお、更新処理部１１５は、更に、第１ゲーム後更新情報の更新処理を実行する際に、プレイヤポイントを更新してもよい。プレイヤポイントは、対戦ごとに勝ち（２点）、負（－１点）、引き分け（１点）として、加算されてよい。なお、負けた場合は加算分のプレイヤポイントが０点とされてもよい（すなわち加算なし）。また、得点差に応じて付与されるプレイヤポイントが変化されてもよい。

修正指示処理部１１６は、通信処理部１１８がサーバ装置３０から修正指示（後述）を受信した場合に、修正指示に従って、第１ゲーム状況情報を修正する修正指示処理を実行する。修正指示は、後述するが、ゲームの終了の際の第１ゲーム状況情報及びゲームの終了の際の第２ゲーム状況情報が整合しない場合に生成される。

修正指示処理は、ゲームの終了の際の第１ゲーム状況情報のうちの、ゲームの終了の際の第２ゲーム状況情報に整合しないすべての情報を修正する処理であってもよい。この場合、修正指示処理は、通信処理部１１８が修正指示を受信したタイミングやその後の所定のタイミングで一括して実行されてもよいし、ゲームの終了の際の第１ゲーム状況情報のうちの、一部の情報に対してと、他の情報に対してとで、別々のタイミングで実行されてもよい。
本実施例では、一例として、修正指示処理は、第１ゲーム状況情報のうちの対戦結果関連情報を修正する処理と、第１ゲーム状況情報のうちの対戦能力情報を修正する処理とを含む。

修正指示処理部１１６は、好ましくは、対戦結果関連情報については、第１通知タイミング（結果通知処理の実行タイミング）よりも前の第１修正タイミングで、修正する。これにより、修正された対戦結果関連情報に基づいて対戦結果画面を生成できるので、修正されない対戦結果関連情報に基づいて対戦結果画面を出力した場合にユーザに与えうる違和感を低減できる。

修正指示処理部１１６は、好ましくは、対戦能力情報については、第１通知タイミング（結果通知処理の実行タイミング）よりも後の第２修正タイミングで、修正する。これにより、ゲーム端末１０－２のゲーム実行部１１０は、ゲーム端末１０－１側で対戦能力情報の修正が完了するまで待機することなく、速やかに対戦結果画面を出力し、当該ゲームに係る処理を完了させることができる。すなわち、対戦結果画面を出力するまでの対戦相手（第２プレイヤ）の待ち時間を低減しつつ、例えば処理負荷の低い状況下で対戦能力情報を修正できる。

なお、変形例では、修正指示処理部１１６は、第１修正タイミングで、対戦結果関連情報及び対戦能力情報を修正してもよい。ただし、この場合、対戦能力情報の修正のための処理時間分だけ、対戦結果画面を出力するまでの対戦相手の待ち時間が長くなる。また、他の変形例では、修正指示処理部１１６は、第２修正タイミングで、対戦結果関連情報及び対戦能力情報を修正してもよい。

修正指示処理部１１６は、上述した第１ゲーム後更新情報（ゲーム後更新パラメータの値を表す情報）を修正する場合、第１更新処理により更新された第１ゲーム後更新情報を修正してもよいし、第１更新処理により更新される前の第１ゲーム後更新情報を、サーバ装置３０から通信処理部１１８が受信する置換用の第１ゲーム後更新情報に置き換えることで、更新してもよい。置換用の第１ゲーム後更新情報は、第２ゲーム状況情報に基づいて生成され、例えば第２ゲーム後更新情報と同じであってよい。また、第１ゲーム状況情報が、ゲームに係る対戦結果に影響しないパラメータの値（対戦能力情報以外の情報）を含む場合、修正指示処理部１１６は、当該パラメータの値を、対戦能力情報と同じ第２修正タイミングで修正してもよい。この場合も、第１修正タイミングにおける修正対象の情報項目数を低減できるので、第１修正タイミングにおける修正を速やかに完了できる。この結果、対戦結果画面を出力するまでの対戦相手（第２プレイヤ）の待ち時間を低減できる。

通信処理部１１８は、操作情報送受信処理部１１２、通知処理部１１３、及びゲーム状況情報送信処理部１１４で実行される通信処理以外の各種の通信処理を実行する。例えば、通信処理部１１８は、サーバ装置３０から結果通知指示等を受信したり、サーバ装置３０に接続要求等を送信したりする。

強制終了処理部３０１は、ゲームの正常な終了が通信の遮断に起因して不能となる状態に基づいて、ゲームを強制的に終了する。ゲームの正常な終了が通信の遮断に起因して不能となる状態とは、例えば、通信の遮断が所定期間Ｔ１以上継続した状態であってよい。所定期間Ｔ１は、例えば通信の接続待ち状態の対戦相手が許容できる上限時間に対応するように適合される。なお、所定期間Ｔ１以上経過した場合は、通信の接続待ち状態を継続させるか、あるいは、通信の接続待ち状態を解除する（リタイアによる勝ち）かを対戦相手が選択可能であってもよい。

強制終了処理部３０１は、更に、ゲーム端末１０－１又はゲーム端末１０－２からリタイア要求を受け付けた場合に、ゲームを強制的に終了してもよい。

判定処理部３０２は、ゲームの終了の際の第１ゲーム状況情報及びゲームの終了の際の第２ゲーム状況情報を比較し、比較結果に応じて、ゲームの終了の際の第１ゲーム状況情報及びゲームの終了の際の第２ゲーム状況情報のうちの、一方のゲーム状況情報を、他方のゲーム状況情報に整合するように修正するための修正指示を、ゲーム端末１０－１、１０－２のゲーム実行部１１０に送信する。本実施例では、判定処理部３０２は、ゲームの終了の際の第１ゲーム状況情報及びゲームの終了の際の第２ゲーム状況情報が整合するか否かを判定し、整合しないと判定した場合に、ゲーム端末１０－１及び／又はゲーム端末１０－２のゲーム実行部１１０に修正指示を送信する。

判定処理部３０２は、整合性判定部３０３と、修正指示生成部３０４と、ゲームデータ修正部３０６とを含む。

整合性判定部３０３は、ゲームの終了の際の第１ゲーム状況情報及びゲームの終了の際の第２ゲーム状況情報が整合するか否か、言い換えると、第１ゲーム状況情報と第２ゲーム状況情報とが同じか否かを判定する判定処理を行う。なお、ゲームの終了の際とは、ある対戦に係るゲームが終了した際を意味する。ある対戦とは、勝敗が決まる単位であるが、複数の対戦セットが１つの対戦を形成する場合は対戦セットの単位であってもよいし、前半の対戦や後半の対戦のように区切られた単位であってもよい。ゲームの終了とは、ゲームの正常な終了のみならず、ゲームの強制的な終了をも含む。

ゲームの終了の際の第１ゲーム状況情報は、ゲームの終了の際にゲーム端末１０－１のゲーム状況情報記憶部１２０（第１記憶部の一例）に記憶されている第１ゲーム状況情報に対応し、以下、単に「第１ゲーム状況情報」と称する。同様に、ゲームの終了の際の第２ゲーム状況情報は、例えば、ゲームの終了の際にゲーム端末１０－２のゲーム状況情報記憶部１２０（第２記憶部の一例）に記憶されている第２ゲーム状況情報に対応し、以下、単に「第２ゲーム状況情報」と称する。なお、整合性判定部３０３は、ゲームの終了の際に、ゲーム端末１０－１から第１ゲーム状況情報を、ゲーム端末１０－２から第２ゲーム状況情報を、それぞれ受信すると、所定の記憶部（例えばゲームデータ記憶部３２０）に第１ゲーム状況情報及び第２ゲーム状況情報を記憶する。

第１ゲーム状況情報と第２ゲーム状況情報とが整合しない場合とは、例えば第１ゲーム状況情報におけるある選手に関する投球数が、第２ゲーム状況情報における同選手に関する投球数と異なる場合である。また、第１ゲーム状況情報におけるある選手に関するスタミナが、第２ゲーム状況情報における同選手に関するスタミナと異なる場合である。また、第１ゲーム状況情報におけるあるイニングの得点が、第２ゲーム状況情報における同イニングの得点と異なる場合である。また、第１ゲーム状況情報における第１プレイヤに関連付けられた本塁打の数が、第２ゲーム状況情報における第２プレイヤに関連付けられた被本塁打の数と異なる場合である。

整合性判定部３０３は、ゲームの終了の際に、判定処理を行ってよい。具体的には、整合性判定部３０３は、第１通知タイミングよりも前に、第１ゲーム状況情報及び第２ゲーム状況情報のすべての属性に係る情報について、又は、対戦結果関連情報及び対戦能力情報について、判定処理を行ってもよい。あるいは、対戦結果関連情報について修正しない変形例では、整合性判定部３０３は、ゲームの終了後（次のゲームの開始時までに）、判定処理を行ってもよい。
ただし、整合性判定部３０３は、好ましくは、ゲームの終了の際に、第１ゲーム状況情報及び第２ゲーム状況情報のうちの対戦結果関連情報に関してのみ判定処理を行い、ゲームの終了後（次のゲームの開始時までに）、第１ゲーム状況情報及び第２ゲーム状況情報のうちの対戦能力情報に関して判定処理を行ってもよい。より具体的には、整合性判定部３０３は、第１通知タイミングよりも前に、第１ゲーム状況情報及び第２ゲーム状況情報のうちの対戦結果関連情報に関してのみ判定処理を行い、第１通知タイミングよりも後に（次のゲームの開始時までに）、第１ゲーム状況情報及び第２ゲーム状況情報のうちの対戦能力情報に関して判定処理を行ってもよい。この場合、ゲームの終了の際に、第１ゲーム状況情報及び第２ゲーム状況情報間のすべての情報の整合性を判定する場合に比べて、ゲームの終了時点から第１通知タイミングまでの時間を短くできる。

修正指示生成部３０４は、整合性判定部３０３が第１ゲーム状況情報と第２ゲーム状況情報とが整合しないと判定した場合に、第１ゲーム状況情報と第２ゲーム状況情報のうちの少なくとも一方のゲーム状況情報を修正するための修正指示を生成する。

ここで、上述したように、このような不整合が生じる原因は、例えば、単なるバグや、いわゆる同期ずれと呼ばれる類のバグ、キャッシュの不具合、ゲーム中の電源の遮断（電源オフ操作）等がありうる。揮発性メモリへの記憶と不揮発性メモリへの記憶にはソフトウェアによるタイムラグがあるので、例えば、ゲーム端末１０－１のゲーム実行部１１０において、不揮発性メモリに揮発性メモリ内のゲーム状況情報が転送（更新）される前に電源の遮断が生じると、第１ゲーム状況情報が第２ゲーム状況情報と整合しない状況が生じる。

なお、単なるバグ、いわゆる同期ずれと呼ばれる類のバグは、主にゲーム端末１０－１のユーザ固有の設定（例えば、仮想カメラ）に基づいてゲーム処理を行った場合、初期化した乱数を使わなかった場合、ゲーム処理以外の処理において、初期化した乱数を使ってしまった場合、メモリ破壊、メモリオーバー、変数の初期化忘れ、スレッドセーフに実装されていない場合等で生じやすい。特に、オンラインゲームはオンラインアップデートを頻繁に繰り返すため、バグが混入しやすい。

修正指示生成部３０４は、整合性判定部３０３が第１ゲーム状況情報と第２ゲーム状況情報とが整合しないと判定した場合に、いずれか一方のゲーム状況情報を“偽”と看做し、他方のゲーム状況情報を“真”と看做してよい。この場合、修正指示生成部３０４は、“真”と看做したゲーム状況情報に、“偽”と看做したゲーム状況情報に合わせる態様で、“偽”と看做したゲーム状況情報が修正されるような修正指示（修正指示処理部１１６に対する修正指示）を生成する。すなわち、“偽”と看做したゲーム状況情報を、“真”と看做したゲーム状況情報に更新させる修正指示を生成する。あるいは、修正指示生成部３０４は、第１ゲーム状況情報と第２ゲーム状況情報とが整合しない場合に、双方の中間値等に双方が修正されるような修正指示を生成してもよい。あるいは、サーバ装置３０は、ゲーム処理を再現することで正しいゲーム状況情報を導出し、当該正しいゲーム状況情報に整合するように第１ゲーム状況情報及び／又は第２ゲーム状況情報が修正されるような修正指示を生成してもよい。

本実施例では、一例として、修正指示生成部３０４は、整合性判定部３０３が第１ゲーム状況情報と第２ゲーム状況情報とが整合しないと判定した場合に、第１ゲーム状況情報と第２ゲーム状況情報とが整合するように、第１ゲーム状況情報と第２ゲーム状況情報の一方を修正するための修正指示を生成するものとする。

修正指示生成部３０４は、所定のルールに従って、第１ゲーム状況情報と第２ゲーム状況情報のうちのいずれか一方を、“偽”と看做す。所定のルールは、任意であり、例えば、ゲーム端末１０－１及びゲーム端末１０－２のうちの、ゲーム中の通信遮断回数が多い方のゲーム端末に係るゲーム状況情報を、“偽”と看做してもよい。

あるいは、修正指示生成部３０４は、第１ゲーム状況情報と第２ゲーム状況情報のうちの、サーバ装置３０に早く受信された方を、“真”と看做してもよい。この場合、簡易なルールで、第１ゲーム状況情報と第２ゲーム状況情報のうちの、“偽”と看做すゲーム状況情報を決定できる。

なお、修正指示生成部３０４は、第１ゲーム状況情報と第２ゲーム状況情報のうちの一方がサーバ装置３０に受信されない場合、サーバ装置３０に受信されない方のゲーム状況情報を、“偽”と看做してもよい。例えば、ゲーム端末１０－１及びゲーム端末１０－２のうちのいずれかにおいて、ゲーム中の電源の遮断（電源オフ操作）があった場合、電源の遮断があった方のゲーム端末からのゲーム状況情報は、サーバ装置３０に受信されない。従って、この場合、電源の遮断がない方のゲーム端末に係るゲーム状況情報が、“真”と看做されることになる。

修正指示生成部３０４は、修正指示を生成すると、ゲーム端末１０－１及びゲーム端末１０－２のうちの、修正対象のゲーム状況情報を記憶しているゲーム端末に、修正指示を送信する。このようにして修正指示が送信されると、ゲーム端末１０－１及びゲーム端末１０－２のうちの、修正指示を受信したゲーム端末において修正指示処理部１１６によりゲーム状況情報が修正されることになるので、ゲーム端末１０－１及びゲーム端末１０－２において記憶されるゲーム状況情報は同じになる。

修正指示は、修正内容を示す情報を含んでよい。例えば、ある選手のスタミナについて、“偽”と看做したゲーム状況情報では“８”であるのに対して、“真”と看做したゲーム状況情報では“７”である場合、“８”を“７”に修正する修正内容となる。

あるいは、修正指示は、“真”と看做したゲーム状況情報のうちのすべて又は一部（修正すべき部分）をゲーム端末１０－１又はゲーム端末１０－２に送信することで実現されてもよい。この場合、“真”と看做されたゲーム状況情報を受信したゲーム端末１０－１又はゲーム端末１０－２は、当該ゲーム状況情報に基づいて、ゲーム状況情報記憶部１２０に記憶されているゲーム状況情報（“偽”と看做されたゲーム状況情報）を修正してよい。

また、第１ゲーム状況情報の対戦能力情報のうちの、上述の第１ゲーム後更新情報を修正する場合は、修正指示生成部３０４は、ゲーム端末１０－１に、置換用の第１ゲーム後更新情報を送信してもよい。この場合、修正指示生成部３０４は、第２ゲーム状況情報に基づいて置換用の第１ゲーム後更新情報を生成する。また、上述の第２ゲーム後更新情報を修正する場合は、修正指示生成部３０４は、ゲーム端末１０－２に、置換用の第２ゲーム後更新情報を送信してもよい。この場合、修正指示生成部３０４は、第１ゲーム状況情報に基づいて置換用の第２ゲーム後更新情報を生成する。

修正指示の送信タイミングは、上述した第１修正タイミング及び第２修正タイミングに応じて決定される。例えば、対戦結果関連情報についての修正指示の送信タイミングは、修正指示処理部１１６が上述した第１修正タイミングで修正を行えるように、第１通知タイミング（結果通知処理の実行タイミング）よりも前に設定される。換言すると、修正指示生成部３０４は、対戦結果関連情報についての修正指示の送信後に、第１通知タイミングに係る結果通知処理の実行を許可してよい。

同様に、対戦能力情報についての修正指示の送信タイミングは、第１通知タイミング（結果通知処理の実行タイミング）よりも後に設定されてもよい。換言すると、修正指示生成部３０４は、対戦能力情報についての修正指示の送信後に、次のゲームの実行を許可してよい。ただし、第１修正タイミング及び第２修正タイミングはゲーム端末１０－１において調整できるので、対戦結果関連情報及び対戦能力情報についての修正指示の送信タイミングは、第１通知タイミング（結果通知処理の実行タイミング）よりも前に設定されてもよい。

ゲームデータ修正部３０６は、整合性判定部３０３が第１ゲーム状況情報と第２ゲーム状況情報とが整合しないと判定した場合に、ゲームデータ記憶部３２０内のゲームデータを修正する。

本実施例では、一例として、ゲームデータ記憶部３２０内のゲームデータは、各チームに係る各種情報を含むチーム情報や、ゲーム端末１０－１からの第１ゲーム状況情報及びゲーム端末１０－２からの第２ゲーム状況情報を含む。例えば、図５に示すゲームデータＤ５０は、プレイヤＩＤごとに、チーム全体の情報Ｄ５２と、保有選手の情報Ｄ５４と、対戦ＩＤごとのゲーム状況情報Ｄ５６とを含む。第１ゲーム状況情報及び第２ゲーム状況情報がサーバ装置３０に送信されてくると、ゲームデータ記憶部３２０には、第１ゲーム状況情報及び第２ゲーム状況情報がそのままの形式で記憶されてもよいし、加工された形式で記憶されてもよい。

ゲームデータ修正部３０６は、整合性判定部３０３が第１ゲーム状況情報と第２ゲーム状況情報とが整合しないと判定した場合に、ゲームデータ記憶部３２０内のゲームデータのうちの、“真”と看做したゲーム状況情報に基づいて、“偽”と看做したゲーム状況情報を修正する。この場合、ゲームデータのうちの、ゲーム状況情報は、“真”と看做したゲーム状況情報で置換される態様で、又は、“真”と看做したゲーム状況情報に基づいて修正される態様で、修正されてよい。これにより、ゲームデータのうちの、対戦ＩＤごとのゲーム状況情報のような情報に対しては、上述した修正指示に係る修正と同様の修正が反映される。なお、ゲームデータ修正部３０６は、ゲームデータのうちの、ゲーム状況情報以外の情報も、“真”と看做したゲーム状況情報に基づいて修正してもよい。なお、変形例では、ゲームデータ修正部３０６は省略されてもよい。

このようにして、本実施例では、サーバ装置３０の判定処理部３０２と、ゲーム端末１０－１又はゲーム端末１０－２の修正指示処理部１１６とは、協動して修正処理を実行する。

従って、本実施例では、ゲーム端末１０－１及びゲーム端末１０－２の各ゲーム実行部１１０によりそれぞれ記憶される第１ゲーム状況情報及び第２ゲーム状況情報間における不整合（ゲームの終了の際の第１及び第２ゲーム状況情報間における不整合）を、修正することが可能となる。

ゲームの終了の際のゲーム状況情報間の不整合が修正されないと、ユーザに違和感を与えたり、不利になる方向へのゲーム状況情報の更新を妨げるために電源オフ操作が誘発されたりするおそれがある。

具体的には、ゲーム中に電源オフ操作等によりゲームアプリが強制終了した場合、強制終了したゲームアプリ側の勝敗が負け（リタイアによる敗北）になることは確定する。しかしながら、強制終了したゲームアプリからは、ゲーム状況情報がサーバ装置３０に送れないため、サーバ装置３０は、ゲーム状況情報を受け取れない。その結果、強制終了したゲーム中のスタミナの値が更新されず、強制終了したゲームアプリのユーザは、当該ゲームに敗北しても次のゲームが有利になる。そして、ゲームが不利になった場合に電源オフ操作を誘発させてしまうおそれがある。一方、対戦相手のゲームアプリの強制終了によってゲームが終了すると、ゲームを有利に進めているユーザのモチベーションが低下する、という問題もある。

この点、実施例では、ゲームの終了の際のゲーム状況情報間の不整合が修正されるので、上記の問題は生じない。すなわち、本実施例では、ゲーム中にゲームアプリが強制終了した場合でも、次のゲームまでに、強制終了したゲームアプリ側のゲーム状況情報のうちの対戦能力情報が修正される。従って、本実施例によれば、電源オフ操作が誘発されることや、ゲームを有利に進めているユーザのモチベーションの低下等を防止できる。

ところで、本実施例では、サーバ装置３０は、ゲーム端末１０－１及びゲーム端末１０－２のそれぞれでどのようなゲーム処理が実行されているかを、ゲーム中に確認（再現）していない。ゲーム端末１０－１及びゲーム端末１０－２間でやり取りするデータはすべてサーバ装置３０を経由するため、サーバ装置３０は、ゲーム端末１０－１及びゲーム端末１０－２のそれぞれで行っているゲーム処理をサーバ装置でも確認できるようにするためだけに、ゲーム処理を実行することはできる。しかしながら、現実的には、対戦している数千、数万の対戦に係るゲーム処理をサーバ装置３０で確認できるようにするためだけに、サーバ装置３０で同様のゲーム処理を再現することは、サーバ負担やサーバ運用費用の観点から現実的ではない。

この点、本実施例によれば、サーバ装置３０は、第１ゲーム状況情報と第２ゲーム状況情報とが整合しない場合に、対応するゲーム処理をサーバ装置３０で再現して修正するのではなく、ゲーム端末１０－１及びゲーム端末１０－２のうちの一方からのゲーム状況情報（“偽”と看做されたゲーム状況情報）を、他方からのゲーム状況情報（“真”と看做されたゲーム状況情報）に基づいて修正する。ここで、“真”と看做されたゲーム状況情報は、ゲーム端末１０－１、１０－２のいずれかから送信されてくる情報であるので、サーバ装置３０は、かかる情報を利用して、比較的軽い処理負荷で修正指示を生成できる。すなわち、ゲーム処理をサーバ装置３０で再現する場合に比べて、サーバ装置３０の負荷を低減できる。

なお、本実施例では、対戦結果関連情報を修正する処理（第１修正処理の一例）と、対戦能力情報を修正する処理（第２修正処理の一例）の双方が実行されるが、いずれか一方だけが実行されてもよい。

図６Ａは、ゲーム端末１０－１、ゲーム端末１０－２、及びサーバ装置３０の３者間でのデータ（情報）のやり取り（通信）を概略的に示す図である。なお、図６Ａ（後出の図６Ｂ～図６Ｆも同様）は、概略図であり、３者間でのデータ（情報）のやり取りのすべてを図示しているわけではない。図６Ａは、ゲームが正常に終了する場合を示す。図６Ａでは、ゲーム端末１０－１、ゲーム端末１０－２、及びサーバ装置３０の３者間を結ぶ点線は、データ（情報）のやり取りを示し、各ブロックは、ゲーム端末１０－１、ゲーム端末１０－２、又はサーバ装置３０の処理を示す。なお、図６Ａでは、各ブロック間の実線の矢印の方向が時間の経過方向に対応するが、順序を示しているだけであり、時間の経過方向で同じ位置のブロックの処理が同時に実行されることを意味しているわけではない。図６Ｃは、他の例によるゲーム端末１０－１、ゲーム端末１０－２、及びサーバ装置３０の３者間でのデータ（情報）のやり取り（通信）を概略的に示す図である。図６Ｄは、比較例の説明図である。ここでは、図６Ａについて、図６Ｃ及び図６Ｄとの対比で説明する。図６Ｃに示す態様は、図６Ａに示す態様に比べて、処理の順序が異なるだけであり、同じ処理については同じ符号を付している。また、図６Ｄに示す比較例は、修正部２００を備えていない構成に関する。

ゲームの開始時、サーバ装置３０は、進行処理に必要な初期データをゲーム端末１０－１及びゲーム端末１０－２に送信し（ＴＳ２）、ゲーム端末１０－１及びゲーム端末１０－２のそれぞれの通信処理部１１８がそれぞれ初期データを受信する（ＴＡ２、ＴＢ２）。初期データは、例えば、共通の乱数シードと、第１プレイヤ情報に対応付けられたチーム情報（第１ゲームデータの一例）と、第２プレイヤ情報に対応付けられたチーム情報（第２ゲームデータの一例）とを含む。第１プレイヤに対応付けられたチーム情報は、第１プレイヤ情報に関連付けられた各ゲームオブジェクト（選手）に関するデータを含み、第２プレイヤ情報に対応付けられたチーム情報は、第２プレイヤ情報に関連付けられた各ゲームオブジェクト（選手）に関するデータを含む。

ゲームが開始されると、第２操作情報と第１操作情報とがサーバ装置３０を介してゲーム端末１０－１及びゲーム端末１０－２の間でやり取りされながら、ゲーム端末１０－１においては第１進行処理が実行され、ゲーム端末１０－２においては第２進行処理が実行される。

図６Ａに示す例では、まず、ゲーム端末１０－２側の攻撃のセッションＳＣ１である。セッションＳＣ１では、ゲーム端末１０－１の操作情報送受信処理部１１２は、投手を表すゲームオブジェクトの投球動作に係る第１操作情報をサーバ装置３０に送信し（ＴＡ４）、サーバ装置３０は、当該第１操作情報をゲーム端末１０－２に送信し（ＴＳ４）、ゲーム端末１０－２の操作情報送受信処理部１１２は、当該第１操作情報を受信する（ＴＢ４）。次いで、ゲーム端末１０－２の操作情報送受信処理部１１２は、当該第１操作情報に対する第２操作情報であって、打者を表すゲームオブジェクトの打撃動作に係る第２操作情報を、サーバ装置３０に送信し（ＴＢ６）、サーバ装置３０は、当該第２操作情報をゲーム端末１０－１に送信し（ＴＳ６）、ゲーム端末１０－１の操作情報送受信処理部１１２は、当該第２操作情報を受信する（ＴＡ６）。ゲーム端末１０－２の進行処理部１１１及びゲーム端末１０－１の進行処理部１１１は、それぞれ、このようにして得られた投球動作に係る第１操作情報と打撃動作に係る第２操作情報と初期データとに基づいて、第２進行処理及び第１進行処理を実行する（ＴＢ８、ＴＡ８）。図６Ａでは、ゲーム端末１０－２側の攻撃のセッションＳＣ１は、１回のデータのやり取りしか含んでいないが、実際には、ゲーム端末１０－２側の攻撃が終了するまで、繰り返される。なお、セッションＳＣ１は、第１操作情報及び第２操作情報に基づくことなくゲームが自動進行するパートを含んでもよい。

ゲーム端末１０－２側の攻撃のセッションＳＣ１では、上述の第２進行処理及び第１進行処理が実行されるごとに、ゲーム端末１０－１のゲーム状況情報記憶部１２０における第１ゲーム状況情報及びゲーム端末１０－２のゲーム状況情報記憶部１２０における第２ゲーム状況情報が更新されていく。

次いで、ゲーム端末１０－１側の攻撃のセッションＳＣ２である。セッションＳＣ２では、ゲーム端末１０－２の操作情報送受信処理部１１２は、投手を表すゲームオブジェクトの投球動作に係る第２操作情報をサーバ装置３０に送信し（ＴＢ１０）、サーバ装置３０は、当該第２操作情報をゲーム端末１０－１に送信し（ＴＳ８）、ゲーム端末１０－１の操作情報送受信処理部１１２は、当該第２操作情報を受信する（ＴＡ１０）。次いで、ゲーム端末１０－１の操作情報送受信処理部１１２は、当該第２操作情報に対する第１操作情報であって、打者を表すゲームオブジェクトの打撃動作に係る第１操作情報を、サーバ装置３０に送信し（ＴＡ１２）、サーバ装置３０は、当該第１操作情報をゲーム端末１０－２に送信し（ＴＳ１０）、ゲーム端末１０－２の操作情報送受信処理部１１２は、当該第１操作情報を受信する（ＴＢ１２）。ゲーム端末１０－１の進行処理部１１１及びゲーム端末１０－２の進行処理部１１１は、それぞれ、このようにして得られた投球動作に係る第２操作情報と打撃動作に係る第１操作情報と初期データとに基づいて、第１進行処理及び第２進行処理を実行する（ＴＡ１４、ＴＢ１４）。図６Ａでは、ゲーム端末１０－１側の攻撃のセッションＳＣ２は、１回のデータのやり取りしか含んでいないが、実際には、ゲーム端末１０－１側の攻撃が終了するまで、繰り返される。なお、セッションＳＣ２は、第１操作情報及び第２操作情報に基づくことなくゲームが自動進行するパートを含んでもよい。

ゲーム端末１０－１側の攻撃のセッションＳＣ２では、上述の第１進行処理及び第２進行処理が実行されるごとに、ゲーム端末１０－１のゲーム状況情報記憶部１２０における第１ゲーム状況情報及びゲーム端末１０－２のゲーム状況情報記憶部１２０における第２ゲーム状況情報が更新されていく。

このようにしてセッションＳＣ１及びセッションＳＣ２が交互に繰り返されてゲームが正常に終了すると、ゲーム端末１０－１のゲーム状況情報送信処理部１１４は、ゲーム状況情報記憶部１２０内の第１ゲーム状況情報（ゲームの終了の際の第１ゲーム状況情報）をサーバ装置３０に送信し（ＴＡ１６）、ゲーム端末１０－２のゲーム状況情報送信処理部１１４は、ゲーム状況情報記憶部１２０内の第２ゲーム状況情報（ゲームの終了の際の第２ゲーム状況情報）をサーバ装置３０に送信する（ＴＢ１６）。

サーバ装置３０の整合性判定部３０３は、ゲームの終了に伴って第１ゲーム状況情報及び第２ゲーム状況情報を受信すると（ＴＳ１２）、第１ゲーム状況情報及び第２ゲーム状況情報間の整合性のうちの、対戦結果関連情報についての整合性を判定する処理（第１整合性判定処理）を行う（ＴＳ１４）。図６Ａでは、第１ゲーム状況情報及び第２ゲーム状況情報は、対戦結果関連情報が整合しておらず、第２ゲーム状況情報が“偽”と看做された場合を想定する。この場合、サーバ装置３０の修正指示生成部３０４は、第２ゲーム状況情報のうちの、対戦結果関連情報についての修正指示を、ゲーム端末１０－２に送信する（ＴＳ１６）。

ゲーム端末１０－２の修正指示処理部１１６は、ゲーム端末１０－２の通信処理部１１８が対戦結果関連情報についての修正指示を受信すると（ＴＢ１８）、第２ゲーム状況情報のうちの、対戦結果関連情報を修正し（ＴＢ２０）、ゲーム端末１０－２の通信処理部１１８から第１修正完了通知をサーバ装置３０に送信させる（ＴＢ２２）。なお、第１修正完了通知は、対戦結果関連情報が修正された第２ゲーム状況情報を含んでもよいし、修正された対戦結果関連情報だけを含んでもよい。

サーバ装置３０は、第１修正完了通知を受信すると（ＴＳ１８）、結果通知指示をゲーム端末１０－１及びゲーム端末１０－２に送信する（ＴＳ２０）。なお、サーバ装置３０は、第２ゲーム状況情報を“偽”と看做した際に（例えば対戦結果関連情報についての修正指示をゲーム端末１０－２に送信する際に）、結果通知指示をゲーム端末１０－１に送信してもよい。この場合、第１修正完了通知を受信した後に結果通知指示をゲーム端末１０－１に送信する場合に比べて、ゲーム端末１０－１における次の結果通知処理（ＴＳ２０）の実行タイミングを早めることができる。

ゲーム端末１０－１の結果通知処理部１１３は、ゲーム端末１０－１の通信処理部１１８が結果通知指示を受信すると（ＴＡ１８）、結果通知処理を実行する（ＴＡ２０）。その後、ゲーム端末１０－１は、今回のゲームに係る処理を完了させる。

ゲーム端末１０－２の結果通知処理部１１３は、ゲーム端末１０－２の通信処理部１１８が結果通知指示を受信すると（ＴＢ２４）、結果通知処理を実行する（ＴＢ２６）。この場合、ゲーム端末１０－２の結果通知処理部１１３は、修正後の対戦結果関連情報に基づいて結果通知処理を実行する。

その後、サーバ装置３０の修正指示生成部３０４は、第１ゲーム状況情報及び第２ゲーム状況情報間の整合性のうちの、対戦能力情報についての整合性を判定する処理（第２整合性判定処理）を行う（ＴＳ２２）。図６Ａでは、第１ゲーム状況情報及び第２ゲーム状況情報は、対戦能力情報が整合していない場合を想定する。なお、上述のように第２ゲーム状況情報が“偽”と看做されている。この場合、サーバ装置３０の修正指示生成部３０４は、第２ゲーム状況情報のうちの、対戦能力情報についての修正指示を、ゲーム端末１０－２に送信する（ＴＳ２４）。ゲーム端末１０－２の修正指示処理部１１６は、ゲーム端末１０－２の通信処理部１１８が対戦能力情報についての修正指示を受信すると（ＴＢ２８）、第２ゲーム状況情報のうちの、対戦能力情報を修正する（ＴＢ３０）。その後、ゲーム端末１０－２は、今回のゲームに係る処理を完了させる。

ここで、図６Ａに示す例との対比として、図６Ｄに示す比較例では、ゲームの終了の際のゲーム状況情報間の不整合が修正されないので、かかる不整合が放置されることに起因した上述した不都合が生じる。すなわち、ユーザに違和感を与えたり、不利になる方向へのゲーム状況情報の更新を妨げるために電源オフ操作が誘発されたり、バグ等に起因した誤ったゲーム状況情報が次のゲームに使用されたりする等の不都合が生じる。

この点、図６Ａに示す例によれば、ゲームの終了の際のゲーム状況情報間の不整合が修正されるので、かかる不整合が放置されることに起因した上述した不都合を、低減できる。また、図６Ａに示す例によれば、セッションＳＣ３の同期状態では、サーバ装置３０は、ゲーム中に第１操作情報及び第２操作情報を転送するだけであるので、サーバ装置３０の処理負荷を低減できる。

ここで、図６Ａでは、セッションＳＣ３は、ゲーム端末１０－１とゲーム端末１０－２とがサーバ装置３０を介して情報をやり取りしながらそれぞれの処理を行う状態（同期状態）に対応し、セッションＳＣ４は、ゲーム端末１０－１とゲーム端末１０－２との間が互いに対して独立した態様で処理を行う状態（非同期状態）に対応する。すなわち、結果通知指示（ＴＳ２０）が送受されることで開始されるセッションＳＣ４は、ゲーム端末１０－１及びゲーム端末１０－２が、互いからの情報を必要とせずに処理を行うことができる状態である。他方、同期状態では、例えばゲーム端末１０－１側では、ゲーム端末１０－２からの情報が取得されていない場合、当該情報が取得されるまで待機させられる。

図６Ａに示す例との対比として、図６Ｃに示す例では、対戦結果関連情報を修正する処理（ＴＳ１４、ＴＳ１６、ＴＢ１８、ＴＢ２０）（第１修正処理の一例）と、対戦能力情報を修正する処理（ＴＳ２２、ＴＳ２４、ＴＢ２８、ＴＢ３０）（第２修正処理の一例）とが同じタイミングで、すなわち、結果通知指示（ＴＳ２０）よりも前に実行されている。この場合、ゲーム端末１０－１は、ゲーム端末１０－２での対戦能力情報の修正が完了するまで同期状態で待機する必要があり、その分だけ、今回のゲームに係る処理を完了できるまでの時間が遅れてしまう。

この点、図６Ａに示す例によれば、ゲームが正常に終了する場合、対戦結果関連情報を修正する処理（ＴＳ１４、ＴＳ１６、ＴＢ１８、ＴＢ２０）（第１修正処理の一例）と、対戦能力情報を修正する処理（ＴＳ２２、ＴＳ２４、ＴＢ２８、ＴＢ３０）（第２修正処理の一例）とが異なるタイミングで実行される。これにより、ゲーム端末１０－１は、ゲーム端末１０－２での対戦能力情報の修正が完了するまで同期状態で待機する必要がなく、速やかに今回のゲームに係る処理を完了できる。すなわち、ゲーム端末１０－２での比較的時間のかかる対戦能力情報の修正のための各種処理（ＴＳ２２、ＴＳ２４、ＴＢ２８、ＴＢ３０）を、結果通知指示（ＴＳ２０）よりも後回しにすることで、ゲーム端末１０－１を同期状態から解放して、ゲーム端末１０－１に速やかに結果通知処理を実行させることができる。
なお、変形例では、第２整合性判定処理（ＴＳ２２）は、第１整合性判定処理（ＴＳ１４）と同じタイミングで実行されてもよい。この場合でも、対戦能力情報を修正する処理の一部（ＴＳ２４、ＴＢ２８、ＴＢ３０）が結果通知指示（ＴＳ２０）よりも後回しされるので、図９Ｃに示す例に比べて、ゲーム端末１０－１に速やかに結果通知処理を実行させることができる。

なお、図６Ｃには図示されていないが、ゲーム端末１０－２の修正指示処理部１１６は、第２ゲーム状況情報のうちの対戦能力情報を修正すると（ＴＢ３０）、ゲーム端末１０－２の通信処理部１１８から第２修正完了通知をサーバ装置３０に送信させてもよい。なお、第２修正完了通知は、対戦能力情報が修正された第２ゲーム状況情報を含んでもよいし、修正された対戦能力情報だけを含んでもよい。この場合、サーバ装置３０は、第２修正完了通知を受信すると、結果通知指示をゲーム端末１０－１及びゲーム端末１０－２に送信してよい（ＴＳ２０）。あるいは、ゲーム端末１０－２の修正指示処理部１１６は、ゲーム端末１０－２の通信処理部１１８が対戦能力情報についての修正指示を受信すると、対戦能力情報を修正する前に、ゲーム端末１０－２の通信処理部１１８から応答通知をサーバ装置３０に送信させてもよい。この場合、サーバ装置３０は、当該応答通知を受信すると、結果通知指示をゲーム端末１０－１及びゲーム端末１０－２に送信してよい（ＴＳ２０）。

図６Ｂは、ゲーム端末１０－１、ゲーム端末１０－２、及びサーバ装置３０の３者間でのデータ（情報）のやり取りを概略的に示す図である。図６Ｂは、ゲームが強制的に終了する場合を示す点で、ゲームが正常に終了する場合を示す図６Ａと異なる。図６Ｂに関しては、図６Ａと異なる点について主に説明し、図６Ａと実質的に同様の処理については、同一の参照符号を付して説明を省略又は簡略化する場合がある。

図６Ｂは、図６Ａに対して、ゲーム端末１０－１に関しては、ＴＡ１６の前にＴＡ４０が追加された点が異なり、サーバ装置３０に関しては、ＴＳ４０、ＴＳ４２、ＴＳ４４が追加され、かつ、ＴＳ１４、ＴＳ１６、ＴＳ１８が削除された点が異なり、ゲーム端末１０－２に関しては、ＴＢ４０、ＴＢ４２が追加され、かつ、ＴＢ１６～ＴＢ２６が削除された点が異なる。

図６Ｂでは、セッションＳＣ３の最中に、ゲーム端末１０－２の電源が遮断された場合（あるいは電源遮断に起因せずにゲームアプリが強制終了された場合）が想定される。この場合、サーバ装置３０の強制終了処理部３０１は、ゲームの正常な終了が通信の遮断に起因して不能となる状態に基づいて、ゲームを強制的に終了する（ＴＳ４０）。サーバ装置３０は、ゲームを強制的に終了すると、ゲーム終了要求をゲーム端末１０－１に通知する（ＴＳ４２）。なお、ゲーム端末１０－２においては、電源が遮断される前までのデータが正常に保存されていない場合等に、第２ゲーム状況情報が第１ゲーム状況情報に対して整合しない状態となる。

ゲーム端末１０－１のゲーム状況情報送信処理部１１４は、ゲーム端末１０－１の通信処理部１１８がゲーム終了要求を受信すると（ＴＡ４０）、ゲーム状況情報記憶部１２０内の第１ゲーム状況情報（ゲームの終了の際の第１ゲーム状況情報）をサーバ装置３０に送信する（ＴＡ１６）。

サーバ装置３０は、ゲームの終了に伴って第１ゲーム状況情報を受信すると（ＴＳ１２）、整合性判定部３０３による第１整合性判定処理（ＴＳ１４）後、結果通知指示をゲーム端末１０－１に送信する（ＴＳ２０）。ゲーム端末１０－１の結果通知処理部１１３は、ゲーム端末１０－１の通信処理部１１８が結果通知指示を受信すると（ＴＡ１８）、結果通知処理を実行する（ＴＡ２０）。

一方、ゲーム端末１０－２の通信処理部１１８は、電源が投入されかつゲームシステム１に係るアプリケーションが起動（復帰）すると（ＴＢ４０）、サーバ装置３０に接続要求を送信する（ＴＢ４２）。

サーバ装置３０の修正指示生成部３０４は、接続要求を受信すると（ＴＳ４４）、接続処理を行ってから、第２ゲーム状況情報のうちの対戦能力情報についての修正指示を、ゲーム端末１０－２に送信する（ＴＳ２４）。ゲーム端末１０－２の修正指示処理部１１６は、ゲーム端末１０－２の通信処理部１１８が対戦能力情報についての修正指示を受信すると（ＴＢ２８）、第２ゲーム状況情報のうちの、対戦能力情報を修正する（ＴＢ３０）。

このように、図６Ｂに示す例によれば、ゲームが強制的に終了する場合、対戦能力情報を修正する処理（ＴＳ２２、ＴＳ２４、ＴＢ２８、ＴＢ３０）（第２修正処理の一例）が実行される。これにより、不利になる方向へのゲーム状況情報の更新を妨げるための電源オフ操作のような、ゲーム性を損なうような電源オフ操作が誘発される可能性を低減できる。

なお、図６Ｂに示す例では、第２整合性判定処理（ＴＳ２２）は、接続要求の受信（ＴＳ４４）前に実行されているが、接続要求の受信（ＴＳ４４）後に実行されてもよい。

図６Ｅは、他の例による３者間でのデータ（情報）のやり取りを概略的に示す図である。図６Ｅは、図６Ａと同様、ゲームが正常に終了する場合を示すが、図６Ｅを参照して以下で説明する処理は、ゲームが強制的に終了する場合でも適用可能である。

図６Ｅに関しては、図６Ａと異なる点について主に説明し、図６Ａと実質的に同様の処理については、同一の参照符号を付して説明を省略又は簡略化する場合がある。

図６Ｅは、図６Ａに対して、ゲーム端末１０－１に関しては、ＴＡ５０が追加された点が異なり、サーバ装置３０に関しては、ＴＳ５０が追加された点が異なり、ゲーム端末１０－２に関しては、ＴＢ５０、ＴＢ５２、ＴＢ５４が追加された点が異なる。

ゲーム端末１０－１の更新処理部１１５は、ゲーム状況情報記憶部１２０内の第１ゲーム状況情報のうちの第１ゲーム後更新情報以外の情報に基づいて、第１ゲーム後更新情報を更新する更新処理を実行する（ＴＡ５０）。

ゲーム端末１０－２の更新処理部１１５は、ゲーム状況情報記憶部１２０内の第２ゲーム状況情報のうちの第２ゲーム後更新情報以外の情報に基づいて、第２ゲーム後更新情報を更新する更新処理を実行する（ＴＢ５０）。

サーバ装置３０の修正指示生成部３０４は、第２ゲーム状況情報のうちの第２ゲーム後更新情報についての修正指示を、ゲーム端末１０－２に送信する（ＴＳ５０）。

ゲーム端末１０－２の修正指示処理部１１６は、ゲーム端末１０－２の通信処理部１１８が第２ゲーム後更新情報についての修正指示を受信すると（ＴＢ５２）、第２ゲーム状況情報のうちの、第２ゲーム後更新情報を修正する（ＴＢ５４）。すなわち、ゲーム端末１０－２の修正指示処理部１１６は、更新処理（ＴＢ５０）で更新された第２ゲーム後更新情報を修正する。

このように、図６Ｅに示す例によれば、対戦能力情報と同様のタイミングで、第２ゲーム後更新情報を修正できる。これにより、ゲーム端末１０－１は、ゲーム端末１０－２での対戦能力情報の修正が完了するまで同期状態で待機する必要がなく、速やかに今回のゲームに係る処理を完了できる。すなわち、ゲーム端末１０－２での比較的時間のかかる対戦能力情報や第２ゲーム後更新情報の修正のための各種処理（ＴＳ２２、ＴＳ２４、ＴＢ２８、ＴＢ３０、ＴＳ５０、ＴＢ５２、ＴＢ５４）を、結果通知指示（ＴＳ２０）よりも後回しにすることで、ゲーム端末１０－１を同期状態から解放して、ゲーム端末１０－１に速やかに結果通知処理を実行させることができる。

なお、図６Ｅに示す例では、対戦能力情報を修正する処理（ＴＳ２２、ＴＳ２４、ＴＢ２８、ＴＢ３０）が、第２ゲーム後更新情報を修正する処理（ＴＳ５０、ＴＢ５２、ＴＢ５４）よりも先に実行されているが、逆であってもよいし、同時に実行されてもよい。例えば、同時に実行される場合、ＴＳ２４にて、サーバ装置３０の修正指示生成部３０４は、第２ゲーム状況情報のうちの、対戦能力情報及び第２ゲーム後更新情報についての修正指示を、ゲーム端末１０－２に送信してよい。

また、図６Ｅに示す例では、第２ゲーム後更新情報についての修正指示は、更新処理部１１５による更新処理後にゲーム端末１０－２に受信されているが、第２ゲーム後更新情報についての修正指示は、更新処理部１１５による更新処理前に受信されてもよい。この場合、更新処理部１１５による更新処理に代えて、第２ゲーム後更新情報についての修正指示に基づいて、第２ゲーム後更新情報が修正（更新）されればよい。

図６Ｆは、他の例による３者間でのデータ（情報）のやり取りを概略的に示す図である。図６Ｆは、図６Ａと同様、ゲームが正常に終了する場合を示すが、図６Ｆを参照して以下で説明する処理は、ゲームが強制的に終了する場合でも適用可能である。

図６Ｆに関しては、図６Ａと異なる点について主に説明し、図６Ａと実質的に同様の処理については、同一の参照符号を付して説明を省略又は簡略化する場合がある。

図６Ｆは、図６Ａに対して、ゲーム端末１０－１に関しては、同じであるが、サーバ装置３０に関しては、ＴＳ６０、ＴＳ６２、ＴＳ６４、ＴＳ６６が追加された点が異なり、ゲーム端末１０－２に関しては、ＴＢ６０、ＴＢ６２、ＴＢ６４、ＴＢ６６が追加された点が異なる。また、図６Ｆには、ゲーム端末１０－２の次の対戦相手に係るゲーム端末１０－３が示されている。

サーバ装置３０のゲームデータ修正部３０６は、第１ゲーム状況情報に基づいて、ゲームデータ記憶部３２０内のゲームデータのうちの、第２ゲーム状況情報を修正する（ＴＳ６０）。なお、ゲームデータ修正部３０６は、第１整合性判定処理（ＴＳ１４）後に、ゲームデータ記憶部３２０内の第２ゲーム状況情報のうちの、対戦結果関連情報だけを修正してもよい。この場合、ゲームデータ修正部３０６は、ＴＳ６０では、ゲームデータ記憶部３２０内の第２ゲーム状況情報のうちの、残りの修正が必要な情報（対戦能力情報を含む）を修正してもよい。あるいは、ゲームデータ修正部３０６は、第１整合性判定処理（ＴＳ１４）後に、ゲームデータ記憶部３２０内の第２ゲーム状況情報を修正せず、ＴＳ６０では、ゲームデータ修正部３０６は、ゲームデータ記憶部３２０内の第２ゲーム状況情報のうちの修正が必要な情報（対戦結果関連情報及び対戦能力情報を含む）を修正してもよい。その後、ゲーム端末１０－２の通信処理部１１８は、サーバ装置３０に接続要求を送信し（ＴＢ６０）、次のゲームに進む操作がなされる（ＴＢ６２）。ここでは、次のゲームの対戦相手に係るゲーム端末がゲーム端末１０－３であるとする。なお、次のゲームの対戦相手に係るゲーム端末がゲーム端末１０－１であってもよい（すなわち再戦であってもよい）。ゲーム端末１０－２の通信処理部１１８は、サーバ装置３０にゲーム開始要求を送信する（ＴＢ６４）。

サーバ装置３０は、接続要求を受信し（ＴＳ６２）、ゲーム開始要求を受信すると（ＴＳ６４）、ゲームデータ記憶部３２０内のゲームデータのうちの、第３プレイヤに対応付けられたチーム情報と第２プレイヤに対応付けられたチーム情報と乱数シードとを含む初期データをゲーム端末１０－２に送信するとともに、同初期データをゲーム端末１０－３に送信する（ＴＳ６６）。ゲーム端末１０－３及びゲーム端末１０－２は、それぞれの通信処理部１１８（ゲーム端末１０－３の通信処理部１１８については図示せず）がそれぞれ初期データを受信する（ＴＣ６０、ＴＢ６６）。この際、ゲーム端末１０－２の修正指示処理部１１６は、サーバ装置３０から送られてくるチーム情報で、ゲーム状況情報記憶部１２０内の同チーム情報を置き換える。この結果、第２ゲーム状況情報の少なくとも一部の情報（チーム情報に関連する情報であり、対戦能力情報を含む）が修正されることになる。後は図６Ａと同様に、ゲームが開始される。なお、この場合、ゲーム端末１０－２に初期データが送信されることで、ゲーム端末１０－２に修正指示が送信されることが実現されている。

このように、図６Ｆに示す例によれば、ゲームが開始される直前のタイミングで、対戦能力情報等を修正できる。これにより、ゲーム端末１０－１は、ゲーム端末１０－２での対戦能力情報の修正が完了するまで同期状態で待機する必要がなく、速やかに今回のゲームに係る処理を完了できる。すなわち、ゲーム端末１０－２での比較的時間のかかる対戦能力情報の修正のための各種処理（ＴＳ２２、ＴＳ６０、ＴＳ６６、ＴＢ６６）を、結果通知指示（ＴＳ２０）よりも後回しにすることで、ゲーム端末１０－１を同期状態から解放して、ゲーム端末１０－１に速やかに結果通知処理を実行させることができる。

なお、図６Ｆに示す例では、第２ゲーム状況情報のうちの、対戦結果関連情報以外の情報は、第１ゲーム状況情報の対応する情報に対して整合していなくても、ゲームが開始される直前のタイミングまでは修正されない。このため、第２プレイヤの操作等により第２ゲーム状況情報や第２ゲーム状況情報に基づき算出される情報等が表示部１５に出力されると、潜在的な不整合が表出されることになる。ただし、かかる不都合があるものの、第２ゲーム状況情報の対戦能力情報が修正されないまま、次の対戦に係るゲームが開始されてしまうことは防止できる。

また、図６Ｆに示す例では、ゲームデータ記憶部３２０内のゲームデータ（ゲームデータ内の第２ゲーム状況情報）を修正する処理（ＴＳ６０）は、接続要求の受信（ＴＳ４４）前に実行されているが、接続要求の受信（ＴＳ４４）後に実行されてもよい。
また、図６Ａ～図６Ｃ、図６Ｅに示す例では、ゲームデータ記憶部３２０内のゲームデータ（ゲームデータ内の第２ゲーム状況情報）を修正する処理（ＴＳ６０）は示されていないが、同様に実行されてもよい。

＜具体例＞次に、図７～図４０を参照して、具体的な構成について説明する。

以下では、一例として、上述した第１プレイヤ及び第２プレイヤが人であるとして、第１プレイヤを「第１ユーザ」と表記し、第２プレイヤを「第２ユーザ」と表記し、区別しないときは単に「ユーザ」と表記する。

また、以下の図７～図４０を参照した説明では、ゲーム状況情報は、複数の修正対象項目の情報を含むものとし、ゲーム状況情報に含まれるすべての修正対象項目の情報のうちの、上述した対戦結果関連情報以外の情報（上述した対戦能力情報を含む）を、「ゲーム詳細情報」と称する。すなわち、以下では、ゲーム状況情報は、対戦結果関連情報と、ゲーム詳細情報とからなるものとする。ゲーム詳細情報は、対戦能力情報のみを含んでもよいし、対戦能力情報以外の情報（例えば、安打数や、失点、四死球の数、エラーの数等のような、ゲームに係る対戦結果に影響しないパラメータの値等）を更に含んでもよい。

また、以下の図７～図４０を参照した説明では、区別のため、ゲーム状況情報を修正するための修正指示のうちの、対戦結果関連情報を修正するための修正指示を「訂正指示」と称し、ゲーム詳細情報を修正するための修正指示を「復元指示」と称する。

図７は、サーバ装置３０の具体的な構成例を示す図である。

図７では、サーバ装置３０は、ゲートサーバ３０１１と、複数の認証サーバ３０１２と、複数のロビーサーバ３０１３と、複数のゲームサーバ３０１４とを含む。

ゲートサーバ３０１１は、サーバコンピュータである。ゲートサーバ３０１１は、ゲームシステム１内のサーバコンピュータのリストを管理する。例えば、ゲートサーバ３０１１は、認証サーバ３０１２、ロビーサーバ３０１３、及びゲームサーバ３０１４のそれぞれのサーバ名（ホスト名）、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレス、ポート番号や各サーバコンピュータの稼働状態等の情報を管理する。

認証サーバ３０１２は、サーバコンピュータである。例えば、認証サーバ３０１２は、ユーザ情報等の認証情報に基づいてユーザ認証を実行する。ユーザ認証に成功するとユーザトークンを発行し、ゲーム端末１０－１、１０－２に送信する。ゲーム端末１０－１、１０－２は、認証サーバ３０１２で発行されたユーザトークンを送信する情報に添付することで、各サーバコンピュータは、正しく認証された端末からの情報であると認識する。

ロビーサーバ３０１３は、サーバコンピュータである。例えば、ロビーサーバ３０１３は、ゲームの対戦におけるマッチングを実行する。

ゲームサーバ３０１４は、サーバコンピュータである。例えば、ゲームサーバ３０１４は、マッチング完了後にゲーム端末１０－１、１０－２が接続するサーバであり、ゲーム端末１０－１、１０－２と協動してゲーム実行に係る各種処理を実行する。

なお、以下で説明するゲーム端末１０－１、１０－２とサーバ装置３０との間でやり取りされる情報は、共通鍵に基づき暗号化されてよい。

なお、ゲームシステム１内のサーバの台数に制限はなく、ゲートサーバ３０１１、認証サーバ３０１２、ロビーサーバ３０１３、及びゲームサーバ３０１４のそれぞれは、２台以上であってもよい。また、１台のサーバコンピュータが、ゲートサーバ３０１１、認証サーバ３０１２、ロビーサーバ３０１３、及びゲームサーバ３０１４のうちの少なくとも２つ以上の機能を担ってもよい。ゲームシステム１内のサーバコンピュータは１台だけであってもよいし、図７に示すサーバコンピュータ以外のコンピュータがゲームシステム１に含まれてもよい。

また、上述したように、ここでは、２台のゲーム端末１０－１、１０－２を例に挙げて説明していくが、ゲームシステム１内のゲーム端末１０－１、１０－２の台数に制限はなく、ゲーム端末は、３台以上であってもよいし、１台だけであってもよい。

次に、図８及び図９を参照して、ゲームシステム１におけるソフトウェアプロセス構成について説明する。

図８は、ゲーム端末１０－１、１０－２におけるソフトウェアプロセス構成を示す図である。

ゲーム端末１０－１、１０－２は、それぞれ、ゲームシステム１に係るゲーム用アプリケーション（以下、単に「ゲームアプリ２０」と称する）が実装される。ゲーム端末１０－１、１０－２のゲームアプリ２０は、同じであるが、区別する場合は、ゲーム端末１０－１のゲームアプリ２０を「２０－１」と表記し、ゲーム端末１０－２のゲームアプリ２０を「２０－２」と表記する。

図９は、サーバ装置３０におけるソフトウェアプロセス構成を示す図である。

ゲートサーバ３０１１は、ゲートサーバプロセス４０が実装される。ゲートサーバプロセス４０は、ゲートサーバ３０１１で動作しているソフトウェアプロセスである。ゲートサーバプロセス４０は、ゲートサーバ３０１１に割り当てられているＩＰアドレスを利用し、ネットワークＮを介して、ゲームアプリ２０と接続する。なお、ゲートサーバプロセス４０のＰＯＲＴ番号は予め定められている。

認証サーバ３０１２は、認証サーバプロセス４１が実装される。認証サーバプロセス４１は、認証サーバ３０１２で動作しているソフトウェアプロセスである。認証サーバプロセス４１は、ユーザ認証を行うためのプロセスである。一般的には、ワンタイムの共通鍵を互いにやり取りし、やり取りした共通鍵を使って、個人情報をやり取りする。認証サーバプロセス４１は、認証サーバ３０１２に割り当てられているＩＰアドレスを利用し、ネットワークＮを介して、ゲームアプリ２０と接続する。認証サーバプロセス４１のＰＯＲＴ番号は予め定められている。認証サーバプロセス４１のＰＯＲＴ番号は、ゲートサーバプロセス４０のＰＯＲＴ番号と異なり、同様に後出する各種プロセスのＰＯＲＴ番号も、互いに異なる。

認証サーバ３０１２は、また、ＳＱＬプロセス４２が実装される。ＳＱＬプロセス４２は、認証サーバ３０１２で動作しているソフトウェアプロセスである。ＳＱＬプロセス４２は、認証サーバ３０１２に割り当てられているＩＰアドレスを利用し、サーバ装置３０内のローカルエリアネットワーク（図示せず）を介して、各種サーバコンピュータと接続される。ＳＱＬプロセス４２のＰＯＲＴ番号は予め定められている。

なお、ＳＱＬプロセス４２は、認証サーバ３０１２で動作しているが、専用のサーバで動作してもよいし、例えば、ゲートサーバ３０１１、ロビーサーバ３０１３、及びゲームサーバ３０１４のいずれかで動作してもよい。

ロビーサーバ３０１３は、ロビーサーバプロセス４３が実装される。ロビーサーバプロセス４３は、ロビーサーバ３０１３で動作しているソフトウェアプロセスである。ロビーサーバプロセス４３は、ロビーサーバ３０１３に割り当てられているＩＰアドレスを利用し、ネットワークＮを介して、ゲームアプリ２０と接続する。ロビーサーバプロセス４３のＰＯＲＴ番号は予め定められている。

ロビーサーバ３０１３は、複数のサブロビーサーバプロセス（４４－１、４４－２のみ図示）が実装される。サブロビーサーバプロセス４４－１、４４－２は、ロビーサーバプロセス４３によって起動されたプロセスである。ゲームアプリ２０－１からロビーサーバプロセス４３に接続要求があると、ロビーサーバプロセス４３は、サブロビーサーバプロセス４４－１を起動する。その後、ゲームアプリ２０－１から送信された通信パケットは、すべて、サブロビーサーバプロセス４４－１が処理する。ゲームアプリ２０－１以外の他のゲームアプリ２０－２からロビーサーバプロセス４３に接続要求があると、ロビーサーバプロセス４３は、サブロビーサーバプロセス４４－２を起動する。その後、ゲームアプリ２０－２から送信された通信パケットは、すべて、サブロビーサーバプロセス４４－２が処理する。以下、区別しないときは、サブロビーサーバプロセス４４と表記する。

ゲームサーバ３０１４は、マッチングプロセス４５が実装される。マッチングプロセス４５は、ゲームサーバ３０１４で動作しているソフトウェアプロセスである。マッチングプロセス４５は、ゲームサーバ３０１４に割り当てられているＩＰアドレスを利用し、ネットワークＮを介して、ゲームアプリ２０と接続する。マッチングプロセス４５のＰＯＲＴ番号は予め定められている。

ゲームサーバ３０１４は、複数のゲームサーバプロセス（４６－１、４６－２のみ図示）が実装される。ゲームサーバプロセス４６－１は、ゲームサーバ３０１４で動作しているソフトウェアプロセスである。ゲームサーバプロセス４６－１は、ゲームサーバ３０１４に割り当てられているＩＰアドレスを利用し、ネットワークＮを介して、ゲームアプリ２０と接続する。ゲームサーバプロセス４６－１、４６－２のそれぞれのＰＯＲＴ番号は予め定められている。ゲームサーバプロセス４６－２は、ゲームサーバプロセス４６－１と同一の実行ファイルから起動したゲームサーバプロセスである。

ゲームサーバプロセス４６－１とゲームサーバプロセス４６－２との相違点は、割り当てられているＰＯＲＴ番号が異なる点である。ゲームサーバ３０１４は、ゲームサーバプロセス４６－１及びゲームサーバプロセス４６－２以外にも複数のソフトウェアプロセスが動作している。

次に、図１０Ａ及び図１０Ｂを参照して、ゲーム画面について説明する。

図１０Ａは、ゲームが正常に終了する場合のゲーム画面の遷移態様を概略的に示す図である。図１０Ａにおいて、“失敗”とは認証の失敗や接続の失敗を意味し、“成功”とは認証の成功や接続の成功を意味する。

図１０Ａに示すように、ゲームアプリ２０を起動すると、タイトル画面Ｇ１００が表示部１５に表示される。操作部１４から操作が入力されると、初めてゲームアプリ２０を起動した場合、又は、ゲーム端末１０－１（又はゲーム端末１０－２）の内部キャッシュをクリアした場合に、初期画面Ｇ２００が表示部１５に表示される。ユーザが初期画面Ｇ２００に表示されている指示に従って操作部１４から必要事項を入力すると、ユーザ認証がサーバ装置３０でなされる。ユーザ認証が正しく行われると、サーバ装置３０への接続処理中の状態を表す接続中画面Ｇ３００が表示部１５に表示される。一度ユーザ認証が正しく行われると初期画面Ｇ２００は表示部１５に表示されずに接続中画面Ｇ３００が表示される。その後、マップ画面Ｇ４００が表示部１５に表示される。マップ画面Ｇ４００に表示されているボタン（図示せず）（操作部１４の一例）を使って操作すると、接続中画面Ｇ５００が表示部１５に表示される。その後、対戦画面Ｇ６００が表示部１５に表示される。ゲームが終わると、対戦結果画面Ｇ７００が表示部１５に表示される。その後、ゲーム結果画面Ｇ８００が表示部１５に表示され、接続中画面Ｇ９００が表示部１５に表示され、サーバ装置３０に正しく接続されると再び、マップ画面Ｇ４００が表示部１５に表示される。サーバ装置３０に正しく接続されない場合、タイトル画面Ｇ１００が表示される。

図１０Ｂは、ゲームが強制的に終了する場合のゲーム画面の遷移態様を概略的に示す図である。図１０Ｂは、図１０Ａとほぼ同じである。図１０Ａの対戦結果画面Ｇ７００と図１０Ｂの対戦結果画面Ｇ７１０が異なっている。図１０Ａのゲーム結果画面Ｇ８００と図１０Ｂのゲーム結果画面Ｇ８１０が異なっている。図１０Ｂに示すように、ゲームアプリ２０－１が対戦画面Ｇ６００を表示部１５に表示している最中に、対戦相手のゲームアプリ２０－２の電源の遮断等に起因してゲームが強制的に終了すると、ゲームアプリ２０－１は、Ｇ７１０のような得点なしの状態の対戦結果画面を表示部１５に表示させる。

ゲーム結果画面Ｇ８１０は、ゲーム結果画面Ｇ８００よりも出力されている情報量が少ない。このようにして、ゲームが強制的に終了する場合、ゲーム結果画面Ｇ８１０のように一部のゲーム状況情報が欠落する態様で表示部１５に表示されてもよい。例えば、ゲーム結果画面Ｇ８００は、ゲーム状況情報のうちの、対戦結果関連情報に基づく表示内容と、ゲーム詳細情報の少なくとも一部に基づく表示内容を含むのに対して、ゲーム結果画面Ｇ８１０は、ゲーム状況情報のうちの、対戦結果関連情報に基づく表示内容を含むが、ゲーム詳細情報の少なくとも一部に基づく表示内容を含まない。これにより、修正される可能性のあるゲーム詳細情報に基づき生成される表示内容を、ゲーム結果画面が含んでしまう可能性を低減できる。

次に、ゲームアプリ２０について説明する。

図１１は、ゲームアプリ２０によるメイン処理を示すフローチャートである。図１２は、ゲームアプリ２０による各種割り込み処理を示すフローチャートである。

図１１に示すように、ゲームアプリ２０は起動すると、各種の初期化処理（Ｓ１１０）を行う。次に、後述するゲームメイン処理（Ｓ１２０）を行い、その後、ゲームメイン処理（Ｓ１２０）で更新された情報を利用して描画処理（Ｓ１３０）を行う。描画処理（Ｓ１３０）の結果として得られる画像は、表示部１５上に出力される。ゲームアプリ２０は、ゲームアプリ２０の終了操作が行われたか否かの終了判定（Ｓ１４０）を実行する。終了操作は、ユーザにより例えば操作部１４により実行される。その後、ゲームアプリ２０は、バックバッファ（図示せず）への描画が完了したか否かの描画完了判定（Ｓ１５０）を実行し、描画が完了していなければ描画の完了を待つ待機状態となる（Ｓ１５０：ＮＯ）。ゲームアプリ２０は、バックバッファへの描画が完了した場合（Ｓ１５０：ＹＥＳ）は、フロントバッファとバックバッファの描画を切り替えた後、ゲームメイン処理（Ｓ１２０）へ戻る。なお、ゲーム端末１０－１、１０－２の制御部１１の性能によっても異なるが、一連の処理は約１６ｍｓ～３３ｍｓで行われる。ゲームアプリ２０の終了操作が行われていた場合（Ｓ１４０：ＹＥＳ）は、ゲームアプリ２０は、終了処理（Ｓ１６０）を行った後、終了する。

ゲームアプリ２０は、メイン処理の実行中、図１２に示すような各種割り込み処理を実行する。

サスペンド処理は、所定のサスペンド条件が成立すると割り込み実行される。サスペンド処理では、ゲームアプリ２０は、通信部１３から切断要求をサーバ装置３０に送信する（Ｓ１７０）。サスペンド条件は、例えば、リタイアボタン（操作部１４の一要素）が操作された場合や、ゲーム端末１０－１、１０－２の電源ボタンが押されて画面表示が消去された場合、ゲーム端末１０－１、１０－２の無操作状態が所定時間継続して画面表示が消去された場合等に成立する。

受信割り込み処理は、サーバ装置３０からのデータが受信されたときに割り込み実行される。受信割り込み処理では、ゲームアプリ２０は、通信部１３を介してサーバ装置３０からデータを取得する（Ｓ１７２）。ゲームアプリ２０は、通信部１３からデータを取得すると、取得したデータのヘッダ部分を確認し、ヘッダ部分の内容に応じて記憶部１２の所定記憶領域にサーバ装置３０から取得したデータを保存する（Ｓ１７４）。なお、ゲームアプリ２０は、データを保存する際にヘッダ部分を削除する等の加工を行う場合がある。ゲームアプリ２０は、サーバ装置３０からデータを受信したか否かを判定するために、ゲームメイン処理（Ｓ１２０）の際に、受信割り込み処理により記憶部１２に保存されたデータを利用する。

例えば、受信割り込み処理では、ゲームアプリ２０は、サーバ装置３０から復元指示を受信した場合に、記憶部１２の第１所定記憶領域に、復元指示を記憶し、復元要フラグを“オン”に設定する。復元要フラグが“オン”状態であることは、上述したゲーム詳細情報を修正する処理が必要な状態を表す。なお、記憶部１２の第１所定記憶領域は、後述の通常ゲーム進行処理により更新されるゲーム状況情報が記憶される記憶領域（ゲーム状況情報記憶部１２０）とは異なる。

操作割り込み処理は、操作部１４から操作情報が入力されると割り込み実行される。操作割り込み処理では、ゲームアプリ２０－１は、操作情報（第１操作情報）を記憶部１２に保存する（Ｓ１７６）。ゲームアプリ２０－２は、操作情報（第２操作情報）を記憶部１２に保存する（Ｓ１７６）。記憶部１２に保存されている操作情報は、ゲームメイン処理（Ｓ１２０）の際に利用される。

送信割り込み処理は、通信部１３の送信バッファが空又は所定量以下の値になった場合に割り込み実行される。送信割り込み処理では、ゲームアプリ２０は、記憶部１２の送信キューに保存されているデータを取り出して、通信部１３の送信バッファにセットする（Ｓ１７８）。記憶部１２の送信キューのデータは、ゲームメイン処理（Ｓ１２０）の際に保存される。

次に、メイン処理中のゲームメイン処理（Ｓ１２０）について説明する。

図１３は、処理に用いるメイン状態（以下、「ＳＴＡＴＵＳ」）と称する）の種類を示す図であり、図１４は、ＳＴＡＴＵＳに係る状態遷移図である。

ここでは、ＳＴＡＴＵＳは、図１３に示すように、「タイトル」、「ユーザ認証」、「マップ」、「ゲーム中」、及び「ゲーム後」の５つの種類を含む。ＳＴＡＴＵＳは、「タイトル」、「ユーザ認証」、「マップ」、「ゲーム中」、及び「ゲーム後」に応じた値が、記憶部１２に記憶される。記憶部１２に記憶されているＳＴＡＴＵＳの値は、現在の状態を表す。「タイトル」、「ユーザ認証」、「マップ」、「ゲーム中」、及び「ゲーム後」の間の遷移は、図１４に示す態様で実現される。「タイトル」からは、「接続」を介して「マップ」に遷移でき、「マップ」を介して「ゲーム中」及び「ゲーム後」に遷移できる。「ゲーム後」からは、「マップ」又は「タイトル」に遷移される。

なお、ある一のＳＴＡＴＵＳは、更に分類された状態（以下、「ＳＵＢＳＴＡＴＵＳ」）と称する）を含んでよい。ＳＵＢＳＴＡＴＵＳは、後述する。ここでは、ＳＴＡＴＵＳ「マップ」は、２種類のＳＵＢＳＴＡＴＵＳ「復元」及び「マップメイン」を含む。ＳＵＢＳＴＡＴＵＳが「復元」の値であることは、上述したゲーム詳細情報を修正する処理が必要な状態を表す。ＳＴＡＴＵＳ「マップ」のＳＵＢＳＴＡＴＵＳの初期値は、「復元」の値に設定される。ＳＵＢＳＴＡＴＵＳの値は、ＳＴＡＴＵＳの値が変化すると、初期値にリセットされる。また、ＳＴＡＴＵＳ「ゲーム中」は、２種類のＳＵＢＳＴＡＴＵＳ「ゲーム初期化」及び「ゲーム進行」を含む。ＳＵＢＳＴＡＴＵＳ「ゲーム進行」は、更に下層に、４種類の「通常進行」、「投球待ち」、「投球入力待ち」、及び「打撃待ち」を含む。

図１５は、ゲームメイン処理（Ｓ１２０）のフローチャートである。

図１５に示すように、ゲームメイン処理（Ｓ１２０）では、ゲームアプリ２０は、記憶部１２に記憶されているＳＴＡＴＵＳの値によって、処理を分岐する。ゲームアプリ２０は、ＳＴＡＴＵＳがタイトルであれば（Ｓ１２００：ＹＥＳ）、タイトル処理（Ｓ１２０２）を行い、ＳＴＡＴＵＳがタイトルでなければ（Ｓ１２００：ＮＯ）、次の処理（Ｓ１２０４）に進む。ゲームアプリ２０は、ＳＴＡＴＵＳがユーザ認証であれば（Ｓ１２０４：ＹＥＳ）、ユーザ認証処理（Ｓ１２０６）を行い、ＳＴＡＴＵＳがユーザ認証でなければ（Ｓ１２０４：ＮＯ）、次の処理（Ｓ１２０８）に進む。ゲームアプリ２０は、ＳＴＡＴＵＳがマップであれば（Ｓ１２０８：ＹＥＳ）、マップ処理（Ｓ１２１０）を行い、ＳＴＡＴＵＳがマップでなければ（Ｓ１２０８：ＮＯ）、次の処理（Ｓ１２１２）に進む。ゲームアプリ２０は、ＳＴＡＴＵＳが「ゲーム中」であれば（Ｓ１２１２：ＹＥＳ）、ゲーム処理（Ｓ１２１４）を行い、ＳＴＡＴＵＳが「ゲーム中」でなければ（Ｓ１２１２：ＮＯ）、次の処理（Ｓ１２１６）に進む。ゲームアプリ２０は、ＳＴＡＴＵＳがゲーム後であれば（Ｓ１２１６：ＹＥＳ）、ゲーム後処理（Ｓ１２１８）を行い、ＳＴＡＴＵＳがゲーム後でなければ（Ｓ１２１６：ＮＯ）、今回の処理周期のゲームメイン処理を終了する。

図１６は、タイトル処理（Ｓ１２０２）のフローチャートである。

図１６に示すように、タイトル処理（Ｓ１２０２）では、ゲームアプリ２０は、ゲームの開始操作が行われたか否かを判定する（Ｓ１２０２２）。ゲームの開始操作（以下で説明する各種操作も同様）は、ユーザにより操作部１４を介して実現される。ゲームアプリ２０は、開始操作が行われていない場合は（Ｓ１２０２２：ＮＯ）、タイトル処理（Ｓ１２０２）を終了し、ゲームメイン処理（Ｓ１２０）に戻る。

ゲームアプリ２０は、開始操作を検出すると（Ｓ１２０２２：ＹＥＳ）、ゲートサーバ３０１１に接続し、サーバリストを要求する（Ｓ１２０２４）。ゲームアプリ２０は、ゲートサーバ３０１１からサーバリストを受け取ったか否かを判定し（Ｓ１２０２６）、受け取っていなかったら（Ｓ１２０２６：ＮＯ）、タイトル処理（Ｓ１２０２）を終了し、ゲームメイン処理（Ｓ１２０）に戻る。ゲームアプリ２０は、ゲートサーバ３０１１からサーバリストを受け取ったら（Ｓ１２０２６：ＹＥＳ）、ゲートサーバ３０１１から受け取ったサーバリストを記憶部１２に保存する（Ｓ１２０２８）。サーバリストには、現在正常に稼働しているサーバを特定する情報が含められる。サーバは２４時間稼働しており、定期的なメンテナンスや長期間の稼働によって、システムダウンすることがある。そのため、現在稼働している最新情報をゲートサーバ３０１１から受け取ることによって、正常に動作するサーバに接続することができる。ゲームアプリ２０は、今後各種サーバコンピュータに接続するときには、ここで保存したサーバリストを参照する。

次いで、ゲームアプリ２０は、ユーザ認証済みのユーザトークンが記憶部１２に保存されているか否か判断する（Ｓ１２０３０）。なお、ユーザトークンが保存されていても期限が切れていた場合は、ユーザトークンが保存されていないと判定する。ゲームアプリ２０は、ユーザトークンが保存されていなかったら（Ｓ１２０３０：ＮＯ）、ユーザトークンを再取得する（Ｓ１２０３２）。ユーザトークンが記憶部１２に保存されていたら、Ｓ１２０３６に進む。この後、明記していないが、すべての通信パケットにユーザトークンを追加して通信を行う。

ユーザトークンが保存されていない場合（Ｓ１２０３０：ＮＯ）、ゲームアプリ２０は、記憶部１２に保存されているＳＴＡＴＵＳを「ユーザ認証」に変更する（Ｓ１２０３２）。ゲームアプリ２０は、記憶部１２に保存されているサーバリストから認証サーバ３０１２を選んで接続する（Ｓ１２０３４）。その後、ゲームアプリ２０は、タイトル処理（Ｓ１２０２）を終了し、ゲームメイン処理（Ｓ１２０）に戻る。

ユーザトークンが保存されている場合（Ｓ１２０３０：ＹＥＳ）、ゲームアプリ２０は、記憶部１２に保存されているＳＴＡＴＵＳを「マップ」に変更する（Ｓ１２０３６）。ゲームアプリ２０は、記憶部１２に保存されているサーバリストからロビーサーバ３０１３を選んで接続する（Ｓ１２０３８）。その後、ゲームアプリ２０は、タイトル処理（Ｓ１２０２）を終了し、ゲームメイン処理（Ｓ１２０）に戻る。

図１７は、ユーザ認証処理（Ｓ１２０６）のフローチャートである。

図１７に示すように、ユーザ認証処理（Ｓ１２０６）では、ゲームアプリ２０は、認証用の個人情報（例えば、ユーザ名とパスワード）の入力を待つ（Ｓ１２０６０）。ユーザは、操作部１４を介して個人情報を入力できる。ゲームアプリ２０は、入力が完了していない場合（Ｓ１２０６０：ＮＯ）は、ユーザ認証処理（Ｓ１２０６）を終了し、ゲームメイン処理（Ｓ１２０）に戻る。ゲームアプリ２０は、入力が完了した場合（Ｓ１２０６０：ＹＥＳ）、入力された個人情報を認証サーバ３０１２に送信する（Ｓ１２０６２）。その後、ゲームアプリ２０は、認証サーバ３０１２からの返答を確認する（Ｓ１２０６４）。ゲームアプリ２０は、認証サーバ３０１２からの返答がＮＧ（認証失敗）であった場合（Ｓ１２０６４：ＮＯ）、記憶部１２に保存されているＳＴＡＴＵＳを「タイトル」に設定する（Ｓ１２０７０）。そして、ゲームアプリ２０は、ユーザ認証処理（Ｓ１２０６）を終了し、ゲームメイン処理（Ｓ１２０）に戻る。ゲームアプリ２０は、認証サーバ３０１２からの返答がＯＫ（認証成功）であった場合（Ｓ１２０６４：ＹＥＳ）、認証サーバ３０１２から受信したユーザトークンを記憶部１２に保存し（Ｓ１２０６６）、記憶部１２に保存されているＳＴＡＴＵＳを「マップ」に設定する（Ｓ１２０６８）。そして、ゲームアプリ２０は、ユーザ認証処理（Ｓ１２０６）を終了し、ゲームメイン処理（Ｓ１２０）に戻る。なお、ユーザ認証において、個人情報を送信するときに暗号化処理（秘密鍵暗号）を行う。

図１８は、マップ処理（Ｓ１２１０）のフローチャートである。

図１８に示すように、マップ処理（Ｓ１２１０）では、ゲームアプリ２０は、記憶部１２に記憶されているＳＵＢＳＴＡＴＵＳの値によって、処理を分岐する。ゲームアプリ２０は、ＳＵＢＳＴＡＴＵＳが「復元」であれば（Ｓ１２１０２：ＹＥＳ）、復元処理（Ｓ１２１０４）を行い、ＳＵＢＳＴＡＴＵＳが「復元」でなければ（Ｓ１２１０２：ＮＯ）、次の処理（Ｓ１２１０６）に進む。ゲームアプリ２０は、ＳＵＢＳＴＡＴＵＳが「マップメイン」であれば（Ｓ１２１０６：ＹＥＳ）、マップメイン処理（Ｓ１２１０８）を行い、ＳＵＢＳＴＡＴＵＳが「マップメイン」でなければ（Ｓ１２１０６：ＮＯ）、マップ処理（Ｓ１２１０）を終了し、ゲームメイン処理（Ｓ１２０）に戻る。

図１９は、復元処理（Ｓ１２１０４）のフローチャートである。復元処理は、上述した修正処理のうちの、ゲーム詳細情報を修正する処理に対応する。

図１９に示すように、復元処理（Ｓ１２１０４）では、ゲームアプリ２０は、前回行ったゲームに関して、修正すべきゲーム状況情報（ゲーム詳細情報）があるか否かについてロビーサーバ３０１３からの返答に基づいて確認する（Ｓ１２１０４０）。具体的には、ゲームアプリ２０は、上述した復元要フラグが“オン”状態であるか否かを判定する。修正すべきゲーム状況情報（ゲーム詳細情報）がない場合、すなわち復元要フラグが“オフ”状態である場合（Ｓ１２１０４０：ＮＯ）は、ステップＳ１２１０４４に進み、修正すべきゲーム状況情報（ゲーム詳細情報）がある場合、すなわち復元要フラグが“オン”状態である場合（Ｓ１２１０４０：ＹＥＳ）は、記憶部１２の第１所定記憶領域に記憶されている復元指示に基づいて、ゲーム状況情報記憶部１２０内のゲーム詳細情報を修正する（Ｓ１２１０４２）。この際、ゲームアプリ２０は、対戦結果関連情報についても修正してもよい。この場合、履歴として過去の対戦結果が表示される場合は、修正した対戦結果関連情報に基づいて過去の対戦結果を表示できる。その後、ゲームアプリ２０は、記憶部１２に記憶されているＳＵＢＳＴＡＴＵＳを「マップメイン」に変更し（Ｓ１２１０４４）、マップ処理（Ｓ１２１０）に戻る。

図２０は、マップメイン処理（Ｓ１２１０８）のフローチャートである。

図２０に示すように、マップメイン処理（Ｓ１２１０８）では、ゲームアプリ２０は、ゲームに進む操作が行われたか否かを判定し（Ｓ１２１０８０）、ゲームに進む操作が行われていない場合（Ｓ１２１０８０：ＮＯ）、マップ処理（Ｓ１２１０）に戻る。ゲームアプリ２０は、ゲームに進む操作があった場合（Ｓ１２１０８０：ＹＥＳ）、ゲーム開始要求を送信し（後出の図３４のサブロビーサーバプロセス４４のステップＳ４４６参照）、記憶部１２に保存されているサーバリストに基づいて、ゲームサーバ３０１４に接続する（Ｓ１２１０８２）。その後、ゲームアプリ２０は、記憶部１２に記憶されているＳＴＡＴＵＳの値を「ゲーム中」に変更し（Ｓ１２１０８４）、マップ処理（Ｓ１２１０）に戻る。

図２１は、ゲーム処理（Ｓ１２１４）のフローチャートである。

図２１に示すように、ゲーム処理（Ｓ１２１４）では、ゲームアプリ２０は、記憶部１２に記憶されているＳＵＢＳＴＡＴＵＳの値によって、処理を分岐する。ゲームアプリ２０は、ＳＵＢＳＴＡＴＵＳが「ゲーム初期化」であれば（Ｓ１２１４０：ＹＥＳ）、ゲーム初期化処理（Ｓ１２１４２）を行い、ＳＵＢＳＴＡＴＵＳが「ゲーム初期化」でなければ（Ｓ１２１４０：ＮＯ）、次の処理（Ｓ１２１４４）に進む。ゲームアプリ２０は、ＳＵＢＳＴＡＴＵＳが「ゲーム進行」であれば（Ｓ１２１４４：ＹＥＳ）、ゲーム進行処理（Ｓ１２１４６）を行う。そして、ゲームアプリ２０は、ゲーム進行処理（Ｓ１２１４６）後に、ゲームメイン処理（Ｓ１２０）に戻る。また、ゲームアプリ２０は、ＳＵＢＳＴＡＴＵＳが「ゲーム中」でなければ（Ｓ１２１４４：ＮＯ）、ゲームメイン処理（Ｓ１２０）に戻る。

図２２は、ゲーム初期化処理（Ｓ１２１４２）のフローチャートである。

図２２に示すように、ゲーム初期化処理（Ｓ１２１４２）では、ゲームアプリ２０は、ゲームサーバ３０１４から受け取った乱数シードを使って、乱数を初期化する（Ｓ１２１４２０）。ゲームアプリ２０は、両チーム（自チームと相手チーム）のチーム情報を読み込む（Ｓ１２１４２２）。チーム情報は、各選手の各種情報（各選手を表すゲームオブジェクトの識別情報や、各選手を表すゲームオブジェクトの名前、ポジション等）を含む。特に、チーム情報は、各選手を表すゲームオブジェクトのスタミナを含む。チーム情報のうちのスタミナは、ゲーム状況情報としてゲーム中に更新される（後出の図２６のステップＳ１２１４６０２２参照）。

両チーム（自チームと相手チーム）のチーム情報は、受信割り込み処理（図１２のステップＳ１７２、ステップＳ１７４）で、ゲームサーバ３０１４から受信され、保存されたものである。その後、ゲームアプリ２０は、記憶部１２に記憶されているＳＵＢＳＴＡＴＵＳの値を「ゲーム進行」に変更する（Ｓ１２１４２４）。なお、ゲームサーバ３０１４からは、同一の乱数シードがゲームアプリ２０－１、２０－２に送信されている。従って、ゲームアプリ２０－１、２０－２のそれぞれで実現するゲーム状況は基本的には同一になる。

図２３は、ゲーム進行処理（Ｓ１２１４６）のフローチャートである。図２４は、ゲーム状況情報Ｄ２４０の例を示す図である。ここでは、ゲーム状況情報Ｄ２４０を用いて説明を続ける。なお、図２４に示すゲーム状況情報Ｄ２４０は、図４に示したゲーム状況情報（概要の説明用のゲーム状況情報）Ｄ１０１とは異なる。ゲーム状況情報の詳細な構成は任意である。

図２３に示すように、ゲーム進行処理（Ｓ１２１４６）では、ゲームアプリ２０は、Ｓ１２１４２０で初期化した乱数を使って、対戦処理（Ｓ１２１４６０）を実行する。乱数シードが同一であれば、乱数を取得する回数における数値が同じになる。例えば、野球ゲームの場合、バットにボールが当たるか否かの抽選をした場合、ゲーム端末１０－１、１０－２のいずれにおいても同じ結果になる。例えば野球ゲームの場合、打者がバッターボックスに入り、バットを振る姿勢になり、投手が投球する直前になるまでのゲームの進行は、ゲーム端末１０－１、１０－２のそれぞれで実現される。ゲーム中においてゲーム端末１０－１、１０－２間で操作情報以外の交換（通信）を要せず、共通の乱数シードを使っていれば、ランダムに決定される不確定要素の結果はゲームアプリ２０－１とゲームアプリ２０－２との間で同じになる。

次いで、ゲームアプリ２０は、ユーザ操作を受け付ける状態で（Ｓ１２１４６２：ＹＥＳ）、実際に操作部１４の入力を受け付けると、ゲームサーバ３０１４に操作情報を送信する（Ｓ１２１４６４）。なお、ゲームサーバ３０１４は、ゲームアプリ２０－１から受け取った操作情報をゲームアプリ２０－２に送信し、ゲームアプリ２０－２から受け取った操作情報をゲームアプリ２０－１に送信する（後述）。このようにしてゲームサーバ３０１４に送信される操作情報は、他方のゲームアプリ２０に受け取られる。

ゲームアプリ２０は、受け取った操作情報があったら（Ｓ１２１４６６：ＹＥＳ）、当該操作情報を記憶部１２に保存する（Ｓ１２１４６８）。ゲームアプリ２０は、ゲームサーバ３０１４からのゲーム終了要求を受信したか否か、又は、対戦処理（Ｓ１２１４６０）でゲームを進行させた結果、ゲーム終了まで到達したか否か（Ｓ１２１４７０）を判定し、ゲームを終了させる場合（Ｓ１２１４７０：ＹＥＳ）は、ゲーム終了通知及びゲーム状況情報（図２４）をゲームサーバ３０１４に送信し（Ｓ１２１４７２）、ゲームを終了させない場合（Ｓ１２１４７０：ＮＯ）は、ゲーム進行処理（Ｓ１２１４６）を終了する。図２４では、ゲーム状況情報Ｄ２４０は、各チームの得点や、各イニングの表と裏の各得点、各選手のスタミナ、投手の投球回数等を含む。なお、各選手には、投手も含まれる。なお、投手が１～Ｎまで複数あるのは、先発から抑えまで複数人数設定できるからである。また、表チームの得点は、各イニングの表の得点の合計であり、裏チームの得点は、各イニングの裏の得点の合計である。

なお、ゲームアプリ２０－１が記憶するゲーム状況情報とゲームアプリ２０－２が記憶するゲーム状況情報とは、各情報項目自体は同じである。従って、ゲームアプリ２０－１が記憶するゲーム状況情報とゲームアプリ２０－２が記憶するゲーム状況情報は、それぞれ、自チームの各選手のスタミナや投球回数のみならず、相手チームの各選手のスタミナや投球回数等をも含む。

その後、ゲームアプリ２０は、ゲームサーバ３０１４からの訂正指示があるか否かを（Ｓ１２１４７４）判断する。訂正指示があった場合（Ｓ１２１４７４：ＹＥＳ）、ゲーム状況情報記憶部１２０内のゲーム状況情報（Ｓ１２１４７２で送信したゲーム状況情報）のうちの、対戦結果関連情報を修正する（Ｓ１２１４７６）。その後、ゲームアプリ２０は、修正した対戦結果関連情報をゲームサーバ３０１４に送信する（Ｓ１２１４７８）。次いで、ゲームアプリ２０は、ゲームサーバ３０１４からの結果通知指示があるか否か判断する（Ｓ１２１４８０）。結果通知指示があるか否かは、受信割り込み処理（図１２のステップＳ１７２、ステップＳ１７４）で、ゲームサーバ３０１４から受信され、保存されたものがあるか否かに基づいて判断できる。

次いで、ゲームアプリ２０は、結果通知指示がある場合（Ｓ１２１４８０：ＹＥＳ）、ＳＴＡＴＵＳを「ゲーム後」に変更し、結果通知処理として結果表示画面を表示する（Ｓ１２１４８２）。次いで、ゲームアプリ２０は、ゲームサーバ３０１４からの情報に基づいて、ゲームが正常に終了したか否かを判定する（Ｓ１２１４８４）。ゲームアプリ２０は、ゲームが正常に終了していなかった場合（Ｓ１２１４８４：ＮＯ）、ゲーム状況情報記憶部１２０に保存されている対戦結果関連情報の得点を出さないための得点非表示フラグを“オン”に設定する（Ｓ１２１４８６）。これにより、当該フラグは、描画処理（図１１のステップＳ１３０参照）において参照される。この結果、ゲームが正常に終了した場合（Ｓ１２１４８４：ＹＥＳ）は、対戦結果画面Ｇ７００（図１０Ａ参照）のように得点が表示され、ゲームが正常に終了しなかった場合（Ｓ１２１４８４：ＮＯ）は、対戦結果画面Ｇ７１０（図１０Ｂ参照）のように得点が表示されない。

図２５は、対戦処理（Ｓ１２１４６０）のフローチャートである。

対戦処理（Ｓ１２１４６０）では、ゲームの進行度合いを示すＧＴＩＭＥが利用される。ＧＴＩＭＥは、通常ゲーム進行処理（Ｓ１２１４６０２）が実行されるごとにカウントアップされる。通常ゲーム進行処理（Ｓ１２１４６０２）以外の各種処理、すなわち投球待ち処理（Ｓ１２１４６０６）や、投球入力待ち処理（Ｓ１２１４６１０）、打撃待ち処理（Ｓ１２１４６１４）では、ＧＴＩＭＥはカウントアップされない。これは、ゲームアプリ２０－１がゲームアプリ２０－２から（逆も同じ）操作情報等の必要な情報を受け取るまで、ゲーム内での時間を進めないようにするためである。ゲーム内での時間は進めないが、描画処理は、行われるため、選手のモーション等は再生される。この場合、選手はバットを揺らしたり、頭をかいたり等のゲーム進行に関係のないモーションが再生される。ＧＴＩＭＥがカウントアップされないため、ゲーム進行が止まる。そのため、ゲームアプリ２０－１、２０－２間で対戦処理がずれることはない。また、ゲーム初期化処理（Ｓ１２１４２）で初期化された乱数は、ＧＴＩＭＥがカウントアップされる通常ゲーム進行処理（Ｓ１２１４６０２）でしか、使用されない。

ゲームアプリ２０は、ＳＵＢＳＴＡＴＵＳが「通常進行」であれば（Ｓ１２１４６００：ＹＥＳ）、通常ゲーム進行処理（Ｓ１２１４６０２）を行い、ＳＵＢＳＴＡＴＵＳが「投球待ち」であれば（Ｓ１２１４６０４：ＹＥＳ）、投球待ち処理（Ｓ１２１４６０６）を行い、ＳＵＢＳＴＡＴＵＳが「投球入力待ち」であれば（Ｓ１２１４６０８：ＹＥＳ）、投球入力待ち処理（Ｓ１２１４６１０）を行い、ＳＵＢＳＴＡＴＵＳが「打撃待ち」であれば（Ｓ１２１４６１２：ＹＥＳ）、打撃待ち処理（Ｓ１２１４６１４）を行う。それぞれの処理については後述する。

図２６は、通常ゲーム進行処理（Ｓ１２１４６０２）のフローチャートである。

図２６に示すように、通常ゲーム進行処理（Ｓ１２１４６０２）では、ゲームアプリ２０は、ＧＴＩＭＥをカウントアップし、最新のＧＴＩＭＥに更新する（Ｓ１２１４６０２０）。その後、ゲームアプリ２０は、現在のＧＴＩＭＥに応じた各種処理を行う（Ｓ１２１４６０２２）。ＧＴＩＭＥに応じた各種処理とは、選手やボール等の３次元のゲームオブジェクトの位置座標の更新であったり、球場に設置される仮想カメラ（描画範囲を決める仮想カメラ）の移動であったり、仮想カメラの切り替えであったりする。

ここで、通常ゲーム進行処理（Ｓ１２１４６０２）におけるＧＴＩＭＥに応じた各種処理（Ｓ１２１４６０２２）は、ＧＴＩＭＥが進むのに伴って、ゲーム状況情報を更新する処理を含む。例えば、通常ゲーム進行処理（Ｓ１２１４６０２）において、ＧＴＩＭＥが進み、選手がホームインした場合、ホームインした選手のチームが表チームか裏チームかによって、裏チームの得点又は表チームの得点が加算される。すなわち、１回表～５回裏の得点のそれぞれに対応した箇所の得点が更新される（図２４参照）。ここでは、５回までの得点データしか説明していないが、延長回数も含めて、１５回までの得点データであっても、２０回までの得点データであってもよい。また、ゲームアプリ２０は、ＧＴＩＭＥに応じた各種処理の一部として、安打から牽制刺のそれぞれの値（図２４参照）を更新する。

なお、通常ゲーム進行処理（Ｓ１２１４６０２）では、打撃情報の加工と、ボールの位置移動のための処理が行われる。投手の手から捕手のミットまでのボールの位置移動のタイミングでバット操作が行われなかった場合、“見逃し”を示す打撃情報が、記憶部１２の送信キューにセットされる。バット操作は、振る操作や、バント用の操作等を含む。打者がバットを振り、バットにボールが当たった場合は、バットとボールの当たり具合が打撃情報として計算（加工）される。計算（加工）された打撃情報は、記憶部１２の送信キューにセットされる。すなわち、通常ゲーム進行処理（Ｓ１２１４６０２）では、ＧＴＩＭＥが進むと必ずボールが打者近くまで移動する。そして、通常ゲーム進行処理（Ｓ１２１４６０２）では、打者がバットを振ったか否かにかかわらず、所定のタイミングで打撃情報が記憶部１２の送信キューにセットされる。

ゲームアプリ２０は、Ｓ１２１４６０２２で各種処理を行った結果、打者がバッターボックスに入り、投手からの投球待ちの状態までＧＴＩＭＥが進む。ゲームアプリ２０は、攻撃側の場合（Ｓ１２１４６０２４：ＹＥＳ）、ＳＵＢＳＴＡＴＵＳを「投球待ち」に変更する（Ｓ１２１４６０２６）。ゲームアプリ２０は、守備側の場合（Ｓ１２１４６０２８：ＹＥＳ）、ＳＵＢＳＴＡＴＵＳは、「投球入力待ち」に変更する（Ｓ１２１４６０３０）。その後、ゲームアプリ２０は、対戦処理（Ｓ１２１４６０）に戻る。

図２７は、投球待ち処理（Ｓ１２１４６０６）のフローチャートである。投球待ち処理（Ｓ１２１４６０６）は、ゲームアプリ２０－２から投球情報が届くまでゲームアプリ２０－１がＧＴＩＭＥを進めないようにするための処理である。

図２７に示すように、投球待ち処理（Ｓ１２１４６０６）では、ゲームアプリ２０は、受信割り込み処理（図１２のステップＳ１７２、ステップＳ１７４）で受信したデータが保存される記憶部１２に投球情報があるか否かを判定し（Ｓ１２１４６０６０）、当該投球情報を通常ゲーム進行処理（Ｓ１２１４６０２）で使用する別の記憶領域（記憶部１２）に保存し直す（Ｓ１２１４６０６２）。なお、変形例では、投球情報は別の場所に保存され直されない。この場合、ゲームアプリ２０は、受信割り込み処理（図１２のステップＳ１７２、ステップＳ１７４）でゲームアプリ２０が受信したデータが保存される記憶部１２から、投球情報を読み出してよい。その後、ゲームアプリ２０は、ＳＵＢＳＴＡＴＵＳを「通常進行」に変更し（Ｓ１２１４６０６４）、対戦処理（Ｓ１２１４６０）に戻る。

図２８は、投球入力待ち処理（Ｓ１２１４６１０）のフローチャートである。

図２８に示すように、投球入力待ち処理（Ｓ１２１４６１０）では、ゲームアプリ２０は、操作部１４で入力された操作情報を受け取り、投球情報に加工する加工処理を行う（Ｓ１２１４６１００）。具体的には、投球情報の球種は、画面上のストレートを示すボタンをタップすればストレートという情報に、カーブを示すボタンを押せばカーブという情報に、それぞれ加工される。また、投球情報のコントロール精度（制球の精度）は、例えば、画面に表示されるタイミングバー（図示せず）のどのタイミングでタップしたかに基づいて算出される。ゲームアプリ２０は、これらのすべての操作情報を加工して投球情報を生成する。

なお、Ｓ１２１４６１００において、ゲームアプリ２０は、投球情報を加工する際に、操作割り込み処理（図１２のステップＳ１７６）でゲームアプリ２０が保存した操作情報を記憶部１２から読み出してもよい。なお、操作割り込み処理（図１２のステップＳ１７６）は、操作部１４から得た原始的な生データを“フリック”や“タップ”といった操作形態を表す情報に加工する処理を含む。Ｓ１２１４６１００の加工処理は、“フリック”や“タップ”といった操作形態を表す情報から投げたボールの球種やコントロールの精度等の投球情報に更に加工する処理である。

ゲームアプリ２０は、Ｓ１２１４６１００の加工処理の結果、投球情報が完成した場合（球種や精度等がすべて出揃った場合）（Ｓ１２１４６１０２：ＹＥＳ）、投球情報を記憶部１２の送信キューにセットする（Ｓ１２１４６１０４）。例えば、ゲームアプリ２０－１は、ゲームアプリ２０－２に投球情報を送信するために、投球情報をゲーム端末１０－１の記憶部１２の送信キューにセットし、ゲームアプリ２０－２は、ゲームアプリ２０－１に投球情報を送信するために、投球情報をゲーム端末１０－２の記憶部１２の送信キューにセットする。なお、ゲーム端末１０－１の記憶部１２の送信キューに入れられた投球情報は、送信割り込み処理（図１２のステップＳ１７８）によって、サーバ装置３０を介して、ゲームアプリ２０－２に送信される。同様に、ゲーム端末１０－２の記憶部１２の送信キューに入れられた投球情報は、送信割り込み処理（図１２のステップＳ１７８）によって、サーバ装置３０を介して、ゲームアプリ２０－１に送信される。

その後、ゲームアプリ２０は、ＳＵＢＳＴＡＴＵＳを「打撃待ち」に変更し（Ｓ１２１４６１０６）、対戦処理（Ｓ１２１４６０）に戻る。

図２９は、打撃待ち処理（Ｓ１２１４６１４）のフローチャートである。

図２９に示すように、打撃待ち処理（Ｓ１２１４６１４）では、ゲームアプリ２０は、受信割り込み処理（図１２のステップＳ１７２、ステップＳ１７４）で受信したデータが保存される記憶部１２に打撃情報があるか否かを判定し（Ｓ１２１４６１４０）、打撃情報があれば（Ｓ１２１４６１４０：ＹＥＳ）、ＳＵＢＳＴＡＴＵＳを「通常ゲーム進行」に変更する（Ｓ１２１４６１４２）。その後、ゲームアプリ２０は、対戦処理（Ｓ１２１４６０）に戻る。
ここで、投手側になっている例えばゲームアプリ２０－１が投球情報をゲームアプリ２０－２に送った後すぐにＳＵＢＳＴＡＴＵＳを「通常ゲーム進行」に変更してしまうと、ゲームアプリ２０－２からの打撃情報が送られてくる前にＧＴＩＭＥがカウントアップされ（Ｓ１２１４６０２）、ゲームが進行してしまう（Ｓ１２１４６０２２）ことで、不都合が生じうる。具体的には、ボールがバットに当たる直前になって、打撃情報が届かなかった場合、Ｓ１２１４６０２２で処理ができなくなってしまう。ボールがバットに当たる直前で、打撃情報が来ていなかったら、ＧＴＩＭＥのカウントアップは一時停止するという処理であってもよいが、この場合、打者がバットを振り、ボールに当たる直前で画面が静止してしまうことになるため、ユーザはゲームアプリ２０の不具合が出たように感じてしまう。また、ゲームをプレイしているユーザに違和感を与えてしまうことにもなる。

この点、図２９に示す処理によれば、受信割り込み処理で受信したデータが保存される記憶部１２に打撃情報がある場合に、ＳＵＢＳＴＡＴＵＳが「通常ゲーム進行」に変更されるので、上記のような不都合を防止できる。

なお、受信割り込み処理で受信したデータが保存される記憶部１２に打撃情報がない場合（Ｓ１２１４６１４０：ＮＯ）は、ＳＵＢＳＴＡＴＵＳが「通常ゲーム進行」に変更されないが、その間、投手と捕手が投球サインの交換をする等のゲーム進行に関係ない選手モーションを再生することで、ゲームアプリ２０の不具合が出たように感じさせないようにしてよい。

このようにして、ゲームアプリ２０－１は、投球入力待ち処理（Ｓ１２１４６１０）の後、打撃待ち処理（Ｓ１２１４６１４）では、ゲームアプリ２０－２から打撃情報を受け取るまでＧＴＩＭＥを更新せずに待つ処理を行う。同様に、ゲームアプリ２０－２は、投球入力待ち処理（Ｓ１２１４６１０）の後、打撃待ち処理（Ｓ１２１４６１４）では、ゲームアプリ２０－１から打撃情報を受け取るまでＧＴＩＭＥを更新せずに待つ処理を行う。

図３０は、ゲーム後処理（Ｓ１２１８）のフローチャートである。ゲーム後処理（Ｓ１２１８）は、ゲーム詳細情報の不整合を修正するための処理である。

図３０に示すように、ゲーム後処理（Ｓ１２１８）では、ゲームアプリ２０は、ゲームサーバ３０１４からの復元指示があるか否かを判定する（Ｓ１２１８０）。ゲームサーバ３０１４から復元指示があるか否かは、受信割り込み処理（図１２のステップＳ１７２、ステップＳ１７４）でサーバ装置３０から受信したデータ（内容に応じて記憶部１２に保存したデータ）に基づいて判断される。具体的には、ゲームサーバ３０１４から復元指示があるか否かは、復元要フラグの状態に基づいて判断される。

ゲーム後処理（Ｓ１２１８）では、ゲームアプリ２０は、復元指示があった場合、すなわち復元要フラグが“オン”状態である場合（Ｓ１２１８０：ＹＥＳ）、ゲーム状況情報のうちのゲーム詳細情報を修正する（Ｓ１２１８２）。ゲーム状況情報のうちの、ステップＳ１２１８２で修正対象となる情報項目は、復元処理（Ｓ１２１０４）で修正対象となる情報項目と同じである。すなわち、ステップＳ１２１８２及びステップＳ１２１０４では、いずれも、ゲーム詳細情報が修正対象である。本来は、ゲーム後処理（Ｓ１２１８）でゲーム詳細情報の修正が実現されるべきであるが、例えばゲームアプリ２０－１、２０－２を強制終了させた場合等は、ゲームアプリ２０－１、２０－２を再起動する必要があり、その場合、タイトル画面Ｇ１００から始まるため、ゲーム後処理（Ｓ１２１８）が行われないためである。ゲームアプリ２０は、ゲーム後処理（Ｓ１２１８）で修正が実現された場合は、復元処理（Ｓ１２１０４）が行われないように、復元要フラグを“オフ”にリセットする。

その後、ゲームアプリ２０は、ゲームサーバ３０１４から応答通知を受信すると（Ｓ１２１８４：ＹＥＳ）、ゲームサーバ３０１４から再びロビーサーバ３０１３に接続し直す（Ｓ１２１８６）。そして、ゲームアプリ２０は、ロビーサーバ３０１３に正しく接続ができたか否か判断し（Ｓ１２１８８）、正常に接続できた場合は（Ｓ１２１８８：ＹＥＳ）、ＳＴＡＴＵＳを「マップ」に変更し（Ｓ１２１９０）、正常に接続できなかった場合は（Ｓ１２１８８：ＮＯ）、ＳＴＡＴＵＳを「タイトル」に変更し（Ｓ１２１９２）、ゲームメイン処理（Ｓ１２０）に戻る。

なお、図３０に示す例では、ステップＳ１２１８０及びステップＳ１２１８２が実行されるが、ステップＳ１２１８０及びステップＳ１２１８２は省略されてもよい。これは、次の対戦を開始するためには必ずＳＴＡＴＵＳ「マップ」を経由する必要があり、復元要フラグが“オン”状態である場合、復元処理（Ｓ１２１０４）で修正されるためである。

次に、サーバ装置３０における各プロセスについて説明する。

図３１は、ゲートサーバプロセス４０のフローチャートである。

図３１に示すように、ゲートサーバプロセス４０は、ゲームアプリ２０からの接続要求を待機している（Ｓ４００：ＮＯ）。ゲートサーバプロセス４０は、ゲームアプリ２０からの接続要求があると（Ｓ４００：ＹＥＳ）、接続要求を送信したゲームアプリ２０との接続を許可する（Ｓ４０２）。その後、ゲートサーバ３０１１は、接続要求を送信したゲームアプリ２０に現在稼働中のサーバコンピュータで、比較的空いているサーバコンピュータを選んでサーバリストを送信する（Ｓ４０４）。ゲートサーバプロセス４０は、ゲームアプリ２０が切断するまでしばらく待つ（Ｓ４０６：ＮＯ）が、所定時間を過ぎる（Ｓ４０６：ＹＥＳ）と、強制的に切断する（Ｓ４０８）。その後、ゲートサーバプロセス４０は、Ｓ４００に戻って、他のゲームアプリ２０からの接続要求を待つ（Ｓ４００：ＮＯ）。ゲートサーバプロセス４０は、ゲームアプリ２０からの接続要求を一手に引き受ける。なお、ミラーリング等の技術を使い、複数のプロセスを並列に動作させる場合もあるが、基本的にゲートサーバプロセス４０によって、次に接続するサーバリストがゲームアプリ２０に与えられる。これにより、ゲームアプリ２０は、現在稼働中で、比較的空いているサーバコンピュータに接続することができる。ゲートサーバプロセス４０とゲームアプリ２０との通信においては、暗号化しない場合が一般的である。ゲートサーバプロセス４０は、ユーザ認証前の段階の通信であるため、ハッキングを受けたとしても、ハッキングで得られる情報からは稼働中のサーバコンピュータの有無しかわからないためである。

図３２は、認証サーバプロセス４１のフローチャートである。

図３２に示すように、認証サーバプロセス４１は、ゲームアプリ２０からの接続要求を待つ（Ｓ４１０：ＮＯ）。認証サーバプロセス４１は、ゲームアプリ２０からの接続要求があると（Ｓ４１０：ＹＥＳ）、接続処理を行う（Ｓ４１２）。認証サーバプロセス４１は、ゲームアプリ２０から送られてきた個人情報を、予め登録されている登録情報と照合する（Ｓ４１４）。認証サーバプロセス４１は、ゲームアプリ２０から送られてきた個人情報が正しかった場合（Ｓ４１６：ＹＥＳ）は、ユーザトークンを発行し、ユーザトークンを送信する（Ｓ４１８）。認証サーバプロセス４１は、ゲームアプリ２０から送られてきた個人情報が正しくなかった場合（Ｓ４１６：ＮＯ）は、個人情報が間違っている旨の内容（エラー）を送信する（Ｓ４２０）。その後、認証サーバプロセス４１は、ゲームアプリ２０からの切断を待つ（Ｓ４２２：ＮＯ）が、所定時間経っても、ゲームアプリ２０から切断されない場合（Ｓ４２２：ＹＥＳ）、ゲームアプリ２０との接続を切断する（Ｓ４２４）。その後、認証サーバプロセス４１は、ステップＳ４１０に戻り、他のゲームアプリ２０からの接続要求（ユーザ認証）を待つ（Ｓ４１０：ＮＯ）。

図３３は、ロビーサーバプロセス４３のフローチャートである。

図３３に示すように、ロビーサーバプロセス４３は、ゲームアプリ２０からの接続要求を待つ（Ｓ４３０：ＮＯ）。ロビーサーバプロセス４３は、ゲームアプリ２０からの接続要求があると（Ｓ４３０：ＹＥＳ）、接続処理を行う（Ｓ４３２）。その後、ロビーサーバプロセス４３は、現在接続しにきているゲームアプリ２０用のスレッド又は別プロセスを作成し、その後は別プロセスとやり取りできるようにする（Ｓ４３４）。その後、ロビーサーバプロセス４３は、ステップＳ４３０に戻って、他のゲームアプリ２０が接続してくるのを待つ。

図３４は、サブロビーサーバプロセス４４のフローチャートである。図３５は、ゲームデータ記憶部３２０に記憶されるゲームデータＤ３０１の一例を示す図である。なお、ゲームデータ記憶部３２０は、ＳＱＬサーバにより実現されてもよい。ここでは、ゲームデータＤ３０１を用いて説明を続ける。なお、図３５に示すゲームデータＤ３０１は、図５に示したゲームデータＤ５０（概要の説明用のゲームデータ）とは異なる。ゲームデータの詳細な構成は任意である。

サブロビーサーバプロセス４４は、ゲームデータＤ３０１における復元フラグ（接続中のゲームアプリに係る復元フラグ）の状態を参照して、修正すべきゲーム状況情報（ゲーム詳細情報）がありかつ未だ修正されていないか否かを判定する（Ｓ４４０）。復元フラグの“オン”状態は、修正すべきゲーム状況情報（ゲーム詳細情報）がありかつ未だ修正されていない状態である。図３５では、ユーザＩＤが「Ｕ００００００１」に関連付けられた復元フラグが“オン”状態であり、ユーザＩＤが「Ｕ００００００２」に関連付けられた復元フラグが“オフ”状態である。図３５では、ゲームデータＤ３０１は、ユーザＩＤごとに、ユーザランク、ユーザポイント、ユーザトークン、チーム情報、及び対戦結果情報（履歴）のデータを含む。チーム情報は、ゲームオブジェクトの識別情報（図３５では「選手ＩＤ」と表記）、ゲームオブジェクトの名前（図３５では「選手名」と表記）、ポジション、及びスタミナのデータを含む。また、対戦結果情報は、対戦ごとに、勝敗、点数、打率、及び防御率のデータを含む。

サブロビーサーバプロセス４４は、修正すべきゲーム状況情報（ゲーム詳細情報）がある場合（Ｓ４４０：ＹＥＳ）、復元指示を送信する（Ｓ４４２）。なお、復元指示は、上述した通りである。例えば、復元指示は、受信したゲームアプリ２０が当該復元指示に基づき正しい修正が実現できるものであれば任意の情報を含んでよく、“真”と看做されたゲーム状況情報の全部又は一部（ゲーム詳細情報）であってもよいし、修正内容を示す情報であってもよい。

サブロビーサーバプロセス４４は、ゲームアプリ２０から情報が送信されているか否かを判定する（Ｓ４４４）。更にゲームアプリ２０から送られてきた情報がゲーム開始要求であった場合（Ｓ４４６：ＹＥＳ）、サブロビーサーバプロセス４４は、ゲームアプリ２０との接続を切断して（Ｓ４５２）、プロセスを終了させる。サブロビーサーバプロセス４４は、ゲーム開始要求以外のデータであれば（Ｓ４４６：ＮＯ）、当該データを保存し（Ｓ４４８）、必要に応じて、当該データに対応する応答をゲームアプリ２０に送る（Ｓ４５０）。その後、サブロビーサーバプロセス４４は、ゲームアプリ２０からデータが送られてくるのを待つ（Ｓ４４４：ＮＯ）。

図３６は、ゲームサーバプロセス４６のフローチャートである。

ゲームサーバプロセス４６は、ゲームアプリ２０からの接続要求を待つ（Ｓ４６０：ＮＯ）。ゲームサーバプロセス４６は、ゲームアプリ２０からの接続要求があると（Ｓ４６０：ＹＥＳ）、ゲームアプリ２０との接続処理を行う（Ｓ４６２）。その後、ゲームサーバプロセス４６は、対戦が可能な状態になったか否かを判定する（Ｓ４６４）。野球のゲームの場合、１対１であるため、対戦が可能なゲームアプリ２０が２つ接続されたか否かを判定する（Ｓ４６４）。対戦が可能なゲームアプリ２０が２つ接続されていなければ（Ｓ４６４：ＮＯ）、ステップＳ４６０に戻り、対戦が可能なゲームアプリ２０が２つ接続された場合（Ｓ４６４：ＹＥＳ）は、進行処理に必要な初期データ（乱数シードやチーム情報）を２つのゲームアプリ２０に送信し（Ｓ４６６）、ステップＳ４６８へ進む。ゲームサーバプロセス４６は、接続したゲームアプリ２０のいずれかからデータ（パケット）を受信しているか否かを判定する（Ｓ４６８）。ゲームサーバプロセス４６は、受信したデータが他のゲームアプリ２０へのデータであれば、他のゲームアプリ２０へ当該データを送信する（Ｓ４７０）。その後、ゲームサーバプロセス４６は、ゲーム終了判定処理（Ｓ４７２）と切断判定処理（Ｓ４７４）を行う。その後、ゲームサーバプロセス４６は、ゲーム終了でないなら（Ｓ４７６：ＮＯ）、ステップＳ４６８へ戻り、ゲームアプリ２０からのデータ受信待ち状態となる。ゲームサーバプロセス４６は、ゲーム終了フラグが“オン”状態であるか否かを判定し（Ｓ４７６）、ゲーム終了フラグが“オン”状態であると（Ｓ４７６：ＹＥＳ）、結果通知指示をゲームアプリ２０に送信し（Ｓ４７８）、ステップＳ４６０に戻る。そして、ゲームサーバプロセス４６は、再びゲームアプリ２０からの接続要求を待つ（Ｓ４６０：ＮＯ）。

図３７は、ゲーム終了判定処理（Ｓ４７２）のフローチャートである。ゲーム終了判定処理（Ｓ４７２）は、ゲームアプリ２０－１、２０－２から送信されてくるゲーム状況情報が整合するか否かを判定する処理である。

図３７に示すように、ゲーム終了判定処理（Ｓ４７２）では、ゲームサーバプロセス４６は、ゲームアプリ２０－１、２０－２からゲーム終了通知とゲーム状況情報（図２３のステップＳ１２１４７２参照）が届いたか否かを判定する（Ｓ４７２０）。ゲーム終了通知及びゲーム状況情報が届いていない場合（Ｓ４７２０：ＮＯ）、ゲームサーバプロセス４６は、ゲーム終了判定処理（Ｓ４７２）を終了する。ゲーム終了通知及びゲーム状況情報が届いた場合（Ｓ４７２０：ＹＥＳ）、ゲームサーバプロセス４６は、ゲーム状況情報を保存し（Ｓ４７２２）、接続中のゲームアプリ２０からのゲーム状況情報が揃ったか否かを判定する（Ｓ４７２４）。接続中のゲームアプリ２０からのゲーム状況情報が揃っていない場合（Ｓ４７２４：ＮＯ）、ゲームサーバプロセス４６は、ゲーム終了判定処理（Ｓ４７２）を終了する。ステップＳ４７２４では、ゲームアプリ２０－１、２０－２のうちの、例えばゲームアプリ２０－２が切断されており、接続されていない場合は、ゲームアプリ２０－１だけが、接続中のゲームアプリ２０である。従って、この場合、ゲームアプリ２０－１からのゲーム終了通知及びゲーム状況情報が届いた場合は、接続中のゲームアプリ２０からのゲーム状況情報が揃ったと判定される。接続中のゲームアプリ２０からのゲーム状況情報が揃った場合（Ｓ４７２４：ＹＥＳ）、ゲームサーバプロセス４６は、各ゲーム状況情報のうちの、対戦結果関連情報が示す勝敗又は引き分けが整合しているか否かを判定する（Ｓ４７２６）。なお、リタイア等に起因して、接続中のゲームアプリ２０が１つだけである場合は、ステップＳ４７２６はスキップされて、ステップＳ４７３０に進んでもよい。勝敗が整合していなければ（Ｓ４７２６：ＮＯ）、ゲームサーバプロセス４６は、特殊処理を行う（Ｓ４７２８）。

特殊処理は、例えば、チートチェック用ソフトでチェックしたメモリの改ざんがあったか否かを判定し、改ざんがあれば改ざんがあった方のゲーム状況情報に含まれる改ざん内容を、元の内容に正す処理である。なお、ゲームサーバプロセス４６は、特殊処理の結果に基づいて勝敗又は引き分けを確定させる。なお、改ざんが検出できなかった場合は、ゲームサーバプロセス４６は、ゲームアプリ２０－１、２０－２からの各ゲーム状況情報のうちの、早く到着した方のゲーム状況情報に基づいて、勝敗又は引き分けを確定させてよい。また、ゲームサーバプロセス４６は、ゲームアプリ２０－１、２０－２のうちの一方が切断されている場合は、切断された方を“敗北”として、勝敗を確定させてよい。また、ゲームサーバプロセス４６は、ゲームアプリ２０－１、２０－２の双方が切断されている場合は、先に切断された方を“敗北”として、勝敗を確定させてよい。このようにすることで、簡易なルールに従って勝敗又は引き分けを確定させることができる。

勝敗が整合していれば（Ｓ４７２６：ＹＥＳ）、ゲームサーバプロセス４６は、対戦結果関連情報が示す得点が整合しているか否かを判定する（Ｓ４７３０）。得点が整合している場合（Ｓ４７３０：ＹＥＳ）、ゲームサーバプロセス４６は、ゲーム終了フラグを“オン”に設定する（Ｓ４７３４）。得点が整合していない場合（Ｓ４７３０：ＮＯ）、ゲームサーバプロセス４６は、ゲームアプリ２０－１、２０－２からの各ゲーム状況情報のうちの、早く到着した方のゲーム状況情報を“真”と看做し、他方のゲーム状況情報のうちの、対戦結果関連情報を修正するための訂正指示を生成及び送信する（Ｓ４７３２）。訂正指示の送信先は、ゲームアプリ２０－１、２０－２のうちの、修正を行うべき側、すなわち、遅く到着した方のゲーム状況情報を送信した側である。なお、ゲームアプリ２０－１、２０－２のうちの一方が切断されている場合は、他方からのゲーム状況情報が“真”と看做される。

このように、ゲームサーバ３０１４は、ゲームアプリ２０－１とゲームアプリ２０－２との間で同期をとって動作しているとき（図６ＡのセッションＳＣ３参照）、最低限の処理で進めるために、まず対戦結果関連情報だけをゲーム進行処理（Ｓ１２１４６）（図２３）で修正させ、ゲーム状況情報の大部分を復元処理（Ｓ１２１０４）（図１９）又はゲーム後処理（Ｓ１２１８）（図３０）で修正させる。

その後、ゲームサーバプロセス４６は、ゲームアプリ２０－１、２０－２からのゲーム状況情報のうちの、ゲーム詳細情報が整合しているか否かを判定し（Ｓ４７３６）、整合していなければ（Ｓ４７３６：ＮＯ）、復元フラグを“オン”に設定するとともに、ゲーム状況情報（ゲーム詳細情報）を修正するための復元指示を生成及び送信する（Ｓ４７３８）。復元指示の送信先は、ゲームアプリ２０－１、２０－２のうちの、“偽”と看做された方のゲーム状況情報を送信したゲームアプリである。ただし、ゲームアプリ２０－１、２０－２のうちの、復元指示の送信先のゲームアプリ２０が切断されている場合は、ゲームサーバプロセス４６は、復元指示の送信先のゲームアプリ２０に、復元指示を送信しなくてよい。この場合でも、復元フラグは“オン”にすることで、上述したサブロビーサーバプロセス４４のステップＳ４４２（図３４参照）に起因した復元処理（Ｓ１２１０４）（図１９参照）によって同様の修正が実現されることになる。

なお、ステップＳ４７３８における復元指示は、上述したサブロビーサーバプロセス４４のステップＳ４４２と同様であってよい。なお、復元フラグは、ゲームアプリ２０－１、２０－２ごとに管理され、ゲームアプリ２０－１、２０－２のうちの、修正を行うべき側の復元フラグが“オン”に設定される。すなわち、“真”と看做されたゲーム状況情報に対して、復元フラグは“オン”に設定されることはなく、“偽”と看做されたゲーム状況情報に対してのみ、復元フラグは“オン”に設定される。

ゲームサーバプロセス４６は、ゲームアプリ２０－１、２０－２からのゲーム詳細情報が整合していれば（Ｓ４７３６：ＹＥＳ）、ゲーム終了判定処理（Ｓ４７２）を終了する。

このように、図３７に示すゲーム終了判定処理（Ｓ４７２）によれば、ゲームアプリ２０－１、２０－２からの各ゲーム状況情報のうちの、早く受信された方のゲーム状況情報が“真”と看做され、他方のゲーム状況情報が“偽”と看做される。そして、“偽”と看做されたゲーム状況情報のうちの、対戦結果関連情報を修正するための訂正指示が生成及び送信される（Ｓ４７３２）とともに、“偽”と看做されたゲーム状況情報うちの、ゲーム詳細情報を修正するために、修正フラグが“オン”に設定される（Ｓ４７３８）。

なお、図３７に示す例では、ステップＳ４７３８において、復元指示の送信は省略されてもよい。すなわち、復元フラグが“オン”に設定されるだけであってもよい。この場合、それに伴い、上述のように、前出した図３０のゲーム後処理（Ｓ１２１８）のステップＳ１２１８０及びステップＳ１２１８２が省略されてよい。
また、図３７に示す例では、ステップＳ４７３２の後にステップＳ４７３６が実行されるが、ステップＳ４７３６は、ステップＳ４７３４が実行された後に実行されることとしてもよい。この場合、ステップＳ４７３６の処理時間に起因して結果通知指示の送信が遅れる可能性を、低減できる。

図３８は、切断判定処理（Ｓ４７４）のフローチャートである。以下の説明で用いるＳＵＢＳＴＡＴＵＳの初期値は、「切断待ち」であるとする。

図３８に示すように、ゲームサーバプロセス４６は、ゲームアプリ２０－１、２０－２のうちの、一方のゲームアプリ２０から切断要求（図１２のＳ１７０参照）を受信した場合（Ｓ４７４０：ＹＥＳ）はＳＵＢＳＴＡＴＵＳを「切断確認」に変更する（Ｓ４７４２）。

ゲームサーバプロセス４６は、ＳＵＢＳＴＡＴＵＳが「切断待ち」の場合（Ｓ４７４４：ＹＥＳ）、切断検知処理（Ｓ４７４６）を行う。ゲームサーバプロセス４６は、ＳＵＢＳＴＡＴＵＳが「切断確認」の場合（Ｓ４７４８：ＹＥＳ）、切断確認処理（Ｓ４７５０）を行う。その後、ゲームサーバプロセス４６は、切断判定処理（Ｓ４７４）を終了する。

図３９は、切断検知処理（Ｓ４７４６）のフローチャートである。

図３９に示すように、切断検知処理（Ｓ４７４６）では、ゲームサーバプロセス４６は、所定期間Ｔ１にわたりゲームアプリ２０－１、２０－２のうちのいずれか１つからの通信が途絶えたか否かを判定する（Ｓ４７４６０）。なお、ゲームアプリ２０－１、２０－２は、接続中、所定周期ごとにキープアライブをサーバ装置３０に送信している。通信が途絶えたか否かは、キープアライブが受信されるか否かに基づいて判断できる。所定期間Ｔ１は上述の通りである。ゲームサーバプロセス４６は、所定期間Ｔ１にわたり、あるゲームアプリ２０からの通信が途絶えたと判定した場合（Ｓ４７４６０：ＹＥＳ）、ゲームサーバプロセス４６は、ＳＵＢＳＴＡＴＵＳを「切断確認」に変更し（Ｓ４７４６２）、当該ゲームアプリ２０に応答確認用のリクエストを送信し（Ｓ４７４６４）、切断検知処理（Ｓ４７４６）を終了する。

図４０は、切断確認処理（Ｓ４７５０）のフローチャートである。

図４０に示すように、切断確認処理（Ｓ４７５０）では、ゲームサーバプロセス４６は、リタイア条件が成立したか否かを判定する。リタイア条件は、例えば、切断要求を受信してから所定期間Ｔ２経過した場合、応答確認用のリクエストに対応する応答が所定期間Ｔ３内に来なかった場合、又は、ゲームアプリ２０からの通信が途絶えたと確認した後更に所定期間Ｔ４経過した場合に成立する。リタイア条件が成立すると（Ｓ４７５００：ＹＥＳ）、ゲームサーバプロセス４６は、切断要求を行った側又は通信が途絶えた側のゲームアプリ２０をリタイアによる“敗北”にする（Ｓ４７５０２）。その後、ゲームサーバプロセス４６は、切断確認処理（Ｓ４７５０）を終了する。

以上、各実施例について詳述したが、特定の実施例に限定されるものではなく、特許請求の範囲に記載された範囲内において、種々の変形及び変更が可能である。また、前述した実施例の構成要素を全部又は複数を組み合わせることも可能である。

例えば、上述した実施例では、ゲームを進行する処理は、第１操作情報と第２操作情報とに基づく任意の態様であったが、これに限られない。すなわち、ゲームを進行する処理は、第１操作情報及び第２操作情報に基づくことなく、自動的に実現されてもよい。例えば、ゲームを進行する処理は、乱数と各チーム情報とに基づいて実行されてもよい。
また、上述した実施例では、ゲーム端末１０－１、１０－２間の通信はサーバ装置３０を介して実現されているが、無線による通信路を介して直接的に実現されてもよい。この場合、無線による通信路は、近距離無線通信、ブルートゥース（登録商標）、Ｗｉ－Ｆｉ（Ｗｉｒｅｌｅｓｓ Ｆｉｄｅｌｉｔｙ）等により実現されてもよい。
また、上述した実施例では、第１プレイヤ情報（第２プレイヤ情報についても同様）は、第１プレイヤに固有の情報以外の情報であってもよい。例えば、ゲームシステムによっては、最初はユーザ登録ができず、本ゲームシステム以外の各種サービスで使用するＩＤや、アカウント、ゲーム端末１０の機種のシリアルコード、Ｍａｃ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレスを使って仮ユーザ登録してもらい、少し遊んでもらった後に、本登録してもらう、という登録方式がある。また、ユーザが引継ぎデータを設定するまで本登録ができないゲームシステムも増えつつある。従って、かかるゲームシステムにおいては、第１プレイヤ情報に関連付けられた操作情報は、ユーザ（第１プレイヤ）が、ゲームアプリを起動し、サーバ認証を行った後のゲームアプリを操作した際の操作情報を含む。サーバ認証に関しては、第１プレイヤが正規の手続きとして入力したユーザ名に基づくサーバ認証に限られず、例えば、各種サービスのＩＤやゲーム端末１０の機種のシリアルコード等に基づくサーバ認証であってもよい。

なお、以上の実施例に関し、更に以下の付記を開示する。
［付記１］
互いに通信可能な第１ゲーム実行部（１１０）及び第２ゲーム実行部（１１０）を含むゲーム用のゲームシステム（１）であって、
前記第１ゲーム実行部（１１０）は、第１ユーザ情報に関連付けられた第１指示情報（例えば、操作部１４から得られる生データ又は生データを加工した情報）と、前記第１ユーザ情報とは異なる第２ユーザ情報に関連付けられた第２指示情報であって前記第２ゲーム実行部（１１０）から通信により取得した第２指示情報とに基づいて、前記ゲームを進行し、進行した前記ゲームのゲーム状況を表す第１ゲーム状況情報（例えばＤ１０１、Ｄ２４０）を第１記憶部（例えばゲーム状況情報記憶部１２０）に記憶する第１進行処理（例えばＴＡ８、ＴＡ１４、Ｓ１２１４６の処理）を実行し、
前記第２ゲーム実行部（１１０）は、前記第１ゲーム実行部（１１０）から通信により取得した前記第１指示情報と、前記第２指示情報とに基づいて、前記ゲームを進行し、進行した前記ゲームのゲーム状況を表す第２ゲーム状況情報（例えばＤ１０１、Ｄ２４０）を第２記憶部（例えばゲーム状況情報記憶部１２０）に記憶する第２進行処理（例えばＴＢ８、ＴＢ１４、Ｓ１２１４６の処理）を実行し、
前記ゲームの終了の際の前記第１ゲーム状況情報及び前記ゲームの終了の際の前記第２ゲーム状況情報を比較し（例えばＴＳ１４、Ｓ４７２６、Ｓ４７３６の処理）、比較結果に応じて、前記ゲームの終了の際の前記第１ゲーム状況情報及び前記ゲームの終了の際の前記第２ゲーム状況情報のうちの、一方のゲーム状況情報を、他方のゲーム状況情報に整合するように修正する修正処理（例えばＴＳ１４、ＴＳ１６、ＴＢ１８、ＴＢ２０、ＴＳ２２、ＴＳ２４、ＴＢ２８、ＴＢ３０、ＴＳ５０、ＴＢ５２、ＴＢ５４、ＴＳ６０、ＴＳ６６、ＴＢ６６、Ｓ４４２、Ｓ４７３２、Ｓ４７３８、Ｓ１２１０４、Ｓ１２１８２、Ｓ１２１４７６の処理）を実行する修正部（２００）を更に含む、ゲームシステム（１）。
付記１によるゲームシステム（１）によれば、ゲームの終了の際の第１ゲーム状況情報及びゲームの終了の際の第２ゲーム状況情報を比較し、比較結果に応じて、ゲームの終了の際の第１ゲーム状況情報及びゲームの終了の際の第２ゲーム状況情報のうちの、一方のゲーム状況情報を、他方のゲーム状況情報に整合するので、ユーザに違和感を与えるといった不都合を回避することが可能となる。
［付記２］
前記修正部（２００）は、前記比較結果として前記ゲームの終了の際の前記第１ゲーム状況情報（例えばＤ１０１、Ｄ２４０）及び前記ゲームの終了の際の前記第２ゲーム状況情報（例えばＤ１０１、Ｄ２４０）とが整合しない場合に、前記他方のゲーム状況情報に基づいて前記一方のゲーム状況情報を修正する前記修正処理を実行する、付記１に記載のゲームシステム（１）。
付記２によるゲームシステム（１）によれば、他方のゲーム状況情報を利用して一方のゲーム状況情報を修正できるので、新たにゲーム処理を行って“真”のゲーム状況情報を再現する必要性を低減できる。
［付記３］
前記第１ゲーム実行部（１１０）は、前記第１ユーザ情報に関連付けられたゲームオブジェクトの対戦能力に影響する第１対戦能力パラメータ（例えばＤ１０１のスタミナ）の値と、前記第２ユーザ情報に関連付けられたゲームオブジェクトの対戦能力に影響する第２対戦能力パラメータ（例えばＤ１０１のスタミナ）の値とに更に基づいて、前記第１進行処理（例えばＴＡ８、ＴＡ１４、Ｓ１２１４６の処理）を実行し、
前記第２ゲーム実行部（１１０）は、前記第１対戦能力パラメータの値と前記第２対戦能力パラメータの値とに更に基づいて、前記第２進行処理（例えばＴＢ８、ＴＢ１４、Ｓ１２１４６の処理）を実行し、
前記第１ゲーム状況情報は、前記第１対戦能力パラメータ及び前記第２対戦能力パラメータの各値とを含み、
前記第２ゲーム状況情報は、前記第１対戦能力パラメータ及び前記第２対戦能力パラメータの各値とを含み、
前記修正処理は、前記一方のゲーム状況情報の前記第１対戦能力パラメータ及び前記第２対戦能力パラメータの各値を、前記他方のゲーム状況情報の前記第１対戦能力パラメータ及び前記第２対戦能力パラメータの各値に整合するように修正するパラメータ修正処理（例えばＴＳ２２、ＴＳ２４、ＴＢ２８、ＴＢ３０、ＴＳ５０、ＴＢ５２、ＴＢ５４、ＴＳ６０、ＴＳ６６、ＴＢ６６、Ｓ４４２、Ｓ４７３８、Ｓ１２１０４、Ｓ１２１８２の処理）を含む、付記１又は２に記載のゲームシステム（１）。
付記３によるゲームシステム（１）によれば、次のゲームの際に利用される対戦能力パラメータの値を修正できるので、対戦能力パラメータの値が不利な方向に更新されないようにするための電源オフ操作が誘発されることを、防止できる。
［付記４］
前記第１ゲーム実行部（１１０）は、更に、第１通知タイミング（例えばＴＡ２０）で、前記ゲームの終了の際の前記第１ゲーム状況情報に基づいて、終了した前記ゲームに係る対戦結果を出力する結果通知処理（例えばＴＡ２０、Ｓ１２１４８２の処理）を実行し、
前記第２ゲーム実行部（１１０）は、更に、第２通知タイミング（例えばＴＢ２６）で、前記ゲームの終了の際の前記第２ゲーム状況情報に基づいて、終了した前記ゲームに係る対戦結果を出力する結果通知処理（例えばＴＢ２６、Ｓ１２１４８２の処理）を実行し、
前記第１ゲーム状況情報に係る前記パラメータ修正処理のうちの少なくとも一部は、前記第１通知タイミング（例えばＴＡ２０）よりも後に実行され、
前記第２ゲーム状況情報に係る前記パラメータ修正処理（例えばＴＳ２２、ＴＳ２４、ＴＢ２８、ＴＢ３０、ＴＳ５０、ＴＢ５２、ＴＢ５４、ＴＳ６０、ＴＳ６６、ＴＢ６６、Ｓ４４２、Ｓ４７３８、Ｓ１２１０４、Ｓ１２１８２の処理）のうちの少なくとも一部（（例えばＴＳ２４、ＴＢ２８、ＴＢ３０、ＴＳ５０、ＴＢ５２、ＴＢ５４、ＴＳ６０、ＴＳ６６、ＴＢ６６、Ｓ４４２、Ｓ４７３８、Ｓ１２１０４、Ｓ１２１８２の処理）は、前記第２通知タイミング（例えばＴＢ２６）よりも後に実行される、付記３に記載のゲームシステム（１）。
付記４によるゲームシステム（１）によれば、次のゲームの際に利用される対戦能力パラメータの値が、結果通知処理後に修正されるので、対戦能力パラメータの値が結果通知処理前に修正される場合よりも、結果通知処理が実行可能となるまでの時間を短くできる。この結果、修正が必要でない側における結果通知処理が可能となるまでの待ち時間（修正が必要となる側の修正が終了するまでの待機時間）を短くできる。
［付記５］
前記第１ゲーム状況情報及び前記第２ゲーム状況情報は、それぞれ、属性の異なる第１情報（例えば、対戦結果関連情報）と第２情報（例えば、対戦能力情報又はゲーム詳細情報）とを含み、
前記修正処理は、前記一方のゲーム状況情報の前記第１情報を修正する第１修正処理（例えばＴＳ１４、ＴＳ１６、ＴＢ１８、ＴＢ２０、Ｓ４７３２、Ｓ１２１４７６の処理）、及び、前記一方のゲーム状況情報の前記第２情報を修正する第２修正処理（例えばＴＳ２２、ＴＳ２４、ＴＢ２８、ＴＢ３０、ＴＳ５０、ＴＢ５２、ＴＢ５４、ＴＳ６０、ＴＳ６６、ＴＢ６６、Ｓ４４２、Ｓ４７３８、Ｓ１２１０４、Ｓ１２１８２の処理）の少なくともいずれか１つを含む、付記１に記載のゲームシステム（１）。
付記５によるゲームシステム（１）によれば、属性の異なる第１情報及び第２情報の少なくともいずれか１つに係る不整合が修正可能となる。
［付記６］
前記第１情報は、終了した前記ゲームに係る対戦結果に影響する第１パラメータ（例えば得点のような対戦結果関連パラメータ）の値を含み、
前記第２情報は、終了した前記ゲームに起因して値が変化する第２パラメータであって対戦能力に影響する第２パラメータ（例えばスタミナのような対戦能力パラメータ）の値を含む、付記５に記載のゲームシステム（１）。
付記６によるゲームシステム（１）によれば、第１パラメータの値を修正することで、ゲームに係る対戦結果を正しく出力できる可能性を高めることができる。また、第２パラメータの値を修正することで、第２パラメータの値が不利な方向に更新されないようにするための電源オフ操作が誘発されることを、防止できる。
［付記７］
前記修正部（２００）は、第１修正タイミングで前記第１修正処理（例えばＴＳ１４、ＴＳ１６、ＴＢ１８、ＴＢ２０、Ｓ４７３２、Ｓ１２１４７６の処理）のうちの少なくとも一部を実行し、
前記修正部（２００）は、前記第１修正タイミングとは異なる第２修正タイミングで前記第２修正処理（例えばＴＳ２２、ＴＳ２４、ＴＢ２８、ＴＢ３０、ＴＳ５０、ＴＢ５２、ＴＢ５４、ＴＳ６０、ＴＳ６６、ＴＢ６６、Ｓ４４２、Ｓ４７３８、Ｓ１２１０４、Ｓ１２１８２の処理）のうちの少なくとも一部を実行する、付記５又は６に記載のゲームシステム（１）。
付記７によるゲームシステム（１）によれば、属性の異なる第１情報及び第２情報について、異なるタイミングで修正できる。
［付記８］
前記第１ゲーム実行部（１１０）は、更に、第１通知タイミング（例えばＴＡ２０）で、前記ゲームの終了の際の前記第１ゲーム状況情報の前記第１情報に基づいて、終了した前記ゲームに係る対戦結果を出力する結果通知処理（例えばＴＡ２０、Ｓ１２１４８２の処理）を実行し、
前記第２ゲーム実行部（１１０）は、更に、第２通知タイミング（例えばＴＢ２６）で、前記ゲームの終了の際の前記第２ゲーム状況情報の前記第１情報に基づいて、終了した前記ゲームに係る対戦結果を出力する結果通知処理（例えばＴＢ２６、Ｓ１２１４８２の処理）を実行し、
前記第１ゲーム状況情報の前記第１情報を修正する場合の前記第１修正タイミングは、前記第１通知タイミングよりも前であり、
前記第２ゲーム状況情報の前記第１情報を修正する場合の前記第１修正タイミング（例えばＴＳ１４、ＴＳ１６、ＴＢ１８、ＴＢ２０）は、前記第２通知タイミングよりも前である、付記７に記載のゲームシステム（１）。
付記８によるゲームシステム（１）によれば、結果通知処理の前に第１情報を修正することで、ゲームに係る対戦結果を正しく出力できる可能性を高めることができる。
［付記９］
前記第１ゲーム実行部（１１０）は、更に、第１通知タイミング（例えばＴＡ２０）で、前記ゲームの終了の際の前記第１ゲーム状況情報の前記第１情報に基づいて、終了した前記ゲームに係る対戦結果を出力する結果通知処理（例えばＴＡ２０、Ｓ１２１４８２の処理）を実行し、
前記第２ゲーム実行部（１１０）は、更に、第２通知タイミング（例えばＴＢ２６）で、前記ゲームの終了の際の前記第２ゲーム状況情報の前記第１情報に基づいて、終了した前記ゲームに係る対戦結果を出力する結果通知処理（例えばＴＢ２６、Ｓ１２１４８２の処理）を実行し、
前記第１ゲーム状況情報の前記第２情報を修正する場合の前記第２修正タイミングは、前記第１通知タイミングよりも後であり、
前記第２ゲーム状況情報の前記第２情報を修正する場合の前記第２修正タイミング（例えばＴＳ２２、ＴＳ２４、ＴＢ２８、ＴＢ３０、ＴＳ５０、ＴＢ５２、ＴＢ５４、ＴＳ６０、ＴＳ６６、ＴＢ６６）は、前記第２通知タイミングよりも後である、付記７に記載のゲームシステム（１）。
付記９によるゲームシステム（１）によれば、結果通知処理の後に第２情報を修正することで、第２情報の不整合を修正可能としつつ、ゲームの終了後速やかに対戦結果を出力できる。
［付記１０］
前記結果通知処理（例えばＴＡ２０、ＴＢ２６、Ｓ１２１４８２の処理）は、前記第１ユーザ情報に関連付けられた得点と、前記第２ユーザ情報に関連付けられた得点とを出力することを含む、付記８又は９に記載のゲームシステム（１）。
付記１０によるゲームシステム（１）によれば、修正が反映された得点関係（対戦結果）を出力できる。
［付記１１］
前記第１ゲーム状況情報の前記第２情報は、前記ゲーム中に更新されることなく前記ゲームの終了後に更新される第１所定情報（例えば選手ごとの能力値のようなゲーム後更新パラメータの値を表す情報）を含み、
前記第２ゲーム状況情報の前記第２情報は、前記ゲーム中に更新されることなく前記ゲームの終了後に更新される第２所定情報（例えば選手ごとの能力値のようなゲーム後更新パラメータの値を表す情報）を含み、
前記第１ゲーム実行部（１１０）は、更に、前記ゲームの終了の際の前記第１ゲーム状況情報のうちの前記第１所定情報以外の情報に基づいて、前記第１所定情報を更新する第１更新処理を実行し（例えばＴＡ５０の処理）、
前記第２ゲーム実行部（１１０）は、更に、前記ゲームの終了の際の前記第２ゲーム状況情報のうちの前記第２所定情報以外の情報に基づいて、前記第２所定情報を更新する第２更新処理を実行し（例えばＴＢ５０の処理）、
前記第２修正処理は、前記第１更新処理又は前記第２更新処理により更新された前記第１所定情報又は前記第２所定情報を修正する処理（例えばＴＳ５０、ＴＢ５２、ＴＢ５４の処理）、又は、前記第１更新処理又は前記第２更新処理に代わり、前記ゲームの終了の際の前記第２ゲーム状況情報に基づいて前記第１所定情報を更新又は前記ゲームの終了の際の前記第１ゲーム状況情報に基づいて前記第２所定情報を更新する処理（例えばＴＳ５０、ＴＢ５２、ＴＢ５４の処理）を含む、付記５又は６に記載のゲームシステム（１）。
付記１１によるゲームシステム（１）によれば、ゲーム中に更新されることなく前記ゲームの終了後に更新される情報についても修正できる。
［付記１２］
前記ゲームの正常な終了が通信の遮断に起因して不能となる状態に基づいて、前記ゲームを強制的に終了する強制終了処理部（３０１）を更に含み、
前記修正部（２００）は、前記ゲームが正常に終了した場合に、前記第１修正処理（例えばＴＳ１４、ＴＳ１６、ＴＢ１８、ＴＢ２０、Ｓ４７３２、Ｓ１２１４７６の処理）と前記第２修正処理（例えばＴＳ２２、ＴＳ２４、ＴＢ２８、ＴＢ３０、ＴＳ５０、ＴＢ５２、ＴＢ５４、ＴＳ６０、ＴＳ６６、ＴＢ６６、Ｓ４４２、Ｓ４７３８、Ｓ１２１０４、Ｓ１２１８２の処理）を実行し、前記ゲームが強制的に終了された場合に、前記第２修正処理（例えばＴＳ２２、ＴＳ２４、ＴＢ２８、ＴＢ３０、ＴＳ５０、ＴＢ５２、ＴＢ５４、ＴＳ６０、ＴＳ６６、ＴＢ６６、Ｓ４４２、Ｓ４７３８、Ｓ１２１０４、Ｓ１２１８２の処理）を実行する、付記５～１１のうちのいずれか１項に記載のゲームシステム（１）。
付記１２によるゲームシステム（１）によれば、ゲームが正常に終了した場合は、第１情報及び第２情報の不整合が修正可能となり、ゲームが強制的に終了した場合は、第２情報の不整合が修正可能となる。
［付記１３］
前記修正部（２００）は、サーバ装置（３０）に設けられる判定処理部（３０２）と、前記第１記憶部（例えばゲーム状況情報記憶部１２０）を含む第１ゲーム端末（１０－１）に設けられる第１修正指示処理部（１１６）と、前記第１ゲーム端末（１０－１）とは異なりかつ前記第２記憶部（例えばゲーム状況情報記憶部１２０）を含む第２ゲーム端末（１０－２）に設けられる第２修正指示処理部（１１６）とを含み、
前記第１ゲーム実行部（１１０）は、前記第１ゲーム端末（１０－１）に設けられ、
前記第２ゲーム実行部（１１０）は、前記第２ゲーム端末（１０－２）に設けられ、
前記判定処理部（３０２）は、前記ゲームの終了の際の前記第１ゲーム状況情報及び前記ゲームの終了の際の前記第２ゲーム状況情報が整合するか否かを判定し、整合しないと判定した場合に、前記第１ゲーム実行部（１１０）又は前記第２ゲーム実行部（１１０）に修正指示を送信し、
前記第１修正指示処理部（１１６）は、前記判定処理部（３０２）から前記修正指示を受信した場合に、前記修正処理（例えばＳ４４２、Ｓ４７３２、Ｓ４７３８、Ｓ１２１０４、Ｓ１２１８２、Ｓ１２１４７６の処理）のうちの、前記第１ゲーム状況情報を修正する処理（例えばＳ１２１０４、Ｓ１２１８２、Ｓ１２１４７６の処理）を実行し、
前記第２修正指示処理部（１１６）は、前記判定処理部（３０２）から前記修正指示を受信した場合に、前記修正処理（例えばＳ４４２、Ｓ４７３２、Ｓ４７３８、Ｓ１２１０４、Ｓ１２１８２、Ｓ１２１４７６の処理）のうちの、前記第２ゲーム状況情報を修正する処理（例えばＳ１２１０４、Ｓ１２１８２、Ｓ１２１４７６の処理）を実行する、付記１～１２のうちのいずれか１項に記載のゲームシステム（１）。
付記１３によるゲームシステム（１）によれば、サーバ装置側で整合性を判断し、修正が必要な側のゲーム端末に修正指示を送信できる。
［付記１４］
前記第１ゲーム実行部（１１０）は、更に、前記ゲームの終了の際に、前記第１記憶部（例えばゲーム状況情報記憶部１２０）に記憶される前記第１ゲーム状況情報を前記サーバ装置（３０）に送信する第１ゲーム状況情報送信処理（例えばＴＡ１６の処理）を実行し、
前記第２ゲーム実行部（１１０）は、更に、前記ゲームの終了の際に、前記第２記憶部（例えばゲーム状況情報記憶部１２０）に記憶される前記第２ゲーム状況情報を前記サーバ装置（３０）に送信する第２ゲーム状況情報送信処理（例えばＴＢ１６の処理）を実行する、付記１３に記載のゲームシステム（１）。
付記１４によるゲームシステム（１）によれば、サーバ装置は、ゲームの終了の際に送信されてくる第１ゲーム状況情報及び第２ゲーム状況情報を比較できる。
［付記１５］
前記他方のゲーム状況情報は、前記ゲームの終了の際の前記第１ゲーム状況情報及び前記ゲームの終了の際の前記第２ゲーム状況情報のうちの、前記サーバ装置（３０）に早く受信された方である、付記１４に記載のゲームシステム（１）。
付記１５によるゲームシステム（１）によれば、簡易なルールに従って修正が必要なゲーム状況情報を決定できる。
［付記１６］
前記第１ゲーム実行部（１１０）は、更に、前記第１指示情報を前記サーバ装置（３０）に送信する第１指示情報送信処理（例えばＴＡ４、ＴＡ１２の処理）を実行し、
前記第２ゲーム実行部（１１０）は、更に、前記第２指示情報を前記サーバ装置（３０）に送信する第２指示情報送信処理（例えばＴＢ６、ＴＢ１０の処理）を実行し、
前記サーバ装置（３０）は、前記第１指示情報を前記第２ゲーム実行部（１１０）に送信し（例えばＴＳ４、ＴＳ１０の処理）、かつ、前記第２指示情報を前記第１ゲーム実行部（１１０）に送信する（例えばＴＳ６、ＴＳ８の処理）、付記１３に記載のゲームシステム（１）。
付記１６によるゲームシステム（１）によれば、サーバ装置は、指示情報の中継を行うだけでよく、サーバ装置の処理負荷を低減できる。
［付記１７］
前記第１ゲーム実行部（１１０）は、前記ゲームの開始時に、前記第１ユーザ情報に関連付けられた第１ゲームデータ（例えばＤ５０、Ｄ３０１）と、前記第２ユーザ情報に関連付けられた第２ゲームデータ（例えばＤ５０、Ｄ３０１）と、乱数シードとを含む初期データを取得し（例えばＴＡ２の処理）、前記ゲームの終了まで、前記初期データと、前記第１指示情報と、前記第２指示情報とに基づいて、前記第１進行処理を実行し（例えばＴＡ８、ＴＡ１４、Ｓ１２１４６の処理）、
前記第２ゲーム実行部（１１０）は、前記ゲームの開始時に前記初期データを取得し（例えばＴＢ２、ＴＢ６６の処理）、前記ゲームの終了まで、前記初期データと、前記第１指示情報と、前記第２指示情報とに基づいて、前記第２進行処理（例えばＴＢ８、ＴＢ１４、Ｓ１２１４６の処理）を実行する、付記１～１６のうちのいずれか１項に記載のゲームシステム（１）。
付記１７によるゲームシステム（１）によれば、乱数シードを用いた不確定要素によるゲーム性を高めることが可能となる。なお、第１ゲーム実行部と第２ゲーム実行部とで共通の乱数シードを用いることで、不確定要素の結果を第１進行処理と第２進行処理とで同じにできる。
［付記１８］
第１ユーザ情報に関連付けられた第１指示情報（例えば、操作部１４から得られる生データ又は生データを加工した情報）と前記第１ユーザ情報とは異なる第２ユーザ情報に関連付けられた第２指示情報であって第２ゲーム実行部（１１０）から通信により取得した第２指示情報とに基づいてゲームを進行し（例えばＴＡ８、ＴＡ１４、Ｓ１２１４６の処理）かつ進行した前記ゲームのゲーム状況を表す第１ゲーム状況情報を第１記憶部（例えばゲーム状況情報記憶部１２０）に記憶する第１ゲーム実行部（１１０）から、前記ゲームの終了の際の前記第１ゲーム状況情報を受信する第１受信処理（例えばＴＳ１２の処理）と、
前記第１ゲーム実行部（１１０）から通信により取得した前記第１指示情報と前記第２指示情報とに基づいて前記ゲームを進行し（例えばＴＡ８、ＴＡ１４、Ｓ１２１４６の処理）かつ進行した前記ゲームのゲーム状況を表す第２ゲーム状況情報を第２記憶部（例えばゲーム状況情報記憶部１２０）に記憶する前記第２ゲーム実行部（１１０）から、前記ゲームの終了の際の前記第２ゲーム状況情報を受信する第２受信処理（例えばＴＳ１２の処理）と、
前記ゲームの終了の際の前記第１ゲーム状況情報及び前記ゲームの終了の際の前記第２ゲーム状況情報を比較し（例えばＴＳ１４、ＴＳ２２、Ｓ４７２６、Ｓ４７３６の処理）、比較結果に応じて、前記ゲームの終了の際の前記第１ゲーム状況情報及び前記ゲームの終了の際の前記第２ゲーム状況情報のうちの、一方のゲーム状況情報を、他方のゲーム状況情報に整合するように修正するための修正指示を生成する処理（例えばＴＳ１６、ＴＳ２４、ＴＳ５０、ＴＳ６０、ＴＳ６６、Ｓ１２１０４、Ｓ１２１８２、Ｓ１２１４７６の処理）とを実行する、サーバ装置（３０）。
［付記１９］
第１ユーザ情報に関連付けられた第１指示情報（例えば、操作部１４から得られる生データ又は生データを加工した情報）と、前記第１ユーザ情報とは異なる第２ユーザ情報に関連付けられた第２指示情報であって通信により取得した第２指示情報とに基づいて、ゲームを進行し（例えばＴＡ８、ＴＡ１４、Ｓ１２１４６の処理）、
進行した前記ゲームのゲーム状況を表す第１ゲーム状況情報を記憶部（例えばゲーム状況情報記憶部１２０）に記憶し（例えばＴＢ８、ＴＢ１４、Ｓ１２１４６の処理）、
前記ゲームの終了の際の前記第１ゲーム状況情報をサーバ装置（３０）に送信し（例えばＴＢ１６の処理）、
前記第２指示情報及び通信により取得された前記第１指示情報に基づいて他のプログラムにより生成された前記ゲームに係る第２ゲーム状況情報と前記第１ゲーム状況情報との間の比較結果に応じて修正指示（例えばＴＳ１６、ＴＳ２４、ＴＳ５０、ＴＳ６０、ＴＳ６６、Ｓ１２１０４、Ｓ１２１８２、Ｓ１２１４７６の処理）を生成する前記サーバ装置（３０）から、前記修正指示を受信し（例えばＴＢ１８、ＴＢ２０、ＴＢ２８、ＴＢ３０、ＴＢ５２、ＴＢ５４、ＴＢ６６、Ｓ４４２、Ｓ４７３２、Ｓ４７３８の処理）、
受信した前記修正指示に基づいて、前記ゲームの終了の際の前記第１ゲーム状況情報を修正する（例えばＴＢ１８、ＴＢ２０、ＴＢ２８、ＴＢ３０の処理）、
処理を、コンピュータに実行させるプログラム。
［付記２０］
第１ゲーム実行部（１１０）及び第２ゲーム実行部（１１０）を含むゲーム用のゲームシステム（１）であって、
前記第１ゲーム実行部（１１０）は、所定のユーザ情報に関連付けられた第１指示情報（例えば、操作部１４から得られる生データ又は生データを加工した情報）と、前記第２ゲーム実行部（１１０）から通信により取得した第２指示情報とに基づいて、前記ゲームを進行し、進行した前記ゲームのゲーム状況を表す第１ゲーム状況情報を第１記憶部（例えばゲーム状況情報記憶部１２０）に記憶する第１進行処理（例えばＴＡ８、ＴＡ１４、Ｓ１２１４６の処理）を実行し、
前記第２ゲーム実行部（１１０）は、前記第１ゲーム実行部（１１０）から通信により取得した前記第１指示情報と、自動的に生成した前記第２指示情報とに基づいて、前記ゲームを進行し、進行した前記ゲームのゲーム状況を表す第２ゲーム状況情報を第２記憶部（例えばゲーム状況情報記憶部１２０）に記憶する第２進行処理（例えばＴＢ８、ＴＢ１４、Ｓ１２１４６の処理）を実行し、
前記ゲームの終了の際の前記第１ゲーム状況情報及び前記ゲームの終了の際の前記第２ゲーム状況情報を比較し（例えばＴＳ１４、ＴＳ２２、Ｓ４７２６、Ｓ４７３６の処理）、比較結果に応じて、前記ゲームの終了の際の前記第１ゲーム状況情報を、前記第２ゲーム状況情報に整合するように修正する修正処理（例えばＴＳ１４、ＴＳ１６、ＴＢ１８、ＴＢ２０、ＴＳ２２、ＴＳ２４、ＴＢ２８、ＴＢ３０、ＴＳ５０、ＴＢ５２、ＴＢ５４、ＴＳ６０、ＴＳ６６、ＴＢ６６、Ｓ４４２、Ｓ４７３２、Ｓ４７３８、Ｓ１２１０４、Ｓ１２１８２、Ｓ１２１４７６の処理）を実行する修正部（２００）を更に含む、ゲームシステム（１）。
付記２０によるゲームシステム（１）によれば、ゲームの終了の際の前記第１ゲーム状況情報及び前記ゲームの終了の際の前記第２ゲーム状況情報が比較され、比較結果に応じて、第１ゲーム状況情報を、第２ゲーム状況情報に整合するように修正する。これにより、ゲームの終了の際のゲーム状況情報間の不整合が放置されずに修正されるので、ゲームの終了の際のゲーム状況情報間の不整合が放置された場合の不都合を低減できる。また、第２ゲーム状況情報は、自動的に生成した第２指示情報に基づき生成されるので（すなわちユーザが入力した指示情報とは異なるので）、第２ゲーム実行部は、ユーザとは切り離してサーバ装置等により実現できる。そして、第２ゲーム実行部で生成される第２ゲーム状況情報の方を“真”として修正を行うことで、一貫性の高い態様で不整合を修正できる。
［付記２１］
互いに通信可能な第１ゲーム実行部（１１０）及び第２ゲーム実行部（１１０）を含むゲーム用のゲームシステム（１）であって、
前記第１ゲーム実行部（１１０）は、第１プレイヤ情報に関連付けられた第１操作情報（例えば、操作部１４から得られる生データ又は生データを加工した情報）と、前記第１プレイヤ情報とは異なる第２プレイヤ情報に関連付けられた第２操作情報であって前記第２ゲーム実行部から通信により取得した第２操作情報とに基づいて、前記ゲームを進行し、進行した前記ゲームのゲーム状況を表す第１ゲーム状況情報を第１記憶部に記憶する第１進行処理を実行し（例えばＴＡ８、ＴＡ１４、Ｓ１２１４６の処理）、
前記第２ゲーム実行部（１１０）は、前記第１ゲーム実行部から通信により取得した前記第１操作情報と、前記第２操作情報とに基づいて、前記ゲームを進行し、進行した前記ゲームのゲーム状況を表す第２ゲーム状況情報を第２記憶部に記憶する第２進行処理を実行し（例えばＴＢ８、ＴＢ１４、Ｓ１２１４６の処理）、
前記ゲームの終了の際の前記第１ゲーム状況情報及び前記ゲームの終了の際の前記第２ゲーム状況情報間の整合性に応じて、少なくとも一方のゲーム状況情報を修正する修正処理（例えばＴＳ１４、ＴＳ１６、ＴＢ１８、ＴＢ２０、ＴＳ２２、ＴＳ２４、ＴＢ２８、ＴＢ３０、ＴＳ５０、ＴＢ５２、ＴＢ５４、ＴＳ６０、ＴＳ６６、ＴＢ６６、Ｓ４４２、Ｓ４７３２、Ｓ４７３８、Ｓ１２１０４、Ｓ１２１８２、Ｓ１２１４７６の処理）を実行する修正部を更に含む、ゲームシステム。
付記２１によるゲームシステム（１）によれば、ゲームの終了の際の第１ゲーム状況情報及びゲームの終了の際の第２ゲーム状況情報間の整合性に応じて、少なくとも一方のゲーム状況情報を修正する修正処理を実行できる。これにより、ゲームの終了の際のゲーム状況情報間の不整合が放置されずに修正されるので、ゲームの終了の際のゲーム状況情報間の不整合が放置された場合の不都合を低減できる。

ところで、ゲームの終了の際のゲーム状況情報間の不整合が修正されないと、ユーザに違和感を与えたり、不利になる方向へのゲーム状況情報の更新を妨げるために電源オフ操作が誘発されたりするおそれがある。例えば、ゲーム状況情報が、対戦能力に影響するパラメータの値を含む場合、パラメータの値が不利な方向に変化するような場面等で、かかる変化を阻止すべく（例えば今回の対戦は諦めて次の対戦に備えて）電源オフ操作による強制終了が誘発されるおそれがある。
ゲーム状況情報は、不整合が生じる複数の属性の情報を含み得り、すべての属性の情報を一括して同時に修正すると、処理負荷が高くなり、ゲームの終了後の処理に時間がかかり、ユーザに違和感を与えるおそれがある。例えば、対戦結果の出力前に、不整合が生じたすべての属性の情報を修正すると、かかる修正のための処理時間に起因して対戦結果の出力が遅れ、ユーザに違和感を与えるおそれがある。
そこで、１つの側面では、本発明は、複数のゲーム実行部によりそれぞれ記憶されるゲーム状況情報間における不整合であって、ゲームの終了の際のゲーム状況情報間における不整合を、属性に応じたタイミングで修正することを目的とする。
［付記２２］
互いに通信可能な第１ゲーム実行部（１１０）及び第２ゲーム実行部（１１０）を含むゲーム用のゲームシステム（１）であって、
前記第１ゲーム実行部（１１０）は、ゲーム処理を行うことで前記ゲームを進行し、進行した前記ゲームのゲーム状況を表す第１ゲーム状況情報を第１記憶部（例えばゲーム状況情報記憶部１２０）に記憶する第１進行処理（例えばＴＡ８、ＴＡ１４、Ｓ１２１４６の処理）を実行し、
前記第２ゲーム実行部（１１０）は、ゲーム処理を行うことで前記ゲームを進行し、進行した前記ゲームのゲーム状況を表す第２ゲーム状況情報を第２記憶部（例えばゲーム状況情報記憶部１２０）に記憶する第２進行処理（例えばＴＢ８、ＴＢ１４、Ｓ１２１４６の処理）を実行し、
前記ゲームの終了の際の前記第１ゲーム状況情報及び前記ゲームの終了の際の前記第２ゲーム状況情報を比較し（例えばＴＳ１４、ＴＳ２２、Ｓ４７２６、Ｓ４７３６の処理）、比較結果に応じて、前記ゲームの終了の際の前記第１ゲーム状況情報及び前記ゲームの終了の際の前記第２ゲーム状況情報のうちの、一方のゲーム状況情報を、他方のゲーム状況情報に整合するように修正する修正処理（例えばＴＳ１４、ＴＳ１６、ＴＢ１８、ＴＢ２０、ＴＳ２２、ＴＳ２４、ＴＢ２８、ＴＢ３０、ＴＳ５０、ＴＢ５２、ＴＢ５４、ＴＳ６０、ＴＳ６６、ＴＢ６６、Ｓ４４２、Ｓ４７３２、Ｓ４７３８、Ｓ１２１０４、Ｓ１２１８２、Ｓ１２１４７６の処理）を実行する修正部（２００）を更に含み、
前記第１ゲーム状況情報及び前記第２ゲーム状況情報は、それぞれ、属性の異なる第１情報（例えば、対戦結果関連情報）と第２情報（例えば、対戦能力情報又はゲーム詳細情報）とを含み、
前記修正部（２００）は、第１修正タイミング（例えばＴＳ１４、ＴＳ１６、ＴＢ１８、ＴＢ２０）で前記第１情報を修正し（例えばＴＳ１４、ＴＳ１６、ＴＢ１８、ＴＢ２０、Ｓ４７３２、Ｓ１２１４７６の処理）、前記第１修正タイミングとは異なる第２修正タイミング（例えばＴＳ２２、ＴＳ２４、ＴＢ２８、ＴＢ３０、ＴＳ５０、ＴＢ５２、ＴＢ５４、ＴＳ６０、ＴＳ６６、ＴＢ６６）で前記第２情報を修正する（例えばＴＳ２２、ＴＳ２４、ＴＢ２８、ＴＢ３０、ＴＳ５０、ＴＢ５２、ＴＢ５４、ＴＳ６０、ＴＳ６６、ＴＢ６６、Ｓ４４２、Ｓ４７３８、Ｓ１２１０４、Ｓ１２１８２の処理）、ゲームシステム（１）。
付記２２によるゲームシステム（１）によれば、属性の異なる第１情報及び第２情報について、異なる属性に応じたタイミングで修正できる。これにより、修正のための処理時間に起因して対戦結果の出力が遅れる等の可能性を低減できる。

１ ゲームシステム
１０ ゲーム端末群
１０－１ ゲーム端末
１０－２ ゲーム端末
１０－３ ゲーム端末
１１ 制御部
１２ 記憶部
１３ 通信部
１４ 操作部
１５ 表示部
１６ 音声出力部
２０ ゲームアプリ
２０－１ ゲームアプリ
２０－２ ゲームアプリ
３０ サーバ装置
３１ 制御部
３２ 記憶部
３３ 通信部
４０ ゲートサーバプロセス
４１ 認証サーバプロセス
４２ ＳＱＬプロセス
４３ ロビーサーバプロセス
４４ サブロビーサーバプロセス
４４－１ サブロビーサーバプロセス
４４－２ サブロビーサーバプロセス
４５ マッチングプロセス
４６ ゲームサーバプロセス
４６－１ ゲームサーバプロセス
４６－２ ゲームサーバプロセス
１１０ ゲーム実行部
１１１ 進行処理部
１１２ 操作情報送受信処理部
１１３ 結果通知処理部
１１４ ゲーム状況情報送信処理部
１１５ 更新処理部
１１６ 修正指示処理部
１１８ 通信処理部
１２０ ゲーム状況情報記憶部
２００ 修正部
３０１ 強制終了処理部
３０２ 判定処理部
３０３ 整合性判定部
３０４ 修正指示生成部
３０６ ゲームデータ修正部
３２０ ゲームデータ記憶部
３０１１ ゲートサーバ
３０１２ 認証サーバ
３０１３ ロビーサーバ
３０１４ ゲームサーバ

Claims (11)

1. 互いに通信可能な第１ゲーム実行部及び第２ゲーム実行部を含むゲーム用のゲームシステムであって、
   前記第１ゲーム実行部は、第１ユーザ情報に関連付けられた第１指示情報と、前記第１ユーザ情報とは異なる第２ユーザ情報に関連付けられた第２指示情報であって前記第２ゲーム実行部から通信により取得した第２指示情報とに基づいて、前記ゲームを進行し、進行した前記ゲームのゲーム状況を表す第１ゲーム状況情報を第１記憶部に記憶する第１進行処理を実行し、
   前記第２ゲーム実行部は、前記第１ゲーム実行部から通信により取得した前記第１指示情報と、前記第２指示情報とに基づいて、前記ゲームを進行し、進行した前記ゲームのゲーム状況を表す第２ゲーム状況情報を第２記憶部に記憶する第２進行処理を実行し、
   前記ゲームの終了の際の前記第１ゲーム状況情報及び前記ゲームの終了の際の前記第２ゲーム状況情報を比較し、比較結果に応じて、前記ゲームの終了の際の前記第１ゲーム状況情報及び前記ゲームの終了の際の前記第２ゲーム状況情報のうちの、一方のゲーム状況情報を、他方のゲーム状況情報に整合するように修正する修正処理を実行する修正部を更に含む、ゲームシステム。
2. 前記修正部は、前記比較結果として前記ゲームの終了の際の前記第１ゲーム状況情報及び前記ゲームの終了の際の前記第２ゲーム状況情報とが整合しない場合に、前記他方のゲーム状況情報に基づいて前記一方のゲーム状況情報を修正する前記修正処理を実行する、請求項１に記載のゲームシステム。
3. 前記第１ゲーム実行部は、前記第１ユーザ情報に関連付けられたゲームオブジェクトの対戦能力に影響する第１対戦能力パラメータの値と、前記第２ユーザ情報に関連付けられたゲームオブジェクトの対戦能力に影響する第２対戦能力パラメータの値とに更に基づいて、前記第１進行処理を実行し、
   前記第２ゲーム実行部は、前記第１対戦能力パラメータの値と前記第２対戦能力パラメータの値とに更に基づいて、前記第２進行処理を実行し、
   前記第１ゲーム状況情報は、前記第１対戦能力パラメータ及び前記第２対戦能力パラメータの各値とを含み、
   前記第２ゲーム状況情報は、前記第１対戦能力パラメータ及び前記第２対戦能力パラメータの各値とを含み、
   前記修正処理は、前記一方のゲーム状況情報の前記第１対戦能力パラメータ及び前記第２対戦能力パラメータの各値を、前記他方のゲーム状況情報の前記第１対戦能力パラメータ及び前記第２対戦能力パラメータの各値に整合するように修正するパラメータ修正処理を含む、請求項１又は２に記載のゲームシステム。
4. 前記第１ゲーム実行部は、更に、第１通知タイミングで、前記ゲームの終了の際の前記第１ゲーム状況情報に基づいて、終了した前記ゲームに係る対戦結果を出力する結果通知処理を実行し、
   前記第２ゲーム実行部は、更に、第２通知タイミングで、前記ゲームの終了の際の前記第２ゲーム状況情報に基づいて、終了した前記ゲームに係る対戦結果を出力する結果通知処理を実行し、
   前記第１ゲーム状況情報に係る前記パラメータ修正処理のうちの少なくとも一部は、前記第１通知タイミングよりも後に実行され、
   前記第２ゲーム状況情報に係る前記パラメータ修正処理のうちの少なくとも一部は、前記第２通知タイミングよりも後に実行される、請求項３に記載のゲームシステム。
5. 前記第１ゲーム状況情報及び前記第２ゲーム状況情報は、それぞれ、属性の異なる第１情報と第２情報とを含み、
   前記修正処理は、前記一方のゲーム状況情報の前記第１情報を修正する第１修正処理、及び、前記一方のゲーム状況情報の前記第２情報を修正する第２修正処理の少なくともいずれか１つを含む、請求項１に記載のゲームシステム。
6. 前記第１情報は、終了した前記ゲームに係る対戦結果に影響する第１パラメータの値を含み、
   前記第２情報は、終了した前記ゲームに起因して値が変化する第２パラメータであって対戦能力に影響する第２パラメータの値を含む、請求項５に記載のゲームシステム。
7. 前記修正部は、第１修正タイミングで前記第１修正処理のうちの少なくとも一部を実行し、
   前記修正部は、前記第１修正タイミングとは異なる第２修正タイミングで前記第２修正処理のうちの少なくとも一部を実行する、請求項５又は６に記載のゲームシステム。
8. 前記第１ゲーム実行部は、更に、第１通知タイミングで、前記ゲームの終了の際の前記第１ゲーム状況情報の前記第１情報に基づいて、終了した前記ゲームに係る対戦結果を出力する結果通知処理を実行し、
   前記第２ゲーム実行部は、更に、第２通知タイミングで、前記ゲームの終了の際の前記第２ゲーム状況情報の前記第１情報に基づいて、終了した前記ゲームに係る対戦結果を出力する結果通知処理を実行し、
   前記第１ゲーム状況情報の前記第１情報を修正する場合の前記第１修正タイミングは、前記第１通知タイミングよりも前であり、
   前記第２ゲーム状況情報の前記第１情報を修正する場合の前記第１修正タイミングは、前記第２通知タイミングよりも前である、請求項７に記載のゲームシステム。
9. 前記第１ゲーム実行部は、更に、第１通知タイミングで、前記ゲームの終了の際の前記第１ゲーム状況情報の前記第１情報に基づいて、終了した前記ゲームに係る対戦結果を出力する結果通知処理を実行し、
   前記第２ゲーム実行部は、更に、第２通知タイミングで、前記ゲームの終了の際の前記第２ゲーム状況情報の前記第１情報に基づいて、終了した前記ゲームに係る対戦結果を出力する結果通知処理を実行し、
   前記第１ゲーム状況情報の前記第２情報を修正する場合の前記第２修正タイミングは、前記第１通知タイミングよりも後であり、
   前記第２ゲーム状況情報の前記第２情報を修正する場合の前記第２修正タイミングは、前記第２通知タイミングよりも後である、請求項７に記載のゲームシステム。
10. 第１ユーザ情報に関連付けられた第１指示情報と前記第１ユーザ情報とは異なる第２ユーザ情報に関連付けられた第２指示情報であって第２ゲーム実行部から通信により取得した第２指示情報とに基づいてゲームを進行しかつ進行した前記ゲームのゲーム状況を表す第１ゲーム状況情報を第１記憶部に記憶する第１ゲーム実行部から、前記ゲームの終了の際の前記第１ゲーム状況情報を受信する第１受信処理と、
    前記第１ゲーム実行部から通信により取得した前記第１指示情報と前記第２指示情報とに基づいて前記ゲームを進行しかつ進行した前記ゲームのゲーム状況を表す第２ゲーム状況情報を第２記憶部に記憶する前記第２ゲーム実行部から、前記ゲームの終了の際の前記第２ゲーム状況情報を受信する第２受信処理と、
    前記ゲームの終了の際の前記第１ゲーム状況情報及び前記ゲームの終了の際の前記第２ゲーム状況情報を比較し、比較結果に応じて、前記ゲームの終了の際の前記第１ゲーム状況情報及び前記ゲームの終了の際の前記第２ゲーム状況情報のうちの、一方のゲーム状況情報を、他方のゲーム状況情報に整合するように修正するための修正指示を生成する処理とを実行する、サーバ装置。
11. 第１ユーザ情報に関連付けられた第１指示情報と、前記第１ユーザ情報とは異なる第２ユーザ情報に関連付けられた第２指示情報であって通信により取得した第２指示情報とに基づいて、ゲームを進行し、
    進行した前記ゲームのゲーム状況を表す第１ゲーム状況情報を記憶部に記憶し、
    前記ゲームの終了の際の前記第１ゲーム状況情報をサーバ装置に送信し、
    前記第２指示情報及び通信により取得された前記第１指示情報に基づいて他のプログラムにより生成された前記ゲームに係る第２ゲーム状況情報と前記第１ゲーム状況情報との間の比較結果に応じて修正指示を生成する前記サーバ装置から、前記修正指示を受信し、
    受信した前記修正指示に基づいて、前記ゲームの終了の際の前記第１ゲーム状況情報を修正する、
    処理を、コンピュータに実行させるプログラム。

Images