Testing for a Windows Store release revealed an intermittent crash occurring in the Windows port of Six/Six. The bug was a combination of errors: a mistake entering statistics for a somewhat unimportant non-player character and a failure to check array bounds when determining if an NPC needed an update. I’ll try to explain a bit about how this bug came to be.

Entering objects into the game can be tedious. In this particular case, there is a screen depicting an outdoor yoga class, which required entering eight identical students. The editor, designed specifically for this game, doesn’t have a “duplicate” function (at least not for objects), meaning they were all entered separately. In this particular case, I must have entered the update frequency, which should be 0 since they don’t move, as some absurd number for whatever reason.

If the code were more robust, this error wouldn’t have crashed. Basically, the update frequency is an integer used to check an array of “speeds” of objects that might need to be updated on this pass through the game loop.

Of course, as a micro-optimization, I never wrote any code to check if this update frequency index fell within allowable bounds (0 to 10) because why would I ever enter an update frequency that didn’t fall within these bounds? In this case, on Windows, the frequency checked was 65535, slightly outside the expected limits of 0 to 10, and the game crashed.

The new release implements two fixes: the actual problematic NPC is corrected in the data files and the bounds for updates are now checked. Unsurprisingly, this change did not slow the game down on the Rainbow’s 4.7MHz 8088 processor, meaning that my “optimized” code was worthless in the end. Additionally, I’m sure there are many more spots where this bug could have cropped up if I had just fixed the NPC and never implemented bounds checking.