Behavior Trees or GOAP for Rimworld-like game?

Question

I am currently making a Rimworld-like game. For now, it is identical in appearance, how the map works and how the pawns (colonists) are supposed to function.

Core world-generation logic and A* pathfinding is done, so my next step is to implement AI.

The question - for a game such as Rimworld (since the original author of the game never mentioned what sort of technology he used), is it preferable to use Behavior Trees or Goal Oriented Action Planning AI methods?

I use Unity and have found assets for both of the technologies:

GOAP

Behavior Trees

I am expecting large map sizes, anywhere from 200x200 to 400x400, and an AI agent might have to take a lot of things into consideration (his environment, the position of his allies and enemies, possibly nearby items and structures).

I am leaning towards GOAP because even though it seems harder to implement at first, it seems easier to maintain later, because the agents figure out stuff on their own based on the information they are given, so I won't have to hard-code every single action or pattern (please correct me if this is wrong.) I also have no experience with either of the technologies so this might be something to take into account, but I am willing to learn.

Any suggestions, comments or ideas are much appreciated and I'm open for discussion.

Answer 1

In a Rimworld-like game you are dealing with NPCs who need to be able perform complex multi-step tasks (transport materials to workplace, craft item, transport crafted item to storage). And players expect their NPCs to perform those steps in a smart way and while considering all kinds of other priorities. Such complex multi-step tasks are far easier to implement using GOAP than using behavior trees.

However, you might use simpler behavior trees for entities with less far-sighted behavior. Like animals, for example.

Answer 2

I'll only speak of Planning.

Unity provides a planner: you may wish to check that first instead of jumping into some GOAP Plugin (as amazing as they can be :-), or embarking into developping your own.

If you wish to develop a planner, GOAP's principles are:

0. NPCs have goals; have a procedure compute a goal for an NPC; this can be a method for each NPC class.
1. Actions as classes: one abstract action class and then subclass according to behaviors (combat, ambiant, etc).
2. Actions have costs; Jeff Orkin's advice is "abstract actions have higher costs".
3. Use Path-Planning A* with action cost to search for a plan.
4. Actions have procedural preconditions : use these to drastically reduce the number of applicable actions in one game-state (i.e. limit A*'s branching factor). This is very powerful to reduce search size, but is time consuming: use clever sensors to store the information you need to avoid recomputing for every action you could consider.

You may wish to begin without action costs.

You may wish to have dynamic action costs; for instance the MoveTo action can get its cost from distance. Obviously this is more complex.

Create a set of actions for each NPC type: for instance when planning for a grunt, use the action set for a grunt.

You may wish to run planning for meaningful NPCs only and have, say, a finite-state machine for others (e.g. animals).

So the idea is: compute a goal, find a plan achieving this goal and then, execute the plan.

Plan-execution-module's tasks are: updating game states, goals, and sensors accordingly, so that you don't spend your time replanning if goal hasn't changed, for instance, or so that you DO replan when game state forbids the execution of one action of a plan. Crucial issue is sampling: how often do you want to check your data to trigger planning again?

Enjoy Planning!

Answer 3

"In other words, I heard GOAP was better for projects where you have player made environment (or perhaps procedurally generated)."

Please, who told you that "GOAP was better for ..."? I'd really like to know.

What is at stake here is the following: planning need not be aware about the game. You can drop actions one morning, have the planner search for plans with these actions and change all these the next day.

And that's one of the best selling point of planning in a video-game. If not the best.

In a game, you can directly drop actions in a Smart Object Node (SON), for instance through a DLL (providing your code architecture can handle that). Then, any game object colliding with this SON can pass these actions to the planner when needed.

DLLs mean you provide actions yourself. You may wish to dynamically create actions.

For instance, you may wish to have the player create actions and then have the planner use these actions. An interesting point is that game design can generate situations when the player doesn't even know he's creating actions.

Or you can, first iteration, modify actions costs, according to what your game has been able to grasp from the player's emotional state.

But you won't escape the problems I listed in my previous post. The more actions available for search, the larger the branching factor.