Thursday, July 31, 2008

Quick Fix: Superpowers in Fate

When our ongoing campaign had to go on hiatus, my group and I discussed what we would like to play next. We decided to try Mutants and Masterminds. After a couple frustrating sessions of players not understanding how their powers worked and me faking rules decisions and generally BSing, we decided to convert our new superheros back to Fate. The following is a distillation of the rules I created for those characters.

First we created Aspects as usual. We gave everyone 5 aspects. I'd suggest focusing on dependent NPCs and secret identity issues for true superhero flavor.

Next, we generated Skills. Our group used a slightly modified SotC skills list, and each character had a Great skill pyramid. In addition, characters identified two of their skills as "meta-skills." A meta-skill could either be a skill they made up to define one of their super powers, (Superman could have a "Flight" skill), or a normal Skill that the character had superhuman ability with (Superman could have Meta-Might). Meta-normal skills received an automatic +2 on all checks. Other Meta-skills didn't get a bonus; their coolness made up for the difference.

We picked stunts out of the SotC book, or created our own from scratch. Many characters supported their powers using stunts. The Herculean Strength stunt is perfect for your super-brawny characters and a number of Athletics stunts are nice for speedsters.

I also house-ruled that characters didn't start with any stress boxes. High Endurance and Resolve ratings gave characters boxes, and they could also use these skills to actively defend. I hoped that reducing the number of boxes would let us get to Consequences faster. The decision to make Endurance an active defense was meant to emulate super-tough characters bouncing bullets of their chests.

This turned out to be surprisingly effective. The trickiest part was creating Meta-skills that effectively modeled the powers our characters already had. We determined there were a few different types of meta-skills.
  • Meta-Normal Skills: These were the easiest. Our Iron-Man knock off had Meta-Might, and our Luck Manipulator had Meta-Athletics.
  • Maneuver-Based Skills: Some characters had skills built around declaring aspects. Our weather controller used his "Weather Manipulation" skill to declare weather aspects on the scene; Our Luck Manipulator used his "Luck" skill to declare lucky coincidences.
  • Super-Skills: These were the skills characters needed to make up to model their other powers. As a rule of thumb, I assumed that the Super-Skill should allow the character to do something they would normally be able to do with a device. Our Power Armor character took a "Blast" skill, which we treated as a Guns skill without requiring a gun. At the extreme, our Weather Controller took a Flight skill, which we treated as Pilot without requiring a Plane.

If people are interested, I can post the characters we made. I'm also happy to answer any questions if the mechanics are unclear.

Sunday, July 27, 2008

Quick Fix: Adding Aspects to D&D

My group is still working on getting together to try out D&D 4E. (Attacking two quick build characters with five Kobalds on a chess board doesn't count, does it?) And since we haven't played yet, I'm withholding judgment on the system, but I must admit that I'm very excited about the new game. There is one house rule that I'm considering implementing. Anyone who's played Spirit of the Century or any other FATE game will tell you about the awesomeness of SotC's supermechanic: Aspects.

Aspects are, according to the SotC SRD, "Aspects can be relationships, beliefs, catchphrases, descriptors, items or pretty much anything else that paints a picture of the character," but Aspects can be much more. In my play, it's become clear that Aspects are the lazy man's mechanical shorthand for anything you need to model in the game. Your players will get a chance to tie they're "Burning Hate for the Empire" to the system, and you can show that "The Building's on Fire" without looking up fire damage in the DMG.

So, how can we go about tacking Aspects onto a system like D&D? In Fate 3.0, a character can "invoke" one of their Aspects by spending a fate point, or they can spend one to "tag" someone (or something) else's aspect.

A Fate invocation is worth a reroll or a +2, a tag is only worth a +2. In D20 terms, let players invoke their Aspects to reroll any D20 rolls. If you're generous, guarantee that rerolls are 11 or higher (add 10 to lower numbers.) My gut says that a +2 for tags would correspond to a D20 +5, but that's untested.

The other thing you'll need to figure out is how your characters will generate Aspects for their characters. While you could implement phase-based creation as seen in SotC, it might be easier to create a list of five or so questions and have your players generate an aspect for each.
  • What was your background like?
  • What motivates you?
  • Who is your greatest enemy?
  • Who is your best friend?
  • What's a quote your character likes to say?
This is a very bare bones implementation that doesn't use core Fate concepts like declarations and assessment, but if Aspects work for your group, check out the SotC book for more groovy Aspecty goodness.

P.S. Aspects might be a useful stand in for players missing the Profession skill from third edition. A character with the "Sailor" Aspect can get the mechanical juice they're looking for when they try to tie knots, balance on a rolling deck, or socialize with some other scurvy dogs.

Friday, July 25, 2008

Tropes: Why Should Players Get All the Fun?

In a recent Amagi gambit, Levi Kornelsen provides a plug-in to mechanically encourage players to "play to the tropes" of the genre you're trying to emulate. Essentially, GM (or the group) creates a list of tropes that will reinforce the chosen genres. Levi recommends starting with about 10 tropes and adding as you go. When a player manages to maneuver to fulfill a trope (the character charms the reporter and "The Hero Gets the Girl" in the process) he gets a trope point. Trope points are the sort of manipulative currency we've become used to in games. Think drama points, fate points, plot points or action points. Stripped to its core, the system lets the GM bribe the players into playing to the genre, and there's nothing wrong with that.

This is a really cool concept that I know could improve my group's genre games, but why should players get all the fun? The Amagi article includes this paragraph about "Non-Player Tropes":
Not every good trope is meant for player action, or covered under these rules. If your game emulates video game RPGs, it’s a trope to include a Fire Dungeon and an Ice Dungeon, but those aren’t things players manage. Making a list of these to have on-hand is helpful; even if they aren’t part of these rules, they’re fun to have at hand.

But why shouldn't the rules support non-player tropes? Can't the players bribe the GM too?
Replace the "Non-Player Tropes" paragraph with this:

Not every good trope is meant for player action, or within the players' hands. If your game emulates video game RPGs, it’s a trope to include a Fire Dungeon and an Ice Dungeon, and if your game adheres to the conventions of the Noir genre, players should expect a sap to the back of the head, eventually. When creating the list of tropes for the group, help the players make their own list of Non-Player Tropes. These are things that the GM can do to support the genre.

Just like player tropes, there are two big rules for the non-player variety. One, the trope should support the genre. Two, the trope should be something you think will be fun, not something that will upset you if the GM chooses to employ it. If you think that a club to the back of the head will be fun, put it on the list. If you think it sounds like the worst kind of railroading, make sure it doesn't end up in the GM's repertoire.

If necessary, have players initial the tropes that they're willing to be involved with. Some tropes, like a crumbling rope bridge, will affect the whole group, but others, like getting possessed by a demon, can be isolated to only interested players.

Any player may Award the GM for acting out a trope. GMs can spend their trope points to Boost NPCs and, if the group likes, he may be limited to only placing bounties using these points. GMs may also use these points to bride players to play along with more undesirable non-player tropes. "I'll give one of my trope points to whoever's willing to be kidnapped"

Thursday, July 24, 2008

A Thought Experiment: Mathless Dice Pools

I like dice pool mechanics. They're fun, and they're a nice change of pace from the die roll+stat+skill we see in most games. The system I'm most familiar with is White Wolf's Storyteller engine, particular the way it's implemented in New World of Darkness. For the unlikely gamer that isn't familiar with this kind of system, it works like this:
  • A character's "dice pool" is a number of dice equal to their rating in the skill. So if you're playing NWoD, and you have 3 dots in Firearms and 2 dots in Dexterity, your rating is five
  • When you attempt an action, you roll a number of dice equal to your rating. In NWoD, you roll d10's, so in the previous example, you would roll 5 d10's
  • After you roll the dice, you count how many of the dice are "Successes." Coming back to our example, any dice that show an 8 or higher is a Success. The more Successes, the more Successful the roll. Get it? ;)
