Book Excerpt: The Game Production Handbook: Making Builds

Author: by Heather Maxwell Chandler

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.

Build Schedule

After production starts, the initial build must be made as soon as possible—well before a first playable build. This provides a benchmark for measuring the progress of future builds. It provides proof of concept and technology to the development team and studio management. By the time the game is at a first playable stage, builds should be made two to three times a week. By alpha, it is ideal to be in the habit of making daily builds.

At the point when daily builds are being made, the QA department will work with the team to decide how often builds will be submitted for testing. It is counterproductive to give QA a new build to test every day. They need to spend several days with a single build to make sure they have tested all aspects of the game thoroughly. QA will probably only want to look at a new build every three to four days during alpha. The frequency of builds submitted to the QA department will increase as the game gets closer to code release. The build schedule will keep production progressing on the game. People can check in their assets and know when the build will be ready and submitted to QA.

Build Checklist

Creating a build checklist is helpful for remembering all the steps that are necessary when creating builds. Figure 18.1 is a build checklist for creating builds of Shanghai: Second Dynasty . This game was a PC/Macintosh hybrid and had several technical steps in the build process. In addition, several other steps were required to ensure that the correct set of assets was used and that any assets not included in the build were removed, such as development cheats and saved game files.

The checklist also tracked which version of the build was being made and what files had changed since the last build. The build steps for Shanghai: Second Dynasty are difficult to understand out of context, but the checklist gives a good idea of complexities involved in making a build. This build checklist can also be given to QA so they can double-check the modifications during the code release process. Refer to Chapter 22, “Code Releasing,” for more information code releasing builds.

Automated Builds

An automated build process is usually simple to set up and saves a lot of development time. If the process is automated, the person responsible for making the build does not have to take time to manually complete all the steps in the build checklist. If the build process for Shanghai: Second Dynasty were automated, the build would take less time, and fewer mistakes would be made. The checklist can provide the framework for what tasks can be automated.

All of these tasks can be automated by setting up a separate “build” machine, which has programming script that will instruct the machine to pull out all the updated code and assets from the version control system and compile them. When compiled, it will generate the latest build and copy it to an appropriate place on the computer network. This programming script can be set to run on a regular basis. For example, the build script can be set to run at midnight each night, so there is a new build waiting for the team in the morning.

 The automation process can be taken a step further in reducing time in other areas of development. For example, on certain days the build script could be instructed to copy the latest build to all the QA machines, so that when the QA testers reported to work in the morning, the latest build was ready for testing. The process can also include scripts that check the build for errors, such as misnamed files, missing assets, or incorrect file formatting. The error log can be automatically emailed to the team so that people can begin fixing the errors before the next build is created. The lead engineer can work with the development team to set up the best way to automate the build process.

A publicly visible indicator can be added to show when the build is not working. Clinton Keith of High Moon Studios has integrated lava lamps into the build process: “when an asset is checked into the game, there is an automated test suite that tests everything that is committed art- and code-wise to pipeline. If the tests determine that an asset has produced a fault, a red lava lamp is triggered to indicate that the build is broken. If the tests determine the asset is working correctly, a green lava lamp is triggered. The lamp is visible to the whole team and is a fun way to remind people to double-check the correctness of their work before checking it into the build.”

Multilingual Builds

Multilingual masters save money on the replication process and are easier for operations to track. If a single disc contains English, French, and Italian versions of the game, there is only one master to keep track of, instead of three. Ultimately, this saves money, because a great number of copies can be made from the single multilingual master that can be distributed in three countries. If planning to make multilingual masters, consider the following issues:

Build Notes

Build notes should accompany any build that is submitted to QA or sent to someone outside the team. Build notes describe pertinent information about the build, such as what is working, what isn't working, and what bugs have been addressed since the last build.

Depending on who the audience is, the build notes will be different. All the build notes must provide basic details on the date the build was made and the version number of the build so they can be matched to the correct build. As development progresses, not everyone will receive every build, so noting the date and version number will allow people to see how long it has been since they last saw a working build.

For the Development Team

Build notes for the development team should focus on what is new in the build. This includes any crash bug fixes, any new features implemented, any changes to existing features, andany art assets that have been added or changed.

