Task System

From LSWiki

Revision as of 13:49, 20 May 2008 (edit) Matts (Talk | contribs) (→Task Type - Expanded on Task Type Roles) ← Previous diff		Current revision (21:45, 7 September 2008) (edit) Arafelis (Talk | contribs) (dev cat added.)
Line 1:		Line 1:
	This page is for the developers to discuss, debate, and collaborate on the in-process dynamic task system. To start I'll outline the various sections that I think we will need to interact with and then list the expected interactions there of.		This page is for the developers to discuss, debate, and collaborate on the in-process dynamic task system. To start I'll outline the various sections that I think we will need to interact with and then list the expected interactions there of.
-	==== Incarnos ====	+	== Incarnos ==
	* ability to store gathered tasks		* ability to store gathered tasks
	* ability to show and retrieve information on stored tasks via show?		* ability to show and retrieve information on stored tasks via show?
-	==== Autonomon ====	+	== Autonomon ==
	* This section will all likely be encompassed by an extension attachable to a living. Incarnoi could possibly inherit this functionality?		* This section will all likely be encompassed by an extension attachable to a living. Incarnoi could possibly inherit this functionality?
	* ability to know it's a task granter		* ability to know it's a task granter
Line 14:		Line 14:
	* ability to complete and reward an incarnoi who completes a relevant task		* ability to complete and reward an incarnoi who completes a relevant task
-	==== Task Daemon ====	+	== Task Daemon ==
	* broker for task type definitions		* broker for task type definitions
	* stores all tasks? ever? (database interaction?) at minimum, provides ability to specify an incarnos/autonomon/unique-tag and find out what active tasks in the MUD it is involved with and what roles it has in them		* stores all tasks? ever? (database interaction?) at minimum, provides ability to specify an incarnos/autonomon/unique-tag and find out what active tasks in the MUD it is involved with and what roles it has in them
		+	** should tasks that are defined at an individual level for say Losthaven be kept track of by a centralized daemon or a project specific daemon? Are there any physical limitations to holding a potentially large subset of tasks in a central place like that? interlacing it with the SQL would be interesting, I'd like to see the available tasks able to be thrown up on the webpage dynamically.
