JP2016131662A - プログラム及びゲームシステム - Google Patents

Abstract

【課題】チーム対戦型のマルチプレイゲームにおいて戦況の理解を助ける技術を提供すること。
【解決手段】ゲーム空間内のプレーヤキャラクタから、１）ロックオンしているキャラクタとされているキャラクタと、２）それらの近場にいるそれぞれの味方キャラクタと、３）近場にいたそれぞれの味方キャラクタを更にロックオンしているキャラクタと、を登録した接敵グループを検出する。つまり、直に戦闘しているキャラクタのみならずその周辺のキャラクタも含め、１つの戦域と見なせる範囲に展開したキャラクタ群としての接敵グループを検出する。マップ画面Ｗ４において、接敵グループの位置を位置報知体３８で表示する。位置報知体３８の表示形態は、当該接敵グループにおけるチーム間のキャラクタ数の多寡を表す。
【選択図】図８

Description

本発明は、第１チームに所属する複数の第１キャラクタと、第２チームに所属する複数の第２キャラクタとが仮想空間を移動して対戦するゲームをコンピュータシステムに実行させるためのプログラム等に関する。

ビデオゲームでは、ゲーム空間内におけるプレーヤ自身が操作するプレーヤキャラクタと、他プレーヤ（コンピュータを含む）が操作する他キャラクタとの相対位置関係に関する情報提供は、重要な要素となっている。プレーヤキャラクタを中心にして周囲に存在する他キャラクタの配置を簡易なシンボルで表示する所謂「レーダ画面」「マップ画面」や、プレーヤの視界内（ゲーム画面内）に、視界外に存在する攻撃目標とする他キャラクタの方角を示す矢印を表示するなどがこれに該当する。

例えば、プレーヤキャラクタを中心とした複数の同心円構造でレーダ画面を表現し、検知された他キャラクタの存在する方向と相対距離を分かり易く表示する技術が特許文献１に開示されている。

特開２００４−１５４４４９公報

さて、チーム対戦型のマルチプレイゲームにおいて勝利するためには、プレーヤ各々の戦況に応じた臨機応変な行動が必要とされる。前線位置と敵味方の多寡とを速やかに判断し、味方が不利な前線には増援として駆けつけるのはその最たるものである。ゲームに習熟した上級プレーヤは、当たり前のように身につけたこうした行動も、初級者プレーヤにとっては難しい。

本発明は、こうした事情を鑑みて成されたものであり、チーム対戦型のマルチプレイゲームにおいて、戦況の理解を助ける技術を提供することを目的とする。

上述した課題を解決するための第１の発明は、第１チームに所属する複数の第１キャラクタ（例えば、図３のチーム「ＲＥＤ」のプレーヤキャラクタ４ａ，４ｂ，…）と、第２チームに所属する複数の第２キャラクタ（例えば、図３のチーム「ＢＬＵＥ」のプレーヤキャラクタ４ｆ，４ｇ，…）とが仮想空間を移動して対戦するゲームをコンピュータシステムに実行させるためのプログラムであって、
前記第１キャラクタ及び前記第２キャラクタが、接敵しているキャラクタのグループの条件である接敵グループ条件を満たす場合に、当該接敵グループ条件を満たす前記第１キャラクタ及び前記第２キャラクタを接敵グループとして検出する接敵グループ検出手段（例えば、図１０のサーバ処理部２００ｓ、接敵グループ検出部２２０、図１７のステップＳ５０）、
前記接敵グループ検出手段の検出に応じた報知を行う報知制御手段（例えば、図１０のサーバ処理部２００ｓ、報知制御部２４０、図１７のステップＳ１３０）、
として前記コンピュータシステムを機能させるためのプログラムである。

第１の発明によれば、接敵しているキャラクタのグループを検出して、プレーヤへ報知することで、プレーヤが戦況を理解するのをサポートできる。

第２の発明は、前記接敵グループ条件には、対敵した状況にあることを示す所与の対敵状況条件が少なくとも含まれ、前記接敵グループ検出手段が、前記第１キャラクタ及び前記第２キャラクタのうちの一方が他方に対して前記対敵状況条件を満たす関係にある当該第１キャラクタ及び当該第２キャラクタを前記接敵グループに含めて検出する、第１の発明のプログラムである。

第３の発明は、前記対敵状況条件には、対敵した状況の距離条件である所与の対敵距離条件が少なくとも含まれる、第２の発明のプログラムである。

第４の発明は、前記接敵グループ検出手段が、前記接敵グループ条件を満たす関係にある当該第１キャラクタ及び当該第２キャラクタにとって近場条件を満たす同一チームのキャラクタを前記接敵グループに含めて検出する、第１〜第３の発明のプログラムである。

第５の発明は、前記接敵グループ検出手段が、近場条件（例えば、図５の近場範囲２４）を満たす前記第１キャラクタをグループとした１体以上の前記第１キャラクタのグループである第１チーム近場グループのうちの何れかの前記第１キャラクタと、近場条件を満たす前記第２キャラクタをグループとした１体以上の前記第２キャラクタのグループである第２チーム近場グループのうちの何れかの前記第２キャラクタとの間が所与の対敵状況条件を満たす関係にある第１チーム近場グループおよび第２チーム近場グループをまとめて前記接敵グループとして検出する、第１の発明のプログラムである。

第２〜第５の発明によれば、対敵しているキャラクタが接敵グループとして検出されたり、対敵しているキャラクタが属しているチームの近場グループごと接敵グループとして検出するといったことができる。換言すれば、今まさに銃で狙い撃ち合っているキャラクタや、当該キャラクタの近場に位置する味方も接敵グループに含めて検出することができる。

第６の発明は、前記接敵グループ検出手段が、Ｎ個の前記第１チーム近場グループとＭ個の前記第２チーム近場グループとにおいて（Ｎ≧１，Ｍ≧１，かつＮ＋Ｍ≧３）、前記対敵状況条件を満たす関係にあるキャラクタ同士がグループ間で連鎖するように存在する場合に、当該Ｎ個の前記第１チーム近場グループと当該Ｍ個の前記第２チーム近場グループとをまとめて１つの接敵グループとして検出する、第５の発明のプログラムである。

第６の発明によれば、対敵状況条件を満たす近場グループ（或いはキャラクタともいえる）をいわば芋づる式に検出して同じ接敵グループとして扱う事が可能になる。

第７の発明は、前記報知制御手段が、前記接敵グループに含まれる各チームのキャラクタの相対的な多寡に応じた報知を行う多寡別報知制御手段（例えば、図１０のサーバ処理部２００ｓ、報知制御部２４０、多寡別報知制御部２４２、図２１のステップＳ１３６）を有する、第１〜第６の何れかの発明のプログラムである。

第７の発明によれば、接敵グループにおける味方と敵との数的な有利／不利の状況に関する情報をプレーヤに提供することができる。よって、プレーヤは、戦況をより正しく理解できるようになる。

第８の発明は、前記報知制御手段が、前記接敵グループに含まれる前記第１キャラクタ及び／又は前記第２キャラクタの位置を報知する位置報知制御手段（例えば、図８の位置報知体３８、図１０のサーバ処理部２００ｓ、位置報知制御部２４６、図２１のステップＳ１３８、Ｓ１４６）を有する、第１〜第７の何れかの発明のプログラムである。

第８の発明によれば、接敵している敵／味方のキャラクタの位置をプレーヤに報知することができる。

第９の発明は、前記接敵グループ検出手段が、従前に当該接敵グループに含まれており、且つ、所与の継続条件を満たすキャラクタを、継続して当該接敵グループに含めて検出する（例えば、図２０のステップＳ１０８〜Ｓ１１０）、第１〜第８の何れかの発明のプログラムである。

第９の発明によれば、接敵グループから除外される条件（例えば、戦闘離脱、前線離脱と判断される条件）を、接敵グループを検知するときよりも緩和し、継続して接敵グループに含めて検出することができる。例えば一時的に敵の背後や側面に回り込もうとして対敵状況条件を満たさなくなったキャラクタであっても即座に接敵グループから除外するのではなく継続して接敵グループに含めておくことができる。よって、プレーヤは、戦況をより適切に理解できるようになる。

第１０の発明は、第１チームに所属する複数の第１キャラクタと、第２チームに所属する複数の第２キャラクタとが仮想空間を移動して対戦するゲームを実行するゲームシステムであって、前記第１キャラクタ及び前記第２キャラクタが、接敵しているキャラクタのグループの条件である接敵グループ条件を満たす場合に、当該接敵グループ条件を満たす前記第１キャラクタ及び前記第２キャラクタを接敵グループとして検出する接敵グループ検出手段（例えば、図１のサーバシステム１１００、制御基板１１５０、図１０のサーバ処理部２００ｓ、接敵グループ検出部２２０、図１７のステップＳ５０）と、前記接敵グループ検出手段の検出に応じた報知を行う報知制御手段（例えば、図１のサーバシステム１１００、制御基板１１５０、図１０のサーバ処理部２００ｓ、報知制御部２４０、図１７のステップＳ１３０）と、を備えたゲームシステムである。

第１０の発明によれば、第１の発明と同様の効果が得られる。

ゲームシステムの構成の一例を示す図。 業務用ゲーム装置の構成例を示す正面外観図。 ゲームについて説明する図。 ゲーム空間の一部を俯瞰して各キャラクタの位置関係例を簡略表記した図。 接敵グループの検出原理について説明する図。 接敵グループの管理について説明するための図。 接敵グループに関する情報報知例を示す図。 マップ表示における接敵グループの位置報知の例を示す図。 業務用ゲーム装置の機能構成例を示す機能ブロック図。 サーバシステムの機能構成例を示す機能ブロック図。 サーバ記憶部が記憶するプログラムやデータの例を示す図。 ゲーム初期設定データのデータ構成例を示す図。 プレイデータのデータ構成例を示す図。 キャラクタ別ステータスデータのデータ構成例を示す図。 キャラクタ別行動ログのデータ構成例を示す図。 サーバシステムにて実行される主たる処理の流れを説明するためのフローチャート。 図１６よりつづくフローチャート。 接敵グループ検知処理の流れを説明するためのフローチャート。 図１８よりつづくフローチャート。 接敵グループ管理処理の流れを説明するためのフローチャート。 接敵グループ報知処理の流れを説明するためのフローチャート。 ゲームシステムの機能構成の変形例を示す図。 位置報知体の変形例を示す図。 マップ表示の変形例を示す図。

〔第１実施形態〕
本発明を適用した第１実施形態として、チーム対戦型のマルチプレイゲームを実行する例を説明する。

図１は、本実施形態におけるゲームシステムの構成の一例を示す図である。本実施形態のゲームシステムは、クライアントサーバ型システムである。すなわち、それぞれ通信回線９に接続することのできるサーバシステム１１００と、プレーヤがゲームプレイするために使用する複数の業務用ゲーム装置１３００と、ゲームプレイ画面やリプレイ映像の表示、ユーザ登録などを行うためのターミナル装置１３９０とを含む。

通信回線９は、データ通信が可能な通信路を意味する。すなわち、通信回線９とは、直接接続のための専用線（専用ケーブル）やイーサネット（登録商標）等によるＬＡＮ（Local Area Network）の他、電話通信網やケーブル網、インターネット等の通信網を含む意味であり、また、通信方法については有線／無線を問わない。

サーバシステム１１００は、例えば、本体装置１１０１と、キーボード１１０６と、タッチパネル１１０８と、ストレージ１１４０とを備える。本体装置１１０１には制御基板１１５０が搭載されている。この制御基板１１５０には、ＣＰＵ（Central Processing Unit）１１５１やＧＰＵ（Graphics Processing Unit）、ＤＳＰ（Digital Signal Processor）などの各種マイクロプロセッサ、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field-Programmable Gate Array）、ＶＲＡＭやＲＡＭ，ＲＯＭ等の各種ＩＣメモリ１１５２、通信装置１１５３が搭載されている。

そして、サーバシステム１１００は、制御基板１１５０で所定のプログラム及びデータに基づいて演算処理することにより、１）固有のアカウントを付与するとともに電子決済用の決済口座を開設するユーザ登録機能と、２）決済口座への入金や、プレイ対価やアイテム課金等に対する決済口座からの課金精算などを行う電子決済機能と、３）業務用ゲーム装置１３００から操作入力情報を取得し、業務用ゲーム装置１３００へゲームを実行するのに必要なプログラムやデータを提供するゲーム管理機能と、を実現する。

なお、図１の例では、サーバシステム１１００は単体として記しているが、これらの各種機能を分担する複数のブレードサーバを搭載して、相互に内部バスを介してデータ通信可能に接続した構成であっても良い。或いは、離れた場所に設置された独立した複数のサーバを、通信回線を介してデータ通信させることで、全体としてサーバシステム１１００として機能させる構成であっても良い。

図２は、業務用ゲーム装置１３００の構成例を示す正面図である。
業務用ゲーム装置１３００は、通信回線９に接続してサーバシステム１１００にアクセスすることができるコンピュータシステムであり電子装置（電子機器）である。業務用ゲーム装置１３００は、ゲームセンターなどの店舗に設置されており、電子決済用媒体６を用いてプレイ対価の支払いを電子決済できる。

電子決済用媒体６は、仮想通貨（電子マネー：有価情報）による電子決済システムを利用するためのキーデータを記憶する。当該キーデータは、専用の読取装置を用いることで読み取り可能とされる。電子決済用媒体６は情報をコンピュータ読み取り可能に記憶する媒体であれば何れでもよく、本実施形態ではＩＣカードのような専用の媒体とするが、スマートフォンのような装置であってもよい。本実施形態の業務用ゲーム装置１３００は、電子決済用媒体６を用いた電子決済に対応しており、電子決済用媒体６から情報を読み取る装置として媒体読取装置１３４４を有している。すなわち、業務用ゲーム装置１３００は対価支払装置として機能する。

キーデータとしては、例えば、ユーザ登録時に設定される固有のアカウントや、固有の媒体ＩＤ（例えば、ＩＣカードならばカードＩＤ、スマートフォンなどの情報機器ならばＭＡＣアドレスやＳＩＭカードＩＤなどの機器固有の情報）などを適宜設定することができる。

本実施形態では、サーバシステム１１００が提供する所定のユーザ登録手続きを経て固有のアカウントを登録すると、当該アカウントに関連づけられる決済口座が開設され、別途入手した電子決済用媒体６の固有の媒体ＩＤをアカウントと関連付けて登録することができる。電子決済用媒体６を登録することで、あたかもプリペイドカードの如く、電子決済用媒体６を、プレイ対価の支払いや、ゲーム内で使用できるアイテム等の購入などの課金精算に使用できるようになる。

本実施形態における業務用ゲーム装置１３００は、ジョイスティック１３０２と、ボタンスイッチ１３０４と、画像表示デバイス兼接触位置入力デバイスとして機能するタッチパネル１３０６と、スピーカ１３１０と、入金装置１３３０と、電子決済用媒体６からデータの読み取りや書き込みができる媒体読取装置１３４４と、制御基板１３５０と、を備える。

制御基板１３５０には、ＣＰＵ１３５１や、ＧＰＵ，ＤＳＰなどの各種マイクロプロセッサ、ＶＲＡＭ，ＲＡＭ，ＲＯＭ等の各種ＩＣメモリ１３５２と、通信回線９に通信接続するための通信装置モジュール１３５３、Ｉ／Ｆコントローラ１３５７（インターフェイスコントローラ）などが搭載されている。

Ｉ／Ｆコントローラ１３５７には、例えば、１）タッチパネル１３０６のドライバ回路、２）ジョイスティック１３０２及びボタンスイッチ１３０４からの信号を受信する回路、３）スピーカ１３１０へ音声信号を出力する出力アンプ回路、４）入金装置１３３０や媒体読取装置１３４４への信号入出力回路、などが搭載されている。

そして、これら制御基板１３５０に搭載されている各要素は、それぞれバス回路などを介して電気的に接続され、データの読み書きや信号の送受信が可能に接続されている。なお、制御基板１３５０の一部または全部をＡＳＩＣやＦＰＧＡにて実現する構成でもよい。

入金装置１３３０は、従来の業務用ゲーム装置１３００と同様に、５０円や、１００円、５００円などの硬貨のうち特定種類の硬貨での入金を受け付ける装置である。

制御基板１３５０は、ゲームプログラムを実行して演算処理を実行し、ジョイスティック１３０２やボタンスイッチ１３０４，タッチパネル１３０６からの操作入力に応じて業務用ゲーム装置１３００の各部を制御してゲームプレイを可能にする。本実施形態の業務用ゲーム装置１３００は、必要なプログラムや各種設定データを予めＩＣメモリ１３５２に記憶しているものとするが、起動の都度、サーバシステム１１００からダウンロードする構成としても良い。

制御基板１３５０の制御により、業務用ゲーム装置１３００は、ジョイスティック１３０２やタッチパネル１３０６などを介した操作入力の結果をサーバシステム１１００へ逐次送信する一方で、ゲームをプレイするための各種データをサーバシステム１１００から受信する。そして、ゲーム画面の画像を生成してタッチパネル１３０６に表示させ、効果音や操作音の音信号を生成してスピーカ１３１０から放音する。つまり、プレーヤはタッチパネル１３０６に表示されるゲーム画面を見て、スピーカ１３１０から流れるゲーム音を聞きながら、ジョイスティック１３０２等を操作してゲームプレイを楽しむことができる。

なお、入金装置１３３０や媒体読取装置１３４４は筐体１３０１と一体の構成に限らず、外付けで通信接続可能な構成としてもよい。例えば、図１に示すように、業務用ゲーム装置１３００と通信接続されたターミナル装置１３９０に、入金装置１３３０や媒体読取装置１３４４を設ける。そして、このターミナル装置１３９０にて、ゲーム参加登録手続きとして、使用する業務用ゲーム装置１３００の指定と、プレイ対価の支払いとを行う構成としてもよい。

なお、業務用ゲーム装置１３００は、家庭用据置型ゲーム装置や、携帯型ゲーム装置、ゲームアプリケーションを実行できるスマートフォン、パソコン、タブレット型コンピュータ、ウェアラブルコンピュータなどの情報機器に置き換えることができる。勿論、その場合、装置の設定場所や使用場所はゲームセンターなどの店舗に限らない。

図３は、本実施形態のゲームについて説明する図である。
本実施形態のゲームは、チーム対戦型オンラインマルチプレイゲームである。各プレーヤは、各々業務用ゲーム装置１３００を使用し、自身が使用するプレーヤキャラクタ４ａ，４ｂ，…を各１体選択し複数のチームに分かれる。本実施形態はチーム「ＲＥＤ」とチーム「ＢＬＵＥ」の２チームの対戦形式としているが、３チーム以上のチームが一斉にゲームに参加する構成としてもよい。チームを構成する人数も適宜設定可能である。また、１プレーヤが操作するプレーヤキャラクタ４の数は複数でもよい。なお、以下、プレーヤキャラクタ４ａ，４ｂ，…を区別しない場合は包括して「プレーヤキャラクタ４」と称する。

仮想３次元空間に構成されたゲーム空間（この場合、戦場）が用意される。ゲーム空間に様々な障害物７が配置され、更に破壊可能なチーム別の拠点８ｒ、８ｂが用意される。そして、ゲーム空間には、各プレーヤキャラクタ４のキャラクタモデルが配置され、それぞれのプレーヤの操作入力に応じて移動・攻撃・防御の行動をするように制御される。また、図示されていないが、プレーヤキャラクタ４それぞれに専用の仮想カメラが用意されており、つねに対応するプレーヤキャラクタ４を撮影するように制御される。

各仮想カメラで撮影されたゲーム空間画像はレンダリングされ、幾つかの情報表示が合成されてゲーム画面を構成する。そして、ゲーム画面は、対応するプレーヤキャラクタ４への操作入力がなされている業務用ゲーム装置１３００のゲーム画面として表示される。

銃撃戦で被弾したプレーヤキャラクタ４は、被弾に応じたダメージが耐久値から減算され、残耐久値が「０」になると行動不能すなわち撃破されたものとされる。各チームは各々の拠点８ｒ，６ｂから出撃して、障害物７を盾にして銃撃戦を展開する。他チームを全滅させるか、他チームの拠点を破壊すると勝利となる。

さて、本実施形態では、他チームのプレーヤキャラクタ４を攻撃するには、１）敵を認識し、２）攻撃可能範囲に捕らえて、３）攻撃目標として選択し、４）攻撃行動を始める、４ステップを経る。

図４は、ゲーム空間の一部を俯瞰して各キャラクタの位置関係例を簡略表記した図である。各プレーヤキャラクタ４（４ａ，４ｂ，…）には、それぞれのキャラクタ種類に応じた索敵能力（他キャラクタの存在を検知し敵味方を識別する能力）が備えられている。索敵能力が及ぶ範囲を索敵範囲２０と称する。図４の例では、代表して、プレーヤキャラクタ４ａについてのみ索敵範囲２０を表記している。

索敵範囲２０に、プレーヤキャラクタ４ａにとって他チームのプレーヤキャラクタ４（以降、理解し易いように他チームのプレーヤキャラクタを「敵キャラクタ」と称する）が位置すれば、プレーヤキャラクタ４ａはレーダで敵キャラクタを検知したものとされる。図４の例では、プレーヤキャラクタ４ａは、他チームのプレーヤキャラクタ４ｆを敵キャラクタとして検知している。

索敵範囲２０にて検知されている敵キャラクタのうち、更に所持する武器の射程範囲２２に入っている敵キャラクタが攻撃対象候補となる。図４の例では、他チームのプレーヤキャラクタ４ｆ（敵キャラクタ１０ｆ）がプレーヤキャラクタ４ａの攻撃対象候補となっている。

そして、プレーヤが攻撃対象候補のうち一体又は複数体を攻撃目標として選択操作すると、以降は選択された敵キャラクタが攻撃目標として自動追尾される。これを「ロックオン」と称する。図４の例では、プレーヤキャラクタ４ａが、他チームのプレーヤキャラクタ４ｆ（敵キャラクタ１０ｆ）をロックオンしている。

ロックオンした敵キャラクタがあってプレーヤが所定の攻撃操作を入力すると、プレーヤキャラクタ４はロックオンした敵キャラクタに対して攻撃行動をとる。本実施形態では射撃する。図４の例では、プレーヤキャラクタ４ａが、他チームのプレーヤキャラクタ４ｆ（敵キャラクタ１０ｆ）を射撃する。

なお、ロックオンの仕様はゲーム内容によっては省略することもできる。また、ロックオンした敵キャラクタ１０へは自動照準されるとしても良いし、自動照準はせずに別途プレーヤによる手動照準操作を要する構成としてもよい。

本実施形態では、索敵と攻撃対象候補の認識は自動で行われるので、プレーヤは自分が操作するプレーヤキャラクタ４を適当な場所に移動させ、攻撃対象候補の中からロックオンの対象を選択し、攻撃操作入力をすれば、他チームのプレーヤキャラクタ４を攻撃することができる。なお、拠点８ｒ、８ｆもプレーヤキャラクタ４と同様にして攻撃することができる。

［接敵の説明］
さて、本実施形態では、射程範囲２２に１体以上の敵キャラクタ１０を捕らえ、その何れかをロックオン（選敵）しているプレーヤキャラクタ４は、「対敵状況条件」を満たしており、前線で敵キャラクタと「接敵」していると見なされる。なお、対敵状況条件は、ロックオンに限らずゲーム内容に応じて適宜設定可能である。例えば、ロックオンが手動操作で行われる構成であれば、射程範囲２２に敵キャラクタ１０を捕らえている段階で対敵状況条件を満たすと判定してもよい。更に言えば、索敵範囲２０に敵キャラクタ１０を検知した段階で対敵状況条件を満たすと判定してもよい。

接敵関係の最小構成は、ロックオンしているプレーヤキャラクタ４と、ロックオンされているプレーヤキャラクタ４とで構成される。図４の例では、プレーヤキャラクタ４ａと、他チームのプレーヤキャラクタ４ｆ（敵キャラクタ１０ｆ）とが最小構成の接敵関係を構成する。

こうした接敵関係のゲーム空間における位置関係と規模は、戦況を理解し、勝利のために速やかな行動をするうえで極めて重要である。そこで、本実施形態ではプレーヤに向けて接敵関係をなしているプレーヤキャラクタ４に関する情報を提供する。但し、情報提供にあたって最小構成の接敵関係を個別に扱うと、却って提供する情報が増えて初心者には理解し難くなる恐れがある。また、上級者であれば、最小構成の接敵関係の近傍にいる味方が駆けつけて援護する可能性を考慮に入れて戦況を判断することができるが、初心者にはそうした熟練の判断が難しい。
そこで、本実施形態では、隣接する接敵関係同士や、駆けつけ可能なプレーヤキャラクタ４の存在を考慮して、概況として１つの交戦域とみなせる範囲内のキャラクタ群を纏めて「接敵グループ」と見なし、接敵グループに関する情報をプレーヤへ提供する。

図５は、本実施形態における接敵グループの検出原理について説明する図である。
概況として１つの交戦域とみなせる範囲内に位置するキャラクタ群の接敵グループは、１）行動可能なプレーヤキャラクタ４別に着目して、対敵状況条件を満たすキャラクタの組合せ、すなわち最小構成の接敵関係を成すキャラクタの組み合せを見つけて始原となる接敵グループを作成し、２）当該接敵グループを構成するプレーヤキャラクタ４それぞれの周囲にいる当該プレーヤキャラクタ４にとっての味方を当該接敵グループに加え、３）当該接敵グループに加えられたプレーヤキャラクタ４と更に対敵状況条件を満たすプレーヤキャラクタ４を当該接敵グループに加え、４）以下、新たなキャラクタの追加がなくなるまで上記２）と上記３）と繰り返す、ことにより検出する。

換言すると、「（条件Ａ）：対敵状況条件を満たす敵対するキャラクタ同士であること」「（条件Ｂ）：条件Ａを満たすキャラクタにとって味方であり且つ近場にいるキャラクタであること」「（条件Ｃ）：条件Ｂを満たすキャラクタが条件Ａを満たす場合に連鎖しているとして同グループにまとめること」を本実施形態では「接敵グループ条件」として、当該接敵グループ条件を満たすプレーヤキャラクタ４を接敵グループとして検出する。

具体的には、図５において、行動可能なプレーヤキャラクタ４として、例えばチーム「ＲＥＤ」のプレーヤキャラクタ４ａに着目すると、その索敵範囲２０（他キャラクタ認識可能範囲）の内に敵キャラクタ１０ｆが存在し、プレーヤが当該敵キャラクタ１０ｆを攻撃目標として選択してロックオンしている。よって、プレーヤキャラクタ４ａと敵キャラクタ１０ｆとは対敵状況条件を満たす（条件Ａ）ため、始原の接敵グループ１６が作成される（図中、丸囲み数字「１」）。この段階の接敵グループ１６は、接敵グループとしては最小構成である。

次に、始原の接敵グループ１６を構成するキャラクタそれぞれの近傍に位置する当該キャラクタにとっての味方を当該接敵グループに加える（条件Ｂの判断）。
具体的には、各プレーヤキャラクタ４（４ａ，４ｂ，…）には、近場条件である近場範囲２４が設定されている。当該範囲は、言うならばいつでも支援に駆けつけられるチームメイトを判定するための近場条件である。近場範囲２４の距離条件は索敵範囲２０より短い距離とすると好適であり、例えば、索敵範囲２０を「３００ｍ」とすれば近場範囲２４は「１００ｍ程度」とすると好適である。そして、接敵グループを構成するプレーヤキャラクタ４の近場範囲２４内に味方が存在すると、その味方を同じ「接敵グループ」に属するとみなす。

図５の例において、先ず始原の接敵グループ１６のプレーヤキャラクタ４ａに着目すると、プレーヤキャラクタ４ａの近場範囲２４には同チームのプレーヤキャラクタ４ｂが存在するため、当該キャラクタ４ｂをプレーヤキャラクタ４ａと同じ接敵グループ１６に追加登録する（図中、丸囲み数字「２」）。プレーヤキャラクタ４ｂが条件Ｂを満足するとして追加登録される。

一方、始原の接敵グループ１６のうちの敵キャラクタ１０ｆの近場範囲２４には同チームの敵キャラクタが存在しないので、敵キャラクタ１０ｆの近場にいる味方として同じ接敵グループ１６に追加登録される敵キャラクタは無い。したがって、この段階では、接敵グループ１６に所属するキャラクタは３体となる。

次に条件Ｃを判断する。条件Ｂを満足するプレーヤキャラクタ４ｂに着目すると、敵キャラクタ１０ｇ（プレーヤキャラクタ４ｇ）が条件Ａである対敵状況条件を満たすので当該敵キャラクタ１０ｇは条件Ｃを満たすとして、同じ接敵グループ１６に加えられる（図中、丸囲み数字「３」）。つまり、対敵状況条件を満たす関係にあるキャラクタ同士が連鎖していると見なせるのでグループに加える。この段階では、接敵グループ１６に所属するキャラクタは４体となる。

次に、新たに追加した敵キャラクタ１０ｇについて条件Ａ，Ｂ，Ｃを判断する。敵キャラクタ１０ｇの近場範囲２４には敵キャラクタ１０ｈ（プレーヤキャラクタ４ｈ）が居るので追加登録される（条件Ｂ。図中、丸囲み数字「４」）。この段階では、接敵グループ１６に所属するキャラクタは５体となる。

次に、新たに追加した敵キャラクタ１０ｈについて条件Ａ，Ｂ，Ｃを判断する。敵キャラクタ１０ｈと対敵状況条件（条件Ａ）を満たすプレーヤキャラクタ４は居ない。また、敵キャラクタ１０ｈの近場範囲２４には敵キャラクタ１０ｇが居るが（条件Ｂ）、既に接敵グループ１６に所属しているので追加登録しない。また、条件Ｃについては敵キャラクタ１０ｈは合致しない。

ここに至って、条件Ａ〜Ｃの判断が行われて、新たに接敵グループ１６に追加されるキャラクタがいなくなったので、接敵グループ１６の検知が完了する。

ちなみに、図５の例では、プレーヤキャラクタ４ｃ及びプレーヤキャラクタ４ｄについては、接敵状況条件を満たす他キャラクタが存在しないので、接敵グループを作ることはない。

本実施形態のこうした接敵グループ１６の検出手順は、始原の接敵グループ１６を構成するプレーヤキャラクタ４を基点として、対敵状況条件や近場条件を満たすキャラクタを芋づる式に検索して追加登録してゆくと読み換えることができる。

なお、ゲーム空間内に複数の接敵グループが存在し、それらがやがて接近するとそれぞれの接敵グループに所属するキャラクタが重複するようになる。重複するキャラクタで複数の接敵グループが連鎖しているとも表現できる。こうなると、その複数の接敵グループは１つの交戦域とみなせるのでそれらをまとめて１つの接敵グループを統合する。

以上、本実施形態の接敵グループの検出の動的な処理手順の一例を説明したが、接敵グループの検出を静的に説明するならば、次のように説明できる。すなわち、近場条件を満たす同じチームの１体以上のキャラクタ同士を１つのグループ（近場グループ）とした場合に、第１チームに係る複数の第１チーム近場グループと、第２チームに係る複数の第２チーム近場グループとがあるが、Ｎ個の第１チーム近場グループとＭ個の第２チーム近場グループにおいて（Ｎ≧１，Ｍ≧１，かつＮ＋Ｍ≧３）、対敵状況条件を満たす関係にあるキャラクタ同士がグループ間で連鎖するように存在する場合に、当該Ｎ個の第１チーム近場グループと当該Ｍ個の第２チーム近場グループとをまとめて１つの接敵グループとして検出する、ということができる。

図５の例では、敵キャラクタ４ｆの近場グループと、プレーヤキャラクタ４ａ，４ｂの近場グループと、敵キャラクタ４ｇ、４ｈの近場グループとの３つの近場グループが考えられる。そして、これら３つの近場グループに所属する何れかのキャラクタが対敵状況条件を満たすとして連鎖する関係にあるため、まとめて１つの接敵グループとして検出されている。

さて、検知された接敵グループ１６はゲーム進行に応じて適宜管理される。
図６は、接敵グループの管理について説明するための図である。例えば、図５で例示した状況から、敵キャラクタ１０ｆがプレーヤキャラクタ４ａの攻撃により撃破されて戦闘不能・行動不能になった場合、敵キャラクタ１０ｆは接敵グループ１６から登録抹消される。

また、敵キャラクタ１０ｈが、離脱条件を満たし、且つ見逃し条件を満たした場合は、前線から後退・逃走したと見做して接敵グループから登録抹消される。
ここで言う「離脱条件」は、ゲーム内容に応じて適宜設定可能である。例えば、接敵グループを構成するキャラクタからの離隔距離であったり、耐久値の残量であったり、残弾数「０」であったり、麻痺などのステータス異常などを１つ又は複数採用することができる。

本実施形態では、離脱条件として接敵グループ１６を構成する最寄りの味方からの離脱判定距離２６を採用し、接敵グループ１６の交戦状況に応じて切り替える。
具体的には、接敵グループ１６は一定時間存在すると、或いは当該グループを構成するプレーヤキャラクタ４が攻撃行動を行うと、交戦状況条件を満たして「非交戦状態」から「交戦状態」へ移行したとみなされる。つまり、単に敵と向かい合っている対敵状況よりも遙かに支援要求度の高い状態に変わったとみなされる。そして、非交戦状態の接敵グループ１６については離隔判定距離２６として近場範囲２４と同じ距離を適用し、交戦状態に移行した接敵グループ１６については、近場範囲２４より広い範囲（例えば、半径２００ｍ）を適用する。

また、「見逃し条件」は、敵が見逃してくれる条件である。例えば、離脱条件を満たした状態の継続時間が所定条件を満たした場合や、ロックオンされていない場合、所定の「降伏」行動をしている場合、などを１つ又は複数採用することができる。本実施形態では継続時間を採用する。

例えば、図６の例では、敵キャラクタ１０ｈが、離脱判定距離２６以上に離れた状態が、「見逃し条件」とする時間（例えば、５秒）以上継続すると（破線黒矢印）、戦闘離脱したとみなされ、接敵グループ１６から登録抹消される。しかし、敵キャラクタ１０ｈが、離脱判定距離２６以上に離れたとしても、その継続時間が見逃し条件とする時間に満たなければ登録は抹消されない。例えば、敵の側面または後方に回り込むために一時的に仲間から離れるといったシチュエーションでも、正しく接敵グループ１６を捉えることができる。

そして、接敵グループ１６を構成するプレーヤキャラクタ４のチームが、当初の複数チームが存在する状態から何れか１つのチームのみの状態に至ると、交戦していた勢力の一方が排除されて交戦が終了したと判断し、当該接敵グループ１６それ自体の登録を解除する。当該接敵グループ１６の残ったプレーヤキャラクタ４は、何れの接敵グループにも属さない状態に戻る。

［接敵グループの報知についての説明］
本実施形態では、検出・管理された接敵グループ１６に関する情報は、ゲーム画面にて各プレーヤに報知される。

図７は、本実施形態における接敵グループ１６に関する情報報知例を示す図である。
各プレーヤが使用する業務用ゲーム装置１３００のゲーム画面Ｗ２には、自身が操作するプレーヤキャラクタ４の１人称視点又は３人称視点のゲーム空間画像が表示される。そして、ゲーム画面Ｗ２は、自分のプレーヤキャラクタ４が向いている方角を知るための方位表示３０と、マップ表示Ｗ４を展開／収納するマップ操作タグ３２とが含まれる。なお、マップ表示Ｗ４は常時ゲーム画面Ｗ２に表示されているとしてもよい。

本実施形態では、接敵グループ１６に関する情報報知として、１）方位表示３０を用いた接敵グループ１６が存在する方位の報知と、２）マップ表示Ｗ４を用いた接敵グループ１６の位置の報知と、３）方位報知及び位置報知を用いた当該接敵グループにおけるチーム別の相対的なキャラクタの多寡の報知と、を行うことができる。

具体的には、方位表示３０には、接敵グループ１６別の存在報知体３４が表示される。
存在報知体３４が示す方位は、ゲーム画像の視点位置から見た相対方位であり、そちらに接敵グループ１６が存在していることを示す。

存在報知体３４の表示形態は、当該報知体に対応付けられる接敵グループ１６におけるチーム別のキャラクタの多寡に応じて決定される。本実施形態では、チーム「ＲＥＤ」とチーム「ＢＬＵＥ」の２チーム対戦なので、接敵グループ１６に登録されているキャラクタの多い方の表示色（例えばチームカラー）が設定される。登録されているキャラクタが同数の場合は別の第３の色（無色を含む）が設定される。また、存在報知体３４には、対応付けられる接敵グループ１６におけるチーム別のキャラクタ数の差の値が表示される。
つまり、存在報知体３４により、接敵グループ１６の相対方位と、数的有利／不利に関する情報と、がプレーヤに提供される。

図８は、マップ表示における接敵グループ１６の位置報知の例を示す図である。
マップ表示Ｗ４のデザインは適宜設定可能であるが、例えば、戦場となるゲーム空間を俯瞰した地図としてデザインし、そこに地形の高低差は勿論のこと、障害物７や拠点８ｒ，８ｂの位置と大きさを簡略して表す。勿論、マップ表示Ｗ４のデザインは平面表示でも立体表示でも構わない。そして、マップ表示Ｗ４には、行動可能なプレーヤキャラクタ４別のキャラクタマーカ３６が表示され、各プレーヤキャラクタ４の位置と向きを逐一表示する。更に、マップ表示Ｗ４には、接敵グループ１６毎の位置報知体３８が表示される。

位置報知体３８のデザインは適宜設定可能である。本実施形態では、接敵グループ１６の全所属キャラクタのキャラクタマーカ３６を囲む矩形領域の輪郭線を表す。これ以外にも、例えば、形状は矩形に限らずその他の多角形や、楕円形、球形、直方体などでもよい。また、輪郭線を表示する形態に限らず領域内を半透明に表示したり、領域の角部（例えば、矩形領域の四つ角）のみを表示するカギ括弧状の表示形態とするなど、演出意図に応じて適宜設定可能である。

また、位置報知体３８の表示形態は、当該報知体に対応付けられる接敵グループ１６におけるチーム別のキャラクタの相対的な多寡に応じて変更される。
本実施形態では、チーム「ＲＥＤ」とチーム「ＢＬＵＥ」の２チーム対戦なので、接敵グループ１６に登録されているキャラクタの多い方のチームカラーが位置報知体３８の表示色として設定される。登録されているキャラクタが同数の場合は別の第３の色（無色を含む）が設定される。また、位置報知体３８が表す輪郭線は、対応付けられる接敵グループ１６におけるチーム別のキャラクタ数の差に応じて、差が大きいほどより太くなるように輪郭線の太さが設定される。勿論、多寡の通知は輪郭線の太さに限らず、位置報知体３８の明度変化周期により表現するとしても良いし、キャラクタ数の差に応じた多重線としたり、キャラクタ数の差に応じた大きさの星印などの付加的表示物を添付するといった表現としてもよい。

つまり、位置報知体３８により、接敵グループ１６のゲーム空間内における位置と、どのチームが優勢であるかと、数的有利／不利に関する情報と、がプレーヤに提供される。

また、本実施形態ではキャラクタマーカ３６に付属して、当該マークに対応するプレーヤキャラクタ４をロックオンしている他プレーヤキャラクタ（敵キャラクタ）の数を通知する集中報知体３９が表示される。図８では、２体以上からロックオンされているプレーヤキャラクタ４に対応するキャラクタマーカ３６に付属して集中報知体３９が表示されている。

［機能構成の説明］
次に、本実施形態におけるゲームシステムの機能構成例について説明する。
図９は、本実施形態における業務用ゲーム装置１３００の機能構成例を示す機能ブロック図である。業務用ゲーム装置１３００は、操作入力部１００と、媒体読取部１０２と、入金検知部１０４と、処理部２００と、音出力部３９０と、画像表示部３９２と、通信部３９４と、記憶部５００とを備える。

操作入力部１００は、プレーヤによって為された各種の操作入力に応じて操作入力信号を処理部２００に出力する。例えば、プッシュスイッチや、ジョイスティック、タッチパッド、トラックボール、加速度センサ、ジャイロ、ジェスチャーコントローラ、などによって実現できる。図２の例では、ジョイスティック１３０２や、ボタンスイッチ１３０４、タッチパネル１３０６がこれに該当する。

媒体読取部１０２は、電子決済用媒体６で採用される技術方式に準じた公知の読取装置により実現され、電子決済用媒体６に記憶されているデータを読み出して処理部２００へ出力する。例えば、電子決済用媒体６に非接触型ＩＣチップを用いるのであれば、そのカードの仕様に準じた非接触型リーダーライターにより実現される。図２の例では、媒体読取装置１３４４がこれに該当する。

入金検知部１０４は、投入された現金を検出し、入金額を示す情報を処理部２００へ出力する手段であって、公知の入金装置、硬貨投入装置等により実現できる。図２の例では、入金装置１３３０がこれに該当する。

処理部２００は、例えばＣＰＵ，ＧＰＵ等のマイクロプロセッサや、ＡＳＩＣ、ＩＣメモリなどの電子部品によって実現され、操作入力部１００や記憶部５００を含む各機能部との間でデータの入出力制御を行う。そして、所定のプログラムやデータ、操作入力部１００からの操作入力信号、媒体読取部１０２で読み出したデータ、サーバシステム１１００から受信したデータ等に基づいて各種の演算処理を実行して、業務用ゲーム装置１３００の動作を制御する。図２の例では制御基板１３５０がこれに該当する。

そして、本実施形態の処理部２００は、プレーヤ端末制御部２０２と、音生成部２９０と、画像生成部２９２と、通信制御部２９４とを含む。

プレーヤ端末制御部２０２は、業務用ゲーム装置１３００をゲームプレイのためのプレーヤ端末として機能させるための制御を行う。
例えば、
１）操作入力に応じた操作入力信号をサーバシステム１１００へ送信する制御と、
２）サーバシステム１１００から配信されたゲームステージや各プレーヤのプレーヤキャラクタ４に関する初期設定データを参照して、仮想３次元空間にゲーム空間を設定し、各プレーヤのプレーヤキャラクタ４と、自機を操作するプレーヤのプレーヤキャラクタ４の１人称視点又は３人称視点となる仮想カメラを配置する制御と、
３）自機での操作入力及びサーバシステム１１００から受信した他の業務用ゲーム装置１３００における操作入力信号に基づいて、各プレーヤキャラクタ４の動作を制御する処理と、
４）ゲーム画面の生成やゲーム音の放音に必要な各種処理と、を行うことができる。
勿論、こうしたプレーヤ端末制御部２０２の機能は、クライアントサーバシステムのシステムデザインにより必ずしもこれに限定されるものではなく、適宜変更することができる。

音生成部２９０は、例えばデジタルシグナルプロセッサ（ＤＳＰ）や、音声合成ＩＣなどのプロセッサ、音声ファイルを再生可能なオーディオコーデック等によって実現され、ゲームに係る効果音やＢＧＭ、各種操作音の音信号を生成し、音出力部３９０に出力する。

音出力部３９０は、音生成部２９０から入力される音信号に基づいて効果音やＢＧＭ等を音出力する装置によって実現される。図２のスピーカ１３１０がこれに該当する。

画像生成部２９２は、例えば、ＧＰＵ、デジタルシグナルプロセッサ（ＤＳＰ）などのプロセッサ、ビデオ信号ＩＣ、ビデオコーデックなどのプログラム、フレームバッファ等の描画フレーム用ＩＣメモリ等によって実現される。そして、画像生成部２９２は、１フレーム時間（例えば１／６０秒）で１枚のゲーム画面の画像を生成し、生成したゲーム画面の画像信号を画像表示部３９２へ出力する。

画像表示部３９２は、画像生成部２９２から入力される画像信号に基づいてゲーム画像等の各種画面を表示することができる。例えば、フラットパネルディスプレイ、ブラウン管（ＣＲＴ）、プロジェクター、ヘッドマウントディスプレイといった画像表示装置によって実現できる。本実施形態では、図２のタッチパネル１３０６がこれに該当する。

通信制御部２９４は、データ通信に係るデータ処理を実行し、通信部３９４を介して外部装置とのデータのやりとりを実現する。

通信部３９４は、通信回線９と接続して通信を実現する。例えば、無線通信機、モデム、ＴＡ（ターミナルアダプタ）、有線用の通信ケーブルのジャックや制御回路等によって実現され、図２の通信装置モジュール１３５３がこれに該当する。

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

記憶部５００は、システムプログラム５０１と、クライアントプログラム５０２と、を予め記憶する。その他、媒体読取部１０２で読み取った電子決済用媒体６の媒体ＩＤであったり、ゲーム音やゲーム画像のデータ、タイマやカウンタ、各種フラグなどの情報を適宜記憶できる。

システムプログラム５０１は、処理部２００が読み出して実行することでコンピュータとして必要な基本的な入出力機能を実現するためのプログラムである。
クライアントプログラム５０２は、処理部２００にプレーヤ端末制御部２０２としての機能を実現させることができる。クライアントプログラム５０２は、業務用ゲーム装置１３００が起動される都度、サーバシステム１１００からダウンロードされて記憶されることとしてもよい。

図１０は、本実施形態におけるサーバシステム１１００の機能構成例を示す機能ブロック図である。本実施形態におけるサーバシステム１１００は、操作入力部１００ｓと、サーバ処理部２００ｓと、画像表示部３９２ｓと、通信部３９４ｓと、サーバ記憶部５００ｓとを備える。

操作入力部１００ｓは、サーバの管理のための各種操作を入力するための手段である。図１の例ではキーボード１１０６が該当する。

サーバ処理部２００ｓは、例えばＣＰＵやＧＰＵ等のマイクロプロセッサや、ＡＳＩＣ、ＩＣメモリなどの電子部品によって実現され、操作入力部１００ｓやサーバ記憶部５００ｓを含む各機能部との間でデータの入出力制御を行う。そして、所定のプログラムやデータ、操作入力部１００ｓからの操作入力信号、業務用ゲーム装置１３００から受信したデータ等に基づいて各種の演算処理を実行して、サーバシステム１１００の動作を統合的に制御する。図１の例では制御基板１１５０がこれに該当する。

そして、本実施形態のサーバ処理部２００ｓは、電子決済部２０８と、ゲーム管理部２１０と、リプレイ表示制御部２１２と、接敵グループ検出部２２０と、報知制御部２４０と、画像生成部２９２ｓと、通信制御部２９４ｓとを含む。

電子決済部２０８は、プレイ対価を電子決済で支払いする場合の決済処理を行う。公知の電子決済技術を適宜利用することで実現される。

