|
 Features
Automating
the Build Process
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.
Welcome
to the relaxing new world of automated build processes. You can make
the process of turning your game assets into an actual CD image or Internet
download as easy as compiling a new executable during debugging.
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
|
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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!
________________________________________________________
 Implementing
it Yourself
|
|
|
|
|
