FF15エピソード・ダスカのエフェクトはこうして作られた～Luminous VFX Editorの紹介～

CEDEC 2015におけるFF15のルミナスVFXエディターの紹介内容

2015年8月26日～28日に、神奈川県横浜市にあるパシフィコ横浜で日本最大の開発者向けの
カンファレンス『CEDEC 2015』が３日間行われました。

FF15は最終日の28日11時20分～12時20分に、『FINAL FANTASY XV -EPISODE DUSCAE-の
エフェクトはこうして作られた～Luminous VFX Editorの紹介～』というセッションを行った。

その様子はニコニコ生放送とUstreamにて、ライブ配信を見ることができました。
内容はFF15で使用されているルミナス・スタジオのエフェクトツールの機能です。講師は以下の３名。

議題

次世代機でのエフェクトデザインの一例

次世代機でのエフェクトデザインの一例は、野副氏が解説した。
FF15におけるエフェクトデザインの話では当たり前の事だが、
ゲームエフェクトとはゲームの世界観はエフェクトのデザイン上で重要な情報だと話す。

FF15の世界観は自動車や現代的な建物があり、そこに生きる人々はスマホを持ってたりとか、
私達の住む現代のような描かれ方をしているが、
一方で剣や魔法、モンスターや召喚獣などが存在するファンタジーな世界観となっています。

じゃあ世界観を踏まえた上で目指すべきエフェクトデザインは、
フォトリアルに描くファンタジーエフェクトを目標にしている。

世界観がフォトリアルな世界観なので、エフェクトもファンタジックな表現を自然な表現できれば、
FF15の世界観に馴染んだエフェクトが達成できると思われますと話す。

簡単にいえば、エフェクトも自然現象や物理現象のようにリアルにすれば
FF15に合うエフェクトになるんじゃねということです。

でもフォトリアルだけだと、ゲームのような過剰演出や記号的なエフェクトにしたい場合は
演出に不足があるので適度なフェイクを取り入れているのだと言う。

フォトリアルの問題点とフェイクの導入

適度なフェイクとはどんなものなのか？というのは、
ノクティスらがクイーンガルラと戦っている動画を見ながら解説を行った。

モンスターにダメージを与えると毛や血が舞ったりしているが、
それだけだと攻撃が当たっているかどうか分からないプレイヤーもいるかもしれないので、
現実では有り得ないことだが、火花のパーティクルが散ったり派手な爽快感を加えている。

過剰演出はノクティスが洞窟内で召喚獣ラムウを入手したときのシーン、
ラムウが攻撃するシーンでは天候を操る神様のような存在として描かれているので、
何でも有りな特別な過剰演出で雷を落として攻撃するシーンで描かれている。

モンスターが倒れているところにダメージを加えているが、
通常の青色エフェクトとは異なり、赤色のエフェクトが瞬間的に発生してます。
これはモンスターの弱点を付いて大ダメージを与えているのを赤色エフェクトで表現しているそうです。

さらなるフォトリアルのアプローチ

さらなるフォトリアルを目指し、環境の影響により動的に変化するエフェクトを実践している。
FF15では時間経過により朝・夕・夜と環境が変化し、風や濃霧による天候変化もある。
それに合わせてエフェクトの方も環境の影響を受けて変化するようにしている。

例えば現実の携帯だと朝は画面が暗く、夜は眩しいくらい明るいが、そんな感じのをゲームに加えてる。
フィールドでは夜になれば街灯の明かりに虫や蛾が集まるが、FF15ではエフェクトで虫を表現しており、
朝になれば虫はどこかに飛び去るが、夜になると虫が集まるようにリアルに表現されてます。
コーヒーから出ている湯気においても、風に吹かれた方向に湯気が流れるようにエフェクトで制御されている。

Luminous VFX Editor

FF15ではそういったエフェクトを、Luminous VFX Editorツールで作成している。
実際のLuminous VFX Editorの画面を見せて解説を行ったが、
制御方法はマウスでドラッグしてノード（線）を繋いで、データに反映されるように制御している。
そして右側にあるメニューで、細かい数値入力を行って調節する感じでした。

下側の画面のところでＹ軸（縦）にオブジェクトが移動するように、
トーンカーブを移動させてオブジェクトが上下に動くように、
シンプルなアニメーション制作を披露してました。
画面左上にある画像は、どんな風に反映されたかを知る小さいビュワーです。

ノードベースエフェクトツールのメリット・効果的な運用

プログラマーを担当している小野氏は、Luminous VFX Editorのツール開発を担当している。
ノードベースの大きなメリットは３点上げている。

柔軟性・自由度が高い

ツールはユーザーが自由にノードを繋いで接続できる。
単純な計算式はもちろん、シグナルリンクを使ったロジックを含めた式も組むことができる。

一例として花畑を蝶が飛ぶアニメーションを公開していたが、
Matrixの親子階層を作って親Matrixの位置だけ継承させたり、別の座標計算式と掛け合わせたりして
蝶が複雑な跳び方をする動きを実装しているのだと言う。
そこにシグナルリンクを使って、蝶がランダムに跳ぶように制御させている。

