Author: Anthony Halstead

Date: 10/10/25

The   Dilemma:   Choosing the Right   Decision   Model

At the beginning of development for Iron Reclamation, there were several responsibilities and systems I had to consider before even touching the keyboard. I was working in an engine I wasn’t entirely familiar with and building systems for a genre I had never developed before; a real-time strategy game.

The first major challenge came early: deciding what kind of AI decision model could support the complexity I envisioned. I wanted factions that could make strategic, world-level decisions, expanding territory, managing resources, and responding to player actions, while individual units still behaved intelligently and reactively in combat.
I dove into the usual suspects: finite state machines, behavior trees, GOAP (Goal-Oriented Action Planning), and Utility AI.

 Each had strengths and trade-offs. State machines were easy to reason about but scaled poorly. GOAP offered flexibility but was heavy for real-time execution across hundreds of agents. Behavior trees had strong structure but limited adaptability. Utility AI was elegant for prioritization but lacked an inherent hierarchy.

It became clear that no single model would handle the entire spectrum of decision-making cleanly. The global faction AI needed to think, weighing priorities and making trade-offs, while individual units needed to act quickly and predictably.

That realization led me to a hybrid architecture:

• Utility AI at the faction level to manage strategic goals such as expansion, defense, and resource optimization.
• Behavior trees at the unit level to drive responsive, moment-to-moment decisions like targeting, movement, and combat reactions.

This combination provided both high-level intelligence and low-level reactivity; strategic intent with tactical clarity.

Extensible   Design

Once the architecture was conceptually solid, the next challenge was keeping it maintainable. I knew from experience that large AI systems tend to collapse under their own weight if not designed carefully.

To prevent that, I focused on composition over inheritance, allowing behaviors and decision logic to be built as independent, reusable modules. For the goals themselves, I used the Strategy pattern, letting each goal encapsulate its evaluation and execution strategy while adhering to a common interface. This made it easy to plug in new global objectives without rewriting core systems.

Building generation, another key aspect of faction decision-making, was implemented with the Factory pattern. Each building type could define its own spawn rules and dependencies, while the factory managed instantiation, ensuring that adding new structures didn’t require hard-coded logic scattered across the project.

These patterns collectively allowed the AI system to evolve. As the project grew, I could introduce new units, goals, or behaviors without needing to restructure the core decision model.

Looking Back

What started as a problem of “Which AI model should I use?” turned into an exploration of how to think about systems holistically. The best solution wasn’t about picking a single paradigm but about combining complementary ones, each solving a different layer of complexity.

In the end, this hybrid architecture not only met my technical goals but also gave me a better understanding of scalable AI design:
Build flexible systems, not rigid hierarchies. Favor composition. Let patterns do the heavy lifting.   

Moving forward, there's still plenty of programming ahead. I'll be expanding the goal set, refining the Utility AI's evaluation logic, and introducing new layers of context for better decision-making. As more units and buildings enter the game, each will help stress-test the system and reveal where it can grow stronger.