AI Framework - Revision history

Greebo: categorised

2008-06-30T07:47:55Z

categorised

← Older revision		Revision as of 07:47, 30 June 2008
Line 145:		Line 145:
	Just checking for NULL pointers via IF and calling RETURN only looks like it was more stable, but in the end you'll have to fire up the debugger in any case to find out why the hell your Task class is not performing.		Just checking for NULL pointers via IF and calling RETURN only looks like it was more stable, but in the end you'll have to fire up the debugger in any case to find out why the hell your Task class is not performing.

	~~[[Category:AI]]~~		{{ai}} {{sdk}}
	~~[[Category:Scripting]]~~
	~~[[Category:Coding]]~~

Greebo: /* Mind */

2008-02-08T19:19:25Z

Mind

← Older revision		Revision as of 19:19, 8 February 2008
Line 53:		Line 53:

	At any rate, the Mind picks exactly one of the four AI Subsystems and calls '''Subsystem::PerformTask()'''. Note that only one of the four subsystems is called each frame, so the calls are interleaved over the frames. The Mind increases its subsystem iterator each frame, disabled Subsystems are skipped. If all four Subsystems are filled with Tasks, each Subsystem gets called every fourth frame - if only one Subsystem is enabled, it gets called each frame.		At any rate, the Mind picks exactly one of the four AI Subsystems and calls '''Subsystem::PerformTask()'''. Note that only one of the four subsystems is called each frame, so the calls are interleaved over the frames. The Mind increases its subsystem iterator each frame, disabled Subsystems are skipped. If all four Subsystems are filled with Tasks, each Subsystem gets called every fourth frame - if only one Subsystem is enabled, it gets called each frame.

	The abstract definition of a Mind is defined in AI/Mind.h, the standard implementation is the '''BasicMind''' class. In principle it's possible to swap an AI's Mind with a different implementation (perhaps a DrunkenMind or something like that). If this concept doesn't work out, one could also remove the intermediate Mind class and replace it with the BasicMind implementation.

	The Mind holds its very own StateQueue, similar to the Subsystem's TaskQueue. States can be pushed/switched and ended. When switching to a new States, the Mind class calls '''State::Init()''' ''once''. This gives the State the opportunity to plug the right Tasks into the Subsystems and do some other one-time setup processing, whatever this might be.		The Mind holds its very own StateQueue, similar to the Subsystem's TaskQueue. States can be pushed/switched and ended. When switching to a new States, the Mind class calls '''State::Init()''' ''once''. This gives the State the opportunity to plug the right Tasks into the Subsystems and do some other one-time setup processing, whatever this might be.

Greebo: /* Mind */

2007-11-08T19:53:27Z

Mind

← Older revision		Revision as of 19:53, 8 November 2007
Line 48:		Line 48:

	== Mind ==		== Mind ==
	Each AI has a Mind, whose purpose is to control the Subsystems. The Mind is always in a certain '''State''' (e.g. Idle, Combat, Searching)~~, which have a distinct priority assigned to them~~.		Each AI has a Mind, whose purpose is to control the Subsystems. The Mind is always in a certain '''State''' (e.g. Idle, Combat, Searching).

	The '''Mind::Think()''' method is called from '''idAI::Think()''', hence it happens each frame. The '''Mind::Think''' method doesn't do much, but passes the call to its currently attached '''State::Think()''' instead, as supposedly most of the thinking is depending on the current State the AI is in.		The '''Mind::Think()''' method is called from '''idAI::Think()''', hence it happens each frame. The '''Mind::Think''' method doesn't do much, but passes the call to its currently attached '''State::Think()''' instead, as supposedly most of the thinking is depending on the current State the AI is in.
Line 56:		Line 56:
	The abstract definition of a Mind is defined in AI/Mind.h, the standard implementation is the '''BasicMind''' class. In principle it's possible to swap an AI's Mind with a different implementation (perhaps a DrunkenMind or something like that). If this concept doesn't work out, one could also remove the intermediate Mind class and replace it with the BasicMind implementation.		The abstract definition of a Mind is defined in AI/Mind.h, the standard implementation is the '''BasicMind''' class. In principle it's possible to swap an AI's Mind with a different implementation (perhaps a DrunkenMind or something like that). If this concept doesn't work out, one could also remove the intermediate Mind class and replace it with the BasicMind implementation.

	The Mind holds its very own StateQueue, similar to the Subsystem's TaskQueue. States can be pushed/switched/ended ~~as well as conditionally pushed/switched, depending on their priority (see interface below)~~. When switching to a new States, the Mind class calls '''State::Init()''' once. This gives the State the opportunity to plug the right Tasks into the Subsystems and do some other one-time setup processing, whatever this might be.		The Mind holds its very own StateQueue, similar to the Subsystem's TaskQueue. States can be pushed/switched and ended. When switching to a new States, the Mind class calls '''State::Init()''' ''once''. This gives the State the opportunity to plug the right Tasks into the Subsystems and do some other one-time setup processing, whatever this might be.

	=== Mind Interface ===		=== Mind Interface ===

Greebo: /* Why so many idAI* owner arguments? */

2007-11-08T19:45:10Z

Why so many idAI* owner arguments?

← Older revision		Revision as of 19:45, 8 November 2007
Line 131:		Line 131:

	== Why so many idAI* owner arguments? ==		== Why so many idAI* owner arguments? ==
	Due to the restriction of raw pointers imposed by the [[Saving and ~~Loading~~]] guidelines, all entity pointers must be stored in idEntityPtr classes. To avoid calling '''_owner.GetEntity()''' all the time (which performs a lookup in the huge gameLocal.entities array), I decided to pass the pointer along the call chain, wherever possible. This is potentially faster than constantly looking up the spawnid in the entities array. Also it makes the use of assertions easier.		Due to the restriction of raw pointers imposed by the [[Saving and Restoring]] guidelines, all entity pointers must be stored in idEntityPtr classes. To avoid calling '''_owner.GetEntity()''' all the time (which performs a lookup in the huge gameLocal.entities array), I decided to pass the pointer along the call chain, wherever possible. This is potentially faster than constantly looking up the spawnid in the entities array. Also it makes the use of assertions easier.

	== Assertions ==		== Assertions ==

Greebo: /* Mind Interface */

2007-11-08T19:44:33Z

Mind Interface

← Older revision		Revision as of 19:44, 8 November 2007
Line 71:		Line 71:
	void SwitchState(StatePtr);		void SwitchState(StatePtr);

	~~// Adds the State to the end of the queue~~
	~~void QueueState(StatePtr);~~

	// Ends the current state (gets destroyed next round) and a new one is picked from the queu		// Ends the current state (gets destroyed next round) and a new one is picked from the queu
	void EndState();		void EndState();

Greebo: /* Mind Interface */

2007-11-08T18:18:10Z

Mind Interface

← Older revision		Revision as of 18:18, 8 November 2007
Line 70:		Line 70:
	// Switches to the given state, the previously active one gets cleared.		// Switches to the given state, the previously active one gets cleared.
	void SwitchState(StatePtr);		void SwitchState(StatePtr);

	~~// Pushes the current state, but only if the priority is higher than the one of the currently active State~~
	~~// Returns TRUE if the State was accepted.~~
	~~bool PushStateIfHigherPriority(StatePtr, int priority);~~

	~~// Analogous to the above, but this switches the state if the priority is higher~~
	~~bool SwitchStateIfHigherPriority(StatePtr, int priority);~~

	// Adds the State to the end of the queue		// Adds the State to the end of the queue

Greebo at 15:10, 8 November 2007

2007-11-08T15:10:55Z

← Older revision		Revision as of 15:10, 8 November 2007
Line 153:		Line 153:
	is shorter and allows the function design to be more strict.		is shorter and allows the function design to be more strict.

	For instance, I'm asserting non-NULL owner pointers in every '''Mind::Think()''' method, because the owner is the one who is calling the Mind in the first place. Each method down the calling chain is getting an '''idAI* owner''' pointer passed along (see above) and these methods are encouraged to assert non-NULL pointers as well. If NULL-pointers are encountered, the program state is probably seriously screwed up anyway, so it's better to let the coder know that there is something amiss. Just checking for NULL pointers via IF and calling RETURN only looks like it was more stable, but in the end you'll have to fire up the debugger in any case to find out why the hell your Task class is not performing.		For instance, I'm asserting non-NULL owner pointers in every '''Mind::Think()''' method, because the owner is the one who is calling the Mind in the first place. Each method down the calling chain is getting an '''idAI* owner''' pointer passed along (see above) and these methods are encouraged to assert non-NULL pointers as well. If NULL-pointers are encountered, the program state is probably seriously screwed up anyway, so it's better to let the coder know that there is something amiss (the hard way, by letting the program crash).

			Just checking for NULL pointers via IF and calling RETURN only looks like it was more stable, but in the end you'll have to fire up the debugger in any case to find out why the hell your Task class is not performing.

	[[Category:AI]]		[[Category:AI]]
	[[Category:Scripting]]		[[Category:Scripting]]
	[[Category:Coding]]		[[Category:Coding]]

Greebo at 15:09, 8 November 2007

2007-11-08T15:09:47Z

@@ Line 139: / Line 139: @@
 == idStr vs. std::string ==
 Although I'm not a fanboy of the homegrown '''idStr''' class, I used it almost everywhere just for the sake of consistency. However, for the Library class I fell back to '''std::string''' for a good reason, as the '''idStr''' class is unsuitable for use as key in '''std::map'''. The implicit cast to '''const char*''' implemented by idStr and the lack of the '''operator<''' method performs a pointer-comparison when used as key in the std::map, and the string lookups fail.
 [[Category:AI]]
 [[Category:Scripting]]
 [[Category:Coding]]

Greebo: /* Task */

2007-11-08T01:56:53Z

Task

← Older revision		Revision as of 01:56, 8 November 2007
Line 103:		Line 103:
	A Task can be plugged into any of the four Subsystems and gets performed each time the '''Subsystem::PerformTask()''' method is called. (this calls '''Task::Perform()'''). When the Task is about to be performed for the first time, the Subsystem invokes the '''Task::Init()''' call to give it a chance to do some one-time processing (setting up walk paths, scan the environment, whatever).		A Task can be plugged into any of the four Subsystems and gets performed each time the '''Subsystem::PerformTask()''' method is called. (this calls '''Task::Perform()'''). When the Task is about to be performed for the first time, the Subsystem invokes the '''Task::Init()''' call to give it a chance to do some one-time processing (setting up walk paths, scan the environment, whatever).

	More information: see [[AI Task]]		More information: see '''[[AI Task]]'''

	= Coding Paradigm =		= Coding Paradigm =

Greebo: /* Task */

2007-11-08T01:56:33Z

Task

← Older revision		Revision as of 01:56, 8 November 2007
Line 103:		Line 103:
	A Task can be plugged into any of the four Subsystems and gets performed each time the '''Subsystem::PerformTask()''' method is called. (this calls '''Task::Perform()'''). When the Task is about to be performed for the first time, the Subsystem invokes the '''Task::Init()''' call to give it a chance to do some one-time processing (setting up walk paths, scan the environment, whatever).		A Task can be plugged into any of the four Subsystems and gets performed each time the '''Subsystem::PerformTask()''' method is called. (this calls '''Task::Perform()'''). When the Task is about to be performed for the first time, the Subsystem invokes the '''Task::Init()''' call to give it a chance to do some one-time processing (setting up walk paths, scan the environment, whatever).

	~~To be written~~: ~~How to add a new~~ AI Task		More information: see [[AI Task]]

	= Coding Paradigm =		= Coding Paradigm =