We had to use Perforce (Helix Core Cloud) at my last game studio, and it is the de facto industry standard that most of your creative staff is already familiar with. The programmers don't love it, but they don't rule the roost in games. It's also the safe, verified default for working with Unreal Engine 5.
It does show its years though. We were one of the first users of the Perforce cloud offering, as we were small and didn't want to self-host ourselves, but it was a bit of a rickety experience. You had to register an Azure account in order to be able to access the service, and you had to ask support to modify things like triggers. Coming from the world of GitHub and other SaaS products, you could tell it was an attempt to retrofit an older model into a new skin.
The Git LFS path has some unofficial support as well, but you are on your own when things go poorly. Epic doesn't provide much help there.
Competition in this space is welcome, especially if they're planning to make it fully officially supported by the Engine.
I wrote about why merging files isn't as common in the world of game dev for folks coming from the world of text: https://www.kuril.in/blog/why-game-devs-dont-merge-files/
ditto; and UE5 on anything that isn't perforce is a lesson in pain.
I just took over a team that was using Git, and yes, I know it's everyones favourite VCS but for Games it's just about the worst thing available. I could measure art reviews with git in hours, now with perforce its seconds. I wish I was joking.
All the interesting tools that UE5 uses (Horde/UBA for a clean example) will require perforce.
but, Perforce hasn't done anything with its industry position. It's expensive as hell and they don't have operational costs related to hosting (you have to host it yourself, and honestly, for performance reasons you really want to- despite it being a real pain to maintain passed first install). There's some echoes of stuff they try but they have absolutely no solid direction and nearly everything they've been doing cuts against common sense or their userbase, while their core product keeps getting renamed but no actual improvements.
It's a lesson in how proprietary software is really a prison.
I wish I could use a better code review tool than Swarm.
I wish I could integrate SSO without weird LUA hooks which cause segfaults on my machine (enough of them causing a perforce deadlock).
and I wish I could run a distributed storage backend instead of relying on a big fat SSD and journalled backups that can't be restored because licenses are tied to the IP address of the main server.
It's forgotten technology, and the company that operates it is a zombie.
I completely agree with every single point you've said here. Running a P4 server is an exercise in self torture, but it's the only option with UE5.
> I wish I could use a better code review tool than Swarm.
With one caveat. I think swarm is a great tool. It could do with being easier to configure, but as a code review tool it's simple, straightforward and gets the job done.
> I wish I could integrate SSO without weird LUA hooks which cause segfaults on my machine (enough of them causing a perforce deadlock).
this is about the only thing that Perforce has actually managed to do in the last... 5 years? [0] It's also woefully awkward to set up and operate, as is everything P4. But it does work.
[0] https://help.perforce.com/helix-core/integrations-plugins/he...
I'm actually using helix-authentication-service.
Swarm "works with it" in theory, but in practice I had to patch the loginWithSSO function to shell out to the p4 process to handle auth, because P4PHP doesn't expose ClientSSO at all and it's required for a clean login with keycloak.
EntraID is a different flow that they've probably nailed, from what I hear from other studios.
As I said in my last reply - none of that surprises me. Our provider worked out of the box, fwiw.
interesting, is it rude to ask what provider you use? (if it's not EntraID?)
Sorry - I didn’t intend to be vague! Entra, yep.
Ah! thanks for clarifying. :)
Couldn't agree more. I wonder why the company stalled as much as it did. To be fair they've been around for three decades, maybe it's just hard to keep momentum for that long, especially if you're in a dominant position with no competition coming after you.
They got sold to a private equity company in 2016.
UBA mostly doesn't need Perforce and Horde isn't as good as the GitHub, gitlab etc.
UGS (the tool that pulls down the latest engine version for artist) is pretty perforce centric.
Wasn't aware that Gitlab could do distributed compilation.
Horde configurations can only live locally or in Perforce: https://dev.epicgames.com/documentation/unreal-engine/horde-...
Horde only supports Perforce today: https://dev.epicgames.com/documentation/unreal-engine/horde-...
UBA and Horde go together pretty well- in fact I've never seen a distributed-UBA deployment without a horde one (SN-DBS, Fastbuild or if you're wealthy: incredibuild are much more popular), but adaptive unity builds check for a read-only flag; which is how Perforce treats checked-out/changed files but not git.
I meant that, as a web accessible build and review tool, Horde is not as good as the rest of the big players. You would still use gitlab et al to run your UAT script and that would do whatever distributed build you want.
I agree that it might not be feasible advice to try to force of of these other SAASed into the mix. It's just that Horde lacks a lot of niceties that the greater tech community has.
This a lot of very old and out of date information and opinions, respectfully disagree
How out of date?
I migrated from Git (AzureDevops) to Perforce in February this year, this was true then.
Horde is approx 8 months in the public eye.
Respectfully, what?
I really like your article. It does a good job of explaining not just the technical differences but the way those affect the surrounding development culture.
Thank you! It was a bit of culture shock for me when I first experienced it, coming from the world of business software, and I figured others would find it equally fascinating to learn more about.
I went in the other direction. 8 years at EA and now at Google working on open source.
Everything is so easy when your entire source repo is a paltry few hundred megs and you can build everything from source in a few minutes. It feels like flying.
Very relatable. I still recall when our team at Microsoft, about 20 years ago, had a dedicated "build engineer" who would be given the task to create a new branch for the product. He would disappear for a few days and re-emerge with the announcement that a new branch had been officially created and was ready to be used. Hard to imagine that in git world.
When I went back to Perforce I was reminded of why that was a thing. You're making a full copy of everything. They recently introduced a virtual copy stream, but I remember people advising against using it, for reasons I can no longer remember. It seemed like a potentially sensible approach.
Oh, and thanks for writing Game Programming Patterns. That was a great resource.
You're welcome! :D
Git LFS and git's (relatively) new sparse clone features i suspect are their answer to this sort of thing, although my understanding is that was more focused on monorepo operations in general. I'm not entirely sure permissions were sorted, or this sort of mixed-mode dvcs/cvcs operation model with file-scope checkouts interacting with traditional branch-mode operation.
Its not just about the tech, you have to have non-technical artists using this thing every day