Game Development Reference
In-Depth Information
'
'
universe itself. I
ve never been able to explain that phenomenon, but it
s real. This
will solve half of the unsolvable bugs.
Another solution is static code analysis. You should have enough observations to
guess at what is going on, but you just can
t figure out how the pieces of the puzzle
fit together. Print out a suspect section of code on paper
'
—
the flat stuff you find in
copy machines
and take it away from your desk. Study it and ask yourself how the
code could fail. Getting away from your computer and the debugger helps to open
your mind a bit, and it removes your dependency on them.
If you get to this point and you still haven
'
t solved the problem, you
'
ve probably been
at it for a few solid hours, if not all night. It
—
not from the prob-
lem, but from your computer. Just leave. Do something else to get your mind off the
problem. Drive home. Eat dinner. Introduce yourself to your family. Take a shower.
The last one is particularly useful for me, not that I need any of you to visualize me
in the shower. The combination of me being away from the office and in a relaxing
environment frees a portion of my mind to continue working on the problem with-
out adding to my stress level. Sometimes a new approach to the problem or, even
better, a solution will simply deposit itself in my consciousness. That odd event has
never happened to me when I
'
s time to walk away
—
'
m under pressure sitting at the computer. It
'
s scary
'
'
when you
re at dinner, it dawns on you suddenly, and you
ve solved a bug just by
getting away from it.
Every game needs to have a robust logging system. You can only go so far with the
assert()
macro from the standard C libraries. With the sheer size of games, you
need the ability to define different levels of errors. Some errors are more important
than others, and you want the ability to define different severities for them. You also
need a way to disable certain errors altogether. Finally, these errors should be ignored
in the release version of the game.
Logging informational messages is another thing we
'
ll need. This is how we
'
ll pepper
the code to find out what
s happening inside a particular system. This logging will be
based on tags; you can turn certain tags on or off, which enables or disables logs for
that tag. For example, the event system may have its own tag. Enabling this tag will
allow you to see what
'
s happening inside the event system as it updates without hav-
ing to step through breakpoints.
For this logging system, there will be three basic levels of logging. The first is error,
the second is warning, and the third is info. Logs at the error level will display a dia-
log box showing the error string along with the function name, filename, and line
'
