Above: Introduction from Trickster: Champions of Time
- Theme: The first page should give you an overview of what the game is about thematically. "You're trying to deliver the most pizzas to different neighborhoods!"
- Strategy: Some more recent games go so far as to give you a very broad guide of how to win. "Your goal is to be the richest player! Make sure you build a money-making engine early or you'll be left behind!"
- Assumptions: Without those guidelines, if players see money on the table, with no other context, they’ll assume you’re trying to be the richest. If players see a point track around a board, they’ll assume the goal is to have the most points. (If that track represents points at all!)
Above: Component and term overview from Blood Rage
- Consistency: Be consistent about the use of game terms. Don’t call something a “unit” on page 1, a “troop” on page 2, etc. If a number on a card is called “value,” or “rank,” or just “number,” stick to that term throughout the rulebook.
- Exclusivity: Once you've established a game term, ake sure that term is exclusive to that concept. If your card has a big number on the front, and you refer to it as "number," then use "amount" or "quantity" when referring to multiples of a card.
- Proofing: Your editor should be able to catch both of these problem areas in your text before you go to layout, but even the most experienced editor can miss them. Make sure you get fresh eyes on the newest drafts specifically looking for these issues.
Above: Player setup from Voyages of Marco Polo
Contents and Setup
- List: When your game has a long list of components, that’s a great opportunity to include a visual example of each component. This also gives you an opportunity to standardize your terminology, as explained above.
- Diagrams: Show the overall game space set up before the start of play. Some games have central play areas that are so big that it wouldn’t be possible to adequately also show a player setup at the same scale. In those cases, it’s okay to split up the board setup from the player setup.
- Flags: Highlight key areas of the setup with numbered flags that correspond with the numbered list of setup instructions. Make sure these flags are small enough to not cover key game components and obvious enough to not be confused for a game component.
- Hybrids: Sometimes it’s possible to combine your contents list with a setup diagram. In those cases, I have listed my flagged components with a lettered list and flagged setup instructions with a numbered list. Hybrids can be tricky to lay out, so don't get committed to the idea too soon.
Above: Each action in Jaipur has its own color-coded page.
- Instruction-First: Most rulebooks are written as if players are being taught the game in real time. Here is a common structure:
• Story of the Game
• Goal of Play
• Component Anatomy
• How to Play
• Structure of a Round of Play
• Who Takes First Turn
• What You Do on Your Turn
• How to Score Points
• End of Round Upkeep, if any
• How the Game Ends
• End of Game Upkeep, if any
• Tiebreaker, if any
• Strategy, Tips, FAQ
• Glossary of Terms
• Expanded List of Cards/Tiles/Components
- Reference-First: Some rules are written to prioritize ease of reference after players have learned the game. You most often see this in lifestyle games like Magic: the Gathering, where the expectation is that new players are introduced to the game by friends or tutorial media. I don't recommend this style of rulebook, but it might be useful as a supplementary booklet.
- Limitations: No one learns the exact same way, nor does everyone teach the same way. If you can make a note in your rules about how this rulebook teaches this game, it can help all players get on the same page.
- Running Examples: If possible, connect your examples of play chronologically using the same fictional players throughout. Try to use player names that are short, sound different, and begin with different initial letters. (Bonus points if they're gender-inclusive. I like Abe, Beth, Cam, and Dee.)
Above: Uwe Rosenberg's commentary in Feast for Odin
- Flavor: After all this talk about the tedium of reading rules, you may feel compelled to break up the text with cool art, funny jokes, or historical factoids. Tread carefully!
- Art: If you use cool art, make sure it is distinctly NOT a game component so it doesn’t look like a diagram or example of play. I've seen rulebooks use early sketches of game art. They look cool, but are not spectacular enough to draw attention away from examples.
- Humor: Some game designers are funny. Some games are funny. But at a certain point you have to admit you're teaching a game, not practicing a second career as a comedian. If you use humor, take it out of the actual flow of instruction. Even a sarcastic start-player rule may not be appropriate if your game is otherwise serious.
- Commentary: Uwe Rosenberg actually appears in his own rulebooks as a little cartoon character, giving you some background on why rules are a certain way. Stefan Feld’s games include this concise reminders as a sidebar beside the full instructions. It's a nice touch, but most of us don't have the clout to occupy that much precious rulebook real estate. Usually your own commentary will have to be consolidated to footnotes, appendices, or even an online supplementary FAQ.
Above: Excerpt from Understanding Comics
- Comics: Whether showing Batman jumping across rooftops or a pawn across a board, we face the same challenge: Showing multiple steps within a single static image. I highly recommend reading Scott McCloud's Understanding Comics. I've found the lessons and concepts there to be extremely useful in ordering my diagrams, placing my captions, and knowing how much to fit into a single image.
- Compression: My ideal world would be a rulebook where each sentence is supplemented by a clear visual example. That takes a lot of space though. Publishers won't want to release a 36-page rulebook and anyway that size can be daunting to new players. For the sake of budgets and time, you'll have to work with your team to prioritize which rules absolutely must have visual examples.
- Playtesting: When you’re playtesting the game, take note when someone asks “Can I do ___?” “Why wouldn’t I do ___?” Address that in your text and example diagrams. For example, a common question in tactical games is whether you can move through occupied spaces. In your example, set up a scenario where a pawn does or does not do so.
- Accessibility: If you lean on color cues, make sure they’re accessible to all players. Use red OR green, use light blue OR yellow, and if you use brown, don’t use red, green, blue, or yellow. Make sure all text his highly contrasted against its background. (Dark on light, or light on dark, not grey on grey.)
Above: Scoring tile summary from Isle of Skye
- Size: If your game overview can be condensed enough to fit onto a small card or player board, do so. It will be easier for all players to not have to share one reference guide.
- Big Reference: Some reference guides are just too big for a single card, though. This is most often the case in a game with a large number of language-neutral components. Ideally, these should be kept to as few pages as possible as it will be passed around a lot. When it's not in use, it will most often be placed back in the box because it is so big.
- Frequently Anticipated Questions: BGG users often make and share their own player aids for games they’ve consistently had trouble teaching from the rulebook. That’s an unfortunate necessity, but it gives new rulebook writers and designers a headstart to know what concepts players need to be reminded of as they play. “Can you deliver, then move?” “Do you draw card at the start or end of a turn?” "What is actually worth points at the end of the game and how much?"
Do you have your own favorite rulebooks with their own little tricks? Share them in the comments below!