つぶやく
 |
オープンワールドを作っていると，同じ質問を何度もされるという。木を何本植えたのか，アセットをいくつ投入したのか，といった類の質問だ。それはパイウェル大陸を作りはじめたPearl Abyssのチームも，例外ではなかった。だが実際に開発の時間をいちばん使ったのは，まったく別の問いだったという。プレイヤーに何を見せるのか。世界を何で埋めるのか。次の場所へ行きたいと思わせるには何が要るのか。
この3つの問いに対する答えを，環境アートとエンジン実装の両側から並べたのが今回の講演である。話し手は3人。パイウェル大陸の環境制作を担当したアン・グンテ（Geuntae Ahn）氏がPART 1を受け持ち，続くPART 2はエンジン側の2人が分担した。前半のランタイム部分をキム・ジンファン（Jinhwan Kim）氏が，後半の地形・プロシージャル生成・レベル管理をユン・ジンホ（Jinho Yoon）氏が担当している。キム氏とユン氏はいずれもゲームエンジングラフィックス部門の所属だ。
 |
PART 1に立ったアン氏は，自身を「紅の砂漠」の環境アーティスト兼プロデューサーだと名乗り，まず自然の話から始めた。
 |
自然らしく見えるほど良い環境だ，と我々はつい考えてしまう。密度が高く，土が多く，草木が生い茂っているほど現実味が増す。だが開発に入ってすぐ，チームはあることに気づいた。本物の自然は，ゲームプレイのために作られてはいないのである。
スライドに映し出されたのは，実際の森を撮った写真だった。美しい。何百万年も木々が日光を奪い合ってきた結果として生まれた奥行きがある。だが，この空間をそのままゲームに持ち込んだらどうなるか。プレイヤーはどこへ行けばいいのか，何を見ればいいのかが分からない。
現実の森は，見通しを遮る。方向感覚を失いやすい。ランドマークを視界から隠す。移動経路を不明瞭にする。もっとも，それは自然が悪いわけではない。自然はもともと，コントローラを握った人間にとって読み取りやすいようには設計されていないというだけのことだ。
 |
そこでチームは「ゲーム内の森では，プレイヤーの視線が自然に誘導される」「遠くのランドマークが発見できる」「野生動物や採集物を見つけられる」「空間全体が移動と戦闘を支える」といったように，自然を再現するのではなく，遊べる自然をデザインする方針へ目標を変えた。
 |
だから，ただ木を植えたのではなく，密度を設計したのだとアン氏はいう。同じ森の中でも，ありふれた雑木林と鬱蒼とした深い森ははっきり区別する。そのうえで，プレイヤーが通り抜ける道なのか，発見されるべき場所なのか，戦闘のための場所なのかによって密度を変えた。目指したのは最もリアルな森ではなく，最も読み取りやすい森である。
 |
うまくいっているとき，プレイヤーは尾根に立って木々の稜線を一瞥するだけで，UIのマーカーが何も指し示さなくても，調べる価値のあるものを3つ見つけられる。逆にチームは，森のかなりの範囲をあえて視覚的に静かに，ディテールを落として作った。密度の高い，出来事の多い場所を対比で際立たせるためである。どこもかしこも面白い森は，逆説的に，何も特別に感じられない森になってしまう。
 |
次にアン氏が挙げたのがスケールの問題だった。パイウェル大陸は広大で，この規模の世界は手作業だけでは作れない。どんなチーム規模でも，スタジオが現実に負担できるどんなスケジュールでも無理だという。実際，開発初期には問題が続出したそうだ。範囲が広すぎて地域ごとに品質がばらついたり，アーティストの技量によって成果物が変わったりして，同じ作業を何度もやり直すことになり，修正コストが積み上がっていったそうだ。
 |
そこで導入されたのが，サンプルベースの制作パイプラインである。まず代表的なサンプル地域を作る。求めるムード，密度，視認性を正確に捉えた，小さな手作りのエリアだ。次にそのサンプルからルールを定義する。植生をどこまで密にしてよいか，傾斜がどう浸食につながるか，ランドマークが水辺とどう交差するか。そしてそのルールを大陸全体に適用する。世界の構築にはHoudiniで組んだプロシージャル生成を使い，サンプル由来のルールを大陸全体へ均等に広げていった。
 |
