Starcraft AI blog

In this game, Steamhammer hit on a surprising plan that exploited a weakness in Stardust. Even so, Stardust had tricks up its sleeve.

It is strategically correct for the stronger bot to play conservatively, taking no risks. Steamhammer happened across an opening which Stardust answers too conservatively: It proxied in Stardust’s natural. It started the hatchery almost immediately after scouting the location of the protoss base. Correct play is for Stardust to smash the proxy before it can be defended. Stardust scouted the proxy and immediately assumed without evidence that it was contained, so it played conservatively and did not try to break out. The yellow dot in Steamhammer’s natural is the scouting probe: Stardust had all the information it needed to conclude that the proxy was indefensible, but assumed that it was too risky to attack.

The production queues tell each bot’s strategy. Stardust made a robo to escape the containment by air. Also notice the Citadel of Adun. The two cannons next to the nexus are unnecessary; zerg does not have a lair, and protoss could have scouted it but did not bother to. Steamhammer’s opening build assumes blindly that the opponent will not attack—it is a build specialized for defeating one-base protoss players who build up and attack late. Steamhammer is making drones now in preparation for sunkens at the proxy and then a large army.

Both sides have attack +1 already. The citadel was for zealot speed. A shuttle can carry four zealots but only two dragoons. Stardust cleverly elevatored zealots from its main to the north of its base where they would not be seen, and ran them across the map. Steamhammer was ready anyway. Zerglings are about to hatch, and once they joined the hydras the zealots were afraid to engage and ran away. The zealots tried to retreat to the protoss main through the proxy, where sunkens and the zerg army slaughtered them.

After that zerg was in charge. Steamhammer immediately invaded the protoss base, while Stardust airlifted a probe out for a distant hidden base. There was more fighting, but Steamhammer is reliable about winning when this far ahead.

On Jade with its low main, it’s important to defend above the ramp if you can. Otherwise you don’t see what’s coming and you have to fight uphill. But as far as I can see, it didn’t affect this game. Stardust scouted the proxy and did not try to defend its ramp, except for one cannon.

Update: Steamhammer played a second game against Stardust, on the map Python. It went very much the same way. I was right that Jade’s low-ground main did not matter.

Second update, 10 July: Steamhammer has since won a bunch of games that went the same way. Here’s the first game that went differently, on Andromeda. It shows both the strength and the fragility of a strong proxy position.

Here is another valuable new Dave Churchill tool. It doesn’t seem to come with a name, but it is a web build order visualizer which uses BOSS behind the scenes. (I’m told it is a new and more powerful version of BOSS.) You enter up to 3 build orders, BOSS simulates them to find their timings, and it diagrams each one. The picture shows how inserting a drone into a 9 pool gas build, to get back to 9 workers, can delay the initial zerglings.

Partial instructions: + and - move a selected item up and down in the build order. X erases. X* erases the whole build. * selects the whole build. The various > and < buttons copy items between locations. In a diagram, hover over an item for info about its cost and timing.

It’s unfinished, and yet already valuable. Despite many limitations (and one bug I found, which has been fixed), I have already used it to analyze and optimize over a dozen builds. It’s much quicker than entering a build into Steamhammer and playing a game to get the timings. Some of the drawbacks in its current state:

• No instructions. I’m told it will get instructions by the time it’s finished.
• It does not support upgrades or research. That’s a big one.
• It does not support stopping gas mining (like mining 100 gas for zergling speed).
• It does not support pulling workers, even one worker to scout.
• It does not support the zerg extractor trick.
• If any of the 3 builds is invalid, you get a blank picture. There are no hints about what is wrong.

I found it best for low-economy builds. For zerg builds I tested to up 9 pool, its timings match well with Steamhammer’s execution. In overpool builds, only slightly slower, Steamhammer is able to insert an occasional extra drone or zergling without slowing down the timings. I expect that is because mineral locking makes mining more efficient than BOSS assumes. On the other hand, BOSS seems to believe that gas mining is a little faster than Steamhammer accomplishes it. That might be an issue of the time it takes to get workers into the refinery when it finishes. Even so, I can optimize a build (if it’s within the limitations) in the visualizer and then drop it into Steamhammer to see if further improvements are possible. It’s easier.

From a quick glance through the page source, it looks as though BOSS has been compiled into javascript using emscripten, so it executes in your browser. The visualizer works offline.

Good stuff already. How much better will it get?

I counted Steamhammer’s zerg openings, and found 222. Most of those I wrote as variations of standard builds, or when inspired to copy somebody else’s build ideas, or to systematically fill out a range of possibilities. A few are novel ideas that I had myself. Steamhammer’s new 12 gas 11 pool builds I have not seen elsewhere, though Steamhammer did already have a build named ZvZ_12Gas11Pool which is similar (it was an example of filling out a range of possibilities).

Why did I write over 200 opening builds? It’s obvious that Steamhammer can’t effectively use that many, because it doesn’t know how to choose between them without trying each one repeatedly. Against a difficult opponent, Steamhammer would have to play thousands of games to be likely to make the best choices, and even then it would risk being wrong—the opponent is learning too. I wrote them all anyway, because I have been planning from the beginning to make learning smarter. If the opening timing project works as well as I hope, the bot will be able to quickly zero in on promising builds from its large library, perhaps turning up surprising but effective tries. Compare my post Precomputing a catalog of build orders from April 2016, before I started work on Steamhammer.

11 gas 10 spawning pool is a standard zerg opening stem. It continues into fast one-hatchery mutalisks for ZvZ (implemented in Steamhammer in version 1.0 in January 2017 and for a long time Steamhammer’s favorite ZvZ build), or into one-hatchery lurkers for other matchups (mainly useful against terran). The timings have a good feeling, because when the spawning pool finishes, you can start your lair immediately and simultaneously start zerglings. You’re spending a lot to get fast tech, so the second hatchery comes much later.

go to 11 drones

extractor

spawning pool

2 more drones

when the pool finishes: lair 3 pairs of zerglings

(continue with spire or lurkers)

I noticed that if you squeeze in a couple drones and drop one of the zergling pairs, you can get a second hatchery right after without delaying your tech. The only delay is in getting one extra drone before the extractor (you do have to wait a bit for the larva to spawn); after that, the build is every bit as smooth as the classic version. For the cost of that delay plus a lower number of zerglings, you get a stronger economy and a second hatchery, with a much wider selection of follow-up plans.

go to 12 drones

extractor

spawning pool

3 more drones

when the pool finishes: lair 2 pairs of zerglings

hatchery

(continue with spire or lurkers)

The build shares ideas with 12 pool builds, where you use the high number of early drones to get a second hatchery, but gets the lair before the second hatch. It also shares ideas with 2.5 hatch muta builds, where you get your tech first and add the extra hatchery along the way. You could think of it is as a 1.5 hatchery lurker/muta build.

