Debugging and other helpful things

[tuturto]

What kind of systems/things are you using for helping in development? Things like profilers, debuggers, debuggin consoles within the game and so on? How do you like them and is there something that you feel could be done better?

Personally, I have two things that I use a lot. One is extensive debug log that is written if the game is started with specific command line switch. It uses aspects to log most of the method calls, their parameters and return values. In case of exception, exception is logged too. I like it because there usually is enough information to see how the program is running and where the problem might be. I also don't have to write separate calls to logging system, but it's handled more or less behind the scenes. Drawback is that the log can get big quite fast and finding information in it can be slow.

Second tool that I'm using is a debug server. There's small webserver running inside of the game and I can use it to inspect state of the game. Currently I can only view player character and map, but later I'm going to implement more functionality in it. Maybe things like spawning specific items or monsters to help in testing.

Very rarely I resort to debugging code. I think I have done that only in handful of cases, where I couldn't otherwise solve the problem. Profiling I haven't done much either, only to check occasionally that there isn't obvious bottlenecks where there shouldn't be any.

[kraflab]

I don't often have a need to use a real debugger.  For me, I just carpet-bomb print statements around the problem to figure out what is going wrong.

[NON]

I used to have a ton of console printouts in my code everywhere. Then I realized just running in debug mode in Code::blocks or similar does a better job. So I removed all the cout stuff for much neater code.

If the game crashes I just check the call stack. If the game is stuck in a loop, I can find out where by setting breakpoints.

For particularly frustrating things (like building the map generator), it's extremely helpful to be able to set breakpoints and look at function variable values.

Profilers are pretty much necessary for optimizing (but I haven't done that in a long time, since the game runs good enough).

[TheCreator]

I don't use logs. I think I have enough of them in my job . When the game crashes, it's the best when debugger breaks the execution, so you can debug immediately. Logs are only useful when someone else is testing and they accidentally find a bug (but crash dumps are still better). However, when you need to debug the initialization stage, a log (or a console window) is very helpful.

Profilers are piceless when you suddenly discover that your game slows down and you cannot find the cause. It's amazing that the results from a profiler are almost always totally different than your first guess.

I don't often have a need to use a real debugger.  For me, I just carpet-bomb print statements around the problem to figure out what is going wrong.

That's exactly what I've been doing in the old times when I had no real IDE with working debugger and I'm really glad that those old times are gone. Not many things are more frustrating than having to modify your code to see what's wrong with it .

[Z]

I have started more serious programming in an integrated debugging environment, and then started programming in gcc, without using IDEs. I had to learn how to effectively debug with print statements, and now I don't want to go back to using IDEs.

One good thing about this method is that it is always readily available. I develop in many different languages (some created by myself), for many different platforms (remote servers, mobile devices), and this method always works. After getting skilled in it, it is just faster to use it than to learn the debugger for each of these situations (in some cases the debugger might not even exist). It is hard for me to see how a debugger helps with some bugs (for example, when I have no idea about the precise condition in a function called 1000000 times which leads to some bad behavior which is also hard to describe, and when it happens, I would like to see the history which led to it), and the print method is more useful there.

[Ancient]

Not using IDE here. A plain editor to color my code is enough. I use two things to help me catch bugs: log file and core dumps. First is just prinfs redirected to physical file. The other is really useful too. Whenever my program falls into infinite loop I can kill it provoking core dump and examine it to know which loop was it and what was the call stack and see state of variables at the time. It is very useful when for some reason game crashes during playing. I can examine the core dump and know why it happened. For errors that do not kill the program there is log file. On the other hand I litter the code with assertions to crash the thing when something goes wrong.

[Krice]

I'm using in-game debug messages, not to track real bugs but to see what the game engine is doing at the moment. It's showing if something fails in dungeon generator etc.

I don't need debugger often, because I have learned how to write consistent code in C++ without producing the usual C/C++ bugs (buffer overruns, pointer problems). However should something happen it's usually quite easy to find with VC debugger.

[ant]

hello,

  because i have rog-o-matic talking to rogue i use
gdb to attach to the running processes if i need to
see the stepping.

  as i am learning how to use gdb now there are things
i will get better at (like figuring out how to tell it i
really don't want to see system call stuff at the moment).

  other times it is by adding more print statements (
below line 24 ).  for debugging the message parsing
i used a few lines and then added a few more lines for
figuring out a pack corruption bug...  now i'm onto trying
to track down a screen artifact problem...    great fun...


  my C is rusty, but i can figure most things out given
enough time, patience and rainy days.

[XLambda]

I mostly use jdb when debugging things that aren't obvious. If that doesn't help, print is your friend.

"The most effective debugging tool is still careful thought, coupled with judiciously placed print statements."
Brian Kernighan, "Unix for Beginners" (1979)

[purestrain]

I'm mostly using logs and unit/integration-tests. Of course sometimes i have to change the tests since gameplay changes.

[Kyzrati]

Mostly an abundance of assertions, even sometimes for conditions which seem impossible, since you can always turn them off.

Logging system with multiple levels of error messages (also controlled through assertions).

VS debugger breaks and watches for exploring values saves a lot of time.

If there's some repeatable but totally unexplainable hard crash that could be coming from anywhere (usually NULL ptr dereference) and the VS debugger is totally confused (it can't usually give you a reliable call stack trace for these) run a memory profiler.

Occasional code insertions to force special situations for testing when something's acting funny.

Most vital: An AI that can mimic the user and be run indefinitely to test the program automatically.

Speed profiling only much later when the program actually seems slow enough to require optimization.

[tuturto]

Most vital: An AI that can mimic the user and be run indefinitely to test the program automatically.

Interesting. You have full game running and the AI is playing it? Or specific scenarios that it replays over and over again? How do you handle asserting that the game is behaving as it is expected?

I'm building my system with test driven development and recently started tinkering with doctest (sort of unit testing the documentation), but really high level stuff I'm lacking. Like move from room to room, while opening the door in between and falling into trap stuff. Would be interesting to try that too.

[Kyzrati]

You have full game running and the AI is playing it?

Exactly. Program an AI to play the game like you would. It's useful not only because it catches bugs, but there's a lot of overlap between that AI and what you can use to run enemies. It takes a fair amount of extra time, but it's worth it because then you don't have to do as much playtesting yourself, and can find any strange errors that players/playtesters would find which you would then have to decipher (more easily done on the dev machine, obviously). Even rare errors, which may repeat only once in 1000, or even 10000, runs, aren't too much trouble for a computer to find. Just have it loop through plays, forever...

Plus it's fun

How do you handle asserting that the game is behaving as it is expected?

Watch it play! If it does stupid things, well, that's a problem to fix, too!

When going for a huge number of runs, the ability to completely turn off rendering/animation is also useful to get the game running far faster, if you're just testing the logic.

[ant]

Another very helpful feature is to be able to toggle the random number
generation to be simple or noisy.

For those situations where you get a rare event in combination that
only happens at deeper levels it can save a lot of time when trying
out a fix if you can replay the altered code with the starting
condition of the original version that errored...

[Krice]

Most vital: An AI that can mimic the user and be run indefinitely to test the program automatically.

Isn't that kind of hard to do? Sounds like that, an AI close to human player.