講演レポート

『ゼルダの伝説ティアーズオブザキングダム』地上から地底、空へ拡張された広大なハイラル世界を“途切れなくシームレス”に移動させるための技術【CEDEC2024】

2024.09.04

CEDEC 注目記事ゲームの舞台裏講演レポート 3DCG CEDEC2024 Houdini プログラムレベルデザイン

この記事をシェア！

国内最大規模のゲーム業界カンファレンス「CEDEC2024」が、2024年8月21日（水）から8月23日（金）までの日程で開催されました。2日目となる8月22日には、任天堂の堂田卓宏氏、奥田貴洋氏、斎藤智久氏が登壇し、「『ゼルダの伝説　ティアーズオブザキングダム』の世界をつなぐ技術　～空、地上、地底、そして制作もシームレスに～」と題した講演が行われました。

2023年にリリースされた『ゼルダの伝説　ティアーズオブザキングダム』（以下、『ティアーズオブザキングダム』において、空、地上、地底と三次元に広がるフィールドはどのように作られ、そしてシームレスに冒険できるようになったか、実は二次元のフィールドであったという前作『ゼルダの伝説ブレスオブザワイルド』（以下、『ブレスオブザワイルド』）の制作時の技術的課題を振り返りながら解説がありました。また、ゲーム制作をシームレスにするためにどのようにワークフローや開発ツールを磨き上げたのかについても触れられました。

『ブレスオブザワイルド』は「二次元」だった

まずは、本作のテクニカルディレクターである堂田卓宏氏が登壇。『ティアーズオブザキングダム』での「シームレスな世界」を実現する上での技術課題を見ていく上で、まずは2017年にリリースされた前作『ブレスオブザワイルド』の世界を実現した技術について説明が行われました。

堂田卓宏氏（任天堂企画制作部）

入社以来、ゲームプログラミングやゲーム技術の開発、技術的な見地からのゲームのプロトタイピングに従事。本作『ティアーズオブザキングダム』および前作『ブレスオブザワイルド』ではテクニカルディレクターを務めた

『ブレスオブザワイルド』の技術で実現したこと、やらなかったこと

『ブレスオブザワイルド』の開発にあたり、「シームレスで広大な世界の表現と、自由度の高いゲームプレイ」の実現を目指すために、「技術の選定」が行われました。

例えば、広大な世界を描くには多くのポリゴンを扱う必要があるため、また時間や天候の変化を表現するにあたりスクリーンスペースのテクニックを用いたかったため、デファードレンダリングが採用されています。

また、自由度の高いアクションを実現するために、様々な状況でも破綻しにくい物理計算を行いたかったので既存の物理エンジンを採用し、かつ処理負荷が発生しても対応できるよう可変フレームレートが採用されました。

大人数での開発、大規模なデータを扱うためにワークフローやコミュニケーション、バージョン管理システムをどうするかということも技術の選定

このように、実現したいゲーム要素から逆算してひとつひとつの技術要素を選んでいく過程が「技術の選定」です。

『ブレスオブザワイルド』の世界を表現するための技術を決めていく過程で大きな問題になったのが、「広大な世界」と「シームレスな移動」です。従来の『ゼルダの伝説』でも「広大な世界」は描いていたものの、内部処理としてはステージ切り替えと同じような構造でした。

データをどういう粒度で持てばいいのか、ロードはいつ行えばいいのか、レベルをどう編集するのかなど、簡単には判断はできなかったそうです。そこで、設計のとっかかりを得るために世界の広さや特徴、遊びをどうするかなど、様々な検討が行われました。

前作開発初期の、世界の広さについてのブレストの様子。過去のゼルダシリーズの地図の広さを調べてみたり、現実世界で知っている場所を当てはめてみたりした

その後、各地域の特色をどうだすか、どこでどのような遊びを作っていこうかについてを検討

これらの検討を経て、開発陣が意識していたのは「平面としての広大さ」でした。そこで、『ブレスオブザワイルド』の世界を「二次元」で考えてみることにしました。

