archive by month
Skip to content

doing away with the BOSS

I think the biggest weakness in Steamhammer protoss and terran is macro (not that they have any shortage of other weaknesses). They rely on BOSS by Dave Churchill for production decisions, and BOSS does not live up to its promise. BOSS often orders more production buildings than it can use, and then does not use them efficiently. It will do things like order up a big batch of workers, or of production buildings, and allow resources to accumulate that could be spent immediately in the existing production buildings. Randomhammer loses game after game as protoss and terran because it does not have as many units as it should. “Never mind that we’re under attack. The factories we have are not enough. Make more factories and leave the existing ones idle!” Steamhammer forks like terran bftjoet also suffer.

BOSS also works more effectively with long build orders, which means that bots tend to react slowly when the situation changes. When the bot makes a discovery (“uh oh, we need detection” or “that’s too many tanks, I should make zealots instead of dragoons”), it has four choices. 1. It can insert an emergency reaction directly into the build order. It does that when it sees dark templar: Protoss makes a forge and cannons, terran makes an ebay and turrets. It’s inefficient and delays regular production, because the inserted reaction and regular production cannot overlap. 2. It can wait for the current build order to finish and call for a reaction in the next build order. If the current build order is long, it may be a long wait before the reaction occurs. 3. It can cancel the build order and call for a new one that includes the reaction along with regular production. The reaction is likely to be slow because BOSS does not offer any way to prioritize. If you say you want an observer, BOSS promises that by the end of the build order you will have an observer; that’s the only promise. 4. It can cancel the current build order and call for a new one with only the reaction. The reaction will be quick but other production will suffer—again, no overlap. You'll get your observer as soon as possible, but in the meantime your gateways will be idle.

BOSS’s strength is that it provides an API that is easy to use. You tell it what units and upgrades you want, and it figures out prerequisites, decides what production and research buildings you’ll need, and gives you back an exact build order that accomplishes what you want (modulo a few bugs, which are minor for protoss and terran). If its build orders were good, BOSS would be great. As it stands, BOSS is convenient but problematic.

I want to drop BOSS to avoid its problems. Who wants to work under a boss when you could be independent? But I would like my replacement to maintain its strength. Here’s what I’m thinking.

The current zerg strategy boss combines “what do we want to make?” and “how do we make it?” into a monolithic module. I want to refactor the two questions into separate modules. BOSS solves “how do we make it?” I’ll replace BOSS with a new production planner that accepts abstract production goals and incrementally plans how to achieve them.

“Abstract production goals” means you don’t ask for exactly what you want, as with BOSS. If you want tanks and vultures, then your production is constrained by the situation. Tanks are gas-heavy and how fast you can make them depends on your gas income. Vultures are limited more by the number of factories. You might emphasize tanks or emphasize vultures, but the production planner should take the income and production constraints into account when deciding how many factories to build and what the ratio between units should be. That should both make the API easier to use and improve the bot’s play.

I’m thinking the input should be a set of goals with priorities. Something like: Tanks with this priority; vultures with that priority; 2 dropships and 2 science vessels as soon as possible without wasting resources; upgrades with some priority, etc.

“Incremental planning” means that the plan is worked out in small chunks so that reactions can be quick. You should be able to change goals and priorities at any time and see results quickly. If you want an observer with high priority, each step along the tech path should take minimum time, and remaining resources should continue to go into your regular production.

That is my idea, as far as I have worked it out. It’s not an immediate plan. I have more plans than time. But I want to get around to it at some point. When I do, I expect Randomhammer’s protoss and terran play to become much stronger. Zerg should be a little stronger too.

Trackbacks

No Trackbacks

Comments

Jay Scott on :

I should add: The problem that BOSS makes poor build orders is an implementation issue. It could be fixed by improving the implementation. The problem that using BOSS makes a bot slow to react to discoveries is a design issue. It can only be fixed by designing a different API.

krasi0 on :

Build order planning - one of the hardest and most interesting problems in bot development. After so much time spent on my implementation, I am still not satisfied with its overall performance...

Arrak on :

Yes! This is one of the major problems I've been trying to solve. It will especially help in ZvZ, and getting to hive tech ZvT, and expanding at the right timings (generally, earlier than Steamhammer/Randomhammer does in all situations)...

Marian on :

Build planning was indeed very exhausting to implement but also rewarding at the same time.
It is even harder for zerg as you have to manage your larvae.
Good news is you don't have to plan every frame and so with a few smart optimalizations it will not consume much time.

MicroDK on :

You might want to check out this new paper about macromanagement from deep learning: https://www.facebook.com/groups/bwapi/permalink/10159031208430261/. PDF: https://njustesen.files.wordpress.com/2017/07/njustesen2017learning.pdf

Jay Scott on :

To me, the paper reads as an attempt to set foot on the path followed by go programmers: First train a network to predict human moves, then bootstrap from that to actual good play. Sounds plausible, right? Early results reported in the paper are... the opposite of impressive. From the description, it sounds like the network learned one build and follows it every time with minor variations. Go programmers followed their path because early experiments were wildly promising.

Jay Scott on :

The poor results make some sense to me. In go, the board is big but at a high level of play only a modest number of moves are plausible at a given time. To predict human moves, you have to identify the plausible moves; learning to predict human play forces the network to learn an important part of the game. In Starcraft, there are situations where it matters whether the next unit out of your gateways is a zealot or a dragoon, but typically you don’t care much. It’s important to get the right mix, not the right next move. Macro is usually a strategy-level decision that stays valid for a longer stretch of time. I would have started with predicting unit ratios over a longer production cycle, not moment by moment what-unit-next moves.

MicroDK on :

Their work is still important to the BWAPI community even if the results are not impressive. They still improve UAB using this method. ;)

Jay Scott on :

Well, adaptivity is an improvement. But their bottom line result is that their modified UAlbertaBot with learned macro scores almost 50% against the game’s built-in terran AI. Of course that’s because they deliberately learned human-like macro, and UAlbertaBot doesn’t have the skills to take advantage. They didn’t show any improvement in performance—their method of comparison doesn’t even allow them to.

Joseph Huang on :

I dropped BOSS from my bot. I am adding code to production manager which handles empty Q and what to build next, and also trying to make it smart enough to build what it needs if the Q is blocked. Basically merging StrategyManager into ProductionManager.

Add Comment

E-Mail addresses will not be displayed and will only be used for E-Mail notifications.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA

Form options

Submitted comments will be subject to moderation before being displayed.