各セクションの課題解決から生まれた『ゼルダの伝説ティアーズオブザキングダム』の移動能力"トーレルーフ"～CEDEC 2024（4）

開発者を対象とし、ゲーム技術・知識の共有を目指す国内最大級のカンファレンス「CEDEC2024」が開催された。数多くのセッションが行われた中、本稿では任天堂株式会社による「『ゼルダの伝説ティアーズオブザキングダム』におけるフィールド制作とQA　～トーレルーフの裏側で～」を紹介する。

記事の目次

・多重リグシステムで実現した『鉄拳8』の「膨大なプレイアブルキャラクター✕豊富なカスタマイズ」～CEDEC2024（1）

・『学園アイドルマスター』はアイドルの新たな魅力をいかに引き出したか？キャラクターモデリングや背景づくりなどその手法をあますことなく解説！～CEDEC2024（2）

・『ストリートファイター6』専門セクションによる「漫画のように技を格好良く見せる」Clothシミュレーションと背景の破壊表現～CEDEC 2024（3）

トーレルーフは、つくろうと思って開発し始めた機能ではない？

日本のオープンワールドゲームの中でも、自由度の高さから新たなマイルストーンとなった『ゼルダの伝説ブレスオブザワイルド（以下、BotW）』。その続編となる『ゼルダの伝説ティアーズオブザキングダム（以下、TotK）』では、冒険できるフィールドが地上に加え、空中世界や地底にまで拡大した。さらにいくつかのギミックを追加することで、プレイヤーが様々な攻略のアイデアを実践できるようになっている。

▲ゼルダの伝説　ティアーズオブザキングダム 3rdトレーラー

そんなゲームプレイの拡大は、どのように実現されたのだろうか。CEDEC 2024の講演「『ゼルダの伝説　ティアーズオブザキングダム』におけるフィールド制作とQA　～トーレルーフの裏側で～」では、多くのプレイヤーの自由な攻略に耐えうるフィールド制作をどう行なったかが解説された。

セッションには、任天堂の企画制作部からQAエンジニアリング担当の大礒琢磨氏、エンバイロメントプログラミング担当の朝倉淳氏、そして地形リードアーティストの竹原学氏が登壇した。

まず今回の講演のタイトルにもある「トーレルーフ」とは、 “屋根まで通れる”というダジャレからついた名前で、プレイヤーが様々な地形の天井から屋上まで通り抜けて移動できる能力のことだ。

これは『TotK』が空中世界や地底世界も冒険できるようになったことで、移動できる空間が上下にも広がったため生まれた能力と思われる。実装には相当な苦労があったのではないだろうか。ところが実際のところ、トーレルーフの実現にあたり、開発では「特別なことをしたわけではない」そうだ。

というのも、ゲームの世界をつくるエンバイロンメント制作チームとQAエンジニア、そして地形アーティストそれぞれが、トーレルーフの開発とは別の目的で推し進めていたものがあり、それぞれがかみ合った結果、トーレルーフが実現することになったのだという。

つまりトーレルーフとは、「最初からその機能の開発に特化するかたちで生まれていなかった」わけだ。各チームが課題解決を目指す中に、新機能が生まれうるヒントがあった、というのである。

エンバイロンメントプログラムが生み出した「地形のボクセル情報」

では、トーレルーフが生まれる過程において、実際に各チームがどのような目的の開発をしていたのか。まずはエンバイロンメントチームの朝倉氏が詳細に解説した。

まずエンバイロンメントプログラマーとは、ひと言で言えば「ゲーム世界全体の挙動」に関わる仕事である。主にフィールドの草のプロシージャル描画や、火が草に燃え移り広がっていくなどの自然現象を管理するエンジンのほか、草木の植生や天候の変化などを構築していくセクションとなる。

『BotW』では、草原から砂漠など様々なロケーションがあるが、基本的には平面を移動するものだった。そのため、水辺や溶岩までの距離や、樹木の密度など、全て2次元のテーブルデータでフィールドに対応する情報を格納することができていた。

