以下、添付図面を参照して、本発明の実施の形態について説明する。
図1は、この実施の形態にかかるネットワークゲームシステムの構成を示すブロック図である。図示するように、このネットワークゲームシステムは、複数(ここでは、3つのみを図示)のビデオゲーム装置100と、サーバ装置200とから構成される。ビデオゲーム装置100は、それぞれサーバ装置200にネットワーク151を介して接続される。
このネットワークゲームシステムで適用されるゲームでは、ビデオゲーム装置100を利用する各プレイヤは、全てのプレイヤに共通の仮想3次元空間(ゲーム空間)に形成されたフィールド上で自己のプレイヤキャラクタを移動させていくことによりゲームを進行していく。また、各プレイヤキャラクタは、各々のプレイヤキャラクタからの指示に従ってフィールド上で移動していくものの、複数のプレイヤキャラクタによりパーティを形成して団体行動することもできる(但し、単独行動を妨げない)。プレイヤキャラクタ、或いはプレイヤキャラクタのパーティは、フィールド上の随所で遭遇する敵キャラクタ(1体または2体以上)とのバトルを行っていく。
このネットワークゲームシステムにおけるバトルでは、各プレイヤは、自己のプレイヤキャラクタに対して攻撃や防御の指示を出すだけではなく、バトルが行われている一定範囲のエリア(以下、バトルエリアという)内では、自己のプレイヤキャラクタを自由に移動させることができる。また、プレイヤキャラクタだけではなく、サーバ装置200の所定の思考ルーチンにより制御される敵キャラクタも、バトルエリア内を自由に移動することができる。プレイヤキャラクタと敵キャラクタの何れもバトルエリアを自由に移動することができるので、これらが接触することがあるが、このときの各キャラクタの移動の制御については後述する。
図2は、図1のビデオゲーム装置100の構成を示すブロック図である。図示するように、ビデオゲーム装置100は、装置本体101を中心として構築される。この装置本体101は、その内部バス119に接続された制御部103、RAM(Random Access Memory)105、ハードディスク・ドライブ(HDD)107、サウンド処理部109、グラフィック処理部111、DVD/CD−ROMドライブ113、通信インターフェイス115、及びインターフェイス部117を含む。
この装置本体101のサウンド処理部109は、スピーカーであるサウンド出力装置125に、グラフィック処理部111は、表示画面122を有する表示装置121に接続されている。DVD/CD−ROMドライブ113には、記録媒体(本実施の形態では、DVD−ROMまたはCD−ROM)131を装着し得る。通信インターフェイス115は、ネットワーク151に接続される。インターフェイス部117には、発光部160と受信部161とメモリーカード162とが接続されている。
制御部103は、CPU(Central Processing Unit)やROM(Read Only Memory)などを含み、HDD107や記録媒体131上に格納されたプログラムを実行し、装置本体101の制御を行う。制御部103は、現在時刻を計時する内部タイマを備えている。RAM105は、制御部103のワークエリアである。HDD107は、プログラムやデータを保存するための記憶領域である。サウンド処理部109は、制御部103により実行されているプログラムがサウンド出力を行うよう指示している場合に、その指示を解釈して、サウンド出力装置125にサウンド信号を出力する。
グラフィック処理部111は、制御部103から出力される描画命令に従って、フレームメモリ(フレームバッファ)112(図では、グラフィック処理部111の外側に描かれているが、グラフィック処理部111を構成するチップに含まれるRAM内に設けられる)に画像を展開し、表示装置121の表示画面122上に画像を表示するビデオ信号を出力する。グラフィック処理部111から出力されるビデオ信号に含まれる画像の1フレーム時間は、例えば30分の1秒である。
DVD/CD−ROMドライブ113は、記録媒体131に対しプログラム及びデータの読み出しを行う。通信インターフェイス115は、ネットワーク151に接続され、他のコンピュータとの通信を行う。
入力装置163は、受光部163aと、加速度センサ163bと、送信部163cを含んでいる。受光部163aは、発光部160に含まれる各LEDから照射された光を受光する。入力装置163の向きによって、受光部163aが光を受光できるLEDの数及び位置に違いが生じる。加速度センサ163bは、3軸以上の多軸加速度センサからなり、入力装置163の傾き及び3次元の動きを検出する。入力装置163は、また、方向キー及び複数の操作ボタンを備えている。当該ビデオゲーム装置100を使用するプレイヤキャラクタの動作は、入力装置163が備える操作ボタンや方向キーの操作、或いは入力装置163の傾き及び3次元の動きによって指示が与えられるものとなる。
送信部163cは、入力装置163の状況に応じた赤外線信号、より詳しくは、受光部163aの受光状態、加速度センサ163bにより検出された入力装置163の傾き、並びに入力装置163の動く方向及び速度、方向キー及び操作ボタンからの入力に応じた赤外線信号を送信する。送信部163cから送信された赤外線信号は、入力装置163からの入力データとして受信部161により受信される。
インターフェイス部117は、受信部161により受信された入力データをRAM105に出力し、制御部103がそれを解釈して演算処理を実施する。インターフェイス部117は、また、制御部103からの指示に基づいて、RAM105に記憶されているゲームの進行状況を示すデータをメモリーカード162に保存させ、メモリーカード162に保存されている中断時のゲームのデータを読み出して、RAM105に転送する。
ビデオゲーム装置100でゲームを行うためのプログラム及びデータは、最初例えば記録媒体131に記憶されている。記録媒体131に記憶されているデータとしては、ゲーム空間に存在するオブジェクト(ゲーム空間に形成されたフィールド、自身及び他者のプレイヤキャラクタ、敵キャラクタ)を構成するためのグラフィックデータを全て含んでいる。
記録媒体131に記憶されたプログラム及びデータは、実行時にDVD/CD−ROMドライブ113により読み出されて、RAM105にロードされる。制御部103は、RAM105にロードされたプログラム及びデータを処理し、描画命令をグラフィック処理部111に出力し、サウンド出力の指示をサウンド処理部109に出力する。制御部103が処理を行っている間の中間的なデータは、RAM105に記憶される。
図3は、図1のサーバ装置200の構成を示すブロック図である。図示するように、サーバ装置200は、装置本体201を中心として構築される。装置本体201は、その内部バス219に接続された制御部203、RAM205、ハードディスク・ドライブ(HDD)207、DVD/CD−ROMドライブ213、通信インターフェイス215を含む。DVD/CD−ROMドライブ213には、記録媒体(DVD−ROMまたはCD−ROM)231を装着し得る。
制御部203は、CPU(Central Processing Unit)やROM(Read Only Memory)などを含み、HDD207や記録媒体231上に格納されたプログラムを実行し、サーバ装置200の制御を行う。制御部203は、現在時刻を計時する内部タイマを備えている。RAM205は、制御部203のワークエリアである。HDD207は、プログラムやデータを保存するための記憶領域である。通信インターフェイス215は、ネットワーク151に接続され、ビデオゲーム装置100のそれぞれとの通信を行う。
サーバ装置200でネットワークゲームを行うためのプログラム及びデータは、最初例えば記録媒体231に記憶され、ここからHDD207にインストールされる。そして、このプログラム及びデータは実行時にHDD207から読み出されて、RAM205にロードされる。制御部203は、RAM205にロードされたプログラム及びデータを処理し、ビデオゲーム装置100のそれぞれから送られてくるメッセージなどを元にネットワークゲームを進行させる。制御部203が処理を行っている間の中間的なデータは、RAM205に記憶される。
以下、この実施の形態にかかるネットワークゲームシステムにおいて、バトルにおけるプレイヤキャラクタと敵キャラクタのバトルエリア内での移動について説明する。前述したとおり、バトルにおいてプレイヤキャラクタ及び敵キャラクタの各々は、バトルエリア内において個々に移動することができるが、その移動量は、仮想3次元空間における3次元ベクトルにより指示される。プレイヤキャラクタ及び敵キャラクタの各々がバトルエリア中の障害物や他のキャラクタに干渉されずに自由に移動できる状況にあるときには、各々の移動量を指示する3次元ベクトルに従って移動させられる。
もっとも、プレイヤキャラクタ及び敵キャラクタの各々がバトルエリア中に障害物や他のキャラクタに接触したときには、各々の移動量を指示する3次元ベクトルのままに移動させる訳にはいかない。ここで、プレイヤキャラクタ同士、敵キャラクタ同士、或いはキャラクタとキャラクタ以外の障害物の接触により移動が干渉されるときは、従来のゲームにおいて適用されてきたのと同じ手法が適用され、この実施の形態において問題とされるものではない。
しかし、この実施の形態において、プレイヤキャラクタと敵キャラクタとが接触したときには、接触状態にあるプレイヤキャラクタと敵キャラクタとの移動に、従来のゲームとは異なる手法が適用される。図4(a)〜(e)は、この実施の形態において、接触状態にあるプレイヤキャラクタと敵キャラクタとの移動制御を説明する図である。
図4(a)に示すように、プレイヤキャラクタ300と敵キャラクタ350とがバトルエリアにおいて接触状態となったと判定すると(接触状態か否かは、各キャラクタの大きさに応じて従来と同じ手法により判定することができる)、プレイヤキャラクタ300の移動ベクトル301の方向を中心としたユニット角302の範囲内に敵キャラクタ350が存在するかと、敵キャラクタ350の移動ベクトル351の方向を中心としたユニット角352の範囲内にプレイヤキャラクタ300が存在するかが判定される。
なお、ユニット角302、352は、それぞれプレイヤキャラクタ300、敵キャラクタ350に対して120°以上150°以下の範囲で、大きさの大きいキャラクタほどユニット角が大きくなるように予め設定されたものである。ここで、プレイヤキャラクタ300のユニット角302が120°の場合、移動ベクトル301の方向から右回りに60°、左回りに60°の範囲が、ユニット角302の範囲内ということとなる。後述する解除角305、355も、それぞれプレイヤキャラクタ300、敵キャラクタ350に対して、大きさに応じて予め設定されたものとなっているが、その大きさは、ユニット角302、352よりも僅かに大きく、130°以上160°以下の範囲にある。
ユニット角302の範囲内に敵キャラクタ350が存在し、且つユニット角352の範囲内にプレイヤキャラクタ300が存在すると判定されると、図4(b)に示すように、接触状態にあるプレイヤキャラクタ300と敵キャラクタ350とがユニット310として設定される。ユニット角302の範囲内に敵キャラクタ350が存在するだけ、或いはユニット角352の範囲内にプレイヤキャラクタ300が存在するというだけでは、プレイヤキャラクタ300と敵キャラクタ350とはユニット310として設定されない。
また、プレイヤキャラクタ300と敵キャラクタ350に予め設定された重量の比に応じて、重み付けされた移動ベクトル304、354が設定される。なお、移動ベクトルの重み付けは、キャラクタの重量比(小/大とする)が9割以上の場合には、重みを付ける方をランダムに選択し、重量比が9割未満8割以上の場合には、重量が大きいキャラクタに重みを付ける。重量比が8割未満の場合には、重量が小さいキャラクタの移動ベクトルを0とする。この重み付けは、後述するようにユニットが解除されるまでの各フレーム期間において個別になされる。
次に、図4(c)に示すように、重み付けの処理を行った後のプレイヤキャラクタ300の移動ベクトル304と敵キャラクタ350の移動ベクトル354とをベクトル合成して、ユニット310全体での移動ベクトル311を求める。そして、ユニット310に含まれるプレイヤキャラクタ300も敵キャラクタ350も、ここで求めた移動ベクトル311に従ってバトルエリアにおいて移動される。なお、このベクトル合成を行う際に、プレイヤキャラクタ300と敵キャラクタ350との傾斜が所定の角度以下となっている場合(或いは、両者の高低差が所定量以下となっている場合)には、高さ方向を除いた2次元ベクトルでベクトル合成を行い、高さ方向のベクトル成分を0としてユニット310の移動ベクトル311を求めることができる。
また、図4(d)に示すように、プレイヤキャラクタ300と敵キャラクタ350とがユニット310として設定された後であっても、各フレーム期間において、プレイヤキャラクタ300の移動ベクトル301の方向を中心とした解除角305の範囲外に敵キャラクタ350が存在するかと、敵キャラクタ350の移動ベクトル351の方向を中心とした解除角355の範囲外にプレイヤキャラクタ300が存在するかが判定される
また、図示はしないが、プレイヤキャラクタ300と敵キャラクタ350とがユニット310として設定された後であっても、各フレーム期間において、プレイヤキャラクタ300の移動ベクトル301の大きさが0となっているかと、敵キャラクタ350の移動ベクトル351の大きさが0となっているかとが判定される。
解除角305の範囲外に敵キャラクタ350が存在する、解除角355の範囲外にプレイヤキャラクタ300が存在する、移動ベクトル301と移動ベクトル351の大きさが何れも0であるの条件のうちの1つの条件でも成立した場合には、図4(e)に示すように、ユニット310が解除され、プレイヤキャラクタ300と敵キャラクタ350は、それぞれ移動ベクトル301、351に従って、バトルエリアにおいて個別に移動させられるものとなる。
以下、この実施の形態にかかるネットワークゲームシステムにおいて、バトルにおいてプレイヤキャラクタと敵キャラクタが接触状態となったときの移動を制御するために必要なデータについて説明する。この実施の形態にかかるネットワークゲームシステムでは、ゲームの進行のためのデータは全てサーバ装置200に集中されてサーバ装置200の制御によりゲームを進めることとなるので、ここでは、サーバ装置200のRAM205またはHDD207にて管理されるデータについて説明する。
サーバ装置200においては、各ビデオゲーム装置100のプレイヤに係るプレイヤキャラクタに関するデータを登録したプレイヤキャラクタテーブルと、これと敵対してバトルを行う敵キャラクタを登録した敵キャラクタテーブルとが用意されている。図5(a)は、プレイヤキャラクタテーブルを示す図であり、図5(b)は、敵キャラクタテーブルを示す図である。プレイヤキャラクタと敵キャラクタとでテーブルを別に用意したのは、ユニット化の対象となるのがプレイヤキャラクタと敵キャラクタとが接触している場合だからであり、プレイヤキャラクタと敵キャラクタの別を区別する必要があるからである。
図示するように、プレイヤキャラクタテーブル400も敵キャラクタテーブル500も、キャラクタを一意に識別するためのID(P−ID、E−ID)と、キャラクタの大きさ及び重量と、仮想3次元空間における基準点(重心)の位置と、各キャラクタに対して指示される移動量を示す3次元の移動ベクトルと、各キャラクタに対して設定されたユニット角及び解除角を登録している。なお、プレイヤキャラクタテーブル400の移動ベクトルは、ビデオゲーム装置100から送られてきた情報に従って、敵キャラクタテーブル500の移動ベクトルは、サーバ装置200の思考ルーチンの実行に従って、1フレーム期間毎に設定される。
以下、この実施の形態にかかるネットワークゲームシステムにおいて実行される処理について説明する。この実施の形態にかかるネットワークゲームシステムでは、各ビデオゲーム装置100は入力装置163から入力された指示に関する情報等を送るのみで、ゲームの実行の制御はサーバ装置200において行われるものであるため、ビデオゲーム装置100において実行される処理については詳細な説明を省略する。また、バトルにおけるバトルエリア内でのキャラクタの移動以外には本発明に特有の処理はないため、このようなものは省いて説明する。
図6は、この実施の形態にかかるネットワークゲームシステムのバトルにおいて、サーバ装置200が実行する処理を示すフローチャートである。このフローチャートの処理は、バトル毎に1つのプロセスとして起動され、また、バトルが終了するまでの各フレーム期間において実行されるものである。
処理が開始されると、サーバ装置200の制御部203は、バトルに参加しているプレイヤキャラクタと敵キャラクタとのうちに、前のフレーム期間までにユニットとして設定されているプレイヤキャラクタと敵キャラクタの組があるかどうかを判定する(ステップS101)。ユニットとして設定されているプレイヤキャラクタと敵キャラクタの組がなければ、そのままステップS105の処理に進む。
ユニットとして設定されているプレイヤキャラクタと敵キャラクタの組があれば、制御部203は、当該ユニットに含まれるプレイヤキャラクタと敵キャラクタについての移動ベクトルをプレイヤキャラクタテーブル400と敵キャラクタテーブル500から読み出し、その何れもが0となっているかを判定する(ステップS102)。双方とも移動ベクトルが0となっていれば、ステップS104の処理に進む。
何れか一方でも移動ベクトルが0となっていなければ、制御部203は、プレイヤキャラクタの解除角の範囲外に敵キャラクタが存在するか、敵キャラクタの解除角の範囲外にプレイヤキャラクタが存在するかを判定する(ステップS103)。何れか一方でも解除角の範囲外に存在すれば、ステップS104の処理に進む。何れも解除角の範囲内に存在すれば、そのままステップS105の処理に進む。
ステップS104では、制御部203は、ユニット化されていたプレイヤキャラクタと敵キャラクタのユニットを解除する。なお、ステップS102〜S104の処理は、バトルにおいてユニット化されているプレイヤキャラクタと敵キャラクタの組が2つ以上あれば、各々のユニットについて実行されるものとなる。そして、ステップS105の処理に進む。
ステップS105では、制御部203は、バトルにおいて接触状態となっているプレイヤキャラクタと敵キャラクタとが生じているかどうかを判定する。接触状態となっているプレイヤキャラクタと敵キャラクタとが生じていなければ、そのままステップS109の処理に進む。接触状態となっているプレイヤキャラクタと敵キャラクタとが生じていれば、制御部203は、当該接触状態となっているプレイヤキャラクタと敵キャラクタの移動ベクトルをプレイヤキャラクタテーブル400と敵キャラクタテーブル500とから読み出し、その何れかが0となっているかどうかを判定する(ステップS106)。何れかの移動ベクトルが0となっていれば、そのままステップS109の処理に進む。
何れも移動ベクトルが0となっていなければ、制御部203は、プレイヤキャラクタのユニット角の範囲内に敵キャラクタが存在し、且つ敵キャラクタのユニット角の範囲内にプレイヤキャラクタが存在するかどうかを判定する(ステップS107)。何れか一方でもユニット角の範囲内に存在しなければ、そのままステップS109の処理に進む。何れもユニット角の範囲内に存在すれば、制御部203は、接触状態にあるプレイヤキャラクタと敵キャラクタとをユニットとして設定する(ステップS108)。そして、ステップS109の処理に進む。
ステップS109では、制御部203は、ステップS108でユニットとして設定した、或いは前のフレーム期間までに既にユニットとして設定されたプレイヤキャラクタと敵キャラクタの重量をプレイヤキャラクタテーブル400と敵キャラクタテーブル500とから読み出し、その重量比を算出する。そして、算出した重量比に従って、ユニットに含まれるプレイヤキャラクタと敵キャラクタの移動ベクトルに重み付けをする。
制御部203は、この重み付けの処理を行った後のプレイヤキャラクタの移動ベクトルと敵キャラクタの移動ベクトルを合成し、ユニット全体の移動ベクトルを算出する(ステップS110)。なお、ステップS102〜S104の処理は、バトルにおいてユニット化されているプレイヤキャラクタと敵キャラクタの組が2つ以上あれば、各々のユニットについて実行されるものとなる。
次に、制御部203は、ステップS108でユニットとして設定した、或いは前のフレーム期間までに既にユニットとして設定されたプレイヤキャラクタと敵キャラクタを、ステップS110で合成した移動ベクトルに従って、バトルエリアにおいて移動させる(ステップS111)。制御部203は、また、ユニットとして設定されていないプレイヤキャラクタ及び敵キャラクタを、プレイヤキャラクタテーブル400または敵キャラクタテーブル500に登録されている移動ベクトルに従って、バトルエリアにおいて移動させる(ステップS112)。そして、このフローチャートの処理を終了する。
以上説明したように、この実施の形態にかかるネットワークゲームシステムでは、複数のプレイヤキャラクタ及び複数の敵キャラクタが仮想3次元空間に存在し、ゲームにおいてプレイヤキャラクタ(のパーティ)と敵キャラクタとのバトルが行われることがある。このバトルにおいて、プレイヤキャラクタも敵キャラクタもバトルエリア内で自由に移動することができるので、プレイヤキャラクタと敵キャラクタとが接触状態となることがある。プレイヤキャラクタと敵キャラクタとが接触状態となった場合は、それぞれに指示されている移動ベクトルによっては、プレイヤキャラクタと敵キャラクタとをそのままに移動させる訳にはいかない。
ここで、プレイヤキャラクタも敵キャラクタも、バトルエリア内を移動することができるものであるため、必ず固定状態にある構造物にキャラクタが接触した場合のようにプレイヤキャラクタと敵キャラクタとを移動させることができない。また、物理法則に従って物体同士が衝突した場合の動きをプレイヤキャラクタと敵キャラクタにそのまま適用しても、キャラクタの動きとしては非常に不自然なものとなってしまう。
これに対して、この実施の形態にかかるネットワークゲームシステムでは、プレイヤキャラクタの移動ベクトルの方向を中心としたユニット角の範囲内に敵キャラクタが存在し、且つ敵キャラクタの移動ベクトルの方向を中心としたユニット角の範囲内にプレイヤキャラクタが存在すると、接触状態にあるプレイヤキャラクタと敵キャラクタとをユニットとして設定する。そして、ユニットに含まれるプレイヤキャラクタの移動ベクトルと敵キャラクタの移動ベクトルをベクトル合成して、ユニット全体の移動ベクトルとして求めている。
ユニットに含まれるプレイヤキャラクタと敵キャラクタとは、何れもユニット全体について求められた移動ベクトルに従ってバトルエリアを移動されることになる。これにより、バトルにおいて別の方向に移動しようとしているプレイヤキャラクタと敵キャラクタとが押し合いをしながら、両者が一体となってバトルエリア内を移動していく様子を的確に再現することができる。
また、バトルにおいて接触状態にあるキャラクタをユニット化する対象とするのは、プレイヤキャラクタと敵キャラクタとが接触状態にあるときであり、プレイヤキャラクタ同士や敵キャラクタ同士では接触状態にあってもユニット化しない。プレイヤキャラクタ同士、或いは敵キャラクタ同士のような味方同士の場合、現実の世界であればその移動に譲り合いが見られるハズであるが、このような譲り合いが当然のものとならないプレイヤキャラクタと敵キャラクタという組み合わせでのみユニットとして設定するので、バトルエリア内を別方向に移動しようとする互いに敵対するキャラクタの押し合いにより、2体のキャラクタが一体となってバトルエリアを移動していく様子を的確に再現することができるものとなる。
また、プレイヤキャラクタと敵キャラクタとをユニット化する条件となるユニット角は、何れのキャラクタについても同じに設定されているのではなく、120°以上150°以下の範囲内で各キャラクタの大きさに応じて個別に設定されている。仮想3次元空間におけるプレイヤキャラクタ及び敵キャラクタの位置は、通常、その基準点(重心位置)の位置によって示されるので、キャラクタの移動ベクトルもその基準点からのベクトルとして計算されてしまう。
これに対して、大きなキャラクタの方が小さなキャラクタよりも、接触状態にある他のキャラクタの移動を規制することになるハズである。ここでは、プレイヤキャラクタと敵キャラクタの各々の大きさに応じてユニット角の大きさを個別に定めることによって、プレイヤキャラクタと敵キャラクタとの押し合いを各々の大きさに見合った的確な状態で再現することができるものとなる。
また、プレイヤキャラクタと敵キャラクタとが一旦ユニット化された後であっても、プレイヤキャラクタの移動ベクトルの方向を中心とした解除角の範囲外に敵キャラクタが存在するものとなったり、敵キャラクタの移動ベクトルの方向を中心とした解除角の範囲外にプレイヤキャラクタが存在するものとなった場合には、一旦設定されたユニットを解除して、プレイヤキャラクタと敵キャラクタとが各々の移動ベクトルに従って個別に移動されるようにしている。
ユニット化されて一体として移動が制御されることとなったプレイヤキャラクタと敵キャラクタの組であっても、各々が移動しようとする方向が変わればユニットを解除して個々のキャラクタ毎に移動した方が自然となることもあるが、ここでユニットを解除するための解除角をユニットを設定するためのユニット角よりも大きくしているため、プレイヤキャラクタと敵キャラクタとのユニットの設定と解除が頻繁になりすぎるのを防ぐことができる。
さらに、ユニットに含まれるプレイヤキャラクタと敵キャラクタの何れの移動ベクトルも0となった場合にも、一旦設定されたユニットを解除して、プレイヤキャラクタと敵キャラクタとが各々の移動ベクトルに従って個別に移動されるようにしている。プレイヤキャラクタと敵キャラクタの移動ベクトルが何れも0となってもユニット化したままでいると、プレイヤキャラクタも敵キャラクタも移動するハズがないのにユニット全体での移動ベクトルを求めるための無駄な処理が生じてしまう。ここでは、ユニットに含まれるプレイヤキャラクタと敵キャラクタの何れの移動ベクトルも0となった場合にユニットを解除するので、無駄な処理負荷を生じさせるのを防ぐことができる。
また、ユニット全体としての移動ベクトルを算出するのに当たって、プレイヤキャラクタと敵キャラクタとの重量比に応じて、プレイヤキャラクタの移動ベクトルと敵キャラクタの移動ベクトルに重み付けを行っている。ユニットを形成するプレイヤキャラクタと敵キャラクタの全体として一体した動きとしては、現実世界であれば単なるベクトル和で決まるのではなく、互いの重量の関係で拮抗したり、一方的となったりする場合がある。ここでは、ユニット全体の移動量を算出する際に、ユニットに含まれるプレイヤキャラクタと敵キャラクタの重量比に応じて重み付けを行っているので、ユニットに含まれるプレイヤキャラクタと敵キャラクタの移動が拮抗したり一方的となったりする様子を的確に再現することができるものとなる。
さらに、プレイヤキャラクタと敵キャラクタが存在する仮想空間は仮想3次元空間であり、プレイヤキャラクタと敵キャラクタとの移動ベクトルは3次元ベクトルで表されるものとなっているが、ユニットに含まれるプレイヤキャラクタと敵キャラクタの傾斜が所定の角度以下となっている場合(或いは、両者の高低差が所定量以下となっている場合)には、高さ方向を除いた2次元ベクトルでベクトル合成を行い、高さ方向のベクトル成分を0としてユニット全体の移動ベクトルを求めるものとしている。
ユニットに含まれるプレイヤキャラクタと敵キャラクタの傾斜が所定の角度以下となっている場合や、両者の高低差が所定量以下となっている場合には、プレイヤキャラクタと敵キャラクタの移動に対して高さ方向のベクトルはあまり関係しない。このような場合において、プレイヤキャラクタ及び敵キャラクタの3次元の移動ベクトルのうちの高さ方向のベクトルを除いた2次元ベクトルでユニット全体の移動量を算出することで、ベクトル演算の演算量を小さくすることができる。
本発明は、上記の実施の形態に限られず、種々の変形、応用が可能である。以下、本発明に適用可能な上記の実施の形態の変形態様について説明する。
上記の実施の形態では、プレイヤキャラクタ及び敵キャラクタの各々について、ユニット角及び解除角がプレイヤキャラクタテーブル400または敵キャラクタテーブル500に登録されていた。もっとも、ユニット角は、120°以上150°以下の範囲で設定するものに限られず、90°以上180°未満の範囲で設定することができる(但し、120°〜150°の範囲で、より良好な結果が得られる)。また、解除角も、ユニット角以上の角度(但し、180°未満)に設定するのであれば、130°以上160°以下の範囲に限られるものではない。
また、ユニット角及び解除角は、プレイヤキャラクタまたは敵キャラクタの大きさに応じて一義的に決まるものとし、プレイヤキャラクタテーブル400や敵キャラクタテーブル500への登録はなくてもよい。例えば、プレイヤキャラクタ及び敵キャラクタが、その大きさ毎に大、中、小の何れかに区分されるものとし、大のユニット角及び解除角は150°と160°、中のユニット角及び解除角は135°と145°、小のユニット角及び解除角は120°と130°となるものとしてもよい。
さらに、ユニット角及び解除角は、プレイヤキャラクタまたは敵キャラクタの移動ベクトルの方向を中心にその範囲が左右対称に設定されるものだけではなく、特殊な形態のキャラクタやキャラクタの状態などによっては左右非対称に設定されるものであってもよい。例えば、左右非対称の形態のキャラクタや左右の手足のうち一方を怪我したキャラクタなどに対して、左右非対称のユニット角及び解除角を設定することができる。但し、何れにしても移動ベクトルの方向はユニット角及び解除角の範囲内に含まれなければならず、この場合も移動ベクトルの方向を中心としてユニット角及び解除角が設定されると考えることができる。
上記の実施の形態では、バトルにおいて接触状態となったプレイヤキャラクタと敵キャラクタをユニット化するのは、プレイヤキャラクタのユニット角の範囲内に敵キャラクタが存在し、且つ敵キャラクタのユニット角の範囲内にプレイヤキャラクタが存在すると判定されたときとしていた。これに対して、ユニット角という概念を用いず、プレイヤキャラクタの移動方向と敵キャラクタの移動方向とがなす角が一定の角度(例えば、120°)以上となったことを条件として、バトルにおいて接触状態となったプレイヤキャラクタと敵キャラクタをユニット化してもよい。
一旦ユニット化されたプレイヤキャラクタと敵キャラクタのユニットを解除するのにも、解除角という概念を用いずに、プレイヤキャラクタの移動方向と敵キャラクタの移動方向とがなす角が一定の角度よりも小さい特定の角度(例えば、120°に対して110°)以下となったことを条件として、一旦設定されたプレイヤキャラクタと敵キャラクタのユニットを解除するものとしてもよい。
上記の実施の形態では、プレイヤキャラクタと敵キャラクタの双方ともに移動ベクトルが0となったときに、ユニットを解除するものとしていた。もっとも、ユニットの解除になるキャラクタの移動量は、0だけに限るものではなく、ほとんど移動が見られないような状態となった(つまり、移動量が所定値以下となった)ならば、ユニットを解除するものとしてもよい。また、プレイヤキャラクタの移動ベクトルについては敵キャラクタの方向に向けたベクトル成分、敵キャラクタの移動ベクトルについてはプレイヤキャラクタの方向に向けたベクトル成分が所定値以下となったならば、ユニットを解除するというようにしてもよい。
上記の実施の形態では、接触状態にあるプレイヤキャラクタと敵キャラクタのユニット全体での移動量をベクトル合成するときの各々のキャラクタの移動ベクトルに対する重み付けは、各々のキャラクタに設定された重量の比率に従って行うものとしていた。もっとも、この重み付けを、各々のキャラクタに設定された重量の比率に従って行うのではなく、各キャラクタの重量と移動量(ここではスカラー量)との積により求められる運動量に従って行うものとしてもよい。
また、重量比または運動量比に応じた移動ベクトルに対する重み付けの手法は、上記の実施の形態のような手法に限るものではなく、例えば、常に重量比そのままの重み付けとするものとしてもよい(この場合は、実質的に運動量のベクトルが合成されるものとなる)。常に重量比や運動量比の重み付けに、ランダムな重み付けを加えるものとしてもよい。また、そもそもユニット全体での移動量をベクトル合成するときの各キャラクタの移動ベクトルの重み付けを全く行わないものとしてもよい。
上記の実施の形態では、1体のプレイヤキャラクタと1体の敵キャラクタとが接触状態となったときに、プレイヤキャラクタのユニット角の範囲内に敵キャラクタが存在し、且つ敵キャラクタのユニット角の範囲内にプレイヤキャラクタが存在することを条件として、プレイヤキャラクタと敵キャラクタとの2体をユニットとして設定するものとしていた。もっとも、複数のプレイヤキャラクタがパーティーを組んでバトルを行ったり、バトルに登場する敵キャラクタが2体以上となることもあるので、3体以上のキャラクタが接触状態となることがある。
3体以上のキャラクタが接触状態となった場合においては、接触状態にある3体以上のキャラクタを1つのユニットとして設定することができる。3体以上のキャラクタをユニット化する手法も、基本的には2体のキャラクタをユニット化する手法と同じであるが、接触状態となったキャラクタの数、種類、或いは接触状態の態様に応じて特有の問題が生じ得る。以下、3体以上のキャラクタをユニット化する場合に特有の問題を挙げて説明する。図7は、3体のキャラクタが接触状態にある場合の移動制御を説明する図である。
図7(a)に示す例では、敵キャラクタ601とプレイヤキャラクタ611とがユニット600として設定されており、このユニット600を構成する敵キャラクタ601に別のプレイヤキャラクタ621が新たに接触した場合を示している。この場合、敵キャラクタ601とプレイヤキャラクタ621とが直接的に接触状態になったので、プレイヤキャラクタ621の移動ベクトル622の方向を中心としたユニット角623の範囲内に敵キャラクタ601が存在するかと、敵キャラクタ601の移動ベクトル602の方向を中心としたユニット角603の範囲内にプレイヤキャラクタ621が存在するかが判定される。
ユニット角623の範囲内に敵キャラクタ601が存在し、且つユニット角603の範囲内にプレイヤキャラクタ621が存在すると判定されると、既にユニット化されていた敵キャラクタ601とプレイヤキャラクタ611にプレイヤキャラクタ621を加えて、ユニット630が設定される。なお、この場合において、プレイヤキャラクタ611とプレイヤキャラクタ621とが接触状態になっているかどうかは問われず、接触状態となっていたとしても、プレイヤキャラクタ611とプレイヤキャラクタ621の移動方向に応じた判定は行われない。
図7(b)に示す例では、敵キャラクタ701とプレイヤキャラクタ711とがユニット700として設定されており、プレイヤキャラクタ711の単体での移動ベクトル712の方向ではなく、ユニット700全体に対して合成した移動ベクトル702にプレイヤキャラクタ711が移動しているものとする。この状態で、別の敵キャラクタ721がプレイヤキャラクタ711と接触状態になったものとする。
この場合、プレイヤキャラクタ711と敵キャラクタ721が直接的に接触状態になったので、プレイヤキャラクタ711の移動ベクトル712の方向を中心としたユニット角713の範囲内に敵キャラクタ721が存在するかと、敵キャラクタ721の移動ベクトル722の方向を中心としたユニット角723の範囲内にプレイヤキャラクタ711が存在するかが判定される。プレイヤキャラクタ711が実際に移動しているのは合成した移動ベクトル702であるものの、判定に用いられるのは、あくまで個別の移動ベクトル712の方である。
ここでは、ユニット角722の範囲内にプレイヤキャラクタ711が存在するものの、ユニット角712の範囲内に敵キャラクタ721は存在しないので、敵キャラクタ721は、敵キャラクタ701及びプレイヤキャラクタ711とはユニット化されない。既に設定されていた敵キャラクタ701とプレイヤキャラクタ711のユニット700は、そのままである。
図7(c)に示す例では、敵キャラクタ801とプレイヤキャラクタ811とがユニット800として設定されており、このユニット800を構成するプレイヤキャラクタ811に別のプレイヤキャラクタ821が新たに接触した場合を示している。この場合、敵キャラクタ801とプレイヤキャラクタ821とが直接的に接触状態になった訳ではないので、プレイヤキャラクタ821の移動ベクトル822の方向を中心としたユニット角823の範囲内に敵キャラクタ801が存在し、且つ敵キャラクタ801の移動ベクトル802の方向を中心としたユニット角803の範囲内にプレイヤキャラクタ821が存在したとしても、プレイヤキャラクタ821を敵キャラクタ801及びプレイヤキャラクタ811とユニット化しなくてもよい。
もっとも、プレイヤキャラクタ821の移動ベクトル822の方向を中心としてユニット角823よりも小さい角度範囲に設定された第2ユニット角824の範囲内にプレイヤキャラクタ821が存在する場合には、既にユニット化されていた敵キャラクタ801とプレイヤキャラクタ811にプレイヤキャラクタ821を加えて、ユニット830を設定することができる。
なお、図7(a)〜(c)では、プレイヤキャラクタと敵キャラクタとを合わせて合計3体のキャラクタとなる場合の例を説明したが、プレイヤキャラクタと敵キャラクタとを合わせて合計4体以上のキャラクタとなる場合についても、図7(a)〜(c)の場合と同様にユニット化するかどうかを決めることができる。
上記の実施の形態では、バトルにおいてプレイヤキャラクタと敵キャラクタとが接触状態となったときに、各々の移動方向に応じて接触状態にあるプレイヤキャラクタと敵キャラクタとをユニット化し、ユニット全体で移動量を求めてバトルエリアにおいて移動させるものとしていた。もっとも、このようなユニット化は、接触状態にあるプレイヤキャラクタと敵キャラクタに適用するのみならず、プレイヤキャラクタ同士、或いは敵キャラクタ同士が接触状態にある場合にも適用するものとしてもよい。また、バトル以外において仮想3次元空間において接触状態となった2体のキャラクタについてもユニット化するものとしてもよい。
上記の実施の形態では、ネットワークRPGにおいて仮想3次元空間に存在するキャラクタ(プレイヤキャラクタ及び敵キャラクタ)について、本発明を適用した場合を説明したが、仮想空間において複数のキャラクタが移動していくものであれば、ネットワークRPG以外のゲームにも適用することができる。本発明は、ネットワークゲームにもスタンドアロンのゲームにも、さらにはアドホック通信により通信対戦を行うゲームにも適用可能である。1人プレイのスタンドアロンのゲームでも、プレイヤキャラクタを含めて仮想空間を自由に移動可能な複数のキャラクタが存在する限り、本発明を適用することは可能である。
また、プレイヤキャラクタが所定の位置に到達することでバトルが開始するRPGに限らず、プレイヤキャラクタが仮想空間を移動しながら敵キャラクタとのバトルを行っていくアクションRPGや、プレイヤキャラクタと敵キャラクタ(或いは、他のプレイヤのプレイヤキャラクタ)とが格闘を行う対戦格闘ゲームにも、本発明を適用することができる。さらには、仮想空間を移動するキャラクタが複数存在するのであれば、ゲーム以外のものに対しても、本発明を適用することができる。また、仮想空間は、仮想3次元空間に限らず、仮想2次元空間であってもよい。
上記の実施の形態では、サーバ装置200のプログラム及びデータは、記録媒体231に格納されて配布されるものとしていた。これに対して、これらのプログラム及びデータをネットワーク上に存在する他のサーバ装置が有する固定ディスク装置に格納しておき、装置本体201にネットワークを介して配信するものとしてもよい。サーバ装置200において、通信インターフェイス215がサーバ装置から受信したプログラム及びデータは、HDD207に保存し、実行時にRAM205にロードすることができる。ビデオゲーム装置100のプログラム及びデータについても、同様である。