Unreal Engine 5 への移行ガイド

このガイドでは、Unreal Engine 4 プロジェクトを Unreal Engine 5 (UE5) 用にアップグレードする方法について説明しています。

Unreal Engine 5 (UE5) では、Unreal Engine 4 (UE4) を構成するシステムに対する一連の変更、アップグレード、および新機能が導入されています。エンジンには大幅な変更が加えられていますが、ビルトインの変換プロセスが、ほぼすべての移行に伴う作業を処理します。ユーザーが操作する必要はありません。

この作業を開始するには、Epic Games Launcher から UE5 を開きます。UE5 がすでに実行されている場合は、メインメニューで、[File (ファイル)] > [Open Project (プロジェクトを開く)] の順に選択します。次に、アップグレードするプロジェクトを選択して、[Open (開く)] をクリックします。

[Open a Copy (コピーを開く)] ボタンをクリックして、元のプロジェクトは変更せずに、プロジェクトの別のコピーをアップグレードします。

このダイアログで [More Options (より多くのオプション)] クリックすると、次のいずれかを選択することができます。

• 変換をスキップ。プロジェクトをそのまま開くことを試みます。
• インプレース変換。既存のプロジェクトのコピーを作成するのではなく、変換を試みます。

プロジェクトを UE5 に変換する際は、前述の コピーを開く ワークフローを使用してください。[Convert in-place] オプションと [Skip conversion] オプションは想定通りに動作しないことがあり、その結果、データの破損や喪失につながる場合があります。

プロジェクトを Unreal Engine の新バージョンに更新すると、旧バージョンで開くことができなくなります。開こうとすると失敗します。

変換プロセスが完了すると、ほとんどのプロジェクトは、UE5 でビルド、実行できるようになるので、その他の操作を行う必要はありません。ただし、新規またはアップグレードされた機能の中には、UE5 で適切に動作し、その機能を最大限に活用するために、手動でのアップデートが必要なものもあります。中でも極めて大きなシステム変更は、Nanite、Lumen、および Chaos です。Lumen では、グラフィックス中心のプロジェクトを UE4 と同じように見せるために、ある程度の作業が必要になります。また、Chaos にまだ切り替えていない物理を多用するプロジェクトでは、構成とアセットの変更が必要になります。

このページでは、非推奨と置換となるシステムなど、必須となるアップデートおよび注目すべきシステム変更について説明します。これらの機能を使用している場合、UE4 プロジェクトを正常に UE5 に追加するために、「必須となるアップデート」セクションで説明するアップデートを実行する必要があります。「その他の変更」セクションで説明されているアップデートは、プロジェクトに影響があってもなくても、覚えておく価値があります。

バージョン別の変換に関する注意

プロジェクトを作成した Unreal Engine のバージョンとプロジェクトの変換に関する注記は、以下の対応表を参照してください。

アセットの互換性

Unreal Engine の古いバージョンで保存されたアセットは、新しいバージョンで開くことができます。たとえば、Unreal Engine 4.26 で保存したアセットを Unreal Engine 5.0 で開くことができます。

Unreal Engine の新しいバージョンで保存されたアセットは古いバージョンで開くことは できません。たとえば、Unreal Engine 5.0 で保存したアセットを Unreal Engine 4.26 で開くことはできません。

必須のアップデート

以下のセクションでは、UE5 に UE4 プロジェクトを取り込むために必要な変更について説明します。これらの変更の一部は必須です。それ以外はで省略可能ですが推奨されています。ただし、UE5 の将来のバージョンでは必須になります。

開発プラットフォームの変更

Visual Studio で C++ コードを作成しているものの、まだ Visual Studio 2019 を使用していない方は Visual Studio 2019 に切り替えてください。Visual Studio 2019 は最新バージョンの UE4 でもデフォルト Visual Studio IDE です。UE5 は、Visual Studio 2017 および Visual Studio 2015 をサポートしていません。

UE5 は 32 ビット プラットフォームをサポートしておらず、将来的にも 32 ビット プラットフォームをサポートする予定はありません。

UE5 では、ターゲット プラットフォーム名 が標準化されています。そのため、ビルド スクリプト、場合によっては「DeviceProfiles.ini」ファイルを更新する必要があります。これは主に、これらのスクリプトを直接実行している場合に影響があります。UAT を使用しているデベロッパーは、変更を行う必要はありません。

以下の表に、変更された対象プラットフォーム名の一覧を示します。

