『聖剣伝説３』スマートフォン版におけるUE4アプリ開発事例～Making of Mana～【UNREAL FEST EXTREME 2021 WINTER】

『聖剣伝説３』スマートフォン版に おけるUE4アプリ開発事例 ~Making of Mana~ 株式会社ジーン

お品書き • アーティスト編(スマートフォン版開発にあたって) • プログラム編(アプリ移植にともなう問題と対応)

スマートフォン版開発にあたって 株式会社ジーン 3Dアーティスト 植本修平

目次 • プロジェクト紹介 • スマートフォン版での変更点 • 最適化系 ◆ CPU、GPU対策 ◆ メモリ対策

聖剣伝説3 TRIALS of MANA紹介 -スマートフォン版-

聖剣伝説3 TRIALS of MANA紹介 -スマートフォン版- スクウェア・エニックス社のブランドである 聖剣伝説シリーズ３作目のリメイク作品。 2020年4月に家庭用、PC版で発売。 本作は上記タイトルのスマートフォン版 本スライド内では家庭用版(PC含む)をCS版、スマートフォン版をSP版とも表記 https://www.jp.square-enix.com/seiken3_tom/ 本スライドは株式会社スクウェア・エニックスが権利を有する著作物を利用しています。 当該コンテンツの転載・配布は禁止いたします。

はじめに(アーティスト編)

本資料内容について(アーティスト編) • これからモバイル開発を行おう、という モバイルアプリ開発未経験の方向けの内容となっております。 • エンジンの機能を使った最適化などのお話が中心のため、 ある程度のエンジンの基本要素を把握されている前提の内容となります。 (過去の登壇者様の最適化講演資料と内容自体は概ね同じ) • SoCなど、端末側については今回は触れません。

プロジェクトについて • CS版開発終了後からスタート • CS版⇒SP版移植について 開発終了時点では、SP版を意識したデータ設計にはなっていないため、 モバイルでは使用できない機能や、処理負荷上優しくないデータに なっているものなどが多々ありました。 (とはいえ、CS版としてはそこそこ切り詰めたデータ) そのデータをどのように移植、最適化していくかが課題。

プロジェクトについて • グラフィックについては、CS版を完全再現するわけではなく、 SP版として問題のないクオリティとして表現する形で調整。 • 3Dについては物量が多く、CS版で保障の取れていた挙動も崩れるため、 可能な限りでアセット単位での調整は抑える方針。

プロジェクトについて • • エンジンについてはCS版終了時に4.22から4.24へバージョンアップ 最終4.25.3を使用 そもそもCS版からSP版への移植は、 すんなり出来るものなのかどうか。 色々と都合のよくない箇所も見えてくるが、 とりあえず端末チェックから進める・・・

スマートフォン版での変更点

スマートフォン版での変更点 • • • • レンダリング方式 アンチエイリアシング方式 ポストプロセスマテリアル その他(マテリアル、影、ボーン等)

レンダリング方式 • ディファードからフォワード(モバイル)に変更 • この時点で使用できる機能の制限がかかる ※ただし、GPU負荷についてはかなりの効果が見られる。 • そもそもエンジンバージョンアップで挙動の変わった箇所もあるため、 モバイルだから、というよりも、とにかく不都合が出た箇所を確認し、 各々の対応を進める

アンチエイリアシング • TemporalAAからMobileMSAAに変更 CS版では、パラメータを調整し、ボケ、ゴースト現象は抑える方針で対応。 • モバイル用TAAでは調整が難しく、 ボケ、ゴースト現象も一部で顕著に発生したため、 SP版では対応端末についてはMSAAに変更。 (その他はr.MobileMSAA=1を使用) 参考資料：猫でも分かるUE4のポストプロセスを使った演出・絵作り p155 /Epic Games Japan 岡田様 https://www.slideshare.net/EpicGamesJapan/ue4-108770894

アウトライン表現について • Gバッファが使えないため、 法線比較を使っていたCS版のアウトライン表現は そのままでは使えない • 背面法や、マテリアル側での表現を検討するも、 アセット毎に再調整するには物量が多すぎるため、 ポスト処理のみで対応を検討 お馴染の表示が、色んな場面で出てしまう・・・ CS版のアウトラインについて： https://www.slideshare.net/EpicGamesJapan/unreal-festext2020winter-xeen/12

アウトライン表現について • 深度比較をメインに置き換えて、 モバイル版に合わせた見映えを調整。 併せて背景側のアウトラインについても調整

