Starcraft AI blog

Steamhammer’s average game is kind of so-so, but its best games are good. Today it played an exciting macro game Steamhammer-adias on Jade. The game showed the strengths of Steamhammer’s queen play and burrowed zerglings, though adias shut the defilers down hard.

For background, Steamhammer’s 30 day record versus adias on BASIL is 17-10, so it wins more than it loses. But nearly all of its wins are with its cheesy hydra rush opening, in games like this one on Benzene: adias survives the rush, but it doesn’t know how to react and its build order breaks down so that it gets outmacroed and run over. Steamhammer is exploiting a bug.

The Jade game is different. Steamhammer opened with one of its anti-factory openings, the one that follows up with hydralisks. Adias set up to do its usual early game 2-vulture runby, but for some reason one of the vultures stayed behind and only 1 made it into the zerg main. It killed 2 drones before hydralisks nabbed it, not enough to set Steamhammer back severely.

A little later, after neatly clearing the spider mines in front of its base, Steamhammer went to attack with the hydras. Adias was in no danger, but it did lose a few goliaths unnecessarily due to clumsy maneuvering. That may have been why terran chose to take a third base, rather than build up and attack on 2 bases.

The picture shows terran trying to take its third base. The blood on the ground is from Steamhammer’s burrowed zergling. The zergling successfully delayed the expansion, but not for long because adias knew what to do: It brought tanks and scanned. Steamhammer also reacted correctly. In the minimap, the small orange splotch near the terran natural is a hydralisk attack which drew the goliaths out of position. Mutalisks went to the terran third and delayed it further. There are only 6 mutas, but they killed those 3 tanks and a number of followup terran units and delayed the third for longer than they should have. I think this was the key battle that set adias back far enough that Steamhammer could play a long game.

Adias did finally bring enough units to take its third safely. Terran with 3 bases is very strong, but Steamhammer now has 6 bases and is ahead in workers. By keeping terran busy with a handful of units, zerg was able to drone heavily.

The picture shows Steamhammer’s queen parasiting the first science vessel. The little orange dot halfway between them is the parasite projectile. Terran did not have irradiate yet. The queen kept busy parasiting vessels for the rest of the game. Adias did not react to the parasites, which handed Steamhammer another crucial advantage: Zerg maintained vision of the terran main army via the parasites, and almost always knew its location, size, and composition.

Adias is no pushover and it has its own strengths. Here a vulture raid has cleared the drones from one of Steamhammer’s bases. Steamhammer went from well ahead to about even in workers. Adias pulled these raids repeatedly. But unlike terran, a zerg with a strong economy can replace lost drones in short order. The raids did ensure that terran could firmly secure its third.

OK, now terran has irradiate. Steamhammer has code to separate an irradiated mutalisk, and it worked when I wrote it, but bits decayed and now it does not work. It’s a devastating weakness. 6 mutalisks and a few scourge died to this one irradiate, and the surviving muta had a sliver of health.

But irradiate a hydra and it burrows to spare its comrades. This came up later in the game.

Here is terran’s big attack, the intended killing blow. The armies of both sides are disorganized. Steamhammer has just cleaned up another vulture raid at lower right (by the time the vultures were dead it had already restored its drone count) and is rushing back, while adias (perhaps hurrying to take advantage while zerg is out of position) has allowed its units to stretch into a narrow column. The line of tanks and goliaths continues north of this wide picture.

Well, zerg is more mobile. Steamhammer got its forces together before adias could sort its units into a ball, and rolled up the terran column with hydra-ultra. The picture shows adias dropping Steamhammer’s natural while this happens. Shortly after this, vultures raided the 4 o’clock base too. The terran army has been forced back, but the worker count went into terran’s favor, and adias still has 2 bases mining.

The scourge on the tail of the dropship did finally catch it after it reached the terran main. Almost safe! I think Steamhammer’s scourge control has a bug that causes it to chase some enemies too slowly.

Oops, the terran army retreated to the natural, not to the third base. A small flight of 7 mutalisks, after erasing the dropped units, arrowed to the undefended third base and started to erase it too. Well, after defending adias still had enough SCVs, partly because its natural was running low, but Steamhammer had replaced its drone losses and was pulling ahead. Steamhammer suddenly switched to mutalisks as its primary unit, and was able to produce them faster than adias could produce goliaths to defend. In the picture terran and zerg are equal in supply, but adias could not hold against the mutas. Terran had the wrong unit mix.

The mutalisks depopulated the terran third, and then there was nothing adias could do. Another devastating irradiate finally forced the mutalisks back (most of the survivors were barely alive), but by then adias had only 14 SCVs and a smaller army size. Steamhammer soon maxed and ultraling finished it. For the cherry on top, the queen infested the main command center.

From Steamhammer’s point of view, the game was all about information. Even though adias knew how to counter it, the burrowed zergling saw what was happening before it died and made it possible for Steamhammer to delay the terran third. Then the queen’s parasites ensured that Steamhammer always knew the terran unit mix. Steamhammer used the information to make sudden switches in its own unit mix to take advantage of temporary opportunities.

