Starcraft AI blog

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.

For anyone who hasn’t noticed yet, the SSCAIT stream is back at the changed address https://www.twitch.tv/sscaitournament.

I’m in the process of switching Steamhammer to BWAPI 4.4.0. There are more steps to it than I expected. It involves switching from ancient Visual Studio 2013 to modestly out of date VS 2017. I hated dealing with Microsoft enough to make the upgrade, but it wasn’t actually difficult. The compiler is more strict about language conformance, and I needed a little research to figure out the minor tweaks. There are still a bunch of warnings that I’ll look at later; at first glance they seem insignificant. Changes to keep up with updates to BWAPI’s API were trivial; I had been ready for more. Up to here, everything was planned for.

I did not realize that BWAPI no longer installs BWAPI.lib but expects you to compile it yourself as a project dependency. BWAPI no longer includes a lib directory at all. See the commit. The change is to work around this issue of link errors, which looks like Microsoft’s fault. The closest thing to a mention in the change log (under BWAPI 4.3.0) is below; you have to read the closed issues to find out the problem and solution. (Steamhammer’s documentation is also behind reality....)

Added [Release|Debug]_NoCopy configurations for BWAPILib and other projects which could be used outside of BWAPI itself (bots, libraries etc). This allows for automatic rebuild of these files when BWAPI or your compiler updates #786

I wonder—could the change cause headaches for CIG and AIIDE as they compile entries? I can imagine issues with project dependencies. They certainly need to know about it, at least.

I have more to do. On the cost side, I’ll need time to run test games to see if Steamhammer has hatched any new bugs. On the benefit side, I’m looking forward to removing Steamhammer’s workarounds for the BWAPI bugs in version 4.1.2. They are holding back its play (though there are bigger weaknesses).

I lost a lot of time dealing with a Pile of Irritating Life Events (PILE for short), but theoretically I should getting back to norbal (search for “everything is back to norbal”). We’ll see if theory holds. Expect a status update on Steamhammer before too long.

Insanitybot has been updated, and its description says “Nukes CAN be built and MAY be launched.” I thought that might be the plan. It looks like insanitybot-WillBot (random terran) on BASIL was its first nuke game, and the only one so far on SSCAIT or BASIL as I write. Unfortunately the replay desyncs toward the end, but there is a cataclysmic nuke launched at about 18:35. (BASIL, by the way, adds little icons on its recent games page to point out certain interesting types of games. That makes it easy to find nuke games.)

The ghost’s cloaking energy looks low, but it was enough. In some cases WillBot scanned for cloaked ghosts and stopped nukes, but apparently this ghost stayed outside of range thanks to good nuke targeting. Don’t miss the before and after supply numbers.

Insanitybot also has a bug and builds multiple science facilities with covert ops. The bug may be in BOSS; that’s where I would look first. In Steamhammer, I intend to get rid of BOSS this year, so I’m not expecting to fix any BOSS bugs.

The first upload of RedRum was identical in play to Steamhammer 2.3 playing terran. Since then it has been updated with changes, so I took a second look. Curiously, though the bot’s idea of its own name has been updated from SteamRoll to RedRum, it still gives its version as 0.1.

The RedRum version uploaded on 4 May had complete map information mistakenly turned on. SSCAIT software did not notice, but stream watchers noticed quickly because a debug option to draw enemy unit locations was turned on. Nobody who was actively trying to cheat would turn on both options at the same time, so it truly was a mistake. Still, it makes me wonder whether any other SSCAIT bots have complete map information turned on, whatever the reason. A corrected version of RedRum was uploaded the next day, on 5 May (the complete map information setting was the only difference between the uploads). Has SSCAIT fixed their side of the error yet? [Fixed on 11 May.] The tournament manager can and should flag that setting.

Compared to Steamhammer, RedRum makes no important changes to the configuration file—it sets bot info like the name and it sets different debug options. The opening book is unchanged. RedRum’s DLL file is microscopically shorter than Steamhammer’s, 512 bytes or about 0.05%. I speculate that it may delete a small amount of code that terran does not need (there is plenty more). It’s unlikely that it deleted a lot of code and also added a lot; we’d probably see a bigger size difference.

