Summary of "Better AI in Unity - GOAP (Goal Oriented Action Planning)"

Overview

This video explains GOAP (Goal Oriented Action Planning) and walks through a full Unity implementation from scratch.

• GOAP is a goal-driven, flexible AI planning approach (developed by Jeff Orkin at MIT) that plans by working backwards from desired goal states instead of hard-wiring actions to states as in a FSM.
• The demo implements beliefs, sensors, actions (preconditions/effects/costs), goals (with priorities), strategies (action executors), an agent wrapper, and a planner that generates an action-stack plan.
• A simple NPC demonstrates idling, wandering, eating to recover health, moving through doors, resting to recover stamina, and chasing/attacking the player, including multi-step plans and priority-based interruptions.

Architecture / Core Components

• Beliefs
  • Boolean (true/false) conditions, optionally with location data.
  • Evaluated via delegates.
  • Built with a builder and a belief factory for easy creation.
• Sensors
  • Sphere-collider triggers that detect targets, maintain target position and in-range state.
  • Raise events so beliefs can be updated.
• Actions
  • Named objects with preconditions, effects, cost, and a Strategy (Start/Update/Stop).
• Strategies
  • Concrete logic that performs the action in-game (idle, wander, move-to, attack, etc.).
  • Decoupled via an interface so actions simply compose strategies.
• Goals
  • Named sets of desired belief outcomes plus a priority number (higher = higher priority).
• Planner
  • Generates an ActionPlan (goal + ordered stack of actions + total cost) from current beliefs, available actions, and goals.
  • Orders goals by priority (recently attempted goal is slightly deprioritized) and filters out already-achieved goals.
  • Performs backward planning from goal effects to current state using DFS and returns the best action stack found.

Key Implementation Details

• Belief creation
  • Use a builder and belief factory.
  • Support three types: simple boolean beliefs, location-in-range beliefs, and sensor-based beliefs.
• Sensor setup
  • Use trigger sphere colliders.
  • Re-evaluate objects inside the sensor radius on a periodic timer (not every frame).
  • Expose properties like TargetPosition (or Vector3.zero if none) and InRange bool.
• Action & Strategy pattern
  • Define IStrategy with Start/Update/Stop and status checks (CanPerform, Complete).
  • Actions wrap a strategy and expose Start/Stop/Update; action completion is tied to the strategy.
  • Use builders to create actions with preconditions/effects/cost.
• Goal definition
  • Builder pattern: goals contain a set of desired belief outcomes and a priority.

Planner Algorithm (Backward DFS)

1. Start from the desired goal effects as the initial requirement set.
2. For each candidate action whose effects satisfy some required beliefs:
   • Compute new requirements = (current requirements − action.effects) ∪ action.preconditions.
   • Recurse with the new requirement set, excluding the used action to avoid reuse in that plan (optional).
3. If any path reduces requirements to empty, that path is a valid plan; compose actions from goal → start into a stack.
4. Order candidate actions by cost when exploring to prefer cheaper plans.
5. Return null if no plan is found for any goal.

Implementation notes:

• Build graph nodes with parent/action/current-beliefs/cost.
• Remove already-true beliefs early to prune the search.
• Optionally sort leaf candidates by cost to choose cheaper full plans.

Agent Runtime Loop

• On world changes (sensor events, timers), clear current action/goal to force replanning.
• Update timers (stats degrade) each tick; update animations.
• If no current action:
  • Call planner with available goals (filtering out lower-priority goals if a current goal exists).
  • If planner returns a plan: set current goal, pop top action, start it.
• During action update:
  • Pass deltaTime to the strategy; if action finishes, stop it.
  • When the action stack is empty mark the goal as done.
• Always validate an action’s preconditions immediately before starting it (handles cases where preconditions changed between planning and execution).

Strategies Implemented in the Demo

• IdleStrategy: simple timer-based completion.
• WanderStrategy: pick a random reachable NavMesh point within a radius; completion when reached.
• MoveStrategy: move to a specific destination (used for food shack, doors, rest spot).
• AttackStrategy: play animation and use a timer to mark completion.

Tests and Demonstrated Behaviors

• Simple idle/wander cycles using two low-priority goals.
• Health/stamina beliefs and location data enable multi-step plans:
  • Example: low health → move to food → eat (two-step plan).
• Three-action plan example: move to door1 (cheaper) → move to rest → rest — planner picks cheaper door because action costs are considered.
• Higher-priority goals interrupt lower-priority plans (e.g., player enters chase range → Seek & Destroy interrupts to chase/attack).
• Preconditions are re-checked at action start to prevent starting actions whose preconditions no longer hold.

Coding Patterns and Helpers Recommended

• Use builder and factory patterns for beliefs, actions, and goals for readability and editor friendliness.
• Keep actions and world effects decoupled via the Strategy pattern.
• Use small helper utilities: countdown timers, tiny extension methods (safe null checks, Vector3 NavMesh helpers), animation clip length lookup.
• Provide a custom inspector to visualize beliefs, current goal/action, and the plan stack during testing.
• Apply dependency injection / a service locator to make testing and swapping planner implementations simpler.

Performance, Design Decisions, and Trade-offs

• Planner uses DFS working backwards from the goal — simple to implement and fine for small action sets, but can be replaced with heuristic search for larger domains.
• Already-true beliefs are removed early to prune the search.
• Each action is removed from the available set within a single plan to avoid cycles and unlimited reuse — a design choice that can be changed.
• Plans are biased toward cheaper options by ordering candidate actions by cost.
• For complex domains, consider replacing DFS with A*, Dijkstra, or other heuristic search algorithms.

Practical Tips & Suggested Improvements

• Build a node-based editor for beliefs/actions/goals/strategies to simplify authoring.
• Use dependency injection/service locators for easier testing and swapping of planner implementations.
• Consider more advanced planners (A*, Dijkstra, etc.) for larger action spaces.
• Integrate with visual tools (Node Canvas, Behavior Designer) or asset-store packages if you prefer not to roll your own.
• Keep actions small and composable — adding new actions/goals should be low-effort.
• Always verify action preconditions immediately before starting an action.

Demo Outcomes

After following the video you should be able to:

• Understand GOAP architecture and the interplay of actions/goals/beliefs.
• Implement a GOAP system in Unity using builder/factory/strategy patterns.
• Create sensors, timers, strategies, and a planner that returns an action stack for an agent.
• Extend the system with new actions, goals, and richer world models with minimal changes to the planner.

Code / Tools / Resources Mentioned

• Jeff Orkin (developer of GOAP at MIT)
• FEAR (example game that used GOAP)
• The presenter’s extension methods and helper utilities (countdown timers, extension methods)
• Node Canvas (third-party node-based AI tool)
• Co-pilot (briefly mentioned)
• Asset-store packages: a paid solution (transcription: “escope”) and a free open-source alternative
• The presenter’s repository containing code, factory, custom inspector, and helpers

End of summary.

Category

Gaming

---

Share this summary

Share on X/Twitter Share on Facebook Share on LinkedIn Share on Reddit Share on WhatsApp Share on Telegram

---

Is the summary off?

If you think the summary is inaccurate, you can reprocess it with the latest model.

Reprocess summary

Video