MAKING BUILDS
In This Chapter
• Build Process
• Multilingual Builds
• Build Notes
• Preventing Piracy
19.1 I
NTRODUCTION
I
t 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 func-
tionality or ensure that the assets are displaying correctly in-game. For example,
there is a noticeable visual difference in how art assets for a console game dis-
play on a PC and how they display 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 the
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 and the
code will be more difficult to deal with as development progresses.
Chapter 19Chapter 19
324 THE GAME PRODUCTION HANDBOOK, 2/E
19.2 BUILD PROCESS
Define the build process in pre-production and implement it as early as possible
in the development cycle (usually when assets and code are available and can be
used to create a build). The sooner a build can be compiled, the sooner you can
start fixing bugs and making improvements to the game. If it takes too long to
establish the process, development delays will occur during critical milestones,
because the engineers will spend precious time trying to compile a milestone
build instead of coding features and fixing bugs.
A flexible process allows special builds to be created upon request. For ex-
ample, marketing might request a demo build for a conference which only has
certain levels and characters available to play. Or QA may need a special build
for a 16 player multiplayer test with an external testing house that limits access
to the single-player part of the game.
Put a system in place to track when something new is added to the build.
This is helpful if an artist is waiting for a certain tool to be finished or if a de-
signer is waiting on a level to be checked-in 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. For example, when an engineer checks in updated vehicle AI
code, he sends an email to this list stating what he just checked in. Artists send a
“New in Build” email every time an art asset is checked into the build, and so on.
Doing this gives QA a better idea of what to expect in each build that is delivered
for testing, and makes it much easier for the team to track what’s added to the
build. The “New in Build” emails also provide a good foundation for creating
build notes, which are discussed later in this chapter.
Hiring a data manager to manage the process is very useful. The data manager
is able to focus the necessary time and attention needed to automate the build
process, fix build errors, and test builds before they are delivered to marketing,
QA, or senior management. He will work with QA to set the delivery schedule
for new builds, and can work with the team to determine which processes can
be automated in order to streamline the build process. Ideally, he will set up a
process to compile a new build every day that is then stored in an archive. While
you may not need a new build every day, it is good to have daily build system
in place so you always have a working build with the latest features. While the
data manager will be the primary person to oversee the process, several people
need to know how the process works in case the data manager is unavailable for
whatever reason.
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
MAKING BUILDS 325
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
counter-productive 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 depart-
ment 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.
Automated Builds
An automated build process is usually simple to set up and saves a lot of develop-
ment 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 necessary to
compile the build. All of the build tasks can be automated by setting up a separate
“build” machine, which has a 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 mid-
night 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 in-
structed to copy the latest build to all the QA machines, so that when the QA tes-
ters 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 automati-
cally 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 work-
ing. 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 the 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
326 THE GAME PRODUCTION HANDBOOK, 2/E
and is a fun way to remind people to double-check the correctness of their work
before checking it into the build.”
19.3 MULTILINGUAL BUILDS
Multilingual masters contain multiple languages on a single master disc. These
masters are cheaper to replicate because only one master is needed to cover a
wide-variety of territories, and one master is easier to track than multiple mas-
ters with different languages. If your game will be distributed on multi-lingual
masters, keep the following issues in mind:
Storage space? Does the disc have enough storage space to hold multiple
sets of assets—this includes localized cinematics, localized VO files, and lo-
calized text files. Remember that you may have to store five full languages on
a single disc (English, French, German, Italian, and Spanish).
Flexible release schedule? If the localized versions are running behind,
how will they impact the release date of the main version? If there is any
chance the main version may be delayed because the plan is to create a
single multi-lingual master, the publisher may opt to separate the main SKU
from the localized versions at the last minute. Thinking about this issue be-
forehand allows you time to figure out the most efficient and accurate way to
separate the languages at the last minute.
Language selection? How will the game determine which language to dis-
play once the game is installed? The player can select their preferred lan-
guage in the options menu, or during the installation process, or the game
can automatically display the correct language based on the hardware’s lan-
guage settings.
19.4 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 de-
velopment 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.
MAKING BUILDS 327
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, and any 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 ad-
dressed 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 im-
plemented, 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 ac-
commodate 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 mile-
stone 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 dur-
ing 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 prop-
erly 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 instruc-
tions 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
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.