JP2007229040A - サーバシステム、プログラム及び情報記憶媒体 - Google Patents

Abstract

【課題】チーム対戦を行うネットワークゲームに適した、チーム対戦ゲームならではのマッチング処理（チーム編成処理）を実現すること。
【解決手段】ゲーム結果に応じて可変されるプレーヤ毎のプレイレベル値がプレーヤ管理ＤＢ１４１に記憶されている。プレーヤ端末２０からマッチング依頼を受け付けた場合、マッチング依頼のあったプレーヤを含むチーム候補を全て算出する。そして、チーム候補のレベル平均値が同程度であって、所属するプレーヤが重複しないチーム同士を対戦するチームとして決定する。
【選択図】図４

Description

本発明は、複数のプレーヤ端末と通信接続され、プレーヤ同士で構成される各対戦チームを編成する対戦ネットワークゲーム用のサーバシステム等に関する。

通信技術の進展に伴い、オンラインネットワークゲームを利用するプレーヤ人口が増加の一途を辿っている。オンラインネットワークゲームは、いわゆるパーティを組むなどして、未知のプレーヤと同一のゲーム世界を共有して遊ぶことができるのが最大の魅力である。また、囲碁やチェス等の１対１で対戦するゲームにあっては、いつでもどこでも対戦することができるのが魅力の１つとなっている。

このパーティを組む相手を検索したり、対戦相手を検索する処理はマッチング処理と呼ばれ、種々の技術が提案されている。例えば特許文献１においては、目的が共通するプレーヤ同士を組織化する技術が開示されている。
特開２００１−３４４３７２号公報

しかしながら、チーム対戦ゲームにおいては、上述の技術をそのまま適用するわけにはいかなかった。例えば、特許文献１の技術は、１つのチーム（パーティ）を組むための技術であって、対戦チーム相互の整合が図られない。すなわち、一方のチームのチーム全体のレベルと他方のチームのチーム全体のレベルとの差が考慮されないため、対戦するチーム間に差が生じ得た。また、単にプレイレベルが同程度のプレーヤ同士からなるチームが編成されるのでは特色あるチームになりにくく、面白味に欠ける面があった。

本発明は、上述の課題に鑑みて為されたものであり、その目的とするところは、チーム対戦を行うネットワークゲームに適した、チーム対戦ゲームならではのマッチング処理（チーム編成処理）を実現することである。

以上の課題を解決するための第１の発明は、
複数のプレーヤ端末と通信接続され、プレーヤ同士で構成される各対戦チームを編成する対戦ネットワークゲーム用のサーバシステム（例えば図２のサーバシステム１）であって、
ゲーム結果に応じて可変されるプレーヤ毎のプレイレベル値を記憶するプレイレベル値記憶手段（例えば図４の記憶部１３０；プレーヤ管理ＤＢ１４１；図７）と、
前記プレーヤ端末からマッチング依頼を受け付ける依頼受付手段（例えば図４の処理部１２０；図６のステップＡ１３）と、
前記記憶されているプレイレベル値に基づいて、前記依頼受付手段により受け付けられたプレーヤのうち、対戦チームそれぞれのチーム全体のプレイレベル値が所定の同程度条件を満たすプレーヤ構成でなるチームを編成するチーム編成手段（例えば図４のチーム編成処理部１２６）と、
を備えたサーバシステムである。

また、他の発明として、
複数のプレーヤ端末と通信接続される対戦ネットワークゲーム用のサーバシステムに、プレーヤ同士で構成される各対戦チームを編成させるためのプログラムであって、
ゲーム結果に応じて可変されるプレーヤ毎のプレイレベル値を記憶するプレイレベル値記憶手段、
前記プレーヤ端末からマッチング依頼を受け付ける依頼受付手段、
前記記憶されているプレイレベル値に基づいて、前記依頼受付手段により受け付けられたプレーヤのうち、対戦チームそれぞれのチーム全体のプレイレベル値が所定の同程度条件を満たすプレーヤ構成でなるチームを編成するチーム編成手段、
として前記サーバシステムを機能させるためのプログラムを構成してもよい。

この第１の発明等によれば、対戦する相互のチームそれぞれのチーム全体のプレイレベル値が同程度条件を満たすようにチームが編成される。従って、対戦するチーム間のレベルが拮抗することとなり、白熱した対戦が期待できる。

また、第２の発明として、第１の発明のサーバシステムであって、
前記対戦ネットワークゲームは、ゲーム中、所定のコミュニケーション方法により同一チームのプレーヤ端末間でコミュニケーションが可能なゲームであり、
前記プレーヤ端末それぞれの所在地情報を記憶する所在地記憶手段（例えば図４の記憶部１３０；図５の端末設置場所情報１４８）を更に備え、
前記チーム編成手段が、前記所在地記憶手段の記憶内容を参照して、前記依頼受付手段によってマッチング依頼の受け付けられたプレーヤ端末のうち、所定の同地域条件を満足するプレーヤ端末のプレーヤ同士で１つのチームを編成する同地域チーム編成手段を有するサーバシステムを構成するようにしてもよい。

この第２の発明によれば、ゲーム中、同一チームのプレーヤ同士は所定のコミュニケーション方法によりコミュニケーションが可能である。また、編成されるチームは、同地域条件を満たすプレーヤ端末のプレーヤ同士である。このため、地域的に親近感の湧き易いプレーヤ同士でチームが編成されるため、互いに未知のプレーヤであっても、比較的結束力が高まり易くなる。具体的には、例えば、互いのコミュニケーションにおいて、地域的な言葉遣いが同じであれば同一地域の人間であることが分かり、互いの親近感が高まる。

さらに、第３の発明として、この第２の発明のサーバシステムであって、
階層的な広狭の所在区域が予め定められており（例えば図５の端末設置場所情報１４８）、
前記同地域チーム編成手段が、より狭小な所在区域を優先して、同一の所在区域内のプレーヤ端末のプレーヤ同士で１つのチームを編成する（例えば図１６の所在地係数）サーバシステムを構成してもよい。

この第３の発明によれば、チームの地域性を更に高めることができ、第２の発明の作用効果をより顕著に発揮させることができる。

また、第４の発明として、第３の発明のサーバシステムであって、
前記同地域チーム編成手段が、対戦するチームのプレーヤ端末の所在地が異なる所在区域となるように対戦する相互のチームを編成するサーバシステムを構成してもよい。

この第４の発明によれば、自チームと、対戦する相手チームとは、互いに異なる所在区域に位置するプレーヤ同士で構成されるため、地域対抗ゲームの様相を呈し、一層白熱したゲームプレイになることが期待できる。

また、第５の発明として、第１〜第４の何れかの発明のサーバシステムであって、
前記依頼受付手段による受け付けたプレーヤ端末それぞれの受付時刻を記憶する受付時刻記憶手段（例えば図８の受付時刻１４２ｄ）を更に備え、
前記チーム編成手段は、前記受付時刻記憶手段に記憶された受付時刻がより古いプレーヤ端末を優先して、チームを編成する受付経過時間優先編成手段（例えば図１７）を有する、
サーバシステムを構成してもよい。

対戦する相互のチーム編成に種々の条件を付加した場合、条件を満足するチーム編成とするために、より多くのプレーヤの参加が要求され、チーム編成に要する時間が長期化する可能性がある。具体的に例を挙げて説明する。例えば、未だマッチングされていないプレーヤが多数いる場合、その数に応じて、編成可能なチーム候補の組合せも多数考えられる。ここで、できるだけ多くのチームを編成するようにマッチングする方法が考えられる。しかし、それでは、チーム編成の条件に合致しにくいプレーヤは、マッチング対象から除外され易くなり、当該プレーヤはなかなかマッチングされないという結果を招来する。この第５の発明によれば、マッチング依頼が受け付けられてからの経過時間の長いプレーヤ端末が優先されるため、そのような問題を解消することができる。

