特許法第30条第2項適用 平成29年8月21日、https://itunes.apple.com/、https://itunes.apple.com/jp/app/id1117270703、https://play.google.com/、https://play.google.com/store/apps/details?id=jp.konami.pesam、https://www.konami.com/、https://www.konami.com/wepes/mobile/ja/
[1.ゲームシステムの全体構成]
以下、本発明に係る実施形態を図面に基づいて説明する。なお、図面において同一又は対応する構成には同一の符号を付し、繰り返しの説明を省略することがある。
図1は、ゲームシステムの全体構成を示す図である。図1に示すように、本実施形態に係るゲームシステムSは、第1ゲーム端末10A、第2ゲーム端末10B、第3ゲーム端末10C、ゲームサーバ30、及びドメインネームサーバ50を含む。例えば、第3ゲーム端末10Cとゲームサーバ30は、インターネットなどのネットワークNに接続され、第1ゲーム端末10A、第2ゲーム端末10B、及びドメインネームサーバ50は、無線LAN(Local Area Network)などのプライベートネットワークPNに接続される。
なお、以降では、第1ゲーム端末10A、第2ゲーム端末10B、及び第3ゲーム端末10Cを特に区別する必要のないときは、単にゲーム端末10と記載する。また、本実施形態では、ゲーム端末10が3台である場合を説明するが、ゲームシステムS内のゲーム端末10の台数に制限はなく、2台であってもよいし4台以上であってもよい。同様に、ゲームシステムS内のゲームサーバ30及びドメインネームサーバ50の台数に制限はなく、2台以上のゲームサーバ30又はドメインネームサーバ50が存在してもよい。また、ゲーム端末10、ゲームサーバ30、及びドメインネームサーバ50以外のコンピュータがゲームシステムSに含まれていてもよい。なお、ゲームシステムSは、プライベートネットワークPNや当該プライベートネットワークPN内のドメインネームサーバ50を含まなくてもよい。
ゲーム端末10は、ユーザが操作するコンピュータである。例えば、ゲーム端末10は、携帯端末(例えば、スマートフォンなどの携帯電話又はタブレット型コンピュータ)、パーソナルコンピュータ、携帯ゲーム機、据置ゲーム機、業務用ゲーム機、又は情報処理機能を備えた多機能型テレビジョン受像機(スマートテレビ)等である。なお、ゲームシステムSに含まれる各ゲーム端末10は、他のゲーム端末10と機種・性能・オペレーティングシステム等が異なってもよい。
図1に示すように、ゲーム端末10は、制御部11、記憶部12、通信部13、操作部14、及び表示部15を含む。制御部11は、少なくとも1つのマイクロプロセッサを含む。例えば、制御部11は、複数のマイクロプロセッサを含んでもよい。制御部11は、オペレーティングシステムやその他のプログラムに従って処理を実行する。記憶部12は、主記憶部(例えば、RAM)及び補助記憶部(例えば、不揮発性の半導体メモリ)を含む。記憶部12は、プログラムやデータを記憶する。なお、例えば、ゲーム端末10がパーソナルコンピュータ等である場合、記憶部12は、例えばハードディスクドライブ又はソリッドステートドライブ等の補助記憶部を含むようにしてもよい。通信部13は、通信モジュールや通信インタフェースを含む。通信部13は、ネットワークN又はプライベートネットワークPNを介してデータ通信を行う。
操作部14は、入力デバイスであり、例えば、ボタン、キー、レバー、ゲームコントローラ(ゲームパッド)、マウスやタッチパネルなどのポインティングデバイス、又はキーボード等を含んでもよい。また例えば、操作部14は、ユーザが音声又はジェスチャによって入力操作を行うためのマイクやカメラを含んでもよい。表示部15は、例えば、液晶表示パネル又は有機ELディスプレイ等であり、制御部11の指示に従って画面を表示する。なお、操作部14及び表示部15は、ゲーム端末10に内蔵されていなくともよく、ゲーム端末10に接続された外部装置であってもよい。
ゲームサーバ30は、サーバコンピュータである。図1に示すように、ゲームサーバ30は、制御部31、記憶部32、及び通信部33を含む。制御部31、記憶部32、及び通信部33のハードウェア構成は、それぞれ制御部11、記憶部12、及び通信部13と同様であってよい。例えば、ゲームサーバ30は、ゲームプログラムを記憶しており、ゲーム端末10からの要求に応じてゲームプログラムを配信する。
ドメインネームサーバ50は、サーバコンピュータである。図1に示すように、ドメインネームサーバ50は、制御部51、記憶部52、及び通信部53を含む。制御部51、記憶部52、及び通信部53のハードウェア構成は、それぞれ制御部11、記憶部12、及び通信部13と同様であってよい。例えば、ドメインネームサーバ50は、ホスト名やドメイン名などの名称からIPアドレスなどの情報を得るためのサーバであり、これらを関連付けて記憶部52に記憶する。ここでは、プライベートネットワークPN内のドメインネームサーバ50が利用されるので、外部のドメインネームサーバには情報が送信されない。
なお、記憶部12,32,52に記憶されるものとして説明するプログラムやデータは、例えば、ネットワークN又はプライベートネットワークPNを介してゲーム端末10、ゲームサーバ30、又はドメインネームサーバ50に供給されるようにしてもよい。また、ゲーム端末10、ゲームサーバ30、又はドメインネームサーバ50は、情報記憶媒体(例えば、光ディスク又はメモリカード等)に記憶されたプログラム又はデータを読み取るための読取部(例えば、光ディスクドライブ又はメモリカードスロット)を含むようにしてもよい。そして、情報記憶媒体を介してゲーム端末10、ゲームサーバ30、又はドメインネームサーバ50にプログラムやデータが供給されるようにしてもよい。
[2.ゲームの概要]
ゲームシステムSは、複数のユーザがプレイするゲームを実行する。ゲームとしては、複数のユーザが互いに対戦するゲームであってもよいし、複数のユーザが互いに協力するゲームであってもよい。本実施形態では、ゲーム内に生成された同じ対戦部屋に関連付けられた複数のユーザが互いに対戦するサッカーゲームが用いられる場合を一例として説明するが、ゲーム形式・ジャンルを問わず任意のゲームであってよく、例えば、サッカー以外のスポーツゲーム(例えば、野球ゲーム)、カードゲーム、アクションゲーム、ロールプレイングゲーム、シミュレーションゲーム、レースゲーム、ボードゲーム、又は格闘ゲームであってもよい。
対戦部屋とは、例えば、他のユーザと対戦するゲームをプレイすることを希望するユーザが関連付けられるゲーム内の部屋である。別の言い方をすれば、対戦部屋は、ゲームへの参加を宣言するための部屋である。また例えば、対戦部屋は、ゲームの中の世界に存在する仮想的な部屋である。また例えば、対戦部屋は、任意の名称で呼ばれてよく、例えば、ゲーム内に設定されたロビーと呼ばれてもよいし、仮想世界の中の場所で呼ばれてもよい。また例えば、対戦部屋は、データベース上のレコードであってもよいし、プログラムメモリ上のハッシュ構造を使った配列であったりしてもよい。
生成とは、例えば、ゲーム内に対戦部屋を生成することである。また例えば、生成とは、対戦部屋を示すデータをコンピュータ上に登録することである。
対戦部屋にユーザが関連付けられるとは、例えば、対戦部屋にユーザIDが関連付けられることである。例えば、対戦部屋IDにユーザIDが関連付けられることであり、対戦部屋IDとユーザIDとが同じレコードに格納されることである。別の言い方をすれば、ゲームをプレイすることの希望しない状態から希望する状態に変えることであり、ゲームをプレイしない状態からプレイ可能な状態に変えることである。
なお、本実施形態では、対戦部屋にユーザが関連付けられることを、対戦部屋にユーザが入室すると記載することもあるが、実在する対戦部屋に人間が入室するわけではなく、ゲームシステムSでは、対戦部屋にユーザIDを関連付けるという処理が実行されることになる。このため、本実施形態において、ユーザが対戦部屋に入室すると記載している箇所については、ユーザを対戦部屋に関連付けると読み替えることができる。この点は、後述する「退室」についても同様であり、対戦部屋とユーザとの関連付けを解除することを、対戦部屋からユーザが退室すると記載することもあるが、実在する対戦部屋から人間が退室するのではなく、ゲームシステムSでは、対戦部屋にユーザIDが関連付けられた状態から関連付けられない状態にする処理が実行されることになる。このため、本実施形態において、ユーザが対戦部屋から退室すると記載している箇所については、ユーザと対戦部屋との関連付けを解除すると読み替えることができる。
本実施形態のゲームでは、複数の対戦形式が用意されている。ここでは、対戦形式の一例として、無線通信可能な端末同士で通信しながら実行されるローカル対戦と、ローカル対戦とは異なるオンライン対戦と、を説明する。なお、無線通信とは、例えば、電波による通信であり、伝送路として有線を使用しない通信である。
例えば、ローカル対戦では、複数のユーザがゲーム端末10を持ち寄って集まり、各ゲーム端末10が互いにP2Pで直接的に通信しながらゲームを実行する。別の言い方をすれば、ローカル対戦では、各ゲーム端末10が無線通信における通信範囲内にいる状態で、互いに通信しながらゲームが実行される。一方、オンライン対戦は、例えば、特に複数のユーザがゲーム端末10を持ち寄って集まる必要はなく、遠く離れたユーザと対戦することが可能である。別の言い方をすれば、オンライン対戦は、場所を選ばずにプレイすることができ、各ゲーム端末10は、ゲームサーバ30等を介して間接的に通信しながらゲームを実行する。
ここでは、第1ゲーム端末10Aを操作するユーザAが対戦部屋を生成し、第2ゲーム端末10Bを操作するユーザBと、第3ゲーム端末10Cを操作するユーザCと、が当該対戦部屋に入室する場合を説明する。例えば、ユーザAが第1ゲーム端末10Aを操作してゲームプログラムが起動すると、メニュー画像が表示部15に表示される。
図2は、メニュー画像の一例を示す図である。図2に示すように、メニュー画像G1は、ゲームに用意された種々のモードを選択するための画像である。例えば、メニュー画像G1には、期間限定のゲームイベントに参加するためのイベントボタンB10、オンライン対戦をプレイするためのオンライン対戦ボタンB11、1シーズンを通しての試合成績を競うシーズンマッチボタンB12,B13、及びローカル対戦をプレイするためのローカル対戦ボタンB14が表示される。
本実施形態では、主に、ローカル対戦に係る処理を説明する。このため、以降では、ユーザAがローカル対戦ボタンB14を選択した場合の画面遷移を説明する。例えば、ローカル対戦は、複数のモードが用意されており、ユーザAがローカル対戦ボタンB14を選択すると、モードを選択するためのダイアログが表示される。
図3は、ユーザがローカル対戦ボタンB14を選択した場合のメニュー画像の一例を示す図である。図3に示すように、ダイアログD15には、ローカル対戦における複数のモードが選択可能に表示される。ここでは、ローカル対戦のモードとして、1対1で1試合のみプレイするエキシビションと、複数のユーザが総当たり戦で対戦するローカルリーグと、の2種類が用意されている場合を説明するが、ローカル対戦のモードは、1種類だけであってもよいし3種類以上が用意されていてもよい。例えば、勝ち抜き戦が行われるトーナメント形式のモードが用意されていてもよいし、総当たり戦で予選リーグを行い、勝ち抜き戦の決勝リーグが行わるといったモードが用意されていてもよい。
例えば、ダイアログD15には、エキシビションをプレイするためのエキシビションボタンB150が表示される。ユーザAがエキシビションボタンB150を選択すると、無線通信可能な他の端末と通信しながら1対1で1試合のみのローカル対戦をプレイすることができる。また例えば、ダイアログD15には、エキシビションの過去の戦績を表示させるための戦績ボタンB151が表示される。ユーザAが戦績ボタンB151を選択すると、ユーザAが過去にプレイしたエキシビションの戦績を表示させることができる。また例えば、ダイアログD15には、エキシビションの試合の履歴を表示させるための試合履歴ボタンB152が表示される。ユーザAが試合履歴ボタンB152を選択すると、ユーザが過去にプレイしたエキシビションの履歴を表示させることができる。
また例えば、ダイアログD15には、ローカルリーグをプレイするためのローカルリーグボタンB153が表示される。ユーザAがローカルリーグボタンB153を選択すると、ローカルリーグをプレイすることができる。また例えば、ダイアログD15には、ローカルリーグの過去の参加履歴を表示させるための参加履歴ボタンB154が表示される。ユーザAが参加履歴ボタンB154を選択すると、ローカルリーグの参加履歴を表示させることができる。なお、ユーザAが戻るボタンB155を選択すると、ダイアログD15が消去される。
ここでは、主に、ローカルリーグに係る処理を説明する。このため、以降では、ユーザAがローカルリーグボタンB153を選択した場合の画面遷移を説明する。例えば、ユーザAがローカルリーグボタンB153を選択すると、参加可能な対戦部屋を検索するための対戦部屋検索画像が表示部15に表示される。
図4は、対戦部屋検索画像の一例を示す図である。図4に示すように、対戦部屋検索画像G2は、ユーザAが入室可能な対戦部屋の一覧を表示するための表示領域A20を含む。仮に、ユーザAの近くにいるユーザB,Cが対戦部屋を生成していれば、表示領域A20には、当該対戦部屋が表示されるが、ここでは、まだ誰も対戦部屋を生成していないので、表示領域A20には、対戦部屋は表示されず、対戦部屋を検索中であることを示すメッセージが表示される。
また例えば、対戦部屋検索画像G2には、対戦部屋を新たに生成するための新規作成ボタンB21が表示される。ユーザAが新規作成ボタンB21を選択すると、新たに対戦部屋を生成することができる。例えば、ユーザAがローカル対戦ボタンB14を選択すると、対戦部屋の名前を入力するためのダイアログが表示される。なお、ユーザAが再読み込みリロードボタンB22を選択すると、対戦部屋検索画像G2のリロードをすることができる。
図5は、ユーザAが新規作成ボタンB21を選択した場合の対戦部屋検索画像G2の一例を示す図である。図5に示すように、ダイアログD23には、対戦部屋の名前を入力するための入力フォームF230が表示される。例えば、ユーザAは、自分が生成する対戦部屋に好きな名前を付けることができる。なお、ユーザAがキャンセルボタンB231を選択すると、ダイアログD23が消去される。
また例えば、対戦部屋検索画像G2には、ユーザAが入力した対戦部屋の名前を確定するためのOKボタンB232が表示される。ユーザAが入力フォームF230に対戦部屋の名前を入力してOKボタンB232を選択すると、当該名前の対戦部屋を生成することができる。なお、ここでは、ダイアログD23から対戦部屋の名前だけを設定可能としている場合を説明するが、名前以外の設定ができるようにしてもよく、例えば、対戦部屋に入室可能なユーザ数などを設定可能であってもよい。
図6は、ユーザAが対戦部屋を生成した場合の対戦部屋検索画像G2の一例を示す図である。図6に示すように、対戦部屋の生成が完了したことを示すダイアログD24が対戦部屋検索画像G2に表示される。ユーザAがOKボタンB240を選択すると、対戦部屋に入室したユーザを示す対戦部屋画像が表示部15に表示される。
図7は、対戦部屋画像の一例を示す図である。図7に示すように、対戦部屋画像G3は、対戦部屋に入室したユーザに関する情報を表示するための表示領域A30を含む。本実施形態では、対戦部屋に4人まで入室可能な場合を説明するが、対戦部屋に入室可能なユーザ数は、4人に限られず、2人又は3人であってもよいし、5人以上であってもよい。例えば、表示領域A30は、表示領域A300~A303を含み、入室中のユーザの詳細を表示可能となっている。
本実施形態では、対戦部屋を生成したユーザが当該対戦部屋に関連付けられるものとして説明するが、特に対戦部屋を生成したユーザは対戦部屋に関連付けられなくてもよい。即ち、対戦部屋を生成したユーザは、必ずしも当該対戦部屋に関連付けられなくてもよい。ここでは、ユーザAが対戦部屋を生成し、ユーザAが対戦部屋に関連付けられているので、表示領域A300には、ユーザAに関する情報が表示される。例えば、表示領域A300には、ユーザAが使用するサッカーチームの名前、ユーザAの名前、及び過去のローカルリーグにおける優勝回数が表示される。
例えば、対戦部屋画像G3が第1ゲーム端末10Aに表示されると、第1ゲーム端末10は、第2ゲーム端末10B及び第3ゲーム端末10Cの各々との無線通信の確立を試みることになる。一方、第2ゲーム端末10Bでは、ユーザBの操作に基づいて、第1ゲーム端末10Aとの無線通信を確立する処理が実行され、第3ゲーム端末10Cでは、ユーザCの操作に基づいて、第1ゲーム端末10Aとの無線通信を確立する処理が実行される。
無線通信としては、任意の無線通信規格を利用可能であり、例えば、Wi-Fi Direct(登録商標)、Bluetooth(登録商標)、IEEE802.11規格の無線LAN、赤外線通信、又はiBeacon(登録商標)などが利用されてもよい。更に、1つの無線通信規格だけに限られず、複数の無線通信規格が用いられるようにしてもよい。なお、無線LANが用いられる場合には、第1ゲーム端末10Aは、プライベートネットワークPN内のドメインネームサーバ50に対し、自身のIPアドレスと、対戦部屋に関する情報と、を関連付けて登録しておき、第2ゲーム端末10B及び第3ゲーム端末10Cに当該情報を取得させるようにしてもよい。他の無線通信規格については、第2ゲーム端末10B及び第3ゲーム端末10Cは、第1ゲーム端末10Aから直接的に、対戦部屋に関する情報を取得してもよい。
ここでは、ユーザBが第2ゲーム端末10Bを操作して、第1ゲーム端末10Aとの無線通信を確立させ、ユーザAが生成した対戦部屋に入室する場合を説明する。第2ゲーム端末10Bも図2に示すメニュー画像G1を表示可能であり、ユーザBがローカル対戦ボタンB14を選択し、ダイアログD15からローカルリーグボタンB153を選択すると、第2ゲーム端末10Bに対戦部屋検索画像G2が表示される。
図8は、第2ゲーム端末10Bに表示される対戦部屋検索画像G2の一例を示す図である。例えば、第2ゲーム端末10Bが第1ゲーム端末10Aと無線通信をすることによって、ユーザAが対戦部屋を生成済みであることが特定され、図8に示すように、表示領域A20には、ユーザAが生成した対戦部屋に入室するための入室ボタンB200が表示される。例えば、入室ボタンB200には、対戦部屋の名前と、対戦部屋を生成したユーザAの名前と、が表示される。なお、入室ボタンB200には、他の情報が表示されるようにしてもよく、例えば、ユーザAのアイコン画像が表示されてもよいし、ユーザAのサッカーチームが表示されてもよい。
例えば、ユーザBが入室ボタンB200を選択すると、ユーザAが生成した対戦部屋に入室する。なお、ユーザCも同様の流れによって、ユーザAが生成した対戦部屋に入室することができる。ユーザB,CがユーザAの対戦部屋に入室すると、第1ゲーム端末10Aに表示された対戦部屋画像G3の表示が変わり、対戦部屋にユーザB,Cが入室したことが分かるようになっている。
図9は、ユーザB,CがユーザAの対戦部屋に入室した場合の対戦部屋画像G3の一例を示す図である。図9に示すように、例えば、表示領域A302には、ユーザBの詳細情報が表示され、例えば、ユーザBが使用するサッカーチームの名前、ユーザBの名前、及び過去のローカルリーグにおける優勝回数が表示される。また例えば、表示領域A303には、ユーザCの詳細情報が表示され、例えば、ユーザCが使用するサッカーチームの名前、ユーザCの名前、及び過去のローカルリーグにおける優勝回数が表示される。
例えば、ユーザAは、ユーザB,Cが対戦部屋に入室したことを確認すると、ローカルリーグを開始するための所定操作を行う。その後、例えば、ユーザA,B,Cの中で総当たり戦となるように対戦組み合わせが決定され、当該対戦組み合わせを示す対戦組み合わせ画像G4が表示部15に表示される。
図10は、対戦組み合わせ画像G4の一例を示す図である。図10に示すように、対戦組み合わせ画像G4は、ユーザAの試合の対戦組み合わせを表示するための表示領域A40を含む。例えば、表示領域A40に示すように、ユーザAは、第1試合でユーザBと対戦し、その後に、第2試合でユーザCと対戦する。
また例えば、表示領域A40には、対戦部屋から退室するための退室ボタンB400が表示される。ユーザAが退室ボタンB400を選択すると、入室中の対戦部屋から退室することができる。第2ゲーム端末10B及び第3ゲーム端末10Cにも、図10と同様の対戦組み合わせ画像G4が表示されており、ユーザB,Cは、退室ボタンB400を選択することで対戦部屋から退室することができる。
なお、退室ボタンB400は、対戦組み合わせ画像G4以外の画像に表示されるようにしてもよく、例えば、メニュー画像G1、対戦部屋検索画像G2、及び対戦部屋画像G3の少なくとも1つに退室ボタンB400が表示されてもよいし、後述するマッチング画像やゲーム画像において退室ボタンB400が表示されてもよい。
また、ユーザが対戦部屋から退室するのは、退室ボタンB400が選択された場合に限られない。特に退室ボタンB400が表示されず、予め定められた条件が満たされた場合にユーザが退室してもよい。例えば、一定時間の間、ユーザが何の操作もしなかった場合に、当該ユーザを退室させるようにしてもよい。また例えば、一定時間の間、ゲームサーバ30がゲーム端末10から何の情報も受信しなかった場合に、当該ゲーム端末10のユーザを退室させるようにしてもよい。また例えば、一定時間の間、対戦部屋を生成したユーザのゲーム端末10と無線通信できなかったり、プライベートネットワークPNの通信範囲外となったりした場合に、ユーザを退室させるようにしてもよい。
対戦組み合わせ画像G4が表示されると、ローカルリーグの試合が開始する。例えば、ユーザA,B,Cが参加するローカルリーグでは、総当たり戦で合計3試合が行われて勝ち点や得失点差を競う。例えば、対戦組み合わせ画像G4が表示された後に、ユーザAが第1試合をプレイするための所定操作をすると、第1試合で対戦するユーザBの第2ゲーム端末10Bとマッチング処理をするためのマッチング画像が表示部15に表示される。
図11は、マッチング画像の一例を示す図である。図11に示すように、マッチング画像G5には、試合を開始するための前処理であるマッチング中であることを示すメッセージが表示される。例えば、マッチング中においては、第1ゲーム端末10Aと第2ゲーム端末10Bとの間で、ゲームに必要なデータ(例えば、試合で使用するキャラクタのデータやユーザが選択した戦術・フォーメーションなどのデータ)が送受信される。
マッチング処理が完了すると、第1試合が開始し、実行中のゲームの様子を示すゲーム画像が表示部15に表示される。なお、第1試合が行われている間は、ユーザCは第1試合が終了するのを待機するが、その間も第3ゲーム端末10Cと、第1ゲーム端末10A及び第2ゲーム端末10Bと、の間の無線通信は維持されているものとする。
図12は、試合開始後に表示されるゲーム画像の一例を示す図である。図12に示すように、ゲーム画像G6には、例えば、ゲームキャラクタが配置されたゲーム空間を仮想カメラから見た様子が表示される。なお、ローカルリーグにおける試合の進行方法自体は、公知の種々の進行方法を適用可能であり、例えば、ユーザAとユーザBは、それぞれ自分のチームの何れかのキャラクタを操作して得点をあげることを目指す。第1試合が終了すると、第1試合の結果等が表示された後に、対戦組み合わせ画像G4に戻る。
図13は、第1試合が終了した場合の対戦組み合わせ画像G4の一例を示す図である。図13に示すように、対戦組み合わせ画像G4の表示領域A40には、終了した第1試合の対戦組み合わせが消去され、第2試合の対戦組み合わせが表示される。即ち、対戦組み合わせ画像G4では、ローカルリーグにおいて、どの試合が残っているかを容易に把握できるようになっている。以降、第1試合と同様の流れにより、ユーザAとユーザCとの第2試合と、ユーザBとユーザCとの第3試合と、が実行される。
例えば、第2試合では、第1ゲーム端末10Aと第3ゲーム端末10Cとの間でマッチング処理が実行され、無線通信しながらゲームが実行されることになる。また例えば、第3試合では、第2ゲーム端末10Bと第3ゲーム端末10Cとの間でマッチング処理が実行され、無線通信しながらゲームが実行されることになる。ローカルリーグの全試合が終了すると、ローカルリーグにおける表彰式を示す表彰式画像が表示部15に表示される。
図14は、表彰式画像の一例を示す図である。図14に示すように、表彰式画像G7には、仮想世界において表彰式が行われる様子が表示される。例えば、勝ち点が高い順にユーザの順位が決まり、勝ち点が同じ場合には得失点差や直接対決の結果によって順位が決まる。表彰式画像G7が表示されると、ユーザA,B,Cの間で行われるローカルリーグは終了する。
なお、ローカルリーグを最後までプレイした場合(即ち、表彰式画像G7がゲーム端末10に表示された場合)には、ユーザA,B,Cにゲームアイテムやゲーム内通貨などの報酬が与えられるようにしてもよい。その後、ゲーム端末10間の無線通信が切断されるようにしてもよいし、無線通信を維持したままローカルリーグを繰り返しプレイできるようにしてもよい。また、表彰式画像G7が表示されてローカルリーグが終了した場合に対戦部屋に関するデータが消滅してもよいし、対戦部屋を消滅させるための操作をユーザが行った場合に対戦部屋に関するデータが消滅してもよい。
上記のように、表彰式画像G7が表示される前であったとしても(即ち、ローカルリーグを最後までプレイしなくても)、ユーザは、退室ボタンB400を選択することで対戦部屋から途中退室できるようになっている。対戦部屋を生成したユーザが途中退室したり、ユーザの退室によって対戦部屋内の合計人数が一定人数未満(例えば、3人未満)になったりしたローカルリーグは、最後まで試合をすることができず、そのままゲームサーバ30に不要なデータが残ってしまうため、ゲームデータの消費量が増加する要因となる。
このため、本実施形態では、ローカルリーグに参加した何れかのユーザが途中退室すると、対戦部屋を生成したユーザが、一定時間の間、新たな対戦部屋を生成することができないようにしている。別の言い方をすれば、ローカルリーグに参加した何れかのユーザが途中退室すると、対戦部屋を生成したユーザに対するペナルティが与えられる。ユーザにペナルティが与えられると、対戦部屋検索画像G2の新規作成ボタンB21を選択しても、新たな対戦部屋を生成することができない。なお、ペナルティが与えられるのは、対戦部屋を生成したユーザだけでなく、対戦部屋に入室したユーザ全員であってもよいし、対戦部屋に入室したユーザの一部だけにペナルティが与えられるようにしてもよい。
図15は、ペナルティが与えられた場合の対戦部屋検索画像G2の一例を示す図である。図15に示すように、ダイアログD25には、対戦部屋を生成できないことを示すメッセージが表示され、ユーザが新規作成ボタンB21を選択しても、新たな対戦部屋を生成することはできない。なお、ユーザが新規作成ボタンB21を選択すること自体ができないようにしてもよい。例えば、新規作成ボタンB21をグレーアウトしてもよいし、新規作成ボタンB21自体を表示させないようにしてもよい。また、ダイアログD25にペナルティが課される残り時間を表示させてもよい。
なお、1人のユーザが生成できる対戦部屋を1つまでとしてもよいが、1人のユーザが複数の対戦部屋を生成できるようにする場合には、何れか1つの対戦部屋で途中退室が発生した場合にペナルティが与えられるようにしてもよいし、所定個数の対戦部屋で途中退室が発生した場合にペナルティが与えられるようにしてもよい。本実施形態では、あるユーザが生成した対戦部屋のうち、3つの対戦部屋で途中退室が発生した場合に、当該ユーザに対してペナルティが与えられるようになっている。
以上のように、本実施形態のゲームシステムSでは、あるユーザが生成した対戦部屋で途中退室が発生した場合に、当該ユーザにペナルティを与えることで、ローカルリーグが終了しない対戦部屋が乱立することを防止し、ゲームシステムS内のゲームデータの消費量の増加を防止することができるようになっている。以降、当該構成の詳細を説明する。
[3.ゲームシステムにおいて実現される機能]
図16は、ゲームシステムSで実現される機能のうち、本発明に関連する機能を示す機能ブロック図である。本実施形態では、主にゲーム端末10とゲームサーバ30の機能を説明する。
[3-1.ゲームサーバで実現される機能]
図16に示すように、ゲームサーバ30では、データ記憶部300、生成部301、入室部302、退室部303、第1判定部304、第2判定部305、第3判定部306、第4判定部307、報酬付与部308、及び表示制御部309が実現される。
[3-1-1.データ記憶部]
データ記憶部300は、記憶部32を主として実現される。データ記憶部300は、ゲームを実行するために必要なデータを記憶する。ここでは、データ記憶部300が記憶するデータの一例として、ユーザデータベースDB1と、対戦部屋データベースDB2と、を説明する。
図17は、ユーザデータベースDB1のデータ格納例を示す図である。図17に示すように、ユーザデータベースDB1は、ゲームシステムSを利用するユーザに関するデータであり、例えば、ユーザを一意に識別するユーザIDに関連付けて、ユーザの名前、画像、サッカーチームの名前、及びペナルティ情報が格納される。なお、ここでは、ユーザを一意に識別する情報は、ユーザを識別可能な情報であればよく、例えば、ユーザIDではなくユーザ名が用いられてもよい。
ペナルティ情報は、新たな対戦部屋を生成できないようにするペナルティの発生中であるか否かを示す情報である。例えば、ペナルティ情報は、途中退室が発生した回数、ペナルティが発生した日時、及び発生中フラグを含む。
途中退室が発生した回数とは、例えば、ユーザが生成した対戦部屋のうち、何個の対戦部屋で途中退室が発生したかを示す情報である。ユーザが生成した対戦部屋で途中退室が発生するたびに回数が増加し、回数が閾値(ここでは3とする)以上になった場合に、ペナルティが発生する。
なお、閾値は3に限られず、2であってもよいし、4以上であってもよい。更に、ユーザによって閾値が異なってもよい。例えば、ペナルティが発生したユーザの閾値を減少させてペナルティが発生しやすくしてもよいし、逆に、ペナルティが一定期間発生しなかったユーザの閾値を増加させてペナルティが発生しにくくしてもよい。
発生中フラグは、ペナルティが発生中であるか否かを示す情報である。例えば、発生中フラグがオンの場合はペナルティの発生中であることを示し、発生中フラグがオフの場合はペナルティの発生中ではないことを示す。途中退室が発生した回数が閾値以上になった場合に、発生中フラグがオンになり、ペナルティが発生する。一方、ペナルティが発生してから一定時間が経過すると、発生中フラグがオフになり、ペナルティが解除される。この場合、途中退室が発生した回数はリセットされる。
図18は、対戦部屋データベースDB2のデータ格納例を示す図である。図18に示すように、対戦部屋データベースDB2は、ユーザが生成した対戦部屋に関するデータであり、例えば、対戦部屋を一意に識別する対戦部屋IDに関連付けて、対戦部屋の名前、対戦部屋を生成したユーザに関する生成ユーザ情報、対戦部屋に入室したユーザに関する入室ユーザ情報、及び対戦部屋におけるゲームの状況や結果などを示すゲームデータが格納される。以降、対戦部屋データベースDB2に格納される個々のレコードを部屋情報と記載する。
生成ユーザ情報としては、例えば、対戦部屋を生成したユーザのユーザID、当該ユーザのゲーム端末10を識別するための端末識別情報、当該ユーザの名前、及び当該ユーザの優勝回数等の情報が格納される。また例えば、端末識別情報は、ゲーム端末10を識別可能な情報であればよく、例えば、IPアドレスや個体識別情報などである。入室ユーザ情報としては、例えば、対戦部屋に入室したユーザのユーザID、当該ユーザのゲーム端末10を識別するための端末識別情報、当該ユーザの名前、及び当該ユーザの優勝回数等の情報が格納される。
ゲームデータとしては、例えば、対戦部屋で実行されるゲームの現在の状況やローカルリーグの結果が格納される。例えば、ゲームデータには、対戦部屋内で行われる試合ごとに、当該試合で対戦するユーザのユーザID、試合の状況情報、及び試合の結果情報が格納される。例えば、状況情報は、ゲーム空間におけるキャラクタの位置・姿勢・向き・移動方向・移動方向、ボールの位置・移動方向・移動速度、仮想カメラの位置・視線方向、試合の経過時間、キャラクタの交代状況、及び両チームの得点が格納される。試合の結果情報は、試合の勝敗、両チームの得点、試合のスタッツ情報(例えば、ボール支配率や平均走行距離)などが格納される。ゲームデータには、他にも各ユーザの勝利数・敗北数・引き分け数・勝ち点・順位などの情報が格納されていてもよい。
なお、データ記憶部300に記憶されるデータは、上記の例に限られない。データ記憶部300は、ゲームに必要なデータを記憶すればよい。例えば、データ記憶部300は、ユーザのサッカーチームのキャラクタに関するデータ(例えば、キャラクタの名前や能力パラメータなど)を記憶してもよい。また例えば、データ記憶部100は、ユーザが保有するゲームアイテムやゲーム内通貨に関するデータを記憶してもよい。また例えば、データ記憶部100は、ユーザが参加したエキシビションの過去の戦績・試合履歴やローカルリーグの参加履歴を記憶してもよい。
[3-1-2.生成部]
生成部301は、制御部31を主として実現される。生成部301は、ユーザの要求に基づいて対戦部屋を生成する。要求とは、例えば、対戦部屋を生成するための操作をすることである。また例えば、要求は、当該操作が行われたことを示す情報をゲームサーバ30に送信することである。以降、この要求を生成要求という。本実施形態では、ユーザが新規作成ボタンB21を選択すると生成要求が行われる。
生成要求は、所定形式のデータが送信されることによって行われるようにすればよく、例えば、生成要求には、ユーザIDと、入力フォームF230に入力された対戦部屋の名前と、が含まれるものとするが、生成要求には、他の情報が含まれてもよく、例えば、ゲーム端末10の識別情報、ユーザ名、及びユーザの優勝回数等が含まれていてもよい。
本実施形態では、生成部301がゲームサーバ30において実現されるので、生成部301は、ゲーム端末10から生成要求を受信したか否かを判定する。生成要求を受信したと判定された場合、生成部301は、生成要求に含まれる情報に基づいて、対戦部屋を生成し、対戦部屋データベースDB2を更新する。
例えば、生成部301は、対戦部屋の対戦部屋IDを生成する。対戦IDは、予め定められたID生成ルールによって生成されるようにすればよく、他の対戦部屋の対戦IDと重複しないように生成すればよい。そして、制御部31は、対戦部屋データベースDB2に新たなレコードを生成し、生成した対戦部屋IDに関連付けて、対戦部屋名、対戦部屋を生成したユーザのユーザID、端末識別情報、及び優勝回数を生成ユーザ情報・入室ユーザ情報に格納する。対戦部屋データベースDB2にこれらの情報が格納されることによって、対戦部屋の生成が完了する。
本実施形態では、ユーザは複数の対戦部屋を生成可能なので、生成部301は、ユーザの生成要求が行われるたびに対戦部屋を生成する。例えば、ユーザは、自分が生成した対戦部屋が残っている状態で、新たな対戦部屋の生成要求をすることができる。別の言い方をすれば、ユーザは繰り返し生成要求をすることができ、生成部301は、対戦部屋を繰り返し生成することができる。
[3-1-3.入室部]
入室部302は、制御部31を主として実現される。入室部302は、ユーザの入室要求に基づいて対戦部屋にユーザを関連付ける。先述したように、対戦部屋にユーザを関連付けることは、ユーザが対戦部屋に入室することを意味するので、入室部302は、ユーザの入室要求に基づいて対戦部屋にユーザを入室させることになる。
入室とは、例えば、対戦部屋にユーザが関連付けられない状態から関連付けられる状態に変化させることである。例えば、対戦部屋にユーザが関連付けられることは、対戦部屋にユーザが入室することを意味する。また例えば、対戦部屋IDにユーザIDが関連付けられることが入室に相当する。また例えば、対戦部屋IDとユーザIDとが同じレコードに格納されることが入室に相当する。別の言い方をすれば、ゲームをプレイすることの希望しない状態から希望する状態に変えることであり、ゲームをプレイしない状態からプレイ可能な状態に変えることである。
入室要求は、例えば、対戦部屋に入室するための操作をすることである。また例えば、入室要求は、当該操作が行われたことを示す情報をゲームサーバ30に送信することである。本実施形態では、ユーザが入室ボタンB23を選択すると入室要求が行われる。入室要求は、所定のデータ形式で行われるようにすればよく、例えば、ユーザが指定した対戦部屋の対戦部屋ID、ユーザID、端末識別情報、ユーザ名、及び優勝回数等の情報を含む。ユーザが指定した対戦部屋とは、入室ボタンB23を選択することで入室可能な対戦部屋である。例えば、入室ボタンB23と、入室可能な対戦部屋の対戦部屋IDと、は予め関連付けられており、ユーザが入室ボタンB23を選択した場合に、入室対象となる対戦部屋の対戦部屋IDを特定可能となっている。
本実施形態では、入室部302がゲームサーバ30において実現されるので、入室部302は、ゲーム端末10から入室要求を受信したか否かを判定する。入室要求を受信したと判定された場合、生成部301は、入室要求に含まれる情報に基づいて、対戦部屋にユーザを入室させる。例えば、入室部302は、対戦部屋データベースDB2を参照し、入室要求に含まれる対戦IDが格納されたレコードの入室ユーザ情報に、入室要求に含まれるユーザID、端末識別情報、ユーザ名、及び優勝回数等の情報を格納する。ユーザに関するこれらの情報が対戦部屋データベースDB2に格納されると、対戦部屋への入室が完了する。
[3-1-4.退室部]
退室部303は、制御部31を主として実現される。退室部303は、対戦部屋に関連付けられたユーザの関連付けを解除する。退室部303は、解除手段の一例である。
関連付けを解除するとは、例えば、対戦部屋にユーザが関連付けられた状態から関連付けられない状態に変化させることである。関連付けを解除するとは、対戦部屋から退室することである。例えば、対戦部屋IDにユーザIDが関連付けられなくなることが解除に相当する。また例えば、対戦部屋IDとユーザIDとが同じレコードに格納されなくなることが解除に相当する。別の言い方をすれば、ゲームをプレイすることの希望を解除することであり、ゲームをプレイ可能な状態からプレイしない状態に変えることである。
例えば、退室部303は、ユーザの退室要求に基づいて対戦部屋からユーザを退室させる。退室要求は、例えば、対戦部屋に退室するための操作をすることである。また例えば、退室要求は、当該操作が行われたことを示す情報をゲームサーバ30に送信することである。本実施形態では、ユーザが退室ボタンB400を選択すると退室要求が行われる。
退室要求は、所定のデータ形式で行われるようにすればよく、例えば、ユーザが指定した対戦部屋の対戦部屋ID、ゲーム端末10のユーザID、端末識別情報、ユーザ名、及び優勝回数等の情報を含む。ここでのユーザが指定した対戦部屋とは、退室ボタンB400を選択することで退室可能な対戦部屋である。例えば、退室ボタンB400と、退室可能な対戦部屋の対戦部屋IDと、は予め関連付けられており、ユーザが退室ボタンB400を選択した場合に、退室対象となる対戦部屋の対戦部屋IDを特定可能となっている。
本実施形態では、退室部303がゲームサーバ30において実現されるので、退室部303は、ゲーム端末10から退室要求を受信したか否かを判定する。退室要求を受信したと判定された場合、生成部301は、退室要求に含まれる情報に基づいて、対戦部屋からユーザを退室させる。例えば、退室部303は、対戦部屋データベースDB2を参照し、退室要求に含まれる対戦IDが格納されたレコードの入室ユーザ情報から、退室要求に含まれるユーザID、端末識別情報、ユーザ名、及び優勝回数等の情報を削除する。ユーザに関するこれらの情報が対戦部屋データベースDB2から削除されると、対戦部屋への退室が完了する。
なお、対戦部屋からユーザを退室させるにあたり、対戦部屋データベースDB2から情報を削除する必要はなく、例えば、ユーザが退室済みであるか否かを示すフラグを用意しておき、退室部303は、入室ユーザ情報を残したまま当該フラグの値を変更することによって、ユーザが退室した状態となるようにしてもよい。
また、先述したように、退室部303は、ユーザが特に退室要求をしなかったとしても、予め定められた条件が満たされた場合にユーザを退室させてもよい。例えば、退室部303は、ゲーム端末10との通信内容に基づいて、一定時間の間、ユーザが何の操作もしない状態が継続したか否かを判定し、一定時間の間、ユーザが何の操作もしなかったと判定した場合に、当該ユーザを退室させるようにしてもよい。
また例えば、退室部303は、ゲーム端末10との通信内容に基づいて、一定時間の間、ゲーム端末10から何の情報も受信しない状態が継続したか否かを判定し、一定時間の間、ゲーム端末10から何の情報も受信しなかったと判定した場合に、当該ユーザを退室させるようにしてもよい。また例えば、退室部303は、一定時間の間、対戦部屋を生成したユーザのゲーム端末10に対し、無線通信できない他のゲーム端末10が存在するか否かを問い合わせ、当該問い合わせに対する応答結果に基づいて、当該他のゲーム端末10のユーザを退室させてもよい。また例えば、退室部303は、プライベートネットワークPN内の通信機器に対し、通信範囲外となったゲーム端末10が存在するか否かを問い合わせ、当該問い合わせに対する応答結果に基づいて、当該ゲーム端末10のユーザを退室させてもよい。
[3-1-5.第1判定部]
第1判定部304は、制御部31を主として実現される。第1判定部304は、対戦部屋(ユーザの要求に基づいて生成された対戦部屋)に関連付けられたゲームの実行状況が所定の条件を満たすか否かを判定する。
対戦部屋に関連付けられたゲームとは、例えば、対戦部屋の中で行われるゲームであり、対戦部屋に関連付けられたユーザが対戦するゲームである。なお、先述したように、対戦部屋にユーザが関連付けられるとは、例えば、対戦部屋にユーザIDが関連付けられることである。また例えば、対戦部屋に関連付けられたゲームは、ユーザが、同じ対戦部屋に関連付けられた他のユーザと対戦するゲームである。また例えば、対戦部屋に関連付けられたゲームは、対戦部屋に関連付けられた複数のユーザが一緒に遊ぶゲームである。また例えば、対戦部屋に関連付けられたゲームは、対戦部屋IDを識別する情報に、ゲームの状況を示すゲームデータが関連付けられるゲームである。
ゲームの実行状況とは、例えば、ゲームがどの程度進行しているかであり、ゲームデータにより特定される状況である。例えば、対戦が終わったか否かである。また例えば、ゲームの実行状況は、所定回数の対戦が終わったか否かである。複数回の対戦が行われる場合には、ゲームの実行状況は、何回の対戦が終了したかである。また例えば、ゲームの実行状況は、ゲーム開始からの経過時間である。また例えば、ゲームの実行状況は、複数のステージを順番に進めるゲームであれば、現在のステージである。また例えば、ゲームの実行状況は、スコアを獲得するゲームであれば、現在のスコアである。スポーツゲームであれば、ゲームの実行状況は、例えば試合がどの程度進行しているかである。野球ゲームであれば、ゲームの実行状況は、例えば現在のイニングである。サッカーゲームであれば、ゲームの実行状況は、例えば試合の経過時間である。
所定の条件とは、例えば、予め定められた条件であればよく、所定の事象が発生することである。また例えば、所定の条件は、ゲームの実行状況が所定の状況になることである。また例えば、所定の条件は、ゲームの実行状況が所定の状況になる前に、対戦部屋との関連付けを解除すること、一定時間が経過すること、通信が切断すること、操作がない状態が一定時間経過することなどである。
本実施形態では、所定の条件の一例として、ゲームが所定の実行状況になる前に、少なくとも1人のユーザと対戦部屋との関連付けが解除されること(即ち、退室すること)を説明する。所定の実行状況としては、予め定められた実行状況であればよく、ここでは、表彰式画像G7をゲーム端末10に表示させることである場合を一例として説明する。例えば、表彰式画像G7がゲーム端末10に少しでも表示された場合に所定の実行状況になったとしてもよいし、表彰式画像G7における表彰式が最後まで表示された場合に所定の実行状況になったとしてもよいし、その間の任意の時点まで表彰式が表示された場合に所定の実行状況になったとしてもよい。
例えば、所定の条件は、後述する表示制御部309により成績が表示されることであってよく、ゲーム端末10は、自身の表示部15に表彰式画像G7が表示されたか否かを判定し、表示されたと判定した場合に、ゲームサーバ30に対し、所定の実行状況になったことを通知する。第1判定部304は、ゲーム端末10から当該通知を受信したか否かを判定することによって、ゲームが所定の実行状況になったか否かを判定する。
また例えば、第1判定部304は、退室部303の処理結果に基づいて、少なくとも1人のユーザが対戦部屋から途中退室したか否かを判定する。少なくとも1人とは、1人だけであってもよいし、2人以上であってもよい。本実施形態では、1人でも途中退室した場合にペナルティが発生する場合を説明するが、2人以上が途中退室した場合にペナルティが発生することにしてもよい。第1判定部304は、退室部303の処理結果に基づいて、所定人数のユーザが対戦部屋から途中退室したか否かを判定する。
例えば、第1判定部304は、対戦部屋データベースDB2に格納された入室ユーザ情報を参照し、ユーザの数が減少した場合に、ユーザが対戦部屋から退室したと判定する。また例えば、対戦部屋データベースDB2に退室済みか否かを示すフラグを用意しておく場合には、第1判定部304は、対戦部屋データベースDB2に格納されたフラグを参照し、ユーザが対戦部屋から退室したか否かを判定する。
[3-1-6.第2判定部]
第2判定部305は、制御部31を主として実現される。第2判定部305は、第1判定部304の判定結果に基づいて、ユーザの要求により新たな対戦部屋を生成するか否かを判定する。
例えば、第2判定部305は、第1判定部304により所定の条件が満たされたと判定された場合に、新たな対戦部屋を生成すると判定し、第1判定部304により所定の条件が満たされないと判定された場合に、新たな対戦部屋を生成しないと判定する。なお、所定の条件の定め方によっては、これとは逆に、第2判定部305は、第1判定部304により所定の条件が満たされないと判定された場合に、新たな対戦部屋を生成すると判定し、第1判定部304により所定の条件が満たされたと判定された場合に、新たな対戦部屋を生成しないと判定してもよい。
第2判定部305が新たな対戦部屋を生成すると判定することは、例えば、生成部301に対戦部屋の生成を許可することであり、生成部301に対し、対戦部屋の生成を指示することである。一方、第2判定部305が新たな対戦部屋を生成しないと判定することは、新たな対戦部屋を生成すると判定しないことであり、例えば、ゲーム端末10に対し生成要求自体をできなくすること、生成要求を受け付けないこと、生成要求を受け付けても無視して対戦部屋を生成しないこと、生成部301に対戦部屋の生成を禁止すること、生成部301に対し、対戦部屋の生成を指示しないことなどである。
第2判定部305は、ユーザの要求により生成された複数の対戦部屋のうちの所定数以上の対戦部屋についての第1判定部304の判定結果に基づいて、ユーザの要求により新たな対戦部屋を生成するか否かを判定する。所定数とは、例えば、予め定められた閾値であればよく、例えば、2回、3回、又は4回以上である。当該所定数は、データ記憶部300に予め記憶させておけばよい。
例えば、第2判定部305は、ユーザデータベースDB1のペナルティ情報を参照し、途中退室が発生した回数が閾値以上になったか否かを判定する。例えば、途中退室が発生した回数が閾値以上になったか否かを判定することによって、第2判定部305は、所定数以上の対戦部屋について所定の条件が満たされたか否かを判定する。
例えば、第2判定部305は、対戦部屋が生成された時点、又は、ローカルリーグが開始された時点から所定期間を経過したか否かを判定する。また例えば、所定期間を経過したかを判定する開始時期は、退室ボタンB400を押した時点としてもよいが、上記のようにするのは、発明の趣旨が対戦部屋の乱立を防ぐためであるため、例えば長期間かかってローカルリーグをプレイし、最終的にリーグを正常に終了することができなかった場合、退室した時からペナルティ期間が発生すると、ユーザにとって酷になるからである。具体的には、所定期間が3時間であったとして、対戦部屋を生成し、ローカルリーグを開始してから2時間たったときにローカルリーグを終了させることができず、対戦部屋を作成したユーザが退室した場合は、退室した時点から1時間待てば、第2判定部305は所定の条件が満たされたと判定する。このようにすれば、対戦部屋を乱立させないことが主目的であって、ユーザのプレイ活動を阻害するものではないようにすることができる。
[3-1-7.第3判定部]
第3判定部306は、制御部31を主として実現される。第3判定部306は、ユーザの要求により新たな対戦部屋が生成されない状態が所定の期間継続したか否かを判定する。所定の期間とは、例えば、予め定められた期間であればよく、例えば、1~12時間程度であってもよいし、数日程度であってもよい。
例えば、第3判定部306は、ユーザデータベースDB1のペナルティ情報を参照し、ペナルティが発生した日時から所定の期間が経過したか否かを判定する。第3判定部306は、リアルタイムクロック又はGPS信号等に基づいて現在日時を取得し、ペナルティが発生した日時と現在日時との間隔が閾値以上になったか否かを判定する。
また例えば、第3判定部306は、ゲームサーバ30におけるサーバ時間を取得し、サーバ時間に基づいて、ペナルティが発生した日時と現在日時との間隔が閾値以上になったか否かを判定してもよい。例えば、ゲーム端末10がゲームサーバ30に接続したときにサーバ時間を取得してもよい。また例えば、サーバ時間を取得したときの端末時間(第1時間)を記憶し、現在のサーバ時間を知りたい場合は、ゲームサーバ30にサーバ時間を取得しにいくのではなく、現在の端末時刻(第2時間)を取得し、以前取得したサーバ時間+(第2時間―第1時間)とすることで、サーバ時間を取得してもよい。ゲームプログラムのサスペンドや第2時間―第1時間の時間が所定数より大きくなった場合は、再びゲームサーバ30にサーバ時間を問い合わせ、サーバ時間と第1時間を更新させるようにしてもよい。このように構成することで、サーバに対する問い合わせを少なくし、サーバ時間とのずれを最小限にすることができる。
例えば、第2判定部305は、第1判定部304の判定結果と、第3判定部306の判定結果と、に基づいて、ユーザの要求により新たな対戦部屋を生成するか否かを決定する。第2判定部305は、第3判定部306により新たな対戦部屋が生成されない状態が所定の期間継続したと判定された場合に、新たな対戦部屋を生成すると判定し、第3判定部306により新たな対戦部屋が生成されない状態が所定の期間継続していないと判定された場合に、新たな対戦部屋を生成しないと判定する。
[3-1-8.第4判定部]
第4判定部307は、制御部31を主として実現される。第4判定部307は、ゲームの実行を開始したか否かを判定する。開始とは、例えば、ゲームを開始するための操作が行われることである。または当該操作が行われたことを示す情報を受信することである。実行中のゲームの画面を端末に表示させることである。ゲームの状況を示すデータを更新することである。
例えば、ゲーム端末10は、ゲームを開始するための操作が行われた場合に、ゲームの開始要求をゲームサーバ30に送信する。第3判定部306は、ゲーム端末10から開始要求を受信したか否かを判定する。例えば、第3判定部306は、ゲーム端末10から開始要求を受信したと判定された場合に、ゲームの実行を開始したと判定し、ゲーム端末10から開始要求を受信していないと判定された場合に、ゲームの実行を開始していないと判定する。
例えば、第2判定部305は、第1判定部304の判定結果と、第4判定部307の判定結果と、に基づいて、ユーザの要求により新たな対戦部屋を生成するか否かを決定する。第2判定部305は、第4判定部307によりゲームの実行が開始されていない場合に、新たな対戦部屋を生成すると判定し、第4判定部307によりゲームの実行が開始されたと判定された場合に、新たな対戦部屋を生成しないと判定する。
[3-1-9.報酬付与部]
報酬付与部308は、制御部31を主として実現される。報酬付与部308は、第1判定部304の判定結果に基づいて、対戦部屋に関連付けられたユーザに報酬を付与する。報酬とは、例えば、ゲームアイテムやゲーム内通貨(ポイント・コインなど)を付与することである。例えば、報酬付与部308は、ユーザIDに対し、ゲームアイテムを識別する情報を関連付けることによって、ユーザにゲームアイテムを付与する。また例えば、報酬付与部308は、ユーザIDに関連付けられたゲーム内通貨を増加させることによって、ユーザにゲーム内通貨を付与する。
例えば、報酬付与部308は、第1判定部304により所定の条件が満たされたと判定された場合に、ユーザに報酬を付与すると判定し、第1判定部304により所定の条件が満たされないと判定された場合に、ユーザに報酬を付与しないと判定する。なお、所定の条件の定め方によっては、これとは逆に、報酬付与部308は、第1判定部304により所定の条件が満たされないと判定された場合に、ユーザに報酬を付与すると判定し、第1判定部304により所定の条件が満たされたと判定された場合に、ユーザに報酬を付与しないと判定してもよい。
[3-1-10.表示制御部]
表示制御部309は、制御部31を主として実現される。例えば、表示制御部309は、ゲームの実行状況を識別するための情報を、対戦部屋に関連付けられたユーザに対応する表示部15と、対戦部屋を生成したユーザに対応する表示部15と、の少なくとも一方に表示させる。少なくとも一方とは、対戦部屋に入室したユーザに対応する表示部15だけであってもよいし、対戦部屋を生成したユーザに対応する表示部15だけであってもよいし、これらの両方であってもよい。
ゲームの実行状況を識別するための情報とは、例えば、ゲームがどの程度進行しているかを識別可能な情報である。例えば、あるユーザが複数のユーザとプレイする場合には、まだ一緒にプレイしていないユーザを表示させることである。例えば、まだ対戦していないユーザを表示させることである。また例えば、所定の実行状況に達するまでにあとどのくらいかを識別可能な情報である。また例えば、現在の対戦回数である。また例えば、終了した対戦の数である。また例えば、ゲーム開始からの経過時間である。また例えば、複数のステージを順番に進めるゲームであれば、現在のステージである。また例えば、スコアを獲得するゲームであれば、現在の獲得スコアである。また例えば、スポーツゲームであれば、試合の現在の状況である。野球ゲームであれば、現在のイニングである。サッカーゲームであれば、試合の経過時間である。
本実施形態では、対戦組み合わせ画像G4の表示領域A40に表示される残りの試合の対戦組み合わせが、ゲームの実行状況を識別するための情報の一例に相当する。表示制御部309は、ゲームデータに基づいて残りの試合を特定し、表示領域A40の表示を更新する。
また例えば、表示制御部309は、ゲームの実行結果に基づいて、対戦部屋に関連付けられたユーザの成績を、当該ユーザに対応する表示部15に表示させる。成績とは、例えば、例えば、ゲームで勝利することである。また例えば、ゲームでの勝利数・勝率・敗北数・引き分け数である。また例えば、ゲームにおける順位である。また例えば、ゲームに参加したユーザの中のランキングである。また例えば、ゲームにおけるユーザのスコアである。
本実施形態では、表彰式画像G7にユーザの成績が表示される場合を一例として説明する。表示制御部309は、ゲームデータに基づいてユーザの成績を特定し、表彰式画像G7を表示させる。
[3-2.ゲーム端末で実現される機能]
ゲーム端末10では、データ記憶部100と対戦実行部101が実現される。
[3-2-1.データ記憶部]
データ記憶部100は、記憶部12を主として実現される。データ記憶部100は、ゲームを実行するために必要なデータを記憶する。ここでは、データ記憶部100が記憶するデータの一例として、対戦部屋データDT1を説明する。
図19は、対戦部屋データDT1のデータ格納例を示す図である。図19に示すように、対戦部屋データDT1には、ユーザが入室した対戦部屋の部屋情報が格納される。部屋情報のデータ構造は、対戦部屋データベースDB2で説明した通りである。
なお、データ記憶部100に記憶されるデータは、上記の例に限られない。データ記憶部100は、ゲームに必要なデータを記憶すればよい。例えば、データ記憶部100は、ゲーム端末10のユーザに係る基本情報(例えば、ユーザIDやユーザ名など)を記憶してもよいし、ユーザが参加したエキシビションの過去の戦績・試合履歴やローカルリーグの参加履歴を記憶してもよい。
[3-2-2.対戦実行部]
対戦実行部101は、制御部11を主として実現される。対戦実行部101は、ユーザの操作に基づいて、対戦を実行する。例えば、対戦実行部101は、操作部14からのユーザの操作と、他のゲーム端末の操作部14からの他のユーザの操作と、に基づいてゲームデータを更新する。例えば、対戦実行部101は、ユーザの操作に基づいてキャラクタを動作させ、ゲームが終了した場合にユーザの優劣を決定する。
[4.ゲームシステムにおいて実行される処理]
図20-図21は、ゲームシステムSにおいて実行される処理の一例を示すフロー図である。図20-図21に示す処理は、制御部11が記憶部12に記憶されたプログラムに従って動作し、制御部31が記憶部32に記憶されたプログラムに従って動作することによって実行される。以降説明する処理は、機能ブロックが実行する処理の一例である。ここでは、対戦部屋検索画像G2からユーザが新規作成ボタンB21を選択して入力フォームF230に対戦部屋の名前を入力し、OKボタンB232を選択した場合の処理を説明する。
図20に示すように、まず、ゲーム端末10においては、制御部11は、対戦部屋の生成要求を送信する(S101)。なお、生成要求に含まれるユーザID等の情報は、予め記憶部12に記憶されているようにすればよい。以降の説明においても、ゲーム端末10からゲームサーバ30に対して何らかの情報が送信される場合には、ユーザIDも送信され、ゲームサーバ30側でどのゲーム端末10と通信しているか特定可能となっている。また、入力フォームF230に対戦部屋の名前が入力されていない場合には、ユーザがOKボタンB232を選択しても生成要求が送信されないようにしてもよい。
ゲームサーバ30においては、生成要求を受信すると、制御部31は、ユーザデータベースDB1のペナルティ情報に基づいて、生成要求により新たな対戦部屋を生成するか否かを判定する(S301)。S301においては、制御部31は、ユーザデータベースDB1のうち、生成要求に含まれるユーザIDに対応するレコードのペナルティ情報を参照する。制御部31は、ペナルティ情報の発生中フラグがオフであれば、新たな対戦部屋を生成すると判定し、ペナルティ情報の発生中フラグがオンであれば、新たな対戦部屋を生成しないと判定する。
新たな対戦部屋を生成すると判定されない場合(S301;N)、制御部31は、ゲーム端末10に対し、新たな対戦部屋を生成しないことを示す通知を送信する(S303)。この場合、S305の処理は実行されず、対戦部屋は生成されない。
ゲーム端末10においては、通知を受信すると、制御部11は、対戦部屋が生成されなかったことを示すダイアログD25を対戦部屋検索画像G2に表示させ(S103)、本処理は終了する。なお、ダイアログD25を表示させるためのデータは、予め記憶部12に記憶されているものとする。
一方、S301において、新たな対戦部屋を生成すると判定された場合(S301;Y)、制御部31は、受信した生成要求に基づいて対戦部屋を生成し(S305)、ゲーム端末10に対し、対戦部屋の生成が完了したことを示す完了通知を送信する(S307)。S305においては、制御部31は、所定のID生成ルールに基づいて対戦部屋IDを生成する。また、制御部31は、対戦部屋データベースDB2に新たなレコードを生成し、生成要求に含まれるユーザIDなどの情報を生成ユーザ情報と入室ユーザ情報として格納する。なお、S307における完了通知は、所定のデータ形式で行われるようにすればよく、例えば、S305で生成した対戦部屋IDが完了通知に含まれるものとする。
ゲーム端末10においては、完了通知を受信すると、制御部11は、他のゲーム端末10に対し、対戦ID等の部屋情報を送信する(S105)。S105においては、制御部11は、少なくとも1つの無線通信規格に則った無線通信に基づいて、部屋情報を他のゲーム端末10に送信する。他のゲーム端末10は、少なくとも1つの無線通信規格に則った無線通信に基づいて、部屋情報を取得すると、対戦部屋検索画像G2に対戦部屋が表示され、入室ボタンB23が選択された場合にゲームサーバ30に対して入室要求を送信する。なお、入室要求は、対戦部屋を生成したゲーム端末10経由でゲームサーバ30に送信されてもよい。
ゲームサーバ30においては、制御部31は、ゲーム端末10から入室要求を受信したか否かを判定する(S309)。入室要求を受信したと判定された場合(S309;Y)、制御部31は、入室要求をしたユーザを対戦部屋に入室させ(S311)、ゲーム端末10に対し、入室が完了したことを示す完了通知を送信する(S313)。S311においては、制御部31は、対戦部屋データベースDB2のうち、入室要求に含まれる対戦部屋IDに対応するレコードの入室ユーザ情報に、入室要求に含まれる情報を格納する。なお、S313における完了通知は、所定のデータ形式で行われるようにすればよく、例えば、対戦部屋に入室したユーザの入室ユーザ情報を含む。
ゲーム端末10においては、完了通知を受信すると、制御部11は、対戦部屋データDT1を更新する(S107)。S107においては、制御部11は、完了通知に含まれる入室ユーザ情報を対戦部屋データDT1に格納する。これにより、ゲーム端末10は、ユーザが生成した対戦部屋に他のユーザが入室したことを特定することができる。
図21に移り、制御部11は、ローカルリーグを開始するための開始操作が操作部14から行われた場合に、ゲームサーバ30に対し、ローカルリーグを開始することを示す開始通知を送信する(S109)。なお、S109における開始通知は、所定のデータ形式で行われるようにすればよく、例えば、ローカルリーグを開始する対戦部屋の対戦部屋IDを含む。
ゲームサーバ30においては、制御部31は、開始通知を受信したか否かを判定する(S315)。開始通知を受信したと判定されない場合(S315;N)、S309に戻る。この場合、対戦部屋に他のユーザが入室するのが待ち受けられることになる。なお、この状態で、対戦部屋に入室したユーザが退室したとしても、後述するS319~S325の処理が実行されないため、ペナルティは発生しない。
S109において開始操作が行われると、ゲーム端末10では、入室ユーザ情報に入室した複数のユーザで総当たり戦となるように対戦組み合わせが決定され、他のゲーム端末10との間でマッチング処理が実行される。ゲーム端末10と他のゲーム端末10との間で確立した無線通信をしながら、実行中のゲームの状況を示すデータやユーザの操作内容を送受信することによって、ゲームを実行する。この間、ゲーム端末10からゲームサーバ30に対し、最新の試合状況や対戦結果を示すゲームデータが送信されるようにしてもよい。
制御部11は、操作部14の検出信号に基づいて、ユーザが退室ボタンB400を選択したか否かを判定する(S111)。ユーザが退室ボタンB400を選択した場合(S111;Y)、制御部11は、ゲームサーバ30に対し、対戦部屋に退室するための退室要求を送信する(S113)。なお、他のゲーム端末10においても、退室ボタンB400が選択された場合に、退室要求がゲームサーバ30に対して送信される。
ゲームサーバ30においては、制御部31は、退室要求を受信したか否かを判定する(S317)。退室要求を受信したと判定されない場合(S317;N)、後述するS327の処理に移行する。
一方、退室要求を受信したと判定された場合(S317;Y)、制御部31は、退室要求をしたユーザを対戦部屋から退室させ(S319)、ペナルティ情報が示す回数を増加させる(S321)。S319においては、制御部31は、対戦部屋データベースDB2のうち、退室要求に含まれる対戦部屋IDに対応するレコードの入室ユーザ情報から、入室要求に含まれるユーザIDに対応する情報を削除する。また、S321においては、制御部31は、ユーザデータベースDB1のうち、退室要求に含まれる対戦部屋IDに対応するレコードのペナルティ情報が示す回数を1増加させる。
制御部31は、ユーザデータベースDB1のペナルティ情報に基づいて、ペナルティを発生させるか否かを判定する(S323)。S323においては、制御部31は、ペナルティ情報が示す回数が閾値以上になったか否かを判定する。制御部31は、回数が閾値以上になった場合にはペナルティを発生させると判定し、回数が閾値未満である場合にはペナルティを発生させると判定しない。
ペナルティを発生させると判定された場合(S323;Y)、制御部31は、対戦部屋を生成したユーザのペナルティ情報を更新する(S325)。S325においては、制御部31は、対戦部屋データベースDB2のうち、退室要求に含まれる対戦部屋IDに対応するレコードの生成ユーザ情報を参照する。制御部31は、ユーザデータベースDB1のうち、当該生成ユーザ情報に含まれるユーザIDに対応するレコードのペナルティ情報の日時に現在日時を格納し、発生フラグをオンにする。なお、ゲームサーバ30は、ユーザデータベースDB1のペナルティ情報を定期的に参照し、ペナルティ情報の日時から一定期間が経過したレコードについては、発生フラグをオフにして回数をリセットする。
ゲーム端末10においては、制御部11は、対戦部屋データDT1に基づいて、ローカルリーグにおける全試合が終了したか否かを判定する(S115)。S115においては、制御部11は、対戦部屋データDT1に格納されたゲームデータに基づいて、対戦組み合わせが決定された全試合が終了したか否かを判定する。全試合が終了したと判定されない場合(S115;N)、S111の処理に戻り、次の試合のマッチング処理が実行されてローカルリーグの残りの試合が進行する。
一方、全試合が終了したと判定された場合(S115;Y)、制御部11は、対戦部屋データDT1に基づいて、表彰式画像G7を表示させ(S117)、ゲームサーバ30に対し、表彰式画像G7が表示されたことを示す終了通知を送信する(S119)。なお、S119における終了通知は、所定のデータ形式で行われるようにすればよく、例えば、ローカルリーグが終了した対戦部屋の対戦部屋IDを含む。
ゲームサーバ30においては、終了通知を受信すると、制御部31は、対戦部屋のユーザに報酬を付与し(S327)、本処理は終了する。S327においては、制御部31は、対戦部屋データベースDB2の入室ユーザ情報を参照して対戦部屋に入室したユーザのユーザIDを特定し、当該ユーザIDに新たにゲームアイテムを関連付けたり、当該ユーザIDに関連付けられたゲーム内通貨を増加させたりする。なお、報酬は、ユーザがゲーム内のお知らせ欄から所定の受け取り操作をすることで付与されるようにしてもよい。
なお、ゲームサーバ30は、対戦部屋に入室した全てのゲーム端末10から終了通知を受信しなければ、ローカルリーグが終了したとみなさないようにしてもよい。この場合、誰か1人でも表彰式画像G7を見終わっていないユーザがいる場合には、報酬が付与されないことになる。また、誰か1人でも表彰式画像G7を見終わっていないユーザがいる場合には、誰か退室した場合には途中退室とみなすようにしてもよい。
以上説明したゲームシステムSによれば、ゲームの実行状況が所定の条件を満たさない場合、新たな対戦部屋を生成しないと判定することで、同じユーザによる新たな対戦部屋の生成を防止することができる。したがって、対戦部屋の乱立によるゲームデータの消費量の増加を防止することができる。
また、ゲームが所定の実行状況になる前に、少なくとも1人のユーザが対戦部屋から退室した場合に、新たな対戦部屋を生成しないと判定することで、当該対戦部屋を生成したユーザによる新たな対戦部屋の生成を防止することができる。
また、ユーザの要求により新たな対戦部屋が生成されない状態が所定の期間継続した場合、新たな対戦部屋を生成すると判定することで、いつまでも新たな対戦部屋を生成できないといったことを防止することができる。例えば、ユーザが意図しない理由で新たな対戦部屋を生成することができなくなってしまった場合に、不当に重いペナルティが課されるといったことを防止できる。
また、ゲームの実行が開始しなかった場合に、新たな対戦部屋を生成すると判定することで、例えば、ゲームを開始できなかった正当な理由がある場合に不当に重いペナルティが課されることを防止することができる。
また、ゲームの実行状況が所定の条件を満たした場合に、新たな対戦部屋を生成できるだけでなく報酬が付与されるので、ゲームの実行状況が所定の条件を満たすまでプレイさせる動機付けを与えることができる。
また、同じユーザにより生成された複数の対戦部屋のうち所定数以上の対戦部屋のゲームの実行状況が所定の条件を満たさない場合、新たな対戦部屋を生成しないと判定することで、ペナルティが不当に重くなってしまうことを防止することができる。
また、ゲームの実行状況をユーザに確認させることができる。したがって、新たな対戦部屋を生成しないと判定される状況であるか否かをユーザに確認させることができる。
また、各ユーザがゲームでの成績を見るまでゲームをプレイさせる動機付けを与えることができる。
[5.変形例]
なお、本発明は、以上に説明した実施の形態に限定されるものではない。本発明の趣旨を逸脱しない範囲で、適宜変更可能である。
(1)例えば、実施形態では、表彰式画像G7が表示される前に途中退室したユーザがいる場合にペナルティが発生する場合を説明したが、ペナルティが発生する所定の条件は実施形態で説明した例に限られない。例えば、所定の条件は、ゲームが所定の実行状況になることなく、対戦部屋が生成された場合に設定される所定の期限が経過することである。
所定の期限とは、例えば、対戦部屋が生成された時点から、当該時点の所定時間後まで、の期間である。所定時間は、予め定められた時間であればよく、例えば、数時間程度であってもよいし、数日又は数週間程度であってもよい。
例えば、変形例(1)では、対戦部屋データベースDB2に、対戦部屋が生成された生成日時が格納される。生成部301は、対戦部屋を生成すると、生成した対戦部屋の生成日時を対戦部屋データベースDB2に格納する。生成日時は、対戦部屋の生成が完了した場合の日時であってもよいし、当該日時の所定時間前後した日時であってもよいし、生成要求の受信日時であってもよい。
変形例(1)の第1判定部304は、ゲームが所定の実行状況になっていない場合に、対戦部屋の生成日時と現在日時との時間間隔が閾値以上であるか否かを判定する。第1判定部304は、時間間隔が閾値以上であると判定した場合に所定の条件を満たすと判定し、時間間隔が閾値以上であると判定した場合に所定の条件を満たさないと判定する。第2判定部は、第1判定部304により時間間隔が閾値未満であると判定された場合に、新たな対戦部屋を生成すると判定し、第1判定部304により時間間隔が閾値以上であると判定された場合に、新たな対戦部屋を生成しないと判定する。
変形例(1)によれば、ゲームが所定の実行状況になることなく所定の期限が経過した場合に、新たな対戦部屋を生成しないと判定することで、いつまでもゲームを進めない対戦部屋が長時間残ってしまうことを防止できるので、ゲームシステムのデータ消費量を軽減することができる。
(2)また例えば、ユーザが他のユーザと対戦するために対戦部屋が生成される場合を説明したが、特に部屋の形式でなくてもよい。例えば、ユーザグループが生成されて、他のユーザとのプレイを希望するユーザがユーザグループに所属してもよい。
ユーザグループとは、例えば、複数のユーザをメンバとして含むグループである。例えば、同じユーザグループに所属している複数のユーザは、ゲームの優劣(順位又は勝敗)を競い合う複数のユーザとなる。例えば、ユーザグループは、他のユーザと対戦するゲームをプレイすることを希望するユーザ、又は、他のユーザと協力して目標の達成を目指すゲームをプレイすることを希望するユーザが集うべきものであってもよい。
別の言い方をすれば、ユーザグループは、ゲームへの参加を宣言するためのものであってもよい。例えば、ユーザグループは、ゲームの中の世界に存在する物体を示すものである。また例えば、ユーザグループは、ゲーム内に設定された部屋・ロビーと呼ばれるものであってもよいし、仮想世界の中に設定された所定の場所であってもよいし、フレンドやギルドといった他の名称で呼ばれるものであってもよい。また例えば、ユーザグループは、データベース上のレコードであってもよいし、メモリ上のハッシュ構造を使った配列であってもよい。
対戦部屋は、ユーザグループの一例であり、実施形態において対戦部屋と記載した箇所は、ユーザグループと読み替えることができる。このため、生成部301は、ユーザの要求に基づいてユーザグループを生成する。第1判定部304は、ユーザグループに関連付けられたゲームの実行状況が所定の条件を満たすか否かを判定する。第2判定部305は、第1判定部305の判定結果に基づいて、ユーザの要求により新たなユーザグループを生成するか否かを判定する。これらの処理の詳細は実施形態で説明した通りである。
変形例(2)によれば、ゲームの実行状況が所定の条件を満たさない場合、新たなユーザグループを生成しないと判定することで、同じユーザによる新たな対戦部屋の生成を防止することができる。したがって、ユーザグループの乱立によるゲームデータの消費量の増加を防止することができる。
(3)また例えば、実施形態では、ローカルリーグを例に挙げて説明したが、エキシビションに実施形態と同様の処理を適用してもよいし、オンライン対戦に実施形態と同様の処理を適用してもよい。
また例えば、実施形態では、何れかのユーザが対戦部屋から退室した場合にペナルティが発生する場合を一例として説明したが、ペナルティが発生する条件は、予め定められた条件であればよく、例えば、対戦部屋を生成したユーザが退室することが条件となってもよいし、対戦部屋を生成したユーザ以外のユーザが退室し、対戦部屋内のユーザ数が所定人数未満になることが条件となってもよい。他にも例えば、所定人数以上のユーザが退室することが条件となってもよい。
また例えば、実施形態では、ゲームサーバ30において対戦部屋の管理に関する主な処理が実行され、ゲームサーバ30が本発明に係るゲーム制御装置に相当する場合を説明したが、ゲームサーバ30において実現される各機能は、ゲーム端末10において実現されてもよい。例えば、生成部301、入室部302、退室部303、第1判定部304、第2判定部305、第3判定部306、第4判定部307、報酬付与部308、及び表示制御部309がゲーム端末10において実現されてもよい。この場合、これら各機能は、制御部11を主として実現される。
例えば、生成部301がゲーム端末10で実現される場合、生成部301は、対戦部屋IDを生成し、ユーザIDと対戦部屋IDを含むデータをゲームサーバ30に送信することによって対戦部屋を生成してもよい。また例えば、入室部302がゲーム端末10で実現される場合、他のゲーム端末10からユーザID等の情報を取得し、入室ユーザ情報を更新することによって他のユーザを入室させてもよい。また例えば、退室部303がゲーム端末10で実現される場合、他のゲーム端末10からユーザID等の情報を取得し、入室ユーザ情報を更新することによって他のユーザを退室させてもよい。また例えば、第1判定部304がゲーム端末10で実現される場合、対戦部屋データDT1に格納されたゲームデータを参照し、所定の条件を満たすか否かを判定してもよい。また例えば、第2判定部305がゲーム端末10で実現される場合、新たな対戦部屋を生成するか否かの判定結果をゲームサーバ30に送信してもよい。
また例えば、ゲーム端末10とゲームサーバ30とで各機能が分担されてもよい。この場合、ゲーム端末10とゲームサーバ30との間で処理結果を送受信すればよい。例えば、ゲーム端末10において生成部301が実現され、ゲームサーバ30において第1判定部304と第2判定部305が実現されてもよい。また例えば、ゲーム端末10において生成部301と第1判定部304が実現され、ゲームサーバ30において第2判定部305が実現されてもよい。
[6.付記]
以上のような記載から、本発明は例えば以下のように把握される。
1)本発明の一態様に係るゲームシステム(S)は、ユーザの要求に基づいて対戦部屋を生成する生成手段(301)と、前記対戦部屋に関連付けられたゲームの実行状況が所定の条件を満たすか否かを判定する第1判定手段(304)と、前記第1判定手段(304)の判定結果に基づいて、前記ユーザの要求により新たな対戦部屋を生成するか否かを判定する第2判定手段(305)と、を含む。
10)本発明の一態様に係るゲームシステム(S)は、ユーザの要求に基づいてユーザグループを生成する生成手段(301)と、前記ユーザグループに関連付けられたゲームの実行状況が所定の条件を満たすか否かを判定する第1判定手段(304)と、前記第1判定手段(304)の判定結果に基づいて、前記ユーザの要求により新たなユーザグループを生成するか否かを判定する第2判定手段(305)と、を含む。
11)本発明の一態様に係るゲーム制御装置(10,30)は、ユーザの要求に基づいて生成された対戦部屋に関連付けられたゲームの実行状況が所定の条件を満たすか否かを判定する第1判定手段(304)と、前記第1判定手段(304)の判定結果に基づいて、前記ユーザの要求により新たな対戦部屋を生成するか否かを判定する第2判定手段(305)と、を含む。
12)本発明の一態様に係るゲーム制御装置(10,30)は、ユーザの要求に基づいて生成されたユーザグループに関連付けられたゲームの実行状況が所定の条件を満たすか否かを判定する第1判定手段(304)と、前記第1判定手段(304)の判定結果に基づいて、前記ユーザの要求により新たなユーザグループを生成するか否かを判定する第2判定手段(305)と、を含む。
13)本発明の一態様に係るプログラムは、1)~10)の何れかに記載のゲームシステム(S)又は11)若しくは12)に記載のゲーム制御装置(10,30)としてコンピュータを機能させる。
14)本発明の一態様に係る情報記憶媒体は、13)のプログラムを記録したコンピュータで読み取り可能な情報記憶媒体である。
1)又は10)~14)に係る発明によれば、ゲームの実行状況が所定の条件を満たさない場合、新たな対戦部屋を生成しないと判定することで、同じユーザによる新たな対戦部屋の生成を防止することができる。したがって、対戦部屋の乱立によるゲームデータの消費量の増加を防止することができる。
2)本発明の一態様では、前記ゲームシステム(S)は、前記対戦部屋に関連付けられたユーザの関連付けを解除する解除手段(303)を更に含み、前記所定の条件は、前記ゲームが所定の実行状況になる前に、少なくとも1人のユーザと前記対戦部屋との関連付けが解除されることである。2)の態様によれば、ゲームが所定の実行状況になる前に、少なくとも1人のユーザと対戦部屋との関連付けが解除された場合に、新たな対戦部屋を生成しないと判定することで、当該対戦部屋を生成したユーザによる新たな対戦部屋の生成を防止することができる。
3)本発明の一態様では、前記ゲームシステム(S)は、前記ユーザの要求により前記新たな対戦部屋が生成されない状態が所定の期間継続したか否かを判定する第3判定手段(306)を更に含み、前記第2判定手段(305)は、前記第1判定手段(304)の判定結果と、前記第3判定手段(306)の判定結果と、に基づいて、前記ユーザの要求により前記新たな対戦部屋を生成するか否かを決定する。3)の態様によれば、ユーザの要求により新たな対戦部屋が生成されない状態が所定の期間継続した場合、新たな対戦部屋を生成すると判定することで、いつまでも新たな対戦部屋を生成できないといったことを防止することができる。例えば、ユーザが意図しない理由で新たな対戦部屋を生成することができなくなってしまった場合に、不当に重いペナルティが課されるといったことを防止できる。
4)本発明の一態様では、前記ゲームの実行を開始したか否かを判定する第4判定手段(307)を更に含み、前記第2判定手段(305)は、前記第1判定手段(304)の判定結果と、前記第4判定手段(307)の判定結果と、に基づいて、前記ユーザの要求により前記新たな対戦部屋を生成するか否かを決定する。4)の態様によれば、ゲームの実行が開始しなかった場合に、新たな対戦部屋を生成すると判定することで、例えば、ゲームを開始できなかった正当な理由がある場合に不当に重いペナルティが課されることを防止することができる。
5)本発明の一態様では、前記ゲームシステム(S)は、前記第1判定手段(304)の判定結果に基づいて、前記対戦部屋に関連付けられたユーザに報酬を付与する報酬付与手段(308)、を更に含む。5)の態様によれば、ゲームの実行状況が所定の条件を満たした場合に、新たな対戦部屋を生成できるだけでなく報酬が付与されるので、ゲームの実行状況が所定の条件を満たすまでプレイさせる動機付けを与えることができる。
6)本発明の一態様では、前記生成手段(301)は、前記ユーザの要求が行われるたびに前記対戦部屋を生成し、前記第2判定手段(305)は、前記ユーザの要求により生成された複数の前記対戦部屋のうちの所定数以上の対戦部屋についての前記第1判定手段(304)の判定結果に基づいて、前記ユーザの要求により前記新たな対戦部屋を生成するか否かを判定する。6)の態様によれば、同じユーザにより生成された複数の対戦部屋のうち所定数以上の対戦部屋のゲームの実行状況が所定の条件を満たさない場合、新たな対戦部屋を生成しないと判定することで、ペナルティが不当に重くなってしまうことを防止することができる。
7)本発明の一態様では、前記ゲームシステム(S)は、前記ゲームの実行状況を識別するための情報を、前記対戦部屋に関連付けられたユーザに対応する表示手段(15)と、前記対戦部屋を生成したユーザに対応する表示手段(15)と、の少なくとも一方に表示させる表示制御手段(309)、を更に含む。7)の態様によれば、ゲームの実行状況をユーザに確認させることができる。したがって、新たな対戦部屋を生成しないと判定される状況であるか否かをユーザに確認させることができる。
8)本発明の一態様では、前記ゲームシステム(S)は、前記ゲームの実行結果に基づいて、前記対戦部屋に関連付けられたユーザの成績を、当該ユーザに対応する表示手段(15)に表示させる表示制御手段(309)を更に含み、前記所定の条件は、前記表示制御手段(309)により成績が表示されることである。8)の態様によれば、各ユーザがゲームでの成績を見るまでゲームをプレイさせる動機付けを与えることができる。
9)本発明の一態様では、前記所定の条件は、前記ゲームが所定の実行状況になることなく、前記対戦部屋が生成された場合に設定される所定の期限が経過することである。9)の態様によれば、ゲームが所定の実行状況になることなく所定の期限が経過した場合に、新たな対戦部屋を生成しないと判定することで、いつまでもゲームを進めない対戦部屋が長時間残ってしまうことを防止できるので、ゲームシステムのデータ消費量を軽減することができる。