アトラスが語る『真・女神転生V』の開発環境・エンジン設計事例紹介ー効率的なUE4での開発をどのように実現しているか【UNREAL FEST 2022】

『真・女神転生V（以下、本作）』は、株式会社アトラスを代表するRPG、『真・女神転生』シリーズのNintendo Switch向け最新作です。敵キャラクターである悪魔と会話することで「仲魔」として行動を共にすることができるのが特徴のひとつであり、本作では200を超える悪魔が3Dモデルにて表現されています。

登壇したのは、本作のリードプログラマーを勤めた株式会社アトラスのチーフプログラマー小山田 佳樹氏

今回の講演では、アンリアルエンジン（以下、UE）での開発を検討している、あるいはプロジェクト開発が中盤より前である開発者を対象に、UEでの開発事例が紹介されました。処理負荷軽減のためにやるべきことから、組織での開発ならではの作業分担に至るまで多岐に渡る内容となっています。

なお、今回の事例紹介はUE4.23.1時点での内容になります。

最初に、UEで開発を行う際のスタッフの学習コスト、エンジンの保守コストについての説明がされました。

学習期間について、デザインオペレーターであれば数週間〜1ヶ月、コアスタッフであれば数ヶ月は必要となるとのこと。エンジンをプロジェクトにあわせて改造・最適化する場合は、アップデートを自分たちで行う必要があり、改造範囲が増大すればコストも増大していきます。無改造の場合も、エンジンのアップデートで仕様が変わることで、自分のプロジェクトに影響がでたり、SDKの対応具合が変わったりすることもあります。

次に、コストに関する注意を踏まえたうえで、UE4の開発環境をどう構築していったかが紹介されました。本作の開発環境は、メンバーの「時間の拘束」を最小限に留めることを目標として構築されました。具体的には、以下の項目をより効率よく使用できるようにしたとのことです。

本作のUE4開発環境は、アーティスト向けの配布用エンジン「InstalledBuildEngine」と、エンジニア向けの改造用エンジン「SourceBuildEngine」の2つがあります。

ビルド環境を必要としないアーティストは、Visual StudioなどのPCのツール環境に依存しないコンパイル済のエンジンを使用しています。取り回しが容易であるという利点がある一方で、エンジン側の修正が必要になった際、コード修正できないことが課題として挙げられました。

エンジニア向けエンジンは、エンジン自体の独自改造や拡張が可能です。しかし、修正を行う度にビルドが必要となるため、膨大なソースコードの管理とビルドコストがかかってしまうことが課題と説明されました。

開発時期によってもエンジンの使い方が異なり、研究期間ではEpic Games Launcher版で機能確認・検証を行い、開発初期では無改造のInstalledBuildを運用しています。無改造ゆえに、Unreal Developer Network（UDN）で質問がしやすく、エンジン設計のルールもここから徐々に作り始めています。

開発中期では、エンジンアップデートを行ったところトーンマッパの仕様変更で一部の色味が変わったなど既存の作業に影響が出ることがあったため、この時期から「デフォルト設定を変更する」「一部の処理の仕様を前のバージョンに戻す」などの小規模なエンジン改造を解禁するようになりました。

開発の後期では、エンジンへの直接修正も解禁しましたが、UE4のバージョンアップ時のアップデートコストを考え、はじめは影響範囲の小さなものから改造し、バージョンを固定させてからプロジェクトで使用しない機能のオミットやコードへの直接修正をしていったそうです。バージョンを固定する直前のSDKの更新はリスクがあるため、事前にSDKのバージョンも確認しておくことが肝心とのことです。

さらに開発を効率化させるために、ビルドやパッケージングにおいて以下のツールを使用しています。

エディター上での作業を止めないように、自動作成されるパッケージでの実機確認のみとし、Launcher上での確認は非推奨に。プラットフォーム特有の問題などを確認したい時は、当該アセットだけエクスポートして、新しいプロジェクト内で作業する

エディタールール

『真・女神転生V』の開発現場でのエディタールールがいくつか紹介されました。

エディター拡張

