Game Development Reference
In-Depth Information
'
Sound systems like Miles from RAD Game Tools are extremely well tested. It
s much
more likely that a sound system crash is due to your game deallocating some sound
memory before its time or perhaps simply trashing the sound buffer. In fact, this is so
likely that my first course of action when I see a really strange, irreproducible bug is
to turn off the sound system and see if I can get the problem to happen again.
The same is true for other multithreaded subsystems, such as AI or resource preload-
ing. If your game uses multiple threads for these kinds of systems, make sure that
you can turn them off easily for testing. Sure, the game will run in a jerky fashion,
since all the processing has to be performed in a linear fashion, but the added benefit
is that you can eliminate the logic of those systems and focus on the communication
and thread synchronization for the source of the problem.
The Pitch Debugger Comes to the Rescue
Ultima VIII had an interrupt-driven multitasking system, which was something
of a feat in DOS 5. A random crash was occurring in QA, and no one could
figure out how to reproduce it, which meant there was little hope of
it
getting fixed. It was finally occurring once every 30 minutes or so
—
way too
often to be ignored.
We set four or five programmers on the problem
each one attempting to
reproduce the bug. Finally, the bug was reproduced by a convoluted path.
We would walk the avatar character around the map in a specific sequence,
teleporting to one side of the map, then the other, and the crash would
happen. We were getting close.
—
Herman, the guy with perfect pitch, turned on his pitch debugger. We followed the steps exactly, and
when the crash happened, Herman called it: A B-flat meant that the bug was somewhere in the memory
manager.
We eventually tracked it down to a lack of protection in the memory system
two threads were
accessing the memory management system at the same time, and the result was a trashed section of
memory. Since the bug was related to multithreading,
—
it never corrupted the same piece of memory
twice in a row.
Had we turned multithreading off, the bug would have disappeared, causing us to focus our effort on
any shared data structure that could be corrupted by multiple thread access. In other words, we were
extremely lucky to find this bug, and the only thing that saved us was a set of steps we could follow
that made the bug happen.
There are some bugs that are very strange, either by their behavior, intermittency, or
the source of the problem. Driver-related issues are pretty common, not necessarily
because there
'
s a bug in the driver. It
'
s more likely that you are assuming the
