People are always asking me s$&%. It’s not enough that, week after week, I post literally thousands of words of solid gold gaming advice here on this site. I also have to put up with constant inquiries and requests. Now, I would LOVE to have the time to answer everyone’s requests – no, wait, that’s a lie. Even if I had the time to answer everyone’s requests, I have so much better s$&% to do in my life that I wouldn’t. And I really don’t like people. So, not having enough time is a good excuse and I’m grateful to have it.

See, here’s the thing: every GM eventually wants to be a game designer. Well, not every GM. But lots. Really, when you get down to it, there’s two types of GMs in the world. There’s the ones that are casual about it and just want to run fun games using published modules and then go home and not worry about gaming for a week. WHICH IS FINE. There is nothing wrong with that. But then, there’s the ones who want to create their own stuff. It starts simple enough with modifying an adventure or making their own dungeon. But then it grows into other s$&%. Custom monsters. New magic items. A campaign. A setting. A new class. New race. New rules.

The thing is, GMing really comes down to two things: performance art and creative endeavor. Some GMs love putting on a show for their friends. Some GMs love creating s$&%. Many love both. And the thing is, there are elements of both even if you prefer one or the other. When you’re running a game, even a published game, you have to make creative choices. The players will do something unexpected and idiotic and you have to figure out how, say, Strahd von Zarovich responds to being wedgied. And that’s after you figure out how to resolve a goddamned wedgie to begin with.

Once the creativity bug bites you, whether it was there from the start or whether it cropped up after you got tired of running the latest $50 nostalgia-grabby-bland-fest from WotC, once that bug bites you, there is one inevitable endpoint. You message ME on Facebook or send ME an e-mail and say “hey, I invented or want to invent this new thing, will you look at it and tell me what you think and/or help me invent it?”

Seriously. You cannot BELIEVE how often this happens. And I just can’t do it. I don’t have the time to look at every homebrew creation everyone sends me and offer a critique. It’s too much.

Also, please stop messaging on Facebook. I don’t respond. I don’t use Facebook to communicate. End of f$&%ing story. E-mail me. I have a public-facing e-mail address: theangrygamemaster@gmail.com. And don’t expect an answer in less than a week. Stop messaging me via other channels.

I’m really sorry.

Now, look, I can’t critique your s$&%. Sorry. But I can help you invent your s$&%. Sort of. DON’T E-MAIL ME A REQUEST TO INVENT S&$% FOR YOU! See, I also get lots of requests for help along the lines of “I have a new idea for a race or class or spell or new rules or whatever; how do I make the thing good?”

So, here’s what I’m going to do. As you know – or maybe you don’t – I try to alternate my content between two basic types of article. Articles for new and inexperienced gamers, like how to run games and write adventures, and more advanced s$&% like how to hack rules and change the game and understand the theoretical underpinnings of RPGs. Now, that second thing has been flapping around at kind of loose end for a while. I just keep posting little bulls$&% articles. But this article marks the start of a new ongoing series of topics. I’m going to start talking about how to hack your game. And I’m going to try and be exemplary about it. That is to say, in talking about how to hack your game, I’m going to use examples. I’m going to think through some hacking activities WHILE I explain how to think through some hacking activities. So, welcome to my new series on Becoming a F$&%ing Hack.

Now, in this series, I’m going to focus on D&D 5E. That’s not because I think it’s the best or anything. But I have to pick ONE system. And the reason D&D 5E is a good choice is because the basic rules are available for free (so you can get check them out and follow wrong) and because there isn’t much TO the rules. Pathfinder is also a good choice for hacking, but there’s so much content out there that it’s hard to be familiar with the system. Not to mention the fact that Pathfinder was based on D&D 3.5 and that was developed in a little more haphazard fashion than you might think. So 5E is approachable, available, and reasonably transparent. But that’s just for examples. Honestly, the CONCEPTS I discuss here are easily portable to any system. It’s just the examples that will draw on 5E, okay?

Now, don’t worry, this article is not just me promising some new articles in 5,000 words. Nope. In a second, we’re going to get to a few basic concepts and general advice about hacking your game. In fact, f$&% it, I’ve said enough. New series about hacking your game, using examples, got it? Good. Let’s dive in.

The Art of Hacking

