Make Good Rules

Jay Treat is a really smart designer. If you follow him, interact with him, or attend an UnPub to play his games, you'll quickly agree. He's thoughtful, and direct. I wrote a post about rules writing on my old blog. I intended to update it and improve it for this site, but then Jay sent me his submission and I saw that my work was unnecessary. Read, enjoy, and learn!

Guest Column by: Jay Treat

One of the most common mistakes new designers make is underestimating the importance of rules. Obviously, you made the rules that make the game, but did you write them down? I often forego that step for initial playtests because they’re so primordial at that stage you’re more likely to change everything than not. However, once you've arrived at the point where you basically know what your game is and are just working out the kinks, you absolutely need to sit down and write the rules. This is important, not just because the finished game will need a rulebook, but to help codify the exact wording you want. Details like determining the starting player and tie breakers may not have a big impact on how your game plays, but they do make a difference and you can’t fudge them once your game is shrink-wrapped. You’ll also need to have playtesters learn the game by reading the rules (to make sure they make sense) and you can’t do that if there are no rules for them to read.

I want to take a moment today to walk you through some tips that will help you produce readable, functional, and flawless rules.

Making Rules :: Programming


Establishing the rules for a game is a lot like programming. A lot. It's not enough to know how things are going to go in the ideal situation or the most common situations, you need to understand exactly what will happen in every possible situation -- no matter how unlikely it may be -- and your game can't break under any of them. Every board game has corner cases, but they become exponentially more common as complexity increases. Games like Cosmic Encounter with pieces that trump the rules of the game are littered with combinations that are ambiguous at best. Ambiguous rules cause arguments and very few gamers enjoy real-life confrontation.

While the first stage of playtesting is about finding the fun of the game and making things generally click, the second and third stages are going to require a lot of bug-hunting. Make play choices that seem suboptimal so that you can check previously unseen combinations and verify that the rules don't fall apart. If there are two many permutations to try them all, make a spreadsheet and do the math to make sure scenario 13 and scenario 74 don’t result in an unfinishable game.

Also like programming, syntax can be the devil. Missing a semicolon? Your code may not compile. Got an 'and' where you wanted an 'or'? Players who learn the game from the rules might be learning a different -- hopefully worse -- game. This is another reason you want multiple foreign eyes going over your rules; these kinds of mistakes are usually invisible to their author.

Ad Absurdum

The best way to make sure your game always plays as expected is to test the extremes. If a player can roll all 1's in your dice game and is guaranteed to come in last place, that doesn't just indicate that one in a million games will be an auto-loss, it strongly suggests that many games could be skewed to the point of being unfun. If, on the other hand, there is no combination of luck that can guarantee a loss, perhaps given a particular strategy, then you can be confident that no game in the possible spectrum will be ruined for that reason.

You have to check both extremes too, of course. In particular, watch out for a dominant strategy. If there's any one path a player can take that will always yield the best chance of winning, you can be sure that everyone who figures it out will use it every time and that nobody will be interested in playing again. Similarly, if there’s a strategy that’s guaranteed to lose, no one will ever take it and it’s just adding clutter to your game. Fix it or pitch it.

Every Rule Has an Exception*

You can't break the law. Unless you're a cop, politician, or diplomat. Or unless you don't get caught. Or unless you've accepted the legal repercussions. Once you're in jail, you can't leave before you've served your sentence. Unless you're well-behaved. Or well-connected. Or escape.

As much as every game must have rules, games almost universally are made interesting by the exceptions to those rules. Small World is a great example. Everyone follows the same rules of playing tokens and attacking regions, but what makes the game worth playing are the races and the abilities that break those rules. Exceptions are so central to the identity of rules that you could argue a rule is defined by its exceptions. Games like Magic: the Gathering are so defined by their exceptions, that the exceptions have their own exceptions.

Not sure where to go with your next game project? Make a rule. Ideally, a stifling, prohibitive rule. How much can you build within the constraints of that rule? (Restrictions breed creativity, but that’s a whole other article. Aaand here it is.) Once you’ve reached the limits within that rule, break it. Not completely, of course; you’d lose everything. Just make one little exception. I can’t guarantee this exercise will produce anything fun, but chances are good it will be interesting and the challenge enlightening.

