On Task Resolution
aka Technical Concerns post #2
(P.S. to the last post: Thanks go to Emily Boss, who helped me hash this stuff out over the phone before I wrote it here.)
So, you've all read my previous post just now on Conflict Resolution, right? Good.
So, what does this mean for Conflict Resolution versus Task Resolution? Well, for one, we have to drop the "versus." All games, in play, use Conflict Resolution (either explicitly or implicitly or a mix of both). So Task Resolution can't be opposed to Conflict Resolution, nor can it be a thing that occurs in the absence of conflict resolution.
What is Task Resolution, though? Well, in any game, there are going to be actions taken by the players. Task resolution either determines what actions are taken, or whether those actions succeed and fail, depending on the IIEE structure of the game. (For those that aren't clear on IIEE... uhm... best of luck to you?)
We can now realize that Task and Conflict resolution are, in fact, orthogonal to each other, and we can look at four types of games in terms of text.
In the fourth category, we can also consider the relationship between the conflict resolution and the task resolution, a wide range from Dogs in the Vineyard's system -- where the steps of conflict resolution are, themselves, task resolutions -- to Burning Wheel -- which uses its task resolution system as a conflict resolution system almost directly -- to theoretical games where the conflict resolution system and the task resolution system are totally separate from each other. That range is a huge thing to mine, but there's something else we have to talk about first.
Namely, now that we know that task resolution isn't anything like conflict resolution, and doesn't have to have anything to do with conflict resolution, do we need task resolution at all? Is it just a vestigal shell of implicit conflict resolution that we can cast aside when we've developed explicit conflict resolution? Or are there some other uses to it?
I, for myself, think the task resolution can still be useful, although I'm happy to hear explanations to the contrary. In particular, I think it can be useful unrelated to conflict resolution entirely, as part of a large subset of mechanics that serve to provide inspiration and color for the rest of the game. (see Tony's post here for more about that.)
In short, conflict resolution is a way of determining what happens in your game. I think that task resolution, once you have your conflict resolution nailed, can be used as one of a set of tools that tell you how whatever happens happens.
So questions: Should we use task resolution and what should we use it for? How, if at all, should it be tied into conflict resolution? Can it be tied into other systems, like conflict generation or resource limitation?
(P.S. to the last post: Thanks go to Emily Boss, who helped me hash this stuff out over the phone before I wrote it here.)
So, you've all read my previous post just now on Conflict Resolution, right? Good.
So, what does this mean for Conflict Resolution versus Task Resolution? Well, for one, we have to drop the "versus." All games, in play, use Conflict Resolution (either explicitly or implicitly or a mix of both). So Task Resolution can't be opposed to Conflict Resolution, nor can it be a thing that occurs in the absence of conflict resolution.
What is Task Resolution, though? Well, in any game, there are going to be actions taken by the players. Task resolution either determines what actions are taken, or whether those actions succeed and fail, depending on the IIEE structure of the game. (For those that aren't clear on IIEE... uhm... best of luck to you?)
We can now realize that Task and Conflict resolution are, in fact, orthogonal to each other, and we can look at four types of games in terms of text.
- No task resolution and no explicit conflict resolution. Freeform games fall into this category, and also anything close to them.
- Task resolution with no explicit conflict resolution. GURPS is like this, so is WOD and a lot of the "standard" games outside of combat.
- No task resolution with explicit conflict resolution. Universalis, the Pool, Primetime Adventures, and other games are like this.
- Task resolution with explicit conflict resolution. D&D is like this, so is Dogs in the Vineyard.
In the fourth category, we can also consider the relationship between the conflict resolution and the task resolution, a wide range from Dogs in the Vineyard's system -- where the steps of conflict resolution are, themselves, task resolutions -- to Burning Wheel -- which uses its task resolution system as a conflict resolution system almost directly -- to theoretical games where the conflict resolution system and the task resolution system are totally separate from each other. That range is a huge thing to mine, but there's something else we have to talk about first.
Namely, now that we know that task resolution isn't anything like conflict resolution, and doesn't have to have anything to do with conflict resolution, do we need task resolution at all? Is it just a vestigal shell of implicit conflict resolution that we can cast aside when we've developed explicit conflict resolution? Or are there some other uses to it?
I, for myself, think the task resolution can still be useful, although I'm happy to hear explanations to the contrary. In particular, I think it can be useful unrelated to conflict resolution entirely, as part of a large subset of mechanics that serve to provide inspiration and color for the rest of the game. (see Tony's post here for more about that.)
In short, conflict resolution is a way of determining what happens in your game. I think that task resolution, once you have your conflict resolution nailed, can be used as one of a set of tools that tell you how whatever happens happens.
So questions: Should we use task resolution and what should we use it for? How, if at all, should it be tied into conflict resolution? Can it be tied into other systems, like conflict generation or resource limitation?
19 Comments:
I'm not really buying this as a complete thought. Its not that I disagree with the individual concepts you've expressed...just that I don't see them having converged into a coherent whole yet.
First, I don't really have a key disagreement with any of the concepts you expressed in the Conflict Res post...because that's all pretty much standard stuff. The only thing you did was switch terms around (for reasons I don't particularly understand).
Meaning, what you're calling "conflict resolution" is really simply "resolution". And so the primary thesis of the article amounts to "all games resolve stuff". Right...I'm with you...that's pretty basic. We already have a term for that...its called simply a "Resolution System". By defining Conflict so vaguely as to include everything and anything under the sun all you've accomplished is to take what we used to just call "Resolution System" and call it "Conflict Resolution". Ok...I just don't see the point.
The explicit, bounded, and unbounded concepts seem like reasonable ways to parse resolutions systems to me.
Second you really lose me with your Task Resolution article. In your first article you basically say that all games have conflicts that get resolved so all games have conflict resolution. Even if I agreed with this broad definition of conflict you can make the exact same arguement for tasks. "All games have tasks that get resolved so all games have task resolution".
But then you go on to identify games that have no Task Resolution. There isn't such a thing. Any task you can think of that can get done in a game gets done somehow, and however that is...is the Task Resolution system (using the same logic you applied to conflict resolution).
For the two articles to work together the way you're envisioning them, you really need to change your 1 and 3 categories to no EXPLICIT Task Resolution system.
But even if you did this I think you'll have created a perfectly reasonable, completely functional, entirely logical framework...
...but you'll have completely and utterly missed the key distinction that has been at the heart of the Conflict vs. Task resolution discussions since the beginning.
Maybe you're just taking issue with labeling that distinction Conflict vs. Task and are defining what you think the useage for Conflict and Task should be...but then you'll need to come up with some other expression to identify what's going on with that key distinction.
So I don't really see these articles as doing anything to What does this do to "the hoary, old "conflict resolution versus task resolution" business?" In fact, I'd say you just coopted the terms for a new framework and ducked addressing the whole "business" altogether.
Which is fine. Perhaps the terms "Conflict" and "Task" are better used the way you used them and maybe there are other terms that better address the C vs. T issue that has been discussed elsewhere. But I don't see where these articles really have anything to do with C vs. T at all.
The heart of the C vs. T issue is not whether or not conflicts get resolved. Its HOW they get resolved and how the overall conflict is being framed and envisioned by the players. And this doesn't map 1:1 with your Explicit distinction because it doesn't have to be explicitly outlined mechanically to be explicitly framed and envisioned by the players.
Hmm...
I think that you're missing something about the first post.
It is absolutely and totally not about just resolution as a thing. It is about conflict resolution, explicitly conflict resolution, and only conflict resolution.
Let's say that my guy wants to rescue the princess. The conflict is "does my guy rescue the princess?" The process by which we resolve this, whatever it is, is conflict resolution.
Calling it just resolution implies that other forms of resolution are equally valid at resolving the conflict "does my guy rescue the princess?" For example, a task resolution system could tell us whether or not he swum the moat, climbed the wall, etc. But it could not tell us whether or not he rescues the princess. To resolve that, we need conflict resolution in some form.
Now, let's look at this from all four perspectives, keeping in mind that these are much broader than the narrow examples allow for.
No task resolution mechanics apply, no conflict resolution mechanics apply. We talk about the situation, what my guy does, etc. Mostly, it is social negotiation between the players.
Task resolution mechanics apply, no conflict resolution mechanics apply. We talk about the situation, what my guy does, etc. Mostly, it is social negotiation between the players. Along the way, we will be resolving individual tasks (do I climb the wall? do I beat the dragon? do I swim the moat?) but whether or not these have any bearing on the outcome is solely based on the social negotiation between the players.
Conflict resolution mechanics apply, no task resolution mechanics apply. We use our mechanics to resolve the conflict -- we know for certain, mechanically, whether or not I'm going to rescue the princess. Then, we figure out how it happens through a group social narration thing, possibly with one person given narration rights.
Both conflict resolution and task resolution mechanics apply. As an example case, let's say that we have a system where task resolutions stack together into a conflict resolution. So I'm rolling for "do I find the castle? Do I swim the moat? Do I climb the wall? Do I beat the dragon" and all the time I'm accumulating points in my "rescure the princess" pool. If I get enough points, I rescue the princess! Otherwise, I don't!
The important thing to remember is that conflict is not "everything under the sun." It is "anything that the players of the game consider to be meaningful and is uncertain." That could not be very many things! A single session might only see 3-4 real conflicts. It is just defined with respect to the local concerns about importance.
If, after reading that, you still think I am missing the key distinction between conflict and task resolution, and that they really are somehow opposed to each other and not able to occupy the same game, I would like an explanation of what I am missing because, yeah, I'm missing it.
yrs--
--Ben
Ben,
This is what makes me agree with you right here: “I think that task resolution, once you have your conflict resolution nailed, can be used as one of a set of tools that tell you how whatever happens happens.”
The issue, and the fundamental nature of the divide between as I have seen it in game is that the micro (task) resolution doesn’t always tie directly into the macro (conflict) resolution in a coherent manner – mostly because there is no place that the system determines that micro resolution must stop because the conflict has been decided. It can, like something out of one of Adorno’s nightmares, just go on forever through infinite delayed gratification.
In D&D you have micro resolution leading coherently into macro resolution in a very specific number of places (mostly around combat), but not in others (like a chase scene). OTOH, something like HeroQuest allows for micro resolution that is hard-wired to the macro situation through extended contests.
In D&D combat you have a large number of tasks that have a clearly defined endpoint in a typical situation – you complete the task of beating “this guy” when he runs out of hit points, or fail in it when you do. You can also extend this to getting a victory condition in a dungeon situation where the DM is running by the pre-written standards and not changing them on the fly (which is a social contract part of system in most D&D games I play). You get it when you kill the appropriate number of things in the dungeon. If it says there are 8 hobgoblins and you have removed all of the HPs from all the hobgoblins then you have achieved victory in the dungeon conflict. It’s all preset, all very much determined by the rules of the game.
However, let’s say you get into a chase in D&D, a long overland chase scene. It involves jumping fences, dodging obstacles, and doing fancy horse riding tricks. When does the chase end? How many obstacles does the GM throw in your way? As it stands the system has no method for dealing with this, so the answer very often becomes “as many as he wants and when he wants.” In HeroQuest, otoh, it ends when one side gives or runs out of AP.
(I’ll note there are d20 chase systems that fix this problem, it isn’t hard – it just isn’t done in the basic rules.)
So it isn’t that GM fiat is a problem in “task resolution” it’s that GM fiat rules when there is no place where task resolution, by the rules, turns into conflict resolution. If you can succeed in everything, go through all the tasks, and only have your conflict end because the GM thinks it should, then you’re in the realm of the stuff people at the Forge bitch about. There needs to be a way to show when one ends and the other begins, be it the explicit (HeroQuest) or the implicit (D&D in a fight or pre-written dungeon but not elsewhere).
As for task resolution for details, I think it’s a good idea. HeroQuest made a move in that direction with extended contests, and The Shadows of Yesterday with Bringing Down the Pain. (Both explicit examples.) However I also think there is room for more implicit design, we just have to pay attention to how we go about it.
Ben,
You don't really address something that I think is pretty important. Whether something is Conflict resolution or Task resolution isn't really a matter of system here.
In D&D, there is a system to determine whether you kill your enemy or not (the combat system). This is a conflict system whenever what matters to the group is whether or not some guy dies, but it's Task resolution if what really matters is do you rescue the princess that some guy is holding hostage.
So, I think what we really have here is Resolution, and then a sliding scale that determines its bounds. If "what matters to the group" (the Conflict) falls within the bounds of a given resolution system, then that system acts as a conflict resolving system. If "what matters to the group" falls outside of that resolution system then that system can achieve no more than task resolution.
Thoughts?
Thomas
Ben:
I agree with Thomas on this. You lost me when you put D&D into category 4, but GURPS and WOD into category 2.
If what matters to me is does some guy die in combat, then both GURPS and WOD have conflict resolution systems for this.
Cheers,
Jason
"Oh, it's you...
deadpanbob"
Thomas,
That's what I was saying as well. D&D does it in some places, so does Storytelling and GURPS.
The big difference, in my mind, is that D&D is pretty straight up about what it's doing. When you read the D&D 3.0 PG and DMG with the "return to the dungeon" advice and the way they tell you to structure adventures it's pretty clear what expectations the game is built upon. That people play D&D differently than those expectations isn't really D&D's fault -- it's more like historical accident.
GURPS and Storyteller, OTOH, often don't even have that level of focus. They may have an implicit combat conflict resolution for "to the death" matches (though I sometimes doubt even that), but outside of that they really don't, and don't even point the way towards having one (which D&D actually does try to do inside its context).
And I think you can see the way these things effect play. There is a reason why the typical D&D solution to saving the princes is to kill every living thing in the castle first.
There are lots of ways to defeat someone in GURPS. People have Reputations (% chance of those who know your reputation helping/hurting). Hit Points (duh). Willpower (vs. addiction, seduction, persuasion, etc.). Playing off the hundreds of disads. There are many avenues of conflict available.
Nonetheless, having a big pick-list of the kinds of conflicts you can have is a pretty labor intensive and ultimately futile - players regularly want to do something outside that list, and when the list gets long enough, the item in question might as well not be there because the players can't find it.
In this respect, there are, by Ben's definition, both Task and Conflict resolution.
The fact that other D&D publications regularly (apparently) publish rules for new arenas of conflict indicates that it's something the basic rules imply but ill-implement.
I don't call it historical accident. I call it willingly misleading while remaining totally, totally ignorant of the actual cause of the problem.
I must admit, with the definition of "conflict" being "what the players care about" it seems to me that that makes the definition of "task" into "things the players don't care about".
Do I save the princess / do I win the game? Conflict.
Do I hit this hobgoblin / do I succeed in something that, if I fail, will have little actual effect on winning the game? Task.
This stuff also isn't agenda-independent. Geez, now I have to delve into jargon. A gamist agenda where the focus is on exploration of the system (AKA ooo, new system! Let's beat on it until it breaks!) would be far more interested in the 'task' resolution than whatever the game assumes is the goal/conflict of the stories told. If the players are interested in the nitty-gritty, then which is conflict and which is task?
Now, I don't think the distinction is useless, but I do think your definition of conflict is a bit too broad. There is a big difference between GURPS, which only ever tells you if the character succeeds at a concrete task, and stuff like the Pool which tells you if the character is successful in moving the story in ways the player wants to. In the end, I think this is pretty fundamentally agenda-based -- if you want to see if your character can do stuff, you want a system that focuses on tasks; if you want to see your character participate in a story, you want a system that focuses on conflict. It's just a matter of having the right tools for the kind of experience you're after.
Ben,
I think we're on the same page except for where you say: "We can now realize that Task and Conflict resolution are, in fact, orthogonal to each other, and we can look at four types of games in terms of text." and then provide your list of 4 game types.
This pretty clearly isn't a textual decision, but a specific playgroup defined one. Textually you either have unbounded resolution or bounded resolution. Whether the bounds in question are wide enough to handle things at the "conflict level" is dependent on what that level is.
So, basically, you can say "This text includes unbounded resolution mechanics" and "this text includes bounded resolution mechanics". It seems to me that whether any given instance of resolution is Conflict or Task is really up to the players almost entirely.
I've been in Universalis games in which the unbounded resolution system has been used as a task resolution system.
In fact, I'd be willing to say that the only way the specific mechanics themselves impact whether a group is using task or conflict resolution is the scope of resolution. If a given text provides no way for a group to mechanically resolve what really matters to them, then that text does not support conflict resolution for that group. But even that is, ultimately, a function of the group. There is nothing inherently "conflict" or "task" about a given mechanical system (except in that unbounded resolution systems will always allow a group to resolve conflicts whereas any bounds at all may prevent that).
Is that what you were saying already? Am I misreading your intention when you talk about texts?
Thomas
Brand -- yup! You nailed it. (although strictly by the book D&D has more than a few non-combat arenas where conflict resolution applies.) In terms of talking about whether or not meaningful results are "GM fiat," the presence or absence of Task Resolution is a red herring. All that matters is the presence or absence of appropriate tools for Conflict Resolution.
yrs--
--Ben
Thomas --
Yes, mostly. Presence or absence of appropriate conflict resolution.
RE: D&D The reason I refer to it as a Conflict Resolution system is that it can resolve a fairly wide number of conflicts (way more than just "do I kill this guy). However, if your main conflict is "do I rescue the princess" then, yes, D&D is not a good system for you to be using for conflict resolution.
What I want to do is totally eliminate reference to "task resolution" in the absense of "conflict resolution." If there are appropriate tools for conflict resolution within the system, you can resolve your conflict with the system. If there aren't, you can't. The presence or absence of task resolution is totally orthogonal to this.
JasonL --
Fair enough. The reason I put in D&D is that it does have a wide variety of conflicts to resolve, rather than just "does this guy die." But you will note that this is a matter of taste.
Watch my terminology drift -- in my response to Ralph, I talk about whether the system has conflict resolution mechanics that apply to the situation. This is a much better way of talking about it, I think.
Brand is also, of course, correct. If you play D&D strictly by-the-book, you will most often find conflict resolution tools within the system, and not have to rely on the social negotiation process. If you play WoD by the book, there is no way in hell that this is going to happen.
Joshua--
You have demonstrated a better knowledge of GURPS than I have. I will stop picking on it, and return to picking on World of Darkness, which I know.
What do you mean by "willingly misleading?" Is that me? Why?
Jason (Ludisto) --
Nope! Conflict is about "what the players care about." Task is about characters and their actions. They are totally disjoint from each other. In some cases, a task is exactly the conflict.
Your stuff about Gamism is also wrong. Could you maybe e-mail me privately about it, or we could set up another thread for me to talk about it with you?
yrs--
--Ben
Thomas, second post --
You're still not with me.
Task resolution is orthogonal to conflict resolution.
So, if the game has a conflict resolution system, it will or will not be sufficient to cover all cases of conflict that your group runs up again.
If it fails to be sufficient, you are left with a conflict resolution system, and must rely on the social persuasion, etc that goes by "GM fiat."
This is totally unrelated to whether or not there is a task resolution system, and whether or not that task resolution system that applies to any given task.
There are ways to turn a task resolution system into a conflict resolution system (see "Let It Ride" in BW Revised) and there are ways to turn a conflict resolution system into a task resolution system (such as your Uni game, some questions about that in the PS.) But they are not the same thing.
(My real point is this -- once we stop trying to make task resolution serve as conflict resolution (which, frankly, it sort of sucks at), what can we do with it? It amuses me that no one has addressed this at all.)
To illustrate, I'm going to ask you to imagine a system where the conflict resolution is totally disjoint from the task resolution.
My guy is going to save the princess. We know this, because the conflict resolution system told us that he is going to save her. So I come to the great castle in the woods. I try to swim the moat. Failure. I fall in and drown. But then I wake up in a ditch down the way, coughing up water, saved by some good-hearted peasants. I try to get them to tell me the secrets of the castle. Success! They tell me it is guarded by the black knight, and the only way in is to defeat him in personal combat. I go to fight the black knight. I lose! I turn away, dejected. The next day, I go to fight the black knight again! I lose. Even more dejection. On the last knight, I challenge the black knight to a story-telling contest instead. I still lose! This sucks, because we all know that I have to rescue the princess. So the black knight lifts off his helmet and reveals that he is my father! Wow! We totally bond, and he lets me come in and have the princess, and gives me leave to marry her or whatever. (that's a follow-up conflict.)
Did you see how the conflict resolution was about what happened, over all, in an important way, and the task resolutions all served to provide detail about *how* that thing happened?
yrs--
--Ben
PS Did the conflict -> task situation in the Universalis game result in play with a lot of negotiation and discussion about what the die results meant?
Ben,
La Ludisto is a Josh, not a Jason.
He's also taller than me, which is annoying as there aren't many gamers who are taller than me.
As for something on topic: There can be a place where the gate between explicit and implicit conflict resolution goes up -- and that is "do the players know it, and if so at what level."
When you're playing HeroQuest or the Pool or Dunjon (just to put a "gamist" one in there) you specifically know what the conflict is, what the scope of it is, and how the conflict as a whole will be dealt with directly in game terms. You run out of AP, you get your narration, etc, you’ve won the conflict and things move on.
When you’re playing D&D, which does have some kinds of conflict resolution, you still (as a player) may not know it. Do you actually realize that getting the princess out is the goal? Is it the goal? Or is killing everything in the dungeon the goal and the princess just the symbol of the way women get treated in gaming? Even if the princess is the goal, and you know that the way to her is on a road of blood and slaughter, do you know when you’re getting to that goal? If you’ve killed 8 orcs and 6 hobgoblins, how much farther is there to the goal? When will you get it? If you leave now and come back later will reinforcements have arrived? Is there a dragon in this castle? Now some of these you can answer by looking at the game’s conventions (“we’re 5th level so 8 orcs and 6 hobgoblins is only about 1/3rd of the suggested EL, and there will probably be a CR 8 dragon at some point because why have a princess without a dragon?”), but in the end the scope, scale, current position, and end position in the players in the conflict are hazy at best.
This, of course, becomes a focus of the “metagame knowledge yes/no” question, along with the “immersion yes/no/maybe so” one. Does knowing the start and end conditions lead to more immersion or less? If you’re playing a game like HeroQuest with its pervy system that wants you to min-max the system to push your goals at the conflict level does that lead to different play than D&D with its pervy system that wants you to min-max the system to push your ability to effect play at the task level? (My answers to the four question are: yes, maybe, neither, and of course.)
Perhaps there is a way to combine the elements of both that gamers seem to like? To have an player-implicit/GM-explicit conflict resolution system that gives the GM clear and system-defined ways to handle all conflicts, while leaving the players to focus on the tasks because they don’t see the meta-conflict system? The players would, I think, have to know that there is such a system and that the GM is following it – but wouldn’t have to know where they are at any given point, just the tasks that they can follow to resolve the conflict and in what way they interact with the conflict.
(I did something like this in Church and State, where there is a system to determine who wins and loses a trial that works by tracking points that the PCs accumulate through tasks throughout the trial. However, because I didn’t realize what I was doing at the time I didn’t make it as effective as I should have. The players should be told more than I told them, and the fact that the system was there explained to them, at the very least.)
Ben,
I think we're on the same page now! Let's find out...
1. There aren't conflict resolution mechanics and task resolution mechanics. There are only resolution mechanics.
2. Resolution mechanics have a scope. If what you want to resolve falls within the scope of the mechanic then you can use that mechanic to resolve it.
3. Conflict is what the real-life players care about. Task is what the characters do in the SIS. Both conflicts and tasks have a scope.
4. Since tasks and conflicts come from different sources (characters in the SIS taking action vs. real-life players caring about something) they are not actually related to one another except that traditionally conflicts are resolved via a series of at least one task (this is true regardless of where the mechanics arbitrate things).
Are we cool? Am I reading you right? Because if that's what you're saying, then I say you're dead right.
As to the Uni game... What we ended up with was (game killing) discussion of what it meant to win a given "conflict". For example:
-"Ha, I win the 'Robot uses poisen darts to knock out Bob' conflict, Bob's unconcious!"
-"Yeah? Well, I'm starting a new conflict in which Bob's ninja bodyguard jumps in to save him so that Bob doesn't get captured."
-"But... capturing Bob was the whole point..!"
-"Tough, you didn't say that!"
-"Fine..."
-*resolution!*
-"Ha! The ninjas succeed, Bob is snatched from the clutches of the robot!"
"Fine, but just as the ninjas start to run away, Evil Mastermind shows up to take them out and get Bob!"
-etc.
The mechanics were being used to resolve individual tasks, not what the players actually cared about.
Thomas
In the latest (not yet PDF'ed) version of Verge, I wrote something like, "If you roll dice, win the roll, and still haven't achieved what you want, then you are resolving tasks, not conflicts."
Your stuff about Gamism is also wrong. Could you maybe e-mail me privately about it, or we could set up another thread for me to talk about it with you?
Right here.
Going back to Ben's first response to my initial comment.
Yeah, I do think you're still missing the key point. Conflict vs Task isn't about game mechanics at all (how they interrelate is a very interesting discussion, but that's not the key). Conflict vs. Task is a thought process. Its a state of mind. Its an APPROACH to resolution.
What the game mechanics are, are entirely irrelevant to whether the players are thinking in terms of conflicts or thinking in terms of tasks. How are they going about setting up what to roll and how to interpret it. Mechanics only enter the picture to the extent that some mechanics make a conflict thought process easier to implement and others make it more difficult to implement. But its the thought process that matters.
How the players frame what is going on in the scene and how they envision using the mechanics to get through it, is where the rubber hits the road.
Take a game of D&D. The characters have been sent on a mission to recover a lord's sword from a Goblin Chief. The party has arrived at the entrance to the goblin lair.
There are many ways that this situation could be framed as a conflict. In traditional D&D play it won't generally be framed using a ritual formula (like DitV's "What's at Stake is". But the meta strategizing that goes on around a D&D table will generally give a good idea about what the conflict is.
It might be "Ok, lets get ready to kill all the goblins and then we'll recover the sword from the Chief's corpse".
It might be "Ok, lets make the thief invisible and see if he can sneak in and steal the sword while the Chief is sleeping"
It might be "Ok, lets set up a diversion so we can get the Chief alone and bargain with him".
Whatever. Most D&D groups will come up with some sort of game plan and the ultimate objective of that game plan will usually be something we can recognize as filling the "What's at Stake..." role.
Now...here's the rubber hits the road part. Having determined what the conflict is (explicitly or implicitly), how do the players set about thinking about how to resolve it mechanically (whatever the actual mechanics happen to be...in this example d20).
If what they are thinking is setting a number of events in motion. And each of these events require some game mechanic resolution. And the players are take the approach that they'll follow along the series of events (whether the series is one event or a dozen events long)and "see what happens". They're taking a Task Resolution Approach.
Eg. the party decides on a sneak in and steal the sword approach.
1) Mage casts invisibility and game rules related to spell are consulted.
2) GM calls for a move silently check and notes this will get the thief halfway across the room and asks "what do you do next".
3) Thief player announces they're going to continue across the room and GM calls for another move silently check.
4) GM announces that the thief has arrived next to the sleeping chief and asks "what do you do next"
5) Thief player announces they're going to make an Observation check to find the sword.
6)GM announces that the thief has found the sword and needs to make a Pickpocket Check to take it.
etc. etc.
Each event is its own independent task and at no time do the players really know what they have to do to actually accomplish the goal of getting the sword. They'll keep declaring actions that they THINK will move them closer to their goal and success or failure on those actions will create a potentially sprawling and branching event tree. But essentially they're on the trail will no real way of knowing for certain when the trail will end.
The GM might just keep throwing rolls down until they fail one. He might reveal after all the goblins are dead that the sword is already gone because some bigger nastier orcs already took it. He might reveal that the goblins never had it to begin with and the whole mission was a wild goose chase, etc. The trail of tasks never ends and never resolves the conflict until the GM decides the conflict gets resolved.
At no time in this sort of play is there ever a roll or series of rolls that can be truly said to resolve the conflict. At best you have a series of rolls that MAY resolve the conflict. Even the Combat system doesn't REALLY resolve the conflict except in the most broad sense because there is really no time at which what's at stake is really set down and solidified.
Now. Take the same situation and the same game and resolve it using a Conflict Resolution thought process. Here's one way it might go down.
1) GM announces that following the casting of invisibility the thief player will need to make a Move Silently Roll, an Observation Roll, and a Pick Pocket Roll.
2) If the thief makes the move silently roll then he will get in and out without alerting the goblins. If not then the goblins will wake up while the thief is still in the room. If he makes the observation roll than he will correctly find and identify the desired sword. If not than he locates the wrong weapon. If he makes the pick pocket roll then he will take possession of the weapon he located.
3) The thief makes the rolls and fails the move silently. He knows exactly what the consequences are. He knows he has the sword in his possession. He knows its the right sword. And he knows he's still in the room when the goblins are alerted.
There is never any doubt in any players mind that at the end of this sequence of rolls the conflict WILL be resolved and what that resolution will be. If the thief makes all three rolls he will have the sword, it will be the right one, and the goblins will not spot him until he's safely out of the room. That's how the conflict was framed...that's what's at stake in the scene...that's what the mechanics are used to determine.
Contrast this with Dogs in the Vineyard. We often point to DitV as being Conflict resolution. But really, what makes it Conflict resolution is NOT the nifty mechanics. Its the very clear instructions on how to frame "what's at stake" and what it means when one side Gives with regards to resolving "what's at stake".
As an exercise, imagine playing DitV exactly as normal, using all of the games rules...EXCEPT...the rules having to do with establishing "what's at stake".
The players enter the resolution system directly...roll dice based on whether they're talking or fighting etc. Raise and see as normal. And then when one side yields, they look back over the sequences of raises and sees and determine what the outcome of the resolution is.
Guess what. You've just turned DitV into a pretty neat Task Resolution System. No one really knows what the end result of that sequence of raises and sees will be...they're just letting the end result fall out organically from series of events.
THAT'S the key difference
With Task Resolution you know before you roll what the possible outcomes for that Task are. I roll to hit. I will either miss, or I will hit and roll for damage. But the outcome for the conflict will simply fall into place organically as a result of the accumulation of tasks.
With Conflict Resolution you know before you roll what the possible outcomes for that conflict are.
Note: I say you know "what" the possible outcomes are. You may well not know the how or the why.
Also note that "what's at stake" may be in game or meta game. In the Pool and Universalis "What's at stake" is "who gets to say what happened".
Ralph --
Ahah! I think we have some common ground, finally.
Here's what I'm saying:
Let's say "Do you get the sword back from the Goblin King" is the conflict.
That conflict is going to be resolved in play, no matter what techniques are employed in resolving it. (Provided that the game doesn't end or break down before it can be resolved.) However you resolve it -- with mechanics or with social negotiation -- that is your method of conflict resolution for this conflict.
My further point is that whether or not you are forced to resort to social negotiation is totally unrelated to whether or not there are tasks being resolved during the scene. You can have task resolution without formal conflict resolution (like your first example) or you can have task resolution with formal conflict resolution (like your second example) or you can do away with task resolution entirely and just have formal conflict resolution (like if the game was the Pool.)
Does that make sense?
yrs--
--Ben
It makes sense, but I'm not sure where you're seeing the common ground exactly.
Yes, every game will have something we can identify as a conflict (little c). And yes, through play those conflicts will get resolved (little r).
But what does that have to do with the issue of Conflict Resolution (big C, big R) as I described it above?
Sure conflicts are getting resolved. But are they getting resolved through the techniques of Conflict Resolution (where the whole point is to drive right at the conflict and resolve it)?
or are the conflicts getting resolved through the techniques of Task Resolution (where the whole point is to resolve the tasks and let the conflict eventually resolve organically through play however it happens to fall out).
In both cases the conflict gets resolved. But are we in agreement that each of those two cases are very different in approach, lead to very different play experiences, and deserve to be distinguished from each other in terms of designing games that facilitate one or the other?
If we are in agreement, then how do you suggest those cases be labeled? I've been labeling them Conflict vs. Task Resolution...which I think is pretty consistent with how Vincent was using the terms when he started throwing them around (though I'll let him clarify that for certain).
But, while I think what you're talking about is quite interesting and valid in its own right...I don't see how it address those 2 cases at all. So I don't think we can keep using the same terms to describe two completely different things.
Post a Comment
<< Home