How to use this handbook

This is a working reference, not a book to read once. It is organised so you can:

• Read it front to back while writing your first rulebook.
• Jump to Part VII if you want the templates and just need to start typing.
• Use Chapter 16 as a checklist during your final production pass.
• Trace any claim — every recommendation here comes from a named source in the appendix, and the companion spreadsheet (Rulebook_Research_Database.xlsx) carries a clickable URL for each one.

Where this material comes from

This handbook synthesises 106 primary sources: BoardGameGeek forum threads, geeklists and blogs on rulebook design and criticism; publisher and designer writing from Stonemaier Games, Resonym, Leder Games and Fantasy Flight; professional style guides — principally Michael "Curby" Lee's Board Game Editing Style Guide (~13,000 words, CC-BY-NC-SA) and the Stonemaier Games Style Guide; interviews with career rules editors including Paul Grogan of Gaming Rules!; and accessibility guidance derived from WCAG and dyslexia typography practice.

Two honest limitations. First, this is targeted research, not an exhaustive crawl — BoardGameGeek hosts millions of posts and offers no bulk export, so threads were selected by relevance across roughly 2007–2026, weighted towards 2019–2026. Second, community opinion is opinion. Several games appear in both the "praised" and the "criticised" chapters, because reasonable, experienced people disagree about them.

The single most useful sentence in the entire corpus is Michael Lee's: "If someone can't learn the game, they won't play the game." Everything else in this handbook is a technique for making that sentence untrue about your game.

---

Part I — Foundations

1. Why the rulebook is not paperwork

1.1 The rulebook is the game

Strip the rulebook out of the box and what remains is a set of tokens. Attractive tokens, perhaps, but not a game. The rules are the only thing that converts components into the specific experience a designer built. Punchboard puts it plainly: "Without the rules, all you're left with is a box full of tokens and pieces."

There is a second, less obvious reason the rulebook carries disproportionate weight. Board games have no shared interface. Every video game has a controller and a screen; every website has a browser. Board games have nothing in common except the manual. That makes rulebooks the one universal surface of the hobby — and, as accessibility writer Michael Heron observes, its one universal point of inaccessibility.

1.2 The commercial case

A bad rulebook is not a cosmetic problem. It is a business risk with documented casualties.

• A professional editor names games killed by their rulebooks. Paul Grogan — who has edited roughly a hundred rulebooks, including Vital Lacerda's heaviest designs — was asked directly whether a poor rulebook has ever damaged a game's success. His answer: "There are a number of examples of how a poor rulebook killed a game. First Martians, Batman Gotham City Chronicles, and many more."
• Awards juries now reject games over rulebooks. The Spiel des Jahres jury issued a public statement that it had ruled out otherwise-strong games purely on rulebook quality: "We jury members no longer wish to see ourselves in the role of beta-testers for rulebooks, which are only made adequate on the second printing run."
• Buyers filter on it. BGG users state directly that they are less likely to buy a game when reviews complain about the rules, and reviewers defend covering rulebooks on the grounds that a game you cannot learn is a game you cannot evaluate: "How can you even tell the gameplay is good without at least a decent rulebook telling you how to play the game?"
• It is an accessibility gate. One player's response in the 1 Player Guild thread is worth keeping on your desk: "My eyes aren't great. If a rulebook doesn't have a readable layout, a clear hierarchy of information, adequate diagrams and an index, then it's useless to me. If I can't find another way to learn the game, I won't be able to play it."

1.3 The counter-argument, taken seriously

You will also meet the opposite view, and it deserves a hearing. A long BGG thread titled "Rulebooks and text comprehension: a history of misunderstandings" argues that many complaints are reading failures, not writing failures: the answer really was on page 14, in the appendix, and the reader skimmed. The author — a 50-year hobbyist and former rules proofreader — points out how often a rules question is answered with a verbatim quote from the rulebook and an "Oh, sorry, I missed that."

Both things are true at once, and the practical conclusion is uncomfortable but useful:

You do not get to design for the reader you wish you had. Some of your readers will skim, will read at night, will read in a second language, will read while three friends wait. A rulebook that only works for the careful reader is a rulebook that works for a minority of your customers.

Two corollaries follow, and both shape everything in Part III:

1. Repeated questions about the same rule are data. As one designer put it: "If you look through the rule queries on a game's page on BGG you will see the same rules being queried over and over. That tells you the rulebook is unclear on that rule."
2. Absence of complaint is invisible. Nobody starts a thread to say the rules were fine. Rules-forum volume is a biased sample; treat it as a signal, not a verdict.

2. Who you are actually writing for

2.1 Three readers, one document

A rulebook serves at least three distinct readers, and they want opposite things.

Reader	Situation	What they need
The learner	Box just opened, has never seen the game	Linear teaching, context before detail, worked examples, a setup diagram
The player mid-game	Three friends waiting, one specific question	Random access: index, headings where they'd look, a back-cover summary
The returner	Played it once, six months ago	A fast refresher: turn flow, setup quantities, commonly missed rules

Curby's style guide extends the list further — the teacher preparing to teach a group, the veteran checking what changed in a revised edition, the reader who only wants the setup diagram — and the point is the same. "A single reader might have different goals every time they pick up the rulebook."

2.2 Most people never learn from your rulebook

This is the most clarifying fact in the corpus, and it should change how you write:

"In practice, most people don't learn board games from rulebooks or videos, but by having another player teach them. The purpose of the rulebook is to get the chain reaction started and to answer questions that come up during play."

Your rulebook has two jobs, and neither is quite "teach everybody how to play":

1. Enable one person to become the teacher. That person will read it carefully, then stand up and explain your game to three people who have not read anything. Write the book so that reading it produces a teach, not just a comprehension.
2. Answer questions fast, mid-game, under social pressure. This is a retrieval problem, and it is the job most rulebooks fail.

2.3 Define your audience before you write a word

You cannot serve everyone equally. Designer J C Lawrence states the hard version: "Know your audience. If your audience does not include light players learning the game, then there is no need to address or support them in your rules. Write your rules to the audience you care about."

BA Games gives the humane counterweight: you genuinely cannot be everything to everyone, so lean on industry conventions — the shapes readers already expect — and spend your originality budget on the game, not the rulebook's structure.

Write down, in one sentence, who your reader is. Example: "A hobbyist who owns 40 games, reading alone at 11pm, who will teach three non-gamers on Saturday." Every later decision — jargon level, example density, page count — resolves against that sentence.

3. The one principle everything reduces to

3.1 Cognitive load

Michael Lee's entire 13,000-word style guide condenses to one line: rulebooks should minimise cognitive load — the effort required to learn the game and remember the rules. Every choice you make should serve that maxim, "even if it goes against the advice in this guide."

That last clause matters. There is no rule in this handbook worth following when following it makes your specific rulebook harder to use. Style guides are not correctness; they are defaults that usually reduce effort.

3.2 Three skills worth deliberately developing

Curby names three skills as the ones editors should practise over years. They are the highest-leverage things in the craft:

1. Framing — introduce the mental model before the rule that operates inside it. (Chapter 6)
2. Templating — things that work the same should look the same. (Chapter 7)
3. Cognitive load management — the meta-skill that judges the other two.

3.3 A usable quality metric

Rulebook enthusiast Ryan Migalla proposed a test that has since been widely quoted:

"A rulebook should only have to be read through once, linearly, to understand the game. I rate rulebooks by how much I have to jump around or how many times undefined concepts pop up."

It is not a complete measure — it says nothing about mid-game retrieval — but as a single number it is remarkably discriminating. Count, on a first read of your own draft: how many times did you have to flip forward, and how many terms appeared before they were defined? Both numbers should be zero or close to it.

---

Part II — Architecture

4. The anatomy of a rulebook

4.1 The canonical order

Ten independent authorities in the research produced ten section orders. They differ at the edges and agree almost perfectly in the middle. Synthesised, the consensus order is:

1. Cover — game name, player count, play time, suggested age.
2. Thematic introduction — one paragraph. Establishes the fiction and the game's nouns.
3. Goal of the game / how you win — stated before the detailed rules.
4. Component list, illustrated — a picture and a name for every item, with counts.
5. Setup — numbered steps plus a labelled diagram of the finished table state.
6. Gameplay overview — the shape of a round or turn, in bullets, no detail.
7. Detailed gameplay — each phase, action or step, in the order it occurs.
8. End-game trigger — what causes the game to end, and what happens after the trigger.
9. Scoring and winning — including tie-breakers.
10. Appendix / card notes / FAQ — clarifications and edge cases.
11. Glossary and/or index.
12. Back cover — turn flow, icon key, setup summary. The most valuable page in the book.

The underlying logic, in Curby's phrasing, is that a rulebook builds a lexicon and then spends it. Theme introduces the nouns; the goal introduces the mechanically important abstractions (Victory Points, Influence); the component list introduces the physical names; setup introduces the zones (Draw Deck, Market Row). Only then can gameplay use all of those words without stopping to explain them.

4.2 Ten templates, side by side

Source	Section order
Stonemaier Games	Overview & goal → Components → Setup → Gameplay overview → Detailed gameplay → Other info → End of game → (last page) icon guide / game flow / index
Curby Style Guide	Thematic intro → Goal → Components → Setup → Gameplay overview → Round structure → Turn structure → Details → End-game trigger → Scoring → Card notes/FAQ → Worldbuilding → Glossary → Credits → Index → Quick reference
Resonym	Story → Goal → Game End → Components → Setup → Gameplay → Ending the game
Rules Writing 101 (BGG)	Title → Catchphrase → Game info → Overview → TOC → Components → Victory condition → Component breakdown → Glossary → Setup → Game end → Turn summary → Detailed turn → Additional rules → Examples
Meeple Mountain	Thematic intro → Objective → Components → Setup → How to read components → First player → Typical turn → Special actions → Examples → Endgame/scoring → Appendix → Glossary → FAQ → Version
Wargame convention	Intro → Components → Key concepts (stacking/ZOC/supply) → Activation → Movement → Combat → Political → Special → Victory → Optional/advanced
Shellhead (TWBG)	Intro → Components → Victory condition → Setup → Phases of turn → Optional rules → 2-turn example of play → Glossary → Back cover summary
Teaching order (BGG)	Theme (1–2 sentences) → Win condition & end trigger → Big-picture flow → Details

