Phase 1 builds everything agents need before one can play: bots, the interface, the perception layer, headless matches, the recorder, ratings and the virtual clock.
Bots created per match#
When a match forms, the server creates bot characters with the right loadouts and seats an agent on each. The bots have no network connection; they are sessions inside the server, driven by the project's module. The research question was whether that needs changes to AzerothCore itself. It doesn't: everything bots need is reachable from a module, which keeps the server close to mainline.
One interface, two modes#
| In-process | Out-of-process | |
|---|---|---|
| Where the agent runs | Inside the server | A separate program on the same machine |
| How messages travel | An in-memory queue | A local socket |
| Parser, perception, validation, delays | The same code | The same code |
Only the pipe differs, so the two modes can't drift apart, and a conformance test checks it anyway. Out-of-process agents never get a game connection: a real client connection would carry exact positions and everything else the perception layer exists to hide.
Each observation is a full snapshot of what the agent knows plus the events since the last one, a few kilobytes in 2v2, so any message can be read on its own. Actions are validated and sent as ordinary client packets, so the server treats a bot exactly like a player.
The recorder#
Every match is kept, in a versioned format that future methods can read:
- each seat's full packet stream in both directions, stamped with game time: the ground truth;
- the observations and actions as sent;
- match events: connects, timeouts, faults, phase changes;
- a sealed log of the true game state, written only after the match ends and unreadable by any agent, used by the parity tests and by monitors that look for bugs.
The server's own dice aren't seeded, so a match can't be re-simulated. What can be replayed is every decision: feed a seat's recorded observations to the same agent version and it must choose the same actions. And every observation can be rebuilt from the packets, so a future perception layer can be run over old matches.
The virtual clock#
The virtual clock runs the real server faster than real time. Almost all of the server's game logic advances by each tick's elapsed time rather than by reading a clock, so the server can run on a lockstep clock: one fixed step of game time per tick, as fast as the CPU allows.
- Estimated speed: about 3 to 40 times real time per match, before the agents' own compute. Several arenas can run at once, up to the machine's cores. Measuring it is a Phase 1 exit criterion.
- Bots only. Movement in WotLK is client-authoritative: a human's client moves in its own time. So virtual-clock matches are bot-only, and humans play on a separate real-time server.
- A small patch. The loop and a handful of clock reads in combat code can't be reached from a module, so the clock is a small AzerothCore patch carried by the project, behind a switch that is off on the server humans play on.
Built so far#
| Part | State |
|---|---|
| Agent interface | Designed; the message format and its codec are built |
| Perception layer | Designed; its parameter file, rule table and information drops are built |
| Recorder | Designed; the record store and its index are built |
| Rating | Designed; the rating fit and the sequential test are built. See measurement |
| Bots per match, headless matches, virtual clock | Designed; next in the server queue |