例えば溶岩とプレイヤーとの距離に応じて、次の実装が行われている。

基本的に、プレイヤーの周囲の座標には野生生物がスポーンされる仕様だが、野生生物が溶岩の近くにいると不自然なため、プレイヤーが溶岩に近づくと、野生生物が出ないように設定されている。こうした設定に、テーブルデータが活用されているわけである。

ところが『TotK』では空中世界や地底世界といった、縦方向への移動が必要になるため、前作の2次元テーブルデータではまかなえない問題が生じた。

空中や地底で地上と同じテーブルデータは活用できない。そのため、例えば地底での地形に合わせてスポーンする野生生物にレイキャストを使用して出現を制御するか、もしくは地底の洞窟用のテーブルデータを用意するかが模索された。

しかし、地底の洞窟が複数階層に広がることもあるため、その都度テーブルデータを用意しなければならず、専用の実装が増えて煩雑になってしまう。あまりスマートではない実装は、バグや挙動の不整合の温床になる問題もあった。

空中や地底といった地形全ての情報を格納したいと考えた結果、従来の2次元テーブルデータの利用を廃止することに決めた。

代わりに、地形の表面を粗くボクセル化し、そのデータを格納する方法を探った。この方法により、空でも地底でもプレイヤーの足元にあるボクセルデータを参照することで、地形の情報を取得し、野生生物のスポーン判定やNPCの行動判定、環境音の鳴らし分けといった様々な要素の挙動を実装するねらいだ。

具体的なボクセル化についてはこうだ。まず「プレイヤーがその場所に到達できる地表面」という定義で各地形の表面部分を洗い出してゆく。

地形の表面にデータを格納するということは、言い換えれば「プレイヤーがその場所に到達できる地表面」にデータを格納するということである。そんな地表面を洗い出すためには、プレイヤーが移動可能な地表面をシミュレーションする必要がある。

そこで、今回は地形に一定間隔のレイキャストを打ち進めることで、プレイヤーが到達できる地表面を網羅的に調べていった。この手法は、洞窟のような立体交差がある地形であっても地表面を割り出すことが可能だ。

この手法で到達可能な地表面の点群を一定間隔で割り出し、それをボクセル化するプロセスを取った。ただ『TotK』のマップは非常に広大であり、上記のプロセスにも相当な計算量がある。そこで全世界の地形のレイキャスト～ボクセル化には、Houdiniを利用することで対応した。

Houdiniは当初の目的である「地形情報はプレイヤーの周囲にあるボクセルを参照する」ことの実装にも役立った。これにより、『TotK』に広がる様々な場所でも一貫した地形情報を取得できるようになり、挙動の不整合やバグも起こりにくくなったという。

朝倉氏は「これにより当初の目標は達成できた」と語るが、今回のボクセルデータは他にも環境音の鳴らし分けや音響演出の他、霧のエフェクトが移動する計算などに役立ったそうだ。

これらのボクセルデータが、あとの2つのセクションと絡むことで、さらなる発展に繋がることになる。

「面白くて、バグがないゲーム」のためのデバッグ機能の充実

続いて大礒氏がQAエンジニアリングについて解説した。このセクションは「バグがないゲームを目指すのが仕事」のように思われるが、大礒氏によれば「仮にそうすると、バグがなくなることが全てになり、バグで苦労する要素を削るようになる。結果、面白い要素もなくしたゲームになってしまう」と言う。

そのため、QAエンジニアが目指すべきものは「面白くて、バグがないゲーム」とのことだ。

その目標達成に必要なのが、「制作」と「確認」のプロセスを繰り返すサイクルである。面白そうな遊びをつくる「制作」と、実際に面白いかどうか「確認」する2つのプロセスを繰り返すことで、ゲームの面白さを仕上げていく。