Note how many put the goal before the details and how few put setup first.

4.3 Three orderings that are usually wrong

Do not open with setup. A veteran teacher's objection in the comprehension thread is the clearest statement of the problem:

"A typical rulebook begins with set-up. Please don't do that. I don't know what those pieces are, why I'm separating out piles, I have no context. Tell me theme, goal, basic overview, then details. Think about how you would tell a story. You wouldn't jump into minutiae before familiarising the listener, would you?"

Do not bury the win condition. Herc du Preez places Victory Condition ahead of the rules deliberately: "This allows the rules reader to keep the end goal in mind while reading through the rest of the rules. Having the goal in mind gives context to all actions. The goal is the game."

Do not follow temporal order slavishly. In some games, understanding phase 8 makes phases 1–7 make sense. The Dune example from BGG: combat happens near the end of the round, but the auction and spice phases only become intelligible once you know what cards and spice are for. The book should follow conceptual order of assimilation, not the clock.

Jamey Stegmaier confirms this is normal professional practice: asked how open he is to changing section order when the game demands it, he answered "Of course! I did this for Vantage, and I've done it for other rulebooks."

4.4 Length is a message

"I try to construct rulebooks in such a way that their length is indicative of the complexity of the game, using other components to assist." — Jamey Stegmaier

When he rewrote the Tokaido Duo rulebook, he pulled the character instructions out into two player aids: more useful during play, and more honest about the game's actual weight. A thick rulebook on a light game tells buyers the wrong thing before they read a word.

Two related smells from the same source, both worth adopting verbatim as editorial rules:

• "If I ever need a full page to explain a minor concept, that's a good sign that the concept is too complex for what it contributes to the game."
• "In 99% of cases, if I use the word 'exception' in the rulebook, it's a sign of something that will be difficult for players to remember and should be removed from the gameplay."

The rulebook is, among other things, a complexity meter for the design. When writing it hurts in a specific place, that place is usually a design problem, not a writing problem.

5. Choosing your architecture

5.1 The central tension

This is named independently by at least three professionals as the hardest problem in the craft:

"The single biggest challenge in writing rulebooks is that players always need them to be two things at once: a quickstart guide for new players learning the game, and a logically organised reference for experienced players with a specific question." — Resonym

One BGG writer goes further: "Trying to make a well-written rulebook that has the dual purpose of teaching you the game and serving as a reference is a self-defeating endeavour."

Teaching wants play order and progressive disclosure. Reference wants subject grouping and alphabetical access. You cannot fully have both in one linear document. What you can do is pick an architecture that puts the compromise where it hurts least.

5.2 Five architectures

A. Single book, teaching order (light to mid-weight)

The default. Under roughly four pages, marc lecours' rule applies: "present the game as you would teach the game. Each rule is explained in the order that it comes up." Add a back-cover summary and you are done.

Good for: family and gateway games, fillers, most 30–60 minute designs. Fails when: the game generates enough edge cases that mid-game look-up becomes frequent.

B. Single book, subject grouping + index (heavy)

Over ~20 pages, the same source flips the advice: "the important part is to group rules by subject so that it is easy to find a rule fast. My favourite long reference rulebooks have the rules organised alphabetically instead of the order you learn them. A large index is an acceptable plan B."

Wargames work despite their length precisely because they use a predictable conventional order: intro, components, key concepts, activation, movement, combat, special rules, victory, optional rules. Readers navigate by convention.

Good for: wargames, heavy simulation, anything with a large rules surface. Fails when: first-time learners have no on-ramp.

C. Dual document: Learn to Play + Rules Reference

Popularised by Fantasy Flight (Marvel Champions, Arkham Horror LCG) and widely praised on BGG: "a really condensed rule book to get you started quickly, and for everything else there's an extensive rules reference book with a detailed index which lets you usually find anything you need in seconds."

The two books have genuinely different structures. Book 1 tells the story of playing the game, in play order, and may deliberately omit rare cases. Book 2 is formal, alphabetical or subject-indexed, and complete. Computer manuals have shipped this exact pair for decades.

The failure mode is specific and severe. If a rule exists in the Learn to Play book but is missing from the Reference, the Reference stops being trustworthy — and once players stop trusting it, they stop using it. This was documented in detail for Gloomhaven: Jaws of the Lion, where the ten-Curse deck limit appeared only in the tutorial book:

"I feel like every rule should be every place you would expect it to be in the Glossary — or at least with 'for more, see [entry]' designations like FFG Rules Reference books — or else the Glossary stops being very useful."

Rule: if you ship two books, the reference must be a superset, never a subset.

D. Playbook / walkthrough (heavy games with a teaching problem)

A separate booklet walks players through a scripted opening. GMT's COIN series pioneered it in wargames; Root brought it to the mainstream.

Root ships a walkthrough that sets up a specific four-player position, passes the book around, and has each player read their moves aloud. Punchboard credits this directly for the game's commercial reach: "I believe that the Root walkthrough book was instrumental in helping make the game the success that it is."

Fog of Love uses a clever variant: the rules instruct players not to shuffle the decks on their first play, so the quickstart guide knows exactly which cards each player holds and can walk them through real decisions.

The wargame convention is even more explicit — some rulebooks open with: "Stop. Read the playbook and play through using the physical game. Then use the rule book as reference."

Good for: heavy or unusual games where the first 20 minutes are the barrier. Cost: an extra booklet, and the reference must still be complete.

E. Tutorial rulebook / progressive disclosure

