『修羅道』制作事例 モバイルハイエンドグラフィックゲーム実現まで【UNREAL FEST EAST 2018】

3.9K Views

October 17, 18

スライド概要

"講演動画:https://www.youtube.com/watch?v=Iy0WWtMJgNQ

2018年10月14日に行われた「UNREAL FEST EAST 2018」における株式会社ガンバリオン様の講演で使用されたスライドです。
●公式サイト
https://unrealengine.jp/unrealfest/
===
UE4にて開発したスマートフォン用ゲーム『修羅道』において、UE4の勉強から始めて、期間半年でどのようにモバイルハイエンドグラフィックゲームを実現したかお話します。アセット制作や最適化、モバイルならではの問題点などを解説していきます。"

profile-image

Unreal Engineを開発・提供しているエピック ゲームズ ジャパンによる公式アカウントです。 勉強会や配信などで行った講演資料を公開しています。 公式サイトはこちら https://www.unrealengine.com/ja/

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

『修羅道』制作事例 モバイルハイエンドグラフィックゲーム実現まで 株式会社ガンバリオン CGデザイナー エンジニア 太田直人 濱浦誠悟 #ue4fest

2.

自己紹介 株式会社ガンバリオン 株式会社ガンバリオン 『修羅道』ディレクター 『修羅道』メインエンジニア 太田直人 濱浦誠悟 2012年、株式会社ガンバリオン入社。 2015年、株式会社ガンバリオン入社。 CGデザイナーとしてUIを中心として 『修羅道』では主にメインモードに 開発に携わる。 あたる修羅道と羅生門の実装、 『修羅道』では世界観や仕様設計、 開発環境の整備を担当。 キャラクターモデリングなどを担当。 #ue4fest

3.

本講演で話すこと 初めてUE4を使用して 期間半年で どのようにモバイルハイエンドグラフィックを実現したか #ue4fest

4.

アジェンダ ■1部:3カ月で基本を完成させたワークフロー 1-1 開発が始まるまで 1-2 UE4の検証 1-3 ハイエンドクオリティを実現するために 1-4 ワークフローに関するTips ■2部:リリースに向けて、最適化 2-1 リリースに向けて 2-2 最適化 2-3 ここが困った #ue4fest

5.

#ue4fest

6.

#ue4fest

7.

『修羅道』 グラフィックにこだわった剣戟アクションゲーム AppStore/GooglePlayで配信中 敵の一挙一動を気にする緊迫した 駆け引きを愉しむゲーム 空気や「間」が感じられる ビジュアルの説得力が求められた #ue4fest

8.

期間と人数 開発期間 ・半年 開発開始から3か月後にTGS出展が控えていた 開発人数 ・2名(濱浦と太田)でスタート ・8名前後で開発 ・繁忙期に最大12名 #ue4fest

9.

第1部:3カ月で基本を完成させたワークフロー #ue4fest

10.

1-1 開発が始まるまで #ue4fest

11.

1-1 開発が始まるまで プロジェクトの前提 ・モバイル ・ハイエンド ※据え置き機と遜色ないグラフィックが目標 ・期間短め ・規模小さめ #ue4fest

12.

1-1 開発が始まるまで UE4での開発 ・バージョン4.15~スタート ・EULA版での開発 #ue4fest

13.

1-2 UE4の検証 #ue4fest

14.

1-2 UE4の検証 そもそもUE4の使用経験がない →プロトタイプを作りつつ検証 #ue4fest

15.

1-2 UE4の検証 役立った文献 ・UnrealEngine4で極めるゲーム開発 (2015年7月発売) ・UnrealEngine4 ブループリント逆引きリファレンス (2016年2月発売) #ue4fest

16.

1-2 UE4の検証 マーケットプレイスでテスト用モデル/モーションを購入 ・低コストで高クオリティ ・規格が設定されており、すぐに使える 高速でプロトタイプが作れた Movement Animset Pro #ue4fest

17.

1-2 UE4の検証 ディファ―ドレンダリングのテスト ・UE4.15.3 当時、モバイルディファードレンダラが開発されており 設定からレンダラを変更できた ・UE4の採用理由のひとつでもあったためサンプルのレベルを使用して まずは動作を確認 #ue4fest

