any type of fact or if the working memory wasn’t just restricted a certain structure of working memory fact.
Action cost and goal relevancy values were coded directly into the application using C++ during the project. However in the F.E.A.R. system this data was contained in an external database which is read throughout the application execution. Creating a similar external database that is read in at the initialisation of the application which contains not only the cost and relevancy values but also agent’s action and goal sets could be another addition to the GOAP system. It would improve compile times as changes to the cost and relevancy values would be external to the application. One criticism of the existing GOAP system is that action costs are static values; they never change throughout application execution. If a context sensitive method of altering action cost values were devised, behaviour in the system could be improved further. For example, if an agent is close to a health pickup, the cost of the GoToHealth action could be reduced while the cost of the GoToAmmo action could be increased, making the GoToHealth action more attractive to the A* machine. The database could store these values so that they could be subsequently obtained and updated at a later stage.
The first-person shooter genre is the only genre publicly known so far to have used GOAP in any shape or form. However other genres of games are actually more suited to using GOAP. For example, take a real-time strategy game like Civilisation where the AI has several plans on-going at the same time. It must plan what buildings to put on the map and where, what units to build, where to move them to and can also have economic and strategic plans. The GOAP system would be ideal for this kind of scenario whereby a single planner could be used by the different systems to plan out an AI’s course of action. Other game genres whereby GOAP could be used include sports games, simulation type games like The Sims or even puzzle games.