I played a few test games to see if I could spot changes. I set Steamhammer and RedRum to play identical terran openings, to help small differences stand out. I noticed that RedRum always claims that its opening is “enemy specific”, though I set it myself and it was not. I thought there might be a difference in the SCV scout’s behavior when it reached the enemy base. And attack/retreat decisions seemed a little sharper; maybe that has been improved. Other than that I could not spot any difference. But then, I know from experience that play differences are quite hard to find by eye. I could have misinterpreted game events as skill differences, and I could easily have overlooked other differences in play.

Still, RedRum remains very similar to Steamhammer terran. In the first test game, the initial vultures met in the center of the map and fired on each other simultaneously, and the build orders remained identical until deep into the game. That’s natural, of course; it takes time to make substantial changes.

It’s good that we’re getting at least some new bots. I have the idea that Ayran Olckers, author of RedRum, is still at the exploring stage, trying to get a firm grip on things. Bigger changes may be coming—the 0.1 version number at least says so.

Events in the putative real world are kicking my wimpy butt. It took me until now to store up enough energy to look at the interesting new terran Dragon, said to be a project of Tscmoo the person (Vegard Mella) of the CherryPi team. Its comment says it is a TorchCraft bot like CherryPi.

Dragon’s page on SSCAIT, by the way, shows a flaw in SSCAIT’s Liquipedia linking: There already existed a human player named DragOn, and the page displays information about the person DragOn instead of the bot Dragon. Dragon the bot doesn’t seem to have a Liquipedia page yet. (There may be a connection, though; the games of Dragon the bot often drag on.)

Peering into Dragon’s binary, I can verify that it is a TorchCraft bot. It is packaged quite differently than CherryPi was in its AIIDE appearances: CherryPi appeared as a pile of startup scripts and learning data files and stuff, while Dragon is a single DLL file. The simpler packaging seems easier to deploy, though I imagine that Dragon needs a build process to pack the code and the learning data and whatever else into the DLL file. I speculate that Dragon has a development build to make coding and machine learning easy, and a production build that puts together the DLL. Perhaps CherryPi now does too, though in a quick look at the github repo I didn’t spot any obvious mention.

The idea behind a TorchCraft bot is, of course, to use machine learning for some decisions and code for others. (It’s the same general plan I am following with Steamhammer, except that they have a team and are way ahead of me on both sides.) Since Dragon running on SSCAIT has (last I heard) no GPU available to it, it can’t run very large neural networks. But it should be able to run networks large enough to be quite smart in particular aspects.

Dragon’s BASIL stats are curious. As I write, Dragon is ranked #19 with elo 2257, good but not great. Its win rates by matchup are inconsistent: 55% for TvP, 68% for TvZ, and 89% for TvT—the range is from a bit above average to outstanding. I think most other bots with wide ranges in win rates by matchup are either random, or else the wide range is “achieved” by doing poorly in one matchup (both are true for Randomhammer). Also the win rates by map vary from 50% on Andromeda to 100% on Jade (though with only 7 Jade games). Bots nearby in the rankings are mostly 50-60% on their worst map and 70-80% on their best map, a much narrower range.

Watching games, I see that Dragon has mostly good combat skills, and especially superb wraith micro. That seems natural for a bot related to CherryPi. It tends to pick a good unit mix, and it likes wraiths to make use of its wraith skills. I expect that unit mix decisions are learned. Its building placement skills are above average, but also like CherryPi, not fully convincing. It has good map awareness, but its tactical decisions are nevertheless often questionable. I imagine that tactics are decided by hand-written code rather than by learning. One peculiarity I noticed is that it likes to build bunkers more than it likes to load marines into them; it often loses empty bunkers.

Dragon defeats SAIDA most games, leaning on its wraith micro and coordinating its wraiths and tanks well. It also loses to lower-ranked #39 NLPRBot around half the time. Perhaps Dragon will improve due to opening learning, but it seems that its inconsistent skills extend down to the individual opponent level.

What is the cause of Dragon’s inconsistent skill? A natural guess is that its skills reflect its training. If its TvT training was against SAIDA alone, or perhaps SAIDA and a small number of other terrans, then it makes sense that it could learn to defeat SAIDA. I think that winning against SAIDA should generalize to many other terran opponents, since SAIDA makes few big mistakes, and combat errors that it does make will be hard for lesser terran bots to avoid. If Dragon was trained against weaker opponents in the other matchups, of course its skills should be less. If it’s a personal project rather than a team effort, maybe it did not get enough total training.

