There are a few reason why I choose to deep-dive into GOAP:

-   A Great Learning Opportunity.

While I've worked on BehaviorTrees and Finite State Machines before GOAP is something that I've heard mentioned a lot, especially in a lot of GDC talks, but never actually worked with myself. This made it a good learning opportunity to expand my knowledge.

-   Working With Scalability and Adaptability

One of the big advantages is the modular design and reusability for logic. For example the same Action Node can be used across multiple goals and by multiple actors. It's also needs to be adaptable since it needs to be integrated with other systems.

I think this a great mindset to get into in general and is usually how I like to think while designing systems.

-   Showcase C++ & System Design Skills

GOAP isn't just about AI behaviors, it's a data driven system that can be used to more things than just AI behaviors. By developing GOAP from the ground up I hope to demonstrate my ability to design and integrate systems, not only relying on architecture provided by the engine. I also hope it showcase my proficiency in c++.

-   Ability to connect my own system with others

Since this project is made in Unreal 5 I've had to integrate and adapt my GOAP-system with Unreal's infrastructure. I also connected GOAP with a hunger, thirst, and tiredness system, showing that I can bridge AI planning with gameplay mechanics. I also hope this project demonstrates my ability to work within Unreal Engine’s ecosystem while extending it with custom logic.

The World State is a fundamental part of the GOAP-system. It represents the current state of the world and serves as the data for the Planner to determine the AI agents goal and action.

The data struct I made contains a Map of a String and a bool. The keys identifiers are strings and represent different facts about the world. For example, "IsHungry", "HasWater", "Sleeping" etc. 

The rest of the struct is a set of helper functions and operators that allow for easy modification and retrieval of the data.

For this project, I kept the World State implementation simple by using only boolean values, however, a more advanced system could of course expand this by having more data containers with different value types aswell. 

For this project I decided very early on to create a simple graph system to structure the goals and actions. This is because I wanted to utilize A-star to decide on the Goal & Action for the AI.

The Base Node contains all the properties that both Goal and Action nodes must have.

WorldState Preconditions: 

Preconditions define what must be true for this node to be valid and considered by the Planner.

Example:

"HasWater" must be true for the node AN_DrinkWater to be considered by the planner. 

WorldState CostState: 

A set of factors that influence the H-cost and likelihood of this node being selected. This is the main way to customize how the AI behaves.

Example: If the food storage is low on food then the H-cost of the Goal Node to gather food should be lowered, and the opposite if the storage is almost full.

int32 Cost:

The base cost for the node. This can be modified to prioritise different nodes before World State based filtering is taken into consideration.

TArray<TSubclassOf<UGOAP_ActionNode>> ConnectedActionsClasses: 

This is referencing the connected actions to the node. Both Goals & Actions can be connected to multiple actions. 

The reason it's an array of subclasses of action nodes is so it can reference defined Actions Nodes in blueprints and be able to instantiate them during run time.

TArray<UGOAP_ActionNode*> ConnectedActions:

Stores the Action Nodes after they have been instantiated.

virtual int32 CalculateHCost(): 

A function to be overridden when calculating the H-cost for the node.

Example of Goal Node connected actions: 

The node for the current Action of the AI. Here logic and properties only applied to Actions are contained.

WorldState Effects:

This is the effect on the World State that gets applied when the action is completed.

Example: Action "DrinkWater" --> Sets "HasWater" to false.

void ExecuteOnce()

Function exposed as a blueprint native event to execute initialization logic when the Action gets selected. This can be called both through c++ and blueprints. 

bool ExecuteAction()

Function that controls when the action is completed. It's running every tick and when true is returned the action is considered complete. Just as ExecuteOnce this can be controlled both through c++ and blueprints.

void ResetAction()

A function to reset variables in the action for a specific actor.

int32 CalculateHCost()

Works the same way as in the Goal Node but without the option to use the number of actors assigned as a weight to the H-cost.

With this design it allows subclasses of the Goal & Action node to be created in the editor. This makes it very simple and quick to set up desired Goals & Actions.

Goal Nodes I made for the showcase:

Action Nodes for the Sleep Goal:

The AI Agent is the actor that interacts with the GOAP system. To do this it maintains its own World State, calls the Planner to evaluate goals & actions. For this I created a GOAPComponent that can be attached to the AI.

The AI Agent also has a "brain" system that keeps track of hunger, thirst and tiredness. For this to communicate with the GOAP-system I used delegates that gets broadcast whenever the state changes.

Example setting up goal nodes in the editor:

The GOAP Utility class is a helper class to provide common task to be called from an Action Nodes. It serves as a static library of functions that can be used across multiple action nodes without requiring duplication of logic.

The common tasks include:

• FindFirstActorOfClass

• FindAllActorsOfClass

• MoveToLocation

• StartTimer

• IsTimerDone

Certain functions need to run every frame (like MoveToLocation and IsTimerDone). They are designed with that aspect in mind, for example, MoveToLocation only does a move request if it's not already active and restoring a delegate only when the move is completed instead of polling every frame.

The functions are made static for a few reasons. It avoids unnecessary object instantiation, especially since it's most likely going to be used with a lot of actors. Since some functions are called every frame creating and destroying objects for each function call would be very unnecessary overhead. It is also convenient to use be able to call the functions in blueprints without requiring references.

Example MoveToLocation being used in an Action Node:

Copyright © All Rights Reserved