Now, hacking is another one of those words that has been badly abused over the years. It’s just like that other type of hacking. If you watch movies, there’s one definition of hacking. If you read blogs and news stories on the internet, there’s another. And if you talk to the people who actually do it, there’s like six different other definitions and lots of jargon. So, I’m going to start by defining hacking. This is MY definition. If you don’t like it, I don’t give a f$&%. MY definition is USEFUL for MY series of articles. YOUR definition sucks. So let’s not have that fight okay.

Hacking is modifying an existing RPG game system to enhance the game experience or to create a new experience. Neat, huh? Doesn’t that sound so official? Yeah. But now let’s dig into it because the definition is still complicated and messy. But at least it’s useful.

First of all, it’s important to distinguish between a SYSTEM and a GAME. Dungeons & Dragons, Pathfinder, Numanuma, FATE, Dungeon Crawl Classics? Those AREN’T games. That’s super important to understand. The game is the actual adventure or scenario or module or whatever. And no, the campaign is not the game either. That’s more like franchise. To put it in very specific terms: Curse of Strahd is a game. Dungeons & Dragons is a system. Burnt Offerings is a game. Rise of the Runelords is a campaign. Pathfinder is a system.

So, what is a system? A system is a collection of RULES and GAME ELEMENTS that can be used to run or play a specific game. Dungeons & Dragons has a bunch of rules for ability checks and initiative and how magic works and what defines a character and all that crap. Those are RULES. Dungeons & Dragons also has a bunch of classes, monsters, spells, magic items, feats, deities, and even settings. Those are GAME ELEMENTS. The system is the sum total of all of the RULES and all of the GAME ELEMENTS.

But that’s not all a system is. And this is the part that drives some people absolutely f$&%ing bonkers. A system also has certain feel to it. A system has an AESTHETIC. That is, the way the game feels. Dungeons and Dragons FEELS very different from Numanuma and FATE. And the AESTHETIC comes from the RULES and GAME ELEMENTS. Specifically, they come from the interactions between the players and the RULES and GAME ELEMENTS. The combat rules of D&D, for example, create a highly strategic and tactical skirmish experience. They are much different from the encounter rules in FATE, which exists to create a character-driven and story-driven experience.

Now, you CAN break away from the design AESTHETIC of D&D or FATE or whatever. You can willingly depart from that, to any sort of greater or lesser extent you want, and the game will still work. But, the father you get from the design AESTHETIC, the more work you’ll have to do to get it to feel right and the more likely it is for the game to break down in some way.

Here’s another good, specific example: D&D doesn’t handle horror well. Horror is a particular aesthetic. It’s a FEEL. And horror relies on feelings of isolation, disempowerment, and hopelessness. Characters in D&D are very powerful, they have lots of tools at their disposal, those tools are designed specifically to be broadly useful, and they are designed to synergize well with other tools. And the system is designed to favor the players over the obstacles. Players are more likely to succeed than fail. To run an effective horror game, you have to find ways to deal with most or all of those aspects of the system. Contrast this with Call of Cthulhu. Investigators in CoC have a much smaller repertoire of tools and most of those tools are either highly specialized or mostly ineffective in the situations they find themselves in. And the obstacles are much more powerful than the investigators in general.

If you’re not willing to accept this s$&% because “D&D can be anything to anyone,” you can’t be a part of this series of articles. Because this series of articles is about being a f$&%ing adult. Being a mature designer and making good design decisions. And, ironically, if you can’t handle this series, you’ll miss out on exactly HOW to make D&D whatever YOU want. And that brings us around to hacking.

Ultimately, there’s only two types of hacking. First, there’s adding new GAME ELEMENTS. Second, there’s modifying or adding new RULES. Where do AESTHETICS come in? Well, because AESTHETICS are a holistic and emergent property of the game – that is, the FEEL of the game arises from the interaction between the players and the RULES and GAME ELEMENTS – that means whenever you hack the GAME ELEMENTS or hack the RULES, you can either MAINTAIN the game’s AESTHETICS or you can MODIFY the game’s AESTHETICS.

Put another way, you can hack the game elements without changing the core game experience. You can hack the rules without changing the core experience. Or you can change the core came experience by hacking both the rules of the game elements.

And those are the types of hacking we’re going to be exploring. Want to create a new spell? Cool. Want to add rules for mass combat? Cool. Want to make D&D into a angst-filled horror fest? Cool.

