Andrew RudoiAt Believer, we feel strongly that we need technological innovation to make the games we want to make, and it’s critical to us that we share our learnings with the broader game development community. In this series, we’ll share our learnings around source control management and build infrastructure for Unreal Engine projects using Git. We intend to fully open-source any technology we’ve built for this, so that other Unreal projects out there need not start from zero.
Hello! I’m Andrew Rudoi (aka Rudeboy), an engineer at Believer focusing on developer workflows. My job is to help make working on our game as fluid and fun as possible, whether that’s through building Unreal Editor plugins or backend tools. Prior to Believer, I worked on three different titles at Riot Games. Enough about me! Let’s talk source control.
Git + Unreal: Does it even work?
Yes, it does. However, there are reliability and user-friendliness concerns, as well as a few missing features that are critical for designer workflows. In this series, we’ll walk through our adventure standing up a Git-based source control pipeline for our Unreal projects. We’ll explain why we chose Git, the successes and failures we’ve had so far throughout our implementation, and our future plans for Git-based tooling.
Let there be no suspense: We’ve found our decision to use Git completely worthwhile. Despite some initial onboarding and engineering costs, Git has enabled us to stand up repeatable and reliable workflows for engineers and designers working in Unreal. Our Git tooling has allowed us to implement a “clean main” system that makes it very difficult to break our game’s main build. On top of that, we’ve implemented desktop tools that make interacting with our game’s commit history straightforward and enjoyable. Of course, these tools aren’t finished, and we’ve got a plan for continuing to iterate on them as our studio scales.
Why Git? (Why not Git?)
When setting up our game’s project, we wanted to give Git a shot, primarily due to our positive experiences using Git on past engineering projects and our negative experiences using other tools on past game projects. That said, we knew Git would come with some challenges. Our pros/cons list at the time looked like this:
Pros:
- Git is the most popular and therefore best-tested source control tool there is
- The path for Git + LFS to scale geographically is well-known and straightforward due to LFS’ use of HTTP. This is a big deal for our remote-first studio.
- Git allows us to use GitHub for storing repo history
- GitHub provides great features for viewing repo history and conducting code reviews
- GitHub has built-in CI/CD capabilities through GitHub Actions
- GitHub as a platform is geographically distributed, meaning we can expect consistent network performance for all members of our team, which is fully-remote.
- Even if we were to not use all of GitHub’s features, there are tons of open-source and off-the-shelf tools available for supporting and enhancing Git-based workflows.
Cons:
- All of our designers and engineers were used to Perforce workflows. We knew that onboarding to any kind of Git-based workflow would be costly up front.
- Git’s UX is rough, especially for non-engineers.
- The Git CLI is hard to approach. There are a lot of subcommands and loads of options for each subcommand.
- Desktop UI tools like GitHub Desktop and Fork remove a lot of the command line requirements for working with Git repositories, but they expose way too much of Git’s internals to be straightforward to use.
- At the time, it was unclear how well Unreal Editor would support Git out-of-the-box. (it has strong support for Perforce through UnrealGameSync).
- Git in its default configuration does not perform well with large, binary files. We knew that Git LFS (Large File Storage) was available, but our team had little-to-no experience with it. Furthermore, GitHub’s LFS is quite expensive, so we’d likely need to consider alternative options for a Git LFS server.
With these pros + cons in mind, we decided to prototype a Git-based workflow for our game. We needed this exploration to answer the following questions:
Do we feel confident we can deliver a best-in-class workflow to our game’s individual contributors with a Git? Do our individual contributors feel confident?
Does Git give us a stable platform upon which to build our pipelines for iterating on and shipping the game? How difficult is it to support a Git-based workflow? How enjoyable is it to be accountable for the tech stack?
- Do we feel confident we can deliver a best-in-class workflow to our game’s individual contributors with a Git? Do our individual contributors feel confident?
- Does Git give us a stable platform upon which to build our pipelines for iterating on and shipping the game?
- How difficult is it to support a Git-based workflow? How enjoyable is it to be accountable for the tech stack?
The journey ahead provided these answers and more… which we’ll cover next time as I dive into the implementation process!
In the meantime, we’ve got a whole Discord dedicated to this project. If you ever want to come chat Believer open source, join us there!