Here at Cannibal Halfling we’ve been system hacking for more than six years: Taking game systems we know and love and making them do something else. In some cases this has been fairly concrete, like adding mecha to Genesys or designing a way to play Fiasco with two tables that switch it up at The Tilt. Other times we’ve gotten abstract, talking about dice or playing cards or what ‘advancement’ is. In every case, though, there’s been a common thread: We’ve looked at an existing piece of game design and, with our experience playing and running games, made it do something else.

This sort of hacking is both easier and harder than clean-sheet game design. We’re working with the assumption that the game we’ve chosen works, and works very well, for a core of what we want our game to be about. That means that as we address the things that it doesn’t do well or doesn’t do at all, we need to preserve the strengths that already incited us to pick the game in the first place. Luckily, hacking is built into the culture of roleplaying and, because of that, is often built into the games we play from go. Apocalypse World had an entire chapter on creating custom moves before anyone knew that there was a demand for it. Fate has structured essentially all of its rules supplements into ‘toolkits’ for helping you make the system do what you want. The OSR is predicated on backwards compatibility with the entire d20 universe. We are a hobby composed of hackers.

As long and proud as the system hacker tradition is, it’s still intimidating starting out. I remember reading the D&D 3.0 manuals where you were cautioned against changing the rules, and at 13 I was scared into believing in “game balance”, instead of seeing such an admonition as self-aggrandizing hooey as I do now. With that experience in mind, I want to help gamers start hacking with a mind towards making the changes they want and avoiding changes they don’t want. These guidelines won’t work all the time, but they will work most of the time. And if they don’t work? You can always go back to the rules as written. With that in mind, let’s consider rules as written, and how much they’re integrated into each other and all the various other bits of a game.

Integrated and non-integrated mechanics

Hacking an RPG system is intended to either change what a game does or how a game does. Good hacking is also predicated on the assumption that the system you’re starting with does enough good that it is the right choice for your hack. If another system does what you want better, start with that one; if no system truly does what you want then you’re designing your own and that’s bigger than what I’d consider a hack. The reason these are important baselines is because good hacking takes what the system does into consideration. Since you chose the right system for your game, messing around too much with the core mechanics is likely to make the outcome worse.

The first question you need to ask with any hack or rules modification is what you actually want that modification to do. In all likelihood you’re going to want one of two things: A new mechanic which does something not already done by the game, or a modification of a mechanic that changes how the game does something. In both cases you need to consider how that change is going to impact all other moving parts of the game, and the degree to which your new mechanic is integrated with the rest of the rules.

When I say a mechanic is integrated, what I really mean is that it either requires inputs from other mechanics in the game or it produces outputs which are required by other mechanics in the game. Consider, as an example, a system for generating random weather for a game. While the weather could have an effect on the events of play or produce mechanical consequences, weather is usually not integrated with other mechanics, and adding weather generation to a system that doesn’t have it isn’t going to touch most other mechanics. Systems that do have a lot of weather-related mechanics, such as Twilight:2000, will often have a weather generation system already written into the game (indeed, Twilight:2000 does have such a system).

Let’s use Twilight:2000 for another example, one of a mechanic that’s heavily integrated. I have recently worked on a hack that ports the setting of Cyberpunk 2020 into Twilight:2000. Now, the idea here was to mostly leave the mechanics alone and convert between the two systems, but there’s one heavily integrated mechanic from Cyberpunk 2020 that would need to be rewritten: Cyberware. The mechanics for cyberware in Cyberpunk 2020 are tied into the system at a fairly low level, and as such when I rewrote each piece of cyberware for Twilight:2000, everything needed to be rewritten. How the systems model scopes on guns is different, so the Smartlink augmentation had to be rewritten. How the systems treat movement is different, so skate feet had to be rewritten. When you want to add something that interacts with the core of a game, you’re often going to need to rewrite it from the ground up.

Non-integrated mechanics can be easily written to be system agnostic; in fact any supplement you see that markets itself as ‘system agnostic’ is, if written correctly, built around a completely non-integrated mechanic. This doesn’t necessarily mean that the supplement is simple, but rather that everything it does is self-contained. The issue with a self-contained system is that, especially in a more complex game, its usefulness will be limited. The key is to figure out how integrated your hack or supplement needs to be, and then write that integration in a way that plays nicely with the existing mechanics.

System modularity and information flow

Integrated mechanics share information with each other. If you’re writing a spell in D&D, how long it takes to cast and whether it has verbal or somatic components provide pieces of information that are used by other elements of the game, like the combat system. In this way, spells are modular; they can be written one by one and the information needed to make a spell work is going to be the same pretty much every time. The idea of modularity is even written into the core of some generic systems: Hero System is famous for modeling everything using the same underlying mechanics, to the point that a gun and a fireball spell are described as the same core effect (with different modifiers). Similarly, EABA is built around ‘The Chart’, so that a nearly exhaustive list of modifiers are all scaled to each other consistently. Both of these games intend to make it easy to port in something from the real world or fiction with a known and understood effect and turn into a legal game element very quickly. The primary limitation of this approach is that it is solely for “physics engine” modeling of cause and effect. When looking at modular systems for narrative you find things like PbtA and Fate. Fate is incredibly modular; while the game has a few different mechanics for character differentiation (skills and approaches), it’s also built around the idea that pretty much anything can be modeled as a character and any ability can be modeled as an Aspect. Need more detail? There’s one more catch-all, Extras, and in reality those three elements are used to model everything (although it’s seen as core to the game, Stunts are in a way just a very important Extra). Of course, this means that Fate can be as dizzying and complex as the Hero System, which is why this level of editability is only discussed at length in the System Toolkit and the core rulebooks describe default modes of playing instead of the system laid bare.