また、第６の発明として、第１〜第５の何れかの発明のサーバシステムであって、
前記依頼受付手段が、味方チームに属する味方プレーヤの前記プレイレベル値のレベル分布の希望を受け付けるレベル分布希望受付手段（例えば図９のチームタイプＲＷ３）を有し、
前記チーム編成手段が、同一チームに属するプレーヤそれぞれの前記レベル分布希望受付手段により受け付けられた希望レベル分布を満たすようにチームを編成する希望レベル分布基準編成手段を有する、
サーバシステムを構成してもよい。

この第６の発明によれば、例えば、同じレベルのプレーヤ同士からなるチームや、階層的に異なるレベルのプレーヤからなるチームといった、編成されるチームに属するプレーヤのレベル分布を希望することができる。

また、第７の発明として、第１〜第６の何れかの発明のサーバシステムであって、
前記依頼受付手段が、前記プレイレベル値に関する味方チーム内の他の味方プレーヤとの相対レベルの希望を受け付けるチーム内相対レベル希望受付手段（例えば図９の地位ＲＷ４）を有し、
前記チーム編成手段が、同一チームに属するプレーヤそれぞれの前記チーム内相対レベル布希望受付手段により受け付けられた希望相対レベルを満たすようにチームを編成する希望相対レベル基準編成手段を有する、
サーバシステムを構成してもよい。

この第７の発明によれば、例えば、自プレーヤがチーム内で最高のレベルとなるような希望や、チーム内で平均的なレベルとなるような希望をすることができる。

第８の発明は、複数のプレーヤ端末と通信接続され、プレーヤ同士で構成される各対戦チームを編成する対戦ネットワークゲーム用のサーバシステムであって、
ゲーム結果に応じて可変されるプレーヤ毎のプレイレベル値を記憶するプレイレベル値記憶手段（例えば図４の記憶部１３０；プレーヤ管理ＤＢ１４１；図７）と、
前記プレーヤの組合せでなるチーム候補を算出する候補算出手段（例えば図４のチーム編成処理部１２６；図１２のステップＣ１）と、
前記算出されたチーム候補それぞれのチーム全体のプレイレベル値を算出するチームレベル値算出手段（例えば図１２のステップＣ５）と、
前記チームレベル値算出手段により算出されたプレイレベル値が所定の同程度条件を満たすチーム候補同士を対戦する相互のチームとして決定する対戦チーム決定手段（例えば図１９のステップＦ３）と、
を備えたサーバシステムである。

また、他の発明として、複数のプレーヤ端末と通信接続される対戦ネットワークゲーム用のサーバシステムに、プレーヤ同士で構成される各対戦チームを編成させるためのプログラムであって、
ゲーム結果に応じて可変されるプレーヤ毎のプレイレベル値を記憶するプレイレベル値記憶手段、
前記プレーヤの組合せでなるチーム候補を算出する候補算出手段、
前記算出されたチーム候補それぞれのチーム全体のプレイレベル値を算出するチームレベル値算出手段、
前記チームレベル値算出手段により算出されたプレイレベル値が所定の同程度条件を満たすチーム候補同士を対戦する相互のチームとして決定する対戦チーム決定手段、
として前記サーバシステムを機能させるためのプログラムを構成することとしてもよい。

この第８の発明等によれば、チーム候補のうち、対戦する相互のチームそれぞれのチーム全体のプレイレベル値が同程度条件を満たすチーム候補同士が、対戦する相互のチームとされる。従って、対戦するチーム間のレベルが拮抗することとなり、白熱した対戦が期待できる。

また、第９の発明として、第８の発明のサーバシステムであって、
前記算出されたチーム候補それぞれの優先度指数を算出する優先度指数算出手段（例えば図１５のステップＥ５）を更に備え、
前記対戦チーム決定手段は、前記算出された優先度指数の高いチーム候補を優先して対戦チームとする優先決定手段（例えば図１５のステップＥ９；図１９のステップＦ５）を有する、
サーバシステムを構成してもよい。

この第９の発明によれば、チーム候補それぞれの優先度指数が算出され、算出された優先度指数の高いチーム候補が優先して対戦チームとして決定される。多数のチーム候補の中には、優先して対戦チームとすべきものや、優先度の低いものが混在しており、その判断尺度となる優先度指数が算出される。

また、第１０の発明として、第９の発明のサーバシステムであって、
前記対戦ネットワークゲームは、ゲーム中、所定のコミュニケーション方法により同一チームのプレーヤ端末間でコミュニケーションが可能なゲームであり、
前記プレーヤ端末それぞれの所在地情報を記憶する所在地記憶手段（例えば図４の記憶部１３０；図５の端末設置場所情報１４８）を更に備え、
前記優先度指数算出手段が、前記所在地記憶手段の記憶内容を参照して、所定の同地域条件を満足するプレーヤ端末のプレーヤ同士でなるチーム候補の優先度指数を、同地域条件を満たさないチーム候補より高く算出する（例えば図１６）、
サーバシステムを構成してもよい。

この第１０の発明によれば、同地域条件を満たすプレーヤ端末のプレーヤ同士でなるチーム候補の優先度指数が、同地域条件を満たさないチーム候補より高く算出されるため、同地域条件を満たすチーム候補の方が優先して対戦チームとされる。同地域条件を満たすプレーヤ同士は、地域的に親近感が湧きやすいと言えるため、結束力の高まり易いチームになると考えられる。具体的には、例えば、互いのコミュニケーションにおいて、地域的な言葉遣いが同じであれば同一地域の人間であることが分かり、互いの親近感が高まる。見知らぬプレーヤ同士がチームを組むネットワークゲームにおいては有効な手段である。

以下、図面を参照して、本発明を実施するための最良の形態を説明する。尚、以下では、複数のプレーヤが同時に同一のゲーム空間を共有して楽しむネットワーク対戦型のガンシューティングゲームに本発明を適用した場合の形態について説明するが、本発明を適用し得る実施形態がこれに限定されるものではない。

ネットワークゲームを実現するゲームシステムの構成としては、例えば、（Ａ）パソコンや家庭用ゲーム機等をプレーヤ端末とし、インターネット網や専用線網等の有線／無線の通信回線を介してゲームサーバと接続する構成、（Ｂ）ゲームサーバを用いることなく複数のプレーヤ端末同士が通信回線を介して接続される構成、（Ｃ）複数のプレーヤ端末同士が通信回線を介して接続されるが、その内の１台がゲームサーバ機能を有する構成、（Ｄ）複数のプレーヤ端末が物理的に結合した、全体として１台のシステム（例えば業務用ゲーム機）となっている構成、等がある。本発明は何れのシステム構成に対しても適用可能であるが、以下では、（Ａ）の構成のゲームシステムを例にとって説明する。詳細には、本実施形態のゲームシステムは、各地のゲームセンターやアミューズメント施設等を通信回線で結んだ全国的なシステムであり、管理サーバ及びゲームサーバで構成されるサーバシステムがゲーム提供事業者側に設置されて構成される。

１．システム概要
図１は、ある店舗の一区域に設置されたプレーヤ端末２０の設置状況の一例を示している。同図に示すように、当該区域には、キーボード、マウス、ディスプレイ及び本体を備える複数のプレーヤ端末２０が配列されて設置されており、遊戯者（プレーヤ）は、プレーヤ端末２０を操作してガンシューティングゲームを楽しむ。

図２は、ゲームシステム５の概略構成を示す図である。同図に示すように、ゲームシステム５は、複数のプレーヤ端末２０が、例えば、無線通信回線、専用線、ツイストペアケーブル、光通信ケーブル等の通信回線を介し、ＬＡＮ或いはＷＡＮ等のネットワークＮを介してサーバシステム１に接続されて構成される。

サーバシステム１は、１台又は複数台のサーバコンピュータで構成され、主に、プレーヤ情報の管理処理と、プレーヤのマッチングにかかるチーム編成処理と、対戦ネットワークゲームの進行を制御するゲーム進行制御処理との３つの処理を同時並行的に実行している。プレーヤ情報の管理処理には、プレーヤの新規登録やログイン認証などの他、チーム対戦に対する希望条件を入力する処理が含まれる。

