JP6187670B1 - ゲームサーバおよびゲームプログラム - Google Patents

Abstract

【課題】 ネットワークゲームにおいて、多数のプレイヤにより構成されるチームの新しい運営方法を提案する。【解決手段】ゲームシステムにおいて、ゲームサーバは複数のゲーム端末とインターネットを介して接続される。１以上のプレイヤによりチームが編成される。チームは、競合関係にある複数の連合のうちのいずれかに所属する。チームのリーダーが連合の変更を提案したとき、その提案に対してチームのメンバーは承諾または拒否の意思表示をする。そして、リーダーと承認者のみを含むチームとして、所属先の連合へ移籍する。一方、拒否者グループは、新たなチームとして編成される。【選択図】図５

Description

本発明は、ネットワークゲームにおけるチーム編成のための技術、に関する。

通信端末としてだけでなくゲーム端末としてのスマートフォンの利用も一般化している。スマートフォンで親しまれているネットワークゲームは、ゲームサーバに構築されるプラットフォームにスマートフォンからアクセスすることで提供される。ネットワークゲームは、キャラクタの育成、他のプレイヤとの協力や競争、カードやアイテムの収集を重視した内容であることが多い。

ネットワークゲームには、複数のプレイヤによりチームを編成し、チーム戦を実行するものがある（特許文献１，２参照）。特許文献１では、クランとよばれるチームにおいて、クランマスターとよばれるリーダー・プレイヤが設定される。クランマスターは、クランのメンバー編成につき強い権限を握る（段落［００２６］等参照）。特許文献２では、チームのメンバー構成が硬直的になるのを防ぐため、ログイン回数が少ないなどのアクティブではないプレイヤをチームから排除する仕組みを提案する（段落［００２６］［００２７］等参照）。

特開２０１２−５５４３５号公報 特開２０１３−１１１２８１号公報

リーダーが無制限に強権を行使すると、メンバーはチームへの献身意欲を失ってしまう可能性がある。一方、リーダーの権限が弱すぎると、チームの統一性が失われてしまう可能性もある。本発明者らは、メンバーが自らの意思を反映させやすく、かつ、リーダーがメンバーの総意に基づいてチームを運営する仕組みを提供することが望ましいと考える。

本発明は、上記課題認識に基づいて完成された発明であり、その主たる目的は、ネットワークゲームにおいて、多数のプレイヤにより構成されるチームの新しい運営方法を提案することにある。

本発明のある態様におけるゲームサーバは、複数のゲーム端末と通信ネットワークを介して接続される。
このゲームサーバは、１以上のプレイヤを含むチームを編成するチーム設定部と、リーダー・プレイヤのゲーム端末から、チームの設定情報の変更提案を受信する提案受信部と、リーダー・プレイヤと同一チームに所属するメンバー・プレイヤのゲーム端末に対して、変更提案を送信する提案通知部と、メンバー・プレイヤのゲーム端末から、変更提案に対する諾否を受信する諾否受信部と、変更後の設定情報に基づいて、変更提案を承諾したメンバー・プレイヤのゲームの進行状態を変化させるゲーム制御部と、を備える。

本発明によれば、ネットワークゲームにおけるチームの運営を円滑化しやすくなる。

ゲームシステムのハードウェア構成図である。 チームの模式図である。 連合の模式図である。 シーズンの模式図である。 チームの連合移籍を説明するための模式図である。 ゲームシステムの機能ブロック図である。 チーム情報のデータ構造図である。 諾否選択画面の画面図である。 連合移籍の処理過程を示すフローチャートである。 連合移籍にともなうチームの分裂を説明するための模式図である。

本実施形態においては、１以上のプレイヤが「チーム」を編成し、１以上のチームが「連合」を形成するネットワークゲーム（以下、「ゲームＧ」とよぶ）を想定して説明する。ゲームＧは、ウォー・シミュレーションゲーム（Wargame）である。プレイヤは、１以上のキャラクタを操作し、敵キャラクタと戦闘を行う。プレイヤは、ゲームＧに参加するためには、ゲームサーバにプレイヤ登録をする必要がある。

プレイヤはいずれかのチーム（同盟）に所属する。チームにはリーダー・プレイヤ（盟主）が設定される。プレイヤは傭兵、チームは傭兵部隊、連合は傭兵部隊が所属する王国、リーダー・プレイヤは傭兵隊長のイメージに近い。本実施形態においては４つの連合（勢力）が存在し、各連合は互いに勢力争いをしている。プレイヤは、個人としての戦績を競い合う。プレイヤは、戦果を上げやすいチーム、ひいては、戦果を上げやすい連合に加わることで個人としての戦績を上げやすくなる。

プレイヤは、チームからいつでも離脱可能である。また、離脱後に、他のチームに所属することも可能である。同様にして、チームとしても、他の連合に移籍（鞍替え）することができる。
以下、チームが所属先の連合を移籍する場合を中心として説明する。