The advantage of big, modular mechanics is that they’re easy to hack and write for. Either the information needed is minimal because the mechanic is externally consistent (like Aspects from Fate), or the information needed is incredibly clear because the mechanic is internally consistent (like The Chart from EABA). The problem with these big modular games is that you still want to differentiate everything and make characters feel different and unique. You’re either going to flatten things out, making your gun and your fireball act too close to the same, or you’re going to go completely fractal, adding special cases and new rules until you’ve doubled or tripled the length of the game. There is a middle ground, though, and that’s where the example of PbtA comes in.

A good PbtA game is modular, yes, but it usually has distinct modules and mechanics which make good PbtA games feel distinct from each other. Masks and Apocalypse World both have Moves, yes, but only in Masks is ‘shifting your labels’ a core mechanic. If you’re creating new Moves or new Playbooks as part of hacking Masks, you need your new material to reflect (and feed information back to) that mechanic, or your hack isn’t going to work very well. Same goes for how the game treats advancement, or combat, or injury. In PbtA it’s easy to assess this because most mechanical interactions with the world are in the form of Moves, and there’s a big library of Moves to help an aspiring hacker determine if their execution is going to have the intended effect. In most other games this isn’t as clear, but the same logic often applies. You know what situation your mechanic is for, and where it hooks into the rest of the rules. All you need to do is write (or borrow) a mechanic that does what you want it to do, and then figure out the math for that mechanic to have all of the requisite impacts on characters or the environment within the context of the existing rules.

---

Talking about rules as entities and separable modules is all fine and good, but quite abstract. How do you apply this information? First, you need to know what you’re writing and what you want it to do. Easy enough. Then, you need to understand what it will take to translate your ‘thing’ into the rules of the system you’re using. When Seamus wrote Genesys Mecha, the first step of this was figuring out how much extra detail the Genesys vehicles system needed to make mecha feel unique and interesting. There was more, though, because to fully support writing characters to use these mecha, some skills needed to be added, as well as new character archetypes to emulate the genre. Finally, you need to understand how you just changed the game, and if there’s any additional work to support that. To continue the Genesys Mecha example, this is where minions and adversaries came in: Mecha pilots are on their own power level compared to typical Genesys player characters, so a bunch of mech-piloting enemies were needed to make the hack truly playable.

Are all hacks as big and ambitious as Genesys Mecha? Not necessarily, but that depends on how much detail you want the game to have. If you’re playing Fate, a whole lot of interesting stuff can be boiled down to an Aspect, or a stunt. If it’s a secondary element, that may be fine. If you want to write a fantasy campaign with a detailed magic system, though, just having Aspects tagged as ‘magical’ may be unsatisfying; you may want to write a detailed magic system as its own Extra instead.

It’s probably not strictly necessary to approach mechanics in terms of how ‘integrated’ or ‘modular’ they are, but I think it’s a good way to look at game systems with a hacker’s eye. Next time you read a new game, try and notice which mechanics feed information into which other mechanics. If you wanted to take a whole mechanic out and replace it with something else, what are the information ‘pipes’ you need to hook back up to ensure everything still works? What are the core bits of ‘tech’ you can swap in and out or add to? Are they items? Spells? Special abilities? Moves? And keep in mind the same exact logic works for low-level mechanics too. Could you replace hit points with something else? How else could you advance characters besides encounters or milestones? What would a different dice mechanic look like? Once you see game systems as discrete rules modules which flow information back and forth, it becomes easy to pick at the boundaries between these modules and figure out how to swap them back and forth. Some systems are going to be easier to hack, whether they’re highly modular and adaptable like Fate or just have decades of content already written like d20 games in the OSR. Even if your game of choice isn’t easy like one of those, writing your own system hack can still be easy and fun if you take some time to figure out how things work. All you need to do is write down some ideas, run some mini playtests, and sketch up your new mechanic into a full-fledged system hack.

Like what Cannibal Halfling Gaming is doing and want to help us bring games and gamers together? First, you can follow me @LevelOneWonk@dice.camp for RPG commentary, relevant retweets, and maybe some rambling. You can also find our Discord channel and drop in to chat with our authors and get every new post as it comes out. You can travel to DriveThruRPG through one of our fine and elegantly-crafted links, which generates credit that lets us get more games to work with! Finally, you can support us directly on Patreon, which lets us cover costs, pay our contributors, and save up for projects. Thanks for reading!