Starcraft AI blog

Steamhammer 2.1 is uploaded. The headline feature is that terran and protoss play acceptably well again, unlike in version 2.0, so Randomhammer is updated. Zerg should also play significantly better: Zergling micro is fixed, scourge are more effective (I hope), and defilers are more active.

I reset Steamhammer’s learned data for version 2.0, because 2.0 plays differently. Since then it has learned enough to play its best against some opponents, but it is still short of equilibrium. It reached final elo 2164, which is probably lower than its elo if it had enough games under its belt. Version 2.1 is not that different from 2.0, so it is continuing with the same data.

I reset Randomhammer’s data for 2.1, since the existing data is for version 1.4.7. It will have to figure its opponents out from scratch again, which will take months.

Stand by for source. I’m way behind in updating Steamhammer’s web page. Here is the change list:

opponent model

• Fixed a bug in InformationManager that could fail to recognize an in-base proxy.

macro

• Configured WorkersPerPatch to 2.0 for terran and protoss, to reflect mineral locking. Mineral locking helps terran and protoss over zerg, because bases tend to have more workers. Reducing the maximum worker count per base while maintaining full mining efficiency means that much more cash and supply to spend on tech and army.

tactics

• Medics and tanks act in clusters. They are controlled by their own code, which needed updating.

• Bug fix: A cluster of all medics which happened to reach the front line would then continue to advance heedlessly into the enemy position and die. Now it falls back toward the base—normally it will soon merge with another cluster that is on the way. To implement this, I split the former “no fight” case into 2 cases, “I have no fighting units” and “there are no enemies nearby,” which behave differently. All medics is an example of no fighting units.

• Steamhammer knows a number of places that a cluster of units can retreat to. I moved “retreat to join up with another cluster” (which can be an advance rather than a retreat) ahead of “retreat to the location of a cluster unit which is not near the enemy” in priority order. It helps clusters merge a little more often.

• When there are many clusters, Steamhammer saves execution time by not updating all clusters every frame. It divides the clusters into “phases” and updates one phase per frame. In Steamhammer 2.0, the phases were calculated incorrectly, which contributed to bad micro (though it wasn’t the biggest cause). Fixed.

combat sim

• Combat sim scores are based on the cost of units, not the destroyScore, because destroyScore is sometimes strange. For now I set score = mineral cost + gas cost.

• Steamhammer uses the combat sim scores in an unusual way to decide who won the simulation: It’s the side that ended up with more stuff surviving. It seems illogical, but it tested better than alternatives I tried, such as the side that lost less. Still, there are pathological cases where it gives a wrong answer. I fixed this pathological case: If you lost nothing, then you won the simulation, even if you finished with less stuff surviving. (If the other side also lost nothing, then you still won, because a draw counts as a win.)

• I also changed the units included in the combat sim in special cases. 1. If you have nothing but ground units that can’t shoot up, then ignore enemy air units that can’t shoot down. Because the side with more surviving stuff wins, this can affect who wins the simulation. This fixes another pathological case, where for example zerglings might run away from corsairs. 2. If you’re scourge, include only ground enemies that can shoot up. Scourge are never afraid of the air units that they want to destroy, only of useless death by ground enemies.

At some point I’ll add the other natural special case, for air units that can’t shoot down. All this combat sim stuff could be way more sophisticated....

micro

• I fixed the biggest cause of poor micro in Steamhammer 2.0. As part of choosing an enemy target, the melee and ranged unit controllers called CanCatchUnit() to see whether the enemy unit would be able to escape if chased. It was meant to reduce goose chases. Anyway, the results of CanCatchUnit() are apparently wrong. I haven’t looked into what the trouble was, because I found that removing the calls had no effect on goose chases—long chases have become rare due to other changes. The error caused units to overlook targets that they could, and often should, attack. Zergling micro became weak, and zealot micro was worse. It’s all back to normal now.

• Vultures and wraiths would become fixated on their targets, unable to switch away even to retreat in an emergency. Fixed.

• Like clusters, defiler actions are divided into phases. There was a bug in coordinating the cluster phases and defiler phases, so that defiler actions might be skipped for a long time depending on the phase of the cluster the defiler was in. Fixing it makes defilers more active, though they still don’t swarm or plague as often as they should.

• Scourge is allowed to spread out more in regrouping. Mutalisks should usually group tight, scourge should spread out some. Formerly, all air units behaved the same.

• I made a couple adjustments to defiler plague. 1. Plague on a building was formerly worth 0.6 of plague on units with the same hit point loss; I changed the discount to 0.3, half as much, so that defilers will try harder to plague units. Buildings have a lot of hit points and threaten to dominate the scoring. (Static defense buildings are treated the same as mobile units, though.) 2. Plague gets a bonus for carrier interceptors, to exploit the plague-on-interceptor behavior, but I didn’t see Steamhammer trying hard to plague XIMP’s interceptors (only the carriers themselves). I increased the bonus by a factor of 4.

zerg

• Scourge are in their own squad, the Scourge squad. They behave somewhat better in my tests, but it’s primitive and they still have a long way to go. I mentioned a couple other improvements to scourge behavior above. It was surprisingly difficult to get scourge to do anything sensible.

• Get an evolution chamber and a spore colony for air defense when needed even if still in book. Steamhammer formerly waited until the book line came to an end before it dared defend itself. I think this will be a net gain, though it will make mistakes sometimes.

• Tweak: Enemy dragoons and dark templar loom a little larger as reasons to make static defense.

• Fixed a bug in deciding to get defilers. Battlecruisers are an excellent reason to get defilers; valkyries, not so much.

• Strongly avoid spawning mutalisks versus large valkyrie counts. Valkyries in numbers pass through mutas like they’re hardly there.

openings

• Fixed a typo in the opening name Over10Hatch2SunkHard in the AntiZealot strategy combo. When this opening was selected, Steamhammer couldn’t find it and played its default 9 pool instead, a poor choice against mass zealots.

• Added the zerg opening AntiFactoryHydra, which may be better against SAIDA’s unit mix than Steamhammer's original AntiFactory, and the terran opening 10-10-10FD in a form close to that popularized by Flash. 10-10-10 is an opening stem that gets a super-fast factory, and 10-10-10 FD is a followup that continues into an attack with 2 tanks and 8 marines, which is strong against protoss that techs too hard or expands fast.

• I configured terran and protoss counters to Naked expand by protoss. That means configuring which openings are to be tried as counters to an expected enemy plan. 10-10-10FD should be a good counter to protoss Naked expand.

debug drawing

• In the game info display (drawn in the upper left of the screen when turned on), Steamhammer 2.0 added an overall score versus this opponent, shown next to the opponent name, “2-3” meaning 2 wins and 3 losses. Steamhammer 2.1 also adds a score for the chosen opening, drawn next to the opening name. The context makes it easier to interpret Steamhammer’s choices. The numbers are specific to the matchup. Randomhammer will show different numbers depending on what race it rolled.

• Squads have 2 settable flags, “fight visible only” (only include visible enemies in the combat sim, not all known enemies) and “meatgrinder” (be more aggressive, willing to accept high losses). Visible-only is used by the Recon squad, and meatgrinder tested poorly and is not used. If the squad info display is turned on, it draws cyan V and M left of the squad’s information line if the flags are turned on.

I see that Killerbot by Marian Devecka has figured out its own way to beat SAIDA with its persistent mutalisk pressure: win 1 and win 2. I’m not sure how consistent it is, but as soon as SAIDA starts taking serious economic damage, terran only goes downhill. The update is a few days old now, and the most visible change is that Killerbot makes a few unupgraded hydralisks early, presumably only when the enemy has or is expected to get vultures. The hydras counter any early vulture or wraith tricks that terran might try. The idea is well known among human players, and Steamhammer uses it too.

I was looking at Steamhammer’s 2 hatch muta loss to SAIDA today, and thinking “With good muta micro and good decisions, zerg should win this.” I’ve been promising good muta micro for 2 years and haven’t delivered....

Update: Apparently SAIDA reacted by becoming more aggressive. It seems to have found an attack timing that works against Killerbot. Is this the same mechanism that solves rushes by adjusting timings, or a different kind of reaction? If it’s the same, the mechanism is quite general.

I have fixed the bugs affecting terran play, a bug affecting defilers, and a few bugs and weaknesses affecting all races. I also improved scourge control, and added a new opening to maintain my sanity. There is still a critical bug affecting protoss, which causes units to wander around without fighting, carrying banners “make levity not war.” Another severe weakness affects base defense, causing defenders to hang back from the action. I’ve spent the last 2 days trying to fix base defense, and it doesn’t work. I might have to think up a different solution.

Everything is good except the last 2 critical problems. Not that there’s any shortage of other weaknesses, but these 2 are so bad that they can’t be ignored. Surely they won’t resist me for long, though. Stand by!

Update the next day: I got everything working well enough, so I thought. I ran final tests and found... the newly implemented scourge micro had stopped working, though I hadn’t touched anything related. Now what has gone wrong?

SAIDA

SAIDA has been updated and is again defeating Krasi0 and Locutus. The arms race continues!

CIG 2018

I started poking at the detailed results file to figure out how to reproduce the official results exactly... then I discovered that the build order problem was wider than it first seemed. I canceled my plans. We don’t need per-map crosstables and race balance analysis of a tournament with such badly distorted results.

Steamhammer 2.1

I haven’t been working that hard on it, but I have made progress. I fixed some of the bugs introduced along with squad clustering, and found the causes of others. 2.1 should have smoother play in many cases. To say the same thing differently, Steamhammer 2.1 is suffering from feature creep, or at least bug fix creep. Hang on, it shouldn’t take too much longer.

TitanIron is, as all signs indicated, a fork of Iron. It forks from the latest Iron, the AIIDE 2017 Iron. The Iron that played in CIG 2018 was carried over from the previous CIG 2017 tournament, and is an earlier version.

#15 TitanIron crashed in 30% of its games. Its win rate was 51.46% overall, or 73.59% in non-crash games. #6 Iron itself (an earlier version) finished with 74.31% win rate, so TitanIron does not seem to be an improvement, even discounting poor code quality. Curious point: #9 LetaBot upset Iron, because LetaBot copes well with vulture and wraith harassment. But TitanIron upset LetaBot. Another curious point: TitanIron performed poorly on the map Andromeda and strongly on Destination, and about equally well on the other 3 maps. Andromeda seems a surprising map to have trouble with.