図１は、ゲームシステム１００のハードウェア構成図である。
ゲームシステム１００においては、ゲームサーバ１０２に対して、複数のゲーム端末１０４ａ、１０４ｂ、１０４ｃ・・・１０４ｎ（以下、まとめて言うときや特に区別しないときには「ゲーム端末１０４」と総称する）がインターネット１０６を介して接続される。本実施形態におけるゲーム端末１０４は、スマートフォンを想定している。ゲーム端末１０４は、携帯型のゲーム専用機であってもよいし、ラップトップＰＣなどの汎用コンピュータであってもよい。ゲーム端末１０４とインターネット１０６は無線接続されるが、有線接続されてもよい。ゲームのプレイヤにはプレイヤＩＤとよばれる一意のＩＤがあらかじめ付与されている。ゲームサーバ１０２は、各ゲーム端末１０４にゲームを提供する。

図２は、チームの模式図である。
ゲームＧにおいては、複数のチームが編成される。チームは１人以上のプレイヤにより編成される。プレイヤは、ゲームＧにプレイヤ登録するとき、最初は、自分１人のチームに所属する。他のチームに所属したいときには、そのチームのリーダー・プレイヤ（以下、単に「リーダー」とよぶ）に加入申請する。加入申請が許可されれば、既存のチームのメンバーとなることができる。一方、自らが所属するチームに他のプレイヤを取り込むことで、リーダーとしてチームを拡大してもよい。

チームおよびプレイヤには、チームＩＤ（ＴＩＤ）とプレイヤＩＤ（ＰＩＤ）が付与される。図２に示すＴＩＤ＝Ｘ１のチーム（以下、「チーム（Ｘ１）」のように表記する）は、７人のプレイヤ（Ｐ１）〜プレイヤ（Ｐ７）を含む。プレイヤ（Ｐ１）がチーム（Ｘ１）のリーダーであり、プレイヤ（Ｐ２）はサブ・リーダー・プレイヤ（以下、単に「サブ・リーダー」とよぶ）である。チーム（Ｘ１）に所属するプレイヤ（Ｐ１）〜プレイヤ（Ｐ７）を「（チーム（Ｘ１））のメンバー」とよぶ。
チームの運営方針はリーダーが決める。サブ・リーダーは、リーダーに任命される。チームには必ずリーダーがいるが、サブ・リーダーは常設ではない。

プレイヤ（Ｐ１）〜（Ｐ７）は、チーム（Ｘ１）のメンバーと相互協力して敵チームと戦う。ゲームＧにおいては、プレイヤはキャラクタに攻撃や防御などの各種コマンドを設定することによりキャラクタを操作する。チーム（Ｘ１）の敵チームは、チーム（Ｘ１）とは異なる連合に所属するチームである。プレイヤは、戦闘によって経験値を得る。経験値が一定以上たまると、プレイヤが操作するキャラクタ（分身）のレベルがアップする。また、戦闘に勝利することにより、さまざまなリソースやアイテム、装備等（戦利品）を手に入れることもできる。リソースは、一種のゲームポイントであり、施設（後述）の建設・強化や装備購入の原資となる。
プレイヤは戦闘を繰り返しながら、キャラクタをレベルアップさせ、チームの施設（後述）やキャラクタの装備を整えることによりキャラクタを強くしていく。

お互いに顔見知りのプレイヤたちが集まってチームを編成する場合もあれば、見知らぬプレイヤが集まってチームを編成する場合もある。いずれの場合も、ゲームＧのチーム戦を通じて、各プレイヤは交流を深めることができる。

チームは、共有財産としての設定情報１０８を有する。設定情報１０８は、チームの名称（ブランド）、チームとして共有する施設、所属先の連合、チームの規模（最大メンバー数）などである。チームの名称は、リーダーが自由に名付けることができる。たとえば、チーム（Ｘ１）の名前は「フォックス」であるとする。チームは、ゲームフィールドの一区画を占有し、ここにさまざまな施設を建設できる。施設の建設には時間とコストがかかる。メンバーがリソースを出資し合うことで建設コストを賄う。建設後の施設に追加投資することにより、施設をいっそう強化することもできる。

たとえば、兵舎を建設・強化することでチームに参加可能なメンバー数を最大８０人まで増加させることができる。また、各キャラクタの装備を強化する施設、経験値の蓄積速度を向上させる施設、ダメージを回復させる施設、攻撃施設などさまざまな施設を建設可能である。一般的には、チームに長く所属しているメンバーほどチームの強化・育成に貢献しているため、チームに対する愛着（忠誠心）が強くなると考えられる。また、チームが活躍すればするほど、チーム名「フォックス」のブランド価値も高まる。

図３は、連合の模式図である。
連合には連合ＩＤ（ＡＩＤ）が付与される。上述したように、ゲームＧには４つの連合（Ｙ１）〜連合（Ｙ４）があらかじめ用意される。連合（Ｙ１）〜連合（Ｙ４）は互いに戦闘を繰り返しながら勢力拡大を図っている。連合にも名称が付与されている。たとえば、連合（Ｙ１）の名称は「パープル連合」であり、連合（Ｙ２）の名称は「ブルー連合」である。

図３においては、連合（Ｙ１）にはチーム（Ｘ１）〜チーム（Ｘ４）の４つのチームが所属している。同様にして、連合（Ｙ２）にはチーム（Ｘ５），チーム（Ｘ６）の２つのチームが所属し、連合（Ｙ３）にはチーム（Ｘ７）〜チーム（Ｘ１３）の６つのチームが所属し、連合（Ｙ４）にはチーム（Ｘ１３）のみが所属する。チーム（Ｘ１）のメンバーにとって、同じ連合（Ｙ１）に所属するチーム（Ｘ２）〜チーム（Ｘ４）は共に戦う仲間であり、他の連合に所属するチーム（Ｘ５）〜チーム（Ｘ１３）は敵である。

