特許法第30条第2項適用 平成29年10月30日、https://play.google.com/store/apps/details?id=jp.konami.weccにて公開
[1.実施形態1]
以下、本発明に係る実施形態を図面に基づいて説明する。なお、図面において同一又は対応する構成には同一の符号を付し、繰り返しの説明を省略することがある。
[1-1.ゲームシステムの全体構成]
図1は、ゲームシステムの全体構成を示す図である。図1に示すように、本実施形態に係るゲームシステムSは、ゲーム端末10A,10B、ゲートサーバ30A、認証サーバ30B、ロビーサーバ30C、及びゲームサーバ30Dを含む。ゲーム端末10A,10B、ゲートサーバ30A、認証サーバ30B、ロビーサーバ30C、及びゲームサーバ30Dの各々は、インターネットなどのネットワークNに接続される。
ゲーム端末10A,10Bは、コンピュータである。例えば、ゲーム端末10A,10Bは、携帯端末(例えば、スマートフォンなどの携帯電話又はタブレット型コンピュータ)、パーソナルコンピュータ、携帯ゲーム機、据置ゲーム機、業務用ゲーム機、又は、情報処理機能を備えた多機能型テレビジョン受像機(スマートテレビ)等である。
図1に示すように、ゲーム端末10Aは、制御部11A、記憶部12A、通信部13A、操作部14A、及び表示部15Aを含む。制御部11Aは、少なくとも1つのマイクロプロセッサを含む。
例えば、制御部11Aは、複数のマイクロプロセッサを含んでもよい。制御部11Aは、オペレーティングシステムやその他のプログラムに従って処理を実行する。記憶部12Aは、主記憶部(例えば、RAM)及び補助記憶部(例えば、不揮発性の半導体メモリ)を含む。記憶部12Aは、プログラムやデータを記憶する。なお、例えば、ゲーム端末10Aがパーソナルコンピュータ等である場合、記憶部12Aは、例えばハードディスクドライブ又はソリッドステートドライブ等の補助記憶部を含むようにしてもよい。通信部13Aは、通信モジュールや通信インタフェースを含む。通信部13Aは、ネットワークNを介してデータ通信を行う。
操作部14Aは、入力デバイスであり、例えば、キー、レバー、ゲームコントローラ(ゲームパッド)、マウスやタッチパネルなどのポインティングデバイス、又はキーボード等を含んでもよい。また例えば、操作部14Aは、ユーザが音声又はジェスチャによって入力操作を行うためのマイクやカメラを含んでもよい。表示部15Aは、例えば、液晶表示パネル又は有機ELディスプレイ等であり、制御部11の指示に従って画面を表示する。なお、操作部14A及び表示部15Aは、ゲーム端末10Aに内蔵されていなくともよく、ゲーム端末10Aに接続された外部装置であってもよい。
ゲーム端末10Bは、制御部11B、記憶部12B、通信部13B、操作部14B、及び表示部15Bを有する。制御部11B、記憶部12B、通信部13B、操作部14B、及び表示部15Bのハードウェア構成は、それぞれ制御部11A、記憶部12A、通信部13A、操作部14A、及び表示部15Aと同様であってよい。
なお、本実施形態では、ゲーム端末10A,10Bを特に区別する必要のないときは、単にゲーム端末10と記載する。また、制御部11A,11Bを区別する必要のないときは、単に制御部11と記載する。同様に、記憶部12A,12B、通信部13A,13B、操作部14A,14B、及び表示部15A,15Bを、単に記憶部12、通信部13、操作部14、及び表示部15と記載することもある。また、図1では、2台のゲーム端末10を例に挙げたが、ゲームシステムS内のゲーム端末10の台数に制限はなく、ゲーム端末10は、3台以上であってもよいし、1台だけであってもよい。
ゲートサーバ30Aは、サーバコンピュータである。図1に示すように、ゲートサーバ30Aは、制御部31A、記憶部32A、及び通信部33Aを含む。制御部31A、記憶部32A、及び通信部33Aのハードウェア構成は、それぞれ制御部11、記憶部12、及び通信部13と同様であってよい。例えば、ゲートサーバ30Aは、ゲームシステムS内のサーバコンピュータのリストを管理し、例えば、認証サーバ30B、ロビーサーバ30C、及びゲームサーバ30Dの各々のサーバ名やIPアドレス等の情報を管理する。
認証サーバ30Bは、サーバコンピュータである。図1に示すように、認証サーバ30Bは、制御部31B、記憶部32B、及び通信部33Bを含む。制御部31B、記憶部32B、及び通信部33Bのハードウェア構成は、それぞれ制御部11、記憶部12、及び通信部13と同様であってよい。例えば、認証サーバ30Bは、ユーザ情報等の認証情報に基づいてユーザ認証を実行する。
ロビーサーバ30Cは、サーバコンピュータである。図1に示すように、ロビーサーバ30Cは、制御部31C、記憶部32C、及び通信部33Cを含む。制御部31C、記憶部32C、及び通信部33Cのハードウェア構成は、それぞれ制御部11、記憶部12、及び通信部13と同様であってよい。例えば、ロビーサーバ30Cは、対戦におけるマッチングを実行する。
ゲームサーバ30Dは、サーバコンピュータである。図1に示すように、ゲームサーバ30Dは、制御部31D、記憶部32D、及び通信部33Dを含む。制御部31D、記憶部32D、及び通信部33Dのハードウェア構成は、それぞれ制御部11、記憶部12、及び通信部13と同様であってよい。例えば、ゲームサーバ30Dは、マッチング完了後にゲーム端末10が接続するサーバであり、対戦を実行する。
なお、本実施形態では、ゲートサーバ30A、認証サーバ30B、ロビーサーバ30C、及びゲームサーバ30Dを区別する必要のないときは、単にサーバ30と記載する。また、制御部31A~31Dを区別する必要のないときは、単に制御部31と記載する。同様に、記憶部32A~32Dを区別する必要のないときは、単に記憶部32と記載し、通信部33A~33Dを区別する必要のないときは、単に通信部33と記載する。
また、ゲームシステムS内のサーバの台数に制限はなく、ゲートサーバ30A、認証サーバ30B、ロビーサーバ30C、及びゲームサーバ30Dの各々は、2台以上であってもよい。また、1台のサーバ30が、ゲートサーバ30A、認証サーバ30B、ロビーサーバ30C、及びゲームサーバ30Dのうちの少なくとも2つ以上の機能を担ってもよい。ゲームシステムS内のサーバコンピュータは1台だけであってもよいし、図1に示すサーバ以外のコンピュータがゲームシステムSに含まれていてもよい。
なお、記憶部12,32に記憶されるものとして説明するプログラムやデータは、例えば、ネットワークNを介してゲーム端末10又はサーバ30に供給されるようにしてもよい。また、ゲーム端末10又はサーバ30は、情報記憶媒体(例えば、光ディスク又はメモリカード等)に記憶されたプログラム又はデータを読み取るための読取部(例えば、光ディスクドライブ又はメモリカードスロット)を含むようにしてもよい。そして、情報記憶媒体を介してゲーム端末10又はサーバ30にプログラムやデータが供給されるようにしてもよい。
[1-2.ゲームの概要]
本実施形態では、複数のユーザがそれぞれゲーム端末10を操作する。例えば、ゲームシステムSが第1のゲーム端末であるゲーム端末10Aと、第2のゲーム端末であるゲーム端末10Bと、を含む場合、ゲーム端末10Aを使用する第1ユーザと、第2ゲーム端末を使用する第2ユーザとが上記「複数のユーザ」に相当する。
ゲームシステムSで実行されるゲームは、任意のゲームであってよく、例えば、対戦ゲームであってもよい。また例えば、サッカーゲーム、野球ゲーム、バスケットボールゲーム、アイスホッケーゲーム、レースゲーム、格闘ゲーム、又はカードゲーム等であってもよい。これらのゲームに限られず、他の種類の対戦ゲームであってもよい。また例えば、対戦に限られず、共通の目的を達成することを目指す協力ゲームであってもよい。なお、目的とは、例えば、対戦に勝利すること、敵を退治すること、ゲームオブジェクトが所定の地点に到達すること、ゲーム評価が所定の基準を満たすこと、又はゲームアイテムを入手すること等である。また例えば、対戦相手チームとの試合に勝利することを目指すスポーツゲームであってもよい。また例えば、他のグループとの戦闘に勝利したり、特定の敵キャラクタを退治したり、又は、特定のゲームアイテムを入手したりすることを目指すアクションゲーム又はロールプレイングゲーム等であってもよい。
本実施形態では、ゲームの一例として、サッカーゲームを説明する。ゲーム端末10においてゲームプログラムが起動すると、ゲームのタイトル画像などが表示された後に、トップページに相当するマイページ画像が表示部15に表示される。
図2は、マイページ画像の一例を示す図である。図2に示すように、マイページ画像G1は、ポイントやコインなどのゲーム内通貨やチーム名を表示するための表示領域A10と、チームの代表選手を表示するための表示領域A11と、を含む。なお、マイページ画像G1に表示される情報は、これらに限られず、開催中のイベントなどの情報が表示されてもよい。
また、マイページ画像G1には、マイページ画像G1を表示させるためのボタンB12、対戦を実行するためのボタンB13、チームの編成をするためのボタンB14、チーム内のキャラクタを表示するためのボタンB15、及び、キャラクタが描かれたカードの抽選をするためのボタンB16が表示される。例えば、ボタンB13が選択されると、試合のメニューを示す試合メニュー画像が表示部15に表示される。
図3は、試合メニュー画像の一例を示す図である。図3に示すように、試合メニュー画像G2には、イベントに参加するためのボタンB20、コンピュータと対戦するためのボタンB21、1人対1人の対戦である個別対戦をするためのボタンB22、及び、複数人でチームを組むグループ対戦をするためのボタンB23が表示される。
本実施形態では、個別対戦について説明する。個別対戦では、あるユーザ情報に関連付けられたチーム情報と、他のユーザ情報に関連付けられたチーム情報と、に基づいて、対戦が実行される。チーム情報は、チームに所属するキャラクタが描かれたカードに関する情報を含み、例えば、キャラクタの名前、能力パラメータ、スキル、画像、及び3次元モデルといった情報を含む。
例えば、個別対戦は、操作部14に対する操作が介入されることなく、原則として自動進行する。即ち、各チームのキャラクタは、操作部14の検出信号に従って動作するのではなく、ゲームプログラムが決定した動作をする。例えば、ボタンB22が選択されると、個別対戦をするための個別対戦画像が表示部15に表示される。
図4は、個別対戦画像の一例を示す図である。図4に示すように、個別対戦画像G3は、チームのレベル情報やランク情報を表示するための表示領域A30と、個別対戦で勝利した場合の獲得ポイントやミッションの条件などを表示するための表示領域A31と、を含む。また例えば、個別対戦画像G3には、個別対戦を開始するためのボタンB32,B33が表示される。
本実施形態では、ポイントを消費することによって個別対戦が実行され、例えば、ボタンB32は、1ポイント消費して個別対戦を1回実行するためのボタンであり、ボタンB33は、全てのポイントを消費して個別対戦を複数回連続して実行するためのボタンである。
ここでは、ボタンB32が選択された場合の個別対戦の流れを説明するが、ボタンB33が選択された場合も、個別対戦が連続的に実行される点で異なるだけであり、個々の個別対戦の流れは、ボタンB32が選択された場合と同じである。ボタンB32が選択されると、チーム情報を表示するためのチーム情報画像が表示部15に表示される。
図5は、チーム情報画像の一例を示す図である。図5に示すように、チーム情報画像G4は、チーム名やチーム画像を表示するための表示領域A40と、チームの総合的な強さを示す総合値やフォーメーションなどの情報を表示するための表示領域A41,A42と、を含む。なお、チーム情報画像G4が表示されたばかりの時点では、まだマッチングが実行されていないので、対戦相手チームの情報は表示されない。また例えば、チーム情報画像G4には、個別対戦を開始するためのボタンB43が表示される。ボタンB43が選択されると、所定量のポイントが消費され、対戦相手を探すためのマッチングが開始される。マッチングの実行中は、マッチング画像が表示部15に表示される。
図6は、マッチング画像の一例を示す図である。図6に示すように、マッチング画像G5は、マッチング中であることを示すメッセージが表示される。マッチングが完了すると、対戦相手のチーム情報が表示された後に、個別対戦が開始される。個別対戦が開始されると、実行中の個別対戦の様子を示す対戦画像が表示部15に表示される。
図7は、対戦画像の一例を示す図である。図7に示すように、対戦画像G6は、各チームの名前と得点を表示するための表示領域A60と、ゲーム空間の現在の様子を表示するための表示領域A61と、を含む。本実施形態では、3次元のゲーム空間が構築され、ゲーム空間内の所定位置に仮想カメラが設定される。ゲーム空間に配置された各キャラクタやボールの3次元モデルが座標変換され、仮想カメラからゲーム空間を見た様子を示す画像が表示領域A61に表示される。
本実施形態では、原則として、ゲーム端末10Aとゲーム端末10Bとの間で、データの整合性(同期)を取ることなく、個別対戦が実行される。即ち、ゲーム端末10間で操作信号を送り合ったり、更新後のデータを送り合ったりすることなく、各ゲーム端末10で個別にデータの更新が実行される。
また、本実施形態では、各ゲーム端末10で同じ進行状況・試合結果とするために、ゲームサーバ30Dは、ゲームの開始時において、各ゲーム端末10に対し、共通の乱数シードを送信する。詳細は後述するが、乱数シードは、乱数列を生成するための情報であり、乱数シードが同じ値であれば、生成される乱数列も同じとなる。
ゲーム端末10A,10Bは、受信した乱数シードに基づいて乱数列を生成し、自身のゲームプログラムに基づいて、キャラクタの動作を決定する。ゲーム端末10A,10Bの各々において生成される乱数列が同じなので、キャラクタの動作結果も同じとなり、ゲーム端末10A,10Bで同じ処理結果が得られる。ただし、ゲーム端末10A,10Bで独自に個別対戦を実行させると、ゲーム端末10A,10Bの各々で進行にずれが生じる可能性がある。例えば、ゲーム端末10Aの方が、ゲーム端末10Bよりも高性能の場合、ゲーム端末10Aの進行が、ゲーム端末10Bよりも早くなることがある。
図8は、ゲーム端末10A,10Bの各々における個別対戦の進行を示す図である。図8の例では、ゲーム端末10Aの方が、ゲーム端末10Bよりも高性能とする。また、ゲーム端末10Aが実行するゲームプログラムを「ゲームプログラムA」と記載し、ゲーム端末10Bが実行するゲームプログラムを「ゲームプログラムB」と記載する。なお、図8は、ゲームの進行にずれが生じる場合を説明する図のため、ゲームサーバ30D等のサーバ30は省略している。
図8に示すように、ゲーム端末10AのゲームプログラムAと、ゲーム端末10BのゲームプログラムBと、の各々が同時に試合を開始したとしても、ゲーム端末10Aの方がゲーム端末10Bよりも高性能のため、ゲームプログラムAが実行する個別対戦の方が、進行が早い。例えば、前半10分にゴールが決まったとすると、ゴールシーンが発生するのは、ゲームプログラムAの方がゲームプログラムBよりも早い。また例えば、前半15分に反則が発生したとすると、反則が発生するのは、ゲームプログラムAの方がゲームプログラムBよりも早い。
このように、ゲームプログラムAとBで結果は同じとなるが、ゲームの進行はゲーム端末10Aの方が早くなり、ゲーム端末10AのゲームプログラムAが実行する個別対戦と、ゲーム端末10BのゲームプログラムBが実行する個別対戦と、の間で徐々に進行の差が大きくなる。進行のずれは、主に、コンピュータの性能の差に起因するため、計算量の多い処理が発生するほど、進行のずれが大きくなる。
例えば、サッカーゲームでは、ゴールが決まったり反則が発生したりすると、試合が一時的に停止するアウトオブプレイになるが、この場合にリプレイ映像を流したとすると、リプレイ映像は画像処理による計算量が高いため、アウトオブプレイが発生するほど進行のずれが大きくなる。
このため、本実施形態では、アウトオブプレイが発生した回数をカウントし、一定回数のアウトオブプレイが発生すると、個別対戦の進行を一時的に停止して、相手方の進行が追いつくまで待機する。図8の例であれば、例えば、ゲーム端末10AのゲームプログラムAは、アウトオブプレイが10回発生すると、個別対戦の進行を一時停止する。この間は、対戦画像G6の表示が変わらないようにしてもよいし、対戦画像G6の表示を止めてゲームに関係のない映像を流してもよい。その後、ゲーム端末10BのゲームプログラムBが実行する個別対戦の進行が追いついた場合に、ゲーム端末10AのゲームプログラムAは、個別対戦の進行を再開する。
上記のように、本実施形態のゲームシステムSは、複数のゲーム端末10で共通の乱数発生規則に基づいて発生される乱数を利用し、各ゲーム端末10で独自にゲーム処理を実行することで、通信を利用してデータの整合性を取ることなく、同じ対戦結果を得ることで、通信負荷を軽減するようになっている。また、アウトオブプレイが一定回数発生すると、相手方の進行が追いつくまで待機するようになっている。以降、当該構成の詳細を説明する。
[1-3.ゲームシステムで実現される機能]
図9は、ゲームシステムSで実現される機能のうち、本発明に関連する機能を示す機能ブロック図である。ここでは、ゲーム端末10で実現される機能と、サーバ30で実現される機能と、について説明する。
[1-3-1.ゲーム端末で実現される機能]
ゲームシステムSでは、複数のゲーム実行部100が実現される。例えば、ゲーム端末10は、複数のゲーム実行部100のうちの少なくとも1つを含む。ゲーム端末10に含まれるゲーム実行部100の数は、1つであってもよいし複数であってもよい。例えば、ゲームプログラム(アプリケーション)、ブラウザ、又は端末が、ゲーム実行部100に相当する。各ゲーム実行部100は、別々の端末内に存在してもよいし、1つの端末内に複数のゲーム実行部100が存在してもよい。なお、図9では、図面の簡略化のために、ゲーム実行部100を1つだけ図示する。
本実施形態では、各ゲーム端末10でゲーム実行部100が実現され、1台のゲーム端末10に対し、1つのゲーム実行部100が実現される場合を例に挙げる。ただし、1台のゲーム端末10内に複数のゲーム実行部100が存在してもよく、例えば、1台のゲーム端末10において、複数のブラウザが起動し、個々のブラウザがゲーム実行部100に相当してもよい。また例えば、1台のゲーム端末10において、複数のゲームプログラムが起動し、個々のゲームプログラムがゲーム実行部100に相当してもよい。
[ゲーム実行部]
ゲーム実行部100は、制御部11及び記憶部12を主として実現される。ゲーム実行部100は、ゲームを実行する。ゲームを実行するとは、例えば、ゲームプログラムを実行し、プログラムコードに記述された各種処理を実行することである。処理としては、例えば、キャラクタやボールなどのオブジェクトを移動させる処理、パラメータを変化させる処理、キャラクタのスキルを発動させる処理などの任意の処理であってよい。例えば、ゲーム実行部100は、プログラムコードに記述された処理の実行結果に基づいて、後述する状況データを更新する。
本実施形態では、ゲーム実行部100は、ゲームデータ取得部101、規則情報取得部102、乱数取得部103、データ記憶部104、更新部105、表示制御部106、第1判定部107、第1停止部108、第1再開部109、第2判定部110、第2停止部111、変更部112、ゲームデータ送信部113、ゲームデータ受信部114、及び第2再開部115を含む。
[ゲームデータ取得部]
ゲームデータ取得部101は、ゲームが開始される場合に、複数のユーザ情報の各々に関連付けられたゲームデータを取得する。例えば、ゲームデータは、後述するサーバ30のデータ記憶部300に記憶されているので、ゲームデータ取得部101は、データ記憶部300からゲームデータを取得する。
なお、ゲームデータは、ゲーム端末10のデータ記憶部104に記憶されていてもよく、この場合、ゲームデータ取得部101は、データ記憶部104からゲームデータを取得する。他にも例えば、ゲームデータは、ゲーム端末10及びサーバ30以外のコンピュータに記憶されていてもよく、この場合、ゲームデータ取得部101は、当該コンピュータからゲームデータを取得する。
ゲームが開始される場合とは、例えば、マッチングが完了した時点、又は、マッチングが完了した後の任意の時点であってよい。マッチングが完了するとは、例えば、対戦におけるユーザ情報の組み合わせが決定されること、当該ユーザ情報に関連付けられたゲームデータが決定されることである。なお、ここでのマッチングとは、例えば、ゲームに参加するユーザのユーザ情報(例えば、ユーザID)やゲームで用いられるゲームデータ(ここでは、チーム情報)の組み合わせを決めることである。例えば、マッチングは、あるユーザと対戦又は協力する他のユーザのユーザ情報や当該ユーザ情報に関連付けられたゲームデータを決めることである。
ユーザ情報とは、例えば、ユーザに関する情報である。例えば、ユーザ情報は、ユーザを一意に識別する情報である。例えば、ユーザID、ユーザ名などである。関連付けられたとは、例えば、一方から他方を検索可能とすることであり、データベース上で、あるデータと他のデータが紐付けられることである。
ゲームデータとは、例えば、ゲームの実行時に参照されるデータである。また例えば、ゲームデータは、ゲームの結果に影響するデータである。また例えば、ゲームデータは、ユーザ情報に関連付けられたデータである。また例えば、ゲームデータは、キャラクタ、カード、又はアイテムといったゲームオブジェクトである。また例えば、ゲームデータは、ゲームで用いられるゲームオブジェクトである。本実施形態では、カードがゲームオブジェクトに相当してもよいし、カードに描かれたキャラクタがゲームオブジェクトに相当してもよい。
また例えば、ゲームデータは、ユーザが使用するチームの戦術、フォーメーション、使用キャラクタといった情報である。また例えば、ゲームデータは、キャラクタの装備、能力パラメータ、スキルといった情報である。本実施形態では、チーム情報がゲームデータに相当する。このため、本実施形態でチーム情報と記載した箇所は、ゲームデータと読み替えることができる。
[規則情報取得部]
規則情報取得部102は、乱数発生規則に関する規則情報を取得する。乱数発生規則とは、例えば、乱数を発生させるための規則であり、関数、アルゴリズム、数式などである。例えば、乱数発生規則は、randといった乱数を発生させるための関数である。例えば、この関数は、乱数シードと呼ばれる値を元にして乱数を取り出す関数である。本実施形態では、乱数発生規則は、複数のゲーム実行部100で共通なので、複数のゲーム実行部100で共通の乱数列となるような規則といえる。
乱数とは、例えば、数字が不規則に表れるように配列されたものであり、疑似乱数又はソフトウェア乱数と呼ばれることもある。乱数シードとは、例えば、乱数を初期化するための値である。例えば、乱数シードは、乱数を発生させるための関数に入力する値である。また例えば、乱数シードは、乱数列のもととなる値であり、乱数シードの値が異なると、乱数発生規則により生成される乱数列も異なる。
乱数列は、例えば、乱数の組み合わせ全体のことである。複数の乱数が順番に並べられたものが乱数列である。例えば、ゲーム実行部100は、乱数列の各乱数を順番に取得する。規則情報とは、例えば、乱数発生規則が乱数を発生させるために使用する情報である。例えば、規則情報は、乱数発生規則に入力される乱数シードである。本実施形態では、乱数シードが規則情報に相当する。このため、本実施形態で乱数シードと記載した箇所は、規則情報と読み替えることができる。
本実施形態では、規則情報取得部102は、後述するサーバ30の規則情報送信部302により送信された規則情報を取得する。即ち、規則情報取得部102は、ゲーム実行部100の外部において生成され、規則情報送信部302により送信された規則情報を取得する。なお、規則情報は、ゲーム実行部100内部において生成されてもよい。この場合、規則情報送信部302は省略してもよい。また、規則情報は、ゲーム端末10及びサーバ30以外のコンピュータで生成されてもよく、この場合、規則情報取得部102は、当該コンピュータから規則情報を取得する。
[乱数取得部]
乱数取得部103は、複数のゲーム実行部100で共通の乱数発生規則に基づいて発生される乱数を取得する。本実施形態では、乱数発生規則が共通であり、あるゲーム実行部100の乱数発生規則と、他のゲーム実行部100の乱数発生規則と、は同じである。このため、あるゲーム実行部100の乱数取得部103が取得する乱数と、他のゲーム実行部100の乱数取得部103が取得する乱数と、は同じとなる。
本実施形態では、乱数取得部103は、規則情報に基づいて乱数を発生させる。即ち、乱数取得部103は、ゲーム実行部100の外部において生成された乱数を取得するのではなく、自身が乱数を発生させることになる。なお、ゲーム実行部100の内部で乱数が生成される態様に限られず、乱数は、ゲーム実行部100の外部において生成されてもよい。この場合は、乱数取得部103は、外部において生成された乱数を取得することになる。また、乱数は、ゲーム端末10及びサーバ30以外のコンピュータで生成されてもよく、この場合、乱数取得部103は、当該コンピュータから乱数を取得する。
本実施形態では、乱数取得部103は、状況データを更新するための複数の更新タイミングの各々が訪れるたびに、乱数発生規則に基づいて発生される乱数列から順番に乱数を取得する。例えば、乱数列は、複数の乱数の各々が順番に並んだものなので、乱数取得部103は、更新タイミングのたびに、乱数列から順番に乱数を取得することになる。即ち、乱数列にn個(nは2以上の整数)が順番に並べられているとすると、乱数取得部103は、1番目の乱数、2番目の乱数、3番目の乱数・・・といったように、n番目まで順番に乱数を取得する。
更新タイミングとは、例えば、状況データを更新するために乱数が取得されるタイミングである。別の言い方をすれば、更新タイミングは、乱数に基づいて状況データを更新するタイミングであり、ゲームプログラムに記述された命令のうち、乱数を取得する命令が実行されるタイミングである。
乱数取得部103は、ゲームプログラムに記述された命令に基づいて、更新タイミングであるか否かを判定する。例えば、乱数取得部103は、当該命令が乱数を参照することを示している場合には更新タイミングであると判定し、特に当該命令が乱数を参照するものではない場合には更新タイミングではないと判定する。乱数取得部103は、更新タイミングであると判定された場合に、直近で取得した乱数の次の順番の乱数を取得する。
なお、定期的に乱数を取得するといった場合には、所定時間ごとに更新タイミングが設定されていてもよい。この場合、乱数取得部103は、一定時間が経過したか否かを判定する。乱数取得部103は、一定時間が経過したと判定された場合に、直近で取得した乱数の次の順番の乱数を取得してもよい。
[データ記憶部]
データ記憶部104は、ゲームを実行するために必要なデータを記憶する。ここでは、データ記憶部104が記憶するデータの一例として、ゲームの状況を示す状況データDT1を説明する。
状況データDT1とは、例えば、ゲームの現在の状況を示すデータである。例えば、状況データDT1は、ゲーム空間の状況を示すデータを含む。また例えば、ゲーム空間には、1又は複数のゲームオブジェクトが配置される。また例えば、ゲーム空間は、仮想的な空間であり、3つの座標軸が関連付けられた仮想的な3次元空間であってもよいし、2つの座標軸が関連付けられた仮想的な2次元平面であってもよい。
また例えば、ゲーム空間の状況を示すデータは、ゲーム空間に配置されるゲームオブジェクトの状態を示すデータを含む。なお、サッカーゲーム、野球ゲーム、バスケットボールゲーム、又はアイスホッケーゲーム等のスポーツゲームの場合、選手キャラクタやボールがゲームオブジェクトに相当する。この場合、選手キャラクタの位置、向き、姿勢、移動方向、移動速度、現在行っている動作種類、ボールを保持しているか否か等を示すデータや、ボールの位置、移動方向、移動速度等を示すデータが、ゲームオブジェクトの状態を示すデータに相当する。
例えば、レースゲームの場合、レースカーがゲームオブジェクトに相当する。この場合、レースカーの位置、向き、移動方向、移動速度等を示すデータが、ゲームオブジェクトの状態を示すデータに相当する。また例えば、格闘ゲーム、アクションゲーム、又はロールプレイングゲームの場合、キャラクタがゲームオブジェクトに相当する。この場合、キャラクタの位置、向き、姿勢、移動方向、移動速度、現在行っている動作種類、ヒットポイント(ライフポイント)等を示すデータが、ゲームオブジェクトの状態を示すデータに相当する。
また例えば、カードゲームの場合、ゲームカードがゲームオブジェクトに相当する。この場合、ゲームカードの位置、向き等を示すデータが、ゲームオブジェクトの状態を示すデータに相当する。また例えば、状況データDT1は、ゲームの進行状況を示すデータを含んでもよい。例えば、サッカーゲームの場合、試合が開始されてからの経過時間、試合が開始されてから現在までの途中経過、両チームの得点、アウトオブプレイの状態(コーナーキック、ペナルティキック、フリーキック、スローイング、又はゴールキック)であるか否か等を示すデータが、状況データDT1に含まれてもよい。また例えば、野球ゲームの場合、現在のイニング、試合が開始されてから現在までの途中経過、両チームの得点等を示すデータが、状況データDT1に含まれてもよい。
図10は、状況データDT1のデータ格納例を示す図である。本実施形態では、サッカーゲームを例に挙げるので、図10に示すように、状況データDT1には、各チームのキャラクタを一意に識別するキャラクタID(又はキャラクタが描かれたカードを一意に識別するカードID)、当該キャラクタの位置・移動方向・移動速度に関する情報、ボールの位置・移動方向・移動速度に関する情報、各チームの得点、試合の経過時間に関する時間情報、及び、リプレイ映像が流れた回数(後述する第1の処理の実行回数)といった情報が格納される。なお、状況データDT1に含まれる情報は、上記の例に限られず、例えば、キャラクタやボールの3次元モデルの頂点座標等の情報が含まれていてもよい。
時間情報は、例えば、ゲーム内の世界での時間(仮想世界の時間)であり、リアルタイムクロックが示す時間ではない。例えば、時間情報は、スポーツゲームであれば、試合開始からの経過時間である。また例えば、時間情報は、ゲーム内の世界における仮想的な日時又は時刻であってもよい。先述したように、本実施形態では、状況データDT1は、ゲーム開始後の操作部14の検出信号に関係なく更新される。即ち、ゲーム開始後は、原則として、操作部14の検出信号は、状況データDT1の更新に影響しない。
なお、データ記憶部104に記憶されるデータは、上記の例に限られない。データ記憶部104は、ゲームに必要なデータを記憶すればよい。例えば、データ記憶部104は、ゲームデータ取得部101が取得したチーム情報を記憶してもよいし、マイページ画像G1等の種々の画像の画像データを記憶してもよい。
[更新部]
更新部105は、各ユーザ情報に関連付けられたチーム情報と乱数とに基づいて、複数のゲーム実行部100で共通のゲーム処理を実行することによって、状況データDT1を更新する。
共通のゲーム処理とは、例えば、共通のアルゴリズムが記述されたゲームプログラムによって実行される処理である。例えば、共通のゲーム処理は、複数の処理の各々が同じであり、各処理の実行順も同じとなる処理である。また例えば、共通のゲーム処理は、乱数の値が同じであれば結果も同じとなる処理である。
ゲーム処理は、任意の処理であってよく、例えば、ゲームオブジェクトの動作を決定する処理であってもよい。例えば、ゲーム処理は、キャラクタの移動方向、動作の種類、動作の強度を決定するための処理であってもよい。サッカーゲームであれば、ゲーム処理は、例えば、シュート、パス、フェイントといった動作を決定する処理である。野球ゲームであれば、ゲーム処理は、例えば、ヒッティング、バント、投球動作といった動作を決定する処理である。カードゲームであれば、例えば、使用するカードを決定したり、使用するスキルを決定したりする処理である。
乱数とゲーム処理との関係は、予めゲームプログラムに記述されているものとする。例えば、更新部105は、乱数取得部103が取得した乱数に関連付けられたゲーム処理を実行し、状況データDT1を更新する。例えば、更新部105は、乱数に基づいて、キャラクタの移動方向、動作の種類、及び動作の強度の少なくとも1つを決定し、状況データDT1を更新する。また例えば、更新部105は、乱数に基づいて、キャラクタやゲームカードのスキルを発動させ、状況データDT1を更新する。また例えば、更新部105は、乱数に基づいて、キャラクタの動作の成否を決定し、状況データDT1を更新する。
本実施形態では、更新部105は、各更新タイミングが訪れるたびに、乱数列から順番に取得された乱数に基づいて、状況データDT1を更新する。更新部105は、状況データDT1に基づいて更新タイミングが訪れたか否かを判定し、更新タイミングが訪れたと判定した場合に、乱数列から取得された乱数に基づいてゲーム処理を実行し、状況データDT1を更新する。
[表示制御部]
表示制御部106は、状況データDT1に基づいて、ゲームの状況を示すゲーム画像を表示部15に表示させる。本実施形態では、対戦画像G6がゲーム画像に相当する。このため、本実施形態で対戦画像G6と記載した箇所は、ゲーム画像と読み替えることができる。例えば、表示制御部106は、状況データDT1が示すゲーム空間の様子を対戦画像G6に表示させる。例えば、表示制御部106は、ゲーム空間に配置されたキャラクタやボールなどの3次元モデルの座標変換処理を実行し、対戦画像G6を表示させる。また例えば、表示制御部106は、状況データDT1が示す戦況(例えば、各チームの得点や試合の経過時間)を対戦画像G6に表示させてもよい。
[第1判定部]
第1判定部107は、状況データDT1に基づいて、ゲームが第1の状況になったか否かを判定する。第1の状況とは、例えば、予め定められた進行状況である。例えば、第1の状況は、所定の処理が実行された回数が閾値以上になることである。また例えば、第1の状況は、ゲーム開始からの経過時間が所定時間になることである。また例えば、第1の状況は、状況データDT1の各項目の値が所定値を示すことである。また例えば、第1の状況は、リプレイが再生された回数が閾値以上になることである。
また例えば、スポーツの試合を模したゲームであれば、第1の状況は、試合が一時停止する状況が所定回数発生することである。また例えば、サッカーゲームであれば、第1の状況は、シュート本数が閾値以上になること、アニメーションの再生速度が速くなったり遅くなったりした回数が閾値以上になること、ボールがタッチラインを割ったり反則が発生したりしてアウトオブプレイになった回数が閾値以上になることなどである。
例えば、第1判定部107は、状況データDT1に格納された第1の項目の値に基づいて、ゲームが第1の状況になったか否かを判定する。例えば、第1判定部107は、第1の項目の値が所定範囲になっていない場合は、ゲームが第1の状況になったとは判定せず、第1の項目の値が所定範囲になった場合は、ゲームが第1の状況になったと判定する。
本実施形態では、第1の状況は、ゲームにおいて、所定の処理が実行された回数が閾値以上になることである。所定の処理とは、例えば、処理完了までに時間がかかると予測される処理である。例えば、リプレイ映像を流す処理、試合を一時停止する処理、といった上記処理である。本実施形態では、リプレイ映像を流す処理が所定の処理に相当する。このため、状況データDT1には、リプレイ映像が流された回数が格納されているものとする。
例えば、第1判定部107は、状況データDT1に格納されたリプレイ映像の回数が所定回数以上であるか否かを判定する。第1判定部107は、リプレイ映像の回数が所定回数未満である場合はゲームが第1の状況になったとは判定せず、リプレイ映像の回数が所定回数以上である場合はゲームが第1の状況になったと判定する。なお、リプレイ映像の回数は、所定回数以上になった場合にいったん0回にリセットされてもよいし、特にリセットされなくてもよい。
[第1停止部]
第1停止部108は、ゲームが第1の状況になったと判定された場合に、他のゲーム実行部100におけるゲームが第1の状況になるまで、状況データDT1の更新を一時停止させる。
例えば、各ゲーム実行部100は、当該ゲーム実行部100の第1判定部107により、第1の状況になったと判定された場合に、サーバ30に対して所定の通知を送信する。サーバ30は、当該通知を受信すると当該通知を転送する。ゲーム実行部100は、サーバ30が転送した通知を受信することによって、他のゲーム実行部100におけるゲームが第1の状況になったか否かを特定する。
他のゲーム実行部100におけるゲームが第1の状況になるまでとは、例えば、他のゲーム実行部100におけるゲームが第1の状況になったことを示す通知を受信した時点、又は、当該時点の後の任意の時点である。例えば、第1停止部108は、サーバ30から当該通知を受信したか否かを判定することによって、他のゲーム実行部100におけるゲームが第1の状況になったか否かを判定する。
例えば、第1停止部108は、ゲームが第1の状況になったと判定された場合に、状況データDT1の更新を一時停止する。状況データDT1の更新を一時停止するとは、例えば、ゲームの進行を一時停止することである。なお、第1停止部108により状況データDT1の更新が一時停止されている間は、表示制御部106は、対戦画像G6の表示を更新しないようにしてもよいし、「しばらくお待ち下さい」といった所定のメッセージを表示させてもよい。また例えば、この間は、表示制御部106は、それまでのダイジェスト映像を流してもよいし、試合とは関係のない映像を流してもよい。例えば、第1停止部108は、サーバ30から通知を受信したと判定しない場合は、状況データDT1の更新の一時停止を継続する。
[第1再開部]
第1再開部109は、他のゲーム実行部100におけるゲームが第1の状況になった場合に、状況データDT1の更新を再開させる。例えば、第1再開部109は、他のゲーム実行部100におけるゲームが第1の状況になったことを示す通知を受信した場合に、状況データDT1の更新を再開させる。状況データDT1の更新を再開させるとは、例えば、ゲームの進行の一時停止を解除して再開することである。状況データDT1の更新が再開されると、表示制御部106は、対戦画像G6の表示の更新を再開する。
[第2判定部]
第2判定部110は、状況データDT1に基づいて、ゲームが第2の状況になったか否かを判定する。第2の状況とは、例えば、第1の状況とは異なる状況である。例えば、第2の状況は、休憩や選手交代などの目的で定められた期間が訪れることである。また例えば、第2の状況は、サッカーゲームにおけるハーフタイムであってもよいし、野球ゲームにおけるイニングの合間であってもよい。また例えば、ゲームデータの変更を許可する状況として定められた状況である。
例えば、第2判定部110は、状況データDT1に格納された第2の項目の値に基づいて、ゲームが第2の状況になったか否かを判定する。例えば、第2判定部110は、第2の項目の値が所定範囲になっていない場合は、ゲームが第2の状況になったとは判定せず、第2の項目の値が所定範囲になった場合は、ゲームが第2の状況になったと判定する。
本実施形態では、第2判定部110は、状況データDT1が示す試合の経過時間が所定時間になったか否かを判定する。例えば、第2判定部110は、状況データDT1が示す試合の経過時間に基づいて、試合の前半(例えば、仮想世界内での45分)が終了してハーフタイムが訪れたいか否かを判定する。このため、本実施形態では、試合の前半が終了してハーフタイムが訪れることが第2の状況になることに相当する。
[第2停止部]
第2停止部111は、ゲームが第2の状況になったと判定された場合に、状況データDT1の更新を一時停止させる。例えば、第2停止部111は、ゲームが第2の状況になったと判定された場合に、状況データDT1の更新を一時停止する。第2停止部111により状況データDT1の更新が一時停止されている間は、表示制御部106は、チーム情報の変更を受け付けるための画像を表示部15に表示させ、当該画像に対する操作に基づいて、後述する変更部112がチーム情報を変更してもよい。
[変更部]
本実施形態では、チーム情報がゲームデータに相当するので、変更部112は、状況データDT1の更新が一時停止された場合に、各ゲーム実行部100のうちの1又は複数のゲーム実行部100に対応するユーザ情報に関連付けられたチーム情報を変更する。例えば、変更部112は、操作部14の検出信号に基づいて、チーム情報を変更する。
例えば、変更部112は、操作部14の検出信号に基づいて、戦術、フォーメーション、使用するキャラクタといったチーム情報を変更する。例えば、変更部112は、戦術・フォーメーションは、予め定められた複数種類の戦術・フォーメーションのうち、指定された戦術・フォーメーションとなるように変更する。また例えば、変更部112は、所有するキャラクタ(カード)のうち、指定されたキャラクタ(カード)が使用されるように変更する。
[ゲームデータ送信部]
本実施形態では、チーム情報がゲームデータに相当するので、ゲームデータ送信部113は、変更部112により変更されたチーム情報を他のゲーム実行部100に送信する。例えば、ゲームデータ送信部113は、変更部112により変更されたチーム情報をサーバ30に送信する。サーバ30は、当該チーム情報を転送する。各ゲーム実行部100の後述するゲームデータ受信部114は、他のゲーム実行部100の変更部112により変更されたチーム情報を受信する。即ち、各ゲーム実行部100の変更により変更されたチーム情報が共有される。なお、P2P通信が利用される場合には、サーバ30を介するのではなく、ゲームデータ送信部113は、他のゲーム実行部100に対して直接的にチーム情報を送信してもよい。
[ゲームデータ受信部]
本実施形態では、チーム情報がゲームデータに相当するので、ゲームデータ受信部114は、他のゲーム実行部100の変更部112により変更されたチーム情報を受信する。例えば、各ゲーム実行部100のゲームデータ受信部114は、他のゲーム実行部100のゲームデータ送信部113により送信されたチーム情報を、サーバ30を介して受信する。なお、P2P通信が利用される場合には、サーバ30を介するのではなく、ゲームデータ受信部114は、他のゲーム実行部100から直接的にチーム情報を受信してもよい。
[第2再開部]
本実施形態では、チーム情報がゲームデータに相当するので、第2再開部115は、自身の変更部112により変更されたチーム情報と、他のゲーム実行部100の変更部112により変更されたチーム情報と、に基づいて、状況データDT1の更新を再開させる。例えば、第2再開部は、チーム情報を更新したうえで、状況データDT1の更新を再開させることになる。また例えば、第2再開部115は、ゲームデータ受信部114がチーム情報を受信した場合に、状況データDT1の更新を再開させる。状況データDT1の更新が再開されると、表示制御部106は、再び対戦画像G6を表示させて対戦を再開させる。
[1-3-2.サーバで実現される機能]
サーバ30では、データ記憶部300、規則情報生成部301、及び規則情報送信部302が実現される。本実施形態では、これら各機能がゲームサーバ30Dによって実現される場合を説明するが、ゲームシステムS内の任意のサーバで実現されるようにすればよい。
[データ記憶部]
データ記憶部300は、記憶部32Dを主として実現される。データ記憶部300は、ゲームを実行するために必要なデータを記憶する。ここでは、データ記憶部300が記憶するデータの一例として、ユーザデータDT2を説明する。
図11は、ユーザデータDT2のデータ格納例を示す図である。図11に示すように、ユーザデータDT2は、ユーザ情報(例えば、ユーザID)に関連付けて、ユーザ名、及びチーム情報などが格納される。チーム情報としては、例えば、チームのフォーメーション、作戦、キャラクタを一意に識別するキャラクタID、キャラクタの名前、能力パラメータ、及びスキルといった情報が格納される。
なお、データ記憶部300に記憶されるデータは、上記の例に限られない。データ記憶部300は、ゲームに必要なデータを記憶すればよい。例えば、データ記憶部300には、乱数シードを生成するための関数などが記憶されていてもよい。
[規則情報生成部]
規則情報生成部301は、制御部31Dを主として実現される。規則情報生成部301は、マッチングが実行された場合に、時間情報に基づいて規則情報を生成する。マッチングが実行された場合とは、例えば、マッチングが完了した時点、又は、当該時点よりも後の任意の時点である。時間情報とは、例えば、日時であってもよいし、日付を含まない時刻であってもよい。なお、ここでの時間情報は、状況データDT1に含まれる仮想世界の時間情報ではなく、リアルタイムクロック等によって取得される現実世界の時間情報である。
本実施形態では、乱数シードが規則情報に相当するので、規則情報生成部301は、時間情報に基づいて乱数シードを生成することになる。乱数シードの生成方法自体は、公知の種々の手法を適用可能であり、例えば、時間情報が示す数値を所定の数式に代入することによって乱数シードを取得してもよいし、時間情報が示す数値をそのまま乱数シードの値をしてもよい。
[規則情報送信部]
規則情報送信部302は、制御部31Dを主として実現される。規則情報送信部302は、各ゲーム実行部100に対し、規則情報を送信する。本実施形態では、乱数シードが規則情報に相当するので、規則情報送信部302は、マッチング結果に基づいて送信相手のゲーム実行部100を特定し、当該特定したゲーム実行部100に対し、規則情報生成部301が生成した乱数シードを送信することになる。
[1-4.ゲームシステムにおいて実行される処理]
図12-図14は、ゲームシステムSにおいて実行される処理の一例を示すフロー図である。図12-図14に示す処理は、制御部11が記憶部12に記憶されたプログラムに従って動作し、制御部31が記憶部32に記憶されたプログラムに従って動作することによって実行される。以降説明する処理は、機能ブロックが実行する処理の一例である。
なお、ゲーム端末10は、任意の通信プロトコルを利用してよいが、ここでは、TCP/IPを利用する場合を説明する。ゲーム端末10のIPアドレスについては、プロバイダ等によって決められた値なので任意の値を利用できないが、ポート番号については、ゲーム端末10内の他のプログラムが使用していなければ、任意の値を利用してもよい。なお、所定のポート番号(例えば、1~49151など)が他のプログラムで利用されている可能性が高い場合には、これらの範囲は避けてもよい。
図12に示すように、まず、ゲーム端末10においてゲームプログラムが起動すると、制御部11は、ゲートサーバ30Aとの接続処理を行い、サーバリストを要求する(S101)。ゲームプログラムには、ゲートサーバ30AのIPアドレスと、ゲームシステムSで利用される共通鍵と、が予め記憶されているものとする。ここでは、ゲームプログラムからサーバ30に対する通信が行われる場合には、例えばハッカーによるチートを防止するために、当該共通鍵で暗号化されたデータを使用して通信が行われる。なお、ゲートサーバ30Aに対する通信も共通鍵が用いられてもよいが、ゲートサーバ30Aは、データを復号化する時間がないほどアクセス数が多いため、セキュリティよりも速度を優先させるために、ゲートサーバ30に対する通信は共通鍵が用いられないようにしてもよい。また例えば、ゲームプログラムは、ゲートサーバ30AのIPアドレスと、上記予め定められたポート番号のポート(例えば、66000)と、を利用してTCP/IPによってゲートサーバ30Aに接続する。その後、ゲームプログラムは、ゲートサーバ30Aに対し、サーバリストを要求する。
ゲートサーバ30Aにおいては、要求を受信すると、制御部31Aは、ゲーム端末10に対し、サーバリストを送信する(S301)。S301においては、記憶部32Aに、現在稼働中のサーバの種類とIPアドレスとの組み合わせを示すサーバリストが記憶されており、制御部31Aは、当該サーバリストを送信することになる。
ゲーム端末10においては、サーバリストを受信すると、ゲートサーバ30Aとの接続を切断し、制御部11は、受信したサーバリストに基づいて、認証サーバ30Bとの接続処理を行い、ユーザ認証の実行を要求する(S103)。先述したように、サーバリストには、現在稼働中のサーバが記載されており、認証サーバ30Bもサーバリストに含まれている。ユーザ認証は、任意の認証方法を利用すればよく、例えば、公開鍵と秘密鍵を利用してワンタイムの共通鍵暗号をやり取りすることで実行されてもよい。
認証サーバ30Bにおいては、要求を受信すると、制御部31Bは、ユーザ認証を実行する(S303)。S303においては、先述したように、任意の認証方法を利用可能であり、例えば、公開鍵と秘密鍵を利用した認証が実行されるようにしてもよい。
ユーザ認証に失敗した場合(S303;失敗)、ゲーム端末10に対し、所定のエラーメッセージが送信されて本処理は終了する。一方、ユーザ認証に成功した場合(S303;成功)、制御部31Bは、ユーザトークンを発行してゲーム端末10に送信する(S305)。ユーザトークンは、例えば、所定ビットのバイナリデータである。以降やり取りされるデータには、原則としてユーザトークンが添付される。
なお、以降の処理において、ロビーサーバ30Cやゲームサーバ30Dからトークンエラーが受信された場合には、ユーザ認証を実行しなおしてユーザトークンが更新されてもよい。再度のユーザ認証が実行される場合には、ゲートサーバ30Aから受信したサーバリストが利用されるようにすればよい。なお、サーバリストに記載されたサーバ30に接続しても、正しいユーザトークンを取得できない場合には、再度ゲートサーバ30Aに接続してリストの更新が行われてもよい。その後、先述した手順と同様にして、ユーザ認証が実行される。
ゲーム端末10においては、ユーザトークンを受信すると、制御部11は、受信したユーザトークンを保持する(S105)。以降、マイページ画像G1等が表示される状態となるが、ここでは、個別対戦画像G3のボタンB32,B33が選択された場合の処理を説明する。制御部11は、ゲートサーバ30Aから受信したリストに基づいて、ロビーサーバ30Cとの接続処理を実行する(S107)。
制御部11は、チーム情報画像G4を表示部15に表示させ、操作部14の検出信号に基づいて、試合を開始するためのボタンB43が選択されたか否かを判定する(S109)。ボタンB43が選択されたと判定された場合(S109;Y)、制御部11は、ロビーサーバ30Cに対し、マッチングの要求を送信する(S111)。
ロビーサーバ30Cにおいては、要求を受信すると、制御部31Cは、マッチングを実行する(S307)。記憶部32Cには、ロビーサーバ30Cに接続したゲームプログラムに対応するユーザ情報が予め記憶されており、制御部31Cは、当該ユーザ情報に基づいてマッチングを実行する。制御部31Cは、マッチングが完了すると、ゲーム端末10に対し、マッチングが完了した旨の通知を送信する(S309)。なお、ロビーサーバ30Cは、ゲームサーバ30Dにマッチング結果を送信してもよいし、ゲーム端末10経由でマッチング結果がゲームサーバ30Dに送信されてもよい。マッチング結果は、例えば、マッチングされたユーザ情報やチーム情報などを含んでいてもよい。
図13に移り、ゲーム端末10においては、通知を受信すると、制御部11は、ゲームサーバ30Dとの接続処理を実行する(S113)。なお、ゲームサーバ30Dとの接続処理に失敗した場合には、マッチング前の画面に戻り、再びロビーサーバ30Cと接続してもよい。戻る先のロビーサーバ30Cがない場合には、タイトル画像やマイページ画像G1等に戻ってもよい。ゲームサーバ30Dとの接続処理が成功した場合は、以降の処理が実行される。
ゲームサーバ30Dにおいては、ゲーム端末10と接続すると、制御部31Dは、現在の時間情報に基づいて、乱数シードを生成する(S311)。S311においては、制御部31Dは、リアルタイムクロック等を利用して時間情報を取得し、時間情報を所定の数式に代入することによって乱数シードを生成する。
制御部31Dは、ゲーム端末10に対し、ユーザデータDT2に格納されたチーム情報と、S311で生成した乱数シードと、を送信する(S313)。なお、ゲーム端末10のゲームプログラムが、ゲームサーバ30Dのプロセスにデータを送信する場合には、データにユーザトークンが付与される。例えば、ゲーム端末10AのゲームプログラムAが、ゲームサーバ30Dのプロセスにデータを送信する場合には、データにユーザトークンUTK-Aが付与されて暗号化されたものが送信される。また例えば、ゲーム端末10BのゲームプログラムBが、ゲームサーバ30Dのプロセスにデータを送信する場合には、データにユーザトークンUTK-Bが付与されて暗号化されたものが送信される。
逆に、ゲームサーバ30Dのプロセスから各ゲーム端末10のゲームプログラムにデータが送信される場合には、ユーザトークンは付与されない。例えば、ゲームサーバ30Dがゲーム端末10AのゲームプログラムAに送信するデータは、ゲームプログラムA用のデータになっており、ゲームサーバ30Dがゲーム端末10BのゲームプログラムBに送信するデータは、ゲームプログラムB用のデータになっている。なお、セキュリティ向上などの目的で、ゲームサーバ30Dのプロセスから各ゲーム端末10のゲームプログラムに送信されるデータにユーザトークンが付与されてもよい。
以降説明する処理は、マッチングされた各ゲーム端末10において実行される。ゲーム端末10は、チーム情報と乱数シードを受信すると、制御部11は、個別対戦を開始する(S115)。S115においては、状況データDT1が記憶部12に記憶され、ゲームプログラムに記述されたプログラムコードが実行される。例えば、制御部11は、予め定められたアルゴリズムに基づいて、ゲーム空間におけるキャラクタの動作を決定する。
制御部11は、状況データDT1の更新タイミングが訪れたか否かを判定する(S117)。S117においては、制御部11は、ゲームプログラムに記述されたプログラムコードが乱数を参照することを示しているか否かを判定する。更新タイミングが訪れたと判定された場合(S117;Y)、制御部11は、乱数シードに基づく乱数列から乱数を取得し(S119)、乱数に基づいて状況データDT1を更新する(S121)。S119においては、制御部11は、乱数列のうち所定の順番の乱数を取得し、S121においては、乱数に基づいてキャラクタの動作を決定して状況データDT1を更新する。
制御部11は、状況データDT1に基づいて、アプトオブプレイとなったか否かを判定する(S123)。アプトオブプレイとは、試合の進行が一時停止する状況であり、例えば、ボールがタッチラインを割った場合、ゴールが決まった場合、及び反則が発生した場合等にアプトオブプレイとなる。S123においては、制御部11は、状況データDT1に格納されたボールの位置に基づいて、ボールがタッチラインを割ったか否かを判定したり、ゴールが決まったか否かを判定したりする。また例えば、制御部11は、状況データDT1に格納されたキャラクタの位置に基づいて、反則が発生したか否かを判定する。
アプトオブプレイとなったと判定された場合(S123;Y)、制御部11は、リプレイ映像を表示部15に表示させ(S125)、状況データDT1に格納されたリプレイ映像の再生回数を増加させる(S127)。例えば、状況データDT1の履歴を記憶部12に記憶させておき、S125においては、制御部11は、状況データDT1履歴に基づいてリプレイ映像を生成して表示部15に表示させる。
図14に移り、制御部11は、状況データDT1に基づいて、リプレイ映像の再生回数が閾値以上になったか否かを判定する(S129)。閾値は、予め定められた値であればよく、記憶部12に記憶されているものとする。リプレイ映像の再生回数が閾値以上になったと判定された場合(S129;Y)、制御部11は、状況データDT1の更新を一時停止させ(S131)、ゲームサーバ30Dに対し、状況データDT1の更新を一時停止した旨の通知を送信する(S133)。以降、制御部11は、ゲームに関係のない映像を表示部15に表示させ、他のゲーム端末10におけるゲームの進行が追いつくまで(後述するS135の処理が実行されるまで)待機する。
ゲームサーバ30Dにおいては、通知を受信すると、制御部31Dは、他のゲーム端末10から同様の通知を受信したか否かを判定する(S315)。S315においては、マッチングにより対戦中の全てのゲーム端末10からリプレイ映像の再生回数が閾値以上になり、進行を一時停止する旨の通知を受信したか否かを判定することになる。
他のゲーム端末10から通知を受信したと判定されない場合(S315;N)、再びS315に戻る。一方、他のゲーム端末10から通知を受信したと判定された場合(S315;Y)、制御部31Dは、各ゲーム端末10に対し、ゲームを再開させるための再開要求を送信する(S317)。再開要求は、所定のデータ形式で行われるようにすればよい。
ゲーム端末10においては、再開要求を受信すると、制御部11は、状況データDT1の更新を再開させ(S135)、S117に戻る。この場合、ゲームが一時停止された時点の続きから試合が再開することになる。
一方、S129において、再生回数が閾値以上になったと判定されない場合(S129;N)、制御部11は、状況データDT1に基づいて、前半終了又は試合終了したか否かを判定する(S137)。S137においては、制御部11は、状況データDT1に格納された時間情報が所定の時間を示したか否かを判定する。例えば、制御部11は、時間情報が45分を示していれば前半終了と判定し、時間情報が90分を示していれば試合終了と判定する。
前半が終了したと判定された場合(S137;前半終了)、制御部11は、操作部14の検出信号に基づいて、チーム情報を変更してゲームサーバ30Dに送信する(S139)。S139においては、制御部11は、操作部14の検出信号に基づいて、作戦、フォーメーション、使用するキャラクタ(カード)といったチーム情報を変更し、変更後のチーム情報をゲームサーバ30Dに送信する。
ゲームサーバ30Dにおいては、変更後のチーム情報を受信すると、制御部31Dは、当該チーム情報を保持する(S319)。制御部31Dは、試合の後半を再開させるか否かを判定する(S321)。S321においては、各ゲーム端末10からチーム情報を受信したか否かを判定する。試合の後半を再開させると判定された場合(S321;Y)、制御部31Dは、各ゲーム端末10に対し、変更後のチーム情報を送信する(S323)。
ゲーム端末10においては、変更後のチーム情報を受信すると、制御部11は、変更後のチーム情報に基づいて、後半を再開させ(S141)、S117の処理に戻る。一方、S137において、試合が終了したと判定された場合(S137;試合終了)、本処理は終了する。
以上説明したゲームシステムSによれば、ゲームが開始される場合に取得されたチーム情報と、複数のゲーム実行部100で共通の乱数発生規則に基づいて発生される乱数と、に基づいて、複数のゲーム実行部100で共通のゲーム処理を実行することによって状況データDT1が更新され、状況データDT1の整合を取らなくても状況データDT1が同じ内容になるので、通信負荷を軽減することができる。また、ゲームで使用されるチーム情報の組み合わせが同じだった場合、乱数を使用しなかったとすると毎回同じゲーム結果となってしまい、ユーザが飽きてしまう可能性があるが、乱数を使用してランダム要素を入れることで、チーム情報の組み合わせが同じだったとしてもゲーム結果に変化をつけることができる。また、通信障害やアプリケーション終了等の理由により、一部のゲーム実行部100でゲームが途中終了したとしても、各ゲーム実行部100が状況データDT1を更新するので、他のゲーム実行部100はゲームを最後まで実行することができる。
また、各ゲーム実行部100が、ゲームが開始される場合に、複数のゲーム実行部100で共通の乱数発生規則に関する規則情報に基づいて乱数を発生させることで、複数のゲーム実行部100で共通の乱数とし、状況データDT1を整合しなくても、他のゲーム実行部100と同じ内容の状況データDT1を取得させることができる。また、各ゲーム実行部100が、サーバコンピュータなどから乱数のリストを取得する場合には、一応は同じ乱数を使って状況データDT1を更新することができるが、乱数のリストを送信する分の通信負荷が発生する。この点、ゲームシステムSは、各ゲーム実行部100が、規則情報を使って自分で乱数を発生させることで、乱数のリストを送信する必要がなくなるので、通信負荷を効果的に軽減することができる。
また、マッチングが実行された場合に、時間情報に基づいて規則情報を生成することで、マッチングのたびに異なる規則情報を生成し、各ゲーム実行部100に取得させる乱数を異ならせることができるので、ゲームの結果が毎回同じになりゲームの興趣性が低下するといったことを確実に防止することができる。
また、乱数シードを用いることで、複数のゲーム実行部100で共通の乱数を確実に発生させ、状況データDT1を整合しなくても、他のゲーム実行部100と同じ内容の状況データDT1を取得させることができる。
また、複数の更新タイミングの各々が訪れるたびに、乱数発生規則に基づいて発生される乱数列から順番に取得された乱数に基づいて状況データDT1を更新することにより、乱数が状況データDT1に複数回影響してランダム要素が高まるので、ゲームの興趣性を効果的に高めることができる。
また、リプレイ映像の再生回数が閾値以上になった場合に、他のゲーム実行部100におけるゲームが同様の状況になるまでは状況データDT1の更新を一時停止し、他のゲーム実行部100におけるゲームが同様の状況になった場合に状況データDT1の更新を再開することによって、ゲーム実行部100間でゲームの進行を合わせることができる。ゲームの進行を合わせることで、例えば、ゲームの終了時点を合わせることができたり、ゲーム実行中のチャット時に話が噛みあわないといったことを防止したりすることができる。
また、リプレイ映像の再生回数のような所定の処理が実行された回数が閾値以上になった場合に、状況データDT1の更新を一時停止して、ゲーム実行部100間でゲームの進行を合わせることで、より確実にゲームの進行を合わせることができる。例えば、所定の処理として、進行がずれそうな処理(端末の性能によって処理時間に差が出そうな処理)を定めておくことで、ゲームの進行が大幅にずれるといったことを防止することができる。また例えば、閾値を2以上に設定しておく場合には、所定の処理が発生したとしても、その回数が閾値以上になるまでは状況データDT1の更新が一時停止しないので、所定の処理が発生するたびにゲームが一時停止するといったことを防止でき、ゲームの進行をスムーズにすることができる。
また、ハーフタイムにおいてチーム情報の変更を許可することで、ゲーム終了まで全く介入できないのではなく、ゲームの途中でチーム情報の変更をさせることで、ゲームの興趣性を効果的に高めることができる。
[2.実施形態2]
次に、ゲームシステムSの別実施形態を説明する。以降説明する実施形態2では、実施形態1で説明したゲームと同様のゲームが実行される場合を説明するが、実施形態2のゲームは、実施形態1のゲームとは異なってもよい。なお、実施形態1では個別対戦について説明したが、実施形態2ではグループ対戦について説明する。
先述したように、グループ対戦では、複数人の対戦が実行される。例えば、グループ対戦は、複数人対コンピュータの対戦であってもよいし、複数人対複数人の対戦であってもよい。グループ対戦におけるマッチングについては、後述する実施形態3で説明し、実施形態2では、グループ対戦中に行われるチャットについて説明する。なお、以降説明するチャットは、個別対戦において行われてもよい。個別対戦と同様に、グループ対戦が開始すると対戦画像G6が表示部15に表示される。
図15は、グループ対戦における対戦画像G6の一例を示す図である。図15に示すように、対戦画像G6には、チャットにおけるメッセージを入力するためのボタンB62が表示される。ボタンB62が選択されると、メッセージを入力するためのウィンドウが対戦画像G6に表示される。
図16は、対戦画像G6にウィンドウが表示される様子を示す図である。本実施形態では、スタンプと呼ばれる画像を利用してメッセージを入力することができ、図16に示すように、ウィンドウW63には、スタンプの一覧が表示される。スタンプは、例えば、キャラクタの顔やサッカーボールなどのイラストと、発言内容を示す文字列と、を含んでもよい。ウィンドウW63に表示されたスタンプの何れかが選択されると、当該選択されたスタンプがメッセージとして入力され、対戦画像G6に表示される。
図17は、対戦画像G6にメッセージが表示される様子を示す図である。図17に示すように、対戦画像G6には、メッセージM64が表示される。なお、メッセージM64は、入力者を示す文字列が表示されてもよい。図17の例では、「A」というユーザにより「ゴール!」というメッセージが入力された場合を示している。
実施形態1と同様に、実施形態2のゲームシステムSでは、ゲーム端末10間で操作信号を送り合ったり、更新後のデータを送り合ったりすることなく、各ゲーム端末10で個別にデータの更新が実行されるものとする。このため、ゲーム端末10間でゲーム進行にずれが生じることがあり、メッセージをすぐに表示させない方がよいことがある。
例えば、ゲーム端末10Aの方が、ゲーム端末10Bよりも高性能の場合、ゲーム端末10Aのゲーム進行が、ゲーム端末10Bよりも早くなることがある。この場合、ゲーム端末10Aに入力されたメッセージを、すぐにゲーム端末10Bに出力させてしまうと、メッセージの内容から今後のゲーム展開を予想することができてしまうので、ゲームの興趣性が低下してしまう。
図18は、各ゲーム端末10のゲームプログラムで実行されるゲームの進行を示す図である。図18の例では、ゲーム端末10Aの方が、ゲーム端末10Bよりも高性能とする。このため、ゲーム端末10AのゲームプログラムAと、ゲーム端末10BのゲームプログラムBと、の各々が同時に試合を開始したとしても、ゲームプログラムAが実行するグループ対戦の方が、進行が早い。
例えば、前半25分にゴールが決まったとすると、ゴールシーンが発生するのは、ゲームプログラムAの方がゲームプログラムBよりも早い。ゴールが決まった場合にゲーム端末10Aに入力されたメッセージを、ゲーム端末10Bにすぐに表示させてしまうと、ゲーム端末10Bでは、ゴールシーンになっていないにも関わらず、メッセージが表示されてしまうので、ゴールが決まったことを予想できてしまい、興ざめしてしまう可能性がある。
このため、本実施形態では、ゲームプログラムBが実行するゲームが前半25分になってゴールシーンが発生するまでは、メッセージの表示を待機するようにしている。一方、前半40分に反則が発生し、ゲーム端末10Bにメッセージが入力されたとすると、ゲームプログラムAの方がゲームプログラムBよりも進行が早いため、当該メッセージは、特に表示を待機することなく、ゲーム端末10Aにすぐに表示させるようになっている。
以上のように、実施形態2のゲームシステムSでは、各ゲーム端末10におけるゲームの進行状況が、他のゲーム端末10におけるゲームの進行状況になるまで、メッセージの出力を制限することによって、メッセージの内容から今後のゲーム展開を予想するといったことを防止するようにしている。以降、実施形態2の詳細を説明する。なお、以降の説明では、実施形態1と同様の構成については説明を省略する。
[2-1.実施形態2で実現される機能]
図19は、ゲームシステムSで実現される機能のうち、本発明に関連する機能を示す機能ブロック図である。ここでは、ゲーム端末10で実現される機能について説明する。なお、サーバ30においては、実施形態1と同様、データ記憶部300、規則情報生成部301、及び規則情報送信部302が実現されてもよい。
実施形態2のゲームシステムSでは、実施形態1と同様、複数のゲーム実行部100が実現されるが、図19では、図面の簡略化のために、ゲーム実行部100を1つだけ示す。なお、ゲーム実行部100が実行する処理は、実施形態1と一部は共通するが、実施形態1では説明しなかった処理も含む。図19に示すように、実施形態2のゲーム実行部100は、ゲームデータ取得部101、乱数取得部103、データ記憶部104、更新部105、表示制御部106、メッセージ受信部116、制限部117、及び出力部118を含む。
[ゲームデータ取得部]
ゲームデータ取得部101は、ゲームが開始される場合に、複数のユーザ情報の各々に関連付けられたゲームデータを取得する。ゲームデータ取得部101の処理の詳細は、実施形態1と同様のため、説明を省略する。実施形態1と同様、実施形態2では、チーム情報がゲームデータに相当する。このため、ゲームデータ取得部101は、チーム情報を取得することになる。
[乱数取得部]
乱数取得部103は、複数のゲーム実行部100で共通の乱数発生規則に基づいて発生される乱数を取得する。乱数取得部103の処理の詳細は、実施形態1と同様のため、説明を省略する。
[データ記憶部]
データ記憶部104は、ゲームの状況を示す状況データDT1を記憶する。状況データDT1は、実施形態1と同様のため、説明を省略する。
[更新部]
更新部105は、複数のゲーム実行部100で共通のゲーム処理を実行することによって、状況データDT1を更新する。共通のゲーム処理とは、例えば、共通のアルゴリズムが記述されたゲームプログラムによって実行される処理である。また例えば、共通のゲーム処理は、複数の処理の各々が同じであり、各処理の実行順も同じとなる処理である。また例えば、共通のゲーム処理は、乱数の値が同じであれば結果も同じとなる処理である。
なお、更新部105の処理の詳細は、実施形態1と同様であってもよい。例えば、更新部105は、各ユーザ情報に関連付けられたチーム情報と乱数とに基づいて、ゲーム処理を実行することによって、状況データDT1を更新する。状況データDT1の更新方法は、実施形態1で説明した通りである。
[表示制御部]
表示制御部106は、状況データDT1に基づいて、ゲーム画像を表示部15に表示させる。実施形態1と同様、実施形態2では、対戦画像G6がゲーム画像に相当する。表示制御部106の処理の詳細は、実施形態1と同様のため、説明を省略する。
[メッセージ受信部]
メッセージ受信部116は、他のゲーム実行部100において入力されたメッセージを受信する。例えば、各ゲーム実行部100は、メッセージが入力されると、当該メッセージをサーバ30に送信する。サーバ30は、当該メッセージを他のゲーム実行部100に転送する。各ゲーム実行部100のメッセージ受信部116は、他のゲーム実行部100において入力され、サーバ30により転送されたメッセージを受信する。なお、各ゲーム実行部100は、サーバ30を介するのではなく、P2P通信などを利用して、他のゲーム実行部100に対してメッセージを直接送信してもよい。
メッセージとは、ユーザ間で伝達される情報の内容であり、例えば、各ユーザが入力した記号列や指定した画像により構成されてもよいし、音声によって伝達されてもよい。ここでの記号列とは、文字列(テキスト)を含む意味である。画像としては、例えば、スタンプと呼ばれるイラストの画像であってもよい。
本実施形態では、メッセージ受信部116は、メッセージが入力された場合の他のゲーム実行部100で実行中のゲームの進行状況を示す進行情報を受信する。例えば、各ゲーム実行部100は、メッセージが入力されると、進行情報をサーバ30に送信する。サーバ30は、当該進行情報を他のゲーム実行部100に転送する。各ゲーム実行部100のメッセージ受信部116は、他のゲーム実行部100において入力され、サーバ30により転送された進行情報を受信する。なお、各ゲーム実行部100は、P2P通信などを利用して、他のゲーム実行部100に対して進行情報を直接送信してもよい。
メッセージが入力された場合とは、例えば、メッセージの入力が検知された時点、又は、当該時点の前後の時点である。メッセージを入力するための操作信号が検出された時点が、メッセージの入力が検知された時点に相当する。本実施形態では、ウィンドウに表示されたスタンプのうちの何れかを選択する操作信号が検出された時点が、メッセージの入力が検知された時点に相当する。
例えば、各ゲーム実行部100は、操作部14の操作信号に基づいて、メッセージが入力されたか否かを判定する。メッセージが入力されたと判定された場合、各ゲーム実行部100は、データ記憶部104に記憶された状況データDT1が示す進行情報をサーバ30に送信する。サーバ30は、当該進行情報を転送する。各ゲーム実行部100のメッセージ受信部116は、サーバ30により転送された進行情報を受信する。
進行情報は、例えば、状況データDT1に含まれる少なくとも1つの項目の値を含む情報である。進行情報は、ゲームの進行を特定可能な情報であればよく、例えば、時間情報であってもよいし、試合の戦況やキャラクタの位置等の情報であってもよい。本実施形態では、状況データDT1に格納された時間情報が進行情報に相当する。このため、本実施形態で時間情報と記載した箇所は、進行情報と読み替えることができる。
[制限部]
制限部117は、実行中のゲームの進行状況が、他のゲーム実行部100でメッセージが入力された場合の進行状況になるまで、メッセージの出力を制限する。本実施形態では、メッセージ受信部116が進行情報を受信するので、例えば、制限部117は、実行中のゲームの進行状況が、受信した進行情報が示す進行状況になるまで、メッセージの出力を制限することになる。
実行中のゲームの進行状況とは、例えば、状況データDT1が示す進行状況であり、状況データDT1に含まれる少なくとも1つの項目の値である。本実施形態では、時間情報が進行情報に相当するので、状況データDT1に格納された時間情報が、実行中のゲームの進行状況に相当する。
メッセージが入力された場合の進行状況とは、例えば、メッセージが入力された時点の状況データDT1が示す進行状況である。なお、時点とは、例えば、処理単位であるフレームであってもよいし、状況データDT1に格納された時間情報であってもよい。また例えば、メッセージが入力された時点の前後の時点(例えば、数フレームだけ前後した時点)の状況データDT1が示す進行状況である。なお、メッセージが入力された時点とは、操作部14からメッセージの入力(又は入力完了)を示す信号を受信した時点である。
メッセージが入力された場合の進行状況になるまでとは、例えば、メッセージが入力された場合の進行状況と同じになるまでである。また例えば、メッセージが入力された場合の進行状況と一致するまでである。また例えば、メッセージが入力された場合の進行状況と等しくなるまである。
なお、少なくとも、メッセージが入力された場合の進行状況と同じになる(一致する・等しくなる)までは、メッセージの出力が制限されるようにすればよく、その後もメッセージの出力が制限されてもよい。即ち、メッセージが入力された場合の進行状況と同じになった時点(一致した時点・等しくなった時点)と、メッセージが出力される時点(メッセージの出力の制限が解除される時点)と、が完全に一致している必要はなく、メッセージが出力される時点(メッセージの出力の制限が解除される時点)は、メッセージが入力された場合の進行状況と同じになった時点(一致した時点・等しくなった時点)よりも後であってもよい。
制限とは、例えば、メッセージを出力させないことであり、メッセージの出力を待機することである。また例えば、制限は、メッセージが出力されるタイミングを遅らせることである。また例えば、制限は、メッセージを目立たないように表示させることである。また例えば、制限は、目立たないとは、サイズが小さいこと、透明度が高いこと、色が薄いことなどである。
本実施形態では、制限部117は、実行中のゲームの進行状況が、他のゲーム実行部100でメッセージが入力された場合の進行状況に既になっている場合は、メッセージの出力を制限せずに、メッセージを出力させる。
メッセージが入力された場合の進行状況に既になっている場合とは、例えば、メッセージが入力された場合の進行状況と同じであること、又は、メッセージが入力された場合の進行状況と同じになったことが過去にあることである。また例えば、メッセージが入力された場合の進行状況と一致していること、又は、メッセージが入力された場合の進行状況と一致したことが過去にあることである。また例えば、メッセージが入力された場合の進行状況と等しいこと、又は、メッセージが入力された場合の進行状況と等しくなったことが過去にあることである。
本実施形態では、状況データDT1は、ゲーム内の時間を示す時間情報を含み、制限部117は、実行中のゲーム内の時間が、他のゲーム実行部100でメッセージが入力された場合のゲーム内の時間になるまで、メッセージの出力を制限する。
メッセージが入力された場合のゲーム内の時間になるまでとは、例えば、メッセージが入力された場合の時間と同じ時間になるまでである。また例えば、メッセージが入力された場合の時間と一致する時間になるまでである。また例えば、メッセージが入力された場合の時間と等しい時間になるまである。
少なくとも、メッセージが入力された場合の時間と同じになる(一致する・等しくなる)までは、メッセージの出力が制限されるようにすればよく、その後もメッセージの出力が制限されてもよい。即ち、メッセージが入力された場合の時間と同じになった時点(一致した時点・等しくなった時点)と、メッセージが出力される時点(メッセージの出力の制限が解除される時点)と、が完全に一致している必要はなく、メッセージが出力される時点(メッセージの出力の制限が解除される時点)は、メッセージが入力された場合の時間と同じになった時点(一致した時点・等しくなった時点)よりも後であってもよい。
なお、制限部117は、所定数以上のメッセージが入力された場合は、当該所定数以上のメッセージの全部又は一部のメッセージの出力を制限してもよい。例えば、制限部117は、メッセージの入力が受け付けられるたびに、メッセージが入力された回数をカウントし、当該回数が閾値以上になったか否かを判定する。制限部117は、メッセージが入力された回数が閾値以上になったと判定された場合に、メッセージの出力を制限する。なお、メッセージが入力された回数は、データ記憶部104に記録しておけばよい。
本実施形態では、制限部117は、状況データDT1に格納された時間情報と、受信部が受信した時間情報と、に基づいて、メッセージの出力を制限するか否かを決定する。例えば、制限部117は、状況データDT1に格納された時間情報が示す時間が、受信部が受信した時間情報が示す時間よりも早い場合、メッセージの出力を制限すると決定し、制限部117は、状況データDT1に格納された時間情報が示す時間が、受信部が受信した時間情報が示す時間と同じ又は当該時間よりも遅い場合、メッセージの出力を制限しないと決定する。
[出力部]
出力部118は、メッセージを出力する。出力とは、例えば、視覚的又は聴覚的に出力されることである。即ち、出力とは、画像として表示されること、又は、音声として出力されることである。例えば、出力部118は、表示部15にメッセージを表示させる。また例えば、ゲーム端末10がスピーカやイヤホンジャックなどの音声出力部を含む場合には、出力部118は、音声出力部からメッセージを出力してもよい。
例えば、出力部118は、実行中のゲームの進行状況が、他のゲーム実行部100でメッセージが入力された場合の進行状況に既になっている場合は、メッセージが入力された場合の進行状況を示す情報とともに、メッセージを出力してもよい。即ち、出力部118は、実行中のゲームの進行状況が、他のゲーム実行部100でメッセージが入力された場合の進行状況に既になっている場合は、メッセージの出力を制限することなく、進行状況を示す情報とともにメッセージを表示させる。進行状況を示す情報は、進行状況を特定可能な情報であればよく、例えば、進行状況を示す文字列や画像である。なお、当該情報の表示は省略してもよい。
[2-2.ゲームシステムにおいて実行される処理]
図20は、ゲームシステムSにおいて実行される処理の一例を示すフロー図である。図20に示す処理は、制御部11が記憶部12に記憶されたプログラムに従って動作し、制御部31が記憶部32に記憶されたプログラムに従って動作することによって実行される。以降説明する処理は、機能ブロックが実行する処理の一例である。なお、ここでは、グループ対戦のマッチングが完了し、対戦画像G6が表示された後の処理について説明する。また、グループ対戦においても、実施形態1で説明した個別対戦と同様の処理が実行され、共通の乱数に基づく試合進行が行われているものとする。
図20に示すように、まず、ゲーム端末10においては、制御部11は、操作部14の検出信号に基づいて、対戦画像G6のボタンB62が選択されたか否かを判定する(S151)。ボタンB62が選択されたと判定された場合(S151;Y)、制御部11は、メッセージの入力回数が閾値以上であるか否かを判定する(S153)。なお、メッセージの入力回数は、初期値を0として、予め記憶部12に記憶されているものとする。
メッセージの入力回数が閾値以上であると判定された場合(S153;Y)、S155以降の処理は実行されず、メッセージは入力されない。一方、メッセージの入力回数が閾値以上であると判定されない場合(S153;N)、制御部11は、対戦画像G6にウィンドウW63を表示させる(S155)。ウィンドウW63に表示させる各スタンプの画像データは、予め記憶部12に記憶されているものとする。
制御部11は、操作部14の検出信号に基づいて、ウィンドウW63に表示された何れかのスタンプが選択されたか否かを判定する(S157)。何れかのスタンプが選択されたと判定された場合(S157;Y)、制御部11は、状況データDT1に格納された時間情報とともに、メッセージを送信する(S159)。
ゲームサーバ30Dにおいては、メッセージ等を受信すると、制御部31Dは、受信したメッセージ等を転送する(S331)。なお、S331においては、制御部31Dは、メッセージとともにユーザ情報も送信し、メッセージの入力者を特定可能としてもよい。
ゲーム端末10においては、制御部11は、ゲームサーバ30Dからメッセージ等を受信したか否かを判定する(S161)。メッセージを受信したと判定された場合(S161)、制御部11は、状況データDT1に格納された時間情報と、受信した時間情報と、に基づいて、メッセージを表示させるか否かを決定する(S163)。
一方、S163において、メッセージを表示させると決定された場合(S163;Y)、制御部11は、メッセージを表示させる(S165)。S165においては、制御部11は、メッセージが入力された場合の時間情報も表示させてもよい。
メッセージを表示させると決定されない場合(S163;N)、制御部11は、メッセージの表示を待機する(S167)。制御部11は、S167で表示が待機されたメッセージを、S161で受信した時間情報になった場合に表示させる。即ち、制御部11は、状況データDT1に格納された時間情報が示す時間が、S161で受信した時間情報が示す時間になった場合に、S167で表示が待機されたメッセージを表示部15に表示させる。
制御部11は、終了条件が満たされたか否かを判定する(S169)。終了条件は、前半終了又は試合終了などの任意の条件であってよい。終了条件が満たされたと判定されない場合(S169;N)、S151の処理に戻る。終了条件が満たされたと判定された場合(S169;Y)、本処理は首領する。
以上説明したゲームシステムSによれば、実行中のゲームが、他のゲーム実行部100でメッセージが入力された場合の進行状況になるまで、メッセージの出力を制限することで、ゲーム進行が遅いゲーム実行部100のユーザが、ゲーム進行が早いゲーム実行部100のユーザのメッセージの内容から今後の展開を予想するといったことを防止できるので、ゲームの興趣性の低下を防止することができる。また、ゲーム進行が遅いゲーム実行部100に、ゲーム進行が早いゲーム実行部100のユーザのメッセージを表示させると、ゲーム進行の違いによって話がかみ合わないといったことが生じるが、実施形態2のゲームシステムSでは、このようなことを防止し、複数のユーザの話をかみ合わせることができる。また、各ゲーム実行部100で共通のゲーム処理を実行することによって状況データDT1を更新することで、複数のユーザがゲームに参加する場合の通信負荷を軽減することもできる。
また、実行中のゲームの進行状況が他のゲーム実行部100でメッセージが入力された場合の進行状況に既になっている場合には、当該メッセージの出力を制限せずに出力することで、進行が遅れている他のユーザが入力したメッセージをユーザに迅速に把握させることができる。このため、進行が遅れている他のユーザのメッセージが出力されないといったことを防止することができる。
また、ゲーム内の時間を示す時間情報を利用することで、実行中のゲームの進行状況が、他のゲーム実行部100でメッセージが入力された場合の進行状況になっているか否かをより簡易な処理によって判定することができるので、ゲーム実行部100の処理負荷を軽減することができる。
また、所定数以上のメッセージが入力された場合に、所定数以上のメッセージの全部又は一部のメッセージの出力が制限されることで、多数のメッセージが出力されることを防止できる。
また、ゲームが開始される場合に取得されたチーム情報と、複数のゲーム実行部100で共通の乱数発生規則に基づいて発生される乱数と、に基づいて、複数のゲーム実行部100で共通のゲーム処理を実行することによって状況データDT1が更新され、ゲーム実行部100間で状況データDT1の整合を取らなくても状況データDT1が同じ内容になるので、複数のユーザがゲームに参加する場合の通信負荷を軽減することができる。また、ゲームで使用されるチーム情報の組み合わせが同じだった場合、乱数を使用しなかったとすると毎回同じゲーム結果となってしまい、ユーザが飽きてしまう可能性があるが、乱数を使用してランダム要素を入れることで、チーム情報の組み合わせが同じだったとしてもゲーム結果に変化をつけることができる。また、通信障害やアプリケーション終了等の理由により、一部のユーザがゲームを途中終了させたとしても、各ユーザ端末内で状況データDT1が更新されるので、他のユーザはゲームを最後まで続けることができる。
また、実行中のゲームが、他のゲーム実行部100でメッセージが入力された場合の進行状況に既になっている場合に、当該進行状況を示す情報とともにメッセージが表示されるので、どの時点で他のユーザが入力したメッセージなのかをユーザに把握させることができる。
また、各ゲーム実行部100にメッセージの出力を制限する処理を実行させることで、例えば、ゲームシステムS内のサーバ30の処理負荷を軽減することができる。
[3.実施形態3]
次に、ゲームシステムSの別実施形態を説明する。以降説明する実施形態3では、実施形態1-2で説明したゲームと同様のゲームが実行される場合を説明するが、実施形態3のゲームは、実施形態1-2のゲームとは異なってもよい。実施形態3のゲームシステムSは、複数のユーザが役割を分担して参加するゲームを実行する。
役割とは、例えば、ゲームの中で果たすべき任務である。例えば、スポーツゲームであればポジションである。また例えば、野球ゲームの場合には、ポジションではなく打順が役割に相当してもよい。また例えば、ロールプレイングゲームであれば、役割は、ジョブなどと呼ばれる役職であってもよい。また例えば、カードゲームであれば、役割は、攻撃用のカードであるか、他のカードの支援用のカードであるか等であってもよい。また例えば、役割は、ユーザの役割であってもよいし、ユーザのゲームオブジェクトの役割であってもよい。
分担とは、例えば、複数のユーザの間で異なる役割が割り当てられることであり、あるユーザと他のユーザとがそれぞれ別の役割を担当することである。例えば、第1のユーザが第1の役割を担当し、第2のユーザが第2の役割を担当することである。また例えば、第1のユーザ情報に第1の役割が関連付けられ、第2のユーザ情報に第2の役割が関連付けられることである。また例えば、第1のゲームオブジェクトに第1の役割が関連付けられ、第2のゲームオブジェクトに第2の役割が関連付けられることである。
本実施形態では、ポジションが役割に相当する。このため、本実施形態でポジションと記載した箇所は、役割と読み替えることができる。また、実施形態3では、グループ対戦におけるマッチングについて説明する。例えば、グループ対戦は、複数人でチームを組んで対戦する。チームのフォーメーションは、予め決められており、原則として、フォーメーションが示す複数のポジションの中で分担が行われる。
なお、グループ対戦のフォーメーションは、期間に関係なく固定されていてもよいし、期間に応じて変わってもよい。例えば、ある期間は、キーパーが1人、ディフェンダーが4人、ミッドフィールダーが3人、フォワードが3人の「4-3-3」と呼ばれるフォーメーションとなり、他の期間では、キーパーが1人、ディフェンダーが3人、ミッドフィールダーが4人、フォワードが3人の「3-4-3」と呼ばれるフォーメーションとなってもよい。
また、グループ対戦では、原則として、予め定められたフォーメーションの中で、1人当たり1つのポジションを担当する。このため、グループ対戦では、同じチームに属する11人のマッチングが行われる。別の言い方をすれば、グループ対戦では、11個のユーザ情報のマッチング、11個のキャラクタ(又はカード)のマッチング、又は11個のゲームプログラムのマッチングが行われるということもできる。
なお、11人集まらなかった場合には、マッチングされたユーザのユーザ情報に関連付けられたキャラクタが使用される。例えば、サッカーゲームでは1チームあたり11人のキャラクタで試合が行われるが、マッチングで5人しか集まらなかった場合には、残り6人分のキャラクタについては、その時点で集まった5人のユーザ情報の各々に関連付けられたキャラクタの中から補充される。
例えば、試合メニュー画像G2(図3)のボタンB23が選択されると、グループ対戦のレベルなどを選択するための画像が表示された後に、グループ対戦で使用するキャラクタが描かれたカードを選択するためのカード選択画像が表示部15に表示される。
図21は、カード選択画像の一例を示す図である。図21に示すように、カード選択画像G7は、フォーメーションを表示するための表示領域を含む。表示領域A70には、ピッチを模した画像の上に、各ポジションの混み具合を示す画像が表示されている。混み具合とは、後述する参加登録ユーザの数であり、各画像は、フォーメーションが示す各ポジションに対応する位置に表示されている。ここでは、混み具合が3段階で示されており、例えば、「◎」は最も空いており、「○」は2番目に空いており、「△」は最も混み合っていることを示す。なお、混み具合は、2段階で示されてもよいし、4段階以上で示されてもよい。
図21の例であれば、「4-3-3」のフォーメーションが定められており、例えば、ゴールキーパーが1人、ディフェンダーが4人、ミッドフィールダーが3人、フォワードが3人のフォーメーションが定められている。例えば、ディフェンダー、ミッドフィールダー、及びフォワードは、役割が細分化されていてもよく、表示領域A70には、細分化された役割ごとに混み具合が示されている。
例えば、ディフェンダーは、センターバック、右サイドバック、左サイドバックに細分化され、センターバックは2人存在し、右サイドバックと左サイドバックは1人ずつ存在する。また例えば、ミッドフィールダーは、セントラルミッドフィールダー、右サイドハーフ、及び左サイドハーフに細分化され、これら各ポジションは1人ずつ存在する。また例えば、フォワードは、センターフォワード、右ウイング、及び左ウイングに細分化され、これら各ポジションは1人ずつ存在する。
図21の例では、センターフォワードは混みあっており、センターフォワードのキャラクタをグループ対戦で使おうとすると、マッチングに時間がかかる可能性がある。一方、右ウイングと左ウイングとミッドフィールダー(セントラルミッドフィールダー、右サイドハーフ、及び左サイドハーフ)は、センターフォワードよりは空いており、マッチングにさほど時間はかからない。ゴールキーパーとディフェンダー(センターバック、右サイドバック、左サイドバック)は、何れも空いており、比較的すぐにマッチングされる可能性がある。各ポジションの混み具合は、その時の状況に応じて動的に変化する。
また、カード選択画像G7は、選択中のキャラクタに関する情報を表示するための表示領域A71を含む。選択中のキャラクタとは、グループ対戦で使おうとしているキャラクタであり、チーム内の何れかのキャラクタが選択される。例えば、表示領域A71には、キャラクタの画像、名称、レベル、ポジション、及び能力パラメータなどの情報が表示される。
なお、本実施形態では、キャラクタのポジションは、上記説明した細分化されたポジションが設定されているものとする。キャラクタには、ポジションが1つだけ設定されていてもよいし、複数のポジションが設定されていてもよい。また、キャラクタによって、設定されるポジションの数が異なってもよい。キャラクタのポジションは、表示領域A70に表示されたピッチに示されてもよい。例えば、キャラクタのポジションに対応する領域が、他の領域とは異なる色で表示されてもよい。図21の例では、キャラクタのポジションは、センターフォワードであり、表示領域A70のピッチのうち、センターフォワードに対応する位置の色(図21では網点で示す)が異なっている。
表示領域A71には、キャラクタを入れ替えるためのボタンB710が表示される。ボタンB710が選択されると、グループ対戦で使用するキャラクタが他のキャラクタに切り替わる。例えば、ボタンB710が選択されると、キャラクタのリストが表示され、当該リストの中からグループ対戦で使用するキャラクタが選択される。例えば、グループ対戦で別のポジションのキャラクタが使用されるように、キャラクタを切り替えることができる。
また、カード選択画像G7には、グループ対戦を開始するためのボタンB72が表示される。ボタンB72が選択されると、グループ対戦への参加要求が送信され、グループ対戦のマッチングが開始される。
図22は、マッチング中のカード選択画像G7の一例を示す図である。図22に示すように、カード選択画像G7には、マッチング中であることを示すウィンドウW73が表示される。ウィンドウW73には、現時点でマッチングされた人数が表示される。なお、ウィンドウW73には、マッチングをキャンセルしてウィンドウW73を閉じるためのボタンB730も表示される。ボタンB730が選択されると、グループ対戦への参加がキャンセルされてマッチングが中断される。
グループ対戦のマッチングでは、ポジションごとに、参加登録ユーザのユーザ情報を格納するためのキューが用意されている。例えば、「4-3-3」のフォーメーションでは、ゴールキーパー、センターバック、右サイドバック、左サイドバック、セントラルミッドフィールダー、右サイドハーフ、左サイドハーフ、センターフォワード、右ウイング、及び左ウイングの合計10個のポジションが存在するため、10個のキューが存在する。
例えば、グループ対戦への参加要求が送信されると、選択中のキャラクタに設定されたポジションのキューに、参加登録ユーザのユーザ情報が格納される。キャラクタに複数のポジションが設定されている場合には、最も空いているキューにユーザ情報が格納されるものとする。マッチングは、各キューに対するユーザ情報の格納順に実行される。このため、空いているポジションについては、マッチング完了まであまり時間がかからず、混んでいるポジションについては、マッチング完了までに時間がかかる。表示領域A70には、キューごとの混み具合が表示されることになる。
なお、先述したように、一定時間経過しても11人そろわない場合には、現時点で集まった分だけでマッチングが行われ、足りないポジションについては、現時点で集まったユーザのユーザ情報に関連付けられたキャラクタ(カード)によって補充される。マッチングが完了すると、各チームのキャラクタの画像が表示された後に、グループ対戦が開始される。グループ対戦の流れは、実施形態2で説明した通りであり、ユーザの操作は介入されずに自動進行する。
以上のように、実施形態3のゲームシステムSでは、グループ対戦において、ポジションごとにキューが設定されており、参加登録ユーザのユーザ情報が何れかのキューに格納されることで、ユーザが所望の役割を担当するための手間を軽減するようにしている。以降、実施形態3の詳細を説明する。なお、以降の説明では、実施形態1-2と同様の構成については説明を省略する。
[3-1.実施形態3で実現される機能]
図23は、ゲームシステムSで実現される機能のうち、本発明に関連する機能を示す機能ブロック図である。図23に示すように、実施形態3のゲームシステムSでは、データ記憶部300、受付部303、役割取得部304、追加部305、選択部306、提示部307、役割変更部308、時間変更部309、及び役割割当部310が実現され、これらがサーバ30において実現される場合を説明する。なお、実施形態3においても、実施形態1-2で説明した機能が実現されてよい。
[データ記憶部]
実施形態3のデータ記憶部300は、実施形態1-2で説明したユーザデータDT2に加え、参加登録データDT3を記憶する。
図24は、参加登録データDT3のデータ格納例を示す図である。図24に示すように、参加登録データDT3には、各ポジションと、ゲームへの参加を登録している参加登録ユーザのユーザ情報と、が関連付けられている。例えば、参加登録データDT3は、ポジションごとに、ゲームへの参加登録ユーザのユーザ情報が関連付けられたデータである。ここでは、参加登録データDT3は、キューと呼ばれる形式である場合を説明するが、任意のデータ形式であってよく、例えば、テーブル形式や配列形式であってもよい。
なお、ゲームへの参加を登録するとは、例えば、参加要求を受け付けたことがコンピュータ上に登録されていることである。別の言い方をすれば、マッチング待ちとしてコンピュータ上に登録されていることである。参加登録ユーザとは、例えば、参加登録データDT3にユーザ情報が登録されたユーザである。
[受付部]
受付部303は、制御部31Cを主として実現される。受付部303は、各ユーザによる、ゲームへの参加要求を受け付ける。本実施形態では、受付部303がロビーサーバ30Cにおいて実現される場合を説明するので、受付部303は、所定の通知を受信することによって、参加要求を受け付けることになる。
参加要求とは、例えば、ゲームに参加する意思を示すことである。例えば、参加要求は、ゲームに参加するための情報をサーバに送信することである。また例えば、参加要求は、画面内の所定のボタンの選択を検知することであってもよいし、ゲーム端末10からサーバ30に対してゲームへの参加を要求する通知であってもよい。また例えば、参加要求は、予め定められたデータ形式で行われるようにすればよく、ユーザ情報、ユーザが使用するゲームオブジェクトのIDといった情報を送信することによって行われる。
本実施形態では、カード選択画像G7のボタンB72が選択されると参加要求が送信されるので、受付部303は、ボタンB72が選択されたことを示す通知を受信することによって、参加要求を受け付けることになる。例えば、参加要求には、ユーザ情報と、選択中のキャラクタ(又はキャラクタが描かれたカード)に関する情報(例えば、キャラクタID(カードID)やポジション)と、が含まれるものとする。
[役割取得部]
役割取得部304は、制御部31Cを主として実現される。本実施形態では、ポジションが役割に相当するので、役割取得部304は、複数のポジションのうち、参加要求をしたユーザが所望するポジションを取得する。本実施形態では、役割取得部304がロビーサーバ30Cにおいて実現される場合を説明するので、役割取得部304は、ポジションを識別する情報を受信することによって、所望するポジションを取得することになる。
所望するポジションとは、例えば、ゲームで担当したいポジションとして選択されたポジションである。例えば、所望するポジションは、複数のポジションの中からユーザが選択してもよいし、ゲームで使用するゲームオブジェクトに関連付けられたポジションであってもよい。複数のポジションは、操作部14の検出信号に基づいて決定されてもよいが、本実施形態では、複数のポジションは、予め定められたポジションの組み合わせに基づいて決定される。ポジションの組み合わせとは、例えば、複数のポジションからなるポジションのセットであり、例えば、グループ対戦において予め定められたフォーメーションがポジションの組み合わせに相当する。なお、役割がポジション以外の名称で呼ばれるものであれば、役割の組み合わせは、例えば、パーティ、隊列、陣形などと呼ばれる。
本実施形態のゲームでは、各ユーザのゲームオブジェクトが使用され、役割取得部304は、参加要求をしたユーザのゲームオブジェクトと関連付けられたポジションを、当該ユーザが所望するポジションとして取得する。本実施形態では、キャラクタを示すゲームカードがゲームオブジェクトに相当し、ポジションが役割に相当するので、役割取得部304は、カード選択画像G7において選択されたキャラクタのポジションを、所望する役割として取得することになる。なお、本実施形態では、ゲームカードを例に挙げて説明するが、ゲームカードに限られず、ゲームオブジェクトであれば、ゲームカード以外の構成であってもよく、例えば、キャラクタであってもよいしアイテムであってもよい。
[追加部]
追加部305は、制御部31Cを主として実現される。追加部305は、各ポジションと、ゲームへの参加を登録している参加登録ユーザのユーザ情報と、が関連付けられた参加登録データDT3に、参加要求をしたユーザのユーザ情報を、当該ユーザが所望するポジションと関連付けて追加する。例えば、受付部303が参加要求を受け付けると、追加部305は、参加登録データDT3のうち、役割取得部304が取得したポジションに対応するキューに、参加要求とともに受信したユーザ情報を格納する。
参加登録データDT3に格納されるユーザ情報の順番は、任意であってよいが、ここでは、追加部305は、参加要求を受け付けた順にユーザ情報を格納する。このため、参加要求を受け付けたのが早いほどマッチングされるのが早くなり、参加要求を受け付けたのが遅いほどマッチングされるのが遅くなる。
なお、追加部305は、参加要求をしたユーザが所望するポジションが複数ある場合には、参加登録データDT3に基づいて、当該ユーザが所望する複数のポジションの中から選択した少なくとも1つのポジションと関連付けて、当該ユーザのユーザ情報を参加登録データDT3に追加する。
例えば、追加部305は、操作部14の検出信号に基づいて、複数のポジションの何れかを選択してもよいし、ランダムにポジションを選択してもよい。また例えば、追加部305は、参加登録データDT3が示す各ポジションの混み具合に基づいて、ポジションを選択してもよい。例えば、追加部305は、複数のポジションのうち、最も空いているポジションを選択してもよい。空いているポジションとは、キューに格納されたユーザ情報の数が少ないポジションである。
[選択部]
選択部306は、ゲームに参加する複数のユーザを選択する。ここでの選択とは、例えば、ゲームに参加するユーザの組み合わせを決めることであり、あるユーザと対戦又は協力する他のユーザを決めることである。即ち、ユーザ同士のマッチングである。選択部306は、参加登録データDT3に基づいて、ポジションごとに、当該ポジションを担当するユーザを、当該ポジションにユーザ情報が関連付けられた参加登録ユーザの中から選択する。
例えば、選択部306は、複数のポジションをそれぞれ所望する複数のユーザが集まった場合に、当該複数のユーザを選択する。集まった場合とは、例えば、各ポジションを担当する数が予め定められている場合に、各ポジションを担当する数だけ参加登録ユーザの数がそろうことである。
また例えば、選択部306は、所定時間が経過しても、複数のポジションをそれぞれ所望する複数のユーザが集まらなかった場合には、現時点で集まったユーザを選択してもよい。所定時間は、予め定められた時間であればよく、固定値であってもよいし可変値であってもよい。例えば、選択部306は、参加要求が受け付けられた場合に計時処理を開始し、所定時間が経過したか否かを判定する。選択部306は、所定時間が経過したと判定した場合には、11人そろわなくてもマッチングを完了することになる。
本実施形態のゲームでは、各ユーザの複数のゲームオブジェクトのうち、当該ユーザが指定したゲームオブジェクトが使用されるので、選択部306は、複数のポジションをそれぞれ所望する複数のユーザが集まった場合に、当該複数のユーザを選択する。選択部306は、所定時間が経過しても、複数のポジションをそれぞれ所望する複数のユーザが集まらなかった場合には、現時点で集まったユーザを選択することになる。
[提示部]
提示部307は、参加登録データDT3に基づいて、各ポジションの参加登録状況を各ユーザに提示する。参加登録状況とは、例えば、参加登録ユーザの数である。また例えば、各ポジションを担当する数に対する参加登録ユーザの数の割合である。参加登録状況は、画像で提示されてもよいし、音声で通知されてもよい。例えば、提示部307は、参加登録ユーザの数を示す画像又は音声を出力させてもよいし、混み具合を示す画像又は音声を出力させてもよい。
[役割変更部]
役割変更部308は、参加登録状況が提示されたユーザの操作に基づいて、当該ユーザが所望するポジションを変更する。例えば、役割変更部308は、操作部14の検出信号に基づいて、ユーザが所望するポジションを変更する。本実施形態では、グループ対戦で使用するキャラクタを切り替えることでポジションが変更されるので、役割変更部308は、操作部14の検出信号に基づいて、選択されたキャラクタのポジションに変更する。なお、役割変更部308は、複数のポジションの中から選択されたポジションに変更してもよい。
[時間変更部]
時間変更部309は、参加登録データDT3に基づいて、所定時間の長さを変更する。例えば、時間変更部309は、参加登録データDT3に格納されたユーザ情報の数に基づいて所定時間の長さを変更する。例えば、時間変更部309は、ユーザ情報の数が少ないほど所定時間を長く設定し、ユーザ情報の数が多いほど所定時間を短く設定する。即ち、時間変更部309は、参加登録ユーザが少ないほど所定時間を長く設定し、参加登録ユーザが多いほど所定時間を短く設定する。
[役割割当部]
役割割当部310は、選択部306により選択された複数のユーザの各々が指定したゲームオブジェクトに、当該ユーザが所望するポジションを割り当てる。本実施形態では、キャラクタ(カード)がゲームオブジェクトに相当するので、役割割当部310は、キャラクタに設定されたポジションを、グループ対戦におけるポジションとして割り当てることになる。
例えば、役割割当部310は、複数のポジションをそれぞれ所望する複数のユーザが集まらなかった場合には、選択部306により選択された複数のユーザの各々が指定しなかったゲームオブジェクトの中から、ユーザが集まらなかったポジションを割り当てるゲームオブジェクトを決定してもよい。本実施形態では、キャラクタ(カード)がゲームオブジェクトに相当するので、役割割当部310は、ユーザが集まらなかったポジションについては、集まったユーザのキャラクタのうちの何れかが担当するように、ポジションを割り当てることになる。
[3-2.ゲームシステムにおいて実行される処理]
図25は、ゲームシステムSにおいて実行される処理の一例を示すフロー図である。図25に示す処理は、制御部11が記憶部12に記憶されたプログラムに従って動作し、制御部31が記憶部32に記憶されたプログラムに従って動作することによって実行される。以降説明する処理は、機能ブロックが実行する処理の一例である。なお、ここでは、試合メニュー画像G2のボタンB23が選択された後の処理について説明する。
図25に示すように、ゲーム端末10においては、制御部11は、ロビーサーバ30Cに対し、カード選択画像G7の表示要求を送信する(S181)。表示要求は、予め定められた形式で行われるようにすればよく、例えば、カード選択画像G7を識別するためのID情報が含まれる。
ロビーサーバ30Cにおいては、表示要求を受信すると、制御部31Cは、参加登録データDT3に基づいて、各ポジションの混み具合を示すデータを送信する(S341)。S341においては、制御部31Cは、各ポジションの参加登録ユーザの数を混み具合として送信してもよいし、各ポジションの参加登録ユーザの数に基づいてどの画像を表示させたらよいかを示すデータを送信してもよい。また例えば、混み具合を複数段階の何れかで示す場合には、制御部31Cは、各ポジションの混み具合の段階を示すデータを送信してもよい。
ゲーム端末10においては、データを受信すると、制御部11は、カード選択画像G7を表示部15に表示させる(S183)。S183においては、制御部11は、受信したデータに基づいて、表示領域G70のピッチ上の各画像の表示態様を決定する。例えば、制御部11は、最も空いているポジションに「◎」の画像を表示させ、次に空いているポジションに「○」の画像を表示させ、最も混んでいるポジションに「△」の画像を表示させる。
制御部11は、操作部14の検出信号に基づいて、ユーザの操作を特定する(S185)。ここでは、ボタンB710,B72を選択する操作が行われるものとする。ボタンB710が選択された場合(S185;B710)、制御部11は、グループ対戦で使用するキャラクタを変更する(S187)。S187においてキャラクタが変更されると、表示領域A70,A71の内容も更新される。
一方、ボタンB72が選択された場合(S185;B72)、制御部11は、グループ対戦への参加要求を送信する(S189)。参加要求は、予め定められた形式で行われるようにすればよく、例えば、ユーザ情報と、選択中のキャラクタのキャラクタIDとポジションと、が含まれるものとする。
ロビーサーバ30Cにおいては、参加要求を受信すると、制御部31Cは、キャラクタのポジションに対応するキューに、参加要求をしたユーザのユーザ情報を追加し(S343)、マッチングを実行する(S345)。S343においては、制御部31Cは、参加登録データDT3のうち、選択中のキャラクタのポジションに対応するレコードにユーザ情報を追加する。
図26は、S345の処理の詳細を示す図である。図26に示すように、制御部31Cは、参加登録データDT3に基づいて、フォーメーションの全ポジションが集まっているか否かを判定する(S3451)。S3451においては、制御部31Cは、各ポジションに定められた人数分のユーザ情報が参加登録データDT3に格納されているか否かを判定する。
全ポジションが集まっていると判定された場合(S3451;Y)、制御部31Cは、集まったユーザ同士がチームを組むようにマッチングする(S3453)。S3453においては、制御部31Cは、マッチングされたユーザ情報を参加登録データDT3から削除する。一方、集まっていないポジションがあると判定された場合(S3451;N)、制御部31Cは、新たな参加要求を待ち受ける(S3455)。S3455においては、制御部31Cは、計時を開始し、参加登録データDT3にユーザ情報が追加されて、全ポジションが揃うまで待機する。
制御部31Cは、新たな参加要求を待ち受けてから所定時間が経過したか否かを判定する(S3457)。所定時間の長さを示す情報は、記憶部32Cに記憶されているものとする。なお、先述したように、所定時間は参加登録データDT3が示す混み具合に基づいて変化させてもよい。所定時間が経過したと判定されない場合(S3457;N)、S3451の処理に戻る。制御部31Cは、参加登録データDT3にユーザ情報が追加されて、全ポジションが揃った場合には、S3453の処理に移行してマッチングを行うことになる。
一方、所定時間が経過したと判定された場合(S3457;Y)、制御部31Cは、集まっていないポジションに割り当てるキャラクタを決定してマッチングを完了する(S3459)。S3459においては、制御部31Cは、現時点で集まったユーザのキャラクタ(カード)でチームを組むようにマッチングを行い、集まっていないポジションについては、現時点で集まったユーザのキャラクタの中から補充する。
図25に戻り、制御部31Cは、マッチングが完了した旨の通知を送信する(S347)。S347の処理は、個別対戦のS309と同様であってよく、以降は、個別対戦と同様の流れでグループ対戦が実行されるようにしてよい。
以上説明したゲームシステムSによれば、ゲームへの参加要求をしたユーザのユーザ情報を、当該ユーザが所望するポジションと関連付けて参加登録データDT3に追加して、ポジションごとに、当該ポジションを担当するユーザを、当該ポジションにユーザ情報が関連付けられた参加登録ユーザの中から選択することで、例えば、ユーザが所望するポジションを他のユーザに取られたり、所望するポジションが空いている対戦部屋をいちいち探したりすることがなくなるので、ユーザが所望のポジションを担当するための手間を軽減することができる。
また、各ポジションを所望するユーザが集まるまでゲームに参加するユーザの選択が行われないといった場合には、参加要求をしたユーザが待機する状態が続き、ユーザがいつまで待てばよいか分からずに不満を感じる可能性があるが、ゲームシステムSによれば、各ポジションの参加登録状況が提示され、マッチングまでどの程度時間がかかるかを予め予測させるといったことができるので、ユーザの不満を解消することができる。
また、予め定められたポジションの組み合わせに基づいて複数のポジションが決定されることで、複数のポジションを決める手間を省くことができる。他にも例えば、複数種類の組み合わせを用意しておき、時期に応じて使用する組み合わせを変えるようにした場合には、時期によってポジションに変化を与えることができ、ゲームの興趣性を向上させることができる。
また、参加登録状況が提示されたユーザが所望するポジションを変更することで、例えば、比較的空いているポジションに変更して待ち時間を減らすといったことができ、ユーザの不満を効果的に解消することができる。
また、参加要求をしたユーザのゲームオブジェクトと関連付けられたポジションを当該ユーザが所望するポジションとすることで、ユーザがゲームに参加する前に所望するポジションをいちいち選択しなくても済むので、ユーザの手間を効果的に軽減することができる。
また、参加登録データDT3が示す各ポジションの参加登録状況を考慮したうえで、ユーザ情報を関連付けるポジションを選択することで、例えば、比較的空いているポジションにユーザ情報を追加するといったことができるので、マッチングまでの待ち時間(ゲーム開始までの待ち時間)を短縮することができる。
また、参加登録データDT3が示す各ポジションの参加登録状況が、ゲームに参加するユーザを選択するための所定時間の長さに反映されるので、ゲームに参加するユーザを選択するまでにユーザを長時間待たせるといったことを防止することができる。
また、所定時間が経過しても複数のポジションをそれぞれ所望する複数のユーザが集まらなかった場合には、現時点で集まったユーザを選択することで、ユーザがいつまで待ってもゲームに参加できないといった不満を防止することができる。更に、ユーザが指定しなかったゲームオブジェクトの中から、ユーザが集まらなかったポジションを担当させることで、全く関係のないゲームオブジェクトが使用されるのではなく、ユーザのゲームオブジェクトが使用されるので、ゲームの興趣性を向上させることができる。
[3-3.実施形態3の変形例]
なお、参加登録データDT3には、細分化されたポジションごとにキューが設けられている場合を説明したが、大まかなポジションごとにキューが設けられていてもよい。例えば、図24のように、10個の細かなポジションごとにキューを設けるのではなく、フォワード、ミッドフィールダー、ディフェンダー、ゴールキーパーといった4つの大まかなポジションごとにキューを設けてもよい。この場合、例えば、センターフォワードのキャラクタが選択された場合には、センターフォワードが属するフォワードのキューにユーザ情報が格納される。マッチング後に細かなポジションを決定する場合には、各キャラクタのポジションは、ランダムに決定されてもよいし、当該キャラクタに設定されたポジションに基づいて決定されてもよい。
図27は、実施形態3の変形例における機能ブロック図である。図27に示すように、役割決定部311が実現される。本変形例のゲームでは、複数の第1のポジションと、当該複数の第1のポジションの各々の何れか一又は複数の第1のポジションに属する詳細なポジションである一又は複数の第2のポジションと、があり、役割取得部304は、参加要求をしたユーザが所望する第2のポジションを取得する。
第1のポジションとは、第2のポジションよりも大きな分類(カテゴリ)である。第2のポジションの上位概念に相当するポジションである。第2のポジションを包含するポジションである。例えば、スポーツゲームであれば、第2のポジションよりも大きなポジションである。サッカーゲームであれば、フォワードやミッドフィールダーといったポジションである。野球ゲームであれば、内野手や外野手といったポジションである。
第2のポジションとは、第1のポジションよりも小さな分類(カテゴリ)である。第1のポジションの下位概念に相当するポジションである。第1のポジションを具体化したポジションである。例えば、スポーツゲームであれば、第1のポジションよりも細かなポジションである。サッカーゲームであれば、センターフォワードやセントラルミッドフィールダーといったポジションである。野球ゲームであれば、一塁手や右翼手といったポジションである。
図28は、第1のポジションと第2のポジションとの関係を示す図である。図28に示すように、実施形態3のフォーメーションでは、フォワード、ミッドフィールダー、及びディフェンダーの各々は、3種類の詳細なポジションを含むので、1つの第1のポジションに対し、3つの第2のポジションが存在することになる。一方、ゴールキーパーは、1つだけなので、1つの第1のポジションに対し、1つの第2のポジションが存在することになる。このように、第1のポジションと第2のポジションは、1対多の関係に限られず、1対1の関係であってもよい。即ち、図28のゴールキーパーのように、第1のポジジョンと第2のポジションのポジションがいずれも1対1で対応しているものも含む。
また、先述したように、第1の役割と第2の役割は、ポジションに限られず、ゲームに応じた役割を定めればよい。例えば、ロールプレイングゲームにおけるキャラクタの職業(又は役職)が役割に相当してもよい。この場合に、第1の職業と、詳細な職業である第2の役職と、が存在してもよい。
図29は、第1の職業と第2の役職との関係を示す図である。図29に示すように、例えば、第1の職業として魔法使いと戦士が存在する場合に、魔法使いに対応する第2の役職として、冒険者、下級魔法使い、中級魔法使い、上級魔法使い、及び魔法戦士が存在し、戦士に対応する第2の役職として、冒険者、下級戦士、中級戦士、上級戦士、及び魔法戦士が存在してもよい。この場合、冒険者と魔法戦士は、第1の職業と第2の役職の両方に属することになる。即ち、第1の職業と第2の役職とが多対多の関係にあってもよく、第1の職業である魔法使いと戦士の各々に、第2の役職である冒険者と魔法戦士が属していてもよい。
上記の例では、第1の役割は、例えば、第1のポジションや第1の職業のことであり、第2の役割は、例えば、第2のポジションや第2の役職のことである。図28に示すポジションのように、第1の役割と第2役割が同一分類(カテゴリ)であってもよいし、図29に示す職業と役職のように第1の役割と第2の役割とで、分類(カテゴリ)が異なっていてもよい。データ記憶部300に、第1の役割と第2の役割の対応関係が予め保存されていればよい。
本変形例の参加登録データDT3には、複数の第1のポジションの各々と、ゲームへの参加登録のユーザのユーザ情報と、が関連付けられており、追加部305は、参加要求をしたユーザが所望する第2のポジションが属する第1のポジションと関連付けて、当該ユーザのユーザ情報を参加登録データDT3に追加する。
例えば、第2のポジションがどの第1のポジションに属するかを示すデータは、予めデータ記憶部300等に記憶されているものとする。追加部305は、当該データに基づいて、参加要求をしたユーザが所望する第2のポジションが属する第1のポジションを特定し、当該第1のポジションと関連付けて、ユーザ情報を参加登録データDT3に追加することになる。
役割決定部311は、制御部31Cを主として実現される。役割決定部311は、参加登録データDT3に基づいて、選択部306により選択された複数のユーザの各々が担当する第2のポジションを決定する。例えば、役割決定部311は、第1のポジションに属する複数の第2のポジションの中からランダムに決定してもよいし、キャラクタに関連付けられた第2のポジションに基づいて決定してもよい。
実施形態3の変形例によれば、参加要求をしたユーザが所望する第2のポジションよりも広い第1のポジションと関連付けて、当該ユーザのユーザ情報を参加登録データDT3に追加することで、ユーザが集まりやすくなるので、マッチングまでの時間を早めることができる。
[4.その他変形例]
なお、本発明は、以上に説明した実施の形態に限定されるものではない。本発明の趣旨を逸脱しない範囲で、適宜変更可能である。
例えば、ゲーム端末10においてゲームの主な処理が実行されて、ゲーム端末10が本発明に係るゲーム制御装置に相当してもよいし、サーバ30においてゲームの主な処理が実行され、サーバ30が本発明に係るゲーム制御装置に相当してもよい。また例えば、ゲーム端末10とサーバ30とで各機能が分担されてもよい。この場合、ゲーム端末10とサーバ30とで処理結果を送受信すればよい。
また例えば、サーバ30において実現される各機能は、ゲーム端末10において実現されてもよい。例えば、データ記憶部300がゲーム端末10において実現され、ユーザデータDT2が記憶部12に記憶されてもよい。また例えば、規則情報生成部301及び規則情報送信部302がゲーム端末10において実現され、制御部11が乱数シードを生成したり他のゲーム端末10に乱数シードを送信したりしてもよい。
また例えば、制限部117がサーバ30において実現されてもよい。例えば、制限部117がゲームサーバ30Dで実現されてもよく、この場合、制御部31Dにより、メッセージの出力が制限されてもよい。例えば、ゲームサーバ30Dの制限部117は、ゲーム端末10に対してメッセージを送信しないことによって、メッセージの出力を制限してもよい。
また例えば、受付部303がゲーム端末10で実現されてもよい。この場合、受付部303は、制御部11を主として実現され、操作部14の検出信号に基づいて参加要求を受け付けることになる。また例えば、役割取得部304がゲーム端末10で実現されてもよい。この場合、役割取得部304は、制御部11を主として実現され、操作部14の検出信号に基づいて所望するポジションを取得してもよいし、記憶部12に記憶されたポジションを取得してもよい。また例えば、追加部305がゲーム端末10で実現されてもよい。この場合、追加部305は、制御部11を主として実現され、ユーザ情報をキューに追加する旨の要求をサーバ30に送信してもよい。また例えば、選択部306がゲーム端末10で実現されてもよい。この場合、選択部306は、制御部11を主として実現され、サーバ30から参加登録データDT3を取得してマッチングを実行してもよい。
また例えば、サッカーゲームが実行される場合を説明したが、他のゲームに本発明に係る処理を適用してもよい。例えば、他のスポーツゲーム(例えば、野球、テニス、アメリカンフットボール、バスケットボール、バレーボール等を題材としたゲーム)に本発明に係る処理を適用してもよい。また例えば、カードゲームやスポーツゲーム以外にも、アクションゲーム・ロールプレイングゲーム・格闘ゲーム等のように、ゲーム形式・ジャンルを問わず種々のゲームに本発明に係る処理を適用してもよい。
[5.付記]
以上のような記載から、本発明は例えば以下のように把握される。
[5-1.実施形態1に係る発明]
1-1)本発明の一態様に係るゲームシステム(S)は、複数のゲーム実行手段(100)を含むゲームシステム(S)であって、各ゲーム実行手段(100)は、ゲームが開始される場合に、複数のユーザ情報の各々に関連付けられたゲームデータを取得するゲームデータ取得手段(101)と、前記複数のゲーム実行手段(100)で共通の乱数発生規則に基づいて発生される乱数を取得する乱数取得手段(103)と、前記ゲームの状況を示す状況データを記憶する記憶手段(104)と、各ユーザ情報に関連付けられた前記ゲームデータと前記乱数とに基づいて、前記複数のゲーム実行手段(100)で共通のゲーム処理を実行することによって、前記状況データを更新する更新手段(105)と、前記状況データに基づいて、前記ゲームの状況を示すゲーム画像を表示手段(15)に表示させる表示制御手段(106)と、を含む。
1-9)本発明の一態様に係るゲーム端末(10)は、複数のゲーム実行手段(100)のうちの少なくとも1つを含むゲーム端末(10)であって、各ゲーム実行手段(100)は、ゲームが開始される場合に、複数のユーザ情報の各々に関連付けられたゲームデータを取得するゲームデータ取得手段(101)と、前記複数のゲーム実行手段(100)で共通の乱数発生規則に基づいて発生される乱数を取得する乱数取得手段(103)と、前記ゲームの状況を示す状況データを記憶する記憶手段(104)と、各ユーザ情報に関連付けられた前記ゲームデータと前記乱数とに基づいて、前記複数のゲーム実行手段(100)で共通のゲーム処理を実行することによって、前記状況データを更新する更新手段(105)と、前記状況データに基づいて、前記ゲームの状況を示すゲーム画像を表示手段(15)に表示させる表示制御手段(106)と、を含む。
1-10)本発明の一態様に係るプログラムは、1-1)~1-8)の何れかに記載のゲームシステム(S)又は1-9)に記載のゲーム端末(10)としてコンピュータを機能させる。
1-11)本発明の一態様に係る情報記憶媒体は、1-10)のプログラムを記録したコンピュータで読み取り可能な情報記憶媒体である。
1-1)又は1-9)~1-11)に係る発明によれば、ゲームが開始される場合に取得されたゲームデータと、複数のゲーム実行手段で共通の乱数発生規則に基づいて発生される乱数と、に基づいて、複数のゲーム実行手段で共通のゲーム処理を実行することによって状況データが更新され、状況データの整合を取らなくても状況データが同じ内容になるので、通信負荷を軽減することができる。また、ゲームで使用されるゲームデータの組み合わせが同じだった場合、乱数を使用しなかったとすると毎回同じゲーム結果となってしまい、ユーザが飽きてしまう可能性があるが、乱数を使用してランダム要素を入れることで、ゲームデータの組み合わせが同じだったとしてもゲーム結果に変化をつけることができる。また、通信障害やアプリケーション終了等の理由により、一部のゲーム実行手段でゲームが途中終了したとしても、各ゲーム実行手段が状況データを更新するので、他のゲーム実行手段はゲームを最後まで実行することができる。
1-2)本発明の一態様では、各ゲーム実行手段(100)は、前記乱数発生規則に関する規則情報を取得する規則情報取得手段(102)を更に含み、前記乱数取得手段(103)は、前記規則情報に基づいて前記乱数を発生させる。1-2)の態様によれば、各ゲーム実行手段が、ゲームが開始される場合に、複数のゲーム実行手段で共通の乱数発生規則に関する規則情報に基づいて乱数を発生させることで、複数のゲーム実行手段で共通の乱数とし、状況データを整合しなくても、他のゲーム実行手段と同じ内容の状況データを取得させることができる。また、各ゲーム実行手段が、サーバコンピュータなどから乱数のリストを取得する場合には、一応は同じ乱数を使って状況データを更新することができるが、乱数のリストを送信する分の通信負荷が発生する。この点、1-2)の態様は、各ゲーム実行手段が、規則情報を使って自分で乱数を発生させることで、乱数のリストを送信する必要がなくなるので、通信負荷を効果的に軽減することができる。
1-3)本発明の一態様では、前記ゲームシステム(S)は、マッチングを実行するためのサーバを更に含み、前記サーバは、マッチングが実行された場合に、時間情報に基づいて前記規則情報を生成する規則情報生成手段(301)と、各ゲーム実行手段(100)に対し、前記規則情報を送信する規則情報送信手段(302)と、を含み、前記規則情報取得手段(102)は、前記規則情報送信手段(302)により送信された前記規則情報を取得する。1-3)の態様によれば、マッチングが実行された場合に、時間情報に基づいて規則情報を生成することで、マッチングのたびに異なる規則情報を生成し、各ゲーム実行手段に取得させる乱数を異ならせることができるので、ゲームの結果が毎回同じになりゲームの興趣性が低下するといったことを確実に防止することができる。
1-4)本発明の一態様では、前記規則情報は、前記乱数発生規則に入力される乱数シードである。1-4)の態様によれば、乱数シードを用いることで、複数のゲーム実行手段で共通の乱数を確実に発生させ、状況データを整合しなくても、他のゲーム実行手段と同じ内容の状況データを取得させることができる。
1-5)本発明の一態様では、前記乱数取得手段(103)は、前記状況データを更新するための複数の更新タイミングの各々が訪れるたびに、前記乱数発生規則に基づいて発生される乱数列から順番に前記乱数を取得し、前記更新手段(105)は、各更新タイミングが訪れるたびに、前記乱数列から順番に取得された前記乱数に基づいて、前記状況データを更新する。1-5)の態様によれば、複数の更新タイミングの各々が訪れるたびに、乱数発生規則に基づいて発生される乱数列から順番に取得された乱数に基づいて状況データを更新することにより、乱数が状況データに複数回影響してランダム要素が高まるので、ゲームの興趣性を効果的に高めることができる。
1-6)本発明の一態様では、各ゲーム実行手段(100)は、前記状況データに基づいて、前記ゲームが第1の状況になったか否かを判定する第1判定手段(107)と、前記ゲームが第1の状況になったと判定された場合に、他のゲーム実行手段(100)における前記ゲームが前記第1の状況になるまで、前記状況データの更新を一時停止させる第1停止手段(108)と、他のゲーム実行手段(100)における前記ゲームが前記第1の状況になった場合に、前記状況データの更新を再開させる第1再開手段(109)と、を更に含む。1-6)の態様によれば、ゲームが第1の状況になった場合に、他のゲーム実行手段におけるゲームが第1の状況になるまでは状況データの更新を一時停止し、他のゲーム実行手段におけるゲームが第1の状況になった場合に状況データの更新を再開することによって、ゲーム実行手段間でゲームの進行を合わせることができる。ゲームの進行を合わせることで、例えば、ゲームの終了時点を合わせることができたり、ゲーム実行中のチャット時に話が噛みあわないといったことを防止したりすることができる。
1-7)本発明の一態様では、前記第1の状況は、前記ゲームにおいて、所定の処理が実行された回数が閾値以上になることである。1-7)の態様によれば、所定の処理が実行された回数が閾値以上になった場合に、状況データの更新を一時停止して、ゲーム実行手段間でゲームの進行を合わせることで、より確実にゲームの進行を合わせることができる。例えば、所定の処理として、進行がずれそうな処理(端末の性能によって処理時間に差が出そうな処理)を定めておくことで、ゲームの進行が大幅にずれるといったことを防止することができる。また例えば、閾値を2以上に設定しておく場合には、所定の処理が発生したとしても、その回数が閾値以上になるまでは状況データの更新が一時停止しないので、所定の処理が発生するたびにゲームが一時停止するといったことを防止でき、ゲームの進行をスムーズにすることができる。
1-8)本発明の一態様では、各ゲーム実行手段(100)は、前記状況データに基づいて、前記ゲームが第2の状況になったか否かを判定する第2判定手段(110)と、前記ゲームが前記第2の状況になったと判定された場合に、前記状況データの更新を一時停止させる第2停止手段(111)と、前記状況データの更新が一時停止された場合に、当該各ゲーム実行手段(100)のうちの1又は複数のゲーム実行手段(100)に対応するユーザ情報に関連付けられた前記ゲームデータを変更する変更手段(112)と、前記変更手段(112)により変更されたゲームデータを他のゲーム実行手段(100)に送信するゲームデータ送信手段(113)と、他のゲーム実行手段(100)の前記変更手段(112)により変更されたゲームデータを受信するゲームデータ受信手段(114)と、自身の前記変更手段(112)により変更されたゲームデータと、他のゲーム実行手段(100)の前記変更手段(112)により変更されたゲームデータと、に基づいて、前記状況データの更新を再開させる第2再開手段(115)と、を更に含む。1-8)の態様によれば、ゲーム終了まで全く介入できないのではなく、ゲームの途中でゲームデータの変更をさせることで、ゲームの興趣性を効果的に高めることができる。
[5-2.実施形態2に係る発明]
2-1)本発明の一態様に係るゲームシステム(S)は、複数のゲーム実行手段(100)を含むゲームシステム(S)であって、各ゲーム実行手段(100)は、ゲームの状況を示す状況データを記憶する記憶手段(104)と、前記複数のゲーム実行手段(100)で共通のゲーム処理を実行することによって、前記状況データを更新する更新手段(105)と、前記状況データに基づいて、ゲーム画像を表示手段に表示させる表示制御手段(106)と、他のゲーム実行手段(100)において入力されたメッセージを受信する受信手段(116)と、前記メッセージを出力する出力手段(118)と、を含み、前記ゲームシステム(S)は、実行中の前記ゲームの進行状況が、前記他のゲーム実行手段(100)で前記メッセージが入力された場合の進行状況になるまで、前記メッセージの出力を制限する制限手段(117)、を含む。
2-8)本発明の一態様に係るゲーム端末は、複数のゲーム実行手段(100)のうちの少なくとも1つを含むゲーム端末であって、各ゲーム実行手段(100)は、ゲームの状況を示す状況データを記憶する記憶手段(104)と、他のゲーム実行手段(100)と共通のゲーム処理を実行することによって、前記状況データを更新する更新手段(105)と、前記状況データに基づいて、ゲーム画像を表示手段に表示させる表示制御手段(106)と、他のゲーム実行手段(100)において入力されたメッセージと、前記メッセージが入力された場合の前記他のゲーム実行手段(100)で実行中の前記ゲームの進行状況を示す進行情報と、を受信する受信手段(116)と、前記メッセージを出力する出力手段(118)と、実行中の前記ゲームの進行状況が、受信した前記進行情報が示す進行状況になるまで、前記メッセージの出力を制限する制限手段(117)と、を含む。
2-9)本発明の一態様に係るプログラムは、2-1)~2-8)の何れかに記載のゲーム実行手段(100)としてコンピュータを機能させる。
2-10)本発明の一態様に係る情報記憶媒体は、2-9)のプログラムを記録したコンピュータで読み取り可能な情報記憶媒体である。
2-1)又は2-8)~2-10)に係る発明によれば、実行中のゲームが、他のゲーム実行手段でメッセージが入力された場合の進行状況になるまで、メッセージの出力を制限することで、ゲーム進行が遅いゲーム実行手段のユーザが、ゲーム進行が早いゲーム実行手段のユーザのメッセージの内容から今後の展開を予想するといったことを防止できるので、ゲームの興趣性の低下を防止することができる。また、ゲーム進行が遅いゲーム実行手段に、ゲーム進行が早いゲーム実行手段のユーザのメッセージを表示させると、ゲーム進行の違いによって話がかみ合わないといったことが生じるが、2-1)又は2-8)~2-10)に係る発明では、このようなことを防止し、複数のユーザの話をかみ合わせることができる。また、各ゲーム実行手段で共通のゲーム処理を実行することによって状況データを更新することで、複数のユーザがゲームに参加する場合の通信負荷を軽減することもできる。
2-2)本発明の一態様では、前記制限手段(117)は、実行中の前記ゲームの進行状況が、前記他のゲーム実行手段(100)で前記メッセージが入力された場合の進行状況に既になっている場合は、前記メッセージの出力を制限せずに、前記メッセージを出力させる。2-2)の態様によれば、実行中のゲームの進行状況が他のゲーム実行手段でメッセージが入力された場合の進行状況に既になっている場合には、当該メッセージの出力を制限せずに出力することで、進行が遅れている他のユーザが入力したメッセージをユーザに迅速に把握させることができる。このため、進行が遅れている他のユーザのメッセージが出力されないといったことを防止することができる。
2-3)本発明の一態様では、前記状況データは、前記ゲーム内の時間を示す時間情報を含み、前記制限手段(117)は、実行中の前記ゲーム内の時間が、前記他のゲーム実行手段(100)で前記メッセージが入力された場合の前記ゲーム内の時間になるまで、前記メッセージの出力を制限する。2-3)の態様によれば、ゲーム内の時間を示す時間情報を利用することで、実行中のゲームの進行状況が、他のゲーム実行手段でメッセージが入力された場合の進行状況になっているか否かをより簡易な処理によって判定することができるので、ゲーム実行手段の処理負荷を軽減することができる。
2-4)本発明の一態様では、前記制限手段(117)は、所定数以上のメッセージが入力された場合は、当該所定数以上のメッセージの全部又は一部のメッセージの出力を制限する。2-4)の態様によれば、所定数以上のメッセージが入力された場合に、所定数以上のメッセージの全部又は一部のメッセージの出力が制限されることで、多数のメッセージが出力されることを防止できる。
2-5)本発明の一態様では、各ゲーム実行手段(100)は、前記ゲームが開始される場合に、複数のユーザ情報の各々に関連付けられたゲームデータを取得するゲームデータ取得手段(101)と、前記複数のゲーム実行手段(100)で共通の乱数発生規則に基づいて発生される乱数を取得する乱数取得手段(103)と、を更に含み、前記更新手段(105)は、各ユーザ情報に関連付けられた前記ゲームデータと前記乱数とに基づいて、前記ゲーム処理を実行することによって、前記状況データを更新する。2-5)の態様によれば、ゲームが開始される場合に取得されたゲームデータと、複数のゲーム実行手段で共通の乱数発生規則に基づいて発生される乱数と、に基づいて、複数のゲーム実行手段で共通のゲーム処理を実行することによって状況データが更新され、ゲーム実行手段間で状況データの整合を取らなくても状況データが同じ内容になるので、複数のユーザがゲームに参加する場合の通信負荷を軽減することができる。また、ゲームで使用されるゲームデータの組み合わせが同じだった場合、乱数を使用しなかったとすると毎回同じゲーム結果となってしまい、ユーザが飽きてしまう可能性があるが、乱数を使用してランダム要素を入れることで、ゲームデータの組み合わせが同じだったとしてもゲーム結果に変化をつけることができる。また、通信障害やアプリケーション終了等の理由により、一部のユーザがゲームを途中終了させたとしても、各ユーザ端末内で状況データが更新されるので、他のユーザはゲームを最後まで続けることができる。
2-6)本発明の一態様では、前記出力手段(118)は、実行中の前記ゲームの進行状況が、前記他のゲーム実行手段(100)で前記メッセージが入力された場合の進行状況に既になっている場合は、前記メッセージが入力された場合の進行状況を示す情報とともに、前記メッセージを出力する。2-6)の態様によれば、実行中のゲームが、他のゲーム実行手段でメッセージが入力された場合の進行状況に既になっている場合に、当該進行状況を示す情報とともにメッセージが表示されるので、どの時点で他のユーザが入力したメッセージなのかをユーザに把握させることができる。
2-7)本発明の一態様では、各ゲーム実行手段(100)は、前記制限手段(117)を含み、前記受信手段(116)は、前記メッセージが入力された場合の前記他のゲーム実行手段(100)で実行中の前記ゲームの進行状況を示す進行情報を受信し、前記制限手段(117)は、実行中の前記ゲームの進行状況が、受信した前記進行情報が示す進行状況になるまで、前記メッセージの出力を制限する。2-7)の態様によれば、各ゲーム実行手段にメッセージの出力を制限する処理を実行させることで、例えば、ゲームシステム内のサーバの処理負荷を軽減することができる。
[5-3.実施形態3に係る発明]
3-1)本発明の一態様に係るゲームシステム(S)は、複数のユーザが役割を分担して参加するゲームを実行するゲームシステム(S)であって、各ユーザによる、前記ゲームへの参加要求を受け付ける受付手段(303)と、複数の役割のうち、前記参加要求をしたユーザが所望する役割を取得する役割取得手段(304)と、各役割と、前記ゲームへの参加を登録している参加登録ユーザのユーザ情報と、が関連付けられた参加登録データに、前記参加要求をしたユーザのユーザ情報を、当該ユーザが所望する役割と関連付けて追加する追加手段(305)と、前記ゲームに参加する複数のユーザを選択する手段(306)であって、前記参加登録データに基づいて、前記役割ごとに、当該役割を担当するユーザを、当該役割に前記ユーザ情報が関連付けられた前記参加登録ユーザの中から選択する選択手段(306)と、を含む。
3-10)本発明の一態様に係るゲーム制御装置(10,30)は、複数のユーザが役割を分担して参加するゲームを実行するゲーム制御装置(10,30)であって、各ユーザによる、前記ゲームへの参加要求を受け付ける受付手段(303)と、複数の役割のうち、前記参加要求をしたユーザが所望する役割を取得する役割取得手段(304)と、各役割と、前記ゲームへの参加を登録している参加登録ユーザのユーザ情報と、が関連付けられた参加登録データに、前記参加要求をしたユーザのユーザ情報を、当該ユーザが所望する役割と関連付けて追加する追加手段(305)と、前記ゲームに参加する複数のユーザを選択する手段(306)であって、前記参加登録データに基づいて、前記役割ごとに、当該役割を担当するユーザを、当該役割に前記ユーザ情報が関連付けられた前記参加登録ユーザの中から選択する選択手段(306)と、を含む。
3-11)本発明の一態様に係るプログラムは、3-1)~3-9)の何れかに記載のゲームシステム(S)又は3-10)に記載のゲーム制御装置(10,30)としてコンピュータを機能させる。
3-12)本発明の一態様に係る情報記憶媒体は、3-11)のプログラムを記録したコンピュータで読み取り可能な情報記憶媒体である。
3-1)又は3-10)~3-12)に係る発明によれば、ゲームへの参加要求をしたユーザのユーザ情報を、当該ユーザが所望する役割と関連付けて参加登録データに追加して、役割ごとに、当該役割を担当するユーザを、当該役割にユーザ情報が関連付けられた参加登録ユーザの中から選択することで、例えば、ユーザが所望する役割を他のユーザに取られたり、所望する役割が空いている対戦部屋をいちいち探したりすることがなくなるので、ユーザが所望の役割を担当するための手間を軽減することができる。
3-2)本発明の一態様では、前記ゲームシステム(S)は、前記参加登録データに基づいて、各役割の参加登録状況を各ユーザに提示する提示手段(307)、を更に含む。各役割を所望するユーザが集まるまでゲームに参加するユーザの選択が行われないといった場合には、参加要求をしたユーザが待機する状態が続き、ユーザがいつまで待てばよいか分からずに不満を感じる可能性があるが、3-2)の態様によれば、各役割の参加登録状況が提示され、マッチングまでどの程度時間がかかるかを予め予測させるといったことができるので、ユーザの不満を解消することができる。
3-3)本発明の一態様では、前記複数の役割は、予め定められた役割の組み合わせに基づいて決定される。3-3)の態様によれば、予め定められた役割の組み合わせに基づいて複数の役割が決定されることで、複数の役割を決める手間を省くことができる。他にも例えば、複数種類の組み合わせを用意しておき、時期に応じて使用する組み合わせを変えるようにした場合には、時期によって役割に変化を与えることができ、ゲームの興趣性を向上させることができる。
3-4)本発明の一態様では、前記ゲームシステム(S)は、前記参加登録状況が提示されたユーザの操作に基づいて、当該ユーザが所望する役割を変更する役割変更手段(308)を更に含む。
3-4)の態様によれば、参加登録状況が提示されたユーザが所望する役割を変更することで、例えば、比較的空いている役割に変更して待ち時間を減らすといったことができ、ユーザの不満を効果的に解消することができる。
3-5)本発明の一態様では、前記ゲームでは、各ユーザのゲームオブジェクトが使用され、前記役割取得手段(304)は、前記参加要求をしたユーザのゲームオブジェクトと関連付けられた役割を、当該ユーザが所望する役割として取得する。3-5)の態様によれば、参加要求をしたユーザのゲームオブジェクトと関連付けられた役割を当該ユーザが所望する役割とすることで、ユーザがゲームに参加する前に所望する役割をいちいち選択しなくても済むので、ユーザの手間を効果的に軽減することができる。
3-6)本発明の一態様では、前記追加手段(305)は、前記参加要求をしたユーザが所望する役割が複数ある場合には、前記参加登録データに基づいて、当該ユーザが所望する複数の役割の中から選択した少なくとも1つの役割と関連付けて、当該ユーザのユーザ情報を前記参加登録データに追加する。3-6)の態様によれば、参加登録データが示す各役割の参加登録状況を考慮したうえで、ユーザ情報を関連付ける役割を選択することで、例えば、比較的空いている役割にユーザ情報を追加するといったことができるので、マッチングまでの待ち時間(ゲーム開始までの待ち時間)を短縮することができる。
3-7)本発明の一態様では、前記選択手段(306)は、前記複数の役割をそれぞれ所望する複数のユーザが集まった場合に、当該複数のユーザを選択し、前記選択手段(306)は、所定時間が経過しても、前記複数の役割をそれぞれ所望する複数のユーザが集まらなかった場合には、現時点で集まったユーザを選択し、前記ゲームシステム(S)は、前記参加登録データに基づいて、前記所定時間の長さを変更する時間変更手段(309)、を更に含む。3-7)の態様によれば、参加登録データが示す各役割の参加登録状況が、ゲームに参加するユーザを選択するための所定時間の長さに反映されるので、ゲームに参加するユーザを選択するまでにユーザを長時間待たせるといったことを防止することができる。
3-8)本発明の一態様では、前記ゲームでは、各ユーザの複数のゲームオブジェクトのうち、当該ユーザが指定したゲームオブジェクトが使用され、前記選択手段(306)は、前記複数の役割をそれぞれ所望する複数のユーザが集まった場合に、当該複数のユーザを選択し、前記ゲームシステム(S)は、前記選択手段(306)により選択された複数のユーザの各々が指定したゲームオブジェクトに、当該ユーザが所望する役割を割り当てる役割割当手段(310)を更に含み、前記選択手段(306)は、所定時間が経過しても、前記複数の役割をそれぞれ所望する複数のユーザが集まらなかった場合には、現時点で集まったユーザを選択し、前記役割割当手段(310)は、前記複数の役割をそれぞれ所望する複数のユーザが集まらなかった場合には、前記選択手段(306)により選択された複数のユーザの各々が指定しなかったゲームオブジェクトの中から、ユーザが集まらなかった役割を割り当てるゲームオブジェクトを決定する。3-8)の態様によれば、所定時間が経過しても複数の役割をそれぞれ所望する複数のユーザが集まらなかった場合には、現時点で集まったユーザを選択することで、ユーザがいつまで待ってもゲームに参加できないといった不満を防止することができる。更に、ユーザが指定しなかったゲームオブジェクトの中から、ユーザが集まらなかった役割を担当させることで、全く関係のないゲームオブジェクトが使用されるのではなく、ユーザのゲームオブジェクトが使用されるので、ゲームの興趣性を向上させることができる。
3-9)本発明の一態様では、前記ゲームでは、複数の第1の役割と、当該複数の第1の役割の各々の何れか一又は複数の第1の役割に属する詳細な役割である一又は複数の第2の役割と、があり、前記役割取得手段(304)は、前記参加要求をしたユーザが所望する第2の役割を取得し、前記参加登録データには、前記複数の第1の役割の各々と、前記ゲームへの参加登録のユーザのユーザ情報と、が関連付けられており、前記追加手段(305)は、前記参加要求をしたユーザが所望する第2の役割が属する第1の役割と関連付けて、当該ユーザのユーザ情報を前記参加登録データに追加し、前記ゲームシステム(S)は、前記参加登録データに基づいて、前記選択手段(306)により選択された複数のユーザの各々が担当する第2の役割を決定する役割決定手段(311)を更に含む。3-9)の態様によれば、参加要求をしたユーザが所望する第2の役割よりも広い第1の役割と関連付けて、当該ユーザのユーザ情報を参加登録データに追加することで、ユーザが集まりやすくなるので、マッチングまでの時間を早めることができる。