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

Abstract

【課題】ゲームデータの消費量の増加を防止する。【解決手段】ゲームシステム（Ｓ）の生成手段（３０１）は、ユーザの要求に基づいて対戦部屋を生成する。第１判定手段（３０４）は、対戦部屋に関連付けられたゲームの実行状況が所定の条件を満たすか否かを判定する。第２判定手段（３０５）は、第１判定手段（３０４）の判定結果に基づいて、ユーザの要求により新たな対戦部屋を生成するか否かを判定する。【選択図】図１６

Description

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

従来、例えば対戦部屋を生成するシステムが知られている。例えば、特許文献１には、ユーザが生成した対戦部屋に他のユーザを入室させ、対戦部屋に入室したユーザ同士でゲームをプレイさせるゲームシステムが記載されている。

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

しかしながら、特許文献１の技術では、ユーザが対戦部屋を自由に生成することができるので、誰も使用しない対戦部屋が乱立してそのまま残ってしまい、ゲームシステムのゲームデータの消費量が増加する可能性があった。

本発明は上記課題に鑑みてなされたものであって、その目的は、ゲームデータの消費量の増加を防止することが可能なゲームシステム、ゲーム制御装置、及びプログラムを提供することである。

上記課題を解決するために、本発明の一態様に係るゲームシステムは、ユーザの要求に基づいて対戦部屋を生成する生成手段と、前記対戦部屋に関連付けられたゲームの実行状況が所定の条件を満たすか否かを判定する第１判定手段と、前記第１判定手段の判定結果に基づいて、前記ユーザの要求により新たな対戦部屋を生成するか否かを判定する第２判定手段と、を含む。

本発明の一態様に係るゲームシステムは、ユーザの要求に基づいてユーザグループを生成する生成手段と、前記ユーザグループに関連付けられたゲームの実行状況が所定の条件を満たすか否かを判定する第１判定手段と、前記第１判定手段の判定結果に基づいて、前記ユーザの要求により新たなユーザグループを生成するか否かを判定する第２判定手段と、を含む。

本発明の一態様に係るゲーム制御装置は、ユーザの要求に基づいて生成された対戦部屋に関連付けられたゲームの実行状況が所定の条件を満たすか否かを判定する第１判定手段と、前記第１判定手段の判定結果に基づいて、前記ユーザの要求により新たな対戦部屋を生成するか否かを判定する第２判定手段と、を含む。

本発明の一態様に係るゲーム制御装置は、ユーザの要求に基づいて生成されたユーザグループに関連付けられたゲームの実行状況が所定の条件を満たすか否かを判定する第１判定手段と、前記第１判定手段の判定結果に基づいて、前記ユーザの要求により新たなユーザグループを生成するか否かを判定する第２判定手段と、を含む。

ゲームシステムの全体構成を示す図である。 メニュー画像の一例を示す図である。 ユーザがローカル対戦ボタンを選択した場合のメニュー画像の一例を示す図である。 対戦部屋検索画像の一例を示す図である。 ユーザＡが新規作成ボタンを選択した場合の対戦部屋検索画像の一例を示す図である。 ユーザＡが対戦部屋を生成した場合の対戦部屋検索画像の一例を示す図である。 対戦部屋画像の一例を示す図である。 第２ゲーム端末に表示される対戦部屋検索画像の一例を示す図である。 ユーザＢ，ＣがユーザＡの対戦部屋に入室した場合の対戦部屋画像の一例を示す図である。 対戦組み合わせ画像の一例を示す図である。 マッチング画像の一例を示す図である。 試合開始後に表示されるゲーム画像の一例を示す図である。 第１試合が終了した場合の対戦組み合わせ画像の一例を示す図である。 表彰式画像の一例を示す図である。 ペナルティが与えられた場合の対戦部屋検索画像の一例を示す図である。 ゲームシステムで実現される機能のうち、本発明に関連する機能を示す機能ブロック図である。 ユーザデータベースのデータ格納例を示す図である。 対戦部屋データベースのデータ格納例を示す図である。 対戦部屋データのデータ格納例を示す図である。 ゲームシステムにおいて実行される処理の一例を示すフロー図である。 ゲームシステムにおいて実行される処理の一例を示すフロー図である。

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

図１は、ゲームシステムの全体構成を示す図である。図１に示すように、本実施形態に係るゲームシステムＳは、第１ゲーム端末１０Ａ、第２ゲーム端末１０Ｂ、第３ゲーム端末１０Ｃ、ゲームサーバ３０、及びドメインネームサーバ５０を含む。例えば、第３ゲーム端末１０Ｃとゲームサーバ３０は、インターネットなどのネットワークＮに接続され、第１ゲーム端末１０Ａ、第２ゲーム端末１０Ｂ、及びドメインネームサーバ５０は、無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）などのプライベートネットワークＰＮに接続される。

なお、以降では、第１ゲーム端末１０Ａ、第２ゲーム端末１０Ｂ、及び第３ゲーム端末１０Ｃを特に区別する必要のないときは、単にゲーム端末１０と記載する。また、本実施形態では、ゲーム端末１０が３台である場合を説明するが、ゲームシステムＳ内のゲーム端末１０の台数に制限はなく、２台であってもよいし４台以上であってもよい。同様に、ゲームシステムＳ内のゲームサーバ３０及びドメインネームサーバ５０の台数に制限はなく、２台以上のゲームサーバ３０又はドメインネームサーバ５０が存在してもよい。また、ゲーム端末１０、ゲームサーバ３０、及びドメインネームサーバ５０以外のコンピュータがゲームシステムＳに含まれていてもよい。なお、ゲームシステムＳは、プライベートネットワークＰＮや当該プライベートネットワークＰＮ内のドメインネームサーバ５０を含まなくてもよい。

ゲーム端末１０は、ユーザが操作するコンピュータである。例えば、ゲーム端末１０は、携帯端末（例えば、スマートフォンなどの携帯電話又はタブレット型コンピュータ）、パーソナルコンピュータ、携帯ゲーム機、据置ゲーム機、業務用ゲーム機、又は情報処理機能を備えた多機能型テレビジョン受像機（スマートテレビ）等である。なお、ゲームシステムＳに含まれる各ゲーム端末１０は、他のゲーム端末１０と機種・性能・オペレーティングシステム等が異なってもよい。

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

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

ゲームサーバ３０は、サーバコンピュータである。図１に示すように、ゲームサーバ３０は、制御部３１、記憶部３２、及び通信部３３を含む。制御部３１、記憶部３２、及び通信部３３のハードウェア構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。例えば、ゲームサーバ３０は、ゲームプログラムを記憶しており、ゲーム端末１０からの要求に応じてゲームプログラムを配信する。

ドメインネームサーバ５０は、サーバコンピュータである。図１に示すように、ドメインネームサーバ５０は、制御部５１、記憶部５２、及び通信部５３を含む。制御部５１、記憶部５２、及び通信部５３のハードウェア構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。例えば、ドメインネームサーバ５０は、ホスト名やドメイン名などの名称からＩＰアドレスなどの情報を得るためのサーバであり、これらを関連付けて記憶部５２に記憶する。ここでは、プライベートネットワークＰＮ内のドメインネームサーバ５０が利用されるので、外部のドメインネームサーバには情報が送信されない。

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

［２．ゲームの概要］
ゲームシステムＳは、複数のユーザがプレイするゲームを実行する。ゲームとしては、複数のユーザが互いに対戦するゲームであってもよいし、複数のユーザが互いに協力するゲームであってもよい。本実施形態では、ゲーム内に生成された同じ対戦部屋に関連付けられた複数のユーザが互いに対戦するサッカーゲームが用いられる場合を一例として説明するが、ゲーム形式・ジャンルを問わず任意のゲームであってよく、例えば、サッカー以外のスポーツゲーム（例えば、野球ゲーム）、カードゲーム、アクションゲーム、ロールプレイングゲーム、シミュレーションゲーム、レースゲーム、ボードゲーム、又は格闘ゲームであってもよい。

対戦部屋とは、例えば、他のユーザと対戦するゲームをプレイすることを希望するユーザが関連付けられるゲーム内の部屋である。別の言い方をすれば、対戦部屋は、ゲームへの参加を宣言するための部屋である。また例えば、対戦部屋は、ゲームの中の世界に存在する仮想的な部屋である。また例えば、対戦部屋は、任意の名称で呼ばれてよく、例えば、ゲーム内に設定されたロビーと呼ばれてもよいし、仮想世界の中の場所で呼ばれてもよい。また例えば、対戦部屋は、データベース上のレコードであってもよいし、プログラムメモリ上のハッシュ構造を使った配列であったりしてもよい。

生成とは、例えば、ゲーム内に対戦部屋を生成することである。また例えば、生成とは、対戦部屋を示すデータをコンピュータ上に登録することである。

対戦部屋にユーザが関連付けられるとは、例えば、対戦部屋にユーザＩＤが関連付けられることである。例えば、対戦部屋ＩＤにユーザＩＤが関連付けられることであり、対戦部屋ＩＤとユーザＩＤとが同じレコードに格納されることである。別の言い方をすれば、ゲームをプレイすることの希望しない状態から希望する状態に変えることであり、ゲームをプレイしない状態からプレイ可能な状態に変えることである。

なお、本実施形態では、対戦部屋にユーザが関連付けられることを、対戦部屋にユーザが入室すると記載することもあるが、実在する対戦部屋に人間が入室するわけではなく、ゲームシステムＳでは、対戦部屋にユーザＩＤを関連付けるという処理が実行されることになる。このため、本実施形態において、ユーザが対戦部屋に入室すると記載している箇所については、ユーザを対戦部屋に関連付けると読み替えることができる。この点は、後述する「退室」についても同様であり、対戦部屋とユーザとの関連付けを解除することを、対戦部屋からユーザが退室すると記載することもあるが、実在する対戦部屋から人間が退室するのではなく、ゲームシステムＳでは、対戦部屋にユーザＩＤが関連付けられた状態から関連付けられない状態にする処理が実行されることになる。このため、本実施形態において、ユーザが対戦部屋から退室すると記載している箇所については、ユーザと対戦部屋との関連付けを解除すると読み替えることができる。

本実施形態のゲームでは、複数の対戦形式が用意されている。ここでは、対戦形式の一例として、無線通信可能な端末同士で通信しながら実行されるローカル対戦と、ローカル対戦とは異なるオンライン対戦と、を説明する。なお、無線通信とは、例えば、電波による通信であり、伝送路として有線を使用しない通信である。

例えば、ローカル対戦では、複数のユーザがゲーム端末１０を持ち寄って集まり、各ゲーム端末１０が互いにＰ２Ｐで直接的に通信しながらゲームを実行する。別の言い方をすれば、ローカル対戦では、各ゲーム端末１０が無線通信における通信範囲内にいる状態で、互いに通信しながらゲームが実行される。一方、オンライン対戦は、例えば、特に複数のユーザがゲーム端末１０を持ち寄って集まる必要はなく、遠く離れたユーザと対戦することが可能である。別の言い方をすれば、オンライン対戦は、場所を選ばずにプレイすることができ、各ゲーム端末１０は、ゲームサーバ３０等を介して間接的に通信しながらゲームを実行する。

ここでは、第１ゲーム端末１０Ａを操作するユーザＡが対戦部屋を生成し、第２ゲーム端末１０Ｂを操作するユーザＢと、第３ゲーム端末１０Ｃを操作するユーザＣと、が当該対戦部屋に入室する場合を説明する。例えば、ユーザＡが第１ゲーム端末１０Ａを操作してゲームプログラムが起動すると、メニュー画像が表示部１５に表示される。

