「真・女神転生V」はこうやって生まれた！「Unreal Engine」を用いて独特の世界観を生み出した技術の数々が語られる

　アトラスは5月26日、　ゲームエンジン「Unreal Engine（以下、UE）」について学べるオンラインイベント「UNREAL FEST EXTREME 2022 SUMMER」にて、Nintendo Switch用RPG「真・女神転生V」開発事例紹介を行なった。

　本セッションでは、「真・女神転生V」にてリードプログラマーを務めた小山田佳樹氏の考えを交えながら、開発環境の解説・製作に至るロードマッピング、「Unreal Engine（以下、UE）」を用いた様々な技術などを含めたプロ目線の濃い内容が語られた。「真・女神転生V」だからこそ発生したポイント等も合わせて語られ、ゲームクリエイターはもちろん「真・女神転生」ファンにとっても非常に興味深い話を聞くことができた。

「真・女神転生V」開発環境は？ 主に使用したミドルウェアを公開

　まず初めに語られたのは開発環境について。設備状況として、2TB以上のSSD、バージョン管理ツールに「SVN」、「OPTPiX SpriteStudio」や「CRI Sfdec、CRI ADX2」などの主に使用したミドルウェアが公開された。それらをチョイスした理由は、開発作業への“時間の拘束”を最小限に留めるため。UE4を開いて作業開始できるまでの時間や、アセットを開く時間、実機で確認するまでの時間など、これらの時間を短縮することを目的としている。

　今作では膨大なソースコードの管理やコンパイル時間の削減という面から2つのエンジンを用いた開発が行なわれている。手軽で取り回しが容易な代わりにエンジン側のコード修正などの急なエンジン対応が難しいアーティスト配布用エンジンである「InstalledBuildEngine」と、エンジンを修正する度にビルドが常に必要となるため扱える環境が限られる代わりにエンジンの独自改造や拡張を行なえるエンジニア改造用エンジン「SourceBuildEngine」の2つをシチュエーションや作業担当に合わせて使い分ける。そうすることで作業の効率化を図っていたのだ。

　例えば、開発初期の段階であれば頻繁に改造を行なわないことや、サンプル等のやり取りが行ないやすいという理由からアーティスト配布用エンジンで進め、中期から終盤にかけては大規模なアップデートによって発生してしまうコストを鑑みて徐々にエンジンへの直接的な修正を開発するといったような施策が取られている。効率・リスクマネジメント面においても2つのエンジンを使い分ける理由と言うのが明確にわかる。

　また、作業効率を上げるシステムとして、上記で取り上げたソースコンパイル時とシェーダーコンパイル時などで高速化を促してくれる「Incredibuild」をはじめ、ホストPCを1台立ててライトビルドの分散処理を高速化してくれるだけでなく、メンテや設定も簡易なコスパ最強の「SWARM」など、小山田氏のオススメも一緒に紹介された。本セッションでは、このようなゲーム開発における効率化を高めてくれるような即時性のあるシステム、さらには豆知識をトピックとして挟んできてくれるのもうれしい。

エディター設計について。チームで開発するためのルールを決める

　エディター設計においては、エディター内での命名規則は事前にある程度決定しておき、その上でチェックアウトを厳密にルール化しておく。ソースコントロールは常に有効化、プロジェクト設定の変更が許可制などのルールに加えて、作成者の意図がわからない状況を避けるためにコリジョンプリセットのカスタム使用を禁止するなど、ひとえに1つの変更によって大きく環境が変わってしまうことを避けるための様々なルールが最初に決められている。チームプレイとなる開発においては基本的なことながら非常に重要なポイントだ。

　投入されていたエディター拡張機能についてもオススメのものが数多く挙げられている。全悪魔のビュアーかつバストアップSSが取れるショーケースの作成や様々な背景のプリセットを変更できる「EditorUtilityBlueprint」をはじめ、エンジン側からのエディター拡張の例として巨大なヒットを作成した際の視認性を上げる「Box,Sphire」や目視では確認が難しい影の中の隠れた影を判別できるようになる「CastShadow」など、全体的に作業時に見えない or 見え辛い部分を可視化して作業をより効率化することを目的としたエディターの拡張を行なっている。主にエフェクト作成時において重宝する拡張機能となっており、最初に掲げていた「開発作業への時間の拘束を最小限に留める」というポリシーともマッチした効率化を上げる内容となっている。

ベースとなる考えを決めておく。デザイン設計やマテリアル設計

　次はデザイン設計について。最初に触れられたのは製品としてどこまで持って行くべきかのビジュアルショーケースの作成についてだ。ここを決めておかなければ様々な進行が遅れていくため、せめてポストとライトだけでも最初に決めてから動く方がいいと小山田氏は強く提言した。職種に関係なく現実のどんな作業でも、ベースとなる主柱の考えや案を決めておかないと他の事項の決議すら滞ることがあるため、身に染みる話である。