I prefer the lurker version. Steamhammer wins a lot of games versus terran with 1 hatch lurker builds, but it is not skilled at using its lings along with the fast lurkers. And many terrans stay safe at home anyway, so that lings have little value before lurkers; all they can do is keep an eye on the front line. Getting an extra hatchery and stronger economy seems like a good tradeoff.

Here are the timings of some of Steamhammer’s lurker builds. The lurker column is the number of lurkers made in the first wave, for an initial attack (Steamhammer’s lurkers always attack). The time given is the frame that the first lurker hatches from its egg, median of 3 runs.

build	second hatch	lurkers	frame
11 gas 10 pool lurker	after lurkers	3 then 1 more	7405
12 gas 11 pool lurker	after lair	4 at once	7551
12 pool lurker	before lair	5, as gas allows	7785
12 hatch lurker	before pool	5 at once	8513

Here are my implementation thoughts about opening timing data, as mentioned yesterday. I haven’t decided whether this is what I’ll do next, still thinking. I will at least do something similar eventually.

the data

1. Record timings for all of Steamhammer’s openings, in a static data file to be read at startup. The timings should include the time when each tech or production building finishes, plus the number of workers and the army size and composition at the end of the book line (meaning the units produced; some may have been lost), and maybe a few other things. Time resolution of one second or a few seconds is probably fine. Even so, timings will vary from game to game, so maybe the timings should give low and high values, or mean and variance, or something.

Another idea is to accept that new openings will be added and reject the work of timing them before they can be played. Keep a database of opening timings and update it after each game. That’s only safe on a server which plays one game at a time; for tournaments like AIIDE the database would have to be frozen and read-only.

2. For each game against a given opponent, record the earliest time that each enemy unit type is scouted, including buildings. Steamhammer already does this, with its “unit timing” skill (implemented using the skill kit). Also record the timing and army size and composition of the enemy’s first attack, or maybe its first few attacks, or maybe all of its major attacks. I’ll see what helps.

using the data

The data about the enemy can be used to recognize enemy builds earlier and more consistently. Most bots have a small repertoire of openings. As Steamhammer plays, it can check its scouting data for the current game for the closest matches among recorded games. If the records say that the enemy followed up the same way in all of the close matches, then the enemy strategy is predicted to that extent. You can see it as a kind of case-based reasoning: Find approximately matching cases and generalize from them.

We don’t have to fully predict the enemy strategy to react to it, we only need to know constraints on it. For example, if we’re going to add static defense (whether written into the opening or in reaction to the enemy army size), then we can check records of when the enemy first attacked: Don’t build sunks too early. If a clever enemy notices the vulnerability and attacks early, too bad, but then we have a new game record and will know for next time.

The main purpose of the opening timings is to choose openings. The records of enemy games tell us the range of enemy play. When choosing an opening at the start of the game, before any scouting information is available, we can try to pick one with unit mix and timings that counter the range of enemy play. One basic adaptation is to try to always be a little greedier than the enemy, to get ahead in economy (except when the enemy is too greedy, then we can rush). That’s a principled way to choose 5 hatch before pool versus Dragon. Another is, if the enemy prefers certain units, we can pick openings that produce counter units at the right time.

Of course the data can also be used to adapt openings when our first choice was not right for the enemy’s actual play. It will be a while before Steamhammer can do that with generality.

Part of my regular change list for each new version is a list of openings I’ve added, so here’s another preview. The list is long this time, but easy to write up. Only a few of these openings are configured for regular play, but all will show up now and again.

Steamhammer’s new proxy skills enable a huge range of cheese builds. I wrote 2 or 3 for each race, sort of as samples.

terran

• In base proxy openings ProxyBBS and ProxyFactory. Ecgberht occasionally pulls out a similar proxy factory, which has scored wins over Steamhammer. These builds annihilate unready opponents but show execution weaknesses if the enemy is able to defend at all. BunkerNatural makes barracks in the center and bunker at the enemy natural, and scouts at a timing so that it just barely works reliably on a 4-player map.

• 10-10-10Vultures gets vultures earlier than the standard factory timing. I wrote this to test zerg reactions to fast vultures. Might as well keep it.

protoss

• Proxy2Gate in a corner of the enemy base, which I haven’t seen another bot try, and CannonRushNatural with dragoon followup, also new to bot play.

zerg

• Burrow versions of existing openings, zergling openings with different timings. It is part of my followup on the burrow skill. As burrow gains more uses in the future, these openings should show up more often. 6PoolBurrow 6PoolSpeedBurrow 8Hatch7PoolBurrow 8Hatch7PoolBurrowB 9PoolBurrowB 9PoolSunkBurrow OverpoolBurrow Overpool_3HatchBurrow 9Hatch8PoolBurrow 10HatchBurrow Over10HatchBurrow 3HatchLingBurrow 5HatchPoolLingBurrow.

• Proxy openings: Proxy8HatchNatural makes a quick hatchery in the enemy natural and sunkens it up. AntiTyr and AntiTyrLurker are the same idea, but timed much later to counter the Tyr protoss build where it makes cannons in its base and builds up for a timing attack. AntiTyr serenely swallows the attack and wins. Steamhammer still needs a couple more skills before it can do Fried Liverpool.

• AntiFactory2 is a slightly faster version of Steamhammer’s longstanding anti-factory opening, with hydralisks first. The original opening was timed to stop a 3-vulture runby, but lately a couple of terrans have been winning with a 2-vulture runby which is earlier and sneaks in before the defenses are ready. AntiFactory2 closes the gap. I configured it as a top answer to factory openings, so it should be fairly frequent.

• 11Pool is slightly faster than 12 pool for ZvZ, filling a small gap.

• 10HatchLing and 10HatchLing2 are specialized versions of 10 hatchery 9 pool which go all-in on zerglings.

• Experimental openings: Phlegethon I timed and showed to be inferior. The alternative 2x10Hatch (10 hatchery, 10 hatchery, 9 spawning pool with repeated use of the extractor trick) I have not timed, so in my ignorance I allowed myself to write variants 2x10HatchSlow 2x10HatchAllIn and 2x10HatchBurrow. The less I know, the more fun stuff I get, there’s a lesson!

• Over10Hatch11Pool starts with the same extractor trick-overlord-hatchery sequence as a number of common Steamhammer builds, but inserts a couple extra drones before the spawning pool to build up the economy.

• Going the opposite direction, 3 hatcheries before pool but cutting drones to get the hatcheries faster than standard, are 12-11Hatch, 12-12Hatch, and 12-13Hatch. I was pleased with these and added 12-11HatchLing as a zergling all-in version.

• 2HatchLurkerPure is a variant 2 hatch lurker build which includes minimal zerglings, making drones instead, so that there’s a little more economy. I figure that if opponents lose because they are unprepared with detection, then the zerglings may not help much.

• QueenRush and GuardianRush are not really useful except for testing (the only reason I wrote the queen rush in the first place). But then, I used to think the same about the hive rush build, until it scored wins over BananaBrain. At least they’ll be entertaining if they ever show up. The queen rush makes a half dozen queens with broodling nice and early in the game.

I’ve been exploring build orders in which zerg uses the extractor trick repeatedly to make its first two buildings at 10 supply before the overlord. I was looking for a build as finely tuned as the Styx opening, but for 3 hatcheries. Here is the best one I found. I call it the Phlegethon build, parallel to the Styx, and I compare it to a more standard 3 hatch ling build.

step	Styx	Phlegethon	3 hatch ling
1	5 x drone (9 total)		4 x drone
2		extractor trick	overlord
3	spawning pool	hatchery	4 x drone (12 total)
4	drone (9 total)	extractor trick	hatchery
5	overlord	overlord	spawning pool
6	3 x zergling	spawning pool	3 x drone
7		4 x drone
8	hatchery		hatchery
9	extractor		extractor
10	3 x zergling	6 x zergling	6 x zergling
11	metabolic boost		metabolic boost
12	zerglings		zerglings

I inserted blank steps on the left and right to show how parallel the builds are. Phlegethon’s overlord before spawning pool gets the needed extra drones with minimal loss of time and pulls ahead in minerals compared to overlord after pool. It’s possible to make either 3 or 4 drones after the spawning pool; there is little difference in timings, but the 4 drone version is slightly superior in keeping down its larva count in the runout. The third hatchery starts slightly before the spawning pool finishes, and taking gas delays the first pair of zerglings by around 2 seconds. If for some reason you want zerglings right now instead of zergling speed later, I think it’s reasonable to insert as many as 5 pairs of zerglings before the extractor (but it delays speed a lot in return for getting zerglings a little earlier).

You could say that 4 pool is a one hatchery member of the Styx family. It ends up with 3 drones and produces zerglings constantly from 1 hatchery. Styx ends up with 7 drones and produces speed-upgraded zerglings constantly from 2 hatcheries starting from the 7th pair of zerglings. Phlegethon and 3 hatch ling both end up with 11 drones and produce constantly from 3 hatcheries. Each member of the family has one more hatchery than the last, so that it starts zergling production later but produces at a higher rate. All have a good drone count for constant production.

Now to compare them. Was my clever trickery worth it? The Styx timings are from the data for my post on timing the Styx build. The Phlegethon and 3 hatch ling timings are from single test runs with variants optimized the same way, no scouting and all hatcheries in the main.

item	Styx	Phlegethon	3 hatch ling
first lings	3267	4580	4520
speed finishes	5955	6769	6594

The standard 3 hatch ling build is superior in every way that matters. Phlegethon gets its second hatchery faster, but is slower in every other respect; the margins are not large, but they are definite. I draw lessons: 1. Standard builds are standard for a reason. Somebody considered all these possibilities years ago. 2. If you’re aiming for a given drone count, get as many as possible up front. The early drone catches the minerals.

I’ll graph the production curves another time. The 3 hatchery builds produce zerglings 1.5 times as fast as Styx, so they will surpass it after a while despite starting later. Whether that is better or worse in the game will depend on what the opponent is doing. We can expect that later members of the family will have decreasing results as they take ever longer to catch up. Also an over-large zergling army gains in strength less than it gains in numbers, because zerglings don’t have range and the ones in back can’t fight.

So—can anyone find a better build that has the same goal of constant speedling production from 3 hatcheries, or is 3 hatch ling optimal? There is reason to suspect that the Styx build is optimal for its goal. I don’t know any better way to prove it than exhaustive search.

Here’s a table of variants of the Styx build. The left one, 7 drone hatchery first, is the original; the other 3 are natural variations. The story from Dan Gant is that an entire population of machine learning agents all converged on the original build, so according to those agents, it’s the best choice. I won’t accept their opinion without checking. Steamhammer, of course, includes all 4 of these builds, and has additional decorations beside.

step	7 drone hatch 1st	7 drone gas 1st	8 drone hatch 1st	8 drone gas 1st
1	5 x drone (9 total)
2	spawning pool
3	drone (back to 9 total)
4			extractor trick (10th drone)
5	overlord
6	3 x zergling
7	hatchery	extractor	hatchery	extractor
8	extractor	hatchery	extractor	hatchery
9	4 x zergling	2 x zergling	4 x zergling	2 x zergling
10	metabolic boost (zergling speed)
11	keep making zerglings

The 4 variants differ in 2 features. Feature 1: The 8 drone variants, on the right of the table, throw in an extractor trick (step 4) to get an additional drone, leaving the zerg with 8 drones mining at the end of the build rather than 7. Feature 2: You’re making both a hatchery and an extractor, and you can make them in either order (steps 7 and 8). Hatchery first means the hatchery finishes a little earlier and may be able to raise the zergling count a little. There are also timing effects because of the different number of zerglings made (step 9) before starting zergling speed (step 10).

The machine learning agents concluded that the leftmost build is best. My intuition is that the rightmost build is best: The extra drone from the extractor trick doesn’t help at first, but provides more flexibility in the long run (in case you don’t win outright). Getting gas before hatchery barely delays the hatchery, because the extractor does not finish before the hatchery starts, but gets zergling speed significantly earlier, which I feel outweighs the couple extra zerglings you may gain by getting hatchery first.

I’m not trusting my intuition without checking, either. This post is about measurements. I can measure timings. I can’t measure which variant is objectively stronger, because it depends on the skill of the player. PerfectBot is not available to tell us. Are you better at taking advantage of zergling numbers, or zergling speed?

All tests were run on the map Heartbreak Ridge. I didn’t use Steamhammer’s existing builds, but wrote special ones to reduce variance. Each build calls for exactly 40 pairs of zerglings. There is no drone scouting. The second hatchery goes in the main base because long drone movements will vary more. Overlords were inserted by Steamhammer’s usual method, which is heuristic but consistent. Zerglings stayed put and did no fighting so that overlords were made at predictable points; I disabled the Recon squad and convinced the opponent to also stay home. Building placement is different between the 2 starting bases on the map, so I only timed games from the 9 o’clock base. Zerglings gathering around the main hatchery interfered with drone movement when placing buildings and caused variations in the timings, so I had them gather at a distance. I recorded data for 5 runs of each build.

Zergling speed timing: The frame when metabolic boost finished upgrading. The gas-first builds get zergling speed over 330 frames faster, around 14 seconds at 24 frames per second. That’s a long time during a game, but don’t forget that it is only a window of opportunity. If there is any advantage to be gained by a gas-first build, it must be gained during that interval. With hatchery first, the extractor trick to gain the 8th drone causes a 100 frame or 4 second delay, which is much more than I expected. With gas first, the extractor trick causes no measurable delay. Now that’s interesting.

