Luminous Engineが目指す、自然で効率的なオープンワールド構築〜CEDEC 2020（3）

動き回れるマップに制限がなく、どこまでも自由に移動することができる「オープンワールド」と呼ばれるタイプのゲームに人気が集まっている。このオープンワールドを制作する上で、広大すぎる空間へのマップやアイテムの配置、環境音の設定などを人力で行うには限界があり、これらの作業をできるだけスマートに自動化することが求められている。本稿では、Luminous Productionsが構築したオープンワールド制作向け環境「Luminous Engine World Editor」について紹介する。

TEXT＿安藤幸央（エクサ）/ Yukio Ando（EXA CORPORATION）
EDIT＿小村仁美 / Hitomi Komura（CGWORLD）、山田桃子 / Momoko Yamada

＜1＞広いワールドマップをどう編集するか？

Luminous Engine World Editor

はじめに、Luminous Productions 開発部プログラムセクションディレクター・岩崎浩氏より、Luminous Engine World Editor以前の取り組みについて紹介された。

『FINAL FANTASY XV』（以下、FFXV）の開発時にも、リアルタイムでカーブを引いたり、植物を塗ったり、地形を上げ下げするといった作業が可能な環境は用意されており、岩には植物を生やさない、急斜面には植物を生やさないといった"少し賢い"機能も備えられていたが、それでも下記のような課題があったという。

編集コストが高い：高速に塗れるがそれでも追いつかないくらいワールドマップが広い
少し賢い機能がブラックボックス化：拡張するにはプログラマに依頼する必要がある
地形を変える際の手間：地形が変わったとき再編集する必要がある

これらの課題を解決するため、何とか工程を自動化したいという想いが強くなっていった。「手で1つずつ置く」という操作からスタートし、『FFXV』では「塗って高速に置く」という操作に進化したが、これをさらに「自動で置く」に進めるべく、新ツールの開発プロジェクトが始動した。目標として定められたのは以下のとおり。

ミクロからマクロまで：手で微調整する作業から大規模な範囲を一度に扱うといった両方をサポートしたい
拡張・応用しやすく：様々な人が機能を追加できるようにノードベースでプロシージャル演算を定義する
毎回同じ結果：ビルドするたびに結果が変わるのは良くない。ランダム要素を排除し広域で設定しても一部を設定しても結果が同じになるようにする
結果をリアルタイムに確認：操作の結果をできるだけ早く確認できるようにしたい

＜2＞演算をどう組み合わせてプロシージャルをつくっていくのか？

続いて、エンバイロメントアーティストの山本健斗氏より、Luminous Engine World Editorでどのようなことができるのか、アーティスト視点からの解説が行われた。山本氏は、2018年入社後、プロシージャル植生の作成やEnv（環境用）シェーダの開発、アセット制作やマップレイアウトの仕事に携わってきた。

▲プロシージャル植生

Luminous Engine World Editorは様々なマスクをノードベースでかけ合わせて意図をもったマスク範囲を作成し、そこに下草などのブリッジを生やしたり、エフェクトや環境設定の配置、パラメータ設定が行えるオープンワールドに特化したプロシージャルエディタだ。

▲デモリール中にある植生もLuminous Engine World Editorでマスクを調整することで自動で生成されている

▲マスクの内訳。パーリンノイズなどの各種基本的なノイズマスクと、地形から得られる地面法線や地面オクルージョン、侵食マスクなど。これらの単純なマスクを何度もかけ合わせることで、意図をもった目的のマスクを出力している

マスクや地形情報からポイントを生成するという手法は、Luminous Engine World Editorに限らずHoudiniなどでも工夫次第で再現できる方法だという。

▲密集した配置をつくる具体例

▲ノイズを2値化してポイントを生成した場合。これだけでもまとまった配置が表現できる。しかしマスクの境目がくっきりと目立ってしまい、機械的な見た目になっている。一律に生えず外に向かってまばらに生えるのが普通

▲よりタイリング数を増やした同一のノイズで減算した後に2値化する。大きな塊に細かいノイズが乗るようになる。ある程度まばらに、外側に拡散していったようなマスクを生成することができる

▲結果の比較。右の方が自然

また、デモリール中の森も簡単な工夫で表現されている。木を配置するため、地形からマスクを取得し、急斜面で崖になりそうなところを地面法線を参照して除去、ノイズでムラや木の生えないようなエリアがあれば減算をかけ、最終的にはアーティストのマスクペイントを重ねている。

木が密集していないと森と表現されないため、森の中の植生は木の根元ではなく、木が密集したところに生成されなければならない。そこで、木と他の植生が重ならないようにするためのマスクを応用し、木の密度判定に利用。マスク範囲を一度拡大することで隙間を埋め、その後範囲を縮小することで密集している箇所を判断することができる。これを森マスクの原型とし、用途に応じて加工することで、様々な表現に利用した。

