Conflict, intent and stuff…
On RPG.net there was a discussion about stakes that invariably turned to conflict resolution, which is something I’ve been looking at myself. Some of the interesting things that came up is confusion over conflict resolution as it is apparently defined by rpg theorists (not game theorists, who are a different animal entirety) and resistance to the idea. So I’m going to try to break down what appears to be the building blocks of certain implementations of conflict resolution to gain a better understanding myself.
In most standard rpgs, everything a character does can be broken down to an individually resolved task. Most games give guidelines as to when to call for a ask to be resolved - if the task if opposed, or being done under pressure, or is just hard, it generally requires resolution. Few give solid guidelines as for how to break the tasks down besides using common sense, with the exception being combat.
So the first thing that has to be tackled is how atomic do tasks need to be? This helps define the scope of resolution. In order to repair a car for example, realistically there are dozens or even scores of individual tasks that have to be accomplished. However, many games (even ones designed before there was a concept of “conflict resolution”) resolve that with just one “Automobile Repair” roll. Yet those same games will turn around and require a character breaking into a building to roll separately to pick the lock, sneak down the hallway, pick another lock, sneak past a guard, etc.
However, conflict resolution doesn’t seem to be worried so much about scope - it’s concerned with encapsulation. In other words, how does information gleaned from one task affect the other? In the two examples above, either you fail fixing the car or you succeed; yet you can succeed at picking the lock and fail at sneaking down the hall. The lock picking and sneaking tasks are encapsulated and do not share their resolution with one another.
As John Wick pointed out in his blog the determining factor is consequence. Since actions like combat have severe consequences, the scope is often narrow and the encapsulation high. Curiously, this is often true of important applications in the real world. The electric company doesn’t have the it’s switching systems tied to a seismograph at CalTech. You can succeed on your hit roll, roll crap damage and then decide to change tactics before you get creamed. If the entire exchange rests on one roll, you lose that ability to choose. So the trick when designing a conflict resolution system that resolves, say, a volley of attacks with one roll is to offer some way of allowing the player to weigh consequence and make decisions in a similar manner to what happens in a task resolution system with lower scope/higher encapsulation. One way I think is John’s system with wagers, the other is to allow for changes to be made after the dice hit the table. So you’d have wagers that are set in stone, the dice are rolled, and then some mechanism to allow the players to overturn or alter specific results (but not all of them…maybe some kind of trade off or exchange). I’m going to have to think about it a bit more.
