Godot Game AI Development: Building Autonomous NPC Planning with GOAP

From State Machines to Autonomous Planning: The Evolution of Game AI

In game development, making NPCs (non-player characters) behave in realistic, intelligent ways has always been a central challenge for indie developers. One developer recently built an advanced AI system in the Godot engine that allows game AI characters to autonomously form action plans at runtime — completely without manual step-by-step guidance. The system starts with Goal-Oriented Action Planning (GOAP) and significantly extends it, with plans to release it as a free open-source Godot plugin.

The project's goal is clear: create immersive simulation-focused games where AI is the top design priority. Over the years, the developer has implemented game AI in multiple smaller projects — from enemy patrols in side-scrollers to teammate and enemy behavior in a helicopter-based Rocket League variant — accumulating substantial hands-on experience.

The Limitations of State Machines and Behavior Trees

The typical starting point for enemy behavior is a Finite State Machine (FSM) — define a handful of behavior states and specify the transitions between them. Think: patrol, chase player, attack, and repeat.

FSM is one of the oldest architectures in game AI, with theoretical roots going back to automata theory in the 1950s. Classic early games like the ghost AI in Pac-Man (1980) are textbook FSM applications. FSMs are simple to implement, have minimal performance overhead, and are easy to debug. However, as character behavior grows more complex, the number of states explodes exponentially, creating an unmaintainable "state explosion" problem. When N states have M possible transitions, developers must manually manage N×M rules — adding any new state risks breaking existing logic. This is what the industry calls "FSM hell."

The most popular solution to this problem is the Behavior Tree. One of its earliest high-profile applications was the Halo series — specifically, Bungie systematically applied behavior trees while developing Halo 2 (2004) and further refined them in Halo 3 to drive the tactical decision-making of Covenant soldiers, enabling them to coordinate, seek cover, throw grenades, and call for backup, resulting in believable and challenging behavior. Behavior trees address FSM's state explosion by organizing behavior into a hierarchical tree structure: leaf nodes represent specific actions or condition checks, while internal nodes are Sequence nodes (all children execute in order) and Selector nodes (children are tried in priority order until one succeeds), making control flow more manageable.

Godot has solid behavior tree support — the developer tested both the Behave and LimboAI plugins, both offering excellent documentation and debugging tools. However, while prototyping a restaurant management game, he realized behavior trees weren't the right fit.

Why Behavior Trees Aren't Enough

Just to implement a basic set of predefined actions — a customer walks to the counter, places an order, waits, receives the order, rates the experience, and leaves — required building a fairly complex tree and writing a large amount of custom leaf nodes.

The more critical issue was scalability and reusability. The core limitation of behavior trees is that all possible decision paths still need to be manually predefined by the developer. The system has no inherent reasoning or planning capability, and becomes brittle when faced with unanticipated combinations of circumstances. Developers must manually account for edge cases: what if the agent is hungry but has no food? What if there's food but the agent is hungry? On top of that, actions like "walk toward food" and "pick up food" are fundamentally generalizable as "walk toward anything" and "pick up any object" — yet in a behavior tree, you end up rewriting these simple sequences over and over.

Repeated interaction sequences in a behavior tree

In short, every time you want a new type of agent behavior, you have to build a new tree from scratch. For an immersive game aiming for complex emergent behavior, this is nearly unworkable.

GOAP: Letting NPC Agents Plan for Themselves

Goal-Oriented Action Planning (GOAP) offers a fundamentally different approach. GOAP was developed and applied by Monolith Productions AI researcher Jeff Orkin during the development of F.E.A.R. (2005), drawing its theoretical foundations from the classic AI planning algorithm STRIPS (Stanford Research Institute Problem Solver, 1971) and the more modern A* heuristic search algorithm. The AI soldiers in F.E.A.R. demonstrated astonishing tactical intelligence through GOAP — dynamically finding cover, coordinating squad fire, and responding logically to player actions — and were widely regarded as a milestone in game AI history.

A GOAP system relies on three core elements: goals, actions, and planning.

The Core Mechanics of GOAP

Each agent has a list of available goals, each with its own reward level, and the system automatically selects the highest-reward goal. Agents also have a set of available actions, each with:

Preconditions: states that must be true before the action can execute
Effects: changes the action makes to the world state when executed

Take "eat food" as an example: the precondition is "agent has food," and the effects are "agent is less hungry" and "food is gone."

Given a selected goal and a set of available actions, the system recursively plans in reverse: the goal requires condition X to be true, action 1 can satisfy X but depends on precondition Y, action 2 can satisfy Y with no preconditions — forming a complete plan chain from action 2 to action 1. GOAP's planning process is essentially a backward graph search through "action space": starting from the goal state as the endpoint and the current world state as the origin, treating each action's preconditions and effects as graph edges, using A* to find the lowest-cost sequence of actions.

You might not have noticed: planning runs in reverse, but execution runs forward. The system first executes action 2 (satisfying Y), then action 1 (satisfying X), ultimately achieving the goal.

An action plan autonomously formed by an agent

GOAP's Core Advantages Over Behavior Trees

GOAP's greatest appeal is that actions require no predefined relationships with each other. Developers can freely add actions like napping or attacking, and once a goal like "increase hunger value" is set, the agent will automatically chain relevant actions into a plan.

