『FINAL FANTASY VII REBIRTH』会話イベントはカメラもライティングも自動生成されていた。大規模開発で「誰が直すの？」に陥らない、プロシージャル活用の可能性【CEDEC2024】

本講演のスピーカーを務めたのはスクウェア・エニックスの原 龍（はら りょう）氏。『FINAL FANTASY VII（以下、FFVIIと表記）』のリメイクシリーズでアニメーションプログラマーを担当しており、ランタイムアニメーションイベントやカメラ付き会話イベント、アーティスト向け作業環境整備など幅広い役割を担っています。

CEDECでは過去にも複数の登壇経験を持つ原氏。写真はリモートワークを支える愛猫たち

最初のトピックは「会話イベントシステムの再構築」について。リメイクシリーズ1作目となった『FINAL FANTASY VII REMAKE（以下、REMAKEと表記）』のイベントシーンは、アーティスト主導で実装された「カットシーン」とゲームデザイナー主導で実装された「会話イベント」との2種類に大別できます。

講演ではそれぞれの映像が紹介された上で、原氏は両者の間で「映像品質に大きな隔たりがある」ことを指摘。仕組みも工数にも差があるため単純比較できるものではありませんが、それぞれのシーンをシームレスに接続して連続再生されるとユーザー目線ではどうしても気になる要素になってしまいます。

『REMAKE』開発を終えた段階でのポストモーテムでは、アーティストからは「カットシーンと会話イベントの品質差が大きいことによる没入感の低下」が問題として挙げられました。アーティストではなくゲームデザイナーが修正作業を行うことも、指示の伝言ゲームを生み、イテレーション効率を悪くしていました。

アニメーターからは、フェイシャルモーションやボディモーションをシーンのカメラに合わせて設定したにもかかわらず、カメラが変更されていたと悲鳴も

対して同時期のゲームデザイナーからのポストモーテムを見ると、会話イベントはフラグ管理や分岐などゲーム進行に影響を与える仕様が多いため、イベントシーケンス構築や不具合の対応を考えるとゲームデザイナー側での実装が望ましいものであることが分かります。品質を上げたい気持ちはありながらもアーティストに丸投げする訳にもいかない作業でした。

アニメーターから悲鳴があがっていたカメラが変わる問題は、担当者による品質差を出さないために設定した自動カメラが原因。品質差を出さないためのものだったのに、事故が増えてしまった

2桁以上の人数で分担して組み込んでいく環境に一貫した高水準を求めるのも難しく、『REMAKE』では「あちらを立てればこちらが立たない」大規模開発ならではの問題に陥ってしまっていました。

リメイクシリーズ2作目となる『FINAL FANTASY VII REBIRTH（以下、REBIRTHと表記）』では、こうした前作の課題だけでなく、広大なフィールドと多くのサイドコンテンツ実装によってイベントシーンが大量に増えることが既に分かっていたため、開発に向けて量産体制の見直しと品質向上の検討が必要になりました。そこで、まずは現状のワークフローの整理から進めることにしました。

GDC2016の『The:Witcher3:Wild Hunt』を題材とした講演が開発の参考になったとも紹介

『REMAKE』と『REBIRTH』のカットシーンの制作フロー

カットシーンのアセット構成は『REMAKE』と『REBIRTH』で大きな変更は無く、最大限の品質を目指してそれぞれのセクションが専門性を生かして実装していくフローでした。特徴は工数が高く、変更対応の負担も大きいということ。ゲームとのシームレスな接続においては予期せぬ不具合も起こりやすかったそうです。

カットシーンアーティストがMotion BuilderやFlow Production Trackingを使ってレイアウト構築や登録情報の管理を行い、アンリアルエンジンにシーケンサーアセットとしてインポート。そしてシーケンサーのトラック上で、それぞれの専門性に応じてアーティストがエフェクト、ライトなどをブラッシュアップしていく

このフローを踏襲すれば、会話イベントでもカットシーン並みの品質の高さを維持できますが、膨大な数の会話イベント作成への流用は工数面でも管理面でも現実的ではありません。会話イベント用には、実装の手軽さを重視した専用のフロー構築が必要でした。