プロジェクトを効率的に進めることを目的に、エンジンに影響のないエディター拡張は開発の初期から行われています。また、エディター拡張はデザイナーからの要望によるものが多かったとのこと。

拡張の際にエディターの環境設定-一般-未分類から「UIの拡張点の表示」をONにしておくと、各エディターの拡張用名称がわかるため、ソースコードから検索しやすくなる

Editor Utility Blueprintを用いることで、悪魔のスクリーンショットの作成、背景のプリセット変更などビューポート上での汎用操作の効率化が図れる

さらに、アニメーションビューワー上で指定カメラオフセットに切り替える機能を追加することで、アーティストがゲームをプレイしなくてもLOD調整やミップ確認ができるように、エンジン改造によるエディター拡張も行っています。

レベル構成について

本作では、パーシスタントレベルに含まれるサブレベルは、マップのロード設計のために全て非常駐扱いにしています。

ゲーム中の要素はレベル単位で行うように設計されており、イベント開始でイベントのサブレベルをロード、バトル開始でバトルのサブレベルをロード、施設に入ると施設のサブレベルをロードする、というようになっています。

講演では、パーシスタントレベルを空にするということが強調されました。これは、専用処理をパーシスタントレベルで行ってしまうと、サブレベルを他のパーシスタントレベルに接続させた際に動かなくなってしまい、レベルの流動性に問題が生じるからとのことです。

とあるマップでのレベル構成（担当者ごとにサブレベルを分けている）

全体的なデザイン設計

開発初期に行うべきこととして、キャラクター、背景、エフェクト、ポストプロセス、ライトなどのデザイン要素を1レベルにまとめ、製品としてどこまで持っていくかのビジュアルショーケースを作成することが挙げられました。

この作業によって、デザインのレギュレーションやGPUのバジェットなどが素早く決定できるとのこと。講演内では、ポストプロセスとライトといった全体に影響するものだけでも早めに決めた方がいいと強く勧めていました。

ディファードレンダリングを使用する場合、半透明処理をいれると処理負荷やビジュアル面で色々問題が起こる可能性があるとのこと。デフォルトで入っているポストエフェクトは、アンチエイリアシング以外を切った方が、「どの色が乗っているか」を効率よくチェックできる

マテリアル設計について、本作では、『マテリアルとマテリアルインスタンスの仕組みと問題点の共有 (Epic Games Japan: 篠山範明) #UE4DD』を参考に、マテリアル大量増加を回避するためにマスターマテリアルと子・孫インスタンスでの管理を行っています。マスターマテリアルは「背景」「キャラ」「エフェクト」の3種類に分類されます。

テクスチャの差し替えや既存パラメーターの調整を主とするオペレーターにとって、マテリアルを詳しく理解する必要がないため、学習コスト・管理コスト面で優れている

ただし、マスターマテリアルで必要な機能が精査されていないと不要な機能を多数搭載することになり、描画負荷が発生する

マテリアルを最適化する場合、GPUプロファイルを行ってどこにネックがあるか確認する必要がある

3DCGモデルについては、最初に本作で使用するモデルの頂点数・ボーン数の目安が紹介されました。『真・女神転生』シリーズは悪魔の活躍が見どころであるため、悪魔のモデルのボーン数はパフォーマンスの最大限まで許容されています。人間キャラクターは3万ポリゴン（300ボーン）、ボス悪魔は3万～4万ポリゴン（300～400ボーン）と、Switchタイトルであることを考えると非常にリッチな作りとなっています。

続いて、背景モデルが紹介されました。荒廃した東京を舞台にした超広域マップは、Unreal Engine上でおよそ「4km×4km」のサイズとなっており、他のゲームと比べると非常に大きいとのこと。マップの地形はランドスケープにて作成されており、木や岩などの自然物は、ゲーム的な演出がない限りフォリッジで配置されています。

ダンジョンについては、通路や曲がり角など構成要素がパーツに分解されアクター化されていて、ツールによって配置ができるようになっています。

高速化やメモリ軽減、調整のしやすさにつながるTIPSも紹介された

アニメーションのデザイン設計

