『FINAL FANTASY VII （以下、FFVII）』完全リメイク3部作の2作目として、『FFVII REMAKE（以下、REMAKE）』から4年を経てリリースされた『FINAL FANTASY VII REBIRTH（以下、REBIRTH）』。

前作と地続きでありながらPS5のパワーによってさらに微細に描き出される本作の開発について、CGWORLD本誌掲載分4回にディレクター浜口直樹氏のインタビューを加えた全5回で紹介していく。

広大なワールドマップを現代の技術でどう描くか

CGWORLD編集部（以下、CGW）：前作『REMAKE』の開発完了後、『INTERGRADE』を挟んで『REBIRTH』のリリースとなりました。まず、本作のグラフィック面でのコンセプトやテーマについてお聞かせください。

浜口直樹氏（以下、浜口）：前作はミッドガルを舞台にした冒険でした。ミッドガル自体は過去の『FFVII』コンピレーション作品の中である程度密度をもって描かれてきたため、そうした“思い出”をいかに現代の技術でリアルに表現するかが前作のグラフィック面のコンセプトでした。

浜口：今回の『REBIRTH』はワールドマップを実現する必要がありました。原作ではポリゴンの粗い表現だったワールドマップを、現代の技術でどのように描くかが課題でした。ユーザーに「こんなふうになっていたんだ」と思ってもらえるよう、『INTERGRADE』の開発と並行して各地域の植生や生態などを設定し、ワールドマップのエリアごとの特徴をつくり上げました。

今回、グラフィック面で最もこだわったのは、画面内に表示されるアセットの密度や量を前作よりも増やすことです。

PS5の優れたSSDを活用し、必要なアセットを必要なときにだけ読み込む描画設計にしました。ハードディスクをベースとしていた頃のゲーム開発では、プレイヤーの周囲360度を全て読み込んでメモリに載せるアプローチが主流でしたが、今回はカメラに見えている範囲のみを読み込むことにより、見えている範囲内のアセットの密度を高めることを意識しています。

『INTERGRADE』の開発と『REBIRTH』の立ち上げを同時並行

CGW：開発はどのようなながれで進行したのでしょうか？

浜口：『INTERGRADE』は“『REMAKE』のPS5版を1年で届けよう”というテーマで開発していました。そこで、PS5での開発経験を積むために、『REBIRTH』の立ち上げと並行して進めました。『INTERGRADE』の開発が終わる頃には『REBIRTH』の開発環境も整っていたため、スムーズに進行しました。

CGW：『INTERGRADE』の開発を通して『REBIRTH』の開発環境を整えていったのですね。

浜口：そうですね。ただ、『INTERGRADE』のアセットは前作時点のものなので、『INTERGRADE』の開発環境をそのまま『REBIRTH』にもち込んだというよりは、そこで得た知見を基に『REBIRTH』の開発環境を構築したという言い方が正確ですね。『REBIRTH』の開発には実質4年かかり、その最初の1年は『INTERGRADE』と同時並行で環境を整えたり、ゲームの方向性を決める試作的な期間でした。

CGW：開発チームの編成については、前作から大きな変化はありましたか？

浜口：編成は大きく変わっていません。前作の開発で指示系統が明確になっていたため、その状態で開発を開始できました。新型コロナ禍でリモートワークを強いられましたが、前作の組織体制でそのまま進められたので、比較的しっかり回っていたと思います。

CGW：開発ツール面ではいかがでしょうか？

浜口：今回はエフェクトをNiagaraベースで制作した点がひとつ大きく変わったところですね。最初はデザイナーも自由に触っていたのですが、負荷に顕著に影響が出るため制約が増え、最終的には現実的な使用に落ち着きました。

また、UE5をベースにしたという点では、コントロールリグ周りも書き換えて利用しています。加えて、キャラクターやモブのアニメーション数が増えたことでメモリを圧迫していたので、UE5.3からAnimation Compression Libraryというプラグインをわれわれの開発環境にマージして、アニメーション関連のメモリを改善しました。

CGW：前作ではリビジョン管理にSVNを使用されていましたが、本作も同様でしょうか？

浜口：そうですね。中にはPerforceを使いたいという声もありましたが、今回SVNで開発したのには理由があります。われわれは100人以上の規模で開発を行なっていますが、プロジェクト開始時に完全リモートに切り替わり、会社に来られない状況になりました。

