Starcraft AI blog

The source for Steamhammer 2.4 is available at Steamhammer’s web page.

Steamhammer 2.4 is uploaded. Since I never got around to releasing the source of the previous version, I’ll release source shortly.

This version has 2 points of focus: First, fixing critical bugs that are responsible for many of the losses against weaker opponents, and second, coping with the deadly Styx opening. I wrote 18 new openings, 10 of which are connected to the Styx opening.

configuration

• Added the Config::Strategy::HumanOpponent flag for games against humans. It’s false by default, since almost all games are versus bots.

critical bugs

• Cancelling mutalisks just before making them is fixed. It happened intermittently in some openings. A spire takes 1800 frames to build, and Steamhammer is configured to conclude that production is jammed if there are 1440 frames without production. In some cases, the opening build might pause production for longer than the limit while saving up for mutalisks; a jam clears the queue and drops out of the opening, so the mutalisks were never made. I fixed it with a special case test, since only this one case was failing.

• Gas deadlock is an emergency that happens when Steamhammer needs gas for the next item, and has the extractors for it, but finds itself unable to collect the gas for some reason (for example, the base is under attack so the drones ran away). It clears the queue to try again. The condition for recognizing gas deadlock was too loose, and sometimes declared deadlock falsely. I tightened it up.

• Tracking of geysers and refinery buildings seemed to be wrong in some cases. I was not able to pin down any bad behavior it caused, but the code looked confused and I’ll be surprised if nothing is corrected.

• Combat sim is more fixed. In the previous version I fixed bugs in setting up the combat sim, related to short-circuit judgments when facing cloaked units. There was still a bug, and I traced it to... checking whether a unit’s air weapon was unequal to BWAPI::UnitTypes::None rather than BWAPI::WeaponTypes::None. Thank you C++ for your “helpful” type checking. This fix will make mutalisks more aggressive, as they should be, in certain situations.

macro

• Restored the setting of 2 workers per mineral patch for terran and protoss. It had been accidentally set to the zerg value of 1.6.

operations

• Against certain stronger enemy units, send more defenders. If an archon is in your base wreaking havoc, 2 marines will not stop it.

• The natural expansion cannot be one of the map’s starting bases. This fixes a problem that came up on the map Baekmagoji.

• StrategyBossZerg::enemySeemsToBeDead() works more nearly as intended. There was a minor bug. The enemy is considered to be dead and ready to be buried when all these conditions are met: 1. The enemy starting base has been found (so it can’t happen immediately when the game starts). 2. The enemy has no known surviving bases. 3. The known enemy ground army is not strong enough to threaten to win. 4. The enemy has no known anti-air units or anti-air static defense. When the enemy looks dead, Steamhammer techs to mutas and switches to a unit mix of drone + mutalisk. The mutalisks can efficiently hunt down any hidden or floating buildings.

unit control

• The micro system drops positional orders for which the position is “close enough” to the previous order. If code orders a move to (x, y) and then on a later frame a move to (x, y+1), the second order is dropped. The tolerance is a few pixels for short-range moves, larger for long moves. This reduces command spamming and smooths unit flow. In the long run, I ideally want to reduce Steamhammer’s APM to human levels.

• Targeting priority for enemy buildings is factored out and more nearly standardized across unit controllers. Streamhammer should destroy enemy bases a little more purposefully, with fewer cases of zerglings tearing down the spire while mutalisks tackle the spawning pool.

• Enemy observers are a higher priority target for ranged units and scourge, depending on the situation.

zerg

• When in book, if we have no zerglings, do not change a planned zergling into a drone. Steamhammer likes to skip zerglings when it foresees no danger. A similar change was already made for the case when it was out of the opening.

• Queen bug: The queen believed it could infest an unfinished command center. “It has few enough HP, let me fly across the map and take it.” When the building SCV was killed, the queen might sit over the unfinished command center forever. “This infestation sure is taking a long time. Oh well, stick with it!”

• Queen bug: When using broodling, the previous version was intended to be willing to make 2 queens, not the usual 1. After testing the feature, I introduced a typo that prevented it from working. Fixed.

• Prevent production freezes related to queen upgrades. Rare but painful.

• Allow air upgrades in any order, using 1 or 2 spires. Formerly, air carapace had to be first (or else production freezes were possible) and Steamhammer could upgrade in only 1 spire. This any-order-is-OK improvement was made earlier for ground upgrades.

openings

• ZvZ_Overgas8Pool fills a small gap in the repertoire. A very small gap.

• 973HydraBust is a precise modern build versus protoss forge expand. The name is because you are supposed to end up with 9 drones in your main, 7 in your natural, and 3 at a third base. Steamhammer does not have the skills to distribute the drones efficiently as intended, but it does get the right total count.

• 2HatchMutaForever covers a weakness in the zerg strategy boss: There are times when growing the mutalisk flock is best, but the strategy boss doesn’t understand the value of stacking air units and prefers to switch into a different unit mix. The opening doesn’t really make mutalisks indefinitely, only for a long time. It also gets air upgrades.