ここからが重要な部分だ，とアン氏は続けた。自動化で浮いた時間を，チームはそのままにはしなかった。サンプル間のバリエーションを増やし，全体の品質を上げ，環境をより面白くすることに再投資したのである。結果として，1つのサンプルの品質を上げれば，世界全体の品質がそれに合わせて上がるようになった。1か所直せば大陸全体に効く――これがこのパイプラインを作るに値した理由のすべてだ，というのがアン氏の説明である。
 |
考え方の転換はこうだ。大陸をもっと速く作るにはどうすればいいか，と問うのをやめて，コピーする価値のあるものをどう作るか，と問うようになった。その問いに変えたとたん，自動化は近道ではなく品質の乗数になる。
3つめの主題は，環境そのものをコンテンツにすることだった。プレイヤーが丘を登り，遠くに何かを見つけ，興味を持ち，そちらへ向かう。到着する前に別の眺望を見つけ，また移動する。この体験を何度も繰り返させたい。クエストマーカーでもチェックリストでもなく，純粋な好奇心が十分な頻度で報われることが，オフロード探索の核心だとチームは考えた。
 |
そこで立てた原則が，遠くに見えるものには実際に行けるようにする，というものだ。パイウェルではランドマークを風景ではなくコンテンツとして作り，テストルートを何度も歩いた。最も高い場所に立ち，遠くの一点を目指して実際に歩いてみて，約束が守られているかを確かめる。数時間も遊べば，プレイヤーは遠くのものには必ずたどり着けると学習し，地平線を信用するようになる。クエストマーカーを待つのをやめる。この信頼は，チームが作ったほとんど何よりも価値があったという。
では，良いランドマークとは何か。目立つもの――半分は正しく，半分は間違いだ，とアン氏はいう。目立ちすぎれば世界の一部に感じられなくなる。地図の真ん中に絵はがきを貼りつけたようになってしまう。逆に自然に馴染ませすぎればプレイヤーは気づかず，作業がすべて無駄になる。その2つのあいだのバランスを探すことになるが，そのバランスは変化し続ける。
 |
いくつもの地域をまたいで遠方から見えるランドマークに必要なのは，単純なシルエットである。その距離ではディテールは無駄になる。逆にプレイヤーが目の前まで近づくランドマークは，近くで見るに値するものでなければ，その瞬間とスケール感が壊れてしまう。そのため主要なランドマークはほぼすべて，1km先からどう見えるかと，10m先でどう持ちこたえるかという2段階に分けて設計された。
とくに効いたのがスカイラインだったという。プレイヤーは細部を認識するより先に地平線の形を認識する。遠くのランドマークの彫刻や樽が見分けられるずっと前に，空を背にしたシルエットが目に入っている。だからチームは，標高と木の配置とランドマークのシルエットに膨大な時間を費やした。夜明けと正午で，複数のアプローチ角度で追跡しながら，空を背にどう読めるかを詰めていった。1つの方向からしかうまく見えないランドマークは，仕事をしていないのと同じだからである。
そして，失敗から最も多くを学んだとして，アン氏はひとつの事例を挙げた。ある場所は見た目が圧倒的に素晴らしく，チームの誰もが気に入った。レビュー会議でスクリーンショットを出せば，皆が手を止めて見入るほどだった。だが実際にプレイしてみると，完全に破綻していたのである。
 |
森が密すぎて，配置した野生動物や採集物がまったく見えず，1週間かけて手で置いた小さな生活の気配は，森に遮られて誰の目にも触れなかった。地形が複雑すぎてプレイヤーは快適な道から外れ，迷ってしまうか，見た目が良いという理由だけで足した障害物に引っかかるかのどちらかになった。また，一部の区画は，密度が低いようにしか見えなかった。
遠景は確かに重要だ。だが最も重要なのは，つねにキャラクターの目線から見た景色であって，社内レビューでレベルの上空を飛ぶドローンカメラの絵ではない。美しい場所ではあったが，プレイヤーが探索したくなる場所ではなかった。
 |