このサイクルと同時にバグの原因を調べて直したり、バグがないかを確認する作業を繰り返すことで、バグがなくなっていく。これらのサイクルがたくさん回るほど、目的のゲームに近づけるという。

そんなバグチェックを開発チーム内で行う機能がデバッグ機能である。この機能は、例えば任意の敵を生成しバトルが機能するかなど、各機能に問題ないかチェックするために利用される。本作のデバッグ機能には、PCツール上でマップ上の確認したい場所をクリックするとすぐにその場所でチェックできるなど、多様な機能が実装されている。

この機能はデバッグだけではなく、先述した「面白い遊びの制作」と「実際に面白いかどうかの確認」プロセス全般で利用されているという。そのため、本作ではデバッグ機能を充実させることが、「面白くて、バグがないゲーム」という目的を達成する手段となった。

デバッグ機能で追加された機能のひとつに「マップ上のオブジェクトを配置したスタッフが誰か」をすぐに検索できる機能がある。

これにより、例えばデバッグ中に、あるオブジェクトの配置について担当スタッフと相談しやすくなり、制作と確認サイクルが効率化した。その他、マップ上でイベントをつくりたい場合も、仕様書内にデバッグ中に訪れているマップの位置情報を貼るだけで、ドキュメントからワンクリックでゲーム内のその場所を確認できるようにしている。

また「ウルトラハンド」という、ゲーム中のオブジェクトをくっつけて道具やクルマなどを好きに作成できる能力のチェックにも、開発ツールと連携したデバッグ機能が活用された。ここでは、デバッガーがチェックしたい部品を開発ツール上から生成できるようにしている。

バグの報告をスムーズに行う機能もある。例えばデバッグ中にクラッシュした場合、そのまま開発ツールでバグの詳細な報告を行える機能を実装した。プログラムを担当したエンジニアにも報告内容がわかるため、仕様に関する相談がしやすくなったという。こうした報告と相談を容易にする機能のおかげで、バグの修正は円滑になった。

さらに、デバッグ機能を他のツールと連携させ、作業効率を向上させた。その一例がローカライズツールとの連携だ。翻訳が必要な場面のスクリーンショットを添付することで、翻訳者が状況を理解しやすくしている。さらに、テキストの一連のながれを動画で確認できる機能を追加し、作業効率を大幅に向上させた。

こうしたデバッグ機能は、開発者だけでなくテスターにも活用された。これまではデバッグ機能の充実と言ってもあくまで開発者向けのもので、テスター向けにはあまり機能が解放されておらず、開発者とテスターとでは開発中のゲームを試す環境に隔たりが生じてしまっていた。開発が進む中、その点に気づいたという。

テスターとの環境の隔たりがある限り、「面白くて、バグがないゲーム」という目標の達成も難しくなる。そこでテスターにも開発者と同じツールを提供し、開発Wikiやチャットツール、タスク管理ツールへのアクセスを可能にしたほか、開発者とのミーティングにも参加してもらった。

この施策により、テスターも開発者と同等の環境でゲームのテストが可能となったため、さらにバグの減少と面白さの磨き込みに繋がったそうだ。この開発者とテスターの環境の隔たりをなくしたことが、後に大きな繋がりを生むことになる。

地形制作チームによる「大事なものをなくさない効率化」

リードアーティストの竹原学氏は、本作の地形制作において効率化に注力してきたが、「データをつくる作業は効率化できても、ゲームの遊びに基づいたアート表現を、最終的にアーティスト自身が体験し確認する作業は大切なのでなくしてはいけない」ため、効率化には限界があると語る。

とはいえ、本作では作業量が膨大で、前作の約2.5倍のフィールド面積を誇るため、物量の処理が大きな課題となった。人員を増やすことで対応しようとすると、アートのクオリティコントロールが難しくなるため、竹原氏は「手間がかかるが大事な作業を省かずに、効率化する方法」を模索した。

最終的に、地形アーティストの人数を抑えつつ、前作を超える物量を処理するために出した結論は「新たなツールやワークフローの導入」だった。

