エディタのPlayではキャラクターが動き、ジャンプもできる。友達にも遊んでほしいけれど、相手のPCにはUnreal Engineが入っていない。ここで必要になるのが、ゲームを配布できる形へまとめる パッケージ化 です。
Windows向けなら、起動用の .exe と、ゲームに必要なデータが出力されます。エディタで開いているプロジェクトとは別の成果物なので、書き出したゲームを起動して確かめる ところまでが作業です。
この記事ではThird Personテンプレートを使い、手元で動くパッケージを作ってから、フォルダごとZIPにします。完成を待たず、小さな試作のうちに一度通しておくと、配布直前の準備を減らせます。
この記事でわかること
- パッケージ化の中で行うBuild・Cook・Stage・Packageの役割
- 起動するマップと、ゲームに含めるマップの設定
- Developmentで確認し、Shippingを作る手順
- 配布するフォルダと、失敗したときの調べ方
パッケージ化の中では何をする？
メニューでは「Package Project」を1回選びますが、中ではいくつかの工程が進みます。
| 工程 | 役割 |
|---|---|
| Build | 必要なコードを、対象のOSで実行できるプログラムへ変換する |
| Cook | マップ、画像、音声などを、対象の環境で使えるデータへ変換する |
| Stage | 実行ファイルと変換済みデータを、出力用の場所へ集める |
| Package | 集めたファイルを、配布できるまとまりにする |
コードを実行できる形に変換する作業は コンパイル とも呼びます。Cookは同じ「変換」でも、アセット側の準備です。たとえばWindows用とスマートフォン用では、画像や描画の扱いが異なるため、使う環境に合わせます。
初回はコードやシェーダーの準備、Cookなどに時間がかかります。2回目以降に再利用できるデータもありますが、変更内容や設定によって所要時間は変わります。待ち時間の長さだけで失敗と決めず、進捗やログを見ます。
開発側に必要なツール
WindowsでC++コードやプラグインのコンパイルが必要な場合は、対応するコンパイラと Windows SDK が必要です。SDKは、そのOS向けにプログラムを作るための道具一式です。
Visual Studioを使うなら、Installerで「C++によるゲーム開発」と必要なSDKを追加します。対応版はUEのバージョンで異なるため、Epic公式の対応表で、自分のUEの行を確認してください。
Launcher版UEのBlueprintテンプレートでは、追加のC++開発環境なしで進められる構成もあります。プラグインも、コンパイルが必要か、ビルド済みのものを使えるかで条件が変わります。「プラグインを入れたら必ずVisual Studioが必要」と一律には決まりません。
起動するマップと、収録するマップ
パッケージ版は、エディタで最後に開いていたレベルを見て起動するわけではありません。最初にどのマップを開く かを、設定で決めます。
Game Default Mapを確認する
「Edit → Project Settings → Maps & Modes」を開きます。
| 項目 | いつ使うか |
|---|---|
| Editor Startup Map | エディタを起動したときに開くマップ |
| Game Default Map | ゲームを起動したときに、標準で開くマップ |
タイトルから始めるならタイトル用レベル、すぐ遊ばせるなら最初のステージをGame Default Mapへ指定します。テンプレートでは設定済みの場合もありますが、自分が起動させたい相手かを確認します。
未設定や意図しないレベルの指定は、黒い画面になる原因の1つです。ただし、正しいマップでもカメラやプレイヤーが用意されていなければ、期待した映像にはなりません。設定を直しても変わらない場合は、後半の切り分けへ進みます。
必要なマップを含める
次に「Project Settings → Packaging」で「List of maps to include in a packaged build」を探し、使うマップを登録します。タイトル・ステージ・結果の3レベルを使うなら、3つとも含めます（→ レベル遷移の記事）。
Game Default Mapは 最初に開く場所、マップ一覧は ゲームへ含める場所 の指定です。この2つを分けると、「最初の画面は出たのに次のステージへ移れない」を調べやすくなります。独自のビルド手順では別のマップ指定が使われる場合もあるため、最終確認は書き出したゲームで行います。
アセットの「参照」も収録に関係する
参照 は「このマップがこのキャラクターを使う」といったつながりです。Cookはマップやコードから必要なアセットを集めますが、追加指定や除外設定も関係します。「起動マップからたどれるものだけ」と一律には決まりません。
特に注意するのは、実行中に文字列を組み立ててアセットの場所を決めるような処理です。Cookの時点で使用先が分からなければ、必要なデータが含まれないことがあります。単にBlueprintの変数へアセットを選んだだけで、参照が消えるわけではありません。
意図的にまとめて含めたいアセットは「Additional Asset Directories to Cook」でフォルダを指定できます。入らない原因を確認し、必要な範囲を足します。最初から「Cook everything」で全部を入れると、不要なデータも増えやすくなります（→ アセットと参照の整理）。
DevelopmentとShippingの使い分け
Build Configuration は、どの最適化や調査機能を含めてプログラムを 作るかの設定です。最初は次の2つを使い分けます。
| 設定 | 向いている段階 | 確認するときの違い |
|---|---|---|
| Development | 開発中の動作確認 | ログやコンソール、デバッグ表示を使って調べやすい |
| Shipping | 最終的な配布 | 最適化を有効にし、通常はコンソールや多くの調査機能を外す |
コンソールは、ゲームの実行中に命令を入力する欄です。Print Stringやデバッグ用の線も開発中の確認に役立ちますが、Shippingでプレイヤーへ見せる表示は、文字やボタンを作るUMGなどで用意します（→ UMG入門）。
Shippingのログ出力を別途設計することもできますが、通常の設定ではDevelopmentと同じ手がかりを期待できません。まずDevelopmentで不具合を調べ、その後Shippingを作り、配布する版でも同じ操作を確認 します。
容量や速度の差はプロジェクトと設定によります。「何MB小さくなれば成功」という判断にはしません。
実践：テンプレートをWindows向けに書き出す
Third Personテンプレートで、キャラクターを歩かせ、ジャンプさせ られるWindows用パッケージを作ります。ここではプロジェクト名を PackTest とします。
① 練習用レベルを用意する
- 「Games → Third Person」でBlueprintプロジェクトを作ります。Variantを選べる場合は基本の「None」を使い、追加のStarter Contentは不要です。
- テンプレートのレベルでPlayし、移動とジャンプを確認します。
- Playを止め、「File → Save Current Level As」で
Content/Maps/L_PackPracticeとして別名保存します。テンプレートの床・Player Start・GameModeの設定は引き継ぎます。 - プレイヤーの正面付近へ目印のCubeを1つ置き、「Save All」します。
保存先は D:\UE\PackTest のように短く分かりやすい場所にすると、ログに出るパスも追いやすくなります。
② マップとビルド構成を設定する
「Project Settings」で次を設定します。
| 場所 | 項目 | 今回の値 |
|---|---|---|
| Maps & Modes | Game Default Map | L_PackPractice |
| Maps & Modes | Editor Startup Map | L_PackPractice（練習で開きやすくするため） |
| Packaging | List of maps to include in a packaged build | L_PackPractice を追加 |
| Packaging | Build Configuration | Development |
| Packaging | Include Prerequisites Installer | オン。配布時に同梱内容も確認する |
Prerequisites は、ゲームを実行するために必要な共通部品です。開発用のVisual Studioとは別で、遊ぶ人のPCにも実行用部品が必要な場合があります。
③ Package Projectを実行する
- ツールバーの「Platforms → Windows」を開きます。
- ビルド構成の欄で「Use Project Setting (Development)」、または明示的な「Development」が選ばれていることを確認します。
- 「Package Project」を選びます。
- プロジェクトの外にある
D:\UEBuilds\PackTest\Developmentなどを出力先にします。
項目名や並びはUEの版によって多少変わります。「プロジェクト設定を使う」のか、メニュー側で構成を上書きしているのかも見ておきます。
右下の通知で進捗を確認できます。失敗した場合は「Show Output Log」を開きます。完了するまでは、出力先にexeが見えていても完成とは扱いません。
④ エディタの外で遊ぶ
完了した出力先を開き、Windows フォルダなどの中にある PackTest.exe を起動します。フォルダ名は構成によって変わる場合があります。
L_PackPracticeが開き、置いたCubeが見える。- ゲーム画面へ入力を向けると、WASDで移動し、Spaceでジャンプできる。
Alt + F4で終了できる。
この3つを確認できれば、エディタのPlayとは別に動くゲームができています。ウィンドウかフルスクリーンかは設定次第なので、表示形式だけで成否を判断しません。
小さな実験として、エディタでCubeを別の場所へ動かして保存し、古いexeをもう一度起動してみましょう。 書き出し直すまでは、配布物のCubeは元の位置のままです。同じDevelopment設定でもう一度パッケージ化し、移動後の位置へ変われば、「プロジェクトの保存」と「配布物の更新」が別の作業だと確かめられます。
⑤ Shippingも起動して確かめる
Build ConfigurationをShippingへ変え、PlatformsメニューでもShippingが選ばれていることを確認します。今度は D:\UEBuilds\PackTest\Shipping など、Developmentと別の出力先へパッケージ化します。
Shipping版のexeでも、Cube・移動・ジャンプ・終了を確認します。 自分のゲームなら、タイトルから開始し、結果へ進み、再挑戦する一周も試します。Print Stringが表示されないことと、ゲームの処理が動かないことを混同しないようにします。
配布するのはフォルダ全体
通常のWindows向け出力は、次のようなまとまりになります。実際のフォルダ名やファイル数は設定によって変わります。
Windows/
├─ PackTest.exe 起動用
├─ Engine/ エンジン側の実行用ファイル
└─ PackTest/
├─ Binaries/ ゲームの実行ファイルなど
└─ Content/
└─ Paks/ .pak、.utoc、.ucasなど
.pak はデータをまとめる入れ物です。「Use Io Store」を使う構成では .utoc や .ucas も並びます。役割の違いを覚えるより、まずは 出力されたまとまりを崩さず扱う ことが大切です。
起動用exeだけを抜き出しても、必要なデータが足りません。Windowsフォルダ全体をZIPにし、受け取った人には全体を展開してからexeを開いてもらいます。 ZIPの中からexeだけを直接実行しないよう、操作説明も添えます。
UEが入っていないPCでも試す
ゲームを遊ぶためにUEエディタは不要ですが、対応するWindows・GPU・実行用部品は必要です。自分の開発PCには揃っていても、相手のPCにはない場合があります。
「Include Prerequisites Installer」を有効にしたら、実際の出力に必要部品のインストーラが含まれているか確認します。相手側で不足を示すメッセージが出た場合は、その内容に応じて同梱インストーラなどから導入します。設定のチェックだけで、相手へのインストールまで完了するわけではありません。
最後に、ZIPを別フォルダへ展開して起動し、可能ならUEを入れていない別PCでも試します。配 布物に「起動するexe」「移動・ジャンプ・終了の操作」を短く添えれば、初めて受け取る人も迷いにくくなります。
失敗したら、どこを見る？
最初に、書き出しが失敗したのか、書き出せたゲームの動作がおかしいのか を分けます。見るログが違うためです。
パッケージ化が途中で止まった
- 「Message Log」の「Packaging Results」で、エラーになった項目を確認します。
- 「Show Output Log」などから詳細を開き、エラーの前後を読みます。
- 後から読み返す場合は、元のプロジェクトの
Saved/Logs/や、Output Logに案内されたビルド用ログを開きます。
末尾の Unknown Error は「処理が失敗した」というまとめで、それ自体が原因ではありません。その前にあるSDK名、Blueprint名、見つからないファイルのパスなどを探します。検索するときも、その具体的な名前とUEのバージョンを使います。
| ログに出る手がかり | 最初に確認するもの |
|---|---|
| SDKやコンパイラが見つからない | 使用UEに対応する開発ツールとSDK |
| BlueprintのCompileエラー | 指定されたBlueprintを開いてCompileし、エラー箇所を修正 |
| アセットが見 つからない | 移動・削除後の参照、指定パス、必要なプラグイン |
| 書き込みやファイル保存に失敗 | 空き容量、出力先、アクセス権、ログに出たパス |
パッケージ化は完了したが、遊べない
まずDevelopment版で再現を確認します。
| 症状 | 最初に確認するもの |
|---|---|
| 真っ暗 | Game Default Mapと収録。正しければカメラ・プレイヤー生成・照明 |
| 画面は見えるが操作できない | ゲームへ入力が届いているか、GameModeや入力設定 |
| 別のレベルへ進めない | 移動先の指定と、使うマップが含まれているか |
| 音やオブジェクトの一部がない | 読み込みエラー、参照とCook設定。音量や表示条件も確認 |
| 起動直後に終了する | 実行時ログ、不足部品のメッセージ、対象PCの対応環境 |
| Print Stringだけ出ない | Shippingかどうか。製品UIの表示は別途用意する |
実行時のログは、作成元プロジェクトのエディタログと区別します。Windowsでは、パッケージ内の PackTest/Saved/Logs/ や %LOCALAPPDATA%\PackTest\Saved\Logs\ などを確認します。出力先はビルド構成や実行方法によって変わります。
場所が分からない場合は、Development版のexeがあるフォルダでPowerShellを開き、次のように保存先を指定して起動できます。
.\PackTest.exe -log "-ABSLOG=D:\UEBuilds\PackTest\PackTest-run.log"
指定するフォルダは先に作り、自分が書き込める場所へ置き換えてください。これは実行時のログの指定で、Shippingで無効なログ機能を有効にするものではありません。ログ機能の準備より前に停止した場合は、ファイルができないこともあります（→ Print Stringとログの使い方）。
おまけ：配布前に整えること
名前・アイコン・終了方法
ウィンドウに出す名前は「Project Settings → Description」の「Project Displayed Title」、Windowsのアイコンは「Platforms → Windows」の「Game Icon」で設定できます。今回の練習はAlt＋F4で終えますが、製品では終了ボタンやメニューも用意します。
出力先と作り直しの設定
プロジェクトと配布物は別フォルダへ置くと、元データと完成物を取り違えにくくなります。配布物を開発履歴へ誤って追加することも避けられます（→ Git管理の記事）。
「Full Rebuild」はコードのビルドを全体からやり直す設定です。Cook済みデータや出力先の全ファイルを片付ける万能な修復ボタンではありません。失敗したら先にログで工程と原因を調べ、必要な作り直しを選びます。
ゲームの一周と、配布先での確認
起動だけでなく、終了・再起動・再挑戦まで試します。自動テストがあるならパッケージ前にも実行し、書き出したゲームの操作確認と組み合わせます（→ 自動テスト入門）。
UEやプラグインを更新したときも、パッケージまで通して確認します。更新手順は バージョンアップの記事 で扱います。ストアへ公開する場合は、その配布先の登録・アップロード手順も別途必要です。
まとめ
最初に開くマップを決め、必要なマップとアセットを含めてWindows向けに書き出します。Developmentで調べ、Shippingでも操作を確認してから、出力フォルダ全体をZIPにします。
エディタの外でキャラクターが動いたら、次は受け取る人の環境で確かめます。「自分のPCで作れた」から「相手が遊べる」までつながれば、配布の最初の一歩は完了です。