Talk:Task System - Revision history

Arafelis: /* Significance */

Arafelis — Thu, 30 Oct 2008 11:48:19 GMT

Significance

←Older revision		Revision as of 11:48, 30 October 2008
Line 93:		Line 93:

	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)		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=		=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)		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)

Arafelis: /* Type suggestions */

Arafelis — Thu, 30 Oct 2008 11:44:01 GMT

Type suggestions

←Older revision		Revision as of 11:44, 30 October 2008
Line 38:		Line 38:
	: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)		: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=		=Levels of abstraction=

Nirnaeth: /* Linking */

Nirnaeth — Thu, 30 Oct 2008 04:14:36 GMT

Linking

←Older revision		Revision as of 04:14, 30 October 2008
Line 95:		Line 95:
	=Linking=		=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.	+	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)

Nirnaeth at 04:14, 30 October 2008

Nirnaeth — Thu, 30 Oct 2008 04:14:27 GMT

←Older revision		Revision as of 04:14, 30 October 2008
Line 92:		Line 92:

	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)		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)
		+
		+	=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 at 02:37, 30 October 2008

Nirnaeth — Thu, 30 Oct 2008 02:37:02 GMT

←Older revision		Revision as of 02:37, 30 October 2008
Line 34:		Line 34:

	: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)
		+
		+
		+	: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)
		+

	=Levels of abstraction=		=Levels of abstraction=
Line 80:		Line 84:

	: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. —[[User:Chaos\|Chaos]] 20:32, 21 May 2008 (EDT)		: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. —[[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)

Chaos at 01:08, 22 May 2008

Chaos — Thu, 22 May 2008 01:08:39 GMT

←Older revision		Revision as of 01:08, 22 May 2008
Line 1:		Line 1:
	=Type suggestions=		=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.		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)		[[User:Matts\|Erebus]] 14:43, 20 May 2008 (EDT)

Line 47:		Line 48:

	courier -> dispatch		courier -> dispatch
		+
	knowledge -> learn		knowledge -> learn
		+
	all the -ions -> their verb forms (explore, eliminate, etc.)		all the -ions -> their verb forms (explore, eliminate, etc.)

Line 53:		Line 56:

	escort -> escorting?		escort -> escorting?
		+
	heal -> healing		heal -> healing
		+
	befriend -> ingratiation		befriend -> ingratiation
		+
	recruit -> recruitment, or enlistment		recruit -> recruitment, or enlistment
		+
	arbitrate -> arbitration		arbitrate -> arbitration
		+
	ally -> treaty negotiation (? -- alliance is the product, not the process of allying)		ally -> treaty negotiation (? -- alliance is the product, not the process of allying)
		+
	convert -> conversion		convert -> conversion
		+
	protect -> protection		protect -> protection
		+
	guard -> vigil (? -- standing guard?)		guard -> vigil (? -- standing guard?)
		+
	alter -> alteration		alter -> alteration
		+
	destroy -> destruction		destroy -> destruction
		+
	[[User:Msb\|Msb]]		[[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. —[[User:Chaos\|Chaos]] 20:32, 21 May 2008 (EDT)		: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. —[[User:Chaos\|Chaos]] 20:32, 21 May 2008 (EDT)

Chaos at 01:07, 22 May 2008

Chaos — Thu, 22 May 2008 01:07:02 GMT

←Older revision		Revision as of 01:07, 22 May 2008
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.

Chaos at 01:06, 22 May 2008

Chaos — Thu, 22 May 2008 01:06:00 GMT

←Older revision		Revision as of 01:06, 22 May 2008
Line 28:		Line 28:
	--[[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.	+	: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).	+	: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)

	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.

Chaos at 00:58, 22 May 2008

Chaos — Thu, 22 May 2008 00:58:24 GMT

←Older revision		Revision as of 00:58, 22 May 2008
Line 59:		Line 59:
	[[User:Msb\|Msb]]		[[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. —[[User:Chaos\|Chaos]] 20:32, 21 May 2008 (EDT)	+	: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. —[[User:Chaos\|Chaos]] 20:32, 21 May 2008 (EDT)

Chaos at 00:32, 22 May 2008

Chaos — Thu, 22 May 2008 00:32:18 GMT

←Older revision		Revision as of 00:32, 22 May 2008
Line 57:		Line 57:
	alter -> alteration		alter -> alteration
	destroy -> destruction		destroy -> destruction
-	[[User:Msb\|Msb]] 20:18, 21 May 2008 (EDT)	+	[[User:Msb\|Msb]]

-	..default wiki formatting sucks [[User:Msb\|Msb]] 20:19, 21 May 2008 (EDT)	+	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. —[[User:Chaos\|Chaos]] 20:32, 21 May 2008 (EDT)