Useful debugging tools and features

Published January 19, 2015
Advertisement
Bug finding is one of the more frustrating tasks when coding a game. Just yesterday I hopefully hunted down a very frustrating bug, thought I hoped this already 3 times before.
Sometimes bugs are really nasty, coming up only after several minutes of active gameplay and once you see the result, you can't find a trace for the reason. Over the years I've added some useful features to help me finding bugs and I thought it is good moment to present them here. Larger projects will most likely utilize these and many others features, still you might find one or two ideas useful to tweak your own debugging tools for your game.

Let's start.

Log files
Okay, this is one of the most basic debug features available and a must have.

HTML Server
I think that your game should be a HTML server, it is not unusal, but nevertheless extremely powerful. For coding a server like this, you really just need a tcp socket and some basic http handling. HTTP is no magic and is really easy to parse and write. If you write out some simple html pages as responce to a http request, then your browser will suddenly be a very powerful debugging tool.

More advanced features are the usage of javascript/ajax etc. to transform the browser into a extremly powerful interactive tool.

Shader Reload
Reloading shaders on the fly (per html server plugin) and logging out some data (does it compile etc.) is really useful to track down this little nasty shader glitches.

Custom Script Execution
If your engine supports a scripting language, add a possiblity to execute script-code on-the-fly. Very useful to log out information, or to modify game objects.

Ingame Object Information
Add some way to have a ingame information about objects. Use the cursor/mouse to target an object and push out the data directly on the screen. I found it really useful to have two of this debugging outputs, one on the left side of the screen and one on the other side. This way I can track down two objects concurrently. Although helpful is the use of the page up/down keys to display multiple pages of information.
Lock on a Single Object
I can take a single object and put a debug focus on it. This results in additional debug output (logfile) etc and to in the option to set conditional breakpoints to isolate a single object in your debugger. If you debug every object all the time, then you will have just too much information to handle efficiently.

Custom Visualisation
Just add some visualization to else invisible information. From a simple wireframe render output to displaying physics hullobjects and waypoints.

Persistent Gameflow History
It is really useful to have a secondary logging mechanism to log and view the gameflow. This is similar to the standard log file with the difference, that it is part of the game (and will be saved with it), is more compact, describes only game related stuff (no technical stuff). It helps to track down these game design bugs, eg. if a tester said, that he never found the red-key, just look up the history file to get a hint (eg. he picked it up and dropped it later on). It helps to keep track of all these events you can't watch all the time (Why are suddenly half of my minions dead ?).

Time slow/forward
Ok, if your game is realtime, you should consider to use a virtual clock. I have the option to speed-hack my own engine by slowing/speeding up the time. It is really useful to reproduce some time dependent events (7x forward and the bug will be reproducable in a few seconds), to slow it down (why are this animation transition so choppy) or to even stop the time completely
to freeze your game state and debug it with your html plugins and script execution.
One thought, your forward will most likely get CPU bound due to fix-your-timestep parts of your code. In this case additonal CPU power is really useful.
8 likes 7 comments

Comments

Aardvajk

That's a good summary, thanks. The HTML server stuff is interesting. Care to share some of the implementation of that?

January 19, 2015 08:47 AM
Ashaman73

That's a good summary, thanks. The HTML server stuff is interesting. Care to share some of the implementation of that?

I would not mind, but I would fear that you will not understand a lot (eg. I use a more generic socket handling to cover udp/tcp multiplayer stuff, in general I use a lot of my engine stuff). Best to google for simple http server, I found what looks like a simple implementation here.

January 19, 2015 10:07 AM
studentTeacher

Cool stuff. I'm actually starting to look into that HTML Server stuff since it seems so damn useful, and interesting to learn! Thanks for the cool read :)

January 20, 2015 03:31 AM
Aardvajk

That's a good summary, thanks. The HTML server stuff is interesting. Care to share some of the implementation of that?

I would not mind, but I would fear that you will not understand a lot (eg. I use a more generic socket handling to cover udp/tcp multiplayer stuff, in general I use a lot of my engine stuff). Best to google for simple http server, I found what looks like a simple implementation here.

Thanks. Not an area I know squat about so you're almost certainly correct. Will check out the link.

January 20, 2015 08:12 AM
CC Ricers

I work with HTML so this should be second nature for me. With the example you posted, what exactly would you do to produce relevant debugging data? Seems like you're describing a fancy version of a text log file writer. However I think it would be possible to send HTTP requests via AJAX to update the page while the game runs.

January 20, 2015 09:04 PM
Stragen

While as a summary this article is great, IMO, the HTTP server is overkill...

You're only going to be able to make static calls to view information, unless you force a refresh or use a dynamic language which really moves this from a basic implementation to a more serious one, at which point the value of setting up a full blown web server in your code really is questionable because you've spent a deal of time to code this component over coding your game. I also wouldn't expect you would want to be running a full blown web server for your release versions to avoid the various issues that a 'basic' web server would result in (privacy, connectivity, exploitability), so the utility would be somewhat diminished.

In a similar ilk to the HTTP approach, perhaps just output your 'debug log'/'critical variables' file into a HTML format, which you're going to have to do anyway with the approach above, and either open the file with any browser or drop the file in a dedicated web server, append to the header of the file you create a 1 second refresh using javascript and use that as one option for debugging.

January 24, 2015 09:05 PM
Ashaman73

While as a summary this article is great, IMO, the HTTP server is overkill...

You're only going to be able to make static calls to view information, unless you force a refresh or use a dynamic language which really moves this from a basic implementation to a more serious one, at which point the value of setting up a full blown web server in your code really is questionable because you've spent a deal of time to code this component over coding your game. I also wouldn't expect you would want to be running a full blown web server for your release versions to avoid the various issues that a 'basic' web server would result in (privacy, connectivity, exploitability), so the utility would be somewhat diminished.

In a similar ilk to the HTTP approach, perhaps just output your 'debug log'/'critical variables' file into a HTML format, which you're going to have to do anyway with the approach above, and either open the file with any browser or drop the file in a dedicated web server, append to the header of the file you create a 1 second refresh using javascript and use that as one option for debugging.

Http is not a full-blown webserver, but a simple and easy to implement protocol. I use javascript/ajax etc. to make the browser a powerful tool, not the server. Eg I made a simple, dynamic particle/effect editor as javascript , the server just takes the modified effect-file and updates the effect on-the-fly.

Some more advantages: I use often several browser tabs, I keep them open between game sessions (no need to browse through your ingame debug features all the time), I display them on a secondary monitor, I can change visuals on-the-fly without cluttering the game screen with ingame-tools, I can modifiy tool-webpages on-the-fly without recompiling/re-starting the game,...

For logfiles it is just easier to use some of the log-file viewer tools around.

you've spent a deal of time to code this component over coding your game.

Yep, indeed, but I spent a considerable portion of my dev time debugging my game and these tools gave me a good return over the last years.

I have not added these features up-front, I build them to solve certain issues more efficiently

January 26, 2015 07:36 AM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement