Build Management Hell February 17, 2014 cliffski This is part of indie life nobody warns you about. In your mind, you create a game, test it, upload it, then sit in front of windows showing the sales figures and the bug reports. That’s what happens right? Not quite. The modern indie game, even one that is a pure-desktop (not mobile/tablet) experience can end up with a scary amount of build-management. If you are really organized and clever (clearly I’m not) you can manage it without too much stress. If you don’t plan ahead, you end up like me. Democracy 3 has, primarily it’s ‘direct sales’ build on PC. This is the ‘master build’. It then has a separate build for steam, which is uploaded through valves tools. That’s 2 builds. Then there is a build for GoG without steams API in it. Then there is the build for the humble store. And also there is the secure copy uploaded for reviewers. That’s five builds. That’s no problem. Then each of those has a mac and a linux build. Ouch, that’s 15 builds now. This is a pain, but doable. Then it gets translated into French and German. Ok, that means 45 builds now. Yeah, 45 builds. No big deal right? But don’t forget each one is about 40-50MB in size. That’s 2 gigabytes. No big deal? Try uploading that with 45k/s upload speed out here amongst the sheep. You can see why I don’t get to play any online games around ‘democracy 3 patch days’. Also, you can see just how infuriating it is when you find a bug that needs patching. 20 minutes debugging, an hour fixing and checking, 12 hours uploading. And because I’m so dumb, all of those builds are entirely separate, even though 95% of the files are shared across them all. Learn from my mistakes, get your build process sorted out beforehand!