そのタイミングで基盤となるツールを変えるとなると、何か問題が発生したときの対応が難しくなる。それならば実績のある同じ環境で進めた方が良いと判断し、SVNを選択しました。

実際、SVNが大きなボトルネックになっていたわけではなく、このタイミングでツールを変更するよりも、現状を引き継いだ方が開発チーム全体のパフォーマンスを高く維持できると考えました。一部ではPerforceへの乗り換え要望もありましたが、SVNを使用する方針に決定しました。

膨大なボリュームに対応する様々なしくみづくり

CGW：ありがとうございます。次に、具体的な開発のながれについてお伺いします。それぞれのパートのつくり方の変化については別途伺っていますが、ディレクターとしてチェックフローの変化などはありましたか？

浜口：大きな変化はありませんが、今回は広いワールドマップと、メインストーリーに加えてオープンワールドでの自由なゲーム体験を提供するデザインだったため、チェックがとても大変でした。チェックしてもチェックしても、まだ確認することがあるというしんどさはありましたね（笑）。

開発期間中、特に中盤から終盤にかけては重点的に通しプレイをくり返し、「ここはこう直してほしい」「もっとこういう機能を入れてほしい」とやり取りを重ねました。今回はおそらく30往復以上はプレイしたと思います。1回の通しプレイで全部の要素を確認しようとすると100時間以上かかってしまうので、毎回テーマを決めてプレイしていました。今回はメインストーリーの確認、次はサイドコンテンツ、次はワールドレポートを埋めながら……といった具合です。通しプレイにも工夫が必要でした。

これまでなら、基本的にはメインストーリーを追うということで比較的チェックしやすかったのですが、今回は物量が多いため、開発メンバーも確認が大変なんです。それぞれの担当者は自分の関わっているパートをプレイしますが、全体をプレイするのは難しいため、私が日々通しプレイを行い、それを動画にして開発チーム全体に共有していました。実況配信のようなイメージで、仕事しながら横で流しておくだけでも、開発の進行状況がわかります。

しかし、私1人では1周するのにも時間がかかるため、後半からはQAテスターに通しプレイを定期的に動画で上げてもらい、開発全体のチェックのやりやすさを改善しました。

CGW：ゲームプレイだけでなく、シネマティックのボリュームもすごいと思いますが、そのあたりのチェックも大変そうですね。

浜口：私はシームレスイン／アウトにこだわるタイプなので、ゲームに戻る瞬間にキャラクターが少しでもピクついたり、ライティングが変わったりするのが気になります。「ここがピクついてます」「ライトが不自然に変わってます」といった修正要望をよく出していました。

ただ、ライティングは開発後半に進むので、画づくりのチェックを開発中盤に行なってもあまり意味がないんです。カットシーンのつなぎやモーションのピクつきといったテクニカルな部分は中盤でも確認できるので、開始部分とフィールドにつながるアウト部分だけをチェックできればいい。そこでチェック時間を減らすために、カットシーンの中盤部分だけ倍速再生する機能を導入してもらうなど、様々な協力を得ていました。

この機能は『REMAKE』開発時につくってもらったもので非常に役立っていましたが、続編の環境では機能しなくなっていました。「必要なので復活させてほしい」と要望を出したので、もしかしたら開発スタッフも使っていない、あるいは知らない機能かもしれませんね（笑）。

つなぎ部分だけを確認したいというニーズは『REMAKE』のときから変わりません。ゲーム速度を倍速にする機能もありますが、カットシーンの終わりで倍速をOFFにするタイミングを逃すと、つなぎのチェックができずにながれてしまいます。そうなると同じカットシーンをもう一度見直すことになり、時間の無駄です。そのため、システマチックに中間部分だけ倍速再生にするようお願いしています。

オープンフィールドを構築する上での配置・最適化の苦労

CGW：ワールドマップが本作の大きなテーマのひとつだったとのことですが、オープンフィールドになったマップはどのように開発を進められましたか？

浜口：『REMAKE』もそうですが、われわれのチームが開発してきたタイトルでは、キャラクターの立ち位置によって「ここからはあの塔は見えないはずだから読まない」など、どのアセットを読み込むかをデザイナーがコントロールしていました。『REMAKE』のようなシーケンシャルな展開では、この方法が上手く機能していました。