ゲーム要素やデータ構造を考えるのも「二次元」なら考えやすく、データの編集も既存のツールで対応できたとのことです。また、情報の可視化や管理の面でも二次元なら問題をシンプルにでき、メモリや処理効率の面でも有利です。

「シームレスな移動」という課題についても、「二次元」で考えることで処理をシンプルにすることができました。

もっとも荒いLoDデータとプレイヤー周辺の詳細なマップデータについてメモリを読み込ませ、その間の段階的なLoDデータはプレイヤーの移動に合わせてデータの読み替えを実行（詳細は後述の奥田氏のパートにて）

一方で、技術の選定は「できない事」も同時に生み出します。

前述の話でいうと、デファードレンダリングはフォワードレンダリングと異なり、マテリアル表現の多様性と柔軟性については苦手であり、『ブレスオブザワイルド』ではアーティストと相談して「できない事」としたそうです。

このように、技術の選定によって「何ができなくなるのか」というのは、エンジニアだけでなくチーム全体が理解していくことが重要になります。この理解というのは、チームの中で「やらないこと」のコンセンサスをとっていくことと同義になります。

『ティアーズオブザキングダム』の「三次元」への挑戦

「技術の選定」によってできない事について、「広大な世界」「シームレスな移動」の解決策として「二次元の移動に合わせてデータをロード」を選んだケースにあてはめると、「三次元の立体構造」ができない事になります。

つまり、『ブレスオブザワイルド』は「二次元」で考えられたゲームであったという事が言えると堂田氏は述べました。

プレイ面では崖を登る、パラセールで滑空するという三次元の要素はあったが、ゲームデザインや実装の面では例外を除くと二次元という縛りのもとで作られていた

ここで、話は本作『ティアーズオブザキングダム』に移ります。本作で真っ先に挑戦したかったのは、『ブレスオブザワイルド』の時にできなかったこと、つまり「二次元」から「三次元」の世界ということでした。

『ティアーズオブザキングダム』開発最初期の資料。地面、地底、空と、縦方向の世界の広がりから考え始めたことが分かる。なお、WiiUに対応の『ブレスオブザワイルド』からSwitch専用ソフトになったことで、ハードとしてもできなかったことを模索するという側面もあった

『ブレスオブザワイルド』で実現した「二次元」の処理を、いかに「三次元」に拡張するか。これが本作『ティアーズオブザキングダム』での技術課題であったということです。

シームレスに「三次元」のフィールドを表現するための「洞窟システム」

ここで『ティアーズオブザキングダム』にて、いかに「三次元」のフィールドを実現したか、斎藤氏から発表が行われました。

斎藤智久氏（任天堂企画制作部）

社内のグラフィックスライブラリやゲームシステムの開発に従事し、『ティアーズオブザキングダム』では『ブレスオブザワイルド』に引き続き地形のリードプログラムを担当

『ブレスオブザワイルド』のフィールドに関する技術の選定

まず、前作『ブレスオブザワイルド』のフィールドに関する技術について見ていきましょう。

『ブレスオブザワイルド』では先述のとおりデータ的にも「二次元」をベースに考えられています。また、広大な自然地形を想定していたので、ポリゴン予算をプログラムからコントロールしたいという狙いもありました。そこで、「静的な地形メッシュデータでの地面描画」ではなく、「ハイトマップを利用したプロシージャルな地面描画」という手法が採用されました。

「ハイトマップを利用したプロシージャルな地面描画」とは、高さ情報を持ったテクスチャに対して、格子状のメッシュを被せてレンダリングする手法です。

xzの座標に対して高さがひとつ定まるので、グリッドの各頂点を対応する高さにリアルタイムに持ち上げることで、地形の凹凸を表現することができます。

このようなプロシージャルなレンダリング手法では、静的なメッシュデータを描画するのとは違い、プログラムからポリゴン予算の調整が可能になります。

さらにプログラムから調整可能ということで、LoDも実現しています。

カメラから近いところはメッシュを細かく、遠いところは粗くレンダリングしている

一方でこの手法は、「三次元」の立体構造は実現できないというデメリットも持っています。

