How an NPC builds a plan with GOAP.

Describe the goal, then the actions.

Goal-oriented action planning (GOAP) separates what an agent wants from how it gets there. A goal describes a desired state. Actions describe their requirements and expected changes. A planner searches for a sequence that connects the current state to that goal. Jeff Orkin’s GDC paper on F.E.A.R. is a useful reference for this approach.

Here, the goal is simply fire = lit. Five true-or-false facts describe the world: whether the ranger carries wood or an axe, whether the fire is lit, and whether fallen wood or an axe is available at camp.

The shortest plan is not always the cheapest.

At the starting cost, gathering and lighting take two actions but cost 5. Picking up the axe, chopping and lighting take three actions but cost 4. Lower gathering to 2 and the direct route wins at a total cost of 3.

This example uses forward uniform-cost search: explore the cheapest accumulated path first, try actions whose preconditions match, and keep the best cost found for each state. With positive costs and this complete five-fact model, the first goal removed from the search queue has the lowest total cost. Equal-cost routes are both valid; action ordering breaks ties here.

The planner searches up to 32 expanded states. Running out of states means the goal is unreachable in this model. Hitting the search budget means only that the search stopped; a plan might still exist. A campfire that is already lit needs an empty plan, with cost zero.

A small Unity example.

The two C# files below reproduce the same domain and planner. Copy them into a Unity project, attach CampfireExample to a GameObject, and choose Print campfire plan from the component’s context menu. Change its Inspector fields and run it again to compare plans.

var world = World.LooseWood | World.AxeAtCamp;
var result = GoapPlanner.Plan(world, gatherCost: 4);
if (result.Status == PlanStatus.Found)
{
    foreach (var action in result.Steps)
        Debug.Log($"{action.Name}: cost {action.Cost}");
}

The planner has no Unity dependency. It uses a small list as its search queue and copies paths for readability; larger domains need a more deliberate allocation and search-budget strategy. The component prints a plan. It does not navigate or animate a character.

Planning predicts. Execution must check.

“Do next action” applies an action’s symbolic effects immediately. A game executor needs a slower loop: validate the next action, start it, wait for success, observe the resulting world, then continue or replan. If another agent takes the axe, discard the invalid step and search again from the observed facts.

For example, Unity’s NavMeshAgent.SetDestination returning true means a destination request was accepted. It does not mean the character arrived; path calculation can still be pending. Likewise, requesting a walk to the wood must not immediately set hasWood.

Try this failure case: reset, then remove both fallen wood and the axe at camp. There is no valid plan. Put wood directly in the pack and the ranger can light the fire. After picking up an axe, removing the camp’s spare axe will not remove the one already carried.

Use planning where the choices justify it.

I would start with a small state machine for a character that only patrols, chases and attacks through a few clear transitions. GOAP becomes an option when the interesting problem is combining reusable actions as resources and opportunities change. The tradeoff is another model to maintain, search and debug.

A planner can choose an action while a state machine handles its execution. Orkin’s paper discusses planning alongside a small state machine in F.E.A.R.; these approaches can work together. For this ranger, useful debugging starts with the observed facts, chosen goal, rejected preconditions and total plan cost.

Explore more Unity Dev notes, browse my project work, or tell me about your game.