Nightingale の飛躍的向上を実現：Inflexion Games が開発途中で UE4 から UE5 にアップグレードした方法

エンジンのアップグレードを管理するプロセス

ブループリント プロジェクトを使用している場合は、エンジンのアップグレードは非常に簡単です。コードを更新する必要がなく、新しいエンジンのバージョンでプロジェクトをロードして、表示されるアセット エラーを確認し、エンジンが警告を出している問題を修正するだけで済みます。

コード プロジェクトのアップグレードはより複雑になるため、ここではコード プロジェクトのアップグレードについて説明します。重要なのは、エンジンをどのくらいカスタマイズしたかということです。エンジンに一切変更を加えていない場合は、引き続きアップグレードは簡単です。ただし、エンジンを大幅に変更している場合は、アップグレードが一気に大変な作業になります。Nightingale プロジェクトでは、中程度のカスタマイズを行っていたため、以下のプラクティスがアップグレード プロセスの管理に役立ちました。

エンジンからの乖離を管理する

エンジンへの変更をマークアップして、追跡すると役立ちます。これを行うことで、コードの競合をマージするプロセスが簡素化されるからです。Nightingale では、次のプロセスを実行しました。

• エンジンへのすべての変更は、承認者グループによってレビューされます。Nightingale プロジェクトでは、レビュー担当者は、エンジンのアップグレードを担当するプログラマーと同じであるため、メンテナンスが困難になるような変更を指摘することができます。
• Inflexion Games では、できるだけ多くの変更を Epic に提案することを奨励しています。「Unreal Engine のソース変更を提案する」を参照してください。こうすることで、将来のリリースを導入した際のコードの乖離を除去することができます。
• コードですべての変更をタグ付けし、Jira チケットで追跡します。次に例を示します。

// NTGL_BEGIN - NTGL-1234 - [IMPROVEMENT] 初期化されていない変数を修正する
// int IntVar;
int IntVar = 0;
// NTGL_END
 

• 乖離は以下のように分類されます。
  • [IMPROVEMENT] - Epic に送信するのに適した変更
  • [TEMP] - 一時的に (通常はエンジンの次のメジャー アップデートまで) 必要な変更。
  • [PREPORT] - 将来のアップデートから取り入れた変更
  • [DIVERGENCE] - ゲームのシッピングのためにこの変更を行う必要があるものの、Epic に提案するのに適した変更ではない (通常、このような変更は避ける必要がある)
• Jira チケットを使用すると、UDN へのリンク、変更を必要とするその他のタスクへのリンク、変更の削除に必要なタスクなど、変更に関する詳細なコンテキストを追跡することができます。
• 乖離をエンジンのアップデートと簡単にマージできない場合、通常、変更を中断して、新しいコードで再実装するか、変更を完全に放棄します。

統合プロセス

エンジンのアップデートは、最初は Epic の Github からアップデートを取得し、「Engine」フォルダの内容をすべて置き換えて、P4V を介してオフライン作業を調整するだけの簡単な作業です。ただし、エンジン コードに変更を加ていくと、一気に管理が困難になります。

私たちは、Perforce のストリーム デポを活用して、以下のブランチを設定しました。

デポ/ストリーム	説明
//ue4/release-4.27 //ue5/release-5.0	UE4 / UE5 リリースの未変更のミラー
//ntgl/dev	チームのほとんどが作業に携わるメインの開発ストリーム
//ntgl/integrate	エンジンのアップデートをマージする dev の子ストリーム このストリームは、すべての問題が解決されるまで、機能しない状態になると想定されます。

