X hits on this document

PDF document

Enhanced NPC Behaviour using Goal Oriented Action Planning - page 60 / 110





60 / 110

need to be as up to date is still stored in the working memory like orders, events and enemy details.

4.3 Game-specific GOAP issues

One of the biggest hurdles experienced throughout the implementation was detecting when actions have completed and getting actions to execute alongside the various subsystems, where different subsystems needed separate activation. Initially, quite low-level actions were designed for the game. There was to be GoTo actions to handle movement, separate attack actions to handle attacking and other ancillary actions to deal with actions like reloading, changing weapons and so on. Only one action can be active at any time but it was often the case that an agent needed to move and attack at the same time. Suppose the agent was moving to some location in the world using a GoTo action and is attacked en-route. The agent is in the process of a GoTo action which doesn’t actually attack. If the agent just invalidated its current plan and replanned to activate an attack action then the agent would just stand there attacking as movement is handled by GoTo actions only. So it was decided to make the actions a little more high level and control different subsystems simultaneously if required. For example, the AttackShortRange action states that if the target isn’t visible then the agent should move within range of it or if it is patrolling then the agent should move back to protect the patrol position. At the same time, the action must activate an attack so it is essentially controlling two subsystems, the weapons manager and the navigation manager.

Determining when actions complete was quite challenging and this project employed two very simple finite state machines to determine if subsystems have finished their tasks. The first state machine records the status of navigation, which can be unset, incomplete or complete. The second state machine records the status of an attack, which again can be unset, incomplete or complete. Orkin also used simple finite state machines in the F.E.A.R. system, which had GoTo, Animate or UseSmartObject FSMs (Orkin, 2006). The status of each of the state machines is placed on the blackboard so that actions can access them and decide


Document info
Document views357
Page views361
Page last viewedWed Jan 18 04:31:52 UTC 2017