JP2019141266A - ゲームシステム、ゲーム制御装置、及びプログラム - Google Patents

Abstract

【課題】ユーザが所望の役割を担当するための手間を軽減する。【解決手段】ゲームシステム（Ｓ）は、複数のユーザが役割を分担して参加するゲームを実行する。受付手段（３０３）は、各ユーザによる、ゲームへの参加要求を受け付ける。役割取得手段（３０４）は、複数の役割のうち、参加要求をしたユーザが所望する役割を取得する。追加手段（３０５）は、各役割と、ゲームへの参加を登録している参加登録ユーザのユーザ情報と、が関連付けられた参加登録データに、参加要求をしたユーザのユーザ情報を、当該ユーザが所望する役割と関連付けて追加する。選択手段（３０６）は、ゲームに参加する複数のユーザを選択する。選択手段（３０６）は、参加登録データに基づいて、役割ごとに、当該役割を担当するユーザを、当該役割にユーザ情報が関連付けられた参加登録ユーザの中から選択する。【選択図】図２３

Description

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

従来、複数のユーザが役割を分担して参加するゲームが知られている。例えば、特許文献１には、マッチングが行われた後に各ユーザに自分の役割を選択させたり、ユーザが自分の役割を選択した後に、当該役割に空きがある対戦部屋を探して入室したりするゲームシステムが記載されている。

特開２０１４−０６８８７０号公報

しかしながら、特許文献１の技術では、ユーザは、所望の役割を他のユーザに取られてしまい、当該役割を担当できないことがある。ユーザが対戦部屋に入室する前に自分の役割を選択したとしても、当該役割が空いている対戦部屋をいちいち探さなければならないので、手間がかかってしまう。

本発明は上記課題に鑑みてなされたものであって、その目的は、ユーザが所望の役割を担当するための手間を軽減することが可能なゲームシステム、ゲーム制御装置、及びプログラムを提供することである。

上記課題を解決するために、本発明の一態様に係るゲームシステムは、複数のユーザが役割を分担して参加するゲームを実行するゲームシステムであって、各ユーザによる、前記ゲームへの参加要求を受け付ける受付手段と、複数の役割のうち、前記参加要求をしたユーザが所望する役割を取得する役割取得手段と、各役割と、前記ゲームへの参加を登録している参加登録ユーザのユーザ情報と、が関連付けられた参加登録データに、前記参加要求をしたユーザのユーザ情報を、当該ユーザが所望する役割と関連付けて追加する追加手段と、前記ゲームに参加する複数のユーザを選択する手段であって、前記参加登録データに基づいて、前記役割ごとに、当該役割を担当するユーザを、当該役割に前記ユーザ情報が関連付けられた前記参加登録ユーザの中から選択する選択手段と、を含む。

本発明の一態様に係るゲーム制御装置は、複数のユーザが役割を分担して参加するゲームを実行するゲーム制御装置であって、各ユーザによる、前記ゲームへの参加要求を受け付ける受付手段と、複数の役割のうち、前記参加要求をしたユーザが所望する役割を取得する役割取得手段と、各役割と、前記ゲームへの参加を登録している参加登録ユーザのユーザ情報と、が関連付けられた参加登録データに、前記参加要求をしたユーザのユーザ情報を、当該ユーザが所望する役割と関連付けて追加する追加手段と、前記ゲームに参加する複数のユーザを選択する手段であって、前記参加登録データに基づいて、前記役割ごとに、当該役割を担当するユーザを、当該役割に前記ユーザ情報が関連付けられた前記参加登録ユーザの中から選択する選択手段と、を含む。

ゲームシステムの全体構成を示す図である。 マイページ画像の一例を示す図である。 試合メニュー画像の一例を示す図である。 個別対戦画像の一例を示す図である。 チーム情報画像の一例を示す図である。 マッチング画像の一例を示す図である。 対戦画像の一例を示す図である。 ゲーム端末の各々における個別対戦の進行を示す図である。 ゲームシステムで実現される機能のうち、本発明に関連する機能を示す機能ブロック図である。 状況データのデータ格納例を示す図である。 ユーザデータのデータ格納例を示す図である。 ゲームシステムにおいて実行される処理の一例を示すフロー図である。 ゲームシステムにおいて実行される処理の一例を示すフロー図である。 ゲームシステムにおいて実行される処理の一例を示すフロー図である。 グループ対戦における対戦画像の一例を示す図である。 対戦画像にウィンドウが表示される様子を示す図である。 対戦画像にメッセージが表示される様子を示す図である。 各ゲーム端末のゲームプログラムで実行されるゲームの進行を示す図である。 ゲームシステムで実現される機能のうち、本発明に関連する機能を示す機能ブロック図である。 ゲームシステムにおいて実行される処理の一例を示すフロー図である。 カード選択画像の一例を示す図である。 マッチング中のカード選択画像の一例を示す図である。 ゲームシステムで実現される機能のうち、本発明に関連する機能を示す機能ブロック図である。 参加登録データのデータ格納例を示す図である。 ゲームシステムにおいて実行される処理の一例を示すフロー図である。 Ｓ３４５の処理の詳細を示す図である。 実施形態３の変形例における機能ブロック図である。 第１のポジションと第２のポジションとの関係を示す図である。 第１の職業と第２の役職との関係を示す図である。

［１．実施形態１］
以下、本発明に係る実施形態を図面に基づいて説明する。なお、図面において同一又は対応する構成には同一の符号を付し、繰り返しの説明を省略することがある。

［１−１．ゲームシステムの全体構成］
図１は、ゲームシステムの全体構成を示す図である。図１に示すように、本実施形態に係るゲームシステムＳは、ゲーム端末１０Ａ，１０Ｂ、ゲートサーバ３０Ａ、認証サーバ３０Ｂ、ロビーサーバ３０Ｃ、及びゲームサーバ３０Ｄを含む。ゲーム端末１０Ａ，１０Ｂ、ゲートサーバ３０Ａ、認証サーバ３０Ｂ、ロビーサーバ３０Ｃ、及びゲームサーバ３０Ｄの各々は、インターネットなどのネットワークＮに接続される。

ゲーム端末１０Ａ，１０Ｂは、コンピュータである。例えば、ゲーム端末１０Ａ，１０Ｂは、携帯端末（例えば、スマートフォンなどの携帯電話又はタブレット型コンピュータ）、パーソナルコンピュータ、携帯ゲーム機、据置ゲーム機、業務用ゲーム機、又は、情報処理機能を備えた多機能型テレビジョン受像機（スマートテレビ）等である。

図１に示すように、ゲーム端末１０Ａは、制御部１１Ａ、記憶部１２Ａ、通信部１３Ａ、操作部１４Ａ、及び表示部１５Ａを含む。制御部１１Ａは、少なくとも１つのマイクロプロセッサを含む。

例えば、制御部１１Ａは、複数のマイクロプロセッサを含んでもよい。制御部１１Ａは、オペレーティングシステムやその他のプログラムに従って処理を実行する。記憶部１２Ａは、主記憶部（例えば、ＲＡＭ）及び補助記憶部（例えば、不揮発性の半導体メモリ）を含む。記憶部１２Ａは、プログラムやデータを記憶する。なお、例えば、ゲーム端末１０Ａがパーソナルコンピュータ等である場合、記憶部１２Ａは、例えばハードディスクドライブ又はソリッドステートドライブ等の補助記憶部を含むようにしてもよい。通信部１３Ａは、通信モジュールや通信インタフェースを含む。通信部１３Ａは、ネットワークＮを介してデータ通信を行う。

操作部１４Ａは、入力デバイスであり、例えば、キー、レバー、ゲームコントローラ（ゲームパッド）、マウスやタッチパネルなどのポインティングデバイス、又はキーボード等を含んでもよい。また例えば、操作部１４Ａは、ユーザが音声又はジェスチャによって入力操作を行うためのマイクやカメラを含んでもよい。表示部１５Ａは、例えば、液晶表示パネル又は有機ＥＬディスプレイ等であり、制御部１１の指示に従って画面を表示する。なお、操作部１４Ａ及び表示部１５Ａは、ゲーム端末１０Ａに内蔵されていなくともよく、ゲーム端末１０Ａに接続された外部装置であってもよい。

ゲーム端末１０Ｂは、制御部１１Ｂ、記憶部１２Ｂ、通信部１３Ｂ、操作部１４Ｂ、及び表示部１５Ｂを有する。制御部１１Ｂ、記憶部１２Ｂ、通信部１３Ｂ、操作部１４Ｂ、及び表示部１５Ｂのハードウェア構成は、それぞれ制御部１１Ａ、記憶部１２Ａ、通信部１３Ａ、操作部１４Ａ、及び表示部１５Ａと同様であってよい。

なお、本実施形態では、ゲーム端末１０Ａ，１０Ｂを特に区別する必要のないときは、単にゲーム端末１０と記載する。また、制御部１１Ａ，１１Ｂを区別する必要のないときは、単に制御部１１と記載する。同様に、記憶部１２Ａ，１２Ｂ、通信部１３Ａ，１３Ｂ、操作部１４Ａ，１４Ｂ、及び表示部１５Ａ，１５Ｂを、単に記憶部１２、通信部１３、操作部１４、及び表示部１５と記載することもある。また、図１では、２台のゲーム端末１０を例に挙げたが、ゲームシステムＳ内のゲーム端末１０の台数に制限はなく、ゲーム端末１０は、３台以上であってもよいし、１台だけであってもよい。

ゲートサーバ３０Ａは、サーバコンピュータである。図１に示すように、ゲートサーバ３０Ａは、制御部３１Ａ、記憶部３２Ａ、及び通信部３３Ａを含む。制御部３１Ａ、記憶部３２Ａ、及び通信部３３Ａのハードウェア構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。例えば、ゲートサーバ３０Ａは、ゲームシステムＳ内のサーバコンピュータのリストを管理し、例えば、認証サーバ３０Ｂ、ロビーサーバ３０Ｃ、及びゲームサーバ３０Ｄの各々のサーバ名やＩＰアドレス等の情報を管理する。

認証サーバ３０Ｂは、サーバコンピュータである。図１に示すように、認証サーバ３０Ｂは、制御部３１Ｂ、記憶部３２Ｂ、及び通信部３３Ｂを含む。制御部３１Ｂ、記憶部３２Ｂ、及び通信部３３Ｂのハードウェア構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。例えば、認証サーバ３０Ｂは、ユーザ情報等の認証情報に基づいてユーザ認証を実行する。

ロビーサーバ３０Ｃは、サーバコンピュータである。図１に示すように、ロビーサーバ３０Ｃは、制御部３１Ｃ、記憶部３２Ｃ、及び通信部３３Ｃを含む。制御部３１Ｃ、記憶部３２Ｃ、及び通信部３３Ｃのハードウェア構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。例えば、ロビーサーバ３０Ｃは、対戦におけるマッチングを実行する。

ゲームサーバ３０Ｄは、サーバコンピュータである。図１に示すように、ゲームサーバ３０Ｄは、制御部３１Ｄ、記憶部３２Ｄ、及び通信部３３Ｄを含む。制御部３１Ｄ、記憶部３２Ｄ、及び通信部３３Ｄのハードウェア構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。例えば、ゲームサーバ３０Ｄは、マッチング完了後にゲーム端末１０が接続するサーバであり、対戦を実行する。

なお、本実施形態では、ゲートサーバ３０Ａ、認証サーバ３０Ｂ、ロビーサーバ３０Ｃ、及びゲームサーバ３０Ｄを区別する必要のないときは、単にサーバ３０と記載する。また、制御部３１Ａ〜３１Ｄを区別する必要のないときは、単に制御部３１と記載する。同様に、記憶部３２Ａ〜３２Ｄを区別する必要のないときは、単に記憶部３２と記載し、通信部３３Ａ〜３３Ｄを区別する必要のないときは、単に通信部３３と記載する。

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

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

［１−２．ゲームの概要］
本実施形態では、複数のユーザがそれぞれゲーム端末１０を操作する。例えば、ゲームシステムＳが第１のゲーム端末であるゲーム端末１０Ａと、第２のゲーム端末であるゲーム端末１０Ｂと、を含む場合、ゲーム端末１０Ａを使用する第１ユーザと、第２ゲーム端末を使用する第２ユーザとが上記「複数のユーザ」に相当する。

ゲームシステムＳで実行されるゲームは、任意のゲームであってよく、例えば、対戦ゲームであってもよい。また例えば、サッカーゲーム、野球ゲーム、バスケットボールゲーム、アイスホッケーゲーム、レースゲーム、格闘ゲーム、又はカードゲーム等であってもよい。これらのゲームに限られず、他の種類の対戦ゲームであってもよい。また例えば、対戦に限られず、共通の目的を達成することを目指す協力ゲームであってもよい。なお、目的とは、例えば、対戦に勝利すること、敵を退治すること、ゲームオブジェクトが所定の地点に到達すること、ゲーム評価が所定の基準を満たすこと、又はゲームアイテムを入手すること等である。また例えば、対戦相手チームとの試合に勝利することを目指すスポーツゲームであってもよい。また例えば、他のグループとの戦闘に勝利したり、特定の敵キャラクタを退治したり、又は、特定のゲームアイテムを入手したりすることを目指すアクションゲーム又はロールプレイングゲーム等であってもよい。

本実施形態では、ゲームの一例として、サッカーゲームを説明する。ゲーム端末１０においてゲームプログラムが起動すると、ゲームのタイトル画像などが表示された後に、トップページに相当するマイページ画像が表示部１５に表示される。

図２は、マイページ画像の一例を示す図である。図２に示すように、マイページ画像Ｇ１は、ポイントやコインなどのゲーム内通貨やチーム名を表示するための表示領域Ａ１０と、チームの代表選手を表示するための表示領域Ａ１１と、を含む。なお、マイページ画像Ｇ１に表示される情報は、これらに限られず、開催中のイベントなどの情報が表示されてもよい。

また、マイページ画像Ｇ１には、マイページ画像Ｇ１を表示させるためのボタンＢ１２、対戦を実行するためのボタンＢ１３、チームの編成をするためのボタンＢ１４、チーム内のキャラクタを表示するためのボタンＢ１５、及び、キャラクタが描かれたカードの抽選をするためのボタンＢ１６が表示される。例えば、ボタンＢ１３が選択されると、試合のメニューを示す試合メニュー画像が表示部１５に表示される。

図３は、試合メニュー画像の一例を示す図である。図３に示すように、試合メニュー画像Ｇ２には、イベントに参加するためのボタンＢ２０、コンピュータと対戦するためのボタンＢ２１、１人対１人の対戦である個別対戦をするためのボタンＢ２２、及び、複数人でチームを組むグループ対戦をするためのボタンＢ２３が表示される。

本実施形態では、個別対戦について説明する。個別対戦では、あるユーザ情報に関連付けられたチーム情報と、他のユーザ情報に関連付けられたチーム情報と、に基づいて、対戦が実行される。チーム情報は、チームに所属するキャラクタが描かれたカードに関する情報を含み、例えば、キャラクタの名前、能力パラメータ、スキル、画像、及び３次元モデルといった情報を含む。

例えば、個別対戦は、操作部１４に対する操作が介入されることなく、原則として自動進行する。即ち、各チームのキャラクタは、操作部１４の検出信号に従って動作するのではなく、ゲームプログラムが決定した動作をする。例えば、ボタンＢ２２が選択されると、個別対戦をするための個別対戦画像が表示部１５に表示される。

図４は、個別対戦画像の一例を示す図である。図４に示すように、個別対戦画像Ｇ３は、チームのレベル情報やランク情報を表示するための表示領域Ａ３０と、個別対戦で勝利した場合の獲得ポイントやミッションの条件などを表示するための表示領域Ａ３１と、を含む。また例えば、個別対戦画像Ｇ３には、個別対戦を開始するためのボタンＢ３２，Ｂ３３が表示される。

本実施形態では、ポイントを消費することによって個別対戦が実行され、例えば、ボタンＢ３２は、１ポイント消費して個別対戦を１回実行するためのボタンであり、ボタンＢ３３は、全てのポイントを消費して個別対戦を複数回連続して実行するためのボタンである。

ここでは、ボタンＢ３２が選択された場合の個別対戦の流れを説明するが、ボタンＢ３３が選択された場合も、個別対戦が連続的に実行される点で異なるだけであり、個々の個別対戦の流れは、ボタンＢ３２が選択された場合と同じである。ボタンＢ３２が選択されると、チーム情報を表示するためのチーム情報画像が表示部１５に表示される。

図５は、チーム情報画像の一例を示す図である。図５に示すように、チーム情報画像Ｇ４は、チーム名やチーム画像を表示するための表示領域Ａ４０と、チームの総合的な強さを示す総合値やフォーメーションなどの情報を表示するための表示領域Ａ４１，Ａ４２と、を含む。なお、チーム情報画像Ｇ４が表示されたばかりの時点では、まだマッチングが実行されていないので、対戦相手チームの情報は表示されない。また例えば、チーム情報画像Ｇ４には、個別対戦を開始するためのボタンＢ４３が表示される。ボタンＢ４３が選択されると、所定量のポイントが消費され、対戦相手を探すためのマッチングが開始される。マッチングの実行中は、マッチング画像が表示部１５に表示される。

図６は、マッチング画像の一例を示す図である。図６に示すように、マッチング画像Ｇ５は、マッチング中であることを示すメッセージが表示される。マッチングが完了すると、対戦相手のチーム情報が表示された後に、個別対戦が開始される。個別対戦が開始されると、実行中の個別対戦の様子を示す対戦画像が表示部１５に表示される。

図７は、対戦画像の一例を示す図である。図７に示すように、対戦画像Ｇ６は、各チームの名前と得点を表示するための表示領域Ａ６０と、ゲーム空間の現在の様子を表示するための表示領域Ａ６１と、を含む。本実施形態では、３次元のゲーム空間が構築され、ゲーム空間内の所定位置に仮想カメラが設定される。ゲーム空間に配置された各キャラクタやボールの３次元モデルが座標変換され、仮想カメラからゲーム空間を見た様子を示す画像が表示領域Ａ６１に表示される。

本実施形態では、原則として、ゲーム端末１０Ａとゲーム端末１０Ｂとの間で、データの整合性（同期）を取ることなく、個別対戦が実行される。即ち、ゲーム端末１０間で操作信号を送り合ったり、更新後のデータを送り合ったりすることなく、各ゲーム端末１０で個別にデータの更新が実行される。

また、本実施形態では、各ゲーム端末１０で同じ進行状況・試合結果とするために、ゲームサーバ３０Ｄは、ゲームの開始時において、各ゲーム端末１０に対し、共通の乱数シードを送信する。詳細は後述するが、乱数シードは、乱数列を生成するための情報であり、乱数シードが同じ値であれば、生成される乱数列も同じとなる。

ゲーム端末１０Ａ，１０Ｂは、受信した乱数シードに基づいて乱数列を生成し、自身のゲームプログラムに基づいて、キャラクタの動作を決定する。ゲーム端末１０Ａ，１０Ｂの各々において生成される乱数列が同じなので、キャラクタの動作結果も同じとなり、ゲーム端末１０Ａ，１０Ｂで同じ処理結果が得られる。ただし、ゲーム端末１０Ａ，１０Ｂで独自に個別対戦を実行させると、ゲーム端末１０Ａ，１０Ｂの各々で進行にずれが生じる可能性がある。例えば、ゲーム端末１０Ａの方が、ゲーム端末１０Ｂよりも高性能の場合、ゲーム端末１０Ａの進行が、ゲーム端末１０Ｂよりも早くなることがある。

図８は、ゲーム端末１０Ａ，１０Ｂの各々における個別対戦の進行を示す図である。図８の例では、ゲーム端末１０Ａの方が、ゲーム端末１０Ｂよりも高性能とする。また、ゲーム端末１０Ａが実行するゲームプログラムを「ゲームプログラムＡ」と記載し、ゲーム端末１０Ｂが実行するゲームプログラムを「ゲームプログラムＢ」と記載する。なお、図８は、ゲームの進行にずれが生じる場合を説明する図のため、ゲームサーバ３０Ｄ等のサーバ３０は省略している。

図８に示すように、ゲーム端末１０ＡのゲームプログラムＡと、ゲーム端末１０ＢのゲームプログラムＢと、の各々が同時に試合を開始したとしても、ゲーム端末１０Ａの方がゲーム端末１０Ｂよりも高性能のため、ゲームプログラムＡが実行する個別対戦の方が、進行が早い。例えば、前半１０分にゴールが決まったとすると、ゴールシーンが発生するのは、ゲームプログラムＡの方がゲームプログラムＢよりも早い。また例えば、前半１５分に反則が発生したとすると、反則が発生するのは、ゲームプログラムＡの方がゲームプログラムＢよりも早い。

