Game Development Reference
In-Depth Information
'
The second step, attempt to explain the behavior, can be pretty hard if you don
t
know the software like the back of your hand. It
'
s probably safe to say that you
should know the software, the operating system, the CPU, video hardware, and
audio hardware pretty well, too. Sound tough? It is. It also helps to have a few years
of game programming under your belt so that you
ve been exposed to the wacky
behavior of broken games. This is probably one of the most frustrating aspects of
programming in general: A lack of understanding and experience can leave you shak-
ing your head in dismay when you see your game blow up in your face. Everybody
gets through it, though, usually with the help of, dare I say, more experienced
programmers.
Steps three through five represent the classic experimental phase of debugging. Your
explanation will usually inspire some sort of test, input modification, or code change
that should have predictable results. There
'
s an important trick to this rinse and
repeat cycle: Take detailed notes of everything you do. Inevitably, your notes will
come in handy as you realize that you
'
re chasing a dead-end hypothesis. Your notes
should send you back to the point where your predictions were accurate. This will
put you back on track.
'
Change One Thing at a Time
—
and Don
'
t Rewrite Anything
—
Yet
Another critical aspect to the experiment-driven debugging process is that
you should try to limit your changes to one small thing at a time. If you
change too much during one experiment cycle, you won
t be able to point
to the exact change that fixed the problem. Change for change
'
s sake is a
horrible motivation to modify buggy code. Resist that temptation.
Sometimes there is a desire to rip a subsystem out altogether and replace it
without truly understanding the nature of the problem. This impulse is
especially strong when the subsystem in question was written by a
programmer who has less than, shall we say, stellar design and coding
skills. The effect of this midnight remodeling is usually negative because it
isn
'
'
t guaranteed to fix the bug, and you
'
ll demoralize your teammate at the
same time.
'
Assuming that you follow Table 23.1, you
ll eventually arrive at the source of the
problem. If you
'
re lucky, the bug can be fixed with a simple tweak of the code. Per-
haps a loop exited too soon or a special case wasn
t handled properly. You make your
mod, rebuild the game, and perform your experiments one last time. Congratula-
tions, your bug is fixed. Not every programmer is so lucky, and certainly I haven
'
t
been. Some bugs, once exposed in their full glory, tell you things about your game
that you don
'
ve seen bugs that told us we had to completely redesign
the graphics system we were using. Other bugs enjoy conveying the message that
'
t want to hear. I
'