And, by the way, changing the AESTHETIC of a game can encompass anything from making the setting feel a little different to completely changing the setting.

Becoming a Hack 101

Now, let’s wrap up this introduction with a little bit of basic advice. I’m just going to throw a quick hodgepodge of really basic tips, tricks, and goals for successful game hacking. We’ll keep these in mind every time we do anything in this series.

Fail Fast, Then Iterate

First and foremost, understand this: the first draft of everything is s&%$. Every f$&% time. That’s why I don’t post my first drafts. Yeah, believe it or not, despite all the typos, I do edit this s$&%. It’s just almost impossible to catch your own mistakes. But I digress.

You’re going to invent something: a new spell, a new monster, a new rule, whatever. And it’s probably going to be garbage. There’s no way around that. And no matter how much you think and tinker and tweak, it’s still going to be garbage. See, no matter how smart you think you are and how much you know about the game, the fact is that the only way to test any rule or game element or game system or anything is to PLAY. That’s why we have the term PLAYTEST. And that’s also why I tend to discount all the “brilliant geniuses” in my comment section who respond to my rules hacks by telling me why they are bad and how they won’t work. Because those idiots can’t know. There’s only one way to know: play it.

Mark Rosewater, who is some guy who makes Yu-Gi-Oh! cards or something, once said in this podcast he does that the most important thing a designer can do is “fail fast, then iterate.” Whatever your idea is, get it into a playable form and play it. If it’s a Yu-Gi-Oh! card, put it on an index card and use it in a game. If it’s a monster, run it in a combat. If it’s a new role-playing game system, make some dummy characters and test that f$&%er.

A lot of e-mails I get are from people saying things like “I’ve been thinking about doing this thing and I have this idea, but I’m worried it might not work right and I’m not sure how this part will interact with that other thing and I’ve been tweaking the design and…” holy mother of f$&%, STOP DESIGNING. STOP F$&%ING DESIGNING! Take whatever crappy thing you have, slap it together into something you can try at the table, and TRY IT! THAT’S THE ONLY WAY.

Game design IS NOT a thoughtful activity. It isn’t a scientific activity. It isn’t something you do at a desk or on a computer. It’s something you do by testing and iterating. Slap something together, try it, then fix how it’s broken.

You Can’t Treat Your Game Like Porcelain

Now, if you’re a big ole professional developer making products for publication… well, what the f$&% are you doing taking advice from me? I’m no one. I’m just random schmuck on the internet who thinks he’s a goddamned genius. Go away.

Sorry…

Now, if you’re creating something for publication, that first bit of advice is good. Create, test, iterate, test, iterate, test, and so on. But most likely, if you’re reading this, you are probably just looking to modify your home game. You’re trying to create a new spell or monster or change a rule so that your game is more fun. And that means rounds and rounds of playtesting aren’t going to happen. Or rather, it means your game is going to be the playtest.

That’s okay for some stuff. If you’re testing a new rule or spell or whatever, something that will come up a lot during the game, you DO get to iterate it. Create the spell, give it to the wizard, and ask him to use it a lot. Then, watch what happens. Use the new rule and see how it works. Your ongoing game becomes the iteration and playtest.

Does that mean you might f$&% up your game? Yes. Yes, it does. It’s kind of like doing medical experiments on your own baby instead of ordering some foreign babies from a baby supply depot. But here’s the thing you can do with games that you can’t do with babies: you can roll things back. If things go horribly, horribly wrong, you can stop the game and say “whoa, whoa, I f$&%ed up inventing the nuclear suplex ability for your monk. We have to take it out right now. Sorry.” Done and done. You can’t do that if you’ve injected a baby with a badly designed genetic modification inside a retrovirus. But fortunately, as long as you have a willing partner, it’s pretty easy to make a new baby.

The point is, if you want to start hacking your game, you ARE endangering your game, but not as much as you think. As long as you’re willing to admit it when you f$&%ed up really bad, stop the game, and roll back the thing, you’re okay. And your players SHOULD be fine with it as long as you tell them up front that you’re testing a new spell, ability, rule, or whatever.

Don’t be afraid to break your game, but do stop before your game gets too broken. And then roll back whatever you have to roll back.

Now, that said, sometimes you’re going to invent something that will only ever come up in your game once. The most common thing GMs invent is new monsters. And most new monsters get one chance in the game. So, generally, iteration isn’t possible. But if it’s only for home use anyway, no big deal. Run the fight and hope it works, but be willing to step in if it doesn’t work. Sure, it’s better to use the monster a few times if you can, but a boss monster doesn’t always work that way.