18.

1-2 UE4の検証 ディファ―ドレンダリングの断念 サンプルレベルを使用してテストした結果… ・iOSでは描画結果が破たんしていた ・Androidでは表示できたがSnapdragon820でも20fps程度しか出ず フォワードレンダラを採用 ・・・UE4.20現在はモバイルディファ―ドレンダラの設定自体が消滅している #ue4fest

19.

1-2 UE4の検証 ブループリントの検証 ・考え方は一般的なオブジェクト指向言語に近くで大きな混乱はなかった ・Delay ノードやイベントなどでフレームをまたいだ処理も書きやすい ・演算子1つにも1つのノードを使うため、ソートなどのアルゴリズムや 数学の公式を表現しようとすると複雑化しやすい プロトタイプはブループリントで不自由なく作れた #ue4fest

20.

1-2 UE4の検証 プロジェクト本格始動 ・プロトタイプの作成には3週間ほど使用 ・UE4の基本操作を覚えた ・試作できる程度の仕様をまとめた #ue4fest

21.

1-3 ハイエンドを実現するために #ue4fest

22.

1-3 ハイエンドを実現するために ハイエンドの定義:モバイルで据え置き機のクオリティ ・見た目第一、ポリゴン数など一切の制約を気にせず作る #ue4fest

23.

1-3 ハイエンドを実現するために キャラモデル 主な使用ツール Maya ZBrush Substance Painter ポリゴン:約47,000tris テクスチャ:1024x1024 diffuse / material / normal 1モデルにつき1枚ずつ #ue4fest

24.

1-3 ハイエンドを実現するために マテリアル テクスチャ構成はキャラクター/武器/ステージ共通 ・diffuse ・material(R=roughness G=metallic B=ambient occlusion) ・normal モバイルレンダラではAOは効かなかったが コントラストの強いビジュアルなので あまり気にならなかった #ue4fest

25.

1-3 ハイエンドを実現するために マテリアル・濡れた世界の表現 ・硬質パーツは特に輪郭のmetal値を極端に 上げ、少ない光源でもハイライトが 入るようにしている ・逆に布系はmetal値を0にして 少ない光源でも質感差が分かるように している #ue4fest

26.

1-3 ハイエンドを実現するために マテリアル・少ない光源への対応 ・ステージがかなり暗いため、 ディフューズカラーは極限までビビッドに している ・極限まで上げてようやく視認できる程度に 暗い #ue4fest

27.

1-3 ハイエンドを実現するために 武器モデル 主な使用ツール Maya Mudbox ZBrush Substance Painter ポリゴン:約1,000~11,000tris テクスチャ:1024x1024 diffuse / material / normal 1モデルにつき1枚ずつ #ue4fest

28.

1-3 ハイエンドを実現するために 武器モデル・少ない光源への対応 武器用ライトを用意して視認性を上げる ・ステージの光量では目立たないため BEFORE AFTER #ue4fest

29.

1-3 ハイエンドを実現するために モーション 主な使用ツール Maya #ue4fest

30.

1-3 ハイエンドを実現するために モーション・ボーン構成 ・社内汎用とUE4で 骨構造が異なる ・ボーン総数125本 社内汎用 UE4 #ue4fest

31.

1-3 ハイエンドを実現するために モーション・UE4構成の採用 UE4のボーン構成でモデルを作成することに ・社内汎用でもリターゲットできたが 対応にひと手間かかるため ・UE4構成の方が不安要素が少ない #ue4fest

32.

1-3 ハイエンドを実現するために モーション・プロトタイプデータの活用 購入した仮モーションで事前に完成形のステートマシンを作成しており、 モーションキャプチャの指示が的確にできた ・必要なモーションの尺、要素を割り出すことができていた ・上記ステートマシンに本番データを流し込んでもほぼそのまま運用できた #ue4fest

33.

1-3 ハイエンドを実現するために モーション・キャプチャモーションの扱い方 殺陣経験のある役者の方による高品質なキャプチャモーション ・微調整はしたが、基本的にはキャプチャデータを そのまま使用できた ・モーション速度はUE4側で調整 #ue4fest

