Task resolution

From Post-Apocalyptic RPG wiki

Jump to: navigation, search

Submitted mechanic.png This article covers a submitted game mechanic.

Submitted game mechanics have been fleshed out in detail and are ready for review by the other developers. Once submitted mechanics have been reviewed and agreed upon, they become accepted game mechanics.

This supersedes: Thoughts on Task Resolution


Background and Motivation

This Mechanic is a general interaction between the player (or NPC) and the game state. In particular, it handles cases in which an attempt to change the gamestate is "contested". Contested in this instance means that there is some random probability of success or failure. There are other types of "in game" actions which are not contested (for example, moving your character on the map, or initiating combat). There are some types of action which MAY be contested (for example, opening a door, or initiating dialog with an NPC), but are usually not contested. Other actions are nearly always contested, for example, "use a skill (includes combat skills)".

In principle the whole combat system can be considered a "task" - or a chained set of tasks.

Any attempt to change the gamestate by an Agent (typically PC or NPC, but sometimes "non character CPU") that has some probability of success/failure is called a Task. Tasks can be defined in a general way using templates, and different types of tasks can use these templates or or add their own functionality.

Task resolution is closely tied to scripting in that a given script can generally be composed of "task-less" actions (such at movement) coupled with some skills/Tasks.

This system can be thought of as a structured generalization of what happens in most PnP RPGs "roll a die and see what happens" - but instead of using a fixed set of "dice" like 3d6 or d100 and look up tables - the look up tables and rolls are just defined together in a template (set of outcomes + probabilities)

What is a task?

At various times in the game, actors (typically, but not limited to the PC) may attempt some action to change the gamestate. The change of gamestate desired (it may be explicit or implicit) is called the Goal. This is called a "task". Some outcomes require that a task have a quantitative result (ie., some amount of X happens), or else each result must be specifically scripted. In general - for ANY task the types of outcomes include:

  • Super success - The goal is met with an additional orthogonal result that favors the actor.
  • Total Success - The goal is met. The task can usually not be repeated with the same actors/objects.
  • Partial Success - Some progress is made toward a goal. The same task can usually be repeated, although additional resources may have to be expended and conditions may change). All else being equal, the actor is no worse off than had he never attempted the task.
  • Orthogonal Result - A result is obtained that has nothing to do with the task goal - but is typically net neutral for the actor. The original task may or may not be no longer valid or attemptable.
Example:  You attempt to shoot enemy X, but shoot enemy Y instead (you can usually at X again next turn). 

It is possibly to have an orthogonal result in addition to a partial success or favor. These results may not be neutral to the actor overall (but they should be neural to the specific goal... otherwise it wouldn't be orthogonal)

Another Example: You attempt to derail train X, but train Y is derailed instead (and chance for X is lost). 
  • Partial Failure - Negative progress is made towards your goal. All else being equal, the actor is no better off than had he never attempted the task.
  • Total Failure - No progress is made, and the task can no longer be attempted with the same actors/objects.
  • Super Failure. - As total failure, but with an additional orthogonal result that disfavors the actor

Not all attempted actions have all six results, in fact, a given game may never implement some of the outcomes for _any_task ever. This is just meant to be a complete description of possible task resolutions. Some tasks are essentially binary - you either succeed or fail with no partial or super success or failure possible. Example: Perception - you either notice something or you don't. Some PnPs have a mechanism for critical perception failure - which might mean the GM has to convince the player that he sees something that is not there. (This is not to say that some perceptions tasks couldn't be coded with partial successes). A "blank" failure or no effect can be considered a partial success or failure with value 0.

Tasks may or may not require consumable (such as money or time) or renewable resources to complete, or require certain conditions to be met (item in inventory, pc in at a certain map location, at a certain time of day).

Active vs. Passive tasks

Some tasks require an active decision by the player to execute - these are called Active tasks or Active skill use. Skills that are used without the players direct action are called Passive tasks or skill use. The practical difference from the programming perspective is that Active skills are triggered by the GUI (or console substitute), while passive skills are triggered by planned scripting events (or, conceivable, AI actions). If an AI is controlling an actor, the line between an active and passive action is somewhat blurred.


Note that "super" here is used instead of the more common and obvious "critical". That is because in many systems, a critical success is just a very high partial or "maximal" result for an attempt - but might not achieve the goal. Example: PC attack foe A with the attempt to incapacitate him. He selects his action and rolls. He could (in some systems) roll a critical success - but be incapable of actually fulfilling his goal with a single attack!