Stick it Out

Now, here’s the corollary to the above rule: don’t be too quick to pull the plug. It’s really easy to panic when a fight starts to go bad and say “whoa, whoa, I f$&%ed up… let’s just say you win, okay, because that monster is going to wreck your s$&% if I don’t stop it.” Honestly, as crazy as this sounds, it’s better to let the monster wreck the players s$&% and then say “okay, so, I totally f$&%ed up… so I declare that you survived and it wasn’t a TPK and you dragged yourself away to this sheltered place to recover.” In other words, let the whole thing play out and then undo the results in a way that doesn’t warp reality TOO much.

Why? First of all, because GM’s tend to be too f$&%ing nervous and THINK they broke something when they really haven’t. Second of all, failure is remarkably instructive. Seeing that something is going wrong is less useful than watching exactly how it goes wrong and how badly wrong it goes. And that is extremely valuable. Even if all you’ve created is a monster that will be used once and discarded, it’s still better to watch the failure in all of its glory. Because whatever lessons you learn, you can apply them to your next creation.

Here’s the thing: anything less than a character death is not a big deal. Seriously. If the PCs spend extra resources and have to take an extra rest? No big deal. If the PCs lose a magical item they liked? No. Big. Deal. Seriously. The game is made up of gains and losses and the PCs have to deal with the world that is presented to them. And half the time, that world runs on random chance anyway. So, unless a PC is dead, it’s not a disaster worth rolling back, let alone stopping in the middle. And if a PC is dead, you can always rule they were only mostly dead after the disaster and let them sleep it off for an hour.

Apart from saving your game from disasters, the other impulse is to start iterating immediately. This tends to happen most often with new rules. You throw a new rule into the game and, before the first session is over, it just doesn’t seem to be doing what it should. So, you want to get it out of there, tweak it, and put a new version in place as quick as possible. Don’t do this either. Why? Because, it takes time for players to settle into a new rule or mechanic. And it takes time for YOU to settle into a new rule or mechanic. What looks like a problem might actually just be a period of adjustment or growing pains or people just not grokking how things work. But, beyond that, if you pull the rule out too soon, you might miss other problems and weird interactions that also need to be tweaked. Hell, your tweak might exacerbate a problem you didn’t even see because you pulled the rule too early.

So, when it comes to stuff that has a longer lifespan in the game, like new or modified rules, I always leave them in place for at least three sessions before I pull them out for tweaking or tossing. The first session is for people to get used to it. The second session is to see it in action. And the third session is when people exploit or break it.

Obviously, if something is actively causing an ongoing disaster, I pull it out sooner. But I try not to.

The Smallest Thing You Need

Look, RPGs are big, complicated systems. There’s lots of weird little moving parts and it’s not always obvious which parts are there for what reasons and how different parts interact with each other. And the bigger the change you make, the more other moving parts you’re going to rub your s$&% all over. And that means potential for s$&% to go wrong.

So, when it comes to designing anything, be it a new rule or a new spell or a new class, you always want to build the smallest possible thing. More directly, you ALWAYS want to make the smallest change possible. Big changes are more work and they are more likely to go wrong.

For example, suppose you want to give players the option to play a character specialized in using a specific weapon. Let’s say, hypothetically, you want to focus on guns. You could invent a new class, like, oh, say, the gunslinger. And you’d have to make a complete class and write all the class features and a level progression and all of that s$&%. But if you aim for the smallest design possible, maybe you might realize that everything you want to accomplish with that class could easily be accomplished by giving some new options to an existing class. For example, in Pathfinder or D&D 3.5, you could make a gunplay feat progression and make it available as a series of bonus fighter feats. Or as ranger feats in place of archery. In D&D 5E, it could be a subclass of ranger. Or it could be a single feat.

And that means, before you start designing anything, you have to challenge your own assumptions. Whenever you decide the game needs a new race, class, spell, system of magic, or monster, the first thing you need to do is ask if there’s another space you could fit your thing into instead? Instead of race, maybe subrace? Instead of class, maybe class option or feat? Instead of spell, maybe class ability? Instead of monster, maybe… well, it’s probably going to be a monster no matter what.

Don’t Reinvent the Wheel

