ゲーム・エンタメ最新情報のファミ通.com
取材・リポート
- 家庭用ゲーム
- Nintendo Switch
『ゼルダの伝説ティアキン』トーレルーフの実装に特別なことは何もしていない。地形情報へのアクセス、地形制作の自動化、デバッグ環境の充実が融合して誕生【CEDEC2024】

『ゼルダの伝説ティアキン』トーレルーフの実装に特別なことは何もしていない。地形情報へのアクセス、地形制作の自動化、デバッグ環境の充実が融合して誕生【CEDEC2024】

2024.08.25 09:00

更新

　2024年8月21日（水）から23日（金）にかけて開催された、日本最大のコンピュータエンターテインメント開発者向けカンファレンス“CEDEC2024（Computer Entertainment Developers Conference 2024）”。8月23日には“『ゼルダの伝説　ティアーズオブザキングダム』（以下、『ティアキン』）におけるフィールド制作とQA　～トーレルーフの裏側で～”というセッションが実施された。

　講演は、任天堂企画制作部『ティアキン』開発チームでQAエンジニアリングを担当する大礒琢磨氏、エンバイロメントプログラミング担当の朝倉淳氏、地形リードアーティストの竹原学氏が務めた。

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

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

QAエンジニア、エンバイロメントプログラマー、地形アーティストの取り組みが噛み合って実現したトーレルーフ

　初めに、大礒氏が『ティアキン』の遊びの要素のひとつである“トーレルーフ”について紹介。トーレルーフは天井を突き抜けて屋上に移動する能力で、薄い天井のほかに洞窟でも利用することができる。

　この能力は、一見すると実現が難しそうに見えるが、トーレルーフの開発のために、何か特別なことをしたわけではないとのこと。QAエンジニアの大礒氏、エンバイロメントプログラマーの朝倉淳氏、地形アーティストの竹原氏それぞれが、別の目的で進めていたものが、トーレルーフのアイデアが出た際に、うまく噛み合うことで実現したという。

　講演では、それぞれが行った取り組みが順に紹介。三者から紹介される内容は、トーレルーフの実装とは無関係に思えるかもしれないが、大礒氏いわく「講演の最後には3つのお話が結びついて、トーレルーフ実装の裏側を知ることができる」とのこと。3つの内容のどの要素が鍵となるか予想しながら聞いてもらえればと説明されたところで、さっそく朝倉氏から取り組みが解説されていった。

地形に一様に情報を格納すべく、地形表面を粗くボクセル化

　朝倉氏は、前作『ゼルダの伝説　ブレスオブザワイルド』（以下、『ブレワイ』）では、世界中に草を生やすためのプロシージャル描画、世界中の生態系などに合わせて適切に気候や天候を制御する仕組みなどを開発。これらはゲーム世界全体の挙動をターゲットにしたメカニクスや内部的な設計の一部。朝倉氏からは、地形全体の処理ついて紹介された。

　『ブレワイ』では、平原や山や砂漠、海、森などさまざまな地形が登場。これらは多少の起伏はあるものの、おおむね平面とみなせる地形だったため、単純な二次元のテーブルデータを用意すれば、世界中の地形の各座標に対応する情報を格納できた。

　実際に『ブレワイ』では、二次元のテーブルデータとして水辺までの距離や溶岩までの距離のデータを保持。森に近づくほど上昇する樹木の密度や街道までの距離といった地形情報も保持しており、どこにいてもゲーム内のプログラムから参照できるようにしていたという。

　たとえば、溶岩までの距離の利用事例。プレイヤーの周囲の座標には野生生物が湧き出すようになっているが、事前に溶岩までの距離を参照して、溶岩に近すぎないことをチェック。プレイヤーが溶岩に接近しても、溶岩のすぐ近くに野生生物が出現するのを抑制できる。

　野生生物が溶岩のすぐ横にいるのは不自然で、近づきすぎると野生生物が勝手に溶岩に触って発火しかねない。こうしたチェックは、ゲーム世界の納得感を担保するために重要だったという。ほかにも、敵やNPCの行動判定、環境音の鳴らし分けなどの判定に地形の情報を利用したそうだ。