I watched some replays. In Iron-TitanIron games, the two played identical build orders until the first factory finished, when Iron made 1 vulture first while TitanIron immediately added a machine shop to get the vulture upgrades faster. The bigger difference came later, when Iron built a starport and made wraiths while TitanIron did not. I got the impression that TitanIron rarely or never goes air. The expense of going air puts TitanIron ahead in vultures for a while, so that it won some games, but it seemed that if the vulture pressure did not push Iron over the edge, then Iron would strike back and take the advantage. I watched only 1 game Locutus-TitanIron, because Locutus’s proxy pylon trick misled TitanIron just as it does Iron, and Locutus won easily. I watched a strange game against AIUR where TitanIron built a second command center far from its natural, slowly floated it over, left it in the air, and built a new command center underneath. Not all the bugs are crashing bugs. In the picture, TitanIron is losing to AIUR. Notice the nicely spaced tanks, the spider mines directly next to one tank, the barracks floating in an unhelpful position, and the spare command center in the air.

Overall, my impression is that TitanIron’s play is often similar to Iron’s. Unlike Iron, it does not make air units (it seems to have drop skills, but I didn’t run into any games with drop). Against protoss, TitanIron makes more tanks and uses them more cautiously and often clumsily. TitanIron also seems a bit fonder of expanding and growing its economy.

TitanIron adds over 4,000 lines of code to Iron. It was made by a team of 10, so that’s not an excessive amount of new code. The crash rate and the score suggest that the team was not disciplined enough in code quality and testing (of course Steamhammer crashed even more, so I don’t get to brag). Read on and you’ll see what most of the new lines of code do. I question the choices of where to spend effort. I’m not sure what the plan behind TitanIron was supposed to be.

openings

Iron does not play different openings as such. Conceptually, I see Iron as playing one opening which it varies reactively. TitanIron adds a directory opening with code which allows it to define specific build orders. The build order system is loosely modeled on Steamhammer’s, using similar names (which are not the same as UAlbertaBot’s names)—some members of the team have worked on Steamhammer forks.

TitanIron knows 3 specific build orders, named 8BB CC (1 barracks expand), SKT (tanks first), and 5BB (marines). Based on watching replays, TitanIron retains and uses Iron’s reactive opening, with modifications.

opponent-specific strategies

Iron does not recognize opponents by name. TitanIron recognizes 2 specific opponents: Locutus and PurpleSwarm. The zerg PurpleSwarm is a curious choice, since it did not play in CIG. Maybe they found it an interesting test opponent? In any case, Locutus is the main focus. It is recognized in 4 strategy classes, Locutus, SKT, TankAdvance, and Walling. In Iron’s codebase, any number of strategies can be active at the same time, and other parts of the code check by name which strategies are active to suit their actions to the situation.

	Locutus::Locutus()
	{
		std::string enemyName = him().Player()->getName();
		if (enemyName == “Locutus” || enemyName == “locutus”)
		{
			me().SetOpening(“SKT”);
			m_detected = true;
		}
	}

SKT (defined in opening/opening.cpp) builds a barracks and refinery on 11, then adds 2 factories and gets tanks before vultures. It sounds as though it should refer to the “SK terran” unit mix of marines and medics with science vessels and no tanks, but it doesn’t. The Locutus strategy turns itself off (if I understand the code’s intent correctly) after all 4 dark templar of Locutus’s DT drop are dead, or after frame 13,000. Various buildings (barracks, factory, e-bay, turret) recognize when the Locutus strategy is active and carry out scripted actions. The name “Locutus” also activates the TankAdvance strategy which seems to first guard the natural and then perform a tank push, and deactivates the Walling strategy after frame 11,000 or when above 12 marines, causing the barracks to lift and open the wall.

TitanIron scored a total of 1 win out of 125 games against Locutus, so the special attention does not seem to have paid off.

PurpleSwarm gets less attention. (The question is why it got any.)

	Purpleswarm::Purpleswarm()
	{
		std::string enemyName = him().Player()->getName();
		if (him().Race() == BWAPI::Races::Zerg &&
			(enemyName == “Purpleswarm” || enemyName == “purpleswarm” || enemyName == “PurpleSwarm”))
		{
			me().SetOpening(“5BB”);
			m_detected = true;
		}
	}

5BB (also defined in opening/opening.cpp) builds barracks on 10 and 12, later adding a third barracks and training marines up to 30. I don’t see any other cases where TitanIron uses this opening. The rest of the code has no special instructions for PurpleSwarm or 5BB.

other new files

Besides the opening directory, TitanIron adds 16 files in the strategy and behavior directories, defining 8 strategies and behaviors. The added strategies are:

• GuardNatural
• Locutus
• PurpleSwarm
• SKT
• TankAdvance

These are remarkable for being all and only the classes used when Locutus or PurpleSwarm is recognized. Do they have any other purpose? I didn’t dig into it, but I suspect that GuardNatural and TankAdvance may be used more widely against protoss.

The added unit behaviors are:

• GuardLoc - guard a location
• HangingBase - carry out drops
• SKTAttack - related to SKT

GuardLoc has some connection with GuardNatural, but seems to be a general-purpose behavior, as far as I can tell. I’m not sure how HangingBase got its name.

The new opening directory and the newly added strategy and behavior files account for about 2/3rds of the lines of code added to Iron. The rest is scattered through the code and not as easy to inventory, but surely much of it must be uses of the new openings, strategies, and behaviors. I do see a lot of changes related to expanding.

SAIDA is holding its position as #1 on SSCAIT, but it is under constant attack from other bots and loses some games. On the one hand, SAIDA has weaknesses against early harassment and timing attacks, especially if the opponent denies scouting. On the other hand, SAIDA appears to have a learning mechanism that recognizes rush timing and figures out a defense. The SAIDA page describes it as “He also catches perfect rush timing by using information he collected.” That’s a vague description, but the behavior does appear to involve learning from experience. MicroDK noted that SAIDA writes data only after it loses; this must be why. For example, BananaBrain tried a dark templar rush and won a series of games, but finally the learning kicked in and SAIDA figured out how to get turrets in time to stop it (SAIDA’s code was not updated). Since then, BananaBrain has mostly lost games, defeating SAIDA only once, in this game where the turret was seconds late.

Other examples include PurpleSpirit winning one game with BBS then being unable to win with it again, and Krasi0 winning with its fast barracks marine cheese with similar results.

In the latest attacks, Locutus won with center gates, making only 2 zealots before switching into dragoons, and Krasi0 added a bunker to its marine cheese to overcome SAIDA’s vulture counter to the marines (SAIDA crashed this game). Will SAIDA learn to defeat these tricks too? I don’t know, let’s find out!

How powerful is this learning mechanism? Surely there must be attacks that it cannot figure out how to forestall—or can’t figure out in reasonable time. If you find 2 winning tricks and switch between them, can it learn to defend against both? If you DT rush once so that it learns to get early turrets, does it get early turrets for the rest of time after you switch back to regular play? The unnecessary turrets give you a small advantage, and at a high level of play, small advantages are big.

Here are some of the weaknesses I see in SAIDA’s play.

• Poor defense against unscouted early attacks, mitigated by the learning mechanism. SAIDA loses more SCVs than it should.
• SAIDA recovers poorly from economic setbacks. It does not replenish lost SCVs as well as it should, and stops expanding after a while. If you gain an early lead, you can win by holding on and waiting for SAIDA to mine out.
• SAIDA is vulnerable to mine drags. It sees no danger in having its spider mines and its forces next to each other. It will even place mines in its mineral line, begging you to blow up its SCVs.
• SAIDA does not know how to build in safe locations. On some maps, like Moon Glaive, parts of the main base are easily sieged from outside. Krasi0 has won games by blasting down factories that are in range, and SAIDA keeps trying to rebuild in places that are also in range.
• SAIDA is consistent and predictable. It varies to counter the opponent, but at heart always plays the same strategy and the same tactics. The dropships always fly along the edge.

SAIDA also has great strengths. The greatest may be the big red animated arrow that points out the main attack position. As long as SAIDA has a monopoly on big animated arrows, I think it will remain #1.

Locutus only recorded 8 games. It is configured to retain 200 game records, and I read the source code and verified that Locutus does not intentionally drop game records before the limit of 200. Recording exactly 8 games is the same problem that McRave suffered, and must be due to CIG problems. I don't know what the underlying problem was. My suspicion is that CIG organizers or tournament software may have accidentally or mistakenly cleared learning data for some bots. If that is what happened, and it happened once 8 games before the end of the tournament, it seems likely that it happened more than once. Who knows, though? The error might be somewhere else. Maybe they mistakenly shipped us data from after round 8 instead of round 125—in that case the tournament may have run normally, and only the data about it is wrong.

Locutus has prepared data for some opponents, stored in the AI directory. When Locutus finds it has no game records for a given opponent, it looks in AI to see if it has prepared data, and if so, it reads in those game records. At the end of the game, it writes out the prepared game records along with the record for the newly played game, and from then on the prepared records are treated like any others and retained unless and until the 200 record limit is passed.

How many other bots were affected by the 8 game problem?

---

Here is Locutus’s prepared data. Against some opponents, like McRave, Locutus picks out openings to avoid at first. If other openings don’t win either, I’m sure Locutus will come back and try these anyway. Against others, it picks out winners to try first. For some, it simply provides data. Most but not all of the prepared data is for opponents which were carried over from last year, for which pre-learning is sure to be helpful... if it is done on the same maps.

#3 mcrave

opening	games	wins
12Nexus5ZealotFECannons	1	0%
Turtle	1	0%
2 openings	2	0%

#6 iron

opening	games	wins
DTDrop	14	100%
1 openings	14	100%

#7 zzzkbot

opening	games	wins
ForgeExpand5GateGoon	2	100%
1 openings	2	100%

#11 ualbertabot

opening	games	wins
4GateGoon	1	0%
9-9GateDefensive	2	50%
ForgeExpand5GateGoon	15	93%
3 openings	18	83%

#14 aiur

opening	games	wins
4GateGoon	3	100%
9-9GateDefensive	1	100%
2 openings	4	100%

#16 ziabot

opening	games	wins
9-9GateDefensive	1	0%
ForgeExpand5GateGoon	1	100%
2 openings	2	50%

#19 terranuab

opening	games	wins
DTDrop	10	100%
1 openings	10	100%

#21 opprimobot

opening	games	wins
DTDrop	11	100%
1 openings	11	100%

#22 sling

opening	games	wins
ForgeExpand5GateGoon	2	100%
1 openings	2	100%

#23 srbotone

opening	games	wins
DTDrop	7	100%
PlasmaProxy2Gate	1	100%
2 openings	8	100%

#24 bonjwa

opening	games	wins
DTDrop	6	100%
PlasmaProxy2Gate	1	100%
2 openings	7	100%

overall

	total		PvT		PvP		PvZ		PvR
opening	games	wins	games	wins	games	wins	games	wins	games	wins
12Nexus5ZealotFECannons	1	0%			1	0%
4GateGoon	4	75%			3	100%			1	0%
9-9GateDefensive	4	50%			1	100%	1	0%	2	50%
DTDrop	48	100%	48	100%
ForgeExpand5GateGoon	20	95%					5	100%	15	93%
PlasmaProxy2Gate	2	100%	2	100%
Turtle	1	0%			1	0%
total	80	92%	50	100%	6	67%	6	83%	18	83%
openings played	7		2		4		2		3