Even better, if a precondition is already satisfied — say the agent is already holding food — the plan can start from the middle, skipping unnecessary steps. The system always seeks the shortest, most efficient plan, which typically means executing fewer actions.

Extending GOAP: From Boolean Conditions to Object-Oriented World State

The developer started from the original GOAP implementation described in research papers, also referencing Vinitius's example code on GitHub and accompanying YouTube explanations. In practice, however, he identified several limitations of original GOAP and set out to extend it.

Problem 1: World State Is Too Simple

Original GOAP requires the world state to be reduced to a set of simple boolean conditions — all states are global predicates, like IsHungry=true. "Hunger," for instance, is inherently a continuous value but can only be encoded as a binary "is hungry or not." If an agent is extremely hungry, a single piece of food might not fully resolve the hunger state, requiring a plan chain involving multiple eating actions — even though the first banana is conceptually already contributing toward the goal.

Problem 2: Object-Oriented World State

The developer's first major change was upgrading world state from simple key-value pairs to support object information. This aligns with the concept of "Object-Oriented Planning" in AI planning research. By introducing object identifiers or object references as state keys, the planner can handle Parameterized Actions — the same "pick up" action can apply to any specific object — so the action library doesn't grow linearly as game content expands.

Tracking spatial relationships like "is the agent near a banana" is a significant challenge in GOAP, because during planning, neither the player nor objects can actually move. The developer adjusted the world state simulation so objects maintain their own state, which can be copied during planning without copying actual objects, and split world state into agent-specific attributes and world attributes.

Simulation of object-oriented world state

One technical pitfall worth noting: during implementation, the developer encountered serious memory leaks. This is a typical risk when object references are introduced into a planning system — when the planner simulates action execution, it must create deep copies of the world state, and these temporary copies require careful management. The specific cause was that Godot does not automatically free copied nodes, even when they lose all references and are never added to the scene tree. The problem was only resolved by manually freeing these nodes when the simulated world state was destroyed.

Problem 3: Lambda-Style Preconditions

In original GOAP, preconditions are simple checks of whether a key in the world state equals a desired value — they can only express simple propositions like "the value of key K in world state equals V." The developer upgraded these to evaluable Lambda functions capable of checking custom conditions against the agent and simulated world state.

This improvement essentially merges "Declarative Planning" with "Procedural Logic" — a design pattern closely aligned with the "Strategy Pattern" in software engineering. Logic is no longer confined to world state; it can call Godot-specific information or other systems. For example, his navigation precondition calls Godot's navigation agent during planning and immediately fails if no path to the target can be found — allowing high-level logic to be chained with very few actions. One important caveat: since planning recursively calls these functions in a simulated state, the logic inside Lambdas must be pure functions with no side effects, or they risk contaminating real game state.

The Goblin Mailroom: A Full Real-World Test of the GOAP Framework

To validate the AI framework, the developer set up a cleverly conceived test environment — the "Goblin Mailroom." The premise: loot that disappears from a dungeon gets teleported to a mysterious mailroom, where a pair of goblins sorts the items for later redistribution back into the dungeon.

Goblin Mailroom test scene

In this scenario, the main goal is simply for the goblins to sort items in their group (gems, potions, etc.). After creating individual goals for each goblin, all goblins automatically began collaborating to sort items. The developer admits that implementing the same functionality with a behavior tree would require hours of planning and implementation; with the GOAP framework, while the initial setup also took considerable time, "next time it'll be fast — until something breaks."

Spatial Actions: A Design Pattern Against Complexity

GOAP's originator Jeff Orkin discussed the challenge of combating complexity in his 2006 GDC talk and paper "Three States and a Plan: The A.I. of F.E.A.R." — as the number of actions grows, the planner's search space expands exponentially, and overly fine-grained action decomposition often produces illogical behavior sequences. Orkin proposed the concept of "Smart Objects" as a countermeasure, encapsulating environmental objects as entities that carry their own available actions.

Inspired by this, the developer created a base class called "Spatial Actions," merging actions like "walk toward object" and "interact with object" so any action requiring proximity to an object can inherit it. This is in the same spirit as Smart Objects: raising the abstraction level of actions to shrink the effective search space, using object-oriented inheritance instead of a flat action list to improve efficiency and reduce repetition.

Future Plans and Open Source

The developer notes that this Godot AI system is still being actively refined. Key items on the roadmap include:

Multithreading the planning process for better performance
Creating a visual debugger — debugging via plain text is extremely difficult and has been the single biggest time sink
Refactoring into a standard Godot plugin for easier community use, feedback, and contributions

On multithreading: migrating GOAP planning to a separate thread is standard practice for production-grade AI systems. When many AI agents in a scene trigger replanning simultaneously, synchronous execution on the main thread can easily cause frame rate stutters. The F.E.A.R. team had already implemented a similar approach on the Xbox 360's multi-core architecture, distributing planning computation to auxiliary cores while keeping the main thread focused on rendering and physics. Achieving this in Godot 4's multithreaded environment requires addressing read/write contention on world state (typically using an immutable snapshot mechanism), safe delivery of planning results back to the main thread (via a message queue), and priority scheduling of planning tasks.

The project plans to open up for testing and code contributions once published on GitHub. For indie developers pursuing simulation depth and emergent behavior, this extended GOAP framework offers a compelling technical direction: less manual design in exchange for richer, more flexible NPC AI behavior.