Have you considered storing the world state, actions with their preconditions / effects and the goal states in a Native container outside of ECS. I have taken that route in my basic GOAP implementation. GOAP is an essential part of what I am trying to achieve because whatever the AI can do the Player can, too so basically every Player action is a Goal. Therefore I had to get something usable done pretty quickly.
I have these three native containers in an ActionComposer singleton class:
public NativeArray<Action> AllActions;
public NativeMultiHashMap<int, Condition> AllPreconditions;
public NativeMultiHashMap<int, Condition> AllEffects;
Action struct has the action cost and all the blittable info an action requires along with a unique identifier, which is the ActionType enum. Each of these native NativeMultiHashMaps use the ActionType enum as key and a Condition struct as value. I use the ActionType to connect these containers together during planning. Condition structs are used to describe preconditions, effects and goal states. It consists of a key (enum), an integer value and an operator, which can be ==, <, >, etc…. It is used to compare world / goal states with the effects and preconditions. Based on your post I assume you know how GOAP works so I won’t get into details here.
I also have a GoalComposer class, that has the following native container:
public NativeMultiHashMap<int, Condition> AllGoalStates;
It is used to store the Goals and their states. The key is an enum called GoalType, which is used as a unique identifier for the goals, the value is the Condition struct I described above.
These native containers are all allocated persistently (Allocator.Persistent) and you can populate them from a DB or serialised data from local storage (which is my preference with a simple editor plugin providing the CMS) when the app starts.
The World State can be another native container, like a NativeArray with a struct that contains the Condition struct and some target data or a NativeMultiHashMap where your state type is the key. In my case I need to store quite a lot of different info here so I won’t go through it but what is important is that lots of other systems (such as F.E.A.R. style sensors) write into a TempJob allocated NativeArray that gets merged into this WorldState array at the end of the simulation group or even beginning of the Initialisation group (deferred writing, just like what ECBs do).
And now the ECS part:
I have a SupportedActions DynamicBuffer attached to all unit entities, which contains the list of ActionType enum values that the unit supports. I also have a SupportedGoals DynamicBuffer, which I add to entities that the Units can do actions on, like GoalType.Refuel on a filling station entity or even a GoalType.ReachDestination on the HexGrid. The SupportedGoals is used to check if the unit can do anything with the target by comparing the supported actions with the states of the SupportedGoals of the target.
When a unit is ordered to achieve a goal, I add a simple GoalPlanningParams component to the unit with a few fields, like the target entity the unit needs to achieve a goal, destination tile position, etc… This component triggers the GoalPlanningSystem, which gets the AllActions, AllPreconditions, AllEffects, WorldState and GoalState native containers as dependencies, optimises some of them (like strips out the non relevant world states) and performs the A* search inside a parallel job. The result is an ActiveActions component that contains the list of actions and a CurrentActionIndex added to the unit entity that can be picked up by Action Ordering Systems, like Move, Survey, Repair, etc…
This setup works pretty well for me so far, but it is nowhere near complete. One important missing part is the procedural (or context) preconditions, which I am planning to plug in when I need it.
I have done a few very basic, nonscientific performance tests, where 1100 units were ordered to do a few actions, such as: move → land → survey all in one frame to achieve a goal. The job system performed that calculation in 0.7ms on 10 worker threads and completed all of them way before the BuildPhysicsSystem completed its job on 350 entities on the main thread. These tests are obviously non representative but they helped me do some obvious optimisation on the data the A* searches through and gave me some confidence that the route I took is not leading me to a dead end (for now).
I hope this will give you some ideas and that it might anger a few experienced ECS purists and Burst Job experts, who will be nice enough to lead us to a better solution :).