右側の画像ではFcurveノードでスケール（大きさ）、描画、アルファ（透明度）にノードを繋いで
板のオブジェクトが小さくなり、透明になって消える動きを制御している。
このような複雑な計算式も、ノードベースのＵＩで作成できるのが強みなのだと話す。

外部とのやり取りが簡単

環境に馴染んだエフェクトを出すには、エフェクトの呼び出し元から現在のパラメーターをもらってきて、
その状態に適した絵を出す必要がある。
外部から受け取るパラメーターの例としては、時間や風の強さといった影響だったりとか、
車のスピードなどエフェクトの発生源などの情報がある。

さらにパラメーターに限らず、外部からのエフェクトのフェードアウトのタイミングを制御したり、
エフェクト内部からサウンドを鳴らすタイミングを外部に知らせることが必要になってくる。
ノードベースのツールであれば、外部からのシグナルやパラメーターを用意することで
その要件を用意に満たすことができる。

画像では車が起こす砂煙のエフェクトの例です。
車の速度、タイヤの回転、スリップといった生のパラメータ値をもらってきて、
それを元に砂煙の量、大きさ、濃さを算出している。
つまりそういった設定はエフェクトアーティストだけで、エフェクトエディターだけを使用して完結できる。

作業分担がしやすい

ノードベースのツールでは組み合わせで様々な機能が実現できるため、
プログラムの更新無しに新しいエフェクトを生み出すことができる。
これによってアーティストがプログラマーに頼らずにエフェクトを作ることができるし、
アーティストからの要望をプログラマーが検討し、ノードを足さずにツール上で実装できるケースもある。

作業でよくあるのがアーティストがプログラマーに要請を出して、
プログラマーが実装を行い、さらにアーティストがその機能を検証してまた修正要望を出し、
プログラマーがまた更新するといったような無駄なイテレーションを省くことができるメリットがある。

実際にFF15の制作であった要望は、ニフルハイムの帝国魔導兵が到着すると地面に砂煙を巻き起こすが、
地形が傾いた場所だとエフェクトが不自然に流れてしまうといったことがあったようです。
なので起伏が激しい場所では、その設定を無視するようにしてくれという案件があった。

これをプログラムで対応しようとすると、実装→検証→調整依頼→また実装という
プログラマーとアーティスト間で作業の行き来が発生する。
FF15ではそういった事はプログラム更新無しで、ツール上で実装できたそうです。

ツール設計

ツール開発で目指したことは、ノードベースのメリットを活かした柔軟性の高いツールであることと、
アーティストが学習しやすく使いやすいツールの2点だそうです。
ノードベースのメリットを活かすためには、個々のノードをできるだけ小さく設計して、
いろんな場所で使いまわせるように設計する必要がある。

そして、大きな機能はノードを組み合わせて実現する。
巨大なノードを設計すると他で使えなかったり、接続自由度が薄れたりと大抵失敗する。
なので画像のように、BillboardとParticleなどでノードを分離させて構成している。
それによりノードを差し替えて別のバリエーションを作るのが用意になる。

Reference Controlと機能拡充

ただ、こういった方針の課題であっても、個々のデータを細かく作るとデータを作る手間が増えたり、
ノードを組み合わせないと動かないためツールの学習が難しくなってしまう。
その課題を解決するために、複数のノードを１つのノードとして固めて扱う
『Reference Control』という機能を導入した。

１つをノードを大きくして設計して使い手が簡単に使えるようにすることもできるし、
１つのノードを細かく設計して自由度を高くすることもできる。
こういったことをアーティストが目的に合わせて選択して作れるのが、
Reference Controlの最大のメリットです。

この機能を充実させて格段に使いやすくするために機能拡充を行った。
まずアーティストが作りやすいように、ツールのグラフ上で作成できるようにした。
またポート編集機能、並び順やグループ化、使わないパラメータを非常時にする機能を実装した。

さらにベースノードの概念を追加を行い、Reference Controlを使う際にプロパティウィンドウで
中身をノードで選択して動作を差し替えれるようにした。
差し替えるのはプルダウンで選択できるようにして、向きや動きなどもプルダウンで動きを
変化させることができる。結果として汎用性が高い設計かつ扱いやすい設計が実現した。

実現時の課題とその解決方法

実現時の技術的な課題、Luminous VFX Editorにおける解決方法については
シニアプログラマーの長谷川氏が解説を行った。

ノードベースのツール自体は真新しいものでもなく、前例があるので実装は問題なくできるはず
と思っていたが、実際に取り組んでみると『リアルタイム』『エフェクト』を
扱うノードベースツールというのはまだまだ少数だったため、
Luminous VFX Editorの開発時にリアルタイムエフェクト特有の課題に遭遇したそうです。

実装時の課題は、エフェクト特有の寿命の概念と相性の悪さ、
ランタイムを実装する上で重い（メモリ）、遅い（処理）が上げられた。