　今作『ティアキン』では、開発の序盤から空島や洞窟が多数追加されるなど、世界を縦方向に拡張すべく動いていた。ここで、いままで平面的だった地形に空島や洞窟が増えてしまうと、新たに追加された地形が立体交差してしまい、従来の二次元のテーブルデータとは整合性が取れなくなってしまい、情報を格納できないという問題が発生する。

　地上では、二次元のテーブルデータで溶岩までの距離を取得可能。野生生物はうまく溶岩付近を避けられたが、洞窟だけテーブルデータがないために溶岩までの距離情報を取得できなかった場合、野生生物は溶岩の位置がわからない。このままの実装では溶岩のすぐ横に出現してしまうなど、地上と異なる挙動になってしまう。

　これを修正するには、出現予定地から周囲の地形にレイキャストして溶岩を検出できるようにしたり、洞窟用に二次元のテーブルデータをもう一層用意したりする必要が出てくるかもしれない。

　いずれにせよ、地上とは別の洞窟専用の実装が必要になったということだ。シンプルな洞窟だけならどうにかなるかもしれないが、複雑に入り組んだ洞窟も作れることを考えると、実際には何層のテーブルデータが必要かわからなかったそうだ。

　この状態で専用実装を増やすとバグや挙動の不整合の温床になりがちだ。解決するには仕様に制限を課すことも考えなければならない。自由に洞窟や空島を作れるようにするためにも、専用実装はなしで済ませたいところで、地上、洞窟、空島を偏りなく情報を格納できる方法が必要となった。

　そこで、二次元のテーブルデータの利用を廃止し、地形の表面を粗くボクセル化して、そのボクセルにデータを格納できるようにすれば解決できるのではと考えた。足もとにあるボクセルを参照すればどこでも地形情報を取得でき、挙動の実装が可能になるからだ。

　なお、立体交差した地形があったときは地形表面のボクセル構造をどう作ればいいかという問題が生じる。地形の表面にデータを格納したいということは、言い換えると「プレイヤーが到達可能な地表面にデータを格納したい」ということだと、朝倉氏。地表面を洗い出すには、プレイヤーの移動をシミュレーションして、地表面を連続的にたどっていく必要があるという。

　そのため、地形に対して一定間隔でレイキャストを打ち進めていくという方法で、プレイヤーが到達可能な地表面を調べることに。こうすることで洞窟などの立体交差のある地形であっても、プレイヤーが到達可能な地表面の点を一定間隔で網羅。生成した地表面の点群は、すでに一定間隔に並んでいるので、そのままボクセルの位置として扱うことができる。

　実際のコリジョンデータに対して適用してみると、一定間隔でプレイヤーが到達可能な地表面の座標だけを網羅できており、これらの座標をボクセルに置き換えることで、プレイヤーが到達可能な地表面のボクセルができあがった。

　こうして地形のボクセル構造は生成できることがわかったが、このデータは全世界の地形で必要になる。全世界の地形をボクセル化するということは、全世界の地形に対して大量のレイキャストを打つ必要があるということ。

　これには膨大な計算量が必要になる。ジオメトリ処理（三次元的に配置された座標を二次元平面上の座標に変換する処理）に強いTCCツール“Houdini”を使えば高速に計算できるのではと考え、具体的な実装に取り組むことにした。

　ゲーム内にはさまざまな種類のコリジョンがある。これらの読み取り情報やマテリアルの属性情報などを、すべてHoudiniにインポート。内製のレベルエディターからもそれらの配置データをインポートし、Houdini上でゲーム内と同等の地形コリジョンを作成した。

　Houdiniのレイキャスト計算は十分に高速だったので、これらの処理は毎晩全世界の地形に対して実行。日々変化する地形に対してボクセルを更新し続けることができた。生成したボクセルを格納するデータも用意する必要があったが、Houdiniには地形のマテリアル情報も取り込んでいたため、そのままHoudini上で計算ができたとのこと。

　Houdiniを多用することで、世界中の地形にデータを埋め込んで参照できるボクセル情報が制作できた。これにより、洞窟、空島、地底世界すべて同じ実装が行えるように。野外、洞窟の中、洞窟の天井、洞窟と野外の境目でも、周囲のボクセルを参照するだけという一貫した実装で、すべてのシチュエーションをシームレスに処理することが可能となった。

