『ゼルダの伝説ティアキン』の空島は“積極的に放置”されていた。空、地上、地底の3つの世界と制作環境のすべてをシームレスにつないだ技術【CEDEC2024】

2024.08.23 12:35

更新

　2024年8月21日（水）から23日（金）にかけて開催されている、日本最大のコンピュータエンターテインメント開発者向けカンファレンス“CEDEC2024（Computer Entertainment Developers Conference 2024）”。その2日目に実施されたセッション、“『ゼルダの伝説　ティアーズオブザキングダム』（以下、『ティアキン』）の世界をつなぐ技術　～空、地上、地底、そして制作もシームレスに～”の内容をお伝えする。

　講演者は任天堂株式会社・企画制作部『ティアキン』開発チームの皆さん。テクニカルディレクターの堂田卓宏氏、地形プログラミング担当の斎藤智久氏、プログラミングディレクターの奥田貴洋氏のお三方だ。

『ゼルダの伝説　ティアーズオブザキングダム』(Switch)の購入はこちら（Amazon）

『ゼルダの伝説　ティアーズオブザキングダム』(Switch)の購入はこちら(楽天)

　『ティアキン』は、空世界から地底世界までをシームレスに行き来できるのが大きな特徴のタイトルだ。開発陣としても、空、地上、地底を途切れることなく移動できるゲーム体験を作りたいと考えていたが、これは大きな技術課題のひとつとなった。本講演では3つの世界をいかにシームレスにしたかの技術解説に加え、開発において制作フロー自体もシームレスにした手法について解説された。

じつは2次元だった前作から3次元への拡張

　『ティアキン』の前作にあたる『ゼルダの伝説　ブレスオブザワイルド』（以下、『ブレワイ』）もまた、シームレスで広大な世界と、自由度の高いゲームプレイの実現を目指したタイトルだった。

　そのためにはまず、実現目標に向けての“技術の選定”から開発がスタートした。一例としては、広大な世界を表現するために大量のポリゴンを用意する必要があるため、ディープなパスが必要となりがちな“フォワードレンダリング”ではなく、一度のGバッファ（深度情報や法線情報などの値）の描画で済む“デファードレンダリング”を採用した。

　技術の選定はワークフローやコミュニケーション、バージョン管理など多岐にわたる。それらを決定していくうえでどうしても大きな課題になったのは、広大な世界とシームレスな移動についてだった。

　過去の『ゼルダの伝説』シリーズ作品でも広大な世界は描かれていたが、内部的にはステージ切り換え型のゲームと同じ構造になっていた。そのため、改めてシームレスで広大なフィールドを表現するための試行錯誤が始まった。

　その初期には過去のシリーズ作品の床面積や、現実世界の地域を当てはめたりすることで、世界の広さを決定。そこに地域色をどうするか仮置きするなど、どのような“遊び”を作っていくかを検討していった

　この過程から、開発陣が注目していたのは“平面としての広大な世界”だったということが判明。『ブレワイ』ではフィールドの仕組みを考えるうえで、世界を平面、2次元で考えることとなった。2次元ならゲーム要素も考えやすく、データ構造もシンプル。編集や情報の可視化、情報管理など、さまざまな部分の問題をシンプル化できた。

　Wii Uのハード的な制約や、シームレスな移動に関しても、2次元の構造は有利に働く。LOD（※）の設定やロードについても、2次元的な主人公の動きに合わせて行うことができた。

※LOD：Level of Detailの略。カメラからの距離に応じてモデルのポリゴン数を制御することで、遠くにあるモデルは少ないポリゴン数で描写し、描画を高速化する手法。

　一方で技術の選定は、必ず“できないこと”を生みだす。たとえば先述のデファードレンダリングは、『スプラトゥーン3』などで活用されているフォワードレンダリングのような、多様なマテリアル表現は苦手としている。一部技術には選定と同時に、予想外の挙動や追加の設定などを要する場合があった。

　採用した技術によって何ができなくなるのか、注意すべき点はどこか。これらをエンジニアだけでなくアーティストなど、チーム全体が理解することが重要となった。チーム内での理解を進めていくと、“やらないこと”のコンセンサスを取っていくことになる。

