Writing War Gaming Rules Correctly

Robert Delwood
10 min readJul 7, 2019

--

There’s more to writing good rules than many think.

Possibly the most overlooked component of any game is the rules themselves. This is ironic since it’s the one component every game has to have. Even if there are no other parts or maps, the rules are the only way game designers have to convey their thoughts. As an example, archaeologists have found ancient games in tombs and while the components may be preserved for all time, without the rules we’re not sure how the game is played.

Good rules are overlooked since they provide all the information effortlessly. That’s the way it should be. Bad rules are complained about and can prevent the game from being played. This is what I’m trying to change. Richard Berg, the prolific game designer and, hence, rule writer, summed it up best when he asked “Who Cares? We didn’t come to read the rules, we came to play the game! Well, you can’t play the game unless you can read the rules.”

It’s easy to sidestep rules writing. Game designers have the onerous task of creating an interesting, playable, and balanced system. The focus and emphasis is on the imagination of new ideas, with the goal of innovating from scratch. Overlooked then, is the process to record those ideas. The burden goes to the rules writer who must know the system concepts expertly in order to communicate nuisances. As a result, a partnership is now formed between writer and designer.

Fortunately, most games’ rules are well written and clear. However, they could all be improved. These comments were originally meant for war games, which tend to have longer and more detailed rules. However, it also applies to any game. And that starts with understanding some basics. If you write rules keep the following in mind.

Rules as Technical Writing

It would be safest to see rules as technical writing. After all, they are conveying concepts that need to be clearly understood and succinctly written. Some concepts are simple but the quality measure is how well they convey the difficult or abstract ones. This can be seen in one of two ways: Language and familiarity.

Language

A commonly held attitude is that is a native speaker of English is always adequate to write formal papers. Run, not walk away, from this attitude. This may be true in general. It’s not the simple concepts I’m concerned about. Some rules are easy. “All units have three movement points.” But writing about complex or involved concepts is another matter. We’re not all trained to write clearly, and it’s no embarrassment to recognize that. For example, a too common of a case is an unclear antecedent. The classic Three Stooges comes to mind when attempting to hang a picture on a wall Moe tells Curly that “You hold the hammer and I’ll hold the nail. When I nod my head you hit it,” with comic mayhem following. For us, “After moving a unit from a city, it may no longer be supplied.” What may not be supplied? The city or the unit? Possible context aside, players now have to stop and figure this out. Perhaps even just “A unit moving from a city may no longer be supplied,” becomes clearer.

Familiarity

The first tenets of technical writing are You don’t know what you know, and You don’t know what they don’t know. A good example is from most horror movies. The escaped victim runs up to the local sheriff babbling about monsters, eating arms, Mary Joe JoEllen, and chainsaws. It’s comical because we know exactly what the victim means, we just saw that in the movie, but the sheriff has no clue. In fact, it goes as far as to frustrate us as the audience knowing the sheriff could kill the monster right now if only he did something.

A common case is when the designer writes the rules. After all, who knows more about the game than the designers? The trouble is that they have a familiarity with those concepts and may write the rules omitting some important information that is assumed to be known to everyone. Playtesters can encounter this, too, and not catch omissions or unclear points in the rules. To catch these familiarity omissions, have an outsider or someone less familiar with the game read the rules carefully. Another catch would be to read the rules anew after setting them aside for a while, perhaps two weeks.

Follow Turn Sequence

For the structure of the rules, consider presenting each rule in the turn sequence. Keep in mind, that rules serve two purposes. They are both an instruction set that will be read initially in page order, but they are also a reference guide that players will use during the game to address a specific issue. Following the turn sequence accomplishes both goals at once. They will be introduced to the rules in the same order they will likely be encountered. This also limits the forward referencing rules, or mentioning a rule before it is defined. Forward referencing is both disorienting for the reader and burdensome, having to interrupt the reading to look up a term or concept. And the rules in sequence allows readers to look up rules in a logical manner, such as actions early in the sequence appear early in the rules).

Term Consistency

Use the same term when referring to the same concept. Although elegant variation, using different terms for the same concept, may be appropriate in novels (avoiding reader boredom or emphasizing different aspects), with rules as with technical manuals, it only serves to confuse. On first occurrence, define the term, along with its abbreviation, noting the use of capitalization. Thereafter use that term, abbreviation, and capitalization strictly referring to that concept. For example, in the GMT game Onward Christian Soldiers, the activation pool (the set of chits drawn to determine movement sequence) is referred to in five separate ways: The Pool, Pool, AM Pool, Activation Pool, and as “a cup.” This is confusing. In contrast, the GMT games series, Great Battles of the American Civil War, gets it correct, defining the term as “Activation Markers (AM),” and thereafter using only either “Activation Marker” or “AM,” even keeping the capitalization correct. Better yet, just use one term. In our electronic age with copy and paste, there’s no reason not to.

Capitalization

Use capitalization for proper nouns and special terms only. Defining a term is usually enough. For example, “activation” may not need to be initial capital if it refers to the general concept of allowing a unit to make an action. In some instances, however, a term takes on a specific or nonstandard meaning. If an activation has a specific procedure associated with it, such as perhaps a die roll or a cost, then the initial capital of “Activation” may be needed to make it clear that that procedure is to be invoked. The two terms, Activation and activation can even be used in the same rule set since they now clearly refer to different concepts. But consistency is the key.

