Mechanics Are Tools Part 1: Requirement and Permission Mechanics

Repeat after me: mechanics are worthless.


Yep, I said it. Your awesome 3d6 drop lowest+modifiers+a custom "destiny die" base mechanic? Worthless. Your lavishly detailed system for diabolic pacts? Worthless. Your thirteen pages of robot construction rules for your Steampunk Engineer character class? Worthless, worthless, worthless.

At least, worthless in and of themselves, without context or intention.You see, mechanics are a means to an end, a way of making the "perfect session" of your game-in-progress a regular occurrence rather than a fluke that takes a perfect storm of awesome players and an awesome GM  to work(assuming your game uses a GM). Just like any single screwdriver, tack hammer, or shovel, your Steampunk Engineer and it's robot construction rules might be a masterpiece of design or a piece of utter shit. But even if your Steampunk Engineer class is the best thing in the hobby since the polyhedral randomizer, it's useless to you if having a Steampunk Engineer class doesn't support what your game is about. To go back to the tool analogy, a beautifully made, rust-resistant, durable, perfectly machined screwdriver is still next to useless if you're trying to dig a ditch.

So you need to make sure that the mechanics you choose, and your implementation of those mechanics support your game's areas of focus. But in order to do that, we need to take a look at what we have in our metaphorical tool box: what types of mechanics we as game designers have to work with while designing a game.

The list that follows is made up of general categories, rather than specific rules like "Roll 1d20+modifiers" or "You gain 1 Drama point when you lie about your affair to your husband". To highlight how each category of mechanic can be used to accomplish a particular design goal, I'll design a rule off-the-cuff that works to fulfill the design goal of "Making magic feel magical." I'll also discuss the potential pitfalls associated with each type of mechanic; just like a hammer can stub your toe or a rusty blade can give you tetanus a mechanic that's improperly used, or a poor example of it's kind can end up biting you in the ass.

Requirements
These are rules which tell a player or the GM, what they've have to do. Requirements get used all the time in RPG design, but often we're not aware of them because their existence is taken for granted or implicit in the rules. A good example of this would be hypothetical fantasy game with axes as a weapon choice. You can't hit someone with an axe unless you have an axe. While it is true that in most fantasy rpgs you can't hit someone with an axe unless you have an axe, it's such a common-sense proposition that such a thing rarely needs to be spelled out.

The sort of Requirements that are more interesting for game designers are those that aren't "well duh" assumptions that come with the subject matter, but rules that call attention to the limits and purpose of an RPG by requiring specific things that jive with the game's genre, message, or tone. Here are couple of Requirements that might make their way into two very different games, both of which have "Making magic feel magical" as one of their design goals (the important parts are bolded):

1. In order to cast a spell, the magician must sacrifice something they truly love. 

2. In order to learn a spell the magician must perform a quest for the archdemon or archangel under whose influence the spell falls. 

Without knowing anything else about these two games and their two magic systems we already get a sense that we're looking at two very different animals.

In the first, being a magician is a road to ruin, whatever power it might grant you, and mages are driven into a continuous cycle of love and callous sacrifice if they want to keep casting spells. Using magic becomes a question of "do I want this more than I love my wife? My lands? My son?" and "when do I stop?"

In the second, even without knowing how magicians cast spells we know that in order for a magician to be a magician they've got to put themselves under the thumb of powerful angels or demons, at least temporarily. Playing a mage in this game would likely focus on struggling to balance your various obligations to different patrons, trying to subvert evil commands to a good end, and figuring out how to solve a problem without resorting to a spell granted by a patron who will ask a horrible price for that knowledge.

And all of that's without knowing what else makes up the game's system. Requirements are powerful tools, but they need to be used carefully. In order for a Requirement-based mechanic to really pop, it's got to:

1. They take action in order to fulfill: A requirement that a character, the player, or the GM can fulfill without acting is one that will get ignored or forgotten. You saw this sort of thing a lot with various iterations of D&D's class alignment requirements. When they weren't the cause of group-breaking fights over whatever the fuck "Lawful Good" means, they were usually just pushed under the rug so everyone could get back to the looting and dragon slaying.

A similar thing happens with stat prerequisites for various special abilities in high-detail games. Even if it's not house-ruled away by the group or ignored by cheating players, having to possess a certain amount of  Intelligence or Fluffiness, or Sex Appeal in order to qualify for something never comes up past those few seconds where the player is considering what doodads to select for their character. It never becomes an interesting issue in play. It doesn't require the player to do much of anything, or at least not anything that can be appreciated by the other players.

