UE4における大規模レベル実装ワークフローとブループリント活用事例

©2019 SQUARE ENIX CO., LTD. All Rights Reserved.
株式会社スクウェア・エニックス大野和貴
林要一
U E 4 における大規模レベル実装ワークフローと
ブループリント活用事例

略称について
・『Unreal Engine 4』をスライド内では『UE4』と記載しています
・『ブループリント』も同様に『BP』『レベルBP』と記載しています
注意事項

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

本講演にて、レベルBPの記述を一部公開させて頂きますが
弊社内で拡張されたノードや機能が多数存在します。
ぼかし等、一部の画像加工についてはご了承ください。
注意事項

講演に先立ちまして…

弊社大阪チームが講演/公開させて頂いたスライド群
• UE4におけるエフェクトの基本戦略事例前半/後半
• UE4におけるエフェクトの為のエンジン改造事例
• UE4におけるレベル制作事例
• UE4におけるアニメーション制作事例
• UE4における自動プレイのポストモーテム
• 実行速度の最適化のあれこれプラスおまけ
• UE4における大規模背景制作事例（コリジョン編）
• UE4における大規模背景制作事例（データメンテナンス・大技設定編）
• UE4における大規模背景制作事例（描画特殊表現編）
• UE4における大規模背景制作事例（最適化ワークフロー編）
• 大規模ゲーム開発のキャラクターマテリアル制作例
• 大規模ゲーム開発におけるフリーラン実装事例
• 大規模ゲーム開発における大技発動仕様事例

一部内容が本講演と重複しておりますが
プログラマー視点での講演です。
職種を問わずご覧頂く事をおススメ。

サブレベルの構成や背景との作業分担について
一部、内容の重複がございます。

自己紹介

大野和貴
レベルディレクター
• レベルの企画/実装全般
• レベル実装に関する運営/進捗管理
• レベル実装ワークフロー管理
• 他セクションとの連携構築など。
自己紹介

林要一
リードレベルデザイナー
• レベルの企画/実装全般
• ゲーム全体の進行接続
• レベルBP運用や実装ルールの管理
• レベルBPマクロの作成/管理など。
自己紹介

本日お話する内容

• なぜ企画がブループリントを多用したのか？
• レベル実装のワークフロー
• レベル構成とサブレベルの切り分け
• レベルブループリント記述/実装事例
• レベルブループリント活用下でのバグ分布
• まとめ
本日お話する内容

なぜ企画がBPを多用したのか？

• ギミック(ゲーム中の仕掛けなど)関連の実装（企画/プログラマー問わず）
• ゲームの進行や実装（レベルＢＰ）
• レベルストリーミング（プログラマー実装とレベルＢＰの連携）
• ミニゲームの実装（プログラム実装＋ノード化によるＢＰ制御）
• ゲームプレイ中の演出やカメラの挙動（プログラム対応＆マチネ＋ＢＰ）
• カットシーン中の表示物制御、および演出の流れ制御（マチネ＋ＢＰ）
• 演出中のテクスチャー遅延対策（プログラム対応＋レベルＢＰ側への仕込み）
• キャラクターや背景の見た目（シェーダ）調整
• ゲーム進行による背景物の変化（背景のＢＰアクター、レベルＢＰによるサブレベル切替）
• ライティングシナリオの切り替え（背景のレベルＢＰ）
• バトル中の周囲環境変化（エネミーからの通知を受けてレベルＢＰで処理）
• タイムラプス演出（マチネ＋背景のレベルＢＰ）
• サウンドの制御（弊社サウンドドライバーとＢＰ連携） …etc
本講演のプロジェクトで B P を使用した部分

そもそも・・・
BP主体の大規模開発は成立する？
B P 主体の大規模開発は？？
Q

少し否定的になりますが、
難しいだろう
と言うのが自分たちの見解です。

弊社一部プログラマーの見解を引用
（総意では無い）

"ブループリントはC++よりもパフォーマンスが出ません。
大規模プロジェクトのような実装物が多いプロジェクトは
ブループリントを主体にすると
クオリティコントロールが非常に難しく
理想とするゲームの作成が難しくなると思います。
どの部分をブループリントにして実装するか
プログラマーと密に話し合う必要があります。"

総意では無い（※重ねて）

“主体”ではなく“活用”
BPを使う比率や範囲の制御が重要

なぜここまで活用する事に？
B P をここまで活用するに至った経緯
Q

• 仕様の検討や追加、細かい要望が多くとにかく反映速度が重要だった
• 実装の検証段階では企画が触ってみて動かすという程度の物だった
チーム体勢を整えていく中で本格的にＢＰ活用の流れとなった
• 大阪開発でUE4の小規模タイトルがあり
その際の実装実績とワークフローを活かす形で発展させた結果
• 後、触ってて楽しい！！

本プロジェクトは…
• ワールド毎にワンオフ仕様が非常に多かった
• とにかく動かして確かめるというところが重要だった
• 手探りながらも多少の慣れが芽生え始めていた

