If you've followed this blog from the start — project setup, Blueprint errors, input, saves, performance — you've now got a project that runs great inside the editor. Packaging it feels like it should be one button. It is one button. It's just that the button does five separate things, and any one of them can fail silently.

The three failures almost everyone hits on their first build: a black screen on launch, a cook that dies partway through with a cryptic path error, or a finished .exe that's ten times bigger than it should be. None of these are engine bugs. They're all fixable in the settings you already have open.

Development, Shipping, and what actually changes

Development and Shipping aren't just labels — they change real behavior:

  • Shipping strips debug tooling. Console commands, stat overlays, and most UE_LOG output are compiled out. Print String nodes are skipped too, but only if their Development Only checkbox is on — which is the default, but worth knowing about.
  • Shipping is harder to reverse-engineer. Blueprint-heavy projects are more exposed here than C++-heavy ones, since Blueprint bytecode is easier to pull apart. Pak encryption (Project Settings → Packaging → "Use Pak File") closes most of that gap.
  • Shipping runs faster. No debug checks, no editor-only code paths, optimized compiler flags.

For your first playtest build, package Development — you'll want the logs. Switch to Shipping only once the game actually runs end to end, because Shipping errors are much harder to debug (the crash log that would tell you why is one of the things that got stripped).

The black screen on launch

The single most common "why is my package broken" question. The editor opens whatever level you were last looking at. A packaged build has no such memory — it needs to be told explicitly.

Fix it in Project Settings → Maps & Modes:

  • Game Default Map — the level that loads on startup.
  • Editor Startup Map — separate setting, only affects the editor. Don't confuse the two.

If both are set and you still get black, check the level's own World Settings → GameMode Override — an empty or misconfigured GameMode here will load the map but spawn nothing into it.

Cook errors: read the actual path

"Failed to cook" is the error, but the interesting text is above it — the specific asset and the specific reason. Three causes make up most of what you'll see:

  • Spaces or non-ASCII characters in the project path. C:\Users\Max Müller\My Game\ can break the cook process partway through. Move the project to a plain path (C:\Projects\MyGame\) before packaging.
  • File name too long. Windows has an absolute path limit, and deeply nested Content folders plus long asset names can hit it. Shorten folder structure rather than fighting the OS setting.
  • Deprecated or moved classes. An old GameMode or Blueprint got renamed or deleted, but something still references its old path. Search for the asset name in Reference Viewer and fix or remove the dangling reference.

Read the log top to bottom — the first cook error is usually the real one, and every error after it is often just a symptom of the first.

Trimming a bloated build

An empty UE5 project already packages to roughly 320 MB — that's the engine floor, not something you did wrong. What you can control is everything on top of it. It's common for a mid-size beginner project to build out at 8-15 GB when the actual game content is closer to 1-2 GB. That gap is almost always one of these:

  • Unused plugins still enabled. Every enabled plugin gets cooked whether you use it or not. Project Settings → Plugins → disable anything you're not actively using.
  • Marketplace/Fab megapacks, mostly unused. You imported a 4 GB environment pack for one rock formation. Only referenced assets get cooked — but "referenced" includes anything still pulled in by a level, a Blueprint, or a DataTable you forgot about.
  • Uncompressed source textures. 4K textures you're previewing at 256px in-game still cook at full resolution unless you set a max size in the texture's LOD settings.

Two tools to find the actual culprits: Window → Developer Tools → Size Map shows what's pulling in what, sorted by disk size — usually the fastest way to spot the one asset dragging in 2 GB of dependencies. Reference Viewer on a specific asset shows exactly what still points to it, which tells you whether it's safe to delete.

Only cook what you reference

By default, Unreal cooks everything reachable from your maps and your Primary Asset rules, not your entire Content folder — but "reachable" is broader than most people expect. A test level you forgot to delete, still referencing a debug prop library, will drag that whole library into the build. Before your first real Shipping package, delete or exclude test levels, debug-only Blueprints, and anything under a _Sandbox or Test folder you've been using to try things out.

Testing the result

Never assume the package works because it built without errors. Run the actual .exe standalone, not through the editor:

  • Check it launches to the right map with no black screen.
  • Play through your core loop once — save/load, main menu, whatever the player actually touches first.
  • Check the log folder (Saved/Logs/ inside the packaged build) for warnings that got silently swallowed in PIE but show up here.

If it works standalone but the file size still looks wrong, that's a Size Map problem, not a cook problem — go back to the previous section.

Common pitfalls

  • Packaging Shipping on the first attempt. You lose the debug log exactly when you need it most. Development first, Shipping once it's proven.
  • Trusting "no errors" as "it works". A cook can finish clean and still produce a black screen — that's a Maps & Modes problem, not a cook problem, and the cook step doesn't check for it.
  • Leaving every plugin enabled "just in case". Each one adds cook time and build size for zero benefit if unused.
  • Testing only in PIE. Play-in-Editor uses editor-only code paths and doesn't catch packaging-specific failures. Always run the standalone build before calling it done.
  • Ignoring the first cook error and scrolling to the last one. The last error in the log is frequently a downstream symptom, not the cause.

30-second recap

  • Package Development first for the logs; move to Shipping once the build actually runs.
  • Black screen = Maps & Modes → Game Default Map, not a cook bug.
  • Cook errors: check for spaces/non-ASCII in the path and overly long file names first.
  • An empty project is ~320 MB baseline — anything way past that is unused plugins or unreferenced megapacks.
  • Size Map and Reference Viewer tell you exactly what's bloating the build.
  • Always test the standalone .exe, never just PIE.

That's the full beginner journey from empty project to a build you can hand to someone else — setup, Blueprint patterns, game systems, world building, performance, and now shipping. Next up: a look at what actually changed in the latest Unreal Engine release and which of it is worth your time as a beginner.

— Marco