Smarter Game AI with Infinite Axis Utility Systems

Game AI has evolved through several design patterns: Finite State Machines (FSMs), Behavior Trees (BTs), and Planning systems. Each has strengths, but also limitations. FSMs risk lock-in if an exit condition is missed, while BTs can grow unwieldy as branches multiply.

Utility Systems offer another path — one that balances flexibility, scalability, and performance. Infinite Axis Utility Systems (IAUS) extend this approach by allowing actions to be scored across multiple considerations, or “axis.” The result is AI that feels responsive and adaptive, without being brittle.

I first came across this solution in 2013, and I immediately liked its simplicity and efficiency. A few years later, I had the opportunity to put it into practice while creating the AI for Settlers of Catan (digital version for Andriod). Even with just a spreadsheet model, the system produced believable play and allowed me to experiment quickly with different behaviors. More recently, goap showed how Utility Systems can reorder objectives dynamically, prioritizing urgent goals without rewriting plans.

At a larger scale, Guild Wars 2 proved that Utility Systems could power an MMO’s combat AI efficiently, handling hundreds of NPCs simultaneously while remaining lightweight and scalable.

Inputs (Normalized 0–1)

Every Utility System begins with inputs, raw game data normalized into a clean [0–1] range. This allows very different values to be compared on equal footing.

• Simple examples:

  • Health at 25/100 = 0.25

  • Ammo in gun at 15/30 = 0.5

  • Cooldown timer at 9s of 10 = 0.9

• Complex examples:

  • Composite values like “cover quality” (line of sight, exposure, distance to allies).

  • Non-linear preferences, such as distance where too close and too far are both bad, but mid-range is ideal.

By always working in [0–1], Utility Systems keep decision-making predictable and comparable across many inputs.

Axis (Considerations)

Each action is made up of one or more axis.

• An axis = one input + one curve type + four parameters.

• This transforms the input into a score, expressing how valuable that input is for this specific action.

• Example:

  • Shoot action, Ammo axis: if ammo = 0 → score = 0.

  • Reload action, Ammo axis: if ammo = 0 → score = 1 (perfect time to reload).

Axis make the system context-aware. The same input can mean very different things depending on which action it’s applied to.

As we discussed in AI planning, this makes Utility Systems a powerful complement to planners, adding dynamic scoring without rigid logic.

Curve Types & Parameters

Each axis uses a curve to transform its input. These curves are defined by a small set of parameters and, in some cases, a numerical constant.

Parameters (tunable by designers)

• m – slope or width (steepness/spread of the curve)

• k – exponent or vertical scale (depends on curve type)

• b – vertical shift (baseline)

• c – horizontal shift (offset or center point)

Constant (technical, not designer-facing)

• e (epsilon) – a very small value (e.g., 10−610^{-6}10−6) used only to prevent division by zero in formulas. This is not an input to design, but a safeguard in implementation.

Common Curve Types:

• Linear (straight line)

  • Use Case: Inputs that scale directly (e.g., “More ammo in gun = better”).

  • Formula:

• • Here, k = 1

• Quadratic (parabolic)

  • Use Case: When mid-values are best (e.g., “Best distance is mid-range”).

  • Formula:

• • With $k=2$ you get a parabola, higher exponents create sharper curves.

• Logistic (S-shaped)

  • Use Case: Threshold behaviors (e.g., “Healing is mostly irrelevant until health drops below 50%, then urgency spikes”).
  • Formula:

• Logit (inverse S-shaped)

  • Use Case: Diminishing returns (e.g., “Each additional ally helps less than the last”).

  • Formula:

• • Here, e ensures stability near the edges of x = 0 and x = 1

• Gaussian (bell curve)

  • Use Case: Sweet spots, where one range of values is best (e.g., “Optimal combat distance is around 10m, too close or too far is worse”).

  • Formula:

These curves let designers encode intent directly into the math, without scripting rigid rules. You’ll see them clearly when plotted, linear rising straight, quadratic peaking, logistic ramping, logit flattening.

Atomic Actions

Actions should be atomic, the smallest meaningful unit of behavior. Examples:

• Shoot

• Reload

• Retreat

• Move-to-position

Keeping actions small avoids the pitfalls of FSM lock-in and BT branching explosions. Complex behavior then emerges naturally: “Move-to-cover” followed by “Reload” isn’t scripted, it just results from the scores aligning.

Combining Axis Scores

Once axis are scored, they must be combined.

• Naïve multiplication: multiply all scores together.

  • Problem: since all values are [0–1], adding more axis drags scores lower, unfairly penalizing complex actions.

• Geometric Mean (fix):

  • Formula:

  • Fairly balances axis no matter how many there are.

  • If any axis = 0, final score = 0 (the zero rule).

This optimization was highlighted by Rez Graham at GDC 2018 “The Simplest Trick in the Book”.

Weights (Multipliers)

