JP6901659B2

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

Info

Publication number: JP6901659B2
Application number: JP2017201080A
Authority: JP
Inventors: 実米山
Original assignee: Konami Digital Entertainment Co Ltd
Current assignee: Konami Digital Entertainment Co Ltd
Priority date: 2017-10-17
Filing date: 2017-10-17
Publication date: 2021-07-14
Anticipated expiration: 2037-10-17
Also published as: JP2019072245A

Description

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

従来、対戦部屋やロビーなどのグループを生成し、複数のユーザにゲームをプレイさせるゲームシステムが知られている。例えば、特許文献１には、ユーザが生成した対戦部屋に他のユーザを入室させ、対戦部屋に入室した複数のユーザがゲームをプレイすることが記載されている。

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

しかしながら、特許文献１の技術では、ユーザが生成した対戦部屋に意図しない他のユーザが入室してしまうことがあった。この点、限られたユーザしか入室できないように対戦部屋に制限をかけることも考えられるが、この場合、他のユーザは、対戦部屋の中で実行されるゲームに何ら関与できないので不満に感じる可能性がある。

本発明は上記課題に鑑みてなされたものであって、その目的は、対戦部屋の中で実行されるゲームに他のユーザが適切に関与することが可能なゲームシステム、ゲーム制御装置、及びプログラムを提供することである。

上記課題を解決するために、本発明の一態様に係るゲームシステムは、複数のユーザがゲームをプレイするために用いるグループの生成要求を受け付ける受付手段と、前記生成要求が受け付けられた場合に、前記グループを識別可能な複数の識別情報を生成する識別情報生成手段と、前記複数の識別情報をデータベースに格納することによって、前記グループを生成するグループ生成手段と、を含み、前記複数の識別情報には、それぞれ互いに異なる機能が対応付けられている。

本発明の一態様に係るゲーム制御装置は、複数のユーザがゲームをプレイするために用いるグループの生成要求を受け付ける受付手段と、前記生成要求が受け付けられた場合に、前記グループを識別可能な複数の識別情報を生成する識別情報生成手段と、前記複数の識別情報をデータベースに格納することによって、前記グループを生成するグループ生成手段と、を含み、前記複数の識別情報には、それぞれ互いに異なる機能が対応付けられている。

ゲームシステムの全体構成を示す図である。対戦モード選択画像の一例を示す図である。対戦部屋モード画像の一例を示す図である。対戦部屋生成ボタンが選択された場合の対戦部屋モード画像の一例を示す図である。対戦部屋画像の一例を示す図である。対戦部屋モード画像から部屋ＩＤが入力される様子を示す図である。第１ユーザと第２ユーザがテーブルにエントリーする様子を示す図である。第１ユーザと第２ユーザとが対戦する様子を示す図である。対戦部屋モード画像から観戦ＩＤが入力される様子を示す図である。観戦画像の一例を示す図である。観戦ユーザが対戦を観戦している様子を示す図である。ゲームシステムで実現される機能のうち、本発明に関連する機能を示す機能ブロック図である。対戦部屋データのデータ格納例を示す図である。ゲームシステムにおいて実行される処理の一例を示すフロー図である。ゲームシステムにおいて実行される処理の一例を示すフロー図である。第２実施形態のゲームシステムの全体構成を示す図である。大会会場内でユーザ同士が対戦する様子を示す図である。ゲーム大会の１日目における進行手順を示す図である。ゲーム大会の１日目における進行手順を示す図である。ゲーム大会の１日目における進行手順を示す図である。ゲーム大会の１日目における進行手順を示す図である。管理ツール画像の一例を示す図である。管理ツールからレジェンドカードが登録される様子を示す図である。管理ツールから対戦結果が登録される様子を示す図である。第２実施形態の機能ブロック図である。オブジェクトデータの一例を示す図である。

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

図１は、ゲームシステムの全体構成を示す図である。図１に示すように、本実施形態に係るゲームシステムＳは、第１ゲーム端末１０Ａ、第２ゲーム端末１０Ｂ、第３ゲーム端末１０Ｃ、及びサーバ３０を含む。第１ゲーム端末１０Ａ、第２ゲーム端末１０Ｂ、第３ゲーム端末１０Ｃ、及びサーバ３０の各々は、インターネットなどのネットワークＮに接続される。このため、ゲーム端末１０とサーバ３０との間で相互にデータ通信が可能である。

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

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

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

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

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

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

［２．ゲームの概要］
ゲームシステムＳでは、複数のユーザがプレイするゲームが実行される。複数のユーザがプレイするゲームとは、例えば、複数のユーザが参加するゲーム、複数のユーザが互いに対戦するゲーム、複数のユーザが協力して対戦相手（コンピュータ又は他のユーザ）と対戦するゲーム、複数のユーザの各々がゲームをプレイして他のユーザとスコアなどを競うゲームなどである。ゲームシステムＳでは、複数のユーザがゲームをプレイするために用いるグループが生成される。

グループとは、例えば、複数のユーザをメンバ（参加者）として含むグループである。例えば、同じグループに所属する複数のユーザは、ゲームの優劣（順位又は勝敗）を競い合う複数のユーザといえる。また例えば、グループは、他のユーザと対戦するゲームをプレイすることを希望するユーザ、又は、他のユーザと協力して目標の達成を目指すゲームをプレイすることを希望するユーザが集うべきものであってもよい。別の言い方をすれば、グループは、例えば、ゲームへの参加を宣言するためのものであってもよい。例えば、グループは、ゲームの中の世界に存在する物体を示すものであってもよい。また例えば、グループは、ゲーム内に設定された部屋・ロビーと呼ばれるものであってもよいし、仮想世界の中に設定された所定の場所であってもよいし、フレンドやギルドといった他の名前で呼ばれるものであってもよい。本実施形態では、グループに、複数のサブグループが設定されている場合を説明するが、特にサブグループがなくてもよい。

サブグループとは、例えば、グループ内に設定された別のグループである。例えば、サブグループは、グループよりも小さい単位であり、グループに所属するユーザの一部が所属するものである。例えば、グループが部屋やロビーであれば、その中に配置されたテーブルや椅子などである。また例えば、グループが仮想世界の中の場所であれば、その場所に配置されたテーブルや椅子などである。また例えば、グループがフレンドやギルドといったものであれば、その中に設定された小さな仲間グループのことである。

本実施形態では、ゲームの一例として、複数のユーザがゲームカードを使用して対戦するカードゲームを説明する。また、グループの一例として対戦部屋を説明し、サブグループの一例として対戦部屋内のテーブルを説明する。このため、本実施形態で対戦部屋と記載した箇所は、グループと読み替えることができ、テーブルと記載した箇所は、サブグループと読み替えることができる。例えば、ゲームシステムＳでは、複数の対戦モードが用意されており、ユーザがゲームプログラムを起動させると、プレイする対戦モードを選択するための対戦モード選択画面が表示部１５に表示される。

図２は、対戦モード選択画像の一例を示す図である。図２に示すように、対戦モード選択画像Ｇ１では、複数の対戦モードの中からプレイする対戦モードを選択可能となっている。例えば、ランク戦ボタンＢ１０は、一定期間内の戦績に基づいて複数のユーザがランキングを競うランク戦モードをプレイするための画像である。また例えば、フリー対戦ボタンＢ１１は、特にランキング等に影響せず、複数のユーザが自由に対戦するフリー対戦モードをプレイするための画像である。また例えば、フレンド対戦ボタンＢ１２は、互いに友人関係にある複数のユーザが対戦するフレンド対戦モードをプレイするための画像である。また例えば、対戦部屋ボタンＢ１３は、対戦部屋に入室した複数のユーザが対戦する対戦部屋モードをプレイするための画像である。

本実施形態では、主に、対戦部屋モードについて説明する。対戦部屋モードでは、ユーザは、自分が生成した対戦部屋に他のユーザを招待したり、他のユーザが生成した対戦部屋に入室したりすることによって、他のユーザと対戦することができる。ユーザが対戦部屋ボタンＢ１３を選択すると、対戦部屋モードをプレイするための対戦部屋モード画像がゲーム端末１０に表示される。

図３は、対戦部屋モード画像の一例を示す図である。図３に示すように、対戦部屋モード画像Ｇ２には、対戦部屋を生成するための対戦部屋生成ボタンＢ２０、メンバとして対戦部屋に入室するためのメンバ入室ボタンＢ２１、及び観戦ユーザとして対戦部屋に入室するための観戦ユーザ入室ボタンＢ２２が表示される。

以降、第１ゲーム端末１０Ａを操作する第１ユーザが対戦部屋を生成し、第２ゲーム端末１０Ｂを操作する第２ユーザがメンバとして当該対戦部屋に入室し、第３ゲーム端末１０Ｃを操作する第３ユーザが観戦ユーザとして当該対戦部屋に入室する場合を一例として説明する。第１ユーザが対戦部屋生成ボタンＢ２０を選択すると、対戦部屋を生成するためのダイアログが対戦部屋モード画像Ｇ２に表示される。

図４は、対戦部屋生成ボタンＢ２０が選択された場合の対戦部屋モード画像Ｇ２の一例を示す図である。図４に示すように、対戦部屋モード画像Ｇ２には、対戦部屋に関する各種設定をするためのダイアログＤ２３が表示される。例えば、対戦部屋の名前を入力するための入力フォームＦ２３０が、ダイアログＤ２３に表示される。また例えば、対戦部屋に入室可能なユーザの上限数を入力するための入力フォームＦ２３１が、ダイアログＤ２３に表示される。

また例えば、対戦部屋を観戦するための観戦機能を有効にするか無効にするかを入力するためのラジオボタンＢ２３２が、ダイアログＤ２３に表示される。また例えば、対戦部屋を生成する第１ユーザがメンバとして対戦に参加するか否かを入力するためのラジオボタンＢ２３３が、ダイアログＤ２３に表示される。なお、第１ユーザがキャンセルボタンＢ２３４を選択すると、対戦部屋が生成されることなくダイアログＤ２３が消去される。

第１ユーザが決定ボタンＢ２３５を選択すると、ダイアログＤ２３に対する入力内容に基づいて、新たな対戦部屋が生成される。例えば、入力フォームＦ２３０に入力された名前の対戦部屋が生成され、入力フォームＦ２３１に入力された人数が上限数として設定される。また例えば、ラジオボタンＢ２３２で観戦機能をオンにした場合には、対戦部屋内でのゲームの観戦ができるようになる。一方、ラジオボタンＢ２３２で観戦機能をオフにした場合には、対戦部屋内でのゲームの観戦ができないようになる。

また例えば、ラジオボタンＢ２３３でメンバとして参加することが選択された場合には、第１ユーザがメンバとして対戦部屋に入室して他のユーザ（例えば、第２ユーザ）と対戦可能となる。一方、ラジオボタンＢ２３３でメンバとして参加しないことが選択された場合には、第１ユーザはメンバとして対戦部屋に入室できず、他のユーザと対戦できないようになる。なお、第１ユーザは、生成した対戦部屋を管理するオーナユーザとしての権限を持ち、例えば、他のユーザを対戦部屋に招待したり、対戦部屋に関する設定変更をしたりすることが可能となる。

ここでは、第１ユーザが、ラジオボタンＢ２３２において観戦機能をオンにし、ラジオボタンＢ２３３においてメンバとして参加することを選択した場合を説明する。この場合、決定ボタンＢ２３５が選択されて対戦部屋が生成されると、第１ユーザは対戦部屋にメンバとして入室した状態となり、対戦部屋の様子を示す対戦部屋画像が表示部１５に表示される。