• 2HatchFakeHydra and 2HatchFakeMuta are deceptive openings that make both hydralisk den and spire. The fake hydra opening makes a hydralisk den when the enemy scout should see it, chases the scout away, and adds the spire later. The enemy may predict hydra play or lurkers. The fake muta opening is similar but in reverse.

• 5HatchPool makes 5 hatcheries before spawning pool, an extremely greedy opening for use against opponents that move out late. (See my mention of Locutus in what Steamhammer learned. I’ve seen 6 hatch before pool work against a bot.) ZvP_5HatchPoolHydra is a specialized version that follows up with mass hydralisks. 5HatchPoolLing gets an evolution chamber before the spawning pool, so that when the first zerglings hatch, melee attack +1 is already half finished. The flood of lings is late but massive.

• The powerful Styx build. The openings 9PoolHatchSpeed7Drone, 9PoolHatchSpeed7DroneB, 9PoolHatchSpeed, 9PoolHatchSpeedAllIn, 9PoolHatchSpeedAllInB are variations on the Styx build of 9 pool, 3 pairs of zerglings, hatchery, extractor (leaving yourself with 7 drones), zergling speed, and deluge the enemy with zerglings (7 drones are enough). That exact build is 9PoolHatchSpeed7DroneB. The versions without a B have the extractor before the second hatchery, which gets faster zergling speed and a slightly slower hatchery. The versions without 7Drone use the extractor trick to end up with an 8th drone without losing time. The 8th drone does not make the zergling attack stronger, because 7 drones are enough to keep the 2 hatcheries completely busy producing, but it does establish leeway to lose a drone to accidents, make an emergency sunken, or transition into another plan. The plain version 9PoolHatchSpeed makes fewer zerglings and leaves the followup to the strategy boss, which is not too helpful because the strategy boss doesn’t understand the idea.

• Anti-Styx openings. If you know your opponent’s exact build order, you can always choose your own build to gain an advantage. (Don’t be predictable!) If the opponent is too greedy, you can clobber them with a rush or a bust before they’re ready. The Styx opening is not greedy; 9 pool is what you play to be safe against cheese. When the opponent is not greedy, you gain an advantage by being greedier, to a calculated extent. AntiStyx_9Pool is the simplest try. It uses the extractor trick for the 8th drone, and turns the drone into a sunken. The zergling wars are about equal, but the sunken at home is safer and allows more freedom of action because there is less need to hang back in defense. At Steamhammer’s level of play, the advantage is slight. However, this anti-Styx build is valuable as a general-purpose anti-cheese build; I configured it for that too. AntiStyx_3Hatch and AntiStyx_Muta are more successful at defending against the Styx opening. They open with overpool rather than 9 pool, gaining a lead in drones. Both make 1 sunken and use the safety it provides to scrape out more drones. The 3 hatch followup adds a third hatchery to eventually win the zergling wars, while the muta followup techs instead. The safe path is narrow; I’m curious to see how well the openings perform in practice.

Turtle openings can also cross the river Styx. Some turtles swim well, and they do not have the same weakness as Achilles. See wins over StyxZ by ZurZurZur, by Simplicity, and by Microwave with its turtle build.

• 9PoolHatchSpeedSpire and 9PoolHatchSpeedLurker are my try to pre-empt bot authors who may add a recognizer for the dangerous Styx opening so they can counter it. These builds start out with the Styx opening stem but transition into tech.

• I made tweaks to AntiZeal_12Hatch and 12HatchTurtle. They should be a trifle stronger.

Steamhammer 2.4 is almost ready. I’ll upload it tomorrow. It has accumulated enough critical bug fixes and changes; it is time to put it on the road and see how it drives.

New are 4 variants of the “Styx” opening (popularized, not invented, by StyxZ—as Ogden Nash said, “Don’t be a discoverer, be a promoter.”). A later post will analyze and compare the variants. And I wrote 3 counter-Styx openings designed to defend and come out ahead.

Steamhammer’s SSCAIT prospects

In 2016, when Steamhammer was brand new, it squeaked into the SSCAIT final playoffs through a tiebreaker match. In 2017 and 2018, it was clear to me ahead of time that Steamhammer would make it into the finals. This year, my life and schedule have been disrupted and I made less progress. Some of the work I put in, like queen skills, was more about having fun than about playing better, because I need some fun. The bottom line is, Steamhammer is failing to keep up with advances. Its rank is sliding.

I think that Steamhammer is still likely to make it into the SSCAIT round of 16, but it may be a close call. There’s a real risk that it may fall short. The fixes in version 2.4 may claw back a rank or two, but not enough to eliminate the risk. It’s possible that I can change Steamhammer’s prospects before then by implementing a killer skill (I have one in mind), but that’s risky in itself, and my past attempts to code killer skills before a deadline have fallen short. But we’ll see.

