じつは2次元だった前作から3次元への拡張
そのためにはまず、実現目標に向けての“技術の選定”から開発がスタートした。一例としては、広大な世界を表現するために大量のポリゴンを用意する必要があるため、ディープなパスが必要となりがちな“フォワードレンダリング”ではなく、一度のGバッファ(深度情報や法線情報などの値)の描画で済む“デファードレンダリング”を採用した。
過去の『ゼルダの伝説』シリーズ作品でも広大な世界は描かれていたが、内部的にはステージ切り換え型のゲームと同じ構造になっていた。そのため、改めてシームレスで広大なフィールドを表現するための試行錯誤が始まった。
その初期には過去のシリーズ作品の床面積や、現実世界の地域を当てはめたりすることで、世界の広さを決定。そこに地域色をどうするか仮置きするなど、どのような“遊び”を作っていくかを検討していった
Wii Uのハード的な制約や、シームレスな移動に関しても、2次元の構造は有利に働く。LOD(※)の設定やロードについても、2次元的な主人公の動きに合わせて行うことができた。
2次元の仕組みを作った『ブレワイ』において、それは当然“3次元の立体構造”だった。ゲーム内では壁登りや滑空、ちょっとした空のフィールドや洞窟など、3D要素をふんだんに使っている。それでも大局的に見ると、2次元の縛りで作られたゲームだったのだ。
世界描写を3次元へ拡張した“洞窟システム”
高さ情報を持つハイトマップに、格子状のメッシュ(頂点、辺、面などのデータをともなってオブジェクトの表面部を形成するポリゴン集合体)を被せることでレンダリングを実施。これでグリッドの各頂点を対応する高さをリアルタイムに持ち上げて、地形の凹凸を表現できる。プログラム側から動的にポリゴン数を調整できるというメリットもある
だが、ハイトマップを用いた手法では3次元の立体構造を表現することは難しい。『ブレワイ』では立体構造が欲しい場面で、アーティストがメッシュデータで作成した3Dモデルを別途配置していた。
まず、“洞窟”には壁や天井にもメッシュがある。これらをシームレスに描画するため、新たにメッシュベースの地形システム、通称“洞窟システム”を開発することになる。メッシュが持つ頂点データをLODに合わせてモーフィングするわけだが、LOD間で頂点どうしのモーフィングを行うには、LOD間での頂点の対応付けが必要になる。
セッションの中でポリゴンリダクションは Half-Edge Collapse というアルゴリズムで実装していると説明があった。
つまり、地上で何かを発見すると同じ地点の地底でも何かが見つかったり、逆に地底を探索することで地上に何があるか予想できたりと、地上と地底が相互にヒントになっている関係性を持たせることができるというわけだ。
地底への挑戦、そして空島はまさかの“放置”
前作『ブレワイ』ではこれらの配置物も、ハイトマップ同様に2次元ベースでロードされていた。配置物は、2次元の表示距離に応じたグリッド上に配置される。たとえば大きな建物なら、表示距離が大きい(サイズが大きい)グリッドに配置し、遠くから見えなくてもいい小さなオブジェクトなら、小さなグリッドに配置される。これらのグリッドが重なりあっているわけだ。
また、前作ではダンジョンへの入場にロード時間を挟んでいたが、『ティアキン』ではそういったダンジョンへとシームレスに入場したいという思いがあり、独立した領域にロードしておける汎用的な処理を導入した。
まず地底世界だが、地上と地底は十分に離れているという構造は初期から決まっていた。つまり、地上と地底を両方同時に見る機会はない。そこで地上世界と地底世界等を同時にロードしておくよりも、地上にいるときは地上世界だけ、地底にいるときは地底世界だけをロードしておくほうが、より密度の高い、より広い、より深い世界を楽しめると考えたという。そこで、一定の深さに到達したときに地底世界をロードする仕様を入れてみたところ……。
この役割がわかっているという点は非常に重要。『ティアキン』では制作と確認のサイクルを大事にしており、おもしろそうなことが本当におもしろいのか確認できるだけの最低限のゲーム内実装が必要になる。ただ、やり直しになる可能性もあるため、作り込みすぎるのも好ましくない。役割を確認するための最低限の実装というのが、非常に重要なのだという。
そこでロードデータの総量を減らすため、見えない位置にある配置物はロードしないシステムを考案。テクスチャの解像度についてもオブジェクトごとに、そのオブジェクトが見える場所から観測した和集合をもとに、適切な値を導き出した。ここまでしても足りないケースがあったため、飛び降りる穴に近づいた時点で必要なファイルの一部を先行ロードする仕組みも導入し、ついにシームレスなロードを実現できた。
空島が試作配置されたころは、地上から行けそうな低い位置の島もあれば、はるか高い位置にある島もあった。これらをロードするために必要なシステムについて、奥田氏がデザイナーと相談した結果はまさかの“放置”だった。
何かの機能を実装するということは、何かをひとつ決めるということ。しかし、空島はまだ試行錯誤の段階だった。いまその将来を決めることはしないほうがよいと考え、あえて空島専用のロードは実装しなかったわけだ。
こうした作戦を経て、どのような空島が必要になるのか絞り込まれていった。並行してデザインやアートの観点から、空島の配置も大きく変化していく。結果、メインストーリーに関わり、配置物やギミックが多い大きな空島が少数と、空の移動の経由地になることを目的とした小さめの空島がいくつか、そしてそもそもどうやってたどり着くのかを発見する必要があるようなごく小さな空島というように、空島の役割が分かれていった。
マクロとミクロの視点が『ティアキン』の要
その一例が洞窟システムにおける、開発実機への実装時間を限りなくゼロにする試みだ。このシステムにおいてはコンバートの過程自体をなくし、ゲーム上で即時に編集確認が可能なリアルタイムエディットが、データストリーミングの仕組みの応用で実現された。
そこで洞窟システムでは、ブラッシュアップと変更作業が同時進行できるワークフローを目指して“プロシージャルデコレーション”を構築。コンバート時に“Houdini”(※)の処理を挟むことで、 天井や壁などの遊びへの関与が薄い箇所は自動的に意匠を細部まで仕上げる一方で、メインの導線がある地面などはレベルデザインの意図を壊さないように形状を保つ仕組みを実現した。
今回の講演内容においても、制作サイクルという長い時間単位を考慮する一方で、ミリセカンドのロード時間の最適化を考えるなど、視点の切り替えが多くあったという。エンジニアリングは目の前の課題に集中するイメージが強いが、そこで顔を上げて俯瞰してみると、その実装が本当に必要か、その問題の本質は何かなどが理解できるとのこと。