---

Here is Locutus’s learned data. In every case, the number of games recorded is 8 plus the number of games in the prepared data. With only 8 games there is not much to go on, but the prepared data does seem to have helped Locutus choose successful openings.

#2 purplewave

opening	games	wins
12Nexus5ZealotFECannons	1	0%
4GateGoon	1	0%
9-9GateDefensive	5	80%
Proxy9-9Gate	1	0%
4 openings	8	50%

#3 mcrave

opening	games	wins
12Nexus5ZealotFECannons	1	0%
4GateGoon	3	67%
Proxy9-9Gate	5	100%
Turtle	1	0%
4 openings	10	70%

#4 tscmoo

opening	games	wins
4GateGoon	1	0%
9-9GateDefensive	1	0%
ForgeExpand5GateGoon	4	25%
Proxy9-9Gate	2	50%
4 openings	8	25%

#5 isamind

opening	games	wins
4GateGoon	6	83%
9-9GateDefensive	1	100%
Proxy9-9Gate	1	100%
3 openings	8	88%

#6 iron

opening	games	wins
DTDrop	22	95%
1 openings	22	95%

#7 zzzkbot

opening	games	wins
ForgeExpand5GateGoon	7	86%
ForgeExpandSpeedlots	2	50%
Proxy9-9Gate	1	0%
3 openings	10	70%

#8 microwave

opening	games	wins
ForgeExpand5GateGoon	8	100%
1 openings	8	100%

#9 letabot

opening	games	wins
DTDrop	8	88%
1 openings	8	88%

#10 megabot

opening	games	wins
4GateGoon	8	100%
1 openings	8	100%

#11 ualbertabot

opening	games	wins
4GateGoon	1	0%
9-9GateDefensive	2	50%
ForgeExpand5GateGoon	23	91%
3 openings	26	85%

#12 tyr

opening	games	wins
4GateGoon	8	100%
1 openings	8	100%

#13 ecgberht

opening	games	wins
DTDrop	8	88%
1 openings	8	88%

#14 aiur

opening	games	wins
12Nexus5ZealotFECannons	1	0%
2GateDTExpo	1	100%
4GateGoon	5	80%
9-9GateDefensive	1	100%
Proxy9-9Gate	4	75%
5 openings	12	75%

#15 titaniron

opening	games	wins
DTDrop	8	100%
1 openings	8	100%

#16 ziabot

opening	games	wins
9-9GateDefensive	1	0%
ForgeExpand5GateGoon	6	83%
ForgeExpandSpeedlots	2	50%
Proxy9-9Gate	1	100%
4 openings	10	70%

#17 steamhammer

opening	games	wins
ForgeExpand5GateGoon	8	100%
1 openings	8	100%

#18 overkill

opening	games	wins
ForgeExpand5GateGoon	8	100%
1 openings	8	100%

#19 terranuab

opening	games	wins
DTDrop	18	100%
1 openings	18	100%

#20 cunybot

opening	games	wins
ForgeExpand5GateGoon	8	100%
1 openings	8	100%

#21 opprimobot

opening	games	wins
DTDrop	19	100%
1 openings	19	100%

#22 sling

opening	games	wins
ForgeExpand5GateGoon	10	100%
1 openings	10	100%

#23 srbotone

opening	games	wins
DTDrop	15	100%
PlasmaProxy2Gate	1	100%
2 openings	16	100%

#24 bonjwa

opening	games	wins
DTDrop	14	100%
PlasmaProxy2Gate	1	100%
2 openings	15	100%

#25 stormbreaker

opening	games	wins
ForgeExpand5GateGoon	8	100%
1 openings	8	100%

#26 korean

opening	games	wins
ForgeExpand5GateGoon	8	100%
1 openings	8	100%

#27 salsa

opening	games	wins
ForgeExpand5GateGoon	8	100%
1 openings	8	100%

overall

	total		PvT		PvP		PvZ		PvR
opening	games	wins	games	wins	games	wins	games	wins	games	wins
12Nexus5ZealotFECannons	3	0%			3	0%
2GateDTExpo	1	100%			1	100%
4GateGoon	33	82%			31	87%			2	0%
9-9GateDefensive	11	64%			7	86%	1	0%	3	33%
DTDrop	112	97%	112	97%
ForgeExpand5GateGoon	106	93%					79	97%	27	81%
ForgeExpandSpeedlots	4	50%					4	50%
PlasmaProxy2Gate	2	100%	2	100%
Proxy9-9Gate	15	73%			11	82%	2	50%	2	50%
Turtle	1	0%			1	0%
total	288	90%	114	97%	54	80%	86	93%	34	71%
openings played	10		2		6		4		4

I wrote a new script to analyze Steamhammer’s learning data. A couple points: 1. Steamhammer crashed in nearly half of its games in CIG 2018. It can’t save learning data after a crash, so against some opponents Steamhammer had few opportunities to experiment. The number of crashes varied strongly depending on the opponent. 2. Steamhammer was set to remember the previous 100 games, since I figure there’s no play advantage to remembering more. The tournament was 125 rounds long. So in the tables below, “100 games” means that Steamhammer played at least 100 games without crashing, and up to 25 games may have been dropped, the early games. Against some weak opponents, Steamhammer learned, within 25 games, how to win 100% of the remaining games, and those tables give a 100% win rate for remembered games. Steamhammer did not score 100% against any opponent overall; it always had some losses in early games.

I should be able to run the same analysis for Steamhammer forks which retain Steamhammer’s opponent model file format.

#1 Locutus

opening	games	wins
2HatchHydraBust	1	0%
3HatchHydraExpo	2	0%
3HatchLingBust	1	0%
3HatchLingExpo	1	0%
4HatchBeforeGas	1	0%
OverpoolSpeed	9	56%
6 openings	15	33%

A mystery is solved. Why was Steamhammer’s crash rate higher than I expected? Because many opponents learned to make Steamhammer crash. A crash for the opponent is a win, and the bot doesn’t care how it wins, so if it can learn a plan that makes the opponent crash reliably, it will. The stronger opponents tend to be learning bots, so Steamhammer crashed more often on average against strong opponents. This also means that my glib conclusion that Steamhammer won 66% of non-crash games, so it seems to have kept up with general progress is not sound. The non-crash games were mostly against weak opponents.

Locutus was lucky that it could figure out how to break Steamhammer. As Bruce mentioned in a comment, this Locutus version had a bug when facing certain zergling timings, and Steamhammer quickly figured out how to exploit the bug. It’s possible that Steamhammer minus the crash would have upset Locutus.

#2 PurpleWave

opening	games	wins
11Gas10PoolMuta	1	0%
3HatchHydra	3	0%
3HatchLurker	1	0%
4PoolSoft	1	0%
7Pool12Hatch	1	0%
7PoolSoft	1	0%
9Hatch8Pool	1	0%
9HatchExpo9Pool9Gas	1	0%
9PoolSpeed	1	0%
AntiFactory	1	0%
Over10Hatch	6	0%
Over10Hatch1Sunk	7	0%
Over10Hatch2Sunk	18	0%
Over10HatchBust	1	0%
Over10HatchSlowLings	4	0%
OverhatchMuta	1	0%
OverpoolHatch	1	0%
OverpoolTurtle	3	0%
ZvP_3HatchPoolHydra	2	0%
ZvP_4HatchPoolHydra	1	0%
ZvT_12PoolMuta	1	0%
ZvZ_Overpool11Gas	1	0%
22 openings	58	0%

PurpleWave shut out Steamhammer. It didn’t learn to make Steamhammer crash because every game was a win for it anyway. Steamhammer desperately tried alternatives all over the map, including crazy all-ins and openings intended for ZvT and ZvZ, and nothing worked.

#3 McRave

opening	games	wins
11Gas10PoolLurker	1	0%
4HatchBeforeGas	1	0%
9HatchExpo9Pool9Gas	1	0%
9PoolSpeed	5	100%
ZvP_3HatchPoolHydra	2	0%
5 openings	10	50%

#4 tscmoo

opening	games	wins
9PoolExpo	1	0%
9PoolHatch	1	0%
9PoolSunkHatch	1	0%
AntiFact_2Hatch	1	0%
Over10Hatch2Sunk	1	0%
OverhatchExpoLing	13	15%
OverpoolSpeed	22	23%
7 openings	40	18%

#5 ISAMind

opening	games	wins
3HatchHydraExpo	1	0%
4HatchBeforeGas	1	0%
OverpoolSpeed	4	100%
ZvP_2HatchMuta	7	0%
ZvP_3HatchPoolHydra	6	0%
5 openings	19	21%

#6 Iron

opening	games	wins
2HatchHydra	1	0%
3HatchLingExpo	2	0%
4PoolHard	1	0%
6PoolSpeed	1	0%
9Hatch8Pool	1	0%
9HatchMain9Pool9Gas	1	0%
9PoolSunkSpeed	1	0%
AntiFact_13Pool	4	0%
AntiFact_2Hatch	83	12%
AntiFactory	1	0%
Over10Hatch	1	0%
PurpleSwarmBuild	1	0%
ZvP_2HatchMuta	1	0%
ZvT_12PoolMuta	1	0%
14 openings	100	10%

Iron is not a learning bot, so it did not learn to crash Steamhammer. Still, these results show a weakness in Steamhammer: Its best opening against Iron is AntiFactory, which it tried only once in these 100 games. Steamhammer did not explore enough. I tried to fix the weakness in Steamhammer 2.0.

#7 ZZZKBot

opening	games	wins
11Gas10PoolMuta	1	0%
8Pool	7	29%
9HatchMain9Pool9Gas	1	0%
9PoolSpeed	1	0%
OverhatchMuta	1	0%
Overpool+1	1	0%
OverpoolSpeed	1	0%
ZvZ_12HatchMain	2	0%
ZvZ_12Pool	1	0%
ZvZ_12PoolLing	48	58%
ZvZ_Overgas9Pool	2	0%
ZvZ_Overpool9Gas	2	0%
12 openings	68	44%

#8 Microwave

opening	games	wins
9PoolSunkHatch	5	80%
9PoolSunkSpeed	27	67%
OverpoolSunk	1	0%
OverpoolTurtle	3	33%
ZvZ_12PoolLing	1	0%
5 openings	37	62%

This looks like successful learning. Too bad Steamhammer only successfully played 37 of the 125 games.

#9 LetaBot

opening	games	wins
11Gas10PoolLurker	1	0%
2HatchLurkerAllIn	4	0%
3HatchHydraExpo	1	0%
3HatchLurker	13	38%
9HatchExpo9Pool9Gas	45	36%
OverpoolLurker	13	31%
ZvP_2HatchMuta	1	0%
ZvT_12PoolMuta	1	0%
ZvT_13Pool	1	0%
ZvT_3HatchMuta	1	0%
10 openings	81	31%

