UE4におけるレベル制作事例

V F X S T U D Y G R O U P©2019 SQUARE ENIX CO., LTD. All Rights Reserved.
株式会社スクウェア・エニックス吉田武史
U E 4 におけるレベル制作事例

略称について
・『Unreal Engine 4』をスライド内では『UE4』と記載しています
・『PlayStation®4』も同様に『PS4』と記載しています
・一部『ブループリント』を『BP』と記載しています

本プロジェクトは UE4.17.2 を使用して作成されており
本スライドの内容もそれに準じて作られております。
最新バージョンでは挙動、もしくはソースコードが
変更されている可能性がありますのでご了承ください

まずは自己紹介

自己紹介
吉田武史
プログラマー。
入社して現在ちょうど4年目。UE4 歴は５年目。
（１年はBPでの開発、残りはC++とBPの両方を触る）
元々はブループリントのサポート担当で配属されましたが
色々と雑務をしている内にレベルプログラム担当に。

今回お話する内容について

• ブループリント
• レベルの構成
• レベルストリーミング
• レベルの最適化
今回お話する内容

今回お話する内容
オブジェクト継承のブループリントと
レベルブループリントをメインに
解説していきます。

どれくらい使っていた？
ブループリント

本プロジェクトでは
プランナー、デザイナー、プログラマー
どのセクションでも高い頻度で使っていました。
どれくらい使ってた？

各セクションが
どういった感じで使っていたかというと……

プランナー
・「仕掛け」の作成
・ゲーム性検証
・ミニゲーム作成
・カメラ挙動作成
プログラマー
・「仕掛け」の作成
・ミニゲーム作成
デザイナー
・見た目の調整
・演出強化
こんな感じで使っていました。
・「仕掛け」とは……
ボタン等のプレイヤーからのアクセスで起動するオブジェクトや
プレイヤーの進行を阻害する為に動作しているオブジェクトの事を指す。

使う上でのルール

BPのTickはなるべく使わない

理由は２つあり……
・処理負荷が上がるのでなるべく使いたくない
・Tick を使う＝複雑な物になりやすい
・呼び出しイベントから実行して終わる程度の
シンプルな流れで済ませたい

・「完全に使わない」ではなく「なるべく使わない」
・必要な場面であれば使用
・使用する場面のみON、使用後はOFFといった感じで
常にTickをONにするという事はほぼ無かった。

プログラマー側では
どの Tick が動いているか定期的に調査。
不要な物が見つかった場合は担当者に連絡し
実装方法に関してすり合わせをしていた。
最終的にこの流れが浸透し、Tick 使用率は自然と減少傾向に。

親クラスはなるべくC++クラスに

・これも絶対ではなく「なるべく」
・重たい処理があってもC++に逃がしやすい
・C++であれば実機デバッグ時にコード修正だけで確認可能
・C++からの継承コンポーネントも除去可能

RazorCPU などのプロファイラーとも相性がよくなる。
コールスタックから、どのオブジェクトか判断が付きやすい。
本プロジェクトでは処理負荷はTest版で見ており
こちらで仕込んだマーカーで負荷を確認する事が大半だった。

その他気になる点としてBPクラスロード時に
親BP が持つアセットを芋づる式に呼んでしまう問題がある。
C++クラスでも同じ作りは出来るが
コーディングルールとして禁止していた。

インプットイベントはエディター限定に

インプットイベントはエディター限定に
キーボードイベントを利用してのデバッグは
非常にお手軽で便利なのだが
製品版に残る可能性がある為
レベル上で設定できるインプットイベントは
エディター以外では無効にするようにした。

BPマクロの活用

・各作業者が独立した設計を避ける為にBPマクロを積極的に使用
・使用頻度の高いノードも事前にBPマクロでラッピングしている

・ BPマクロの中身は定期的にプログラマー側で確認。
・整理できる部分は作成者と相談してリダクションする。

定期的にBPの中身をプログラマーが確認

・開発末期でもいいので確認する工程が必要
・奇想天外な物、複雑な物がよく見つかる。そういった場合
担当者と話し、最適な修正方法を話し合う必要がある。
使われてない変数が見つかったり
Transient フラグを付けた方がいい物が
いっぱいあった。

