The benefit of using this system is that if agents with different goal and action sets need to be created then the program just needs to read in the XML file for that agent type. For example, an agent with the XML file defined above could be just a rat-like enemy in the game which can’t attack and just wanders aimlessly while another agent type could have more or all of the action and goal types enabled thus giving it different behaviour.
The design of the structure for the GOAP actions was influenced by the requirements specification document set-out by the working group on GOAP (Orkin et al., 2004) along with other considerations taken from Orkin’s suggestions in his various articles. GOAP actions have the same general characteristics according to Orkin (Orkin, 2002) so an abstract action was designed that implements the basic functionality required for all actions. All the subsequent actions created build on-top of this and extend its functionality. For an action to trigger, the preconditions and effects of the action must be satisfied. These preconditions and effects are each represented by a world state which has a subset of the world state symbols actually set (see figure 1, the Reload action has no precondition world state symbols set and has a single effect world state symbol set). Each action was designed to have functions that test the action’s preconditions against an input world state to determine if they’re met and also to apply the effects of the action to an input world state. To direct the A* search, actions require costs associated with them, cheaper actions that solve a goal are selected over more costly actions. If there is a tie during an A* insertion (i.e. if it turns out that an action has the same f value as something already on the open list during A*) there needs to be conflict resolution. To this end, each action has an integer that represents the precedence of the action. Actions with higher precedence are inserted before the lower precedence actions in