UE5 へのアップグレードを開始する前に、UE4 の最終バージョン (//ue4/release-4.27) を統合ストリームにマージして、リビジョン履歴を作成することをお勧めします。まだ 4.27 を使用していない場合は、一度に複数のバージョンをまとめてアップグレードすることを検討しているかもしれませんが、経験上、一度に 1 バージョンずつ段階的にアップグレードする方が確実に簡単です。

その場合は、release-5.0 ブランチを次のように作成しましょう。

• //ue4/release-4.27 から //ue5/release-5.0 に p4 copy を実行する(最初は 4.27 のコピーとして作成する)
• 公式リリースの ue5/release-5.0 の内容をアップデートする

このアップデートとマージの手順は次のようになります。

1. 開発ストリームのすべての変更を統合ストリームにマージします。
   • コンテンツの変更で競合が発生した場合は、コンテンツ クリエイターの作業が失われないように、常に開発ストリームの変更を受け入れます。
2. 別の Perforce デポ (たとえば、//ue5/release-5.x) に目的の Unreal リリースのミラーを作成します。
   • このミラーは未変更のままにする必要があります。これにより、Perforce のリビジョン履歴でエンジンの変更を追跡し、マージ手順をサポートする役割を果たします。
3. /integrate を //ue5/release-5.x から//ntgl/integrate にマージします
4. マージの競合を解決し、サブミットします。

以上のステップはすべて手動で実行できますが、少し手間をかけてスクリプトで自動化すると非常に役立ちます。

アップデートをマージした後は、エンジンのアップグレード作業を以下のような個別のステップに分けることができます。

5. コード プロジェクト生成に関する警告やエラーを修正します。
6. コンパイル エラーとリンク エラーを修正します。
7. エディタ エラーとクック エラーを修正します。
8. 自動テストの失敗を修正します。
9. ゲーム バグを修正します。

オートメーション

労力を割いて自動化を行うと、アップグレード プロセスを簡素化するうえで非常に役立ちます。理想的なのは、統合ストリームに対して実行できるイテレーション可能なビルド プロセスを策定し、開発ストリームにマージする前にすべてが機能していることを検証することです。自動化は次のようなその他の分野でも役立ちます。

• 労力を割いて、自動テストの包括的なスイートを維持すると、自動テストの実行が必要になる前に、多くの問題を検出するのに役立ちます。このプロジェクトの UE5 への最初の移行では、自動テストで、UE4 の物理エンジンと UE5 の Chaos 物理との間の多くの不整合をフラグで示すことができました。
• スクリプトを作成することで、リリースのミラー作成のプロセスやマージのさまざまなステップを大幅に迅速化できます。
• また、アセット バリデータを実行し、ゲームをクックする前にすべてのブループリントをコンパイルする (-run=CompileAllBlueprints) 自動化チェックを追加すると、アセットのその他の問題を検出することができます。
• 開発ストリームに行われるものと厳密に同じビルド プロセスで、統合ストリームを頻繁に実行することで、最終的なマージを行う前に、明るみになっていなかったエッジ ケースを確実に検出することができます。
• 大規模なプレイテストを可能にするために、統合ストリームのテスト ビルドを配布するシステムに投資することは、ゲームの問題を早期に検出するうえで役立ちます。

ヒントとコツ

以下は、アップグレードのプロセスを簡素化するために私たちが実践しているヒント集です。

• エンジンのメジャー アップグレードを導入する際、ほとんどのファイルは自動的に解決されますが、数万の変更が記載されたチェンジリストが残ります。次の p4 コマンドを使用すると、手動で解決する必要のあるファイルを別のチェンジリストに分離できます。

p4 -F %localPath% resolve -n | p4 -x - reopen -c [new changelist #]
 

• コンパイル エラーやリンク エラーを修正するときは、-DisableUnity でコンパイルします。これにより、多数の .cpp ファイルを 1 つにまとめる UnrealBuildTool のコンパイル最適化が無効になります。コンパイルには時間がかかりますが、コンパイル時の問題の追跡ははるかに容易になり、include ステートメントの欠落に関連する問題も検出できるようになります。
• github 経由で Unreal Engine を入手した場合、GitDependencies.exe から取得したファイルをどのように取り込むかを決定する必要があります。デベロッパーにこれらのファイルを個別に更新してもらうことができます。Nightingale プロジェクトでは、これらのファイルをミラー自動化スクリプトに組み込み、これらのファイルを独自の Perforce ミラーにサブミットしました。
• Unreal Engine の非推奨に関する警告には細心の注意を払う必要があります。これらは、多くの場合、プロジェクトのアップグレードに関する適切な情報を提供します。警告が表示されないコンパイルを維持することで、このような非推奨事項をはるかに簡単に把握できるようになります。
• すべてのアセットを統合ストリームに含めると、必要に応じて、自分で個々のアセットをアップグレードできます。私たちはこの作業をそれほど多く行う必要はありませんでしたが、メインの開発ストリームでアセットが定期的に変更される場合、管理が面倒になる可能性があります。以下は、この問題を解決するための推奨事項です。
  • 開発ストリームに最小限のエンジンの変更を選択し、開発でアセットを更新できれば、競合の発生をなくすことができます。
  • コマンドレットを使用してアセットをアップグレードできる場合、マージ後に必ず実行されるコマンドレットをビルドして、関連するすべてのアセットが最新の状態に保たれるようにすることができます。多くの場合、単にエディタの最新バージョンでアセットを再保存する必要があります。
• Epic を使用すると、リリースが早期プレビュー ステータスになる前であっても、リリース ブランチにアクセスすることができます。これにより、次期リリースのマージに早い段階で対応できるため、一度にマージするコードの範囲を縮小することができます。同様に、日常的に開発ラインのマージを行うことで、困難なマージが発生したときにすぐに対応できます。そのため、関連するデベロッパーと協力して問題に対処することができます。
• サードパーティのプラグイン (マーケットプレイスや他のベンダーのプラグイン) に依存している場合は、それらのプラグインがアップデートされるまで少し待ちましょう。このようなアップデートより前にアップグレードしてしまうと、少し待てば「無料」で入手できるプラグインを追加の労力を費やしてアップデートしなければならなくなります。
• 新しいエンジンがアップグレードされるたびに、非常に役立つ機能が追加されます。新機能は魅力的であるため、すぐにでも利用を開始したくなりますが、目標はあくまで、ゲームやデベロッパーのワークフローにできるだけ少なく有意な変更を加えることで、新しいエンジンのアップデートを開始することです。開発ストリームでアップグレードが安定していると確認できた後に、初めて新機能の試用を開始しましょう。

 

Unreal Engine 5 のメリット

Lumen と Nanite へのアップグレードは期待に満ちたものでした。より正確なバウンス ライトや、ゲームのポリゴンの性能を大幅に向上させる機能に期待しない人はいないでしょう。

仮想シャドウ マップも活用したかったので、時間はかかりましたが、プロジェクトを Nanite に変換しました。Unreal Engine 5 では、Nanite アセットと非 Nanite アセットの相互運用性がサポートされているため、徐々に変換を行うことができました。このことにより、移行することで、完全にプレイアブルな体験が実現しました。何といっても、Nanite を使用するためにより多くのアセットを変換すると、仮想シャドウ マップのパフォーマンスの向上を期待できます。この変換を行うことで、自分のゲームがどのようなパフォーマンスを発揮するかを把握したいと思わずにはいられないでしょう。

個々のアセットの変換プロセスは、次のいずれかのカテゴリに分類される傾向がありました。

• 一部のアセットは、すでに十分に忠実度が高いため、メッシュ上で Nanite を有効にしただけで済みました。
• 一部のアセットは、より高い忠実度で再度作成した方が良いため、Nanite を念頭に置いて再作成しました。
• プレイヤーが作成した構造物はカスタム シェーダーを備えており、プレイヤーが構造物を配置するときに、透明性を使用してレンダリングしていました。Nanite は不透明なオブジェクトでのみサポートされるため、メッシュがこの特別な配置モードを使用している場合、透明性を備える非 Nanite メッシュにフォールバックするシステムを実装しました。

5.0 から 5.2 へとバージョン アップを重ねるたびに、ボリュメトリック クラウド レンダリングの向上や、Lumen によるフォリッジのレンダリングの向上など、エンジンの多くの機能が向上しました。最終的には、Nanite、Lumen、仮想シャドウ マップを組み合わせることで、非常に印象的なビジュアルを実現することができました。