現在の進行
• なぜ企画がブループリントを多用したのか？ Done
• レベル実装のワークフロー
• まとめ

レベル実装のワークフロー

そもそも、どういうゲーム？
そもそも、どういうゲームなのか？
Q

ジャンルは３DのアクションRPG

ワールドマップ
ワールドマップと呼ばれる
だだっ広い空間があり……

ワールド２
ワールド３
ワールド１
ワールド４
そのワールドマップの中に
複数のワールドが存在します。

ワールド１
ワールドは
などの要素で構成されています。
この１ワールドについて各パートが担当者を立て
ゲーム進行や遊び、背景を実装していきました。
バトルカットシーン探索
ミッションミニゲーム

ロケーション１
ロケーション２
ロケーション３
ワールドの中は
ロケーションと呼ばれる単位で
さらに分割されており
これが、パーシスタントレベルになります。
※各ロケーションに色々なサブレベルを紐づけていく
※ロケーション＝パーシスタントレベルなので
ワールドというレベル(.umap)は存在しません

本プロジェクトにおけるレベル実装人員の構成と役割
ワークフローの前に…
どんなチーム構成だった？
Q

レベル企画
ディレクター
リード(兼BP管理者)
マップ企画
ギミック実装
BP管理者
レベルプログラム
リアルタイム演出背景班
ディレクター
リード
プレイヤー
カットシーン
バトル（敵/仲間/AI ）

レベル企画
ディレクター
マップ企画
ギミック実装
BP管理者
ディレクター
リード
プレイヤー
カットシーン
各パートの人数は比率のイメージ
正確な人数を示すものではありません
ご了承ください。

レベル企画
ディレクター
マップ企画
ギミック実装
BP管理者
ディレクター
リード
プレイヤー
カットシーン
各ワールドやロケーションの企画/遊び/ギミックを検討
１ワールドにつき１～２名で担当（複数ワールド担当もある）
専任ではなく他のパート（敵や仲間NPCなど）兼任の者もいる
各ロケーションのサブレベル追加やレベルストリーミング対応
そのワールドのレベルに関わる事をすべてやる
リードはマクロやBPを管理し各ワールドの実装をサポート
レベル企画班の役割や動き

レベル企画と関わりの深かったセクション
レベル企画
ディレクター
リアルタイム演出
プレイヤー
カットシーン
マップ企画
ギミック実装
BP管理者
背景班
ディレクター
リード

マップ企画班の役割や動き
レベル企画
ディレクター
プレイヤー
カットシーン
マップ企画
ギミック実装
BP管理者
背景班
ディレクター
リード
コリジョンやナビメッシュのルールを意識して
レベル企画の作成したモックの精度を上げる
企画されたギミック類のまとめや各種発注
世界観に合わせたヴィジュアル的な仕様の相談/作成
上記をうけてギミック実装担当がBPベースで作成
プログラマーへの相談なども行う

背景班 ( E N V 班 ) の役割や動き
レベル企画
ディレクター
プレイヤー
カットシーン
マップ企画
ギミック実装
BP管理者
背景班
ディレクター
リード
アート、ライティング
それぞれにディレクター
ロケーション毎にリードを設置
レベル企画と密にやり取り
TAの多くは背景班所属
仮アセット～本アセット作成
背景に関わる全てを担う
企画のレベルモックをベースに
より良い背景分割を検討

レベルプログラム班の役割や動き
レベル企画
ディレクター
プレイヤー
カットシーン
マップ企画
ギミック実装
BP管理者
背景班
ディレクター
リード
レベル企画が対処できない部分への
アドバイス及びレベルBPの作成
マクロやノードの使い方のチェック
各ワールド固有システムの作成
レベルBPや配置アクターのチェック
新規アクターやギミック、BPノード作成

その他のセクションとの関り
レベル企画
ディレクター
マップ企画
ギミック実装
BP管理者
背景班
ディレクター
リード
プレイヤー
カットシーン
レベルからの発注を受けて各種演出を設計/作成する
シナリオベースでの絵コンテ作成やマチネでの演出実装
移動関連の挙動、コリジョン周りで背景班との関りが多い
敵配置の設計、レベル企画から特殊なAIの実装依頼など

１ワールドを作成する際の各パート作業の流れ
これらのパートが
どのような流れで動いていたのか？
Q

先程話した小規模タイトル終了後に
密に関わるセクション
（レベル企画、マップ企画、背景）
でワークフローを策定しました

レベル企画
マップ企画マップ仮実装
レベル仮実装
背景
フェーズ０
マップ
発注/作成/管理
レベル本実装
背景
フェーズ１
マップ
調整
レベル
調整
背景
ポリッシュ
マップ
本実装
背景
フェーズ２
実
機
で
流
れ
の
確
認
可
能
企画仮実装本実装調整

企画フェーズ
レベル企画
レベル仮実装
背景
フェーズ０
マップ
レベル本実装
背景
フェーズ１
マップ
調整
レベル
調整
背景
ポリッシュ
マップ
本実装
背景
フェーズ２
実
機
で
流
れ
の
確
認
可
能