#10 MegaBot

opening	games	wins
11Gas10PoolLurker	1	0%
3HatchHydra	1	0%
3HatchHydraExpo	1	0%
3HatchLingExpo	21	43%
Over10Hatch	1	0%
OverhatchExpoLing	1	100%
ZvP_3HatchPoolHydra	2	0%
7 openings	28	36%

#11 UAlbertaBot

opening	games	wins
3HatchLingExpo	1	0%
5PoolHard2Player	1	0%
9PoolExpo	1	0%
9PoolSpeed	1	0%
9PoolSunkHatch	46	33%
9PoolSunkSpeed	29	48%
Over10Hatch1Sunk	2	0%
OverpoolSpeed	1	0%
ZvZ_Overpool9Gas	1	0%
9 openings	83	35%

#12 Tyr

opening	games	wins
9PoolHatch	5	100%
ZvP_3HatchPoolHydra	5	0%
2 openings	10	50%

#13 Ecgberht

opening	games	wins
11Gas10PoolLurker	10	50%
2HatchLurker	23	61%
2HatchLurkerAllIn	44	75%
Over10HatchBust	3	33%
OverpoolLurker	8	75%
OverpoolSpeed	3	33%
ZvT_13Pool	1	0%
7 openings	92	65%

#14 Aiur

opening	games	wins
11Gas10PoolLurker	1	100%
5PoolHard2Player	1	100%
9PoolSunkHatch	1	100%
9PoolSunkSpeed	2	100%
Over10Hatch	1	0%
Over10Hatch1Sunk	2	50%
Over10Hatch2Hard	1	100%
Over10HatchSlowLings	1	100%
OverpoolSpeed	2	100%
OverpoolTurtle	3	67%
10 openings	15	80%

#15 TitanIron

opening	games	wins
3HatchLingBust	1	0%
AntiFact_13Pool	6	50%
AntiFact_2Hatch	1	0%
AntiFactory	74	42%
Over10Hatch2Sunk	1	0%
OverhatchExpoMuta	1	0%
OverpoolLurker	1	0%
ZvZ_Overgas9Pool	14	21%
ZvZ_Overpool9Gas	1	0%
9 openings	100	37%

This selection of openings implies that TitanIron plays a factory-first build against zerg, like Iron, and is a non-learning bot, like Iron. Later I’ll look into the source and find out for sure.

#16 Ziabot

opening	games	wins
11Gas10PoolMuta	4	25%
2.5HatchMuta	1	0%
3HatchHydraBust	1	0%
6PoolSpeed	1	0%
8Pool	7	71%
9Hatch8Pool	1	0%
9PoolHatch	4	50%
ZvP_2HatchTurtle	1	0%
ZvZ_12Pool	1	0%
ZvZ_12PoolMain	16	25%
ZvZ_Overpool11Gas	10	50%
ZvZ_Overpool9Gas	53	74%
12 openings	100	56%

Low win rates against Zia and some other opponents suggest to me that Steamhammer had other new weaknesses besides crashing. I think Steamhammer should score over 80% against Zia.

#18 Overkill

opening	games	wins
11Gas10PoolMuta	10	90%
4PoolHard	23	96%
6PoolSpeed	28	100%
9Hatch8Pool	1	0%
OverhatchLing	2	50%
OverpoolSpeed	13	92%
ZvZ_12HatchExpo	2	50%
ZvZ_12PoolMain	1	0%
8 openings	80	91%

#19 TerranUAB

opening	games	wins
2HatchLurker	52	90%
AntiFact_13Pool	8	88%
AntiFact_2Hatch	9	78%
AntiFactory	31	90%
4 openings	100	89%

#20 CUNYbot

opening	games	wins
11Gas10PoolMuta	9	78%
OverhatchLing	34	97%
ZvZ_12PoolLing	27	96%
ZvZ_Overgas9Pool	1	0%
ZvZ_Overpool9Gas	19	89%
5 openings	90	92%

#21 OpprimoBot

opening	games	wins
11Gas10PoolLurker	3	67%
2HatchLurker	2	50%
2HatchLurkerAllIn	6	83%
6PoolSpeed	19	100%
OverpoolLurker	1	0%
OverpoolSpeed	5	80%
ZvT_12PoolMuta	20	95%
ZvT_3HatchMuta	20	100%
ZvT_3HatchMutaExpo	24	100%
9 openings	100	94%

#22 Sling

opening	games	wins
4PoolHard	4	75%
4PoolSoft	6	100%
5PoolHard2Player	3	100%
ZvZ_12HatchMain	1	0%
ZvZ_Overgas9Pool	1	0%
5 openings	15	80%

The selection of fast rush openings suggests that Sling played a macro strategy which was countered by fast rushes. But I don’t want to draw strong conclusions based on 15 non-crash games out of 125.

#23 SRbotOne

opening	games	wins
11Gas10PoolLurker	14	93%
2HatchLurker	10	90%
2HatchLurkerAllIn	10	90%
3HatchLurker	17	100%
4PoolSoft	17	100%
5PoolHard	7	100%
9HatchExpo9Pool9Gas	4	75%
9PoolLurker	3	100%
OverpoolLurker	5	100%
9 openings	87	95%

The wide range of lurker openings means that SRbotOne by Johan Kayser fought with mostly barracks units. Well, we already knew that.

#24 Bonjwa

opening	games	wins
9PoolExpo	6	100%
9PoolSunkHatch	5	100%
9PoolSunkSpeed	5	100%
AntiFact_2Hatch	3	100%
AntiFactory	5	100%
ZvT_2HatchMuta	1	100%
6 openings	25	100%

#25 Stormbreaker

opening	games	wins
11Gas10PoolMuta	1	100%
4PoolHard	1	100%
9PoolSunkHatch	8	100%
9PoolSunkSpeed	8	100%
OverhatchLing	1	100%
OverhatchMuta	7	100%
OverpoolSpeed	1	100%
OverpoolSunk	7	100%
ZvZ_12HatchExpo	2	100%
ZvZ_12HatchMain	3	100%
ZvZ_12PoolLing	1	100%
ZvZ_12PoolMain	3	100%
12 openings	43	100%

#26 Korean

opening	games	wins
4PoolHard	1	100%
4PoolSoft	3	100%
5PoolHard	5	100%
5PoolHard2Player	3	100%
5PoolSoft	1	100%
6PoolSpeed	6	100%
OverhatchLing	9	100%
OverhatchMuta	12	100%
ZvZ_12HatchExpo	13	100%
ZvZ_12HatchMain	16	100%
ZvZ_12PoolLing	14	100%
ZvZ_12PoolMain	17	100%
12 openings	100	100%

#27 Salsa

opening	games	wins
4PoolHard	2	100%
4PoolSoft	4	100%
5PoolHard	7	100%
5PoolHard2Player	1	100%
5PoolSoft	1	100%
6PoolSpeed	8	100%
OverhatchLing	11	100%
OverhatchMuta	8	100%
ZvZ_12HatchExpo	12	100%
ZvZ_12HatchMain	20	100%
ZvZ_12PoolLing	13	100%
ZvZ_12PoolMain	12	100%
ZvZ_Overgas9Pool	1	100%
13 openings	100	100%

overall

	total		ZvT		ZvP		ZvZ		ZvR
opening	games	wins	games	wins	games	wins	games	wins	games	wins
11Gas10PoolLurker	31	68%	28	71%	3	33%
11Gas10PoolMuta	26	69%			1	0%	25	72%
2.5HatchMuta	1	0%					1	0%
2HatchHydra	1	0%	1	0%
2HatchHydraBust	1	0%			1	0%
2HatchLurker	87	82%	87	82%
2HatchLurkerAllIn	64	73%	64	73%
3HatchHydra	4	0%			4	0%
3HatchHydraBust	1	0%					1	0%
3HatchHydraExpo	5	0%	1	0%	4	0%
3HatchLingBust	2	0%	1	0%	1	0%
3HatchLingExpo	25	36%	2	0%	22	41%			1	0%
3HatchLurker	31	71%	30	73%	1	0%
4HatchBeforeGas	3	0%			3	0%
4PoolHard	32	91%	1	0%			31	94%
4PoolSoft	31	97%	17	100%	1	0%	13	100%
5PoolHard	19	100%	7	100%			12	100%
5PoolHard2Player	9	89%			1	100%	7	100%	1	0%
5PoolSoft	2	100%					2	100%
6PoolSpeed	63	97%	20	95%			43	98%
7Pool12Hatch	1	0%			1	0%
7PoolSoft	1	0%			1	0%
8Pool	14	50%					14	50%
9Hatch8Pool	4	0%	1	0%	1	0%	2	0%
9HatchExpo9Pool9Gas	51	37%	49	39%	2	0%
9HatchMain9Pool9Gas	2	0%	1	0%			1	0%
9PoolExpo	8	75%	6	100%					2	0%
9PoolHatch	10	70%			5	100%	4	50%	1	0%
9PoolLurker	3	100%	3	100%
9PoolSpeed	8	62%			6	83%	1	0%	1	0%
9PoolSunkHatch	66	50%	5	100%	1	100%	13	92%	47	32%
9PoolSunkSpeed	72	65%	6	83%	2	100%	35	74%	29	48%
AntiFact_13Pool	18	56%	18	56%
AntiFact_2Hatch	97	21%	96	21%					1	0%
AntiFactory	112	57%	111	58%	1	0%
Over10Hatch	9	0%	1	0%	8	0%
Over10Hatch1Sunk	11	9%			9	11%			2	0%
Over10Hatch2Hard	1	100%			1	100%
Over10Hatch2Sunk	20	0%	1	0%	18	0%			1	0%
Over10HatchBust	4	25%	3	33%	1	0%
Over10HatchSlowLings	5	20%			5	20%
OverhatchExpoLing	14	21%			1	100%			13	15%
OverhatchExpoMuta	1	0%	1	0%
OverhatchLing	57	96%					57	96%
OverhatchMuta	29	93%			1	0%	28	96%
Overpool+1	1	0%					1	0%
OverpoolHatch	1	0%			1	0%
OverpoolLurker	28	54%	28	54%
OverpoolSpeed	61	56%	8	62%	15	73%	15	87%	23	22%
OverpoolSunk	8	88%					8	88%
OverpoolTurtle	9	33%			6	33%	3	33%
PurpleSwarmBuild	1	0%	1	0%
ZvP_2HatchMuta	9	0%	2	0%	7	0%
ZvP_2HatchTurtle	1	0%					1	0%
ZvP_3HatchPoolHydra	17	0%			17	0%
ZvP_4HatchPoolHydra	1	0%			1	0%
ZvT_12PoolMuta	23	83%	22	86%	1	0%
ZvT_13Pool	2	0%	2	0%
ZvT_2HatchMuta	1	100%	1	100%
ZvT_3HatchMuta	21	95%	21	95%
ZvT_3HatchMutaExpo	24	100%	24	100%
ZvZ_12HatchExpo	29	97%					29	97%
ZvZ_12HatchMain	42	93%					42	93%
ZvZ_12Pool	2	0%					2	0%
ZvZ_12PoolLing	104	79%					104	79%
ZvZ_12PoolMain	49	73%					49	73%
ZvZ_Overgas9Pool	19	21%	14	21%			5	20%
ZvZ_Overpool11Gas	11	45%			1	0%	10	50%
ZvZ_Overpool9Gas	76	74%	1	0%			74	76%	1	0%
total	1596	64%	685	62%	155	26%	633	82%	123	29%
openings played	69		37		36		31		13