build	median	low	high
7 drone hatchery	5955	5941	6003
7 drone gas	5621	5591	5659
8 drone hatchery	6055	6054	6092
8 drone gas	5621	5594	5633

Zergling timing. For each build, I took the run with the median timing of zergling speed from above, and put only that data into these charts. The initial 6 zerglings happen after the extractor trick and before the hatchery/extractor decision, so only the 7 drone/8 drone division between the builds is meaningful. The numbers say there may be added variance in the extractor trick causing some delay on average, but no necessary delay. The 8th zergling (the fourth pair) comes after the hatchery and extractor and before zergling speed. For the hatchery first builds, zergling speed finishes after 22 or 24 zerglings have been produced. For the gas first builds, after 16 or 18 zerglings.

This scatter chart shows how similar the four variants are. The x axis is time, y is the zergling count. Blue is the original 7 drone hatchery first build. The other colors are visible a bit around the edges of the blue. The initial 6 zerglings appear at the lower left in a column. There are visible gaps where overlords are made.

Here is a more useful visualization. I subtracted the blue timings from each build and plotted the residuals. A point above the horizontal zero line means that that build was later than the 7 drone hatchery first build to reach that specific zergling count. A point below the line means it was earlier. The vertical axis gives the frame difference. 40 points are plotted for each build, one point for each zergling pair from 1 to 40.

The original blue build is quite good at pumping out lings. It is ahead of the others at more timings than not. But every build is ahead at some timings. The regular spikes are related to overlord spawning. If you are fighting hard you will not need to make overlords, and the results may be different. You can think of each timing when a build is ahead as a window of opportunity, and compare the zergling count windows to the zergling speed window of 14 seconds for the gas-first variants.

Extra minerals. The 7 drone variants are just about perfectly tuned to balance mineral income and larva production from 2 hatcheries. After starting 40 pairs of zerglings, less than 50 minerals are on hand and the larva count is 0 or 1. That means that the 8 drone variants cannot gain an edge in zergling production, even in the long run. Instead, the 8th drone allows flexibility in case the build does damage but does not win outright; the player has more resources to switch into another line.

After starting 40 pairs of zerglings, the 8 drone variants have banked about 400 minerals. Normally, you’d prefer to spend them before getting that far. One idea is to spend the minerals on a sunken—perhaps an offensive sunken against zerg. Another is to add a third hatchery, pause zerglings briefly to make a few drones to keep the hatchery fed, and go back into zergling production at a higher rate. Another is to put the 8th drone on gas and prepare to suddenly switch into a tech build.

Old zerg bot StyxZ has been getting updates recently, and I have been watching it steadily climb the rankings. Today Styx became the top zerg on BASIL, at least for the moment, so clearly it is time to write about it!

To give an impression of how far Styx has climbed, its lifetime win rate on SSCAIT is about 34%. In the last 24 hours on BASIL, I count 5 losses and 35 wins, an 88% win rate. On the BASIL crosstable its row is almost all red and stands out sharply in its new green environment. The degree of improvement is astounding.

Styx is distributed as a JAR file, so I unpacked it and took a look. I found that Styx is written in Kotlin, a recent language. That makes me wonder: Is this Styx version a complete rewrite, new code that replaces the older version? That would fit in with the quantum leap in results. But I also see both of the map analysis libraries BWTA and BWEM, which gives the impression that Styx is in the process of transitioning to BWEM, though perhaps it is using both to take advantage of different features. Also in there is the jts geometry library, which seems potentially useful for map-related calculations. The jts version is 1.16.1, officially released this past February (I love that it is the same as our Starcraft version number).

Also in the object code I see the ASS combat simulator, a project started only last year. I see the jsoniter JSON parser, which suggests that Styx is reading data files of some kind, whether static initialization and configuration or dynamic learning files.

The feeling I get is that work on Styx was restarted sometime this year, and a substantial amount of new work has been done. It’s hard to say exactly what, though, since I didn’t save an old version to compare.

What specifically makes Styx stronger? The most obvious improvement is a new build, much sharper than what Styx used to play: It is 9 pool, second hatchery, then zergling speed, and don’t waste time making extra drones but keep up zergling production with a 7 drone economy, which enough for constant production from the 2 hatcheries. The mass lings overrun opponents of every race, including solid defenders like McRave. The purple zerg PurpleSwarm has been playing a similar build for a while, also with success.

The new build is great, but it does make me wonder how much the other changes to Styx contribute.

The frame when the first zealot completes. The usual caveats apply: I measured only 1 run, and there is variation; maps and starting positions are all a little different; Steamhammer’s execution is not frame-perfect. Still, I found protoss timings more repeatable than zerg timings, maybe because larvas have randomness in spawn timing and position.

build	zealot
4 pylon 4 gate	2734
5 pylon 5 gate	2823
5 pylon 6 gate	3003
6 pylon 6 gate	2984
6 pylon 7 gate	3122
7 pylon 7 gate	3158
7 pylon 8 gate	3246
8 pylon 8 gate	3305
8 pylon 9 gate	3316
9 pylon 9 gate	3532
8 pylon 10 gate	3468

Recommended builds are darker. That means builds that seem to offer some advantage; it’s up to you to decide whether the advantage is worth the cost. The lighter builds are are those that appear inferior.

8 pylon 10 gate is the standard and the most economical gateway timing. Any faster build sacrifices some economy and can be called a rush.

The purpose of including 5 pylon 6 gate is to show that for a 6 gate or earlier, you lose by making the pylon early. For a 7 gate, you can choose either 6 pylon or 7 pylon, with different tradeoffs. 9 pylon 9 gate is there to show why 8 is the standard pylon timing.

8 pylon 8 gate barely has an edge over 9 gate. I didn’t know that. On some runs, I got only a 2 frame timing difference. If you’re rushing with 8 gate, pylon on 7 is recommended to shave seconds.

two gates

I also wrote a bit of code to time when the second zealot finishes. If you open with 2 gates, you care when your zealot count starts to get ahead of a 1 gate build. Most of these are with the standard pylon on 8. The timings seemed more variable than with a single gate.

build	zealot 1	zealot 2
7 pylon 7-7 gates	3141	3613
7 pylon 7-8 gates	3138	3639
7 pylon 8-8 gates	3263	3599
8-8 gates	3311	3613
8-9 gates	3372	3711
9-9 gates	3321	3678
9-10 gates	3317	3770
10-10 gates	3431	3773
10-11 gates	3431	3918
10-12 gates	3441	3988

Again, recommended builds for double gate zealot are darkened. You can go with a cheesier build from one of the top rows if you believe that a faster first zealot will be able to cause consternation before its partner arrives. I evaluated those builds under the assumption that the timing of the second zealot is what matters.