There are no firm rules about the use of capitalization. If there is no compelling reason to use them, then good practice would be not to use them. Understand that excessive or improper use becomes a difficulty for readers, having to stop and figure out if it’s already been introduced before, has a new meaning, is just a variation of an existing concept, or just a grammar mistake. Position in the sentence aside, capitalization instances such as Leader/leader, Force/force, Stop/stop, Space/space are confusing.

Grammar

This isn’t specific to rules writing but is just good writing practices.

Don’t use Latin. This includes via, i.e, e.g, and etc. No one knows what those really mean. If want to say for example for example, say for example, that is, in other words. They’re much more clear.

Vice versa. Go ahead and be explicit. For example, from GMT’s Shifting Sands:

Only Allied units may move between Khartoum and Aswan spaces, and vice versa.

The first part of the sentence is clear that it’s between those two spaces. Test this by replacing the vice versa and you get the awkward sentence:

Only Allied units may move between Khartoum and Aswan spaces, or between Aswan and Khartoum.

Keep it simple:

Only Allied units may move between Khartoum and Aswan spaces.

Similar concepts should be stated similarly. Don’t be bothered if two statements are similar. The following is a good example of this:

Full Supply: The supply status of units within three spaces of a Supply Source.
Limited Supply: The supply status of units that are more than three spaces from a Supply Source.

Notes

Use notes sparingly. They should only be used when clarifying a comment, or pointing out an implication, something is implied but not obvious. Do not use it to introduce a rule. For example:

Note: Units have three movement points.

In context, this is a rule, and not a note. Take the case of another example:

Combat Card: Combat Cards are a special type of Event that are played during the Combat Phase. Note: For simplicity the rules refer simply to Combat Cards rather than Combat Card Events.

Why would you even note that? It doesn’t do anything. It complicates things. They just explicitly defined a combat card as a combat card, and not a combat card event. The extra sentence just wasted our time.

Currency

Update the rules for the latest version of all terms. Players understand games evolve and concepts change during development. However, the rules need to reflect the current state of the game and this includes removing old concepts and updating new ones. In one case they didn’t even literally remove the placeholder:

The game should take xxx players xxx hours.

More common examples include referring to phases that are not in the game anymore, leaving in designer or playtest comments.

Rules as a Reference

Except for the first reading, the rules book will be used more like a reference book, so make rules easy to find. During the game, players look up specific rules to answer questions. Make references to material precisely and explicitly. Statements like “See Movement rules,” are weak since readers don’t know where to look. “See Movement below,” is likewise bad. Unless the rules are immediately attached to the same paragraph, the reference is vague. In some cases, it may refer to a mention elsewhere in the same section, in other cases, the mention may be several pages away. In addition, the rules format could change (as with living rules), and “below” may not be appropriate anymore. Precise references are much better. “See Movement, rule 12.0,” or even “See Movement 12.44,” to be exact.

In a similar way, consider having a glossary and an index. Both shortcut the rules some. The glossary allows readers to get a definition of the term without having to look up the rule itself. An index references the locations in the rules for the term. An index becomes more important with longer rules. But an index is also difficult to create correctly and should be done after the rules book is finished.

Consistency

Whichever style or format you choose, be consistent. Consistency is not a substitute for bad grammar but it does cover up a multitude of issues. However you do it, just do it the same way each time. Presenting the same information the same way each time also helps the reader such as defining acronyms on the first usage and then always use the acronyms.

Attention to Details

Pay attention to details. Whether God is the in details or the devil is, clearly there is importance there. This takes the most effort and diligence but there is an ultimate payoff in quality. Perhaps designers approach the rules book as an afterthought or that they have less interest in writing rules but the rules are the player’s first exposure to the game. A bad rules book experience can stop players from trying the game, or, at the least, bias them even before playing. That means even the best of game designs become minimized. And there’s no excuse for misspellings.

The best test is to review questions in forums. Every rules question posted in a forum is a failure of the rules. Period. Review the questions and change the rules. Living rules are the only way to go forward.

Content

Sometimes there are tricky concepts to explain. In those cases, write in short sentences, break down concepts into individual ideas, and carefully relate one idea to the next, tying them together. An example can often help

Editors

Many of these are issues that a good editor can fix. Find an editor and use them without restriction. Don’t get offended by their changes and don’t get defensive. If you work with anyone who thinks they’re above criticism, they’re not worth working with.

Other

See the companion article A Bad Example that shows in more detail what not to do.

Check out https://www.kathleenmercury.com/writing-rules.html. She has an outstanding article on rules writing.

Postscript

I made references, actually some unkind references, to game designer Richard Berg in this and an accompanying article. I held him to a higher standard, but no higher than he himself imposed on others. Richard passed away on July 29, 2019. He was a talented person, among other things a prolific game designer, with over 140 game credits. More importantly, he created perhaps 20 genres. His 1976 Gettysburg Terrible Swift Sword was my favorite. It reinvented Civil War games and influenced designs even today. However, he had a reputation of being acerbic and with acid-toned writings that distracted from his brilliance. I met him once at a 1978 Houston convention and found him cold, demeaning, and dismissive. I later heard of personal challenges and struggles that followed. I am not saying that I am excusing or accepting of these as a reason. I am saying he will be missed.

--

--

Robert Delwood
Robert Delwood

Written by Robert Delwood

Programmer/writer/programmer-writer. A former NASA engineer, he ensured astronauts had clean underwear. Yet, it was always about API documentation & automation.