generally isn’t more than two or three actions involved in solving any given goal at a time. Hence plans are regularly finishing as only two or three actions are included in each plan and replanning occurs. In a commercial game there would be far more actions and goals (F.E.A.R has 71 goals and 121 actions) and plans would have many more actions contained within them. More actions in a plan mean that it could take longer to execute before the plan finishes and so less planning would occur as a consequence and efficiency would improve.
See the Appendix B for the goals and actions created as part of the project and for brief descriptions of their functionality.
One of the benefits of GOAP that also became problematic during development was the unpredictability of the system. As agents can pick any goals or actions available to them, predicting behaviour in the GOAP system is extremely difficult. Debugging the planning process was quite a painstaking operation involving many manual walkthroughs of each stage of the planning (goal selection, correct neighbours being selected during A*, plan formulation, plan activation, action activation, action validation, action completion etc.) in Visual Studio to determine where a problem occurred with the GOAP system. The logging system along with the outputting of data to screen helped somewhat but debugging the GOAP system definitely ranked as being far more difficult than debugging the FSM system.
4.4 Squad manager implementation
The squad manager implementation experienced several setbacks throughout development due to the fact that the game moves so quickly and agents were often killed before they could carry out squad commands. The squad manager is in charge of allocating agents to squads, assigning tasks to these squads and updating them. The Domination squad manager maintains two squads, one for each Domination point. When there is an agent in the pool of agents, it can be allocated to either the closest squad to the agent or allocated to