I watched the SCHNAIL video and I’m pleased. Today I added a HumanOpponent flag to Steamhammer’s configuration file, to make the bot more fun for humans to play against. If you set it to true, the flag has 2 effects:

1. It tells the opponent model that the opponent is unpredictable, which the opponent model takes to mean “I’d better be unpredictable too so I can’t be exploited.” It chooses openings more randomly. This is just turning on a standard Steamhammer behavior that already existed.

2. When losing, Steamhammer ggs out much earlier. Steamhammer in the past assumed that its opponent is a bot and may mess up the win, so it surrenders barely one step before it is provably unable to win. (Even so, I’ve seen a couple games over the years when it might have won if it hadn’t given up—when it had no drones and no combat units and no money, but had units in production that could outfight the opponent which was also near death. It’s extremely rare.) Versus a human, that gg timing is way way too late, unacceptably late. When HumanOpponent is turned on, Steamhammer follows a two-part rule: A. The enemy is much stronger than me—my supply is less than half the enemy’s known supply. B. I have been hurt—my supply has fallen below half of its high water mark. The B part ensures that Steamhammer doesn’t give up without a fight merely because it has been grossly outmacroed.

I’m curious to find out how well the gg rule works in real human games. In test games, I thought the gg still came later than a strong human would prefer. But perhaps it is a good fit for human players who deem Steamhammer an interesting opponent. Also, the enemy’s known supply is generally less than the enemy’s true supply, and Steamhammer is weak at scouting so often it is much less. But I will need to improve scouting as part of my strategy adaptation project, and gg timing may improve when I do.

About SCHNAIL: Obviously we can’t expect SCHNAIL users to edit Steamhammer’s config file and set the HumanOpponent flag. The file won’t be exposed to them at all; they don’t need to know it exists. I asked Sonko if there will be a way for a bot to tell that it is running under SCHNAIL. Whatever the final arrangement ends up being, I will help Steamhammer fit into it so the bot does sensible things in human games.

I was testing a macro build on the map Baekmagoji, a 2 player map where macro builds are fitting because each main base has 2 geysers and 18 mineral patches—double the usual. (I routinely test on all kinds of maps.) Early in the game, Steamhammer suddenly panicked and canceled a hatchery to get its spawning pool immediately. What was going on?

The bug, or I should say bugs, turned out to be this: Because the enemy main was so rich in resources, Steamhammer decided “well, it’s a bit far away, but still it’s the best choice for my natural base.” When the scout found enemy buildings (“hey, that’s in my natural”), Steamhammer concluded that it was getting proxied. Panic! That was easy to fix; the chosen natural is not allowed to be a starting base. But wait, why was the first expansion hatchery already started somewhere else, so that it could be canceled? Because the choice of the natural base and the actual first expansion taken are not quite coordinated correctly; in some cases they can be different for no good reason. Ack!

Baekmagoji is a difficult map for bots. Another issue is that some of the mineral patches in the main are not reachable until other patches are mined out. It’s a clever design, but Steamhammer doesn’t understand it and tries to assign drones to minerals that they can’t reach. Well, that’s not important to fix yet. I can’t think of another competitive map that would trigger this bug (though more than a few Blizzard maps do). Also notice the neutral sunken colonies spreading creep, and the blocking temples and blocking minerals. Lots of tricks lying in wait.

New bot Crona is, as it says in its description, BananaBrain playing zerg. It was uploaded today and has started out well. The name “Crona” is after an anime villain.

Sp far, I have only seen Crona play with zerglings and mutalisks, no other units. Here are the names of Crona’s openings, extracted from the binary. “Main Muta/Hydra/Ling” looks like an unrelated string that sneaked into the list, but maybe it’s an opening too.

ZvZ_2hatchling
ZvZ_5pool
ZvT_2hatchling
ZvT_4pool
ZvT_2hatchmuta_12pool
ZvT_2hatchmuta_12hatch
ZvP_2hatchling
ZvP_5pool
ZvP_4pool
ZvP_2hatchmuta
Main Muta/Hydra/Ling
ZvU_2hatchling

The build ZvZ_2hatchling is the “Styx build” of 9 pool, 3 pairs of zerglings, second hatchery, extractor, research zergling speed and produce zerglings for a long, long time. (Note 1: One of the rules of naming is that the origin of a thing cannot be the name; you have to pick something later. Note 2: I’ve tested both variants, and I’m pretty sure that the PurpleSwarm variant with extractor before the second hatchery is better.) Likely the other 2hatchling openings are too.

When playing 4 pool, and presumably other builds, Crona sticks with 1 hatchery and 3 drones for a while, then transitions to 2 hatcheries and 7 drones, then later to 3 hatcheries. I assume the sequence continues. My impression is that the expansions are on a timer: I’ve done this long enough, time for another hatchery. It’s a simple way to slowly increase pressure on the opponent.

