Difference between revisions of "Stacked AI"

From Elite Wiki
m (Example of a multi-layer stacked AI-system:)
m (indexing)
 
(3 intermediate revisions by 2 users not shown)
Line 24: Line 24:
  
 
  '''job2AI:'''
 
  '''job2AI:'''
  *STATE1 jobdescription: scanfor and collect loot.
+
  *STATE1 jobdescription: performCollect (loot).
 
  NOTARGET = "exitAI"
 
  NOTARGET = "exitAI"
  
Line 44: Line 44:
 
  '''job1AI:'''
 
  '''job1AI:'''
 
  *STATE1 Jobdescription: combat; scanForHostiles,attack,etc.
 
  *STATE1 Jobdescription: combat; scanForHostiles,attack,etc.
   NO_TARGET = "exitAI"
+
   NO_TARGET = (exitAI)
  
 
  '''job2AI:'''
 
  '''job2AI:'''
 
  *STATE1 jobdescription: scanfor and collect loot.
 
  *STATE1 jobdescription: scanfor and collect loot.
  NO_TARGET = "exitAI"
+
  NO_TARGET = (exitAI)
 +
ATTACKED = ("setAITo: job1AI.plist");
  
 
== Note ==
 
== Note ==
Line 61: Line 62:
 
  [[OXP_howto_AI]]
 
  [[OXP_howto_AI]]
 
  Back to: [[State_machine]]
 
  Back to: [[State_machine]]
 +
 +
 +
[[Category:Oolite]]
 +
[[Category:Oolite scripting]]

Latest revision as of 12:30, 23 December 2007

The best way to avoid overly-complex AI's is to use 'stacked'AI's.

An AI(firstAI.plist) can stack another AI(secondAI.plist) on top of itself by calling the method 'setAITo: secondAI.plist'.

One could design a 'scaffoldAI' that defines the entity's default behaviour, have this call for specialised jobAI's when such specific behaviour is called for.

Specialised JobAI's need to 'exitAI' in order for the state machine to return to the previous AI.

(! Warning: do not use another 'setAITo' action to return to a previous state unless there is a good reason for doing so. To do so could lead to recursive AI loops, resulting in memoryleaks and crashes.)

Alternatively: the completion of a job results in the ending of the entity (leaves system or destruction for example). Entity death should exit all AI's in the stack.

Example of a multi-layer stacked AI-system:

defaultAI: 
Jobdescription: Navigate from witchpoint to station,
ATTACKED = "setAITo: job1AI.plist"
job1AI:
*STATE1 Jobdescription: Combat, scan for hostiles, attack.
NO_TARGET = "set state to STATE2"
*STATE2 Jobdescription: scanforloot/Attacked setStateTo:State1
NOTARGET = "exitAI"
TARGETFOUND = "setAITo: job2AI.plist"
job2AI:
*STATE1 jobdescription: performCollect (loot).
NOTARGET = "exitAI"

RESTART

Is the message recieved when a halted AI returns to the top of the stack.

So alternatively we could have organised the above system in a less complex way:

defaultAI: 
*STATE1 Jobdescription: Navigate from witchpoint to station,
 ATTACKED = ("setAITo: job1AI.plist");
 RESTART = ("setStateTo: STATE2");  
*STATE2 Jobdescription: scan for loot 
 TARGET_FOUND = (setAITo: job2.plist"); 
 ATTACKED = ("setAITo: job1AI.plist");
 NO_TARGET = ("setStateTo: STATE1");
 UPDATE = (scanForLoot); 
job1AI:
*STATE1 Jobdescription: combat; scanForHostiles,attack,etc.
 NO_TARGET = (exitAI)
job2AI:
*STATE1 jobdescription: scanfor and collect loot.
NO_TARGET = (exitAI)
ATTACKED = ("setAITo: job1AI.plist");

Note

The above examles have highly simplified AI scripts, for complete AI structure go here.

Working examples of JobAI are collectLootAI.plist and InterceptAI.plist.

A working example of a 'scaffold'AI is route1PatrollAI.plist.

Links

OXP_howto
OXP_howto_AI
Back to: State_machine