This was a great game to show off the weaknesses of both sides. Adias repeatedly ran into trouble because it could not keep its units in good formation. Steamhammer needed to frequently replace dead drones, and suffered in the air from irradiate.

In the next game, on Circuit Breaker, Steamhammer repeated the opening, but the game went differently. Adias did its 2-vulture runby before Steamhammer was ready, killed a bunch of drones, and pulled far ahead to win easily. I made a version of an anti-factory opening timed to stop the 2 vultures, but this was not it.

I’ve mentioned it briefly before, but here’s a longer post. It is past time to start writing serious machine learning methods into Steamhammer. I’ve been writing code for it behind the scenes, though none is in Steamhammer yet, even in the development version. I selected a combination of techniques that will learn fast, will run fast, and I hope will be accurate enough. Right now I need to fix a numerical precision problem (I’ve always hated numerical analysis), but soon it should be ready to start testing on non-toy problems. It won’t be in the next Steamhammer 3.1, but perhaps a version or two after that, if all goes well.

The first application will be a “will I win this game?” evaluation function. The idea of evaluation functions is very general: You can evaluate anything, “how good is this build order?” “am I likely to win this fight?” “which tactical maneuver is better, A or B?”—anything you want to measure or compare, really. The use of evaluators is also very general. Whenever you want to make a choice, if you have the right evaluator and you can provide it the right inputs, you can compare the choices and pick the one that looks best. That is what search is, and search is one of the most basic ideas in AI.

The “am I winning?” evaluator will take several hundred numbers as inputs, unit counts and things like that. You can see my 2018 analysis of LastOrder for some of the possibilities. The output will be an evaluation of how likely Steamhammer is to win from the game position, I think a probability or something that can be converted to a probability. My initial estimate is that it should run in under 5 milliseconds. It doesn’t need to be run often, so even if that’s optimistic it will be fast enough. If it works as well as I hope, it will be possible to specialize the evaluator for each opponent. If that succeeds, there will be a pre-learned evaluator for unfamiliar opponents, and learning data in the opponent model will update it to understand that player. I’m seriously expecting the learning to be fast enough for that to help, though we’ll see.

The first use of the evaluator will be to select openings. Right now Steamhammer keeps tabs on whether a given opening won or lost. The bot does not know, at least until it plays a lot of games, whether it won because the opening gave it a huge strategic advantage, or whether it was behind after the opening but managed to scrape a win anyway. The evaluator will tell it, and it will select better openings. For example, against a much stronger opponent Steamhammer rarely wins and falls back on trying builds at random, hoping to hit one that works. Most of the random choices are poor, but it is losing every game anyway so it can’t tell. The evaluator will tell it which tries are more nearly successful; it will try those more often and have better chances. That is only an example; I expect the evaluator to help against most opponents.

A later use of the evaluator will be to construct new builds. I have plans in mind. There is already code in Steamhammer—it’s not finished or working, but the nub of the idea is there—to simulate build orders. When that is in place, Steamhammer will be able to evaluate builds that it has never played in a real game and get an idea of whether they will work. “I got run over fast. If I substitute 12 pool for 12 hatch, am I ready in time?” If that succeeds, Steamhammer will be able to customize builds to counter specific opponents. The potential is great, and this evaluator is a key step on the way.

Starcraft gives the players many many choices. It’s not possible to search any large proportion of them. In the search/knowledge tradeoff, I think that means that knowledge is preferred: You want to search few choices (at least compared to how many there are), but select and evaluate the choices with a lot of knowledge. That’s why I think that knowledge-rich machine learning methods are the right way.

Steamhammer versus BananaBrain on Moon Glaive was a fun back-and-forth game. Well, it was Randomhammer as zerg, that’s Steamhammer.

Steamhammer opened with a fast hatchery before pool, preparing zergling aggression. BananaBrain was also aggressive; it hid 2 gateways on the left of the map where they were unlikely to be scouted early. The gateways were more or less midway by ground between the 2 bases where zerg might be.

The zerglings outfought the zealots, then made a beeline for the protoss base, where they wrecked the economy. Protoss was left with 1 probe mining and 1 more in production.

But protoss had still been producing army during the attack, though the units were too far away to defend the main. It’s the drawback of a proxy opening: Close to the enemy means far from home. Steamhammer did not see the units and concluded that it was safe, so it started a third base (see 8 o’clock in the minimap), added a hydralisk den, and morphed a lair in its natural. A good human player would have predicted the protoss army size and been ready for it, but bots to date are weak at inference. Steamhammer could not save the lair in its natural and threw away units trying, then pulled together a defense in its main barely in time. BananaBrain ran by the sunkens to attack drones, one of its great skills, and it was zerg’s turn to fall behind in economy. Notice how much the protoss probe count has recovered. The zerg drone count fell to 5 shortly after the picture.

Three drones escaped the carnage and ran across the map to the hidden zerg third, which protoss did not yet know about (though a human player would have guessed its general location from the direction of arriving units). After a short distraction when a small zerg squad again attacked the protoss main, BananaBrain put heavy pressure on the defended zerg main. Both sides were racing to rebuild workers and trying to afford tech.

