エピック ゲームズ ジャパンが主催するUnreal Engineの公式大型勉強会「UNREAL FEST EXTREME 2021 WINTER」が、11月1日（月）～6日（土）に渡り開催された。ここでは11月1日の株式会社ジーンによるGAME講演「『聖剣伝説3』スマートフォン版におけるUE4アプリ開発事例～Making of Mana～」の模様をレポートする。
TEXT＿石井勇夫 / Isao Ishii（ねぎぞうデザイン）
EDIT＿小村仁美 / Hitomi Komura（CGWORLD）、山田桃子 / Momoko Yamada
スマートフォン版開発にあたって～アーティスト編～
2021年7月にスマートフォン版がリリースされた『聖剣伝説3 TRIALS of MANA』。本作はスクウェア・エニックスの人気アクションRPG『聖剣伝説』シリーズ3作目のリメイク作品であり、2020年4月にPC／家庭用ゲーム機版が発売されているもののスマートフォン移植版だ。
『聖剣伝説3 TRIALS of MANA』ファイナルトレーラー
スマートフォン版への移植に必要だった最適化や、プラットフォームへの対応について、株式会社ジーンの3Dアーティスト植本修平氏とプログラマーの柿本恭兵氏よりプレゼンテーションが行われた。
講演はアーティスト編とプログラマー編に分けられて進められ、前半のアーティスト編は3Dアーティストの植本氏が登壇。この講演では、エンジンの機能を使った最適化などの話が中心のため、基本要素を把握している人対象となり、実例の紹介がメインでSoCなどの端末側には触れないとのことだった。
プロジェクトはPC／家庭用ゲーム機版（以下、CS版）の開発終了後からスタートしたが、CS版の開発時点ではスマートフォン版（以下、SP版）を意識したデータ設計になっていないため、モバイルでは使用できない機能や処理負荷が高いものがあり、それらをどのように移植、最適化していくかが課題だった。
大きな方針として、グラフィックスはCS版の完全再現をねらうのではなく、SP版として満足できる程度を目指すことと、街、ダンジョン等の数が100近くあるなど3Dの物量が多かったためアセット単位での調整は抑えるということが定められた。
▲プロジェクトについての指針
具体的なスマートフォンでの変更点や最適化
SP版での変更点を挙げていくと、まず、レンダリング方式をディファードからフォワードに変更した。使用できる機能の制限はかかったが、GPU負荷はかなり下げられた。
続いて、アンチエイリアシング方式をTemporalAAからMobileMSAAに変更。スマホの画面は小さいので、より鮮明になった。
アウトライン表現は深度比較メインにして、ポスト処理のみにした。フォグは、ゼロからの開発ならともかく、移植のためにモバイル用に設計し直すのは高コストのため、実装をポスプロからマテリアル側へ変更して対処した。表現としてはモバイルとして遜色ない出来だという。
▲SP版でも満足いく表現が可能
その他、影をinsetShadowからCSMへ変更したり、1Callについて75以上のボーンが使用できないためにマテリアルを分割するなど、多くの変更があった。
▲ボーンが多いキャラクターのマテリアル分割例
一方で、疑似物理プラグインKawaiiPhysics + AnimDynamicsを使った揺れもの系はSP版でも違和感がなかったため、そのまま使用された。
GPUの最適化についてはモバイルフォワードへの移行でだいたい処理内に収まっていたため大きな問題はなかったが、CPUがネックになることが多く、対象端末のスペックからドローコールが1,000～1,200前後になるように調整がされた。
CS版ではハードウェアオクルージョンカリングにより作業者が気にせずともある程度のカリングがされていたが、SP版では使用できないためステージの最果てまでのオブジェクトが全て描写されてしまっている場合もあった。
▲遮蔽が多いマップでは、カリングが効かないとひどいときは3~4倍のドローコールが発生した
対策としては、距離カリング、ソフトウェアオクルージョンカリング、マージ、インスタンス化、HLOD化などを検討した。距離カリングはある程度の対応はできるが、一括設定ができずアセット単位での細かい調整が必要でこれのみの対応では限界があった。
▲SP版では距離カリングが有効だが、注意が必要
ソフトウェアオクルージョンカリングは特定アセットのLODを指定して使い、壁が多いMAPでは有効で、調整次第ではCS版と同等のカリングができた。マージは安定した効果があり、ヒューマンエラー対策もありできる限りプレイヤーが干渉しない遠景で使用した。インスタンス化は効果的に設定が難しいため、要所だけで使用。HLODは求めていた機能だが、メモリに余裕がないことと作業イテレーションの都合で本プロジェクトでは見送られた。
メモリは動作端末の半分程度を目安に設定されている。テクスチャのフォーマット、ライトマップの縮小、マテリアルの軽量化などの対策だけで、メモリオーバーはせずにプレイ可能となった。
しかし特定のイベントではメモリオーバーが発生したため、ゲーム側の設計ではなく、アセットリダクション、背景のLODの削除、マージでリソース削減などのアセット単位での対策で対応した。
各種対策についてのまとめとリモートワークでの開発の難しさ
グラフィックス表現に関するCS版からSP版への置き換えは、GPU、CPU、メモリへの対策があるが、それぞれが相互関係しており、並行して対応を続けることで効率よくモバイルへの移植が可能となった。
また、テレワークでの開発は、手元に当該端末がないなどで四苦八苦したという。
SoCでの動作の振る舞いや処理負荷のちがいが想像以上に大きく、テレワークでの開発体制ではビデオ会議でカメラに端末を映してもらいながら描画デバッグした。アナクロなのかデジタルなのかよくわからない不思議な感覚で安楽椅子探偵の気分だったということだ。リモートワークが進む上での、今後の課題だろう。
アプリ移植に伴う問題と対応〜プログラマー編～
後半はプログラマー目線からの問題と対応というテーマで、プログラマーの柿本氏が登壇した。
開発環境の最終バージョンは4.25.3で4.26は移行後の不具合が多く断念された。ビルドPCはAndroid＝Windows、iOS＝MacOSが１台ずつ用意されたが、平均パッケージ時間はAndroidが50分、iOSが2時間だった。MacはOSのバージョン更新のたびに環境整備コストが発生することもあり、時間がかかりがちとのこと。Androidが早い理由は分散ビルドが効率的だったこととPCのスペックが良かったことだろうとの推測だった。ビルド時間は開発効率に大きい影響があるので、ビルドマシンへの投資はした方がいいとのことだ。
クラッシュレポーターにはSmartBeatを導入。プラグインが提供されているので導入コストが低く、クラッシュ時のコールスタックをWebサイト上で閲覧できるので工数削減につながった。
アプリサイズ制限の壁と対応
CS版のパッケージサイズは最低でも10GB以上だが、SP版は4GB程度に抑えないとならない。まずはDeviceProfiles.iniで主な原因のテクスチャ解像度を極端に下げたところ、パッケージングされ、実機でプレイすることができた。ゲームパッドを接続するとCS版と変わらない遊び心地で想定より安定した動作をしていた。ここからクオリティを上げていくには、4GB以上のアセットを取り扱えるようにする必要がある。そのために、以下の3つの戦略が立てられた。
1.アプリ起動時と追加ダウンロードのアセットを分ける
ChunkIDで指定した。CS版でも使用していたので、ID指定のルールを調整するだけで対応できた。
2. 特定のフロー追加時や手動で追加アセットをダウンロードする
特定のフローとは、アプリ側には体験版範囲のアセットを詰め込み、それ以降は追加アセットとしている。ダウンロード機能は、iOSではUE4のMobile Patch Utilityを、Androidではプラットフォームの専用機能のGoogle Play Asset Deliveryをそれぞれ採用した。
▲ダウンロード機能にはいくつか候補があったが、最適なものを選択
3.追加アセットの更新／破損をアプリが検知したらダウンロードを行う
売り切りアプリのため起動の度にサーバにアクセスすることができないので、アプリに定義されたアセットバージョンと保存済みのアセットバージョンが不一致の場合サーバへ問い合わせる仕様とした。これはユーザーが自発的にアプリ更新をしないと発生しない。
開発ではイテレーションを落とさないためにサーバーを経由しないで全てのプレイを確認したいため、ローカルでコピーできるようなしくみが必要。その際、iOSはセキュリティが厳しいので、工夫がいるとのことだ。
Android App Bundle（AAB）への対応
AABは、APKに変わる新しいアプリバイナリ方式で、2021年8月以降にリリースするアプリはAABでの提出が必須となっている。サイズを軽減するなどの大きなメリットがあるが、AssetPackの合計ダウンロードサイズ上限が2GBとなっており、解決策が必要だった。この解決策は非公開情報のため、Googleに問い合わせてほしい。
.aabファイルは4GBを超えるとパッケージングに失敗するが、Epic Gamesに調査を依頼したところ、エラーは出ているがパッケージングには成功していたとのことだった。根本的な解決としては、Gradle内部での修正が必要なので、ビルドスクリプトで.aabをサルベージ、リネームすることで対処した。
AABの開発にはオフライン環境でも動作確認できるワークフローが必要で、APKでの確認環境もあった方がいいとのことだ。
最後に最適化について言及された。方針としては、ゲームデザインが変わる変更は行わないこと、スペックが厳しい端末向けに安定化対処を入れること、BlueprintのC++化やTickからEventへの変換があった。
メモリ不足への対応は、原因となるEffectをPool化してメモリを使いまわすようにして対処した。ヒッチはランタイムでのシェーダコンパイル負荷が原因で、PSOキャッシュによって改善した。
プログラム編のまとめとして、アセットのサイズ制限や機能実装の問題があったが、ゲームプレイはすんなり動作できたので、エンジンの強みを感じたという。また、iOSはハードウェア的に安定しており、エンジンのサポートも優先的に入っているが、Androidは時期も悪かったのか、OSの新仕様への対応情報が模索段階の印象とのことだった。
『聖剣伝説３』スマートフォン版におけるUE4アプリ開発事例～Making of Mana～ | UNREAL FEST EXTREME 2021 WINTER