How GOAP Systems Evaluate Dynamic Preconditions

Goal-Oriented Action Planning (GOAP) allows game AI to dynamically assemble sequences of actions to satisfy high-level goals based on the current state of the game world. This article explores how GOAP architectures process dynamic, context-sensitive preconditions—such as line-of-sight, resource proximity, and health thresholds—using sensory inputs, procedural checks, and search algorithms to select optimal enemy behaviors in real time.

The Foundations of GOAP in Game AI

At its core, a GOAP architecture separates an agent's objectives from the steps required to achieve them. An agent possesses:

  • Goals: Desired future world states (e.g., TargetIsDead = true, IsSafe = true).
  • Actions: Specific behaviors with assigned costs, explicit prerequisites (preconditions), and the changes they make to the world (effects).
  • World State: A representation of the environment, traditionally stored as key-value pairs or bitsets.

Instead of hardcoding behavior trees or state machines, a GOAP planner works backward from a chosen goal toward the current world state using a graph search algorithm—typically A*—to find the lowest-cost sequence of actions that bridges the gap.

Static vs. Dynamic Preconditions

Standard GOAP architectures use static symbolic preconditions, like HasWeapon = true or IsAlerted = true, which map directly to simple flags in the world state. However, modern game environments require dynamic preconditions that depend on fluid spatial and temporal data.

Dynamic preconditions involve variables such as:

  • Continuous spatial relationships (e.g., "Is distance to cover less than 10 meters?").
  • Environmental queries (e.g., "Does the agent have line-of-sight to the player?").
  • Runtime resource availability (e.g., "Is there an unreserved ammo crate nearby?").

The Evaluation Workflow

To handle dynamic conditions without crippling performance, GOAP systems rely on a structured evaluation pipeline during the planning phase.

1. Sensor and Blackboard Data Extraction

Before planning begins, sensory components populate a local "blackboard" or working memory. Perception systems run raycasts to update visibility flags, while spatial awareness systems locate nearby interest points (cover nodes, patrol routes, or flanking positions). This pre-filtering transforms raw physical world data into structured information ready for symbolic comparison.

2. Procedural Precondition Checks

When the A* planner considers adding an action to an action path, it tests its preconditions. For dynamic preconditions, developers replace rigid equality checks with procedural callbacks or lambda expressions. If an action like TakeCover requires CoverAvailable == true, the precondition dynamically queries the navigation system to see if a valid, uncompromised cover point exists within the agent's movement radius. If the query returns null, the precondition fails, and the planner prunes that action from the search path immediately.

3. Dynamic Cost Calculation

Optimal action selection is not just about whether an action can run, but whether it should run compared to alternatives. Precondition evaluation frequently feeds directly into dynamic action costs.

  • A MeleeAttack action might be technically valid whenever the player is visible, but assigning it a dynamic cost based on DistanceToPlayer * Factor makes shooting far more attractive at long range.
  • An action with a dynamic precondition that is barely met (e.g., cover that is distant or offers poor protection) can dynamically increase its execution cost, prompting the planner to favor better alternatives.

4. Contextual Binding (Parameterization)

Dynamic preconditions often bind parameters to actions during evaluation. If an agent considers the action FlankTarget, the precondition doesn’t just evaluate whether flanking is possible—it calculates and stores the specific flanking coordinate. If the planner selects that path, the action already holds the dynamic parameters needed for execution, preventing redundant recalculations.

Real-Time Validation and Replanning

Precondition evaluation does not stop once a plan is formed. Because game worlds change rapidly, the active action must continuously validate its dynamic preconditions during execution.

If an enemy begins executing a MoveToCover action, but the player rounds the corner and invalidates the CoverIsHiddenFromPlayer condition, the agent immediately halts execution. The failed precondition triggers an interrupt, forcing the GOAP system to update its local world state and run a new planning cycle to generate an appropriate response, such as retreating or returning fire.