It was around here when BananaBrain repeatedly tried to expand, and Steamhammer’s patrolling Recon squad repeatedly denied it with only a few units. Protoss chose to keep attacking rather than defend an expansion. BananaBrain has added tech and sent out corsairs, and zerg protected its overlords with a spore colony in the main. Steamhammer’s mineral bank of 900 is a sign that it is short of hatcheries—it knows that, and wants to add hatcheries.

Needing more hatcheries, Steamhammer also tried to expand, in a rather strange pattern where the first hatchery at a new base was offset and the second one placed at the base location. The natural was denied, then a new base at 10 o’clock was about to be killed by zealots—when a scouting observer finally ran down the left of the map and discovered the hidden base, now bustling with drones. The protoss army suddenly had a more alluring target, and ran there to raze it.

But Steamhammer had mined its third base for most of the game, and BananaBrain had never been able to expand. The protoss main was dry, and the zerg 10 o’clock now had a half dozen drones at work, and it shows in the production tab. Steamhammer scourged the sky of corsairs, defeated the zealots with hydra-ling and a few mutalisks, and tore down the proxy gates before finally tackling the protoss main.

Whew, no big fights because of the damaged economies, but an exhausting struggle. Either side could have won easily at various points with smarter play at that moment.

I have given Steamhammer a primitive ability to lift terran buildings. A terran opening can include a command like "go lift engineering bay" and every ebay that can lift, will. If it’s busy researching, it can’t lift. The StrategyManager code that manages terran production will lift every barracks and ebay if the plan calls for all factory production, so the command doesn’t have much practical use for those writing openings. Still, the lifted buildings will leave more space available in the main base, so fewer factories should end up in the middle of the map.

I thought the work would be trivial, but I had to make more changes to the parser than I expected. Now a MacroAct is able to parse and remember a command with a UnitType argument, in case I ever add any more commands like that.

Floating buildings are controlled by the new Scout Boss, which will find something useful for them to do. That’s why I added lifting now. I am also looking ahead: Lifting an infested command center is a zerg skill, and I’d like to be able to do that when appropriate. Steamhammer infests command centers on a regular basis, much more often than I’ve seen any other player do, bot or human.

You’ll need to write code if you want to lift off a specific building: Just this ebay that I built forward for scouting, not the one at home. A simple command has no way to specify. Still, I would like the production system to be able to tie production to specific units: Morph these hydras to lurkers, not the others; make this creep colony into a spore and that one into a sunken. I’ve seen only one game where it tried to make a spore (in main) and sunken (at natural) at the same time and got them switched, but it seems like something I had better get right.

Landing is not as easy as lifting off, because you have to decide where to land, and it depends on what you’re aiming for. Someday I’ll implement lifting off an endangered building and landing it again when the area is safe. It may involve ordering your own units out of the landing zone. That will likely be the first use case for landing. I think other cases will wait until there is an operations planner: Opening and closing “gates” in a wall, relocating a command center, floating in a proxy factory, reacting to enemy tricks like blocking the machine shop with a pylon....

Does Steamhammer’s updated gas steal skill help it win games? I ran an analysis on Starcraft AI Ladder games to find out. Each of these tables represents data from 100 games against that opponent.

“Gas steal decision” means Steamhammer decided to try to steal gas. It gives the number of games it made the decision and the time when it decided, along with the win rate and the enemy gas timing in games where it decided to steal gas. “Gas steal success” counts games where it succeeded in making the extractor on the enemy geyser. That’s more important than making the decision. “None or failed” means games other than successes, and “gas steal killed” is the time the extractor was destroyed, given that it was made in the first place. The “enemy gas” column is the median game time when the enemy was first observed to use gas (they made a building or unit which costs gas); the purpose of stealing gas is to delay this time. When it is “-”, that means the enemy was never observed to use gas before the game ended.

Conclusion: The important rows to compare for each opponent are “gas steal success” versus “none or failed”. The numbers say that a successful gas steal does delay the enemy’s gas use. That is why Steamhammer tries it so often—it takes that as a sign that the trick is working. But by and large, stealing gas doesn’t lead to a higher win rate. These opponents can cope with having their gas stolen, at least as Steamhammer does it.

Maybe I should tone down the vespene theft. I have the impression that most opponents which are discombobulated by the gas steal are ones that Steamhammer will defeat anyway.

I thought I’d take the opportunity to update the script that analyzes Steamhammer’s learning data files to handle the new game record format.

Since yesterday, on the Starcraft AI Ladder both Microwave and Halo by Hao Pan have been updated. Halo in particular is performing better. Here’s the new crosstable, just for background, showing the new results since the ladder was reset yesterday.

#	bot	overall	bana	halo	stea	micr	ecgb	purp	zzzk
1	bananabrain	82.41%		67%	78%	72%	100%	100%	78%
2	halo	71.56%	33%		72%	67%	84%	97%	76%
3	steamhammer	56.94%	22%	28%		67%	81%	89%	56%
4	microwave	56.48%	28%	33%	33%		72%	100%	72%
5	ecgberht	36.41%	0%	16%	19%	28%		75%	81%
6	purplewave	17.59%	0%	3%	11%	0%	25%		67%
7	zzzkbot	28.57%	22%	24%	44%	28%	19%	33%

