[Unreal Summit 2019] FortniteでUnrealGameSyncを作った経緯とイテレーション改善について

Fortniteの開発チームにエディタを配布する過程は慎重過ぎるあまりイテレーションが遅かったそうです。これを改善すべくUnrealGameSyncという新ツールが開発され、イテレーションを短縮した過程が解説されています。

 


（スライド原題：Workflow on Fortnite、セッション原題：포트나이트 워크플로）

動画とpdfはこちら

三行要約

• イテレーションのためUnrealGameSync(UGS)を開発した
• ソースのコミットから10分で自動テストまで完了
• 実行バイナリをPerforceにサブミットせず、ローカルのVisual Studioでエディタをビルド（プログラマ以外の職種も！）

本ポストでは、アジェンダのうち、Distributing the Editorについて解説します。ほぼUGSの話です。

長年使われてきた従来型のビルドパイプラインはイテレーションが遅く、使えるビルド(good build)が一日に１回か２回しか得られませんでした。遅さゆえゲームプログラマーとコンテントクリエーターの連携が困難です。

CIでビルドされたバイナリはPerforce等にサブミットされ、QAセクションでテストされた結果大きな問題がない場合、ラベル付けされて開発で使えるようになっていたようです。開発が進むにつれテストの量も増えていきます。

バイナリ（exeやdll等の実行ファイル）とコンテンツのバージョンが一致していないとデータを壊す危険をはらみます。

エンジニアがローカルでビルドしたエディタはバージョン付けがされてないため、エンジニアがコンテンツを編集するためにはPerforce上のバイナリを取得して編集しなければいけませんでした。

一方、Battle Breakerチームでは当時のFortniteのような従来型のビルドパイプラインを好みませんでした。Perforce上にバイナリはなく、企画職やアーティストを含む全職種（計8人）が、Visual Studioからソースコードをビルドしてエディタを起動していました。

問題があれば隣のエンジニアに聞いて解決します。コミュニケーションが密になりました。

この体制の柔軟さに気づき、Fortniteに適用できないか考えました。

Fortniteへ適用する現実の壁がありました。

安全に導入せねばならず、コンパイル時間も問題です。

チームが大きいので通常エンジニアとアーティストは別室であり対話が難しいです。

これらを解決するツールが必要と考えました。

初期のUnrealGameSync(UGS)です。

CL(Change List)をダブルクリックするとビルドが始まります。ビルド結果はDBに格納され、GUIからは青信号又は赤信号で結果が見れます。

また、CLを右クリックしてコメントを残せます。（コメントの例：「このビルドはおかしい」「調査中です」）

現在のUGSです。

複数の(Perforceの)ストリームが見えます。

Automation Testの結果がみえます。

UGSクライアントにメッセージを送信する機構を用意しました。ビルドやテストが失敗するとUGSを経由してデスクトップにポップアップで通知できます。

ビルドからテストまで１０分で完了するそうです。

メインのCI（セッション内ではCISと表現）は１台のマシンです。

Incremental editor buildとし、unity buildは切っていたそうです。

サブミットされたアセットの無効な参照のチェックを行います。

ログインとゲームプレイループまでを自動テストしています。

２台目のマシンは他のプラットフォーム向けのビルドを行っていました。

ParagonチームはFortniteチームと違い全員がローカルでビルドしませんが、UGSがCLに対応するビルド済みZIPを取得して実行していたそうです。

Sync Filter

作業に不要なプラットフォームを除外してSyncできます。コンソール担当ではないスタッフはPS4やXBOXを除外します。自宅からリモートで作業するスタッフはムービーファイルを除外するでしょう。

Clean Workspace

Intermediateを削除し、ワークスペースをディポから取得したばかりの初期状態と同じにする機能です。

Bisect

複数のCLを選択し、どこで問題が発生しているかバイナリサーチで探す過程を支援するツールです。

カスタマイズ機能

ブランチごとにロゴを設定できます。

赤いのはリリースブランチであり、ロックしているのでここに変更が加わることがないことを表示しています。

朝に自動シンクし、出勤時に既に最新状態が取得できている状態にすることもできます。

任意のリンクを挿入できます。例えば深刻なバグが発見されたらそのリンクを入れられます。

任意のテキストを入れて、重要な情報、例えば次回リリース日などを表示できます。

これらは公開されており、未公開の機能などはなく、全て皆さんが使えます。

どのバージョンのエンジンでも使えます。

まとめ

「従来型のビルドパイプライン」は普通のゲーム開発の現場で行われている事に近いのではないでしょうか。ビルド済みバイナリを待つ場合（自動化されていたとしても）バイナリが得られるまでに数十分のタイムラグが発生することもあります。

ソースコードを含むCLを配布そのものと見なし、タイムラグを０とするのは示唆に富んだ事例と言えそうです。

