A Crash Course in Visual Studio Debugging for Game Developers
One of the common types of questions I see asked quite often on the XNA Forums is "Here is my code, I expect it to do this but it does that. Someone tell me why." This is frustrating to hear because it's often easy to figure these things out by simply walking through your code as it is running. I suspect the reason for these questions is that many new developers simply aren't aware of how to debug an application/game.
As a basic example, let's say that I have an enemy thisEnemy and when he gets shot, I will set "thisEnemy.Active = false" to indicate that he has been killed. But when I shoot him, he isn't removed from the screen. The reason for this could be because thisEnemy.Active isn't being set correctly or maybe it's being reset at a later point or the Update or Draw loop isn't correctly checking the Active property or it could even be a fourth wild scenario that you never imagined. Without debugging the app, you either have to think through the code line by line or guess what might not be working and try fixing it (running the risk of changing pieces of code that don't need changing). For a basic case like this, that might work, but you're going to struggle with more complex situations. Using some simple debugging techniques, you will be able to follow exactly what is going on as your code executes, seeing the variable values all along the way, and determine much more quickly what is causing your problem.
You will start your exciting journey into the world of debugging by setting a breakpoint. To do so, all you have to do is left-click the mouse on the left edge of your source file in the narrow gray bar area (if you have line numbers turned on, this will be just to the left of those). A big red circle will appear. If you click here a second time, the breakpoint will go away. It's also noteworthy to know that you can set (and remove) a breakpoint while your game is running.
When your code is running and it hits that breakpoint, execution will stop immediately at that point. In the IDE, you'll notice that if you hover over any variable names (either in the current method or global variables), you'll see an Intellisence-like pop-up that tells you the values for that particular variable (and allows you to change them if you wish). The goal of debugging your app is to determine what is actually going on (as opposed to what is desired to be going on) and knowing what values things are set to is key to that understanding.
From this point, there are a couple of actions you can take. If you're happy with the information you've found at this breakpoint, you can allow your program to happily continue executing. Press the green play arrow (or F5) to do this.
If you want to examine how your code is executing (such as seeing what happens inside a loop), you are going to need to use Step Over (F10) and Step Into (F11). Both of these commands execute the next line of code (and then stop) but act differently when it comes to methods. If the next line of code was "MyMethod();", Step Over would execute this method and go to the next line of code. If you used Step Into, you would jump to the first line of MyMethod() and be able to walk through that method (and then return to the point it was called when the method completes).
When you're debugging, you want to pay close attention to what your code is doing and compare that to what you expect it to be doing. Check if your code is correctly entering and exiting loops, calling methods, and setting variables how and when you expect. It's also good to set breakpoint near where you think the problem might be to eliminate walking through excessive amounts of code. If you think a problem is in your thisEnemy.Update method, you can set a breakpoint right there and find the problem more quickly.
Going back to our original example with thisEnemy, in o
This article has been view 2343 times.