図５は、対戦部屋画像の一例を示す図である。図５に示すように、対戦部屋画像Ｇ３は、例えば、入室中の対戦部屋の名前を表示するための表示領域Ａ３０を含む。また例えば、対戦部屋画像Ｇ３は、メンバとして入室中のユーザ数、入室可能なユーザの上限数、及び観戦ユーザとして入室中のユーザ数を表示するための表示領域Ａ３１を含む。

本実施形態では、決定ボタンＢ２３５が選択された場合に、対戦部屋を識別するためのＩＤが２つ生成される。例えば、これら２つのＩＤのうちの一方は、対戦部屋にメンバとして入室するための部屋ＩＤであり、他方は、対戦部屋に観戦ユーザとして入室するための観戦ＩＤである。例えば、表示領域Ａ３２には部屋ＩＤが表示され、表示領域Ａ３３には観戦ＩＤが表示される。

また例えば、対戦部屋画像Ｇ３には、メンバとして入室中のユーザのリストを表示するためのメンバボタンＢ３４、対戦部屋内での戦績を表示するための戦績ボタンＢ３５、メンバ又は観戦ユーザが残したコメントを表示するためのコメントボタンＢ３６、対戦部屋から退室するための退室ボタンＢ３７、及び対戦部屋内に設けられたテーブルを選択するためのテーブル選択ボタンＢ３８Ａ〜Ｂ３８Ｃが表示される。なお、本実施形態では、ユーザは、退室ボタンＢ３７を選択して対戦部屋から退室しなくても、他の対戦モードをプレイすることができ、対戦以外のゲームパート（例えば、ユーザが１人で遊ぶクエストなど）をプレイすることもできるようになっている。

以降では、テーブル選択ボタンＢ３８Ａ〜Ｂ３８Ｃを特に区別する必要のないときは、単にテーブル選択ボタンＢ３８と記載する。また、図５では、３つのテーブルを選択可能となっているが、対戦部屋内に設定されるテーブルの数は、任意の数であってよく、例えば、１つ、２つ、又は４つ以上であってもよい。

図５の対戦部屋画像Ｇ３は、対戦部屋が生成されたばかりの状態を示しており、第１ユーザ以外のユーザは、誰も入室していない状態となっている。第１ユーザは、表示領域Ａ３２に表示された部屋ＩＤを、メンバとして招待したい他のユーザ（ここでは、第２ユーザ）に通知し、表示領域Ａ３３に表示された観戦ＩＤを、観戦ユーザとして招待したい他のユーザ（ここでは、第３ユーザ）に通知し、他のユーザを対戦部屋に招待する。

なお、部屋ＩＤと観戦ＩＤの通知方法としては、公知の種々の通知媒体を利用可能であり、例えば、ゲーム内のメッセージ機能を利用してもよいし、電子メールやメッセージアプリを利用してもよいし、口頭で通知してもよい。また、第１ユーザが生成した対戦部屋は、対戦部屋を生成してから所定時間（例えば、２４時間又はメンバが全員退室するまで残るようにしてもよい。

第２ユーザは、第１ユーザの対戦部屋の部屋ＩＤを取得すると、当該部屋ＩＤに基づいて、第１ユーザの対戦部屋にメンバとして入室することができるようになる。例えば、第２ユーザは、第１ユーザから通知された部屋ＩＤを対戦部屋モード画像Ｇ２から入力することで、第１ユーザの対戦部屋にメンバとして入室することができる。

図６は、対戦部屋モード画像Ｇ２から部屋ＩＤが入力される様子を示す図である。例えば、対戦部屋モード画像Ｇ２が第２ゲーム端末１０Ｂに表示された状態で、第２ユーザがメンバ入室ボタンＢ２１を選択すると、図６に示すように、対戦部屋モード画像Ｇ２にダイアログＤ２４が表示される。例えば、部屋ＩＤを入力するための入力フォームＦ２４０が、ダイアログＤ２４に表示される。

例えば、第２ユーザが、第１ユーザの対戦部屋の部屋ＩＤを入力フォームＦ２４０に入力して決定ボタンＢ２４１を選択すると、第１ユーザが生成した対戦部屋にメンバとして入室することができる。この場合、第１ゲーム端末１０Ａに表示される対戦部屋画像Ｇ３と同じ対戦部屋画像Ｇ３が表示されるようにしてもよいし、第１ゲーム端末１０Ａに表示される対戦部屋画像Ｇ３とは異なる対戦部屋画像Ｇ３が表示されるようにしてもよい。例えば、第２ゲーム端末１０Ｂに表示される対戦部屋画像Ｇ３には、観戦ＩＤが表示されないようにしてもよい。

なお、第２ユーザが入力フォームＦ２４０から間違った部屋ＩＤを入力すると、所定のエラーメッセージが表示され、第１ユーザの対戦部屋に入室することができない。また、もし仮に第２ユーザが入力フォームＦ２４０に部屋ＩＤではなく観戦ＩＤを入力しても、対戦部屋に観戦ユーザとして入室することはできない。

第２ユーザが、第１ユーザの対戦部屋に入室すると、第１ユーザ又は当該対戦部屋に入室中の他のユーザとの対戦が可能な状態となる。ここでは、第１ユーザが既に入室済みの状態なので、第１ユーザと第２ユーザは、対戦部屋の中の同じテーブルにエントリーすることによって、対戦を開始することができる。

図７は、第１ユーザと第２ユーザがテーブルにエントリーする様子を示す図である。図７に示すように、誰もエントリーしていない第１テーブルのテーブル選択ボタンＢ３８Ａには、特にユーザの情報は表示されない。例えば、第１ユーザ（図７では「ＡＡＡ」という名前のユーザ）が、先にテーブル選択ボタンＢ３８Ａを選択して第１テーブルにエントリーすると、テーブル選択ボタンＢ３８Ａに第１ユーザの名前やアイコンが表示される。この状態で、第２ユーザがテーブル選択ボタンＢ３８Ａを選択すると、第１ユーザがエントリー済みの第１テーブルにエントリーすることができ、第１ユーザと第２ユーザとの対戦が開始される。

なお、図７では、第１テーブルが用いられる場合を説明したが、対戦部屋内の任意のテーブルが用いられるようにすればよく、第２テーブル又は第３テーブルが用いられてもよい。この場合、第１ユーザと第２ユーザは、テーブル選択ボタンＢ３８Ｂ，Ｂ３８Ｃを選択して第２テーブル又は第３テーブルにエントリーすることで対戦できる。また、各テーブルが２人用である場合を説明したが、テーブルは３人以上がエントリー可能であってもよい。

図８は、第１ユーザと第２ユーザとが対戦する様子を示す図である。図８に示すように、対戦部屋画像Ｇ３には、実行中のゲームの様子が表示される。本実施形態では、カードゲームが実行されるので、例えば、対戦部屋画像Ｇ３には、ユーザの手札の情報、ゲームカードが配置されるフィールド上の様子、及びユーザのライフポイントが表示される。

カードゲーム自体は、公知の種々のカードゲームを適用可能なので、ゲーム内容の詳細は省略するが、例えば、各ユーザは、自身のゲームカードを使用して対戦相手を攻撃し、対戦相手のライフポイントを０にした方が勝利する。対戦が終了すると、対戦部屋画像Ｇ３は図５の状態に戻る。なお、対戦が終了した場合に、各ユーザはテーブルから自動的に離脱してもよいし、テーブルにエントリーした状態で同じユーザと再戦できるようにしてもよい。なお、離脱とは、例えば、ユーザがテーブルにエントリーした状態からエントリーしていない状態になることである。例えば、ユーザがテーブルから離脱すると、他のテーブルにエントリーすることができる。

一方、第３ユーザは、第１ユーザの対戦部屋の観戦ＩＤを取得すると、当該観戦ＩＤに基づいて、第１ユーザの対戦部屋に観戦ユーザとして入室することができるようになる。例えば、第３ユーザは、第１ユーザから通知された観戦ＩＤを対戦部屋モード画像Ｇ２から入力することで、第１ユーザの対戦部屋に観戦ユーザとして入室することができる。

図９は、対戦部屋モード画像Ｇ２から観戦ＩＤが入力される様子を示す図である。例えば、対戦部屋モード画像Ｇ２が第３ゲーム端末１０Ｃに表示された状態で、第３ユーザが観戦ユーザ入室ボタンＢ２２を選択すると、図９に示すように、対戦部屋モード画像Ｇ２にダイアログＤ２５が表示される。例えば、観戦ＩＤを入力するための入力フォームＦ２５０が、ダイアログＤ２５に表示される。

例えば、第３ユーザが、第１ユーザの対戦部屋の観戦ＩＤを入力フォームＦ２５０に入力して決定ボタンＢ２５１を選択すると、第１ユーザが生成した対戦部屋に第３ユーザは観戦ユーザとして入室することができる。

なお、実施形態では、観戦ＩＤと部屋ＩＤをそれぞれ別のダイアログから入力する場合を説明するが、１つのダイアログから入力されたＩＤに応じた権限で対戦部屋に入室できるようにしてもよい。例えば、ある１つのダイアログから複数種類のＩＤを入力可能とし、当該ダイアログから入力されたＩＤに対応する機能が提供されるようにしてもよい。この場合、ダイアログには、複数種類のＩＤの各々に対応する入力フォームが含まれているようにしてもよいし、入力フォームが１つだけであり、当該１つの入力フォームから複数種類のＩＤを入力可能としてもよい。

また、第３ユーザが入力フォームＦ２５０から間違った観戦ＩＤを入力すると、所定のエラーメッセージが表示され、第１ユーザの対戦部屋に入室することができない。また、もし仮に第３ユーザが入力フォームＦ２５０に観戦ＩＤではなく部屋ＩＤを入力しても、対戦部屋にメンバとして入室することはできない。第３ユーザが対戦部屋に入室すると、対戦部屋を観戦するための観戦画像が第３ゲーム端末１０Ｃに表示される。

図１０は、観戦画像の一例を示す図である。図１０に示すように、観戦画像Ｇ４は、対戦部屋画像Ｇ３とは異なっている。例えば、観戦画像Ｇ４では、第３ユーザは対戦に参加することができず、第３ユーザが対戦部屋の中の対戦を観戦することができるようになっている。例えば、観戦画像Ｇ４には、対戦部屋に設けられたテーブルのうち、観戦するテーブルを選択するためのテーブル選択ボタンＢ４０Ａ〜Ｂ４０Ｃが表示される。なお、以降では、テーブル選択ボタンＢ４０Ａ〜Ｂ４０Ｃを特に区別する必要のないときは、単に、テーブル選択ボタンＢ４０と記載する。

例えば、テーブル選択ボタンＢ４０には、各テーブルの状況が表示されており、エントリー中のユーザに関する情報が表示される。また例えば、既に対戦が開始しているテーブルについては、テーブル選択ボタンＢ４０に、対戦の状況が表示されるようにしてもよい。例えば、対戦の状況としては、対戦中であるか否かを識別する情報や対戦の進行状況（例えば、現在のターン数やライフポイントなど）が表示されてもよい。第３ユーザは、テーブル選択ボタンＢ４０の中から、観戦したいテーブルを選択することになる。

図１１は、観戦ユーザが対戦を観戦している様子を示す図である。図１１に示すように、観戦画像Ｇ４には、第３ユーザが選択したテーブルで行われている対戦の様子が表示される。例えば、観戦画像Ｇ４は、図８の対戦部屋画像Ｇ３と同じであってもよいが、ここでは内容が異なるものとする。例えば、観戦画像Ｇ４には、両ユーザの手札が隠されていてもよいし、逆に両ユーザの手札が見える状態であってもよい。例えば、対戦が既に始まっている場合、観戦画像Ｇ４では、対戦の最初から現在に至るまでの進行が自動的に表示されるようにしてもよい。現在の状況まで到達した場合には、対戦をリアルタイムで観戦できるようになる。

