“トーレルーフ”の裏側で何があったのか。「ティアーズ オブ ザ キングダム」開発陣が語る，一貫した実装と効率化の重要性［CEDEC 2024］

　ゲーム開発者向けカンファレンス「CEDEC 2024」にて，2024年8月23日に開催されたセッション「『ゼルダの伝説　ティアーズ オブ ザ キングダム』におけるフィールド制作とQA　〜トーレルーフの裏側で〜」を紹介しよう。

　登壇したのは，任天堂の企画制作部でQAエンジニアリングを担当した大礒 琢磨氏と，エンバイロメントプログラミングを担当した朝倉 淳氏。そして地形リードアーティストの竹原 学氏だ。同セッションでは同作のプレイヤーなら必ずお世話になっただろう「トーレルーフ」をテーマに，本作の開発がどのように進められたかが，3人の登壇者によって解き明かされた。

任天堂の企画制作部の大礒琢磨氏（前列左）と朝倉 淳氏（前列右），竹原 学氏（後列）

「ゼルダの伝説　ティアーズ オブ ザ キングダム」公式サイト

トーレルーフはどうやって生まれたのか

　セッションは，まず大礒氏がトーレルーフの説明を行うところからスタートした。
　トーレルーフとは，「ゼルダの伝説　ティアーズ オブ ザ キングダム」（以下，ティアーズ オブ ザ キングダム）に登場するリンク（主人公）の能力の一つで，発動すると現在地点の真上にある天井を突き抜け，その上に登ることができる。抜けた先に安全な空間がなければ使えないが，分厚い天井がある場所や，洞窟内などでも使用できる。地底世界から地上まで続く石の柱を通って，地上に出ることさえ可能なのだ。

　この機能は見るからに不具合やバグを生み出しそうで，実装が難しそうに思える。だが実際は，あっさりと実現できてしまった。その理由は，登壇した3人がそれぞれ別の目的で推し進めていた取り組みがあったからだという。では，それらはどんな取り組みだったのだろうか。

一貫した実装は応用に強い

　核心部分は最後に説明するとして，まずは朝倉氏が自身の取り組みについて発表を行った。
　エンバイロメントプログラミングを担当する氏は，前作「ブレス オブ ザ ワイルド」においては，世界中の物体を燃やしたり，通電させたり，風を発生させたりできる「化学エンジン」や，自然な草を生やすためのプロシージャル描画を担当していたという。
　そして「ティアーズ オブ ザ キングダム」では，世界中の草花や生物を適切な場所に出現させる植生や生態系を管理する仕組み，気候や天候を制御する仕組みなどを開発したという。


　そんな朝倉氏が推し進めていたのは「一貫した地形情報へのアクセス手段である，ボクセル情報の提供」だ。
　前作「ブレスオブワイルド」の地形情報は，もちろんさまざまな起伏はあれど，世界全体で見ればおおむね平面と見なしてよいものだった。ゆえに単純な2次元のテーブルデータを用意すれば，各地の座標に対応する情報を格納できたそうだ。


　地形情報には，水や溶岩までの距離や，森の密度などのデータが保持されており，ゲーム内のプログラムがいつでも参照できる仕組みになっている。これにより森と溶岩の周りでは登場する動物の種類が変わったり，溶岩の中に動物が現れ，出現と同時に燃えたりせずに済んでいたのだそうだ。

　しかし「ティアーズ オブ ザ キングダム」では，空島や洞窟といった特殊な地形が多数追加され，世界が縦方向に拡張された。なので従来型の2次元のテーブルデータでは，対応しきれなくなってしまった。
　であれば，複雑な構造の場所には専用のテーブルデータを用意すればいいのではないか。しかしこの方法では幾層ものデータが必要になってしまい，バグの温床になりかねない。それを防ぐためにも，特殊な実装なしに済ませたいと朝倉氏は考えた。


　その結果思いついたのが，地形の表面を粗くボクセル化し，そのボクセルにデータを格納する方法だ。