チームに所属するメンバーの数やレベル、装備は多様であるが、連合（Ｙ３）は、チーム数が多いので、比較的有力な勢力であると考えられる。したがって、連合（Ｙ３）に所属するチームはゲームを優位に進めやすい。一方、連合（Ｙ４）に唯一所属するチーム（Ｘ１３）は、敵と戦う機会に恵まれやすい。このため、チーム（Ｘ１３）のメンバーは豊富な戦闘経験によりキャラクタをレベルアップさせやすくなるかもしれない。

なお、プレイヤはいずれかのチームに所属し、チームはいずれかの連合に所属する。１人のプレイヤが複数のチームに所属することはできない。また、１つのチームが複数の連合に所属することもできない。

図４は、シーズンの模式図である。
ゲームサーバ１０２は、ゲームＧを「シーズン」の単位で運営する。シーズンは３ヶ月単位で切り替わる。具体的には、１月から３月がシーズンＳ１、４月から６月がシーズンＳ２、７月から９月がシーズンＳ３、１０月から１２月がシーズンＳ４となる。シーズンが終了するタイミングでプレイヤの戦績がランキングされる。戦績はレベルであってもよいし、敵の撃破数や被弾率、プレイ時間などさまざまなパラメータに基づいて任意に決定されればよい。

図５は、チームの連合移籍を説明するための模式図である。
チームは、リーダーの発議により、所属先の連合を変更（以下、「連合移籍」とよぶ）することもできる。連合移籍はシーズンの変わり目や、シーズン中の所定地点において実行可能である。図５においては、チーム（Ｘ１）が連合（Ｙ１）から連合（Ｙ２）に移籍する状況を示す。

チーム（Ｘ１）のリーダー（Ｐ１）は、連合（Ｙ２）への移籍をメンバーに提案する。このとき、チーム（Ｘ１）の他のメンバーは、リーダー（Ｐ１）に従ってもよいし、従わなくてもよい。チーム（Ｘ１）の設定情報１０８は、リーダー（Ｐ１）に付随する。すなわち、リーダー（Ｐ１）による移籍提案は、実質的には、移籍決定通知であり、少なくともリーダー（Ｐ１）を含むチーム（Ｘ１）は連合（Ｙ２）に移籍する。この連合移籍の決定に対して、チーム（Ｘ１）のメンバーが従うか否かは各自の判断となる。すべてのメンバーがリーダー（Ｐ１）とともに連合移籍するかもしれないし、一部のメンバーのみが連合移籍するかもしれないし、リーダー以外の全てのメンバーが残留を選択するかもしれない。リーダーが連合移籍を提案したとき、リーダーは設定情報１０８を持って移籍するため、リーダー（Ｐ１）にしたがって連合移籍したプレイヤは、それまでのチームの設定情報１０８（共有財産）による恩恵（ゲームの進行にともなう有利な効果）を引き続き享受できる。リーダー（Ｐ１）に従わなかったプレイヤは、チーム（Ｘ１）から離脱し、連合（Ｙ１）に残留する。リーダー（Ｐ１）が設定情報１０８をもっていってしまうので、残留者のチームは初期状態からの育成となる。離脱時の処理の詳細は後述する。

図６は、ゲームシステム１００の機能ブロック図である。
上述のように、ゲームシステム１００は、ゲームサーバ１０２およびゲーム端末１０４を含む。ゲーム端末１０４およびゲームサーバ１０２の各構成要素は、ＣＰＵ（Central Processing Unit）および各種コプロセッサなどの演算器、メモリやストレージといった記憶装置、それらを連結する有線または無線の通信線を含むハードウェアと、記憶装置に格納され、演算器に処理命令を供給するソフトウェアによって実現される。コンピュータプログラムは、デバイスドライバ、オペレーティングシステム、それらの上位層に位置する各種アプリケーションプログラム、また、これらのプログラムに共通機能を提供するライブラリによって構成されてもよい。以下に説明する各ブロックは、ハードウェア単位の構成ではなく、機能単位のブロックを示している。
ゲームサーバ１０２は、ウェブサーバを含む構成であってもよいし、ゲーム端末１０４は、携帯型の通信端末と、これにインストールされたウェブブラウザを含む構成であってもよい。

（ゲームサーバ１０２）
ゲームサーバ１０２は、通信部１１０、データ処理部１１２およびデータ格納部１１４を含む。
通信部１１０は、インターネット１０６を介してゲーム端末１０４との通信処理を担当する。データ格納部１１４は各種データを格納する。データ処理部１１２は、通信部１１０により取得されたデータおよびデータ格納部１１４に格納されているデータに基づいて各種処理を実行する。データ処理部１１２は、通信部１１０およびデータ格納部１１４のインタフェースとしても機能する。データ格納部１１４は、ゲームプログラムのほか、各プレイヤのプレイ状態を示す情報を格納する。