10-12 gate is the most economic version. You get a later initial blow and then a choice of heavier long term zealot pressure, or transitioning out whenever you choose with a sound economy. Skynet is one bot that plays 10-12 gate strongly.

With 7 pylon, it seems there is no advantage to any double gate earlier than 8-8. And 7 pylon 8-8 is at most marginally faster than 8 pylon 8-8, so it looks as though pylon on 8 is better. 8-9 gate provides no edge over 9-9 gate, so 9-9 is the next possibility. 9-10 gate has no edge over 10-10 gate.

The last couple of posts were time-consuming, so here is data I can gather with much less effort: The frame when the first terran marine completes, given a barracks made with a given SCV count and assuming the marine is started as soon as possible. A bot can use these timings to judge whether a terran opponent rushed an early barracks. And a terran bot author can use the timings to help decide whether a rush is worth it. Bear in mind that even 8 rax, the most standard terran early pressure build, sets terran far back economically compared to an economic barracks timing; the attack has to make up the difference in damage done.

build	marine
4 barracks	2278
5 barracks	2430
6 barracks	2594
7 barracks	2777
8 barracks	2911
9 barracks	3128
10 barracks 10 depot	3236
9 depot 10 barracks	3527
9 depot 11 barracks	3709

If the fast barracks is a proxy, the marine will not have as far to walk, but in return terran must send an SCV earlier and will be lower on minerals. Also, if the opponent defends, the proxy barracks may be far out of position, and terran will be a sitting duck for the counterattack.

To make constant marines from 1 barracks, you only need 3 SCVs. A double proxy barracks starts to be feasible with 7 or 8 SCVs total, accounting for sending out 2 SCVs to build, plus occasional supply depots and a possible offensive bunker.

The last build here, 9 depot 11 barracks, is the most standard barracks timing. It’s not slow at all. You can even delay the barracks a little more, to gain resources to do something else faster, and I think it is rarely dangerous.

I decided to make competitive versions for all the winning builds, not only the fastest, because I’m not sure how effective they will be in practice. A fast build can barely afford supporting units, and depends on a fast strike for its power—if any. In fact, I ended up writing 5 different builds. I wonder why Steamhammer has so many openings?

Steamhammer’s statistics from AIIDE 2018 may shed a little light. See the “overall” table at the bottom. The interesting number is not each opening’s winning rate, which depends on the opponents that it was used against, but the number of games it was played in: How often did Steamhammer think it was the best opening? The best opening against a strong opponent may have a 10% win rate, and against a weak opponent may have a 90% win rate, but if the opening was tried often then Steamhammer found it useful, and that is what matters. (The same idea of looking at the number of tries instead of the winning rate is common in MCTS algorithms.)

opening	tries
9PoolLurker	91
OverpoolLurker	76
2HatchLurkerAllIn	52
2HatchLurker	6

The openings are listed from fastest to slowest. The numbers say that the faster lurker rushes were more useful, and the 2 hatchery all-in opening (which makes many zerglings) was far more valuable than the middle-of-the-road 2 hatchery lurker, which tries to keep its options open. Well, it may be simply because the faster rushes get zerglings right away, which by themselves are enough to destroy a low-end terran opponent (Steamhammer can win games against weaker terrans before the lurkers arrive). Even so, it’s suggestive evidence that a faster lurker rush may be worthwhile.

I tackled the faster openings first, because they have fewer degrees of freedom. I thought they would be easier because there aren’t as many possibilities to check, but in fact they required more detail work. In adding zerglings to make the openings useful in competition, there are 2 goals to meet. First, you’d like at least one pair of zerglings early to handle the enemy scout. They can catch an enemy scout in the base, block the ramp if the enemy hasn’t scouted yet (these builds can’t afford to block with a drone), or go look for the enemy base themselves. Second, you’d like as many zerglings as possible to accompany the lurkers and make the rush stronger. But in either case, it defeats the purpose if zerglings delay the lurkers.

scouting

TLDR: Good enough on all maps, with a little care.

In the 7 pool dawn lurker rush, the fastest of them, the build cannot spare a single extra unit to scout. Only the initial overlord is free to look for the enemy base; the second overlord spawns too late to help. The overlord is able to scout one base location before the lurkers hatch. If the first location is empty, it is just a little short of the second location when the lurkers hatch. On a 2- or 3-player map, this is perfect. On a 4-player map, it’s also OK provided the overlord does not scout diagonally, which takes longer. When the lurkers finish their morph, they are still in the zerg base, and by the time they have moved far enough that they have to decide to turn one way or the other, the overlord will have scouted the next location and the enemy start will be known. So the build should be playable on all competitive maps provided the overlord takes the shortest scouting path on the larger maps.

The other builds get lurkers later, so there is more time to scout.

7 pool dawn lurker rush

Here is the original, copied from yesterday.

"7Pool6GasLurker" : { "Race" : "Zerg", "OpeningBuildOrder" : ["go nonadaptive", "3 x drone", "spawning pool", "extractor", "go gas until 350", "2 x drone", "lair", "drone", "hydralisk den", "lurker aspect", "2 x drone", "go gas until 250", "overlord", "2 x hydralisk", "2 x lurker"] },

The build is extremely tight and does not have room for zerglings until after lurker research starts. Even then, to avoid delaying the lurkers the build needs to squeeze in 1 additional drone. It is only possible to make 2 pairs of zerglings total before the lurkers start to morph. Here’s the build that gets the 4 zerglings as early as possible. Compared to yesterday’s build, it changes the last drone to a zergling, and inserts one more zergling before the lurkers. At the end of the build, zerg has 8 drones (not 9 as yesterday).

"7Pool6GasLurker A" : { "Race" : "Zerg", "OpeningBuildOrder" : ["go nonadaptive", "3 x drone", "spawning pool", "extractor", "go gas until 350", "2 x drone", "lair", "drone", "hydralisk den", "lurker aspect", "drone", "zergling", "go gas until 250", "overlord", "2 x hydralisk", "zergling", "2 x lurker"] }

I do not recommend the A version above. I think the B version below is better. It keeps the 9th drone and gets the 2 zergling pairs later. With the income from the 9th drone, it is possible to get the same 4 zerglings without delaying the lurkers.

"7Pool6GasLurker B" : { "Race" : "Zerg", "OpeningBuildOrder" : ["go nonadaptive", "3 x drone", "spawning pool", "extractor", "go gas until 350", "2 x drone", "lair", "drone", "hydralisk den", "lurker aspect", "2 x drone", "go gas until 250", "overlord", "2 x hydralisk", "2 x zergling", "2 x lurker"] },

Which version is truly better might depend on how you intend to follow up. The build is all-in, so one natural followup is to keep making zerglings until the lurkers hatch, then pull drones and go for broke. Use drones and lings to shield the lurkers until they can burrow in good positions (I think it’s a difficult skill for a bot). All units should attack together, so it doesn’t matter that one pair of zerglings comes slightly later, and pulling 1 drone more makes the attack a trifle stronger. Alternatively, if you don’t pull drones, having 1 drone more opens options for what’s next.

