アイデアの発端はデバッグツール。正攻法で堅牢なシステム作りを目指したフィールド制作の裏側に迫る【CEDEC2024】

ゲーム開発者向けの技術交流会、「CEDEC2024」が、8月21日から23日にわたって開催された。今回お届けするのは、その中で行われた「『ゼルダの伝説 ティアーズ オブ ザ キングダム』におけるフィールド制作とQA～トーレルーフの裏側で～」という講演の内容だ。 【この記事に関連するほかの画像を見る】 『ゼルダの伝説 ティアーズ オブ ザ キングダム』と言えば、全世界で2000万本以上を売り上げたNintendo Swichのミリオンタイトルのひとつだ。前作『ブレス オブ ザ ワイルド』と同じく広大な世界を自由に冒険できるオープンワールドの作品であり、また今作では空や地下など、横方向だけではなく縦方向にもフィールドが広がったことで、さらに幅広い遊び方ができるようになった。 「トーレルーフ」とはその名前が示す通り、天井を突き抜けて屋上に抜け出る、主人公リンクが持つ能力のことだ。建物のような天井の薄い場所だけではなく、洞窟のような分厚い地形ですら貫通して上に抜け出ることができ、条件さえ満たせばどこでも使用可能と、本作の遊びの幅を大きく広げているシステムのひとつになっている。 実はこの「トーレルーフ」は、開発初期から実装が決まっていたものではなく、ある程度開発が進んできた後で生まれたアイデアだった。さらに言えば、一見いかにも実現が難しそうに思えるこの機能だが、意外にもかなりスムーズに実装されたのだという。その裏には、もともとは「トーレルーフ」とはまったく無関係に行われていた3つの取り組みがあった。 本講演では「トーレルーフ」誕生の裏話として、それら3つの取組みを、エンバイロメントプログラマー・朝倉淳氏、QAエンジニア・大礒琢磨氏、地形アーティスト・竹原学氏の3名からそれぞれ紹介。無関係だった取り組みが、どのように本作の面白さを代表する機能のひとつに結実したのかを解説していく。 文・取材／恵那 編集／久田晴 ■世界全てを一様の方法で扱う「ボクセル情報」 ひとつ目の取り組みは、地形の「ボクセル情報」について。これについて語ったのは、エンバイロメントプログラマーを務めた朝倉淳氏だ。エンバイロメントプログラマーとは、ざっくりと説明すれば、生態系や植生、天候の管理などといった、ゲーム世界全体の挙動をターゲットにしたメカニクスを開発する仕事のことである。今回語られたのは、そうした仕事のうち、「地形の情報をどのように扱うか」という取り組みに関するものだ。 たとえば、本作には平原や溶岩、川や砂漠など様々な地形が登場するが、こうした地形の環境がきちんと納得感のあるものとなるためには、ゲーム内で様々な処理が必要になる。溶岩の近くでは野生の動物が湧き出してこないようにするとか、近くの地形に応じて異なる環境音が鳴るようにするといったことだ。 そのためには、周囲の地形のデータについて、各地点ごとに情報を格納しておく必要がある。前作『ブレス オブ ザ ワイルド』では、各地点ごとに「水辺までの距離」や「溶岩までの距離」といった情報が格納され、前述したような処理に活用されていたという。 ただし、前作の場合は地形は“ほぼ平面”とみなせるものだったため、そうした情報は2次元のテーブルデータさえあれば格納することができたのに対して、今作では空島や洞窟などが無数に存在しており、世界全体が縦方向へ立体的に拡張されている。そのため地上のフィールドと立体交差した地形に対して、2次元のテーブルデータでは地形情報を格納することができなくなってしまったという。 この場合、例えば洞窟などに対して専用のテーブルデータを追加するなど、地上とは異なるなんらかの専用実装を追加するという方法も考えられるが、そうした実装を増やせばバグや不整合の温床となりかねない。それを避けようとすれば、今度は複雑な洞窟を作らないようにするなど、仕様に対して制限を課す必要が出る場合もある。そのため、専用実装の追加は可能な限り避けたいところだった。 どうにか「地形に一様に情報を格納する」方法がないかと模索した朝倉氏が考えたのが、地形の表面を粗くボクセル化し、そのボクセルにデータを格納するという方法だった。これさえできれば、足元にあるボクセルのデータを参照するだけで、周囲の地形情報を読み取り、環境の挙動を実装できる。 方針が決まれば、今度はそれをどのように実行するかを考えなければならない。データを格納したい「地表の表面」というのは、言い換えれば「プレイヤーが到達可能な地表面」のこと。それを知るためには、地形に対して一定間隔でレイキャストを実施し、プレイヤーの移動をシミュレーションする必要がある。それも全世界の膨大な地形データに対してだ。 膨大な計算量が予測される作業だが、ジオメトリ処理に強いDCCツールであるHoudiniならば可能なのではないかと考えた朝倉氏は、その方向で検討を進めた。 地形データにはメッシュで作られたものや、球体・ボックスなどのプリミティブな地形、高さのテーブルデータとして作られたものなど、様々な種類のコリジョンが存在する。そうしたジオメトリ情報やマテリアルの属性情報、配置情報などをすべてHoudini内に取り込み、Houdini上でゲーム内と同等の地形コリジョンを再現、そのままHoudini内でレイキャストを実施して、「プレイヤーが到達可能な地表面」を洗い出すことに成功した。 Houdiniでのレイキャスト計算は十分に高速であり、開発の進行によって日々変化していく地形に対しても、定期的な全更新が可能であったという。 これによって、どんな場所であっても周囲のボクセルを参照するだけ、という一貫した実装ですべてのシチュエーションをシームレスに処理することが可能になった。専用実装を避けたことにより、挙動の不整合を心配する必要もなくなり、バグも起こりづらく、仕様に制限を課す必要性もなくなった。 さらに今回生まれたボクセルによる処理は、様々な副次効果も生んだ。例えば地形コリジョンに比べかなり粗いサイズのボクセルに対してならば、レイキャストの速度も10倍高速になる。この高速レイキャストによって周囲の地形を走査することで、音の残響や遮蔽、回折などの効果を実現することにも活用されたという。 ボクセル情報は世界全体を「一貫した実装」で扱うためのアクセス手段となったことから、当初の想定を超えて様々な場面で活用されることになり、挙動の不整合を防ぐ結果をもたらしたのである。 ■開発者とテスターの「隔たりをなくす」取り組み ふたつ目の取り組みとして語られたのが、開発者とテスターの「隔たりをなくす」というものだ。話者は、本作でQAエンジニア【※】を担当した大礒琢磨氏だ。 QAエンジニアの仕事といえば、もちろん「バグがないゲーム」を目指すことだと思われるかもしれない。しかし、大礒氏によればそれでは不十分であり、なぜならバグをなくす、ということだけを至上命題にすれば、バグで苦労しそうな要素を削るような動きにも繋がりかねないからだ。 QAエンジニアが目指すべきものは「面白くてバグがないゲーム」であり、バグはないが面白い要素も削られてしまったゲームを作ってしまっては意味がない。そして実は「バグがないゲーム」も「面白いゲーム」も、作り方は変わらないのだという。必要なのは「制作」と「確認」の工程を繰り返すことだ。 ゲームの面白さを磨いていくには、まず面白そうな遊びを作り、次に実際に遊んで面白いかどうか確認する、というサイクルを繰り返していく必要がある。バグに関してもそれは同様で、バグがないかを確認し、あれば調べて直し、再び確認して……というサイクルを繰り返すことでバグを減らしていく。つまり「制作」と「確認」というサイクルを効率化し、可能な限り多く回すことが、「面白くてバグがないゲーム」を作ることに繋がる、というのが大礒氏の考えだ。 そこで大礒氏が取り組んだのが、いわゆる「デバッグ機能」と総称される機能を強化し、ゲーム開発の序盤から使えるようにしておくこと。本稿では、製品版では使用できないものの、開発中に活用できる便利な機能のことをまとめて「デバッグ機能」と呼んでいる。一例として、任意の場所に敵を呼び出したり、素早くマップを移動するような機能などだ。 そのような機能は「デバッグ」と名がついてはいるものの、実際にはバグを探すためだけではなく、ゲーム機能の面白さを確認するためなど、制作・確認の工程全般で使われる。まず大礒氏が取り組んだのが、そうした開発者向けのデバッグツールの強化だ。 一方で、開発者向けのデバッグツールを強化すればするほど、新たな問題も浮かび上がってきた。それが開発者とテスターとの「情報」と「ツール」の格差だ。というのも、開発チームが大量の情報やツールを抱えている一方で、それまでテスターはごく一部の情報・ツールにしかアクセスできなかったのだという。 そこで大礒氏が次に進めたのが、この「情報」と「ツール」の格差解消である。まず行ったのが、開発者同士のコミュニケーションパスに、テスターにも同権限で参加してもらうことだ。 開発wikiや開発者チャットに参加してもらうことでゲームに関する情報を集めやすくし、さらにタスク管理ツールを公開して現在進行中の作業や、これから行われる作業などについても共有した。また開発者ミーティングにも参加してもらい、開発の最新情報をリアルタイムで共有しつつ、開発者の意図なども伝わりやすくする取り組みまで行ったという。 情報だけでなく、それまでテスターに開放されていなかったツールに関する共有も進められた。共有に際しては単に権限上で扱えるようにするのではなく、正しく活用できるようにすることを目的とし、ハンズオン資料も作成したという。加えて、必要に応じて有償ライセンスのツールが共有できるような体制も整えた。バージョン管理ツールであるPerforceや、DCCツールであるHoudiniなどだ。 こうした広く情報共有を行ってツール活用の幅を広げる取り組みは、通常であれば発見が難しい発生条件の複雑なバグの発見につながったり、テスターから開発者への情報共有がスムーズになったことで、バグ修正のための作業も格段に効率的になるという成果を得たという。 さらに良い変化が生じたのはそれだけではなかった。情報共有によってテスターが開発者と共通の視座でゲームに向き合えるようになったことから、単なるバグ発見のためのデバッグを超えて、「目指している遊びが実現できているか」というデバッグも行えるようになったのだという。仕様上”バグ”ではないものも含め、ゲームの面白さに磨き込みをかけるための提案が上がってくるようにもなったのだ。 ■大切なクオリティを守りつつ挑んだ「制作の効率化」 3つ目の取り組みとして語られたのが、本作の地形に関する「制作の効率化」について。演壇に登ったのは、今作で地形全般の監修を行う地形リードアーティストを務めた竹原学氏だ。竹原氏が挑んだのは、前作を上回る規模のフィールドを持つことになった『ティアーズ オブ ザ キングダム』において、制作をどのように効率化するか、という問題だった。 というのも、今作では空島や地底などのエリアが増えたこともあり、前作『ブレス オブ ザ ワイルド』に比べて床面積が2.5倍となっているなど、単純な物量だけ考えても制作にはかなりの困難が予想されていた。人手はそう簡単に増やせず、増やせたとしても、今度は多くのスタッフを取りまとめてクオリティをコントロールすることが難しくなる。 アート表現はゲーム体験を大きく左右し、クオリティにも直結する非常に大切なものだ。一方で、そうした大切なことは人の手で行わなければならないものも多く、どうしても手間がかかってしまう。効率化できるに越したことはないが、間違ったやり方をすればゲーム体験を損なうものになりかねない。 そこで竹原氏が向き合ったのが、絶対に人の手が必要な「大切なこと」をしっかり切り分けた上で、それ以外の部分を自動化させて、全体の作業を効率化させることだった。 その代表例として紹介されたのが、地形制作の効率化において顕著な成果をだすことができたという「洞窟」の制作だ。その中で生み出されたのが、プロシージャルモデリングによってアーティストの制作した絵が洞窟内に自動生成されていくという「洞窟システム」と呼ばれるものだ。 ゲーム内世界に200箇所以上存在する洞窟は、本作における遊びの重要なウェイトを占める新要素だ。各洞窟にはそれぞれ独自の遊びの要素があり、その遊びを作るためのレベルデザイン作業、レベルデザイン作業に応じたアセットの配置作業、そして洞窟に関するアートの検討とコントロールといった作業を通して、ひとつひとつの洞窟が生み出されていく。 しかしながら「洞窟システム」が生まれる以前のフローでは、どのような遊びが発生するのかを検討・実装するレベルデザインの作業が終了するまで、その場所にどのようなアートを配置するのかを定める作業が進められず、さらに言えば一度アートデザインが定まってしまえば、後から遊びの内容を調整することも難しい、という問題が存在していた。 このような状態を改善したのが前述した「洞窟システム」で、制作フローの一部を自動化したことで、洞窟にどのような遊びが実装されるのかが決定される前から、アートの検討を独立して進められるようになった。これは「検討・制作・体験」といったゲームをブラッシュアップしていくためのサイクルをより効率的に回すことにも繋がり、結果として洞窟という要素に多様な遊び方をもたらす要因にもなったという。 このように、クオリティを維持するために絶対に人の手を外すことができない作業はしっかり残しつつ、それ以外の箇所については自動化していくことで、本作の地形開発は進められていった。 同様に進められたのが、地形デバッグの作業に関してだ。人による目視での確認作業、という点はクオリティ維持のためにどうしても外すことのできないが、それ以外の部分は徹底して自動化し、人の手が必要な作業がスムーズに進行するようなツールや体制づくりが進められたのだ。 例えば、確認のためにわざわざゲーム内で現地に移動するのに時間がかかるのであれば、実際に移動しなくてもチェックができるようなシステムを組んだり、「地形コリジョンの穴」を埋める作業であれば、広大なフィールドから人海戦術でそうした穴を見つけるのではなく、穴のありそうなおおよその位置を調べる「穴探しツール」を導入した。 人の手が必要な作業自体はしっかり残しつつも、可能な限り少ない労力でチェックができる体制が推し進められていったのだ。 こうした様々な問題がスムーズに解決に進んだ背景として、チーム内に情報の透明性があったことが重要だったと、竹原氏は語る。それによって必要な情報、技能を持ったメンバー同士が、互いに協力しやすい環境にあったというのだ。 クオリティに直結する「大切なこと」を行うためには手間がかかる。その手間を省くのではなく、そのために必要な手間をいかに減らすか、ということを考え、実行するのが、面白いゲームを作るための効率化なのだという。 ■「トーレルーフ」の裏側にあったもの ここまでの内容を踏まえたうえで、いよいよ本講演のメインテーマである「トーレルーフ」の誕生の話になる。冒頭で述べた通り、「トーレルーフ」という機能は、制作初期の段階では予定されていたものではなかった。 初めてそのアイデアが生まれたのは、洞窟の遊びができてきた頃に行われたテストプレイの中だったという。洞窟を奥まで探索した後に、入口まで引き返す道がかなり面倒に感じてしまったというのだ。そうなると、プレイヤーは洞窟を見つけても探索をためらうようになってしまい、期待した方法で遊んでもらえない。 ここで目をつけられたのが、デバッグツールだ。デバッグツールには壁なども貫通して3次元空間を自由に移動できるという機能も用意されており、洞窟からも簡単に脱出することができたからだ。これをそのままゲーム内でも実際に遊べるようにすれば、洞窟の帰り道の問題は解消される。 そうして始まった「トーレルーフ」実装への道のりだが、最も困難が予想されたのは「トーレルーフ」した後に「どこに出るのか？」という判定処理の問題だった。天井を貫通した先のプレイヤーが到達可能な床はどこにあるのかという情報が、どんな地形でも事前に判定できる必要があるからだ。 ここで登場するのが「ボクセル情報」だ。ボクセル情報はそもそもがプレイヤーが到達可能な地表面を網羅しているので、「トーレルーフ」した後の「プレイヤーが到達可能な床」の情報もすべて含まれている。そのため、「トーレルーフ」した天井から上方向のボクセル情報を調べるだけという、非常に簡単な実装で実現できそうだった。 しかし、この方法にも弱点はある。ボクセル情報に高い精度が必要になることだ。地形にコリジョンの穴などがあった場合、それがプレイヤーが通れないほど小さなものであったとしても、地形レイキャストが入り込んで、地形の裏側にもボクセル情報が生成されてしまうからだ。そうすると、「トーレルーフ」した際にゲームが破綻してしまう。 ここで思い出したいのが、地形制作の効率化の際に、「穴探しツール」を使って穴の大まかな位置を自動で割り出せるようにしていたことだ。つまり、そのツールを使用した作業の延長上で、穴を埋めることは可能なのだ。 ただし「トーレルーフ」が使えるようにするには、本来であれば無視しても良かった程度の軽微なコリジョンの穴まで、すべてを埋める必要がある。そうすると数千もの作業が必要になるうえ、ツールを正しく使うには、地形コリジョンの知識やHoudiniの技能が必要になる。 こうした条件を備えた人手を増やすのは、当然ながら難しい問題だ。本来であれば。 そう、QAエンジニアが行っていた取り組みによって、多くのテスターに知識やツールが行き渡っていたのだ。テスターはゲームの地形コリジョンについての知識を得ており、またHoudini提供のための土台もできた状態だったのである。 これによって人手の問題も解消され、穴探しツールによって大まかに判明した穴の正確な位置や原因をテスターが確認・報告し、それを地形アーティストが修復するという工程が全て可能になった。世界の穴は、ついに塞がったのだ。 以上が、「トーレルーフ」が誕生するまでの物語だ。まったく無関係に進められていた3つの取組みが組み合わさることで、「トーレルーフ」はスムーズに実現することになったことがお分かりいただけただろうか。 いずれの取り組みも特定のアプローチに特化したものではなく、汎用的で堅牢な仕組みやワークフローの改善を目指していたことも、これらがうまく噛み合ったひとつの要因だったと考えられる。 『ティアーズ オブ ザ キングダム』の開発において、ここで紹介した事例のような別々の取り組みが成果に繋がるという事例はいくつもあったのだという。「トーレルーフ」の裏側にあったのは、チーム内の情報の透明性や、それによって形成されていった制作文化が生んだ、当初意図されていなかった数々の連携だったのである。