フォグ表現について CS版ではポストプロセスマテリアルを使用し、 深度(SceneDepth)を利用したフォグを調整に使用。 深度を参照し彩度、色味、天球の色の拾い度合い等を変更可能 極端に変更した例

フォグ表現について CS版ではポストプロセスマテリアルを使用し、 深度(SceneDepth)を利用したフォグを調整に使用。 CS SP ⇒ © 1995, 2020, 2021 SQUARE ENIX CO.,LTD. All Rights Reserved. 遠景に薄くかけていたフォグが・・・ © 1995, 2020, 2021 SQUARE ENIX CO.,LTD. All Rights Reserved. モバイル版では結果が異なってしまう ※モバイル版を疑似再現したイメージ画像です

フォグ表現について(必殺技演出) • 他にも、CS版では必殺技の暗転演出にもフォグを利用 ※背景のみを暗転させることに使用

フォグ表現について(必殺技演出) • SeparateTranslucencyを使用することで避けていた 半透明のフォグへの巻き込みも、SP版で発生するようになってしまう。 ※必殺技のエフェクトがフォグに巻き込まれる CS版半透明 SP版半透明 ※MSAAを無効にしないとMobileSeparateTranslucencyが使えない

フォグ表現についての対策を検討 • 計算結果が異なる SceneDepthから取得できる数値幅がCS版とSP版で異なる様で、 見映えが大きく変わってしまう。 バッファのサイズの違いが原因と思われる。 ゼロからSP版を制作する場合、深度の閾値内での設計を検討するが、 移植のため、背景データをモバイル用に設計しなおすのは高コスト。 また、半透明が巻き込まれる問題もある。 そこで、開発中のエンジン更新や、端末毎に結果の違いがあった場合などを考慮し、 実装をポスプロから、背景マテリアル側へ変更

背景マテリアルに移植 • ポスプロで行っていた処理を 背景のマテリアル側に機能を移植、 • エリアごとにパラメータコレクションで調整 明表現(距離表現、時間変化)にエミッシブ、 暗表現(洞窟、演出)にスペキュラ、AO等を使用

その他の置き換え • • ポストプロセスボリュームのAmbientCubeMapが使用できない • マップのエリアごとにSkyLightを調整して代用 影をinsetShadowからCSMに変更 • 変調シャドウについては、見映えを考慮し、使用を見送り キャラへの落ち影などがなくなるが、許容とする (影を落としたい側をMovableにすることで対応は可能) 屋内でも平行光源の影響を受けるので要注意

その他の置き換え • 1Callにつき、75以上のボーンが使用できなくなる • 該当するキャラ(マテリアル)が 数える程度だったので、マテリアルを分割し、 セクション内のボーンを分散する形で対応 公式ドキュメント：モバイル プラットフォーム用のメッシュ https://docs.unrealengine.com/4.27/ja/SharingAndReleasing/Mobile/Meshes/

その他の置き換え • Timeノード、LandscapeCoordsなど、座標系のマテリアルの処理が 精度の都合、ブロックノイズのような表示がされる CustomizedUV、FullPrecisionで対応 公式ドキュメント： モバイル プラットフォーム用のマテリアル/カスタム仕様の UV https://docs.unrealengine.com/4.27/ja/SharingAndReleasing/Mobile/Materials/ https://docs.unrealengine.com/4.27/ja/RenderingAndGraphics/Materials/CustomizedUVs/

置き換えなかったモノ • KawaiiPhysics + AnimDynamics(揺れもの系) SP版でも、違和感なくそのまま使用 KawaiiPhysics：おかず様制作の非公式の物理プラグイン https://github.com/pafuhana1213/KawaiiPhysics ※UNREAL FEST EXTREME 2020 WINTERより抜粋 CS版の揺れものについて： https://www.slideshare.net/EpicGamesJapan/unreal-festext2020winter-xeen/34

最適化について

GPUについて • モバイルフォワードへの移行でおよそ処理内におさまっていた。 • 常時対応として、バトルエフェクトの軽量化。 負荷の高い箇所については個別対応(アセット調整等)を行う。 後述のCPU対策もあわせると、GPUに投入されるオブジェクトも減るため、 恒常的な負荷軽減として並行して対応を進める。 • 対象端末のスペック差、サーマルスロットリングも考慮し、 GPU負荷対策として、ゲームオプションで品質(解像度や影周り)を変更可能に。