Crona’s zerg play is good—see its results—but still looks a little rough to me. It doesn’t scout with its overlord. It has a glitch where, at a certain point in the opening, all the drones move away from the minerals for a second before returning. Crona seems a little confused about drone transfers in general. These things should not be hard to fix, though.

I see terran openings in the binary too. Can anybody guess what the terran BananaBrain will be called?

Adias is a new terran bot, and starting off strongly. The first thing I noticed about it is that its name is SAIDA spelled backward. Does that mean it is like SAIDA, or the opposite of SAIDA? The second thing I noticed, after unpacking the binary from SSCAIT, is a machine learning folder with files caffe2.dll, torch.dll, and a couple of learned models with the .pt suffix. It is the signature of a project using PyTorch for deep learning. It’s not TorchCraft, so not directly related to CherryPi. It also does not seem to be based on SAIDA_RL; strings I checked from SAIDA_RL do not appear in adias.

The third thing I noticed, peering into the .exe, is that it looks to be derived from SAIDA. It’s clear that the two share a lot of code, at least. That’s surprising; based on SAIDA and using RL but not based on SAIDA_RL? Close similarities to SAIDA are visible in the game play. For example, adias shares SAIDA’s way of grouping supply depots and tech buildings together, and SAIDA’s predilection for walls composed of barracks plus engineering bay. Both habits appear in the game adias-Tomas Cere on Benzene. There are a lot more similarities; the building placement and opening build orders look identical to me, and adias shares the skill to set up tank lines where the opponent will be compelled to engage at a disadvantage.

The combination of traits reminds me of something else: Stormbreaker, the bot which was disqualified from AIIDE 2019 for being SAIDA with cosmetic changes and a neural network whose result was not used. Is adias only Stormbreaker under a different name?

Well, I don’t know, but I’m guessing not. Though SAIDA and adias look more similar than not, I went back and watched old SAIDA games and I think I see differences too. The difference most salient to me is that adias likes to send an SCV to scout around inside and near its base early in the game, seeming to check for proxies. The only other bot I’ve seen with that style of anti-proxy scouting is tscmoo. Did tscmoo have a hand in adias?

I expect we’ll learn more as we get to see more games. Krasi0 was eventually updated to defeat SAIDA. Will Krasi0 quickly learn to beat adias too, or will Krasi0 have to be updated again to keep up?

Here’s data from Microwave’s history files, using the same script as for BananaBrain with a little customization. Unlike Microwave’s learning files, which deliberately omit data and include information from pre-learning, the history files tell what Microwave actually did during the games. Microwave didn’t record information about the opponent’s strategy, so that table is left out. That made it look a little sparse, so I added columns giving the first and last games when the opening was tried, where the first game in the history file is game 0. We can see things like when a winning opening was found, and whether it kept winning. If there are fewer than 100 games recorded for an opponent because Microwave crashed, then the game numbers generally do not align with the tournament round numbers.

Against difficult opponents, Microwave experimented widely. Against some opponents that Microwave pre-trained against, it played whatever came out of pre-training. So I don’t have much to say about opponents in the top half of the post. But toward the bottom I’ve made some comments. Especially see the note to AITP.

Why are only 71 games recorded? According to the official results, Microwave crashed in 56 games throughout the tournament, and 29 of those crashes happened against ZZZKBot. Microwave recorded every game in which it did not crash. It’s a debugging opportunity. :-/

As soon as Microwave found that 7 pool worked, it played 7 pool exclusively.

Microwave was late to discover the success of the hydra bust opening. That’s why it was played so little. The example shows the importance of finding good ideas as early as possible. I am adding smarts to Steamhammer to make it better at finding the good tries fast.

It’s interesting that 2HatchMuta and 4PoolSoft have the same numbers, but were given up on at different times.

The choice against UAlbertaBot was determined by pre-training. From scratch, I expect Microwave would have tried a wider variety.

Apparently the initial choice against an unknown is random.

I wrote a script to analyze BananaBrain’s game history files, which record its experience with each opponent. For now, I had the script summarize the strategies played and the enemy strategies recognized. The history files also record the map and a value that represents the game duration. History files are rich with information, and there are many ways to summarize it. It would be interesting to see how strategy usage and win rate vary by map, among other possibilities.

The same script should work with minor changes to summarize Microwave’s history files.

BananaBrain had prepared history files for the opponents #1 Locutus, #2 PurpleWave, #5 Steamhammer, #6 ZZZKBot, #7 Microwave, and #8 Iron. Data from the prepared history files was not copied into the write directory. That is different from how Steamhammer and Locutus keep their game records, and it has the nice effect that the tables show exactly what happened in the tournament, from BananaBrain’s point of view.

For each opponent, the left table is BananaBrain’s choice. The right table is BananaBrain’s idea of what the opponent did. All the win rates are from BananaBrain’s point of view, so that, for example, when Locutus played P_1gatecore, BananaBrain won 5% of the time. Of course, the opponent’s view of its own strategy is likely to be more fine-grained than BananaBrain’s. To take the extreme case, Steamhammer played 30 different openings against BananaBrain, and BananaBrain recognized them in 8 categories.

