mode required several of the FSM states to be duplicated and rewritten along with new states added. The GOAP just required two new goals, four new actions and a new XML file.
An extra action and state were added to the game late on. The BlindFire action is triggered when an agent is being damaged and doesn’t know where it is being hit from. The agent fires randomly in any direction once activated. Including this into the GOAP system required just defining an extra action and placing the action into the agent’s action set. The FSM system required a new state to be created along with extra transition logic placed in the Attack, Idle, GoToAmmo. Patrol, GoToHealth and Melee states to inform the FSM when to change to the BlindFire state. Again this illustrated the flexibility along with the ease of management of the GOAP system. Actions and goals can be easily added or removed from GOAP system whilst the high amount of coupling intrinsic in the FSM system makes this task far more difficult. The FSM needed the whole system to be recompiled again due to the coupling between all the states. This highlights another major benefit provided by GOAP as illustrated by figure 17. The actions and goals just need to be defined and there is no explicit link between the two, the GOAP system establishes the links at runtime. Links exist between FSM states which are hard-coded into the C++ code pre-runtime and this doesn’t facilitate new states or changes to existing ones.