Starcraft AI blog

BWAPI 4.1.2 has two bugs that (it seems to me) pinch zerg hard. One is the hive research bug that prevents a bot from doing lair research in a hive (and related bad stuff). This bug is why Steamhammer so rarely gets overlord speed; it wants a fast hive. Someday I’ll work around it as best I can, either making a second lair or spending on overlord speed first whether or not it is needed at the time.

But today I want to talk about the other bad bug, the extractor bug. In BWAPI 4.1.2, when a gas mining building of any race is destroyed or canceled, the geyser goes dark: It is treated as a unit which is out of your vision, and you can’t get information about it. geyser->exists() returns false, even when you are standing next to it and it’s in plain sight.

UAlbertaBot and Steamhammer are unable to take the dark geyser. That is why, when Steamhammer loses its gas, it never retakes it. The geyser is permanently lost to it.

I’ve never seen it done, but in principle the bug could be used offensively: Take your opponent’s gas but cancel your refinery building immediately. Do it again in the natural, if you like. Against a BWAPI 4.1.2 bot, the geyser goes dark permanently. Steamhammer would have little chance to recover. Rules don’t forbid it; after all, it is in a sense Steamhammer’s own fault that it can’t recover—nobody required it to use a buggy library.

I hit this bug back in Steamhammer 1.0 when I implemented the extractor trick: At 9/9 supply, start an extractor which uses up a drone and takes you to 8/9 supply; make a new drone, returning to 9/9; cancel the extractor, getting 10/9 supply. I wanted to try the old school 10 hatch opening which is strong against 2 gate zealot rushes. The extractor trick is a slightly fancy skill with a lot of potential failure cases, but I thought it through and implemented it with all the checks—then never used it in production or advertised the feature, because once the extractor was canceled it could never be taken again. That’s why I say that the bug is particularly harmful to zerg: The extractor trick is a basic zerg skill for getting an extra unit in certain openings, and for restoring the health of a drone in the field which has gotten into a scrape (which could count as the offensive exploitation of a bug, which I don’t want to do).

Is there a workaround? I hope that there is still a way to take the geyser after it goes dark. I tried a couple of quick fixes and did not find a workaround yet. The issue discussion says that getAllUnits() returns the real geyser, but it did not work for me. I will have to dig into the code to see what’s happening, and I’m a little reluctant to put in the effort without knowing whether it will help. So I ask: Does anybody know a workaround? Do other 4.1.2 bots cope successfully?

I took a little time to look into the bot named 5 Pool, checking the version just uploaded. I had noticed that it didn’t play exactly the same version of 5 pool in every game.

It’s a Steamhammer fork (which I already knew from watching its behavior). It no longer comes with a separate configuration file, but that’s no hindrance to understanding it. It uses the go defensive/go aggressive commands, so either it is a fork of 1.2.1 or 1.2.2, or it has backported recent changes to an older version.

It plays the same version of 5 pool usually, but it has exceptions for 5 specific opponents. Killerbot by Marian Devecka, bftjoe, and Krasi0 get a different 5 pool that makes 2 extra drones after the pool (which is stronger overall, but does require an earlier overlord so it may hit less hard at first). Stone gets its own specialized variant of 5 pool which makes 2 further extra drones (for 4 total after the pool) after the first round of zerglings. And finally, Steamhammer gets an even more specialized variant that makes a bunch of drones after the pool, uses go defensive and go aggressive at specific timings, and switches into 3 hatch ling in an attempt to overwhelm the 2 hatchery build that Steamhammer plays against 5 pooling bots. Ha ha, that is what I get for playing a fixed opening! I deserved it! The next version will regain support for random choice of openings when playing specific opponents, which will put paid to that.

Well, Steamhammer’s anti-5 pool build in the dev version is a little tighter than in the last release version (it’s been days already, I can’t leave an opening alone that long, it will grow sad). 5 Pool’s counter may work against version 1.2.2, I haven’t tried it. But I did run a test game against the dev version, and Steamhammer won with surprising ease. I think it is quite hard to counter a 9 pool with a 5 pool, even if you know the exact 9 pool build order and aim for its weakest points.

I have a bit of a philosophical question: How far can you get by tailoring variants of the same extreme opening to different opponents? At the moment, 5 Pool is #6 on the rating list, very high for a bot that plays a fixed opening which all strong opponents have seen before and should be ready for. And it has room to grow: There are tactics that 5 Pool does not know which could make it much scarier. For example, it doesn’t know how to run by a bunker. Martin Rooijackers thinks that the cheese openings are dead, but I think they still have some life in them.

Yesterday I watched a pro ZvZ game from 2010 where the winner played an opening I had not seen before. “Hmm, does that have good timings against overpool?” I thought. It seems to be a rare opening and is not documented on Liquipedia, but I coded up a version and tested it out. The scores are Steamhammer 1.2.2 set to play one fixed opening, versus each opponent.

victim	score	version
Ailien	13-2	uploaded 4 April
Killerbot	14-1	SSCAIT 2016
Microwave	14-1	0.15, uploaded 5 April
Steamhammer	11-4	1.2.2, latest release with 11 ZvZ openings
Zia	15-0	uploaded 7 September

Holy Saint Isidore, Batman! Bots are not prepared for this!

