|[Image stolen from Dan Brady on Flickr]|
My experience so far is limited, but I am moving along. The one tabletop game rulebook I have presented to the world as "finished" (I Know An Old Woman) has already received feedback helping me to locate more places where things are unclear -- and this is a very simple game, which just goes to show how far I have yet to go. I have also helped with proofreading rules for other designers (helping to build up my ability to spot problems) and am in the process of helping rewrite a translation of the rules of a foreign language game.
I figure that one of the best ways of getting experience and building my skills is to just get out and help people out. There is only so much time each week, but I can fit some work on other people's projects in between my own. It isn't hard to find this sort of work on a voluntary basis: the forums on Board Game Geek, for example, regularly have people requesting help with various aspects of their games, including the rules.
Of course, these two aren't really disagreeing: Gravelyn is aiming to cut out useless text, while Pulsipher is warning against cutting out too much, as you may impede understanding. Basically, the acceptable length and complexity of game rules depends on your target audience. In the end, you need to test the effectiveness of your rules.
A really great resource is a discussion from the Metatopia game design convention, featuring Geoff Engelstein (of Space Cadets and the Ludology podcast) and Gil Hova (of Battle Merchants and the Breaking Into Boardgames podcast). This is almost an hour of solid gold with a lot of good advice, but I think one of the most interesting parts of the discussion is about how rulebooks need to meet two mutually-encumbering objectives: to provide a tutorial for the game and a reference for once you have learnt the basics. The big take-away though is that writing rulebooks is hard and even very experienced people get it wrong.
A little more in-your-face is a talk given by Mike Selinker (of... almost everywhere) at PAX Dev, where he gives 10 rules (well, 11) for writing rules, with examples of a whole heap of traps you can easily fall into and how you can keep out of them. The talk is based on an essay he wrote in The Kobold Guide to Board Game Design, which is a book full of useful advice from a great many knowledgeable people. The majority of Selinker's rules can, I think, be summed up by "don't try to be too clever."
From all this stuff along with other sources, plus my own meagre experience, I am starting to build my own principles that I will try to use to guide my rulebook writing. The top of my list is currently as follows:
- State, in general terms, how to win the game right at the start of the rules. Details can come later, but the general idea needs to be there before anything else is explained in order to give context for everything that follows.
- Closely connected to this, the rulebook needs to convey some level-zero heuristics. This is a slightly technical term (see Characteristics of Games for plenty of discussion on heuristics), but basically I mean that on reading the rules, the players need to have a general idea about what they need to do to play the game and have a chance of doing OK. If the players start with no idea of what to do, that is a failure of the rules.
- Keep the language simple and consistent. It may be necessary to define special terms, but do so sparingly and be really careful to stick to those definitions.
- Don't be afraid to repeat yourself in the rules in order to make sure that information is in appropriate places, but remember that if a rule is repeated, this adds an overhead for editing as a change in one place means checking everywhere else.
- Proofreading is necessary but not sufficient. A proofreader may decide that the rules read just fine, but someone trying to learn and play the game from the written rules may still have all manner of problems. Blind playtesting the rules is essential.