Game Developers Conference 2005現地レポート

会場：Moscone West Convention Center

　3DゲームファンのためのAGE OF EMPIRESエンジン講座の後編では、リアルタイムストラテジー(RTS)ゲームに3Dグラフィックを盛り込んだ「AGE OF EMPIRES」の最新作、「AGE OF EMPIRES III(「AOE3」)」のグラフィックスエンジンについて、さらに解説していこう。

ENSEMBLE STUDIOSリードプログラマDave Pottinger氏	ENSEMBLE STUDIOSシニアプログラマMichael Bean氏

■ こだわりの影生成～RTSでセルフシャドウが拝める「「AOE3」」

　RTSゲームの場合、視点が俯瞰となる関係で、どうしても描画される各ユニットが小さくなる。そのため、「マジメに影を生成してもあまり意味がない」というのが定説であった。ほとんどのRTSゲームの影生成は、キャラクタの足元に丸影を配置するものがほとんどで、中にはキャラクタ形状のシルエットを光源位置から投射テクスチャマッピングで貼り付ける物もあったが、いずれにせよ、自分の影が自分自身に投射されるセルフシャドウや、オブジェクト同士が影を落とし合う相互等射影などはサポートされるはずもなかった。

　しかし、「AOE3」では、このRTSグラフィックスの常識を打ち破り、強力な影生成エンジンを実装することに踏み切った。「AOE3」で採用された影の生成技法は、スプリンターセルなどで実装されたことで著名となった「シャドウマップ」技法だ(その他、デプスシャドウ技法、シャドウバッファ技法と呼ぶこともある)。

　シャドウマップ技法では、まず、影の元となる光源を視点にしてシーンの深度情報のみをZバッファにレンダリングする。これはシーン内の遮蔽構造を記録したものに相当し、これを特にシャドウマップとかシャドウバッファと呼ぶことから、その技法の名前が付いている。最終的な、ゲーム画面としてレンダリングする際、その視点からの深度情報(Zバッファ)の内容と、シャドウバッファの内容を比較して、そのポリゴンを構成するピクセルが光源にてらされているか、影となっているかを判断して、適切な陰影処理を行なっていく。理論上はピクセル単位に光が当たっているか影となっているかの描きわけができるわけで、複雑な遮蔽構造でもきちんと影が描画できる。セルフシャドウや相互等射影なども、シャドウマップ技法を普通に実践するだけで自ずと結果として生成されることになる。

　この技法の問題点は、影の生成精度がシャドウバッファのサイズに強く依存してしまうというところにある。シャドウバッファとして確保できるサイズは、最大でも4,096×4,096ドット(要は最大テクスチャサイズと同じ)まで。「AOE3」のようなRTSゲームでは、広域な遮蔽構造を網羅しなければならないので、それでも全然足りない。シャドウバッファ解像度が十分でないと影のエッジにジャギーが出たり、出るべきでない場所に影が出たりする。

　そこで、「AOE3」では、シャドウマップ技法の改良発展系であるPerspective Shadow Maps(PSM)技法を採用した。より精度の高い遮蔽情報が必要なのは、よく目に見える視点に近い位置のほうであり、逆に視点から遠い遠景はいい加減であってもよく見えないから困らない。そこで、シャドウマップ自体を透視変換してやり、視点からの座標系でシャドウマップを生成してしまおうというのが基本アプローチになる。

近場から奥まで同じ精度でシャドウマップを生成すると近場はジャギーが出やすくなる	そこでシャドウマップ自体も透視変換してしまって、視点側から均等な解像度の遮蔽構造が得られるようにしてしまおう、というのがPSMの考え方

　実はこの技法は、業界標準ベンチマークソフト「3DMark05」の影生成エンジンでも活用されている。ところが、3DMark05では、このPSMを用いながらも若干のジャギーが出てしまっていた。

　「AOE3」ではこのジャギーをなくすために、光源を視点としてシーンをシャドウバッファにレンダリングする際に、この画角をリアルタイムに絞れるだけ絞り、影が生成されるべきオブジェクトがシャドウマップにめいっぱい収まるようにしている。シャドウバッファは確保できる限りの最大サイズを確保するとのことで、おそらく最大4,096×4,096ドットなのだろう。まぁ、結構、力業の工夫だといえるが、その効果は大きく、実際のゲームの映像中の影にほとんどジャギーらしいジャギーが見えない。

