3 min read
Featured Blog

Sins of Game Programming #1 - The Callback

This is the first installment of a new blog thread about my personal list of “Do’s and Don’ts” in game engineering.

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.



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.

Latest Jobs


Playa Vista, California
Audio Engineer

Digital Extremes

London, Ontario, Canada
Communications Director

High Moon Studios

Carlsbad, California
Senior Producer

Build a Rocket Boy Games

Edinburgh, Scotland
Lead UI Programmer
More Jobs   


Register for a
Subscribe to
Follow us

Game Developer Account

Game Developer Newsletter


Register for a

Game Developer Account

Gain full access to resources (events, white paper, webinars, reports, etc)
Single sign-on to all Informa products

Subscribe to

Game Developer Newsletter

Get daily Game Developer top stories every morning straight into your inbox

Follow us


Follow us @gamedevdotcom to stay up-to-date with the latest news & insider information about events & more