『REMAKE』の会話イベントの制作フロー

『REMAKE』における会話イベントのアセット構成はカメラが付くか否かで大きな違いはなく、大量のイベントを管理・実装するため実装工数が比較的低いフローになっています。会話イベントはすべてExcelで管理していました。この方法は、検索ツールやエラーチェッカーなども充実している点が特徴です。

ラーニングコストが低いものの、カメラ付き会話イベントを作る上では『REBIRTH』で求める品質には達していませんでした。

『REMAKE』での会話イベントのアセット構成。カメラが付かない会話イベントの工程も含んでいる

会話イベントはゲームデザイナーがExcelでイベントの流れを設計し、CSVで出力してアンリアルエンジンにインポート。『REBIRTH』でもカメラなしの会話イベントでは引き続き使っている

『REBIRTH』では会話イベントの制作フローをどう変えたか

続編となる『REBIRTH』におけるカメラ付き会話イベントの開発に求められている条件は以下のものでした。

この実現に向け、まずは「カメラ無し会話イベント」「カメラ付き会話イベント」「カットシーン」の3種に担当者が分かれていたもののうち「カメラ付き会話イベント」を「ゲームデザイナーが調整作業を行うカメラ付き会話イベント」「アーティストが調整作業を行うカメラ付き会話イベント」の2つに細分化しました。

ゲームデザイナーが調整作業する場合は、映像品質があまり求められず、実装工数が小さいものを担当します。

アーティストが調整作業する場合は、映像品質が高く、実装工数もやや大きいものです。それでいて、ゲームデザイナーが主導して、イベントシーケンスの構築が可能であるものと定義しました。

映像品質は★が多いほど高品質、実装工数は★が多いほどコストが低いことを表しているようだ。ゲームデザイナーが主導してイベントシーケンスを作成できないものはカットシーン扱いとなり、アーティストが調整作業する

定義の見直しによってやるべきことが絞られ、それぞれの解決策も以下のように講じられました。

こうして『REBIRTH』における会話イベント制作フローは以下のようになりました。

上記の流れをフロー図にして、先ほどの表にプロットした図。青がゲームデザイナー作業、赤がアーティスト作業となる。この方法はアーティスト担当作業に移った時点で既にゲーム進行上の接続作業は完了しているため、ゲームデザイナーの手を離れているのもメリット

『REBIRTH』で実装された、会話イベントを例に工程を確認

ここで、ティファとクラウドが魔晄タンクについて会話するイベントを例に、新しくなった会話イベント制作のワークフローを紹介。Excelで設定した流れを実装確認した後、シーケンス化してカメラの動きやライトを自動生成しています。最後に、アーティストが細部調整をしたことで、きめ細やかな演出が活きた表現になっています。

ゲームデザイナーがExcelでイベントの流れを設計。上記チャートの1.にあたる

ゲームデザイナーがゲーム進行に組み込んで、選択肢選択などに問題がないか確認。カメラの動きは付いておらず、カメラ無しイベントの場合はここで作業終了。チャートでは2.の工程

Excelの内容をシーケンサーアセットとしてアンリアルエンジンに取り込むと（左）アンリアルエンジン上でカメラやモーションを調整できる状態に。自動生成によってカメラやモーションを出力し、良さそうならOK、イマイチなら再ジェネレートを繰り返す（右）。チャート上の3.の工程

アーティストがさらに手動で調整を加える。表情の変化やカメラワークなど細部にわたって調整がされている。チャートの4.にあたる工程

更に多人数が同時に登場するイベントシーンについても、ほぼ自動生成で完結しているパターンとすべて手動調整で実装された例を紹介。アーティストによる調整が可能になったことでカットシーンと比較しても大きく見劣りしない映像も実現しており、『REMAKE』での課題を見事に解決しています。

続いて講演は実装までに使用したツールの紹介へ。まず最初に取り上げられたのはカメラ付き会話イベント編集環境である「Dialogue Editor」です。シーケンサーのプレビューや編集だけでなく、ショットの自動生成に加えてボイスやイベントトリガーの追加・削除などショット情報の変更も可能です。

