[In this reprinted #altdevblogaday-opinion piece, Nlogn Information Technologies Technical Director Charilaos Kalogirou discusses how one can exactly reproduce scenarios to track down bugs.
Debugging a game can be quite frustrating some times. What makes it so is the fact that in many cases, reproducing a crash can be impossible.
How can you pinpoint a memory corruption bug that causes a crash many frames after the incident? How can you replay the exact game until the point right before the crash, then a bit earlier, until you can see what went wrong?
You can never play the same game twice, and even single a frame lasting longer can have dramatic changes to the execution and the point of crash.
The system I use for such cases is a full replay system. To be able to reproduce a bug, you must be able to replay the exact game. And by game I mean the whole session from execution start, all the way to the point of crash.
To do so you must think of the game engine as a deterministic black box that has specific undeterministic inputs. If these underterministic inputs are logged, we can reproduce the exact execution any number of times we like.
The key here is to understand these inputs. The most obvious input is the user input, either that being the controller, or the mouse, or the keyboard. However these are not the only inputs that add randomness to the system.
There are some more things that need to be consider as inputs in order to get to a full deterministic behavior. If your game uses random numbers, the random number generator is an input. You must either log it, or use the same seed as you did in the crash.
If your game queries the system time (of course it does!), then you have another input! We are basically looking for every point that the game engine reaches out of itself and gets data, or it is fed data.
So the inputs are:
- User controller input
- Random number generator
- System time