The new colonist behavior system has been a lot more work then I originally thought it would be. I’m not entirely sure why I thought I could rebuild the entire behavior system in a short amount of time, but I tend to be a bit too critical of my own abilities. The new system is coming along great and I wanted to share a bit more information about it.

How Not To GOAP

As mentioned in my previous developer log I’ve been working on designing a Goal Oriented Action Planning (GOAP) system in to Mercury Fallen to better control colonist actions. As it turned out building the system was easier than learning how to use it. With great power comes great responsibility and in the case of this new system I was trying to migrate older ideas in to a new method of operation.

As a quick review the GOAP system dynamically generates a sequence of actions to fulfill a given goal. Each action has effects and preconditions which determine how they fit in to the action plan for a goal. This means a colonist can have a goal and the goal planner will automatically determine how to complete that goal by generating a list of relevant actions.

The first mistake I made was being a bit short sighted on what a goal is and how actions should should fit in. I started looking at things like mining and construction as goals to be fulfilled. While this is technically true it meant I had a lot of different goals with only one or two possible actions. The system can certainly work that way, but it was a bit short sighted and lead to problems with how to best distribute these various goals to the correct colonist. I went back and forth between the idea of goal directors, which would assign goals to colonists, and colonists managing their own list of possible goals. Each of these options kept throwing up red flags with me and I didn’t like the mess it created.

In the end I realized I was asking the wrong question when thinking about what the colonists goals were. My focus was on mining, crafting and other job related tasks which are not goals, but actions. After some thinking and asking the question “What is the goal of the colonist?” I realized that the answer was that a colonist only has one goal: Staying Alive.

One Goal To Rule Them All

Actions have a cost associated with them and if two actions have the same effect and both can be done then the lower cost action is chosen. The way I have things setup is that action costs can even be procedurally generated on the fly if need be. So, for example, if I have a SleepOnFloor action and a SleepOnBed action I can have the SleepOnFloor action have a higher cost. This way if SleepOnBed can’t be done because there is no bed then the colonist can sleep on the floor, but if both options are possible the colonist will favor sleeping in a bed.

So after realizing that the colonist only has one goal I also realized that I could use action costs to determine the flow of decision making. The only goal that the colonist is ever trying to satisfy is that StayAlive = True. Top level actions like sleeping, eating and healing have low action costs and procedural conditions that determine if they are possible. Sleeping is only possible if the colonist is tired, eating is only possible if the colonist is hungry etc.. These will always be evaluated first and after that the higher cost FindWork action fulfills the StayAlive goal by just having a precondition of DoWork=true. All work actions fall under that and have their own preconditions and validation. If all of that logically fails then the colonist can default to an idle behavior of wandering around.

Example Decision Flow

To additionally control the possible action flow the system determines what actions are available to the colonist. Some actions are added to the colonist for a given profession. The Miner Profession, for example, adds the GPActionMine action to the colonist. By controlling what actions the colonist has I can further optimize the decision making by reducing the number of actions they have to check when planning their goal. This has the added benefit of specific racial actions. For instance robots don’t need sleep actions, but they do need actions for charging.

Conclusion

As I mentioned at the start the new system is taking longer then originally expected, but I’ve had various slow downs and complications along the way. I’m now on track with the new system and am rapidly working to create the old jobs in to the new system via actions. I hope to have something new available sometime late next week.