図２は、メニュー画像の一例を示す図である。図２に示すように、メニュー画像Ｇ１は、ゲームに用意された種々のモードを選択するための画像である。例えば、メニュー画像Ｇ１には、期間限定のゲームイベントに参加するためのイベントボタンＢ１０、オンライン対戦をプレイするためのオンライン対戦ボタンＢ１１、１シーズンを通しての試合成績を競うシーズンマッチボタンＢ１２，Ｂ１３、及びローカル対戦をプレイするためのローカル対戦ボタンＢ１４が表示される。

本実施形態では、主に、ローカル対戦に係る処理を説明する。このため、以降では、ユーザＡがローカル対戦ボタンＢ１４を選択した場合の画面遷移を説明する。例えば、ローカル対戦は、複数のモードが用意されており、ユーザＡがローカル対戦ボタンＢ１４を選択すると、モードを選択するためのダイアログが表示される。

図３は、ユーザがローカル対戦ボタンＢ１４を選択した場合のメニュー画像の一例を示す図である。図３に示すように、ダイアログＤ１５には、ローカル対戦における複数のモードが選択可能に表示される。ここでは、ローカル対戦のモードとして、１対１で１試合のみプレイするエキシビションと、複数のユーザが総当たり戦で対戦するローカルリーグと、の２種類が用意されている場合を説明するが、ローカル対戦のモードは、１種類だけであってもよいし３種類以上が用意されていてもよい。例えば、勝ち抜き戦が行われるトーナメント形式のモードが用意されていてもよいし、総当たり戦で予選リーグを行い、勝ち抜き戦の決勝リーグが行わるといったモードが用意されていてもよい。

例えば、ダイアログＤ１５には、エキシビションをプレイするためのエキシビションボタンＢ１５０が表示される。ユーザＡがエキシビションボタンＢ１５０を選択すると、無線通信可能な他の端末と通信しながら１対１で１試合のみのローカル対戦をプレイすることができる。また例えば、ダイアログＤ１５には、エキシビションの過去の戦績を表示させるための戦績ボタンＢ１５１が表示される。ユーザＡが戦績ボタンＢ１５１を選択すると、ユーザＡが過去にプレイしたエキシビションの戦績を表示させることができる。また例えば、ダイアログＤ１５には、エキシビションの試合の履歴を表示させるための試合履歴ボタンＢ１５２が表示される。ユーザＡが試合履歴ボタンＢ１５２を選択すると、ユーザが過去にプレイしたエキシビションの履歴を表示させることができる。

また例えば、ダイアログＤ１５には、ローカルリーグをプレイするためのローカルリーグボタンＢ１５３が表示される。ユーザＡがローカルリーグボタンＢ１５３を選択すると、ローカルリーグをプレイすることができる。また例えば、ダイアログＤ１５には、ローカルリーグの過去の参加履歴を表示させるための参加履歴ボタンＢ１５４が表示される。ユーザＡが参加履歴ボタンＢ１５４を選択すると、ローカルリーグの参加履歴を表示させることができる。なお、ユーザＡが戻るボタンＢ１５５を選択すると、ダイアログＤ１５が消去される。

ここでは、主に、ローカルリーグに係る処理を説明する。このため、以降では、ユーザＡがローカルリーグボタンＢ１５３を選択した場合の画面遷移を説明する。例えば、ユーザＡがローカルリーグボタンＢ１５３を選択すると、参加可能な対戦部屋を検索するための対戦部屋検索画像が表示部１５に表示される。

図４は、対戦部屋検索画像の一例を示す図である。図４に示すように、対戦部屋検索画像Ｇ２は、ユーザＡが入室可能な対戦部屋の一覧を表示するための表示領域Ａ２０を含む。仮に、ユーザＡの近くにいるユーザＢ，Ｃが対戦部屋を生成していれば、表示領域Ａ２０には、当該対戦部屋が表示されるが、ここでは、まだ誰も対戦部屋を生成していないので、表示領域Ａ２０には、対戦部屋は表示されず、対戦部屋を検索中であることを示すメッセージが表示される。

また例えば、対戦部屋検索画像Ｇ２には、対戦部屋を新たに生成するための新規作成ボタンＢ２１が表示される。ユーザＡが新規作成ボタンＢ２１を選択すると、新たに対戦部屋を生成することができる。例えば、ユーザＡがローカル対戦ボタンＢ１４を選択すると、対戦部屋の名前を入力するためのダイアログが表示される。なお、ユーザＡが再読み込みリロードボタンＢ２２を選択すると、対戦部屋検索画像Ｇ２のリロードをすることができる。

図５は、ユーザＡが新規作成ボタンＢ２１を選択した場合の対戦部屋検索画像Ｇ２の一例を示す図である。図５に示すように、ダイアログＤ２３には、対戦部屋の名前を入力するための入力フォームＦ２３０が表示される。例えば、ユーザＡは、自分が生成する対戦部屋に好きな名前を付けることができる。なお、ユーザＡがキャンセルボタンＢ２３１を選択すると、ダイアログＤ２３が消去される。

また例えば、対戦部屋検索画像Ｇ２には、ユーザＡが入力した対戦部屋の名前を確定するためのＯＫボタンＢ２３２が表示される。ユーザＡが入力フォームＦ２３０に対戦部屋の名前を入力してＯＫボタンＢ２３２を選択すると、当該名前の対戦部屋を生成することができる。なお、ここでは、ダイアログＤ２３から対戦部屋の名前だけを設定可能としている場合を説明するが、名前以外の設定ができるようにしてもよく、例えば、対戦部屋に入室可能なユーザ数などを設定可能であってもよい。

図６は、ユーザＡが対戦部屋を生成した場合の対戦部屋検索画像Ｇ２の一例を示す図である。図６に示すように、対戦部屋の生成が完了したことを示すダイアログＤ２４が対戦部屋検索画像Ｇ２に表示される。ユーザＡがＯＫボタンＢ２４０を選択すると、対戦部屋に入室したユーザを示す対戦部屋画像が表示部１５に表示される。

図７は、対戦部屋画像の一例を示す図である。図７に示すように、対戦部屋画像Ｇ３は、対戦部屋に入室したユーザに関する情報を表示するための表示領域Ａ３０を含む。本実施形態では、対戦部屋に４人まで入室可能な場合を説明するが、対戦部屋に入室可能なユーザ数は、４人に限られず、２人又は３人であってもよいし、５人以上であってもよい。例えば、表示領域Ａ３０は、表示領域Ａ３００〜Ａ３０３を含み、入室中のユーザの詳細を表示可能となっている。

本実施形態では、対戦部屋を生成したユーザが当該対戦部屋に関連付けられるものとして説明するが、特に対戦部屋を生成したユーザは対戦部屋に関連付けられなくてもよい。即ち、対戦部屋を生成したユーザは、必ずしも当該対戦部屋に関連付けられなくてもよい。ここでは、ユーザＡが対戦部屋を生成し、ユーザＡが対戦部屋に関連付けられているので、表示領域Ａ３００には、ユーザＡに関する情報が表示される。例えば、表示領域Ａ３００には、ユーザＡが使用するサッカーチームの名前、ユーザＡの名前、及び過去のローカルリーグにおける優勝回数が表示される。

例えば、対戦部屋画像Ｇ３が第１ゲーム端末１０Ａに表示されると、第１ゲーム端末１０は、第２ゲーム端末１０Ｂ及び第３ゲーム端末１０Ｃの各々との無線通信の確立を試みることになる。一方、第２ゲーム端末１０Ｂでは、ユーザＢの操作に基づいて、第１ゲーム端末１０Ａとの無線通信を確立する処理が実行され、第３ゲーム端末１０Ｃでは、ユーザＣの操作に基づいて、第１ゲーム端末１０Ａとの無線通信を確立する処理が実行される。

無線通信としては、任意の無線通信規格を利用可能であり、例えば、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＩＥＥＥ８０２．１１規格の無線ＬＡＮ、赤外線通信、又はｉＢｅａｃｏｎ（登録商標）などが利用されてもよい。更に、１つの無線通信規格だけに限られず、複数の無線通信規格が用いられるようにしてもよい。なお、無線ＬＡＮが用いられる場合には、第１ゲーム端末１０Ａは、プライベートネットワークＰＮ内のドメインネームサーバ５０に対し、自身のＩＰアドレスと、対戦部屋に関する情報と、を関連付けて登録しておき、第２ゲーム端末１０Ｂ及び第３ゲーム端末１０Ｃに当該情報を取得させるようにしてもよい。他の無線通信規格については、第２ゲーム端末１０Ｂ及び第３ゲーム端末１０Ｃは、第１ゲーム端末１０Ａから直接的に、対戦部屋に関する情報を取得してもよい。

ここでは、ユーザＢが第２ゲーム端末１０Ｂを操作して、第１ゲーム端末１０Ａとの無線通信を確立させ、ユーザＡが生成した対戦部屋に入室する場合を説明する。第２ゲーム端末１０Ｂも図２に示すメニュー画像Ｇ１を表示可能であり、ユーザＢがローカル対戦ボタンＢ１４を選択し、ダイアログＤ１５からローカルリーグボタンＢ１５３を選択すると、第２ゲーム端末１０Ｂに対戦部屋検索画像Ｇ２が表示される。

図８は、第２ゲーム端末１０Ｂに表示される対戦部屋検索画像Ｇ２の一例を示す図である。例えば、第２ゲーム端末１０Ｂが第１ゲーム端末１０Ａと無線通信をすることによって、ユーザＡが対戦部屋を生成済みであることが特定され、図８に示すように、表示領域Ａ２０には、ユーザＡが生成した対戦部屋に入室するための入室ボタンＢ２００が表示される。例えば、入室ボタンＢ２００には、対戦部屋の名前と、対戦部屋を生成したユーザＡの名前と、が表示される。なお、入室ボタンＢ２００には、他の情報が表示されるようにしてもよく、例えば、ユーザＡのアイコン画像が表示されてもよいし、ユーザＡのサッカーチームが表示されてもよい。

例えば、ユーザＢが入室ボタンＢ２００を選択すると、ユーザＡが生成した対戦部屋に入室する。なお、ユーザＣも同様の流れによって、ユーザＡが生成した対戦部屋に入室することができる。ユーザＢ，ＣがユーザＡの対戦部屋に入室すると、第１ゲーム端末１０Ａに表示された対戦部屋画像Ｇ３の表示が変わり、対戦部屋にユーザＢ，Ｃが入室したことが分かるようになっている。

図９は、ユーザＢ，ＣがユーザＡの対戦部屋に入室した場合の対戦部屋画像Ｇ３の一例を示す図である。図９に示すように、例えば、表示領域Ａ３０２には、ユーザＢの詳細情報が表示され、例えば、ユーザＢが使用するサッカーチームの名前、ユーザＢの名前、及び過去のローカルリーグにおける優勝回数が表示される。また例えば、表示領域Ａ３０３には、ユーザＣの詳細情報が表示され、例えば、ユーザＣが使用するサッカーチームの名前、ユーザＣの名前、及び過去のローカルリーグにおける優勝回数が表示される。

例えば、ユーザＡは、ユーザＢ，Ｃが対戦部屋に入室したことを確認すると、ローカルリーグを開始するための所定操作を行う。その後、例えば、ユーザＡ，Ｂ，Ｃの中で総当たり戦となるように対戦組み合わせが決定され、当該対戦組み合わせを示す対戦組み合わせ画像Ｇ４が表示部１５に表示される。

