Game Development Reference
In-Depth Information
memory leak. If the bug goes away, you can be sure that it only exists in the main
loop somewhere.
You should be able to creatively disable every major system at a time, such as anima-
tion, AI, and sound. Once these systems are stubbed out, your game will probably act
pretty strangely, and you don
t want this strangeness to be interpreted as the bug you
are looking for. You should have a pretty complete understanding of your game
before you embark on excising large pieces of it from execution.
If your game has an options menu for sound, animation, and other subsystems, you
can use these as debugging tools without having to resort to changing code. Turn
everything off via your game options and try to reproduce the bug. Whether the
bug continues to exist or disappears, the information you
'
ll gain from the experiment
is always valuable. As always, keep good records of what you try and try to change
only one option at a time.
You can take this tactic to extremes and perform a binary search of sorts to locate a
bug. Stub out half of your subsystems and see if the bug manifests itself. If it does,
stub out half of what remains and repeat the experiment. Even in a large code base,
you
'
ll quickly locate the bug.
If the bug eludes this process, it might depend on the memory map of your applica-
tion. Change the memory contents of your game, and the bug will change, too.
Because this might be true, it
'
s a good idea to stub out subsystems via a simple Bool-
ean value, but leave their code and global data in place as much as possible. This is
another example of making small changes rather than large ones.
'
Most debuggers give you the power to set the next statement to be executed, which is
equivalent to setting the instruction pointer directly. This can be useful if you know
what you are doing, but it can be a source of mayhem when applied indiscriminately.
You might want to do this for a few reasons. You may want to skip some statements
or rerun a section of code again with different parameters as a part of a debugging
experiment. You might also be debugging through some assembler, and you want to
avoid calling into other pieces of code.
You can set the next statement in Visual Studio by right-clicking on the target state-
ment and selecting Set Next Statement from the pop-up menu. In other debuggers,
you can bring up a register window and set the EIP register, also known as the
instruction pointer, to the address of the target statement, which you can usually
find by showing the disassembly window. You must be mindful of the code that
you are skipping and the current state of your process. When you set the instruction