As you might expect against Locutus, the best choice was a fast expansion.

Is the single game of enemy P_fastexpand a misrecognition? I suspect that Locutus played otherwise, and BananaBrain didn’t see everything and wasn’t able to draw the right conclusion. Or maybe it’s a bug somewhere. PurpleWave and McRave also show a single P_fastexpand game.

Against PurpleWave, different zealot rushes worked best. Maybe it is because zealot rushes depend for their success more on execution than on the enemy’s strategic reaction. PurpleWave is particularly good at reacting to the enemy strategy, and BananaBrain is good at execution.

BananaBrain made quite a variety of tries, and was most successful with... zealot rush and dark templars, which are kind of different. BananaBrain’s varied opening choice is a strength.

2 gate zealot openings work well against Steamhammer—but only when played by PurpleWave or BananaBrain. Steamhammer can usually defend versus a lesser protoss.

I like that BananaBrain varies its opening choice even when several openings win 100%. (Steamhammer does too; if more than one opening has scored 100% so far, Steamhammer chooses randomly among them.) Playing a strong opening gives the opponent one problem to solve (“how do I survive this?”). Unpredictably playing one of several strong openings sets the opponent two problems (“what is this fiend doing, and then how do I live through it?”) which must both be solved, more than twice as difficult.

Bulldog! That involves protoss dropping zealots, typically on cliff tanks, with a simultaneous attack by ground. When successful, a bulldog can abruptly break a terran defense that is sound against any purely ground attack. I don’t think I’ve seen BananaBrain play that; I should watch more games versus terran. Can anybody point out an example?

The Stove worked against XiaoYi? Again, XiaoYi shows weakness against tricks. The Stove involves making scouts to harass while teching to dark templar. It should not be hard for a good terran to defend against; notice that Iron dealt with it well enough.

It looks like most openings performed similarly against McRave, and BananaBrain struggled to identify what worked. I imagine a fierce learning battle, both trying to keep one step ahead.

BananaBrain apparently does not have a bunker rush recognizer.

Locutus’s game records are in almost the same format as Steamhammer’s and can be summarized by the same script. I expect it will also work for DaQin and AITP.

Where Steamhammer was set to keep 100 game records per opponent, Locutus was set to keep 200. Since there were 100 rounds in the tournament, game counts over 100 mean that pre-learned data is included in the table alongside the tournament data. If Locutus was not trained on a near-final version of the opponent, then the two could be significantly different.

After seeing a few Locutus-PurpleWave games I got the impression that PurpleWave reacted adequately to Locutus’s trick strategy of cannoning the ramp and then dropping zealots. So I was surprised that Locutus considered it the best choice. But the overall win rate is high compared to the tournament results, so I suspect it is influenced by pre-learned data from games against a weaker version of PurpleWave.

The numbers in the “recognized” columns of the plan table show how widely Steamhammer cast its net for a solution to Locutus.

Locutus never tried to steal the gas of a zerg. Objectively, that makes sense. In the context of bot play, I’m not so sure; many bots of all races mess up their builds in the face of a gas steal.

Locutus declared an enemy-specific strategy against Iron. I’m not sure why it also had pre-learned data.

Proxy DT rush. That tends to confirm my picture of XiaoYi as vulnerable to tricks.

Locutus configured an enemy-specific strategy against UAlbertaBot. Openings other than CannonFirst4GateGoon are from pre-learned data, which was ignored in making the opening decision.

Today is Steamhammer. With a mid-rank finish and the widest range of builds, plus informative game records, Steamhammer may give us the best insight into how other bots played.

The tournament was 100 rounds, and Steamhammer was configured to remember the previous 100 game records, because in play there is no reason to remember more (earlier records are increasingly discounted). Steamhammer also had pre-learned game records for many opponents, so when the game record count reached 100, new records added caused old pre-learned records to drop away. Not all 100 tournament games happened for each opponent, but the pre-learned games filled in the small gaps so that Steamhammer ended up with exactly 100 game records per opponent in every case.

The “opening” table counts Steamhammer’s opening choices. The “plan” table shows the plan that Steamhammer first predicted that the opponent would play, then recognized that the opponent was playing. Both prediction and recognition can be wrong. The timing table is new this year, an attempt to get a little more information out of Steamhammer’s rich game records. For some events, it gives the count of games in which the event occurred, and the median time, earliest time, and latest time it occurred in those games when it did. The times are given under the assumption that 1 second of game time is exactly 24 frames, a simplification.

• gas steal attempt - When Steamhammer sent out the drone to steal gas (if it did).
• gas steal success - Whether the gas steal attempt succeeded in taking the opponent’s gas. Steamhammer doesn’t record the time it happens, so this is only a success count.
• enemy scout - When the enemy scout first reached Streamhammer’s base.
• enemy combat units - When the first enemy combat unit was seen.
• enemy air units - When the enemy is first known to have tech for flying units (except overlords).
• enemy cloaked units - When the enemy is first known to have tech for cloaked units.