図１０は、対戦組み合わせ画像Ｇ４の一例を示す図である。図１０に示すように、対戦組み合わせ画像Ｇ４は、ユーザＡの試合の対戦組み合わせを表示するための表示領域Ａ４０を含む。例えば、表示領域Ａ４０に示すように、ユーザＡは、第１試合でユーザＢと対戦し、その後に、第２試合でユーザＣと対戦する。

また例えば、表示領域Ａ４０には、対戦部屋から退室するための退室ボタンＢ４００が表示される。ユーザＡが退室ボタンＢ４００を選択すると、入室中の対戦部屋から退室することができる。第２ゲーム端末１０Ｂ及び第３ゲーム端末１０Ｃにも、図１０と同様の対戦組み合わせ画像Ｇ４が表示されており、ユーザＢ，Ｃは、退室ボタンＢ４００を選択することで対戦部屋から退室することができる。

なお、退室ボタンＢ４００は、対戦組み合わせ画像Ｇ４以外の画像に表示されるようにしてもよく、例えば、メニュー画像Ｇ１、対戦部屋検索画像Ｇ２、及び対戦部屋画像Ｇ３の少なくとも１つに退室ボタンＢ４００が表示されてもよいし、後述するマッチング画像やゲーム画像において退室ボタンＢ４００が表示されてもよい。

また、ユーザが対戦部屋から退室するのは、退室ボタンＢ４００が選択された場合に限られない。特に退室ボタンＢ４００が表示されず、予め定められた条件が満たされた場合にユーザが退室してもよい。例えば、一定時間の間、ユーザが何の操作もしなかった場合に、当該ユーザを退室させるようにしてもよい。また例えば、一定時間の間、ゲームサーバ３０がゲーム端末１０から何の情報も受信しなかった場合に、当該ゲーム端末１０のユーザを退室させるようにしてもよい。また例えば、一定時間の間、対戦部屋を生成したユーザのゲーム端末１０と無線通信できなかったり、プライベートネットワークＰＮの通信範囲外となったりした場合に、ユーザを退室させるようにしてもよい。

対戦組み合わせ画像Ｇ４が表示されると、ローカルリーグの試合が開始する。例えば、ユーザＡ，Ｂ，Ｃが参加するローカルリーグでは、総当たり戦で合計３試合が行われて勝ち点や得失点差を競う。例えば、対戦組み合わせ画像Ｇ４が表示された後に、ユーザＡが第１試合をプレイするための所定操作をすると、第１試合で対戦するユーザＢの第２ゲーム端末１０Ｂとマッチング処理をするためのマッチング画像が表示部１５に表示される。

図１１は、マッチング画像の一例を示す図である。図１１に示すように、マッチング画像Ｇ５には、試合を開始するための前処理であるマッチング中であることを示すメッセージが表示される。例えば、マッチング中においては、第１ゲーム端末１０Ａと第２ゲーム端末１０Ｂとの間で、ゲームに必要なデータ（例えば、試合で使用するキャラクタのデータやユーザが選択した戦術・フォーメーションなどのデータ）が送受信される。

マッチング処理が完了すると、第１試合が開始し、実行中のゲームの様子を示すゲーム画像が表示部１５に表示される。なお、第１試合が行われている間は、ユーザＣは第１試合が終了するのを待機するが、その間も第３ゲーム端末１０Ｃと、第１ゲーム端末１０Ａ及び第２ゲーム端末１０Ｂと、の間の無線通信は維持されているものとする。

図１２は、試合開始後に表示されるゲーム画像の一例を示す図である。図１２に示すように、ゲーム画像Ｇ６には、例えば、ゲームキャラクタが配置されたゲーム空間を仮想カメラから見た様子が表示される。なお、ローカルリーグにおける試合の進行方法自体は、公知の種々の進行方法を適用可能であり、例えば、ユーザＡとユーザＢは、それぞれ自分のチームの何れかのキャラクタを操作して得点をあげることを目指す。第１試合が終了すると、第１試合の結果等が表示された後に、対戦組み合わせ画像Ｇ４に戻る。

図１３は、第１試合が終了した場合の対戦組み合わせ画像Ｇ４の一例を示す図である。図１３に示すように、対戦組み合わせ画像Ｇ４の表示領域Ａ４０には、終了した第１試合の対戦組み合わせが消去され、第２試合の対戦組み合わせが表示される。即ち、対戦組み合わせ画像Ｇ４では、ローカルリーグにおいて、どの試合が残っているかを容易に把握できるようになっている。以降、第１試合と同様の流れにより、ユーザＡとユーザＣとの第２試合と、ユーザＢとユーザＣとの第３試合と、が実行される。

例えば、第２試合では、第１ゲーム端末１０Ａと第３ゲーム端末１０Ｃとの間でマッチング処理が実行され、無線通信しながらゲームが実行されることになる。また例えば、第３試合では、第２ゲーム端末１０Ｂと第３ゲーム端末１０Ｃとの間でマッチング処理が実行され、無線通信しながらゲームが実行されることになる。ローカルリーグの全試合が終了すると、ローカルリーグにおける表彰式を示す表彰式画像が表示部１５に表示される。

図１４は、表彰式画像の一例を示す図である。図１４に示すように、表彰式画像Ｇ７には、仮想世界において表彰式が行われる様子が表示される。例えば、勝ち点が高い順にユーザの順位が決まり、勝ち点が同じ場合には得失点差や直接対決の結果によって順位が決まる。表彰式画像Ｇ７が表示されると、ユーザＡ，Ｂ，Ｃの間で行われるローカルリーグは終了する。

なお、ローカルリーグを最後までプレイした場合（即ち、表彰式画像Ｇ７がゲーム端末１０に表示された場合）には、ユーザＡ，Ｂ，Ｃにゲームアイテムやゲーム内通貨などの報酬が与えられるようにしてもよい。その後、ゲーム端末１０間の無線通信が切断されるようにしてもよいし、無線通信を維持したままローカルリーグを繰り返しプレイできるようにしてもよい。また、表彰式画像Ｇ７が表示されてローカルリーグが終了した場合に対戦部屋に関するデータが消滅してもよいし、対戦部屋を消滅させるための操作をユーザが行った場合に対戦部屋に関するデータが消滅してもよい。

上記のように、表彰式画像Ｇ７が表示される前であったとしても（即ち、ローカルリーグを最後までプレイしなくても）、ユーザは、退室ボタンＢ４００を選択することで対戦部屋から途中退室できるようになっている。対戦部屋を生成したユーザが途中退室したり、ユーザの退室によって対戦部屋内の合計人数が一定人数未満（例えば、３人未満）になったりしたローカルリーグは、最後まで試合をすることができず、そのままゲームサーバ３０に不要なデータが残ってしまうため、ゲームデータの消費量が増加する要因となる。

このため、本実施形態では、ローカルリーグに参加した何れかのユーザが途中退室すると、対戦部屋を生成したユーザが、一定時間の間、新たな対戦部屋を生成することができないようにしている。別の言い方をすれば、ローカルリーグに参加した何れかのユーザが途中退室すると、対戦部屋を生成したユーザに対するペナルティが与えられる。ユーザにペナルティが与えられると、対戦部屋検索画像Ｇ２の新規作成ボタンＢ２１を選択しても、新たな対戦部屋を生成することができない。なお、ペナルティが与えられるのは、対戦部屋を生成したユーザだけでなく、対戦部屋に入室したユーザ全員であってもよいし、対戦部屋に入室したユーザの一部だけにペナルティが与えられるようにしてもよい。

図１５は、ペナルティが与えられた場合の対戦部屋検索画像Ｇ２の一例を示す図である。図１５に示すように、ダイアログＤ２５には、対戦部屋を生成できないことを示すメッセージが表示され、ユーザが新規作成ボタンＢ２１を選択しても、新たな対戦部屋を生成することはできない。なお、ユーザが新規作成ボタンＢ２１を選択すること自体ができないようにしてもよい。例えば、新規作成ボタンＢ２１をグレーアウトしてもよいし、新規作成ボタンＢ２１自体を表示させないようにしてもよい。また、ダイアログＤ２５にペナルティが課される残り時間を表示させてもよい。

なお、１人のユーザが生成できる対戦部屋を１つまでとしてもよいが、１人のユーザが複数の対戦部屋を生成できるようにする場合には、何れか１つの対戦部屋で途中退室が発生した場合にペナルティが与えられるようにしてもよいし、所定個数の対戦部屋で途中退室が発生した場合にペナルティが与えられるようにしてもよい。本実施形態では、あるユーザが生成した対戦部屋のうち、３つの対戦部屋で途中退室が発生した場合に、当該ユーザに対してペナルティが与えられるようになっている。

以上のように、本実施形態のゲームシステムＳでは、あるユーザが生成した対戦部屋で途中退室が発生した場合に、当該ユーザにペナルティを与えることで、ローカルリーグが終了しない対戦部屋が乱立することを防止し、ゲームシステムＳ内のゲームデータの消費量の増加を防止することができるようになっている。以降、当該構成の詳細を説明する。

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

［３−１．ゲームサーバで実現される機能］
図１６に示すように、ゲームサーバ３０では、データ記憶部３００、生成部３０１、入室部３０２、退室部３０３、第１判定部３０４、第２判定部３０５、第３判定部３０６、第４判定部３０７、報酬付与部３０８、及び表示制御部３０９が実現される。

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

図１７は、ユーザデータベースＤＢ１のデータ格納例を示す図である。図１７に示すように、ユーザデータベースＤＢ１は、ゲームシステムＳを利用するユーザに関するデータであり、例えば、ユーザを一意に識別するユーザＩＤに関連付けて、ユーザの名前、画像、サッカーチームの名前、及びペナルティ情報が格納される。なお、ここでは、ユーザを一意に識別する情報は、ユーザを識別可能な情報であればよく、例えば、ユーザＩＤではなくユーザ名が用いられてもよい。

ペナルティ情報は、新たな対戦部屋を生成できないようにするペナルティの発生中であるか否かを示す情報である。例えば、ペナルティ情報は、途中退室が発生した回数、ペナルティが発生した日時、及び発生中フラグを含む。

途中退室が発生した回数とは、例えば、ユーザが生成した対戦部屋のうち、何個の対戦部屋で途中退室が発生したかを示す情報である。ユーザが生成した対戦部屋で途中退室が発生するたびに回数が増加し、回数が閾値（ここでは３とする）以上になった場合に、ペナルティが発生する。

なお、閾値は３に限られず、２であってもよいし、４以上であってもよい。更に、ユーザによって閾値が異なってもよい。例えば、ペナルティが発生したユーザの閾値を減少させてペナルティが発生しやすくしてもよいし、逆に、ペナルティが一定期間発生しなかったユーザの閾値を増加させてペナルティが発生しにくくしてもよい。

発生中フラグは、ペナルティが発生中であるか否かを示す情報である。例えば、発生中フラグがオンの場合はペナルティの発生中であることを示し、発生中フラグがオフの場合はペナルティの発生中ではないことを示す。途中退室が発生した回数が閾値以上になった場合に、発生中フラグがオンになり、ペナルティが発生する。一方、ペナルティが発生してから一定時間が経過すると、発生中フラグがオフになり、ペナルティが解除される。この場合、途中退室が発生した回数はリセットされる。