上記のように、本実施形態のゲームシステムＳは、決定ボタンＢ２３５が選択された場合に、メンバとして入室するための部屋ＩＤと、観戦ユーザとして入室するための観戦ＩＤと、の２つのＩＤが生成され、ＩＤごとに機能を使い分けることによって、ユーザの満足度を高めるようになっている。以降、当該構成の詳細を説明する。

［３．ゲームシステムにおいて実現される機能］
図１２は、ゲームシステムＳで実現される機能のうち、本発明に関連する機能を示す機能ブロック図である。本実施形態では、対戦部屋に関する主な機能がサーバ３０において実現される場合を説明するが、後述する変形例のように、主な機能がゲーム端末１０において実現されてもよいし、各機能がゲーム端末１０とサーバ３０とで分担されてもよい。図１２に示すように、サーバ３０では、データ記憶部３００、対戦部屋生成部３０１、識別情報生成部３０２、及びゲーム実行部３０３が実現される。

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

図１３は、対戦部屋データＤＴ１のデータ格納例を示す図である。図１３に示すように、対戦部屋データＤＴ１は、対戦部屋に関するデータであり、例えば、対戦部屋の基本情報と、対戦部屋の現在の状況と、格納される。基本情報としては、例えば、部屋ＩＤ、観戦ＩＤ、対戦部屋の名前、入室可能なユーザの上限数、観戦機能の有無、対戦部屋を生成したオーナユーザのユーザＩＤ、及び当該オーナユーザがメンバとして参加できるか否かを示す情報が格納される。

対戦部屋の現在の状況としては、メンバとして入室中のユーザのユーザＩＤ、メンバの現在の状態（例えば、対戦中、テーブルにエントリー中、テーブルに未エントリー等の状態）、対戦部屋におけるメンバの対戦成績、観戦ユーザとして入室中のユーザのユーザＩＤ、メンバ又は観戦ユーザが入力したコメント、及び各テーブルの状況等が格納される。各テーブルの状況としては、テーブルを識別するためのテーブルＩＤ、エントリー中のユーザのユーザＩＤ、対戦の状況などが格納される。対戦の状況は、対戦の進行状況であり、例えば、現在のターン、各ユーザのライフポイント、各ユーザの手札、フィールド上に配置されたゲームカード等の情報である。

なお、データ記憶部３００に記憶されるデータは、上記の例に限られない。データ記憶部３００は、ゲームに必要なデータを記憶すればよい。例えば、データ記憶部３００は、各ユーザが保有するゲームカードに関するデータを記憶してもよいし、各ユーザのユーザＩＤや名前などの基本情報に関するデータを記憶してもよい。また例えば、データ記憶部３００は、対戦における各ユーザの操作と当該操作による実行結果の履歴を示す履歴データ記憶してもよい。当該履歴データは、対戦のリプレイを再生するために使用される。

［３−２．対戦部屋生成部］
対戦部屋生成部３０１は、制御部１１を主として実現される。対戦部屋生成部３０１は、複数のユーザがゲームをプレイするために用いる対戦部屋を生成する。本実施形態では、対戦部屋生成部３０１は、ユーザが対戦部屋モード画像Ｇ２のダイアログＤ２３から対戦部屋の設定情報を入力し、決定ボタンＢ２３５が選択された場合に、当該入力内容に基づいて、対戦部屋を生成することになる。

生成とは、例えば、ゲーム内に対戦部屋を生成することである。また例えば、対戦部屋に関するデータ（例えば、部屋ＩＤと観戦ＩＤ）をコンピュータ上に登録することである。また例えば、本実施形態では対戦部屋をグループの一例として説明しているが、ロビーをグループの一例とする場合には、ゲーム内に新たにロビーを生成することが、生成の一態様である。また例えば、仮想世界内の所定の場所をグループの一例とする場合には、仮想世界内に新たな場所を生成することが、生成の一態様である。また例えば、フレンドやギルドをグループの一例とする場合には、新たなフレンドグループやギルドを生成することが、生成の一態様である。

例えば、対戦部屋生成部３０１は、対戦部屋データＤＴ１に、対戦部屋に関するデータを新たに登録することによって、対戦部屋を生成する。より具体的には、対戦部屋生成部３０１は、対戦部屋データＤＴ１に新たなレコードを作成し、当該レコードに対戦部屋に関する情報を格納することによって、対戦部屋を生成する。本実施形態では、対戦部屋生成部３０１は、対戦部屋データＤＴ１に新たなレコードを作成し、後述する識別情報生成部３０２が生成した部屋ＩＤと観戦ＩＤに関連付けて、オーナユーザが入力した対戦部屋の基本情報を格納することによって、対戦部屋を生成する。

なお、対戦部屋生成部３０１は、ユーザによって所定の操作が行われた場合に対戦部屋を生成してもよいし、ユーザの操作ではなく他の条件が満たされた場合に対戦部屋を生成してもよい。他の条件としては、ゲームシステムＳの管理者が所定の操作をすること、所定の日時が到来すること、又はゲームシステムＳ全体のユーザ数が閾値以上となること等の各種条件を適用可能である。

［３−３．識別情報生成部］
識別情報生成部３０２は、制御部１１を主として実現される。識別情報生成部３０２は、後述する生成要求が受け付けられた場合に、複数の識別情報を生成する。識別情報とは、例えば、対戦部屋を一意に識別可能な情報である。例えば、識別情報は、ＩＤや対戦部屋の名前などの情報である。識別情報は、例えば、文字や数字などの記号列によって示される。

識別情報生成部３０２は、生成要求が受け付けられた場合に、他の対戦部屋の識別情報と重複しないように、複数の識別情報を生成すればよい。識別情報の生成は、所定のルールに基づいて行われるようにすればよく、当該ルールはプログラムコードとして記述されているようにすればよい。識別情報生成部３０２は、生成済みの識別情報と、当該生成ルールと、に基づいて、複数の識別情報を生成する。例えば、識別情報生成部３０２は、直近で生成された識別情報が示す数値を所定値だけ増加させることによって識別情報を生成してもよいし、直近で生成された識別情報に所定の文字を追加することによって識別情報を生成してもよい。

本実施形態では、複数の識別情報の一例として、部屋ＩＤと観戦ＩＤの２つのＩＤを説明する。このため、本実施形態で部屋ＩＤ又は観戦ＩＤと記載した箇所は、識別情報と読み替えることができる。

例えば、識別情報生成部３０２は、他の対戦部屋の部屋ＩＤと重複しないように、部屋ＩＤを生成する。更に、部屋ＩＤと観戦ＩＤが重複してもいけないので、例えば、識別情報生成部３０２は、他の対戦部屋の観戦ＩＤ及び今回生成する対戦部屋の観戦ＩＤと重複しないように、部屋ＩＤを生成する。

また例えば、識別情報生成部３０２は、他の対戦部屋の観戦ＩＤと重複しないように、観戦ＩＤを生成する。更に、部屋ＩＤと観戦ＩＤが重複してもいけないので、例えば、識別情報生成部３０２は、他の対戦部屋の部屋ＩＤ及び今回生成する対戦部屋の部屋ＩＤと重複しないように、観戦ＩＤを生成する。

複数の識別情報には、それぞれ互いに異なる機能が対応付けられている。例えば、識別情報ごとに、少なくとも１つの機能が対応付けられている。また例えば、識別情報ごとに、他の識別情報と対応付けられた機能とは一部又は全部が異なる機能が対応付けられている。識別情報と機能との対応関係は、予め数式形式、テーブル形式、又はプログラムコードの一部としてデータ記憶部３００に定めておけばよい。

機能とは、例えば、ゲームプログラムが有する機能の一部である。例えば、機能は、プログラムコードによって実行される処理である。また例えば、機能は、ユーザにゲームをプレイさせるための処理である。また例えば、機能は、ユーザに提供するサービスである。また例えば、機能は、ユーザに与えられる権限である。また例えば、機能は、ユーザに許可される操作である。例えば、機能は、ゲームをプレイすることでゲームに関与することであってもよいし、ゲームをプレイせずにゲームに関与することであってもよい。即ち、例えば、機能は、ゲームに直接的に関与することであってもよいし、間接的に関与することであってもよい。

例えば、ユーザを観戦させるための観戦機能であってもよい。また例えば、他のユーザと対戦させるための対戦機能であってもよい。また例えば、他のユーザと協力プレイさせるための協力機能であってもよい。また例えば、ゲームをプレイする他のユーザを応援、投票、又は妨害するための機能であってもよい。応援は、例えば、ゲームをプレイするユーザに対する応援であり、例えば、メッセージ、ゲームアイテム、ゲーム内通貨などを送ることである。投票は、例えば、勝者や敗者などを予想することである。妨害は、例えば、ゲームをプレイするユーザが不利になるように邪魔をすることである。

なお、各識別情報に対応付けられる機能は、互いに完全一致していなければよい。例えば、ある機能は、他の機能の全てを含んでもよい。また例えば、ある機能と他の機能は互いに一致部分がなく完全に異なってもよい。また例えば、ある機能と他の機能とで一部の機能が共通（部分一致）していてもよい。また例えば、ある機能は、他の機能よりも、ゲームをプレイするうえでの制限がかかっていたりしてもよい。また例えば、ある機能は、他の機能よりも使用可能なカードやキャラクタが多かったり少なかったりしてもよい。また例えば、ある機能は、他の機能よりもプレイ可能な時間が長かったり短かったりしてもよい。また例えば、ある機能は、他の機能よりもパラメータが多かったり小さかったりしてもよい。

本実施形態では、各識別情報に対応付けられた機能の何れか１つは、ゲームのプレイを観戦するための観戦機能である。例えば、観戦ＩＤに観戦機能が対応付けられている。なお、観戦とは、例えば、ゲームをプレイせずに画像や音声によってゲームの様子を見たり聞いたりすることである。別の言い方をすれば、観戦は、ゲームをプレイする当事者とはならず、第三者としてゲームを見ることである。例えば、ユーザが操作してもゲーム進行には影響せず、ユーザはゲームの様子を見たり聞いたりするだけの状態が、観戦に相当する。なお、例えば、観戦機能は、対戦をリプレイするためのリプレイ機能と、ユーザの対戦履歴を表示するための対戦履歴表示機能と、を含んでいてもよい。例えば、リプレイは、過去に行われた対戦の再現である。例えば、観戦は、過去に行われた対戦の再現を見ること（リプレイを見ること）と、現在進行中の対戦の様子を見ることと、の両方を包含する意味である。

本実施形態では、各識別情報に対応付けられた機能の何れか１つは、他のユーザと対戦するための対戦機能である。例えば、部屋ＩＤに対戦機能が対応付けられている。なお、対戦とは、例えば、他のユーザと戦ったり、スコアなどを競ったりすることである。別の言い方をすれば、対戦は、ゲームをプレイする当事者となることである。例えば、ユーザが操作した場合にゲーム進行に影響する状態が、観戦に相当する。

本実施形態では、対戦部屋には、複数のテーブルが設定されており、各識別情報に対応付けられた機能の何れか１つは、テーブルごとに、当該テーブルにエントリーする複数のユーザがゲームをプレイするための機能である。例えば、部屋ＩＤに、各テーブルで対戦するための対戦機能が対応付けられている。なお、なお、テーブルにエントリーすることは、サブグループに所属することの一態様である。このため、以降の説明で「テーブルにエントリー」と記載した箇所は、サブグループに所属と読み替えることができる。