BPクラスへのCastも注意が必要。
Cast したクラスが BP クラスだった場合
その BP クラスを参照する形になりロード対象となってしまう。
BPをCastすると、このBPも読み
込み対象になってしまう。Castし
たBPがレベル上に存在するのであ
れば問題ないが、存在しないので
あれば無駄な読み込みとなる。

使用して困った事
• 良かった所と悪かった所

「何でも出来る」それが仇になる場面も…

「何でも出来る」それが仇になる場面も……
ブループリントは実装が早い事が利点ではあるものの
チカラづくで実装された物も多く
後に現れる複雑な仕様に対応できず
大きな問題に発展する事も多々あった。

そういった物の大半は
プログラマーから見ると簡単に対応できる案件だったり
コードで組んだ方が楽という物も多かった。

何はともあれ
雲行きが怪しくなってきたら
プログラマーに相談するのが一番ベスト。

パフォーマンス面で問題が多数

ブループリントノード、コンポーネント周りで
想定外の使われ方をしている物が多数存在していた。

特にコンポーネントは凄まじい数で
つけられている物があり
そこから発生する Tick 負荷や
アクター移動・回転時の
コリジョン負荷が目立っていた。

この他では ChildActorComponent が起因の
バグ・処理負荷も多く起きていた。
根深い問題に関してはプログラマー側で作り直し
それ以外は相談して対応で済ませていった。

最終的には知見が溜まっていき
パフォーマンス面の問題は発生しづらくなっていった傾向に。

可読性の低い物が多く、作りに性格が出る

可読性の低い物が多く、作りに性格が出る
人間だもの。仕方がない。
※ 再現画像を用意しようと思いましたが再現が大変すぎて諦めました。

バグが非常に多かった

使用しているセクションが多く
BPの習熟度は人それぞれ、かつ性格も出るので
バグの種類もバリエーション豊かに。

思い出深いバグを下記に……

・Latent（ Delay ）を多用しすぎて処理順が崩壊

・BeginPlayでイベントフラグを立てたままサブミット → 原因不明のバグに。

・イベント途中でアクターの表示をOFF → そのタイミングで
イベントスキップしたらイベント終了後に表示が消えっぱなし。

・イベント途中でアクターの表示をOFF → そのタイミングで
イベントスキップしたらイベント終了後に表示が消えっぱなし。
・バグを修正したが、対処が甘く他のバグを生み出した。

多くのバグは人為的ミスによるものだったので
全てのカスタムイベントや特定のアクターの配置情報を
Csv、もしくはテキストで書き出すコマンドレットを作成。
それを参考に各セクションが人力で対処するという形で収まった。

設計ミスで発生した物はプログラマーが引き取り対処。

嬉しい誤算もあって
終盤ではどのセクションも多くの失敗経験をしたおかげで
簡単なバグならプログラマーを介さず対処できるようになっていた。

作成して有用だった機能

『Bool』から『Bit』への機能修正

ある程度の規模のゲーム開発になると
想定していない所でフラグが書き換えられる事が多々ある。
表示周りだと
「OFFにしていたのに知らぬ間にONになっていた」
という事がよく発生する。

ブループリントがある以上
他の作業者から書き換えられる事もあれば
システムを制御するマネージャーから書き換えられる事もあり
UE4標準の Bool での制御では耐えきれない事が
早期に分かっていた。

そこで一部の機能は Bool で扱うのではなく
Bit として扱うように改造。
「セクション」「カテゴリー」といった単位でビットを振り分け
１つでもビットが落ちている場合は
結果を False にするような仕組みを作成した。

表示切替のサンプルを用意しました。
Hidden が Bit をどう扱うか。
Category がどの Bit を使うか。

最終的に Bit へ機能変更した物は下記に。
・表示の切り替え
・コリジョンの切り替え
・TickのON、OFF
これらはアクター版、コンポーネント版の二種類がある。

この機能が出来た事によりブループリントのノードも
UE4標準のものではなくプロジェクト専用の物に置き換えた。
機能作成前はフラグの切り替え周りで
ワーストケースが頭にちらついていたが
機能作成後は特に問題がなく運用できたので非常に良かった。

