Getting started

Both Epic's live streams present setting up and using Perforce.

Configuring server

Stream depots allow for much easier managing of the depot. For instance, you can have "Coders" stream configured in such a way that any binaries compiled by programmers are ignored by Perforce. A standard practice with Unreal Engine is to have a "build system" compiling binaries (after every change in source code submitted) and publish it to the team.

Without stream depot, you would have to configure the same things manually for every single workspace.

• Using Perforce as Source Control - a page from the official docs explaining with example typemap

Unreal-specific typemap

And here's go the typemap we should cover all common filetypes, including types used while pushing the engine source to the repository. Also if using Perforce to store asset sources created by artists.

binary+l //....uasset
	binary+l //....umap
	binary+w //....3ds
	binary+w //....abc
	binary+w //....ai
	binary+w //....aiff
	binary+w //....blend
	binary+w //....bgeo
	binary+w //....bmp
	binary+w //....dae
	binary+w //....dds
	binary+w //....dxf
	binary+w //....exr
	binary+w //....fbx
	binary+w //....flac
	binary+w //....geo
	binary+w //....gif
	binary+w //....glb
	binary+w //....gltf
	binary+w //....hip
	binary+w //....hipnc
	binary+w //....hmv
	binary+w //....jpg
	binary+w //....jpeg
	binary+w //....ma
	binary+w //....mb
	binary+w //....mp3
	binary+w //....mp4
	binary+w //....obj
	binary+w //....ogg
	binary+w //....pic
	binary+w //....picnc
	binary+w //....png
	binary+w //....psb
	binary+w //....psd
	binary+w //....sbsar
	binary+w //....skp
	binary+w //....spp
	binary+w //....tga
	binary+w //....tif
	binary+w //....tiff
	binary+w //....usd
	binary+w //....wav
	binary+w //....wmv
	binary+w //....vfl
	binary+w //....zpr
	binary+w //....ztl
	binary+w //....exe
	binary+w //....dll
	binary+w //....lib
	binary+w //....app
	binary+w //....dylib
	binary+w //....stub
	binary+w //....ipa
	binary+Sw //....pdb
	text //....c
	text //....config
	text //....cpp
	text //....cs
	text //....h
	text //....ini
	text //....m
	text //....mm
	text //....py
	text //....txt
	text+w //....DotSettings
	text+w //....modules
	text+w //....target
	text+w //....version

Binary files

File locking is a standard feature of Perforce. Basically, all binary file types submitted to the repository should have such entry in the typemap.

binary+l //....uasset

Every file submitted to the Perforce repository is set to read-only. It's crucial when working with binary assets, the user has to either:

• Check out the file before editing. If the filetype is "lockable", checkout it exclusive. That means that no one else is allowed to check out this asset. Now you and only you are allowed to submit the asset. Some teams prefer to set .uassset to binary+w, this prevent situation when someone would lock the asset for everyone for a longer period of time.

• Make it writable. It allows saving assets on your drive while someone else locked it. This allows you to temporarily change assets and continue your work. You won't be able to submit changes until the asset is locked by another person. And it this other person would submit a changed file, you need to discard your changes and download the latest version of the asset.

  • If that's important, you can that other person to Revert the file (discard changes and unlock the file) or simply Unlock the file via Perforce client.

  • This action should be avoided, if not really needed. You might forget that you modified this asset and could take a while to debug "why my game works differently for me than all teammates".

Binary, but temporary files

binary+Sw //....pdb

You can tell Perforce to store only the last version of the file, by filetype. This is useful for debugging symbols (.pdb) - a single version of symbols for the compiled engine is about 20 GB. Although you don't need to version it, it's just useful to provide debugging symbols to non-programmer people - so they could get a descriptive callstack in case of a crash.

Text-based files

text //....cpp

Text-based files don't need exclusive checkout. If two programmers would submit conflicting versions of the file, it can be easily merged.

With Perforce integration configured (IDE connected to your Perforce server like the UE editor), every time programmer starts to edit a text file (.h, .cpp, .cs and so on), IDE will automatically check out the file. It should be an invisible action to the programmer, like with Git.

• Visual Studio doesn't provide Perforce integration out of the box. Programmers need to install a free official plug-in called P4VS.

• There's also a plug-in for VS Code.

• Rider comes with Perforce integration built-in :)

Writeable text files

text+w //....modules

Some types of text files are modified during C++ compilation. These filetypes should be always writeable locally. Otherwise, compilation would fail.

Using Perforce

Perforce system has "users" and "workspaces" which can be confusing before you start using it, especially when looking at licensing terms. Albeit it's very simple. Generally, Perforce is very easy to use for non-tech savvy people.

Users

Access levels are set per user.

• There's a special Admin user, usually the first user auto-created while opening P4Admin for the first time. It has all privileges, configuring other users, groups, depots, access restrictions. All the power.

• Regular users can have different access to data on the server. For instance, Design users read/download the entire project, but modifying anything in the engine folder is blocked. This prevents accidental changing some engine's content. Also, regular users never download folders with the source code (it's approx. 100K files in the engine's Source folder).

• Now Code users are allowed to change anything in the engine folders and see all the code, but asset sources are hidden from their view (if such sources are stored in the repository). This way programmers simply never download files used by Digital Content Creation tools, like Maya or FMOD.

• FMOD project and sound sources would be visible only to Audio users.

Also, every user can have a different password. Although many studios set the same password for every developer. Simply, nobody needs privacy on a team-shared repository. And this makes things easier if a given person goes for a long vacation, but someone else needs to access files locked by this person.

Workspaces

All the operations on files, commits and changelists are bound to the workspace, not the user. This way every user could use multiple workspaces.

• One workspace used in the office, another one while working remotely.

• Or your default workspace belongs to Code user, so you can download and compile the code. But sometimes you want to access the FMOD project to test a game feature related to FMOD. You can simply a new workspace under Audio user just for this purpose.

Your personal preferences are saved to the workspace.

• You can change folder mappings, i.e. Unreal project could be synced to "C:\MyProject" folder, but a folder with the custom engine could be downloaded elsewhere, i.e. "D:\Engine".

• You can also exclude specific folders or files from being ever synced.

The Advanced tab in the workspace settings window hides many useful things.

Useful links

• Start Collaborating with Unreal Engine and Helix Core

• Allar's Blog - Populating Perforce With An Unreal Engine Source Build

Talks for advanced users, presenting Epic's take on branching. Also showcasing Unreal Game Sync - which is a tool based on the Perforce.