独立したプレビュー環境のため、確認したい際に背景やエフェクトの読み込み待ち時間が発生してイテレーション効率が低下する現象を防げるのも大きなポイント。背景がある状態でできるオプションも搭載

「Dialogue Editor」の登場により、『REBIRTH』の会話イベントのアセット構成はそれぞれ以下の図のようになっています。

カメラ無し会話イベント

カメラ付き会話イベント（自動生成）

カメラ付き会話イベント（手動調整）

また、カメラ・モーション・ライトの自動生成に使用するジェネレーターは繰り返し“シードガチャ”をするだけでなく、ショットごとの細かな切り替えも可能。イベント内容に合わせて、アングルなどに制限を加えたい場合は使用するジェネレーターを変えることで出力をコントロールしています。

ライトの距離、モーションに移動を含めるか否か、カメラアングルなどはジェネレーターの変更が可能

このブループリントはシーケンサーアセットにベイクする際に使用するもので、ロジックを調整した場合でもベイク済みのシーケンサーアセットには影響しないという利点も

ジェネレーターはブループリントの継承を使って親子関係を作ることも可能です。

親となるロジックを定義したジェネレーターはアニメーションプログラマがアーティストからリファレンスとなる動画を受け取り、それに沿ったロジックを考えて実装。その後の派生先のジェネレーターはアーティストがプリセットを増やすことも可能で、プログラマとアーティストによる共同作業になっています。

実際にジェネレーターによる自動生成を実行する場合、カメラ・モーション・ライトでは工程が前後することもあり、それぞれ2回のPassを通します。

1st Passでは立ち位置は仮で、モーションを決定。2nd Passで1st Passで決まった内容に沿って生成する

肩越しショットを例にジェネレーターによる自動生成の過程を詳説

先ほど紹介された、自動生成による肩越しショット。このようなショット作成の流れを見ていく

カメラ

1st Passではフォーカス対象となるキャラクター（デフォルトでは話者）を確定させ、カメラアニメーションプリセットと立ち位置プリセットを確定させます。

被写界深度などもフォーカス対象を参照してベイクされるため、適宜手動調整が必要

2nd Passでは、フォーカス対象キャラクターの頭の位置からの相対位置でカメラを設定します。そのままでは頭が画面の中央に来てしまうため、三分割法で適切な写り方となるよう、カメラの位置を平行移動させます。これでカメラの基本位置が決まるため、周囲のキャラクターのバウンズ範囲を参照して邪魔になってしまう人物を移動させるなどの処理を行い、キャラクター位置も調整。

フォーカス対象が移動する場合にはカメラも追従するが、聴者がフレーム内に映り込んでしまうことも多いため「対象と聴者とカメラによる三角形の位置関係を維持するようにしながら回り込ませる」という解決法も

ライト

汎用ライトの自動配置ロジックもカメラの場合と同様に、ショットにおけるライトフォーカス対象キャラクターを確定させ、カメラ位置とフォーカス位置から確定したライトプリセットに合わせて4つのスポットライトを当てるという手順を踏んでいます。ライトもカメラ同様に追従設定が可能です。

メインとなる前方斜め上の「Key」、影を柔らかくするための「Fill」、輪郭を出すための「Back」の3灯照明と、ハイライト用の「Eye」を組み和わせた4種類のスポットライトを自動配置している

イマジナリーラインを考慮したカメラアングル

イベントシーンのカメラアングルについてはイマジナリーライン（※）を超えないカメラ移動の制御も必要になりますが、3人以上のキャラクターが向かい合って会話をするシーンの自動生成カメラでは破綻が起きやすい複雑な処理になってしまいます。そのため『REBIRTH』ではキャラクターをグループ化したイマジナリーラインに置き換えて対応しています。このときのグループ化は「パーティキャラクターか否か」が基本的なルールとなっています。
※　対話者の間を結ぶ仮想の線。映像制作上の基本原則で、この線を超えてカメラの移動や編集をしてはいけないとされている