本作には200種類を超える悪魔が登場しますが、特殊な形状を持ったものが多く、悪魔のモデルに対して単純なアニメーションリターゲットをかけてもうまくいかなかったとのこと。そのため、形状の特徴からベースとなる悪魔のテンプレートを作成し、そこから各悪魔モデルにセットアップを行いました。

首が8つある「龍王ヤマタノオロチ」や、豹の頭が胸部にある「堕天使フラロウス」など、悪魔の形状は多種多様です。そのため、悪魔テンプレートからリターゲットしても、実際の悪魔の形状にあわせて足、腰、目、踵、上体などのボーンを再設定し、細かいチューニングをする必要があります。

主人公の髪の物理挙動にはKawaiiPhysicsを採用。自然な物理挙動よりも広がる髪のシルエットを優先させるため、毛先に行くほど首のひねりを打ち消すロール回転をいれる改造をしている

ポストエフェクト、ライティングのデザイン設計

ポストプロセスについては、Epic Games Japanが制作したスライドをベストプラクティスとして参考にしたそうです。

LightMassについては、『UE4 Lightmass Deep Dive ポストモーテム』を参考にしています。講演で紹介された本作におけるライトの決め方は以下の通りです。

ポイントライト、スポットライトありきの絵作りをすると、調整コストがかかってしまうので、本作では「松明や証明器具があるから」というような明確な理由が無ければ使用していない

デカールはStaticMeshのみにレンダリングされるようになっている。スライドに掲載されている「鬼女マーメイド」の水面の効果は、床にはレンダリングされるが、岩を含めたキャラクターにはレンダリングされない

UIのデザイン設計

UIテクスチャは基本的にオンメモリで実装しており、シーン遷移後でのみ使うショップなどの施設は都度呼び出しを行っています。

また、ウィジェットブループリント（WBP）でUI制御管理を行い、SpriteStudioでテクスチャとアニメーションの管理を行うことで、プログラマーとデザイナーの作業分割をしています。

後からUIを実装するというプロジェクトでも、処理負荷コストのバッファを取るべきとのこと

ブループリントについて

本作の開発現場では、規約の多さによる動きづらさとスクリプトの良さを消してしまう可能性を考慮して、細かなブループリント規約は作りませんでした。

C++で書くべきかブループリントで作るべきかの問いについては、CPUプロファイルの結果改善の余地があるものはC++化を検討する流れにしたということでした。特に大量のループ処理をするものについてはC++化したほうがよい傾向にあったようです。

プログラマーのコスト低減や作業の高速化のため、プログラマー以外（スクリプターなど）にブループリントを扱える作業者を増やした

BiginPlayとTickは、実行順がどうなるか分からない状況では使用しないほうが安全である

ブループリントの基底クラスはC++化を行い、共通処理を行うオブジェクトはなるべくインターフェース化してスリムにした。本作では、3割がC++で、7割がブループリント。コア部分はほぼC++で、ゲームロジック部分はほぼブループリントで作成された

アセットのリファレンスに関する注意として、ハードリファレンスとソフトリファレンスの違い、リファレンスのメンテナンスの解説がありました。

また、プロジェクト内のアセットを使ってマップデザイン、ゲームデザイン、進行ブループリントが作成できる、レベルデザイナーの育成の重要性もあげられました。

講演の最後に、『真・女神転生V』の開発中に得られたUE上級者向けのTIPSが紹介されました。

『真・女神転生V』の開発における経験からつくられた数多くのTIPSを紹介した小山田氏は「多くの方の情報提供を頂いた結果、今日の開発に繋がっています。UEでの開発において情報収集はとても大事です」と、今回の講演を締めました。なお、講演では本記事で記載しきれなかったTIPSがいくつか紹介されています。さらに詳細な内容についてはぜひ公式アーカイブをご確認ください。

田端 秀輝

「ゲームと社会をごちゃまぜにして楽しんじゃえ」がモットーの、フリーのコンテンツ開発者。節電ゲーム「#denkimeter」やVRコンテンツ、体験型エンタメの開発をしています。モニター画面の中だけで完結しないゲーム体験が好きで、ここ十数年注目しているのはアイドルマスターです。