また、プロジェクトが末期になると
・特定の条件下で特定のオブジェクトの表示を消したい
といった案件もよくあり、その部分も本機能で乗り切れた事が多
かった。最終的には１７ビット分の役割が当てられていたので活用
する場面は多かったと思える。

ブループリントのお話は以上です

次にお話する内容
レベルに関する情報を
あっさり目に
説明していきます

レベル構成
１パーシスタントレベルのサブレベル数
少ない所で３０、多い所で２００弱程度。
サブレベルが多いと管理が大変で
特にレベルストリーミング周りの制御は非常に難航。

レベル構成
１パーシスタントレベルのアクター数
アクター数は多い所で１６０００、少ない所で８０００程。
これはエディター上で表示されている数値で
動的に配置されるアクターも存在するので
実際にはこれよりもうちょっとだけ多い。

レベル構成
１パーシスタントレベルのアクター数
ただし、インゲームではレベルストリーミングの関係で
大部分のアクターが削られる。
実際のゲームではもっと少ないアクター数で動いている。

サブレベルのカテゴリー
レベル構成

・ゲームフロー
・エネミー
・背景
・エフェクト
・サウンド
・仕掛け
レベル構成
・リアルタイム演出
・カットシーン
・ボイス
・NPC
・宝箱
・ミニゲーム
・専用ミッション
・風
大まかに下記のようなカテゴリーで分けられている。

ゲームフローとは？
レベル構成

レベル構成
下記をブループリントで作成する事を指します。

レベル構成
・パーシスタントレベルの BeginPlay からゲームが始まるまでの流れ

レベル構成
・各サブレベルとRemoteEventを使ってのやり取り

レベル構成
・ボリュームとオーバーラップした際の処理

レベル構成
・ミニゲーム、カットシーン等のフロー

レベル構成
・レベル表示周り処理（レベルストリーミング含む）

レベル構成
・レベル表示周り処理（レベルストリーミング含む）
プランナーが
左記の項目を
実装していた
（一部例外あり）

サブレベルの切り分け
レベル構成

レベル構成
サブレベルは全て表示すると負荷的に耐えら
れない為、表示や地形的にキリが良い単位で
細かく分解、切り分けている。
※右図で説明すると各エリア単位で
サブレベルを用意している

レベル構成
切り分けたサブレベルは
プレイヤーの立ち位置によって
表示・非表示を制御している。
・エリアＡにいる時はエリアＢを表示、エリアＣを非表示
・エリアＢにいる時はエリアＡとエリアＣを表示

レベル構成
切り分けは各サブレベルの担当者が行っている。
例）「仕掛け」ならプランナー、「BG」なら背景
コンセプト的に全ステージが
ユニークな形状をしているので
切り分けのルールはステージ毎に変わっていた。

レベル構成
各レベルの表示制御はプランナーが担当。
・ボリュームに接触
・ゲームの進行状況に応じて
上記をトリガーにレベルの
表示・非表示を制御している。

レベル構成
処理負荷、レベルストリーミングの関係で
問題が出る場所（※）もよくあったので
切り分けと表示周りの作業は終盤まで長引いた。
※表示されるべき物が表示されてない、
ロードが間に合わない。

レベル構成のお話は以上です

次にお話する内容

まず初めに
レベルストリーミング

難題が多く見送っていたレベルストリーミング

・以前の検証結果ではスパイクが凄まじく商品として耐えられない

・一部のマップはレベルストリーミングを考慮してない作り

・プレイヤーの移動速度は爆速（高速突進移動、ワープ技所持）

・アクター数がかなりある上、使用アセット数も膨大

・ストリーミングが間に合ってない時の事も考えないといけない

・ストリーミングが間に合ってない時の事も考えないといけない
上記が理由で対応していなかったのだが……

メモリが枯渇。実装しなければいけない状況に

メモリが枯渇。実装しなければいけない状況に
本プロジェクトでは１レベルにおけるアセット数が
凄まじく多く、マルチプラットフォーム故に
片方だけメモリが足りない状況も多々あり
結局対応せざるを得なかった。

使用する上で困ったところ

スパイク（処理負荷）

スパイク(処理負荷)
スパイクの原因の大半はガベージの負荷。

