Thursday, July 28, 2011

You say you want a resolution.... part 2

Continued from part 1...

Yesterday we discussed intent.  Today, we'll discuss declaration.  For those joining us halfway through the woods, this is a series of posts of task resolution, breaking it down into five separate stages: intent, declaration, resolution, effect, and description.



Tell Me What You Want, What You Really, Really Want

Once you have figured out your intent, you need to declare it to your GM (or the players, if you are the GM).  It needs to be clear and precise.  It also should be evocative and energetic.  Very few gamers will disagree on that first statement, but the second one frequently divides the room into different styles.

I have very frequently run into DMs (I switched from "GM" here because these were almost exclusively in D&D games) who strongly discouraged descriptive declarations, especially of attacks.  Instead of saying "I attack him with my sword," I would say something like "I drive my saber into the bastard's guts!"  Oops, no, I can't say that.  First, it presumes that I succeed, so I can't say things like that before the roll.  Second, if I say something like "guts" that means that I'm declaring a called shot.  That involves penalties and complicated mechanics.

Honestly, most of my continual insistence on the importance of descriptions in addition to the mechanics comes from a deep-seated frustration over much of my gaming career.

Now, I will admit that evocative language can erode both the clarity and precision of the declaration.  After all, if there are special rules for attacking his guts, and I say I'm attacking his guts, the DM has every right to be confused as to whether I am invoking them.  But, honestly, that kind of confusion tells me two things:  The system has put its complexity in all the wrong places, and the DM is not interested in descriptive language (i.e., is boring).

The emphasis on descriptive language is clearly a matter of taste.  I happen to lean very strongly on the side of more description makes for a better game.  I lean on it so strongly that I occasionally break it.  I really don't understand how other people can enjoy a game without it.  So, I evangelize it.  Given my goal with this post, I am going to try to avoid it here.  If you see an unfair bias, please call me on it.

Dream the Impossible Dream

As for my assertion that unclear declarations are a symptom of system issues, let me elaborate.  There is a dangerous train of thought in system design.  It starts with, "Action heroes do awesome things!"  But, of course, the awesome things that action heroes do are terribly unrealistic.  The only way they could do them is if they were ludicrously good.  If we want to restrict those awesome actions to the ludicrously good, they should be ludicrously hard to pull off.  Therefore, awesome stunts should come at severe penalties.  Anyone who tries to be awesome without taking the penalties is just trying to get away with something.

If you are designing a gritty, realistic game, then having awesome stunts be very hard makes sense.  However, in that case the above train of thought never should have left the station.  Action heroes are neither gritty, nor realistic, and should be actively discouraged as role models for characters in the system.  Your heroes are either desperately out of their depth and making do as best they can, or quietly competent.  Or, sometimes, both.

If you are designing a cinematic game, then why the heck are you introducing realism?  Your players want to be awesome.  You want your players to be awesome.  Why are you making it hard to be awesome?  The difficulty of the task should be based on how much of an advantage it gives the character, not how likely it is for the character to pull it off.  Suppose you have a firefight in a hospital.  The bad guy has been pummeling the hero.  The hero notices that the bad guy is now standing in front of a rack of oxygen tanks.  What is the awesome solution?  The hero fires his gun at an oxygen tank, neatly clips off the valve, and the spark ignites the suddenly depressurized oxygen.  Boom, fireball.  If you, as a GM, hear this declaration, please don't make this difficult because even the best sharpshooter in the world would have trouble making that shot, or because a single bullet is unlikely to actually penetrate an oxygen tank, or because Mythbusters proved that a bullet hitting metal is unlikely to spark any kind of explosion.  If you have to make it difficult, make it difficult because suddenly creating a 10d6 fireball and immolating the bad guy is one hell of a use of "improvised weapon".  (Conversely, players, if your GM is letting you get away with shooting open the oxygen canisters, don't start fussing about the "realism" of the damage the explosion would do.  The argument cuts both ways.)

Most systems look to create interesting tactical options in conflicts by trading greater risk for greater reward.  That is good game design.  Where it fails is when it doesn't separate the fluff from the crunch (look for a post on that later this week).  The greater reward is defined as "making the impossible shot", and not simply as "deals triple damage."  The result becomes that anyone attempting to "make the impossible shot" must take the penalties, even if they don't actually care about the triple damage.

9 comments:

  1. As a tangent (or maybe not), I prefer a Homeric treatment of the PCs. They're the heroes of the story and though they should not be the ultimate bad-asses in the setting, they should never be overshadowed by an allied NPC (though villains may, it makes for motivation). That probably means i fall towards the cinematic end of the equation. I do try to weigh that somewhat, even the baddest hero can fall through overwhelming odds, bad planning (which can cause overwhelming odds), and sheer dumb luck.

    ReplyDelete
  2. I will agree with you in general. Though, specifically, I think saying that PCs should never be overshadowed by allies is a bit too absolute. There are ways to do it well. There are many, many more ways to do it poorly. That should probably be a post on its own.

    ReplyDelete
  3. I can't say I've seen it done well. I think you're right, this is a topic that merits its own post.

    ReplyDelete
  4. Re overshadowing PCs: I've done it a few times, and seen others do it on a few occasions--though that depends in part on how one defines "overshadow". Semantics, I know.

    I wrote about the techniques here, and more in the trackbacks on that post.

    But enough with the self-promotion.

    I think one other thing to look at is how much you want to encourage people to think of the awesome solution--a third variable to take into account along with how hard would it be and how big an advantage would it provide. Namely "Is this too cool not to work?"

    There's also just using a particularly impressive success as a source of following complications; brokenness comes with a price, after all. Take the oxygen tank 10d6 fireball. Yeah, it's a pretty nifty improvised weapon--but you can get a lot of challenge out of the collateral damage it's guaranteed to bring about, and the PC who set it off is probably going to need to defend against it himself. Tit for tat, right?

    ReplyDelete
  5. Huh, Ravyn, I can't seem to get to your site. I keep getting a 404.

    I definitely love the "Is this too cool not to work?" variable. The problem that I've found with it is that the players and GM may have different ideas of cool. It's a variable that very stubbornly resists being measured and categorized. I want to reward cool, but I don't always recognize it, especially in the midst of the action.

    ReplyDelete
  6. Sorry about the 404 there. I'm having words with the webmaster now. Try checking back in three or four days.

    I agree, it can be a bit tough. I sometimes open it to my fellow players, when I'm not trusting my own judgment--though I tend to err on the side of oh my this is awesome more often than not, I think. I suppose it's an advantage of working in text.

    ReplyDelete
  7. Definitely an advantage of working in text. If nothing else, it allows you to take a minute to just let yourself react to the declaration before having to respond. You don't have as much pressure to keep the tempo up.

    ReplyDelete
  8. I'm getting a 404 as well. And here I was looking forward to reading it too.

    ReplyDelete
  9. Ok, it worked and I got something out of it. Thanks!

    ReplyDelete