企画フェーズ
企画ワールドのコンセプト、遊びの内容企画
各種必要要素（RT演出、ボイスなど）の洗い出しや発注
シナリオ、CS班向け資料作成（ウォークスルー動画＆カットシーン資料）
ワールド内で出現する敵の選定
レベル企画
マップ企画

ワールドのコンセプト、遊びの内容企画
各種必要要素（RT演出、ボイスなど）の洗い出しや発注
シナリオ、CS班向け資料作成（ウォークスルー動画＆カットシーン資料）
ワールド内で出現する敵の選定
企画フェーズ
企画
モックアップ作成（コリジョン込み）
ギミック洗い出し
各種配置想定（探索要素、セーブポイント）
エリア分割やストリーミングの見通し
マップ概要書の作成
レベル企画
マップ企画

仮実装フェーズ
レベル企画
レベル仮実装
背景
フェーズ０
マップ
レベル本実装
背景
フェーズ１
マップ
調整
レベル
調整
背景
ポリッシュ
マップ
本実装
背景
フェーズ２
実
機
で
流
れ
の
確
認
可
能

パーシスタントレベル作成＆必要サブレベルのぶら下げ
ゲームフロー仮実装、敵の仮配置、ミッションの仮実装・検証
マップ仮実装
レベル仮実装
背景
フェーズ０
仮実装

ギミックID発行、ギミック仮実装
ナビメッシュ、ナビリンク仮設定
マップ仮実装
レベル仮実装
背景
フェーズ０
仮実装

背景モックを作成・分解、サブレベル分け→UE4登録
コスト見積もり＆外注資料作成
仮ライティング、仮コリジョン設定
マップ仮実装
レベル仮実装
背景
フェーズ０
仮実装

背景モックを作成・分解、サブレベル分け→UE4登録
コスト見積もり＆外注資料作成
仮ライティング、仮コリジョン設定
ここまでで可能な限り
イテレーションを回す
マップ仮実装
レベル仮実装
背景
フェーズ0
仮実装

本実装フェーズ
レベル企画
レベル仮実装
背景
フェーズ０
マップ
レベル本実装
背景
フェーズ１
マップ
調整
レベル
調整
背景
ポリッシュ
マップ
本実装
背景
フェーズ２
実
機
で
流
れ
の
確
認
可
能

ゲームフロー最適化、サブレベルの表示/非表示対応、
探索要素配置/データ設定、ギミック組み込み、敵配置調整
カットシーン、RT演出組み込み/前後対応、ボイス＆サウンド組み込み
ミッション/ミニゲーム組み込み、テキストと実装
ワールドの本実装
マップ
発注/作成/管理→本実装
レベル本実装
※データ変更は随時対応
背景
フェーズ１→フェーズ２
本実装

レベル本実装
背景
本実装
ナビメッシュ、ナビリンク設定
ギミック本実装、マップの発注表示設定
マップ

ナビメッシュ、ナビリンク設定
ギミック本実装、マップの発注表示設定
レベル本実装
本実装
マップ
フェーズ１（全体6割）：アセット制作、レイアウト、ライティング、
コリジョン整理、サブレベル整理、背景エフェクト
フェーズ２（全体８割）：制作、コリジョン確定、フィジカルマテリアル対応
背景

調整フェーズ
レベル企画
レベル仮実装
背景
フェーズ０
マップ
レベル本実装
背景
フェーズ１
マップ
調整
レベル
調整
背景
ポリッシュ
マップ
本実装
背景
フェーズ２
実
機
で
流
れ
の
確
認
可
能

不具合修正、データ調整、クオリティアップ等々不具合修正、データ調整、クオリティアップ等々
調整フェーズ
調整
不具合修正、データ調整、クオリティアップ等々
マップ
調整
レベル
調整
背景
ポリッシュ

実際やってみて
最初に意思統一をしたおかげで、
足並みを揃えて進むことが出来た

レベル企画って？
レベル企画って何する人？
Q

最初の企画に始まり
出来たデータの組み込みまで行う
最上流から最下流関わり続ける
（一番色んな人と関わる）

プロジェクトが大きくなるほど
作業は細分化され、関わる人が増える
結果、全貌を把握するのが困難になる
あれってどうなってんの？
これは誰に聞けば良いの？

本プロジェクトでは
困ったり、分からないことがあったら
レベル企画に聞いてください！！
と公言してました。

レベル企画は
企画もしますし、実装もします。

しかし、本プロジェクトで
レベル企画チームが目指したのは

各セクションのハブとなり
ゲームを完成に導く人
背景
RTEV
サウンド
CS
PC
VFX
エネミー
NPC
マップ
レベル
企画

現在の進行
• レベル実装のワークフロー Done
• まとめ

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

レベル全体の構成説明
最初に全体の構成を説明します

World Map(.umap)
ワールドマップなるものがあります。
ここにも色々サブレベルがぶら下がっていますが割愛

World Map(.umap)
World 1
World 2
ワールドに実体(.umap)はありません
管理用のフォルダだと思ってください