本作で特に制作効率の向上が顕著だったのが、200箇所以上に及ぶ洞窟の制作だった。各洞窟は異なる特徴や遊び方をもち、個別に設計されている。

制作プロセスは、まず「遊びの検討」から始まり、その後地形アーティストがデータを作成しビルドに載せる「制作」、そして最終的に「体験」としてゲームをプレイする。この3つのプロセスを繰り返し、洞窟を磨き上げていった。

重要なポイントは、この3つのプロセスのサイクルをいかに自動化するかだった。ただし、先述したようにスタッフによる確認が不可欠な部分もあるため、自動化の際には「手作業が必要な部分」の見直しが行われた。

結果、人の手で行うべき作業として、主に「遊びをつくるためのレベルデザイン」と、洞窟内の素材や敵配置といった「レベルデザインに応じたアセットの配置」、そしてゲームプレイを阻害しないようにする「洞窟でのアートの検討とコントロール」が挙がった。

レベルデザインなど、遊びの核になる部分は人の手でやらなくてはならない。そのため、自動化できるのは遊びに関わらない、アート部分のみということがわかってきた。

この洞窟制作の効率化を支えたのが、プログラマーと共同開発した「洞窟システム」だ。これは、レベルデザインを人の手で作成した後、アート部分をプロシージャルデコレーションによって自動生成するシステムである。洞窟システムは、空の島や地底、鍾乳石など、他の多様なエリアにも適用できる柔軟性もあわせもっている。

このシステムの導入によって、レベルデザインの後にアートの検討と実装を行うプロセスが、プロシージャルモデリングを挟むことでスムーズに進行するようになった。その結果、洞窟の遊び方が多様化し、ゲーム体験がさらに豊かなものとなった。

また、短期間で高品質なビジュアルの多様化が可能となり、当初掲げていた「大事なものをなくさない効率化」という目標が達成された。さらに、このシステムの成功により、アーティストからも「他の部分でも自動化が可能ではないか」という提案が上がるなど、意外な効果も生まれたという。

地形のデバッグも効率化が進められた。前作では主に人海戦術で対応していたが、今回はさらに作業量が増え、特にゲーム内の各地に存在する約1,000体のキャラクター「コログ」を地形のデバッグのたびに確認する作業は大きな負担となった。

そのため、効率化が模索され、コログの場所に向かう手間を減らすために新たなシステムが導入された。このシステムは、マップ上にいるコログの場所を自動で撮影し、スクリーンショットを表示する機能をもつ。さらに、画像をクリックするだけでそのコログの場所にワープできるため、作業効率が大幅に向上した。

開発の後期には、製品化に向けてゲーム内の約16万個のアセットが正しく配置されているか確認する「全数チェック」が必要となった。しかし、その膨大な量のアセットを手動で確認するのは現実的ではなく、ここでも効率化が求められた。

効率化のためのツールでは、「計画的かつ確実に確認できること」が重視された。具体的には、チェックの進捗を記録し、複数人で同時に作業しても重複が発生しない機能が必要とされた。

そこで開発された全数チェックツールは、ゲームをチェックする右画面に開発ツールが連動している構成をとった。PC画面上のデータを確認しながらチェックできることを利点としており、スタッフ間で作業の重複を避けることができる。

また、ルックを損ねたり、プレイヤーがはまり込んでしまう「地形コリジョンの穴」のチェックの効率化も図られた。

地形コリジョンの穴は、アセットの配置から意図せず生じやすく、発見が困難だ。ここまでに何度か語られているように、人海戦術によるチェックにも限界がある。そのため、ここでも効率化のためのツールが考案された。それが「穴探しツール」である。

これは地形上にコリジョンの穴がある可能性がある場所にチェックを入れるものだ。これは穴の正確な位置を指摘するものではないが、「ゲーム体験を阻害する修正必須の大きな穴」と「体験に影響のない小さな穴」に分けられた。