There's a lot to like about dice pool mechanics. For one thing, they're fun from a tactile perspective. In other words, rolling fistfuls of dice is fun; I'm not going to deny it. Dice pools are also cool for determining success and failure. After all, if you achieve a Success, you've succeeded (usually).

However, there are problems. One thing that I don't like much is the trouble a GM can have with determining the difficulty of a check. Basically, some tasks might require more than one Success. Seems like it might be easier to say a Success means you succeed, but then you have trouble when players attempt something that should be harder. Climbing the wall in the rain should be more diifcult than climbing it on a nice day, right?

And, because I'm really lazy, I admit that I wish it were easier to do the counting. 8's, 9's, and 10's are all successes, which means a little more time separating the dice. I think I've been spoiled by the fudge dice used by our current system of choice, Evil Hat's FATE engine.

So, here are some ideas I've have for a new spin on dice pools.

To fix my tiny nitpick with the word Success, there is a simple solution. We'll appropriate the word "Shift" from FATE. In FATE 3.0, a Shift is what get when your roll is higher than difficulty. If it's two higher, you get two shifts. So in this theoretical engine, when you roll your dice, you get a certain number of "shifts."

My next idea to make a really tight system is eliminating the disconnect between the number on the die, and its result in the game. The coolest thing would dice that directly indicated a shift without considering numbers. For instance, dice could have some sides dyed green. Each green die is a Shift. Easy, right? Customized dice are, unfortunately, not exactly cheap, so we'll have to settle for something else. The other thing to fiddle with, is how often a success occurs. In NWoD, someone with a rating of one succeeds 3/10 of the time. I could almost replicate this be rolling fudge dice and considering +'s shifts and discounting -'s and blanks.

The other thing that appeals to me is using coins or tokens. They're easier to come by or make, and there's something endearing about the idea of having only two sides. The tokens would show the Shift side or the Not Shift side. Normal coins could easily stand in if we assume that Heads are Shifts (or vice versa; as long as everyone's counting the same thing, we should be okay.)

The last thing that would create the ideal Dice Pool system is an easy way to handle easy and difficult situations. The most intuitive thing to do would be to consider an anti-shift. For argumnet's sake, call it a Neg. A neg is equal to negative one shift. The harder a task is, the more negs it has. For a really easy way to run the game, the GM could have Neg and Shift tokens. When a player attempted an action, a GM could pick up a number of tokens appropriate to the situation and throw them in the pile with the results of the check. "The dice show 5 shifts, but there are 3 Neg tokens, so I achieved 2 shifts." If a roll were especially easy, the GM would show some Shift tokens that could be counted as usual.

So to summarize:
  • A player throws a number of coins equal to their rating.
  • They separate out the Shifts.
  • This total of Shifts may be increased or decreased by Shift or Neg tokens.
  • In the end, one Shift is a success; more than that indicate that the check went especially well, and would likely have other mechanical advantages.
What do people think about Dice Pool Mechanics? Any dislikes? Would those dislikes be adressed by a system like this?