Written rules are not ideal. Unfortunately, what IS ideal is usually not possible.

Written rules are not ideal. But the Star Trek Holodeck is not yet reality.

If you don't understand what you're trying to accomplish when you write a set of rules, they'll never be suitable.

A game design document tells the artists, programmers, sound people what to make. There's an enormous amount of detail, more than a tabletop game's rules because EVERYTHING must be described.

But will the others read it? Often not. So designers have experimented with alternatives.

Knowing your objectives, your worst enemy is the human tendency to "satisfice", to do just enough to get by, which has become much more prevalent in this century because of so many distractions and the "Age of Instant Gratification".

The biggest problem is writing is that other people don't think like you. In rules-writing, the additional problem is that you know your game too well., far, far better than the reader will. You have to put yourself in the reader's place to see what they might misunderstand.

I've seen so many people - even demo-people at conventions, who launch into details of gameplay without providing context or objective, that I felt a separate discussion was necessary. This applies to writing rules as well, of course.

Use plain English in rules, and write to an 8th grade (or lower) level. DON'T use jargon or abbreviations. (The US Army uses "BMNT". That stands for "Before Morning Nautical Twilight". What it means is, "dawn". Duh.)

Anyone who tries to entertain or inform MUST know who the audience is, because the audience determines how the creator proceeds.

It's difficult to create exercises that you can do when this is a no-grading format, but here's an attempt

You need to understand the difference between mechanics, rules, the rulebook, descriptions, and narrative game design documents. Here it is.

This screencast is from my large "Learning Game Design" course.

Game schools used to emphasize game design documents, which are long descriptions to tell programmers, artists, etc. how to make the software. But now we're moving away from them for various reasons. Tabletoppers don't use them at all, they just make the prototype and write the rules.

From my "Learning Game Design" course.

Many game documents are marketing documents for games that do not yet exist (video games). They are written to help convince a publisher or investor to put up the money to enable the game to be created.

This is one of my simplest games, contrast with the vastly-longer rules for Britannia, later in the course.

I include this and the next set of rules to illustrate how much rules can change, even simple ones. Some of the changes are actual changes in the game, others are clarifications to cover situations that come up in playtesting.

(The 414 is month and year.) I don't count each change as a new set of rules, only major changes that I save separately. So I have five different sets of Sea Kings rules saved.

One reason why this is so much longer is that I devised a variant for the game that involves much more direct conflict.

Is there a rule of thumb for how long rules should be? No. Use common sense, but remember, it's better to be long, than to leave things out.

Unless you are self-publishing, you can write with whatever you're comfortable with. Publishers don't want you to do the formatting, they'll do it. Most good word processors will let you add graphics for rules blind-testing.

Almost no one wants to read rules. And rules are, after all, a set of instructions. Try to use a friendly, personal tone to make the task less like reading a manual! Use the active rather than passive voice, to make the rules seem less formal (and more straightforward).

What can you do, when writing rules, about people who "skim" when they read? In the end, not a lot, if people want to be functionally illiterate, then they're not going to get everything from a set of rules no matter what you do. But there are some ways to mitigate the problem.

"Big words" often express meaning better than several small ones, but only if the reader/listener knows the word. For game rules you have to assume they don't, that the reader has about an 8th grade education (or lower for children's games, of course).

Rules used to be written for later reference, usually numbered, more like a technical manual or instruction set. Now they're written in more typical narrative and organized in the same order as rules would be encountered in actual play. This sequence of play makes it hard to look things up, but it's now most rules are written today.

"Close is good enough" is a bad motto for rules (or game design document) writing.

The Reference Rules version of Britannia as I submitted them to Fantasy Flight. When people had trouble with the FFG rewritten rules (next lecture) I'd give them a copy of these rules, which were generally regarded as clearer and more precise.

