Task System
From LSWiki
(Difference between revisions)
| Revision as of 01:41, 21 May 2008 (edit) Msb (Talk | contribs) ← Previous diff |
Revision as of 13:03, 21 May 2008 (edit) Matts (Talk | contribs) (→Task Descriptor - Refining descriptor content) Next diff → |
||
| Line 19: | Line 19: | ||
| ** 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. | ** 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' | + | ** Datatype: int |
| - | *** /lib/task_types.h and /def/task_types encompasses this. Ideally the definitions for each type will define a lot of the functionality. | + | ** Types defined in /lib/task_types.h |
| - | ** Task_Name | + | ** See: [[Task System#Task Types]] |
| - | *** A semi-unique name for the task at hand, ie 'aildrek's rat Problem' | + | * Task_Name |
| - | ** Task_Description | + | ** Datatype: string |
| - | *** A verbose explanation of the task, ie 'aildrek at the lost lamb tavern is known to have an on-going rat problem.' | + | ** Description |
| - | ** Task_Status | + | * Task_Description |
| - | ** Task_Roles | + | ** A verbose explanation of the task, ie 'aildrek at the lost lamb tavern is known to have an on-going rat problem.' |
| - | *** 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. | + | * Task_Status |
| - | *** I'll ponder over _Roles under task types below a bit more. | + | * Task_Roles |
| - | **** After doing a few task types it's easy to see that at least semantically that the 'target' role will change easily. Should this field be an infostore instead? I think you noted that actually Chaos. What each type of task expects to find set in this infostore would be defined in the task_type definition. | + | ** 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. |
| - | ** Task_Objectives | + | ** I'll ponder over _Roles under task types below a bit more. |
| - | *** Ideally this would fill out the objectives of the task, ie '30 rats' | + | *** After doing a few task types it's easy to see that at least semantically that the 'target' role will change easily. Should this field be an infostore instead? I think you noted that actually Chaos. What each type of task expects to find set in this infostore would be defined in the task_type definition. |
| - | ** Task_Count? | + | * Task_Objectives |
| - | *** Number of X to achieve (X rats, X types of rings)? | + | ** Ideally this would fill out the objectives of the task, ie '30 rats' |
| - | ** Task_Info | + | * Task_Count? |
| - | *** Task general-purpose infostore | + | ** Number of X to achieve (X rats, X types of rings)? |
| - | ** Task_Flags | + | * Task_Info |
| - | *** Bitwise flags (see below) | + | ** Task general-purpose infostore |
| - | ** Task_Unique_Tag | + | * Task_Flags |
| - | *** System generated tag to uniquely identify this task. | + | ** Bitwise flags (see below) |
| - | * Flags: | + | * Task_Unique_Tag |
| - | ** Task_Flag_Active | + | ** System generated tag to uniquely identify this task. |
| - | * Functions: | + | === Flags === |
| - | ** task_setup? | + | * Task_Flag_Active |
| - | *** this will do basic setup for the descriptor and the Actor for the task type | + | === Functions === |
| - | *** 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_setup? |
| - | ** task_validate | + | ** this will do basic setup for the descriptor and the Actor for the task type |
| - | *** validates the task descriptor against the defined 'win' conditions, returns true or false | + | ** 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_complete | + | * task_validate |
| - | *** completes the task, awarding any rewards and setting the task to completed | + | ** 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 Type ==== | ==== Task Type ==== | ||
Revision as of 13:03, 21 May 2008
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 |
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
- Datatype: int
- Types defined in /lib/task_types.h
- See: Task System#Task Types
- Task_Name
- Datatype: string
- Description
- Task_Description
- A verbose explanation of the task, ie 'aildrek at the lost lamb tavern is known to have an on-going rat problem.'
- Task_Status
- Task_Roles
- 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.
- I'll ponder over _Roles under task types below a bit more.
- After doing a few task types it's easy to see that at least semantically that the 'target' role will change easily. Should this field be an infostore instead? I think you noted that actually Chaos. What each type of task expects to find set in this infostore would be defined in the task_type definition.
- Task_Objectives
- Ideally this would fill out the objectives of the task, ie '30 rats'
- Task_Count?
- Number of X to achieve (X rats, X types of rings)?
- Task_Info
- Task general-purpose infostore
- Task_Flags
- Bitwise flags (see below)
- Task_Unique_Tag
- System generated tag to uniquely identify this task.
Flags
- Task_Flag_Active
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 Type
- Courier
- Originator gives object/information to Actor who must deliver it to Objective.
- Roles:
- Originator
- Actor (courier?)
- Deliveree?
- Knowledge
- Originator dictates X pieces of Objective knowledge Actor must become familiar with/memorize.
- Originator
- Actor
- Originator dictates X pieces of Objective knowledge Actor must become familiar with/memorize.
- Exploration
- Originator dictates location Objective that Actor must become familiar with/memorize.
- Originator
- Actor
- Originator dictates location Objective that Actor must become familiar with/memorize.
- Elimination
- Originator dictates Objective target that Actor must kill.
- Originator
- Actor
- Target
- Originator dictates Objective target that Actor must kill.
- Collection
- Originator dictates X Objective items that Actor must gather.
- Escort
- Originator dictates Actor must escort Objective to destination.
- Originator
- Actor
- Escorted
- Originator dictates Actor must escort Objective to destination.
(suggestions by twi -- dunno if some of these are too uwieldy for the system being envisioned)
- 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.
[removed suggestions by iggy; see discussion. --twi]
