ゲーム開発者向けの技術交流会、「CEDEC2024」が、8月21日から23日にわたって開催された。今回お届けするのは、その中で行われた「『ゼルダの伝説 ティアーズ オブ ザ キングダム』におけるフィールド制作とQA〜トーレルーフの裏側で〜」という講演の内容だ。
『ゼルダの伝説 ティアーズ オブ ザ キングダム』と言えば、全世界で2000万本以上を売り上げたNintendo Swichのミリオンタイトルのひとつだ。前作『ブレス オブ ザ ワイルド』と同じく広大な世界を自由に冒険できるオープンワールドの作品であり、また今作では空や地下など、横方向だけではなく縦方向にもフィールドが広がったことで、さらに幅広い遊び方ができるようになった。
「トーレルーフ」とはその名前が示す通り、天井を突き抜けて屋上に抜け出る、主人公リンクが持つ能力のことだ。建物のような天井の薄い場所だけではなく、洞窟のような分厚い地形ですら貫通して上に抜け出ることができ、条件さえ満たせばどこでも使用可能と、本作の遊びの幅を大きく広げているシステムのひとつになっている。
実はこの「トーレルーフ」は、開発初期から実装が決まっていたものではなく、ある程度開発が進んできた後で生まれたアイデアだった。さらに言えば、一見いかにも実現が難しそうに思えるこの機能だが、意外にもかなりスムーズに実装されたのだという。その裏には、もともとは「トーレルーフ」とはまったく無関係に行われていた3つの取り組みがあった。
本講演では「トーレルーフ」誕生の裏話として、それら3つの取組みを、エンバイロメントプログラマー・朝倉淳氏、QAエンジニア・大礒琢磨氏、地形アーティスト・竹原学氏の3名からそれぞれ紹介。無関係だった取り組みが、どのように本作の面白さを代表する機能のひとつに結実したのかを解説していく。
※この記事はCEDEC事務局の方針を遵守し、9月2日以降の掲載としています。
世界全てを一様の方法で扱う「ボクセル情報」
ひとつ目の取り組みは、地形の「ボクセル情報」について。これについて語ったのは、エンバイロメントプログラマーを務めた朝倉淳氏だ。エンバイロメントプログラマーとは、ざっくりと説明すれば、生態系や植生、天候の管理などといった、ゲーム世界全体の挙動をターゲットにしたメカニクスを開発する仕事のことである。今回語られたのは、そうした仕事のうち、「地形の情報をどのように扱うか」という取り組みに関するものだ。
たとえば、本作には平原や溶岩、川や砂漠など様々な地形が登場するが、こうした地形の環境がきちんと納得感のあるものとなるためには、ゲーム内で様々な処理が必要になる。溶岩の近くでは野生の動物が湧き出してこないようにするとか、近くの地形に応じて異なる環境音が鳴るようにするといったことだ。
そのためには、周囲の地形のデータについて、各地点ごとに情報を格納しておく必要がある。前作『ブレス オブ ザ ワイルド』では、各地点ごとに「水辺までの距離」や「溶岩までの距離」といった情報が格納され、前述したような処理に活用されていたという。
ただし、前作の場合は地形は“ほぼ平面”とみなせるものだったため、そうした情報は2次元のテーブルデータさえあれば格納することができたのに対して、今作では空島や洞窟などが無数に存在しており、世界全体が縦方向へ立体的に拡張されている。そのため地上のフィールドと立体交差した地形に対して、2次元のテーブルデータでは地形情報を格納することができなくなってしまったという。
この場合、例えば洞窟などに対して専用のテーブルデータを追加するなど、地上とは異なるなんらかの専用実装を追加するという方法も考えられるが、そうした実装を増やせばバグや不整合の温床となりかねない。それを避けようとすれば、今度は複雑な洞窟を作らないようにするなど、仕様に対して制限を課す必要が出る場合もある。そのため、専用実装の追加は可能な限り避けたいところだった。
どうにか「地形に一様に情報を格納する」方法がないかと模索した朝倉氏が考えたのが、地形の表面を粗くボクセル化し、そのボクセルにデータを格納するという方法だった。これさえできれば、足元にあるボクセルのデータを参照するだけで、周囲の地形情報を読み取り、環境の挙動を実装できる。
方針が決まれば、今度はそれをどのように実行するかを考えなければならない。データを格納したい「地表の表面」というのは、言い換えれば「プレイヤーが到達可能な地表面」のこと。それを知るためには、地形に対して一定間隔でレイキャストを実施し、プレイヤーの移動をシミュレーションする必要がある。それも全世界の膨大な地形データに対してだ。
膨大な計算量が予測される作業だが、ジオメトリ処理に強いDCCツールであるHoudiniならば可能なのではないかと考えた朝倉氏は、その方向で検討を進めた。
地形データにはメッシュで作られたものや、球体・ボックスなどのプリミティブな地形、高さのテーブルデータとして作られたものなど、様々な種類のコリジョンが存在する。そうしたジオメトリ情報やマテリアルの属性情報、配置情報などをすべてHoudini内に取り込み、Houdini上でゲーム内と同等の地形コリジョンを再現、そのままHoudini内でレイキャストを実施して、「プレイヤーが到達可能な地表面」を洗い出すことに成功した。
Houdiniでのレイキャスト計算は十分に高速であり、開発の進行によって日々変化していく地形に対しても、定期的な全更新が可能であったという。
これによって、どんな場所であっても周囲のボクセルを参照するだけ、という一貫した実装ですべてのシチュエーションをシームレスに処理することが可能になった。専用実装を避けたことにより、挙動の不整合を心配する必要もなくなり、バグも起こりづらく、仕様に制限を課す必要性もなくなった。
さらに今回生まれたボクセルによる処理は、様々な副次効果も生んだ。例えば地形コリジョンに比べかなり粗いサイズのボクセルに対してならば、レイキャストの速度も10倍高速になる。この高速レイキャストによって周囲の地形を走査することで、音の残響や遮蔽、回折などの効果を実現することにも活用されたという。
ボクセル情報は世界全体を「一貫した実装」で扱うためのアクセス手段となったことから、当初の想定を超えて様々な場面で活用されることになり、挙動の不整合を防ぐ結果をもたらしたのである。
開発者とテスターの「隔たりをなくす」取り組み
ふたつ目の取り組みとして語られたのが、開発者とテスターの「隔たりをなくす」というものだ。話者は、本作でQAエンジニア【※】を担当した大礒琢磨氏だ。
※QAエンジニア：QAはQuality Assuranceの略。おもに品質保証を担当するエンジニアのこと。
QAエンジニアの仕事といえば、もちろん「バグがないゲーム」を目指すことだと思われるかもしれない。しかし、大礒氏によればそれでは不十分であり、なぜならバグをなくす、ということだけを至上命題にすれば、バグで苦労しそうな要素を削るような動きにも繋がりかねないからだ。
QAエンジニアが目指すべきものは「面白くてバグがないゲーム」であり、バグはないが面白い要素も削られてしまったゲームを作ってしまっては意味がない。そして実は「バグがないゲーム」も「面白いゲーム」も、作り方は変わらないのだという。必要なのは「制作」と「確認」の工程を繰り返すことだ。
ゲームの面白さを磨いていくには、まず面白そうな遊びを作り、次に実際に遊んで面白いかどうか確認する、というサイクルを繰り返していく必要がある。バグに関してもそれは同様で、バグがないかを確認し、あれば調べて直し、再び確認して……というサイクルを繰り返すことでバグを減らしていく。つまり「制作」と「確認」というサイクルを効率化し、可能な限り多く回すことが、「面白くてバグがないゲーム」を作ることに繋がる、というのが大礒氏の考えだ。
そこで大礒氏が取り組んだのが、いわゆる「デバッグ機能」と総称される機能を強化し、ゲーム開発の序盤から使えるようにしておくこと。本稿では、製品版では使用できないものの、開発中に活用できる便利な機能のことをまとめて「デバッグ機能」と呼んでいる。一例として、任意の場所に敵を呼び出したり、素早くマップを移動するような機能などだ。
そのような機能は「デバッグ」と名がついてはいるものの、実際にはバグを探すためだけではなく、ゲーム機能の面白さを確認するためなど、制作・確認の工程全般で使われる。まず大礒氏が取り組んだのが、そうした開発者向けのデバッグツールの強化だ。
一方で、開発者向けのデバッグツールを強化すればするほど、新たな問題も浮かび上がってきた。それが開発者とテスターとの「情報」と「ツール」の格差だ。というのも、開発チームが大量の情報やツールを抱えている一方で、それまでテスターはごく一部の情報・ツールにしかアクセスできなかったのだという。
そこで大礒氏が次に進めたのが、この「情報」と「ツール」の格差解消である。まず行ったのが、開発者同士のコミュニケーションパスに、テスターにも同権限で参加してもらうことだ。
開発wikiや開発者チャットに参加してもらうことでゲームに関する情報を集めやすくし、さらにタスク管理ツールを公開して現在進行中の作業や、これから行われる作業などについても共有した。また開発者ミーティングにも参加してもらい、開発の最新情報をリアルタイムで共有しつつ、開発者の意図なども伝わりやすくする取り組みまで行ったという。
情報だけでなく、それまでテスターに開放されていなかったツールに関する共有も進められた。共有に際しては単に権限上で扱えるようにするのではなく、正しく活用できるようにすることを目的とし、ハンズオン資料も作成したという。加えて、必要に応じて有償ライセンスのツールが共有できるような体制も整えた。バージョン管理ツールであるPerforceや、DCCツールであるHoudiniなどだ。
こうした広く情報共有を行ってツール活用の幅を広げる取り組みは、通常であれば発見が難しい発生条件の複雑なバグの発見につながったり、テスターから開発者への情報共有がスムーズになったことで、バグ修正のための作業も格段に効率的になるという成果を得たという。
さらに良い変化が生じたのはそれだけではなかった。情報共有によってテスターが開発者と共通の視座でゲームに向き合えるようになったことから、単なるバグ発見のためのデバッグを超えて、「目指している遊びが実現できているか」というデバッグも行えるようになったのだという。仕様上”バグ”ではないものも含め、ゲームの面白さに磨き込みをかけるための提案が上がってくるようにもなったのだ。