追加の解説が欲しい点としては、各自のPCでのビルドに時間が掛かったりしないかということです。特にエンジンに手を加えた場合はビルドマシンでも１０分では終わらない気がします。全員の席で出勤前にデイリービルドが行われるので、日中はインクリメンタルビルドで凌ぐのでしょうか。IncrediBuildも全職種のPCで導入されているかもしれません。おそらくはソフトウェアのライセンス費も惜しまず投資をしていると推測されます。

2019/09/01 追記：
Unreal Fest Europe 2019の同名のセッションで、FortniteにUGS導入当時アーティストの席に導入されたのはVisual Studio Expressであったと言及されていました。

[GDC 2019] UE4の新物理エンジンChaosの紹介と内製の理由

GDC 2019のセッションで、UE4.23からEarly Access扱いで登場する新物理エンジンChaosについて、内製が必要になった背景と用途について解説されています。

（原題：Order from Chaos - Destruction in UE4）




特に重要そうなポイントを要約します

• UE4.23でプレビュー版が搭載される
• 最終的にはNVIDIA PhysXを置き換える
• 破壊の表現に強い
• Niagaraインテグレーション
• 破壊結果でAIのナビゲーションメッシュを書き換える
• モバイルプラットフォームをサポート
• ネットワーク対応
• 物理シミュレーション結果を事前キャッシュすることで負荷を軽量化する機能あり

まず、最終的にはNVIDIA PhysXを置き換える、UE4.23でプレビュー版が搭載される、破壊の表現に強い、などの特徴が挙げられましたが、今回のセッションでは特に破壊表現を中心に解説されています。

今までのUE4の破壊表現の実装方法について振り返っています。単純な破壊可能なメッシュはエディタ上でStatic Meshから生成可能でしたが、より複雑な破壊となるとDCCツール上の編集、アプリケーション側の実装などが必須になり、結果として開発イテレーションが遅くなると解説されていました。

新しいシステムはエディタ上ですべての作業が完結します。
破壊は、あらゆるスケールで可能で、人スケール、ビルのスケール、街の区画スケールを例として挙げられていました。
Niagaraとは密な統合が行われています。
コリジョンの形状は凸状に制限されることはなくなりました。

今までの破壊はゲームに与える影響が限定的でした。例えば道に大きな破片が落ちていた場合AIは単純にぶつかって進めなくなるなど、これをどうするか決めることができませんでした。Chaosはナビゲーションメッシュを変化させます。AIは道に落ちた破片を避けるか乗り越えるか選択することになります。また、壁に空いた穴を通り抜けられる事を認識します。

NVIDIA PhysXはモバイルプラットフォームをサポートしませんでしたが、Chaosはあらゆるプラットフォームで動作します。

アスタリスクがついている「Persistence」と「Network replication」は今は実装できていませんが将来にサポートが予定されているものです。

いくつかの新しい概念が登場します。

Geometry Collectionsは新しいアセットタイプです。Static Meshを束ねて破壊可能な一つの構造を定義します。
１つのGeometry Collectionは１回のドローコールで描画が完了するそうです。

Geometry Collectionの作り方の実演です。

Fracturingとは割れ方を定義するものです。

Clusteringは、１つのGeometry Collectionの壊れ方を階層構造にします。
実演では、Level 1は10個、Level 2は30個まで増え、Level 6は681個までに分けていました。

FieldsとはUE4の「Volume」であり、特定範囲内での物理挙動のパラメータを定義するものと思われます。
実演ではいくつかの定義済みのフィールドがアセットとして用意されていました。

挙動から推測するに「Anchor」フィールドが物理オブジェクトがその場に「留まる」場所を定義し、「Strain」フィールドは銃弾を撃つと発生した破片が外向きの衝撃を受けて飛び散る様を定義、
「Disable」フィールドは、落ちた破片同士が重なってガタガタするのを抑えるために破片をすぐに停止状態にする場所を定義していました。

また、それら機能にBlueprintからアクセス可能であることに言及されていました。

 
Connection Graphはチャンクの結びつきを定義します。黄色は固定されているチャンクで、青はコネクションが破壊されると落下を始めるという意味のようです。

Cached Simulationsは、非常に大きな物を破壊するときに有用になると思われます。
破壊を事前計算しておくため高速ですが、インタラクト可能で、Cached Simulationの一部に触れた瞬間その部分がキャッシュではない物理挙動を開始するそうです。

 
Chaosが発生させるイベントはNiagaraからアクセス可能です。Niagaraからは破片の物理及びマテリアルのプロパティを参照可能です。



建物の破壊をエディタ上の編集で作れるようになるのはうれしいですね。
PhysXが無くなるということは既存の物理挙動が変わってしまう可能性があり、エンジンのバージョンを変えるときは気をつけるポイントになりそうです。
ただし、UE4.23でpreviewなのでしばらくはPhysXと共存することになるのかなと思います。