図１８は、対戦部屋データベースＤＢ２のデータ格納例を示す図である。図１８に示すように、対戦部屋データベースＤＢ２は、ユーザが生成した対戦部屋に関するデータであり、例えば、対戦部屋を一意に識別する対戦部屋ＩＤに関連付けて、対戦部屋の名前、対戦部屋を生成したユーザに関する生成ユーザ情報、対戦部屋に入室したユーザに関する入室ユーザ情報、及び対戦部屋におけるゲームの状況や結果などを示すゲームデータが格納される。以降、対戦部屋データベースＤＢ２に格納される個々のレコードを部屋情報と記載する。

生成ユーザ情報としては、例えば、対戦部屋を生成したユーザのユーザＩＤ、当該ユーザのゲーム端末１０を識別するための端末識別情報、当該ユーザの名前、及び当該ユーザの優勝回数等の情報が格納される。また例えば、端末識別情報は、ゲーム端末１０を識別可能な情報であればよく、例えば、ＩＰアドレスや個体識別情報などである。入室ユーザ情報としては、例えば、対戦部屋に入室したユーザのユーザＩＤ、当該ユーザのゲーム端末１０を識別するための端末識別情報、当該ユーザの名前、及び当該ユーザの優勝回数等の情報が格納される。

ゲームデータとしては、例えば、対戦部屋で実行されるゲームの現在の状況やローカルリーグの結果が格納される。例えば、ゲームデータには、対戦部屋内で行われる試合ごとに、当該試合で対戦するユーザのユーザＩＤ、試合の状況情報、及び試合の結果情報が格納される。例えば、状況情報は、ゲーム空間におけるキャラクタの位置・姿勢・向き・移動方向・移動方向、ボールの位置・移動方向・移動速度、仮想カメラの位置・視線方向、試合の経過時間、キャラクタの交代状況、及び両チームの得点が格納される。試合の結果情報は、試合の勝敗、両チームの得点、試合のスタッツ情報（例えば、ボール支配率や平均走行距離）などが格納される。ゲームデータには、他にも各ユーザの勝利数・敗北数・引き分け数・勝ち点・順位などの情報が格納されていてもよい。

なお、データ記憶部３００に記憶されるデータは、上記の例に限られない。データ記憶部３００は、ゲームに必要なデータを記憶すればよい。例えば、データ記憶部３００は、ユーザのサッカーチームのキャラクタに関するデータ（例えば、キャラクタの名前や能力パラメータなど）を記憶してもよい。また例えば、データ記憶部１００は、ユーザが保有するゲームアイテムやゲーム内通貨に関するデータを記憶してもよい。また例えば、データ記憶部１００は、ユーザが参加したエキシビションの過去の戦績・試合履歴やローカルリーグの参加履歴を記憶してもよい。

［３−１−２．生成部］
生成部３０１は、制御部３１を主として実現される。生成部３０１は、ユーザの要求に基づいて対戦部屋を生成する。要求とは、例えば、対戦部屋を生成するための操作をすることである。また例えば、要求は、当該操作が行われたことを示す情報をゲームサーバ３０に送信することである。以降、この要求を生成要求という。本実施形態では、ユーザが新規作成ボタンＢ２１を選択すると生成要求が行われる。

生成要求は、所定形式のデータが送信されることによって行われるようにすればよく、例えば、生成要求には、ユーザＩＤと、入力フォームＦ２３０に入力された対戦部屋の名前と、が含まれるものとするが、生成要求には、他の情報が含まれてもよく、例えば、ゲーム端末１０の識別情報、ユーザ名、及びユーザの優勝回数等が含まれていてもよい。

本実施形態では、生成部３０１がゲームサーバ３０において実現されるので、生成部３０１は、ゲーム端末１０から生成要求を受信したか否かを判定する。生成要求を受信したと判定された場合、生成部３０１は、生成要求に含まれる情報に基づいて、対戦部屋を生成し、対戦部屋データベースＤＢ２を更新する。

例えば、生成部３０１は、対戦部屋の対戦部屋ＩＤを生成する。対戦ＩＤは、予め定められたＩＤ生成ルールによって生成されるようにすればよく、他の対戦部屋の対戦ＩＤと重複しないように生成すればよい。そして、制御部３１は、対戦部屋データベースＤＢ２に新たなレコードを生成し、生成した対戦部屋ＩＤに関連付けて、対戦部屋名、対戦部屋を生成したユーザのユーザＩＤ、端末識別情報、及び優勝回数を生成ユーザ情報・入室ユーザ情報に格納する。対戦部屋データベースＤＢ２にこれらの情報が格納されることによって、対戦部屋の生成が完了する。

本実施形態では、ユーザは複数の対戦部屋を生成可能なので、生成部３０１は、ユーザの生成要求が行われるたびに対戦部屋を生成する。例えば、ユーザは、自分が生成した対戦部屋が残っている状態で、新たな対戦部屋の生成要求をすることができる。別の言い方をすれば、ユーザは繰り返し生成要求をすることができ、生成部３０１は、対戦部屋を繰り返し生成することができる。

［３−１−３．入室部］
入室部３０２は、制御部３１を主として実現される。入室部３０２は、ユーザの入室要求に基づいて対戦部屋にユーザを関連付ける。先述したように、対戦部屋にユーザを関連付けることは、ユーザが対戦部屋に入室することを意味するので、入室部３０２は、ユーザの入室要求に基づいて対戦部屋にユーザを入室させることになる。

入室とは、例えば、対戦部屋にユーザが関連付けられない状態から関連付けられる状態に変化させることである。例えば、対戦部屋にユーザが関連付けられることは、対戦部屋にユーザが入室することを意味する。また例えば、対戦部屋ＩＤにユーザＩＤが関連付けられることが入室に相当する。また例えば、対戦部屋ＩＤとユーザＩＤとが同じレコードに格納されることが入室に相当する。別の言い方をすれば、ゲームをプレイすることの希望しない状態から希望する状態に変えることであり、ゲームをプレイしない状態からプレイ可能な状態に変えることである。

入室要求は、例えば、対戦部屋に入室するための操作をすることである。また例えば、入室要求は、当該操作が行われたことを示す情報をゲームサーバ３０に送信することである。本実施形態では、ユーザが入室ボタンＢ２３を選択すると入室要求が行われる。入室要求は、所定のデータ形式で行われるようにすればよく、例えば、ユーザが指定した対戦部屋の対戦部屋ＩＤ、ユーザＩＤ、端末識別情報、ユーザ名、及び優勝回数等の情報を含む。ユーザが指定した対戦部屋とは、入室ボタンＢ２３を選択することで入室可能な対戦部屋である。例えば、入室ボタンＢ２３と、入室可能な対戦部屋の対戦部屋ＩＤと、は予め関連付けられており、ユーザが入室ボタンＢ２３を選択した場合に、入室対象となる対戦部屋の対戦部屋ＩＤを特定可能となっている。

本実施形態では、入室部３０２がゲームサーバ３０において実現されるので、入室部３０２は、ゲーム端末１０から入室要求を受信したか否かを判定する。入室要求を受信したと判定された場合、生成部３０１は、入室要求に含まれる情報に基づいて、対戦部屋にユーザを入室させる。例えば、入室部３０２は、対戦部屋データベースＤＢ２を参照し、入室要求に含まれる対戦ＩＤが格納されたレコードの入室ユーザ情報に、入室要求に含まれるユーザＩＤ、端末識別情報、ユーザ名、及び優勝回数等の情報を格納する。ユーザに関するこれらの情報が対戦部屋データベースＤＢ２に格納されると、対戦部屋への入室が完了する。

［３−１−４．退室部］
退室部３０３は、制御部３１を主として実現される。退室部３０３は、対戦部屋に関連付けられたユーザの関連付けを解除する。退室部３０３は、解除手段の一例である。

関連付けを解除するとは、例えば、対戦部屋にユーザが関連付けられた状態から関連付けられない状態に変化させることである。関連付けを解除するとは、対戦部屋から退室することである。例えば、対戦部屋ＩＤにユーザＩＤが関連付けられなくなることが解除に相当する。また例えば、対戦部屋ＩＤとユーザＩＤとが同じレコードに格納されなくなることが解除に相当する。別の言い方をすれば、ゲームをプレイすることの希望を解除することであり、ゲームをプレイ可能な状態からプレイしない状態に変えることである。

例えば、退室部３０３は、ユーザの退室要求に基づいて対戦部屋からユーザを退室させる。退室要求は、例えば、対戦部屋に退室するための操作をすることである。また例えば、退室要求は、当該操作が行われたことを示す情報をゲームサーバ３０に送信することである。本実施形態では、ユーザが退室ボタンＢ４００を選択すると退室要求が行われる。

退室要求は、所定のデータ形式で行われるようにすればよく、例えば、ユーザが指定した対戦部屋の対戦部屋ＩＤ、ゲーム端末１０のユーザＩＤ、端末識別情報、ユーザ名、及び優勝回数等の情報を含む。ここでのユーザが指定した対戦部屋とは、退室ボタンＢ４００を選択することで退室可能な対戦部屋である。例えば、退室ボタンＢ４００と、退室可能な対戦部屋の対戦部屋ＩＤと、は予め関連付けられており、ユーザが退室ボタンＢ４００を選択した場合に、退室対象となる対戦部屋の対戦部屋ＩＤを特定可能となっている。

本実施形態では、退室部３０３がゲームサーバ３０において実現されるので、退室部３０３は、ゲーム端末１０から退室要求を受信したか否かを判定する。退室要求を受信したと判定された場合、生成部３０１は、退室要求に含まれる情報に基づいて、対戦部屋からユーザを退室させる。例えば、退室部３０３は、対戦部屋データベースＤＢ２を参照し、退室要求に含まれる対戦ＩＤが格納されたレコードの入室ユーザ情報から、退室要求に含まれるユーザＩＤ、端末識別情報、ユーザ名、及び優勝回数等の情報を削除する。ユーザに関するこれらの情報が対戦部屋データベースＤＢ２から削除されると、対戦部屋への退室が完了する。

なお、対戦部屋からユーザを退室させるにあたり、対戦部屋データベースＤＢ２から情報を削除する必要はなく、例えば、ユーザが退室済みであるか否かを示すフラグを用意しておき、退室部３０３は、入室ユーザ情報を残したまま当該フラグの値を変更することによって、ユーザが退室した状態となるようにしてもよい。

また、先述したように、退室部３０３は、ユーザが特に退室要求をしなかったとしても、予め定められた条件が満たされた場合にユーザを退室させてもよい。例えば、退室部３０３は、ゲーム端末１０との通信内容に基づいて、一定時間の間、ユーザが何の操作もしない状態が継続したか否かを判定し、一定時間の間、ユーザが何の操作もしなかったと判定した場合に、当該ユーザを退室させるようにしてもよい。

また例えば、退室部３０３は、ゲーム端末１０との通信内容に基づいて、一定時間の間、ゲーム端末１０から何の情報も受信しない状態が継続したか否かを判定し、一定時間の間、ゲーム端末１０から何の情報も受信しなかったと判定した場合に、当該ユーザを退室させるようにしてもよい。また例えば、退室部３０３は、一定時間の間、対戦部屋を生成したユーザのゲーム端末１０に対し、無線通信できない他のゲーム端末１０が存在するか否かを問い合わせ、当該問い合わせに対する応答結果に基づいて、当該他のゲーム端末１０のユーザを退室させてもよい。また例えば、退室部３０３は、プライベートネットワークＰＮ内の通信機器に対し、通信範囲外となったゲーム端末１０が存在するか否かを問い合わせ、当該問い合わせに対する応答結果に基づいて、当該ゲーム端末１０のユーザを退室させてもよい。

