About a month ago, Justin over at ‘The Alexandrian’ posted a breakdown of his concept of dissociation. While I largely agree with what he says, I have a few points of contention. Conveniently enough, today’s our usual Commentary day!
We’ve been putting our links at the bottom of our posts lately. I linked that one on top for a reason, though. This post will probably make a lot more sense if you read his article first.
For those of you who choose not to, however, here’s a brief overview. An “associated” mechanic is one that is linked to the game world. Conversely, a “dissociated” mechanic is one that breaks from in-world considerations.
For example, an “ammo counting” mechanic would be associated. Your decision of whether to loose that next arrow is much the same as the character’s would be in the situation you’re portraying. However, a once per day Super Mondo Mega attack would be dissociated. The character doesn’t go into the situation knowing that he can only use his awesome Crane Kick once in the tournament, but the player does. That discrepancy will change how the two behave.
Justin’s point is that divorcing the player’s thought process from the game’s reality is detrimental to the role play. You’re being forced from your character’s head-space. He goes so far as to say that, while using a dissociated mechanic, you’re not role playing.
Before I continue, I want to reiterate that I agree with most of what Justin has to say. All things being equal, it’s better that a mechanic model the game’s reality while aligning the motivations of player and character. I’ve mentioned similar sentiments here before, in fact.
However, I think that there are a lot more important influences on the role playing. It’s definitely going a bit far to say that you’re not role playing for the moment you’re using a dissociated mechanic.
The article’s running example of a dissociated mechanic is the One-Handed Catch ability of an American football RPG. This would give the character a +4 to making a catch once per day. This is dissociated, because its once-a-day use isn’t actually modeling the use of anything in the game world. It’s just there for game balance.
However, as Justin points out, all RPG mechanics are just abstractions. It’s not that the character isn’t trying to make one-handed catches all the rest of the day, but rather that he has a better chance of succeeding on that particular one. Presumably, the player will use this ability when the game is on the line. Thus, this mechanic makes for a character who is more likely to pull through on clutch plays.
You could model it in a more associated way. Maybe the character gets the bonus when the game depends on the play, or when the chances of succeeding are really low. However, these are both more complicated, open to abuse, and remove the player’s capacity to use the ability when they think it’s most dramatically appropriate.
As it happens, one of my favorite RPG mechanics is dissociated. Fate’s Aspects work by giving bonuses to the things the character is good at, penalties (essentially) for their weaknesses, and allow the GM to compel them to act out their bad habits in ways that might be detrimental. A player in a Fate-based game spends (appropriately enough) Fate points to use their good qualities, and receives points when their bad qualities are used against them.
When I’m spending a Fate point to Invoke (make beneficial use of) an aspect, nothing is actually getting used up in-game. When Derek, my young Dresden Files RPG magic user, benefited from his Grandfather’s Stories (one of his aspects), he didn’t then think “I’ll have to act more like a Punk Kid now.” I might have been motivated to look for ways to get more Fate points, but my character wasn’t.
Still, the ultimate effect is that both a character’s good and bad features are role played. The Fate point economy is about as dissociated as you can get. However, it’s one of the best mechanics I’ve found for getting players to voluntarily play all sides of their characters, even when it’s against their interests.
Guilty by Disassociation?
As I said above, I think a mechanic is better off associated than not, all things being equal. However, I’d place several other qualities above that in importance, such as ease of use, and plain old pragmatic effectiveness. I can’t think of a way to implement aspects in a more associated way, but I also can’t think of a mechanic that better incentivizes role play. Any ideas?
P.S. Yeah, that section header had nothing to do with anything, I just couldn’t help myself.