テーブルにエントリーするとは、例えば、ユーザがテーブルを選択することであり、ユーザがテーブルにエントリーすることである。また例えば、テーブルの識別情報に、ユーザの識別情報が関連付けられることである。本実施形態の対戦機能では、対戦部屋にメンバとして入室した複数のユーザの各々が何れか１つのテーブルにエントリーし、同じテーブルにエントリーした他のユーザとゲームをプレイする。

なお、識別情報生成部３０２が生成する識別情報は、複数個であればよく、３つ以上であってもよい。３つ以上の識別情報が生成される場合には、１つの対戦部屋に対し、３つ以上の機能が存在することになる。例えば、識別情報生成部３０２は、１つの対戦部屋に対し、対戦機能が対応付けられた部屋ＩＤ、観戦機能が対応付けられた観戦ＩＤ、及び応援機能が対応付けられた応援ＩＤと、の３つを生成してもよい。また例えば、識別情報生成部３０２は、部屋ＩＤとして、自分のゲームカードの使用が対戦で制限されない無制限ＩＤと、自分のゲームカードの使用が対戦で制限される（例えば、決められたゲームカードしか使用できない）制限ＩＤと、の２種類を生成してもよい。識別情報生成部３０２は、対戦部屋内でのゲームに設定される機能の数に応じた識別情報を生成すればよい。

［３−４．ゲーム実行部］
ゲーム実行部３０３は、制御部１１を主として実現される。ゲーム実行部３０３は、複数のユーザが参加するゲームを実行する。例えば、ゲーム実行部３０３は、各ユーザを、識別情報生成部３０２が生成した複数の識別情報の何れか１つと関連付ける処理を実行し、当該ユーザに対し、当該ユーザと関連付けられた識別情報に対応する機能を提供する。ゲーム実行部３０３は、ユーザが関連付けられた識別情報に対応する機能に関するプログラムコードを実行することによって、当該機能をユーザに提供する。

例えば、ゲーム実行部３０３は、部屋ＩＤを入力したユーザを当該部屋ＩＤと関連付ける。ゲーム実行部３０３は、部屋ＩＤと関連付けられたユーザ（本実施形態ではメンバ）に対し、対戦機能を提供する。例えば、ゲーム実行部３０３は、部屋ＩＤと関連付けられたユーザの操作に基づいてテーブルにエントリーさせたり、ユーザの操作に基づいて対戦を実行したりする。別の言い方をすれば、ゲーム実行部３０３は、部屋ＩＤと関連付けられたユーザの操作に基づいて、他のユーザと対戦するためのプログラムコードを実行する。

また例えば、ゲーム実行部３０３は、観戦ＩＤを入力したユーザを当該観戦ＩＤと関連付ける。ゲーム実行部３０３は、観戦ＩＤと関連付けられたユーザ（本実施形態では観戦ユーザ）に対し、観戦機能を提供する。例えば、ゲーム実行部３０３は、観戦ＩＤと関連付けられたユーザのゲーム端末１０に対し、実行中の対戦の様子を示す画像を表示させるためのデータを送信する。別の言い方をすれば、ゲーム実行部３０３は、観戦ＩＤと関連付けられたユーザの操作に基づいて、他のユーザの対戦を観戦するためのプログラムコードを実行する。

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

図１４に示すように、まず、制御部１１は、記憶部１２に記憶されたゲームプログラムを起動させ、ユーザが所定の操作をした場合に、対戦モード選択画像Ｇ１を表示部１５に表示させる（Ｓ１０１）。なお、対戦モード選択画像Ｇ１の表示データは、記憶部１２に記憶されていてもよいし、サーバ３０から受信してもよい。

制御部１１は、操作部１４の検出信号に基づいて、ユーザの操作を特定する（Ｓ１０３）。ここでは、対戦部屋ボタンＢ１３を選択する操作、又は、他の操作（ランク戦ボタンＢ１０、フリー対戦ボタンＢ１１、又はフレンド対戦ボタンＢ１２を選択する操作）が行われる。他の操作が行われた場合（Ｓ１０３；その他）、本処理は終了し、制御部１１は、ランク戦、フリー対戦、又はフレンド対戦に係る処理を実行することになる。

ユーザが対戦部屋ボタンＢ１３を選択した場合（Ｓ１０３；対戦部屋ボタン）、制御部１１は、対戦部屋モード画像Ｇ２を表示部１５に表示させる（Ｓ１０５）。なお、対戦部屋モード画像Ｇ２の表示データは、記憶部１２に記憶されていてもよいし、サーバ３０から受信してもよい。

制御部１１は、操作部１４の検出信号に基づいて、ユーザの操作を特定する（Ｓ１０７）。ここでは、対戦部屋生成ボタンＢ２０を選択する操作、観戦ユーザ入室ボタンＢ２２を選択する操作、又は観戦ユーザ入室ボタンＢ２２を選択する操作が行われる。

ユーザが対戦部屋生成ボタンＢ２０を選択した場合（Ｓ１０７；対戦部屋生成ボタン）、制御部１１は、対戦部屋モード画像Ｇ２上にダイアログＤ２３を表示させる（Ｓ１０９）。なお、ダイアログＤ２３の表示データは、記憶部１２に記憶されていてもよいし、サーバ３０から受信してもよい。

制御部１１は、ダイアログＤ２３に対するユーザの入力に基づいて、サーバ３０に対し、対戦部屋の生成要求を送信する（Ｓ１１１）。Ｓ１１１においては、制御部１１は、操作部１４の検出信号に基づいて、ユーザの入力内容を特定する。例えば、制御部１１は、入力フォームＦ２３０に対して入力された対戦部屋の名前を記憶部１２に記録する。また例えば、制御部１１は、入力フォームＦ２３１に対して入力された人数を記憶部１２に記録する。また例えば、制御部１１は、ラジオボタンＢ２３２，Ｂ２３３の選択結果を記憶部１２に記録する。制御部１１は、決定ボタンＢ２３５が選択されたことに応じて、記憶部１２に記憶された入力内容を含む生成要求を送信する。生成要求は、予め定められたデータ形式で行われるようにすればよく、ユーザＩＤと、ダイアログＤ２３に対する入力内容と、を含む。なお、ユーザＩＤは、予め記憶部１２に記憶されているものとする。この点は、以降の処理でも同様である。また、ユーザがキャンセルボタンＢ２３４を選択した場合には、Ｓ１１１の処理が実行されず、Ｓ１０５の処理に戻るものとする。

サーバ３０においては、生成要求を受信すると、制御部３１は、受信した生成要求に基づいて、対戦部屋データＤＴ１に新たなレコードを作成し、生成要求に含まれる対戦部屋の基本情報を格納する（Ｓ３０１）。

制御部３１は、対戦部屋の識別情報として、対戦機能が対応付けられた部屋ＩＤと、観戦機能が対応付けられた観戦ＩＤと、を生成し（Ｓ３０３）、対戦部屋の生成処理が完了する。Ｓ３０３においては、制御部３１は、所定のルールに基づいて部屋ＩＤと観戦ＩＤを生成し、Ｓ３０１で生成したレコードに格納する。

一方、Ｓ１０７において、ユーザがメンバ入室ボタンＢ２１を選択した場合（Ｓ１０７；メンバ入室ボタン）、図１５に移り、制御部１１は、対戦部屋モード画像Ｇ２上にダイアログＤ２４を表示させる（Ｓ１１３）。なお、ダイアログＤ２４の表示データは、記憶部１２に記憶されていてもよいし、サーバ３０から受信してもよい。

制御部１１は、ダイアログＤ２４に対するユーザの入力に基づいて、サーバ３０に対し、メンバとしての入室要求を送信する（Ｓ１１５）。Ｓ１１５においては、制御部１１は、操作部１４の検出信号に基づいて、ユーザの入力内容を特定する。例えば、制御部１１は、入力フォームＦ２４０に対して入力された部屋ＩＤを記憶部１２に記録する。制御部１１は、決定ボタンＢ２４１が選択されたことに応じて、記憶部１２に記憶された入力内容を含む入室要求を送信する。入室要求は、予め定められたデータ形式で行われるようにすればよく、ユーザＩＤと、ダイアログＤ２４に対する入力内容と、を含む。なお、ユーザが決定ボタンＢ２４１を選択しなかった場合には、Ｓ１１５の処理が実行されず、Ｓ１０５の処理に戻るものとする。

サーバ３０においては、入室要求を受信すると、制御部３１は、対戦部屋データＤＴ１に基づいて、受信した部屋ＩＤが存在するか否かを判定する（Ｓ３０５）。Ｓ３０５においては、制御部３１は、対戦部屋データＤＴ１に格納された部屋ＩＤの中に、受信した入室要求に含まれる部屋ＩＤが存在するか否かを判定する。

部屋ＩＤが存在すると判定された場合（Ｓ３０５）、制御部３１は、ユーザをメンバとして入室させる（Ｓ３０７）。Ｓ３０７においては、制御部３１は、対戦部屋データＤＴ１のうち、入室要求に含まれる部屋ＩＤが格納されたレコードの対戦部屋の状況を更新し、入室要求をしたユーザのユーザＩＤをメンバとして追加する。以降、対戦部屋画像Ｇ３が表示され、ユーザはテーブルへのエントリー及び他のユーザとの対戦が可能な状態となる。即ち、ユーザが入力した部屋ＩＤによって、当該ユーザに対して対戦機能が提供されることになる。

一方、Ｓ１０７において、ユーザが観戦ユーザ入室ボタンＢ２２を選択した場合（Ｓ１０７；観戦ユーザ入室ボタン）、図１５に移り、制御部１１は、対戦部屋モード画像Ｇ２上にダイアログＤ２５を表示させる（Ｓ１１７）。なお、ダイアログＤ２５の表示データは、記憶部１２に記憶されていてもよいし、サーバ３０から受信してもよい。

制御部１１は、ダイアログＤ２５に対するユーザの入力に基づいて、サーバ３０に対し、観戦ユーザとしての入室要求を送信する（Ｓ１１９）。Ｓ１１９においては、制御部１１は、操作部１４の検出信号に基づいて、ユーザの入力内容を特定する。例えば、制御部１１は、入力フォームＦ２５０に対して入力された観戦ＩＤを記憶部１２に記録する。制御部１１は、決定ボタンＢ２５１が選択されたことに応じて、記憶部１２に記憶された入力内容を含む入室要求を送信する。入室要求は、予め定められたデータ形式で行われるようにすればよく、ユーザＩＤと、ダイアログＤ２５に対する入力内容と、を含む。なお、ユーザが決定ボタンＢ２５１を選択しなかった場合には、Ｓ１１９の処理が実行されず、Ｓ１０５の処理に戻るものとする。

サーバ３０においては、入室要求を受信すると、制御部３１は、対戦部屋データＤＴ１に基づいて、受信した観戦ＩＤが存在するか否かを判定する（Ｓ３０９）。Ｓ３０９においては、制御部３１は、対戦部屋データＤＴ１に格納された観戦ＩＤの中に、受信した入室要求に含まれる観戦ＩＤが存在するか否かを判定する。

観戦ＩＤが存在すると判定された場合（Ｓ３０９；Ｙ）、制御部３１は、ユーザを観戦ユーザとして入室させる（Ｓ３１１）。Ｓ３１１においては、制御部３１は、対戦部屋データＤＴ１のうち、入室要求に含まれる観戦ＩＤが格納されたレコードの対戦部屋の状況を更新し、入室要求をしたユーザのユーザＩＤを観戦ユーザとして追加する。以降、観戦画像Ｇ４が表示され、ユーザは、観戦したいテーブルを選択することができる状態となる。即ち、ユーザが入力した観戦ＩＤによって、当該ユーザに対して観戦機能が提供されることになる。