Rules are introduced scenario by scenario (Gloomhaven: Jaws of the Lion, Avalon Hill's old "Programmed Instruction", legacy games with rule stickers).

This teaches beautifully and references terribly. The complaint is consistent:

"The board game had the approach of teaching the rules a bit at a time as you played. I hated the experience. You would encounter new rules in odd little places. BUT it was difficult to look up rules. If I hadn't played the game in over a month, I could not remember where to find a certain rule."

Rule: if you tutorialise, you owe the player a separate, completely-organised reference. A tutorial without a reference is a debt you are asking the player to carry.

5.3 Why board games cannot simply copy video game tutorials

Designers coming from video games consistently expect to replace the rulebook with a tutorial, and consistently discover they cannot. The reasons, drawn from a long thread started by a professional video game developer:

• Software enforces its own rules; a board game's players must enforce them. In a video game you can learn by experiment because the machine will not let you cheat. In a board game, a rule nobody knows is a rule that does not exist.
• Mixed-experience tables make mandatory tutorials socially unworkable. "If some people have already played a dozen times but one player is new, and the only way for them to learn is a tutorial, that's very boring for the experienced players. It is socially important for the new guy to be able to jump into a full game."
• Board game discovery runs in the opposite direction. "In a board game if I see element X and Y and want to combine them to do Z then I want, and need, to be able to look up how Z works from day one. In a digital game I don't need to worry about it until the first time I'm holding X near Y and Z happens."

The useful transfer from video games is not the tutorial. It is pacing: introduce mechanisms in an order the player can absorb, and let early scenarios do work that a wall of text cannot.

5.4 Video, apps and digital rules

Roughly a third of the corpus is players saying they watch a how-to-play video before or instead of reading. That is real, and it is not a reason to write less.

Curby's position is the professional consensus:

"Digital rulebooks should not replace printed rulebooks, because many players will not have appropriate access to the Internet, tablets, or colour printers. The rulebook included with the game should be able to stand on its own as a complete resource for learning the game."

Practical guidance:

• Ship a searchable PDF. Players use Ctrl-F as the index you did not print. Multiple BGG users describe downloading the PDF specifically to text-search it.
• Hyperlink the PDF's cross-references and bookmark its sections. Page-flipping is worse in a PDF than on paper if the file is not bookmarked.
• Maintain a public living-rules page with a dated changelog for errata.
• Do not let blind testers use your video. Meeple Mountain is explicit: not all future owners will have immediate internet access, and the video will paper over rulebook defects you need to see.

---

Part III — Craft

6. Writing the sentences

6.1 Framing: the highest-leverage editing skill

Framing is the mental model the reader uses to understand a new concept. It operates at two scales: the order of sections (Chapter 4) and the construction of individual sentences.

The technique: when a rule is confusing, do not add words to it. Change what it is about.

Example 1 — a dice-drafting game.

• Before: "Take 1 of each type of resource you roll."
• After: "For each type of resource you roll, take 1 die of that type."

The original frames the rule around the player taking dice, which leaves room for two misreadings (take all the dice; take several of one type). The revision frames it around resource types, considered one at a time. The ambiguity disappears without a single clarifying clause.

Example 2 — a bag-building spell game.

• Before: "Each player draws one random Mana Token from their bag for each of their Spells in random order. A player cannot decide on which Spell to place the Mana Token after seeing the Token. However they can choose to not place it at all and return it to their bag."
• After: "For each Spell, its player draws a random Mana Token from their bag and places it on that Spell. The Token cannot be placed on a different Spell once drawn, but it can be returned to their bag instead of being placed on that Spell."

The revision establishes the Spell as the frame, then shifts to the Token and what may be done with it. Same rules, far less room to misread.

6.2 Conditions before effects

Put the trigger or condition first, then the effect.

Weaker	Stronger
Each Army receives an additional Army Token at the beginning of each round.	At the beginning of each round, each Army receives an additional Army Token.
Draw a card if you roll a 5 or higher.	If you roll a 5 or higher, draw a card.

Two benefits. Skimmers can skip an effect whose condition is unmet without reading it. And readers make fewer timing errors — applying an effect at the wrong moment. Put the failure branch in its own sentence: "If you roll a 5 or higher, draw a card. Otherwise, take 2 damage."

The exception: when the context is already established, leading with the effect reads more smoothly. Under a heading Ending the Game, "The game ends when a total of 7 Monuments have been built" is fine — a reader who stops early only discovers something they already knew.

6.3 Sentences

A lawyer who explains complex statutes for a living gave BGG eight rules for rulebook writing. They hold up:

1. Lists and bullets are your best friends.
2. Headers and sub-headers are also your friends.
3. Use short sentences. When in doubt, make your sentence shorter. Or make a list.
4. Use active voice.
5. Put the most important clause of your sentence first.
6. Use lots of empty space. Walls of text overwhelm people.
7. Tell people what they should do rather than what they shouldn't.
8. Use an appendix for special circumstances.

To which Entro Games adds the single best practical test in the corpus — the one-breath rule: "You need to be able to speak each sentence in the rulebook in one breath. If you can't, it's probably too long."

And split any sentence that describes two actions:

• Before: "Choose one area of the Spaceship (Bridge, Cargo, Engineering, or Quarters) and add a number of damage tokens equal to the difference between its Armor and the weapon's Damage."
• After: "Choose one area of the Spaceship (Bridge, Cargo, Engineering, or Quarters). In that area, add a number of damage tokens equal to the difference between its Armor and the weapon's Damage."

The first sentence frames; the second acts. The pause between them is doing real work.

6.4 Voice and person

Talk to the player. Stonemaier's house style: "I write rulebooks as if I'm talking to you. 'Pay $1 to gain 2 resources', not 'The player pays $1 to gain 2 resources.'"

Second person is also shorter, which matters enormously on cards and player mats.

Choose second or third person and be consistent within a context. Third person suits multiplayer descriptions ("Each player reveals 1 card from their hand"); second person suits setup instructions (usually performed by one person) and solo rules. Mixing them randomly within a paragraph is the defect; using them for different purposes is fine.

Use active voice by default — but know the one place passive earns its keep. Compare:

• "Players may not remove mountain tiles from the map." — only addresses player actions. Could some effect remove them?
• "Mountain tiles cannot be removed from the map." — closes the question.

6.5 The modal verbs are load-bearing

This is the vocabulary that carries your rules' legal force. Curby's canonical breakdown:

Word	Means	Example
may	Optional action the player chooses	During the Encounter Phase, the active player may play an Encounter Card.
may not	Forbidden, though the player might want to	Players may not activate abilities during the Equip Phase.
cannot	Physically impossible in the game state	If the active player cannot play a card...
must	Compelled — use sparingly	...they must draw a card instead.
should	Avoid entirely in rules text	Reserve for a "Tips and Tricks" section only.

All rules are requirements by default, so must should be reserved for actions a player would rather avoid. Stonemaier's editing pass is blunt about this: "Remove all instances of 'should' and highlight any instances of 'except' and 'remember.'" Those last two are design cues — except flags an exception worth removing, remember flags something the game's interface should be reminding the player of instead.

6.6 Vocabulary that carries meaning

Several word pairs quietly communicate mechanical information. Use them deliberately.

Distinction	Rule
gain / take / give / earn	gain = from an unlimited supply. take = from a limited supply, or from another player. give = grant to another player. earn = generic. The choice silently tells the reader whether the action affects opponents.
each / every / all	each applies individually to distinct members; every and all treat the group as a unit. Misuse silently changes whether an effect resolves once or N times.
when / whenever / if / at	when = once, at a predictable time. whenever = repeatable, several causes. if = might never happen. at = focuses on a point in time. Using when for something that may never occur implies to the reader that it will.
less / fewer / more	less for singular nouns, fewer for plural. This handles distance, time and money elegantly ("less than 1000 Greeblots").
greater/less than vs higher/lower	greater than / less than for comparing numbers; higher / lower for dice results. Both piggyback on vocabulary readers already own.
opponent vs enemy	opponent for human players; enemy for factions and non-player characters. "Enemy" carries stronger negative connotations than you want at a friendly table.
action / ability / effect	action = a broad player choice. ability = attached to an entity, usually player-controlled and beneficial. effect = automatic or continuous, often outside player control and often negative.

6.7 Turn, round, phase, step

Fix your time hierarchy on page one and never overload a level:

• Turn — one player acts.
• Round — one turn per player, consecutive or simultaneous.
• Act / epoch / season / year — a group of rounds, if you need one.
• Phase — a named subdivision of a turn or of a round (pick one; do not use it for both).
• Step — a subdivision of a phase, for complex games.

Be aware of the tradition clash: wargames traditionally use Turn as the big unit divided into Player Turns, the inverse of modern eurogame usage. Whichever you choose, define it explicitly. As one designer noted, Turn and Round "could easily be used either way and still make sense" — which is exactly why the reader needs to be told.

6.8 Small words with big effects

Delete "simply." It adds a word, adds no information, and reads as condescension to a reader who is in fact confused. This correction happened live inside the BGG Rules Writing 101 thread and the author edited his post:

"In the actual rules, 'simply' can come off in a weird condescending tone and add complexity. It's also one more word to get in the way when skimming a rule book."

Hyphenate face-up and face-down consistently. Strict grammar says hyphenate only as a pre-noun adjective, but editor Andy Van Zandt makes a compelling practical case: "You will see this when you blind playtest rules and someone reading them aloud hits 'faceup' and stumbles while they pause to wrap their head around the word." Worse, face up also means "to confront" and face down means "to endure", and "Flip the top card of each deck face down under it" can genuinely be misparsed. The hyphen glues the pair together and removes the ambiguity.

Consider "dice" as both singular and plural. Die collides with the verb "to die", which shows up constantly in game contexts. Consistency matters more than which you pick.

Use singular "they" — and know when to replace it. Never he, she, (s)he, s/he, he or she or him or her. But watch for the binding problem raised in the style-guide thread:

• Ambiguous: "If a player has no Scientists, they may not research Technologies." (Does "they" mean the player or the Scientists?)
• Fixed: "If a player has no Scientists, that player may not research Technologies."

The fix costs one word and removes the ambiguity entirely.

Parentheses clarify; they never introduce rules. A parenthetical must be removable without losing information. The same is true of examples and captions — see the failure taxonomy in Chapter 15.

7. Terminology, keywords and templating

7.1 One concept, one word, forever

If there were one sentence to tattoo on a designer, it is Cardboard Edison's:

"Consistency in language is one of those small things that makes games so much easier to play. Refer to the same actions, components, and game sections by the same terms every time in rules, card text, reference materials, etc."

The prose instinct to vary your word choice is exactly wrong here. If it is an Attack, it is never a Strike or an Assault. If they are Victory Points, they are never Prestige Points. If it is combat, it is not also a battle and a fight. Russ's version on BGG: "don't use gratuitous synonyms."

7.2 The sharper version: consistency and deliberate inconsistency

Curby's formulation is the most useful sentence in his guide after the cognitive-load maxim:

Things should look and sound the same only if they are the same, and they should look and sound different only if they are different.

Consistency is not the goal — signalling is. When players trust that similar wording means similar behaviour, they can spot a genuine difference instantly. Which means deliberate inconsistency is also a tool: if two abilities behave differently, word them differently enough that nobody has to hunt for the difference.

7.3 Templating

Templating is a syntactic framework for writing similar rules across many components. Consider two cards that both draw a card:

Card A	Card B
Draw a card into your hand.	Take 1 card from the deck.

These mean the same thing, and the difference in wording forces every player to study both texts looking for a distinction that does not exist. That effort is pure waste — and worse, it teaches players that wording differences are meaningless, so they will miss a real one later.

Templating covers punctuation and symbols too. Three cost-and-effect notations in one game:

Spend 3: draw · 2 ➜ attack · {Pay 5} activate

One may argue about which is best. It does not matter: "Consistent application of even the worst form would still be better than using a chaotic mix of all three."

And templating is where deliberate inconsistency pays. Two ability triggers:

• When Played: Gain 1 food resource from the supply.
• When Activated: Draw 2 new bonus cards and discard one.

Both start with "When", so a skimming player has to read three words in before the triggers diverge. Changing the second to If Activated: both fixes the when/if distinction and lets the eye discriminate at the first character.

Magic: The Gathering is the reference implementation here, and for a structural reason worth noting: because most of MTG's rules live on components rather than in a book, it was forced to develop strict templating early.

7.4 Naming things so they cannot be confused

• Avoid confusable pairs. Two commerce roles should not be "Traders" and "Merchants". Find the real distinction and name it. If you cannot find one, that is evidence they should be a single role.
• Prefer keywords that start with different letters, especially for headings at the same level — a skimming reader navigates by first letters. "Shipyards" and "Shipbuilding" as sibling headings is a small daily tax on every reader.
• Keep the keyword count low. Dominion's power is that it has almost none: Action, Buy, Gain, Card. Used with total consistency, brand-new cards remain parseable at a glance. I Slay the Dragon: "No one wants to learn a language to learn a new game."
• Piggyback on what players already know. Mark Rosewater's term for using pre-existing knowledge to front-load information. A Flying character is understood instantly; a character with the Aether Jaunt ability is not, even if they are mechanically identical. Weigh the thematic gain against the memory cost — and never reuse a familiar word for an unfamiliar concept.
• Distinguish mats from boards. A mat belongs to one player; a board is shared. One reader reported this single line from the Stonemaier style guide immediately fixed a naming problem they had been circling for weeks.

7.5 Capitalisation is a budget

Capitals grab attention — which means every capitalised word spends some of the reader's finite attention, and attention lingers on them while reading.

The balanced method: capitalise only instances that refer to a specific in-game component, action or value.

• "Gain 5 Gold from the central supply." / "The active player enters their Attack Phase."
• "Each player keeps their gold in the labelled region of their player mat." / "After the active player declares their attack..."

The side effect is useful: capitalisation ends up marking the instances with direct mechanical consequence.

Resonym's warning is the counterweight: "You can capitalise some keywords and phrases, but don't go overboard. If you have too much capitalisation, it all blends together and is useless."

7.6 Fix a canonical order

If your game has three resources, decide their order once — say labour, stone, wood — and use it in the component list, the setup diagram, every printed cost, every card, and even in the list of regions that produce them. This is invisible when you do it and quietly exhausting for the reader when you do not.

7.7 Write your style guide before you write your rules

This is the cheapest quality intervention available, and it is Stonemaier's explicit headline recommendation:

"The core recommendation I'm trying to make today is that you have a written style guide. It may be vastly different than the Stonemaier style guide — we can still be friends even if you don't believe in the serial comma."

It does not need to be a document. Entro Games keeps theirs on a dry-erase board. What matters is that when you sit down after two weeks away, the decisions are recorded and you do not silently re-decide them. A starter template is in Chapter 17.

8. Examples and diagrams

8.1 Examples exist to resolve ambiguity, not to demonstrate the obvious

The most common waste of print in rulebooks is an example that shows the move everyone already understood.

Russ gives the perfect test case. Suppose a rule says an attacking unit with an archer or a catapult gets +1. A unit with both — is that +1 or +2? The rule as written implies +1, but a meaningful number of readers will read +2. That is where the example goes.

I Slay the Dragon's version: "Don't take the easy way out, giving obvious examples of what cards and actions do. Most players will understand obvious moves by reading the regular rules, but they won't necessarily understand cases that conflict with obvious play. If you don't illustrate edge cases, you'll send players directly to the forums."

8.2 Maximise coverage per diagram

Rulebook space is finite, so make every diagram answer several questions at once. Curby's worked example: a tile-laying rule, "Score 1 point for every Blacksmith adjacent to 2 or more Iron Mines."

A diagram showing one Blacksmith flanked by two Mines is nearly worthless. A high-coverage diagram shows several Blacksmiths, some scoring and some not, and answers:

• Can multiple Blacksmiths share a given Mine?
• Do diagonal touches count as adjacent?
• Does a Mine adjacent to another Mine chain?
• Does a road or fence on a shared edge break adjacency?
• Does a Mine flipped to its depleted side still count?

Those details belong in the rules. The diagram's job is to reinforce them and to look like a real game in progress, not a laboratory specimen.

8.3 Make clear what is arbitrary

Readers infer rules from examples. If every tableau in your book shows five cards in the same arrangement, some readers will conclude tableaus must look like that — and will play in a way that limits their own options.

"If you choose your examples haphazardly, you may inadvertently introduce unintended rules."

Vary the incidental details across examples, or say explicitly what is illustrative.

8.4 Long walkthroughs versus short snippets

Both have their place, and they do different jobs:

• Isolated examples clarify one rule at the point of confusion.
• A long walkthrough — a full turn or two consecutive turns, with the board state shown after each action — shows the system working, which no set of snippets can. This is repeatedly praised in 1960: The Making of the President, Combat Commander and Avalon Hill's programmed-instruction titles.

One BGG editor's rationale: "This is an advantage of having a few longer walkthrough examples which show various parts of the system all working together, instead of many isolated examples showing a single point."

8.5 Should examples show motivation?

Genuine disagreement here, and both positions are defensible.

For: "I like it when examples provide motivation for the players — 'Alice would really like to choose Take Stone to finish her palace, but Bob has already taken it, so she takes Recruit Troops instead.' Such examples give you a notion of what playing the game is really like."

Against: J C Lawrence's position is that rules should state the algebra and stop — "no suggesting strategies or why some things may be better than others, or having examples that suggest play patterns to readers."

A workable resolution: motivation belongs in the teaching document (playbook, learn-to-play, tutorial) and not in the reference. If you have only one book, use a visually distinct sidebar so a re-reader can skip it.

8.6 Anatomy diagrams

If a card, tile or player mat carries several pieces of information, label every zone once in a dedicated diagram — cost, type, strength, effect — and then use those labels as vocabulary for the rest of the book. Herc du Preez calls this the Component Breakdown and places it before the rules; Resonym calls it Anatomy. Either way it converts a component into shared language.

8.7 Set examples visually apart

Use italics, a tint block or a sidebar. Two reasons: a learner needs to find them, and a re-reader needs to skip them. Curby's convention — bold for keywords and headings, italic for examples, captions and flavour, and never italic for rules themselves — is a sound default.

And the hard rule that follows from it: a rule that appears only inside an example does not exist. Paul Grogan lists "rules hidden only in examples" among the red flags he actively hunts for in a draft.

9. Reference apparatus

9.1 Table of contents and index are not the same tool

• A table of contents lists sections in order. It answers "where does the game explain combat?"
• An index maps keywords — including words that are not section names — to pages. It answers "where does it say anything about ties?"

Short books need a TOC. Books over about twelve pages need both. From the Sword & Sorcery discussion:

"For me, a keyword-oriented index (as opposed to a by-subject TOC) would still be useful after two campaigns. From time to time I look for some rare effect or rule and have to guess which TOC subject it may belong to, and scan a page or two checking if my guess was right, sometimes missing the short paragraph, searching again, and so on."

A useful trick from the same thread: an index placed on or near the back cover means the reader does not have to open to the front and then flip to the target — one page turn instead of two.

9.2 The missing index is a top-tier complaint

Two of Going Analog's four worst rulebooks are indicted primarily for the index, not the prose.

• Mice and Mystics: "I agree, Mice & Mystics has a terrible rule book. They could have at least put an index in there, as I spend a lot of time looking up rules. It is still my second favourite game though."
• Space Base: the manual has no index outside a list of every card with "corresponding (and utterly meaningless) ship classes", and card interactions are not in alphabetical order. "Any time anyone questions anything in the game, you're subjected to several minutes of page-flipping tedium."

Note in both cases the game is liked. The index is not a polish item; it is the difference between a game people play and a game people look up on BGG.

9.3 Glossary placement: the unresolved argument

There is a real, well-argued disagreement in the corpus, and knowing both sides lets you choose deliberately.

Glossary at the front: if the rules are written in terms the glossary defines, front-loading avoids duplicating definitions and prevents the reader hitting undefined words. Glossary at the back: "I don't like having a lot of stuff before the real rules. It's frustrating to have to wade through it all to get to the part that teaches the game."

The counter-counter: "Having to page back and forth, to me, is the hallmark of a badly written boardgame rulebook."

Practical resolution used by good books:

1. Define each term at first use in the body text (so a linear reader never stalls).
2. Put the glossary on the inside back cover (so a look-up is one flip, not a hunt).
3. Reserve the outside back cover for the icon key and turn flow — the things you need while playing, not while learning.
4. Index everything so neither is the only route in.

9.4 Card and action appendices beat FAQs

An alphabetical, per-card clarification appendix is repeatedly praised: Dominion (including cross-expansion combos), Ark Nova, and — the gold standard — Puerto Rico, which puts each building's clarifications directly beneath the building's description. I Slay the Dragon: "Every building has helpful clarifications right underneath its description, eliminating the need for supplemental online FAQs."

And the corollary, from Russ:

"If a rule is found to be confusing for significant numbers of readers or playtesters, then rewrite the rule to make it clearer; don't add a separate FAQ at the end of the rules."

An FAQ entry is a patch over a defect in the rules text. Entro Games goes further: "Consider why such Questions are Frequently Asked. It often comes from someone looking for a rule and not finding it where expected. I'd rather deal with edge cases in the section where they're most likely to come up."

9.5 The "commonly missed rules" section

The highest value-per-word feature available to you. Attika closes with "a list of a few things often forgotten in a first game"; Brass has a short section for oft-missed rules. It costs a quarter page and prevents a whole class of misplays — and it costs you nothing to write, because blind playtesting already told you exactly what belongs on it.

9.6 The back cover

"Use the back cover as a player aid. So many rulebooks waste this really useful space."

Candidates, in rough priority order: turn / round flow; icon and symbol key; setup quantities by player count; scoring summary; index.

The reason setup quantities appear on this list so often is that they are the single most re-looked-up fact in most games. As one user put it: "Those are the kind of details that I always have to look up, even when I can remember all the other rules of a game."

9.7 A graphical index

Gloomhaven's picture-led index is repeatedly named as best-in-class: "IMO the graphical index Gloomhaven uses is unsurpassed. Especially when line of sight or conditions or effects like poison or fire are involved, we refer to the rule book. The only time we are happy when the need to look something up arises is when playing Gloomhaven."

The transferable principle: for anything visual — adjacency, line of sight, spatial conditions — put the picture next to the definition, not on another page.

---

Part IV — Design and Production

10. Layout, typography and print

10.1 Numbers you can act on

Decision	Recommendation
Body text size	10 pt absolute minimum (Stonemaier's stated floor); 11–12 pt preferred; larger for some typefaces
Accessibility target	12 pt minimum "clear print"; 16 pt+ Arial for large-print editions
Line height	≥ 1.5× the text size
Text contrast	≥ 4.5:1 for body text; ≥ 3:1 for large or bold text
Rulebook trim size	180 × 240 mm is Stonemaier's favourite — big enough for visuals, small enough to leave open on the table
Page count	Must be divisible by 4
Self-publishing buffer	Budget 2–4 more pages than you think you need

On buffer, Resonym's reasoning is worth quoting: "There are always useful ways to fill space, even if it's only having your characters pop in to reinforce the story, but it's hard to make more space when you've already laid out your rulebook."

10.2 The typographic profile readers actually ask for

Asked what makes a good rulebook, one BGG user answered in six lines that summarise the entire corpus:

Sans serif · Simple layout · Sensible order · Light on jargon · Concise · Proper grammar

Around that, the recurring specifics:

• Never print rules over art, texture or a dark background. This complaint appears in threads from 2007 to 2026. One user described having to angle a rulebook against a light source to read it.
• Avoid decorative and display faces for body text. Killer Bunnies is the standing example: "The graphic designer chose a thinline font, printed at a small size, with the characters kerned far too tightly, and often outlined with bold colour that makes them HARD to read. Legibility is more important than cutesy letters."
• Do not underline rules text. Underlines clash with descenders and reduce legibility.
• Avoid long all-caps passages. All-caps is measurably less readable; if your font supports true small caps, use those instead of shrinking capitals.
• Use white space generously. It is not wasted; it is the thing that makes a dense page approachable.

10.3 Emphasis is a hierarchy, not a decoration

"Not only is plain text easiest to read, but the overuse of emphasis leads to a cacophony of competing voices that decreases your ability to attract the reader's attention."

A workable convention:

• Bold — keywords at the point of definition, headings, and the rare genuinely critical instruction.
• Italic — examples, captions, flavour text, short in-line references. Never rules.
• ALL CAPS — reserve for a handful of rules that playtesting proved players miss.
• Underline — never.

Meeple Mountain's four-level scheme from a real published game is a good starting point: bold for paragraph titles, Capitalised First Letters for game-specific concepts, ALL CAPS for the very few rules everyone forgets, and italics for side notes and gameplay examples.

One designer's honest self-report in the Stonemaier comments shows why restraint matters: "I initially had icons everywhere, but that caused me to have an EXTENSIVE iconography… All the random bold words can look very jarring and when you read it, you seem to mentally add emphasis — absolutely not what I want in the finalised rulebook."

10.4 Marginal summaries: the best hybrid answer to the teach/reference problem

The Alea series (Puerto Rico, San Juan, Castles of Burgundy) runs the full explanation in the main column and a one-line summary in the margin:

"I liked Castles of Burgundy in that there are easy-to-follow setup instructions, long form rules, and then in the margins, just the short form rule. The latter makes a good reference for subsequent plays." — "+1 to this. The Alea series all have the same style and it has made learning them a breeze."

This is the single most elegant solution in the corpus to the tension in Chapter 5: the same spread teaches the first-time reader and serves the returning one. Rio Grande's side-strip and San Juan's interleaved summaries are variants of the same idea.

10.5 Facing pages and page breaks

Books are read as spreads, not pages. Design accordingly:

• If the component list and setup will not fit on one page, make them facing pages so the reader never turns back mid-setup to remember what a Guest Card is.
• Short sections should not break across a page boundary.
• Two-page sections belong on facing pages.
• Keep a rule and its example/diagram on the same spread. Page-flipping between a rule and its illustration defeats the illustration.

10.6 Tooling and sequence

The consensus workflow, from the rulebook-design thread and professional practice:

1. Draft in a word processor — Word or Google Docs. Google Docs specifically because it makes sharing with test readers trivial.
2. Edit the text before layout. Michael Lee's professional rationale: "This allows me to reorder and rewrite entire sections without requiring costly graphic design updates."
3. Lay out in InDesign (or Affinity Publisher) once the text is stable. InDesign links Photoshop and Illustrator files live, so updating an icon updates the book.
4. Proofread after layout, because layout introduces its own errors — reflowed text, orphaned lines, broken cross-references, mis-set page numbers.

And the ever-present caveat from Rob Harper: "Of course, layout is no substitute for badly written rules." Or, from an editor on the same thread: "Flavor, humor, indexing and diagrams are all useless if the sentence structure and flow of your rules stink."

11. Player aids and pushing rules onto components

11.1 Write the player aid first

This is one of the most practical process insights in the research, and it comes from three independent professionals:

"For initial local playtesting, I create player aids instead of a rulebook, as the rules are very much in flux at that stage (plus, it sets the groundwork for each player to have a player aid in the final product too). It's only when I'm approaching blind playtesting that I write the rulebook." — Jamey Stegmaier

A reader in the same thread noted hearing Cole Wehrle and Sen-Foong Lim describe the same practice within 48 hours of each other. The logic is sound: early on, rules churn weekly, so a full rulebook is wasted work — but the aid forces you to identify what actually matters, and it ships.

11.2 Player aids duplicate; they never replace

The failure is well documented:

"One of my favourite games and one of the best solo games on the market is Mage Knight. One of the worst things about it is how many rules are not in the rulebook but rather on reference cards. Reference cards should be used as a rules reference, as their name implies."

Triplock shipped with trap and countermeasure rules only on a reference card — and some copies had that card packed outside the box. The publisher's response is the right one: "I think we will elect to add this card's info to the rulebook in future printings to ensure that everything can be found in one place."

Rule: anything printed on a card, mat, board or aid must also exist in the rulebook. The aid reorganises information for speed; it does not own information.

The one thing that most reliably breaks this rule is setup quantities by player count, which designers love to relegate to an aid. "Setup being only on a player aid sheet tends to really annoy me."

11.3 One aid per player

Board Game Sanctuary's version is unimprovable: "NEVER cheapen out on summary action cards for EVERY PLAYER."

A shared aid creates a queue and a reading-over-shoulders problem. A per-player aid lets each player answer their own question instead of interrupting the teacher — which is, in practice, what makes a heavy game playable at a mixed table. Merchants & Marauders and Splotter's games are both repeatedly cited as titles where the aid carries most of the load: "For [a Splotter game], I think we had to check the rulebook for clarification one time; all the other info we needed was right on the player aid."

11.4 Push rules onto the components

Every rule the components carry is a rule nobody looks up.

Stonemaier's philosophy: "My general philosophy is to put text on cards (not combinations of icons to decipher) and that the text be self-sufficient enough that a separate appendix isn't necessary. However, sometimes there just isn't room. In those cases, either an appendix or the back of the card/tile are good places."

A commenter's refinement is worth adopting: put icons where players look often (player mats, boards) and keep card text word-only where space allows. Icons on a hundred different cards means a hundred lookups; icons on a mat in front of you means none.

Curby adds a nuance about component context: the rulebook may say "Machine Cards", but a player holding a Machine Card knows it is a card, so its own text can simply say "Machine". Where space is tight, that shortcut beats shrinking the font.

12. Accessibility, inclusion and localisation

12.1 Double-code everything

Never carry meaning by colour alone. Pair every colour distinction with a shape, icon, texture or label.

The direct beneficiary is the roughly 8% of men and 0.5% of women with colour vision deficiency — around 300 million people worldwide. But the second-order benefit is larger: double coding also helps players in dim rooms, players reading components across a table, and players with any degree of vision impairment. This is the standard argument for inclusive over merely accessible design: decisions that explicitly support specific users implicitly benefit everyone.

12.2 Contrast

Adopt WCAG-derived targets: 4.5:1 for body text, 3:1 for large or bold text (18 pt, or 14 pt bold).

The cheapest test in this entire handbook: convert your page to greyscale. If the text becomes hard to read, your contrast is too low.

The nuance worth respecting is that pure black on pure white can feel harsh, and can glare under bright light. The workable compromise is a hybrid: high contrast for anything the player must read, low contrast reserved for decoration.

12.3 Typography for dyslexic readers

• Plain, evenly spaced sans serif — Arial, Verdana, Tahoma, Century Gothic, Trebuchet.
• 12–14 pt body text.
• Line height at least 1.5×.
• Bold for emphasis, not italic — italics make text appear to run together.
• Avoid blocks of capitals.
• Avoid fully justified text; the resulting rivers of white space are hard to track.

These overlap almost exactly with the general legibility advice in Chapter 10, which is the point: accessible typography is just good typography with the excuses removed.

12.4 The wider accessibility frame

Stonemaier's working model spans nine categories, and it is a useful audit checklist because it shows how much of "accessibility" the rulebook actually controls:

Learning (tutorial, rulebook length, rules video, digital version) · Retention (reference guide, minimal exceptions, intuitive interface) · Time (setup, play, cleanup) · Visuals (dual-coded icons, uniquely shaped tokens, font size and contrast) · Presence (table space, box size) · Language (language independence, localised versions) · Purchase · Scope (player counts) · Inclusion

The rulebook owns Learning, Retention, Visuals and Language outright. Note the item "minimal exceptions" under Retention — this is the same design smell from Chapter 4, arriving from a different direction.

12.5 Write for readers in a second language

A significant share of your audience will read your rules in a language they did not grow up speaking. Everything in Chapter 6 helps them, plus:

• Avoid slang, idiom, Americanisms and Britishisms. Entro Games lists this explicitly.
• Avoid cultural references as load-bearing explanation.
• Keep sentences short. A long sentence in a second language is exponentially harder, not linearly.
• Recruit non-native speakers as beta readers. Brandon the Game Dev deliberately assembles readers of different backgrounds, skill levels and nationalities, then looks for common trends in their confusion rather than fixing one-off complaints.

One BGG user's plain statement of stakes: "English is my second language so a good rulebook makes a huge difference for me."

12.6 Translation is technical writing, not language conversion

The Andoria team spent more than six months translating a German rulebook into English, through multiple proofreading passes, and their conclusion is the practical takeaway:

"We have learned our lesson and highly recommend to everyone who wants to bring his rules onto paper to double double check everything before giving it to the designer for a graphic version. Saves a lot of time."

What survives translation is templating. Consistently-worded, patterned rules translate almost mechanically; synonym-rich prose multiplies the number of judgement calls a translator must make, and each judgement call is a chance to introduce a rules error.

Where translation fails, it fails visibly: Heroes of Normandie — "Great game… rulebook will give you PTSD" — is cited repeatedly as a good game damaged by a disjointed English edition, to the point where fans spent months rewriting it. Fan rewrites are a symptom of publisher failure, not a solution to it.

---

Part V — Process

13. From first draft to print

13.1 The timeline

Stage	What exists	What you do
Early design	Prototype, weekly rule churn	Player aids only. No rulebook.
Stabilising	Rules mostly settled	First full draft. Expect it to be too long and too wordy.
Pre-blind-test	Draft + components	Rewrite twice. Build the style guide. Add examples where playtesting showed confusion.
Blind testing	A rulebook a stranger must survive	Observe, do not help. Rewrite. Repeat.
Editing	Stable text	Professional developmental edit / copyedit, before layout.
Layout	Edited text + art	Graphic design in InDesign. Text may need trimming to fit.
Proofreading	Laid-out file	Separate proofreader. Layout introduces its own errors.
Pre-production copy	Physical PPC	Timed look-up test. Read the book backwards. Cross-check every count.
Post-launch	Shipped game	Living rules page, dated errata, searchable PDF.

The rewrite count is not optional. From BGG: "When I first attempted to write a rule book it was way too long and wordy. After I had written a few of them, my writing got better. My advice: write the whole thing, then rewrite it two times. The third iteration will be way better than the first."

13.2 Keep the rulebook in sync with the components

Entro Games names a defect class most designers hit at least once: "The last thing you want is for your cards to be on version 3, the board to be on version 4, and the rulebook to be on version 2."

Practical control: put a version number and date on the rulebook draft, and on every component sheet, and check them against each other at every milestone.

13.3 Two techniques from professional practice

Read the rulebook backwards, section by section. Jamey Stegmaier's QA technique. Reading in reverse breaks the autopilot that lets you skim your own writing: "I can hone in on specific elements without skimming ahead by accident."

Time the look-up on the pre-production copy. "When the pre-production copy of the product is ready, one of the things I'm looking for in our playtests is how easily I can find answers to questions in the rulebook. If I can't find the answer quickly, I revise the rulebook accordingly."

Note what this second test measures: not whether the answer is present, but whether it is findable. Slow look-up is a structural defect, and the fix is reorganisation, not rewriting.

13.4 Hire people, and hire two of them

Editors catch between 80% and 95% of errors on a pass. That is a well-established figure (from The Copyeditor's Handbook), and it has one obvious implication: one person will never catch everything, even if catching things is their job. Hire an editor and a separate proofreader for anything substantial.

Rates from the Meeple Mountain survey run roughly USD 25–50 per hour for most freelance editors, more for the very experienced. Against the cost of a print run, this is rounding error.

The cautionary tale is public and generous. The designer of Obsession posted a complete, itemised errata list for his own game, and wrote:

"I apologise as these errors are my fault; I have learned a lesson that a professional proofreader is required in all future projects." … "In fact, I had my proofreader quote me on the project, and decided she wasn't necessary. Bad decision."

If you genuinely cannot pay, the alternatives in the corpus are real: rulebook exchanges between designers on BGG, the Break My Game Discord, the Editors' Hangout Discord, and simply asking BGG to review your rulebook — several designers report doing exactly that with good results.

13.5 Understand what you are buying

Editing is not one service. The stages, in Michael Lee's glossary:

• Proofreading — spelling, grammar, punctuation, localised issues.
• Copyediting — proofreading plus rewriting awkward sentences and enforcing consistency in terminology and templating.
• Substantive / developmental editing — copyediting plus rewriting entire sections and reorganising large chunks.

If your "rulebook" is a set of scrawled notes, you need substantive editing, and asking for a proofread will not help you. Tell your editor honestly which one you need.

14. Blind playtesting

14.1 What it is actually for

By the time you blind test, you should already believe the game is good. What you are testing is the document.

"To me, blind testing is testing the written rules. By the time I ask people to blind test a game, I am convinced that the game itself is good enough. But I need to know whether people understand it from just reading the rules."

Meeple Mountain states the same boundary more sharply: "The goal of a blind playtest should not be to improve game design. It's a rules test only."

Stonemaier quantifies it: blind playtesting is "25% for the purpose of improving the rulebook." And the standard he applies is unusually demanding:

"If a playtester misses a rule, even if it's marked clear as day in the rulebook, I consider it an opportunity to make it even clearer or put it in a more obvious place."

Notice there is no version of that sentence where the tester is at fault. That posture is what separates a rulebook that improves from one that does not.

14.2 The protocol

Recruit people who have never seen the game. Friends of friends work well — close enough to say yes, distant enough to be blunt. A note in a friendly local game store occasionally produces someone. Designer-to-designer exchanges ("play mine and I'll play yours") are an established BGG practice.

Test with non-gamers. This is Resonym's Tip 2 and it is the one most often skipped:

"Rulebook testing with experienced board gamers is comparatively easy, since they often already know how to read rulebooks. You should seek out folks who don't read rulebooks often — your family, your nongaming friends, anyone who you can convince — because these playtests are the ones that will make your rulebook awesome. If your rulebook can teach your grandma how to play your game, then it can teach anyone."

Warn them what they are in for. Also Resonym, with a line that should end the debate about whether this matters:

"After the time my wife broke down in tears during a rulebook test, I always make sure playtesters know what they're getting into."

The script: "In this playtest you're going to be reading the rulebook and learning how to play. Reading rulebooks can be hard. We're here to find the parts that are confusing, so if you're confused at any point, let me know — it's not your fault, it's ours. I'll write it down. I won't be able to help you with it, but I'll fix it in the future."

No videos. Not all future owners will have internet access, and the video will hide exactly the defects you came to find.

Do not help them. This is the hardest instruction in the chapter and the most important:

"It's really, really tempting to step in and save your players when they inevitably make mistakes… Unfortunately, if you swoop in to save your players from mistakes, they become reliant on you. They learn that they don't need to think too hard about whether the rules work this way or that way; they just need to choose one and then look at you to see if you correct them."

Resonym's illustration: in one test, players put out every Food token for the entire game at once, producing an ugly pile and a much worse game. He let them play that way for the whole session.

The one exception: intervene when a misreading will invalidate the rest of the test — when their current error means you will never get to observe the other rule you needed to check. When you do intervene, write down that you intervened, because it is remarkably easy to forget afterwards that a "clean" test was not clean.

14.3 Observation technique: play dumb

The single most actionable trick in the research. Have a single tester teach you the game, then interrupt yourself constantly:

• "What do I do now?" — used at nearly every juncture, and deliberately right before any rule that has tripped players up in the past. It is far too easy to accidentally do the correct thing and learn nothing.
• "How should I make that decision?" — surfaces whether the rulebook conveyed any sense of why a player would choose an option.
• Do it wrong on purpose. If you saw someone misunderstand a rule in an earlier session, enact that misunderstanding yourself and see whether this tester catches you.

14.4 Live blind testing: the aggressive variant

Peter C. Hayward of Jellybean Games hands a group the rules and components, sits in a corner, and stays silent for the entire session. If they get stuck, they must resolve the ambiguity themselves and continue.

His argument in favour is genuinely strong: when the designer teaches and plays, it is impossible to separate the game from the designer's presence — the tone-setting, the on-the-fly corrections, the clear demonstrations. "For everyone else, the experience of the game will not include the designer."

The critique from Jeff Warrend is equally fair: forcing testers to flounder is expensive, unpleasant, and unreliable as a design method. He also notes a real and underappreciated pattern: "Groups that are taught a game tend to like it better than those who must learn it for themselves."

The synthesis: learning from the rules alone is necessary but not sufficient. If your target audience is families and casual players who will open the box with nobody to teach them — Jellybean's audience — the aggressive variant simulates reality precisely. If your audience is hobbyists who will be taught by the one person who read the rules, the milder protocol tests the more common path.

14.5 Feedback instruments

Build a short, game-specific feedback form rather than using a generic one — a widely-circulated generic evaluation sheet was judged "too much and too full of technical terms when used by casual gamers."

Two useful design ideas from the same discussion:

• A small reference card at the table listing what you want testers to notice, so they can register a problem in the moment rather than reconstruct it afterwards.
• Calibration questions: "On a scale of 1–10, how much do you like worker placement games in general?" followed by "On the same scale, how much did you like this game?" The gap between the two is more informative than either number.

And one useful contribution from Entro Games, run at the end of a normal playtest: ask the winner how they would teach the game. Their spontaneous ordering is direct evidence about what your structure should be.

---

Part VI — Evidence

15. The failure taxonomy

Twelve failure modes, each with real documented examples. Use this as a diagnostic: when someone says your rulebook is "confusing", the useful question is which of these is it?

15.1 Missing rules

The most damaging class, because players cannot distinguish "not stated" from "we missed it". They house-rule, or they stop.

• Imperium: Classics / Legends — a commonly drawn card type that the solo bot should simply discard was omitted from the rules entirely. Players treated it as an "other" card and gave the bot an extra action, silently making the solo game much harder than designed.
• Raising Robots: Pets — the icon index did not match the printed cards; whether a robot could be activated more than once, and when a special activation had to occur, were never stated.
• Inferno (pre-release review) — access requirements for special locations admitted three different readings; the solo setup contradicted the standard setup at step 8.
• Triplock — trap and countermeasure rules existed only on a reference card, which some copies shipped outside the box.

Detection: blind playtesting is the only reliable method. Paul Grogan lists "a lack of blind playtesting, where situations occur which are not in the rulebook" among his primary red flags.

15.2 Undefined terms used as if defined

Caper is the cleanest case study in the corpus. The rulebook uses the word "set" throughout its scoring rules without ever defining it. Two independent groups arrived at the same wrong-but-entirely-sensible reading, and played that way for months. One of them created a BGG account specifically to say so. The designer eventually answered in the thread. A player's verdict:

"Referring to 'set' a number of times as scoring and caper opportunities without clarifying what a 'set' is has to be one of the biggest rules boners I've seen in a while."

Note what makes this so instructive: nothing about the sentence looks broken. The word "set" is ordinary English. It became a defect because the game gave it a specific meaning and never said so.

15.3 Rules scattered across artefacts

• Mage Knight — "a mess, with rules in 3 different places, with no consistency. Just awful. (Great game though.)"
• A Feast for Odin and 7 Wonders — "I invariably pick up the wrong booklet."
• Ulm — "Not actually badly written, but it was a very unfortunate decision to spread the rules over two separate booklets."
• Gloomhaven: Jaws of the Lion — the tutorial book holds rules the Glossary omits.

The complaint is never total length. It is not knowing which artefact to reach for.

15.4 Humour and flavour interleaved with rules

The most polarised topic in the research, and worth understanding rather than picking a side.

Against: "Dungeon Lords is bad, as is Galaxy Trucker. I really like Galaxy Trucker, but the rules are an abomination. It is really not a good idea to mix rules with flavour text." … "The joking manner in which the rules are presented just makes trying to pull the actual rules out a real pain."

For: "For me nobody in the business writes a better rulebook than Vlaada Chvátil. His rulebooks are written in a way that they teach you how to teach the game. They are often humorous and very easy to read through." And Stonemaier lists Dungeon Lords as a book to study for its humour.

The resolution both camps accept: humour and flavour belong in visually separated sidebars and boxes. Herc du Preez: "Don't mix humorous statements or theme elements with the rules. Keep the rules as only rules. This does not mean there shouldn't be any humour or story elements in a rulebook — they should be placed in sidebars or asides. Keep them separated."

A commenter's honest calibration: "I don't want to slog through a rulebook for a pirate game that sounds like it's narrated by Long John Silver throughout, but a drop of humour here and there in Dungeon Lords / Galaxy Trucker can make a rule easier to grasp and recall."

There is also a real benefit worth noting: "A good rulebook makes it easy to remember rules. Dungeon Lords, for example, has lore that explains certain rules and makes them stick." Flavour that explains a rule earns its place; flavour that merely surrounds one does not.

15.5 Icon soup with no key

A Heroes of Might & Magic adaptation: "A lot of icons spread around, but no reference page at the end of the rules."

Two rules follow. Every icon must be double-coded (Chapter 12), and the icon key must exist in exactly one obvious place — normally the back cover.

15.6 Rules hidden in examples, captions or parentheses

Paul Grogan hunts for this specifically. It is insidious because a re-reader skips examples by design, so a rule placed there is invisible on every read after the first.

Rule: parentheses, captions and examples clarify. They never introduce.

15.7 Circular and recursive cross-references

Root attracts this criticism repeatedly:

"I don't want to read a 'law' that gives me a rule and then tells me to refer back to paragraph 2B. Just repeat the point if necessary."

Herc du Preez names his version: "A section which references another section which references a third and then back again to the first."

Rule: cross-reference forward to detail, never in a loop, and always cite the target explicitly (see Connections, p. 34). When a rule is short, repeat it rather than reference it.

15.8 Errata churn and version drift

Coffee Traders is the flagship case: the 1.0 rulebook was "so utterly confounding that publisher Capstone Games decided to have a second crack at writing it just two years after release." The 1.5 rulebook fixed it — but a physical copy cost owners an extra USD 7, on a game priced over USD 100.

Agricola's original rulebook is widely described as awful and substantially improved in later editions. Reprints are the industry's patch mechanism, and they are slow: "you're likely to be waiting more than a decade in the hopes that a reprint will fix any glaring issues."

Mitigation: version and date every rulebook, maintain a public living-rules page with a dated changelog, and publish the corrected PDF free.

15.9 Inconsistent counts across artefacts

Obsession's public errata is an excellent QA checklist in negative form. Component counts were wrong in both the rulebook and the glossary (Theme Cards listed as 4, actually 10; £100 coins as 30, actually 35; Casual Guest Cards as 30, actually 35 — the last because five cards were added after the rulebook was submitted). A player aid stated 2 reputation for an action where the board and rules both said 4.

Mitigation: cross-check every number in the component list against the actual print run, and re-check after any late component change.

15.10 Illegible by design

Rules printed on a faux treasure map. Rules over dark art. Display faces at small sizes. Each of these appears in the worst-rulebook threads attached to a game the reader liked and shelved anyway.

"The rules are on a stupid faux treasure map… ugh, I had to write a 'quick start' sheet for it. Love the game!"

15.11 Over-explanation

Worth taking seriously, because it is the failure that good advice causes.

"[Rulebooks chock full of examples and pictures] I personally find bloody annoying because it causes book bloat, and serves no purpose because most information will be ignored after most of the rules are internalised. The worst offender is 24 pages for a game which struggles to fill half that amount."

And FFG draws this specific criticism: "notorious for over-explaining rules that are not terribly complicated, and bloating every rulebook out to 40 pages with examples — and every one of their books ends up needing a FAQ anyway."

Note the compatible preference from the opposite camp: "I'd rather flip through twenty pages of rules and glance the content of each page in an instant than have to plough through ten pages that are walls of text." Page count is not the complaint. Density is.

15.12 Edition and expansion sprawl

Vinhos Deluxe with Kickstarter expansions is the named example: editions, variants and stretch goals combined haphazardly into one book, with some content only on loose sheets.

Rule (Curby): the base game's rulebook describes only the base game. Expansions get supplements. For a franchise with many expansions, a separate comprehensive reference covering everything can be maintained and redistributed — but the base rulebook should never make a new player feel they are reading around content they do not own.

16. Case studies

16.1 Rulebooks worth studying

Game / publisher	Study it for
Fantasy Flight (Marvel Champions, Arkham Horror LCG)	The dual-document model done properly: condensed Learn to Play + indexed Rules Reference
Root (Leder Games)	A walkthrough book that made a wargame mainstream — and a reference that tells you which book to read based on how you learn
Arcs (Leder Games)	Tone. Honest, warm, casual voice ("expect a long, tedious first game"); contextual component descriptions; even a labelled repacking diagram
Alea series (Puerto Rico, San Juan, Castles of Burgundy)	Marginal summaries: full rules in the column, one-line summary in the margin
Puerto Rico	Edge-case handling: every building's clarifications sit directly under its description
Dominion	Keyword discipline — four keywords used with total consistency — plus a per-card appendix covering odd and cross-expansion combos
Uwe Rosenberg rulebooks	Order of presentation, examples attached to most concepts, digestible chunks, and "Uwe Says" tip boxes
Vital Lacerda games (ed. Paul Grogan)	Example density on genuinely heavy games
Gloomhaven	The graphical index — pictures next to definitions for spatial rules
Gloomhaven: Jaws of the Lion	Tutorial design (with the reference caveat from 15.3)
Combat Commander / Here I Stand (Ed Beach, Chad Jensen)	Wargame reference craft: numbered sections, no filler, TOC + glossary + index
Twilight Struggle Deluxe	Numbered-section navigation that makes look-up fast
Splendor	Four pages, complete. Proof that sparse can be sufficient
Roll Player	Many small sections rather than few large ones; back cover as quick reference
Attika	Clear headers, disciplined bold, a two-column split mirroring a two-option choice, and a closing "often forgotten" list
Belfort	Making a game with many moving parts feel simpler than it is
Splotter titles	Breaking complexity down, plus player aids so good the rulebook is rarely opened
Raptor	Anticipating every question a player could have, in an organised way
Merchants & Marauders	Rulebook and player aid working as a partnership
Mechanica / Surrealist Dinner Party (Resonym)	Attention engineering — faded and upside-down text to stop new players reading advanced sections
Ark Nova	Alphabetical card-specific appendix
Brass: Birmingham	A short "oft-missed rules" section
Dune: Imperium	A single-page symbol reference
Galactic Cruise	Organisation (Stonemaier's pick)
Barcelona	Historical context integrated without displacing rules
Origin Story	Serving different player counts and experience levels in one book
Dawn of the Zeds	Multi-rulebook architecture

16.2 Rulebooks worth studying as warnings

Game	Primary failure
Robinson Crusoe (1st ed.)	Errors acknowledged by the designer, vague action descriptions, inconsistent graphic design. Spawned an entire fan FAQ and rewrite ecosystem
First Martians	Named by a professional editor as killed by its rulebook; hundreds of posts of rules questions and errata
Batman: Gotham City Chronicles	Also named by Paul Grogan; seven pages of BGG errata and FAQ
Mice and Mystics	No index — in a liked game, this alone was the complaint
Space Base	No usable index; card interactions not alphabetised
Kemet: Blood and Sand	Critical rules hidden inside the components list; contradictory wording; boxout examples that make simple rules harder
Coffee Traders	Errors and inconsistent terminology severe enough to force a publisher rewrite two years later
Pathfinder ACG: Rise of the Runelords (1st printing)	Terms used before definition; over 1,500 BGG rules threads
Heroes of Normandie	Disjointed structure plus poor translation
Space Hulk: Death Angel	Only a few pages, yet players could not determine setup — brevity is not clarity
Mage Knight	Rules split across three artefacts, including reference cards holding unique rules
Galaxy Trucker / CGE house style	Humour interleaved with rules; delightful once, painful as reference
Root	Law-style cross-references sending readers back to numbered paragraphs
Caper	A core scoring term ("set") used throughout and never defined
Myth (2014)	USD 900,000+ raised; players spent more time deciphering rules than playing; prompted a 72-page fan rewrite
Perdition's Mouth	Merged Overview and Setup sections, icon and sidebar overload — documented in a public self-critique by its own rulebook writer
Sword & Sorcery: Immortal Souls	Subject TOC only; players build their own keyword index over dozens of hours
Race for the Galaxy	~6–8 pt body text: legible, but the hobby's standing reference for "too small"
Killer Bunnies	Thin display face, small size, tight kerning, coloured outlines
Star Fleet Battles	Rules diluted by one-liners, strategy asides and stray thoughts
Advanced Squad Leader	Paragraph-long single sentences: comprehensive, not learnable

16.3 A cautionary tale worth reading in full

The most valuable single document in this research is Dean Ray Johnson's essay Every Board Game Rulebook Is Awful — not for its conclusions, but because it is a rulebook writer publicly dissecting his own failures.

He rewrote the Myth rulebook as technical-writing practice. The result was 72 pages, stuffed with flavour text, with the steps of a game round split across chapters. Fans loved it — it was downloaded roughly 4,900 times. Then a friend asked him to teach Myth from it, and he could not: "I spent several minutes stumbling over pages that I had written myself."

He rewrote Heroes of Normandie next, this time as a reference manual, and merged the Overview and Setup sections — "why not explain what a component does in the same place that I tell you where to put it on the board?" Again fans loved it (~4,800 downloads). Again he nearly failed to teach the game from it.

Then a publisher hired him to write the rulebook for Perdition's Mouth. He carried both mistakes forward. Tom Vasel's verdict on the published game: "The rulebook is not very handy at all… I thought it was very overwrought; it took me a while just to figure out how to play the game."

Three lessons, and they are cheap to learn from someone else's expense:

1. Positive feedback is not evidence. Every one of those rulebooks was praised by the people who downloaded it.
2. The test is teaching, not reading. Try to teach your game from your own rulebook, cold. If you stumble, so will everyone else.
3. Setup and Overview are different jobs. Overview builds the mental model; Setup arranges the table. Merging them means teaching the overview in setup order, which is almost never the right order.

---

Part VII — Templates and Tools

17. Ready-to-use templates

17.1 The master rulebook skeleton

Copy this into a blank document and start filling. Delete what your game does not need; the point is to make omissions deliberate rather than accidental.

[GAME NAME]
[One-line hook: what kind of game, for whom]
[N] players · [N]–[N] minutes · Ages [N]+

1. INTRODUCTION
   One paragraph. Who are you? Where and when? What are you trying to do,
   and why? How, broadly, will you do it?

2. GOAL OF THE GAME
   One or two sentences. State the win condition explicitly.

3. COMPONENTS
   Illustrated. Every item, its exact count, its name.
   [Component anatomy diagram if cards/mats carry several data points]

4. SETUP
   Numbered steps in physical order of operations.
   State face-up / face-down and public / secret explicitly for everything.
   [Labelled diagram of the finished table state]
   Choosing the start player: [rule]

5. GAMEPLAY OVERVIEW
   Bullet list of what a round/turn contains. No detail.
   The game is played over [N] rounds / until [trigger].

6. DETAILED GAMEPLAY
   6.1 [Phase / Action A]  — common case only; exceptions in a marked box
   6.2 [Phase / Action B]
   6.3 [Phase / Action C]
   [Worked example covering a non-obvious interaction]

7. END OF ROUND (if applicable)
   Cleanup and reset steps, in order. End-of-game check.

8. END OF THE GAME
   Trigger: [what causes it]
   After the trigger: [does the round finish? do all players get equal turns?]

9. SCORING AND WINNING
   Numbered scoring steps in resolution order.
   Tie-breakers: [first tie-break, second tie-break]
   [Worked scoring example]

10. APPENDIX
    Card / action / ability clarifications, alphabetical.
    Commonly missed rules (write this from your blind playtest notes).

11. GLOSSARY (inside back cover)
12. INDEX (if over ~12 pages)
13. BACK COVER: turn flow · icon key · setup quantities by player count

---
Rulebook version [x.y] · [date] · Living rules: [url]

17.2 Your project style guide

Fill this in before you write. It takes fifteen minutes and prevents most consistency defects.

Decision	Your choice
Person (2nd / 3rd)
Voice	Active by default
Pronoun for a player	Singular they; that player when ambiguous
Capitalisation policy	Capitalise only specific in-game components, actions and values
Bold used for	Keywords at definition; headings
Italic used for	Examples, captions, flavour
Underline	Never
Serial (Oxford) comma	Yes / No
Numbers	Digits for game quantities; spell out sentence-initial and flavour numbers
Time hierarchy	turn → round → [act/season]; phases subdivide [turns/rounds]; steps subdivide phases
gain / take	gain from unlimited supply; take from limited supply or a player
Canonical resource order
Canonical player-colour order
Component nouns (mat vs board vs card vs tile)
Cross-reference format	(see Section Name, p. N)
Banned words	should; simply; and any synonym for a keyword
Flagged words to review	except; remember; must

17.3 Keyword register

Keep one row per game term. This is your defence against synonym drift, and it is what you hand a translator.

Keyword	Definition (one sentence)	Icon	First defined on page	Never call it

17.4 Blind playtest protocol

Before

• Rulebook version number and date recorded.
• Testers have never seen the game.
• At least one session with non-gamers or non-native speakers.
• Testers told: no how-to-play videos, no asking the designer.
• Briefing script delivered: "Confusion is our fault, not yours. Tell me when it happens; I'll write it down but I can't help."
• Your observation sheet is ready with the specific rules you suspect are weak.

During — record, do not help

Time	Rule / page	What happened	Was it a misread, a gap, or a layout problem?

• Note every time a tester flips back a page, and to where.
• Note every question asked out loud.
• Note every rule played wrongly, whether or not anyone noticed.
• Note every intervention you made, and why.

After

• What was the total time from opening the box to the first meaningful turn?
• Which rules were played wrongly? Where does the rulebook state each one?
• Which rules were looked up mid-game, and how long did the look-up take?
• Ask the winner: "How would you teach this game?" Write down their order.
• Which questions were asked by more than one tester? Those are defects. One-off confusion may be noise.

17.5 Pre-print QA checklist

Content completeness

• Every component in the box appears in the illustrated list, with the correct count
• Every rule printed on a card, board, mat or aid also exists in the rulebook
• Setup is fully specified for every supported player count
• Every "most / least / first place" rule has a tie-breaker
• Solo, cooperative and variant modes have complete setup and end conditions
• Both the end-game trigger and the end-of-game sequence are stated

Structure

• Goal appears before the detailed rules
• No term is used before it is defined
• Every forward reference cites its target section and page
• Exceptions sit beside their rule or in a marked section, not in the core flow
• Each rule sits under the heading a confused player would reach for
• One linear read is sufficient to understand the game

Language

• One concept = one term, everywhere, including cards and marketing copy
• Identical effects are worded identically
• Conditions precede effects
• No sentence fails the one-breath test
• "should" removed; "except" and "remember" reviewed as design smells
• Repeated sets always listed in the same canonical order

Examples and visuals

• Every example covers at least one non-obvious case
• No rule appears only in an example, caption or parenthetical
• Examples make clear which details are arbitrary
• There is a labelled setup diagram
• Information-dense components have an anatomy diagram

Reference apparatus

• Table of contents present; index present if over ~12 pages
• Icon key exists in exactly one obvious place
• Back cover carries turn flow, icon key and/or setup summary
• A "commonly missed rules" list exists
• Rulebook carries a version number and date

Typography and print

• Body text ≥ 10 pt; smallest text checked in dim light
• Contrast ≥ 4.5:1; page readable in greyscale
• No rules text over art, texture or dark backgrounds
• No colour-only coding anywhere
• No underlined rules text; all-caps limited to a few critical notes
• Short sections do not break across pages; 2-page sections on facing pages
• Page count divisible by 4

Testing and handover

• At least one full blind playtest completed
• At least one test with non-gamers or non-native speakers
• Timed look-up test passed on the pre-production copy
• Rulebook read backwards, section by section
• Written style guide handed to copyeditor and proofreader
• Editing done before layout; proofreading done after
• Designer instructions unmistakably distinguished from rules text
• Rulebook version matches the component version going to print
• Searchable PDF and living-rules page planned

17.6 The one-page version

If you remember nothing else:

1. State the goal before the rules. The goal is the game.
2. Never use a term before you define it.
3. One concept, one word, forever.
4. Conditions before effects.
5. Illustrated component list, and a labelled setup diagram.
6. Examples exist to resolve ambiguity, not to demonstrate the obvious.
7. Never hide a rule in an example, a caption or a parenthesis.
8. Put rules where a confused player will look for them, not where they first became true.
9. Use the back cover.
10. Blind test with someone who has never seen the game — and do not help them.
11. Write your style guide before you write your rules.
12. If explaining a minor concept takes a full page, fix the design, not the paragraph.

---

Appendix A — Principal sources

The full source list, with clickable URLs, publication era and topic tags, is in the companion spreadsheet Rulebook_Research_Database.xlsx (sheet 01_Sources). The most load-bearing sources for this handbook were:

Style guides and professional practice

• Michael "Curby" Lee — Board Game Editing Style Guide (~13,000 words, CC-BY-NC-SA) — cur.by/styleguide
• Michael Lee — editing.curby.net (editing services, workflow, scope)
• Jamey Stegmaier — What Makes a Great Rulebook? — Stonemaier Games
• Jamey Stegmaier — The Stonemaier Games Style Guide
• Jamey Stegmaier — How Do You Measure Accessibility? — Stonemaier Games
• Kathleen Mercury — Writing Rules (rules template and style guide)
• Paul Grogan (Gaming Rules!) interviewed in Playing By The Rules — Punchboard

Practitioner guides

• Resonym — Writing Rulebooks
• Meeple Mountain — Top Six Rules for Rulebook Writing
• I Slay the Dragon — Laying Down the Law: a guide to rulebook writing
• Brandon the Game Dev — How to Make the Perfect Board Game Rule Book
• Entro Games — How to Write a Rulebook for Your Board Game
• Board Game Design Lab — Writing Rules article collection
• Cardboard Edison — Best Practices and rules-writing articles
• Diátaxis — a systematic framework for technical documentation

BoardGameGeek — craft and process

• Rulebook Editing Style Guide (thread 2527114)
• Rules Writing 101 (with an example) (thread 1552162)
• The Boardtastic Guide to Explaining Rules... Good (thread 918830)
• In-depth information about designing a good rulebook (thread 897413)
• What makes a good rulebook? (thread 2784900)
• Examples of well-written game rules? (thread 286303)
• Good Rulebooks (thread 2644979) · Best Written Rulebooks as of 2019 (thread 2323149)
• Blind playtest preparation (2513759) · How do you go about blind playtesting? (989999)
• Blind playtesting reconsidered — Jeff's World of Game Design
• Tutorializing (2581878) · Tutorial differences between videogames and board games (2681026)
• Rulebooks and text comprehension: a history of misunderstandings (3538423)
• Writing Rules — facing up to breaking the rules — Andy Van Zandt
• Every Board Game Rulebook is Awful — Dean Ray Johnson
• Comprehensibility of Game Rulebooks — David Niecikowski (dissertation announcement + free checklist)

Criticism and case material

• Going Analog — 4 terrible board game rulebooks that really don't rule
• BGG — Worst rulebook ever! (1554960) · Worst/Best written rules (1949478)
• BGG — Clarity in the Rulebook (Caper, 2395671)
• BGG — Sometimes finding the rulebook organization annoying (Jaws of the Lion, 2455924)
• BGG — OFFICIAL Obsession Rulebook and Glossary errata thread (2003488)
• BGG — Rules Missing from the Rulebook (Inferno, 3258804) · Pets Rule Book is missing crucial info (3271735)
• The Esoteric Order of Gamers — fan rules summaries (Robinson Crusoe and others)

Design, accessibility and production

• MINIFINITI — Rulebook Design: Contrast and Readability
• Kylin Manufactory — Board Game Rulebook Editing: A Step-by-Step Guide
• QinPrinting — How to Write a Board Game Rule Book
• Brain Games — Player Aids vs Rulebooks: Key Differences

Appendix B — Attribution and licence

Michael Lee's Board Game Editing Style Guide is published under a Creative Commons Attribution-NonCommercial-ShareAlike licence. Material derived from it in this handbook — principally the framing, templating, modal-verb, and word-choice guidance in Chapters 6 and 7 — is attributed to him here and in the companion database.

All other sources are summarised and attributed rather than reproduced. Quotations are short excerpts for the purpose of attribution and commentary; follow the URLs in the companion spreadsheet for full context.