〔第1実施形態〕
本発明を適用した第1実施形態として、チーム対戦型のマルチプレイゲームを実行する例を説明する。
図1は、本実施形態におけるゲームシステムの構成の一例を示す図である。本実施形態のゲームシステムは、クライアントサーバ型システムである。すなわち、それぞれ通信回線9に接続することのできるサーバシステム1100と、プレーヤがゲームプレイするために使用する複数の業務用ゲーム装置1300と、ゲームプレイ画面やリプレイ映像の表示、ユーザ登録などを行うためのターミナル装置1390とを含む。
通信回線9は、データ通信が可能な通信路を意味する。すなわち、通信回線9とは、直接接続のための専用線(専用ケーブル)やイーサネット(登録商標)等によるLAN(Local Area Network)の他、電話通信網やケーブル網、インターネット等の通信網を含む意味であり、また、通信方法については有線/無線を問わない。
サーバシステム1100は、例えば、本体装置1101と、キーボード1106と、タッチパネル1108と、ストレージ1140とを備える。本体装置1101には制御基板1150が搭載されている。この制御基板1150には、CPU(Central Processing Unit)1151やGPU(Graphics Processing Unit)、DSP(Digital Signal Processor)などの各種マイクロプロセッサ、ASIC(Application Specific Integrated Circuit)、FPGA(Field-Programmable Gate Array)、VRAMやRAM,ROM等の各種ICメモリ1152、通信装置1153が搭載されている。
そして、サーバシステム1100は、制御基板1150で所定のプログラム及びデータに基づいて演算処理することにより、1)固有のアカウントを付与するとともに電子決済用の決済口座を開設するユーザ登録機能と、2)決済口座への入金や、プレイ対価やアイテム課金等に対する決済口座からの課金精算などを行う電子決済機能と、3)業務用ゲーム装置1300から操作入力情報を取得し、業務用ゲーム装置1300へゲームを実行するのに必要なプログラムやデータを提供するゲーム管理機能と、を実現する。
なお、図1の例では、サーバシステム1100は単体として記しているが、これらの各種機能を分担する複数のブレードサーバを搭載して、相互に内部バスを介してデータ通信可能に接続した構成であっても良い。或いは、離れた場所に設置された独立した複数のサーバを、通信回線を介してデータ通信させることで、全体としてサーバシステム1100として機能させる構成であっても良い。
図2は、業務用ゲーム装置1300の構成例を示す正面図である。
業務用ゲーム装置1300は、通信回線9に接続してサーバシステム1100にアクセスすることができるコンピュータシステムであり電子装置(電子機器)である。業務用ゲーム装置1300は、ゲームセンターなどの店舗に設置されており、電子決済用媒体6を用いてプレイ対価の支払いを電子決済できる。
電子決済用媒体6は、仮想通貨(電子マネー:有価情報)による電子決済システムを利用するためのキーデータを記憶する。当該キーデータは、専用の読取装置を用いることで読み取り可能とされる。電子決済用媒体6は情報をコンピュータ読み取り可能に記憶する媒体であれば何れでもよく、本実施形態ではICカードのような専用の媒体とするが、スマートフォンのような装置であってもよい。本実施形態の業務用ゲーム装置1300は、電子決済用媒体6を用いた電子決済に対応しており、電子決済用媒体6から情報を読み取る装置として媒体読取装置1344を有している。すなわち、業務用ゲーム装置1300は対価支払装置として機能する。
キーデータとしては、例えば、ユーザ登録時に設定される固有のアカウントや、固有の媒体ID(例えば、ICカードならばカードID、スマートフォンなどの情報機器ならばMACアドレスやSIMカードIDなどの機器固有の情報)などを適宜設定することができる。
本実施形態では、サーバシステム1100が提供する所定のユーザ登録手続きを経て固有のアカウントを登録すると、当該アカウントに関連づけられる決済口座が開設され、別途入手した電子決済用媒体6の固有の媒体IDをアカウントと関連付けて登録することができる。電子決済用媒体6を登録することで、あたかもプリペイドカードの如く、電子決済用媒体6を、プレイ対価の支払いや、ゲーム内で使用できるアイテム等の購入などの課金精算に使用できるようになる。
本実施形態における業務用ゲーム装置1300は、ジョイスティック1302と、ボタンスイッチ1304と、画像表示デバイス兼接触位置入力デバイスとして機能するタッチパネル1306と、スピーカ1310と、入金装置1330と、電子決済用媒体6からデータの読み取りや書き込みができる媒体読取装置1344と、制御基板1350と、を備える。
制御基板1350には、CPU1351や、GPU,DSPなどの各種マイクロプロセッサ、VRAM,RAM,ROM等の各種ICメモリ1352と、通信回線9に通信接続するための通信装置モジュール1353、I/Fコントローラ1357(インターフェイスコントローラ)などが搭載されている。
I/Fコントローラ1357には、例えば、1)タッチパネル1306のドライバ回路、2)ジョイスティック1302及びボタンスイッチ1304からの信号を受信する回路、3)スピーカ1310へ音声信号を出力する出力アンプ回路、4)入金装置1330や媒体読取装置1344への信号入出力回路、などが搭載されている。
そして、これら制御基板1350に搭載されている各要素は、それぞれバス回路などを介して電気的に接続され、データの読み書きや信号の送受信が可能に接続されている。なお、制御基板1350の一部または全部をASICやFPGAにて実現する構成でもよい。
入金装置1330は、従来の業務用ゲーム装置1300と同様に、50円や、100円、500円などの硬貨のうち特定種類の硬貨での入金を受け付ける装置である。
制御基板1350は、ゲームプログラムを実行して演算処理を実行し、ジョイスティック1302やボタンスイッチ1304,タッチパネル1306からの操作入力に応じて業務用ゲーム装置1300の各部を制御してゲームプレイを可能にする。本実施形態の業務用ゲーム装置1300は、必要なプログラムや各種設定データを予めICメモリ1352に記憶しているものとするが、起動の都度、サーバシステム1100からダウンロードする構成としても良い。
制御基板1350の制御により、業務用ゲーム装置1300は、ジョイスティック1302やタッチパネル1306などを介した操作入力の結果をサーバシステム1100へ逐次送信する一方で、ゲームをプレイするための各種データをサーバシステム1100から受信する。そして、ゲーム画面の画像を生成してタッチパネル1306に表示させ、効果音や操作音の音信号を生成してスピーカ1310から放音する。つまり、プレーヤはタッチパネル1306に表示されるゲーム画面を見て、スピーカ1310から流れるゲーム音を聞きながら、ジョイスティック1302等を操作してゲームプレイを楽しむことができる。
なお、入金装置1330や媒体読取装置1344は筐体1301と一体の構成に限らず、外付けで通信接続可能な構成としてもよい。例えば、図1に示すように、業務用ゲーム装置1300と通信接続されたターミナル装置1390に、入金装置1330や媒体読取装置1344を設ける。そして、このターミナル装置1390にて、ゲーム参加登録手続きとして、使用する業務用ゲーム装置1300の指定と、プレイ対価の支払いとを行う構成としてもよい。
なお、業務用ゲーム装置1300は、家庭用据置型ゲーム装置や、携帯型ゲーム装置、ゲームアプリケーションを実行できるスマートフォン、パソコン、タブレット型コンピュータ、ウェアラブルコンピュータなどの情報機器に置き換えることができる。勿論、その場合、装置の設定場所や使用場所はゲームセンターなどの店舗に限らない。
図3は、本実施形態のゲームについて説明する図である。
本実施形態のゲームは、チーム対戦型オンラインマルチプレイゲームである。各プレーヤは、各々業務用ゲーム装置1300を使用し、自身が使用するプレーヤキャラクタ4a,4b,…を各1体選択し複数のチームに分かれる。本実施形態はチーム「RED」とチーム「BLUE」の2チームの対戦形式としているが、3チーム以上のチームが一斉にゲームに参加する構成としてもよい。チームを構成する人数も適宜設定可能である。また、1プレーヤが操作するプレーヤキャラクタ4の数は複数でもよい。なお、以下、プレーヤキャラクタ4a,4b,…を区別しない場合は包括して「プレーヤキャラクタ4」と称する。
仮想3次元空間に構成されたゲーム空間(この場合、戦場)が用意される。ゲーム空間に様々な障害物7が配置され、更に破壊可能なチーム別の拠点8r、8bが用意される。そして、ゲーム空間には、各プレーヤキャラクタ4のキャラクタモデルが配置され、それぞれのプレーヤの操作入力に応じて移動・攻撃・防御の行動をするように制御される。また、図示されていないが、プレーヤキャラクタ4それぞれに専用の仮想カメラが用意されており、つねに対応するプレーヤキャラクタ4を撮影するように制御される。
各仮想カメラで撮影されたゲーム空間画像はレンダリングされ、幾つかの情報表示が合成されてゲーム画面を構成する。そして、ゲーム画面は、対応するプレーヤキャラクタ4への操作入力がなされている業務用ゲーム装置1300のゲーム画面として表示される。
銃撃戦で被弾したプレーヤキャラクタ4は、被弾に応じたダメージが耐久値から減算され、残耐久値が「0」になると行動不能すなわち撃破されたものとされる。各チームは各々の拠点8r,6bから出撃して、障害物7を盾にして銃撃戦を展開する。他チームを全滅させるか、他チームの拠点を破壊すると勝利となる。
さて、本実施形態では、他チームのプレーヤキャラクタ4を攻撃するには、1)敵を認識し、2)攻撃可能範囲に捕らえて、3)攻撃目標として選択し、4)攻撃行動を始める、4ステップを経る。
図4は、ゲーム空間の一部を俯瞰して各キャラクタの位置関係例を簡略表記した図である。各プレーヤキャラクタ4(4a,4b,…)には、それぞれのキャラクタ種類に応じた索敵能力(他キャラクタの存在を検知し敵味方を識別する能力)が備えられている。索敵能力が及ぶ範囲を索敵範囲20と称する。図4の例では、代表して、プレーヤキャラクタ4aについてのみ索敵範囲20を表記している。
索敵範囲20に、プレーヤキャラクタ4aにとって他チームのプレーヤキャラクタ4(以降、理解し易いように他チームのプレーヤキャラクタを「敵キャラクタ」と称する)が位置すれば、プレーヤキャラクタ4aはレーダで敵キャラクタを検知したものとされる。図4の例では、プレーヤキャラクタ4aは、他チームのプレーヤキャラクタ4fを敵キャラクタとして検知している。
索敵範囲20にて検知されている敵キャラクタのうち、更に所持する武器の射程範囲22に入っている敵キャラクタが攻撃対象候補となる。図4の例では、他チームのプレーヤキャラクタ4f(敵キャラクタ10f)がプレーヤキャラクタ4aの攻撃対象候補となっている。
そして、プレーヤが攻撃対象候補のうち一体又は複数体を攻撃目標として選択操作すると、以降は選択された敵キャラクタが攻撃目標として自動追尾される。これを「ロックオン」と称する。図4の例では、プレーヤキャラクタ4aが、他チームのプレーヤキャラクタ4f(敵キャラクタ10f)をロックオンしている。
ロックオンした敵キャラクタがあってプレーヤが所定の攻撃操作を入力すると、プレーヤキャラクタ4はロックオンした敵キャラクタに対して攻撃行動をとる。本実施形態では射撃する。図4の例では、プレーヤキャラクタ4aが、他チームのプレーヤキャラクタ4f(敵キャラクタ10f)を射撃する。
なお、ロックオンの仕様はゲーム内容によっては省略することもできる。また、ロックオンした敵キャラクタ10へは自動照準されるとしても良いし、自動照準はせずに別途プレーヤによる手動照準操作を要する構成としてもよい。
本実施形態では、索敵と攻撃対象候補の認識は自動で行われるので、プレーヤは自分が操作するプレーヤキャラクタ4を適当な場所に移動させ、攻撃対象候補の中からロックオンの対象を選択し、攻撃操作入力をすれば、他チームのプレーヤキャラクタ4を攻撃することができる。なお、拠点8r、8fもプレーヤキャラクタ4と同様にして攻撃することができる。
[接敵の説明]
さて、本実施形態では、射程範囲22に1体以上の敵キャラクタ10を捕らえ、その何れかをロックオン(選敵)しているプレーヤキャラクタ4は、「対敵状況条件」を満たしており、前線で敵キャラクタと「接敵」していると見なされる。なお、対敵状況条件は、ロックオンに限らずゲーム内容に応じて適宜設定可能である。例えば、ロックオンが手動操作で行われる構成であれば、射程範囲22に敵キャラクタ10を捕らえている段階で対敵状況条件を満たすと判定してもよい。更に言えば、索敵範囲20に敵キャラクタ10を検知した段階で対敵状況条件を満たすと判定してもよい。
接敵関係の最小構成は、ロックオンしているプレーヤキャラクタ4と、ロックオンされているプレーヤキャラクタ4とで構成される。図4の例では、プレーヤキャラクタ4aと、他チームのプレーヤキャラクタ4f(敵キャラクタ10f)とが最小構成の接敵関係を構成する。
こうした接敵関係のゲーム空間における位置関係と規模は、戦況を理解し、勝利のために速やかな行動をするうえで極めて重要である。そこで、本実施形態ではプレーヤに向けて接敵関係をなしているプレーヤキャラクタ4に関する情報を提供する。但し、情報提供にあたって最小構成の接敵関係を個別に扱うと、却って提供する情報が増えて初心者には理解し難くなる恐れがある。また、上級者であれば、最小構成の接敵関係の近傍にいる味方が駆けつけて援護する可能性を考慮に入れて戦況を判断することができるが、初心者にはそうした熟練の判断が難しい。
そこで、本実施形態では、隣接する接敵関係同士や、駆けつけ可能なプレーヤキャラクタ4の存在を考慮して、概況として1つの交戦域とみなせる範囲内のキャラクタ群を纏めて「接敵グループ」と見なし、接敵グループに関する情報をプレーヤへ提供する。
図5は、本実施形態における接敵グループの検出原理について説明する図である。
概況として1つの交戦域とみなせる範囲内に位置するキャラクタ群の接敵グループは、1)行動可能なプレーヤキャラクタ4別に着目して、対敵状況条件を満たすキャラクタの組合せ、すなわち最小構成の接敵関係を成すキャラクタの組み合せを見つけて始原となる接敵グループを作成し、2)当該接敵グループを構成するプレーヤキャラクタ4それぞれの周囲にいる当該プレーヤキャラクタ4にとっての味方を当該接敵グループに加え、3)当該接敵グループに加えられたプレーヤキャラクタ4と更に対敵状況条件を満たすプレーヤキャラクタ4を当該接敵グループに加え、4)以下、新たなキャラクタの追加がなくなるまで上記2)と上記3)と繰り返す、ことにより検出する。
換言すると、「(条件A):対敵状況条件を満たす敵対するキャラクタ同士であること」「(条件B):条件Aを満たすキャラクタにとって味方であり且つ近場にいるキャラクタであること」「(条件C):条件Bを満たすキャラクタが条件Aを満たす場合に連鎖しているとして同グループにまとめること」を本実施形態では「接敵グループ条件」として、当該接敵グループ条件を満たすプレーヤキャラクタ4を接敵グループとして検出する。
具体的には、図5において、行動可能なプレーヤキャラクタ4として、例えばチーム「RED」のプレーヤキャラクタ4aに着目すると、その索敵範囲20(他キャラクタ認識可能範囲)の内に敵キャラクタ10fが存在し、プレーヤが当該敵キャラクタ10fを攻撃目標として選択してロックオンしている。よって、プレーヤキャラクタ4aと敵キャラクタ10fとは対敵状況条件を満たす(条件A)ため、始原の接敵グループ16が作成される(図中、丸囲み数字「1」)。この段階の接敵グループ16は、接敵グループとしては最小構成である。
次に、始原の接敵グループ16を構成するキャラクタそれぞれの近傍に位置する当該キャラクタにとっての味方を当該接敵グループに加える(条件Bの判断)。
具体的には、各プレーヤキャラクタ4(4a,4b,…)には、近場条件である近場範囲24が設定されている。当該範囲は、言うならばいつでも支援に駆けつけられるチームメイトを判定するための近場条件である。近場範囲24の距離条件は索敵範囲20より短い距離とすると好適であり、例えば、索敵範囲20を「300m」とすれば近場範囲24は「100m程度」とすると好適である。そして、接敵グループを構成するプレーヤキャラクタ4の近場範囲24内に味方が存在すると、その味方を同じ「接敵グループ」に属するとみなす。
図5の例において、先ず始原の接敵グループ16のプレーヤキャラクタ4aに着目すると、プレーヤキャラクタ4aの近場範囲24には同チームのプレーヤキャラクタ4bが存在するため、当該キャラクタ4bをプレーヤキャラクタ4aと同じ接敵グループ16に追加登録する(図中、丸囲み数字「2」)。プレーヤキャラクタ4bが条件Bを満足するとして追加登録される。
一方、始原の接敵グループ16のうちの敵キャラクタ10fの近場範囲24には同チームの敵キャラクタが存在しないので、敵キャラクタ10fの近場にいる味方として同じ接敵グループ16に追加登録される敵キャラクタは無い。したがって、この段階では、接敵グループ16に所属するキャラクタは3体となる。
次に条件Cを判断する。条件Bを満足するプレーヤキャラクタ4bに着目すると、敵キャラクタ10g(プレーヤキャラクタ4g)が条件Aである対敵状況条件を満たすので当該敵キャラクタ10gは条件Cを満たすとして、同じ接敵グループ16に加えられる(図中、丸囲み数字「3」)。つまり、対敵状況条件を満たす関係にあるキャラクタ同士が連鎖していると見なせるのでグループに加える。この段階では、接敵グループ16に所属するキャラクタは4体となる。
次に、新たに追加した敵キャラクタ10gについて条件A,B,Cを判断する。敵キャラクタ10gの近場範囲24には敵キャラクタ10h(プレーヤキャラクタ4h)が居るので追加登録される(条件B。図中、丸囲み数字「4」)。この段階では、接敵グループ16に所属するキャラクタは5体となる。
次に、新たに追加した敵キャラクタ10hについて条件A,B,Cを判断する。敵キャラクタ10hと対敵状況条件(条件A)を満たすプレーヤキャラクタ4は居ない。また、敵キャラクタ10hの近場範囲24には敵キャラクタ10gが居るが(条件B)、既に接敵グループ16に所属しているので追加登録しない。また、条件Cについては敵キャラクタ10hは合致しない。
ここに至って、条件A〜Cの判断が行われて、新たに接敵グループ16に追加されるキャラクタがいなくなったので、接敵グループ16の検知が完了する。
ちなみに、図5の例では、プレーヤキャラクタ4c及びプレーヤキャラクタ4dについては、接敵状況条件を満たす他キャラクタが存在しないので、接敵グループを作ることはない。
本実施形態のこうした接敵グループ16の検出手順は、始原の接敵グループ16を構成するプレーヤキャラクタ4を基点として、対敵状況条件や近場条件を満たすキャラクタを芋づる式に検索して追加登録してゆくと読み換えることができる。
なお、ゲーム空間内に複数の接敵グループが存在し、それらがやがて接近するとそれぞれの接敵グループに所属するキャラクタが重複するようになる。重複するキャラクタで複数の接敵グループが連鎖しているとも表現できる。こうなると、その複数の接敵グループは1つの交戦域とみなせるのでそれらをまとめて1つの接敵グループを統合する。
以上、本実施形態の接敵グループの検出の動的な処理手順の一例を説明したが、接敵グループの検出を静的に説明するならば、次のように説明できる。すなわち、近場条件を満たす同じチームの1体以上のキャラクタ同士を1つのグループ(近場グループ)とした場合に、第1チームに係る複数の第1チーム近場グループと、第2チームに係る複数の第2チーム近場グループとがあるが、N個の第1チーム近場グループとM個の第2チーム近場グループにおいて(N≧1,M≧1,かつN+M≧3)、対敵状況条件を満たす関係にあるキャラクタ同士がグループ間で連鎖するように存在する場合に、当該N個の第1チーム近場グループと当該M個の第2チーム近場グループとをまとめて1つの接敵グループとして検出する、ということができる。
図5の例では、敵キャラクタ4fの近場グループと、プレーヤキャラクタ4a,4bの近場グループと、敵キャラクタ4g、4hの近場グループとの3つの近場グループが考えられる。そして、これら3つの近場グループに所属する何れかのキャラクタが対敵状況条件を満たすとして連鎖する関係にあるため、まとめて1つの接敵グループとして検出されている。
さて、検知された接敵グループ16はゲーム進行に応じて適宜管理される。
図6は、接敵グループの管理について説明するための図である。例えば、図5で例示した状況から、敵キャラクタ10fがプレーヤキャラクタ4aの攻撃により撃破されて戦闘不能・行動不能になった場合、敵キャラクタ10fは接敵グループ16から登録抹消される。
また、敵キャラクタ10hが、離脱条件を満たし、且つ見逃し条件を満たした場合は、前線から後退・逃走したと見做して接敵グループから登録抹消される。
ここで言う「離脱条件」は、ゲーム内容に応じて適宜設定可能である。例えば、接敵グループを構成するキャラクタからの離隔距離であったり、耐久値の残量であったり、残弾数「0」であったり、麻痺などのステータス異常などを1つ又は複数採用することができる。
本実施形態では、離脱条件として接敵グループ16を構成する最寄りの味方からの離脱判定距離26を採用し、接敵グループ16の交戦状況に応じて切り替える。
具体的には、接敵グループ16は一定時間存在すると、或いは当該グループを構成するプレーヤキャラクタ4が攻撃行動を行うと、交戦状況条件を満たして「非交戦状態」から「交戦状態」へ移行したとみなされる。つまり、単に敵と向かい合っている対敵状況よりも遙かに支援要求度の高い状態に変わったとみなされる。そして、非交戦状態の接敵グループ16については離隔判定距離26として近場範囲24と同じ距離を適用し、交戦状態に移行した接敵グループ16については、近場範囲24より広い範囲(例えば、半径200m)を適用する。
また、「見逃し条件」は、敵が見逃してくれる条件である。例えば、離脱条件を満たした状態の継続時間が所定条件を満たした場合や、ロックオンされていない場合、所定の「降伏」行動をしている場合、などを1つ又は複数採用することができる。本実施形態では継続時間を採用する。
例えば、図6の例では、敵キャラクタ10hが、離脱判定距離26以上に離れた状態が、「見逃し条件」とする時間(例えば、5秒)以上継続すると(破線黒矢印)、戦闘離脱したとみなされ、接敵グループ16から登録抹消される。しかし、敵キャラクタ10hが、離脱判定距離26以上に離れたとしても、その継続時間が見逃し条件とする時間に満たなければ登録は抹消されない。例えば、敵の側面または後方に回り込むために一時的に仲間から離れるといったシチュエーションでも、正しく接敵グループ16を捉えることができる。
そして、接敵グループ16を構成するプレーヤキャラクタ4のチームが、当初の複数チームが存在する状態から何れか1つのチームのみの状態に至ると、交戦していた勢力の一方が排除されて交戦が終了したと判断し、当該接敵グループ16それ自体の登録を解除する。当該接敵グループ16の残ったプレーヤキャラクタ4は、何れの接敵グループにも属さない状態に戻る。
[接敵グループの報知についての説明]
本実施形態では、検出・管理された接敵グループ16に関する情報は、ゲーム画面にて各プレーヤに報知される。
図7は、本実施形態における接敵グループ16に関する情報報知例を示す図である。
各プレーヤが使用する業務用ゲーム装置1300のゲーム画面W2には、自身が操作するプレーヤキャラクタ4の1人称視点又は3人称視点のゲーム空間画像が表示される。そして、ゲーム画面W2は、自分のプレーヤキャラクタ4が向いている方角を知るための方位表示30と、マップ表示W4を展開/収納するマップ操作タグ32とが含まれる。なお、マップ表示W4は常時ゲーム画面W2に表示されているとしてもよい。
本実施形態では、接敵グループ16に関する情報報知として、1)方位表示30を用いた接敵グループ16が存在する方位の報知と、2)マップ表示W4を用いた接敵グループ16の位置の報知と、3)方位報知及び位置報知を用いた当該接敵グループにおけるチーム別の相対的なキャラクタの多寡の報知と、を行うことができる。
具体的には、方位表示30には、接敵グループ16別の存在報知体34が表示される。
存在報知体34が示す方位は、ゲーム画像の視点位置から見た相対方位であり、そちらに接敵グループ16が存在していることを示す。
存在報知体34の表示形態は、当該報知体に対応付けられる接敵グループ16におけるチーム別のキャラクタの多寡に応じて決定される。本実施形態では、チーム「RED」とチーム「BLUE」の2チーム対戦なので、接敵グループ16に登録されているキャラクタの多い方の表示色(例えばチームカラー)が設定される。登録されているキャラクタが同数の場合は別の第3の色(無色を含む)が設定される。また、存在報知体34には、対応付けられる接敵グループ16におけるチーム別のキャラクタ数の差の値が表示される。
つまり、存在報知体34により、接敵グループ16の相対方位と、数的有利/不利に関する情報と、がプレーヤに提供される。
図8は、マップ表示における接敵グループ16の位置報知の例を示す図である。
マップ表示W4のデザインは適宜設定可能であるが、例えば、戦場となるゲーム空間を俯瞰した地図としてデザインし、そこに地形の高低差は勿論のこと、障害物7や拠点8r,8bの位置と大きさを簡略して表す。勿論、マップ表示W4のデザインは平面表示でも立体表示でも構わない。そして、マップ表示W4には、行動可能なプレーヤキャラクタ4別のキャラクタマーカ36が表示され、各プレーヤキャラクタ4の位置と向きを逐一表示する。更に、マップ表示W4には、接敵グループ16毎の位置報知体38が表示される。
位置報知体38のデザインは適宜設定可能である。本実施形態では、接敵グループ16の全所属キャラクタのキャラクタマーカ36を囲む矩形領域の輪郭線を表す。これ以外にも、例えば、形状は矩形に限らずその他の多角形や、楕円形、球形、直方体などでもよい。また、輪郭線を表示する形態に限らず領域内を半透明に表示したり、領域の角部(例えば、矩形領域の四つ角)のみを表示するカギ括弧状の表示形態とするなど、演出意図に応じて適宜設定可能である。
また、位置報知体38の表示形態は、当該報知体に対応付けられる接敵グループ16におけるチーム別のキャラクタの相対的な多寡に応じて変更される。
本実施形態では、チーム「RED」とチーム「BLUE」の2チーム対戦なので、接敵グループ16に登録されているキャラクタの多い方のチームカラーが位置報知体38の表示色として設定される。登録されているキャラクタが同数の場合は別の第3の色(無色を含む)が設定される。また、位置報知体38が表す輪郭線は、対応付けられる接敵グループ16におけるチーム別のキャラクタ数の差に応じて、差が大きいほどより太くなるように輪郭線の太さが設定される。勿論、多寡の通知は輪郭線の太さに限らず、位置報知体38の明度変化周期により表現するとしても良いし、キャラクタ数の差に応じた多重線としたり、キャラクタ数の差に応じた大きさの星印などの付加的表示物を添付するといった表現としてもよい。
つまり、位置報知体38により、接敵グループ16のゲーム空間内における位置と、どのチームが優勢であるかと、数的有利/不利に関する情報と、がプレーヤに提供される。
また、本実施形態ではキャラクタマーカ36に付属して、当該マークに対応するプレーヤキャラクタ4をロックオンしている他プレーヤキャラクタ(敵キャラクタ)の数を通知する集中報知体39が表示される。図8では、2体以上からロックオンされているプレーヤキャラクタ4に対応するキャラクタマーカ36に付属して集中報知体39が表示されている。
[機能構成の説明]
次に、本実施形態におけるゲームシステムの機能構成例について説明する。
図9は、本実施形態における業務用ゲーム装置1300の機能構成例を示す機能ブロック図である。業務用ゲーム装置1300は、操作入力部100と、媒体読取部102と、入金検知部104と、処理部200と、音出力部390と、画像表示部392と、通信部394と、記憶部500とを備える。
操作入力部100は、プレーヤによって為された各種の操作入力に応じて操作入力信号を処理部200に出力する。例えば、プッシュスイッチや、ジョイスティック、タッチパッド、トラックボール、加速度センサ、ジャイロ、ジェスチャーコントローラ、などによって実現できる。図2の例では、ジョイスティック1302や、ボタンスイッチ1304、タッチパネル1306がこれに該当する。
媒体読取部102は、電子決済用媒体6で採用される技術方式に準じた公知の読取装置により実現され、電子決済用媒体6に記憶されているデータを読み出して処理部200へ出力する。例えば、電子決済用媒体6に非接触型ICチップを用いるのであれば、そのカードの仕様に準じた非接触型リーダーライターにより実現される。図2の例では、媒体読取装置1344がこれに該当する。
入金検知部104は、投入された現金を検出し、入金額を示す情報を処理部200へ出力する手段であって、公知の入金装置、硬貨投入装置等により実現できる。図2の例では、入金装置1330がこれに該当する。
処理部200は、例えばCPU,GPU等のマイクロプロセッサや、ASIC、ICメモリなどの電子部品によって実現され、操作入力部100や記憶部500を含む各機能部との間でデータの入出力制御を行う。そして、所定のプログラムやデータ、操作入力部100からの操作入力信号、媒体読取部102で読み出したデータ、サーバシステム1100から受信したデータ等に基づいて各種の演算処理を実行して、業務用ゲーム装置1300の動作を制御する。図2の例では制御基板1350がこれに該当する。
そして、本実施形態の処理部200は、プレーヤ端末制御部202と、音生成部290と、画像生成部292と、通信制御部294とを含む。
プレーヤ端末制御部202は、業務用ゲーム装置1300をゲームプレイのためのプレーヤ端末として機能させるための制御を行う。
例えば、
1)操作入力に応じた操作入力信号をサーバシステム1100へ送信する制御と、
2)サーバシステム1100から配信されたゲームステージや各プレーヤのプレーヤキャラクタ4に関する初期設定データを参照して、仮想3次元空間にゲーム空間を設定し、各プレーヤのプレーヤキャラクタ4と、自機を操作するプレーヤのプレーヤキャラクタ4の1人称視点又は3人称視点となる仮想カメラを配置する制御と、
3)自機での操作入力及びサーバシステム1100から受信した他の業務用ゲーム装置1300における操作入力信号に基づいて、各プレーヤキャラクタ4の動作を制御する処理と、
4)ゲーム画面の生成やゲーム音の放音に必要な各種処理と、を行うことができる。
勿論、こうしたプレーヤ端末制御部202の機能は、クライアントサーバシステムのシステムデザインにより必ずしもこれに限定されるものではなく、適宜変更することができる。
音生成部290は、例えばデジタルシグナルプロセッサ(DSP)や、音声合成ICなどのプロセッサ、音声ファイルを再生可能なオーディオコーデック等によって実現され、ゲームに係る効果音やBGM、各種操作音の音信号を生成し、音出力部390に出力する。
音出力部390は、音生成部290から入力される音信号に基づいて効果音やBGM等を音出力する装置によって実現される。図2のスピーカ1310がこれに該当する。
画像生成部292は、例えば、GPU、デジタルシグナルプロセッサ(DSP)などのプロセッサ、ビデオ信号IC、ビデオコーデックなどのプログラム、フレームバッファ等の描画フレーム用ICメモリ等によって実現される。そして、画像生成部292は、1フレーム時間(例えば1/60秒)で1枚のゲーム画面の画像を生成し、生成したゲーム画面の画像信号を画像表示部392へ出力する。
画像表示部392は、画像生成部292から入力される画像信号に基づいてゲーム画像等の各種画面を表示することができる。例えば、フラットパネルディスプレイ、ブラウン管(CRT)、プロジェクター、ヘッドマウントディスプレイといった画像表示装置によって実現できる。本実施形態では、図2のタッチパネル1306がこれに該当する。
通信制御部294は、データ通信に係るデータ処理を実行し、通信部394を介して外部装置とのデータのやりとりを実現する。
通信部394は、通信回線9と接続して通信を実現する。例えば、無線通信機、モデム、TA(ターミナルアダプタ)、有線用の通信ケーブルのジャックや制御回路等によって実現され、図2の通信装置モジュール1353がこれに該当する。
記憶部500は、業務用ゲーム装置1300を統合的に制御するための諸機能を処理部200に実現させるためのシステムプログラムや、ゲームプレイに必要なプログラム、各種データ等を記憶する。また、処理部200の作業領域として用いられ、処理部200が各種プログラムに従って実行した演算結果や操作入力部100から入力される入力データ等を一時的に記憶する。こうした機能は、例えばRAMやROMなどのICメモリ、ハードディスク等の磁気ディスク、CD−ROMやDVDなどの光学ディスクなどによって実現される。図2の制御基板1350が搭載するICメモリ1352がこれに該当する。
記憶部500は、システムプログラム501と、クライアントプログラム502と、を予め記憶する。その他、媒体読取部102で読み取った電子決済用媒体6の媒体IDであったり、ゲーム音やゲーム画像のデータ、タイマやカウンタ、各種フラグなどの情報を適宜記憶できる。
システムプログラム501は、処理部200が読み出して実行することでコンピュータとして必要な基本的な入出力機能を実現するためのプログラムである。
クライアントプログラム502は、処理部200にプレーヤ端末制御部202としての機能を実現させることができる。クライアントプログラム502は、業務用ゲーム装置1300が起動される都度、サーバシステム1100からダウンロードされて記憶されることとしてもよい。
図10は、本実施形態におけるサーバシステム1100の機能構成例を示す機能ブロック図である。本実施形態におけるサーバシステム1100は、操作入力部100sと、サーバ処理部200sと、画像表示部392sと、通信部394sと、サーバ記憶部500sとを備える。
操作入力部100sは、サーバの管理のための各種操作を入力するための手段である。図1の例ではキーボード1106が該当する。
サーバ処理部200sは、例えばCPUやGPU等のマイクロプロセッサや、ASIC、ICメモリなどの電子部品によって実現され、操作入力部100sやサーバ記憶部500sを含む各機能部との間でデータの入出力制御を行う。そして、所定のプログラムやデータ、操作入力部100sからの操作入力信号、業務用ゲーム装置1300から受信したデータ等に基づいて各種の演算処理を実行して、サーバシステム1100の動作を統合的に制御する。図1の例では制御基板1150がこれに該当する。
そして、本実施形態のサーバ処理部200sは、電子決済部208と、ゲーム管理部210と、リプレイ表示制御部212と、接敵グループ検出部220と、報知制御部240と、画像生成部292sと、通信制御部294sとを含む。
電子決済部208は、プレイ対価を電子決済で支払いする場合の決済処理を行う。公知の電子決済技術を適宜利用することで実現される。
ゲーム管理部210は、本実施形態のチーム対戦型オンラインマルチプレイゲームに係る処理を実行する。例えば、
1)プレイ対価の支払いが行われた業務用ゲーム装置1300にて、プレーヤ登録とプレーヤキャラクタ4の選択を行わせ、登録内容と選択結果の入力信号を受信して、サーバ記憶部500sにプレーヤ登録データとして記憶させる処理、
2)各業務用ゲーム装置1300から、プレーヤのチーム登録に関する情報を取得し、プレーヤ登録データに格納する処理、
3)対戦プレイするゲームステージを業務用ゲーム装置1300に選択入力させて、選択結果を受信してサーバ記憶部500sに格納するとともに、各業務用ゲーム装置1300へ配信する処理、
4)各業務用ゲーム装置1300から操作入力信号を受け付け、各プレーヤキャラクタ4の位置と動作とを記憶する処理、
5)攻撃行動にともなうダメージの算出と反映処理、
6)各プレーヤキャラクタ4の最新のステータス情報を配信する処理、
などを実行できる。その他、ゲーム実行に必要な計時処理やランダム抽選処理、フラグ管理、などを実行できる。勿論、こうしたゲーム管理部210の機能は、クライアントサーバシステムのシステムデザインにより必ずしもこれに限定されるものではなく、適宜変更することができる。
リプレイ表示制御部212は、ゲーム終了後に各業務用ゲーム装置1300にて、或いはターミナル装置1390にてリプレイ画面を表示させる制御を行う。
接敵グループ検出部220は、上述した条件A〜Cの判断を行うことで、接敵グループ条件を満たすプレーヤキャラクタ4の集合すなわち接敵グループを検出する。すなわち、本実施形態では、最小構成の接敵関係をなす始原の接敵グループを検出するとともに、始原の接敵グループに所属する敵味方双方のプレーヤキャラクタ4を基点として1つの交戦域とみなせる範囲内のキャラクタ群を当該接敵グループに追加し、1つの交戦域とみなせる接敵グループを検出する。また、接敵グループを構成するプレーヤキャラクタ4の増減管理、接敵関係をなさなくなった接敵グループの抹消、同一のプレーヤキャラクタ4がどちらにも登録されている複数の接敵グループの統合、などの管理制御を行う。また、接敵グループ検出部220は、内部的な機能構成として、第1サブグループ検出部222と、第2サブグループ検出部224と、状態判定部226とを含む。
第1サブグループ検出部222は、近場条件を満たす一方のチーム(第1キャラクタのグループ)のキャラクタのグループである第1サブグループ(第1チーム近場グループ)を検出する。図5の例で言えば、例えば、チーム「RED」のプレーヤキャラクタのうち、近場条件を満たすプレーヤキャラクタ4a、4bを1つの第1サブグループとして検出する。
第2サブグループ検出部224は、近場条件を満たす他方のチーム(第2キャラクタのグループ)のキャラクタのグループである第2サブグループ(第2チーム近場グループ)を検出する。図5の例で言えば、例えば、チーム「BLUE」のプレーヤキャラクタのうち、近場条件を満たすプレーヤキャラクタ4fを1つの第2サブグループ(1つの第2チーム近場グループ)として検出し、近場条件を満たすプレーヤキャラクタ4g、4hを1つの第2サブグループ(1つの第2チーム近場グループ)として検出する。
接敵グループの検出を結果的(全体構成的)に説明すると、接敵グループ検出部220は、第1サブグループ検出部222で検出されたN個の第1サブグループと、第2サブグループ検出部224で検出されたM個の第2サブグループとにおいて(N≧1,M≧1,かつN+M≧3)、対敵状況条件を満たす関係にあるキャラクタ同士がグループ間で連鎖するように存在する場合に、当該N個の第1サブグループと当該M個の第2サブグループとをまとめて1つの接敵グループとして検出すると言える。
状態判定部226は、第1サブグループと第2サブグループとが交戦状態にあることを示す交戦状況条件を満たさない場合には、接敵グループの状態を「非交戦状態」と判定し、満たす場合には「交戦状態」と判定する。本実施形態における「交戦状況条件」は、接敵グループが生成されて所定時間が経過したこととするが、攻撃行動が発生したことを条件としてもよい。
そして、接敵グループ検出部220は、状況判定部226による判定を用いて、交戦状態と判定された接敵グループ(交戦グループ)については、従前に当該接敵グループに含まれていたキャラクタであって、当該接敵グループに含まれる何れかのキャラクタとの間の距離が所与の距離条件を満たすキャラクタを、継続して当該接敵グループに含めて検出する。図6の例で言うと、チーム「BLUE」のキャラクタ10hが離脱判定距離26以内であれば、近場範囲24を越えた位置にあっても従前の接敵グループに含める。
また、接敵グループ検出部220は、過去所定時間の間に交戦状態の接敵グループ(交戦グループ)に含まれていたキャラクタを継続して当該接敵グループに含めて検出することができる。
図6の例で言うと、チーム「BLUE」のキャラクタ10hがチーム「BLUE」のキャラクタ10gを中心とする離脱判定距離26の外に移動しても、「見逃し条件」とする時間内に、キャラクタ10gとの距離を離脱判定距離26以内に縮めれば、近場範囲24を越えた位置にあってもキャラクタ10gと同じ交戦状態の接敵グループに含めて検出する。すなわち、接敵グループ検出部220は、従前に交戦状態の接敵グループ(交戦グループ)に含まれているキャラクタについては、従前の接敵グループ(交戦グループ)の何れかのキャラクタと所与の継続条件を満たす場合、継続条件を満たすキャラクタと同じ接敵グループに含めて検出することができると言える。これにより交戦中のキャラクタ同士の関係性を強くすることができる。
さらに、接敵グループ検出部220は、過去所定時間の間に交戦状態の接敵グループ(交戦グループ)に含まれていたキャラクタを含む他の接敵グループが存在する場合、当該他の接敵グループと、従前の交戦状態の接敵グループ(交戦グループ)とを連結対象接敵グループ候補として検出し、一つの接敵グループ(交戦グループ)として連結・検出することができる。
図5の例を元に具体的に説明すると、仮にゲームが進行するうちに、チーム「BLUE」のキャラクタ10hが、図示されている接敵グループ16とは別の、チーム「BLUE」のキャラクタからなる不図示の他接敵グループに新たに含まれたとする。その場合、交戦状態の接敵グループ16と、キャラクタ10gを含まずキャラクタ10hを含む他接敵グループとを、キャラクタ10hを中継して繋げるように一つの接敵グループ(交戦グループ)として検出する。
なお、接敵グループ条件=交戦状況条件とする場合には、非交戦状態の接敵グループを接敵グループ候補(接敵グループ)、交戦状態の接敵グループを最終的な接敵グループ(交戦グループ)として検出してもよい。
報知制御部240は、接敵グループ検出部220の検出に応じた報知を行うための制御を行う。本実施形態では多寡別報知制御部242と、存在報知制御部244と、位置報知制御部246と、集中報知制御部248とを含む。
多寡別報知制御部242は、接敵グループに含まれる各チームのキャラクタの多寡に応じた報知の制御を行う。本実施形態では、存在報知体34(図7参照)と、位置報知体38(図8参照)との表示形態を多寡に応じて設定する。
存在報知制御部244は、第1サブグループ及び/又は第2サブグループの存在を示す所与の報知の制御を行う。本実施形態では、方位表示30に相対方位を示す存在報知体34を表示制御する(図7参照)。
位置報知制御部246は、第1サブグループ及び/又は第2サブグループの位置、すなわち接敵グループに含まれるキャラクタの位置を報知する制御を行う。本実施形態では、位置報知体38(図8参照)を表示制御する。
集中報知制御部248は、接敵関係が集中しているプレーヤキャラクタ4を報知する制御を行う。本実施形態では、集中報知体39(図8参照)を表示制御する。
画像生成部292sは、サーバシステム1100の保守に関する画像等を生成し、画像表示部392sへ出力することができる。クライアントサーバシステムの機能配分によっては、業務用ゲーム装置1300にて表示するゲーム画面を生成する機能をもたせることもできる。
画像表示部392sは、画像生成部292sから入力される画像信号に基づいてシステム管理のための各種画像を表示する。例えば、フラットパネルディスプレイ、ブラウン管(CRT)、プロジェクター、ヘッドマウントディスプレイといった画像表示装置によって実現できる。図1の例ではタッチパネル1108が該当する。
通信制御部294sは、データ通信に係るデータ処理を実行し、通信部394sを介して外部装置とのデータのやりとりを実現する。
通信部394sは、通信回線9と接続して通信を実現する。例えば、無線通信機、モデム、TA(ターミナルアダプタ)、有線用の通信ケーブルのジャックや制御回路等によって実現される。図1の例では通信装置1153が該当する。
サーバ記憶部500sは、サーバ処理部200sにサーバシステム1100を統合的に制御させるための諸機能を実現するためのシステムプログラムや、ゲーム実行に必要なプログラム、各種データ等を記憶する。また、サーバ処理部200sの作業領域として用いられ、サーバ処理部200sが各種プログラムに従って実行した演算結果などを一時的に記憶する。この機能は、例えばRAMやROMなどのICメモリ、ハードディスク等の磁気ディスク、CD−ROMやDVDなどの光学ディスクなどによって実現される。図1の例では本体装置1101が搭載するICメモリ1152やハードディスクなどの記憶媒体、及びストレージ1140がこれに該当する。
図11は、本実施形態のサーバ記憶部500sが記憶するプログラムやデータの例を示す図である。本実施形態のサーバ記憶部500sは、サーバシステムプログラム503と、ゲームサーバプログラム505と、配信用クライアントプログラム507と、ゲーム初期設定データ510と、を予め記憶する。また、プレーヤ登録データ550と、プレイデータ700とを記憶する。その他、タイマやカウンタ、各種フラグなどの情報を適宜記憶できる。
サーバシステムプログラム503は、サーバ処理部200sが読み出して実行することでサーバシステム1100にコンピュータとして必要な基本的な入出力機能を実現させるためのシステムプログラムである。
ゲームサーバプログラム505は、サーバ処理部200sが読み出して実行することで、サーバシステム1100をゲームサーバとして機能させるプログラムである。サーバ処理部200sに、電子決済部208、ゲーム管理部210、リプレイ表示制御部212、接敵グループ検出部220、報知制御部240、画像生成部292s、通信制御部294sとしての機能を実装させることができる。
配信用クライアントプログラム507は、業務用ゲーム装置1300へ配信・提供されるクライアントプログラム502(図9参照)のオリジナルである。
ゲーム初期設定データ510は、ゲームの実行に必要な各種初期設定データを格納する。
例えば、図12に示すように、ゲームステージ別に用意されたゲーム空間設定データ511と、キャラクタ種類別に用意されたキャラクタ初期設定データ520とを含む。勿論、これら以外のデータも適宜格納することができる。
1つのゲーム空間設定データ511は、ステージ名などのステージID512と、障害物7や拠点8r,8bのモデルや配置位置を定義する背景オブジェクト配置データ513と、索敵範囲設定値514と、近場範囲設定値515と、離脱判定距離設定値516と、マップ表示W4(図8参照)の地図に相当するマップデータ517と、を含む。勿論、これら以外のデータも適宜格納することができる。
索敵範囲設定値514と、近場範囲設定値515とは、それぞれプレーヤキャラクタ4を基準とした索敵範囲20(図4参照)と、近場条件となる近場範囲24(図5参照)の形状と大きさとを定義する。離脱判定距離設定値516は交戦状態の接敵グループに適用される離脱判定距離26(図6参照)の大きさを定義する。
1つのキャラクタ初期設定データ520は、キャラクタ種類と、属性と、初期能力値リストとを含む。初期能力値リストには当該キャラクタの射程範囲22(図5参照)すなわち対敵状況条件に係る距離要素すなわち対敵距離条件を定義するデータを含む。
図11に戻って、プレーヤ登録データ550は、本実施形態のチーム対戦型オンラインマルチプレイゲームに参加するプレーヤ別に用意されて各種の登録情報を格納する。
1つのプレーヤ登録データ550は、1)プレーヤ名などのプレーヤID551と、2)当該プレーヤのプレーヤキャラクタ4とするキャラクタ種類を定義するプレーヤキャラクタ種類553と、3)サーバシステム1100が業務用ゲーム装置1300とデータ通信を確保するために必要なアドレス情報等を格納する使用端末情報555と、4)所属チーム名557とを含む。勿論、これら以外のデータも適宜格納することができる。
プレイデータ700は、本実施形態のチーム対戦型オンラインマルチプレイゲームの進行状況を記述する各種データを格納する。
例えば、図13に示すように、参加プレーヤIDリスト701と、プレイ開始日時702と、対戦するゲーム空間の種類を定義する使用ステージID704と、キャラクタ別ステータスデータ710と、キャラクタ別行動ログ730と、接敵グループ登録データ760と、存在報知体制御データ780と、位置報知体制御データ782と、集中報知体制御データ784と、を含む。勿論、これら以外のデータも適宜格納することができる。
キャラクタ別ステータスデータ710は、プレーヤキャラクタ4別に用意されて、当該キャラクタの最新状況を記述する各種データを格納する。例えば、図14に示すように、当該キャラクタを使用するプレーヤを定義するプレーヤID711と、キャラクタ種類713と、所属チームID714と、ゲーム空間内における位置座標715と、視線方向717と、残耐久値719と、索敵済キャラクタIDリスト720と、攻撃対象候補キャラクタIDリスト722と、ロックオン対象キャラクタID724と、を含む。勿論、これら以外のデータも適宜格納することができる。
索敵済キャラクタIDリスト720は、当該プレーヤキャラクタの索敵範囲20(図4参照)に存在する他プレーヤキャラクタのキャラクタIDのリストである。ゲーム開始時点の初期状態では当該リストは登録無しである。
攻撃対象候補キャラクタIDリスト722は、当該プレーヤキャラクタの射程範囲22(図4参照)に存在する他プレーヤキャラクタのキャラクタIDのリストである。ゲーム開始時点の初期状態では当該リストは登録無しである。
ロックオン対象キャラクタID724は、攻撃対象候補のうちロックオンされているキャラクタを示す。ゲーム開始時点の初期状態では登録無しである。
図13に戻って、キャラクタ別行動ログ730は、プレーヤキャラクタ4別に用意され、プレイ中の行動を時系列に記述するデータである。例えば、図15に示すように、1つのキャラクタ別行動ログ730は、対応するプレーヤキャラクタ4を示す記録対象キャラクタID731と、時系列のログデータセット740と、を含む。勿論、これら以外のデータも適宜格納することができる。
1つのログデータセット740は、例えば、記録時のタイミングを示すフレーム番号741と、その時に対応するプレーヤキャラクタ4のゲーム空間における位置座標742と、視線方向743と、残耐久値744と、その時の行動種類745と、その時の索敵済キャラクタIDリスト720(図14参照)の複製である索敵リスト746と、その時の攻撃対象候補キャラクタIDリスト722(図14参照)の複製である攻撃対象リスト747と、その時のロックオン対象キャラクタID724(図14参照)の複製であるロックオンリスト748とを含む。勿論、これら以外のデータも適宜格納することができる。
図13に戻って、接敵グループ登録データ760は、検知された接敵グループ毎に用意され、当該接敵グループに係る各種データを格納する。1つの接敵グループ登録データ760は、例えば、ユニークな接敵グループID761と、グループ作成日時762と、交戦状態/非交戦状態を示す交戦状態フラグ763と、グループ所属キャラクタIDリスト765と、第1サブグループ所属キャラクタIDリスト767と、第2サブグループ所属キャラクタIDリスト769と、を含む。勿論、これら以外のデータも適宜格納することができる。
存在報知体制御データ780は、存在報知体34(図7参照)毎に用意され、その表示制御に係る各種データを格納する。例えば、報知先を示す表示先キャラクタIDと、報知対象接敵グループIDと、相対方位と、表示形態設定データと、を含む。勿論、これら以外のデータも適宜格納することができる。
相対方位は、表示先キャラクタIDの示すプレーヤキャラクタ4の現在位置から、報知対象接敵グループIDが示す接敵グループの中心位置を見た相対方位である。
表示形態設定データは、存在報知体34の形状や表示色、明度変化パターンなどの表示形態を定義する。
位置報知体制御データ782は、位置報知体38(図8参照)毎に用意され、その表示制御に係る各種データを格納する。例えば、報知対象接敵グループIDと、マップ表示W4内における表示位置データと、表示形態設定データとを格納する。勿論、これら以外のデータも適宜格納することができる。
集中報知体制御データ784は、集中報知体39(図8参照)毎に用意され、その表示制御に係る各種データを格納する。例えば、添付対象キャラクタIDと、表示数とを格納する。勿論、これら以外のデータも適宜格納することができる。
[処理の流れの説明]
次に、ゲームシステムの動作説明として、先ずユーザ登録に係る処理の流れについて説明する。
図16〜図17は、本実施形態におけるサーバシステム1100にて実行される主たる処理の流れを説明するためのフローチャートである。同処理は、サーバシステム1100がゲームサーバプログラム505を実行することにより実現される。
図16に示すように、先ずサーバシステム1100は、プレーヤ登録に関する処理を実行する(ステップS2)。具体的には、プレイ対価の支払いが済まされた業務用ゲーム装置1300にて所定のエントリー画面を表示させて、プレーヤにプレーヤIDの入力と、自分のプレーヤキャラクタ4とするキャラクタ種類の入力と、所属チーム名の入力とをさせる。そして、各業務用ゲーム装置1300から受信したそれらの入力結果を元に、プレーヤ登録データ550を記憶する(図11参照)。また、プレイデータ700を用意して、全プレーヤのプレーヤIDを参加プレーヤIDリスト701に設定し、プレイ開始日時702に現在日時を設定する(図13参照)。
次に、サーバシステム1100は、対戦ステージの選択に関する処理とゲーム開始前の初期化処理をする(ステップS4)。具体的には、何れかの業務用ゲーム装置1300にて所定のステージ選択画面を表示させて、対戦プレイを行うステージをプレーヤに選択させ、選択結果を受信して使用ステージID704に格納する。そして、選択されたステージのゲーム空間設定データ511(図12参照)を参照して、仮想3次元空間にゲーム空間を構成し、各プレーヤのプレーヤキャラクタ4及び各々の仮想カメラを初期位置に配置する。
次に、サーバシステム1100はゲームの進行制御を開始する(ステップS10)。
これに伴い、各プレーヤが使用する業務用ゲーム装置1300ではゲーム画像が表示されるとともにゲーム音が放音され、プレイできるようになる。キャラクタ別ステータスデータ710は逐次更新されるとともに、キャラクタ別行動ログ730にログデータセット740が蓄積されてゆく(図15参照)。
そして、ゲームが開始されると、サーバシステム1100は、ゲームが終了するまでタッチパネル1306の1描画フレーム以下の所定周期でステップS10〜S160を実行する。
具体的には、所定周期毎に、サーバシステム1100は、行動可能なプレーヤキャラクタ4毎にループAを実行する(ステップS10〜S28)。
ループAにおいて、サーバシステム1100は、処理対象とするプレーヤキャラクタ4の索敵範囲20(プレイするステージの索敵範囲設定値514が適用される;図4、図12参照)に存在する、処理対象のプレーヤキャラクタ4以外の他プレーヤキャラクタを抽出して、処理対象キャラクタのキャラクタ別ステータスデータ710の索敵済キャラクタIDリスト720を更新する(ステップS12)。
また、処理対象とするプレーヤキャラクタ4の射程範囲22に存在する他プレーヤキャラクタを抽出して、処理対象キャラクタの攻撃対象候補キャラクタIDリスト722を更新する(ステップS14)。
次に、処理対象とするプレーヤキャラクタ4のロックオン対象キャラクタID724(図14参照)が未定であれば(ステップS16のYES)、自動で攻撃対象候補キャラクタIDリスト722からロックオン対象を自動選択する(ステップS18)。勿論、処理対象とするプレーヤキャラクタ4のプレーヤの業務用ゲーム装置1300から、所定のロックオン対象選択操作に応じて、攻撃対象候補キャラクタIDリスト722からロックオン対象の選択を切替変更することができる(ステップS20)。
図17に移って、サーバシステム1100は、処理対象とするプレーヤキャラクタ4に対応する業務用ゲーム装置1300から所定の攻撃操作入力を受信すると、当該プレーヤキャラクタ4にロックオン対象へ攻撃するように攻撃行動制御を開始することができる(ステップS22)。そして、処理対象とするプレーヤキャラクタ4への着弾判定に応じたダメージ判定とダメージ反映を行うことができる(ステップS24)。ダメージ反映では残耐久値719が減算され、減算の結果「0」に達すると処理対象とするプレーヤキャラクタ4は行動不能となり、以降はループAの処理対象外となる。
また、サーバシステム1100は、処理対象とするプレーヤキャラクタ4に対応する業務用ゲーム装置1300から移動操作入力を受信すると、当該プレーヤキャラクタ4を移動行動制御することができる(ステップS26)。
行動可能な全てのプレーヤキャラクタ4についてループAを実行したならば(ステップS28)、サーバシステム1100は次に接敵グループ検知処理を実行する(ステップS50)。
図18〜図19は、本実施形態における接敵グループ検知処理の流れを説明するためのフローチャートである。同処理において、サーバシステム1100は、接敵グループ未登録で行動可能なプレーヤキャラクタ4毎にループBを実行する(ステップS52〜S88)。
ループBでは先ず、ループB処理対象キャラクタと対敵状況条件を満たす敵キャラクタすなわち接敵関係をなす敵キャラクタの有無を判定する(ステップS54)。本実施形態における接敵関係は、ロックオン対象キャラクタID724にプレーヤキャラクタ4のキャラクタIDが設定されていることである。
もし、否定であれば(ステップS54のNO)、サーバシステム1100はループBを終了する。
一方、肯定であれば(ステップS54のYES)、サーバシステム1100は、該当する敵キャラクタが登録されている既存の接敵グループがあるかを判定する(ステップS56)。そして、もし該当する既存の接敵グループがあれば(ステップS56のYES)、サーバシステム1100は、ループB処理対象キャラクタを該当敵キャラクタが登録されているのと同じ接敵グループに登録し(ステップS60)、ループBを終了する。
反対に、該当敵キャラクタが登録されている既存の接敵グループが無ければ(ステップS56のNO)、サーバシステム1100は新たに接敵関係が発生したと判断し、新規に接敵グループを作成する(ステップS62)。具体的には、プレイデータ700に新たな接敵グループ登録データ760を作成し(図13参照)、接敵グループID761にユニークなIDを自動生成して設定し、現在日時をグループ作成日時762に設定し、交戦状態フラグ763を「0(非交戦)」に設定する。また、グループ所属キャラクタIDリスト765と、第1サブグループ所属キャラクタIDリスト767と、第2サブグループ所属キャラクタIDリスト769とは登録無しに設定する。
そして、ループBの処理対象キャラクタと、敵対条件を満たした敵キャラクタとなる他プレーヤキャラクタと、のそれぞれのキャラクタIDをグループ所属キャラクタIDリスト765に格納して、この新規作成した接敵グループに登録する(ステップS64)。例えば、第1サブグループ所属キャラクタIDリスト767には、チーム「RED」のプレーヤキャラクタ4のキャラクタIDを登録し、第2サブグループ所属キャラクタIDリスト769には、チーム「BLUE」のプレーヤキャラクタ4のキャラクタIDを登録するとする。これが始原の接敵グループとなる。
次に、ループB処理対象キャラクタと同じ接敵グループに登録されているキャラクタ毎にループCを実行して、それぞれにとって近場にいる味方を検索して当該接敵グループに追加登録し、その近場に居る味方と対敵状況条件を満たすキャラクタを検索して追加登録する(ステップS80〜S84)。
すなわち、ループCの処理対象キャラクタの近場範囲24(図5参照;プレイするステージの近場範囲設定値515が適用される)に位置し近場条件を満たすと判断される味方を検索し、該当するキャラクタがいれば(ステップS82のYES)、そのキャラクタIDをグループ所属キャラクタIDリスト765に格納して当該新規作成した接敵グループに登録する(ステップS84)。また、それとともに、該当するキャラクタを、ループCの処理対象キャラクタと同じサブグループの第1サブグループ所属キャラクタIDリスト767又は第2サブグループ所属キャラクタIDリスト769に格納して登録する。
図19に移って、サーバシステム1100は、次にループC処理対象キャラクタと対敵条件を満たす敵キャラクタを検索する(ステップS86)。そして、該当するキャラクタがあれば(ステップS86のYES)、当該キャラクタをループB処理対象キャラクタと同じ接敵グループへ追加登録する(ステップS88)。また、それとともに、該当するキャラクタを、ループCの処理対象キャラクタとは異なるサブグループの第1サブグループ所属キャラクタIDリスト767又は第2サブグループ所属キャラクタIDリスト769に格納して登録する。そして、現在処理対象としているキャラクタに対するループCの実行は終了する(ステップS90)。
ループCを最初に実行する段階では、ループB処理対象キャラクタと同じ接敵グループには、ループB処理対象キャラクタと、ステップS54にて判別された敵キャラクタとが所属している。図5の例では、プレーヤキャラクタ4aと敵キャラクタ10fのみが所属していることになる。そして、ループCを実行して新たなキャラクタが追加されると、当該新たなキャラクタもループCの処理対象となる。図5の例では、ステップS82〜S84によりプレーヤキャラクタ4aの味方であるプレーヤキャラクタ4bが追加登録され、プレーヤキャラクタ4bについてもループCは実行される。
プレーヤキャラクタ4bについてループCが実行されると、今度はステップS86〜S88により敵キャラクタ10gが接敵グループに追加登録される。そして、やはり敵キャラクタ10gもループCの処理対象となる。敵キャラクタ10gについてループCが実行されると、今度はステップS82〜S84により敵キャラクタ10hが接敵グループに追加登録され、この敵キャラクタ10hもループCの処理対象となる。敵キャラクタ10hについてもループCが実行されるが、敵キャラクタ10hの近場にいる味方も、敵キャラクタ10hをロックオンしている他プレーヤキャラクタも見つからないので、新たなキャラクタは追加されない。
ここに至って、ループB処理対象キャラクタの接敵グループに所属する全てのキャラクタについてループCが実行されたことになり、サーバシステム1100は次に、ループB処理対象キャラクタの新規作成した接敵グループに含まれているキャラクタの所属チームをカウントする。
もし、1つのチームのキャラクタで当該接敵グループが構成されているならば(ステップS92のYES)、今回のループBのステップS62で作成した接敵グループを削除して(ステップS94)、ループBを終了する(ステップS96)。もし、複数のチームのキャラクタで当該接敵グループが構成されているならば(ステップS92のNO)、ステップS94をスキップしてループBを終了する(ステップS96)。
接敵グループに未所属の全てのキャラクタについてループBを実行したならば、図17に戻って、サーバシステム1100は次に接敵グループ管理処理を実行する(ステップS100)。
図20は、本実施形態における接敵グループ管理処理の流れを説明するためのフローチャートである。同処理において、サーバシステム1100は、先ず接敵グループ登録データ760を参照して(図13参照)、グループ作成日時762から所定時間(例えば、3秒)が経過している接敵グループを抽出し、それらの交戦状態フラグ763を「1(交戦状態)」に変更する(ステップS102)。
次に、キャラクタ別ステータスデータ710を参照して(図14参照)、残耐久値719が「0」に達しているキャラクタを行動不能と判断して、接敵グループからの登録を抹消する(ステップS104)。すなわち、行動不能となったプレーヤキャラクタ4のキャラクタIDを所属していた接敵グループのグループ所属キャラクタIDリスト765、第1サブグループ所属キャラクタIDリスト767、第2サブグループ所属キャラクタIDリスト769からそれぞれ削除する(図13参照)。
次に、サーバシステム1100は、接敵グループ毎にループDを実行する(ステップS106〜S112)。
ループDでは、先ず、処理対象接敵グループに登録済のキャラクタのうち、最寄りの同じ接敵グループのキャラクタから離脱判定距離26を越えて離れたキャラクタを抽出する(ステップS108)。このとき、交戦状態フラグ763(図13参照)が「0(非交戦状態)」の接敵グループについては離脱判定距離26を近場範囲24と同距離とし、交戦状態フラグ763が「1(交戦状態)」の接敵グループについてはプレイ中のゲームステージのゲーム空間設定データ511(図12参照)の離脱判定距離設定値516を適用する。
そして、抽出したキャラクタのキャラクタ別行動ログ730を参照して(図15参照)、離脱判定距離26を越えて離れた状態の継続時間を算出する。そして、算出した継続時間が所定の見逃し条件に相当する所定時間に達したキャラクタであって、同じ接敵グループの何れのキャラクタからもロックオンされていないキャラクタを検索して、当該キャラクタを処理対象の接敵グループから登録抹消する(ステップS110)。
ステップS110の処理を換言すると、過去の所定時間の間に交戦状態と判定された当該接敵グループ(交戦グループ)に含まれていたキャラクタについては、当該従前の接敵グループ(交戦グループ)に含まれていた他のキャラクタとの間の距離が離脱判定距離26以内の場合、離脱判定距離26以内の他のキャラクタと同じ接敵グループに含めて検出する処理である、ということもできる。
そして、全ての接敵グループについてループDを実行したならば(ステップS112)、サーバシステム1100は、次に、同じキャラクタが重複して登録されている接敵グループすなわち所属するキャラクタが共通する接敵グループを連結対象接敵グループ候補として検索し、該当する接敵グループをグループ作成日時762が古い方の1つの接敵グループに統合する(ステップS114)。すなわち、グループ作成日時762が新しい方の接敵グループから共通しているプレーヤキャラクタ4を登録抹消して除外し、グループ作成日時762が古い方の接敵グループに登録して当該グループに所属している状態にする。これで、各接敵グループの所属キャラクタが最新の状態に更新されて増減した状態で、1つの交戦域とみなせる範囲内のキャラクタ群を接敵グループとして正しく検出することができる。なお、ステップS114は交戦状態の接敵グループ(交戦グループ)に限定して実行するとしてもよい。
次いで、サーバシステム1100は、全所属キャラクタのチームが同じになった接敵グループを抹消する(ステップS116)。すなわち、対敵していた2つのチームのうち一方のチームのキャラクタが全滅している接敵グループの接敵グループ登録データ760を削除する(図13参照)。
更に、サーバシステム1100は、所属するキャラクタの数が「0」になった接敵グループを抹消して(ステップS118)、接敵グループ管理処理を終了する。
図17に戻って、次にサーバシステム1100は接敵グループ報知処理を行う(ステップS130)。
図21は、接敵グループ報知処理の流れを説明するためのフローチャートである。
同処理において、サーバシステム1100は、接敵グループ毎にループEを実行する(ステップS132〜S142)。
具体的には、ループEにおいて、サーバシステム1100は先ず処理対象の接敵グループからチーム別のサブグループすなわち第1サブグループと第2サブグループとを抽出する(ステップS134)。ここで、サブグループを、近場条件を満たすグループ単位で細分化して抽出してもよいし、接敵グループが検出されているため、接敵グループのうちのチーム別のキャラクタグループの単位で抽出してもよい。これで、第1サブグループ所属キャラクタIDリスト767と、第2サブグループ所属キャラクタIDリスト769とが最新状態に更新される。これらのリスト間の登録キャラクタ数の差が、その接敵グループにおけるチーム間のキャラクタの多寡にあたる。
次に、サーバシステム1100は、報知先キャラクタ別(業務用ゲーム装置1300別)に相対方位と存在報知体34(図7参照)の表示形態を設定する(ステップS136)。このとき、存在報知体34の表示形態は、第1サブグループ所属キャラクタIDリスト767と、第2サブグループ所属キャラクタIDリスト769とを参照して接敵グループに含まれる各チーム間の所属キャラクタ数の多寡に応じて決定される。設定内容は、存在報知体制御データ780に格納する(図13参照)。
次に、サーバシステム1100は、マップ表示W4にて表示される処理対象接敵グループの全所属キャラクタのキャラクタマーカ36を囲む位置報知体38の表示位置と表示形態とを設定する(ステップS138;図8参照)。このとき、位置報知体38の表示形態は、第1サブグループ所属キャラクタIDリスト767と、第2サブグループ所属キャラクタIDリスト769とを参照して接敵グループに含まれる各チーム間の所属キャラクタ数の多寡に応じて決定される。設定内容は、位置報知体制御データ782としてプレイデータ700に格納さする(図13参照)。
次に、サーバシステム1100は集中報知体39を設定する(ステップS140;図8参照)。すなわち、処理対象接敵グループの所属キャラクタのキャラクタ別ステータスデータ710のロックオン対象キャラクタID724を照合して(図14参照)、複数のキャラクタからロックオンされているキャラクタを抽出し、ロックオンされている数をカウントし、プレイデータ700に集中報知体制御データ784を生成する(図13参照)。
全ての接敵グループについてループEを実行したならば、各業務用ゲーム装置1300にて存在報知体34を表示させ(ステップS144)、また位置報知体38が表示されたマップ表示W4を表示させる(ステップS146)。更に、マップ表示W4に集中報知体39を表示させて(ステップS148)、接敵グループ報知処理を終了する。
図17に戻って、ゲーム終了条件を満たしたならば(ステップS160のYES)、サーバシステム1100は各プレーヤキャラクタ4の行動ログの記録を終了し(ステップS162)、対戦結果の発表を行う(ステップS164)。
そして、サーバシステム1100は、キャラクタ別行動ログ730(図13参照)を元にして各業務用ゲーム装置1300及び/又はターミナル装置1390にて、リプレイ表示させる(ステップS166)。リプレイ表示は、公知技術を適宜流用することができる。但し、リプレイ中もステップS50,S100,S130と同様にして、接敵グループ検知処理と、接敵グループ管理処理と、接敵グループ報知処理とを実行し、マップ表示W4等を表示させる。
リプレイが完了すると、サーバシステム1100は一連の処理を終了する。
以上、本実施形態によれば、チーム対戦型オンラインマルチプレイゲームにおいて、敵味方が交戦可能に接近した前線すなわち接敵グループの存在を存在報知体34で示し、ゲーム空間中の具体的な位置をマップ表示内の位置報知体38で示すことができる。
しかも、報知される接敵グループは、単に武器を向け合う関係をなしているキャラクタの対(ペア)に限らず、それらの近場にいて直ぐに駆けつけて支援が可能な味方も含めた、1つの交戦域で交戦しているとみなせるキャラクタ群およびその交戦域として検知される。
故に、一対一の対敵関係(最小構成の接敵グループ)の存在や位置を報知しても初心者では情報過多になり却って状況を理解できない恐れがあるが、本実施形態ではそうした心配はない。また、初心者でも駆けつけて支援が可能な状況も含めた総合的な戦況を一瞥で理解でき、すみやかに勝利のための行動をとることができるようになる。更には、存在報知体34や位置報知体38、集中報知体39の表示形態により、接敵グループ毎の数的な有利/不利が一目瞭然となる。よって、自分が何処に駆けつけて支援すれば最も効果的であるかを初心者でも直ぐに理解することができる。
こうした工夫は、初心者プレーヤのゲームへの習熟と戦術的技量の向上とを促す。ユーザ層全体の技量が底上げされれば、やり応えのある対戦が楽しめる機会も増えるであろう。そして、結果的に当該ゲームへの大きな魅力の1つとなるであろう。
〔変形例〕
以上、本発明を適用した実施形態について説明したが、本発明を適用可能な形態は上記形態に限定されるものではなく、適宜構成要素の追加・省略・変更を施すことができる。
[その1]
例えば、上記実施形態ではゲームシステムをクライアントサーバシステムにて構成したが、複数の業務用ゲーム装置1300がピアツーピア接続してゲームシステムを構成するとしてもよい。その場合、上記実施形態においてサーバシステム1100が担っていた機能を適宜業務用ゲーム装置1300間で分散実行する構成とすることができる。あるいは、1台の業務用ゲーム装置1300がホスト機として、サーバシステム1100が担っていた機能をも実行することとしてもよい。
[その2]
また、上記実施形態では、ゲーム進行制御や、接敵グループの検知・管理・報知に係る制御を専らサーバシステム1100にて実行する構成としたが、図22に示すように、接敵グループの検知・管理・報知に関する制御を、サーバシステム1100に代えて各業務用ゲーム装置1300やターミナル装置1390にて実現させる構成も可能である。
[その2]
また、上記実施形態では、位置報知体38を報知対象の接敵グループのキャラクタマーカ36を全て囲う単一の矩形形状としたが、別の表示態様としてもよい。例えば、図23(1)に示すように、スナイパー(長距離攻撃可能な装備を限定的に与えられている特別なプレーヤキャラクタ;他のプレーヤキャラクタが明らかに交戦不可能な位置から、一方的に攻撃可能な性能を持つキャラクタ)に相当するプレーヤキャラクタ4dが接敵グループ16に含まれる場合、上記実施形態のように接敵グループ16を単一の矩形形状の位置報知体38で表示する態様とすると、マップ表示W4において複数の位置報知体38同士が重なり合って却って見難くなる場合がある。
そこで、図23(2)に示すように、位置報知体38を複数のサブ報知体の集合としてもよい。すなわち、プレーヤキャラクタ4dのキャラクタマーカ36dを第1サブ位置報知体38aで囲って表示して、それ以外の接敵グループ16の所属キャラクタのキャラクタマーカ36を第2サブ位置報知体38bで囲って表示し、これらの報知体を連結する第3サブ位置報知体38cを表示するとしてもよい。
[その3]
また、上記実施形態では、敵味方を混合して接敵グループの検知・管理・報知を行ったが、それぞれの敵についてのみ接敵グループを検知・管理・報知する構成としてもよい。この場合、存在報知体34は接敵状態にある敵グループの存在を報知し、位置報知体38はその位置を報知することとなる。例えば、図8のマップ表示W4と同じ状況を、当該構成を適用してチーム「RED」の業務用ゲーム装置1300でマップ表示すると、図24のマップ表示W6のようになる。
[その4]
また、上記実地形態では対戦に登場するキャラクタは、全てプレーヤキャラクタ4として説明したが、コンピュータが自動で行動制御するNPC(ノンプレーヤキャラクタ)を含む構成も可能である。