This is the Fantasy Flight Britannia rules - actually the revision for the second printing. This illustrates Sequence of Play pretty well. It also highlights another point: rewritten rules MUST be playtested. These rules were rewritten (in 2006) by someone who may not have EVER played the game, and almost certainly were not tested in play. FFG was in a big deadline crunch (after some delays at their end); I was given a week, a very busy week while I was teaching seated classes, to look at the rules, and I didn't catch all of the screwups. The remainder were fixed in 2008.

Rules need to provide a context so that the reader understands why they're being told "whatever it is". You need to briefly describe the objective (normally, how to win) early in the rules, then with all the details near the end.

Putting rules on cards, instead of in the instruction booklet, lets you put exceptions to the normal rules in a place where they're isolated, where they need not be considered until the player has the card. But they're not a solution to the fundamental problem of writing rules, that is, being clear and complete.

Some things you cannot "legislate" against. You can't prevent "out of game" behavior, such as cheating or metagame activity, no matter how much you'd like to. If it's in-game behavior that you don't like, saying so in the rules won't prevent people from doing it. Instead you need to redesign your game so that the undesirable behavior does not lead to success.

All but the simplest games can benefit from a Player's Aid (cheat sheet). Regard it as part of the rules, even though it will be printed separately in multiple copies (so that each player can have one).

You've seen how long the Britannia rules are. Here's a one-page reference I wrote for the same game. I now write one-page "Player's Aids" for almost every prototype game I design, and players find them very useful after they've been taught how to play (rather than read the rules).

Unfortunately I didn't think to do this until after the second edition was published. There will be such player's aids with the third editions.

Here's a player's aid for one of my games, vaguely Stratego-like, scheduled to be published in 2014. Remember that the player will have the board and pieces in front of him or her, and will have a general idea of what happens, so this will make more sense than it can to you.

Pac Convoy is a much simpler game than Britannia, but not simple enough that it doesn't benefit from the player's aid.

Here's an outline of sorts to follow for Sequence of Play rules.

Don't wait until "you're done" with the game design to write a formal set of rules?. I don't recommend writing them before any playtesting, but some designers prefer that even though it wastes some time (because the game will change so much).

Don't rely on someone else to write the rules, unless they have played the game a fair bit. If someone hasn't played the game, there will be fine points in the rules they don't understand and they will screw up.

Some say "a picture is worth a thousand words", but often in rules, a word is worth at least one picture. Graphics can be evocative, but rules must be precise. So use graphics sparingly (except in examples).

Even the best writers can benefit from suggestions. And some people really need editing of their writing. It's when the editor's changes become compulsory that problems can occur. Especially, when a publisher assigns a "developer" (a different meaning than in the video game world) to test and potentially modify a submitted game, the developer's preferences may override the designer's.

I hear a lot of claptrap that amounts to a belief, almost a religion, that somehow we can manage to say as much as we have in the past, with a lot fewer words. Yes, everyone wants to be concise, to say as much as possible with as few words, but concise blends into incomplete or incomprehensible. Don't screw up your rules by trying to be too brief.

This depends partly on your audience. More in the screencast.

A simple question, and inevitably the answer is "it depends". But in these days of Sequence of Play rather than Reference rules, less repetition is expected.

I describe the different overall approached you can take when writing a set of tabletop game rules.

The rules are the most important component of a published game. You need to test the rules just like you test everything else, and that means writing the rules fairly early in the process, revising and retesting them as you go along.

What do you do about people so inexperienced in games, and such poor readers, that they effectively make up their own rules, accidentally?

The original discussion I allude to at the beginning of this screencast is at:

http://boardgames.stackexchange.com/questions/9384/players-who-cant-seem-to-follow-the-rules-what-can-be-done

Blind testing - having someone play your game without your intervention of even presence, so they must read the rules to learn the game - is ideal, but it's hard to find reliable tabletop blind testers. REALLY HARD.

It's so easy to copy rules nowadays that you can assume yours will be. So why not distribute them before publication and gain some advantages?