This summary table took me hours to get right, so I hope it's useful.

Steamhammer played 69 openings in 1596 non-crash games, which is around 2/3rds of the openings it knows. No single matchup had more than 37 different openings. There were far more games against terran and zerg than against protoss and random, partly due to the crashing pattern. Against the random opponents (Tscmoo and UAlbertaBot), it settled on mostly general-purpose openings, as you might expect. Its best matchup was ZvZ, with a Jaedong-like 82% win rate (and lately, Jaedong crashes half the time too, so they’re just alike).

Openings that were both popular and successful include 2HatchLurker and 2HatchLurkerAllIn versus terran, 6PoolSpeed with a 97% win rate against mostly weak opponents, 9PoolSunkSpeed used across all matchups, and ZvZ specialties OverhatchLing, ZvZ_12PoolLing, and ZvZ_Overpool9Gas. None of the opening choices surprises me, though some of the win rates do.

Did Overkill actually perform much worse in CIG 2018 than in past years? Here are the bots carried over from 2017 to 2018, with win rates in both years, with numbers from the official results. We see that Overkill collapsed in win rate from 2017 to 2018, a far bigger change than any other bot. Iron performed poorly in 2017 because it failed on the map Hitchhiker. Other bots mostly had modestly lower win rates in the stronger field this year. My 2017 crosstable was calculated from the detailed results, which included some corrupted data and are a little different from the official results—except for Sling, which was a lot different: 26.07% in 2017 versus its official 18.08%, reducing its year-over-year difference.

bot	2017	2018
UAlbertaBot	65.59%	60.58%
Overkill	62.75%	34.68%
Ziabot	61.75%	51.08%
Iron	61.62%	74.31%
Aiur	59.83%	51.54%
TerranUAB	36.78%	34.40%
SRbotOne	34.14%	24.37%
OpprimoBot	30.69%	27.11%
Bonjwa	30.67%	23.57%
Sling	18.08%	26.52%
Salsa	4.64%	1.54%

Was the difference due to the maps? N0. In 2017, Overkill scored 57% or more on every map (CIG 2017 bots x maps). In 2018, Overkill scored 38% or below on every map (official results). And 3 of the 5 maps were the same: Tau Cross, Andromeda, and Python.

Did they run different versions of Overkill? The source that they distributed for Overkill is identical in both years. Theoretically they might have run something different by mistake—but it produced the expected files in the write directory, so it would be a surprise.

Finally I downloaded the Overkill replays and watched some. The poor bot’s build orders were severely distorted, skipping over drones and buildings. It would do things like take gas on 7 and then stop all construction, or follow a normal-ish build but drop many drones so that its economy was anemic. Sometimes drones moved erratically instead of mining. It looked similar to play I’ve seen from Steamhammer when latency stuff is way out of whack. Of the games I looked at, some were hopelessly muddled, some were close to normal with only occasional dropped drones, and none were 100% good. I don’t know what the problem was, something corrupted or a server setting that Overkill could not cope with, but whatever it was, Overkill was badly broken and far short of its normal strength.

43864-OVER_ZIAB.REP (Overkill’s last game of the tournament) is an example replay that shows the problems.

It’s possible that some other bots may have been affected. If the difference was in a server setting that Overkill was not ready for, then it would be surprising if every other bot was ready.

After analyzing AIUR yesterday, I ran a similar (but much simpler) analysis for the classic zerg #18 Overkill. The version in CIG 2018 has not been updated since 2015 and is the same version that still plays on SSCAIT. In 2015 it was a sensation, placing 3rd in both CIG and AIIDE—its place of 18 in this tournament, with about 35% win rate, suggests huge progress over the past 3 years. But keep reading; Overkill appears to have been broken in this tournament. I did this analysis once before: See what Overkill learned in AIIDE 2015.

Classic Overkill knows 3 openings, a 9 pool opening which stays on one base for a good time, and 10- and 12-hatch openings to get mutalisks first. When it chooses 9 pool, that means that the opponent is either rushing (so the 9 pool is necessary to defend) or is being too greedy (which the 9 pool can exploit). Overkill counts some games twice in an attempt to learn faster, so sometimes its total game count is larger than the number of rounds in the tournament (125).

	NinePoolling		TenHatchMuta		TwelveHatchMuta		total
opponent	n	win	n	win	n	win	n	win
#1 Locutus	42	0%	42	0%	41	0%	125	0%
#2 PurpleWave	43	0%	43	0%	42	0%	128	0%
#3 McRave	44	0%	44	0%	43	0%	131	0%
#4 tscmoo	40	0%	40	0%	47	2%	127	1%
#5 ISAMind	42	0%	42	0%	41	0%	125	0%
#6 Iron	54	7%	32	0%	39	3%	125	4%
#7 ZZZKBot	47	2%	39	0%	47	2%	133	2%
#8 Microwave	54	6%	35	0%	42	2%	131	3%
#9 LetaBot	52	6%	33	0%	40	2%	125	3%
#10 MegaBot	60	12%	24	0%	41	7%	125	8%
#11 UAlbertaBot	41	0%	41	0%	48	2%	130	1%
#12 Tyr	40	0%	39	0%	47	2%	126	1%
#13 Ecgberht	57	16%	24	4%	42	12%	123	12%
#14 Aiur	94	34%	14	7%	17	12%	125	28%
#15 TitanIron	36	11%	20	0%	69	16%	125	12%
#16 Ziabot	16	0%	16	0%	93	23%	125	17%
#17 Steamhammer	107	48%	7	0%	10	10%	124	42%
#19 TerranUAB	24	67%	3	0%	98	83%	125	78%
#20 CUNYbot	18	44%	6	17%	101	66%	125	61%
#21 OpprimoBot	36	67%	3	0%	86	76%	125	71%
#22 Sling	67	46%	6	0%	52	42%	125	42%
#23 SRbotOne	23	74%	4	25%	95	89%	122	84%
#24 Bonjwa	75	92%	4	25%	46	87%	125	88%
#25 Stormbreaker	70	91%	2	0%	53	87%	125	88%
#26 Korean	77	99%	2	0%	46	93%	125	95%
#27 Salsa	46	100%	32	94%	46	100%	124	98%
total	1305	36%	597	6%	1372	40%	3274	32%

The 10 hatch opening was useless in this tournament—against every opponent, 10 hatch was the worst choice, at best tying for 0. In 2015, 10 hatch was about as successful as the other openings.

Signs are that something was wrong with Overkill in this tournament. In AIIDE 2015, then #3 Overkill scored 23% against then #4 UAlbertaBot, 68% against #5 AIUR, and 99% against #17 OpprimoBot. In CIG 2018, it was 1.6% against UAlbertaBot, 28% against AIUR, 71% against OpprimoBot. All versions appear to be the same in both tournaments—I didn’t look closely, but I did unpack the sources and check dates (in particular, Overkill has file change dates up to 8 October 2015 in both tournaments). Overkill had 14 crash games in CIG 2018, not enough to account for the difference. It’s hard to believe that the maps could have shifted results that much.

Tomorrow: What went wrong with Overkill?

Here is what the classic protoss bot AIUR learned about each opponent over the course of CIG 2018. AIUR has not been updated in many years and has fallen behind the state of the art, but its varied strategies and learning still make it a tricky opponent in a long tournament. Seeing AIUR's counters for each opponent tells us something about how the opponent played. For past editions, see AIIDE 2017 what AIUR learned and what AIUR learned (AIIDE 2015).

This is generated from data in AIUR's final write directory. There were 125 rounds and 5 maps, one 2-player and two each 3- and 4-player maps. For some opponents, all games were recorded, giving 25 games on the 2-player map and 50 games each on 3- and 4-player maps. For most opponents, fewer games were recorded. AIUR recorded 2932 games, and the results table lists 318 crashes for AIUR. 2932 + 318 = 3250, the correct total game count. Unrecorded games were lost due to crashes, and for no other reason.

First the overview, summing across all opponents.

overall	2		3		4		total
	n	wins	n	wins	n	wins	n	wins
cheese	72	49%	127	65%	132	35%	331	49%
rush	29	41%	269	33%	261	55%	559	44%
aggressive	13	23%	225	68%	184	78%	422	71%
fast expo	33	24%	185	48%	207	48%	425	46%
macro	46	33%	180	52%	135	60%	361	53%
defensive	141	75%	314	73%	379	55%	834	65%
total	334	54%	1300	56%	1298	56%	2932	56%

• 2, 3, 4 - map size, the number of starting positions
• n - games recorded
• wins - winning percentage over those games
• cheese - cannon rush
• rush - dark templar rush
• aggressive - fast 4 zealot drop
• fast expo - nexus first
• macro - aim for a strong middle game army
• defensive - try to be safe against rushes

Looking across the bottom row, you can see that AIUR had a plus score on every size of map, and that it had to choose different strategies to do so well. It's a strong result for a bot which has essentially no micro skills and has not been updated since 2014. It does still have the best cannon rush of any bot, if you ask me.

#1 locutus	2		3		4		total
	n	wins	n	wins	n	wins	n	wins
cheese	1	0%	8	0%	25	12%	34	9%
rush	1	0%	10	0%	6	0%	17	0%
aggressive	1	0%	4	0%	5	0%	10	0%
fast expo	1	0%	14	0%	5	0%	20	0%
macro	1	0%	7	0%	4	0%	12	0%
defensive	1	0%	7	14%	5	0%	13	8%
total	6	0%	50	2%	50	6%	106	4%

Even against the toughest opponents, AIUR can scrape a small edge with learning. Against Locutus, it pulled barely above zero, but got a few extra wins because it discovered that its cannon rush occasionally scores on 4-player maps. Results against PurpleWave below are similar. I suspect that if AIUR had played the cannon rush every game, Locutus would have adapted and nullified the edge. Maybe it did, and that’s why the edge is so small.

#2 purplewave	2		3		4		total
	n	wins	n	wins	n	wins	n	wins
