Chapter 10. Packaging and Distribution
Now that you have a Level and the associated Pawn, Player Controller, and Game Modes to walk around it with, it’s time to prepare it to run as a standalone application. This is referred to broadly as packaging. After it is packaged, you will be able to share your application like any other installable application. This chapter walks you through the process of packaging the application.
Packaged Versus Editor Builds
When you run your application using the Play In Editor button, you’re actually just running another window in the Editor, not a standalone application. The Editor uses the Assets and maps from your Content folder and what’s been loaded into RAM already to populate the world, and the Editor code runs the simulation. This makes it very fast to launch, test, and iterate, but it requires the entire UE4 Editor to be installed.
This is obviously not how you want to hand an application over to your clients or the public.
To create a standalone application for the platform you are developing for that can be distributed easily, your content must be packaged. Packaging processes your content and creates a standalone application that is easy to distribute like any other game or app.
You can also choose to test your application in Standalone Mode by selecting that option from the Play in Editor option menu in the toolbar. This will launch the currently loaded level in a separate process that is more similar to a packaged build but is not. It’s important to build and test your applications—bugs and inconsistencies can appear between editor and packaged builds.
Project Packaging
In broad terms, packaging takes your content and game code, optimizes it, and creates an executable application for the platform you’ve selected.
Packaged builds attempt to load as little as possible into RAM. This is to ensure maximum performance and compatibility. However, it can introduce issues, especially with Level streaming and loading Assets at runtime. For simple projects this isn’t an issue, but larger projects should test using a packaged build regularly to avoid this issue.
Content Cooking
Cooking also goes through the process of compiling all your shaders, compressing all your Texture maps, and fixing up any redirectors in the project. This avoids your Players’ needing to wait for the application to load while it does this.
This can take some time and is very CPU and RAM intensive. Cook your project on a beefy machine. The more Assets, Materials, and Textures your project has, the longer this will take.
Cooking then takes all the Assets and Classes that have been processed and copies them to a .pak file. This .pak file is designed to be read very quickly by even the slowest of drives allowing your application to load quickly.
Deployment
Packaging takes the cooked content and pairs it with the binary Engine files and places them together into a single folder for distribution. This final step creates a standalone application that can be launched without the Editor being installed.
Packaging Options
UE4 can generate packaged projects for a ton of platforms and systems (iOS, Windows, Mac, and so on). With that flexibility comes some options.
Platforms
The target platform is the hardware/software combination you are trying to create a project executable for.
You can package your project for a myriad of platforms supported by UE4. From mobile devices to Windows and Mac and Linux to consoles, UE4 can package your project for nearly all the most popular devices and operating systems.
Each will have its own optimizations, input methods, and other limitations that you must consider. This book focuses only on desktop platforms (Mac and Windows).
Build Configuration
The other major decision you must make is the build configuration. The two main options are Shipping and Development.
The biggest difference between Shipping and Development builds is access to debugging tools, logging, and the command prompt. Development builds allow these whereas Shipping builds have these features stripped out.
I generally use Development unless I plan to distribute the package to the public as a wide release. The console commands, logging, and debug info are useful if I need to debug any issues.
Shipping builds are great when you want to distribute your application to the public and you do not want them to have access to the Console.
How to Package
You can package your project most easily through the Editor. Simply select Package Project from the File menu. This menu presents a few options and provides quick access to more detailed options in the Project Settings dialog (see Figure 10.1).
Upon selecting your desired platform, you are prompted for a location to save your packaged project. Don’t put the packaged project into your project folder—it can lead to confusion.
Packaging takes some time. A small notice appears letting you know that packaging is underway (see Figure 10.2). This process is fully threaded so you can continue to work on your project while it processes your content in the background.
Launching Your Application
After packaging completes, the Editor alerts you (see Figure 10.3).
Proceed to the directory you defined earlier and look for a folder called WindowsNoEditor (this might be different on another platform). You can rename this folder.
Inside the folder, you will find an executable file and some folders containing all your data and Classes along with a lightweight, binary version of the engine (see Figure 10.4).
You can launch your application simply by double-clicking the executable file. Your application should launch, load the Level you built, and spawn the proper Player Controller and Pawn giving you mouse access.
Packaging Errors
Sometimes, packaging encounters an error. A simple Blueprint compiling error or running out of disk space can halt the entire Packaging process.
When this happens, you should turn to the Output Log window, which can offer helpful information in most cases.
To access the Output Log window, in the Editor, go to Window > Developer Tools > Output Log (see Figure 10.5). I generally dock this window with my Content Browser for easy access.
Distributing the Project
You can now copy, zip, and send this folder to whomever you like. It’s really that simple (mostly).
Of course, you still have platform issues and hardware compatibility, but that’s par for the course for any application.
Some computers that try to run your application might be missing some system components that UE4 requires. These are referred to as Prerequisites. By default, these files are included in your packaged project. If your packaged UE4 project detects that they are not installed, it will prompt the user to install them when they try to run the executable.
Other than the prerequisites, a packaged UE4 application does not require any sort of formal installation process; it can be run from any location.
Using Installers
UE4 does not have any installer packager built in. Developing or using an installer for your application and for the platform you are developing for is up to you. However, because UE4 doesn’t require a formal installation, providing the project files in a zip file with simple instructions is usually adequate.
Of course, if you want to set up desktop shortcuts, register for uninstalling, and all the other things a full installer does, you’ll need to develop an installer.
Although these tasks are outside the scope of this text, they are fairly straightforward to accomplish using one of the many free and commercial installer authoring applications.
Summary
Now that you’ve built your first application from the ground up in UE4, you should feel accomplished. Congratulations!
The following chapters explore a more traditional-style visualization by looking at the data pipeline and some of the most important systems for visualizations: Lightmass, Sequencer, and Blueprints in specific.