34.

1-3 ハイエンドを実現するために モーション・めり込み対策 武器が体にめり込まないように 武器の形状に応じて腕の傾きを調整 Before After #ue4fest

35.

1-3 ハイエンドを実現するために キャラバリエーションをつけるにあたり 全キャラクターでボーン構成を統一 ・四脚など異形デザインは採用しなかった 1点集中してクオリティを上げるため #ue4fest

36.

1-3 ハイエンドを実現するために バリエーション ・体格 ・刺さった矢 ・角の有無 ・色 #ue4fest

37.

1-3 ハイエンドを実現するために バリエーション・体格と矢、角 ・体格はアニメーションBPで ボーンをスケール ・刺さった矢や角は予め刺さった 状態でスケルタルメッシュを用意 「Hide Bone by Name」ノードで 不要なものを非表示に #ue4fest

38.

1-3 ハイエンドを実現するために バリエーション・色 ・色はマテリアルを入れ替える ことで対応 #ue4fest

39.

1-3 ハイエンドを実現するために 物理アセット #ue4fest

40.

1-3 ハイエンドを実現するために 物理アセット 場所を限定して使用(前垂れや紐) ・物理エディタとゲーム画面とで物理の見た目が合わなかった ・調査せず「見た目良ければ良し」で実装した 特にバグも上がらなかったのでそのまま採用 #ue4fest

41.

1-3 ハイエンドを実現するために ステージ 主な使用ツール Maya ZBrush Substance Painter ポリゴン: 1区画 約110,000tris #ue4fest

42.

1-3 ハイエンドを実現するために ステージ・アセットクオリティを上げるために 遮蔽物の多いシチュエーションを採用 黒のfogを効かせ、視界を狭めることで アセットの質を高めることができた #ue4fest

43.

1-3 ハイエンドを実現するために ステージ・効果的に落ちる影 鳥居部分だけムーバブルにすることで効果的にキャラに影を落とせた ・全てのアセットが動的に影を落とす必要はない #ue4fest

44.

1-3 ハイエンドを実現するために ステージ・単調な見た目の回避 地面など、同じ見た目が続くと違和感が あるものはテクスチャをブレンドできるマテリアルを使用 Before After #ue4fest

45.

1-3 ハイエンドを実現するために ステージ・立体感のある壁と地面 壁や地面にはAチャンネルにHeight情報の 入ったマテリアルを使用 ・壁は100ポリゴン程度 #ue4fest

46.

1-3 ハイエンドを実現するために ステージ・デザイン作業に没頭するために ライトマップ用のUVを自動で展開してくれる機能を活用 #ue4fest

47.

1-3 ハイエンドを実現するために 演出 ハイポリゴンモデル、 動的光源を生かす演出 ・鍔迫り ・クリティカル、パリィ #ue4fest

48.

1-3 ハイエンドを実現するために 演出・ドアップ鍔迫りの実現 ・鍔迫りカメラに切り替えることで表現 ・武器ごとに鍔迫り用のsocketを用意し、 位置を合わせて再現 ・足元を見せないアングルにすることで 背の高さの違いによる破綻を回避 #ue4fest

49.

1-3 ハイエンドを実現するために 演出・直感的な気持ちよさ クリティカルとパリィは動的ライトを活用 ・HUDを省き、没入感を損なわないように ・光量が少ないため効果が大きかった #ue4fest

50.

1-3 ハイエンドを実現するために エンジニアリング デザイナーが用意したこれらのアセットを試しに表示 ・キャラクター +武器:50,000tris x 2体 ・ステージ :stat Engine コマンドで確認する 処理量の最大タイミングで100,000tris 程度 (マテリアルもデザイナーの希望クオリティ) #ue4fest

51.

1-3 ハイエンドを実現するために エンジニアリング 特に積極的な最適化はしていなかったものの ・当時最新だったiPhone7であれば意外にも快適に動作することを確認 ・Android はSnapdragon820で若干のフレームレート低下を確認 このクオリティレベルを基準として クオリティアップと最適化を行うことに決定 デザイナー主導でこの後も色々追加したことで最適化自体は苦労しましたが… #ue4fest

52.