cheese	1	0%	8	0%	39	18%	48	15%
rush	1	0%	8	0%	2	0%	11	0%
aggressive	1	0%	10	0%	3	0%	14	0%
fast expo	4	0%	8	0%	2	0%	14	0%
macro	1	0%	10	0%	2	0%	13	0%
defensive	3	0%	6	0%	2	0%	11	0%
total	11	0%	50	0%	50	14%	111	6%

#3 mcrave	2		3		4		total
	n	wins	n	wins	n	wins	n	wins
cheese	1	100%	1	0%	1	0%	3	33%
rush	1	0%	41	2%	1	0%	43	2%
aggressive	0	0%	2	0%	3	0%	5	0%
fast expo	1	0%	1	0%	42	17%	44	16%
macro	1	0%	3	0%	1	0%	5	0%
defensive	1	0%	2	0%	2	0%	5	0%
total	5	20%	50	2%	50	14%	105	9%

Against McRave, the choice is nexus first. McRave must have settled on a macro opening itself.

#4 tscmoo	2		3		4		total
	n	wins	n	wins	n	wins	n	wins
cheese	11	27%	1	0%	1	0%	13	23%
rush	1	0%	1	0%	3	0%	5	0%
aggressive	1	0%	11	9%	1	0%	13	8%
fast expo	5	20%	33	15%	1	0%	39	15%
macro	1	0%	2	0%	22	14%	25	12%
defensive	1	0%	2	0%	22	18%	25	16%
total	20	20%	50	12%	50	14%	120	14%

Against the unpredictable Tscmoo, AIUR wavered before settling on an unpredictable set of answers. Notice that not all the strategies are well explored: If you win less than 1 game in 5, then playing an opening 3 times is not enough. If the tournament were much longer, AIUR would likely have scored higher because of its slow but effective learning.

#5 isamind	2		3		4		total
	n	wins	n	wins	n	wins	n	wins
cheese	1	0%	2	0%	4	0%	7	0%
rush	1	100%	37	19%	38	8%	76	14%
aggressive	0	0%	1	0%	3	0%	4	0%
fast expo	1	0%	5	0%	2	0%	8	0%
macro	1	0%	1	0%	2	0%	4	0%
defensive	1	0%	4	0%	1	0%	6	0%
total	5	20%	50	14%	50	6%	105	10%

ISAMind may be based on Locutus, but unlike Locutus it is vulnerable to AIUR’s dark templar rushes. It’s a sign that it is not as mature and well tested.

#6 iron	2		3		4		total
	n	wins	n	wins	n	wins	n	wins
cheese	1	0%	1	0%	5	0%	7	0%
rush	1	0%	26	19%	2	0%	29	17%
aggressive	0	0%	2	0%	2	0%	4	0%
fast expo	1	0%	1	0%	31	10%	33	9%
macro	1	0%	19	5%	4	0%	24	4%
defensive	1	0%	1	0%	6	0%	8	0%
total	5	0%	50	12%	50	6%	105	9%

#7 zzzkbot	2		3		4		total
	n	wins	n	wins	n	wins	n	wins
cheese	4	0%	2	0%	2	0%	8	0%
rush	4	0%	4	0%	1	0%	9	0%
aggressive	3	0%	2	0%	1	0%	6	0%
fast expo	3	0%	3	0%	1	0%	7	0%
macro	7	0%	5	0%	4	0%	16	0%
defensive	4	0%	34	29%	41	12%	79	19%
total	25	0%	50	20%	50	10%	125	12%

4 pooler ZZZKBot is of course best countered by a defensive anti-rush strategy. Well, it helped, but the rush is too strong for AIUR to survive reliably. On the 2-player map, AIUR found no answer.

#8 microwave	2		3		4		total
	n	wins	n	wins	n	wins	n	wins
cheese	2	0%	2	0%	1	0%	5	0%
rush	1	0%	27	7%	1	0%	29	7%
aggressive	1	0%	1	0%	1	0%	3	0%
fast expo	1	0%	2	0%	1	0%	4	0%
macro	1	0%	1	0%	9	22%	11	18%
defensive	18	22%	17	24%	36	25%	71	24%
total	24	17%	50	12%	49	22%	123	17%

Microwave apparently also played a rushy style versus AIUR. That’s interesting. I think that AIUR’s defensive strategy is good against pressure openings generally, so Microwave was likely playing low-econ but not necessarily fast rushes.

#9 letabot	2		3		4		total
	n	wins	n	wins	n	wins	n	wins
cheese	1	0%	1	0%	1	0%	3	0%
rush	1	0%	1	0%	3	33%	5	20%
aggressive	0	0%	3	33%	1	0%	4	25%
fast expo	1	0%	41	49%	43	49%	85	48%
macro	1	100%	3	33%	1	0%	5	40%
defensive	1	0%	1	0%	1	0%	3	0%
total	5	20%	50	44%	50	44%	105	43%

Fast expo makes sense against LetaBot’s “wait for it... wait for it... here it comes!” one big smash.

#10 megabot	2		3		4		total
	n	wins	n	wins	n	wins	n	wins
cheese	1	0%	2	0%	3	0%	6	0%
rush	2	50%	4	0%	38	11%	44	11%
aggressive	1	0%	3	0%	3	0%	7	0%
fast expo	1	0%	3	0%	2	0%	6	0%
macro	2	0%	36	28%	2	0%	40	25%
defensive	18	94%	2	0%	2	0%	22	77%
total	25	72%	50	20%	50	8%	125	26%

Why did MegaBot have so much more trouble on the 2-player map? According to the official per-map result table, MegaBot did fine overall on Destination (the one 2-player map), so its trouble came only against AIUR. Maybe I should watch replays and diagnose it.

#11 ualbertabot	2		3		4		total
	n	wins	n	wins	n	wins	n	wins
cheese	1	0%	1	0%	1	0%	3	0%
rush	2	0%	43	37%	2	0%	47	34%
aggressive	1	0%	2	0%	1	0%	4	0%
fast expo	1	0%	2	0%	1	0%	4	0%
macro	18	33%	1	0%	1	0%	20	30%
defensive	1	0%	1	0%	44	16%	46	15%
total	24	25%	50	32%	50	14%	124	23%

#12 tyr	2		3		4		total
	n	wins	n	wins	n	wins	n	wins
cheese	1	0%	1	0%	1	0%	3	0%
rush	1	100%	1	0%	32	81%	34	79%
aggressive	0	0%	37	46%	8	75%	45	51%
fast expo	1	100%	3	33%	3	67%	7	57%
macro	1	0%	6	33%	3	33%	10	30%
defensive	1	0%	2	0%	3	33%	6	17%
total	5	40%	50	40%	50	72%	105	55%

I suspect that Tyr suffered here because it is a jvm bot and could not write its learning file.

#13 ecgberht	2		3		4		total
	n	wins	n	wins	n	wins	n	wins
cheese	1	100%	38	89%	2	50%	41	88%
rush	1	100%	1	0%	43	67%	45	67%
aggressive	0	0%	4	75%	1	0%	5	60%
fast expo	1	100%	1	0%	2	0%	4	25%
macro	1	0%	3	67%	1	0%	5	40%
defensive	1	0%	3	67%	1	0%	5	40%
total	5	60%	50	82%	50	60%	105	70%

#15 titaniron	2		3		4		total
	n	wins	n	wins	n	wins	n	wins
cheese	1	0%	1	0%	2	50%	4	25%
rush	1	0%	1	0%	3	33%	5	20%
aggressive	0	0%	42	79%	42	88%	84	83%
fast expo	1	0%	1	0%	1	0%	3	0%
macro	1	100%	2	50%	1	0%	4	50%
defensive	1	100%	3	0%	1	0%	5	20%
total	5	40%	50	68%	50	78%	105	71%

TitanIron appears to have been too predictable. Notice that the winning strategy on most maps was never tried (without crashing) on the 2-player map. It might have won there too.

#16 ziabot	2		3		4		total
	n	wins	n	wins	n	wins	n	wins
cheese	16	50%	2	50%	1	0%	19	47%
rush	1	0%	2	0%	1	0%	4	0%
aggressive	1	0%	1	0%	3	33%	5	20%
fast expo	1	0%	2	50%	0	0%	3	33%
macro	1	0%	1	0%	1	0%	3	0%
defensive	3	33%	42	69%	44	57%	89	62%
total	23	39%	50	62%	50	52%	123	54%

#17 steamhammer	2		3		4		total
	n	wins	n	wins	n	wins	n	wins
cheese	1	0%	1	0%	1	0%	3	0%
rush	3	67%	4	75%	9	100%	16	88%
aggressive	3	100%	17	100%	15	100%	35	100%
fast expo	2	0%	2	0%	2	50%	6	17%
macro	1	100%	10	100%	1	0%	12	92%
defensive	14	100%	16	100%	22	100%	52	100%
total	24	83%	50	92%	50	94%	124	91%

#18 overkill	2		3		4		total
	n	wins	n	wins	n	wins	n	wins
cheese	1	0%	3	0%	2	50%	6	17%
rush	0	0%	2	50%	1	0%	3	33%
aggressive	0	0%	1	0%	10	60%	11	55%
fast expo	1	0%	3	67%	0	0%	4	50%
macro	0	0%	0	0%	0	0%	0	0%
defensive	16	88%	41	90%	37	78%	94	85%
total	18	78%	50	80%	50	72%	118	76%

#19 terranuab	2		3		4		total
	n	wins	n	wins	n	wins	n	wins
cheese	1	100%	8	88%	1	0%	10	80%
rush	1	100%	11	100%	30	100%	42	100%
aggressive	0	0%	4	75%	2	50%	6	67%
fast expo	1	100%	16	100%	6	83%	23	96%
macro	1	100%	9	89%	10	90%	20	90%
defensive	1	100%	2	50%	1	0%	4	50%
total	5	100%	50	92%	50	90%	105	91%

#20 cunybot	2		3		4		total
	n	wins	n	wins	n	wins	n	wins
cheese	1	0%	2	50%	4	75%	7	57%
rush	1	100%	1	0%	2	0%	4	25%
aggressive	0	0%	4	75%	13	92%	17	88%
fast expo	1	0%	2	50%	2	50%	5	40%
macro	1	100%	9	89%	13	100%	23	96%
defensive	1	100%	32	100%	15	100%	48	100%
total	5	60%	50	90%	49	90%	104	88%

#21 opprimobot	2		3		4		total
	n	wins	n	wins	n	wins	n	wins
cheese	1	100%	12	100%	6	83%	19	95%
rush	1	100%	5	100%	7	100%	13	100%
aggressive	0	0%	7	100%	4	100%	11	100%
fast expo	1	100%	11	100%	17	100%	29	100%
macro	1	100%	8	100%	7	100%	16	100%
defensive	1	100%	7	100%	9	100%	17	100%
total	5	100%	50	100%	50	98%	105	99%

