JP2011098013A - コンピュータプログラム、記録媒体、及びゲーム装置 - Google Patents

Abstract

【課題】 グループに所属するプレイヤ数や各グループから対戦に参加するプレイヤ数の偏りにかかわらず、適切なプレイヤ数から成るチーム同士の対戦を可能にし、参加プレイヤに多人数プレイの対戦ゲームの面白さを実感させることのできるゲームプログラムを提供する。
【解決手段】 本ゲームプログラム１０は、コンピュータをグループ登録手段、チーム編成手段、及びチーム対戦制御手段として機能させ、チーム編成手段は、各グループに登録されたプレイヤのうち対戦に参加するプレイヤについて、同一グループに登録された全てのプレイヤを互いに同一のチームに所属させると共に、そのチームに対し、登録されたグループが互いに異なるプレイヤを所属可能になっている。
【選択図】図１３

Description

本発明は、複数プレイヤ参加型のゲームにおいて、チーム対チームの対戦を行うにあたり、各プレイヤによるチームを編成するためのプログラム、該プログラムを記録した記録媒体、及びゲーム装置に関する。

近年、ネットワークを介することで、複数プレイヤの各キャラクタを同一の仮想ゲーム空間で同時に活動させることのできる、多人数参加型のオンラインゲームが提供されている。このようなゲームとしては、例えば、参加している複数のプレイヤが協力してゲームを進行させるタイプや、各プレイヤが操作するキャラクタ同士を対戦させるタイプ（オンラインバトル）などがある。更に、オンラインバトルには、各参加プレイヤ同士が互いに敵となって戦う個人戦のバトルモード（個人サバイバルモード）と、集まった複数の参加プレイヤをチームに分けて対戦するチーム戦のバトルモード（チームサバイバルモード）とがある。

このうちチームサバイバルモードでは、例えば最大１６人の参加プレイヤを２〜４チームに振り分けて、チーム対チームの対戦を行い、勝利したチームに所属していたプレイヤにポイントを付与するものがある。この場合、各プレイヤは、付与されるポイントを他のプレイヤよりも多く獲得し、獲得ポイントによって自身のランクを上げることを目標としてゲームをプレイする。

しかしながら、単に複数プレイヤをチーム分けし、そのチームの勝敗を各プレイヤのポイントやランクに反映させるだけでは、プレイヤを、チームサバイバルモードでのゲームに継続的に参加させるのに限界がある。即ち、既に多くのポイントを獲得し、高いランクを有するプレイヤにとっては、ポイントの獲得やランクを上げるといった目標が意味を失うため、チームサバイバルモードでプレイする意義がなくなってしまう。その結果、チームサバイバルモードのゲームに参加するプレイヤ数が減少し、チームを構成するプレイヤ数を十分に確保できなくなってしまう可能性がある。

これに対し、特許文献１には、各プレイヤが複数設けられたグループの何れかに登録され、一のグループに所属するプレイヤで構成するチームと、他の一のグループに所属するプレイヤで構成するチームとを対戦させる方法が開示されている。即ち、同一グループに所属するプレイヤが一のチームを構成し、異なるチーム同士によって、グループ対グループの対戦を行う。そして、一の対戦が終了した後も、各プレイヤは先に登録されたグループに所属し続けており、該グループの構成員として、次の対戦のためのチームに参加できる。また、同一グループに登録された他のプレイヤは、他のグループに登録されたプレイヤから成るチームと対戦できるようになっている。

このように、各プレイヤは、あるグループの構成員として対戦を行うことができ、また、同一グループに登録された他のプレイヤが、自身の参加していない対戦をプレイすることも可能であるため、各プレイヤに対して、その所属するグループの戦況を把握しようという意志を喚起させ、更には状況に応じて対戦に繰り返し参加させる意欲を持たせることができる。

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

しかしながら、上記特許文献１に開示された方法では、各チームを構成するプレイヤは、何れか一のグループに所属する者のみであるため、もともと各グループに所属するプレイヤ数に偏りがある場合や対戦への参加プレイヤ数が少ない場合には、大人数のチームと少人数のチームとの対戦が行われる可能性がある。この場合、大人数のチームが必然的に有利になるため、プレイヤの対戦への参加意欲が薄れ、対戦ゲーム本来の趣向性が薄れてしまう。

そこで本発明は、上述したような事情を鑑みて、グループに所属するプレイヤ数や各グループから対戦に参加するプレイヤ数の偏りにかかわらず、適切なプレイヤ数から成るチーム同士の対戦を可能にし、参加プレイヤに多人数プレイの対戦ゲームの面白さを実感させることのできるゲームプログラム、該ゲームプログラムを記録した記録媒体、及びゲーム装置を提供することを目的とする。

本発明に係るゲームプログラムは、コンピュータを、該コンピュータを操作するプレイヤを複数のグループのうち何れかに登録するグループ登録手段、該コンピュータを操作するプレイヤと、該コンピュータに通信ネットワークを介して接続された他のコンピュータを操作する他のプレイヤとを、複数のチームの何れかに所属させるチーム編成手段、及び前記チームに所属する各プレイヤの操作入力に応じて、仮想ゲーム空間にて各プレイヤに対応するキャラクタを行動させ、チーム対チームの対戦を行わせるチーム対戦制御手段として機能させ、前記チーム編成手段は、各グループに登録されたプレイヤのうち前記対戦に参加するプレイヤについて、同一グループに登録された全てのプレイヤを互いに同一のチームに所属させると共に、該チームに対し、登録されたグループが互いに異なるプレイヤを所属可能になっている。

また、前記チーム編成手段は、前記グループにより分類したときの前記対戦への参加プレイヤの構成に基づいて、各プレイヤを前記チームに振り分けて所属させるものであってもよい。

また、前記チーム編成手段は、複数の前記グループのうち前記対戦に参加するプレイヤ数が多いグループから順に、前記チームへプレイヤを振り分ける対象とし、振り分け対象のグループに登録されて前記対戦に参加する全てのプレイヤを、該グループのプレイヤを振り分ける時点で所属済みプレイヤ数の最も少ない同一のチームに所属させるものであってもよい。

また、前記チーム編成手段は、各グループに優先順位を設定しており、前記対戦に参加するプレイヤ数が同一のグループが複数存在する場合には、前記優先順位の高いグループから順に該グループに登録されたプレイヤをチームに所属させるものであってもよい。

また、前記チーム編成手段は、対戦する各チームに優先順位を設定しており、所属済みのプレイヤ数が同一のチームが複数存在する場合に、優先順位の高いチームから順にプレイヤを所属させるものであってもよい。

前記チーム編成手段は、チーム編成を終了した後、編成されたチームの構成内容に基づいて、編成結果の有効性を決定するものであってもよい。

また、前記チームの構成内容は各チームの所属プレイヤ数であり、前記チーム編成手段は、何れのチームの所属プレイヤ数も、他の何れのチームの所属プレイヤ数に対して所定の割合を下回ることがない場合に、該チーム編成を有効とするものであってもよい。

前記チームの構成内容は各チームに所属するプレイヤのプレイヤ情報であってもよい。

また、前記コンピュータを、前記対戦の結果を判定する対戦結果判定手段と、該対戦の結果に応じて、該対戦に参加したプレイヤが登録された前記グループに対しポイントを付与するポイント付与手段として機能させるものであってもよい。

また、前記対戦結果判定手段は、前記対戦の結果として各勢力の勝敗を判定し、前記ポイント付与手段は、勝利チームに所属していたプレイヤのグループに対してゼロより大きいポイントを付与し、敗北チームに所属していたプレイヤのグループに対してゼロ・ポイントを付与するものであってもよい。

また、前記ポイント付与手段は、前記ポイントに基づいて各勢力を順位付けするものであってもよい。

本発明に係る記録媒体は、上述した何れかのゲームプログラムを記録したコンピュータ読み取り可能な記録媒体であり、本発明に係るゲーム装置は、上述した何れかのゲームプログラムを読み込んで実行するゲーム装置である。

本発明によれば、グループに所属するプレイヤ数や各グループから対戦に参加するプレイヤ数の偏りにかかわらず、適切なプレイヤ数から成るチーム同士の対戦を可能にし、参加プレイヤに多人数プレイの対戦ゲームの面白さを実感させることのできるゲームプログラム、該ゲームプログラムを記録した記録媒体、及びゲーム装置を提供することができる。

本発明の実施の形態に係るゲーム装置を備えるゲームシステムの構成を示す回路図である。 （ａ）は、本発明の実施の形態に係るゲームプログラムの構成を示す模式図であり、（ｂ）は、図１に示すゲーム装置の機能的な構成を示すブロック図である。 本実施の形態に係るゲームの概要を説明するための模式図である。 本ゲームを実行するゲーム装置の動作を示すフローチャートである。 図４のフローチャートに続くゲーム装置の動作を示すフローチャートである。 図４のフローチャートに続くゲーム装置の動作を示すフローチャートである。 ゲーム装置の動作に伴ってモニタに表示されるトップメニュー画面を示す模式図である。 ゲーム装置の動作に伴ってモニタに表示されるモード選択画面を示す模式図である。 ゲーム装置の動作に伴ってモニタに表示される前回の結果画面を示す模式図である。 ゲーム装置の動作に伴ってモニタに表示されるエントリーメニュー画面を示す模式図である。 ゲーム装置の動作に伴ってモニタに表示される勢力マッチメニュー画面を示す模式図である。 ゲーム装置の動作に伴ってモニタに表示されるマッチングロビー画面を示す模式図である。 トレード方式によるチーム編成処理においてゲーム装置が実行する動作を示すフローチャートである。 本実施の形態に係るチーム編成処理を説明するための図面であり、各勢力からの参加プレイヤ数が異なる３つのケース１〜３を示している。 変形例に係るトレード方式によるチーム編成処理を説明するための図面であり、図１４のケース２と同じメンバー構成を有するケース４及びケース５とケース１と同じメンバー構成を有するケース６及びケース７とを示している。 １チームあたりの定員が設定されているという条件の下でトレード方式に従うゲーム装置の動作を示すフローチャートである。 マッチングロビーに入室している勢力毎のプレイヤ数の組み合わせと、この組み合わせから編成可能なチーム構成とを関連づけて記載したテーブルデータの模式図である。 ハイブリッド式によるチーム編成処理によって形成されるテーブルデータの模式図である。 ゲーム装置がバトルポイント付与処理を実行する場合の動作を説明するためのフローチャートである。

以下、本発明の実施の形態に係るコンピュータプログラム、記録媒体、及びゲーム装置について、図面を参照しつつ説明する。

［ゲームシステム］
図１は、本発明の実施の形態に係るゲーム装置を備えるゲームシステムの構成を示すブロック図である。図１に示すように、ゲーム装置１は、その動作を制御するＣＰＵ２を備え、このＣＰＵ２にはバス３を介してディスクドライブ４、メモリカードスロット５、ハードディスクドライブ（以下、ＨＤＤ）６、ＲＯＭ７、及びＲＡＭ８が接続されている。

ディスクドライブ４には、本発明の実施の形態に係るゲームプログラム１０が記録されたＤＶＤ、ＣＤ−ＲＯＭ、又はＢｌｕ−ｒａｙ Ｄｉｓｃ（登録商標）などのディスク型記録媒体４ａが装填されるようになっている。該ディスク型記録媒体４ａには、ゲームプログラム１０の他、キャラクタやゲームステージを形成するためのテクスチャなどのデータも記録されている。そして、ディスクドライブ４にディスク型記録媒体４ａが装填されると、ＣＰＵ２からの指示に従って、該ディスク型記録媒体４ａからゲームプログラム１０などを適宜読み出す。また、メモリカードスロット５は、ＣＰＵ２からの指示に従って、ゲームの途中経過を示すデータなどを、装填されたカード型記録媒体５ａ（例えば、フラッシュメモリ等）に不揮発的に記録する。

ＨＤＤ６はディスク型の大容量記録媒体であって、ゲームの途中経過を示すデータなどを記録する。ＲＯＭ７は、マスクＲＯＭ又はＰＲＯＭなどの半導体メモリであり、ゲーム装置１を起動する起動プログラムや、ディスク型記録媒体４ａが装填されたときの動作を制御するプログラムなどを記録している。ＲＡＭ８は、ＤＲＡＭ又はＳＲＡＭなどから成り、ＣＰＵ２が実行するべきゲームプログラム１０や、このゲームプログラム１０を実行する際に必要なキャラクタ及びゲームステージなどのデータを、ディスク型記録媒体４ａなどから読み込んで一時的に記録する。なお、プレイヤの操作によりディスク型記録媒体４ａ内の全データがＨＤＤ６に記録されている場合には、ＨＤＤ６に記録されているデータのうち、ＣＰＵ２が実行するべきゲームプログラム１０やこれを実行する際に必要なキャラクタ及びゲームステージなどのデータが、ＲＡＭ８に一時的に記録される。

また、ＣＰＵ２にはバス３を介して更にグラフィック処理部１１、オーディオ合成部１４、無線通信制御部１７、及びネットワークインタフェース１９が接続されている。

このうちグラフィック処理部１１は、ＣＰＵ２の指示に従って仮想ゲーム空間やキャラクタなどを含むゲーム画像を描画する。また、グラフィック処理部１１にはビデオ変換部１２を介して外部のモニタ１３が接続されており、グラフィック処理部１１にて描画されたゲーム画像は動画形式に変換され、更にモニタ１３にて表示される。

オーディオ合成部１４は、ＣＰＵ２の指示に従ってデジタルのゲーム音声を再生及び合成する。また、オーディオ合成部１４にはオーディオ変換部１５を介して外部のスピーカ１６に接続されており、オーディオ合成部１４にて再生及び合成されたゲーム音声は、オーディオ変換部１５にてアナログ形式にデコードされ、更にスピーカ１６にて出力される。

無線通信制御部１７は、２．４ＧＨｚ帯の無線通信モジュールを有し、ゲーム装置１に付属するコントローラ１８との間で無線により接続され、データの送受信が可能となっている。また、ネットワークインタフェース１９は、インターネットやＬＡＮなどの通信ネットワーク２０に対してゲーム装置１を接続する。そして、通信ネットワーク２０に接続された同様の構成を有する他のゲーム装置１との間で、サーバ装置２１を介さないピア・ツー・ピア方式での通信（以下、「Ｐ２Ｐ通信」）を可能とし、本発明に係るゲームシステム１００を構築する。