データ格納部１１４は、ゲームデータ格納部１１６、プレイヤデータ格納部１１８およびチームデータ格納部１２０を含む。
ゲームデータ格納部１１６は、ゲームプログラムを格納する。プレイヤデータ格納部１１８は、各プレイヤのレベル、装備、アイテム、リソースなど、プレイヤごとのゲームの進捗状況を示す情報を格納する。チームデータ格納部１２０は、チームおよび連合の編成を示すチーム情報やチームの設定情報１０８を格納する。チーム情報については図７に関連して後述する。

通信部１１０は、提案受信部１２２、提案通知部１２４および諾否受信部１２６を含む。
提案受信部１２２は、リーダーから連合移籍など、設定情報１０８の設定変更に関する提案（以下、「変更提案」とよぶ）を受信する。提案通知部１２４は、変更提案をチームのリーダー以外のメンバーに通知する。諾否受信部１２６は、変更提案に対する諾否（イエス／ノー）をメンバーのゲーム端末１０４から受信する。

データ処理部１１２は、プレイヤ登録部１２８、チーム設定部１３０およびゲーム制御部１３２を含む。
プレイヤ登録部１２８は、ゲーム端末１０４から通信部１１０を介してプレイヤ登録を受け付ける。プレイヤ登録部１２８は、プレイヤ登録がリクエストされると、プレイヤにプレイヤＩＤとチームＩＤを付与し、いずれかの連合ＩＤと対応づけて、プレイヤデータ格納部１１８とチームデータ格納部１２０に登録する。ゲームＧのゲームモジュールをゲーム端末１０４にインストールするときプレイヤ登録が自動的にリクエストされる。

チーム設定部１３０は、１人以上のプレイヤからなるチームを編成する。また、チーム設定部１３０は、チームと連合を対応づける。ゲーム制御部１３２は、ゲームごと、プレイヤごとにゲームの進捗状態を管理する。ゲームの進捗状態は、たとえば、各プレイヤのレベルや戦績、リソースなどである。

（ゲーム端末１０４）
ゲーム端末１０４は、ユーザインタフェース部１３４、通信部１３６、データ処理部１３８およびデータ格納部１４０を含む。
ユーザインタフェース部１３４は、タッチパネルを介してプレイヤからの操作を受け付けるほか、画像表示や音声出力など、ユーザインタフェースに関する処理を担当する。通信部１３６は、インターネット１０６を介してゲームサーバ１０２および他のゲーム端末１０４との通信処理を担当する。データ格納部１４０は各種データを格納する。データ処理部１３８は、ユーザインタフェース部１３４や通信部１３６により取得されたデータ、データ格納部１４０に格納されているデータに基づいて各種処理を実行する。データ処理部１３８は、ユーザインタフェース部１３４、通信部１３６およびデータ格納部１４０のインタフェースとしても機能する。

通信部１３６は、提案送信部１４２、提案受信部１４４および諾否送信部１４６を含む。
提案送信部１４２は、リーダーによる変更提案をゲームサーバ１０２に送信する。提案受信部１４４は、リーダーによる変更提案を提案通知部１２４から受信する。諾否送信部１４６は、変更提案に対するメンバーの諾否を送信する。

データ処理部１３８は、ゲーム実行部１４８を含む。
ゲーム実行部１４８は、ゲームサーバ１０２と連携してゲームの進行を制御する。ゲーム実行部１４８は、ゲームサーバ１０２からゲーム制御部１３２の機能の一部としてダウンロードされるソフトウェアモジュールとして形成されてもよい。
通信部１３６は、ゲームサーバ１０２から各種ゲーム情報を取得し、データ処理部１３８はユーザインタフェース部１３４にゲーム画面を表示させる。また、ユーザインタフェース部１３４はユーザによる各種入力を検出し、データ処理部１３８は入力情報をゲームサーバ１０２に通信部１３６を介して通知する。この入力情報に応じて、ゲームサーバ１０２のゲーム制御部１３２はゲーム端末１０４のゲーム実行部１４８と連携してゲームの進行を制御する。

ユーザインタフェース部１３４は、プレイヤからの入力を受け付ける入力部１５２と、プレイヤに対して画像や音声等の各種情報を出力する出力部１５４を含む。入力部１５２は、主として、画面に対するプレイヤのタッチ操作を入力として検出する。

図７は、チーム情報１５６のデータ構造図である。
チーム情報１５６は、チームデータ格納部１２０に格納される。チーム設定部１３０は、プレイヤ、チームおよび連合の対応関係をチーム情報１５６に記録する。図７の場合、プレイヤ（Ｐ１）は、チーム（Ｘ１）のリーダーであり、チーム（Ｘ１）は連合（Ｙ１）に所属している。ゲーム制御部１３２は、チーム（チームＩＤ）とチームの設定情報１０８を対応づけ、連合（連合ＩＤ）と連合の設定情報を対応づける。同様に、ゲーム制御部１３２は、プレイヤ（プレイヤＩＤ）とゲームの進捗状態（レベルや装備等）をプレイヤデータ格納部１１８において対応付ける。

