プロジェクトは、チームの規模が大きくなるにつれてコードやアセットの数が増えていくため、スケーリングの課題に直面することがあります。 可能な限りプロジェクトがスムーズに進行するように、Epic Games では UE で使用できるさまざまなツールを提供しているため、次のような場面で役立ちます。
エンジンとプロジェクトをチームに配布する。
コンパイル時間とパッケージ化の時間を削減する。
プロジェクトが使用するハード ドライブ容量を削減する。
バージョン管理から更新されたコードやアセットをプルするための同期時間を短縮する。
自動ビルド パイプラインをセットアップする。
自動テスト パイプラインをセットアップする。
これらはすべて、Unreal Engine で作業する際にチーム メンバーが感じる負担を軽減し、ビルド、テスト、機能の変更の際のイテレーション時間を削減することができます。
バージョン管理ソフトウェアを使用してプロジェクトを管理する
バージョン管理は、ゲーム開発プロジェクトに欠かせない要素です。 バージョン管理サーバーは、プロジェクトのコードとファイルの一元管理されたコピーを保存し、バージョン管理クライアントはチーム メンバーがそれらのファイルにアクセスして更新できるようにします。 「リポジトリ」は、バージョン管理サーバーに保存されているファイルをバージョンごとに分類したファイルのグループのことです。「ワークスペース」は、クライアントが特定のリポジトリのコピーを保存するクライアント側のディレクトリのことです。
バージョン管理の統合により、次のことが可能になります。
プロジェクトのコピーをローカル マシンにプルします。
コードとアセットをレビューしてコミットします。
ワークストリームを分離して競合を防ぎます。
複数のチーム メンバーが同じファイルで作業しないように、ファイルをチェックアウト、ロック、リリースします。
ファイル (差分) を比較し、統合します。
また、バージョン管理ではリポジトリに対して行われた変更の履歴が保持されるため、変更によって問題が生じた場合は、簡単に以前のバージョンのアセットやコードにロールバックすることができます。
UE では、次のバージョン管理の統合をサポートしています。
Perforce
Git with GitLFS
Subversion
Diversion
プロジェクトでこれらのいずれかをセット アップする場合は、アセットやコードの作業を開始する前に行う必要があります。 これらはすべて利用可能ですが、Epic Games では主に Perforce を使用しているため、このガイドに記載されている多くの機能は、UE の Perforce との統合を中心に説明しています。 プロジェクトにリポジトリを作成したら、それをコンテンツ ブラウザと統合し、Unreal Editor 内から直接ファイルをチェックアウトおよび管理できるようになります。
UE でバージョン管理を使用する方法の詳細については、「[ソース コントロール](understanding-the-basics\source-control)」ページや「[共同作業とバージョン管理](setting-up-your-production-pipeline\collaboration-in-unreal-engine)」セクションを参照してください。
Unreal Game Sync を使用してプロジェクトを配布する
Unreal Game Sync (UGS) は、Perforce、Unreal Build Tool、および IDE (該当する場合) と連携して、チーム メンバーがプロジェクトの作業ビルドを簡単にダウンロードしたり、コンパイルしたりすることができるクライアントです。 UGS を設定すると、ユーザーは .uproject ファイルを選択し、 そのプロジェクトのビルド リストを確認したり、動作が検証済みのビルドを見つけたりすることができます。 IDE がインストールされている場合は、コマンド 1 つでソース ファイルをプルしてビルドすることができます。 インストールされていない場合、事前にビルドされたバイナリを含むビルドを探し、それをダウンロードできます。
詳細については、UGS のドキュメントを参照してください。
チーム向けのオフライン インストーラを作成する
エンジン ソースをフォークしてカスタマイズした場合は、インストール済みのビルドを作成し、Unreal Engine のオフライン インストーラとしてパッケージ化することをお勧めします。 オフライン インストーラの作成方法については、「Installed Build を作成する」や Installed Build のリファレンスを参照してください。
Unreal Engine のモジュールと ICWYU を使用して過度な C++ コンパイルを削減する
プロジェクト内に C++ コードが多いほど、IDE からのコンパイルに時間がかかります。 そのため、通常はプロジェクトが進むにつれて C++ のコンパイル時間が長くなります。 特に大規模なプロジェクトでは、これによってプログラマーのイテレーション時間が妨げられることがあります。
UE のアーキテクチャでは、この問題を軽減するためにコードをモジュールに分割しています。 コードをモジュールに分割すると、作業しているモジュール内のコードのみが再コンパイルされ、他のモジュールは影響を受けません。 その他のモジュールを使用する利点については、「Unreal Engine のモジュール」セクションや「エディタ モジュール」ページを参照してください。
UE のコードベースは「Include What You Use (IWYU)」パラダイムも使用しています。こちらも #include 文と forward 宣言をより効率的に使用することで、ビルド時間を短縮することができます。 詳細については、「Include What You Use」ページを参照してください。
UAT、BuildGraph、Horde を使用して自動ビルドを作成する
Unreal Editor からプロジェクトをパッケージ化することもできますが、Unreal Automation Tool (UAT) の BuildCookRun コマンドは、パッケージ化されたビルドを作成するための基盤となるメカニズムであり、オペレーティング システムの任意のコマンドライン インターフェースからアクセスすることができます。 UAT には、バージョン管理システムへの各送信を自動的にコンパイルするビルド サーバーの設定など、GUI を使用することができないシナリオでビルド プロセスを自動化するのに役立つスクリプトが数多く用意されています。 直接かつシンプルなアプローチとして UAT の BuildCookRun コマンドを使用し、独自の自動ビルド パイプラインをスクリプト化したり、BuildGraph を使用して、より詳細な自動ビルドのシステムを設定したりできます。
Horde は、BuildGraph フレームワークの上に構築された堅牢で継続的な統合スイートです。これには、ビルドの健全性の監視、タスク追跡ソフトウェアとの統合、リモート テスト デバイスの管理、詳細な分析やログの提供など、多彩なツールが備わっています。 さらに、Horde は Unreal Build Accelerator (UBA) もサポートしており、作業を複数のサーバーやワークステーションに分散させることによってコンパイルの速度を向上させることができます。
ビルド パイプラインをカスタマイズする場合は、Automation Tool や Build Tool の完全なリファレンスとして「Unreal ビルド システム」セクションを参照してください。
マルチプロセス クックを使用してクック時間を短縮する
ビルドをパッケージ化すると、UE ではターゲット プラットフォーム用にプロジェクトのアセットをクックし、互換性のある形式に変換して、設定した圧縮設定を適用します。 通常、これは単一のプロセスですが、クック時間を短縮するためにマルチプロセス クックを有効にして、同時に実行するクック プロセスの数を設定できます。 詳細については、「マルチプロセス クック」のガイドを参照してください。
仮想アセットを使用してアセット管理を合理化する
プロジェクト内にあるアセットの数が増え、サイズが大きくなると、チーム メンバーがソース コントロールからプロジェクトを更新するのにかかる速度が大幅に低下し、プロジェクトのローカル コピーが使用するハード ドライブ容量の量も増加する可能性があります。
これに対処するために、Unreal Engine では仮想アセットをサポートしています。 これらは、エディタのコンテンツ ブラウザに表示するために使用するメタデータからアセットのメイン データを分離します。 チーム メンバーがプロジェクトを同期する場合、メタデータのみが同期されます。これは、アセット全体に比べて、ごくわずかな容量しか使用しません。 実際にアセットにアクセスして表示や変更を行う必要がある場合、UE はバルク データをチームのリポジトリや派生データ キャッシュ (DDC) からオンデマンドでプルします。
詳細については、「仮想アセット」のドキュメントを参照してください。
派生データ キャッシュを使用して、エディタのシェーダー コンパイル時間を短縮する
UE のアセットの多くは、派生データを使用します。 たとえば、マテリアルを作成すると、Unreal ではマテリアル全体が表示されるように、シェーダーをコンパイルする必要があります。 バージョン管理システムのファイルには、すべてのプラットフォームに共通し、編集しやすいシェーダーを作成するために必要な手順が含まれています。派生データは、元のデータと同じファイルに保存するとリポジトリが大きくなりすぎるため、また、コンパイルしたシェーダーの形式が、使用するハードウェアやオペレーティング システムによって異なる可能性があるため、独立した概念やメカニズムとして存在します。 プロジェクトやチームが大きくなるにつれて、大きな変更を取得する必要がある場合、特にプロジェクトを最初から再ダウンロードする必要がある場合に、これは厄介なプロセスになる可能性があります。
派生データ キャッシュ(DDC) は、このタイプの派生データ専用のセカンダリ リポジトリとして機能します。 ユーザーがアセットをコンパイルまたはクックすると、派生データが DDC に追加されます。 そして、互換性のあるハードウェアを持つ他のユーザーがアセットを同期すると、UE ではアセットとその派生データの両方をプルすることができます。つまり、最初から再コンパイルする必要がありません。 バージョン管理とは異なり、DDC は通常、それまでに送信されたすべてのファイルのすべてのバージョンを保持するのではなく、最新のデータのみを指定された期限まで保持します。 プロジェクトの非常に古いバージョンのチェックアウトが必要となる稀なケースでは、派生データは常に再生成できます。 スタッフに応じてさまざまな場所にさまざまな共有 DDC をデプロイし、チーム メンバーによるアクセスのルールを定義することで、最も高速で信頼性の高いソースからデータをプルできるようにすることができます。
DDC の使用については、「派生データ キャッシュ」のドキュメントを参照してください。 UE では共有 DDC をホストするメソッドを複数サポートしていますが、Zen Storage サーバーを推奨しています。
自動テストでテストの規模を拡大する
UE には、さまざまなコンテキストでコードをテストするための多様な自動テスト フレームワークが用意されています。 これらを使用することにより、コードのバグをより早く、より頻繁に検出できるようになり、QA テスターにはユーザー エクスペリエンスの問題に集中できる余裕ができます。 詳細については、「自動テスト フレームワーク」セクションを参照してください。