8 gas dawn lurker rush

Yesterday’s original:

"8Gas7PoolLurker" : { "Race" : "Zerg", "OpeningBuildOrder" : ["go nonadaptive", "4 x drone", "extractor", "go gas until 100", "spawning pool", "2 x drone", "lair", "drone", "go gas until 500", "hydralisk den", "drone", "lurker aspect", "overlord", "2 x hydralisk", "2 x drone", "2 x lurker"] },

This slower build remains very tight, but resources are more plentiful. I again made 2 versions, A and B.

Version A fits 3 pairs of zerglings before the 2 lurkers (using up all available larvas), and has excess minerals so it is soon possible to start a second hatchery. Because of the hatchery, it finishes with 8 drones. With a second hatchery, it makes no sense to pull drones. You might plan an escalating lurker-ling followup to keep the pressure on, in which case you’ll research zergling speed and make lings from the second hatchery (if so, I think you’ll want to go to 10 drones).

"8Gas7PoolLurker A" : { "Race" : "Zerg", "OpeningBuildOrder" : ["go nonadaptive", "4 x drone", "extractor", "go gas until 100", "spawning pool", "2 x drone", "lair", "drone", "go gas until 500", "hydralisk den", "drone", "lurker aspect", "overlord", "2 x hydralisk", "3 x zergling", "2 x lurker", "hatchery", "overlord"] },

Version B collects more gas to make 3 lurkers instead of 2, and has minerals and larvas for only 2 pairs of zerglings. It finishes with 9 drones. There is no mineral excess. This version hits harder but has a weaker followup, so it is more all-in.

"8Gas7PoolLurker B" : { "Race" : "Zerg", "OpeningBuildOrder" : ["go nonadaptive", "4 x drone", "extractor", "go gas until 100", "spawning pool", "2 x drone", "lair", "drone", "go gas until 625", "hydralisk den", "drone", "lurker aspect", "overlord", "3 x hydralisk", "2 x zergling", "3 x lurker", "overlord"] },

9 pool lurker rush

Yesterday’s original:

"9Pool8GasLurker" : { "Race" : "Zerg", "OpeningBuildOrder" : ["go nonadaptive", "5 x drone", "spawning pool", "extractor", "2 x drone", "overlord", "lair", "2 x drone", "hydralisk den", "lurker aspect", "drone", "3 x hydralisk", "3 x lurker"] }

This I see as a normal lurker rush, no longer a “dawn” rush where the lurkers burrow as the sun rises (thus keeping the planet in balance). It’s not as tight, and there are many ways to turn it into a competitive build. I didn’t make extra versions this time, but picked one. This version ends with 10 drones and makes 4 pairs of zerglings at different times. I’m pretty sure it could be rearranged to get 4 lurkers instead of 3.

"9Pool8GasLurker" : { "Race" : "Zerg", "OpeningBuildOrder" : ["go nonadaptive", "5 x drone", "spawning pool", "extractor", "2 x drone", "overlord", "lair", "2 x drone", "zergling", "hydralisk den", "zergling", "lurker aspect", "3 x hydralisk", "2 x zergling", "3 x lurker"] },

Here is the path I followed to discover (what I conclude is) the fastest possible lurker rush. Whew, that was hard work. The build can afford 2 lurkers. I’ve never seen anything similar before.

All the timings are of course with Steamhammer’s execution, which is reasonably good but hardly perfect. For example, mineral locking is not ideal, and drones can make unnecessary movements when building.

I found a simple improvement to yesterday’s supposedly optimal build, by heeding my own lesson: It makes sense to delay 1 drone now to get 2 drones sooner, provided you can use the income of the 2 drones in time for the next step. It does not make sense to delay a drone for no benefit! Simply move the delayed drone before the overlord for a faster lair and faster lurkers. The lair timing is then gas-limited, and making the overlord immediately before the lair does not delay it.

"9Pool8GasLurker" : { "Race" : "Zerg", "OpeningBuildOrder" : ["go nonadaptive", "5 x drone", "spawning pool", "extractor", "2 x drone", "overlord", "lair", "2 x drone", "hydralisk den", "lurker aspect", "drone", "3 x hydralisk", "3 x lurker"] }

I got a lair timing of frame 2972 and a lurker timing of 6286. Ideally, lair start at 2972 + lair build time 1500 + lurker aspect research time 1800 should give a lurker timing of 6272, which is 14 frames earlier. Watching the game by eye, lurker aspect has its prerequisites on time and seems to start instantly when the lair finishes, and the lurker morph seems to start instantly when lurker research finishes. There could be a few frames of unnecessary Steamhammer execution delay, but I suspect that the bulk of the 14 frame slippage is Brood War latency stuff that is not accounted for in the build time. Maybe some other day I will instrument it and track down those 14 frames.

Now that the lair is gas limited, can we speed it up by getting gas earlier? 9 gas 9 pool gave me lair timing 3139, limited by the spawning pool. For a faster spawning pool, drop the drone in front of the pool for 9 gas 8 pool, and collect just enough gas at each step. That got me a lair timing of 3022, faster but still limited by the spawning pool—and not fast enough. Since the lair is slower, there is no point in timing out what happens after.

"9Gas9PoolLurker" : { "Race" : "Zerg", "OpeningBuildOrder" : ["go nonadaptive", "5 x drone", "extractor", "drone", "spawning pool", "drone", "overlord", "lair", "hydralisk den", "lurker aspect", "hydralisk", "lurker"] },

"9Gas8PoolLurker" : { "Race" : "Zerg", "OpeningBuildOrder" : ["go nonadaptive", "5 x drone", "extractor", "go gas until 100", "spawning pool", "2 x drone", "overlord", "lair", "go gas until 375", "hydralisk den", "lurker aspect", "hydralisk", "lurker"] },

The next step is to reduce the number of drones. Will that speed up the lair, or slow it down for lack of resources? I optimized this build through several steps which I won’t show. Notice that the second overlord is delayed until after lurker research starts! The overlord costs too much; otherwise lurkers would be delayed. Lair timing: 2868. Lurker timing: 6182. Success! Again there are 14 frames of slippage.

"8Gas7PoolLurker" : { "Race" : "Zerg", "OpeningBuildOrder" : ["go nonadaptive", "4 x drone", "extractor", "go gas until 100", "spawning pool", "2 x drone", "lair", "drone", "go gas until 500", "hydralisk den", "drone", "lurker aspect", "overlord", "2 x hydralisk", "2 x drone", "2 x lurker"] },