チーム編成処理とは、ログイン認証されたプレーヤを組み合わせることで、対戦するそれぞれのチームを編成するマッチングに関する処理である。ゲーム進行制御処理とは、チーム編成処理によって編成されたチーム同士による対戦ゲームの進行を制御する処理である。また、対戦ゲームの結果に基づいて、当該ゲームに参加したプレーヤのゲームプレイを評価し、プレイレベル値を変更する。本実施の形態は、特にチーム編成処理に特徴がある。

プレーヤ端末２０は、コンピュータシステムによって実現され、サーバシステム１にアクセスしてゲームシステム５にログインし、ネットワークゲームのクライアント用ゲームプログラムを適宜実行することによって、他のプレーヤ端末２０又はサーバシステム１からネットワークゲームのゲームプレイに係るゲームデータを取得し、取得したゲームデータに基づいてゲーム画像を生成して表示する。

プレーヤ端末２０は、各地のアミューズメント施設に設置されるが、例えば、図２に示すように、東京の新宿店の１階や２階、名古屋の栄店の１階といった具合に設置される。各プレーヤ端末２０それぞれが設置されている地域、店舗、フロア等の設置場所はサーバシステム１に登録されている。図５は、各プレーヤ端末２０の端末ＩＤと、当該プレーヤ端末２０が設置されている設置場所との対応関係を示す端末設置場所情報１４８の構成例を示す図である。同図に示すように、設置場所には、最も大きな区域である地域（東京、大阪、名古屋等）と、中程度の区域である店舗（新宿店、渋谷店等）と、最小の区域であるフロア（１階、２階等）との３段階の区域がある。

２．ゲーム概要
本実施形態の対戦ネットワークゲームは、１人称視点のガンシューティングゲームであり、３人のプレーヤで１つのチームが組まれ、プレーヤチーム同士で対戦する。各プレーヤはそれぞれ銃を備えた１体の兵士キャラクタを操作する。兵士キャラクタが撃たれ、死亡した場合には、当該プレーヤはその場でゲームから脱けることとなる。被弾した部位に応じてダメージが異なるが、例えば額を撃たれた場合には１発で死亡と判断される。従って、緊張感、緊迫感のあるゲーム性となっている。

また、本実施形態のゲームは攻撃側と防御側との２つのチームに分かれて対戦するゲームである。勝敗は、予め定められた規定時間内に、予め定められた爆弾設置位置に攻撃側が時限爆弾を設置し、爆破させることができれば攻撃側のチームの勝利となり、規定時間内での爆破を阻むことができれば防御側のチームの勝利となる。また、攻撃側が時限爆弾を設置した後も、爆破作動前であれば防御側が爆弾を解除することができる。このため、設置した時限爆弾が解除された場合には、勝利するために、攻撃側は再度時限爆弾を設置する必要がある。

但し、被弾し、死亡と判断された兵士キャラクタはゲームから離脱させられるため、参戦している兵士キャラクタは減少していく一方である。よって、攻撃側／防御側のチームとして、どのように攻撃するか、どのように防御するかの戦略が重要となり、チームワークが勝敗を決する重要な要素となる。各プレーヤは、あたかも戦場で戦闘しているかのような緊張感溢れるエキサイティングなゲームを楽しむことができる。

図３（ａ）はゲーム空間のマップを示す図であり、ゲーム空間全体を上から俯瞰した略図である。図３（ｂ）は同図（ａ）のゲーム画面の一例を示す図であり、兵士キャラクタＡＣ１の視点（１人称視点）から見たゲーム空間の画像が表示されている。

図３において、ゲーム空間は１つの閉空間であり、複数のコンテナＣＴ１〜ＣＴ５と、攻撃側の兵士キャラクタであるキャラクタＡＣ１〜ＡＣ３と、防御側の兵士キャラクタであるキャラクタＤＣ１〜ＤＣ３とが配置されている。各兵士キャラクタＡＣ１〜ＡＣ３，ＤＣ１〜ＤＣ３は個々のプレーヤによりそれぞれのプレーヤ端末２０で操作されている。また、ゲーム空間中には爆弾設置位置ＢＳＰが予め設定・明示されており、攻撃側がこの爆弾設置位置ＢＳＰに規定時間内に爆弾を設置し、爆破させることができれば攻撃側の勝利となり、規定時間内に爆破させることができなければ防御側の勝利となる。

各キャラクタＡＣ１〜ＡＣ３，ＤＣ１〜ＤＣ３は、ゲーム開始時に所定の陣地（例えば、図３（ａ）のＳＴ１，ＳＴ２）にそれぞれ配置される。そして、ゲーム開始に伴い、各キャラクタＡＣ１〜ＡＣ３，ＤＣ１〜ＤＣ３は、プレーヤ操作に従って所与の位置に移動される。

図３（ｂ）は兵士キャラクタＡＣ１を操作するプレーヤのプレーヤ端末に表示されるゲーム画面である。他のプレーヤのプレーヤ端末２０には、当該プレーヤが操作する兵士キャラクタの視点から見たゲーム空間の画像が表示される。すなわち、何れのプレーヤ端末においても、当該兵士キャラクタの視点から見たゲーム空間の画像のみが表示される。従って、同一のゲーム空間を共有してゲームが進行するが、一のプレーヤにとっては、一のプレーヤが操作する兵士キャラクタの視点でしかゲーム空間の様子を伺い知ることができない。即ち、他の兵士キャラクタからゲーム空間がどのように見えているのか、他の兵士キャラクタから自分の兵士キャラクタが見えているのか、といったことは推測するしかない。このため、より実戦に近い戦闘が模擬されることとなる。

また、図３（ｂ）のゲーム画面に示す通り、各プレーヤのゲーム画面内には、チャットウィンドウＣＨＷが表示され、同一チームの他のプレーヤとの間では、あたかも戦場での無線通信のようにチャットによって互いのコミュニケーションが取れるようになっている。但し、死亡と判断されると、当該死亡と判断された兵士キャラクタを操作するプレーヤ端末との間のチャットが不可能となる。この点でもより実戦に近い戦闘が模擬される。

なお、本実施形態では、チャットは文字で行うこととして説明するが、文字である必要はなく、ヘッドセット等を用いて実際にプレーヤ同士が音声で会話してコミュニケーションを取ることにしてもよい。

３．機能構成
次に、本実施形態におけるサーバシステム１の機能構成について説明する。図４は、サーバシステム１の機能構成の一例を示すブロック図である。図４に示すように、サーバシステムは、操作部１１０、処理部１２０、記憶部１３０、表示部１５０、通信部１６０等を備えて構成され、プレーヤ端末２０との間でデータ通信を行って、上述したプレーヤ情報の管理処理、プレーヤのマッチングにかかるチーム編成処理、対戦ネットワークゲームの進行を制御するゲーム進行制御処理等を実行する。

操作部１１０は、サーバシステム１の管理者等による操作指示を受け付け、操作に応じた操作信号を処理部１２０に出力する。この機能は、例えばボタンや操作スティック、ダイヤル、マウス、キーボード、各種センサ等によって実現される。

処理部１２０は、サーバシステム１全体の制御やゲームの進行、画像生成等の各種演算処理を行う。この機能は、例えばＣＰＵ（ＣＩＳＣ型、ＲＩＳＣ型）、ＡＳＩＣ（ゲートアレイ等）等の演算装置やその制御プログラムにより実現される。

処理部１２０は、主な機能部として、プレーヤ管理部１２４と、チーム編成処理部１２６と、ゲーム進行制御部１２８とを含んで構成される。