A good example of this principle in action is with Apocalypse World's MC principles, which are the rules for that game's GM to follow. When the Principles say things like "always say what honesty demands", that requires the GM to act in a way that requiring the player of the paladin to write down "lawful good" or requiring a stat prerequisite doesn't.

2. They're specific.   This point is a continuation of #1. Requirements have to be clear about what they're requiring of the player, of the GM, or of the group. This means either providing detailed examples of that requirement in play, or making it so obvious what the requirement means that there's no ambiguity about what it's asking for. Compare the two of these:

"Each scene narrated by a player must focus on an emotional issue."

"Each scene narrated by a player must focus on an issue from a single character's dark and troubled past"

One is incredibly vague. It tells you to do something (requiring action) but it doesn't really tell you what to do. The other is very similar, but it goes out of it's way to describe what sort of emotional issues are relevant to the game: the issues arising from a specific character's dark and troubled past. It tells you not just to do something, but also what to do and how to do it. Vague or wishy-washy requirements are worse than no requirements at all, because they cause uncertainty about what the point of the game is.


Note that specific in this case doesn't mean narrow. It just means that the game's system tells you how to fulfill the requirement. Apocalypse World's rules for the Seduce/Manipulate Move are one such example. To seduce or manipulate someone in that game, your character needs "leverage" over them. What's leverage? The game goes on to describe that it's something that the NPC or PC you're dealing with really wants (like a shiny new gun) or really doesn't want (like that shiny new gun putting a bullet in their brain), and it goes on to give specific in-play examples of what does and doesn't constitute leverage. Examples and clarifications of this type can turn a vague Restriction like "Each scene narrated by a player must focus on an emotional issue" into something more interesting an easy to use just by virtue of explaining what that means.

3. The Requirement Tells you Something About the Game. This is the big one. The biggest strength of roleplaying games as a medium compared to movies or video games or books is that within the bounds of the game's premise or genre most anything can happen. To justify limiting that wide-open creative potential, a Requirement has got to shout to the rooftops what your game is all about. If it's not doing so, either jack up the volume or scrap it.

Testing whether or not a requirement tells a reader what your game is all about is simple. Pick someone you know who knows next to nothing about RPGs beyond "it's a game of playing pretend with rules". Your mother, your father, your sister, your brother, your significant other...doesn't matter. Just ask them "what would you think a book/movie would be about where  ___________ had to _____________ in order to _____________?" The first blank is whoever's doing the action, the second is the requirement, and the third is the action or drama that the Requirement relates to. Depending on the requirement you may need to substitute "Director" or "Writer" for player or GM if they're not familiar with such concepts and your requirement relates to who has the right to describe scenes, or how the GM needs to set up conflicts or what have you.

If they look at you like you have tentacles growing from your eyes or just don't have a clear answer you need to make the Requirement more specifically reference your game. To do this, ask yourself "What makes my game different from every other (fantasy roleplaying game, near-future cyberpunk explosion fest, game about sentient blobs of lime jello, whatever)" and start from there when redesigning your Requirement. You can't help but come up with interesting ideas as a result.

Permissions
Permissions tell you what your players and/or GMs can do in the same way that Requirements tell them what they must do. Like with the section on Requirements, we're going to ignore for now those Permissions that are often left implicit in game design. "I have an axe, so I can now hit people with this axe" is self-evident in most systems that include axes, and is not terribly interesting as far as design goes.

Where Permission-based mechanics really shine is in showing your game's players and/or GM things that they can do that they might not of considered possible and do so in a way that highlights what your game is about. Once again going with the theme of "Making magic feel magical" here are two different examples of Permission based mechanics for two very different games (the important stuff is in bold):

"At the beginning of any scene including a magician, any player may draw down the wrath of heaven upon that magician's head."

"Any magician who knows a being's true name ignores that creature's resistances to his or her spells until the creature performs the Rite of Renunciation to change their true name."

