国内最大規模のゲーム業界カンファレンス「CEDEC2024」が、2024年8月21日（水）から8月23日（金）までの日程で開催されました。3日目となる8月23日（金）には、任天堂 企画制作部 大礒 琢磨氏、朝倉 淳氏、竹原 学氏が登壇し、「『ゼルダの伝説 ティアーズ オブ ザ キングダム』におけるフィールド制作とQA ～トーレルーフの裏側で～」と題した講演を行いました。
「トーレルーフ」は天井や地形を通り抜けてワープする移動手段のひとつ。この技術的背景には、フィールド制作フローの自動化とテスター、開発者の間にあった「隔たり」の是正によるデバッグ作業の改善など、一見無関係に思える各セクションでの技術的な取り組みが数多くありました。
TEXT / 浜井 智史
EDIT / 神山 大輝
本講演に登壇した、任天堂 企画制作部の大礒 琢磨氏（画像左）、竹原 学氏（画像中央）、朝倉 淳氏（画像右）
本講演は、2023年5月12日（金）に発売されたオープンワールドアクションRPG『ゼルダの伝説 ティアーズ オブ ザ キングダム』（以下、『ティアーズ オブ ザ キングダム』）における主人公リンクが使用する能力「トーレルーフ」の実装経緯が解説されています。
「トーレルーフ」は洞窟や建造物の天井を通り抜け、その上に移動できる機能で、通り抜け先が安全に着地できる空間であれば、基本的にはフィールドのどこにいても使用可能です。
「トーレルーフ」使用例。洞窟内部の天井を通り抜けて地上に脱出できる
実装難易度が高く見える「トーレルーフ」ですが、本機能のために特別な技法を用意したわけではなく、異なる3つのセクションで独自に進めていた施策が最終的に絡み合った結果生まれたものであると大礒氏は語ります。
3セクションそれぞれの施策について、QAエンジニアの大礒氏、エンバイロメントプログラマーの朝倉氏、地形リードアーティストの竹原氏が説明を行いました。
最初に登壇したのはエンバイロメントプログラマーの朝倉氏。同氏は前作『ゼルダの伝説 ブレス オブ ザ ワイルド』（以下、『ブレス オブ ザ ワイルド』）でフィールドのプロシージャル描画や、物体の燃焼などに関わる「化学エンジン」などを開発しました。
朝倉氏は2009年に任天堂へ入社して以降、プログラマーとしてゲーム開発に携わってきた
本作『ティアーズ オブ ザ キングダム』ではこれに加えて生態系や気候など世界全体の挙動に関するメカニクスや内部設計の開発を担当。こういった開発分野の担当者を、任天堂では「エンバイロメントプログラマー」と呼称しています。
「エンバイロメントプログラマー」の担当は、ゲーム内の世界全体に草を生やすプロシージャル描画や、植物や動物を適切な場所に出現させる仕組み、燃焼や通電のほか風の発生などが可能なシステム「化学エンジン」、時刻に合わせて気候や天候を制御するメカニクスなどの開発など多岐にわたる
前作『ブレス オブ ザ ワイルド』にも平原や山、砂漠、海、森など多様な地形が登場しますが、これらは多少の起伏があるものの、おおむね平面とみなせる地形でした。そのため、地形の各座標に対応する情報は、単純な2次元のテーブルデータに格納が可能でした。
このテーブルデータは、例えば溶岩と野生動物のスポーン位置に活用されています。野生生物はプレイヤーの周囲に湧き出す仕様となっていますが、溶岩に近いとスポーンしません。フィールドの各座標における溶岩までの距離は事前計算されているため、このテーブルデータを参照する形で実装が行われていました。
『ブレス オブ ザ ワイルド』では、水辺や溶岩までの距離のほか、森に近づくほど上昇する樹木の密度といった地形のデータを2次元のテーブルで保持していた
野生生物はプレイヤーの周囲に湧き出す仕様となっているが、溶岩に近い場所には湧かないように設計されている。フィールドの各座標における溶岩までの距離は事前計算され、テーブルに格納されており、ランタイムではこのテーブル内の計算結果を参照し、湧き出し判定に使用する設計となっている。このテーブル内情報は野生生物の湧き出し判定のほか、敵やNPCの行動判定、環境音の鳴らし分けといった処理に利用される
一方、本作『ティアーズ オブ ザ キングダム』では浮遊する空島や地下に広がる洞窟などが追加されたため、地形が縦方向に大きく拡張されました。地上や洞窟などが立体交差するため、前作と同じ2次元のテーブルでは地形の情報を格納できなくなりました。
先ほどの例示で挙げられた「溶岩」と「野生動物」で言えば、2次元的なテーブルでは野生生物と溶岩の距離情報を取得できず、溶岩の真横に動物が湧くといった想定と異なる挙動が生じてしまう
溶岩と野生動物の問題を立体的な空間で解決しようとした場合、生物の出現予定地から周囲の地形にレイキャストを行い溶岩を検出する仕組みの実装や、洞窟用に新たな2次元のテーブルを用意するなど、地上とは別に洞窟専用の対処が必要になります。しかし、洞窟用のテーブルを用意する場合、複雑に入り組んだ洞窟に対して用意すべきテーブルの数が膨大になるなど、これらの手法には懸念点がありました。
こうした観点から、「自由に洞窟や空島を作るためには、実装上のトラブルなどを考慮しても専用実装なしで済ませる必要があった」と朝倉氏は説明します。
何層にも重なる洞窟のために専用実装を施すと、バグや実装の違いによる挙動の不整合の温床となる問題がある。問題を減らそうとすれば仕様を制限しかねない
こうした中、前作を踏襲した2次元のテーブルは廃止され、地上・洞窟・空島、すべての地形で偏りなく一様にデータを格納するために「地形の表面を粗くボクセル化し、情報を格納する」という解決策が編み出されました。
足元にあるボクセルを参照するだけで地形の情報を取得できる仕組みを考案
立体交差した地形におけるボクセル構造の作り方として、例示されたのは上部がオーバーハングした（下の階の床よりも上の階の床がせり出し、根本から外側に広がっている）建造物です。
上部が大きくせり出し、根本より外側に広がっている建造物の一例
「地形の表面にデータを格納する」とは、言い換えれば「プレイヤーが到達可能な地表面にデータを格納する」ことを意味すると朝倉氏は述べます。この地表面を洗い出すため、地形に対して一定間隔でレイキャストを行う方法で、プレイヤーが到達可能な場所を網羅的に調査しました。続いて、検出した座標に対してボクセルを作成します。
プレイヤーが到達可能な地表面を黄色い点群で表示したもの。一定間隔で検出しているため、このままボクセルの位置として扱うことができる
生成したボクセルは地表面にあたる座標にしか存在しないため、疎な八分木である「Sparse Voxel Octree」として扱われる
ボクセル構造はフィールドに存在するすべての地形で使用されるため、すべての地形に対して大量のレイキャストを行う必要がありますが、処理負荷の高さがネックになりました。同氏は「ジオメトリ処理に強いHoudiniを介することで高速な計算が可能」と考え、Houdini上にゲームと同等の地形コリジョンを再現し、そこでレイキャストを行うことにしました。
実際のゲーム内には、メッシュで作られた地形やボックス、球などパラメータを基に生成されるプリミティブな地形コリジョンや、高さのテーブルデータによって作られる地形コリジョンといった多様な種類のコリジョンが配置されています。
これらの地形コリジョンをHoudini上で再現するため、コリジョンのジオメトリやマテリアル情報をHoudiniにインポートし、これらの情報に加えて内製のレベルエディタからも配置データをインポートしました。Houdiniによる高速なレイキャスト計算により、日々更新される地形に対してボクセルを更新し続けることが可能になりました。
すべての地形に対して一連の処理をCIツールで毎晩実行する仕組みを取り入れたことで、地形が更新されても問題なくボクセルが更新できるようになった
Houdiniにインポートした地形のマテリアル情報をもとに計算された、各ボクセルの水辺や街道までの距離、樹木の密度（森らしさの度合い）などもボクセルと併せて格納されています。
各ボクセルの水辺からの距離を可視化した様子。湖の周辺が赤く表示されている
地表面の検出は洞窟内部にも適用されており、各ボクセルが洞窟の入口からどれくらい離れているかを算出し、ボクセルに情報を格納することで、洞窟の奥深くに潜るにつれてBGMを変化させるような実装にも役立ったとのこと。
洞窟の入口からの距離に応じて色分けをした図
地表面をボクセル化したことで、「周囲のボクセルを参照する」という一貫した実装ですべての処理をシームレスに行えるようになった結果、洞窟や空島において特別なデータを参照する実装が不要になりました。こうした実装上の工夫から、実装の違いによる挙動の不整合やバグの発生などが抑制できたほか、仕様の制限を検討することもなくなったと朝倉氏は語ります。
これだけで当初の目的は十分達成できたといいますが、このボクセル情報は当初の想像を超えてさまざまな場面で利用されることになったとのこと。例えば、ボクセルに対するレイキャストを実装したところ、地形コリジョンへのレイキャストと比較して約10倍速く処理できることがわかりました。ボクセルはかなり粗いサイズである分レイキャストの精度が低くなるため「ざっくりと周囲の地形を調べたい場合」などに活用されています。
地面がどのあたりにあるか、前方に壁があるかといった調査であれば、ボクセルに対するレイキャストで十分な結果が得られたという
サウンドに関しても、残響や遮蔽物による音響効果を実現するためにボクセルに対するレイキャストでプレイヤーの周囲の地形を走査している。また、音が回折して伝わる効果を実現するために、ボクセルに対してA*（Aスター）経路探索を行っている。当初の想定用途である環境音の鳴らし分けだけにとどまらず、サウンド面においても多様な用途でボクセルが活用された
グラフィックスにおいては、流体シミュレーションによって地表付近の霧のエフェクトを動かすためにボクセル情報を用いた事例が紹介されました。また、処理負荷を可視化したヒートマップを作成する際はCIでフィールド全体の処理負荷計測を漏れなく実行するため、ボクセルのある場所を巡回座標として利用したとのこと。
プレイヤーの周囲のボクセルのみ関係するため、立体交差する洞窟内でも破綻なくシミュレーションが可能
ボクセルのある場所を巡回することで、地形の立体交差の有無にかかわらず、プレイヤーが到達可能な地表面を計測できる
その他、経路探索などに利用されるナビメッシュに関する事例も紹介されました。フィールドのコリジョンは地形を構成する各パーツのコリジョンが組み合わさって出来ており、コリジョン同士が交差していることもあります。各コリジョンにナビメッシュを生成すると、別のコリジョンの裏側など、本来プレイヤーが到達できない場所にも不要なナビメッシュが生まれてしまいます。
従来では手動で削除するか放置されていた不要なナビメッシュは、ボクセル情報を活用することで自動で削除できるようになりました。ボクセルに格納されるデータはプレイヤーが到達可能な地表面にのみ存在するため、データの格納されていない座標のナビメッシュはプレイヤーが到達不可能だと判断できます。その条件に該当するナビメッシュだけを割り出し、自動で削除するという手段が取れるようになりました。
「特定の地形がコリジョンの裏側かどうか」という判定は、ボクセル情報を参照することで実現可能に。世界全体を一貫したした仕様で処理したいという想いから、数多くの使用用途が生まれた
続いて発表者はQAエンジニアの大礒氏に交代し、本作のデバッグ作業に関する取り組みが解説されました。
2010年に任天堂に入社した大礒氏は、『New スーパーマリオブラザーズ U』でシステムプログラムや開発環境を担当。『ブレス オブ ザ ワイルド』『ティアーズ オブ ザ キングダム』ではQAエンジニアリングを担当した
QAエンジニアリングはデバッグ調査やバグ修正を行う職種というイメージを持たれがちですが、「バグが全くないゲームの完成を目指しているわけではない」と大礒氏は語ります。バグがないゲームを最終ゴールに設定してしまうと、「バグをなくすことこそがすべて」という思考に陥り、バグの原因になると思しき要素をすべて削りたくなる可能性があります。
不穏な要素にブレーキをかけていくと、面白くなるはずだった要素も削ぎ落としかねません。このことから、大礒氏は「（QAエンジニアは）バグの少なさだけにとらわれず、ゲームの面白さを大事にするべき」と結論づけたといいます。
大礒氏によれば、ゲーム制作では「制作」と「確認」のサイクルが重要であり、“面白そうな遊びのアイディアを思いついたら、試しに作ってみて面白さの手応えを確認する”というサイクルを繰り返すことでゲームが面白くなっていくとのこと。バグ修正についても同様で、バグの発見から修正、再チェックのサイクルで作業を行います。
「制作」と「確認」のサイクルを効率化する上で活用できるのが“デバッグ機能”です。本講演における「デバッグ機能」は、開発者やテスターが活用する便利な機能を総称したものを指しています。
例えば、フィールドを歩き回らずとも敵の挙動が確認できるように、任意の敵キャラクターをプレイヤーの目の前に生成する機能などが「デバッグ機能」に該当します。また、PCツールで地図を表示し、行きたい場所をクリックすると、実機で起動しているゲーム上でワープが行われる機能なども存在しました。
製品では使用できないが、開発中に便利に使える機能をデバッグ機能と定義
ゲーム開発には多くのスタッフが関わっているため、フィールドに配置されたオブジェクト1つとっても「誰が作ったか？」を明らかにするのは容易ではありません。
これを一目でわかるようにするため、「配置されているオブジェクトの情報を参照できる機能」を作成。また、オブジェクトが前作『ブレス オブ ザ ワイルド』から既に配置されていたものなのか、本作『ティアーズ オブ ザ キングダム』で新たに追加されたものなのかも一目で確認できるようになり、開発者への相談がスムーズに実施できるようになりました。
オブジェクトを配置したレベルデザイナーやアーティストの名前が閲覧可能。前作から既に配置されていたか否かも確認できるように。これによって制作サイクルが大きく効率化した
また、レベルデザイナーがフィールド上に新しいイベントを作ろうと企画を考えた際の資料に位置情報を貼り付けることで、資料からワンクリックでワープ可能な機能も実装されています。これによって目的地を探して時間を浪費することなく、企画を検討する時間を確保できたとのこと。
開発Wikiやタスクに位置情報を貼り付けることで、該当地点にワープ可能
この他にも、「ウルトラハンド」（物体を浮かせて移動させ、別の物体とくっ付ける機能）をテストする際、インゲームで対象オブジェクトを選択した後にPCツール上で物体を生成する機能も実装されました。
デバッグ機能により、あらゆる物体をボタン1つで生成可能
類例として、一覧で表示されたNPCの地点に直接ワープする機能や、アイテム一覧から武器を入手する機能なども用意されていました。
NPC一覧には、各NPCが配置されている地点にワープできるボタンが搭載されている
フィールドに配置する物体やNPCだけでなく、アイテムの入手も可能
バグの報告も一定の自動化が行われています。不意にゲームがクラッシュした際、PC上でバグ報告ウィンドウが自動で表示され、発生条件等の情報が自動掲載されるほか相談先の担当エンジニアの名前も確認できます。また、同じ現象を既に別の人が経験しており、報告を済ませていれば、追記モードでウィンドウが表示される仕様となっています。
ゲームがクラッシュした際に自動で表示されるバグ報告ウィンドウ
同じクラッシュを経験した人が報告を残していれば、コメントを参照してクラッシュを回避しながら制作にあたることが可能
報告を受ける側の開発者も、ウィンドウから各種情報を閲覧することで迅速に対処できる。報告の手間を効率化したことで、作業がスムーズになった
バグ発生に関する統計情報をブラウザで閲覧できる機能も作成。バグが生まれたタイミングや発生場所といった情報が一覧で確認できる
各種ツールは連携しており、例えば日本語のセリフを英語やフランス語などへ翻訳するにあたって、翻訳者が使用するローカライズツール上に自動テストを用いて撮影されたゲーム画面のスクリーンショットが掲載されるようになりました。また、該当するセリフがどのような流れで表示されるのかを調べられるように、フローチャートツールに飛ぶ仕組みも実装されています。
自動テストなどで撮影したゲーム画面のスクリーンショットをローカライズツールに掲載し、ゲームの場面に適した翻訳をサポート
ローカライズツールからセリフのフローチャートツールに飛ぶ仕組みを作ったことで、翻訳の際にセリフの文脈などを簡単に汲み取れるように
さらに、自動テストで録画した主要イベントの映像を流用し、映像を確認しながら翻訳できる仕組みを作ったことで、ローカライズの品質や作業効率が向上したといいます。
これらのデバッグ機能の十分な手応えを感じたため、これらをテスターにも提供したいと考えたという大礒氏。ところが、テスターにデバッグ機能を提供するにあたって開発チームとテスターの間に存在する大きな「隔たり」が問題になったといいます。
開発チームは膨大な量の情報や数多くのツールを所持しています。一方、テスターがアクセスできる情報は少なく、使用ツールも限られていました。デバッグ機能を作成しても、その一部しかテスターに届かない状況であり、ツールを充実させるほど開発チームとテスターとの「隔たり」が広がってしまう構造でした。
開発チーム側が所持する膨大な情報・ツールのうち、テスターがアクセスできるのはほんの一部だけだった
この状況を解決し、テスターにもデバッグ機能を活用してもらうことが、QAエンジニアとしての新たなテーマとなったと大礒氏は語りました。最初に行ったのは「情報格差の是正」。開発者側は開発Wikiやチャットツールといった環境により、多くの情報に触れることができます。そこで、テスターにも開発Wikiの閲覧権限を付与し、チャットツールにも招待した上、タスク管理ツールの公開、開発者同士のミーティングへの招集などを実施。開発者が持つ最新情報を共有する機会を作り、制作への想いや思考をテスターにも伝えました。
テスターにオープンしたのは情報だけではなく、データ管理や2D可視化ツール、ローカライズツールにフローチャートツールなど、開発者と同じツールを提供。さらに、テスターがツールを使いこなせるようにハンズオン資料も作成されました。
「アクセス権を得る」という意味での「使える」と、実際にツールの機能を効果的に活用できるという意味での「使える」は異なる。情報とツールの開放だけでなく、ハンズオン資料も充実させた
バージョン管理ツール「Perforce」やHoudiniといった有償ライセンスが必要なツールの提供も検討
こうした試みによって、テスターによるバグの発見作業が格段に改善しました。例えば、特定の条件を満たすことで同じNPCが重複して生成されるバグなど、複雑な条件を満たして初めて発生する難易度の高いバグの解決も可能になったとのこと。
テスターに提供したデータ管理ツール。ゲームの進行に応じて各NPCがどこでどのような行動を取るのか知ることができる
イベントを制御するフローチャートツールの提供により、イベントの処理内容や分岐条件を確認しながらバグ調査が可能に
また、テスターがバグの再現に効果的なデバッグ機能の使い方をバグ報告に併記し、開発者が行う修正作業のサポートにつながった事例もありました。
さらに、開発者の「面白さ」に対する考えも含めて共有したことで、「それが実現されているか？」という視点をテスターが持った上でデバッグを行ってくれたメリットもありました。「ある敵キャラクターが行う攻撃のうち、2種類の攻撃が同じダメージ量となっているが、ダメージ量に変化を付けたほうが目指す方向性に近いのでは」といった、面白さを向上させるための提案もテスターから出るようになり、「目指している遊びが実現できているか」という観点でのデバッグが可能になったと大礒氏は語りました。
2種類の異なる攻撃で受けるダメージ量は、開発当初は同じ値だった。これはバグではなかったが、テスターが単なるバグ調査だけでなく、ゲームの面白さをより磨こうとする意識を持って調査に臨んでくれた結果だという
ここからは地形リードアーティストの竹原氏が登壇。地形全体のアートを監修する立場として、クオリティを維持しつつ作業の効率化を図るための方法について語りました。
竹原氏は2011年に任天堂へ中途入社。地形のアーティストとして内製のソフトに携わっている。『ブレス オブ ザ ワイルド』ではストラクチャーデザインリードとして建造物全般の監修や制作を担当。『ティアーズ オブ ザ キングダム』では地形リードアーティストとして地形のアート全体を監修した
地形制作の効率化の前に「自動化“すべきではない”作業はなにか？」を考えた際、レベルデザインやそれに応じたアセットの配置作業などゲームの中核を担う作業は人の手で行うべきと結論付けられました。また、洞窟に関するアートの検討とコントロールも自動化できない部分として挙げられました。
プレイ感に密接に関係する箇所は、アーティスト自らコントロールを行い、遊び心地を阻害しない見た目になるよう制作する必要があります。そのため、「プレイ感に直接影響しない装飾としての地形デザイン」についてのみ、自動化が適用できると竹原氏は述べました。
こうした中で制作されたのが、手作業でレベルデザインされた地形に対して、プレイ感に影響しない装飾的な部分をプロシージャルモデリングによって生成する「洞窟システム」です。
「洞窟システム」とは呼びつつも、装飾のプロシージャルモデリングは洞窟以外の地形にも使用可能
これまでのフローでは、遊び心地を検討するレベルデザイン工程が終わらない限りは絵作りの工程に移行できませんでした。また、絵作りが進行している最中に再びレベルデザインに立ち返るのは困難でした。
「洞窟システム」を活用したワークフローでは、レベルデザインと同時進行で洞窟の絵作りを行います。「洞窟システム」で試作したルックをもとに自動でディテールを付与するHDAをHoudini上で実装し、レベルデザイン後のレベルに対して自動的にディティールアップができるようになりました。
レベルデザインと絵作りという異なる作業が、互いの作業進捗の影響を受けずに同時並行で進められるため、制作サイクルの回転数が大幅に向上した
また、この洞窟システムは地底に広がる大規模な空洞や浮島のデザインなど、多くの地形制作においても活用され、費用対効果の高いツールとなったとのこと。
地底の大規模な空洞をプロシージャルに生成するほか、浮島の底面から突き出ている石柱をHoudiniでプロシージャルモデリングする基礎として、また鍾乳石や小さな岩の生成などにいおいても、「洞窟システム」は活用された
プロシージャルモデリングによって短期間で多種多様の絵作りが可能になり、当初の目的であった「大事な工程を残しつつ効率化を図る」ことが実現できたと竹原氏。さらに、洞窟システムを皮切りに、アーティスト自身からも作業の自動化が提案されるようになったそうです。
アーティストの現場制作におけるもう1つの大事な作業として、地形のデバッグ作業が挙げられました。例えば、ゲーム世界全体に1,000体ほど点在するお助けキャラクター「コログ」に関するデバッグ作業を、ゲームの仕様や地形が変わるたびにチェックするのは大変な作業になります。
ゲーム世界全体に点在する1,000体ものお助けキャラクター「コログ」。彼らを見つけてお願いを聞いてあげると、旅に役立つアイテムが貰える
人の目による確認は外すことができないため、コログに向かう時間の短縮と捜索の時間を短縮する方針が取られ、インフラチームが作成していた撮影機能を使用した「コログの場所を撮影するシステム」が開発されました。撮影した画面にワープできるボタンも実装されたため移動時間も大きく削減。
また、フィールドに配置した総数16万に達するアセットがすべて正しい状態なのかを確認する「全数チェック」と呼ばれる作業も大きな負担を伴います。この効率化にあたっては、確認の進捗を正しく管理し、複数人による同時作業でも重複が生じないようにするため専用のツールが用意されました。このように、目視で確認する作業は変わらず人が担いつつも、重複による二度手間などをシステム的に防止したり、対象を探す時間を短縮したりすることで、計画的かつ正確なチェックを実現できたといいます。
コログがいる場所を自動撮影により割り出し、目的の場所までボタン1つで移動できる
全数チェックツール。普段からビルドを使用して確認作業を行っているアーティストにとっても扱いやすいツールだったという
この他にも、プレイヤーやアイテムが地形の裏側に入り込んでしまう地形コリジョンの穴をいかに塞ぐかについて紹介されました。本作の地形はアセットの配置によって合成されているため、意図しない隙間が生じることも多かったとのこと。本作のフィールドは前作の約2.5倍の規模であるため。人海戦術で穴を探し出すには限界があったといいます。そこで開発されたのが、穴の場所におよその目星を付ける「穴探しツール」です。
「穴探しツール」で穴の位置に目星をつけた様子。赤い棘のようなものが集中している付近に穴がある。穴探しツールはプロジェクトの終盤あたりに完成の目途が立ったという
正確な位置は特定できないものの、地形の構造をよく理解している開発者が使うには最適なツールで、それぞれの穴がゲーム体験に支障をきたすレベルの大きさなのか、それとも放置して問題ない小さな穴なのかが大枠で判別可能だったとのこと。
ゲーム体験に支障のない小さな穴は無数に発生していた。「穴探しツール」を使用しても穴の場所を確実に特定できるわけではなかったことや、ツールの使用においてはHoudiniが使える必要があるなど、人材が限定されていることも踏まえて、小さな穴は塞がずに放置することに決めたとのこと
今回挙げられた3つの事例に限らず、手間になる作業をなくすのではなく「大事なものをなくさないために、その手段を考え、創造する」という考え方が、クオリティを高めるための効率化を進める上で常に原点としてあると竹原氏は語りました。
一貫した地形情報にアクセスする手段である地表面のボクセル化、開発者とテスターの「隔たり」の是正とデバッグ機能の充実化、そして地形制作の効率化。これら3つの取り組みの中では、トーレルーフに関することは言及されていません。
契機となったのは、制作の区切りのタイミングであるマイルストーンで洞窟をプレイしていた時のこと。洞窟の奥深くまで探索し、十分な手応えが確認できたことで戻ろうとしますが、歩いて引き返す道のりが面倒に感じられたために「デバッグ機能で空を飛ぶのと同じように、洞窟から簡単に脱出したい」というアイデアが生まれました。
洞窟から出るのが面倒な状態では、洞窟探索自体を楽しんでもらえない。普段の開発の際は、デバッグ機能で空を自由に移動し、崖の上まで上ることもできたため、この機能をインゲームでも活かす発想となった
トーレルーフの実装におけるネックは「天井を抜けた先、どこに出てくるのか」の判定だったとのこと。プレイヤーが到達可能な床という概念を考えたとき、すぐにボクセル情報が使えると思いついたという朝倉氏。生成されるボクセルは、トーレルーフによりプレイヤーが到達可能な床をすべて含んでいます。
プレイヤーが到達可能な床はどこにあるのか、そもそも足場は存在するのかといった処理を、あらゆる地形で事前に判定できる必要があった
トーレルーフで天井を貫通したプレイヤーがどこに出てくるのか。一見難問に思えたこの問題は、天井から上方向のボクセル情報を調べるだけで簡単に解決できた
しかし、ボクセル情報をトーレルーフに利用するには高い精度が求められます。もし地形に小さなコリジョンの穴があったら、それがプレイヤーが通れないような軽微な隙間だとしても、地表面を調べるためのレイキャストが中に入り込んでしまいます。その結果、本来はプレイヤーが到達できないはずの場所までボクセル情報が取得されてしまい、トーレルーフで地形の裏側にプレイヤーが出てくる事態が起こり得ます。
普段はバグにつながらないような小さな穴でも、トーレルーフの挙動に支障をきたす恐れがある
フィールドに存在するすべての穴を埋めたい。そう考えたとき、地形アーティストが試みた作業の効率化において、「穴探しツール」を活用した実績が思い出されます。
地形アーティストは世界中の穴を埋められる。しかし、ここで問題になるのは、トーレルーフで塞ぎたい穴は、本作において修正不要と判断された小さな穴だということ。塞ぐこと自体は可能ですが、数千にもおよぶ穴をすべて特定し埋めるのは厳しい作業です。さらに、穴を探して塞ぐためには地形コリジョンやゲームの仕様に詳しくなければなりません。加えて、「穴探しツール」にはHoudiniが使用できるという条件があります。
そんな中、穴を塞ぐ適切な人材を探すにあたって良い効果をもたらしたのが、大礒氏が進めていた「開発者とテスターの隔たりの是正」でした。テスターがゲーム仕様や地形コリジョンの知識を身に着けており、ツールの格差もなくなったことでHoudiniを提供する土台も完成していたため、テスターに穴探しを手伝ってもらう選択をすることができるようになっていました。
テスターの協力を得て穴を塞ぐ一連のフローは大きく3つに分けられました。1つ目は穴を検出する工程。竹原氏がエンジニアにかけ合い、塞ぐべき穴のおおまかな位置を自動で検出できるツールを作成してもらいました。
2つ目は穴を探して報告する工程。穴が発生する原因は、地形そのものに穴が開いているのか、それとも地形の上に乗っている3Dモデルの問題なのか、配置の問題で隙間ができているのかなど多岐にわたります。Houdiniを使いながら穴の正確な位置を割り出し、適切な情報を報告する作業が最も大変で、時間もかかりますが、この部分をテスターが手伝ってくれることになりました。
3つ目はアーティストによるデータの修正です。テスターが穴の調査報告を送る際、穴の正確な位置情報や、穴の場所へ向かうためのワープボタン、スクリーンショットに配置されているデータのファイル名など、修正に必要な情報をすべて揃えてもらったことで、スムーズな修正作業が可能となりました。
トーレルーフの実現においては直接的な施策や技法などが用意されたわけではなかったものの、エンバイロメントプログラマー・QAエンジニア・地形アーティストのそれぞれの立場で取り組んでいたさまざまな施策が掛け合わさることで、新たな遊びが生み出された好例と言えます。
これら3つの取り組みは特定のゲーム仕様に特化したアプローチではなく、汎用的で堅牢な仕組みやワークフローの改善を意識していたことも、最終的にトーレルーフに結び付くことができた要因の一つではないかと大礒氏は述べた
『ティアーズ オブ ザ キングダム』の開発においては各所で進行していた取り組みがチーム内で随時共有され、常に情報がオープンになっていたとのこと。そういったチーム内の透明性や、形成された制作文化が功を奏し、トーレルーフの事例の他にもあらゆる場面で個々の取り組みが掛け合わさり、新たな成果が生み出されてきたといいます。「本講演の内容がゲーム制作に少しでも役立てば嬉しい」という大礒氏の言葉で講演が締め括られました。
『ゼルダの伝説 ティアーズ オブ ザ キングダム』におけるフィールド制作とQA ～トーレルーフの裏側で～ - CEDEC2024『ゼルダの伝説 ティアーズ オブ ザ キングダム』公式サイトゲームメーカーズで編集や諸業務に携わっています。『星のカービィ』シリーズと『ポケモン不思議のダンジョン』シリーズが好きです。
西川善司が語る“ゲームの仕組み”の記事をまとめました。
Blenderを初めて使う人に向けたチュートリアル記事。モデル制作からUE5へのインポートまで幅広く解説。
アークライトの野澤 邦仁（のざわ くにひと）氏が、ボードゲームの企画から制作・出展方法まで解説。
ゲーム制作の定番ツールやイベント情報をまとめました。
CEDEC2024で行われた講演レポートをまとめました。
BitSummitで展示された作品のプレイレポートをまとめました。
ゲームメーカーズ スクランブル2024で行われた講演のアーカイブ動画・スライドをまとめました。
CEDEC2023で行われた講演レポートをまとめました。
東京ゲームショウ2023で展示された作品のプレイレポートやインタビューをまとめました。
UNREAL FEST 2023で行われた講演レポートをまとめました。
BitSummitで展示された作品のプレイレポートをまとめました。
ゲームメーカーズ スクランブルで行われた講演のアーカイブ動画・スライドをまとめました。
UNREAL FEST 2022で行われた講演レポートやインタビューをまとめました。
CEDEC2022で行われた講演レポートをまとめました。