And here is the analysis of what Steamhammer learned against each opponent so far. This is only a small part of the information that can be extracted from the game records; many more tables and charts are possible.

#1 bananabrain

opening	games	wins
11Gas10PoolMuta	4	25%
11HatchTurtleHydra	1	0%
4PoolHard	1	0%
9PoolHatchSpeedAllIn	1	0%
AntiZeal_12Hatch	4	25%
Over10HatchBust	10	50%
OverhatchExpoMuta	1	0%
OverhatchLateGas	1	0%
Sparkle 2HatchMuta	13	31%
ZvZ_Overgas11Pool	4	25%
10 openings	40	30%

plan	predicted			recognized			accuracy
	count	games	wins	count	games	wins	good	?
Heavy rush	3	8%	33%	4	10%	25%	33%	0%
Naked expand	1	2%	0%	5	12%	80%	0%	0%
Proxy	1	2%	100%	1	2%	0%	0%	0%
Safe expand	30	75%	27%	12	30%	17%	27%	37%
Turtle	5	12%	40%	4	10%	50%	0%	60%
Unknown		0%	0%	14	35%	21%	0%	0%

timing	#	median	early	late
my combat unit	37	3:06	1:47	3:11
my gas	35	2:35	1:33	4:22
enemy scout	40	1:58	1:25	3:02
enemy combat unit	39	4:09	2:19	5:46
enemy gas	30	4:53	2:57	10:13
enemy air unit	30	5:27	2:58	11:35
enemy cloaked unit	20	6:47	3:29	12:54
game duration	40	10:12	4:46	29:56

The Starcraft AI Ladder does not display crosstables or per-map results. I wanted to see the charts to know Steamhammer’s strengths and weaknesses, so I calculated them myself. I modified the script I use to analyze the CoG and AIIDE tournament results every year. The tournament manager’s results file is now in CSV format, a change, but of course it was no trouble to parse. The pop-up table legend explains how to interpret the results to know whether to count each game, only referring to a “Duration” column which the file itself names “Game Time” (to distinguish it from “Wall Time”), and which has value “0:00” on an unstarted game rather than “00:00:00”. My script skipped a total of 3 games out of 2793, all of them with PurpleWave as one player and all due to GAME_STATE_NOT_UPDATED_60S_BOTH_BOTS.

I found that the “Download Search Results” did not behave quite as its name suggests. It seemed to perhaps remember a previous search rather than the current setting, or anyway something unexpected. But after a couple tries I was able to get the complete record of games played since the last reset on 17 April (just a couple days ago). I trimmed off the incomplete round 133, so the file I analyzed includes all games of rounds 0 through 132. 2793 games in 2 days is a great number, far more than BASIL plays.

The ladder would be more valuable if it had more participants. As it is, I am learning from it, because nowhere else runs so many games so quickly.

crosstable

#	bot	overall	Bana	Stea	Micr	Halo	Ecgb	Purp	ZZZK
1	BananaBrain	86.22%		69%	51%	100%	98%	100%	99%
2	Steamhammer	71.68%	31%		80%	46%	79%	95%	98%
3	Microwave	70.05%	49%	20%		56%	97%	99%	100%
4	Halo	61.86%	0%	54%	44%		94%	99%	80%
5	Ecgberht	27.35%	2%	21%	3%	6%		36%	95%
6	PurpleWave	20.88%	0%	5%	1%	1%	64%		56%
7	ZZZKBot	11.79%	1%	2%	0%	20%	5%	44%

BananaBrain is on top in this small field. Steamhammer is doing well; it scores nearly a third versus BananaBrain, wins most games versus Microwave, and is about equal with Halo by Hao Pan. Thanks to the huge number of games, Steamhammer’s learning is saturated so this should be its peak performance. Steamhammer eked out a slight overall lead over Microwave only due to its dominating head-to-head results; against every other bot, Microwave scored better.

The version of PurpleWave is broken; it crashes or oversteps a frame time limit most games. I have to imagine that fixes are progressing in the workshop. I suspect that this version of ZZZKBot may not be working perfectly either, but I didn’t look into it.

each bot’s results per map

BananaBrain	overall	Benzen	Destin	Heartb	Aztec	TauCro	Androm	Circui	Empire	Fortre	Python
Steamhammer	69%	79%	57%	64%	77%	31%	77%	77%	77%	69%	85%
Microwave	51%	21%	57%	50%	62%	46%	46%	62%	46%	46%	77%
Halo	100%	100%	100%	100%	100%	100%	100%	100%	100%	100%	100%
Ecgberht	98%	86%	100%	93%	100%	100%	100%	100%	100%	100%	100%
PurpleWave	100%	100%	100%	100%	100%	100%	100%	100%	100%	100%	100%
ZZZKBot	99%	100%	100%	100%	100%	100%	100%	92%	100%	100%	100%
overall	86.22%	81%	86%	85%	90%	79%	87%	88%	87%	86%	94%

BananaBrain barely noticed opponents other than Steamhammer and Microwave. Against Steamhammer it had trouble on the map Tau Cross, and against Microwave on Benzene. Checking the mix of strategies played on those maps would probably explain the cause.

