The following is a selected excerpt from The Game Production Handbook (ISBN 1-58450-416-1) published by Charles River Media.

--

Introduction

It is important to have a process in place for creating builds on a regular basis so that features and assets can be checked in-game. If regular builds are not created, the development team cannot do proper checks of the game's functionality or ensure that the assets are displaying correctly in-game. There is a noticeable visual difference in how art assets for a console game display on a PC and how they display in-game on a television. There are numerous settings on televisions—some with lighter displays and some with darker displays—all of which can affect how something looks in-game. The developer will not see these differences unless he creates a build and looks at the assets directly in-game.

If there is difficulty creating a build, it can also indicate that there are bugs in the game that are preventing the code from compiling. The developers might not realize these bugs are there until they try to create a build. If a long time elapses without creating a build, critical bugs will remain undiscovered in the code and will be more difficult to deal with as development progresses.

Build Process

Every development team will have a different build process, which is usually determined by the lead engineer. The important thing is making sure that this process gets defined during pre-production and implemented as soon as assets are available for creating a build. Waiting too long to establish a build process will cause development delays during critical milestones; the engineers will spend precious production time trying to work out kinks in the build process instead of coding features and fixing bugs.

The process must be flexible so that it can be modified to create builds with special requests. For example, marketing might request a stable build they can demo at a conference, which has only a certain area of the game available to play. Access to the other game levels can be prevented by locking out UI functionality or by removing items completely from the game.

The process must also have a way to track what has been added to the build. This is helpful if an artist is waiting for a certain tool to be finished or if a designer is waiting on a level to be finished so he can begin scripting it. One simple way to do this is to set up a “New in Build” mailing list for what's been added to the build. This way, if an engineer checks in updated vehicle AI code, he sends an email to this list stating what new code he just checked in. An artist would send an email to the “New in Build” list every time an art asset was checked into the build, and so on. This helps the team as a whole track what's being added to the build, and it alsogives QA a better idea of what to expect in each build that is delivered to them for testing. The “New in Build” emails also provide a good foundation for creating build notes, which are discussed later in this chapter.

Although a primary person will oversee the build process, several people needto know how the process works. This is useful if an unplanned build needs to becreated, and the primary person is not available to do it.