SpecTactics / μSC2 / Augur · StarCraft II
StarCraft II agents
Three projects exploring StarCraft II bots: scripted strategy, learned action policies, and training from replays.
Agent decision loop
- 01 / InputObserve
- 02 / PolicyDecide
- 03 / OutputAct
Three ways to build a bot
StarCraft II combines economy management, unit control, and an opponent you can’t fully see. I use it to work on the code that runs an agent and the decisions that agent makes.
SpecTactics is a scripted Zerg bot with separate world-state, tactics, strategy, and runtime layers. μSC2 (MuBot) explores a compact learned policy. Augur focuses on replay-based training within a consumer-GPU budget. They’re separate implementations, each testing a different approach.
| Project | Approach | Central question |
|---|---|---|
| SpecTactics | Explicit strategy and tactics | Can the decisions survive a real game? |
| μSC2 / MuBot | Compact learned action policy | How should the policy represent a player’s choices? |
| Augur | Replay-based learning experiments | What can a replay-trained policy learn? |
Fixing stale-state distance queries
SpecTactics remembers enemy units after they leave vision. A bug appeared when those remembered units reached the game library’s distance function: it could use a distance matrix rebuilt for the current frame, while the remembered unit still held an index from an older frame.
The result could be an error or a believable distance to the wrong unit. I changed those queries to use positions instead of stale unit indexes.
The test double had hidden the bug by always calculating distances geometrically. I updated it to reproduce the library’s stale-object behavior so the test could catch the actual failure.
Choosing a unit, ability, and target
In μSC2, each action depends on several choices: which unit acts, which ability it uses, and what it targets. The policy conditions later choices on earlier ones so those decisions fit together.
I also separated resource-spending actions from movement and combat commands. Otherwise, the more frequent commands can dominate training and leave production decisions underrepresented.
Another issue was mismatched ability IDs between recorded demonstrations and the abilities available at runtime. Normalizing both to a generic ability identity stopped valid training labels from being discarded.
Evaluating actor selection
In an Augur experiment recorded on September 8, 2026, a rule redirected some actor selections toward units capable of production when resources were available.
It improved the production-command check but reduced broader ability accuracy beyond the experiment’s allowed margin, so I rejected it. The rule activated too often: being able to afford production didn’t mean production was the right move.
This was an offline check on a reused development holdout, with no full games played. It measured command predictions, not playing strength.
Current work
The work includes bot runtimes, learned policies, replay preparation, and evaluation tools. SpecTactics uses fixed opponents and an identified suite in the AI Arena environment to compare behavior.
I’m still investigating how well the offline measurements predict complete-game outcomes. Correct commands and better local scores are useful checks, but I need game results to establish whether a change makes the bot stronger.
Project notes · September 2026