この経験からチームが学んだのは，美しさと探索しやすさは両立しうるし，それが目標でもあるが，どちらかを選ばなければならない場面では探索しやすさが勝つ，ということだった。オープンワールドの環境は，見た目が良いだけの空間では務まらない。プレイヤーが動きたくなる空間でなければならない。
冒頭の2つの質問に戻る。木を何本植えたのか。アセットをいくつ投入したのか。パイウェルの構築には膨大な数のアセットが使われた。木，岩，遺跡，野生動物。森は自分でも認めたくないほど大きい，とアン氏は苦笑した。だがアセットの数は，一度も重要な部分ではなかったという。重要だったのは，プレイヤーが何を見て，どこへ行き，途中で何を発見するかを設計することである。森が成功するのは，1平方メートルあたりの木の密度が現実的だからではない。その端に立ったプレイヤーが，中へ歩いて入りたくなったときだ。
 |
200平方kmを，1つの連続した空間として動かす
PART 2の前半は，キム・ジンファン氏によるBlackSpace Engineのランタイム解説だ。
 |
BlackSpace Engineは「紅の砂漠」を動かすと同時に，「DokeV」「PLAN 8」といった今後のタイトルの開発基盤にもなっている共通技術基盤だ。PS5，XBOX，PC，Macという幅広いプラットフォームで同じ世界とゲームプレイ体験を届けることも設計目標に含まれている。
 |
中核的な目標のひとつが，広大なオープンワールドをリアルタイムに表現することである。単に大きなマップに対応するのではなく，プレイヤーのすぐ周囲から遠景の地形，そして地平線まで伸びる1つの連続した空間にしたい。見えている場所はすべて実際に到達できる場所でなければならない。ここから3つの要件が導かれた。
空間が地平線からプレイヤーまで連続していること。地形，オブジェクト，植生がそれぞれの距離と重要度に応じた適切な表現を持つこと。そして視認性とシーンの複雑さがフレーム予算の範囲に収まっていること。
世界は同時に動的でもある。時間，天候，風，流体の運動が，ライティング，大気，植生，水に一貫して伝播しなければならない。これらのシステムは同期を保ちながら，プレイヤーの行動には即座に局所的な反応を返す必要がある。
「紅の砂漠」がカバーするのは約200平方km。より重要なのは，マップに示された距離が，プレイヤーが実際に踏破できる空間に対応していることだ。プレイヤーマーカーは完全な世界の中の小さな一点にすぎないが，そこからは近くのゲームプレイ空間も遠景も同時に見えている。だからランタイムは，それらを同じ連続した世界の一部として扱わなければならない。
 |
視界はおおよそ1km，3km，10kmの3つのレンジに分かれる。近距離にはインタラクティブなオブジェクトと密な植生が，中距離には地形と集落が，遠距離には森とランドマークとシルエットが置かれる。目指したのは大きいだけの空っぽな風景ではなく，どのレンジにも説得力を保つだけのコンテンツがあり，かつシーン全体がターゲットハードウェアの性能とメモリの制約に収まっている状態だ。
この規模を管理するため，BlackSpaceは世界を2万を超える独立管理単位に分割している。ワールド全体を1つの構造でつなぎ，空間的な領域はプレイヤーの位置に応じて詳細表現と簡略表現を切り替える。町，屋内，クエスト，トリガーといった責務の異なるコンテンツは個別に管理され，関係のない領域に影響を与えずにロード／開放可能だ。イベントやゲームプレイのためだけに必要なオブジェクトは，ランタイムに動的生成される。
 |
