Task resolution

This supersedes: Thoughts on Task Resolution

NOTE: (especially for qubodup and other "minimalists") The below is NOT an attempt to make PARPG the most complicated game in the universe (even thought it might appear that way). The purpose of the following is to consider how RPGs in general handle task resolution, and to consider implementation of a a very general task resolution system. One which is flexible and expandable -- allowing us to set the detail level for different types of tasks. I came up with it while pondering why some systems use 3d6 skill resolutions, some use d100 (or the nearly equivalent d20), and whether or not they take into account modifiers or "made roll by", or "open ended rolls". It's reasonably trivial to code nearly every possible permutation of rule type - the work then becomes setting the rules/inputs/outputs themselves in a logical manner which fits the game. What I think it will be very useful for is grouping simple tasks together to form "quests"

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

What is a task?
At various times in the game, actors (typically, but not limited to the PC) may attempt some action. This action has a goal. Attempting to an action to acheive a goal 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. The possible outcomes are:
 * 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).  or  You attempt to derail train X, but train Y is derailed instead (and chance for X is lost).  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)
 * 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

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.

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.

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
Not fully expanded here - but 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).

Task groups (aka "Objects with inheritance" for programmers)
Common tasks and related tasks can be group by task templates. A task group or template is a simple a common parent task object which applies to muliple specific subclasses (which would typically be made more complex). In fact the first "perception" case can be trivially generalized to any "binary" skill outputs with difficulty modifier.

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

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)