このように、ゲームプログラムＡとＢで結果は同じとなるが、ゲームの進行はゲーム端末１０Ａの方が早くなり、ゲーム端末１０ＡのゲームプログラムＡが実行する個別対戦と、ゲーム端末１０ＢのゲームプログラムＢが実行する個別対戦と、の間で徐々に進行の差が大きくなる。進行のずれは、主に、コンピュータの性能の差に起因するため、計算量の多い処理が発生するほど、進行のずれが大きくなる。

例えば、サッカーゲームでは、ゴールが決まったり反則が発生したりすると、試合が一時的に停止するアウトオブプレイになるが、この場合にリプレイ映像を流したとすると、リプレイ映像は画像処理による計算量が高いため、アウトオブプレイが発生するほど進行のずれが大きくなる。

このため、本実施形態では、アウトオブプレイが発生した回数をカウントし、一定回数のアウトオブプレイが発生すると、個別対戦の進行を一時的に停止して、相手方の進行が追いつくまで待機する。図８の例であれば、例えば、ゲーム端末１０ＡのゲームプログラムＡは、アウトオブプレイが１０回発生すると、個別対戦の進行を一時停止する。この間は、対戦画像Ｇ６の表示が変わらないようにしてもよいし、対戦画像Ｇ６の表示を止めてゲームに関係のない映像を流してもよい。その後、ゲーム端末１０ＢのゲームプログラムＢが実行する個別対戦の進行が追いついた場合に、ゲーム端末１０ＡのゲームプログラムＡは、個別対戦の進行を再開する。

上記のように、本実施形態のゲームシステムＳは、複数のゲーム端末１０で共通の乱数発生規則に基づいて発生される乱数を利用し、各ゲーム端末１０で独自にゲーム処理を実行することで、通信を利用してデータの整合性を取ることなく、同じ対戦結果を得ることで、通信負荷を軽減するようになっている。また、アウトオブプレイが一定回数発生すると、相手方の進行が追いつくまで待機するようになっている。以降、当該構成の詳細を説明する。

［１−３．ゲームシステムで実現される機能］
図９は、ゲームシステムＳで実現される機能のうち、本発明に関連する機能を示す機能ブロック図である。ここでは、ゲーム端末１０で実現される機能と、サーバ３０で実現される機能と、について説明する。

［１−３−１．ゲーム端末で実現される機能］
ゲームシステムＳでは、複数のゲーム実行部１００が実現される。例えば、ゲーム端末１０は、複数のゲーム実行部１００のうちの少なくとも１つを含む。ゲーム端末１０に含まれるゲーム実行部１００の数は、１つであってもよいし複数であってもよい。例えば、ゲームプログラム（アプリケーション）、ブラウザ、又は端末が、ゲーム実行部１００に相当する。各ゲーム実行部１００は、別々の端末内に存在してもよいし、１つの端末内に複数のゲーム実行部１００が存在してもよい。なお、図９では、図面の簡略化のために、ゲーム実行部１００を１つだけ図示する。

本実施形態では、各ゲーム端末１０でゲーム実行部１００が実現され、１台のゲーム端末１０に対し、１つのゲーム実行部１００が実現される場合を例に挙げる。ただし、１台のゲーム端末１０内に複数のゲーム実行部１００が存在してもよく、例えば、１台のゲーム端末１０において、複数のブラウザが起動し、個々のブラウザがゲーム実行部１００に相当してもよい。また例えば、１台のゲーム端末１０において、複数のゲームプログラムが起動し、個々のゲームプログラムがゲーム実行部１００に相当してもよい。

［ゲーム実行部］
ゲーム実行部１００は、制御部１１及び記憶部１２を主として実現される。ゲーム実行部１００は、ゲームを実行する。ゲームを実行するとは、例えば、ゲームプログラムを実行し、プログラムコードに記述された各種処理を実行することである。処理としては、例えば、キャラクタやボールなどのオブジェクトを移動させる処理、パラメータを変化させる処理、キャラクタのスキルを発動させる処理などの任意の処理であってよい。例えば、ゲーム実行部１００は、プログラムコードに記述された処理の実行結果に基づいて、後述する状況データを更新する。

本実施形態では、ゲーム実行部１００は、ゲームデータ取得部１０１、規則情報取得部１０２、乱数取得部１０３、データ記憶部１０４、更新部１０５、表示制御部１０６、第１判定部１０７、第１停止部１０８、第１再開部１０９、第２判定部１１０、第２停止部１１１、変更部１１２、ゲームデータ送信部１１３、ゲームデータ受信部１１４、及び第２再開部１１５を含む。

［ゲームデータ取得部］
ゲームデータ取得部１０１は、ゲームが開始される場合に、複数のユーザ情報の各々に関連付けられたゲームデータを取得する。例えば、ゲームデータは、後述するサーバ３０のデータ記憶部３００に記憶されているので、ゲームデータ取得部１０１は、データ記憶部３００からゲームデータを取得する。

なお、ゲームデータは、ゲーム端末１０のデータ記憶部１０４に記憶されていてもよく、この場合、ゲームデータ取得部１０１は、データ記憶部１０４からゲームデータを取得する。他にも例えば、ゲームデータは、ゲーム端末１０及びサーバ３０以外のコンピュータに記憶されていてもよく、この場合、ゲームデータ取得部１０１は、当該コンピュータからゲームデータを取得する。

ゲームが開始される場合とは、例えば、マッチングが完了した時点、又は、マッチングが完了した後の任意の時点であってよい。マッチングが完了するとは、例えば、対戦におけるユーザ情報の組み合わせが決定されること、当該ユーザ情報に関連付けられたゲームデータが決定されることである。なお、ここでのマッチングとは、例えば、ゲームに参加するユーザのユーザ情報（例えば、ユーザＩＤ）やゲームで用いられるゲームデータ（ここでは、チーム情報）の組み合わせを決めることである。例えば、マッチングは、あるユーザと対戦又は協力する他のユーザのユーザ情報や当該ユーザ情報に関連付けられたゲームデータを決めることである。

ユーザ情報とは、例えば、ユーザに関する情報である。例えば、ユーザ情報は、ユーザを一意に識別する情報である。例えば、ユーザＩＤ、ユーザ名などである。関連付けられたとは、例えば、一方から他方を検索可能とすることであり、データベース上で、あるデータと他のデータが紐付けられることである。

ゲームデータとは、例えば、ゲームの実行時に参照されるデータである。また例えば、ゲームデータは、ゲームの結果に影響するデータである。また例えば、ゲームデータは、ユーザ情報に関連付けられたデータである。また例えば、ゲームデータは、キャラクタ、カード、又はアイテムといったゲームオブジェクトである。また例えば、ゲームデータは、ゲームで用いられるゲームオブジェクトである。本実施形態では、カードがゲームオブジェクトに相当してもよいし、カードに描かれたキャラクタがゲームオブジェクトに相当してもよい。

また例えば、ゲームデータは、ユーザが使用するチームの戦術、フォーメーション、使用キャラクタといった情報である。また例えば、ゲームデータは、キャラクタの装備、能力パラメータ、スキルといった情報である。本実施形態では、チーム情報がゲームデータに相当する。このため、本実施形態でチーム情報と記載した箇所は、ゲームデータと読み替えることができる。

［規則情報取得部］
規則情報取得部１０２は、乱数発生規則に関する規則情報を取得する。乱数発生規則とは、例えば、乱数を発生させるための規則であり、関数、アルゴリズム、数式などである。例えば、乱数発生規則は、randといった乱数を発生させるための関数である。例えば、この関数は、乱数シードと呼ばれる値を元にして乱数を取り出す関数である。本実施形態では、乱数発生規則は、複数のゲーム実行部１００で共通なので、複数のゲーム実行部１００で共通の乱数列となるような規則といえる。

乱数とは、例えば、数字が不規則に表れるように配列されたものであり、疑似乱数又はソフトウェア乱数と呼ばれることもある。乱数シードとは、例えば、乱数を初期化するための値である。例えば、乱数シードは、乱数を発生させるための関数に入力する値である。また例えば、乱数シードは、乱数列のもととなる値であり、乱数シードの値が異なると、乱数発生規則により生成される乱数列も異なる。

乱数列は、例えば、乱数の組み合わせ全体のことである。複数の乱数が順番に並べられたものが乱数列である。例えば、ゲーム実行部１００は、乱数列の各乱数を順番に取得する。規則情報とは、例えば、乱数発生規則が乱数を発生させるために使用する情報である。例えば、規則情報は、乱数発生規則に入力される乱数シードである。本実施形態では、乱数シードが規則情報に相当する。このため、本実施形態で乱数シードと記載した箇所は、規則情報と読み替えることができる。

本実施形態では、規則情報取得部１０２は、後述するサーバ３０の規則情報送信部３０２により送信された規則情報を取得する。即ち、規則情報取得部１０２は、ゲーム実行部１００の外部において生成され、規則情報送信部３０２により送信された規則情報を取得する。なお、規則情報は、ゲーム実行部１００内部において生成されてもよい。この場合、規則情報送信部３０２は省略してもよい。また、規則情報は、ゲーム端末１０及びサーバ３０以外のコンピュータで生成されてもよく、この場合、規則情報取得部１０２は、当該コンピュータから規則情報を取得する。

［乱数取得部］
乱数取得部１０３は、複数のゲーム実行部１００で共通の乱数発生規則に基づいて発生される乱数を取得する。本実施形態では、乱数発生規則が共通であり、あるゲーム実行部１００の乱数発生規則と、他のゲーム実行部１００の乱数発生規則と、は同じである。このため、あるゲーム実行部１００の乱数取得部１０３が取得する乱数と、他のゲーム実行部１００の乱数取得部１０３が取得する乱数と、は同じとなる。

本実施形態では、乱数取得部１０３は、規則情報に基づいて乱数を発生させる。即ち、乱数取得部１０３は、ゲーム実行部１００の外部において生成された乱数を取得するのではなく、自身が乱数を発生させることになる。なお、ゲーム実行部１００の内部で乱数が生成される態様に限られず、乱数は、ゲーム実行部１００の外部において生成されてもよい。この場合は、乱数取得部１０３は、外部において生成された乱数を取得することになる。また、乱数は、ゲーム端末１０及びサーバ３０以外のコンピュータで生成されてもよく、この場合、乱数取得部１０３は、当該コンピュータから乱数を取得する。

本実施形態では、乱数取得部１０３は、状況データを更新するための複数の更新タイミングの各々が訪れるたびに、乱数発生規則に基づいて発生される乱数列から順番に乱数を取得する。例えば、乱数列は、複数の乱数の各々が順番に並んだものなので、乱数取得部１０３は、更新タイミングのたびに、乱数列から順番に乱数を取得することになる。即ち、乱数列にｎ個（ｎは２以上の整数）が順番に並べられているとすると、乱数取得部１０３は、１番目の乱数、２番目の乱数、３番目の乱数・・・といったように、ｎ番目まで順番に乱数を取得する。

更新タイミングとは、例えば、状況データを更新するために乱数が取得されるタイミングである。別の言い方をすれば、更新タイミングは、乱数に基づいて状況データを更新するタイミングであり、ゲームプログラムに記述された命令のうち、乱数を取得する命令が実行されるタイミングである。

乱数取得部１０３は、ゲームプログラムに記述された命令に基づいて、更新タイミングであるか否かを判定する。例えば、乱数取得部１０３は、当該命令が乱数を参照することを示している場合には更新タイミングであると判定し、特に当該命令が乱数を参照するものではない場合には更新タイミングではないと判定する。乱数取得部１０３は、更新タイミングであると判定された場合に、直近で取得した乱数の次の順番の乱数を取得する。

なお、定期的に乱数を取得するといった場合には、所定時間ごとに更新タイミングが設定されていてもよい。この場合、乱数取得部１０３は、一定時間が経過したか否かを判定する。乱数取得部１０３は、一定時間が経過したと判定された場合に、直近で取得した乱数の次の順番の乱数を取得してもよい。

［データ記憶部］
データ記憶部１０４は、ゲームを実行するために必要なデータを記憶する。ここでは、データ記憶部１０４が記憶するデータの一例として、ゲームの状況を示す状況データＤＴ１を説明する。

状況データＤＴ１とは、例えば、ゲームの現在の状況を示すデータである。例えば、状況データＤＴ１は、ゲーム空間の状況を示すデータを含む。また例えば、ゲーム空間には、１又は複数のゲームオブジェクトが配置される。また例えば、ゲーム空間は、仮想的な空間であり、３つの座標軸が関連付けられた仮想的な３次元空間であってもよいし、２つの座標軸が関連付けられた仮想的な２次元平面であってもよい。

また例えば、ゲーム空間の状況を示すデータは、ゲーム空間に配置されるゲームオブジェクトの状態を示すデータを含む。なお、サッカーゲーム、野球ゲーム、バスケットボールゲーム、又はアイスホッケーゲーム等のスポーツゲームの場合、選手キャラクタやボールがゲームオブジェクトに相当する。この場合、選手キャラクタの位置、向き、姿勢、移動方向、移動速度、現在行っている動作種類、ボールを保持しているか否か等を示すデータや、ボールの位置、移動方向、移動速度等を示すデータが、ゲームオブジェクトの状態を示すデータに相当する。

例えば、レースゲームの場合、レースカーがゲームオブジェクトに相当する。この場合、レースカーの位置、向き、移動方向、移動速度等を示すデータが、ゲームオブジェクトの状態を示すデータに相当する。また例えば、格闘ゲーム、アクションゲーム、又はロールプレイングゲームの場合、キャラクタがゲームオブジェクトに相当する。この場合、キャラクタの位置、向き、姿勢、移動方向、移動速度、現在行っている動作種類、ヒットポイント（ライフポイント）等を示すデータが、ゲームオブジェクトの状態を示すデータに相当する。

また例えば、カードゲームの場合、ゲームカードがゲームオブジェクトに相当する。この場合、ゲームカードの位置、向き等を示すデータが、ゲームオブジェクトの状態を示すデータに相当する。また例えば、状況データＤＴ１は、ゲームの進行状況を示すデータを含んでもよい。例えば、サッカーゲームの場合、試合が開始されてからの経過時間、試合が開始されてから現在までの途中経過、両チームの得点、アウトオブプレイの状態（コーナーキック、ペナルティキック、フリーキック、スローイング、又はゴールキック）であるか否か等を示すデータが、状況データＤＴ１に含まれてもよい。また例えば、野球ゲームの場合、現在のイニング、試合が開始されてから現在までの途中経過、両チームの得点等を示すデータが、状況データＤＴ１に含まれてもよい。

図１０は、状況データＤＴ１のデータ格納例を示す図である。本実施形態では、サッカーゲームを例に挙げるので、図１０に示すように、状況データＤＴ１には、各チームのキャラクタを一意に識別するキャラクタＩＤ（又はキャラクタが描かれたカードを一意に識別するカードＩＤ）、当該キャラクタの位置・移動方向・移動速度に関する情報、ボールの位置・移動方向・移動速度に関する情報、各チームの得点、試合の経過時間に関する時間情報、及び、リプレイ映像が流れた回数（後述する第１の処理の実行回数）といった情報が格納される。なお、状況データＤＴ１に含まれる情報は、上記の例に限られず、例えば、キャラクタやボールの３次元モデルの頂点座標等の情報が含まれていてもよい。

時間情報は、例えば、ゲーム内の世界での時間（仮想世界の時間）であり、リアルタイムクロックが示す時間ではない。例えば、時間情報は、スポーツゲームであれば、試合開始からの経過時間である。また例えば、時間情報は、ゲーム内の世界における仮想的な日時又は時刻であってもよい。先述したように、本実施形態では、状況データＤＴ１は、ゲーム開始後の操作部１４の検出信号に関係なく更新される。即ち、ゲーム開始後は、原則として、操作部１４の検出信号は、状況データＤＴ１の更新に影響しない。

なお、データ記憶部１０４に記憶されるデータは、上記の例に限られない。データ記憶部１０４は、ゲームに必要なデータを記憶すればよい。例えば、データ記憶部１０４は、ゲームデータ取得部１０１が取得したチーム情報を記憶してもよいし、マイページ画像Ｇ１等の種々の画像の画像データを記憶してもよい。

［更新部］
更新部１０５は、各ユーザ情報に関連付けられたチーム情報と乱数とに基づいて、複数のゲーム実行部１００で共通のゲーム処理を実行することによって、状況データＤＴ１を更新する。

共通のゲーム処理とは、例えば、共通のアルゴリズムが記述されたゲームプログラムによって実行される処理である。例えば、共通のゲーム処理は、複数の処理の各々が同じであり、各処理の実行順も同じとなる処理である。また例えば、共通のゲーム処理は、乱数の値が同じであれば結果も同じとなる処理である。

ゲーム処理は、任意の処理であってよく、例えば、ゲームオブジェクトの動作を決定する処理であってもよい。例えば、ゲーム処理は、キャラクタの移動方向、動作の種類、動作の強度を決定するための処理であってもよい。サッカーゲームであれば、ゲーム処理は、例えば、シュート、パス、フェイントといった動作を決定する処理である。野球ゲームであれば、ゲーム処理は、例えば、ヒッティング、バント、投球動作といった動作を決定する処理である。カードゲームであれば、例えば、使用するカードを決定したり、使用するスキルを決定したりする処理である。

乱数とゲーム処理との関係は、予めゲームプログラムに記述されているものとする。例えば、更新部１０５は、乱数取得部１０３が取得した乱数に関連付けられたゲーム処理を実行し、状況データＤＴ１を更新する。例えば、更新部１０５は、乱数に基づいて、キャラクタの移動方向、動作の種類、及び動作の強度の少なくとも１つを決定し、状況データＤＴ１を更新する。また例えば、更新部１０５は、乱数に基づいて、キャラクタやゲームカードのスキルを発動させ、状況データＤＴ１を更新する。また例えば、更新部１０５は、乱数に基づいて、キャラクタの動作の成否を決定し、状況データＤＴ１を更新する。

本実施形態では、更新部１０５は、各更新タイミングが訪れるたびに、乱数列から順番に取得された乱数に基づいて、状況データＤＴ１を更新する。更新部１０５は、状況データＤＴ１に基づいて更新タイミングが訪れたか否かを判定し、更新タイミングが訪れたと判定した場合に、乱数列から取得された乱数に基づいてゲーム処理を実行し、状況データＤＴ１を更新する。

［表示制御部］
表示制御部１０６は、状況データＤＴ１に基づいて、ゲームの状況を示すゲーム画像を表示部１５に表示させる。本実施形態では、対戦画像Ｇ６がゲーム画像に相当する。このため、本実施形態で対戦画像Ｇ６と記載した箇所は、ゲーム画像と読み替えることができる。例えば、表示制御部１０６は、状況データＤＴ１が示すゲーム空間の様子を対戦画像Ｇ６に表示させる。例えば、表示制御部１０６は、ゲーム空間に配置されたキャラクタやボールなどの３次元モデルの座標変換処理を実行し、対戦画像Ｇ６を表示させる。また例えば、表示制御部１０６は、状況データＤＴ１が示す戦況（例えば、各チームの得点や試合の経過時間）を対戦画像Ｇ６に表示させてもよい。

［第１判定部］
第１判定部１０７は、状況データＤＴ１に基づいて、ゲームが第１の状況になったか否かを判定する。第１の状況とは、例えば、予め定められた進行状況である。例えば、第１の状況は、所定の処理が実行された回数が閾値以上になることである。また例えば、第１の状況は、ゲーム開始からの経過時間が所定時間になることである。また例えば、第１の状況は、状況データＤＴ１の各項目の値が所定値を示すことである。また例えば、第１の状況は、リプレイが再生された回数が閾値以上になることである。

また例えば、スポーツの試合を模したゲームであれば、第１の状況は、試合が一時停止する状況が所定回数発生することである。また例えば、サッカーゲームであれば、第１の状況は、シュート本数が閾値以上になること、アニメーションの再生速度が速くなったり遅くなったりした回数が閾値以上になること、ボールがタッチラインを割ったり反則が発生したりしてアウトオブプレイになった回数が閾値以上になることなどである。

例えば、第１判定部１０７は、状況データＤＴ１に格納された第１の項目の値に基づいて、ゲームが第１の状況になったか否かを判定する。例えば、第１判定部１０７は、第１の項目の値が所定範囲になっていない場合は、ゲームが第１の状況になったとは判定せず、第１の項目の値が所定範囲になった場合は、ゲームが第１の状況になったと判定する。

