(58)【調査した分野】(Int.Cl.,DB名)
【発明を実施するための形態】
【0010】
本実施形態においては、1以上のプレイヤが「チーム」を編成し、1以上のチームが「連合」を形成するネットワークゲーム(以下、「ゲームG」とよぶ)を想定して説明する。ゲームGは、ウォー・シミュレーションゲーム(Wargame)である。プレイヤは、1以上のキャラクタを操作し、敵キャラクタと戦闘を行う。プレイヤは、ゲームGに参加するためには、ゲームサーバにプレイヤ登録をする必要がある。
【0011】
プレイヤはいずれかのチーム(同盟)に所属する。チームにはリーダー・プレイヤ(盟主)が設定される。プレイヤは傭兵、チームは傭兵部隊、連合は傭兵部隊が所属する王国、リーダー・プレイヤは傭兵隊長のイメージに近い。本実施形態においては4つの連合(勢力)が存在し、各連合は互いに勢力争いをしている。プレイヤは、個人としての戦績を競い合う。プレイヤは、戦果を上げやすいチーム、ひいては、戦果を上げやすい連合に加わることで個人としての戦績を上げやすくなる。
【0012】
プレイヤは、チームからいつでも離脱可能である。また、離脱後に、他のチームに所属することも可能である。同様にして、チームとしても、他の連合に移籍(鞍替え)することができる。
以下、チームが所属先の連合を移籍する場合を中心として説明する。
【0013】
図1は、ゲームシステム100のハードウェア構成図である。
ゲームシステム100においては、ゲームサーバ102に対して、複数のゲーム端末104a、104b、104c・・・104n(以下、まとめて言うときや特に区別しないときには「ゲーム端末104」と総称する)がインターネット106を介して接続される。本実施形態におけるゲーム端末104は、スマートフォンを想定している。ゲーム端末104は、携帯型のゲーム専用機であってもよいし、ラップトップPCなどの汎用コンピュータであってもよい。ゲーム端末104とインターネット106は無線接続されるが、有線接続されてもよい。ゲームのプレイヤにはプレイヤIDとよばれる一意のIDがあらかじめ付与されている。ゲームサーバ102は、各ゲーム端末104にゲームを提供する。
【0014】
図2は、チームの模式図である。
ゲームGにおいては、複数のチームが編成される。チームは1人以上のプレイヤにより編成される。プレイヤは、ゲームGにプレイヤ登録するとき、最初は、自分1人のチームに所属する。他のチームに所属したいときには、そのチームのリーダー・プレイヤ(以下、単に「リーダー」とよぶ)に加入申請する。加入申請が許可されれば、既存のチームのメンバーとなることができる。一方、自らが所属するチームに他のプレイヤを取り込むことで、リーダーとしてチームを拡大してもよい。
【0015】
チームおよびプレイヤには、チームID(TID)とプレイヤID(PID)が付与される。
図2に示すTID=X1のチーム(以下、「チーム(X1)」のように表記する)は、7人のプレイヤ(P1)〜プレイヤ(P7)を含む。プレイヤ(P1)がチーム(X1)のリーダーであり、プレイヤ(P2)はサブ・リーダー・プレイヤ(以下、単に「サブ・リーダー」とよぶ)である。チーム(X1)に所属するプレイヤ(P1)〜プレイヤ(P7)を「(チーム(X1))のメンバー」とよぶ。
チームの運営方針はリーダーが決める。サブ・リーダーは、リーダーに任命される。チームには必ずリーダーがいるが、サブ・リーダーは常設ではない。
【0016】
プレイヤ(P1)〜(P7)は、チーム(X1)のメンバーと相互協力して敵チームと戦う。ゲームGにおいては、プレイヤはキャラクタに攻撃や防御などの各種コマンドを設定することによりキャラクタを操作する。チーム(X1)の敵チームは、チーム(X1)とは異なる連合に所属するチームである。プレイヤは、戦闘によって経験値を得る。経験値が一定以上たまると、プレイヤが操作するキャラクタ(分身)のレベルがアップする。また、戦闘に勝利することにより、さまざまなリソースやアイテム、装備等(戦利品)を手に入れることもできる。リソースは、一種のゲームポイントであり、施設(後述)の建設・強化や装備購入の原資となる。
プレイヤは戦闘を繰り返しながら、キャラクタをレベルアップさせ、チームの施設(後述)やキャラクタの装備を整えることによりキャラクタを強くしていく。
【0017】
お互いに顔見知りのプレイヤたちが集まってチームを編成する場合もあれば、見知らぬプレイヤが集まってチームを編成する場合もある。いずれの場合も、ゲームGのチーム戦を通じて、各プレイヤは交流を深めることができる。
【0018】
チームは、共有財産としての設定情報108を有する。設定情報108は、チームの名称(ブランド)、チームとして共有する施設、所属先の連合、チームの規模(最大メンバー数)などである。チームの名称は、リーダーが自由に名付けることができる。たとえば、チーム(X1)の名前は「フォックス」であるとする。チームは、ゲームフィールドの一区画を占有し、ここにさまざまな施設を建設できる。施設の建設には時間とコストがかかる。メンバーがリソースを出資し合うことで建設コストを賄う。建設後の施設に追加投資することにより、施設をいっそう強化することもできる。
【0019】
たとえば、兵舎を建設・強化することでチームに参加可能なメンバー数を最大80人まで増加させることができる。また、各キャラクタの装備を強化する施設、経験値の蓄積速度を向上させる施設、ダメージを回復させる施設、攻撃施設などさまざまな施設を建設可能である。一般的には、チームに長く所属しているメンバーほどチームの強化・育成に貢献しているため、チームに対する愛着(忠誠心)が強くなると考えられる。また、チームが活躍すればするほど、チーム名「フォックス」のブランド価値も高まる。
【0020】
図3は、連合の模式図である。
連合には連合ID(AID)が付与される。上述したように、ゲームGには4つの連合(Y1)〜連合(Y4)があらかじめ用意される。連合(Y1)〜連合(Y4)は互いに戦闘を繰り返しながら勢力拡大を図っている。連合にも名称が付与されている。たとえば、連合(Y1)の名称は「パープル連合」であり、連合(Y2)の名称は「ブルー連合」である。
【0021】
図3においては、連合(Y1)にはチーム(X1)〜チーム(X4)の4つのチームが所属している。同様にして、連合(Y2)にはチーム(X5),チーム(X6)の2つのチームが所属し、連合(Y3)にはチーム(X7)〜チーム(X13)の6つのチームが所属し、連合(Y4)にはチーム(X13)のみが所属する。チーム(X1)のメンバーにとって、同じ連合(Y1)に所属するチーム(X2)〜チーム(X4)は共に戦う仲間であり、他の連合に所属するチーム(X5)〜チーム(X13)は敵である。
【0022】
チームに所属するメンバーの数やレベル、装備は多様であるが、連合(Y3)は、チーム数が多いので、比較的有力な勢力であると考えられる。したがって、連合(Y3)に所属するチームはゲームを優位に進めやすい。一方、連合(Y4)に唯一所属するチーム(X13)は、敵と戦う機会に恵まれやすい。このため、チーム(X13)のメンバーは豊富な戦闘経験によりキャラクタをレベルアップさせやすくなるかもしれない。
【0023】
なお、プレイヤはいずれかのチームに所属し、チームはいずれかの連合に所属する。1人のプレイヤが複数のチームに所属することはできない。また、1つのチームが複数の連合に所属することもできない。
【0024】
図4は、シーズンの模式図である。
ゲームサーバ102は、ゲームGを「シーズン」の単位で運営する。シーズンは3ヶ月単位で切り替わる。具体的には、1月から3月がシーズンS1、4月から6月がシーズンS2、7月から9月がシーズンS3、10月から12月がシーズンS4となる。シーズンが終了するタイミングでプレイヤの戦績がランキングされる。戦績はレベルであってもよいし、敵の撃破数や被弾率、プレイ時間などさまざまなパラメータに基づいて任意に決定されればよい。
【0025】
図5は、チームの連合移籍を説明するための模式図である。
チームは、リーダーの発議により、所属先の連合を変更(以下、「連合移籍」とよぶ)することもできる。連合移籍はシーズンの変わり目や、シーズン中の所定地点において実行可能である。
図5においては、チーム(X1)が連合(Y1)から連合(Y2)に移籍する状況を示す。
【0026】
チーム(X1)のリーダー(P1)は、連合(Y2)への移籍をメンバーに提案する。このとき、チーム(X1)の他のメンバーは、リーダー(P1)に従ってもよいし、従わなくてもよい。チーム(X1)の設定情報108は、リーダー(P1)に付随する。すなわち、リーダー(P1)による移籍提案は、実質的には、移籍決定通知であり、少なくともリーダー(P1)を含むチーム(X1)は連合(Y2)に移籍する。この連合移籍の決定に対して、チーム(X1)のメンバーが従うか否かは各自の判断となる。すべてのメンバーがリーダー(P1)とともに連合移籍するかもしれないし、一部のメンバーのみが連合移籍するかもしれないし、リーダー以外の全てのメンバーが残留を選択するかもしれない。リーダーが連合移籍を提案したとき、リーダーは設定情報108を持って移籍するため、リーダー(P1)にしたがって連合移籍したプレイヤは、それまでのチームの設定情報108(共有財産)による恩恵(ゲームの進行にともなう有利な効果)を引き続き享受できる。リーダー(P1)に従わなかったプレイヤは、チーム(X1)から離脱し、連合(Y1)に残留する。リーダー(P1)が設定情報108をもっていってしまうので、残留者のチームは初期状態からの育成となる。離脱時の処理の詳細は後述する。
【0027】
図6は、ゲームシステム100の機能ブロック図である。
上述のように、ゲームシステム100は、ゲームサーバ102およびゲーム端末104を含む。ゲーム端末104およびゲームサーバ102の各構成要素は、CPU(Central Processing Unit)および各種コプロセッサなどの演算器、メモリやストレージといった記憶装置、それらを連結する有線または無線の通信線を含むハードウェアと、記憶装置に格納され、演算器に処理命令を供給するソフトウェアによって実現される。コンピュータプログラムは、デバイスドライバ、オペレーティングシステム、それらの上位層に位置する各種アプリケーションプログラム、また、これらのプログラムに共通機能を提供するライブラリによって構成されてもよい。以下に説明する各ブロックは、ハードウェア単位の構成ではなく、機能単位のブロックを示している。
ゲームサーバ102は、ウェブサーバを含む構成であってもよいし、ゲーム端末104は、携帯型の通信端末と、これにインストールされたウェブブラウザを含む構成であってもよい。
【0028】
(ゲームサーバ102)
ゲームサーバ102は、通信部110、データ処理部112およびデータ格納部114を含む。
通信部110は、インターネット106を介してゲーム端末104との通信処理を担当する。データ格納部114は各種データを格納する。データ処理部112は、通信部110により取得されたデータおよびデータ格納部114に格納されているデータに基づいて各種処理を実行する。データ処理部112は、通信部110およびデータ格納部114のインタフェースとしても機能する。データ格納部114は、ゲームプログラムのほか、各プレイヤのプレイ状態を示す情報を格納する。
【0029】
データ格納部114は、ゲームデータ格納部116、プレイヤデータ格納部118およびチームデータ格納部120を含む。
ゲームデータ格納部116は、ゲームプログラムを格納する。プレイヤデータ格納部118は、各プレイヤのレベル、装備、アイテム、リソースなど、プレイヤごとのゲームの進捗状況を示す情報を格納する。チームデータ格納部120は、チームおよび連合の編成を示すチーム情報やチームの設定情報108を格納する。チーム情報については
図7に関連して後述する。
【0030】
通信部110は、提案受信部122、提案通知部124および諾否受信部126を含む。
提案受信部122は、リーダーから連合移籍など、設定情報108の設定変更に関する提案(以下、「変更提案」とよぶ)を受信する。提案通知部124は、変更提案をチームのリーダー以外のメンバーに通知する。諾否受信部126は、変更提案に対する諾否(イエス/ノー)をメンバーのゲーム端末104から受信する。
【0031】
データ処理部112は、プレイヤ登録部128、チーム設定部130およびゲーム制御部132を含む。
プレイヤ登録部128は、ゲーム端末104から通信部110を介してプレイヤ登録を受け付ける。プレイヤ登録部128は、プレイヤ登録がリクエストされると、プレイヤにプレイヤIDとチームIDを付与し、いずれかの連合IDと対応づけて、プレイヤデータ格納部118とチームデータ格納部120に登録する。ゲームGのゲームモジュールをゲーム端末104にインストールするときプレイヤ登録が自動的にリクエストされる。
【0032】
チーム設定部130は、1人以上のプレイヤからなるチームを編成する。また、チーム設定部130は、チームと連合を対応づける。ゲーム制御部132は、ゲームごと、プレイヤごとにゲームの進捗状態を管理する。ゲームの進捗状態は、たとえば、各プレイヤのレベルや戦績、リソースなどである。
【0033】
(ゲーム端末104)
ゲーム端末104は、ユーザインタフェース部134、通信部136、データ処理部138およびデータ格納部140を含む。
ユーザインタフェース部134は、タッチパネルを介してプレイヤからの操作を受け付けるほか、画像表示や音声出力など、ユーザインタフェースに関する処理を担当する。通信部136は、インターネット106を介してゲームサーバ102および他のゲーム端末104との通信処理を担当する。データ格納部140は各種データを格納する。データ処理部138は、ユーザインタフェース部134や通信部136により取得されたデータ、データ格納部140に格納されているデータに基づいて各種処理を実行する。データ処理部138は、ユーザインタフェース部134、通信部136およびデータ格納部140のインタフェースとしても機能する。
【0034】
通信部136は、提案送信部142、提案受信部144および諾否送信部146を含む。
提案送信部142は、リーダーによる変更提案をゲームサーバ102に送信する。提案受信部144は、リーダーによる変更提案を提案通知部124から受信する。諾否送信部146は、変更提案に対するメンバーの諾否を送信する。
【0035】
データ処理部138は、ゲーム実行部148を含む。
ゲーム実行部148は、ゲームサーバ102と連携してゲームの進行を制御する。ゲーム実行部148は、ゲームサーバ102からゲーム制御部132の機能の一部としてダウンロードされるソフトウェアモジュールとして形成されてもよい。
通信部136は、ゲームサーバ102から各種ゲーム情報を取得し、データ処理部138はユーザインタフェース部134にゲーム画面を表示させる。また、ユーザインタフェース部134はユーザによる各種入力を検出し、データ処理部138は入力情報をゲームサーバ102に通信部136を介して通知する。この入力情報に応じて、ゲームサーバ102のゲーム制御部132はゲーム端末104のゲーム実行部148と連携してゲームの進行を制御する。
【0036】
ユーザインタフェース部134は、プレイヤからの入力を受け付ける入力部152と、プレイヤに対して画像や音声等の各種情報を出力する出力部154を含む。入力部152は、主として、画面に対するプレイヤのタッチ操作を入力として検出する。
【0037】
図7は、チーム情報156のデータ構造図である。
チーム情報156は、チームデータ格納部120に格納される。チーム設定部130は、プレイヤ、チームおよび連合の対応関係をチーム情報156に記録する。
図7の場合、プレイヤ(P1)は、チーム(X1)のリーダーであり、チーム(X1)は連合(Y1)に所属している。ゲーム制御部132は、チーム(チームID)とチームの設定情報108を対応づけ、連合(連合ID)と連合の設定情報を対応づける。同様に、ゲーム制御部132は、プレイヤ(プレイヤID)とゲームの進捗状態(レベルや装備等)をプレイヤデータ格納部118において対応付ける。
【0038】
図8は、諾否選択画面158の画面図である。
諾否選択画面158は、リーダー以外のメンバーのゲーム端末104に表示される。リーダーは、変更提案を提案送信部142によりゲームサーバ102に送信する。ゲームサーバ102の提案受信部122は変更提案を受信し、提案通知部124はリーダーと同じチームに所属する他のメンバーに変更提案を送信する。メンバーのゲーム端末104において、提案受信部144が変更提案を受信したとき、出力部154は諾否選択画面158を表示させる。メンバーは、諾否選択画面158において、リーダーの変更提案に対する承認(YES)または拒否(NO)をタッチ入力する。諾否送信部146は、プレイヤIDとともに諾否(YES/NO)(以下、「諾否情報」とよぶ)をゲームサーバ102に送信する。
【0039】
図8においては、チーム(X1)(チーム名称「フォックス」)のリーダーが、連合(Y1)(連合名称「パープル連合」)から連合(Y2)(連合名称「ブルー連合」)への移籍を提案したときに、チーム(X1)に所属するメンバーの104に表示される。
【0040】
図9は、連合移籍の処理過程を示すフローチャートである。
図9に示す処理は、ゲームサーバ102がリーダーから変更提案を受信したときに実行される。提案通知部124は、チーム情報156を参照し、リーダーと同一チームに所属する他のメンバーのゲーム端末104に変更提案を配信する(S10)。諾否受信部126は、各ゲーム端末104からの諾否情報を受信し、これを集計する(S12)。制限時間以内に諾否情報を送信しなかったメンバーについては、承諾したものと見なしてもよい。
【0041】
拒否者、すなわち、諾否選択画面158において拒否を入力したメンバーがいるときには(S14のY)、チーム設定部130は拒否者を含む新チームを編成する(S16)。たとえば、プレイヤP3のみが拒否したときには、プレイヤP3のみをメンバーとする新チームが編成され、チーム設定部130は新チームにチームIDを付与する。複数のプレイヤ、たとえば、プレイヤP3とP4が拒否したときには、プレイヤP3、P4を含む新チームが編成され、同様にチームIDが付与される。
【0042】
新チーム編成後、チーム設定部130は所定の選択条件(後述)にしたがって新チームのリーダーを選択する(S18)。チーム設定部130は、1以上の承認者を含むチームを設定し、このチームの所属先の連合を変更する(S20)。拒否がなければ(S14のN)、処理はS20にスキップされる。
【0043】
図10は、連合移籍にともなうチームの分裂を説明するための模式図である。
図10では、チーム(X1)のリーダー(P1)が連合(Y1)から連合(Y2)への連合移籍を提案したとする。6人の残りメンバーのうち、プレイヤ(P2),プレイヤ(P3),プレイヤ(P5),プレイヤ(P6)は承認し、プレイヤ(P4),プレイヤ(P7)は拒否したとする。
【0044】
チーム設定部130は、拒否したプレイヤ(P4),プレイヤ(P7)をメンバーとする新たなチームを編成し、チームID=X14を付与する。チーム情報156においてチーム(X14)は連合(Y1)に対応づけられる。また、チーム設定部130は、プレイヤ(P4),プレイヤ(P7)のいずれかを新チーム(X14)のリーダーとして所定の選択条件にしたがって自動的に選ぶ。本実施形態における選択条件は下記の通りである。
(1)残留チーム(X14)に旧チーム(X1)のサブ・リーダーが含まれているときには、サブ・リーダーがチーム(X14)のリーダーとなる。
(2)旧チーム(X1)のサブ・リーダーが含まれていないときには、チーム(X14)のメンバーのうちもっともレベルの高いメンバーが新リーダーとなる。
(3)もっとも高いレベルに二人以上のメンバーがいるときには、それらのメンバーからランダムに選択する。
【0045】
チーム(X14)のサブ・リーダーは、チーム(X14)のリーダーに指名される。チーム設定部130は、リーダー以外のメンバーのうちもっともレベルの高いメンバーをサブ・リーダーとして選んでもよいし、ランダムに選択してもよい。
【0046】
このようにチーム設定部130は、チーム(X1)からリーダーの変更提案を拒否したプレイヤを追放する。チーム(X1)の設定情報108も、拒否者の数に関わらず、リーダー(P1)とともに連合(Y2)に移籍後のチーム(X1)の共有資産となる。
【0047】
以上、実施形態に基づいてゲームシステム100を説明した。
本実施形態によれば、リーダーはメンバーを引き連れてある連合から別の連合へとチームを移籍させることができる。リーダーがいったんチームを脱退して、移籍先の連合で再びチームを作り、旧メンバーを呼び寄せる方式も考えられるが、この場合、チームはいったん解体されてしまう。移籍後に旧メンバーが再集結するかわからないため、リーダーは連合移籍を決断しにくくなると考えられる。また、リーダーについていくプレイヤにとっても、リーダーの移籍後に、リーダーの新チームに改めて加入申請をするのは煩瑣である。
【0048】
本実施形態においては、リーダーが連合移籍を提案したとき、メンバーは諾否選択画面158において承認または拒否を選択するだけで、リーダーと行動をともにするか、チームから離脱するかを実質的にはワンタッチで選択できる。リーダーの提案は決定事項であるが、その決定に従うか否かは各自の自由である。チームを離脱したときにも、拒否者だけで新たなチームが編成され、リーダーも自動的に選ばれるため、離脱にともなう手続負担が大きく軽減される。集団離脱しやすいため、リーダーのチーム運営に緊張感をもたせることができる。
【0049】
リーダーは、チームの共有財産である設定情報108を持ち運ぶ権利を有する。ブランドやチーム規模(メンバー枠)などは、チームに対するメンバーの投資や献身によって育まれる。このため、メンバーはリーダーに従わない自由はあるものの、設定情報108を失う覚悟が必要である。設定情報108が充実したチーム、いわば、伝統・歴史のあるチームほど拒否者(離脱者)が出にくく、リーダーの権威が高まると考えられる。また、チームに長期にわたって献身してきた古参のプレイヤほど離散しにくくなると考えられる。プレイヤに提案拒否の自由を与えつつも、リーダーの権威を醸成しやすいシステムとなっている。
【0050】
リーダーは、メンバーを強制的に連れて行くことはできないが、チーム運営を上手に行えば孤立もしにくい。本実施形態におけるゲームシステム100によれば、チームとしての一体性とメンバーの自由度のバランスを両立させやすくなる。
【0051】
なお、本発明は上記実施形態や変形例に限定されるものではなく、要旨を逸脱しない範囲で構成要素を変形して具体化することができる。上記実施形態や変形例に開示されている複数の構成要素を適宜組み合わせることにより種々の発明を形成してもよい。また、上記実施形態や変形例に示される全構成要素からいくつかの構成要素を削除してもよい。
【0052】
複数のゲーム端末104と1つのゲームサーバ102によりゲームシステム100が構成されるとして説明したが、ゲーム端末104の機能の一部はゲームサーバ102により実現されてもよいし、ゲームサーバ102の機能の一部がゲーム端末104に割り当てられてもよい。また、ゲームサーバ102やゲーム端末104以外の第3の装置が、機能の一部を担ってもよい。
図6において説明したゲーム端末104の各機能とゲームサーバ102の各機能の集合体は大局的には1つの「情報処理装置」として把握することも可能である。1つまたは複数のハードウェアに対して、本発明を実現するために必要な複数の機能をどのように配分するかは、各ハードウェアの処理能力やゲームシステム100に求められる仕様等に鑑みて決定されればよい。
【0053】
連合移籍に際し、拒否者のグループのリーダーは、所定期間におけるログイン回数、旧チームの施設建設・強化への貢献度(たとえば、累計出資額)、旧チームへの所属期間の長さ、戦闘参加率や敵機撃破数などの戦績などさまざまな選択条件に基づいて選ばれてもよい。拒否者のグループのリーダーは、離脱グループのメンバーの間での立候補、推薦、多数決により選んでもよいし、最初に提案拒否を表明したプレイヤを新チームのリーダーとしてもよい。
【0054】
リーダーの交代を可能としてもよい。たとえば、シーズンごとにリーダーを輪番制で選んでもよい。メンバーがリーダー変更を提案し、これに過半数のメンバーが賛成したとき、リーダーを解任できるとしてもよい。チーム設定部130は、解任動議を受けると、メンバーの賛否を集計し、集計結果に基づいてチーム情報156を更新することによりリーダーを変更する。新リーダーは、上述の選択条件にしたがって選んでもよい。
【0055】
チーム移籍以外にも、リーダーはさまざまな変更提案が可能である。たとえば、あるチームと別のチームを合併することでより強大なチームを形成することができる。チーム(X1)のリーダー(P1)とチーム(X2)のリーダー(P8)が合併に同意したとき、リーダー(P1),リーダー(P2)はそれぞれが率いるチームのメンバーに合併を提案する。合併を拒否したプレイヤはチームから追放され、新たなチームが編成される。そして、合併を承認したメンバーだけの新チーム(合併チーム)が編成される。チーム設定部130は、新チームにチームIDを付与することで、2つのチームを合併させる。合併されたチームのリーダーは、二人の旧リーダーの話し合いにより決めてもよいし、チーム設定部130が選択条件にしたがって選んでもよい。リーダーの合併提案は決定事項であるが、その決定に従うか否かも各自の自由である。
【0056】
リーダーは、チーム内における施設の建設や強化も提案する。上述したように、施設を建設・強化することにより、プレイヤが操作するキャラクタが強化されることもあれば、キャラクタのダメージが回復することもある。施設の建設・強化はプレイヤに有利な効果をもたらす。施設建設・強化の承認者は、そのための出資を求められる。拒否者は出資を求められないが施設を利用することはできない。このように施設の建設・強化という変更提案を受け入れたメンバーのみ、その変更提案に基づいてゲームの進行状態が変化するとしてもよい。上記例の場合、出資を求められるという負担や施設の利用にともなう効果がゲームの進行状態に影響することになる。一方、拒否者には負担も恩恵もない。チーム設定部130は、施設の建設・強化の提案であっても、拒否者をチームから追放するとしてもよい。また、提案拒否にどのようなペナルティを与えるかはリーダーが設定してもよい。
【0057】
リーダーは、他のチームとのチーム戦を提案してもよい。たとえば、チーム(X1)のリーダー(P1)が、敵連合(Y2)に所属するチーム(X5)との対戦を提案したとする。このときは、承認者のみが出撃し、拒否者は防衛に専念するとしてもよい。
【0058】
ゲーム制御部132は、リーダーの提案の拒否者に対してさまざまなペナルティを与えてもよい。たとえば、他のチームとの対戦提案を拒否したプレイヤに対して、一定期間の戦闘参加禁止(謹慎)を課してもよいし、プレイヤの保有するリソースの一部をチームのために強制的に拠出させてもよい。一方、リーダーの提案の承認者に対して、ゲーム制御部132はメリットを与えてもよい。たとえば、リーダーのリソースの一部を承認者に配分してもよい。このような方法によれば、アメとムチによる組織のコントロールが可能となる。
【0059】
本実施形態においては、リーダーの提案は決定通知である。各メンバーは、この決定通知に従うか否かを選択できるものの、決定そのものを覆すことはできない。変形例として、リーダーの提案に対して拒否権を有するメンバーが含まれてもよい。たとえば、チームへの所属期間が所定時間以上のプレイヤや、戦績や出資額が一定条件をクリアしたプレイヤに対して、ゲーム制御部132は拒否権(発言権)を付与してもよい。拒否権を有するプレイヤが諾否選択画面158において拒否を選択すると、リーダーは提案を実行できなくなる。
【0060】
リーダーの提案は、全員一致または過半数賛成でなければ実行されないとしてもよい。リーダーの権力に対してさまざまな制限を加えることにより、リーダーとメンバーのパワーバランスを調整してもよい。
【0061】
施設を建設・強化すると、メンバーには装備強化などの恩恵が付与される。しかし、チームに加入して、恩恵だけを享受してそのあとに別のチームに簡単に移ってしまうという不誠実な行動も想定可能である。そこで、チームに加入してから所定の認定条件が満たされるまでは、施設などのチームの設定情報108にともなう恩恵を付与しないとしてもよい。たとえば、チームに加入してから所定時間が経過すること、チームのために所定数の敵機を撃破すること、リーダーから承認されること、3人以上のメンバーにより推薦されること、などの認定条件が考えられる。チーム設定部130は、チーム情報156においてプレイヤごとに所属チームの認定条件をクリアしているか否かを記録しておく。ゲーム制御部132は、設定情報108にともなう恩恵(たとえば、施設利用権や施設から定期的に提供されるリソースなど)を、認定条件をクリアしているプレイヤのみに提供する。
【0062】
本実施形態においては、連合移籍に際し、設定情報108はリーダーに付随するものとして説明した。変形例として、設定情報108の一部が離脱したメンバーに付与されてもよい。たとえば、一部の施設や、装備、リソースなどが離脱メンバーの新チームの設定情報108として付与されてもよい。
【0063】
リーダーは、提案を撤回できてもよい。リーダーは、提案をし、メンバーの賛成状況を確認の上、提案を実行するか否かを決めてもよい。このような制御方法によれば、リーダーはメンバーの意思を尊重しながらチーム運営をすることができる。リーダーに多くの権限を設定するチームと、メンバーの意思を尊重するチームが混在してもよい。不満分子を逐一追放する純化路線でチームを運営してもよいし、戦闘で力を発揮してくれさえすればある程度のわがままは許すというチーム運営も考えられる。
【0064】
連合移籍に際しては、移籍したチームに新たなチームIDを付与してもよい。たとえば、
図10に示す場合において、チーム(X1)(連合(Y1))のリーダー(P1)が、連合(Y2)への移籍を提案するとき、移籍後のチームIDには(X1)とは異なる新たなチームID(たとえば、X15)が付与されてもよい。この場合、チーム情報156においてはチーム(X15)と承認者のプレイヤIDが対応づけられる。旧チームの設定情報108もチーム(X15)に対応づけられる。一方、残留した拒否者は、新たなチームを編成するがこのチームには引き続きチームID=X1が付与されてもよい。移籍したチーム(X15)は、チームIDは変更となるが、チーム名称「フォックス」などの設定情報108は維持される。
【0065】
本実施形態においては、ウォーシミュレーションとしてのゲームGを対象として説明したが、シミュレーションゲームに限らず、スポーツゲームやロールプレイングゲーム、アクションゲームなど他のタイプのゲームにも同様に本発明を応用可能である。
【解決手段】ゲームシステムにおいて、ゲームサーバは複数のゲーム端末とインターネットを介して接続される。1以上のプレイヤによりチームが編成される。チームは、競合関係にある複数の連合のうちのいずれかに所属する。チームのリーダーが連合の変更を提案したとき、その提案に対してチームのメンバーは承諾または拒否の意思表示をする。そして、リーダーと承認者のみを含むチームとして、所属先の連合へ移籍する。一方、拒否者グループは、新たなチームとして編成される。