プレーヤ管理部１２４は、プレーヤ管理プログラム１３８に従って、プレーヤ管理処理を実行する。図６はプレーヤ管理処理の流れを示すフローチャートである。プレーヤ管理部１２４は、プレーヤ端末２０からプレーヤとしての新規登録依頼があるか否かを監視し（ステップＡ１）、新規登録依頼があった場合（ステップＡ１：ＹＥＳ）には新規登録処理を行い、当該プレーヤに関する新たなプレーヤデータを作成してプレーヤ管理ＤＢ１４１に登録する（ステップＡ３）。新規登録処理は、プレーヤを新たに登録する処理であって、従来公知の処理と同様である。図７にプレーヤ管理ＤＢ１４１の構成例を示す。図７に示す通り、プレーヤ管理ＤＢ１４１は、プレーヤ１人ずつのプレーヤデータ１４１−１，１４１−２・・・から成り、各プレーヤデータにはプレーヤ名１４１ａ、プレーヤＩＤ１４１ｂ、プレーヤ認証用のパスワード１４１ｃ、当該プレーヤのプレイレベルを示すレベル値１４１ｄ・・・等が記録されている。尚、図示していないが、プレーヤが使用するキャラクタの識別情報や、当該ゲームで獲得したゲームマネー、当該プレーヤが現在ログイン中か否かのフラグ、ログイン中である場合には現在プレイ中のプレーヤ端末の端末ＩＤ等もプレーヤ管理ＤＢ１４１に記録される。

また、プレーヤ管理部１２４は、プレーヤ端末２０からログイン要求があるか否かを監視する（ステップＡ５）。ログイン要求があった場合（ステップＡ５：ＹＥＳ）にはプレーヤの認証処理を行ってプレーヤを特定する（ステップＡ７）。認証処理は、プレーヤ管理ＤＢ１４１に登録されているプレーヤ名１４１ａとプレーヤＩＤ１４１ｂ、パスワード１４１ｃを照合する処理であって、従来公知の処理と同様である。認証の結果、登録済みの正規のプレーヤであることが了解された場合（ステップＡ９：ＹＥＳ）には、当該プレーヤがログインされた旨及び当該プレーヤがログインしたプレーヤ端末２０の端末ＩＤをプレーヤ管理ＤＢ１４１に登録して、当該プレーヤ端末２０からの処理依頼待ちとなる。

次いで、プレーヤ管理部１２４は、認証されたプレーヤのプレーヤ端末２０から対戦ゲーム開始の希望信号が送信されたか否かを判定する（ステップＡ１１）。対戦ゲーム開始の希望信号ではなく（ステップＡ１１：ＮＯ）、他の処理依頼の信号をプレーヤ端末２０から受信した場合は、その信号に応じた処理を実行する（ステップＡ１７）。

一方、対戦ゲーム開始の希望信号をプレーヤ端末２０から受信した場合（ステップＡ１１：ＹＥＳ）には、プレーヤ管理部１２４は、当該信号を送信したプレーヤ端末２０の端末ＩＤと、プレーヤとを対応付けて新たな受付データを作成して、マッチング受付情報１４２に登録する（ステップＡ１３）。そして、チーム編成に関する希望条件を入力する希望条件入力処理を行って（ステップＡ１５）、対戦ゲーム開始を希望するプレーヤの希望条件を併せてマッチング受付情報１４２に登録する。

図８はマッチング受付情報１４２の構成例を示す図である。マッチング受付情報１４２は、対戦ゲーム開始の希望が受け付けられたプレーヤ１人ずつの受付データ１４２−１，１４２−２・・・から成る。各受付データには、プレーヤ名１４２ａ、プレーヤＩＤ１４２ｂ、レベル値１４２ｃ、受付時刻１４２ｄ、希望条件１４２ｈ、端末ＩＤ１４２ｐ、端末設置場所１４２ｑが対応付けて記録される。

希望条件入力処理は、対戦ゲーム開始の希望を受け付けたプレーヤに対して、編成されるチームに関する希望を伺う処理である。具体的には、プレーヤ管理部１２４が希望伺い信号を送信して当該プレーヤ端末２０に希望条件入力画面を表示させて、希望条件を問い合わせる処理である。図９に、プレーヤ端末２０に表示される希望条件入力画面の一例を示す。

図９において、希望条件入力画面ＲＷには、希望の有無を入力するラジオボタンＲＢ１Ｂ，ＲＢ２Ｂと、詳細な希望としてチームタイプＲＷ３、地位ＲＷ４、希望条件解除時限ＲＷ５を入力する入力欄とが配置されている。チームタイプとは、チームに所属するプレーヤのプレイレベル値の分布であって、プレイレベル値の組織的な構成である。具体的には、平均型と、直列型と、ピラミッド型とがある。１チームは３人のプレーヤで構成されるが、「平均型」は、それぞれのプレーヤのレベル値が所定の均一範囲内（例えばレベル値の最大〜最小の差が１．０以下）にある場合のチームタイプであり、「直列型」は、３人のプレーヤのレベル値が高、中、低に分かれ、それぞれのレベル値の差の何れもが所定の均一範囲内にない場合のチームタイプであり、「ピラミッド型」は、２人のプレーヤのレベル値は所定の均一範囲内であるが、残る１人のレベルが、均一範囲内になく、均一範囲内にある２人のプレーヤそれぞれよりも高いレベル値にある場合のチームタイプである。

地位とは、チーム内における当該プレーヤの立場を示し、具体的には、チーム内における当該プレーヤのレベル値がどの位置かを示すものである。「平均型」のチームタイプであれば、地位は“同等”しかなく、「直列型」のチームタイプであれば、“トップ”、“真ん中”、“下”の３つの地位があり、「ピラミッド型」のチームタイプであれば、“トップ”と“下”の２つの地位がある。

チームタイプＲＷ３と、地位ＲＷ４とに入力可能な選択肢の構成を図１０に示す。上述した通り、チームタイプが選択された場合には、選択可能な地位の種類は定まる。但し、地位に関する希望が無い場合には“希望無し”を選択可能である。具体的には、チームタイプとして「ピラミッド型」を希望するが、「ピラミッド型」のチームであれば、「トップ」であろうが「下」であろうがどちらでも良い場合には、プレーヤは、地位については「希望無し」を選択すればよい。

希望条件解除時限とは、マッチング希望が受け付けられてから、希望条件を解除するまでの時間である。サーバシステム１は、希望条件に合致するチームの編成を試みるが、マッチング依頼を受け付けたプレーヤの数や各プレーヤの希望条件によっては、マッチング希望が受け付けられてから条件を満足するマッチングが成立するまで長時間を要する場合がある。プレーヤは、希望条件を満足しなくとも出来る限り早く対戦ゲームを実行したい場合には、希望条件解除時限として短い時間（例えば１分）を入力すれば良いし、長時間待ってもよいから希望条件を満たすチームによる対戦を希望する場合には、希望条件解除時限として長時間（例えば１２０分）を入力すれば良い。希望条件解除時限は、いわば、希望する条件を満足するチームが編成されるまでに待てる時間といえる。

図４に戻る。チーム編成処理部１２６は、チーム編成処理プログラム１３１に従って、チーム編成処理を実行し、実行中、サブルーチン処理として、チーム候補追加更新プログラム１３２に従ったチーム候補追加更新処理と、解除時間経過時処理プログラム１３３に従った解除時間経過時処理と、優先度指数算出処理プログラム１３４に従った優先度指数算出処理と、対戦チーム選別処理プログラム１３５に従った対戦チーム選別処理とを実行する。

各処理の動作を詳細に説明する。図１１はチーム編成処理の流れを示すフローチャートである。チーム編成処理部１２６は、新たに、対戦ゲーム開始の希望信号が受信され、プレーヤ管理部１２４によってマッチング依頼が受け付けられたか否かを監視し（ステップＢ１）、新たにマッチング依頼が受け付けられたプレーヤがいる場合には（ステップＢ１：ＹＥＳ）、チーム候補追加更新処理プログラム１３２を読み出してチーム候補追加更新処理を実行する（ステップＢ３）。

図１２はチーム候補追加更新処理の流れを示すフローチャートである。チーム候補追加更新処理において、チーム編成処理部１２６は、先ず、マッチング依頼を受け付けた新たなプレーヤを含むチーム候補の組合せを全て算出する（ステップＣ１）。例えば、マッチング受付情報１４２に登録されている、既にマッチング依頼を受け付けたプレーヤとしてプレーヤＡ，Ｂ，Ｃがおり、新たにプレーヤＤのマッチング依頼を受け付けた場合には、この新たなプレーヤＤを含むチーム候補である（Ａ，Ｂ，Ｄ）、（Ａ，Ｃ，Ｄ）、（Ｂ，Ｃ，Ｄ）の３つのチーム候補を算出する。