　2次元の仕組みを作った『ブレワイ』において、それは当然“3次元の立体構造”だった。ゲーム内では壁登りや滑空、ちょっとした空のフィールドや洞窟など、3D要素をふんだんに使っている。それでも大局的に見ると、2次元の縛りで作られたゲームだったのだ。

　では、『ティアキン』ではどうだったのか。開発初期のブレストでは、すでに縦方向への世界の広がりから考え始めていた。真っ先に挑戦したかったのは、『ブレワイ』ではできなかったことだったという。加えてNintendo Switch専用タイトルということで、ハードの制限がなくなったことによる伸びしろもあった。

　前作で実現した2次元の処理を、いかに3次元に拡張するか。それが『ティアキン』での具体的な技術課題になったわけだ。

世界描写を3次元へ拡張した“洞窟システム”

　『ブレワイ』ではフィールド制作の技術の選定において、“ハイトマップ”（※）を利用してのプロシージャル（複数のデータや処理を組み合わせる方法）な地面描画を採用した。

※ハイトマップ：グレースケールの画像内で、白い部分は高い、黒いエリアは低いといった高さの違いを表現するテクスチャ。2次元の描写でありながら高低差を表現できる。

　高さ情報を持つハイトマップに、格子状のメッシュ（頂点、辺、面などのデータをともなってオブジェクトの表面部を形成するポリゴン集合体）を被せることでレンダリングを実施。これでグリッドの各頂点を対応する高さをリアルタイムに持ち上げて、地形の凹凸を表現できる。プログラム側から動的にポリゴン数を調整できるというメリットもある

　LODについても、プログラム側からメッシュのレンダリングを調整することで実現。広大な世界の描画についても、ハイトマップを適切に分割することでロードの読み分けができた。ハイトマップを用いることで、柔軟な描画に対応できたわけだ。

　だが、ハイトマップを用いた手法では3次元の立体構造を表現することは難しい。『ブレワイ』では立体構造が欲しい場面で、アーティストがメッシュデータで作成した3Dモデルを別途配置していた。

　では、『ティアキン』のフィールドはどう制作するのか。地上世界は前作の仕組みを使えるとしても、空や地底についてはデータストリーミングやLODに関して、3次元で考え直す必要があった。

　まず、“洞窟”には壁や天井にもメッシュがある。これらをシームレスに描画するため、新たにメッシュベースの地形システム、通称“洞窟システム”を開発することになる。メッシュが持つ頂点データをLODに合わせてモーフィングするわけだが、LOD間で頂点どうしのモーフィングを行うには、LOD間での頂点の対応付けが必要になる。

　この対応付けを作成するためにポリゴンリダクションを独自に実装したようだ。
　セッションの中でポリゴンリダクションは Half-Edge Collapse というアルゴリズムで実装していると説明があった。

　さらに八分木の構造データ“チャンク”にポリゴンを所属させることで、LODの段階に従って読み込まれるポリゴン群を制御。この場合、ポリゴンの計算位置はチャンク内に存在する必要があるが、複数のチャンクをポリゴンがまたぐ場合は、チャンクの表面に補間率計算用の位置を別に持たせることで、あくまでチャンク内にモーフィング計算を閉じ込めることができる。

　データストリーミングについても、チャンクがベースとなる。カメラから近ければ詳細な描写をし、一定以上離れていればそのままチャンクを描画するという、シンプルなアルゴリズムだ。

　こうして完成した洞窟システムを活用することで、地下の広大な空間も作成。この空洞でさまざまな遊びを検証するうちに、ひとつながりになっている広大な地下空間、なおかつ地上との相関があれば、ますます遊びや発見のサイクルが膨らむのではないかという話が出てきた。

　つまり、地上で何かを発見すると同じ地点の地底でも何かが見つかったり、逆に地底を探索することで地上に何があるか予想できたりと、地上と地底が相互にヒントになっている関係性を持たせることができるというわけだ。

　そこで実際に洞窟システムを利用し、地上世界をそのまま“裏返す”ことで、地底世界を形成。テストプレイでよい手応えが得られたため、地上のデータ（地形や植生など）を反映する生成ルールを設けて、アーティストによる細かな意匠や、新たなメッシュでの介入による個性付けなども加えつつ制作を進めた。

