Bridging the Gap: Using AI Planning to Assist Behavior Tree Authoring

TL;DR

Creating believable NPC behavior in modern games is a balancing act between narrative control and emergent complexity. This paper proposes a system that uses AI Planning to generate "plan traces"—abstracted sequences of actions—which designers then use as blueprints to build robust Behavior Trees (BTs). By mapping game components directly to an ontology, the system allows non-programmers to leverage advanced planning without writing complex symbolic logic.

The Authoring Tension: Complexity vs. Control

In the game industry, Behavior Trees are the "gold standard" because they offer better scalability than Finite State Machines. However, for designers (who are often not programmers), building a BT is a fragile process of trial and error.

The authors identify a major industry hurdle: Academic AI (like automated planners) requires a "world model" that is tedious to build. Meanwhile, Industry AI (Component-based systems) is great for performance but lacks the semantic depth for automated reasoning. This paper seeks to connect these two worlds.

Methodology: Components as Knowledge Sources

The breakthrough in this method is how it builds its "world view." Instead of a manual setup, it hooks into the Component-Based approach already used in commercial engines.

1. Blueprints to Ontology: Every entity (e.g., a Goblin) is defined by its components (e.g., MoveTo, MeleeAttack). The system maps these to a domain ontology.
2. Self-Describing Components: Each component is extended to provide a "symbolic description" (a planning operator). For example, a Take component knows it needs the attribute hasStrength to lift an object.
3. Plan Generalization: Using the DLPlan planner, the system doesn't just find a path to a goal; it generalizes it. Instead of "Pick up Sword A," it suggests "Pick up any Melee Weapon."

Figure 2: The interactive workflow between the designer, the planning ontology, and the resulting BT.

Case Study: The Greedy Goblin

To demonstrate, the authors simulate a goblin trying to steal a diamond.

• Scenario A (Empty Room): Planner suggests a simple "Walk and Take" sequence.
• Scenario B (Enemy Present): Planner offers two distinct strategies: "Charge at Enemy" (Melee) or "Take Cover and Shoot" (Ranged).

The designer takes these sequences and organizes them into the Priority and Sequence nodes of a Behavior Tree. This ensures that the NPC isn't just following a script, but has the logical branches to handle different world states (like finding a chair to hide behind).

Figure 5: The final Behavior Tree where different colored branches represent solutions discovered by the planner for different tactical scenarios.

Critical Analysis & Conclusion

This work provides a pragmatic middle ground for AI development. It respects the Designer-in-the-Loop philosophy—the planner doesn't build the game, it suggests strategies.

Key Takeaways:

• Abstraction is Power: By using ontologies, the system moves from "specific plans" to "general strategies," making the AI much more adaptable.
• Reduced Debugging: Because the planner validates the logic (e.g., "you can't take this if you aren't strong enough"), the resulting BTs are inherently more robust.

Limitations & Future Work:

The current process still requires manual integration of plans into the BT editor. Future work aims to semi-automate this translation and provide better debugging tools so designers can ask the planner: "Why didn't you suggest sneaking here?"

This research marks a significant step toward "Design-Assistive AI," where the machine handles the combinatorial explosion of logic, leaving the creative storytelling to the humans.