本実施形態では、第１の状況は、ゲームにおいて、所定の処理が実行された回数が閾値以上になることである。所定の処理とは、例えば、処理完了までに時間がかかると予測される処理である。例えば、リプレイ映像を流す処理、試合を一時停止する処理、といった上記処理である。本実施形態では、リプレイ映像を流す処理が所定の処理に相当する。このため、状況データＤＴ１には、リプレイ映像が流された回数が格納されているものとする。

例えば、第１判定部１０７は、状況データＤＴ１に格納されたリプレイ映像の回数が所定回数以上であるか否かを判定する。第１判定部１０７は、リプレイ映像の回数が所定回数未満である場合はゲームが第１の状況になったとは判定せず、リプレイ映像の回数が所定回数以上である場合はゲームが第１の状況になったと判定する。なお、リプレイ映像の回数は、所定回数以上になった場合にいったん０回にリセットされてもよいし、特にリセットされなくてもよい。

［第１停止部］
第１停止部１０８は、ゲームが第１の状況になったと判定された場合に、他のゲーム実行部１００におけるゲームが第１の状況になるまで、状況データＤＴ１の更新を一時停止させる。

例えば、各ゲーム実行部１００は、当該ゲーム実行部１００の第１判定部１０７により、第１の状況になったと判定された場合に、サーバ３０に対して所定の通知を送信する。サーバ３０は、当該通知を受信すると当該通知を転送する。ゲーム実行部１００は、サーバ３０が転送した通知を受信することによって、他のゲーム実行部１００におけるゲームが第１の状況になったか否かを特定する。

他のゲーム実行部１００におけるゲームが第１の状況になるまでとは、例えば、他のゲーム実行部１００におけるゲームが第１の状況になったことを示す通知を受信した時点、又は、当該時点の後の任意の時点である。例えば、第１停止部１０８は、サーバ３０から当該通知を受信したか否かを判定することによって、他のゲーム実行部１００におけるゲームが第１の状況になったか否かを判定する。

例えば、第１停止部１０８は、ゲームが第１の状況になったと判定された場合に、状況データＤＴ１の更新を一時停止する。状況データＤＴ１の更新を一時停止するとは、例えば、ゲームの進行を一時停止することである。なお、第１停止部１０８により状況データＤＴ１の更新が一時停止されている間は、表示制御部１０６は、対戦画像Ｇ６の表示を更新しないようにしてもよいし、「しばらくお待ち下さい」といった所定のメッセージを表示させてもよい。また例えば、この間は、表示制御部１０６は、それまでのダイジェスト映像を流してもよいし、試合とは関係のない映像を流してもよい。例えば、第１停止部１０８は、サーバ３０から通知を受信したと判定しない場合は、状況データＤＴ１の更新の一時停止を継続する。

［第１再開部］
第１再開部１０９は、他のゲーム実行部１００におけるゲームが第１の状況になった場合に、状況データＤＴ１の更新を再開させる。例えば、第１再開部１０９は、他のゲーム実行部１００におけるゲームが第１の状況になったことを示す通知を受信した場合に、状況データＤＴ１の更新を再開させる。状況データＤＴ１の更新を再開させるとは、例えば、ゲームの進行の一時停止を解除して再開することである。状況データＤＴ１の更新が再開されると、表示制御部１０６は、対戦画像Ｇ６の表示の更新を再開する。

［第２判定部］
第２判定部１１０は、状況データＤＴ１に基づいて、ゲームが第２の状況になったか否かを判定する。第２の状況とは、例えば、第１の状況とは異なる状況である。例えば、第２の状況は、休憩や選手交代などの目的で定められた期間が訪れることである。また例えば、第２の状況は、サッカーゲームにおけるハーフタイムであってもよいし、野球ゲームにおけるイニングの合間であってもよい。また例えば、ゲームデータの変更を許可する状況として定められた状況である。

例えば、第２判定部１１０は、状況データＤＴ１に格納された第２の項目の値に基づいて、ゲームが第２の状況になったか否かを判定する。例えば、第２判定部１１０は、第２の項目の値が所定範囲になっていない場合は、ゲームが第２の状況になったとは判定せず、第２の項目の値が所定範囲になった場合は、ゲームが第２の状況になったと判定する。

本実施形態では、第２判定部１１０は、状況データＤＴ１が示す試合の経過時間が所定時間になったか否かを判定する。例えば、第２判定部１１０は、状況データＤＴ１が示す試合の経過時間に基づいて、試合の前半（例えば、仮想世界内での４５分）が終了してハーフタイムが訪れたいか否かを判定する。このため、本実施形態では、試合の前半が終了してハーフタイムが訪れることが第２の状況になることに相当する。

［第２停止部］
第２停止部１１１は、ゲームが第２の状況になったと判定された場合に、状況データＤＴ１の更新を一時停止させる。例えば、第２停止部１１１は、ゲームが第２の状況になったと判定された場合に、状況データＤＴ１の更新を一時停止する。第２停止部１１１により状況データＤＴ１の更新が一時停止されている間は、表示制御部１０６は、チーム情報の変更を受け付けるための画像を表示部１５に表示させ、当該画像に対する操作に基づいて、後述する変更部１１２がチーム情報を変更してもよい。

［変更部］
本実施形態では、チーム情報がゲームデータに相当するので、変更部１１２は、状況データＤＴ１の更新が一時停止された場合に、各ゲーム実行部１００のうちの１又は複数のゲーム実行部１００に対応するユーザ情報に関連付けられたチーム情報を変更する。例えば、変更部１１２は、操作部１４の検出信号に基づいて、チーム情報を変更する。

例えば、変更部１１２は、操作部１４の検出信号に基づいて、戦術、フォーメーション、使用するキャラクタといったチーム情報を変更する。例えば、変更部１１２は、戦術・フォーメーションは、予め定められた複数種類の戦術・フォーメーションのうち、指定された戦術・フォーメーションとなるように変更する。また例えば、変更部１１２は、所有するキャラクタ（カード）のうち、指定されたキャラクタ（カード）が使用されるように変更する。

［ゲームデータ送信部］
本実施形態では、チーム情報がゲームデータに相当するので、ゲームデータ送信部１１３は、変更部１１２により変更されたチーム情報を他のゲーム実行部１００に送信する。例えば、ゲームデータ送信部１１３は、変更部１１２により変更されたチーム情報をサーバ３０に送信する。サーバ３０は、当該チーム情報を転送する。各ゲーム実行部１００の後述するゲームデータ受信部１１４は、他のゲーム実行部１００の変更部１１２により変更されたチーム情報を受信する。即ち、各ゲーム実行部１００の変更により変更されたチーム情報が共有される。なお、Ｐ２Ｐ通信が利用される場合には、サーバ３０を介するのではなく、ゲームデータ送信部１１３は、他のゲーム実行部１００に対して直接的にチーム情報を送信してもよい。

［ゲームデータ受信部］
本実施形態では、チーム情報がゲームデータに相当するので、ゲームデータ受信部１１４は、他のゲーム実行部１００の変更部１１２により変更されたチーム情報を受信する。例えば、各ゲーム実行部１００のゲームデータ受信部１１４は、他のゲーム実行部１００のゲームデータ送信部１１３により送信されたチーム情報を、サーバ３０を介して受信する。なお、Ｐ２Ｐ通信が利用される場合には、サーバ３０を介するのではなく、ゲームデータ受信部１１４は、他のゲーム実行部１００から直接的にチーム情報を受信してもよい。

［第２再開部］
本実施形態では、チーム情報がゲームデータに相当するので、第２再開部１１５は、自身の変更部１１２により変更されたチーム情報と、他のゲーム実行部１００の変更部１１２により変更されたチーム情報と、に基づいて、状況データＤＴ１の更新を再開させる。例えば、第２再開部は、チーム情報を更新したうえで、状況データＤＴ１の更新を再開させることになる。また例えば、第２再開部１１５は、ゲームデータ受信部１１４がチーム情報を受信した場合に、状況データＤＴ１の更新を再開させる。状況データＤＴ１の更新が再開されると、表示制御部１０６は、再び対戦画像Ｇ６を表示させて対戦を再開させる。

［１−３−２．サーバで実現される機能］
サーバ３０では、データ記憶部３００、規則情報生成部３０１、及び規則情報送信部３０２が実現される。本実施形態では、これら各機能がゲームサーバ３０Ｄによって実現される場合を説明するが、ゲームシステムＳ内の任意のサーバで実現されるようにすればよい。

［データ記憶部］
データ記憶部３００は、記憶部３２Ｄを主として実現される。データ記憶部３００は、ゲームを実行するために必要なデータを記憶する。ここでは、データ記憶部３００が記憶するデータの一例として、ユーザデータＤＴ２を説明する。

図１１は、ユーザデータＤＴ２のデータ格納例を示す図である。図１１に示すように、ユーザデータＤＴ２は、ユーザ情報（例えば、ユーザＩＤ）に関連付けて、ユーザ名、及びチーム情報などが格納される。チーム情報としては、例えば、チームのフォーメーション、作戦、キャラクタを一意に識別するキャラクタＩＤ、キャラクタの名前、能力パラメータ、及びスキルといった情報が格納される。

なお、データ記憶部３００に記憶されるデータは、上記の例に限られない。データ記憶部３００は、ゲームに必要なデータを記憶すればよい。例えば、データ記憶部３００には、乱数シードを生成するための関数などが記憶されていてもよい。

［規則情報生成部］
規則情報生成部３０１は、制御部３１Ｄを主として実現される。規則情報生成部３０１は、マッチングが実行された場合に、時間情報に基づいて規則情報を生成する。マッチングが実行された場合とは、例えば、マッチングが完了した時点、又は、当該時点よりも後の任意の時点である。時間情報とは、例えば、日時であってもよいし、日付を含まない時刻であってもよい。なお、ここでの時間情報は、状況データＤＴ１に含まれる仮想世界の時間情報ではなく、リアルタイムクロック等によって取得される現実世界の時間情報である。

本実施形態では、乱数シードが規則情報に相当するので、規則情報生成部３０１は、時間情報に基づいて乱数シードを生成することになる。乱数シードの生成方法自体は、公知の種々の手法を適用可能であり、例えば、時間情報が示す数値を所定の数式に代入することによって乱数シードを取得してもよいし、時間情報が示す数値をそのまま乱数シードの値をしてもよい。

［規則情報送信部］
規則情報送信部３０２は、制御部３１Ｄを主として実現される。規則情報送信部３０２は、各ゲーム実行部１００に対し、規則情報を送信する。本実施形態では、乱数シードが規則情報に相当するので、規則情報送信部３０２は、マッチング結果に基づいて送信相手のゲーム実行部１００を特定し、当該特定したゲーム実行部１００に対し、規則情報生成部３０１が生成した乱数シードを送信することになる。

［１−４．ゲームシステムにおいて実行される処理］
図１２−図１４は、ゲームシステムＳにおいて実行される処理の一例を示すフロー図である。図１２−図１４に示す処理は、制御部１１が記憶部１２に記憶されたプログラムに従って動作し、制御部３１が記憶部３２に記憶されたプログラムに従って動作することによって実行される。以降説明する処理は、機能ブロックが実行する処理の一例である。

なお、ゲーム端末１０は、任意の通信プロトコルを利用してよいが、ここでは、ＴＣＰ／ＩＰを利用する場合を説明する。ゲーム端末１０のＩＰアドレスについては、プロバイダ等によって決められた値なので任意の値を利用できないが、ポート番号については、ゲーム端末１０内の他のプログラムが使用していなければ、任意の値を利用してもよい。なお、所定のポート番号（例えば、１〜４９１５１など）が他のプログラムで利用されている可能性が高い場合には、これらの範囲は避けてもよい。

図１２に示すように、まず、ゲーム端末１０においてゲームプログラムが起動すると、制御部１１は、ゲートサーバ３０Ａとの接続処理を行い、サーバリストを要求する（Ｓ１０１）。ゲームプログラムには、ゲートサーバ３０ＡのＩＰアドレスと、ゲームシステムＳで利用される共通鍵と、が予め記憶されているものとする。ここでは、ゲームプログラムからサーバ３０に対する通信が行われる場合には、例えばハッカーによるチートを防止するために、当該共通鍵で暗号化されたデータを使用して通信が行われる。なお、ゲートサーバ３０Ａに対する通信も共通鍵が用いられてもよいが、ゲートサーバ３０Ａは、データを復号化する時間がないほどアクセス数が多いため、セキュリティよりも速度を優先させるために、ゲートサーバ３０に対する通信は共通鍵が用いられないようにしてもよい。また例えば、ゲームプログラムは、ゲートサーバ３０ＡのＩＰアドレスと、上記予め定められたポート番号のポート（例えば、６６０００）と、を利用してＴＣＰ／ＩＰによってゲートサーバ３０Ａに接続する。その後、ゲームプログラムは、ゲートサーバ３０Ａに対し、サーバリストを要求する。

ゲートサーバ３０Ａにおいては、要求を受信すると、制御部３１Ａは、ゲーム端末１０に対し、サーバリストを送信する（Ｓ３０１）。Ｓ３０１においては、記憶部３２Ａに、現在稼働中のサーバの種類とＩＰアドレスとの組み合わせを示すサーバリストが記憶されており、制御部３１Ａは、当該サーバリストを送信することになる。

ゲーム端末１０においては、サーバリストを受信すると、ゲートサーバ３０Ａとの接続を切断し、制御部１１は、受信したサーバリストに基づいて、認証サーバ３０Ｂとの接続処理を行い、ユーザ認証の実行を要求する（Ｓ１０３）。先述したように、サーバリストには、現在稼働中のサーバが記載されており、認証サーバ３０Ｂもサーバリストに含まれている。ユーザ認証は、任意の認証方法を利用すればよく、例えば、公開鍵と秘密鍵を利用してワンタイムの共通鍵暗号をやり取りすることで実行されてもよい。

認証サーバ３０Ｂにおいては、要求を受信すると、制御部３１Ｂは、ユーザ認証を実行する（Ｓ３０３）。Ｓ３０３においては、先述したように、任意の認証方法を利用可能であり、例えば、公開鍵と秘密鍵を利用した認証が実行されるようにしてもよい。

ユーザ認証に失敗した場合（Ｓ３０３；失敗）、ゲーム端末１０に対し、所定のエラーメッセージが送信されて本処理は終了する。一方、ユーザ認証に成功した場合（Ｓ３０３；成功）、制御部３１Ｂは、ユーザトークンを発行してゲーム端末１０に送信する（Ｓ３０５）。ユーザトークンは、例えば、所定ビットのバイナリデータである。以降やり取りされるデータには、原則としてユーザトークンが添付される。

なお、以降の処理において、ロビーサーバ３０Ｃやゲームサーバ３０Ｄからトークンエラーが受信された場合には、ユーザ認証を実行しなおしてユーザトークンが更新されてもよい。再度のユーザ認証が実行される場合には、ゲートサーバ３０Ａから受信したサーバリストが利用されるようにすればよい。なお、サーバリストに記載されたサーバ３０に接続しても、正しいユーザトークンを取得できない場合には、再度ゲートサーバ３０Ａに接続してリストの更新が行われてもよい。その後、先述した手順と同様にして、ユーザ認証が実行される。

ゲーム端末１０においては、ユーザトークンを受信すると、制御部１１は、受信したユーザトークンを保持する（Ｓ１０５）。以降、マイページ画像Ｇ１等が表示される状態となるが、ここでは、個別対戦画像Ｇ３のボタンＢ３２，Ｂ３３が選択された場合の処理を説明する。制御部１１は、ゲートサーバ３０Ａから受信したリストに基づいて、ロビーサーバ３０Ｃとの接続処理を実行する（Ｓ１０７）。

制御部１１は、チーム情報画像Ｇ４を表示部１５に表示させ、操作部１４の検出信号に基づいて、試合を開始するためのボタンＢ４３が選択されたか否かを判定する（Ｓ１０９）。ボタンＢ４３が選択されたと判定された場合（Ｓ１０９；Ｙ）、制御部１１は、ロビーサーバ３０Ｃに対し、マッチングの要求を送信する（Ｓ１１１）。

ロビーサーバ３０Ｃにおいては、要求を受信すると、制御部３１Ｃは、マッチングを実行する（Ｓ３０７）。記憶部３２Ｃには、ロビーサーバ３０Ｃに接続したゲームプログラムに対応するユーザ情報が予め記憶されており、制御部３１Ｃは、当該ユーザ情報に基づいてマッチングを実行する。制御部３１Ｃは、マッチングが完了すると、ゲーム端末１０に対し、マッチングが完了した旨の通知を送信する（Ｓ３０９）。なお、ロビーサーバ３０Ｃは、ゲームサーバ３０Ｄにマッチング結果を送信してもよいし、ゲーム端末１０経由でマッチング結果がゲームサーバ３０Ｄに送信されてもよい。マッチング結果は、例えば、マッチングされたユーザ情報やチーム情報などを含んでいてもよい。

図１３に移り、ゲーム端末１０においては、通知を受信すると、制御部１１は、ゲームサーバ３０Ｄとの接続処理を実行する（Ｓ１１３）。なお、ゲームサーバ３０Ｄとの接続処理に失敗した場合には、マッチング前の画面に戻り、再びロビーサーバ３０Ｃと接続してもよい。戻る先のロビーサーバ３０Ｃがない場合には、タイトル画像やマイページ画像Ｇ１等に戻ってもよい。ゲームサーバ３０Ｄとの接続処理が成功した場合は、以降の処理が実行される。

ゲームサーバ３０Ｄにおいては、ゲーム端末１０と接続すると、制御部３１Ｄは、現在の時間情報に基づいて、乱数シードを生成する（Ｓ３１１）。Ｓ３１１においては、制御部３１Ｄは、リアルタイムクロック等を利用して時間情報を取得し、時間情報を所定の数式に代入することによって乱数シードを生成する。

制御部３１Ｄは、ゲーム端末１０に対し、ユーザデータＤＴ２に格納されたチーム情報と、Ｓ３１１で生成した乱数シードと、を送信する（Ｓ３１３）。なお、ゲーム端末１０のゲームプログラムが、ゲームサーバ３０Ｄのプロセスにデータを送信する場合には、データにユーザトークンが付与される。例えば、ゲーム端末１０ＡのゲームプログラムＡが、ゲームサーバ３０Ｄのプロセスにデータを送信する場合には、データにユーザトークンＵＴＫ−Ａが付与されて暗号化されたものが送信される。また例えば、ゲーム端末１０ＢのゲームプログラムＢが、ゲームサーバ３０Ｄのプロセスにデータを送信する場合には、データにユーザトークンＵＴＫ−Ｂが付与されて暗号化されたものが送信される。

逆に、ゲームサーバ３０Ｄのプロセスから各ゲーム端末１０のゲームプログラムにデータが送信される場合には、ユーザトークンは付与されない。例えば、ゲームサーバ３０Ｄがゲーム端末１０ＡのゲームプログラムＡに送信するデータは、ゲームプログラムＡ用のデータになっており、ゲームサーバ３０Ｄがゲーム端末１０ＢのゲームプログラムＢに送信するデータは、ゲームプログラムＢ用のデータになっている。なお、セキュリティ向上などの目的で、ゲームサーバ３０Ｄのプロセスから各ゲーム端末１０のゲームプログラムに送信されるデータにユーザトークンが付与されてもよい。

以降説明する処理は、マッチングされた各ゲーム端末１０において実行される。ゲーム端末１０は、チーム情報と乱数シードを受信すると、制御部１１は、個別対戦を開始する（Ｓ１１５）。Ｓ１１５においては、状況データＤＴ１が記憶部１２に記憶され、ゲームプログラムに記述されたプログラムコードが実行される。例えば、制御部１１は、予め定められたアルゴリズムに基づいて、ゲーム空間におけるキャラクタの動作を決定する。

制御部１１は、状況データＤＴ１の更新タイミングが訪れたか否かを判定する（Ｓ１１７）。Ｓ１１７においては、制御部１１は、ゲームプログラムに記述されたプログラムコードが乱数を参照することを示しているか否かを判定する。更新タイミングが訪れたと判定された場合（Ｓ１１７；Ｙ）、制御部１１は、乱数シードに基づく乱数列から乱数を取得し（Ｓ１１９）、乱数に基づいて状況データＤＴ１を更新する（Ｓ１２１）。Ｓ１１９においては、制御部１１は、乱数列のうち所定の順番の乱数を取得し、Ｓ１２１においては、乱数に基づいてキャラクタの動作を決定して状況データＤＴ１を更新する。

