What "Cooking" and "Packaging" Actually Mean in Unreal Engine 5

From "it works on my machine" to "my friend can play it"

Up to now you've pressed Play and your game has run inside the editor. That's brilliant for building and testing, but you can't email someone the whole Unreal Engine and your project folder and expect them to play it. To share your game you have to turn it into a standalone app — a folder with an .exe (on Windows) that runs on its own.

Getting there involves two words that sound technical but really aren't: cooking and packaging. This lesson is pure concepts — no buttons to press yet. Once you understand what these two steps do and why your packaged game can behave a little differently from the editor, the actual packaging lesson that follows will feel obvious instead of mysterious.

Think of it like cooking a meal for guests. In the editor you've been tasting raw ingredients as you go. Cooking and packaging is plating up a finished dish someone else can eat without your kitchen.

Cooking: translating your assets into the platform's language

Inside the editor your assets live in a flexible, editable form. A texture, for example, is stored so you can keep tweaking it. But a graphics card on a player's PC doesn't want your editable texture — it wants a compressed format it can load fast. "Cooking" is Unreal converting every asset your game uses into the optimised format for the platform you're shipping to (Windows, a console, etc.).

Cooking does a few jobs at once: it converts assets to platform-ready formats, strips out editor-only data the final game never needs, and compiles the shaders for that platform so they don't have to be built on the player's machine the way they were the first time you opened your project. The result is leaner, faster-loading data.

Crucially, cooking only includes the assets your game actually references. An unused test mesh sitting in your Content folder normally won't be cooked into the build — which is great for size, but also a classic source of "it was there in the editor and now it's missing" surprises.

Packaging: bundling it all into something you can hand over

If cooking prepares the ingredients, packaging plates the meal. Packaging takes your cooked content, adds the engine runtime (the slimmed-down engine code needed to actually run the game, minus all the editor tooling), and wraps it up with an executable into a single, self-contained build.

What you get out the other end is a folder you can zip up and share. On Windows that's typically a folder containing a .exe to launch the game plus supporting content and data files. The person who downloads it doesn't need Unreal Engine, the editor, or your project — they just run the .exe.

Packaging is what triggers cooking under the hood, so in practice you press one 'Package' command and Unreal cooks and bundles in one go.

Walk through what happens when you hit "Package"

You won't click anything in this lesson — instead, read each stage so the next lesson's button-pressing makes sense. This is the mental model of the whole pipeline, in order.

1. ✓
   1You choose a target and a configuration

   You tell Unreal the platform (e.g. Windows) and the build configuration (Development while testing, Shipping for release). Everything downstream depends on these two choices.

   TipIf you're not sure, choose Development. You can always repackage as Shipping later once it works.

2. ✓
   2Unreal works out what your game references

   Starting from your maps and their dependencies, the engine traces every asset your game actually uses. Anything nothing points at is, by default, left out — this is why an unused asset can quietly vanish from the build.

   TipIf a level loads by name at runtime rather than by a direct reference, the engine may not realise it's needed. That's a common reason something is 'missing' only after packaging.

3. ✓
   3It cooks those assets

   Each referenced asset is converted to the platform's optimised format, editor-only data is stripped, and shaders are compiled for that platform. The first cook is slow because there's a lot to compile; later cooks reuse what hasn't changed.

   TipBe patient on the first package — a long pause on shader compilation is normal, not a hang.

4. ✓
   4It bundles the runtime and content together

   The cooked content is packaged with the engine runtime and an executable into a self-contained build folder. This is the 'plating up' step that turns ingredients into a meal.

5. ✓
   5You get a build folder you can run and share

   The output is a folder with an .exe (on Windows) and its data. Double-click the .exe to run the game with no editor in sight — and zip the folder to send it to someone else.

   TipAlways test the packaged .exe yourself before sharing it. The whole point of this lesson is that the packaged game can behave differently from the editor.

Why a packaged build doesn't behave exactly like Play-In-Editor

This is the part that trips up every beginner, so it's worth saying plainly: Play-In-Editor and a packaged build are not the same thing, and you should expect small differences.

In PIE you're running on uncooked assets, inside the editor process, with editor systems quietly helping out. A packaged build runs on cooked assets, on its own, with none of that help. So things that 'worked' in PIE only because the editor was covering for you — an asset that wasn't really referenced, a path that only resolves in the editor, an input setting that the editor handled — can behave differently or break once packaged.

Timing and performance differ too. The editor carries overhead PIE doesn't fully escape, while a Shipping build is leaner; and the editor often skips startup work like first-time shader compilation that a packaged game has to do for real. The takeaway isn't 'packaging is unreliable' — it's 'PIE is a preview, the packaged build is the truth.' Always test the real build.