Garshasp Development Blog

In the past weeks, a very common sight at Fanafzar was a series of 4 or 5 machines, all running Garshasp on a pre-recorded command sequence (or timedemo, or whatever you might want to call it,) trying to get the game to crash or fire an assertion or behave erratically to help us pinpoint some intermittent or hard to reproduce bug.

First of all, we have a quite cool replay feature in Zorvan (our engine) that lets us record and then play back a game session. It’s not perfect, and not quite fit for end-users, but you wouldn’t imagine how useful it has been (and will be) to us.

This replay system is serving as our unit test (“You added that feature? Let’s see if the boat sequence is playable now.”) and our regression test (“You committed that fix? Let’s see if the game is still playable!!!”) and our performance test and playability test and much more. Since the structure of our game is linear by design, we can get very good coverage with a straightforward replaying of the entire game.

In any case, since we are almost feature-frozen now, our (programmer’s) lives mostly consist of running the game till it crashes (or does something it shouldn’t do) and then tracking down the bug and working it out.

I guess the next step will be finding the few major performance bottlenecks and optimizing them (that we have put off till now because they would have made debugging and adding features quite hard.)

My point in all this was that debugging is usually considered a gruesome and intimidating task, or boring and uninteresting at best. Right now, I quite enjoy debugging our engine and game for two main reasons: first is the replay system (which makes debugging much more effective, targeted and efficient) and second and more important is finding out bugs in my own (and our own) mental processes by finding bugs in the code that resulted from those processes.

It can be illuminating to find out what you had missed when you designed or implemented a piece of code, or the bugs caused by lack of communication or a problem in the general work flow (these are not common, but interesting nonetheless.) This form of revelation that results from finding a bug in your code is quite a rush and can make us better programmers.