[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であったと言及されていました。