以上説明したゲームシステムＳによれば、決定ボタンＢ２３５が選択された場合に、対戦部屋に関連付けられる複数の識別情報が生成され、複数の識別情報にはそれぞれ互いに異なる機能が対応付けられているので、対戦部屋の中で実行されるゲームに他のユーザが適切に関与することができる。例えば、ユーザに対して何らかの機能が提供されることで、ゲームを見ることすらできないといったことを防止することができる。

また、観戦ＩＤによって、ユーザがゲームを観戦することができるので、ゲームを観戦することすらできず不満を感じるといったことを防止することができる。

また、部屋ＩＤによって、ユーザが他のユーザと対戦することができるので、ゲームをプレイすることすらできず不満を感じるといったことを防止することができる。

また、テーブルごとに、当該テーブルにエントリーするユーザ同士でゲームがプレイされるので、好きなユーザ同士でゲームをプレイさせることができる。

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

（１）例えば、実施形態では、部屋ＩＤに対戦機能が対応付けられており、観戦ＩＤに観戦機能が対応付けられている場合を説明したが、各識別情報に対応付けられた機能の何れか１つは、他のユーザと協力して対戦するための協力機能であってもよい。例えば、部屋ＩＤに協力機能が対応付けられていてもよい。協力とは、例えば、他のユーザと協力して共通の目標の達成を目指すことである。別の言い方をすれば、協力は、ゲームをプレイする当事者となることである。例えば、ユーザが操作した場合と、協力相手の他のユーザが操作した場合と、にゲーム進行に影響する状態が協力に相当する。

変形例（１）によれば、ユーザが他のユーザと協力することができるので、ゲームをプレイすることすらできず不満を感じるといったことを防止することができる。

（２）また例えば、ゲームシステムＳで実行されるゲームは、複数のユーザでプレイされる第１ゲームパートと、第２ゲームパートと、を含んでいてもよい。第１ゲームパートのゲームプログラムと第２ゲームパートのゲームプログラムとは、プログラムとして一体であってもよいし別体であってもよい。

第１ゲームパートは、例えば、ゲームのうち、他のユーザと対戦したり協力したりすることによってプレイする一部分である。実施形態で説明した各識別情報に対応付けられた機能は、第１ゲームパートに関する機能である。

第２ゲームパートは、例えば、第１ゲームパートとは異なるゲーム部分であればよく、例えば、ゲームのうち、ユーザが１人でプレイする部分である。また例えば、第２ゲームパートは、ユーザが１人で所定のゲーム課題（クエスト・ミッション）をクリアする部分である。また例えば、第２ゲームパートは、ネットワークに接続しなくてもプレイ可能な部分である。また例えば、第２ゲームパートは、第１ゲームパートとはゲームのクリア条件・勝利条件・報酬体系などが異なる部分である。例えば、第１ゲームパートと第２ゲームパートは、内容が共通する部分があり、例えば、登場人物、ユーザが使用するゲームオブジェクト、ストーリーや世界観などは共通していてもよい。

なお、実施形態と同様に、本変形例でも、各ユーザは、複数の識別情報の何れか１つと関連付けられ、自身と関連付けられた識別情報に対応する機能を利用可能である。各ユーザは、複数の識別情報のうち自身が入力した識別情報と関連付けられることになる。

利用とは、例えば、機能が提供されることである。例えば、ユーザの指示に基づいて、機能に対応するプログラムコードを実行可能にすることである。例えば、機能が観戦機能であれば、実行中のゲームの画面をユーザの端末に表示させることである。また例えば、機能が対戦機能であれば、ユーザが他のユーザと対戦できるようにすることである。また例えば、機能が協力機能であれば、ユーザが他のユーザと協力プレイできるようにすることである。また例えば、機能が応援・投票・妨害機能であれば、ユーザが他のユーザを応援・投票・妨害できるようにすることである。

複数の識別情報には、ユーザが第２ゲームパートをプレイしても関連付けが維持される識別情報と、ユーザが第２ゲームパートをプレイした場合に関連付けが解除される識別情報と、が含まれる。

維持とは、例えば、ユーザが識別情報に関連付けられた状態のまま変えないことである解除とは、例えば、識別情報に関連付けられた状態から関連付けられていない状態に変えることである。機能が提供されない状態に変えることである。例えば、ユーザを部屋やロビーから退室させることである。また例えば、仮想世界の中に設定された所定の場所から離れることである。また例えば、フレンドグループやギルドから離脱させることである。なお、ゲーム端末１０とサーバ３０との接続が切断された場合に、ユーザと識別情報との関連付けが解除されてもよいが、ここでは、ユーザと識別情報との関連付けが維持されるものとする。なお、接続が切断とは、例えば、ゲーム端末１０とサーバ３０の少なくとも一方が通信を終了するための信号を送信すること、ゲーム端末１０とサーバ３０の少なくとも一方の応答がない状態が一定時間以上経過することを意味する。また、部屋ＩＤについては、通信が切断してもユーザが関連付けられた状態を維持し、観戦ＩＤについては、通信が切断した場合にユーザとの関連付けを解除するといったように、通信が切断された場合に関連付けを維持するか解除するかを識別情報に応じて異ならせてもよい。

例えば、部屋ＩＤは第２ゲームパートをプレイしてもユーザと部屋ＩＤとの関連付けが維持される。一方、例えば、観戦ＩＤは第２ゲームパートをプレイした場合にユーザと観戦ＩＤとの関連付けが解除される。なお、どの識別情報が、第２ゲームパートをプレイしても関連付けが維持される識別情報であるかは、予めデータ記憶部３００に定めておけばよい。同様に、どの識別情報が、ユーザが第２ゲームパートをプレイした場合に関連付けが解除される識別情報であるかは、予めデータ記憶部３００に定めておけばよい。

変形例（２）によれば、第２ゲームパートをプレイしても関連付けが維持される識別情報があるので、第２ゲームパートをプレイした後に、再び識別情報との関連付けをし直さなければならないといった煩雑さを防止することができる。また、第２ゲームパートをプレイした場合に関連付けが解除される識別情報については、ユーザがずっと識別情報と関連付けられているといった状態を防止することができる。

（３）また例えば、変形例（２）で説明した第２ゲームパートは、テーブルにエントリー中のユーザによってプレイされることが制限されるようにしてもよい。例えば、ゲーム実行部３０３は、テーブルにエントリー中のユーザについては、テーブルのエントリーを解除しなければ、第２ゲームパートをプレイできないようにしてもよい。なお、テーブルのエントリーは、エントリー中のテーブルのテーブル選択ボタンＢ３８が選択されることによって解除されるようにすればよい。

変形例（３）によれば、テーブルにエントリー中のユーザが第２ゲームパートをプレイすることが制限されるので、他のユーザが一緒にゲームをプレイしようと思っても、それに気づかずに第２ゲームパートをプレイしてしまうといったことを防止することができる。

（４）また例えば、２人のユーザが先攻と後攻に分かれて対戦するゲームが実行されるようにしてもよい。先攻とは、例えば、２人のユーザのうち、先に攻撃する方である。ターン制のゲームであれば、先に自分のターンが訪れることである。野球ゲームであれば、イニングの表に攻撃する方である。後攻とは、例えば、２人のユーザのうち、後に攻撃する方である。ターン制のゲームであれば、後に自分のターンが訪れることである。野球ゲームであれば、イニングの裏に攻撃する方である。

各識別情報に対応付けられた機能の何れか１つは、テーブルごとに、当該テーブルにエントリーする２人のユーザの少なくとも一方が先攻と後攻を決定してゲームをプレイさせるための機能である。例えば、ユーザがテーブルにエントリーする際に先攻と後攻の何れか１つを指定可能であってもよいし、ゲームの開始時に先攻と後攻の何れか１つを指定可能であってもよい。ゲーム実行部３０３は、ゲーム端末１０からユーザの指定結果を取得し、当該指定結果に基づいて先攻と後攻を決定してゲームを開始する。

変形例（４）によれば、ユーザが先攻と後攻の好きな方を選択することができるので、対戦の興趣性を向上させることができる。

［６．第２実施形態について］
次に、ゲームシステムＳの別実施形態を説明する。以降説明する第２実施形態では、第１実施形態で説明したゲームと同様のゲームが実行される場合を一例として説明するが、第２実施形態のゲームは、第１実施形態のゲームとは異なってもよい。第２実施形態では、実在の大会会場においてゲーム大会が開催される。

大会会場とは、例えば、ゲーム大会の開催場所であり、ユーザを集める場所である。例えば、大会会場は、イベント会場、野球場、陸上競技場、音楽ホール、ゲームセンターなどである。

ゲーム大会とは、例えば、ゲームに関するイベントであり、ユーザが互いに優劣を競うものである。なお、ゲーム大会に出場せずに観戦するだけのユーザが存在してもよい。例えば、ゲーム大会では、１種類のゲームの優劣を競ってもよいし、複数種類のゲームの優劣を競ってもよい。また例えば、ゲーム大会は、出場ユーザが、互いに協力してプレイするものであってもよい。また例えば、ゲーム大会では、出場ユーザが自分の端末を操作してもよいし、運営者によって専用の端末が用意されていてもよい。また例えば、ゲーム大会は、いわゆるｅスポーツと呼ばれる大会であってもよいし、特に賞金や景品がかけられていない大会であってもよい。

［６−１．第２実施形態のゲームシステムの全体構成］
図１６は、第２実施形態のゲームシステムＳの全体構成を示す図である。図１６に示すように、ゲームシステムＳは、第１実施形態で説明した構成に加えて、管理者端末５０を含む。管理者端末５０は、ゲーム大会の管理者が操作するコンピュータである。管理者は、ゲーム大会の運営を管理する者であり、例えば、ゲーム会社の関係者であってもよいし、イベント運営を委託された会社の関係者であってもよい。なお、管理者端末５０は、１台だけではなく、複数台存在してもよい。

例えば、管理者端末５０は、携帯端末（例えば、スマートフォンなどの携帯電話又はタブレット型コンピュータ）又はパーソナルコンピュータ等である。図１６に示すように、管理者端末５０は、制御部５１、記憶部５２、通信部５３、操作部５４、及び表示部５５を含む。制御部５１、記憶部５２、通信部５３、操作部５４、及び表示部５５のハードウェア構成は、それぞれ制御部１１、記憶部１２、通信部１３、操作部１４、及び表示部１５と同様であってよい。大会会場では、ユーザがゲーム端末１０を操作して対戦し、管理者が管理者端末５０を操作してゲーム大会の運営業務を行う。

図１７は、大会会場内でユーザ同士が対戦する様子を示す図である。図１７に示すように、大会会場にはテーブルＴが用意されており、テーブルＴを挟むようにしてユーザＵ１，Ｕ２が座る。ユーザＵ１，Ｕ２の各々は、手元にあるゲーム端末１０を操作して対戦する。テーブルＴの近くにいる管理者Ｍは、管理者端末５０を操作しながら対戦の進行を管理する。例えば、大会会場には、図１７のようなテーブルＴが複数台配置されており、各テーブルで対戦が行われる。なお、以降では、管理者Ｍ、ユーザＵ１，Ｕ２、及びテーブルＴの各符号を省略する。

例えば、ゲーム大会は、予選を勝ち抜いた複数のユーザが出場してもよいし、特に予選が行われることなく出場するユーザが決まってもよい。また例えば、ゲーム大会は、１日で終了してもよいし、複数日にまたがって開催されてもよい。本実施形態では、ゲーム大会が２日間にわたって開催され、１日目にリーグ戦が開催され、２日目にトーナメント戦が開催される場合を説明する。

