This thread is about error checking, logging, error reporting and other debugging / betatest info gathering methods.

Personally, I love assert/verify custom made macros that report an error and shut down the game smoothly, and I use them liberally (they were life savers back in the fullscreen-exclusive DirectDraw days).

Just yesterday I've coded a record/replay module for my logic game collection. It's quite simple, it mostly captures every message in the main game loop (I use SDL, but I imagine everything would work just as well with a Win32 message pump) and writes it to a record file. There are some issues with syncronising the AI thread, forbidding or recording srand calls, recording the delays I use to keep the FPS constant, but nothing that can't be worked out. To replay I simply use a different main loop that reads messages from the record file instead of the SDL messages (I pay attention to MOUSE_MOVE messages and move the mouse appropriately). Surprisingly, the record file size is quite small (notwithstanding that it can be further shrinked a lot).

The result is perfect recording, to the point that most bugs are captured in the replay (those that aren't machine dependent anyway). I can't wait to add features such as changing the speed of the replay, or an edit box to allow the betatesters to write comments about the game as they play.

I know people who have implemented featurs like this have always claimed it was worth it and that it helped speed up debugging 10 fold. Sometimes, however, a developer doesn't rely purely on the windows message pump to gather input from the user. The messagepump can be notoriously slow especially for repeated input like someone holding down on an arrow key, so often the state of the keyboard or mouse is queried asyncronously.

Here's a link (http://www.flipcode.com/cgi-bin/msg.cgi?showThread=Tip-MainLoopTimeSteps&forum=totd&id=-1) to an old Code of the Day at flipcode which describes a method for implementing a fixed timestep loop. Basically the main game loop runs on a fixed time step it checks all it's input at the top of the loop and encodes it into a 32bit word (or some other sized bit field) it then performs the operations based on that input and the word is recorded to a file. In this way you are no longer dependant on the windows messages because you build the input word and you can query any input at that time. When playing back the input words your game is gaurenteed to run correctly as the main loop operates under a fixed timestep and for each timestep you know the exact input for the loop because you recoreded it at the same timestep. This would also reduce the problems you were having with AI timing etc...

Original post by Dan MacDonald
The messagepump can be notoriously slow especially for repeated input like someone holding down on an arrow key, so often the state of the keyboard or mouse is queried asyncronously.


Yes, everything asyncronous or non-deterministic must be recorded. Timer reads, network input (or lack of), thread syncronisation, etc.


Here's a link to an old Code of the Day at flipcode which describes a method for implementing a fixed timestep loop.


That was a good read. My objection to their approach is that only the game logic code would be guaranteed to run exactly the same in the replay as it did originally, which may have advantages and disadvantages.


This would also reduce the problems you were having with AI timing etc...


Not really. The AI runs in a separate thread. In the main thread, I have a timer message that pops about 6 times a second that checks on whether the AI has offered a solution yet. Either way, I must record whether the AI has finished or not.

Anyway, what I'm saying is that it should be very easy to add recording to just about any message pump based game, largely regardless of it's design.