こんにちは。『フォートナイト』開発チームでリード FX アーティストを務めている Scott Kennedy です。Epic では、独自の自社ツールを使うことが好まれていて、このことは実際に『フォートナイト』をサンドボックスとして Niagara で実行しています。Niagara をよく知らない人に説明すると、これは、新たなパーティクル エディタ (アーリーアクセス) です。古くなった Cascade エディタの代わりにするべく、現在活発な開発が進行しています。現時点では、まだデベロッパーが開発用に Niagara に切り替えることは推奨していませんが、私たちは、Cascade に比較してはるかに自由度が高く、より柔軟で、データ駆動型のツールセットになるようにその開発に取り組んでいるところです。
『フォートナイト』第 2 章では、水が全面に出ています。そのため、マップを移動するまったく新たな方法を追加するとともに、景観のビジュアル面に変更を加えました。これらのことを念頭に置いて、まったく新たな水のシステムを開発することにしました。この新しい技術を構築し始めたとき、Niagara を使用するには絶好の機会だと思いました。私たちのこのツールを強化するためには、モバイルからハイエンド PC に至るまで、何百万人ものプレイヤーに使ってもらうことが一番だと考えました。この記事では、Niagara を既存のパイプラインに組み込む過程で私たちがどのようなことを学んだか、ということについてお話います。できれば、私たちのチームが経験した試練と困難が教訓としてデベロッパーたちの役に立ってもらいたいものです。そして、そのことが、この新たなパーティクル ツールを使う開発者の基礎になってくれればいいと思います。
私たちが学んだこと
Niagara には、Cascade では簡単に実現できなかった素晴らしい機能が豊富に備わっています。たとえば、Emitter の継承 (これについては後で説明します) や、プログラマブルなワークフローなどを挙げることができます。しかし、格言にもあるように、大いなる力には大いなる責任が伴います。言い換えれば、スムーズな Niagara のパイプラインを実現するためには、秩序が何より重要だと私たちはわかったのです。Niagara は、Cascade よりも格段に多くのアセットを生成するため、適切な命名規則 / ファイル構造 / 作業ガイドラインが必要になるはずです。以下は、私たちがたどり着いた命名規則一例です。Niagara のシステム: NS_SystemExample
Niagara のエミッタ: FN_EmitterExample
Niagara のモジュール: FN_ModuleExample
Niagara の動的入力: FN_DynamicInputExample
みなさんは、なぜ複数のアセット タイプのために FN_ を使用するようになったのか疑問に思われるかもしれませんね。アーティストたちは、ツール内でアセットを検索するときに、この FN_ によって『フォートナイト』の承認済みのアセットであるとわかるのです。アセットのリストを見ると、一目で簡単にわかりますね。これらのアセットは主にツール内のメニューから追加するのであって、コンテンツ ブラウザからドラッグするものではありません。だから、たとえば、エミッタとモジュールを区別するために冗長なプレフィックスを追加する必要はなかったのです。
私たちが実施した手続きは他にもあります。新しいエミッタとモジュールを作成する場合に、ゲートキーパー (門番) を置くというのがそれです。私たちの場合、FX テクニカル アーティストの Andrew Melnychuk が、モジュール作成と極めて複雑な数学的問題に関して FX チームを専門にサポートしています。彼はまた、『フォートナイト』チームで Niagara に関する全般的なファシリテーターでもあります。チームの 1人だけが新しいエミッタを作成することができ、その他のアーティストが独自に新しいエミッタを作成する場合にはその人から指示を受けるという仕組みによって、理論的には、アセットの増大が抑えられ、複数のエミッタとモジュールにおける重複した作業が削減されることになります。また、このようにすると、人は、基礎となるエミッタを作ることによって、『フォートナイト』でいつも作られるようなタイプの FX をサポートしてみようか、という気にもなります (マスターマテリアルのことを考えてみてください)。このような専門職的な役割をもつ人を配置することによって、新しい機能を作成する際にエンジニアに頼ることが劇的に減りました。
Niagara では複数の方法で継承がサポートされています。まず、エミッタの子を作ることができます。ブループリントやマテリアルとよく似ていますね。この機能のおかげで、第 2 章開発中に行ったリファクタリング作業では、その大変さが軽減され、時間も節約できたのですから、素晴らしい機能です。たとえば、すべての武器のエフェクトで、距離に応じてスケーリングする新たなモジュールを作成する必要があるとします。その場合、親にそのモジュールを追加すると、すべての子が瞬時にそれを取得できるようになります。Niagara は、飛び抜けて柔軟なツールです。アーティストは、デフォルトのエミッタを作成して、チームの他のメンバーと共有できるのですから。エミッタの構造をどのように設定するかいろいろと考えた際に、2つの流派ができました。 流派 1: 少数の汎用的なエミッタを作成し、FX チームにこれらを叩き台としてとして使ってもらう。Cascade で行っていたこととほぼ同じやり方です。流派 2: 非常に特殊なエミッタを作成する。たとえば、gun_sparks や gun_smoke など、ゲーム内の特定のアセット タイプを支えるようなエミッタを作成します。流派 1 の汎用的なアプローチをとると、アセットの増加を抑えることができますが、理論的にはアーティストが新たなエフェクトを作る場合に毎回最初から作成していかなければなりません。反対に、流派 2 の非常に特殊なエミッタを作るやり方をとるなら、アーティストは、特殊でアート指向のエミッタを追加することですぐさま作り始めることができます。ただし、この方式では、大量のファイルが作られるとともに、創造性が減退し、継承のメリットも低下します。そこで私たちのチームは、これらのハイブリッド型ソリューションに行き着いたのです。 たとえば、武器の FX では、武器の FX を作成する用途に限定されたエミッタのセットが使われています。これによって新たな銃を素早く作成できるようになります。そして、同時に Skydive Trail (スカイダイビング時に表示する軌跡表現) を作成するためのエミッタ セットも使われています。こうすることにより、ワークフローが改善されただけでなく、作業スピードも向上しました。また、レンダリングに特化した FN_Mesh や FN_Sprite、FN_Ribbon などの汎用エミッタのセットも使っています。これらの汎用エミッタによって、Cascade を使う場合と同じように新規エミッタを追加することができるようになりました。私たちが Niagara を使い続けるうちに、きっと、もっとよい親エミッタを作る機会が増えてくると思います。
上手くいったこと、成功したこと
泳ぎ！『フォートナイト』ではまったく新しい移動の仕組みが導入されました。そのシステムを支える FX はすべて、Niagara で作成されました。これは大成功でした！『フォートナイト』の開発リズムを考えてみれば、安全策をとるのが当然の選択と言えるのでしょうが (特に、真新しい機能と技術を使う場合)、私たちはそのようにはしませんでした。この取り組みに頭から飛び込み、最初から Niagara を使って、Cascade には頼らないことにしたのです。最初は難しい状況が続きました。Niagara がまだ活発に開発されている最中だったからです。そのため、私たちは時々作業速度を落とさなければなりませんでした。Niagara で水泳を処理する必要があったため、Niagara のさまざまなバグと欠けている機能が表面化しました。その結果、このツールは堅牢なものになり、アーリーアクセス状態から脱しやすくなりました。『フォートナイト』で強制的に使うことで、このツールに大きな恩恵があったばかりか、Cascade で FX を作成するよりも多彩な選択肢がもたらされました。たとえば、新たな水のシェーダーは、格段に強力なものになりました。これは、Niagara によって動的パラメータの制限が 4 から 20 に引き上げられたことによります。
もう 1つの成功は、『フォートナイト』の新しい乗り物、モーターボートです。すべての水泳ビジュアルは Niagara で作成していたので、ボートも Niagara を使うことにしました。車両は非常に複雑です。速度や体力、ブーストなど、多数の変数で FX を制御します。その上、ボートは水システムと連携させる必要があるのです。Niagara はこれにぴったりでした。データを読み取り、ゲームコードまたはブループリントのコードに頼ってスポーンの動作などを制御するのではなく、Niagara 内でもっと多くのことを行うことができたのです。たとえば、ボートにはカスタムのエミッタとモジュールが組み込まれ、ボートが水中にあるときにその角度と速度を読み取り、水に接している側だけでしぶきが起きるようにしました。この主のしぶきの動作は、ブループリントやコードの助けがないと Cascade では不可能です。
『フォートナイト』第 2 章で輝きを放っているのは水だけではありません。第 2 章の開発が始まるまでの数カ月間で、私たちは、『フォートナイト』で Niagara の早期運用を開始しました。まず、既存の Skydive Trail を Cascade から Niagara に移植しようとしました。第 2 章では、初めてまったく新しい Skydive Trail を Niagara だけで作ろうと決めていました。そして、この新たなパーティクル用ツールでしかできないものもいくつか作ろうとしていました。わかりやすく言えば、Skydive Trail とは機能的には、ゲームで最初の落下部分でプレイヤーにアタッチされる Cascade のシステムにすぎません。Skydive Trail はコードで出現するものです。だから FX チームがブループリントにアクセスして、Cascade ではできないことを実行するということは難しいのです。そこで私たちは、Niagara を使って、初めての Skydive Trail をプレイヤーの入力に反応するようにしました。しかも、すべてこの新たな VFX システムの中で設定できるようにしたのです。私たちが考え出したのは、Spectrum Skydive Trail というものでした。このシステムは、プレイヤーの速度や角度などのデータや属性を使って、色を変化させたり、テクスチャのパンを速めたり、マテリアル内の動的パラメータの値を制御することによって、アルファマスクでテクスチャがもっと現われるようにすることができます。この新たな Niagara Skydive Trail は、すでに以前のものよりもステップアップしています。
第 2 章の開発で非常に上手くいったものは、もう一つあります。それは、Cascade とおよそ同じシステムのビューを新たに備えることができたことです。Cascade の長所の一つに、パーティクル システムがどのように構成されているかひと目でわかる、ということがあります。Unreal を使っている FX アーティストなら全員知っている共通語というものがあります。そのような言葉によって、アセットを共有したり、大規模なチームで仕事がしやすくなるのですが、これまで、Niagara にはこのようなひと目でわかるビューというものがなかったのです。それから、Niagara プラグインで提供されるモジュールが Cascade と機能的に同等なものとなり、Niagara を初めて利用する人たちへのオンボーディングも迅速化します。この新たなシステムのビューによって、Niagara での作業は飛躍的に高速化しました。これは、スタックのビューをスクロールする量が圧倒的に少なくなったためです。これで、Cascade と Niagara の両方の長所を取り入れられたことになります。この長所には、Cascade の速い開発と、わかりやすいワークフローも含まれます。これらが、必要に応じて、完全なグラフ ビューが備わった完全な属性/データ駆動のパーティクル エディタと組み合わせれることになります。
初期の実験と課題
初期の実験によって、水の相互作用をモデリングする場合にとるべきアプローチが、刺激的で完全にプロシージャルな形でわかりました。キャラクターの手足の解析的表現と水の表面の交差部分をモデル化することによって、水しぶきの発生数/移動速度/配置場所を動的に選択することができるようになりました。残念ながら、この機能は第 2 章に間に合いませんでしたが、今後の展開が楽しみです。私たちが最初に Niagara を使い始めて、既存のアセットを移植し始めたとき、新しいエミッタとモジュールは少しばかり混乱した状態にありました。このまったく新しいツールの実験を行い、非常に複雑で活発なパイプラインに組み入れようとすることによって、未使用であったり、やり直しが必要になったものが多く出てきました。初めの頃に探索を行ったことは非常に有益でした。それは今後の指針を得ることができたからなのですが、同時に、私たちは技術的な負債を負うとともに、プロジェクトで不要になった古いエミッタやモジュールを除去するために作業を何度もやり直す必要がありました。最終的には、新しく加わったアーティストたちが Niagara を使うようになったときに、どのエミッタを使用すべきかよくわからない状態になりました。そのため、サポートされていないエミッタがあったり、無駄に新しいエミッタを作成する羽目になったのでした。このような問題は、マテリアルのパイプラインでもよく起きます。プロジェクトにちゃんとした秩序と適切な命名規則が欠けている場合は、使用すべきマスター マテリアルをコンテンツ ブラウザから探し回るよりも、必要な機能を備えた新しいマテリアルをゼロから作成する方が簡単なのです。このような問題に対処しているうちに、チームの 1人にエミッタのゲートキーパーという役割をもたせるようになりました。Andrew と私というフィルターにかけることによって、より有意義なエミッタを選択することができるようになり、Niagara に切り替えたときにパイプラインのプロセスをチームに広げることができました。そのため、技術的な負債を減らし、前進することができたのでした。
Niagara と『フォートナイト』の今後
今後の展望について考えてみると、前から Cascade で可能であったこと以上のことを Niagara でできるようにするために、さまざまなな方法を見つけ出したいと思っています。最初のプロシージャルのテストは『フォートナイト』にはまだ含まれていません。しかし、開発が進むにつれ、ハードウェアもより高速になりつつあるということから、ワールド内で完全に創発的で動的な相互作用が可能になるはずです。『フォートナイト』の FX チームでは常に努力していることが一つあります。それは、FX が単にワールドの上に合成されているだけではなく、ワールドに統合され、ワールドに影響を与えているかのように感じさせたいということです。まだ早期アクセス状態にあるツールで作業する場合、明らかに問題となることがあります。その 1つは、私たちが遭遇した莫大な量のバグとワークフローの問題です。しかし、Epic では、構築中のツールをワールドクラスに仕上げ、Unreal Engine への意味ある追加物にするためには、このような早期アクセスのやり方をとるほかありません。私たちは、QOL のリクエストからなる長いリストを作成しました。それらへの対処が完了するならば、ワークフローはより速く、より良くなり、多くの人たちが Cascade を使ってやり慣れていたことを上回る結果をもたらすようになるはずです。
Niagara にはパワーと柔軟性が備わっているため、今後、機能を作成するためにエンジニアの助けを借りることは少なくなるはずです。以前なら不可能だったと思われるようなことでも、試してみることができるようになります。Niagara は Unreal における FX の未来の姿です。『フォートナイト』でこのツールを実際に使用することによって、安定性/高速性/柔軟性が保証されるようになるだけではなく、すべての Unreal デベロッパーにとって、高速化されたワークフローで簡単に使えるようになることが保証されます。今後、Niagara を使ってどのような素晴らしいものが作られるか楽しみです。