World Map(.umap)
World 1 Location 山 (.umap)
World 1 Location 城 (.umap)
World 1 Location 街 (.umap)
World 2 Location 海 (.umap)

World Map(.umap)
ワールドマップと各ロケーションに
直接的な依存関係はありません
※ロケーションそれぞれがパーシスタントレベル

World Map(.umap)
Env Sub Level
Cutscene Sub Level
Gameflow Sub Level
Gimmick Sub Level
Enemy Sub Level
VFX Sub Level
Sound Sub Level
※各ロケーションそれぞれにサブレベルがぶら下がってる

サブレベルの切り分け
次はサブレベルの切り分けについて

サブレベルを切り分ける主な目的は…
• レベルストリーミングに対応するため
• 他の担当者との作業分担のため

レベルストリーミングに対応するため
サブレベルは全て表示すると負荷的に耐えられないので
表示や地形的にキリが良い単位で細かめに切り分ける
※これをエリアと呼称してました
World Map
World
Location
Area A
Area B
Area C
※また増えてゴメンナサイ

Area_A：Env Sub Level
Gameflow Sub Level
Area_B：Env Sub Level
Area_C：Env Sub Level

Gameflow Sub Level
いらない

Gameflow Sub Level
表示！

Gameflow Sub Level
World 1 Location 山 (.umap) これは？？

Gameflow Sub Level
どのエリアにいても有効にしておきたいサブレベル

他の担当者との作業分担のため
サブレベルが１つのままだと…

• なぁ、敵の配置調整したいねんけど…
• 岩動かしたから影焼き直すわ１時間待ってｗ
• そもそも、エリアA広いから背景担当２人なんやで？
• え！？あいつチェックアウトしたまま帰ったんちゃう？

• なぁ、敵の配置調整したいねんけど…
• 岩動かしたから影焼き直すわ１時間待ってｗ
• そもそも、エリアA広いから背景担当２人なんやで？
• え！？あいつチェックアウトしたまま帰ったんちゃう？
仲良く作業したい……

できる限り各エリア単位でサブレベルを準備する
※実際に使用されたデータ名称ではありません。

Q
エリアの切り分けは誰が決めた？

背景班がやってくれました！

レベル企画：ざーっくりしたレベル構成
遊びや体験重視

マップ企画：段差やコリジョン、広さを最低限整えてモック作成
ルール重視
※ここで言うルールというのは
プレイヤーの移動に関する挙動や
ナビメッシュの生成に関わるコリジョンに関する事など

背景班：アセットの構成や担当わけを検討しつつエリア分割（Phase 0）
作業効率重視

背景班：アセットの構成や担当わけを検討しつつエリア分割（Phase 0）
レベル企画：背景班が決めた分割でレベルストリーミングの設定をする
以降イテレーション

画像＋エクセルで背景班から情報をもらってレベル企画が作業

サブレベルの管理
最後にサブレベルの管理ついて

パーシスタントレベルの管理は
レベル企画が命をかけてやる

各サブレベルは管理する班を厳密に決める
リアルタイム演出班の管理：Camera
カットシーン班の管理：Cutscene
レベル企画 & エネミー班の管理：Enemy
背景班の管理：ENV
レベル企画班の管理：Level
マップ企画班の管理：Map
エフェクト班の管理：VFX
サウンド班の管理：Sound
※レベルタブのフォルダ機能を活用

サブレベルはできる限り機能や役割ごとに切り分ける
レベル企画：Level
・ゲームフロー
・ギミックなど役割の分割
背景：ENV
・エリアA / エリアB などエリアの分割
・コリジョンなど役割の分割

サブレベルは“管理者”と”役割”を
明確にして管理するのが良い

サブレベルの切り分けは計画的に！
分割によって管理コストは上がるので
サブレベル切り分けは計画的に！

現在の進行
• レベル構成とサブレベルの切り分け Done
• まとめ

レベルBP記述/実装事例

この項でお話する内容
・レベルBPを記述するにあたり多用した機能
・レベルBPを記述するにあたり気を付けた事
・１ロケーション分のレベルBP全体像
・レベルBPの記述に関するルール
・マクロの活用と実装
・レベル企画のドキュメントなどのお話

レベル B P を記述するにあたり多用した機能
・リモートイベントとカスタムイベント
・ブループリントマクロライブラリ

Event Name に任意の文字列を入れておき
レベルBP上でこのノードを通ると…
別の場所（別のサブレベルでもOK 複数あってもOK）の
カスタムイベントが動き始める。
リモートイベントとカスタムイベント

リモートイベントとカスタムイベント
本プロジェクトでは
リモートイベントを少し拡張しています。
UE4標準のリモートイベントは
Actor の中では使えないのですが…
ギミックなどでリモートイベントを使いたい！
といった場面があり
Actorの中で使えるようにしてもらった。
＋演出用にActorの情報を付加できものも準備。

