Zenbitz:Thoughts on task resolution

From Post-Apocalyptic RPG wiki

Jump to: navigation, search

Wip mechanic.png This article covers a work in progress game mechanic.

Work in progress mechanics get currently fleshed out and are not ready for review yet. Once they have been fleshed out in detail and are ready to be reviewed, they become submitted game mechanics.


This page is superseded by: 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.

Contents

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

Notes

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!

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 automatic "total" success. For example, "Move one space over". 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 (such as action points) 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).

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.

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)

Personal tools