Starcraft AI blog

The new production goal code that I announced yesterday is working great for its one use case, terran addons. I have a lot more testing to do, but so far it looks solid. There are no known bugs. Addons are reliably built when ordered, or as soon as possible afterward.

Building addons is not only more reliable and more timely, it’s easier. If you know you want a control tower as soon as possible, simply ask for it immediately after the starport, like this:

... "starport", "control tower", ...

Previously, you had to figure out where in the build order the starport would finish, and insert the control tower there. That was a pain and often delayed the build order.

When the control tower comes up, ProductionManager turns it into a goal. The goal looks around and finds the uncompleted starport it is to be added to (as soon as the starport does start–it may stay in the building manager for a while), and remembers it. (Or it finds a completed starport and executes immediately.) If the production queue is displayed, pending goals are shown in white and orange above the green units under construction (which are above the multicolored units queued for production). When the starport finishes, the control tower starts immediately, and the control tower goal is completed and deleted.

Of course, there are a lot of ways for goals to fail. If the starport gets canceled before it is started, or is canceled or destroyed after it is started, the goal will recognize (in a second or so) that it has failed, and be deleted. On the other hand, if the control tower starts but is then destroyed before it finishes, you have to order another control tower. The goal was already completed.

Next, I will work through the terran openings. Merely having the production goal code makes them more reliable. I think several of them can be tightened up to also produce key units sooner. Terran play will be slightly but unequivocally improved.

The new code never fails to build the addon when commanded. It seems strange. It builds the addon on the earliest possible frame, and it’s fine (just as Ankmairdor said in a comment). Building at a different time should be the only difference from the old code: The production goal code does exactly the same checks (“can I start this yet?”) and issues exactly the same command, because all I did was reorganize the code to do the same things at different times. I remain mystified about the cause of the original bug.

My initial goal code was beautifully simple. I was pleased. Of course, once I fixed the early bugs it was not quite so beautiful any more. I guess that’s how it goes. I found solutions, though, and it’s still good code.

Production goals work so well that I’m already considering adding another kind of goal for this version. When the opening ends, maybe Steamhammer should automatically post a goal to build workers as possible, for terran and protoss. Zerg has to make tradeoffs, but terran and protoss commonly want to build workers continuously until their bases are saturated. It’s not perfect play, but it’s better than Steamhammer’s current play. I would change the strategy code for terran and protoss to request no SCVs or probes, and leave it to the goal. The worker goal would build workers with priority over regular production. If you happen to want different behavior, create a different worker goal and post that instead. For example, for a rush opening, you could create a command to post a goal to make workers with low priority for some period of time.

I think the addition would be a substantial and relatively easy improvement over BOSS. Is it worth delaying other features to get that one in too?

Update: I’ve tested every terran opening multiple times in full games, and slightly revised about a third of them to get addons sooner. The production goal system is working perfectly. Macro is noticeably improved for everything that depends on addons: Comsats have more energy because they are made sooner, factories get more tanks out, and so on. I was able to remove a workaround for a BOSS comsat bug, because the production goals work around it automatically. There is one issue where BOSS occasionally orders far too many addons, partly because of bugs and partly because BOSS doesn’t know the bot’s full state. The system struggles to recognize that most of the addon goals will fail, and they stick around too long. So far this hasn’t caused any problem worse than looking stupid, but in the worst case it could cause a slowdown.