グループ化する際、パーティのメンバーがいなかった場合などどちらかのグループしか存在しなかった場合は一人だけ別グループに

条件分岐発生時のショット遷移

ショットの冒頭ですぐに条件分岐が発生し、次のショットへと遷移するようなシーンでは、最初に1フレームだけ不必要なショットが表示される不具合が起こってしまいます。これを防止するため、事前にセクション情報を収集して次のシーンを先読みする処理を実行し、セクション実行以外のタイミングでも遷移の制御ができるようにしました。この分岐予測によって次にジャンプするショットが予測できれば背景の先読みストリーミングも可能になり、カットが変わる瞬間のフレーム表示防止にもつながっています。

予測した分岐後のカメラをAddViewSlaveLocationで登録し、先読みしている

先読み処理を行わなかった画面のコマ送り比較。ストリーミングが間に合わなかった左上部分の背景が1フレームで大きく変化してしまっていることが分かる

イベントの演出はワールドの絶対座標ではなく、レベル配置時の再生基準位置との相対位置で再生を行っています。そのため、カメラの映りが悪い場合などは背景位置をずらすのではなく、再生基準位置をずらすことで調整が可能です。

「キャラクターの位置が変わるとカメラやライトとの位置関係が変わって破綻してしまうのでは？」と思うかもしれませんが、キャラクターが移動した分だけカメラやライトにも同じオフセットをかけ、キャラクターとの位置関係が変化しないよう工夫しています。

地形に調整が入る前提での設計のため、シーケンサー再生時にはカプセルの接地やIKでの補正は基本的に有効にしている

シーケンサーで行った処理負荷軽減

また、昨今のゲームは映像表現の進化や広大なフィールド表現などによって物理メモリが足りなくなることは珍しくありません。『REBIRTH』の開発においてもそうした問題を回避するために「不必要なアセットはなるべく読み込まない」という地道な対応を重視しています。再生されるかどうかがまだ確実でない会話イベントはシーケンサーアセットを事前に読み込まず、メモリに常駐させないという方針を基本としました。

プレイヤーが会話イベントを開始した場合、その一言目はシーケンサーの外でカメラ無し会話イベントとして再生します。その間に、シーケンサーアセットの非同期読み込みを行うことで二言目からカメラ演出を開始しています。これによってメモリ使用量のピークを抑えつつ読み込み待ちの時間も無くしています。実は『REBIRTH』の会話イベントはほとんどが二言目からがシーケンサーになっているそうです。

魔晄タンクの会話シーンはプレイヤーがティファに話しかけて始まる。最初のセリフはシーケンサー外で再生している

シーケンサーのローカライズでの応用例

『REBIRTH』では、日・英・仏・独の4言語でボイスが収録されています。このローカライズ対応もシーケンサーで行われています。

通常、言語が変わるとボイスごとの尺が変わるため、日本語ボイスの尺に合わせたモーションやカメラワークがずれてしまうという不具合が起こりがちです。

カットシーンではローカライズチームが日本語の尺に合わせて海外原語の尺を調整する工夫をしていますが、会話イベントは数が膨大なため尺合わせはしない方針となりました。そのため『REMAKE』では海外言語の方が尺が長くなってしまう問題への対処として、尺に合わせてシーケンサー全体の再生速度を調整することで解決・対応しています。

ドイツ語は尺が長くなりがち。ボイスの開始・終了タイミングが一致するように再生速度を変更している

シーケンサーのベイク処理や実行時の流れ

シーケンサーへのベイク処理については「Unreal Engine Meetup in Nagoya Season2 Vol.1」にて実施された岡田和也氏の講演「猫でもわかる UE5 シーケンサー自動生成！」の資料が非常に良くまとまっているものとして紹介しました。

また、ここまで紹介されてきたシーケンサー関連の処理がどういった流れで実行されているかも明らかにしました。

ランタイムで使用するシーケンスプレイヤーは会話イベント向けに拡張している