Now the second, for those of you who are quick learners is a combination of a Requirement mechanic(knowing the creature's Truename) and a Permission mechanic (you get to ignore their magic resistance!). Often, the best Permission mechanics come along with one or more Requirements for their use to create the need of action, establish the tone of the game, and to make it more apparent when the permission mechanic may be used. In any case, it's clear to see that just by changing up what a Permission mechanic lets someone do we can establish vastly different visions of what magicians are like and what they're capable of.

When designing Permission mechanics consider the following:

1. Design Most Permissions with Requirements Your game's biggest and broadest permissions, like "the players portray monster hunters" or "the actions of the player's characters, and the responses of the GM's NPCs to those actions and so on is what creates the story" don't typically need requirements. But the smaller ones? The special abilities you've written into such-and-such a class, the new spell you're thinking of including, the super awesome equipment list you have full of geegaws and doodads though? Requirements are the way to go.

This isn't to short-circuit creativity or to "keep players in line" or anything so crude. It's because Requirements of the sort I've discussed earlier in this article provide context, create interest in, and require action of the person who's working with your spiffy Permission mechanic. Let's look at two examples of a special ability for an imaginary game focusing on the activities of mages:

"As a mage you can call forth demons from the pits of hell to serve you"
                                                   vs.
 "If you successfully strike a bargain with a demon, you can call it from  the pits of hell to serve you."

Which is more interesting? Which has the potential for more narrative twists, turns, and complications? The second one, no questions asked. In most circumstances, a mechanic that grants a player, a character, or the GM a new toy should be accompanied by some sort of Requirement governing it's use.

The only exception to this general rule is when a Permission mechanic is the basis of your game. If your game is all about the exploits of Demon-Summoning Mages fighting Cthulhuesque horrors in the Grimdark future of 3270, then you might not need the bit about having to strike a bargain with demons that you summon. The demons are just there to facilitate the explosions and action, and requirements take away from the real focus of the game. Remember, we're designing tools here. And when you design a tool, you've got to always ask yourself "Does this help the tool accomplish it's primary function?"

2. Permissions Should Give you Something New. In many games, a large number of Permission-based mechanics modify other mechanics. Sometimes these modifications have conditions attached to them, other times they don't, but they all share in common that they don't give anything new to the person who's making use of the rules. Let's compare the following two versions of the same "Talent" for characters in a hypothetical fantasy roleplaying game:

Warrior: Your character is skilled in the arts of war. They gain a +1 bonus to attack rolls.

Warrior: Your character is skilled in the arts of war. They gain a +1 bonus to attack rolls, and when you throw yourself into pitched battle against a foe the GM will tell you what makes your opponents weak that you can exploit.

Both technically give your character something new, but the second is a hell of a lot more interesting. It still modifies a preexisting mechanic (attack rolls), but it also grants an entirely new ability that no one else possesses with a Requirement attached to it that is specific, requires you to do something, and tells you a bit about the game (that warriors in this game aren't careful tacticians but brave champions that "throw themselves" into pitched battle. The first Talent is likely to get added into a characters attack bonus and then forgotten. The second will likely be used and referenced on a regular basis.

I don't need to tell you which is preferable from a design perspective.


As the length of this post has gotten away from me somewhat, I will continue this design article next week with Mechanics are Tools Part 2: Prohibition Mechanics and The Right Tool For The Right Job. It'll focus on the final category of mechanic commonly used in roleplaying games: prohibitions, or in simpler terms "things the game stops you from doing".

Accompanying that will be a section on ensuring that the mechanics you've designed with these guidelines in mind help you fulfill your design goals. Because a top of the line screwdriver is all well and good, but you're SOL if all you need to do is dig a ditch. For that, you need to get back to the drawing board, and start coming up with a good shovel.

Designing For Genre

"Live out the adventurers of Farfhd and the Grey Mouser!" (Barbarians of Lemuria)

"Be the last hope of the rebellion!" (Star Wars Saga Edition)

"It's like Twilight or True Blood except that all of the messy dysfunctional relationships are treated as messy and dysfunctional instead of romantic." (Monsterhearts)

"Yeah, it's kind of like Lord of the Rings, except a lot bloodier." (Burning Wheel)

Whether appropriate or not for the game in question, we as designers and gamers often pitch games based on comparisons to media, usually to a well known movie or series of books that fit into the same genre. Such comparisons give other people an idea of whether or not they'll like the game, as well as giving us a hook to recruit new gamers into the fold who might not know a d10 from a hole in the ground but who are die-hard fans of Firefly, or Lord of the Rings, or Pokemon (hey don't judge) or what have you.

When we as designers make games, we do the exact same thing when brainstorming a new game: we start with what we like about various media and try to distill that into game mechanics for others to enjoy. The difficulty comes in the transition from the thought "I like Firefly's tight-knit band of outcast smugglers and their adventures on the frontier of space" to "Here's mechanics x, y, and z that help give the feel of the Firefly universe". What to do, beyond Netflix binging on content you enjoy and hoping for a revelation?

Well consuming content of the genre that you want to emulate in your design is important. More important than raw consumption though, is pattern recognition. What types of characters make up the main cast? What sorts of antagonists and obstacles do the protagonists struggle with?  How are the obstacles that the main cast faces resolved most of the time (by violence, by intrigue, because of dumb luck, by combining the powers or talents of the main cast, through the power of friendship)? What motivates the protagonists (love, money, duty, saving their hides, loyalty to each other)?

Take a moment, and type these questions or similar questions of your own design out, with plenty of white space in between them. Print it out, and grab a notebook or notepad, then sit your butt down at your desk or on your couch and get ready to watch a bit of tv. Pick a tv series that you enjoy, and that belongs to a genre or tone that you're trying to design towards. It's time to binge yes, but this isn't the undirected binging of an addict. This is consumption with a purpose.

Via Netflix or Hulu or whatever on-demand tv service you subscribe to (or have a free trial with), bring up season 3 of the show you're using as your inspiration. If the tv show you selected didn't make it to season 3 for whatever reason, pick an episode from halfway into the show's run and start from there. This is important. Seasons 1 and 2 of a series are usually all about establishing stuff: the setting, the characters, the antagonists. By season 3 (or it's equivalent in a shorter-run series), the director has settled on a particular "voice", the characters have been established, and at least one narrative arc has been resolved with room hints of bigger stuff to come. It's when a show starts to show it's true colors, and before a change of direction in later seasons (often called "jumping the shark") has a chance to change what the show is about.