リーグ戦では、複数のブロックの各々で総当たり戦が行われる。例えば、ユーザは、複数のブロックのうちの何れか１つに割り当てられ、同じブロックに割り当てられた他のユーザ全員と対戦する。例えば、ユーザは、同じブロックの他のユーザと３回ずつ対戦し、先に２勝した方の勝利となる。以降、同じユーザ同士で行われる３回の対戦の各々をラウンドと記載する。

リーグ戦におけるブロック数は、ユーザ数などに応じて定めればよく、本実施形態では２つとするが、ブロック数は３つ以上であってもよい。以降、２つのブロックを、それぞれＡブロック・Ｂブロックという。Ａブロックに割り当てられるユーザの数と、Ｂブロックに割り当てられるユーザの数と、は同じであってもよいし、異なっていてもよい。

リーグ戦では、ブロックごとに、総当たり戦の結果に基づいてユーザの順位が決定される。例えば、各ブロックの上位２名は、２日目に行われるトーナメント戦に出場することができる。即ち、２日目のトーナメント戦は、合計４名のユーザによって行われる勝ち抜き戦となる。以降、ゲーム大会における１日目の流れと２日目の流れの詳細を説明する。

［６−１．ゲーム大会の流れ］
図１８−図２１は、ゲーム大会の１日目における進行手順を示す図である。各ブロックで行われる対戦は、開始時間が予め決められており、各ユーザは、自身の対戦の開始時間が近づくまで、大会会場内又はその付近の控室で待機する。また、テーブルごとに、当該テーブルの進行を担当する管理者が決められている。管理者は、自身が担当するテーブルの対戦の開始時間が近づくと、管理者端末５０を操作して対戦の準備を行う。

図１８に示すように、各テーブルの管理者は、操作部５４を操作して記憶部５２に記憶された管理ツールを起動し、ゲーム大会の進行を管理するための管理ツール画像を表示部５５に表示させる（Ｓ５０１）。なお、管理ツールは、ゲーム大会の進行を管理するためのツールであり、管理ツールのプログラムは、予め記憶部５２に記憶されているものとする。

図２２は、管理ツール画像の一例を示す図である。図２２に示すように、管理ツール画像Ｇ５では、管理者が担当するテーブルを入力するための入力フォームＦ５０が表示されており、例えば、大会会場に用意されたテーブルがプルダウン形式で選択できるようになっている。Ｓ５０１では、管理者は、入力フォームＦ５０から自分が担当するテーブルを選択する。

また、本実施形態では１対戦あたり３ラウンド行われるので、管理ツール画像Ｇ５では、これから開始するラウンドを入力するための入力フォームＦ５１が表示されており、第１ラウンド〜第３ラウンドの何れか１つをプルダウン形式で選択できるようになっている。Ｓ５０１の時点では、管理者は、まだ対戦前の準備作業をしているので、入力フォームＦ５１から第１ラウンドを選択することになる。

管理者は、入力フォームＦ５０からテーブルを選択し、入力フォームＦ５１からラウンドを選択すると、ラウンド進行ボタンＢ５２を選択する（Ｓ５０３）。その後、管理者は、大会会場内にあるゲーム端末１０とレジェンドカードとを、自身が担当するテーブルに持っていく（Ｓ５０５）。

なお、レジェンドカードは、レジェンドと呼ばれるゲームキャラクタの顔が印刷されたカードであり、ユーザが対戦で使用するデッキを指定するために用いられる。本実施形態では、複数のレジェンドの各々がゲーム内でゲームカードを使用して対戦する。例えば、ユーザは、レジェンドごとにデッキを用意することが可能であり、ユーザが対戦で使用するレジェンドを指定すると、当該レジェンドに対応するデッキをその対戦で使用することができる。レジェンドカードをテーブルに置くのは、ユーザが使用するレジェンドを指定するためである。

また、大会会場は、ネットワークＮに有線接続できる環境が整っており、例えば、管理者は、ゲーム端末１０を置き（Ｓ５０７）、各ゲーム端末１０を有線接続する（Ｓ５０９）。有線としては、ゲーム端末１０に備えられた通信端子に応じた任意の規格を適用可能である。

第１実施形態で説明した対戦部屋モードは、第２実施形態のゲーム大会でも利用されるようになっており、管理者は、Ｓ５０９で有線接続した各ゲーム端末１０を操作し、ゲームプログラムを起動して対戦モード選択画像Ｇ１を表示させる。なお、ゲーム大会専用の対戦部屋は、予め管理者によって生成されており、当該対戦部屋の部屋ＩＤと観戦ＩＤも予め生成されているものとする。例えば、参加資格のないユーザが勝手にメンバとして入室することを防ぐために、管理者のみが部屋ＩＤを把握するようにしてもよい。一方、観戦ＩＤは、ゲームプログラム内のお知らせ機能やウェブサイトなどを通じて多くのユーザに通知されるようにしてもよい。

管理者は、各ゲーム端末１０を操作し、対戦部屋ボタンＢ１３を選択して対戦部屋モード画像Ｇ２を表示させ、メンバ入室ボタンＢ２１を選択してダイアログＤ２４から部屋ＩＤを入力し、ゲーム大会用の対戦部屋にメンバとして入室する（Ｓ５１１）。なお、各ゲーム端末１０には、当該ゲーム端末１０を利用するユーザのユーザＩＤが予め入力されているものとする。これにより、管理者がゲーム端末１０を操作したとしても、サーバ３０は、どのユーザがメンバとして入室したかを特定することができる。

管理者は、ゲーム端末１０を裏返し、当該ゲーム端末１０を使用予定のユーザの名前を確認できるようにする（Ｓ５１３）。例えば、管理者は、ゲーム端末１０の裏面にユーザ名が印刷された紙やシールを貼り付けてもよいし、ユーザ名が印刷された紙をゲーム端末１０の上に置いてもよい。管理者は、レジェンドカードが対戦相手にも見えるように、各ユーザのレジェンドカードの表（レジェンドの顔が描かれた側）を上にしてテーブルに置く（Ｓ５１５）。

以上により、対戦の事前準備が完了する。管理者は、事前準備を終えると、対戦の開始時間が近づいてユーザが控室から出てくるのを待つ。図１９に示すように、ユーザは、対戦開始の５分前を目途にテーブルに着席する（Ｓ１０１）。管理者は、ユーザが着席したことを確認すると（Ｓ５１７）、テーブル上のゲーム端末１０を使用予定のユーザと、実際に着席したユーザと、の一致を確認し（Ｓ５１９）、各ユーザに対し、ゲーム端末１０を表にするよう促す（Ｓ５２１）。

ユーザは、管理者の指示を受けると、ゲーム端末１０を表にする（Ｓ１０３）。管理者は、各ユーザに対し、手を挙げて何れかのレジェンドカードを選択することを促す（Ｓ５２３）。Ｓ５２３においては、管理者は、複数のレジェンドカードの中から、今から始まるラウンドで使用するレジェンドが描かれたレジェンドカードを選択することを促すことになる。

ユーザは、テーブル上の複数のレジェンドカードのうちの何れか１つを選択し（Ｓ１０５）、手を挙げて合図をしつつ、選択したレジェンドカードを管理者にだけ見せる（Ｓ１０７）。この段階では、対戦相手は、どのレジェンドカードが選択されたかを知ることができない。管理者は、２人のユーザの各々のレジェンドカードを確認すると、各ユーザが選択したレジェンドカードを管理ツールから登録する（Ｓ５２５）。

図２３は、管理ツールからレジェンドカードが登録される様子を示す図である。Ｓ５０３においてラウンド進行ボタンＢ５２が選択されると、管理ツール画像Ｇ５の表示が変わり、図２３に示すように、管理ツール画像Ｇ５には、管理者が担当するテーブル、これから開始するラウンドの情報、対戦部屋の部屋ＩＤ、対戦が行われるブロック、ユーザの名前、及びユーザが使用可能なレジェンドの情報等が表示される。

また、管理ツール画像Ｇ５には、ラウンドのステータスを入力するための入力フォームＦ５３と、ユーザが使用するレジェンドを入力するための入力フォームＦ５４と、が表示される。管理者は、各ユーザが選択したレジェンドカードに描かれたレジェンドを入力フォームＦ５４から入力する。これにより、管理ツール側で、各ユーザがどのデッキを使用するかを特定可能となる。なお、管理ツールに対して入力された情報は、適宜サーバ３０にも送信され、サーバ３０側でも、各ユーザがどのデッキを使用するかを特定可能となる。

管理者は、各ユーザに互いに握手するように促し、ラウンドを開始させる（Ｓ５２７）。各ユーザは、互いに挨拶及び握手を行い、自分のゲーム端末１０を操作してラウンドを開始する（Ｓ１０９）。管理者は、対戦の開始を確認すると、管理ツール画像Ｇ５の入力フォームＦ５３から、ラウンドのステータスを対戦中に変更する（Ｓ５２９）。

図２０に移り、各ユーザがゲーム端末１０を操作することによって、ラウンドが進行する（Ｓ１１１）。ラウンド中に通信エラーが発生した場合には、管理者は、ユーザに対し、ゲーム端末１０から所定の操作をして復帰を試みることを促す（Ｓ５３１）。また、サーバ３０側でエラーが発生した場合には、管理者は、各ユーザが使用中のデッキ（即ち、ラウンドの開始前に各ユーザが選択したレジェンドカード）を変更することなく、ラウンドの最初から再試合をさせる（Ｓ５３３）。なお、予め定められた制限時間が経過しても勝負がつかなかった場合には、引き分けとなるようにしてもよい。

実行中のラウンドの勝敗又は引き分けが決定すると、各ユーザは、手を挙げて管理者に合図し、ゲーム端末１０をテーブル上に置く（Ｓ１１３）。管理者は、各ユーザのゲーム端末１０の画面を確認し、対戦結果を管理ツールから登録する（Ｓ５３３）。この時点で何れかのユーザが２勝した場合、又は、３ラウンド目が終了した場合には対戦終了となる（Ｓ５３５）。

対戦が終了していない場合（Ｓ５３７；Ｎ）、勝利したユーザは自身が使用したレジェンドカードを裏側にして、管理者は、管理ツール画像Ｇ５の入力フォームＦ５１から次のラウンドを入力し、Ｓ５２３から次のラウンドを進行させる。なお、勝利した方のユーザは、先のラウンドで使用したレジェンドカードを次のラウンドで使用できないものとする。一方、敗北した方のユーザは、先のラウンドで使用したレジェンドカードを次のラウンドで使用することができる。

一方、Ｓ５３３において、対戦が終了した場合（Ｓ５３７；Ｙ）、勝ち数が多い方のユーザが勝利となり、管理者は、対戦結果を管理ツールに登録し、対戦状態を対戦終了に変更する（Ｓ５３９）。

図２４は、管理ツールから対戦結果が登録される様子を示す図である。図２４に示すように、管理者は、Ｓ５３３において、管理ツール画像Ｇ５の入力フォームＦ５５から各ユーザの勝敗を入力し、入力フォームＦ５３から対戦終了のステータスに変更する。管理者は、ユーザにゲーム端末１０をテーブル上に置いてもらい、互いに握手してもらう（Ｓ５４１）。管理者は、ユーザに対し、控室に戻ることを促し（Ｓ５４３）、ユーザは控室に戻る（Ｓ１１５）。

図２１に示すように、ユーザが控室に戻ると、管理者は、２台のゲーム端末１０のうちの片方の対戦部屋画像Ｇ３から退室ボタンＢ３７を選択し、片方のユーザを対戦部屋から退室させる（Ｓ５４５）。そして、管理者は、当該ゲーム端末１０の有線接続を外す（Ｓ５４７）。同様に、管理者は、２台のゲーム端末１０のうちの他方の対戦部屋画像Ｇ３から退室ボタンＢ３７を選択し、残りのユーザを対戦部屋から退室させる（Ｓ５４９）。そして、管理者は、当該ゲーム端末１０の有線接続を外す（Ｓ５５１）。

