Thursday, June 23, 2005


On This is My Blog Ben is going off on Conflict and Task Resolution, which are Forge terms the usefulness of which I am skeptical about. Ben's version of the definitions are "Conflict is what the players care about and Task is what the characters do". He claims they are completely orthogonal and disjointed. There are some major issues with the definitions stated thusly, and to my mind, the fault is in the definitions as they are stated rather than distinctions in actual play.

If "what the players care about" and "what the characters do" aren't intimately connected, what you have is a broken, or at least rather useless, mechanic. This is part of Ben's point, I believe, in that if you want to "save the princess" but all your character sheet and the game's mechanics tell you is if you can swim the moat, slay the dragon, and overcome the sorcerer, but not tell you if you save the princess / resolve the story / win the game, then your system isn't speaking to what you're interested in. One of the flaws in Ben's argument, however, is that his conflict (AKA what the players care about) is more often than not in terms of story, which may or may not be the case.

An illustrative example: recently I recovered my old Teenage Mutant Ninja Turtles games, and my wife and I play a game called "Beat 'em Up". In this game, we create characters (since that is half the enjoyment of the game) and then fight. There is no story. What we the players care about is, roughly, making a neat (or ridiculous) character and winning the fight. My guerrilla warrior chicken beats her pommeranian mechanic (see what I mean about ridiculous?). Prima facie, Ben would likely say that TMNT:OS (roughly analogous, mechanically, to Palladium FRPG, Robotech, and Rifts) has no Conflict Resolution, only Task Resolution. But when my wife and I only want to make characters and fight, that's all we care about, and so by the above definitions, the (terrible, terrible) combat rules are Conflict Resolution.

As I said in comments on This is my Blog, I don't think the conflict/task resolution distinction is a useless one, but I also don't think it's a universally useful one, either. Nor do I think that any specific resolution system is fundamentally one or the other; we can use the combat system in TMNT:OS for piddly in-character action, or we can make it the focus of the story.

Conflict is great and all, really, and I'm glad that gaming is turning its attention to conflict because it can be a very useful tool for specific kinds of play. Conflict isn't the end-all be-all of all gaming, however. While Ben is correct that conflict appears in nearly all forms of roleplaying, the same holds true for characters, settings, situations, and monty python jokes. One could define conflict very very broadly as "what the characters care about" but... we already have a term for that: creative agenda. Conflict is something smaller, more specific, and more precise.

When I get home I'll excerpt the portion of Full Light, Full Steam that talks about conflict and harnessing it for your game. In the mean time, I'll outline the basic ideas. Conflict consists of two parts: (a) something a character wants, and (b) something that is threatening that outcome from happening. Resolving the conflict(s) of a story is the focus, and in some cases the goal, of a story. To reduce the resolution of conflict into a die roll (however complex) unconnected to the details of the story saps the vital energy out of that story.

Ben gives an example of play where the task resolution is completely unrelated to the conflict resolution; a young knight tries to save the princess and fails repeatedly to do anything towards that goal, but in the end saves the princess, anyway. Were I playing in that game, I would feel dreadfully cheated. Nothing I or my character did affected the outcome at all! If I wanted to experience Sir Gawain and the Green Knight, I'd read it. That sort of set up is fine for a story where the reader's perspective is neither authorial nor bound by one character; the revelation of events is enjoyable because that's what I'm after. In a role playing game where I am an active participant in the story, I want to be, well, an active participant in the story. I don't want to play through the GM's short story aspirations.

Perhaps this is the distinction I've been groping for: "what is important to the players" is a concern of creative agenda; every specific instance of actual play will have a different emphasis, if only slightly. The mechanics written out in a game rulebook, on the other hand, are set. Every specific instance of actual play using that system will be using the same exact system. Unless the written rules are only good for one instance of play, the encoded resolution mechanic must be independent of creative agenda, must be tools useful for supporting more than one approach to the game. Any given resolution system is not "task resolution" or "conflict resolution". They are resolution systems that can be applied to tasks or to conflict, depending on how your playgroup uses them.

Now certainly some systems are better geared towards tasks than conflicts, and vice-versa. There is also the important distinction between system-as-printed and system-as-played. In most cases, the system-as-played includes a lot of other mechanisms like player negotiation, power struggles, GM credibility, and so on: social interactions, but mechanical nonetheless. How or whether the conflict gets resolved can be stated explicitly in the encoded rules, or it may arise out of the unwritten rules the game runs by. Rules-as-written may be tossed out if they don't do what the playgroup wants at the moment, or may be amended or shoehorned (get five successes and you catch him). But however it turns out in the end, the rules-as-written are simply tools that are used as the playgroup sees fit; they are no more task or conflict resolution than my old computer is an excellent paperweight.


Post a Comment

<< Home