#22 sling	2		3		4		total
	n	wins	n	wins	n	wins	n	wins
cheese	1	0%	1	0%	1	0%	3	0%
rush	1	100%	5	100%	2	50%	8	88%
aggressive	0	0%	13	100%	13	100%	26	100%
fast expo	1	100%	7	100%	10	100%	18	100%
macro	1	100%	8	100%	11	100%	20	100%
defensive	1	100%	16	100%	13	100%	30	100%
total	5	80%	50	98%	50	96%	105	96%

#23 srbotone	2		3		4		total
	n	wins	n	wins	n	wins	n	wins
cheese	1	0%	2	50%	1	0%	4	25%
rush	1	100%	9	100%	3	67%	13	92%
aggressive	0	0%	13	100%	16	100%	29	100%
fast expo	1	100%	10	100%	8	100%	19	100%
macro	1	100%	7	86%	6	100%	14	93%
defensive	1	100%	9	100%	16	100%	26	100%
total	5	80%	50	96%	50	96%	105	95%

#24 bonjwa	2		3		4		total
	n	wins	n	wins	n	wins	n	wins
cheese	1	100%	9	100%	4	75%	14	93%
rush	1	100%	13	100%	10	100%	24	100%
aggressive	0	0%	7	100%	10	100%	17	100%
fast expo	1	100%	6	100%	7	100%	14	100%
macro	1	100%	7	100%	8	100%	16	100%
defensive	1	100%	8	100%	11	100%	20	100%
total	5	100%	50	100%	50	98%	105	99%

#25 stormbreaker	2		3		4		total
	n	wins	n	wins	n	wins	n	wins
cheese	4	75%	1	0%	4	75%	9	67%
rush	0	0%	5	80%	10	100%	15	93%
aggressive	0	0%	18	100%	7	100%	25	100%
fast expo	0	0%	0	0%	6	100%	6	100%
macro	0	0%	9	100%	8	100%	17	100%
defensive	20	100%	17	100%	15	100%	52	100%
total	24	96%	50	96%	50	98%	124	97%

#26 korean	2		3		4		total
	n	wins	n	wins	n	wins	n	wins
cheese	7	100%	2	100%	10	100%	19	100%
rush	0	0%	7	100%	8	100%	15	100%
aggressive	0	0%	5	100%	8	100%	13	100%
fast expo	0	0%	8	100%	8	100%	16	100%
macro	0	0%	5	100%	6	100%	11	100%
defensive	14	100%	23	100%	10	100%	47	100%
total	21	100%	50	100%	50	100%	121	100%

Well, if you win every game, learning cannot help.

#27 salsa	2		3		4		total
	n	wins	n	wins	n	wins	n	wins
cheese	9	100%	15	100%	9	100%	33	100%
rush	0	0%	0	0%	3	100%	3	100%
aggressive	0	0%	11	100%	8	100%	19	100%
fast expo	0	0%	0	0%	4	100%	4	100%
macro	0	0%	8	100%	7	100%	15	100%
defensive	15	100%	16	100%	19	100%	50	100%
total	24	100%	50	100%	50	100%	124	100%

SAIDA introduces new drop skills in TvT. Bots have not faced drops like this before, and are not adept at defending. SAIDA likes to drop tanks and goliaths with several ships, at the edge of the map, using your mineral line or your buildings for cover. The drops are able to destroy a base if the defender is weak or disorganized.

There are a lot of defensive possibilities; I’ll list some. Make SAIDA pay for those drops!

active defense

• Drop prediction. If you spot moving dropships, you may be able to guess where they are going. You can try to divert wraiths or goliaths to intercept the path, or send defenders to the predicted drop zone.

• Wraiths. Seek out those dropships and make them hurt. If they’re loaded, you can force them to unload prematurely. If the drop already happened, shoot down as many as you can. Even if the dropships escape to friendly territory, you have caused delays and gained time.

• Counter drops. Drop your own units directly on top of the enemy units. SAIDA’s tanks will have to unsiege, and (if you have coordination skills) you can take the opportunity to move in with other units. A good counter drop can turn the enemy drop from a benefit into a cost.

• If all else fails, maneuver tanks to pin down and destroy the dropped units. Don’t let them stay alive and kill more of your stuff. So far, Tscmoo has done the best job of this.

exploit predictability

Bots tend to have stereotyped play. SAIDA likes to fly along the edge of the map and drop on the edge where its units cannot be surrounded. An opponent could record the events, notice the obvious pattern, and prepare special defenses. Or at least: Once you’ve seen dropships, set up some turrets to see them coming and restrict their movement. By the time big drops can happen, terran commonly has excess minerals and can afford to throw up a bunch of turrets even if they aren’t efficiently placed.

• Place turrets along the edge where SAIDA may approach. (This is more common in TvP as defense against arbiter recall.) If you have high confidence, you could even detail goliaths to lie in ambush. If SAIDA doesn’t know about the turrets, it will have to fly into range and take damage before it can evade. At worst, you will have seen the drop and can try to predict where it will go next.

• Lay spider mines in potential drop zones, such as behind your mineral line. I don’t know whether SAIDA will drop on the mines and blow up, or scan the mines and drop elsewhere, but it’s to your advantage either way. Laying mines near your mineral line is not as clever against protoss or zerg drops, because protoss and zerg can more easily drag the mines into your workers. Terran doesn’t have a good unit to drag mines with.

stay alive

• Lift the command center and run SCVs. There’s a good chance you can keep the CC alive and quickly restore the base to operation once the drop is cleared. Lifting the command center is a basic terran skill; I find it surprising that Krasi0 doesn’t have it yet.

My energy is recovering slowly from “blrgh, is it day again?” toward “I wonder what’s for lunch?”

I got a modest amount of work done for Steamhammer 2.1. I fixed 4 different bugs in terran play, and now terran is up to snuff—there was a good one where medics liked to break away and advance on their own. Steamhammer is better than before with barracks units, still klutzy with factory units though vultures may get stuck on each other less often. At least one protoss bug is not as easy and needs actual work to solve. I also feel like fixing scourge, so we’ll see how long it takes. Should be more on the order of days than weeks.

For Steamhammer 2.2, I think the headline feature will be dropping BWTA. That will be a relief. When it looks solid, I can move to BWAPI 4.2.0 and be free of the bugs in 4.1.2. The 4.1.2 bugs effectively make drop more expensive for zerg, which has discouraged me from working on drop skills.

Last year, the end-of-year Steamhammer version 1.4a3 (gotta love that version number) was not only the absolutely strongest Steamhammer of the year, it was also relatively strongest: It showed the best results against other bots. Steamhammer finished higher in SSCAIT than in AIIDE. I’m seeing early signs that it might work out the same this year. This year, the AIIDE version includes a lot of necessary work, but not all of it is polished enough. By the end of the year, the new bugs should be smoothed out and other important problems fixed. I’m expecting a strong chance that Steamhammer will again finish higher in SSCAIT than in AIIDE. I think I am being taught a lesson in good tournament preparation.

Still coming soon-ish: CIG 2018 analysis.

I think we have a new champion.

New terran SAIDA has been playing extremely impressive games on SSCAIT, scoring 10-0 as I write. In games so far, it breaks down both Krasi0 and Locutus with a strategy like this: Stay home on 2 bases and build up a strong tank force, move out and establish a contain as close to the enemy natural as possible, use the space this gives to reduce other enemy bases around the map with vulture raids, small tank attacks, and drops with multiple dropships (a unique skill for terran bots). Based on its debug drawing, it seems to have a sophisticated understanding of what its enemy is doing, and from the way it varies its play against different opponents, it makes use of that understanding. It scouts carefully. It can place tanks on high ground appropriately. Its drop positioning is strong. When rushed, it places a bunker in a strong rear position and pops marines in and out at the right times. When PurpleWave tried forward 2 gates, SAIDA scouted it and correctly focussed down the pylon first, then took its vultures away from the gates to hit the protoss main, perfectly done. The bot has a lot of powerful and rare skills.

SAIDA appears to play with primarily factory units against all races. If so, it may be vulnerable against the strongest zergs. Or maybe not, we haven’t seen the games yet! Looking into the binary, I see that SAIDA knows names for a wide variety of strategies by all races. If it also knows counters for those strategies–which I think we can expect—then it is prepared for anything it is likely to see. For example, here are the names it knows for zerg:

opening	“main” (current) strategy
Zerg_4_Drone	Zerg_main_zergling
Zerg_5_Drone	Zerg_main_maybe_mutal
Zerg_9_Drone	Zerg_main_hydra
Zerg_9_Hat	Zerg_main_lurker
Zerg_9_OverPool	Zerg_main_mutal
Zerg_9_Balup	Zerg_main_fast_mutal
Zerg_12_Pool	Zerg_main_hydra_mutal
Zerg_12_Hat	Zerg_main_queen_hydra
Zerg_12_Ap
Zerg_sunken_rush
Zerg_4_Drone_Real

I’m not sure what all of the names mean, but most are obvious. Steamhammer, with its huge opening repertoire, knows openings which are technically not on this list. But for practical purposes, I expect this should cover everything before hive tech.

I can see flaws in SAIDA’s play: It makes too many turrets, its tank positioning versus protoss is too compact and vulnerable, it makes micro errors. But the flaws are not easy for other bots to exploit.

This bot must be the product of long development. The rest of us have work to do!

Here is the Steamhammer 2.0 download link. It’s the same zip file I submitted for AIIDE 2018, so unlike an SSCAIT upload it doesn’t include BWAPI.

Steamhammer 2.0 download with source and binary.

It is meant to play zerg only. The configuration file contains nothing for terran or protoss.

You can fill in openings yourself and it will play, but my testing shows unacceptable bugs for both terran and protoss. For example, vultures often get stuck on targets as if married to them, unable to switch away until one or the other dies (this bug allows no divorce for any cause). In zealots versus zerglings, the zealots like to move back and forth and give the zerglings free hits. “It’s only fair, we’re so much taller and stronger.”

Steamhammer 2.1 will come out when the bot again plays all races acceptably. I’m not sure how long it will take. After the big effort for AIIDE, my energy is low and I need a break. I haven’t even updated Steamhammer’s web page yet.

Some parts of the change list are already posted; think of those posts as part of this one (ahem, “included here by reference are....”). Here is the rest. You may notice that it is slightly long.

• overview
• defiler support
• base defense changes
• squad unit clustering

code changes

• More stuff in UnitUtil: Cooldown and FramesToReachAttackRange() functions added, and used in micro. GetWeapon() functions reworked for simplicity. Damage-per-frame functions added to compare weapon strengths. IsCompletedResourceDepot() added, factoring out code that was repeated in several places.

• UnitInfo::estimateHealth() estimates the health of a unit which may not been seen for a while, accounting for protoss shield regeneration and zerg hp regeneration. (Terran medic healing and SCV repair are not easy to predict.)