▲木の根元から生成したマスクを森マスクの原型に

▲植物のマスクが森のマスクに重なっているときだけ、普通の植物から森の植物に切り替わる

▲日向にしか生えない花畑のマスクを森マスクで減算することで、花が生えないようにする

ひとつひとつは単純な計算だが、マスクベースで行うと、アイデアに応じてフレキシブルな植生表現ができる。ゲームエンジン上でリアルタイムに反映されるため、Substance Designerのように直感的に素早く植生の更新を確認可能とのこと。

＜3＞プロシージャルとレベル作業者をどうつないでいくか？

プロシージャルの課題として、「部分的な対応に弱い」ことがあると言う山本氏。その都度ノードネットワークを書き換えていくのはとても効率の悪い作業となる。また、それを続けていくとノードネットワークが膨大になり、制御できなくなってしまう。ノードネットワークの編集者が限られる場合、アーティストの要望に即座に対応できないのも問題だ。ノードベースの作業の学習コストや、こういった作業が好まれない場合もあり、作業クオリティに差が出るということもままあるのだという。

▲黄色い花の一部分だけ白い花を咲かせたい場合など

ノードネットワークの制作者とは別に、アーティストも気軽にプロシージャルに関与でき、自動で自然な見た目にしてくれるしくみづくりが必要だった。そのため、以下の3つの取り組みが行われた。

●プロシージャルを構成するマスクの上書き
●レイアウトとの連携
●オリジナル植生の追加

まず、植生ネットワークを作成する際にネットワーク全体を丸々つくるのではなくキーとなるマスクを明確に分担しプリセット化したのち、合成することで表現。様々な植生に対応するためにこのような構成になっており、森や花畑に対応する必要がない場合はキーマスクをOFFにしてしまう。

▲植生ネットワーク全体の構成

▲対応する必要がないキーマスクはOFFに

キーマスクに対して、ポイントの生成数やマスクの強さなどはアーティスト側で調整することで、同じプリセットでも数値次第で調整が可能となる。またアーティストがペイントツールで、マスクを書き換えることができるようにした。

▲土や草の地面など地形のマテリアル単位で影響するエリアマスクと、森や茂みなどの配置系に関わるサブエリアマスクで構成されている

例えばアーティストが土マスクに手を加えれば地面の様子が変わり、ツリーマスクに手を入れれば高い木を生やすことができる。森マスクに手を入れれば、ある箇所を中心に木が生えたり、森を分断させることも可能だ。

また、キーマスクのつなぎ方次第で、併用させるかなどを操作でき、鬱蒼とした森や歩きやすい森などレベルデザインに合わせて森をつくることができる。

ペイントマスクの優先順や、競合するかしないかなどを共有することで、ノードネットワークの詳細を知らない人でも把握できるようにしてある。地域ごとのリージョンマスク、草・土・岩といったエリアマスク、森・茂みといったサブエリアマスクが順に機能していく。

▲同じ森ペイントを塗ったとしてもAの地域とBの地域では異なる。エリアの変更があっても木の生え方などを全て修正する必要はなくなる

■レイアウトとの連携

アーティストが配置したアセットや、カーブで引いたものとプロシージャルとの連携は、まずモデルのコリジョンからマスクを取得し、そのマスクを使ってカーブやモデルと重なった場所の植生を間引くというネットワークが組まれた。アサインされたコリジョンの属性を取得することで、プロシージャルの同系列のキーマスクと組み合わせているという。

▲轍（わだち）の部分でコリジョンが草の属性になっており、植生ネットワークと同じ条件で配置できる。つまり植生を変えると轍部分も変更される

▲川の場合も水属性の縁の処理を自動で行なっている。アーティストが縁を意識せずにレイアウトしても良い感じに表現してくれる

■オリジナル植生の追加

ネットワークで定義するまでもない部分的な配置への対応として、アーティストによるオリジナルの植生を追加する方法が下記のように組み立てられた。

▲マスクを定義しそこに設定したリソースをペイントする機能。あとでパラメータ変更が可能

▲キーマスクと連携することで、既存の配置を上書きするなど、ノードネットワークを活用したかたちで付け加えることができる

アーティストの技術やセンスを自動化と上手く組み合わせることで、クオリティと開発速度の両立が図れたと、山本氏は語った。

次ページ：
＜4＞よりシンプルな操作でより複雑な結果を

[[SplitPage]]

＜4＞よりシンプルな操作でより複雑な結果を

続いて、過去に『FINAL FANTASY XV WINDOWS EDITION』のプラットフォーム対応やマウス・キーボード対応などを担当してきたプログラマー・濵野翔平氏がLuminous Engine World Editor実装の背景を解説。「よりシンプルな操作でより複雑な結果を」というポリシーのもと開発が進められたという。

