More on tasks and conflict | KingSpoom's RPG Design & Theory Junkyard

More on tasks and conflict

Okay, more things to be said about task and conflict resolution now that I have seen some interesting things discussed over at therpgsite forum. I see 2 things that conflict resolution advocates are hanging on. The first is just wrong, but still a justifiable way to view task resolution. The second isn't so much a problem with task resolution, as it is a shared problem with the system (or lack thereof).

The first hangup... task resolution leaves the actual resolution up to GM fiat, or that task resolution + GM skills = a means to resolve the conflict, task resolution can't do it alone. This is usually accompanied by an example that shows it was a mistake. The mistake is that the lack of evidence for a task, is the proof that the GM is resolving the issue himself. Such is not the case. Example:

Player: I want to jump over the fence to catch the ship.
What is at stake? Whether or not the character jumps the fence.
Roll: Success, you jump over the fence, but the ship has left the port.

Above is a common example of task resolution and it gives a false appearance. It's a shorthanded way of how things could go, but it isn't really a task resolution system as written. It's a fiat-resolution system. In a task resolution system, a conflict will be resolved according to a number of tasks that is determined by the situation. In the above situation, we are only shown that the player succeeds in jumping the fence. However, task resolution runs almost like a simulation. The GM should be considering:

1: How long does it take to jump over the fence?
2: How long will it take the ship to leave the port?
3: How fast is the character?

All that's left is to simulate the situation by running it out, round by round. Round 1, jump the fence and the crew prepares the boat, round 2, move 120 feet towards boat and the crew opens the sail, round 3, move 120 feet towards the boat and the crew fixates the sail to wind, round 4 boat moves 60 feet away from dock and character realizes he cannot make it. That's task resolution, and it resolved the conflict. Anything else is just someone skimping on the tasks by ignoring them, or (in the case of actual play) the GM skimping on telling the player exactly what task he failed at to accomplish his goal (or, just as likely, the player not noticing he failed a task and thinking the GM just screwed him).

The second hangup occurs when a situation isn't broken down into tasks because there is no 'skill' to cover a task. In dnd, you could want to seduce a barmaid. There is no skill that covers this. If, for every situation, the GM could say "Okay, roll skill X", I don't think other people would have a problem with task resolution.

As it stands in dnd, the GM could ask for a diplomacy roll to seduce a barmaid. It could be broken into several diplomacy rolls, or there could be direct charisma rolls, or opposed charisma versus wisdom rolls. Either way, the main problem is that something a player wants to do isn't covered by the rules, and some GMs will follow the rules (offer a diplomacy roll), but not give the player what they want exactly (you succeed with your diplomacy roll, but she isn't seduced). There's a lack of communication that another 2 successful diplomacy rolls will accomplish his goal, but that lack of communication is only a habit, not a hardcoded part of the resolution system. If the player could be reminded to ask the GM what he must further do to seduce her, or if the GM were to realize that he can't stop talking after he says "but you haven't seduced her", there would be no problem.

In restrospect, the same thing can happens in conflict resolution, people are just ignoring it. Conflict resolution usually works at a scale that is above these things, but that's just another choice.

Player: I want to seduce the barmaid to gain access to the tap.
GM: *thinks* That's too large of a scale, let's say that if you succeed at 3 out of 4 rolls of diplomacy, you will have successfully seduced her.
Player: *rolls once* Success
GM: You haven't seduced her yet...

I'm going to cut it off there, because the only difference between task resolution and conflict resolution, as they stand, is that in task resolution the GM isn't likely to tell you all the tasks you need to accomplish, upfront, in order to succeed. In both cases, the player could roll a success without accomplishing his goal. In both cases, the GM could say that success is not possible and deny the player an opportunity.

Another difference that people might argue, however, is that once it is agreed upon that 3 of 4 successful diplomacy rolls seduces her, the GM cannot go back on that. The same thing applies to task resolution, but there are different cutoff points. After those 3 successes, the barmaid is seduced, but the player wanted access to the tap. The GM could have a fire start and thwart access to the tap anyhow. In task resolution, the GM could interrupt a diplomacy attempt with the fire, because diplomacy takes 2d4 minutes and the fire was set in 5 minutes. Conflict resolution seems to balk at this idea because it usually ignores extra conflicts or it constantly allows the opportunity for content anyhow.

No doubt, if the fire started in conflict resolution after the diplomacy successes, the player would try to put the fire out in time to save the tap, or he would try to access the tap before the fire got to it. Both can be handled by either system.

In task resolution, without being upfront, it is easier to cheat your way out of a situation. In conflict resolution, you know ahead of time what can and cannot happen. In conflict resolution, there is a lot of metagame knowledge thrown about. In task resolution, you never know what could happen. Personally, I don't want to know what can and cannot happen in a given conflict. I do realize that problems can be caused in task resolution when a task is not covered on the character sheet. This is why it is important for everyone to understand the genre, and for the system to handle the genre as a whole.


Anonymous said...

There's always the middle road. I tell up-front how difficult a roll is and what roughly happens on success (and usually let player describe how it happens). I may or may not tell what happens if a roll is failed, but it is always nasty.

KingSpoom said...

Thinking back, I'm not sure if 3.x encourages or discourages the DM from telling a player what the difficulty is. As a player, I've always been told in dnd, and as a GM, I've always told the player the difficulty.

I think I prefer the consequences of success and failure to be spelled out in the rulebook, if possible.