しかしながら、今までの通信ゲームシステムでは、複数の遊技者がチームを組んで相手チームと多人数対多人数の対戦ゲームを行う場合(以下、この対戦ゲームを「チーム対戦」又は「多人数対多人数の対戦」と呼ぶ。)、そのゲーム画像の表示、チーム間の優劣判定、及びゲームデータの通信に関して、以下のように改善しなければならない点が多々あった。
第1に、ゲーム画像の表示に関しては、以下のような改善点が指摘されていた。シューティングゲーム(砲弾や光線を発射して相手を倒すようなゲーム)では、遊技者が操作するオブジェクト、すなわちキャラクタが相手キャラクタに向かって発射する「光線弾」は、臨場感を持たせるため、地面に投射像オブジェクト(例えば、疑似的な影)を伴うようになっている。
ここで、この明細書では、便宜上仮想空間を定義するためのワールド座標系において、キャラクタはXZ平面上に「立つ」ものとし、このXZ平面に沿って仮想的な「地面」が凹凸を伴って規定されるものとする。したがってY軸方向の正方向が「上」方向となり、Y軸座標に沿って「高さ」が規定される。
具体的には、光線弾の真下に仮想的に点光源を設定し、この点光源からの光を地面に影として投影させ、光線弾の影を模すようになっている。この場合、地面に投影される影の大きさは、光線弾の高さに応じて小さくなるように処理されている。
しかし、光線弾の高さが地面から相当に高くなる場合、光線弾の影も極端に小さくなって、表示される画面上では、遊技者には殆ど認識できなくなるという問題があった。
また、各ゲーム装置で表示されるゲーム画像を規定する仮想空間内の視点は、遊技者が操作するオブジェクト、すなわちキャラクタの頭上斜め後方に固定されていた。つまり、遊技者が手動で視点の位置を切り替えない限り、視点の位置は常に一定に固定されていた。このため、表示する対象物が多数ある場合には表示される視野からはみ出し表示されない対象物が出るという問題があった。逆に、これを回避するに予め視点を対象物に対し遠方に設定した場合には、個々の対象物が表示画面内で小さく表示されることになり、臨場感に欠けるという問題が生ずる。他方、はみ出した表示対象物の位置を示す副画面を表示することが考えられるが、副画面を表示させるための演算処理が負担になる他、2つ以上の画面を注視する必要があるため遊技者が混乱し、ゲームへ集中できなくなる可能性もあった。さらに、遊技者が操作するキャラクタの動きに合わせて視点を移動させる方法も考えられるが、この方法では画像表示のための視野が自己キャラクタの動きにのみ対応するため必ずしも遊技者が見たい表示対象物が表示されているとは限らなくなり、見たい対象物を別途捜す必要があった。
さらに、背景の一部として表示されるオブジェクトの表示についても問題が指摘されていた。例えば、仮想空間内で設定される海中の構造物(建物の柱、船の底面など)を実際に水没しているように見せるために、海水を表すためのテクスチャを構造物のテクスチャと合成している。このとき、双方のテクスチャを構成する画素の色成分を加算や乗算等の演算により合成する色演算処理が行われていた。しかし、このような方法では、海面のような画面上で大きい面積を占める物体全体を半透明化させるための演算処理量が多く、ゲーム装置の全体処理能力を下げる場合があった。
第2に、チーム間の優劣判定に関しては、以下のような問題点が指摘されている。まず、今までのゲーム装置では、ゲーム画面上に表示されるメータ情報などによって自己キャラクタだけのゲーム上の残存した戦力(例えば体力)を示す情報は表示されていたが、チーム全体としてチーム毎の優劣状況を統一して判定したり表示したりする機能は無かった。各遊技者のゲーム画面には、自己キャラクタ、他の一部のキャラクタ、または全キャラクタの体力状況が、それぞればらばらで表示され、チームとしてまとまった残存戦力の表示が提供されていなかった。このため、各遊技者はそれらの情報を一定の操作をして集める必要があった。
また、チーム対戦をしている場合に、いずれか一方のチームの残存キャラクタ数が零になった時点でゲームが終結するように設計されていた。しかし、この方法の場合には、遊技者は残存しているキャラクタの状況を常に把握しなければならず煩わしかった。また一方のチームの残存キャラクタ数を他方のチームのゲーム装置において常に表示させておかなければならないため、そのための演算処理が必要となり、全体の処理能力を下げる要因になっていた。
さらに、チーム対戦の場合、チームを組んだ人数の多い方のチームが有利になることは当然であるが、今までのゲームシステムではチームを構成する人数に不均衡があっても、そのままでゲーム参加を打ち切り、対等でない条件のままゲームが開始されることが多かった。このような不均衡な状態のままゲームが継続されると、一方のチームのみ優勢になり、対等な条件で力量を競えないため、遊技者のゲームへの意欲が半減したり、緊迫感が萎えてしまったりしていた。
またさらに、対戦中にチームを構成するキャラクタのうち一人が倒された場合、そのチームは相手より一人少ない状態となり人数に不均衡が生ずる。従来はこのような場合でもゲームが続行されていたため、倒されたキャラクタを操作していた遊技者は、そのゲームの勝敗が決するまで何もできず待っているしかなかった。また、そのキャラクタが倒されたチームに属する他の遊技者は劣勢なキャラクタ数でゲームを継続しなければならなかった。
第3に、ゲーム処理に必要なデータの処理遅延に起因した問題が指摘されていた。すなわち、今までは、いずれかのゲーム装置において光線弾を発射した等の事項(以下「イベント」という。)が発生した場合、イベントが発生したゲーム装置はそのイベントに応じてゲーム処理を進め処理が終結してから(例えば、光線弾により相手キャラクタが倒される等)その処理の結果だけをネットワークを介して相手方のゲーム装置を送るようにしていた。しかしネットワークを通じてデータを送受信する場合には時間遅延が不可避であることから、受信側ゲーム装置は時間的に遅れたデータを受信することになる。送信側と受信側のゲーム装置では同期してゲームが進行しているため、このデータの時間遅延により、言わばピントが外れた画像表示がされる場合があった。例えば、光線弾を発射するイベントが生じた場合、その光線弾が相手キャラクタに当たるまでの処理が送信側ゲーム装置で行われ、相手キャラクタが爆発したことを示すデータが処理の結果として送られてくる。このとき、処理結果の送信中に、本来爆発処理されるべき相手キャラクタが移動していた場合には、移動した後の相手キャラクタの位置では光線弾が命中していないにもかかわらず、光線弾は相手キャラクタに命中したことになっている。このため、命中していないはずの光線弾によって相手キャラクタが爆発処理されているような表示になってしまっていた。これでは相手キャラクタを操作している遊技者は、自分のゲームスキルが劣るためではなく、ゲーム装置やゲームプログラムの内部的な不具合(通信遅延や命中判定の設定不備等)のせいで不利を被ったように感じ、このことがゲームの興味を失わせることになっていた。
以上の数々の不都合に鑑み、本発明の第1の目的は、今までのゲーム装置で指摘されていたゲーム画像の表示上の不都合を解決するためのゲーム装置を提供することである。
本発明の第2の目的は、今までの通信ゲームシステムで指摘されていたチーム間の優劣判定上の不都合を解決するための通信ゲームシステムを提供することである。
本発明の第3の目的は、今までの通信ゲームシステムで指摘されていた、ゲームデータの通信遅延に起因する不都合を解決するための通信ゲームシステムを提供することである。
第1の目的を解決するために、本発明は、仮想空間内に設定された地形表面から離れて位置する空間オブジェクトを表示可能に構成されたゲーム装置において、地形表面に対して空間オブジェクトの投影像を模した投影像オブジェクトを生成する投影像生成モジュールと、投影像オブジェクトを空間オブジェクトの移動に伴って移動させ、仮想空間内における空間オブジェクトの位置と仮想空間内に設定された仮想光源の位置とに応じて表示させる投影像オブジェクトの大きさを変更し、当該空間オブジェクトの地形表面からの距離が基準距離を超えた場合には当該投影像オブジェクトの大きさを所定の大きさに留める投影像変更モジュールと、を備える。
本発明において「モジュール」とは、ソフトウェアプログラムとハードウェアとが協働して実行される所定の機能を備えたユニットをいう。
ここで「仮想空間」とはCG処理のために論理的に設定された座標系で規定される空間をいう。
ここで「空間オブジェクト」とは仮想空間内に浮かんでいるようなオブジェクト一般をいい、シューティングゲームであれば発射された光線弾のようなものをいう。また空間オブジェクトは遊技者によって操作されるキャラクタであってもよい。さらに空間オブジェクトは前記仮想光源を伴なった飛翔体であってもよい。
ここで、例えば上記ゲームはシューティングゲームであって、空間オブジェクトはそのシューティング(shooting)に登場するキャラクタが武器から発射させる光線弾である。
ここで「キャラクタ」はゲーム装置を操作する遊技者やゲーム装置自体が仮想空間内における動作を変更可能なオブジェクトであり、対戦ゲームの主体となるものである。遊技者が操作可能な自己キャラクタ、遊技者と対戦している他人が操作可能になっていたりゲーム装置が操作するようになっている敵キャラクタを含む。
また本発明は、遊技者が仮想空間で自己キャラクタを操作してゲームを行うことが可能に構成されたゲーム装置において、自己キャラクタの背後の視点から当該自己キャラクタの前方を視野に収めた、二次元平面に投影されたゲーム画像を生成する画像生成モジュールと、視野内に入れるべきキャラクタの仮想空間内における位置又は移動状態に応じて視点の位置を自己キャラクタの背後の空間内で移動させる視点位置制御モジュールと、を備える。
ここで「背後」や「前方」とは自己キャラクタに対し便宜上定めた仮想空間における方向をいう。人間やロボットを模したキャラクタの場合、一般にいう前後関係と一致する。
ここで、例えば視点位置制御モジュールは、視点の位置を自己キャラクタの背後の空間内で移動させるときに、当該視点と自己キャラクタとの距離が所定距離以内なる範囲で移動させる。
また、視点位置制御モジュールは、視野内に入れるべきキャラクタが当該視野からずれた場合に、所定の速度で視点を移動して当該視野内に入れるべきキャラクタを当該視野内に入れる。
本発明は、遊技者が仮想空間で自己キャラクタを操作してゲームを行うことが可能に構成されたゲーム装置において、前記自己キャラクタの背後の視点から当該自己キャラクタの前方を視野に収めた、二次元平面に投影されたゲーム画像を生成する画像生成モジュールと、前記視野内に入れるべきキャラクタの仮想空間内における位置又は移動状態に応じて前記視点の位置を前記自己キャラクタの背後の空間内で移動させる視点位置制御モジュールと、を備え、前記ゲームは複数のキャラクタが仮想空間内を移動するゲームであって、前記視点位置制御モジュールは、前記視点の位置は前記自己キャラクタおよびその他のキャラクタの位置または移動状態に応じて前記視点の位置を制御するゲーム装置である。
ここで、視点位置制御モジュールは、前記視点と前記自己キャラクタとの距離が所定距離以内となる範囲で他のキャラクタの前記ゲーム画像への表示数が最大となるように前記視点の位置を移動させてもよい。
さらに本発明は、遊技者が仮想空間でゲームを行うことが可能に構成されたゲーム装置において、仮想空間内で少なくとも一部が重なり関係にある複数の表示対象物を特定する特定モジュールと、この特定された複数の表示対象物の各々について各表示対象物がゲーム画像として表示される際の面積を比較する比較モジュールと、この比較によってより小さい面積の表示対象物を半透明にする半透明化処理モジュールと、この半透明化処理された表示対象物をゲーム画像の視線から見てより手前に配置してゲーム画像を生成する画像生成モジュールと、を備える。
ここで「表示対象物」は背景の一部をなすオブジェクトであってもキャラクタであってもよい。
第2の目的を解決するために、本発明は、複数のゲーム装置が相互に接続され、当該ゲーム装置を操作する少なくとも2人の遊技者を1チームとしてチーム間で対戦ゲームを行うことが可能に構成された通信ゲームシステムにおいて、対戦ゲームを行っているチーム間の優劣をチーム内における対戦能力の合計に基づいて判定する優劣判定モジュールと、この判定の結果を表示する画像を生成する画像生成モジュールと、を備える。
ここで、優劣判定モジュールは、各遊技者が操作するキャラクタの対戦ゲームにおける対戦能力の最大値に占める当該対戦能力の現在値の割合を演算し、この割合をチーム毎に合計してチーム間の優劣を決める。
また本発明は、複数のゲーム装置が相互に接続され、ゲーム装置を操作する少なくとも2人の遊技者を1チームとしてチーム同士で対戦ゲームを行うことが可能に構成された通信ゲームシステムにおいて、対戦ゲームを行っているチーム間の優劣を、各チームでリーダーとして指定されたリーダーキャラクタが対戦ゲームにおいて有効であるか否かを判定する有効性判定モジュールと、リーダーキャラクタが有効であると判定された場合に当該リーダーキャラクタが属するチームが勝ちであると判定する優劣判定モジュールと、を備える。
ここで「有効」とは、例えばキャラクタが消滅せず残っている(すなわち「生きている」)ような場合をいう。
また対戦ゲームは各回毎に勝敗をつけるステージを複数回実行可能に構成されており、リーダーとして指定されるキャラクタを各回のステージ毎に自動的に交替させるリーダー交替モジュールと、このリーダー交替モジュールにより交替させたリーダーキャラクタの元で各ステージのゲームを実行させるゲーム実行モジュールと、を備えていてもよい。
ここで、リーダー交替モジュールは、各ステージにおいて、それ以前のステージ中で成績が最も良かったリーダーキャラクタを自動的に再指名するように構成してもよい。
ここで、リーダー交替モジュールは、最終ラウンドにおいて、それ以前のステージ中で成績が最も良かったリーダーキャラクタを自動的に再指名してもよい。
リーダーキャラクタの有効性は、リーダーキャラクタの体力が残っていることを基準に定められてもよい。
また、ゲームにおいて対戦可能時間を予め定め、当該対戦可能時間が経過した時に両チームのリーダーキャラクタが有効であった場合に、当該リーダーキャラクタの残り体力が多い方のチームを勝ちであると判定してもよい。
また、ゲームにおいて対戦可能時間を予め定め、当該対戦可能時間が経過した時に両チームのリーダーキャラクタが有効であった場合に、各チームに属するキャラクタの残り体力を合計し、その合計した体力が多い方のチームを勝ちであると判定してもよい。
本発明は、複数のゲーム装置が相互に接続され、前記ゲーム装置を操作する少なくとも2人の遊技者を1チームとしてチーム同士で対戦ゲームを行うことが可能に構成された通信ゲームシステムにおいて、前記対戦ゲームを行っているチーム間の優劣を、各チームでリーダーとして指定されたリーダーキャラクタが前記対戦ゲームにおいて有効であるか否かを判定する有効性判定モジュールと、いずれかのチーム内において前記リーダーキャラクタ以外のキャラクタの体力が低減された場合に当該リーダーキャラクタの体力を当該体力が低減したキャラクタに分配させる体力分配モジュールと、を備える。
さらに本発明は、複数のゲーム装置が相互に接続され、ゲーム装置を操作する少なくとも2人の遊技者を1チームとしてチーム同士で対戦ゲームを行うことが可能に構成された通信ゲームシステムにおいて、複数のゲーム装置の夫々は、対戦ゲームを行うチーム間における戦力バランスに対応した所定の条件を考慮する条件考慮モジュールと、条件に応じてチーム間における戦力バランスを調整する戦力バランス調整モジュールと、を備える。
ここで、戦力バランス調整モジュールは、対戦ゲームの開始時に、この対戦ゲームに参加するキャラクタの数をチーム間で一致させてもよい。
ここで、戦力バランス調整モジュールは、対戦ゲームの途中で生じるチーム間の不均衡に応じて所定の基準以上優位にあるチームに負荷条件をつけてもよい。
ここで「負荷条件」とは、一定期間該当キャラクタの攻撃を禁止したり向きを変えることを禁止したりすることを含む。
ここで、戦力バランス調整モジュールは、チーム間の不均衡として、チーム毎のキャラクタ数、ゲーム上設定されている各キャラクタの能力、当該キャラクタの対戦勝率、およびチーム毎の対戦勝率からなる群のうちから選ばれる一以上の条件(上記所定の条件に対応)に応じて、負荷条件をつけてもよい。
ここで、戦力バランス調整モジュールは、対戦ゲームの途中でチーム内において一のキャラクタが他のキャラクタを助ける処理を行うように構成してもよい。
ここで、ゲーム装置の各々は、相手となるチームを構成するキャラクタの中から所定の条件に基づいて一のキャラクタを追跡対象として設定する追跡対象設定モジュールと、前記遊技者が操作する自己キャラクタが前記追跡対象に設定されたキャラクタの攻撃可能範囲に入るまで前記自己キャラクタの位置または向きを変更する追跡モジュールと、を備えていてもよい。
ここで、追跡モジュールは、前記追跡対象に設定されたキャラクタの動きに対応させて当該キャラクタの前記攻撃可能範囲に当該自己キャラクタが入るように当該自己キャラクタの位置または向きを補正する補正モジュールをさらに備えていてもよい。
ここで、「所定の条件」として、相手キャラクタの絶対的体力値、相手キャラクタの自己キャラクタとの相対的体力値、攻撃力、防御力、リーダー設定の有無、および当該キャラクタを操作している遊技者の勝率からなる群から選ばれる一以上の条件を利用するようにしてもよい。
第3の目的を解決するために、本発明は、複数のゲーム装置が相互に接続され、複数の遊技者がそれぞれのゲーム装置を操作して対戦ゲームを行うことが可能に構成された通信ゲームシステムにおいて、ゲーム装置の夫々は、所定のイベントが発生した場合に、当該イベントが発生した旨を示すデータを、当該対戦ゲームを実施している他のゲーム装置に送信するイベント送信モジュールと、当該対戦ゲームを実施している他のいずれかのゲーム装置からのデータを受信するデータ受信モジュールと、受信したデータに基づいたゲーム処理を実行し、この処理の結果を示すデータを当該対戦ゲームを実施している他のゲーム装置に送信する処理結果送信モジュールと、処理の結果に基づいたゲーム画像を生成するゲーム画像生成モジュールと、を備える。
ここで、三以上のゲーム装置が相互に接続されている場合に、ゲーム画像生成モジュールは、いずれかのゲーム装置において発生したイベントに対応して他のゲーム装置から返信される処理の結果を示すデータが、当該対戦ゲームを実施している総ての他のゲーム装置について受信された後に、受信された複数の処理の結果に基づいたゲーム画像を生成するように構成されている。
また各ゲーム装置では、イベントが発生した旨を示すデータとして、少なくとも、当該イベントを発生させた自己のゲーム装置を特定する情報および当該イベントの内容を示す情報を含ませてもよい。
また各ゲーム装置では、イベントが発生した旨を示すデータを受信した場合に、当該イベントを発生させたゲーム装置および当該イベントの内容に対応させたゲーム画像を生成し、処理の結果を示すデータとして、少なくとも、当該イベントを発生させたゲーム装置を特定する情報、当該イベントの内容、および当該イベントに対応させた自己のゲーム装置における処理の結果を含ませてもよい。
ここで、本発明は、送信側のゲーム装置において、一のキャラクタが出した攻撃が前記イベントとして受信側のゲーム装置に送信され、当該受信側のゲーム装置では、当該攻撃が攻撃対象とされたキャラクタに当たったか否かの命中判定を行い、当該命中判定の結果を前記送信側のゲーム装置に前記処理結果として返信し、前記送信側のゲーム装置では、対戦ゲームに参加する他のゲーム装置における処理結果が総て揃った後にこれら処理結果に基づいてゲーム処理を行うように構成されている。
上記した各発明において、例えば、ゲームは遊技者が操作するキャラクタ同士でシューティングを行って勝敗を競うシューティングゲームである。
本発明は、上記した各発明を実施するためのゲーム方法をコンピュータに実行させるためのプログラムを記録した機械読み取り可能な記録媒体でもある。
ここで「記録媒体」としてはCD−ROM、CD−R,CD−R/W,DVE,MD,DAT、FD、HDなど、デジタルデータを格納するために適するあらゆる媒体を含む。ネットワーク経由の通信によりプログラムデータが受信される場合、プログラムデータが流通するそのネットワーク全体もここでいう「記録媒体」に含む。
以下、本発明に係る実施の形態を図面に基づき説明する。
図1に、この実施形態に係る通信ゲームシステムGSの概略構成を示す。この通信ゲームシステムGSは、遊技者が操作する複数のゲーム装置1(1A,1B,1C,1D,…)が通信手段としてのネットワーク2を介して相互に接続されている。この通信ゲームシステムGSにより、不特定多数の遊技者は、チーム対戦(複数人対複数人の対戦)のシューティングゲームを行うことができる。
なお、以下の説明では、主として通信機能を利用して複数のゲーム装置が対戦ゲームを行う上で必要な構成及び機能を説明するが、通信機能を利用した対戦ゲームを行わないときには、各ゲーム装置1はスタンドアロンのゲーム装置として機能可能に構成されている。
通信ネットワーク2は、公衆回線または専用線であって、ゲーム専用ネットワークやインターネットなどのWAN(Wide Area Network)を形成している。この通信ネットワーク2がインターネットの場合、不特定多数のコンピュータ装置が接続可能であり、TCP/IPプロトコルで規定される各種コマンドを利用することで、ファイルの閲覧や電子メール、ファイルの転送などを実現することが可能になっている。ただし、通信ネットワークはWANである必要はなく、閉回路(closed circuit)で運用されるLAN等の局所的なネットワークであってもよい。
なお、通信ネットワーク2にゲームサーバシステムを接続して、このゲームサーバシステムにゲームの一部または全体の管理を任せるように構成してもよい。
図2にゲーム装置1の概観図を、図3にその電気的なハードウェアブロック図を示す。
このゲーム装置1は、図2に示すように、ゲーム装置本体10、コントローラ20、およびバックアップメモリ203を相互に接続して構成される。
ゲーム装置本体10はゲーム進行を司る制御装置本体である。ゲーム装置本体10は、複数のコントローラ20を、コネクタCを介して接続可能になっている。またゲーム装置本体10はCD−ROM用ドライブ304(図3参照)を備え、CD−ROM等の記録媒体を着脱自あに装着できるようになっている。
コントローラ20は、各遊技者が操作する操作部としての構成を備えており、操作ボタン群201や十字キー202等を備え、コネクタPを備えた接続コード21でゲーム装置本体10と接続可能になっている。コントローラ20にはバックアップメモリ203を着脱自あに接続できる。
ゲーム装置本体10はコンピュータ装置に類似の構成を備え、図3に示すように、CPUブロック30,ビデオブロック31、サウンドブロック32、通信装置33などを備えている。
CPUブロック30は、バスアビータ300、CPU301、メインメモリ302、ROM303、及びCD−ROMドライブ304を備えている。バスアビータ300は、バスを介して相互に接続されるデバイスにバス占有時間を割り振ることにより、データの送受信を制御可能に構成されている。CPU301は、メインメモリ302、ROM303、CD−ROMドライブ304、ビデオブロック31およびサウンドブロック32、コントローラ20を介してバックアップメモリ203にアクセス可能に構成されている。
CPU301は、通信によるチーム対戦型のシューティングゲームの遂行に必要な各種のゲーム処理及び制御を行い、画像データをグラフィックメモリ311に転送するとともに音声データをサウンドメモリ321に転送可能になっている。
このCPU301が実行する処理には、コントローラ20から指令される各種操作情報の受付処理及びその受付情報のゲームへの反映処理のほか、キャラクタの挙動計算(シミュレーション)処理、光源処理、視点移動制御処理、半透明化処理などが含まれる。
挙動計算は、仮想空間でのキャラクタの動きをシミュレートするものである。これを実行するには、仮想空間におけるキャラクタのポリゴンの座標値が決定された後、この座標値を2次元視野座標系に変換するための変換マトリクスと形状データ(ポリゴンデータ)とがVDP310に指定される。なお、ポリゴンデータとは、複数の頂点の集合からなるポリゴン(多角形:主に3角形、4角形)の各頂点の相対ないしは絶対座標の座標データ群を言う。
ROM303は、イニシャルプログラムローダの格納領域である。ROM303は、本発明の記録媒体の一部を構成する要素であり、CPU301の処理に必要なプログラムが予め記録されている。なお、この記録媒体としては、他にCD−ROM等の外部メモリを用いてもよい。
CD−ROM用ドライブ304は、本発明の記録媒体の一部を構成する要素でもあり且つ外部から供給されるデータの記録媒体としてCD−ROMを用いている。また通信装置33を経由して、プログラムをメモリに転送するように構成してもよい。このように設定すれば遠隔地のサーバの固定ディスクなどからデータの転送が可能である。
ビデオブロック31は、VDP(Video Display Processor)310、グラフィックメモリ311及びビデオエンコーダ312を備えている。これらの構成により、ビデオブロック31は、3D画像データやムービー画像を生成可能に構成されている。すなわち、変換された視野座標系の形状データにこのテクスチャが貼り付けられるとともに、キャラクタ、その他のオブジェクト、ワールド座標系におけるXZ面に対応して規定される地形などのポリゴン画面と文字情報などのスクロール画面とが指定プライオリティにしたがって合成され、最終的なフレーム画像データが一定タイミング毎に生成される。これが遊技者に提供されるゲーム画像となる。
ビデオエンコーダ312は、VDP310が生成した画像データをNTSC方式等の所定のテレビジョン信号に変換し外部に接続されるメインモニタ12(テレビ受像機のブラウン管等)に出力可能に構成されている。
サウンドブロック32は、サウンドプロセッサ320、サウンドメモリ321及びD/Aコンバータ322を備えている。これらの構成によりサウンドブロック232は、波形データに基づく音声合成を行って音響信号を出力可能に構成されている。D/Aコンバータ322は、サウンドプロセッサ320により生成された音声データをアナログ信号に変換し、外部に接続されるスピーカ13(テレビ受像機のスピーカまたは音響装置のスピーカ)に出力可能に構成されている。
通信装置33は、例えばモデムやターミナルアダプタ、LANアダプタ等であって、ゲーム装置本体10と通信ネットワークとを接続するアダプターとして機能する。通信装置33は、公衆回線網に接続されるインターネットサーバ等のゲーム供給用サーバから送信されたデータを受信し、CPUブロック30のバスに供給可能になっている。通信ネットワークが公衆回線網の場合、加入者回線、専用線、有線無線の別を問わない。通信態様は、FTTH,ADSL,CATVインターネット等のブロードバンド接続でも、ISDNやアナログ回線のような非ブロードバンド接続でもよい。
続いて、図4〜19を参照して、本実施形態の通信ゲームシステムにおける処理を説明する。
図4のフローチャートは、各ゲーム装置1(1A,1B,1C,1D,…)により一定周期で実行される機能の概要を示す。図4に示すように、ゲーム画像の更新周期(例えばビデオ信号におけるフィールド期間やフレーム期間に対応した期間)に対応したタイミングが到来すると(ステップS1)、CPU301は、コントローラ20からの遊技者による操作情報の読込み(ステップS2)、通信ネットワーク2を介して他のゲーム装置とのデータの送受信(ステップS3)、および遊技者の手動設定による視点位置(ゲーム画像を生成するための仮想空間内における視点)の取得及び記憶情報から光源位置の取得(ステップS4)を順次行う。この後、CPU301は、ゲーム画面の表示やチーム対戦の勝敗(優劣)に関わる種々の処理を含むゲーム処理(ステップS5)、半透明化処理の指令(ステップS6)、及び表示処理の指令(ステップS7)を行う。
ゲーム処理には、視点の自動設定(ステップS5A)、チーム対戦におけるチーム力のアンバランスを補助する処理(ステップS5B)、空間オブジェクトとしての光線弾の投影処理(ステップS5C)、各チームのリーダの自動指定(ステップS5D)、ワールド座標系から視野座標系への投影変換(ステップS5E)、チーム間のチーム力の優劣判定(ステップS5F)、ゲーム成績の演算(ステップS5G)などが含まれる。なお、ステップS5A〜S5Gは適宜な順番で処理すればよい。
なお、上記した各処理(ステップS5A〜S5D)は、ゲームの更新周期内で完了するものではなく、何回もの更新周期を経た全体として処理されるものである。したがって、ゲーム装置は、各更新周期毎に、その処理内容(S5A〜S5G)に対応する条件をチェックし、何らかのイベントが発生していればその処理をし、イベントが発生していなかったら、他の処理へ移行していくことになる。
また、図4に示した各ステップはこの順番で処理する必要はなく、更新周期以内または一定の周期以内に実施されるのであれば、これ以外の順序で実行してもよい。
以下、上記処理S5A〜S5Gを詳しく説明する。以下の説明において、「自己キャラクタ」とは遊技者が操作可能になっているキャラクタであり、「敵キャラクタ」とは、他の遊技者によって操作可能になっているキャラクタをいう。
また、本通信ゲームシステムでは、ネットワークを介して相互に接続されている異なるゲーム装置を操作している遠隔地の遊技者同士でチームを組むことも、同じゲーム装置にコントローラをそれぞれ接続している遊技者同士でチームを組むことも可能になっている。例えば、同じゲーム装置を操作している遊技者がそれぞれ異なるチームに属し、対戦しあうようなことも可能になっている。
(視点の移動設定)
本実施形態の視点の移動設定処理を図5〜7に基づき詳述する。この視点の移動設定は、遊技者が自発的にコントローラを操作して視点を変更する従来処理とは異なり、ゲーム装置において適当な画像が表示されるように視点を移動させる自動的な処理である。具体的には、自己キャラクタの背後の視点から当該自己キャラクタの前方を視野に収めた、二次元平面に投影されたゲーム画像を生成するに当たり、ゲーム装置が、視野内に入れるべきキャラクタの仮想空間内における位置又は移動状態に応じて視点の位置を自己キャラクタの背後の空間内で移動させるものである。
今までは、このゲーム画像を生成するための視点は、遊技者の頭上後方の一定位置に固定されていた。このような方法では表示対象体(例えば複数の敵キャラクタ)が多数空間内に存在する場合、全表示対象体がゲーム画面内に入りきらないことがあった。このような事態は、例えば図5Aに示す如く、自己キャラクタおよび敵キャラクタ(目標)1,2がゲーム画面に表示されている状態において敵キャラクタ2が大きく動く場合に生じる。すなわち、敵キャラクタ2がゲーム画像のフレーム外に移動すると、図5Bに示す如く、固定されたままの視点からは敵キャラクタ1,2をフレーム内に収めることができなくなる。
そこで、本実施形態では、視野内に入れるべきキャラクタ(目標である敵キャラクタ等)の仮想空間内における位置又は移動状態に応じて視点の位置を自己キャラクタの背後の空間内で移動させる。具体的には、所定の速度で視点を移動して視野内に入れるべきキャラクタ(敵キャラクタ)を当該視野内に入れる。例えば、図5Bのように敵キャラクタが移動した場合、CPU301は視点を視線方向の後方及び/又は上方に所定速度で移動させ、敵キャラクタ1,2を共に画面内に収めるように制御する。これにより、図5Cに示すように、全表示対象体を収めたゲーム画像が表示時されるようになる。
このとき、当該視点と自己キャラクタとの距離が所定距離以内となる範囲で視点を移動させる。この距離は、あまりにキャラクタから離れ過ぎて各キャラクタがゲーム画像内に小さくなりすぎない程度の距離に設定する。あまりに視点がキャラクタから遠いとゲーム画像の臨場感が乏しくなるからである。
図6に、この視点の自動設定の具体的手順を示すフローチャートを示す。
まず、視点が通常位置である自己キャラクタの頭上後方の所定位置にある状態を初期状態とする(ステップS21)。そして、表示対象体(目標)が全て画面に収まっているか否かを判断する(ステップS22)。この判断がNOの場合、通常位置よりも後方及び/又は上方に視点位置を変更する(ステップS23)。表示すべきキャラクタと自己キャラクタとの位置関係により、変更すべき距離が大きくなる場合、視点が急激に大きく移動すると遊技者が見づらくなる。これを防止するために、視点の移動速度がある所定速度を超えないように調整した上で、目的となる視点位置に視点が移動するように視点移動制御を行う(S24)。このとき、自己キャラクタや敵キャラクタの位置から視点が後方になり過ぎているか否か、すなわち所定距離以内になっているか否かを判断する(ステップS25)。視点が後ろ過ぎる場合(YES)にはその位置を視点位置とし、まだ後退できる場合には(NO)、再びステップS22から繰り返す。自己キャラクタを十分認識でき、且つ全部の表示対象体が画面に収まっている場合には(ステップS22、YES)、その時点の変更視点を維持する(ステップS26)。
なお、視点を所定速度で移動させる場合、目標位置に視点が到達するマエニキャラクタの位置関係が変化すると視点の目標位置自体が変わることも考えられる。このような場合には常に最新の目標位置に視点を移動させたり、現時点での視点位置と最新の視点の目標位置との差分を考慮して差分が小さい場合には現時点の視点位置を優先させたり、等の処理をすることができる。
この視点の自動設定において、視点を後方及び/又は上方に移動させる限界は、自己キャラクタと敵キャラクタの区別ができる範囲に制限されている。この制限は、上記フローチャートでは自己キャラクタと視点との距離に応じて定めた。この他、例えば、自己キャラクタの表示大きさの限界を予め決めておき、この表示大きさに到達すると視点の移動を禁止するように、処理を変更してもよい。
図7は、キャラクタの仮想空間内における平面(XZ面)配置を示す。本実施形態では、自己キャラクタの頭上後方に設定される視点の位置が、図7のように自動制御される。最初には表示対象体P1(自己キャラクタ)を基準にして、視点C1が設定される。他の表示対象体がP2だけの場合には、視点C1はそのまま維持される。しかし、表示対象体がP2,P3の2つ存在する場合、視点C1の位置からでは表示対象体P3が視野に収まらない。そこで図6のフローチャートにしたがって、当該ゲーム装置は、視点を後方及び/又は上方に所定速度で移動させ、表示対象体P3が収まるまで移動させることになる。さらに、表示対象体がP2〜P4の3つ存在する場合、視点C2の位置であっても表示対象体P4が視野に収まらない。図6のステップS22〜S24の処理にしたがえばさらに視点を後方に移動させるところである。しかし、視点をC3の位置まで移動させてしまうと、自己キャラクタを他のキャラクタから認識し難くなるとともに、初期の視点C1の位置で得られていた画像からかけ離れてた画像が提供されてしまうので、ステップS25(YES)により制限が掛かり、視点はC2の位置で維持されるのである。
ここで、他の表示対象体がP2だけになった場合(つまり、全表示対象体は自己キャラクタを含めてP1及びP2の場合)、視点は再びC1に自動的に所定速度でゆっくりと戻されるように処理される。
(戦力バランス調整処理)
ステップS5Bで実行されるチーム対戦における補助処理(戦力バランス調整処理)について、図8〜11に基づき説明する。
この処理は、2人の遊技者を1チームとしてチーム同士で対戦ゲームを行うことが可能に構成された本実施形態のような通信ゲームシステムにおいて、対戦ゲームを行うチーム間における戦力バランスに対応した所定の条件を考慮して、この条件に応じてチーム間における戦力バランスを調整するための処理である。例えば、対戦ゲームに参加するチーム間のキャラクタ数に不均衡がある場合に、キャラクタの数をチーム間で一致させたり、対戦ゲームの途中で生じるチーム間の不均衡に応じて所定の基準以上優位にあるチームに負荷条件をつけたりする。つまり、複数人対複数人で対戦を行う場合に、開始時またはゲーム途中で、その戦力バランスに不均衡が生じてきた場合に、優勢なチームに負荷条件をつけたり、劣勢のチームに補助を加えたりすることで、結果的に戦力バランスをとるものである。この処理によって、チームの戦力が対等に近い状態である時間を長くすることができ、遊技者が白熱し緊張している状態を持続させることができる。
ここで、チーム間の不均衡として考えられるものは、チーム毎のキャラクタ数、ゲーム上設定されている各キャラクタの能力、当該キャラクタの対戦勝率、およびチーム毎の対戦勝率などである。
以下に具体的な補助処理を説明する。これら第1〜第3の補助処理は、そのうちの任意のものを選択的にまたは併行して実行するように構成可能である。
第1の補助処理は、チーム間のキャラクタ数の不均衡を是正するものである。ゲーム装置は、ゲーム開始時に各チームのキャラクタ数、すなわち参加する競技者の数を比較し、その数に不均衡が生じている場合に人数が不足しているチームのキャラクタ数を補う。
例えば、図8Aに示すように、チームBへの参加人数がチームAの参加人数より不足している場合、ゲーム装置は、参加人数の足りないチームBに対しゲーム装置自らが制御するキャラクタAIを追加する。このキャラクタAIは、遊技者Cの操作するキャラクタと共同してチームAと対戦することが可能に構成されている。
また、本実施形態の補助処理は、参加する遊技者の数に不均衡がある場合のみに限られない。チーム対戦を実施するための最低参加者数に満たない場合に、最低参加者数を満たすようにキャラクタを補うような場合も含む。例えば、図8Bに示すように、最低参加者数をチーム当たり二人と設定してある場合であって、チームAに参加する遊技者が1人、チームBに参加する遊技者が1人のとき、それぞれのチームに属するゲーム装置が、最低参加人数になるまでゲーム装置によって制御されるキャラクタAI(ここではキャラクタ一つ)を追加する。
以上のような補助処理により、キャラクタ数の不均衡が解消され、チームの戦力が同じになるため、処理を単純化できる。
第2の補助処理は、対戦ゲームの途中で生じるチーム間の不均衡に応じて所定の基準以上優位にあるチームに負荷条件をつける処理である。例えば、対戦ゲーム中に、いずれかのチームに属するキャラクタ数が一定数以上減った場合に、その結果生じる不均衡を是正するため、キャラクタ数が多い方のチームに負荷条件となる妨害処理を入れることである。妨害処理としては、例えばシューティングゲームであれば、優勢なチームに属するキャラクタを劣勢なチームに属するキャラクタの方向に向けることが禁止されたり、キャラクタを攻撃する際に必要な、照準のロックオン機能が優勢なチームに属するキャラクタのみ所定時間無効にされたりするようなことが考えられる。
例えば、チーム間のキャラクタ数に不均衡が生じていなければ、図9Aに示すように、チームBのキャラクタP3を操作する遊技者は当該キャラクタをチームAのキャラクタの方向に向けることができる。ここで、図9Bに示すように、チームAのキャラクタP2が消滅しチームAのキャラクタ数が減った時、チームBのキャラクタが属するゲーム装置は、チームBのキャラクタに負荷条件を課す。例えば本実施形態のシューティングゲームにおいては、あいてチームにおける複数のキャラクタから特定のキャラクタだけをねらえるようにするため、遊技者の操作により狙いたい相手キャラクタをロックオン対象として指定するロックオン機能と、遊技者の操作によって現在ロックオン対象となっている相手キャラクタの方向を自動的に向く自動追跡機能を備えている。ゲーム進行に伴なって相手チームのキャラクタ数が減少した場合にはキャラクタ数の多いチーム側において、これらのロックオン機能や自動追跡機能を所定時間あるいはチームの不均衡が解消するまで禁止する妨害処理を行う。すなわち不均衡が生じた時、ゲーム装置は、チームAのキャラクタの方向を向いていなかったチームBのキャラクタP3がチームAに属するキャラクタをロックオン対象としたりその方向を向くことが禁止される。不均衡が解消された場合(例えばチームBのキャラクタのいずれかが消滅したりチームAのキャラクタが増加したような場合)または所定時間が経過した場合には、この妨害処理は解除される。このような補助処理により、キャラクタ数で優位なチームの戦力を強制的に一時的に低下させ、劣勢になったチームに逆転の機会とその後の戦略を考える時間を与えることができる。
第3の補助処理は、対戦ゲームの途中でチーム内において一のキャラクタが他のキャラクタを助けるような処理である。各キャラクタにはゲーム上の戦力や耐久性を示す、体力パラメータが設定されている。本実施形態の通信ゲームシステムでは、この体力パラメータをゲーム装置間の送受信で相互に通信することが可能に構成されている。この体力パラメータを受信したゲーム装置に属するキャラクタは、受信した体力パラメータの示す「体力」に対応してその戦力を上昇させることができる。このような機能により、チーム間のキャラクタ内で「助け合う」ことが可能になる。
図10および図11のフローチャートに基づいてこの補助処理の具体例を説明する。図10はあるキャラクタについて、戦力、つまり体力が十分ある場合の処理であり、図11は戦力が減少している場合の処理である。ここで、キャラクタ各ゲーム装置では、キャラクタの体力パラメータ等の送受信によって同じチームに属する味方のキャラクタの戦力状態を監視しているものとする。また、この補助処理を行う際、各ゲーム装置はネットワークを介するデータの送受信において生ずる時間遅延を考慮して処理を行うものとする。
キャラクタの体力が十分ある場合には、まず、仮想空間内における近距離に味方となるキャラクタが存在し、かつそのキャラクタの体力が低下しているか否かを判定する(ステップS31)。体力が低下しているとは、例えば、キャラクタの体力パラメータが一定値以下になっていたり、自己キャラクタとの比較において相対的に体力パラメータ値が低かったりするような場合である。体力が低下しているキャラクタを発見した場合(ステップS31、YES),ゲーム装置は自己キャラクタの余剰な体力分を体力パラメータとして体力が低下しているキャラクタに送信する(ステップS32)。体力が低下していたキャラクタの属するゲーム装置では、この体力パラメータを受信した場合(ステップS41、YES),この体力パラメータに応じて自己キャラクタの体力をアップさせ、受信した旨の返信をする(ステップS42)。体力パラメータを送信したゲーム装置では、この返信が到着した場合には(ステップS33、YES)、処理を終了する。一方、この返信が到着しない場合(ステップS33、NO)、一定期間待ち(ステップS34、NO〜S33)、一定期間経過したら(ステップS34、YES)処理を終了する。返信が来た場合には、ゲーム装置は自己キャラクタの戦力を、送信した体力パラメータ分だけ減少させる。一方、返信が来ずタイムアウトになった場合には、自己キャラクタからの戦力削減を禁止する。このような処理によって、確実な体力の受け渡しが確実になる。
なお、上記処理では近隣の体力が減少しているキャラクタを体力十分なキャラクタが助けるような処理になっているが、体力が減少してるキャラクタが自ら体力を分けてもらうように近くの味方のキャラクタを探知するように処理してもよい。ここで体力を分ける処理とは、体力をもらいたいまたは分け与えたいキャラクタが、味方のキャラクタに近寄るなどの処理が考えられる。ただし、敢えて倒されたり弱っている味方キャラクタがいても体力の分配などを行わずゲーム処理を続行したい場合も存在するので、キャラクタ同士が体を接触させない限り体力の分配が行われないように設定することも意味がある。
また、近くに体力が低下した味方のキャラクタが存在しない場合、ゲーム装置は、遊技者の操作によって、味方のキャラクタを探索する範囲を広げ、戦力の低下した味方キャラクタを探し出し、その方向へ自動的に進むように構成してもよい。この処理により、味方のキャラクタを助ける確率を高めることができる。また、このような探索処理を戦力が低下していない味方のキャラクタに対して実行可能に構成してもよい。このように構成すれば、遊技者は自己キャラクタの戦力が低下したときに、戦力十分な味方のキャラクタを探し出し、そのキャラクタから体力をもらうことができるようになる。これらのような場合に、味方のキャラクタを探索する処理を、遊技者の操作に頼ること無く、自動的にゲーム装置側で行うように構成してもよい。このとき遊技者は味方のキャラクタを探しにいくという意図を示すための簡単な操作をするだけで済む。
(光線弾の投影処理)
次いで、ステップ5Cで実行される光線弾の投影処理を、図12,13に基づき説明する。
本実施形態における投影処理は、仮想空間内に設定された地形表面に対する空間オブジェクトの投影像を模した投影像オブジェクトを生成し、その投影像オブジェクトを空間オブジェクトの移動に伴って移動させ、仮想空間内における空間オブジェクトの位置と仮想空間内に設定された仮想光源の位置とに応じて表示させる投影像オブジェクトの大きさを変更するものであり、その際、当該空間オブジェクトの地形表面からの距離が基準距離を超えた場合には当該投影像オブジェクトの大きさを所定の大きさに留める処理である。
図12AおよびBにこの投影処理の仮想空間における概念を示す。図12Bに示すように、本対戦ゲームにおいて、遊技者はコントローラを操作して自己キャラクタCRの武器WPから空間オブジェクトとしての光線弾OBを敵キャラクタ目掛けて発射させることが可能になっている。ゲーム装置は、この光線弾OBの位置と地面ETとの距離に応じて、投影像オブジェクトとして光線弾OBの影SDを生成し、地面ET上に配置させる(投影させる)。この影SDは光線弾OBの移動に伴って移動する。ここで、本対戦ゲームにおける光線弾OBは光っているという想定であるため、影SDは暗い画像ではなく光が当たっている画像となる。光線弾OBの位置に応じて影SDの大きさを変えるために、発射された光線弾OBの真下に光源LS(例えば点光源)を仮想的に配置し、この光源から地面方向に向けて照射される光を用いて行う。このため、図12Aに示すように、光線弾OBの地面ETからの高さHが高くなるにつれて、影SDの面積が小さくなるように制御されている。
今までのゲームでは、空間オブジェクトの地面からの高さとは無関係にこの影の投影処理が行われていた。しかし、本実施形態では、ゲーム装置は、点光源LSの高さHに制限値HLIMを設け、光線弾OBの高さがこの制限値HLIMを超えた場合には、点光源LSを光線弾OBから切り離し、影SDの大きさが小さくなりすぎないように処理している。
この処理を図13のフローチャートに基づいて説明する。まず、ゲーム装置は操作情報やキャラクタCRの位置情報及びそのキャラクタの腕部分の傾き情報などから光線弾OBの地面ETからの高さHと発射方向を、処理周期毎に更新していく(ステップS61)。そして、この高さHと高さ制限値HLIMとを比較し(ステップS62)、H≦HLIMとなる場合(YES)、光線弾OBの高さHに応じた大きさで投影物オブジェクトである影SDの画像を生成し地面ET上に投影する(ステップS63)。一方、ステップS62においてH>HLIMとなる場合(NO)、光源LSを高さ制限値HLIMに留め、その高さから投影される大きさで影SDを投影する(ステップS64)。この処理により、図12Aにおいて光線弾OBの高さHがH1やH2である場合のように光線弾OBの高さが高さ制限値HLIM以内であるとき、光線弾OBの光る影SDは高さに応じて徐々に小さく投影される。一方、光線弾OBの高さHがH3となった場合のように光線弾OBが高さ制限値HLIMを超えて飛翔しているとき、光線弾OBの影SDは高さ制限値HLIMに対応した面積の影SDとして一定の大きさで投影される。この処理により、光線弾OBの影SDがその高さに応じて無制限に小さくなって遊技者がその影を認識できなくなることがない。このため、本実施形態によれば、光線弾OBを高く発射させたとしても、遊技者はその軌跡を影SDの存在によって容易に確認できる。
(リーダーの自動設定)
次いで、ステップ5Dで実行されるリーダーの自動設定処理を、図14,15に基づき説明する。
このリーダーの自動設定処理は、少なくとも2人の遊技者を1チームとしてチーム同士で対戦ゲームを行うことが可能に構成された通信ゲームシステムにおいて、対戦ゲームを行っているチーム間の優劣を、各チームでリーダーとして指定されたリーダーキャラクタが対戦ゲームにおいて有効であるか否かを判定し、リーダーキャラクタが有効であると判定された場合に当該リーダーキャラクタが属するチームが勝ちであると判定するものである。
チーム対戦におけるゲームの勝敗は、一般には、どちらかのチームのキャラクタが総て消滅し残存するキャラクタ数が零になった時点で決められる。しかし、このような条件で勝敗を決めると、決着まで時間が掛かかり過ぎる場合がある。そこで、本実施形態では各チームに属するキャラクタのなかで一つのリーダーキャラクタ(代表者)をゲーム装置が自動的に指定し、リーダー以外のキャラクタの生死は問わずに、リーダーキャラクタが最後まで生き残った方のチームを勝ちとするように構成している。これにより、決着までの時間を短縮し、また決着判定のための演算処理を大幅に軽減することができる。
図14に基づいて、このリーダーの自動設定処理を説明する。まずゲーム装置は、ゲームの開始前に、各チームに属するキャラクタのうちの何れか一つをリーダーとして指定する(ステップS51)。どのキャラクタがリーダーに指定されているかの情報は、当該対戦ゲームに参加する各ゲーム装置間で送受信され共有されている。対戦が開始されると(ステップS52)、対戦ゲーム処理が進められる。ここで、一の自己キャラクタに関するゲーム処理に関し、相手チームのリーダーキャラクタを消滅させることができたと判定した場合には(ステップS53、YES)、ゲーム装置はその自己キャラクタの属するチームが勝ったと判断しそれに応じた処理をする。一方、自己キャラクタの属するチームのリーダーキャラクタが消滅させられたと判定した場合には(ステップS53、NO;ステップS54、YES)、ゲーム装置は自己キャラクタの属するチームが負けたと判断しそれに応じた処理をする。このような処理は、ゲームが続行する限り(ステップS55、NO)続けられる。このリーダー自動設定処理により、勝敗の判定はリーダーとして指定されたキャラクタの生死に限定されるので、キャラクタ全員の戦力を合計するような演算をしたり残っているキャラクタ数を総計したりする演算が不要になり、演算負荷が軽減される。またゲーム終結までの時間を早めることもできる。
また、対戦ゲームが各回毎に勝敗をつけるステージを複数回実行可能に構成されている場合には、リーダーとして指定されるキャラクタを各回のステージ毎に自動的に交替させるように構成してもよい。このように構成する場合、ゲーム装置は、各ステージ毎のゲームにおけるリーダーキャラクタを毎回異ならせる。リーダーキャラクタはチーム内で交代で割り当てられる。対戦ゲームの開始前に、総てのステージにおけるリーダーキャラクタを割り振ってしまってもよい。このように事前に割り振れば、リーダーキャラクタをステージ毎に指定するための処理時間を軽減できる。
ステージ毎にリーダーを交替する場合、ゲーム装置は、最終回のステージにおいてそれ以前のステージ中で成績が最も良かったリーダーキャラクタを自動的に再指名するように構成されていてもよい。つまり、最終ゲームの場合にのみ、今回の同一カードの対戦成績においてチーム内で最も勝率が高かったキャラクタ(遊技者)がリーダーキャラクタとなるようにゲーム装置が指令する。このとき勝率の高いキャラクタやチームを決定するために、キャラクタごとの勝率やチームとしての勝率を記録する記録手段を備える。なお、最も勝率が高かったキャラクタをリーダーとする処理を最終ステージのみならず、他のステージで実行可能にしてもよい。
図15に基づいて、このリーダー自動設定処理の具体例を示す。この対戦ゲームは、勝敗を3ステージ(ゲーム、試合)で決するように設定されており、2ゲームを先に取ったチームが勝ちと判定される。図15Aにおいて、第1試合目はリーダーキャラクタP1で戦ったチームAの勝利となり、第2試合目はリーダーキャラクタP4で戦ったチームBの勝利となった。この結果、第3試合目の対戦成績は1対1の引き分けであった。そこで、第3試合目の開始時において、ゲーム装置は、チームAおよびBの各々において、そのチームが勝利を収めたときのキャラクタをリーダーとして再び選出する。つまりチームAではP1が、チームBではP4が、それぞれリーダーキャラクタを勤めるように自動設定される。この処理によれば、最終対戦が強いリーダーキャラクタに率いられるチーム同士の対戦となるため、最終戦として十分なゲームの緊迫感や盛り上がりを提供可能である。
なお、この処理は戦力バランス調整処理と密接に関連する。すなわち、いずれかのチーム内においてリーダーキャラクタ以外のキャラクタの体力が例えば敵キャラクタによってダメージを受けた等して低減した場合に、当該リーダーキャラクタは、自らの体力をこの体力が低減したキャラクタに分配させることが可能に構成されている。このような処理により、キャラクタ数の不均衡による不利を解消し、先に倒されたキャラクタを操作していた遊技者に再度ゲームに復帰する機会が与えられ、一旦はキャラクタがダメージを受けた遊技者であってもゲームへの意欲を保つことができる。
(優劣判定)
次いで、ステップ5Fで実行されるチーム間の優劣判定処理を、図16に基づき説明する。
本実施系体における優劣判定処理は、少なくとも2人の遊技者を1チームとしてチーム間で対戦ゲームを行うことが可能に構成された通信ゲームシステムにおいて、対戦ゲームを行っているチーム間の優劣をチーム内における対戦能力の合計に基づいて判定するものである。具体的には、各遊技者が操作するキャラクタの対戦ゲームにおける対戦能力の最大値に占める当該対戦能力の現在値の割合を演算し、この割合をチーム毎に合計してチーム間の優劣を決めるものである。
この優劣判定処理は、チーム対戦モードのゲームに好適である。言い換えれば、各チームで総計したゲーム上の戦力、つまり体力やパワーを対戦チームとの間で比較するものである。
各ゲーム装置は各チームに属する各キャラクタに与えられている戦力をしめすパラメータ、例えば体力パラメータの最大値を記憶している。一方で各ゲーム装置は各キャラクタに対する操作情報、移動距離情報、およびダメージ状況から体力の現在値を演算する。そしてゲーム装置はこの体力演算値が予め記憶している体力最大値(100%)に占める割合を各キャラクタ毎に演算する。
図16にこの計算例を示す。この例では、チームAおよびBのそれぞれにキャラクタが二つずつ参加している。対戦が終了した時点で、まずゲーム装置は体力評価の現在地の最大値に占める割合を計算する。例えば、チームAのキャラクタP1とP2の体力評価の現在値は夫々48%と70%となり、チームBの体力評価の現在値は60%と38%となる。次いでゲーム装置はチーム毎の体力評価の現在値を合計してチームの総合値を計算する。ここでは、チームAについては118%、チームBについては98%となる。最後にゲーム装置は両チームの総合値を比較して優劣を判定する。ここでは、総合値の高いチームAの方が優勢であると判定することになる。
なお、各チームの総合値は、ゲージ又は数値としてゲーム画面にリアルタイムに表示される。また、各キャラクタ毎の体力現在値の割合を示すライフメータを上記総合値と共に表示するように構成してもよい。
(半透明化の処理)
図4のステップS6で実行される半透明化処理を図17,18に基づき説明する。
本実施形態の半透明化処理は、仮想空間内で少なくとも一部が重なり関係にある複数の表示対象物を特定し、この特定された複数の表示対象物の各々について各表示対象物がゲーム画像として表示される際の面積を比較し、この比較によってより小さい面積の表示対象物を半透明し、さらにこの半透明化処理された表示対象物をゲーム画像の視線から見てより手前に配置してゲーム画像を生成するものである。
この半透明化処理は、例えば表示すべきオブジェクトとして構造物(建物の柱や船の底面な等)が水中に全体に又は部分的に没している状態を表すために適する処理である。
図17のフローチャートに基づいてこの半透明化処理を説明する。CPU301は、図4の更新周期になる毎に図17に示す処理を行う。まず、ゲーム装置は公知の重なり判定方法を適用して構造物などのオブジェクトと他のオブジェクトとが視点から見て重なっているか否かの重なり具合を判定する。その結果、互いに重なっておりかつ半透明化処理が必要となる対象物を特定される(ステップS71)。次いで、ゲーム装置は、特定された例えば2つのオブジェクトのゲーム画像上での表示面積を相互に比較する(ステップS72)。この比較結果、CPU301は表示面積がより小さい方の対象物の半透明化処理をVDP310に指令する(ステップS73)。これに応答して、VDP310は指令されたオブジェクトに適用されるテクスチャの一部分に対し当該テクスチャとその背後のオブジェクトのテクスチャとの間で、画素間の色成分の加算や乗算等の半透明化演算処理を行う。さらにCPU301は、半透明化した対象物を視点側に配置するようにVDP310に指令する(ステップS74)。これら処理の結果、図18Aに示すように、海面SEに一部が没する柱PLを表現させる場合、柱PLのオブジェクトの表示面積が小さいため柱PLが半透明化処理され、柱PLのテクスチャが視点側に置かれる。すなわち、海面SEのテクスチャは柱PLのテクスチャの背後に置かれる。このため、ゲーム画像を表示させるために両オブジェクトを重ねて表示すると、それらの重なり部分PL´において柱PLのテクスチャを通して海面SEの色が一部透けて見えることになり、現実に柱PLの一部PL´が海面SEに没しているように見せることができる。
今までの例では、海面SEを表すテクスチャ全体に演算を施して半透明化処理を施している場合もあったため演算量が大きかったが、本実施形態では半透明化処理の負担が少ない方のオブジェクトが選択されるので、半透明性を維持しつつ半透明化処理の演算量を抑制できる。
(他のゲーム装置との間のデータ通信)
本実施形態では、ゲーム装置の夫々は、所定のイベントが発生した場合に、当該イベントが発生した旨を示すデータを、当該対戦ゲームを実施している他のゲーム装置に送信し、他のいずれかのゲーム装置からのデータを受信する。そして、受信したデータに基づいたゲーム処理を実行し、この処理の結果を示すデータを他のゲーム装置に送信する。そして、処理の結果に基づいたゲーム画像を生成するようになっている。具体的には、受信側のゲーム装置にとって不利なイベント(例えば攻撃を受けるなど)が発生した場合に、CPU301は当該ゲーム装置で処理を進める前にこのイベントが発生したことを示すデータを当該受信側のゲーム装置に送信する。
例えば、図4におけるステップS3における送受信において、イベントを発生させたゲーム装置においてそのイベントに基づく処理をする前にそのイベントが発生したことを示すデータが他のゲーム装置(味方チームであったり相手チームであったりする)に送信される。これにより、他のゲーム装置は送信されてきたデータが示しているイベントに基づいたゲーム処理をし、その処理結果に基づいてゲーム画像を生成し自らのゲーム装置のゲーム画面に反映させる(例えば、爆発シーンが表示される)。
さらに本実施形態では、いずれかのゲーム装置において発生したイベントに対応して他のゲーム装置から返信される処理の結果を示すデータが、当該対戦ゲームを実施している総ての他のゲーム装置について受信された後に、受信された複数の処理の結果に基づいたゲーム画像を生成するように構成されている。具体的には、受信側のゲーム装置ではそのイベントを認識してから実際のゲーム処理(例えば爆発処理)をしてその処理結果を送信側のゲーム装置に返すようにしている。このため、通信処理で遅延が生じ、その遅延時間の間に受信側のゲーム装置で操作される相手キャラクタが移動していたような場合であっても、受信側ゲーム装置では、イベント(攻撃等)を処理して攻撃を受けたと判断してからキャラクタが爆発するという処理が行われる。また送信側ゲーム装置でも、相手キャラクタが遅延時間の間に移動していたとしても、攻撃を仕掛けたときの狙いが正確であれば、確実に相手キャラクタを倒すことができるようになる。このため、送信側ゲーム装置を操作する遊技者は実際に表示されてるゲーム画像から認識されるよりも有利な結果を得ることができ送受信の遅延がストレスにならない。また受信側ゲーム装置でもキャラクタが倒されたことが送信遅延によるものではないので、画面上認識できる状況よりも不利な結果が生じても納得できる。
ここで、各ゲーム装置では、イベントが発生した旨を示すデータとして、少なくとも、当該イベントを発生させた自己のゲーム装置を特定する情報および当該イベントの内容を示す情報を含ませてもよい。
また各ゲーム装置では、イベントが発生した旨を示すデータを受信した場合に、当該イベントを発生させたゲーム装置および当該イベントの内容に対応させたゲーム画像を生成し、処理の結果を示すデータとして、少なくとも、当該イベントを発生させたゲーム装置を特定する情報、当該イベントの内容、および当該イベントに対応させた自己のゲーム装置における処理の結果を含ませてもよい。
これらの遅延防止処理を図19に基づいて説明する。この例では図1に示すゲーム装置1A〜1Dが相互に対戦ゲームをしているものとしている。
いま、図19Aに示すように、ゲーム装置1Aはあるイベントに基づいてゲームを進行させなければならない状態が出現したら、その内容を示すイベント発生データaを他のゲーム装置1B,1C,1Dにそれぞれ送信する。
次いで、図19Bに示すように、ゲーム装置1Aから送信されてきたイベント発生データを受信したゲーム装置1B,1C,1Dは、この受信データを処理して処理結果ab、ac、adを得て、その結果に基づいた画像を自己のゲーム画面に反映させる。
次いで、図19Cに示すように、ゲーム装置1Aは他のゲーム装置1B,1C,1Dが自らの装置で処理して得られた処理結果を示す処理結果データab,ac,adを受信する。
さらに、図19Dに示すように、ゲーム装置1Aは対戦している他の総てのゲーム装置1B,1C,1Dから処理結果データを受信したことを確認してからそれらのデータおよび自らのイベント発生データaに基づいて処理を実行し、一定時間遅延させたデータを表示し、その処理結果のデータaaを作成し必要であれば他のゲーム装置に送信する。
その他のゲーム装置1B,1C,1Dにおいても同様にデータの送受信およびそのデータに基いたゲームへの反映が行われる。すなわち、図示していないが、他のゲーム装置も自らのイベント発生データを他のゲーム装置に送信し、その他のゲーム装置はそれらを受信する。そしてイベント発生データに基づくゲーム処理を実行し、処理の結果をイベント発生データを送信したゲーム装置に返信する。イベント発生データを送信したゲーム装置は、それらの処理結果データが総て揃ったところでゲーム処理を実行し最終的な処理結果bb、cc、ddを得るのである。
これら一連の処理により、全部のゲーム装置1A〜1Dはほぼ同期したゲーム画面を表示することができる。
本実施形態によれば、自らの装置で発生したイベントは自装置で処理してから相手方に通報するという従来方式と比べて、相手方での表示に処理時間に因る遅れの影響が出ず、進行の早いゲームであっても遊技者自らがした操作とそれに対応して生じる相手キャラクタの変化(爆発等)が位置的にずれて表示されることが無くなり、違和感が無くなる。つまり、データを受信したゲーム装置は、自装置のゲーム画面に影響のある結果を迅速に画面に反映させることができる。
(産業上の利用可能性)
本発明によれば、種々の利点を得ることができる。
前述した視点の自動設定処理によれば、ゲーム装置が、視野内に入れるべきキャラクタの仮想空間内における位置又は移動状態に応じて視点の位置を自己キャラクタの背後の空間内で移動させるので、自己キャラクタに対応して設定された視点位置が自動的に修正され、必要なキャラクタを確実に視野内に入れることができる。
このとき当該視点と自己キャラクタとの距離が所定距離以内なる範囲で視点を移動させるので、距離が遠くになりすぎ広過ぎる視野を必要しなくなった場合には、適正な視点の位置に自動的に戻される。これにより、常に緊迫感及び臨場感のある画面が提供される。
また、このとき所定の速度で前記視点を移動するので、急激な画面変化がなされて見難くなったり、違和感を与えることもない。また、自己キャラクタの存在を認識できる範囲の視点移動に止められるので、自己キャラクタを画面上で見失うこともなく、安心してゲームに集中できる。
本発明の戦力バランス調整(補助)処理によれば、対戦ゲームを行うチーム間における戦力バランスに対応した所定の条件を考慮して、この条件に応じてチーム間における戦力バランスを調整するので、各チーム1人ずつの遊技者あっても、またグループの人数にアンバランスがあっても、これを調整して白熱したチーム対戦を行うことができる。
また、チーム間における戦力バランスに不均衡がある場合にキャラクタの数をチーム間で一致させるので、対等で平等なゲーム環境を提供可能である。
また、対戦ゲームの途中で生じるチーム間の不均衡に応じて所定の基準以上優位にあるチームに負荷条件をつけるので、優位なチームの戦力を一時的に低下させ、劣勢なチームには逆転の機会を与えて、ゲームに緊迫感を持たせることができる。
また、対戦ゲームの途中でチーム内において一のキャラクタが他のキャラクタを助けるようにしたので、チームプレイやチームワークという実際のスポーツのような面白さを提供することができる。
本発明における投影処理によれば、空間オブジェクトの地形表面からの距離が基準距離を超えた場合には当該投影像オブジェクトの大きさを所定の大きさに留めるようにしたので、光線弾を高く発射させる場合でも、遊技者はその軌跡を投影物オブジェクトによって容易に確認できるようになる。
本発明におけるリーダーの自動設定処理によれば、対戦ゲームを行っているチーム間の優劣を、各チームでリーダーとして指定されたリーダーキャラクタが対戦ゲームにおいて有効であるか否かを判定するので、毎回全キャラクタの状態のチェックする必要が無く、リーダーキャラクタだけに対しチェックすればよいので、勝敗判定の処理を大幅に軽減できる。
また、リーダーとして指定されるキャラクタを各回のステージ毎に自動的に交替させるようにしたので、何度もリーダー指定を行う処理を省くことができ、遊技者の操作負担や装置の演算上の負担を軽減できる。また、リーダーキャラクタの有効性が勝敗を決めるので、リーダーキャラクタを中心とした戦術を考えることができゲーム内容を多様にできる。特に本発明ではリーダーを設定してそのリーダーを倒すことを勝利条件とし、いずれかのチーム内において前記リーダーキャラクタ以外のキャラクタの体力が低減した場合に当該リーダーキャラクタの体力を当該体力が低減したキャラクタに分配させるので、キャラクタ数の不均衡による不利を解消し、先に倒されたキャラクタを操作していた遊技者に再度ゲームに復帰する機会が与えられる。
本発明の優劣判定によれば、対戦ゲームを行っているチーム間の優劣をチーム内における対戦能力の合計に基づいて判定するので、いずれのチームが優位にあるかの状態を常に一目で判断できる。従来は各キャラクタのパワーのみを参照して優劣を判断していたが、この処理によればチーム間の優位を一目で把握できる。
また、対戦ゲームにおける対戦能力の最大値に占める当該対戦能力の現在値の割合を演算し、この割合をチーム毎に合計してチーム間の優劣を決めるので、処理が簡単でかつ優劣の状況を的確に把握させることができる。さらに、このチーム間の優劣判断の結果を他の処理、例えば戦力バランス調整処理などに利用しやすいものにできる。
本発明の半透明化処理によれば、複数の表示対象物の各々について各表示対象物がゲーム画像として表示される際の面積を比較し、この比較によってより小さい面積の表示対象物を半透明にするので、半透明性を確保しながら、演算負荷を大幅に減らすことができる。
本発明の通信における遅延防止処理によれば、所定のイベントが発生した場合に、当該イベントが発生した旨を示すデータを他のゲーム装置に送信し、他のゲーム装置から処理結果が返信された後にゲーム画像を生成するので、通信ゲームシステムに指摘されていたような処理の遅延に基づく不自然な画像が表示されることを防止できる。
以上説明したように、本発明によれば、従来の通信ゲームシステムで指摘されていたゲーム画面の表示、チーム間の優劣判定、及びゲームデータの通信遅延に起因する諸問題を改善可能に構成されているので、演算処理を抑制して高速化を図ると共に、チーム対戦におけるゲームの質の向上を図ることができる。
なお、本発明は上述した実施形態に限定されることなく、本発明の特許請求の範囲に記載の要旨の範囲内で種々に変形、変更できるものである。