PhysX と Chaos Physics システム

UE5 の物理シミュレーションでは、デフォルトで PhysX の代わりに Chaos Physics エンジンを使用します。PhysX は UE5 には引き続き搭載されていますが、今後のリリースで削除されます。Chaos Physics の下での物理シミュレーションは PhysX とは動作が異なるため、開発者は一貫した動作を出力させるために調整が必要です。

新規作成されたプロジェクトの物理ティック レートはデフォルトで変更されます。ティック レートの変更は、[Project Settings] 内の Tick Async Physics (メニュー： [Edit (編集)] > [Project Settings]) からアクセスできます。この新機能は Game スレッドではなく、独自のスレッドで物理をシミュレートします。

この変更により、物理シミュレーションの更新を固定レートで実行され、決定論が強化されます。更新レートが固定された結果、クライアント システムとサーバー システムが同じ間隔で実行されるため、ネットワーク化された物理のシミュレーションを同期することが容易になります。

ゲーム スレッドで実行されなくなったということは、ゲーム スレッドから物理システムへの入力と、その入力に対する物理システムの反応の間に遅延が生じる可能性があることを意味します。ゲームプレイ ロジックが物理シミュレーションに大きく依存するプロジェクトでの予測不可能な動作を避けるために、この遅延を考慮する必要があります。物理演算を多用するゲームプレイのコードを、物理スレッドで実行される C++ のコールバックで起動することでこの問題を軽減することができますが、この手法を用いるには、プロジェクトのコードの修正が必要です。

シェーダー デバッグのためのコンソール変数

Unreal Engine 5 のリリースにおいて、シェーダーのデバッグに使用されるコンソール変数が変更されました。以下はこの名称変更に関する操作ガイドです。

プロジェクトの中でこれらのコンフィグ ファイルで変数を使用している場合、シェーダー デバッグの生成データの使用を継続するために、UE5 への移行時にこれらを更新する必要があります。

シンボルのみが必要な場合、ランタイム シェーダー データへの変更を取り除くために、コンソール変数 r.Shaders.KeepDebugInfo は2 つのコンソール変数に分割されました (r.Shaders.Symbols と r.Shaders.ExtraData)。最終的なシェーダー データを変更せずにシッピング ビルド用のシンボルを生成できるため、エクスポートされたデバッグ情報をサポートするプラットフォームで有用です。

この処理に関する詳細は、「シェーダー デバッグ」を参照してください。

その他の変更

このアップデートでは、Unreal Engine 4 (UE4) のプロジェクトを Unreal Engine 5 (UE5) で実行する必要はありませんが、将来のバージョンでは必要になるかもしれません。また、Unreal Engine の機能を十分に活用するのに役立つかもしれません。

このページを読んで Unreal Engine 5 (UE5) の今後のバージョンに備え、Unreal Engine の新しい機能やアップグレードした機能を十分に活用してください。

C++ オブジェクト ポインタのプロパティ

次のセクションは、C++ コードを使用するプロジェクトのみを対象とします。ブループリント ビジュアル スクリプティングのユーザーは、何も操作を行う必要はありません。C++ ライセンシー プロジェクトは生オブジェクト ポインタのオプションの使用を継続するか、またはTObjectPtr の使用を開始することができます。

UE5 では、エディタ ビルドでの生オブジェクト ポインタのオプションの代わりとして、テンプレートベースの 64 ビット ポインタ システムである TObjectPtr が導入されています。このシステムは、エディタ ビルドでは動的解決とアクセス トラッキングを追加し、非エディタ ビルドでは生ポインタと同じ操作を実行します。TObjectPtr 変数も、関数に渡されるとき、またはローカル変数に格納されるときに、自動的に生ポインタに変換されます。これまで UPROPERTY 変数の生ポインタを使用していたエンジン クラスの多くは、TObjectPtr を使用するようになります。TObjectPtr 型とのインタラクションのほとんどは暗黙的に生のポインタに変換されますが、エンジン クラスのメンバー変数との直接のインタラクションは稀なケースとして生のポインタのセマンティクスから TObjectPtr のセマンティクスに変更する必要があります。たとえば、AActor の RootComponent プロパティは UE4 では USceneComponent* でしたが、UE5 では TObjectPtr<USceneComponent> です。USceneComponent* 戻り値型を持つ GetRootComponent への呼び出しは常にそのままにしておくことができますが、RootComponent との直接の対話については更新が必要な場合があります。