このゲームシステム１００では、複数のプレイヤが、同一のゲームプログラム１０を有する各ゲーム装置１を操作することにより、同期して同一の仮想ゲーム空間内でオンラインゲームを実行することができる。即ち、各ゲーム装置１は通信ネットワーク２０を介して互いにデータ通信を行うことができ、相互に送受信したデータや、ディスク型記録媒体４ａに記録されたゲームプログラム１０及びデータなどに基づき、各ゲーム装置１には同一の仮想ゲーム空間が生成される。各ゲーム装置１に接続されたモニタ１３には、各プレイヤが操作するキャラクタが中心に表示されるような視点で、この仮想ゲーム空間が表示される。例えば、プレイヤＡが操作するゲーム装置１に接続されたモニタ１３には、プレイヤＡが操作するキャラクタを中心とした仮想ゲーム空間の一部が表示され、プレイヤＢが操作するゲーム装置１に接続されたモニタ１３には、プレイヤＢが操作するキャラクタを中心とした仮想ゲーム空間の一部が表示される。

一方、各ゲーム装置１は、通信ネットワーク２０を介してサーバ装置２１との間でもデータ通信を行うことができる。このサーバ装置２１はいわゆるマッチングサーバであり、一般的なサーバ装置と同様に、ＣＰＵ、ＨＤＤ、ＲＯＭ、ＲＡＭ、及びネットワークインタフェースなどを備えている。サーバ装置２１は、ホストプレイヤ（後述）がゲームをする際に行うマッチングロビーの作成要求を、ホストプレイヤのゲーム装置１から通信ネットワーク２０を介して受け付けると、ＣＰＵがマッチングリストを作成してＨＤＤに記録する。一方、ゲストプレイヤ（後述）からの要求に応じて、マッチングリストをゲストプレイヤのゲーム装置１へ通信ネットワーク２０を介して送信する。そして、ゲストプレイヤによってマッチングリスト内の希望するロビーへの参加が要求されると、この参加要求がサーバ装置２１を介してホストプレイヤのゲーム装置１へ送信され、ホストプレイヤによりこの要求が受け付けられると、ゲストプレイヤは要求したロビーへの入室が許可される。また、サーバ装置１は、ゲストプレイヤのロビー入室許可を受けてマッチングリストの内容を更新する。これ以降、ホストプレイヤのゲーム装置１と入室が許可されたゲストプレイヤのゲーム装置１とは、サーバ装置２１を介さずＰ２Ｐ通信を行うことになる。

なお、本実施の形態ではゲストプレイヤがロビーへ入室した後、同一ロビーへの入室が許可された各プレイヤが操作するゲーム装置１間では、上記のようにＰ２Ｐ通信を行うこととしているが、サーバ装置を介してクライアント・サーバ方式によるデータ通信を行うように構成してもよい。

図２（ａ）は、上述したゲームプログラム１０の構成を示す模式図であり、図２（ｂ）は、図１に示すゲーム装置１の機能的な構成を示すブロック図である。図２（ａ）に示すように、ゲームプログラム１０は、ホスト用プログラム１０ａ及びゲスト用プログラム１０ｂを備えている。これらのプログラム１０ａ，１０ｂは、一連のプログラムとして作成されており、適宜設定されたフラグの状態に応じて、何れかのプログラム１０ａ，１０ｂが選択的に実行される。

また、図２（ｂ）に示すように機能的に見ると、ゲーム装置１は、チーム対戦制御部６２、グループ登録部６３、チーム編成部６４、及びポイント付与部６５を有する制御部６１を備えている。この制御部６１は、図１に示したＣＰＵ２、ＨＤＤ６、ＲＯＭ７、ＲＡＭ８、グラフィック処理部１１、ビデオ変換部１２、オーディオ合成部１４、及びオーディオ変換部１５などのハードウェアと、ＣＰＵ２により実行されるゲームプログラム１０とによって実現されている。更に、チーム対戦制御部６２は、ゲーム進行部６２ａ、ローディング部６２ｂ、仮想ゲーム空間生成部６２ｃ、及びキャラクタ生成部６２ｄを有している。

このうちゲーム進行部６２ａは、プレイヤによる操作入力に応じてキャラクタを仮想ゲーム空間にて行動させ、該キャラクタの行動に応じてゲームを進行させる。そして、通信ネットワーク２０を介して複数プレイヤが参加している場合には、該通信ネットワーク２０を介して受信した各プレイヤによる操作入力の情報に基づき、各キャラクタを仮想ゲーム空間にて行動させ、各キャラクタの行動に応じてゲームを進行させる。

ローディング部６２ｂは、ディスクドライブ４に装填されたディスク型記録媒体４ａから仮想ゲーム空間を構築するためのデータをＲＡＭ８へローディングする他、適宜カード型記録媒体５ａに記録されたデータもＲＡＭ８へローディングする。仮想ゲーム空間生成部６２ｃは、プレイヤが視認するモニタ１３に表示するための仮想ゲーム空間を生成する。キャラクタ生成部６２ｄは、仮想ゲーム空間に登場させるキャラクタ（参加している他のプレイヤの操作によるキャラクタを含む）を生成するものであり、プレイヤによって服装や装備を含む外観イメージがカスタマイズされている場合には、そのカスタマイズされた外観イメージをモニタ１３に表示させる。

ゲーム装置１を、このような各部６２ａ〜６２ｄとして機能させるプログラムは、ホストプログラム１０ａ及びゲストプログラム１０ｂの夫々に含まれている。従って、ディスクドライブ４にて読み込んだプログラム１０をＣＰＵ２が実行することにより、ゲーム装置１は上記各部６２ａ〜６２ｄとしての機能を発揮することができる。

なお、図２（ｂ）に示すように、制御部６１は、既に説明したディスクドライブ４、メモリカードスロット５、モニタ１３、スピーカ１６、無線通信制御部１７、及びネットワークインタフェース１９の動作も制御する。

［ゲームの概要］
図３は、本実施の形態に係るゲームの概要を説明するための模式図である。本ゲームでは、複数のプレイヤが、通信ネットワーク２０を介して接続された各自のゲーム装置１を操作することにより、各プレイヤが所属するチーム同士で戦うチーム対チームの対戦を同一の仮想ゲーム空間内で行う。

より詳しく説明すると、本ゲームでは複数の勢力（グループ）が設定されており、例えば、図３に示すように、勢力Ａ〜Ｅの５つの勢力が設定されている。そして、本ゲームにて対戦にエントリー（参加）しようとする各プレイヤは、これら５つの勢力のうち何れかの勢力に自身を登録する。また、本ゲームでは対戦場所として、夫々ルールの異なる複数のマップ（ステージ）が用意されており、勢力に登録済みのプレイヤは、例えば図３に示すように予め用意された３つのマップ１〜３のうちから、対戦に参加するたびに、その対戦場所として何れか１つのマップを選択できるようになっている。

なお、各マップ１〜３には対戦時間、勝敗の決定方法、及び装備できる武器の種類などのルールに関する情報が関連づけられており、プレイヤはこれらの情報に基づいてマップを選択する。そして、マップを選択することにより、このプレイヤは対戦への参加を要求した状態となり、他のプレイヤが同一マップでの対戦に参加要求してくるのを待機する。また、最初に参加を要求したプレイヤは該対戦においてはホストプレイヤとなり、その後に参加を要求したプレイヤはゲストプレイヤとなる（詳細は後述）。

次に、一定時間の経過や参加プレイヤ数が規定に達するなどの所定の条件が満たされて参加要求期間が締め切られると、同一マップでの対戦に参加要求した複数のプレイヤによってチーム編成処理が行われる。これにより、各プレイヤは、予め用意された複数のチーム（例えば、「赤チーム」及び「青チーム」）のうち何れかに所属することとなる。

例えば、図３に示すように、勢力Ａに登録された８人のプレイヤＡのうち対戦にエントリーする５人のプレイヤＡと、勢力Ｄに登録された６人のプレイヤＤのうち対戦にエントリーする３人のプレイヤＤとで、合計８人のプレイヤから成る「赤チーム」が編成される。また、勢力Ｂに登録された７人のプレイヤＢのうち４人と、勢力Ｃに登録された４人のプレイヤＣのうち３人と、勢力Ｅに登録された３人のプレイヤＥのうち１人とで、合計８人のプレイヤから成る「青チーム」が編成される。

ここで、図３に示す例のように、同一勢力（例えば、勢力Ａ）に登録されて対戦にエントリーする各プレイヤは、全て同一のチーム（ここでは、赤チーム）に所属される。従って、同一勢力に登録されたプレイヤ同士が、異なるチームに所属されて互いに対戦するようなことがないようになっている。一方、１つのチーム（例えば、赤チーム）に対して複数の勢力（勢力Ａ，Ｄ）のプレイヤが所属可能になっている。

このようにしてチーム編成が完了すると、編成されたチーム対チーム（「赤チーム」対「青チーム」）の対戦が行われる。例えば、敵チームのプレイヤを攻撃したり、対戦場所に設定された拠点（後述する「データポスト」）の争奪を行ったりする。そして、対戦が終了すると、勝利チームのプレイヤが登録されているグループに対してポイント（後述する「バトルポイント」）が付与される。また、プレイヤは、一旦ある勢力に登録されると、一定期間（例えば、月曜日から次の日曜日までの１週間）はこの勢力に登録された状態のままで対戦にエントリーすることができる。そして、この期間中に対戦にエントリーした回数に応じて、この期間を終えて次にゲームをプレイする際、褒賞（例えば、特別な武器や防具、装飾品、称号など）を受けることができるようになっている。また、この期間を終えて次の期間に入ると、プレイヤが選択できる各マップの内容が更新され、前期間とは異なるルールが設定されたマップで対戦できるようになっている。

なお、以下ではこのようなチーム対チームの対戦を適宜「勢力マッチ」と称する。

［ゲーム装置の動作］
プレイヤが上述したような勢力マッチをプレイする場合のゲーム装置１の動作について説明する。なお、以下では、各チームに分かれて対戦に参加するプレイヤの総数が１６人以下である場合について説明する。

図４は、本ゲームを実行するゲーム装置１の動作を示すフローチャートであり、図５及び図６は、図４のフローチャートに続くゲーム装置１の動作を示すフローチャートである。また、図７〜図１２は、ゲーム装置１の動作に伴ってモニタ１３に表示される各種の画面を示す模式図である。以下に示すゲーム装置１の動作は、ディスク型記録媒体４ａに記録されたゲームプログラム１０に従ってＣＰＵ２が各部の動作を制御することによって実現される。

図４に示すように、はじめにゲーム装置１はトップメニュー画面３１（図７参照）をモニタ１３に表示する（ステップＳ１）。図７に示すように、このトップメニュー画面３１の下部には本ゲームをプレイする際に選択するキャンペーン・アイコン３１ａを含む複数のアイコン３１ａ〜３１ｇが設けられて（表示されて）おり、プレイヤは目的に応じて何れかのアイコンをコントローラ１８の操作によって選択できる。また、トップメニュー３１の中央部分には、本ゲームでプレイすることのできる対戦場所を示すマップ３１ｈの全体イメージが概観的に表示されている。

次に、プレイヤがキャンペーン・アイコン３１ａを選択すべくコントローラ１８を操作し、ゲーム装置１がこの選択を受け付けると（ステップＳ２）、ゲーム装置１はモニタ１３にモード選択画面３２（図８参照）を表示させる（ステップＳ３）。図８に示すように、このモード選択画面３２には、本ゲームにおいてプレイ可能な複数のモードを文字列で示す表示が、さきほどのマップ３１ｈの上に重なるようにして配置（表示）される。例えば、「Influence Match」（勢力マッチ）と記載された表示３２ａは、本実施の形態において説明するチーム対チームでの対戦を行うゲーム・モードを示しており、「Co-op」と記載された表示３２ｂは、通信ネットワーク２０を介して他のプレイヤと協力してゲーム進行させるゲーム・モードを示しており、「Single」と記載された表示３２ｃは、プレイヤが１人でステージ（Co-opモードのステージと同一）のクリアを目指してゲームを進行させるゲーム・モードを示している。

このモード選択画面３２において、プレイヤがコントローラ１８を操作してInfluence Match（勢力マッチ）の表示３２ａを選択し、ゲーム装置１がこの選択を受け付けると（ステップＳ４）、ゲーム装置１とサーバ装置２１との間の通信接続処理が行われ（ステップＳ５）、更にゲーム装置１は、自身のＨＤＤ６に記録された情報に基づいて、プレイヤが既に勢力マッチへ今期（例えば、プレイしている日を含む、月曜日から次の日曜日までの１週間）エントリーをしているか否かを判断する（ステップＳ６）。そして、既にエントリーしていると判断した場合は（ステップＳ６：ＹＥＳ）、モニタ１３の表示を勢力マッチメニュー画面３５（後述の図１１参照）に切り換えて表示する（ステップＳ１２）。

一方、今期はまだエントリーしていないと判断した場合は（ステップＳ６：ＮＯ）、続いて、前期にプレイヤが勢力マッチへエントリーしているか否かを判断する（ステップＳ７）。そして、前期にプレイヤがエントリーしていた場合（ステップＳ７：ＹＥＳ）は、図９に示す前回の結果画面３３をモニタ１３に表示する（ステップＳ８）。図９に示すように、この前回の結果画面３３では、前期にプレイヤが登録した勢力を示す情報、及び対戦したマップに関する情報などを含む結果表示欄３３ａが中央に表示されている。そして、この前回の結果画面３３が表示されている状態で、プレイヤがコントローラ１８に設けられた所定のボタンを操作して表示の切り換えを指示すると、モニタ１３には、前回の結果画面３３に換わってエントリーメニュー画面３４（図１０参照）が表示される（ステップＳ９）。また、ステップＳ７にて前期においてもプレイヤが勢力マッチにエントリーしていないと判断した場合（ステップＳ７：ＮＯ）も、モード選択画面３２からエントリーメニュー画面３４へとモニタ１３の表示が切り換えられる。

