Game Development Reference
In-Depth Information
servers, was collated in the login server, and was written to a SQL database.
The EA executives liked pretty charts and graphs, and we gave them what they
wanted. Anyway, the login process was a Win32 console application, and to
help me understand what was going on, I printed debug messages for logins,
statistics data, and anything else that looked reasonable. When the login
servers were running, these messages were scrolling by so fast that I certainly
couldn
t read them, but I could feel them. Imagine me sitting in the UO server
room, staring blankly at three login server screens. I could tell just by the shape
of the text flowing by whether or not a large number of logins were failing or a
UO server was disconnected. It was like looking at the Matrix in its raw form.
'
Debugging with Music
The best caveman debugging solution I ever saw was one that used the PC
speaker. Herman was a programmer who worked on Ultima V through
Ultima IX, and one of his talents was perfect pitch. He could tell you the
difference between a B and a B flat and get it right every time. He used this
to his advantage when he was searching for the nastiest crasher bugs of them
all
t even allow the debugger window to pop up. He wrote a
special checker program that output specific tones through the PC speaker
and peppered the code with these checks. If you walked into his office while
his spiced-up version of the game was running, it sounded a little like raw
modem noise, until
—
they didn
'
t
dependent on the CPU, it would remain emitting the tone of his last check.
“
the game crashed. Because the PC speaker wasn
'
Hmm
…
that
'
saD,
”
he would say, and zero in on the line of code that
caused the crash.
So you tried everything and hours later you are no closer to solving the problem than
when you started. Your boss is probably making excuses to pass by your office and
ask you cheerily,
You suppress the urge to jump up and make an
example of his annoying behavior, but you still have no idea what to do. Here are a
few last resort ideas.
First, go find another programmer and explain your problem. It doesn
“
How
'
s it going?
”
t really matter
if you can find John Carmack or the greenest guy in your group, just find someone.
Walk them through each step, explaining the behavior of the bug and each hypothe-
sis you had
'
even if it failed. Talk about your debugging experiments and step
through the last one with him (or her) watching over your shoulder. For some odd
reason, you sometimes find the solution to your problem without that person ever
even speaking a single word. It will just come as if it were handed to you by the
—
