Starcraft AI blog

Oh look, SAIDA is updated! And the update is... that it is disabled on SSCAIT. It has an update on BASIL too, but it is still active there.

A confusing development. Will the disabling propagate to BASIL later? Will SAIDA now play on BASIL exclusively? Is it so they can keep their binary to themselves while they prepare for tournaments? I can only speculate. I found no new information on the github page. There is a March issue Expect the next SAIDA update to bring something more interesting, though I imagine it’s just some random user expressing a wish.

I'm a random user with a wish, too. I hope we get a new and improved SAIDA version in AIIDE. If so, with their resources and skill they may overwhelm all opponents again. So far, the updated version on BASIL does have a loss against Krasi0, but wins against 12 other opponents.

The latest insanitybot update is able to carry out drops. The author seems to be systematically adding All The Features. Here’s a typical drop game, insanitybot-WillyT. Insanitybot plays a battlecruiser rush (compare PurpleSpirit’s battlecruiser rush), and follows up with a vulture drop.

I think insanitybot performs a drop in most of its games which go over 10 minutes. There are plenty more examples.

The drop feature is clearly leaning on the limited support for drop in insanitybot’s parent Steamhammer. The drop is a usually vulture drop, just like Steamhammer’s terran drop, and the dropship follows the same path around the edge of the map and unloads in the same location. Notable differences from Steamhammer’s drop skills are: 1. If there are no vultures, the dropship will carry marines instead. Are there other possibilities? 2. The drop is a middle game behavior, rather than being coded into the opening. 3. Insanitybot can lay mines, so spider mines may end up in the enemy base. I notice that the drop location near the mineral line is not ideal for laying mines, though. 4. Insanitybot attempts to set up for another drop. The dropship comes home after the drop, and sometimes picks up new units. If the dropship dies, another is eventually made. I have yet to see the second drop land, though.

The game insanitybot-Gaoyuan Chen is a highly effective marine drop. The dropship returns home and starts picking up fresh marines, but the marines are more interested in the fight in front of them than in the distant enemy base. The dropship is finally shot down before it can make the second drop.

Drop in the general case is of course a very complex set of skills. There are cliff drops (Icebot and SAIDA can drop tanks on a cliff), mixed unit drops (marines and medics are good), not filling the transport (to reduce the loss in case it is shot down, or to speed up the drop timing; it is normal for protoss to load only 2 dark templar into a shuttle, for example), multi-ship killing drops versus harassment drops, good play after dropping (lay mines in front of the enemy gateways, for example), changing the drop point based on new information (the dropship may fly over an unscouted enemy base), scanning the drop zone to make final plans (“ack, turn back, it’s well defended!” or “I only see zerglings, let’s go behind the minerals so we’re hard to reach”), and so on. Then there is coordinating the drop with other actions. In pro games, it’s common to escort the dropship across the map, load up near the destination, and carry the troops only a short distance. And there are tricks to draw forces away from the drop zone, or to use the drop to draw forces away from the front. It’s far more than any bot can do, for now. Another way to say it is, there are plenty of ways available to surprise your opponents in the next tournament.

What’s next for insanitybot? I think there are still some terran skills to add, but not that many!

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.