［３−１−５．第１判定部］
第１判定部３０４は、制御部３１を主として実現される。第１判定部３０４は、対戦部屋（ユーザの要求に基づいて生成された対戦部屋）に関連付けられたゲームの実行状況が所定の条件を満たすか否かを判定する。

対戦部屋に関連付けられたゲームとは、例えば、対戦部屋の中で行われるゲームであり、対戦部屋に関連付けられたユーザが対戦するゲームである。なお、先述したように、対戦部屋にユーザが関連付けられるとは、例えば、対戦部屋にユーザＩＤが関連付けられることである。また例えば、対戦部屋に関連付けられたゲームは、ユーザが、同じ対戦部屋に関連付けられた他のユーザと対戦するゲームである。また例えば、対戦部屋に関連付けられたゲームは、対戦部屋に関連付けられた複数のユーザが一緒に遊ぶゲームである。また例えば、対戦部屋に関連付けられたゲームは、対戦部屋ＩＤを識別する情報に、ゲームの状況を示すゲームデータが関連付けられるゲームである。

ゲームの実行状況とは、例えば、ゲームがどの程度進行しているかであり、ゲームデータにより特定される状況である。例えば、対戦が終わったか否かである。また例えば、ゲームの実行状況は、所定回数の対戦が終わったか否かである。複数回の対戦が行われる場合には、ゲームの実行状況は、何回の対戦が終了したかである。また例えば、ゲームの実行状況は、ゲーム開始からの経過時間である。また例えば、ゲームの実行状況は、複数のステージを順番に進めるゲームであれば、現在のステージである。また例えば、ゲームの実行状況は、スコアを獲得するゲームであれば、現在のスコアである。スポーツゲームであれば、ゲームの実行状況は、例えば試合がどの程度進行しているかである。野球ゲームであれば、ゲームの実行状況は、例えば現在のイニングである。サッカーゲームであれば、ゲームの実行状況は、例えば試合の経過時間である。

所定の条件とは、例えば、予め定められた条件であればよく、所定の事象が発生することである。また例えば、所定の条件は、ゲームの実行状況が所定の状況になることである。また例えば、所定の条件は、ゲームの実行状況が所定の状況になる前に、対戦部屋との関連付けを解除すること、一定時間が経過すること、通信が切断すること、操作がない状態が一定時間経過することなどである。

本実施形態では、所定の条件の一例として、ゲームが所定の実行状況になる前に、少なくとも１人のユーザと対戦部屋との関連付けが解除されること（即ち、退室すること）を説明する。所定の実行状況としては、予め定められた実行状況であればよく、ここでは、表彰式画像Ｇ７をゲーム端末１０に表示させることである場合を一例として説明する。例えば、表彰式画像Ｇ７がゲーム端末１０に少しでも表示された場合に所定の実行状況になったとしてもよいし、表彰式画像Ｇ７における表彰式が最後まで表示された場合に所定の実行状況になったとしてもよいし、その間の任意の時点まで表彰式が表示された場合に所定の実行状況になったとしてもよい。

例えば、所定の条件は、後述する表示制御部３０９により成績が表示されることであってよく、ゲーム端末１０は、自身の表示部１５に表彰式画像Ｇ７が表示されたか否かを判定し、表示されたと判定した場合に、ゲームサーバ３０に対し、所定の実行状況になったことを通知する。第１判定部３０４は、ゲーム端末１０から当該通知を受信したか否かを判定することによって、ゲームが所定の実行状況になったか否かを判定する。

また例えば、第１判定部３０４は、退室部３０３の処理結果に基づいて、少なくとも１人のユーザが対戦部屋から途中退室したか否かを判定する。少なくとも１人とは、１人だけであってもよいし、２人以上であってもよい。本実施形態では、１人でも途中退室した場合にペナルティが発生する場合を説明するが、２人以上が途中退室した場合にペナルティが発生することにしてもよい。第１判定部３０４は、退室部３０３の処理結果に基づいて、所定人数のユーザが対戦部屋から途中退室したか否かを判定する。

例えば、第１判定部３０４は、対戦部屋データベースＤＢ２に格納された入室ユーザ情報を参照し、ユーザの数が減少した場合に、ユーザが対戦部屋から退室したと判定する。また例えば、対戦部屋データベースＤＢ２に退室済みか否かを示すフラグを用意しておく場合には、第１判定部３０４は、対戦部屋データベースＤＢ２に格納されたフラグを参照し、ユーザが対戦部屋から退室したか否かを判定する。

［３−１−６．第２判定部］
第２判定部３０５は、制御部３１を主として実現される。第２判定部３０５は、第１判定部３０４の判定結果に基づいて、ユーザの要求により新たな対戦部屋を生成するか否かを判定する。

例えば、第２判定部３０５は、第１判定部３０４により所定の条件が満たされたと判定された場合に、新たな対戦部屋を生成すると判定し、第１判定部３０４により所定の条件が満たされないと判定された場合に、新たな対戦部屋を生成しないと判定する。なお、所定の条件の定め方によっては、これとは逆に、第２判定部３０５は、第１判定部３０４により所定の条件が満たされないと判定された場合に、新たな対戦部屋を生成すると判定し、第１判定部３０４により所定の条件が満たされたと判定された場合に、新たな対戦部屋を生成しないと判定してもよい。

第２判定部３０５が新たな対戦部屋を生成すると判定することは、例えば、生成部３０１に対戦部屋の生成を許可することであり、生成部３０１に対し、対戦部屋の生成を指示することである。一方、第２判定部３０５が新たな対戦部屋を生成しないと判定することは、新たな対戦部屋を生成すると判定しないことであり、例えば、ゲーム端末１０に対し生成要求自体をできなくすること、生成要求を受け付けないこと、生成要求を受け付けても無視して対戦部屋を生成しないこと、生成部３０１に対戦部屋の生成を禁止すること、生成部３０１に対し、対戦部屋の生成を指示しないことなどである。

第２判定部３０５は、ユーザの要求により生成された複数の対戦部屋のうちの所定数以上の対戦部屋についての第１判定部３０４の判定結果に基づいて、ユーザの要求により新たな対戦部屋を生成するか否かを判定する。所定数とは、例えば、予め定められた閾値であればよく、例えば、２回、３回、又は４回以上である。当該所定数は、データ記憶部３００に予め記憶させておけばよい。

例えば、第２判定部３０５は、ユーザデータベースＤＢ１のペナルティ情報を参照し、途中退室が発生した回数が閾値以上になったか否かを判定する。例えば、途中退室が発生した回数が閾値以上になったか否かを判定することによって、第２判定部３０５は、所定数以上の対戦部屋について所定の条件が満たされたか否かを判定する。

例えば、第２判定部３０５は、対戦部屋が生成された時点、又は、ローカルリーグが開始された時点から所定期間を経過したか否かを判定する。また例えば、所定期間を経過したかを判定する開始時期は、退室ボタンＢ４００を押した時点としてもよいが、上記のようにするのは、発明の趣旨が対戦部屋の乱立を防ぐためであるため、例えば長期間かかってローカルリーグをプレイし、最終的にリーグを正常に終了することができなかった場合、退室した時からペナルティ期間が発生すると、ユーザにとって酷になるからである。具体的には、所定期間が３時間であったとして、対戦部屋を生成し、ローカルリーグを開始してから２時間たったときにローカルリーグを終了させることができず、対戦部屋を作成したユーザが退室した場合は、退室した時点から１時間待てば、第２判定部３０５は所定の条件が満たされたと判定する。このようにすれば、対戦部屋を乱立させないことが主目的であって、ユーザのプレイ活動を阻害するものではないようにすることができる。

［３−１−７．第３判定部］
第３判定部３０６は、制御部３１を主として実現される。第３判定部３０６は、ユーザの要求により新たな対戦部屋が生成されない状態が所定の期間継続したか否かを判定する。所定の期間とは、例えば、予め定められた期間であればよく、例えば、１〜１２時間程度であってもよいし、数日程度であってもよい。

例えば、第３判定部３０６は、ユーザデータベースＤＢ１のペナルティ情報を参照し、ペナルティが発生した日時から所定の期間が経過したか否かを判定する。第３判定部３０６は、リアルタイムクロック又はＧＰＳ信号等に基づいて現在日時を取得し、ペナルティが発生した日時と現在日時との間隔が閾値以上になったか否かを判定する。

また例えば、第３判定部３０６は、ゲームサーバ３０におけるサーバ時間を取得し、サーバ時間に基づいて、ペナルティが発生した日時と現在日時との間隔が閾値以上になったか否かを判定してもよい。例えば、ゲーム端末１０がゲームサーバ３０に接続したときにサーバ時間を取得してもよい。また例えば、サーバ時間を取得したときの端末時間（第１時間）を記憶し、現在のサーバ時間を知りたい場合は、ゲームサーバ３０にサーバ時間を取得しにいくのではなく、現在の端末時刻（第２時間）を取得し、以前取得したサーバ時間＋（第２時間―第１時間）とすることで、サーバ時間を取得してもよい。ゲームプログラムのサスペンドや第２時間―第１時間の時間が所定数より大きくなった場合は、再びゲームサーバ３０にサーバ時間を問い合わせ、サーバ時間と第１時間を更新させるようにしてもよい。このように構成することで、サーバに対する問い合わせを少なくし、サーバ時間とのずれを最小限にすることができる。

例えば、第２判定部３０５は、第１判定部３０４の判定結果と、第３判定部３０６の判定結果と、に基づいて、ユーザの要求により新たな対戦部屋を生成するか否かを決定する。第２判定部３０５は、第３判定部３０６により新たな対戦部屋が生成されない状態が所定の期間継続したと判定された場合に、新たな対戦部屋を生成すると判定し、第３判定部３０６により新たな対戦部屋が生成されない状態が所定の期間継続していないと判定された場合に、新たな対戦部屋を生成しないと判定する。

［３−１−８．第４判定部］
第４判定部３０７は、制御部３１を主として実現される。第４判定部３０７は、ゲームの実行を開始したか否かを判定する。開始とは、例えば、ゲームを開始するための操作が行われることである。または当該操作が行われたことを示す情報を受信することである。実行中のゲームの画面を端末に表示させることである。ゲームの状況を示すデータを更新することである。

例えば、ゲーム端末１０は、ゲームを開始するための操作が行われた場合に、ゲームの開始要求をゲームサーバ３０に送信する。第３判定部３０６は、ゲーム端末１０から開始要求を受信したか否かを判定する。例えば、第３判定部３０６は、ゲーム端末１０から開始要求を受信したと判定された場合に、ゲームの実行を開始したと判定し、ゲーム端末１０から開始要求を受信していないと判定された場合に、ゲームの実行を開始していないと判定する。

例えば、第２判定部３０５は、第１判定部３０４の判定結果と、第４判定部３０７の判定結果と、に基づいて、ユーザの要求により新たな対戦部屋を生成するか否かを決定する。第２判定部３０５は、第４判定部３０７によりゲームの実行が開始されていない場合に、新たな対戦部屋を生成すると判定し、第４判定部３０７によりゲームの実行が開始されたと判定された場合に、新たな対戦部屋を生成しないと判定する。