Can we get away with 7 drones? When does the drone count go too low to support the tech? 7 gas 6 pool got the lair slightly faster than 8 gas 7 pool above, but it was limited by the pool timing, so I went back to pool before gas. My first try with 7 pool 6 gas got the lair substantially faster at 2649, but there were not enough resources to start lurker aspect on time, and lurkers were delayed to 6465. I tried different ways to get extra drones in. The feasibility is narrow: It breaks the build to insert 1 more drone anywhere... or to shift any drone earlier... or to collect more gas than specified. In the end, I was able to get lurkers out faster overall, despite delays both in the lair and in starting lurker aspect. Lair timing: 2718. Lurker timing: 6080. This time there are 62 frames of slippage, most of which are due to a delay in starting lurker aspect because minerals are short.

"7Pool6GasLurker" : { "Race" : "Zerg", "OpeningBuildOrder" : ["go nonadaptive", "3 x drone", "spawning pool", "extractor", "go gas until 350", "2 x drone", "lair", "drone", "hydralisk den", "lurker aspect", "2 x drone", "go gas until 250", "overlord", "2 x hydralisk", "2 x lurker"] },

I find it clear that 6 pool or 6 gas will not work. The delays due to lack of resources will be longer than the gain from starting sooner. I didn’t bother to try.

The final build must be close to optimal. But it’s possible that there is a faster lurker build. I tried a lot of ideas, but I did not examine every detail with mathematical thoroughness; it is too big a job for the time I was willing to spend on it. At some point, maybe I will do as Dave Churchill did in his thesis: Search programmatically through the tree of builds to find builds which are optimal for different purposes. The giant search for optimal builds is a perfect computer job.

Next: Competitive versions of some of these builds.

I decided to accept McRave’s challenge to find the fastest possible lurker rush, ignoring all else. The goal is to find a build order that morphs at least 1 lurker at the lowest possible frame count, and attempt to show that it truly is the fastest possible. I can’t do the whole analysis in a day, though, and still get it right. I can get a faster lair by reducing the drone count, but with a low drone count I can no longer assume that there will be enough resources to get lurkers without waiting on mining. I have to test full build orders, and that means carefully tweaking each build to add exactly the necessary drones at the right places, get the overlord timing perfect, and so on.

As an appetizer, here is my baseline build, based on the 9Pool8GasLair fast lair build from the analysis of McRaveZ’s buggy opening. I think it is the fastest possible lair with 9 drones. In my test run, the 3 lurkers morphed at frame 6355—that’s the timing to beat.

"9Pool8GasLurker" : { "Race" : "Zerg", "OpeningBuildOrder" : ["go nonadaptive", "5 x drone", "spawning pool", "extractor", "drone", "overlord", "drone", "lair", "2 x drone", "hydralisk den", "lurker aspect", "drone", "3 x hydralisk", "3 x lurker"] }

There are no zerglings; that’s not part of the goal. The build includes 3 drones after the lair which are not on the critical path to get lurkers, but they fit into gaps and use available resources, so they add no delay (not even to get an extra overlord). "go nonadaptive" prevents Steamhammer from altering its build order in response to the opponent’s static defense, so I can be sure that I am testing the intended build and not another one. I turned off other adaptations elsewhere.

As a bonus, once I think I’ve found the fastest build, I’ll make a competitive version of it which produces as many zerglings as possible without delaying the lurkers. A rush build like this is all-in, so in a real game you want zerglings instead of drones as much as possible (and you may want to pull workers, though I’m not sure about pulling drones for a lurker attack). If the build looks good, I’ll configure it to be played in competition.

The standard build order for 12 hatchery is this. The initial overlord provides 8 supply and the hatchery provides 1 supply, for a total of 9 until the second overlord spawns.

- 4 drones (8 total)
- overlord @ 8
- 1 drone (9 total, supply limit)
- ... wait for overlord to finish
- 3 more drones (12 total)
- hatchery

Many zerg bots follow the standard build. I’m making this post because some zerg bots follow a different build:

- 5 drones (9 total, supply limit)
- overlord @ 9
- ... wait for overlord to finish
- 3 more drones (12 total)
- hatchery

It may seem to make sense. Don’t you mine more minerals if you make the 9th drone as early as possible? But in fact the standard build is a tiny bit better. It’s standard for good reason.

Here are the timings. “12 drones” is the time when the 12th drone starts. “Hatchery” is when the hatchery starts.

build	12 drones frame	hatchery frame
overlord on 8	2079	2401
overlord on 9	2079	2422

In these runs, the 12th drone was started on exactly the same frame for both builds. The 12th drone is larva limited for both builds; after the overlord finishes, you have only 2 larvas and have to wait for the next one to get the last of the additional 3 drones. There is a bit of randomness in larva timing, so the exact frame can vary. Furthermore, the 9th drone really does mine more minerals before then; with the overlord on 9, zerg has slightly more minerals when the 12th drone starts. Nevertheless, the hatchery starts a little sooner if you make the overlord on 8! Why is that?

You don’t care about the mineral count when the 12th drone starts. You care about how soon you can get to 300 minerals for the hatchery. If you make the 9th drone before the overlord, 1 drone mines a little longer, and 2 drones are delayed waiting for the overlord to provide supply. If you make the 9th drone after the overlord, those 2 drones start mining sooner. The extra mining time of the 2 drones after the overlord (in the standard build) outweighs the mining time of 1 earlier drone before the overlord (in the other build).

The difference is very small. At bot level of play, it probably has almost no effect on who wins. If you play the “wrong” build, then you surely have more important things to fix first! Nevertheless, the standard build is superior, and it should be easy to switch to it.

Similar timing calculations are behind the standard terran supply depot @ 9 and the standard protoss pylon @ 8. The general topic is: What is the most efficient time to order supply? Too early and you tie up minerals that you could have spent better; too late and the supply block holds you back. In general, there is an optimal answer (at least there is provided you can predict your combat losses), and it depends on what you intend to make next.

This post is about timing openings to see if they are good for their intended purpose. I started with one opening, assumed I could guess its purpose, and timed a range of related openings with the same purpose to see which one is best.

McRaveZ has been playing an outlandish opening in ZvZ games, such as McRaveZ-Killerbot by Marian Devecka. The opening is 5 pool... but no fast zerglings, a lair is next. The opening is so strange that it looks like a bug, but McRave has kept playing it after updates, so maybe not.

- 5 pool
- drones to 9
- extractor
- overlord
- drone (back to 9 drones)
- ... wait for the overlord to finish
- drone
- zerglings until there is enough gas for the lair (1 or 2 pairs)
- lair
- zerglings until the lair completes
- spire

The aim logically must be fast mutalisks with little regard for defense against enemy zerglings. Since the opponent often attacks with zerglings, McRaveZ loses a lot of ZvZ games. The spire does start somewhat early though, at about 3:40. Is there a chance that the opening could make sense in some situations? That’s the starting point for my analysis.