マクロまたは内蔵グラフのコレクションを保持するコンテナで
別のブループリントにノードとして配置することができます。
実行とデータ移行のための入出力の両方が付いていて
よく使うノードのシーケンスを格納できるため、時間を短縮できます。
※Unreal Engine ドキュメントより引用
ブループリントマクロライブラリ

なんか毎回同じ処理してるなぁ… まとめてスッキリ！他の場所でも使いまわせる！
マクロを編集すると全てに反映される！
ブループリントマクロライブラリ

現在の進行
・レベルBPを記述するにあたり多用した機能 Done
・レベルBPを記述するにあたり気を付けた事

レベル B P を記述するにあたり気を付けた事
・BPのTickはなるべく使わない
・インプットイベントはエディター限定に
・不要なサブレベルはできるだけ非表示 or アンロード

BPのTickはなるべく使わない
・処理負荷が上がるのでなるべく使いたくない
・複雑な流れになりやすく、不慣れな人が扱うとバグを多く生む
・仮実装の際はそれなりに使っていたが
本実装の際にプログラマーへの相談、監視でなるべく無くすよう努力
・『なるべく使わない』なのでプログラマーと相談の上
最終的に使用している箇所もあります。

インプットイベントはエディター限定に
・ちゃんと確認しようとすると数手かかる演出をさっと起動するなどに活用
・正直いってとっても便利！
ただし…製品で動作する可能性がある大変危険な機能
・使用する場合は確認目的の一時的な用途に限る
・プログラマーが『エディター以外では動作しない』様にしてくれた

不要なサブレベルはできるだけ非表示 or アンロード
・プログラマーや背景班の負荷チェックから指摘を受けて作業する事が多い
・描画の負荷や、レベルに置かれているギミック類のTickをごっそり削れる
・演出系のサブレベルは再生前に読み込み、終了したらアンロードが基本
・描画の負荷や、メモリが許すのであれば出しっぱなしの方が良い事もある
・配置物の多いサブレベルは出し消しする時カクツキの原因となる事があるので
場合によっては出し消ししないようにしている箇所もある（負荷と相談）
・通常のレベルストリーミング処理とは別に、レベルBPで制御している場合もある

不要なサブレベルはできるだけ非表示 or アンロード
レベルプログラマーが用意してくれた
各サブレベルの状態を確認したり
個別にアンロードしたりできる機能が便利でした。
※別講演のスライドを見てね

現在の進行
・レベルBPを記述するにあたり気を付けた事 Done

１ロケーション分のレベル B P 全体像
※全体像と言っていますが７割くらいです
細かいものを含めるともう少し増えます

パーシスタントレベル
・レベル企画管理
・ゲーム開始前のレベルストリーミング初期設定
・ナビメッシュ関連の処理
・ライトシナリオの変更（一部のロケーション）
・プレイヤーの開始位置に応じた処理
・そのロケーションでの敵の強さ設定
など

ゲームフローサブレベル
・レベル企画管理
・ゲーム開始直後の処理
・ゲーム進行制御全般
・ゲーム進行用のメッセージ処理
・オートセーブやリトライ処理
・ゲーム展開によるBGMの変更
・パーシスタントレベルからの
Remote Eventで動き始める

ゲームフローサブレベルには…
• Player Start
• イベント起動用のTrigger や Volume
• 移動範囲を制限するためのギミック(透明壁)
といった、ゲーム進行制御に関わるものしか
配置されていません。
※ゲームフローサブレベルのみだとこんな感じ

進行管理用のフラグは…
• エクセルにてレベル企画が作成（ワールド毎に作成）
• メインの進行フラグは int 型の変数で管理
• サブフラグとして bool 型の変数も自由に作れる
• レベルBPでこれらフラグの中身を確認/比較/更新する
※雑ですがこのような感じ…

その他のサブレベル
・基本的に役割毎に
サブレベルが用意されている
・ゲームフローサブレベルからの
Remote Event で動き始めて
Remote Event でゲームフローに戻す
・サブレベル単体で
処理が完結するものも多数ある

大小の違いはありますが全ロケーションこんな構成

Remote Event
①

Remote Event
Remote Event
① ②

Remote Event Remote Event
Remote Event
① ②
③

Remote Event
Remote Event
レベル以外のBP
または
プログラムから
Remote Event

Remote Event
Remote Event
または
Remote Event
Remote Event

Remote Event
Remote Event
または
Remote Event
Remote Event
Remote Event
Remote Event

その他のサブレベルの処理や役割
その他のサブレベルについても
簡単にですがご説明します

演出関連サブレベル
・リアルタイム演出制御
・カットシーン再生制御
・１演出につき１サブレベル
・マチネの再生と
カメラ制御ノードなどで構成

エネミー関連サブレベル
・エディター上で敵Pawnを配置
バトル専用のVolumeで管理しており
多くはレベルBPの記述をしていない
・殲滅によるゲーム進行処理など
イベントの起動が必要な場合のみ
レベルBPで処理
・１バトルにつき１サブレベル