Now watch the entirety of season 3, the middle of the show's run if it didn't make it that far. After each episode, write down a brief summary-who the antagonists were, what the main characters did, who the characters focused on in the episode were, and how the episode's story got resolved (or if it didn't, then how the stakes were raised). Once you do this for each episode in the season, patterns should emerge.

Maybe every monster of the week the characters fight is a symbol of or a reflection of the main cast's problems (Supernatural and Buffy). Maybe the characters are a constant-bickering band of misfits who always manage to put their baggage to the side at the last minute to get one over on their opponents (Firefly and Agents of Shield). Maybe the power of acceptance and friendship always wins the day (My Little Pony, Pokemon). List any such commonalities that you notice in your notepad or notebook.

At this point you have a hodge-podge of observations written down from the "meat" of the show in question. Now pick 1 observation that has to do with who the main characters are, 1 observation that has to do with who the antagonists are, 1 observation that has to do with how the main characters deal with their problems, 1 observation about the tone of the action, and 1 observation of your choice.

These five observations are your blueprint, the design specs for your putative game. Every mechanic you design, every concept that makes it into your notes, every doodad you're tempted to throw into the system because "wouldn't it be cool if...?", should be weighed against how many of your the observations you've listed your mechanic encourages, reinforces, or enables.

How to do that? That's a subject for my next post: Mechanics are Tools, which will cover how to design specific mechanics to make your list of media-inspired observations (and your other design goals) a reality when your game is played.

What it's All About

Seize The Game was created out of my burning desire for a blog focused the on practical nuts-and-bolts oftabletop rpg design. One without confusing jargon, an ideological agenda, or any competing "filler" content. Just the tools to help you and your friends design your own tabletop rpg, create new content for an existing rpg, or just to patch your favorite game. Odds are, if you're a tabletop gamer then you're at least a little bit of a designer as well; and Seize the Game is the blog for you.

I'm aiming to post articles on a weekly basis. Each individual post will cover the tools one can use to design towards specific goals for your tabletop rpg, or how to deal with specific challenges that can come up during the design process. Like I said, real nuts-and-bolts stuff without a lot of space set aside for theorizing. While I'm familiar with most of the more common lenses through which to view rpgs and their design, I don't find them terribly useful when considering how individual mechanics impact game play and in my experience, that's where most design work takes place.

Moreover, I hope that this blog will be the beginning of a community where game designers of any stripe can come together to talk shop with, learn from, and critique the work of other like-minded people in an open and welcoming environment. So never hesitate to argue with, contradict, or dismantle my opinions via the comment section of this page; so long as such dialogue is respectful and honest the only thing it can do is enliven and strengthen gamer culture as a whole and this blog in particular.

Enough talk though. I can see that you've come because you're looking to (or have already started on) design(ing) a game, and need resources to help you do that. If that's the case, you're in good company and I hope that this is the beginning of a long and productive working relationship.


Regards,




-John