オプションとして、 UCLASS 型と USTRUCT 型にある UObject ポインタのプロパティやコンテナ クラスには T* よりも TObjectPtr<T> の使用をお勧めします。TObjectPtr は非エディタ ビルドの生ポインタに変換するため、出荷された製品の動作やパフォーマンスには影響しませんが、エディタ ビルドでの開発時のエクスペリエンスが向上する可能性があります。以下の方法で、プログラミング スタイルをこの新しいポインタ システムに適応させることができます。

• コンテナ関数の「Find」ファミリーを呼び出す場合は、T** ではなく TObjectPtr<T>* を使用して戻り値を取得します。

• 生ポインタ コンテナによる範囲ベースのイテレーション処理は、イテレータ変数の型として auto* を使用している可能性があります。これらを auto& に変更します。また、TObjectPtr は解決されたオブジェクト アドレスをキャッシュできるため、将来のアクセス試行時間の節約になるため、新しいコードでは auto& または const auto& の使用をお勧めします。

• 生ポインタが必要で、暗黙の変換ができない場合は、TObjectPtr で ToRawPtr または Get を呼び出します。一般的なケースとしては、三項演算や const_cast の内部などがあります。関数デリゲートにパラメータを渡す場合は、パラレル デリゲート関数をパススルーとして宣言し、生ポインタを TObjectPtr パラメータで置き換えます。以下は、パススルー デリゲート関数の例です。

        // Original function signature, using raw pointers, which we will use in most cases:
        static bool MyFunction(UObject* FirstParameter);
  
        // In rare cases where implicit conversion is not available, use this pass-through function.
        // Pass-through function signature, using TObjectPtr:
        static bool MyFunction(TObjectPtr<UObject> FirstParameter);
  
        // Pass-through function body (in the source file):
        bool UMyClass::MyFunction(TObjectPtr<UObject> FirstParameter)
        {
            return ShouldShowResetToDefault(FirstParameter.Get());
        }
  Copy full snippet

  // Original function signature, using raw pointers, which we will use in most cases: static bool MyFunction(UObject* FirstParameter); // In rare cases where implicit conversion is not available, use this pass-through function. // Pass-through function signature, using TObjectPtr: static bool MyFunction(TObjectPtr<UObject> FirstParameter); // Pass-through function body (in the source file): bool UMyClass::MyFunction(TObjectPtr<UObject> FirstParameter) { return ShouldShowResetToDefault(FirstParameter.Get()); }

関数にパラメータを渡したり、ローカル変数にデータを保存したりする場合など、ほとんどの場合、TObjectPtr は自動的に生のポインタ タイプに変換します。上記のように、若干のコード変更がまれに必要な場合はありますが、ほとんどのプロジェクトでは必要はありません。

オプション変換ツール

UE5 には、エンジンから見える生ポインタのプロパティを TObjectPtr システムに自動変換するための UnrealObjectPtrTool というプログラムが含まれています。プログラムは、コード IDE のソリューション階層の UE5/Programs/UnrealObjectPtrTool/ セクションにあります。ソースコードは Engine/Source/Programs/UnrealObjectPtrTool/ にあります。実行ファイルは「Engine/Binaries/Win64」フォルダの中にあります。オペレーティング システムまたは開発環境によって、この実行ファイルは「Engine/Binaries/OS (OS は使用しているオペレーシング システム)」フォルダに存在する場合があります。

このオプション プログラムの目的は、コードの生ポインタから TObjectPtr システムへの変換処理を迅速化することです。ヘッダ ファイル内のクラスおよび構造体定義の UPROPERTY 変数を更新しますが、上記のようにソース コードに必要な変更をすべて行うわけではありません。これらの調整は手動で行い、UnrealObjectPtrTool を使用する前にプロジェクトがコンパイルされていることを確認する必要があります。

UnrealObjectPtrTool を使用するには、次の手順を実行します。

1. 「Engine\Programs\UnrealHeaderTool\Config」ディレクトリにある「DefaultEngine.ini」 UHT コンフィグ ファイルへ移動します。

2. DefaultEngine.ini ファイル内で次のスクリプトを修正します。

    	NonEngineNativePointerMemberBehavior=AllowAndLog
   Copy full snippet

   NonEngineNativePointerMemberBehavior=AllowAndLog

3. すべてのコードが UHT でパースされるようにプロジェクトをリビルドします。

