Game Development Reference
In-Depth Information
Once the Beta test phase winds down, the game should be at a state that resembles the
following set of typical release guidelines:
1. All known Severity 1 bugs (crashes, hangs, major function failures) are fixed.
2. Greater than 90% of all known Severity 2 bugs are fixed.
3. Greater than 85% of all known Severity 3 bugs are fixed.
4. Any known open issues have a workaround that has been communicated
to Technical Support (or documented in the
README.TXT
file, in the case of
PC games).
5. Release-level performance has been achieved (60-fps frame rate).
Upon meeting your release criteria, the game is declared to be at “code lock.�? A brief,
intense period of testing is performed on what everyone on the team hopes will be
(but which will probably not be) the final build. Since the version of the game that is
sent to be manufactured is known as the
gold master
, the final few versions tested are
known as
gold master candidates (GMCs)
or
release candidates
.
At this point the game look and feels like any other retail game. It's up to the testers to
serve as the last line of protection for both the player and the project team by sniffing
out any remaining hidden defects that would have a significant impact on player sat-
isfaction. This should be done by rerunning one final time all of the test suites, or as
many as time permits. In addition, a number of testers should be tasked with “breaking�?
the game one final time. Any remaining bug found during this final effort deemed too
severe to be waived is called a
showstopper
, because it causes the gold master candidate
to be rejected. A new GMC must be prepared with a fix for the new defect, and release
testing must start over again from the beginning.
Last-Minute Defects
Because the final stages of the project are so intense and pressure-laden, people will
react negatively to showstoppers: “Why are we [or you] just finding this now? Test has
been going on for months!�? This refrain is frequently heard from stressed-out executives.
It is best for the test team to take such emotional comments in stride and remember
several inviolable truths of game development:
1. There is seldom enough time in any project to find every bug.
2. Every time a programmer touches the code, bugs may be introduced.
3. Code changes accumulate over time, so that several iterative changes to
different parts of the game may result in a bug showing up downstream
from those changes.