制御部１１は、状況データＤＴ１に基づいて、アプトオブプレイとなったか否かを判定する（Ｓ１２３）。アプトオブプレイとは、試合の進行が一時停止する状況であり、例えば、ボールがタッチラインを割った場合、ゴールが決まった場合、及び反則が発生した場合等にアプトオブプレイとなる。Ｓ１２３においては、制御部１１は、状況データＤＴ１に格納されたボールの位置に基づいて、ボールがタッチラインを割ったか否かを判定したり、ゴールが決まったか否かを判定したりする。また例えば、制御部１１は、状況データＤＴ１に格納されたキャラクタの位置に基づいて、反則が発生したか否かを判定する。

アプトオブプレイとなったと判定された場合（Ｓ１２３；Ｙ）、制御部１１は、リプレイ映像を表示部１５に表示させ（Ｓ１２５）、状況データＤＴ１に格納されたリプレイ映像の再生回数を増加させる（Ｓ１２７）。例えば、状況データＤＴ１の履歴を記憶部１２に記憶させておき、Ｓ１２５においては、制御部１１は、状況データＤＴ１履歴に基づいてリプレイ映像を生成して表示部１５に表示させる。

図１４に移り、制御部１１は、状況データＤＴ１に基づいて、リプレイ映像の再生回数が閾値以上になったか否かを判定する（Ｓ１２９）。閾値は、予め定められた値であればよく、記憶部１２に記憶されているものとする。リプレイ映像の再生回数が閾値以上になったと判定された場合（Ｓ１２９；Ｙ）、制御部１１は、状況データＤＴ１の更新を一時停止させ（Ｓ１３１）、ゲームサーバ３０Ｄに対し、状況データＤＴ１の更新を一時停止した旨の通知を送信する（Ｓ１３３）。以降、制御部１１は、ゲームに関係のない映像を表示部１５に表示させ、他のゲーム端末１０におけるゲームの進行が追いつくまで（後述するＳ１３５の処理が実行されるまで）待機する。

ゲームサーバ３０Ｄにおいては、通知を受信すると、制御部３１Ｄは、他のゲーム端末１０から同様の通知を受信したか否かを判定する（Ｓ３１５）。Ｓ３１５においては、マッチングにより対戦中の全てのゲーム端末１０からリプレイ映像の再生回数が閾値以上になり、進行を一時停止する旨の通知を受信したか否かを判定することになる。

他のゲーム端末１０から通知を受信したと判定されない場合（Ｓ３１５；Ｎ）、再びＳ３１５に戻る。一方、他のゲーム端末１０から通知を受信したと判定された場合（Ｓ３１５；Ｙ）、制御部３１Ｄは、各ゲーム端末１０に対し、ゲームを再開させるための再開要求を送信する（Ｓ３１７）。再開要求は、所定のデータ形式で行われるようにすればよい。

ゲーム端末１０においては、再開要求を受信すると、制御部１１は、状況データＤＴ１の更新を再開させ（Ｓ１３５）、Ｓ１１７に戻る。この場合、ゲームが一時停止された時点の続きから試合が再開することになる。

一方、Ｓ１２９において、再生回数が閾値以上になったと判定されない場合（Ｓ１２９；Ｎ）、制御部１１は、状況データＤＴ１に基づいて、前半終了又は試合終了したか否かを判定する（Ｓ１３７）。Ｓ１３７においては、制御部１１は、状況データＤＴ１に格納された時間情報が所定の時間を示したか否かを判定する。例えば、制御部１１は、時間情報が４５分を示していれば前半終了と判定し、時間情報が９０分を示していれば試合終了と判定する。

前半が終了したと判定された場合（Ｓ１３７；前半終了）、制御部１１は、操作部１４の検出信号に基づいて、チーム情報を変更してゲームサーバ３０Ｄに送信する（Ｓ１３９）。Ｓ１３９においては、制御部１１は、操作部１４の検出信号に基づいて、作戦、フォーメーション、使用するキャラクタ（カード）といったチーム情報を変更し、変更後のチーム情報をゲームサーバ３０Ｄに送信する。

ゲームサーバ３０Ｄにおいては、変更後のチーム情報を受信すると、制御部３１Ｄは、当該チーム情報を保持する（Ｓ３１９）。制御部３１Ｄは、試合の後半を再開させるか否かを判定する（Ｓ３２１）。Ｓ３２１においては、各ゲーム端末１０からチーム情報を受信したか否かを判定する。試合の後半を再開させると判定された場合（Ｓ３２１；Ｙ）、制御部３１Ｄは、各ゲーム端末１０に対し、変更後のチーム情報を送信する（Ｓ３２３）。

ゲーム端末１０においては、変更後のチーム情報を受信すると、制御部１１は、変更後のチーム情報に基づいて、後半を再開させ（Ｓ１４１）、Ｓ１１７の処理に戻る。一方、Ｓ１３７において、試合が終了したと判定された場合（Ｓ１３７；試合終了）、本処理は終了する。

以上説明したゲームシステムＳによれば、ゲームが開始される場合に取得されたチーム情報と、複数のゲーム実行部１００で共通の乱数発生規則に基づいて発生される乱数と、に基づいて、複数のゲーム実行部１００で共通のゲーム処理を実行することによって状況データＤＴ１が更新され、状況データＤＴ１の整合を取らなくても状況データＤＴ１が同じ内容になるので、通信負荷を軽減することができる。また、ゲームで使用されるチーム情報の組み合わせが同じだった場合、乱数を使用しなかったとすると毎回同じゲーム結果となってしまい、ユーザが飽きてしまう可能性があるが、乱数を使用してランダム要素を入れることで、チーム情報の組み合わせが同じだったとしてもゲーム結果に変化をつけることができる。また、通信障害やアプリケーション終了等の理由により、一部のゲーム実行部１００でゲームが途中終了したとしても、各ゲーム実行部１００が状況データＤＴ１を更新するので、他のゲーム実行部１００はゲームを最後まで実行することができる。

また、各ゲーム実行部１００が、ゲームが開始される場合に、複数のゲーム実行部１００で共通の乱数発生規則に関する規則情報に基づいて乱数を発生させることで、複数のゲーム実行部１００で共通の乱数とし、状況データＤＴ１を整合しなくても、他のゲーム実行部１００と同じ内容の状況データＤＴ１を取得させることができる。また、各ゲーム実行部１００が、サーバコンピュータなどから乱数のリストを取得する場合には、一応は同じ乱数を使って状況データＤＴ１を更新することができるが、乱数のリストを送信する分の通信負荷が発生する。この点、ゲームシステムＳは、各ゲーム実行部１００が、規則情報を使って自分で乱数を発生させることで、乱数のリストを送信する必要がなくなるので、通信負荷を効果的に軽減することができる。

また、マッチングが実行された場合に、時間情報に基づいて規則情報を生成することで、マッチングのたびに異なる規則情報を生成し、各ゲーム実行部１００に取得させる乱数を異ならせることができるので、ゲームの結果が毎回同じになりゲームの興趣性が低下するといったことを確実に防止することができる。

また、乱数シードを用いることで、複数のゲーム実行部１００で共通の乱数を確実に発生させ、状況データＤＴ１を整合しなくても、他のゲーム実行部１００と同じ内容の状況データＤＴ１を取得させることができる。

また、複数の更新タイミングの各々が訪れるたびに、乱数発生規則に基づいて発生される乱数列から順番に取得された乱数に基づいて状況データＤＴ１を更新することにより、乱数が状況データＤＴ１に複数回影響してランダム要素が高まるので、ゲームの興趣性を効果的に高めることができる。

また、リプレイ映像の再生回数が閾値以上になった場合に、他のゲーム実行部１００におけるゲームが同様の状況になるまでは状況データＤＴ１の更新を一時停止し、他のゲーム実行部１００におけるゲームが同様の状況になった場合に状況データＤＴ１の更新を再開することによって、ゲーム実行部１００間でゲームの進行を合わせることができる。ゲームの進行を合わせることで、例えば、ゲームの終了時点を合わせることができたり、ゲーム実行中のチャット時に話が噛みあわないといったことを防止したりすることができる。

また、リプレイ映像の再生回数のような所定の処理が実行された回数が閾値以上になった場合に、状況データＤＴ１の更新を一時停止して、ゲーム実行部１００間でゲームの進行を合わせることで、より確実にゲームの進行を合わせることができる。例えば、所定の処理として、進行がずれそうな処理（端末の性能によって処理時間に差が出そうな処理）を定めておくことで、ゲームの進行が大幅にずれるといったことを防止することができる。また例えば、閾値を２以上に設定しておく場合には、所定の処理が発生したとしても、その回数が閾値以上になるまでは状況データＤＴ１の更新が一時停止しないので、所定の処理が発生するたびにゲームが一時停止するといったことを防止でき、ゲームの進行をスムーズにすることができる。

また、ハーフタイムにおいてチーム情報の変更を許可することで、ゲーム終了まで全く介入できないのではなく、ゲームの途中でチーム情報の変更をさせることで、ゲームの興趣性を効果的に高めることができる。

［２．実施形態２］
次に、ゲームシステムＳの別実施形態を説明する。以降説明する実施形態２では、実施形態１で説明したゲームと同様のゲームが実行される場合を説明するが、実施形態２のゲームは、実施形態１のゲームとは異なってもよい。なお、実施形態１では個別対戦について説明したが、実施形態２ではグループ対戦について説明する。

先述したように、グループ対戦では、複数人の対戦が実行される。例えば、グループ対戦は、複数人対コンピュータの対戦であってもよいし、複数人対複数人の対戦であってもよい。グループ対戦におけるマッチングについては、後述する実施形態３で説明し、実施形態２では、グループ対戦中に行われるチャットについて説明する。なお、以降説明するチャットは、個別対戦において行われてもよい。個別対戦と同様に、グループ対戦が開始すると対戦画像Ｇ６が表示部１５に表示される。

図１５は、グループ対戦における対戦画像Ｇ６の一例を示す図である。図１５に示すように、対戦画像Ｇ６には、チャットにおけるメッセージを入力するためのボタンＢ６２が表示される。ボタンＢ６２が選択されると、メッセージを入力するためのウィンドウが対戦画像Ｇ６に表示される。

図１６は、対戦画像Ｇ６にウィンドウが表示される様子を示す図である。本実施形態では、スタンプと呼ばれる画像を利用してメッセージを入力することができ、図１６に示すように、ウィンドウＷ６３には、スタンプの一覧が表示される。スタンプは、例えば、キャラクタの顔やサッカーボールなどのイラストと、発言内容を示す文字列と、を含んでもよい。ウィンドウＷ６３に表示されたスタンプの何れかが選択されると、当該選択されたスタンプがメッセージとして入力され、対戦画像Ｇ６に表示される。

図１７は、対戦画像Ｇ６にメッセージが表示される様子を示す図である。図１７に示すように、対戦画像Ｇ６には、メッセージＭ６４が表示される。なお、メッセージＭ６４は、入力者を示す文字列が表示されてもよい。図１７の例では、「Ａ」というユーザにより「ゴール！」というメッセージが入力された場合を示している。

実施形態１と同様に、実施形態２のゲームシステムＳでは、ゲーム端末１０間で操作信号を送り合ったり、更新後のデータを送り合ったりすることなく、各ゲーム端末１０で個別にデータの更新が実行されるものとする。このため、ゲーム端末１０間でゲーム進行にずれが生じることがあり、メッセージをすぐに表示させない方がよいことがある。

例えば、ゲーム端末１０Ａの方が、ゲーム端末１０Ｂよりも高性能の場合、ゲーム端末１０Ａのゲーム進行が、ゲーム端末１０Ｂよりも早くなることがある。この場合、ゲーム端末１０Ａに入力されたメッセージを、すぐにゲーム端末１０Ｂに出力させてしまうと、メッセージの内容から今後のゲーム展開を予想することができてしまうので、ゲームの興趣性が低下してしまう。

図１８は、各ゲーム端末１０のゲームプログラムで実行されるゲームの進行を示す図である。図１８の例では、ゲーム端末１０Ａの方が、ゲーム端末１０Ｂよりも高性能とする。このため、ゲーム端末１０ＡのゲームプログラムＡと、ゲーム端末１０ＢのゲームプログラムＢと、の各々が同時に試合を開始したとしても、ゲームプログラムＡが実行するグループ対戦の方が、進行が早い。

例えば、前半２５分にゴールが決まったとすると、ゴールシーンが発生するのは、ゲームプログラムＡの方がゲームプログラムＢよりも早い。ゴールが決まった場合にゲーム端末１０Ａに入力されたメッセージを、ゲーム端末１０Ｂにすぐに表示させてしまうと、ゲーム端末１０Ｂでは、ゴールシーンになっていないにも関わらず、メッセージが表示されてしまうので、ゴールが決まったことを予想できてしまい、興ざめしてしまう可能性がある。

このため、本実施形態では、ゲームプログラムＢが実行するゲームが前半２５分になってゴールシーンが発生するまでは、メッセージの表示を待機するようにしている。一方、前半４０分に反則が発生し、ゲーム端末１０Ｂにメッセージが入力されたとすると、ゲームプログラムＡの方がゲームプログラムＢよりも進行が早いため、当該メッセージは、特に表示を待機することなく、ゲーム端末１０Ａにすぐに表示させるようになっている。

以上のように、実施形態２のゲームシステムＳでは、各ゲーム端末１０におけるゲームの進行状況が、他のゲーム端末１０におけるゲームの進行状況になるまで、メッセージの出力を制限することによって、メッセージの内容から今後のゲーム展開を予想するといったことを防止するようにしている。以降、実施形態２の詳細を説明する。なお、以降の説明では、実施形態１と同様の構成については説明を省略する。

［２−１．実施形態２で実現される機能］
図１９は、ゲームシステムＳで実現される機能のうち、本発明に関連する機能を示す機能ブロック図である。ここでは、ゲーム端末１０で実現される機能について説明する。なお、サーバ３０においては、実施形態１と同様、データ記憶部３００、規則情報生成部３０１、及び規則情報送信部３０２が実現されてもよい。

実施形態２のゲームシステムＳでは、実施形態１と同様、複数のゲーム実行部１００が実現されるが、図１９では、図面の簡略化のために、ゲーム実行部１００を１つだけ示す。なお、ゲーム実行部１００が実行する処理は、実施形態１と一部は共通するが、実施形態１では説明しなかった処理も含む。図１９に示すように、実施形態２のゲーム実行部１００は、ゲームデータ取得部１０１、乱数取得部１０３、データ記憶部１０４、更新部１０５、表示制御部１０６、メッセージ受信部１１６、制限部１１７、及び出力部１１８を含む。

［ゲームデータ取得部］
ゲームデータ取得部１０１は、ゲームが開始される場合に、複数のユーザ情報の各々に関連付けられたゲームデータを取得する。ゲームデータ取得部１０１の処理の詳細は、実施形態１と同様のため、説明を省略する。実施形態１と同様、実施形態２では、チーム情報がゲームデータに相当する。このため、ゲームデータ取得部１０１は、チーム情報を取得することになる。

［乱数取得部］
乱数取得部１０３は、複数のゲーム実行部１００で共通の乱数発生規則に基づいて発生される乱数を取得する。乱数取得部１０３の処理の詳細は、実施形態１と同様のため、説明を省略する。

［データ記憶部］
データ記憶部１０４は、ゲームの状況を示す状況データＤＴ１を記憶する。状況データＤＴ１は、実施形態１と同様のため、説明を省略する。

［更新部］
更新部１０５は、複数のゲーム実行部１００で共通のゲーム処理を実行することによって、状況データＤＴ１を更新する。共通のゲーム処理とは、例えば、共通のアルゴリズムが記述されたゲームプログラムによって実行される処理である。また例えば、共通のゲーム処理は、複数の処理の各々が同じであり、各処理の実行順も同じとなる処理である。また例えば、共通のゲーム処理は、乱数の値が同じであれば結果も同じとなる処理である。

なお、更新部１０５の処理の詳細は、実施形態１と同様であってもよい。例えば、更新部１０５は、各ユーザ情報に関連付けられたチーム情報と乱数とに基づいて、ゲーム処理を実行することによって、状況データＤＴ１を更新する。状況データＤＴ１の更新方法は、実施形態１で説明した通りである。

［表示制御部］
表示制御部１０６は、状況データＤＴ１に基づいて、ゲーム画像を表示部１５に表示させる。実施形態１と同様、実施形態２では、対戦画像Ｇ６がゲーム画像に相当する。表示制御部１０６の処理の詳細は、実施形態１と同様のため、説明を省略する。

［メッセージ受信部］
メッセージ受信部１１６は、他のゲーム実行部１００において入力されたメッセージを受信する。例えば、各ゲーム実行部１００は、メッセージが入力されると、当該メッセージをサーバ３０に送信する。サーバ３０は、当該メッセージを他のゲーム実行部１００に転送する。各ゲーム実行部１００のメッセージ受信部１１６は、他のゲーム実行部１００において入力され、サーバ３０により転送されたメッセージを受信する。なお、各ゲーム実行部１００は、サーバ３０を介するのではなく、Ｐ２Ｐ通信などを利用して、他のゲーム実行部１００に対してメッセージを直接送信してもよい。

メッセージとは、ユーザ間で伝達される情報の内容であり、例えば、各ユーザが入力した記号列や指定した画像により構成されてもよいし、音声によって伝達されてもよい。ここでの記号列とは、文字列（テキスト）を含む意味である。画像としては、例えば、スタンプと呼ばれるイラストの画像であってもよい。

本実施形態では、メッセージ受信部１１６は、メッセージが入力された場合の他のゲーム実行部１００で実行中のゲームの進行状況を示す進行情報を受信する。例えば、各ゲーム実行部１００は、メッセージが入力されると、進行情報をサーバ３０に送信する。サーバ３０は、当該進行情報を他のゲーム実行部１００に転送する。各ゲーム実行部１００のメッセージ受信部１１６は、他のゲーム実行部１００において入力され、サーバ３０により転送された進行情報を受信する。なお、各ゲーム実行部１００は、Ｐ２Ｐ通信などを利用して、他のゲーム実行部１００に対して進行情報を直接送信してもよい。

メッセージが入力された場合とは、例えば、メッセージの入力が検知された時点、又は、当該時点の前後の時点である。メッセージを入力するための操作信号が検出された時点が、メッセージの入力が検知された時点に相当する。本実施形態では、ウィンドウに表示されたスタンプのうちの何れかを選択する操作信号が検出された時点が、メッセージの入力が検知された時点に相当する。

例えば、各ゲーム実行部１００は、操作部１４の操作信号に基づいて、メッセージが入力されたか否かを判定する。メッセージが入力されたと判定された場合、各ゲーム実行部１００は、データ記憶部１０４に記憶された状況データＤＴ１が示す進行情報をサーバ３０に送信する。サーバ３０は、当該進行情報を転送する。各ゲーム実行部１００のメッセージ受信部１１６は、サーバ３０により転送された進行情報を受信する。

進行情報は、例えば、状況データＤＴ１に含まれる少なくとも１つの項目の値を含む情報である。進行情報は、ゲームの進行を特定可能な情報であればよく、例えば、時間情報であってもよいし、試合の戦況やキャラクタの位置等の情報であってもよい。本実施形態では、状況データＤＴ１に格納された時間情報が進行情報に相当する。このため、本実施形態で時間情報と記載した箇所は、進行情報と読み替えることができる。

［制限部］
制限部１１７は、実行中のゲームの進行状況が、他のゲーム実行部１００でメッセージが入力された場合の進行状況になるまで、メッセージの出力を制限する。本実施形態では、メッセージ受信部１１６が進行情報を受信するので、例えば、制限部１１７は、実行中のゲームの進行状況が、受信した進行情報が示す進行状況になるまで、メッセージの出力を制限することになる。

実行中のゲームの進行状況とは、例えば、状況データＤＴ１が示す進行状況であり、状況データＤＴ１に含まれる少なくとも１つの項目の値である。本実施形態では、時間情報が進行情報に相当するので、状況データＤＴ１に格納された時間情報が、実行中のゲームの進行状況に相当する。

メッセージが入力された場合の進行状況とは、例えば、メッセージが入力された時点の状況データＤＴ１が示す進行状況である。なお、時点とは、例えば、処理単位であるフレームであってもよいし、状況データＤＴ１に格納された時間情報であってもよい。また例えば、メッセージが入力された時点の前後の時点（例えば、数フレームだけ前後した時点）の状況データＤＴ１が示す進行状況である。なお、メッセージが入力された時点とは、操作部１４からメッセージの入力（又は入力完了）を示す信号を受信した時点である。