This type of information is especially useful to the QA department, because it lets them know which bugs have been fixed. They can regress these bugs by confirming these fixes in the current build and marking them closed in the bug-tracking database. If QA does not receive build notes, they might spend time regressing bugs that have not been fixed by the development team.

For Management

Build notes for management do not need to detail the specific bug numbers addressed since the last build reviewed, as they are more interested in seeing the progression of the game.

Instead, focus on what features are implemented, what features aren't implemented, and any feature changes that have occurred since the last build they reviewed. Also note why the change was made: was this a specific request from management, or was it something that the team changed? If the feature change was requested by management, it is good to note this because it might affect future milestone deliverables, especially if another feature was dropped to accommodate this request. Build notes can provide a good record of all the project milestones and can track the history of the game's progress.

If an independent developer is working with a publisher, the publisher might have a specific format for the build notes, which might be based on the milestone definitions defined in schedule. This makes it easier for the publisher to check the accuracy and completeness of the deliverable.

Other important information to include in the management build notes are instructions on how to install and run the build. This is especially important during the development process, as the PC builds will not have installers, and the console builds will need to be copied to a development kit in order to be properly viewed. This information should be basic and written in layman's terms so that anyone can copy the build and get it to work. If special software is needed in addition to the build, this needs to be included in the build, along with instructions on how to install it.

For Marketing and PR

Build notes for marketing and PR should definitely not mention specific bug numbers that have been addressed. Instead, the notes should focus on what key features are working and what percentage complete they are. These notes will be sent directly to journalists, along with preview and review builds, so make sure that the wording is positive, even when discussing visible bugs that appear in the game.

Include specific instructions for installing and running the game. Also include basic gameplay information—the controller scheme, the main gameplay mechanics, the goal of the missions, and so on. This is a good chance for the development team to communicate what areas of the game look good and are really fun to play. If there is time, hints and tips for playing the game can also be included.

Journalists often play builds that are still in development, so they will forgive anything that is listed in the build notes as being incomplete or having a bug. If the game only has 5 levels out of 10 that are playable, list which levels should be looked at in the build notes. Make sure to note which levels are not yet finished and the major things that are still being worked on in the level. Any placeholder assets also should also be mentioned in the notes.

Preventing Piracy

Piracy, the act of selling illegal copies of game software, is an ongoing problem for game publishers, and they are always looking for ways to minimize the impact on the profitability of a game. According to the Entertainment Software Association (ESA), piracy costs the U.S. entertainment software industry several billion dollars each year. This number increases when adding the losses for the games distributed in international markets.

Piracy includes acts such as making and selling illegal copies of the game and offering the game for free download on the Internet (often referred to as “warez”). In some cases, the games made available through these illegal channels are not even the final versions.

Although these games are copyrighted and the copyright is enforceable under law, it is fairly easy for software pirates to create and sell copies of the game. Since piracy is an ongoing problem, software developers and publishers are taking steps to make this practice more difficult. The most common methods for deterring this behavior are copy protection schemes and lock-out schemes.

Copy Protection Schemes

A copy protection scheme prevents the user from making an illegal copy of the software. Such schemes include the following:

These types of copy protection schemes are effective in preventing the casual user from making a copy or two of a game and giving it to a friend, but are not as effective against professionals. Piracy networks have the tools to crack these protection schemes and create massive numbers of software copies that are then sold on the black market. As a whole, the software industry is still finding ways to fight against this practice.

Lock-Out Schemes

Lock-out schemes are also used by publishers on PC games to cut down on gray market imports. Gray market imports are official versions of the game that are “unofficially” available in territories where the product was not distributed. The full U.S. version of a game in the original packaging will often show up for sale in Korea, China, or other countries. One way to cut down on this practice is to lock out certain operating systems (OSs). For example, the U.S. version can lock out Korean, Chinese, or any other non-U.S. OS in the installer. The installer will check the OS before installing the game to make sure that it is a valid OS for the game. If not, the game will not install. These schemes are easy for hackers to work around, but they do provide a small level of security and will deter a casual user.

Summary

A well-organized build process makes game development go more smoothly, and it is not difficult to set up an automated process that is even more effective. This chapter discussed how to set up and automate the build process and why this is important. It also includes a brief discussion of various copy protection schemes that help prevent piracy.

_____________________________________________________