I was lucky enough to have both Gav Thorpe (clang!) and Andy Chambers (clang!) look over an early version of the text for A Billion Suns, which is to be my next published game.
They both agreed that my rules editing suffered from a slavishly chronological structure. Much like the first Gaslands rulebook, I was introducing all the additional rules and details that applied to a specific phase of the game all at the same time, rather than providing a framework and then filling in details later.
Gaslands is not a simple game. I believe it to be intuitive, and easy to explain at the table, but I believe it is a relatively complex game, particularly compared to many similarly skirmish-sized games, once all the layers are in place. Introducing this complexity to new players in a progressive way, in which concepts build naturally and intuitively on top of each other towards car combat nirvana, is critical.
Editing as Arts & Crafts
I thought a lot about this feedback from the experts. I knew I needed to apply it to Gaslands: Refuelled. I needed a new structure for the Gaslands rules. I tried tentatively moving some paragraphs around, but I couldn’t see it.
In frustration, I printed the rules out on full A4 pages, single sided. I took some scissors and some blu-tac and went to work. I cut up every page into strips, so that every rule or sub-section was separate. I put two columns on my French-windows: “basic rules” and “additional rules”.
One by one, I picked up a rule and asked: “Are you essential to understanding the basic flow of the game?”
It was pretty easy. The rules naturally fell into one column or another. On the one side was all the basic stuff you need during pretty much every turn. On the other side was a bunch of more complicated and fiddling stuff that only comes up in every third activation.
I moved a couple of things back and forth, trying to find the right balance. Was the standard “slide” move a basic rule or an additional rule? Are trivial manoeuvres important enough to be in the basic rules section?
After this process, I had a draft version of Gaslands, divided into “Basic Rules”, “Additional Rules” and “Advanced Rules”. The goal was to provide a very basic outline of the game’s shape in the “Basic Rules”, skipping over all the edge cases and exceptions to the main flow, and then layer on detail progressively. I wanted to give the reader has an end-to-end understanding of the flow of the core rules before overloading them with additional details.
Happy Path
I’ve written before that I’m a software product manager, and this inevitably influences the way I think about both game design and game writing. It has actually steering me badly wrong on at least one occasion (which I’ll dig into in another post in this series). However, it does provide some useful patterns on which to model some of what I’m discovering in my game design journey.
There is (a slightly unfashionable now) analysis tool in software development called the “use case”. Use cases have multiple sections, but the one that springs to mind here is the idea of “Happy Paths” and “Alternative Paths”. The happy path is the main flow of the user experience, assuming the user clicks all the right buttons in the right order to complete their task, doesn’t stumble or deviate, doesn’t enter any bad data, and the system works perfectly. It describes the platonic ideal of the user flow, without worrying about any of the possible exceptions, alternately paths, errors or mistakes that can occur.
Once the happy path is described, you can then create any number of alternative paths to describe situations when something goes wrong, or the user deviates from the core path, or they do something non-standard, or an edge case emerges. I’ve generally found that having these alternate paths make the system design more robust, but going too far is a waste of time, as there are diminishing returns.
I’ve starting thinking about the layout of my rules in the same terms. The “basic rules” should describe the basic shape of the game, with the fewest rules to get the reader from the start to the end of the turn. Anything deviates play from the most basic happy path should be held back into a subsequent section. In this way, the reader has an end-to-end understanding of the game, and a grasp of it key terms, with which to contextualise all the subsequent exceptions and additional details.
Additional Rules
Once the happy path is described, the “additional rules” section then adds on everything else that is essential to make the game work. These are not intended to be optional rules, and the section makes it clear that the basic rules plus the additional rules form the core rules of Gaslands. These additional rules add a lot of the things that transform the basic engine of the game into a humming fun machine. The game basically works without them, but you would quickly encounter situations that weren’t covered.
There are two kinds of things I moved out of the basic rules in the additional rules: delightful things and situational things. “Delightful things” includes stuff like “push it” and “touch it, use it”, which you don’t strictly need to make the game work, but which make the game more fun, or fix little moments that would otherwise be frustrating. “Situational things” includes stuff like collisions, which are a core part of the game, but which you don’t need to know about until they occur.
Advanced Rules
Even things like rules for terrain, which are not strictly required to enjoy a game of Gaslands, are bumped into the “Advanced Rules” section, in order that players can read the minimum number of words prior to getting a game on the table.
Similarly, I have reduced the selection of weapons and vehicles that are initially presented alongside the team construction rules, so that players get an easy ramp into customising teams without having to digest 10 pages of detailed options and rules exceptions. These “basic vehicle types” amply cover the common shapes of toy cars, and the “basic weapons” are those that have absolutely zero special rules: they just follow the core shooting rules presented in the basic rules. My hope is that once players understand how to shoot a machine gun at someone, they will find the more complex weapons less daunting, as they will already have a solid foundation in the shooting mechanics.
In many respects, the staging introduction of these increasingly exception-led rules mirrors the game design process. First I establish the core mechanics and only after those are stable and understood do I start to play around with them, providing new rules that create interesting exceptions to those established mechanics.
I am really happy with this personal realisation. I think I’m going to refer to this pattern as “progressive sophistication” from now on, in order to focus my attention on it in future as a successful strategy for communicating a rules system.
You can check out the rest of the posts in this series here.