ミッション・ミニゲーム関連サブレベル
・普段のバトルと異なる特殊な実装のバトル
※制限時間表示がある
※仲間NPCを護衛しながら戦うなど
・そのサブレベル単体で完結するミニゲーム
・１ミッションにつき１サブレベル

仲間NPC制御サブレベル
・特定のエリアに入ると
仲間NPCが普段と違う行動になる
・特定のエリアに向かって
仲間NPCがプレイヤーを誘導する
・AI班や仲間NPC担当プログラマーが
用意してくれたノードをマクロ化するなどして使用

ゲーム中のボイス制御サブレベル
・特定地点で仲間NPCが何かしゃべりだす
・仲間NPCやその他NPCとの汎用会話
・同レベル内のイベントトリガーや
他のサブレベルからのリモートイベントで動作

分割して管理したサブレベルの一覧
• ゲームフロー：レベル企画管理、ゲームの進行全般を制御
• ギミック：レベル企画管理、色々な種類の仕掛けを配置して動作を制御している
• 敵（エネミー）：レベル企画とバトルチームの管理、敵の配置やバトル展開の制御している
• ミッション：レベル企画管理、特殊なルールの遊びやバトルを制御している
• ミニゲーム：レベル企画管理、ミッションと同じように特殊なルールの遊びを制御
• リアルタイム演出：リアルタイム演出班管理、様々なカメラ演出などが再生されるサブレベルレベル
• カットシーン：カットシーン班管理、その名の通りカットシーンの再生を制御
• 宝箱（トレジャー）：マップ企画管理、宝箱のみを配置調整するためのサブレベル
• 仲間NPC制御：レベル企画とNPC班管理、仲間NPCのAIや会話などを制御するためのサブレベル
• その他NPC制御：レベル企画とNPC班管理、NPCの配置やAIに関わる制御を行うためのサブレベル
• ナビリンク：マップ企画とAI班管理、ナビリンクは自動生成、一部手動で置く必要があり用意した
• ボイス再生や会話：レベル企画管理、ちょっとした会話やゲーム中のヒントボイスなどの再生を制御
• ストリーミング制御：レベル企画管理、レベルストリーミング制御全般を行うボリュームの配置
• 背景：背景班管理、地形に関するすべての配置を行う、かなり細かく分割されている
• 背景ライティング：背景班管理、背景のライトの配置や環境を制御するために用意されたサブレベル
• 背景エフェクト：エフェクト班管理、背景に関わるエフェクト全般が配置されるサブレベル
• サウンド（環境音）：サウンド班管理、環境音のみが配置されている（BGMの制御はゲームフロー）

サブレベルの役割毎に B P を記述する利点
レベルBPの記述をサブレベル毎に分割する事で
• 実装時の細かい役割分担が可能でヘルプも入れやすい
※例）敵の配置や処理だけ○○さんに～！
• 不具合発生時に見るべき箇所がわかりやすくなる
※例）あれ、NPCの挙動が変？ → NPC制御のサブレベルを確認

サブレベルの役割毎に B P を記述する時に意識した事
各サブレベルでの記述内容を明確にし
Remote Event で簡潔にやり取りする

現在の進行
・１ロケーション分のレベルBP全体像 Done

レベル B P の記述に関するルール
・リモートイベントの命名規則
・ゲームフローの記述に関するルール

リモートイベントの命名規則
レベル ⇒ レベルへの通知
ex_01_gameflow_REvt_Boss_Retry_Start
前半：通知を投げたサブレベルの名前例では ex_01_gameflow
真ん中：リモートイベントだよ！という目印
後半：通知を投げた目的例ではボス戦のリトライ演出の開始

プログラム（敵Pawn）⇒ レベルへの通知
program_e_001_REvt_SpecialAttack_Finish
前半：プログラムからの通知であるという目印と
エネミーのID 例では e_001 という敵である事がわかる
真ん中：リモートイベントだよ！という目印
後半：通知を投げた目的例では必殺技が終わったタイミング

ex_01_gameflow_REvt_Boss_Retry_Start
program_e_001_REvt_SpecialAttack_Finish
・リモートイベントは不特定多数のレベルへの通知が可能なため
通知を受けた側が『どこからの通知なのか？』がちゃんとわかる事を重視
・レベル実装に使用するリモートイベントはレベル企画が命名/管理する事が前提
・後半部分は名称被りを防ぐため、多少の工夫は必要
・リアルタイム演出やカットシーン用のものは作業用にエクセルでの表管理もした

・リモートイベントは不特定多数のレベルへの通知が可能なため
通知を受けた側が『どこからの通知なのか？』がちゃんとわかる事を重視
・レベル実装に使用するリモートイベントはレベル企画が命名/管理する事が前提
・後半部分は名称被りを防ぐため、多少の工夫は必要
・リアルタイム演出やカットシーン用のものは作業用にエクセルでの表管理もした
※受け側で混乱しないように

ゲームフローの記述に関するルール

ゲームの開始処理や
ロケーションを通して共通の処理は上部にまとめる

ゲームフローの進行は上から下に

ロケーションで時系列がとぶ場合は右にずらす