*Except those that don't.

Less Isn’t Worse

It’s entirely natural to keep adding cool new things to your game. A is cool, therefore wouldn't A+B and A+C be even cooler? Whether they are or not, you need to seriously consider whether those additions are needed to make the game fun or if they just add more bulk to the rules and thus length and difficulty to learning the game.

It’s so natural to keep adding more things to your game, that you’re often not even aware of it. You produce your first prototype or your last and say this is the game and nothing extra, but you’ve been playing with parts for so long that they feel inseparable to you, even though they’re not. One of the hardest parts of game design is knowing what to exclude from your game and trimming legitimately fun things away from a working game. But it’s important because the best games are always tight packages, metaphorically, presenting only the bare minimum components and rules needed to enjoy the game and nothing else.

Failing to trim your game into a lean mean fun machine will almost invariably cost you publication because extra parts make the game more expensive, extra rules make the game less accessible, and the combination makes a game no one wants to take a chance on. Can you save these cool bits for an expansion? Tuck them at the bottom of the box with a note that says “don’t open until your fifth game?” Often times, getting the core game published, played, and reviewed gives you the perspective to inform sequels and expansions that will validate some of your excised ideas, mutate others, completely negate the bulk of them, and then add new, better ones. It’s hard to see when you’re cutting your darlings, but in the end, it really is for the best.

Unenforceable Rules

Sometimes a game knowingly includes a rule that's impossible for other players to verify for correctness, and sometimes these tricky situations just sneak in. “Draw two cards, then put one back on the top of your deck.” If you put the cards you drew into your hand, your opponent can’t be sure that the card you put back was part of that pair or had already been in your hand. If you’re not paying attention, you may not even be able to tell.

I love flicking games, but they often involve keeping track of what hit what and considering the number of pieces that can be involved and the speed at which many flicks happen. It’s often highly debatable (if not a complete mystery) whether my piece hit your piece before or after it hit my other piece, or whether it was my other piece that the first knocked into yours. Rules that depend on knowing these things are flawed.

This is actually the biggest problem with the holy grail of simultaneous real-time play. Woe to the new designer who wants to brilliantly eliminate all downtime from her multiplayer games by making them real-time. It is a path fraught with peril. Every game like this that I’ve played requires so much attention to your own area of interest that you’d be lucky to have a passing idea what your immediate neighbors are doing, much less the players further away. That ultimately means it’s up to you to make sure you play correctly. Even if you assume everyone in your game is 100% honorable and would never intentionally cheat, the chances that everyone understands the rules well enough to play without error while things get fast-paced and hairy are usually nil.

You want to avoid ambiguous situations and those that require the honor code whenever possible. Outside of tournaments, the vast majority of players will never cheat. Not only is it wrong, it defeats the joy of besting your pals in a friendly battle of wits. But there are always exceptions. It’s not just the twisted players who take more joy from cheating without being caught than they do from winning. I know people who will break a game just to demonstrate that the game is breakable, with no intention of profiting from it themselves. And when it comes to tournaments where real pride and sometimes real money is on the line, I wouldn’t be surprised if a third of the room would cheat given the opportunity.

Learning a Game
I don’t have any stats, but from my own experience and from my various playgroups, I’d estimate that on average, a player learns ten games by playing with someone who already knows the rules for every one that they buckle down and read the rules themselves. Even if it’s not 10:1, it’s 4:1 at the very bare minimum. The rules for some games have never been read because they’ve never been written -- consider folk games like Charades, Celebrities, Werewolf, Ring around the Rosy, and The Paper Game. Granted, many of these have been published after the fact, but the point stands.

It’s vitally important that your rules are clear enough and readable enough (simple, fun language that isn’t ten pages long) that the first person who reads them understands them well enough to teach them, and it’s equally important that your rules are short and resonant enough to be passed along orally.

A lot of players, particularly the sort I gravitate toward, would prefer to start playing a game as soon as possible and learn the details of the game as we play and make mistakes rather than sit through an entire reading before getting to do anything at all. Consider the possibility of writing the rules to your game in a way that supports this kind of play. It’s not always possible, but it adds a lot of value for the people who enjoy that. Sometimes, it’s as simple as telling the reader the objective, the basic flow of the game (what you’ll be doing and the major mechanics you’ll be using) and how to set up. From there, players can read each step of the game as they get to it. Again, this doesn’t work for every game, but when it does, it’s a beautiful thing.

