ネットワークゲームシステム，クライアント機器，サーバ機器，キャラクタ管理プログラムおよびキャラクタ管理プログラムを記憶した記憶媒体
【課題】 ゲームに登場する各キャラクタの処理および管理を分散して実行するネットワークゲームシステムを提供すること。
【解決手段】 ネットワークゲームシステム１０に接続された各ゲーム機２００は，キャラクタ情報と管理キャラクタの情報とを記憶部２５５に記憶する。演算部２６０ａは，記憶部２５５に記憶されたキャラクタ情報を用いて，ゲームの展開に応じた上記各管理キャラクタの位置の変化および動作の変化を管理キャラクタ毎に演算する。通信部２８０は，演算された変化後の各管理キャラクタのキャラクタ情報パケットをゲームサーバ１００に送信する。ゲームサーバ１００は，受信したキャラクタ情報パケットを上記ゲームに参加している他のゲーム機２００に送信する。他のゲーム機２００は，受信したキャラクタ情報を記憶するとともに変化後の各管理キャラクタに関する画像を生成する。
【解決手段】 ネットワークゲームシステム１０に接続された各ゲーム機２００は，キャラクタ情報と管理キャラクタの情報とを記憶部２５５に記憶する。演算部２６０ａは，記憶部２５５に記憶されたキャラクタ情報を用いて，ゲームの展開に応じた上記各管理キャラクタの位置の変化および動作の変化を管理キャラクタ毎に演算する。通信部２８０は，演算された変化後の各管理キャラクタのキャラクタ情報パケットをゲームサーバ１００に送信する。ゲームサーバ１００は，受信したキャラクタ情報パケットを上記ゲームに参加している他のゲーム機２００に送信する。他のゲーム機２００は，受信したキャラクタ情報を記憶するとともに変化後の各管理キャラクタに関する画像を生成する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は，複数のキャラクタが登場するネットワークゲームシステムにおいて，ゲームに登場するキャラクタに関する処理を複数の機器に分散させる方法に関する。特に，複数のキャラクタが敵味方の集団を形成して互いに戦闘するネットワークゲームシステムにおいてその集団戦闘をスムーズに実現するために，登場する各キャラクタの処理および管理を分散して処理する方法に関する。
【背景技術】
【０００２】
近年，ブロードバンドの普及により，インターネットを利用する人口の拡大と通信技術の進歩が目覚しく，これに伴ってネットワークを介して複数のプレイヤが同時に参加可能なネットワークゲームの人気が高まっている。このようなネットワークゲームとして，たとえば，ネットワークを介して参加した複数のゲームプレイヤを複数のチームに振り分け，複数のチーム同士でネットワークを通じてリアルタイムにゲーム対戦するシステムが提案されている（たとえば，特許文献１を参照。）。
【０００３】
【特許文献１】特開２００１−３５３３７５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
このネットワークゲームシステムでは，ゲーム内のすべてのキャラクタをサーバ側で一元管理する「サーバ・クライアント方式」が採用されている。すなわち，このネットワークシステムでは，センターのホストマシンとしての専用サーバが，実際のゲームプログラムの主な実行とすべてのゲームデータ，および各クライアント機器が共有する仮想空間を一元管理し，各クライアント機器とゲームコマンド等の送受信をすることによりゲームが進行する。
【０００５】
したがって，このネットワークシステムでは，ゲームプレイヤがクライアント機器にキー入力すると，サーバがこのキー入力データを受け取り，すべての処理を実行し，描画情報のみをクライアント機器に送り返した後に，ようやくゲームプレイヤの操作に対するアクションが画面に反映される。このように，自己の操作に対して画面上のキャラクタがすぐに反応しないと，ゲームとしての面白さ，楽しさが半減し，ゲームプレイヤは，その操作性の悪さによりゲームに没頭することができない。
【０００６】
これに対して，「Ｐ２Ｐ（ピアツーピア）ホスト方式」という方式も存在する。この方式は，何れかのクライアント機器をホストマシンとし，ネットワークに接続された他のクライアント機器と直接通信してゲームを進行させていくものである。このため，ホストマシンであるクライアント機器の処理の負荷が高く，どうしてもゲームプレイヤの操作に対して画面上のキャラクタのアクションが遅延してしまう。したがって，Ｐ２Ｐホスト方式によっても上記問題を払拭することはできない。
【０００７】
特に，現在，スタンドアローンで動作している１００体以上のキャラクタが同時に集団戦闘する複雑なアクションゲームをネットワークゲームとして動作させる場合，１００体以上のキャラクタを瞬時にアクションさせることが要求される。しかし，上記従来の方式でのゲーム管理では，キャラクタデータやモーションデータ等の通信量が非常に多くなり，著しいアクション処理の遅延が生じてしまい，ゲームとして成立させることが著しく困難となる。
【０００８】
そこで，本発明は，上記問題に鑑みてなされたものであり，本発明の目的とするところは，複数のキャラクタが登場するネットワークゲームシステムにおいてそれらのキャラクタをスムーズに動作させるために，登場する各キャラクタの処理および管理を分散して実行するネットワークゲームシステム，クライアント機器，サーバ機器を提供することにある。
【課題を解決するための手段】
【０００９】
上記課題を解決するために，本発明のある観点によれば，ネットワークを介してサーバ機器に接続された複数のクライアント機器を，ユーザが操作することにより，入力された情報に応じて動作する複数のプレイヤキャラクタと，自動的に動作する複数のノンプレイヤキャラクタと，を含んだ複数のキャラクタが登場するネットワークゲームシステムが提供される。
【００１０】
このネットワークゲームシステムでは，上記各クライアント機器は，上記複数のキャラクタの位置情報を含んだキャラクタ情報を記憶し，上記ノンプレイヤキャラクタのうち自己のクライアント機器が管理するノンプレイヤキャラクタを管理キャラクタとして登録する記憶部と，上記記憶部に記憶されたキャラクタ情報を用いて，上記ゲームの展開に応じた上記各管理キャラクタの位置の変化の程度および動作の変化の程度を変化後のキャラクタ情報として上記管理キャラクタ毎に演算する演算部と，上記演算された変化後の各管理キャラクタのキャラクタ情報をキャラクタ情報パケットとしてサーバ機器に送信する通信部と，を備える。
【００１１】
また，上記サーバ機器は，上記送信されたキャラクタ情報パケットを受信し，受信したキャラクタ情報パケットを上記ゲームに参加している他のクライアント機器に送信する。これに対して，上記他のクライアント機器は，上記送信されたキャラクタ情報パケットを受信し，受信したキャラクタ情報に基づいて上記変化後のキャラクタ情報を記憶する。
【００１２】
これによれば，クライアント機器が，ゲームの展開に応じた各管理キャラクタの位置の変化および動作の変化の程度を演算する。これにより，サーバ機器に負荷が集中していた，ゲームを進行させるための主処理をゲームに参加している複数のクライアント機器に分担させることができるとともに，サーバ機器とクライアント機器との通信量を極力減らすことができる。この結果，プレイヤの操作に応じて画面上の複数のキャラクタを即座に動作させることができる。このため，プレイヤは，ネットワークを介して接続された他のプレイヤとともに，その操作性のよさにより臨場感あふれたゲームに没頭することができる。
【００１３】
上記各クライアント機器は，さらに，上記演算された各管理キャラクタの位置の変化の程度に基づいて，上記各管理キャラクタの演算後の位置と自己のクライアント機器が管理するプレイヤキャラクタの位置と他のクライアント機器が管理するプレイヤキャラクタの位置との相対関係を求め，求められた位置の相対関係に基づき各管理キャラクタを管理するか否かを判定する判定部を備えていてもよい。このとき，上記各クライアント機器の記憶部は，上記判定部により管理しないと判定された管理キャラクタの登録を削除し，上記各クライアント機器の通信部は，上記判定部により上記管理キャラクタが上記他のクライアント機器により管理されると判定された場合，上記管理キャラクタのキャラクタ情報を含んだキャラクタ管理変更パケットをサーバ機器に送信してもよい。
【００１４】
これに対して，上記サーバ機器は，上記キャラクタ管理変更パケットを受信し，受信したキャラクタ管理変更パケットを上記他のクライアント機器に送信し，上記他のクライアント機器は，上記送信されたキャラクタ管理変更パケットを受信し，受信されたキャラクタ情報を記憶するとともに上記受信されたキャラクタ情報により特定されるキャラクタを管理キャラクタとして登録するようにしてもよい。
【００１５】
これによれば，管理キャラクタの位置と自己のクライアント機器が管理するプレイヤキャラクタの位置と他のクライアント機器が管理するプレイヤキャラクタの位置との相対関係から，ゲームの進行状況に応じてノンプレイヤキャラクタを管理するクライアント機器が適切に特定される。このようにして，ゲームの状況に応じてノンプレイヤキャラクタを管理するクライアント機器を適宜切り替えることにより，システム全体の処理分散を最適化して，よりスムーズにゲームを進行させることができる。なお，ここでいう「管理」とは，たとえば，攻撃防御時のノンプレイヤキャラクタ双方の座標計算やモーションの再生等の処理を各クライアント機器側で行うことをいう。
【００１６】
特に，上記ネットワークゲームシステムは，上記複数のクライアント機器により管理される複数のプレイヤキャラクタと上記複数のプレイヤキャラクタを護衛するノンプレイヤキャラクタとからなる複数のキャラクタが敵味方の集団を形成して互いに戦闘するゲームを提供するシステムである場合に有利である。このような集団戦闘ゲームでは，たとえば，８０体〜１２８体程度の非常に多くのキャラクタが同時に画面上に登場する。このため，ゲームの遅延を避けるためには，処理分散の最適化が不可欠である。
【００１７】
また，上記ネットワークゲームシステムは，上記戦闘ゲームの他，上記複数のクライアント機器により管理される複数のプレイヤキャラクタと上記複数のノンプレイヤキャラクタとが集団を形成して互いに協力するゲームを提供するシステムであってもよい。このシステムの具体例としては，自分のプレイヤキャラクタを操作して複数のノンプレイヤキャラクタとともに仕事等をすることによりプレイヤキャラクタのレベルや能力等のパラメータを上昇させ，ネットワークを介して接続された他のクライアント機器を操作する他のプレイヤキャラクタと立身出世を競うゲームシステムが挙げられる。或いは，プレイヤが操作するプレイヤキャラクタが，複数のノンプレイヤキャラクタの協力を得ながら，ネットワークを介して他のプレイヤキャラクタとチャットをして，コミュニケーションを楽しむゲームが挙げられる。
【００１８】
また，上記課題を解決するために，本発明の別の観点によれば，ネットワークに接続された複数のクライアント機器によりそれぞれ管理される複数のプレイヤキャラクタと上記複数のプレイヤキャラクタの脇役となる複数のノンプレイヤキャラクタとからなる複数のキャラクタが登場するネットワークゲームに参加するクライアント機器が提供される。具体的には，このクライアント機器は，上記複数のキャラクタの位置情報を含んだキャラクタ情報を記憶し，上記ノンプレイヤキャラクタのうち自己のクライアント機器が管理するノンプレイヤキャラクタを管理キャラクタとして登録する記憶部と，上記記憶部に記憶されたキャラクタ情報を用いて，上記ゲームの展開に応じた上記各管理キャラクタの位置の変化の程度および動作の変化の程度を変化後のキャラクタ情報として上記管理キャラクタ毎に演算する演算部と，を備える。
【００１９】
上記クライアント機器は，さらに，上記生成されたキャラクタ情報に基づいてそのキャラクタ情報により特定されるキャラクタに関する画像を生成する画像生成部を備えていてもよい。
【００２０】
これによれば，ゲームの展開に応じた各管理キャラクタの位置の変化および動作の変化の程度はクライアント機器側で演算される。これにより，従来，サーバ機器に負荷が集中していた主処理をゲームに参加している複数のクライアント機器に分担させることができる。これにより，サーバ機器とクライアント機器との通信量も極力減らすことができる。この結果，プレイヤは，プレイヤの操作に応じて即座に動作する画面上の複数のキャラクタを見ながら，臨場感あふれたゲームで楽しく遊ぶことができる。
【００２１】
上記クライアント機器は，上記演算された各管理キャラクタの位置の変化の程度に基づいて，上記各管理キャラクタの演算後の位置と自己のクライアント機器が管理するプレイヤキャラクタの位置と他のクライアント機器が管理するプレイヤキャラクタの位置との相対関係を求め，上記求められた位置の相対関係に基づき各管理キャラクタを管理するか否かを判定する判定部を備えていてもよい。
【００２２】
これによれば，管理キャラクタの位置と自己のクライアント機器が管理するプレイヤキャラクタの位置と他のクライアント機器が管理するプレイヤキャラクタの位置との相対関係から，ゲームの進行状況に応じてノンプレイヤキャラクタを管理するクライアント機器が適切に特定される。また，これによれば，上記各ノンプレイヤキャラクタは，上記ネットワークゲームに参加しているいずれかのクライアント機器に分散して管理される。このようにして，ゲーム状況に応じてノンプレイヤキャラクタを管理するクライアント機器を適宜切り替えることにより，システム全体の処理分散を最適化して，よりスムーズにゲームを進行させることができる。
【００２３】
このとき，上記判定部は，上記求められた位置の相対関係に基づき，上記各管理キャラクタから所定範囲内に位置するプレイヤキャラクタを管理するクライアント機器に管理されるように上記各管理キャラクタを管理するか否かを判定するようにしてもよい。
【００２４】
また，上記判定部は，上記求められた位置の相対関係に基づき，上記各管理キャラクタが，上記各管理キャラクタの敵のプレイヤキャラクタを管理するクライアント機器に優先して管理されるように上記各管理キャラクタを管理するか否かを判定するようにしてもよい。
【００２５】
このネットワークゲームシステムが集団戦闘ゲームである場合，プレイヤキャラクタは，味方のノンプレイヤキャラクタを攻撃しない。換言すれば，プレイヤの入力操作に応じてプレイヤキャラクタを動作させる際，このプレイヤキャラクタの動作（攻撃）に対応して，クライアント機器が，プレイヤの入力操作に応じることなく，自動的に動作させる（すなわち，攻撃に対応して動作するために演算が必要な）キャラクタは，プレイヤキャラクタ近傍の敵のノンプレイヤキャラクタのみである。このことから，本発明では，攻撃を仕掛けたプレイヤキャラクタを管理するクライアント機器自身がプレイヤキャラクタ近傍の敵のノンプレイヤキャラクタを優先的に管理するようにする。この結果，プレイヤの操作に応じて，自クライアント機器が，自プレイヤキャラクタとともに敵のノンプレイヤキャラクタの動作の変化値を瞬時に演算し，その結果を即座に画面上に反映することにより，攻撃時の処理落ちを回避して，臨場感あふれるゲーム展開をプレイヤに即座に提供することができる。
【００２６】
また，上記判定部は，上記求められた位置の相対関係に基づき，上記各管理キャラクタに最も近いプレイヤキャラクタを管理するクライアント機器に管理されるように上記各管理キャラクタを管理するか否かを判定してもよい。
【００２７】
プレイヤの操作に応じて動作するプレイヤキャラクタに対してゲーム進行のための処理が必要になるノンプレイヤキャラクタは，プレイヤキャラクタ近傍のノンプレイヤキャラクタである場合が多い。このことから，本発明では，プレイヤキャラクタを管理するクライアント機器と同じ機器がプレイヤキャラクタ近傍のノンプレイヤキャラクタを敵味方にかかわらず優先的に管理する。これにより，ゲームをスムーズに進行させることができる。
【００２８】
上記判定部は，上記他のクライアント機器が管理するプレイヤキャラクタの位置が，上記各管理キャラクタに最も近い場合であっても，自己のクライアント機器が管理するプレイヤキャラクタの位置より所定距離以上上記各管理キャラクタの近くに位置しない限り，自己のクライアント機器が上記各管理キャラクタを管理すると判定するようにしてもよい。
【００２９】
このように，管理キャラクタの管理の切り替えに際して，所定のマージン（所定距離）を設けることにより，各管理キャラクタの管理の切り替えが頻繁に発生することを防止することができる。このとき，上記所定距離は，各管理キャラクタの管理を切り替えるとの判定が頻繁に生じないような値に設定されるのが好ましい。また，上記所定距離は，上記他のクライアント機器が管理するプレイヤキャラクタと上記各管理キャラクタとの関係が敵味方である場合には，その関係が味方同士である場合に比べ短い値に設定されるほうがよい。また，判定部は，距離以外の要素によって各管理キャラクタの管理切り替えを判定してもよい。たとえば，ノンプレイヤキャラクタが特定のクライアント機器に予め割り付けられている場合には，その取り決めに従って管理を切り替えてもよい。
【００３０】
また，上記判定部は，上記各管理キャラクタが，自己のクライアント機器により管理されるプレイヤキャラクタに対して敵のキャラクタであるか味方のキャラクタであるかを区別することなく，上記演算された位置の相対関係に基づき，上記各管理キャラクタを管理するか否かを判定するようにしてもよい。
【００３１】
また，上記判定部は，上記他のクライアント機器が管理するプレイヤキャラクタが，上記各管理キャラクタおよび自己のクライアント機器が管理するプレイヤキャラクタの敵であって，上記他のクライアント機器が管理するプレイヤキャラクタが上記各管理キャラクタの一定範囲内に位置する場合には，上記求められた位置の相対関係にかかわらず，上記他のクライアント機器が上記各管理キャラクタを管理すると判定するようにしてもよい。
【００３２】
上記クライアント機器であって，さらに，上記判定部により上記各管理キャラクタが上記他のクライアント機器により管理されると判定された場合，上記判定された管理キャラクタのキャラクタ情報を含んだキャラクタ管理変更パケットをサーバ機器に送信する通信部を備え，上記記憶部は，上記他のクライアント機器により管理されると判定された管理キャラクタの登録を削除するようにしてもよい。
【００３３】
また，上記通信部は，上記ネットワークを介してサーバ機器に接続された他のクライアント機器から送信されたキャラクタ管理変更パケットを受信し，上記記憶部は，上記受信したキャラクタ管理変更パケットに含まれるキャラクタ情報を記憶し，上記キャラクタ情報により特定されるキャラクタを管理キャラクタとして登録するようにしてもよい。
【００３４】
これによれば，各クライアント機器が演算した変化後のキャラクタ情報を，サーバ機器を介して他のクライアント機器に送信し，これに応じて，他のクライアント機器が，記憶部のデータを送信されたキャラクタ情報に更新することにより，すべてのクライアント機器において，すべてのキャラクタ情報に関するデータの整合性を保つことができる。
【００３５】
また，上記他のクライアント機器がネットワークを介して複数接続され，上記他のクライアント機器のうち，第１の他のクライアント機器が管理するプレイヤキャラクタが敵であり，第２の他のクライアント機器が管理するプレイヤキャラクタが味方である場合，上記判定部は，上記求められた位置の相対関係に基づき，上記各管理キャラクタが第２の他のクライアント機器よりも第１の他のクライアント機器に優先して管理されるように上記各管理キャラクタを管理するか否かを判定するようにしてもよい。
【００３６】
また，上記判定部は，所定周期ごとに上記各管理キャラクタを管理するか否かを判定してもよい。上記判定部は，ゲームを表示する表示画面を走査するタイミングに連動して，上記判定を行ってもよい。ここで，この画面の走査タイミングとは，垂直帰線割込が発生するタイミングである。また，所定周期の一例としては，モニタの垂直帰線周期と一致した１／６０秒（１６．６ミリ秒）に一度の周期が挙げられるが，必ずしも，所定周期は画面走査のタイミングである必要はなく，判定部での処理の負荷に応じて適度な所定周期，例えば１／３０秒または１／２０秒としてもよい。なお，上記判定部は，所定周期ごとに全ての管理キャラクタについて一度に判定するのではなく，全ての管理キャラクタを所定数に分けて所定周期ごとに数段階ずつ判定するようにしてもよい。
【００３７】
また，上記課題を解決するために，本発明の別の観点によれば，複数のプレイヤキャラクタと上記複数のプレイヤキャラクタを上記複数のプレイヤキャラクタの脇役となる複数のノンプレイヤキャラクタとからなる複数のキャラクタが登場するネットワークゲームを管理するサーバ機器が提供される。
【００３８】
具体的には，上記サーバ機器は，ネットワークに接続された複数のクライアント機器により管理される上記複数のキャラクタの位置情報と上記複数のキャラクタを管理するクライアント機器の識別情報とを記憶する記憶部と，上記キャラクタ情報に含まれる位置情報と上記各ノンプレイヤキャラクタを各々管理するクライアント機器の識別情報とに基づいて，各クライアント機器が管理するプレイヤキャラクタの位置と各クライアント機器が管理するノンプレイヤキャラクタの位置との相対関係を求め，上記求められた位置の相対関係に基づき上記ノンプレイヤキャラクタを管理するクライアント機器を判定する判定部と，上記各ノンプレイヤキャラクタを管理すると判定されたクライアント機器にキャラクタ管理変更パケットを送信する通信部とを備える。
【００３９】
これによれば，サーバ機器にてすべてのキャラクタの管理切替処理が実行され，その結果が，各クライアント機器に一度に送信される。これにより，サーバ機器から全クライアント機器までの距離や各クライアント機器の性能その他の通信環境が同一の場合で且つ通信障害が発生しない場合，各クライアント機器で生じる管理切替処理の遅延は，理論上，ほぼ同時になると考えられる。このため，画面上の多数のキャラクタをより自然に動作させることができる。また，すべてのキャラクタの管理切り替えをサーバ側で行うため，正確かつ簡易にデータの整合性を保つことができる。また，この場合，キャラクタ管理の切り替えのための遅延時間は，サーバ機器からクライアント機器への通信時間のみである。このため，キャラクタの管理切替処理をクライアント機器にて行う場合に比べて通信遅延（キャラクタの管理切替処理をクライアント機器にて行う場合，変更元クライアント機器からサーバを経由して変更先クライアント機器へ通信するための通信時間がかかる。即ち，この場合は,サーバ側で管理切替処理を行う場合に比べ，ほぼ２倍の通信時間がかかる。）が少ないという利点がある。なお，キャラクタを管理するクライアント機器の識別情報の一例としては，予め登録されている管理元のクライアント番号が挙げられる。
【００４０】
また，上記課題を解決するために，本発明の別の観点によれば，ネットワークに接続された複数のクライアント機器を，ユーザが操作することにより，入力された情報に応じて動作する複数のプレイヤキャラクタと，自動的に動作する複数のノンプレイヤキャラクタと，を含んだ複数のキャラクタが登場するネットワークゲームをコンピュータに実行させるためのキャラクタ管理プログラムが提供される。
【００４１】
具体的には，上記複数のキャラクタの位置情報を含んだキャラクタ情報を各クライアント機器の記憶部に各々記憶する処理と，上記ノンプレイヤキャラクタのうち自己のクライアント機器が管理するノンプレイヤキャラクタを管理キャラクタとして各クライアント機器の記憶部に各々登録する処理と，上記各クライアント機器の記憶部に記憶されたキャラクタ情報を用いて，各クライアント機器に対して上記ゲームの展開に応じた上記各管理キャラクタの位置の変化の程度および動作の変化の程度を変化後のキャラクタ情報として上記管理キャラクタ毎に演算する処理と，をコンピュータに実行させることを特徴とするキャラクタ管理プログラムが提供される。
【００４２】
上記キャラクタ管理プログラムでは，上記演算された各管理キャラクタの位置の変化の程度に基づいて，上記各管理キャラクタの演算後の位置と自己のクライアント機器が管理するプレイヤキャラクタの位置と他のクライアント機器が管理するプレイヤキャラクタの位置との相対関係を求め，上記求められた位置の相対関係に基づき各管理キャラクタを管理するクライアント機器を判定する処理と，上記他のクライアント機器により管理されると判定された管理キャラクタの登録を上記自己のクライアント機器の記憶部から削除する処理と，上記他のクライアント機器により管理されると判定された管理キャラクタのキャラクタ情報を含んだキャラクタ管理変更パケットをサーバ機器に送信する処理と，をコンピュータに実行させるようにしてもよい。
【００４３】
また，上記課題を解決するために，本発明の別の観点によれば，ネットワークに接続された複数のクライアント機器を，ユーザが操作することにより，入力された情報に応じて動作する複数のプレイヤキャラクタと，自動的に動作する複数のノンプレイヤキャラクタと，を含んだ複数のキャラクタが登場するネットワークゲームをコンピュータに実行させるためのキャラクタ管理プログラムを記憶したコンピュータ読み取り可能な記憶媒体が提供される。
【００４４】
具体的には，上記複数のキャラクタの位置情報を含んだキャラクタ情報を各クライアント機器の記憶部に各々記憶する処理と，上記ノンプレイヤキャラクタのうち自己のクライアント機器が管理するノンプレイヤキャラクタを管理キャラクタとして各クライアント機器の記憶部に各々登録する処理と，上記各クライアント機器の記憶部に記憶されたキャラクタ情報を用いて，各クライアント機器に対して上記ゲームの展開に応じた上記各管理キャラクタの位置の変化の程度および動作の変化の程度を変化後のキャラクタ情報として上記管理キャラクタ毎に演算する処理と，をコンピュータに実行させることを特徴とするキャラクタ管理プログラムを記憶したコンピュータ読み取り可能な記憶媒体が提供される。
【００４５】
上記キャラクタ管理プログラムを記憶したコンピュータ読み取り可能な記憶媒体では，上記演算された各管理キャラクタの位置の変化の程度に基づいて，各管理キャラクタの演算後の位置と自己のクライアント機器が管理するプレイヤキャラクタの位置と他のクライアント機器が管理するプレイヤキャラクタの位置との相対関係を求め，上記求められた位置の相対関係に基づき各管理キャラクタを管理するクライアント機器を判定する処理と，上記他のクライアント機器により管理されると判定された管理キャラクタの登録を上記自己のクライアント機器の記憶部から削除する処理と，上記他のクライアント機器により管理されると判定された管理キャラクタのキャラクタ情報を含んだキャラクタ管理変更パケットをサーバ機器に送信する処理と，をコンピュータに実行させるキャラクタ管理プログラムを記憶したコンピュータ読み取り可能な記憶媒体であってもよい。
【００４６】
これによれば，クライアント機器が，ゲームの展開に応じた各管理キャラクタの位置の変化および動作の変化を演算する。これにより，ゲームを進行させるために発生する主処理をゲームに参加している複数のクライアント機器に分担させることができるとともに，サーバ機器とクライアント機器との通信量を極力減らすことができる。この結果，プレイヤによる操作に応じて即座に動作する画面上の複数のキャラクタを見ながら，プレイヤは，臨場感あふれたゲームを楽しむことができる。
【００４７】
また，上記課題を解決するために，本発明の別の観点によれば，ネットワークを介してサーバ機器に接続された１または複数のクライアント機器を，ユーザが操作することにより，入力された情報に応じて動作する１または複数のプレイヤキャラクタと，自動的に動作する複数のノンプレイヤキャラクタと，を含んだ複数のキャラクタが登場するネットワークゲームシステムが提供される。
【００４８】
このネットワークゲームシステムでは，前記各クライアント機器は，前記複数のキャラクタの位置情報を含んだキャラクタ情報を記憶し，前記ノンプレイヤキャラクタのうち自己のクライアント機器が管理するノンプレイヤキャラクタを管理キャラクタとして登録する記憶部と，前記記憶部に記憶されたキャラクタ情報を用いて，前記ゲームの展開に応じた前記各管理キャラクタの位置の変化の程度および動作の変化の程度を変化後のキャラクタ情報として前記管理キャラクタ毎に演算する演算部と，前記演算された変化後の各管理キャラクタのキャラクタ情報をキャラクタ情報パケットとしてサーバ機器に送信する通信部と，を備え，前記サーバ機器は，前記送信されたキャラクタ情報パケットを受信し，受信したキャラクタ情報パケットを前記ゲームに参加している他のクライアント機器に送信し，前記ゲームに参加している他のクライアント機器は，前記送信されたキャラクタ情報パケットを受信し，受信されたキャラクタ情報に基づいて前記変化後のキャラクタ情報を記憶する。
【００４９】
このとき，前記サーバ機器は，前記複数のキャラクタの位置情報を含んだキャラクタ情報を記憶し，前記ノンプレイヤキャラクタのうち自己のサーバ機器が管理するノンプレイヤキャラクタを管理キャラクタとして登録する記憶部と，前記記憶部に記憶されたキャラクタ情報を用いて，前記ゲームの展開に応じた前記各管理キャラクタの位置の変化の程度および動作の変化の程度を変化後のキャラクタ情報として前記管理キャラクタ毎に演算する演算部と，前記演算された変化後の各管理キャラクタのキャラクタ情報をキャラクタ情報パケットとして前記ゲームに参加しているすべてのクライアント機器に送信する通信部と，を備えていてもよい。
【００５０】
これによれば，ゲームに参加するユーザが足りない場合であっても（たとえば，ゲームに参加するユーザが一人だとしても），操作するユーザがいないプレイヤキャラクタおよびこのプレイヤキャラクタに付随するノンプレイヤキャラクタについては，サーバ機器が，それらのキャラクタを自動的に操作する。これにより，参加者が足りなくても，ユーザは，ゲームを思う存分楽しむことができる。また，クライアント機器により管理されるキャラクタとサーバ機器により管理されるキャラクタとを分けることによって，システム全体の処理を分散し，これにより，ゲームをスムーズに進行させることができる。なお，サーバ機器が自動操作するプレイヤキャラクタは複数であってもよい。
【００５１】
前記ゲームに登場する前記複数のキャラクタは，さらに，前記サーバ機器の制御により自動的に動作する１または複数のサーバキャラクタを含み，前記サーバ機器は，さらに，前記演算された各管理キャラクタの位置の変化の程度に基づいて，前記各管理キャラクタの演算後の位置と自己のサーバ機器が管理するいずれかの前記サーバキャラクタの位置と前記クライアント機器が管理するプレイヤキャラクタまたは他のサーバキャラクタの位置との相対関係を求め，求められた位置の相対関係に基づき各管理キャラクタを管理するか否かを前記サーバキャラクタ毎に判定する判定部，を備えていてもよい。
【００５２】
このとき，前記サーバ機器の記憶部は，前記サーバ機器の判定部により管理しないと判定された管理キャラクタの登録を削除し，前記サーバ機器の通信部は，前記サーバ機器の判定部により前記管理キャラクタが前記クライアント機器により管理されると判定された場合，前記管理キャラクタのキャラクタ情報を含んだキャラクタ管理変更パケットを前記クライアント機器に送信し，前記クライアント機器は，前記送信されたキャラクタ管理変更パケットを受信し，受信されたキャラクタ情報を記憶するとともに前記受信されたキャラクタ情報により特定されるキャラクタを管理キャラクタとして登録するようにしてもよい。
【００５３】
これによれば，サーバ機器が管理している管理キャラクタについては，サーバ機器がその管理を他の機器に切り替えるか否かをサーバキャラクタ毎に判定する。ここで，サーバ機器が複数のサーバキャラクタを管理する場合，記憶部には，サーバキャラクタ毎に，そのサーバキャラクタの情報および各サーバキャラクタの小隊に含まれる管理キャラクタ（ノンプレイヤキャラクタ）の情報が記憶され，随時更新される。
【００５４】
また，前記ネットワークゲームシステムは，前記１または複数のクライアント機器により管理される１または複数のプレイヤキャラクタと前記１または複数のプレイヤキャラクタを護衛する１または複数のノンプレイヤキャラクタとが味方集団を形成し，かつ，前記サーバ機器により管理される１または複数のサーバキャラクタと前記サーバキャラクタを護衛する１または複数のノンプレイヤキャラクタとが敵集団または味方集団の少なくともいずれかを形成して互いに戦闘するゲームを提供するシステムであってもよい。
【００５５】
また，上記課題を解決するために，本発明の別の観点によれば，ネットワークを介してサーバ機器に接続された１または複数のクライアント機器を，ユーザが操作することにより，入力された情報に応じて動作する１または複数のプレイヤキャラクタと，自動的に動作する複数のノンプレイヤキャラクタと，を含んだ複数のキャラクタが登場するネットワークゲームをコンピュータに実行させるためのキャラクタ管理プログラムが提供される。
【００５６】
このキャラクタ管理プログラムは，さらに，前記複数のキャラクタの位置情報を含んだキャラクタ情報を各クライアント機器の記憶部に各々記憶する処理と，前記ノンプレイヤキャラクタのうち自己のクライアント機器が管理するノンプレイヤキャラクタを管理キャラクタとして各クライアント機器の記憶部に各々登録する処理と，前記各クライアント機器の記憶部に記憶されたキャラクタ情報を用いて，各クライアント機器に対して前記ゲームの展開に応じた前記各管理キャラクタの位置の変化の程度および動作の変化の程度を変化後のキャラクタ情報として前記管理キャラクタ毎に演算する処理と，をコンピュータに実行させるようにしてもよい。
【００５７】
前記キャラクタ管理プログラムは，さらに，前記複数のキャラクタの位置情報を含んだキャラクタ情報を前記サーバ機器の記憶部に記憶する処理と，前記ノンプレイヤキャラクタのうち自己のサーバ機器が管理するノンプレイヤキャラクタを管理キャラクタとして前記サーバ機器の記憶部に登録する処理と，前記サーバ機器の記憶部に記憶されたキャラクタ情報を用いて，前記サーバ機器に対して前記ゲームの展開に応じた前記各管理キャラクタの位置の変化の程度および動作の変化の程度を変化後のキャラクタ情報として前記管理キャラクタ毎に演算する処理と，をコンピュータに実行させるようにしてもよい。
【００５８】
このとき，前記ゲームで登場する前記複数のキャラクタは，さらに，前記サーバ機器の制御により自動的に動作する１または複数のサーバキャラクタを含んでいてもよい。また，前記キャラクタ管理プログラムは，さらに，前記演算された各管理キャラクタの位置の変化の程度に基づいて，前記各管理キャラクタの演算後の位置と自己のサーバ機器が管理するいずれかのサーバキャラクタの位置とクライアント機器が管理するプレイヤキャラクタの位置との相対関係を求め，前記求められた位置の相対関係に基づき各管理キャラクタを前記サーバキャラクタ毎に管理するサーバ機器またはクライアント機器を判定する処理と，前記クライアント機器により管理されると判定された管理キャラクタの登録を前記自己のサーバ機器の記憶部から削除する処理と，前記クライアント機器により管理されると判定された管理キャラクタのキャラクタ情報を含んだキャラクタ管理変更パケットを前記クライアント機器に送信する処理と，をコンピュータに実行させるようにしてもよい。
【００５９】
前記キャラクタ管理プログラムは，前記１または複数のクライアント機器により管理される１または複数のプレイヤキャラクタと前記１または複数のプレイヤキャラクタを護衛する１または複数のノンプレイヤキャラクタが味方集団を形成し，且つ前記サーバ機器により管理される１または複数のサーバキャラクタと前記サーバキャラクタを護衛する１または複数のノンプレイヤキャラクタが敵集団または味方集団の少なくともいずれかを形成して互いに戦闘するゲームを提供するプログラムであってもよい。
【００６０】
これによれば，ゲームに参加するユーザが足りない場合であっても（たとえば，ゲームに参加するユーザが一人だとしても），操作するユーザがいないプレイヤキャラクタおよび自己のサーバ機器が管理するノンプレイヤキャラクタについては，サーバ機器が，それらのキャラクタを自動的に操作する。これにより，参加者が足りなくても，ユーザは，ゲームを思う存分楽しむことができる。また，クライアント機器により管理されるキャラクタとサーバ機器により管理されるキャラクタとを分けることによって，システム全体の処理を分散し，これにより，ゲームをスムーズに進行させることができる。
【発明の効果】
【００６１】
以上説明したように本発明によれば，複数のキャラクタが登場するネットワークゲームシステムにおいてそれらのキャラクタをスムーズに動作させるために，登場する各キャラクタの処理および管理を分散して実行するネットワークゲームシステム，クライアント機器，サーバ機器およびこれらを制御するプログラムを提供することができる。
【発明を実施するための最良の形態】
【００６２】
以下に添付図面を参照しながら，本発明の好適な実施形態について詳細に説明する。なお，以下の説明及び添付図面において，同一の構成及び機能を有する構成要素については，同一符号を付することにより，重複説明を省略する。
【００６３】
（第１実施形態）
（ネットワークゲームシステムの全体構成）
まず，本発明の第１実施形態にかかるネットワークゲームシステムの全体構成およびこのシステムにて実行されるゲームの概要について，図１を参照しながら説明する。
【００６４】
ネットワークゲームシステム１０は，ネットワークゲームサーバ（以下，ゲームサーバと称呼する。）１００と複数のゲーム機２００（２００ａ，２００ｂ，２００ｃ）とを含んで構成されている。ここでは，ＰＣ２００ａも，ゲーム機２００として機能するので，以下の説明ではゲーム機２００に含んで説明する。ゲームサーバ１００と複数のゲーム機２００とは，インターネット等のネットワーク（通信回線）３００を介して接続されている。
【００６５】
ゲームサーバ１００は，ネットワークゲームの進行および管理を制御する。具体的には，ゲームサーバ１００は，主にチート対策，すなわち，不正行為の有無の判定とその排除や送受信データの整合性チェックを行う。また，ゲームサーバ１００は，各ゲーム機２００から種々のデータを受信したり，他のゲーム機２００に種々のデータを一斉に送信する。ゲームサーバ１００は，その他アイテム情報の管理（どのプレイヤが何を持っているか）やプレイヤにより操作されるプレイヤキャラクタの体力情報などを記憶管理している。ゲームサーバ１００は，ネットワークゲームを提供する側のコンピュータ（サーバ機器）の一例であり，ネットワーク３００に接続されたクライアント機器（ゲーム機器）の一つがゲームサーバ１００として機能してもよい。
【００６６】
ゲーム機２００は，プレイヤの操作に応じてネットワークゲームを遂行する。ゲーム機２００は，ネットワークゲームに登場するキャラクタのうち，後述する管理キャラクタを管理する。ネットワークゲームに登場するキャラクタは，いずれかのゲーム機２００に管理されるものとし，同じキャラクタが複数のゲーム機２００により管理されることはない。
【００６７】
また，各ゲーム機２００は，自分が管理しているキャラクタのキャラクタ情報を，ゲームサーバ１００を介して他のゲーム機２００に送り続ける。ここで，キャラクタ情報は，キャラクタのモーション等そのキャラクタの状態を示す情報である。また，各ゲーム機２００は，他のゲーム機２００から送信されたキャラクタ情報を受け取った時点でそのモーション処理（ゲーム上のキャラクタの動作処理）を開始する。また，ゲーム機２００は，モーションと同じタイミングでコリジョン判定（当たり判定，衝突判定）を行う。
【００６８】
ゲーム機２００は，ゲームサーバ１００からサービスを受ける側のコンピュータ（クライアント機器）の一例であって，家庭用ゲーム装置であっても携帯ゲーム機であってもよい。クライアント機器の他の例としては，パーソナルコンピュータ（ＰＣ）の他に携帯デバイス（たとえば，携帯電話，ＰＤＡ（Personal Digital Assistants））等のユーザ端末であってもよい。なお，各ゲーム機２００は，ＴＣＰ／ＩＰ等の通信プロトコルによりネットワーク３００に接続され，各々異なるＩＰアドレスが割り振られているため，各プレイヤは，各種データを送受信したゲーム機２００を各々識別することができる。
【００６９】
また，ゲーム機２００は，たとえば，図２に示したように，ゲーム機本体２００ａ１とコントローラパッド等２００ａ２（入力装置）とテレビモニタ２００ａ３とから構成されていてもよい。ゲーム機２００ａで使用されるプログラム，画像，音楽等の各種データがＣＤ−ＲＯＭ４００（または，ＤＶＤ）等の記録媒体に記録されている場合には，プレイヤ（ユーザ）は，ＣＤ−ＲＯＭ４００等の記録媒体をゲーム機本体２００ａ１に挿入することによりゲームをスタートさせることができる。
【００７０】
（ネットワークゲームシステムの概要）
このように構成されたネットワークゲームシステム１０では，複数のゲーム機２００によりそれぞれ管理される複数のプレイヤキャラクタ，および，これら複数のプレイヤキャラクタのそれぞれ脇役となる複数のノンプレイヤキャラクタからなる複数のキャラクタが登場するネットワークゲームが提供される。そして，各ゲーム機２００のプレイヤが各プレイヤキャラクタをそれぞれ操作することにより，複数のキャラクタがゲーム上で動作してゲームが進行する。以下の実施形態では，このネットワークゲームシステム１０によって提供されるネットワークゲームとして，複数のプレイヤキャラクタとこれら複数のプレイヤキャラクタを護衛するノンプレイヤキャラクタとからなる複数のキャラクタが敵味方の集団を形成して互いに戦闘するゲームを例に挙げて説明する。
【００７１】
（集団戦闘ネットワークゲーム）
まず，このゲームの概要を説明する。あるプレイヤが，ネットワーク３００に接続された自己のゲーム機２００を用いて自己のプレイヤキャラクタを操作すると，このプレイヤキャラクタを小隊長とした複数の味方コンピュータキャラクタ（ノンプレイヤキャラクタ）で構成される自小隊がプレイヤの操作にしたがって画面上を移動し，武器を使って戦う。同時に，他のプレイヤが，ネットワーク３００に接続された他ゲーム機２００を用いて敵プレイヤキャラクタを操作すると，この敵プレイヤキャラクタを小隊長とした敵小隊が画面上を移動し，武器を使って戦う。プレイヤは，自己のプレイヤキャラクタを操作して戦闘することにより自己のプレイヤキャラクタのレベルや能力等のパラメータを上昇させたり，ネットワーク３００を介して接続された他のプレイヤの領土を占領することができる。なお，このゲームに登場するキャラクタは，前述したように，プレイヤが操作可能なプレイヤキャラクタに限らず，各ゲーム機２００による自動的な演算により動作するノンプレイヤキャラクタも存在し，プレイヤキャラクタとノンプレイヤキャラクタとがディスプレイ上に小隊を組んで表示される。本実施形態にかかる集団戦闘ネットワークゲームは，このようにしてネットワーク３００を介して自小隊と味方小隊と敵小隊とが集団で対戦するゲームである。
【００７２】
集団戦闘ネットワークゲームには，８台のゲーム機２００が４台ずつ敵味方に分かれて参加するものとする。参加する８人のプレイヤのうち，たとえば，４人を徳川軍，残りの４人を豊臣軍し，各軍は，４小隊で構成され，各小隊は１体のプレイヤキャラクタと最大７９体のノンプレイヤキャラクタとから構成されるものとする。なお，以下の説明では，便宜上，各プレイヤが操作するプレイヤキャラクタをＰＣ（Ｐｌａｙｅｒ Ｃｈａｒａｃｔｅｒ）といい，このうち，自プレイヤが操作するプレイヤキャラクタを自ＰＣ，他プレイヤが操作する味方のプレイヤキャラクタを味方ＰＣ，他プレイヤが操作する敵のプレイヤキャラクタを敵ＰＣという。
【００７３】
また，８体のＰＣをそれぞれ護衛するコンピュータキャラクタをＮＰＣ（Ｎｏｎ Ｐｌａｙｅｒ Ｃｈａｒａｃｔｅｒ，ノンプレイヤキャラクタ）といい，このうち，自プレイヤまたは味方プレイヤを護衛するノンプレイヤキャラクタを味方ＮＰＣといい，敵プレイヤを護衛するノンプレイヤキャラクタを敵ＮＰＣという。
【００７４】
たとえば，図１１では，ＰＣ１が自ＰＣ，ＰＣ２およびＰＣ４が味方ＰＣ，ＰＣ３が敵ＰＣである。また，ＰＣ１，ＰＣ２およびＰＣ４の周囲にてそれぞれの小隊境界線内に位置するＮＰＣ（ＮＰＣ１１を含む。）が味方ＮＰＣ，ＰＣ３の周囲にて小隊境界線内に位置するＮＰＣ（ＮＰＣ３１を含む。）が敵ＮＰＣである。
【００７５】
（ノンプレイヤキャラクタの管理の原則）
つぎに，各キャラクタがどの機器によって管理されるかについて，その原則を説明する。まず，上述した複数の小隊のうち，自小隊に属する自ＰＣおよびＮＰＣは，原則として自己のゲーム機２００に管理される。味方ＰＣの他小隊に属する味方ＰＣおよびＮＰＣは，原則として味方ＰＣを操作するゲーム機２００に管理される。同様に，敵ＰＣの他小隊に属する敵ＰＣおよびＮＰＣは，原則として敵ＰＣを操作するゲーム機２００に管理される。なお，ＰＣをゲームサーバ１００にて自動的に管理する場合（たとえば，ゲームに参加するプレイヤが足りず，１または２以上の敵ＰＣまたは味方ＰＣをゲームサーバ１００にて自動管理することとなった場合）には，このＰＣの小隊に属するＮＰＣもゲームサーバ１００により自動的に管理されるように制御してもよい。これについては第３実施形態にて詳細を説明する。そして，以下の第１実施形態および実施形態２の説明では，すべてのＮＰＣは，いずれかのゲーム機２００により管理されることとする。
【００７６】
なお，本実施形態では，ネットワーク仮想空間上に存在するすべてのキャラクタは，いずれかのゲーム機２００に管理されるようになっている。すなわち，各ゲーム機２００は，自分が管理するキャラクタの位置，モーション情報（再生中のモーション番号，現在のフレーム番号）などを所定周期毎に演算し，演算された情報に基づいてキャラクタの動作をディスプレイに描画するとともに，演算されたデータをキャラクタ情報としてゲームサーバ１００を介して他のゲーム機２００に送信する。他のゲーム機２００は，送信されたキャラクタ情報（詳細は後述）を受信し，受信した情報データに基づいてキャラクタの動作をディスプレイに描画するとともに，記憶領域に記憶されているキャラクタ情報を更新する。
【００７７】
このように，本実施形態のネットワークゲームシステム１０は，完全非同期型（同一フレームで各ゲーム機のキャラクタ情報が食い違っていても，違ったままゲームを進行するタイプ）を採用する。これによれば，自ゲーム機２００が操作する自ＰＣが，自ゲーム機２００によって管理される管理キャラクタを攻撃した場合には，自ゲーム機２００により管理キャラクタの攻撃後のモーションが演算され，この演算結果により自ゲーム機２００では，管理キャラクタのダメージモーションが即座に再生される。しかし，自ゲーム機２００が操作する自ＰＣが，他ゲーム機２００が管理するキャラクタを攻撃した場合には，往復（自ゲーム機２００→ゲームサーバ１００→他ゲーム機２００→ゲームサーバ１００→自ゲーム機２００）の通信時間が経過した後に，自ゲーム機２００にて攻撃されたキャラクタのダメージモーションが再生されることになる。
【００７８】
この性質を利用して，ＰＣと各ＮＰＣとの距離に応じて各ＮＰＣを管理するゲーム機２００を切り替えることにより，各キャラクタのモーションの遅延を感じる機会を少なくすることができ，この結果，プレイヤの操作感覚を良好にすることができる。そこで，ＮＰＣは，敵味方に関係なくその座標から最も近いＰＣを管理するゲーム機２００により管理されるようにする。以下に，この戦闘ゲームを管理するゲームサーバ１００について説明し，ついで，ゲーム機２００が各ＮＰＣの管理をどのように切り替えるのかについて説明する。
【００７９】
（ゲームサーバおよびゲーム機の内部構成）
まず，ゲームサーバ１００およびゲーム機２００のハードウエア構成について，図３および図４を参照しながら説明する。図３は，ゲームサーバ１００のハードウエア構成を示し，図４は，ゲーム機２００のハードウエア構成を示したものである。
【００８０】
図３のゲームサーバ１００は，ＲＯＭ１０５，ハードディスク（ＨＤＤ）１１０，ＣＰＵ１１５，ＲＡＭ１２０，バス１２５，画像生成回路１２７，内部インタフェース（内部Ｉ／Ｆ）１３０および外部インタフェース（外部Ｉ／Ｆ）１３５を含んで構成されている。
【００８１】
ＲＯＭ１０５には，ゲームサーバ１００を動作させるための基本的なプログラムや，ゲームサーバ１００が異常なときに起動するプログラム等が記録されている。ハードディスク１１０には各種プログラムやデータが蓄積されている。ハードディスク１１０は，記憶装置の一例であり，光ディスクや光磁気ディスクなどの記憶装置であってもよい。
【００８２】
ＣＰＵ１１５は，ゲームサーバ１００全体を制御する。ＣＰＵ１１５は，ハードディスク１１０等に記憶されたプログラムをワーク用のＲＡＭ１２０にロードした後，そのプログラムを実行するようになっている。バス１２５は，ＲＯＭ１０５，ハードディスク１１０，ＣＰＵ１１５，ＲＡＭ１２０，画像生成回路１２７，内部インタフェース１３０および外部インタフェース１３５の各デバイス間で情報をやりとりする経路である。
【００８３】
画像生成回路１２７は，グラフィックチップとＶＲＡＭとから構成されていて，ＣＰＵ１１５から画像の生成を指示されると，その指示に従ってＣＰＵ１１５とは別な時系列で画像を生成する。
【００８４】
内部インタフェース１３０は，キーボード４０５やマウス４１０からネットワークゲームに関するデータを入力し，必要なデータをモニタ４１５に出力するようになっている。外部インタフェース１３５は，ネットワーク３００を介してゲームに参加している他のゲーム機２００と各種データを送受信するようになっている。
【００８５】
図４のゲーム機２００は，ＲＯＭ２０５，ハードディスク（ＨＤＤ）２１０，ＣＰＵ２１５，ＲＡＭ２２０，バス２２５，画像生成回路２２７，音響再生回路２２９，内部インタフェース２３０，外部インタフェース２３５およびリーダ２４０を含んで構成されている。
【００８６】
ＲＯＭ２０５には，ゲームを実行させるためのプログラム等が記録されている。ハードディスク２１０には各種プログラムや各種データが蓄積されている。ハードディスク２１０は，記憶装置の一例であり，光ディスクや光磁気ディスクなどの記憶装置であってもよい。
【００８７】
ＣＰＵ２１５は，ゲーム機２００全体を制御する。ＣＰＵ２１５は，ハードディスク２１０に記憶されたプログラムをゲーム機２００内のワーク用のＲＡＭ２２０にロードする。または，ＣＰＵ２１５は，リーダ２４０が読み込んだＣＤ−ＲＯＭ４００内のプログラムをＲＡＭ２２０にロードする。ＣＰＵ２１５は，このようにしてＲＡＭ２２０にロードされたプログラムを実行することによりゲームをスタートさせ，ゲームサーバ１００と逐次通信しながらゲームを進行するようになっている。
【００８８】
なお，一旦，ＣＰＵ２１５が，記録媒体上のプログラム等をＲＡＭ２２０上にコピーしてしまえば，次回からはＲＡＭ２２０上のプログラム等を実行することによりゲームをスタートすることができる。また，一旦，ＣＰＵ２１５が，ゲーム機２００内のハードディスク２１０に，ＣＤ−ＲＯＭ４００上のプログラム等をコピーしてしまえば，次回以降は，ハードディスク２１０上のプログラムを実行することによりゲームをスタートすることもできる。また，ネットワーク３００上にこれらのプログラム等がアップロードされている場合には，ＣＰＵ２１５が，一旦，これらのプログラムをゲーム機２００のＲＡＭ２２０にダウンロードした後，そのプログラムをスタートさせるようにしてもよいし，一旦，ゲーム機２００のハードディスク２１０にこれをダウンロードし，次回以降は，ハードディスク２１０に記憶されたプログラムを起動させることによりゲームをスタートさせるようにしてもよい。
【００８９】
バス２２５は，ＲＯＭ２０５，ハードディスク２１０，ＣＰＵ２１５，ＲＡＭ２２０，画像生成回路２２７，音響再生回路２２９，内部インタフェース２３０，外部インタフェース２３５およびリーダ２４０の各デバイス間で情報をやりとりする経路である。
【００９０】
画像生成回路２２７は，グラフィックチップとＶＲＡＭとから構成されていて，ＣＰＵ２１５から画像の生成を指示されると，その指示に従って画像を生成する。音響再生回路２２９は，サウンドチップとサウンドＲＡＭとから構成されていて，ＣＰＵ２１５からサウンドの生成を指示されると，その指示に従って各管理キャラクタの戦闘動作に対応したバックミュージックや戦闘音等の音響処理を行う。
【００９１】
内部インタフェース２３０は，コントローラパッド４３０やキーボード４３５やマウス４４０等を用いてプレイヤのゲーム操作を入力するとともに，敵味方の集団を形成して互いに戦闘する複数のキャラクタの映像および音響をモニタ４４５およびスピーカ４５０にそれぞれ出力するようになっている。外部インタフェース２３５は，ネットワーク３００を介して，プレイヤによる操作に応じたコマンドやメッセージ等の各種データをゲームサーバ１００に送受信するようになっている。リーダ２４０は，ＣＤ−ＲＯＭ４００からデータを読み込む。
【００９２】
つぎに，ゲームサーバ１００およびゲーム機２００の機能構成について，図５および図６を参照しながら説明する。
（ゲームサーバの機能構成）
図５に示したように，ゲームサーバ１００は，入力部１４０，通信部１４５，記憶部１５０，管理部１５５，画像処理部１６０および画像生成部１６５の機能ブロックにて示される各機能を有している。
【００９３】
入力部１４０は，ネットワークゲームを管理する管理者によるキーボード４０５またはマウス４１０の操作に応じてデータを入力する。通信部１４５は，ゲームに参加している複数のゲーム機２００に必要な情報を送受信する。
【００９４】
記憶部１５０は，複数のキャラクタ（プレイヤキャラクタＰＣおよびノンプレイヤキャラクタＮＰＣ）の位置情報と各ノンプレイヤキャラクタＮＰＣを各々管理するゲーム機２００の識別情報とを含んだキャラクタ情報を記憶する。
【００９５】
管理部１５５は，ゲーム中のデータの整合性を保ち，ゲームを矛盾なく進行させるために，入力部１４０により入力されるデータ，通信部１４５により送受信されるデータ，記憶部１５０の各記憶領域（ＲＯＭ１０５，ＲＡＭ１２０，ハードディスク１１０）に記憶されたデータを管理したり，ゲーム中の各処理のタイミングを管理する。
【００９６】
画像処理部１６０は，ゲームの進行に会わせて必要なパラメータとコマンドとを生成し，これらを画像生成部１６５に出力することにより，画像生成部１６５に画像の生成を指示するようになっている。画像生成部１６５は，画像処理部１６０からの画像の生成の指示を受けて，光源処理等を行い，キャラクタ情報にしたがった各管理キャラクタの戦闘動作を３次元フィールドでモニタ４４５に描画する。
【００９７】
（ゲーム機の機能構成）
図６に示したように，ゲーム機２００は，媒体読取部２４５，入力部２５０，記憶部２５５，アクション処理実行部２６０，画像生成部２６５，音響再生部２７０，判定部２７５および通信部２８０の機能ブロックにて示される各機能を有している。
【００９８】
媒体読取部２４５は，ＣＤ−ＲＯＭ４００等の記録媒体に記憶されたデータを読み込む。たとえば，プレイヤが，ＣＤ−ＲＯＭ４００をゲーム機２００に挿入してゲームをスタートすると，媒体読取部２４５は，自動的にそのプログラム等のデータを読み込み，ＲＡＭ２２０に転送するようになっている。
【００９９】
入力部２５０は，プレイヤが，モニタ４４５に表示されるネットワークゲームの画面を見ながら，ゲーム機２００に接続されたゲームコントローラパッド４３０，キーボード４３５，マウス４４０等の入力装置を操作すると，この操作に応じてデータを入力する。
【０１００】
記憶部２５５は，複数のキャラクタの位置情報を含んだキャラクタ情報をＲＡＭ２２０に記憶するとともに，ノンプレイヤキャラクタのうち自己のゲーム機２００が管理するキャラクタを管理キャラクタとしてＲＡＭ２２０に登録する。
【０１０１】
ここで，ＲＡＭ２２０に記憶される各情報について図７を参照しながら説明する。図７は，ＲＡＭ２２０に記憶されたキャラクタ情報のデータ構造の一例を示す。
【０１０２】
ＲＡＭ２２０には，まず，プレイヤキャラクタのうち，自ゲーム機器２００により管理される自プレイヤキャラクタ（自ＰＣ０）のＰＣデータが記憶される。ＲＡＭ２２０には，自ＰＣ０のキャラクタ情報として，ＰＣ番号，座標（ｘ，ｙ，ｚ），キャラクタの体の向き（角度），モーション番号，再生フレーム位置，進行方向，所属軍，管理中のキャラクタ数が保持される。
【０１０３】
ＰＣ番号には，自ＰＣ０を管理するゲーム機（ＣＬ，クライアント機器）の識別番号が付けられている。ここでは，ＰＣ番号として「０」が登録されているが，この番号は，そのＰＣを管理するゲーム機を識別できる情報であればこれに限られない。
【０１０４】
座標（ｘ，ｙ，ｚ）は，仮想空間上のキャラクタの位置を示す。モーション番号は，予め作成されたキャラクタの動作（モーション）を示すモーションデータの番号を示す。各モーションデータには，固有のモーション番号が付けられ，そのデータ自体は，各ゲーム機２００のハードディスク２１０等の記録媒体上に記録されている。
【０１０５】
キャラクタの動作は，フレーム（画像処理の時間的単位）毎に描画されるので，再生フレーム位置は，モーション番号に示されるモーションが再生されるフレームの位置を示す。進行方向は，キャラクタが進行する方向をベクトルで示したものである。所属軍は，自ＰＣ０が属する軍であり，現在は味方の「徳川」であるが，敵の軍に所属する場合もある。管理中のキャラクタ数は，自ゲーム機２００にて管理されている管理キャラクタ（ノンプレイヤキャラクタＮＰＣ）の数を示していて，７９以下の数値を取るようになっている。
【０１０６】
また，ＲＡＭ２２０には，自プレイヤキャラクタ（自ＰＣ０）を護衛する７９体の自ノンプレイヤキャラクタ（自ＮＰＣ１〜自ＮＰＣ７９）のキャラクタ情報が記憶される。ノンプレイヤキャラクタ（ＮＰＣ）のキャラクタ情報が，プレイヤキャラクタ（ＰＣ）のキャラクタ情報と異なる点は，プレイヤキャラクタ（ＰＣ）では，最後に「キャラクタ情報に管理中のキャラクタ数」が含まれていたのに対し，ノンプレイヤキャラクタ（ＮＰＣ）では，最後に「キャラクタ情報に管理元のＰＣ番号」が含まれている点である。たとえば，自ノンプレイヤキャラクタ１（自ＮＰＣ１）の管理元のＰＣ番号は，「０」である。これは，自ＮＰＣ１が，自ＰＣ０の管理キャラクタとしてＲＡＭ２２０に登録されていることを示している。
【０１０７】
また，ＲＡＭ２２０には，７体の他プレイヤキャラクタ（他ＰＣ１〜他ＰＣ７）のキャラクタ情報が記憶されるとともに，各他プレイヤキャラクタを各々護衛する他ノンプレイヤキャラクタ（他ＮＰＣ１−１〜他ＮＰＣ１−７９，他ＮＰＣ２−１〜他ＮＰＣ２−７９他，他ＮＰＣ３−１〜他ＮＰＣ３−７９，他ＮＰＣ４−１〜他ＮＰＣ４−７９，他ＮＰＣ５−１〜他ＮＰＣ５−７９，他ＮＰＣ６−１〜他ＮＰＣ６−７９，他ＮＰＣ７−１〜他ＮＰＣ７−７９）のキャラクタ情報が記憶されている。このようにして，ＲＡＭ２２０には，ゲームに登場するすべて（＝６４０体）のキャラクタのキャラクタ情報が記憶され，これらの情報を用いて，戦闘ゲーム中の各キャラクタが次にとるアクションが演算されたり，どのキャラクタを自ゲーム機２００にて管理しなければならないかが判定される。
【０１０８】
再び，図６に戻って，アクション処理実行部２６０は，演算部２６０ａ，画像処理部２６０ｂおよび音響処理部２６０ｃを有する。アクション処理実行部２６０は，記憶部２５５に登録されている各管理キャラクタのアクション処理を管理キャラクタ毎に実行する。具体的には，演算部２６０ａは，記憶部２５５に記憶されたキャラクタ情報を用いて，ゲーム上の戦闘によって発生する各管理キャラクタの位置の変化および動作の変化を表す変化量をそれぞれ演算することにより変化後のキャラクタ情報を生成する。
【０１０９】
画像処理部２６０ｂは，ゲームの進行に会わせて必要なパラメータとコマンドとを生成し，これらを画像生成部２６５に出力することにより，画像生成部２６５に画像の生成を指示する。画像生成部２６５は，画像処理部２６０ｂからの画像の生成の指示を受けて，画像を生成し,生成された画像をモニタ４４５に表示する。
【０１１０】
音響処理部２６０ｃは，音響再生部２７０にサウンドの再生を指示する。音響再生部２７０は，各管理キャラクタの戦闘動作に対応したバックミュージックや戦闘音等の音響処理を行い，スピーカ４５０に出力する。このようにして表現される臨場感あふれる画像や音響を通じて，プレイヤは，自分のプレイヤキャラクタをそのネットワークゲームの仮想空間内で移動させたり，他のキャラクタと戦わせることができる。
【０１１１】
判定部２７５は，演算部２６０ａにより演算された各管理キャラクタの位置の変化値に基づいて，自己のゲーム機２００が管理するプレイヤキャラクタの位置と，他のゲーム機２００が管理するプレイヤキャラクタの位置と，各管理キャラクタのアクション処理後の位置との相対関係を求め，求められた位置の相対関係に基づき各管理キャラクタを管理するか否かを判定する。
【０１１２】
通信部２８０は，演算部２６０ａにより演算された変化後の各管理キャラクタのキャラクタ情報をキャラクタ情報パケットとしてゲームサーバ１００に送信する。また，通信部２８０は，他のゲーム機２００により管理されると判定された管理キャラクタのキャラクタ情報をキャラクタ管理変更パケットとしてゲームサーバ１００に送信する。なお，同一内容であっても，本明細書及び図面中では，ＲＡＭ２２０等のメモリ内に保持しているデータの場合は「〜情報」と表記し，送受信するデータの場合は「〜パケット」と表記する。
【０１１３】
さらに，通信部２８０は，ゲームサーバ１００から送信されたキャラクタ情報パケットを受信する。すなわち，通信部２８０は，ネットワークゲーム内で起こった変動結果の情報や，他のプレイヤにより送信され，ゲームサーバ１００を介して転送される情報，或いはゲームサーバ１００が自発的に送信する情報等種々のデータを受信する。
【０１１４】
このようにして受信されたキャラクタ情報または演算部２６０ａにより演算されたキャラクタ情報に基づいて，アクション処理実行部２６０が，アクション処理を管理キャラクタ毎に実行することにより，ゲーム機２００とゲームサーバ１００とが逐次通信しながらネットワークゲームが進行するようになっている。
【０１１５】
なお，以上に説明したゲームサーバ１００およびゲーム機２００の各機能は，実際には，ＣＰＵがこれらの機能を実現する処理手順を記述したプログラムを実行することにより，または，いずれかの機能を実現するためのハードウエアやＩＣを制御することにより達成される。たとえば，図５に示したゲームサーバ１００の管理部１５５および画像処理部１６０の機能は，これらの機能を実現する処理手順を記述したプログラムを図３のＣＰＵ１１５が実行することにより達成され，画像生成部１６５の機能は，グラフィックチップ（画像生成回路１２７）により達成される。また，図６に示したゲーム機２００のアクション処理実行部２６０および判定部２７５の機能は，これらの機能を実現する処理手順を記述したプログラムを図４のＣＰＵ２１５が実行することにより達成され，画像生成部２６５および音響再生部２７０の機能は，グラフィックチップ（画像生成回路２２７）およびサウンドチップ（音響再生回路２２９）によりそれぞれ達成される。
【０１１６】
以上に説明した本実施形態にかかるネットワークゲームシステム１０では，まず，プレイヤが，自己のゲーム機２００を用いて自分が担当するプレイヤキャラクタを選択する。プレイヤキャラクタには，例えば戦国時代をテーマとしたゲームであれば，侍，忍者，陰陽師等があり，通常はこれらの中から１つを選択する。その後，プレイヤは，自分のプレイヤキャラクタを操作して戦闘することによりプレイヤキャラクタのレベルや能力等のパラメータを上昇させたり，ネットワーク３００を介して接続された他のゲーム機２００を操作する他のプレイヤのキャラクタと戦う。なお，この仮想空間に登場するキャラクタは，いわゆるプレイヤが操作するプレイヤキャラクタに限らず，各ゲーム機２００による自動的な演算により動作するノンプレイヤキャラクタ（ＮＰＣ）も存在し，これらのキャラクタが各ゲーム機２００の画面に表示される。
【０１１７】
（ゲーム機の動作，アクション処理およびキャラクタ管理処理）
つぎに，ゲーム機２００の動作について，図８〜図１０を参照しながら説明することにより，本実施形態の特徴であるアクション処理およびキャラクタ管理処理について詳述する。図８は，各ゲーム機２００が実行するクライアント側管理処理（メインルーチン）を示したフローチャートである。図９は，図８のメインルーチンにて呼び出されるキャラクタ管理処理を示したフローチャートである。図１０は，図９のサブルーチンにて呼び出されるキャラクタ変更判定処理を示したフローチャートである。なお，自プレイヤの小隊と他のプレイヤの小隊との動作に関しては同様な処理がなされるため，以下のフローチャートにおいては，説明を簡単にするために，自プレイヤの小隊を中心に記載し，他のプレイヤの小隊を中心とした記載を省略する。また，その他のゲーム上必要ではあるが本願発明と直接関係のない具体的な処理の説明は省略するものとする。
【０１１８】
また，このネットワークゲームを開始する前に，プレイヤは予めユーザ登録しておく必要がある。すなわち，プレイヤは，ゲーム機２００の画面に表示される指示に従って個人情報を入力することにより，ゲームサーバ１００に個人情報等を送信し，ユーザＩＤ及びパスワードを取得する。２回目以降にゲームを行うときには，プレイヤは，取得したユーザＩＤ及びパスワードを画面に入力するだけでゲームサーバ１００にアクセスすることができるようになる。
【０１１９】
（ゲームスタート）
ゲーム機２００の電源が「ＯＮ」され，プレイヤからゲームの開始が要求されると，図８のステップ８００から処理が開始され，ステップ８０５にて初期設定が行われる。具体的には，記憶部２５５は，プレイヤによって選択されたプレイヤキャラクタ（自ＰＣ）および各キャラクタのキャラクタ情報をＲＡＭ２２０に予め登録する。また，通信部２８０は，ユーザ認証し，その後，ゲームサーバ１００との間で各キャラクタのキャラクタ情報を送受信する。これにより，ゲームサーバ１００およびゲームに参加しているすべてのゲーム機２００のＲＡＭに，図７にて示した各キャラクタのキャラクタ情報が予め登録される。さらに，ゲームサーバ１００は，各キャラクタを管理するゲーム機２００をすべてのキャラクタについてそれぞれ特定し，ゲームサーバ１００および各ゲーム機２００のＲＡＭ（具体的には，図７に示した管理元のＰＣ番号の項目）に記憶する。なお，ゲームサーバ１００には，必ずしも，各キャラクタのキャラクタ情報を記憶しておく必要はない。
【０１２０】
つぎに，ステップ８１０にて，判定部２７５は，割込み（垂直帰線割込（Ｖｓｙｎｃ））が発生したか否かを判定する。判定部２７５は，モニタ４４５の垂直帰線周期と一致した１／６０秒（１６．６ミリ秒）に一度の周期で割込みが発生すると，これに応じて，ステップ８１０にて「ＹＥＳ」と判定し，ステップ８１５に進んでキャラクタ管理処理を実行する。キャラクタ管理処理については後述する。
【０１２１】
つぎに，判定部２７５は，ステップ８２０に進んでゲームが終了か否かを判定する。具体的には，プレイヤが，ゲーム機２００の電源を「ＯＦＦ」するか，または，画面上のゲーム終了を選択することによりゲームは終了する。そこで，プレイヤがこれらのいずれかの操作をするまで，ゲーム機２００は，基本的に，ステップ８１０〜ステップ８２０の処理を繰り返し，プレイヤがこれらのいずれかの操作をするとステップ８９５に進んでゲームを終了する。
【０１２２】
ステップ８１０で割込みが発生していない場合，判定部２７５は，「ＮＯ」と判定してステップ８２５でメイン処理を実行し，その後ステップ８２０に進む。このメイン処理においては，本実施形態におけるネットワークゲームと直接関係しないその他の処理，例えば，プレイヤがコントローラパッド４３０等を操作することにより入力され，入力部２５０を介して取り込まれた入力情報を，ＲＡＭ２２０に記憶して随時更新する処理や，ゲーム効果音を音響処理部２６０ｃおよび音響再生部２７０を用いて合成させるための音響処理等の処理も，ここで実行するものとする。また，本実施形態では，一定間隔でクライアント側管理処理が行われる例（すなわち，垂直帰線周期の割込処理内でキャラクタ管理処理が行われる例）を示したが，図示しないタイマー割込処理内やステップ８２５のメイン処理内でキャラクタ管理処理が行われるようにしてもよい。
【０１２３】
（キャラクタ管理処理）
つぎに，ステップ８１５のキャラクタ管理処理について，図９のフローチャートを参照しながら説明する。ステップ９００から処理が開始されると，通信部２８０は，ステップ９０５にて，他のゲーム機２００から送信されたキャラクタ管理変更パケットを受信したか否かを判定する。キャラクタ管理変更パケットを受信した場合には，ステップ９１０に進んで，記憶部２５５は，キャラクタ管理変更パケットに含まれるキャラクタ情報に基づきＲＡＭ２２０の該当キャラクタ情報を更新する。具体的には，図７の該当ＰＣまたは該当ＮＰＣに記憶された座標，体の向き，モーション番号，再生フレーム位置，進行方向，所属軍の情報を更新する。また，記憶部２５５は，このキャラクタ情報により特定されるキャラクタを管理キャラクタとしてＲＡＭ２２０に登録する。具体的には，図７の該当キャラクタ情報の管理元のＰＣ番号を変更する。
【０１２４】
つぎに，ステップ９１５に進み，通信部２８０は，ステップ９１５にて，他のゲーム機２００からキャラクタ情報パケットを受信したか否かを判定する。キャラクタ情報パケットを受信した場合には，ステップ９２０に進んで，記憶部２５５は，キャラクタ情報パケットに含まれるキャラクタ情報に基づきＲＡＭ２２０の該当キャラクタ情報を更新する。具体的には，図７の該当ＰＣまたは該当ＮＰＣに記憶された座標，体の向き，モーション番号，再生フレーム位置，進行方向，所属軍の情報を更新する。なお，フレームとは，画像処理の時間的単位であり，描画の際のいわゆる「コマ」を示している。本実施形態では，１フレームの時間は，垂直帰線割込処理の周期の１／２の時間（１／３０秒）に相当する。
【０１２５】
ついで，ステップ９２５に進んで，アクション処理実行部２６０は，アクション処理を実行する。アクション処理とは，具体的には，アクション処理実行部２６０の各部により実行されるつぎの処理をいう。まず，演算部２６０ａは，ＲＡＭ２２０に記憶されたキャラクタ情報（具体的には，自ゲーム機の管理キャラクタ情報および他ゲーム機の管理キャラクタ情報の相対関係）に基づき，プレイヤの操作に応じて各管理キャラクタの位置の変化量および動作の変化量を含んだキャラクタ情報を演算する。管理キャラクタ毎にこの演算を行うことにより，各キャラクタは，攻撃が当たったらダメージモーションに移行するなどのアクションを行うことができる。
【０１２６】
また，画像処理部２６０ｂは，画像生成部２６５に画像の生成を指示し，画像生成部２６５は，これを受けて，演算後のキャラクタ情報に基づいて各キャラクタの仮想空間上の位置および動作をグラフィック処理する。また，音響処理部２６０ｃは，音響再生部２７０に音響の生成を指示し，音響再生部２７０は，これを受けて，演算後のキャラクタ情報に基づいて各キャラクタの状態にあった音響を生成する。この結果，各プレイヤの操作に応じたキャラクタの動作がモニタ４４５に表示されると同時に，ゲームの展開に応じた音響がスピーカ４５０から出力されることにより，各プレイヤの操作に応じたゲームが展開される。
【０１２７】
つぎに，ステップ９３０に進み，判定部２７５は，キャラクタ変更判定処理（サブルーチン）を実行する。この処理は，各管理キャラクタの位置と敵ＰＣおよび味方ＰＣおよび自ＰＣの位置との関係から当該キャラクタが管理されるべきゲーム機２００を判定する処理であるが，後程詳述する。
【０１２８】
ついで，ステップ９３５に進み，通信部２８０が，演算部２６０ａにより演算された各管理キャラクタのキャラクタ情報を，ゲームサーバ１００を介して他のゲーム機２００に送信する。このように最新のキャラクタの状態を他のゲーム機２００に送信することにより，通信時間だけ遅延が生じた状態ではあるが，他のゲーム機２００に記憶された各キャラクタのキャラクタ情報が更新される。これにより，データの整合性を保つことができる。
【０１２９】
（キャラクタ変更判定処理）
つぎに，ステップ９３０に示したキャラクタ変更判定処理について，図１０を参照しながら，詳細に説明する。
ステップ１０００からキャラクタ変更判定処理が開始され，ステップ１００５に進むと，演算部２６０ａは，管理キャラクタとして登録されているＮＰＣ（図７の該当ＮＰＣの座標）と最寄の敵ＰＣ（図７の該当敵ＰＣの座標）との距離ＤＥＰＣを求める。たとえば，図１１に示したように，自ＰＣ１の小隊が，敵ＰＣ３の小隊を攻撃するために，敵ＰＣ３の小隊に向かっている場合，ステップ１００５では，図１２に示したように，当該ＮＰＣ（ＮＰＣ１１）と敵ＰＣ３との距離ＤＥＰＣが演算される。
【０１３０】
つぎに，ステップ１０１０に進み，判定部２７５は，ＮＰＣ１１を管理するゲーム機２００（この時点では自ゲーム機）のＰＣ（すなわち，自ＰＣ１）が，ＮＰＣ１１の味方であるか否かを判定する。この時点では，自ＰＣ１は，ＮＰＣ１１の味方であるので，判定部２７５は，ステップ１０１５に進み，距離ＤＥＰＣがマージンＭＣ（＝５０）より小さいか否かを判定する。この時点では，ＰＣ３は，ＮＰＣ１１を中心とした半径がマージンＭＣの円内まで近づいていないので，距離ＤＥＰＣはマージンＭＣより大きい。そこで，ステップ１０２０に進んで，演算部２６０ａは，ＮＰＣ１１と自ＰＣ１との距離Ｄを求め，ステップ１０２５にて，ＮＰＣ１１と最寄の味方ＰＣ（＝ＰＣ２）との距離ＤＡＰＣを求める。
【０１３１】
つぎに，ステップ１０３０に進んで，判定部２７５は，距離ＤＡＰＣにマージンＭＤ（＝５０）を加算した値が距離Ｄより小さいか否かを判定する。この時点で，距離ＤＡＰＣ＋マージンＭＤの値は距離Ｄより大きい。すなわち，ＰＣ２は，ＮＰＣ１１を中心とした半径が（距離Ｄ−マージンＭＤ）の円内まで近づいていない。そこで，判定部２７５は，（ＮＰＣ１１の管理を他のユーザ機２００に変更することなく），ステップ１０３５に進み，管理中のすべてのＮＰＣ（すなわち，管理キャラクタ）についてキャラクタ変更判定処理を実行するまで，ステップ１００５に戻って各管理キャラクタの変更判定処理を続け，すべての管理キャラクタについて，この変更判定処理を終えると，ステップ１０９５にて本処理を終了する。
【０１３２】
つぎに，図１１に示したＰＣ２の小隊のみが，ＰＣ１の小隊に接近した場合のキャラクタ変更判定処理について説明する。このとき，図１３に示したように，味方ＰＣ２は自ＰＣ１よりマージンＭＤ以上ＮＰＣ１１の近くに位置しているので，判定部２７５は，ステップ１０００〜ステップ１０２５に続くステップ１０３０にて「ＹＥＳ」と判定し，ステップ１０４０に進んで，味方ＰＣ管理変更処理を実行する。
【０１３３】
（味方ＰＣ管理変更処理）
具体的には，図１４に示したように，判定部２７５は，ステップ１４００から味方ＰＣ管理変更処理を開始して，ステップ１４０５に進み，最寄の味方ＰＣ（＝ＰＣ２）と当該ＮＰＣ（＝ＮＰＣ１１）を管理しているゲーム機２００のＰＣ（＝ＰＣ１）とが，同一か否かを判定する。ここでは同一でないので，判定部２７５は，ステップ１４１０に進んで，最寄の味方ＰＣ（＝ＰＣ２）のゲーム機が管理している管理キャラクタ数が７９以上であるか否かを判定する。ＰＣ２を管理しているゲーム機が管理している管理キャラクタ数が７９より少ないと，記憶部２５５は，ステップ１４１５に進んで，ＲＡＭ２２０に記憶されているＰＣ２に関するキャラクタ情報のうち，管理中のキャラクタ数を１つ増やし，ステップ１４２０に進んで，現時点でＮＰＣ（＝ＮＰＣ１１）を管理しているゲーム機（ＣＬ）により管理されているＰＣ（＝ＰＣ１）の管理中のキャラクタ数を１つ減らす。
【０１３４】
ついで，ステップ１４２５に進んで，通信部２８０は，当該ＮＰＣ（＝ＮＰＣ１１）の管理を，ＰＣ１を管理するゲーム機２００からＰＣ２を管理するゲーム機２００に変更する情報を含んだ管理変更パケットを，ゲームサーバ１００を介して他のゲーム機２００に送信し，ステップ１４９５に進んで本処理を終了する。このように，味方ＰＣ２が自ＰＣ１よりマージンＭＤ以上ＮＰＣ１１の近くに位置している場合，敵ＰＣ２を管理するゲーム機が，ＮＰＣ１１（管理キャラクタ）を管理するように管理キャラクタが切り替わる。
【０１３５】
なお，ステップ１４０５にて，最寄の味方ＰＣと当該ＮＰＣを管理しているゲーム機２００のＰＣとが同一の場合には，管理キャラクタの管理変更を行う必要がなく，また，ステップ１４１０にて，最寄の味方ＰＣのゲーム機２００が管理している管理キャラクタ数が７９以上である場合には，そのゲーム機が管理する管理キャラクタをこれ以上増やすことが適当でないので，いずれも当該管理キャラクタを変更することなく，ステップ１４９５に進んで本処理を終了する。
【０１３６】
つぎに，図１１の状態から図１５の状態にゲームが展開した場合（すなわち，自ＰＣ１の小隊と敵ＰＣ３の小隊と味方ＰＣ２の小隊とが集団戦闘状態にある場合）のキャラクタ変更判定処理について説明する。この場合，図１６に示したように，ＮＰＣ１１には味方ＰＣ２が最も近接しているが，敵ＰＣ３もＮＰＣ１１を中心とした半径がマージンＭＣの円内に存在する。このとき，図１０のステップ１０００からキャラクタ変更判定処理を開始して，判定部２７５は，ステップ１００５，ステップ１０１０に続くステップ１０１５にて「ＹＥＳ」と判定し，ステップ１０４５に進んで，敵ＰＣ管理変更処理を実行する。
【０１３７】
（敵ＰＣ管理変更処理）
具体的には，図１７に示したように，判定部２７５は，ステップ１７００から敵ＰＣ管理変更処理を開始して，ステップ１７０５に進み，最寄の敵ＰＣ（＝ＰＣ３）と当該ＮＰＣ（＝ＮＰＣ１１）を管理しているゲーム機２００のＰＣ（＝ＰＣ１）とが，同一か否かを判定する。ここでは同一でないので，判定部２７５は，ステップ１７１０に進んで，最寄の敵ＰＣ（＝ＰＣ３）のゲーム機が管理している管理キャラクタ数が７９以上であるか否かを判定する。ＰＣ３を管理しているゲーム機が管理している管理キャラクタ数が７９より少ないと，ステップ１７１５に進んで，記憶部２５５は，ＲＡＭ２２０に記憶されているＰＣ３に関するキャラクタ情報のうち，管理中のキャラクタ数を１つ増やし，ステップ１７２０に進んで，現時点でＮＰＣ（＝ＮＰＣ１１）を管理しているゲーム機により管理されているＰＣ（＝ＰＣ１）の管理中のキャラクタ数を１つ減らす。
【０１３８】
ついで，ステップ１７２５に進んで，通信部２８０は，当該ＮＰＣ（＝ＮＰＣ１１）の管理を，ＰＣ１を管理するゲーム機２００からＰＣ３を管理するゲーム機２００に変更する情報を含んだ管理変更パケットを，ゲームサーバ１００を介して他のゲーム機２００に送信し，ステップ１７９５に進んで本処理を終了する。このように，ＮＰＣ１１に対して，味方ＰＣ２および敵ＰＣ３の両方が近接した場合，敵ＰＣ３を管理するゲーム機が，味方ＰＣ２を管理するゲーム機より優先してＮＰ１３１（管理キャラクタ）を管理するように管理キャラクタが切り替わる。
【０１３９】
なお，図１４の味方ＰＣ管理変更処理と同様に，ステップ１７０５またはステップ１７１０にて「ＹＥＳ」と判定された場合には，いずれも当該管理キャラクタを変更することなく，ステップ１７９５に進んで本処理を終了する。
【０１４０】
この時点では，図１５に示したように，ＮＰＣ１１の管理はＰＣ３に切り替わっている。同様にして，ＰＣ３を管理するゲーム機２００が，垂直帰線割込み毎に図１０に示したキャラクタ変更判定処理を実行することによりＮＰＣ３１の管理がＰＣ１に切り替わった（ＰＣ１を管理するゲーム機２００のＲＡＭ２２０にＮＰＣ３１が管理キャラクタとして登録された）後，ゲームが図１８に示した状態に展開した場合（すなわち，ＰＣ１がＰＣ３に接近した（図１５）後，ＰＣ３から少し遠ざかった（図１８）場合）について，つぎに説明する。
【０１４１】
この場合，ＮＰＣ３１，自ＰＣ１，味方ＰＣ２および敵ＰＣ３との関係は図１９に示したようになる。この状態で，図１０のキャラクタ変更判定処理が実行されると，ステップ１０００，１００５に続くステップ１０１０にて，判定部２７５は，ＮＰＣ３１は，ＮＰＣを管理するゲーム機が操作するＰＣ（＝ＰＣ１）の敵であると判定する。そこで，ステップ１０５０に進み，演算部２６０ａは，ＮＰＣ３１とＰＣ１との距離Ｄを求める。続いて，ステップ１０５５にて，判定部２７５は，距離ＤＥＰＣにマージンＭＡを加算した値が距離Ｄより小さいか否かを判定する。この時点では，距離ＤＥＰＣ＋マージンＭＡの値は距離Ｄより大きい。そこで，ステップ１０６０に進み，演算部２６０ａは，ＮＰＣ３１と最寄の味方ＰＣ（＝ＰＣ２）との距離ＤＡＰＣを求める。
【０１４２】
つぎに，ステップ１０６５に進んで，判定部２７５は，距離ＤＡＰＣにマージンＭＢを加算した値が距離Ｄより小さいか否かを判定する。この時点では，距離ＤＡＰＣ＋マージンＭＢの値は距離Ｄより大きい。そこで，ステップ１０３５に進み，ＲＡＭ２２０に登録されているすべての管理キャラクタの処理を終えるまでステップ１００５に戻って各管理キャラクタの変更判定処理を実行する。
【０１４３】
つぎに，図２０に示したように，ＮＰＣ３１に対して味方ＰＣ２および敵ＰＣ３が近接した場合であって，敵ＰＣ３は自ＰＣ１よりマージンＭＡ以上ＮＰＣ３１の近くに位置している場合について説明する。この状態で，図１０のキャラクタ変更判定処理が実行されると，ステップ１０００〜１０１０，ステップ１０５０に続くステップ１０５５にて，判定部２７５は，「ＹＥＳ」と判定し，ステップ１０７０に進んで，図１７の敵ＰＣ管理変更処理を実行する。すなわち，ステップ１７００〜１７２５を実行することにより，ＮＰＣ３１の管理が，ＰＣ１を管理するゲーム機２００からＰＣ３を管理するゲーム機２００に切り替わる。このように，ＮＰＣ３１に対して味方ＰＣ２および敵ＰＣ３の両方が近接した場合であって，敵ＰＣ３が自ＰＣ１よりマージンＭＡ以上ＮＰＣ３１の近くに位置している場合，敵ＰＣ３を管理するゲーム機が，味方ＰＣ２を管理するゲーム機より優先してＮＰＣ３１（管理キャラクタ）を管理するように管理キャラクタが切り替わる。
【０１４４】
一方，ゲームの状態が，図１９の状態から図２１の状態（すなわち，敵ＰＣ３が自ＰＣ１よりマージンＭＡ以上ＮＰＣ３１の近くに位置していない場合であって，かつ，味方ＰＣ２が自ＰＣ１よりマージンＭＢ以上ＮＰＣ３１の近くに位置している状態）に遷移した場合について説明する。この状態で，図１０のキャラクタ変更判定処理が実行されると，ステップ１０００〜１０１０，ステップ１０５０〜１０６０に続くステップ１０６５にて，判定部２７５は，「ＹＥＳ」と判定し，ステップ１０４０に進んで，図１４の味方ＰＣ管理変更処理を実行する。すなわち，ステップ１４００〜１４２５を実行することにより，ＮＰＣ３１の管理が，ＰＣ１を管理するゲーム機２００からＰＣ２を管理するゲーム機２００に切り替わる。
【０１４５】
（マージンの設定）
以上に説明した図１０のキャラクタ変更判定処理では，当該ＮＰＣの管理を切り替える対象となるＰＣ（敵ＰＣ，味方ＰＣ）毎に所定のマージン（マージンＭＡ，ＭＢ，ＭＣ，ＭＤ）を設けた。これは，他のゲーム機２００が管理するＰＣの位置が自ＰＣの管理キャラクタ（当該ＮＰＣ）に最も近い場合であっても，自己のゲーム機２００が管理するプレイヤキャラクタの位置より所定距離以上上記各管理キャラクタの近くに位置しない限り，判定部２７５は，自己のゲーム機２００がその管理キャラクタを管理すると判定するようにして，管理権を切り替える境界付近での管理権の切り替えが頻繁に発生しないように考慮したものである。特に，集団戦闘ゲームは，アクションゲームなので微妙な位置の変化が極めて頻繁に発生するため，管理権の切り替えが頻繁に発生しないように制御することは処理全体の負荷を軽減し，スムーズにゲームを進行させるために非常に重要である。
【０１４６】
また，マージンＭＡに比べて，マージンＭＢ，マージンＭＣ，マージンＭＤの値を大きくしたのは，マージンＭＡの場合は，ステップ１０５５にて，判定対象としている管理キャラクタ（当該ＮＰＣ）と敵ＰＣとの距離と，当該ＮＰＣと自ＰＣとの距離と，を比較処理しているので，マージンを比較的短く設定して，当該ＮＰＣの管理を優先的に敵ＰＣに与えるようにするためである。すなわち，判定部２７５は，優先的にステップ１０５５にて「ＹＥＳ」と判定し，ステップ１０７０にて敵ＰＣに当該ＮＰＣの管理を変更する処理を実行する。
【０１４７】
一方，マージンＭＢ，マージンＭＤの場合は，ステップ７１０６５およびステップ１０３０にて，それぞれ判定対象としている管理キャラクタ（当該ＮＰＣ）と味方ＰＣとの距離と，当該ＮＰＣと自ＰＣとの距離と，を比較処理しているので，マージンを比較的長く設定して，当該ＮＰＣの管理をなるべく味方ＰＣに与えないようにするためである。すなわち，判定部２７５は，優先的にはステップ１０３０およびステップ１０６５にて「ＹＥＳ」と判定せず，なるべく当該ＮＰＣの管理を味方ＰＣ変更しないように処理を実行する。
【０１４８】
また，マージンＭＣの場合は，他のゲーム機２００が管理するＰＣが，管理キャラクタ（当該ＮＰＣ）および自ゲーム機２００が管理する自ＰＣの敵であって，その他のゲーム機２００が管理する敵ＰＣが当該ＮＰＣの一定範囲内（＝マージンＭＣ）に位置する場合には，求められた位置の相対関係（すなわち，自ＰＣと当該ＮＰＣと敵ＰＣとの相対位置）にかかわらず，他のゲーム機２００が当該ＮＰＣを管理させるためである。すなわち，敵ＰＣが当該ＮＰＣの一定範囲内（＝マージンＭＣ）に位置する場合には，判定部２７５は，ステップ１０１５にて「ＹＥＳ」と判定してステップ１０４５にて優先的に敵ＰＣに当該ＮＰＣの管理を変更するように判定する。
【０１４９】
また，マージンＭＢの値をマージンＭＣの値より大きくしたのは，以下の理由による。前述したように，集団戦闘ゲームは，アクションゲームなので微妙な位置の変化が極めて頻繁に発生する。また，実際の処理では，キャラクタの位置は，小数点以下も含めた数値で演算されるので，画面上，全く移動せず待機しているように見えるキャラクタであっても，実は，常に僅かに移動していると判定される場合が非常に多い。より詳しく述べると，ある地点から仮想空間上にて５０ｍ離れた位置に立っているキャラクタは，処理上は，常に，４９．９ｍ〜５０．１ｍといった位置を揺れ動いている。プレイヤが，自ＰＣを操作すると，その幅はいっそう大きくなり，このような状況で，ある地点から５０ｍの位置で自ＰＣの小隊と敵ＰＣの小隊とが戦っていると，非常に多数のキャラクタが，極めて頻繁に５０ｍ前後の位置を揺れ動くことになる。
【０１５０】
このような状況で，たとえば，マージンＭＢとマージンＭＣとを同じ値（＝５０）に設定すると，に管理キャラクタの切り替えが多発してしまう。具体的には，当該ＮＰＣと自ＰＣとが味方であって，最寄の敵ＰＣと当該ＮＰＣとの距離ＤＥＰＣが４９であった場合，判定部２７５は，ステップ１００５，ステップ１０１０に続くステップ１０１５にて「ＹＥＳ」と判定してステップ１０４５にて敵ＰＣに当該ＮＰＣの管理を変更する。その後，敵ＰＣが当該ＮＰＣから少し離れ，距離ＤＥＰＣが５１になると，判定部２７５は，ステップ１００５，ステップ１０１０，ステップ１０５０〜ステップ１０６０に続くステップ１０６５にて「ＹＥＳ」と判定してステップ１０４０にて味方ＰＣに当該ＮＰＣの管理を変更する。その後，敵ＰＣが当該ＮＰＣに少し近づき，再び，最寄の敵ＰＣと当該ＮＰＣとの距離ＤＥＰＣが４９になった場合，判定部２７５は，ステップ１０１５にて再び「ＹＥＳ」と判定してステップ１０４５にて敵ＰＣに当該ＮＰＣの管理を変更する。このような頻繁なキャラクタ管理の切り替えを防止するために，マージンＭＢの値をマージンＭＣと異なる値に設定している（すなわち，マージンＭＢ＝６０，マージンＭＣ＝５０）。
【０１５１】
（ゲームサーバの動作）
つぎに，ゲームサーバ１００の動作について説明する。ゲームサーバ１００は，図２２のフローチャートを示したように，ステップ２２００から処理を開始して，ステップ２２０５にて，キャラクタ管理変更パケット，および／または，キャラクタ情報パケットを受信したか否かを判定する。これらのパケットを受信している場合，ゲームサーバ１００は，ステップ２２１０にて，各ゲーム機２００から送信されたキャラクタ管理変更パケット，および／または，キャラクタ情報パケットを送信元のゲーム機２００以外のすべてのゲーム機２００に送信し，ステップ２２９５に進んで本処理を終了する。なお，前述したように，ゲームサーバ１００の記憶部１５０には，各キャラクタのキャラクタ情報を記憶する必要はないが，記憶してもよい。
【０１５２】
以上，本実施形態に係るネットワークゲームシステムによれば，格闘ゲームにおいて即時性が要求される「アクション処理」をユーザ側の端末であるゲーム機（クライアント側）で行う。また，本システムでは，ノンプレイヤキャラクタは，いずれかのゲーム機２００により管理される。このため，ゲームサーバ１００に処理の負荷が集中せず，システム全体に処理を負荷分散することができる。このため，プレイヤは，通信遅延を感じることなく，リアルタイム性の高い迫力あるゲームを楽しむことができる。
【０１５３】
また，本システムでは，管理キャラクタであるＮＰＣの所定距離内に敵ＰＣが存在する乱戦時には，その敵ＰＣを管理するゲーム機が，優先してＮＰＣを管理するように制御され，それ以外の場合（敵ＰＣが所定距離外にいる場合，所定距離外に味方ＰＣがいる場合，または，所定距離内に何もいない場合）には，最短となる別なＰＣが現れたら，敵味方に関係なく，管理権がそのＰＣに変更される。
【０１５４】
このように，優先的に敵を管理する方がネットワークゲームにおいての通信遅延を感じる機会を少なくできる。つまり，本実施形態にかかるネットワークゲームシステム１０では，ＰＣ同士が近づいた乱戦時には，自ＰＣを管理するゲーム機は，まず，敵ＮＰＣを優先して管理する。このとき敵味方だけで判断できない場合（同一陣営のＰＣが近くに複数いる場合など）は距離によってＮＰＣをどのゲーム機に管理させるかを判断する。また，ＰＣ同士が離れた場合には，敵味方に関係なく距離だけでＮＰＣをどのゲーム機に管理させるかが判断される。
【０１５５】
原則的に，自ＰＣは，近傍の敵ＮＰＣと戦い，近傍の味方ＮＰＣとは戦わないので，自ＰＣを管理するゲーム機は，自ＰＣと近傍の敵ＮＰＣとの間で頻繁に演算処理が発生する。したがって，前述したキャラクタ管理方法によって，敵ＮＰＣを優先的に自ＰＣを管理するゲーム機２００に管理させることにより，頻繁に発生する演算処理を自ゲーム機内で処理することができる。同一ゲーム機内で管理されているキャラクタ同士はネットワーク通信を行わずに処理が行えるので，敵ＮＰＣを優先して管理することにより通信の遅延時間を少なくすることができる。この結果，各プレイヤの操作に応じて即座に画面上のキャラクタのモーションが変わり，プレイヤは，敵の護衛兵（ＮＰＣ）との戦闘は実質スタンドアローンのように早く感じるため，よりゲームに没頭して楽しむことができる。
【０１５６】
なお，クライアント処理（ゲーム機側の処理）では，ＲＡＭ等のメモリ内に保持するデータとして，各ゲーム機が管理するすべての自ＮＰＣ＋自ＰＣ（すなわち，自小隊）のキャラクタ情報ではなく，他のゲーム機が管理するキャラクタを含めた全キャラクタのキャラクタ情報を記憶した。この理由は，たとえば，他のゲーム機が管理するものも自己の画面に表示される可能性があり，少なくともそのキャラクタ情報のうちの最新座標データ等を記憶しておかなければデータの整合が取れないためである。ここで，全キャラクタの最新座標の記憶更新管理に関して，自己が管理する全自ＮＰＣ＋自ＰＣについては，各ゲーム機２００内でキー入力等に対する変化量から最新座標を直接計算して記憶更新した後に，ゲームサーバ１００経由で他のゲーム機２００に送信して整合を取るため，最新座標の更新処理が速くなると考えられるが，他のゲーム機２００が管理するものについては，他のゲーム機で算出した最新座標をゲームサーバ１００経由で受信した後に記憶更新されることにより整合をとるので，通信遅延が生じて遅くなると考えられる。
【０１５７】
しかしながら，本実施形態にかかる発明のポイントは，近接した敵ＮＰＣを含む自己が管理するＮＰＣへの処理を速くする点であるからこの遅れによる直接的な影響はなく，また全キャラクタの状態情報を各ゲーム機で記憶すること自体の見た目への影響はないものと考えられる。この理由は，通常このような集団戦闘ゲームでは自ＰＣを画面中央からやや下側に表示するので（このとき各ゲーム機での視界，即ち視点カメラの位置と角度は各自，自動的に適切な数値に設定される），経験則上，実際にプレイヤが注目する自小隊の戦闘場面での処理が速ければ，それ以外の他のゲーム機が管理している他小隊が表示される部分，即ち周囲の部分の表示が多少遅くても気にならないと考えられるからである。
【０１５８】
（第２実施形態）
つぎに，第２実施形態にかかるネットワークゲームシステム１０について説明する。第２実施形態にかかるネットワークゲームシステム１０は，キャラクタ変更判定処理をゲームサーバ１００側で実行する点で，キャラクタ変更判定処理をゲーム機２００側で実行する第１実施形態と動作上異なる。よって，この相違点を中心に本実施形態にかかるネットワークゲームシステムについて説明する。
【０１５９】
（ゲーム機の動作）
本実施形態では，図８のクライアント側管理処理のうち，ステップ８１５で呼び出されるキャラクタ管理処理を図２３のステップ２３００から開始し，ステップ９０５〜ステップ９２５の処理後，第１実施形態の場合に実行した図９のステップ９３０のキャラクタ変更判定処理を行うことなく，ステップ９３５を処理してステップ２３９５に進んで本処理を終了する。このように，本実施形態では，各ゲーム機２００は，アクション処理を実行するが，キャラクタ変更判定処理を実行しない。
【０１６０】
(ゲームサーバの動作)
一方，本実施形態では，ゲームサーバ１００は，図７に示した各キャラクタのキャラクタ情報をＲＡＭ１２０に予め記憶する。すなわち，ゲームサーバ１００にてキャラクタ管理変更判定をする場合，図７に示したキャラクタ情報は，ゲームサーバ１００および各ゲーム機器２００のＲＡＭにそれぞれ保持される。
【０１６１】
ゲームサーバ１００は，図２４にフローチャートを示したように，ステップ２４００から処理を開始して，ステップ２４０５にて，キャラクタ情報パケットを受信したか否かを判定する。これらのパケットを受信している場合，ゲームサーバ１００は，ステップ２４１０にて，各ゲーム機２００から送信されたキャラクタ情報パケットに含まれるキャラクタ情報にて，図７に示したように，ＲＡＭ１２０に記憶されたキャラクタのうち，該当するキャラクタのキャラクタ情報を更新し，そのキャラクタ情報パケットを送信元のゲーム機２００以外のすべてのゲーム機２００に送信した後，ステップ２４１５に進んで，図１０のキャラクタ変更判定処理を実行し，ステップ２４９５に進んで本処理を終了する。なお，第１実施形態では，すべてのノンプレイヤキャラクタ（ＮＰＣ）のうち，各ゲーム機２００が管理する管理キャラクタ毎に，図１０のキャラクタ変更判定処理を繰り返していた。しかし，本実施形態では，すべてのノンプレイヤキャラクタ（ＮＰＣ）について，キャラクタ変更判定処理を繰り返す必要がある。
【０１６２】
本実施形態にかかるネットワークゲームシステム１０によれば，ゲームサーバ１００側で，すべてのキャラクタが管理される。これによれば，ゲームサーバ１００から各ゲーム機２００までの距離や各ゲーム機２００の性能その他の通信環境が同一の場合で且つ通信障害が発生しない場合，各ゲーム機２００で生じる処理の遅延は，理論上ほぼ同時と考えられる。このため，画面上の多数のキャラクタが不自然に動作することがない。また，すべてのキャラクタ管理をゲームサーバ１００側で行うため，正確かつ簡易にデータの整合性を保つことができる。
【０１６３】
さらに，上記の様に通信環境が同一の場合，本実施形態にかかるキャラクタ管理の切り替えのための遅延時間は，ゲームサーバ１００からゲーム機２００の通信時間のみであるため，本実施形態のシステムでは，ゲーム機２００側でキャラクタ管理処理を実行する第１実施形態の場合と比べ，第１実施形態の他のゲーム機２００に生じる切り替え時間の半分しか遅延しないという利点がある。
【０１６４】
以上に説明したように，上記各実施形態にかかるネットワークゲームシステム１０によれば，「キャラクタ毎に管理するゲーム機を決めて，アクション処理を各ゲーム機２００に振り分ける」，「他のゲーム機にて管理されている管理キャラクタの映像が少し遅れて自ゲーム機に表示される」，「他のゲーム機にて管理されている管理キャラクタの映像から自ゲーム機にて管理されている管理キャラクタが影響を及ぼされる」という巧妙な制御により，自ゲーム機２００が管理するキャラクタ同士のアクションの結果が即座に画面上に反映されるという状況を作り出すことができる。これは，非常に多数のキャラクタが複数の小隊を作って集団戦闘するネットワークゲームに特に有効である。
【０１６５】
なお，上記各実施形態において，最寄のＰＣは，総当りで距離を比較することにより算出される。
【０１６６】
また，以上のキャラクタ変更管理処理では，管理キャラクタ（ＮＰＣ）を中心として各ＰＣとの相対距離関係を算出し，算出した関係に基づきキャラクタの管理を変更するか否かが判定されていた。しかし，各実施形態にかかるキャラクタ変更管理処理は，各ＰＣを中心としてある所定範囲内に存在するＮＰＣを管理キャラクタとして管理するようにしてもよい。
【０１６７】
（ＰＣを中心としたキャラクタ管理）
実際には，たとえば，各ゲーム機２００の判定部２７５は，演算部２６０ａにより演算された各管理キャラクタの位置の変化に基づいて，自ゲーム機２００により管理されるプレイヤキャラクタ（自ＰＣ）から第１の所定範囲内に位置する１または２以上のノンプレイヤキャラクタ（ＮＰＣ）を，自ゲーム機２００が管理キャラクタとして管理すると判定してもよい。
【０１６８】
このようにＰＣを中心としたキャラクタ管理処理を実行する場合，判定部２７５は，他のゲーム機２００により管理されるプレイヤキャラクタ（他ＰＣ）とノンプレイヤキャラクタ（ＮＰＣ）との関係が敵味方であって，自ゲーム機２００により管理されるＰＣ（自ＰＣ）と当該ＮＰＣとの関係が味方同士の場合には，ノンプレイヤキャラクタ（ＮＰＣ）が自ゲーム機２００により管理されるＰＣから上記第１の所定範囲内に位置していても，上記敵のＰＣから第２の所定範囲内に位置するときには，上記他のゲーム機２００が当該ＮＰＣを管理すると判定するようにしてもよい。また，上記第１の所定範囲は，上記第２の所定範囲より小さくなるように設定してもよい。
【０１６９】
また，ＰＣから所定範囲内に予め定められた所定数以上のＮＰＣが存在するとき，当該所定数のＮＰＣの管理を切り替えるようにしてもよい。また，ＰＣから所定範囲内に所定数以上のＮＰＣが存在してから，所定時間経過後にＮＰＣの管理を切り替えるようにしてもよい。
【０１７０】
これによれば，ＮＰＣと敵ＰＣと自ＰＣとが近傍に位置する戦闘体制において，ＮＰＣを優先的に敵ＰＣを管理するゲーム機２００に管理させることができ，この結果，ゲーム全体の処理をスムーズに進行させることができる。
【０１７１】
（第３実施形態）
つぎに，第３実施形態にかかるネットワークゲームシステム１０について説明する。第３実施形態にかかるネットワークゲームシステム１０では，第１実施形態にて説明したように，原則として，自小隊に属する自ＰＣおよびＮＰＣは，自己のゲーム機２００に管理され，味方ＰＣの他小隊に属する味方ＰＣおよびＮＰＣは，味方ＰＣを操作するゲーム機２００に管理され，敵ＰＣの他小隊に属する敵ＰＣおよびＮＰＣは，敵ＰＣを操作するゲーム機２００に管理される点において第１実施形態と同様である。
【０１７２】
しかし，本実施形態では，たとえば，ゲームに参加するプレイヤが足りない場合であっても（たとえば，ゲームに参加するプレイヤが一人だとしても），ゲームに参加するプレイヤに対しては上記管理の原則が適用され，参加者の不足によりユーザによって操作されることがない１または２以上のＰＣおよびそのＰＣの小隊に属するＮＰＣは，ゲームサーバ１００により自動的に管理される点において第１実施形態と動作上異なる。よって，この相違点を中心に本実施形態にかかるネットワークゲームシステム１０について説明する。
【０１７３】
なお，以下の説明では，ゲームサーバ１００（ＳＶ）により管理されるプレイヤキャラクタ（ＰＣ）をサーバキャラクタ（ＳＣ）とも称呼する。また，ゲームサーバ１００により管理されるサーバキャラクタが複数存在する場合，ゲーム機２００により管理されるプレイヤキャラクタまたはゲームサーバ１００により管理される他のサーバキャラクタ（キャラクタ変更判定の対象となっているＮＰＣを管理するゲームサーバ１００のサーバキャラクタ以外のサーバキャラクタ）をメインキャラクタ（ＭＣ）とも称呼する。さらに，メインキャラクタを管理するゲーム機２００またはゲームサーバ１００をＭＣ管理機器とも称呼する。
【０１７４】
（ゲームサーバ１００の機能構成）
本実施形態にかかるゲームサーバ１００は，図２５に示したように，第１実施形態にかかるゲームサーバ１００の機能構成に加え，演算部１７０ａおよび判定部１７５の機能ブロックにより示された新たな機能が加えられている。また，演算部１７０ａと画像処理部１７０ｂとによりアクション処理実行部１７０の機能が実現される。
【０１７５】
新たに加えられた機能のうち，アクション処理実行部１７０は，記憶部１５０に登録され，ゲームサーバ１００により管理される各管理キャラクタのアクション処理を管理キャラクタ毎に実行する。具体的には，演算部１７０ａは，記憶部１５０に記憶されたキャラクタ情報を用いて，ゲーム上の戦闘によって発生する各管理キャラクタの位置の変化および動作の変化を表す変化量をそれぞれ演算することにより変化後のキャラクタ情報を生成する。
【０１７６】
また，判定部１７５は，演算部１７０ａにより演算された各管理キャラクタの位置の変化値に基づいて，ゲームサーバ１００が管理するいずれかのサーバキャラクタの位置（ＳＣの位置）と，ＭＣ管理機器により管理されるメインキャラクタの位置（ＭＣの位置）と，各管理キャラクタのアクション処理後の位置（演算後のＮＰＣの位置）と，の相対関係を求め，求められた位置の相対関係に基づき各管理キャラクタを管理するか否かを判定する。ゲームサーバ１００が管理する「いずれかの」プレイヤキャラクタの位置としたのは，ゲームに参加するユーザが少ない場合，ゲーム機２００に割り当てられなかった複数のプレイヤキャラクタを複数のサーバキャラクタとしてゲームサーバ１００にてそれぞれ管理する必要があるためである。
【０１７７】
（ゲームサーバ１００の動作）
本実施形態においても，原則的に，各プレイヤキャラクタおよび各ゲーム機２００により管理すると判定されたノンプレイヤキャラクタは，各ゲーム機２００により管理される。具体的には，これらのキャラクタは，各ゲーム機２００が図８のクライアント側管理処理を実行することにより管理される。
【０１７８】
これに加えて，本実施形態では，ゲーム参加者が不足しているので，ゲームサーバ１００にて自動的に管理することとなった１または複数のサーバキャラクタが存在する。この１または複数のサーバキャラクタおよびゲームサーバ１００によりサーバキャラクタ毎に管理すると判定されたノンプレイヤキャラクタは，ゲームサーバ１００により管理される。具体的には，これらのキャラクタは，図８に代わる図２６に示したように，ゲームサーバ１００がサーバ側管理処理を実行することにより管理される。
【０１７９】
なお，ゲームサーバ１００の動作には，原則的に，以下に説明する動作以外にも，第１実施形態または第２実施形態にて説明した動作が含まれる。また，言うまでも無いが，ＳＣ及びそのＳＣの小隊中のＮＰＣの位置変化に関するキャラクタ管理変更パケット及びキャラクタ情報パケットのサーバ間での送受信は行わず（サちなみに，ゲームサーバ１００とゲーム機２００との間は通常通り送受信を行う），この場合にはゲームサーバ１００内部のＲＡＭ１２０に記憶されたキャラクタ情報（図７）を直接更新する。
【０１８０】
また，本実施形態では，ユーザが割り当てられなかったプレイヤキャラクタに対してのみ，ゲームの進行に応じてゲームサーバ１００が「自動的に」その動作を管理する。したがって，ゲームサーバ１００は，サーバ管理者によるアクション処理のためのモニタ４１５の表示も，キーボード４０５などの入力装置による入力情報の入力も不要である。また，本実施形態では，第１実施形態にて図８のステップ８２５で行われていたような，ＲＡＭ１２０の更新処理や音響等に関する処理も不要となる。以上を踏まえて，本実施形態におけるゲームサーバ１００の動作について説明する。
【０１８１】
（ゲームスタート）
ゲーム機２００の電源が「ＯＮ」され，あるプレイヤからゲームの開始が要求されると，ゲームサーバ１００は，図２６のステップ２６００からサーバ側管理処理を開始し，ステップ８０５にて初期設定を行う。
【０１８２】
つぎに，ステップ８１０にて，判定部１７５は，割込み（垂直帰線割込（Ｖｓｙｎｃ））が発生したか否かを判定する。判定部１７５は，モニタ４１５の垂直帰線周期と一致した１／６０秒に一度の周期で割込みが発生すると，これに応じて，ステップ８１０にて「ＹＥＳ」と判定し，ステップ８１５に進んでキャラクタ管理処理（キャラクタ管理処理の詳細は後述）を実行する。
【０１８３】
つぎに，判定部１７５は，ステップ８２０に進んでゲームが終了か否かを判定する。具体的には，プレイヤが，ゲーム機２００の電源を「ＯＦＦ」するか，または，画面上のゲーム終了を選択することによりゲームは終了する。そこで，プレイヤがこれらのいずれかの操作をするまで，ゲームサーバ１００は，基本的に，ステップ８１０〜ステップ８２０の処理を繰り返し，プレイヤがこれらのいずれかの操作をするとステップ２６９５に進んでゲームを終了する。
【０１８４】
ステップ８１０で割込みが発生していない場合，判定部１７５は，ステップ８１０にて「ＮＯ」と判定してステップ８２５でメイン処理を実行し，その後ステップ８２０に進む。このメイン処理においては，本実施形態におけるネットワークゲームと直接関係しないその他の処理が実行される。
【０１８５】
（キャラクタ管理処理）
つぎに，ステップ８１５のキャラクタ管理処理について，図２７のフローチャートを参照しながら説明する。ステップ２７００から処理が開始されると，通信部１４５は，ステップ９０５にて，他のゲーム機２００から送信されたキャラクタ管理変更パケットを受信したか否かを判定する。
【０１８６】
キャラクタ管理変更パケットを受信した場合には，ステップ２７０５に進んで，記憶部１５０は，キャラクタ管理変更パケットに含まれるキャラクタ情報に基づきＲＡＭ１２０の該当キャラクタ情報を更新する。具体的には，図７に示されたように，該当ＰＣまたは該当ＮＰＣに記憶された座標，体の向き，モーション番号，再生フレーム位置，進行方向，所属軍の情報を更新する。また，記憶部１５０は，このキャラクタ情報により特定されるキャラクタを管理キャラクタとしてＲＡＭ１２０に登録する。具体的には，図７に示されたように，該当キャラクタ情報の管理元のＰＣ番号を変更することにより，各管理キャラクタの管理をクライアント側（ゲーム機器２００）またはサーバ側（ゲームサーバ１００）のいずれかに変更する。また，通信部１４５は，同ステップ２７０５にて，受信したキャラクタ管理変更パケットをゲームに参加しているゲーム機２００に転送する。
【０１８７】
つぎに，ステップ９１５に進み，通信部１４５は，参加しているゲーム機２００からキャラクタ情報パケットを受信したか否かを判定する。キャラクタ情報パケットを受信した場合には，ステップ２７１０に進んで，記憶部１５０は，キャラクタ情報パケットに含まれるキャラクタ情報に基づきＲＡＭ１２０の該当キャラクタ情報を更新する。具体的には，図７の該当ＰＣまたは該当ＮＰＣに記憶された座標，体の向き，モーション番号，再生フレーム位置，進行方向，所属軍の情報を更新する。また，通信部１４５は，同ステップ２７１０にて，受信したキャラクタ情報パケットをゲームに参加しているゲーム機２００に転送する。
【０１８８】
ついで，ステップ９２５に進んで，アクション処理実行部１７０は，アクション処理を実行する。アクション処理とは，具体的には，アクション処理実行部１７０の各部により実行されるつぎの処理をいう。まず，演算部１７０ａは，ＲＡＭ１２０に記憶されたキャラクタ情報に基づき，各管理キャラクタの位置の変化量および動作の変化量を含んだキャラクタ情報を自動演算する。
【０１８９】
つぎに，ステップ９３０に進み，判定部１７５は，キャラクタ変更判定処理（サブルーチン）を実行する。この処理は，各管理キャラクタ（ＮＰＣ）の演算後の位置と，サーバキャラクタ（ＳＣ）の位置と，メインキャラクタ（ＭＣ）の位置と，の関係から当該管理キャラクタが管理されるべきＭＣ管理機器（ゲームサーバ１００またはゲーム機２００）を判定する。
【０１９０】
ついで，ステップ９３５に進み，通信部１４５が，演算部１７０ａにより演算された各管理キャラクタのキャラクタ情報をゲームに参加しているゲーム機２００に送信する。このように最新のキャラクタの状態をゲームに参加しているゲーム機２００に送信することにより，ゲームに参加しているゲーム機２００に記憶された各キャラクタのキャラクタ情報が更新される。これにより，データの整合性を保つことができる。
【０１９１】
（キャラクタ変更判定処理）
つぎに，ステップ９３０に示したキャラクタ変更判定処理について，図２８を参照しながら，詳細に説明する。
ステップ２８００からキャラクタ変更判定処理が開始され，ステップ２８０５に進むと，演算部１７０ａは，管理キャラクタとして記憶部１５０に登録されているＮＰＣと最寄の敵メインキャラクタ（敵ＭＣ）（すなわち，最寄の敵ＰＣまたは最寄の他のＳＣ）との距離ＤＥＰＣを求める。ここで，他のＳＣとは，キャラクタ変更判定の対象となっているＮＰＣを管理するゲームサーバ１００のサーバキャラクタ（ＳＣ）以外のＳＣをいう。
【０１９２】
つぎに，ステップ２８１０に進み，判定部１７５は，キャラクタ変更判定の対象となっているＮＰＣを管理するゲームサーバ１００（ＳＶ）のサーバキャラクタ（ＳＣ）が，ＮＰＣの味方であるか否かを判定する。サーバキャラクタが，ＮＰＣの味方である場合，判定部１７５は，ステップ２８１５に進み，距離ＤＥＰＣがマージンＭＣより小さいか否かを判定する。距離ＤＥＰＣがマージンＭＣより大きい場合，ステップ２８２０に進んで，演算部１７０ａは，ＮＰＣとサーバキャラクタとの距離Ｄを求め，ステップ２８２５にて，ＮＰＣと，最寄の味方メインキャラクタとの距離ＤＡＰＣを求める。
【０１９３】
つぎに，ステップ２８３０に進んで，判定部１７５は，距離ＤＡＰＣにマージンＭＤを加算した値が距離Ｄより小さいか否かを判定する。この時点で，距離ＤＡＰＣ＋マージンＭＤの値が距離Ｄより大きい場合，すなわち，最寄の味方メインキャラクタが，ＮＰＣを中心とした半径が（距離Ｄ−マージンＭＤ）の円内まで近づいていない場合には，判定部１７５は，ＮＰＣの管理をいずれかの機器に変更することなく，ステップ２８３５に進み，管理中のすべてのＮＰＣ（すなわち，管理キャラクタ）についてキャラクタ変更判定処理を実行するまで，ステップ２８０５に戻って各管理キャラクタの変更判定処理を続け，すべての管理キャラクタについて，この変更判定処理を終えるとステップ２８９５にて本処理を終了する。
【０１９４】
つぎに，味方メインキャラクタがＳＣよりマージンＭＤ以上ＮＰＣの近くに位置している場合について説明する。判定部１７５は，ステップ２８００〜ステップ２８２５に続くステップ２８３０にて「ＹＥＳ」と判定し，ステップ２８４０に進んで，味方ＭＣ管理変更処理を実行する。
【０１９５】
（味方ＭＣ管理変更処理）
具体的には，図２９に示したように，判定部１７５は，ステップ２９００から味方ＭＣ管理変更処理を開始して，ステップ２９０５に進み，最寄の味方ＭＣと当該ＮＰＣを管理しているゲームサーバ１００（ＳＶ）のＳＣとが同一か否かを判定する。同一でない場合，判定部１７５は，ステップ２９１０に進んで，最寄の味方ＭＣのＭＣ管理機器（ＣＬまたはＳＶ）が管理している管理キャラクタ数が７９以上であるか否かを判定する。最寄の味方ＭＣのＭＣ管理機器が管理している管理キャラクタ数が７９より少ないと，ステップ２９１５に進んで，記憶部１５０は，ＲＡＭ１２０に記憶されている最寄の味方ＭＣのキャラクタ情報のうち，ＭＣ管理機器が管理している管理キャラクタ数を１つ増やし，ステップ２９２０に進んで，現時点でＮＰＣを管理しているゲームサーバ１００により管理されている管理キャラクタ数を１つ減らす。
【０１９６】
ついで，ステップ２９２５に進んで，通信部１４５は，当該ＮＰＣの管理を，ＳＣを管理するゲームサーバ１００から味方ＭＣを管理するＭＣ管理機器に変更する情報を含んだ管理変更パケットを，ゲームに参加しているゲーム機２００に送信し，ステップ２９９５に進んで本処理を終了する。このように，味方ＭＣがＳＣよりマージンＭＤ以上ＮＰＣの近くに位置している場合，味方ＭＣを管理するＭＣ管理機器がＮＰＣ（管理キャラクタ）を管理するように，管理キャラクタが切り替わる。
【０１９７】
なお，ステップ２９０５にて，最寄の味方ＭＣと当該ＮＰＣを管理しているゲームサーバ１００のＳＣとが同一の場合には，管理キャラクタの管理変更を行う必要がなく，また，ステップ２９１０にて，最寄の味方ＭＣのＭＣ管理機器が管理している管理キャラクタ数が７９以上である場合には，そのゲーム機が管理する管理キャラクタをこれ以上増やすことが適当でないので，いずれも当該管理キャラクタを変更することなく，ステップ２９９５に進んで本処理を終了する。
【０１９８】
つぎに，ＳＣの小隊と敵ＭＣの小隊と味方ＭＣの小隊とが集団戦闘状態にある場合のキャラクタ変更判定処理について説明する。具体的には，ＮＰＣには味方ＭＣが最も近接しているが，敵ＭＣもＮＰＣを中心とした半径がマージンＭＣの円内に存在する場合，図２８のステップ２８００からキャラクタ変更判定処理を開始して，判定部１７５は，ステップ２８０５，ステップ２８１０に続くステップ２８１５にて「ＹＥＳ」と判定し，ステップ２８４５に進んで，敵ＭＣ管理変更処理を実行する。
【０１９９】
（敵ＭＣ管理変更処理）
具体的には，図３０に示したように，判定部１７５は，ステップ３０００から敵ＭＣ管理変更処理を開始して，ステップ３００５に進み，最寄の敵ＭＣと当該ＮＰＣを管理しているゲームサーバ１００のＳＣとが同一か否かを判定する。ここでは同一でないので，判定部１７５は，ステップ３０１０に進んで，最寄の敵ＭＣのＭＣ管理機器が管理している管理キャラクタ数が７９以上であるか否かを判定する。最寄の敵ＭＣを管理しているＭＣ管理機器の管理キャラクタ数が７９より少ないと，ステップ３０１５に進んで，記憶部１５０は，ＲＡＭ１２０に記憶されている，これからＮＰＣを管理するＭＣ等に関するキャラクタ情報のうち，ＭＣ管理機器が管理している管理キャラクタ数を１つ増やし，ステップ３０２０に進んで，現時点でＮＰＣを管理しているゲームサーバ１００により管理されている管理キャラクタ数を１つ減らす。
【０２００】
ついで，ステップ３０２５に進んで，通信部１４５は，当該ＮＰＣの管理を，ＳＣを管理するゲームサーバ１００から敵ＭＣを管理するＭＣ管理機器に変更する情報を含んだ管理変更パケットを，ゲームに参加しているゲーム機２００に送信し，ステップ３０９５に進んで本処理を終了する。このように，ＮＰＣに対して，味方ＭＣおよび敵ＭＣの両方が近接した場合，敵ＭＣを管理するゲーム機が，味方ＭＣを管理するゲーム機より優先してＮＰＣ（管理キャラクタ）を管理するように管理キャラクタが切り替わる。
【０２０１】
なお，図２９の味方ＰＣ管理変更処理と同様に，ステップ３００５またはステップ３０１０にて「ＹＥＳ」と判定された場合には，いずれも当該管理キャラクタを変更することなく，ステップ３０９５に進んで本処理を終了する。
【０２０２】
つぎに，ＮＰＣ（ＮＰＣ３１），ＰＣ１に代わるＳＣ，味方ＰＣ２に代わる味方ＭＣおよび敵ＰＣ３に代わる敵ＭＣとの関係が図１９に示した状況にある場合の処理について説明する。この状態で，図２８のキャラクタ変更判定処理が実行されると，ステップ２８００，２８０５に続くステップ２８１０にて，判定部１７５は，ＮＰＣは，ＮＰＣを管理するゲームサーバ１００が操作するＳＣの敵であると判定する。そこで，ステップ２８５０に進み，演算部１７０ａは，ＮＰＣとＳＣとの距離Ｄを求める。続いて，ステップ２８５５にて，判定部１７５は，距離ＤＥＰＣにマージンＭＡを加算した値が距離Ｄより小さいか否かを判定する。この時点では，距離ＤＥＰＣ＋マージンＭＡの値は距離Ｄより大きい。そこで，ステップ２８６０に進み，演算部１７０ａは，ＮＰＣと最寄の味方ＭＣとの距離ＤＡＰＣを求める。
【０２０３】
つぎに，ステップ２８６５に進んで，判定部１７５は，距離ＤＡＰＣにマージンＭＢを加算した値が距離Ｄより小さいか否かを判定する。この時点では，距離ＤＡＰＣ＋マージンＭＢの値は距離Ｄより大きい。そこで，ステップ２８３５に進み，ＲＡＭ１２０に登録されているすべての管理キャラクタの処理を終えるまでステップ２８０５に戻って各管理キャラクタの変更判定処理を実行する。
【０２０４】
つぎに，図２０に示したように，ＮＰＣ（ＮＰＣ３１）に対して味方ＰＣ２に代わる味方ＭＣおよび敵ＰＣ３に代わる敵ＭＣが近接した場合であって，敵ＭＣは自ＰＣ１に代わるＳＣよりマージンＭＡ以上ＮＰＣの近くに位置している場合について説明する。この状態で，図２８のキャラクタ変更判定処理が実行されると，ステップ２８００〜２８１０，ステップ２８５０に続くステップ２８５５にて，判定部１７５は，「ＹＥＳ」と判定し，ステップ２８７０に進んで，図３０の敵ＭＣ管理変更処理を実行する。すなわち，ステップ３０００〜３０２５を実行することにより，ＮＰＣの管理が，ＳＣを管理するゲームサーバ１００から敵ＭＣを管理するＭＣ管理機器に切り替わる。このように，ＮＰＣに対して味方ＭＣおよび敵ＭＣの両方が近接した場合であって，敵ＭＣがＳＣよりマージンＭＡ以上ＮＰＣの近くに位置している場合，敵ＭＣを管理するゲーム機が，味方ＭＣを管理するゲーム機より優先してＮＰＣ（管理キャラクタ）を管理するように管理キャラクタが切り替わる。
【０２０５】
一方，ゲームの状態が，図１９の状態から図２１の状態（すなわち，敵ＰＣ３に代わる敵ＭＣが自ＰＣ１に代わるＳＣよりマージンＭＡ以上ＮＰＣ（ＮＰＣ３１）の近くに位置していない場合であって，かつ，味方ＰＣ２に代わる味方ＭＣが自ＰＣ１に代わるＳＣよりマージンＭＢ以上ＮＰＣの近くに位置している状態）に遷移した場合について説明する。この状態で，図２８のキャラクタ変更判定処理が実行されると，ステップ２８００〜２８１０，ステップ２８５０〜２８６０に続くステップ２８６５にて，判定部１７５は，「ＹＥＳ」と判定し，ステップ２８４０に進んで，図２９の味方ＭＣ管理変更処理を実行する。すなわち，ステップ２９００〜２９２５を実行することにより，ＮＰＣの管理が，ＳＣを管理するゲームサーバ１００から味方ＭＣを管理するＭＣ管理機器に切り替わる。
【０２０６】
以上に説明したように，本実施形態によれば，ゲームに参加するプレイヤが足りない場合であっても（たとえば，ゲームに参加するユーザが一人だとしても），ゲームに参加するプレイヤのＰＣに対しては第１実施形態の原則（ＮＰＣをクライアント側で管理）が適用され，プレイヤがいない１または２以上のＳＣおよびそのＳＣの小隊中のＮＰＣは基本的にゲームサーバ１００により自動的に管理される。これにより，参加者が足りなくても，ユーザは，ゲームを思う存分楽しむことができる。また，クライアント機器により管理されるキャラクタとサーバ機器により管理されるキャラクタとを分けることによって，システム全体の処理を分散し，これにより，ゲームをスムーズに進行させることができる。
【０２０７】
（ＳＣを中心としたキャラクタ管理）
なお，本実施形態においても，たとえば，判定部１７５は，演算部１７０ａにより演算された各管理キャラクタの位置の変化に基づいて，ゲームサーバ１００により管理されるＳＣから第１の所定範囲内に位置する１または２以上のノンプレイヤキャラクタ（ＮＰＣ）を，ゲームサーバ１００が管理キャラクタとして管理すると判定してもよい。
【０２０８】
このようにＳＣを中心としたキャラクタ管理処理を実行する場合，判定部１７５は，ＭＣ管理機器により管理されるＭＣとＮＰＣとの関係が敵味方であって，ゲームサーバ１００により管理されるＳＣと当該ＮＰＣとの関係が味方同士の場合には，ＮＰＣがゲームサーバ１００により管理されるＳＣから第１の所定範囲内に位置していても，ＭＣから第２の所定範囲内（たとえば，第１の所定範囲＜第２の所定範囲）に位置するときには，ＭＣを管理するＭＣ管理機器が当該ＮＰＣを管理すると判定するようにしてもよい。
【０２０９】
また，ＳＣから所定範囲内に予め定められた所定数以上のＮＰＣが存在するとき，当該所定数のＮＰＣの管理を切り替えるようにしてもよい。また，ＳＣから所定範囲内に所定数以上のＮＰＣが存在してから，所定時間経過後にＮＰＣの管理を切り替えるようにしてもよい。
【０２１０】
これによれば，ＮＰＣとＭＣとＳＣとが近傍に位置する戦闘体制において，ＮＰＣを優先的にＭＣを管理するＭＣ管理機器に管理させることができ，この結果，ゲーム全体の処理をスムーズに進行させることができる。
【０２１１】
また，ゲームサーバ１００（ＳＶ）が管理する各ＮＰＣについて，最寄のＳＣと最寄のＭＣとの位置関係からＮＰＣの管理を変更してもよい。たとえば，ゲームサーバ１００が管理するＮＰＣとＭＣとの距離が，ゲームサーバ１００が管理するＮＰＣとＳＣとの距離より短くなった場合にＮＰＣの管理を変更するようにしてもよい。
【０２１２】
また，ネットワークゲームシステム１０では，敵味方同士のプレイヤキャラクタにゲームサーバ１００にて管理されるサーバキャラクタやノンプレイヤキャラクタが付随するようなキャラクタ構成にしてもよく，敵がすべてゲームサーバ１００にて管理されるサーバキャラクタであり，味方がすべてゲーム機器２００にて管理されるプレイヤキャラクタであるキャラクタ構成にしてもよい。
【０２１３】
また，プレイヤが不足していなくても，ゲームサーバ１００が自動操作するサーバキャラクタおよび管理キャラクタ（ノンプレイヤキャラクタ）をゲーム上に登場させてもよい。また，ゲームサーバ１００が自動操作する複数のサーバキャラクタが敵味方同士であってもよい。
【０２１４】
上記実施形態において，各部の動作はお互いに関連しており，互いの関連を考慮しながら，一連の動作として置き換えることができる。そして，このように置き換えることにより，キャラクタを管理するクライアント機器の発明の実施形態をクライアント機器のキャラクタ管理方法の実施形態とすることができる。
【０２１５】
したがって，本発明にかかるクライアント機器は，ネットワークを介してサーバ機器に接続された複数のクライアント機器を，ユーザが操作することにより，入力された情報に応じて動作する複数のプレイヤキャラクタと，自動的に動作する複数のノンプレイヤキャラクタと，を含んだ複数のキャラクタが登場するネットワークゲームにおける各クライアント機器のキャラクタ管理方法であって，各クライアント機器は，上記複数のキャラクタの位置情報を含んだキャラクタ情報を各クライアント機器の記憶部に各々記憶し，上記ノンプレイヤキャラクタのうち自己のクライアント機器が管理するノンプレイヤキャラクタを管理キャラクタとして各クライアント機器の記憶部に各々登録し，上記各クライアント機器の記憶部に記憶されたキャラクタ情報を用いて，上記ゲームの展開に応じた上記各管理キャラクタの位置の変化の程度および動作の変化の程度を変化後のキャラクタ情報として上記管理キャラクタ毎に演算することを特徴とする各クライアント機器のキャラクタ管理方法とすることができる。
【０２１６】
また，上記各クライアント機器の上記キャラクタ管理方法では，各クライアント機器は，上記演算された各管理キャラクタの位置の変化に基づいて，上記各管理キャラクタの演算後の位置と自己のクライアント機器が管理するプレイヤキャラクタの位置と他のクライアント機器が管理するプレイヤキャラクタの位置との相対関係を求め，求められた位置の相対関係に基づき各管理キャラクタを管理するクライアント機器を判定し，上記他のクライアント機器により管理されると判定された管理キャラクタの登録を上記自己のクライアント機器の記憶部から削除し，上記他のクライアント機器により管理されると判定された管理キャラクタのキャラクタ情報を含んだキャラクタ管理変更パケットをサーバ機器に送信することができる。
【０２１７】
また，上記各部の動作を，各部の処理と置き換えることにより，プログラムの実施形態とすることができる。また，プログラムを，プログラムを記録したコンピュータ読み取り可能な記録媒体に記憶させることにより，プログラムの実施形態をプログラムに記録したコンピュータ読み取り可能な記録媒体の実施形態とすることができる。
【０２１８】
以上，添付図面を参照しながら本発明の好適な実施形態について説明したが，本発明は係る例に限定されないことは言うまでもない。当業者であれば，特許請求の範囲に記載された範疇内において，各種の変更例または修正例に想到し得ることは明らかであり，それらについても当然に本発明の技術的範囲に属するものと了解される。
【０２１９】
たとえば，上記各実施形態にかかる集団戦闘ゲームは，ネットワークゲームシステムの一例であり，ネットワークゲームの他の例としては，自分のプレイヤキャラクタを操作して仕事等をすることによりプレイヤキャラクタのレベルや能力等のパラメータを上昇させ，ネットワークを介して接続された他のクライアント機器を操作する他のプレイヤキャラクタと立身出世を競ったり，或いは，ネットワークを介して他のプレイヤキャラクタとチャットをしてコミュニケーションを楽しむゲームが挙げられる。
【０２２０】
また，上記各実施形態では，８人のプレイヤが参加するネットワークゲームを例に挙げて説明したが，本発明にかかるネットワークゲームシステムは，これに限定されるものではなく，たとえば，サーバ機器対１のクライアント機器で戦闘する１人プレイヤ用のゲーム形態も含まれることは言うまでも無い。
【０２２１】
また，ゲームに参加している他のプレイヤが少ないときに，本来人数分のプレイヤが参加していれば存在したであろう他のＰＣ及びそのＰＣの小隊中のＮＰＣを，全てＮＰＣとして登場させ，それらのＮＰＣを現在参加している何れかのクライアント機器（クライアント機器が１つの場合も含む）に分散させて管理させたり，一律にサーバ機器に管理させてもよい。この場合，システムの内部処理的には，ＰＣは，もはや，ユーザ操作にしたがって動作する本来のＰＣではないため，いわゆる相対位置関係を求める処理においてもＮＰＣとして処理する。
【産業上の利用可能性】
【０２２２】
本発明は，複数のキャラクタが登場するネットワークゲームシステムにおいてそのキャラクタをスムーズに動作させるために，登場する各キャラクタの処理および管理を分散して実行するネットワークゲームシステム，クライアント機器，サーバ機器に適用可能である。
【図面の簡単な説明】
【０２２３】
【図１】本発明の各実施形態にかかるネットワークゲームシステムの全体構成図である。
【図２】各実施形態にかかるゲーム機の一例を示した図である。
【図３】各実施形態にかかるゲームサーバのハードウエア構成図である。
【図４】各実施形態にかかるゲーム機のハードウエア構成図である。
【図５】第１実施形態および第２実施形態にかかるゲームサーバの機能構成図である。
【図６】各実施形態にかかるゲーム機の機能構成図である。
【図７】各実施形態にかかるＲＡＭに記憶されるキャラクタ情報の一例を示した図である。
【図８】第１実施形態および第２実施形態にてゲーム機が実行するクライアント側管理処理ルーチンを示したフローチャートである。
【図９】第１実施形態にてゲーム機が実行するキャラクタ管理処理ルーチンを示したフローチャートである。
【図１０】第１実施形態および第２実施形態にてゲーム機またはゲームサーバが実行するキャラクタ変更判定処理ルーチンを示したフローチャートである。
【図１１】戦闘体制に移行する前のゲーム状態を説明するための図である。
【図１２】ＮＰＣと各ＰＣと相対位置関係の一例を説明するための図である。
【図１３】ＮＰＣと各ＰＣと相対位置関係の一例を説明するための図である。
【図１４】第１実施形態および第２実施形態にてゲーム機またはゲームサーバが実行する味方ＰＣ管理変更処理ルーチンを示したフローチャートである。
【図１５】戦闘体制にあるゲーム状態を説明するための図である。
【図１６】ＮＰＣと各ＰＣと相対位置関係の一例を説明するための図である。
【図１７】第１実施形態および第２実施形態にてゲーム機またはゲームサーバが実行する敵ＰＣ管理変更処理ルーチンを示したフローチャートである。
【図１８】自小隊が敵小隊から逃げるゲーム状態を説明するための図である。
【図１９】ＮＰＣと各ＰＣと相対位置関係の一例を説明するための図である。
【図２０】ＮＰＣと各ＰＣと相対位置関係の一例を説明するための図である。
【図２１】ＮＰＣと各ＰＣと相対位置関係の一例を説明するための図である。
【図２２】第１実施形態にてゲームサーバが実行するサーバ側管理処理ルーチンを示したフローチャートである。
【図２３】第２実施形態にてゲーム機が実行するキャラクタ管理処理ルーチンを示したフローチャートである。
【図２４】第２実施形態にてゲームサーバが実行するサーバ側管理処理ルーチンを示したフローチャートである。
【図２５】第３実施形態にかかるゲームサーバの機能構成図である。
【図２６】第３実施形態にてゲームサーバが実行するサーバ側管理処理ルーチンを示したフローチャートである。
【図２７】第３実施形態にてゲーム機が実行するキャラクタ管理処理ルーチンを示したフローチャートである。
【図２８】第３実施形態にてゲーム機またはゲームサーバが実行するキャラクタ変更判定処理ルーチンを示したフローチャートである。
【図２９】第３実施形態にてゲーム機またはゲームサーバが実行する味方ＭＣ管理変更処理ルーチンを示したフローチャートである。
【図３０】第３実施形態にてゲーム機またはゲームサーバが実行する敵ＭＣ管理変更処理ルーチンを示したフローチャートである。
【符号の説明】
【０２２４】
１０ ネットワークゲームシステム
１００ ゲームサーバ
１１０ ハードディスク
１２０ ＲＡＭ
１４０ 入力部
１４５ 通信部
１５０ 記憶部
１５５ 管理部
１６０ 画像処理部
１６５ 画像生成部
１７０ アクション処理実行部
１７０ａ 演算部
１７０ｂ 画像処理部
１７５ 判定部
２００ ゲーム機
２１０ ハードディスク
２２０ ＲＡＭ
２４０ リーダ
２４５ 媒体読取部
２５０ 入力部
２５５ 記憶部
２６０ アクション処理実行部
２６０ａ 演算部
２６０ｂ 画像処理部
２６０ｃ 音響処理部
２６５ 画像生成部
２７０ 音響再生部
２７５ 判定部
２８０ 通信部
３００ ネットワーク
ＰＣ プレイヤキャラクタ
ＮＰＣ ノンプレイヤキャラクタ
ＳＣ サーバキャラクタ
ＭＣ メインキャラクタ
ＣＬ ゲーム機
ＳＶ ゲームサーバ
【技術分野】
【０００１】
本発明は，複数のキャラクタが登場するネットワークゲームシステムにおいて，ゲームに登場するキャラクタに関する処理を複数の機器に分散させる方法に関する。特に，複数のキャラクタが敵味方の集団を形成して互いに戦闘するネットワークゲームシステムにおいてその集団戦闘をスムーズに実現するために，登場する各キャラクタの処理および管理を分散して処理する方法に関する。
【背景技術】
【０００２】
近年，ブロードバンドの普及により，インターネットを利用する人口の拡大と通信技術の進歩が目覚しく，これに伴ってネットワークを介して複数のプレイヤが同時に参加可能なネットワークゲームの人気が高まっている。このようなネットワークゲームとして，たとえば，ネットワークを介して参加した複数のゲームプレイヤを複数のチームに振り分け，複数のチーム同士でネットワークを通じてリアルタイムにゲーム対戦するシステムが提案されている（たとえば，特許文献１を参照。）。
【０００３】
【特許文献１】特開２００１−３５３３７５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
このネットワークゲームシステムでは，ゲーム内のすべてのキャラクタをサーバ側で一元管理する「サーバ・クライアント方式」が採用されている。すなわち，このネットワークシステムでは，センターのホストマシンとしての専用サーバが，実際のゲームプログラムの主な実行とすべてのゲームデータ，および各クライアント機器が共有する仮想空間を一元管理し，各クライアント機器とゲームコマンド等の送受信をすることによりゲームが進行する。
【０００５】
したがって，このネットワークシステムでは，ゲームプレイヤがクライアント機器にキー入力すると，サーバがこのキー入力データを受け取り，すべての処理を実行し，描画情報のみをクライアント機器に送り返した後に，ようやくゲームプレイヤの操作に対するアクションが画面に反映される。このように，自己の操作に対して画面上のキャラクタがすぐに反応しないと，ゲームとしての面白さ，楽しさが半減し，ゲームプレイヤは，その操作性の悪さによりゲームに没頭することができない。
【０００６】
これに対して，「Ｐ２Ｐ（ピアツーピア）ホスト方式」という方式も存在する。この方式は，何れかのクライアント機器をホストマシンとし，ネットワークに接続された他のクライアント機器と直接通信してゲームを進行させていくものである。このため，ホストマシンであるクライアント機器の処理の負荷が高く，どうしてもゲームプレイヤの操作に対して画面上のキャラクタのアクションが遅延してしまう。したがって，Ｐ２Ｐホスト方式によっても上記問題を払拭することはできない。
【０００７】
特に，現在，スタンドアローンで動作している１００体以上のキャラクタが同時に集団戦闘する複雑なアクションゲームをネットワークゲームとして動作させる場合，１００体以上のキャラクタを瞬時にアクションさせることが要求される。しかし，上記従来の方式でのゲーム管理では，キャラクタデータやモーションデータ等の通信量が非常に多くなり，著しいアクション処理の遅延が生じてしまい，ゲームとして成立させることが著しく困難となる。
【０００８】
そこで，本発明は，上記問題に鑑みてなされたものであり，本発明の目的とするところは，複数のキャラクタが登場するネットワークゲームシステムにおいてそれらのキャラクタをスムーズに動作させるために，登場する各キャラクタの処理および管理を分散して実行するネットワークゲームシステム，クライアント機器，サーバ機器を提供することにある。
【課題を解決するための手段】
【０００９】
上記課題を解決するために，本発明のある観点によれば，ネットワークを介してサーバ機器に接続された複数のクライアント機器を，ユーザが操作することにより，入力された情報に応じて動作する複数のプレイヤキャラクタと，自動的に動作する複数のノンプレイヤキャラクタと，を含んだ複数のキャラクタが登場するネットワークゲームシステムが提供される。
【００１０】
このネットワークゲームシステムでは，上記各クライアント機器は，上記複数のキャラクタの位置情報を含んだキャラクタ情報を記憶し，上記ノンプレイヤキャラクタのうち自己のクライアント機器が管理するノンプレイヤキャラクタを管理キャラクタとして登録する記憶部と，上記記憶部に記憶されたキャラクタ情報を用いて，上記ゲームの展開に応じた上記各管理キャラクタの位置の変化の程度および動作の変化の程度を変化後のキャラクタ情報として上記管理キャラクタ毎に演算する演算部と，上記演算された変化後の各管理キャラクタのキャラクタ情報をキャラクタ情報パケットとしてサーバ機器に送信する通信部と，を備える。
【００１１】
また，上記サーバ機器は，上記送信されたキャラクタ情報パケットを受信し，受信したキャラクタ情報パケットを上記ゲームに参加している他のクライアント機器に送信する。これに対して，上記他のクライアント機器は，上記送信されたキャラクタ情報パケットを受信し，受信したキャラクタ情報に基づいて上記変化後のキャラクタ情報を記憶する。
【００１２】
これによれば，クライアント機器が，ゲームの展開に応じた各管理キャラクタの位置の変化および動作の変化の程度を演算する。これにより，サーバ機器に負荷が集中していた，ゲームを進行させるための主処理をゲームに参加している複数のクライアント機器に分担させることができるとともに，サーバ機器とクライアント機器との通信量を極力減らすことができる。この結果，プレイヤの操作に応じて画面上の複数のキャラクタを即座に動作させることができる。このため，プレイヤは，ネットワークを介して接続された他のプレイヤとともに，その操作性のよさにより臨場感あふれたゲームに没頭することができる。
【００１３】
上記各クライアント機器は，さらに，上記演算された各管理キャラクタの位置の変化の程度に基づいて，上記各管理キャラクタの演算後の位置と自己のクライアント機器が管理するプレイヤキャラクタの位置と他のクライアント機器が管理するプレイヤキャラクタの位置との相対関係を求め，求められた位置の相対関係に基づき各管理キャラクタを管理するか否かを判定する判定部を備えていてもよい。このとき，上記各クライアント機器の記憶部は，上記判定部により管理しないと判定された管理キャラクタの登録を削除し，上記各クライアント機器の通信部は，上記判定部により上記管理キャラクタが上記他のクライアント機器により管理されると判定された場合，上記管理キャラクタのキャラクタ情報を含んだキャラクタ管理変更パケットをサーバ機器に送信してもよい。
【００１４】
これに対して，上記サーバ機器は，上記キャラクタ管理変更パケットを受信し，受信したキャラクタ管理変更パケットを上記他のクライアント機器に送信し，上記他のクライアント機器は，上記送信されたキャラクタ管理変更パケットを受信し，受信されたキャラクタ情報を記憶するとともに上記受信されたキャラクタ情報により特定されるキャラクタを管理キャラクタとして登録するようにしてもよい。
【００１５】
これによれば，管理キャラクタの位置と自己のクライアント機器が管理するプレイヤキャラクタの位置と他のクライアント機器が管理するプレイヤキャラクタの位置との相対関係から，ゲームの進行状況に応じてノンプレイヤキャラクタを管理するクライアント機器が適切に特定される。このようにして，ゲームの状況に応じてノンプレイヤキャラクタを管理するクライアント機器を適宜切り替えることにより，システム全体の処理分散を最適化して，よりスムーズにゲームを進行させることができる。なお，ここでいう「管理」とは，たとえば，攻撃防御時のノンプレイヤキャラクタ双方の座標計算やモーションの再生等の処理を各クライアント機器側で行うことをいう。
【００１６】
特に，上記ネットワークゲームシステムは，上記複数のクライアント機器により管理される複数のプレイヤキャラクタと上記複数のプレイヤキャラクタを護衛するノンプレイヤキャラクタとからなる複数のキャラクタが敵味方の集団を形成して互いに戦闘するゲームを提供するシステムである場合に有利である。このような集団戦闘ゲームでは，たとえば，８０体〜１２８体程度の非常に多くのキャラクタが同時に画面上に登場する。このため，ゲームの遅延を避けるためには，処理分散の最適化が不可欠である。
【００１７】
また，上記ネットワークゲームシステムは，上記戦闘ゲームの他，上記複数のクライアント機器により管理される複数のプレイヤキャラクタと上記複数のノンプレイヤキャラクタとが集団を形成して互いに協力するゲームを提供するシステムであってもよい。このシステムの具体例としては，自分のプレイヤキャラクタを操作して複数のノンプレイヤキャラクタとともに仕事等をすることによりプレイヤキャラクタのレベルや能力等のパラメータを上昇させ，ネットワークを介して接続された他のクライアント機器を操作する他のプレイヤキャラクタと立身出世を競うゲームシステムが挙げられる。或いは，プレイヤが操作するプレイヤキャラクタが，複数のノンプレイヤキャラクタの協力を得ながら，ネットワークを介して他のプレイヤキャラクタとチャットをして，コミュニケーションを楽しむゲームが挙げられる。
【００１８】
また，上記課題を解決するために，本発明の別の観点によれば，ネットワークに接続された複数のクライアント機器によりそれぞれ管理される複数のプレイヤキャラクタと上記複数のプレイヤキャラクタの脇役となる複数のノンプレイヤキャラクタとからなる複数のキャラクタが登場するネットワークゲームに参加するクライアント機器が提供される。具体的には，このクライアント機器は，上記複数のキャラクタの位置情報を含んだキャラクタ情報を記憶し，上記ノンプレイヤキャラクタのうち自己のクライアント機器が管理するノンプレイヤキャラクタを管理キャラクタとして登録する記憶部と，上記記憶部に記憶されたキャラクタ情報を用いて，上記ゲームの展開に応じた上記各管理キャラクタの位置の変化の程度および動作の変化の程度を変化後のキャラクタ情報として上記管理キャラクタ毎に演算する演算部と，を備える。
【００１９】
上記クライアント機器は，さらに，上記生成されたキャラクタ情報に基づいてそのキャラクタ情報により特定されるキャラクタに関する画像を生成する画像生成部を備えていてもよい。
【００２０】
これによれば，ゲームの展開に応じた各管理キャラクタの位置の変化および動作の変化の程度はクライアント機器側で演算される。これにより，従来，サーバ機器に負荷が集中していた主処理をゲームに参加している複数のクライアント機器に分担させることができる。これにより，サーバ機器とクライアント機器との通信量も極力減らすことができる。この結果，プレイヤは，プレイヤの操作に応じて即座に動作する画面上の複数のキャラクタを見ながら，臨場感あふれたゲームで楽しく遊ぶことができる。
【００２１】
上記クライアント機器は，上記演算された各管理キャラクタの位置の変化の程度に基づいて，上記各管理キャラクタの演算後の位置と自己のクライアント機器が管理するプレイヤキャラクタの位置と他のクライアント機器が管理するプレイヤキャラクタの位置との相対関係を求め，上記求められた位置の相対関係に基づき各管理キャラクタを管理するか否かを判定する判定部を備えていてもよい。
【００２２】
これによれば，管理キャラクタの位置と自己のクライアント機器が管理するプレイヤキャラクタの位置と他のクライアント機器が管理するプレイヤキャラクタの位置との相対関係から，ゲームの進行状況に応じてノンプレイヤキャラクタを管理するクライアント機器が適切に特定される。また，これによれば，上記各ノンプレイヤキャラクタは，上記ネットワークゲームに参加しているいずれかのクライアント機器に分散して管理される。このようにして，ゲーム状況に応じてノンプレイヤキャラクタを管理するクライアント機器を適宜切り替えることにより，システム全体の処理分散を最適化して，よりスムーズにゲームを進行させることができる。
【００２３】
このとき，上記判定部は，上記求められた位置の相対関係に基づき，上記各管理キャラクタから所定範囲内に位置するプレイヤキャラクタを管理するクライアント機器に管理されるように上記各管理キャラクタを管理するか否かを判定するようにしてもよい。
【００２４】
また，上記判定部は，上記求められた位置の相対関係に基づき，上記各管理キャラクタが，上記各管理キャラクタの敵のプレイヤキャラクタを管理するクライアント機器に優先して管理されるように上記各管理キャラクタを管理するか否かを判定するようにしてもよい。
【００２５】
このネットワークゲームシステムが集団戦闘ゲームである場合，プレイヤキャラクタは，味方のノンプレイヤキャラクタを攻撃しない。換言すれば，プレイヤの入力操作に応じてプレイヤキャラクタを動作させる際，このプレイヤキャラクタの動作（攻撃）に対応して，クライアント機器が，プレイヤの入力操作に応じることなく，自動的に動作させる（すなわち，攻撃に対応して動作するために演算が必要な）キャラクタは，プレイヤキャラクタ近傍の敵のノンプレイヤキャラクタのみである。このことから，本発明では，攻撃を仕掛けたプレイヤキャラクタを管理するクライアント機器自身がプレイヤキャラクタ近傍の敵のノンプレイヤキャラクタを優先的に管理するようにする。この結果，プレイヤの操作に応じて，自クライアント機器が，自プレイヤキャラクタとともに敵のノンプレイヤキャラクタの動作の変化値を瞬時に演算し，その結果を即座に画面上に反映することにより，攻撃時の処理落ちを回避して，臨場感あふれるゲーム展開をプレイヤに即座に提供することができる。
【００２６】
また，上記判定部は，上記求められた位置の相対関係に基づき，上記各管理キャラクタに最も近いプレイヤキャラクタを管理するクライアント機器に管理されるように上記各管理キャラクタを管理するか否かを判定してもよい。
【００２７】
プレイヤの操作に応じて動作するプレイヤキャラクタに対してゲーム進行のための処理が必要になるノンプレイヤキャラクタは，プレイヤキャラクタ近傍のノンプレイヤキャラクタである場合が多い。このことから，本発明では，プレイヤキャラクタを管理するクライアント機器と同じ機器がプレイヤキャラクタ近傍のノンプレイヤキャラクタを敵味方にかかわらず優先的に管理する。これにより，ゲームをスムーズに進行させることができる。
【００２８】
上記判定部は，上記他のクライアント機器が管理するプレイヤキャラクタの位置が，上記各管理キャラクタに最も近い場合であっても，自己のクライアント機器が管理するプレイヤキャラクタの位置より所定距離以上上記各管理キャラクタの近くに位置しない限り，自己のクライアント機器が上記各管理キャラクタを管理すると判定するようにしてもよい。
【００２９】
このように，管理キャラクタの管理の切り替えに際して，所定のマージン（所定距離）を設けることにより，各管理キャラクタの管理の切り替えが頻繁に発生することを防止することができる。このとき，上記所定距離は，各管理キャラクタの管理を切り替えるとの判定が頻繁に生じないような値に設定されるのが好ましい。また，上記所定距離は，上記他のクライアント機器が管理するプレイヤキャラクタと上記各管理キャラクタとの関係が敵味方である場合には，その関係が味方同士である場合に比べ短い値に設定されるほうがよい。また，判定部は，距離以外の要素によって各管理キャラクタの管理切り替えを判定してもよい。たとえば，ノンプレイヤキャラクタが特定のクライアント機器に予め割り付けられている場合には，その取り決めに従って管理を切り替えてもよい。
【００３０】
また，上記判定部は，上記各管理キャラクタが，自己のクライアント機器により管理されるプレイヤキャラクタに対して敵のキャラクタであるか味方のキャラクタであるかを区別することなく，上記演算された位置の相対関係に基づき，上記各管理キャラクタを管理するか否かを判定するようにしてもよい。
【００３１】
また，上記判定部は，上記他のクライアント機器が管理するプレイヤキャラクタが，上記各管理キャラクタおよび自己のクライアント機器が管理するプレイヤキャラクタの敵であって，上記他のクライアント機器が管理するプレイヤキャラクタが上記各管理キャラクタの一定範囲内に位置する場合には，上記求められた位置の相対関係にかかわらず，上記他のクライアント機器が上記各管理キャラクタを管理すると判定するようにしてもよい。
【００３２】
上記クライアント機器であって，さらに，上記判定部により上記各管理キャラクタが上記他のクライアント機器により管理されると判定された場合，上記判定された管理キャラクタのキャラクタ情報を含んだキャラクタ管理変更パケットをサーバ機器に送信する通信部を備え，上記記憶部は，上記他のクライアント機器により管理されると判定された管理キャラクタの登録を削除するようにしてもよい。
【００３３】
また，上記通信部は，上記ネットワークを介してサーバ機器に接続された他のクライアント機器から送信されたキャラクタ管理変更パケットを受信し，上記記憶部は，上記受信したキャラクタ管理変更パケットに含まれるキャラクタ情報を記憶し，上記キャラクタ情報により特定されるキャラクタを管理キャラクタとして登録するようにしてもよい。
【００３４】
これによれば，各クライアント機器が演算した変化後のキャラクタ情報を，サーバ機器を介して他のクライアント機器に送信し，これに応じて，他のクライアント機器が，記憶部のデータを送信されたキャラクタ情報に更新することにより，すべてのクライアント機器において，すべてのキャラクタ情報に関するデータの整合性を保つことができる。
【００３５】
また，上記他のクライアント機器がネットワークを介して複数接続され，上記他のクライアント機器のうち，第１の他のクライアント機器が管理するプレイヤキャラクタが敵であり，第２の他のクライアント機器が管理するプレイヤキャラクタが味方である場合，上記判定部は，上記求められた位置の相対関係に基づき，上記各管理キャラクタが第２の他のクライアント機器よりも第１の他のクライアント機器に優先して管理されるように上記各管理キャラクタを管理するか否かを判定するようにしてもよい。
【００３６】
また，上記判定部は，所定周期ごとに上記各管理キャラクタを管理するか否かを判定してもよい。上記判定部は，ゲームを表示する表示画面を走査するタイミングに連動して，上記判定を行ってもよい。ここで，この画面の走査タイミングとは，垂直帰線割込が発生するタイミングである。また，所定周期の一例としては，モニタの垂直帰線周期と一致した１／６０秒（１６．６ミリ秒）に一度の周期が挙げられるが，必ずしも，所定周期は画面走査のタイミングである必要はなく，判定部での処理の負荷に応じて適度な所定周期，例えば１／３０秒または１／２０秒としてもよい。なお，上記判定部は，所定周期ごとに全ての管理キャラクタについて一度に判定するのではなく，全ての管理キャラクタを所定数に分けて所定周期ごとに数段階ずつ判定するようにしてもよい。
【００３７】
また，上記課題を解決するために，本発明の別の観点によれば，複数のプレイヤキャラクタと上記複数のプレイヤキャラクタを上記複数のプレイヤキャラクタの脇役となる複数のノンプレイヤキャラクタとからなる複数のキャラクタが登場するネットワークゲームを管理するサーバ機器が提供される。
【００３８】
具体的には，上記サーバ機器は，ネットワークに接続された複数のクライアント機器により管理される上記複数のキャラクタの位置情報と上記複数のキャラクタを管理するクライアント機器の識別情報とを記憶する記憶部と，上記キャラクタ情報に含まれる位置情報と上記各ノンプレイヤキャラクタを各々管理するクライアント機器の識別情報とに基づいて，各クライアント機器が管理するプレイヤキャラクタの位置と各クライアント機器が管理するノンプレイヤキャラクタの位置との相対関係を求め，上記求められた位置の相対関係に基づき上記ノンプレイヤキャラクタを管理するクライアント機器を判定する判定部と，上記各ノンプレイヤキャラクタを管理すると判定されたクライアント機器にキャラクタ管理変更パケットを送信する通信部とを備える。
【００３９】
これによれば，サーバ機器にてすべてのキャラクタの管理切替処理が実行され，その結果が，各クライアント機器に一度に送信される。これにより，サーバ機器から全クライアント機器までの距離や各クライアント機器の性能その他の通信環境が同一の場合で且つ通信障害が発生しない場合，各クライアント機器で生じる管理切替処理の遅延は，理論上，ほぼ同時になると考えられる。このため，画面上の多数のキャラクタをより自然に動作させることができる。また，すべてのキャラクタの管理切り替えをサーバ側で行うため，正確かつ簡易にデータの整合性を保つことができる。また，この場合，キャラクタ管理の切り替えのための遅延時間は，サーバ機器からクライアント機器への通信時間のみである。このため，キャラクタの管理切替処理をクライアント機器にて行う場合に比べて通信遅延（キャラクタの管理切替処理をクライアント機器にて行う場合，変更元クライアント機器からサーバを経由して変更先クライアント機器へ通信するための通信時間がかかる。即ち，この場合は,サーバ側で管理切替処理を行う場合に比べ，ほぼ２倍の通信時間がかかる。）が少ないという利点がある。なお，キャラクタを管理するクライアント機器の識別情報の一例としては，予め登録されている管理元のクライアント番号が挙げられる。
【００４０】
また，上記課題を解決するために，本発明の別の観点によれば，ネットワークに接続された複数のクライアント機器を，ユーザが操作することにより，入力された情報に応じて動作する複数のプレイヤキャラクタと，自動的に動作する複数のノンプレイヤキャラクタと，を含んだ複数のキャラクタが登場するネットワークゲームをコンピュータに実行させるためのキャラクタ管理プログラムが提供される。
【００４１】
具体的には，上記複数のキャラクタの位置情報を含んだキャラクタ情報を各クライアント機器の記憶部に各々記憶する処理と，上記ノンプレイヤキャラクタのうち自己のクライアント機器が管理するノンプレイヤキャラクタを管理キャラクタとして各クライアント機器の記憶部に各々登録する処理と，上記各クライアント機器の記憶部に記憶されたキャラクタ情報を用いて，各クライアント機器に対して上記ゲームの展開に応じた上記各管理キャラクタの位置の変化の程度および動作の変化の程度を変化後のキャラクタ情報として上記管理キャラクタ毎に演算する処理と，をコンピュータに実行させることを特徴とするキャラクタ管理プログラムが提供される。
【００４２】
上記キャラクタ管理プログラムでは，上記演算された各管理キャラクタの位置の変化の程度に基づいて，上記各管理キャラクタの演算後の位置と自己のクライアント機器が管理するプレイヤキャラクタの位置と他のクライアント機器が管理するプレイヤキャラクタの位置との相対関係を求め，上記求められた位置の相対関係に基づき各管理キャラクタを管理するクライアント機器を判定する処理と，上記他のクライアント機器により管理されると判定された管理キャラクタの登録を上記自己のクライアント機器の記憶部から削除する処理と，上記他のクライアント機器により管理されると判定された管理キャラクタのキャラクタ情報を含んだキャラクタ管理変更パケットをサーバ機器に送信する処理と，をコンピュータに実行させるようにしてもよい。
【００４３】
また，上記課題を解決するために，本発明の別の観点によれば，ネットワークに接続された複数のクライアント機器を，ユーザが操作することにより，入力された情報に応じて動作する複数のプレイヤキャラクタと，自動的に動作する複数のノンプレイヤキャラクタと，を含んだ複数のキャラクタが登場するネットワークゲームをコンピュータに実行させるためのキャラクタ管理プログラムを記憶したコンピュータ読み取り可能な記憶媒体が提供される。
【００４４】
具体的には，上記複数のキャラクタの位置情報を含んだキャラクタ情報を各クライアント機器の記憶部に各々記憶する処理と，上記ノンプレイヤキャラクタのうち自己のクライアント機器が管理するノンプレイヤキャラクタを管理キャラクタとして各クライアント機器の記憶部に各々登録する処理と，上記各クライアント機器の記憶部に記憶されたキャラクタ情報を用いて，各クライアント機器に対して上記ゲームの展開に応じた上記各管理キャラクタの位置の変化の程度および動作の変化の程度を変化後のキャラクタ情報として上記管理キャラクタ毎に演算する処理と，をコンピュータに実行させることを特徴とするキャラクタ管理プログラムを記憶したコンピュータ読み取り可能な記憶媒体が提供される。
【００４５】
上記キャラクタ管理プログラムを記憶したコンピュータ読み取り可能な記憶媒体では，上記演算された各管理キャラクタの位置の変化の程度に基づいて，各管理キャラクタの演算後の位置と自己のクライアント機器が管理するプレイヤキャラクタの位置と他のクライアント機器が管理するプレイヤキャラクタの位置との相対関係を求め，上記求められた位置の相対関係に基づき各管理キャラクタを管理するクライアント機器を判定する処理と，上記他のクライアント機器により管理されると判定された管理キャラクタの登録を上記自己のクライアント機器の記憶部から削除する処理と，上記他のクライアント機器により管理されると判定された管理キャラクタのキャラクタ情報を含んだキャラクタ管理変更パケットをサーバ機器に送信する処理と，をコンピュータに実行させるキャラクタ管理プログラムを記憶したコンピュータ読み取り可能な記憶媒体であってもよい。
【００４６】
これによれば，クライアント機器が，ゲームの展開に応じた各管理キャラクタの位置の変化および動作の変化を演算する。これにより，ゲームを進行させるために発生する主処理をゲームに参加している複数のクライアント機器に分担させることができるとともに，サーバ機器とクライアント機器との通信量を極力減らすことができる。この結果，プレイヤによる操作に応じて即座に動作する画面上の複数のキャラクタを見ながら，プレイヤは，臨場感あふれたゲームを楽しむことができる。
【００４７】
また，上記課題を解決するために，本発明の別の観点によれば，ネットワークを介してサーバ機器に接続された１または複数のクライアント機器を，ユーザが操作することにより，入力された情報に応じて動作する１または複数のプレイヤキャラクタと，自動的に動作する複数のノンプレイヤキャラクタと，を含んだ複数のキャラクタが登場するネットワークゲームシステムが提供される。
【００４８】
このネットワークゲームシステムでは，前記各クライアント機器は，前記複数のキャラクタの位置情報を含んだキャラクタ情報を記憶し，前記ノンプレイヤキャラクタのうち自己のクライアント機器が管理するノンプレイヤキャラクタを管理キャラクタとして登録する記憶部と，前記記憶部に記憶されたキャラクタ情報を用いて，前記ゲームの展開に応じた前記各管理キャラクタの位置の変化の程度および動作の変化の程度を変化後のキャラクタ情報として前記管理キャラクタ毎に演算する演算部と，前記演算された変化後の各管理キャラクタのキャラクタ情報をキャラクタ情報パケットとしてサーバ機器に送信する通信部と，を備え，前記サーバ機器は，前記送信されたキャラクタ情報パケットを受信し，受信したキャラクタ情報パケットを前記ゲームに参加している他のクライアント機器に送信し，前記ゲームに参加している他のクライアント機器は，前記送信されたキャラクタ情報パケットを受信し，受信されたキャラクタ情報に基づいて前記変化後のキャラクタ情報を記憶する。
【００４９】
このとき，前記サーバ機器は，前記複数のキャラクタの位置情報を含んだキャラクタ情報を記憶し，前記ノンプレイヤキャラクタのうち自己のサーバ機器が管理するノンプレイヤキャラクタを管理キャラクタとして登録する記憶部と，前記記憶部に記憶されたキャラクタ情報を用いて，前記ゲームの展開に応じた前記各管理キャラクタの位置の変化の程度および動作の変化の程度を変化後のキャラクタ情報として前記管理キャラクタ毎に演算する演算部と，前記演算された変化後の各管理キャラクタのキャラクタ情報をキャラクタ情報パケットとして前記ゲームに参加しているすべてのクライアント機器に送信する通信部と，を備えていてもよい。
【００５０】
これによれば，ゲームに参加するユーザが足りない場合であっても（たとえば，ゲームに参加するユーザが一人だとしても），操作するユーザがいないプレイヤキャラクタおよびこのプレイヤキャラクタに付随するノンプレイヤキャラクタについては，サーバ機器が，それらのキャラクタを自動的に操作する。これにより，参加者が足りなくても，ユーザは，ゲームを思う存分楽しむことができる。また，クライアント機器により管理されるキャラクタとサーバ機器により管理されるキャラクタとを分けることによって，システム全体の処理を分散し，これにより，ゲームをスムーズに進行させることができる。なお，サーバ機器が自動操作するプレイヤキャラクタは複数であってもよい。
【００５１】
前記ゲームに登場する前記複数のキャラクタは，さらに，前記サーバ機器の制御により自動的に動作する１または複数のサーバキャラクタを含み，前記サーバ機器は，さらに，前記演算された各管理キャラクタの位置の変化の程度に基づいて，前記各管理キャラクタの演算後の位置と自己のサーバ機器が管理するいずれかの前記サーバキャラクタの位置と前記クライアント機器が管理するプレイヤキャラクタまたは他のサーバキャラクタの位置との相対関係を求め，求められた位置の相対関係に基づき各管理キャラクタを管理するか否かを前記サーバキャラクタ毎に判定する判定部，を備えていてもよい。
【００５２】
このとき，前記サーバ機器の記憶部は，前記サーバ機器の判定部により管理しないと判定された管理キャラクタの登録を削除し，前記サーバ機器の通信部は，前記サーバ機器の判定部により前記管理キャラクタが前記クライアント機器により管理されると判定された場合，前記管理キャラクタのキャラクタ情報を含んだキャラクタ管理変更パケットを前記クライアント機器に送信し，前記クライアント機器は，前記送信されたキャラクタ管理変更パケットを受信し，受信されたキャラクタ情報を記憶するとともに前記受信されたキャラクタ情報により特定されるキャラクタを管理キャラクタとして登録するようにしてもよい。
【００５３】
これによれば，サーバ機器が管理している管理キャラクタについては，サーバ機器がその管理を他の機器に切り替えるか否かをサーバキャラクタ毎に判定する。ここで，サーバ機器が複数のサーバキャラクタを管理する場合，記憶部には，サーバキャラクタ毎に，そのサーバキャラクタの情報および各サーバキャラクタの小隊に含まれる管理キャラクタ（ノンプレイヤキャラクタ）の情報が記憶され，随時更新される。
【００５４】
また，前記ネットワークゲームシステムは，前記１または複数のクライアント機器により管理される１または複数のプレイヤキャラクタと前記１または複数のプレイヤキャラクタを護衛する１または複数のノンプレイヤキャラクタとが味方集団を形成し，かつ，前記サーバ機器により管理される１または複数のサーバキャラクタと前記サーバキャラクタを護衛する１または複数のノンプレイヤキャラクタとが敵集団または味方集団の少なくともいずれかを形成して互いに戦闘するゲームを提供するシステムであってもよい。
【００５５】
また，上記課題を解決するために，本発明の別の観点によれば，ネットワークを介してサーバ機器に接続された１または複数のクライアント機器を，ユーザが操作することにより，入力された情報に応じて動作する１または複数のプレイヤキャラクタと，自動的に動作する複数のノンプレイヤキャラクタと，を含んだ複数のキャラクタが登場するネットワークゲームをコンピュータに実行させるためのキャラクタ管理プログラムが提供される。
【００５６】
このキャラクタ管理プログラムは，さらに，前記複数のキャラクタの位置情報を含んだキャラクタ情報を各クライアント機器の記憶部に各々記憶する処理と，前記ノンプレイヤキャラクタのうち自己のクライアント機器が管理するノンプレイヤキャラクタを管理キャラクタとして各クライアント機器の記憶部に各々登録する処理と，前記各クライアント機器の記憶部に記憶されたキャラクタ情報を用いて，各クライアント機器に対して前記ゲームの展開に応じた前記各管理キャラクタの位置の変化の程度および動作の変化の程度を変化後のキャラクタ情報として前記管理キャラクタ毎に演算する処理と，をコンピュータに実行させるようにしてもよい。
【００５７】
前記キャラクタ管理プログラムは，さらに，前記複数のキャラクタの位置情報を含んだキャラクタ情報を前記サーバ機器の記憶部に記憶する処理と，前記ノンプレイヤキャラクタのうち自己のサーバ機器が管理するノンプレイヤキャラクタを管理キャラクタとして前記サーバ機器の記憶部に登録する処理と，前記サーバ機器の記憶部に記憶されたキャラクタ情報を用いて，前記サーバ機器に対して前記ゲームの展開に応じた前記各管理キャラクタの位置の変化の程度および動作の変化の程度を変化後のキャラクタ情報として前記管理キャラクタ毎に演算する処理と，をコンピュータに実行させるようにしてもよい。
【００５８】
このとき，前記ゲームで登場する前記複数のキャラクタは，さらに，前記サーバ機器の制御により自動的に動作する１または複数のサーバキャラクタを含んでいてもよい。また，前記キャラクタ管理プログラムは，さらに，前記演算された各管理キャラクタの位置の変化の程度に基づいて，前記各管理キャラクタの演算後の位置と自己のサーバ機器が管理するいずれかのサーバキャラクタの位置とクライアント機器が管理するプレイヤキャラクタの位置との相対関係を求め，前記求められた位置の相対関係に基づき各管理キャラクタを前記サーバキャラクタ毎に管理するサーバ機器またはクライアント機器を判定する処理と，前記クライアント機器により管理されると判定された管理キャラクタの登録を前記自己のサーバ機器の記憶部から削除する処理と，前記クライアント機器により管理されると判定された管理キャラクタのキャラクタ情報を含んだキャラクタ管理変更パケットを前記クライアント機器に送信する処理と，をコンピュータに実行させるようにしてもよい。
【００５９】
前記キャラクタ管理プログラムは，前記１または複数のクライアント機器により管理される１または複数のプレイヤキャラクタと前記１または複数のプレイヤキャラクタを護衛する１または複数のノンプレイヤキャラクタが味方集団を形成し，且つ前記サーバ機器により管理される１または複数のサーバキャラクタと前記サーバキャラクタを護衛する１または複数のノンプレイヤキャラクタが敵集団または味方集団の少なくともいずれかを形成して互いに戦闘するゲームを提供するプログラムであってもよい。
【００６０】
これによれば，ゲームに参加するユーザが足りない場合であっても（たとえば，ゲームに参加するユーザが一人だとしても），操作するユーザがいないプレイヤキャラクタおよび自己のサーバ機器が管理するノンプレイヤキャラクタについては，サーバ機器が，それらのキャラクタを自動的に操作する。これにより，参加者が足りなくても，ユーザは，ゲームを思う存分楽しむことができる。また，クライアント機器により管理されるキャラクタとサーバ機器により管理されるキャラクタとを分けることによって，システム全体の処理を分散し，これにより，ゲームをスムーズに進行させることができる。
【発明の効果】
【００６１】
以上説明したように本発明によれば，複数のキャラクタが登場するネットワークゲームシステムにおいてそれらのキャラクタをスムーズに動作させるために，登場する各キャラクタの処理および管理を分散して実行するネットワークゲームシステム，クライアント機器，サーバ機器およびこれらを制御するプログラムを提供することができる。
【発明を実施するための最良の形態】
【００６２】
以下に添付図面を参照しながら，本発明の好適な実施形態について詳細に説明する。なお，以下の説明及び添付図面において，同一の構成及び機能を有する構成要素については，同一符号を付することにより，重複説明を省略する。
【００６３】
（第１実施形態）
（ネットワークゲームシステムの全体構成）
まず，本発明の第１実施形態にかかるネットワークゲームシステムの全体構成およびこのシステムにて実行されるゲームの概要について，図１を参照しながら説明する。
【００６４】
ネットワークゲームシステム１０は，ネットワークゲームサーバ（以下，ゲームサーバと称呼する。）１００と複数のゲーム機２００（２００ａ，２００ｂ，２００ｃ）とを含んで構成されている。ここでは，ＰＣ２００ａも，ゲーム機２００として機能するので，以下の説明ではゲーム機２００に含んで説明する。ゲームサーバ１００と複数のゲーム機２００とは，インターネット等のネットワーク（通信回線）３００を介して接続されている。
【００６５】
ゲームサーバ１００は，ネットワークゲームの進行および管理を制御する。具体的には，ゲームサーバ１００は，主にチート対策，すなわち，不正行為の有無の判定とその排除や送受信データの整合性チェックを行う。また，ゲームサーバ１００は，各ゲーム機２００から種々のデータを受信したり，他のゲーム機２００に種々のデータを一斉に送信する。ゲームサーバ１００は，その他アイテム情報の管理（どのプレイヤが何を持っているか）やプレイヤにより操作されるプレイヤキャラクタの体力情報などを記憶管理している。ゲームサーバ１００は，ネットワークゲームを提供する側のコンピュータ（サーバ機器）の一例であり，ネットワーク３００に接続されたクライアント機器（ゲーム機器）の一つがゲームサーバ１００として機能してもよい。
【００６６】
ゲーム機２００は，プレイヤの操作に応じてネットワークゲームを遂行する。ゲーム機２００は，ネットワークゲームに登場するキャラクタのうち，後述する管理キャラクタを管理する。ネットワークゲームに登場するキャラクタは，いずれかのゲーム機２００に管理されるものとし，同じキャラクタが複数のゲーム機２００により管理されることはない。
【００６７】
また，各ゲーム機２００は，自分が管理しているキャラクタのキャラクタ情報を，ゲームサーバ１００を介して他のゲーム機２００に送り続ける。ここで，キャラクタ情報は，キャラクタのモーション等そのキャラクタの状態を示す情報である。また，各ゲーム機２００は，他のゲーム機２００から送信されたキャラクタ情報を受け取った時点でそのモーション処理（ゲーム上のキャラクタの動作処理）を開始する。また，ゲーム機２００は，モーションと同じタイミングでコリジョン判定（当たり判定，衝突判定）を行う。
【００６８】
ゲーム機２００は，ゲームサーバ１００からサービスを受ける側のコンピュータ（クライアント機器）の一例であって，家庭用ゲーム装置であっても携帯ゲーム機であってもよい。クライアント機器の他の例としては，パーソナルコンピュータ（ＰＣ）の他に携帯デバイス（たとえば，携帯電話，ＰＤＡ（Personal Digital Assistants））等のユーザ端末であってもよい。なお，各ゲーム機２００は，ＴＣＰ／ＩＰ等の通信プロトコルによりネットワーク３００に接続され，各々異なるＩＰアドレスが割り振られているため，各プレイヤは，各種データを送受信したゲーム機２００を各々識別することができる。
【００６９】
また，ゲーム機２００は，たとえば，図２に示したように，ゲーム機本体２００ａ１とコントローラパッド等２００ａ２（入力装置）とテレビモニタ２００ａ３とから構成されていてもよい。ゲーム機２００ａで使用されるプログラム，画像，音楽等の各種データがＣＤ−ＲＯＭ４００（または，ＤＶＤ）等の記録媒体に記録されている場合には，プレイヤ（ユーザ）は，ＣＤ−ＲＯＭ４００等の記録媒体をゲーム機本体２００ａ１に挿入することによりゲームをスタートさせることができる。
【００７０】
（ネットワークゲームシステムの概要）
このように構成されたネットワークゲームシステム１０では，複数のゲーム機２００によりそれぞれ管理される複数のプレイヤキャラクタ，および，これら複数のプレイヤキャラクタのそれぞれ脇役となる複数のノンプレイヤキャラクタからなる複数のキャラクタが登場するネットワークゲームが提供される。そして，各ゲーム機２００のプレイヤが各プレイヤキャラクタをそれぞれ操作することにより，複数のキャラクタがゲーム上で動作してゲームが進行する。以下の実施形態では，このネットワークゲームシステム１０によって提供されるネットワークゲームとして，複数のプレイヤキャラクタとこれら複数のプレイヤキャラクタを護衛するノンプレイヤキャラクタとからなる複数のキャラクタが敵味方の集団を形成して互いに戦闘するゲームを例に挙げて説明する。
【００７１】
（集団戦闘ネットワークゲーム）
まず，このゲームの概要を説明する。あるプレイヤが，ネットワーク３００に接続された自己のゲーム機２００を用いて自己のプレイヤキャラクタを操作すると，このプレイヤキャラクタを小隊長とした複数の味方コンピュータキャラクタ（ノンプレイヤキャラクタ）で構成される自小隊がプレイヤの操作にしたがって画面上を移動し，武器を使って戦う。同時に，他のプレイヤが，ネットワーク３００に接続された他ゲーム機２００を用いて敵プレイヤキャラクタを操作すると，この敵プレイヤキャラクタを小隊長とした敵小隊が画面上を移動し，武器を使って戦う。プレイヤは，自己のプレイヤキャラクタを操作して戦闘することにより自己のプレイヤキャラクタのレベルや能力等のパラメータを上昇させたり，ネットワーク３００を介して接続された他のプレイヤの領土を占領することができる。なお，このゲームに登場するキャラクタは，前述したように，プレイヤが操作可能なプレイヤキャラクタに限らず，各ゲーム機２００による自動的な演算により動作するノンプレイヤキャラクタも存在し，プレイヤキャラクタとノンプレイヤキャラクタとがディスプレイ上に小隊を組んで表示される。本実施形態にかかる集団戦闘ネットワークゲームは，このようにしてネットワーク３００を介して自小隊と味方小隊と敵小隊とが集団で対戦するゲームである。
【００７２】
集団戦闘ネットワークゲームには，８台のゲーム機２００が４台ずつ敵味方に分かれて参加するものとする。参加する８人のプレイヤのうち，たとえば，４人を徳川軍，残りの４人を豊臣軍し，各軍は，４小隊で構成され，各小隊は１体のプレイヤキャラクタと最大７９体のノンプレイヤキャラクタとから構成されるものとする。なお，以下の説明では，便宜上，各プレイヤが操作するプレイヤキャラクタをＰＣ（Ｐｌａｙｅｒ Ｃｈａｒａｃｔｅｒ）といい，このうち，自プレイヤが操作するプレイヤキャラクタを自ＰＣ，他プレイヤが操作する味方のプレイヤキャラクタを味方ＰＣ，他プレイヤが操作する敵のプレイヤキャラクタを敵ＰＣという。
【００７３】
また，８体のＰＣをそれぞれ護衛するコンピュータキャラクタをＮＰＣ（Ｎｏｎ Ｐｌａｙｅｒ Ｃｈａｒａｃｔｅｒ，ノンプレイヤキャラクタ）といい，このうち，自プレイヤまたは味方プレイヤを護衛するノンプレイヤキャラクタを味方ＮＰＣといい，敵プレイヤを護衛するノンプレイヤキャラクタを敵ＮＰＣという。
【００７４】
たとえば，図１１では，ＰＣ１が自ＰＣ，ＰＣ２およびＰＣ４が味方ＰＣ，ＰＣ３が敵ＰＣである。また，ＰＣ１，ＰＣ２およびＰＣ４の周囲にてそれぞれの小隊境界線内に位置するＮＰＣ（ＮＰＣ１１を含む。）が味方ＮＰＣ，ＰＣ３の周囲にて小隊境界線内に位置するＮＰＣ（ＮＰＣ３１を含む。）が敵ＮＰＣである。
【００７５】
（ノンプレイヤキャラクタの管理の原則）
つぎに，各キャラクタがどの機器によって管理されるかについて，その原則を説明する。まず，上述した複数の小隊のうち，自小隊に属する自ＰＣおよびＮＰＣは，原則として自己のゲーム機２００に管理される。味方ＰＣの他小隊に属する味方ＰＣおよびＮＰＣは，原則として味方ＰＣを操作するゲーム機２００に管理される。同様に，敵ＰＣの他小隊に属する敵ＰＣおよびＮＰＣは，原則として敵ＰＣを操作するゲーム機２００に管理される。なお，ＰＣをゲームサーバ１００にて自動的に管理する場合（たとえば，ゲームに参加するプレイヤが足りず，１または２以上の敵ＰＣまたは味方ＰＣをゲームサーバ１００にて自動管理することとなった場合）には，このＰＣの小隊に属するＮＰＣもゲームサーバ１００により自動的に管理されるように制御してもよい。これについては第３実施形態にて詳細を説明する。そして，以下の第１実施形態および実施形態２の説明では，すべてのＮＰＣは，いずれかのゲーム機２００により管理されることとする。
【００７６】
なお，本実施形態では，ネットワーク仮想空間上に存在するすべてのキャラクタは，いずれかのゲーム機２００に管理されるようになっている。すなわち，各ゲーム機２００は，自分が管理するキャラクタの位置，モーション情報（再生中のモーション番号，現在のフレーム番号）などを所定周期毎に演算し，演算された情報に基づいてキャラクタの動作をディスプレイに描画するとともに，演算されたデータをキャラクタ情報としてゲームサーバ１００を介して他のゲーム機２００に送信する。他のゲーム機２００は，送信されたキャラクタ情報（詳細は後述）を受信し，受信した情報データに基づいてキャラクタの動作をディスプレイに描画するとともに，記憶領域に記憶されているキャラクタ情報を更新する。
【００７７】
このように，本実施形態のネットワークゲームシステム１０は，完全非同期型（同一フレームで各ゲーム機のキャラクタ情報が食い違っていても，違ったままゲームを進行するタイプ）を採用する。これによれば，自ゲーム機２００が操作する自ＰＣが，自ゲーム機２００によって管理される管理キャラクタを攻撃した場合には，自ゲーム機２００により管理キャラクタの攻撃後のモーションが演算され，この演算結果により自ゲーム機２００では，管理キャラクタのダメージモーションが即座に再生される。しかし，自ゲーム機２００が操作する自ＰＣが，他ゲーム機２００が管理するキャラクタを攻撃した場合には，往復（自ゲーム機２００→ゲームサーバ１００→他ゲーム機２００→ゲームサーバ１００→自ゲーム機２００）の通信時間が経過した後に，自ゲーム機２００にて攻撃されたキャラクタのダメージモーションが再生されることになる。
【００７８】
この性質を利用して，ＰＣと各ＮＰＣとの距離に応じて各ＮＰＣを管理するゲーム機２００を切り替えることにより，各キャラクタのモーションの遅延を感じる機会を少なくすることができ，この結果，プレイヤの操作感覚を良好にすることができる。そこで，ＮＰＣは，敵味方に関係なくその座標から最も近いＰＣを管理するゲーム機２００により管理されるようにする。以下に，この戦闘ゲームを管理するゲームサーバ１００について説明し，ついで，ゲーム機２００が各ＮＰＣの管理をどのように切り替えるのかについて説明する。
【００７９】
（ゲームサーバおよびゲーム機の内部構成）
まず，ゲームサーバ１００およびゲーム機２００のハードウエア構成について，図３および図４を参照しながら説明する。図３は，ゲームサーバ１００のハードウエア構成を示し，図４は，ゲーム機２００のハードウエア構成を示したものである。
【００８０】
図３のゲームサーバ１００は，ＲＯＭ１０５，ハードディスク（ＨＤＤ）１１０，ＣＰＵ１１５，ＲＡＭ１２０，バス１２５，画像生成回路１２７，内部インタフェース（内部Ｉ／Ｆ）１３０および外部インタフェース（外部Ｉ／Ｆ）１３５を含んで構成されている。
【００８１】
ＲＯＭ１０５には，ゲームサーバ１００を動作させるための基本的なプログラムや，ゲームサーバ１００が異常なときに起動するプログラム等が記録されている。ハードディスク１１０には各種プログラムやデータが蓄積されている。ハードディスク１１０は，記憶装置の一例であり，光ディスクや光磁気ディスクなどの記憶装置であってもよい。
【００８２】
ＣＰＵ１１５は，ゲームサーバ１００全体を制御する。ＣＰＵ１１５は，ハードディスク１１０等に記憶されたプログラムをワーク用のＲＡＭ１２０にロードした後，そのプログラムを実行するようになっている。バス１２５は，ＲＯＭ１０５，ハードディスク１１０，ＣＰＵ１１５，ＲＡＭ１２０，画像生成回路１２７，内部インタフェース１３０および外部インタフェース１３５の各デバイス間で情報をやりとりする経路である。
【００８３】
画像生成回路１２７は，グラフィックチップとＶＲＡＭとから構成されていて，ＣＰＵ１１５から画像の生成を指示されると，その指示に従ってＣＰＵ１１５とは別な時系列で画像を生成する。
【００８４】
内部インタフェース１３０は，キーボード４０５やマウス４１０からネットワークゲームに関するデータを入力し，必要なデータをモニタ４１５に出力するようになっている。外部インタフェース１３５は，ネットワーク３００を介してゲームに参加している他のゲーム機２００と各種データを送受信するようになっている。
【００８５】
図４のゲーム機２００は，ＲＯＭ２０５，ハードディスク（ＨＤＤ）２１０，ＣＰＵ２１５，ＲＡＭ２２０，バス２２５，画像生成回路２２７，音響再生回路２２９，内部インタフェース２３０，外部インタフェース２３５およびリーダ２４０を含んで構成されている。
【００８６】
ＲＯＭ２０５には，ゲームを実行させるためのプログラム等が記録されている。ハードディスク２１０には各種プログラムや各種データが蓄積されている。ハードディスク２１０は，記憶装置の一例であり，光ディスクや光磁気ディスクなどの記憶装置であってもよい。
【００８７】
ＣＰＵ２１５は，ゲーム機２００全体を制御する。ＣＰＵ２１５は，ハードディスク２１０に記憶されたプログラムをゲーム機２００内のワーク用のＲＡＭ２２０にロードする。または，ＣＰＵ２１５は，リーダ２４０が読み込んだＣＤ−ＲＯＭ４００内のプログラムをＲＡＭ２２０にロードする。ＣＰＵ２１５は，このようにしてＲＡＭ２２０にロードされたプログラムを実行することによりゲームをスタートさせ，ゲームサーバ１００と逐次通信しながらゲームを進行するようになっている。
【００８８】
なお，一旦，ＣＰＵ２１５が，記録媒体上のプログラム等をＲＡＭ２２０上にコピーしてしまえば，次回からはＲＡＭ２２０上のプログラム等を実行することによりゲームをスタートすることができる。また，一旦，ＣＰＵ２１５が，ゲーム機２００内のハードディスク２１０に，ＣＤ−ＲＯＭ４００上のプログラム等をコピーしてしまえば，次回以降は，ハードディスク２１０上のプログラムを実行することによりゲームをスタートすることもできる。また，ネットワーク３００上にこれらのプログラム等がアップロードされている場合には，ＣＰＵ２１５が，一旦，これらのプログラムをゲーム機２００のＲＡＭ２２０にダウンロードした後，そのプログラムをスタートさせるようにしてもよいし，一旦，ゲーム機２００のハードディスク２１０にこれをダウンロードし，次回以降は，ハードディスク２１０に記憶されたプログラムを起動させることによりゲームをスタートさせるようにしてもよい。
【００８９】
バス２２５は，ＲＯＭ２０５，ハードディスク２１０，ＣＰＵ２１５，ＲＡＭ２２０，画像生成回路２２７，音響再生回路２２９，内部インタフェース２３０，外部インタフェース２３５およびリーダ２４０の各デバイス間で情報をやりとりする経路である。
【００９０】
画像生成回路２２７は，グラフィックチップとＶＲＡＭとから構成されていて，ＣＰＵ２１５から画像の生成を指示されると，その指示に従って画像を生成する。音響再生回路２２９は，サウンドチップとサウンドＲＡＭとから構成されていて，ＣＰＵ２１５からサウンドの生成を指示されると，その指示に従って各管理キャラクタの戦闘動作に対応したバックミュージックや戦闘音等の音響処理を行う。
【００９１】
内部インタフェース２３０は，コントローラパッド４３０やキーボード４３５やマウス４４０等を用いてプレイヤのゲーム操作を入力するとともに，敵味方の集団を形成して互いに戦闘する複数のキャラクタの映像および音響をモニタ４４５およびスピーカ４５０にそれぞれ出力するようになっている。外部インタフェース２３５は，ネットワーク３００を介して，プレイヤによる操作に応じたコマンドやメッセージ等の各種データをゲームサーバ１００に送受信するようになっている。リーダ２４０は，ＣＤ−ＲＯＭ４００からデータを読み込む。
【００９２】
つぎに，ゲームサーバ１００およびゲーム機２００の機能構成について，図５および図６を参照しながら説明する。
（ゲームサーバの機能構成）
図５に示したように，ゲームサーバ１００は，入力部１４０，通信部１４５，記憶部１５０，管理部１５５，画像処理部１６０および画像生成部１６５の機能ブロックにて示される各機能を有している。
【００９３】
入力部１４０は，ネットワークゲームを管理する管理者によるキーボード４０５またはマウス４１０の操作に応じてデータを入力する。通信部１４５は，ゲームに参加している複数のゲーム機２００に必要な情報を送受信する。
【００９４】
記憶部１５０は，複数のキャラクタ（プレイヤキャラクタＰＣおよびノンプレイヤキャラクタＮＰＣ）の位置情報と各ノンプレイヤキャラクタＮＰＣを各々管理するゲーム機２００の識別情報とを含んだキャラクタ情報を記憶する。
【００９５】
管理部１５５は，ゲーム中のデータの整合性を保ち，ゲームを矛盾なく進行させるために，入力部１４０により入力されるデータ，通信部１４５により送受信されるデータ，記憶部１５０の各記憶領域（ＲＯＭ１０５，ＲＡＭ１２０，ハードディスク１１０）に記憶されたデータを管理したり，ゲーム中の各処理のタイミングを管理する。
【００９６】
画像処理部１６０は，ゲームの進行に会わせて必要なパラメータとコマンドとを生成し，これらを画像生成部１６５に出力することにより，画像生成部１６５に画像の生成を指示するようになっている。画像生成部１６５は，画像処理部１６０からの画像の生成の指示を受けて，光源処理等を行い，キャラクタ情報にしたがった各管理キャラクタの戦闘動作を３次元フィールドでモニタ４４５に描画する。
【００９７】
（ゲーム機の機能構成）
図６に示したように，ゲーム機２００は，媒体読取部２４５，入力部２５０，記憶部２５５，アクション処理実行部２６０，画像生成部２６５，音響再生部２７０，判定部２７５および通信部２８０の機能ブロックにて示される各機能を有している。
【００９８】
媒体読取部２４５は，ＣＤ−ＲＯＭ４００等の記録媒体に記憶されたデータを読み込む。たとえば，プレイヤが，ＣＤ−ＲＯＭ４００をゲーム機２００に挿入してゲームをスタートすると，媒体読取部２４５は，自動的にそのプログラム等のデータを読み込み，ＲＡＭ２２０に転送するようになっている。
【００９９】
入力部２５０は，プレイヤが，モニタ４４５に表示されるネットワークゲームの画面を見ながら，ゲーム機２００に接続されたゲームコントローラパッド４３０，キーボード４３５，マウス４４０等の入力装置を操作すると，この操作に応じてデータを入力する。
【０１００】
記憶部２５５は，複数のキャラクタの位置情報を含んだキャラクタ情報をＲＡＭ２２０に記憶するとともに，ノンプレイヤキャラクタのうち自己のゲーム機２００が管理するキャラクタを管理キャラクタとしてＲＡＭ２２０に登録する。
【０１０１】
ここで，ＲＡＭ２２０に記憶される各情報について図７を参照しながら説明する。図７は，ＲＡＭ２２０に記憶されたキャラクタ情報のデータ構造の一例を示す。
【０１０２】
ＲＡＭ２２０には，まず，プレイヤキャラクタのうち，自ゲーム機器２００により管理される自プレイヤキャラクタ（自ＰＣ０）のＰＣデータが記憶される。ＲＡＭ２２０には，自ＰＣ０のキャラクタ情報として，ＰＣ番号，座標（ｘ，ｙ，ｚ），キャラクタの体の向き（角度），モーション番号，再生フレーム位置，進行方向，所属軍，管理中のキャラクタ数が保持される。
【０１０３】
ＰＣ番号には，自ＰＣ０を管理するゲーム機（ＣＬ，クライアント機器）の識別番号が付けられている。ここでは，ＰＣ番号として「０」が登録されているが，この番号は，そのＰＣを管理するゲーム機を識別できる情報であればこれに限られない。
【０１０４】
座標（ｘ，ｙ，ｚ）は，仮想空間上のキャラクタの位置を示す。モーション番号は，予め作成されたキャラクタの動作（モーション）を示すモーションデータの番号を示す。各モーションデータには，固有のモーション番号が付けられ，そのデータ自体は，各ゲーム機２００のハードディスク２１０等の記録媒体上に記録されている。
【０１０５】
キャラクタの動作は，フレーム（画像処理の時間的単位）毎に描画されるので，再生フレーム位置は，モーション番号に示されるモーションが再生されるフレームの位置を示す。進行方向は，キャラクタが進行する方向をベクトルで示したものである。所属軍は，自ＰＣ０が属する軍であり，現在は味方の「徳川」であるが，敵の軍に所属する場合もある。管理中のキャラクタ数は，自ゲーム機２００にて管理されている管理キャラクタ（ノンプレイヤキャラクタＮＰＣ）の数を示していて，７９以下の数値を取るようになっている。
【０１０６】
また，ＲＡＭ２２０には，自プレイヤキャラクタ（自ＰＣ０）を護衛する７９体の自ノンプレイヤキャラクタ（自ＮＰＣ１〜自ＮＰＣ７９）のキャラクタ情報が記憶される。ノンプレイヤキャラクタ（ＮＰＣ）のキャラクタ情報が，プレイヤキャラクタ（ＰＣ）のキャラクタ情報と異なる点は，プレイヤキャラクタ（ＰＣ）では，最後に「キャラクタ情報に管理中のキャラクタ数」が含まれていたのに対し，ノンプレイヤキャラクタ（ＮＰＣ）では，最後に「キャラクタ情報に管理元のＰＣ番号」が含まれている点である。たとえば，自ノンプレイヤキャラクタ１（自ＮＰＣ１）の管理元のＰＣ番号は，「０」である。これは，自ＮＰＣ１が，自ＰＣ０の管理キャラクタとしてＲＡＭ２２０に登録されていることを示している。
【０１０７】
また，ＲＡＭ２２０には，７体の他プレイヤキャラクタ（他ＰＣ１〜他ＰＣ７）のキャラクタ情報が記憶されるとともに，各他プレイヤキャラクタを各々護衛する他ノンプレイヤキャラクタ（他ＮＰＣ１−１〜他ＮＰＣ１−７９，他ＮＰＣ２−１〜他ＮＰＣ２−７９他，他ＮＰＣ３−１〜他ＮＰＣ３−７９，他ＮＰＣ４−１〜他ＮＰＣ４−７９，他ＮＰＣ５−１〜他ＮＰＣ５−７９，他ＮＰＣ６−１〜他ＮＰＣ６−７９，他ＮＰＣ７−１〜他ＮＰＣ７−７９）のキャラクタ情報が記憶されている。このようにして，ＲＡＭ２２０には，ゲームに登場するすべて（＝６４０体）のキャラクタのキャラクタ情報が記憶され，これらの情報を用いて，戦闘ゲーム中の各キャラクタが次にとるアクションが演算されたり，どのキャラクタを自ゲーム機２００にて管理しなければならないかが判定される。
【０１０８】
再び，図６に戻って，アクション処理実行部２６０は，演算部２６０ａ，画像処理部２６０ｂおよび音響処理部２６０ｃを有する。アクション処理実行部２６０は，記憶部２５５に登録されている各管理キャラクタのアクション処理を管理キャラクタ毎に実行する。具体的には，演算部２６０ａは，記憶部２５５に記憶されたキャラクタ情報を用いて，ゲーム上の戦闘によって発生する各管理キャラクタの位置の変化および動作の変化を表す変化量をそれぞれ演算することにより変化後のキャラクタ情報を生成する。
【０１０９】
画像処理部２６０ｂは，ゲームの進行に会わせて必要なパラメータとコマンドとを生成し，これらを画像生成部２６５に出力することにより，画像生成部２６５に画像の生成を指示する。画像生成部２６５は，画像処理部２６０ｂからの画像の生成の指示を受けて，画像を生成し,生成された画像をモニタ４４５に表示する。
【０１１０】
音響処理部２６０ｃは，音響再生部２７０にサウンドの再生を指示する。音響再生部２７０は，各管理キャラクタの戦闘動作に対応したバックミュージックや戦闘音等の音響処理を行い，スピーカ４５０に出力する。このようにして表現される臨場感あふれる画像や音響を通じて，プレイヤは，自分のプレイヤキャラクタをそのネットワークゲームの仮想空間内で移動させたり，他のキャラクタと戦わせることができる。
【０１１１】
判定部２７５は，演算部２６０ａにより演算された各管理キャラクタの位置の変化値に基づいて，自己のゲーム機２００が管理するプレイヤキャラクタの位置と，他のゲーム機２００が管理するプレイヤキャラクタの位置と，各管理キャラクタのアクション処理後の位置との相対関係を求め，求められた位置の相対関係に基づき各管理キャラクタを管理するか否かを判定する。
【０１１２】
通信部２８０は，演算部２６０ａにより演算された変化後の各管理キャラクタのキャラクタ情報をキャラクタ情報パケットとしてゲームサーバ１００に送信する。また，通信部２８０は，他のゲーム機２００により管理されると判定された管理キャラクタのキャラクタ情報をキャラクタ管理変更パケットとしてゲームサーバ１００に送信する。なお，同一内容であっても，本明細書及び図面中では，ＲＡＭ２２０等のメモリ内に保持しているデータの場合は「〜情報」と表記し，送受信するデータの場合は「〜パケット」と表記する。
【０１１３】
さらに，通信部２８０は，ゲームサーバ１００から送信されたキャラクタ情報パケットを受信する。すなわち，通信部２８０は，ネットワークゲーム内で起こった変動結果の情報や，他のプレイヤにより送信され，ゲームサーバ１００を介して転送される情報，或いはゲームサーバ１００が自発的に送信する情報等種々のデータを受信する。
【０１１４】
このようにして受信されたキャラクタ情報または演算部２６０ａにより演算されたキャラクタ情報に基づいて，アクション処理実行部２６０が，アクション処理を管理キャラクタ毎に実行することにより，ゲーム機２００とゲームサーバ１００とが逐次通信しながらネットワークゲームが進行するようになっている。
【０１１５】
なお，以上に説明したゲームサーバ１００およびゲーム機２００の各機能は，実際には，ＣＰＵがこれらの機能を実現する処理手順を記述したプログラムを実行することにより，または，いずれかの機能を実現するためのハードウエアやＩＣを制御することにより達成される。たとえば，図５に示したゲームサーバ１００の管理部１５５および画像処理部１６０の機能は，これらの機能を実現する処理手順を記述したプログラムを図３のＣＰＵ１１５が実行することにより達成され，画像生成部１６５の機能は，グラフィックチップ（画像生成回路１２７）により達成される。また，図６に示したゲーム機２００のアクション処理実行部２６０および判定部２７５の機能は，これらの機能を実現する処理手順を記述したプログラムを図４のＣＰＵ２１５が実行することにより達成され，画像生成部２６５および音響再生部２７０の機能は，グラフィックチップ（画像生成回路２２７）およびサウンドチップ（音響再生回路２２９）によりそれぞれ達成される。
【０１１６】
以上に説明した本実施形態にかかるネットワークゲームシステム１０では，まず，プレイヤが，自己のゲーム機２００を用いて自分が担当するプレイヤキャラクタを選択する。プレイヤキャラクタには，例えば戦国時代をテーマとしたゲームであれば，侍，忍者，陰陽師等があり，通常はこれらの中から１つを選択する。その後，プレイヤは，自分のプレイヤキャラクタを操作して戦闘することによりプレイヤキャラクタのレベルや能力等のパラメータを上昇させたり，ネットワーク３００を介して接続された他のゲーム機２００を操作する他のプレイヤのキャラクタと戦う。なお，この仮想空間に登場するキャラクタは，いわゆるプレイヤが操作するプレイヤキャラクタに限らず，各ゲーム機２００による自動的な演算により動作するノンプレイヤキャラクタ（ＮＰＣ）も存在し，これらのキャラクタが各ゲーム機２００の画面に表示される。
【０１１７】
（ゲーム機の動作，アクション処理およびキャラクタ管理処理）
つぎに，ゲーム機２００の動作について，図８〜図１０を参照しながら説明することにより，本実施形態の特徴であるアクション処理およびキャラクタ管理処理について詳述する。図８は，各ゲーム機２００が実行するクライアント側管理処理（メインルーチン）を示したフローチャートである。図９は，図８のメインルーチンにて呼び出されるキャラクタ管理処理を示したフローチャートである。図１０は，図９のサブルーチンにて呼び出されるキャラクタ変更判定処理を示したフローチャートである。なお，自プレイヤの小隊と他のプレイヤの小隊との動作に関しては同様な処理がなされるため，以下のフローチャートにおいては，説明を簡単にするために，自プレイヤの小隊を中心に記載し，他のプレイヤの小隊を中心とした記載を省略する。また，その他のゲーム上必要ではあるが本願発明と直接関係のない具体的な処理の説明は省略するものとする。
【０１１８】
また，このネットワークゲームを開始する前に，プレイヤは予めユーザ登録しておく必要がある。すなわち，プレイヤは，ゲーム機２００の画面に表示される指示に従って個人情報を入力することにより，ゲームサーバ１００に個人情報等を送信し，ユーザＩＤ及びパスワードを取得する。２回目以降にゲームを行うときには，プレイヤは，取得したユーザＩＤ及びパスワードを画面に入力するだけでゲームサーバ１００にアクセスすることができるようになる。
【０１１９】
（ゲームスタート）
ゲーム機２００の電源が「ＯＮ」され，プレイヤからゲームの開始が要求されると，図８のステップ８００から処理が開始され，ステップ８０５にて初期設定が行われる。具体的には，記憶部２５５は，プレイヤによって選択されたプレイヤキャラクタ（自ＰＣ）および各キャラクタのキャラクタ情報をＲＡＭ２２０に予め登録する。また，通信部２８０は，ユーザ認証し，その後，ゲームサーバ１００との間で各キャラクタのキャラクタ情報を送受信する。これにより，ゲームサーバ１００およびゲームに参加しているすべてのゲーム機２００のＲＡＭに，図７にて示した各キャラクタのキャラクタ情報が予め登録される。さらに，ゲームサーバ１００は，各キャラクタを管理するゲーム機２００をすべてのキャラクタについてそれぞれ特定し，ゲームサーバ１００および各ゲーム機２００のＲＡＭ（具体的には，図７に示した管理元のＰＣ番号の項目）に記憶する。なお，ゲームサーバ１００には，必ずしも，各キャラクタのキャラクタ情報を記憶しておく必要はない。
【０１２０】
つぎに，ステップ８１０にて，判定部２７５は，割込み（垂直帰線割込（Ｖｓｙｎｃ））が発生したか否かを判定する。判定部２７５は，モニタ４４５の垂直帰線周期と一致した１／６０秒（１６．６ミリ秒）に一度の周期で割込みが発生すると，これに応じて，ステップ８１０にて「ＹＥＳ」と判定し，ステップ８１５に進んでキャラクタ管理処理を実行する。キャラクタ管理処理については後述する。
【０１２１】
つぎに，判定部２７５は，ステップ８２０に進んでゲームが終了か否かを判定する。具体的には，プレイヤが，ゲーム機２００の電源を「ＯＦＦ」するか，または，画面上のゲーム終了を選択することによりゲームは終了する。そこで，プレイヤがこれらのいずれかの操作をするまで，ゲーム機２００は，基本的に，ステップ８１０〜ステップ８２０の処理を繰り返し，プレイヤがこれらのいずれかの操作をするとステップ８９５に進んでゲームを終了する。
【０１２２】
ステップ８１０で割込みが発生していない場合，判定部２７５は，「ＮＯ」と判定してステップ８２５でメイン処理を実行し，その後ステップ８２０に進む。このメイン処理においては，本実施形態におけるネットワークゲームと直接関係しないその他の処理，例えば，プレイヤがコントローラパッド４３０等を操作することにより入力され，入力部２５０を介して取り込まれた入力情報を，ＲＡＭ２２０に記憶して随時更新する処理や，ゲーム効果音を音響処理部２６０ｃおよび音響再生部２７０を用いて合成させるための音響処理等の処理も，ここで実行するものとする。また，本実施形態では，一定間隔でクライアント側管理処理が行われる例（すなわち，垂直帰線周期の割込処理内でキャラクタ管理処理が行われる例）を示したが，図示しないタイマー割込処理内やステップ８２５のメイン処理内でキャラクタ管理処理が行われるようにしてもよい。
【０１２３】
（キャラクタ管理処理）
つぎに，ステップ８１５のキャラクタ管理処理について，図９のフローチャートを参照しながら説明する。ステップ９００から処理が開始されると，通信部２８０は，ステップ９０５にて，他のゲーム機２００から送信されたキャラクタ管理変更パケットを受信したか否かを判定する。キャラクタ管理変更パケットを受信した場合には，ステップ９１０に進んで，記憶部２５５は，キャラクタ管理変更パケットに含まれるキャラクタ情報に基づきＲＡＭ２２０の該当キャラクタ情報を更新する。具体的には，図７の該当ＰＣまたは該当ＮＰＣに記憶された座標，体の向き，モーション番号，再生フレーム位置，進行方向，所属軍の情報を更新する。また，記憶部２５５は，このキャラクタ情報により特定されるキャラクタを管理キャラクタとしてＲＡＭ２２０に登録する。具体的には，図７の該当キャラクタ情報の管理元のＰＣ番号を変更する。
【０１２４】
つぎに，ステップ９１５に進み，通信部２８０は，ステップ９１５にて，他のゲーム機２００からキャラクタ情報パケットを受信したか否かを判定する。キャラクタ情報パケットを受信した場合には，ステップ９２０に進んで，記憶部２５５は，キャラクタ情報パケットに含まれるキャラクタ情報に基づきＲＡＭ２２０の該当キャラクタ情報を更新する。具体的には，図７の該当ＰＣまたは該当ＮＰＣに記憶された座標，体の向き，モーション番号，再生フレーム位置，進行方向，所属軍の情報を更新する。なお，フレームとは，画像処理の時間的単位であり，描画の際のいわゆる「コマ」を示している。本実施形態では，１フレームの時間は，垂直帰線割込処理の周期の１／２の時間（１／３０秒）に相当する。
【０１２５】
ついで，ステップ９２５に進んで，アクション処理実行部２６０は，アクション処理を実行する。アクション処理とは，具体的には，アクション処理実行部２６０の各部により実行されるつぎの処理をいう。まず，演算部２６０ａは，ＲＡＭ２２０に記憶されたキャラクタ情報（具体的には，自ゲーム機の管理キャラクタ情報および他ゲーム機の管理キャラクタ情報の相対関係）に基づき，プレイヤの操作に応じて各管理キャラクタの位置の変化量および動作の変化量を含んだキャラクタ情報を演算する。管理キャラクタ毎にこの演算を行うことにより，各キャラクタは，攻撃が当たったらダメージモーションに移行するなどのアクションを行うことができる。
【０１２６】
また，画像処理部２６０ｂは，画像生成部２６５に画像の生成を指示し，画像生成部２６５は，これを受けて，演算後のキャラクタ情報に基づいて各キャラクタの仮想空間上の位置および動作をグラフィック処理する。また，音響処理部２６０ｃは，音響再生部２７０に音響の生成を指示し，音響再生部２７０は，これを受けて，演算後のキャラクタ情報に基づいて各キャラクタの状態にあった音響を生成する。この結果，各プレイヤの操作に応じたキャラクタの動作がモニタ４４５に表示されると同時に，ゲームの展開に応じた音響がスピーカ４５０から出力されることにより，各プレイヤの操作に応じたゲームが展開される。
【０１２７】
つぎに，ステップ９３０に進み，判定部２７５は，キャラクタ変更判定処理（サブルーチン）を実行する。この処理は，各管理キャラクタの位置と敵ＰＣおよび味方ＰＣおよび自ＰＣの位置との関係から当該キャラクタが管理されるべきゲーム機２００を判定する処理であるが，後程詳述する。
【０１２８】
ついで，ステップ９３５に進み，通信部２８０が，演算部２６０ａにより演算された各管理キャラクタのキャラクタ情報を，ゲームサーバ１００を介して他のゲーム機２００に送信する。このように最新のキャラクタの状態を他のゲーム機２００に送信することにより，通信時間だけ遅延が生じた状態ではあるが，他のゲーム機２００に記憶された各キャラクタのキャラクタ情報が更新される。これにより，データの整合性を保つことができる。
【０１２９】
（キャラクタ変更判定処理）
つぎに，ステップ９３０に示したキャラクタ変更判定処理について，図１０を参照しながら，詳細に説明する。
ステップ１０００からキャラクタ変更判定処理が開始され，ステップ１００５に進むと，演算部２６０ａは，管理キャラクタとして登録されているＮＰＣ（図７の該当ＮＰＣの座標）と最寄の敵ＰＣ（図７の該当敵ＰＣの座標）との距離ＤＥＰＣを求める。たとえば，図１１に示したように，自ＰＣ１の小隊が，敵ＰＣ３の小隊を攻撃するために，敵ＰＣ３の小隊に向かっている場合，ステップ１００５では，図１２に示したように，当該ＮＰＣ（ＮＰＣ１１）と敵ＰＣ３との距離ＤＥＰＣが演算される。
【０１３０】
つぎに，ステップ１０１０に進み，判定部２７５は，ＮＰＣ１１を管理するゲーム機２００（この時点では自ゲーム機）のＰＣ（すなわち，自ＰＣ１）が，ＮＰＣ１１の味方であるか否かを判定する。この時点では，自ＰＣ１は，ＮＰＣ１１の味方であるので，判定部２７５は，ステップ１０１５に進み，距離ＤＥＰＣがマージンＭＣ（＝５０）より小さいか否かを判定する。この時点では，ＰＣ３は，ＮＰＣ１１を中心とした半径がマージンＭＣの円内まで近づいていないので，距離ＤＥＰＣはマージンＭＣより大きい。そこで，ステップ１０２０に進んで，演算部２６０ａは，ＮＰＣ１１と自ＰＣ１との距離Ｄを求め，ステップ１０２５にて，ＮＰＣ１１と最寄の味方ＰＣ（＝ＰＣ２）との距離ＤＡＰＣを求める。
【０１３１】
つぎに，ステップ１０３０に進んで，判定部２７５は，距離ＤＡＰＣにマージンＭＤ（＝５０）を加算した値が距離Ｄより小さいか否かを判定する。この時点で，距離ＤＡＰＣ＋マージンＭＤの値は距離Ｄより大きい。すなわち，ＰＣ２は，ＮＰＣ１１を中心とした半径が（距離Ｄ−マージンＭＤ）の円内まで近づいていない。そこで，判定部２７５は，（ＮＰＣ１１の管理を他のユーザ機２００に変更することなく），ステップ１０３５に進み，管理中のすべてのＮＰＣ（すなわち，管理キャラクタ）についてキャラクタ変更判定処理を実行するまで，ステップ１００５に戻って各管理キャラクタの変更判定処理を続け，すべての管理キャラクタについて，この変更判定処理を終えると，ステップ１０９５にて本処理を終了する。
【０１３２】
つぎに，図１１に示したＰＣ２の小隊のみが，ＰＣ１の小隊に接近した場合のキャラクタ変更判定処理について説明する。このとき，図１３に示したように，味方ＰＣ２は自ＰＣ１よりマージンＭＤ以上ＮＰＣ１１の近くに位置しているので，判定部２７５は，ステップ１０００〜ステップ１０２５に続くステップ１０３０にて「ＹＥＳ」と判定し，ステップ１０４０に進んで，味方ＰＣ管理変更処理を実行する。
【０１３３】
（味方ＰＣ管理変更処理）
具体的には，図１４に示したように，判定部２７５は，ステップ１４００から味方ＰＣ管理変更処理を開始して，ステップ１４０５に進み，最寄の味方ＰＣ（＝ＰＣ２）と当該ＮＰＣ（＝ＮＰＣ１１）を管理しているゲーム機２００のＰＣ（＝ＰＣ１）とが，同一か否かを判定する。ここでは同一でないので，判定部２７５は，ステップ１４１０に進んで，最寄の味方ＰＣ（＝ＰＣ２）のゲーム機が管理している管理キャラクタ数が７９以上であるか否かを判定する。ＰＣ２を管理しているゲーム機が管理している管理キャラクタ数が７９より少ないと，記憶部２５５は，ステップ１４１５に進んで，ＲＡＭ２２０に記憶されているＰＣ２に関するキャラクタ情報のうち，管理中のキャラクタ数を１つ増やし，ステップ１４２０に進んで，現時点でＮＰＣ（＝ＮＰＣ１１）を管理しているゲーム機（ＣＬ）により管理されているＰＣ（＝ＰＣ１）の管理中のキャラクタ数を１つ減らす。
【０１３４】
ついで，ステップ１４２５に進んで，通信部２８０は，当該ＮＰＣ（＝ＮＰＣ１１）の管理を，ＰＣ１を管理するゲーム機２００からＰＣ２を管理するゲーム機２００に変更する情報を含んだ管理変更パケットを，ゲームサーバ１００を介して他のゲーム機２００に送信し，ステップ１４９５に進んで本処理を終了する。このように，味方ＰＣ２が自ＰＣ１よりマージンＭＤ以上ＮＰＣ１１の近くに位置している場合，敵ＰＣ２を管理するゲーム機が，ＮＰＣ１１（管理キャラクタ）を管理するように管理キャラクタが切り替わる。
【０１３５】
なお，ステップ１４０５にて，最寄の味方ＰＣと当該ＮＰＣを管理しているゲーム機２００のＰＣとが同一の場合には，管理キャラクタの管理変更を行う必要がなく，また，ステップ１４１０にて，最寄の味方ＰＣのゲーム機２００が管理している管理キャラクタ数が７９以上である場合には，そのゲーム機が管理する管理キャラクタをこれ以上増やすことが適当でないので，いずれも当該管理キャラクタを変更することなく，ステップ１４９５に進んで本処理を終了する。
【０１３６】
つぎに，図１１の状態から図１５の状態にゲームが展開した場合（すなわち，自ＰＣ１の小隊と敵ＰＣ３の小隊と味方ＰＣ２の小隊とが集団戦闘状態にある場合）のキャラクタ変更判定処理について説明する。この場合，図１６に示したように，ＮＰＣ１１には味方ＰＣ２が最も近接しているが，敵ＰＣ３もＮＰＣ１１を中心とした半径がマージンＭＣの円内に存在する。このとき，図１０のステップ１０００からキャラクタ変更判定処理を開始して，判定部２７５は，ステップ１００５，ステップ１０１０に続くステップ１０１５にて「ＹＥＳ」と判定し，ステップ１０４５に進んで，敵ＰＣ管理変更処理を実行する。
【０１３７】
（敵ＰＣ管理変更処理）
具体的には，図１７に示したように，判定部２７５は，ステップ１７００から敵ＰＣ管理変更処理を開始して，ステップ１７０５に進み，最寄の敵ＰＣ（＝ＰＣ３）と当該ＮＰＣ（＝ＮＰＣ１１）を管理しているゲーム機２００のＰＣ（＝ＰＣ１）とが，同一か否かを判定する。ここでは同一でないので，判定部２７５は，ステップ１７１０に進んで，最寄の敵ＰＣ（＝ＰＣ３）のゲーム機が管理している管理キャラクタ数が７９以上であるか否かを判定する。ＰＣ３を管理しているゲーム機が管理している管理キャラクタ数が７９より少ないと，ステップ１７１５に進んで，記憶部２５５は，ＲＡＭ２２０に記憶されているＰＣ３に関するキャラクタ情報のうち，管理中のキャラクタ数を１つ増やし，ステップ１７２０に進んで，現時点でＮＰＣ（＝ＮＰＣ１１）を管理しているゲーム機により管理されているＰＣ（＝ＰＣ１）の管理中のキャラクタ数を１つ減らす。
【０１３８】
ついで，ステップ１７２５に進んで，通信部２８０は，当該ＮＰＣ（＝ＮＰＣ１１）の管理を，ＰＣ１を管理するゲーム機２００からＰＣ３を管理するゲーム機２００に変更する情報を含んだ管理変更パケットを，ゲームサーバ１００を介して他のゲーム機２００に送信し，ステップ１７９５に進んで本処理を終了する。このように，ＮＰＣ１１に対して，味方ＰＣ２および敵ＰＣ３の両方が近接した場合，敵ＰＣ３を管理するゲーム機が，味方ＰＣ２を管理するゲーム機より優先してＮＰ１３１（管理キャラクタ）を管理するように管理キャラクタが切り替わる。
【０１３９】
なお，図１４の味方ＰＣ管理変更処理と同様に，ステップ１７０５またはステップ１７１０にて「ＹＥＳ」と判定された場合には，いずれも当該管理キャラクタを変更することなく，ステップ１７９５に進んで本処理を終了する。
【０１４０】
この時点では，図１５に示したように，ＮＰＣ１１の管理はＰＣ３に切り替わっている。同様にして，ＰＣ３を管理するゲーム機２００が，垂直帰線割込み毎に図１０に示したキャラクタ変更判定処理を実行することによりＮＰＣ３１の管理がＰＣ１に切り替わった（ＰＣ１を管理するゲーム機２００のＲＡＭ２２０にＮＰＣ３１が管理キャラクタとして登録された）後，ゲームが図１８に示した状態に展開した場合（すなわち，ＰＣ１がＰＣ３に接近した（図１５）後，ＰＣ３から少し遠ざかった（図１８）場合）について，つぎに説明する。
【０１４１】
この場合，ＮＰＣ３１，自ＰＣ１，味方ＰＣ２および敵ＰＣ３との関係は図１９に示したようになる。この状態で，図１０のキャラクタ変更判定処理が実行されると，ステップ１０００，１００５に続くステップ１０１０にて，判定部２７５は，ＮＰＣ３１は，ＮＰＣを管理するゲーム機が操作するＰＣ（＝ＰＣ１）の敵であると判定する。そこで，ステップ１０５０に進み，演算部２６０ａは，ＮＰＣ３１とＰＣ１との距離Ｄを求める。続いて，ステップ１０５５にて，判定部２７５は，距離ＤＥＰＣにマージンＭＡを加算した値が距離Ｄより小さいか否かを判定する。この時点では，距離ＤＥＰＣ＋マージンＭＡの値は距離Ｄより大きい。そこで，ステップ１０６０に進み，演算部２６０ａは，ＮＰＣ３１と最寄の味方ＰＣ（＝ＰＣ２）との距離ＤＡＰＣを求める。
【０１４２】
つぎに，ステップ１０６５に進んで，判定部２７５は，距離ＤＡＰＣにマージンＭＢを加算した値が距離Ｄより小さいか否かを判定する。この時点では，距離ＤＡＰＣ＋マージンＭＢの値は距離Ｄより大きい。そこで，ステップ１０３５に進み，ＲＡＭ２２０に登録されているすべての管理キャラクタの処理を終えるまでステップ１００５に戻って各管理キャラクタの変更判定処理を実行する。
【０１４３】
つぎに，図２０に示したように，ＮＰＣ３１に対して味方ＰＣ２および敵ＰＣ３が近接した場合であって，敵ＰＣ３は自ＰＣ１よりマージンＭＡ以上ＮＰＣ３１の近くに位置している場合について説明する。この状態で，図１０のキャラクタ変更判定処理が実行されると，ステップ１０００〜１０１０，ステップ１０５０に続くステップ１０５５にて，判定部２７５は，「ＹＥＳ」と判定し，ステップ１０７０に進んで，図１７の敵ＰＣ管理変更処理を実行する。すなわち，ステップ１７００〜１７２５を実行することにより，ＮＰＣ３１の管理が，ＰＣ１を管理するゲーム機２００からＰＣ３を管理するゲーム機２００に切り替わる。このように，ＮＰＣ３１に対して味方ＰＣ２および敵ＰＣ３の両方が近接した場合であって，敵ＰＣ３が自ＰＣ１よりマージンＭＡ以上ＮＰＣ３１の近くに位置している場合，敵ＰＣ３を管理するゲーム機が，味方ＰＣ２を管理するゲーム機より優先してＮＰＣ３１（管理キャラクタ）を管理するように管理キャラクタが切り替わる。
【０１４４】
一方，ゲームの状態が，図１９の状態から図２１の状態（すなわち，敵ＰＣ３が自ＰＣ１よりマージンＭＡ以上ＮＰＣ３１の近くに位置していない場合であって，かつ，味方ＰＣ２が自ＰＣ１よりマージンＭＢ以上ＮＰＣ３１の近くに位置している状態）に遷移した場合について説明する。この状態で，図１０のキャラクタ変更判定処理が実行されると，ステップ１０００〜１０１０，ステップ１０５０〜１０６０に続くステップ１０６５にて，判定部２７５は，「ＹＥＳ」と判定し，ステップ１０４０に進んで，図１４の味方ＰＣ管理変更処理を実行する。すなわち，ステップ１４００〜１４２５を実行することにより，ＮＰＣ３１の管理が，ＰＣ１を管理するゲーム機２００からＰＣ２を管理するゲーム機２００に切り替わる。
【０１４５】
（マージンの設定）
以上に説明した図１０のキャラクタ変更判定処理では，当該ＮＰＣの管理を切り替える対象となるＰＣ（敵ＰＣ，味方ＰＣ）毎に所定のマージン（マージンＭＡ，ＭＢ，ＭＣ，ＭＤ）を設けた。これは，他のゲーム機２００が管理するＰＣの位置が自ＰＣの管理キャラクタ（当該ＮＰＣ）に最も近い場合であっても，自己のゲーム機２００が管理するプレイヤキャラクタの位置より所定距離以上上記各管理キャラクタの近くに位置しない限り，判定部２７５は，自己のゲーム機２００がその管理キャラクタを管理すると判定するようにして，管理権を切り替える境界付近での管理権の切り替えが頻繁に発生しないように考慮したものである。特に，集団戦闘ゲームは，アクションゲームなので微妙な位置の変化が極めて頻繁に発生するため，管理権の切り替えが頻繁に発生しないように制御することは処理全体の負荷を軽減し，スムーズにゲームを進行させるために非常に重要である。
【０１４６】
また，マージンＭＡに比べて，マージンＭＢ，マージンＭＣ，マージンＭＤの値を大きくしたのは，マージンＭＡの場合は，ステップ１０５５にて，判定対象としている管理キャラクタ（当該ＮＰＣ）と敵ＰＣとの距離と，当該ＮＰＣと自ＰＣとの距離と，を比較処理しているので，マージンを比較的短く設定して，当該ＮＰＣの管理を優先的に敵ＰＣに与えるようにするためである。すなわち，判定部２７５は，優先的にステップ１０５５にて「ＹＥＳ」と判定し，ステップ１０７０にて敵ＰＣに当該ＮＰＣの管理を変更する処理を実行する。
【０１４７】
一方，マージンＭＢ，マージンＭＤの場合は，ステップ７１０６５およびステップ１０３０にて，それぞれ判定対象としている管理キャラクタ（当該ＮＰＣ）と味方ＰＣとの距離と，当該ＮＰＣと自ＰＣとの距離と，を比較処理しているので，マージンを比較的長く設定して，当該ＮＰＣの管理をなるべく味方ＰＣに与えないようにするためである。すなわち，判定部２７５は，優先的にはステップ１０３０およびステップ１０６５にて「ＹＥＳ」と判定せず，なるべく当該ＮＰＣの管理を味方ＰＣ変更しないように処理を実行する。
【０１４８】
また，マージンＭＣの場合は，他のゲーム機２００が管理するＰＣが，管理キャラクタ（当該ＮＰＣ）および自ゲーム機２００が管理する自ＰＣの敵であって，その他のゲーム機２００が管理する敵ＰＣが当該ＮＰＣの一定範囲内（＝マージンＭＣ）に位置する場合には，求められた位置の相対関係（すなわち，自ＰＣと当該ＮＰＣと敵ＰＣとの相対位置）にかかわらず，他のゲーム機２００が当該ＮＰＣを管理させるためである。すなわち，敵ＰＣが当該ＮＰＣの一定範囲内（＝マージンＭＣ）に位置する場合には，判定部２７５は，ステップ１０１５にて「ＹＥＳ」と判定してステップ１０４５にて優先的に敵ＰＣに当該ＮＰＣの管理を変更するように判定する。
【０１４９】
また，マージンＭＢの値をマージンＭＣの値より大きくしたのは，以下の理由による。前述したように，集団戦闘ゲームは，アクションゲームなので微妙な位置の変化が極めて頻繁に発生する。また，実際の処理では，キャラクタの位置は，小数点以下も含めた数値で演算されるので，画面上，全く移動せず待機しているように見えるキャラクタであっても，実は，常に僅かに移動していると判定される場合が非常に多い。より詳しく述べると，ある地点から仮想空間上にて５０ｍ離れた位置に立っているキャラクタは，処理上は，常に，４９．９ｍ〜５０．１ｍといった位置を揺れ動いている。プレイヤが，自ＰＣを操作すると，その幅はいっそう大きくなり，このような状況で，ある地点から５０ｍの位置で自ＰＣの小隊と敵ＰＣの小隊とが戦っていると，非常に多数のキャラクタが，極めて頻繁に５０ｍ前後の位置を揺れ動くことになる。
【０１５０】
このような状況で，たとえば，マージンＭＢとマージンＭＣとを同じ値（＝５０）に設定すると，に管理キャラクタの切り替えが多発してしまう。具体的には，当該ＮＰＣと自ＰＣとが味方であって，最寄の敵ＰＣと当該ＮＰＣとの距離ＤＥＰＣが４９であった場合，判定部２７５は，ステップ１００５，ステップ１０１０に続くステップ１０１５にて「ＹＥＳ」と判定してステップ１０４５にて敵ＰＣに当該ＮＰＣの管理を変更する。その後，敵ＰＣが当該ＮＰＣから少し離れ，距離ＤＥＰＣが５１になると，判定部２７５は，ステップ１００５，ステップ１０１０，ステップ１０５０〜ステップ１０６０に続くステップ１０６５にて「ＹＥＳ」と判定してステップ１０４０にて味方ＰＣに当該ＮＰＣの管理を変更する。その後，敵ＰＣが当該ＮＰＣに少し近づき，再び，最寄の敵ＰＣと当該ＮＰＣとの距離ＤＥＰＣが４９になった場合，判定部２７５は，ステップ１０１５にて再び「ＹＥＳ」と判定してステップ１０４５にて敵ＰＣに当該ＮＰＣの管理を変更する。このような頻繁なキャラクタ管理の切り替えを防止するために，マージンＭＢの値をマージンＭＣと異なる値に設定している（すなわち，マージンＭＢ＝６０，マージンＭＣ＝５０）。
【０１５１】
（ゲームサーバの動作）
つぎに，ゲームサーバ１００の動作について説明する。ゲームサーバ１００は，図２２のフローチャートを示したように，ステップ２２００から処理を開始して，ステップ２２０５にて，キャラクタ管理変更パケット，および／または，キャラクタ情報パケットを受信したか否かを判定する。これらのパケットを受信している場合，ゲームサーバ１００は，ステップ２２１０にて，各ゲーム機２００から送信されたキャラクタ管理変更パケット，および／または，キャラクタ情報パケットを送信元のゲーム機２００以外のすべてのゲーム機２００に送信し，ステップ２２９５に進んで本処理を終了する。なお，前述したように，ゲームサーバ１００の記憶部１５０には，各キャラクタのキャラクタ情報を記憶する必要はないが，記憶してもよい。
【０１５２】
以上，本実施形態に係るネットワークゲームシステムによれば，格闘ゲームにおいて即時性が要求される「アクション処理」をユーザ側の端末であるゲーム機（クライアント側）で行う。また，本システムでは，ノンプレイヤキャラクタは，いずれかのゲーム機２００により管理される。このため，ゲームサーバ１００に処理の負荷が集中せず，システム全体に処理を負荷分散することができる。このため，プレイヤは，通信遅延を感じることなく，リアルタイム性の高い迫力あるゲームを楽しむことができる。
【０１５３】
また，本システムでは，管理キャラクタであるＮＰＣの所定距離内に敵ＰＣが存在する乱戦時には，その敵ＰＣを管理するゲーム機が，優先してＮＰＣを管理するように制御され，それ以外の場合（敵ＰＣが所定距離外にいる場合，所定距離外に味方ＰＣがいる場合，または，所定距離内に何もいない場合）には，最短となる別なＰＣが現れたら，敵味方に関係なく，管理権がそのＰＣに変更される。
【０１５４】
このように，優先的に敵を管理する方がネットワークゲームにおいての通信遅延を感じる機会を少なくできる。つまり，本実施形態にかかるネットワークゲームシステム１０では，ＰＣ同士が近づいた乱戦時には，自ＰＣを管理するゲーム機は，まず，敵ＮＰＣを優先して管理する。このとき敵味方だけで判断できない場合（同一陣営のＰＣが近くに複数いる場合など）は距離によってＮＰＣをどのゲーム機に管理させるかを判断する。また，ＰＣ同士が離れた場合には，敵味方に関係なく距離だけでＮＰＣをどのゲーム機に管理させるかが判断される。
【０１５５】
原則的に，自ＰＣは，近傍の敵ＮＰＣと戦い，近傍の味方ＮＰＣとは戦わないので，自ＰＣを管理するゲーム機は，自ＰＣと近傍の敵ＮＰＣとの間で頻繁に演算処理が発生する。したがって，前述したキャラクタ管理方法によって，敵ＮＰＣを優先的に自ＰＣを管理するゲーム機２００に管理させることにより，頻繁に発生する演算処理を自ゲーム機内で処理することができる。同一ゲーム機内で管理されているキャラクタ同士はネットワーク通信を行わずに処理が行えるので，敵ＮＰＣを優先して管理することにより通信の遅延時間を少なくすることができる。この結果，各プレイヤの操作に応じて即座に画面上のキャラクタのモーションが変わり，プレイヤは，敵の護衛兵（ＮＰＣ）との戦闘は実質スタンドアローンのように早く感じるため，よりゲームに没頭して楽しむことができる。
【０１５６】
なお，クライアント処理（ゲーム機側の処理）では，ＲＡＭ等のメモリ内に保持するデータとして，各ゲーム機が管理するすべての自ＮＰＣ＋自ＰＣ（すなわち，自小隊）のキャラクタ情報ではなく，他のゲーム機が管理するキャラクタを含めた全キャラクタのキャラクタ情報を記憶した。この理由は，たとえば，他のゲーム機が管理するものも自己の画面に表示される可能性があり，少なくともそのキャラクタ情報のうちの最新座標データ等を記憶しておかなければデータの整合が取れないためである。ここで，全キャラクタの最新座標の記憶更新管理に関して，自己が管理する全自ＮＰＣ＋自ＰＣについては，各ゲーム機２００内でキー入力等に対する変化量から最新座標を直接計算して記憶更新した後に，ゲームサーバ１００経由で他のゲーム機２００に送信して整合を取るため，最新座標の更新処理が速くなると考えられるが，他のゲーム機２００が管理するものについては，他のゲーム機で算出した最新座標をゲームサーバ１００経由で受信した後に記憶更新されることにより整合をとるので，通信遅延が生じて遅くなると考えられる。
【０１５７】
しかしながら，本実施形態にかかる発明のポイントは，近接した敵ＮＰＣを含む自己が管理するＮＰＣへの処理を速くする点であるからこの遅れによる直接的な影響はなく，また全キャラクタの状態情報を各ゲーム機で記憶すること自体の見た目への影響はないものと考えられる。この理由は，通常このような集団戦闘ゲームでは自ＰＣを画面中央からやや下側に表示するので（このとき各ゲーム機での視界，即ち視点カメラの位置と角度は各自，自動的に適切な数値に設定される），経験則上，実際にプレイヤが注目する自小隊の戦闘場面での処理が速ければ，それ以外の他のゲーム機が管理している他小隊が表示される部分，即ち周囲の部分の表示が多少遅くても気にならないと考えられるからである。
【０１５８】
（第２実施形態）
つぎに，第２実施形態にかかるネットワークゲームシステム１０について説明する。第２実施形態にかかるネットワークゲームシステム１０は，キャラクタ変更判定処理をゲームサーバ１００側で実行する点で，キャラクタ変更判定処理をゲーム機２００側で実行する第１実施形態と動作上異なる。よって，この相違点を中心に本実施形態にかかるネットワークゲームシステムについて説明する。
【０１５９】
（ゲーム機の動作）
本実施形態では，図８のクライアント側管理処理のうち，ステップ８１５で呼び出されるキャラクタ管理処理を図２３のステップ２３００から開始し，ステップ９０５〜ステップ９２５の処理後，第１実施形態の場合に実行した図９のステップ９３０のキャラクタ変更判定処理を行うことなく，ステップ９３５を処理してステップ２３９５に進んで本処理を終了する。このように，本実施形態では，各ゲーム機２００は，アクション処理を実行するが，キャラクタ変更判定処理を実行しない。
【０１６０】
(ゲームサーバの動作)
一方，本実施形態では，ゲームサーバ１００は，図７に示した各キャラクタのキャラクタ情報をＲＡＭ１２０に予め記憶する。すなわち，ゲームサーバ１００にてキャラクタ管理変更判定をする場合，図７に示したキャラクタ情報は，ゲームサーバ１００および各ゲーム機器２００のＲＡＭにそれぞれ保持される。
【０１６１】
ゲームサーバ１００は，図２４にフローチャートを示したように，ステップ２４００から処理を開始して，ステップ２４０５にて，キャラクタ情報パケットを受信したか否かを判定する。これらのパケットを受信している場合，ゲームサーバ１００は，ステップ２４１０にて，各ゲーム機２００から送信されたキャラクタ情報パケットに含まれるキャラクタ情報にて，図７に示したように，ＲＡＭ１２０に記憶されたキャラクタのうち，該当するキャラクタのキャラクタ情報を更新し，そのキャラクタ情報パケットを送信元のゲーム機２００以外のすべてのゲーム機２００に送信した後，ステップ２４１５に進んで，図１０のキャラクタ変更判定処理を実行し，ステップ２４９５に進んで本処理を終了する。なお，第１実施形態では，すべてのノンプレイヤキャラクタ（ＮＰＣ）のうち，各ゲーム機２００が管理する管理キャラクタ毎に，図１０のキャラクタ変更判定処理を繰り返していた。しかし，本実施形態では，すべてのノンプレイヤキャラクタ（ＮＰＣ）について，キャラクタ変更判定処理を繰り返す必要がある。
【０１６２】
本実施形態にかかるネットワークゲームシステム１０によれば，ゲームサーバ１００側で，すべてのキャラクタが管理される。これによれば，ゲームサーバ１００から各ゲーム機２００までの距離や各ゲーム機２００の性能その他の通信環境が同一の場合で且つ通信障害が発生しない場合，各ゲーム機２００で生じる処理の遅延は，理論上ほぼ同時と考えられる。このため，画面上の多数のキャラクタが不自然に動作することがない。また，すべてのキャラクタ管理をゲームサーバ１００側で行うため，正確かつ簡易にデータの整合性を保つことができる。
【０１６３】
さらに，上記の様に通信環境が同一の場合，本実施形態にかかるキャラクタ管理の切り替えのための遅延時間は，ゲームサーバ１００からゲーム機２００の通信時間のみであるため，本実施形態のシステムでは，ゲーム機２００側でキャラクタ管理処理を実行する第１実施形態の場合と比べ，第１実施形態の他のゲーム機２００に生じる切り替え時間の半分しか遅延しないという利点がある。
【０１６４】
以上に説明したように，上記各実施形態にかかるネットワークゲームシステム１０によれば，「キャラクタ毎に管理するゲーム機を決めて，アクション処理を各ゲーム機２００に振り分ける」，「他のゲーム機にて管理されている管理キャラクタの映像が少し遅れて自ゲーム機に表示される」，「他のゲーム機にて管理されている管理キャラクタの映像から自ゲーム機にて管理されている管理キャラクタが影響を及ぼされる」という巧妙な制御により，自ゲーム機２００が管理するキャラクタ同士のアクションの結果が即座に画面上に反映されるという状況を作り出すことができる。これは，非常に多数のキャラクタが複数の小隊を作って集団戦闘するネットワークゲームに特に有効である。
【０１６５】
なお，上記各実施形態において，最寄のＰＣは，総当りで距離を比較することにより算出される。
【０１６６】
また，以上のキャラクタ変更管理処理では，管理キャラクタ（ＮＰＣ）を中心として各ＰＣとの相対距離関係を算出し，算出した関係に基づきキャラクタの管理を変更するか否かが判定されていた。しかし，各実施形態にかかるキャラクタ変更管理処理は，各ＰＣを中心としてある所定範囲内に存在するＮＰＣを管理キャラクタとして管理するようにしてもよい。
【０１６７】
（ＰＣを中心としたキャラクタ管理）
実際には，たとえば，各ゲーム機２００の判定部２７５は，演算部２６０ａにより演算された各管理キャラクタの位置の変化に基づいて，自ゲーム機２００により管理されるプレイヤキャラクタ（自ＰＣ）から第１の所定範囲内に位置する１または２以上のノンプレイヤキャラクタ（ＮＰＣ）を，自ゲーム機２００が管理キャラクタとして管理すると判定してもよい。
【０１６８】
このようにＰＣを中心としたキャラクタ管理処理を実行する場合，判定部２７５は，他のゲーム機２００により管理されるプレイヤキャラクタ（他ＰＣ）とノンプレイヤキャラクタ（ＮＰＣ）との関係が敵味方であって，自ゲーム機２００により管理されるＰＣ（自ＰＣ）と当該ＮＰＣとの関係が味方同士の場合には，ノンプレイヤキャラクタ（ＮＰＣ）が自ゲーム機２００により管理されるＰＣから上記第１の所定範囲内に位置していても，上記敵のＰＣから第２の所定範囲内に位置するときには，上記他のゲーム機２００が当該ＮＰＣを管理すると判定するようにしてもよい。また，上記第１の所定範囲は，上記第２の所定範囲より小さくなるように設定してもよい。
【０１６９】
また，ＰＣから所定範囲内に予め定められた所定数以上のＮＰＣが存在するとき，当該所定数のＮＰＣの管理を切り替えるようにしてもよい。また，ＰＣから所定範囲内に所定数以上のＮＰＣが存在してから，所定時間経過後にＮＰＣの管理を切り替えるようにしてもよい。
【０１７０】
これによれば，ＮＰＣと敵ＰＣと自ＰＣとが近傍に位置する戦闘体制において，ＮＰＣを優先的に敵ＰＣを管理するゲーム機２００に管理させることができ，この結果，ゲーム全体の処理をスムーズに進行させることができる。
【０１７１】
（第３実施形態）
つぎに，第３実施形態にかかるネットワークゲームシステム１０について説明する。第３実施形態にかかるネットワークゲームシステム１０では，第１実施形態にて説明したように，原則として，自小隊に属する自ＰＣおよびＮＰＣは，自己のゲーム機２００に管理され，味方ＰＣの他小隊に属する味方ＰＣおよびＮＰＣは，味方ＰＣを操作するゲーム機２００に管理され，敵ＰＣの他小隊に属する敵ＰＣおよびＮＰＣは，敵ＰＣを操作するゲーム機２００に管理される点において第１実施形態と同様である。
【０１７２】
しかし，本実施形態では，たとえば，ゲームに参加するプレイヤが足りない場合であっても（たとえば，ゲームに参加するプレイヤが一人だとしても），ゲームに参加するプレイヤに対しては上記管理の原則が適用され，参加者の不足によりユーザによって操作されることがない１または２以上のＰＣおよびそのＰＣの小隊に属するＮＰＣは，ゲームサーバ１００により自動的に管理される点において第１実施形態と動作上異なる。よって，この相違点を中心に本実施形態にかかるネットワークゲームシステム１０について説明する。
【０１７３】
なお，以下の説明では，ゲームサーバ１００（ＳＶ）により管理されるプレイヤキャラクタ（ＰＣ）をサーバキャラクタ（ＳＣ）とも称呼する。また，ゲームサーバ１００により管理されるサーバキャラクタが複数存在する場合，ゲーム機２００により管理されるプレイヤキャラクタまたはゲームサーバ１００により管理される他のサーバキャラクタ（キャラクタ変更判定の対象となっているＮＰＣを管理するゲームサーバ１００のサーバキャラクタ以外のサーバキャラクタ）をメインキャラクタ（ＭＣ）とも称呼する。さらに，メインキャラクタを管理するゲーム機２００またはゲームサーバ１００をＭＣ管理機器とも称呼する。
【０１７４】
（ゲームサーバ１００の機能構成）
本実施形態にかかるゲームサーバ１００は，図２５に示したように，第１実施形態にかかるゲームサーバ１００の機能構成に加え，演算部１７０ａおよび判定部１７５の機能ブロックにより示された新たな機能が加えられている。また，演算部１７０ａと画像処理部１７０ｂとによりアクション処理実行部１７０の機能が実現される。
【０１７５】
新たに加えられた機能のうち，アクション処理実行部１７０は，記憶部１５０に登録され，ゲームサーバ１００により管理される各管理キャラクタのアクション処理を管理キャラクタ毎に実行する。具体的には，演算部１７０ａは，記憶部１５０に記憶されたキャラクタ情報を用いて，ゲーム上の戦闘によって発生する各管理キャラクタの位置の変化および動作の変化を表す変化量をそれぞれ演算することにより変化後のキャラクタ情報を生成する。
【０１７６】
また，判定部１７５は，演算部１７０ａにより演算された各管理キャラクタの位置の変化値に基づいて，ゲームサーバ１００が管理するいずれかのサーバキャラクタの位置（ＳＣの位置）と，ＭＣ管理機器により管理されるメインキャラクタの位置（ＭＣの位置）と，各管理キャラクタのアクション処理後の位置（演算後のＮＰＣの位置）と，の相対関係を求め，求められた位置の相対関係に基づき各管理キャラクタを管理するか否かを判定する。ゲームサーバ１００が管理する「いずれかの」プレイヤキャラクタの位置としたのは，ゲームに参加するユーザが少ない場合，ゲーム機２００に割り当てられなかった複数のプレイヤキャラクタを複数のサーバキャラクタとしてゲームサーバ１００にてそれぞれ管理する必要があるためである。
【０１７７】
（ゲームサーバ１００の動作）
本実施形態においても，原則的に，各プレイヤキャラクタおよび各ゲーム機２００により管理すると判定されたノンプレイヤキャラクタは，各ゲーム機２００により管理される。具体的には，これらのキャラクタは，各ゲーム機２００が図８のクライアント側管理処理を実行することにより管理される。
【０１７８】
これに加えて，本実施形態では，ゲーム参加者が不足しているので，ゲームサーバ１００にて自動的に管理することとなった１または複数のサーバキャラクタが存在する。この１または複数のサーバキャラクタおよびゲームサーバ１００によりサーバキャラクタ毎に管理すると判定されたノンプレイヤキャラクタは，ゲームサーバ１００により管理される。具体的には，これらのキャラクタは，図８に代わる図２６に示したように，ゲームサーバ１００がサーバ側管理処理を実行することにより管理される。
【０１７９】
なお，ゲームサーバ１００の動作には，原則的に，以下に説明する動作以外にも，第１実施形態または第２実施形態にて説明した動作が含まれる。また，言うまでも無いが，ＳＣ及びそのＳＣの小隊中のＮＰＣの位置変化に関するキャラクタ管理変更パケット及びキャラクタ情報パケットのサーバ間での送受信は行わず（サちなみに，ゲームサーバ１００とゲーム機２００との間は通常通り送受信を行う），この場合にはゲームサーバ１００内部のＲＡＭ１２０に記憶されたキャラクタ情報（図７）を直接更新する。
【０１８０】
また，本実施形態では，ユーザが割り当てられなかったプレイヤキャラクタに対してのみ，ゲームの進行に応じてゲームサーバ１００が「自動的に」その動作を管理する。したがって，ゲームサーバ１００は，サーバ管理者によるアクション処理のためのモニタ４１５の表示も，キーボード４０５などの入力装置による入力情報の入力も不要である。また，本実施形態では，第１実施形態にて図８のステップ８２５で行われていたような，ＲＡＭ１２０の更新処理や音響等に関する処理も不要となる。以上を踏まえて，本実施形態におけるゲームサーバ１００の動作について説明する。
【０１８１】
（ゲームスタート）
ゲーム機２００の電源が「ＯＮ」され，あるプレイヤからゲームの開始が要求されると，ゲームサーバ１００は，図２６のステップ２６００からサーバ側管理処理を開始し，ステップ８０５にて初期設定を行う。
【０１８２】
つぎに，ステップ８１０にて，判定部１７５は，割込み（垂直帰線割込（Ｖｓｙｎｃ））が発生したか否かを判定する。判定部１７５は，モニタ４１５の垂直帰線周期と一致した１／６０秒に一度の周期で割込みが発生すると，これに応じて，ステップ８１０にて「ＹＥＳ」と判定し，ステップ８１５に進んでキャラクタ管理処理（キャラクタ管理処理の詳細は後述）を実行する。
【０１８３】
つぎに，判定部１７５は，ステップ８２０に進んでゲームが終了か否かを判定する。具体的には，プレイヤが，ゲーム機２００の電源を「ＯＦＦ」するか，または，画面上のゲーム終了を選択することによりゲームは終了する。そこで，プレイヤがこれらのいずれかの操作をするまで，ゲームサーバ１００は，基本的に，ステップ８１０〜ステップ８２０の処理を繰り返し，プレイヤがこれらのいずれかの操作をするとステップ２６９５に進んでゲームを終了する。
【０１８４】
ステップ８１０で割込みが発生していない場合，判定部１７５は，ステップ８１０にて「ＮＯ」と判定してステップ８２５でメイン処理を実行し，その後ステップ８２０に進む。このメイン処理においては，本実施形態におけるネットワークゲームと直接関係しないその他の処理が実行される。
【０１８５】
（キャラクタ管理処理）
つぎに，ステップ８１５のキャラクタ管理処理について，図２７のフローチャートを参照しながら説明する。ステップ２７００から処理が開始されると，通信部１４５は，ステップ９０５にて，他のゲーム機２００から送信されたキャラクタ管理変更パケットを受信したか否かを判定する。
【０１８６】
キャラクタ管理変更パケットを受信した場合には，ステップ２７０５に進んで，記憶部１５０は，キャラクタ管理変更パケットに含まれるキャラクタ情報に基づきＲＡＭ１２０の該当キャラクタ情報を更新する。具体的には，図７に示されたように，該当ＰＣまたは該当ＮＰＣに記憶された座標，体の向き，モーション番号，再生フレーム位置，進行方向，所属軍の情報を更新する。また，記憶部１５０は，このキャラクタ情報により特定されるキャラクタを管理キャラクタとしてＲＡＭ１２０に登録する。具体的には，図７に示されたように，該当キャラクタ情報の管理元のＰＣ番号を変更することにより，各管理キャラクタの管理をクライアント側（ゲーム機器２００）またはサーバ側（ゲームサーバ１００）のいずれかに変更する。また，通信部１４５は，同ステップ２７０５にて，受信したキャラクタ管理変更パケットをゲームに参加しているゲーム機２００に転送する。
【０１８７】
つぎに，ステップ９１５に進み，通信部１４５は，参加しているゲーム機２００からキャラクタ情報パケットを受信したか否かを判定する。キャラクタ情報パケットを受信した場合には，ステップ２７１０に進んで，記憶部１５０は，キャラクタ情報パケットに含まれるキャラクタ情報に基づきＲＡＭ１２０の該当キャラクタ情報を更新する。具体的には，図７の該当ＰＣまたは該当ＮＰＣに記憶された座標，体の向き，モーション番号，再生フレーム位置，進行方向，所属軍の情報を更新する。また，通信部１４５は，同ステップ２７１０にて，受信したキャラクタ情報パケットをゲームに参加しているゲーム機２００に転送する。
【０１８８】
ついで，ステップ９２５に進んで，アクション処理実行部１７０は，アクション処理を実行する。アクション処理とは，具体的には，アクション処理実行部１７０の各部により実行されるつぎの処理をいう。まず，演算部１７０ａは，ＲＡＭ１２０に記憶されたキャラクタ情報に基づき，各管理キャラクタの位置の変化量および動作の変化量を含んだキャラクタ情報を自動演算する。
【０１８９】
つぎに，ステップ９３０に進み，判定部１７５は，キャラクタ変更判定処理（サブルーチン）を実行する。この処理は，各管理キャラクタ（ＮＰＣ）の演算後の位置と，サーバキャラクタ（ＳＣ）の位置と，メインキャラクタ（ＭＣ）の位置と，の関係から当該管理キャラクタが管理されるべきＭＣ管理機器（ゲームサーバ１００またはゲーム機２００）を判定する。
【０１９０】
ついで，ステップ９３５に進み，通信部１４５が，演算部１７０ａにより演算された各管理キャラクタのキャラクタ情報をゲームに参加しているゲーム機２００に送信する。このように最新のキャラクタの状態をゲームに参加しているゲーム機２００に送信することにより，ゲームに参加しているゲーム機２００に記憶された各キャラクタのキャラクタ情報が更新される。これにより，データの整合性を保つことができる。
【０１９１】
（キャラクタ変更判定処理）
つぎに，ステップ９３０に示したキャラクタ変更判定処理について，図２８を参照しながら，詳細に説明する。
ステップ２８００からキャラクタ変更判定処理が開始され，ステップ２８０５に進むと，演算部１７０ａは，管理キャラクタとして記憶部１５０に登録されているＮＰＣと最寄の敵メインキャラクタ（敵ＭＣ）（すなわち，最寄の敵ＰＣまたは最寄の他のＳＣ）との距離ＤＥＰＣを求める。ここで，他のＳＣとは，キャラクタ変更判定の対象となっているＮＰＣを管理するゲームサーバ１００のサーバキャラクタ（ＳＣ）以外のＳＣをいう。
【０１９２】
つぎに，ステップ２８１０に進み，判定部１７５は，キャラクタ変更判定の対象となっているＮＰＣを管理するゲームサーバ１００（ＳＶ）のサーバキャラクタ（ＳＣ）が，ＮＰＣの味方であるか否かを判定する。サーバキャラクタが，ＮＰＣの味方である場合，判定部１７５は，ステップ２８１５に進み，距離ＤＥＰＣがマージンＭＣより小さいか否かを判定する。距離ＤＥＰＣがマージンＭＣより大きい場合，ステップ２８２０に進んで，演算部１７０ａは，ＮＰＣとサーバキャラクタとの距離Ｄを求め，ステップ２８２５にて，ＮＰＣと，最寄の味方メインキャラクタとの距離ＤＡＰＣを求める。
【０１９３】
つぎに，ステップ２８３０に進んで，判定部１７５は，距離ＤＡＰＣにマージンＭＤを加算した値が距離Ｄより小さいか否かを判定する。この時点で，距離ＤＡＰＣ＋マージンＭＤの値が距離Ｄより大きい場合，すなわち，最寄の味方メインキャラクタが，ＮＰＣを中心とした半径が（距離Ｄ−マージンＭＤ）の円内まで近づいていない場合には，判定部１７５は，ＮＰＣの管理をいずれかの機器に変更することなく，ステップ２８３５に進み，管理中のすべてのＮＰＣ（すなわち，管理キャラクタ）についてキャラクタ変更判定処理を実行するまで，ステップ２８０５に戻って各管理キャラクタの変更判定処理を続け，すべての管理キャラクタについて，この変更判定処理を終えるとステップ２８９５にて本処理を終了する。
【０１９４】
つぎに，味方メインキャラクタがＳＣよりマージンＭＤ以上ＮＰＣの近くに位置している場合について説明する。判定部１７５は，ステップ２８００〜ステップ２８２５に続くステップ２８３０にて「ＹＥＳ」と判定し，ステップ２８４０に進んで，味方ＭＣ管理変更処理を実行する。
【０１９５】
（味方ＭＣ管理変更処理）
具体的には，図２９に示したように，判定部１７５は，ステップ２９００から味方ＭＣ管理変更処理を開始して，ステップ２９０５に進み，最寄の味方ＭＣと当該ＮＰＣを管理しているゲームサーバ１００（ＳＶ）のＳＣとが同一か否かを判定する。同一でない場合，判定部１７５は，ステップ２９１０に進んで，最寄の味方ＭＣのＭＣ管理機器（ＣＬまたはＳＶ）が管理している管理キャラクタ数が７９以上であるか否かを判定する。最寄の味方ＭＣのＭＣ管理機器が管理している管理キャラクタ数が７９より少ないと，ステップ２９１５に進んで，記憶部１５０は，ＲＡＭ１２０に記憶されている最寄の味方ＭＣのキャラクタ情報のうち，ＭＣ管理機器が管理している管理キャラクタ数を１つ増やし，ステップ２９２０に進んで，現時点でＮＰＣを管理しているゲームサーバ１００により管理されている管理キャラクタ数を１つ減らす。
【０１９６】
ついで，ステップ２９２５に進んで，通信部１４５は，当該ＮＰＣの管理を，ＳＣを管理するゲームサーバ１００から味方ＭＣを管理するＭＣ管理機器に変更する情報を含んだ管理変更パケットを，ゲームに参加しているゲーム機２００に送信し，ステップ２９９５に進んで本処理を終了する。このように，味方ＭＣがＳＣよりマージンＭＤ以上ＮＰＣの近くに位置している場合，味方ＭＣを管理するＭＣ管理機器がＮＰＣ（管理キャラクタ）を管理するように，管理キャラクタが切り替わる。
【０１９７】
なお，ステップ２９０５にて，最寄の味方ＭＣと当該ＮＰＣを管理しているゲームサーバ１００のＳＣとが同一の場合には，管理キャラクタの管理変更を行う必要がなく，また，ステップ２９１０にて，最寄の味方ＭＣのＭＣ管理機器が管理している管理キャラクタ数が７９以上である場合には，そのゲーム機が管理する管理キャラクタをこれ以上増やすことが適当でないので，いずれも当該管理キャラクタを変更することなく，ステップ２９９５に進んで本処理を終了する。
【０１９８】
つぎに，ＳＣの小隊と敵ＭＣの小隊と味方ＭＣの小隊とが集団戦闘状態にある場合のキャラクタ変更判定処理について説明する。具体的には，ＮＰＣには味方ＭＣが最も近接しているが，敵ＭＣもＮＰＣを中心とした半径がマージンＭＣの円内に存在する場合，図２８のステップ２８００からキャラクタ変更判定処理を開始して，判定部１７５は，ステップ２８０５，ステップ２８１０に続くステップ２８１５にて「ＹＥＳ」と判定し，ステップ２８４５に進んで，敵ＭＣ管理変更処理を実行する。
【０１９９】
（敵ＭＣ管理変更処理）
具体的には，図３０に示したように，判定部１７５は，ステップ３０００から敵ＭＣ管理変更処理を開始して，ステップ３００５に進み，最寄の敵ＭＣと当該ＮＰＣを管理しているゲームサーバ１００のＳＣとが同一か否かを判定する。ここでは同一でないので，判定部１７５は，ステップ３０１０に進んで，最寄の敵ＭＣのＭＣ管理機器が管理している管理キャラクタ数が７９以上であるか否かを判定する。最寄の敵ＭＣを管理しているＭＣ管理機器の管理キャラクタ数が７９より少ないと，ステップ３０１５に進んで，記憶部１５０は，ＲＡＭ１２０に記憶されている，これからＮＰＣを管理するＭＣ等に関するキャラクタ情報のうち，ＭＣ管理機器が管理している管理キャラクタ数を１つ増やし，ステップ３０２０に進んで，現時点でＮＰＣを管理しているゲームサーバ１００により管理されている管理キャラクタ数を１つ減らす。
【０２００】
ついで，ステップ３０２５に進んで，通信部１４５は，当該ＮＰＣの管理を，ＳＣを管理するゲームサーバ１００から敵ＭＣを管理するＭＣ管理機器に変更する情報を含んだ管理変更パケットを，ゲームに参加しているゲーム機２００に送信し，ステップ３０９５に進んで本処理を終了する。このように，ＮＰＣに対して，味方ＭＣおよび敵ＭＣの両方が近接した場合，敵ＭＣを管理するゲーム機が，味方ＭＣを管理するゲーム機より優先してＮＰＣ（管理キャラクタ）を管理するように管理キャラクタが切り替わる。
【０２０１】
なお，図２９の味方ＰＣ管理変更処理と同様に，ステップ３００５またはステップ３０１０にて「ＹＥＳ」と判定された場合には，いずれも当該管理キャラクタを変更することなく，ステップ３０９５に進んで本処理を終了する。
【０２０２】
つぎに，ＮＰＣ（ＮＰＣ３１），ＰＣ１に代わるＳＣ，味方ＰＣ２に代わる味方ＭＣおよび敵ＰＣ３に代わる敵ＭＣとの関係が図１９に示した状況にある場合の処理について説明する。この状態で，図２８のキャラクタ変更判定処理が実行されると，ステップ２８００，２８０５に続くステップ２８１０にて，判定部１７５は，ＮＰＣは，ＮＰＣを管理するゲームサーバ１００が操作するＳＣの敵であると判定する。そこで，ステップ２８５０に進み，演算部１７０ａは，ＮＰＣとＳＣとの距離Ｄを求める。続いて，ステップ２８５５にて，判定部１７５は，距離ＤＥＰＣにマージンＭＡを加算した値が距離Ｄより小さいか否かを判定する。この時点では，距離ＤＥＰＣ＋マージンＭＡの値は距離Ｄより大きい。そこで，ステップ２８６０に進み，演算部１７０ａは，ＮＰＣと最寄の味方ＭＣとの距離ＤＡＰＣを求める。
【０２０３】
つぎに，ステップ２８６５に進んで，判定部１７５は，距離ＤＡＰＣにマージンＭＢを加算した値が距離Ｄより小さいか否かを判定する。この時点では，距離ＤＡＰＣ＋マージンＭＢの値は距離Ｄより大きい。そこで，ステップ２８３５に進み，ＲＡＭ１２０に登録されているすべての管理キャラクタの処理を終えるまでステップ２８０５に戻って各管理キャラクタの変更判定処理を実行する。
【０２０４】
つぎに，図２０に示したように，ＮＰＣ（ＮＰＣ３１）に対して味方ＰＣ２に代わる味方ＭＣおよび敵ＰＣ３に代わる敵ＭＣが近接した場合であって，敵ＭＣは自ＰＣ１に代わるＳＣよりマージンＭＡ以上ＮＰＣの近くに位置している場合について説明する。この状態で，図２８のキャラクタ変更判定処理が実行されると，ステップ２８００〜２８１０，ステップ２８５０に続くステップ２８５５にて，判定部１７５は，「ＹＥＳ」と判定し，ステップ２８７０に進んで，図３０の敵ＭＣ管理変更処理を実行する。すなわち，ステップ３０００〜３０２５を実行することにより，ＮＰＣの管理が，ＳＣを管理するゲームサーバ１００から敵ＭＣを管理するＭＣ管理機器に切り替わる。このように，ＮＰＣに対して味方ＭＣおよび敵ＭＣの両方が近接した場合であって，敵ＭＣがＳＣよりマージンＭＡ以上ＮＰＣの近くに位置している場合，敵ＭＣを管理するゲーム機が，味方ＭＣを管理するゲーム機より優先してＮＰＣ（管理キャラクタ）を管理するように管理キャラクタが切り替わる。
【０２０５】
一方，ゲームの状態が，図１９の状態から図２１の状態（すなわち，敵ＰＣ３に代わる敵ＭＣが自ＰＣ１に代わるＳＣよりマージンＭＡ以上ＮＰＣ（ＮＰＣ３１）の近くに位置していない場合であって，かつ，味方ＰＣ２に代わる味方ＭＣが自ＰＣ１に代わるＳＣよりマージンＭＢ以上ＮＰＣの近くに位置している状態）に遷移した場合について説明する。この状態で，図２８のキャラクタ変更判定処理が実行されると，ステップ２８００〜２８１０，ステップ２８５０〜２８６０に続くステップ２８６５にて，判定部１７５は，「ＹＥＳ」と判定し，ステップ２８４０に進んで，図２９の味方ＭＣ管理変更処理を実行する。すなわち，ステップ２９００〜２９２５を実行することにより，ＮＰＣの管理が，ＳＣを管理するゲームサーバ１００から味方ＭＣを管理するＭＣ管理機器に切り替わる。
【０２０６】
以上に説明したように，本実施形態によれば，ゲームに参加するプレイヤが足りない場合であっても（たとえば，ゲームに参加するユーザが一人だとしても），ゲームに参加するプレイヤのＰＣに対しては第１実施形態の原則（ＮＰＣをクライアント側で管理）が適用され，プレイヤがいない１または２以上のＳＣおよびそのＳＣの小隊中のＮＰＣは基本的にゲームサーバ１００により自動的に管理される。これにより，参加者が足りなくても，ユーザは，ゲームを思う存分楽しむことができる。また，クライアント機器により管理されるキャラクタとサーバ機器により管理されるキャラクタとを分けることによって，システム全体の処理を分散し，これにより，ゲームをスムーズに進行させることができる。
【０２０７】
（ＳＣを中心としたキャラクタ管理）
なお，本実施形態においても，たとえば，判定部１７５は，演算部１７０ａにより演算された各管理キャラクタの位置の変化に基づいて，ゲームサーバ１００により管理されるＳＣから第１の所定範囲内に位置する１または２以上のノンプレイヤキャラクタ（ＮＰＣ）を，ゲームサーバ１００が管理キャラクタとして管理すると判定してもよい。
【０２０８】
このようにＳＣを中心としたキャラクタ管理処理を実行する場合，判定部１７５は，ＭＣ管理機器により管理されるＭＣとＮＰＣとの関係が敵味方であって，ゲームサーバ１００により管理されるＳＣと当該ＮＰＣとの関係が味方同士の場合には，ＮＰＣがゲームサーバ１００により管理されるＳＣから第１の所定範囲内に位置していても，ＭＣから第２の所定範囲内（たとえば，第１の所定範囲＜第２の所定範囲）に位置するときには，ＭＣを管理するＭＣ管理機器が当該ＮＰＣを管理すると判定するようにしてもよい。
【０２０９】
また，ＳＣから所定範囲内に予め定められた所定数以上のＮＰＣが存在するとき，当該所定数のＮＰＣの管理を切り替えるようにしてもよい。また，ＳＣから所定範囲内に所定数以上のＮＰＣが存在してから，所定時間経過後にＮＰＣの管理を切り替えるようにしてもよい。
【０２１０】
これによれば，ＮＰＣとＭＣとＳＣとが近傍に位置する戦闘体制において，ＮＰＣを優先的にＭＣを管理するＭＣ管理機器に管理させることができ，この結果，ゲーム全体の処理をスムーズに進行させることができる。
【０２１１】
また，ゲームサーバ１００（ＳＶ）が管理する各ＮＰＣについて，最寄のＳＣと最寄のＭＣとの位置関係からＮＰＣの管理を変更してもよい。たとえば，ゲームサーバ１００が管理するＮＰＣとＭＣとの距離が，ゲームサーバ１００が管理するＮＰＣとＳＣとの距離より短くなった場合にＮＰＣの管理を変更するようにしてもよい。
【０２１２】
また，ネットワークゲームシステム１０では，敵味方同士のプレイヤキャラクタにゲームサーバ１００にて管理されるサーバキャラクタやノンプレイヤキャラクタが付随するようなキャラクタ構成にしてもよく，敵がすべてゲームサーバ１００にて管理されるサーバキャラクタであり，味方がすべてゲーム機器２００にて管理されるプレイヤキャラクタであるキャラクタ構成にしてもよい。
【０２１３】
また，プレイヤが不足していなくても，ゲームサーバ１００が自動操作するサーバキャラクタおよび管理キャラクタ（ノンプレイヤキャラクタ）をゲーム上に登場させてもよい。また，ゲームサーバ１００が自動操作する複数のサーバキャラクタが敵味方同士であってもよい。
【０２１４】
上記実施形態において，各部の動作はお互いに関連しており，互いの関連を考慮しながら，一連の動作として置き換えることができる。そして，このように置き換えることにより，キャラクタを管理するクライアント機器の発明の実施形態をクライアント機器のキャラクタ管理方法の実施形態とすることができる。
【０２１５】
したがって，本発明にかかるクライアント機器は，ネットワークを介してサーバ機器に接続された複数のクライアント機器を，ユーザが操作することにより，入力された情報に応じて動作する複数のプレイヤキャラクタと，自動的に動作する複数のノンプレイヤキャラクタと，を含んだ複数のキャラクタが登場するネットワークゲームにおける各クライアント機器のキャラクタ管理方法であって，各クライアント機器は，上記複数のキャラクタの位置情報を含んだキャラクタ情報を各クライアント機器の記憶部に各々記憶し，上記ノンプレイヤキャラクタのうち自己のクライアント機器が管理するノンプレイヤキャラクタを管理キャラクタとして各クライアント機器の記憶部に各々登録し，上記各クライアント機器の記憶部に記憶されたキャラクタ情報を用いて，上記ゲームの展開に応じた上記各管理キャラクタの位置の変化の程度および動作の変化の程度を変化後のキャラクタ情報として上記管理キャラクタ毎に演算することを特徴とする各クライアント機器のキャラクタ管理方法とすることができる。
【０２１６】
また，上記各クライアント機器の上記キャラクタ管理方法では，各クライアント機器は，上記演算された各管理キャラクタの位置の変化に基づいて，上記各管理キャラクタの演算後の位置と自己のクライアント機器が管理するプレイヤキャラクタの位置と他のクライアント機器が管理するプレイヤキャラクタの位置との相対関係を求め，求められた位置の相対関係に基づき各管理キャラクタを管理するクライアント機器を判定し，上記他のクライアント機器により管理されると判定された管理キャラクタの登録を上記自己のクライアント機器の記憶部から削除し，上記他のクライアント機器により管理されると判定された管理キャラクタのキャラクタ情報を含んだキャラクタ管理変更パケットをサーバ機器に送信することができる。
【０２１７】
また，上記各部の動作を，各部の処理と置き換えることにより，プログラムの実施形態とすることができる。また，プログラムを，プログラムを記録したコンピュータ読み取り可能な記録媒体に記憶させることにより，プログラムの実施形態をプログラムに記録したコンピュータ読み取り可能な記録媒体の実施形態とすることができる。
【０２１８】
以上，添付図面を参照しながら本発明の好適な実施形態について説明したが，本発明は係る例に限定されないことは言うまでもない。当業者であれば，特許請求の範囲に記載された範疇内において，各種の変更例または修正例に想到し得ることは明らかであり，それらについても当然に本発明の技術的範囲に属するものと了解される。
【０２１９】
たとえば，上記各実施形態にかかる集団戦闘ゲームは，ネットワークゲームシステムの一例であり，ネットワークゲームの他の例としては，自分のプレイヤキャラクタを操作して仕事等をすることによりプレイヤキャラクタのレベルや能力等のパラメータを上昇させ，ネットワークを介して接続された他のクライアント機器を操作する他のプレイヤキャラクタと立身出世を競ったり，或いは，ネットワークを介して他のプレイヤキャラクタとチャットをしてコミュニケーションを楽しむゲームが挙げられる。
【０２２０】
また，上記各実施形態では，８人のプレイヤが参加するネットワークゲームを例に挙げて説明したが，本発明にかかるネットワークゲームシステムは，これに限定されるものではなく，たとえば，サーバ機器対１のクライアント機器で戦闘する１人プレイヤ用のゲーム形態も含まれることは言うまでも無い。
【０２２１】
また，ゲームに参加している他のプレイヤが少ないときに，本来人数分のプレイヤが参加していれば存在したであろう他のＰＣ及びそのＰＣの小隊中のＮＰＣを，全てＮＰＣとして登場させ，それらのＮＰＣを現在参加している何れかのクライアント機器（クライアント機器が１つの場合も含む）に分散させて管理させたり，一律にサーバ機器に管理させてもよい。この場合，システムの内部処理的には，ＰＣは，もはや，ユーザ操作にしたがって動作する本来のＰＣではないため，いわゆる相対位置関係を求める処理においてもＮＰＣとして処理する。
【産業上の利用可能性】
【０２２２】
本発明は，複数のキャラクタが登場するネットワークゲームシステムにおいてそのキャラクタをスムーズに動作させるために，登場する各キャラクタの処理および管理を分散して実行するネットワークゲームシステム，クライアント機器，サーバ機器に適用可能である。
【図面の簡単な説明】
【０２２３】
【図１】本発明の各実施形態にかかるネットワークゲームシステムの全体構成図である。
【図２】各実施形態にかかるゲーム機の一例を示した図である。
【図３】各実施形態にかかるゲームサーバのハードウエア構成図である。
【図４】各実施形態にかかるゲーム機のハードウエア構成図である。
【図５】第１実施形態および第２実施形態にかかるゲームサーバの機能構成図である。
【図６】各実施形態にかかるゲーム機の機能構成図である。
【図７】各実施形態にかかるＲＡＭに記憶されるキャラクタ情報の一例を示した図である。
【図８】第１実施形態および第２実施形態にてゲーム機が実行するクライアント側管理処理ルーチンを示したフローチャートである。
【図９】第１実施形態にてゲーム機が実行するキャラクタ管理処理ルーチンを示したフローチャートである。
【図１０】第１実施形態および第２実施形態にてゲーム機またはゲームサーバが実行するキャラクタ変更判定処理ルーチンを示したフローチャートである。
【図１１】戦闘体制に移行する前のゲーム状態を説明するための図である。
【図１２】ＮＰＣと各ＰＣと相対位置関係の一例を説明するための図である。
【図１３】ＮＰＣと各ＰＣと相対位置関係の一例を説明するための図である。
【図１４】第１実施形態および第２実施形態にてゲーム機またはゲームサーバが実行する味方ＰＣ管理変更処理ルーチンを示したフローチャートである。
【図１５】戦闘体制にあるゲーム状態を説明するための図である。
【図１６】ＮＰＣと各ＰＣと相対位置関係の一例を説明するための図である。
【図１７】第１実施形態および第２実施形態にてゲーム機またはゲームサーバが実行する敵ＰＣ管理変更処理ルーチンを示したフローチャートである。
【図１８】自小隊が敵小隊から逃げるゲーム状態を説明するための図である。
【図１９】ＮＰＣと各ＰＣと相対位置関係の一例を説明するための図である。
【図２０】ＮＰＣと各ＰＣと相対位置関係の一例を説明するための図である。
【図２１】ＮＰＣと各ＰＣと相対位置関係の一例を説明するための図である。
【図２２】第１実施形態にてゲームサーバが実行するサーバ側管理処理ルーチンを示したフローチャートである。
【図２３】第２実施形態にてゲーム機が実行するキャラクタ管理処理ルーチンを示したフローチャートである。
【図２４】第２実施形態にてゲームサーバが実行するサーバ側管理処理ルーチンを示したフローチャートである。
【図２５】第３実施形態にかかるゲームサーバの機能構成図である。
【図２６】第３実施形態にてゲームサーバが実行するサーバ側管理処理ルーチンを示したフローチャートである。
【図２７】第３実施形態にてゲーム機が実行するキャラクタ管理処理ルーチンを示したフローチャートである。
【図２８】第３実施形態にてゲーム機またはゲームサーバが実行するキャラクタ変更判定処理ルーチンを示したフローチャートである。
【図２９】第３実施形態にてゲーム機またはゲームサーバが実行する味方ＭＣ管理変更処理ルーチンを示したフローチャートである。
【図３０】第３実施形態にてゲーム機またはゲームサーバが実行する敵ＭＣ管理変更処理ルーチンを示したフローチャートである。
【符号の説明】
【０２２４】
１０ ネットワークゲームシステム
１００ ゲームサーバ
１１０ ハードディスク
１２０ ＲＡＭ
１４０ 入力部
１４５ 通信部
１５０ 記憶部
１５５ 管理部
１６０ 画像処理部
１６５ 画像生成部
１７０ アクション処理実行部
１７０ａ 演算部
１７０ｂ 画像処理部
１７５ 判定部
２００ ゲーム機
２１０ ハードディスク
２２０ ＲＡＭ
２４０ リーダ
２４５ 媒体読取部
２５０ 入力部
２５５ 記憶部
２６０ アクション処理実行部
２６０ａ 演算部
２６０ｂ 画像処理部
２６０ｃ 音響処理部
２６５ 画像生成部
２７０ 音響再生部
２７５ 判定部
２８０ 通信部
３００ ネットワーク
ＰＣ プレイヤキャラクタ
ＮＰＣ ノンプレイヤキャラクタ
ＳＣ サーバキャラクタ
ＭＣ メインキャラクタ
ＣＬ ゲーム機
ＳＶ ゲームサーバ
【特許請求の範囲】
【請求項１】
ネットワークを介してサーバ機器に接続された複数のクライアント機器を，ユーザが操作することにより，入力された情報に応じて動作する複数のプレイヤキャラクタと，自動的に動作する複数のノンプレイヤキャラクタと，を含んだ複数のキャラクタが登場するネットワークゲームシステムであって，
前記各クライアント機器は，
前記複数のキャラクタの位置情報を含んだキャラクタ情報を記憶し，前記ノンプレイヤキャラクタのうち自己のクライアント機器が管理するノンプレイヤキャラクタを管理キャラクタとして登録する記憶部と，
前記記憶部に記憶されたキャラクタ情報を用いて，前記ゲームの展開に応じた前記各管理キャラクタの位置の変化の程度および動作の変化の程度を変化後のキャラクタ情報として前記管理キャラクタ毎に演算する演算部と，
前記演算された変化後の各管理キャラクタのキャラクタ情報をキャラクタ情報パケットとしてサーバ機器に送信する通信部と，を備え，
前記サーバ機器は，
前記送信されたキャラクタ情報パケットを受信し，受信したキャラクタ情報パケットを前記ゲームに参加している他のクライアント機器に送信し，
前記他のクライアント機器は，
前記送信されたキャラクタ情報パケットを受信し，受信されたキャラクタ情報に基づいて前記変化後のキャラクタ情報を記憶することを特徴とするネットワークゲームシステム。
【請求項２】
前記各クライアント機器は，さらに，
前記演算された各管理キャラクタの位置の変化の程度に基づいて，前記各管理キャラクタの演算後の位置と自己のクライアント機器が管理するプレイヤキャラクタの位置と他のクライアント機器が管理するプレイヤキャラクタの位置との相対関係を求め，求められた位置の相対関係に基づき各管理キャラクタを管理するか否かを判定する判定部，を備え，
前記各クライアント機器の記憶部は，
前記判定部により管理しないと判定された管理キャラクタの登録を削除し，
前記各クライアント機器の通信部は，
前記判定部により前記管理キャラクタが前記他のクライアント機器により管理されると判定された場合，前記管理キャラクタのキャラクタ情報を含んだキャラクタ管理変更パケットをサーバ機器に送信し，
前記サーバ機器は，
前記キャラクタ管理変更パケットを受信し，受信したキャラクタ管理変更パケットを前記他のクライアント機器に送信し，
前記他のクライアント機器は，
前記送信されたキャラクタ管理変更パケットを受信し，受信されたキャラクタ情報を記憶するとともに前記受信されたキャラクタ情報により特定されるキャラクタを管理キャラクタとして登録することを特徴とする請求項１に記載されたネットワークゲームシステム。
【請求項３】
前記ネットワークゲームシステムは，
前記複数のクライアント機器により管理される複数のプレイヤキャラクタと前記複数のプレイヤキャラクタを護衛するノンプレイヤキャラクタとからなる複数のキャラクタが敵味方の集団を形成して互いに戦闘するゲームを提供するシステムであることを特徴とする請求項１に記載されたネットワークゲームシステム。
【請求項４】
ネットワークに接続された複数のクライアント機器を，ユーザが操作することにより，入力された情報に応じて動作する複数のプレイヤキャラクタと，自動的に動作する複数のノンプレイヤキャラクタと，を含んだ複数のキャラクタが登場するネットワークゲームに参加するクライアント機器であって，
前記クライアント機器は，
前記複数のキャラクタの位置情報を含んだキャラクタ情報を記憶し，前記ノンプレイヤキャラクタのうち自己のクライアント機器が管理するノンプレイヤキャラクタを管理キャラクタとして登録する記憶部と，
前記記憶部に記憶されたキャラクタ情報を用いて，前記ゲームの展開に応じた前記各管理キャラクタの位置の変化の程度および動作の変化の程度を変化後のキャラクタ情報として前記管理キャラクタ毎に演算する演算部と，を備えることを特徴とするクライアント機器。
【請求項５】
前記クライアント機器であって，さらに，
前記演算された各管理キャラクタの位置の変化の程度に基づいて，前記各管理キャラクタの演算後の位置と自己のクライアント機器が管理するプレイヤキャラクタの位置と他のクライアント機器が管理するプレイヤキャラクタの位置との相対関係を求め，前記求められた位置の相対関係に基づき各管理キャラクタを管理するか否かを判定する判定部を備えることを特徴とする請求項４に記載されたクライアント機器。
【請求項６】
前記クライアント機器は，
前記複数のクライアント機器により管理される複数のプレイヤキャラクタと前記複数のプレイヤキャラクタを護衛するノンプレイヤキャラクタとからなる複数のキャラクタが敵味方の集団を形成して互いに戦闘するゲームを提供することを特徴とする請求項４または請求項５のいずれかに記載されたクライアント機器。
【請求項７】
前記クライアント機器であって，さらに，
前記生成されたキャラクタ情報に基づいてそのキャラクタ情報により特定されるキャラクタに関する画像を生成する画像生成部を備えることを特徴とする請求項４に記載されたクライアント機器。
【請求項８】
前記判定部は，
前記求められた位置の相対関係に基づき，前記各管理キャラクタから所定範囲内に位置するプレイヤキャラクタを管理するクライアント機器に管理されるように前記各管理キャラクタを管理するか否かを判定することを特徴とする請求項５に記載されたクライアント機器。
【請求項９】
前記判定部は，
前記求められた位置の相対関係に基づき，前記各管理キャラクタが，前記各管理キャラクタの敵のプレイヤキャラクタを管理するクライアント機器に優先して管理されるように前記各管理キャラクタを管理するか否かを判定することを特徴とする請求項６に記載されたクライアント機器。
【請求項１０】
前記判定部は，
前記求められた位置の相対関係に基づき，前記各管理キャラクタに最も近いプレイヤキャラクタを管理するクライアント機器に管理されるように前記各管理キャラクタを管理するか否かを判定することを特徴とする請求項６に記載されたクライアント機器。
【請求項１１】
前記判定部は，
前記他のクライアント機器が管理するプレイヤキャラクタの位置が，前記各管理キャラクタに最も近い場合であっても，自己のクライアント機器が管理するプレイヤキャラクタの位置より所定距離以上前記各管理キャラクタの近くに位置しない限り，自己のクライアント機器が前記各管理キャラクタを管理すると判定することを特徴とする請求項１０に記載されたクライアント機器。
【請求項１２】
前記所定距離は，前記管理キャラクタを管理するクライアント機器を切り替えるとの判定が前記判定部により頻繁に生じないためのマージンとなる値に設定されることを特徴とする請求項１１に記載されたクライアント機器。
【請求項１３】
前記所定距離は，前記他のクライアント機器が管理するプレイヤキャラクタと前記各管理キャラクタとの関係が敵味方である場合には，その関係が味方同士である場合に比べ短い値に設定されることを特徴とする請求項１２に記載されたクライアント機器。
【請求項１４】
前記判定部は，
前記各管理キャラクタが，自己のクライアント機器により管理されるプレイヤキャラクタに対して敵のキャラクタであるか味方のキャラクタであるかを区別することなく，前記演算された位置の相対関係に基づき，前記各管理キャラクタを管理するか否かを判定することを特徴とする請求項６に記載されたクライアント機器。
【請求項１５】
前記判定部は，
前記他のクライアント機器が管理するプレイヤキャラクタが，前記各管理キャラクタおよび自己のクライアント機器が管理するプレイヤキャラクタの敵であり，かつ，前記他のクライアント機器が管理するプレイヤキャラクタが前記各管理キャラクタの一定範囲内に位置する場合には，前記求められた位置の相対関係にかかわらず，前記他のクライアント機器が前記各管理キャラクタを管理すると判定することを特徴とする請求項６に記載されたクライアント機器。
【請求項１６】
前記クライアント機器であって，さらに，
前記判定部により前記各管理キャラクタが前記他のクライアント機器により管理されると判定された場合，前記判定された管理キャラクタのキャラクタ情報を含んだキャラクタ管理変更パケットをサーバ機器に送信する通信部を備え，
前記記憶部は，
前記他のクライアント機器により管理されると判定された管理キャラクタの登録を削除することを特徴とする請求項５に記載されたクライアント機器。
【請求項１７】
前記通信部は，
前記ネットワークを介して前記サーバ機器に接続された他のクライアント機器から送信されたキャラクタ管理変更パケットを受信し，
前記記憶部は，
前記受信したキャラクタ管理変更パケットに含まれるキャラクタ情報を記憶し，前記キャラクタ情報により特定されるキャラクタを管理キャラクタとして登録することを特徴とする請求項１６に記載されたクライアント機器。
【請求項１８】
前記他のクライアント機器がネットワークを介して複数接続され，
前記他のクライアント機器のうち，第１の他のクライアント機器が管理するプレイヤキャラクタが敵であり，第２の他のクライアント機器が管理するプレイヤキャラクタが味方である場合，
前記判定部は，
前記求められた位置の相対関係に基づき，前記各管理キャラクタが第２の他のクライアント機器よりも第１の他のクライアント機器に優先して管理されるように前記各管理キャラクタを管理するか否かを判定することを特徴とする請求項６に記載されたクライアント機器。
【請求項１９】
前記判定部は，
所定周期ごとに前記各管理キャラクタを管理するか否かを判定することを特徴とする請求項７に記載されたクライアント機器。
【請求項２０】
前記各ノンプレイヤキャラクタは，
前記ネットワークゲームに参加しているいずれかのクライアント機器に分散して管理されることを特徴とする請求項５に記載されたクライアント機器。
【請求項２１】
前記ネットワークゲームシステムは，
前記複数のクライアント機器により管理される複数のプレイヤキャラクタと前記複数のノンプレイヤキャラクタとが集団を形成して互いに協力するゲームを提供するシステムであることを特徴とする請求項１に記載されたネットワークゲームシステム。
【請求項２２】
複数のプレイヤキャラクタと複数のノンプレイヤキャラクタとを含んだ複数のキャラクタが登場するネットワークゲームを管理するサーバ機器であって，
前記サーバ機器は，
ネットワークに接続された複数のクライアント機器により管理される前記複数のキャラクタの位置情報を含んだキャラクタ情報を記憶する記憶部と，
前記キャラクタ情報に含まれる位置情報に基づいて，各クライアント機器が管理するプレイヤキャラクタの位置と各クライアント機器が管理するノンプレイヤキャラクタの位置との相対関係を求め，前記求められた位置の相対関係に基づき前記ノンプレイヤキャラクタを管理するクライアント機器を判定する判定部と，
前記各ノンプレイヤキャラクタを管理すると判定されたクライアント機器にキャラクタ管理変更パケットを送信する通信部と，を備えることを特徴とするサーバ機器。
【請求項２３】
ネットワークに接続された複数のクライアント機器を，ユーザが操作することにより，入力された情報に応じて動作する複数のプレイヤキャラクタと，自動的に動作する複数のノンプレイヤキャラクタと，を含んだ複数のキャラクタが登場するネットワークゲームをコンピュータに実行させるためのキャラクタ管理プログラムであって，
前記複数のキャラクタの位置情報を含んだキャラクタ情報を各クライアント機器の記憶部に各々記憶する処理と，
前記ノンプレイヤキャラクタのうち自己のクライアント機器が管理するノンプレイヤキャラクタを管理キャラクタとして各クライアント機器の記憶部に各々登録する処理と，
前記各クライアント機器の記憶部に記憶されたキャラクタ情報を用いて，各クライアント機器に対して前記ゲームの展開に応じた前記各管理キャラクタの位置の変化の程度および動作の変化の程度を変化後のキャラクタ情報として前記管理キャラクタ毎に演算する処理と，をコンピュータに実行させることを特徴とするキャラクタ管理プログラム。
【請求項２４】
前記キャラクタ管理プログラムであって，さらに，
前記演算された各管理キャラクタの位置の変化の程度に基づいて，前記各管理キャラクタの演算後の位置と自己のクライアント機器が管理するプレイヤキャラクタの位置と他のクライアント機器が管理するプレイヤキャラクタの位置との相対関係を求め，前記求められた位置の相対関係に基づき各管理キャラクタを管理するクライアント機器を判定する処理と，
前記他のクライアント機器により管理されると判定された管理キャラクタの登録を前記自己のクライアント機器の記憶部から削除する処理と，
前記他のクライアント機器により管理されると判定された管理キャラクタのキャラクタ情報を含んだキャラクタ管理変更パケットをサーバ機器に送信する処理と，をコンピュータに実行させることを特徴とする請求項２３に記載されたキャラクタ管理プログラム。
【請求項２５】
ネットワークに接続された複数のクライアント機器を，ユーザが操作することにより，入力された情報に応じて動作する複数のプレイヤキャラクタと，自動的に動作する複数のノンプレイヤキャラクタと，を含んだ複数のキャラクタが登場するネットワークゲームをコンピュータに実行させるためのキャラクタ管理プログラムを記憶したコンピュータ読み取り可能な記憶媒体であって，
前記複数のキャラクタの位置情報を含んだキャラクタ情報を各クライアント機器の記憶部に各々記憶する処理と，
前記ノンプレイヤキャラクタのうち自己のクライアント機器が管理するノンプレイヤキャラクタを管理キャラクタとして各クライアント機器の記憶部に各々登録する処理と，
前記各クライアント機器の記憶部に記憶されたキャラクタ情報を用いて，各クライアント機器に対して前記ゲームの展開に応じた前記各管理キャラクタの位置の変化の程度および動作の変化の程度を変化後のキャラクタ情報として前記管理キャラクタ毎に演算する処理と，をコンピュータに実行させることを特徴とするキャラクタ管理プログラムを記憶したコンピュータ読み取り可能な記憶媒体。
【請求項２６】
前記キャラクタ管理プログラムを記憶したコンピュータ読み取り可能な記憶媒体であって，さらに，
前記演算された各管理キャラクタの位置の変化の程度に基づいて，各管理キャラクタの演算後の位置と自己のクライアント機器が管理するプレイヤキャラクタの位置と他のクライアント機器が管理するプレイヤキャラクタの位置との相対関係を求め，前記求められた位置の相対関係に基づき各管理キャラクタを管理するクライアント機器を判定する処理と，
前記他のクライアント機器により管理されると判定された管理キャラクタの登録を前記自己のクライアント機器の記憶部から削除する処理と，
前記他のクライアント機器により管理されると判定された管理キャラクタのキャラクタ情報を含んだキャラクタ管理変更パケットをサーバ機器に送信する処理と，をコンピュータに実行させることを特徴とする請求項２５に記載されたキャラクタ管理プログラムを記憶したコンピュータ読み取り可能な記憶媒体。
【請求項２７】
ネットワークを介してサーバ機器に接続された１または複数のクライアント機器を，ユーザが操作することにより，入力された情報に応じて動作する１または複数のプレイヤキャラクタと，自動的に動作する複数のノンプレイヤキャラクタと，を含んだ複数のキャラクタが登場するネットワークゲームシステムであって，
前記各クライアント機器は，
前記複数のキャラクタの位置情報を含んだキャラクタ情報を記憶し，前記ノンプレイヤキャラクタのうち自己のクライアント機器が管理するノンプレイヤキャラクタを管理キャラクタとして登録する記憶部と，
前記記憶部に記憶されたキャラクタ情報を用いて，前記ゲームの展開に応じた前記各管理キャラクタの位置の変化の程度および動作の変化の程度を変化後のキャラクタ情報として前記管理キャラクタ毎に演算する演算部と，
前記演算された変化後の各管理キャラクタのキャラクタ情報をキャラクタ情報パケットとしてサーバ機器に送信する通信部と，を備え，
前記サーバ機器は，
前記送信されたキャラクタ情報パケットを受信し，受信したキャラクタ情報パケットを前記ゲームに参加している他のクライアント機器に送信し，
前記他のクライアント機器は，
前記送信されたキャラクタ情報パケットを受信し，受信されたキャラクタ情報に基づいて前記変化後のキャラクタ情報を記憶することを特徴とするネットワークゲームシステム。
【請求項２８】
前記サーバ機器は，さらに，
前記複数のキャラクタの位置情報を含んだキャラクタ情報を記憶し，前記ノンプレイヤキャラクタのうち自己のサーバ機器が管理するノンプレイヤキャラクタを管理キャラクタとして登録する記憶部と，
前記記憶部に記憶されたキャラクタ情報を用いて，前記ゲームの展開に応じた前記各管理キャラクタの位置の変化の程度および動作の変化の程度を変化後のキャラクタ情報として前記管理キャラクタ毎に演算する演算部と，
前記演算された変化後の各管理キャラクタのキャラクタ情報をキャラクタ情報パケットとして前記ゲームに参加しているすべてのクライアント機器に送信する通信部と，を備えることを特徴とする請求項２７に記載されたネットワークゲームシステム。
【請求項２９】
前記ゲームに登場する前記複数のキャラクタは，さらに，前記サーバ機器の制御により自動的に動作する１または複数のサーバキャラクタを含み，
前記サーバ機器は，さらに，
前記演算された各管理キャラクタの位置の変化の程度に基づいて，前記各管理キャラクタの演算後の位置と自己のサーバ機器が管理するいずれかの前記サーバキャラクタの位置と前記クライアント機器が管理するプレイヤキャラクタまたは他のサーバキャラクタの位置との相対関係を求め，求められた位置の相対関係に基づき各管理キャラクタを管理するか否かを前記サーバキャラクタ毎に判定する判定部，を備え，
前記サーバ機器の記憶部は，
前記サーバ機器の判定部により管理しないと判定された管理キャラクタの登録を削除し，
前記サーバ機器の通信部は，
前記サーバ機器の判定部により前記管理キャラクタが前記クライアント機器により管理されると判定された場合，前記管理キャラクタのキャラクタ情報を含んだキャラクタ管理変更パケットを前記クライアント機器に送信し，
前記クライアント機器は，
前記送信されたキャラクタ管理変更パケットを受信し，受信されたキャラクタ情報を記憶するとともに前記受信されたキャラクタ情報により特定されるキャラクタを管理キャラクタとして登録することを特徴とする請求項２８に記載されたネットワークゲームシステム。
【請求項３０】
前記ネットワークゲームシステムは，
前記１または複数のクライアント機器により管理される１または複数のプレイヤキャラクタと前記１または複数のプレイヤキャラクタを護衛する１または複数のノンプレイヤキャラクタとが味方集団を形成し，かつ，前記サーバ機器により管理される１または複数のサーバキャラクタと前記サーバキャラクタを護衛する１または複数のノンプレイヤキャラクタとが敵集団または味方集団の少なくともいずれかを形成して互いに戦闘するゲームを提供するシステムであることを特徴とする請求項２９に記載されたネットワークゲームシステム。
【請求項３１】
ネットワークを介してサーバ機器に接続された１または複数のクライアント機器を，ユーザが操作することにより，入力された情報に応じて動作する１または複数のプレイヤキャラクタと，自動的に動作する複数のノンプレイヤキャラクタと，を含んだ複数のキャラクタが登場するネットワークゲームをコンピュータに実行させるためのキャラクタ管理プログラムであって，
前記複数のキャラクタの位置情報を含んだキャラクタ情報を各クライアント機器の記憶部に各々記憶する処理と，
前記ノンプレイヤキャラクタのうち自己のクライアント機器が管理するノンプレイヤキャラクタを管理キャラクタとして各クライアント機器の記憶部に各々登録する処理と，
前記各クライアント機器の記憶部に記憶されたキャラクタ情報を用いて，各クライアント機器に対して前記ゲームの展開に応じた前記各管理キャラクタの位置の変化の程度および動作の変化の程度を変化後のキャラクタ情報として前記管理キャラクタ毎に演算する処理と，をコンピュータに実行させることを特徴とするキャラクタ管理プログラム。
【請求項３２】
前記キャラクタ管理プログラムであって，さらに，
前記複数のキャラクタの位置情報を含んだキャラクタ情報を前記サーバ機器の記憶部に記憶する処理と，
前記ノンプレイヤキャラクタのうち自己のサーバ機器が管理するノンプレイヤキャラクタを管理キャラクタとして前記サーバ機器の記憶部に登録する処理と，
前記サーバ機器の記憶部に記憶されたキャラクタ情報を用いて，前記サーバ機器に対して前記ゲームの展開に応じた前記各管理キャラクタの位置の変化の程度および動作の変化の程度を変化後のキャラクタ情報として前記管理キャラクタ毎に演算する処理と，をコンピュータに実行させることを特徴とする請求項３１に記載されたキャラクタ管理プログラム。
【請求項３３】
前記ゲームで登場する前記複数のキャラクタは，さらに，前記サーバ機器の制御により自動的に動作する１または複数のサーバキャラクタを含み，
前記キャラクタ管理プログラムであって，さらに，
前記演算された各管理キャラクタの位置の変化の程度に基づいて，前記各管理キャラクタの演算後の位置と自己のサーバ機器が管理するいずれかのサーバキャラクタの位置とクライアント機器が管理するプレイヤキャラクタの位置との相対関係を求め，前記求められた位置の相対関係に基づき各管理キャラクタを前記サーバキャラクタ毎に管理するサーバ機器またはクライアント機器を判定する処理と，
前記クライアント機器により管理されると判定された管理キャラクタの登録を前記自己のサーバ機器の記憶部から削除する処理と，
前記クライアント機器により管理されると判定された管理キャラクタのキャラクタ情報を含んだキャラクタ管理変更パケットを前記クライアント機器に送信する処理と，をコンピュータに実行させることを特徴とする請求項３２に記載されたキャラクタ管理プログラム。
【請求項３４】
前記キャラクタ管理プログラムは，
前記１または複数のクライアント機器により管理される１または複数のプレイヤキャラクタと前記１または複数のプレイヤキャラクタを護衛する１または複数のノンプレイヤキャラクタが味方集団を形成し，且つ前記サーバ機器により管理される１または複数のサーバキャラクタと前記サーバキャラクタを護衛する１または複数のノンプレイヤキャラクタが敵集団または味方集団の少なくともいずれかを形成して互いに戦闘するゲームを提供するプログラムであることを特徴とする請求項３３に記載されたキャラクタ管理プログラム。
【請求項１】
ネットワークを介してサーバ機器に接続された複数のクライアント機器を，ユーザが操作することにより，入力された情報に応じて動作する複数のプレイヤキャラクタと，自動的に動作する複数のノンプレイヤキャラクタと，を含んだ複数のキャラクタが登場するネットワークゲームシステムであって，
前記各クライアント機器は，
前記複数のキャラクタの位置情報を含んだキャラクタ情報を記憶し，前記ノンプレイヤキャラクタのうち自己のクライアント機器が管理するノンプレイヤキャラクタを管理キャラクタとして登録する記憶部と，
前記記憶部に記憶されたキャラクタ情報を用いて，前記ゲームの展開に応じた前記各管理キャラクタの位置の変化の程度および動作の変化の程度を変化後のキャラクタ情報として前記管理キャラクタ毎に演算する演算部と，
前記演算された変化後の各管理キャラクタのキャラクタ情報をキャラクタ情報パケットとしてサーバ機器に送信する通信部と，を備え，
前記サーバ機器は，
前記送信されたキャラクタ情報パケットを受信し，受信したキャラクタ情報パケットを前記ゲームに参加している他のクライアント機器に送信し，
前記他のクライアント機器は，
前記送信されたキャラクタ情報パケットを受信し，受信されたキャラクタ情報に基づいて前記変化後のキャラクタ情報を記憶することを特徴とするネットワークゲームシステム。
【請求項２】
前記各クライアント機器は，さらに，
前記演算された各管理キャラクタの位置の変化の程度に基づいて，前記各管理キャラクタの演算後の位置と自己のクライアント機器が管理するプレイヤキャラクタの位置と他のクライアント機器が管理するプレイヤキャラクタの位置との相対関係を求め，求められた位置の相対関係に基づき各管理キャラクタを管理するか否かを判定する判定部，を備え，
前記各クライアント機器の記憶部は，
前記判定部により管理しないと判定された管理キャラクタの登録を削除し，
前記各クライアント機器の通信部は，
前記判定部により前記管理キャラクタが前記他のクライアント機器により管理されると判定された場合，前記管理キャラクタのキャラクタ情報を含んだキャラクタ管理変更パケットをサーバ機器に送信し，
前記サーバ機器は，
前記キャラクタ管理変更パケットを受信し，受信したキャラクタ管理変更パケットを前記他のクライアント機器に送信し，
前記他のクライアント機器は，
前記送信されたキャラクタ管理変更パケットを受信し，受信されたキャラクタ情報を記憶するとともに前記受信されたキャラクタ情報により特定されるキャラクタを管理キャラクタとして登録することを特徴とする請求項１に記載されたネットワークゲームシステム。
【請求項３】
前記ネットワークゲームシステムは，
前記複数のクライアント機器により管理される複数のプレイヤキャラクタと前記複数のプレイヤキャラクタを護衛するノンプレイヤキャラクタとからなる複数のキャラクタが敵味方の集団を形成して互いに戦闘するゲームを提供するシステムであることを特徴とする請求項１に記載されたネットワークゲームシステム。
【請求項４】
ネットワークに接続された複数のクライアント機器を，ユーザが操作することにより，入力された情報に応じて動作する複数のプレイヤキャラクタと，自動的に動作する複数のノンプレイヤキャラクタと，を含んだ複数のキャラクタが登場するネットワークゲームに参加するクライアント機器であって，
前記クライアント機器は，
前記複数のキャラクタの位置情報を含んだキャラクタ情報を記憶し，前記ノンプレイヤキャラクタのうち自己のクライアント機器が管理するノンプレイヤキャラクタを管理キャラクタとして登録する記憶部と，
前記記憶部に記憶されたキャラクタ情報を用いて，前記ゲームの展開に応じた前記各管理キャラクタの位置の変化の程度および動作の変化の程度を変化後のキャラクタ情報として前記管理キャラクタ毎に演算する演算部と，を備えることを特徴とするクライアント機器。
【請求項５】
前記クライアント機器であって，さらに，
前記演算された各管理キャラクタの位置の変化の程度に基づいて，前記各管理キャラクタの演算後の位置と自己のクライアント機器が管理するプレイヤキャラクタの位置と他のクライアント機器が管理するプレイヤキャラクタの位置との相対関係を求め，前記求められた位置の相対関係に基づき各管理キャラクタを管理するか否かを判定する判定部を備えることを特徴とする請求項４に記載されたクライアント機器。
【請求項６】
前記クライアント機器は，
前記複数のクライアント機器により管理される複数のプレイヤキャラクタと前記複数のプレイヤキャラクタを護衛するノンプレイヤキャラクタとからなる複数のキャラクタが敵味方の集団を形成して互いに戦闘するゲームを提供することを特徴とする請求項４または請求項５のいずれかに記載されたクライアント機器。
【請求項７】
前記クライアント機器であって，さらに，
前記生成されたキャラクタ情報に基づいてそのキャラクタ情報により特定されるキャラクタに関する画像を生成する画像生成部を備えることを特徴とする請求項４に記載されたクライアント機器。
【請求項８】
前記判定部は，
前記求められた位置の相対関係に基づき，前記各管理キャラクタから所定範囲内に位置するプレイヤキャラクタを管理するクライアント機器に管理されるように前記各管理キャラクタを管理するか否かを判定することを特徴とする請求項５に記載されたクライアント機器。
【請求項９】
前記判定部は，
前記求められた位置の相対関係に基づき，前記各管理キャラクタが，前記各管理キャラクタの敵のプレイヤキャラクタを管理するクライアント機器に優先して管理されるように前記各管理キャラクタを管理するか否かを判定することを特徴とする請求項６に記載されたクライアント機器。
【請求項１０】
前記判定部は，
前記求められた位置の相対関係に基づき，前記各管理キャラクタに最も近いプレイヤキャラクタを管理するクライアント機器に管理されるように前記各管理キャラクタを管理するか否かを判定することを特徴とする請求項６に記載されたクライアント機器。
【請求項１１】
前記判定部は，
前記他のクライアント機器が管理するプレイヤキャラクタの位置が，前記各管理キャラクタに最も近い場合であっても，自己のクライアント機器が管理するプレイヤキャラクタの位置より所定距離以上前記各管理キャラクタの近くに位置しない限り，自己のクライアント機器が前記各管理キャラクタを管理すると判定することを特徴とする請求項１０に記載されたクライアント機器。
【請求項１２】
前記所定距離は，前記管理キャラクタを管理するクライアント機器を切り替えるとの判定が前記判定部により頻繁に生じないためのマージンとなる値に設定されることを特徴とする請求項１１に記載されたクライアント機器。
【請求項１３】
前記所定距離は，前記他のクライアント機器が管理するプレイヤキャラクタと前記各管理キャラクタとの関係が敵味方である場合には，その関係が味方同士である場合に比べ短い値に設定されることを特徴とする請求項１２に記載されたクライアント機器。
【請求項１４】
前記判定部は，
前記各管理キャラクタが，自己のクライアント機器により管理されるプレイヤキャラクタに対して敵のキャラクタであるか味方のキャラクタであるかを区別することなく，前記演算された位置の相対関係に基づき，前記各管理キャラクタを管理するか否かを判定することを特徴とする請求項６に記載されたクライアント機器。
【請求項１５】
前記判定部は，
前記他のクライアント機器が管理するプレイヤキャラクタが，前記各管理キャラクタおよび自己のクライアント機器が管理するプレイヤキャラクタの敵であり，かつ，前記他のクライアント機器が管理するプレイヤキャラクタが前記各管理キャラクタの一定範囲内に位置する場合には，前記求められた位置の相対関係にかかわらず，前記他のクライアント機器が前記各管理キャラクタを管理すると判定することを特徴とする請求項６に記載されたクライアント機器。
【請求項１６】
前記クライアント機器であって，さらに，
前記判定部により前記各管理キャラクタが前記他のクライアント機器により管理されると判定された場合，前記判定された管理キャラクタのキャラクタ情報を含んだキャラクタ管理変更パケットをサーバ機器に送信する通信部を備え，
前記記憶部は，
前記他のクライアント機器により管理されると判定された管理キャラクタの登録を削除することを特徴とする請求項５に記載されたクライアント機器。
【請求項１７】
前記通信部は，
前記ネットワークを介して前記サーバ機器に接続された他のクライアント機器から送信されたキャラクタ管理変更パケットを受信し，
前記記憶部は，
前記受信したキャラクタ管理変更パケットに含まれるキャラクタ情報を記憶し，前記キャラクタ情報により特定されるキャラクタを管理キャラクタとして登録することを特徴とする請求項１６に記載されたクライアント機器。
【請求項１８】
前記他のクライアント機器がネットワークを介して複数接続され，
前記他のクライアント機器のうち，第１の他のクライアント機器が管理するプレイヤキャラクタが敵であり，第２の他のクライアント機器が管理するプレイヤキャラクタが味方である場合，
前記判定部は，
前記求められた位置の相対関係に基づき，前記各管理キャラクタが第２の他のクライアント機器よりも第１の他のクライアント機器に優先して管理されるように前記各管理キャラクタを管理するか否かを判定することを特徴とする請求項６に記載されたクライアント機器。
【請求項１９】
前記判定部は，
所定周期ごとに前記各管理キャラクタを管理するか否かを判定することを特徴とする請求項７に記載されたクライアント機器。
【請求項２０】
前記各ノンプレイヤキャラクタは，
前記ネットワークゲームに参加しているいずれかのクライアント機器に分散して管理されることを特徴とする請求項５に記載されたクライアント機器。
【請求項２１】
前記ネットワークゲームシステムは，
前記複数のクライアント機器により管理される複数のプレイヤキャラクタと前記複数のノンプレイヤキャラクタとが集団を形成して互いに協力するゲームを提供するシステムであることを特徴とする請求項１に記載されたネットワークゲームシステム。
【請求項２２】
複数のプレイヤキャラクタと複数のノンプレイヤキャラクタとを含んだ複数のキャラクタが登場するネットワークゲームを管理するサーバ機器であって，
前記サーバ機器は，
ネットワークに接続された複数のクライアント機器により管理される前記複数のキャラクタの位置情報を含んだキャラクタ情報を記憶する記憶部と，
前記キャラクタ情報に含まれる位置情報に基づいて，各クライアント機器が管理するプレイヤキャラクタの位置と各クライアント機器が管理するノンプレイヤキャラクタの位置との相対関係を求め，前記求められた位置の相対関係に基づき前記ノンプレイヤキャラクタを管理するクライアント機器を判定する判定部と，
前記各ノンプレイヤキャラクタを管理すると判定されたクライアント機器にキャラクタ管理変更パケットを送信する通信部と，を備えることを特徴とするサーバ機器。
【請求項２３】
ネットワークに接続された複数のクライアント機器を，ユーザが操作することにより，入力された情報に応じて動作する複数のプレイヤキャラクタと，自動的に動作する複数のノンプレイヤキャラクタと，を含んだ複数のキャラクタが登場するネットワークゲームをコンピュータに実行させるためのキャラクタ管理プログラムであって，
前記複数のキャラクタの位置情報を含んだキャラクタ情報を各クライアント機器の記憶部に各々記憶する処理と，
前記ノンプレイヤキャラクタのうち自己のクライアント機器が管理するノンプレイヤキャラクタを管理キャラクタとして各クライアント機器の記憶部に各々登録する処理と，
前記各クライアント機器の記憶部に記憶されたキャラクタ情報を用いて，各クライアント機器に対して前記ゲームの展開に応じた前記各管理キャラクタの位置の変化の程度および動作の変化の程度を変化後のキャラクタ情報として前記管理キャラクタ毎に演算する処理と，をコンピュータに実行させることを特徴とするキャラクタ管理プログラム。
【請求項２４】
前記キャラクタ管理プログラムであって，さらに，
前記演算された各管理キャラクタの位置の変化の程度に基づいて，前記各管理キャラクタの演算後の位置と自己のクライアント機器が管理するプレイヤキャラクタの位置と他のクライアント機器が管理するプレイヤキャラクタの位置との相対関係を求め，前記求められた位置の相対関係に基づき各管理キャラクタを管理するクライアント機器を判定する処理と，
前記他のクライアント機器により管理されると判定された管理キャラクタの登録を前記自己のクライアント機器の記憶部から削除する処理と，
前記他のクライアント機器により管理されると判定された管理キャラクタのキャラクタ情報を含んだキャラクタ管理変更パケットをサーバ機器に送信する処理と，をコンピュータに実行させることを特徴とする請求項２３に記載されたキャラクタ管理プログラム。
【請求項２５】
ネットワークに接続された複数のクライアント機器を，ユーザが操作することにより，入力された情報に応じて動作する複数のプレイヤキャラクタと，自動的に動作する複数のノンプレイヤキャラクタと，を含んだ複数のキャラクタが登場するネットワークゲームをコンピュータに実行させるためのキャラクタ管理プログラムを記憶したコンピュータ読み取り可能な記憶媒体であって，
前記複数のキャラクタの位置情報を含んだキャラクタ情報を各クライアント機器の記憶部に各々記憶する処理と，
前記ノンプレイヤキャラクタのうち自己のクライアント機器が管理するノンプレイヤキャラクタを管理キャラクタとして各クライアント機器の記憶部に各々登録する処理と，
前記各クライアント機器の記憶部に記憶されたキャラクタ情報を用いて，各クライアント機器に対して前記ゲームの展開に応じた前記各管理キャラクタの位置の変化の程度および動作の変化の程度を変化後のキャラクタ情報として前記管理キャラクタ毎に演算する処理と，をコンピュータに実行させることを特徴とするキャラクタ管理プログラムを記憶したコンピュータ読み取り可能な記憶媒体。
【請求項２６】
前記キャラクタ管理プログラムを記憶したコンピュータ読み取り可能な記憶媒体であって，さらに，
前記演算された各管理キャラクタの位置の変化の程度に基づいて，各管理キャラクタの演算後の位置と自己のクライアント機器が管理するプレイヤキャラクタの位置と他のクライアント機器が管理するプレイヤキャラクタの位置との相対関係を求め，前記求められた位置の相対関係に基づき各管理キャラクタを管理するクライアント機器を判定する処理と，
前記他のクライアント機器により管理されると判定された管理キャラクタの登録を前記自己のクライアント機器の記憶部から削除する処理と，
前記他のクライアント機器により管理されると判定された管理キャラクタのキャラクタ情報を含んだキャラクタ管理変更パケットをサーバ機器に送信する処理と，をコンピュータに実行させることを特徴とする請求項２５に記載されたキャラクタ管理プログラムを記憶したコンピュータ読み取り可能な記憶媒体。
【請求項２７】
ネットワークを介してサーバ機器に接続された１または複数のクライアント機器を，ユーザが操作することにより，入力された情報に応じて動作する１または複数のプレイヤキャラクタと，自動的に動作する複数のノンプレイヤキャラクタと，を含んだ複数のキャラクタが登場するネットワークゲームシステムであって，
前記各クライアント機器は，
前記複数のキャラクタの位置情報を含んだキャラクタ情報を記憶し，前記ノンプレイヤキャラクタのうち自己のクライアント機器が管理するノンプレイヤキャラクタを管理キャラクタとして登録する記憶部と，
前記記憶部に記憶されたキャラクタ情報を用いて，前記ゲームの展開に応じた前記各管理キャラクタの位置の変化の程度および動作の変化の程度を変化後のキャラクタ情報として前記管理キャラクタ毎に演算する演算部と，
前記演算された変化後の各管理キャラクタのキャラクタ情報をキャラクタ情報パケットとしてサーバ機器に送信する通信部と，を備え，
前記サーバ機器は，
前記送信されたキャラクタ情報パケットを受信し，受信したキャラクタ情報パケットを前記ゲームに参加している他のクライアント機器に送信し，
前記他のクライアント機器は，
前記送信されたキャラクタ情報パケットを受信し，受信されたキャラクタ情報に基づいて前記変化後のキャラクタ情報を記憶することを特徴とするネットワークゲームシステム。
【請求項２８】
前記サーバ機器は，さらに，
前記複数のキャラクタの位置情報を含んだキャラクタ情報を記憶し，前記ノンプレイヤキャラクタのうち自己のサーバ機器が管理するノンプレイヤキャラクタを管理キャラクタとして登録する記憶部と，
前記記憶部に記憶されたキャラクタ情報を用いて，前記ゲームの展開に応じた前記各管理キャラクタの位置の変化の程度および動作の変化の程度を変化後のキャラクタ情報として前記管理キャラクタ毎に演算する演算部と，
前記演算された変化後の各管理キャラクタのキャラクタ情報をキャラクタ情報パケットとして前記ゲームに参加しているすべてのクライアント機器に送信する通信部と，を備えることを特徴とする請求項２７に記載されたネットワークゲームシステム。
【請求項２９】
前記ゲームに登場する前記複数のキャラクタは，さらに，前記サーバ機器の制御により自動的に動作する１または複数のサーバキャラクタを含み，
前記サーバ機器は，さらに，
前記演算された各管理キャラクタの位置の変化の程度に基づいて，前記各管理キャラクタの演算後の位置と自己のサーバ機器が管理するいずれかの前記サーバキャラクタの位置と前記クライアント機器が管理するプレイヤキャラクタまたは他のサーバキャラクタの位置との相対関係を求め，求められた位置の相対関係に基づき各管理キャラクタを管理するか否かを前記サーバキャラクタ毎に判定する判定部，を備え，
前記サーバ機器の記憶部は，
前記サーバ機器の判定部により管理しないと判定された管理キャラクタの登録を削除し，
前記サーバ機器の通信部は，
前記サーバ機器の判定部により前記管理キャラクタが前記クライアント機器により管理されると判定された場合，前記管理キャラクタのキャラクタ情報を含んだキャラクタ管理変更パケットを前記クライアント機器に送信し，
前記クライアント機器は，
前記送信されたキャラクタ管理変更パケットを受信し，受信されたキャラクタ情報を記憶するとともに前記受信されたキャラクタ情報により特定されるキャラクタを管理キャラクタとして登録することを特徴とする請求項２８に記載されたネットワークゲームシステム。
【請求項３０】
前記ネットワークゲームシステムは，
前記１または複数のクライアント機器により管理される１または複数のプレイヤキャラクタと前記１または複数のプレイヤキャラクタを護衛する１または複数のノンプレイヤキャラクタとが味方集団を形成し，かつ，前記サーバ機器により管理される１または複数のサーバキャラクタと前記サーバキャラクタを護衛する１または複数のノンプレイヤキャラクタとが敵集団または味方集団の少なくともいずれかを形成して互いに戦闘するゲームを提供するシステムであることを特徴とする請求項２９に記載されたネットワークゲームシステム。
【請求項３１】
ネットワークを介してサーバ機器に接続された１または複数のクライアント機器を，ユーザが操作することにより，入力された情報に応じて動作する１または複数のプレイヤキャラクタと，自動的に動作する複数のノンプレイヤキャラクタと，を含んだ複数のキャラクタが登場するネットワークゲームをコンピュータに実行させるためのキャラクタ管理プログラムであって，
前記複数のキャラクタの位置情報を含んだキャラクタ情報を各クライアント機器の記憶部に各々記憶する処理と，
前記ノンプレイヤキャラクタのうち自己のクライアント機器が管理するノンプレイヤキャラクタを管理キャラクタとして各クライアント機器の記憶部に各々登録する処理と，
前記各クライアント機器の記憶部に記憶されたキャラクタ情報を用いて，各クライアント機器に対して前記ゲームの展開に応じた前記各管理キャラクタの位置の変化の程度および動作の変化の程度を変化後のキャラクタ情報として前記管理キャラクタ毎に演算する処理と，をコンピュータに実行させることを特徴とするキャラクタ管理プログラム。
【請求項３２】
前記キャラクタ管理プログラムであって，さらに，
前記複数のキャラクタの位置情報を含んだキャラクタ情報を前記サーバ機器の記憶部に記憶する処理と，
前記ノンプレイヤキャラクタのうち自己のサーバ機器が管理するノンプレイヤキャラクタを管理キャラクタとして前記サーバ機器の記憶部に登録する処理と，
前記サーバ機器の記憶部に記憶されたキャラクタ情報を用いて，前記サーバ機器に対して前記ゲームの展開に応じた前記各管理キャラクタの位置の変化の程度および動作の変化の程度を変化後のキャラクタ情報として前記管理キャラクタ毎に演算する処理と，をコンピュータに実行させることを特徴とする請求項３１に記載されたキャラクタ管理プログラム。
【請求項３３】
前記ゲームで登場する前記複数のキャラクタは，さらに，前記サーバ機器の制御により自動的に動作する１または複数のサーバキャラクタを含み，
前記キャラクタ管理プログラムであって，さらに，
前記演算された各管理キャラクタの位置の変化の程度に基づいて，前記各管理キャラクタの演算後の位置と自己のサーバ機器が管理するいずれかのサーバキャラクタの位置とクライアント機器が管理するプレイヤキャラクタの位置との相対関係を求め，前記求められた位置の相対関係に基づき各管理キャラクタを前記サーバキャラクタ毎に管理するサーバ機器またはクライアント機器を判定する処理と，
前記クライアント機器により管理されると判定された管理キャラクタの登録を前記自己のサーバ機器の記憶部から削除する処理と，
前記クライアント機器により管理されると判定された管理キャラクタのキャラクタ情報を含んだキャラクタ管理変更パケットを前記クライアント機器に送信する処理と，をコンピュータに実行させることを特徴とする請求項３２に記載されたキャラクタ管理プログラム。
【請求項３４】
前記キャラクタ管理プログラムは，
前記１または複数のクライアント機器により管理される１または複数のプレイヤキャラクタと前記１または複数のプレイヤキャラクタを護衛する１または複数のノンプレイヤキャラクタが味方集団を形成し，且つ前記サーバ機器により管理される１または複数のサーバキャラクタと前記サーバキャラクタを護衛する１または複数のノンプレイヤキャラクタが敵集団または味方集団の少なくともいずれかを形成して互いに戦闘するゲームを提供するプログラムであることを特徴とする請求項３３に記載されたキャラクタ管理プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【公開番号】特開２００７−９８０６３（Ｐ２００７−９８０６３Ａ）
【公開日】平成１９年４月１９日（２００７．４．１９）
【国際特許分類】
【出願番号】特願２００５−３１１８１３（Ｐ２００５−３１１８１３）
【出願日】平成１７年１０月２６日（２００５．１０．２６）
【出願人】（５９５０００４２７）株式会社光栄 (12)
【Ｆターム（参考）】
【公開日】平成１９年４月１９日（２００７．４．１９）
【国際特許分類】
【出願日】平成１７年１０月２６日（２００５．１０．２６）
【出願人】（５９５０００４２７）株式会社光栄 (12)
【Ｆターム（参考）】
[ Back to top ]