なお、対戦中の各ユーザの操作及びゲームの進行の履歴は予め記録されており、対戦のリプレイを再生することができるようになっている。管理者は、終了した対戦の結果とリプレイデータと対応付けるための操作を行う（Ｓ５５３）。なお、この対応付けは、自動化されていてもよい。管理者は、管理ツールから対戦結果の公開設定をオンにする（Ｓ５５５）。なお、終了した対戦の公開設定は自動的にオンになるようにしてもよい。管理者は、所定の位置にゲーム端末１０とレジェンドカードを戻す（Ｓ５５７）。

以上のようにしてリーグ戦が繰り返される。各ブロックの全試合が終了して上位２名が決定すると、管理者は、管理ツールから翌日のトーナメント戦のトーナメント表を生成する。管理者が生成したトーナメント表は、ユーザに公開される。

ゲーム大会の２日目に行われるトーナメント戦は、ゲーム大会の１日目に行われるリーグ戦の手順と全く同じであってもよいし異なっていてもよい。例えば、本実施形態のように、トーナメント戦の試合数がリーグ戦よりも少ない場合には、Ｓ５０１とＳ５０３の手順は省略し、Ｓ５０５の手順から開始されてもよい。

第２実施形態のゲーム大会は、上記説明した手順で進行する。第２実施形態のゲームシステムＳでは、各ユーザが、予めレジェンドとデッキとを対応付けておき、ゲーム大会の対戦時にレジェンドカードを選択することによって、どのデッキを使用するかを容易に選択できるようになっている。以降、当該構成の詳細を説明する。

［６−２．第２実施形態で実現される機能］
図２５は、第２実施形態の機能ブロック図である。図２５に示すように、第２実施形態では、第１実施形態で説明した機能ブロックに加え、データ取得部３０４が実現される。なお、データ記憶部３００、対戦部屋生成部３０１、識別情報生成部３０２、及びゲーム実行部３０３は、第１実施形態と一部共通するが下記の点で異なる。

例えば、データ記憶部は、ユーザごとに、ゲームで使用可能な第１ゲームオブジェクトと、ゲーム内で第１ゲームオブジェクトを使用する第２ゲームオブジェクトと、の組み合わせが複数格納されたオブジェクトデータＤＴ２を記憶する。なお、オブジェクトは、ゲームで使用され得る対象であり、例えば、ゲームキャラクタ、ゲームカード、ゲームアイテムである。以降では、第１ゲームオブジェクトが複数のゲームカードからなるデッキであり、第２ゲームオブジェクトがレジェンド（ゲームキャラクタ）である場合を説明する。

図２６は、オブジェクトデータＤＴ２の一例を示す図である。図２６に示すように、オブジェクトデータＤＴ２は、ユーザが使用するゲームオブジェクトに関するデータである。例えば、オブジェクトデータＤＴ２には、ユーザＩＤと関連付けて、レジェンドとデッキとが格納される。デッキとしては、ゲームカードを識別するＩＤが格納される。データ取得部は、制御部３１を主として実現される。データ取得部は、データ記憶部３００に記憶されたオブジェクトデータＤＴ２を取得する。

なお、複数のスキルのうちの少なくとも１つがレジェンドに関連付けられる場合には、オブジェクトデータＤＴ２には、レジェンドとスキルの両方と、デッキと、が関連付けられていてもよい。この場合、同じレジェンドであったとしてもスキルが異なればデッキも異なるようにしてもよい。

また、データ記憶部３００は、ゲーム大会に関するデータを記憶してもよい。例えば、データ記憶部３００は、リーグ戦やトーナメント戦の対戦組み合わせを記憶してもよいし、各対戦の開始時間を記憶してもよい。また例えば、データ記憶部３００は、ゲーム大会に出場するユーザのユーザＩＤのリストを記憶してもよい。

第２実施形態のゲームでは、各ユーザの複数のデッキのうち、当該ユーザにより選択されたレジェンドに対応するデッキが使用される。例えば、ゲーム実行部３０３は、対戦の開始時に、ユーザが指定したレジェンドを取得する。本実施形態では、ユーザが指定したレジェンドは、管理ツールから入力されるので、ゲーム実行部３０３は、オブジェクトデータＤＴ２に格納された複数のレジェンドのうち、管理ツールから入力されたレジェンドに対応するデッキを、ユーザが使用するデッキとして特定する。

第２実施形態のゲームでは、２人のユーザが繰り返し対戦し、２人のユーザのうち勝利した方が対戦で使用したレジェンドが次の対戦で選択されることが制限される。制限とは、例えば、レジェンドを選択できないようにすることであり、レジェンドをゲームで使用できないようにすることである。例えば、ゲーム実行部３０３は、各ラウンドでのユーザの対戦結果を取得し、勝利した方のユーザが使用したレジェンドが次のラウンドで使用できないようにする。例えば、ゲーム実行部３０３は、レジェンドに対応するデッキが次のラウンドで使用できないようにする。

なお、第２実施形態のゲームでは、ユーザ同士が対戦し、各ユーザの複数のレジェンドのうち、対戦相手により選択されたレジェンドが当該ユーザによって選択されることが制限されるようにしてもよい。ゲーム実行部３０３は、対戦相手が選択したレジェンドを、ゲーム端末１０から取得してもよいし、管理者端末５０から取得してもよい。ゲーム実行部３０３は、対戦相手のレジェンドの中から各ユーザが指定したレジェンドを特定し、当該レジェンドが次のラウンドで使用できないようにする。例えば、ゲーム実行部３０３は、レジェンドに対応するデッキが次のラウンドで使用できないようにする。

第２実施形態のゲームシステムＳによれば、各ユーザが複数のレジェンドを使用可能になるので、ゲームで使用するゲームオブジェクトに多様性を持たせることができる。更に、ユーザはレジェンドを選択すれば、ゲームで使用するデッキを選択することができるので、対戦前にデッキを入れ替えるといった手間を省くこともできる。例えば、デッキの多様性を設けようとするルール作りは難しく、３つのデッキで同じカードは３枚までしか入れられない等のルールを作成すると、制限カードなどどのデッキにも入るようなカードを各デッキに入れることができなくなり、かえってユーザのストレスとなっていた。これは、デッキの多様性を求めた結果であるが、必要以上に制限してしまうという問題があるため、レジェンドやスキルを異ならせるだけで対応するデッキは必然的に決まり、各デッキに汎用的に使えるようなカードはそれぞれに入れることができるようになる。このことによって、ユーザのストレスなくデッキの多様性を生むことができる。

また、対戦で勝利したユーザは当該対戦で使用したレジェンドやデッキを使用できなくなるので、レジェンドやデッキの使用に制限がかかるので、ゲームの興趣性を向上させることができる。例えば、多様性のあるデッキを複数用意しても、ユーザがその中の１つのデッキしか選ばないのであれば、多様性のあるデッキを用意した意味がなくなってしまう。そこで、ユーザが勝利した場合は、そのデッキを使えなくさせることによって、多様性のあるデッキを使わせることができる。しかも、ユーザが負けた場合は、何度も使うことができる。例えば、ユーザの中で最強と思われるデッキが使えなくなることによって、負けた人が負け続けるといったことを防止することができ、ユーザのモチベーション低下を防ぐこともできる。

また、対戦相手が選択したレジェンドやデッキが使用できなくなり、レジェンドやデッキの選択に制限がかかるので、ゲームの興趣性を向上させることができる。例えば、ゲームでは、全方向に強いデッキというものを作らせないようにしているが、思いもよらない組合せで、全方向に強いというデッキが作れてしまう場合がある。また、昨今の情報の伝搬の速さから、強いと言われているデッキに全ユーザが偏ってしまう可能性もある。その結果、対戦するデッキがすべて同じものとなってしまい、ユーザの対戦意欲が減退してしまうという問題がある。そこで、対戦前にレジェンドに対応するキャラクタやキャラクタに対応するスキルを使用させないことにより、対戦するデッキに多様性を持たせることができる。

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

例えば、実施形態では、サーバ３０においてゲームの主な処理が実行され、サーバ３０が本発明に係るゲーム制御装置に相当する場合を説明したが、サーバ３０において実現される各機能は、ゲーム端末１０において実現されてもよい。例えば、ゲーム端末１０において、ゲームの主な処理が実行されるようにしてもよい。この場合、ゲーム端末１０が本発明に係るゲーム制御装置に相当する。

例えば、データ記憶部３００がゲーム端末１０で実現される場合、データ記憶部３００は記憶部１２を主として実現される。ゲーム端末１０は、対戦部屋データＤＴ１やオブジェクトデータＤＴ２を記憶してもよい。また例えば、対戦部屋生成部３０１、識別情報生成部３０２、ゲーム実行部３０３、及びデータ取得部３０４がゲーム端末１０で実現されてもよい。この場合、これら各機能は制御部１１を主として実現される。ゲーム端末１０は、ユーザから所定の操作を受け付けると対戦部屋を生成し、実施形態で説明した方法と同様にして複数の識別情報を生成する。また、ゲーム端末１０は、ユーザの操作を取得してゲームプログラムを実行し、データ記憶部３００に記憶された対戦部屋データＤＴ１やオブジェクトデータＤＴ２を取得する。

また例えば、ゲーム端末１０とサーバ３０とで各機能が分担されてもよい。この場合、ゲーム端末１０とサーバ３０とで処理結果を送受信すればよい。例えば、ゲーム端末１０において対戦部屋生成部３０１が実現され、サーバ３０において識別情報生成部３０２が実現されてもよい。これとは逆に、サーバ３０において対戦部屋生成部３０１が実現され、ゲーム端末１０において識別情報生成部３０２が実現されてもよい。また例えば、実施形態や上記変形例で説明した各機能のうち、対戦部屋生成部３０１と識別情報生成部３０２以外の機能は省略してもよい。

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

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

１）本発明の一態様に係るゲームシステム（Ｓ）は、複数のユーザがゲームをプレイするために用いるグループの生成要求を受け付ける受付手段と、前記生成要求が受け付けられた場合に、前記グループを識別可能な複数の識別情報を生成する識別情報生成手段（３０１）と、前記複数の識別情報をデータベースに格納することによって、前記グループを生成するグループ生成手段（３０２）と、を含み、前記複数の識別情報には、それぞれ互いに異なる機能が対応付けられている。

１２）本発明の一態様に係るゲーム制御装置（１０，３０）は、複数のユーザがゲームをプレイするために用いるグループの生成要求を受け付ける受付手段と、前記生成要求が受け付けられた場合に、前記グループを識別可能な複数の識別情報を生成する識別情報生成手段（３０１）と、前記複数の識別情報をデータベースに格納することによって、前記グループを生成するグループ生成手段（３０２）と、を含み、前記複数の識別情報には、それぞれ互いに異なる機能が対応付けられている。

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

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

１）又は１２）〜１４）に係る発明によれば、生成要求が受け付けられた場合に、グループに関連付けられる複数の識別情報が生成され、複数の識別情報にはそれぞれ互いに異なる機能が対応付けられているので、ゲームにおけるユーザの満足度を高めることができる。例えば、ユーザに対して何らかの機能が提供されることで、ゲームを見ることすらできないといったことを防止することができる。

２）本発明の一態様では、各識別情報に対応付けられた機能の何れか１つは、前記ゲームのプレイを観戦するための観戦機能である。２）の態様によれば、ユーザがゲームを観戦することができるので、ゲームを観戦することすらできず不満を感じるといったことを防止することができる。