ゲーム管理部２１０は、本実施形態のチーム対戦型オンラインマルチプレイゲームに係る処理を実行する。例えば、
１）プレイ対価の支払いが行われた業務用ゲーム装置１３００にて、プレーヤ登録とプレーヤキャラクタ４の選択を行わせ、登録内容と選択結果の入力信号を受信して、サーバ記憶部５００ｓにプレーヤ登録データとして記憶させる処理、
２）各業務用ゲーム装置１３００から、プレーヤのチーム登録に関する情報を取得し、プレーヤ登録データに格納する処理、
３）対戦プレイするゲームステージを業務用ゲーム装置１３００に選択入力させて、選択結果を受信してサーバ記憶部５００ｓに格納するとともに、各業務用ゲーム装置１３００へ配信する処理、
４）各業務用ゲーム装置１３００から操作入力信号を受け付け、各プレーヤキャラクタ４の位置と動作とを記憶する処理、
５）攻撃行動にともなうダメージの算出と反映処理、
６）各プレーヤキャラクタ４の最新のステータス情報を配信する処理、
などを実行できる。その他、ゲーム実行に必要な計時処理やランダム抽選処理、フラグ管理、などを実行できる。勿論、こうしたゲーム管理部２１０の機能は、クライアントサーバシステムのシステムデザインにより必ずしもこれに限定されるものではなく、適宜変更することができる。

リプレイ表示制御部２１２は、ゲーム終了後に各業務用ゲーム装置１３００にて、或いはターミナル装置１３９０にてリプレイ画面を表示させる制御を行う。

接敵グループ検出部２２０は、上述した条件Ａ〜Ｃの判断を行うことで、接敵グループ条件を満たすプレーヤキャラクタ４の集合すなわち接敵グループを検出する。すなわち、本実施形態では、最小構成の接敵関係をなす始原の接敵グループを検出するとともに、始原の接敵グループに所属する敵味方双方のプレーヤキャラクタ４を基点として１つの交戦域とみなせる範囲内のキャラクタ群を当該接敵グループに追加し、１つの交戦域とみなせる接敵グループを検出する。また、接敵グループを構成するプレーヤキャラクタ４の増減管理、接敵関係をなさなくなった接敵グループの抹消、同一のプレーヤキャラクタ４がどちらにも登録されている複数の接敵グループの統合、などの管理制御を行う。また、接敵グループ検出部２２０は、内部的な機能構成として、第１サブグループ検出部２２２と、第２サブグループ検出部２２４と、状態判定部２２６とを含む。

第１サブグループ検出部２２２は、近場条件を満たす一方のチーム（第１キャラクタのグループ）のキャラクタのグループである第１サブグループ（第１チーム近場グループ）を検出する。図５の例で言えば、例えば、チーム「ＲＥＤ」のプレーヤキャラクタのうち、近場条件を満たすプレーヤキャラクタ４ａ、４ｂを１つの第１サブグループとして検出する。

第２サブグループ検出部２２４は、近場条件を満たす他方のチーム（第２キャラクタのグループ）のキャラクタのグループである第２サブグループ（第２チーム近場グループ）を検出する。図５の例で言えば、例えば、チーム「ＢＬＵＥ」のプレーヤキャラクタのうち、近場条件を満たすプレーヤキャラクタ４ｆを１つの第２サブグループ（１つの第２チーム近場グループ）として検出し、近場条件を満たすプレーヤキャラクタ４ｇ、４ｈを１つの第２サブグループ（１つの第２チーム近場グループ）として検出する。

接敵グループの検出を結果的（全体構成的）に説明すると、接敵グループ検出部２２０は、第１サブグループ検出部２２２で検出されたＮ個の第１サブグループと、第２サブグループ検出部２２４で検出されたＭ個の第２サブグループとにおいて（Ｎ≧１，Ｍ≧１，かつＮ＋Ｍ≧３）、対敵状況条件を満たす関係にあるキャラクタ同士がグループ間で連鎖するように存在する場合に、当該Ｎ個の第１サブグループと当該Ｍ個の第２サブグループとをまとめて１つの接敵グループとして検出すると言える。

状態判定部２２６は、第１サブグループと第２サブグループとが交戦状態にあることを示す交戦状況条件を満たさない場合には、接敵グループの状態を「非交戦状態」と判定し、満たす場合には「交戦状態」と判定する。本実施形態における「交戦状況条件」は、接敵グループが生成されて所定時間が経過したこととするが、攻撃行動が発生したことを条件としてもよい。

そして、接敵グループ検出部２２０は、状況判定部２２６による判定を用いて、交戦状態と判定された接敵グループ（交戦グループ）については、従前に当該接敵グループに含まれていたキャラクタであって、当該接敵グループに含まれる何れかのキャラクタとの間の距離が所与の距離条件を満たすキャラクタを、継続して当該接敵グループに含めて検出する。図６の例で言うと、チーム「ＢＬＵＥ」のキャラクタ１０ｈが離脱判定距離２６以内であれば、近場範囲２４を越えた位置にあっても従前の接敵グループに含める。

また、接敵グループ検出部２２０は、過去所定時間の間に交戦状態の接敵グループ（交戦グループ）に含まれていたキャラクタを継続して当該接敵グループに含めて検出することができる。
図６の例で言うと、チーム「ＢＬＵＥ」のキャラクタ１０ｈがチーム「ＢＬＵＥ」のキャラクタ１０ｇを中心とする離脱判定距離２６の外に移動しても、「見逃し条件」とする時間内に、キャラクタ１０ｇとの距離を離脱判定距離２６以内に縮めれば、近場範囲２４を越えた位置にあってもキャラクタ１０ｇと同じ交戦状態の接敵グループに含めて検出する。すなわち、接敵グループ検出部２２０は、従前に交戦状態の接敵グループ（交戦グループ）に含まれているキャラクタについては、従前の接敵グループ（交戦グループ）の何れかのキャラクタと所与の継続条件を満たす場合、継続条件を満たすキャラクタと同じ接敵グループに含めて検出することができると言える。これにより交戦中のキャラクタ同士の関係性を強くすることができる。

さらに、接敵グループ検出部２２０は、過去所定時間の間に交戦状態の接敵グループ（交戦グループ）に含まれていたキャラクタを含む他の接敵グループが存在する場合、当該他の接敵グループと、従前の交戦状態の接敵グループ（交戦グループ）とを連結対象接敵グループ候補として検出し、一つの接敵グループ（交戦グループ）として連結・検出することができる。

図５の例を元に具体的に説明すると、仮にゲームが進行するうちに、チーム「ＢＬＵＥ」のキャラクタ１０ｈが、図示されている接敵グループ１６とは別の、チーム「ＢＬＵＥ」のキャラクタからなる不図示の他接敵グループに新たに含まれたとする。その場合、交戦状態の接敵グループ１６と、キャラクタ１０ｇを含まずキャラクタ１０ｈを含む他接敵グループとを、キャラクタ１０ｈを中継して繋げるように一つの接敵グループ（交戦グループ）として検出する。

なお、接敵グループ条件＝交戦状況条件とする場合には、非交戦状態の接敵グループを接敵グループ候補（接敵グループ）、交戦状態の接敵グループを最終的な接敵グループ（交戦グループ）として検出してもよい。

報知制御部２４０は、接敵グループ検出部２２０の検出に応じた報知を行うための制御を行う。本実施形態では多寡別報知制御部２４２と、存在報知制御部２４４と、位置報知制御部２４６と、集中報知制御部２４８とを含む。

多寡別報知制御部２４２は、接敵グループに含まれる各チームのキャラクタの多寡に応じた報知の制御を行う。本実施形態では、存在報知体３４（図７参照）と、位置報知体３８（図８参照）との表示形態を多寡に応じて設定する。

存在報知制御部２４４は、第１サブグループ及び／又は第２サブグループの存在を示す所与の報知の制御を行う。本実施形態では、方位表示３０に相対方位を示す存在報知体３４を表示制御する（図７参照）。

位置報知制御部２４６は、第１サブグループ及び／又は第２サブグループの位置、すなわち接敵グループに含まれるキャラクタの位置を報知する制御を行う。本実施形態では、位置報知体３８（図８参照）を表示制御する。

集中報知制御部２４８は、接敵関係が集中しているプレーヤキャラクタ４を報知する制御を行う。本実施形態では、集中報知体３９（図８参照）を表示制御する。

画像生成部２９２ｓは、サーバシステム１１００の保守に関する画像等を生成し、画像表示部３９２ｓへ出力することができる。クライアントサーバシステムの機能配分によっては、業務用ゲーム装置１３００にて表示するゲーム画面を生成する機能をもたせることもできる。

画像表示部３９２ｓは、画像生成部２９２ｓから入力される画像信号に基づいてシステム管理のための各種画像を表示する。例えば、フラットパネルディスプレイ、ブラウン管（ＣＲＴ）、プロジェクター、ヘッドマウントディスプレイといった画像表示装置によって実現できる。図１の例ではタッチパネル１１０８が該当する。

通信制御部２９４ｓは、データ通信に係るデータ処理を実行し、通信部３９４ｓを介して外部装置とのデータのやりとりを実現する。

通信部３９４ｓは、通信回線９と接続して通信を実現する。例えば、無線通信機、モデム、ＴＡ（ターミナルアダプタ）、有線用の通信ケーブルのジャックや制御回路等によって実現される。図１の例では通信装置１１５３が該当する。

サーバ記憶部５００ｓは、サーバ処理部２００ｓにサーバシステム１１００を統合的に制御させるための諸機能を実現するためのシステムプログラムや、ゲーム実行に必要なプログラム、各種データ等を記憶する。また、サーバ処理部２００ｓの作業領域として用いられ、サーバ処理部２００ｓが各種プログラムに従って実行した演算結果などを一時的に記憶する。この機能は、例えばＲＡＭやＲＯＭなどのＩＣメモリ、ハードディスク等の磁気ディスク、ＣＤ−ＲＯＭやＤＶＤなどの光学ディスクなどによって実現される。図１の例では本体装置１１０１が搭載するＩＣメモリ１１５２やハードディスクなどの記憶媒体、及びストレージ１１４０がこれに該当する。

図１１は、本実施形態のサーバ記憶部５００ｓが記憶するプログラムやデータの例を示す図である。本実施形態のサーバ記憶部５００ｓは、サーバシステムプログラム５０３と、ゲームサーバプログラム５０５と、配信用クライアントプログラム５０７と、ゲーム初期設定データ５１０と、を予め記憶する。また、プレーヤ登録データ５５０と、プレイデータ７００とを記憶する。その他、タイマやカウンタ、各種フラグなどの情報を適宜記憶できる。

サーバシステムプログラム５０３は、サーバ処理部２００ｓが読み出して実行することでサーバシステム１１００にコンピュータとして必要な基本的な入出力機能を実現させるためのシステムプログラムである。

ゲームサーバプログラム５０５は、サーバ処理部２００ｓが読み出して実行することで、サーバシステム１１００をゲームサーバとして機能させるプログラムである。サーバ処理部２００ｓに、電子決済部２０８、ゲーム管理部２１０、リプレイ表示制御部２１２、接敵グループ検出部２２０、報知制御部２４０、画像生成部２９２ｓ、通信制御部２９４ｓとしての機能を実装させることができる。

配信用クライアントプログラム５０７は、業務用ゲーム装置１３００へ配信・提供されるクライアントプログラム５０２（図９参照）のオリジナルである。

ゲーム初期設定データ５１０は、ゲームの実行に必要な各種初期設定データを格納する。
例えば、図１２に示すように、ゲームステージ別に用意されたゲーム空間設定データ５１１と、キャラクタ種類別に用意されたキャラクタ初期設定データ５２０とを含む。勿論、これら以外のデータも適宜格納することができる。

１つのゲーム空間設定データ５１１は、ステージ名などのステージＩＤ５１２と、障害物７や拠点８ｒ，８ｂのモデルや配置位置を定義する背景オブジェクト配置データ５１３と、索敵範囲設定値５１４と、近場範囲設定値５１５と、離脱判定距離設定値５１６と、マップ表示Ｗ４（図８参照）の地図に相当するマップデータ５１７と、を含む。勿論、これら以外のデータも適宜格納することができる。