Killerbot scored 1 win when Steamhammer made a tactical mistake of a kind that I intend to fix in the upcoming version. Microwave was able to exploit a risk inherent to the opening—once. Zia tried its builds one after another and lost with all of them. Ailien’s machine learning came the closest to finding an answer; it tried different tacks, and a few of the games were fierce. By the end of the match it seemed to be grasping at straws: Do hydras work? No! Do lurkers work? No! Every fixed opening has counterbuilds, and a human player who knew what was coming would find it easy to beat. It is possible that the counterbuilds are outside Ailien’s gamut, or take over 15 games to find. The release version of Steamhammer itself put up the strongest fight but was forced down.

Of course Steamhammer does not play fixed openings outside of tests like this. I think that adding the new opening to its repertoire is likely to make Steamhammer impervious for a long time to machine learning attacks on its openings.

I’ll be holding my secret weapon in reserve until version 1.2.3 comes out. Everything will be published then, but I also enjoy springing surprises. This will change the meta, and I would like to be 2 steps ahead.

Yesterday’s post was the 256th blog entry, which makes it an important anniversary. How many blogs make it to 2^8 posts in hardly more than a year?

The first post was on 2016 March 4. In May I made only a few posts while I worked on the blog software, but even including the gap, I have posted on more days than not. As I write, the blog has 747 published comments.

A success! And my it be useful for BWAPI coders everywhere.

Steamhammer 1.2.2 is uploaded. It is a bug fix release, mostly to fix strength-reducing bugs introduced in 1.2.1.

Next will be 1.2.3, primarily a feature release to help all races play stronger and more interesting games, then 1.2.4 to fix lingering bugs.

bug fixes

6 bugs are fixed, 3 serious bugs that caused losses for all races in version 1.2.1, and 3 zerg bugs that are smaller and didn’t cause any losses that I could identify. There are still no known crashing bugs.

• The bug in retreating to the natural is fixed. When retreating with no fresh units on the way, Steamhammer now retreats to the natural if it has been taken, or to the main otherwise. Retreating blindly to the natural caused many losses when the bot did things like retreat from the main to the natural when the enemy was at the ramp. (Squad::calcRegroupPosition())

The retreat system is confused in the first place. The first choice of retreat point is the closest friendly unit that is not “near” the enemy. It is supposed to close up gaps in the formation—that is why it is called “regrouping”. But in practice the closest friendly unit might be anywhere, and Steamhammer may retreat to the natural, to the main, or in a direction that makes no sense at all. Only when there is no friendly unit to retreat toward does it retreat to the natural or main as appropriate.

• Errors related to pulling workers for emergency defense are fixed. There were subtle issues causing workers to be left in the base defense squad after they were supposed to be released. It sometimes caused weird worker dances and other bad behavior. I also tightened it up; workers are now pulled to fight a proxy only if no combat units are out yet, and to fight zerglings only when they come very close to the mineral line, and otherwise not at all. Steamhammer will self-destruct less often, and (I hope) continue to successfully defend itself when it can. (CombatCommander::updateBaseDefenseSquads()—I renamed it for consistency.)

• A change in 1.2.1 to put more idle workers back to work introduced a bug where it also put building workers back to work before they started building, sometimes delaying the start of construction by as much as a few seconds. When timing is critical, it causes losses. In particular, it caused the 9 hatch opening to lose to 9 pool, when it should defend in time. Excess worker pulling contributed. (WorkerManager::updateWorkerStatus())

Lukas Moravec has found another bug that makes buildings start later, but the effect is smaller. I decided to delay fixing it until I understand it thoroughly.

• Zerg mistakenly made sunkens to defend against air attack. Oops. (StrategyBossZerg::checkGroundDefenses())

• Zerg was ignoring its absoluteMaxDrones value and making too many drones in long games, cutting into the supply available for its army. (StrategyBossZerg::updateGameState())

• Zerg catches more cases of deadlocks that cause production freezes. It should only have happened when Steamhammer was already in trouble, though. (StrategyBossZerg::nextInQueueIsUseless())

other improvements

• I tuned up the ZvZ 12 pool opening, and adjusted some opening settings.

• The true/false configuration options KiteWithRangedUnits, WorkersDefendRush, and ScoutHarassEnemy can now be set differently per race, to better support playing random. The feature is not used in the default configuration; all races are set to the same value. I also removed UseSparcraftSimulation, since it was already unused in the code.

Stone

This version does do worse versus Stone. In a test match, it scored 12-3 with 2 close calls where it went down to 2 drones. When worker defense was first implemented, Steamhammer scored 15-0 with 1 close call where it was taken down to 3 drones. The cause seems to be the return cargo bug fix. The effect is hard to see, but it makes workers more likely to stop and defend themselves in spots where other workers will not help them out. I decided that the correct fix is to improve worker micro, and I didn’t want to try something so delicate in a bug fix release.

Steamhammer 1.2.2 needs no more work, but the SSCAIT stream seems to be down so I guess there’s no point in uploading it right away. I’ll use the time to run extra tests and make extra sure that it’s extra solid. The last release was not tested carefully enough, but this one should be good.

I put in 3 serious bug fixes that affect all races, 3 lesser bug fixes for zerg, and 2 minor improvements. Version 1.2.1 was weaker than 1.2; if I did my job, version 1.2.2 should make up the difference and then some.

It’s April 1, time for Big Game Hunters, and—ack! Steamhammer is refusing to start up on the map! Another bug to fix, and one that may not matter again until next year. I regularly try it on maps outside the SSCAIT pack, but not on maps this strange.... Should I add another test to my release checklist?

Update: It’s working for me locally, with the WebMaps version of Big Game Hunters. What version of bgh is SSCAIT using?