Probably the biggest mistake I made in the text of Gaslands was treating the players like computers. Re-editing the rulebook in preparation for the new Gaslands: Refuelled edition of the game gave me an opportunity to revisit and revision my some of my approaches to presenting wargame rules, and this was a big learning area for me.
In software, one always looks for opportunities to create functions: reusable definitions for some action or object that can be referenced from multiple places with a predictable outcome.
Wargames are full of opportunities to create functions.
If I write a rule than defines what happens when a vehicle is attacked by a flaming weapon, and call the rule “Fire”, then I merely need to make reference to the “Fire” rule later on and save myself a ton of copy and pasting. Once the player understands how the “Fire” rule works, they can be trusted to understand what is suppose to happen when they are shot by flaming bullets, or rammed by a flaming car, or drive over a flaming barricade.
The issue comes when this obsession with “never repeat yourself” results in players having to flip back and forth through the rulebook to decode how a specific interaction works.
This has been a relatively common complaint on the first version of Gaslands, with players saying that they sometimes feel lost and have to flip back and forth through the rulebook at the table to find all the rules they need in a given situation.
If It’s Important, Repeat It
Jarvis Johnson apparently says that if a rule is important, it should be repeated three times.
Instinctively, this feels wrong. In part, my experience of the open beta process with Gaslands may skew this. I had situations early on in the development process where certain rules appeared in multiple places in the rules text, and when I changed or improved a rule I wasn’t always successful in going back and finding all the duplicate mentions of a given rule. This led to confusion among the playtesters, where they wouldn’t know which conflicting wording of the rule to use.
Even if you are careful, the English language is a funny old thing, and if you don’t express the duplicate rule using EXACTLY the same words, in the same order, you are basically guaranteed to have someone use that alternative wording to misinterpret the rule.
As an example, the “main” rule text about starting an activation touching an obstruction says you must ignore that obstruction during your activation. If I repeat that rule in the collisions section in a slightly different wording, something like “remember you ignore obstructions you start an activation touching”, I guarantee I’ll have to publish an FAQ clarifying that the rule is indeed a “must”, regardless of the slightly weaker wording in the redundant repetition.
My solution was to be as disciplined as possible about treating rules as functions, never repeating myself, and instead making reference to the name of the rule, rather than repeating its content, when I needed to invoke it. That’s just good software writing, and game rules are just software that runs on players. Right?
Meatware
The problem with this approach, I have learnt, is that players are not computers. A rule definition that is many pages away in an unrelated section of the rules is not always going to be instantly and perfectly recalled by the player’s meat-based rules processing engine, and they will need to go looking for it. If that rule had been redundantly repeated in the place that invokes it, the rules will be more verbose, but likely more usable. To a point, of course.
A perfect example is the section, early on in the Gaslands rulebook, entitled “Touching an Obstacle”. This is a critical rule in Gaslands, it’s correct application at the table can genuinely be a decisive factor in whether a player has an awesome time playing Gaslands or gets stuck bumping against a wall for 45mins. It is crucial that players apply this rule correctly.
In the first version of Gaslands, this rule appears at the end of the section on collisions because, chronologically, that is the first time that the rule can theoretically trigger. However, the time that it actually MATTERS is at the start of the movement step. If nowhere else, it should appear there, otherwise a player flicking through that section trying to figure out if they are allowed to move might wrongly assume that, because they are touching an obstacle, they are stuck.
Oddly, I actually did repeat this rule in the section on terrain, in a rare concession to usability over purity, but it’s still not at all in the place it needs to be!
Refuelled
Some amount of functional rules writing is important, to increase readability and reduce word count. Some areas of the rules, such as the dreaded “final position” rules, make great “functions”. I can invoke several paragraphs of finicky specifics and exceptions with a two word phase, but other rules are happy to be repeated.
In the text of Gaslands: Refuelled, I have been much more careful about ensuring that small rules are repeated in places that invoke them, to increase the usability of the rulebook at the table. I have (gasp) copied and pasted exact duplicates of certain critical rules into different part of the rulebook, to ensure they are right in the places they are needed to understand how another rule work. This turned out to be rather freeing, and once embraced, creates obviously more readable text.
I’m happy to be have learnt this lesson, and I’ll be keeping it front of mind as I assemble the final text of A Billion Suns.
For more posts in this series on Editing Wargame Rules, click here.
Photo by David Hellmann on Unsplash