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.

One major task for the development of the necessary features in the engine which is being worked on currently is the resource management section, as part of the Seamlessness feature which is being added to the game engine. Resources being 3D mesh files, textures, sound files, animation files and etc. The seamlessness design breaks down the world into chunks which will be loaded and unloaded in real time as the player progresses through the levels. This should ideally help out in increasing the rendering performance, memory consumption and general cpu load due to processes related to AI, physics and animation.

This feature needs to connect to the resource management hooks and start getting tested. It will probably be the last major architecturally significant feature we’ve planned for at this stage of development. The most critical resources are related to graphics and we’re currently trying to investigate the mechanisms OGRE provides for handling resources. One major feature which is definitely necessary for this design is the background resource load/unload which OGRE supports in a separate application thread.

Necessary tools to be integrated for Seamlessness and Resource Management are buing built into the level editor (Iranvij) in parallel.

Implementing this feature properly needs great focus from the technical and artistic departments since it affects the processes and main workflows of both.