Next: RedRum.

In one of the Undermind podcasts there came up the recent Rich Sutton essay The Bitter Lesson. The basic point of the essay is true: “general methods that leverage computation are ultimately the most effective.” (That is why, though I don’t post about it, behind the scenes I am implementing a machine learning method for Steamhammer.) Nevertheless, I have a complaint about what he says.

Rich Sutton (home page) is a big name in machine learning, and his opinions are worth attention. He is co-author of the major textbook Reinforcement Learning: An Introduction, which I recommend. On his home page you can find more short essays on AI topics; I particularly like Verification, The Key to AI. He’s a smart guy who thinks things through carefully.

Reading The Bitter Lesson, the first paragraph makes perfect sense to me. I might quibble with minor details, but I have no substantial objection; I agree with it, it’s correct or nearly so. Then he goes into examples, and there I feel that he misrepresents history in a cartoonish way. That’s not how the bitter lesson was or is learned.

In the computer chess example, “this was looked upon with dismay by the majority of computer-chess researchers” is false. The Chess 4.x series of programs by Slate and Atkin showed in the 1970s that massive search was more successful than any other method tried. Long before Deep Blue defeated Kasparov, work on knowledge-based approaches was a minor activity; I have a pile of International Computer Chess Association journals to prove it.

The example of computer go is also presented misleadingly. I subscribe to the computer go mailing list and have listened in on the conversations since before the deep learning revolution in computer go. In the old days, people were writing complex programs with too many varieties of hand-coded knowledge, not because they were sure it was the right way—I think everyone agreed that it was not very successful—but because nobody had found a better one. There were experiments with neural networks that intimated that a breakthrough might be possible, but until AlphaGo, the breakthrough was not achieved. The big lesson was not “use a general method of massive learning,” it was “here is the recipe for massive learning.” Finding the recipe was extremely difficult; people had been working on it for many years of slow progress, and victory did not arrive until there were technical breakthroughs in deep learning and DeepMind brought its great resources to bear. Knowing that you should use massive search and/or massive learning is only a tiny part of the battle; figuring out how to use them is the real fight.

That is exactly where we stand in Brood War. We know, and most agree, that search methods (as used in combat simulation) and learning methods (like deep learning) have the potential to be successful. And we have intimations of a breakthrough, bots that have achieved some of that success, like LastOrder with its macro model and CherryPi in TorchCraft with its build order switcher. But we don’t know the full recipe yet, and finding it is difficult work.

I thought that Sonko’s first SSCAIT cast yesterday was not particularly accomplished. Nepeta doesn’t always understand the flow of the game and sometimes misses events that are visible on the minimap, but with years of weekly practice he has developed a smooth presentation. Sonko chose good games, but is not all the way there yet.

Casting seems to me a difficult skill; I wouldn’t try it without rehearsing, which is time-consuming. The caster benefits from strong knowledge of game play, the maps, and the players, and needs to follow the events of the game in real time while both showing them on the screen in a way that viewers can understand and fluidly offering useful and interesting commentary. That’s a lot of different subskills to coordinate at the same time. There is a reason that pro casters work in teams, with a game observer plus two or more commentators who always have something to say and can report background information or banter with each other if the game situation is not interesting at the moment. If you watch closely, you can see that top game observers understand the drama of the game, and can deliberately ignore important developments until suddenly revealing them at the most exciting moment. That requires simultaneously interpreting the actions of the players and foreseeing the reactions of the viewers; it is nothing simple.

I’m sure casting is like other difficult skills: You can’t help but improve with attentive practice.

An enemy lurker or dark templar is in your base, and you have absolutely no form of detection nearby. Can you defeat it anyway? In many cases, yes.

An enemy unit can be in sight range but undetected if it is burrowed—a spider mine or a burrowed zerg unit—or if it is cloaked—a wraith, ghost, dark templar, observer, or a unit under an arbiter’s cloaking field. I’ve written before about countering spider mines, so I’ll skip that.

burrow versus cloak

When a cloaked unit is in sight, a bot knows where it is. Without detection the cloaked unit cannot be targeted, but BWAPI gives its type and position.