［３−１−９．報酬付与部］
報酬付与部３０８は、制御部３１を主として実現される。報酬付与部３０８は、第１判定部３０４の判定結果に基づいて、対戦部屋に関連付けられたユーザに報酬を付与する。報酬とは、例えば、ゲームアイテムやゲーム内通貨（ポイント・コインなど）を付与することである。例えば、報酬付与部３０８は、ユーザＩＤに対し、ゲームアイテムを識別する情報を関連付けることによって、ユーザにゲームアイテムを付与する。また例えば、報酬付与部３０８は、ユーザＩＤに関連付けられたゲーム内通貨を増加させることによって、ユーザにゲーム内通貨を付与する。

例えば、報酬付与部３０８は、第１判定部３０４により所定の条件が満たされたと判定された場合に、ユーザに報酬を付与すると判定し、第１判定部３０４により所定の条件が満たされないと判定された場合に、ユーザに報酬を付与しないと判定する。なお、所定の条件の定め方によっては、これとは逆に、報酬付与部３０８は、第１判定部３０４により所定の条件が満たされないと判定された場合に、ユーザに報酬を付与すると判定し、第１判定部３０４により所定の条件が満たされたと判定された場合に、ユーザに報酬を付与しないと判定してもよい。

［３−１−１０．表示制御部］
表示制御部３０９は、制御部３１を主として実現される。例えば、表示制御部３０９は、ゲームの実行状況を識別するための情報を、対戦部屋に関連付けられたユーザに対応する表示部１５と、対戦部屋を生成したユーザに対応する表示部１５と、の少なくとも一方に表示させる。少なくとも一方とは、対戦部屋に入室したユーザに対応する表示部１５だけであってもよいし、対戦部屋を生成したユーザに対応する表示部１５だけであってもよいし、これらの両方であってもよい。

ゲームの実行状況を識別するための情報とは、例えば、ゲームがどの程度進行しているかを識別可能な情報である。例えば、あるユーザが複数のユーザとプレイする場合には、まだ一緒にプレイしていないユーザを表示させることである。例えば、まだ対戦していないユーザを表示させることである。また例えば、所定の実行状況に達するまでにあとどのくらいかを識別可能な情報である。また例えば、現在の対戦回数である。また例えば、終了した対戦の数である。また例えば、ゲーム開始からの経過時間である。また例えば、複数のステージを順番に進めるゲームであれば、現在のステージである。また例えば、スコアを獲得するゲームであれば、現在の獲得スコアである。また例えば、スポーツゲームであれば、試合の現在の状況である。野球ゲームであれば、現在のイニングである。サッカーゲームであれば、試合の経過時間である。

本実施形態では、対戦組み合わせ画像Ｇ４の表示領域Ａ４０に表示される残りの試合の対戦組み合わせが、ゲームの実行状況を識別するための情報の一例に相当する。表示制御部３０９は、ゲームデータに基づいて残りの試合を特定し、表示領域Ａ４０の表示を更新する。

また例えば、表示制御部３０９は、ゲームの実行結果に基づいて、対戦部屋に関連付けられたユーザの成績を、当該ユーザに対応する表示部１５に表示させる。成績とは、例えば、例えば、ゲームで勝利することである。また例えば、ゲームでの勝利数・勝率・敗北数・引き分け数である。また例えば、ゲームにおける順位である。また例えば、ゲームに参加したユーザの中のランキングである。また例えば、ゲームにおけるユーザのスコアである。

本実施形態では、表彰式画像Ｇ７にユーザの成績が表示される場合を一例として説明する。表示制御部３０９は、ゲームデータに基づいてユーザの成績を特定し、表彰式画像Ｇ７を表示させる。

［３−２．ゲーム端末で実現される機能］
ゲーム端末１０では、データ記憶部１００と対戦実行部１０１が実現される。

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

図１９は、対戦部屋データＤＴ１のデータ格納例を示す図である。図１９に示すように、対戦部屋データＤＴ１には、ユーザが入室した対戦部屋の部屋情報が格納される。部屋情報のデータ構造は、対戦部屋データベースＤＢ２で説明した通りである。

なお、データ記憶部１００に記憶されるデータは、上記の例に限られない。データ記憶部１００は、ゲームに必要なデータを記憶すればよい。例えば、データ記憶部１００は、ゲーム端末１０のユーザに係る基本情報（例えば、ユーザＩＤやユーザ名など）を記憶してもよいし、ユーザが参加したエキシビションの過去の戦績・試合履歴やローカルリーグの参加履歴を記憶してもよい。

［３−２−２．対戦実行部］
対戦実行部１０１は、制御部１１を主として実現される。対戦実行部１０１は、ユーザの操作に基づいて、対戦を実行する。例えば、対戦実行部１０１は、操作部１４からのユーザの操作と、他のゲーム端末の操作部１４からの他のユーザの操作と、に基づいてゲームデータを更新する。例えば、対戦実行部１０１は、ユーザの操作に基づいてキャラクタを動作させ、ゲームが終了した場合にユーザの優劣を決定する。

［４．ゲームシステムにおいて実行される処理］
図２０−図２１は、ゲームシステムＳにおいて実行される処理の一例を示すフロー図である。図２０−図２１に示す処理は、制御部１１が記憶部１２に記憶されたプログラムに従って動作し、制御部３１が記憶部３２に記憶されたプログラムに従って動作することによって実行される。以降説明する処理は、機能ブロックが実行する処理の一例である。ここでは、対戦部屋検索画像Ｇ２からユーザが新規作成ボタンＢ２１を選択して入力フォームＦ２３０に対戦部屋の名前を入力し、ＯＫボタンＢ２３２を選択した場合の処理を説明する。

図２０に示すように、まず、ゲーム端末１０においては、制御部１１は、対戦部屋の生成要求を送信する（Ｓ１０１）。なお、生成要求に含まれるユーザＩＤ等の情報は、予め記憶部１２に記憶されているようにすればよい。以降の説明においても、ゲーム端末１０からゲームサーバ３０に対して何らかの情報が送信される場合には、ユーザＩＤも送信され、ゲームサーバ３０側でどのゲーム端末１０と通信しているか特定可能となっている。また、入力フォームＦ２３０に対戦部屋の名前が入力されていない場合には、ユーザがＯＫボタンＢ２３２を選択しても生成要求が送信されないようにしてもよい。

ゲームサーバ３０においては、生成要求を受信すると、制御部３１は、ユーザデータベースＤＢ１のペナルティ情報に基づいて、生成要求により新たな対戦部屋を生成するか否かを判定する（Ｓ３０１）。Ｓ３０１においては、制御部３１は、ユーザデータベースＤＢ１のうち、生成要求に含まれるユーザＩＤに対応するレコードのペナルティ情報を参照する。制御部３１は、ペナルティ情報の発生中フラグがオフであれば、新たな対戦部屋を生成すると判定し、ペナルティ情報の発生中フラグがオンであれば、新たな対戦部屋を生成しないと判定する。

新たな対戦部屋を生成すると判定されない場合（Ｓ３０１；Ｎ）、制御部３１は、ゲーム端末１０に対し、新たな対戦部屋を生成しないことを示す通知を送信する（Ｓ３０３）。この場合、Ｓ３０５の処理は実行されず、対戦部屋は生成されない。

ゲーム端末１０においては、通知を受信すると、制御部１１は、対戦部屋が生成されなかったことを示すダイアログＤ２５を対戦部屋検索画像Ｇ２に表示させ（Ｓ１０３）、本処理は終了する。なお、ダイアログＤ２５を表示させるためのデータは、予め記憶部１２に記憶されているものとする。

一方、Ｓ３０１において、新たな対戦部屋を生成すると判定された場合（Ｓ３０１；Ｙ）、制御部３１は、受信した生成要求に基づいて対戦部屋を生成し（Ｓ３０５）、ゲーム端末１０に対し、対戦部屋の生成が完了したことを示す完了通知を送信する（Ｓ３０７）。Ｓ３０５においては、制御部３１は、所定のＩＤ生成ルールに基づいて対戦部屋ＩＤを生成する。また、制御部３１は、対戦部屋データベースＤＢ２に新たなレコードを生成し、生成要求に含まれるユーザＩＤなどの情報を生成ユーザ情報と入室ユーザ情報として格納する。なお、Ｓ３０７における完了通知は、所定のデータ形式で行われるようにすればよく、例えば、Ｓ３０５で生成した対戦部屋ＩＤが完了通知に含まれるものとする。

ゲーム端末１０においては、完了通知を受信すると、制御部１１は、他のゲーム端末１０に対し、対戦ＩＤ等の部屋情報を送信する（Ｓ１０５）。Ｓ１０５においては、制御部１１は、少なくとも１つの無線通信規格に則った無線通信に基づいて、部屋情報を他のゲーム端末１０に送信する。他のゲーム端末１０は、少なくとも１つの無線通信規格に則った無線通信に基づいて、部屋情報を取得すると、対戦部屋検索画像Ｇ２に対戦部屋が表示され、入室ボタンＢ２３が選択された場合にゲームサーバ３０に対して入室要求を送信する。なお、入室要求は、対戦部屋を生成したゲーム端末１０経由でゲームサーバ３０に送信されてもよい。

ゲームサーバ３０においては、制御部３１は、ゲーム端末１０から入室要求を受信したか否かを判定する（Ｓ３０９）。入室要求を受信したと判定された場合（Ｓ３０９；Ｙ）、制御部３１は、入室要求をしたユーザを対戦部屋に入室させ（Ｓ３１１）、ゲーム端末１０に対し、入室が完了したことを示す完了通知を送信する（Ｓ３１３）。Ｓ３１１においては、制御部３１は、対戦部屋データベースＤＢ２のうち、入室要求に含まれる対戦部屋ＩＤに対応するレコードの入室ユーザ情報に、入室要求に含まれる情報を格納する。なお、Ｓ３１３における完了通知は、所定のデータ形式で行われるようにすればよく、例えば、対戦部屋に入室したユーザの入室ユーザ情報を含む。

ゲーム端末１０においては、完了通知を受信すると、制御部１１は、対戦部屋データＤＴ１を更新する（Ｓ１０７）。Ｓ１０７においては、制御部１１は、完了通知に含まれる入室ユーザ情報を対戦部屋データＤＴ１に格納する。これにより、ゲーム端末１０は、ユーザが生成した対戦部屋に他のユーザが入室したことを特定することができる。

図２１に移り、制御部１１は、ローカルリーグを開始するための開始操作が操作部１４から行われた場合に、ゲームサーバ３０に対し、ローカルリーグを開始することを示す開始通知を送信する（Ｓ１０９）。なお、Ｓ１０９における開始通知は、所定のデータ形式で行われるようにすればよく、例えば、ローカルリーグを開始する対戦部屋の対戦部屋ＩＤを含む。

ゲームサーバ３０においては、制御部３１は、開始通知を受信したか否かを判定する（Ｓ３１５）。開始通知を受信したと判定されない場合（Ｓ３１５；Ｎ）、Ｓ３０９に戻る。この場合、対戦部屋に他のユーザが入室するのが待ち受けられることになる。なお、この状態で、対戦部屋に入室したユーザが退室したとしても、後述するＳ３１９〜Ｓ３２５の処理が実行されないため、ペナルティは発生しない。

Ｓ１０９において開始操作が行われると、ゲーム端末１０では、入室ユーザ情報に入室した複数のユーザで総当たり戦となるように対戦組み合わせが決定され、他のゲーム端末１０との間でマッチング処理が実行される。ゲーム端末１０と他のゲーム端末１０との間で確立した無線通信をしながら、実行中のゲームの状況を示すデータやユーザの操作内容を送受信することによって、ゲームを実行する。この間、ゲーム端末１０からゲームサーバ３０に対し、最新の試合状況や対戦結果を示すゲームデータが送信されるようにしてもよい。