4. UHT ログはプロジェクトがコンパイルされている方法によって Log_UHT.txt または UnrealHeaderTool.log という名前になる場合があります。以下のフォルダ ディレクトリのいずれかに移動することができます。

        C:\Users\USERNAME\AppData\Local\UnrealBuildTool\Log_UHT.txt
        C:\Users\USERNAME\AppData\Local\UnrealHeaderTool\Saved\Logs\UnrealHeaderTool.log
        Engine\Programs\UnrealBuildTool\Log_UHT.txt
   Copy full snippet

   C:\Users\USERNAME\AppData\Local\UnrealBuildTool\Log_UHT.txt C:\Users\USERNAME\AppData\Local\UnrealHeaderTool\Saved\Logs\UnrealHeaderTool.log Engine\Programs\UnrealBuildTool\Log_UHT.txt

5. Visual Studio ソリューションから UnrealObjectPtrTool をコンパイルします。

   この手順はエンジンをソースから実行する場合のみ必要になります。それ以外の場合、UnrealObjectPtrTool はインストール時に Epic Games Launcher からプリコンパイルされます。

6. UnrealObjectPtrTool 実行ファイルを実行します。

           UnrealObjectPtrTool.exe <UHT_LOG_PATH> -SCCCommand="p4 edit -c UPGRADE_CL {filenames}"
   Copy full snippet

   UnrealObjectPtrTool.exe <UHT_LOG_PATH> -SCCCommand="p4 edit -c UPGRADE_CL {filenames}"

   省略可能なパラメータ -PREVIEW または -n を追加して、潜在的な変更のプレビューを取得できます。

レンダリング

以下のデフォルト設定は変更は変更されており、プロジェクトの外観に影響を与えるかもしれません。

• スクリーン スペース グローバル イルミネーション： スクリーン スペース グローバル イルミネーション (BETA) のプロジェクト設定と関連するコンソール変数 r.SSGI.Enable は削除され、以前の状態は失われます。スクリーン スペース グローバル イルミネーションをプロジェクトのデフォルトのグローバル イルミネーション メソッドとして再度有効にする場合は、[Project Settings (プロジェクト設定)] > [(Engine) Rendering (レンダリング)] > [Global Illumination properties (グローバル イルミネーション プロパティ)] から Dynamic Global Illumination Method を Screen Space (Beta) に設定します。ポスト プロセス ボリュームでスクリーン スペース グローバル イルミネーションを再度有効にする場合は、ボリュームのプロパティで Global Illumination カテゴリを探し、[Method (メソッド)] フィールドを [Screen Space (Beta) (スクリーン スペース ベータ)] に設定します。

• Lumen ハードウェア レイトレーシングでレイトレーシングをサポート: スタンドアローン レイトレーシングの機能は Unreal Engine 5 で非推奨となりました。ただし、Lumen がこれらのライティング機能に対応しているため、これらのライティング効果を計算するエンジンの機能は削除されていません。削除されている機能は Unreal Engine 4 で開発されてきたスタンドアローン レイトレーシング システムです。これらの機能の大部分は、それぞれが別々に機能していたため、エンジンの同じ機能を同等に、または一貫してサポートすることが保証されていませんでした。Lumen には、ハードウェア レイトレーシング パスに反射とグローバル イルミネーション用の完全に新しいレイトレーシング機能が追加されています。UE5 の開発が継続されると共に、Lumen のレイトレーシング機能もエンジンの他の機能の一部として機能するように幅広いサポートを提供できるように引き続き改善されます。

  • レイトレーシング リフレクション、グローバル イルミネーション、シャドウは、それぞれ独立して有効化できるように、機能ごとに切り分けられました。これらの各機能を使用するには [Project Settings] > [Rendering] の順に開き [Support Hardware Ray Tracing] を有効にする必要があります。

  [Global Illumination] セクションで Dynamic Global Illumination Method を選択するのが好ましいです。 [Reflections] セクションで Reflection Method を選択するのが好ましいです。 * [Hardware Ray Tracing] セクションで [Ray Tracing Shadows] を使用するようにチェックを入れます。

  • リフレクションとグローバル イルミネーションは、Post Process ボリュームでグローバル イルミネーション メソッドとリフレクション メソッドから選択しても設定することができます。