索敵範囲設定値５１４と、近場範囲設定値５１５とは、それぞれプレーヤキャラクタ４を基準とした索敵範囲２０（図４参照）と、近場条件となる近場範囲２４（図５参照）の形状と大きさとを定義する。離脱判定距離設定値５１６は交戦状態の接敵グループに適用される離脱判定距離２６（図６参照）の大きさを定義する。

１つのキャラクタ初期設定データ５２０は、キャラクタ種類と、属性と、初期能力値リストとを含む。初期能力値リストには当該キャラクタの射程範囲２２（図５参照）すなわち対敵状況条件に係る距離要素すなわち対敵距離条件を定義するデータを含む。

図１１に戻って、プレーヤ登録データ５５０は、本実施形態のチーム対戦型オンラインマルチプレイゲームに参加するプレーヤ別に用意されて各種の登録情報を格納する。
１つのプレーヤ登録データ５５０は、１）プレーヤ名などのプレーヤＩＤ５５１と、２）当該プレーヤのプレーヤキャラクタ４とするキャラクタ種類を定義するプレーヤキャラクタ種類５５３と、３）サーバシステム１１００が業務用ゲーム装置１３００とデータ通信を確保するために必要なアドレス情報等を格納する使用端末情報５５５と、４）所属チーム名５５７とを含む。勿論、これら以外のデータも適宜格納することができる。

プレイデータ７００は、本実施形態のチーム対戦型オンラインマルチプレイゲームの進行状況を記述する各種データを格納する。
例えば、図１３に示すように、参加プレーヤＩＤリスト７０１と、プレイ開始日時７０２と、対戦するゲーム空間の種類を定義する使用ステージＩＤ７０４と、キャラクタ別ステータスデータ７１０と、キャラクタ別行動ログ７３０と、接敵グループ登録データ７６０と、存在報知体制御データ７８０と、位置報知体制御データ７８２と、集中報知体制御データ７８４と、を含む。勿論、これら以外のデータも適宜格納することができる。

キャラクタ別ステータスデータ７１０は、プレーヤキャラクタ４別に用意されて、当該キャラクタの最新状況を記述する各種データを格納する。例えば、図１４に示すように、当該キャラクタを使用するプレーヤを定義するプレーヤＩＤ７１１と、キャラクタ種類７１３と、所属チームＩＤ７１４と、ゲーム空間内における位置座標７１５と、視線方向７１７と、残耐久値７１９と、索敵済キャラクタＩＤリスト７２０と、攻撃対象候補キャラクタＩＤリスト７２２と、ロックオン対象キャラクタＩＤ７２４と、を含む。勿論、これら以外のデータも適宜格納することができる。

索敵済キャラクタＩＤリスト７２０は、当該プレーヤキャラクタの索敵範囲２０（図４参照）に存在する他プレーヤキャラクタのキャラクタＩＤのリストである。ゲーム開始時点の初期状態では当該リストは登録無しである。

攻撃対象候補キャラクタＩＤリスト７２２は、当該プレーヤキャラクタの射程範囲２２（図４参照）に存在する他プレーヤキャラクタのキャラクタＩＤのリストである。ゲーム開始時点の初期状態では当該リストは登録無しである。

ロックオン対象キャラクタＩＤ７２４は、攻撃対象候補のうちロックオンされているキャラクタを示す。ゲーム開始時点の初期状態では登録無しである。

図１３に戻って、キャラクタ別行動ログ７３０は、プレーヤキャラクタ４別に用意され、プレイ中の行動を時系列に記述するデータである。例えば、図１５に示すように、１つのキャラクタ別行動ログ７３０は、対応するプレーヤキャラクタ４を示す記録対象キャラクタＩＤ７３１と、時系列のログデータセット７４０と、を含む。勿論、これら以外のデータも適宜格納することができる。

１つのログデータセット７４０は、例えば、記録時のタイミングを示すフレーム番号７４１と、その時に対応するプレーヤキャラクタ４のゲーム空間における位置座標７４２と、視線方向７４３と、残耐久値７４４と、その時の行動種類７４５と、その時の索敵済キャラクタＩＤリスト７２０（図１４参照）の複製である索敵リスト７４６と、その時の攻撃対象候補キャラクタＩＤリスト７２２（図１４参照）の複製である攻撃対象リスト７４７と、その時のロックオン対象キャラクタＩＤ７２４（図１４参照）の複製であるロックオンリスト７４８とを含む。勿論、これら以外のデータも適宜格納することができる。

図１３に戻って、接敵グループ登録データ７６０は、検知された接敵グループ毎に用意され、当該接敵グループに係る各種データを格納する。１つの接敵グループ登録データ７６０は、例えば、ユニークな接敵グループＩＤ７６１と、グループ作成日時７６２と、交戦状態／非交戦状態を示す交戦状態フラグ７６３と、グループ所属キャラクタＩＤリスト７６５と、第１サブグループ所属キャラクタＩＤリスト７６７と、第２サブグループ所属キャラクタＩＤリスト７６９と、を含む。勿論、これら以外のデータも適宜格納することができる。

存在報知体制御データ７８０は、存在報知体３４（図７参照）毎に用意され、その表示制御に係る各種データを格納する。例えば、報知先を示す表示先キャラクタＩＤと、報知対象接敵グループＩＤと、相対方位と、表示形態設定データと、を含む。勿論、これら以外のデータも適宜格納することができる。

相対方位は、表示先キャラクタＩＤの示すプレーヤキャラクタ４の現在位置から、報知対象接敵グループＩＤが示す接敵グループの中心位置を見た相対方位である。

表示形態設定データは、存在報知体３４の形状や表示色、明度変化パターンなどの表示形態を定義する。

位置報知体制御データ７８２は、位置報知体３８（図８参照）毎に用意され、その表示制御に係る各種データを格納する。例えば、報知対象接敵グループＩＤと、マップ表示Ｗ４内における表示位置データと、表示形態設定データとを格納する。勿論、これら以外のデータも適宜格納することができる。

集中報知体制御データ７８４は、集中報知体３９（図８参照）毎に用意され、その表示制御に係る各種データを格納する。例えば、添付対象キャラクタＩＤと、表示数とを格納する。勿論、これら以外のデータも適宜格納することができる。

［処理の流れの説明］
次に、ゲームシステムの動作説明として、先ずユーザ登録に係る処理の流れについて説明する。

図１６〜図１７は、本実施形態におけるサーバシステム１１００にて実行される主たる処理の流れを説明するためのフローチャートである。同処理は、サーバシステム１１００がゲームサーバプログラム５０５を実行することにより実現される。

図１６に示すように、先ずサーバシステム１１００は、プレーヤ登録に関する処理を実行する（ステップＳ２）。具体的には、プレイ対価の支払いが済まされた業務用ゲーム装置１３００にて所定のエントリー画面を表示させて、プレーヤにプレーヤＩＤの入力と、自分のプレーヤキャラクタ４とするキャラクタ種類の入力と、所属チーム名の入力とをさせる。そして、各業務用ゲーム装置１３００から受信したそれらの入力結果を元に、プレーヤ登録データ５５０を記憶する（図１１参照）。また、プレイデータ７００を用意して、全プレーヤのプレーヤＩＤを参加プレーヤＩＤリスト７０１に設定し、プレイ開始日時７０２に現在日時を設定する（図１３参照）。

次に、サーバシステム１１００は、対戦ステージの選択に関する処理とゲーム開始前の初期化処理をする（ステップＳ４）。具体的には、何れかの業務用ゲーム装置１３００にて所定のステージ選択画面を表示させて、対戦プレイを行うステージをプレーヤに選択させ、選択結果を受信して使用ステージＩＤ７０４に格納する。そして、選択されたステージのゲーム空間設定データ５１１（図１２参照）を参照して、仮想３次元空間にゲーム空間を構成し、各プレーヤのプレーヤキャラクタ４及び各々の仮想カメラを初期位置に配置する。

次に、サーバシステム１１００はゲームの進行制御を開始する（ステップＳ１０）。
これに伴い、各プレーヤが使用する業務用ゲーム装置１３００ではゲーム画像が表示されるとともにゲーム音が放音され、プレイできるようになる。キャラクタ別ステータスデータ７１０は逐次更新されるとともに、キャラクタ別行動ログ７３０にログデータセット７４０が蓄積されてゆく（図１５参照）。

そして、ゲームが開始されると、サーバシステム１１００は、ゲームが終了するまでタッチパネル１３０６の１描画フレーム以下の所定周期でステップＳ１０〜Ｓ１６０を実行する。

具体的には、所定周期毎に、サーバシステム１１００は、行動可能なプレーヤキャラクタ４毎にループＡを実行する（ステップＳ１０〜Ｓ２８）。

ループＡにおいて、サーバシステム１１００は、処理対象とするプレーヤキャラクタ４の索敵範囲２０（プレイするステージの索敵範囲設定値５１４が適用される；図４、図１２参照）に存在する、処理対象のプレーヤキャラクタ４以外の他プレーヤキャラクタを抽出して、処理対象キャラクタのキャラクタ別ステータスデータ７１０の索敵済キャラクタＩＤリスト７２０を更新する（ステップＳ１２）。

また、処理対象とするプレーヤキャラクタ４の射程範囲２２に存在する他プレーヤキャラクタを抽出して、処理対象キャラクタの攻撃対象候補キャラクタＩＤリスト７２２を更新する（ステップＳ１４）。

次に、処理対象とするプレーヤキャラクタ４のロックオン対象キャラクタＩＤ７２４（図１４参照）が未定であれば（ステップＳ１６のＹＥＳ）、自動で攻撃対象候補キャラクタＩＤリスト７２２からロックオン対象を自動選択する（ステップＳ１８）。勿論、処理対象とするプレーヤキャラクタ４のプレーヤの業務用ゲーム装置１３００から、所定のロックオン対象選択操作に応じて、攻撃対象候補キャラクタＩＤリスト７２２からロックオン対象の選択を切替変更することができる（ステップＳ２０）。

図１７に移って、サーバシステム１１００は、処理対象とするプレーヤキャラクタ４に対応する業務用ゲーム装置１３００から所定の攻撃操作入力を受信すると、当該プレーヤキャラクタ４にロックオン対象へ攻撃するように攻撃行動制御を開始することができる（ステップＳ２２）。そして、処理対象とするプレーヤキャラクタ４への着弾判定に応じたダメージ判定とダメージ反映を行うことができる（ステップＳ２４）。ダメージ反映では残耐久値７１９が減算され、減算の結果「０」に達すると処理対象とするプレーヤキャラクタ４は行動不能となり、以降はループＡの処理対象外となる。

また、サーバシステム１１００は、処理対象とするプレーヤキャラクタ４に対応する業務用ゲーム装置１３００から移動操作入力を受信すると、当該プレーヤキャラクタ４を移動行動制御することができる（ステップＳ２６）。

行動可能な全てのプレーヤキャラクタ４についてループＡを実行したならば（ステップＳ２８）、サーバシステム１１００は次に接敵グループ検知処理を実行する（ステップＳ５０）。

図１８〜図１９は、本実施形態における接敵グループ検知処理の流れを説明するためのフローチャートである。同処理において、サーバシステム１１００は、接敵グループ未登録で行動可能なプレーヤキャラクタ４毎にループＢを実行する（ステップＳ５２〜Ｓ８８）。

ループＢでは先ず、ループＢ処理対象キャラクタと対敵状況条件を満たす敵キャラクタすなわち接敵関係をなす敵キャラクタの有無を判定する（ステップＳ５４）。本実施形態における接敵関係は、ロックオン対象キャラクタＩＤ７２４にプレーヤキャラクタ４のキャラクタＩＤが設定されていることである。

もし、否定であれば（ステップＳ５４のＮＯ）、サーバシステム１１００はループＢを終了する。

一方、肯定であれば（ステップＳ５４のＹＥＳ）、サーバシステム１１００は、該当する敵キャラクタが登録されている既存の接敵グループがあるかを判定する（ステップＳ５６）。そして、もし該当する既存の接敵グループがあれば（ステップＳ５６のＹＥＳ）、サーバシステム１１００は、ループＢ処理対象キャラクタを該当敵キャラクタが登録されているのと同じ接敵グループに登録し（ステップＳ６０）、ループＢを終了する。