エフェクト特有の寿命の概念と相性の悪さの問題

エフェクトの要素の大きな特徴となるものは、短寿命と大量がある。
『短寿命』というのは、攻撃がヒットしたときのパーティクルが飛び、数フレームで消えるエフェクト。

『大量』というのは攻撃がヒットしたときのダメージだったり、敵の攻撃のエフェクトだったり、
インジケータもエフェクトなど、画面上にたくさんエフェクトが出ている様のこと。

タイムラインベースでは、エフェクトがどこで生成されて破棄されるのか一目瞭然で分かる。
しかしノードベースのツールだと、
生成と破棄のタイミングがグラフを見ても分からないという問題があった。

重い（メモリコスト）の問題

それぞれのノードにはIDや型、入出力のプロパティ、シグナルリンクで使うポート情報、
どこでノードが繋がっているのかなどリンク情報を持っている。
すると高々１個の足し算をするのに、情報が大きすぎるのでメモリを食い過ぎだという問題があった。

遅い（処理コスト）の問題

画像ではノードの生成処理を書いている。
これを何も考えずにナイーブに実装すると、まずはメモリを確保して初期化してとノードの生成処理がある。
次にノードの持つプロパティ生成に、メモリを確保して初期化しての生成処理がある。
さらにリンクオブジェクトを作って接続してというような処理がある。

数十個以上ノードが生成される処理になると非常に重くなるため、
生成はロード時に行って実行時には行いたくないということが言えるかと思うが、
リアルタイムエフェクトと動的生成の問題もある。

攻撃時に発生するエフェクト要素の数はランダムで決まっているので、
ノードベースのエフェクトツールでは重い、ノード動的生成処理は避けられないことがあげられる。
これが重いと言った問題です。

３つの問題における解決策

ノードの寿命の問題はノードのグループ単位で生成・削除を行い、
寿命管理と生成破棄コスト削減を行っている。これらはライフサイクルが同じようなものしか使えないので、
同じライフサイクルを固めて使うことでまとめて生成・削除を行い、
１回でメモリ確保と解放ができて、開放時のリンク解除が不要にして処理コストを下げてる。

ただグループ単位でノード生成・削除を行うことは問題もあり、
個別にノード生成・削除ができなくなるし、動的にノード種別を決定するような
動的グラフが作れないので柔軟性が低下してしまうが、処理コストのトレードオフとして許容した。

寿命管理は、グループ間で必要な部分の寿命の設定をしている。
残りのノードと全体寿命は自動でシステムが管理してくれるというアプローチをとっている。
それだけでは解決しないので、寿命が目視で分かりやすいようにタイムラインビューを作った。
ノード1本分のラインが、タイムライン形式で表示しているので分かりやすいなった。

データ構造の階層化は、こちらでメモリコストの削減を行っている。
ノードの編集時と実行時で複数個作らずに、必要なデータは必要な部分だけ持とうという考え方です。
プロパティの初期値は編集時ノードでOKなのでコストを下げることができる。
重い処理はロード時に処理をして、あとは差分だけ実行時に構築すればいい。

ノード群の式化、こちらでもメモリと処理コストを下げることをしている。
画像では蝶の出現ロジックの構成しているが、
FF15では朝７時になったら蝶が出現し、１８時になったら飛び去る計算を行っている。
プログラムで書くと簡潔に済むが、ノードで作ると大規模なものになってしまう。

たくさんノードがあるので消費メモリが増えてしまうし、処理時間が増えてしまう。
なので計算を行っている部分だけを、仮想的な計算ノードとして扱うことで１ノードとし、
実行時に消費メモリと処理時間を減らしている。

感想

全体的に開発者向け内容だな。
意味がよく分からない方にも、エフェクト作成作業の熱意くらいは感じとれたかもね。

実際の生のデータを反映させて物づくりをするくらいなので、
やっぱ大手の企業となるとやることがひと味違うもんだな。

ゲームらしさを演出するために、オーバー表現なエフェクトも必要になってくるし、
一方でプログラマー側は使いやすくコストパフォマンスに優れた設計が求められてくる。
一連の操作方法を理解すれば、容易にリアルなエフェクトを作れる点がやはり大きいことなのだろう。
なんかハイクオリティなゲーム制作の裏側を見たような感じの内容でしたね。

初めにLuminous VFX Editorツールの画面を見たときは、
ゲーム開発ツール・Unreal Engineのブループリントという機能みたいなUIだなと思った。

プログラムコードが一切出てこないので、簡単操作でエフェクトを作成できることは
アーティストやプログラマーの作業負担・効率化を上げる要因にも繋がるし作りやすい。

環境や天候に合わせて自動的にエフェクトが変化するように制御されていたのは驚きだったが、
将来的にどこの大手のゲーム会社も、こんな感じのノードで制御して制作することになるのかな。
というか、すでに実践しているメーカーも多かったりもするのかな～
でも中小企業は、さすがにツール開発とかそこまで予算が出るかどうか怪しいか…