　洞窟だからといって特別なデータを参照せず、実装の違いによる挙動の不整合の心配も不要。バグも起こりにくくなり、仕様の制限もなくなった。このボクセル情報は、さまざまな場面で利用されるようなり、挙動の不整合の発生を防ぐことができたという。その利用事例も紹介された。

“おもしろくてバグがないゲーム”のため、開発者とテスターで情報・ツールの隔たりをなくす

　続いてQAエンジニアリングの大礒氏にバトンタッチ。

　QAエンジニアはバグがないゲームを目指していると思われるかもしれない。しかし、バグがないゲームを最終ゴールにしてしまうと、バグがなくなることがすべてと考えてしまいそうで、開発中に「この要素は絶対バグで苦労するから削ってほしい、といったよくない感情が生まれてしまいそう」だと大礒氏は語る。続けて、バグがたくさん生まれそうな要素にブレーキをかけていくと、「バグがないけど、おもしろい要素も削られてしまったゲームになる恐れがある」と強調。

　大礒氏は、本当に目指すべきものは何なのかと改めて初心にかえったとき、目指すものは“おもしろくてバグがないゲーム”だと思い至った。そのためには、バグの少なさだけに囚われず、おもしろさも大事にしなければならないと考えたそうだ。

　そこで、開発中のゲームはどのようにしておもしろくなっていくのかをまとめてみたという。ゲーム制作では制作と確認のサイクルが重要だ。おもしろそうな遊びのアイデアを試しに作ってテスト。これをくり返すとゲームはおもしろくなっていく。バグも同じだ。バグがないかを確認して、あれば原因を調べて直して再度確認。このくり返しでしだいにバグはなくなっていく。

　つまり、“おもしろくて、バグがないゲーム”は、上記のふたつのサイクルがたくさん回ることで成り立っている。それゆえ、このサイクルがたくさん回るように、制作と確認の工程を効率化しようと考えた。これを可能にするのが、デバッグ機能である。

　デバッグ機能は、デバッグと名が付いているが、バグの原因を調べるとき以外にも利用。開発者の試行錯誤やゲームプレイによる手応えの確認、おもしろさの磨き込みといった制作と確認の工程全般で使われている。

　デバック機能を充実させることは、バグの少なさだけにとらわれず、おもしろさも大事にできる取り組みともいえる。そのような便利な機能は、早くからあるのに越したことはないので、開発序盤から取り組むことにしたとのこと。

　開発に関わるメンバーが多いと、「このオブジェクトは誰が置いたのだろう？　相談したいことがあるんだけど……」と思っても、相談先を調べるのもひと苦労。デバッグ機能で配置情報を確認できれば、担当者がすぐにわかるほか、今作で追加されたものなのか前作から存在していたものなのか判別もする。

　　ほかにも、デバッグ機能で位置情報をコピーして開発Wikiやタスクに位置情報を貼り、指定した場所にかんたんにワープできる機能も実装された。これにより確認したい場所を探してさまようなどのムダな時間を削減し、そのぶんを企画について考える時間に充てられるが増えた。ワープボタンは何度も活用したそうだ。

　自分だけで完結する作業に活用できるデバッグ機能も存在。。たとえば『ティアキン』には、ゲーム内のオブジェクトをくっつけてものを作る遊び“ウルトラハンド”がある。タイヤがもうひとつほしくなったときにゲーム内でクリックすると、PCツールでそのオブジェクトが選択され、ボタンひとつでゲーム内に生成できるように。何でも生成できるので、試行錯誤がいっそうはかどるようになった。ほかにも、NPC一覧からそのNPCがいる場所にワープしたり、アイテム一覧から武器を入手できたりする機能も制作したという。

　デバッグ機能による効率化に十分な手応えを感じた大礒氏は、これらの機能をテスターにも活用してもらいたいと考えた。しかし、テスターがアクセスできる情報や利用できるツールは限られている。これでは十分な効果を発揮できないと考え、"開発者とテスターの隔たりをなくす"ことをQAエンジニアとしての新たなテーマとして掲げることにした。

　まずは、情報の隔たりをなくすため、開発者同士のコミュニケーションパスに、開発者と同じ権限で参加してもらうことに。開発日記からは、開発者が考えている遊びのアイデアなど、ゲームに関するさまざまな情報を得られる。

