以下に添付図面を参照しながら,本発明の好適な実施形態について詳細に説明する。なお,以下の説明及び添付図面において,同一の構成及び機能を有する構成要素については,同一符号を付することにより,重複説明を省略する。
(第1実施形態)
(ネットワークゲームシステムの全体構成)
まず,本発明の第1実施形態にかかるネットワークゲームシステムの全体構成およびこのシステムにて実行されるゲームの概要について,図1を参照しながら説明する。
ネットワークゲームシステム10は,ネットワークゲームサーバ(以下,ゲームサーバと称呼する。)100と複数のゲーム機200(200a,200b,200c)とを含んで構成されている。ここでは,PC200aも,ゲーム機200として機能するので,以下の説明ではゲーム機200に含んで説明する。ゲームサーバ100と複数のゲーム機200とは,インターネット等のネットワーク(通信回線)300を介して接続されている。
ゲームサーバ100は,ネットワークゲームの進行および管理を制御する。具体的には,ゲームサーバ100は,主にチート対策,すなわち,不正行為の有無の判定とその排除や送受信データの整合性チェックを行う。また,ゲームサーバ100は,各ゲーム機200から種々のデータを受信したり,他のゲーム機200に種々のデータを一斉に送信する。ゲームサーバ100は,その他アイテム情報の管理(どのプレイヤが何を持っているか)やプレイヤにより操作されるプレイヤキャラクタの体力情報などを記憶管理している。ゲームサーバ100は,ネットワークゲームを提供する側のコンピュータ(サーバ機器)の一例であり,ネットワーク300に接続されたクライアント機器(ゲーム機器)の一つがゲームサーバ100として機能してもよい。
ゲーム機200は,プレイヤの操作に応じてネットワークゲームを遂行する。ゲーム機200は,ネットワークゲームに登場するキャラクタのうち,後述する管理キャラクタを管理する。ネットワークゲームに登場するキャラクタは,いずれかのゲーム機200に管理されるものとし,同じキャラクタが複数のゲーム機200により管理されることはない。
また,各ゲーム機200は,自分が管理しているキャラクタのキャラクタ情報を,ゲームサーバ100を介して他のゲーム機200に送り続ける。ここで,キャラクタ情報は,キャラクタのモーション等そのキャラクタの状態を示す情報である。また,各ゲーム機200は,他のゲーム機200から送信されたキャラクタ情報を受け取った時点でそのモーション処理(ゲーム上のキャラクタの動作処理)を開始する。また,ゲーム機200は,モーションと同じタイミングでコリジョン判定(当たり判定,衝突判定)を行う。
ゲーム機200は,ゲームサーバ100からサービスを受ける側のコンピュータ(クライアント機器)の一例であって,家庭用ゲーム装置であっても携帯ゲーム機であってもよい。クライアント機器の他の例としては,パーソナルコンピュータ(PC)の他に携帯デバイス(たとえば,携帯電話,PDA(Personal Digital Assistants))等のユーザ端末であってもよい。なお,各ゲーム機200は,TCP/IP等の通信プロトコルによりネットワーク300に接続され,各々異なるIPアドレスが割り振られているため,各プレイヤは,各種データを送受信したゲーム機200を各々識別することができる。
また,ゲーム機200は,たとえば,図2に示したように,ゲーム機本体200a1とコントローラパッド等200a2(入力装置)とテレビモニタ200a3とから構成されていてもよい。ゲーム機200aで使用されるプログラム,画像,音楽等の各種データがCD−ROM400(または,DVD)等の記録媒体に記録されている場合には,プレイヤ(ユーザ)は,CD−ROM400等の記録媒体をゲーム機本体200a1に挿入することによりゲームをスタートさせることができる。
(ネットワークゲームシステムの概要)
このように構成されたネットワークゲームシステム10では,複数のゲーム機200によりそれぞれ管理される複数のプレイヤキャラクタ,および,これら複数のプレイヤキャラクタのそれぞれ脇役となる複数のノンプレイヤキャラクタからなる複数のキャラクタが登場するネットワークゲームが提供される。そして,各ゲーム機200のプレイヤが各プレイヤキャラクタをそれぞれ操作することにより,複数のキャラクタがゲーム上で動作してゲームが進行する。以下の実施形態では,このネットワークゲームシステム10によって提供されるネットワークゲームとして,複数のプレイヤキャラクタとこれら複数のプレイヤキャラクタを護衛するノンプレイヤキャラクタとからなる複数のキャラクタが敵味方の集団を形成して互いに戦闘するゲームを例に挙げて説明する。
(集団戦闘ネットワークゲーム)
まず,このゲームの概要を説明する。あるプレイヤが,ネットワーク300に接続された自己のゲーム機200を用いて自己のプレイヤキャラクタを操作すると,このプレイヤキャラクタを小隊長とした複数の味方コンピュータキャラクタ(ノンプレイヤキャラクタ)で構成される自小隊がプレイヤの操作にしたがって画面上を移動し,武器を使って戦う。同時に,他のプレイヤが,ネットワーク300に接続された他ゲーム機200を用いて敵プレイヤキャラクタを操作すると,この敵プレイヤキャラクタを小隊長とした敵小隊が画面上を移動し,武器を使って戦う。プレイヤは,自己のプレイヤキャラクタを操作して戦闘することにより自己のプレイヤキャラクタのレベルや能力等のパラメータを上昇させたり,ネットワーク300を介して接続された他のプレイヤの領土を占領することができる。なお,このゲームに登場するキャラクタは,前述したように,プレイヤが操作可能なプレイヤキャラクタに限らず,各ゲーム機200による自動的な演算により動作するノンプレイヤキャラクタも存在し,プレイヤキャラクタとノンプレイヤキャラクタとがディスプレイ上に小隊を組んで表示される。本実施形態にかかる集団戦闘ネットワークゲームは,このようにしてネットワーク300を介して自小隊と味方小隊と敵小隊とが集団で対戦するゲームである。
集団戦闘ネットワークゲームには,8台のゲーム機200が4台ずつ敵味方に分かれて参加するものとする。参加する8人のプレイヤのうち,たとえば,4人を徳川軍,残りの4人を豊臣軍し,各軍は,4小隊で構成され,各小隊は1体のプレイヤキャラクタと最大79体のノンプレイヤキャラクタとから構成されるものとする。なお,以下の説明では,便宜上,各プレイヤが操作するプレイヤキャラクタをPC(Player Character)といい,このうち,自プレイヤが操作するプレイヤキャラクタを自PC,他プレイヤが操作する味方のプレイヤキャラクタを味方PC,他プレイヤが操作する敵のプレイヤキャラクタを敵PCという。
また,8体のPCをそれぞれ護衛するコンピュータキャラクタをNPC(Non Player Character,ノンプレイヤキャラクタ)といい,このうち,自プレイヤまたは味方プレイヤを護衛するノンプレイヤキャラクタを味方NPCといい,敵プレイヤを護衛するノンプレイヤキャラクタを敵NPCという。
たとえば,図11では,PC1が自PC,PC2およびPC4が味方PC,PC3が敵PCである。また,PC1,PC2およびPC4の周囲にてそれぞれの小隊境界線内に位置するNPC(NPC11を含む。)が味方NPC,PC3の周囲にて小隊境界線内に位置するNPC(NPC31を含む。)が敵NPCである。
(ノンプレイヤキャラクタの管理の原則)
つぎに,各キャラクタがどの機器によって管理されるかについて,その原則を説明する。まず,上述した複数の小隊のうち,自小隊に属する自PCおよびNPCは,原則として自己のゲーム機200に管理される。味方PCの他小隊に属する味方PCおよびNPCは,原則として味方PCを操作するゲーム機200に管理される。同様に,敵PCの他小隊に属する敵PCおよびNPCは,原則として敵PCを操作するゲーム機200に管理される。なお,PCをゲームサーバ100にて自動的に管理する場合(たとえば,ゲームに参加するプレイヤが足りず,1または2以上の敵PCまたは味方PCをゲームサーバ100にて自動管理することとなった場合)には,このPCの小隊に属するNPCもゲームサーバ100により自動的に管理されるように制御してもよい。これについては第3実施形態にて詳細を説明する。そして,以下の第1実施形態および実施形態2の説明では,すべてのNPCは,いずれかのゲーム機200により管理されることとする。
なお,本実施形態では,ネットワーク仮想空間上に存在するすべてのキャラクタは,いずれかのゲーム機200に管理されるようになっている。すなわち,各ゲーム機200は,自分が管理するキャラクタの位置,モーション情報(再生中のモーション番号,現在のフレーム番号)などを所定周期毎に演算し,演算された情報に基づいてキャラクタの動作をディスプレイに描画するとともに,演算されたデータをキャラクタ情報としてゲームサーバ100を介して他のゲーム機200に送信する。他のゲーム機200は,送信されたキャラクタ情報(詳細は後述)を受信し,受信した情報データに基づいてキャラクタの動作をディスプレイに描画するとともに,記憶領域に記憶されているキャラクタ情報を更新する。
このように,本実施形態のネットワークゲームシステム10は,完全非同期型(同一フレームで各ゲーム機のキャラクタ情報が食い違っていても,違ったままゲームを進行するタイプ)を採用する。これによれば,自ゲーム機200が操作する自PCが,自ゲーム機200によって管理される管理キャラクタを攻撃した場合には,自ゲーム機200により管理キャラクタの攻撃後のモーションが演算され,この演算結果により自ゲーム機200では,管理キャラクタのダメージモーションが即座に再生される。しかし,自ゲーム機200が操作する自PCが,他ゲーム機200が管理するキャラクタを攻撃した場合には,往復(自ゲーム機200→ゲームサーバ100→他ゲーム機200→ゲームサーバ100→自ゲーム機200)の通信時間が経過した後に,自ゲーム機200にて攻撃されたキャラクタのダメージモーションが再生されることになる。
この性質を利用して,PCと各NPCとの距離に応じて各NPCを管理するゲーム機200を切り替えることにより,各キャラクタのモーションの遅延を感じる機会を少なくすることができ,この結果,プレイヤの操作感覚を良好にすることができる。そこで,NPCは,敵味方に関係なくその座標から最も近いPCを管理するゲーム機200により管理されるようにする。以下に,この戦闘ゲームを管理するゲームサーバ100について説明し,ついで,ゲーム機200が各NPCの管理をどのように切り替えるのかについて説明する。
(ゲームサーバおよびゲーム機の内部構成)
まず,ゲームサーバ100およびゲーム機200のハードウエア構成について,図3および図4を参照しながら説明する。図3は,ゲームサーバ100のハードウエア構成を示し,図4は,ゲーム機200のハードウエア構成を示したものである。
図3のゲームサーバ100は,ROM105,ハードディスク(HDD)110,CPU115,RAM120,バス125,画像生成回路127,内部インタフェース(内部I/F)130および外部インタフェース(外部I/F)135を含んで構成されている。
ROM105には,ゲームサーバ100を動作させるための基本的なプログラムや,ゲームサーバ100が異常なときに起動するプログラム等が記録されている。ハードディスク110には各種プログラムやデータが蓄積されている。ハードディスク110は,記憶装置の一例であり,光ディスクや光磁気ディスクなどの記憶装置であってもよい。
CPU115は,ゲームサーバ100全体を制御する。CPU115は,ハードディスク110等に記憶されたプログラムをワーク用のRAM120にロードした後,そのプログラムを実行するようになっている。バス125は,ROM105,ハードディスク110,CPU115,RAM120,画像生成回路127,内部インタフェース130および外部インタフェース135の各デバイス間で情報をやりとりする経路である。
画像生成回路127は,グラフィックチップとVRAMとから構成されていて,CPU115から画像の生成を指示されると,その指示に従ってCPU115とは別な時系列で画像を生成する。
内部インタフェース130は,キーボード405やマウス410からネットワークゲームに関するデータを入力し,必要なデータをモニタ415に出力するようになっている。外部インタフェース135は,ネットワーク300を介してゲームに参加している他のゲーム機200と各種データを送受信するようになっている。
図4のゲーム機200は,ROM205,ハードディスク(HDD)210,CPU215,RAM220,バス225,画像生成回路227,音響再生回路229,内部インタフェース230,外部インタフェース235およびリーダ240を含んで構成されている。
ROM205には,ゲームを実行させるためのプログラム等が記録されている。ハードディスク210には各種プログラムや各種データが蓄積されている。ハードディスク210は,記憶装置の一例であり,光ディスクや光磁気ディスクなどの記憶装置であってもよい。
CPU215は,ゲーム機200全体を制御する。CPU215は,ハードディスク210に記憶されたプログラムをゲーム機200内のワーク用のRAM220にロードする。または,CPU215は,リーダ240が読み込んだCD−ROM400内のプログラムをRAM220にロードする。CPU215は,このようにしてRAM220にロードされたプログラムを実行することによりゲームをスタートさせ,ゲームサーバ100と逐次通信しながらゲームを進行するようになっている。
なお,一旦,CPU215が,記録媒体上のプログラム等をRAM220上にコピーしてしまえば,次回からはRAM220上のプログラム等を実行することによりゲームをスタートすることができる。また,一旦,CPU215が,ゲーム機200内のハードディスク210に,CD−ROM400上のプログラム等をコピーしてしまえば,次回以降は,ハードディスク210上のプログラムを実行することによりゲームをスタートすることもできる。また,ネットワーク300上にこれらのプログラム等がアップロードされている場合には,CPU215が,一旦,これらのプログラムをゲーム機200のRAM220にダウンロードした後,そのプログラムをスタートさせるようにしてもよいし,一旦,ゲーム機200のハードディスク210にこれをダウンロードし,次回以降は,ハードディスク210に記憶されたプログラムを起動させることによりゲームをスタートさせるようにしてもよい。
バス225は,ROM205,ハードディスク210,CPU215,RAM220,画像生成回路227,音響再生回路229,内部インタフェース230,外部インタフェース235およびリーダ240の各デバイス間で情報をやりとりする経路である。
画像生成回路227は,グラフィックチップとVRAMとから構成されていて,CPU215から画像の生成を指示されると,その指示に従って画像を生成する。音響再生回路229は,サウンドチップとサウンドRAMとから構成されていて,CPU215からサウンドの生成を指示されると,その指示に従って各管理キャラクタの戦闘動作に対応したバックミュージックや戦闘音等の音響処理を行う。
内部インタフェース230は,コントローラパッド430やキーボード435やマウス440等を用いてプレイヤのゲーム操作を入力するとともに,敵味方の集団を形成して互いに戦闘する複数のキャラクタの映像および音響をモニタ445およびスピーカ450にそれぞれ出力するようになっている。外部インタフェース235は,ネットワーク300を介して,プレイヤによる操作に応じたコマンドやメッセージ等の各種データをゲームサーバ100に送受信するようになっている。リーダ240は,CD−ROM400からデータを読み込む。
つぎに,ゲームサーバ100およびゲーム機200の機能構成について,図5および図6を参照しながら説明する。
(ゲームサーバの機能構成)
図5に示したように,ゲームサーバ100は,入力部140,通信部145,記憶部150,管理部155,画像処理部160および画像生成部165の機能ブロックにて示される各機能を有している。
入力部140は,ネットワークゲームを管理する管理者によるキーボード405またはマウス410の操作に応じてデータを入力する。通信部145は,ゲームに参加している複数のゲーム機200に必要な情報を送受信する。
記憶部150は,複数のキャラクタ(プレイヤキャラクタPCおよびノンプレイヤキャラクタNPC)の位置情報と各ノンプレイヤキャラクタNPCを各々管理するゲーム機200の識別情報とを含んだキャラクタ情報を記憶する。
管理部155は,ゲーム中のデータの整合性を保ち,ゲームを矛盾なく進行させるために,入力部140により入力されるデータ,通信部145により送受信されるデータ,記憶部150の各記憶領域(ROM105,RAM120,ハードディスク110)に記憶されたデータを管理したり,ゲーム中の各処理のタイミングを管理する。
画像処理部160は,ゲームの進行に会わせて必要なパラメータとコマンドとを生成し,これらを画像生成部165に出力することにより,画像生成部165に画像の生成を指示するようになっている。画像生成部165は,画像処理部160からの画像の生成の指示を受けて,光源処理等を行い,キャラクタ情報にしたがった各管理キャラクタの戦闘動作を3次元フィールドでモニタ445に描画する。
(ゲーム機の機能構成)
図6に示したように,ゲーム機200は,媒体読取部245,入力部250,記憶部255,アクション処理実行部260,画像生成部265,音響再生部270,判定部275および通信部280の機能ブロックにて示される各機能を有している。
媒体読取部245は,CD−ROM400等の記録媒体に記憶されたデータを読み込む。たとえば,プレイヤが,CD−ROM400をゲーム機200に挿入してゲームをスタートすると,媒体読取部245は,自動的にそのプログラム等のデータを読み込み,RAM220に転送するようになっている。
入力部250は,プレイヤが,モニタ445に表示されるネットワークゲームの画面を見ながら,ゲーム機200に接続されたゲームコントローラパッド430,キーボード435,マウス440等の入力装置を操作すると,この操作に応じてデータを入力する。
記憶部255は,複数のキャラクタの位置情報を含んだキャラクタ情報をRAM220に記憶するとともに,ノンプレイヤキャラクタのうち自己のゲーム機200が管理するキャラクタを管理キャラクタとしてRAM220に登録する。
ここで,RAM220に記憶される各情報について図7を参照しながら説明する。図7は,RAM220に記憶されたキャラクタ情報のデータ構造の一例を示す。
RAM220には,まず,プレイヤキャラクタのうち,自ゲーム機器200により管理される自プレイヤキャラクタ(自PC0)のPCデータが記憶される。RAM220には,自PC0のキャラクタ情報として,PC番号,座標(x,y,z),キャラクタの体の向き(角度),モーション番号,再生フレーム位置,進行方向,所属軍,管理中のキャラクタ数が保持される。
PC番号には,自PC0を管理するゲーム機(CL,クライアント機器)の識別番号が付けられている。ここでは,PC番号として「0」が登録されているが,この番号は,そのPCを管理するゲーム機を識別できる情報であればこれに限られない。
座標(x,y,z)は,仮想空間上のキャラクタの位置を示す。モーション番号は,予め作成されたキャラクタの動作(モーション)を示すモーションデータの番号を示す。各モーションデータには,固有のモーション番号が付けられ,そのデータ自体は,各ゲーム機200のハードディスク210等の記録媒体上に記録されている。
キャラクタの動作は,フレーム(画像処理の時間的単位)毎に描画されるので,再生フレーム位置は,モーション番号に示されるモーションが再生されるフレームの位置を示す。進行方向は,キャラクタが進行する方向をベクトルで示したものである。所属軍は,自PC0が属する軍であり,現在は味方の「徳川」であるが,敵の軍に所属する場合もある。管理中のキャラクタ数は,自ゲーム機200にて管理されている管理キャラクタ(ノンプレイヤキャラクタNPC)の数を示していて,79以下の数値を取るようになっている。
また,RAM220には,自プレイヤキャラクタ(自PC0)を護衛する79体の自ノンプレイヤキャラクタ(自NPC1〜自NPC79)のキャラクタ情報が記憶される。ノンプレイヤキャラクタ(NPC)のキャラクタ情報が,プレイヤキャラクタ(PC)のキャラクタ情報と異なる点は,プレイヤキャラクタ(PC)では,最後に「キャラクタ情報に管理中のキャラクタ数」が含まれていたのに対し,ノンプレイヤキャラクタ(NPC)では,最後に「キャラクタ情報に管理元のPC番号」が含まれている点である。たとえば,自ノンプレイヤキャラクタ1(自NPC1)の管理元のPC番号は,「0」である。これは,自NPC1が,自PC0の管理キャラクタとしてRAM220に登録されていることを示している。
また,RAM220には,7体の他プレイヤキャラクタ(他PC1〜他PC7)のキャラクタ情報が記憶されるとともに,各他プレイヤキャラクタを各々護衛する他ノンプレイヤキャラクタ(他NPC1−1〜他NPC1−79,他NPC2−1〜他NPC2−79他,他NPC3−1〜他NPC3−79,他NPC4−1〜他NPC4−79,他NPC5−1〜他NPC5−79,他NPC6−1〜他NPC6−79,他NPC7−1〜他NPC7−79)のキャラクタ情報が記憶されている。このようにして,RAM220には,ゲームに登場するすべて(=640体)のキャラクタのキャラクタ情報が記憶され,これらの情報を用いて,戦闘ゲーム中の各キャラクタが次にとるアクションが演算されたり,どのキャラクタを自ゲーム機200にて管理しなければならないかが判定される。
再び,図6に戻って,アクション処理実行部260は,演算部260a,画像処理部260bおよび音響処理部260cを有する。アクション処理実行部260は,記憶部255に登録されている各管理キャラクタのアクション処理を管理キャラクタ毎に実行する。具体的には,演算部260aは,記憶部255に記憶されたキャラクタ情報を用いて,ゲーム上の戦闘によって発生する各管理キャラクタの位置の変化および動作の変化を表す変化量をそれぞれ演算することにより変化後のキャラクタ情報を生成する。
画像処理部260bは,ゲームの進行に会わせて必要なパラメータとコマンドとを生成し,これらを画像生成部265に出力することにより,画像生成部265に画像の生成を指示する。画像生成部265は,画像処理部260bからの画像の生成の指示を受けて,画像を生成し,生成された画像をモニタ445に表示する。
音響処理部260cは,音響再生部270にサウンドの再生を指示する。音響再生部270は,各管理キャラクタの戦闘動作に対応したバックミュージックや戦闘音等の音響処理を行い,スピーカ450に出力する。このようにして表現される臨場感あふれる画像や音響を通じて,プレイヤは,自分のプレイヤキャラクタをそのネットワークゲームの仮想空間内で移動させたり,他のキャラクタと戦わせることができる。
判定部275は,演算部260aにより演算された各管理キャラクタの位置の変化値に基づいて,自己のゲーム機200が管理するプレイヤキャラクタの位置と,他のゲーム機200が管理するプレイヤキャラクタの位置と,各管理キャラクタのアクション処理後の位置との相対関係を求め,求められた位置の相対関係に基づき各管理キャラクタを管理するか否かを判定する。
通信部280は,演算部260aにより演算された変化後の各管理キャラクタのキャラクタ情報をキャラクタ情報パケットとしてゲームサーバ100に送信する。また,通信部280は,他のゲーム機200により管理されると判定された管理キャラクタのキャラクタ情報をキャラクタ管理変更パケットとしてゲームサーバ100に送信する。なお,同一内容であっても,本明細書及び図面中では,RAM220等のメモリ内に保持しているデータの場合は「〜情報」と表記し,送受信するデータの場合は「〜パケット」と表記する。
さらに,通信部280は,ゲームサーバ100から送信されたキャラクタ情報パケットを受信する。すなわち,通信部280は,ネットワークゲーム内で起こった変動結果の情報や,他のプレイヤにより送信され,ゲームサーバ100を介して転送される情報,或いはゲームサーバ100が自発的に送信する情報等種々のデータを受信する。
このようにして受信されたキャラクタ情報または演算部260aにより演算されたキャラクタ情報に基づいて,アクション処理実行部260が,アクション処理を管理キャラクタ毎に実行することにより,ゲーム機200とゲームサーバ100とが逐次通信しながらネットワークゲームが進行するようになっている。
なお,以上に説明したゲームサーバ100およびゲーム機200の各機能は,実際には,CPUがこれらの機能を実現する処理手順を記述したプログラムを実行することにより,または,いずれかの機能を実現するためのハードウエアやICを制御することにより達成される。たとえば,図5に示したゲームサーバ100の管理部155および画像処理部160の機能は,これらの機能を実現する処理手順を記述したプログラムを図3のCPU115が実行することにより達成され,画像生成部165の機能は,グラフィックチップ(画像生成回路127)により達成される。また,図6に示したゲーム機200のアクション処理実行部260および判定部275の機能は,これらの機能を実現する処理手順を記述したプログラムを図4のCPU215が実行することにより達成され,画像生成部265および音響再生部270の機能は,グラフィックチップ(画像生成回路227)およびサウンドチップ(音響再生回路229)によりそれぞれ達成される。
以上に説明した本実施形態にかかるネットワークゲームシステム10では,まず,プレイヤが,自己のゲーム機200を用いて自分が担当するプレイヤキャラクタを選択する。プレイヤキャラクタには,例えば戦国時代をテーマとしたゲームであれば,侍,忍者,陰陽師等があり,通常はこれらの中から1つを選択する。その後,プレイヤは,自分のプレイヤキャラクタを操作して戦闘することによりプレイヤキャラクタのレベルや能力等のパラメータを上昇させたり,ネットワーク300を介して接続された他のゲーム機200を操作する他のプレイヤのキャラクタと戦う。なお,この仮想空間に登場するキャラクタは,いわゆるプレイヤが操作するプレイヤキャラクタに限らず,各ゲーム機200による自動的な演算により動作するノンプレイヤキャラクタ(NPC)も存在し,これらのキャラクタが各ゲーム機200の画面に表示される。
(ゲーム機の動作,アクション処理およびキャラクタ管理処理)
つぎに,ゲーム機200の動作について,図8〜図10を参照しながら説明することにより,本実施形態の特徴であるアクション処理およびキャラクタ管理処理について詳述する。図8は,各ゲーム機200が実行するクライアント側管理処理(メインルーチン)を示したフローチャートである。図9は,図8のメインルーチンにて呼び出されるキャラクタ管理処理を示したフローチャートである。図10は,図9のサブルーチンにて呼び出されるキャラクタ変更判定処理を示したフローチャートである。なお,自プレイヤの小隊と他のプレイヤの小隊との動作に関しては同様な処理がなされるため,以下のフローチャートにおいては,説明を簡単にするために,自プレイヤの小隊を中心に記載し,他のプレイヤの小隊を中心とした記載を省略する。また,その他のゲーム上必要ではあるが本願発明と直接関係のない具体的な処理の説明は省略するものとする。
また,このネットワークゲームを開始する前に,プレイヤは予めユーザ登録しておく必要がある。すなわち,プレイヤは,ゲーム機200の画面に表示される指示に従って個人情報を入力することにより,ゲームサーバ100に個人情報等を送信し,ユーザID及びパスワードを取得する。2回目以降にゲームを行うときには,プレイヤは,取得したユーザID及びパスワードを画面に入力するだけでゲームサーバ100にアクセスすることができるようになる。
(ゲームスタート)
ゲーム機200の電源が「ON」され,プレイヤからゲームの開始が要求されると,図8のステップ800から処理が開始され,ステップ805にて初期設定が行われる。具体的には,記憶部255は,プレイヤによって選択されたプレイヤキャラクタ(自PC)および各キャラクタのキャラクタ情報をRAM220に予め登録する。また,通信部280は,ユーザ認証し,その後,ゲームサーバ100との間で各キャラクタのキャラクタ情報を送受信する。これにより,ゲームサーバ100およびゲームに参加しているすべてのゲーム機200のRAMに,図7にて示した各キャラクタのキャラクタ情報が予め登録される。さらに,ゲームサーバ100は,各キャラクタを管理するゲーム機200をすべてのキャラクタについてそれぞれ特定し,ゲームサーバ100および各ゲーム機200のRAM(具体的には,図7に示した管理元のPC番号の項目)に記憶する。なお,ゲームサーバ100には,必ずしも,各キャラクタのキャラクタ情報を記憶しておく必要はない。
つぎに,ステップ810にて,判定部275は,割込み(垂直帰線割込(Vsync))が発生したか否かを判定する。判定部275は,モニタ445の垂直帰線周期と一致した1/60秒(16.6ミリ秒)に一度の周期で割込みが発生すると,これに応じて,ステップ810にて「YES」と判定し,ステップ815に進んでキャラクタ管理処理を実行する。キャラクタ管理処理については後述する。
つぎに,判定部275は,ステップ820に進んでゲームが終了か否かを判定する。具体的には,プレイヤが,ゲーム機200の電源を「OFF」するか,または,画面上のゲーム終了を選択することによりゲームは終了する。そこで,プレイヤがこれらのいずれかの操作をするまで,ゲーム機200は,基本的に,ステップ810〜ステップ820の処理を繰り返し,プレイヤがこれらのいずれかの操作をするとステップ895に進んでゲームを終了する。
ステップ810で割込みが発生していない場合,判定部275は,「NO」と判定してステップ825でメイン処理を実行し,その後ステップ820に進む。このメイン処理においては,本実施形態におけるネットワークゲームと直接関係しないその他の処理,例えば,プレイヤがコントローラパッド430等を操作することにより入力され,入力部250を介して取り込まれた入力情報を,RAM220に記憶して随時更新する処理や,ゲーム効果音を音響処理部260cおよび音響再生部270を用いて合成させるための音響処理等の処理も,ここで実行するものとする。また,本実施形態では,一定間隔でクライアント側管理処理が行われる例(すなわち,垂直帰線周期の割込処理内でキャラクタ管理処理が行われる例)を示したが,図示しないタイマー割込処理内やステップ825のメイン処理内でキャラクタ管理処理が行われるようにしてもよい。
(キャラクタ管理処理)
つぎに,ステップ815のキャラクタ管理処理について,図9のフローチャートを参照しながら説明する。ステップ900から処理が開始されると,通信部280は,ステップ905にて,他のゲーム機200から送信されたキャラクタ管理変更パケットを受信したか否かを判定する。キャラクタ管理変更パケットを受信した場合には,ステップ910に進んで,記憶部255は,キャラクタ管理変更パケットに含まれるキャラクタ情報に基づきRAM220の該当キャラクタ情報を更新する。具体的には,図7の該当PCまたは該当NPCに記憶された座標,体の向き,モーション番号,再生フレーム位置,進行方向,所属軍の情報を更新する。また,記憶部255は,このキャラクタ情報により特定されるキャラクタを管理キャラクタとしてRAM220に登録する。具体的には,図7の該当キャラクタ情報の管理元のPC番号を変更する。
つぎに,ステップ915に進み,通信部280は,ステップ915にて,他のゲーム機200からキャラクタ情報パケットを受信したか否かを判定する。キャラクタ情報パケットを受信した場合には,ステップ920に進んで,記憶部255は,キャラクタ情報パケットに含まれるキャラクタ情報に基づきRAM220の該当キャラクタ情報を更新する。具体的には,図7の該当PCまたは該当NPCに記憶された座標,体の向き,モーション番号,再生フレーム位置,進行方向,所属軍の情報を更新する。なお,フレームとは,画像処理の時間的単位であり,描画の際のいわゆる「コマ」を示している。本実施形態では,1フレームの時間は,垂直帰線割込処理の周期の1/2の時間(1/30秒)に相当する。
ついで,ステップ925に進んで,アクション処理実行部260は,アクション処理を実行する。アクション処理とは,具体的には,アクション処理実行部260の各部により実行されるつぎの処理をいう。まず,演算部260aは,RAM220に記憶されたキャラクタ情報(具体的には,自ゲーム機の管理キャラクタ情報および他ゲーム機の管理キャラクタ情報の相対関係)に基づき,プレイヤの操作に応じて各管理キャラクタの位置の変化量および動作の変化量を含んだキャラクタ情報を演算する。管理キャラクタ毎にこの演算を行うことにより,各キャラクタは,攻撃が当たったらダメージモーションに移行するなどのアクションを行うことができる。
また,画像処理部260bは,画像生成部265に画像の生成を指示し,画像生成部265は,これを受けて,演算後のキャラクタ情報に基づいて各キャラクタの仮想空間上の位置および動作をグラフィック処理する。また,音響処理部260cは,音響再生部270に音響の生成を指示し,音響再生部270は,これを受けて,演算後のキャラクタ情報に基づいて各キャラクタの状態にあった音響を生成する。この結果,各プレイヤの操作に応じたキャラクタの動作がモニタ445に表示されると同時に,ゲームの展開に応じた音響がスピーカ450から出力されることにより,各プレイヤの操作に応じたゲームが展開される。
つぎに,ステップ930に進み,判定部275は,キャラクタ変更判定処理(サブルーチン)を実行する。この処理は,各管理キャラクタの位置と敵PCおよび味方PCおよび自PCの位置との関係から当該キャラクタが管理されるべきゲーム機200を判定する処理であるが,後程詳述する。
ついで,ステップ935に進み,通信部280が,演算部260aにより演算された各管理キャラクタのキャラクタ情報を,ゲームサーバ100を介して他のゲーム機200に送信する。このように最新のキャラクタの状態を他のゲーム機200に送信することにより,通信時間だけ遅延が生じた状態ではあるが,他のゲーム機200に記憶された各キャラクタのキャラクタ情報が更新される。これにより,データの整合性を保つことができる。
(キャラクタ変更判定処理)
つぎに,ステップ930に示したキャラクタ変更判定処理について,図10を参照しながら,詳細に説明する。
ステップ1000からキャラクタ変更判定処理が開始され,ステップ1005に進むと,演算部260aは,管理キャラクタとして登録されているNPC(図7の該当NPCの座標)と最寄の敵PC(図7の該当敵PCの座標)との距離DEPCを求める。たとえば,図11に示したように,自PC1の小隊が,敵PC3の小隊を攻撃するために,敵PC3の小隊に向かっている場合,ステップ1005では,図12に示したように,当該NPC(NPC11)と敵PC3との距離DEPCが演算される。
つぎに,ステップ1010に進み,判定部275は,NPC11を管理するゲーム機200(この時点では自ゲーム機)のPC(すなわち,自PC1)が,NPC11の味方であるか否かを判定する。この時点では,自PC1は,NPC11の味方であるので,判定部275は,ステップ1015に進み,距離DEPCがマージンMC(=50)より小さいか否かを判定する。この時点では,PC3は,NPC11を中心とした半径がマージンMCの円内まで近づいていないので,距離DEPCはマージンMCより大きい。そこで,ステップ1020に進んで,演算部260aは,NPC11と自PC1との距離Dを求め,ステップ1025にて,NPC11と最寄の味方PC(=PC2)との距離DAPCを求める。
つぎに,ステップ1030に進んで,判定部275は,距離DAPCにマージンMD(=50)を加算した値が距離Dより小さいか否かを判定する。この時点で,距離DAPC+マージンMDの値は距離Dより大きい。すなわち,PC2は,NPC11を中心とした半径が(距離D−マージンMD)の円内まで近づいていない。そこで,判定部275は,(NPC11の管理を他のユーザ機200に変更することなく),ステップ1035に進み,管理中のすべてのNPC(すなわち,管理キャラクタ)についてキャラクタ変更判定処理を実行するまで,ステップ1005に戻って各管理キャラクタの変更判定処理を続け,すべての管理キャラクタについて,この変更判定処理を終えると,ステップ1095にて本処理を終了する。
つぎに,図11に示したPC2の小隊のみが,PC1の小隊に接近した場合のキャラクタ変更判定処理について説明する。このとき,図13に示したように,味方PC2は自PC1よりマージンMD以上NPC11の近くに位置しているので,判定部275は,ステップ1000〜ステップ1025に続くステップ1030にて「YES」と判定し,ステップ1040に進んで,味方PC管理変更処理を実行する。
(味方PC管理変更処理)
具体的には,図14に示したように,判定部275は,ステップ1400から味方PC管理変更処理を開始して,ステップ1405に進み,最寄の味方PC(=PC2)と当該NPC(=NPC11)を管理しているゲーム機200のPC(=PC1)とが,同一か否かを判定する。ここでは同一でないので,判定部275は,ステップ1410に進んで,最寄の味方PC(=PC2)のゲーム機が管理している管理キャラクタ数が79以上であるか否かを判定する。PC2を管理しているゲーム機が管理している管理キャラクタ数が79より少ないと,記憶部255は,ステップ1415に進んで,RAM220に記憶されているPC2に関するキャラクタ情報のうち,管理中のキャラクタ数を1つ増やし,ステップ1420に進んで,現時点でNPC(=NPC11)を管理しているゲーム機(CL)により管理されているPC(=PC1)の管理中のキャラクタ数を1つ減らす。
ついで,ステップ1425に進んで,通信部280は,当該NPC(=NPC11)の管理を,PC1を管理するゲーム機200からPC2を管理するゲーム機200に変更する情報を含んだ管理変更パケットを,ゲームサーバ100を介して他のゲーム機200に送信し,ステップ1495に進んで本処理を終了する。このように,味方PC2が自PC1よりマージンMD以上NPC11の近くに位置している場合,敵PC2を管理するゲーム機が,NPC11(管理キャラクタ)を管理するように管理キャラクタが切り替わる。
なお,ステップ1405にて,最寄の味方PCと当該NPCを管理しているゲーム機200のPCとが同一の場合には,管理キャラクタの管理変更を行う必要がなく,また,ステップ1410にて,最寄の味方PCのゲーム機200が管理している管理キャラクタ数が79以上である場合には,そのゲーム機が管理する管理キャラクタをこれ以上増やすことが適当でないので,いずれも当該管理キャラクタを変更することなく,ステップ1495に進んで本処理を終了する。
つぎに,図11の状態から図15の状態にゲームが展開した場合(すなわち,自PC1の小隊と敵PC3の小隊と味方PC2の小隊とが集団戦闘状態にある場合)のキャラクタ変更判定処理について説明する。この場合,図16に示したように,NPC11には味方PC2が最も近接しているが,敵PC3もNPC11を中心とした半径がマージンMCの円内に存在する。このとき,図10のステップ1000からキャラクタ変更判定処理を開始して,判定部275は,ステップ1005,ステップ1010に続くステップ1015にて「YES」と判定し,ステップ1045に進んで,敵PC管理変更処理を実行する。
(敵PC管理変更処理)
具体的には,図17に示したように,判定部275は,ステップ1700から敵PC管理変更処理を開始して,ステップ1705に進み,最寄の敵PC(=PC3)と当該NPC(=NPC11)を管理しているゲーム機200のPC(=PC1)とが,同一か否かを判定する。ここでは同一でないので,判定部275は,ステップ1710に進んで,最寄の敵PC(=PC3)のゲーム機が管理している管理キャラクタ数が79以上であるか否かを判定する。PC3を管理しているゲーム機が管理している管理キャラクタ数が79より少ないと,ステップ1715に進んで,記憶部255は,RAM220に記憶されているPC3に関するキャラクタ情報のうち,管理中のキャラクタ数を1つ増やし,ステップ1720に進んで,現時点でNPC(=NPC11)を管理しているゲーム機により管理されているPC(=PC1)の管理中のキャラクタ数を1つ減らす。
ついで,ステップ1725に進んで,通信部280は,当該NPC(=NPC11)の管理を,PC1を管理するゲーム機200からPC3を管理するゲーム機200に変更する情報を含んだ管理変更パケットを,ゲームサーバ100を介して他のゲーム機200に送信し,ステップ1795に進んで本処理を終了する。このように,NPC11に対して,味方PC2および敵PC3の両方が近接した場合,敵PC3を管理するゲーム機が,味方PC2を管理するゲーム機より優先してNP131(管理キャラクタ)を管理するように管理キャラクタが切り替わる。
なお,図14の味方PC管理変更処理と同様に,ステップ1705またはステップ1710にて「YES」と判定された場合には,いずれも当該管理キャラクタを変更することなく,ステップ1795に進んで本処理を終了する。
この時点では,図15に示したように,NPC11の管理はPC3に切り替わっている。同様にして,PC3を管理するゲーム機200が,垂直帰線割込み毎に図10に示したキャラクタ変更判定処理を実行することによりNPC31の管理がPC1に切り替わった(PC1を管理するゲーム機200のRAM220にNPC31が管理キャラクタとして登録された)後,ゲームが図18に示した状態に展開した場合(すなわち,PC1がPC3に接近した(図15)後,PC3から少し遠ざかった(図18)場合)について,つぎに説明する。
この場合,NPC31,自PC1,味方PC2および敵PC3との関係は図19に示したようになる。この状態で,図10のキャラクタ変更判定処理が実行されると,ステップ1000,1005に続くステップ1010にて,判定部275は,NPC31は,NPCを管理するゲーム機が操作するPC(=PC1)の敵であると判定する。そこで,ステップ1050に進み,演算部260aは,NPC31とPC1との距離Dを求める。続いて,ステップ1055にて,判定部275は,距離DEPCにマージンMAを加算した値が距離Dより小さいか否かを判定する。この時点では,距離DEPC+マージンMAの値は距離Dより大きい。そこで,ステップ1060に進み,演算部260aは,NPC31と最寄の味方PC(=PC2)との距離DAPCを求める。
つぎに,ステップ1065に進んで,判定部275は,距離DAPCにマージンMBを加算した値が距離Dより小さいか否かを判定する。この時点では,距離DAPC+マージンMBの値は距離Dより大きい。そこで,ステップ1035に進み,RAM220に登録されているすべての管理キャラクタの処理を終えるまでステップ1005に戻って各管理キャラクタの変更判定処理を実行する。
つぎに,図20に示したように,NPC31に対して味方PC2および敵PC3が近接した場合であって,敵PC3は自PC1よりマージンMA以上NPC31の近くに位置している場合について説明する。この状態で,図10のキャラクタ変更判定処理が実行されると,ステップ1000〜1010,ステップ1050に続くステップ1055にて,判定部275は,「YES」と判定し,ステップ1070に進んで,図17の敵PC管理変更処理を実行する。すなわち,ステップ1700〜1725を実行することにより,NPC31の管理が,PC1を管理するゲーム機200からPC3を管理するゲーム機200に切り替わる。このように,NPC31に対して味方PC2および敵PC3の両方が近接した場合であって,敵PC3が自PC1よりマージンMA以上NPC31の近くに位置している場合,敵PC3を管理するゲーム機が,味方PC2を管理するゲーム機より優先してNPC31(管理キャラクタ)を管理するように管理キャラクタが切り替わる。
一方,ゲームの状態が,図19の状態から図21の状態(すなわち,敵PC3が自PC1よりマージンMA以上NPC31の近くに位置していない場合であって,かつ,味方PC2が自PC1よりマージンMB以上NPC31の近くに位置している状態)に遷移した場合について説明する。この状態で,図10のキャラクタ変更判定処理が実行されると,ステップ1000〜1010,ステップ1050〜1060に続くステップ1065にて,判定部275は,「YES」と判定し,ステップ1040に進んで,図14の味方PC管理変更処理を実行する。すなわち,ステップ1400〜1425を実行することにより,NPC31の管理が,PC1を管理するゲーム機200からPC2を管理するゲーム機200に切り替わる。
(マージンの設定)
以上に説明した図10のキャラクタ変更判定処理では,当該NPCの管理を切り替える対象となるPC(敵PC,味方PC)毎に所定のマージン(マージンMA,MB,MC,MD)を設けた。これは,他のゲーム機200が管理するPCの位置が自PCの管理キャラクタ(当該NPC)に最も近い場合であっても,自己のゲーム機200が管理するプレイヤキャラクタの位置より所定距離以上上記各管理キャラクタの近くに位置しない限り,判定部275は,自己のゲーム機200がその管理キャラクタを管理すると判定するようにして,管理権を切り替える境界付近での管理権の切り替えが頻繁に発生しないように考慮したものである。特に,集団戦闘ゲームは,アクションゲームなので微妙な位置の変化が極めて頻繁に発生するため,管理権の切り替えが頻繁に発生しないように制御することは処理全体の負荷を軽減し,スムーズにゲームを進行させるために非常に重要である。
また,マージンMAに比べて,マージンMB,マージンMC,マージンMDの値を大きくしたのは,マージンMAの場合は,ステップ1055にて,判定対象としている管理キャラクタ(当該NPC)と敵PCとの距離と,当該NPCと自PCとの距離と,を比較処理しているので,マージンを比較的短く設定して,当該NPCの管理を優先的に敵PCに与えるようにするためである。すなわち,判定部275は,優先的にステップ1055にて「YES」と判定し,ステップ1070にて敵PCに当該NPCの管理を変更する処理を実行する。
一方,マージンMB,マージンMDの場合は,ステップ71065およびステップ1030にて,それぞれ判定対象としている管理キャラクタ(当該NPC)と味方PCとの距離と,当該NPCと自PCとの距離と,を比較処理しているので,マージンを比較的長く設定して,当該NPCの管理をなるべく味方PCに与えないようにするためである。すなわち,判定部275は,優先的にはステップ1030およびステップ1065にて「YES」と判定せず,なるべく当該NPCの管理を味方PC変更しないように処理を実行する。
また,マージンMCの場合は,他のゲーム機200が管理するPCが,管理キャラクタ(当該NPC)および自ゲーム機200が管理する自PCの敵であって,その他のゲーム機200が管理する敵PCが当該NPCの一定範囲内(=マージンMC)に位置する場合には,求められた位置の相対関係(すなわち,自PCと当該NPCと敵PCとの相対位置)にかかわらず,他のゲーム機200が当該NPCを管理させるためである。すなわち,敵PCが当該NPCの一定範囲内(=マージンMC)に位置する場合には,判定部275は,ステップ1015にて「YES」と判定してステップ1045にて優先的に敵PCに当該NPCの管理を変更するように判定する。
また,マージンMBの値をマージンMCの値より大きくしたのは,以下の理由による。前述したように,集団戦闘ゲームは,アクションゲームなので微妙な位置の変化が極めて頻繁に発生する。また,実際の処理では,キャラクタの位置は,小数点以下も含めた数値で演算されるので,画面上,全く移動せず待機しているように見えるキャラクタであっても,実は,常に僅かに移動していると判定される場合が非常に多い。より詳しく述べると,ある地点から仮想空間上にて50m離れた位置に立っているキャラクタは,処理上は,常に,49.9m〜50.1mといった位置を揺れ動いている。プレイヤが,自PCを操作すると,その幅はいっそう大きくなり,このような状況で,ある地点から50mの位置で自PCの小隊と敵PCの小隊とが戦っていると,非常に多数のキャラクタが,極めて頻繁に50m前後の位置を揺れ動くことになる。
このような状況で,たとえば,マージンMBとマージンMCとを同じ値(=50)に設定すると,に管理キャラクタの切り替えが多発してしまう。具体的には,当該NPCと自PCとが味方であって,最寄の敵PCと当該NPCとの距離DEPCが49であった場合,判定部275は,ステップ1005,ステップ1010に続くステップ1015にて「YES」と判定してステップ1045にて敵PCに当該NPCの管理を変更する。その後,敵PCが当該NPCから少し離れ,距離DEPCが51になると,判定部275は,ステップ1005,ステップ1010,ステップ1050〜ステップ1060に続くステップ1065にて「YES」と判定してステップ1040にて味方PCに当該NPCの管理を変更する。その後,敵PCが当該NPCに少し近づき,再び,最寄の敵PCと当該NPCとの距離DEPCが49になった場合,判定部275は,ステップ1015にて再び「YES」と判定してステップ1045にて敵PCに当該NPCの管理を変更する。このような頻繁なキャラクタ管理の切り替えを防止するために,マージンMBの値をマージンMCと異なる値に設定している(すなわち,マージンMB=60,マージンMC=50)。
(ゲームサーバの動作)
つぎに,ゲームサーバ100の動作について説明する。ゲームサーバ100は,図22のフローチャートを示したように,ステップ2200から処理を開始して,ステップ2205にて,キャラクタ管理変更パケット,および/または,キャラクタ情報パケットを受信したか否かを判定する。これらのパケットを受信している場合,ゲームサーバ100は,ステップ2210にて,各ゲーム機200から送信されたキャラクタ管理変更パケット,および/または,キャラクタ情報パケットを送信元のゲーム機200以外のすべてのゲーム機200に送信し,ステップ2295に進んで本処理を終了する。なお,前述したように,ゲームサーバ100の記憶部150には,各キャラクタのキャラクタ情報を記憶する必要はないが,記憶してもよい。
以上,本実施形態に係るネットワークゲームシステムによれば,格闘ゲームにおいて即時性が要求される「アクション処理」をユーザ側の端末であるゲーム機(クライアント側)で行う。また,本システムでは,ノンプレイヤキャラクタは,いずれかのゲーム機200により管理される。このため,ゲームサーバ100に処理の負荷が集中せず,システム全体に処理を負荷分散することができる。このため,プレイヤは,通信遅延を感じることなく,リアルタイム性の高い迫力あるゲームを楽しむことができる。
また,本システムでは,管理キャラクタであるNPCの所定距離内に敵PCが存在する乱戦時には,その敵PCを管理するゲーム機が,優先してNPCを管理するように制御され,それ以外の場合(敵PCが所定距離外にいる場合,所定距離外に味方PCがいる場合,または,所定距離内に何もいない場合)には,最短となる別なPCが現れたら,敵味方に関係なく,管理権がそのPCに変更される。
このように,優先的に敵を管理する方がネットワークゲームにおいての通信遅延を感じる機会を少なくできる。つまり,本実施形態にかかるネットワークゲームシステム10では,PC同士が近づいた乱戦時には,自PCを管理するゲーム機は,まず,敵NPCを優先して管理する。このとき敵味方だけで判断できない場合(同一陣営のPCが近くに複数いる場合など)は距離によってNPCをどのゲーム機に管理させるかを判断する。また,PC同士が離れた場合には,敵味方に関係なく距離だけでNPCをどのゲーム機に管理させるかが判断される。
原則的に,自PCは,近傍の敵NPCと戦い,近傍の味方NPCとは戦わないので,自PCを管理するゲーム機は,自PCと近傍の敵NPCとの間で頻繁に演算処理が発生する。したがって,前述したキャラクタ管理方法によって,敵NPCを優先的に自PCを管理するゲーム機200に管理させることにより,頻繁に発生する演算処理を自ゲーム機内で処理することができる。同一ゲーム機内で管理されているキャラクタ同士はネットワーク通信を行わずに処理が行えるので,敵NPCを優先して管理することにより通信の遅延時間を少なくすることができる。この結果,各プレイヤの操作に応じて即座に画面上のキャラクタのモーションが変わり,プレイヤは,敵の護衛兵(NPC)との戦闘は実質スタンドアローンのように早く感じるため,よりゲームに没頭して楽しむことができる。
なお,クライアント処理(ゲーム機側の処理)では,RAM等のメモリ内に保持するデータとして,各ゲーム機が管理するすべての自NPC+自PC(すなわち,自小隊)のキャラクタ情報ではなく,他のゲーム機が管理するキャラクタを含めた全キャラクタのキャラクタ情報を記憶した。この理由は,たとえば,他のゲーム機が管理するものも自己の画面に表示される可能性があり,少なくともそのキャラクタ情報のうちの最新座標データ等を記憶しておかなければデータの整合が取れないためである。ここで,全キャラクタの最新座標の記憶更新管理に関して,自己が管理する全自NPC+自PCについては,各ゲーム機200内でキー入力等に対する変化量から最新座標を直接計算して記憶更新した後に,ゲームサーバ100経由で他のゲーム機200に送信して整合を取るため,最新座標の更新処理が速くなると考えられるが,他のゲーム機200が管理するものについては,他のゲーム機で算出した最新座標をゲームサーバ100経由で受信した後に記憶更新されることにより整合をとるので,通信遅延が生じて遅くなると考えられる。
しかしながら,本実施形態にかかる発明のポイントは,近接した敵NPCを含む自己が管理するNPCへの処理を速くする点であるからこの遅れによる直接的な影響はなく,また全キャラクタの状態情報を各ゲーム機で記憶すること自体の見た目への影響はないものと考えられる。この理由は,通常このような集団戦闘ゲームでは自PCを画面中央からやや下側に表示するので(このとき各ゲーム機での視界,即ち視点カメラの位置と角度は各自,自動的に適切な数値に設定される),経験則上,実際にプレイヤが注目する自小隊の戦闘場面での処理が速ければ,それ以外の他のゲーム機が管理している他小隊が表示される部分,即ち周囲の部分の表示が多少遅くても気にならないと考えられるからである。
(第2実施形態)
つぎに,第2実施形態にかかるネットワークゲームシステム10について説明する。第2実施形態にかかるネットワークゲームシステム10は,キャラクタ変更判定処理をゲームサーバ100側で実行する点で,キャラクタ変更判定処理をゲーム機200側で実行する第1実施形態と動作上異なる。よって,この相違点を中心に本実施形態にかかるネットワークゲームシステムについて説明する。
(ゲーム機の動作)
本実施形態では,図8のクライアント側管理処理のうち,ステップ815で呼び出されるキャラクタ管理処理を図23のステップ2300から開始し,ステップ905〜ステップ925の処理後,第1実施形態の場合に実行した図9のステップ930のキャラクタ変更判定処理を行うことなく,ステップ935を処理してステップ2395に進んで本処理を終了する。このように,本実施形態では,各ゲーム機200は,アクション処理を実行するが,キャラクタ変更判定処理を実行しない。
(ゲームサーバの動作)
一方,本実施形態では,ゲームサーバ100は,図7に示した各キャラクタのキャラクタ情報をRAM120に予め記憶する。すなわち,ゲームサーバ100にてキャラクタ管理変更判定をする場合,図7に示したキャラクタ情報は,ゲームサーバ100および各ゲーム機器200のRAMにそれぞれ保持される。
ゲームサーバ100は,図24にフローチャートを示したように,ステップ2400から処理を開始して,ステップ2405にて,キャラクタ情報パケットを受信したか否かを判定する。これらのパケットを受信している場合,ゲームサーバ100は,ステップ2410にて,各ゲーム機200から送信されたキャラクタ情報パケットに含まれるキャラクタ情報にて,図7に示したように,RAM120に記憶されたキャラクタのうち,該当するキャラクタのキャラクタ情報を更新し,そのキャラクタ情報パケットを送信元のゲーム機200以外のすべてのゲーム機200に送信した後,ステップ2415に進んで,図10のキャラクタ変更判定処理を実行し,ステップ2495に進んで本処理を終了する。なお,第1実施形態では,すべてのノンプレイヤキャラクタ(NPC)のうち,各ゲーム機200が管理する管理キャラクタ毎に,図10のキャラクタ変更判定処理を繰り返していた。しかし,本実施形態では,すべてのノンプレイヤキャラクタ(NPC)について,キャラクタ変更判定処理を繰り返す必要がある。
本実施形態にかかるネットワークゲームシステム10によれば,ゲームサーバ100側で,すべてのキャラクタが管理される。これによれば,ゲームサーバ100から各ゲーム機200までの距離や各ゲーム機200の性能その他の通信環境が同一の場合で且つ通信障害が発生しない場合,各ゲーム機200で生じる処理の遅延は,理論上ほぼ同時と考えられる。このため,画面上の多数のキャラクタが不自然に動作することがない。また,すべてのキャラクタ管理をゲームサーバ100側で行うため,正確かつ簡易にデータの整合性を保つことができる。
さらに,上記の様に通信環境が同一の場合,本実施形態にかかるキャラクタ管理の切り替えのための遅延時間は,ゲームサーバ100からゲーム機200の通信時間のみであるため,本実施形態のシステムでは,ゲーム機200側でキャラクタ管理処理を実行する第1実施形態の場合と比べ,第1実施形態の他のゲーム機200に生じる切り替え時間の半分しか遅延しないという利点がある。
以上に説明したように,上記各実施形態にかかるネットワークゲームシステム10によれば,「キャラクタ毎に管理するゲーム機を決めて,アクション処理を各ゲーム機200に振り分ける」,「他のゲーム機にて管理されている管理キャラクタの映像が少し遅れて自ゲーム機に表示される」,「他のゲーム機にて管理されている管理キャラクタの映像から自ゲーム機にて管理されている管理キャラクタが影響を及ぼされる」という巧妙な制御により,自ゲーム機200が管理するキャラクタ同士のアクションの結果が即座に画面上に反映されるという状況を作り出すことができる。これは,非常に多数のキャラクタが複数の小隊を作って集団戦闘するネットワークゲームに特に有効である。
なお,上記各実施形態において,最寄のPCは,総当りで距離を比較することにより算出される。
また,以上のキャラクタ変更管理処理では,管理キャラクタ(NPC)を中心として各PCとの相対距離関係を算出し,算出した関係に基づきキャラクタの管理を変更するか否かが判定されていた。しかし,各実施形態にかかるキャラクタ変更管理処理は,各PCを中心としてある所定範囲内に存在するNPCを管理キャラクタとして管理するようにしてもよい。
(PCを中心としたキャラクタ管理)
実際には,たとえば,各ゲーム機200の判定部275は,演算部260aにより演算された各管理キャラクタの位置の変化に基づいて,自ゲーム機200により管理されるプレイヤキャラクタ(自PC)から第1の所定範囲内に位置する1または2以上のノンプレイヤキャラクタ(NPC)を,自ゲーム機200が管理キャラクタとして管理すると判定してもよい。
このようにPCを中心としたキャラクタ管理処理を実行する場合,判定部275は,他のゲーム機200により管理されるプレイヤキャラクタ(他PC)とノンプレイヤキャラクタ(NPC)との関係が敵味方であって,自ゲーム機200により管理されるPC(自PC)と当該NPCとの関係が味方同士の場合には,ノンプレイヤキャラクタ(NPC)が自ゲーム機200により管理されるPCから上記第1の所定範囲内に位置していても,上記敵のPCから第2の所定範囲内に位置するときには,上記他のゲーム機200が当該NPCを管理すると判定するようにしてもよい。また,上記第1の所定範囲は,上記第2の所定範囲より小さくなるように設定してもよい。
また,PCから所定範囲内に予め定められた所定数以上のNPCが存在するとき,当該所定数のNPCの管理を切り替えるようにしてもよい。また,PCから所定範囲内に所定数以上のNPCが存在してから,所定時間経過後にNPCの管理を切り替えるようにしてもよい。
これによれば,NPCと敵PCと自PCとが近傍に位置する戦闘体制において,NPCを優先的に敵PCを管理するゲーム機200に管理させることができ,この結果,ゲーム全体の処理をスムーズに進行させることができる。
(第3実施形態)
つぎに,第3実施形態にかかるネットワークゲームシステム10について説明する。第3実施形態にかかるネットワークゲームシステム10では,第1実施形態にて説明したように,原則として,自小隊に属する自PCおよびNPCは,自己のゲーム機200に管理され,味方PCの他小隊に属する味方PCおよびNPCは,味方PCを操作するゲーム機200に管理され,敵PCの他小隊に属する敵PCおよびNPCは,敵PCを操作するゲーム機200に管理される点において第1実施形態と同様である。
しかし,本実施形態では,たとえば,ゲームに参加するプレイヤが足りない場合であっても(たとえば,ゲームに参加するプレイヤが一人だとしても),ゲームに参加するプレイヤに対しては上記管理の原則が適用され,参加者の不足によりユーザによって操作されることがない1または2以上のPCおよびそのPCの小隊に属するNPCは,ゲームサーバ100により自動的に管理される点において第1実施形態と動作上異なる。よって,この相違点を中心に本実施形態にかかるネットワークゲームシステム10について説明する。
なお,以下の説明では,ゲームサーバ100(SV)により管理されるプレイヤキャラクタ(PC)をサーバキャラクタ(SC)とも称呼する。また,ゲームサーバ100により管理されるサーバキャラクタが複数存在する場合,ゲーム機200により管理されるプレイヤキャラクタまたはゲームサーバ100により管理される他のサーバキャラクタ(キャラクタ変更判定の対象となっているNPCを管理するゲームサーバ100のサーバキャラクタ以外のサーバキャラクタ)をメインキャラクタ(MC)とも称呼する。さらに,メインキャラクタを管理するゲーム機200またはゲームサーバ100をMC管理機器とも称呼する。
(ゲームサーバ100の機能構成)
本実施形態にかかるゲームサーバ100は,図25に示したように,第1実施形態にかかるゲームサーバ100の機能構成に加え,演算部170aおよび判定部175の機能ブロックにより示された新たな機能が加えられている。また,演算部170aと画像処理部170bとによりアクション処理実行部170の機能が実現される。
新たに加えられた機能のうち,アクション処理実行部170は,記憶部150に登録され,ゲームサーバ100により管理される各管理キャラクタのアクション処理を管理キャラクタ毎に実行する。具体的には,演算部170aは,記憶部150に記憶されたキャラクタ情報を用いて,ゲーム上の戦闘によって発生する各管理キャラクタの位置の変化および動作の変化を表す変化量をそれぞれ演算することにより変化後のキャラクタ情報を生成する。
また,判定部175は,演算部170aにより演算された各管理キャラクタの位置の変化値に基づいて,ゲームサーバ100が管理するいずれかのサーバキャラクタの位置(SCの位置)と,MC管理機器により管理されるメインキャラクタの位置(MCの位置)と,各管理キャラクタのアクション処理後の位置(演算後のNPCの位置)と,の相対関係を求め,求められた位置の相対関係に基づき各管理キャラクタを管理するか否かを判定する。ゲームサーバ100が管理する「いずれかの」プレイヤキャラクタの位置としたのは,ゲームに参加するユーザが少ない場合,ゲーム機200に割り当てられなかった複数のプレイヤキャラクタを複数のサーバキャラクタとしてゲームサーバ100にてそれぞれ管理する必要があるためである。
(ゲームサーバ100の動作)
本実施形態においても,原則的に,各プレイヤキャラクタおよび各ゲーム機200により管理すると判定されたノンプレイヤキャラクタは,各ゲーム機200により管理される。具体的には,これらのキャラクタは,各ゲーム機200が図8のクライアント側管理処理を実行することにより管理される。
これに加えて,本実施形態では,ゲーム参加者が不足しているので,ゲームサーバ100にて自動的に管理することとなった1または複数のサーバキャラクタが存在する。この1または複数のサーバキャラクタおよびゲームサーバ100によりサーバキャラクタ毎に管理すると判定されたノンプレイヤキャラクタは,ゲームサーバ100により管理される。具体的には,これらのキャラクタは,図8に代わる図26に示したように,ゲームサーバ100がサーバ側管理処理を実行することにより管理される。
なお,ゲームサーバ100の動作には,原則的に,以下に説明する動作以外にも,第1実施形態または第2実施形態にて説明した動作が含まれる。また,言うまでも無いが,SC及びそのSCの小隊中のNPCの位置変化に関するキャラクタ管理変更パケット及びキャラクタ情報パケットのサーバ間での送受信は行わず(サちなみに,ゲームサーバ100とゲーム機200との間は通常通り送受信を行う),この場合にはゲームサーバ100内部のRAM120に記憶されたキャラクタ情報(図7)を直接更新する。
また,本実施形態では,ユーザが割り当てられなかったプレイヤキャラクタに対してのみ,ゲームの進行に応じてゲームサーバ100が「自動的に」その動作を管理する。したがって,ゲームサーバ100は,サーバ管理者によるアクション処理のためのモニタ415の表示も,キーボード405などの入力装置による入力情報の入力も不要である。また,本実施形態では,第1実施形態にて図8のステップ825で行われていたような,RAM120の更新処理や音響等に関する処理も不要となる。以上を踏まえて,本実施形態におけるゲームサーバ100の動作について説明する。
(ゲームスタート)
ゲーム機200の電源が「ON」され,あるプレイヤからゲームの開始が要求されると,ゲームサーバ100は,図26のステップ2600からサーバ側管理処理を開始し,ステップ805にて初期設定を行う。
つぎに,ステップ810にて,判定部175は,割込み(垂直帰線割込(Vsync))が発生したか否かを判定する。判定部175は,モニタ415の垂直帰線周期と一致した1/60秒に一度の周期で割込みが発生すると,これに応じて,ステップ810にて「YES」と判定し,ステップ815に進んでキャラクタ管理処理(キャラクタ管理処理の詳細は後述)を実行する。
つぎに,判定部175は,ステップ820に進んでゲームが終了か否かを判定する。具体的には,プレイヤが,ゲーム機200の電源を「OFF」するか,または,画面上のゲーム終了を選択することによりゲームは終了する。そこで,プレイヤがこれらのいずれかの操作をするまで,ゲームサーバ100は,基本的に,ステップ810〜ステップ820の処理を繰り返し,プレイヤがこれらのいずれかの操作をするとステップ2695に進んでゲームを終了する。
ステップ810で割込みが発生していない場合,判定部175は,ステップ810にて「NO」と判定してステップ825でメイン処理を実行し,その後ステップ820に進む。このメイン処理においては,本実施形態におけるネットワークゲームと直接関係しないその他の処理が実行される。
(キャラクタ管理処理)
つぎに,ステップ815のキャラクタ管理処理について,図27のフローチャートを参照しながら説明する。ステップ2700から処理が開始されると,通信部145は,ステップ905にて,他のゲーム機200から送信されたキャラクタ管理変更パケットを受信したか否かを判定する。
キャラクタ管理変更パケットを受信した場合には,ステップ2705に進んで,記憶部150は,キャラクタ管理変更パケットに含まれるキャラクタ情報に基づきRAM120の該当キャラクタ情報を更新する。具体的には,図7に示されたように,該当PCまたは該当NPCに記憶された座標,体の向き,モーション番号,再生フレーム位置,進行方向,所属軍の情報を更新する。また,記憶部150は,このキャラクタ情報により特定されるキャラクタを管理キャラクタとしてRAM120に登録する。具体的には,図7に示されたように,該当キャラクタ情報の管理元のPC番号を変更することにより,各管理キャラクタの管理をクライアント側(ゲーム機器200)またはサーバ側(ゲームサーバ100)のいずれかに変更する。また,通信部145は,同ステップ2705にて,受信したキャラクタ管理変更パケットをゲームに参加しているゲーム機200に転送する。
つぎに,ステップ915に進み,通信部145は,参加しているゲーム機200からキャラクタ情報パケットを受信したか否かを判定する。キャラクタ情報パケットを受信した場合には,ステップ2710に進んで,記憶部150は,キャラクタ情報パケットに含まれるキャラクタ情報に基づきRAM120の該当キャラクタ情報を更新する。具体的には,図7の該当PCまたは該当NPCに記憶された座標,体の向き,モーション番号,再生フレーム位置,進行方向,所属軍の情報を更新する。また,通信部145は,同ステップ2710にて,受信したキャラクタ情報パケットをゲームに参加しているゲーム機200に転送する。
ついで,ステップ925に進んで,アクション処理実行部170は,アクション処理を実行する。アクション処理とは,具体的には,アクション処理実行部170の各部により実行されるつぎの処理をいう。まず,演算部170aは,RAM120に記憶されたキャラクタ情報に基づき,各管理キャラクタの位置の変化量および動作の変化量を含んだキャラクタ情報を自動演算する。
つぎに,ステップ930に進み,判定部175は,キャラクタ変更判定処理(サブルーチン)を実行する。この処理は,各管理キャラクタ(NPC)の演算後の位置と,サーバキャラクタ(SC)の位置と,メインキャラクタ(MC)の位置と,の関係から当該管理キャラクタが管理されるべきMC管理機器(ゲームサーバ100またはゲーム機200)を判定する。
ついで,ステップ935に進み,通信部145が,演算部170aにより演算された各管理キャラクタのキャラクタ情報をゲームに参加しているゲーム機200に送信する。このように最新のキャラクタの状態をゲームに参加しているゲーム機200に送信することにより,ゲームに参加しているゲーム機200に記憶された各キャラクタのキャラクタ情報が更新される。これにより,データの整合性を保つことができる。
(キャラクタ変更判定処理)
つぎに,ステップ930に示したキャラクタ変更判定処理について,図28を参照しながら,詳細に説明する。
ステップ2800からキャラクタ変更判定処理が開始され,ステップ2805に進むと,演算部170aは,管理キャラクタとして記憶部150に登録されているNPCと最寄の敵メインキャラクタ(敵MC)(すなわち,最寄の敵PCまたは最寄の他のSC)との距離DEPCを求める。ここで,他のSCとは,キャラクタ変更判定の対象となっているNPCを管理するゲームサーバ100のサーバキャラクタ(SC)以外のSCをいう。
つぎに,ステップ2810に進み,判定部175は,キャラクタ変更判定の対象となっているNPCを管理するゲームサーバ100(SV)のサーバキャラクタ(SC)が,NPCの味方であるか否かを判定する。サーバキャラクタが,NPCの味方である場合,判定部175は,ステップ2815に進み,距離DEPCがマージンMCより小さいか否かを判定する。距離DEPCがマージンMCより大きい場合,ステップ2820に進んで,演算部170aは,NPCとサーバキャラクタとの距離Dを求め,ステップ2825にて,NPCと,最寄の味方メインキャラクタとの距離DAPCを求める。
つぎに,ステップ2830に進んで,判定部175は,距離DAPCにマージンMDを加算した値が距離Dより小さいか否かを判定する。この時点で,距離DAPC+マージンMDの値が距離Dより大きい場合,すなわち,最寄の味方メインキャラクタが,NPCを中心とした半径が(距離D−マージンMD)の円内まで近づいていない場合には,判定部175は,NPCの管理をいずれかの機器に変更することなく,ステップ2835に進み,管理中のすべてのNPC(すなわち,管理キャラクタ)についてキャラクタ変更判定処理を実行するまで,ステップ2805に戻って各管理キャラクタの変更判定処理を続け,すべての管理キャラクタについて,この変更判定処理を終えるとステップ2895にて本処理を終了する。
つぎに,味方メインキャラクタがSCよりマージンMD以上NPCの近くに位置している場合について説明する。判定部175は,ステップ2800〜ステップ2825に続くステップ2830にて「YES」と判定し,ステップ2840に進んで,味方MC管理変更処理を実行する。
(味方MC管理変更処理)
具体的には,図29に示したように,判定部175は,ステップ2900から味方MC管理変更処理を開始して,ステップ2905に進み,最寄の味方MCと当該NPCを管理しているゲームサーバ100(SV)のSCとが同一か否かを判定する。同一でない場合,判定部175は,ステップ2910に進んで,最寄の味方MCのMC管理機器(CLまたはSV)が管理している管理キャラクタ数が79以上であるか否かを判定する。最寄の味方MCのMC管理機器が管理している管理キャラクタ数が79より少ないと,ステップ2915に進んで,記憶部150は,RAM120に記憶されている最寄の味方MCのキャラクタ情報のうち,MC管理機器が管理している管理キャラクタ数を1つ増やし,ステップ2920に進んで,現時点でNPCを管理しているゲームサーバ100により管理されている管理キャラクタ数を1つ減らす。
ついで,ステップ2925に進んで,通信部145は,当該NPCの管理を,SCを管理するゲームサーバ100から味方MCを管理するMC管理機器に変更する情報を含んだ管理変更パケットを,ゲームに参加しているゲーム機200に送信し,ステップ2995に進んで本処理を終了する。このように,味方MCがSCよりマージンMD以上NPCの近くに位置している場合,味方MCを管理するMC管理機器がNPC(管理キャラクタ)を管理するように,管理キャラクタが切り替わる。
なお,ステップ2905にて,最寄の味方MCと当該NPCを管理しているゲームサーバ100のSCとが同一の場合には,管理キャラクタの管理変更を行う必要がなく,また,ステップ2910にて,最寄の味方MCのMC管理機器が管理している管理キャラクタ数が79以上である場合には,そのゲーム機が管理する管理キャラクタをこれ以上増やすことが適当でないので,いずれも当該管理キャラクタを変更することなく,ステップ2995に進んで本処理を終了する。
つぎに,SCの小隊と敵MCの小隊と味方MCの小隊とが集団戦闘状態にある場合のキャラクタ変更判定処理について説明する。具体的には,NPCには味方MCが最も近接しているが,敵MCもNPCを中心とした半径がマージンMCの円内に存在する場合,図28のステップ2800からキャラクタ変更判定処理を開始して,判定部175は,ステップ2805,ステップ2810に続くステップ2815にて「YES」と判定し,ステップ2845に進んで,敵MC管理変更処理を実行する。
(敵MC管理変更処理)
具体的には,図30に示したように,判定部175は,ステップ3000から敵MC管理変更処理を開始して,ステップ3005に進み,最寄の敵MCと当該NPCを管理しているゲームサーバ100のSCとが同一か否かを判定する。ここでは同一でないので,判定部175は,ステップ3010に進んで,最寄の敵MCのMC管理機器が管理している管理キャラクタ数が79以上であるか否かを判定する。最寄の敵MCを管理しているMC管理機器の管理キャラクタ数が79より少ないと,ステップ3015に進んで,記憶部150は,RAM120に記憶されている,これからNPCを管理するMC等に関するキャラクタ情報のうち,MC管理機器が管理している管理キャラクタ数を1つ増やし,ステップ3020に進んで,現時点でNPCを管理しているゲームサーバ100により管理されている管理キャラクタ数を1つ減らす。
ついで,ステップ3025に進んで,通信部145は,当該NPCの管理を,SCを管理するゲームサーバ100から敵MCを管理するMC管理機器に変更する情報を含んだ管理変更パケットを,ゲームに参加しているゲーム機200に送信し,ステップ3095に進んで本処理を終了する。このように,NPCに対して,味方MCおよび敵MCの両方が近接した場合,敵MCを管理するゲーム機が,味方MCを管理するゲーム機より優先してNPC(管理キャラクタ)を管理するように管理キャラクタが切り替わる。
なお,図29の味方PC管理変更処理と同様に,ステップ3005またはステップ3010にて「YES」と判定された場合には,いずれも当該管理キャラクタを変更することなく,ステップ3095に進んで本処理を終了する。
つぎに,NPC(NPC31),PC1に代わるSC,味方PC2に代わる味方MCおよび敵PC3に代わる敵MCとの関係が図19に示した状況にある場合の処理について説明する。この状態で,図28のキャラクタ変更判定処理が実行されると,ステップ2800,2805に続くステップ2810にて,判定部175は,NPCは,NPCを管理するゲームサーバ100が操作するSCの敵であると判定する。そこで,ステップ2850に進み,演算部170aは,NPCとSCとの距離Dを求める。続いて,ステップ2855にて,判定部175は,距離DEPCにマージンMAを加算した値が距離Dより小さいか否かを判定する。この時点では,距離DEPC+マージンMAの値は距離Dより大きい。そこで,ステップ2860に進み,演算部170aは,NPCと最寄の味方MCとの距離DAPCを求める。
つぎに,ステップ2865に進んで,判定部175は,距離DAPCにマージンMBを加算した値が距離Dより小さいか否かを判定する。この時点では,距離DAPC+マージンMBの値は距離Dより大きい。そこで,ステップ2835に進み,RAM120に登録されているすべての管理キャラクタの処理を終えるまでステップ2805に戻って各管理キャラクタの変更判定処理を実行する。
つぎに,図20に示したように,NPC(NPC31)に対して味方PC2に代わる味方MCおよび敵PC3に代わる敵MCが近接した場合であって,敵MCは自PC1に代わるSCよりマージンMA以上NPCの近くに位置している場合について説明する。この状態で,図28のキャラクタ変更判定処理が実行されると,ステップ2800〜2810,ステップ2850に続くステップ2855にて,判定部175は,「YES」と判定し,ステップ2870に進んで,図30の敵MC管理変更処理を実行する。すなわち,ステップ3000〜3025を実行することにより,NPCの管理が,SCを管理するゲームサーバ100から敵MCを管理するMC管理機器に切り替わる。このように,NPCに対して味方MCおよび敵MCの両方が近接した場合であって,敵MCがSCよりマージンMA以上NPCの近くに位置している場合,敵MCを管理するゲーム機が,味方MCを管理するゲーム機より優先してNPC(管理キャラクタ)を管理するように管理キャラクタが切り替わる。
一方,ゲームの状態が,図19の状態から図21の状態(すなわち,敵PC3に代わる敵MCが自PC1に代わるSCよりマージンMA以上NPC(NPC31)の近くに位置していない場合であって,かつ,味方PC2に代わる味方MCが自PC1に代わるSCよりマージンMB以上NPCの近くに位置している状態)に遷移した場合について説明する。この状態で,図28のキャラクタ変更判定処理が実行されると,ステップ2800〜2810,ステップ2850〜2860に続くステップ2865にて,判定部175は,「YES」と判定し,ステップ2840に進んで,図29の味方MC管理変更処理を実行する。すなわち,ステップ2900〜2925を実行することにより,NPCの管理が,SCを管理するゲームサーバ100から味方MCを管理するMC管理機器に切り替わる。
以上に説明したように,本実施形態によれば,ゲームに参加するプレイヤが足りない場合であっても(たとえば,ゲームに参加するユーザが一人だとしても),ゲームに参加するプレイヤのPCに対しては第1実施形態の原則(NPCをクライアント側で管理)が適用され,プレイヤがいない1または2以上のSCおよびそのSCの小隊中のNPCは基本的にゲームサーバ100により自動的に管理される。これにより,参加者が足りなくても,ユーザは,ゲームを思う存分楽しむことができる。また,クライアント機器により管理されるキャラクタとサーバ機器により管理されるキャラクタとを分けることによって,システム全体の処理を分散し,これにより,ゲームをスムーズに進行させることができる。
(SCを中心としたキャラクタ管理)
なお,本実施形態においても,たとえば,判定部175は,演算部170aにより演算された各管理キャラクタの位置の変化に基づいて,ゲームサーバ100により管理されるSCから第1の所定範囲内に位置する1または2以上のノンプレイヤキャラクタ(NPC)を,ゲームサーバ100が管理キャラクタとして管理すると判定してもよい。
このようにSCを中心としたキャラクタ管理処理を実行する場合,判定部175は,MC管理機器により管理されるMCとNPCとの関係が敵味方であって,ゲームサーバ100により管理されるSCと当該NPCとの関係が味方同士の場合には,NPCがゲームサーバ100により管理されるSCから第1の所定範囲内に位置していても,MCから第2の所定範囲内(たとえば,第1の所定範囲<第2の所定範囲)に位置するときには,MCを管理するMC管理機器が当該NPCを管理すると判定するようにしてもよい。
また,SCから所定範囲内に予め定められた所定数以上のNPCが存在するとき,当該所定数のNPCの管理を切り替えるようにしてもよい。また,SCから所定範囲内に所定数以上のNPCが存在してから,所定時間経過後にNPCの管理を切り替えるようにしてもよい。
これによれば,NPCとMCとSCとが近傍に位置する戦闘体制において,NPCを優先的にMCを管理するMC管理機器に管理させることができ,この結果,ゲーム全体の処理をスムーズに進行させることができる。
また,ゲームサーバ100(SV)が管理する各NPCについて,最寄のSCと最寄のMCとの位置関係からNPCの管理を変更してもよい。たとえば,ゲームサーバ100が管理するNPCとMCとの距離が,ゲームサーバ100が管理するNPCとSCとの距離より短くなった場合にNPCの管理を変更するようにしてもよい。
また,ネットワークゲームシステム10では,敵味方同士のプレイヤキャラクタにゲームサーバ100にて管理されるサーバキャラクタやノンプレイヤキャラクタが付随するようなキャラクタ構成にしてもよく,敵がすべてゲームサーバ100にて管理されるサーバキャラクタであり,味方がすべてゲーム機器200にて管理されるプレイヤキャラクタであるキャラクタ構成にしてもよい。
また,プレイヤが不足していなくても,ゲームサーバ100が自動操作するサーバキャラクタおよび管理キャラクタ(ノンプレイヤキャラクタ)をゲーム上に登場させてもよい。また,ゲームサーバ100が自動操作する複数のサーバキャラクタが敵味方同士であってもよい。
上記実施形態において,各部の動作はお互いに関連しており,互いの関連を考慮しながら,一連の動作として置き換えることができる。そして,このように置き換えることにより,キャラクタを管理するクライアント機器の発明の実施形態をクライアント機器のキャラクタ管理方法の実施形態とすることができる。
したがって,本発明にかかるクライアント機器は,ネットワークを介してサーバ機器に接続された複数のクライアント機器を,ユーザが操作することにより,入力された情報に応じて動作する複数のプレイヤキャラクタと,自動的に動作する複数のノンプレイヤキャラクタと,を含んだ複数のキャラクタが登場するネットワークゲームにおける各クライアント機器のキャラクタ管理方法であって,各クライアント機器は,上記複数のキャラクタの位置情報を含んだキャラクタ情報を各クライアント機器の記憶部に各々記憶し,上記ノンプレイヤキャラクタのうち自己のクライアント機器が管理するノンプレイヤキャラクタを管理キャラクタとして各クライアント機器の記憶部に各々登録し,上記各クライアント機器の記憶部に記憶されたキャラクタ情報を用いて,上記ゲームの展開に応じた上記各管理キャラクタの位置の変化の程度および動作の変化の程度を変化後のキャラクタ情報として上記管理キャラクタ毎に演算することを特徴とする各クライアント機器のキャラクタ管理方法とすることができる。
また,上記各クライアント機器の上記キャラクタ管理方法では,各クライアント機器は,上記演算された各管理キャラクタの位置の変化に基づいて,上記各管理キャラクタの演算後の位置と自己のクライアント機器が管理するプレイヤキャラクタの位置と他のクライアント機器が管理するプレイヤキャラクタの位置との相対関係を求め,求められた位置の相対関係に基づき各管理キャラクタを管理するクライアント機器を判定し,上記他のクライアント機器により管理されると判定された管理キャラクタの登録を上記自己のクライアント機器の記憶部から削除し,上記他のクライアント機器により管理されると判定された管理キャラクタのキャラクタ情報を含んだキャラクタ管理変更パケットをサーバ機器に送信することができる。
また,上記各部の動作を,各部の処理と置き換えることにより,プログラムの実施形態とすることができる。また,プログラムを,プログラムを記録したコンピュータ読み取り可能な記録媒体に記憶させることにより,プログラムの実施形態をプログラムに記録したコンピュータ読み取り可能な記録媒体の実施形態とすることができる。
以上,添付図面を参照しながら本発明の好適な実施形態について説明したが,本発明は係る例に限定されないことは言うまでもない。当業者であれば,特許請求の範囲に記載された範疇内において,各種の変更例または修正例に想到し得ることは明らかであり,それらについても当然に本発明の技術的範囲に属するものと了解される。
たとえば,上記各実施形態にかかる集団戦闘ゲームは,ネットワークゲームシステムの一例であり,ネットワークゲームの他の例としては,自分のプレイヤキャラクタを操作して仕事等をすることによりプレイヤキャラクタのレベルや能力等のパラメータを上昇させ,ネットワークを介して接続された他のクライアント機器を操作する他のプレイヤキャラクタと立身出世を競ったり,或いは,ネットワークを介して他のプレイヤキャラクタとチャットをしてコミュニケーションを楽しむゲームが挙げられる。
また,上記各実施形態では,8人のプレイヤが参加するネットワークゲームを例に挙げて説明したが,本発明にかかるネットワークゲームシステムは,これに限定されるものではなく,たとえば,サーバ機器対1のクライアント機器で戦闘する1人プレイヤ用のゲーム形態も含まれることは言うまでも無い。
また,ゲームに参加している他のプレイヤが少ないときに,本来人数分のプレイヤが参加していれば存在したであろう他のPC及びそのPCの小隊中のNPCを,全てNPCとして登場させ,それらのNPCを現在参加している何れかのクライアント機器(クライアント機器が1つの場合も含む)に分散させて管理させたり,一律にサーバ機器に管理させてもよい。この場合,システムの内部処理的には,PCは,もはや,ユーザ操作にしたがって動作する本来のPCではないため,いわゆる相対位置関係を求める処理においてもNPCとして処理する。