ストリーミングは2階層に分かれる。空間側では，可視性・距離・カメラ位置・移動から，現在と近い将来の視界に必要なレベル単位を有効化し，不要になった領域を開放する。リソース側では，テクスチャストリーミングがミップを，メッシュストリーミングがオブジェクト・植生・地形のジオメトリLODを供給する。つまり有効化されたレベルが，最初からすべてのリソースをフル詳細で必要とするわけではない。非同期I/O，展開，準備はフレームをブロックせずに走り，リクエストには優先度が付く。置き換え先の準備ができるまで現在のリソースを表示し続けることで，穴や露骨なロード境界が出ないようにしている。
LODは5段階で，距離が離れるにつれて形状とマテリアルの精度を段階的に落としていく。5段階目より遠くなると，あらかじめ作り置きしておいた簡略メッシュ――遠景用の身代わり――に置き換わる。遠方の要素が消えるのではなく，全体の形状とシルエットが保たれる仕組みだ。この段階的な移行は，遊べる前景から遠景の地形までを連続させるうえでも効いている。
 |
最適化の要は，CPUとGPUがそれぞれ得意な仕事を受け持つ形で協調させることにあるという。GPUは可視性の評価，距離に基づく表現の選択，大量のオブジェクトと植生の処理といった負荷の高いタスクを担当する。
非同期コンピュートでグラフィックス処理と重ねることで，GPUの待ち時間を減らす。CPU側ではワールド更新とエンジンシステムをマルチスレッドのジョブに分割し，スケジューラが依存関係を解決して実行順を決め，バッチにまとめてGPUに供給し続ける。単純化していえば，CPUがフレームを供給し，GPUが大規模なデータセットを並列に処理する構図である。
植生は個別のCPU駆動オブジェクトとして扱うには数が多すぎるため，可視性と距離ベースの表現，そして描画をGPU駆動の構造で処理している。アーティストは密度，種，スケール，傾斜，標高，除外条件といったルールで広い範囲を一括配置し，重要な場所だけを個別に調整する。これで地域ごとの意図的な個性を保ちながら，大規模配置の効率も維持できる。
遠方の植生では，個々のメッシュの細部よりも樹種の識別性，樹冠の形，分布のほうが重要になる。そこで100を超える樹種のインポスターを用意し，距離と視線方向に応じて表現を選択する。1シーンあたり最大50万インスタンスまで表示でき，世界中のすべての木が距離に応じた形で描画され続ける。
 |
距離の説得力はジオメトリだけでは作れない。大気と雲は物理ベースのモデルで扱われ，太陽光が通過する過程で視線に沿って散乱と減衰が蓄積する。そのため空の色，明るさ，コントラストが太陽の位置と視距離に応答し，一律のフォグをかけるのとは違う自然な近景・遠景の分離が生まれる。
雲は高度の異なる2層で表現され，それぞれ高さと形を変えられるので，垂直方向の奥行きと天候のスケール感が伝わる。ボクセルベースのボリュームレンダリングが空間的な散乱と光の透過を扱い，ハイトフォグが高度によって濃度を変えて地面と遠景の地形を分離する。
グローバルイルミネーションは事前計算なしで動的に更新され，ハードウェアレイトレーシングとソフトウェアのレイマーチングを併用する。ワールド全体に広がるサーフェルベースのラディアンスキャッシュに加え，タイル単位とクラスタ単位のキャッシュがノイズを解消する。レイの予算は品質設定に応じてスケールする。集落や戦闘やエフェクトが生む多数の局所光源については，Many Lights Renderingが処理し，パーティクルシミュレーションから光の形状，強度，方向を導くこともできる。
 |
水の表現は，地平線の彼方まで続く海から小さな池や流れる川までを対象とする。スケールも挙動も異なるため，構造は分けられた。海は長距離の波形とうねりを海洋波モデルで扱い，地形に接する水は深度，境界，流れに応答する。技術は違っても，すべての水がライティング，風，天候の状態を共有するので，1つの環境として一貫するという。
プレイヤーの近くの浅瀬は，用意しておいた流れをなぞるのではなく，その場で計算しながら動かす。遠くの水はそこまでやらず，どちらへどれだけ流れるかを画像として描き込んでおいたもの――フローマップ――を貼って済ませる。波の高さの変化から泡が生まれ，地形とぶつかる境目は符号付き距離場で表現される。
 |
