Making a new build of a game in development is a very stressful task. It requires great care and concentration for several hours, on work which is essentially tedious. Particularly towards the end of a project, the slightest mistake could be disastrous. Because of the demands of marketing, testing, management and the publisher, it is often carried out under high pressure.

Computers are particularly good at automating repetitive tasks, and carry them out more quickly and more reliably than humans can. Unfortunately, because this is often hard to do in Windows, people find it easier to carry on performing tasks manually using the GUI.

During development of Creatures 3, we used Unix scripting tools under Windows to write an automatic build process. It gathered all the work of the team, compiled, processed and tested it to produce a final CD image. This was very successful. We are using the same system to similar advantage in current projects.

Key Advantages

There are several ways that having a build system will help your project.

• More reliable. The final builds were of a higher quality than manually made builds. This is because the build script never forgets to do something. In addition, automatic testing during the build process ensures the most obvious errors are caught before the build is finished.
  
  
• Save developer time. Instead of having one engineer working full time to make a build, you only need someone to start the build going, and organize fixing of any errors that show up. That one engineer can then fix bugs, or do something else useful.
• Risk reducing. If the developer who normally makes builds is ill, goes on holiday, or somewhere more disreputable, it is easier for other people to make builds. Even if there are problems, there is a clear script describing every stage of the process, so it is possible to work out what went wrong. The knowledge in the mind of the developer is captured in script code, rather than in his head.
• Faster. If things went smoothly, we made a new build in half an hour. This isn't hugely faster than a smooth manual build with an attentive developer. However, the time taken is much more consistent. And the build can be made overnight, or while at lunch

• Instant availability for testing. The build process empowers your QA department by emailing them to let them know as soon as a new build is available. They can start testing it straight away, or have it waiting for them fresh off the cooker when they arrive earlier than you in the morning

Despite all these improvements, making builds can still be stressful! The person responsible for builds still needs to check that everyone in the team is ready for the new build to be made. Then they set the build going, check for any errors and fix them or arrange for them to be fixed. They also need to maintain the build scripts.

Outline of Build Stages

Figure 1 is a brief overview of the stages that you need in your build process. You can use this as an overall guide to writing your build script. The rest of the article gives lots of details for technical implementation.

Figure 1: Outline of the Build Stages

1. Compiling executables. The first thing for a script to do is to grab any C/C++ source code from the version control system, and use a compiler to automatically make a release mode version of your game engine. In the process it can upgrade the version number and tag it in source control for future reference. Then you can always get the exact code back again for future debugging.
2. Gathering files. Next it is time to muster all the other assets. This means graphics, sounds, music, scripting code, level designs and video. These can be retrieved from your version control system or from a fixed place on the network. We do both, keeping many assets in a "build template" folder which is a skeletal version of the installed image.
3. Localization. If your game is localized then you can customize the build, for example by copying the correct files depending on the language. You can also add or remove bundled adverts (e.g. an AOL installer) and change logos according to your publisher and market.
4. File processing. This is a good moment to carry out processing on the files. Graphics can be converted and optimized, and level files compiled. In Creatures 3 the build script ran our own tools to splice Norn genomes together, making the lives of our genetic engineers that bit easier.
5. Automated checks. As you get more used to build scripts, you will find it useful to add code to check for common errors. For example, scanning scripts to detect missing graphics files, or for common coding errors.
6. Full game testing. The next stage of the script is particularly crucial for increasing build quality. The build machine copies the game image as if it had been installed, and then launches it into a rolling demo or self-play mode. In Creatures 3 we hatched a few Norns and let them play in the world. The build script detects any error messages and if it finds them it abandons the build.
7. Installation compiling. Finally the build script calls the installation program (e.g. InstallShield) to create the installer from the game image, and copies the completed CD image to the network.
8. Email notification. The team members and QA are emailed to let them know it is ready. As a final flourish, you can even get the script to cut a physical CD and eject it from the drive!