この問題はエンジン改造 + データ調整で対応。
・内容は以前 Epic Games Japan 様が講演された内容（※）とほぼ同じ
※「UE4におけるLoadingとGCのProfilingと最適化手法」
https://www.slideshare.net/EpicGamesJapan/420-ue4loadinggcprofiling-108367408
また本プロジェクトでは
UE4.20で実装された分散ガベージにも対応。

ガベージの検索コストを削る為に下記も実行。

・UObjectは限りなく削る

・UObjectは限りなく削る
・不要なコンポーネントは作成者とすり合わせ、徹底的に削る努力をする。

他には下記変数をパーシスタントレベル毎に調整
・GAsyncLoadingTimeLimit
・GPriorityAsyncLoadingExtraTime
・GLevelStreamingActorsUpdateTimeLimit
・GLevelStreamingComponentsRegistrationGranularity
・GLevelStreamingComponentsUnregistrationGranularity
・GLevelStreamingUnregisterComponentsTimeLimit

しかし、これらを対応しても
まだまだスパイクが発生するのが実情……
原因を調べていくと２箇所が負荷が高まる所があった。

ひとつ目は ULevel::RouteActorInitialize 。
この関数は端的に言うと
レベルストリーミングのロード時のアクター初期化を行う部分。
この部分でスパイクが発生していた。

見るべきレベルもかなり多く
毎回プロファイラーで調べるのも苦だったので
ULevel::RouteActorInitialize がある一定の負荷を超えた際
画面上にアクター名 + 処理負荷量付きで表示するように改造。

また ULevel::RouteActorInitialize の中身の処理は
アクターによっては「不要」「必要」
と別れていたのでフラグを追加し
それを元に実行するかどうかを判断させるようにした。

次に気になったのがナビゲーションメッシュの更新周り。
ストリーミングでアクター（※）が生まれてくる際に
ナビメッシュの更新を行うものがあった。
※ 主にNavLinkProxy、NavModifierVolume、
NavModifierComponent が付いているアクター

調べていくと UNavigationSystem::Tick 関数の
NavData->TickAsyncBuild(DeltaSeconds) 周辺が
スパイクの原因になっていたので
この処理の負荷が極端に上がった時は
画面上に負荷を表示するようにした。

長きに渡る調整の結果
レベルストリーミングのスパイクは大きく軽減。
ただし調整後に敵の配置やレベル調整、アセット調整で
日によって結果が変わる為、ほぼ終わりまで監視する形になった。

パッケージを使用してのチェック

限りなく製品版に近いアセット構成やプログラムでないと
実際のストリーミングの挙動が分からないので
Test版パッケージを使用して毎日チェックしていた。

しかしパッケージは作るのに時間がかかるのがネック。
修正しても次回パッケージまで修正確認ができない。

更に苦しいのが
ロードが間に合わないからストリーミングの位置をずらした
といった理論的ではなく感覚的な修正が多くなるのも辛い所。
修正しても内容に満足できず
何度も繰り返し修正した所も多かった。

唯一救いだったのがどのハードも
パッケージデータを使用してのプログラムのみ差し替え実行
が出来たのでプログラム的な問題は素早く対応できた。
ロードもエディターより早かったので一部のプログラマーは
エディターではなく実機での調整時間の方が長かった。

他のAsyncLoadと競合

AsyncLoad 発生中にレベルストリーミングを行うと
先に行われた AsyncLoad が終わるまで
レベルストリーミングはサスペンド状態となる。

この問題の厄介な所は
パッと見では何故止まっているかが分からない点。
単純に「ロードが長いだけかも」と疑うだけで
終わってしまう可能性がある。

この後に紹介予定の
サブレベルの状態変更時に画面上に表示するデバッグを
作っていたおかげで中身があまり入ってないサブレベルなのに
異様にロードが長い時がある事が分かり
この問題の原因究明に繋がった。

本件は一部の場所で
動的にデータが読まれる事が原因だったので
プレイヤーが問題の場所にいる時に限り
動的に読み込まれるデータを常駐データ扱いにして
AsyncLoad が発生しないようにして対応した。

作って便利だった機能