図１０に示すエントリーメニュー画面３４においては、プレイヤは自身を登録する勢力を選択することができ、また、この勢力にて自身が操作するキャラクタを選択することができる。具体的には、エントリーメニュー画面３４には複数の勢力（ここでは５つ）の夫々を示すシンボルマーク３４ａ〜３４ｅが含まれている。そして、コントローラ１８が有する所定のボタン（例えば、十字キーの左右ボタン）を操作するたびに、何れか１つのシンボルマークに対応する勢力を順次指定することができ、指定した勢力の詳細情報がエントリーメニュー画面３４内に表示される。また、ある勢力を指定した状態でコントローラ１８が有する所定のボタン（例えば、十字キーの上下ボタン）を操作すると、該勢力において使用可能な複数のキャラクタの外観イメージ３４ｆを順次１つずつエントリーメニュー画面３４内に表示させることができる。

また、エントリーメニュー画面３４には、プレイヤの個人情報（プレイヤ情報）として、勢力マッチに参加することによって獲得したポイント数、このポイント数に応じて設定されるレベル値、及び次のレベルに到達するために必要なポイント数などの個人ポイント情報３４ｇが含まれている。更に、プレイヤが勢力を選択する際の指標の一つとして、各勢力を示すシンボルマーク３４ａ〜３４ｅには、キャリアレベルとここで称する数値３４ｈが添えて表示されている。このキャリアレベルとは、ある勢力に登録した場合の該勢力でのプレイヤのレベルを意味しており、プレイヤが同一勢力に登録した状態でプレイするほど、該勢力でのキャリアレベルは増加するようになっている。そして、キャリアレベルが高いほど、該勢力にて使用するキャラクタをカスタマイズできる要素が増えるようにしてもよい。

プレイヤは、このような情報に基づいて自身を登録する勢力と、該勢力において使用するキャラクタとを選択し、ゲーム装置１（特に、グループ登録部６３）はこの選択を受け付ける（ステップＳ１０）。そしてゲーム装置１は、勢力及びキャラクタが選択された後、コントローラ１８が有する所定のボタンがプレイヤによって操作されたか否かにより、プレイヤのエントリーが決定されたか否かを判断する（ステップＳ１１）。プレイヤの操作がない間はエントリーメニュー画面３４を表示し続け（ステップＳ１１：ＮＯ）、プレイヤの操作によってエントリーが決定されると（ステップＳ１１：ＹＥＳ）、エントリーメニュー画面３４に換えて勢力マッチメニュー画面３５（図１１参照）をモニタ１３に表示させる（ステップＳ１２）。

以上のように、勢力マッチメニュー画面３５をモニタ１３に表示する時点では、このゲーム装置１を操作するプレイヤは、登録する勢力と操作するキャラクタとが決定された状態となっている。次に、図１１に示すように、勢力マッチメニュー画面３５では、勢力マッチに参加する場合の対戦場所を、複数のマップから選択できるようになっている。具体的には、勢力マッチメニュー画面３５には、選択可能なマップを示す表示（「MAP1」、「MAP2」、「MAP3」など）３５ａが含まれており、各マップについての詳細情報（対戦ルール、対戦時間、勝敗決定方法、装備できる武具の種類など）も表示される。また、何れか１つのマップを示す表示３５ａを指定すると、そのマップでの最新の勢力情報３５ｂが表示される。この勢力情報３５ｂとしては、例えば、指定したマップで今期これまでに行われた対戦により各勢力が獲得したポイント（バトルポイント）に関する情報（勢力図）などがあり、図１１ではこれを円グラフで表示した例を示している。

なお、勢力マッチメニュー画面３５には、このような勢力図の他にも、登録した勢力を示す情報やその他の情報を含めてもよい。また、コントローラ１８が有する所定のボタンをプレイヤが操作することによって、勢力マッチメニュー画面３５に代えて、又は勢力マッチメニュー画面３５の上に重ねて、ショートカットメニュー画面（図示せず）が表示されるようにしてもよい。このショートカットメニュー画面では、例えばキャラクタをカスタマイズすることができるようにしてもよいし、前期にエントリーしていたゲーム装置１においては前期の結果を勢力図などで表示するようにしてもよい。

次に、プレイヤが勢力マッチメニュー画面３５にて何れか１つのマップを選択すると、この選択がゲーム装置１にて受け付けられる（ステップＳ１３）。そしてゲーム装置１は、通信ネットワーク２０を介してサーバ装置２１へマッチング検索を要求する（ステップＳ１４）。以後、ゲーム装置１は、マッチング検索要求の結果に応じて、ホスト及びゲストのうち何れかの立場となって動作する。

この点について補足しておくと、サーバ装置２１は、通信ネットワーク２０を介して接続されたゲーム装置１から所定のセッション情報（プレイヤ名、プレイヤＩＤ、ゲーム装置１のＩＰアドレス、選択したマップを示す情報など）を受信することにより、該セッション情報に基づいてこのゲーム装置１をホストとするマッチングロビーを作成する。一方、サーバ装置２１とのセッションが未確立のゲーム装置１は、ステップＳ１４に示すマッチング検索の要求に応じて、サーバ装置２１から（参加条件の合わないマッチングを含む）全てのマッチングロビーに関するリスト（マッチングリスト）を受信する。そして、このゲーム装置１は、受信したマッチングリストの中に、自身が参加することのできるマッチングロビー（参加条件が一致するマッチングロビー）が存在するか否かを判断する（ステップＳ１５）。

なお、ゲーム装置１からのステップＳ１４に示す要求に対し、サーバ装置２１は、ゲーム装置１がゲストとして入室することのできるマッチングロビーのみを含むマッチングリストを送信するようにしてもよい。具体的には、ゲーム装置１は、サーバ装置２１との間で通信接続処理（ステップＳ５）を行った後、サーバ装置２１に対してマッチング検索要求を行う（ステップＳ１４）。即ち、ゲーム装置１は、ステップＳ１０，Ｓ１３において行った選択条件をサーバ装置へ送信すると共に、検索要求（ステップＳ１４）をサーバ装置２１に対して行う。サーバ装置２１は、管理しているマッチングリストを前記選択条件に基づいてフィルタリングし、当該選択条件を満たすマッチングリストをゲーム装置１へ送信する。なお、最大定員に達しているマッチングロビーやゲーム装置１のプレイヤ情報（勢力による入室制限など）により入室できないマッチは、前記フィルタリングにより、送信されるマッチングリストには含まれない。このようにして、ゲーム装置１は、自身が入室可能なマッチングロビーのみを含むマッチングリストをサーバ装置２１から受信する。そして、このリスト情報を含む画面をモニタ１３に表示する。ゲーム装置１を操作するプレイヤは、モニタ１３に表示されたマッチングリストから、参加したいマッチングロビーを選択することにより、このマッチングロビーへ入室する。

上記ステップＳ１５の結果、マッチングリストを受信したゲーム装置１が、そのマッチングリスト中に自身の参加条件と一致するマッチングロビーが存在しないと判断した場合には（ステップＳ１５：ＮＯ）、該ゲーム装置１は以後ホストとなって動作し、図５に示す処理を実行する。一方、マッチングリスト中に自身の参加条件と一致するマッチングロビーが存在すると判断した場合には（ステップＳ１５：ＹＥＳ）、該ゲーム装置１は以後ゲストとなって動作し、図６に示す処理を実行する。なお、マッチングリスト中に、自身が参加可能な（参加条件が一致する）マッチングロビーが複数存在する場合には、参加可能な各マッチングロビーをモニタ１３に表示させ、プレイヤの操作によって何れか１つのマッチングロビーを選択できるようにしてもよい。以下では、はじめにホストとなったゲーム装置１（以下、適宜「ホストゲーム装置１」という）の動作について説明し、次に、ゲストとなったゲーム装置１（以下、適宜「ゲストゲーム装置１」という）の動作について説明する。

［ホストゲーム装置の動作］
上述したように、図４のステップＳ１５にて、サーバ装置２１から受信したマッチングリストに参加可能なマッチングロビーが存在しないと判断したゲーム装置１は、図５に示すように、ホストゲーム装置１という位置付けとなって、サーバ装置２１に対してセッションの作成を要求する（ステップＳ２０）。サーバ装置２１は、この要求に応じてホストゲーム装置１との間にセッションを確立し、該セッションが確立すると、ホストゲーム装置１はマッチングロビー画面３６を作成し、モニタ１３に該マッチングロビー画面３６（図１２参照）を表示する（ステップＳ２１）。

図１２に示すように、マッチングロビー画面３６には、該勢力マッチに参加を要求したプレイヤ（即ち、該マッチングロビーに入室したプレイヤ）のプレイヤ情報（プレイヤ名、キャラクタ情報、所属勢力情報、個人ポイント情報、キャリアレベルなど）が上から順に表示されるプレイヤ情報表示欄３６ａが設けられており、また、該勢力マッチの対戦ルール、オプション、対戦時間、装備できる武具などに関する情報を表示するマッチ内容表示欄３６ｂが設けられている。

ホストゲーム装置１は、マッチングロビーを作成して（ステップＳ２１）、マッチングロビー画面３６をモニタ１３に表示すると、所定の条件を満たして参加を締め切る（ステップＳ３０）までの間、他のプレイヤの参加を募集しつつ待機する。待機中に新たなプレイヤ（ゲストゲーム装置１）がマッチングロビーに入室し、セッションが確立すると（ステップＳ２２：ＹＥＳ）、ホストゲーム装置１は、この新たなゲストゲーム装置１に対して自身（ホストプレイヤ）に関するプレイヤ情報を送信する（ステップＳ２３）。

なお、ステップＳ３１にて参加を締め切る条件としては、本実施の形態においては、参加プレイヤ数が定員（例えば、１６人）に到達した時点で参加を締め切り、到達していない場合であってもマッチングロビー作成時点から所定時間（例えば、３分）が経過すれば参加を締め切るようにしている。但し、他の条件を採用してもよく、例えば時間制限をなくして、後述するフィルタリングによって参加プレイヤ数が定員に到達した時点で参加を締め切るようにしてもよいし、ホストプレイヤの操作などによって締め切るようにしてもよい。

ホストゲーム装置１は、セッションを確立したゲストゲーム装置１との間で、Ｐ２Ｐ通信によりデータの送受信を行う。そして、ホストゲーム装置１は、セッションが確立したこの新たなゲストゲーム装置１から、該ゲストプレイヤに関するプレイヤ情報をＰ２Ｐ通信により受信する（ステップＳ２４）。なお、ホストゲーム装置１とゲストゲーム装置１との間で送受信するプレイヤ情報としては、プレイヤ名及びキャラクタ情報などが含まれている。

更に、ホストゲーム装置１は、自身のマッチングロビーに既に入室（参加）している他のゲストゲーム装置１のセッション情報を、新たに入室（参加）するゲストゲーム装置１へ送信し（ステップＳ２５）、また、新たに入室するゲストゲーム装置１のセッション情報を、既に入室している他のゲストゲーム装置１へ送信する（ステップＳ２６）。これにより、既に入室しているゲストゲーム装置１と、新たに入室するゲストゲーム装置１とが、互いに受信した相手のセッション情報に基づいてセッションを確立し、以後は、Ｐ２Ｐ通信により互いにデータの送受信を行う。また、ホストゲーム装置１は、ステップＳ２４により受信した新たなゲストのプレイヤ情報に基づき、ステップＳ２１でモニタ１３に表示させたマッチングロビー画面３６の内容を更新表示させる（ステップＳ２７）。なお、マッチングロビー画面３６の更新表示（ステップＳ２７）は、新たなゲストからそのプレイヤ情報を受信した直後（ステップＳ２４とステップＳ２５との間のタイミング）に行ってもよい。

ホストゲーム装置１は、このようにしてゲストゲーム装置１から受信したプレイヤ情報に基づき、マッチングロビー画面３６のプレイヤ名表示欄３６ａに、このゲストプレイヤに関するプレイヤ情報を表示する。また、ホストゲーム装置１は、受信した新たなゲストプレイヤに関するプレイヤ情報をサーバ装置２１へ送信し、サーバ装置２１ではこのプレイヤ情報に基づいてマッチングリスト情報の内容を更新する。

なお、ここで説明する勢力マッチでは、上述したように参加可能な定員が、一例として１６人に設定されている。そして、同一勢力のプレイヤ同士が異なるチームに所属することがなく、且つチーム同士の人数的な均衡を確保するためには、一の勢力からの参加プレイヤ数を定員の半数（ここでは８人）以下に制限することが好ましい。このような観点から、本実施の形態では、マッチングロビーに入室することのできる同一勢力のプレイヤ数を、勢力マッチに参加できる定員（１６人）の半数以下（８人以下）としている。

そのために、ゲーム装置１は、サーバ装置２１から受信したマッチングリスト中に、自身の参加条件に一致するマッチングロビーが存在していた場合、更に、自身が登録された同一勢力からのそのマッチングロビーへの参加プレイヤ数が定員の半数（８人）に到達しているか否かを判断する。そして、定員の半数に到達していると判断した場合には、そのマッチングロビーには参加できないようにし、同一勢力から定員の半数を超えるプレイヤが同一のマッチングロビーに入室できないようにしている。

一方、ホストプレイヤは、マッチングロビー画面３６をモニタ１３に表示している間にコントローラ１８を所定操作することにより、マッチングロビーからの退室要求をホストゲーム装置１に入力することができる。ホストゲーム装置１は、この退室要求を受け付けると（ステップＳ２８：ＹＥＳ）、該マッチングロビーから退室して本ゲームを終了する（ステップＳ２９）。なお、他の参加プレイヤが既にいる場合には、残りの参加者のうち何れかのプレイヤがホストとなり、他の参加プレイヤが存在しない場合には、該マッチングロビーは閉鎖（削除）される。また、ホストゲーム装置１がプレイヤからの退室要求を受け付けていなければ（ステップＳ２８：ＮＯ）、上述した参加締切の条件が満たされたから否かを判断し（ステップＳ３０）、条件が満たされていなければ（ステップＳ３０：ＮＯ）、再びステップＳ２２からの処理を実行する。

このようにして、ホストゲーム装置１は、途中退室（ステップＳ２８）しなければ、参加締切の条件が満たされるまでの間、該勢力マッチへプレイヤが参加してくるのを待機する。待機中に他のプレイヤがマッチングロビーに入室（参加）し、このプレイヤとの間でＰ２Ｐ通信によりセッションを確立する（ステップＳ２２：ＹＥＳ）。そして、お互いのプレイヤ情報を送受信し合う（ステップＳ２３，Ｓ２４）。所定の時間が経過するか、又は参加プレイヤ数が所定数に達するなどして所定の条件が満たされると参加を締め切り（ステップＳ３０）、マッチングロビーに入室している参加プレイヤによるチーム編成処理（ステップＳ３１）を実行する。なお、このチーム編成処理については後に詳述する。