1-3 ハイエンドを実現するために エンジニアリング ・デザイナー主導で高品質なビジュアルを作成できた デザイナーが使おうとする機能がモバイルで使用できるかどうかの確認や グラフィックスに関してはプレビューしやすい環境の構築が主な作業になった #ue4fest

53.

1-3 ハイエンドを実現するために プレビュー ・モバイルプレビュアを使用してエディタ内で見た目を確認しつつ作業 ・実機上での動作に不安もあったため、実機による確認は必須とし、 最終的なクオリティの確認には iPhone 6s を使用 #ue4fest

54.

1-3 ハイエンドを実現するために モバイルプレビュアでの表示確認 モバイルプレビュア 実機 ※画像はイメージです #ue4fest

55.

1-4ワークフローに関するTips #ue4fest

56.

1-4 ワークフローに関するTips バージョン管理ツールについて ・UE4本体ソース以外のプロジェクト内のファイルはアンリアルエディタの Subversionクライアント機能を使用してSubversionで管理 ・アンリアルエディタはContentフォルダ以下しか管理しないため それ以外のC++コードや設定ファイルはUE4と直接関連しないスクリプト等と共に TortoiseSVNを使い同じリポジトリで管理 Subversionクライアント機能はアカウントを設定するだけですぐに使用でき 素直に他のクライアントツールと同じリポジトリで運用すると扱いやすい #ue4fest

57.

1-4 ワークフローに関するTips バージョン管理ツールについて ・UE4本体のソースコードはプロジェクトリポジトリとは別に 社内変更分とともにGitで管理 ・公式ソースから変更の適用前・適用後でバージョンごとに2つブランチを分けて バージョンアップの際は変更前後のブランチ間差分からパッチを作成して 新しいバージョンのソースコードに適用して対応 エンジン本体とプロジェクトは別のバージョン管理ツールになったが UE4のバージョン管理環境と合わせて使用でき運用上問題は無かった #ue4fest

58.

1-4 ワークフローに関するTips ビルドの自動化 ・専用でビルドマシンを1台用意 コンソールからビルド、パッケージをモバイル端末のブラウザからダウンロー ドできるよう構成 Jenkinsから iOS, Android版のパッケージを常に最新でビルドし続ける ・参考:株式会社ヒストリア 様 「 ブログ [UE4] 4.9におけるパッケージングまとめ ~ProjectLauncher & Console編~」 http://historia.co.jp/archives/3684/ #ue4fest

59.

1-4 ワークフローに関するTips ライティングのバッチ処理 ・ステージのライトビルドをワンボタンで複数レベルの処理を連続実行できる ように整備 必要に応じてライトビルドを夜間実行 ・参考:株式会社ヒストリア 様 ブログ 「[UE4] ライトビルドをコマンドから実行しよう!」 http://historia.co.jp/archives/7343/ #ue4fest

60.

1-4 ワークフローに関するTips 環境の全体図(社内) #ue4fest

61.

1-4 ワークフローに関するTips C++かブループリントか ・ブループリントのほうが書籍やTips解説系ブログなど国内情報が充実 ・エンジニア以外へのレクチャのためにブループリントの習熟が必要 ・仕様規模からノードベースでもつくりきれると判断 ・開発期間の短さからエンジン起因のトラブルは避けたい状況 BPに公開されていない、情報が少なくエンジン内部に近い操作を要する機能の使用は 仕様を変更してもらってでも極力避けることに(HTTPなどどうしても必要な機能はある) 『修羅道』はブループリントベースで開発 #ue4fest

62.

1-4 ワークフローに関するTips ブループリントベースとした効果 ・公開されているTipsを手早く取り込め すぐに各機能の実装ができた ・エンジニア以外ともやりとりしやすく、調整値の 設定環境の作成が最低限の作業で済んだ #ue4fest

63.

1-4 ワークフローに関するTips C++の立ち位置 ・シンプルに1モジュールで構成 ・Character 等の主要なクラスは継承だけした空のC++クラスを継承して保険に ・バトル中のステータス異常関連の処理など数値処理の多い機能はC++で実装 いくつかの列挙体、構造体などをC++に移動する 必要は生じたものの根本的な作り直しは発生しなかった #ue4fest

