Games are not just code. Art, design, music and QA all get in the way, making the whole CI process harder, but actually making the game fun! It’s just as important that the CI process benefits these guys otherwise there are still going to be a hurdles to getting a solid game released and making the process as smooth as possible.
The Nightly Build
Due to using Cruise Control, we know the build can compile and because we never leave on a failed build we know we can run a full ‘rebuild’ of the game at night. This guarantees that we do a full rebuild of the game at least once a day, and can remove any niggles that crop up from Cruise Control only running ‘build’ steps. And since we are doing it when no one is around, we have the time to build all the game assets, including animations, textures, models, music and anything else that we need. Since this can take hours, it doesn’t matter if we start the build at 11pm, as by 9am the next day everything is up and ready to go.
So we finally have a fully integrated build that is being generated for the start of every working day. It means that QA have a full build to test at the start of the day, but also the designers, artists and musicians have a fully up-to-date project in which to add their assets and tweak the game play.
But this can be difficult to first set up. Since you are automating the entire process, everything needs to be command line driven. This isn’t always easy with off the shelf tools, or even bespoke software, but the time it can save is definitely worth the time. Luckily the BlitzTech SDK is fully configurable using a custom scripting language so we can not only build the assets, but run additional processing steps such as compression or pre-processing of assets.
Generating More Regular Builds
But we still have a slight problem. What happens if 10 minutes into the day a programmer implements a new feature that the designers want to play with it right there and then? Do they have to wait until tomorrow morning just to get hold of it? What if the assets being generated by the artists change in a way that are no longer compatible with the build they have?
Since we have a Cruise Control machine constantly building a new version of the game, we can easily add additional steps to the end of the CC process. We have a step at the end of a successful build that copies the executables to the network and (similar to the failed build mails) sends a mail to the designers and artists telling them a new build is available.
By providing them with a simple tool that allows them to get ‘latest build’ from whereever they want, the designers have access to the latest game features pretty quickly (this is also another reason to trim down the amount of time it takes to finish a Cruise Control build).
So the programmers are no longer disrupted with requests for new builds, and the artists on the team are no longer using half-built, half complete builds during the day. It means the full game is being used at all times and is never in an unknown state.
Some teams at Blitz add additional information to their Cruise Control builds and this is something I hope to incorporate into the Arcade process at some point. Each CC build will display the latest Subversion revision on screen at all times. By requesting that the programmers specify the SVN revision in bug reports or feature check-in’s, designers will instantly know if the build they have does what they need it to do.
Generating The Game Assets
It would also be cool if the Cruise Control build also came with up-to-date assets so QA could get the latest build and go from there. Obviously time is a serious concern here, but since our entire build process is command line driven, we can add steps to build the assets at the end of a successful build and before copying it to the network. In our process this is an optional step, as at the start of a project, when it takes minutes to generate the assets this is pretty useful, but near the end of a project this can add hours onto the process and has to be removed.
One way to avoid this, and make the process more suitable for the artists, is to have a separate build machine, which only generates the release build (which is usually the one used by the artists and designers) and builds only the common asset packages. This is sometimes done on the bigger projects at Blitz as it can take slightly too long for artists to wait for the programmers Cruise Control machine to finish.
Generating Submission Builds
One more thing that comes from this process is our submission builds. Since we can generate a nightly build automatically (usually by adding a single script as an automated task) we can generate all our builds by running the same script. This means that our submission builds hook into the same process as everything else which avoids the most important builds being built in an un-tested environment and make the process even more secure.
So we now have a process that allows us to automatically generate the whole game at any point of the day, and at least once a night. The designers, artists and very importantly QA can hook into the CI system giving them an up-to-date build at any point and no one is every playing a build of the game that is half-built or doesn’t have everything that is currently available.
In the next part I want to cover the process of self-testing builds and how this can make a build not only compile, but actually make sure it is doing what it is supposed to be doing.