Chapter 12: Debugging Your Game

Overview

By the end of any game development project, the programmers and others that they can recruit spend all of their time fixing bugs and tweaking performance. As important as debugging is (especially in game development), techniques in debugging are rarely taught. They tend to just come from experience, or are traded around the programming team. Since I'm communicating to you through a book, we can't trade much but since you bought the book I think we can call it even.

Games are complicated pieces of software and they push every piece of hardware in the system. Bugs are usually pilot error, but there are plenty of cases where bugs trace their roots to the compiler, operating system, drivers, and even specific pieces of hardware. Bugs also happen as a result of unexpected interactions between code written by different programmers; each module functions perfectly in a unit test but failures are seen after they are integrated. Programmers spend lots of time hunting down issues in code they didn't write.

If you are going to have a chance in hell of fixing broken code, whether you wrote it or not, you should have a few ideas and techniques in your toolbox. I've often considered myself a much better debugger than a programmer, which is lucky because I tend to find bugs caused by my own flawed code pretty fast. As I say be careful of harping on other people's mistakes because the next person to screw up could be you! This happened, I'm sure, because of how I learned to program. I programmed for years in BASIC on the old Apple ][, which didn't have a debugger. When I went to college I programmed in PASCAL on the VAX mini computer at the University of Houston. After four years of college I noticed an odd looking screen in the computer lab. I asked the person sitting there what I was seeing. "A debugger," they replied. "What's a debugger?" I asked. I got this blank stare back as if I'd asked what electricity was.

I'd spent my entire college experience coding programs without using a symbolic debugger. Needless to say, programming got a lot easier after I was introduced to my first debugger, but the experience left me with some good programming practices and solution strategies that you can use whether you use debuggers or not.

I need to warn you up front that you're going to see some assembly code and other heavy metal in this chapter. You simply can't perform the task of debugging without a basic working knowledge of assembly code and how the CPU really works. This is not a gentle chapter, because we're not discussing a gentle problem. It's not brutally hard to learn assembly, and you have an excellent teacher: your debugger.

All debuggers, Visual Studio included, let you look at your source code at the same time as the assembly. Take some time to learn how each C++ statement is broken down into its assembly instructions and you'll end up being a much better programmer for it. Fear not: I'm with you in spirit, and I wasn't born with a full knowledge of assembly. You can learn it the same way I did, which was by playing with the debugger.