Over the last decade, AAA game development has become so expensive and risky that game teams are forced to play it safe, which results in less creativity. Embark is all about trying to rethink the way games are made, from the ground up.

In part 1, our solo developer ran into a familiar problem: They had something that worked great before… but it’s gone now. The Game has changed over time, but there’s no reliable way to see how or when those Changes happened.

Now they face a different problem. The Game is live and needs to stay stable. But at the same time, the developer wants to work on something risky, a new system, or experimental tech that might take weeks and will almost certainly break things along the way.

So far, everything has worked out ok because there was only one developer. One person, one computer, one mental model of what the “latest version” is. As soon as a second person joins, an old problem comes back. “Which version of this file is the latest?”

In this series of posts, I will outline how our CI system helps us ship high quality content at a fast pace. If we refer back to the terminology from my colleague Arvid’s blog posts, this article series would be overkill if your team is small enough that you’re within shouting distance in the office.

If you worked with Unreal you might recognize the above as the steps run by BuildCookRun. Our actual CI processes run in a program called ci.exe that is about 80K lines of Rust code. It invokes Unreal tools, exports game data into our backends, publishes the game on Steam and Playstation and many other things.

No matter how good your CI is you always want it to be faster. The first step of making anything faster is to measure how fast it is. If you look too much at individual runs you’re going to end up exhausting yourself, drawing the wrong conclusions and also probably focusing too much on outliers rather than the main paths.