　この洞窟システムは、空島の制作にも使用できた。洞窟と空島の違いは、ポリゴンの法線が内向きか外向きかのみで、対応はそれほど難しくなかったとのこと。

地底への挑戦、そして空島はまさかの“放置”

　こうして『ティアキン』の世界は前作の2次元から3次元に拡張された。だが同じころ、プログラミングディレクターの奥田貴洋氏は、この世界を“どうやってロードしようか”と悩んでいたという。ここでいうロードとは、木や崖などの配置物のことだ。

　前作『ブレワイ』ではこれらの配置物も、ハイトマップ同様に2次元ベースでロードされていた。配置物は、2次元の表示距離に応じたグリッド上に配置される。たとえば大きな建物なら、表示距離が大きい（サイズが大きい）グリッドに配置し、遠くから見えなくてもいい小さなオブジェクトなら、小さなグリッドに配置される。これらのグリッドが重なりあっているわけだ。

　ただしロードはしなくても、コリジョン（物体同士が衝突、反発する判定）がないと困る場合がある。ほかのキャラクターなどが配置物の場所に入り、配置物がロードされたときにめり込んでしまうといったケースだ。そのため、地形コリジョンについてはメッシュコリジョンデータを独立してロードする仕様になった。

　これらの経験を踏まえ、『ティアキン』では配置物の読み込みをより柔軟に行えるロードシステムを作り直したという。このシステムはゲームフラグに応じて配置の入れ替えを柔軟に行えるため、ゲーム進行に応じて村の地形が変わる演出に使用された。

　また、前作ではダンジョンへの入場にロード時間を挟んでいたが、『ティアキン』ではそういったダンジョンへとシームレスに入場したいという思いがあり、独立した領域にロードしておける汎用的な処理を導入した。

　ただし、ロードのアルゴリズム自体は前作の2次元ベースのロードをそのまま使用している。このロードシステムで地底世界や空島をどうロードするのかは、新たな挑戦となった。

　まず地底世界だが、地上と地底は十分に離れているという構造は初期から決まっていた。つまり、地上と地底を両方同時に見る機会はない。そこで地上世界と地底世界等を同時にロードしておくよりも、地上にいるときは地上世界だけ、地底にいるときは地底世界だけをロードしておくほうが、より密度の高い、より広い、より深い世界を楽しめると考えたという。そこで、一定の深さに到達したときに地底世界をロードする仕様を入れてみたところ……。

　降下途中でロードが間に合わず、穴の中で画面が止まってしまった。この時点で、地底世界は地上世界と地続きになっており、地上から直接向かう場所であるという“役割”は確定した。

　この役割がわかっているという点は非常に重要。『ティアキン』では制作と確認のサイクルを大事にしており、おもしろそうなことが本当におもしろいのか確認できるだけの最低限のゲーム内実装が必要になる。ただ、やり直しになる可能性もあるため、作り込みすぎるのも好ましくない。役割を確認するための最低限の実装というのが、非常に重要なのだという。

　地底へ向かう仕組みの最低限の役割ということでは、この穴へ飛び込む仕様は問題ない。とはいえ製品化するには、さすがにロードの問題は解決しなければならない。プロファイラーツールでロード処理を可視化することで、時間がかかっているボトルネックを洗い出し、ロードを行っていない空白の時間に処理を割り当てたり、すぐには必要にならないデータのロードを後回しにしたりしてみたが、まだ足りない。

　そこでロードデータの総量を減らすため、見えない位置にある配置物はロードしないシステムを考案。テクスチャの解像度についてもオブジェクトごとに、そのオブジェクトが見える場所から観測した和集合をもとに、適切な値を導き出した。ここまでしても足りないケースがあったため、飛び降りる穴に近づいた時点で必要なファイルの一部を先行ロードする仕組みも導入し、ついにシームレスなロードを実現できた。

　こうして地底世界と地上世界のロード問題が解決したころ、空島のロードはどうなっていたのだろうか。

　空島が試作配置されたころは、地上から行けそうな低い位置の島もあれば、はるか高い位置にある島もあった。これらをロードするために必要なシステムについて、奥田氏がデザイナーと相談した結果はまさかの“放置”だった。

