新しいUEに使ってみたい機能がある。でも、いま動いているゲームが動かなくなるのは困る。そんなときは、制作中のデータをそのまま更新する前に、コピーを新しいUEで開いて試します。
大切なのは、エディタが起動するかだけではありません。キャラクターが動く、扉が開く、結果画面へ進める。以前できていた操作を同じように試し、配布用のゲームも作れるところまで確かめます。
この記事ではLauncherから入れたUEを使い、更新前の状態を残す準備から、コピーの変換、動作の比較までを通します。問題が出ても、元のプロジェクトと古いUEで制作を続けられる状態を先に用意しましょう。
この記事でわかること
- 更新する理由と、プラグインの対応を確かめる方法
- 元のデータを残し、Open a Copyで試す手順
- ログ・Blueprint・Play・パッケージ版を比べるポイント
- 問題が出たときに調べる場所と、制作を再開する方法
上げるべきか、待つべきか
新しい版が出ても、制作中のプロジェクトをすぐ更新する必要はありません。まず「何のために上げるか」を一言で書いてみます。
| 更新を考える理由 | 先に確かめること |
|---|---|
| 使いたい新機能がある | 自分のゲームで使う機能か、必要な環境が揃うか |
| 困っている不具合を直したい | 対象の不具合が、移行先で修正されているか |
| 配布先への対応が必要 | 対応OSや開発ツールなどの条件を満たす版はどれか |
| チームの開発環境を揃えたい | 全員が同じUE・プラグインを用意できるか |
リリースノート は、そのバージョンで変わったことや直った不具合の一覧です。新機能の紹介だけでなく、使っている機能の変更や「Upgrade Notes」も確認します。全項目を読み切るより、入力・描画・アニメーションなど、自分のゲームに関 係する場所から探すと読みやすくなります。
制作終盤なら、更新後の確認に使える時間も重要です。新しい版にするメリットが小さく、今の版で配布できるなら、完成後に試す選択もできます。反対に、配布先への対応など期限のある理由があれば、移行と確認の時間を予定へ入れます。
プラグインは無料・有料を問わず確認する
プラグイン は、UEへ機能を追加する部品です。プロジェクトがその部品を使っていれば、UE本体だけを更新しても同じようには動かない場合があります。
「Edit → Plugins」で使用中のものを確認し、名前・現在の版・移行先への対応をメモします。Fabや開発元の説明で対応版と導入方法を調べます。エンジン側に入れたプラグインは、プロジェクトフォルダのコピーだけでは新しいUEへ移りません。
対応版がまだない必須プラグインがあれば、更新を待つか、代わりの方法を試す時間が必要です。未対応のプラグインがすべて自動的に無効になるわけではなく、プロジェクトを開く段階で止まることもあります。
上げる前に残しておくもの
更新後に困ったときの戻り先は、更新前のデータと、それを開けるUEの組み合わせ です。先に今の版でPlayし、動くことを確認してから「Save All」で保存します。
ソース管理を使っているなら、ここでコミットします。コミットは、その時点の変更を履歴へ残す操作です。ただし、管理対象に入れていないファイルまでは保存されません。LFSで扱うアセットの実データも含め、必要なものが揃っているか確認します（→ Git管理の記事）。
| 残すもの | 理由 |
|---|---|
| プロジェクト一式 | Content・Config・.uprojectに加え、使用するSource・Plugins・Buildなども必要 |
| 古いUEとプラグインの情報 | 元の環境で開き直して比較するため |
| プロジェクト外の必要データ | 外部参照の素材やツールは、プロジェクトのコピーに含まれないため |
| 動作のメモや画面 | 更新前からあった問題と、新しく起きた問題を分けるため |
エディタを閉じてプロジェクトフォルダを別の場所へコピーし、バックアップとして保管します。そのうえで、次の「Open a Copy」が作る検証用コピーを更新します。ディスクには、元データ・コピー・新しいUE・作業中の生成物が入る空きが必要です。
Savedをまとめて消さない
Saved にはログのほか、自動保存やゲームのセーブ データが入ることがあります。フォルダをUEが作り直せても、中にあったデータまで戻るわけではありません。 更新前の決まりとして削除する必要はありません。
Intermediate はビルド途中のデータ、DerivedDataCache は再利用する変換済みデータです。問題の調査で作り直すことはありますが、まずは削除せずに進めます。Gitから除外することと、手元から消してよいことも別です（→ 初期設定と保存対象）。
コピーを新しいUEで開く
Epic Games Launcherの「Unreal Engine → Library」から、移行先のUEを追加インストールします。古い版は残したままで構いません。C++やコードを含むプラグインを使う場合は、移行先に対応する開発ツールも用意します。
ここではUEにコピーを作ってもらう Open a Copy を使います。
- Launcherで、移行先のバージョンのUEを起動します。
- Project Browserで元のプロジェクトを選びます。一覧にない場合は「Browse」から
.uprojectを指定します。 - 別バージョンのプロジェクトを開く確認画面で「Open a Copy」を選びます。
- コピーの作成と変換を待ちます。開いたら、作業しているプロジェクトの保存先が元とは別であることを確認します。Launcherのプロジェクト一覧で右クリックし、「Show in folder」からフォルダを開くと、場所を確かめられます。
「Convert in-place」は元のプロジェクトをその場所で変換する選択肢です。今回の手順ではOpen a Copyを選びます。既存プロジェクトが自動で開いてしまう設定なら、「File → Open Project」から選び直します。
初回はシェーダーなどの準備に時間がかかる場合があります。進行状況やログを見ながら待ち、変換に失敗した場合は表示されたエラーを残します。
手動で作ったコピーを切り替える方法
Windowsでは、コピーした側の .uproject を右クリックし、「Switch Unreal Engine Version」でインストール済みのUEを選ぶ方法もあります。これは、そのプロジェクトを どのUEで開くかの指定 です。コピーの作成や動作確認まで自動で済ませる機能ではありません。
また、更新したアセットの形式を古い形式へ戻す機能でもありません。古いUEへ指定を戻すだけでは、更新を取り消せません。 戻る場合は、保管した更新前のデータを古いUEで開きます。
開けたら、以前の動作と比べる
まずログとBlueprintを確認し、その後に実際の操作へ進みます。コンパイルが通る とは、処理を実行できる形へ組み立てられたということです。「ゲームのルールが以前どおりか」までは保証しません。
- 「Output Log」でErrorとWarningを確認します。絞り込みで気になる項目を見つけたら、周囲の通常ログも戻して前後を読みます。
- 必要なプラグインが利用できるか、クラスやアセットが見つからない警告がないかを確認します。
- 自作の主要なBlueprintを開き、それぞれの「Compile」でエラーと警告を調べます。問題が出たものはメッセージの指す箇所から直します。
- 使うレベルを開き、Playで入力・当たり判定・画面遷移・音などを試します。更新前のメモと比べます。
- 自動テストがあれば実行し、パッケージ版も作って操作します。
警告が出たらすべて無視するのでも、件数だけをゼロにするのでもなく、何に影響するかを確認します。更新前にも出ていたものかを比べると、調べる範囲を絞れます。
見た目は同じ場所・同じカメラ・同じ画質設定で比べます。明るさが変わった場合も、設定を一度に戻す前に、照明、マテリアル、描画設定のどこで差が出たかを見ます。
問題が出たときの調べ方
| 症状 | 調べる手がかり | 次にすること |
|---|---|---|
| 起動や変換が止まる | 変換時のエラー、コピー内のSaved/Logs、Crash Reporter | 名前が出たプラグイン・ファイル・開発ツールを確認 |
| BlueprintがCompileに失敗する | そのBlueprintのCompiler Results | 失われた関数、型、親クラス、ピンの接続を確認 |
| Deprecatedと出る | 警告文と移行先の変更点 | 推奨される置き換えを調べ、変更後の動作を確認 |
| C++をビルドできない | 最初の具体的なコンパイルエラー | 対応コンパイラ・SDK、関数名や引数の変更を確認 |
| エディタでは動くが配布物で動かない | パッケージ時と実行時のログ | 収録マップ、アセット、プラグインの実行時対応を確認 |
Deprecated（非推奨） は、「今後は別の方法へ移してほしい」という案内です。まだ動くものもあり、「赤いノードはすべて非推奨」という意味ではありません。必要なプラグインや親クラスが見つからなくてもCompileは失敗します。
プラグイン不足の状態で開けた場合も、すぐに全アセットを保存し直さないようにします。先に依存する部品を揃え、正しく読み込める状態へ戻します。切り分けのために機能を無効にする場合は、さらに分けた検証用コピーで試します。
キャッシュを作り直すのは、ログや既知の不具合から、その必要があると分かった段階です。エディタを閉じ、再生成できる対象を確かめて退避します。ソースのないプラグインの Binaries など、消すと自分では作り直せないデータもあります。
解決に時間がかかるなら、検証用コピーとログを残し、元のプロジェクトを古いUEで開いて制作を再開し ます。失敗したコピーを消すことが復旧の条件ではありません（→ ログの読み方）。
実践：小さなプロジェクトで更新を一周する
初めてなら、制作本体の前に小さなThird Personプロジェクトで試してみましょう。目的は 不具合を起こすことではなく、更新前後で同じ結果を確認できること です。
① 比べるための目印を作る
現在のUEでBlueprintのThird Personテンプレートを作り、UpgradePractice と名付けます。Variantを選べる場合は基本の「None」を使います。
- テンプレートの床やPlayer Startを残し、キャラクターの前にCubeを1つ追加します。
- 「Blueprint Class → Actor」で
BP_UpgradeCheckを作ります。Actorはレベルへ配置できるものの基本クラスです。 - Event Graphで
Event BeginPlayの白い実行ピンからPrint Stringへつなぎ、In StringをUPGRADE CHECK OK、Durationを10.0にします。 - Compileして保存し、
BP_UpgradeCheckをレベルへ1つ配置します。見た目の部品は不要です。 - Playし、開始直後に文字が出ること、Cubeが見えること、WASDで移動してSpaceでジャンプできることを確認します。
BeginPlayはゲーム開始時などに呼ばれるイベントです。今回のActorがレベルにあり、その処理も呼ばれていることを文字で確認します。Print StringのDurationが見えなければ、ノード下部の展開ボタンで詳細を表示します。Print to Screenはオンにしておきます。
画面を1枚残してからPlayを止め、Save Allで保存します。
② コピーを更新し、同じことを試す
エディタを閉じてバックアップを作り、前半のOpen a Copyの手順で新しいUEへ移します。元とコピーのフォルダ、使用するUEの版をメモしておきます。
コピーが開いたらログを確認し、BP_UpgradeCheck とテンプレートのキャラクターBlueprintをCompileします。そのうえで同じレベルをPlayし、次を比較します。
| 確認すること | 更新前 | 更新後に期待する結果 |
|---|---|---|
| 開始時の文字 | UPGRADE CHECK OK | 同じ文字が出る |
| 目印のCube | 置いた位置に見える | 同じ位置に見 える |
| WASD・Space | 移動・ジャンプできる | 同じ操作ができる |
問題なく揃えば、小さなプロジェクトの更新と比較はできています。自分のゲームでは、この表に「敵へ20ダメージでHPが100→80」「結果から再挑戦できる」などの確認を足していきます（→ 自動テスト入門）。
③ パッケージ版と戻り先を確認する
コピーをDevelopmentでパッケージ化し、エディタの外でも文字・Cube・移動・ジャンプを確認します。起動マップには、この練習を置いたレベルを指定します。配布する場合はShippingも作り、移動などの操作を再確認します。Print StringはShippingの確認用表示には使いません（→ パッケージ化の手順）。
最後にコピーを閉じ、古いUEで 元のプロジェクト を開いてみます。同じ練習が動けば、戻り先も確認できました。更新がうまくいった後は、どちらを制作の続きに使うか決め、両方へ別々に変更を加えて混乱しないようにします。
おまけ：少し離れたバージョンへ移すとき
1つずつ上げる必要はある？
必ずすべての版を経由するわけではありません。まず移行先の互換性と、間に入る版の重要な変更を調べ、コピーで試します。大きく離れた版への移行で原因を絞れないときは、中間の版でも確認すると、どこで差が生まれたかを調べやすくなります。
UE4からUE5のように大きな変更をまたぐ場合は、通常の更新手順に加えて公式の移行ガイドを確認します。物理や描画など、データの変換だけでは同じ動作にならない機能もあります。
新しい版の変更を、古い版へ戻したくなったら
コピーで追加した作業は、元のプロジェクトへ自動では戻りません。更新済みアセットを古いUEへそのまま持ち込める前提にせず、変更内容を記録して、古い版で作り直せる範囲を判断します。更新の確認中は、新機能の実装を大量に進める前に採用する版を決めると整理しやすくなります。
エンジンをソースからビルドしている場合は、エンジン側の変更やビルド環境も移行対象です。この記事のLauncher版の操作に加え、その開発環境に合った手順を用意します。
まとめ
更新する理由と必要なプラグインを確認し、元のデータと古いUEを残してからコピーで試します。開けた後はログとCompileだけで終えず、以前と同じ操作、見た目、パッケージ版を比べます。
小さな練習で「新しい版でも動く」と「元の版へ戻って続けられる」の両方を確認できれば、制作中のゲームでも同じ順番で試せます。