when does the bot get to build the army it wants?

Watching your Bot lose sucks, even more in public. I saw it play on LaughNGamez’s channel the other day. The opponent went air. My bot stuck to the exact army it decided on before the game even started, stared at a sky full of flyers, and just kept building ground units.

The first instinct is bolting on an air counter. You sit down to write it, and this sets off an arms race. You code a rule for that specific unit, at that specific timing, in that specific matchup. The next game exposes a different hole, so you write another rule. By rule fifteen, you’re just maintaining a list of every way you’ve ever lost.

What can be done to break this cycle?

Thinking about how Pro players use composition builds and win with them constantly, their compositions are immediately identifiable: Roach Ravagers, Mech, Skytoss. They bend those compositions to survive what the opponent is doing, but they never break the synergy to chase a hard counter.

Countering everything sounds adaptive right up until you pay a tax for it. Every pivot costs tech, ramp time, and tempo, and you never accumulate the synergy that makes an army stronger as a system. You end up perpetually two minutes behind a fight you’ve already lost.

How can we bend our bots?

​MindMe did a Postbot session on his counter tables. His tables aren’t just a blind list of units to build. They are a state-aware tree of plausible solutions.

If the enemy builds Void Rays, the ideal counter is Corruptors. But the bot checks its reality first: Do I have a Spire? Do I have gas? Am I dying right now? If it can’t execute Corruptors, it falls back to Hydralisks. If it lacks a Hydra Den, it falls back to Queens and Spores. The enemy creates the demand, and the bot walks down the tree until it finds the best possible answer its current tech and economy can actually afford to execute.

You prescribe the objective. The demand system handles the adaptation. Push and pull sit at different layers. The push belongs at the objective layer to define what the bot wants. The pull belongs at the execution layer to dictate how it gets there.

To solve that tax, you have to formalize the switching cost: forward spend plus the vulnerability window. Forward spend is the resources for the new structures and the units themselves. The vulnerability window is the ramp time where the army is temporarily weaker while a live threat exists. You exclude sunk costs, the resources already spent on your current army are gone either way. That way when it goes down the table it will favor counters that have lower costs from its current composition states and avoids counter-chasing.

⌨️ Next Commit

This week find one production decision in your code and force it to answer two distinct questions.

What are you building toward? And what do you build right now to keep moving toward it?

Code exactly one scenario where the second answer changes, but the first stays fixed. When you run it, your bot should pivot its immediate action without throwing out the overall strategy.