(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-06-03
(45)【発行日】2024-06-11
(54)【発明の名称】ゲームシステム、ゲーム制御装置、及びプログラム
(51)【国際特許分類】
A63F 13/795 20140101AFI20240604BHJP
A63F 13/80 20140101ALI20240604BHJP
A63F 13/847 20140101ALI20240604BHJP
A63F 13/86 20140101ALI20240604BHJP
【FI】
A63F13/795
A63F13/80 B
A63F13/847
A63F13/86
(21)【出願番号】P 2019085850
(22)【出願日】2019-04-26
(62)【分割の表示】P 2017201080の分割
【原出願日】2017-10-17
【審査請求日】2020-10-13
【審判番号】
【審判請求日】2023-02-24
【新規性喪失の例外の表示】特許法第30条第2項適用 平成29年4月27日、https://itunes.apple.com/、https://itunes.apple.com/app/id1068378177/、https://play.google.com/、https://play.google.com/store/apps/details?id=jp.konami.duellinks、https://www.konami.com/、https://www.konami.com/yugioh/duel_links/ 平成29年5月24日、https://itunes.apple.com/、https://itunes.apple.com/app/id1068378177/、https://play.google.com/、https://play.google.com/store/apps/details?id=jp.konami.duellinks、https://www.konami.com/、https://www.konami.com/yugioh/duel_links/
(73)【特許権者】
【識別番号】506113602
【氏名又は名称】株式会社コナミデジタルエンタテインメント
(74)【代理人】
【識別番号】110000154
【氏名又は名称】弁理士法人はるか国際特許事務所
(72)【発明者】
【氏名】米山 実
【合議体】
【審判長】藤本 義仁
【審判官】門 良成
【審判官】殿川 雅也
(56)【参考文献】
【文献】特開2016-13384(JP,A)
【文献】特開2013-251816(JP,A)
【文献】特開2002-259766(JP,A)
【文献】[遊戯王デュエルリンクス]「デュエルゲーム」の遊び方-ゲームウィズ(GameWith),ゲームウィズ(GameWith)[ONLINE],日本,2017年4月28日,https://gamewith.jp/duellinks/article/show/55865,2020年12月22日検索インターネット
【文献】クイズRPG 魔法使いと黒猫のウィズ,ファミ通App Android NO.019,株式会社KADOKAWA,2014年12月4日,pp.82-83
【文献】SOCOM II:U.S.NAVY SEALs SOFTWARE MANUAL,株式会社ソニー・コンピュータエンタテインメント,2004年9月12日,pp.30-34
(58)【調査した分野】(Int.Cl.,DB名)
A63F 9/24
A63F 13/00-13/98
(57)【特許請求の範囲】
【請求項1】
複数のユーザがゲームをプレイするために用いるグループの生成要求を受け付ける受付手段と、
前記生成要求が受け付けられた場合に、前記グループを識別可能な複数の識別情報を、互いに重複しないように、かつ、他のグループの識別情報と重複しないように生成する識別情報生成手段と、
前記複数の識別情報をデータベースに格納することによって、前記グループを生成するグループ生成手段と、
前記複数の識別情報のうちの第1の識別情報を伴う要求が受け付けられた場合に、第1の機能を許可する第1許可手段と、
前記複数の識別情報のうちの第2の識別情報を伴う要求が受け付けられた場合に、前記第1の機能とは異なる第2の機能を許可する第2許可手段と、
を含むゲームシステム。
【請求項2】
前記第1の識別情報は、前記第1の機能が許可される前記グループを識別可能な第1のIDであり、
前記第2の識別情報は、前記第2の機能が許可される前記グループを識別可能な第2のIDである、
請求項1に記載のゲームシステム。
【請求項3】
前記グループは、対戦部屋であり、
前記第1のIDは、前記第1の機能が許可される前記対戦部屋を識別可能なIDであり、
前記第2のIDは、前記第2の機能が許可される前記対戦部屋を識別可能なIDである、
請求項2に記載のゲームシステム。
【請求項4】
前記要求をするための画面では、前記第1の識別情報又は前記第2の識別情報以外の識別情報の入力は行われない、
請求項1~
3の何れかに記載のゲームシステム。
【請求項5】
前記第1の識別情報と前記第2の識別情報の各々は、前記データベースのレコードを一意に識別可能な情報である、
請求項1~
4の何れかに記載のゲームシステム。
【請求項6】
複数のユーザがゲームをプレイするために用いるグループの生成要求を受け付ける受付手段と、
前記生成要求が受け付けられた場合に、前記グループを識別可能な複数の識別情報を、互いに重複しないように、かつ、他のグループの識別情報と重複しないように生成する識別情報生成手段と、
前記複数の識別情報をデータベースに格納することによって、前記グループを生成するグループ生成手段と、
前記複数の識別情報のうちの第1の識別情報を伴う要求が受け付けられた場合に、第1の機能を許可する第1許可手段と、
前記複数の識別情報のうちの第2の識別情報を伴う要求が受け付けられた場合に、前記第1の機能とは異なる第2の機能を許可する第2許可手段と、
を含むゲーム制御装置。
【請求項7】
請求項1~
5の何れか1項に記載のゲームシステム、又は、請求項
6に記載のゲーム制御装置、としてコンピュータを機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ゲームシステム、ゲーム制御装置、及びプログラムに関する。
【背景技術】
【0002】
従来、対戦部屋やロビーなどのグループを生成し、複数のユーザにゲームをプレイさせるゲームシステムが知られている。例えば、特許文献1には、ユーザが生成した対戦部屋に他のユーザを入室させ、対戦部屋に入室した複数のユーザがゲームをプレイすることが記載されている。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、特許文献1の技術では、ユーザが生成した対戦部屋に意図しない他のユーザが入室してしまうことがあった。この点、限られたユーザしか入室できないように対戦部屋に制限をかけることも考えられるが、この場合、他のユーザは、対戦部屋の中で実行されるゲームに何ら関与できないので不満に感じる可能性がある。
【0005】
本発明は上記課題に鑑みてなされたものであって、その目的は、対戦部屋の中で実行されるゲームに他のユーザが適切に関与することが可能なゲームシステム、ゲーム制御装置、及びプログラムを提供することである。
【課題を解決するための手段】
【0006】
上記課題を解決するために、本発明の一態様に係るゲームシステムは、複数のユーザがゲームをプレイするために用いるグループを生成するグループ生成手段と、前記グループが生成された場合に、当該グループに関連付けられる複数の識別情報を生成する識別情報生成手段と、を含み、前記複数の識別情報には、それぞれ互いに異なる機能が対応付けられている。
【0007】
本発明の一態様に係るゲーム制御装置は、複数のユーザがゲームをプレイするために用いるグループを生成するグループ生成手段と、前記グループが生成された場合に、当該グループに関連付けられる複数の識別情報を生成する識別情報生成手段と、を含み、前記複数の識別情報には、それぞれ互いに異なる機能が対応付けられている。
【図面の簡単な説明】
【0008】
【
図4】対戦部屋生成ボタンが選択された場合の対戦部屋モード画像の一例を示す図である。
【
図6】対戦部屋モード画像から部屋IDが入力される様子を示す図である。
【
図7】第1ユーザと第2ユーザがテーブルにエントリーする様子を示す図である。
【
図8】第1ユーザと第2ユーザとが対戦する様子を示す図である。
【
図9】対戦部屋モード画像から観戦IDが入力される様子を示す図である。
【
図11】観戦ユーザが対戦を観戦している様子を示す図である。
【
図12】ゲームシステムで実現される機能のうち、本発明に関連する機能を示す機能ブロック図である。
【
図13】対戦部屋データのデータ格納例を示す図である。
【
図14】ゲームシステムにおいて実行される処理の一例を示すフロー図である。
【
図15】ゲームシステムにおいて実行される処理の一例を示すフロー図である。
【
図16】第2実施形態のゲームシステムの全体構成を示す図である。
【
図17】大会会場内でユーザ同士が対戦する様子を示す図である。
【
図18】ゲーム大会の1日目における進行手順を示す図である。
【
図19】ゲーム大会の1日目における進行手順を示す図である。
【
図20】ゲーム大会の1日目における進行手順を示す図である。
【
図21】ゲーム大会の1日目における進行手順を示す図である。
【
図23】管理ツールからレジェンドカードが登録される様子を示す図である。
【
図24】管理ツールから対戦結果が登録される様子を示す図である。
【
図26】オブジェクトデータの一例を示す図である。
【発明を実施するための形態】
【0009】
[1.ゲームシステムの全体構成]
以下、本発明に係る第1実施形態を図面に基づいて説明する。図面において同一又は対応する構成には同一の符号を付し、繰り返しの説明を省略することがある。
【0010】
図1は、ゲームシステムの全体構成を示す図である。
図1に示すように、本実施形態に係るゲームシステムSは、第1ゲーム端末10A、第2ゲーム端末10B、第3ゲーム端末10C、及びサーバ30を含む。第1ゲーム端末10A、第2ゲーム端末10B、第3ゲーム端末10C、及びサーバ30の各々は、インターネットなどのネットワークNに接続される。このため、ゲーム端末10とサーバ30との間で相互にデータ通信が可能である。
【0011】
なお、本実施形態では、第1ゲーム端末10A、第2ゲーム端末10B、及び第3ゲーム端末10Cを特に区別する必要のないときは、単にゲーム端末10と記載する。また、ゲーム端末10が3台である場合を説明するが、ゲームシステムS内のゲーム端末10の台数に制限はなく、2台であってもよいし4台以上であってもよい。同様に、ゲームシステムS内のサーバ30の台数に制限はなく、2台以上のサーバ30が存在していてもよいし、サーバ30以外のコンピュータがゲームシステムSに含まれていてもよい。
【0012】
ゲーム端末10は、ユーザが操作するコンピュータである。例えば、ゲーム端末10は、携帯端末(例えば、スマートフォンなどの携帯電話又はタブレット型コンピュータ)、パーソナルコンピュータ、携帯ゲーム機、据置ゲーム機、業務用ゲーム機、又は、情報処理機能を備えた多機能型テレビジョン受像機(スマートテレビ)等である。
【0013】
図1に示すように、ゲーム端末10は、制御部11、記憶部12、通信部13、操作部14、及び表示部15を含む。制御部11は、少なくとも1つのマイクロプロセッサを含む。例えば、制御部11は、複数のマイクロプロセッサを含んでもよい。制御部11は、オペレーティングシステムやその他のプログラムに従って処理を実行する。記憶部12は、主記憶部(例えば、RAM)及び補助記憶部(例えば、不揮発性の半導体メモリ)を含む。記憶部12は、プログラムやデータを記憶する。なお、例えば、ゲーム端末10がパーソナルコンピュータ等である場合、記憶部12は、例えばハードディスクドライブ又はソリッドステートドライブ等の補助記憶部を含むようにしてもよい。通信部13は、通信モジュールや通信インタフェースを含む。通信部13は、ネットワークNを介してデータ通信を行う。
【0014】
操作部14は、入力デバイスであり、例えば、キー、レバー、ゲームコントローラ(ゲームパッド)、マウスやタッチパネルなどのポインティングデバイス、又はキーボード等を含んでもよい。また例えば、操作部14は、ユーザが音声又はジェスチャによって入力操作を行うためのマイクやカメラを含んでもよい。表示部15は、例えば、液晶表示パネル又は有機ELディスプレイ等であり、制御部11の指示に従って画面を表示する。なお、操作部14及び表示部15は、ゲーム端末10に内蔵されていなくともよく、ゲーム端末10に接続された外部装置であってもよい。
【0015】
サーバ30は、サーバコンピュータである。
図1に示すように、サーバ30は、制御部31、記憶部32、及び通信部33を含む。制御部31、記憶部32、及び通信部33のハードウェア構成は、それぞれ制御部11、記憶部12、及び通信部13と同様であってよい。例えば、サーバ30は、ゲームプログラムを記憶しており、ゲーム端末10からの要求に応じてゲームプログラムを配信する。
【0016】
なお、記憶部12又は記憶部32に記憶されるものとして説明するプログラムやデータは、例えば、ネットワークNを介してゲーム端末10又はサーバ30に供給されるようにしてもよい。また、ゲーム端末10又はサーバ30は、情報記憶媒体(例えば、光ディスク又はメモリカード等)に記憶されたプログラム又はデータを読み取るための読取部(例えば、光ディスクドライブ又はメモリカードスロット)を含むようにしてもよい。そして、情報記憶媒体を介してゲーム端末10又はサーバ30にプログラムやデータが供給されるようにしてもよい。
【0017】
[2.ゲームの概要]
ゲームシステムSでは、複数のユーザがプレイするゲームが実行される。複数のユーザがプレイするゲームとは、例えば、複数のユーザが参加するゲーム、複数のユーザが互いに対戦するゲーム、複数のユーザが協力して対戦相手(コンピュータ又は他のユーザ)と対戦するゲーム、複数のユーザの各々がゲームをプレイして他のユーザとスコアなどを競うゲームなどである。ゲームシステムSでは、複数のユーザがゲームをプレイするために用いるグループが生成される。
【0018】
グループとは、例えば、複数のユーザをメンバ(参加者)として含むグループである。例えば、同じグループに所属する複数のユーザは、ゲームの優劣(順位又は勝敗)を競い合う複数のユーザといえる。また例えば、グループは、他のユーザと対戦するゲームをプレイすることを希望するユーザ、又は、他のユーザと協力して目標の達成を目指すゲームをプレイすることを希望するユーザが集うべきものであってもよい。別の言い方をすれば、グループは、例えば、ゲームへの参加を宣言するためのものであってもよい。例えば、グループは、ゲームの中の世界に存在する物体を示すものであってもよい。また例えば、グループは、ゲーム内に設定された部屋・ロビーと呼ばれるものであってもよいし、仮想世界の中に設定された所定の場所であってもよいし、フレンドやギルドといった他の名前で呼ばれるものであってもよい。本実施形態では、グループに、複数のサブグループが設定されている場合を説明するが、特にサブグループがなくてもよい。
【0019】
サブグループとは、例えば、グループ内に設定された別のグループである。例えば、サブグループは、グループよりも小さい単位であり、グループに所属するユーザの一部が所属するものである。例えば、グループが部屋やロビーであれば、その中に配置されたテーブルや椅子などである。また例えば、グループが仮想世界の中の場所であれば、その場所に配置されたテーブルや椅子などである。また例えば、グループがフレンドやギルドといったものであれば、その中に設定された小さな仲間グループのことである。
【0020】
本実施形態では、ゲームの一例として、複数のユーザがゲームカードを使用して対戦するカードゲームを説明する。また、グループの一例として対戦部屋を説明し、サブグループの一例として対戦部屋内のテーブルを説明する。このため、本実施形態で対戦部屋と記載した箇所は、グループと読み替えることができ、テーブルと記載した箇所は、サブグループと読み替えることができる。例えば、ゲームシステムSでは、複数の対戦モードが用意されており、ユーザがゲームプログラムを起動させると、プレイする対戦モードを選択するための対戦モード選択画面が表示部15に表示される。
【0021】
図2は、対戦モード選択画像の一例を示す図である。
図2に示すように、対戦モード選択画像G1では、複数の対戦モードの中からプレイする対戦モードを選択可能となっている。例えば、ランク戦ボタンB10は、一定期間内の戦績に基づいて複数のユーザがランキングを競うランク戦モードをプレイするための画像である。また例えば、フリー対戦ボタンB11は、特にランキング等に影響せず、複数のユーザが自由に対戦するフリー対戦モードをプレイするための画像である。また例えば、フレンド対戦ボタンB12は、互いに友人関係にある複数のユーザが対戦するフレンド対戦モードをプレイするための画像である。また例えば、対戦部屋ボタンB13は、対戦部屋に入室した複数のユーザが対戦する対戦部屋モードをプレイするための画像である。
【0022】
本実施形態では、主に、対戦部屋モードについて説明する。対戦部屋モードでは、ユーザは、自分が生成した対戦部屋に他のユーザを招待したり、他のユーザが生成した対戦部屋に入室したりすることによって、他のユーザと対戦することができる。ユーザが対戦部屋ボタンB13を選択すると、対戦部屋モードをプレイするための対戦部屋モード画像がゲーム端末10に表示される。
【0023】
図3は、対戦部屋モード画像の一例を示す図である。
図3に示すように、対戦部屋モード画像G2には、対戦部屋を生成するための対戦部屋生成ボタンB20、メンバとして対戦部屋に入室するためのメンバ入室ボタンB21、及び観戦ユーザとして対戦部屋に入室するための観戦ユーザ入室ボタンB22が表示される。
【0024】
以降、第1ゲーム端末10Aを操作する第1ユーザが対戦部屋を生成し、第2ゲーム端末10Bを操作する第2ユーザがメンバとして当該対戦部屋に入室し、第3ゲーム端末10Cを操作する第3ユーザが観戦ユーザとして当該対戦部屋に入室する場合を一例として説明する。第1ユーザが対戦部屋生成ボタンB20を選択すると、対戦部屋を生成するためのダイアログが対戦部屋モード画像G2に表示される。
【0025】
図4は、対戦部屋生成ボタンB20が選択された場合の対戦部屋モード画像G2の一例を示す図である。
図4に示すように、対戦部屋モード画像G2には、対戦部屋に関する各種設定をするためのダイアログD23が表示される。例えば、対戦部屋の名前を入力するための入力フォームF230が、ダイアログD23に表示される。また例えば、対戦部屋に入室可能なユーザの上限数を入力するための入力フォームF231が、ダイアログD23に表示される。
【0026】
また例えば、対戦部屋を観戦するための観戦機能を有効にするか無効にするかを入力するためのラジオボタンB232が、ダイアログD23に表示される。また例えば、対戦部屋を生成する第1ユーザがメンバとして対戦に参加するか否かを入力するためのラジオボタンB233が、ダイアログD23に表示される。なお、第1ユーザがキャンセルボタンB234を選択すると、対戦部屋が生成されることなくダイアログD23が消去される。
【0027】
第1ユーザが決定ボタンB235を選択すると、ダイアログD23に対する入力内容に基づいて、新たな対戦部屋が生成される。例えば、入力フォームF230に入力された名前の対戦部屋が生成され、入力フォームF231に入力された人数が上限数として設定される。また例えば、ラジオボタンB232で観戦機能をオンにした場合には、対戦部屋内でのゲームの観戦ができるようになる。一方、ラジオボタンB232で観戦機能をオフにした場合には、対戦部屋内でのゲームの観戦ができないようになる。
【0028】
また例えば、ラジオボタンB233でメンバとして参加することが選択された場合には、第1ユーザがメンバとして対戦部屋に入室して他のユーザ(例えば、第2ユーザ)と対戦可能となる。一方、ラジオボタンB233でメンバとして参加しないことが選択された場合には、第1ユーザはメンバとして対戦部屋に入室できず、他のユーザと対戦できないようになる。なお、第1ユーザは、生成した対戦部屋を管理するオーナユーザとしての権限を持ち、例えば、他のユーザを対戦部屋に招待したり、対戦部屋に関する設定変更をしたりすることが可能となる。
【0029】
ここでは、第1ユーザが、ラジオボタンB232において観戦機能をオンにし、ラジオボタンB233においてメンバとして参加することを選択した場合を説明する。この場合、決定ボタンB235が選択されて対戦部屋が生成されると、第1ユーザは対戦部屋にメンバとして入室した状態となり、対戦部屋の様子を示す対戦部屋画像が表示部15に表示される。
【0030】
図5は、対戦部屋画像の一例を示す図である。
図5に示すように、対戦部屋画像G3は、例えば、入室中の対戦部屋の名前を表示するための表示領域A30を含む。また例えば、対戦部屋画像G3は、メンバとして入室中のユーザ数、入室可能なユーザの上限数、及び観戦ユーザとして入室中のユーザ数を表示するための表示領域A31を含む。
【0031】
本実施形態では、決定ボタンB235が選択された場合に、対戦部屋を識別するためのIDが2つ生成される。例えば、これら2つのIDのうちの一方は、対戦部屋にメンバとして入室するための部屋IDであり、他方は、対戦部屋に観戦ユーザとして入室するための観戦IDである。例えば、表示領域A32には部屋IDが表示され、表示領域A33には観戦IDが表示される。
【0032】
また例えば、対戦部屋画像G3には、メンバとして入室中のユーザのリストを表示するためのメンバボタンB34、対戦部屋内での戦績を表示するための戦績ボタンB35、メンバ又は観戦ユーザが残したコメントを表示するためのコメントボタンB36、対戦部屋から退室するための退室ボタンB37、及び対戦部屋内に設けられたテーブルを選択するためのテーブル選択ボタンB38A~B38Cが表示される。なお、本実施形態では、ユーザは、退室ボタンB37を選択して対戦部屋から退室しなくても、他の対戦モードをプレイすることができ、対戦以外のゲームパート(例えば、ユーザが1人で遊ぶクエストなど)をプレイすることもできるようになっている。
【0033】
以降では、テーブル選択ボタンB38A~B38Cを特に区別する必要のないときは、単にテーブル選択ボタンB38と記載する。また、
図5では、3つのテーブルを選択可能となっているが、対戦部屋内に設定されるテーブルの数は、任意の数であってよく、例えば、1つ、2つ、又は4つ以上であってもよい。
【0034】
図5の対戦部屋画像G3は、対戦部屋が生成されたばかりの状態を示しており、第1ユーザ以外のユーザは、誰も入室していない状態となっている。第1ユーザは、表示領域A32に表示された部屋IDを、メンバとして招待したい他のユーザ(ここでは、第2ユーザ)に通知し、表示領域A33に表示された観戦IDを、観戦ユーザとして招待したい他のユーザ(ここでは、第3ユーザ)に通知し、他のユーザを対戦部屋に招待する。
【0035】
なお、部屋IDと観戦IDの通知方法としては、公知の種々の通知媒体を利用可能であり、例えば、ゲーム内のメッセージ機能を利用してもよいし、電子メールやメッセージアプリを利用してもよいし、口頭で通知してもよい。また、第1ユーザが生成した対戦部屋は、対戦部屋を生成してから所定時間(例えば、24時間又はメンバが全員退室するまで残るようにしてもよい。
【0036】
第2ユーザは、第1ユーザの対戦部屋の部屋IDを取得すると、当該部屋IDに基づいて、第1ユーザの対戦部屋にメンバとして入室することができるようになる。例えば、第2ユーザは、第1ユーザから通知された部屋IDを対戦部屋モード画像G2から入力することで、第1ユーザの対戦部屋にメンバとして入室することができる。
【0037】
図6は、対戦部屋モード画像G2から部屋IDが入力される様子を示す図である。例えば、対戦部屋モード画像G2が第2ゲーム端末10Bに表示された状態で、第2ユーザがメンバ入室ボタンB21を選択すると、
図6に示すように、対戦部屋モード画像G2にダイアログD24が表示される。例えば、部屋IDを入力するための入力フォームF240が、ダイアログD24に表示される。
【0038】
例えば、第2ユーザが、第1ユーザの対戦部屋の部屋IDを入力フォームF240に入力して決定ボタンB241を選択すると、第1ユーザが生成した対戦部屋にメンバとして入室することができる。この場合、第1ゲーム端末10Aに表示される対戦部屋画像G3と同じ対戦部屋画像G3が表示されるようにしてもよいし、第1ゲーム端末10Aに表示される対戦部屋画像G3とは異なる対戦部屋画像G3が表示されるようにしてもよい。例えば、第2ゲーム端末10Bに表示される対戦部屋画像G3には、観戦IDが表示されないようにしてもよい。
【0039】
なお、第2ユーザが入力フォームF240から間違った部屋IDを入力すると、所定のエラーメッセージが表示され、第1ユーザの対戦部屋に入室することができない。また、もし仮に第2ユーザが入力フォームF240に部屋IDではなく観戦IDを入力しても、対戦部屋に観戦ユーザとして入室することはできない。
【0040】
第2ユーザが、第1ユーザの対戦部屋に入室すると、第1ユーザ又は当該対戦部屋に入室中の他のユーザとの対戦が可能な状態となる。ここでは、第1ユーザが既に入室済みの状態なので、第1ユーザと第2ユーザは、対戦部屋の中の同じテーブルにエントリーすることによって、対戦を開始することができる。
【0041】
図7は、第1ユーザと第2ユーザがテーブルにエントリーする様子を示す図である。
図7に示すように、誰もエントリーしていない第1テーブルのテーブル選択ボタンB38Aには、特にユーザの情報は表示されない。例えば、第1ユーザ(
図7では「AAA」という名前のユーザ)が、先にテーブル選択ボタンB38Aを選択して第1テーブルにエントリーすると、テーブル選択ボタンB38Aに第1ユーザの名前やアイコンが表示される。この状態で、第2ユーザがテーブル選択ボタンB38Aを選択すると、第1ユーザがエントリー済みの第1テーブルにエントリーすることができ、第1ユーザと第2ユーザとの対戦が開始される。
【0042】
なお、
図7では、第1テーブルが用いられる場合を説明したが、対戦部屋内の任意のテーブルが用いられるようにすればよく、第2テーブル又は第3テーブルが用いられてもよい。この場合、第1ユーザと第2ユーザは、テーブル選択ボタンB38B,B38Cを選択して第2テーブル又は第3テーブルにエントリーすることで対戦できる。また、各テーブルが2人用である場合を説明したが、テーブルは3人以上がエントリー可能であってもよい。
【0043】
図8は、第1ユーザと第2ユーザとが対戦する様子を示す図である。
図8に示すように、対戦部屋画像G3には、実行中のゲームの様子が表示される。本実施形態では、カードゲームが実行されるので、例えば、対戦部屋画像G3には、ユーザの手札の情報、ゲームカードが配置されるフィールド上の様子、及びユーザのライフポイントが表示される。
【0044】
カードゲーム自体は、公知の種々のカードゲームを適用可能なので、ゲーム内容の詳細は省略するが、例えば、各ユーザは、自身のゲームカードを使用して対戦相手を攻撃し、対戦相手のライフポイントを0にした方が勝利する。対戦が終了すると、対戦部屋画像G3は
図5の状態に戻る。なお、対戦が終了した場合に、各ユーザはテーブルから自動的に離脱してもよいし、テーブルにエントリーした状態で同じユーザと再戦できるようにしてもよい。なお、離脱とは、例えば、ユーザがテーブルにエントリーした状態からエントリーしていない状態になることである。例えば、ユーザがテーブルから離脱すると、他のテーブルにエントリーすることができる。
【0045】
一方、第3ユーザは、第1ユーザの対戦部屋の観戦IDを取得すると、当該観戦IDに基づいて、第1ユーザの対戦部屋に観戦ユーザとして入室することができるようになる。例えば、第3ユーザは、第1ユーザから通知された観戦IDを対戦部屋モード画像G2から入力することで、第1ユーザの対戦部屋に観戦ユーザとして入室することができる。
【0046】
図9は、対戦部屋モード画像G2から観戦IDが入力される様子を示す図である。例えば、対戦部屋モード画像G2が第3ゲーム端末10Cに表示された状態で、第3ユーザが観戦ユーザ入室ボタンB22を選択すると、
図9に示すように、対戦部屋モード画像G2にダイアログD25が表示される。例えば、観戦IDを入力するための入力フォームF250が、ダイアログD25に表示される。
【0047】
例えば、第3ユーザが、第1ユーザの対戦部屋の観戦IDを入力フォームF250に入力して決定ボタンB251を選択すると、第1ユーザが生成した対戦部屋に第3ユーザは観戦ユーザとして入室することができる。
【0048】
なお、実施形態では、観戦IDと部屋IDをそれぞれ別のダイアログから入力する場合を説明するが、1つのダイアログから入力されたIDに応じた権限で対戦部屋に入室できるようにしてもよい。例えば、ある1つのダイアログから複数種類のIDを入力可能とし、当該ダイアログから入力されたIDに対応する機能が提供されるようにしてもよい。この場合、ダイアログには、複数種類のIDの各々に対応する入力フォームが含まれているようにしてもよいし、入力フォームが1つだけであり、当該1つの入力フォームから複数種類のIDを入力可能としてもよい。
【0049】
また、第3ユーザが入力フォームF250から間違った観戦IDを入力すると、所定のエラーメッセージが表示され、第1ユーザの対戦部屋に入室することができない。また、もし仮に第3ユーザが入力フォームF250に観戦IDではなく部屋IDを入力しても、対戦部屋にメンバとして入室することはできない。第3ユーザが対戦部屋に入室すると、対戦部屋を観戦するための観戦画像が第3ゲーム端末10Cに表示される。
【0050】
図10は、観戦画像の一例を示す図である。
図10に示すように、観戦画像G4は、対戦部屋画像G3とは異なっている。例えば、観戦画像G4では、第3ユーザは対戦に参加することができず、第3ユーザが対戦部屋の中の対戦を観戦することができるようになっている。例えば、観戦画像G4には、対戦部屋に設けられたテーブルのうち、観戦するテーブルを選択するためのテーブル選択ボタンB40A~B40Cが表示される。なお、以降では、テーブル選択ボタンB40A~B40Cを特に区別する必要のないときは、単に、テーブル選択ボタンB40と記載する。
【0051】
例えば、テーブル選択ボタンB40には、各テーブルの状況が表示されており、エントリー中のユーザに関する情報が表示される。また例えば、既に対戦が開始しているテーブルについては、テーブル選択ボタンB40に、対戦の状況が表示されるようにしてもよい。例えば、対戦の状況としては、対戦中であるか否かを識別する情報や対戦の進行状況(例えば、現在のターン数やライフポイントなど)が表示されてもよい。第3ユーザは、テーブル選択ボタンB40の中から、観戦したいテーブルを選択することになる。
【0052】
図11は、観戦ユーザが対戦を観戦している様子を示す図である。
図11に示すように、観戦画像G4には、第3ユーザが選択したテーブルで行われている対戦の様子が表示される。例えば、観戦画像G4は、
図8の対戦部屋画像G3と同じであってもよいが、ここでは内容が異なるものとする。例えば、観戦画像G4には、両ユーザの手札が隠されていてもよいし、逆に両ユーザの手札が見える状態であってもよい。例えば、対戦が既に始まっている場合、観戦画像G4では、対戦の最初から現在に至るまでの進行が自動的に表示されるようにしてもよい。現在の状況まで到達した場合には、対戦をリアルタイムで観戦できるようになる。
【0053】
上記のように、本実施形態のゲームシステムSは、決定ボタンB235が選択された場合に、メンバとして入室するための部屋IDと、観戦ユーザとして入室するための観戦IDと、の2つのIDが生成され、IDごとに機能を使い分けることによって、ユーザの満足度を高めるようになっている。以降、当該構成の詳細を説明する。
【0054】
[3.ゲームシステムにおいて実現される機能]
図12は、ゲームシステムSで実現される機能のうち、本発明に関連する機能を示す機能ブロック図である。本実施形態では、対戦部屋に関する主な機能がサーバ30において実現される場合を説明するが、後述する変形例のように、主な機能がゲーム端末10において実現されてもよいし、各機能がゲーム端末10とサーバ30とで分担されてもよい。
図12に示すように、サーバ30では、データ記憶部300、対戦部屋生成部301、識別情報生成部302、及びゲーム実行部303が実現される。
【0055】
[3-1.データ記憶部]
データ記憶部300は、記憶部32を主として実現される。データ記憶部300は、ゲームを実行するために必要なデータを記憶する。ここでは、データ記憶部300が記憶するデータの一例として、対戦部屋データDT1を説明する。
【0056】
図13は、対戦部屋データDT1のデータ格納例を示す図である。
図13に示すように、対戦部屋データDT1は、対戦部屋に関するデータであり、例えば、対戦部屋の基本情報と、対戦部屋の現在の状況と、格納される。基本情報としては、例えば、部屋ID、観戦ID、対戦部屋の名前、入室可能なユーザの上限数、観戦機能の有無、対戦部屋を生成したオーナユーザのユーザID、及び当該オーナユーザがメンバとして参加できるか否かを示す情報が格納される。
【0057】
対戦部屋の現在の状況としては、メンバとして入室中のユーザのユーザID、メンバの現在の状態(例えば、対戦中、テーブルにエントリー中、テーブルに未エントリー等の状態)、対戦部屋におけるメンバの対戦成績、観戦ユーザとして入室中のユーザのユーザID、メンバ又は観戦ユーザが入力したコメント、及び各テーブルの状況等が格納される。各テーブルの状況としては、テーブルを識別するためのテーブルID、エントリー中のユーザのユーザID、対戦の状況などが格納される。対戦の状況は、対戦の進行状況であり、例えば、現在のターン、各ユーザのライフポイント、各ユーザの手札、フィールド上に配置されたゲームカード等の情報である。
【0058】
なお、データ記憶部300に記憶されるデータは、上記の例に限られない。データ記憶部300は、ゲームに必要なデータを記憶すればよい。例えば、データ記憶部300は、各ユーザが保有するゲームカードに関するデータを記憶してもよいし、各ユーザのユーザIDや名前などの基本情報に関するデータを記憶してもよい。また例えば、データ記憶部300は、対戦における各ユーザの操作と当該操作による実行結果の履歴を示す履歴データ記憶してもよい。当該履歴データは、対戦のリプレイを再生するために使用される。
【0059】
[3-2.対戦部屋生成部]
対戦部屋生成部301は、制御部11を主として実現される。対戦部屋生成部301は、複数のユーザがゲームをプレイするために用いる対戦部屋を生成する。本実施形態では、対戦部屋生成部301は、ユーザが対戦部屋モード画像G2のダイアログD23から対戦部屋の設定情報を入力し、決定ボタンB235が選択された場合に、当該入力内容に基づいて、対戦部屋を生成することになる。
【0060】
生成とは、例えば、ゲーム内に対戦部屋を生成することである。また例えば、対戦部屋に関するデータ(例えば、部屋IDと観戦ID)をコンピュータ上に登録することである。また例えば、本実施形態では対戦部屋をグループの一例として説明しているが、ロビーをグループの一例とする場合には、ゲーム内に新たにロビーを生成することが、生成の一態様である。また例えば、仮想世界内の所定の場所をグループの一例とする場合には、仮想世界内に新たな場所を生成することが、生成の一態様である。また例えば、フレンドやギルドをグループの一例とする場合には、新たなフレンドグループやギルドを生成することが、生成の一態様である。
【0061】
例えば、対戦部屋生成部301は、対戦部屋データDT1に、対戦部屋に関するデータを新たに登録することによって、対戦部屋を生成する。より具体的には、対戦部屋生成部301は、対戦部屋データDT1に新たなレコードを作成し、当該レコードに対戦部屋に関する情報を格納することによって、対戦部屋を生成する。本実施形態では、対戦部屋生成部301は、対戦部屋データDT1に新たなレコードを作成し、後述する識別情報生成部302が生成した部屋IDと観戦IDに関連付けて、オーナユーザが入力した対戦部屋の基本情報を格納することによって、対戦部屋を生成する。
【0062】
なお、対戦部屋生成部301は、ユーザによって所定の操作が行われた場合に対戦部屋を生成してもよいし、ユーザの操作ではなく他の条件が満たされた場合に対戦部屋を生成してもよい。他の条件としては、ゲームシステムSの管理者が所定の操作をすること、所定の日時が到来すること、又はゲームシステムS全体のユーザ数が閾値以上となること等の各種条件を適用可能である。
【0063】
[3-3.識別情報生成部]
識別情報生成部302は、制御部11を主として実現される。識別情報生成部302は、後述する生成要求が受け付けられた場合に、複数の識別情報を生成する。識別情報とは、例えば、対戦部屋を一意に識別可能な情報である。例えば、識別情報は、IDや対戦部屋の名前などの情報である。識別情報は、例えば、文字や数字などの記号列によって示される。
【0064】
識別情報生成部302は、生成要求が受け付けられた場合に、他の対戦部屋の識別情報と重複しないように、複数の識別情報を生成すればよい。識別情報の生成は、所定のルールに基づいて行われるようにすればよく、当該ルールはプログラムコードとして記述されているようにすればよい。識別情報生成部302は、生成済みの識別情報と、当該生成ルールと、に基づいて、複数の識別情報を生成する。例えば、識別情報生成部302は、直近で生成された識別情報が示す数値を所定値だけ増加させることによって識別情報を生成してもよいし、直近で生成された識別情報に所定の文字を追加することによって識別情報を生成してもよい。
【0065】
本実施形態では、複数の識別情報の一例として、部屋IDと観戦IDの2つのIDを説明する。このため、本実施形態で部屋ID又は観戦IDと記載した箇所は、識別情報と読み替えることができる。
【0066】
例えば、識別情報生成部302は、他の対戦部屋の部屋IDと重複しないように、部屋IDを生成する。更に、部屋IDと観戦IDが重複してもいけないので、例えば、識別情報生成部302は、他の対戦部屋の観戦ID及び今回生成する対戦部屋の観戦IDと重複しないように、部屋IDを生成する。
【0067】
また例えば、識別情報生成部302は、他の対戦部屋の観戦IDと重複しないように、観戦IDを生成する。更に、部屋IDと観戦IDが重複してもいけないので、例えば、識別情報生成部302は、他の対戦部屋の部屋ID及び今回生成する対戦部屋の部屋IDと重複しないように、観戦IDを生成する。
【0068】
複数の識別情報には、それぞれ互いに異なる機能が対応付けられている。例えば、識別情報ごとに、少なくとも1つの機能が対応付けられている。また例えば、識別情報ごとに、他の識別情報と対応付けられた機能とは一部又は全部が異なる機能が対応付けられている。識別情報と機能との対応関係は、予め数式形式、テーブル形式、又はプログラムコードの一部としてデータ記憶部300に定めておけばよい。
【0069】
機能とは、例えば、ゲームプログラムが有する機能の一部である。例えば、機能は、プログラムコードによって実行される処理である。また例えば、機能は、ユーザにゲームをプレイさせるための処理である。また例えば、機能は、ユーザに提供するサービスである。また例えば、機能は、ユーザに与えられる権限である。また例えば、機能は、ユーザに許可される操作である。例えば、機能は、ゲームをプレイすることでゲームに関与することであってもよいし、ゲームをプレイせずにゲームに関与することであってもよい。即ち、例えば、機能は、ゲームに直接的に関与することであってもよいし、間接的に関与することであってもよい。
【0070】
例えば、ユーザを観戦させるための観戦機能であってもよい。また例えば、他のユーザと対戦させるための対戦機能であってもよい。また例えば、他のユーザと協力プレイさせるための協力機能であってもよい。また例えば、ゲームをプレイする他のユーザを応援、投票、又は妨害するための機能であってもよい。応援は、例えば、ゲームをプレイするユーザに対する応援であり、例えば、メッセージ、ゲームアイテム、ゲーム内通貨などを送ることである。投票は、例えば、勝者や敗者などを予想することである。妨害は、例えば、ゲームをプレイするユーザが不利になるように邪魔をすることである。
【0071】
なお、各識別情報に対応付けられる機能は、互いに完全一致していなければよい。例えば、ある機能は、他の機能の全てを含んでもよい。また例えば、ある機能と他の機能は互いに一致部分がなく完全に異なってもよい。また例えば、ある機能と他の機能とで一部の機能が共通(部分一致)していてもよい。また例えば、ある機能は、他の機能よりも、ゲームをプレイするうえでの制限がかかっていたりしてもよい。また例えば、ある機能は、他の機能よりも使用可能なカードやキャラクタが多かったり少なかったりしてもよい。また例えば、ある機能は、他の機能よりもプレイ可能な時間が長かったり短かったりしてもよい。また例えば、ある機能は、他の機能よりもパラメータが多かったり小さかったりしてもよい。
【0072】
本実施形態では、各識別情報に対応付けられた機能の何れか1つは、ゲームのプレイを観戦するための観戦機能である。例えば、観戦IDに観戦機能が対応付けられている。なお、観戦とは、例えば、ゲームをプレイせずに画像や音声によってゲームの様子を見たり聞いたりすることである。別の言い方をすれば、観戦は、ゲームをプレイする当事者とはならず、第三者としてゲームを見ることである。例えば、ユーザが操作してもゲーム進行には影響せず、ユーザはゲームの様子を見たり聞いたりするだけの状態が、観戦に相当する。なお、例えば、観戦機能は、対戦をリプレイするためのリプレイ機能と、ユーザの対戦履歴を表示するための対戦履歴表示機能と、を含んでいてもよい。例えば、リプレイは、過去に行われた対戦の再現である。例えば、観戦は、過去に行われた対戦の再現を見ること(リプレイを見ること)と、現在進行中の対戦の様子を見ることと、の両方を包含する意味である。
【0073】
本実施形態では、各識別情報に対応付けられた機能の何れか1つは、他のユーザと対戦するための対戦機能である。例えば、部屋IDに対戦機能が対応付けられている。なお、対戦とは、例えば、他のユーザと戦ったり、スコアなどを競ったりすることである。別の言い方をすれば、対戦は、ゲームをプレイする当事者となることである。例えば、ユーザが操作した場合にゲーム進行に影響する状態が、観戦に相当する。
【0074】
本実施形態では、対戦部屋には、複数のテーブルが設定されており、各識別情報に対応付けられた機能の何れか1つは、テーブルごとに、当該テーブルにエントリーする複数のユーザがゲームをプレイするための機能である。例えば、部屋IDに、各テーブルで対戦するための対戦機能が対応付けられている。なお、なお、テーブルにエントリーすることは、サブグループに所属することの一態様である。このため、以降の説明で「テーブルにエントリー」と記載した箇所は、サブグループに所属と読み替えることができる。
【0075】
テーブルにエントリーするとは、例えば、ユーザがテーブルを選択することであり、ユーザがテーブルにエントリーすることである。また例えば、テーブルの識別情報に、ユーザの識別情報が関連付けられることである。本実施形態の対戦機能では、対戦部屋にメンバとして入室した複数のユーザの各々が何れか1つのテーブルにエントリーし、同じテーブルにエントリーした他のユーザとゲームをプレイする。
【0076】
なお、識別情報生成部302が生成する識別情報は、複数個であればよく、3つ以上であってもよい。3つ以上の識別情報が生成される場合には、1つの対戦部屋に対し、3つ以上の機能が存在することになる。例えば、識別情報生成部302は、1つの対戦部屋に対し、対戦機能が対応付けられた部屋ID、観戦機能が対応付けられた観戦ID、及び応援機能が対応付けられた応援IDと、の3つを生成してもよい。また例えば、識別情報生成部302は、部屋IDとして、自分のゲームカードの使用が対戦で制限されない無制限IDと、自分のゲームカードの使用が対戦で制限される(例えば、決められたゲームカードしか使用できない)制限IDと、の2種類を生成してもよい。識別情報生成部302は、対戦部屋内でのゲームに設定される機能の数に応じた識別情報を生成すればよい。
【0077】
[3-4.ゲーム実行部]
ゲーム実行部303は、制御部11を主として実現される。ゲーム実行部303は、複数のユーザが参加するゲームを実行する。例えば、ゲーム実行部303は、各ユーザを、識別情報生成部302が生成した複数の識別情報の何れか1つと関連付ける処理を実行し、当該ユーザに対し、当該ユーザと関連付けられた識別情報に対応する機能を提供する。ゲーム実行部303は、ユーザが関連付けられた識別情報に対応する機能に関するプログラムコードを実行することによって、当該機能をユーザに提供する。
【0078】
例えば、ゲーム実行部303は、部屋IDを入力したユーザを当該部屋IDと関連付ける。ゲーム実行部303は、部屋IDと関連付けられたユーザ(本実施形態ではメンバ)に対し、対戦機能を提供する。例えば、ゲーム実行部303は、部屋IDと関連付けられたユーザの操作に基づいてテーブルにエントリーさせたり、ユーザの操作に基づいて対戦を実行したりする。別の言い方をすれば、ゲーム実行部303は、部屋IDと関連付けられたユーザの操作に基づいて、他のユーザと対戦するためのプログラムコードを実行する。
【0079】
また例えば、ゲーム実行部303は、観戦IDを入力したユーザを当該観戦IDと関連付ける。ゲーム実行部303は、観戦IDと関連付けられたユーザ(本実施形態では観戦ユーザ)に対し、観戦機能を提供する。例えば、ゲーム実行部303は、観戦IDと関連付けられたユーザのゲーム端末10に対し、実行中の対戦の様子を示す画像を表示させるためのデータを送信する。別の言い方をすれば、ゲーム実行部303は、観戦IDと関連付けられたユーザの操作に基づいて、他のユーザの対戦を観戦するためのプログラムコードを実行する。
【0080】
[4.ゲームシステムにおいて実行される処理]
図14-
図15は、ゲームシステムSにおいて実行される処理の一例を示すフロー図である。
図14-
図15に示す処理は、制御部11が記憶部12に記憶されたプログラムに従って動作し、制御部31が記憶部32に記憶されたプログラムに従って動作することによって実行される。以降説明する処理は、機能ブロックが実行する処理の一例である。
【0081】
図14に示すように、まず、制御部11は、記憶部12に記憶されたゲームプログラムを起動させ、ユーザが所定の操作をした場合に、対戦モード選択画像G1を表示部15に表示させる(S101)。なお、対戦モード選択画像G1の表示データは、記憶部12に記憶されていてもよいし、サーバ30から受信してもよい。
【0082】
制御部11は、操作部14の検出信号に基づいて、ユーザの操作を特定する(S103)。ここでは、対戦部屋ボタンB13を選択する操作、又は、他の操作(ランク戦ボタンB10、フリー対戦ボタンB11、又はフレンド対戦ボタンB12を選択する操作)が行われる。他の操作が行われた場合(S103;その他)、本処理は終了し、制御部11は、ランク戦、フリー対戦、又はフレンド対戦に係る処理を実行することになる。
【0083】
ユーザが対戦部屋ボタンB13を選択した場合(S103;対戦部屋ボタン)、制御部11は、対戦部屋モード画像G2を表示部15に表示させる(S105)。なお、対戦部屋モード画像G2の表示データは、記憶部12に記憶されていてもよいし、サーバ30から受信してもよい。
【0084】
制御部11は、操作部14の検出信号に基づいて、ユーザの操作を特定する(S107)。ここでは、対戦部屋生成ボタンB20を選択する操作、観戦ユーザ入室ボタンB22を選択する操作、又は観戦ユーザ入室ボタンB22を選択する操作が行われる。
【0085】
ユーザが対戦部屋生成ボタンB20を選択した場合(S107;対戦部屋生成ボタン)、制御部11は、対戦部屋モード画像G2上にダイアログD23を表示させる(S109)。なお、ダイアログD23の表示データは、記憶部12に記憶されていてもよいし、サーバ30から受信してもよい。
【0086】
制御部11は、ダイアログD23に対するユーザの入力に基づいて、サーバ30に対し、対戦部屋の生成要求を送信する(S111)。S111においては、制御部11は、操作部14の検出信号に基づいて、ユーザの入力内容を特定する。例えば、制御部11は、入力フォームF230に対して入力された対戦部屋の名前を記憶部12に記録する。また例えば、制御部11は、入力フォームF231に対して入力された人数を記憶部12に記録する。また例えば、制御部11は、ラジオボタンB232,B233の選択結果を記憶部12に記録する。制御部11は、決定ボタンB235が選択されたことに応じて、記憶部12に記憶された入力内容を含む生成要求を送信する。生成要求は、予め定められたデータ形式で行われるようにすればよく、ユーザIDと、ダイアログD23に対する入力内容と、を含む。なお、ユーザIDは、予め記憶部12に記憶されているものとする。この点は、以降の処理でも同様である。また、ユーザがキャンセルボタンB234を選択した場合には、S111の処理が実行されず、S105の処理に戻るものとする。
【0087】
サーバ30においては、生成要求を受信すると、制御部31は、受信した生成要求に基づいて、対戦部屋データDT1に新たなレコードを作成し、生成要求に含まれる対戦部屋の基本情報を格納する(S301)。
【0088】
制御部31は、対戦部屋の識別情報として、対戦機能が対応付けられた部屋IDと、観戦機能が対応付けられた観戦IDと、を生成し(S303)、対戦部屋の生成処理が完了する。S303においては、制御部31は、所定のルールに基づいて部屋IDと観戦IDを生成し、S301で生成したレコードに格納する。
【0089】
一方、S107において、ユーザがメンバ入室ボタンB21を選択した場合(S107;メンバ入室ボタン)、
図15に移り、制御部11は、対戦部屋モード画像G2上にダイアログD24を表示させる(S113)。なお、ダイアログD24の表示データは、記憶部12に記憶されていてもよいし、サーバ30から受信してもよい。
【0090】
制御部11は、ダイアログD24に対するユーザの入力に基づいて、サーバ30に対し、メンバとしての入室要求を送信する(S115)。S115においては、制御部11は、操作部14の検出信号に基づいて、ユーザの入力内容を特定する。例えば、制御部11は、入力フォームF240に対して入力された部屋IDを記憶部12に記録する。制御部11は、決定ボタンB241が選択されたことに応じて、記憶部12に記憶された入力内容を含む入室要求を送信する。入室要求は、予め定められたデータ形式で行われるようにすればよく、ユーザIDと、ダイアログD24に対する入力内容と、を含む。なお、ユーザが決定ボタンB241を選択しなかった場合には、S115の処理が実行されず、S105の処理に戻るものとする。
【0091】
サーバ30においては、入室要求を受信すると、制御部31は、対戦部屋データDT1に基づいて、受信した部屋IDが存在するか否かを判定する(S305)。S305においては、制御部31は、対戦部屋データDT1に格納された部屋IDの中に、受信した入室要求に含まれる部屋IDが存在するか否かを判定する。
【0092】
部屋IDが存在すると判定された場合(S305)、制御部31は、ユーザをメンバとして入室させる(S307)。S307においては、制御部31は、対戦部屋データDT1のうち、入室要求に含まれる部屋IDが格納されたレコードの対戦部屋の状況を更新し、入室要求をしたユーザのユーザIDをメンバとして追加する。以降、対戦部屋画像G3が表示され、ユーザはテーブルへのエントリー及び他のユーザとの対戦が可能な状態となる。即ち、ユーザが入力した部屋IDによって、当該ユーザに対して対戦機能が提供されることになる。
【0093】
一方、S107において、ユーザが観戦ユーザ入室ボタンB22を選択した場合(S107;観戦ユーザ入室ボタン)、
図15に移り、制御部11は、対戦部屋モード画像G2上にダイアログD25を表示させる(S117)。なお、ダイアログD25の表示データは、記憶部12に記憶されていてもよいし、サーバ30から受信してもよい。
【0094】
制御部11は、ダイアログD25に対するユーザの入力に基づいて、サーバ30に対し、観戦ユーザとしての入室要求を送信する(S119)。S119においては、制御部11は、操作部14の検出信号に基づいて、ユーザの入力内容を特定する。例えば、制御部11は、入力フォームF250に対して入力された観戦IDを記憶部12に記録する。制御部11は、決定ボタンB251が選択されたことに応じて、記憶部12に記憶された入力内容を含む入室要求を送信する。入室要求は、予め定められたデータ形式で行われるようにすればよく、ユーザIDと、ダイアログD25に対する入力内容と、を含む。なお、ユーザが決定ボタンB251を選択しなかった場合には、S119の処理が実行されず、S105の処理に戻るものとする。
【0095】
サーバ30においては、入室要求を受信すると、制御部31は、対戦部屋データDT1に基づいて、受信した観戦IDが存在するか否かを判定する(S309)。S309においては、制御部31は、対戦部屋データDT1に格納された観戦IDの中に、受信した入室要求に含まれる観戦IDが存在するか否かを判定する。
【0096】
観戦IDが存在すると判定された場合(S309;Y)、制御部31は、ユーザを観戦ユーザとして入室させる(S311)。S311においては、制御部31は、対戦部屋データDT1のうち、入室要求に含まれる観戦IDが格納されたレコードの対戦部屋の状況を更新し、入室要求をしたユーザのユーザIDを観戦ユーザとして追加する。以降、観戦画像G4が表示され、ユーザは、観戦したいテーブルを選択することができる状態となる。即ち、ユーザが入力した観戦IDによって、当該ユーザに対して観戦機能が提供されることになる。
【0097】
以上説明したゲームシステムSによれば、決定ボタンB235が選択された場合に、対戦部屋に関連付けられる複数の識別情報が生成され、複数の識別情報にはそれぞれ互いに異なる機能が対応付けられているので、対戦部屋の中で実行されるゲームに他のユーザが適切に関与することができる。例えば、ユーザに対して何らかの機能が提供されることで、ゲームを見ることすらできないといったことを防止することができる。
【0098】
また、観戦IDによって、ユーザがゲームを観戦することができるので、ゲームを観戦することすらできず不満を感じるといったことを防止することができる。
【0099】
また、部屋IDによって、ユーザが他のユーザと対戦することができるので、ゲームをプレイすることすらできず不満を感じるといったことを防止することができる。
【0100】
また、テーブルごとに、当該テーブルにエントリーするユーザ同士でゲームがプレイされるので、好きなユーザ同士でゲームをプレイさせることができる。
【0101】
[5.変形例]
なお、本発明は、以上に説明した実施の形態に限定されるものではない。本発明の趣旨を逸脱しない範囲で、適宜変更可能である。
【0102】
(1)例えば、実施形態では、部屋IDに対戦機能が対応付けられており、観戦IDに観戦機能が対応付けられている場合を説明したが、各識別情報に対応付けられた機能の何れか1つは、他のユーザと協力して対戦するための協力機能であってもよい。例えば、部屋IDに協力機能が対応付けられていてもよい。協力とは、例えば、他のユーザと協力して共通の目標の達成を目指すことである。別の言い方をすれば、協力は、ゲームをプレイする当事者となることである。例えば、ユーザが操作した場合と、協力相手の他のユーザが操作した場合と、にゲーム進行に影響する状態が協力に相当する。
【0103】
変形例(1)によれば、ユーザが他のユーザと協力することができるので、ゲームをプレイすることすらできず不満を感じるといったことを防止することができる。
【0104】
(2)また例えば、ゲームシステムSで実行されるゲームは、複数のユーザでプレイされる第1ゲームパートと、第2ゲームパートと、を含んでいてもよい。第1ゲームパートのゲームプログラムと第2ゲームパートのゲームプログラムとは、プログラムとして一体であってもよいし別体であってもよい。
【0105】
第1ゲームパートは、例えば、ゲームのうち、他のユーザと対戦したり協力したりすることによってプレイする一部分である。実施形態で説明した各識別情報に対応付けられた機能は、第1ゲームパートに関する機能である。
【0106】
第2ゲームパートは、例えば、第1ゲームパートとは異なるゲーム部分であればよく、例えば、ゲームのうち、ユーザが1人でプレイする部分である。また例えば、第2ゲームパートは、ユーザが1人で所定のゲーム課題(クエスト・ミッション)をクリアする部分である。また例えば、第2ゲームパートは、ネットワークに接続しなくてもプレイ可能な部分である。また例えば、第2ゲームパートは、第1ゲームパートとはゲームのクリア条件・勝利条件・報酬体系などが異なる部分である。例えば、第1ゲームパートと第2ゲームパートは、内容が共通する部分があり、例えば、登場人物、ユーザが使用するゲームオブジェクト、ストーリーや世界観などは共通していてもよい。
【0107】
なお、実施形態と同様に、本変形例でも、各ユーザは、複数の識別情報の何れか1つと関連付けられ、自身と関連付けられた識別情報に対応する機能を利用可能である。各ユーザは、複数の識別情報のうち自身が入力した識別情報と関連付けられることになる。
【0108】
利用とは、例えば、機能が提供されることである。例えば、ユーザの指示に基づいて、機能に対応するプログラムコードを実行可能にすることである。例えば、機能が観戦機能であれば、実行中のゲームの画面をユーザの端末に表示させることである。また例えば、機能が対戦機能であれば、ユーザが他のユーザと対戦できるようにすることである。また例えば、機能が協力機能であれば、ユーザが他のユーザと協力プレイできるようにすることである。また例えば、機能が応援・投票・妨害機能であれば、ユーザが他のユーザを応援・投票・妨害できるようにすることである。
【0109】
複数の識別情報には、ユーザが第2ゲームパートをプレイしても関連付けが維持される識別情報と、ユーザが第2ゲームパートをプレイした場合に関連付けが解除される識別情報と、が含まれる。
【0110】
維持とは、例えば、ユーザが識別情報に関連付けられた状態のまま変えないことである解除とは、例えば、識別情報に関連付けられた状態から関連付けられていない状態に変えることである。機能が提供されない状態に変えることである。例えば、ユーザを部屋やロビーから退室させることである。また例えば、仮想世界の中に設定された所定の場所から離れることである。また例えば、フレンドグループやギルドから離脱させることである。なお、ゲーム端末10とサーバ30との接続が切断された場合に、ユーザと識別情報との関連付けが解除されてもよいが、ここでは、ユーザと識別情報との関連付けが維持されるものとする。なお、接続が切断とは、例えば、ゲーム端末10とサーバ30の少なくとも一方が通信を終了するための信号を送信すること、ゲーム端末10とサーバ30の少なくとも一方の応答がない状態が一定時間以上経過することを意味する。また、部屋IDについては、通信が切断してもユーザが関連付けられた状態を維持し、観戦IDについては、通信が切断した場合にユーザとの関連付けを解除するといったように、通信が切断された場合に関連付けを維持するか解除するかを識別情報に応じて異ならせてもよい。
【0111】
例えば、部屋IDは第2ゲームパートをプレイしてもユーザと部屋IDとの関連付けが維持される。一方、例えば、観戦IDは第2ゲームパートをプレイした場合にユーザと観戦IDとの関連付けが解除される。なお、どの識別情報が、第2ゲームパートをプレイしても関連付けが維持される識別情報であるかは、予めデータ記憶部300に定めておけばよい。同様に、どの識別情報が、ユーザが第2ゲームパートをプレイした場合に関連付けが解除される識別情報であるかは、予めデータ記憶部300に定めておけばよい。
【0112】
変形例(2)によれば、第2ゲームパートをプレイしても関連付けが維持される識別情報があるので、第2ゲームパートをプレイした後に、再び識別情報との関連付けをし直さなければならないといった煩雑さを防止することができる。また、第2ゲームパートをプレイした場合に関連付けが解除される識別情報については、ユーザがずっと識別情報と関連付けられているといった状態を防止することができる。
【0113】
(3)また例えば、変形例(2)で説明した第2ゲームパートは、テーブルにエントリー中のユーザによってプレイされることが制限されるようにしてもよい。例えば、ゲーム実行部303は、テーブルにエントリー中のユーザについては、テーブルのエントリーを解除しなければ、第2ゲームパートをプレイできないようにしてもよい。なお、テーブルのエントリーは、エントリー中のテーブルのテーブル選択ボタンB38が選択されることによって解除されるようにすればよい。
【0114】
変形例(3)によれば、テーブルにエントリー中のユーザが第2ゲームパートをプレイすることが制限されるので、他のユーザが一緒にゲームをプレイしようと思っても、それに気づかずに第2ゲームパートをプレイしてしまうといったことを防止することができる。
【0115】
(4)また例えば、2人のユーザが先攻と後攻に分かれて対戦するゲームが実行されるようにしてもよい。先攻とは、例えば、2人のユーザのうち、先に攻撃する方である。ターン制のゲームであれば、先に自分のターンが訪れることである。野球ゲームであれば、イニングの表に攻撃する方である。後攻とは、例えば、2人のユーザのうち、後に攻撃する方である。ターン制のゲームであれば、後に自分のターンが訪れることである。野球ゲームであれば、イニングの裏に攻撃する方である。
【0116】
各識別情報に対応付けられた機能の何れか1つは、テーブルごとに、当該テーブルにエントリーする2人のユーザの少なくとも一方が先攻と後攻を決定してゲームをプレイさせるための機能である。例えば、ユーザがテーブルにエントリーする際に先攻と後攻の何れか1つを指定可能であってもよいし、ゲームの開始時に先攻と後攻の何れか1つを指定可能であってもよい。ゲーム実行部303は、ゲーム端末10からユーザの指定結果を取得し、当該指定結果に基づいて先攻と後攻を決定してゲームを開始する。
【0117】
変形例(4)によれば、ユーザが先攻と後攻の好きな方を選択することができるので、対戦の興趣性を向上させることができる。
【0118】
[6.第2実施形態について]
次に、ゲームシステムSの別実施形態を説明する。以降説明する第2実施形態では、第1実施形態で説明したゲームと同様のゲームが実行される場合を一例として説明するが、第2実施形態のゲームは、第1実施形態のゲームとは異なってもよい。第2実施形態では、実在の大会会場においてゲーム大会が開催される。
【0119】
大会会場とは、例えば、ゲーム大会の開催場所であり、ユーザを集める場所である。例えば、大会会場は、イベント会場、野球場、陸上競技場、音楽ホール、ゲームセンターなどである。
【0120】
ゲーム大会とは、例えば、ゲームに関するイベントであり、ユーザが互いに優劣を競うものである。なお、ゲーム大会に出場せずに観戦するだけのユーザが存在してもよい。例えば、ゲーム大会では、1種類のゲームの優劣を競ってもよいし、複数種類のゲームの優劣を競ってもよい。また例えば、ゲーム大会は、出場ユーザが、互いに協力してプレイするものであってもよい。また例えば、ゲーム大会では、出場ユーザが自分の端末を操作してもよいし、運営者によって専用の端末が用意されていてもよい。また例えば、ゲーム大会は、いわゆるeスポーツと呼ばれる大会であってもよいし、特に賞金や景品がかけられていない大会であってもよい。
【0121】
[6-1.第2実施形態のゲームシステムの全体構成]
図16は、第2実施形態のゲームシステムSの全体構成を示す図である。
図16に示すように、ゲームシステムSは、第1実施形態で説明した構成に加えて、管理者端末50を含む。管理者端末50は、ゲーム大会の管理者が操作するコンピュータである。管理者は、ゲーム大会の運営を管理する者であり、例えば、ゲーム会社の関係者であってもよいし、イベント運営を委託された会社の関係者であってもよい。なお、管理者端末50は、1台だけではなく、複数台存在してもよい。
【0122】
例えば、管理者端末50は、携帯端末(例えば、スマートフォンなどの携帯電話又はタブレット型コンピュータ)又はパーソナルコンピュータ等である。
図16に示すように、管理者端末50は、制御部51、記憶部52、通信部53、操作部54、及び表示部55を含む。制御部51、記憶部52、通信部53、操作部54、及び表示部55のハードウェア構成は、それぞれ制御部11、記憶部12、通信部13、操作部14、及び表示部15と同様であってよい。大会会場では、ユーザがゲーム端末10を操作して対戦し、管理者が管理者端末50を操作してゲーム大会の運営業務を行う。
【0123】
図17は、大会会場内でユーザ同士が対戦する様子を示す図である。
図17に示すように、大会会場にはテーブルTが用意されており、テーブルTを挟むようにしてユーザU1,U2が座る。ユーザU1,U2の各々は、手元にあるゲーム端末10を操作して対戦する。テーブルTの近くにいる管理者Mは、管理者端末50を操作しながら対戦の進行を管理する。例えば、大会会場には、
図17のようなテーブルTが複数台配置されており、各テーブルで対戦が行われる。なお、以降では、管理者M、ユーザU1,U2、及びテーブルTの各符号を省略する。
【0124】
例えば、ゲーム大会は、予選を勝ち抜いた複数のユーザが出場してもよいし、特に予選が行われることなく出場するユーザが決まってもよい。また例えば、ゲーム大会は、1日で終了してもよいし、複数日にまたがって開催されてもよい。本実施形態では、ゲーム大会が2日間にわたって開催され、1日目にリーグ戦が開催され、2日目にトーナメント戦が開催される場合を説明する。
【0125】
リーグ戦では、複数のブロックの各々で総当たり戦が行われる。例えば、ユーザは、複数のブロックのうちの何れか1つに割り当てられ、同じブロックに割り当てられた他のユーザ全員と対戦する。例えば、ユーザは、同じブロックの他のユーザと3回ずつ対戦し、先に2勝した方の勝利となる。以降、同じユーザ同士で行われる3回の対戦の各々をラウンドと記載する。
【0126】
リーグ戦におけるブロック数は、ユーザ数などに応じて定めればよく、本実施形態では2つとするが、ブロック数は3つ以上であってもよい。以降、2つのブロックを、それぞれAブロック・Bブロックという。Aブロックに割り当てられるユーザの数と、Bブロックに割り当てられるユーザの数と、は同じであってもよいし、異なっていてもよい。
【0127】
リーグ戦では、ブロックごとに、総当たり戦の結果に基づいてユーザの順位が決定される。例えば、各ブロックの上位2名は、2日目に行われるトーナメント戦に出場することができる。即ち、2日目のトーナメント戦は、合計4名のユーザによって行われる勝ち抜き戦となる。以降、ゲーム大会における1日目の流れと2日目の流れの詳細を説明する。
【0128】
[6-1.ゲーム大会の流れ]
図18-
図21は、ゲーム大会の1日目における進行手順を示す図である。各ブロックで行われる対戦は、開始時間が予め決められており、各ユーザは、自身の対戦の開始時間が近づくまで、大会会場内又はその付近の控室で待機する。また、テーブルごとに、当該テーブルの進行を担当する管理者が決められている。管理者は、自身が担当するテーブルの対戦の開始時間が近づくと、管理者端末50を操作して対戦の準備を行う。
【0129】
図18に示すように、各テーブルの管理者は、操作部54を操作して記憶部52に記憶された管理ツールを起動し、ゲーム大会の進行を管理するための管理ツール画像を表示部55に表示させる(S501)。なお、管理ツールは、ゲーム大会の進行を管理するためのツールであり、管理ツールのプログラムは、予め記憶部52に記憶されているものとする。
【0130】
図22は、管理ツール画像の一例を示す図である。
図22に示すように、管理ツール画像G5では、管理者が担当するテーブルを入力するための入力フォームF50が表示されており、例えば、大会会場に用意されたテーブルがプルダウン形式で選択できるようになっている。S501では、管理者は、入力フォームF50から自分が担当するテーブルを選択する。
【0131】
また、本実施形態では1対戦あたり3ラウンド行われるので、管理ツール画像G5では、これから開始するラウンドを入力するための入力フォームF51が表示されており、第1ラウンド~第3ラウンドの何れか1つをプルダウン形式で選択できるようになっている。S501の時点では、管理者は、まだ対戦前の準備作業をしているので、入力フォームF51から第1ラウンドを選択することになる。
【0132】
管理者は、入力フォームF50からテーブルを選択し、入力フォームF51からラウンドを選択すると、ラウンド進行ボタンB52を選択する(S503)。その後、管理者は、大会会場内にあるゲーム端末10とレジェンドカードとを、自身が担当するテーブルに持っていく(S505)。
【0133】
なお、レジェンドカードは、レジェンドと呼ばれるゲームキャラクタの顔が印刷されたカードであり、ユーザが対戦で使用するデッキを指定するために用いられる。本実施形態では、複数のレジェンドの各々がゲーム内でゲームカードを使用して対戦する。例えば、ユーザは、レジェンドごとにデッキを用意することが可能であり、ユーザが対戦で使用するレジェンドを指定すると、当該レジェンドに対応するデッキをその対戦で使用することができる。レジェンドカードをテーブルに置くのは、ユーザが使用するレジェンドを指定するためである。
【0134】
また、大会会場は、ネットワークNに有線接続できる環境が整っており、例えば、管理者は、ゲーム端末10を置き(S507)、各ゲーム端末10を有線接続する(S509)。有線としては、ゲーム端末10に備えられた通信端子に応じた任意の規格を適用可能である。
【0135】
第1実施形態で説明した対戦部屋モードは、第2実施形態のゲーム大会でも利用されるようになっており、管理者は、S509で有線接続した各ゲーム端末10を操作し、ゲームプログラムを起動して対戦モード選択画像G1を表示させる。なお、ゲーム大会専用の対戦部屋は、予め管理者によって生成されており、当該対戦部屋の部屋IDと観戦IDも予め生成されているものとする。例えば、参加資格のないユーザが勝手にメンバとして入室することを防ぐために、管理者のみが部屋IDを把握するようにしてもよい。一方、観戦IDは、ゲームプログラム内のお知らせ機能やウェブサイトなどを通じて多くのユーザに通知されるようにしてもよい。
【0136】
管理者は、各ゲーム端末10を操作し、対戦部屋ボタンB13を選択して対戦部屋モード画像G2を表示させ、メンバ入室ボタンB21を選択してダイアログD24から部屋IDを入力し、ゲーム大会用の対戦部屋にメンバとして入室する(S511)。なお、各ゲーム端末10には、当該ゲーム端末10を利用するユーザのユーザIDが予め入力されているものとする。これにより、管理者がゲーム端末10を操作したとしても、サーバ30は、どのユーザがメンバとして入室したかを特定することができる。
【0137】
管理者は、ゲーム端末10を裏返し、当該ゲーム端末10を使用予定のユーザの名前を確認できるようにする(S513)。例えば、管理者は、ゲーム端末10の裏面にユーザ名が印刷された紙やシールを貼り付けてもよいし、ユーザ名が印刷された紙をゲーム端末10の上に置いてもよい。管理者は、レジェンドカードが対戦相手にも見えるように、各ユーザのレジェンドカードの表(レジェンドの顔が描かれた側)を上にしてテーブルに置く(S515)。
【0138】
以上により、対戦の事前準備が完了する。管理者は、事前準備を終えると、対戦の開始時間が近づいてユーザが控室から出てくるのを待つ。
図19に示すように、ユーザは、対戦開始の5分前を目途にテーブルに着席する(S101)。管理者は、ユーザが着席したことを確認すると(S517)、テーブル上のゲーム端末10を使用予定のユーザと、実際に着席したユーザと、の一致を確認し(S519)、各ユーザに対し、ゲーム端末10を表にするよう促す(S521)。
【0139】
ユーザは、管理者の指示を受けると、ゲーム端末10を表にする(S103)。管理者は、各ユーザに対し、手を挙げて何れかのレジェンドカードを選択することを促す(S523)。S523においては、管理者は、複数のレジェンドカードの中から、今から始まるラウンドで使用するレジェンドが描かれたレジェンドカードを選択することを促すことになる。
【0140】
ユーザは、テーブル上の複数のレジェンドカードのうちの何れか1つを選択し(S105)、手を挙げて合図をしつつ、選択したレジェンドカードを管理者にだけ見せる(S107)。この段階では、対戦相手は、どのレジェンドカードが選択されたかを知ることができない。管理者は、2人のユーザの各々のレジェンドカードを確認すると、各ユーザが選択したレジェンドカードを管理ツールから登録する(S525)。
【0141】
図23は、管理ツールからレジェンドカードが登録される様子を示す図である。S503においてラウンド進行ボタンB52が選択されると、管理ツール画像G5の表示が変わり、
図23に示すように、管理ツール画像G5には、管理者が担当するテーブル、これから開始するラウンドの情報、対戦部屋の部屋ID、対戦が行われるブロック、ユーザの名前、及びユーザが使用可能なレジェンドの情報等が表示される。
【0142】
また、管理ツール画像G5には、ラウンドのステータスを入力するための入力フォームF53と、ユーザが使用するレジェンドを入力するための入力フォームF54と、が表示される。管理者は、各ユーザが選択したレジェンドカードに描かれたレジェンドを入力フォームF54から入力する。これにより、管理ツール側で、各ユーザがどのデッキを使用するかを特定可能となる。なお、管理ツールに対して入力された情報は、適宜サーバ30にも送信され、サーバ30側でも、各ユーザがどのデッキを使用するかを特定可能となる。
【0143】
管理者は、各ユーザに互いに握手するように促し、ラウンドを開始させる(S527)。各ユーザは、互いに挨拶及び握手を行い、自分のゲーム端末10を操作してラウンドを開始する(S109)。管理者は、対戦の開始を確認すると、管理ツール画像G5の入力フォームF53から、ラウンドのステータスを対戦中に変更する(S529)。
【0144】
図20に移り、各ユーザがゲーム端末10を操作することによって、ラウンドが進行する(S111)。ラウンド中に通信エラーが発生した場合には、管理者は、ユーザに対し、ゲーム端末10から所定の操作をして復帰を試みることを促す(S531)。また、サーバ30側でエラーが発生した場合には、管理者は、各ユーザが使用中のデッキ(即ち、ラウンドの開始前に各ユーザが選択したレジェンドカード)を変更することなく、ラウンドの最初から再試合をさせる(S533)。なお、予め定められた制限時間が経過しても勝負がつかなかった場合には、引き分けとなるようにしてもよい。
【0145】
実行中のラウンドの勝敗又は引き分けが決定すると、各ユーザは、手を挙げて管理者に合図し、ゲーム端末10をテーブル上に置く(S113)。管理者は、各ユーザのゲーム端末10の画面を確認し、対戦結果を管理ツールから登録する(S533)。この時点で何れかのユーザが2勝した場合、又は、3ラウンド目が終了した場合には対戦終了となる(S535)。
【0146】
対戦が終了していない場合(S537;N)、勝利したユーザは自身が使用したレジェンドカードを裏側にして、管理者は、管理ツール画像G5の入力フォームF51から次のラウンドを入力し、S523から次のラウンドを進行させる。なお、勝利した方のユーザは、先のラウンドで使用したレジェンドカードを次のラウンドで使用できないものとする。一方、敗北した方のユーザは、先のラウンドで使用したレジェンドカードを次のラウンドで使用することができる。
【0147】
一方、S533において、対戦が終了した場合(S537;Y)、勝ち数が多い方のユーザが勝利となり、管理者は、対戦結果を管理ツールに登録し、対戦状態を対戦終了に変更する(S539)。
【0148】
図24は、管理ツールから対戦結果が登録される様子を示す図である。
図24に示すように、管理者は、S533において、管理ツール画像G5の入力フォームF55から各ユーザの勝敗を入力し、入力フォームF53から対戦終了のステータスに変更する。管理者は、ユーザにゲーム端末10をテーブル上に置いてもらい、互いに握手してもらう(S541)。管理者は、ユーザに対し、控室に戻ることを促し(S543)、ユーザは控室に戻る(S115)。
【0149】
図21に示すように、ユーザが控室に戻ると、管理者は、2台のゲーム端末10のうちの片方の対戦部屋画像G3から退室ボタンB37を選択し、片方のユーザを対戦部屋から退室させる(S545)。そして、管理者は、当該ゲーム端末10の有線接続を外す(S547)。同様に、管理者は、2台のゲーム端末10のうちの他方の対戦部屋画像G3から退室ボタンB37を選択し、残りのユーザを対戦部屋から退室させる(S549)。そして、管理者は、当該ゲーム端末10の有線接続を外す(S551)。
【0150】
なお、対戦中の各ユーザの操作及びゲームの進行の履歴は予め記録されており、対戦のリプレイを再生することができるようになっている。管理者は、終了した対戦の結果とリプレイデータと対応付けるための操作を行う(S553)。なお、この対応付けは、自動化されていてもよい。管理者は、管理ツールから対戦結果の公開設定をオンにする(S555)。なお、終了した対戦の公開設定は自動的にオンになるようにしてもよい。管理者は、所定の位置にゲーム端末10とレジェンドカードを戻す(S557)。
【0151】
以上のようにしてリーグ戦が繰り返される。各ブロックの全試合が終了して上位2名が決定すると、管理者は、管理ツールから翌日のトーナメント戦のトーナメント表を生成する。管理者が生成したトーナメント表は、ユーザに公開される。
【0152】
ゲーム大会の2日目に行われるトーナメント戦は、ゲーム大会の1日目に行われるリーグ戦の手順と全く同じであってもよいし異なっていてもよい。例えば、本実施形態のように、トーナメント戦の試合数がリーグ戦よりも少ない場合には、S501とS503の手順は省略し、S505の手順から開始されてもよい。
【0153】
第2実施形態のゲーム大会は、上記説明した手順で進行する。第2実施形態のゲームシステムSでは、各ユーザが、予めレジェンドとデッキとを対応付けておき、ゲーム大会の対戦時にレジェンドカードを選択することによって、どのデッキを使用するかを容易に選択できるようになっている。以降、当該構成の詳細を説明する。
【0154】
[6-2.第2実施形態で実現される機能]
図25は、第2実施形態の機能ブロック図である。
図25に示すように、第2実施形態では、第1実施形態で説明した機能ブロックに加え、データ取得部304が実現される。なお、データ記憶部300、対戦部屋生成部301、識別情報生成部302、及びゲーム実行部303は、第1実施形態と一部共通するが下記の点で異なる。
【0155】
例えば、データ記憶部は、ユーザごとに、ゲームで使用可能な第1ゲームオブジェクトと、ゲーム内で第1ゲームオブジェクトを使用する第2ゲームオブジェクトと、の組み合わせが複数格納されたオブジェクトデータDT2を記憶する。なお、オブジェクトは、ゲームで使用され得る対象であり、例えば、ゲームキャラクタ、ゲームカード、ゲームアイテムである。以降では、第1ゲームオブジェクトが複数のゲームカードからなるデッキであり、第2ゲームオブジェクトがレジェンド(ゲームキャラクタ)である場合を説明する。
【0156】
図26は、オブジェクトデータDT2の一例を示す図である。
図26に示すように、オブジェクトデータDT2は、ユーザが使用するゲームオブジェクトに関するデータである。例えば、オブジェクトデータDT2には、ユーザIDと関連付けて、レジェンドとデッキとが格納される。デッキとしては、ゲームカードを識別するIDが格納される。データ取得部は、制御部31を主として実現される。データ取得部は、データ記憶部300に記憶されたオブジェクトデータDT2を取得する。
【0157】
なお、複数のスキルのうちの少なくとも1つがレジェンドに関連付けられる場合には、オブジェクトデータDT2には、レジェンドとスキルの両方と、デッキと、が関連付けられていてもよい。この場合、同じレジェンドであったとしてもスキルが異なればデッキも異なるようにしてもよい。
【0158】
また、データ記憶部300は、ゲーム大会に関するデータを記憶してもよい。例えば、データ記憶部300は、リーグ戦やトーナメント戦の対戦組み合わせを記憶してもよいし、各対戦の開始時間を記憶してもよい。また例えば、データ記憶部300は、ゲーム大会に出場するユーザのユーザIDのリストを記憶してもよい。
【0159】
第2実施形態のゲームでは、各ユーザの複数のデッキのうち、当該ユーザにより選択されたレジェンドに対応するデッキが使用される。例えば、ゲーム実行部303は、対戦の開始時に、ユーザが指定したレジェンドを取得する。本実施形態では、ユーザが指定したレジェンドは、管理ツールから入力されるので、ゲーム実行部303は、オブジェクトデータDT2に格納された複数のレジェンドのうち、管理ツールから入力されたレジェンドに対応するデッキを、ユーザが使用するデッキとして特定する。
【0160】
第2実施形態のゲームでは、2人のユーザが繰り返し対戦し、2人のユーザのうち勝利した方が対戦で使用したレジェンドが次の対戦で選択されることが制限される。制限とは、例えば、レジェンドを選択できないようにすることであり、レジェンドをゲームで使用できないようにすることである。例えば、ゲーム実行部303は、各ラウンドでのユーザの対戦結果を取得し、勝利した方のユーザが使用したレジェンドが次のラウンドで使用できないようにする。例えば、ゲーム実行部303は、レジェンドに対応するデッキが次のラウンドで使用できないようにする。
【0161】
なお、第2実施形態のゲームでは、ユーザ同士が対戦し、各ユーザの複数のレジェンドのうち、対戦相手により選択されたレジェンドが当該ユーザによって選択されることが制限されるようにしてもよい。ゲーム実行部303は、対戦相手が選択したレジェンドを、ゲーム端末10から取得してもよいし、管理者端末50から取得してもよい。ゲーム実行部303は、対戦相手のレジェンドの中から各ユーザが指定したレジェンドを特定し、当該レジェンドが次のラウンドで使用できないようにする。例えば、ゲーム実行部303は、レジェンドに対応するデッキが次のラウンドで使用できないようにする。
【0162】
第2実施形態のゲームシステムSによれば、各ユーザが複数のレジェンドを使用可能になるので、ゲームで使用するゲームオブジェクトに多様性を持たせることができる。更に、ユーザはレジェンドを選択すれば、ゲームで使用するデッキを選択することができるので、対戦前にデッキを入れ替えるといった手間を省くこともできる。例えば、デッキの多様性を設けようとするルール作りは難しく、3つのデッキで同じカードは3枚までしか入れられない等のルールを作成すると、制限カードなどどのデッキにも入るようなカードを各デッキに入れることができなくなり、かえってユーザのストレスとなっていた。これは、デッキの多様性を求めた結果であるが、必要以上に制限してしまうという問題があるため、レジェンドやスキルを異ならせるだけで対応するデッキは必然的に決まり、各デッキに汎用的に使えるようなカードはそれぞれに入れることができるようになる。このことによって、ユーザのストレスなくデッキの多様性を生むことができる。
【0163】
また、対戦で勝利したユーザは当該対戦で使用したレジェンドやデッキを使用できなくなるので、レジェンドやデッキの使用に制限がかかるので、ゲームの興趣性を向上させることができる。例えば、多様性のあるデッキを複数用意しても、ユーザがその中の1つのデッキしか選ばないのであれば、多様性のあるデッキを用意した意味がなくなってしまう。そこで、ユーザが勝利した場合は、そのデッキを使えなくさせることによって、多様性のあるデッキを使わせることができる。しかも、ユーザが負けた場合は、何度も使うことができる。例えば、ユーザの中で最強と思われるデッキが使えなくなることによって、負けた人が負け続けるといったことを防止することができ、ユーザのモチベーション低下を防ぐこともできる。
【0164】
また、対戦相手が選択したレジェンドやデッキが使用できなくなり、レジェンドやデッキの選択に制限がかかるので、ゲームの興趣性を向上させることができる。例えば、ゲームでは、全方向に強いデッキというものを作らせないようにしているが、思いもよらない組合せで、全方向に強いというデッキが作れてしまう場合がある。また、昨今の情報の伝搬の速さから、強いと言われているデッキに全ユーザが偏ってしまう可能性もある。その結果、対戦するデッキがすべて同じものとなってしまい、ユーザの対戦意欲が減退してしまうという問題がある。そこで、対戦前にレジェンドに対応するキャラクタやキャラクタに対応するスキルを使用させないことにより、対戦するデッキに多様性を持たせることができる。
【0165】
[7.その他変形例]
なお、本発明は、以上に説明した実施の形態に限定されるものではない。本発明の趣旨を逸脱しない範囲で、適宜変更可能である。
【0166】
例えば、実施形態では、サーバ30においてゲームの主な処理が実行され、サーバ30が本発明に係るゲーム制御装置に相当する場合を説明したが、サーバ30において実現される各機能は、ゲーム端末10において実現されてもよい。例えば、ゲーム端末10において、ゲームの主な処理が実行されるようにしてもよい。この場合、ゲーム端末10が本発明に係るゲーム制御装置に相当する。
【0167】
例えば、データ記憶部300がゲーム端末10で実現される場合、データ記憶部300は記憶部12を主として実現される。ゲーム端末10は、対戦部屋データDT1やオブジェクトデータDT2を記憶してもよい。また例えば、対戦部屋生成部301、識別情報生成部302、ゲーム実行部303、及びデータ取得部304がゲーム端末10で実現されてもよい。この場合、これら各機能は制御部11を主として実現される。ゲーム端末10は、ユーザから所定の操作を受け付けると対戦部屋を生成し、実施形態で説明した方法と同様にして複数の識別情報を生成する。また、ゲーム端末10は、ユーザの操作を取得してゲームプログラムを実行し、データ記憶部300に記憶された対戦部屋データDT1やオブジェクトデータDT2を取得する。
【0168】
また例えば、ゲーム端末10とサーバ30とで各機能が分担されてもよい。この場合、ゲーム端末10とサーバ30とで処理結果を送受信すればよい。例えば、ゲーム端末10において対戦部屋生成部301が実現され、サーバ30において識別情報生成部302が実現されてもよい。これとは逆に、サーバ30において対戦部屋生成部301が実現され、ゲーム端末10において識別情報生成部302が実現されてもよい。また例えば、実施形態や上記変形例で説明した各機能のうち、対戦部屋生成部301と識別情報生成部302以外の機能は省略してもよい。
【0169】
また例えば、カードゲームが実行される場合を説明したが、他のゲームに本発明に係る処理を適用してもよい。例えば、スポーツゲーム(例えば、野球、サッカー、テニス、アメリカンフットボール、バスケットボール、バレーボール等を題材としたゲーム)に本発明に係る処理を適用してもよい。また例えば、カードゲームやスポーツゲーム以外にも、アクションゲーム・ロールプレイングゲーム・格闘ゲーム等のように、ゲーム形式・ジャンルを問わず種々のゲームに本発明に係る処理を適用してもよい。
【0170】
[6.付記]
以上のような記載から、本発明は例えば以下のように把握される。
【0171】
1)本発明の一態様に係るゲームシステム(S)は、複数のユーザがゲームをプレイするために用いるグループを生成するグループ生成部(301)と、前記グループが生成された場合に、当該グループに関連付けられる複数の識別情報を生成する識別情報生成部(302)と、を含み、前記複数の識別情報には、それぞれ互いに異なる機能が対応付けられている。
【0172】
12)本発明の一態様に係るゲーム制御装置(10,30)は、複数のユーザがゲームをプレイするために用いるグループを生成するグループ生成部(301)と、前記グループが生成された場合に、当該グループに関連付けられる複数の識別情報を生成する識別情報生成部(302)と、を含み、前記複数の識別情報には、それぞれ互いに異なる機能が対応付けられている。
【0173】
13)本発明の一態様に係るプログラムは、1)~11)の何れかに記載のゲームシステム(S)又は12)に記載のゲーム制御装置(10,30)としてコンピュータを機能させる。
【0174】
14)本発明の一態様に係る情報記憶媒体は、13)のプログラムを記録したコンピュータで読み取り可能な情報記憶媒体である。
【0175】
1)又は12)~14)に係る発明によれば、グループが生成された場合に、グループに関連付けられる複数の識別情報が生成され、複数の識別情報にはそれぞれ互いに異なる機能が対応付けられているので、ゲームにおけるユーザの満足度を高めることができる。例えば、ユーザに対して何らかの機能が提供されることで、ゲームを見ることすらできないといったことを防止することができる。
【0176】
2)本発明の一態様では、各識別情報に対応付けられた機能の何れか1つは、前記ゲームのプレイを観戦するための観戦機能である。2)の態様によれば、ユーザがゲームを観戦することができるので、ゲームを観戦することすらできず不満を感じるといったことを防止することができる。
【0177】
3)本発明の一態様では、各識別情報に対応付けられた機能の何れか1つは、他のユーザと対戦するための対戦機能である。3)の態様によれば、ユーザが他のユーザと対戦することができるので、ゲームをプレイすることすらできず不満を感じるといったことを防止することができる。
【0178】
4)本発明の一態様では、各識別情報に対応付けられた機能の何れか1つは、他のユーザと協力して対戦するための協力機能である。4)の態様によれば、ユーザが他のユーザと協力することができるので、ゲームをプレイすることすらできず不満を感じるといったことを防止することができる。
【0179】
5)本発明の一態様では、前記ゲームは、前記複数のユーザでプレイされる第1ゲームパートと、第2ゲームパートと、を含み、各識別情報に対応付けられた機能は、前記第1ゲームパートに関する機能であり、各ユーザは、前記複数の識別情報の何れか1つと関連付けられ、自身と関連付けられた識別情報に対応する機能を利用可能であり、前記複数の識別情報には、ユーザが前記第2ゲームパートをプレイしても関連付けが維持される識別情報と、ユーザが前記第2ゲームパートをプレイした場合に関連付けが解除される識別情報と、が含まれる。5)の態様によれば、第2ゲームパートをプレイしても関連付けが維持される識別情報があるので、第2ゲームパートをプレイした後に、再び識別情報との関連付けをし直さなければならないといった煩雑さを防止することができる。また、第2ゲームパートをプレイした場合に関連付けが解除される識別情報については、ユーザがずっと識別情報と関連付けられているといった状態を防止することができる。
【0180】
6)本発明の一態様では、前記グループには、複数のサブグループが設定されており、各識別情報に対応付けられた機能の何れか1つは、前記サブグループごとに、当該サブグループに所属する複数のユーザが前記ゲームをプレイするための機能である。6)の態様によれば、サブグループごとに、当該サブグループに所属するユーザ同士でゲームがプレイされるので、好きなユーザ同士でゲームをプレイさせることができる。
【0181】
7)本発明の一態様では、前記ゲームは、前記複数のユーザでプレイされる第1ゲームパートと、第2ゲームパートと、を含み、各識別情報に対応付けられた機能は、前記第1ゲームパートに関する機能であり、前記第2ゲームパートは、前記サブグループに所属中のユーザによってプレイされることが制限される。7)の態様によれば、サブグループに所属中のユーザが第2ゲームパートをプレイすることが制限されるので、他のユーザが一緒にゲームをプレイしようと思っても、それに気づかずに第2ゲームパートをプレイしてしまうといったことを防止することができる。
【0182】
8)本発明の一態様では、前記ゲームでは、2人のユーザが先攻と後攻に分かれて対戦し、各識別情報に対応付けられた機能の何れか1つは、前記サブグループごとに、当該サブグループに所属する2人のユーザの少なくとも一方が先攻と後攻を決定して前記ゲームをプレイさせるための機能である。8)の態様によれば、ユーザが先攻と後攻の好きな方を選択することができるので、対戦の興趣性を向上させることができる。
【0183】
9)本発明の一態様では、前記ゲームシステムは、前記ユーザごとに、前記ゲームで使用可能な第1ゲームオブジェクトと、前記ゲーム内で前記第1ゲームオブジェクトを使用する第2ゲームオブジェクトと、の組み合わせが複数格納されたデータを取得するデータ取得手段(304)を更に含み、前記ゲームでは、各ユーザの複数の前記第2ゲームオブジェクトのうち、当該ユーザにより選択された第2ゲームオブジェクトに対応する第1ゲームオブジェクトが使用される。9)の態様によれば、各ユーザが複数のゲームオブジェクトを使用可能になるので、ゲームで使用するゲームオブジェクトに多様性を持たせることができる。更に、ユーザは第2ゲームオブジェクトを選択すれば、ゲームで使用する第1ゲームオブジェクトを選択することができるので、対戦前に第1ゲームオブジェクトを入れ替えるといった手間を省くこともできる。
【0184】
10)本発明の一態様では、前記ゲームでは、2人のユーザが繰り返し対戦し、前記2人のユーザのうち勝利した方が対戦で使用した第2ゲームオブジェクトが次の対戦で選択されることが制限される。10)の態様によれば、ゲームオブジェクトの使用に制限がかかるので、ゲームの興趣性を向上させることができる。
【0185】
11)本発明の一態様では、前記ゲームでは、ユーザ同士が対戦し、各ユーザの前記複数の第2ゲームオブジェクトのうち、対戦相手により選択された前記第2ゲームオブジェクトが当該ユーザによって選択されることが制限される。11)の態様によれば、ゲームオブジェクトの選択に制限がかかるので、ゲームの興趣性を向上させることができる。
【符号の説明】
【0186】
S ゲームシステム、N ネットワーク、10 ゲーム端末、30 サーバ、50 管理者端末、11,31,51 制御部、12,32,52 記憶部、13,33,53 通信部、14,54 操作部、15,55 表示部、G1 対戦モード選択画像、G2 対戦部屋モード画像、G3 対戦部屋画像、G4 観戦画像、G5 管理ツール画像、300 データ記憶部、301 対戦部屋生成部、302 識別情報生成部、303 ゲーム実行部、304 データ取得部、A30,A31,A32,A33 表示領域、B10 ランク戦ボタン、B11 フリー対戦ボタン、B12 フレンド対戦ボタン、B13 対戦部屋ボタン、B20 対戦部屋生成ボタン、B21 メンバ入室ボタン、B22 観戦ユーザ入室ボタン、B34 メンバボタン、B35 戦績ボタン、B36 コメントボタン、B37 退室ボタン、B38,B38A,B38B,B38C テーブル選択ボタン、B40,B40A,B40B,B40C テーブル選択ボタン、B52 ラウンド進行ボタン、D23,D24,D25 ダイアログ、DT1 対戦部屋データ、DT2 オブジェクトデータ、B232,B233 ラジオボタン、B234 キャンセルボタン、B235,B241,B251 決定ボタン、F50,F51,F52,F53,F54,F55,F230,F231,F240,F250 入力フォーム。