ステップＳ３１のチーム編成処理を終えると、このチーム編成の結果が有効か否かを、後述する所定の基準に基づいて判断し（ステップＳ３２）、無効と判断した場合（ステップＳ３２：ＮＯ）には、マッチングロビーに入室していた各ゲストゲーム装置１へ該チームを解散する旨の情報を送信（ステップＳ３３）して、再びステップＳ１４（図４参照）からの処理を実行する。一方、チーム編成の結果が有効であると判断した場合（ステップＳ３２：ＹＥＳ）には、チーム編成に関する情報及びゲームを開始する旨の情報を各ゲストゲーム装置１へ送信し（ステップＳ３４）、本ゲームを開始して勢力マッチをプレイすべくゲーム処理を実行する（ステップＳ３５）。

このゲーム処理では、各ゲーム装置１において同一の仮想ゲーム空間が形成され、その中に各プレイヤが操作するキャラクタが表示される。各プレイヤは自身のキャラクタを動作させ、敵チームのキャラクタを攻撃したり拠点（データポスト）を争奪するなど、チーム対抗戦の形式で勢力マッチを実行する。このようなゲーム装置１の動作は、制御部６１のチーム対戦制御部６２によって制御される。

なお、勢力マッチが終了すると、勝敗チームが決定され、勝利チームに属するプレイヤの勢力に対してポイント（バトルポイント）が付与される。ここで、勝敗の決定方法については、例えば、ＫＩＬＬ数、拠点奪取（データポスト起動）数、戦力ゲージなどを基準にして決定することができる。

具体的に説明すると、ＫＩＬＬ数（敵チームのキャラクタを倒した数）に基づいて勝敗を決定する場合では、敵チームのキャラクタを対戦終了時点までに全て倒すか、より多く倒したチームを勝利チームとする。なお、各キャラクタには体力値が設定されており、敵キャラクタからの攻撃を受けると、攻撃を受けたキャラクタの体力値は減少し、体力値がゼロになるとそのキャラクタは倒されたことになる。そして、敵キャラクタを倒したキャラクタが所属するチームには、ＫＩＬＬ数が「１」加算される。また、ホストゲーム装置１は、対戦終了の条件（例えば、ゲームスタートからの経過時間（１０分など）や、一方のチームのキャラクタの全滅、など）、両チームのＫＩＬＬ数、及び各キャラクタの生死情報などを記憶しており、更に、ゲームスタートからの経過時間をカウントして管理する。

また、対戦場所の各所にデータポストと称する拠点を設けておき、全てのデータポストを起動させる（拠点を奪取する）か、対戦終了時点でより多くのデータポストを起動させたチームを勝利チームとしてもよい。なお、ホストゲーム装置１は、起動されたデータポストの夫々に関連づけて、各データポストを起動したプレイヤに関する情報（所属チーム及び登録勢力に関する情報を含む情報）を記憶するようになっている。

また、各キャラクタに戦力ゲージを設定し、前述したように敵チームのキャラクタを倒したりデータポストを起動（拠点を奪取）するなどにより戦力ゲージを増加させ、逆に自チームのキャラクタが攻撃を受けたりデータポストを起動されるなどすると減少させるように設定する。そして、各キャラクタが獲得した戦力ゲージを加算するなどして各チームの戦力ゲージを算出し、対戦終了時点でその多い方のチームを勝利チームとすることができる。

［ゲストゲーム装置の動作］
一方、図４のステップＳ１５にて、サーバ装置２１から受信したマッチングリストに参加可能なマッチングロビーが存在すると判断した（ステップＳ１５：ＹＥＳ）ゲーム装置１は、図６に示すように、ゲストゲーム装置１という位置付けとなって、サーバ装置２１に対してセッションへの参加を要求し、マッチングロビーへ入室する（ステップＳ４０）。この要求に応じてサーバ装置２１からホストゲーム装置１のセッション情報を受信すると、ホストゲーム装置１との間でＰ２Ｐ通信によるセッションを確立する（ステップＳ４１）。続いて、ゲストゲーム装置１は、このＰ２Ｐ通信により、ホストゲーム装置１へ自身のプレイヤ情報（図５のステップＳ２４で受信される情報）を送信し（ステップＳ４２）、ホストゲーム装置１からは、ホストのプレイヤ情報を受信する（ステップＳ４３）。更に、ゲストゲーム装置１は、ホストゲーム装置１から、マッチングロビーに先に入室している他のゲストゲーム装置１のセッション情報を受信して、これら他のゲストゲーム装置１との間でＰ２Ｐ通信によるセッションを確立する（ステップＳ４４）。このＰ２Ｐ通信により、ゲストゲーム装置１は自身のプレイヤ情報を、先に入室している他のゲストゲーム装置１へ送信（ステップＳ４５）する一方、先に入室している他のゲストゲーム装置１から、これら他のゲストゲーム装置１のプレイヤ情報を受信する（ステップＳ４６）。そして、ゲストゲーム装置１は、図１２に示したのと同様のマッチングロビー画面３６をモニタ１３に表示させる（ステップＳ４７）。

このようにして、ホストゲーム装置１及び先に入室しているゲストゲーム装置１との間でセッションを確立してマッチングロビーに入室すると、ゲストゲーム装置１に接続されたモニタ１３のマッチングロビー画面３６には、ホストプレイヤと先に入室していたゲストプレイヤと自身とについて、プレイヤ情報がプレイヤ名表示欄３６ａに表示される。

この後、ゲストゲーム装置１は新たな他のプレイヤの参加を待機する状態となり、参加が締め切られる（ステップＳ５５）までの間、ホストゲーム装置１に関するステップＳ２２〜Ｓ３０の動作に対応するステップＳ４８〜Ｓ５５の動作を実行する。即ち、待機中に新たな他のプレイヤ（ゲストゲーム装置１）がマッチングロビーに入室すると（ステップＳ４８：ＹＥＳ）、ステップＳ４０〜Ｓ４７を経て待機状態となったゲストゲーム装置１は「既に入室しているゲストゲーム装置１」という位置付けになる。そして、この既に入室しているゲストゲーム装置１は、ホストゲーム装置１から、新たな他のゲストゲーム装置１のセッション情報を受信して、この新たな他のゲストゲーム装置１との間でＰ２Ｐ通信によるセッションを確立する（ステップＳ４９）。そして、このＰ２Ｐ通信により、既に入室しているゲストゲーム装置１は、この新たなゲストゲーム装置１に対して自身のプレイヤ情報を送信（ステップＳ５０）する一方、新たなゲストゲーム装置１から当該新たなゲストゲーム装置１のプレイヤ情報を受信する（ステップＳ５１）。そして、受信したプレイヤ情報に基づき、ステップＳ４７にて表示したマッチングロビー画面３６のプレイヤ名表示欄３６ａの内容を更新表示する（ステップＳ５２）。

一方、ゲストプレイヤも上述したホストプレイヤと同様に、マッチングロビー画面３６をモニタ１３に表示している間にコントローラ１８を所定操作することにより、マッチングロビーからの退室要求をゲストゲーム装置１に入力することができる。ゲストゲーム装置１は、この退室要求を受け付けると（ステップＳ５３：ＹＥＳ）、該マッチングロビーから退室して本ゲームを終了する（ステップＳ５４）。また、ゲストゲーム装置１がプレイヤからの退室要求を受け付けておらず（ステップＳ５３：ＮＯ）、参加が締め切られていなければ（ステップＳ５５：ＮＯ）、再びステップＳ４８からの処理を実行する。

次に、ホストゲーム装置１によって本マッチングロビーへの参加が締め切られると（ステップＳ５５：ＹＥＳ）、ホストゲーム装置１では、入室済みのプレイヤによってチーム編成処理が行われる（図５のステップＳ３１参照）。そしてゲストゲーム装置１は、編成したチームを解散する旨の情報（図５のステップＳ３３参照）、又はチーム編成及びゲーム開始に関する情報（図５のステップＳ３４参照）をホストゲーム装置１から受信する。ここで、ゲストゲーム装置１が、編成したチームを解散する旨の情報（図５のステップＳ３３参照）を受信した場合は、チーム編成が無効であるために解散され（ステップＳ５６：ＹＥＳ）、再びステップＳ１４（図４参照）からの処理が実行される。一方、ゲストゲーム装置１が、チーム編成及びゲーム開始に関する情報（図５のステップＳ３４参照）を受信した場合は（ステップＳ５６：ＮＯ、ステップＳ５７：ＹＥＳ）、本ゲームを開始して勢力マッチをプレイすべくゲーム処理を実行する（ステップＳ５８）。

［チーム編成処理：トレード方式］
次に、図５のステップＳ３１に示したチーム編成処理について、５つの勢力（勢力Ａ〜勢力Ｅ）に登録されたプレイヤによって２つのチーム（赤チーム及び青チーム）を編成する場合について説明する。このようなチーム編成処理は、ゲーム装置１のチーム編成部６４によって実行される。

はじめに、本実施の形態に係るチーム編成処理について概説する。本チーム編成では、勢力マッチに参加する全プレイヤをグループ毎に分類し、分類された参加プレイヤの構成（プレイヤ数のパターン）に基づいて、各プレイヤを各チームに振り分けるようにしている。より具体的には、各プレイヤが勢力毎に何れかのチームに振り分けられる（所属される）。従って、同一勢力のプレイヤ同士が異なるチームに振り分けられることがないようになっている。そして、基本ルールとして、参加プレイヤ数（同一マッチングロビーに入室しているプレイヤ数）が多い勢力のプレイヤから順番にチームに振り分けられる。また、振り分けの時点で所属プレイヤ数の最も少ないチームがそのプレイヤの振り分けの対象となる。

しかしながら、参加プレイヤ数が同一の勢力が複数存在する場合もあり得るため、勢力間には、チームへ振り分けられる順序に関する優先順位が設定されている。ここでは、特に言及する場合を除き、一例として勢力Ａが最も高い優先順位を有し、以下は勢力Ｂ、勢力Ｃ、勢力Ｄ、勢力Ｅの順に優先順位が低く設定されている。従って、参加プレイヤ数が最も多い勢力として勢力Ａ及び勢力Ｂが存在する場合には、優先順位の高い勢力Ａのプレイヤが先にチームへ振り分けられる。

また、所属プレイヤ数が同一のチーム（所属プレイヤ数が０人の場合を含む）が複数存在する場合もあり得るため、チーム間にもプレイヤが振り分けられる順序に関する優先順位が設定されている。ここでは、特に言及する場合を除き、一例として赤チームが青チームより高い優先順位に設定されている。従って、ある勢力のプレイヤが振り分けられる際、赤チーム及び青チームの夫々の所属プレイヤ数が同一である場合には、優先順位の高い赤チームに対して振り分けられることになる。

本実施の形態においては、このような編成方法に従って各勢力Ａ〜勢力Ｅのプレイヤを赤チーム又は青チームに振り分けてチーム編成を行うが、チーム編成の対象となるプレイヤには定員が設定されており、既に説明したようにここでは一例として１６人に設定されている。従って、最大１６人のプレイヤを、赤チーム又は青チームに振り分けるようにチーム編成を行う。なお、上述したチーム編成方式を、以下では「トレード方式」と称することとし、図１３〜図１６を参照しつつ更に具体的に説明する。

図１３は、トレード方式によるチーム編成処理においてゲーム装置１が実行する動作を示すフローチャートである。また、図１４は、本実施の形態に係るチーム編成処理を説明するための図面であり、各勢力からの参加プレイヤ数が異なる３つのケース１〜３を示している。以下では、はじめにトレード方式に従うゲーム装置１のチーム編成処理について図１３を参照して説明し、次に、図１４のケース１〜３に対して具体的に適用した場合について説明する。

図１３のフローチャートに示すように、ゲーム装置１は、まず勢力毎に参加プレイヤ数（マッチングロビーに入室しているプレイヤ数）を取得する（ステップＳ１０１）。次に、取得した情報に基づき、何れのチームにも所属していないプレイヤ数が最も多い勢力のうち、優先順位の最も高い勢力に登録された参加プレイヤ数をＸとする（ステップＳ１０２）。そして、優先順位の最も高いチームに対してこのＸを振り分ける（ステップＳ１０３）。

ステップＳ１０３の後、チームに所属していないプレイヤが残存しているか否かを判断し（ステップＳ１０４）、残存プレイヤがいない場合（ステップＳ１０４：ＮＯ）にはチーム編成を終了し（ステップＳ１０７）、該チーム編成の有効性を判断する処理を実行する（ステップＳ１０８）。なお、１回目のステップＳ１０４の処理にて残存プレイヤがいない（ステップＳ１０４：ＮＯ）と判断されるのは、マッチングロビーに入室しているプレイヤの勢力が１つだけの場合である。一方、ステップＳ１０４にて、残存プレイヤが存在する（ステップＳ１０４：ＹＥＳ）と判断した場合には、未所属のプレイヤ数が最も多い勢力のうち、優先順位が最も高い勢力に登録されたプレイヤ数をＸとする（ステップＳ１０５）。そして、所属プレイヤ数が最も少ないチームのうち、優先順位が最も高いチームにこのＸを振り分ける（ステップＳ１０６）。

その後、再びステップＳ１０４の処理を実行し、未所属プレイヤが残存している間（ステップＳ１０４：ＹＥＳ）は、ステップＳ１０４〜Ｓ１０６の処理を繰り返し実行する一方、残存していない場合（ステップＳ１０４：ＮＯ）には、チーム編成を終了し（ステップＳ１０７）、該チーム編成の有効性を判断する処理を実行する（ステップＳ１０８）。