サブレベルの状態を
画面上に表示するデバッグ機能

サブレベルの状態を画面上に表示するデバッグ機能
・レベルストリーミングを行っているレベルをテキストで左上に表示
・レベルストリーミングが発行されたタイミングで右上に
どういった発行内容だったか（ロード切替？表示切替？）を
3秒間テキストで表示
上記のデバッグ表示機能を作成。

「 Stat Levels 」と違うのは
現在実行中の物しか表示されないので
見落としが少ないという点。

このデバッグはQAチェック、
ストリーミング周りの不具合を調べる時に非常に重宝した。
レベルがどの順番で遷移しているかも見る事が可能で
「ロード」「表示」にどれくらい時間がかかっているか
簡単に分かるので有用なデバッグだった。

レベルストリーミングのお話は以上です

レベルの最適化
入ってきた当初、処理負荷は100msを超えていた
自分が本プロジェクトに入ってきた時、実機での処理負荷は
Gameの負荷が100msを超えている状況。
原因の大半はレベルに配置されているアセットで
作業者各位がルールも特になく自由にアセットを作っている為
処理負荷の高いアセットが山ほど存在していた。

入ってきた当初、処理負荷は100msを超えていた
自分も UE4 の処理負荷削減経験がなかった為
最初は何が重たいのか全く分からなかった。
ゲーム実装作業の裏で、それらを簡単に発見する為の
処理負荷計測用ツールや機能を充実させる事から始める事に。

独自の処理負荷計測ツール & 機能紹介

サブレベルデバッグUMG

サブレベルを選んでロード・アンロード可能なデバッグUMGを作成。
ゲーム内の負荷が高い際に一つずつレベルをアンロードしていき
どのレベルが重たいか当たりをつける為に使用。
次のページで実際の画像を紹介します。

• 独自の処理負荷計測ツール & 機能紹介
• サブレベルデバッグUMG

• 独自の処理負荷計測ツール & 機能紹介
• サブレベルデバッグUMG
実際の物より少し改造していますが
イメージはこんな感じです。
キーボードで操作する事を前提にしています。
今選択しているレベルを
「ロード」「アンロード」「表示切替」
する事ができます。

このデバッグ機能の良かった所は
どのセクションでも手軽に調べられ
どこが原因かを洗い出しやすいといった所。
実装も難しくなく、サブレベルを多く使っている
チームにオススメのデバッグです。

負荷が高い物を画面に表示

既に何度か書いておりますが
手軽に見れるように負荷の高い物は画面上に
・アクター（or アセット or 関数）名＋処理負荷付き
で表示するように改造。

UE4の場合 FAutoConsoleVariableRef を使えば
コンソールコマンドからデバッグのON・OFFが簡単に可能。
非常に便利なので使ってない方は是非使ってみてください。
※ FAutoConsoleCommand もオススメです。

専用CPUプロファイラー

最適化班から専用CPUプロファイラーを用意していただきました。
リアルタイムに下記の要素が確認可能です。

・各スレッドの使用状況を表示（どのカテゴリーで処理を食っているか見れる）

・各 TickGroup の Tick 数

・登録された関数で負荷が高い物を順に表示する機能

・タイムライン（スパイク検知用）

・タイムライン（スパイク検知用）
・ポーズ & 巻き戻し（スパイクが発生した際、巻き戻って何が重たいか確認可能）

処理負荷を落とす為にやった事

並列Tickシステム

並列Tickシステム
本プロジェクトの中期以降に作られたシステムで
余ったCPUを活かす為に作成しました。
残念ながら完成した時期が遅かった為
一部のオブジェクトのみ、このシステムを使用しています。

並列Tickシステム概要

ゲームスレッドも使用して並列処理を行っています。また処理毎に
・ゲームスレッド専用処理
・どのスレッドでも実行可能処理
といった区分で分ける事が可能です。
ゲームスレッドと他スレッドを使って分散処理

どうしてもゲームスレッドから離せない処理は
「ゲームスレッド専用処理」に区分させます。
他スレッドでは別の処理が実行されているので
ゲームスレッド専用処理が増えすぎなければ処理は分散されます。
ゲームスレッドと他スレッドを使って分散処理

