Writing rules

Why it matters

A game that only works when its designer explains it is not finished. Playtesters, publishers, teammates and eventually players all need rules they can follow without you. Writing rules also exposes holes in the design: if you cannot write down what happens when two effects happen at once, the game does not actually know either. In video games the same skill appears as tutorial text, ability descriptions and design specs that programmers implement.

The core idea: order and consistency

Good rules answer questions in the order a new player asks them:

1. What is this game about and how do I win? (one or two sentences)
2. What is in the box? (components with quantities)
3. How do I set up? (numbered steps)
4. What do I do on my turn? (numbered steps, in order)
5. How does it end? (end condition, scoring, ties)
6. What about special cases? (clarifications, FAQ)
7. Can I check quickly? (a reference summary)

Inside that structure, consistency matters most: one term for one thing. If you call something a "token" in setup and a "coin" later, readers assume they are different.

Writing style that works

• One rule per sentence. Long sentences hide conditions.
• Imperative mood. "Draw two cards." not "Players will generally want to draw some cards."
• Bold key terms the first time they appear and define them.
• Numbers as numerals ("draw 2 cards"), which are easier to scan.
• Say what happens, not what you hope. "If the deck is empty, shuffle the discard pile to form a new deck."
• Examples beat explanations. One concrete example of a turn clears up more than a paragraph of abstract rules.

Worked example: rewriting a confusing rule

First draft:

On your turn you can move and attack if you want, but if you attacked last turn you might not be able to move as far unless you have the boots, and monsters attack back.

Problems: order is unclear, "might" is vague, the boots condition is buried, and "attack back" has no timing.

Rewrite:

Your turn has three steps, in this order:

1. Move up to 3 squares. If you attacked on your previous turn, move up to 2 squares instead (Boots ignore this limit).
2. Attack (optional): choose one monster next to you and roll a die. On 4 or more, it loses 1 health.
3. Monster response: every monster next to you deals 1 damage to you.

Each step is ordered, every condition is explicit and the timing of the monster's attack is clear.

Edge cases and the "what if" pass

After drafting, read every rule and ask "what if...?":

• What if two players reach the goal on the same turn?
• What if a card tells you to draw and the deck is empty?
• What if a number would go below zero?
• What if two effects trigger at the same moment: which goes first?

Every unanswered "what if" becomes an argument at the table, or a bug in code.

The blind test

The only real test of rules is a blind playtest: give the rules to someone new and stay silent while they learn. Note every hesitation and question. Those are not their mistakes; they are places your writing failed. Rewrite and test again with someone else.

Common mistakes

• Writing from memory, not the prototype. Rules drift from what you actually play. Write with the components in front of you.
• Front-loading exceptions. Teach the normal turn first and special cases later.
• Synonyms. "Card", "tile" and "piece" for the same object will confuse readers.
• Missing end and tie rules. Players always ask, usually at the most heated moment.
• Explaining during a blind test. As soon as you speak, the test stops measuring your rules.

Quick recap

• Order rules as players need them: goal, components, setup, turn, end, special cases, reference.
• One term per thing, one rule per sentence, imperative mood, concrete examples.
• Run a "what if" pass for edge cases and simultaneous effects.
• Test with a silent, blind playtest and rewrite where people hesitate.

Try it

Open the Do tab, write a one-page rules sheet and run a blind test with someone new.