Game Development Reference
In-Depth Information
n
Class B: This bug could ship, but players will definitely notice it; however, if
the bug is rare, they will tolerate it. A good example of this might be a
disappearing background object on the common play path.
n
Class C: Fixing this bug won
the
team might know it is wrong, however. A good example of this might be the
wrong music being played in a specific area or an incorrect texture on an object
in a junk pile.
'
t effectively make any difference to the players
—
The closer the project gets to the scheduled zero bugs milestone, the less likely minor,
C level bugs will actually get fixed. This rule of thumb is directly related to the fact
that any change in content or code induces some risk. I
ve seen a single bug fix create
multiple new bugs. This implies that any high-risk change should either happen
much earlier in the schedule or there has to be some incredibly compelling reason,
like there
'
s no other choice, and the project is in jeopardy if the change isn
'
t made.
These problems are usually elevated to the highest level severity in the bug database,
and your game shouldn
'
'
t ship if it hasn
'
t been fixed.
Ghosts Are Supposed to Be Transparent, Aren
'
t They?
At some point in the final week of Ghostbusters: TheVideoGame for the Wii
at Red Fly Studio, the producer noticed that none of the ghosts were
transparent anymore. Evidently, a change had gone in weeks before, and
everyone was so exhausted from crunch that no one noticed. The change to
fix the problem was tricky, and it touched quite a few systems. As risky as the
change was, it didn
t take the team long to decide that it was worth fixing.
After all, how can you really know you are seeing Slimer without seeing the
hot dogs in his stomach?
'
Everyone on a project has his pet feature, something that person really wants to
see in the game. The best time to install these features is before the code complete
milestone (some people call this alpha). There are a few good reasons for this. First,
it gives the team a huge burst of energy. Everyone is working on their top-tier wish
lists, and tons of important features make it into the game at a time where the risk of
these changes is pretty tolerable. Second, it gives the team a message: Either put
your change in now or forever hold your peace. After code complete, nothing new
code-wise should be installed into the game. For artists and other content folks, this
rule is the same, but the milestone is different. They use the content complete mile-
stone (or beta) as their drop-dead date for pet features. One more note about pro-
grammers and artists adding anything: If the game isn
'
t reaching target performance
goals, it
'
s a bad idea to add anything. Adding things won
'
t make your game any
