Different kinds of games reward different abilities. Pictionary rewards players' ability to draw recognizable clues and to guess the right answer from the clues other people draw. Poker rewards understanding the likelihood of winning with a particular hand, strategic betting, and bluffing. Candyland rewards the player with the best luck. I've talked before about the difference between strategy-oriented games that primarily reward understanding how the game rules work and other types of games where the rules are secondary to some other ability or talent (like trivia knowledge or throwing a ball through a hoop), usually in the context of my preference for role-playing games that reward creativity and storytelling ability rather than understanding of the rules.
While I tend to prefer to keep strategy gaming and story gaming mostly separate (I enjoy strategy games, but want something different out or role-playing), I can at least understand why some players prefer strategy-oriented RPGs or games that provide a mixture of strategy gaming and storytelling. It's a matter of personal preference, and most of the wrong ways to have fun are already illegal. But the way role-playing games work leads to another kind of play that doesn't really reward "rules mastery" so much as "rules fuckery." This kind of gaming often uses the language strategy gaming, but it's really something different.
Rules mastery, unlike rules fuckery, rewards actual gameplay. No matter how much time you spend memorizing chess strategies, that knowledge is only as useful as your ability to adapt them to the moves that your opponent makes. In a well-designed strategy game, it's impossible to create an "unbeatable" strategy. Some strategies are harder to beat than others, but there's always a chance of he killer strategy losing, either through the actions of other players or (in a game with random elements) through bad luck. Your chess gambit only works if your opponent falls for it and you can't buy Boardwalk and Park Place if you never land on them. A strategy game that allows players to create a strategy that can't be countered through gameplay is a flawed game design, and more rules tends to lead to more flaws. That's why the best strategy games are the ones with very simple rules that provide a wide range of possible outcomes.
Rules fuckery turns flawed game design into a feature rather than a bug and (conveniently enough for game companies) is usually based on introducing new rules or playing pieces with the potential (and sometimes the explicit intent) to change how the game works. In order to maintain rules mastery, you have to buy the new books or game pieces and figure out how the new elements change the game. Its' the "Mr. Suitcase" strategy of Magic deck building or the Games Workshop business model. At some point, "winning" the game becomes less about about how well you play the game or understand the rules than how much disposable cash you have lying around to buy new rulebooks and new miniatures and new expansion packs.
The storytelling element of role-playing makes RPGs ripe for rules expansions since it's easy to bring things that were previously "off-screen" into the game, introduce new sub-systems that provide more depth than the core rules, or just add some new monsters or character classes or magic items. RPG expansions are also cheaper than expansions for most other games since you just need text and maybe some artwork. You don't have to change the board, cast new miniatures, or create new playing pieces or cards. While not all rules expansions are intended to encourage rules fuckery, many of them do it unintentionally and a few companies have figured out that a half-assed supplement with a few well-placed game-breakers often sells just as well as (or better than) a well-crafted sourcebook that takes a lot more time and energy to create.
Before we start the blog, the essays for the latest round of Thought Eater are up at Playing D&D With Porn Stars. The entries are anonymous until voting is finished, so I can only tell you that I wrote one of them, but not which one. Vote for the ones you like best.
So, if you've been following along, you know that I've come to the realization that the "how to adapt the rules to the game you want to run section," which was originally a single chapter with some general advice, has turned into a whole section because it's kind of the central idea that makes the game adaptable instead of generic. The first chapter of that section is largely an overview of how to decide what aspects of the game need special rules and some very general guidelines. Subsequent chapters will describe how to actually construct different kinds of rules for your game.
Even though the introduction of the book already goes into considerable detail about the role that rules play in an RPG (I previously posted an earlier version of that particular manifesto here), part of deciding whether new rules are worth creating is asking "what do these rules accomplish." Since (hopefully) the core rules cover all the rules functions from the introduction, any new rule you add needs to add something to the gaming experience that's missing when you just use the basic rules. Since these considerations may be useful for other game designers, rules tinkerers, and DIY-types, I'm going to cut and paste them here. Just ignore the reference to Chapter XX.
To Clarify How The Ficton Works
A lot of special rules are really just clarifications of how ambiguous story elements work in the fictons of the game. Established ficton typically need less clarification than original ones unless you’re adding something new or exploring a part of the world that doesn’t get much (or any) screen time. If you’re playing a Supernatural game, everyone already knows how vampires work from watching the show. If you’re running a generic monster-hunting game, you’ll have to decide which version of vampires exists in your game. Are they disgusting rotting corpses, stylish European nobles, or moody goth kids?
To Clarify The Game Rules
Sometimes you know how something works in the world, but need to decide how to model it with game mechanics. For example, maybe you’ve decided that vampires can be killed by a stake through the heart. Since the basic combat rules don’t specify where an attack lands, you’ll have to figure out what kind of roll a player needs to make in order to stake a vamp. A lot of rules clarifications involve deciding what kind of trait describes unusual character abilities. For example, is “Psychic” a Role, a Trademark, a Special Effect, or a Plot Device in your game?
To Provide Detail
Different genres and story styles focus on different character activities. In a typical cop show, some guy in a lab coat tells the protagonist “we found the suspect’s prints on the murder weapon.” In CSI or Bones, the protagonists are the guys in the lab coats, so at least some of the work involved in finding the print and linking it to the suspect happens on screen. Since some of these sorts of character activities require knowledge that players don’t (and shouldn’t be expected to) have, rules can fill in the details with information, structure, complications, and decision points to help players create the scene. The process outlined by the rules may only be tangentially related to how the activity works in the real world, but it gives the players a starting point for the scene and hopefully promotes dramatic, interesting, or entertaining developments.
To Simplify Through Abstraction
Sometimes rules work in the opposite direction, providing abstract methods for handling things that would normally require tedious detail. In most games, the amount of food the characters have at home isn’t important because they can just go to the store and buy more whenever they run out. In a game set shortly after the apocalypse, on the other hand, the amount of food the players have available may be extremely important to the story. Rather than make the players keep an inventory of how many cans of beans or ears of corn they’ve got in stock, you can just define a standard unit of food (maybe 1 unit is enough to feed 1 person for a day), decide how many units of food the characters start with, and make a rule for how their scavenging, hunting, and other food-gathering rolls translate into food units.
Just like some games may require more detailed handling of equipment (as discussed in Chapter XX: Auxiliary Rules), sometimes other story elements need more detail than the basic rules provide. Customization is often required for unusual character traits like supernatural abilities or robotic bodies where each character with the trait has slightly different characteristics or abilities. For instance, in some stories wizards just use magic in the same way a scientist uses his knowledge or a warrior uses his fighting skills. In a lot of fantasy fictons, though, wizards must learn specific spells and every wizard has a slightly different arsenal of magic at his disposal so you need a way of deciding which spells a wizard has when the game begins and what he has to do to learn new ones.
Fund me on Patreon and I'll be able to afford chapter numbers.
Last time around, I talked about a problem I was running into with a disconnect between intent and interpretation when it comes to rules. Basically, since we usually think of games as "systems" where all different rules concepts are interconnected, some players assume that anything not clearly marked "optional" is essential. The truth is that most systems aren't as interdependent and finely-tuned as game designers like to pretend (or at least they don't have to be; a lot of the interdependence that does exist is wrapped up in the myth of game balance). A good system uses a set of core mechanical concepts to handle different aspects of the game, but each of those individual subsystems is mostly independent. Changing the target number for pickpocket rolls or giving fighters a higher damage bonus for specialization isn't going to change how the game plays. Ultimately, I realized that my challenge was one of presentation: I needed to organize a rules in a way that clarified where different rules concepts fell on the spectrum between "core rules" and "random ideas I thought were neat."
Looking over the rules, I came up with a few general categories of rules that needed to be dealt with:
Core Rules: These are the central mechanics that you need for just about any game you decide to run: the basic rolling mechanic, character trait definitions, basic combat rules, using Acclaim, etc.
Options: These aren't so much specific rules as things that you define (or ignore) to fit the specific game you're playing: game-specific concept traits, allowable Tropes, starting Hero Factor, some details about how leveling up works, that kind of thing.
Non-Core Rules Concepts: These are basically the crunchy rules concepts like extended rolls or teamwork rules. They can provide more detail when you need it, but you should only use them when that level of detail is actually necessary. These (along with the core rules) are the "toolbox" concepts I've mentioned in a few posts and often they're used to create the rules or subsystems you need for a particular game.
Specific Sub-Systems: These are kind of the things you build with the stuff in the toolbox: a description of which rules concepts to use for a specific kind of character action along with target numbers, what different results mean, and any additional rules that are added on. I've written up sub-systems for things like investigation, persuasion, and research, but for most of them you can easily use the core rules unless that particular activity is central to the game premise or story. The only specific sub-system that almost every game needs is a combat system. The necessity of others depends on what kind of game you're running.
Pet Rules: These aren't so much rules concepts or sub-systems as a case where I've noticed a way a rules idea could be used and crammed it into the game. There were a lot of these in some of the early versions of the combat chapter.
It took some trial and error and a lot of cutting and pasting, but eventually I think I worked out the organization. It follows a set of guidelines that I probably could have saved a lot of time by working out ahead of time instead of as I went along. Here they are:
- The core rules chapters are for core rules. Anything else should only be referenced briefly or used as an example for how to use particular rules. Those examples should be clearly marked as such.
- Some options (like the idea of game-specific traits) need to be introduced in a general way in the core rules chapters, but detailed discussion should be saved for the section on adapting the rules to your game.
- The non-core concepts go into a new chapter, which I decided to call "Auxiliary Rules." I didn't want to use "Advanced" because that almost sounds like a challenge to game nerds to use them whether they're needed or not. I also didn't like "Optional" because these aren't really something like psionics or exceptional strength that you take or leave at a game level. You use them when you need them and ignore them when you don't.
- I looked through the sub-systems and pet rules to see if there were any auxiliary rules concepts hiding in them. In a couple of cases, reframing the basic mechanics behind subsystems or pet rules as generic rules all but eliminated the need for the subsystem or pet rule. Those that are left will be used as examples, either in rules chapters (especially the adaptation section) or in specific game set-ups.
Going through this also made me realize that the chapter I had about adapting the rules to your game isn't nearly enough. The idea of using the rules to create the exact game you want to play has become more and more central to the system's purpose, so I need to really tell players how to do that rather than giving a general chapter and trying to show the possibilities mostly by example. So now organized into 3 sections (4 if you count appendices): the basic rules section, the section on adapting the rules to your game, and the GM's section. Part 1 is basically revised, part 3 doesn't need a whole lot of changes, but Part 2 is going to require a lot of new material. I should probably get to work.
Sponsor me on Patreon or I'll club a baby seal.
The first step in solving a problem is identifying the problem. For some problems, like being on fire, that's not very hard to do. For other problems, like being addicted to meth, (or having an irrational dedication to a particular die type) the big step is recognizing and admitting to the problem. For more complex problems, it's not always quite so straightforward. Sometimes, for example, you think you've identified the problem but it turns out just to be a symptom or side-effect of a different or more fundamental problem. In the work I've done on Cinemechanix this week, I think I've hit on one of the latter.
One distinction I've tried to make between an "adaptable" game system (which is what I'm shooting for) and a generic game system is that a generic game system tries to find a one-size-fits-all solution and an adaptable game tries to provide the tools to let you find the solution that actually fits in your game. The problem I've run into a couple of times, and have been trying to solve with the current draft of the rules, is that stating that distinction doesn't quite get the point across. I've run into several instances where players have been annoyed by rules that I thought were pretty obviously take-it-or-leave-it ideas that could easily be ignored. Despite the repeated reminders that everything is optional, the fact that these easily-skipped rules weren't explicitly marked as optional made the playtesters feel like they had to use them.
Trying to find a way to short-circuit the impulse of assuming that anything not clearly marked as non-essential is essential got me thinking about the difference between a game system and game concepts or mechanics. The word "system," implies a certain level of interconnectedness, so it makes sense for people to assume that everything is necessary unless specifically identified as non-vital. The truth is that for most game systems only some of the rules and concepts are interdependent and necessary. There are a lot of sub-systems and add-ons that you only need occasionally and may not need at all for some games. This got me re-working the text to make it more obvious which rules concepts were central to the system and which ones were part of the "toolbox" that could be used to build the sub-systems you need for the particular game you're playing.
From there, I realized that I needed to move from the specific to the general on a lot of things. I'd provided some sub-systems in the early drafts of the rules for things like investigation and persuasion and specific combat mechanics I thought would be cool. Several of these were among the things playtesters didn't like or thought were unnecessary. Like the sub-systems in most games, these relied on some basic mechanical concepts, but they were concepts that built upon the ideas in the core rules rather than directly using the core rules. In some cases, these concepts were already introduced in as generic concepts in other parts of the rules. The trick was to stop doing a little of both and get rid of the sub-systems in favor of the mechanical concepts, then to organize it in a way that separated the mechanics you use for building the rules for your specific game (the "toolbox") from the rules that you're probably going to need for every game (the system).
That's when I realized the difference between a generic system and what I'm calling an "adaptable" system: generic systems don't give you the toolbox. If the system is well-designed enough that the sub-systems are coherent with the core rules, you can usually figure out the underlying concepts on you own, but the game designer isn't going to tell you. Most generic systems are, it turns out, adaptable systems, but the tools for creating that adaptability are proprietary. You might be able to run a wizard in GURPS* with just the basic rules, but it's going to take a lot of work on your part and Steve Jackson isn't going to give you any pointers. You're going to have to buy a copy of GURPS Magic, and even that's just going to let you run a generic wizard that's sort of a gestalt of wizard archetypes and fantasy fiction. If you want to play anything that doesn't fit the standard paradigm, like wizard in the Harry Potter Universe, you're going to have to wait for GURPS Harry Potter to happen. Chances are both of those books will rely on a number of ideas that show up in a lot of GURPS books but aren't spelled out as generic mechanical ideas anywhere in the main rulebook.
Why keep these rules concepts a secret? Part of it's convention, some of it's probably ego, but the big reason is obvious from the example: the game designer wants to sell you more books. Despite the conventional wisdom that people don't buy games because of the system, most game companies seem to think that filling in system holes is what sells game supplements. In my opinion, the conventional wisdom is right for a change in this case. Most people aren't going to buy GURPS Harry Potter to find out the stat adjustments for half-giants or whether Parseltongue is an advantage or a skill, they're going to buy it because they know the designer has mined the source material for gamable ideas and has probably come up with some ideas they wouldn't have thought of themselves. Giving the players guidelines for building the game-specific stuff isn't going to stop them from buying the supplements the company releases. They're still going to buy supplements for the research, new ideas, and convenience of having someone else do the boring, tedious work for them and put it all in one convenient package. Telling them how to do the boring part themselves just makes it easier for them to come up with their own Harry Potter rules without having to wait for Rowling to give up a license. It also helps them come up with rules for their own original game that the company will never write a supplement for.
So once again, the root of my problem is "it's the way things are done." And because that's the way things are done, readers are going to assume that's the way I'm doing it. Fixing the problem requires making it clearer where I'm departing from the standard operating procedure.
*I'll use GURPS here because from the few interactions I've had with him, Steve Jackson doesn't seem like he's got an easily-bruised ego. Besides, he's too busy counting Munchkin money to read this anyway.
I don't have Munchkin money, so I have to panhandle on Patreon.
Alert readers will notice I didn't post a blog last week. That's because I was re-writing the rules again. The good news is that the characters I posted two weeks ago still more or less work in the new new system. I'm keeping the format, for reasons I discussed in the post before that one, but I'm reworking the core mechanic again, which means that the Trope Numbers (and probably a few character's Special Effects) change. Those stats will actually look a lot more like the original character sheets, with the numbers dropping by half for most characters because I'm getting rid of roll modifiers and replacing them with something more akin to Bonus Dice in the original system.
The basic change to the core mechanic is that we're opening up the system to more dice than just the d20. Now, instead of rolling some number of d20s based on character traits and adding to them, players just roll two dice: A Default Die (which is a d20 if the Character Concept is applicable, a d12 otherwise) and a Hero Die (which is the highest die less than or equal to Hero Factor, so a Hero Factor 3 character rolls d2, Hero Factor 6 rolls d6, etc.). Instead of roll modifiers, you now have Boosts and Drops for things like Tropes. A Boost raises your Hero Die to the next dice up (d12s roll over to d12 + d2, so sometimes your Hero Die is really Hero Dice). A Drop lowers it (and if your Hero Die drops to zero, they lower the Default Die as well). So if youv'e got an appropriate concept, a Hero Factor of 4, 2 Boosts, and a Drop, you'd roll a d20 Default Die and a d6 Hero Die then add them together to get your total roll.
Turning what used to be roll modifiers into Boosts and Drops makes the math work out a lot better. Since character abilities increase (or decrease) the size (and sometimes number) of dice you're rolling, more competent characters are still going to generally get better numbers, but the range of likely results isn't as limited as when everyone's rolling multiple d20s. Also, since more powerful characters aren't just adding a huge bonus to their roll, there aren't cases where a less powerful character is mathematically barred from winning a roll. The guy rolling d20 + 2d12 might still roll three 1s and lose to the d12 Mook's 5. This also makes the arbitrary limit of 10 for Hero Factor less vital to avoid breaking the system. And best of, no roll modifiers.
Why is getting rid of roll modifiers a good thing? Because adding them back to the system (at least as part of the core mechanic--there will still probably be cases where they're the simplest solution) felt like moving backwards. One of the things I liked about the original dice pool system was that if something helped or hurt a character's chances, you could just add a bonus or penalty die, so there was no need to worry about how much the thing helped or hurt--the randomness of the die determined that. You could theoretically apply that to modifiers, too, but something about giving an ability a concrete numerical bonus or penalty opens up a whole new can of worms and you inevitably start wanting to compare that bonus or penalty to other bonuses or penalties and fiddle with them so they're all accurate. So we're back to a different kind of fiddliness. When the bonus or penalty is variable (even if the range of variation is only 1 or 2, which is what a standard Boost or Drop is worth), the urge to compare it to other modifiers isn't nearly as strong for some reason.
I probably should have gotten around to this fix sooner, but it was a long time coming because of a block I'd built for myself without even realizing it: The desire to use only a d20. Since QAGS was originally just a simple system I'd come up with for pick-up games, using just one die was to keep the equipment you needed to play to a minimum. Find a d20 and some kind of counters and you're ready to go. During the Open Game License glut, using only a d20 let us make snide comments about how we were the "real" d20 system since we didn't give those other dice the time of day. Somewhere in there, the crude little drawing of a smiling 20-sided die from the first edition of QAGS got redesigned and colored and became our mascot, Happy d20.
Since Cinemechanix started life as QAGS Third Edition, I never even considered using anything but a d20. Josh brought up the possibility when we were working through the second major tweak of the core mechanic, but I dismissed him, in part because of his specific suggestion of replacing the d20 with the d12 as the sole dice would make Happy d20 obsolete. What kind of monster was I dealing with, who could so casually suggest just tossing a loyal, long-term employee like Happy d20 out on the street in this economy? As you can probably guess by my concern for a drawing of a die, I was not in the right frame of mind to make the obvious leap of considering a way to keep both dice around somehow.
Breaking down the block started on the Cinemechanix Playtest group with the idea of using other dice (which seemed easier to stomach than just firing Happy d20 and hiring some d12 scab) in addition to the d20. I suggested a possible way to do that, but was basically just making conversation. It was more "here's a mechanic that would do that" than "this is a mechanic I would consider using." I still felt like we needed to be a d20-only system. I think the block was in part because the d20 was one of the QAGS hallmarks that's still in the game. The early versions of the system still "felt like QAGS" despite the differences, and I think I was afraid that adding new, strange dice would cause that to go away. But really, if you're defining QAGS by its mechanics and dice rolls, that ship sailed a long time ago, maybe even before the system stopped being QAGS 3E. Also, Cinemechanix is not QAGS. I want it to keep a lot of the things that I love about QAGS, but Cinemechanix is really meant for a kind of game that QAGS can't pull off very well. The more I thought about the mechanic, the more potential I saw in it. By the time I started running the math I'd managed to reconcile any old bad feelings about the dice of my childhood (even that foot-poking little bastard d4). When I saw that the math actually worked better, I was sold.
All these changes to the central mechanic of the game may seem excessive, but the Cinemchanix system is more about how to use the rules to build a game than what specific rules you're using, so the character trait redesign I did as part of the last iteration was actually more work than the rules changes for either version. The core mechanic is kind of like the engine in your car. It's vital to make the whole thing work, so you want the best you can get. But unless you're a gearhead it's probably not the main thing that made you buy the car in the first place. If all the other parts of the car work and are still in good shape and the engine blows up, most people are just going to replace the engine. The new engine has to be the right size and have all the right options to work in your car, but once it's replaced the fact that the car has a different engine probably isn't going to change your overall opinion of the vehicle. It's not the plank that turns Theseus' ship into a different boat for most people. With me, the core mechanic of a game is the same kind of deal, so I'm going to keep replacing engines until I find the one that works best.
Replacing game engines is thirsty work. Hook me up with some beer money on Patreon.