次いで、算出したチーム候補それぞれについて、ループＡの処理を実行する（ステップＣ３〜Ｃ２１）。以下、ループＡにおいて、処理対象のチーム候補のことを当該チーム候補と称して説明する。

チーム編成処理部１２６は、当該チーム候補に所属するプレーヤの受付データに基づき、各プレーヤのレベル値１４２ｃの平均値をレベル平均値として算出する（ステップＣ５）。また、各プレーヤのレベル値の分布に基づいてチームタイプを判定する（ステップＣ７）。チームタイプの判定は、各プレーヤのレベル値のそれぞれの差が、所定の均一範囲内か否かによって、「平均型」、「直列型」、「ピラミッド型」の３種の何れに該当するかを判定する。３種のいずれにも該当しない場合は、チームタイプは「無し」となる。

また、当該チーム候補のプレーヤが操作している端末の端末設置場所１４２ｑに基づいて、当該チーム候補のチーム所在地を判定する（ステップＣ９）。具体的には、チーム所在地は次のようにして判定される。すなわち、端末の設置場所は大きく３つの段階の区域に分けられることは図５を参照して説明した通りであるが、この設置場所として当該チーム候補に属する３人のプレーヤの端末設置場所１４２ｑとして共通する区域（但し、広い区域から順に）をチーム所在地として判定する。例えば、プレーヤＡの端末設置場所１４２ｑが「東京」「新宿店」「１Ｆ」であり、プレーヤＢの端末設置場所１４２ｑが「東京」「新宿店」「２Ｆ」であり、プレーヤＤの端末設置場所１４２ｑが「東京」「新宿店」「２Ｆ」であったとするならば、地域「東京」と店舗「新宿店」とが３人のプレーヤにおいて共通する。従って、この場合のチーム所在地は「東京」「新宿店」となる。

また、例えば、プレーヤＡの端末設置場所１４２ｑが「東京」「新宿店」「１Ｆ」であり、プレーヤＢの端末設置場所１４２ｑが「東京」「渋谷店」「１Ｆ」であり、プレーヤＤの端末設置場所１４２ｑが「東京」「新宿店」「１Ｆ」であったとするならば、フロア「１Ｆ」は共通するが、店舗が異なる。よって、広い区域である地域「東京」のみが３人のプレーヤにおいて共通するとして、この場合のチーム所在地は「東京」となる。なお、地域さえも３人のプレーヤに共通しない場合には、チーム所在地は「無し」となる。

次いで、チーム編成処理部１２６は、最古受付時刻を判定する（ステップＣ１１）。最古受付時刻とは、当該チーム候補に属する各プレーヤの受付時刻１４２ｄのうち、最も古い受付時刻のことである。

次いで、チーム編成処理部１２６は、当該チーム候補の情報を、当該チーム候補にＩＤを付与してチーム候補情報１４４に登録する（ステップＣ１３）。図１３はチーム候補情報１４４の構成の一例を示す図である。チーム候補情報１４４は、チーム候補毎の情報が纏めて登録されている情報であって、当該チーム候補に属するプレーヤの受付データと同じデータとして、プレーヤ名１４４ａ、プレーヤＩＤ１４４ｂ、レベル値１４４ｃ、受付時刻１４４ｄ、希望条件のチームタイプ１４４ｅ、希望条件の地位１４４ｆ、希望条件の解除時限１４４ｇ、端末ＩＤ１４４ｐ、端末設置場所１４４ｑが登録されているとともに、ステップＣ５で判定されたレベル平均値１４４ｖと、ステップＣ７で判定されたチームタイプ１４４ｗと、ステップＣ９で判定されたチーム所在地１４４ｓと、ステップＣ１１で判定された最古受付時刻１４４ｕと、解除時間経過時処理や優先度指数算出処理において算出される最長経過時間１４４ｔと、同じく優先度指数算出処理において算出される優先度指数１４４ｘとが登録される。

なお、ステップＣ１３の時点では、最長経過時間１４４ｔと、優先度指数１４４ｘとは算出されていないため、これらの値は登録されない。

チーム候補情報の登録の後、チーム編成処理部１２６は、当該チーム候補が、当該チーム候補に所属する全てのプレーヤの希望条件を満足するチームであるか否かを判定する（ステップＣ１５）。具体的には、例えば、プレーヤＡ，Ｂ，Ｄからなるチーム候補である場合、プレーヤＡ，Ｂ，Ｄそれぞれの希望条件であるチームタイプ１４４ｅ及び地位１４４ｆを満足するチームであるか否かを判定する。

そして、全てのプレーヤの希望条件を満足してはいないと判定した場合（ステップＣ１５：ＮＯ）、チーム編成処理部１２６は、当該チーム候補を、候補待機リスト１４６へ登録する（ステップＣ１５）。一方、全てのプレーヤの希望条件を満足すると判定した場合には（ステップＣ５：ＹＥＳ）、当該チーム候補を、候補リスト１４５に登録する（ステップＣ１７）。

以上のステップＣ５〜Ｃ１９の処理を、ステップＣ１で算出したチーム候補全てに対して行った場合には、チーム候補追加更新処理を終了する（ステップＣ２１）。

図１１に戻り、チーム候補追加更新処理の後、チーム編成処理部１２６は、解除時間経過時処理プログラム１３３を読み出して解除時間経過時処理を実行する（ステップＢ５）。

図１４は、解除時間経過時処理の流れを示すフローチャートである。解除時間経過時処理では、チーム編成処理部１２６は、候補待機リスト１４６に登録されているチーム候補それぞれについてループＢの処理を行う（ステップＤ１〜Ｄ９）。以下、ループＢにおいて、処理対象のチーム候補のことを当該チーム候補と称して説明する。

先ず、チーム編成処理部１２６は、当該チーム候補の最長経過時間１４４ｔを算出（ステップＤ３）してチーム候補情報１４４を更新する。最長経過時間とは、当該チーム候補の最古受付時刻１４４ｕから現在までの経過時間である。

次に、算出した最長経過時間１４４ｔが、当該チーム候補の全てのプレーヤの希望条件の解除時限１４４ｇ以上か否かを判定することで、全てのプレーヤの解除時限１４４ｇを経過しているか否かを判定する（ステップＤ５）。全てのプレーヤの解除時限１４４ｇを経過していると判定された場合には（ステップＤ５：ＹＥＳ）、当該チーム候補を、候補待機リスト１４６から削除し、候補リスト１４５に登録する（ステップＤ７）。一方、経過していないと判定された場合には（ステップＤ５：ＮＯ）、候補待機リスト１４６へ登録されたままとする。

以上のステップＤ３〜Ｄ７の処理を、候補待機リスト１４６に登録されている全てのチーム候補について行った場合には解除時間経過時処理を終了する（ステップＤ９）。

図１１に戻り、解除時間経過時処理の後、チーム編成処理部１２６は、優先度指数算出処理プログラム１３４を読み出して優先度指数算出処理を実行する（ステップＢ７）。

図１５は、優先度指数算出処理の流れを示すフローチャートである。優先度指数算出処理では、先ず、チーム編成処理部１２６は、候補リスト１４５に登録されているチーム候補それぞれについてループＣの処理を行う（ステップＥ１〜Ｅ７）。以下、ループＣにおいて処理対象のチーム候補のことを当該チーム候補と称して説明する。

先ず、チーム編成処理部１２６は、当該チーム候補の最長経過時間１４４ｔを算出（ステップＥ３）してチーム候補情報１４４を更新する。

次いで、当該チーム候補の優先度指数１４４ｘを算出する（ステップＥ５）。ここで、優先度指数は次の（１）式から求まる。
優先度指数＝所在地係数×経過時間係数×満足度合係数・・・（１）

