移行ガイド

Unreal Engine 4 プロジェクトの Unreal Engine 5 早期アクセスへの簡単、スムーズな移行。

Windows
MacOS
Linux

Unreal Engine 4 プロジェクトを Unreal Engine 5 早期アクセス (UE5EA) 用にアップグレードするにはこのガイドの手順に従ってください。

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

まず、Epic Games Launcher から UE5 早期アクセスを起動します。すでに UE5 Early Access を実行している場合は、メインメニューから [File] > [Open Project] を選択します。次にアップグレードするプロジェクトを選択して、[Open (開く)] をクリックします。

Launcher.png

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

ConversionOptions.png

プロジェクトを UE5 Early Access に変換するときに、前述した Open a Copy ワークフローを使用することを強く推奨します。[Convert in-place] オプションと [Skip conversion] オプションは期待通りに動作しない場合があります。

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

このページでは、必須のアップデートについて説明します。これらの機能を使用している場合は、UE4 プロジェクトを正常に UE5 に追加するには、ここで説明するアップデートを実行する必要があります。また、「Unreal Engine 5 の重要な変更点」では、システムの非推奨化と交換、および将来必要になる可能性のある変更について解説されており、UE5 を最大限活用したい方にとって有益です。

このガイドは、UE5EA を中心に取り上げ、UE5 で次世代ゲームのプロトタイプを作成して、機能や性能を検討したいと考えている開発者を対象としています。この早期アクセス ビルドは、本番環境に対応していないため、ライブ ゲームや開発後期段階のゲームに取り組んでいるチームには推奨しません。UE5EAは、利用可能な最先端のツールを使用したいプリプロダクション・フェーズまたはプロトタイピング・フェーズのゲーム開発プロジェクトに最適です。2022年に UE5 5.0 に変換する準備ができています。ゲーム以外の開発者は、2022年に UE5 5.0 に移行する前に、今夏リリース予定の UE4 4.27 をお勧めします。

必須のアップデート

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

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

Visual Studio で C++ コードを記述している開発者で、まだ Visual Studio 2019 に切り替えていない方は切り替えてください。最新版 UE4 のデフォルト Visual Studio IDE も Visual Studio 2019 です。UE5EA は、Visual Studio 2017 および Visual Studio 2015 をサポートしていません。

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

UE5EA は 対象プラットフォーム名 を標準化するため、開発者はビルド スクリプトと、場合によっては DeviceProfiles.ini ファイルを更新する必要があります。これは主に、直接実行する開発者に影響します。UAT を使用する開発者は変更を加える必要はありません。以下の表に、変更された対象プラットフォーム名の一覧を示します。

UE4 対象プラットフォーム名

UE5EA 対象プラットフォーム名

Windows

WindowsEditor

WindowsNoEditor

Windows

MacNoEditor

Mac

Mac

MacEditor

LinuxNoEditor

Linux

Linux

LinuxEditor

LinuxAArch64NoEditor

LinuxAArch64

XboxOne 用の XDK と GDK

UE5EA で Xbox One GDK プラットフォームは、Xbox One XDK に取って代わる ものです。プロジェクトを更新するには、以下のアクションを実行します。

  • 自動ビルド スクリプトを更新して「XboxOne」プラットフォームへの参照を「XboxOneGDK」に変更します。

  • GDK.UseXDKCompatibleSave CVar は、製品による XDK の セーブ ゲーム データのロードを可能にします。製品が既に小売顧客に公開されている場合は、この CVar を設定します。

ビルトインのダメージおよびスコアの概念

UE5EA には、Unreal Engine の以前のバージョンに存在していた、ダメージ モデルとスコアリング モデルのためのビルトインのデータ型およびコード機能は含まれていません。プロジェクトでこれらを使用している場合、UE5EA で再作成するか、Gameplay Ability System といった他のソリューションを検討してください。

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

次のセクションは、C++ コードを使用するプロジェクトのみを対象とします (ただし大部分の C++ プロジェクトはこれらの修正を必要とせずにコンパイルします)。ブループリント ビジュアル スクリプティングのユーザーは、何も操作を行う必要はありません。

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

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

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

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

  • 生ポインタが必要で、暗黙の変換ができない場合は、TObjectPtrToRawPtr または 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());
    }

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

オプション変換ツール

UE5EA には、エンジンから見える生ポインタのプロパティを TObjectPtr システムに自動変換するための UnrealObjectPtrTool というプログラムが含まれています。プログラムは、コード IDE のソリューション階層の Engine/UE5/Programs/UnrealObjectPtrTool/ セクションにあります。ソースコードは Engine/Source/Programs/UnrealObjectPtrTool/ にあります。

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

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

  1. UE5EA でプロジェクトをコンパイル、クック処理、そして実行します。エディタ ビルドとゲーム ビルド共に対象です。

  2. Unreal Header Tool (UHT) のログ ファイルへのエディタ ビルドからのパスを探して記録します。このファイルはコンパイルプロセスの副産物です。このパスを UHT_LOG_PATH と呼びます。

  3. UnrealObjectPtrTool が変更するヘッダ ファイルを保持する空の変更リストを作成します変更リスト ID を記録します。この ID を UPGRADE_CL と呼びます。

  4. UnrealObjectPtrTool の実行可能ファイルをビルドします。シェルで次のように実行します。.build program UnrealObjectPtrTool.

  5. UnrealObjectPtrTool の実行可能ファイルを実行します。シェルで次のように実行します。

    .run program UnrealObjectPtrTool -- UHT_LOG_PATH -SCCCommand="p4 edit -c UPGRADE_CL {filenames}"
  6. ワークスペースが手順 1 で行ったように、変更したファイルを使用してコンパイル、クック処理、および実行することを確認します。

PhysX と Chaos Physics システム

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

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

  • この変更により、物理シミュレーションの更新を固定レートで実行され、決定論が強化されます。

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

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

PhysX は最終的には UE5 から削除されますが、 UE5EA のユーザーは必要に応じて PhysX をソースからコンパイルして有効にすることができます。