右画像のような地形は、左画像のように地面はハイトマップで作成、木や崖などはアーティストがDCCツールで作成した地形を組み合わせて実現させていた

本作『ティアーズオブザキングダム』で、地上だけでなく、空島、洞窟、地底といった「三次元」のマップを実現させるとなると、これまでの「二次元」の考えていた手法を考えなおす必要があったと斎藤氏は述べます。

本作に存在する大小様々な洞窟は、地面だけでなく壁や天井にもメッシュがある

シームレスな三次元の描画を実現する「洞窟システム」

「三次元」でLoDやデータストリーミングを可能としたうえでシームレスに描画するため、「洞窟システム」と呼ばれる、新しい地形システムを開発することになりました。

この「洞窟システム」は、メッシュベースのLoD + ストリーミングを実現するところから始まっています。

洞窟システムは、データを作る専用のエディターと、エディターで作られたデータをコンバート、コンバートしたデータを処理するゲーム側のコードから成り立っています。

洞窟システム専用エディターでは、大まかな形状の編集とスカルプトを用いた凹凸編集、ブラシによるマテリアルの編集などが可能になっている

本作用に作られた洞窟システムでは、三次元の地形に対してメッシュベースのLoDとデータストリーミングを実現させています。

洞窟システムでのメッシュベースのLoDについて、もともとあるメッシュから、複数のLoDレベルを生成した上で、LoD間では頂点のモーフィングを行うことで、シームレスにLoDの切り替えを繋いでいます。

モーフィングにあたり、LoDの詳細度の高いデータの頂点が、低いデータの頂点のどれに収束するかという情報が必要となります。しかしDCCツールなどでのポリゴンリダクションでは、LoD間の頂点の対応付けが手に入らないため、独自のポリゴンリダクションを実装することになりました。

独自実装したポリゴンリダクションは、Half-Edge Collapseというアルゴリズムを利用している。Half-Edgeは半辺・方向性を持った辺、 Collapseは潰す・崩壊するという意味で、半辺ごとに潰すかどうかを決定し、連鎖的に半辺を崩壊、頂点を潰していくというアルゴリズムである。どの半辺を潰すかは、半辺ごとにコスト＝「半辺をつぶした際の悪影響度合い」を計算し決定していく

本講演ではコスト計算の代表的なものとして2つ説明があった。そのひとつとして、「法線の差」が挙げられる。上の例では崩壊前（左）では斜めを向いている法線が崩壊後（右）では上を向くように変化している。下の例では崩壊前も崩壊後も上を向いている。この場合、下の例の方がコストが低いということになる。なお、実際は崩壊させる頂点に関連する全ての三角形の法線からコストを計算している

もうひとつの例として、崩壊した結果、ポリゴンが裏返るかどうかというのも挙げられた。図の上部の左から右のように半辺をつぶしていくと、緑色の面が一番右の例では赤色の辺のように逆向きになってしまっている。この判定は法線が少しでも逆向きなっているか、つまり法線の内積が負になっていないかで求められ、負になっていた場合はコストを最大まで引き上げる

このコスト計算が終わると、合算したコストが小さい半辺から伝播するように崩壊させる。狙ったポリゴン数になるまで崩壊させた結果、LoD 0のオレンジ色の頂点がLoD 1の緑色の頂点にモーフィングで遷移することになる。これにより、モーフィングによるLoD間での頂点の対応付けを作成することができた

頂点データは、「自分の頂点情報」のほかに「モーフィング遷移先の頂点情報」も保持をしている。ただし、LoD 0ならば1つ粗い解像度へのLoD 1の頂点情報のみ持つ。つまり、1つ粗い解像度へのみ遷移可能となっている

独自のポリゴンリダクションによるモーフィングに必要な頂点の対応付けが分かったところで、モーフィング時の頂点位置の変化について見てみましょう。モーフィングは「モーフィング補間率」というパラメーターに基づいて動かしています。

右端の緑色の点がオレンジの各頂点のモーフィング遷移先であるとして、補間率が0.0ならば、オレンジの頂点は本来の頂点位置である場所にそのまま留まる

