以下、本発明の一つの実施形態を図1〜図21を参照して説明する。この実施形態は、本発明の画像処理装置を一体に組み込んだゲーム装置に関する。なお、ここでのアプリケーションソフトはサッカーゲームのソフトである場合を例示するが、野球ゲーム、ソフトボール、バスケットボールなど、その他のゲームソフトであっても同様に実施できる。
図1は、本実施形態に係るゲーム装置のブロック構成の概要を示す。このゲーム装置は、CPU(中央処理装置)1を有し、このCPU1にバスBUSを通してROM2、作業用RAM3、入力装置4およびビデオディスプレイプロセッサ(VDP)5が接続されている。CPU1は、ROM2に予め格納されているゲームのプログラムを順次実行する。本発明に関わる種々の処理は、ROM2に格納されているプログラムをVDP5が一定周期で実行する中で実現される。この本発明に関わる処理としては、キャラクタの視線制御の処理、観客の挙動制御の処理、表示画面のカラー調整としてのフォグ制御の処理の3つである。このため、ROM2にはCPU1やVDP5で処理するプログラムのほか、キャラクタのポリゴンデータ、および、それら3つの処理に必要なプログラムおよび固定データ(観客のポリゴンデータ、フォグの基準データなど)が予め格納されている。
作業用RAM3は、ゲーム実行中の各種データを一時的に記憶する。入力装置4は、ジョイスティックなど、プレーヤが操作する操作器を備え、キャラクタの移動、モーションを制御する場合など、ゲーム進行に必要なデータを入力するために使用される。
VDP5には、ビデオRAM(VRAM)6、描画装置7、作業用RAM8が接続されている。VRAM6にはROM2からのポリゴンデータが格納される。このポリゴンデータのそれぞれは、表示すべき頂点数分の座標データと、それら頂点のカラーパレットとして与えられる色データとを備える。VDP5はデジタル信号プロセッサ(DSP)を有している。このVDP5も、ROM2に予め格納されている画像処理専用のプログラムを、フレームの切換タイミングなどの一定周期のタイミング信号に呼応して起動し、実行する。VDP5の処理により、VRAM6に記憶されているポリゴンデータが座標変換処理されて、描画装置7に渡される。
描画装置7にはテクスチャデータROM9およびフレームバッファメモリ10が接続されている。描画装置7により、座標変換されたポリゴンデータにテクスチャが貼り付けられ、フレームバッファメモリ10に1フレーム(画面)分のピクセルデータとして書き込まれる。
フレームバッファメモリ10はD/A変換器11を介してCRTなどの表示装置12に接続されている。D/A変換器11はビデオ信号発生回路として機能するもので、フレームバッファメモリ10からピクセルデータを読み出し、アナログ信号に変換する。この変換データはビデオ信号として表示装置12に順次送られ、画像が表示される。
さらに、このゲーム装置はバスBUSに接続されたフォグ回路13および実時間クロック14を備える。実時間クロック14は日常の実際の時間データをCPU1に与えるようになっている。フォグ回路13は後述するように、ゲーム装置が操作される時間(すなわち、プレーヤがゲームを行う日常の実際の時間)に応じて、表示画面のカラーをフォグデータと呼ばれる別途設定したカラーデータでマスクして調整する、いわゆる「フォグ機能」を発揮するもので、CPU1の指示の下にフォグデータを生成してVDP5に送るようになっている。
図2に、CPU1により実行されるフレーム毎の処理の一例を示す。まず最初に、CPU1は、プレーヤの操作情報に対応したキャラクタのモーション・コマンド(走る、走る方向を変える、ボールを蹴るなど)を入力装置4から受け取り、3次元仮想空間におけるキャラクタのモーションの計算を実行する(ステップS1)。
次いで、CPU1は、サッカーボールの位置を進めるなど、3次元仮想空間におけるボールの処理を行い(ステップS2)、さらに、3次元仮想空間におけるコリジョン(当たり)の処理を行う(ステップS3)。このコリジョン処理は、キャラクタと地面との間、キャラクタ同士、キャラクタとボールとの間など、様々なコリジョン判定およびその処理が実行される。次いで、CPU1は、プレーヤが操作しているキャラクタ(ロボット)の、プレーヤからの操作情報に対応した仮想3次元空間での挙動処理を行う(ステップS4)。
さらに、CPU1はキャラクタの視線制御の処理を行う(ステップS5)。この視線制御は本発明の特徴との一つを成すもので、競技中のキャラクタの動作の多様化を計り、サッカーゲームのリアル感を増加させようとするものである。この処理の詳細は後述する。
この視線制御の処理済むと、CPU1は、サッカー競技場のフィールドの処理を行う(ステップS6)。このフィールドの処理は、仮想3次元空間のフィールド内に居る各キャラクタの位置を参照して、どのキャラクタがオフセットライン内に居るか、どのキャラクタがゴールエリアに居るかなどを判断して、ゲームを進める上での戦術に関わる必要な処理を指令するものである。
この後、CPU1は、観客の挙動制御の処理を行い(ステップS7)、さらにフォグ制御の指令を出す(ステップS8)。これら2つの処理も、本発明の特徴の一部を成すものである。観客の挙動制御の処理は、演算負荷を押えた状態で、観客の挙動を多彩に表現し、リアル感および臨場感を向上させようとするもので、その詳細は後述する。また、フォグ制御の処理は、上述したフォグ機能を使用して、プレーヤが実際にゲームを行っている1日の内の実時間に合わせたカラー画面の明暗度(昼間の試合か、夜間の試合かなどによるカラー調整)の制御を行い、リアル感および臨場観を盛り上げようとするもので、その詳細は後述する。
最後に、その他の必要な処理を実行する(ステップS9)。なお、ステップS5における視点制御がキャラクタの注視点のみが決定され、実際にキャラクタを振り向かせるモーションは、次の処理時間S1において行われるようにしても良い。ステップS4でも同様にしても良い。つまり、データ取得、注視点決定から、実際いそちらに向くモーションが行われるまで、最大1/60秒のタイムラグを設けることができる。
CPU1は以上の処理をフレーム毎に繰り返す。このため、ゲームの進行に伴って、CPU1はプレーヤ操作に応じたモーションなどのコマンドを、VDP5に送る。VDP5には、またCPU1の制御の元で、ROM2から必要なポリゴンデータが渡される。そこで、VDP5は、ポリゴンデータをVRAM6に一時記憶させるとともに、コマンドにしたがってポリゴンデータを仮想3次元空間から透視2次元空間に座標変換し、この変換座標を描画装置7に渡す。描画装置7は座標変換されたポリゴンデータにテクスチャを貼り付け、フレームバッファメモリ10に書き込む。この結果、フレーム毎にピクセルデータが更新された画像が表示装置12に表示される。
上述したキャラクタの視線制御の処理を図3〜図7に基づき説明する。この処理は上述した図2のステップS5で実行される処理である。
最初にキャラクタCの視線方向を決める角度演算の原理を説明する。いま、キャラクタCが3次元仮想空間の座標(xp,yp,zp)に位置し、また対象体としてサッカーボールBが同空間の座標(xt,yt,zt)に位置しているものとする。この場合、図3に示すy軸方向からみたときのジオメトリから、x'=xt−xpz'=zt−zpの値が演算でき、この値x',z'からキャラクタCとボールBとの間のx−z面上での角度θyおよび距離Lが計算できる。同様に、このジオメトリから横軸にキャラクタCとボールBとの間の距離Lをとり、縦軸をy軸としたときのジオメトリを図4に示すように想定できる。つまり、キャラクタCの座標(yp,Lp)およびボールBの座標(yt,Lt)を設定できる。この場合、y'=yt−LtL'=Lt−Lpの値が演算でき、このy'およびL'からy−L面上でのキャラクタCのボールBを見つめる角度θyが計算できる。つまり、各キャラクタについて、例えばボールをみるときの視線はθy,L,θxのパラメータで決まる。対象体がボールに限らず、相手プレーヤ、ゴール、審判であったりする場合も同様に計算できる。つまり、自己キャラクタの座標と相手プレーヤや審判の所定点の座標、ゴールの例えば中心位置の座標とを与えてやればよい。
このように視線方向が決まるが、キャラクタが実際にその方向に視線を向ける過程においては、種々の体の向け方(回転の仕方)がある。この様子を図5に示す。本実施形態では、視線制御時に体を向ける(回転させる)部分として、キャラクタCの頭部HD、胴部BD,腰部HPを指定している。そして、1)頭部HDの回転(上下方向、横方向の回転)を先行させ、これに胴部BDの回転を追随させ、これに腰部HPの回転を追随させる、2)頭部HDと胴部BDの同時回転を先行させ、これに腰部HPの回転を追随させる、3)胴部HDのみ回転させる、などの回転状態を競技の場面毎に、キャラクタの置かれている状況毎に制御できるようになっている。この制御は、例えば、フレーム毎に各部HD,BD,HPのそれまでの回転角を記憶しておき、次フレームでは、現在の回転角に微小角度を増加させたモーションを指令すればよく、各部毎に演算角度θx,θyまで達したフレームで回転モーションの指令が終わるようにすればよい。
なお、一般的には、人間の動きには構造的な法則性があり、モーションさせるときには、この法則性を加味すると最も自然な動きに見える。例えば、振り向くときには図5にも示した如く、首の回転速度が最も速く、次に上半身、最後に全身となる。そこで、振り向きの場合、首を上半身より速く、かつ上半身を全身より速く回転させることが望ましい。
また、頭部HDの回転角度が一定値に達した時点で胴部BDの回転を開始させるような処理によって、頭→胴→腰の回転タイミングをずらして表現しても良い。
このように決まる視線制御の処理の一例を図6および図7に示す。この処理はCPU1により実施される。なお、この視線制御の手法は多様な形態をとることができるので、ここに示すものはあくまで一例として示し、本発明を限定するものではない。また、この視線制御の処理は、フィールド上に居る全競技者(キャラクタ)について実施してもよいし、演算負荷を軽減する観点から、表示視野内に入るキャラクタのみついて実施してもよい。さらに、表示視野内のキャラクタであっても、とくに、注目すべきキャラクタ(例えばボールに関わるモーションを行っているキャラクタや、プレーヤ(遊戯者)が操作しているキャラクタ)など特定のキャラクタのみについて実施してもよい。
図5に示すように、例えば、あるキャラクタが現在走っているかどうかを判断し、YES(走っている)かNO(走っていない)で場合分けを行う(ステップS21)。YESの場合、さらに、相手チームがボールを持っているか否かを判断し(ステップS22)する。この判断がYES(相手チームが持っている)の場合、さらに、相手チームのキャラクタがドリブル中であるか否かを判断する(ステップS23)。この判断でYES(ドリブル中である)のときは、さらに、ドリブルしているキャラクタが3メートル以内にいるか否かを距離計算値から判断する(ステップS24)。この判断でYES(3メートル以内にいる)のとき、いま制御対象となっているキャラクタはボールの方に視線を向ける(ステップS25)。このステップ25の処理では、前述した図5の回転処理が加味される。例えば、このステップ25に至るキャラクタは走っているので、走りながら視線をボールに向けるには、1)の態様が例えば好適となる。
ステップS24でNO(3メートル以内にいない)のときは、いま制御御対象となっているキャラクタは、ドリブルしている相手キャラクタに視線を向ける(ステップS26)。このときの回転制御は図5で説明したいずれの態様をとってもよく、その時点で相手との角度関係がどのようになっているかに応じて選択すればよい。
ステップS23でNO(ドリブル中ではない)のとき、および、ステップS22でNO(相手チームがボールを持っていない)のときは、現在のボールの挙動が「ハイボール」か否かを判断する(ステップS27)。「ハイボール」はここではボールの位置がキャラクタの頭上よりも高い状態を言う。この判断がYES(ハイボールである)のときは、いま制御対象となっているキャラクタにボールに視線を向けるように指令する(ステップS28)。反対に、NO(ハイボールでない)のときは、視線制御は行わず、モーションに依存した視線を維持させる(ステップS29)。例えば、このキャラクタは少なくとも走っているから、走行方向を向いた視線を維持させる。以下、モーションに依存するとは、視線制御を行わず、プログラムに定められたキャラクタの動作パターン(モーション)の動きをそのまま使うことを言う。
ステップS21の判断でNO、つまり自分が走行していない状態が判断されたときは、ドリブル中であるか(図7ステップS30)、センタリングエリア内にいるか(ステップS31)を順次判断する。ステップS31でYESと判断されたときは、ドリブル中でかつセンタリングエリア内にいる場合であるから、当然ゴールを狙うのが自然の流れである。そこで、この場合は、キャラクタの視線をゴールに向けさせる(ステップS32)。
ステップS31でセンタリングエリア内にいないときは、例えば、4秒に1回の割合でトップの選手に視線を向けさせる(ステップS33)とともに、4秒に1回の割合でゴールに視線を向けさせる(ステップS34)。また、ステップS30でNO(ドリブル中ではない)のときは、例えば、セットプレイ中であるか否かを判断する(ステップS35)。この判断がYES(セットプレイ中)のときはさらに、パスの相手が決まっていてキックに入っているか否かを判断し(ステップS37)、YESのときはパスの相手に視線を向けさせ(ステップS37)、NOのときは格別の視線制御は行わずに、モーションに依存した視線を確保させる(ステップS38)。
このようにキャラクタの視線制御を施すようにしたため、実際のサッカーゲームにおいて競技者が行う挙動に非常近いシミュレーションを行うことができる。従来のように視線は例えば走行方向を向いたままで、突然に、別の方向にボールを蹴り出すということもなくなる。このような場合でも、キャラクタは事前に、蹴り出す、または蹴り出したい方向に視線を向けるので、よりリアルにキャラクタの挙動を表現でき、臨場感も高められ、ゲーム性の高いゲーム装置を提供できる。しかも、視線制御の際、頭部だけを回転させるだけではなく、必要に応じて、胴部や腰部も追随または同時に回転させるので、その視線制御に挙動にリアル感が確実に高められる。
また別の視点から上記視線制御の利点を考えると、キャラクタが向ける視線方向自体が、プレーヤ(遊戯者)に次の操作を行うヒントを暗示するということである。例えば、ドリブル中のキャラクタが頻繁に後ろに視線を向け始めたら、後ろから相手チームのキャラクタが迫っていることが考えられるから、プレーヤ(遊戯者)はこの追跡を避けなければと思うようになる。したがって、キャラクタの挙動がプレーヤ(遊戯者)にゲームの状況を伝える(暗示する)ことができる。
反対に、図6および図7に示した判断ステップに、若干のフロックを混ぜることもできる。つまり、正規の判断とは全く別の方向にわざと視線を向けさせるのである。これにより、プレーヤ(遊戯者)の判断を攪乱することができ、ゲーム装置としての興味性、ゲーム性を一層高めることができ、また、ゲームの難易度を上げることができる。
続いて、上述した観客の挙動制御の処理を図8〜図17を用いて説明する。
最初に、本発明に係る観客を表す画像データ(観客データ)の構造を図8により説明する。いま、後ろに進むほど座席が高くなるm(>2)列のスタンドに観客が座っているとし、このm列の観客の内のn(>2)行を切り出す。この「m列×n行」の内の、m'列(>0)分に対する「m'列×n行」の観客を1枚の矩形状のポリゴンに複数観客分のテクスチャアを貼って表す。例えば、図8において、A〜D,A'〜D',A"〜D"は12枚の矩形状のポリゴンを示し、各ポリゴンがスタンド奥行き方向に進むほど高くなる状態を模して積層した仮想空間でのデータ構造を示す。ポリゴンA〜D,A'〜D',A"〜D"のそれぞれは、1枚のポリゴンで、例えば3列(=m')×4行(=n)分の複数の観客を表す。1枚目のポリゴンAの後ろ(奥行き方向)に仮想的に位置する2枚目のポリゴンBは例えば1列だけ上がった状態を初期状態とし、3枚目のポリゴンCは例えば1列だけ上がった状態を初期状態とし、さらに、4枚目のポリゴンDは例えば1列だけ上がった状態を初期状態としている。このため、A〜D,A'〜D',A"〜D"の12枚のポリゴンにより、スタンドに陣取る例えば「14列×4行」の観客を表す。
12の枚のポリゴンA〜D,A'〜D',A"〜D"の内、例えば、最初の4枚のポリゴンA〜Dが観客の図柄的に相互に関連し、その次の4枚のポリゴンA'〜D'が観客の図柄的に相互に関連し、最後の4枚のポリゴンA"〜D"が観客の図柄的に相互に関連している。同時に、12の枚のポリゴンA〜D,A'〜D',A"〜D"の1、5、9枚目の3枚のポリゴンA,A',A"が同一に動かされる同一オブジェクトOB1を構成している。同様に、2、6、10枚目の3枚のポリゴンB,B',B"が同一に動かされる同一オブジェクトOB2を構成している。同様に、3、7、11枚目の3枚のポリゴンC,C',C"が同一オブジェクトOB3を、4、8、12枚目の3枚のポリゴンD,D',D"が同一オブジェクトOB4をそれぞれ構成している。オブジェクト毎の観客の図柄は関連しなくてもよい。つまり、本発明の観客データは、複数個(枚)のポリゴンが互いに仮想空間上で分離されながらも、同一のオブジェクトを形成している点に一つの特徴がある。なお、オブジェクト毎の観客の図柄は関連させくてもよい。勿論、関連させることも可能である。
このように構成されるデータに対して、図9に示す観客挙動制御の処理がCPU1により実施される。つまり、CPU1は全体の観客データのポリゴンの内、その挙動を制御するポリゴン群を決める(ステップS41)。これにより、視点カメラから見える観客の内、例えば自分が応援するチーム側に陣取った観客のポリゴンの群(例えば図10の12枚のポリゴンA〜D,A'〜D',A"〜D")。ここで、複数のポリゴン群を選択しても勿論よい。
次いでCPU1は、決定(選択)したポリゴン群を動かす挙動パターンを選択する(ステップS42)。この挙動パターンとしては、ここでは、1群あるいは複数群のポリゴンのそれぞれを上下(縦)方向に動かす、または左右(横)方向に動かすパターンが用意されている。この挙動パターンが選択されると、CPU1は、選択した挙動パターンに沿って1群あるいは複数群のポリゴンのそれぞれを動かす処理を行う(ステップS43a,…,S43n)。
このポリゴンの動かし方の一例を図10〜図17に示す。これらの図のポリゴン群は1群を例示しており、図8の同一のデータ構成を有する。ポリゴンを動かす前の状態が図10の状態であるとすると、この状態から、例えばフレーム更新毎に、図11、図12、図13、図14、図15、図16で示すポリゴン位置の状態へと順次動かし、複数フレーム後には一順して再び図17で示すポリゴン位置の状態(図10と同じポリゴン位置の状態)に戻る。
具体例としては、図11に示す最初のフレーム更新時には、最初のオブジェクトOB1を形成する手前から1、5、9番目の3つのポリゴンA,A',A"を仮想空間で上方向に上げる(up)。図12に示すその次のフレーム更新時には、オブジェクトOB1の3つのポリゴンA,A',A"をさらに上方向に上げる(up)とともに、2番目のオブジェクトOB2を形成する2、6、10番目の3つのポリゴンB,B',B"を上方向に上げる(up)。図13に示すその次のフレーム更新時には、オブジェクトOB1のポリゴンA,A',A"を仮想空間で下方向に下げる(down)とともに、2番目のオブジェクトOB2のポリゴンB,B',B"をさらに上方向に上げ、かつ、3番目のオブジェクトOB3を形成する3、7、11番目の3つのポリゴンC,C',C"を上方向に上げる(up)。図14に示すその次のフレーム更新時には、2番目のオブジェクトOB2のポリゴンB,B',B"および3番目のオブジェクトOB3のポリゴンC,C',C"を下方向に下げる(down)とともに、オブジェクトOB4の3つのポリゴンD,D',D"を上方向に上げる(up)。そして、図15に示すその次のフレーム更新時には、3番目のオブジェクトOB3のポリゴンC,C',C"およびオブジェクトOB4のポリゴンD,D',D"を下方向に下げる(down)。その次のフレーム更新時には、遅れて下げ始めたオブジェクトOB4の3つのポリゴンD,D',D"を下方向にさらに下げる(down)。これにより、図17に示すように、一巡して最初のポリゴン位置状態に戻る。ポリゴンを左右方向に動かすときも同様である。
そして、CPU1は、1群あるいは複数群のポリゴンのそれぞれを動かす度に(例えば図10から図11に至る状態)、視点カメラから見える分の観客データをVDP5に指定する(ステップS44)。この後、再びステップS41の処理に戻って、フレーム更新毎に上述した挙動パターンの制御処理を繰り返す。なお、この観客の挙動制御の処理は複数の表示フレーム毎に行うようにして、かかる処理を間引きして、簡素化することもできる。なお、3次元仮想空間内の表示体は、仮想空間内の所定の視点(遊戯者によって移動され得る。)から表示画面に対して透視変換されて表示される。また、仮想カメラの位置、投影センターに相当する視点と、キャラクターの視線制御における視点とは、念のために、別物であることを指摘しておく。
この結果、複数のポリゴンを1つのオブジェクトとして関連付け、かつ、このような複数のオブジェクトの各ポリゴンを横断的にグループ化してインターリーブし、関連する絵柄をグループ毎にテクスチャで与えているので、オブジェクト単位で各ポリゴンを動かすだけで、絶え間なく動く観客の多彩な挙動をよりリアルに表現することができる。オブジェクト単位で動かすので、そのソフトプログラムのコマンド数が少なくなるなど、その設計を簡単化できる。また、挙動制御自体も簡単になって、制御のための演算負荷が少なくなる。観客個々をポリゴンで表示する場合に比べて遜色の無いリアルな挙動を表現しながら、扱うデータ量は格段に少なくて済む。したがって、観客データを格納しておくメモリの容量の少なくてよい。当然に、動画的に観客の挙動を表示する場合よりも、データ数が少なく、かつ、よりリアルに臨場感をもって表現できる。
続いて、上述したフォグ制御の処理を図18〜図21を用いて説明する。このフォグ制御とは、前述したように、カラー値を持った一種のマスクデータを画像データ上に重畳する処理であり、従来の輝度データのみによって1日の日照変化に伴う明るさの度合いの変化を表すことは難しい点を改善しようとするものである。
この処理はCPU1により、例えば図18に示すように実行される。なお、この図18の処理をVDP5で実行させてもよい。
CPU1は、まず、その時点の実時間(すなわち、プレーヤ(遊戯者)がゲーム装置を操作している実際の時間)を実時間クロック13から読み込む(ステップS51)。次いで、その実時間が予め定めた、昼、夕、夜の基準となる時間帯からずれているかどうかを判断する(ステップS52)。この昼、夕、夜の基準時間帯は、例えば、図19のように定められている。例えば、昼間の基準時間帯としては比較的長めに6:00〜16:30を、夕方の基準時間帯としては17:00〜18:30に、夜間の基準時間帯としては19:30〜5:30にそれぞれ設定されている。ここで、昼間の基準時間帯を長めにしているのは、朝方近くにプレイする遊戯者と夕方近くにプレイする遊戯者との間で、画面の明るさが影響してゲーム結果に差が出ないようにするためである。
ステップS52の判断でYESとなるときは、昼、夕、夜の基準時間帯別に予め設定されているフォグデータのパラメータ値をROM2から読み出す(ステップS53)。このパラメータとしては、赤、青、緑のフォグのカラーコード、オフセット値(フォグの濃さを表す)、および濃度(奥行きに対するフォグの掛か具合の3つであり、基準時間帯についてはそれらのパラメータ値が適宜な値になるように予め決められている。
次いで、CPU1はフォグデータを演算し、そのデータをマスクデータとしてVDP5に出力する(ステップS54,S55)。
一方、ステップS52でNOとなるときは、実時間と基準時間帯とのずれを計算する(ステップS56)。例えば、実時間が朝の5:45であったとすれば、夜の基準時間帯と昼のそれとの丁度、中間で、15分のずれがある。
次いで、CPU1は、ずれがある実時間を挟んで存在する2つの基準時間帯のフォグデータのパラメータ値(R,G,Bのカラーコード、オフセット値、濃度)をそれぞれ読み出す(ステップS57)。実時間が例えば5:45であったとすれば、夜間と昼間の基準時間帯のパラメータ値がそれぞれ読み出される。
そして、オフセット値および濃度に対するパラメータ値の補間演算が行われる(ステップS58)。例えば、実時間が例えば5:45の場合、オフセット値および濃度は丁度、夜間と昼間の基準時間帯のオフセット値および濃度の1/2の平均値となる。実時間がいずれかの基準時間帯により近い場合、その近い分の重み付けがなされ、平均化(補間)される。
このように実時間が基準時間帯からずれていた場合でも、補間演算により、オフセット値と濃度が決まり、前述と同様にフォグデータが演算され、出力される(ステップS54,S55)。
この結果、プレーヤ(遊戯者)がゲームを行うときの日照状態(物理的明るさ)に応じてフォグが掛けられた画像がリアルタイムに表示される。例えば、夕方にゲームを行う場合、競技場の外の背景には黒っぽいフォグが掛けられる(図20の斜線参照)。また例えば、夜間にゲームを行う場合、背景に月が出ているとすれば、黒っぽいフォグと月光に輝く黄色っぽいフォグとが背景に掛かる(図21の斜線参照)。
このため、従来のように単に輝度値のみの制御で、競技場およびその周囲を表示する画像の日照状態(物理的明るさ)を表現する場合とは異なり、よりリアルに明るさの変化を表現できる。とくに、カラーのフォグデータを被せているため、例えば月が出ている部分など、局所的な明るさの調整も容易に可能である。また、本実施形態では例えば朝焼け、夕焼けが出るような基準時間帯間の微妙な明るさをも、昼間、夕方、夜間の内の2つの基準時間帯を使った補間パラメータから処理できる。
つまり、昼、夕、夜の一番ゲームに適したカラー状態に対応したカラー状態を予め作成しておいて、実時間に合ったカラー状態を昼/夕、夕/夜、もしくは夜/昼の基準値間で補間(具体的には、カラーの混ぜ合わせ処理;2つの基準値の間で補間をした輝度値を付加してもよい)してカラー状態を決める。このため、単に輝度値のみで調整する場合のように画面が暗くなって操作が難しくなるということもない。カラー調整の開始点(一方の基準値)と終着点(もう一方の基準値)とが予め決まっており、ゲームに適した状態がセットされているから、どの時間にプレイしても画面のカラー状態による有利/不利が生じない。つまり、ゲームであることの特殊性ゆえに、「時間の変化に拠るカラー変化」を演出した上で、「プレイする時間帯によって有利/不利が生じて不公正感を出さない」ということが重要であり、本実施形態の装置はこれに応えることができる。このように、競技場やその周辺を取り巻く環境の明るさ表現に関して臨場感に優れた画像を提供できる。
上述したキャラクタの視線制御、観客の挙動制御、およびフォグ制御は必ずしも3つ同時に実行しなくてもよい。いずれか1つまたは2つの制御を行うようにしてもよい。
なお、図22はキャラクタの視線制御の結果表示される画面を模式的に示したものである。また、図8から図17において説明した実施形態において、競技場を臨む観客、すなわち、ゲーム空間である三次元仮想空間内に表示される表示体の一例、を有するテクスチャーをA乃至D"のそれぞれのポリゴン面に貼られた態様は特に限定されない。例えば、ポリゴン面にマッピングされるテクスチャーのうち、観客を模した表示体以外の背景部分を透明ビットのテクスチャーとし、表示体の部分を不透明ビットのテクチャーとすることができる。
図23はこのテクスチャーの模式図である。観客である表示体300および必要であればその周囲部分301も含めて不透明ビットのテクスチャー領域とする。それ以外の部分、例えば、背景部分302を透明ビットのテクスチャー領域とする。図24は、他の観客の形態に係わるテクスチャーの例である。背景302は同様に透明ビットであり、キャラクタ−304は不透明ビットである。このテクスチャーは、図23のテクスチャーが貼られるポリゴン以外のポリゴンに貼り付けられ、図23のテクスチャーが貼られたポリゴンの手前、即ちより仮想視点側に図24のテクスチャーが貼られたポリゴンを配置する。図25は、これらのテクスチャーが図8乃至17に示すように重畳、すなわち、重ねられた状態を示すものである。図23の透明な背景部分に図24のキャラクタ304が重ねて表示される。したがって、図23と図24とのポリゴンが重ねられて表示されると、両方のテクスチャーの観客が合成、合体、或いは重ねられて画面に表示される。なお、それぞれのポリゴンのキャラクターである観客同士が重なると3次元空間において下の方の観客、すなわち、優先度の低いポリゴンの観客は優先度の高いポリゴンの観客の下になり画面には表示されないことになる。
このようなテクスチャーが貼られた複数のポリゴンを図8から図17のように、複数のポリゴンをその重ね合わせ方向に直交或いはこれ以外に交差する面に沿って、あるいは、3次元空間内でポリゴンA乃至D"に臨む仮想カメラに沿って交差する方向、或いは、その重ね合わせ方向に交差する方向に動かすことによって観客の動きを前記実施形態の場合と同様に再現或いはシミュレートすることができる。 図26及び 図27は図23で説明したポリゴン400と図24で説明したポリゴン402とを重ね、 図26はポリゴン400を上に動かし、 図27はポリゴン402を上に動かした場合である。
このように、本発明によれば、サッカー競技場における観客のように多数の表示体が揺動するような動き、或いは、多数の表示体からなる群の動き、多数の表示体を複数のブロックに分けて、各ブロックを制御された状態で動かすことが好適な場合(動物や昆虫の群の動き)において、その動きをより効率的に作り出すことが可能となる。このような動きは、特定のモードの時、例えば、サッカーゲームの場合、選手が放ったボールがゴールした場合に生じるようにする。なお、繰り返すが、ここで説明したテクスチャーは、背景(例えば、雲、波等)及び観客などのキャラクタを含めた絵のデータであっても良いことは勿論である。また、 図23の背景部分を透明テクスチャーから構成されることに代えて、単一色のテクスチャーにし、 図24のキャラクターを、この単一色とは区別できるような色のテクスチャーから構成しても良い。さらに、 図24の背景部分を単一色のテクスチャーにし、 図23の背景部分は透明色にしたまま、 図23のキャラクタの少なくとも輪郭を前記単一色以外にすることも可能である。さらにまた、図8乃至図17の場合は各ポリゴンを仮想空間状斜め上方に徐々に位置するように配置したが、これに限らず、ほぼ平坦面に各ポリゴンを配置するようにもできる。
以上のように本発明の一つの態様によれば、キャラクタにゲームを通して関わりを持つ目標体と当該キャラクタとの間の物理的関係またはゲーム内容に関する関係が所定条件を合致すると判断されたとき、キャラクタの視線を目標体に向けさせるようにしたので、例えばサッカーゲームにおいてキャラクタがボールをドリブルしながら攻撃をする場合、事前に、蹴り出すゾーンや味方選手を探すため、別の方を見る(見渡す)動作を行うので、実際のサッカー競技者の挙動をよりリアルにシミュレートでき、より自然な動きになり、リアル感および臨場感を向上させることができる。
また、この視点制御は、1)ゲーム中の作戦の立て方、ゲームの難易度にも影響させることができる、2)ボールゲームの場合、ボールを持っているキャラクタの行動からボールの転送される(べき)先や周囲の状況を把握でき、操作がし易い、などの効果も得られる。
また本発明の別の態様によれば、複数の観客を模したテクスチャを個々に貼り付ける複数枚のポリゴンを仮想的に重ね合わせ、この複数枚のポリゴンをその重ね合わせ方向に交差する方向に沿って動かすようにしたので、観客個々の多彩な動き(よりリアルな挙動)を表現でき、ソフトプログラムの設計を簡単化させ、演算負荷を減少させ、メモリ容量の少量化を可能にするなど、これらを要求を同時にほとんど満足させ、かつ、ゲームの臨場感を盛り上げることができる。
さらに本発明の別の態様によれば、プレーヤがゲームを実行する1日の内の実際の時間を検知し、この実際の時間に応じて画像の画面カラーを、予めゲームに最適になるように調整した画面カラーから補完して求めるようにしたので、時間に合わせて画面カラーを変化させる演出を加えた上で、画面カラーを常にゲームの支障にならないように保つことができる。また、従来のように輝度だけで画面カラー状態を調整するときの不都合を回避でき、表示画面のカラー状態と1日の内の明るさの変化とを安定してかつ精度良く適合させ、ゲームの臨場感を高めることができる。
1・・・CPU、2・・・ROM、3・・・RAM、4・・・入力装置、5・・・VDP、6・・・VRAM、7・・・描画装置、9・・・テクスチャデータROM、10・・・フレームバッファメモリ、11・・・D/A変換器、12・・・表示装置、13・・・フォグ回路、14・・・実時間クロック。