I'm new to games programming and I'm working on a C#/XNA project.
Something I'm spending a lot of time on is debugging. Obviously as games run in a loop finding the exact iteration that a bad condition has occurred can be tricky.
Spending time setting up conditional breakpoints certainly helps but eats up time.
Are there some ninja tips out there for helping to track down the precise moment things go bad that you guys use?
you can try creating log files, although they may a be a bit hard to work with but they are useful in many ways:
using log files you can replay your game with all the things happen in it including the bugs! so in case of rare bugs you can check the bug again and again until you solve it.
using log files you can monitor your variables without stopping your program, I mean when you try debugging your program is stopped for a couple of minutes when you are checking what is happening and usually that will lead to unexpected frames after debugging. but using log files you can monitor all those variables after program execution so there will be no unexpected changes in your application results.
later on you can use same log file feature to create a replay viewer for your game, it's pretty good if a gamer could see what he did or what he didn't to win/lose a game.
Kind of a simple advice here but a little something that I found very useful is displaying debugging strings/rectangles to the screen.
You can print the player's current state, the enemy's animation state, the number of active bullets, the frames per second, etc. All these simple variables are what make up the core of your game, so it's essential that they work properly and a nice way to make sure they do so is to have debugging tools at hand.
So, in addition to logging variables like Gajet proposed (which is a very good advice imho), you should also show these variables while your testing so you can clearly see when something is wrong.
It may seem stupid, but it helped me find a lot of nasty bugs that I thought were much more complicated (I simply put red rectangles to show colliding tiles on a platformer, and I found out that the problem wasn't in the collision response code, but rather in the collision detection code).
You'll start out with a debugging string tool, then move on to debugging shapes (rectangles or even lines to represent vectors), then to more complicated tools and you'll eventually end up with a pretty solid debugging toolbox that you can reuse over other projects (if you make sure your debug code is general enough to be independant of the game).
In addition to debugging tools, consider writing unit tests. I know it doesn't sound nice having to write tests for most functions from your game, but don't see it this way. Unit tests can save you a whole lot of time. For example, if your collision system is not working but you wrote enough unit tests for your collision detection, you can just look into your collision response code and find the bug.
Not only does it tell you where to look for the bug, it also tells you when you break something after changing a few lines somewhere, because your tests won't pass anymore.
If unit tests are too much for you, then at least start adding assertions into your code. So, if something is obviously wrong (e.g. a character with negative health), your code will break right away and you won't waste your time too much.
A couple of advices that I learned the hard way. You may think some are useless, but try them out and see if they fit your debugging needs.
I know that it's been awhile since this question was posted but I feel that people might benefit from these answers and I'd like to point out something else that has helped me tremendously. Right click your project in the Solution Explorer and select properties. On the properties page that opens make sure the Application tab is selected and look for the Output Type drop-down list. By Default it is set to Windows Application but you can change it to Console Application. With this enabled your application will run as normal but in addition to the XNA window a second console window will open and you can output messages with a simple Console.WriteLine()
A debugging feature that I recommend implementing is a "frame advance" function. This is a common feature in classic console emulators that allow input recordings for the purpose of developing tool-assisted speedruns. Essentially, you pause the update loop, and press a key to run the next pass of the update loop exactly once. This was really helpful for me in developing a platformer project, as it let me more easily study the effects of a collision response on the frame of the collision.
I implemented this by having a "DebugPause" flag, toggled by pressing a key while in "GameDebugMode" in the game. In the DebugPause state, the update loop is exited immediately after listening for input, essentially freezing everything in place while still rendering graphics. Then, if the "DebugFrameAdvance" key is hit, the remainder of the update loop is called exactly once. This way, you can hold the desired keys down for input, hit the DebugFrameAdvance key, and observe how the game responds on a particular frame. Combined with some kind of collision box display, you can see the details of how the physics in your game works in slow-motion. Also, while paused, you can set a breakpoint somewhere inside your update loop, and it won't be called until your next frame advance!
Note that my game used a fixed time-step, so I think some additional trickery will have to be put in place if you have a variable time step.
I hope this helps, and good luck!