The goal is always to do the least amount of work and build the least complex thing you can build, right? That saves you time and prevents unexpected disasters. Well, one of the best ways to avoid unexpected design work is to not design something. Not designing things is way easier than designing them. WAY EASIER. The thing is, there’s already a lot of crap in every RPG system. Especially games like D&D and Pathfinder. And sometimes, the thing you’re trying to do is something that already exists in the system in another form. You might have a neat idea for a magic item, but it might be kind of similar to a spell that already exists. Or a class feature. Or a monster ability. A rule you’re trying to design might be kind of similar to an optional rule in another book. In those cases, it’s almost always better to tweak those things and repurpose than it is to design from scratch. Partly because it saves work, but also because it might clue you in to potential problems.

For example, suppose you’re trying to build a monster that gives his allies some kind of bonus in battle through a battle cry because you want a leader creature that makes underlings better. In 5E, you COULD invent something from scratch. Or you COULD just remember that there are a few fighter Maneuvers that work as combat leadership abilities and look into ripping those off.

That means you need to be familiar with your system. Very familiar. So familiar that my last tip for basic hacking is this:

Know Thy System

Before you can start f$&%ing around with a game system, you really have to know that game system. You have to know the basic mechanics, you have to know the options that exist, you have to know the optional s$&%, you have to KNOW THE SYSTEM. And that doesn’t just mean you have to know the rulebooks. You also have to have a critical familiarity with the system. You have to understand the s$&% that sits underneath the system.

See, every system has patterns. Things work a certain way in the system. They aren’t always obvious, but they are always there. And that’s because, even when the designers of the game system don’t tell you, they had a specific idea in mind for how things should work. Well, in theory. In practice, sometimes designers are dumba$&es too. But it’s always best to assume the designers did something for a reason and try to work out what the reason is.

For example, you’ll notice in 5E that there aren’t a LOT of ways to really push your attack bonus up. But you’ll also notice that most PCs see their damage output increase substantially every four levels or so. That’s because, in D&D, they decided to keep the numbers needed to succeed on a task (attack, saving throw, or ability check) pretty tightly constrained. And because of that, they also kept armor classes and save DCs pretty tightly constrained. On the other hand, they decided that damage output should rise substantially as levels increase. The end result is that a high-level fighter isn’t much more likely to hit than a low level fighter, but they do a LOT more damage when they do.

So, now imagine you’re designing a new cantrip. And you want your cantrip to be this super accurate laser attack. You’ve noticed that cantrips scale with level. So you decide this cantrip will be different because the attack modifier scales with level while the damage remains pretty much the same. Now, in D&D 3.5 or Pathfinder, that’d work great because attack bonuses do rise with level whereas damage doesn’t rise so much. But in 5E, that spell would be useless at high levels because the amount of damage it would do wouldn’t be nearly enough, even if it never, ever misses.

The only way to learn these patterns is to ask a lot of questions of your system and then see if you can figure out the answers. Start by looking at some of the bigger game constructs and asking yourself what things are and are not a part of them. What do all races have in common? Is there any conspicuous thing that no race seems to do? What things make up a class? How many features can a feat have? Once you’ve gotten good at asking those questions and then figuring out the answers, you’ll start to see some patterns. And when you do identify a pattern, try to prove or disprove it. For example, does every class in D&D 5E have a resource management mechanic? At the same time, you can start challenging yourself by asking questions like “how much damage does a third level spell do” or “what’s the value of knocking someone prone in terms of damage?” Why would you ask those questions? What if you wanted to create a 3rd-level explosion spell that knocks everyone prone?

Compare and contrast the spells in the system. This cantrip just does damage, that one does less damage but slows opponents, and that one does damage over time. What does that tell you about the relative values of damage, damage over time, and slowing.

Unfortunately, part of being a good hacker is being willing to spend some time curled up on the couch with a copy of the Dungeon Master’s Guide and actually reading every f$&%ing rule and magical item description. And spending enough time with your books that you can remember which magic items do what and flip to them at a moment’s notice.

Pop quiz: in D&D 5E, which monster would you flip to if you wanted to see the Leadership ability? What about Reckless? What if you need an example of Innate Spellcasting? How many different kinds of monsters have poison abilities of some kind? What can poison do?

If you can’t answer those questions, maybe you need to spend some time tonight curled up with your Monster Manual.