　チャットツールは、開発者同士と同じチャットにテスターを招待。タスク管理ツールも公開し、開発チームとして何ができていて、いま何の作業中で、今後どういうものを作ろうとしているのかもすべて共有された。さらに開発者同士のミーティングにも参加してもらうことに。ツールの格差をなくす取り組みも進め、バグを減らして、さらにおもしろさの磨き込みにもつながったそうだ。

床面積は前作の2.5倍、洞窟は200カ所以上。クオリティを維持して効率化を行うべく“洞窟システム”を実装

　続いて、竹原氏が登壇。前作ではストラクチャーデザインリードとしてゲーム内の建物全般の監修や制作を行い、今作では地形のアート全体を監修する地形リードを担当。竹原氏からは、規模の大きな『ティアキン』の地形をどのように効率化して作ったのかが語られた。

　まずは、製品のクオリティと効率化について。データを作る作業自体を効率化しつつ、ゲームの遊びに基づいたアート表現を想像して、それらがゲーム内で最終的にどう見えているのかをアーティスト自身が体験、確認することは、アーティストの責任としてなくしてはいけない大切な作業だと竹原氏は語る。

　一方で、そういった大切なことは手間がかかるもの。クオリティに直結した大事な手間はなくしてはいけないが、効率化のやりかたによっては製品のクオリティに悪い影響を与えてしまう。この大事な手間をなくさずに効率化することを竹原氏は目指したそうだ。

　『ティアキン』では、新しいゲーム体験をユーザーに届けるために、前作よりもゲームの仕様や物量が増加している。新たなゲーム体験を作るために必要だったが、床面積は前作の2.5倍となっており、この物流を作り切るのはかなり困難。クオリティコントロールも含めて多くの物量と向き合うための体制には、新たなツールや制作フローが必要だ。

　ここから『ティアキン』の追加要素の中で、効率化が顕著だった洞窟の制作について触れられた。洞窟はハイラルの世界に200ヵ所以上あり、そのひとつひとつにさまざまな遊びが付随している。データを作ってビルドに乗せ、最後にプレイすること。検討して、制作して、自ら体験する。体験がよくなかったら検討に戻る。こういったゲーム制作のサイクルをより多く回すことも、ゲームをおもしろくするために重要だ。

　このサイクルを多く回すべく、自動化できるものは自動化したいが、闇雲に進めてしまっては、ゲームにとって大事にものを失ってしまうかもしれない。そこで自動化せずに人の手で行うべき作業は何かを考えた。

　まずは遊びを作るためのレベルデザインの作業。ゲーム体験の核となる部分なので当然人の手で行う。つぎにレベルデザインに応じた素材や敵の拠点配置などのアセット配置作業。これに加えて、洞窟に関するアートの検討とコントロールが挙がった。

　また、ゲーム中の特定のアートは遊びに密接に関係し、遊び心地にも影響するので、それらを阻害しない見た目となるようにアーティストが検討をコントロールする必要がある。

　以上のことから、自動化できるのは遊びに関わらないアート部分のみとなった。これを踏まえて、洞窟のワークフローの最適解についてプログラマーと検討を繰り返した結果、“洞窟システム”が構築されることに。

　洞窟システムでは、手作業でレベルデザインされた地形に対して、レベルデザインに影響しない部分、遊びに関わらない装飾的な部分に、アーティストによってコントロールされた絵がプロシージャルなモデリングによって生成。洞窟だけでなく島状の形も生成可能で、レベルデザインから手作りまで幅広い作業をカバーできる。この洞窟システムの登場によって地形の制作フローが大きく変わったそうだ。

　以前のワークフローは、遊びの検討・実装（レベルデザイン）が終わると、絵の見当・実装（絵をつける手作業）が開始され、それが終わると製品になる。遊びと絵作りの作業は互いに強く影響して、遊びが決まらなければ絵作りができない状態。一度作業が絵作りまで進んでしまうと、遊びの変更が難しく、ゲーム制作のサイクルを回しづらかった。

　洞窟システムを導入した新しいワークフローでは、遊びの検討・実装と、絵の検討・実装時に、洞窟システムで試作した絵をもとに自動でディテールを付けるため、HoudiniでHADを作成。このふたつの作業を同時に進行し、それらをもとにプロシージャルのモデリングでディテールを付けて製品とする。

