From LSWiki

Revision as of 17:33, 20 May 2008 (edit) Bladestorm (Talk | contribs) ← Previous diff		Current revision (06:48, 30 October 2008) (edit) Arafelis (Talk | contribs) (→Significance)
Line 1:		Line 1:
-	I like the new task types you added Twilight. That really broadens the reach of the tasks, which isn't a bad thing. In that kind of scope the current quests we have could all be encapsulated this way. What would be possibly difficult is finding a standard way to represent this data in the descriptor.<br> [[User:Matts|Erebus]] 14:43, 20 May 2008 (EDT)	+	=Type suggestions=
		+	I like the new task types you added Twilight. That really broadens the reach of the tasks, which isn't a bad thing. In that kind of scope the current quests we have could all be encapsulated this way. What would be possibly difficult is finding a standard way to represent this data in the descriptor.
		+
		+	[[User:Matts|Erebus]] 14:43, 20 May 2008 (EDT)
	What about adding the following tasks?		What about adding the following tasks?
Line 27:		Line 30:
	**The Originator assigns the Actor to infiltrate a specific Objective target location or group		**The Originator assigns the Actor to infiltrate a specific Objective target location or group
	--[[User:Bladestorm|Bladestorm]] 18:33, 20 May 2008 (EDT)		--[[User:Bladestorm|Bladestorm]] 18:33, 20 May 2008 (EDT)
		+
		+	:Most of these are subsumed under the existing tasks. E.g. the example given for eliminate is to kill 30 rats (genocide). Contain == my Guard. Steal == Collect. Research/Investigate == Collect and/or Knowledge. Infiltrate == Befriend, probably.
		+
		+	:Instigate is good. Track could be good as well. [[User:Msb|Msb]] 21:13, 20 May 2008 (EDT)
		+
		+
		+	:It seems people might be too focused on tasks surrounding traditional hack and slash mechanics. This system would be a good time to implement more purpose to some of the lesser used crafting mechanisms. How about task types like "Build" involving subtypes of Learning as well as material acqusition, then being asked to take his new found masonry and smithing skills and repairing the west gate of Losthaven? Doing a few (or all) of the defined task types above are good, but it's a great opportunity to branch out into new areas. [[User:Nirnaeth|Nirnaeth]] 22:37, 29 October 2008 (EDT)
		+
		+	:: Task Type Knowledge + Task Type Alter would satisfy that structure. [[User:Arafelis|Arafelis]] 07:44, 30 October 2008 (EDT)
		+
		+	=Levels of abstraction=
		+	I think people are a little confused about the structure of a system like this. The point isn't to specify every sort of variation on a theme, it's to give very broad task types within which more specific task types/variations can be implemented. So if you have a mission to escort someone, very commonly ofc. it's going to be ambushed, and you have to protect the target. That stuff comes in defining/setting up the particular task, not the task type, which is just generally to escort. (If eliminating someone specific on the way really was a necessary part of the task, then it would be escort + elimination).
		+
		+	You can think about it in terms of reduction. If a task reduces to one or more tasks on the list, then it's not a real task type. E.g. befriend can't be cashed out in terms of the other existing types, so it needs a new type. But revenge clearly reduces to elimination or some more general task yet to be defined (say, curse). [[User:Msb|Msb]] 01:46, 21 May 2008 (EDT)
		+
		+	:It's possible that, to get the right mix of levels of abstraction, we may need to two-tier the task types. (Either "task class" -> "task type" or "task type" -> "task template", probably.) The higher-abstraction level would be the concepts like Escort, and the lower-abstraction level would be version of those, like Escort Without Incident, Escort With Ambush, Escort With Multiple Ambushes, and so on. The reason to split them like that is that different levels of abstraction have benefits for different kinds of maintainability. High abstraction has the benefit of being able to change a lot of related behaviors in one place. Low abstraction has the benefit of not having to worry about a bunch of related behaviors when managing the one you're concerned with. The idea being pursued with the split would be things like the base reward value of Escort tasks in general being manageable from /def/task_type/escort.c, while /def/task_template/escort_with_multiple_ambushes.c would have only its own plot structure, rather than having to code /def/task_type/escort.c to handle many different plot structures. &mdash;[[User:Chaos|Chaos]] 21:06, 21 May 2008 (EDT)
		+
		+	=Nomenclature=
		+	This is somewhat nitpicky, but eventually I think it will get confusing if the task types aren't either all process nouns or all verbs.
		+
		+	If we prefer verbs, the following work:
		+
		+	courier -> dispatch
		+
		+	knowledge -> learn
		+
		+	all the -ions -> their verb forms (explore, eliminate, etc.)
		+
		+	For all nouns:
		+
		+	escort -> escorting?
		+
		+	heal -> healing
		+
		+	befriend -> ingratiation
		+
		+	recruit -> recruitment, or enlistment
		+
		+	arbitrate -> arbitration
		+
		+	ally -> treaty negotiation (? -- alliance is the product, not the process of allying)
		+
		+	convert -> conversion
		+
		+	protect -> protection
		+
		+	guard -> vigil (? -- standing guard?)
		+
		+	alter -> alteration
		+
		+	destroy -> destruction
		+
		+	[[User:Msb|Msb]]
		+
		+	:I agree with picking a part of speech and sticking to it. I favor verbs because it's easier to algorithmically convert them to their gerunds than it is to do the reverse operation. &mdash;[[User:Chaos|Chaos]] 20:32, 21 May 2008 (EDT)
		+
		+	=Repeatability=
		+
		+	The closest example of tasks presently being quests don't leave any room for repeatability. It seems there should be some sort of task log system, similar to the kill log (ultimately to me, kills should become a task, and be a sub-log of the more global task log), which tracks diminishing returns of completed tasks. [[User:Nirnaeth|Nirnaeth]] 22:37, 29 October 2008 (EDT)
		+
		+	=Significance=
		+
		+	The rewards for tasks should probably have a standard scaling mechanism based upon the significance of the task. [[User:Nirnaeth|Nirnaeth]] 22:37, 29 October 2008 (EDT)
		+
		+	: Evaluating task significance is one of the outstanding issues here. The selection mechanism might do adequately with sufficient parameters, but the haziness of any automatic metric correctly evaluating eg Special_Attacks (or even worse, external capabilities, like guild powers or wild talents) in the context of the autonomon's skill levels has been a pretty constant stumbling block. [[User:Arafelis|Arafelis]] 07:48, 30 October 2008 (EDT)
		+
		+	=Linking=
		+
		+	An interesting concept would be linking tasks to satisfy a meta-task. This could be used in such situations as lifecycles of civilizations. A civilization starts out in a bare structure of existence, and a large number of tasks exist to elevate that civilzation to levels. Taking that further would allow for controlled/task oriented introduction of new content to the world, and then allow for a structured task list which could complete the lifecycle to remove it. Multiple people could complete individual tasks, all linked to the single meta-task, upon completion providing a completion event of some sort that links back to all contributors of sub-tasks. [[User:Nirnaeth|Nirnaeth]] 00:14, 30 October 2008 (EDT)

---

Current revision

Contents 1 Type suggestions 2 Levels of abstraction 3 Nomenclature 4 Repeatability 5 Significance 6 Linking

Type suggestions

I like the new task types you added Twilight. That really broadens the reach of the tasks, which isn't a bad thing. In that kind of scope the current quests we have could all be encapsulated this way. What would be possibly difficult is finding a standard way to represent this data in the descriptor.

Erebus 14:43, 20 May 2008 (EDT)

What about adding the following tasks?

• Genocide/Eradicate
  • Originator dictates an entire region of Objective targets which the Actor must kill/destroy ALL of. Task is not complete until all have been destroyed.

• Follow/Shadow/Track
  • Originator dictates a particular Objective target that the Actor must follow for a certain period of time. Can be used to report activities performed by the Objective, where the Objective ended his trail (his lair, his secret hiding place), or as an initial task in association with a secondary task (e.g. Destroy, Steal, Eliminate, Contain)

• Contain
  • Originator dictates a potentially dangerous Objective target that the Actor must locate and somehow ensure that the Objective does not escape from a given area (make sure the orcs don't get through this pass, make sure the dragon does not escape from his cave, make sure the prisoners do not leave the confines of the jail, seal the extradimensional gate to make sure the Hellspawn do not enter the mortal realm).

• Investigate
  • The Originator assigns to Actor to figure out the unknown Objective target that has commited a crime (collect clue to figure out who the murderer is, track down a jewel thief, figure out the secret of the pzyruxial sphere, figure out which flaggon has the poison in it)

• Steal
  • The Originator tells the Actor what Objective target to bring back by means of stealth and subterfuge.

• Research
  • The Originator has a certain Objective target that he is trying to learn about, and it requires research far beyond the scope of the Originator's resources. The Actor is asked to assist in the research effort. (E.g. The old mage has a spell component that is written to only be found in the Necropolis on the other side of the planet in Esartur. Travel there is nigh impossible for an elderly man, so the player is request to make that journey for him. Once there, further research must be done in the personal library of the Lich King to find out where this component can actually be found. The only reference is obscure and requires translation services provided in Devonshire. Translating the text reveals that the plant is extinct, but there is a master herbalist who may know an animistic spell to bring the extinct plant back to life if he has the proper components.

• Instigate
  • The direct opposite of Arbitrate and Ally, the Originator dictates a relationship between two Objective targets that the Actor must degrade or destroy.

• Infiltrate
  • The Originator assigns the Actor to infiltrate a specific Objective target location or group

--Bladestorm 18:33, 20 May 2008 (EDT)

Most of these are subsumed under the existing tasks. E.g. the example given for eliminate is to kill 30 rats (genocide). Contain == my Guard. Steal == Collect. Research/Investigate == Collect and/or Knowledge. Infiltrate == Befriend, probably.

Instigate is good. Track could be good as well. Msb 21:13, 20 May 2008 (EDT)

It seems people might be too focused on tasks surrounding traditional hack and slash mechanics. This system would be a good time to implement more purpose to some of the lesser used crafting mechanisms. How about task types like "Build" involving subtypes of Learning as well as material acqusition, then being asked to take his new found masonry and smithing skills and repairing the west gate of Losthaven? Doing a few (or all) of the defined task types above are good, but it's a great opportunity to branch out into new areas. Nirnaeth 22:37, 29 October 2008 (EDT)

Task Type Knowledge + Task Type Alter would satisfy that structure. Arafelis 07:44, 30 October 2008 (EDT)

Levels of abstraction

I think people are a little confused about the structure of a system like this. The point isn't to specify every sort of variation on a theme, it's to give very broad task types within which more specific task types/variations can be implemented. So if you have a mission to escort someone, very commonly ofc. it's going to be ambushed, and you have to protect the target. That stuff comes in defining/setting up the particular task, not the task type, which is just generally to escort. (If eliminating someone specific on the way really was a necessary part of the task, then it would be escort + elimination).

You can think about it in terms of reduction. If a task reduces to one or more tasks on the list, then it's not a real task type. E.g. befriend can't be cashed out in terms of the other existing types, so it needs a new type. But revenge clearly reduces to elimination or some more general task yet to be defined (say, curse). Msb 01:46, 21 May 2008 (EDT)

It's possible that, to get the right mix of levels of abstraction, we may need to two-tier the task types. (Either "task class" -> "task type" or "task type" -> "task template", probably.) The higher-abstraction level would be the concepts like Escort, and the lower-abstraction level would be version of those, like Escort Without Incident, Escort With Ambush, Escort With Multiple Ambushes, and so on. The reason to split them like that is that different levels of abstraction have benefits for different kinds of maintainability. High abstraction has the benefit of being able to change a lot of related behaviors in one place. Low abstraction has the benefit of not having to worry about a bunch of related behaviors when managing the one you're concerned with. The idea being pursued with the split would be things like the base reward value of Escort tasks in general being manageable from /def/task_type/escort.c, while /def/task_template/escort_with_multiple_ambushes.c would have only its own plot structure, rather than having to code /def/task_type/escort.c to handle many different plot structures. —Chaos 21:06, 21 May 2008 (EDT)

Nomenclature

This is somewhat nitpicky, but eventually I think it will get confusing if the task types aren't either all process nouns or all verbs.

If we prefer verbs, the following work:

courier -> dispatch

knowledge -> learn

all the -ions -> their verb forms (explore, eliminate, etc.)

For all nouns:

escort -> escorting?

heal -> healing

befriend -> ingratiation

recruit -> recruitment, or enlistment

arbitrate -> arbitration

ally -> treaty negotiation (? -- alliance is the product, not the process of allying)

convert -> conversion

protect -> protection

guard -> vigil (? -- standing guard?)

alter -> alteration

destroy -> destruction

Msb

I agree with picking a part of speech and sticking to it. I favor verbs because it's easier to algorithmically convert them to their gerunds than it is to do the reverse operation. —Chaos 20:32, 21 May 2008 (EDT)

Repeatability

The closest example of tasks presently being quests don't leave any room for repeatability. It seems there should be some sort of task log system, similar to the kill log (ultimately to me, kills should become a task, and be a sub-log of the more global task log), which tracks diminishing returns of completed tasks. Nirnaeth 22:37, 29 October 2008 (EDT)

Significance

The rewards for tasks should probably have a standard scaling mechanism based upon the significance of the task. Nirnaeth 22:37, 29 October 2008 (EDT)

Evaluating task significance is one of the outstanding issues here. The selection mechanism might do adequately with sufficient parameters, but the haziness of any automatic metric correctly evaluating eg Special_Attacks (or even worse, external capabilities, like guild powers or wild talents) in the context of the autonomon's skill levels has been a pretty constant stumbling block. Arafelis 07:48, 30 October 2008 (EDT)

Linking

An interesting concept would be linking tasks to satisfy a meta-task. This could be used in such situations as lifecycles of civilizations. A civilization starts out in a bare structure of existence, and a large number of tasks exist to elevate that civilzation to levels. Taking that further would allow for controlled/task oriented introduction of new content to the world, and then allow for a structured task list which could complete the lifecycle to remove it. Multiple people could complete individual tasks, all linked to the single meta-task, upon completion providing a completion event of some sort that links back to all contributors of sub-tasks. Nirnaeth 00:14, 30 October 2008 (EDT)