　シャドウバッファ参照時には、NVIDIAのGeForce系ビデオカードであれば、自動的にバイリニアフィルタ効果が得られるハードウェアシャドウバッファ機能(別名NVIDIA SHADOW機能)を活用する。影のエッジが柔らかくなり、パフォーマンス的にも有利となる。一方、ATIのRADEON系ビデオカードではこれが利用できないので、ピクセルシェーダによるマルチサンプリングで対応するので同じクオリティの影を得ようとすると、パフォーマンス的には若干劣ることになる。

「AOE3」における影	3DMark05の影生成もPSM技法を採用していたが、このように場所によってはジャギーが目立っていた
「AOE3」の場合は、このように光源が斜めからかすめるように照らされて影が長く伸びるような状況でもジャギーが全く感じられない	各建物の煙突の影が自身の屋根に長く伸びる格好で投射されている。こうしたセルフシャドウ表現がRTSのグラフィックスで拝めるようになるとは思わなかった

■ 地形生成はプロシージャル生成～ソフトウェアによるディスプレースメントマッピングエンジンを搭載

　「AGE OF～」シリーズといえば、プレイするたびにゲームマップがパラメトリックにランダム自動生成されるという仕組みが特徴的であった。「AOE3」でも、この「ランダムマップ」コンセプトは受け継がれる。

　「AGE OF MYTHOLOGY」でも、マップは3D化されたフィールドが自動生成されたが、高低表現はいってみれば起伏程度であり、ドラスティックな高低差のあるマップは仕様上生成されなかった。

　一方、ENSEMBLE STUDIOが手がける3DベースRTSの第2弾となる「AOE3」では、この地形生成においても大幅に進化発展させられている。地形の高低生成はかなり大胆に行なわれ(もちろん高低差のないマップも作れるが)、“崖”と呼ぶにふさわしい地形生成も行なわれるようになった。

　こうした崖や絶壁、山岳などの高低地形表現は、基本的な高低のあるジオメトリ構造を生成した後、あらかじめ用意しておいたマテリアルごとの凹凸情報(高低マップ)に従い、ソフトウェアベースのテッセレータでディスプレースメント・マッピングが行なわれるという。

　つまり、崖の地形を生成し、そのままだとカクカクなので、岩肌のハイトマップを持ってきて、これに従ってカクカクの崖を滑らかな自然界の地形のようにポリゴン分割を行なう……というような流れになる。

　ディスプレースメントマッピングと聞いて、プログラマブルシェーダ3.0の頂点テクスチャリング(Vertex Texture Fetch;VTF)を連想した人も多いと思うが、「AOE3」の場合、地形がリアルタイムに変形することもないため、VTFは使われておらず、テッセレーションはCPUベースにて行なっているとのことだ。さらにいえば、テッセレーションはゲーム開始直前のマップ生成の段階で行なうのみで、ゲーム中は普通の固定された地形と同等に扱われるのだという。

高低をこんな感じで自動生成。このままではカクカク過ぎるので……	ハイトマップをベースにしてこれをポリゴン分割する。するとこんな感じに自然に崖や絶壁が完成。一度分割されれば、その取り扱いは普通の地形情報と同じ	こうした、かなりリアルで自然な地形がランダムマップで無数に自動生成されるのには驚かされる

■ 流体波動シミュレーションは事前計算ベース～フレネル反射に配慮した水面表現

　Valve Softwareの「Half-Life2」の水面処理は、かなり高度であり、ゲーム全体を通して最も印象深い映像表現であったが、「AOE3」の水面処理もこれに勝るとも劣らないレベルで作り込まれている。まず、目を引きつけられるのはリアルな水面の動き……すなわち流体(波動)シミュレーションだ。

　さて、水面上の“さざ波”は、細かい凹凸であり、視点が引きがちなRTSにおいて、この表現はポリゴンレベルでやる必要もないので、法線マップを使ったバンプマッピングの概念を使うことになる。しかし、ただ1枚の法線マップを生成しただけでは、波の凹凸が動かない。つまり、動くさざ波を作り出すには、この法線マップを更新してやらなければならないことになる。

　開発当初は、まじめにそのシーン中のキャラクタ達からインタラクト(相互作用)されて発生する波動をリアルタイムにマジメに計算していくつもりだったとのことだが、いくつかの問題が出てきたためにこの方策を断念したという。

「AOE3」では事前計算による水面上のさざ波法線マップ・アニメーション方式を採用。右側は法線マップを可視化したもの

　問題の1つは法線マップの容量や解像度の問題。海洋などの広い範囲の水面をマジメに波動シミュレーションで動かすためには、複数枚の法線マップを海洋に配置しなければならない。つまり、大量の法線マップをフレーム単位に更新しなければならず、これはパフォーマンス的には相当厳しいものになる。