Steamhammer	overall	Benzen	Destin	Heartb	Aztec	TauCro	Androm	Circui	Empire	Fortre	Python
BananaBrain	31%	21%	43%	36%	23%	69%	23%	23%	23%	31%	15%
Microwave	80%	93%	100%	100%	100%	69%	62%	77%	77%	54%	69%
Halo	46%	14%	36%	29%	69%	54%	38%	69%	46%	77%	31%
Ecgberht	79%	93%	79%	71%	92%	85%	77%	85%	85%	62%	62%
PurpleWave	95%	100%	100%	100%	100%	100%	92%	92%	92%	100%	77%
ZZZKBot	98%	100%	100%	100%	100%	100%	100%	92%	92%	100%	100%
overall	71.68%	70%	76%	73%	81%	79%	65%	73%	69%	71%	59%

Steamhammer’s results vary strongly from map to map. I think it is a sign that the opening selection is not paying enough attention to the map. I should have gone with a proper Bayesian calculation rather than an ad hoc algorithm.

Microwave	overall	Benzen	Destin	Heartb	Aztec	TauCro	Androm	Circui	Empire	Fortre	Python
BananaBrain	49%	79%	43%	50%	38%	54%	54%	38%	54%	54%	23%
Steamhammer	20%	7%	0%	0%	0%	31%	38%	23%	23%	46%	31%
Halo	56%	43%	57%	21%	77%	23%	92%	85%	62%	62%	38%
Ecgberht	97%	79%	100%	93%	100%	100%	100%	100%	100%	100%	100%
PurpleWave	99%	100%	100%	100%	100%	100%	100%	100%	100%	100%	92%
ZZZKBot	100%	100%	100%	100%	100%	100%	100%	100%	100%	100%	100%
overall	70.05%	68%	67%	61%	69%	68%	81%	74%	73%	77%	64%

Microwave also shows a lot of variation from map to map. That’s harder for me to interpret, even though it is the same evidence: Microwave has fewer openings overall than Steamhammer, so it is possible that poor results on some maps are due to not having an appropriate strategy available. Of course it could also be that the opponent’s play is much stronger on some maps.

Halo	overall	Benzen	Destin	Heartb	Aztec	TauCro	Androm	Circui	Empire	Fortre	Python
BananaBrain	0%	0%	0%	0%	0%	0%	0%	0%	0%	0%	0%
Steamhammer	54%	86%	64%	71%	31%	46%	62%	31%	54%	23%	69%
Microwave	44%	57%	43%	79%	23%	77%	8%	15%	38%	38%	62%
Ecgberht	94%	100%	93%	100%	92%	100%	100%	92%	85%	92%	85%
PurpleWave	99%	100%	100%	100%	100%	100%	100%	100%	100%	100%	92%
ZZZKBot	80%	93%	79%	79%	38%	100%	69%	77%	85%	92%	85%
overall	61.86%	73%	63%	71%	47%	71%	56%	53%	60%	58%	65%

Halo by Hao Pan seems to have consistent trouble on Aztec, the only map in the pool with a low-ground main and a ramp up to the natural. That could be the cause. Most bots underestimate the difficulty of defending the main from enemies on high ground.

Ecgberht	overall	Benzen	Destin	Heartb	Aztec	TauCro	Androm	Circui	Empire	Fortre	Python
BananaBrain	2%	14%	0%	7%	0%	0%	0%	0%	0%	0%	0%
Steamhammer	21%	7%	21%	29%	8%	15%	23%	15%	15%	38%	38%
Microwave	3%	21%	0%	7%	0%	0%	0%	0%	0%	0%	0%
Halo	6%	0%	7%	0%	8%	0%	0%	8%	15%	8%	15%
PurpleWave	36%	7%	7%	14%	100%	100%	8%	15%	92%	23%	8%
ZZZKBot	95%	93%	100%	100%	85%	100%	92%	100%	92%	100%	92%
overall	27.35%	24%	23%	26%	32%	36%	21%	23%	36%	28%	26%

For Steamhammer, Ecgberht is a tricky opponent that can sometimes pull surprise wins. Other bots don’t seem to have the same experience.

PurpleWave	overall	Benzen	Destin	Heartb	Aztec	TauCro	Androm	Circui	Empire	Fortre	Python
BananaBrain	0%	0%	0%	0%	0%	0%	0%	0%	0%	0%	0%
Steamhammer	5%	0%	0%	0%	0%	0%	8%	8%	8%	0%	23%
Microwave	1%	0%	0%	0%	0%	0%	0%	0%	0%	0%	8%
Halo	1%	0%	0%	0%	0%	0%	0%	0%	0%	0%	8%
Ecgberht	64%	93%	93%	86%	0%	0%	92%	85%	8%	77%	92%
ZZZKBot	56%	93%	43%	57%	0%	77%	62%	62%	77%	46%	38%
overall	20.88%	31%	23%	24%	0%	13%	27%	26%	15%	21%	28%

