AI Layers and Behavior

The Zero Hour source tree does not contain one monolithic AI that decides everything from economy to projectile aim. Its AI is layered across strategic player logic, group-level organization, pathfinding, object-specific update modules, guard and retaliation behavior, and script-driven mission logic. This division is visible in GameLogic/AI, whose files include AISkirmishPlayer.cpp, AIPlayer.cpp, AIGroup.cpp, AIPathfind.cpp, AIStates.cpp, AIGuard.cpp, and AIGuardRetaliate.cpp.

Strategic, operational, and local decisions

A skirmish player addresses high-level concerns such as production, resource allocation, force composition, and attack timing. Groups organize collections of units around a shared operational purpose. Pathfinding answers how a movement request is routed through the map. Per-object states and guard behaviors answer local tactical questions, including whether a unit should hold position, acquire a target, retaliate, or return to a previous activity. These are different questions with different state and timing requirements, and conflating them produces misleading explanations of RTS behavior.

AISkirmishPlayer.cpp belongs in a trace of computer-player strategy, whereas AIStates.cpp and guard files belong in a trace of local unit decision-making. AIPathfind.cpp is not a strategy planner. It is part of the spatial mechanism through which a selected movement or attack intent becomes a route.

The relationship can be treated as a descending refinement of intent:

$$ \text{strategy} \rightarrow \text{group objective} \rightarrow \text{unit order} \rightarrow \text{path and local state}. $$

An attack decision at the strategic layer does not move a tank directly. It establishes or activates an operational intent. A group organizes participating units. Each object then receives or derives work compatible with its own state and locomotion. This prevents the misleading claim that a single class “makes the AI attack.”

strategic player:
    evaluate economy, production, composition, and available plans
    choose or activate an objective

group and object layers:
    organize eligible units
    establish orders and paths
    let individual state machines acquire, guard, fire, or recover

The pseudocode describes responsibility rather than a literal update implementation. The actual cadence and predicates should be read in the active controller and behavior classes for the mode being studied.

Production is an eligibility pipeline

Construction and unit production are especially easy to oversimplify. A strategic desire does not by itself create an object. It must pass conditions such as available construction capacity, prerequisites, affordability, power or economy conditions, rebuild delays, production limits, and legal placement. A useful abstract predicate is:

$$ \operatorname{CanProduce}(x) = P(x)\land R(x)\land A(x)\land L(x), $$

where P represents prerequisite satisfaction, R resource availability, A actor or facility availability, and L legal placement or queue conditions. The precise conditions vary by object and mode, but the pipeline establishes why a desired build can fail without disproving the strategic choice.

When examining a build order, distinguish authored priorities and templates from the engine mechanisms that validate queues, prerequisites, placement, and object creation. The former explains why a computer player wants something; the latter explains how that request is made legal.

Scripts are another layer

Campaign behavior adds the script engine under GameLogic/ScriptEngine. ScriptEngine.cpp, ScriptActions.cpp, ScriptConditions.cpp, and Scripts.cpp are essential whenever a scenario appears to violate ordinary skirmish rules. A scripted attack can activate a prepared group, create objects, change alliances, or trigger a victory condition without implying that every AI player follows the same policy automatically.

Scripts therefore bridge authored scenario intent to game actions. The correct trace is not to search for a universal combat threshold, but to identify the campaign condition, action, or team activation that links scenario state to the attack behavior. A scripted success or failure response can adjust authored priorities, but that is an adaptive rule, not machine learning.

A repeatable behavior trace

The scope of a behavior should be established before reading implementation:

Observed behavior
    -> campaign-only? inspect ScriptEngine conditions and actions
    -> computer-player plan? inspect AISkirmishPlayer and AIPlayer
    -> unit collection? inspect AIGroup
    -> route choice? inspect AIPathfind
    -> target or stance reaction? inspect AIStates, AIGuard, and retaliation

The correct way to study a behavior is to identify its scope before reading implementation: player-level strategy, group orchestration, local tactical state, spatial routing, or authored mission script. The source tree already encodes this distinction.