Five Commandments of Intuitive Game Rules

This post got spurred by my readthrough of Hillfolk, as I lamented some of the decisions made in explaining the game. I made a bit of a fuss on G+ about it committing a large number of the cardinal sins of rules-writing, so now I'm going to discuss this in a bit more depth. Rules are important to get right, especially with roleplaying games, but the hobby hasn't had a good history of rules that explain themselves well...

A massive challenge for any ruleset is that it has to simultaneously wrestle with being a tutorial and a reference at the same time. It's definitely a daunting challenge, but I've observed that there's a bit of a divergence between the tabletop boardgaming hobby and the roleplaying game hobby. While roleplaying games have remained a bit of a niche, boardgaming has achieved much wider popularity, which means that boardgames have had to make themselves much more user-friendly. Some RPGs have managed to present their rules in a more easily-digestible format (D&D's latest edition succeeds in some of the following rules I lay out), but others remain rather opaque.

So, how do you stop your book from feeling unwieldy, brain-burning, and hostile to newcomers? Read on!

Find Your Core Loop
I put this up front, because this is what most games should have early on! The "core loop" is another way of saying "this is what you do in the game". It should come shortly after more general statements, but before you have to make characters in the game. For example, the core loop in Dungeons and Dragons is: "The DM says what's going on. You tell the DM what you do. The DM might ask you to roll dice; if you roll high enough, things go your way, but otherwise..." (Notably, the D&D 5th Edition quickstart did exactly this! It was nice to see that callout.)

Why is it so important to explain the core loop early? Because the core loop is the foundation that the other rules of the game build on. If you don't understand the core loop, a lot of the other game won't make sense! One mistake that a lot of games make in this regard is putting character creation too early in the game. I've seen games where character creation comes before you explain the mechanics of gameplay! While this works out decently in a game like PrimeTime Adventures (where character creation doesn't really specifically tie into the mechanics of the game), this wouldn't fly in a more complicated game where character creation means picking mechanical features for your character. One game that partially averts this is Ryan Macklin's Mythender: most of the mechanical character creation actually happens during a combat scene, which means that you already have an idea of how the game works.

My preferred example of design that effectively isolates its core loop is Burning Wheel: the first 70 pages of the game explain the rules that are referenced for at least 60% of gameplay, and then it divides the rest of the rules into their own sections, explaining that you can slot them into the core framework as you need them, or else leave them be. (This also ties into something that Vincent Baker refers to as "concentric design", which basically means that if you forget the more detailed rules, you can still fall back on the core loop.)

Do Not Use Extraneous Jargon
Roleplaying games have a lot of jargon, especially as you stray out of the more traditional stuff! I'm not against gaming jargon--but I think that games can overdo it sometimes, to the point where it becomes un-useful. This is where I'll bring up Hillfolk, even though I feel a bit like I'm picking on them. There's a point early in the game where they start referencing something called a "precedence order"...and it's completely indistinguishable from the concept that most other games call a "turn order". It's the order that players frame scenes in. Every time I saw "precedence order", I had to remind myself what that meant.

And that's the crux of the issue: each new piece of jargon is one extra thing that a player needs to learn and keep in their head. Eventually, you internalize the jargon after playing the game and using it correctly, but the more jargon that exists in a game, the steeper the learning curve gets. Use jargon that already matches terms that players are likely to know: Dread uses the term "pull" for when you pull a block from the tower, and Fiasco uses "Act I", "Act II", and "Aftermath" to talk about the story structure of the game.

In other words, you can "cheat" a bit by using knowledge that the players already possess!

Keep Things Concrete
This rule's one I fell afoul of in an early draft of my game Gloaming's Wilds! I had a rather elaborate rule that went more or less as follows: "When the players have beaten a Nemesis a number of times equal to the number of players, begin the endgame." Josh Jordan told me to just use coins: if I give the GM a number of coins equal to the number of players, and the GM loses a coin each time the players beat a Nemesis, I can just say "When the GM runs out of coins, begin the endgame". That's what keeping things concrete means.