It looks like Locutus opened forge-expand every game. It worked. Steamhammer desperately tried everything, including ZvZ builds and island builds, and finally squeezed 3 wins with a risky extreme macro opening, 4 hatcheries before spawning pool, which was able to win one game in five. I should add 5 and 6 hatch before pool and see if they help.

Locutus rarely made corsairs or dark templar. I wonder what its criteria are? Maybe it won before it got that far. The scout was usually quite early, and the first combat unit was seen late, as expected for a cannon-first opener.

I played over the 3 wins. They were in rounds 65, 70, and 73; after that, I expect that Locutus found a way to win. In 2 games, Steamhammer pulled ahead in early economy with its greedy opening, then struggled to defend and fell into a losing position. But Locutus got most of its units stuck in its base, and Steamhammer was able to turn it around and win after a hard fight with critical defiler support. In the third win, Locutus chose a zealot-archon unit mix that Steamhammer knows how to cope with, and zerg powered through.

PurpleWave in contrast went with mostly 2 gate openings against Steamhammer; that’s what “heavy rush” means for protoss. Steamhammer countered with early sunkens plus hydras or, less successfully, mutalisks (this version had a bug that weakened mutalisk play). There are also 3 wins with a ZvZ fast mutalisk opening. 2 gates should beat that, so protoss either played poorly or chose a different build in those games.

BananaBrain contrasts with both previous opponents in that it played a variety of builds. Steamhammer was unable to predict what was coming. It looks strange that the best reaction was an opening designed to counter terran factory-first builds that include a vulture runby, but in fact it is a mildly specialized 2 hatch mutalisk variant and not so surprising. BananaBrain made corsairs and dark templar in most games.

DaQin played forge-expand and has similar timings to Locutus, for the same reasons. The fast scout is to allow adjustment of the cannon count and timing, and the late combat units are due to getting a gateway later. Steamhammer couldn’t find any better reaction than to try to bust with zerglings, either early or late, and it was not particularly successful.

ZZZKBot mostly played a turtle-into-mutalisks strategy against Steamhammer, and was somewhat successful. You can read the idea straight out of the tables above. The 2:25 earliest timing but 4:06 median timing for combat units says that ZZZKBot sometimes rushed zerglings, but usually not.

Microwave played a 9 pool speed build into expansion and then spire, which you cannot read out of the plan table because Steamhammer didn’t recognize it accurately. But in the timing table you can see that combat units (zerglings) were early and air units (mutalisks) were not late.

Steamhammer was not able to steal Microwave’s gas. It probably should have stopped trying.

Look at that huge range of scout timings! 0:34 means that the scout SCV was sent immediately at the start of the game and went directly to the zerg base. 15:09 probably means that no enemy unit got into the base until the end of the game when Steamhammer lost (Steamhammer is on BWAPI 4.1.2 and cannot detect scans). Steamhammer prevented the scout entirely in 13 out of the 100 games by its own count; 15:09 is probably the same. Steamhammer was not able to steal Iron’s gas, and did eventually give up trying.

Steamhammer liked 7 pool against XiaoYi, just as Microwave did, but also liked its dawn hydra rush.

Thanks to pre-learning, I expected Steamhammer to play its overpool turtle build every game. I’m not sure why it didn’t. I also don’t know how it hit on the 5 scout build, which means send out a drone at 5 supply to scout very early, then leave all decisions to the strategy boss. It’s a logical try against a random opponent, especially one that has a single strategy for each race, and it was fairly successful. But it did not appear in the pre-learned data.

AITP scored zip against both mass zerglings (9HatchExpo9Pool9Gas) and against fast mutalisks (AntiFact_13Pool). And it successfully scouted Steamhammer’s base only 25% of the time. If you don’t scout reliably, it will be hard to withstand rushes.

Steamhammer was not able to judge whether BunkerBoxeR was playing a proxy (with its proxy bunker) or a worker rush (since it sent SCVs in support). But it didn’t matter. The reactions are nearly the same. Since BunkerBoxeR never wants gas, stealing its gas was a waste.

Steamhammer knows 142 different openings. In the whole tournament, it was only able to try 111 of them! It tried the most openings versus protoss, since it was looking everywhere for an escape from the overwhelming top protoss bots. Most openings were tried only a few times and lost every game, which means that Steamhammer would have performed better without them. That’s expected and even intentional; my plan is to add smarts until it is able to make good guesses about what to try. The work is underway.

Microwave keeps its result files in the same format as UAlbertaBot: A file for each opponent, and in the file a list of strategies tried, each with win and loss counts. But Microwave independently restricts the win count and the loss count to not exceed 10. This amounts to intentionally forgetting older history when there has been a lot of it. The advantage is that Microwave adapts its strategies more quickly if the opponent shifts its play. The disadvantage, of course, is that information is thrown away. As a side effect, the numbers in the “total” and “overall” cells of my tables are not too informative.