メッセージが入力された場合の進行状況になるまでとは、例えば、メッセージが入力された場合の進行状況と同じになるまでである。また例えば、メッセージが入力された場合の進行状況と一致するまでである。また例えば、メッセージが入力された場合の進行状況と等しくなるまである。

なお、少なくとも、メッセージが入力された場合の進行状況と同じになる（一致する・等しくなる）までは、メッセージの出力が制限されるようにすればよく、その後もメッセージの出力が制限されてもよい。即ち、メッセージが入力された場合の進行状況と同じになった時点（一致した時点・等しくなった時点）と、メッセージが出力される時点（メッセージの出力の制限が解除される時点）と、が完全に一致している必要はなく、メッセージが出力される時点（メッセージの出力の制限が解除される時点）は、メッセージが入力された場合の進行状況と同じになった時点（一致した時点・等しくなった時点）よりも後であってもよい。

制限とは、例えば、メッセージを出力させないことであり、メッセージの出力を待機することである。また例えば、制限は、メッセージが出力されるタイミングを遅らせることである。また例えば、制限は、メッセージを目立たないように表示させることである。また例えば、制限は、目立たないとは、サイズが小さいこと、透明度が高いこと、色が薄いことなどである。

本実施形態では、制限部１１７は、実行中のゲームの進行状況が、他のゲーム実行部１００でメッセージが入力された場合の進行状況に既になっている場合は、メッセージの出力を制限せずに、メッセージを出力させる。

メッセージが入力された場合の進行状況に既になっている場合とは、例えば、メッセージが入力された場合の進行状況と同じであること、又は、メッセージが入力された場合の進行状況と同じになったことが過去にあることである。また例えば、メッセージが入力された場合の進行状況と一致していること、又は、メッセージが入力された場合の進行状況と一致したことが過去にあることである。また例えば、メッセージが入力された場合の進行状況と等しいこと、又は、メッセージが入力された場合の進行状況と等しくなったことが過去にあることである。

本実施形態では、状況データＤＴ１は、ゲーム内の時間を示す時間情報を含み、制限部１１７は、実行中のゲーム内の時間が、他のゲーム実行部１００でメッセージが入力された場合のゲーム内の時間になるまで、メッセージの出力を制限する。

メッセージが入力された場合のゲーム内の時間になるまでとは、例えば、メッセージが入力された場合の時間と同じ時間になるまでである。また例えば、メッセージが入力された場合の時間と一致する時間になるまでである。また例えば、メッセージが入力された場合の時間と等しい時間になるまである。

少なくとも、メッセージが入力された場合の時間と同じになる（一致する・等しくなる）までは、メッセージの出力が制限されるようにすればよく、その後もメッセージの出力が制限されてもよい。即ち、メッセージが入力された場合の時間と同じになった時点（一致した時点・等しくなった時点）と、メッセージが出力される時点（メッセージの出力の制限が解除される時点）と、が完全に一致している必要はなく、メッセージが出力される時点（メッセージの出力の制限が解除される時点）は、メッセージが入力された場合の時間と同じになった時点（一致した時点・等しくなった時点）よりも後であってもよい。

なお、制限部１１７は、所定数以上のメッセージが入力された場合は、当該所定数以上のメッセージの全部又は一部のメッセージの出力を制限してもよい。例えば、制限部１１７は、メッセージの入力が受け付けられるたびに、メッセージが入力された回数をカウントし、当該回数が閾値以上になったか否かを判定する。制限部１１７は、メッセージが入力された回数が閾値以上になったと判定された場合に、メッセージの出力を制限する。なお、メッセージが入力された回数は、データ記憶部１０４に記録しておけばよい。

本実施形態では、制限部１１７は、状況データＤＴ１に格納された時間情報と、受信部が受信した時間情報と、に基づいて、メッセージの出力を制限するか否かを決定する。例えば、制限部１１７は、状況データＤＴ１に格納された時間情報が示す時間が、受信部が受信した時間情報が示す時間よりも早い場合、メッセージの出力を制限すると決定し、制限部１１７は、状況データＤＴ１に格納された時間情報が示す時間が、受信部が受信した時間情報が示す時間と同じ又は当該時間よりも遅い場合、メッセージの出力を制限しないと決定する。

［出力部］
出力部１１８は、メッセージを出力する。出力とは、例えば、視覚的又は聴覚的に出力されることである。即ち、出力とは、画像として表示されること、又は、音声として出力されることである。例えば、出力部１１８は、表示部１５にメッセージを表示させる。また例えば、ゲーム端末１０がスピーカやイヤホンジャックなどの音声出力部を含む場合には、出力部１１８は、音声出力部からメッセージを出力してもよい。

例えば、出力部１１８は、実行中のゲームの進行状況が、他のゲーム実行部１００でメッセージが入力された場合の進行状況に既になっている場合は、メッセージが入力された場合の進行状況を示す情報とともに、メッセージを出力してもよい。即ち、出力部１１８は、実行中のゲームの進行状況が、他のゲーム実行部１００でメッセージが入力された場合の進行状況に既になっている場合は、メッセージの出力を制限することなく、進行状況を示す情報とともにメッセージを表示させる。進行状況を示す情報は、進行状況を特定可能な情報であればよく、例えば、進行状況を示す文字列や画像である。なお、当該情報の表示は省略してもよい。

［２−２．ゲームシステムにおいて実行される処理］
図２０は、ゲームシステムＳにおいて実行される処理の一例を示すフロー図である。図２０に示す処理は、制御部１１が記憶部１２に記憶されたプログラムに従って動作し、制御部３１が記憶部３２に記憶されたプログラムに従って動作することによって実行される。以降説明する処理は、機能ブロックが実行する処理の一例である。なお、ここでは、グループ対戦のマッチングが完了し、対戦画像Ｇ６が表示された後の処理について説明する。また、グループ対戦においても、実施形態１で説明した個別対戦と同様の処理が実行され、共通の乱数に基づく試合進行が行われているものとする。

図２０に示すように、まず、ゲーム端末１０においては、制御部１１は、操作部１４の検出信号に基づいて、対戦画像Ｇ６のボタンＢ６２が選択されたか否かを判定する（Ｓ１５１）。ボタンＢ６２が選択されたと判定された場合（Ｓ１５１；Ｙ）、制御部１１は、メッセージの入力回数が閾値以上であるか否かを判定する（Ｓ１５３）。なお、メッセージの入力回数は、初期値を０として、予め記憶部１２に記憶されているものとする。

メッセージの入力回数が閾値以上であると判定された場合（Ｓ１５３；Ｙ）、Ｓ１５５以降の処理は実行されず、メッセージは入力されない。一方、メッセージの入力回数が閾値以上であると判定されない場合（Ｓ１５３；Ｎ）、制御部１１は、対戦画像Ｇ６にウィンドウＷ６３を表示させる（Ｓ１５５）。ウィンドウＷ６３に表示させる各スタンプの画像データは、予め記憶部１２に記憶されているものとする。

制御部１１は、操作部１４の検出信号に基づいて、ウィンドウＷ６３に表示された何れかのスタンプが選択されたか否かを判定する（Ｓ１５７）。何れかのスタンプが選択されたと判定された場合（Ｓ１５７；Ｙ）、制御部１１は、状況データＤＴ１に格納された時間情報とともに、メッセージを送信する（Ｓ１５９）。

ゲームサーバ３０Ｄにおいては、メッセージ等を受信すると、制御部３１Ｄは、受信したメッセージ等を転送する（Ｓ３３１）。なお、Ｓ３３１においては、制御部３１Ｄは、メッセージとともにユーザ情報も送信し、メッセージの入力者を特定可能としてもよい。

ゲーム端末１０においては、制御部１１は、ゲームサーバ３０Ｄからメッセージ等を受信したか否かを判定する（Ｓ１６１）。メッセージを受信したと判定された場合（Ｓ１６１）、制御部１１は、状況データＤＴ１に格納された時間情報と、受信した時間情報と、に基づいて、メッセージを表示させるか否かを決定する（Ｓ１６３）。

一方、Ｓ１６３において、メッセージを表示させると決定された場合（Ｓ１６３；Ｙ）、制御部１１は、メッセージを表示させる（Ｓ１６５）。Ｓ１６５においては、制御部１１は、メッセージが入力された場合の時間情報も表示させてもよい。

メッセージを表示させると決定されない場合（Ｓ１６３；Ｎ）、制御部１１は、メッセージの表示を待機する（Ｓ１６７）。制御部１１は、Ｓ１６７で表示が待機されたメッセージを、Ｓ１６１で受信した時間情報になった場合に表示させる。即ち、制御部１１は、状況データＤＴ１に格納された時間情報が示す時間が、Ｓ１６１で受信した時間情報が示す時間になった場合に、Ｓ１６７で表示が待機されたメッセージを表示部１５に表示させる。

制御部１１は、終了条件が満たされたか否かを判定する（Ｓ１６９）。終了条件は、前半終了又は試合終了などの任意の条件であってよい。終了条件が満たされたと判定されない場合（Ｓ１６９；Ｎ）、Ｓ１５１の処理に戻る。終了条件が満たされたと判定された場合（Ｓ１６９；Ｙ）、本処理は首領する。

以上説明したゲームシステムＳによれば、実行中のゲームが、他のゲーム実行部１００でメッセージが入力された場合の進行状況になるまで、メッセージの出力を制限することで、ゲーム進行が遅いゲーム実行部１００のユーザが、ゲーム進行が早いゲーム実行部１００のユーザのメッセージの内容から今後の展開を予想するといったことを防止できるので、ゲームの興趣性の低下を防止することができる。また、ゲーム進行が遅いゲーム実行部１００に、ゲーム進行が早いゲーム実行部１００のユーザのメッセージを表示させると、ゲーム進行の違いによって話がかみ合わないといったことが生じるが、実施形態２のゲームシステムＳでは、このようなことを防止し、複数のユーザの話をかみ合わせることができる。また、各ゲーム実行部１００で共通のゲーム処理を実行することによって状況データＤＴ１を更新することで、複数のユーザがゲームに参加する場合の通信負荷を軽減することもできる。

また、実行中のゲームの進行状況が他のゲーム実行部１００でメッセージが入力された場合の進行状況に既になっている場合には、当該メッセージの出力を制限せずに出力することで、進行が遅れている他のユーザが入力したメッセージをユーザに迅速に把握させることができる。このため、進行が遅れている他のユーザのメッセージが出力されないといったことを防止することができる。

また、ゲーム内の時間を示す時間情報を利用することで、実行中のゲームの進行状況が、他のゲーム実行部１００でメッセージが入力された場合の進行状況になっているか否かをより簡易な処理によって判定することができるので、ゲーム実行部１００の処理負荷を軽減することができる。

また、所定数以上のメッセージが入力された場合に、所定数以上のメッセージの全部又は一部のメッセージの出力が制限されることで、多数のメッセージが出力されることを防止できる。

また、ゲームが開始される場合に取得されたチーム情報と、複数のゲーム実行部１００で共通の乱数発生規則に基づいて発生される乱数と、に基づいて、複数のゲーム実行部１００で共通のゲーム処理を実行することによって状況データＤＴ１が更新され、ゲーム実行部１００間で状況データＤＴ１の整合を取らなくても状況データＤＴ１が同じ内容になるので、複数のユーザがゲームに参加する場合の通信負荷を軽減することができる。また、ゲームで使用されるチーム情報の組み合わせが同じだった場合、乱数を使用しなかったとすると毎回同じゲーム結果となってしまい、ユーザが飽きてしまう可能性があるが、乱数を使用してランダム要素を入れることで、チーム情報の組み合わせが同じだったとしてもゲーム結果に変化をつけることができる。また、通信障害やアプリケーション終了等の理由により、一部のユーザがゲームを途中終了させたとしても、各ユーザ端末内で状況データＤＴ１が更新されるので、他のユーザはゲームを最後まで続けることができる。

また、実行中のゲームが、他のゲーム実行部１００でメッセージが入力された場合の進行状況に既になっている場合に、当該進行状況を示す情報とともにメッセージが表示されるので、どの時点で他のユーザが入力したメッセージなのかをユーザに把握させることができる。

また、各ゲーム実行部１００にメッセージの出力を制限する処理を実行させることで、例えば、ゲームシステムＳ内のサーバ３０の処理負荷を軽減することができる。

［３．実施形態３］
次に、ゲームシステムＳの別実施形態を説明する。以降説明する実施形態３では、実施形態１−２で説明したゲームと同様のゲームが実行される場合を説明するが、実施形態３のゲームは、実施形態１−２のゲームとは異なってもよい。実施形態３のゲームシステムＳは、複数のユーザが役割を分担して参加するゲームを実行する。

役割とは、例えば、ゲームの中で果たすべき任務である。例えば、スポーツゲームであればポジションである。また例えば、野球ゲームの場合には、ポジションではなく打順が役割に相当してもよい。また例えば、ロールプレイングゲームであれば、役割は、ジョブなどと呼ばれる役職であってもよい。また例えば、カードゲームであれば、役割は、攻撃用のカードであるか、他のカードの支援用のカードであるか等であってもよい。また例えば、役割は、ユーザの役割であってもよいし、ユーザのゲームオブジェクトの役割であってもよい。

分担とは、例えば、複数のユーザの間で異なる役割が割り当てられることであり、あるユーザと他のユーザとがそれぞれ別の役割を担当することである。例えば、第１のユーザが第１の役割を担当し、第２のユーザが第２の役割を担当することである。また例えば、第１のユーザ情報に第１の役割が関連付けられ、第２のユーザ情報に第２の役割が関連付けられることである。また例えば、第１のゲームオブジェクトに第１の役割が関連付けられ、第２のゲームオブジェクトに第２の役割が関連付けられることである。

本実施形態では、ポジションが役割に相当する。このため、本実施形態でポジションと記載した箇所は、役割と読み替えることができる。また、実施形態３では、グループ対戦におけるマッチングについて説明する。例えば、グループ対戦は、複数人でチームを組んで対戦する。チームのフォーメーションは、予め決められており、原則として、フォーメーションが示す複数のポジションの中で分担が行われる。

なお、グループ対戦のフォーメーションは、期間に関係なく固定されていてもよいし、期間に応じて変わってもよい。例えば、ある期間は、キーパーが１人、ディフェンダーが４人、ミッドフィールダーが３人、フォワードが３人の「４−３−３」と呼ばれるフォーメーションとなり、他の期間では、キーパーが１人、ディフェンダーが３人、ミッドフィールダーが４人、フォワードが３人の「３−４−３」と呼ばれるフォーメーションとなってもよい。

また、グループ対戦では、原則として、予め定められたフォーメーションの中で、１人当たり１つのポジションを担当する。このため、グループ対戦では、同じチームに属する１１人のマッチングが行われる。別の言い方をすれば、グループ対戦では、１１個のユーザ情報のマッチング、１１個のキャラクタ（又はカード）のマッチング、又は１１個のゲームプログラムのマッチングが行われるということもできる。

なお、１１人集まらなかった場合には、マッチングされたユーザのユーザ情報に関連付けられたキャラクタが使用される。例えば、サッカーゲームでは１チームあたり１１人のキャラクタで試合が行われるが、マッチングで５人しか集まらなかった場合には、残り６人分のキャラクタについては、その時点で集まった５人のユーザ情報の各々に関連付けられたキャラクタの中から補充される。

例えば、試合メニュー画像Ｇ２（図３）のボタンＢ２３が選択されると、グループ対戦のレベルなどを選択するための画像が表示された後に、グループ対戦で使用するキャラクタが描かれたカードを選択するためのカード選択画像が表示部１５に表示される。

図２１は、カード選択画像の一例を示す図である。図２１に示すように、カード選択画像Ｇ７は、フォーメーションを表示するための表示領域を含む。表示領域Ａ７０には、ピッチを模した画像の上に、各ポジションの混み具合を示す画像が表示されている。混み具合とは、後述する参加登録ユーザの数であり、各画像は、フォーメーションが示す各ポジションに対応する位置に表示されている。ここでは、混み具合が３段階で示されており、例えば、「◎」は最も空いており、「○」は２番目に空いており、「△」は最も混み合っていることを示す。なお、混み具合は、２段階で示されてもよいし、４段階以上で示されてもよい。

図２１の例であれば、「４−３−３」のフォーメーションが定められており、例えば、ゴールキーパーが１人、ディフェンダーが４人、ミッドフィールダーが３人、フォワードが３人のフォーメーションが定められている。例えば、ディフェンダー、ミッドフィールダー、及びフォワードは、役割が細分化されていてもよく、表示領域Ａ７０には、細分化された役割ごとに混み具合が示されている。

例えば、ディフェンダーは、センターバック、右サイドバック、左サイドバックに細分化され、センターバックは２人存在し、右サイドバックと左サイドバックは１人ずつ存在する。また例えば、ミッドフィールダーは、セントラルミッドフィールダー、右サイドハーフ、及び左サイドハーフに細分化され、これら各ポジションは１人ずつ存在する。また例えば、フォワードは、センターフォワード、右ウイング、及び左ウイングに細分化され、これら各ポジションは１人ずつ存在する。

図２１の例では、センターフォワードは混みあっており、センターフォワードのキャラクタをグループ対戦で使おうとすると、マッチングに時間がかかる可能性がある。一方、右ウイングと左ウイングとミッドフィールダー（セントラルミッドフィールダー、右サイドハーフ、及び左サイドハーフ）は、センターフォワードよりは空いており、マッチングにさほど時間はかからない。ゴールキーパーとディフェンダー（センターバック、右サイドバック、左サイドバック）は、何れも空いており、比較的すぐにマッチングされる可能性がある。各ポジションの混み具合は、その時の状況に応じて動的に変化する。

また、カード選択画像Ｇ７は、選択中のキャラクタに関する情報を表示するための表示領域Ａ７１を含む。選択中のキャラクタとは、グループ対戦で使おうとしているキャラクタであり、チーム内の何れかのキャラクタが選択される。例えば、表示領域Ａ７１には、キャラクタの画像、名称、レベル、ポジション、及び能力パラメータなどの情報が表示される。

なお、本実施形態では、キャラクタのポジションは、上記説明した細分化されたポジションが設定されているものとする。キャラクタには、ポジションが１つだけ設定されていてもよいし、複数のポジションが設定されていてもよい。また、キャラクタによって、設定されるポジションの数が異なってもよい。キャラクタのポジションは、表示領域Ａ７０に表示されたピッチに示されてもよい。例えば、キャラクタのポジションに対応する領域が、他の領域とは異なる色で表示されてもよい。図２１の例では、キャラクタのポジションは、センターフォワードであり、表示領域Ａ７０のピッチのうち、センターフォワードに対応する位置の色（図２１では網点で示す）が異なっている。

表示領域Ａ７１には、キャラクタを入れ替えるためのボタンＢ７１０が表示される。ボタンＢ７１０が選択されると、グループ対戦で使用するキャラクタが他のキャラクタに切り替わる。例えば、ボタンＢ７１０が選択されると、キャラクタのリストが表示され、当該リストの中からグループ対戦で使用するキャラクタが選択される。例えば、グループ対戦で別のポジションのキャラクタが使用されるように、キャラクタを切り替えることができる。

また、カード選択画像Ｇ７には、グループ対戦を開始するためのボタンＢ７２が表示される。ボタンＢ７２が選択されると、グループ対戦への参加要求が送信され、グループ対戦のマッチングが開始される。

図２２は、マッチング中のカード選択画像Ｇ７の一例を示す図である。図２２に示すように、カード選択画像Ｇ７には、マッチング中であることを示すウィンドウＷ７３が表示される。ウィンドウＷ７３には、現時点でマッチングされた人数が表示される。なお、ウィンドウＷ７３には、マッチングをキャンセルしてウィンドウＷ７３を閉じるためのボタンＢ７３０も表示される。ボタンＢ７３０が選択されると、グループ対戦への参加がキャンセルされてマッチングが中断される。

グループ対戦のマッチングでは、ポジションごとに、参加登録ユーザのユーザ情報を格納するためのキューが用意されている。例えば、「４−３−３」のフォーメーションでは、ゴールキーパー、センターバック、右サイドバック、左サイドバック、セントラルミッドフィールダー、右サイドハーフ、左サイドハーフ、センターフォワード、右ウイング、及び左ウイングの合計１０個のポジションが存在するため、１０個のキューが存在する。

例えば、グループ対戦への参加要求が送信されると、選択中のキャラクタに設定されたポジションのキューに、参加登録ユーザのユーザ情報が格納される。キャラクタに複数のポジションが設定されている場合には、最も空いているキューにユーザ情報が格納されるものとする。マッチングは、各キューに対するユーザ情報の格納順に実行される。このため、空いているポジションについては、マッチング完了まであまり時間がかからず、混んでいるポジションについては、マッチング完了までに時間がかかる。表示領域Ａ７０には、キューごとの混み具合が表示されることになる。