補間率0.5ならば本来の位置と緑色の頂点の中間地点に移動。補間率1.0ならば緑色の点に移動してモーフィングが終了となる

ここで、使用するLoDのレベルとモーフィング補間率が決まれば、メッシュをレンダリングすることができそうです。洞窟システムではチャンクという八分木のデータ構造を利用して「使用するLoDのレベル」と「各頂点のモーフィング補間率」を決定しています。

チャンクは洞窟全体を包む三次元のバウンディングボックスをもとに、ポリゴンが存在する箇所に対してどんどん分割していくことで生成されます。

最少のチャンクは各辺32mの立方体

チャンクには、LoDに応じたポリゴンが所属しています。LoD 0のチャンクには最も細かいポリゴンが、LoD 1のチャンクにはひとつ粗いポリゴンが所属するという形です。

チャンクは、使用するLoDや読み込むデータの決定、ビューフラスタムカリング（カメラによる視錐台の外にあるものを描画しない手法）を行う基本単位です。データの読み込み判定はチャンクごとに行われるので、読み込まれているかどうかはチャンクごとに異なります。よって、隙間なく綺麗にモーフィングできるかはデータの読み込み状況が影響してきます。

チャンクが二次元・横一列になっている例で説明する。上画像のようにチャンクA～Cが横並びにあるときのチャンクBのモーフィング補間率を考えてみる。チャンクAはLoD 1、チャンクBとCはLoD 0と判定されていて、対応するLoDのデータについてABは読み込み済みだがCのデータは未読み込みの時の場合、チャンクCのLoD 1のデータが読み込まれたとしても、チャンクBは隙間ができてしまうためLoD 0でレンダリングできない。そのため、チャンクBとチャンクCの境界のモーフィング補間率は1.0として、チャンクBも粗い解像度の頂点を使うことになる

その後、チャンクCのLoD 0のデータが読み込まれると、チャンクBとチャンクCの境界のモーフィング補間率は0.0となり、チャンクBの右側では詳細なメッシュを使えることになる。
なお、実際のモーフィング補間率はカメラからの距離も影響するので、0.0のデータが使えたとしても0.3など異なる値になることもある

実際は、チャンクのバウンディングボックスの8つの頂点に対してモーフィング補間率を計算している。洞窟システムでのレンダリングでは、チャンクに所属する各頂点はチャンクのどの位置にいるのかを考慮して実際のモーフィング補間率を割り出す。このようにモーフィング補間率はチャンクの情報をもとに計算するので、モーフィング計算位置は必ずチャンク内に存在する必要がある

ポリゴンが2つ以上のチャンク間を跨ぐ場合は、どれか1つのチャンクに所属させた上で、チャンク外の頂点に対してはモーフィング補間率用の位置をチャンクの境界面に移動させる。このようにすることで、モーフィング計算をチャンク内に閉じ込めることを実現させている

データストリーミングもチャンクをベースに考えられています。ルートのチャンクから計算を始め、カメラから十分に近ければ詳細なチャンクに潜るというシンプルなアルゴリズムになっています。この時、詳細なチャンクのデータが読み込まれていなければ、ひとつ粗いチャンクのデータを表示させつつ、詳細なチャンクのデータの読み込みリクエストを送ります。

洞窟システムのファイル構造。一つの洞窟データファイルの下に複数のページファイルがある。ページファイルの中は各チャンクが使用するインデックスストリームが複数あり、頂点情報は同じファイル間のチャンクで共有できるようSSBO（Shader Storage Buffer Object ）の形で入っている。なおファイルサイズは断片化対策のため2MB固定。
洞窟データファイルにはどのチャンクがどのページに格納されているかの情報が入っている

これまで見てきた洞窟システムにより、メッシュベースのLoDとデータストリーミングが可能となりました。

例えば天井から垂れ下がる鍾乳石のメッシュについて、奥にあるものが手前に来ることでモーフィングして細かくなっていることが分かる

地底世界の制作フロー

このような形で実装した「洞窟システム」を使うことで、地上からシームレスに繋がる大きな空洞を地下に作ることができました。そこで、この空洞で遊びの検証を行っていくと、だんだんとさまざまな遊びについて膨らんでいきました。