制御部１１は、操作部１４の検出信号に基づいて、ユーザが退室ボタンＢ４００を選択したか否かを判定する（Ｓ１１１）。ユーザが退室ボタンＢ４００を選択した場合（Ｓ１１１；Ｙ）、制御部１１は、ゲームサーバ３０に対し、対戦部屋に退室するための退室要求を送信する（Ｓ１１３）。なお、他のゲーム端末１０においても、退室ボタンＢ４００が選択された場合に、退室要求がゲームサーバ３０に対して送信される。

ゲームサーバ３０においては、制御部３１は、退室要求を受信したか否かを判定する（Ｓ３１７）。退室要求を受信したと判定されない場合（Ｓ３１７；Ｎ）、後述するＳ３２７の処理に移行する。

一方、退室要求を受信したと判定された場合（Ｓ３１７；Ｙ）、制御部３１は、退室要求をしたユーザを対戦部屋から退室させ（Ｓ３１９）、ペナルティ情報が示す回数を増加させる（Ｓ３２１）。Ｓ３１９においては、制御部３１は、対戦部屋データベースＤＢ２のうち、退室要求に含まれる対戦部屋ＩＤに対応するレコードの入室ユーザ情報から、入室要求に含まれるユーザＩＤに対応する情報を削除する。また、Ｓ３２１においては、制御部３１は、ユーザデータベースＤＢ１のうち、退室要求に含まれる対戦部屋ＩＤに対応するレコードのペナルティ情報が示す回数を１増加させる。

制御部３１は、ユーザデータベースＤＢ１のペナルティ情報に基づいて、ペナルティを発生させるか否かを判定する（Ｓ３２３）。Ｓ３２３においては、制御部３１は、ペナルティ情報が示す回数が閾値以上になったか否かを判定する。制御部３１は、回数が閾値以上になった場合にはペナルティを発生させると判定し、回数が閾値未満である場合にはペナルティを発生させると判定しない。

ペナルティを発生させると判定された場合（Ｓ３２３；Ｙ）、制御部３１は、対戦部屋を生成したユーザのペナルティ情報を更新する（Ｓ３２５）。Ｓ３２５においては、制御部３１は、対戦部屋データベースＤＢ２のうち、退室要求に含まれる対戦部屋ＩＤに対応するレコードの生成ユーザ情報を参照する。制御部３１は、ユーザデータベースＤＢ１のうち、当該生成ユーザ情報に含まれるユーザＩＤに対応するレコードのペナルティ情報の日時に現在日時を格納し、発生フラグをオンにする。なお、ゲームサーバ３０は、ユーザデータベースＤＢ１のペナルティ情報を定期的に参照し、ペナルティ情報の日時から一定期間が経過したレコードについては、発生フラグをオフにして回数をリセットする。

ゲーム端末１０においては、制御部１１は、対戦部屋データＤＴ１に基づいて、ローカルリーグにおける全試合が終了したか否かを判定する（Ｓ１１５）。Ｓ１１５においては、制御部１１は、対戦部屋データＤＴ１に格納されたゲームデータに基づいて、対戦組み合わせが決定された全試合が終了したか否かを判定する。全試合が終了したと判定されない場合（Ｓ１１５；Ｎ）、Ｓ１１１の処理に戻り、次の試合のマッチング処理が実行されてローカルリーグの残りの試合が進行する。

一方、全試合が終了したと判定された場合（Ｓ１１５；Ｙ）、制御部１１は、対戦部屋データＤＴ１に基づいて、表彰式画像Ｇ７を表示させ（Ｓ１１７）、ゲームサーバ３０に対し、表彰式画像Ｇ７が表示されたことを示す終了通知を送信する（Ｓ１１９）。なお、Ｓ１１９における終了通知は、所定のデータ形式で行われるようにすればよく、例えば、ローカルリーグが終了した対戦部屋の対戦部屋ＩＤを含む。

ゲームサーバ３０においては、終了通知を受信すると、制御部３１は、対戦部屋のユーザに報酬を付与し（Ｓ３２７）、本処理は終了する。Ｓ３２７においては、制御部３１は、対戦部屋データベースＤＢ２の入室ユーザ情報を参照して対戦部屋に入室したユーザのユーザＩＤを特定し、当該ユーザＩＤに新たにゲームアイテムを関連付けたり、当該ユーザＩＤに関連付けられたゲーム内通貨を増加させたりする。なお、報酬は、ユーザがゲーム内のお知らせ欄から所定の受け取り操作をすることで付与されるようにしてもよい。

なお、ゲームサーバ３０は、対戦部屋に入室した全てのゲーム端末１０から終了通知を受信しなければ、ローカルリーグが終了したとみなさないようにしてもよい。この場合、誰か１人でも表彰式画像Ｇ７を見終わっていないユーザがいる場合には、報酬が付与されないことになる。また、誰か１人でも表彰式画像Ｇ７を見終わっていないユーザがいる場合には、誰か退室した場合には途中退室とみなすようにしてもよい。

以上説明したゲームシステムＳによれば、ゲームの実行状況が所定の条件を満たさない場合、新たな対戦部屋を生成しないと判定することで、同じユーザによる新たな対戦部屋の生成を防止することができる。したがって、対戦部屋の乱立によるゲームデータの消費量の増加を防止することができる。

また、ゲームが所定の実行状況になる前に、少なくとも１人のユーザが対戦部屋から退室した場合に、新たな対戦部屋を生成しないと判定することで、当該対戦部屋を生成したユーザによる新たな対戦部屋の生成を防止することができる。

また、ユーザの要求により新たな対戦部屋が生成されない状態が所定の期間継続した場合、新たな対戦部屋を生成すると判定することで、いつまでも新たな対戦部屋を生成できないといったことを防止することができる。例えば、ユーザが意図しない理由で新たな対戦部屋を生成することができなくなってしまった場合に、不当に重いペナルティが課されるといったことを防止できる。

また、ゲームの実行が開始しなかった場合に、新たな対戦部屋を生成すると判定することで、例えば、ゲームを開始できなかった正当な理由がある場合に不当に重いペナルティが課されることを防止することができる。

また、ゲームの実行状況が所定の条件を満たした場合に、新たな対戦部屋を生成できるだけでなく報酬が付与されるので、ゲームの実行状況が所定の条件を満たすまでプレイさせる動機付けを与えることができる。

また、同じユーザにより生成された複数の対戦部屋のうち所定数以上の対戦部屋のゲームの実行状況が所定の条件を満たさない場合、新たな対戦部屋を生成しないと判定することで、ペナルティが不当に重くなってしまうことを防止することができる。

また、ゲームの実行状況をユーザに確認させることができる。したがって、新たな対戦部屋を生成しないと判定される状況であるか否かをユーザに確認させることができる。

また、各ユーザがゲームでの成績を見るまでゲームをプレイさせる動機付けを与えることができる。

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

（１）例えば、実施形態では、表彰式画像Ｇ７が表示される前に途中退室したユーザがいる場合にペナルティが発生する場合を説明したが、ペナルティが発生する所定の条件は実施形態で説明した例に限られない。例えば、所定の条件は、ゲームが所定の実行状況になることなく、対戦部屋が生成された場合に設定される所定の期限が経過することである。

所定の期限とは、例えば、対戦部屋が生成された時点から、当該時点の所定時間後まで、の期間である。所定時間は、予め定められた時間であればよく、例えば、数時間程度であってもよいし、数日又は数週間程度であってもよい。

例えば、変形例（１）では、対戦部屋データベースＤＢ２に、対戦部屋が生成された生成日時が格納される。生成部３０１は、対戦部屋を生成すると、生成した対戦部屋の生成日時を対戦部屋データベースＤＢ２に格納する。生成日時は、対戦部屋の生成が完了した場合の日時であってもよいし、当該日時の所定時間前後した日時であってもよいし、生成要求の受信日時であってもよい。

変形例（１）の第１判定部３０４は、ゲームが所定の実行状況になっていない場合に、対戦部屋の生成日時と現在日時との時間間隔が閾値以上であるか否かを判定する。第１判定部３０４は、時間間隔が閾値以上であると判定した場合に所定の条件を満たすと判定し、時間間隔が閾値以上であると判定した場合に所定の条件を満たさないと判定する。第２判定部は、第１判定部３０４により時間間隔が閾値未満であると判定された場合に、新たな対戦部屋を生成すると判定し、第１判定部３０４により時間間隔が閾値以上であると判定された場合に、新たな対戦部屋を生成しないと判定する。

変形例（１）によれば、ゲームが所定の実行状況になることなく所定の期限が経過した場合に、新たな対戦部屋を生成しないと判定することで、いつまでもゲームを進めない対戦部屋が長時間残ってしまうことを防止できるので、ゲームシステムのデータ消費量を軽減することができる。

（２）また例えば、ユーザが他のユーザと対戦するために対戦部屋が生成される場合を説明したが、特に部屋の形式でなくてもよい。例えば、ユーザグループが生成されて、他のユーザとのプレイを希望するユーザがユーザグループに所属してもよい。

ユーザグループとは、例えば、複数のユーザをメンバとして含むグループである。例えば、同じユーザグループに所属している複数のユーザは、ゲームの優劣（順位又は勝敗）を競い合う複数のユーザとなる。例えば、ユーザグループは、他のユーザと対戦するゲームをプレイすることを希望するユーザ、又は、他のユーザと協力して目標の達成を目指すゲームをプレイすることを希望するユーザが集うべきものであってもよい。

別の言い方をすれば、ユーザグループは、ゲームへの参加を宣言するためのものであってもよい。例えば、ユーザグループは、ゲームの中の世界に存在する物体を示すものである。また例えば、ユーザグループは、ゲーム内に設定された部屋・ロビーと呼ばれるものであってもよいし、仮想世界の中に設定された所定の場所であってもよいし、フレンドやギルドといった他の名称で呼ばれるものであってもよい。また例えば、ユーザグループは、データベース上のレコードであってもよいし、メモリ上のハッシュ構造を使った配列であってもよい。

対戦部屋は、ユーザグループの一例であり、実施形態において対戦部屋と記載した箇所は、ユーザグループと読み替えることができる。このため、生成部３０１は、ユーザの要求に基づいてユーザグループを生成する。第１判定部３０４は、ユーザグループに関連付けられたゲームの実行状況が所定の条件を満たすか否かを判定する。第２判定部３０５は、第１判定部３０５の判定結果に基づいて、ユーザの要求により新たなユーザグループを生成するか否かを判定する。これらの処理の詳細は実施形態で説明した通りである。

変形例（２）によれば、ゲームの実行状況が所定の条件を満たさない場合、新たなユーザグループを生成しないと判定することで、同じユーザによる新たな対戦部屋の生成を防止することができる。したがって、ユーザグループの乱立によるゲームデータの消費量の増加を防止することができる。

（３）また例えば、実施形態では、ローカルリーグを例に挙げて説明したが、エキシビションに実施形態と同様の処理を適用してもよいし、オンライン対戦に実施形態と同様の処理を適用してもよい。

また例えば、実施形態では、何れかのユーザが対戦部屋から退室した場合にペナルティが発生する場合を一例として説明したが、ペナルティが発生する条件は、予め定められた条件であればよく、例えば、対戦部屋を生成したユーザが退室することが条件となってもよいし、対戦部屋を生成したユーザ以外のユーザが退室し、対戦部屋内のユーザ数が所定人数未満になることが条件となってもよい。他にも例えば、所定人数以上のユーザが退室することが条件となってもよい。