　もちろん、画面解像度とテクスチャ解像度は一致している必要はないので、ある解像度の法線マップを海洋全体に割り当てることもできるのだが、その場合はどうしても法線マップの解像度が相対的に低くなるわけで、波の表現がブロッキーになってしまう。 　そんなわけで、結局、「AOE3」では、流体シミュレーションを事前計算し、法線マップアニメーションを生成するアプローチを取ることとなった。

「AOE3」開発初期ではリアルタイムベースの波動シミュレーションを採用していた。画面は、マウスで水面をなぞってそこに波を発生させるデモの様子を捉えたもの

左上の奥の方にさざ波の周期性が見て取れる。このあたりは事前計算ベースの法線マップをタイル状に並べていることの弊害

　事前計算の際に与えるパラメータは、波の高さ、風の方向、風の速度、波の周波数、法線マップのサイズ、何秒間で1ループするか……など。なお、生成された法線マップはタイル状に並べても継ぎ目がわからないようになっており、海洋エリアに並べるだけでその領域全体のさざ波が動いているように見える。

　ただし、この方式を採用したことにより、波は常に一定のアニメーションを繰り返すことになるわけで、船の挙動で波が変化したりするようなインタラクティビティはなくなってしまっている。また、生成する法線マップのサイズがあまりにも小さい場合は、そのさざ波のアニメーションの周期性(≒うそっぽさ)が目立つことになる。

「AOE3」の美しい水面の表現は「Half-Life2」に優るとも劣らない

　その代わり、リアルタイム法線マップ生成の負荷が排除でき、さらに複数枚の法線マップを用いる必要がなくなるわけで、ビデオメモリ使用量も小さくて済むようになった。 　さて、実際のゲームでは、この事前計算は、ランダムマップ生成時に行なっているようで、生成されるさざ波はマップごとに異なり、その情景にあった水面の状態が表現される。

　水面表現のシェーダー自体は、基本は環境バンプマッピングが基本となる。ただし、視線が水面に対して直角に近い場合は水底が見えやすく、視線角度が水面に対して浅くなるにつれて周りの情景が映り込みやすくするといった異方性を導入することで、水面のフレネル反射を表現している。
■ 河川はスプライン関数に従って自動生成

川の軌道はプロシージャル生成される。さらにこの軌道に沿った形でテクスチャ座標が生成され、水面の法線マップアニメーションで川の水の流れを表現する

　「AOE3」では絶壁のような高低生成の他、河川までもがランダムに自動生成される。

　河川の軌道はスプライン関数に従って、滑らかな走時曲線ように生成される。川の水面も、海洋同様の事前計算された法線マップアニメーションを用いたフレネル反射付きの環境バンプマッピングで表現されるが、川の流れを表現するために、テクスチャ座標をスプライン関数で川の軌道に沿った形で生成している。これにより、見た目として、さざ波のアニメーションが、川の軌道に沿って動くようになる。これは、見た目としてかなり説得力が高く、非常に美しく見えていた。

　なお、川の沿岸は、ちょっとした高低差が発生するわけだが、この部分は前述した絶壁と同様、事前計算型のディスプレースメントマッピングによって生成される。これは丁度、川の軌道の曲がりくねったカーブの角を柔らかく見せることにも繋がっているようだ。

　川の流れが岩などに当たる部分などは、事前計算ではなくて、リアルタイムにパーティクルでの泡や水しぶきを付加しており、さらなるリアリティの向上に貢献している。

■ RTSながらHAVOK物理エンジンの導入～動的な当たり判定システムが切り開く新たなRTSの戦闘形態

崩壊を想定したパーツ分解は事前にアーティストが行なっている。つまり壊れ方のパターンはある程度限定されている

　これまでの3D化されたRTSで、まず物足りなかったのは、戦闘そのものの臨場感だ。あらかじめ描き込まれたアニメーションが再生されるだけで、兵ユニット同士が実際に戦っている息づかいが感じられなかった。

　「AOE3」では、この戦闘の動的な臨場感をさらに盛り上げるために、本格的な物理エンジンの導入に踏切った。採用物理エンジンは、ゲーム導入例が圧倒的に多いHAVOK製(バージョンは非公開)。

　「AOE3」では、各ユニットの「崩壊モデル」にHAVOK物理を適用している。「AOE3」では、あるユニットが砲弾を発射すると同一のユニットに対する攻撃でも命中位置が微妙に異なり、命中した箇所がその衝撃に耐えられないと、そのユニットはパーツ単位で崩壊していくのだ。たとえば建物系ユニットであれば、屋根が崩れたり、壁が崩れたりする。