CPUについて • GPUよりも比較的CPU側がネックに。 • 対象端末のスペック都合、 バッファを見ておよそ DrawCallsが1000～1200前後になるように調整 状況下で負荷要因も変わるため、 あくまで目安としての設定

DrawCallsについて CS版ではハードウェアオクルージョンカリングが効いていたことによって、 特に作業者が意図していなかったとしても、ある程度のカリングが行われていた。 モバイルの場合は、 特定の端末でないとハードウェアオクルージョンカリングが使用できないため、 極端な話、ステージの最果てまでのオブジェクトが 全て描画されるようになってしまっていた。 ※特定の端末 iOS端末(Metal)、AndroidでのVulkan対応端末等 https://docs.unrealengine.com/4.27/ja/RenderingAndGraphics/VisibilityCulling/

DrawCallsについて DrawCallsが倍近く変わる例 遮蔽カリングON：1000 遮蔽カリングOFF：2000 ※モバイル版を疑似再現したイメージ画像です

DrawCallsについて 対象端末では、Vulkanをサポートしない端末も多数含まれるため、 ハードウェアオクルージョンカリングは諦め、別の手段を検討 ※一部特定の端末のみをVulkanを使用し、ハードウェアオクルージョンカリングにて、 ボトルネックであるCPU負荷を解消することも検討したが、未実装

Draws対策 • • • 距離カリング ソフトウェアオクルージョンカリング マージ、インスタンス化、HLOD等

距離カリング CS版当時、必要のなかった箇所には 距離カリング設定を入れていないため、 DistanceCullVolumeの調整と、新規配置から始める。 既に調整されているMapに関しては、 より積極的にカリングされるように設定を進めてい く

距離カリング その他カリングより、比較的処理にやさしい(ハズ)。 Volume内で一括設定してしまうので、 作業としては比較的低コストのように思えるが・・・

距離カリング SP版ではより積極的に、という形が仇となり、 想定以上にガンガン物が非表示にされていく・・・。

距離カリング ある程度のセーフティとしての設定は期待出来るが、 そもそも見える範囲で、距離カリング自体をしてはいけないオブジェクトも多い。 また、小さなアセットの集合体で構成された配置物も多いため、 単純に一括設定もできない・・・。 (当たり前かつ、モバイルに限った話ではないですが) CS版でも行っていたが、より一層、 配置しているアセット単位での、さらなる細かい調整が必須。 距離カリングだけで対応するには限界があると悟る。

ソフトウェアオクルージョンカリング • 特定アセットのLODを指定することで、 遮蔽メッシュとして使用し、カリングする • 壁が多いMapでは圧倒的な効果を誇る • 調整次第でCS版と同じ程度にカリングされる ハードウェア オクルージョン クエリでは GPU 上でビジビリティの確認を行いますが、 このカリング方法では CPU 上でシーンをラスタライズすることでアクタをカリングします。 (公式Document引用) https://docs.unrealengine.com/4.27/ja/RenderingAndGraphics/VisibilityCulling/SoftwareOcclusionQueries/

ソフトウェアオクルージョンカリング • 元々、SOを想定したアセット配置となっていないため、 特定メッシュのLODを指定すると、 必要のない箇所でも無駄な分が処理に載ってしまう恐れがあった。 ※アセットの流用も多いため、機械的に設定するとカリングの必要のない箇所にも多く適応されてしまう そのため、必要なメッシュ分だけ、複製して、 オクルーダーとして登録、アセットを差し替えることで対応。

ソフトウェアオクルージョンカリング • 一部の複雑な形状には、専用の遮蔽専用のメッシュを用意 可能な限り頂点を減らし、負荷の要因を増やしたくなく、 また、ON、OFFでの差分を比較しやすかったため 調整の効きやすい プリミティブな専用メッシュを配置 Render in MainPass をFalseにした状態

マージ、インスタンス化、HLOD • • • マージ インスタンス化 HLOD、事前計算カリング

マージ • 安定した効果あり。時短のためプロキシメッシュで作成 • マージ時に、コリジョン周りの設定にてヒューマンエラーの恐れもあるため、 チェックコストも考慮し、 出来得る限り、プレイヤーが干渉しない遠景などに対応をとどめる

インスタンス化 • 要所にだけ使用 通常のインスタンス化(notHISM)の場合、 背景データ都合、アセットをまとめづらく、 またGPU負荷にもつながりやすいので、 効果的に設定できず、マップ次第では効果を望めなかったため。