64.

1-4 ワークフローに関するTips UE4 のソースコード使用とUE4改造のスタンス ・改造にかかるコストが高いと考え原則としては改造は行わない ・例外として、モバイルのOS機能周りについてのみ改造を許可 ・特に最初のレベルが読み込まれるよりも先に行いたい処理などエンジンの処理 をフックしないといけない場所のみで対応 パッケージ化するPCのみ変更を適用すれば済むため UE4の改造が作業環境に影響することは無かった #ue4fest

65.

1-4 ワークフローに関するTips UE4の改造箇所 – Android 向け対応 ・SaveData保存場所がユーザからアクセス可能な場所になっていたため変更 ・OBB(拡張ファイル)を使用すると一部端末では READ_EXTERNAL_STORAGEのパーミッションを取らないと OBBにアクセスできないため起動時に権限要求を行う (Galaxy s7 edge で確認) #ue4fest

66.

1-4 ワークフローに関するTips HDDネックの解消 ・特にパッケージング中、明らかにHDDネックになっていることを確認 SSDの導入でビルド時間を4割程度短縮 #ue4fest

67.

1-4 ワークフローに関するTips 最終的なPCスペック OS Windows 10 Pro 64bit CPU Intel Xeon E5-1620 v3 メモリ 16 GB グラフィック NVIDIA GeForce GTX 960 SSD 250GB x2 HDD 2TB この構成で重くなることも少なく快適に作業ができた #ue4fest

68.

期限に間に合いました ・2017/9/11 PV、第1報公開 ・2017/9/21 TGS出展 #ue4fest

69.

第2部:リリースに向けて、最適化 #ue4fest

70.

2-1 リリースに向けて #ue4fest

71.

2-1 リリースに向けて クオリティの押し上げ TGS版 リリース版※Ver1.1.3 #ue4fest

72.

2-1 リリースに向けて ポストエフェクトの調整と追加 ・Bloom ・Exposure Compensation ・Depth of Field #ue4fest

73.

2-1 リリースに向けて ハイライトのじらつきの緩和 Bloomを抑える BEFORE AFTER #ue4fest

74.

2-1 リリースに向けて コントラストの調整 Exposure Compensationで 中間色を増やす BEFORE AFTER #ue4fest

75.

2-1 リリースに向けて Depth of Fieldの実装 ・UE4アップデートにより Androidでも使えるようになった ※4.17 で修正確認済み #ue4fest

76.

2-1 リリースに向けて 臨場感の補強 パーティクルを 追加して臨場感を上げる ・蛍火 ・水滴 #ue4fest

77.

2-1 リリースに向けて ゲーム完成に向けての量産 86種類の武器の作成※Ver1.0.1当時 ・色違いのみの武器もあるが基本的に1点もの ・武器アセット86本で約200MB ステージの変化 ・鳥居など印象的なアセット以外はできるだけ使いまわし ・ポストエフェクトのMobile TonemapperのTintとContrastで 色味を変更 #ue4fest

78.

2-1 リリースに向けて 見た目の完成 #ue4fest

79.

2-2 最適化 #ue4fest

80.

2-2 最適化 クオリティを押し上げた結果 ・それなりに快適だった iPhone7 でも処理落ちする状態 ・Androidはさらにサーマルスロットリングによる速度低下が深刻 ・処理速度だけでなくバッテリーの減りも改善が求められる いよいよ最適化を開始 #ue4fest

81.

2-2 最適化 目標設定 ・低いスペックの端末では画質を落とすなどの対応は行わずに非対応とし 遊べる機種を限定してでも高品質なものとする ・目に見えるレベルのビジュアルクオリティは下げない #ue4fest

82.

2-2 最適化 目標設定 - Android 当時のハイエンドSoCだったSnapdragon820を下限端末に選定 ・処理落ち・熱の問題が大きかったものの、後継の Snapdragon 835 のモデルが 殆ど無かったため #ue4fest

83.

2-2 最適化 目標設定 - iOS iPhoneはiPhone 6sを下限端末として選定 ・2年前のモデルなら一定のシェアがあると考えたため ・同世代以降のiPad系デバイスもサポート #ue4fest

