Debugging tips?

Question

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?

Answer 1

• 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.

Answer 2

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.