After computing the geometric mean, actions are adjusted by a weight multiplier. These weights are not just numbers, they represent the type of action in terms of urgency or importance.

• 1 = Normal action

  • Everyday behaviors like “Patrol,” or “Idle.”

• 2–3 = Important action

  • Behaviors that carry more weight, like “Defend Ally” or “Use Special Skill.”

• 5 = Emergency action

  • Critical behaviors that must override normal ones, such as “Retreat” when health is low or “Dodge” to avoid a lethal attack.

Example

• Attack: GM = 0.6, Weight = 2 → Score = 1.2

• Reload: GM = 0.9, Weight = 1 → Score = 0.9

• Retreat: GM = 0.4, Weight = 5 → Score = 2.0

Even though Reload had the highest GM, Retreat wins because it’s marked as an emergency action.

Why It Matters

• Design clarity → weights give a clear way to express urgency without needing to retune every curve.

• Emergent prioritization → the system naturally shifts toward the most urgent actions without hard-coded overrides.

• Scalability → weights can define categories of action (normal, important, emergency) that work across many AI agents.

Performance Optimizations

Utility Systems are lightweight by design, but you can make them even faster with a few tricks:

• Early exit on zero

  • If any axis = 0, stop evaluating that action immediately.

• Weight-ordered evaluation

  • Start with higher-weight actions first.

  • If they already produce strong scores, prune weaker candidates early.

• Memorization tables

  • Cache reusable values (ammo, cooldowns, distance).

  • Recompute once per decision cycle.

• Axis evaluation order

  • Check cheap axis first (ammo, cooldown, distance ratios).

  • Leave expensive checks like Line of Sight for last.

  • If a cheap axis already scores 0, you avoid costly operations entirely.

These optimizations don’t change outcomes, but they keep the system efficient at scale.

Tooling Needs

For indie projects, a simple spreadsheet can be enough, rows for actions, columns for axis, formulas for scores. That’s exactly how I prototyped Catan AI.

But as projects grow into AA and AAA scale, spreadsheets quickly fall short. At that level, teams need proper data-driven tools:

• Real-time visualization of scores.

• Debugging overlays.

• Simulation runs for tuning behaviors.

These aren’t luxuries. They’re essential for iteration speed and collaboration between programmers and designers. The challenge is that building these tools requires significant investment.

That’s where a Project Manager or Product Owner comes in. Their role is to weigh the value of faster iteration and clearer debugging against the cost of building or buying the right tools. In other words, deciding whether to build designer-friendly AI tooling depends directly on project scope, budget, and timeline, the kind of strategic call we covered in guidance for Project Managers or Product Owners.

Conclusion

Infinite Axis Utility Systems bring clarity, scalability, and emergent decision-making to Game AI. They start simply, normalized inputs, atomic actions, a few curve types, but can scale all the way to MMO combat without breaking performance.

From my experience on Catan to seeing how larger studios deploy them, Utility Systems prove that good design and math can unlock powerful, believable AI.

If you want to explore how Utility AI could make your game more adaptive and scalable, check out our Game AI consulting services. We help studios design, implement, and optimize AI systems like Utility AI, GOAP, and more, ensuring your technology empowers both your team and your players.

FAQ: Infinite Axis Utility Systems (IAUS)

How is a Utility System different from a Finite State Machine (FSM) or Behavior Tree (BT)?
FSMs can get stuck if exit conditions are missed, and BTs often explode in complexity as you add more branches. Utility Systems avoid both problems by scoring actions continuously, the AI can always switch to the highest-value option without extra branching logic.

What does “Infinite Axis” mean in IAUS?
It means there’s no hard limit to the number of considerations (axis) you can add to an action. Each axis is an independent input + curve, and they can be combined as needed. The system remains flexible and scalable, whether an action has two considerations or twenty.

Do I need advanced math to implement this?
Not really. Inputs are normalized between [0–1], curves are shaped with four parameters (m, k, b, c), and the geometric mean balances the scores. The math is lightweight, the complexity is more about tooling and design intent than heavy computation.

Isn’t this too expensive to compute at runtime?
Utility Systems are very efficient. With optimizations like memoization tables, early exits on zero, weight-ordered evaluation, and ordering cheap axis first (leaving expensive ones like Line of Sight last), the runtime cost stays low, even at scale.

How do weights actually work in practice?
Weights categorize urgency. Normal actions might have a weight of 1, while emergency actions (like “Retreat” or “Dodge”) could be 5. This ensures critical actions surface naturally, without hard-coding overrides.

Can indie studios really use this without building custom tools?
Yes. You can start with a simple spreadsheet model, that’s how I first prototyped Catan. But as projects grow, data-driven tools with real-time visualization, overlays, and simulation runs become essential for speed and collaboration.

When should a team invest in Utility Systems?
They’re lightweight at runtime, but require investment in design and tooling. That decision should be made by a Project Manager or Product Owner who can weigh the value (faster iteration, stronger AI behaviors) against the cost of building the right tools.