HLOD、事前計算カリング • 求めていた機能として、内容はコレ以上ないものであったが、 メモリにそこまで余裕があるわけでもなく、 作業イテレーションの都合もあり、プロジェクトでは見送り

メモリについて

メモリについて • メモリ使用量の想定 • 動作端末のメモリの半分を目安に設定(バッファ込み) • テクスチャのフォーマット、ライトマップの縮小、マテリアルの軽量化、 その他最適化もあって、概ねメモリオーバーせずプレイは可能 しかし、特定のイベント下では確定でメモリオーバーも発生したため、 対策を打つ必要がでる • ゲーム側の設計を大きく変えることは難しいため、 可能な限りアセット単位で対応

メモリ対策 • アセットリダクション モバイル版として問題のない範囲で頂点を削る 背景、特定のボス、一部常駐するエフェクトのメッシュリソース • 背景の効果的でないLODの削除 (段階を減らす、元よりlowモデルを使用する等) • • 使用用途が限定されたキャラのLODの削除 マージ、およびリダクションでリソース削減

各種対策についてまとめ • グラフィック表現に関するCS版からSP版への置き換え GPU、CPU、メモリへの対策、 それぞれが相互関係もあり、 すべてを並行して対応を行い続けることで、 効率よくモバイルへの移植を行うことが出来た。

おまけ(3D編)

おまけ 昨今の時勢もあり、テレワーク期間が発生する。 モバイル開発であるため、各種端末(SoC)での動作の振舞の違いや、 処理負荷が端末毎で予想を上回るほどに違ったりすることに直面。 端末毎の不具合などがあっても、手元に該当端末がないなどでの四苦八苦。 ※各スタッフ間でSoC世代毎に端末を所持、チェックを分散することなどで対応 ビデオ会議にて、カメラに端末を映してもらいながらの、 描画デバッグを行うなど、安楽椅子探偵気分を味わう。

まとめ CS版からの移植ということもあり、「モバイルアプリ開発」という点で、 そもそも適さない内容もあったかもしれません。 そもそも、というならモバイルに限らない基本的なお話も多々あったかと 思われます・・・。 それでも、本資料がなにかしら皆さまのお役に立てられれば幸いです！！

次、プログラム編です！

アプリ移植にともなう問題と対応 株式会社ジーン 第一開発事業部 プログラマー 柿本 恭兵

はじめに [本講演のターゲット] • Unreal Engine(UE) で初めてモバイルアプリを作る方 • UE製の既存タイトルをモバイルアプリに移植する方

はじめに [取り上げる内容] • アプリ移植で立ちふさがる壁について • モバイルプラットフォーム固有の話題

アジェンダ • • • • • • 開発環境 アプリサイズ制限の壁 アプリサイズ制限への対応 Android App Bundle への対応 Android 固有の対応 最適化

アジェンダ • • • • • • 開発環境 アプリサイズ制限の壁 アプリサイズ制限への対応 Android App Bundle への対応 Android 固有の対応 最適化

開発環境 • Engineの最終バージョン：4.25.3 • 4.26は移行後の不具合が多く断念し，以降はCLマージに切り替え • ビルドPC：Android，iOS用に1台ずつ用意 • Android=Windows, iOS=Mac • CI：Jenkins（オンプレミス運用） • 平均パッケージング時間 Android：50分，iOS：2時間 • フルの Shader Compile 時は，この4倍の時間になる • MacはOSバージョン更新の度に環境整備コストが発生

開発環境 [Androidのパッケージングはなぜ速い？] • 分散ビルドが効果的だった（IncrediBuild を使用） • Mac向けに FastBuild は未検証 • Windows, MacでPCのスペック差もある 日々の開発効率を少しでも上げるべく， ビルドマシンのスペックは惜しみなく投資しましょう！

開発環境 [クラッシュレポーターについて] • QA期間中に SmartBeat を導入し，運用（製品には含めず） • Unreal Engine 向けにPluginが提供されており，1日で導入できた • 自動でシンボリケートしてクラッシュ時のコールスタックをWeb サイト上で閲覧できるので，工数削減に繋がった • クラッシュはしないが，実はBpで不正な参照が起きている場合も 検知してくれる • エラーを検知したらSlackに通知するように対応

