I’m going to talk a little about video game design today, but think there’s a lesson in it for board game design as well.An anecdote that I think about at least once a month:
It’s my senior year at UMich, and I’m one of the apex classes of the computer science program “EECS 494: Computer Game Design & Development”. This was the class I’d been champing at the bit to get into all four years, because this is what I was hoping to do professionally after I graduated. I’d convinced a few of my nerd housemates to take the class with me.
One of our assignments was to develop an “arcade-style” game — simple user interactions, on the level of complexity of 80’s classics like Missile Command, Space Invaders, etc., to get a handle on concepts like ‘event loops’, ‘collision bounds checking’ and all that good stuff. I embarked on a JezzBall clone, and my roommate Josh set about building in the Bust-a-Move/Snood style.
Josh had built some data structure atop an C++ STL container, which he was using to keep track of all the “balloons” in the playfield. It implemented a clever formula for determining when three or more balloons were adjacent and should “pop” to score points for the player. There was just one problem. The code would occasionally glitch, and the data structure would “forget” about some of the balloons on the field. He’d narrowed down the bug such that his code could consistently determine that it had happened, after the fact, and it didn’t seem to cause a crash, or break anything else. Continue reading