図８は、諾否選択画面１５８の画面図である。
諾否選択画面１５８は、リーダー以外のメンバーのゲーム端末１０４に表示される。リーダーは、変更提案を提案送信部１４２によりゲームサーバ１０２に送信する。ゲームサーバ１０２の提案受信部１２２は変更提案を受信し、提案通知部１２４はリーダーと同じチームに所属する他のメンバーに変更提案を送信する。メンバーのゲーム端末１０４において、提案受信部１４４が変更提案を受信したとき、出力部１５４は諾否選択画面１５８を表示させる。メンバーは、諾否選択画面１５８において、リーダーの変更提案に対する承認（ＹＥＳ）または拒否（ＮＯ）をタッチ入力する。諾否送信部１４６は、プレイヤＩＤとともに諾否（ＹＥＳ／ＮＯ）（以下、「諾否情報」とよぶ）をゲームサーバ１０２に送信する。

図８においては、チーム（Ｘ１）（チーム名称「フォックス」）のリーダーが、連合（Ｙ１）（連合名称「パープル連合」）から連合（Ｙ２）（連合名称「ブルー連合」）への移籍を提案したときに、チーム（Ｘ１）に所属するメンバーの１０４に表示される。

図９は、連合移籍の処理過程を示すフローチャートである。
図９に示す処理は、ゲームサーバ１０２がリーダーから変更提案を受信したときに実行される。提案通知部１２４は、チーム情報１５６を参照し、リーダーと同一チームに所属する他のメンバーのゲーム端末１０４に変更提案を配信する（Ｓ１０）。諾否受信部１２６は、各ゲーム端末１０４からの諾否情報を受信し、これを集計する（Ｓ１２）。制限時間以内に諾否情報を送信しなかったメンバーについては、承諾したものと見なしてもよい。

拒否者、すなわち、諾否選択画面１５８において拒否を入力したメンバーがいるときには（Ｓ１４のＹ）、チーム設定部１３０は拒否者を含む新チームを編成する（Ｓ１６）。たとえば、プレイヤＰ３のみが拒否したときには、プレイヤＰ３のみをメンバーとする新チームが編成され、チーム設定部１３０は新チームにチームＩＤを付与する。複数のプレイヤ、たとえば、プレイヤＰ３とＰ４が拒否したときには、プレイヤＰ３、Ｐ４を含む新チームが編成され、同様にチームＩＤが付与される。

新チーム編成後、チーム設定部１３０は所定の選択条件（後述）にしたがって新チームのリーダーを選択する（Ｓ１８）。チーム設定部１３０は、１以上の承認者を含むチームを設定し、このチームの所属先の連合を変更する（Ｓ２０）。拒否がなければ（Ｓ１４のＮ）、処理はＳ２０にスキップされる。

図１０は、連合移籍にともなうチームの分裂を説明するための模式図である。
図１０では、チーム（Ｘ１）のリーダー（Ｐ１）が連合（Ｙ１）から連合（Ｙ２）への連合移籍を提案したとする。６人の残りメンバーのうち、プレイヤ（Ｐ２），プレイヤ（Ｐ３），プレイヤ（Ｐ５），プレイヤ（Ｐ６）は承認し、プレイヤ（Ｐ４），プレイヤ（Ｐ７）は拒否したとする。

チーム設定部１３０は、拒否したプレイヤ（Ｐ４），プレイヤ（Ｐ７）をメンバーとする新たなチームを編成し、チームＩＤ＝Ｘ１４を付与する。チーム情報１５６においてチーム（Ｘ１４）は連合（Ｙ１）に対応づけられる。また、チーム設定部１３０は、プレイヤ（Ｐ４），プレイヤ（Ｐ７）のいずれかを新チーム（Ｘ１４）のリーダーとして所定の選択条件にしたがって自動的に選ぶ。本実施形態における選択条件は下記の通りである。
（１）残留チーム（Ｘ１４）に旧チーム（Ｘ１）のサブ・リーダーが含まれているときには、サブ・リーダーがチーム（Ｘ１４）のリーダーとなる。
（２）旧チーム（Ｘ１）のサブ・リーダーが含まれていないときには、チーム（Ｘ１４）のメンバーのうちもっともレベルの高いメンバーが新リーダーとなる。
（３）もっとも高いレベルに二人以上のメンバーがいるときには、それらのメンバーからランダムに選択する。

チーム（Ｘ１４）のサブ・リーダーは、チーム（Ｘ１４）のリーダーに指名される。チーム設定部１３０は、リーダー以外のメンバーのうちもっともレベルの高いメンバーをサブ・リーダーとして選んでもよいし、ランダムに選択してもよい。

このようにチーム設定部１３０は、チーム（Ｘ１）からリーダーの変更提案を拒否したプレイヤを追放する。チーム（Ｘ１）の設定情報１０８も、拒否者の数に関わらず、リーダー（Ｐ１）とともに連合（Ｙ２）に移籍後のチーム（Ｘ１）の共有資産となる。

以上、実施形態に基づいてゲームシステム１００を説明した。
本実施形態によれば、リーダーはメンバーを引き連れてある連合から別の連合へとチームを移籍させることができる。リーダーがいったんチームを脱退して、移籍先の連合で再びチームを作り、旧メンバーを呼び寄せる方式も考えられるが、この場合、チームはいったん解体されてしまう。移籍後に旧メンバーが再集結するかわからないため、リーダーは連合移籍を決断しにくくなると考えられる。また、リーダーについていくプレイヤにとっても、リーダーの移籍後に、リーダーの新チームに改めて加入申請をするのは煩瑣である。