アジェンダ • • • • • • 開発環境 アプリサイズ制限の壁 アプリサイズ制限への対応 Android App Bundle への対応 Android 固有の対応 最適化

アプリサイズ制限の壁 CS版のパッケージサイズは，小さいものでも10GB以上 SP版のアプリサイズは，OSによって構成・上限が異なる （Androidは「APK」と「AAB」でも事情が異なる） iOS (.ipa)：４GiB Android (.apk+.obb)：apk２GiB + obb２GiB

アプリサイズ制限の壁 まずはパッケージサイズを４GiB未満に下げないと， パッケージングエラーとなり実機での確認ができなかった 手っ取り早い方法として，DeviceProfiles.ini の TextureLODGroups からテクスチャ解像度を極端に下げた ↓ ４GiB未満に収まり，パッケージングができるようになった

アプリサイズ制限の壁 開発初期の実機確認では，ゲームパッドを接続すれば， CS版と変わらない遊び心地で想定より安定動作していた ただしここまでは，実機で確認するための準備ができただけ （グラフィックスの評価ができる状態ではない） ↓ ここからクオリティを上げていくには， ４GiB以上のアセットを取り扱えるようにする必要がでてきた

アジェンダ • • • • • • 開発環境 アプリサイズ制限の壁 アプリサイズ制限への対応 Android App Bundle への対応 Android 固有の対応 最適化

アプリサイズ制限への対応 【４GiB以上のアセットを取り扱う戦略】 • アプリ起動時に必要なアセットと，追加でダウンロードする アセットを分ける • 特定のフロー通過時，または手動で追加アセットをダウンロ ードする • 追加アセットの更新/破損をアプリが検知したら，ダウンロー ドを行う

アプリサイズ制限への対応 【４GiB以上のアセットを取り扱う戦略】 • アプリ起動時に必要なアセットと，追加でダウンロードする アセットを分ける • 特定のフロー通過時，または手動で追加アセットをダウンロ ードする • 追加アセットの更新/破損をアプリが検知したら，ダウンロー ドを行う

アプリサイズ制限への対応 【アプリ起動時に必要なアセットと，追加でダウンロードするアセットを分ける】 PrimaryAssetLabel による Chunk ID 指定で対応 Chunk ID=0 はアプリ側，0以外は追加ダウンロード側 CS版でも使用していたので，ID指定のルールを調整するだけでよかった Chunk IDについては以下の資料が参考になります UE4のモバイル開発におけるコンテンツアップデートの話 - Chunk IDとの激闘編 – 徹底解説！UE4を使ったモバイルゲーム開発におけるコンテンツアップデートの極意！

アプリサイズ制限への対応 【４GiB以上のアセットを取り扱う戦略】 • アプリ起動時に必要なアセットと，追加でダウンロードする アセットを分ける • 特定のフロー通過時，または手動で追加アセットをダウンロ ードする • 追加アセットの更新/破損をアプリが検知したら，ダウンロー ドを行う

アプリサイズ制限への対応 【特定のフロー通過時，または手動で追加アセットをダウンロードする】 [ダウンロード機能の候補] • UE4 : Mobile Patch Utility • UE4 : Chunk Downloader • プラットフォーム専用機能（独自のCDNが不要） • iOS : On Demand Resources • Android : Google Play Asset Delivery

アプリサイズ制限への対応 【特定のフロー通過時，または手動で追加アセットをダウンロードする】 [ダウンロード機能の候補] • UE4 : Mobile Patch Utility ←iOSはこちらを採用 • UE4 : Chunk Downloader • プラットフォーム専用機能（独自のCDNが不要） • iOS : On Demand Resources • Android : Google Play Asset Delivery ←AABで利用

アプリサイズ制限への対応 【特定のフロー通過時，または手動で追加アセットをダウンロードする】 [UE4 : Mobile Patch Utility] （iOS版で採用） • 検証してみたところ，本タイトルの利用範囲であれば，動作 に支障がなかった（頻繁にアプリ更新を行わない） • Blueprintでのエラーチェックによるフロー分岐など，プロジ ェクト側の要求にも対応できた

アプリサイズ制限への対応 【特定のフロー通過時，または手動で追加アセットをダウンロードする】 [UE4 : Chunk Downloader] （採用見送り） • 新機能として公式に推されていたのでこちらも検証 • ダウンロードフローが自動化されているのでお手軽 • このお手軽さが問題となり，プロジェクト側から通信フロー分岐等 をカスタムするには，エンジン実装を変更する必要があった