• *メッシュ距離フィールドの生成: Lumen の ソフトウェア レイ トレーシング 機能のメッシュ表現は 符号付距離フィールド に大きく依存しています。すべての 距離フィールド の デフォルトのボクセル密度 は、0.1 から 0.2 に増加しました。Lumen でのソフトウェアのトレース品質の向上のためには必要ですが、距離フィールドのメモリ使用量が大幅に増加します。このプロパティを調整するには、[Generate Mesh Distance Fields (メッシュ距離フィールドの生成)] チェックボックスと 距離フィールド ボクセル密度 のプロパティがある、[Project Settings] > [(Engine) Rendering] へ移動します。反映するにはこの設定の変更後にエディタの再起動が必要な場合があります。

削除事項

Nanite は、ハードウェア テッセレーション のほとんどのユース ケースを廃止します。ハードウェア テッセレーションは UE5 から削除されました。Nanite がサポートしていないユース ケースについて、必要に応じてユーザーはアセットの解像度を上げることができます。

ライト プロパゲーション ボリューム と 距離 フィールド グローバル イルミネーション (DFGI) を Lumen に置き換えます。

• ライト プロパゲーション ボリュームと比較して、Lumen はベースラインのパフォーマンス コストは高いですが、追加の機能や非常に高い品質を実現し、現在開発中です。

• DFGI は実験段階の機能でした。デベロッパーは、ダイナミック グローバル イルミネーションには DFGI の代わりに Lumen を使用してください。

• 時間とともに、レイ トレーシングの機能の大部分が、同等またはそれ以上の質の結果を実現する Lumen のグローバル イルミネーションと反射に置き換わります。

UE4 では非推奨だった レガシー トーンマッパ は、UE5 では存続しません。デベロッパーの操作は不要です。

非推奨事項

• Cascade は UE 5.0 では非推奨となり、今後のリリースでは廃止される予定です。UE5 デベロッパー は Niagara に切り替えてください。Cascade のデータを Niagara にアップグレードする自動コンバータは現在開発中です。
• レイトレーシング 機能は、これらの機能を Lumen の Hardware Ray Tracing システムに統合するためのサポートを必要とするスタンドアローン システムでは非推奨となり削除されています。つまり、リフレクションとグローバル イルミネーションは直接 Limen に統合されます。エンジン機能の幅広いサポートで統一されたエクスペリエンスを提供するために、これらのスタンドアローン機能は非推奨となりました。(詳細は前述の「レンダリング」セクションを参照してください。)

ワールドのビルド

非推奨事項

World Partition は、大規模なストリーミング ワールドを処理するために UE5 が使用するシステムです。UE4 が使用していた World Composition システムはまだ存続しますが非推奨です。アップグレード、修正、サポートは受けられません。World Composition は、UE5 の今後のバージョンでは削除されます。

マップを World Partition システムに変換する場合は、プロジェクトで WorldPartitionConvertCommandlet を使用し、変換する各マップ名を 1 つずつ入力します。例として、パッケージ化されたプロジェクト QAGame 内の /Game/Maps/Tools/Landscape/TM_WorldComp_P にあるTM_WorldComp_P マップを変換するには、コマンドライン オプションでエディタを実行します。

	QAGame -run=WorldPartitionConvertCommandlet TM_WorldComp_P -ConversionSuffix -SCCProvider=None
Copy full snippet

QAGame -run=WorldPartitionConvertCommandlet TM_WorldComp_P -ConversionSuffix -SCCProvider=None

これにより、TM_WorldComp_P マップがワールド パーティション システムに変換されます。-ConversionSuffix は、変換したマップが元のマップを上書きする代わりに TM_WorldComp_P_WP として保存します。-SCCProvider=None オプションにより、コマンドレットはプロジェクトのソース コントロール プロバイダを操作することなく実行します。また、このプロセスはマップの変換に使用した設定と将来の変換のための設定を含む「TM_WorldComp_P.ini」ファイルを生成します。この変換プロセスは既存の World Composition データから (ワールド パーティション システムのための) ランタイム グリッドをビルドし、マップのアクタを適切なグリッドに割り当てます。

C++ を使用するデベロッパーは、グリッドの生成に関わるロジックやアクタの割り当ての検討や修正するには、「UWorldPartitionRuntimeSpatialHash::ImportFromWorldComposition」と「UWorldPartitionRuntimeSpatialHash::GetActorRuntimeGrid」を参照してください。

ツール

ゲームプレイ フレームワーク