所在地係数とは、チーム所在地に基づく係数であり、当該チーム候補のチーム所在地が狭小な区域である程大きな係数が設定される。図１６に、当該チーム候補に所属する各プレーヤの端末設置場所と、所在地係数との対応関係の一例を示す。図１６において、当該チーム候補に所属する各プレーヤの端末設置場所が、「地域」、「店舗」、「フロア」の３つとも同じであった場合には、各プレーヤが最も狭小な区域内に位置するとして、所在地判定レベルを最も高いレベルの「Ａ」と判定し、所在地係数として最も高い“２．０”の値を設定する。例えば、チーム所在地１４４ｓが「東京」「新宿店」「１Ｆ」と登録されていた場合である。また、「地域」のみが同じで「店舗」、「フロア」が異なる場合には、所在地係数として“０．５”の値が設定される。例えば、チーム所在地１４４ｓが「東京」と登録されていた場合が該当する。

従って、当該チーム候補に所属するプレーヤが、お互いにより狭小な区域内に位置するほど、優先度指数が高くなることとなる。

経過時間係数とは、最長経過時間１４４ｔの値に応じた係数である。図１７に、最長経過時間１４４ｔと、経過時間係数との対応関係を示すグラフを示す。最長経過時間１４４ｔが“１０分”までは経過時間係数は“１．０”であり、“１０分”を超え“３０分”までは経過時間係数“２．０”に向けて経過時間に応じて比例して経過時間係数が増え、“３０分”を超えると経過時間係数の増加割合が急峻となって、“５０分”において“５．０”の経過時間係数となる。

従って、最長経過時間の長いチーム候補ほどマッチング待ち時間が長いとして優先度指数が高くなることとなる。

満足度合係数とは、当該チーム候補に所属する各プレーヤの希望条件をどの程度満足しているかを示す係数であって、希望条件を満足するプレーヤの数が多いほど、大きな係数となる。図１８に、希望条件を満足するプレーヤの数と、満足度合係数との対応関係の一例を示す。例えば、当該チーム候補に所属するプレーヤ全員の希望条件を満足する場合には、満足度合係数として“１０”が設定され、３人のプレーヤ全ての希望条件を満足しない場合には、満足度合係数として“０．５”が設定される。

従って、希望条件を満足するプレーヤの数の多いチーム候補ほど優先度指数が高くなることとなる。

なお、所属するプレーヤ全ての希望条件を満足しないチーム候補が候補リスト１４５に登録されるのは、解除時間経過時処理（図１４参照）において、所属するプレーヤ全ての希望条件の解除時限が経過したチーム候補が、いわば「マッチングの時間切れ」として候補リスト１４５に登録されるためである。

チーム編成処理部１２６は、当該チーム候補の所在地係数、経過時間係数及び満足度合係数を算出した後、（１）式に基づいて優先度指数１４４ｘを算出して、チーム候補情報１４４を更新する（ステップＥ５）。

候補リスト１４５に登録されている全てのチーム候補についてステップＥ３〜Ｅ５の処理を行った場合、チーム編成処理部１２６は、候補リスト１４５に登録されているチーム候補の登録順番を、ステップＥ５で算出した優先度指数順にソートする処理を行う（ステップＥ９）。これにより、候補リスト１４５には、優先度指数の高いチーム候補から順番に登録されている状態となる。
以上で優先度指数算出処理が終了となる。

図１１に戻り、優先度指数算出処理の後、チーム編成処理部１２６は、対戦チーム選別処理プログラム１３５を読み出して対戦チーム選別処理を実行する（ステップＢ９）。

図１９は、対戦チーム選別処理の流れを示すフローチャートである。対戦チーム選別処理では、チーム編成処理部１２６は、先ず、候補リスト１４５に登録されているチーム候補の中から、優先度指数１４４ｘの最も高いチーム候補を選択して、第１チームとする（ステップＦ１）。

次いで、レベル平均値１４４ｖが、第１チームと同程度で且つ、所属しているプレーヤが第１チームと全く異なるチーム候補を候補リスト１４５から抽出する（ステップＦ３）。

チーム候補を抽出できた場合には（ステップＦ３：有り）、抽出されたチーム候補のうち、優先度指数１４４ｘの最も高いチーム候補を第２チームとして選択する（ステップＦ５）。そして、第１チームと第２チームとで対戦を行うことを決定する（ステップＦ７）。

そして、第１チーム及び第２チームに所属する各プレーヤのプレーヤ端末２０に、対戦チーム決定通知を行う（ステップＦ８）。図２０は、この対戦チーム決定通知によってプレーヤ端末に表示される画面例である。第１チームであれば、第１チームに所属するプレーヤそれぞれのプレーヤ名及びレベル値と、第１チームのチーム所在地と、第１チームのチームタイプとが、チーム候補情報１４４から読み出されて通知される。また、相手チームである第２チームのチーム所在地が通知される。

次いで、チーム編成処理部１２６は、第１チームと第２チームそれぞれに所属するプレーヤを１人でも含んでいるチーム候補を候補リスト１４５、候補待機リスト１４６及びマッチング受付情報１４２から削除し（ステップＦ９）、第１チームと第２チームによる対戦ゲームを行う旨、及びそれぞれのチーム候補情報を対戦チーム情報１４９に登録する（ステップＦ１０）。

ステップＦ９の処理の後、又は、ステップＦ３で、チーム候補が抽出されなかった場合（ステップＦ３：無し）には、優先度指数１４４ｘが第１チームの優先度指数の次に高いチーム候補が候補リスト１４５に有れば（ステップＦ１１：ＹＥＳ）、そのチーム候補を第１チームとして（ステップＦ１３）、ステップＦ３〜Ｆ１１の処理を繰り返す。一方、第１チームの優先度指数の次に高いチーム候補が候補リスト１４５に登録されていない場合には（ステップＦ１１：ＮＯ）、全てのチーム候補についてステップＦ３〜Ｆ１１の処理を行ったと判断して対戦チーム選別処理を終了する。

図１１に戻り、対戦チーム選別処理を行った後、チーム編成部１２６は、ステップＢ１に処理を移行して、ステップＢ１〜Ｂ９の処理を繰り返し実行する。

図４に戻る。ゲーム進行制御部１２８は、ゲーム進行制御プログラム１３９に従って、対戦ネットワークゲームの進行を制御する機能部であり、対戦チーム情報１４９に基づき、チーム編成処理部１２６の対戦チーム選別処理において対戦することが決定されたチーム同士（図１９のステップＦ７）による対戦を行わせる。具体的には、対戦チーム選別処理において決定された各チームに所属するプレーヤのプレーヤ端末２０同士による通信を確立して、対戦ネットワークゲームの実行を開始する。また、対戦ネットワークゲームが終了した場合には勝敗を判別し、それぞれのチームに所属する各プレーヤのプレーヤ管理ＤＢ１４１に登録されているプレイレベル値を所定の基準に基づいて変更する。

表示部１５０は、文字や画像を表示出力する手段であり、処理部１２０から出力された表示信号に基づき表示画面を表示させる。この機能は、例えばＣＲＴ、ＬＣＤ、ＥＬＤ、ＰＤＰ、ＨＭＤ等のハードウェアによって実現される。

通信部１６０は、所定の通信回線（無線通信回線やＬＡＮ等）に接続してゲーム端末２０とのデータ通信を行う。この機能は、無線ＬＡＮ等の無線通信モジュール、モデム、ＴＡ、有線用の通信ケーブルのジャックや制御回路などによって実現される。

記憶部１３０は、処理部１２０にサーバシステム１を統合的に制御させるための諸機能を実現するためのシステムプログラムや、各種処理を実行させるために必要なプログラムやデータ等を記憶する。また、処理部１２０の作業領域として用いられ、処理部１２０が各種プログラムに従って実行した演算結果や操作部１１０から入力される入力データ等を一時的に記憶する。この機能は、例えば各種ＩＣメモリやハードディスク、ＣＤ−ＲＯＭ、ＤＶＤ、ＭＯ、ＲＡＭ、ＶＲＡＭ等によって実現される。