PurpleWave crashes every game on Aztec, and frequently on other maps. :-(

ZZZKBot	overall	Benzen	Destin	Heartb	Aztec	TauCro	Androm	Circui	Empire	Fortre	Python
BananaBrain	1%	0%	0%	0%	0%	0%	0%	8%	0%	0%	0%
Steamhammer	2%	0%	0%	0%	0%	0%	0%	8%	8%	0%	0%
Microwave	0%	0%	0%	0%	0%	0%	0%	0%	0%	0%	0%
Halo	20%	7%	21%	21%	62%	0%	31%	23%	15%	8%	15%
Ecgberht	5%	7%	0%	0%	15%	0%	8%	0%	8%	0%	8%
PurpleWave	44%	7%	57%	43%	100%	23%	38%	38%	23%	54%	62%
overall	11.79%	4%	13%	11%	29%	4%	13%	13%	9%	10%	14%

These two games were played a few days ago, after Krasio was updated. Krasio apparently forgets its learned data on update, and against some opponents takes a few games to remember how to win again.

Steamhammer-Krasio

In Steamhammer-Krasio on Moon Glaive, Steamhammer started aggressively with overpool (overlord on 9 drones then spawning pool), and the early zerglings prompted Krasio to play defensively with a bunker at its ramp. But sneaky sneaky Steamhammer made few lings and instead added a second hatchery and teched to lurkers. Despite some clumsy zerg play, the lurkers delayed terran from expanding until around 11 minutes into the game. In the picture, lurkers are about to deny Krasio’s attempt to take its natural.

Krasio did at last successfully double-expand, but by then zerg was ahead and was soon able to destroy the terran third.

The next terran expansion was too far away to defend, and the rest of the game was zerg all the way.

Microwave-Krasio

Microwave-Krasio on Icarus, Microwave opened with a hatchery on 12 and went for mutalisks. The early mutas made more losses than gains, but notice the strong zerg economy. Microwave did not fall behind in supply for the whole game—a sign that Krasio was doing something wrong strategically, since the terran unit control was clearly superior.

In the middle game Microwave switched to ground units, overrunning Krasio’s third base in the lower left. For the late game it suddenly switched back into mutalisks and amassed a sky-darkening cloud. Mutas erased Krasio’s second attempt at a third base, in the bottom right, and then it was too late for terran.

comparison

Despite the different unit mixes and play styles, the games are strategically similar. In both, Krasio did not play its best opening and fell behind early. The zergs were able to roll up outlying bases with relative ease because terran did not have the mobility to defend them, and then were so far ahead that they could win by brute force.

Krasio wins when it starts well, of course, and it usually starts well once it has a little experience. The top zergs have gained enough skill to be a threat, though. Both have adequate macro and know how to choose a poorly defended expansion to attack, skills that many bots lack. In the last 7 days, BASIL gives Steamhammer 4-4 versus Krasio, and Microwave 2-5.

When you can’t defend your own expansions, you need to keep your opponent off-balance instead. It’s an advanced skill, and even Krasio does not have it. Against the lurkers, terran could have tried vultures, or drops, or perhaps wraiths—harassment that lurkers will be poor at responding to. Against the mutalisks, terran had enough valkyries to be safe, but seemed to deploy only 1 or 2 at a time in any given fight. Also, since terran was behind, the goliaths were not the best unit choice because they slowed down army movements. Without them, a larger marine and medic army would have been able to maneuver rapidly in defense, or cross the map to threaten zerg bases. I think bots are starting to play well enough that this kind of strategy knowledge will help.

This Steamhammer version is showing clear superiority over the previous one. I expected a small improvement that was hard to be sure of, but got an improvement that’s easy to see. Nevertheless, there is one new misbehavior: It takes bases in a poor order on some maps. On Heartbreak Ridge it takes the center base far too early, among other expansion order mistakes. Using the resource tracking info threw the base scoring out of whack, and my attempts to whack it back into whack were not enough. I have to hit it harder.

A funny picture:

Krasio is taking its third base as it should, and mining out the blocking minerals at a good timing so that it can transfer SCVs along the back path. Steamhammer has 2 drones in view. The drone on the right also wants to take the base, and is just noticing the command center in its way; it will give up and return home. The drone on the left knows, “We’re about to take this base, so I’d better clear this path that’s near it.” The SCV and drone are cooperating to mine out the stacked minerals, entirely to Krasio’s benefit.

Steamhammer stands at an advantage in this position, but ended up losing, most importantly because it took bases in the wrong order. Terran pushed out, and by the time zerg gained the strength to break the attack—which it did—the center base had already fallen. Many bots expand unsafely to that center base.

PurpleTickles of Dan Gant’s purple family is a bot that plays exclusively worker rush builds. It’s not highly ranked; it is #50 on BASIL, well below average. Steamhammer’s score against it is 29-1 on BASIL, and the rest of the BASIL top 10 have similar scores. But I thought this one Steamhammer-PurpleTickles game was fun and instructive.

Steamhammer’s counter to worker rush is spawning pool at 9 drones (sometimes less if drones are lost) followed by creep colony. The intention is that when the spawning pool finishes, the combination of zerglings and a morphing sunken colony will be insuperable. If the sunken completes, zerg is safe against almost any number of workers, so the opponent must prevent that at all costs.

Tickles selected a late worker rush this game, starting its attack when it had 8 probes. It left 1 probe mining and attacked with 7. The late rushes are more effective against Steamhammer, and I assume that Tickles has figured that out (it has won 1 game, after all). At the time of the picture, 1 further probe has been manufactured and is now crossing the map to join the attack.

Tickles does not have perfect worker micro, but it does know how to coordinate its probes so they attack together. Steamhammer has inferior worker micro, because each drone defends itself individually and the drones don’t work together. Its forces can be defeated “in detail,” as the military jargon goes. Also Steamhammer has sent a drone to scout, a questionable decision, so its mining workers barely outnumber the attackers. In general, when Tickles attacks the mineral line from one end, it is very successful in killing drones. When it approaches from a different direction, the probes do not coordinate as nicely and Steamhammer has less trouble. Tickles is not smart enough to figure out the right angle of attack, so the outcome of the battle can depend on the orientation of the mineral line relative to the base entrance.

The probes destroyed all mining drones with 5 surviving attackers (and 1 probe still mining at home). Steamhammer gave priority to zerglings, so 2 pairs of zerglings are about to hatch, but there is no money to morph the sunken. Vanquishing 4 zerglings with 5 probes is a tall order, but protoss is still mining and it’s definitely worth a try.

Well, the probes didn’t stand a chance, though it’s hard to tell with the overlord blocking the view. They held their ground and fought instead of trying to maneuver, a fatal mistake. Steamhammer’s scouting drone canceled its mission and returned immediately to mine, so zerg did not find the protoss base yet. The 4 victorious zerglings aimed for the wrong base at first, and also returned home to clear followup probes, but they were able to win by themselves after these little delays.

I see lessons in the game. 1. Coordinated micro is a key skill. PurpleTickles has it. 2. Steamhammer covered for its lack of that skill with a belt-and-suspenders strategy. It works. In games where the sunken starts to morph, PurpleTickles must stop it with the probes, but then mining continues and zerglings win anyway. One skill can often substitute for another. 3. When you have an advantage, try to fight head on, as Tickles did probe versus drone. A probe is a stronger fighting unit than a drone. When you have a disadvantage, go guerilla. Probes are not bad at fighting zerglings, but they have to avoid head-to-head combat, unlike Tickles. A probe can attack at will as long as it is taking only shield damage, then run away; protoss shields regenerate faster than zerglings heal. Use drills (the minerals are right there), or maneuver to separate one zergling and gang up on it. If the purple probe-versus-zergling micro were as superior as the probe-versus-drone micro, the probes might well have won.

I’m pretty sure it’s possible to defeat Steamhammer most of the time with a worker rush, though no bot has shown it yet. As in this game, gather your attacking workers at one end of Steamhammer’s mineral line and coordinate them to defeat the uncoordinated mining drones, sweeping down to the other end of the mineral line. I believe it can be done more efficiently than in this game, and if it’s quick enough then after wiping the drones there should be no minerals for zerglings, or to morph the sunken—Steamhammer tries to replace drones and doesn’t save up for future needs.

If some bot proves my theory, then I’ll have to update Steamhammer’s worker defense.

I signed up Steamhammer for the Starcraft AI Ladder run by Dave Churchill and his group. After Rick Kelly fixed a bug in the ladderware, I got the bot signed up and activated.

From my point of view, the main advantage of this third ongoing ladder (after SSCAIT and BASIL) is that it runs with the same tournament manager software that is used for the AIIDE tournaments. So for those who plan to participate in AIIDE 2020, it should be a good test to make sure your bot is compatible. In particular, it checks the frame time limits strictly. For now, the ladder has few participants and most of them are above average strength, which could be an advantage or a disadvantage depending on what you’re looking for. Games run at a high rate and there are fewer participants, so each participant gets more games than on BASIL.

It’s a bit barebones. It doesn’t even have a name—”Starcraft AI Ladder” is more a description, and has been used before. In particular, it does not come with any documentation, so the signup process and the features you get for it may come as a surprise. I thought it was worth writing up.

Signing up has a few steps. First, fill out the form. You have to authenticate your e-mail address. Then, according to the authentication success e-mail, you have to wait for an administrator to approve your account. For me, approval was almost instant, which made me wonder whether there was an administrator at all—but then, Steamhammer and I should be familiar. The message also says “You may upload your bot files to your profile before being approved, but you won’t be able to activate your bot to play in the ladder.” What you upload is a zip file that will be unzipped straight into the AI/ directory. You specified your BWAPI version at signup, so unlike SSCAIT you don’t include a copy of bwapi.dll.

Finally, go to your profile page, change “ladder participation” from “inactive” to “active”, and save changes. You can also fill in extra info if you like, like your URL. After the current queue of games runs out, your bot will get games queued up.

And that’s about it. The Detailed Results page is not as polished as BASIL, but it does offer the same replay download and replay viewing features. At the far right of the page (I had to scroll right) is a “Download Search Results” button that gives you a CSV file with the same information. At the bottom of your profile page, you can download your bot’s game history in the same format, or your bot’s read/ directory. For other bots, there is no access to anything but the games and results.

Since it’s running the same software, games are played in the same order as in the AIIDE tournaments. There are 10 maps—the AIIDE maps, which include 2 maps that are not among the 14 SSCAIT maps. The tournament manager takes each map in turn and plays a round-robin among the participants on that map; that is called one “round”. Then it moves on to the next map. Every so often the “tournament” is declared over and game records are reset; as I write, that happened last on 1 April.

What do I think so far? The tournament manager part of it is of course industrial strength. The UI is not great, but it’s good by the standard of academic projects, which are often done under severe time constraints and sometimes by students who are still learning. It could use an About page, or a paragraph of description somewhere. I hit one bug, so there are sure to be more that I did not see. Attention to detail is a little lacking; for example, the Home page aka Server Status lists the game number followed by the round number, while the Detailed Results page lists round number followed by game number.

Let’s suppose there are two safe spots where you want to station overlords to watch for enemy movement, a nearer one A (perhaps near the entrance to your natural) and a farther one B.

    *     A     B
    1

Overlord 1 hatches. Of course you send it toward A. It’s slow, so it takes a while to get there.

    *     A     B
      --> 1

Then overlord 2 hatches. You could send it toward the next spot B, but that’s silly.

    *     A     B
    2     1

It’s faster to send overlord 1 from A to B and replace it with overlord 2 at A.

    *     A     B
      --> 2 --> 1

Humans do this kind of overlord shuffling all the time. Here’s a TeamLiquid post showing the overlord repositioning patterns of a few pro games. I don’t know of any bots that do it. It seems like it might be tricky, no? But in fact the problem of assigning overlords, or scouting units in general, to locations is an example of the mathematical assignment problem, and there is no shortage of known algorithms to solve it either exactly or approximately. I’m still thinking about how I want to solve it in Steamhammer.

Scouting in the presence of an enemy is not as simple. To do it optimally you’d have to understand how scout timings interact with possible timings of the opponent’s build, and consider the risk to the overlord from early marines, and take into account that an enemy that sees your overlord learns something about you too—and they might actively look for the overlord, humans often do (“if you’re at that base and scouting the most efficient way to the closest natural, your overlord will be here at this time; if I see it I found you, and if not, I ruled out one base”). The optimal strategy is surely a mixed strategy, meaning that you don’t play the same every game, and there’s no way it’s possible to calculate it on the fly. You have to either pre-calculate a plan or figure it out heuristically.

The major feature for Steamhammer 3.1 will be a new scout boss which will take care of scouting, detection, and providing vision. It’s next because it meets 2 needs: First, scouting must be improved for strategy adaption. You can only predict the opponent’s moves from what you have seen, and the current scouting does not see enough. As one example, the initial scouting overlord hovers in a fixed position over the enemy base, and some protoss bots are smart enough to hide buildings from it. Second, a major weakness in current Steamhammer is that it loses overlords at a high rate. Today, overlords for different purposes are controlled by different code, and only some of the code knows about avoiding dangers. An overlord being sent to watch over a distant base goes there in a straight line, and then so does its replacement and so on, and sometimes an overlord is unassigned from a task and simply stops in a random location. With unified control, overlords will both see more and expose themselves to fewer risks.

The scout boss will also simplify the codebase. It will centralize the functions of the current scout manager and the overlord squad, and of scattered code that controls squad detectors. I expect the 3.1 version to have less total code even though it will be more capable. It will definitely have simpler interfaces with the rest of the program, I have already implemented most of that aspect.

The current scout manager that handles early game scouting knows how to control one worker and one overlord, and that’s all. The scout boss will take command of all flying detectors (including overlords) and floating buildings (I want to add this feature soon), plus whatever units you assign to it. In the opening it will automatically send the second overlord to scout a different base. If you do BBS in the center of the map, you’ll be able to scout with both SCVs to find the enemy faster, as Liquipedia recommends. Many bots already have these skills, Steamhammer has lagged behind.

3.1 should not take as long as 3.0. Unless I fall to temptation and add more features.

Another day, another fatal bug. I just replaced Steamhammer 3.0.1 with 3.0.2 to fix an infinite recursion that caused a stack overflow. It could happen if Steamhammer was facing a random opponent, depending on the order in which enemy unit types were encountered. Gotta love conditions like that. That’s 2 bugs down, who’s keeping score?

Source is updated too. Only a few lines changed.

Source code for Steamhammer 3.0.1 is now up on Steamhammer’s web page. It will take a little longer to update the documentation, since I made a passel of changes to the configuration stuff.

Part of putting up a new version is calculating the win rate for the previous version. Based on that, the SSCAIT 2019 tournament version 2.4.1 (which plays the same as version 2.4.2) was the strongest relative to the field since version 2.3 from summer 2019. Both are unequalled in Steamhammer history since version 1.2 from early days. In absolute terms, the latest version is of course the strongest.

First deadly bug eradicated! Only n more to go!

Steamhammer 3.0 has a crashing bug. It’s a null pointer dereference that can happen on startup when the gas steal skill analyzes past game records. Fixed, now I’m on Steamhammer 3.0.1. Next please!