Chapter 4. IMPLEMENTATION
4.1 Standalone GOAP system
The GOAP system was developed separately from the game application to begin with. Getting the GOAP system setup initially with the abstract action, goal, planner, A* machine and other components was completed quite quickly due to the design in place, however it was impossible to test the system without any goals or actions. Some sample goals and actions that were to be included in the game were created and testing was performed by manually setting a goal’s relevancy e.g. the KillEnemy goal to a high value so that it was always selected by the GoalManager as the most relevant goal. The plans that were built for each goal were inspected and validated before moving on to implement new goals and actions.
Originally it was hoped that world state symbols could include variable support for the GOAP system. The design included variable support from the off but several problems were encountered during the implementation that forced the world state symbols to be reduced back to Boolean values. It was intended to have support for integers, floats, path nodes and other objects such as AIModules and pickups. To include these, functions in the world state class that get and set the values for each different variable type were required. Not only that but a means of testing whether a variable is equal to another variable or not was also required. This was straight-forward for integers and floats but not so for objects. To test objects against one another the only way to match them was to perform a custom test for each different type of object. If the world state symbol was discovered to be a path node and was being compared to another node, the test would involve checking the location to see if it was the same. If an AI module was being tested against another AI module symbol then a different test would be needed. Instead of having many different variable types stored alongside the world state, it made sense to use a single object (called an OBJECT) as the base