なお、先述したように、一定時間経過しても１１人そろわない場合には、現時点で集まった分だけでマッチングが行われ、足りないポジションについては、現時点で集まったユーザのユーザ情報に関連付けられたキャラクタ（カード）によって補充される。マッチングが完了すると、各チームのキャラクタの画像が表示された後に、グループ対戦が開始される。グループ対戦の流れは、実施形態２で説明した通りであり、ユーザの操作は介入されずに自動進行する。

以上のように、実施形態３のゲームシステムＳでは、グループ対戦において、ポジションごとにキューが設定されており、参加登録ユーザのユーザ情報が何れかのキューに格納されることで、ユーザが所望の役割を担当するための手間を軽減するようにしている。以降、実施形態３の詳細を説明する。なお、以降の説明では、実施形態１−２と同様の構成については説明を省略する。

［３−１．実施形態３で実現される機能］
図２３は、ゲームシステムＳで実現される機能のうち、本発明に関連する機能を示す機能ブロック図である。図２３に示すように、実施形態３のゲームシステムＳでは、データ記憶部３００、受付部３０３、役割取得部３０４、追加部３０５、選択部３０６、提示部３０７、役割変更部３０８、時間変更部３０９、及び役割割当部３１０が実現され、これらがサーバ３０において実現される場合を説明する。なお、実施形態３においても、実施形態１−２で説明した機能が実現されてよい。

［データ記憶部］
実施形態３のデータ記憶部３００は、実施形態１−２で説明したユーザデータＤＴ２に加え、参加登録データＤＴ３を記憶する。

図２４は、参加登録データＤＴ３のデータ格納例を示す図である。図２４に示すように、参加登録データＤＴ３には、各ポジションと、ゲームへの参加を登録している参加登録ユーザのユーザ情報と、が関連付けられている。例えば、参加登録データＤＴ３は、ポジションごとに、ゲームへの参加登録ユーザのユーザ情報が関連付けられたデータである。ここでは、参加登録データＤＴ３は、キューと呼ばれる形式である場合を説明するが、任意のデータ形式であってよく、例えば、テーブル形式や配列形式であってもよい。

なお、ゲームへの参加を登録するとは、例えば、参加要求を受け付けたことがコンピュータ上に登録されていることである。別の言い方をすれば、マッチング待ちとしてコンピュータ上に登録されていることである。参加登録ユーザとは、例えば、参加登録データＤＴ３にユーザ情報が登録されたユーザである。

［受付部］
受付部３０３は、制御部３１Ｃを主として実現される。受付部３０３は、各ユーザによる、ゲームへの参加要求を受け付ける。本実施形態では、受付部３０３がロビーサーバ３０Ｃにおいて実現される場合を説明するので、受付部３０３は、所定の通知を受信することによって、参加要求を受け付けることになる。

参加要求とは、例えば、ゲームに参加する意思を示すことである。例えば、参加要求は、ゲームに参加するための情報をサーバに送信することである。また例えば、参加要求は、画面内の所定のボタンの選択を検知することであってもよいし、ゲーム端末１０からサーバ３０に対してゲームへの参加を要求する通知であってもよい。また例えば、参加要求は、予め定められたデータ形式で行われるようにすればよく、ユーザ情報、ユーザが使用するゲームオブジェクトのＩＤといった情報を送信することによって行われる。

本実施形態では、カード選択画像Ｇ７のボタンＢ７２が選択されると参加要求が送信されるので、受付部３０３は、ボタンＢ７２が選択されたことを示す通知を受信することによって、参加要求を受け付けることになる。例えば、参加要求には、ユーザ情報と、選択中のキャラクタ（又はキャラクタが描かれたカード）に関する情報（例えば、キャラクタＩＤ（カードＩＤ）やポジション）と、が含まれるものとする。

［役割取得部］
役割取得部３０４は、制御部３１Ｃを主として実現される。本実施形態では、ポジションが役割に相当するので、役割取得部３０４は、複数のポジションのうち、参加要求をしたユーザが所望するポジションを取得する。本実施形態では、役割取得部３０４がロビーサーバ３０Ｃにおいて実現される場合を説明するので、役割取得部３０４は、ポジションを識別する情報を受信することによって、所望するポジションを取得することになる。

所望するポジションとは、例えば、ゲームで担当したいポジションとして選択されたポジションである。例えば、所望するポジションは、複数のポジションの中からユーザが選択してもよいし、ゲームで使用するゲームオブジェクトに関連付けられたポジションであってもよい。複数のポジションは、操作部１４の検出信号に基づいて決定されてもよいが、本実施形態では、複数のポジションは、予め定められたポジションの組み合わせに基づいて決定される。ポジションの組み合わせとは、例えば、複数のポジションからなるポジションのセットであり、例えば、グループ対戦において予め定められたフォーメーションがポジションの組み合わせに相当する。なお、役割がポジション以外の名称で呼ばれるものであれば、役割の組み合わせは、例えば、パーティ、隊列、陣形などと呼ばれる。

本実施形態のゲームでは、各ユーザのゲームオブジェクトが使用され、役割取得部３０４は、参加要求をしたユーザのゲームオブジェクトと関連付けられたポジションを、当該ユーザが所望するポジションとして取得する。本実施形態では、キャラクタを示すゲームカードがゲームオブジェクトに相当し、ポジションが役割に相当するので、役割取得部３０４は、カード選択画像Ｇ７において選択されたキャラクタのポジションを、所望する役割として取得することになる。なお、本実施形態では、ゲームカードを例に挙げて説明するが、ゲームカードに限られず、ゲームオブジェクトであれば、ゲームカード以外の構成であってもよく、例えば、キャラクタであってもよいしアイテムであってもよい。

［追加部］
追加部３０５は、制御部３１Ｃを主として実現される。追加部３０５は、各ポジションと、ゲームへの参加を登録している参加登録ユーザのユーザ情報と、が関連付けられた参加登録データＤＴ３に、参加要求をしたユーザのユーザ情報を、当該ユーザが所望するポジションと関連付けて追加する。例えば、受付部３０３が参加要求を受け付けると、追加部３０５は、参加登録データＤＴ３のうち、役割取得部３０４が取得したポジションに対応するキューに、参加要求とともに受信したユーザ情報を格納する。

参加登録データＤＴ３に格納されるユーザ情報の順番は、任意であってよいが、ここでは、追加部３０５は、参加要求を受け付けた順にユーザ情報を格納する。このため、参加要求を受け付けたのが早いほどマッチングされるのが早くなり、参加要求を受け付けたのが遅いほどマッチングされるのが遅くなる。

なお、追加部３０５は、参加要求をしたユーザが所望するポジションが複数ある場合には、参加登録データＤＴ３に基づいて、当該ユーザが所望する複数のポジションの中から選択した少なくとも１つのポジションと関連付けて、当該ユーザのユーザ情報を参加登録データＤＴ３に追加する。

例えば、追加部３０５は、操作部１４の検出信号に基づいて、複数のポジションの何れかを選択してもよいし、ランダムにポジションを選択してもよい。また例えば、追加部３０５は、参加登録データＤＴ３が示す各ポジションの混み具合に基づいて、ポジションを選択してもよい。例えば、追加部３０５は、複数のポジションのうち、最も空いているポジションを選択してもよい。空いているポジションとは、キューに格納されたユーザ情報の数が少ないポジションである。

［選択部］
選択部３０６は、ゲームに参加する複数のユーザを選択する。ここでの選択とは、例えば、ゲームに参加するユーザの組み合わせを決めることであり、あるユーザと対戦又は協力する他のユーザを決めることである。即ち、ユーザ同士のマッチングである。選択部３０６は、参加登録データＤＴ３に基づいて、ポジションごとに、当該ポジションを担当するユーザを、当該ポジションにユーザ情報が関連付けられた参加登録ユーザの中から選択する。

例えば、選択部３０６は、複数のポジションをそれぞれ所望する複数のユーザが集まった場合に、当該複数のユーザを選択する。集まった場合とは、例えば、各ポジションを担当する数が予め定められている場合に、各ポジションを担当する数だけ参加登録ユーザの数がそろうことである。

また例えば、選択部３０６は、所定時間が経過しても、複数のポジションをそれぞれ所望する複数のユーザが集まらなかった場合には、現時点で集まったユーザを選択してもよい。所定時間は、予め定められた時間であればよく、固定値であってもよいし可変値であってもよい。例えば、選択部３０６は、参加要求が受け付けられた場合に計時処理を開始し、所定時間が経過したか否かを判定する。選択部３０６は、所定時間が経過したと判定した場合には、１１人そろわなくてもマッチングを完了することになる。

本実施形態のゲームでは、各ユーザの複数のゲームオブジェクトのうち、当該ユーザが指定したゲームオブジェクトが使用されるので、選択部３０６は、複数のポジションをそれぞれ所望する複数のユーザが集まった場合に、当該複数のユーザを選択する。選択部３０６は、所定時間が経過しても、複数のポジションをそれぞれ所望する複数のユーザが集まらなかった場合には、現時点で集まったユーザを選択することになる。

［提示部］
提示部３０７は、参加登録データＤＴ３に基づいて、各ポジションの参加登録状況を各ユーザに提示する。参加登録状況とは、例えば、参加登録ユーザの数である。また例えば、各ポジションを担当する数に対する参加登録ユーザの数の割合である。参加登録状況は、画像で提示されてもよいし、音声で通知されてもよい。例えば、提示部３０７は、参加登録ユーザの数を示す画像又は音声を出力させてもよいし、混み具合を示す画像又は音声を出力させてもよい。

［役割変更部］
役割変更部３０８は、参加登録状況が提示されたユーザの操作に基づいて、当該ユーザが所望するポジションを変更する。例えば、役割変更部３０８は、操作部１４の検出信号に基づいて、ユーザが所望するポジションを変更する。本実施形態では、グループ対戦で使用するキャラクタを切り替えることでポジションが変更されるので、役割変更部３０８は、操作部１４の検出信号に基づいて、選択されたキャラクタのポジションに変更する。なお、役割変更部３０８は、複数のポジションの中から選択されたポジションに変更してもよい。

［時間変更部］
時間変更部３０９は、参加登録データＤＴ３に基づいて、所定時間の長さを変更する。例えば、時間変更部３０９は、参加登録データＤＴ３に格納されたユーザ情報の数に基づいて所定時間の長さを変更する。例えば、時間変更部３０９は、ユーザ情報の数が少ないほど所定時間を長く設定し、ユーザ情報の数が多いほど所定時間を短く設定する。即ち、時間変更部３０９は、参加登録ユーザが少ないほど所定時間を長く設定し、参加登録ユーザが多いほど所定時間を短く設定する。

［役割割当部］
役割割当部３１０は、選択部３０６により選択された複数のユーザの各々が指定したゲームオブジェクトに、当該ユーザが所望するポジションを割り当てる。本実施形態では、キャラクタ（カード）がゲームオブジェクトに相当するので、役割割当部３１０は、キャラクタに設定されたポジションを、グループ対戦におけるポジションとして割り当てることになる。

例えば、役割割当部３１０は、複数のポジションをそれぞれ所望する複数のユーザが集まらなかった場合には、選択部３０６により選択された複数のユーザの各々が指定しなかったゲームオブジェクトの中から、ユーザが集まらなかったポジションを割り当てるゲームオブジェクトを決定してもよい。本実施形態では、キャラクタ（カード）がゲームオブジェクトに相当するので、役割割当部３１０は、ユーザが集まらなかったポジションについては、集まったユーザのキャラクタのうちの何れかが担当するように、ポジションを割り当てることになる。

［３−２．ゲームシステムにおいて実行される処理］
図２５は、ゲームシステムＳにおいて実行される処理の一例を示すフロー図である。図２５に示す処理は、制御部１１が記憶部１２に記憶されたプログラムに従って動作し、制御部３１が記憶部３２に記憶されたプログラムに従って動作することによって実行される。以降説明する処理は、機能ブロックが実行する処理の一例である。なお、ここでは、試合メニュー画像Ｇ２のボタンＢ２３が選択された後の処理について説明する。

図２５に示すように、ゲーム端末１０においては、制御部１１は、ロビーサーバ３０Ｃに対し、カード選択画像Ｇ７の表示要求を送信する（Ｓ１８１）。表示要求は、予め定められた形式で行われるようにすればよく、例えば、カード選択画像Ｇ７を識別するためのＩＤ情報が含まれる。

ロビーサーバ３０Ｃにおいては、表示要求を受信すると、制御部３１Ｃは、参加登録データＤＴ３に基づいて、各ポジションの混み具合を示すデータを送信する（Ｓ３４１）。Ｓ３４１においては、制御部３１Ｃは、各ポジションの参加登録ユーザの数を混み具合として送信してもよいし、各ポジションの参加登録ユーザの数に基づいてどの画像を表示させたらよいかを示すデータを送信してもよい。また例えば、混み具合を複数段階の何れかで示す場合には、制御部３１Ｃは、各ポジションの混み具合の段階を示すデータを送信してもよい。

ゲーム端末１０においては、データを受信すると、制御部１１は、カード選択画像Ｇ７を表示部１５に表示させる（Ｓ１８３）。Ｓ１８３においては、制御部１１は、受信したデータに基づいて、表示領域Ｇ７０のピッチ上の各画像の表示態様を決定する。例えば、制御部１１は、最も空いているポジションに「◎」の画像を表示させ、次に空いているポジションに「○」の画像を表示させ、最も混んでいるポジションに「△」の画像を表示させる。

制御部１１は、操作部１４の検出信号に基づいて、ユーザの操作を特定する（Ｓ１８５）。ここでは、ボタンＢ７１０，Ｂ７２を選択する操作が行われるものとする。ボタンＢ７１０が選択された場合（Ｓ１８５；Ｂ７１０）、制御部１１は、グループ対戦で使用するキャラクタを変更する（Ｓ１８７）。Ｓ１８７においてキャラクタが変更されると、表示領域Ａ７０，Ａ７１の内容も更新される。

一方、ボタンＢ７２が選択された場合（Ｓ１８５；Ｂ７２）、制御部１１は、グループ対戦への参加要求を送信する（Ｓ１８９）。参加要求は、予め定められた形式で行われるようにすればよく、例えば、ユーザ情報と、選択中のキャラクタのキャラクタＩＤとポジションと、が含まれるものとする。

ロビーサーバ３０Ｃにおいては、参加要求を受信すると、制御部３１Ｃは、キャラクタのポジションに対応するキューに、参加要求をしたユーザのユーザ情報を追加し（Ｓ３４３）、マッチングを実行する（Ｓ３４５）。Ｓ３４３においては、制御部３１Ｃは、参加登録データＤＴ３のうち、選択中のキャラクタのポジションに対応するレコードにユーザ情報を追加する。

図２６は、Ｓ３４５の処理の詳細を示す図である。図２６に示すように、制御部３１Ｃは、参加登録データＤＴ３に基づいて、フォーメーションの全ポジションが集まっているか否かを判定する（Ｓ３４５１）。Ｓ３４５１においては、制御部３１Ｃは、各ポジションに定められた人数分のユーザ情報が参加登録データＤＴ３に格納されているか否かを判定する。

全ポジションが集まっていると判定された場合（Ｓ３４５１；Ｙ）、制御部３１Ｃは、集まったユーザ同士がチームを組むようにマッチングする（Ｓ３４５３）。Ｓ３４５３においては、制御部３１Ｃは、マッチングされたユーザ情報を参加登録データＤＴ３から削除する。一方、集まっていないポジションがあると判定された場合（Ｓ３４５１；Ｎ）、制御部３１Ｃは、新たな参加要求を待ち受ける（Ｓ３４５５）。Ｓ３４５５においては、制御部３１Ｃは、計時を開始し、参加登録データＤＴ３にユーザ情報が追加されて、全ポジションが揃うまで待機する。

制御部３１Ｃは、新たな参加要求を待ち受けてから所定時間が経過したか否かを判定する（Ｓ３４５７）。所定時間の長さを示す情報は、記憶部３２Ｃに記憶されているものとする。なお、先述したように、所定時間は参加登録データＤＴ３が示す混み具合に基づいて変化させてもよい。所定時間が経過したと判定されない場合（Ｓ３４５７；Ｎ）、Ｓ３４５１の処理に戻る。制御部３１Ｃは、参加登録データＤＴ３にユーザ情報が追加されて、全ポジションが揃った場合には、Ｓ３４５３の処理に移行してマッチングを行うことになる。

一方、所定時間が経過したと判定された場合（Ｓ３４５７；Ｙ）、制御部３１Ｃは、集まっていないポジションに割り当てるキャラクタを決定してマッチングを完了する（Ｓ３４５９）。Ｓ３４５９においては、制御部３１Ｃは、現時点で集まったユーザのキャラクタ（カード）でチームを組むようにマッチングを行い、集まっていないポジションについては、現時点で集まったユーザのキャラクタの中から補充する。

図２５に戻り、制御部３１Ｃは、マッチングが完了した旨の通知を送信する（Ｓ３４７）。Ｓ３４７の処理は、個別対戦のＳ３０９と同様であってよく、以降は、個別対戦と同様の流れでグループ対戦が実行されるようにしてよい。

以上説明したゲームシステムＳによれば、ゲームへの参加要求をしたユーザのユーザ情報を、当該ユーザが所望するポジションと関連付けて参加登録データＤＴ３に追加して、ポジションごとに、当該ポジションを担当するユーザを、当該ポジションにユーザ情報が関連付けられた参加登録ユーザの中から選択することで、例えば、ユーザが所望するポジションを他のユーザに取られたり、所望するポジションが空いている対戦部屋をいちいち探したりすることがなくなるので、ユーザが所望のポジションを担当するための手間を軽減することができる。

また、各ポジションを所望するユーザが集まるまでゲームに参加するユーザの選択が行われないといった場合には、参加要求をしたユーザが待機する状態が続き、ユーザがいつまで待てばよいか分からずに不満を感じる可能性があるが、ゲームシステムＳによれば、各ポジションの参加登録状況が提示され、マッチングまでどの程度時間がかかるかを予め予測させるといったことができるので、ユーザの不満を解消することができる。

また、予め定められたポジションの組み合わせに基づいて複数のポジションが決定されることで、複数のポジションを決める手間を省くことができる。他にも例えば、複数種類の組み合わせを用意しておき、時期に応じて使用する組み合わせを変えるようにした場合には、時期によってポジションに変化を与えることができ、ゲームの興趣性を向上させることができる。

また、参加登録状況が提示されたユーザが所望するポジションを変更することで、例えば、比較的空いているポジションに変更して待ち時間を減らすといったことができ、ユーザの不満を効果的に解消することができる。

また、参加要求をしたユーザのゲームオブジェクトと関連付けられたポジションを当該ユーザが所望するポジションとすることで、ユーザがゲームに参加する前に所望するポジションをいちいち選択しなくても済むので、ユーザの手間を効果的に軽減することができる。

また、参加登録データＤＴ３が示す各ポジションの参加登録状況を考慮したうえで、ユーザ情報を関連付けるポジションを選択することで、例えば、比較的空いているポジションにユーザ情報を追加するといったことができるので、マッチングまでの待ち時間（ゲーム開始までの待ち時間）を短縮することができる。

また、参加登録データＤＴ３が示す各ポジションの参加登録状況が、ゲームに参加するユーザを選択するための所定時間の長さに反映されるので、ゲームに参加するユーザを選択するまでにユーザを長時間待たせるといったことを防止することができる。

また、所定時間が経過しても複数のポジションをそれぞれ所望する複数のユーザが集まらなかった場合には、現時点で集まったユーザを選択することで、ユーザがいつまで待ってもゲームに参加できないといった不満を防止することができる。更に、ユーザが指定しなかったゲームオブジェクトの中から、ユーザが集まらなかったポジションを担当させることで、全く関係のないゲームオブジェクトが使用されるのではなく、ユーザのゲームオブジェクトが使用されるので、ゲームの興趣性を向上させることができる。

［３−３．実施形態３の変形例］
なお、参加登録データＤＴ３には、細分化されたポジションごとにキューが設けられている場合を説明したが、大まかなポジションごとにキューが設けられていてもよい。例えば、図２４のように、１０個の細かなポジションごとにキューを設けるのではなく、フォワード、ミッドフィールダー、ディフェンダー、ゴールキーパーといった４つの大まかなポジションごとにキューを設けてもよい。この場合、例えば、センターフォワードのキャラクタが選択された場合には、センターフォワードが属するフォワードのキューにユーザ情報が格納される。マッチング後に細かなポジションを決定する場合には、各キャラクタのポジションは、ランダムに決定されてもよいし、当該キャラクタに設定されたポジションに基づいて決定されてもよい。