84.

2-2 最適化 最終的な目標 ・iPhone 6s以上 及び Snapdragon 820相当以上のAndroid ・30fpsの維持 ・iPhone系端末は r.MobileContentScaleFactor=2.0 を設定 ・Androidはデフォルト設定で基本的に r.MobileContentScaleFactor=1.0(1280x720) ・Androidにおけるサーマルスロットリングの抑止 #ue4fest

85.

2-2 最適化 最終的な目標 ・Android, iOS いずれも処理落ちしていたものの より処理落ちが深刻だったAndroidさえ動けばこちらは問題になることは無いと想定 →これ以降は基本的にAndroid端末で検証 (スライド上のデータもSnapdragon 820搭載Android端末でのもの) #ue4fest

86.

2-2 最適化 サーマルスロットリングについて ・端末の温度が高くなると自動的に速度を落として端末の冷却を図る機能 ・コンシューマやPCでは起きないモバイル特有の問題 ・特にAndroidでの影響が顕著で高負荷をかけるとすぐに速度が落ちる →1フレームあたり80msかかっていた場面では 約5分経過後、1フレームあたり140msにまで処理時間が増加し 端末性能が半分程度まで落ちることがあった 性能を100%使い続けられないので、高負荷状態が続かないようにする必要がある #ue4fest

87.

2-2 最適化 負荷状況の確認 ・stat fps, stat unit, stat unitgraph コマンド ・Snapdragon Profiler 最も処理落ちの激しかった下限端末 Snapdragon820 搭載 Android デバイス実機で 処理落ちする箇所を調べた結果、Draw, GPU の負荷の高さが問題と確認 ・参考:CEDEC2017 - Epic Games Japan 様 講演 「UE4 プロファイリングツール総おさらい(グラフィクス編)」 https://www.slideshare.net/EpicGamesJapan/cedec2017-ue4 #ue4fest

88.

2-2 最適化 UE4の動作要素 ・Game CPU:ゲームの世界を更新してキャラクターの位置や動きを確定 ・Draw CPU:Gameで決定したシーンを解釈して描画命令を発行 ・GPU GPU:頂点やピクセルを計算して画面に表示する絵を作成 #ue4fest

89.

2-2 最適化 Draw負荷の低減 特にスタティックメッシュの描画に時間がかかっていることを確認 ・いくつものスタティックメッシュをレベルに配置してもらう方法で 背景をデザインしており、ドローコールを大きく減らす余地がある →アクターのマージ機能でドローコールを減らすことに #ue4fest

90.

2-2 最適化 アクターのマージ レベルは全部まとめてしまうとクリッピングが効かなくなってしまい、 逆に重くなってしまうので程よく、負荷状況を見つつマージ 特に重かった場所 ドローコール Draw 数 処理時間 マージ前 1,120回 85ms マージ後 185回 33ms #ue4fest

91.

2-2 最適化 アクターのマージ 編集用と書き出し用のレベルを用意し、編集用はアセットがばらばらの状態、 書き出し用はマージしてまとめたものと分けていた 配置変更のたびにマージが必要になるためマージ後の微調整は大きな手間 今回は実現できなかったがエディタプラグインなどで自動化できればもっと良かった #ue4fest

92.

2-2 最適化 GPU負荷の低減 パーティクルの描画に時間がかかっていることを確認 ・ステージに浮かぶ炎もカメラに近づくなどで使用ピクセルが増えると 非常に負荷が増える 演出効果の薄い背景の小さな炎にパーティクルを使っている部分も確認 →パターンアニメへの置き換えをすることに #ue4fest

93.

2-2 最適化 パーティクルをパターンアニメに変更 アイテムの表示などに使用しているパーティクルや 見た目のサイズが大きなパーティクルは パターンアニメのビルボードにして負荷低減 #ue4fest

94.

2-2 最適化 パーティクルをパターンアニメに変更 ・数が多く、かつ小さくて静止している背景の蝋燭の炎はマージできない ビルボードは使わず、板ポリゴンを2枚十字に重ねてからマージ ・パーティクルへの対策だったが CPUの処理時間に対する効果が高かった ボスバトルの場面の場合 炎アクター数 Draw処理時間 Game処理時間 対策前 128個 71ms 29ms 対策後 1個 65ms 25ms #ue4fest