後半の進行も上から下に

レベルBP上部にゲームの開始処理
プレイヤー誘導用のインフォメーション更新
ロケーションの前半の進行が左側
後半の進行が右側にあり、それぞれ上から下に並んでいる
コメントで青色のところ、セーブ or リトライ設定
黄色と赤色の仮処理は無くなっている

B P の記述ルールは …
メンテナンスのみならず
引継ぎや担当者変更などでも重要

現在の進行
・レベルBPの記述に関するルール Done

マクロの活用と実装
• 使用頻度の高いノードの個別ラッピング
• よく使う処理をまとめて定型化する
• マクロの作成者/管理者は少数に絞る

使用頻度の高いノードの個別ラッピング
ノードそのものを直接使うのではなく
マクロにしてしまい、そちらを使う様にしている場面が多かった。

個別にラッピングしておくことで
使用するノードが変わっちゃったー！？使えなくなったー！？
など、問題が起こった場合も
マクロの編集のみで、全てのレベルBPに反映される。
※変更後、各ロケーションでの動作確認は必須ですが…
マクロの中身を変えるだけ

どのノードをラッピングしておくか？
これについて、開発の初期段階での判断は難しい…
プログラマーさんに相談してとりあえずやっておく、くらいで良いのかもしれません。
※結局最後までこのまま…みたいなものもありました。

今回のプロジェクトで効果は薄かったんですが…
同じノードなんだけど、使用目的が違う。
といった場合、別々のマクロとしてラッピングするといった事もしました。

・カットシーンに対してリモートイベントを送るマクロ
・リアルタイム演出に対してリモートイベントを送るマクロ中身は同じ。
それぞれ独自の拡張が入るかも…と思ったが、特に何もなかったです。

よく使う処理をまとめて定型化する
パーシスタントレベル起動直後に必ず通すべき処理
カットシーンの開始前にやっておく処理
ボス戦開始前にやらなければいけない設定… などなど。
各ロケーションで実装方法が異なるといった事態は避けなければいけない。
※マクロの中はちょっと複雑になりがちですが

レベル実装を行う担当者の理解度や技術力に関係なく同じ挙動とする事ができる。
また、マクロの中身の管理はレベル企画リードやプログラマーが行うため
レベル実装時の負担も軽減できていた様に思います。
ノードの並べ方とかに個性はでるけど
処理順はみんな統一出来ている
Aさん
Bさん
Cさん

ノードのラッピングと同じく…
どういった部分を、どこまで定型化するか？
開発初期段階での判断は難しい、試作や仮実装を通して
定型化する場所を徐々に増やしていきました。

マクロの作成者/管理者は少数に絞る
レベルブループリントのマクロライブラリーは非常に便利ではあるのですが…
不特定多数の人間が好き勝手にマクロを作成すると混乱の原因となります。
『レベルBPの記述ルール』の項でも書いた通り
使い方などのルールはちゃんと管理されるべきですので
マクロの作成者/管理者は、レベル企画のリードと一部プログラマーのみ
に絞りました。

マクロの活用の罠
• デバッグの難度上がる
• 変更によるコンパイルエラー
• 変更による影響範囲が広すぎる

デバッグの難度が上がる
ブループリントの処理や流れをデバッグする時
処理がマクロの中に入っていく事で、処理の順番を追いかけたり
問題のある個所を見つける事が難しくなってしまい
プログラマーさんのサポートコストが上がってしまいました。
??

デバッグの難度が上がる
・なんか動きはおかしいんだけど…
マクロが悪いの？レベルBPの組み方が悪いの？
・マクロの中にブレークポイントを置くと
色んな所でブレークしちゃって、面倒くさい… など
企画が扱うには、ちょっと難易度が高いかもと感じる事も

変更によるコンパイルエラー
マクロにしておくと定型化されて楽ちん！とは言いましたが…
マクロの入力や出力が変更されると、
そのマクロを使用している場所全てでコンパイルエラーが出る可能性があります。
入力増えた！入力削除した！

変更によるコンパイルエラー
特に入力や出力ピンの削除はかなり危険！！
マクロの変更に関しては、レベル企画全体のミーティングにて相談/報告を密にし
変更後のエラー対処、動作確認は厳しめにお願いしていました。

変更による影響範囲が広すぎる
これは開発終盤で特に苦労しました…
バグの原因がマクロにある場合、マクロを修正する事によって
問題のなかった場所にも影響が出る事になります。
修正はこれだけなんだけど……
!!
!!
!!

また、バグではないが新たな要望でマクロの中身が変更された場合。
全ワールド、全ロケーションにて問題が無いかの再確認が必要になります。
開発終盤での要望対応の際はQAチームも巻き込み、影響範囲や対応の危険度など
慎重に判断する必要がありました。
レベル企画：
影のクオリティを
マクロで変更しました！
QAチーム：
全カットシーン
再チェック！

出来るだけ影響範囲を抑える変更で対応
・入力が増えるけどデフォルトの値は現状から変わらないようにしておき
変更を反映したい一部分でのみ値を修正する
・バグの対処を行う際、該当箇所のマクロのみ展開して独自の修正を行う
※これは本当に最終手段