アプリサイズ制限への対応 【特定のフロー通過時，または手動で追加アセットをダウンロードする】 [iOS : On Demand Resources] （採用見送り） • Apple社がホスティングしているサーバーを無料で利用可能 • サーバーランニングコストを考慮すると，売り切りアプリと の相性がよい • UE4.25.3 時点では，この機能の対応がエンジン内部でコメ ントアウトされており，独自に対応するコストがかかる

アプリサイズ制限への対応 【特定のフロー通過時，または手動で追加アセットをダウンロードする】 [Android : Google Play Asset Delivery] （AABで利用） • 開発中盤まではAPK形式で進めていたが，終盤でAAB形式へ の移行が必須となったため，急遽こちらの機能に対応 • UE4.25では GooglePAD Pluginとして対応が進んでいる途中 だったので，QA期間と並行しつつ実装を間に合わせた • AAB(Android App Bundle) への対応詳細は後述

アプリサイズ制限への対応 【特定のフロー通過時，または手動で追加アセットをダウンロードする】 [特定のフロー とは？] • CS版で言うところの，体験版範囲が遊び終わったら強制的に ダウンロードとなる • アプリ側には体験版範囲のアセットを詰め込んで，それ以降 のデータ全てを追加アセットにする • （諸事情により）この仕様はiOSのみ

アプリサイズ制限への対応 【４GiB以上のアセットを取り扱う戦略】 • アプリ起動時に必要なアセットと，追加でダウンロードする アセットを分ける • 特定のフロー通過時，または手動で追加アセットをダウンロ ードする • 追加アセットの更新/破損をアプリが検知したら，ダウンロー ドを行う

アプリサイズ制限への対応 【追加アセットの更新/破損をアプリが検知したら，ダウンロードを行う】 [更新検知方法] • 売り切りのオフラインアプリなので，起動のたびにサーバー へバージョンを問い合わせる仕様はNG • アプリに定義されたアセットバージョンと，保存済みのアセ ットバージョンが不一致なら，サーバーへ問い合わせる （ユーザーが自主的にアプリを更新しない限りは通信が発生しない）

アプリサイズ制限への対応 【補足：サーバーを経由せずに追加アセットをインストールするしくみ】 開発イテレーション速度を落とさないように，サーバーを経由 せずとも全てのプレイ範囲を確認できる必要がある →追加アセットを端末に直接コピーする Android : 標準でエクスプローラーから端末内にアクセス可能 iOS : アプリ内アクセスへの制限が厳しいので，少々工夫が必要

アプリサイズ制限への対応 [Android : Google Play Asset Delivery] （AABで利用） • 開発中盤まではAPK形式で進めていたが，終盤でAAB形式へ の移行が必須となったため，急遽こちらに対応 • UE4.25では GooglePAD Pluginとして対応が進んでいる途中 だったので，QA期間と並行しつつ実装を間に合わせた • AAB(Android App Bundle) への対応詳細は後述

アジェンダ • • • • • • 開発環境 アプリサイズ制限の壁 アプリサイズ制限への対応 Android App Bundle への対応 Android 固有の対応 最適化

Android App Bundle への対応 [Android App Bundle(AAB) とは] • １つのAABデータで多数のCPU構成の端末をサポートできる， APKから換わる新しいアプリバイナリ形式 • .apkサイズの肥大化を軽減できるなど多くのメリット • 2021年8月 以降にリリースするアプリはAABでの提出が必須 • Play Asset Delivery を使うことでアセット追加配信に対応

Android App Bundle への対応 [UE4でAABをパッケージングするには] • 基本的な手順は，UE4ドキュメントの GooglePAD Pluginの 説明どおり • 事前にPakファイル生成 → AABビルドの流れになる都合で， ２回ビルドを行う（ビルドスクリプトで自動化） • ChunkID=0 以外の追加 AssetPack をビルドするには，例外 対応が必要となる（UE4.25時点では）

Android App Bundle への対応 [ChunkID=0 以外の追加 AssetPack をビルドする] • ObbFilter 機能を使い，全ての.pakファイルがChunk0に内包 されるのを防ぐ /Config/Android/AndroidEngine.ini [/Script/AndroidRuntimeSettings.AndroidRuntimeSettings] ;AAB生成時にpakchunk0以外をmain.obbから除外する +ObbFilters=-*.pak +ObbFilters=pakchunk0-* ※この機能を使うと，出力される.obbがpak0のみとなるため， UniversalAPKでの確認ができなくなる