Task Templates

Tasks are defined by the designer in template files. A template file can represent either a very specific task (for example, tied to a specific quest or specific location/object on a specific map. A template file can also represent a SET of tasks that are all grouped by they inputs and outputs. A "grouped task template file" may have ALL inputs and outputs for the task specified, or they may leave some customizable (with defaults). In this way - they are very similar to an inherited set of objects in a computer programming sense. An example of some "grouped task templates" can be found in the Crafting mechanics, although these do not as of yet have P values associated with all outcomes.

A template is essentially a set of rules - given these inputs - what are the chances of each output (from "some" of the implemented "successes" and "failures" above (i.e, "Total success", "Partial Failure").

At the end of the day - the software must decide what the possible range of results are for any particular task, and their probabilities (Ps) . The mid-range Ps might range from 0.01-0.99. Rare Ps might have higher exponents say 1e-06 to (1-1e-06) or whatever. This system allows full flexibility to give as wide a range of results given any relevant input parameters.

Task Parameters

Each task has a set of parameters and rules that account for the inputs and outputs (possible outcomes of the tasks). The inputs are a set of dependencies (typically objects, locations, game state, etc.), and a set of gauges (skills, stats, attributes, talents) and a vector weighting them. The inputs are combined in a set of rules which determine the P values for every specified outcome. This sounds needlessly complex - but it's just to describe the general case. Some examples follow. I use a "0-99" roll here -but what I really mean is a rnd(1) generated float between 0 and 1 (exclusive). My examples don't have any probability out comes <1%, so we can round to the .01. If _really_ rare things want to be added, it's easy to just add decimals. Yay computers!

In both cases, I use a simple model of skill roll minus difficulty. This is just for illustration purposes. There are many other "valid" ways to combine the inputs to get P values.

Task Difficulty

Tasks, or rather, Task groups can be classed into various difficulty levels. This is a useful framework for allowing certain items, situations, or environments to "shift" a task harder or easier. There are 5 classes of difficulty:

  • Trivial (D = -100) - this task generally does not require a roll-- or even knowing the skill. In some cases, a rare "fumble" roll for a disaster (recommended P<= 0.001) might be warrented.
    • Example: lighting a fire with a match (no rain), breaking something into component parts
  • Easy (D = -50) - This means easier than Normal, so for a skill rated X, success should be roughly P=X+50.
  • Standard (D = 0)- This is the default difficulty, so for a skill rated X, success should have roughly P=X.
  • Hard - (D = +50) This means harder than Standard, so for a skill rated X, success shoudl be roughly P=X-50.
  • Impossible - (D = +100)This is not literally impossible, but requires some modifier to have more than P>=0.01 chance of success

Note that these are just a guideline for Items/Modifiers. If you want an item or modifier to make something jump from Hard to easy, it should have a +100% modifier! Each "level" corresponds to roughly 50%. You may use any D value you wish.

Difficulty modifiers

As mentioned, this can be specified in the individual task templates. They might include tools that make things easier or faster. Many intensive tasks can be made easier 1 level by taking 2X the amount of time for a "Standard" roll, or be done 2x as fast by increasing the difficulty by 1 level. Such tags have the property "Time Sensitive". Note that, in general, Task Difficulties only modify the P for "Standard" Failures or Sucesses, not "Super", so it's not precisely like just adding 50 to your "roll".

Simple example

  • Find a secret door (note that this could be made arbitrarily complex by adding what the actor is wearing on his hands, the light level in the room, any other general stress or perception modifiers - such as whether or not actor is wounded, or on drugs)
    • Inputs
      • Actors perception skill (a gauge - weight 1) doesn't have to be a specific skill - could be = characters intelligence
      • Difficulty D (how well hidden is it)
    • Outputs
      • Full success: You find the door, and can now access it from GUI
      • Full failure: You will never find the door
    • Rules
      • Compare random roll (0-99) to perception skill - D.
  • Roll > (skill - D) - Full failure
  • Roll < (skill - D) - Full success

Complicated example

  • Pick a locked door (note that it is probably overkill to implement all these outputs - it's just an example)
    • Inputs (dependencies)
      • Actors picklock skill (a gauge, weight 1)
      • Lockpicks item equipped in hand, quality of lockpicks
      • Lock difficulty is D (Average)
      • Current lighting level of location
    • Outputs (outcomes)
      • Super success: Lock is picked, and you gain +10 lockpick skill for innovative technique
      • Full success: Lock is picked
      • Partial success: Lock is not picked, but further attempt has an N skill bonus (where N is some f(random)) -
      • Partial failure: Lock is not picked and further attempts have an N skill penalty (where N is some f(random)
      • Full failure: You fail to pick the lock and can make no further attempts
      • Super failure: You jam the lock and break your lockpicks
      • Orthogonal result: While you are trying to pick the lock, you hear hushed voices on the other side of the door
    • Rules
      • If you have no lockpicks - all attempts result in Partial failure with N=0. (i.e., nothing happens)
      • Compare random roll (0-99) to picklock skill. Subtract 10 from roll for each level of light lower than "full daylight". Add/Subtract N from previous attempts.

Delta = Roll - (skill + D)

Ranges of roll:
0 :  Super success
between 1 and skill - D: Full success
between skill - D to skill +D (exclusive range) Partial Success/Failure with N = - delta/2 
between skill+D and 99: Full failure
99 Super failure
Roll divisible by 11: Check listening task for Orthogonal result.

So if D = 10, and skill = 50:

1-40 Full success
41-49 partial success +5 to +1 on next roll
50 no effect
51-60 partial failure -1 to -5 on next roll
61-99 full failure
with special effects on rolls of 0,11,22,33,44,55,66,77,88,99(2)

Note 2 thinks about both of these examples. By including D and actors skill as variables, we have already made a single task apply to a class of tasks simply by varying the linear difficulty. In both cases the gauge input is generalized. If the character doesn't "have" the specific picklock skill - a default can be used. The default can be 0. A specific rule could be added to deal with 0 skill, but it's probably not necessary.

Example with multiple gauges

Multiple tasks might be Parallel (have to use both simultaneously) or Serial, have to use one then the other (like a chained task, but first part of the chain doesn't really have an output).

Parallel Tasks

A case where 2 skills (or more) are combined with a weighted average (for example, trying to shoot a target while riding a horse) would take both archery and horseman ship into account (possibly with equal weights).

Serial Tasks

A case where need to use a skill to know what skill to use. For example, to Build a Still you need to make a Distillation or Chemistry roll (or find schematics) before you can use your Jury Rigging skill to put the thing together.

Chained tasks and subtasks

In principle - tasks can be chained together - this is simply modeled as a task that takes successful completion of another task as an input. The distinction between a chained task and a subtask is somewhat semantic and subtle. Both require a "major" task with parts that are required. If the "parts" are in themselves useful (perhaps they are permanent, or produce something on their own) the it's a chained task. If the "parts" are obligate - i.e, have to be done everytime then they are subtasks. Chained tasks in a major tasks often (but not always) have a defined order of completion. Subtasks might or might not. Chained tasks and subtasks can be nested as deep as programmers/designers are willing to go

A chained task would require another type of "Template grouping" file -- essentially a script -- that indicates how various game states can be manipulated.

Chained task example

Player wishes to use "blacksmithing" to forge a weapon. To forge a weapon the inputs are:

  • "working forge" (including heat source)
  • "hammers and tongs" (or other tools)
  • materials (i.e, steel)

Without going into smelting ore, etc. the PC could have a blacksmithing+engineering task to build a forge, then a blacksmithing task (easy) to make the tools, then finally a task to make the weapon. In this case - the order is important - you have to build a forge, THEN tools, THEN weapon (although you can get the materials before or after making the forge)

Subtask example

Player wishes to defeat a group of bandits. Every bandit has to be defeated (killed, captured, reformed, whatever) - and defeating them one at a time can be considered separate subtasks. Note that if they are defeated in "batches" (perhaps with one start/stop of turn based combat), then there might be 2 levels of subtask.

  • Defeat all 16 bandits
    • Defeat guards at the gate (5 bandits)
    • Defeat off-duty bandits in living quarters (5 bandits)
    • Defeat inner circle in council room (5 tough bandits)
    • Defeat bandit leader (1 leader bandit)

Here, the order is not so important, and in fact, if you manage to defeat the leader first, it might help you defeat the rest easier (or even make their surrender automatic)

Tasks and Combat System

When originally designed, it was clear to me that "Combat" was a specific (complicated) case of Chained tasks. Essentially it uses various skills to achieve a goal (victory & loot). However, while it may "tie into" or use some of the same low-level code as the Task system, it probably is not too useful to think of "Turn based combat" in terms of "tasks".

Personal tools