This post looks at Microwave’s result_*.txt files for each opponent, since it’s what I’ve done before and I already had a script to parse them. This year Microwave also kept history_*.txt files with a record of each game. I could get a fuller picture of what Microwave did from the history files. I’m not sure whether Microwave uses the history files to make decisions. Still, if this is about “what Microwave learned,” then the result files are what Microwave learned, at least in large part.

Microwave has pre-learned data files for a number of opponents. Data from those files survived to be included in these tables. In other words, the tables here include not only tournament games, but in some cases preparation games played before the tournament.

Microwave’s author MicroDK commented that Microwave might have a bug in keeping its learning files, since the numbers did not always agree with official tournament results. As explained yesterday for UAlbertaBot, the player cannot always know what the tournament manager decides is the outcome of the game. Between that and the pre-learned data, I see reason to doubt that Microwave had a bug. But I didn’t look into details.

This year Microwave recorded a total of 32 strategies, compared to 19 last year. I tried to keep the tables tractable by breaking them down by opponent race, since not all strategies were tried against all races. Nevertheless, prepare to scroll right!

terran

It seems that most of Microwave’s openings worked about equally poorly against Iron, which is interesting and hard for me to explain. 2 hatch muta equals 3 hatch hydra bust equals 7 pool—among others? XiaoYi was vulnerable to rushes, and Microwave settled on 7 pool. After seeing the learning files of only 2 bots, I’m already getting a picture of XiaoYi as strong but apparently not robust against tricky strategies; UAlbertaBot chose DT rush against it. AITP and BunkerBoxeR were easy opponents and seem to have been vulnerable to the first thing Microwave tried, so that zerg never felt the need to vary.

The tournament had 100 rounds. Totals of more than 100 games versus an opponent, as versus Iron here, are a sign that pre-learned data was carried over. Microwave did not have time during the competition to try this many strategies so many times each.

#	bot	total	10Hatch9Pool9gas	2HatchHydra	2HatchLurker	2HatchLurkerAllIn	2HatchMuta	3HatchHydraBust	3HatchHydraExpo	3HatchLingBust	3HatchPoolHydra	4HatchBeforeGas	4PoolHard	4PoolSoft	5Pool	5PoolSpeed	6Pool	6PoolSpeed	7Pool	8Pool	9Pool	9PoolLurker	9PoolSpeed	9PoolSpeedLing	OverpoolTurtle	ZvZ_Overpool11Gas
8	iron	63-175  26%	1-5 17%	1-5 17%	1-5 17%	2-7 22%	5-10 33%	5-10 33%	1-5 17%	0-5 0%	1-5 17%	2-7 22%	5-10 33%	5-10 33%	1-5 17%	5-10 33%	1-5 17%	3-8 27%	5-10 33%	5-10 33%	3-8 27%	4-10 29%	2-7 22%	2-7 22%	3-8 27%	0-3 0%
9	xiaoyi	22-13  63%	0-2 0%	-	0-1 0%	-	0-2 0%	-	-	-	-	-	-	10-4 71%	1-1 50%	-	-	-	10-0 100%	-	1-1 50%	-	-	0-2 0%	-	-
12	aitp	10-0  100%	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	10-0 100%	-	-
13	bunkerboxer	10-0  100%	-	-	-	-	-	-	-	-	-	-	-	-	10-0 100%	-	-	-	-	-	-	-	-	-	-	-
overall		-  36%	1-7 12%	1-5 17%	1-6 14%	2-7 22%	5-12 29%	5-10 33%	1-5 17%	0-5 0%	1-5 17%	2-7 22%	5-10 33%	15-14 52%	12-6 67%	5-10 33%	1-5 17%	3-8 27%	15-10 60%	5-10 33%	4-9 31%	4-10 29%	2-7 22%	12-9 57%	3-8 27%	0-3 0%

protoss

Aha, Bananabrain had a weakness against Microwave’s 3 hatch zergling bust! I’ve seen the same on BASIL, e.g. Microwave-BananaBrain on Empire of the Sun, where BananaBrain was negligent in setting up the defense of its natural. In general, Bananabrain showed sensitivity to the opponent’s strategy; the other top protoss bots were more consistent.