Intuitive Rules / Game Kinesthetics
A good science fiction story asks its viewer to accept a new reality. It can be anything from, “it’s the future, we can travel faster than light, and there are other humanoid lifeforms with advanced technology” all the way to “everyone’s a different freaky alien, there’s technology that’s basically magic, and a bunch of us have superpowers to boot” and beyond. The viewer accepts that reality, and the power of suspension of disbelief prevents their natural “that’s not real!” instincts from rejecting the experience. It’s very engrossing... until the story breaks its own rules. How many riots would there be if Captain Picard force-lifted Deanna Troi and dropped her down the core shaft? All of them, that’s correct. All the riots.

The point is that whatever absurd reality you create for your game, every single entity must remain as true as possible to that reality. This is what I mean by ‘resonance’ or it will kill the illusion and your players might as well be playing an abstract game with no theme at all. If you’ve got a battle game where everything has a size stat, you can’t give your killer housecat a 3 while your german shepherd has a 2, even if the housecat has laser claws that’ll make it win every time. If you’ve got an Animal House game in which anthropomorphic animals party together, don’t make the spiders more sociable than the pigs. We’ve accepted that cats can have laser claws and that spiders can talk and dance, but we haven’t forgotten that we already know that dogs are bigger than cats and pigs aren’t creepy eight-eyed monsters that eat their own. (Don’t you hate spiders?)

You also need to ensure that playing your game is what it sounds like it will be from the box. Have you ever mistakenly put sugar on your food when you wanted salt? You like sugar, it might not even be a bad combination with your meal, but when you first taste it and it’s not what you were expecting, you’ll spit it out. Sugar is good at being sugar, but it’s terrible at being salt. If your box looks light and silly, don’t give your players a three-hour epic strategy. If your box shows a robotic firefight, don’t make your players trade robot parts in a marketplace. They expect fierce metallic combat.

This extends beyond Box versus High-Level Gameplay all the way down to the individual components. If players find dice in the box, they’re going to want to roll them. If it turns out you’re just using them to count from 1-6, your players will be disappointed. If they open a deck of cards, someone’s going to shuffle it before the person reading the rules can get to “lay the cards out in order” and they’ll be annoyed. If you give them plastic pieces that stack well and never let them stack, expect angry letters. In the ideal situation, your components should be so obvious that players can basically play the game without reading any rules. I’m not saying that’s often achievable, but it is the ideal and you want to get as close to it as you can while preserving the unique fun of your game.

In Summary
Make good rules.


It does seem backwards. I generally write an outline of the rules or maybe a turn sequence for something complex, but for the simpler things, I have the rules "written" they just aren't on paper. :)

Once I have playtested and I know the game isn't broken, I'll generally flesh out that outline and then modify it accordingly after each playtest session... which is part of the reason my rules are so horrible to read.

I really need to think more about this process.

I typically come up with a premise -- usually a setting or a mechanic I want to develop. I think on it, sometimes for an hour (Farmageddon), sometimes for months (Field Marshals). Once I think I have it, I immediately sit down and write the rules.

This answers so many things for me:
1.) What components?
2.) How do players play? What do they do? This helps me identify early problems.
3.) How do I explain the mechanics? This usually helps me simplify things.

Then I build the prototype and test. I constantly update my rules doc as a result and always try to have it in a good state.

Not saying my process is right, just how I do it!

Excellent post! It veered off into other areas of game design for a bit but all points are exceptional. I'm in the process of re-writing the rules to Princess Fairy Rainbow Unicorn dice, and I have been stumped. I can use quite a bit of information from this post. I hate my rules as a general rule and realize that I must get better at it if I want to pursue more contracts....

It seems like it veers, but I honestly believe Rules = Design. In the digital space, we often write design documents before engineers implement them. In the print space, we make prototypes and then at some point write rules. It almost seems backwards (to me, at least!). As rules are THE way players learn your game, I feel they are so fundamental that, even though some of the stuff Jay said isn't specifically about typing the text for the rules document, it's ultimately ABOUT rules.