反対に、該当敵キャラクタが登録されている既存の接敵グループが無ければ（ステップＳ５６のＮＯ）、サーバシステム１１００は新たに接敵関係が発生したと判断し、新規に接敵グループを作成する（ステップＳ６２）。具体的には、プレイデータ７００に新たな接敵グループ登録データ７６０を作成し（図１３参照）、接敵グループＩＤ７６１にユニークなＩＤを自動生成して設定し、現在日時をグループ作成日時７６２に設定し、交戦状態フラグ７６３を「０（非交戦）」に設定する。また、グループ所属キャラクタＩＤリスト７６５と、第１サブグループ所属キャラクタＩＤリスト７６７と、第２サブグループ所属キャラクタＩＤリスト７６９とは登録無しに設定する。

そして、ループＢの処理対象キャラクタと、敵対条件を満たした敵キャラクタとなる他プレーヤキャラクタと、のそれぞれのキャラクタＩＤをグループ所属キャラクタＩＤリスト７６５に格納して、この新規作成した接敵グループに登録する（ステップＳ６４）。例えば、第１サブグループ所属キャラクタＩＤリスト７６７には、チーム「ＲＥＤ」のプレーヤキャラクタ４のキャラクタＩＤを登録し、第２サブグループ所属キャラクタＩＤリスト７６９には、チーム「ＢＬＵＥ」のプレーヤキャラクタ４のキャラクタＩＤを登録するとする。これが始原の接敵グループとなる。

次に、ループＢ処理対象キャラクタと同じ接敵グループに登録されているキャラクタ毎にループＣを実行して、それぞれにとって近場にいる味方を検索して当該接敵グループに追加登録し、その近場に居る味方と対敵状況条件を満たすキャラクタを検索して追加登録する（ステップＳ８０〜Ｓ８４）。

すなわち、ループＣの処理対象キャラクタの近場範囲２４（図５参照；プレイするステージの近場範囲設定値５１５が適用される）に位置し近場条件を満たすと判断される味方を検索し、該当するキャラクタがいれば（ステップＳ８２のＹＥＳ）、そのキャラクタＩＤをグループ所属キャラクタＩＤリスト７６５に格納して当該新規作成した接敵グループに登録する（ステップＳ８４）。また、それとともに、該当するキャラクタを、ループＣの処理対象キャラクタと同じサブグループの第１サブグループ所属キャラクタＩＤリスト７６７又は第２サブグループ所属キャラクタＩＤリスト７６９に格納して登録する。

図１９に移って、サーバシステム１１００は、次にループＣ処理対象キャラクタと対敵条件を満たす敵キャラクタを検索する（ステップＳ８６）。そして、該当するキャラクタがあれば（ステップＳ８６のＹＥＳ）、当該キャラクタをループＢ処理対象キャラクタと同じ接敵グループへ追加登録する（ステップＳ８８）。また、それとともに、該当するキャラクタを、ループＣの処理対象キャラクタとは異なるサブグループの第１サブグループ所属キャラクタＩＤリスト７６７又は第２サブグループ所属キャラクタＩＤリスト７６９に格納して登録する。そして、現在処理対象としているキャラクタに対するループＣの実行は終了する（ステップＳ９０）。

ループＣを最初に実行する段階では、ループＢ処理対象キャラクタと同じ接敵グループには、ループＢ処理対象キャラクタと、ステップＳ５４にて判別された敵キャラクタとが所属している。図５の例では、プレーヤキャラクタ４ａと敵キャラクタ１０ｆのみが所属していることになる。そして、ループＣを実行して新たなキャラクタが追加されると、当該新たなキャラクタもループＣの処理対象となる。図５の例では、ステップＳ８２〜Ｓ８４によりプレーヤキャラクタ４ａの味方であるプレーヤキャラクタ４ｂが追加登録され、プレーヤキャラクタ４ｂについてもループＣは実行される。

プレーヤキャラクタ４ｂについてループＣが実行されると、今度はステップＳ８６〜Ｓ８８により敵キャラクタ１０ｇが接敵グループに追加登録される。そして、やはり敵キャラクタ１０ｇもループＣの処理対象となる。敵キャラクタ１０ｇについてループＣが実行されると、今度はステップＳ８２〜Ｓ８４により敵キャラクタ１０ｈが接敵グループに追加登録され、この敵キャラクタ１０ｈもループＣの処理対象となる。敵キャラクタ１０ｈについてもループＣが実行されるが、敵キャラクタ１０ｈの近場にいる味方も、敵キャラクタ１０ｈをロックオンしている他プレーヤキャラクタも見つからないので、新たなキャラクタは追加されない。

ここに至って、ループＢ処理対象キャラクタの接敵グループに所属する全てのキャラクタについてループＣが実行されたことになり、サーバシステム１１００は次に、ループＢ処理対象キャラクタの新規作成した接敵グループに含まれているキャラクタの所属チームをカウントする。

もし、１つのチームのキャラクタで当該接敵グループが構成されているならば（ステップＳ９２のＹＥＳ）、今回のループＢのステップＳ６２で作成した接敵グループを削除して（ステップＳ９４）、ループＢを終了する（ステップＳ９６）。もし、複数のチームのキャラクタで当該接敵グループが構成されているならば（ステップＳ９２のＮＯ）、ステップＳ９４をスキップしてループＢを終了する（ステップＳ９６）。

接敵グループに未所属の全てのキャラクタについてループＢを実行したならば、図１７に戻って、サーバシステム１１００は次に接敵グループ管理処理を実行する（ステップＳ１００）。

図２０は、本実施形態における接敵グループ管理処理の流れを説明するためのフローチャートである。同処理において、サーバシステム１１００は、先ず接敵グループ登録データ７６０を参照して（図１３参照）、グループ作成日時７６２から所定時間（例えば、３秒）が経過している接敵グループを抽出し、それらの交戦状態フラグ７６３を「１（交戦状態）」に変更する（ステップＳ１０２）。

次に、キャラクタ別ステータスデータ７１０を参照して（図１４参照）、残耐久値７１９が「０」に達しているキャラクタを行動不能と判断して、接敵グループからの登録を抹消する（ステップＳ１０４）。すなわち、行動不能となったプレーヤキャラクタ４のキャラクタＩＤを所属していた接敵グループのグループ所属キャラクタＩＤリスト７６５、第１サブグループ所属キャラクタＩＤリスト７６７、第２サブグループ所属キャラクタＩＤリスト７６９からそれぞれ削除する（図１３参照）。

次に、サーバシステム１１００は、接敵グループ毎にループＤを実行する（ステップＳ１０６〜Ｓ１１２）。
ループＤでは、先ず、処理対象接敵グループに登録済のキャラクタのうち、最寄りの同じ接敵グループのキャラクタから離脱判定距離２６を越えて離れたキャラクタを抽出する（ステップＳ１０８）。このとき、交戦状態フラグ７６３（図１３参照）が「０（非交戦状態）」の接敵グループについては離脱判定距離２６を近場範囲２４と同距離とし、交戦状態フラグ７６３が「１（交戦状態）」の接敵グループについてはプレイ中のゲームステージのゲーム空間設定データ５１１（図１２参照）の離脱判定距離設定値５１６を適用する。

そして、抽出したキャラクタのキャラクタ別行動ログ７３０を参照して（図１５参照）、離脱判定距離２６を越えて離れた状態の継続時間を算出する。そして、算出した継続時間が所定の見逃し条件に相当する所定時間に達したキャラクタであって、同じ接敵グループの何れのキャラクタからもロックオンされていないキャラクタを検索して、当該キャラクタを処理対象の接敵グループから登録抹消する（ステップＳ１１０）。

ステップＳ１１０の処理を換言すると、過去の所定時間の間に交戦状態と判定された当該接敵グループ（交戦グループ）に含まれていたキャラクタについては、当該従前の接敵グループ（交戦グループ）に含まれていた他のキャラクタとの間の距離が離脱判定距離２６以内の場合、離脱判定距離２６以内の他のキャラクタと同じ接敵グループに含めて検出する処理である、ということもできる。

そして、全ての接敵グループについてループＤを実行したならば（ステップＳ１１２）、サーバシステム１１００は、次に、同じキャラクタが重複して登録されている接敵グループすなわち所属するキャラクタが共通する接敵グループを連結対象接敵グループ候補として検索し、該当する接敵グループをグループ作成日時７６２が古い方の１つの接敵グループに統合する（ステップＳ１１４）。すなわち、グループ作成日時７６２が新しい方の接敵グループから共通しているプレーヤキャラクタ４を登録抹消して除外し、グループ作成日時７６２が古い方の接敵グループに登録して当該グループに所属している状態にする。これで、各接敵グループの所属キャラクタが最新の状態に更新されて増減した状態で、１つの交戦域とみなせる範囲内のキャラクタ群を接敵グループとして正しく検出することができる。なお、ステップＳ１１４は交戦状態の接敵グループ（交戦グループ）に限定して実行するとしてもよい。

次いで、サーバシステム１１００は、全所属キャラクタのチームが同じになった接敵グループを抹消する（ステップＳ１１６）。すなわち、対敵していた２つのチームのうち一方のチームのキャラクタが全滅している接敵グループの接敵グループ登録データ７６０を削除する（図１３参照）。

更に、サーバシステム１１００は、所属するキャラクタの数が「０」になった接敵グループを抹消して（ステップＳ１１８）、接敵グループ管理処理を終了する。

図１７に戻って、次にサーバシステム１１００は接敵グループ報知処理を行う（ステップＳ１３０）。

図２１は、接敵グループ報知処理の流れを説明するためのフローチャートである。
同処理において、サーバシステム１１００は、接敵グループ毎にループＥを実行する（ステップＳ１３２〜Ｓ１４２）。
具体的には、ループＥにおいて、サーバシステム１１００は先ず処理対象の接敵グループからチーム別のサブグループすなわち第１サブグループと第２サブグループとを抽出する（ステップＳ１３４）。ここで、サブグループを、近場条件を満たすグループ単位で細分化して抽出してもよいし、接敵グループが検出されているため、接敵グループのうちのチーム別のキャラクタグループの単位で抽出してもよい。これで、第１サブグループ所属キャラクタＩＤリスト７６７と、第２サブグループ所属キャラクタＩＤリスト７６９とが最新状態に更新される。これらのリスト間の登録キャラクタ数の差が、その接敵グループにおけるチーム間のキャラクタの多寡にあたる。

次に、サーバシステム１１００は、報知先キャラクタ別（業務用ゲーム装置１３００別）に相対方位と存在報知体３４（図７参照）の表示形態を設定する（ステップＳ１３６）。このとき、存在報知体３４の表示形態は、第１サブグループ所属キャラクタＩＤリスト７６７と、第２サブグループ所属キャラクタＩＤリスト７６９とを参照して接敵グループに含まれる各チーム間の所属キャラクタ数の多寡に応じて決定される。設定内容は、存在報知体制御データ７８０に格納する（図１３参照）。

次に、サーバシステム１１００は、マップ表示Ｗ４にて表示される処理対象接敵グループの全所属キャラクタのキャラクタマーカ３６を囲む位置報知体３８の表示位置と表示形態とを設定する（ステップＳ１３８；図８参照）。このとき、位置報知体３８の表示形態は、第１サブグループ所属キャラクタＩＤリスト７６７と、第２サブグループ所属キャラクタＩＤリスト７６９とを参照して接敵グループに含まれる各チーム間の所属キャラクタ数の多寡に応じて決定される。設定内容は、位置報知体制御データ７８２としてプレイデータ７００に格納さする（図１３参照）。

次に、サーバシステム１１００は集中報知体３９を設定する（ステップＳ１４０；図８参照）。すなわち、処理対象接敵グループの所属キャラクタのキャラクタ別ステータスデータ７１０のロックオン対象キャラクタＩＤ７２４を照合して（図１４参照）、複数のキャラクタからロックオンされているキャラクタを抽出し、ロックオンされている数をカウントし、プレイデータ７００に集中報知体制御データ７８４を生成する（図１３参照）。