　地形表面のボクセルにデータを格納するためには，プレイヤーが到達可能な地表面をすべて洗い出さなくてはならない。そのためにはプレイヤーの移動をシミュレートし，辿っていく必要がある。そして到達可能な地表面に対し，一定間隔でレイキャスト（光線の当たった座標を得る方法）を行えば，これは網羅的に調べられるはずだ。さらに生成された地表面の座標は一定間隔に並んでいるので，そのままボクセルの位置に使うこともできる。


　もちろんゲーム内の世界全体でこれを行うには，膨大な計算が必要になる。しかしジオメトリ処理に強いDCCツール・Houdini（フーディニ）を使えば高速に行える。 ジオメトリ情報やマテリアルの属性などをインポートし，Houdini内にゲーム内と同等の地形コリジョンを再現すれば，そこでレイキャスト処理を行えばいい。こうしてプレイヤーが到達可能な地表面を洗い出し，ボクセルを生成することができたのだった。


　この処理は十分に高速だったため，全世界の地形に対する処理を，夜のうちに実行できた。このため開発期間中，日々変化していく地形に対して，ボクセルの更新が続けられたという。

　さらにボクセルに格納するデータについても，地形のマテリアル情報も取り込んでいたので，Houdini上で計算できてしまう。こうして洞窟や建物の中でも，周囲のボクセルを参照するという一貫した実装により，すべてのシチュエーションを処理できるようになったのである。


　これで当初の目的は達成できたわけだが，このボクセル情報は想像を越えてさまざまな場面で利用されることとなる。地形コリジョンにレイキャストするよりも，ボクセルに対してレイキャストしたほうが処理が10倍速いため，周囲の地形をざっくり参照したいときにも便利に使えるのだ。例えばサウンドの処理などはこれで十分だし，洞窟内で音が回折して伝わってくる効果などに利用されているとのこと。


　グラフィックスの面では，霧のエフェクトを流体シミュレーションで動かすための流体計算用のグリッドもこれを利用している。応用事例はほかにも事欠かないそうだが，こうしたことが可能になったのも，最初の要求を一貫した実装で実現したからこそといえる。

報告と修正の負担を減らせばゲームは面白くなる

　続いては，QAエンジニアである大礒氏の発表が行われた。
　前作から引き続きQAを担当したという大礒氏だが，今作で改めて考えたことがあるという。それは「QAエンジニアはバグのないゲームをめざすだけでいいのか」ということだ。バグを減らすために面白い仕組みが削られてしまったら，それは本末転倒ではないか。


　そもそもゲームを面白くしていく作業とは，どういうものだろうか。それは「アイデアを元に試作し，実際に面白いかを確認する」という，このサイクルの繰り返しなのだ。そして，これはQA作業でも同様だ。バグの原因を取り除き，解決したかを確認する。この繰り返しによってゲームは良くなっていくのである。つまりこの双方のサイクルを大量に回すことで，バグが少なく，そして面白いゲームが生み出される。


　ここで重要になってくるのが，QAエンジニアにとって身近な存在であり，制作と確認の工程を効率化するデバッグ機能である。任意の敵を生成したり，マップ上の特定の位置にワープしたりといった便利な機能は，デバッグのみならず，ゲーム制作におけるあらゆる場面で活用されている。


　本作のデバッグ機能には，これに加えて担当するレベルデザイナーやアーティストを表示する要素が追加されている。これにより，バグが見つかったとき誰に相談すべきかすぐに分かるだけでなく，例えばレベルデザイナーがほかの開発者に新しいイベントを説明するときなどにも活用できるようになっているとのこと。
　このようにデバッグに役立つのみならず，開発においても役立つ機能が次々と実装されていったという。


　またデバッグに特化した機能も用意されている。PCゲーマーであれば，ゲームがクラッシュしたときにバグ報告のウィンドウが表示されるのを見たことがあるだろう。本作のテスト環境にも同様の機能があり，クラッシュ時のさまざまな情報が自動を収集し，報告できるようになっているという。さらには補足情報を手動で追加できる機能もあって，報告済のバグならば，クラッシュを回避しながら作業を進めることも可能とのこと。