• InformationManager::enemyHasSiegeMode() added, and used in tactical calculations.

• In GameCommander, I sorted the manager calls so that managers which gather information are called first, and managers which use the information are called later. They had gotten jumbled over time. The main effect is that Steamhammer reacts 1 frame faster after discovering the race of a random opponent, a crucial difference that I estimate will, over Steamhammer’s lifetime, save approximately zero games.

• I renamed SquadData::addSquad() to createSquad(), since that’s what it does, and reworked it for simplicity. I removed the declaration of SquadData::clearSquad(), which was not implemented.

• Some calls in WorkerManager iterate through bases instead of through units to find base-related information. It’s faster and simpler (but I did have to spend time to fix a bug that I introduced in the process).

• More unnecessary includes removed, bringing a negligible improvement in compile times.

• I removed the configuration option Config::Micro::UnitNearEnemyRadius. The value is now chosen dynamically in code.

• In the game info display (turned on with Config::Debug::DrawGameInfo and drawn in the upper left), most labels were not needed because the meaning is obvious. I removed the labels of items other than “Opp Plan”. Less clutter is better.

• The TimerManager display, turned on with Config::Debug::DrawModuleTimers, had grown disorganized and probably incorrect. I straightened it out. I also improved comments in the code to prevent future disorganization.

opponent model

The opponent model has always distinguished between opponents that appear to follow the same plan every game, and opponents that vary their play. Until this version, it used the information only in a minor way. Now it selects openings using an entirely different method for multi-strategy enemies. If you play the same every game, Steamhammer will try to find the best single response, exploiting your predictability. If you mix up your play to confuse Steamhammer, then Steamhammer will mix up its play to confuse you; you get minimal predictability to exploit. We’ll see how well it works, but I’m expecting it to make a big difference in a long tournament like AIIDE.

• Against a single-strategy opponent, Steamhammer sticks with the variant of epsilon-greedy that it has always used: With probability epsilon, explore randomly; otherwise, choose the best known opening according to a weighted win rate that tries to take the maps into account. It’s not strictly classic epsilon-greedy, though, because epsilon varies according to the loss rate: If we are losing a lot, explore more often and play the best known opening less often. (It’s an adaptation to having more openings available than can be tried.) I have modified it so that the exploration rate increases more rapidly with the loss rate, because I found it was too often repeating an opening that won 1 game out of many, instead of looking for a better choice.

• Against a multi-strategy opponent, Steamhammer starts with the same weighted-win-rate calculation that it uses in the single-strategy case. Each opening it has already played is an option, and has a measured win rate. Exploring a new opening is an option, and its win rate is the mean win rate of openings that have been tried, its best estimate of how likely a newly explored opening is to win—but with a hard floor, so that the exploration rate never goes too close to zero. It randomly chooses among the possibilities, giving each a probability proportional to the square of its win rate. Squaring the rates gives openings with win rates near zero little chance of being chosen—unless most openings have win rates near zero. If all win rates are zero, because there are no wins yet, the hard floor on exploration means that Steamhammer explores every time. If the win rates are high for some openings and low for many others, exploration will be rare and Steamhammer will most often randomly choose one of the better openings. It’s ad hoc but makes a certain amount of sense.

macro

• Mineral locking. Steamhammer’s implementation follows Locutus in outline, but is different in detail. Mineral locking helps mainly in macro games, which Steamhammer is now able to play better because of the squad changes, so this was an opportune time to add it.

construction

• Prefer to expand to bases near the edge of the map. Bases near the edge are usually (not always) more protected than bases near the center of the map. In practice, Steamhammer now mostly avoids taking the risky center bases on Heartbreak Ridge and other maps, and the exposed mineral only bases on Python, at least until later in the game. I had to tune it carefully so that the natural of the 1 o’clock base on Tau Cross, far from the edge, is still preferred over the exposed 3rd base at the edge. Someday I’ll implement map analysis and figure out a real measure of exposure to attack.

• Bug fix: Don’t try to build at a location which a worker cannot reach. It never happened, as far as I know, but there was a mistake in the code.

tactics

• In the overview I said that workers are not transferred to base that is in danger, but there is more to it than that. Each base keeps track of whether it is being attacked severely enough that workers appear to be in danger; the estimate is made by CombatCommander::updateBaseDefenseSquads(), which I wrote about under base defense, and can be accessed via the Base objects for each base with base->inWorkerDanger(). If a worker is idle, meaning it is due to be assigned a new task if one is available, then it is not assigned a task at a base where workers are in danger. A worker is normally made idle after completing any task: worker was just created, gas collection is being turned off so worker no longer needs to mine gas, worker is finished defending itself and should be put back to work, and other cases. Workers are not only not transferred to an endangered base, they are often (not always) transferred away from the endangered base because they had to defend themselves, or were pulled for defense, or otherwise changed tasks. It’s hardly perfect, but it saves workers and greatly improves Steamhammer’s resilience to attack. It was a critical improvement. Related weaknesses remain: Steamhammer may still try to build at the endangered base, or transfer drones to a distant base through the enemy army.

• Fixed CombatCommander bugs in deciding which enemy base to attack.

• Rules for recognizing enemy cloaking and assigning detectors to our squads are slightly improved. Steamhammer pays attention to whether it has cloaked units itself and needs to catch enemy observers. This allows overlords to stay safer in some game situations: We don’t have lurkers, therefore we don’t have a strong need to hunt observers, therefore overlords can stay home.

• In feeding units to the combat sim, an enemy building which was last seen uncompleted is entered as completed if is currently out of sight. It is sometimes an improvement, sometimes a mistake. It would be better to track the estimated completion time and use that (a number of bots do).

micro

• Previous versions changed former stateless module Micro into an object with state, but did nothing new. This version updates the state with each of our unit’s orders and a little more information, but still doesn’t use the state for anything. It’s all prepared for serious work, though.

• Enemy unit movement prediction is smarter. It takes distance into account. Also, prediction is used differently in different cases to get better results in practical situations. Mutalisks, wraiths, and vultures now use prediction; as instant-acceleration units they are kited by a different routine than other units, which didn’t use prediction until now.

• Kite only units which the enemy has targeted. If nobody wants to shoot you, you don’t have to step back from the shooting. This especially helps hydralisks, which fire more slowly when kited and tend to get in each other’s way.

• Some bits of micro explicitly take latency into account in their calculations, especially kiting. It’s more accurate.

• Don’t chase an enemy if we’re predicted to be unable to catch it. CanCatchUnit() (defined in Common.cpp) figures it out. It makes less difference than I expected.

• Targeting priority: A ghost which is nuking is the highest priority target. An enemy defiler is also a high priority. These two were oversights. There are other targeting tweaks, for example to reduce cases of attacking the pylon when the cannon behind it is firing; it’s not fully successful.

zerg

• If we are short of mutas or lurkers (by a simple hardcoded count), then do not substitute a drone for a muta or lurker, no matter how much we may want drones. This was the biggest cause of delayed tech switches, and fixing it makes strategic play crisper at key times. This was one of the most important fixes in version 2.0.

• Late in the game, add extractors willy-nilly everywhere that they are possible. Steamhammer was too often gas-starved in the late game, too slow to get more gas when it was needed. This is also an important fix.

• Limit scourge more stringently. Sometimes Steamhammer makes so much scourge that it has no gas for anything else, causing macro problems as it delays production to get more gas.

• The building manager is much more cautious about turning a failed expansion into a macro hatchery. It only orders the change if it appears that we actually need a macro hatchery.

• Build a queen’s nest sooner in some situations. This is to speed hive tech when it is needed. It doesn’t make a big difference.

• If the enemy has too many corsairs or valkyries, get air carapace. This gets air armor for overlords even if we are not making any other air units.

• Favor guardians more, especially versus mass cannons. Past Steamhammer versions reduced guardian use by too much, and this starts to correct it.

• Emergency reaction: If we’re dangerously short on drones, don’t spend one on a building. Oops.

• Emergency reaction: If we have no bases but do have hatcheries, then make sure that the drone limit is at least 3. Having “no bases” means that no hatchery is at a predefined base location; we might still have hatcheries that can mine. Steamhammer formerly thought that, without bases, it had no need for drones. That was OK if it had drones already, not if they were all dead. Now Steamhammer has a chance to recover, provided the enemy is also prostrate after a base trade.

• Don’t automatically make a sunken in reaction to a proxy. It was often an overreaction.

• Don’t automatically get an early sunken versus protoss 2 gate (the sunken was usually too early) or against zerg 2 hatch (it was often unnecessary).

• When planning a morphed unit type (such as a lurker), don’t count it as using up a larva. This minor bookkeeping fix should occasionally make for better production decisions.

• Cancel grossly excess overlords even in the opening book. This may help if an emergency situation comes up in the opening, but it is mainly meant to mitigate bugs which cause production loops. No simple production loops are possible, but there seem to still be some complex loops where unrelated emergency reactions fire, and each prevents the other from recognizing that it has already taken action. It’s rare, though.

• Don’t let rebuilding the spawning pool cause a production jam, and don’t allow multiple copies of the spawning pool. It was a rare but deadly bug in production unjamming.

• Fixed a crash if a hydralisk den, lair, or spire was dropped in the opening (in reaction to an emergency). It was that specific.

• Fixed a rare bug that could prevent gas from being retaken after it was lost.

• Fixed a bug in defensive reactions that could request zerglings when there was no spawning pool.

• Fixed an unimportant bug in deciding to make a hive. It had no real consequences.

zerg openings

• Fixed a number of openings that had suffered bit decay: They were broken or mistuned due to code changes, such as queue reordering and mineral locking.

• Added new turtle openings designed to exploit particular enemy strategies: 11HatchTurtleHydra, 11HatchTurtleLurker, 12HatchTurtle, ZvZ_OverpoolTurtle. These are meant to stop specific rushes and leave Steamhammer in a sound position.

• Finished up and optimized the anti-forge-expand macro openings ZvP_3BaseSpire+Den (a good success) and 4HatchBeforeGas (not as effective). Steamhammer is finally able to play macro games well, so this was important. To play these openings truly well, though, Steamhammer needs greater ability to understand and react to the enemy’s timings.

• I fiddled with opening probabilities, mainly to continue to make openings more equally likely so that the opponent model can explore more efficiently. But also to include the new openings and to adjust to Steamhammer’s new strengths and weaknesses.

• I split the opening 9PoolSpeed into 2 variants. One variant keeps the same name and makes fewer zerglings (hit them by surprise, then transition to a normal game), the other is called 9PoolSpeedAllIn and makes more zerglings (hit them hard and maintain pressure). Both are more effective in their ways than the former compromise opening.

• A few ZvZ openings make 1 drone fewer, to keep zergling numbers as high as possible.

• Some other changes.