Quick Test Processes

Original write-up by Sean-Li Murmann, Lead Game Programmer

First, I’d like to start with a small introduction to myself. I’m a game programmer by trait, however efficient workflows have always been something that I’ve had an interest in. I get an uncomfortable itch when I see colleagues doing repetitive tasks and always think to myself: “There must be a better way to do this!”

I’ll explain the benefits and reasoning behind why you should use an automated system and give you a quick rundown on how to set something up for your own projects. However, do mind that this is by no means a ‘final’ setup. Our workflows change frequently and yours might differ from ours.


Throughout the development cycle of a game, testing a packaged version of the game frequently is something that is completely unavoidable. Anyone who has gone through the processes of building, cooking and packaging a UE4 project knows that often the results in PIE (Play In-Editor) are different compared to a packaged version of the game. 

Unfortunately, packaging and testing can take a long time. When it comes time to produce a package for QA to test it renders a developer and his/her workstation idle for a while. The exact idle period largely depends on the scale of your project, but with the size of UNBOUND we’ve seen times of upwards of an hour, especially if assets have never been cooked on that machine before. This gets especially bad when we need to rapidly fix bugs for a playtest.


Fortunately, continuous integration and deployment software exists. There are many to pick from out there, but I was most comfortable with learning Jenkins (https://jenkins.io/). It has many different plugins that I found to be useful and with a little bit of command line work, you can automate almost anything.


The least intrusive way for me to setup a job in Jenkins is to poll for changes on SVN every minute. When a developer, artist or any other person working on the project submits to our source control, Jenkins will see that submit and queue a package to be built. The server will build the package and rename some folders to keep track of the revision this package represents and dump it on our shared filed server where QA will be able to extract and test the package. Do mind that you might want to consider trashing packages that you don’t need from time to time as keeping about 20 packaged versions of your game every day might be a huge load on your storage solution.

Apart from packaging we also automatically build the projects binary files. When a programmer submits code, Jenkins is responsible for building and submitting an updated version of the projects binary files to SVN for our artists to pull. This way artists who do not have access to Visual Studio licence will always be able to open the latest version of the project.


If you haven’t already jumped the gun an installed Jenkins, on preferably an idle machine, you can do that now. Download link here: https://jenkins.io/download/ Once you have that setup, you’ll be ready to create a new job.

Jobs are what Jenkins considers an automated task. A job may have many different tasks that are to be executed each time it runs. In our case we want to create a job that takes a UE4 project, packages it and zips it into a location. 

We start out by giving our job a name and selecting the freestyle project.

Next up we setup our source code management. We use Subversion, but you may setup with whichever SCM you use. Do note that if you do not see your SCM provider, you’ll have to check the plugin section and install a plugin that’ll help you with that. 

Depending on what SCM you use, you may have to setup your build triggers differently. I just poll for each minute using cron.


Next up and finally just add a build step. We’ll use a ‘Execute Windows batch command’ build step. And we’ll just use Epic’s RunUAT.bat command to do the packaging for us:

"%PathToYourEngineDir%\Build\BatchFiles\RunUAT.bat" BuildCookRun -project="%DirectoryToYourProject%\YourGameProject.uproject" -noP4 -platform=Win64 -allmaps -build -clientconfig=Development -serverconfig=Development -cook -stage -archive -pak -archivedirectory="%DirectoryToArchiveProjectIn%"

That should be enough to just have the package being built and archived somewhere. There’s a lot more you can do with this such as zipping up the project, renaming it by revision name and etc.