Game Design, Programming and running a one-man games business…

Build Management Hell

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!

9 thoughts on Build Management Hell

  1. 45 builds? Ouch!

    Just curious, what’s the difference between the GOG and Humble build? The GOG build doesn’t have Steam API in it, but does the Humble build have Steam API in it that’s different from the Steam version or something?

  2. Isn’t there a language management library for C/C++? This way you can use the same build for each language and just provide translations as properties files.

  3. #Had a question similar to Mark B

    I would have thought a lot of this could be done automatically?? Like a script of some sort?

  5. I wonder if it would be worth it to do your builds on some kind of remote server. That would mean you could upload just the source code patch from your home system to the server (using whatever your source control system is), then do the release builds and further uploading from a data center with lots of CPU power and bandwidth. Of course, this may depend on how well your tool chain plays with remote access (command line stuff being much easier to handle remotely), but I’d imagine a remote desktop solution could work for almost anything.

    If you used something like Amazon’s cloud services (I forget the name they use for their generic computing cloud system), you could set up multiple copies of your build environment and then build all of the releases simultaneously on separate systems. When you’re done and everything is uploaded, just shut the build systems down until you need them again for the next patch!

    1. Building from a virtual machine in the cloud could be a really good idea. Amazon Web Services EC2 virtual machines are as easy to create and configure as local virtual machines in something like VirtualBox. It would certainly work for Windows and Linux builds, but remote Mac OS builds could be more awkward, if even possible.

      I find building multiple SKUs of a product is usually pretty easy to deal with. In the past, we used to handle several hundred variations of language, screen size, audio format, device and feature set a mobile game. It’s just parameterised scripts and various trigger conditions. As Cliff says though, it’s the logistics of managing those builds once you have them that can be the problem. Size is one thing, but when the numbers increase, simply storing them in a logical place that testers or reviewers can access can be awkward. You need a full CMS, that’s ideally hooked into your source control and bug database systems! I could go on…

  7. Hey Cliff,

    Have you looked into Visual Studio with TFS Online? If you’re an MSDN sub, it’s included I believe.

    All cloud builds plus many more features. Ok, so most of the features you won’t need like work item management since you’re a one-man army, but the CM/RM features of TFS are rich. Something to consider.

    Good luck!

    Chris

  8. Wow, that’s horrible!
    You should implement localization ids, then just load the appropriate language file at the start of the game, replace ids with translated strings and you just got rid of 30 extra builds.

Comments are currently closed.