　遊びと絵作り、お互いの作業進捗の影響を受けず、ふたつの作業を並行して進められることで、目標としていたゲーム制作サイクルの回転数を上げることができた。これを皮切りに、洞窟システムはそのほかの地形制作でも使われ、費用対効果の高いツールとなったとのこと。

　これらを経て、地形制作のサイクルを多く回せたことで、洞窟の遊びに多様性が生まれ、結果としてゲーム体験が豊かに。プロシージャルなモデリングが行われたことで、アーティストが絵作りをコントロールしながら短期間に製品レベルの多種多様な絵作りが可能になり、当初の目的だった大事なものを残しながら効率化できたそうだ。

　アーティストの現場作業には、もうひとつ大事な作業がある。製品のクオリティを左右する、地形のデバッグ作業だ。前作よりも規模が大きくなったこともあり、前作では人海戦術で行っていた地形のデバッグを効率化したい。人の目視での確認作業はなくせないので、そこをどう効率化するのが課題となった。

　ハイラル全土には、お願いを聞いてあげると旅に役立つアイテムをくれるコログが1000体ほど存在。仕様や地形が変わるたびにコログのデバッグするのは厳しいので、洞窟システムを構築したときの自動化を思いつくが、それでも人による目視での確認は重要だ。

　そこで、確認コストが上がってしまう原因を調査。結果、コログたちのいる現地に向かうのに時間がかかるのが大きな問題として浮き上がってきた。慣れている場所でも見失ったり、見つけたと思ったら違うコログだったりと、苦労は絶えない。とにかく現地に行くための手順を減らすべく、わずらわしいと感じる動作を効率化することにした。

　そのために、ゲーム開発インフラチームが作り進めていた撮影機能を活かし、自動でコログのいる場所の撮影を行う“コログ自動撮影システム”の制作を依頼。画面の場所に一気に飛べるアクセスボタンも付いていて、日々のちょっとした確認はコログ自動撮影システムで撮影されたスクリーンショットで行い、最後はアクセスボタンで現地で確認。こうして、人による確認の作業をなくさずに効率化が図られた。

　プロジェクト終盤のデバッグ作業では、ハイラルの世界に配置したすべてのアセットが正しい状態か確認する作業“全数チェック”も必要だった。その数は、およそ16万。これらの確認を無秩序に進めては大惨事が起きてしまう。そこで、効率化の出番だ。

　ここで、それらを補助するツール“全数チェックツール”が誕生。PC内のツールとゲーム画面が連動し、ビルドでエリアを見ながら確認ができたので、ふだんからビルドを使って確認を行っているアーティストにとっても扱いやすいツールに。目視での確認という作業は残るが、このツールにより、二度手間になってしまうかもしれなかった確認作業が計画的かつ正確にチェックを行えるようになった。

　プレイヤーが地形の裏側に入れてしまうなど、ゲーム体験を壊してしまう地形コリジョンの穴がないか確認するのも大切。ただ、アセットの配置によって地形が構成されているので、意図せずに穴ができているものなどもあり、それらはとても発見しづらかった。さらに、地形の規模は前作の2.5倍なので、人海戦術で探すのにも限界がある。

　そこで穴探し用のツールを開発。穴探しツールは、プレイヤーが入り込んでしまうようなゲーム体験に支障をきたす大きくて危険な穴を、ゲーム体験に支障をきたさないレベルの小さな穴を大枠で判別が可能。使用者を選ぶツールでもあったので、費用対効果を考えてゲーム体験に支障のない穴は修正対象外に。これにより、地形コリジョンの大きな穴は穴探しツールによって撲滅された。

三者の取り組みでトーレルーフは意外とスムーズに実現

　ここまで、それぞれ進めてきた取り組みについて紹介されてきたが、それがトーレルーフの実装にどのようにつながったのか。それを解説する前に、大礒氏がトーレルーフが生まれた経緯を紹介。

　開発中に洞窟の遊びができたころ、テストプレイで積極的に洞窟を探索して手応えを確認したいが、奥まで歩いて探索すると引き返す道のりが面倒に感じた。洞窟を見つけても探索するのをためらうようになってしまい、期待していた遊びが実現できていなかったという。