ステップＳ１０８の有効性判断処理では、編成された各チームのうち、何れのチームの所属プレイヤ数も、他の何れのチームの所属プレイヤ数に対して、所定の割合を下回ることがない場合にのみ、該チーム編成を有効と判断する。逆に、何れかのチームの所属プレイヤ数が、他の何れかのチームの所属プレイヤ数に対して所定の割合を下回った場合には、該チーム編成を無効と判断する。ここで、所定の割合としては、例えば、最も多い所属プレイヤ数の半数と設定することができ、以下ではこの設定を採用した場合を前提として説明する。例えば、赤チームに８人が所属し、青チームに７人が所属することとなった場合には、このチーム編成を有効とする一方、赤チームに８人が所属し、青チームに３人が所属することとなった場合は、このチーム編成を無効とする。

（ケース１）
このようなトレード方式によるチーム編成方法を図１４のケース１に適用する場合について説明する。図１４に示すように、ケース１では、マッチングロビーに入室しているプレイヤとして、勢力Ａから５人、勢力Ｂから４人、勢力Ｃから３人、勢力Ｄから３人、勢力Ｅから１人の、合計１６人が存在している。

図１３に示すように、ゲーム装置１は、上述したような勢力毎の参加プレイヤ数を取得し（ステップＳ１０１）、何れのチームにも所属していないプレイヤ数が最も多い勢力に登録されたプレイヤ数として、勢力Ａの５人をＸとする（ステップＳ１０２）。ここで、未所属プレイヤが最も多い勢力は勢力Ａのみであるため、勢力間の優先順位に関係なく、勢力Ａの５人がＸとされる。次に、プレイヤが所属していないチームとして、この時点では赤チーム及び青チームの両チームが存在しているが、このうち優先順位の高い赤チームに対してＸが振り分けられる（ステップＳ１０３）。これにより、勢力Ａの５人のプレイヤは赤チームに所属される。

ステップＳ１０３に続いて、チームに未所属のプレイヤが存在するか否かを判断する（ステップＳ１０４）。ここでは勢力Ｂ〜Ｅの１１人のプレイヤが何れのチームにも所属せずに残存しているため（ステップＳ１０４：ＹＥＳ）、次の処理に移行し、勢力Ｂ〜Ｅのうち未所属プレイヤ数が最も多い勢力Ｂのプレイヤ数（４人）がＸとされる（ステップＳ１０５）。そして、この勢力Ｂの４人は、所属プレイヤが最も少ない青チームに振り分けられる（ステップＳ１０６）。これにより、勢力Ｂの４人のプレイヤは青チームに所属される。

この時点で、勢力Ｃ〜Ｅのプレイヤがまだ何れのチームにも所属していない状態で残存しているため（ステップＳ１０４：ＹＥＳ）、２回目のステップＳ１０５の処理が実行される。この２回目のステップＳ１０５では、未所属プレイヤが最も多い勢力として勢力Ｃ（３人）と勢力Ｄ（３人）とが存在しているが、両者のうち優先順位の高い勢力Ｃに登録されたプレイヤ数（３人）がＸとされる（ステップＳ１０５）。そして、この時点では赤チームに勢力Ａの５人が所属し、青チームに勢力Ｂの４人が所属しているので、チーム間の優先順位にかかわらず、所属プレイヤ数が最も少ないチームである青チームに勢力Ｃの３人が振り分けられる（ステップＳ１０６）。これにより、勢力Ｃの３人のプレイヤは青チームに所属される。

ステップＳ１０６の処理を終えると、チームに未所属のプレイヤとして勢力Ｄ及び勢力Ｅのプレイヤが残存している状態であるため（ステップＳ１０４：ＹＥＳ）、ステップＳ１０５以降の処理を更に繰り返し実行する。その結果、３回目のステップＳ１０５，Ｓ１０６の処理により、勢力Ｄの３人のプレイヤが赤チームに所属され、４回目のステップＳ１０５，Ｓ１０６の処理により、勢力Ｅの１人のプレイヤが青チームに所属される。このようにして、最終的に赤チームには、勢力Ａの５人及び勢力Ｄの３人の合計８人のプレイヤが所属し、青チームには、勢力Ｂの４人、勢力Ｃの３人、及び勢力Ｅの１人の合計８人のプレイヤが所属することとなる。

このようにして４回目のステップＳ１０６の処理を終えると、残存プレイヤが存在しない状態となるため（ステップＳ１０４：ＮＯ）、チーム編成処理を終了し（ステップＳ１０７）、チーム編成の有効性を判断する（ステップＳ１０８）。ケース１の場合、赤チームに８人のプレイヤが所属し、青チームに８人のプレイヤが所属する結果となっているため、何れのチームの所属プレイヤ数も、他のチームの所属プレイヤ数の半数を下回っていないため、このチーム編成は有効と判断される（図５のステップＳ３２：ＹＥＳ）。従って、この場合にホストゲーム装置１は、チーム編成及びゲーム開始に関する情報をゲストゲーム装置１へ送信し（図５のステップＳ３４）、ゲーム処理を開始する（図５のステップＳ３５）。ゲストゲーム装置１も、ホストゲーム装置１からの前記情報を受信し（図６のステップＳ５７：ＹＥＳ）、ゲーム処理を開始する（図６のステップＳ５８）。

（ケース２）
次に、トレード方式によるチーム編成方法を図１４のケース２に適用する場合について説明する。図１４に示すように、ケース２では、マッチングロビーに入室しているプレイヤとして、勢力Ａから６人、勢力Ｂから３人、勢力Ｃから３人、勢力Ｄから３人、勢力Ｅから１人の、合計１６人が存在している。

図１３に示すように、ゲーム装置１は、上述したような勢力毎の参加プレイヤ数を取得し（ステップＳ１０１）、何れのチームにも所属していないプレイヤ数が最も多い勢力に登録されたプレイヤ数として、勢力Ａの６人をＸとする（ステップＳ１０２）。ここで、未所属プレイヤが最も多い勢力は勢力Ａのみであるため、勢力間の優先順位に関係なく、勢力Ａの６人がＸとされる。次に、プレイヤが所属していないチームとして、この時点では赤チーム及び青チームの両チームが存在しているが、このうち優先順位の高い赤チームに対してＸが振り分けられる（ステップＳ１０３）。これにより、勢力Ａの６人のプレイヤは赤チームに所属される。

勢力Ａの６人を赤チームに振り分けた後（ステップＳ１０３）、まだ勢力Ｂ〜Ｅの１０人のプレイヤが何れのチームに所属せずに残存しているため（ステップＳ１０４：ＹＥＳ）、ステップＳ１０５の処理へ移行する。ここでは、チームに未所属のプレイヤ数が最も多い勢力として、何れも３人のプレイヤを有する勢力Ｂ〜Ｄが存在している。従って、このうち最も優先順位の高い勢力Ｂのプレイヤ数（３人）がＸとされる（ステップＳ１０５）。そして、続くステップＳ１０６の処理により、所属プレイヤが存在しない（最も少ない）青チームにこのＸが振り分けられる。これにより、勢力Ｂの３人のプレイヤは青チームに所属される。

この時点で、勢力Ｃ〜Ｅのプレイヤがまだ何れのチームにも所属していない状態で残存しているため（ステップＳ１０４：ＹＥＳ）、ステップＳ１０５以降の処理を更に繰り返し実行する。ここでは、チームに未所属のプレイヤが最も多い勢力として勢力Ｃ（３人）と勢力Ｄ（３人）とがあるため、このうち優先順位の高い勢力Ｃに登録されたプレイヤ数（３人）がＸとされる（ステップＳ１０５）。そして、この時点では赤チームに勢力Ａの６人が所属し、青チームに勢力Ｂの３人が所属しているので、チーム間の優先順位にかかわらず、所属プレイヤ数が最も少ないチームである青チームに、勢力Ｃの３人が振り分けられる（ステップＳ１０６）。これにより、勢力Ｃの３人のプレイヤは青チームに所属される。

２回目のステップＳ１０６の処理を終えると、チームに未所属のプレイヤとして勢力Ｄ及び勢力Ｅのプレイヤが残存している状態であるため（ステップＳ１０４：ＹＥＳ）、ステップＳ１０５からの処理を再び実行する。

この３回目のステップＳ１０５の処理では、未所属プレイヤが最も多い勢力である勢力Ｄのプレイヤ数（３人）がＸとされる。続いて、赤チームには勢力Ａの６人が所属し、青チームには勢力Ｂの３人及び勢力Ｃの３人の合計６人が所属し、何れのチームの所属人数も同一になっているため、優先順位の高い赤チームに対してこのＸが振り分けられる（ステップＳ１０６）。これにより、勢力Ｄの３人のプレイヤは赤チームに所属される。

更にステップＳ１０４を経て４回目のステップＳ１０５では、残りの勢力Ｅの１人がＸとされ、この時点で所属プレイヤ数が最も少ない青チームに対してこのＸが振り分けられる（ステップＳ１０６）。このようにして、最終的に赤チームには勢力Ａの６人及び勢力Ｄの３人の合計９人のプレイヤが所属され、青チームには、勢力Ｂの３人、勢力Ｃの３人、及び勢力Ｅの１人の合計７人のプレイヤが所属されることとなる。

このようにして４回目のステップＳ１０６の処理を終えると残存プレイヤが存在しない状態となるため（ステップＳ１０４：ＮＯ）、チーム編成処理を終了し（ステップＳ１０７）、チーム編成の有効性を判断する（ステップＳ１０８）。ケース２の場合、赤チームに９人のプレイヤが所属し、青チームに７人のプレイヤが所属しており、両チームのプレイヤ数は同一ではないが、何れのチームの所属プレイヤ数も、他のチームの所属プレイヤ数の半数を下回っていないため、このチーム編成は有効と判断される（図５のステップＳ３２：ＹＥＳ）。従って、この場合もホストゲーム装置１は、チーム編成及びゲーム開始に関する情報をゲストゲーム装置１へ送信し（ステップＳ３４）、ゲーム処理を開始する（ステップＳ３５）。ゲストゲーム装置１も、ホストゲーム装置１からの前記情報を受信し（図６のステップＳ５７：ＹＥＳ）、ゲーム処理を開始する（図６のステップＳ５８）。

（ケース３）
次に、トレード方式によるチーム編成方法を図１４のケース３に適用する場合について説明する。図１４に示すように、ケース３では、マッチングロビーに入室しているプレイヤとして、勢力Ａから８人、勢力Ｂから１人、勢力Ｃから１人、勢力Ｄから１人、勢力Ｅから０人の、合計１１人が存在している。このようにケース３では参加プレイヤ数が定員の１６人に達していないが、このような場合であっても、図５のステップＳ３０について説明したように、所定の時間が経過するなどによって参加が締め切られ（ステップＳ３０：ＹＥＳ）、チーム編成処理（ステップＳ３１）が実行される。

図１３に示すように、ゲーム装置１は、上述したような勢力毎の参加プレイヤ数を取得し（ステップＳ１０１）、何れのチームにも所属していないプレイヤ数が最も多い勢力に登録されたプレイヤ数として、勢力Ａの８人をＸとする（ステップＳ１０２）。そして、赤チーム及び青チームのうち、優先順位の高い赤チームにこのＸを振り分ける（ステップＳ１０３）。これにより、勢力Ａの８人のプレイヤは赤チームに所属される。

勢力Ａの８人を赤チームに振り分けた後（ステップＳ１０３）、まだ勢力Ｂ〜Ｄの３人のプレイヤが残存しているため（ステップＳ１０４：ＹＥＳ）、ステップＳ１０５の処理へ移行する。ここでは、チームに未所属のプレイヤ数が最も多い勢力として、何れも１人のプレイヤを有する勢力Ｂ〜Ｄが存在している。従って、このうち最も優先順位の高い勢力Ｂのプレイヤ数（１人）がＸとされる（ステップＳ１０５）。そして、続くステップＳ１０６の処理により、所属プレイヤが存在しない（最も少ない）青チームにこのＸが振り分けられる。これにより、勢力Ｂの１人のプレイヤは青チームに所属される。

次に、勢力Ｃ及び勢力Ｄのプレイヤがまだ何れのチームにも所属していない状態で残存しているため（ステップＳ１０４：ＹＥＳ）、２回目のステップＳ１０６の処理を実行する。ここでは、チームに未所属のプレイヤが最も多い勢力として勢力Ｃ（１人）と勢力Ｄ（１人）とがあるため、このうち優先順位の高い勢力Ｃに登録されたプレイヤ数（１人）がＸとされる（ステップＳ１０５）。そして、この時点では赤チームに勢力Ａの８人が所属し、青チームに勢力Ｂの１人が所属しているので、所属プレイヤ数が最も少ないチームである青チームに、チーム間の優先順位にかかわらず、勢力Ｃの１人が振り分けられる（ステップＳ１０６）。これにより、勢力Ｃの１人のプレイヤは青チームに所属される。

更に、チームに未所属のプレイヤとして勢力Ｄのプレイヤが残存している状態であるため（ステップＳ１０４：ＹＥＳ）、３回目のステップＳ１０５以降の処理を実行する。その結果、勢力Ｄの１人のプレイヤが青チームに所属される。このようにして、最終的に赤チームには勢力Ａの８人のプレイヤが所属され、青チームには、勢力Ｂの１人、勢力Ｃの１人、及び勢力Ｄの１人の合計３人のプレイヤが所属されることとなる。

このようにして３回目のステップＳ１０６の処理を終えると残存プレイヤが存在しない状態となるため（ステップＳ１０４：ＮＯ）、チーム編成処理を終了し（ステップＳ１０７）、チーム編成の有効性を判断する（ステップＳ１０８）。ケース３の場合、赤チームに８人のプレイヤが所属し、青チームに３人のプレイヤが所属しており、青チームの所属プレイヤ数（３人）が、赤チームの所属プレイヤ数（８人）の半数を下回っている。従って、このようなチーム編成は無効と判断される（図５のステップＳ３２：ＮＯ）。そのため、ホストゲーム装置１は、編成したチームを解散する旨の情報をゲストゲーム装置１へ送信し（図５のステップＳ３３）、ステップＳ１４（図４参照）からの処理を再び実行する。ゲストゲーム装置１も、ホストゲーム装置１から前記情報を受信して解散と判断すると（図６のステップＳ５６：ＹＥＳ）、ステップＳ１４からの処理を再び実行する。

以上に説明したように、トレード方式に従ってチーム編成を実行することにより、ケース１，２の場合のように各勢力から勢力マッチに参加するプレイヤ数に偏りがある場合であっても、同一勢力のプレイヤが異なるチームに所属することがないようにして、チーム同士のプレイヤ数の均衡を図ったチーム編成を行うことができる。一方、ケース３のように、編成したチーム間のプレイヤ数に大きな偏りがある場合には、このようなチーム編成を無効化できるため、プレイヤ数に大きな偏りがあるチーム同士が対戦してしまうことがない。