-	==== Task Descriptor ====	+	== Task Descriptor ==
-	* Fields:	+	=== Fields ===
-	** Task_Type_Code	+	==== Task_Type_Code ====
-	*** Specifies the defined type of task, ie 'Task_Type_Elimination'	+	* '''Data type''': int
-	*** /lib/task_types.h and /def/task_types encompasses this. Ideally the definitions for each type will define a lot of the functionality.	+	* '''Description''': Identifies the task's type which defines default beavhior.
-	** Task_Name	+	* '''Defined by''': /lib/task_types.h, /def/task_type/*
-	*** A semi-unique name for the task at hand, ie 'aildrek's rat Problem'	+	* '''Example''': Task_Type_Elimination
-	** Task_Description	+	* '''See''': [[Task System#Task Types]]
-	*** A verbose explanation of the task, ie 'aildrek at the lost lamb tavern is known to have an on-going rat problem.'	+	==== Task_Name ====
-	** Task_Status	+	* '''Data type''': string
-	** Task_Roles	+	* '''Description''': A basic short title for the task.
-	*** This encompasses the various roles which are variable to the task types. For example for Elimination we may need Originator, whom gives the task, Actor whom receieves the task, and Target, the rats. With this in mind Task_Objectives may need to be eliminated as too general and we may need Task_Count or some other designator of quantity.	+	* '''Example''': "Aildrek's Rat Problem"
-	*** I'll ponder over _Roles under task types below a bit more.	+	==== Task_Description ====
-	** Task_Objectives	+	* '''Data type''': string
-	*** Ideally this would fill out the objectives of the task, ie '30 rats'	+	* '''Description''': A verbose description of what the task entails.
-	** Task_Info	+	* '''Example''': "Aildrek's tavern, the Lost Lamb, has an ongoing rat problem that needs dealing with."
-	*** Task general-purpose infostore	+	==== Task_Status ====
-	** Task_Flags	+	* '''Data type''': enumerated integer: Task_Status_Unassigned, Task_Status_Assigned, Task_Status_Completed, or Task_Status_Failed
-	*** Bitwise flags (see below)	+	* '''Description''': The general, system-level status of the task.
-	** Task_Unique_Tag	+	* '''Example''': per data type
-	*** System generated tag to uniquely identify this task.	+	==== Task_Stage ====
-	* Flags:	+	* '''Data type''': string
-	** Task_Flag_Active	+	* '''Description''': One of the set of stage strings defined by the task type. These stages are "active" only while the Task_Status is Task_Status_Assigned. Outside of that status, the most they indicate is the stage the task was in when it left Task_Status_Assigned. The task may be considered as a finite state machine that moves between these stages according to the plot defined in the type definition's code.
-	* Functions:	+	* '''Example''': "assigned", "begun", "stage_1", "stage_2"
-	** Placeholder	+
-	==== Task Type ====	+	==== Task_Parts ====
-	* Courier	+	* '''Data type''': descriptor array
-	** Originator gives object/information to Actor who must deliver it to Objective.	+	* '''Description''': May optionally contain one or more tasks which are associated with the parent task, creating tasks with prerequisites or optional components.
-	** Roles:	+	* '''Example''': array of task descriptors
-	*** Originator	+	==== Task_Roles ====
-	*** Actor (courier?)	+	* '''Data type''': mapping
-	*** Deliveree?	+	* '''Description''': An infostore field that will hold the varying roles unique to each task type.
-	* Knowledge	+	* '''Example''': ([ "actor" : "/usr/erebus", "originator" : "/d/Almeria/Losthaven/npc/aildrek", "target" : "/d/Almeria/Losthaven/Sewers/mon/rat" ])
-	** Originator dictates X pieces of Objective knowledge Actor must become familiar with/memorize.	+	* '''See''': [[Task System#Task Types]]
-	*** Originator	+	==== Task_Objectives ====
-	*** Actor	+	* '''Data type''': ?? (does this need to be a separate descriptor type possibly?)
-	* Exploration	+	* '''Description''': This would ideally describe the objective of the task in some meaningful way.
-	** Originator dictates location Objective that Actor must become familiar with/memorize.	+	* '''Example''': ([ "/d/Almeria/Losthaven/Sewers/mon/rat" : 30 ])
-	*** Originator	+	==== Task_Info ====
-	*** Actor	+	* '''Data type''': variable
-	* Elimination	+	* '''Description''': A general purpose infostore for the descriptor.
-	** Originator dictates Objective target that Actor must kill.	+	==== Task_Flags ====
-	*** Originator	+	* '''Data type''': bitmask
-	*** Actor	+	* '''Description''': This field holds the various bitmask flags for the descriptor.
-	*** Target	+	* '''Example''': Task_Flag_Necessary
-	* Collection	+	* '''See''': [[Task System#Flags]]
		+
		+	==== Task_Unique_Tag ====
		+	* '''Data type''': string
		+	* '''Description''': A system generated unique string tag for this task.
		+	* '''Example''': "-1159877561", "/usr/foo"
		+
		+	=== Flags ===
		+	==== Task_Flag_Necessary ====
		+	* '''Meaning''': When considering a given task and its Task_Parts, designates this task as one which must be completed in order for the parent task to be considered completed. The parent task itself need not have this flag. A task with no Task_Parts is implicitly necessary without having this flag on.
		+	==== Task_Flag_Sufficient ====
		+	* '''Meaning''': When considering a given task and its Task_Parts, designates this task as one which suffices, by itself, for the parent task to be considered completed. To be considered completed, therefore, the set of tasks must have all tasks with Task_Flag_Necessary completed, and either at least one with Task_Flag_Sufficient completed, or the entire set.
		+	=== Functions ===
		+	* task_setup?
		+	** this will do basic setup for the descriptor and the Actor for the task type
		+	** for example with the elimination type above it could setup an At_Kill hook on the Actor that would check for its target against the killed, and if found flip the task to completed
		+	* task_validate
		+	** validates the task descriptor against the defined 'win' conditions, returns true or false
		+	* task_complete
		+	** completes the task, awarding any rewards and setting the task to completed
		+
		+	== Task Types ==
		+	=== Deliver ===
		+	* '''Description''': Actor must deliver a package from Originator to Target
		+	* '''Roles''':
		+	** Originator
		+	** Actor
		+	** Target
		+	=== Learn ===
		+	* '''Description''': Actor must become familiar with and/or memorize the topics decreed by Originator
		+	* '''Roles''':
		+	** Originator
		+	** Actor
		+	=== Explore ===
		+	* '''Description''': Actor must become familiar with and/or memorize a specific location.
		+	* '''Roles''':
		+	** Originator
		+	** Actor
		+	* '''Notes''': This may actually be a subset of Knowledge, do we want to split them like this for clarity of purpose?
		+	=== Eliminate ===
		+	* '''Description''': Actor must kill Target dictated by Originiator
		+	* '''Roles''':
		+	** Originator
		+	** Actor
		+	** Target
		+	=== Collect ===
	** Originator dictates X Objective items that Actor must gather.		** Originator dictates X Objective items that Actor must gather.
-	* Escort	+	=== Escort ===
	** Originator dictates Actor must escort Objective to destination.		** Originator dictates Actor must escort Objective to destination.
	*** Originator		*** Originator
	*** Actor		*** Actor
	*** Escorted		*** Escorted
-	(suggestions by twi -- dunno if some of these are too uwieldy for the system being envisioned)	+	=== Heal ===
-	* Heal	+
	** Originator dictates Objective target with an injury, malady, or curse that Actor must remedy.		** Originator dictates Objective target with an injury, malady, or curse that Actor must remedy.
-	* Befriend	+	=== Befriend ===
	** Originator dictates Objective target of whom Actor must acquire friendship (befriended status).		** Originator dictates Objective target of whom Actor must acquire friendship (befriended status).
-	* Recruit	+	=== Recruit ===
	** Originator dictates Objective target of whom Actor must acquire "ownership" (command).		** Originator dictates Objective target of whom Actor must acquire "ownership" (command).
-	* Arbitrate	+	=== Arbitrate ===
	** Originator dictates two or more Objective targets for whom Actor must forge a friendship between (reciprocal befriended status)		** Originator dictates two or more Objective targets for whom Actor must forge a friendship between (reciprocal befriended status)
-	* Ally	+	=== Ally ===
	** Originator dictates two or more Objective targets for whom Actor must forge a command relation between.		** Originator dictates two or more Objective targets for whom Actor must forge a command relation between.
-	* Convert	+	=== Convert ===
	** Originator dictates Objective target that Actor must convince/force to change worships.		** Originator dictates Objective target that Actor must convince/force to change worships.
-	* Protect	+	=== Protect ===
	** Originator dictates Objective target(s) that the Actor must protector from harm for some delimited amount of time [with the amount of injury that can be sustained and the proportion of the targets that must survive being variables].		** Originator dictates Objective target(s) that the Actor must protector from harm for some delimited amount of time [with the amount of injury that can be sustained and the proportion of the targets that must survive being variables].
-	* Guard	+	=== Guard ===
	** Originator dictates Objective target item(s) that must be kept in a location for some delimited amount of time.		** Originator dictates Objective target item(s) that must be kept in a location for some delimited amount of time.
-	* Alter	+	=== Alter ===
	** Originator dictates Objective target item(s) that must be altered in some way -- cursed, uncursed, enchanted, disenchanted, sharpened, repaired.		** Originator dictates Objective target item(s) that must be altered in some way -- cursed, uncursed, enchanted, disenchanted, sharpened, repaired.
-	* Destroy	+	=== Destroy ===
	** Originator dictates Objective target item(s) that must be destroyed.		** Originator dictates Objective target item(s) that must be destroyed.
		+	=== Dissention ===
		+	** Orginiator dictates Actor must cause strife between targets Objective. Polar opposite of Ally.
		+
		+
		+	[[Category: Development]]

---

Current revision

This page is for the developers to discuss, debate, and collaborate on the in-process dynamic task system. To start I'll outline the various sections that I think we will need to interact with and then list the expected interactions there of.

Contents 1 Incarnos 2 Autonomon 3 Task Daemon 4 Task Descriptor 4.1 Fields 4.1.1 Task_Type_Code 4.1.2 Task_Name 4.1.3 Task_Description 4.1.4 Task_Status 4.1.5 Task_Stage 4.1.6 Task_Parts 4.1.7 Task_Roles 4.1.8 Task_Objectives 4.1.9 Task_Info 4.1.10 Task_Flags 4.1.11 Task_Unique_Tag 4.2 Flags 4.2.1 Task_Flag_Necessary 4.2.2 Task_Flag_Sufficient 4.3 Functions 5 Task Types 5.1 Deliver 5.2 Learn 5.3 Explore 5.4 Eliminate 5.5 Collect 5.6 Escort 5.7 Heal 5.8 Befriend 5.9 Recruit 5.10 Arbitrate 5.11 Ally 5.12 Convert 5.13 Protect 5.14 Guard 5.15 Alter 5.16 Destroy 5.17 Dissention

Incarnos

• ability to store gathered tasks
• ability to show and retrieve information on stored tasks via show?

Autonomon

• This section will all likely be encompassed by an extension attachable to a living. Incarnoi could possibly inherit this functionality?
• ability to know it's a task granter
• ability to poll for available, and suitable, tasks
• ability to respond to queries for available tasks
• ability to describe available tasks to incarnoi
• ability to evaluate progress of an incarnoi's relevant task
• ability to complete and reward an incarnoi who completes a relevant task

Task Daemon

• broker for task type definitions
• stores all tasks? ever? (database interaction?) at minimum, provides ability to specify an incarnos/autonomon/unique-tag and find out what active tasks in the MUD it is involved with and what roles it has in them
  • should tasks that are defined at an individual level for say Losthaven be kept track of by a centralized daemon or a project specific daemon? Are there any physical limitations to holding a potentially large subset of tasks in a central place like that? interlacing it with the SQL would be interesting, I'd like to see the available tasks able to be thrown up on the webpage dynamically.

Task Descriptor

Fields

Task_Type_Code

• Data type: int
• Description: Identifies the task's type which defines default beavhior.
• Defined by: /lib/task_types.h, /def/task_type/*
• Example: Task_Type_Elimination
• See: Task System#Task Types

Task_Name

• Data type: string
• Description: A basic short title for the task.
• Example: "Aildrek's Rat Problem"

Task_Description

• Data type: string
• Description: A verbose description of what the task entails.
• Example: "Aildrek's tavern, the Lost Lamb, has an ongoing rat problem that needs dealing with."

Task_Status

• Data type: enumerated integer: Task_Status_Unassigned, Task_Status_Assigned, Task_Status_Completed, or Task_Status_Failed
• Description: The general, system-level status of the task.
• Example: per data type

Task_Stage

• Data type: string
• Description: One of the set of stage strings defined by the task type. These stages are "active" only while the Task_Status is Task_Status_Assigned. Outside of that status, the most they indicate is the stage the task was in when it left Task_Status_Assigned. The task may be considered as a finite state machine that moves between these stages according to the plot defined in the type definition's code.
• Example: "assigned", "begun", "stage_1", "stage_2"

Task_Parts

• Data type: descriptor array
• Description: May optionally contain one or more tasks which are associated with the parent task, creating tasks with prerequisites or optional components.
• Example: array of task descriptors

Task_Roles

• Data type: mapping
• Description: An infostore field that will hold the varying roles unique to each task type.
• Example: ([ "actor" : "/usr/erebus", "originator" : "/d/Almeria/Losthaven/npc/aildrek", "target" : "/d/Almeria/Losthaven/Sewers/mon/rat" ])
• See: Task System#Task Types

Task_Objectives

• Data type: ?? (does this need to be a separate descriptor type possibly?)
• Description: This would ideally describe the objective of the task in some meaningful way.
• Example: ([ "/d/Almeria/Losthaven/Sewers/mon/rat" : 30 ])

Task_Info

• Data type: variable
• Description: A general purpose infostore for the descriptor.

Task_Flags

• Data type: bitmask
• Description: This field holds the various bitmask flags for the descriptor.
• Example: Task_Flag_Necessary
• See: Task System#Flags

Task_Unique_Tag

• Data type: string
• Description: A system generated unique string tag for this task.
• Example: "-1159877561", "/usr/foo"

Flags

Task_Flag_Necessary

• Meaning: When considering a given task and its Task_Parts, designates this task as one which must be completed in order for the parent task to be considered completed. The parent task itself need not have this flag. A task with no Task_Parts is implicitly necessary without having this flag on.

Task_Flag_Sufficient

• Meaning: When considering a given task and its Task_Parts, designates this task as one which suffices, by itself, for the parent task to be considered completed. To be considered completed, therefore, the set of tasks must have all tasks with Task_Flag_Necessary completed, and either at least one with Task_Flag_Sufficient completed, or the entire set.

Functions

• task_setup?
  • this will do basic setup for the descriptor and the Actor for the task type
  • for example with the elimination type above it could setup an At_Kill hook on the Actor that would check for its target against the killed, and if found flip the task to completed
• task_validate
  • validates the task descriptor against the defined 'win' conditions, returns true or false
• task_complete
  • completes the task, awarding any rewards and setting the task to completed

Task Types

Deliver

• Description: Actor must deliver a package from Originator to Target
• Roles:
  • Originator
  • Actor
  • Target

Learn

• Description: Actor must become familiar with and/or memorize the topics decreed by Originator
• Roles:
  • Originator
  • Actor

Explore

• Description: Actor must become familiar with and/or memorize a specific location.
• Roles:
  • Originator
  • Actor
• Notes: This may actually be a subset of Knowledge, do we want to split them like this for clarity of purpose?

Eliminate

• Description: Actor must kill Target dictated by Originiator
• Roles:
  • Originator
  • Actor
  • Target

Collect

• • Originator dictates X Objective items that Actor must gather.

Escort

• • Originator dictates Actor must escort Objective to destination.
    • Originator
    • Actor
    • Escorted

Heal

• • Originator dictates Objective target with an injury, malady, or curse that Actor must remedy.

Befriend

• • Originator dictates Objective target of whom Actor must acquire friendship (befriended status).

Recruit

• • Originator dictates Objective target of whom Actor must acquire "ownership" (command).

Arbitrate

• • Originator dictates two or more Objective targets for whom Actor must forge a friendship between (reciprocal befriended status)

Ally

• • Originator dictates two or more Objective targets for whom Actor must forge a command relation between.

Convert

• • Originator dictates Objective target that Actor must convince/force to change worships.

Protect

• • Originator dictates Objective target(s) that the Actor must protector from harm for some delimited amount of time [with the amount of injury that can be sustained and the proportion of the targets that must survive being variables].

Guard

• • Originator dictates Objective target item(s) that must be kept in a location for some delimited amount of time.

Alter

• • Originator dictates Objective target item(s) that must be altered in some way -- cursed, uncursed, enchanted, disenchanted, sharpened, repaired.

Destroy

• • Originator dictates Objective target item(s) that must be destroyed.

Dissention

• • Orginiator dictates Actor must cause strife between targets Objective. Polar opposite of Ally.