Sometimes, it's easy to get caught up in abstract structures, especially when designing for a roleplaying game. We know how we want the mechanisms of the game to interact, but sometimes we forget that we're keeping a lot of mechanisms off of the table. That's a problem, because every bit of the rules that a player has to keep in the air is like another ball that has to be juggled: it makes the whole game harder to understand. When you tie rules to physical, concrete parts of the game, however, it makes the entire thing much easier to manage.

For example, the RPG Microscope makes heavy use of a very elaborate structure, but it also uses index cards to make that structure physically present at the table. This means that its rules can rely on the physical props to help the players understand their context. It also has a nice side effect: because there's so much stuff at the table, players don't have to remember much--they can look back at the table and understand at a glance what's going on in the game. Fiasco has a similar effect when it comes to the relationship cards that you set up in the start of the game.

Close Your Loops
An "open loop" is something that our brains start working on, something that they need to keep in our mind. For example, if a game says "always remember that if you ever roll five dice, mark Corruption", you need to open a loop in your brain to keep track of that rule. Ryan Macklin talks about this in a blog post, although his post is more directed towards practical real-life applications of this understanding. In game rules, every loop that you make a reader open is a potential barrier to entry. If they're simultaneously having to keep four or five things in mind as they read your rules, it's likely to make them give up.

How do open loops show up? Mostly, it's when rules give unanswered questions. This is one reason why, earlier, I talked about putting your core loop early. When part of the game mentions a piece of that core loop, your brain starts wondering "Wait, what are these rules talking about?" and has to bookmark that part of the rules as "once I know what X is, I can go back and reread it and understand it better". Of course, if you explain everything upfront, that's a massive information dump, so the better solution is to give a compromise: an answer that satisfies the questions without having to explain things fully.

It might be as simple as a summary of something ("AC will make you harder to hit"), or using a term that's self-explanatory but takes on more specific meaning later ("Your character's Issue is the main problem that they wrestle with throughout the series", where an Issue also has a mechanical effect, which you find out later). In short, you're giving these loops a place to live, instead of leaving them in a sort of "assignment limbo". If you introduce a concept out of the blue without explaining what it means, I have to keep it constantly in mind until I find it a home in my understanding of the rules.

Organize Types of Rules
Roleplaying games can be a bit more informal than boardgames, and many of them have different sorts of rules. Sure, there's the specific mechanical rules that are always followed, but there's a lot of other rules that act as "best practices", gaming etiquette, house rules, or even standard procedures for the GM to follow. When a game mixes all of these kinds of rules together, it's confusing for the people who are trying to read it. "Wait, so I have to follow all of these rules?" Have a clear hierarchy for your rules: some are essential to follow at all times, others are good ideas, and still others are just general guidelines for how to play.

I'll also suggest that if a game says that "this is how the GM should play this part", you might just want to excise that bit! Give the GM some flexibility to play with, too! If you're saying something like "if the player is Strength X or higher, the GM should choose the Defend action" (I have seen games like this!), you're reducing the GM to an algorithm! Don't do that. It makes the rules more complicated, and although it might show off the optimal strategy to a GM, you shouldn't make them feel like they're bound to one specific course of action. Let them develop their own methodology and rules of thumb for running the game.

Closing Up
The best way to learn rules-writing isn't by following these guidelines, although they can be great sanity checks for your writing. Instead, I'd recommend checking out a couple places. First, play boardgames and card games, and read the rules of those games with an astute eye. Start to look for places where the rules are written intuitively, so that they explain themselves to you. Second, read up on software usability, because that's a field which has grappled extensively with this problem. This article on "recognition vs recall" is a good place to start, and Jakob Nielsen's usability heuristics can be applicable to rules-writing in some ways, especially "flexibility and efficiency of use", "consistency and standards", "recognition over recall", and "match between system and the real world".

It's also never a bad idea to do some reading and study on clear and entertaining writing. Game designer David Sirlin has a fantastic series on clear and effective writing, and Words Fail Me is still my favorite snarky guide to punchy, clear writing.

Of course, the absolute best way to know if your rules are effective is to hand them to people who don't have exposure to any sort of hobby gaming; they're quite good at singling out confusing spots of the game. (That, and if you hesitate at the notion of handing your rules to a neophyte, it's well worth considering which parts of the rules make you hesitate!) I wish you well in all of your designing and writing!