『REMAKE』の開発で生まれた課題の解決策として生み出された『REBIRTH』の会話イベント制作フローでしたが、ポストモーテムでは特定のショットだけカメラやモーションを調整した例も含めると、最終的に約9割のイベントでアーティストによる手動調整が行われていたことが発覚。

今後は更にジェネレーターを増やしていくことで改善の見込みがあるのではないかという見方も示し、「個人的には悔やまれるが工数削減には貢献できていたのではないか」と振り返りました。

音声から感情解析をしてキャラクターの表情へ反映させるフェイシャルにおける仕組みはできているため、今後は解析された感情をカメラやモーションの選出条件に加えるなど更に検証していきたいとのこと

また、シーケンサー変換を行った後に生成元データが変更された場合、対応事項が多くなってしまったことも反省点として挙げられました。特にUI表示関連でのオプション機能追加などで既存のコマンドが拡張された場合、従来はExcelの書き換えだけで済んでいたものがシーケンサー上での対応が必要になってしまいました。こちらについては、イベントシーケンスに関わる内容はシーケンサーに変換した後もゲームデザイナーがExcel上で編集作業ができる構成に変更し、対策しました。

改善後のアセット構成。変換後もExcel上のデータは捨てずにシーケンサーから参照することで調整作業がExcel上で可能に

ロジックなどに合わせてキャラクターやカメラの自動配置が可能なプロシージャル配置ツールは、大規模開発ではゲームデザイナーが仮配置と接続を済ませてアーティストへとブラッシュアップ作業を引き継げるなど「各セクションの作業タイミングに依存させない」環境を実現できる利点が大きいと、原氏は解説しました。

アーティストとしても実際に組み込まれて動いているものを見てブラッシュアップ作業に取り組めるのでイメージの共有がしやすく、後から処理負荷の調整がしやすいのも大きなメリットです。特に『REBIRTH』では30fpsの「グラフィックモード」と60fpsの「パフォーマンスモード」が選択可能になっているため、処理負荷の対策は大いに役立ったとのこと。

配置機能を兼ねる群衆アクターに「個体数を割合で減らす」オプションを追加することで、状況をプロファイリングしながら数を減らして負荷の調整が可能に。アンリアルエンジンでの実装にはアクターとして取り回しができるConstruction Scriptが便利であることも紹介

「Skeletal Mesh 群衆配置ツール」で群衆描画時のCPU負荷を削減

『REBIRTH』の開発ではプロシージャル配置ツールのひとつとして、密度などのパラメータに応じてボリューム内にSkeletal MeshをAddComponentしていく「Skeletal Mesh 群衆配置ツール」を作りました。複数種類のモーションを登録しておくことでゲーム進行に応じてイベントトリガーから演技内容を変えることも可能で、MasterPoseで群衆を制御すればCPU負荷削減にもつながります。

同じ骨構成かつ同じポーズであれば、群衆の中の「親」個体のBone Transformsを参照することでEvalutateが不要になり、負荷削減にもつながる

MasterPoseを活用した負荷軽減についての解説。デフォルトのままでは親の更新有無に関係なくMarkRendarDynamicDataDirtyのフラグが立ちDraw負荷が上がる。RefleshSlaveComponentsで無視するようエンジン拡張を推奨

軽減に取り組んでもまだ負荷が高い場合には、画面端やカメラから遠い位置など動きが少なくても気にならない群衆はSkeletal MeshではなくInstanced Static Meshで一度に描画してしまうなど、更なる工夫が必要です。実際に『REBIRTH』の作中でも負荷が厳しいカットシーンではStatic MeshとSkeletal Meshのどちらも使用できるよう群衆をセットアップしておき、カメラカットに合わせてイベントトリガーから状態を切り替える制御を行っています。

「VAT群衆配置ツール」で群れの動きを作る

群衆配置ツールではVAT（Vertex Animation Texture）でループアニメーションしているStatic Meshをパラメータで指定して動きを作る「VAT群衆配置ツール」も活用されており、こちらはゲーム内に登場する「フィーラー」が魚群のように集まる表現で主に使われています。

群衆アクターで動きを作る際は「周期の異なる2つの波を重ね、周期と移動幅にランダム係数をかける」という手法が一般的で、これだけでも適度なばらつきが生まれる