３）本発明の一態様では、各識別情報に対応付けられた機能の何れか１つは、他のユーザと対戦するための対戦機能である。３）の態様によれば、ユーザが他のユーザと対戦することができるので、ゲームをプレイすることすらできず不満を感じるといったことを防止することができる。

４）本発明の一態様では、各識別情報に対応付けられた機能の何れか１つは、他のユーザと協力して対戦するための協力機能である。４）の態様によれば、ユーザが他のユーザと協力することができるので、ゲームをプレイすることすらできず不満を感じるといったことを防止することができる。

５）本発明の一態様では、前記ゲームは、前記複数のユーザでプレイされる第１ゲームパートと、第２ゲームパートと、を含み、各識別情報に対応付けられた機能は、前記第１ゲームパートに関する機能であり、各ユーザは、前記複数の識別情報の何れか１つと関連付けられ、自身と関連付けられた識別情報に対応する機能を利用可能であり、前記複数の識別情報には、ユーザが前記第２ゲームパートをプレイしても関連付けが維持される識別情報と、ユーザが前記第２ゲームパートをプレイした場合に関連付けが解除される識別情報と、が含まれる。５）の態様によれば、第２ゲームパートをプレイしても関連付けが維持される識別情報があるので、第２ゲームパートをプレイした後に、再び識別情報との関連付けをし直さなければならないといった煩雑さを防止することができる。また、第２ゲームパートをプレイした場合に関連付けが解除される識別情報については、ユーザがずっと識別情報と関連付けられているといった状態を防止することができる。

６）本発明の一態様では、前記グループには、複数のサブグループが設定されており、各識別情報に対応付けられた機能の何れか１つは、前記サブグループごとに、当該サブグループに所属する複数のユーザが前記ゲームをプレイするための機能である。６）の態様によれば、サブグループごとに、当該サブグループに所属するユーザ同士でゲームがプレイされるので、好きなユーザ同士でゲームをプレイさせることができる。

７）本発明の一態様では、前記ゲームは、前記複数のユーザでプレイされる第１ゲームパートと、第２ゲームパートと、を含み、各識別情報に対応付けられた機能は、前記第１ゲームパートに関する機能であり、前記第２ゲームパートは、前記サブグループに所属中のユーザによってプレイされることが制限される。７）の態様によれば、サブグループに所属中のユーザが第２ゲームパートをプレイすることが制限されるので、他のユーザが一緒にゲームをプレイしようと思っても、それに気づかずに第２ゲームパートをプレイしてしまうといったことを防止することができる。

８）本発明の一態様では、前記ゲームでは、２人のユーザが先攻と後攻に分かれて対戦し、各識別情報に対応付けられた機能の何れか１つは、前記サブグループごとに、当該サブグループに所属する２人のユーザの少なくとも一方が先攻と後攻を決定して前記ゲームをプレイさせるための機能である。８）の態様によれば、ユーザが先攻と後攻の好きな方を選択することができるので、対戦の興趣性を向上させることができる。

９）本発明の一態様では、前記ゲームシステムは、前記ユーザごとに、前記ゲームで使用可能な第１ゲームオブジェクトと、前記ゲーム内で前記第１ゲームオブジェクトを使用する第２ゲームオブジェクトと、の組み合わせが複数格納されたデータを取得するデータ取得手段（３０４）を更に含み、前記ゲームでは、各ユーザの複数の前記第２ゲームオブジェクトのうち、当該ユーザにより選択された第２ゲームオブジェクトに対応する第１ゲームオブジェクトが使用される。９）の態様によれば、各ユーザが複数のゲームオブジェクトを使用可能になるので、ゲームで使用するゲームオブジェクトに多様性を持たせることができる。更に、ユーザは第２ゲームオブジェクトを選択すれば、ゲームで使用する第１ゲームオブジェクトを選択することができるので、対戦前に第１ゲームオブジェクトを入れ替えるといった手間を省くこともできる。

１０）本発明の一態様では、前記ゲームでは、２人のユーザが繰り返し対戦し、前記２人のユーザのうち勝利した方が対戦で使用した第２ゲームオブジェクトが次の対戦で選択されることが制限される。１０）の態様によれば、ゲームオブジェクトの使用に制限がかかるので、ゲームの興趣性を向上させることができる。

１１）本発明の一態様では、前記ゲームでは、ユーザ同士が対戦し、各ユーザの前記複数の第２ゲームオブジェクトのうち、対戦相手により選択された前記第２ゲームオブジェクトが当該ユーザによって選択されることが制限される。１１）の態様によれば、ゲームオブジェクトの選択に制限がかかるので、ゲームの興趣性を向上させることができる。

Ｓゲームシステム、Ｎネットワーク、１０ゲーム端末、３０サーバ、５０管理者端末、１１，３１，５１制御部、１２，３２，５２記憶部、１３，３３，５３通信部、１４，５４操作部、１５，５５表示部、Ｇ１対戦モード選択画像、Ｇ２対戦部屋モード画像、Ｇ３対戦部屋画像、Ｇ４観戦画像、Ｇ５管理ツール画像、３００データ記憶部、３０１対戦部屋生成部、３０２識別情報生成部、３０３ゲーム実行部、３０４データ取得部、Ａ３０，Ａ３１，Ａ３２，Ａ３３表示領域、Ｂ１０ランク戦ボタン、Ｂ１１フリー対戦ボタン、Ｂ１２フレンド対戦ボタン、Ｂ１３対戦部屋ボタン、Ｂ２０対戦部屋生成ボタン、Ｂ２１メンバ入室ボタン、Ｂ２２観戦ユーザ入室ボタン、Ｂ３４メンバボタン、Ｂ３５戦績ボタン、Ｂ３６コメントボタン、Ｂ３７退室ボタン、Ｂ３８，Ｂ３８Ａ，Ｂ３８Ｂ，Ｂ３８Ｃテーブル選択ボタン、Ｂ４０，Ｂ４０Ａ，Ｂ４０Ｂ，Ｂ４０Ｃテーブル選択ボタン、Ｂ５２ラウンド進行ボタン、Ｄ２３，Ｄ２４，Ｄ２５ダイアログ、ＤＴ１対戦部屋データ、ＤＴ２オブジェクトデータ、Ｂ２３２，Ｂ２３３ラジオボタン、Ｂ２３４キャンセルボタン、Ｂ２３５，Ｂ２４１，Ｂ２５１決定ボタン、Ｆ５０，Ｆ５１，Ｆ５２，Ｆ５３，Ｆ５４，Ｆ５５，Ｆ２３０，Ｆ２３１，Ｆ２４０，Ｆ２５０入力フォーム。

Claims

複数のユーザでプレイされる第１ゲームパートと、第２ゲームパートと、を含むゲームの前記第１ゲームパートを前記複数のユーザがプレイするために用いるグループの生成要求を受け付ける受付手段と、
前記生成要求が受け付けられた場合に、前記グループを識別可能な複数の識別情報を、互いに重複しないように、かつ、他のグループの識別情報と重複しないように生成する識別情報生成手段と、
前記複数の識別情報をデータベースに格納することによって、前記グループを生成するグループ生成手段と、
前記複数の識別情報のうちの第１の識別情報を伴う要求が受け付けられた場合に、第１の機能を許可する第１許可手段と、
前記複数の識別情報のうちの第２の識別情報を伴う要求が受け付けられた場合に、前記第１の機能とは異なる第２の機能を許可する第２許可手段と、
を含み、
各識別情報に対応付けられた機能は、前記第１ゲームパートに関する機能であり、
各ユーザは、前記複数の識別情報の何れか１つと関連付けられ、自身と関連付けられた識別情報に対応する機能を利用可能であり、
前記複数の識別情報のうちの少なくとも１つの識別情報は、ユーザが前記第２ゲームパートをプレイしても関連付けが維持されるものであり、前記複数の識別情報のうちの他の識別情報は、ユーザが前記第２ゲームパートをプレイした場合に関連付けが解除されるものである、
ゲームシステム。
各識別情報に対応付けられた機能の何れか１つは、前記ゲームのプレイを観戦するための観戦機能である、
請求項１記載のゲームシステム。
各識別情報に対応付けられた機能の何れか１つは、他のユーザと対戦するための対戦機能である、
請求項１又は２に記載のゲームシステム。
各識別情報に対応付けられた機能の何れか１つは、他のユーザと協力して対戦するための協力機能である、
請求項１〜３の何れか１項に記載のゲームシステム。
前記グループには、少なくとも１つのサブグループが設定されており、
各識別情報に対応付けられた機能の何れか１つは、前記サブグループごとに、当該サブグループに所属する複数のユーザが前記ゲームをプレイするための機能である、
請求項１〜４の何れか１項に記載のゲームシステム。
前記第２ゲームパートは、前記サブグループに所属中のユーザが前記サブグループへの所属を解除しなければプレイできないように制限される、
請求項５に記載のゲームシステム。
前記ゲームでは、２人のユーザが先攻と後攻に分かれて対戦し、
各識別情報に対応付けられた機能の何れか１つは、前記サブグループごとに、当該サブグループに所属する２人のユーザの少なくとも一方が先攻と後攻を決定して前記ゲームをプレイさせるための機能である、
請求項５又は６に記載のゲームシステム。
前記ゲームシステムは、前記複数のユーザの各々に関連付けて、前記ゲームで使用可能な第１ゲームオブジェクトと、前記ゲーム内で前記第１ゲームオブジェクトを使用する第２ゲームオブジェクトと、の組み合わせが複数格納されたデータを取得するデータ取得手段を更に含み、
前記ゲームでは、各ユーザの複数の前記第２ゲームオブジェクトのうち、選択された第２ゲームオブジェクトに対応する第１ゲームオブジェクトが使用される、
請求項１〜７の何れか１項に記載のゲームシステム。
前記ゲームでは、２人のユーザが繰り返し対戦し、前記２人のユーザのうち勝利した方が対戦で使用した第２ゲームオブジェクトが次の対戦で選択されることが制限される、
請求項８に記載のゲームシステム。
前記ゲームでは、ユーザ同士が対戦し、各ユーザの複数の前記第２ゲームオブジェクトのうち、対戦相手により選択された前記第２ゲームオブジェクトが選択されることが制限される、
請求項８又は９に記載のゲームシステム。
複数のユーザでプレイされる第１ゲームパートと、第２ゲームパートと、を含むゲームの前記第１ゲームパートを前記複数のユーザがプレイするために用いるグループの生成要求を受け付ける受付手段と、
前記生成要求が受け付けられた場合に、前記グループを識別可能な複数の識別情報を、互いに重複しないように、かつ、他のグループの識別情報と重複しないように生成する識別情報生成手段と、
前記複数の識別情報をデータベースに格納することによって、前記グループを生成するグループ生成手段と、
前記複数の識別情報のうちの第１の識別情報を伴う要求が受け付けられた場合に、第１の機能を許可する第１許可手段と、
前記複数の識別情報のうちの第２の識別情報を伴う要求が受け付けられた場合に、前記第１の機能とは異なる第２の機能を許可する第２許可手段と、
を含み、
各識別情報に対応付けられた機能は、前記第１ゲームパートに関する機能であり、
各ユーザは、前記複数の識別情報の何れか１つと関連付けられ、自身と関連付けられた識別情報に対応する機能を利用可能であり、
前記複数の識別情報のうちの少なくとも１つの識別情報は、ユーザが前記第２ゲームパートをプレイしても関連付けが維持されるものであり、前記複数の識別情報のうちの他の識別情報は、ユーザが前記第２ゲームパートをプレイした場合に関連付けが解除されるものである、
ゲーム制御装置。
請求項１〜１０の何れか１項に記載のゲームシステム、又は、請求項１１に記載のゲーム制御装置、としてコンピュータを機能させるためのプログラム。