#	bot	total	10Hatch9Pool9gas	2HatchHydra	2HatchLurker	2HatchLurkerAllIn	2HatchMuta	3HatchHydraBust	3HatchHydraExpo	3HatchLingBust	3HatchPoolHydra	4HatchBeforeGas	4PoolHard	4PoolSoft	5Pool	5PoolSpeed	6Pool	6PoolSpeed	7Pool	8Pool	9Pool	9PoolLurker	9PoolSpeed	9PoolSpeedLing	ZvP_10Hatch9Pool	ZvZ_Overgas11Pool	ZvZ_Overgas9Pool	ZvZ_Overpool11Gas
1	locutus	0-202  0%	0-10 0%	0-10 0%	0-10 0%	0-8 0%	0-10 0%	0-10 0%	-	0-8 0%	0-8 0%	0-8 0%	0-10 0%	0-10 0%	0-10 0%	0-8 0%	0-8 0%	0-8 0%	0-10 0%	0-8 0%	0-10 0%	0-7 0%	0-10 0%	0-7 0%	0-7 0%	-	-	0-7 0%
2	purplewave	26-154  14%	2-10 17%	2-9 18%	0-6 0%	0-5 0%	2-10 17%	2-10 17%	0-4 0%	3-10 23%	0-4 0%	0-4 0%	0-3 0%	3-10 23%	3-10 23%	0-3 0%	0-3 0%	0-3 0%	3-10 23%	2-9 18%	0-3 0%	0-5 0%	1-7 12%	3-10 23%	0-3 0%	-	-	0-3 0%
3	bananabrain	85-130  40%	1-3 25%	2-4 33%	2-5 29%	1-5 17%	2-4 33%	0-2 0%	1-4 20%	10-4 71%	1-4 20%	0-5 0%	6-7 46%	10-9 53%	10-9 53%	5-7 42%	3-5 38%	4-6 40%	1-3 25%	4-6 40%	4-6 40%	0-5 0%	2-4 33%	4-6 40%	0-2 0%	-	7-8 47%	5-7 42%
4	daqin	8-64  11%	2-9 18%	0-4 0%	0-4 0%	-	3-10 23%	0-3 0%	-	3-10 23%	0-3 0%	-	-	0-3 0%	0-3 0%	-	-	-	0-3 0%	-	0-3 0%	-	0-3 0%	0-3 0%	0-3 0%	-	-	-
10	mcrave	95-78  55%	2-2 50%	2-3 40%	5-3 62%	2-3 40%	10-4 71%	10-0 100%	0-4 0%	2-3 40%	1-2 33%	1-4 20%	3-2 60%	10-4 71%	1-4 20%	2-3 40%	5-4 56%	10-5 67%	4-5 44%	2-3 40%	7-4 64%	0-3 0%	3-3 50%	3-2 60%	2-2 50%	8-4 67%	-	0-2 0%
overall		-  25%	7-34 17%	6-30 17%	7-28 20%	3-21 12%	17-38 31%	12-25 32%	1-12 8%	18-35 34%	2-21 9%	1-21 5%	9-22 29%	23-36 39%	14-36 28%	7-21 25%	8-20 29%	14-22 39%	8-31 21%	8-26 24%	11-26 30%	0-20 0%	6-27 18%	10-28 26%	2-17 11%	8-4 67%	7-8 47%	5-19 21%

zerg

Steamhammer and ZZZKBot are opposite opponents, from Microwave’s point of view. Whatever worked against one did not work against the other. Most of the numbers in Steamhammer’s row, by the way, are from preparation games. I see the same numbers in the pre-learned data file. According to the history file, Microwave played its 9 pool speed opening in every game.

#	bot	total	12Pool	4PoolHard	4PoolSoft	5Pool	5PoolSpeed	6Pool	6PoolSpeed	7Pool	8Pool	9HatchMain8Pool8Gas	9PoolHatch	9PoolSpeed	9PoolSunken	OverpoolSpeed	OverpoolTurtle	ZvZ_Overgas11Pool	ZvZ_Overpool11Gas
5	steamhammer	26-16  62%	2-2 50%	-	-	1-2 33%	-	-	-	-	-	2-2 50%	1-2 33%	10-0 100%	1-2 33%	4-3 57%	-	-	5-3 62%
6	zzzkbot	67-70  49%	0-2 0%	1-5 17%	0-2 0%	10-7 59%	0-2 0%	0-2 0%	5-10 33%	1-5 17%	7-10 41%	10-7 59%	10-4 71%	0-2 0%	0-2 0%	3-4 43%	10-4 71%	10-0 100%	0-2 0%
overall		-  52%	2-4 33%	1-5 17%	0-2 0%	11-9 55%	0-2 0%	0-2 0%	5-10 33%	1-5 17%	7-10 41%	12-9 57%	11-6 65%	10-2 83%	1-4 20%	7-7 50%	10-4 71%	10-0 100%	5-5 50%

random

UAlbertaBot was the only random participant. It’s striking how similar openings can have different outcomes, though the numbers are noisy because the game counts intentionally limited and an opening that makes a bad first impression may not be repeated.

#	bot	total	4PoolHard	4PoolSoft	5Pool	5PoolSpeed	6Pool	6PoolSpeed	7Pool	8Pool	9PoolSpeedLing
11	ualbertabot	34-21  62%	5-4 56%	10-0 100%	4-4 50%	10-3 77%	4-3 57%	1-2 33%	0-2 0%	0-2 0%	0-1 0%
overall		-  62%	5-4 56%	10-0 100%	4-4 50%	10-3 77%	4-3 57%	1-2 33%	0-2 0%	0-2 0%	0-1 0%