　報告を受け取った側も，情報を元に効率よく調査・修正が可能で，さらに統計情報からいつからバグが発生しているのか，どのエリアで起こるのかといったことも分かるようになっている。


　こうした機能はローカライズ用のツールにも活かされ，翻訳すべきワードがどんな場面なのか，分かりやすいようスクリーンショットが自動的に撮影されるようになっている。さらなにシナリオのフローチャートを確認するツールなどとも連動することで，翻訳品質の向上や作業の効率化に貢献したとのこと。


　デバッグ作業の効率化に大きな手ごたえを感じた大礒氏は，この機能をテスターにも開放したいと考えた。しかしこうした機能を十全に活用するには，テスターにも開発チームと同等の権限と情報を共有する必要がある。また開発者にとって使いやすくするほど，テスターにとっては扱いづらくなるジレンマにも気が付いた。


　ならば，その格差を解消してしまえばいい。大礒氏はこの改革に乗り出し，以後はテスターにも開発チームと同じ権限，同じ情報が共有され，また同じツールにアクセスできるよう環境整備を行ったという。そしてツールが適切に使えるようハンズオンを作成し，必要に応じて有償ライセンスのツール――先のHoudiniやバージョン管理ツールなども，テスターに提供するようにした。


　こうした取り組みによって，特定の条件でのみ発生するような稀なバグを発見できるようになり，さらにオクタコスの攻撃パターンごとのダメージ量といったゲームバランスの問題なども，テスター側から指摘することが可能になったという。


　結果として，限られた時間の中でゲームを磨き上げていくのに，これらはとても有用だった。のみならず，開発者とテスターが同じチームの一員という意識を持てたことに意味があった。対立ではなく，同じ方向から作品に向き合い，制作に取り組めたのが大きかったと大礒氏は話していた。

人の手によらなければならない部分を見定め，ほかを自動化すること

　さて，最後は地形リードアーティストの竹原氏の発表だ。
　前作では建物全般の監修や制作を行い，今作では地形アート全体の監修と制作を担当したという氏は，クオリティを担保しながら効率化を図る手法を模索していたという。


　もちろん，あらゆる場面で効率化できるに越したことはないが，アーティストの責任としてクオリティを犠牲にはできない。しかし「ティアーズ オブ ザ キングダム」では，プレイヤーに新しい体験を届けるため，とんでもない物量が必要となっていた。世界の床面積は前作の2.5倍に達しており，以前と同じやり方では人員が足りないのが目に見えていたのだ。かといって，人を増やせばクオリティコントロールが難しくなる。この物量に対応した新たな体制，ツール，ワークフローが必要なのが明らかだった。


　中でも効率化が顕著に求められたのが洞窟だ。ハイラル世界に200か所以上あり，一つひとつにさまざまな遊びが付随している洞窟は，より良いゲーム体験を届けるために試行錯誤を重ねる必要がある。検討，制作，そして体験のサイクルの繰り返しである。かといって，やみくもに自動化を進めてしまうと，大事なものを失ってしまう可能性が高い。そこで“自動化できないものは何か”をまず考えたという。


　まず捨てられないのは，遊びを形作るレベルデザインだ。ゲーム体験の核となる部分である。次に，レベルデザインに付随するアセットの配置作業。つまり小物や敵の拠点配置などである。加えて洞窟内に登場するアートも，アーティストがコントロールできるようにしたい。つまり自動化できるのは，遊びに関わらない部分のみである。

　これらを踏まえて，洞窟のワークフローの最適化がプログラマーと共に検討された。その結果生まれたのが「洞窟システム」だ。これはレベルデザインに影響しない装飾的な部分を，アーティストのコントロールの元，プロシージャルに生成するシステムである。


　洞窟システムの登場により，レベルデザインと装飾の作業が，平行して進められるようになった。以前のワークフローは直線的で，前工程が終わらないと手を付けにくかったので，これは大きな進歩といえる。洞窟用として生まれたシステムではあったが，気がつけば鍾乳石の生成や空島の制作にも転用され，ツールとしての費用対効果はかなり高いものになったそうだ。


