Starcraft AI blog

A couple days ago I wrote about Steamhammer’s addon bug, and everyone who offered advice suggested more or less the same plan: Keep track of addon production yourself. Fix the bug by retrying if necessary.

That plan happens to fit with another plan I’ve been nurturing, the idea of abstract opening strategies that I wrote about in March. In an abstract opening strategy, you specify a goal like “get me 3 hatcheries and spire tech, go!” That’s a high-level production goal, while adding a control tower to a starport is a low-level production goal. But they are both production goals, and both can be implemented by the same software system. After all, to achieve a high-level goal, you have to achieve several low-level subgoals.

Today I drew up the first draft of a ProductionGoal class. So far it can only represent goals to build addons, to solve the immediate problem. That will be enough for the next version. As a next step in a later version, I might add goals to create morphed zerg buildings with dependencies. Then you can order a lair, and it will reason “you have the hatchery and stuff, here’s your lair.” Or order a sunken and it will build the creep colony first if necessary. Right now if you ask for a sunken at the natural and there is not enough creep there yet, Steamhammer will build it in the main instead as a fallback (and it’s usually a mistake). With a persistent goal data structure, it will be easy to duplicate Killerbot’s skill of waiting until there is enough creep at the natural to start the building. It will also be easy to add goals like “make 1 sunken at each base,” which you might want when vultures are roaming. Protoss might want the goal of putting 1 pylon at each base, in case cannons are needed later.

I’ll work in stages toward full-power production goals. One of the steps will be to add a production status data structure, after which I’ll be able to turn off latency compensation, another thing that’s needed sooner or later. The plan is growing more concrete.