Rules as Written

In the early days of 1st Edition D&D (AD&D), Gary Gygax made a point of saying that if you weren’t playing by the rules of the game, as they were presented in the rulebook, you weren’t really playing D&D. This was, apparently, a reaction to the number of non-TSR products that were popping up with people’s additional content, including adventures, monsters, spells, and so on, as well as alternative content, like house rules, classes, and so on. I’m just speculating, but I would guess it was the latter material that bothered him most.

This attitude was a striking departure from that of original D&D (OD&D), which was presented with a real “it’s all about imagination, do what you want” approach (inasmuch as it was presented with a design philosophy at all—to be clear, we’re reading between the lines extensively here). Once OD&D was out in the world, it was recognized that there were many different ways to play the game. House rules passed virally from group to group and eventually turned into unofficial published products.

When AD&D came out, it was really the first moment in the hobby when we started to talk about the right and wrong way of playing. While Gary’s statements about the topic weren’t particularly well-received, it did create a new mentality of the importance of playing by the rules as written. There was this idea, still prevalent today, that deviating from some exact reading of the rules from the book was not just wrong, but dangerous. Only the official rules were balanced, and other material, including your own modifications, would certainly ruin your game and bring your fun to an end.

Now, if you’ve read any of my other articles here, you can likely guess my feelings on the topic. I harken back to those earliest days of RPGs, when making your own modifications was an integral part of the fun. Soon after first playing, I hungrily devoured any material I could get my hands on. In particular, I liked the Arduin series, by author Dave Hargrave. Like the OD&D books, the Arduin books were poorly edited monstrosities, random collections of rules, creatures, spells, treasures, and adventures. Most importantly to me, though, they were wildly imaginative and opened doors to opportunities to play with a sensibility that went far afield from traditional fantasy. If you wanted Lovecraftian horrors, lightsabers, and insectoid PCs in your game, Arduin was there for you.

Today, there’s no shortage of weird alternate material for whatever game you play. My thoughts right now are less about the creation of such things, though, and instead how to make the base rules of a game more easily customized. How can you make a game that isn’t ruined by house rules or changes made by the players and GM? (That’s a facetious question, by the way—that kind of tinkering with a game never ruins it. It’s part of the fun.) More importantly, how do you make it easier, rather than harder, to customize a game?

One way is to make your game extremely modular. Some game systems, particularly those that have been around for a lot of years, are sort of like a house of cards. Change one thing about a particular character role, and suddenly unintended changes occur with other characters, the delicate balance between PCs and NPCs, or something else. Even if the house of cards doesn’t collapse, parts of it that you didn’t even want to tinker with might need to be rebuilt. This is often referred to as a cascade. One part of the game relies on another, and so changes to one result in changes to another. This is kind of like if your game based the number of skills a character knows on their Intelligence ability score. (This is known as a derived stat, as in, your number of skills is derived from your Intelligence score.) Change a character’s Intelligence, and suddenly the number of skills they have is incorrect, and you have to adjust. This is a pretty minor cascade, but it serves as an easy example for why it’s dangerous to have mechanics based on other mechanics. Because one change can cascade to another, which cascades to another, and so on.

Non-modular game systems also create conflicts when you’re trying to tinker with them. You might want to give a character an ability, but some facet of that ability directly contradicts an ability they already have. Imagine a sci-fi game that has heavily armored space knight characters. However, if my space knight wants to use psychic abilities, and the rules say that you can’t use such abilities while wearing armor, then does that mean I’m a space knight without their characteristic armor, or a psychic who can’t use their abilities until I take my armor off?

A modular game has few or no mechanics that rely on other mechanics. For example, in the new Cypher edition I’ve been working on, a player creates a “core character” that is fully playable, but is very simplistic. A core character has basic stats, a skill or two, and the number of wounds they can take before being debilitated (we call these wound boxes as shorthand, because they’re like boxes you fill in as you take damage). If a character was a house, the core character is the foundation. Core characters also have a descriptor, like Strong or Intelligent, that says a little about them with an additional skill and a bonus to an ability score. For some genres, a simple core character is great. If you’re playing normal teenagers in a horror game where you’re being stalked by a slasher, that feels right. Since Cypher is designed to work in multiple genres, this is an important consideration.

However, in some genres, more complexity and definition are needed. That’s where the modularity comes in. If you want to play an Aragorn-style character in an epic fantasy game, you want something that showcases their combat abilities but also their nobility. For that character, you have not just a descriptor, but also a type and a focus. Someone with Aragorn as their model might be a Mysterious Noble Warrior who Leads. Being a Noble Warrior doesn’t dictate their stats or how much damage the character can take, it gives additional points and wound boxes that you add to the core character you started with.

All descriptors, types, and foci work together, so you’re using these “modular pieces” to build your character. It’s a little like Lego blocks.

But we don’t need to just stop there. What about an Indiana Jones-style adventurer? He’s not a basic guy, but he’s not a fantasy hero like Aragorn either. Maybe for him, we take the core character and, in addition to his descriptor, Clever, we give him a focus like Explores. Indy is just a normal man, so he doesn’t need a type. Because not every character needs all three modular pieces. However, our GM might recognize that our adventurer needs to be able to really take a lot of punishment, like our model hero does in the movies. So they tell the player their character can take one additional minor and one additional moderate wound than a normal core character can. And maybe they even give them some additional points to distribute to their stats. Now he’s tough enough to fight a bunch of Nazis, but he’s still not going to be up for fighting dragons.

A modular system allows us to build a character the other way, too. In that epic fantasy, our Aragorn analog has an elf friend. Normally, “elf” would be a descriptor like Perceptive, but to do the elf archetype justice, they need to have their species and a descriptor. No problem. Just add perceptive to elf, so the character is a Perceptive Elf Archer who Moves Like the Wind. Since it’s all additive, a character could have multiple descriptors, multiple foci, and even—strange as it may seem—multiple types. (Useful if you’re trying to base your fantasy character on Elric or your sci-fi character on Data.) The bonuses and benefits you get from each component of your character just add together. It all stacks, and the stack can be as small or as tall as the GM wants in their game.

It’s not violating the rules as written to mix and match and stack all these options if that kind of modularity is in the rules as written.

This means that in a modular game system, the rules as written are just a starting point for the GM and players. It’s like sitting at a control panel with a bunch of levers you can pull, each giving the character something different. But pulling a lever never affects the abilities granted by one of the other levers. We might tell you what abilities you get when you are a starship pilot or if you can control magnetism, but you can mash those together however you want.

The way to have a game that is easily modified, hacked, or tinkered with is to build it that way from the very beginning.