Game Execution

AlfredStar's architecture separates strategic planning from game execution. While strategic agents focus on high-level decisions—what to build, when to attack, how to respond to threats—they need a reliable foundation to translate these decisions into precise game actions. This is where the game execution layer operates.

When a strategic agent decides to build two Stalkers, the game execution layer determines all prerequisites, calculates optimal timing, and manages the execution sequence. It transforms abstract goals into concrete, executable operations that respect all game constraints and dependencies.

The Routine Abstraction

The game execution layer operates through "routines"—units of work that can represent tasks at any level of granularity. A routine can be as simple as "build one Probe" or as complex as "execute a two-base all-in attack."

Complex routines decompose into simpler routines, which may further decompose, until reaching atomic operations—single, indivisible game commands like "select unit" or "issue build command." This recursive nature is powerful: it means the routine-based system can theoretically handle any task that can be expressed in the game. This universality makes routines the natural abstraction for execution.

A routine encapsulates:

  • Conditions that must be satisfied before execution
  • The work to be performed
  • Observable criteria for completion
  • Dependencies on other routines

The dependencies between routines form a directed graph that determines execution order. This graph structure, combined with the recursive nature of routines, enables the system to handle arbitrary complexity while maintaining clear execution semantics.

From Routines to Game Commands

Routines serve as an abstraction layer for asynchronous tasks, bridging strategic intent with actual game actions. This translation happens at two levels:

Simple routines map directly to individual game commands. A "Build Probe" routine translates to a single game action: selecting a Nexus and issuing a build command. The routine monitors the game state until the Probe appears, then marks itself complete.

Composite routines decompose into multiple subroutines, which eventually map to sequences of game actions. A "Fast Expand" routine might decompose into: "Build Probe" → "Send Probe to expansion" → "Build Nexus" → "Build Pylon" → "Return Probe to mining". Each subroutine handles its own game commands while the parent routine coordinates the overall sequence.

This abstraction allows the system to handle any asynchronous task—from individual unit production to complex multi-step strategies—while maintaining consistent interfaces for monitoring, cancellation, and error handling.

Two Main Components

The game execution layer operates through two main components that work together to transform strategic decisions into game actions:

  • Routine Generator - Analyzes strategic requirements and current game state to create a dependency-optimized execution plan
  • Action Coordinator - Manages real-time execution of routines, handling scheduling, monitoring, and adaptation to changing conditions

This separation allows the system to plan optimally while remaining responsive to dynamic game events.

Routine Generator

The routine generator takes two inputs: a target build specification and a game state snapshot. The snapshot provides the starting context—what buildings exist, current resources, available units, and ongoing production. From this baseline, the routine generator projects forward to determine what additional routines are needed, calculating dependencies and optimal timings.

Target Build Specification

Target: 1 Zealot, 2 Stalkers, 1 Gateway
Starting state: 1 Nexus, 12/15 supply

The supply notation represents population capacity—12 units currently exist out of 15 maximum allowed by current Pylon infrastructure. Strategic agents can omit production capacity if not relevant:

Target: 1 Zealot, 2 Stalkers

Or specify for faster production:

Target: 6 Zealots, 3 Gateways

The routine generator infers all other dependencies (Pylons, Cybernetics Core, Assimilator) automatically if not explicitly mentioned.

Enhanced Dependency Graph

The routine generator constructs a dependency graph based on unit/building relationships, then enhances it with virtual nodes—abstract dependencies representing resource availability—to capture resource needs:

  • "50 gas available" for Stalker production
  • "Supply capacity for 2 units" for unit production

This leads to precise timing decisions—e.g., when to build Assimilator for just-in-time gas at T+100s.

Critical Path Analysis

Using Critical Path Method (CPM)—a project management algorithm for scheduling tasks with dependencies—the routine generator calculates timing windows for each routine:

  • Earliest Start: When dependencies first allow execution
  • Optimal Start: With safety buffer
  • Latest Start: Latest time before delaying downstream routines

The output is a set of routines with start/end conditions and flexible timing windows, ready to be dispatched by the action coordinator.

Action Coordinator

The action coordinator serves as the runtime layer—an OS-like manager of routine execution. It:

  • Schedules routines
  • Monitors live game state
  • Executes routines in parallel when possible
  • Adjusts based on real-time events

This division of responsibility—generation (forward-looking) vs execution (reactive)—keeps the system robust and responsive.

Asynchronous Parallel Execution

The action coordinator frequently checks to evaluate routine readiness (dependencies, resources, production capacity). Independent routines (e.g., Probes, Pylons, upgrades) can run simultaneously.

If a building is destroyed or resources reallocated, dependent routines pause until recovery. This allows dynamic adaptability without full replanning.

Routine Tracking and Feedback

The coordinator tracks every routine's lifecycle and reports:

  • Status: waiting, executing, completed, failed
  • Completion events: which routines finished and when
  • Failure reasons: e.g., destroyed buildings, unrecoverable resource shortages

This feedback informs strategic agents—allowing them to replan, accelerate, or modify strategies based on real-time progress.

Example: Zealot and Stalkers

Input:
Target: 1 Zealot, 2 Stalkers
Current: 1 Nexus, 12/15 supply, basic economy

Dependency Inference:

  • Zealot: Gateway, Pylon
  • Stalker: Gateway, Cybernetics Core, Pylon, Assimilator

Enhanced Dependency Graph:

zealot_0
    ├── gateway_0
    └── pylon_0

stalker_0, stalker_1
    ├── gateway_0
    ├── cybernetics_core_0
    │   └── gateway_0
    ├── pylon_0
    └── "100 gas available"
        └── assimilator_0

Critical Path: Pylon → Gateway → Cyber Core → Stalkers

Parallel: Assimilator starts at T+43s for just-in-time gas

Execution Timeline:

T+0s:   Pylon started (ETA: 18s)
T+18s:  Gateway started (ETA: 64s)
T+43s:  Assimilator started (ETA: 64s)
T+64s:  Cybernetics Core started (ETA: 100s)
T+100s: Zealot complete, Stalker_0 started (ETA: 132s)
T+132s: All units complete

Foundation for Strategic Intelligence

The game execution layer provides the reliable foundation upon which AlfredStar's strategic intelligence operates. By handling the mechanical complexity of game execution—dependency resolution, timing optimization, resource management—it allows strategic agents to focus on higher-level reasoning.

Strategic agents can issue commands knowing they will be executed optimally and receive detailed feedback about progress and failures. This enables a feedback loop: agents plan strategies, monitor execution through routine completion events, and adjust their plans based on real-world outcomes. Whether adapting to unexpected enemy actions or optimizing build orders through experience, the execution layer provides the stable interface that enables the strategic intelligence described in our design principles.

Follow @alfredqy for updates