Sidebar Menu

Projects

  • Dashboard
  • Research Project
  • Milestones
  • Repository
  • Tasks
  • Time Tracking
  • Designs
  • Forum
  • Users
  • Activities

Login

  • Login
  • Webmail
  • Admin
  • Downloads
  • Research

Twitter

Posts by stumathews
Stuart Mathews
  • Home
  • Blog
  • Code
  • Running
  • Gaming
  • Research
  • About
    • Portfolio
    • Info

Utility Systems

Details
Category: Game Development
By Stuart Mathews
Stuart Mathews
06.Sep
Parent Category: Code
06 September 2026
Last Updated: 06 September 2026
Hits: 53
  • Game development
  • Behavioral Adaptation

FSMs, Behavior Trees and HTNs produce degrees of adaptive decision-making and planning without any explicit quantification of priority of individual behviors. While Behavior Trees can implicitly allow for emulating priority by ordering of its higher priority behaviors to run before other lower ones (and using active-selectors), this however is static predefined order that does not varying to simulate changing priorities.

Utility systems however allow for candidate actions to be valued, measured and compared by giving them relative action-values (utility scores) that represents a notion of priority or action-desirability. Crucially, these values can vary over time depending on circumstance, and therefore can model adaptive prioritisation of situational behavior.

The general concept is that all possible actions are evaluated and the top scoring action is selected. This methodology is however most often used in evaluating the utility of goals, which then drive the execution of plans in Behavior Trees, GOAP and HTNs to run behaviors/actions to solve those goals.

A key aspect of utility systems is that single utility values can be composed of multiple independant decision factors that contribute to the overall utility that are derived from situational characteristics and context. Typically these are normalized values between and including 0 and 1 with high utility/desirability tending towards 1.

This means a utility score can then be composed of multiple influencing factors (decision factors) that augment the overall utility and therefore influence selection of the goal/behavior. These factors can themselves also be weighted to dampen or improve their influence in the overall utility score:

\[ Utility = w_1 \cdot Safety + w_2 \cdot Efficiency + w_3 \cdot Comfort \tag{Weighted decision factors} \]

Combining dynamic selection of goals based on evolving priorities using utility ststems, and coupled with structured but adaptive planning constructs in Behavior Trees and HTNs provides the blueprint for the flexible, adaptive and semi-autonomous behavior found in most games.

 

Heirachial Task Networks

Details
Category: Game Development
By Stuart Mathews
Stuart Mathews
06.Sep
Parent Category: Code
06 September 2026
Last Updated: 06 September 2026
Hits: 48
  • Game development
  • Behavioral Adaptation

Heirachial Task Networks (HTNs) have long been favoured over more emergent and fully autonomous methods such as GOAP for its ability to apply a more deterministic approach to planning such that it achieves coordinated autonomy but with elements that can vary (in well-defined ways), over approaches such as GOAP that organically behave in whatever way allows a target goal to be solved. Indeed, it could be considered that the extensive autonomy of LLMs is what causes them to be as variable and unpredicatable as they are.

HTNs are composed, as the name suggests, of a heirachy of tasks which decompose the problem to solve. Primative tasks form the leaf nodes in a similar fashion to action nodes in Behavior Trees, and correspondingly they perform actions/tasks which modify the environment during execution.

Like Behavior Trees an aggregate node called a compound task can be composed of multiple nodes forming a subtree. The composition, heirachy and conditional selection of tasks establishes a variable plan but remains within the confines of the expected intention of an overal predefined plan.

HTNs

A key aspect in HTNs is the conditional selection of a sub-tree (often called the method) within the compound task. Methods can be chosen based on the situation the agent is experiencing. This means diffirent selections of the sub-tree (methods) can execute depending on the sitation, providing a variation of the plan based on the situation. The tasks that make up the sub-trees are added to plan which is then carried out.

These algorithms allow for the execution of pre-built plans with internal component variability. This means plans are created with pre-defined alterative methods that can be activated/deactivated such that the enviorment’s circumstances can trigger a specific ways the plan it carried out in various circumstances. The overall plan however remains the same - only its specific method selection varies.

 

Goal-Oriented Action Planning

Details
Category: Game Development
By Stuart Mathews
Stuart Mathews
06.Sep
Parent Category: Code
06 September 2026
Last Updated: 06 September 2026
Hits: 57
  • Game development
  • Software Architecture
  • Behavioral Adaptation

While FSMs and Behavior Trees are used to create predefined and static plans with adaptive behavior, the most intuitive autonomous planning algorithm is GOAP (Goal-Orientated Action Planning) which seeks to create dynamic plans that resolve goal requirements at runtime by performing actions that achieve those goals, often by calculating and combining various actions that are defined by their effects on environment to bring about the changes that goals are dependant on.

This produces fully autonomous plans that are dynamically constructed from behaviours (actions) that solve selected goals:

As illustrated, predefined behaviours are defined by their preconditions (for being able to run), and the effects each has on the environment. Goals are defined by a static, predesigned combination of required effects, and the algorithm calculates and selects the actions that can bring about those required effects, and this constitutes the emergent plan of actions to perform to solve the goal.

GOAP is amongst the most dynamic, emergent and flexible methods of planning; however, while GOAP appears to be the panacea of Autonomy and independent behaviour, it can create emergent and creative behaviours that reach beyond the expectations of the game, making it difficult to reason about, debug and reproduce. This becomes a complexity scaling problem when more behaviours are inevitably required. The approach is, however, easy to understand and can be used in simpler scenarios where combinations of small core behaviours can still be managed.

More Articles …

  1. Unit testing networking code
  2. 64-Bit Mazers
  3. Functional XML
  4. So far, it works
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10

Page 1 of 10

Blog RSS Feed