| Sign In
| Site Map | 
RSS 2.0
Two friends sit at a table. One card says, “You may draw a card at the start.” One player draws two. The other says no. Voices rise. Play stops. A small line of text broke the whole game. What went wrong?
The words did not make the action clear or testable. In games, unclear words cost time and joy. This guide shows how to write rules in English so players act in the same way, every time.
Instruction language is short, clear English that turns rules into repeatable steps. It makes actions easy to follow and easy to check. It is not lore. It is not jokes. It is the contract between maker and players.
In a rulebook, story text can be warm and fun. But rule text must be exact. It should use plain words and simple shapes. The best start is to learn and use plain language guidelines. Then add key tools like the imperative mood, modal verbs, and if‑then lines.
Use the imperative mood for forced steps. It is short and strong: “Shuffle the deck.” “Deal three cards to each player.” For bans, use “Do not…” or “Must not…”. This reads like a checklist, not a story. Players move fast with it.
Use modal verbs with care. These are small helper words that set force: must, may, can, should, shall. Pick one and keep that meaning across the book. The Microsoft Writing Style Guide gives handy, real‑world tips on verbs, tense, and clear voice in docs.
Be strict with cause and time. If/then shows cause. When and before show time. Use unless and except to mark rare breaks. Keep each rule testable: either the step happens, or it does not. To keep testability high, write in active voice; a quick read on active vs. passive voice can help.
Modal verbs set the exact force of a rule. The table below is a quick matrix to keep intent the same across your book.
| must | Strong obligation | Non‑optional steps | Overused for soft advice | Players must shuffle the deck. |
| must not | Prohibition | Hard bans | Mixed with “cannot” | You must not peek at the next card. |
| may | Permission | Optional actions | Read as ability | You may draw one card. |
| may not | Prohibition (permission denied) | Limit options | Weaker than “must not” | You may not trade this turn. |
| can | Ability | What the system allows | Read as permission | This token can move two spaces. |
| cannot | Inability | System limits | Mixed with bans | You cannot move through walls. |
| should | Recommendation | Strategy tips | Weakens rules | You should defend early. |
| shall | Formal prescription | Legal standards | Stiff, rare in games | The dealer shall reveal one card. |
For deeper study on form and nuance, see this clear guide to modal verbs usage. It shows how each verb sets force and tone.
Rules love order. For steps that must go in sequence, use numbers: 1, 2, 3. For short choices with no order, use bullets. If a step has sub‑steps, use a two‑level list: 2.1, 2.2. Keep levels tight. Three levels is often the max.
Use colons to start a list, and brackets for short notes that do not change the rule. A comma can mark a short pause; do not pack a rule with many commas. For a quick brush‑up, this guide to punctuation basics is handy.
Cross‑refs help players jump fast. Use short, stable names like “See Setup” or “See 3.2.” Do not say “see below,” as layout can change. For deeper style cases, the Chicago Manual’s Q&A covers many cross‑reference best practices.
Before: “Players should try to draw a card at the start.” After: “At the start of your turn, draw 1 card.”
What changed? We set a time, used imperative, and made a test: did you draw a card at start? Yes or no.
Edge cases are where rules break. Name them before they find you. Ties: say who wins a tie, or how to break it. Timing windows: mark the exact time with set words like “immediately,” “at the end of your turn,” or “before you resolve damage.” Randomness: state how to roll, re‑roll, and in what order you check results.
When two rules clash, set a clear order: “Card rules override base rules.” For effects that stack, state if you add, cap, or replace. For user pain and error states, UX research has strong error message guidelines that map well to rule text too: be clear, be specific, and show the next step.
Good layout is not just “looks nice.” It keeps rules in the right place, helps scan the page, and stops mix‑ups. Use clear heads, white space, and stable fonts. Keep contrast high for all text and icons; see the WCAG notes on contrast guidance to help all players read with ease.
Red flag: walls of text with no examples, no icons, no callouts. Break them up. Add a small example box with a short play scene. Use a diagram for a hard setup step.
Plan for readers who speak English as a second language. Avoid idioms like “rule of thumb” or “hit the road.” Use the same term for the same thing, and make a short glossary with those terms.
When you ship in other languages, know the difference between translation or transcreation. In games, some lines need a shift in tone, not a word‑for‑word match.
As a quick check on ease of read, use a simple score like readability formulas. Aim for short words and short lines in rules. It helps all readers, not just new ones.
Do at least one blind playtest. That means you give the group the rulebook and say nothing else. Watch what they do. Note where they stop, debate, or house‑rule. Stonemaier’s write‑up on what makes a rulebook great has field tips from many teams.
Keep a log of pain points. When you edit a rule, A/B test two short versions. Use a checklist: imperative, time, test, cross‑ref. If both versions still fail, add a small example right under the rule.
Track changes like code. A simple tool is fine, but clear version tags and notes save you in the long run. If your team knows Git, these Git basics are enough for doc version control.
When your game has money, prizes, odds, or online play, write with care. Be clear on chance, fees, and real limits. Use figures where needed. Regulators watch this space. The UK Gambling Commission site is a good start for fair terms and safe play rules.
Players look for trusted checks too. If you speak about casinos, terms, or house rules, point to a neutral, well‑built guide. For example, CanadaCasinos.biz reviews sites and T&C with plain, direct language. A clear review like that helps players see real limits and real odds before they play.
If you do any ads, perks, or links for pay, mark them. In the U.S., the FTC Endorsement Guides explain how to make a clear, honest note so players know when a link is paid.
A one‑page style sheet keeps every writer and editor in sync. It saves time and stops drift in terms and tone. Use it to set calls on “you” vs. “player,” number style (3 or three), caps on terms, and the choice of modal verbs.
Example lines:
For deep rule craft, few texts beat the Magic: The Gathering Comprehensive Rules. It is long, but it shows how to handle timing, layers, and conflicts with care.
For a tight, entry‑level rulebook, read the Catan official rules. Note the layout, the icons, and how examples sit near rules.
Talks in the GDC Vault give case studies on teaching, flow, and player goals. These help your voice and layout, not just your rules.
We had “When you move, you can pass through allies.” Players read “can” as permission, not ability. They tried to pass through foes too. We changed it to “You may move through allies. You cannot move through foes.” Tests showed zero stops after that.
Great rules do not shout. They guide. They let play shine. Write for action, test for proof, and keep words small and firm. Your table will thank you.
In games, no. Use “must” for force. “Shall” sounds legal and stiff, and many readers find it vague.
Use clear flags: “Except during setup…” or “Unless a card says otherwise…” Place the rule and its exception close together.
You give the rulebook to a group and say nothing. You watch. You note where they stop or guess. Then you fix the text that caused the stop.
Keep strategy out of core rules. Put tips in side notes, a guide at the end, or on the web. Use “should,” not “must,” so players know it is advice.
Alex Morgan is a UX writer and editor who builds rulebooks and onboarding flows for tabletop and digital games. Alex has led blind playtests, set house style sheets, and helped teams localize rules into seven languages.
Published: — Last updated: