Talk:Task System
From LSWiki
Revision as of 20:06, 21 May 2008 (edit) Chaos (Talk | contribs) ← Previous diff |
Revision as of 20:07, 21 May 2008 (edit) Chaos (Talk | contribs) Next diff → |
||
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 30: | Line 32: | ||
: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. | :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) | + | :Instigate is good. Track could be good as well. [[User:Msb|Msb]] 21:13, 20 May 2008 (EDT) |
- | :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). | + | =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) | 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. —[[User:Chaos|Chaos]] 21:06, 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. —[[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. | 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. | ||
Revision as of 20:07, 21 May 2008
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)
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)