Sins of Game Programming #1 - The Callback

From the very first line of code a software engineer writes he or she starts to develop their personal “Do’s and Don’ts” list, even if they are never written down they have a tremendous effect upon how we design and program our games. The list evolves and changes over time, we add to it, delete items from it and re-evaluate others. Experience is the driving force behind a lot of the changes, in short we make a mistake, we learn from it.

It is worth mentioning that if you did write down a list of “Do’s and Don’ts” it would look very similar to a projects “Coding Standards”, that’s fair enough, nothing wrong with that at all, but I’m going to try and steer clear of the coding standards discussion for now.

“The Sins of Game Programming”, is a much more interesting way of saying, these are some of my “Do’s and Don’ts” with some recollections of how and why they came to be on my list.

Enjoy. 

The Callback

The callback, an exceedingly useful mechanism used to pass information between different systems. The following experience is the reason why I now advocate that game callbacks should only record information, never act upon it, deal with the consequences of the callback in the main game loop.

The time had come in the project where processing was starting to get a little tight, and one of the task’s that I hadn’t got round to doing was flicking the switch on the physics simulation from single-threaded to multi-threaded. So one morning I made the required modifications, played through a few levels everything looked great, it was playing exactly as it should, so I submitted the change to the projects source control. The following day, the chap working on the boss levels told me that he was getting constant crashes in his physics callbacks. It didn’t take long to figure out what the problem was when I saw what he was doing inside his collision callback:

On Collision Callback

Calculate point of contact.

Start visual effect at contact point.

Start sound effect at contact point.

If contact was with a character

   Subtract health from character.

   Initialize animation system to play hit animation.

   If character is player.

      Update GUI with new health value.

   If character is dead.

      Change character state to dead.

      If character is player.

         Initialize player death sequence.

...

Suffices to say the callback function was 6 or 7 pages in length and touched on many sub-systems both to initialize and setup various outcomes from the collision. The problem in a nutshell is that the callback is not thread safe, it touches so many pieces of data with no thought that other threads might also be accessing that information. Unfortunately a little digging revealed that this was not the only physics callback that was doing large amounts of processing in a callback. Regrettably the amount of work required to fix the callbacks was more than we had time for so the end solution was to make the physics simulation single threaded again.

In truth, the root of this problem and what I consider another sin was that I hadn’t turned on multi-threaded physics simulation from the beginning.