時間と天候はワールドステートを共有しており，1つの変化がライティング，大気，地形，植生，水へ伝播する。同じ場所が昼のあいだは遠景の地形まで見通せ，太陽が傾くにつれて影，間接光，大気の色がそろって夕暮れへ向かう。夜には星と天の川が同じ時間状態から現れる。雨では降水，濡れた地面，反射，ライティング，長距離の視認性が地域の天候状態にそろって応答し，そこから雪へ移行すれば，降水，空の明るさ，大気の濃度，遠景の視認性が1つのまとまった環境として変化する。
流体シミュレーションのフィールドは局所的な方向，強度，カールを計算し，その結果を水，植生，草，霧，塵，パーティクル，近くのオブジェクトと共有するそうだ。同じ空間にある要素が，ばらばらのアニメーションではなく1つの一貫した力に応答することになる。キャラクターが動けばフィールドは連続的に更新され，周囲の草や木がそれに反応するわけだ。
そして，環境ごとの反応を個別に実装するのではなく，1つのインタラクションフレームワークが共通の入力を配る形が採られている。接触位置，力の向き，アクション状態といった物理的な入力を，植生，構造物，水，布，パーティクル，オブジェクト，NPCへ流し，受け手がそれぞれの性質に応じたリアルタイムの反応を返す。
 |
植生の場合，共通入力は3種類の反応に分かれる。接触の力に応じた一時的なしなり。衝撃を受けたあとに残る切断・破壊などの永続的な状態。そしてプレイヤーが掴む，引く，登るといった継続的な接触である。草はキャラクターの移動に合わせて接触位置と方向にしなり，通過後に元へ戻る。攻撃の位置と範囲によって刈られた草は，一時的なしなりから別の状態へ変わる。木を掴めば，掴んだ位置と引く方向に応じて幹と枝がともにしなる。登っているあいだは手と体の接触点が連続的に更新され，木がその動きに応答するという。
最後に，衝撃の位置と力に応じて木は揺れ，折れる。そして破壊された状態は世界に残り続ける。植生は固定された背景ではなく，プレイヤーに反応するゲームプレイ要素なのだ，というのがキム氏の結論だった。
 |
地形，配置，レベル――作り直しに耐える形にする
PART 2の後半を受け持ったユン・ジンホ氏は，BlackSpace Engineの3つのシステム――地形，プロシージャル生成，レベルシステム――に絞って解説した。
 |
地形システムの設計目標は2つあった。担当する開発者が違っても一定の見た目の品質を保てること。そして，地形の編集と管理がしやすいワークフローであること。
描画では，ハイトマップとノーマルマップをベースレイヤーとし，マスクマップとリージョンマップでさらにディスプレースメントを加える。近距離と中距離のジオメトリはGPU上でその都度生成し，遠景の地形は作り置きした簡略モデルに任せて処理を軽くする。マテリアルはリージョンマップに格納されたリージョンデータを使う。各リージョンデータはテクスチャ，ディスプレースメント，植生設定，物理データなどを持つ4つのマテリアルセットで構成され，現在のリージョンと隣接するリージョンを求めたうえで，マスクマップから重みを計算して2つの主要マテリアルをブレンドする。
 |
エディタ側では，さまざまなスプラインレイヤーを重ねて地形を作る。高さレイヤーは領域を定義してその内側の地形を上げ下げし，川レイヤーは地形を削り，平坦化レイヤーは地面をならす。
ほかの地形要素にも専用のスプラインレイヤーがある。これらを積み重ねて最終的な地形マップを生成する仕組みで，各レイヤーが地形の別々の部分を制御するため，個別に編集できるという。しかもスプラインデータが保存されたまま残るので，あとから地形を管理して変更を加えるのも容易だ。
 |