本実施形態においては、リーダーが連合移籍を提案したとき、メンバーは諾否選択画面１５８において承認または拒否を選択するだけで、リーダーと行動をともにするか、チームから離脱するかを実質的にはワンタッチで選択できる。リーダーの提案は決定事項であるが、その決定に従うか否かは各自の自由である。チームを離脱したときにも、拒否者だけで新たなチームが編成され、リーダーも自動的に選ばれるため、離脱にともなう手続負担が大きく軽減される。集団離脱しやすいため、リーダーのチーム運営に緊張感をもたせることができる。

リーダーは、チームの共有財産である設定情報１０８を持ち運ぶ権利を有する。ブランドやチーム規模（メンバー枠）などは、チームに対するメンバーの投資や献身によって育まれる。このため、メンバーはリーダーに従わない自由はあるものの、設定情報１０８を失う覚悟が必要である。設定情報１０８が充実したチーム、いわば、伝統・歴史のあるチームほど拒否者（離脱者）が出にくく、リーダーの権威が高まると考えられる。また、チームに長期にわたって献身してきた古参のプレイヤほど離散しにくくなると考えられる。プレイヤに提案拒否の自由を与えつつも、リーダーの権威を醸成しやすいシステムとなっている。

リーダーは、メンバーを強制的に連れて行くことはできないが、チーム運営を上手に行えば孤立もしにくい。本実施形態におけるゲームシステム１００によれば、チームとしての一体性とメンバーの自由度のバランスを両立させやすくなる。

なお、本発明は上記実施形態や変形例に限定されるものではなく、要旨を逸脱しない範囲で構成要素を変形して具体化することができる。上記実施形態や変形例に開示されている複数の構成要素を適宜組み合わせることにより種々の発明を形成してもよい。また、上記実施形態や変形例に示される全構成要素からいくつかの構成要素を削除してもよい。

複数のゲーム端末１０４と１つのゲームサーバ１０２によりゲームシステム１００が構成されるとして説明したが、ゲーム端末１０４の機能の一部はゲームサーバ１０２により実現されてもよいし、ゲームサーバ１０２の機能の一部がゲーム端末１０４に割り当てられてもよい。また、ゲームサーバ１０２やゲーム端末１０４以外の第３の装置が、機能の一部を担ってもよい。
図６において説明したゲーム端末１０４の各機能とゲームサーバ１０２の各機能の集合体は大局的には１つの「情報処理装置」として把握することも可能である。１つまたは複数のハードウェアに対して、本発明を実現するために必要な複数の機能をどのように配分するかは、各ハードウェアの処理能力やゲームシステム１００に求められる仕様等に鑑みて決定されればよい。

連合移籍に際し、拒否者のグループのリーダーは、所定期間におけるログイン回数、旧チームの施設建設・強化への貢献度（たとえば、累計出資額）、旧チームへの所属期間の長さ、戦闘参加率や敵機撃破数などの戦績などさまざまな選択条件に基づいて選ばれてもよい。拒否者のグループのリーダーは、離脱グループのメンバーの間での立候補、推薦、多数決により選んでもよいし、最初に提案拒否を表明したプレイヤを新チームのリーダーとしてもよい。

リーダーの交代を可能としてもよい。たとえば、シーズンごとにリーダーを輪番制で選んでもよい。メンバーがリーダー変更を提案し、これに過半数のメンバーが賛成したとき、リーダーを解任できるとしてもよい。チーム設定部１３０は、解任動議を受けると、メンバーの賛否を集計し、集計結果に基づいてチーム情報１５６を更新することによりリーダーを変更する。新リーダーは、上述の選択条件にしたがって選んでもよい。

チーム移籍以外にも、リーダーはさまざまな変更提案が可能である。たとえば、あるチームと別のチームを合併することでより強大なチームを形成することができる。チーム（Ｘ１）のリーダー（Ｐ１）とチーム（Ｘ２）のリーダー（Ｐ８）が合併に同意したとき、リーダー（Ｐ１），リーダー（Ｐ２）はそれぞれが率いるチームのメンバーに合併を提案する。合併を拒否したプレイヤはチームから追放され、新たなチームが編成される。そして、合併を承認したメンバーだけの新チーム（合併チーム）が編成される。チーム設定部１３０は、新チームにチームＩＤを付与することで、２つのチームを合併させる。合併されたチームのリーダーは、二人の旧リーダーの話し合いにより決めてもよいし、チーム設定部１３０が選択条件にしたがって選んでもよい。リーダーの合併提案は決定事項であるが、その決定に従うか否かも各自の自由である。

リーダーは、チーム内における施設の建設や強化も提案する。上述したように、施設を建設・強化することにより、プレイヤが操作するキャラクタが強化されることもあれば、キャラクタのダメージが回復することもある。施設の建設・強化はプレイヤに有利な効果をもたらす。施設建設・強化の承認者は、そのための出資を求められる。拒否者は出資を求められないが施設を利用することはできない。このように施設の建設・強化という変更提案を受け入れたメンバーのみ、その変更提案に基づいてゲームの進行状態が変化するとしてもよい。上記例の場合、出資を求められるという負担や施設の利用にともなう効果がゲームの進行状態に影響することになる。一方、拒否者には負担も恩恵もない。チーム設定部１３０は、施設の建設・強化の提案であっても、拒否者をチームから追放するとしてもよい。また、提案拒否にどのようなペナルティを与えるかはリーダーが設定してもよい。