（トレード方式の変形例１）
ところで、上述したトレード方式の説明では、勢力Ａが最も高い優先順位を有し、以下は勢力Ｂ、勢力Ｃ、勢力Ｄ、勢力Ｅの順に優先準備を低く設定し、且つ、赤チームを青チームより高い優先順位に設定しているが、他の設定内容にしてもよい。例えば、勢力間の優先順位についていえば、ホストプレイヤが属する勢力の優先順位を最も高くし、ゲストプレイヤについては参加時期（マッチングロビーへの入室タイミング）が早いものの勢力ほど優先順位が高くなるようにしてもよい。その他にも、プレイヤ数の少ない勢力から順にチームに振り分けるようにしてもよいし、３チームに対してプレイヤを振り分けるようにしてもよい。

図１５は、変形例に係るトレード方式によるチーム編成処理を説明するための図面であり、４つのケース（ケース４〜７）について示している。このうちケース４及びケース５では、既に説明したトレード方式との比較のため、図１４のケース２と同じメンバー構成としている。そして、ケース４では、チーム間の優先順位はケース２と同じく赤チームの方が青チームより高いが、勢力間の優先順位を、ホストプレイヤが属する勢力Ａが最も高く、以下は参加順である勢力Ｃ、勢力Ｄ、勢力Ｂ、勢力Ｅの順に低くなるように設定した場合について示している。また、ケース５では、１チームの定員に上限値を設けた場合を示しており、これについては別の変形例として後述する（「トレード方式の変形例２」を参照）。

更に、ケース６及びケース７では、図１４のケース１と同じメンバー構成としている。そして、ケース６では、登録プレイヤ数の少ない勢力のプレイヤから順にチームに振り分けられるように設定した場合について示している。また、ケース７では、３つのチームに対してプレイヤを振り分ける場合について示している。これら、ケース６及びケース７についても、別の変形例として後述する（「トレード方式の変形例３」及び「トレード方式の変形例４」を参照）。

図１５のケース４について、図１３に示したフローチャートに従ってチーム編成を行う場合について説明する。ケース４では、既に説明したケース２と同様に、勢力Ａから６人、勢力Ｂから３人、勢力Ｃから３人、勢力Ｄから３人、勢力Ｅから１人の、合計１６人が存在している。図１３に示すように、ゲーム装置１は、上述したような勢力毎の参加プレイヤ数を取得し（ステップＳ１０１）、何れのチームにも所属していないプレイヤ数が最も多い勢力に登録されたプレイヤ数として、勢力Ａの６人をＸとする（ステップＳ１０２）。そして、プレイヤが所属していない赤チーム及び青チームのうち、優先順位の高い赤チームにこのＸを振り分ける（ステップＳ１０３）。これにより、勢力Ａの６人のプレイヤは赤チームに所属される。

次に、残存するプレイヤが存在するか否かを判断する（ステップＳ１０４）。ここでは勢力Ｂ〜Ｅのプレイヤが残存しているため（ステップＳ１０４：ＹＥＳ）、続いてステップＳ１０５の処理に移行する。ここでは、未所属のプレイヤ数が最も多い勢力として勢力Ｂ（３人）、勢力Ｃ（３人）、及び勢力Ｄ（３人）が残っているが、このうち優先順位が最も高い勢力Ｃのプレイヤ数（３人）がＸとされる。そして、続くステップＳ１０６の処理によってこのＸが青チームに振り分けられる。これにより、勢力Ｃの３人のプレイヤは青チームに所属される。

次に、勢力Ｂ、勢力Ｄ、及び勢力Ｅのプレイヤがまだチームに所属していない状態で残存しているため（ステップＳ１０４：ＹＥＳ）、２回目のステップＳ１０５の処理が実行される。このステップＳ１０５では、チームに未所属のプレイヤが最も多い勢力として勢力Ｂ（３人）と勢力Ｄ（３人）とが存在し、このうち優先順位の高い勢力Ｄのプレイヤ数（３人）がＸとされる。また、この時点では赤チームに勢力Ａの６人が所属し、勢力Ｃの３人が所属する青チームの方が所属プレイヤ数は少ないため、ステップＳ１０６にて青チームに対してＸが振り分けられる。これにより、勢力Ｄの３人のプレイヤは青チームに所属される。

この時点で、チームに未所属のプレイヤとして勢力Ｂ及び勢力Ｅのプレイヤが残存している状態であるため（ステップＳ１０４：ＹＥＳ）、ステップＳ１０５からの処理を再び実行する。

３回目のステップＳ１０５の処理では、勢力Ｂ及び勢力Ｅのうち、プレイヤ数の多い勢力Ｂの３人がＸとされる。続いてステップＳ１０６の処理が行われるが、この時点で赤チームには勢力Ａの６人が所属し、青チームには勢力Ｃの３人及び勢力Ｄの３人の合計６人が所属しており、両チームの所属プレイヤ数は同じになっている。従って、所属プレイヤ数の最も少ないチームとしては、赤チーム及び青チームは同レベルであるが、このうち優先順位の高い赤チームに対し、Ｘが振り分けられる（ステップＳ１０６）。その結果、勢力Ｂの３人は赤チームに所属することになる。

更に、残りの勢力Ｅを対象として４回目のステップＳ１０５，Ｓ１０６の処理が行われ、勢力Ｅの１人は青チームに所属される。このようにして、最終的に赤チームには、勢力Ａの６人及び勢力Ｂの３人の合計９人のプレイヤが所属し、青チームには、勢力Ｃの３人、勢力Ｄの３人、及び勢力Ｅの１人の合計７人のプレイヤが所属することとなる。

こうして４回目のステップＳ１０６の処理を終えると残存プレイヤが存在しない状態となるため（ステップＳ１０４：ＮＯ）、チーム編成処理を終了し（ステップＳ１０７）、チーム編成の有効性を判断する（ステップＳ１０８）。ケース４の場合、赤チームに９人のプレイヤが所属し、青チームに７人のプレイヤが所属する結果となっているため、何れのチームの所属プレイヤ数も、他のチームの所属プレイヤ数の半数を下回っていないため、このチーム編成は有効と判断される（図５のステップＳ３２：ＹＥＳ）。

このように、各勢力からの参加人数が同じであるケース２の場合と比較すると分かるように、優先順位を異なる態様に設定することによって、その他の条件が同一であっても異なるチーム編成を実現することができる。また、上述したようにホストプレイヤが属する勢力の優先順位を最も高くし、ゲストプレイヤについては参加が早いものの勢力ほど優先順位が高くなるようにすると、マッチングロビーを作成するたびに優先順位が異なることになるため、多様なチーム編成を実現することができる。

（トレード方式の変形例２）
上述した説明では、チーム編成に加われるプレイヤ数にのみ１６人という定員が設定され、１チームの定員は設定されていなかったが、１チームの定員も設定するようにしてもよい。図１５のケース５は、このように１チームの定員を、チーム編成に加われるプレイヤの定員（１６人）の半数である８人に設定した場合について示している。また、図１６は、１チームあたり定員が設定されているという条件の下でトレード方式に従うゲーム装置１の動作を示すフローチャートである。

図１６に示すように、この変形例２に係るトレード方式では、勢力毎の参加プレイヤ数を取得し（ステップＳ１１１）、何れのチームにも所属していないプレイヤ数が最も多い勢力に登録されたプレイヤ数として、勢力Ａの６人をＸとする（ステップＳ１１２）。次に、プレイヤが所属していないチームとして、この時点では赤チーム及び青チームの両チームが存在しているが、このうち優先順位の高い赤チームに対してＸが振り分けられる（ステップＳ１１３）。これにより、勢力Ａの６人のプレイヤは赤チームに所属される。この時点で、勢力Ｂ〜Ｅの１０人のプレイヤが何れのチームに所属せずに残存しており（ステップＳ１１４：ＹＥＳ）、プレイヤ未所属のチームとして青チームが存在するため（ステップＳ１１５：ＹＥＳ）、ステップＳ１１２からの処理を再び実行する。

この２回目のステップＳ１１２，Ｓ１１３の処理により、勢力Ｂのプレイヤ３人が青チームに所属することになる。そして、この時点で、勢力Ｃ〜Ｅのプレイヤは何れのチームにも所属していない状態であり（ステップＳ１１４：ＹＥＳ）、且つ、プレイヤ未所属のチームは存在しなくなっている（ステップＳ１１５：ＮＯ）。従って、次のステップＳ１１６へ移行し、未所属プレイヤが最も多く、且つ優先順位の高い勢力に登録されたプレイヤとして、勢力Ｃのプレイヤ数（３人）がＸとされる（ステップＳ１１６）。

次に、全てのチームのうち、最も所属プレイヤ数が少なく優先順位の高いチームの空き数をＹとする（ステップＳ１１７）。この空き数とは、１チームの定員（８人）から既に所属しているプレイヤ数を差し引いた値である。そしてケース５では、この時点で赤チームに勢力Ａの６人が所属し、青チームに勢力Ｂの３人が所属しているので、所属プレイヤ数が最も少ないチームである青チームの空き数（８−３＝５人）がＹとされる（ステップＳ１１７）。そして、勢力Ｃのプレイヤ数Ｘ（３人）と青チームの空き数Ｙ（５人）との大小関係を比較し（ステップＳ１１８）、空き数Ｙ（５人）がプレイヤ数Ｘ（３人）以上であるため（ステップＳ１１８：ＹＥＳ）、この空き数Ｙの青チームに対してＸを振り分ける（ステップＳ１１９）。これにより、勢力Ｃの３人のプレイヤは青チームに所属される。

ステップＳ１１９を終えると、全てのプレイヤに対して検証が終了したか否かを判断する（ステップＳ１２０）。ここでは勢力Ｄ及び勢力Ｅのプレイヤについての検証が済んでいないため（ステップＳ１２０：ＮＯ）、ステップＳ１１６からの処理を再び実行する。

２回目のステップＳ１１６の処理では、検証済みの勢力を除外した勢力Ｄ及び勢力Ｅを対象とし、未所属プレイヤが最も多い勢力Ｄのプレイヤ数（３人）がＸとされる。続くステップＳ１１７の処理に際し、この時点で赤チームには勢力Ａの６人が所属し、青チームには勢力Ｂの３人及び勢力Ｃの３人の合計６人が所属しており、両チームとも同条件になっている。従って、優先順位の高い赤チームの空き数（８−６＝２人）がＹとされる（ステップＳ１１７）。

このようにして、２回目のステップＳ１１６，Ｓ１１７の夫々の処理にて決定された勢力Ｄのプレイヤ数Ｘ（３人）と赤チームの空き数Ｙ（２人）との大小関係が比較される（ステップＳ１１８）。その結果、空き数Ｙ（２人）がプレイヤ数Ｘ（３人）よりも小さいため（ステップＳ１１８：ＮＯ）、このプレイヤ数Ｘを空き数Ｙに振り分けることなく、全てのプレイヤに対して検証が終了したか否かを判断する（ステップＳ１２０）。

ここでは勢力Ｅのプレイヤについての検証が済んでいないため（ステップＳ１２０：ＮＯ）、更にもう一度ステップＳ１１６からの処理を実行する。３回目のステップＳ１１６以降の処理については簡単に説明するが、ステップＳ１１６にて勢力Ｅのプレイヤ数（１人）がＸとされ、ステップＳ１１７にて優先順位の高い赤チームの空き数（２人）がＹとされる。そして、空き数Ｙ（２人）がプレイヤ数Ｘ（１人）以上であるため（ステップＳ１１８：ＹＥＳ）、このプレイヤ数Ｘが空き数Ｙに振り分けられて、勢力Ｅのプレイヤ１人は赤チームに所属される（ステップＳ１１９）。これにより、全てのプレイヤに対する検証が終了するため（ステップＳ１２０：ＹＥＳ）、チーム編成を終了し（ステップＳ１２１）、その有効性判断処理を行う（ステップＳ１２２）。

以上の編成処理により、本ケース５の場合、最終的に赤チームには、勢力Ａの６人及び勢力Ｅの１人の合計７人のプレイヤが所属し、青チームには、勢力Ｂの３人及び勢力Ｃの３人の合計６人のプレイヤが所属することとなり、勢力Ｄの３人は何れのチームにも所属されない。また、ステップＳ１２２の有効性判断処理においては、何れのチームの所属プレイヤ数も、他のチームの所属プレイヤ数の半数を下回っていないため、このチーム編成は有効と判断される（図５のステップＳ３２：ＹＥＳ）。

従って、赤チーム及び青チームに所属されたプレイヤは、このチーム編成によって勢力マッチのゲームを開始することとなる（図５のステップＳ３５、図６のステップＳ５８）。一方、チームに所属されなかった勢力Ｄのプレイヤは、該マッチングロビーから解散させられ（図６のステップＳ５６）、ステップＳ１４（図４参照）からの処理を繰り返し実行することになる。

なお、上述したケース５の例では、勢力Ｄの３人のように、何れのチームにも所属できない端数プレイヤが生じる場合について説明したが、当然ながら、このような端数プレイヤが生じずにチーム編成可能な場合もある。例えば、変形例２に係るトレード方式に従って、ケース１のような組み合わせのプレイヤ（勢力Ａ：５人、勢力Ｂ：４人、勢力Ｃ：３人、勢力Ｄ：３人、勢力Ｅ：１人）を対象にチーム編成を行った場合などである。詳しいチーム編成処理過程の説明は省略するが、この場合、該ケース１と同様に赤チームに８人（勢力Ａの５人及び勢力Ｄの３人）が所属し、青チームに８人（勢力Ｂの４人、勢力Ｃの３人、及び勢力Ｅの１人）が所属して、端数プレイヤが存在しないチーム編成となる。

ところで、変形例２に係るトレード方式では、１チーム当たりに所属できるプレイヤ数に定員を設けたため、上記のように端数プレイヤが生じる可能性がある。そして、上述した説明では、この端数プレイヤを除外して完成したチーム編成について、その有効性を判断し、有効であればこのチーム編成によって勢力マッチのゲームを開始し、端数プレイヤは該マッチングロビーから除外（解散）させられる。これにより、参加している全てのプレイヤを解散させなくてもよくなる。しかしながら、このような態様に代えて、端数プレイヤが生じた場合には、該マッチングロビーに入室していた全てのプレイヤを解散させるようにしてもよい。