　さらに，アーティスト達の意識にも変化があらわれた。手作業にこだわっていた彼らから，さらなる自動化のアイデアが提案されるようになったという。クリエイティブな要素を取りこぼすことのない自動化を実現できたことで，守るべき部分とそうでない部分がはっきり分かるようになったのだ。


　また地形のデバッグも難題だったという。とくにコログの位置確認は，自動化できない作業として重くのしかかってきた。どうしても人の目で確認する必要があるからだ。では，省略できるのはどこか。それは現地に向かうための移動時間だ。
　そこで開発インフラチームが作っていた自動撮影機能を使い，コログを撮影するシステムを作ってもらった。写真の場所にワープできるボタンも付いて，これを目視確認に活用した。


　マップに配置したアセットの全数確認も膨大な数となったが，目視が必要な部分以外はツールで自動化し，情報共有の仕組みで作業の重複を避けることで，計画的に進められようになった。
　さらにコリジョン（地形の当たり判定）の確認にも自動化は必須だった。地形に穴があるとリンクやアイテムがそこから落ちてしまうので，これはどうしても潰さなくてはならない。しかし，そもそもこうした穴は発見が難しく，マップの規模も前作の2.5倍である。プロジェクト初期からエンジニアに相談していたものの，しばらくは良い方法が見つからなかったという。


　そして開発中盤になって完成したのが，穴の場所に目星を付ける「穴探しツール」だ。実際に使ってみると効果は一目瞭然で，問題のある穴はこれで比較的簡単に直すことができた。ただゲーム進行への影響がほとんどない穴も数千個発見され，これをどうするかで悩まされたという。結果的に，これらは費用対効果を考えて修正はいったん見送られることになった。安全な穴であるなら，ゲームが進行不能になることもないのだから。
　こうして大きな穴は撲滅され，ハイラルにひとときの安寧が訪れた，のだが……。

この赤い線が集中しているどこかに穴がある

それで結局，トーレルーフはどうやって生まれたのか

　と，ここまで説明してきても，トーレルーフの話がまったく出てこなかったわけだが，ようやっと話が冒頭に戻る。トーレルーフが発案されたのは開発の中盤，全員でゲームをプレイして感触を確かめる，マイルストーンのタイミングだったという。洞窟を探索したあと，入口に戻るのが大変なことが判明し，それを解決する手段として生まれたのがトーレルーフだったのである。


　このアイデアは，まず朝倉氏に持ち込まれた。トーレルーフの終着点は，プレイヤーが到達可能な地形でなくてはならない。つまりボクセル情報が活用できることに，氏はすぐに気が付いたそうだ。
　ただ一つ問題があった。地形に残っているコリジョンの穴が，トーレルーフの邪魔になってしまっていたのだ。小さな穴からレイキャストが入り込み，そこにボクセルが生まれてしまうのが原因だった。


　つまりすべての穴を塞がなくては，トーレルーフは実現できない。穴を塞ぐには，地形アーティストが手作業で行う必要がある。穴探しツールとHoudiniを使わねば，穴は塞げないのだから。しかしマンパワーが足りない。なにせ，それが理由で一度は見送っているくらいなのだ。……いや待ってほしい。そういえばHoudiniが使える部隊が，地形アーティストのほかにもあったではないか。


　こうして使い勝手のいいデバッグツールの力もあり，テスター部隊が穴を探して報告し，地形アーティストが穴を修正するという作業フローが構築された。これによりハイラルの地に残っていた小さな穴も埋められ，ついにトーレルーフが実現したのである。


　このように，トーレルーフは汎用的で一貫した実装と，ワークフローの改善によって実現された。しかし似たようなケースは，「ティアーズ オブ ザ キングダム」の開発において大小の違いこそあれ，多くみられたことだったそうだ。今回紹介されたトーレルーフの事例は，あくまでその一つにすぎない。そのように総括し，大礒氏はセッションを締めくくった。

「ゼルダの伝説　ティアーズ オブ ザ キングダム」公式サイト

4Gamer「CEDEC 2024」記事一覧