　本作のマテリアル設計は「背景」、「キャラ」、「エフェクト」の3種で分類されており、それぞれにマスターマテリアル担当者がいるイメージだ。オペレーター業務だけで言えば、内部構造を詳しく理解する必要がなく学習コストも低いため、管理コストが低く修正なども行ないやすいという点がメリットとなっている。また、開発中はマテリアルが常に増え続けていくがマスターを修正することで関連するマテリアルにも全て修正が適応されるため、作業効率的にも便利。ただし、様々なマテリアルに影響を与えてしまう特性上、マスターマテリアルの機能が精査されていないと不要な機能を多数持ったマテリアルが生まれてしまうという側面も持っているため、扱う場合には注意が必要となっている。

　また、「使う必要がないものに使われている」というパターンが一番厄介な状況として語られており、視覚的には問題ないように見えるのにシェーダー命令数が想定よりも多いということが発生するという。その解決法としては、最軽量のマスターマテリアルを作成して見た目を変えずに軽量化するという方法がなされている。1つのマテリアルを使いまわし過ぎると発生する自体ではあるが、逆に増やし過ぎてもマスターマテリアルの意味がないので、「通常のフル機能版」と「軽量版」の2つを駆使する今作の方法は非常に理にかなっていると感じる。

キャラクターデザイン設計を紹介！ 「悪魔」を含めた独自のキャラクター制作とは

　キャラクターデザイン設計の紹介の際には、技術的な解説はもちろんながら「真・女神転生V」ならではの「悪魔」を含めた独自のキャラクター制作について語られている。まず、「真・女神転生」シリーズの特徴として、「悪魔」が主軸のゲームになっているということ。デザイン設計のモデルからして、Nintendo Switchのマシンパワーを鑑みるに通常1～2万頂点で制作されるところ、人間キャラが3万頂点、ボス悪魔に関しては3～4万頂点使われているとのことでその気合の入りようがよくわかる。

　アニメーション設計についても「悪魔」のリターゲットは特殊な毛状を持つ存在が多すぎるため、単純なリターゲットでは対応できない。そのため、各形状に合わせた「人型」、「四足型」、「不定形型」といったようなテンプレートを作成した「悪魔」専用のテンプレートなるものが作られているとのことだ。モデル作成時にはテンプレートからABPの適切なものを選びリターゲットを行なうのだが、なにせ形状が変だったり体や顔のパーツの一部がやたら多かったりする「悪魔」も多いため、本作ならではのチューニングは必須。IKに関しても足・頭・眼・上体・浮遊（!?）に対応して調整しているとのこと。これら全てが完備されていることを考えると、これこそまさに「悪魔全書」と言えるかもしれない。

【デザイン設計】

　「悪魔」だけでなく、しっかり人間側のデザイン設計にも力が入っている。紆余曲折を経て採用された物理エンジン「KawaiiPhysics」は、本作ではなんとプレーヤーキャラクターであるナホビノの“髪”のためにピンポイントで採用されているのだ。さらには、一部機能を改造し首IKに対応させてリアクションを入れる、注視する際に気先に行くほど首のうねりを打ち消すロール回転を入れるなど、自然の物理を再現するのではなく、キャラクターのシルエットを優先した調整がなされている。プレイした人間なら誰もが一度目を惹かれたあのサラサラで美しくなびく彼の髪の毛には並々ならぬ情熱が注がれていたのである。

　もちろん他の人間キャラクターもしっかり作り込まれており、顔の表情変化を司るフェイシャルは「AnimMontage」機能で対応し、フェイシャルと口パクのブレンドも可能にしていたりと独自のデザイン設計を駆使して人間らしい表情や感情を表現している。

ブループリントについての利便性について。システム設計で主に使用

　システム設計では本作で主に使用されたブループリントについての利便性について語られる。細かなBP規約をつけないことでお手軽スクリプトの良さを担保しつつも、効率を上げるために必須な検索のしやすさと可視化のために色々な命名規則は設けるやり方を行なう方法をとった。また、論争にもなるC++についても本作ではブループリントが7、C++が3の割合で使用していたとのこと。ゲームロジック部分はほぼBPで作成したが、コアな機能はC++で作成している。

　これらを踏まえた上で小山田氏はデザイナー兼プログラマー、もしくはデザイナー兼プランナーといった複合的な役職となるレベルデザインが可能な人材を育てた方がいいと強く推奨した。かなり幅広い知識と技術が要求されるポジションとなるが、量産フェーズに入った際にかなり重要な人材となるため、探すよりも育成した方が早いとも語る。今回のセッションで語られた内容を全て把握でき、プロジェクト内のアセットを使ってマップデザイン、ゲームデザイン、進行BPの作成を可能とする人材が今後は求められるようになるのかもしれない。