First and foremost, and this goes for all rulebooks, ever, including future printings of published games, put an icon glossary in your rulebook. List every symbol and what it means. Lists of components are de rigueur, but I rarely play games that tell me what the symbols mean. I judged 25 games for Cardboard Edison's contest this year, and none of the games had an icon glossary. Even if you think your icons are obvious, list what they mean. Dragging icons into a word document is not hard. If you have no other images in your rulebooks, still have the icons. (Keywords are consider icons for the purposes of this discussion.)
Prioritize being professional and usable over being clever. This dictum could apply to every aspect of the process, but here it means that your rulebook should be a rulebook. It should look and flow and be usable like a rulebook. If you try to make it look like something other than a rulebook, you will most likely compromise the usability. For instance, if your rulebook is laid out like a novel or a cookbook or an Ikea manual, your players/readers may have a harder time looking up rules questions. Do not make the rulebook a friction point in your game. Additionally, your writing should be clear and free of excess adjectives. Don't use the words fun, unique, or exciting in your rules. Don't use your rules to describe how you hope the players should feel. Don't put fluff in the rules, except as icon/component/action names. Fluff should only be added in after the rulebook is deemed usable and should not detract from usability. (If you are a UI/graphic designer professional, go nuts. You should already know where the boundaries are.)
Use an A/B mindset when writing rules. An A/B mindset just means to think "if A then X, if B then Y." A lot of rulebooks, even of published games, either are incomplete or feel incomplete because they fail to mention contingencies. Every time you write a rule also include a contingency rule for the opposite case scenario. If the rule is "draw a card," make sure that you include a rule for if there are no more cards to draw. Maybe the deck can't run out in a game, in which case you don't need the contingency rule. I see this most often in pass/fail rules. Designers will include what happens if you succeed in an action but not what happens if you fail. Leaving out these rules leads to players guessing what to do in a game. That's bad. We want to eliminate players guessing about rules. I consider a lack of contingencies mentioned in a rulebook to be an incomplete ruleset. Incomplete rules communicate incomplete mechanics. (This is especially bad when submitting to publishers or contests.) Writing a rulebook can also help you clarify how your mechanics work, in case you didn't have rules for certain things. So, pay attention to contingencies.
There are a number of rules exchanges available through fora. Many contests also function as rules feedback on rulebooks alone. I think that 'playtesting' your rulebook is a quick way to get mechanics feedback without having to set up formal playtests. I would suggest approaching rules exchanges for mechanics feedback, not just rules clarity/copyediting. I am sure every designer is capable of giving feedback on a game without playing it.
If you are just playtesting your rulebook, you can get away with imperfect formatting and a certain amount of incompleteness. If you are submitting to a publisher, your rulebook should be worded in a way that could be published as is, with enough icons, diagrams, and images included as necessary for the publisher to play without you there to explain. Treat contests like they are publishers in your level of professionalism expressed in the materials you submit.
If you need a template to get you started on rules, I am a big fan of Pencil First's rulebooks, or you can use my template and change it to suit your needs.
ShippBoard Games is a board game design blog that updates most Mondays.
I think the overall/problem is that there are two functions that need to be covered: we need to teach you how to play the game, and we need to give you an authoritative rules document to litigate disputes or resolve questions during play.
ReplyDeleteThe trouble is that most games have a single document that tries to cover both of these functions, and doesn't cover either of them particularly well.
I think for a publisher or contest submission, I'd err on the side of the former function, teaching you how to play the game. And I think contingency type stuff generally falls into the category of disruptive to teaching. For example, in Ticket to Ride, at some point you need to know that if three cards of the same color in the display you expunge the display, but you don't need to know that to get up and running as a player, and if I burden the rulebook with rules like that (as the TtR rulebook does), I'm making the game sound more confusing rather than less.
I believe Gabe B. with the Board Game Design Lab Podcast also has a pretty cool Google template to help design and layout rules for amateur designers (and probably for professional designers as well).
ReplyDelete