Mat Zaga

generals.io is a two-player, real-time strategy game where you can't see most of the board. The competition version lets you build castles and gives you 150 ms per move on one CPU core. I started from a published self-play recipe and changed what the network sees, where its games start, how it was pushed to try castles, and how progress was measured.

Below: the training loop, then the improvements. Each letter is an improvement made at that step.

• 38 standard layers: armies, ownership, fog, move history.
• +11 derived layers: five threat maps — how soon an enemy force can reach each cell, how much could arrive, how far your own general is — computed in one pass; countdowns to the turn-800 and turn-1200 rule changes, which the raw turn counter can't resolve in half-precision.
• Castle price per cell, taken from the game's own cost function — the net sees exactly what it will be charged.
• Its own belief fed back: a dedicated head predicts where the hidden enemy general is; last turn's answer is an input this turn, so the network keeps updating a posterior instead of guessing from scratch.
• An early plan had the net predict incoming threat as an output. Threat is computable from the board, so it became an input instead — don't ask a model to guess what you can calculate.

• I watched the bot's games, spotted its recurring mistakes, wrote each as a formal rule, and mined 284k real games for matching moments — about 20,000 positions across six situation types. E.g.: a castle built then lost within 50 turns; a 20-stack two squares from the enemy general but four by path; land grabbed behind you after first contact; the bot's own win-prediction flipping against the actual outcome and never recovering.
• Half of all training games start 10 turns before such a moment. A once-in-a-thousand-games decision becomes one the bot faces hundreds of times, with whichever choice wins more getting reinforced — that is what pushes it to choose differently.

• A fresh agent never builds by default — castles cost a lot of army up front and pay back too slowly for it to discover the value — and a naive per-castle bonus makes it build everywhere.
• So I pushed the model to try the build action more often without over-rewarding it, and let it learn from the outcomes: a small material bonus shaped so it cancels out over a whole game (potential-based shaping, Ng, Harada & Russell 1999) plus a forced build on a fraction of turns.
• The forced tries only fire where formal rules say a castle makes sense: it repays its cost before the turn-1200 cutoff, leaves army behind to hold it, no enemy force can reach it in time, nothing unseen is within 3 squares. Once the network's own urge to build there passes 25%, the push switches itself off.

• The learning rate — how far the weights move per update — should shrink as training matures, down to a settling phase at the very end. I grandfathered the recipe's decay schedule, written for one continuous run, without re-basing it when resuming across legs.
• By the last leg the rate had decayed ~4× below where a still-learning net wants it, while total training volume sat at ~10% of the top competitors'. Small steps on a small budget read as a plateau. The fix is two lines: reset the clock at each resume.

• No access to the judges' machine, so latency was measured single-core on a laptop and calibrated against the live bot (×2.2 overhead factor). The 7M network takes ~7 ms a move, the 11M one ~10 ms.
• A harness around the network adds ~2 ms: two-view ensembling (board + its rotation), sampling among near-tied moves, a loop-breaker, a mate-in-one check, a doomed-castle veto — worth an estimated +10–20 rating points.
• The obvious use for the remaining ~130 ms is search: a 2-ply lookahead over the top 8 moves would fit. It needs a value head precise enough to rank sibling moves; mine was improving but, with the D mistake and the budget, never got there.

• Every snapshot plays a fixed roster of opponents — earlier snapshots plus outside reference bots — each map twice with sides swapped so luck cancels. Games go to members the bot still loses to; anyone beaten past 85% is retired, because beyond that a win rate carries no information.
• Ship decisions use a sequential test that stops as soon as the evidence is decisive — one release cleared in 14 games.
• All ~30,000 test games ran on a laptop, not the rented GPU, on a batched runner 66× faster than the reference one. Testing had been eating 19% of every paid GPU second.

• Self-play, where “self” is half a mirror of the current network and half a pool of 15 frozen past versions, drawn in proportion to how often they still win; anything beaten >90% gets zero games.
• I logged which opponents were actually drawn and found the weighting running backwards — favouring the already-beaten — for the first 1,700 steps. Fixed on the spot.

• The game's rules changed mid-corpus: 200k games under the new rules, 212k under the old. Filtering to strong, current games would have discarded ~80%. Instead, each game's player skill and rule version were fed to the network as inputs, so it learns “this is how a 2,400-rated player behaves under the old rules”.
• The test was fixed in advance: a model trained on the full messy corpus had to match one trained on hand-curated data. It did, within the noise. Every position was also used in all 8 board symmetries, and train/test were split by map rather than by game, so a map seen in training could never appear in testing.

• Goal: a bigger network that starts exactly as strong as the 7M one. Training a fresh 11M network to imitate the 7M one failed — after 48k steps the copy still lost 98% of games to the original.
• Instead, Net2Net-style growth (Chen, Goodfellow & Shlens, 2016): copy every existing weight into a deeper network and insert four new layers initialised to output zero. Day one it plays identically to the original — 49% head-to-head, untrained — and the new layers can only add. Depth over width per Straka & Schmid 2026.

• ~$41 of GPU behind the shipped version, against $1,000+ for the 3rd-place bot. Rule: paid GPUs only ever train.
• Everything else offloaded: all 30k test games to a laptop (19% of paid seconds reclaimed); the 11M distillation — a job with no rating gain by design — to free Colab A100 credits; vast.ai instead of RunPod at 1.63× less per training step.
• Watchdogs with balance floors that stop the box automatically, but only after a checksummed copy of the checkpoint is confirmed in the cloud.

• Imitation copies of the top ladder bots, trained on their public games, as measurement anchors — admitted only if they scored 30–70% against my bot. One passed; the rest were data-starved.
• Exploiter bots trained to beat my champion: four attempts, all collapsed within ~100 steps. Diagnosed after: each had been started from the champion's own weights.
• Search at inference: gated on value-head precision; never opened (see E).
• Seven extra harness rules over ~20k paired games: none beat the shipped set once replicated on fresh maps.
• Masking the “pass” move (the bot passed 5% of turns vs 1.4% for elite players): −25 rating points. Left unmasked.

Continuous calorie counter

Sublet finder