図２７は、実施形態３の変形例における機能ブロック図である。図２７に示すように、役割決定部３１１が実現される。本変形例のゲームでは、複数の第１のポジションと、当該複数の第１のポジションの各々の何れか一又は複数の第１のポジションに属する詳細なポジションである一又は複数の第２のポジションと、があり、役割取得部３０４は、参加要求をしたユーザが所望する第２のポジションを取得する。

第１のポジションとは、第２のポジションよりも大きな分類（カテゴリ）である。第２のポジションの上位概念に相当するポジションである。第２のポジションを包含するポジションである。例えば、スポーツゲームであれば、第２のポジションよりも大きなポジションである。サッカーゲームであれば、フォワードやミッドフィールダーといったポジションである。野球ゲームであれば、内野手や外野手といったポジションである。

第２のポジションとは、第１のポジションよりも小さな分類（カテゴリ）である。第１のポジションの下位概念に相当するポジションである。第１のポジションを具体化したポジションである。例えば、スポーツゲームであれば、第１のポジションよりも細かなポジションである。サッカーゲームであれば、センターフォワードやセントラルミッドフィールダーといったポジションである。野球ゲームであれば、一塁手や右翼手といったポジションである。

図２８は、第１のポジションと第２のポジションとの関係を示す図である。図２８に示すように、実施形態３のフォーメーションでは、フォワード、ミッドフィールダー、及びディフェンダーの各々は、３種類の詳細なポジションを含むので、１つの第１のポジションに対し、３つの第２のポジションが存在することになる。一方、ゴールキーパーは、１つだけなので、１つの第１のポジションに対し、１つの第２のポジションが存在することになる。このように、第１のポジションと第２のポジションは、１対多の関係に限られず、１対１の関係であってもよい。即ち、図２８のゴールキーパーのように、第１のポジジョンと第２のポジションのポジションがいずれも１対１で対応しているものも含む。

また、先述したように、第１の役割と第２の役割は、ポジションに限られず、ゲームに応じた役割を定めればよい。例えば、ロールプレイングゲームにおけるキャラクタの職業（又は役職）が役割に相当してもよい。この場合に、第１の職業と、詳細な職業である第２の役職と、が存在してもよい。

図２９は、第１の職業と第２の役職との関係を示す図である。図２９に示すように、例えば、第１の職業として魔法使いと戦士が存在する場合に、魔法使いに対応する第２の役職として、冒険者、下級魔法使い、中級魔法使い、上級魔法使い、及び魔法戦士が存在し、戦士に対応する第２の役職として、冒険者、下級戦士、中級戦士、上級戦士、及び魔法戦士が存在してもよい。この場合、冒険者と魔法戦士は、第１の職業と第２の役職の両方に属することになる。即ち、第１の職業と第２の役職とが多対多の関係にあってもよく、第１の職業である魔法使いと戦士の各々に、第２の役職である冒険者と魔法戦士が属していてもよい。

上記の例では、第１の役割は、例えば、第１のポジションや第１の職業のことであり、第２の役割は、例えば、第２のポジションや第２の役職のことである。図２８に示すポジションのように、第１の役割と第２役割が同一分類（カテゴリ）であってもよいし、図２９に示す職業と役職のように第１の役割と第２の役割とで、分類（カテゴリ）が異なっていてもよい。データ記憶部３００に、第１の役割と第２の役割の対応関係が予め保存されていればよい。

本変形例の参加登録データＤＴ３には、複数の第１のポジションの各々と、ゲームへの参加登録のユーザのユーザ情報と、が関連付けられており、追加部３０５は、参加要求をしたユーザが所望する第２のポジションが属する第１のポジションと関連付けて、当該ユーザのユーザ情報を参加登録データＤＴ３に追加する。

例えば、第２のポジションがどの第１のポジションに属するかを示すデータは、予めデータ記憶部３００等に記憶されているものとする。追加部３０５は、当該データに基づいて、参加要求をしたユーザが所望する第２のポジションが属する第１のポジションを特定し、当該第１のポジションと関連付けて、ユーザ情報を参加登録データＤＴ３に追加することになる。

役割決定部３１１は、制御部３１Ｃを主として実現される。役割決定部３１１は、参加登録データＤＴ３に基づいて、選択部３０６により選択された複数のユーザの各々が担当する第２のポジションを決定する。例えば、役割決定部３１１は、第１のポジションに属する複数の第２のポジションの中からランダムに決定してもよいし、キャラクタに関連付けられた第２のポジションに基づいて決定してもよい。

実施形態３の変形例によれば、参加要求をしたユーザが所望する第２のポジションよりも広い第１のポジションと関連付けて、当該ユーザのユーザ情報を参加登録データＤＴ３に追加することで、ユーザが集まりやすくなるので、マッチングまでの時間を早めることができる。

［４．その他変形例］
なお、本発明は、以上に説明した実施の形態に限定されるものではない。本発明の趣旨を逸脱しない範囲で、適宜変更可能である。

例えば、ゲーム端末１０においてゲームの主な処理が実行されて、ゲーム端末１０が本発明に係るゲーム制御装置に相当してもよいし、サーバ３０においてゲームの主な処理が実行され、サーバ３０が本発明に係るゲーム制御装置に相当してもよい。また例えば、ゲーム端末１０とサーバ３０とで各機能が分担されてもよい。この場合、ゲーム端末１０とサーバ３０とで処理結果を送受信すればよい。

また例えば、サーバ３０において実現される各機能は、ゲーム端末１０において実現されてもよい。例えば、データ記憶部３００がゲーム端末１０において実現され、ユーザデータＤＴ２が記憶部１２に記憶されてもよい。また例えば、規則情報生成部３０１及び規則情報送信部３０２がゲーム端末１０において実現され、制御部１１が乱数シードを生成したり他のゲーム端末１０に乱数シードを送信したりしてもよい。

また例えば、制限部１１７がサーバ３０において実現されてもよい。例えば、制限部１１７がゲームサーバ３０Ｄで実現されてもよく、この場合、制御部３１Ｄにより、メッセージの出力が制限されてもよい。例えば、ゲームサーバ３０Ｄの制限部１１７は、ゲーム端末１０に対してメッセージを送信しないことによって、メッセージの出力を制限してもよい。

また例えば、受付部３０３がゲーム端末１０で実現されてもよい。この場合、受付部３０３は、制御部１１を主として実現され、操作部１４の検出信号に基づいて参加要求を受け付けることになる。また例えば、役割取得部３０４がゲーム端末１０で実現されてもよい。この場合、役割取得部３０４は、制御部１１を主として実現され、操作部１４の検出信号に基づいて所望するポジションを取得してもよいし、記憶部１２に記憶されたポジションを取得してもよい。また例えば、追加部３０５がゲーム端末１０で実現されてもよい。この場合、追加部３０５は、制御部１１を主として実現され、ユーザ情報をキューに追加する旨の要求をサーバ３０に送信してもよい。また例えば、選択部３０６がゲーム端末１０で実現されてもよい。この場合、選択部３０６は、制御部１１を主として実現され、サーバ３０から参加登録データＤＴ３を取得してマッチングを実行してもよい。

また例えば、サッカーゲームが実行される場合を説明したが、他のゲームに本発明に係る処理を適用してもよい。例えば、他のスポーツゲーム（例えば、野球、テニス、アメリカンフットボール、バスケットボール、バレーボール等を題材としたゲーム）に本発明に係る処理を適用してもよい。また例えば、カードゲームやスポーツゲーム以外にも、アクションゲーム・ロールプレイングゲーム・格闘ゲーム等のように、ゲーム形式・ジャンルを問わず種々のゲームに本発明に係る処理を適用してもよい。

［５．付記］
以上のような記載から、本発明は例えば以下のように把握される。

［５−１．実施形態１に係る発明］
１−１）本発明の一態様に係るゲームシステム（Ｓ）は、複数のゲーム実行手段（１００）を含むゲームシステム（Ｓ）であって、各ゲーム実行手段（１００）は、ゲームが開始される場合に、複数のユーザ情報の各々に関連付けられたゲームデータを取得するゲームデータ取得手段（１０１）と、前記複数のゲーム実行手段（１００）で共通の乱数発生規則に基づいて発生される乱数を取得する乱数取得手段（１０３）と、前記ゲームの状況を示す状況データを記憶する記憶手段（１０４）と、各ユーザ情報に関連付けられた前記ゲームデータと前記乱数とに基づいて、前記複数のゲーム実行手段（１００）で共通のゲーム処理を実行することによって、前記状況データを更新する更新手段（１０５）と、前記状況データに基づいて、前記ゲームの状況を示すゲーム画像を表示手段（１５）に表示させる表示制御手段（１０６）と、を含む。

１−９）本発明の一態様に係るゲーム端末（１０）は、複数のゲーム実行手段（１００）のうちの少なくとも１つを含むゲーム端末（１０）であって、各ゲーム実行手段（１００）は、ゲームが開始される場合に、複数のユーザ情報の各々に関連付けられたゲームデータを取得するゲームデータ取得手段（１０１）と、前記複数のゲーム実行手段（１００）で共通の乱数発生規則に基づいて発生される乱数を取得する乱数取得手段（１０３）と、前記ゲームの状況を示す状況データを記憶する記憶手段（１０４）と、各ユーザ情報に関連付けられた前記ゲームデータと前記乱数とに基づいて、前記複数のゲーム実行手段（１００）で共通のゲーム処理を実行することによって、前記状況データを更新する更新手段（１０５）と、前記状況データに基づいて、前記ゲームの状況を示すゲーム画像を表示手段（１５）に表示させる表示制御手段（１０６）と、を含む。

１−１０）本発明の一態様に係るプログラムは、１−１）〜１−８）の何れかに記載のゲームシステム（Ｓ）又は１−９）に記載のゲーム端末（１０）としてコンピュータを機能させる。

１−１１）本発明の一態様に係る情報記憶媒体は、１−１０）のプログラムを記録したコンピュータで読み取り可能な情報記憶媒体である。

１−１）又は１−９）〜１−１１）に係る発明によれば、ゲームが開始される場合に取得されたゲームデータと、複数のゲーム実行手段で共通の乱数発生規則に基づいて発生される乱数と、に基づいて、複数のゲーム実行手段で共通のゲーム処理を実行することによって状況データが更新され、状況データの整合を取らなくても状況データが同じ内容になるので、通信負荷を軽減することができる。また、ゲームで使用されるゲームデータの組み合わせが同じだった場合、乱数を使用しなかったとすると毎回同じゲーム結果となってしまい、ユーザが飽きてしまう可能性があるが、乱数を使用してランダム要素を入れることで、ゲームデータの組み合わせが同じだったとしてもゲーム結果に変化をつけることができる。また、通信障害やアプリケーション終了等の理由により、一部のゲーム実行手段でゲームが途中終了したとしても、各ゲーム実行手段が状況データを更新するので、他のゲーム実行手段はゲームを最後まで実行することができる。

１−２）本発明の一態様では、各ゲーム実行手段（１００）は、前記乱数発生規則に関する規則情報を取得する規則情報取得手段（１０２）を更に含み、前記乱数取得手段（１０３）は、前記規則情報に基づいて前記乱数を発生させる。１−２）の態様によれば、各ゲーム実行手段が、ゲームが開始される場合に、複数のゲーム実行手段で共通の乱数発生規則に関する規則情報に基づいて乱数を発生させることで、複数のゲーム実行手段で共通の乱数とし、状況データを整合しなくても、他のゲーム実行手段と同じ内容の状況データを取得させることができる。また、各ゲーム実行手段が、サーバコンピュータなどから乱数のリストを取得する場合には、一応は同じ乱数を使って状況データを更新することができるが、乱数のリストを送信する分の通信負荷が発生する。この点、１−２）の態様は、各ゲーム実行手段が、規則情報を使って自分で乱数を発生させることで、乱数のリストを送信する必要がなくなるので、通信負荷を効果的に軽減することができる。

１−３）本発明の一態様では、前記ゲームシステム（Ｓ）は、マッチングを実行するためのサーバを更に含み、前記サーバは、マッチングが実行された場合に、時間情報に基づいて前記規則情報を生成する規則情報生成手段（３０１）と、各ゲーム実行手段（１００）に対し、前記規則情報を送信する規則情報送信手段（３０２）と、を含み、前記規則情報取得手段（１０２）は、前記規則情報送信手段（３０２）により送信された前記規則情報を取得する。１−３）の態様によれば、マッチングが実行された場合に、時間情報に基づいて規則情報を生成することで、マッチングのたびに異なる規則情報を生成し、各ゲーム実行手段に取得させる乱数を異ならせることができるので、ゲームの結果が毎回同じになりゲームの興趣性が低下するといったことを確実に防止することができる。

１−４）本発明の一態様では、前記規則情報は、前記乱数発生規則に入力される乱数シードである。１−４）の態様によれば、乱数シードを用いることで、複数のゲーム実行手段で共通の乱数を確実に発生させ、状況データを整合しなくても、他のゲーム実行手段と同じ内容の状況データを取得させることができる。

１−５）本発明の一態様では、前記乱数取得手段（１０３）は、前記状況データを更新するための複数の更新タイミングの各々が訪れるたびに、前記乱数発生規則に基づいて発生される乱数列から順番に前記乱数を取得し、前記更新手段（１０５）は、各更新タイミングが訪れるたびに、前記乱数列から順番に取得された前記乱数に基づいて、前記状況データを更新する。１−５）の態様によれば、複数の更新タイミングの各々が訪れるたびに、乱数発生規則に基づいて発生される乱数列から順番に取得された乱数に基づいて状況データを更新することにより、乱数が状況データに複数回影響してランダム要素が高まるので、ゲームの興趣性を効果的に高めることができる。

１−６）本発明の一態様では、各ゲーム実行手段（１００）は、前記状況データに基づいて、前記ゲームが第１の状況になったか否かを判定する第１判定手段（１０７）と、前記ゲームが第１の状況になったと判定された場合に、他のゲーム実行手段（１００）における前記ゲームが前記第１の状況になるまで、前記状況データの更新を一時停止させる第１停止手段（１０８）と、他のゲーム実行手段（１００）における前記ゲームが前記第１の状況になった場合に、前記状況データの更新を再開させる第１再開手段（１０９）と、を更に含む。１−６）の態様によれば、ゲームが第１の状況になった場合に、他のゲーム実行手段におけるゲームが第１の状況になるまでは状況データの更新を一時停止し、他のゲーム実行手段におけるゲームが第１の状況になった場合に状況データの更新を再開することによって、ゲーム実行手段間でゲームの進行を合わせることができる。ゲームの進行を合わせることで、例えば、ゲームの終了時点を合わせることができたり、ゲーム実行中のチャット時に話が噛みあわないといったことを防止したりすることができる。

１−７）本発明の一態様では、前記第１の状況は、前記ゲームにおいて、所定の処理が実行された回数が閾値以上になることである。１−７）の態様によれば、所定の処理が実行された回数が閾値以上になった場合に、状況データの更新を一時停止して、ゲーム実行手段間でゲームの進行を合わせることで、より確実にゲームの進行を合わせることができる。例えば、所定の処理として、進行がずれそうな処理（端末の性能によって処理時間に差が出そうな処理）を定めておくことで、ゲームの進行が大幅にずれるといったことを防止することができる。また例えば、閾値を２以上に設定しておく場合には、所定の処理が発生したとしても、その回数が閾値以上になるまでは状況データの更新が一時停止しないので、所定の処理が発生するたびにゲームが一時停止するといったことを防止でき、ゲームの進行をスムーズにすることができる。

１−８）本発明の一態様では、各ゲーム実行手段（１００）は、前記状況データに基づいて、前記ゲームが第２の状況になったか否かを判定する第２判定手段（１１０）と、前記ゲームが前記第２の状況になったと判定された場合に、前記状況データの更新を一時停止させる第２停止手段（１１１）と、前記状況データの更新が一時停止された場合に、当該各ゲーム実行手段（１００）のうちの１又は複数のゲーム実行手段（１００）に対応するユーザ情報に関連付けられた前記ゲームデータを変更する変更手段（１１２）と、前記変更手段（１１２）により変更されたゲームデータを他のゲーム実行手段（１００）に送信するゲームデータ送信手段（１１３）と、他のゲーム実行手段（１００）の前記変更手段（１１２）により変更されたゲームデータを受信するゲームデータ受信手段（１１４）と、自身の前記変更手段（１１２）により変更されたゲームデータと、他のゲーム実行手段（１００）の前記変更手段（１１２）により変更されたゲームデータと、に基づいて、前記状況データの更新を再開させる第２再開手段（１１５）と、を更に含む。１−８）の態様によれば、ゲーム終了まで全く介入できないのではなく、ゲームの途中でゲームデータの変更をさせることで、ゲームの興趣性を効果的に高めることができる。

［５−２．実施形態２に係る発明］
２−１）本発明の一態様に係るゲームシステム（Ｓ）は、複数のゲーム実行手段（１００）を含むゲームシステム（Ｓ）であって、各ゲーム実行手段（１００）は、ゲームの状況を示す状況データを記憶する記憶手段（１０４）と、前記複数のゲーム実行手段（１００）で共通のゲーム処理を実行することによって、前記状況データを更新する更新手段（１０５）と、前記状況データに基づいて、ゲーム画像を表示手段に表示させる表示制御手段（１０６）と、他のゲーム実行手段（１００）において入力されたメッセージを受信する受信手段（１１６）と、前記メッセージを出力する出力手段（１１８）と、を含み、前記ゲームシステム（Ｓ）は、実行中の前記ゲームの進行状況が、前記他のゲーム実行手段（１００）で前記メッセージが入力された場合の進行状況になるまで、前記メッセージの出力を制限する制限手段（１１７）、を含む。

２−８）本発明の一態様に係るゲーム端末は、複数のゲーム実行手段（１００）のうちの少なくとも１つを含むゲーム端末であって、各ゲーム実行手段（１００）は、ゲームの状況を示す状況データを記憶する記憶手段（１０４）と、他のゲーム実行手段（１００）と共通のゲーム処理を実行することによって、前記状況データを更新する更新手段（１０５）と、前記状況データに基づいて、ゲーム画像を表示手段に表示させる表示制御手段（１０６）と、他のゲーム実行手段（１００）において入力されたメッセージと、前記メッセージが入力された場合の前記他のゲーム実行手段（１００）で実行中の前記ゲームの進行状況を示す進行情報と、を受信する受信手段（１１６）と、前記メッセージを出力する出力手段（１１８）と、実行中の前記ゲームの進行状況が、受信した前記進行情報が示す進行状況になるまで、前記メッセージの出力を制限する制限手段（１１７）と、を含む。

２−９）本発明の一態様に係るプログラムは、２−１）〜２−８）の何れかに記載のゲーム実行手段（１００）としてコンピュータを機能させる。

２−１０）本発明の一態様に係る情報記憶媒体は、２−９）のプログラムを記録したコンピュータで読み取り可能な情報記憶媒体である。

２−１）又は２−８）〜２−１０）に係る発明によれば、実行中のゲームが、他のゲーム実行手段でメッセージが入力された場合の進行状況になるまで、メッセージの出力を制限することで、ゲーム進行が遅いゲーム実行手段のユーザが、ゲーム進行が早いゲーム実行手段のユーザのメッセージの内容から今後の展開を予想するといったことを防止できるので、ゲームの興趣性の低下を防止することができる。また、ゲーム進行が遅いゲーム実行手段に、ゲーム進行が早いゲーム実行手段のユーザのメッセージを表示させると、ゲーム進行の違いによって話がかみ合わないといったことが生じるが、２−１）又は２−８）〜２−１０）に係る発明では、このようなことを防止し、複数のユーザの話をかみ合わせることができる。また、各ゲーム実行手段で共通のゲーム処理を実行することによって状況データを更新することで、複数のユーザがゲームに参加する場合の通信負荷を軽減することもできる。

２−２）本発明の一態様では、前記制限手段（１１７）は、実行中の前記ゲームの進行状況が、前記他のゲーム実行手段（１００）で前記メッセージが入力された場合の進行状況に既になっている場合は、前記メッセージの出力を制限せずに、前記メッセージを出力させる。２−２）の態様によれば、実行中のゲームの進行状況が他のゲーム実行手段でメッセージが入力された場合の進行状況に既になっている場合には、当該メッセージの出力を制限せずに出力することで、進行が遅れている他のユーザが入力したメッセージをユーザに迅速に把握させることができる。このため、進行が遅れている他のユーザのメッセージが出力されないといったことを防止することができる。