現在の進行
・レベルBPの記述に関するルール Done
・マクロの活用と実装 Done

レベル企画のドキュメントなどのお話
レベル企画のWebページ
・基本的にここを見れば大抵の事が解る
・仮実装のモック作成から
本実装の各種配置、マクロ使用方法など
・進行フラグやリモートイベントの
命名規則などについても記載

各種ページはこのような感じ
基本的なバトルの実装/配置方法や、レベルBPでのミッション実装方法など

新規人員がアサインされたら…
• 無改造のUE4で簡単なBPを使ったチュートリアルを行い
UE4の基本操作やレベルの挙動などを学ぶ
• ドキュメントページを見ながら
仮実装の工程をデベロップ階層でやってもらう（２～４週間程度）

・ドキュメントは担当者₍基本的に企画₎が随時情報の更新を行う
・記載量が膨大なため読むのは一苦労だが頑張ってもらう
・繁忙期には更新が追いつかず、古い情報がちらほら……（反省）

現在の進行
• レベルブループリント記述/実装事例 Done
• まとめ

レベルBP活用下でのバグ分布

バグ対処の割合

企画のバグのうち
約６割（全体の15％程度）がレベル担当のもの

その他の部分なんですが、集計データが最終的なものでなく…
対処中のバグやQAさん預かりとなっているチェック項目です。
また、一部作業タスクがチケット管理されているものがあり
単純な不具合でないものもここに含まれています。
ご了承ください。

ブループリント使ってるから？？
BPを活用した結果こうなった？
と、いうにはデータが少なすぎます。
弊社のUE4を使用した他のプロジェクトでも
企画担当のバグは全体の２割～３割程度になるそうです。
これについてもプロジェクトの規模や内容によって変わってくるかと思いますので…
『今回はこんな感じだったんだなぁ』
程度でとどめておいて頂くようお願いします。

レベル企画関連のバグについて
全体の約15％にのぼる…
・レベルBPによる進行不具合
・マクロの挙動不具合
・ミッション・ミニゲーム挙動
・レベルストリーミングの挙動
・宝箱やギミックなどの配置
・演出との接続不具合
・敵が資料通り出現していない
・ボイス再生のタイミング
・BGMの切り替え不具合
など

プログラマー関連のバグについて
全体の約20％
このうちレベルプログラマーは…
・レベル全体の負荷対処
・プログラマー作成のノードの挙動
・ミッション・ミニゲームの挙動
・レベル企画関連バグへのサポート
など

背景関連のバグについて
全体の約30％
・コリジョン関連の対応
プレイヤーやAIのはまり
・テクスチャーストリーム関連
・レベルストリーミング関連の調整
・背景アセット起因の表示不具合
・背景全体の処理負荷対応
・大技対応
など

今回の全体的な印象として …
BPの管理が甘いとバグは増加
処理負荷のボトルネックになる場合も
けっこう色々できる！からついやっちゃう……
可読性の低いカオスな実装……ダメ、絶対。

現在の進行
• レベルブループリント活用下でのバグ分布 Done
• まとめ

まとめ
ブループリントを上手く付き合っていくには？（企画視点）
ブループリント良い悪いみたいなお話になりがちですが…
プロジェクト毎にチームで相談し、活用してく範囲を決めていけば良いのだと思います。
全てをBPでやるではなく
”活用”していくという意識が大事

まとめ
ブループリントを上手く付き合っていくには？（企画視点）
全てをBPでやるではなく
”活用”していくという意識が大事
ブループリントでルールなしに実装を進めた結果、プログラマーの負担が上がり
結局C++でやった方が良かったやん……とならないためにも
密な相談、ブループリントを使っていく上でのルールの作成と実装フローは最重要です。

まとめ
ブループリント活用でのレベル実装
作業者の実力平均化と実装の共通化
ブループリントマクロライブラリを活用した実装内容の定型化については
今回のプロジェクトでかなり効果があったと思います。
また、プロジェクトの初期にレベル実装フローと処理内容の共通化を進めたことで
プロジェクト中盤以降、誰が実装しても精度の高いものになっていたと思います。

まとめ
ブループリント活用でのレベル実装
管理者と役割を明確にした
レベルの切り分けと実装
レベルブループリントを記述するにあたっては
どのサブレベルで何が処理されているのか？どの部分を企画が責任を握って進めていくのか？
を明確にしていたのも大きかったと思います。

現在の進行
• レベルブループリント活用下でのバグ分布 Done
• まとめ Done

ご清聴ありがとうございました！
Unreal Engine 4 は Epic Games 社の商標または登録商標です。

UE4における大規模レベル実装ワークフローとブループリント活用事例

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to UE4における大規模レベル実装ワークフローとブループリント活用事例

Similar to UE4における大規模レベル実装ワークフローとブループリント活用事例 (20)

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

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

UE4における大規模レベル実装ワークフローとブループリント活用事例