A burrowed unit does not give itself away. If the bot did not see the enemy burrow, and did not detect it since it burrowed, then BWAPI does not reveal that it is there. Exception: A lurker can give away its position when it attacks. The lurker spines are a bullet, in BWAPI parlance. However, if you try to build on top of a burrowed unit, construction will fail. Many bots use that fact to infer that a spider mine is blocking an expansion position, but the principle is general. In theory, you could locate burrowed zerglings by starting buildings in different positions. It’s rare, but I have seen a game where hold lurkers waiting in ambush in an expansion were discovered by trying to build a turret before any mining SCVs arrived.

spider mines

Spider mines will attack cloaked enemies. They are popular for fending off dark templar.

splash damage

An undetected unit can’t be targeted, but it can be hit by splash damage. Psionic storm is the simplest way; burrowed and cloaked units are affected like any other. Nuke may be overkill, but is effective.

An example: For protoss, the most common way to deal with a single undetected lurker is to park a friendly zealot on top of the lurker and attack the zealot with an archon. The zealot will remain stoic as it takes full damage, and the lurker will take splash damage. You may need 2 zealots to finish off the lurker. Skynet by Andrew Smith has this skill, and I wrote it up in 2016.

Any unit or spell that does splash damage will work—well, it has to do ground splash for ground enemies or air splash for air enemies (archons do both ground and air splash). Besides archons, popular choices are reavers, lurkers, and sieged tanks. Corsairs and valkyries are good for air splash. Firebats and infested terrans can theoretically work, though I’ve never seen it done. You can also do the eraser: Irradiate a unit (preferably an air unit) and keep it next to a dark templar or ghost—but then, if you have a science vessel, you have a detector, so the eraser is for when you have no other forces around. Spider mines do not attack friendlies and are the only splash damage unit that cannot be used, but they do attack enemies so you don’t need to. Mutalisk bounce does not count as splash; glaive wurms do not bounce to undetected enemies. Also devourer acid spores do not splash onto undetected air units—they will reveal a cloaked unit that they are attached to, but they can only attach to a unit that is detected.

Also, any target that will splash onto the undetected enemy is good—anything directly next to the undetected enemy. Sometimes you can target a building or an enemy unit.

revealing cloaked units

The queen’s ensnare and the defiler’s plague are area effect spells that work on cloaked units, though not on burrowed units. Besides affecting cloaked units, the green or red goo reveals cloaked units so that they can be targeted.

EMP

Wraiths and ghosts need energy to cloak. Hit them with EMP, and they are forced to become visible. Of course, the science vessel can also directly detect them. EMP might be worth it if the vessel is at risk (perhaps from the wraiths, or perhaps from ghost lockdown), or if one EMP can hit a group of enemies which will then have to build up energy to cloak again.

drilling cloaked units

Sometimes you only need to gain a little time before you can deal with the cloaked enemy. You can delay the enemy if you can force one of your units to overlap with it; both units will move randomly, unable to act, until they separate. Zerg can do this by unburrowing from under the unit, or by turning a larva into an egg when the unit is very close to the larva. All races can do it with a worker drill: Send workers to a mineral patch so that their path will take them through the position of the enemy—mineral walk through the enemy—then stop or attack when they are overlapping.

Any other techniques? I won’t be surprised if I forgot a few.

Insanitybot was also updated today. It is another terran fork of Steamhammer, and it is not particularly strong but it has been growing more interesting with every update. It has some play improvements over Steamhammer, but it appears that the author has put more effort into adding terran skills like wraith cloak, spider mines, irradiate, and more. This version also makes ghosts and cloaks them; I’m guessing that nukes may be coming down the pike.

This BASIL game against zerg CUNYbot by Bryan Weber shows off its ability to use optical flare. Optical flare research finishes a little after 11:00 into the game, and the first optical flare that I saw was about a minute later (because the cowardly medics had retreated from the front). Starting at 16:25, more overlords are blinded. CUNYbot does not seem to notice, but maneuvers the blinded overlords as usual—no doubt many other bots would also fail to react. Steamhammer doesn’t notice blind units either; it has never mattered.

Optical flare is similar to parasite in that it is more fun than useful. There are occasional situations where it can be valuable, but usually something else is more important. But that’s in human play; bots may be different. If nukes are coming, as I guessed, then maybe insanitybot will cloak the ghost, blind every detector that shows itself, and nuke in safety.

Few bots have the ability to destroy an undetected unit. Maybe I’ll write about that soon.