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.
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.
He spent an entire weekend sifting through code in the debugger in an attempt to determine the cause, but to no avail. He thought he was totally stuck, and was afraid he would have to rebuild the whole thing from scratch.
Since this was college, and floating around the house, room to room, with your housemates is just what you do, my other housemate Dennis (not enrolled in EECS 494) and I were just loitering in Josh’s room one evening as he fought with the debugger. After a few near-misses at catching the problem in the act, Dennis tossed out: “Well, if you can tell when it happens, why not just run with it? Throw the word BONUS! on the screen or something and just stop drawing the ones that are missing.”
For a moment, Josh visibly wrestled with the sunk costs of the time he’d spent trying to fix it. I called total bullshit, and may have even used the term “cheating”, though witness accounts vary. But Josh quickly came to what was to be the right conclusion: he implemented the new BONUS feature. He included a little animation to make it look like the word, and some spare balloons were flying out of the screen at the player, which also served to obscure the board for a moment while he re-rendered the playfield with just the balloons he still knew about. It was rad as fuck. It provided a totally unearned dopamine hit for the player, and looked really cool, to boot. We turned our projects in, and a week or so later, Josh went charging through the house waving his grading sheet in victory. The BONUS! feature ended up being the professor’s favorite part of the game, and really differentiated it from several other Snood clones from other classmates.
My takeaway from this is that, when a game is aiming to optimize primarily for fun, it rarely pays to maintain a strict adherence to orthodoxy in the simulation; technical limitations, odd edge cases, or mistakes can often be brought into the fold thematically in a fun way. This can be a boon for the sanity of designers/developers, if you find yourself banging your head against the table trying to make something work, and there’s a good chance that when done right, will delight your players.
[1] This image is from a computer graphics class, not the games class, but this frame was titled “494.bmp” on my hard drive, so it turned up while looking for an image for this post… an odd coincidence since this is a project I worked on with Josh, and this frame also happens to have his face in it. Weird.