　ただし、実装できないから諦めて放置するというわけではない。あくまで“積極的放置作戦”、実装できたとしても実装しないという意図だ。これはこの段階で実装を進めると、むしろ空島に制約を課すことにもなりかねないと考えた結果だったとのこと。

　何かの機能を実装するということは、何かをひとつ決めるということ。しかし、空島はまだ試行錯誤の段階だった。いまその将来を決めることはしないほうがよいと考え、あえて空島専用のロードは実装しなかったわけだ。

　空島のロードについては、前作と同じ2次元ベースで補うことになった。そのトレードオフとして少々の処理落ちやバグはあっても、空島の役割の確認に支障がなければ、まだ開発中だから許容できる。

　こうした作戦を経て、どのような空島が必要になるのか絞り込まれていった。並行してデザインやアートの観点から、空島の配置も大きく変化していく。結果、メインストーリーに関わり、配置物やギミックが多い大きな空島が少数と、空の移動の経由地になることを目的とした小さめの空島がいくつか、そしてそもそもどうやってたどり着くのかを発見する必要があるようなごく小さな空島というように、空島の役割が分かれていった。

　プレイヤーが地上を歩いているあいだは、空島のことをほぼ無視できそうなことを確認したところで、空島を大きな空島と小さな空島に分類し、大きな空島はひとつだけ、小さな空島は複数を先行ロードしてメモリーに置いておけるシステムを開発。この定義付けにより、ロードの取り回しが格段に向上することになった。

マクロとミクロの視点が『ティアキン』の要

　このように、『ティアキン』の開発においては3つの世界をシームレスに描写、ロードするためのさまざまな技術が生み出された。しかし『ティアキン』の世界を実現するためにはそれらだけでなく、まずは役割を確認するための最低限の実装が必要であったり、本当に必要なものを絞り込むために積極的放置作戦を取ったりと、制作と確認のサイクル運用が必須だった。

　制作と確認のサイクル運用への取り組みは、“制作をシームレスにする”ものであると言える。この取り組みのために、進行方法だけでなくツールワークフローにおいても改善の取り組みがあったという。

　その一例が洞窟システムにおける、開発実機への実装時間を限りなくゼロにする試みだ。このシステムにおいてはコンバートの過程自体をなくし、ゲーム上で即時に編集確認が可能なリアルタイムエディットが、データストリーミングの仕組みの応用で実現された。

　また、通常のフローならレベルデザイン決定後にデータを磨き上げることになるが、レベルデザインに変更が入ると当然ながら磨き上げはやり直しになり、完成は遠のく。

　そこで洞窟システムでは、ブラッシュアップと変更作業が同時進行できるワークフローを目指して“プロシージャルデコレーション”を構築。コンバート時に“Houdini”（※）の処理を挟むことで、　天井や壁などの遊びへの関与が薄い箇所は自動的に意匠を細部まで仕上げる一方で、メインの導線がある地面などはレベルデザインの意図を壊さないように形状を保つ仕組みを実現した。

※Houdini：カナダのSide Effects Software社が開発した、映画制作などでも愛用される3DCG制作ソフトウェア。3DCGの作成過程を一貫して行えるほか、炎や煙といった不規則性を持つエフェクトの処理にも優れる。

　また、プロシージャルデコレーションはHoudiniでの実装をもともとエンジニアが行っていたこともあって、洞窟システムとの相性もよかった。アーティストが試行錯誤したい部分や、エンジニアとしてもアーティストに任せたい部分などが出てくるなかでワークフローの試行錯誤が続き、お互いが得意分野を理解し、最適な役割分担ができる体制が整っていったという。

　そもそも『ティアキン』は、空から地上、地上から地底へと、ダイナミックな視点の切り替えが魅力のタイトルだ。プレイ中には目の前の対象にだけ集中したり、俯瞰的に世界を見たりと、ミクロとマクロの視点切り換えを繰り返すことで、ゲーム世界がひとつにつながっていく。

　今回の講演内容においても、制作サイクルという長い時間単位を考慮する一方で、ミリセカンドのロード時間の最適化を考えるなど、視点の切り替えが多くあったという。エンジニアリングは目の前の課題に集中するイメージが強いが、そこで顔を上げて俯瞰してみると、その実装が本当に必要か、その問題の本質は何かなどが理解できるとのこと。