また、記憶部１３０は、処理部１２０をプレーヤ管理部１２４、チーム編成処理部１２６、ゲーム進行制御部１２８として機能させるためのプログラム及びデータを記憶する。具体的には、プログラムとしてプレーヤ管理プログラム１３８、チーム編成処理プログラム１３１、ゲーム進行制御プログラム１３９を記憶する。データとしてプレーヤ管理ＤＢ１４１、マッチング受付情報１４２、チーム候補情報１４４、候補リスト１４５、候補待機リスト１４６、端末設置場所情報１４８、対戦チーム情報１４９を記憶する。

４．ハードウェア構成
次に、図２１を参照して、本実施形態のサーバシステム１を実現するためのハードウェア構成の一例について説明する。図２１に示す装置では、ＣＰＵ１０００、ＲＯＭ１００２、ＲＡＭ１００４、情報記憶媒体１００６、画像生成ＩＣ１０１０、音生成ＩＣ１００８、Ｉ／Ｏポート１０１２，１０１４がシステムバス１０１６により相互にデータ入出力可能に接続されている。Ｉ／Ｏポート１０１２には入力装置１０２２が、Ｉ／Ｏポート１０１４には通信装置１０２４が、それぞれ接続されている。

ＣＰＵ１０００は、情報記憶媒体１００６に格納されるプログラム、ＲＯＭ１００２に格納されるシステムプログラム（装置本体の初期化情報等）、入力装置１０２２によって入力される信号等に従って、装置全体の制御や各種データ処理を行う。

ＲＡＭ１００４は、ＣＰＵ１０００の作業領域等として用いられる記憶手段であり、情報記憶媒体１００６やＲＯＭ１００２内の所与の内容、ＣＰＵ１０００の演算結果等が格納される。

情報記憶媒体１００６は、プログラムや各種データを記憶するものであり、情報記憶媒体として、ＲＯＭ等のメモリやハードディスクや、ＣＤ−ＲＯＭ、ＤＶＤ、磁気ディスク、光ディスク等が用いられる。この情報記憶媒体１００６は、図４に示す記憶部１３０に相当する。

また、この装置に設けられている画像生成ＩＣ１０１０と音生成ＩＣ１００８により、音や画像の好適な出力が行えるようになっている。

画像生成ＩＣ１０１０は、ＣＰＵ１０００の命令によって、ＲＯＭ１００２、ＲＡＭ１００４、情報記憶媒体１００６等から送られる情報に基づいて画素情報を生成する集積回路であり、生成される表示信号は、表示装置１０１８に出力される。表示装置１０１８は、ＣＲＴやＬＣＤ、ＴＶ、プラズマディスプレイ、或いはプロジェクター等により実現され、図４に示す表示部１５０に相当する。

また、音生成ＩＣ１００８は、ＣＰＵ１０００の命令によって、情報記憶媒体１００６やＲＯＭ１００２に格納される情報、ＲＡＭ１００４に格納される音データに応じた音信号を生成する集積回路であり、生成される音信号はスピーカ１０２０によって出力される。

入力装置１０２２は、サーバシステム１を利用する管理者が各種操作を入力するための装置であり、その機能は、キーボード、マウス、タッチパネル等のハードウェアにより実現される。尚、この入力装置１０２２は、図４に示す操作部１１０に相当する。

通信装置１０２４は装置内部で利用される情報を外部とやりとりするものであり、他の装置と通信回線を介して接続されてプログラムに応じた所与の情報を送受すること等に利用される。この通信装置１０２４は、図４に示す通信部１６０に相当する。

５．作用・効果
以上のように、本実施形態のサーバシステム１によれば、チーム全体のプレイレベル値が同程度のチーム同士が対戦するようにマッチング処理が行われることとなる。即ち、プレーヤのプレイレベル値の平均値が同程度のチーム同士で対戦することとなる（図１９のステップＦ３）。従って、対戦するチーム間のレベルが拮抗することとなり、白熱した対戦が期待できる。

また、チームに所属するプレーヤのプレーヤ端末の端末設置場所が考慮されてチームが編成される。即ち、端末設置場所として共通する区域がなるべく狭小な区域となるようにチーム編成がなされる。この結果、地域的に親近感の涌き易いプレーヤ同士でチームが編成されることとなり、互いに未知のプレーヤであっても、比較的結束力が高まり易くなる。具体的には、同じ、「東京」「新宿店」「１Ｆ」のプレーヤ同士でチームが編成されるとした場合、互いに未知のプレーヤではあるが、同じ場所でゲームプレイしているプレーヤが味方であるということで、結束力が高まり易くなる。またゲームプレイが終わった後に、プレーヤ同士が声を掛け合って親しくなる可能性が高い。

また、プレーヤは、マッチングに当たって、編成されるチームに対する自らの希望を条件として設定することができる。具体的には、所属プレーヤのプレイレベル値の分布から定まるチームタイプとして「直列型」や「ピラミッド型」等の希望や、チームにおける自らの地位の希望を設定することができる。

また、希望条件の解除時限を入力することができるため、希望条件を満たすチーム編成がなされるまで待つことのできる限界の待ち時間を設定できる。

また、マッチング依頼の受付時刻からの経過時間の長いプレーヤを含むチーム候補ほど、経過時間係数が高くなり、ひいては優先度指数が高くなる。この結果、マッチング依頼が受け付けられてからの経過時間が長いプレーヤほど、優先的にチーム編成（マッチング）がなされることとなる。

６．変形例
本発明についての好適な実施形態の一例について説明したが、本発明は、上記したものに限らず、発明の趣旨を逸脱しない限りにおいて適宜他の実施形態に適用可能である。以下、変形例について説明する。

６．１．対戦チーム同士のチーム所在地
対戦するチーム同士は、異なるチーム所在地となるようにしてもよい。具体的には、図１９の対戦チーム選別処理のステップＦ３において、抽出するチーム候補として、レベル平均値が第１チームと同程度で且つ、所属プレーヤが全く異なるチーム候補であって、第１チームのチーム所在地と異なるチーム所在地のチーム候補を抽出するようにしてもよい。

この場合、チーム所在地の異なるチーム同士の対戦となるため、対戦ゲームがいわば地域対抗戦の様相を呈することとなり、一層白熱したゲームとなることが期待できる。図２０のチーム決定通知画面に示されるように、チーム所在地は自チームのチーム所在地のみならず、相手チームのチーム所在地も表示される。このため、例えば、「新宿店」ｖｓ「渋谷店」といった対戦や、「東京」ｖｓ「大阪」といった対戦が組まれることとなる。

６．２．チーム所在地が必ず有るチームの編成
図１６を参照して説明した通り、チーム所在地の無いチーム候補には所在地係数として最低の値が設定されるだけであるため、編成されるチームとしてチーム所在地が無い場合があり得る。そこで、図１２のチーム候補追加更新処理のステップＣ１において、少なくとも最大の区域である「地域」が共通するプレーヤからなるチーム候補の組合せを算出することとして、チーム所在地が必ず有るチームを編成することとしてもよい。

またこのとき、チーム所在地の条件（同地域条件）として、プレーヤが「東京」や「新宿店」といった条件を入力可能として、この条件を満たすチームのみを編成するようにしてもよい。

６．３．希望条件
全てのプレーヤの希望条件が満たされたチームのみを編成するようにしてもよい。具体的には、解除期限として入力できる時間に「無期限」の選択肢を追加して、希望条件を満たすチームが編成されるまで待てるようにしてもよい。

６．４．システム構成
本実施形態のゲームシステム５として、店舗及びフロアを単位とするシステム構成としたが、本発明の適用が可能なシステム構成はこれに限られるものではない。例えば、各家庭に設置されたＰＣ（パーソナル・コンピュータ）や家庭用ゲーム装置をプレーヤ端末２０として構成してもよい。この場合、サーバシステム１に、予め各プレーヤ端末の設置場所を登録しておけばよい。「地域」「店舗」「フロア」といった区域の代わりに、例えば「地方」「都道府県」「市区町村」といった区域を設置場所として登録する。

６．５．他のゲームへの適用
本実施形態のゲームをガンシューティング型のゲームとして説明したが、適用可能なゲームはこれに限られない。例えば、野球やサッカー等のチーム戦を行うスポーツゲーム等にも適用可能である。