リーダーは、他のチームとのチーム戦を提案してもよい。たとえば、チーム（Ｘ１）のリーダー（Ｐ１）が、敵連合（Ｙ２）に所属するチーム（Ｘ５）との対戦を提案したとする。このときは、承認者のみが出撃し、拒否者は防衛に専念するとしてもよい。

ゲーム制御部１３２は、リーダーの提案の拒否者に対してさまざまなペナルティを与えてもよい。たとえば、他のチームとの対戦提案を拒否したプレイヤに対して、一定期間の戦闘参加禁止（謹慎）を課してもよいし、プレイヤの保有するリソースの一部をチームのために強制的に拠出させてもよい。一方、リーダーの提案の承認者に対して、ゲーム制御部１３２はメリットを与えてもよい。たとえば、リーダーのリソースの一部を承認者に配分してもよい。このような方法によれば、アメとムチによる組織のコントロールが可能となる。

本実施形態においては、リーダーの提案は決定通知である。各メンバーは、この決定通知に従うか否かを選択できるものの、決定そのものを覆すことはできない。変形例として、リーダーの提案に対して拒否権を有するメンバーが含まれてもよい。たとえば、チームへの所属期間が所定時間以上のプレイヤや、戦績や出資額が一定条件をクリアしたプレイヤに対して、ゲーム制御部１３２は拒否権（発言権）を付与してもよい。拒否権を有するプレイヤが諾否選択画面１５８において拒否を選択すると、リーダーは提案を実行できなくなる。

リーダーの提案は、全員一致または過半数賛成でなければ実行されないとしてもよい。リーダーの権力に対してさまざまな制限を加えることにより、リーダーとメンバーのパワーバランスを調整してもよい。

施設を建設・強化すると、メンバーには装備強化などの恩恵が付与される。しかし、チームに加入して、恩恵だけを享受してそのあとに別のチームに簡単に移ってしまうという不誠実な行動も想定可能である。そこで、チームに加入してから所定の認定条件が満たされるまでは、施設などのチームの設定情報１０８にともなう恩恵を付与しないとしてもよい。たとえば、チームに加入してから所定時間が経過すること、チームのために所定数の敵機を撃破すること、リーダーから承認されること、３人以上のメンバーにより推薦されること、などの認定条件が考えられる。チーム設定部１３０は、チーム情報１５６においてプレイヤごとに所属チームの認定条件をクリアしているか否かを記録しておく。ゲーム制御部１３２は、設定情報１０８にともなう恩恵（たとえば、施設利用権や施設から定期的に提供されるリソースなど）を、認定条件をクリアしているプレイヤのみに提供する。

本実施形態においては、連合移籍に際し、設定情報１０８はリーダーに付随するものとして説明した。変形例として、設定情報１０８の一部が離脱したメンバーに付与されてもよい。たとえば、一部の施設や、装備、リソースなどが離脱メンバーの新チームの設定情報１０８として付与されてもよい。

リーダーは、提案を撤回できてもよい。リーダーは、提案をし、メンバーの賛成状況を確認の上、提案を実行するか否かを決めてもよい。このような制御方法によれば、リーダーはメンバーの意思を尊重しながらチーム運営をすることができる。リーダーに多くの権限を設定するチームと、メンバーの意思を尊重するチームが混在してもよい。不満分子を逐一追放する純化路線でチームを運営してもよいし、戦闘で力を発揮してくれさえすればある程度のわがままは許すというチーム運営も考えられる。

連合移籍に際しては、移籍したチームに新たなチームＩＤを付与してもよい。たとえば、図１０に示す場合において、チーム（Ｘ１）（連合（Ｙ１））のリーダー（Ｐ１）が、連合（Ｙ２）への移籍を提案するとき、移籍後のチームＩＤには（Ｘ１）とは異なる新たなチームＩＤ（たとえば、Ｘ１５）が付与されてもよい。この場合、チーム情報１５６においてはチーム（Ｘ１５）と承認者のプレイヤＩＤが対応づけられる。旧チームの設定情報１０８もチーム（Ｘ１５）に対応づけられる。一方、残留した拒否者は、新たなチームを編成するがこのチームには引き続きチームＩＤ＝Ｘ１が付与されてもよい。移籍したチーム（Ｘ１５）は、チームＩＤは変更となるが、チーム名称「フォックス」などの設定情報１０８は維持される。

本実施形態においては、ウォーシミュレーションとしてのゲームＧを対象として説明したが、シミュレーションゲームに限らず、スポーツゲームやロールプレイングゲーム、アクションゲームなど他のタイプのゲームにも同様に本発明を応用可能である。