ただしハイトマップには限界がある。垂直な崖や複雑な岩の形状は表現しきれない。そこで使われるのがTerrain Meshと呼ばれる特殊なスタティックメッシュだ。上面には地形と同じマテリアル関数を使うため周囲となじみ，リージョンデータに応じて崖のパターン，色，表面の性質を変えられるという。
「紅の砂漠」では複数のTerrain Meshを組み合わせて再利用可能な崖プリセットを作り，そのプリセットを使って大きな山や崖を構築した。少数のメッシュとテクスチャから，多くのバリエーションを作れることになる。
 |
大きな地形を作ることが1つの課題だとすれば，世界を埋めることにはさらに手間がかかる。手作業の配置を減らすために使われている中核が，自動配置システムである。大規模配置は，小さめの木，低木，草のクラスタ，岩といった中サイズのオブジェクトを広い範囲に散らす。使うのは地形のリージョンデータに紐づく配置グループで，何を置くか，どう分布させるかを定義する。密度，間隔，スケール，回転，高さ，傾斜といったパラメータで分布を制御でき，これを調整することでリージョンデータごとに異なる環境が作れる。
 |
一方の小規模配置は，苔，落ち葉，蔦，小石といった近距離のディテールを扱う。こちらも配置グループを使うが，スクリーンスペースのバッファから供給される点が異なり，地形だけでなくスタティックメッシュのマテリアルにも適用できる。どちらもGPU上でランタイムにオブジェクトを駆動するため，レベルデータが減り，広い環境の管理が容易になる。
種類の異なるプロシージャル処理には，HoudiniやBlenderといった外部ツールを制作パイプラインの一部として使っている。エンジンが地形やオブジェクトの情報を外部ツールへ送り，ツール側がプロシージャルなセットアップでデータを処理して結果を生成し，それをエンジンに戻して制作に使う。アセットの作成と配置を自動化でき，ゲームデータのコンテンツも生成できる。
最後がレベルシステムだ。BlackSpace Engineはオブジェクト管理に，セクターレベルとマニュアルレベルの2種類を使う。ほとんどのオブジェクトはセクターレベルで扱われ，世界はゲーム内の距離で一辺256メートルの正方形マスに区切られる。オブジェクトは位置とバウンディングボックスに基づいて自動的にレベルへ割り当てられるので，レベルデザイナーはオブジェクトを手作業でレベルに割り振る代わりに，世界を作ることに集中できる。
 |
ただしセクターレベルをロードすると，可視範囲の外にあるオブジェクトまで読み込まれ，メモリ使用量と描画コストが増えてしまう。これを解決するのがオートサブレベル化で，各セクターレベルをオブジェクトの位置，サイズ，データ型に基づいてより小さなサブレベルへ分割する。
もう一方のマニュアルレベルは，より個別の制御が要るコンテンツに使われる。例として挙げられたのが，「紅の砂漠」に登場する浮遊島The Abyssだ。特定の条件でのみ出現し，複雑なレベル構造を持つ。こうした領域については，レベルデザイナーがマニュアルレベルを選び，レベル階層，ストリーミング条件，ロード範囲を直接設定できる。
 |
遠くのレベルについては，元のオブジェクトをそのまま読み込む代わりにプロキシLODを読み込み，描画の負荷とメモリの消費を抑える。プロキシLODは，そのレベルに置かれたオブジェクトをひとまとめにして1つの軽いメッシュに作り直したものだ。ゲームデータを組み上げる工程で自動的に生成されるので，手作業で用意する必要はない。
問題は，オープンワールドではクエストイベントやプレイヤーの干渉によってレベルが変化するのに，通常のプロキシLODではその変化を反映しにくいことだった。そこでプロキシLODのメッシュに元のオブジェクトの情報を持たせている。これによって遠方からでもオブジェクトの現在の状態が反映され，世界がより動的に感じられるという。
 |
BlackSpace Engineで「紅の砂漠」を開発するにあたり，チームが求めたのは世界を素早く広げる手段だった。同時に，途中で発生する変更を扱える効率的なプロセスも必要だった。今回紹介したシステム群はその一環であり，反復作業を減らし，世界の管理を単純にし，異なる開発者が世界全体で品質を保つのを助けるものだ，とユン氏は締めくくった。
 |
