Distributing UE4 editor builds to non-programmers through Perforce
After seeing the following tweet:
I figured I would share the process we’ve been using on my current project.
First, make sure you’ve got a typemap set up in Perforce. Ideally you’d have this in place before submitting any files, because it’ll automatically add them with the proper type specifiers. If you missed this step on the initial setup, you’ll have to mark some files for edit and update their types.
Here’s my standard UE4 typemap:
The first four lines are the most relevant, as they mark any exe, dll, pdb, and self files as writable on the client. You’ll need that so that programmers (or any build machines) don’t have to check out binaries just to build them locally. (But programmers should probably just mask out the binaries… more on that later).
Building + Submitting
Next, you’ll need to set up a clean workspace for building and submitting the binaries. On my project, this is handled by a build machine (we’re using Bamboo), which periodically checks if there are any new changes, and kicks off a build.
For our editor build plan, we build the following targets:
- Development Editor Win64
- Development Win64
- Development PS4
- Development Xbox One
(If you’re wondering why the editor plan builds non-editor binaries for PS4 and Xbox One, it’s so non-programmers can test their local changes on console)
Once the build is finished, running this script from the root of the project will identify any binaries that should be marked for add or edit with Perforce:
p4 reconcile ProjectName\Binaries\....dll
p4 reconcile ProjectName\Binaries\....pdb
p4 reconcile ProjectName\Binaries\....exe
p4 reconcile ProjectName\Binaries\....self
p4 reconcile ProjectName\Binaries\....target
p4 reconcile ProjectName\Plugins\...\Binaries\....dll
p4 reconcile ProjectName\Plugins\...\Binaries\....pdb
p4 reconcile Engine\Binaries\....dll
p4 reconcile Engine\Binaries\....pdb
p4 reconcile Engine\Binaries\....exe
p4 reconcile Engine\Plugins\...\Binaries\....dll
p4 reconcile Engine\Plugins\...\Binaries\....pdb
To limit the number of file revisions on the server, we also run the following script:
p4 reopen -t +S32w ProjectName\Binaries\....dll
p4 reopen -t +S32w ProjectName\Binaries\....pdb
p4 reopen -t +S32w ProjectName\Binaries\....exe
p4 reopen -t +S32w ProjectName\Binaries\....self
p4 reopen -t +S32w ProjectName\Binaries\....target
p4 reopen -t +S32w ProjectName\Plugins\...\Binaries\....dll
p4 reopen -t +S32w ProjectName\Plugins\...\Binaries\....pdb
p4 reopen -t +S32w Engine\Binaries\....dll
p4 reopen -t +S32w Engine\Binaries\....pdb
p4 reopen -t +S32w Engine\Binaries\....exe
p4 reopen -t +S32w Engine\Plugins\...\Binaries\....dll
p4 reopen -t +S32w Engine\Plugins\...\Binaries\....pdb
The reopen command makes sure only files that are open for add or edit are affected. The +S flag specifies the number of revisions to keep on the server. If you make frequent builds, your Perforce admin will appreciate you not using up all the server space with generated binaries.
Once those two scripts have run, the last step is to submit the files to Perforce.
Masking Out Binaries For Programmers
So now we’re building and submitting new binaries to Perforce, and all our non-programmers can just sync up and run the editor. But there’s one last step for programmers: masking out the binaries that get submitted. If you already build the binaries yourself, there’s no reason to sync them. In addition to it being unnecessary, we’ve had issues where a sync would overwrite some binaries that had been built locally, and chaos would ensue.
Here’s a workspace mapping that demonstrates masking out the submitted binaries:
So that’s it. We’ve been running with this for a while now, and I’m pretty happy with how it turned out. If you’ve got questions or feedback, I’d love to hear it!