１００ ゲームシステム、１０２ ゲームサーバ、１０４ ゲーム端末、１０６ インターネット、１０８ 設定情報、１１０ 通信部、１１２ データ処理部、１１４ データ格納部、１１６ ゲームデータ格納部、１１８ プレイヤデータ格納部、１２０ チームデータ格納部、１２２ 提案受信部、１２４ 提案通知部、１２６ 諾否受信部、１２８ プレイヤ登録部、１３０ チーム設定部、１３２ ゲーム制御部、１３４ ユーザインタフェース部、１３６ 通信部、１３８ データ処理部、１４０ データ格納部、１４２ 提案送信部、１４４ 提案受信部、１４６ 諾否送信部、１４８ ゲーム実行部、１５２ 入力部、１５４ 出力部、１５６ チーム情報、１５８ 諾否選択画面

Claims (7)

1. 複数のゲーム端末と通信ネットワークを介して接続され、
   １以上のプレイヤを含むチームを編成するチーム設定部と、
   リーダー・プレイヤのゲーム端末から、チームの設定情報の変更提案を受信する提案受信部と、
   前記リーダー・プレイヤと同一チームに所属するメンバー・プレイヤのゲーム端末に対して、前記変更提案を送信する提案通知部と、
   メンバー・プレイヤのゲーム端末から、前記変更提案に対する諾否を受信する諾否受信部と、
   変更後の設定情報に基づいて、前記変更提案を承諾したメンバー・プレイヤのゲームの進行状態を変化させるゲーム制御部と、を備え、
   前記チーム設定部は、前記変更提案を拒否したメンバー・プレイヤを前記チームから追放し、複数のメンバー・プレイヤを追放するときには、前記複数のメンバー・プレイヤを構成員とする新たなチームを編成し、かつ、前記新たなチームのリーダー・プレイヤを所定の選択条件に基づいて選ぶことを特徴とするゲームサーバ。
2. 複数のゲーム端末と通信ネットワークを介して接続され、
   １以上のプレイヤを含むチームを編成するチーム設定部と、
   リーダー・プレイヤのゲーム端末から、チームの設定情報の変更提案を受信する提案受信部と、
   前記リーダー・プレイヤと同一チームに所属するメンバー・プレイヤのゲーム端末に対して、前記変更提案を送信する提案通知部と、
   メンバー・プレイヤのゲーム端末から、前記変更提案に対する諾否を受信する諾否受信部と、
   変更後の設定情報に基づいて、前記変更提案を承諾したメンバー・プレイヤのゲームの進行状態を変化させるゲーム制御部と、を備え、
   前記チーム設定部は、複数のチームそれぞれを競合関係にある複数の連合のいずれかに対応づけ、チームの所属先となる連合の変更がリーダー・プレイヤから提案されたときには、リーダー・プレイヤおよび連合の変更を承諾したメンバー・プレイヤのみを含むチームを移籍先の連合に所属させることを特徴とするゲームサーバ。
3. 前記ゲーム制御部は、前記変更提案を承諾したメンバー・プレイヤに対して、変更後の設定情報に基づいてゲームの進行に有利な効果を発生させることを特徴とする請求項１または２に記載のゲームサーバ。
4. 前記ゲーム制御部は、チームへの加入後に所定の認定条件を充足させたメンバー・プレイヤに限り、前記有利な効果を発生させることを特徴とする請求項３に記載のゲームサーバ。
5. 前記ゲーム制御部は、前記変更提案を拒否したメンバー・プレイヤに対して、ペナルティを与えることを特徴とする請求項１から４のいずれかに記載のゲームサーバ。
6. １以上のプレイヤによりチームを編成する機能と、
   リーダー・プレイヤのゲーム端末から、チームの設定情報の変更提案を受信する機能と、
   前記リーダー・プレイヤと同一チームに所属するメンバー・プレイヤのゲーム端末に対して、前記変更提案を送信する機能と、
   メンバー・プレイヤのゲーム端末から、前記変更提案に対する諾否を受信する機能と、
   変更後の設定情報に基づいて、前記変更提案を承諾したメンバー・プレイヤのゲームの進行状態を変化させる機能と、
   前記変更提案を拒否したメンバー・プレイヤを前記チームから追放する機能と、
   複数のメンバー・プレイヤが追放されたときには、前記複数のメンバー・プレイヤを構成員とする新たなチームを編成する機能と、
   前記新たなチームのリーダー・プレイヤを所定の選択条件に基づいて選ぶ機能と、をコンピュータに発揮させることを特徴とするゲームプログラム。
7. １以上のプレイヤによりチームを編成する機能と、
   リーダー・プレイヤのゲーム端末から、チームの設定情報の変更提案を受信する機能と、
   前記リーダー・プレイヤと同一チームに所属するメンバー・プレイヤのゲーム端末に対して、前記変更提案を送信する機能と、
   メンバー・プレイヤのゲーム端末から、前記変更提案に対する諾否を受信する機能と、
   変更後の設定情報に基づいて、前記変更提案を承諾したメンバー・プレイヤのゲームの進行状態を変化させる機能と、
   複数のチームそれぞれを競合関係にある複数の連合のいずれかに対応づけ、チームの所属先となる連合の変更がリーダー・プレイヤから提案されたときには、リーダー・プレイヤおよび連合の変更を承諾したメンバー・プレイヤのみを含むチームを移籍先の連合に所属させる機能と、をコンピュータに発揮させることを特徴とするゲームプログラム。

Images