Android App Bundle への対応 [AssetPack のダウンロードサイズ上限について] Androidの開発者サイト には，AssetPackの合計ダウンロード サイズ上限が「2GB」と記載されている しかし，今作はまったく２GBに収まっていない… ↓ 解決手段としては… 非公開情報のため，Google社にお問い合わせください

Android App Bundle への対応 [トラブル対応：.aabファイルサイズが増えるとビルドエラー] .aabファイルが４GiBを超えると，パッケージングに失敗する Execution failed for task ':app:signReleaseBundle'. > A failure occurred while executing com.android.build.gradle.internal.tasks.Workers$ActionFacade > Malformed ZIP Central Directory record #1 at file offset 4294967295 UDNにてEpicGames社に調査協力いただいた結果， エラーは出ているがパッケージングには成功していた ↓ .aab の作業ファイルが以下のパスに出力されている ¥<Project Path>¥Intermediate¥Android¥gradle¥app¥build¥intermediates¥intermediary_bundle¥release

Android App Bundle への対応 [トラブル対応：.aabファイルサイズが増えるとビルドエラー] .aabファイルが４GiBを超えると，パッケージングに失敗する Execution failed for task ':app:signReleaseBundle'. > A failure occurred while executing com.android.build.gradle.internal.tasks.Workers$ActionFacade > Malformed ZIP Central Directory record #1 at file offset 4294967295 根本解決は Gradle内部での修正が必要なので， ビルドスクリプトで.aabをサルベージ/リネームする形で対処

Android App Bundle への対応 [Play Asset Delivery の AssetPack 構成例] Asset Pack Chunk ID Chunk サイズ上限 用途 install-time 0 1GiB アプリ起動に必要なデータ，常駐物など （UI/SE/OpeningMovie/Effect/Sequencer…） fast-follow 1 512MiB 早期に必要なデータ（アプリDL後に自動でDLされる） （Stage Commonアセット） on-demand A 2 512MiB 追加ダウンロードデータ A （序盤StageSet1 / 序盤BGM） on-demand B 3 512MiB 追加ダウンロードデータ B （序盤StageSet2 / 序盤Movie） on-demand n n 512MiB 追加ダウンロードデータ n 仕様では Asset Pack 数は最大50個まで

Android App Bundle への対応 [AssetPak のサイズを削減する] • install-time は常駐物が多く，１GiBに収めるのが難しい • DefaultPakFileRules.ini にて不要アセットを除外した • 別のプラットフォーム向けのアイコンテクスチャなど… ; Assets to exclude from the package. [ExcludeContent] bExcludeFromPaks=true bOverrideChunkManifest=true +Files="Engine/Content/SlateDebug/Fonts/LastResort.*"

Android App Bundle への対応 [AAB の動作確認方法] • UniversalAPK は使えず • ObbFilterにより，起動データしか main.obb に内包されないため • Google社の bundletool で端末にローカル転送すると？ • アプリは起動せず（詳細までは時間がなくて追いきれず） • 消去法で GooglePlayConsole の 内部アプリ共有 を使用 • イテレーション時間はかかるが，製品フローが確認できて確実

Android App Bundle への対応
[APK と AAB のフロー共存]

•

全員が GooglePlayStore を経由してアプリをダウンロードするのは，イテレーション
効率が落ちる

•

AAB起動かどうかのフラグを見て，APKとフローを分岐させる

// 直接 .ini から設定を取得する場合
bool bEnableBundle = false;
check(GConfig);
if(!GConfig->GetBool(TEXT("/Script/AndroidRuntimeSettings.AndroidRuntimeSettings"), TEXT("bEnableBundle"), bEnableBundle, GEngineIni)) {
bEnableBundle=false;
}
// クラス変数経由で .ini から設定を取得する場合
const UAndroidRuntimeSettings *pSettings = GetDefault<UAndroidRuntimeSettings>();
if (pSettings) {
return pSettings->bEnableBundle;
}

Android App Bundle への対応 【AAB 対応まとめ】 • 今後開発/リリースするAndroidアプリは初めから対応必須 • オフライン環境でも動作確認できるワークフローが必要 • 結局はAPKでの確認環境もあったほうがよいかもしれない • AABビルド環境は今後の安定化に期待

アジェンダ • • • • • • 開発環境 アプリサイズ制限の壁 アプリサイズ制限への対応 Android App Bundle への対応 Android 固有の対応 最適化

Android 固有の対応 • • • • • • • バックキー対応 アダプティブアイコン ライセンス認証（有料アプリ向け） SavedGames（エンジン機能拡張） Android App Bundle パーミッション利用説明画面 Wi-Fi通信とCellular通信の切り替え確認画面

Android 固有の対応 • • • • • • • バックキー対応 アダプティブアイコン ライセンス認証（有料アプリ向け） SavedGames（エンジン機能拡張） Android App Bundle パーミッション利用説明画面 Wi-Fi通信とCellular通信の切り替え確認画面

Android 固有の対応 【SavedGames（エンジン機能拡張）】 Google社がPlayゲームサービスの一部として提供している， クラウド上にデータを保存するシステム UE4.25時点では，セーブデータ保存時にクラウドに自動的に書 き込む連携機能が入っている ↓ ユーザー任意のタイミングではセーブデータの同期ができない

Android 固有の対応 【SavedGames（エンジン機能拡張）】 iOS版とはUserCloudの実装内容が揃っていなかったので， OnlineUserCloudInterface 経由で gpg-cpp-sdk の Snapshot機能にアクセスできるように追加実装を行った （セーブデータ保存時の自動連携はOFFに）

アジェンダ • • • • • • 開発環境 アプリサイズ制限の壁 アプリサイズ制限への対応 Android App Bundle への対応 Android 固有の対応 最適化

最適化 【対応方針】 • CS版の時点で，ソフトウェアでのCPU負荷軽減はある程度済 んでいた • ゲームデザインが変わる変更は行わない(Enemy数を削る等) • スペックが厳しい端末向けに安定化対処を入れる • 一部BlueprintのC++化や，TickからEventへの置換を行った

最適化 【メモリ不足への対応】 一定間隔でのガベージコレクション（GC）はOFFで， 任意のタイミングでGCを走らせる設計となっている ↓ 時間経過で未解放Effectが溜まってメモリ不足となる ↓ 原因となるEffectをPool化してメモリを使い回すように対処

最適化 【ヒッチへの対応】 開発初期から，ヒッチ（処理負荷のスパイク）が目立っていた 原因は，ランタイムでのシェーダーコンパイル負荷 → PSOキャッシュ によって改善する必要がある 基本的には UE4ドキュメント に沿って対応 エンジンに不具合があった箇所は個別に修正を取得/マージ

最適化 【ヒッチへの対応（PSOキャッシュの収集）】 PSOデータ収集はある程度自動化したが，収集には端末のメモ リ量が多くないとアプリがクラッシュし，収集効率が落ちる ↓ 搭載メモリの大きい端末を用意することを推奨 iOS端末は搭載メモリが少ないので，レベル分割などで収集を複 数回に分ける必要がある

最適化 【ヒッチへの対応（PSOキャッシュ PreCompile分散）】 アプリ起動時に全てのキャッシュをPreCompileすると， 起動までに数分の待ち時間が発生してしまう問題がある ↓ アプリ起動時に全てのキャッシュのPreCompileを行わず， アプリ初回起動から少しずつ分散しながらPreCompileするよう に，フローの隙間に処理を組み込んだ

最適化 【ヒッチへの対応（PSOキャッシュ ロード短縮）】 Androidは OpenGL ES を使用しているので， ２回目以降のアプリ起動時にも毎回キャッシュのPreCompileが 発生し，ロード時間が長くなってしまう ↓ ProgramBinaryCache によって，２回目以降の起動時でも PreCompile時間が気にならない程度に短縮できた そう、UE4ならね。あなたのモバイルゲームをより快適にする沢山の冴えたやり方について Part 1 <Shader Compile, PSO Cache編>

まとめ

【プログラム編】まとめ • 移植ならではの問題としては，アセットのデータ構造分割と サイズ制限，プラットフォーム専用の機能実装があるが，ゲ ームプレイ部分はすんなり動作させられたのでエンジンの強 みを感じた • iOSはハードウェア的に安定しており，エンジンのサポートも 優先的に入っているが，Androidはまとまった情報がまだ少 なく，OS新仕様への対応情報が模索状態と感じる

全ての情報を詰め込むことはできませんでしたが， 本資料が少しでも今後の開発の参考になれば幸いです ご清聴 ありがとうございました