Static MeshをVATによる頂点アニメでループ再生させて群衆配置ツールで動きをつけていく仕組みになっており、こちらもInstanced Static Meshを使って一度に書くことでDraw負荷を下げています。インスタンスごとのカリングはされないため、遠いインスタンスは機能側で数を減らすなどの対応を採っています。

スプラインの周りを周回する竜巻表現

群衆アクターのランタイム更新

ランタイム更新は、まず群衆に関するContextの更新を行う「Actor Tick」、次に最適化に関するContext更新を行う「Optimize Tick」、最後に更新されたContextを参照してインスタンスの座標更新や増減を行う「Post Tick」の3つで行っています。

『REBIRTH』にはフォトモードがあるため「Optimize Tick」はゲームポーズ中も実行され、カメラ外での処理を行っている

従来の音素解析から機械学習ベースに更新したリップシンク

スクウェア・エニックスは社内で機械学習によるリップシンク「Lip-Sync ML」を開発しました。『REMAKE』での音素解析ベースから『REBIRTH』では機械学習ベースに完全移行できたことで不具合なく運用できたことが紹介されました。従来の音素解析と新手法の機械学習が動画でも比較され、特に新たな手法では海外言語でもしっかりとした口の動きが作られていることがあわせて確認されました。

Lip-Sync MLについてはCEDEC2022での講演資料も参照

アンリアルエンジンの標準機能になった「Control Rig」への差し替え

CEDEC2020では『REMAKE』の開発にあたってエンジン内に独自のリグの作成ツールを実装したことを紹介する講演も行われましたが、アンリアルエンジンの標準機能になったことで『REBIRTH』では独自ツールはオミットし、機能をノードとして移植する形ですべてControl Rigでの制御になっています。

Control Rigはキャラクターごとに作られていますが、人型のキャラクターが多いこともあって共通で利用するものを用途に合わせて3種類作成して使い回す運用も行われていました。

『REBIRTH』の開発で特にControl Rigについてブラッシュアップされた点のひとつがモーション中に足滑りが起こらないよう固定する「Foot Lock」です。Foot Lockは汎用的に使えるオプション機能として実装されており、独自の「Foot Control」と標準の「Position Based IK」という2種類のノードを組み合わせ、ロックした座標にコントローラーを固定する制御を実現しています。

実際にFoot Lockを活用しているエネミー。体が大きく旋回すると足滑りが目立ちやすいが、歩行モーションにNotifyを設置してFoot Lockされることで対策している

Foot Lockは「Look At」との組み合わせも相性が良いです。物体を目で追う動きでは多少腰が動くモーションが自然ではあるものの、補正がないと腰の動きにあわせて足が滑ってしまいます。そのため、Look Atで補正を行う前に足のボーンをコントローラーの位置に戻すことで自然なLook At表現を行っています。そのほか、加算ダメージ表現で腰から動かすような表現においてもFoot Lockの制御が活用されています。

また、『REMAKE』の開発でも用いられた位置ベースの物理シミュレーション「Position Based Dynamics」は『REBIRTH』でもControl Rigで汎用的に利用できるようノードとして実装されています。これは、汎用ノード以外にも、吊り橋の表現など共通して実装に活かせるものに特化した専用ノードの作成で活用されています。

会話イベントシーンのワークフロー改善を中心に、自動生成のポイントや使用ツールなど多岐にわたる内容で『REBIRTH』の開発の裏側が解説された本講演。カットシーン以外でもリッチな表現が求められる開発環境において、品質を担保しながら多数のイベントを作り上げていくための知見が詰まった内容となりました。

ハル飯田

大阪生まれ大阪育ちのフリーライター。イベントやeスポーツシーンを取材したり懐ゲー回顧記事をコソコソ作ったり、時には大会にキャスターとして出演したりと、ゲーム周りで幅広く活動中。
ゲームとスポーツ観戦を趣味に、日々ゲームをクリアしては「このゲームの何が自分に刺さったんだろう」と考察してはニヤニヤしている。