プロシージャルのネットワーク自体は、テクニックを組み込んでいくにつれ複雑なものになっていくが、レベル作業のアーティストは細かいことを気にすることなく「良い感じ」に配置されていれば良い。細かく指定したいパラメータ調整も、複雑なノードネットワークを開かずとも簡単に調整できる工夫が実装されている。

■データ作成のワークフロー

まずは何もない空間からプロシージャル処理で配置データが作成されるまでのワークフローを紹介。範囲指定し、プロシージャル処理を進めると地形が出現する。そこから徐々に配置が計算されていく。さらにカーブを引いたり、植生をペイントしたり任意の場所を編集することもできる。

プロシージャル定義
（TAやEnvアーティストが事前に用意）
　↓
レベル上にゲームオブジェクトとして配置
（最低限必要なプロパティはネットワークのパスとプロシージャルの適用範囲）
　↓
パラメータ編集
（実機上で編集。編集した結果がリアルタイムに反映される）
　↓
出力ファイル更新

レベル作業者が編集するのはプロシージャルの入力データであり、出力データ（配置データ）ではない。作業中は結果をその場で確認しながら作業でき、確認用の出力ファイルを待つ必要がない。配置データは専用サーバで定期的にビルドされる。複数人が同時に同じ場所で作業するコンフリクト回避が行われ、特定の領域をすぐにビルドできるようリクエストできる機能もあるという。

■基本ツール

実機上で編集する基本ツールは、スカルプトツール、ペイントツール、カーブツールの3つ。

スカルプトツールは、地形を上げ下げしたり、範囲内を平らにしたり、滑らかにする処理ができる。変更した地形に追従し、勾配によって配置されるアセットが切り替わったりする。ペイントツールは、1つ1つのアセットを指定してアセットを配置するのではなく、エリアのIDをペイントするようなツール。カーブツールは、道路など左右幅が同じものは1本描くだけで十分で、川のような左右で幅を細かく調整したい場合は、マルチカーブデータを利用し細かく編集することも可能。ここで編集したデータはスカルプトデータ、ペイントデータ、カーブデータとしてネットワークをながれていく。ツールを組み合わせるのも容易だ。

▲マスクをペイントした位置にカーブをつくり、マテリアルを変更してカーブの領域にアセットを追加して畦道をつくる

■カスタムパラメータ

複雑に組まれたネットワークのうち、スカルプト、ペイント、カーブの3つだけで満足なデータがつくり出せるかというとそうではない。数値やリソースの情報など様々な情報が組み込まれており、ネットワークの外から指定できるパラメータとして扱った方が便利なものもあり、カスタムパラメータというしくみが実装された。

ノードネットワークの処理は同じだが1箇所のみパラメータが異なるといった、あるネットワークを別のエリアに適応したい場合、コピーを用意するのは無駄が多く、メンテナンスコストも高くなってしまう。そこで同じネットワークを使い回す方法を考えた。

▲Exposeパラメータというネットワークの外部から値を上書きできるようにし、バリエーションをもたせることができるようになった。カーブの編集時にも、カーブを地面に吸着させるなど座標以外のパラメータ編集が可能

■レイヤーデータ

同じエリアに対して、花のペイント用、木のペイント用のネットワークがあるところに第3のマスクを使って岩を追加したい場合、Exposeパラメータではモデルを差し替えたり、生成数を変えたりはできるが、基となる入力データそのものを新規に追加することはできない。コピーして増やすことはできるが、無駄やメンテナンスコストが高くなる。そこで、ネットワークにレイヤーという概念を追加し、ながれるデータを多階層的に処理できるようにした。

▲パラメータの異なる部分についてはメタデータ化し、メタデータ単位でデータを追加したり編集したりできる。ノードネットワークの編集なしで、新しいデータを追加することが可能になった

＜5＞発展性を重視した実装

ノードを組み合わせて処理を行うフレームワークをいかに実装していったのか、プログラムセクションのディレクター岩崎浩氏から解説された。Luminous Engine World Editorが目指したのは「発展性」、中でも重視したのは次の3点とのこと。

●応用のしやすさ
●拡張のしやすさ
●メンテのしやすさ

そのために「単純さを保つ」。「単純な入力に単純な処理をすると複雑そうに見える結果が得られる」ことを目指したという。

例えば、アーティストが地形を上げ下げする操作は、実はマスクのデータを上げ下げすることで目的の出力結果を得ている。そのため、対応するマスクのデータを変更すれば、地形を上げ下げするツールを木を描くツールに応用することも可能というわけだ。

こういった構造にした目的は「エディタと結果を分離する」ことだという。

「入力、演算、出力には様々な種類があり、これらのバリエーションが重要です。バリエーションの多さは表現力や応用力につながってくるため、これらを無理にシンプルにする必要はありません」（岩崎氏）。では「単純さを保つ」にはどこをシンプルにするかというと「間をながれるデータ」であるという。扱うデータが単純であれば全体の単純さを維持できるのがその理由とした。