Packaging & Delivering Experiences

Inside the editor you are running an uncompiled, editable version of your project: raw assets, a live editor, and hot-reloadable everything. That is wonderful for building and useless for delivering. Packaging (Unreal calls it Package Project, under Platforms in the toolbar) takes that project and produces a standalone build - a compiled, self-contained application that runs on its own, with no Unreal Engine installed on the target machine.

Two things happen. First, your C++/Blueprint logic is compiled into an executable. Second - and this is the slow part - Unreal cooks your content: it converts every asset (meshes, textures, materials, lighting data) into the optimized, platform-specific format the packaged game loads at runtime, and strips out everything the build does not reference. The result is a folder containing an .exe, a .pak file or two holding the cooked content, and the runtime files the app needs. The client double-clicks the .exe and your walkthrough launches full-screen - free camera, interactive doors, material swaps, day-night, whatever you built in Blueprints - all working, with no editor and no you.

One consequence catches people out the first time: the .exe alone is not the app. The build is the whole folder - the executable plus its Engine and content sub-folders and the runtime DLLs beside it. Move or send the .exe on its own and it will not launch, because it cannot find the cooked content it needs. Always keep (and zip) the entire output folder as one unit. Cooking is also not instant - a dressed scene can take several minutes to tens of minutes to cook the first time, and re-cooks after small changes are faster because Unreal only re-processes what changed. Budget for it; do not leave the cook to the last five minutes before a client call.

The mental model: the editor is your workshop; the package is the finished object that leaves the workshop. You keep the workshop.

Unreal offers build configurations, and the two that matter to you are Development and Shipping. A Development build keeps debugging tools, the console (backtick key), on-screen stats and looser error handling - useful while you are testing the package on another machine. A Shipping build is the real deliverable: debug code stripped, the console disabled, smaller and faster, locked down so a client cannot accidentally open a stats overlay or type a command. Ship Shipping.

A handful of Project Settings shape the experience the client gets. Set the default map so the app boots straight into your scene, not an empty level. Set a game default map and a splash/loading screen so the first thing they see is branded, not a black window. Under Packaging, choose Full Rebuild off for faster re-cooks, decide whether to build for Distribution, and pick which maps to include so you are not cooking test levels into the deliverable. Set the window mode (windowed vs fullscreen) and a sensible default resolution - clients run all kinds of screens. And add a simple Exit affordance (Alt+F4 works, but a menu button is kinder), because a fullscreen app with no visible way out frustrates non-technical people fast.

Test the package on a different computer than the one you built on - ideally one without Unreal installed and without your beefy GPU. That is the only honest way to know it runs for the client, not just for you.

One more polish worth the ten minutes: put a navigation prompt on first launch. Non-gamers do not intuit that the mouse looks and WASD walks; a small Blueprint widget that fades a controls hint in for the first few seconds removes the single most common 'it doesn't work' email. Pair it with a pause/main menu (Esc) that at minimum offers Resume, a quality setting and Quit, so the client is never trapped in a fullscreen app they cannot leave. These are not cosmetic - a walkthrough the client cannot drive is a walkthrough they will judge as broken, however beautiful the render behind it.

Windows is the default and easiest target for archviz - most clients and offices run it, and a Windows package is a folder you can hand over on a USB stick, a Google Drive link or a WeTransfer. macOS is possible but has more friction: you build it from (or with tooling for) a Mac, and Apple's Gatekeeper will warn about an unsigned app unless you pay for and apply an Apple Developer signature. If a Mac deliverable matters, plan for that signing step; otherwise default to Windows and, when the client is Mac-only, consider Pixel Streaming (next lesson) instead.

Be realistic about size. A cooked archviz build is rarely small: a single well-dressed interior can land anywhere from 1-3 GB, and a large exterior with Megascans foliage, 4K textures and several rooms can reach 5-10 GB or more. Textures dominate, so trimming texture resolution where it will not be noticed is the biggest lever; excluding unused maps and cinematics helps too. Compress the folder to a .zip for transfer - it shrinks meaningfully and, just as importantly, keeps the many loose runtime files together so nothing goes missing.

Write a two-line note for the client: double-click the .exe, WASD or arrows to move, mouse to look, Esc for the menu. Non-gamers do not know the controls you take for granted. A short on-screen controls hint on first launch (a Blueprint widget) is even better.

Mind the delivery channel too. Email attachments cap out well below a multi-gigabyte build, so plan on a shared drive link or a transfer service, and give the client a plain-language heads-up about the download size and that Windows may show a 'Windows protected your PC' SmartScreen warning for an unsigned executable - reassuring them to click More info -> Run anyway avoids a panicked email. If you deliver to the same client repeatedly, a signed executable (a code-signing certificate) removes that warning and looks more professional, though it is an added cost most one-off archviz jobs skip.

The single most important delivery discipline: what you hand over is the packaged build; what you keep is the project. The .uproject, your source assets, the master materials, the Blueprints, the high-resolution textures and the level files stay with you. The client gets a cooked, compiled app - which is deliberately hard to open, edit or extract assets from. That protects your work, keeps your ability to make revisions and re-cook, and means the client cannot accidentally break the scene.

Have a versioning habit. Name builds clearly - ProjectName_v03_ClientReview_Win64.zip beats Package(2).zip - and keep a short changelog so you know which build a client is looking at when they email feedback. Keep old builds until sign-off. And back up the source project religiously (a repo or a synced drive): the build is disposable because you can always re-cook it, but the project is the thing you cannot regenerate.

There is a business dimension here too, not just a technical one. A packaged build is an asset you licensed to the client for a purpose, and being deliberate about it protects the relationship. Decide up front what the client is paying for: a review build for internal use, or a marketing build they may host publicly. Watermark or brand the loading screen with your studio, and keep the source so that revisions - the near-certain 'can we try the kitchen in walnut' a week later - are a re-cook for you and a fee conversation, not a scramble to reopen a project you did not keep. Handing over the source project instead of a build is the amateur move that gives away both your leverage and your ability to support the work.

One honest caveat: a packaged real-time app runs on the client's hardware, so a modest laptop with weak graphics may run your Lumen-lit scene poorly. Offer a quality toggle in your menu (a Blueprint that swaps scalability settings - Low/Medium/High/Epic), or provide a lighter build for weaker machines. When the client's hardware is unknown or feeble, streaming the experience from a server instead of shipping a download is the fix - which is exactly the next lesson.