GOAP stands for Goal-Oriented Action Planning.

It is a way to build game AI that chooses what to do by planning from the current world state toward a goal. Instead of hardcoding one fixed behavior chain, you describe the actions an agent can take, the conditions required for each action, and the effects those actions produce.

Then the planner figures out the sequence.

That is the whole appeal. You define the pieces. The AI assembles the plan.

GOAP planning flow from world state to action plan

Why GOAP exists

A lot of game AI starts as a finite state machine.

That works fine until the logic gets big.

At that point, the code often turns into a web of transitions:

  • if enemy seen, attack
  • if out of ammo, reload
  • if low health, flee
  • if no weapon, search
  • if cover available, move there
  • if target lost, search again

Very quickly, the AI is not “a machine with states” anymore. It is a pile of exceptions.

GOAP is useful because it changes the shape of the problem. You stop asking, “What state should this AI be in?” and start asking, “What goal does this agent want, and what sequence of actions can get there?”

That is often a better fit for enemies, allies, and NPCs that need to react to changing conditions.

The pieces of a GOAP system

A GOAP setup usually has three parts:

1. World state

This is a set of facts about the agent or the environment.

Examples:

  • has weapon
  • has ammo
  • sees player
  • is in cover
  • health low
  • target in range

You can store these as booleans, numbers, enums, or key-value pairs. The important part is that they are queryable and small enough to search efficiently.

2. Actions

Each action describes:

  • preconditions: what must be true before the action can run
  • effects: what becomes true after the action succeeds
  • cost: how expensive the action is
  • implementation: the actual gameplay behavior

Examples:

  • FindWeapon
  • Reload
  • MoveToCover
  • AttackTarget
  • Heal

An action is not just animation. It is a gameplay step with meaning in the world model.

3. Goals

A goal is a desired world state.

Examples:

  • target dead
  • self healed
  • in cover
  • weapon acquired

The planner looks for a chain of actions that can make the goal true from the current state.

How planning works

Here is the simple version.

If the current state already satisfies the goal, no plan is needed.

If not, the planner searches backward or forward through actions to find a valid sequence.

For example:

  • Goal: target dead
  • Available action: attack target
  • Precondition for attack: has weapon and target in range
  • Available action: move to target
  • Precondition for move: can path to target

Now the planner can build a chain:

  1. move to target
  2. attack target

If has weapon is false, it may add:

  1. find weapon
  2. move to target
  3. attack target

The AI does not need a special “find weapon then attack” state. It discovers that sequence when the world demands it.

Why GOAP feels flexible

GOAP shines when the same action can serve multiple goals.

For example:

  • MoveToCover might help survival
  • MoveToTarget might help attack
  • MoveToItem might help resupply

Because actions are reusable, you often get more behavior from fewer building blocks.

That makes GOAP attractive for emergent AI. It can produce behavior that looks intentional without requiring a giant hand-authored tree of every possible case.

Where GOAP is not magic

GOAP is not free.

It comes with costs:

  • planning takes CPU
  • debugging can be harder than with a simple FSM
  • action design has to be clean
  • bad world state modeling leads to weird plans

If your actions are too broad, the planner gets vague. If they are too narrow, you end up with too many tiny steps. Both extremes make the system harder to use.

You also need to think about interruption.

A plan may be valid now and invalid two seconds later. The player moves. The door closes. The target dies. The AI must replan when the world changes enough to matter.

Practical implementation advice

If you are building GOAP in Unity, start small.

A good first version usually has:

  • a compact world state representation
  • a simple action base class
  • a planner that searches for the lowest-cost valid sequence
  • a blackboard or shared state object
  • replan triggers for invalidated goals

Keep the action list short at first. Get one NPC working before you add ten goals and twenty actions.

A common pattern is to separate:

  • decision logic: the planner
  • execution logic: the actual action running in the scene

That separation keeps your system easier to test.

Good use cases

GOAP is a strong fit for:

  • enemy AI that has to switch between fighting, retreating, and resupplying
  • survival NPCs
  • simulation-heavy games
  • agents with multiple competing needs

It is less useful when the behavior is mostly cinematic, highly scripted, or very simple.

Practical takeaway

GOAP is useful because it makes AI think in terms of goals and actions instead of hardwired state transitions.

That does not make it automatically better than every other approach. It just means it scales well when the agent needs to choose among many valid action sequences.

If your AI needs to look adaptable, GOAP is worth the effort.

Diagram note

The flow diagram above is enough for this article. If you add a second visual later, show one concrete action chain or a small planner search tree.