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 (より多くのオプション)] クリックすると、次のいずれかを選択することができます。

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

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

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

変換プロセスが完了すると、ほとんどのプロジェクトは、UE5 でビルド、実行できるようになるので、その他の操作を行う必要はありません。ただし、新規またはアップグレードされた機能の中には、UE5 で適切に動作し、その機能を最大限に活用するために、手動アップデートが必要なものもあります。中でもきわめて大きなシステム変更は、Nanite、Lumen、および Chaos です。Nanite と 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 物理システム

UE5 の物理シミュレーションでは、デフォルトで PhysX の代わりに Chaos 物理 エンジンを使用します。Chaos 物理学の下での物理シミュレーションは PhysX とは動作が異なるため、デベロッパーは一貫した動作を出力させるために調整が必要です。

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

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

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

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

Unreal Engine 5 のリリースでは、シェーダーのデバッグに使用されるコンソール変数が変更されています。名前が変更されたこれらのコンソール変数を示す表を次に示します。

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

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

このプロセスの詳細については、「シェーダー デバッグ」ページを参照してください。

その他の変更点

これらのアップデートは 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 パラメータで置き換えます。以下は、パススルー デリゲート関数の例です。

               // 生ポインタを使用した元関数のシグネチャで、ほとんどの場合に使用します。
               static bool MyFunction(UObject* FirstParameter);
  		
            // 暗黙の変換が利用できない稀なケースでは、このパススルー関数を使用してください。
               // TObjectPtr を使用したパススルー関数のシグネチャ
               static bool MyFunction(TObjectPtr<UObject> FirstParameter);
  		
               // (ソースファイル内の) パススルー関数の本体
               bool UMyClass::MyFunction(TObjectPtr<UObject> FirstParameter)
               {
                   return ShouldShowResetToDefault(FirstParameter.Get());
               }
  Copy full snippet

  // 生ポインタを使用した元関数のシグネチャで、ほとんどの場合に使用します。 static bool MyFunction(UObject* FirstParameter); // 暗黙の変換が利用できない稀なケースでは、このパススルー関数を使用してください。 // TObjectPtr を使用したパススルー関数のシグネチャ static bool MyFunction(TObjectPtr<UObject> FirstParameter); // (ソースファイル内の) パススルー関数の本体 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.txt または UnrealHeaderTool.log という名称のファイルに記録される場合があります。それらのファイルは、次のフォルダ ディレクトリにあります。

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

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

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

   このステップは、エンジンをソースから実行している場合にのみ必要です。それ以外の場合は、Epic Games Launcher からインストールする際に UnrealObjectPtrTool がプリコンパイルされます。

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 を追加できます。

レンダリング

以下のデフォルト設定は変更されており、プロジェクトの外観に影響を与える可能性があります。

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

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

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

  [Global Illumination] セクションで目的の ダイナミック グローバル イルミネーション メソッド を選択します。 [Reflections] セクションで目的の 反射メソッド を選択します。 * [Hardware Ray Tracing] セクションで、使用する レイトレーシング シャドウ のボックスをオンにします。

  • 反射とグローバル イルミネーションは、ポストプロセス ボリュームでグローバル イルミネーション メソッドと反射メソッドを選択することでも設定できます。

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

削除事項

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

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

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

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

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

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

非推奨事項

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

ワールドのビルド

非推奨事項

World Partition は、UE5 が大きなストリーミング ワールドを処理するために使用するシステムです。UE4 が使用していた ワールド コンポジション システムはまだ存続しますが非推奨です。アップグレード、修正、サポートは受けられません。ワールド コンポジションは、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 マップが World Partition システムに変換されます。-ConversionSuffix は、変換したマップで元のマップを上書きする代わりに、TM_WorldComp_P_WP として保存します。-SCCProvider=None オプションにより、コマンドレットがプロジェクトのソース コントロール プロバイダとやり取りすることなく実行されます。また、このプロセスでは、マップの変換に使用した設定と将来の変換のための設定を含む「TM_WorldComp_P.ini」ファイルが生成されます。この変換プロセスは既存のワールド コンポジション データから (World Partition システムのための) ランタイム グリッドをビルドし、マップのアクタを適切なグリッドに割り当てます。

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

ツール

削除事項

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

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

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

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

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

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

非推奨事項

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

コントロールリグ

変更点

Spaces (スペース) の名称が Nulls に変更されました。

Gizmos (ギズモ) の名称が Shapes (形状) に変更されました。

[Set Initial Transform from Current (現在のトランスフォームから初期トランスフォームを設定)] が [Set Offset Transform from Current (現在のトランスフォームからオフセット トランスフォームを設定)] に変更されました。

非推奨事項

Collections (コレクション) が Arrays (配列) に置き換えられました。

Transform Constraint ノードが非推奨となり、point、rotation、parent contraint の個々のノードに置き換えられました。

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

Parent Switch Constraint (親切り替え制限) の代わりに Space Switching (空間の切り替え) を使用できるようになりました。

Bezier Data Type が Splines プラグイン に置き換えられました。

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

ControlRigBlueprint の controller (コントローラー) プロパティは削除されました。メインの RigVMController にアクセスするには、関数 ControlRigBlueprint.get_controller() を使用します。

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

Audio

削除事項

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

非推奨事項

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

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

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

• オーディオ ボリュームは、UE 5.0 で利用可能になる予定 (現在開発中) の新しいシステムに置き換えられます。

できるだけ早くこれらのシステムの新バージョンに移行することを推奨します。

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

削除事項

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

Networking

非推奨事項

AES、RSA、および RSA キー AES 暗号化ハンドラ は非推奨となり、削除が計画されています。

コア

削除事項

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

非推奨事項

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