I’m currently designing another board game with the same group I made “Sleeper Cell” with, a board game in which you attempt to stop a bomb from destroying a city. So the process of coming up with rules was going a bit slow, so I suggested, “Why don’t we Calvinball it?” I got weird looks all around. So, here, I will go through the process of playing Calvinball.
Oh, and if you’ve never read Calvin & Hobbes, leave my blog and never return.
In terms of game design, I’ve used the Calvinball approach on many occasions, but I actually haven’t since… middle school, probably. I used to in my RPG’s all the time. The simplest form of Calvinball is just to throw out a number and try it. For example, “How many spaces can a player move per turn?” Then comes the argument. “He should move two!” “No! He should only move one!” “You’re all wrong! He should move six!” The Calvinball approach to this would be to just set one of those numbers and stick with it until it needs to be changed.
Then there may be the scenario where you’ve come up with a feature you want to try out. For the sake of trying, Calvinball it in. For example, in the game my group is developing for Brenda’s class, you play as spiders trying to catch other spiders in your webs. Originally, you could shoot the web anywhere on the board. This led to the games going by far too quickly, so I threw out the idea that you could only send out webs radially from where your player token is. This made the game much more strategic, as you could not as easily trap the other spiders right at the beginning of the game.
In order to demonstrate implementation more properly, let’s take a look at a game we all know. Monopoly (sorry Brenda) as a pretty well-known set of rules. But what would happen if we made the game board a bit more dynamic by forcing players to travel to the opposite train station when they landed on one? Well, it would both cut down and increase travel time around the board, depending on which station you landed on. You could potentially play through an entire game and never collect $200 as you pass Go. Or, you could win just by taking the train basically right to Go. Something like this would add another layer onto the game. It’s not much, but remember that every rule you implement affects the ENTIRE game in one way or another.
Try not to Calvinball in too many rules at once. Treat Calvinball like a scientific experiment. Only change one variable at a time so you can keep track of what works and what doesn’t work. Granted, this isn’t “Calvinball” in the truest sense, as true Calvinball never keeps the same rules for more than a minute and can never be played the same way twice. However, for true game design, Calvinball must be used one rule at a time for an entire playthrough, or until the rule fails miserably, whatever comes first. If the rule lasts an entire playthrough, you (and your group) must decide if the rule stays or goes. Never keep in a rule that makes the game unplayable, thinking you can fix it by adding another rule. That’s not Calvinball. Also, figure out when you’re done playing Calvinball before you have too many rules to keep track of.
Calvinball does not exist to fix broken rules in your game. Calvinball exists mainly to experiment with the rules you have currently implemented, or to create a rule based on a loophole in the current ruleset, or even a rule just to generally break the game. Worst case scenario, you take the rule out. Best case scenario? You create a rule that not only works, but makes the game more fun.