Game Development Reference
In-Depth Information
Appendix B. Useful Tools for Programmers
There are several tools that make programming less error prone and
improve the overall ability of a programmer. This appendix covers
some of the most valuable tools—the ones most professional developers
will use on a daily basis. These tools are general enough that they aren't
exclusively for game programmers, so any programmer can benefit
from learning to use them.
Debugger
Novice programmers often try to debug problems in their code with text output
statements, using something like
printf
in C or
cout
in C++. For a console
application, this might make a lot of sense. If a user is required to type “yes” or
“no” and instead enters “maybe,” it's completely appropriate to have a text error
message. But using print statements in real-time programs such as a game typic-
ally does not work too well.
Imagine you are trying to fix a problem with the position of a particular game ob-
ject.Itmightbetemptingtoaddaprintstatementinthisobject's
Update
function
that outputs the position of the object every frame. But the problem with this ap-
proach is you will now have console output 60 times per second with the position
of the object (assuming the game runs at 60 FPS). It would be difficult to extract
meaningful information from that amount of spam—and worst of all, all that spam
can slow down the frame rate.
That's not to say that print messages don't have any value in a game. If it's an
error that only occurs once, such as a nonfatal inability to load a texture, it might
be okay to output that as a text error. But an even better solution would be to ac-
tually show a temporary texture in-game, in hot pink or another neon color, so the
problem is instantly visualized by anyone playing the game. The fact of the mat-
ter is that other team members likely are not going to pay attention to text console
output, but they definitely will notice a hot pink texture.
So if print messages aren't a good way to debug a game (or most programs), what
should be used? The answer is the debugger. Every single
IDE
(integrated devel-
opment environment) has some sort of debugger built in. Some work better than
others, but the basic principles are typically the same. This section looks at the de-
bugger in Visual Studio 2010, but all of the concepts should transfer over to the