また、端数プレイヤの発生を防止するために、次のような方法を採用することもできる。即ち、ゲーム装置１からサーバ装置２１へマッチング検索要求があった場合に（図４のステップＳ１４）、該検索要求をしてきたゲーム装置１に対してフィルタをかけ、端数プレイヤとなるようなプレイヤのゲーム装置１に対しては、該マッチングロビーを除外したマッチングリスト情報を送信するようにする方法である。

例えば、あるマッチングロビーに、勢力Ａの７人のプレイヤと勢力Ｂの７人のプレイヤとが入室している場合、マッチングロビーの定員（１６人）に対して２人の空きが存在している。しかしながら、ここで例えば勢力Ｃの２人のプレイヤの入室を許可すると、この２人のプレイヤを何れのチームに振り分けてもそのチームは定員を超える９人となってしまうため、そのような振り分けはできず、この２人のプレイヤは端数プレイヤになってしまう。そこで、勢力Ａ，Ｂ以外の勢力Ｃ〜Ｅのプレイヤに対しては、各チームの空き数分だけのプレイヤの入室を許可し、例えば、勢力Ｃ〜Ｅのうち参加要求タイミングの早い２つの勢力に対して、各１人だけを該マッチングロビーへ入室できるようにする。そして、勢力Ｃ〜Ｅのうち入室した勢力の２人目のプレイヤに対しては、該マッチングロビーを除外したマッチングリスト情報を送信するようにする。これにより、端数プレイヤの発生を防止することができる。

なお、マッチング検索を要求したゲーム装置１に対してフィルタをかける処理は、次のようにして行うことができる。即ち、既に説明したようにサーバ装置２１は、ホストゲーム装置１での図５のステップＳ２４（ゲストのプレイヤ情報の受信）の処理後に、該ホストゲーム装置１から、新たに入室したゲストプレイヤの情報を受信してマッチングリスト情報の内容を更新する。従って、サーバ装置２１において、新たなゲストプレイヤの情報を受信するたびに、図１６に示すチーム編成処理を仮に実行することで、その時点でのチームの空き数（図１６のステップＳ１１７で取得するＹに相当）を取得する。次に、この空き数と、その時点で入室しているプレイヤ数及びその勢力とに基づき、仮に実行する図１６のステップＳ１１８の処理で「ＮＯ」という判断になってしまう勢力のプレイヤを特定する。そして、このようなプレイヤに対して送信するマッチングリスト情報には該マッチングロビーを含めないようにすればよい。

（トレード方式の変形例３）
図１５のケース６の場合について説明する。このケース６に示すチーム編成では、対戦に参加する勢力のうち参加プレイヤ数の少ないプレイヤから順にチームに振り分けられるように設定されている。即ち、ケース６ではケース１と同じメンバー構成となっているため、参加プレイヤ数の少ない順に列挙すると、勢力Ｅ、勢力Ｃ、勢力Ｄ、勢力Ｂ、勢力Ａの順になっており、この順でチームに振り分けられる。なお、勢力Ｃと勢力Ｄとはプレイヤ数が同一であるが、勢力間の優先順位として勢力Ｃ＞勢力Ｄと設定されていることから、上記の順に振り分けられることになる。

従って、ケース６においては、まず勢力Ｅの１人が、優先順位の高い赤チームに振り分けられる。次に、勢力Ｃの３人が青チームに、勢力Ｄの３人が赤チームに、勢力Ｂの４人が青チームに、そして、勢力Ａの５人が赤チームに振り分けられる。その結果、赤チームには、勢力Ｅ、勢力Ｄ、及び勢力Ａの計９人のプレイヤが所属し、青チームには、勢力Ｃ及び勢力Ｂの計７人のプレイヤが所属することとなる。

（トレード方式の変形例４）
図１５のケース７の場合について説明する。このケース７に示すチーム編成では、赤チーム、青チーム、及び黄チームの計３チームに対して、勢力Ａ〜勢力Ｅの計１６人のプレイヤを振り分けており、振り分けるチームが３チームになっていること、及びチーム優先順位が赤＞青＞黄の順に設定されていることを除けば、その他の条件はケース１の場合と同じになっている。

従って、ケース７においては、まず最もプレイヤ数の多い勢力Ａの５人が、優先順位の高い赤チームに振り分けられ、次にプレイヤ数の多い勢力Ｂの４人が、優先順位が２番手である青チームに振り分けられる。続いて、残存勢力のうち最もプレイヤ数の多い勢力Ｃ及び勢力Ｄのうち、勢力優先順位の高い勢力Ｃの３人が、黄チームに振り分けられる。そして、勢力Ｄの３人は、所属プレイヤ数の少ない黄チームに振り分けられ、勢力Ｅの１人は、この時点で最も所属プレイヤ数の少ない青チームに振り分けられる。その結果、赤チームには勢力Ａの５人が所属し、青チームには勢力Ｂ及び勢力Ｅの５人が所属し、黄チームには勢力Ｃ及び勢力Ｄの６人が所属することとなる。

（トレード方式の変形例５）
トレード方式によるチーム編成処理の設定としては、上述した態様に限定されず、各勢力間に特別な関係を設定しておき、この関係に従ってチーム編成を行うようにしてもよい。具体的に説明すると、勢力間に同盟関係を設定しておき、この同盟関係にある勢力同士（例えば、勢力Ａ及び勢力Ｂ）を、ゲームの設定上では友好的な関係としておき、チーム編成処理においては必ず同一チームに振り分けられるようにしてもよい。また、勢力間にライバル関係を設定しておき、このライバル関係にある勢力同士（例えば、勢力Ａ及び勢力Ｃ）を、ゲームの設定上では敵対的な関係としておき、チーム編成処理においては必ず異なるチームに振り分けられるようにしてもよい。

そして、このようにチーム編成処理には様々の態様が考えられるが、ゲームにおいて１つの態様のみを採用するのではなく、ゲーム中のマップ毎に異なる態様のチーム編成処理を採用してもよいし、プレイする期間（既に述べた、例えば月曜日から次の日曜日までの１週間を１単位とする期間）毎にチーム編成処理の態様を変更させてもよい。

また、上記説明では、トレード方式により編成したチームの有効性の判断基準として、「何れのチームの所属プレイヤ数も、所属プレイヤの最も多いチームのプレイヤ数の半数を下回ることがない場合にのみ、該チーム編成を有効とする」という設定を採用した場合を前提としたが、このような判断基準に限られない。例えば、所属プレイヤの最も多いチームのプレイヤ数の「半数」ではなく、「２／３の人数」に設定してもよいし、「同一人数」に設定することも可能である。

また、上記のようなチーム間の所属プレイヤ数の割合を判断基準とすることにも限定されない。即ち、編成されたチームの構成内容に基づいて、チーム編成結果の有効性を決定することができる。

例えば、編成されたチームに所属する各プレイヤのプレイヤ情報に基づいて、編成結果の有効性を決定することもできる。より具体的には、プレイヤのポイント数から所属チームの合計ポイント数を取得し、この合計ポイント数のチーム間格差が所定範囲内に収まっていて、ポイント数でみたときのチーム間バランスが保たれている場合に、「有効」と決定するようにしてもよい。また、プレイヤのレベル値から所属チームの合計レベル値を取得し、この合計レベル値のチーム間格差が所定範囲内に収まっていて、レベル値でみたときのチーム間バランスが保たれている場合に、「有効」と決定するようにしてもよい。更に他の例として、上記のように勢力間に同盟関係を設定している場合には、同盟となる勢力のプレイヤが敵チームに存在しない場合に「有効」と決定するようにしてもよい。

［チーム編成処理の変形例：テーブル方式］
図５のステップＳ３１に示したチーム編成処理として、これまでトレード方式を採用した場合について説明してきたが、他の方式を採用することも可能である。例えば、マッチングロビーに入室している勢力毎のプレイヤ数の組み合わせと、この組み合わせから編成可能なチーム構成とを関連付けておき、想定し得る複数の組み合わせについてこれに対応するチーム構成を記載したテーブルデータを予め用意する。そして、このテーブルデータに基づき、実際にマッチングロビーに入室した勢力毎のプレイヤ数の組み合わせに対応するチーム構成を取得し、このチーム構成に従って各プレイヤを振り分けてチーム編成を行ってもよい。ここでは、このようなチーム編成方式を上記トレード方式と区別して「テーブル方式」と称することとする。

図１７は、マッチングロビーに入室している勢力毎のプレイヤ数の組み合わせと、この組み合わせから編成可能なチーム構成とを関連づけて記載したテーブルデータの模式図である。このようなテーブルデータは、ディスク型記録媒体４ａに記録されているものを読み出して参照してもよく、またはサーバ装置２１から受信して参照するようにしてもよい。

図１７に示すように、テーブルデータ５０には勢力毎のプレイヤ数の組み合わせ５０ａと、この組み合わせから編成可能なチーム構成５０ｂとが、関連づけられた状態で含まれている。このうち組み合わせ５０ａには、１つの勢力の最大プレイヤ数が８人であり、且つ総プレイヤ数が１６人以下となるような全ての組み合わせが含まれている。また、勢力の種類については識別しない。従って、例えば勢力Ａの８人及び勢力Ｂの７人で構成される組み合わせと、勢力Ａの７人及び勢力Ｂの８人で構成される組み合わせとは、同一の組み合わせ（図１７の組み合わせ５１「８：７：０：０：０」参照）として扱う。

一方、チーム構成５０ｂには、プレイヤ数の各組み合わせ５０ａに対して、両チームのプレイヤ数の差が最も少なくなる１つのチーム構成が対応付けられている。例えば、組み合わせ５２に示すように、プレイヤ数の組み合わせが「５人、３人、３人、３人、２人」である場合、赤チームに「５人＋３人」の合計８人のプレイヤを振り分け、青チームに「３人＋３人＋２人」の合計８人のプレイヤを振り分けたチーム構成が対応付けられている。

なお、この例のようにプレイヤ数が同一の勢力が複数存在し、そのうち一部の勢力のプレイヤを赤チームに振り分け、他の勢力のプレイヤを青チームに振り分ける場合がある。このような場合は、優先順の高い勢力から順に優先順位の高いチームに振り分けるようにしてもよいし、又は、抽選によって振り分けるようにしてもよい。

また、プレイヤ数の組み合わせによっては、複数種類のチーム構成が可能な場合もある。例えば、組み合わせ５３に示すように、プレイヤ数の組み合わせが「５人、４人、３人、２人、１人」である場合である。この場合、図１７に示すように赤チームに「５人＋２人＋１人」の８人を振り分け、青チームに「４人＋３人」の７人を振り分けたチーム構成の他、赤チームに「５人＋２人」の７人を振り分け、青チームに「４人＋３人＋１人」の８人を振り分けたチーム構成や、赤チームに「５人＋３人」の８人を振り分け、青チームに「４人＋２人＋１人」の７人を振り分けたチーム構成も可能である。このような場合には、図１７に示すようにテーブルデータ５０には何れか１つのチーム構成を含めるようにしてもよいし、これら全てのパターンのチーム構成を含めておき、順番に、又は抽選によって何れか１のチーム構成を採用するようにしてもよい。

更に、プレイヤ数の組み合わせによっては、何れか一方のチームのプレイヤ数が他方のチームのプレイヤ数の半数未満になってしまう場合がある。例えば、組み合わせ５４に示すように、プレイヤ数の組み合わせが「８人、１人、１人、１人、０人」の場合、どのように振り分けてチームを構成しても両チームに５人以上の差が生じてしまい、本実施の形態に係る有効性判断処理では無効になる。従って、このようなプレイヤ数の組み合わせに対しては、チーム構成５０ｂとして「無効」である旨を対応付けておく。そして、このようなプレイヤ数の組み合わせに対してチーム編成処理（図５のステップＳ３１）を行う場合は、その後の有効性の判断処理において「無効」と判断し（ステップＳ３２：ＮＯ）、チーム編成を解散（ステップＳ３３）してステップＳ１４からの処理を繰り返し実行する。

なお、図１７に示したテーブルデータ５０では、「無効」となるプレイヤ数の組み合わせについても含めた内容としたが、このような組み合わせは除外してもよい。この場合、チーム編成処理の対象となったプレイヤ数の組み合わせが、テーブルデータ５０から見つけられなかった場合には、このチーム編成を無効として解散（ステップＳ３３）すればよい。

更に、テーブルデータ５０では１チームの定員を８人としたときの内容となっているが、チーム構成５０ｂに１チームが９人以上の場合のチーム構成を含めておくことにより、チーム定員を設けない場合にも対応することができる。

以上に説明したようなテーブルデータ５０を用いることにより、参加を締め切った後のプレイヤ数の組み合わせに対応するチーム構成となるようにプレイヤを振り分けてチームを編成することができる。従って、図５のステップＳ３１に示したチーム編成処理において、先に説明したトレード方式に代えて、テーブル方式に基づいてチーム編成することも可能である。

［チーム編成処理の変形例：ハイブリッド方式］
チーム編成処理の方法としては、更に、上述したトレード方式とテーブル方式とを組み合わせた方法を採用することも可能である。このようなチーム編成方法を、ここでは「ハイブリッド式」と称することとする。

ハイブリッド式のチーム編成方法について具体的に説明すると、ゲーム装置１のＨＤＤ６に予め、プレイヤ数の組み合わせとこれに関連づけられたチーム構成とを記憶することのできる所定領域を用意しておく。そして、図５のステップＳ３１のチーム編成処理にて、まずはトレード方式に基づいてチーム編成を実行し、この処理によって得られたプレイヤ数の組み合わせとチーム構成とを関連づけて、前記ＨＤＤ６の所定領域に記憶してテーブルデータを形成する。次に、２回目以降のチーム編成処理では、既に作成したテーブルデータ中で該当するプレイヤ数の組み合わせを検索し、存在していればそれに関連づけられたチーム構成に従ってプレイヤを振り分けてチームを編成する。一方、存在していなければトレード方式によりチームを編成し、その結果得られたプレイヤ数の組み合わせとチーム構成とを関連づけてＨＤＤ６の所定領域に追加して記憶し、テーブルデータの内容を更新する。