小さな穴の修正はHoudiniの使用が必要などコストがかかるため、開発チームは「ゲーム体験を阻害する大きな穴」にのみ対応する方針を取った。その結果、地形のデバッグもスムーズに解決していったという。

これらの効率化ツールの導入によって、チーム内で情報共有が容易になり、問題解決のスピードが向上した。竹原氏は、この環境を「ひとつの目標を達成するために、必要な情報をもった人がすぐに手助けできる環境」と表現している。これが他のセクションと繋がり、ひとつの能力を生み出すことに繋がった。

こうして「トーレルーフ」が生まれた

エンバイロンメント班の「ボクセルによる地形データ」、QAエンジニア班の「テスターと開発側とのデバック環境の隔たりをなくすこと」、そして地形制作班の「制作の効率化」が揃うことによって、冒頭のトーレルーフの実現に繋がっていく。

大礒氏はトーレルーフが生まれた経緯を次のように説明する。

当初、エンバイロンメント班によって洞窟での遊びがある程度できると、内部をチェックした後に入口まで走って戻るのが面倒で、そういったときにはQAエンジニア班のデバッグ機能にある自由な移動機能を使って対処していた。そんな中、「この自由な移動自体をゲームの遊びに組み込めないか？」という発想が生まれたという。

そこでトーレルーフ実装の話がエンバイロンメント班の朝倉氏に舞い込んでくる。朝倉氏が当初、悩んだのは「トーレルーフで天井を突き抜けた後、プレイヤーが到達可能な床がどこにあるのか？」だった。

そこで朝倉氏は「到達可能な床」ということから「ここまでに構築した、地形のボクセルデータが使えるのでは？」と判断。先述したようにボクセルデータはすでにプレイヤーが到達できる地表面を網羅している。つまり、トーレルーフ後にプレイヤーが到達できる床情報もまとまっていることに気づいた。

実装には、天井のボクセルの上方向にあるボクセル情報を調べるだけで、簡単に実現できそうだという目星がついた。

しかし問題もあった。地形にコリジョンの穴があると、レイキャストで生成したボクセルデータが穴の中にまでできてしまい、トーレルーフしたときコリジョンの穴にひっかかるバグが生じる。

この問題の解決法として、地形アーティストが行なったコリジョンの穴を探すツールが役立つことになる。とはいえ、穴を見つけて埋めることで簡単に解決できたわけではなかった。

小さな穴の修正には、「地形コリジョンやゲームの仕様に精通していること」や「Houdiniを使えるスキル」が必要であり、対応できるスタッフが限られていた。さらに、発見される穴は数千個に及ぶ可能性があり、それに対応するためには多くの人員が必要になることが予測された。

そこで再びQAエンジニアが取り組んでいた、テスターとの情報やツールの隔たりの解消が役立つことになる。

開発側とほぼ同等の情報や環境を得たテスターは、ゲーム中の地形コリジョンについても詳しくなっており、様々なツールを使いこなせていた。Houdiniも使用できるようになっていたため、なんとテスターがコリジョンの穴探しができるようになっていたのである。

ここで各セクションと連携しやすいデバッグ機能も大いに役立つ。コリジョン穴の調査ツールで調べ、テスターが穴を特定して報告し、そこから地形アーティストが修正していくという連携が実現。こうして世界の穴がふさがり、トーレルーフが実現した。

このように、各セクションが取り組んでいた効率化や情報の透明性を追求した結果、ゲームの重要な仕様が実装されるながれは、まるで『ゼルダの伝説』シリーズの謎解きのようにロジカルで、鮮やかだ。

今回の講演ではトーレルーフの事例に絞っているが、実は各セクションの課題解決による取り組みが連携することで、ひとつの成果が出るというケースが本作の開発では多々発生したという。

このように同セッションは、一般的な「アイデアを発想し、実現するための尽力」というより、「現場の課題解決から導き出されるアイデア」という、任天堂ならではの開発プロセスが窺える内容であった。