　ここで再び登場するのがデバッグ機能だ。ふだんの制作では、デバッグ機能を使って自由に移動できていたため、洞窟の帰り道もデバッグ機能を使って自由に移動し、かんたんに脱出することができたらと考えた。そして、ゲーム内の遊びとして実装することに。

　そこで、エンバイロメントプログラマーの朝倉氏に実装の相談が。話が舞い込んできたときに朝倉氏がいちばんたいへんだと思ったのは、トーレルーフした後に、どこに出てくるかの判定処理だったそう。天井を貫通した先のプレイヤーが到達可能な床はどこにあるのか。そもそも存在するのか。これをどんな地形でも事前に判定できる必要があるからだ。

　ただ、プレイヤーが到達可能な床は聞いたことのある概念だったので、すぐにボクセル情報が使えると思ったという。ボクセルはプレイヤーが到達可能な地表面を網羅しているため、ルーフした後に出てくる到達可能な床の情報もすべて含まれていた。これにより、トーレルーフ後の出現ポイントという難問は、プレイヤーの上方向のボクセル情報を調べるだけで実現できそうだった。

　しかし、トーレルーフを利用するには、かなり高精度のボクセル情報が必要。地形に小さなコリジョンの穴があると、プレイヤーが通れないような軽微な隙間であっても、地表面を調べるためのレイキャストが中に入り込んでしまう。

　その結果、地形の裏側に残っていたコリジョン表面にまでボクセルが生成されてしまう。本来ならプレイヤーが到達できないはずの場所だ。このままトーレルーフを行うとゲームが破綻するため、ふだんはバグにつながらないようなコリジョンの小さな穴ですら、世界中から撲滅しなければトーレルーフは実現できない。

　穴を埋めるといえば、地形アーティストは穴探しツールを使って地形コリジョンの穴を埋めたという実績がある。地形アーティストは穴を埋めることができるが、トーレルーフで求められている埋めたい穴は、今作では直さないと判断したゲーム体験に支障がなかったはずの小さい穴。それらの穴を特定することも含めて、数千の数となると厳しい。

　この小さな穴を埋める人手が必要だ。人手と言えば、大礒氏が進めていた取り組みで、テスターとの隔たりを解消している。情報の隔たりがなくなり、テスターはゲームや仕様、地形コリジョンに詳しくなっていた。ツールの隔たりもなくなり、Houdiniを使ってテスターに穴探しを手伝ってもらえそうだ。

　穴を埋めるまでの工程は大きく3つ。ひとつめは穴を検出する工程。これは穴のだいたいの位置が検出できる穴探しツールで自動化されている。ふたつめは穴を探して報告する工程。Houdiniを見ながらゲーム内で現地に行き、穴の正確な位置や状況を調べる必要がある。この工程が意外とたいへんで、いちばん時間がかかるが、テスターの協力によって解決となった。

　最後はアーティストによる穴が開いているデータの修正。穴探しの報告工程によって、穴の正確な位置やワープボタン、スクリーンショットに、配置されているデータのファイル名など、修正に必要な情報がすべて添えられており、アーティストの修正はスムーズに進行。これにより、無事トーレルーフが実装されたのだった。

　本講演は、“トーレルーフの裏側で”というタイトルだったゆえ、「トーレルーフに関する直接的なストーリーを期待されていた方も多かったかもしれない」と大礒氏。しかし、トーレルーフの裏側には3人の取り組みがあった。

　エンバイロメントプログラマーは、洞窟や空世界のような立体的な遊びが成立するようにボクセル情報を用意して、一貫した地形情報へのアクセス方法を実現。

　QAエンジニアは、デバッグ機能を充実させ、テスターも開発者と同じような環境で作業できるように、開発者とテスターの隔たりを排除。

　地形アーティストは、自動化できるものは自動化し、手作業にこだわるものは効率化することで、地形制作全体の効率化を実施。

　これらが掛け合わさったことで、「トーレルーフは意外にスムーズに実現した」と大礒氏は振り返る。さらに、「3人とも特定のゲーム仕様に特化したアプローチではなく、汎用的で堅牢な仕組みやワークフローの改善を意識していたことも要因のひとつだったのでは」と分析した。