また例えば、実施形態では、ゲームサーバ３０において対戦部屋の管理に関する主な処理が実行され、ゲームサーバ３０が本発明に係るゲーム制御装置に相当する場合を説明したが、ゲームサーバ３０において実現される各機能は、ゲーム端末１０において実現されてもよい。例えば、生成部３０１、入室部３０２、退室部３０３、第１判定部３０４、第２判定部３０５、第３判定部３０６、第４判定部３０７、報酬付与部３０８、及び表示制御部３０９がゲーム端末１０において実現されてもよい。この場合、これら各機能は、制御部１１を主として実現される。

例えば、生成部３０１がゲーム端末１０で実現される場合、生成部３０１は、対戦部屋ＩＤを生成し、ユーザＩＤと対戦部屋ＩＤを含むデータをゲームサーバ３０に送信することによって対戦部屋を生成してもよい。また例えば、入室部３０２がゲーム端末１０で実現される場合、他のゲーム端末１０からユーザＩＤ等の情報を取得し、入室ユーザ情報を更新することによって他のユーザを入室させてもよい。また例えば、退室部３０３がゲーム端末１０で実現される場合、他のゲーム端末１０からユーザＩＤ等の情報を取得し、入室ユーザ情報を更新することによって他のユーザを退室させてもよい。また例えば、第１判定部３０４がゲーム端末１０で実現される場合、対戦部屋データＤＴ１に格納されたゲームデータを参照し、所定の条件を満たすか否かを判定してもよい。また例えば、第２判定部３０５がゲーム端末１０で実現される場合、新たな対戦部屋を生成するか否かの判定結果をゲームサーバ３０に送信してもよい。

また例えば、ゲーム端末１０とゲームサーバ３０とで各機能が分担されてもよい。この場合、ゲーム端末１０とゲームサーバ３０との間で処理結果を送受信すればよい。例えば、ゲーム端末１０において生成部３０１が実現され、ゲームサーバ３０において第１判定部３０４と第２判定部３０５が実現されてもよい。また例えば、ゲーム端末１０において生成部３０１と第１判定部３０４が実現され、ゲームサーバ３０において第２判定部３０５が実現されてもよい。

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

１）本発明の一態様に係るゲームシステム（Ｓ）は、ユーザの要求に基づいて対戦部屋を生成する生成手段（３０１）と、前記対戦部屋に関連付けられたゲームの実行状況が所定の条件を満たすか否かを判定する第１判定手段（３０４）と、前記第１判定手段（３０４）の判定結果に基づいて、前記ユーザの要求により新たな対戦部屋を生成するか否かを判定する第２判定手段（３０５）と、を含む。

１０）本発明の一態様に係るゲームシステム（Ｓ）は、ユーザの要求に基づいてユーザグループを生成する生成手段（３０１）と、前記ユーザグループに関連付けられたゲームの実行状況が所定の条件を満たすか否かを判定する第１判定手段（３０４）と、前記第１判定手段（３０４）の判定結果に基づいて、前記ユーザの要求により新たなユーザグループを生成するか否かを判定する第２判定手段（３０５）と、を含む。

１１）本発明の一態様に係るゲーム制御装置（１０，３０）は、ユーザの要求に基づいて生成された対戦部屋に関連付けられたゲームの実行状況が所定の条件を満たすか否かを判定する第１判定手段（３０４）と、前記第１判定手段（３０４）の判定結果に基づいて、前記ユーザの要求により新たな対戦部屋を生成するか否かを判定する第２判定手段（３０５）と、を含む。

１２）本発明の一態様に係るゲーム制御装置（１０，３０）は、ユーザの要求に基づいて生成されたユーザグループに関連付けられたゲームの実行状況が所定の条件を満たすか否かを判定する第１判定手段（３０４）と、前記第１判定手段（３０４）の判定結果に基づいて、前記ユーザの要求により新たなユーザグループを生成するか否かを判定する第２判定手段（３０５）と、を含む。

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

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

１）又は１０）〜１４）に係る発明によれば、ゲームの実行状況が所定の条件を満たさない場合、新たな対戦部屋を生成しないと判定することで、同じユーザによる新たな対戦部屋の生成を防止することができる。したがって、対戦部屋の乱立によるゲームデータの消費量の増加を防止することができる。

２）本発明の一態様では、前記ゲームシステム（Ｓ）は、前記対戦部屋に関連付けられたユーザの関連付けを解除する解除手段（３０３）を更に含み、前記所定の条件は、前記ゲームが所定の実行状況になる前に、少なくとも１人のユーザと前記対戦部屋との関連付けが解除されることである。２）の態様によれば、ゲームが所定の実行状況になる前に、少なくとも１人のユーザと対戦部屋との関連付けが解除された場合に、新たな対戦部屋を生成しないと判定することで、当該対戦部屋を生成したユーザによる新たな対戦部屋の生成を防止することができる。

３）本発明の一態様では、前記ゲームシステム（Ｓ）は、前記ユーザの要求により前記新たな対戦部屋が生成されない状態が所定の期間継続したか否かを判定する第３判定手段（３０６）を更に含み、前記第２判定手段（３０５）は、前記第１判定手段（３０４）の判定結果と、前記第３判定手段（３０６）の判定結果と、に基づいて、前記ユーザの要求により前記新たな対戦部屋を生成するか否かを決定する。３）の態様によれば、ユーザの要求により新たな対戦部屋が生成されない状態が所定の期間継続した場合、新たな対戦部屋を生成すると判定することで、いつまでも新たな対戦部屋を生成できないといったことを防止することができる。例えば、ユーザが意図しない理由で新たな対戦部屋を生成することができなくなってしまった場合に、不当に重いペナルティが課されるといったことを防止できる。

４）本発明の一態様では、前記ゲームの実行を開始したか否かを判定する第４判定手段（３０７）を更に含み、前記第２判定手段（３０５）は、前記第１判定手段（３０４）の判定結果と、前記第４判定手段（３０７）の判定結果と、に基づいて、前記ユーザの要求により前記新たな対戦部屋を生成するか否かを決定する。４）の態様によれば、ゲームの実行が開始しなかった場合に、新たな対戦部屋を生成すると判定することで、例えば、ゲームを開始できなかった正当な理由がある場合に不当に重いペナルティが課されることを防止することができる。

５）本発明の一態様では、前記ゲームシステム（Ｓ）は、前記第１判定手段（３０４）の判定結果に基づいて、前記対戦部屋に関連付けられたユーザに報酬を付与する報酬付与手段（３０８）、を更に含む。５）の態様によれば、ゲームの実行状況が所定の条件を満たした場合に、新たな対戦部屋を生成できるだけでなく報酬が付与されるので、ゲームの実行状況が所定の条件を満たすまでプレイさせる動機付けを与えることができる。

６）本発明の一態様では、前記生成手段（３０１）は、前記ユーザの要求が行われるたびに前記対戦部屋を生成し、前記第２判定手段（３０５）は、前記ユーザの要求により生成された複数の前記対戦部屋のうちの所定数以上の対戦部屋についての前記第１判定手段（３０４）の判定結果に基づいて、前記ユーザの要求により前記新たな対戦部屋を生成するか否かを判定する。６）の態様によれば、同じユーザにより生成された複数の対戦部屋のうち所定数以上の対戦部屋のゲームの実行状況が所定の条件を満たさない場合、新たな対戦部屋を生成しないと判定することで、ペナルティが不当に重くなってしまうことを防止することができる。

７）本発明の一態様では、前記ゲームシステム（Ｓ）は、前記ゲームの実行状況を識別するための情報を、前記対戦部屋に関連付けられたユーザに対応する表示手段（１５）と、前記対戦部屋を生成したユーザに対応する表示手段（１５）と、の少なくとも一方に表示させる表示制御手段（３０９）、を更に含む。７）の態様によれば、ゲームの実行状況をユーザに確認させることができる。したがって、新たな対戦部屋を生成しないと判定される状況であるか否かをユーザに確認させることができる。

８）本発明の一態様では、前記ゲームシステム（Ｓ）は、前記ゲームの実行結果に基づいて、前記対戦部屋に関連付けられたユーザの成績を、当該ユーザに対応する表示手段（１５）に表示させる表示制御手段（３０９）を更に含み、前記所定の条件は、前記表示制御手段（３０９）により成績が表示されることである。８）の態様によれば、各ユーザがゲームでの成績を見るまでゲームをプレイさせる動機付けを与えることができる。

９）本発明の一態様では、前記所定の条件は、前記ゲームが所定の実行状況になることなく、前記対戦部屋が生成された場合に設定される所定の期限が経過することである。９）の態様によれば、ゲームが所定の実行状況になることなく所定の期限が経過した場合に、新たな対戦部屋を生成しないと判定することで、いつまでもゲームを進めない対戦部屋が長時間残ってしまうことを防止できるので、ゲームシステムのデータ消費量を軽減することができる。

Ｓ ゲームシステム、Ｎ ネットワーク、ＰＮ プライベートネットワーク、１０，１０Ａ，１０Ｂ，１０Ｃ ゲーム端末、３０ ゲームサーバ、５０ ドメインネームサーバ、１１，３１，５１ 制御部、１２，３２，５２ 記憶部、１３，３３，５３ 通信部、１４ 操作部、１５ 表示部、Ｇ１ メニュー画像、Ｇ２ 対戦部屋検索画像、Ｇ３ 対戦部屋画像、Ｇ４ 対戦組み合わせ画像、Ｇ５ マッチング画像、Ｇ６ ゲーム画像、Ｇ７ 表彰式画像、１００ データ記憶部、１０１ 対戦実行部、３００ データ記憶部、３０１ 生成部、３０２ 入室部、３０３ 退室部、３０８ 報酬付与部、３０９ 表示制御部、Ａ２０ 表示領域、Ａ３０ 表示領域、Ａ４０ 表示領域、Ｂ１０ イベントボタン、Ｂ１１ オンライン対戦ボタン、Ｂ１２ シーズンマッチボタン、Ｂ１４ ローカル対戦ボタン、Ｂ２１ 新規作成ボタン、Ｂ２２ リロードボタン、Ｂ２３ 入室ボタン、Ｄ１５ ダイアログ、Ｄ２３ ダイアログ、Ｄ２４ ダイアログ、Ｄ２５ ダイアログ、ＤＢ１ ユーザデータベース、ＤＢ２ 対戦部屋データベース、ＤＴ１ 対戦部屋データ、Ａ３００ 表示領域、Ａ３０２ 表示領域、Ａ３０３ 表示領域、Ｂ１５０ エキシビションボタン、Ｂ１５１ 戦績ボタン、Ｂ１５２ 試合履歴ボタン、Ｂ１５３ ローカルリーグボタン、Ｂ１５４ 参加履歴ボタン、Ｂ１５５ ボタン、Ｂ２００ 入室ボタン、Ｂ２３１ キャンセルボタン、Ｂ２３２ ボタン、Ｂ２４０ ボタン、Ｂ４００ 退室ボタン、Ｆ２３０ 入力フォーム。

Claims (1)

1. ユーザの要求に基づいて対戦部屋を生成する生成手段と、
   前記対戦部屋に関連付けられたゲームの実行状況が所定の条件を満たすか否かを判定する第１判定手段と、
   前記第１判定手段の判定結果に基づいて、前記ユーザの要求により新たな対戦部屋を生成するか否かを判定する第２判定手段と、
   を含むゲームシステム。

Images