"Living rules", updated regularly online, are convenient for players, but you can't expect most players to go and get them. Most will rely what's in the box, and that's where you must concentrate. "Patches" are a convenience of video games, not of tabletop games.

PAGE LAUBHEIMER: “A crucial point in discussing user errors is where to assign the blame for the error. The term ‘user error’ implies that the user is at fault for having done something wrong. Not so. The designer is at fault for making it too easy for the user to commit the error. Therefore, the solution to user errors is not to scold users, to ask them to try harder, or to give them more extensive training. The answer is to redesign the system to be less error prone.”

I like to include a box highlighting a few rules that are often missed, misunderstood, or forgotten. Readers have poor recognition and retention these days - help them out.

Most rule sets include Examples of Play, which are not actual rules, they're illustrations of how the rules look. Be sure the rules and the examples don't contradict one another!

Play-throughs are a combination of text and graphics to show players whether they're playing the game correctly. They take up a lot of space in the rulebook, however.

Frequently Asked Questions belong with website, companies - something that isn't highly organized and precise in the way that rules are. If there are questions, they should be incorporated into the rules. However, a "Frequently Missed or Misunderstood Rules" section is good, and I usually provide a one-page "cheatsheet" for players.

Keep in mind, calling something a FAQ begs people to overlook it, because a FAQ is supposed to be clarification, not new information.

Often there are alternative ways to play a game that are as good as the standard, or make it more attractive to certain kinds of players. Why not include those with the rules? Pros and cons.

Do you want to include hints about good play in your rulebook? It depends - be careful.

You can add designer's notes to game rules. What are they, where should they be, and do you actually want to use them?

Online aids will help some people learn how to play the game, or to play it correctly, at relatively little cost.

Online play aids don't have to be videos, they can be audio (podcasts).

In the 21st century, even as we say a picture is worth a thousand words, too many people "turn off" as soon as they see a flowcharts. Lookup tables, which aren't even pictures, are even worse. That's why most wargames, which once ALWAYS had a lookup table (the Combat Results Table) rarely do these days.

RPG rules are different from other game rules, because in tabletop RPGs a player can try to do ANYthing. How do you cope with this?

Rules translation is a can of worms, but there's not much a designer can do about it. Here are some "war stories".

I'm including these two sets of rules in the course to show how much a set of game rules can change. This first set (when I still called the game "Naval Doomstar" because it derives from another game) was not, of course, comprehensive. The second set is much closer to comprehensive, and also has additional scenarios. And it's nearly twice as long.

I'm including these two sets of rules in the course to show how much a set of game rules can change. This second set is much closer to comprehensive, and also has additional scenarios. And it's nearly twice as long.

This is ruleset #6, but the rules went through many more iterations. I don't renumber for minor changes, only for extensive changes or changes after a long interval.

There aren't many resources about rules writing, that's why I created this course. Here are clickable links to those mentioned in the video.

http://boardgamegeek.com/thread/405444/rule-book-writing

http://www.bgdf.com/node/608

http://www.grammarbook.com/grammar/effWrite.asp

http://numberless.net/blog/2007/04/09/how-to-write-rules-without-confusing-

people/

This is practical advice about writing well, advice that served my (computer networking) college and grad students well for many years. (Yes, even computer people need to write well.) I've attached a revision of my writing notes for students in Resources (with part 1)

This is practical advice about writing well, advice that served my (computer networking) college and grad students well for many years. (Yes, even computer people need to write well.) I've attached a revision of my writing notes for students in Resources (with part 1)

There's no substitute for writing and USING rules. Using them either to play, or at least to have people read them to provide feedback.

Lew's online courses and information sources

Why write a book in the 21st century, an era when people rarely read non-fiction books? And why a game design book? Here's why…

What makes my book "Game Design" unusual or unique?

This is a "brief" summary, rather than new material, of what's most important in this subject. Part 2