95.

2-2 最適化 視覚化機能による問題個所の確認 ・問題になっていそうな箇所を分かりやすく簡単に確認できる 怪しい箇所をエンジニアが手元で軽く調整してみて効果の程を確認 Lightmap Density, Shader Complexity の調整で効果が確認できた #ue4fest

96.

2-2 最適化 ・Lightmap Density - ライトマップ密度の高い部分を修正 #ue4fest

97.

2-2 最適化 ・Shader Complexity - エクスポートミスで表示されている判定ポリゴンを削除 #ue4fest

98.

2-2 最適化 描画APIの選択 ・iOS は当初より Metal を使用していた 元々GLES3.1より高速な動作を確認しており、動作も安定していた #ue4fest

99.

2-2 最適化 描画APIの選択 ・Androidは Vulkan に変更 Experimental とされており検証段階で不安定だったため避けていたが 残りの期間が少ない中、サーマルスロットリングが依然発生していたため Vulkanを有効にして負荷を下げる方法しか取れる手が無い状態だった →当時の最新版で再度検証を行った結果、一部の端末でちらつく不具合があったものの 以前との比較では安定してきていたため採用 UE4.20現在もExperimentalとされており、Android版については注意が必要 #ue4fest

100.

2-2 最適化 その他の最適化 ・異方性フィルタのオフ →16%程度のGPU負荷改善 ・テクスチャ解像度の変更 キャラクターのテクスチャサイズを 2048x2048 から 1024x1024 に変更 →2体分で 7% 程度のGPU負荷改善 #ue4fest

101.

2-3 ここが困った #ue4fest

102.

2-3 ここが困った UE4特有の不具合 ある程度致命的なものがリリースされているものから出てくることが →UE4.17.0 で立体音響がiOSデバイスの左右片方からしか音が出ない (現在修正済み・未確認) →UE4.18.3 でパッケージングしたバイナリがリジェクト(現在修正済み) 等々… AnswerHub, Unreal Engine Issues の事例を検索して対応方法を検討 立体音響などかなり先のバージョンで修正予定と判明して断念した表現も… アップデートを続ける運営型のゲームには注意が必要 #ue4fest

103.

2-3 ここが困った ボーン数の制限が追加 ・キャラモデルの使用ボーン数 125 本 ・UE4.20でES3.1環境下で(Metal, Vulkan 含む) スケルタルメッシュのボーン数が75を超えると アサートに失敗する仕様が追加 エンジンコード変更による上限の変更で修正 #ue4fest

104.

2-3 ここが困った ブループリントのネイティブ化 ・ネイティブ化ツールは不具合による制約から断念 ・マップ型変数を使用するとネイティブ化に失敗する不具合が Unreal Engine Issues に掲載されていることが判明(修正済み・未確認) →使うつもりだったものの途中から有効にしたことも問題 使う気があれば初期から有効にして様子を見るべきだった リアルタイムに複雑な処理を多数行うようなゲーム性ではなく、 より描画周りに改善の余地があったため今回はこのまま #ue4fest

105.

2-3 ここが困った UE4の不具合の調査方法のまとめ ・クラッシュやモバイルでの問題はXcodeなどデバッガを実機に接続して問題個所の調査 ・githubからソースコードを取得して差分の確認(コミットが多数まとめられていると難しい) ・古いUE4で起動して異常のあるバージョンの調査 ・Forum, AnswerHub, Unreal Engine Issues で事例検索・質問 小手先の対応でなんとかなるものもあれば、内部知識を要し手元での対応が難しいものも モバイル含め特に続々と機能が追加される部分については検証をしっかり行う必要がある #ue4fest

106.

まとめ #ue4fest

107.

まとめ ・モバイルでもハイエンドグラフィックはできる ・一点集中でクオリティを高められる企画を ・最適化は支援機能を生かして的確に ・どの機能もまずは一回動かすことが重要 ・運営系のタイトルの場合、エンジンのアップデートは大変 #ue4fest

108.

ご清聴ありがとうございました #ue4fest