暗闇を探索しながら進む遊び、ここでしかいないような強敵と戦う遊び、乗り物同士で戦う遊び

開発チームで様々な遊びについて検証している中で、独立した空洞よりもひとつながりの大きな空洞があった方がよいのでは、地底がひとつながりの地形になるならば地上と交換の関係があると発見と遊びのサイクルをより膨らませることができそうではないかという意見もでてきました。

そこで、俗に言う「裏世界」と呼ばれるフィールドになるよう、地上世界を裏返して地底世界を試作してみました。

地面の高さや地面のマテリアル、モデルの配置情報といった地上の情報に基づき、洞窟システムを利用して地上と裏表の関係性があるフィールドを作成

試作した地底世界でゲームプレイの試作や検証をしたところ手応えがあったので、この方向性で地底を制作していくことになりました。

地底の生成ルールは、地上に祠があれば地底にはチェックポイントがある、地上が盛り上がっていれば地底ではへこんでいる、地上に水があれば地底は壁があるというように、地上を転写する形でできています。

このようなルールベースによる生成だけでは思い通りのレベルデザインはできないため、「ブーリアン」と呼ばれるメッシュを配置した所は、地底の生成処理に介入できるようにしたそうです。

ブーリアンにより壁を空けたり地面の形状を変えたりという処理は、地底世界の数百か所で行われた

空島の制作にも洞窟システムが利用されています。洞窟と空島の違いは、ポリゴンの法線が内向きか外向きかでしかなかったので、空島に対応することは難しいことではなかったそうです。

空島でもLoDやデータストリーミングは洞窟の時と同じように動作する

このようにして、洞窟システムによって洞窟や地底世界、空島が試作され、本作の世界が形作られていきました。

「三次元」の世界をシームレスに移動できるようにするロード手法は

ここからは奥田氏が登壇。「こうして作られた世界を、いったいどうやってロードしようか」という言葉から講演を始めました。

奥田貴洋氏（任天堂企画制作部）

『ブレスオブザワイルド』の追加コンテンツからはプログラミングディレクターを務め、ゲームシステムやフレームワークを担当。さらにロードの実装も引き継ぐ。『ティアーズオブザキングダム』でもプログラミングディレクターを務めた

「二次元」世界データのロード

再び前作『ブレスオブザワイルド』の話に戻ります。木や崖などの3Dモデルの配置物について、『ブレスオブザワイルド』では「二次元」のグリッド上に登録しています。このグリッドは四分木として管理されていて、配置物はその大きさによって決められる表示距離に応じたグリッドに登録されています。

大きい建物は遠くから見えるので表示距離は長くなり、大きなサイズのグリッドに登録される。小さなタルは近くでのみ見えればいいので表示距離は短くなり、小さなサイズのグリッドに登録される

異なる大きさからなるグリッドの層にそれぞれの配置物が登録される。プレイヤーがある座標にいる時、プレイヤーの近くにあるグリッドを探し、そのグリッドに登録されている配置物をロードの対象とする

これを全てのグリッドの層に対して行うことで、その時表示させる全ての配置物を探すことができる

この方法をとることで「見えないほど遠くにあるものはロードしない」ということが実現できますが、「見えないほど遠くにあり見えなくてもいいけれど、コリジョンはないと困る」というケースがあります。そのため、表示とは別に地形メッシュコリジョンを持っており、配置物の表示距離に寄らずコリジョン抜けが発生しないことを担保しています。

大きくて表示距離が長い魔物に対して、小さくて表示距離が短い障害物がある場合、魔物を表示だけしてコリジョンがないと、障害物が表示された時に魔物がめり込んでしまう可能性がある

奥田氏が担当した『ブレスオブザワイルド』の追加コンテンツでは「一撃の大地」というものがあり、この追加コンテンツを遊ぶ間はゲームフィールドに新たな敵や地形が配置されます。しかしこの対応をするためにはそれ専用の処理を追加する必要があったといい、本作『ティアーズオブザキングダム』では配置物の読み込みをより柔軟に行えるよう、ロードシステムを作り直したそうです。

ゲーム中のフラグに応じて配置の入れ替えを柔軟に行えるようにする機能。ゲーム進行に応じて村の地形を大きく変えるということに使われている

大規模なダンジョンにシームレスに入れるようにするため、普段の世界とは独立した領域にロードしておける機構を本作では汎用的な処理として実装

ただ、ロードのアルゴリズム自体は前作の「二次元」ベースのロードをそのまま使っていたため、地底世界や空島といった「三次元」の世界をこのシステムでロードするのは新たな挑戦だったといいます。

地底世界への「三次元」移動のロードの検証

開発初期から地底世界と地上世界は十分に離れていることは決まっていました。これは、地底と地上を同時に見ることは無く、また地上から地底へは落下していけるけれど、地底から地上へは直接は容易に登ることはできないという事を意味しています。

これらを踏まえると、地上世界にいる時は地上世界のデータをロードし、地底世界にいる時は地底世界のデータに入れ替えるようにする方が、より深く広い地底世界を楽しんでもらえるのではないかということになりました。

そこで、地上にある穴から地底に向かって落ちていき、一定の深さに到達したときに、地上世界のデータをアンロードし、地底世界のデータをロードする実装を試すことになりました。

本作では「面白そうなことを試す」という制作フェーズと「実際に面白いか確認する」という確認フェーズ、そして確認した結果を踏まえさらに改良してくことで面白さを磨き込んでいくというサイクルを重要視していたそうです。

このサイクルを回すためには、「ゲーム中での役割を確認するための最低限の実装」が必要で、先の「地上のデータと地底のデータを入れ替える」というのは、このサイクルで必要な最低限の実装でした。

実装を試したところ、落下の途中でデータのロードのため動きが止まってしまいましたが、「地底世界は地上世界と地続きになった世界で、地上から直接向かう場所である」という役割は確認できたそうです。

講演中に再生された動画でもアンロード・ロードのため落下中に5秒程画面が止まっていた

地底世界への「三次元」移動のロードをシームレスにするために

ここで、製品としてリリースするためには、アンロードとロードを間に合わせる必要があります。そこで、以下の4点について取り組むことになりました。

プロファイラーによる可視化と処理の並べ替え

ロードすべきファイルの数を減らす

ロードすべきファイルのサイズを減らす

ロードの開始を早める

1.プロファイラーによる可視化と処理の並べ替え

まずはどこの処理で時間がかかっているのか状況の把握が大事です。そこでNintendo SDKが提供しているプロファイラーツールを用いてどこがボトルネックかを可視化し、処理が効率よく行えるよう並び替えを行う、あるいはデータ構造の見直しなどを行いました。

実際に穴から落ちた時のプロファイラー。これによると、地上から地底への切り替えの中で、地底の配置情報ファイルをロードするのに想定以上の時間がかかっていたことが分かった。

しかしファイルのロードの様子を見ると、切り替えの最初の方でデータをロードしていない時間があることも分かった

そこで、地底の配置情報ファイルを、「穴の近くにある配置物をロードするのに必要な部分」と「すぐには必要にならない遠くの部分」の2つに分け、前者をロードしていない隙間時間にロードし、後者のロードは後回しに。このことで、隙間時間にもロードを行うことができ、さらに配置情報ファイルの読み込みが短くなり、その後の処理にすぐに移れるようになった。その結果、切り替え時間全体として数秒短縮することができた

2.ロードすべきファイルの数を減らす

1.の結果、ファイルのロードが間に合わなくなりがちという事が分かりました。そこで、地底世界に移動するときにロードすべきファイルデータの総量を減らす必要があるということになりました。まずは、ファイルの数を減らすことを考えます。

配置物はその大きさに基づく表示距離によって読み込みが行われる。しかし、地底世界は凸凹で、崖の下にあるため着地時点ではプレイヤーから見えないデータも読み込みが行われていた

