Game Development Reference
In-Depth Information
testers are certifiably crazy. Or your code could be crazy. My bet is on the code being
crazy.
You might wonder why I put something so amusing in the
section of working
on games. There are plenty of funny bugs; stuff goes wrong in a game and has a
bizarre result. Luckily, Quality Assurance (QA) should find it because it will be fun-
nier for you as a developer than it will be for players whose crashed game destroyed
their save files and ruined all their progress, forcing them to start again from the
beginning. Trust me, most players will
“
hard
”
“
”
rage quit
at that moment.
Beyond the funny bugs, there
'
s a dark side.
One bad thing is just the sheer volume of bugs. Games tend to be rushed into testing,
and the QA department does what they are paid to do and writes up every problem
they observe. I think they hope that eventually the producers will get the point and
stop sending proto-ware into the test department. They hope in vain because the
pressure to call the game
“
testable
”
is usually too much for the project management
to bear. It
'
s too bad that there tends to be no solid definition of
“
testable
”
unless you
work in QA. From their point of view, it
s pretty obvious.
The heavy bug volume weighs on everyone, developers and testers alike. They end up
creating a logistical nightmare. The graphical reports that get spit out by the bug
database are watched like the stock market; only this time, a steep upward curve
tends to have a negative effect on team morale. The worst part by far is what happens
when the team can
'
t quite keep the bug count under control, which typically happens
when they are still focused on finishing the game
'
s content and features. To stay
ahead, the project leadership gathers together and does
'
a process where
they kill off bugs without the team ever really seeing it. The bug simply becomes a
feature, maybe a weird screwed-up annoying feature, but a feature all the same.
“
triage
”—
You Won
'
t Be Able to Fix Every Bug
There
s nothing like having the rug pulled out from underneath you
because a bug that you intended to fix is marked
'
by the
team leadership. You might even have the code fixed on your machine,
ready to check in for the next build. Instead, you get to undo the
change. The final straw is when some critic on the Internet bashes the
programmers for writing buggy code and even points out the very bug
that you intended to fix. Most programmers I know are perfectionists
and take a lot of pride in their work, and because of that they lose
sleep over bugs. As evil as this seems, making those decisions is as
tough as knowing your code has a bug that you aren
“
won
'
t fix
”
'
t allowed to fix.
Believe me, I
'
ve done that a few thousand times.