しかし、今回のように広大なフィールドになると、どのタイミングでどれだけのアセットが読み込まれていれば画が成立するのかを人間がコントロールするのは難しくなってきます。そこで、デザイナーがアセットの読み込みを意識しなくてもマップをつくれるように、まずプログラマーにそのしくみを構築してもらいました。具体的には、キャラクターの立ち位置に基づいて読み込む範囲を自動で調整するというものです。

このしくみを早い段階で導入したことは非常に大きかったです。もちろん、本当に「こことここが同時に読み込まれたらメモリに入りません！」といった問題が発生した場合には、ENV班に相談することもありました。

CGW：そうしたしくみ自体はUEに備わったものではなく内製したものだと思いますが、かなり影響範囲が大きく、規模も大きいものですよね。この取り組みは『INTERGRADE』と並行して準備期間中に進められたものなのでしょうか？

浜口：そうですね。UE4に標準で備わっているレベルストリーミングやワールドコンポジションは使わず、独自に空間管理や読み込み管理をしています。このしくみは基本的に最初の1年で構築されたものですね。

担当したのは『FFXV』でも同じ領域を手がけていたエンジニアで、彼には「こういう風にデータをもてばこういう風にいける」といった実績と算段がありました。そのため、彼にその部分を一任し、早い段階で実装してもらったので非常に助かりました。

ただ、背景は単にモデルを読み込むだけではなく、コリジョンやナビメッシュなど、様々なアセットに紐づいた情報も読み込む必要があります。その際、データをUEに取り込むとメモリが急増したりスパイクが発生するなどの問題が多発したので、ベースの設計よりも、実際にUEで動かすときの調整にかなり苦労があったようです。

CGW：ENV班へのインタビューでは、「古代種の神殿」でもそのあたりの苦労があったと伺いました。

浜口：UEではスケルタルメッシュの数が増えるとCPU負荷が上がりやすい傾向があります。「古代種の神殿」はマップ自体があちこち動くため、ダンジョンの全オブジェクトがスケルタルメッシュに近いもので構成されており、描画負荷以上にCPU負荷が大幅に上昇しました。

そこで、スケルタルメッシュの数を減らすために最適化担当を1人配置し、実装状況を監視しながら「これとこれは同一メッシュにして」「スケルタルメッシュが増えてきてます！」といった対応を行いました。他のマップでは背景物がそれほど動かないため、これまでの設計で上手く動いていましたが、「古代種の神殿」は特殊ケースでした。

ただし、本当に最適化が難しいのはグラフィック的なポリゴン数が多い場合です。例えば、森のように木が多くポリゴン密度が高いエリアでは終盤まで負荷との戦いが続き、最終的にはアセットのリダクションで対応することになります。「古代種の神殿」の場合はCPU負荷だったので、プログラマーの技術で落としどころを見つけることができました。

CGW：アーティストだけでなくプログラマーもグラフィックのレベルを引き上げるのに大きく貢献していることが窺えます。前作同様UEをベースにしつつ、大規模に独自実装しておられるのが印象的ですね。

浜口：はい、UE4をベースにしつつ、独自実装を進めるのは意図的な選択でした。『REMAKE』ではできるだけ既存の環境を活用し、スピーディに開発を進めたかったんです。また、新しい技術については、Epic Games側の開発スケジュールに合わせるとリスクが高くなることがあります。例えば、安定性が不十分な状態でマスターを作成しなければならないことも考えられるため、リスクを避けるためには、自分たちで独自に開発する方が安全だと判断しました。

そのため、『REMAKE』の後には「次もUE4をベースにしつつ、必要な機能は独自に開発する」という方針を早い段階で決めていました。このアプローチにより、独自に開発した部分も高品質に仕上がり、次につながると考えています。

CGW：次作に向けての開発環境のUE5へのアップグレードなどは検討されているんでしょうか？

浜口：エンジンの良し悪しを見極めながらにはなりますが、検討は可能だと思います。これは「SVNからPerforceに乗り換えるか」といった検討と同様です。

ただ、いまユーザーの皆さまが最も求めているのは、なるべく早くシリーズ完結作をいいかたちで届けることだと思います。環境を変えることでそれが加速するのか、それとも現状のまま一気に作る方がベストなのか、その点はフラットに考えて判断しようと思っています。

CGW：ありがとうございました。

（2）キャラクター制作編に続く＞＞