UE4の物とは別に専用の Tick カテゴリーを持っています。
なので処理順をある程度操作する事が可能です。
専用のTickカテゴリーを持っている

エンジン部分も適用したい場合は
エンジン内部で定義する必要はありますが
自分のプロジェクトだけ反映したい場合は
無改造でも簡単にできます。
作りはシンプルでエンジン無改造でも可能

並列Tickシステムの効果

５００体ほどアクターが動き回るエリアがあり
全てTickを実行している所があったので
「PS4 Test版PGOなし」で処理負荷を計ってみました。

結果は下記となります。

・UE4標準Tick実行 6.91 ms

・並列TickをOFFで実行 6.04 ms（ -0.87 ms ）

・並列Tick実行 2.65 ms（ -4.26 ms ）

・並列Tick実行 2.65 ms（ -4.26 ms ）
4.26ms 減少は中々良い結果……！

並列Tickシステムの難点

最大の難点ともいえるべきかもしれません。
バグが出た時、原因を探りにくいといったデメリットもあります。
慣れてないと深刻なバグも引き起こしやすく
滅多に発生しない稀バグも並列化が原因の事が多いです。
バグを生み出しやすい

並列化したい部分が少ないとシングルスレッドで
回していた方が早い局面も多々あります。
特に実装し始めはこの問題に直面しやすく
「やる価値あるのだろうか」と心が折れがちです。
並列化したい部分が少ないと逆に遅くなる事も

パフォーマンスを出す為には処理順も考えなければいけません。
具体的には負荷の高い処理を先に、負荷の低い処理を後にするよう
にしなければいけません。
処理順も考慮しなくてはいけない

下図はよくない一例です。色の付いたバーが「処理」で、今回の例で
は三つ処理が動いているとお考えください。

最終的に全ての処理が終了しなければ次へ移行できません。現状はオ
レンジ色の処理が一番負荷が高く、最後に来ている為、終了処理への
移行が遅くなっています。
処理の終わりが
ここになってしまうので
処理負荷が増える。

これを解決するにはオレンジを最初に処理させ、その裏で他の処理を
消化させるのがベストです。

本プロジェクトではこの問題を対応する為に
「各実行処理にプライオリティをつける」事や
「処理を分散して実行する機能」で対応しました。

距離による表示制御

距離による表示制御
距離に応じて一部のオブジェクトの
表示を制御（近ければON、遠いとOFF）するシステムがあります。
表示がOFFの時に TickもOFFにするオプションもあります。

移動オブジェクトのコリジョン制御

コリジョンを持つオブジェクトの
移動時の処理負荷が高かった為
・近距離でコリジョン ON
・遠距離でコリジョン OFF
と制御している物があります。

プレイヤーには飛び道具、ワープもあれば
仲間も自由に動いている為、安直な対応はできませんが
不自然にならない程度で対応しています。

厳密なTick制御

厳密なTick制御
Tick は中身が何も記述されてなくても使用するだけで
それなりの処理負荷が発生するので
不要な物は徹底的に切っています。

厳密なTick制御
動的な制御もしています。
例えば宝箱。
開ける時のアニメーションをしている時だけ
SkeletalMeshComponent の Tick を ON 、
それ以外では Tick を OFF にする等です。

厳密なTick制御
その他ではマネージャーとなるシステムを用意し
特定のアクターの更新関数をまとめて呼んでいる物もあります。
アクターDの更新処理
アクターＡの更新処理
アクターＢの更新処理
アクターCの更新処理
マネージャー
のTick

レベルの最適化のお話は以上です

最後に

ご清聴ありがとうございました！
UNREALはエピック・ゲームズ・インコーポレーテッドの商標または登録商標です。
PlayStationおよびPS4は株式会社ソニー・インタラクティブエンタテインメントの商標または登録商標です。
その他掲載されている会社名、商品名は、各社の商標または登録商標です。

UE4におけるレベル制作事例

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a UE4におけるレベル制作事例

Semelhante a UE4におけるレベル制作事例 (20)

Mais de エピック・ゲームズ・ジャパン Epic Games Japan

Mais de エピック・ゲームズ・ジャパン Epic Games Japan (20)

UE4におけるレベル制作事例