２−３）本発明の一態様では、前記状況データは、前記ゲーム内の時間を示す時間情報を含み、前記制限手段（１１７）は、実行中の前記ゲーム内の時間が、前記他のゲーム実行手段（１００）で前記メッセージが入力された場合の前記ゲーム内の時間になるまで、前記メッセージの出力を制限する。２−３）の態様によれば、ゲーム内の時間を示す時間情報を利用することで、実行中のゲームの進行状況が、他のゲーム実行手段でメッセージが入力された場合の進行状況になっているか否かをより簡易な処理によって判定することができるので、ゲーム実行手段の処理負荷を軽減することができる。

２−４）本発明の一態様では、前記制限手段（１１７）は、所定数以上のメッセージが入力された場合は、当該所定数以上のメッセージの全部又は一部のメッセージの出力を制限する。２−４）の態様によれば、所定数以上のメッセージが入力された場合に、所定数以上のメッセージの全部又は一部のメッセージの出力が制限されることで、多数のメッセージが出力されることを防止できる。

２−５）本発明の一態様では、各ゲーム実行手段（１００）は、前記ゲームが開始される場合に、複数のユーザ情報の各々に関連付けられたゲームデータを取得するゲームデータ取得手段（１０１）と、前記複数のゲーム実行手段（１００）で共通の乱数発生規則に基づいて発生される乱数を取得する乱数取得手段（１０３）と、を更に含み、前記更新手段（１０５）は、各ユーザ情報に関連付けられた前記ゲームデータと前記乱数とに基づいて、前記ゲーム処理を実行することによって、前記状況データを更新する。２−５）の態様によれば、ゲームが開始される場合に取得されたゲームデータと、複数のゲーム実行手段で共通の乱数発生規則に基づいて発生される乱数と、に基づいて、複数のゲーム実行手段で共通のゲーム処理を実行することによって状況データが更新され、ゲーム実行手段間で状況データの整合を取らなくても状況データが同じ内容になるので、複数のユーザがゲームに参加する場合の通信負荷を軽減することができる。また、ゲームで使用されるゲームデータの組み合わせが同じだった場合、乱数を使用しなかったとすると毎回同じゲーム結果となってしまい、ユーザが飽きてしまう可能性があるが、乱数を使用してランダム要素を入れることで、ゲームデータの組み合わせが同じだったとしてもゲーム結果に変化をつけることができる。また、通信障害やアプリケーション終了等の理由により、一部のユーザがゲームを途中終了させたとしても、各ユーザ端末内で状況データが更新されるので、他のユーザはゲームを最後まで続けることができる。

２−６）本発明の一態様では、前記出力手段（１１８）は、実行中の前記ゲームの進行状況が、前記他のゲーム実行手段（１００）で前記メッセージが入力された場合の進行状況に既になっている場合は、前記メッセージが入力された場合の進行状況を示す情報とともに、前記メッセージを出力する。２−６）の態様によれば、実行中のゲームが、他のゲーム実行手段でメッセージが入力された場合の進行状況に既になっている場合に、当該進行状況を示す情報とともにメッセージが表示されるので、どの時点で他のユーザが入力したメッセージなのかをユーザに把握させることができる。

２−７）本発明の一態様では、各ゲーム実行手段（１００）は、前記制限手段（１１７）を含み、前記受信手段（１１６）は、前記メッセージが入力された場合の前記他のゲーム実行手段（１００）で実行中の前記ゲームの進行状況を示す進行情報を受信し、前記制限手段（１１７）は、実行中の前記ゲームの進行状況が、受信した前記進行情報が示す進行状況になるまで、前記メッセージの出力を制限する。２−７）の態様によれば、各ゲーム実行手段にメッセージの出力を制限する処理を実行させることで、例えば、ゲームシステム内のサーバの処理負荷を軽減することができる。

［５−３．実施形態３に係る発明］
３−１）本発明の一態様に係るゲームシステム（Ｓ）は、複数のユーザが役割を分担して参加するゲームを実行するゲームシステム（Ｓ）であって、各ユーザによる、前記ゲームへの参加要求を受け付ける受付手段（３０３）と、複数の役割のうち、前記参加要求をしたユーザが所望する役割を取得する役割取得手段（３０４）と、各役割と、前記ゲームへの参加を登録している参加登録ユーザのユーザ情報と、が関連付けられた参加登録データに、前記参加要求をしたユーザのユーザ情報を、当該ユーザが所望する役割と関連付けて追加する追加手段（３０５）と、前記ゲームに参加する複数のユーザを選択する手段（３０６）であって、前記参加登録データに基づいて、前記役割ごとに、当該役割を担当するユーザを、当該役割に前記ユーザ情報が関連付けられた前記参加登録ユーザの中から選択する選択手段（３０６）と、を含む。

３−１０）本発明の一態様に係るゲーム制御装置（１０，３０）は、複数のユーザが役割を分担して参加するゲームを実行するゲーム制御装置（１０，３０）であって、各ユーザによる、前記ゲームへの参加要求を受け付ける受付手段（３０３）と、複数の役割のうち、前記参加要求をしたユーザが所望する役割を取得する役割取得手段（３０４）と、各役割と、前記ゲームへの参加を登録している参加登録ユーザのユーザ情報と、が関連付けられた参加登録データに、前記参加要求をしたユーザのユーザ情報を、当該ユーザが所望する役割と関連付けて追加する追加手段（３０５）と、前記ゲームに参加する複数のユーザを選択する手段（３０６）であって、前記参加登録データに基づいて、前記役割ごとに、当該役割を担当するユーザを、当該役割に前記ユーザ情報が関連付けられた前記参加登録ユーザの中から選択する選択手段（３０６）と、を含む。

３−１１）本発明の一態様に係るプログラムは、３−１）〜３−９）の何れかに記載のゲームシステム（Ｓ）又は３−１０）に記載のゲーム制御装置（１０，３０）としてコンピュータを機能させる。

３−１２）本発明の一態様に係る情報記憶媒体は、３−１１）のプログラムを記録したコンピュータで読み取り可能な情報記憶媒体である。

３−１）又は３−１０）〜３−１２）に係る発明によれば、ゲームへの参加要求をしたユーザのユーザ情報を、当該ユーザが所望する役割と関連付けて参加登録データに追加して、役割ごとに、当該役割を担当するユーザを、当該役割にユーザ情報が関連付けられた参加登録ユーザの中から選択することで、例えば、ユーザが所望する役割を他のユーザに取られたり、所望する役割が空いている対戦部屋をいちいち探したりすることがなくなるので、ユーザが所望の役割を担当するための手間を軽減することができる。

３−２）本発明の一態様では、前記ゲームシステム（Ｓ）は、前記参加登録データに基づいて、各役割の参加登録状況を各ユーザに提示する提示手段（３０７）、を更に含む。各役割を所望するユーザが集まるまでゲームに参加するユーザの選択が行われないといった場合には、参加要求をしたユーザが待機する状態が続き、ユーザがいつまで待てばよいか分からずに不満を感じる可能性があるが、３−２）の態様によれば、各役割の参加登録状況が提示され、マッチングまでどの程度時間がかかるかを予め予測させるといったことができるので、ユーザの不満を解消することができる。

３−３）本発明の一態様では、前記複数の役割は、予め定められた役割の組み合わせに基づいて決定される。３−３）の態様によれば、予め定められた役割の組み合わせに基づいて複数の役割が決定されることで、複数の役割を決める手間を省くことができる。他にも例えば、複数種類の組み合わせを用意しておき、時期に応じて使用する組み合わせを変えるようにした場合には、時期によって役割に変化を与えることができ、ゲームの興趣性を向上させることができる。

３−４）本発明の一態様では、前記ゲームシステム（Ｓ）は、前記参加登録状況が提示されたユーザの操作に基づいて、当該ユーザが所望する役割を変更する役割変更手段（３０８）を更に含む。
３−４）の態様によれば、参加登録状況が提示されたユーザが所望する役割を変更することで、例えば、比較的空いている役割に変更して待ち時間を減らすといったことができ、ユーザの不満を効果的に解消することができる。

３−５）本発明の一態様では、前記ゲームでは、各ユーザのゲームオブジェクトが使用され、前記役割取得手段（３０４）は、前記参加要求をしたユーザのゲームオブジェクトと関連付けられた役割を、当該ユーザが所望する役割として取得する。３−５）の態様によれば、参加要求をしたユーザのゲームオブジェクトと関連付けられた役割を当該ユーザが所望する役割とすることで、ユーザがゲームに参加する前に所望する役割をいちいち選択しなくても済むので、ユーザの手間を効果的に軽減することができる。

３−６）本発明の一態様では、前記追加手段（３０５）は、前記参加要求をしたユーザが所望する役割が複数ある場合には、前記参加登録データに基づいて、当該ユーザが所望する複数の役割の中から選択した少なくとも１つの役割と関連付けて、当該ユーザのユーザ情報を前記参加登録データに追加する。３−６）の態様によれば、参加登録データが示す各役割の参加登録状況を考慮したうえで、ユーザ情報を関連付ける役割を選択することで、例えば、比較的空いている役割にユーザ情報を追加するといったことができるので、マッチングまでの待ち時間（ゲーム開始までの待ち時間）を短縮することができる。

３−７）本発明の一態様では、前記選択手段（３０６）は、前記複数の役割をそれぞれ所望する複数のユーザが集まった場合に、当該複数のユーザを選択し、前記選択手段（３０６）は、所定時間が経過しても、前記複数の役割をそれぞれ所望する複数のユーザが集まらなかった場合には、現時点で集まったユーザを選択し、前記ゲームシステム（Ｓ）は、前記参加登録データに基づいて、前記所定時間の長さを変更する時間変更手段（３０９）、を更に含む。３−７）の態様によれば、参加登録データが示す各役割の参加登録状況が、ゲームに参加するユーザを選択するための所定時間の長さに反映されるので、ゲームに参加するユーザを選択するまでにユーザを長時間待たせるといったことを防止することができる。

３−８）本発明の一態様では、前記ゲームでは、各ユーザの複数のゲームオブジェクトのうち、当該ユーザが指定したゲームオブジェクトが使用され、前記選択手段（３０６）は、前記複数の役割をそれぞれ所望する複数のユーザが集まった場合に、当該複数のユーザを選択し、前記ゲームシステム（Ｓ）は、前記選択手段（３０６）により選択された複数のユーザの各々が指定したゲームオブジェクトに、当該ユーザが所望する役割を割り当てる役割割当手段（３１０）を更に含み、前記選択手段（３０６）は、所定時間が経過しても、前記複数の役割をそれぞれ所望する複数のユーザが集まらなかった場合には、現時点で集まったユーザを選択し、前記役割割当手段（３１０）は、前記複数の役割をそれぞれ所望する複数のユーザが集まらなかった場合には、前記選択手段（３０６）により選択された複数のユーザの各々が指定しなかったゲームオブジェクトの中から、ユーザが集まらなかった役割を割り当てるゲームオブジェクトを決定する。３−８）の態様によれば、所定時間が経過しても複数の役割をそれぞれ所望する複数のユーザが集まらなかった場合には、現時点で集まったユーザを選択することで、ユーザがいつまで待ってもゲームに参加できないといった不満を防止することができる。更に、ユーザが指定しなかったゲームオブジェクトの中から、ユーザが集まらなかった役割を担当させることで、全く関係のないゲームオブジェクトが使用されるのではなく、ユーザのゲームオブジェクトが使用されるので、ゲームの興趣性を向上させることができる。

３−９）本発明の一態様では、前記ゲームでは、複数の第１の役割と、当該複数の第１の役割の各々の何れか一又は複数の第１の役割に属する詳細な役割である一又は複数の第２の役割と、があり、前記役割取得手段（３０４）は、前記参加要求をしたユーザが所望する第２の役割を取得し、前記参加登録データには、前記複数の第１の役割の各々と、前記ゲームへの参加登録のユーザのユーザ情報と、が関連付けられており、前記追加手段（３０５）は、前記参加要求をしたユーザが所望する第２の役割が属する第１の役割と関連付けて、当該ユーザのユーザ情報を前記参加登録データに追加し、前記ゲームシステム（Ｓ）は、前記参加登録データに基づいて、前記選択手段（３０６）により選択された複数のユーザの各々が担当する第２の役割を決定する役割決定手段（３１１）を更に含む。３−９）の態様によれば、参加要求をしたユーザが所望する第２の役割よりも広い第１の役割と関連付けて、当該ユーザのユーザ情報を参加登録データに追加することで、ユーザが集まりやすくなるので、マッチングまでの時間を早めることができる。

Ｓ ゲームシステム、Ｎ ネットワーク、１０，１０Ａ，１０Ｂ ゲーム端末、３０ サーバ、３０Ａ ゲートサーバ、３０Ｂ 認証サーバ、３０Ｃ ロビーサーバ、３０Ｄ ゲームサーバ、１１，１１Ａ，１１Ｂ，３１，３１Ａ，３１Ｂ，３１Ｃ，３１Ｄ 制御部、１２，１２Ａ，１２Ｂ，３２，３２Ａ，３２Ｂ，３２Ｃ，３２Ｄ 記憶部、１３，１３Ａ，１３Ｂ，３３，３３Ａ，３３Ｂ，３３Ｃ，３３Ｄ 通信部、１４，１４Ａ，１４Ｂ 操作部、１５，１５Ａ，１５Ｂ 表示部、１００ ゲーム実行部、１０１ ゲームデータ取得部、１０２ 規則情報取得部、１０３ 乱数取得部、１０４ データ記憶部、１０５ 更新部、１０６ 表示制御部、１０７ 第１判定部、１０８ 第１停止部、１０９ 第１再開部、１１０ 第２判定部、１１１ 第２停止部、１１２ 変更部、１１３ ゲームデータ送信部、１１４ ゲームデータ受信部、１１５ 第２再開部、１１６ メッセージ受信部、１１７ 制限部、１１８ 出力部、３００ データ記憶部、３０１ 規則情報生成部、３０２ 規則情報送信部、３０３ 受付部、３０４ 役割取得部、３０５ 追加部、３０６ 選択部、３０７ 提示部、３０８ 役割変更部、３０９ 時間変更部、３１０ 役割割当部、３１１ 役割決定部、Ａ１０，Ａ１１，Ａ３０，Ａ３１，Ａ４０，Ａ４１，Ａ６０，Ａ６１，Ａ７０，Ａ７１ 表示領域、Ｂ１２，Ｂ１３，Ｂ１４，Ｂ１５，Ｂ１６，Ｂ２０，Ｂ２１，Ｂ２２，Ｂ２３，Ｂ３２，Ｂ３３，Ｂ４３，Ｂ６２，Ｂ７２，Ｂ７１０，Ｂ７３０ ボタン、ＤＴ１ 状況データ，ＤＴ２ ユーザデータ，ＤＴ３ 参加登録データ，Ｍ６４ メッセージ，Ｗ６３，Ｗ７３ ウィンドウ、Ｇ１ マイページ画像、Ｇ２ 試合メニュー画像、Ｇ３ 個別対戦画像、Ｇ４ チーム情報画像、Ｇ５ マッチング画像、Ｇ６ 対戦画像、Ｇ７ カード選択画像。

Claims (11)

1. 複数のユーザが役割を分担して参加するゲームを実行するゲームシステムであって、
   各ユーザによる、前記ゲームへの参加要求を受け付ける受付手段と、
   複数の役割のうち、前記参加要求をしたユーザが所望する役割を取得する役割取得手段と、
   各役割と、前記ゲームへの参加を登録している参加登録ユーザのユーザ情報と、が関連付けられた参加登録データに、前記参加要求をしたユーザのユーザ情報を、当該ユーザが所望する役割と関連付けて追加する追加手段と、
   前記ゲームに参加する複数のユーザを選択する手段であって、前記参加登録データに基づいて、前記役割ごとに、当該役割を担当するユーザを、当該役割に前記ユーザ情報が関連付けられた前記参加登録ユーザの中から選択する選択手段と、
   を含むゲームシステム。
2. 前記ゲームシステムは、前記参加登録データに基づいて、各役割の参加登録状況を各ユーザに提示する提示手段、
   を更に含む請求項１に記載のゲームシステム。
3. 前記複数の役割は、予め定められた役割の組み合わせに基づいて決定される、
   請求項１又は２に記載のゲームシステム。
4. 前記ゲームシステムは、前記参加登録状況が提示されたユーザの操作に基づいて、当該ユーザが所望する役割を変更する役割変更手段を更に含む、
   請求項２に記載のゲームシステム。
5. 前記ゲームでは、各ユーザのゲームオブジェクトが使用され、
   前記役割取得手段は、前記参加要求をしたユーザのゲームオブジェクトと関連付けられた役割を、当該ユーザが所望する役割として取得する、
   請求項１〜４の何れか１項に記載のゲームシステム。
6. 前記追加手段は、前記参加要求をしたユーザが所望する役割が複数ある場合には、前記参加登録データに基づいて、当該ユーザが所望する複数の役割の中から選択した少なくとも１つの役割と関連付けて、当該ユーザのユーザ情報を前記参加登録データに追加する、
   請求項１〜５の何れか１項に記載のゲームシステム。
7. 前記選択手段は、前記複数の役割をそれぞれ所望する複数のユーザが集まった場合に、当該複数のユーザを選択し、
   前記選択手段は、所定時間が経過しても、前記複数の役割をそれぞれ所望する複数のユーザが集まらなかった場合には、現時点で集まったユーザを選択し、
   前記ゲームシステムは、前記参加登録データに基づいて、前記所定時間の長さを変更する時間変更手段、
   を更に含む請求項１〜６の何れか１項に記載のゲームシステム。
8. 前記ゲームでは、各ユーザの複数のゲームオブジェクトのうち、当該ユーザが指定したゲームオブジェクトが使用され、
   前記選択手段は、前記複数の役割をそれぞれ所望する複数のユーザが集まった場合に、当該複数のユーザを選択し、
   前記ゲームシステムは、前記選択手段により選択された複数のユーザの各々が指定したゲームオブジェクトに、当該ユーザが所望する役割を割り当てる役割割当手段を更に含み、
   前記選択手段は、所定時間が経過しても、前記複数の役割をそれぞれ所望する複数のユーザが集まらなかった場合には、現時点で集まったユーザを選択し、
   前記役割割当手段は、前記複数の役割をそれぞれ所望する複数のユーザが集まらなかった場合には、前記選択手段により選択された複数のユーザの各々が指定しなかったゲームオブジェクトの中から、ユーザが集まらなかった役割を割り当てるゲームオブジェクトを決定する、
   請求項１〜７の何れか１項に記載のゲームシステム。
9. 前記ゲームでは、複数の第１の役割と、当該複数の第１の役割の各々の何れか一又は複数の第１の役割に属する詳細な役割である一又は複数の第２の役割と、があり、
   前記役割取得手段は、前記参加要求をしたユーザが所望する第２の役割を取得し、
   前記参加登録データには、前記複数の第１の役割の各々と、前記ゲームへの参加登録のユーザのユーザ情報と、が関連付けられており、
   前記追加手段は、前記参加要求をしたユーザが所望する第２の役割が属する第１の役割と関連付けて、当該ユーザのユーザ情報を前記参加登録データに追加し、
   前記ゲームシステムは、前記参加登録データに基づいて、前記選択手段により選択された複数のユーザの各々が担当する第２の役割を決定する役割決定手段を更に含む、
   請求項１〜８の何れか１項に記載のゲームシステム。
10. 複数のユーザが役割を分担して参加するゲームを実行するゲーム制御装置であって、
    各ユーザによる、前記ゲームへの参加要求を受け付ける受付手段と、
    複数の役割のうち、前記参加要求をしたユーザが所望する役割を取得する役割取得手段と、
    各役割と、前記ゲームへの参加を登録している参加登録ユーザのユーザ情報と、が関連付けられた参加登録データに、前記参加要求をしたユーザのユーザ情報を、当該ユーザが所望する役割と関連付けて追加する追加手段と、
    前記ゲームに参加する複数のユーザを選択する手段であって、前記参加登録データに基づいて、前記役割ごとに、当該役割を担当するユーザを、当該役割に前記ユーザ情報が関連付けられた前記参加登録ユーザの中から選択する選択手段と、
    を含むゲーム制御装置。
11. 請求項１〜９何れか１項に記載のゲームシステム、又は、請求項１０記載のゲーム制御装置、としてコンピュータを機能させるためのプログラム。
    

Images