落下時にプレイヤーが到達しうる場所を調べ、地表面や空中に撮影点設定（画像のオレンジ色の点）、そこからカメラで見える配置物・見えない配置物を判定しデータとして出力。このデータを用いて、今いる所から見えない配置物はロードしないようにすることで、ロードする配置物を減らすことができた

3.ロードすべきファイルのサイズを減らす

さらに、ロードするファイルサイズを減らすことも有効であったといいます。

この箱のモデルのテクスチャは実際に画面に映る大きさと比較して解像度が少し高すぎる状態であった

テクスチャの適切な解像度を求めるため、このテクスチャが使われている場所を全てリストアップ。次に、これらがプレイ中どの位置から映るのかを求め、その和集合を求める。

その後、これらの位置からゲーム実機を使ってモデルを撮影してみて、使われるMipレベルを求める。高解像度のMipマップが使われる率が低すぎれば、実際に映る場面に対して高すぎる解像度になっていると言える

配置されている地形モデルに対して適切なテクスチャ解像度を求め、アーティストに確認して問題がない場合は、自動に解像度を下げるようにした

4.ロードの開始を早める

このように読み込むファイルの総容量を減らしていっても間に合わないケースがありました。そこで、ロードし始めるのを早める、つまり、地底世界に入る前から必要なデータをロードするようにしました。

開発実機と開発中のビルドを用いて、穴から落ちた時にロードされたファイルを調べるというプレイをCIツールで回し、実際にロードされたファイルをリストアップする

そしてプレイ中に、地底へ続く穴に近づいたときにリストアップしたファイルをメモリが許す限り読み込むようにする

これらの取り組みの結果、実機では地底世界へのシームレスな移動を実現することが可能となりました。

空世界の実装は「積極的放置作戦」から

一方で、空島のロードについての実装はどうだったのでしょうか。

試作中、空島が配置され始めた時は、地上から簡単にアクセスできそうな空島もあれば、大分高い位置に浮かんでいる空島もありました。また、地上からゴミゴミした感じで配置されたものもありました。

この時に奥田氏がゲームデザイナーと配置に関して話をしたものの、空島に関して決まっていることは多くはなく、試行錯誤の段階であるということでした。

そこで、空島に関するデータロードについては、実装できたとしても敢えて実装をしないという、積極的放置作戦をとることにしました。これは、ここで実装を進めてしまうと、かえって空島の配置に制約を課すことになりかねないからです。

空島のデータを作るための実装をすると、空島のデータ上の単位を決めることになる。空島のロードに関する実装を行うと、空島のロードの条件を決めることになる。実装後に、巨大な空島や他のものと重なっている空島を作ることになると、先に決めた条件が制約を課してしまう可能性がある

何かひとつを実装するということは、何かをひとつ決めるという事だと奥田氏は言います。

試行錯誤のタイミングにおいて敢えて空島専用のロードの実装をしないことで、制約なく空島の配置が試せ、「空島にいらない事」「空島の配置に本当に必要なもの」を絞り込んでいくことができたそうです。

専用の実装をしなかったので少々の処理落ちやバグはあったが、「役割の確認」に支障がなければ許容した

このような積極的放置作戦のもと試行錯誤を行った結果、いくつかの空島は存在や配置場所が整理され、また空島の役割も見えてきました。

また、地上から直接歩いてアクセスする空島はごくわずかで、だいたいはプレイヤーを打ち上げる施設を使ってアクセスするか、別の空島からアクセスする想定になったそうです。

このような条件であれば、プレイヤーが地上にいるときは空島のことはほぼ無視できそうです。

そこで奥田氏は、世界に点在する空島を、「メインルートのために存在する大きな空島」と「小さな空島」に分類。そして、大きな空島はひとつだけ、小さな空島は複数ロードしてメモリに置けるようにしました。配置しなかった空島は、配置情報から事前に生成したLODのローモデルを表示しています。

このように、空島の役割を分類することでデータのロードの仕方が単純化できました。

小さな空島を複数ロードしたのは、互いに行き来できる空島や、領域がオーバーラップしている空島のため

広大な世界の制作もシームレスにしたツールワークフロー

ここでゲーム中の話だけではなく、ゲーム制作における「シームレス」についても話が及びました。