図１８は、ハイブリッド式によるチーム編成処理によって形成されるテーブルデータの模式図である。このテーブルデータ６０には、既に説明したテーブルデータ５０と同様にプレイヤ数の組み合わせ６０ａとこれに関連づけられたチーム構成６０ｂとが含まれている。そして、上述した手順で複数回のチーム編成処理を実行することにより、記録済部６１と未記録部６２とが形成されている。このうち記録済部６１には、過去にトレード方式に基づくチーム編成処理が実行されたときに得られた組み合わせ６０ａとチーム構成６０ｂとのパターンが記録されており、未記録部６２には、今後トレード方式に基づいてチーム編成処理が実行されたときに得られるパターンが記録されるようになっている。

そして、チーム編成処理を実行する場合には、まず記録済部６１から該当するプレイヤ数の組み合わせを検索し、存在していればそれに関連づけられたチーム構成に従ってプレイヤを振り分けてチームを編成する。また、存在していなければトレード方式によりチームを編成し、その結果得られたプレイヤ数の組み合わせとチーム構成とを関連づけて未記録部６２に記録する。

ハイブリッド方式では、このように、トレード方式に基づくチーム編成処理を実行するたびに、テーブルデータ６０にその結果が追加されるため、予め全ての組み合わせとチーム構成とを記憶しておく必要がない。

また、実際にチーム編成処理の対象となるプレイヤ数の組み合わせは、全種類の組み合わせのうち、一部のものに偏っていると考えられる。換言すれば、プレイヤ数の所定の組み合わせが、他の組み合わせに比べて、チーム編成処理の対象となる可能性が高いと考えられる。従って、チーム編成処理を実行するたびに、その対象となるプレイヤ数の組み合わせの既出回数をカウントし、カウント数が大きいものほどテーブルデータ６０の記録済部６１内の上位に位置付け、テーブルデータ６０を参照する場合には、記録済部６１の上位のものから順に検索するようにしてもよい。これにより、検索速度を速めることができる。

［バトルポイントの付与処理］
ところで、上述したようなチーム編成処理が有効であった場合には、本ゲームに係る勢力マッチが開始され（図５のステップＳ３５、図６のステップＳ５８）、編成されたチーム対チームの対戦（勢力マッチ）が行われる。そして、所定の条件（設定された対戦時間の経過、一方のチームのプレイヤの全滅など）を満たした時点で対戦は終了する。また、既に述べたように、本実施の形態に係るゲーム処理では、対戦が終了した後に、対戦に参加したプレイヤの勢力に対してバトルポイントを付与する処理を行う。以下、このバトルポイントの付与処理について説明する。

図１９は、ゲーム装置１（特に、ポイント付与部６５）がバトルポイント付与処理を実行する場合の動作を説明するためのフローチャートである。図１９に示すように、ホストゲーム装置１は、勢力マッチが終了すると（ステップＳ６０）、勢力マッチに参加していた各勢力のバトルポイントの加算値を算出する（ステップＳ６１）。この処理では、まず各勢力の勝敗を、既に説明したＫＩＬＬ数、戦力ゲージ、又はデータポスト数などに基づいて決定する。このような勝敗を判定する手段は、ゲーム装置１の制御部６１（図２参照）のチーム対戦制御部６２に備えられている。

次に、各勢力の勝敗を決定すると、勝利チームに所属していた勢力については、下記の式（１）に基づいて加算値を算出し、敗北チームに所属していた勢力については、下記の式（２）式に基づいて加算値を算出する。
そして、各勢力について加算値を取得すると、サーバ装置２１にアクセスして、本対戦前のバトルポイントの最新情報とそのレイティング値とを全てのプレイヤに関して取得する（ステップＳ６２）。

ここで「レイティング値」とは、特定の情報に関連づけて付与される数値であり、最新の情報には最大のレイティング値が付与されるようになっている。更に説明すると、本実施の形態に係るサーバ装置２１は、大きいレイティング値に関連づけられた情報ほど、上位（最新情報）として記憶されるようなシステムになっている。そして、本ゲームシステム１００では、このサーバ装置２１のシステムを利用して、各プレイヤのバトルポイントをサーバ装置２１に保存することとしている。

そのため、ホストゲーム装置１は、レイティング値とバトルポイントとを関連づけて、サーバ装置２１のシステムに登録する。そして、ホストゲーム装置１は、システムの登録内容を更新するたびに、レイティング値に所定の値（例えば、１）を加算して最大値にして更新しておく。これにより、次回の更新時には、最大のレイティング値に関連づけられたバトルポイントを取得することにより、バトルポイントの最新情報を得ることができる。

このようにして、本対戦前のバトルポイントの最新情報とレイティング値の最新情報とを全チームの全てのプレイヤに関して取得すると（ステップＳ６２）、取得した最新のバトルポイントにステップＳ６１で算出した加算値を加算し（ステップＳ６３）、各プレイヤのゲーム装置１にバトルポイントの加算結果と最新のレイティング値とに関する情報を送信する（ステップＳ６４）。そして各ゲーム装置１（ホストゲーム装置及びゲストゲーム装置）は、今回対戦を行った勢力マッチの結果画面をモニタ１３に表示（ステップＳ６６）すると共に、自身の最新のレイティング値に所定の値（例えば、１）を加算し、加算後のレイティング値にステップＳ６３で算出した自身のバトルポイントを関連づけて、サーバ装置２１へ送信する（ステップＳ６７）。そして更に、各ゲーム装置１は、自プレイヤの情報として、勢力マッチへの参加回数、ポイント、レベルなどの個人情報を更新し（ステップＳ６８）、バトルポイントの付与処理を終了する。なお、上述したように、サーバ装置２１は受信したレイティング値及びバトルポイントに基づき、システムの内容を更新する。

一方、ゲストゲーム装置１の場合は、勢力マッチが終了すると（ステップＳ６０）、ホストゲーム装置１で行われるステップＳ６１〜Ｓ６４の処理の間は待機しており、ステップＳ６４でバトルポイントの加算結果と最新のレイティング値とに関する情報が送信されると、これを受信する（ステップＳ６５）。そしてその後は、上述したのと同様にステップＳ６６〜Ｓ６８の処理を実行し、バトルポイントの付与処理を終了する。

以上の処理によって、勝利チームのプレイヤの勢力には、式（１）で算出されるポイントが付与され、バトルポイントが増加する。従って各プレイヤには、自身の勢力が優勢になるために勢力マッチに参加しようとする指向が働く。また、式（１）から分かるように、自チームのプレイヤ数が少ないほど付与されるバトルポイントは大きくなるため、各プレイヤには、チーム編成により自チームのプレイヤ数が少なくても、諦めずに積極的に対戦しようとする指向が働くことになる。更に、式（１）から、対戦時の自チーム内において自勢力のプレイヤ数が多いほど付与されるバトルポイントは大きくなるため、各プレイヤには、勢力マッチに積極的に参加しようという指向が働くことになる。

なお、上記バトルポイントの付与処理では、レイティング値を利用してバトルポイントの加算値を算出し、更新する場合について説明したが、これに限定されない。即ち、最新の情報にポイントを加算して、加算後のポイントに更新できるシステムであれば他のものを採用してバトルポイントの付与処理を行うようにしてもよい。また、上記説明では、各ゲーム装置１（ホストゲーム装置及びゲストゲーム装置）が、それぞれ最新のバトルポイントに関する情報をサーバ装置２１へ送信すると言及したが、これに換えて、ホストゲーム装置１のみがサーバ装置２１へ送信するようにしてもよい。

［ポイント付与後の処理］
なお、本実施の形態に係る勢力マッチでは、このようなバトルポイントの付与によりゲーム処理は終了されるが、更に続けて次のような処理が行われる。即ち、バトルポイントの付与処理を終えると、ゲーム装置１は、該勢力マッチの対戦期間（例えば、月曜日から次の日曜日までの１週間）が終了したか否かを判断し、この期間が終了していなければ、図４のステップＳ１２以降の処理を再び実行する。

一方、この対戦期間が終了している場合には、自身が参加していた勢力が全勢力の中で、該対戦期間において獲得したバトルポイントが最も高かったか否かを判断する。即ち、各ゲーム装置１は、バトルポイントの付与処理を終えると、サーバ装置２１から各勢力が獲得したバトルポイントの値を示す情報を受信し、この情報に基づいてバトルポイント値の大きい勢力ほど順位が高くなるように順位付けを行う。この順位付けから、自身の勢力のバトルポイントが最も高かったか否かを判断する。このような処理は、ゲーム装置１の制御部６１のポイント付与部６５において、バトルポイントの付与処理に引き続いて行われる。そして、最も高かった場合には、自身（自キャラクタ）の該対戦期間中の対戦への参加回数に応じて、次にゲームをプレイする際、褒賞（例えば、特別な武器や防具、装飾品、称号など）を受け取る権利を取得して本ゲームを終了し、そうでなかった場合には褒賞を受け取る権利を獲得できずに本ゲームを終了する。

なお、上記権利に基づいて褒賞を実際に受け取ることができるのは、次にゲームをプレイすべく前期の結果画面３３をモニタ１３に表示しているとき（図４のステップＳ８参照）とするが、他のタイミングに褒賞を受け取れるように設定してもよい。また、各勢力の最新のバトルポイントの獲得比率は、図１１に示す勢力マッチメニュー３５の勢力情報３５ｂに円グラフとして表示される。

更に、褒賞を付与するための条件は、上記のように対戦期間中の獲得ポイントが最高の勢力であることに限定されない。例えば、バトルポイントに基づく勢力の順位にかかわらず、勢力マッチに参加した回数が最も多い勢力や、参加回数が所定値を超えた勢力に付与するようにしてもよい。また、勢力内で最も多く参加したプレイヤや、ＫＩＬＬ数に基づいて勢力内で最も活躍したプレイヤ（ＭＶＰやＭＩＰに該当するようなプレイヤ）に褒賞を付与するようにしてもよい。

本発明は、グループに所属するプレイヤ数や各グループから対戦に参加するプレイヤ数の偏りにかかわらず、適切なプレイヤ数から成るチーム同士の対戦を可能にし、参加プレイヤに多人数プレイの対戦ゲームの面白さを実感させることのできるゲームプログラム、該ゲームプログラムを記録した記録媒体、及びゲーム装置に適用することができる。

１ ゲーム装置（コンピュータ）
４ａ ディスク型記録媒体（記録媒体）
１０ ゲームプログラム
６１ 制御部
６２ チーム対戦制御部
６３ グループ登録部
６４ チーム編成部
６５ ポイント付与部
１００ ゲームシステム

Claims (13)

1. コンピュータを、
   該コンピュータを操作するプレイヤを複数のグループのうち何れかに登録するグループ登録手段、
   該コンピュータを操作するプレイヤと、該コンピュータに通信ネットワークを介して接続された他のコンピュータを操作する他のプレイヤとを、複数のチームの何れかに所属させるチーム編成手段、及び
   前記チームに所属する各プレイヤの操作入力に応じて、仮想ゲーム空間にて各プレイヤに対応するキャラクタを行動させ、チーム対チームの対戦を行わせるチーム対戦制御手段
   として機能させ、
   前記チーム編成手段は、各グループに登録されたプレイヤのうち前記対戦に参加するプレイヤについて、同一グループに登録された全てのプレイヤを互いに同一のチームに所属させると共に、該チームに対し、登録されたグループが互いに異なるプレイヤを所属可能になっている、ゲームプログラム。
2. 前記チーム編成手段は、前記グループにより分類したときの前記対戦への参加プレイヤの構成に基づいて、各プレイヤを前記チームに振り分けて所属させる、請求項１に記載のゲームプログラム。
3. 前記チーム編成手段は、
   複数の前記グループのうち前記対戦に参加するプレイヤ数が多いグループから順に、前記チームへプレイヤを振り分ける対象とし、
   振り分け対象のグループに登録されて前記対戦に参加する全てのプレイヤを、該グループのプレイヤを振り分ける時点で所属済みプレイヤ数の最も少ない同一のチームに所属させる、請求項２に記載のゲームプログラム。
4. 前記チーム編成手段は、各グループに優先順位を設定しており、前記対戦に参加するプレイヤ数が同一のグループが複数存在する場合には、前記優先順位の高いグループから順に該グループに登録されたプレイヤをチームに所属させる、請求項３に記載のゲームプログラム。
5. 前記チーム編成手段は、対戦する各チームに優先順位を設定しており、所属済みのプレイヤ数が同一のチームが複数存在する場合に、優先順位の高いチームから順にプレイヤを所属させる、請求項３又は４に記載のゲームプログラム。
6. 前記チーム編成手段は、チーム編成を終了した後、編成されたチームの構成内容に基づいて、編成結果の有効性を決定する、請求項１乃至５の何れかに記載のゲームプログラム。
7. 前記チームの構成内容は各チームの所属プレイヤ数であり、前記チーム編成手段は、何れのチームの所属プレイヤ数も、他の何れのチームの所属プレイヤ数に対して所定の割合を下回ることがない場合に、該チーム編成を有効とする、請求項６に記載のゲームプログラム。
8. 前記チームの構成内容は各チームに所属するプレイヤのプレイヤ情報である、請求項６に記載のゲームプログラム。
9. 前記コンピュータを、
   前記対戦の結果を判定する対戦結果判定手段と、
   該対戦の結果に応じて、該対戦に参加したプレイヤが登録された前記グループに対しポイントを付与するポイント付与手段として機能させる、請求項１乃至８の何れかに記載のゲームプログラム。
10. 前記対戦結果判定手段は、前記対戦の結果として各勢力の勝敗を判定し、
    前記ポイント付与手段は、勝利チームに所属していたプレイヤのグループに対してゼロより大きいポイントを付与し、敗北チームに所属していたプレイヤのグループに対してゼロ・ポイントを付与する、請求項９に記載のゲームプログラム。
11. 前記ポイント付与手段は、前記ポイントに基づいて各勢力を順位付けする、請求項９又は１０に記載のゲームプログラム。
12. 請求項１乃至１１の何れかに記載のゲームプログラムを記録したコンピュータ読み取り可能な記録媒体。
13. 請求項１乃至１１の何れかに記載したゲームプログラムを読み込んで実行するゲーム装置。