全ての接敵グループについてループＥを実行したならば、各業務用ゲーム装置１３００にて存在報知体３４を表示させ（ステップＳ１４４）、また位置報知体３８が表示されたマップ表示Ｗ４を表示させる（ステップＳ１４６）。更に、マップ表示Ｗ４に集中報知体３９を表示させて（ステップＳ１４８）、接敵グループ報知処理を終了する。

図１７に戻って、ゲーム終了条件を満たしたならば（ステップＳ１６０のＹＥＳ）、サーバシステム１１００は各プレーヤキャラクタ４の行動ログの記録を終了し（ステップＳ１６２）、対戦結果の発表を行う（ステップＳ１６４）。

そして、サーバシステム１１００は、キャラクタ別行動ログ７３０（図１３参照）を元にして各業務用ゲーム装置１３００及び／又はターミナル装置１３９０にて、リプレイ表示させる（ステップＳ１６６）。リプレイ表示は、公知技術を適宜流用することができる。但し、リプレイ中もステップＳ５０，Ｓ１００，Ｓ１３０と同様にして、接敵グループ検知処理と、接敵グループ管理処理と、接敵グループ報知処理とを実行し、マップ表示Ｗ４等を表示させる。
リプレイが完了すると、サーバシステム１１００は一連の処理を終了する。

以上、本実施形態によれば、チーム対戦型オンラインマルチプレイゲームにおいて、敵味方が交戦可能に接近した前線すなわち接敵グループの存在を存在報知体３４で示し、ゲーム空間中の具体的な位置をマップ表示内の位置報知体３８で示すことができる。

しかも、報知される接敵グループは、単に武器を向け合う関係をなしているキャラクタの対（ペア）に限らず、それらの近場にいて直ぐに駆けつけて支援が可能な味方も含めた、１つの交戦域で交戦しているとみなせるキャラクタ群およびその交戦域として検知される。
故に、一対一の対敵関係（最小構成の接敵グループ）の存在や位置を報知しても初心者では情報過多になり却って状況を理解できない恐れがあるが、本実施形態ではそうした心配はない。また、初心者でも駆けつけて支援が可能な状況も含めた総合的な戦況を一瞥で理解でき、すみやかに勝利のための行動をとることができるようになる。更には、存在報知体３４や位置報知体３８、集中報知体３９の表示形態により、接敵グループ毎の数的な有利／不利が一目瞭然となる。よって、自分が何処に駆けつけて支援すれば最も効果的であるかを初心者でも直ぐに理解することができる。

こうした工夫は、初心者プレーヤのゲームへの習熟と戦術的技量の向上とを促す。ユーザ層全体の技量が底上げされれば、やり応えのある対戦が楽しめる機会も増えるであろう。そして、結果的に当該ゲームへの大きな魅力の１つとなるであろう。

〔変形例〕
以上、本発明を適用した実施形態について説明したが、本発明を適用可能な形態は上記形態に限定されるものではなく、適宜構成要素の追加・省略・変更を施すことができる。

［その１］
例えば、上記実施形態ではゲームシステムをクライアントサーバシステムにて構成したが、複数の業務用ゲーム装置１３００がピアツーピア接続してゲームシステムを構成するとしてもよい。その場合、上記実施形態においてサーバシステム１１００が担っていた機能を適宜業務用ゲーム装置１３００間で分散実行する構成とすることができる。あるいは、１台の業務用ゲーム装置１３００がホスト機として、サーバシステム１１００が担っていた機能をも実行することとしてもよい。

［その２］
また、上記実施形態では、ゲーム進行制御や、接敵グループの検知・管理・報知に係る制御を専らサーバシステム１１００にて実行する構成としたが、図２２に示すように、接敵グループの検知・管理・報知に関する制御を、サーバシステム１１００に代えて各業務用ゲーム装置１３００やターミナル装置１３９０にて実現させる構成も可能である。

［その２］
また、上記実施形態では、位置報知体３８を報知対象の接敵グループのキャラクタマーカ３６を全て囲う単一の矩形形状としたが、別の表示態様としてもよい。例えば、図２３（１）に示すように、スナイパー（長距離攻撃可能な装備を限定的に与えられている特別なプレーヤキャラクタ；他のプレーヤキャラクタが明らかに交戦不可能な位置から、一方的に攻撃可能な性能を持つキャラクタ）に相当するプレーヤキャラクタ４ｄが接敵グループ１６に含まれる場合、上記実施形態のように接敵グループ１６を単一の矩形形状の位置報知体３８で表示する態様とすると、マップ表示Ｗ４において複数の位置報知体３８同士が重なり合って却って見難くなる場合がある。

そこで、図２３（２）に示すように、位置報知体３８を複数のサブ報知体の集合としてもよい。すなわち、プレーヤキャラクタ４ｄのキャラクタマーカ３６ｄを第１サブ位置報知体３８ａで囲って表示して、それ以外の接敵グループ１６の所属キャラクタのキャラクタマーカ３６を第２サブ位置報知体３８ｂで囲って表示し、これらの報知体を連結する第３サブ位置報知体３８ｃを表示するとしてもよい。

［その３］
また、上記実施形態では、敵味方を混合して接敵グループの検知・管理・報知を行ったが、それぞれの敵についてのみ接敵グループを検知・管理・報知する構成としてもよい。この場合、存在報知体３４は接敵状態にある敵グループの存在を報知し、位置報知体３８はその位置を報知することとなる。例えば、図８のマップ表示Ｗ４と同じ状況を、当該構成を適用してチーム「ＲＥＤ」の業務用ゲーム装置１３００でマップ表示すると、図２４のマップ表示Ｗ６のようになる。

［その４］
また、上記実地形態では対戦に登場するキャラクタは、全てプレーヤキャラクタ４として説明したが、コンピュータが自動で行動制御するＮＰＣ（ノンプレーヤキャラクタ）を含む構成も可能である。

４（４ａ、４ｂ、…）…プレーヤキャラクタ
１０（１０ａ，１０ｂ，…）…敵キャラクタ
１６…接敵グループ
２０…索敵範囲
２２…射程範囲
２４…近場範囲
２６…離脱判定距離
３０…方位表示
３２…マップ操作タグ
３４…存在報知体
３６…キャラクタマーカ
３８…位置報知体
３９…集中報知体
２００ｓ…サーバ処理部
２１０…ゲーム管理部
２１２…リプレイ表示制御部
２２０…接敵グループ検出部
２２２…第１サブグループ検出部
２２４…第２サブグループ検出部
２２６…状態判定部
２４０…報知制御部
２４２…多寡別報知制御部
２４４…存在報知制御部
２４６…位置報知制御部
２４８…集中報知制御部
５００ｓ…サーバ記憶部
５０５…ゲームサーバプログラム
５１０…ゲーム初期設定データ
５１４…索敵範囲設定値
５１５…近場範囲設定値
５１６…離脱判定距離設定値
５１７…マップデータ
５２０…キャラクタ初期設定データ
７００…プレイデータ
７０１…参加プレーヤＩＤリスト
７０４…使用ステージＩＤ
７１０…キャラクタ別ステータスデータ
７１１…プレーヤＩＤ
７１３…キャラクタ種類
７１４…所属チームＩＤ
７２０…索敵済キャラクタＩＤリスト
７２２…攻撃対象候補キャラクタＩＤリスト
７２４…ロックオン対象キャラクタＩＤ
７３０…キャラクタ別行動ログ
７６０…接敵グループ登録データ
７６１…接敵グループＩＤ
７６２…グループ作成日時
７６３…交戦状態フラグ
７６５…グループ所属キャラクタＩＤリスト
７６７…第１サブグループ所属キャラクタＩＤリスト
７６９…第２サブグループ所属キャラクタＩＤリスト
７８０…存在報知体制御データ
７８２…位置報知体制御データ
７８４…集中報知体制御データ
１１００…サーバシステム
１１５０…制御基板
１３００…業務用ゲーム装置

Claims (10)

1. 第１チームに所属する複数の第１キャラクタと、第２チームに所属する複数の第２キャラクタとが仮想空間を移動して対戦するゲームをコンピュータシステムに実行させるためのプログラムであって、
   前記第１キャラクタ及び前記第２キャラクタが、接敵しているキャラクタのグループの条件である接敵グループ条件を満たす場合に、当該接敵グループ条件を満たす前記第１キャラクタ及び前記第２キャラクタを接敵グループとして検出する接敵グループ検出手段、
   前記接敵グループ検出手段の検出に応じた報知を行う報知制御手段、
   として前記コンピュータシステムを機能させるためのプログラム。
2. 前記接敵グループ条件には、対敵した状況にあることを示す所与の対敵状況条件が少なくとも含まれ、
   前記接敵グループ検出手段は、前記第１キャラクタ及び前記第２キャラクタのうちの一方が他方に対して前記対敵状況条件を満たす関係にある当該第１キャラクタ及び当該第２キャラクタを前記接敵グループに含めて検出する、
   請求項１に記載のプログラム。
3. 前記対敵状況条件には、対敵した状況の距離条件である所与の対敵距離条件が少なくとも含まれる、
   請求項２に記載のプログラム。
4. 前記接敵グループ検出手段は、前記接敵グループ条件を満たす関係にある当該第１キャラクタ及び当該第２キャラクタにとって近場条件を満たす同一チームのキャラクタを前記接敵グループに含めて検出する、
   請求項１〜３の何れか一項に記載のプログラム。
5. 前記接敵グループ検出手段は、近場条件を満たす前記第１キャラクタをグループとした１体以上の前記第１キャラクタのグループである第１チーム近場グループのうちの何れかの前記第１キャラクタと、近場条件を満たす前記第２キャラクタをグループとした１体以上の前記第２キャラクタのグループである第２チーム近場グループのうちの何れかの前記第２キャラクタとの間が所与の対敵状況条件を満たす関係にある第１チーム近場グループおよび第２チーム近場グループをまとめて前記接敵グループとして検出する、
   請求項１に記載のプログラム。
6. 前記接敵グループ検出手段は、Ｎ個の前記第１チーム近場グループとＭ個の前記第２チーム近場グループとにおいて（Ｎ≧１，Ｍ≧１，かつＮ＋Ｍ≧３）、前記対敵状況条件を満たす関係にあるキャラクタ同士がグループ間で連鎖するように存在する場合に、当該Ｎ個の前記第１チーム近場グループと当該Ｍ個の前記第２チーム近場グループとをまとめて１つの接敵グループとして検出する、
   請求項５に記載のプログラム。
7. 前記報知制御手段は、前記接敵グループに含まれる各チームのキャラクタの相対的な多寡に応じた報知を行う多寡別報知制御手段を有する、
   請求項１〜６の何れか一項に記載のプログラム。
8. 前記報知制御手段は、前記接敵グループに含まれる前記第１キャラクタ及び／又は前記第２キャラクタの位置を報知する位置報知制御手段を有する、
   請求項１〜７の何れか一項に記載のプログラム。
9. 前記接敵グループ検出手段は、従前に当該接敵グループに含まれており、且つ、所与の継続条件を満たすキャラクタを、継続して当該接敵グループに含めて検出する、
   請求項１〜８の何れか一項に記載のプログラム。
10. 第１チームに所属する複数の第１キャラクタと、第２チームに所属する複数の第２キャラクタとが仮想空間を移動して対戦するゲームを実行するゲームシステムであって、
    前記第１キャラクタ及び前記第２キャラクタが、接敵しているキャラクタのグループの条件である接敵グループ条件を満たす場合に、当該接敵グループ条件を満たす前記第１キャラクタ及び前記第２キャラクタを接敵グループとして検出する接敵グループ検出手段と、
    前記接敵グループ検出手段の検出に応じた報知を行う報知制御手段と、
    を備えたゲームシステム。

Images