これまで見てきたようなシームレスにロードするための「技術」を作っていく中で、役割を確認するための最低限の実装、積極的放置作戦など、開発チームの中で制作と確認のサイクルを回す「運用」についても講演の中では触れられてきました。こういった、制作から確認までをスムーズに進める事を、「制作をシームレスにする」と開発チームでは呼んでいると奥田氏から紹介がありました。

この「制作をシームレスにする」取り組みは、制作の進め方を工夫するだけでなく、ツールワークフローにおいて制作サイクルそのものを改善することも含まれます。

斎藤氏からは、制作サイクルの改善のために、「編集から開発実機に反映されるための待ち時間を限りなく0にする」「レベルデザインの制作と並行してアートの制作も可能な開発環境」といった2点の取り組みについて解説がありました。

「編集から開発実機に反映されるための待ち時間を限りなく0にする」とは、イテレーションサイクルを可能な限り素早く回すということです。

「洞窟システム」のワークフローは先述の通り、エディターでデータを編集して、出来上がったデータをコンバート、そのデータをゲーム内で確認するといったものです。

ここでコンバートの手間が省ければスムーズになるということで、PC上のエディターで編集した地形が開発実機ですぐに確認できる、「リアルタイムエディット」の機能が開発されました。

データストリーミングの仕組みを利用して、エディター側から逐次変更箇所のデータを変換して送ることで「洞窟システム」の「リアルタイムエディット」機能は実現されている

レベルの変更にアートが追随する「プロシージャルデコレーション」

「レベルデザインの制作と並行してアートの制作も可能な開発環境」は、複数人の作業にまたがる課題です。

通常はレベルデザイナーによって遊びが決定したのち、アーティストがアートを磨き上げていく流れですが、レベルデザインに変更が入ると、磨き上げたアートのデータにも変更が入り、完成が遠のいてしまいます。

これは、アートのデータの磨き上げが進んでいるとレベルデザインが変えにくくなっていくとも言えます。しかしながら、本来必要な遊びの変更が入れられないと、ゲームの質も上がっていきません。

ここで、アートのデータを磨き上げる＝細部まで意匠を作り込むという作業の労力が減れば、ゲームデザインの変更に強いという制作環境と言えます。

そこで「洞窟システム」では、アーティストによるブラッシュアップ作業とレベルデザインの変更作業が両立するワークフローを目指したといいます。

その結果、「プロシージャルデコレーション」と呼ばれる、レベルデザインを変更してもアートが追随してくれる編集環境を用意することになりました。

イテレーションを素早く回すための「リアルタイムエディット」

プロシージャルデコレーション適用の例。適用前（左画像）と適用後（右画像）とで天井や壁など大きく形状が変わっているように見えるが、メインの導線がある地面はレベルデザインの意図を壊さないよう形状が保たれている

プロシージャルデコレーションは、エディターで生成したデータをコンバートする時にHoudiniの処理を入れることで実現している。Houdiniではメッシュやマテリアルの加工、配置情報を利用した変形などが可能である

プロシージャルデコレーションを利用することで、洞窟の入口などアーティストがこだわりたいかつレベルデザインに影響する部分はアーティストが作り込み、レベルデザインに影響しない部分はざっくりとした形を作ったらブラッシュアップはプロシージャル処理に任せる、というフローが実現しています。このことで、細かい磨き上げの作業が減り、より手触りが必要な部分に注力することができたと斎藤氏は言います。

「洞窟システム」ではメッシュベースのLoDによりメッシュ解像度を自動的に最適化されるので、プロシージャルデコレーションで細部まで作り込まれてもポリゴン予算を気にしないでよいという、相性の良さも見られた

もともとHoudiniを通じての実装作業は、アーティストがエンジニアに依頼してやっていた。ここでアーティストが試行錯誤したいということで、エンジニアが骨組みを用意してアーティストが細部を詰めるという、お互いの得意分野を活かしたワークフローになっていった。この、自然と最適な役割分担ができていったということも「制作をシームレスにする」取り組みと言えると思うと斎藤氏は述べた