GOAP: search for an action sequence, then validate its execution

Search through possible world states

Goal-oriented action planning, or GOAP, searches for a sequence of actions that satisfies a desired world condition. An action exposes preconditions, effects and a planning cost. The search operates on hypothetical states; the runtime later performs the chosen actions. Orkin describes this approach in the original F.E.A.R. explanation, and ReGoap provides a concrete implementation with separate planning and execution responsibilities. [1][2]

Give the model enough information

Represent facts that actually change action availability. Having a key and standing beside a locked door are different conditions. Define what each action adds, removes or consumes, and keep the search from silently treating unknown facts as confirmed facts. Costs should express the tradeoff being optimized, such as time or resource use, in comparable units. A low-cost plan is only low-cost within that model.

Worked example: restore power by two routes

An illustrative worker starts at a store without a fuse; the generator is off. The goal is powerOn = true. One plan is FetchFuse, costing 2, followed by ReachGenerator, costing 3, and InstallFuse, costing 1. Installation requires both the fuse and presence at the generator, consumes the fuse and turns the power on. Total cost is 2 + 3 + 1 = 6.

Another plan is ReachGenerator followed by HandCrank, costing 5 once there, for 3 + 5 = 8. If the fuse is available, the first modeled route is cheaper. If the store is empty, FetchFuse must be unavailable and the second route remains possible. These are invented planning costs, not measured action durations.

Execute against the changing world

Before starting each action, recheck the relevant live conditions. Reserve contested resources through the gameplay system; a planner finding a fuse does not reserve it. Update confirmed world facts when the runtime effect succeeds, rather than copying predicted effects into reality when planning finishes.

Create a diagnostic trace containing the goal, initial facts, chosen action bindings, estimated costs and execution outcomes. Remove the fuse after planning but before collection. Close the route to the generator. Interrupt the worker during installation. Verify that failure releases reservations, updates the known state and either replans or selects an explicit fallback. Avoid retrying the identical impossible plan indefinitely.

Control the search and its limits

Many possible targets multiply action bindings and expand the search space. Bound work per planning request and distinguish budget exhaustion from proof that no plan exists. Cache only while its assumptions remain valid. Short plans are easier to inspect, but an overly small planning horizon can miss necessary preparation. GOAP does not automatically coordinate multiple workers, invent missing actions or predict unmodeled consequences. Judge success by both valid execution and the intended behavior.

Sources

• [1] Three States and a Plan: The A.I. of F.E.A.R. — Jeff Orkin, Game Developers Conference 2006.
• [2] ReGoap — luxkun and ReGoap contributors.