X hits on this document

PDF document

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





83 / 110

project and given that F.E.A.R. has 71 goals and 121 actions, these issues could rapidly become time-consuming and harm productivity if not kept in check. Debugging the FSMs involved monitoring the active state and checking why certain state transitioning logic wasn’t triggering if an agent was stuck in a state. The problem of not having any goal/action active couldn’t happen for the FSM as it has to be in a state at all times.

Another drawback with GOAP lies in the difficulty implementing it. Buckland’s FSM was implemented in two header files and the programmer just has to implement the states. The GOAP system requires a goal manager, planners, A* goal, A* map, action container before a start can be made on the goals and actions. The FSM states were created far quicker than the GOAP systems. This was partly due to that fact that they were created after GOAP when all the subsystems were working properly but also because there was less potential to go wrong during implementation. Problems with any of the GOAP systems listed above can derail the entire system while the simplicity of the FSM implementation means only the states can cause problems. Issues within the FSMs can quickly be located while there needed to be a good deal of searching around to pinpoint the relevant buggy module for the GOAP system.


Document info
Document views166
Page views170
Page last viewedSun Oct 23 08:37:42 UTC 2016