　実際には建物のパーツ分解は事前にアーティストが行なっており、実際には、崩壊箇所は決めうちなのだが、これまで、耐久度に応じて火の出方が異なるだけのビジュアルと比べて圧倒的なリアリティがある。

Ragdoll物理がついにRTSの世界へ

　人体系の兵ユニットに対しての死亡アニメーションには、これまたFPSではお馴染みのRagdoll物理が適用される。なお、念のためにRagdoll物理という用語を説明しておくと、これは簡単に言えば、3Dモデルを吹っ飛ばした際、その内部の骨格制御に配慮してワールドとの衝突挙動を計算するもの。Ragdollは“ぬいぐるみ”の意味があるが、要はぬいぐるみを吹っ飛ばしたときにどう転がるかを計算するものと思えばいい。

　「AOE3」では、人体系兵ユニットの内部骨格の各関節には折り曲げ許容範囲とその耐久度が設定されており、この範囲を超えたダメージを受けると内部骨格が崩壊する処理までを行なうそうだ。また、地形の高低差から生まれる位置エネルギーも演算に配慮されるのがすごい。ENSEMBLE STUDIOSでは、実際のデモで、頭に砲弾が当たると頭がとれたりする様や、銃弾を食らって崖から転落する兵ユニットの様を披露した。

「AOE3」ではこの動的な当たり判定システムにより、先頭においてこれまで以上に陣形が重要となるはず

　ところで、RTSにて、このようなFPSのような“動的な”当たり判定システムの仕組みを導入したことで、なにか新しい「ゲーム性」はもたらされているのだろうか。

　「AOE3」でも、歴代のAOEシリーズ同様に戦闘の際、兵ユニットの達の陣形をリアルタイムに変更可能だが、この動的な当たり判定システムにより、陣形の前列のユニットを文字通りの盾とすることができるのだ。そう、前列の兵ユニットに被弾させて、後列のユニットへの被弾を防ぐといった戦略が使えるようになるのだ。「AOE3」では大航海時代付近が描かれることになるが、この時代は各文明が既に銃器の時代に突入しており、ことのほか「当たり判定」は重要な要素になる。チャンバラが主題であった「AOE2」以前とは違うため、「AOE3」では、このFPSばりの戦闘システムがどうしても必要だったのかもしれない。

　さて、一体一体の実際の戦闘演算はこれまでのRTSと同じようにパラメータベースで行なわれる。よって、強力な攻撃を受けて、攻撃ダメージが耐久値を超えれば、一回の攻撃で一気に崩壊するユニットもある。その際にも、崩壊アニメーションは、物理エンジンに従った形で再生されるので、歴代のAOEシリーズよりも高いリアリティを感じられる。

■ 「AOE3」の次はXbox2タイトルに着手か?

シーン奥の空気遠近の表現に注目

　今作では、AOEシリーズでは初めて夜の概念が導入される。また、空気遠近表現には、視点からの距離の遠さに応じて沈み込ませていくだけの従来のGPUが持っていたFOG機能を活用しているのではなく、深度情報を種にした簡易的なポストプロセスベースの光散乱(Light Scattering)シミュレーションにて行なわれている(光散乱シミュレーションについては本連載のこの記事を参照のこと)。ボリュームレンダリング的な空気遠近になっているので、開けた空間が白く霞みやすく、そうでないところは離れていてもやや見えるというような、空気の層の厚みが感じられる映像になっている。

　さて、「AOE3」は、開発途中の現時点でフレームあたり38万ポリゴン、3,900描画プリミティヴコール。テクスチャはフレームあたり360枚、プログラマブルシェーダはなんとフレームあたり120を切り替えて使っているという。

　現在のゲームパフォーマンスのボトルネックはCPUによる各兵ユニットのスキニングなどの3Dモデル変形処理と描画コールの多さだとのこと。これは動かして描くユニットがどうしても多くなるRTSならではの問題だとも言える。描画コールの多さなどは、ジオメトリインスタンシングなどを活用すれば軽減できそうだが、そのことに関しては言及されなかった。

　さて、ENSEMBLE STUDIOSでは、2005年秋発売予定の「AOE3」以降は、RTS以外の、しかもPC用でないゲームタイトルのプロジェクトを思案中だとのこと。ENSEMBLE STUDIOSがマイクロソフト傘下だということを考えれば「PC用でない」はすなわち「Xbox2用」を意味する。どんな物を見せてくれるのか、今から心待ちにしていたい。

(2005年3月13日)

[Reported by トライゼット西川善司]

GAME Watchホームページ

Q&A、ゲームの攻略などに関する質問はお受けしておりません
また、弊誌に掲載された写真、文章の無許諾での転載、使用に関しましては一切お断わりいたします