実験的な レガシー編集可能メッシュプラグイン を、新しいジオメトリ編集ツールに置き換えます。

ムービー シーンのキャプチャ を ムービー レンダー キュー に置き換えます。

VR レベル編集 は、VR プレビューのみの対応になりますが、UE5 は引き続きバーチャル プロダクション スカウティングに対応します。

シーケンス レコーダー を Take Recorder に置き換えます。Take Recorder にはシーケンス レコーダーのすべての機能が含まれます。

カメラ アニメーション を カメラ アニメーション シーケンス に置き換えます。

UE5 は、削除されたプラグインに関連する エディタ機能パック も削除します。ユーザーは、削除されたプラグインが自分のプロジェクトで削除されたコンテンツを参照しないようにする必要があります。

非推奨事項

UE5 の完全版のリリース後、Matinee は シーケンサー に完全に置き換わります。Matinee は非推奨でしたが、UE4 ではまだ存続していました。

コントロール リグ

変更

Spaces (空間) は Nulls に名前が変更されました。

Gizmos は Shapes (形状) に名前が変更されました。

Set Initial Transform from Current (現在から初期トランスフォームを設定) は Set Offset Transform from Current (現在からオフセット トランスフォームを設定) となりました。

非推奨事項

Collection (コレクション) は Array (配列) に置き換えられました。

Transform Constraint ノードは非推奨となり、point、rotation、parent contraint という個々のノードになりました。

Project to New Parent ノードと Set Transform ノードに代わって、新しい Parent Constraint ノードが使用できるようになりました。

Parent Switch Constraint の代わりに Space Switching を使用できるようになりました。

Bezier Data Type は Splines plugin に置き換わりました。

ControlRigHierarchyModifier は Python で使用されなくなり、リグ要素のクエリには RigHierarchy、リグ要素の作成には RigHierarchyController に置き換えられました。

ControlRigBlueprint には controller という名前のプロパティがなくなりました。メインの RigVMController にアクセスするには、関数 ControlRigBlueprint.get_controller() を使用します。

マッピングはコンストラクション スクリプトではなく、コントロール リグ コンポーネントの Pre-Initialize で処理されます。

オーディオ

ゲームプレイ フレームワーク

UE 5.0 では非推奨の レガシー オーディオ バックエンド を Unreal オーディオ ミキサー に置き換えます。ユーザーの操作は不要です。UE5 は Unreal オーディオ ミキサーを使用し、デフォルトで最新のオーディオ バックエンドを使用します。すべての既存のオーディオ機能と相互性があります。

非推奨事項

オーディオ ボリューム、サウンド クラス ミックス、サウンド キュー は、UE 5.0 では非推奨となり、UE5 の今後のリリースでは削除される予定です。

• サウンド キューは UE 5.0 で利用可能となる MetaSounds に置き換わります。

• サウンド クラス ミックスは、現在利用可能な モジュレーション システムと サブミックス システムに置き換わります。

• オーディオ ボリュームは UE 5.0 で利用可能となる、現在開発中の新しいシステムに置き換わります。

ユーザーの皆さまには、できるだけ速くこれらのシステムの新バージョンに移行されることを推奨いたします。

ゲームプレイ フレームワーク

ゲームプレイ フレームワーク

Blueprint Nativization (ブループリントのネイティブ化) は UE5 では存続しません。この機能を利用したプロジェクトを正しく機能させるための変更はなく、修正も必要ありませんが、パフォーマンスに影響があるかもしれません。その場合、デベロッパーは他の最適化のアプローチを取る必要があります。

ネットワーキング

非推奨事項

AES、RSA、RSA Key AES 暗号化ハンドラ は、UE 5.0 の時点で非推奨となり、UE5 の今後のリリースでは削除される予定です。この時点では DTLS のみ使用されています。

*AES GCM は UE 5.0 以降も使用可能ですが、UE5 の今後のバージョンでは削除されます。この変更によってユーザーがプロジェクトを修正する必要はありません。

コア

ゲームプレイ フレームワーク

Event-Driven Loader を Zen Loader に置き換えます。ほとんどのユーザーは Event-Driven Loader を直接連動しないため、この変更ではプロジェクト移行中の操作は不要です。

非推奨事項

UE5 の完全版のリリース後、統計システム は Unreal Insights インストルメンテーションに置き換わります。統計システムは UE 5.0 でも今後も存続しますが、最終的には Unreal Insights に移行します。