Let’s suppose that the goal is to rush mutalisks. A spire takes a long time to finish, and we have 9 drones, so if we choose we can save up enough resources and larvas to start 3 mutalisks when the spire finishes. Similarly, a lair takes a long time to finish, so while it is constructing we can save up enough for the spire. So measuring when the lair starts tells us how fast we can rush mutalisks with a given opening. We don’t have to measure the rest, it follows mathematically.

A lair has 3 prerequisites: 150 minerals, 100 gas, and a completed spawning pool. Intuitively, the reason to suspect that the 5 pool lair build is inefficient is that it gets the spawning pool long before the minerals and gas. Saving up for the spawning pool causes a gap in drone production that delays income, so (other things being equal) you prefer to get the spawning pool as late as possible without delaying the end goal. The rule of thumb is, in a rush build you prefer all the prerequisites on each step of the critical path for your rush to finish at close to the same time. For example, in a zergling rush with an early pool, you time it so that when the spawning pool finishes, you have 150 minerals and 3 larvas so you can make zerglings immediately.

I timed the lair start for a range of related builds. Each (x+1)PoolLair build gets 1 more drone before the spawning pool and 1 less after, compared to the xPoolLair before it. Otherwise the xPoolLair builds are identical, and they all have 9 drones when the lair starts. 9Pool8GasLair moves the drone before the extractor to after it, and moves the zerglings before the lair to after it to avoid delaying the lair (with a drone made later, the minerals are slightly lower). 9GasLair gets an extractor on 9 drones, then a drone, then the spawning pool. The optimized version gets just enough gas, then stops gas collection. ZvZ_Overgas9Pool is a standard Steamhammer build that wins a lot of games, which gets overlord, then gas, then spawning pool, and includes a good number of zerglings while still rushing for mutalisks. CAVEAT These numbers are based on only 1 run each! Different runs, even on the same map with the same starting position, will come out slightly different.

build	lair frame	minerals	gas	limiting resource
5PoolLair	3618	188	104	gas
6PoolLair	3386	180	104
7PoolLair	3250	180	104
8PoolLair	3093	172	104
9PoolLair	3049	188	104
9Pool8GasLair	2937	166	104	minerals and gas
9GasLair	3307	156	280	minerals
9GasLair (optimized)	3144	196	104	pool
ZvZ_Overgas9Pool	3390	218	248	pool

9Pool8GasLair gets 150 minerals and 100 gas for the lair at virtually the same time; the pool is already finished by then. I don’t see how to get a faster lair after 9 drones. The purpose of the gas-first measurements is to show how the gas-minerals tradeoff continues as you get earlier gas. I’m not sure about this, but it’s possible that fast gas could be worth it if you intend a scourge-ling unit mix, seeking initial air control with scourge and using the minerals you save (compared to mutalisks) to add hatcheries.

I timed 5PoolLair against 9Pool8GasLair in full games in Steamhammer. They both start the spire at the same supply, but 9Pool8GasLair reaches that point over 600 frames earlier, exactly as forecast from the lair timings. What do you know, math works! The tremendous advantage in zergling and mutalisk timing can put heavier pressure on the opponent.

The purpose of the ZvZ_Overgas9Pool entry is to remind us all, me included, that rushing for one unit type is an extreme game plan. An extreme plan is not necessarily bad, but a balanced mix of units with a productive economy is safer and more flexible. Steamhammer plays its overgas 9 pool more often than it plays its 5 pool or its 9 pool spire openings, and that is because it wins more.

Theoretically, the assumption that the goal is to rush mutalisks could be wrong. It can make sense to prepare a tech which you don’t intend to use right away: It gives you more options. Getting an early spawning pool means you can make emergency zerglings if you are unexpectedly rushed. However, getting a spawning pool at 9 drones is early enough to stop a zergling rush. The only reason I can think of to get a spawning pool on 5 and then go to 9 drones is to stop a worker rush, if your worker defense is poor (which it shouldn’t be). You won’t scout the enemy in time to notice a vulnerability to the fast pool and change plans.

Bottom line: McRaveZ’s opening looks bad. I do not see a purpose that it is well optimized for. I still suspect that it is a bug, not an intended opening.

One of my goals for Steamhammer, you may remember, is to time its own openings. I want it to keep data about its openings, and reason during the game about which one is good for what purpose. Ideally, it should be able to figure out when one opening dominates another, in the same way that 9Pool8GasLair dominates 5PoolLair: It is better in some ways, and worse in none. An opening which is dominated need never be played or explored further.

I promised a post about how Steamhammer can eventually optimize its own openings. In fact, I intend for it to be able to invent its own openings from scratch, as well as adjust openings (whether hand written or automatically generated) based on calculations and experience. Here’s an outline of my ideas.

My next big project is strategy adaptation. A large part of it will be implementing abstract strategies and the ability to turn them into concrete lines of play. For example, “3 hatch muta” is an abstract strategy at a high level of abstraction, and Steamhammer’s opening lines ZvT_3HatchMuta and ZvP_3HatchMuta are concrete implementations of the strategy, optimized for different matchups. Once abstract strategies exist, Steamhammer will be able to experiment with different strategies by simply filling in its abstract strategy data structure—with random values if no other way—and playing out the game, turning the abstract strategy into a build order. I suppose I’ll do this at home rather than during tournaments! There are more focused ways to find new abstract strategies: Steal them from opponents, extract them from replays, systematically explore the lattice of strategies (since they are partially ordered) extending the promising avenues, note enemy timings and units and do a directed search for strategies that hit the timings and counter the units. The space of abstract strategies is exponentially easier to search than the space of build orders; that is the advantage of abstraction.

Another part of the strategy adaptation project is to collect data on opening lines—aka concrete build orders—with their resource use and timings and unit counts and stuff. If we play out a strategy and get a build order, we record the build order as an opening, and if we play the opening we measure its data in real games. With the measured data, we can compare openings to judge which one is better in a given situation: Does it hit the timings, does it counter the units, does it grow a strong enough economy, does it have adequate defenses?

One way to do the comparison, which both I and others have suggested, is to set up the armies of both sides and run the combat simulator. That compares army strengths; if you also know economy size and tech level, you can do a more comprehensive comparison.

Once you can compare 2 opening lines for goodness in a given scenario, you can optimize an opening line for the scenario without changing its abstract strategy. I think I’ll try goal-directed modifications to the opening line—the enemy attacked early here, we need units in time; or the enemy had too much stuff later, we need more drones to keep up. Modifications that pass the comparison check can be tried in games.

Many new skills are needed. My plans are more than my accomplishments, and my accomplishments turn out different from their original plans. Even so, I expect to get a system like this working eventually. If you try a new idea on Steamhammer and it has no counter, it will invent its own counter and polish it by experience and reasoning. Then I’ll have gotten somewhere.