プレーヤ端末の設置状況の一例を示す図。 ゲームシステムの概略構成を示す図。 （ａ）はゲーム空間のマップを示す図。（ｂ）はゲーム画面の一例を示す図。 サーバシステムの機能ブロック図。 端末設置場所情報の構成例を示す図。 プレーヤ管理処理のフローチャート。 プレーヤ管理ＤＢの構成例を示す図。 マッチング受付情報の構成例を示す図。 プレーヤ端末に表示される希望条件入力画面の一例を示す図。 チームタイプと地位との選択肢の構成を示す図。 チーム編成処理のフローチャート。 チーム候補追加処理のフローチャート。 チーム候補情報の構成例を示す図。 解除時間経過時処理のフローチャート。 優先度指数算出処理のフローチャート。 端末設置場所と所在地係数との対応関係の一例を示す図。 最長経過時間と経過時間係数との対応関係の一例を示す図。 希望条件を満足するプレーヤの数と満足度係数との対応関係の一例を示す図。 対戦チーム選別処理のフローチャート。 対戦チーム決定通知画面例を示す図。 ハードウェア構成の一例を示す図。

符号の説明

５ ゲームシステム
１ サーバシステム
１１０ 操作部
１２０ 処理部
１２４ プレーヤ管理部
１２６ チーム編成処理部
１２８ ゲーム進行制御部
１３０ 記憶部
１３１ チーム編成処理プログラム
１３８ プレーヤ管理プログラム
１３９ ゲーム進行制御プログラム
１４１ プレーヤ管理ＤＢ
１４２ マッチング受付情報
１４４ チーム候補情報
１４５ 候補リスト
１４６ 候補待機リスト
１４８ 端末設置場所情報
１４９ 対戦チーム情報
１５０ 表示部
１６０ 通信部
２０ プレーヤ端末

Claims (13)

1. 複数のプレーヤ端末と通信接続され、プレーヤ同士で構成される各対戦チームを編成する対戦ネットワークゲーム用のサーバシステムであって、
   ゲーム結果に応じて可変されるプレーヤ毎のプレイレベル値を記憶するプレイレベル値記憶手段と、
   前記プレーヤ端末からマッチング依頼を受け付ける依頼受付手段と、
   前記記憶されているプレイレベル値に基づいて、前記依頼受付手段により受け付けられたプレーヤのうち、対戦チームそれぞれのチーム全体のプレイレベル値が所定の同程度条件を満たすプレーヤ構成でなるチームを編成するチーム編成手段と、
   を備えたサーバシステム。
2. 前記対戦ネットワークゲームは、ゲーム中、所定のコミュニケーション方法により同一チームのプレーヤ端末間でコミュニケーションが可能なゲームであり、
   前記プレーヤ端末それぞれの所在地情報を記憶する所在地記憶手段を更に備え、
   前記チーム編成手段は、前記所在地記憶手段の記憶内容を参照して、前記依頼受付手段によってマッチング依頼の受け付けられたプレーヤ端末のうち、所定の同地域条件を満足するプレーヤ端末のプレーヤ同士で１つのチームを編成する同地域チーム編成手段を有する、
   ことを特徴とする請求項１に記載のサーバシステム。
3. 階層的な広狭の所在区域が予め定められており、
   前記同地域チーム編成手段は、より狭小な所在区域を優先して、同一の所在区域内のプレーヤ端末のプレーヤ同士で１つのチームを編成することを特徴とする請求項２に記載のサーバシステム。
4. 前記同地域チーム編成手段は、対戦するチームのプレーヤ端末の所在地が異なる所在区域となるように対戦する相互のチームを編成することを特徴とする請求項３に記載のサーバシステム。
5. 前記依頼受付手段による受け付けたプレーヤ端末それぞれの受付時刻を記憶する受付時刻記憶手段を更に備え、
   前記チーム編成手段は、前記受付時刻記憶手段に記憶された受付時刻がより古いプレーヤ端末を優先して、チームを編成する受付経過時間優先編成手段を有する、
   ことを特徴とする請求項１〜４の何れか一項に記載のサーバシステム。
6. 前記依頼受付手段は、味方チームに属する味方プレーヤの前記プレイレベル値のレベル分布の希望を受け付けるレベル分布希望受付手段を有し、
   前記チーム編成手段は、同一チームに属するプレーヤそれぞれの前記レベル分布希望受付手段により受け付けられた希望レベル分布を満たすようにチームを編成する希望レベル分布基準編成手段を有する、
   ことを特徴とする請求項１〜５の何れか一項に記載のサーバシステム。
7. 前記依頼受付手段は、前記プレイレベル値に関する味方チーム内の他の味方プレーヤとの相対レベルの希望を受け付けるチーム内相対レベル希望受付手段を有し、
   前記チーム編成手段は、同一チームに属するプレーヤそれぞれの前記チーム内相対レベル布希望受付手段により受け付けられた希望相対レベルを満たすようにチームを編成する希望相対レベル基準編成手段を有する、
   ことを特徴とする請求項１〜６の何れか一項に記載のサーバシステム。
8. 複数のプレーヤ端末と通信接続され、プレーヤ同士で構成される各対戦チームを編成する対戦ネットワークゲーム用のサーバシステムであって、
   ゲーム結果に応じて可変されるプレーヤ毎のプレイレベル値を記憶するプレイレベル値記憶手段と、
   前記プレーヤの組合せでなるチーム候補を算出する候補算出手段と、
   前記算出されたチーム候補それぞれのチーム全体のプレイレベル値を算出するチームレベル値算出手段と、
   前記チームレベル値算出手段により算出されたプレイレベル値が所定の同程度条件を満たすチーム候補同士を対戦する相互のチームとして決定する対戦チーム決定手段と、
   を備えたサーバシステム。
9. 前記算出されたチーム候補それぞれの優先度指数を算出する優先度指数算出手段を更に備え、
   前記対戦チーム決定手段は、前記算出された優先度指数の高いチーム候補を優先して対戦チームとする優先決定手段を有する、
   ことを特徴とする請求項８に記載のサーバシステム。
10. 前記プレーヤ端末それぞれの所在地情報を記憶する所在地記憶手段を更に備え、
    前記優先度指数算出手段は、前記所在地記憶手段の記憶内容を参照して、所定の同地域条件を満足するプレーヤ端末のプレーヤ同士でなるチーム候補の優先度指数を、同地域条件を満たさないチーム候補より高く算出する、
    ことを特徴とする請求項９に記載のサーバシステム。
11. 複数のプレーヤ端末と通信接続される対戦ネットワークゲーム用のサーバシステムにプレーヤ同士で構成される各対戦チームを編成させるためのプログラムであって、
    ゲーム結果に応じて可変されるプレーヤ毎のプレイレベル値を記憶するプレイレベル値記憶手段、
    前記プレーヤ端末からマッチング依頼を受け付ける依頼受付手段、
    前記記憶されているプレイレベル値に基づいて、前記依頼受付手段により受け付けられたプレーヤのうち、対戦チームそれぞれのチーム全体のプレイレベル値が所定の同程度条件を満たすプレーヤ構成でなるチームを編成するチーム編成手段、
    として前記サーバシステムを機能させるためのプログラム。
12. 複数のプレーヤ端末と通信接続される対戦ネットワークゲーム用のサーバシステムに、プレーヤ同士で構成される各対戦チームを編成させるためのプログラムであって、
    ゲーム結果に応じて可変されるプレーヤ毎のプレイレベル値を記憶するプレイレベル値記憶手段、
    前記プレーヤの組合せでなるチーム候補を算出する候補算出手段、
    前記算出されたチーム候補それぞれのチーム全体のプレイレベル値を算出するチームレベル値算出手段、
    前記チームレベル値算出手段により算出されたプレイレベル値が所定の同程度条件を満たすチーム候補同士を対戦する相互のチームとして決定する対戦チーム決定手段、
    として前記サーバシステムを機能させるためのプログラム。
13. 請求項１１又は１２に記載のプログラムを記憶したコンピュータ読取可能な情報記憶媒体。

Images