Starcraft AI blog

Randomhammer crashed—as zerg, no less. It got knocked back to 1 base with a few drones, and started to recover as normal, but after making a couple units... kaboom. Zerg has been recovering reliably from these upsets for a long time now, so it’s a surprise. I’m trying to triangulate the source of the problem from not-quite-adequate information.

The upcoming version 1.4.2 is closing in on being ready. The opponent model changes are finished, except for small details. The remaining work is a little bit of smoothing and a bunch of testing (and probably fixing). In between an untraced crash and a new and fairly complex addition to the opponent model, there’s no guessing how long debugging will take.

Ack, Steamhammer has a typo in its UCB formula! A parenthesis is misplaced. What a blunder! In UCB1_bound(), change this inexcusable mistake:

	return sqrt(2.0 * log(double(total)/tries));

to this:

	return sqrt(2.0 * log(total) / tries);

The typecast has no formal effect in C++11 and later, and made it harder to see the error.

The current Steamhammer 1.4.1 uses UCB only for deciding whether to steal gas, when AutoGasSteal is turned on. I had been wondering why it chose to steal gas so often against so many opponents. Was the gas steal really that effective? When I looked again at the code, I soon spotted the mistake.

The behavior is approximately right when the number of games is small. That’s how it passed my end-to-end tests. As the number of games goes up, it gets more and more wrong. It’s impossible to be too careful in testing. :-/

The upcoming version will use UCB for opening selection—not in the most direct way, like most bots, but with a twist to cope with the large number of openings, too many to explore. Good thing I caught the bug in time.

I wrote up Steamhammer’s protoss building problem in March as Steamhammer’s time limit problem with protoss. Since then, I borrowed the smart Locutus idea of limiting the number of gateways to 10, a workaround that nearly eliminated the problem—though it doesn’t solve it. It worked so well that I decided to remove a different workaround, a rule in building placement that many protoss buildings are allowed to touch vertically, blocking horizontal movement. That rule sometimes caused units to get trapped in between buildings and the edge of the map, so it was now causing more harm than good.

Then, in a test game of protoss versus Killerbot by Marian Devecka, the building problem came up again. Steamhammer laid out its base poorly, and no buildings could be added without ordering a new pylon first, which it didn’t know to do. The bot slowed to a crawl, trying over and over again to place buildings that, under its rules, there was no room for. The space powered by pylons was filled up.

Too infuriating! That same evening I put together an elaborate system to solve it, connecting the building manager, the strategy manager, and the information manager. It’s a version of the “absolute minimum” fix that I wrote about before. When the building manager sees that a protoss building location cannot be found, and the building requires pylon power, it sets a flag “stalled for lack of space” and refuses to make any more attempts to place buildings that require pylon power. It can still place a pylon, nexus, or assimilator. The strategy manager recognizes a building manager stall as a production emergency and orders an emergency pylon. Finally, the information manager, which keeps track of units, now keeps a set of our pylons. When a new pylon completes, it notifies the building manager to clear the “stalled for lack of space” flag if it is set.

The system seems to work. As one test, I made an opening which ordered 20 forges in a row. It was fun to write "20 x forge". Everything worked as designed: The building manager stalled each time it came to a forge that could not be placed. In the stalled state it does little work, and there was no slowdown. The strategy manager saw the stall and ordered an emergency pylon, which the building manager started. The information manager saw the pylon finish and told the building manager to unstall, and construction proceeded. It was not too efficient in terms of game play, but nothing broke or froze or ran over the time limit. And it worked repeatedly until all 20 forges were made, and the bot switched into normal play. Still, it would be surprising if such a complicated arrangement didn’t cause any bugs....

The problem to solve is a slowdown, and this change is an optimization that speeds things up: Technically it is a fix, not a workaround. But it is not a complete fix. Building placement can fail due to bugs, rather than lack of space in range of pylon power, and this fix doesn’t take that into account. A building placement bug could cause unnecessary stalls. Also I’m not convinced it will always play nice with the “oh, hey, let’s choose here as my new main base” code. I need to put a lot more work into the building code to make it fast and reliable, and then to teach it more sensible building layout.

The next version is almost finished—nominally. I need to complete some coding in the opponent model and batter it with heavy tests until it doesn’t fall down, and that is all that is in the plan. The problem, to change metaphors, is that every time I kick the ball, the goal moves away, carried by creeping features.

Working on the opponent model today, I made one of the key changes for the next version:

    "UseEnemySpecificStrategy" : false,
    "EnemySpecificStrategy" :
    {
    },

No more openings hand-configured for known opponents. Steamhammer has to figure out everything on its own. I’ve been working toward this for a long time, and it’s good to finally take the step. I expect play to become more varied—Steamhammer is likely to discover surprising solutions for some opponents. Play should also become stronger, especially in tournaments where opponents like to prepare specially against select enemies. They’ll have to look for ways to exploit Steamhammer’s tactical and micro mistakes, because the game plans will be too adaptive.

I also wrote the terran vulture-first recognizer for the plan recognizer today. It recognizes a plan called Factory that can only be followed by terran, and Steamhammer zerg is configured to counter the plan with the AntiFactory opening. Testing against Iron, it worked perfectly: The first game, Iron won easily. The second game, Steamhammer countered and fought back hard (and happened to win). That’s how it’s supposed to work.

The recognizer was easy to write. Maybe I should write a few more recognizers and counters.

Iron should be a good test case, because Iron is strong enough to usually defeat the counter—AntiFactory puts up a tough battle, but still mostly loses. Opening learning success looks like this: Steamhammer realizes that AntiFactory is probably best, though not all that good, and explores other openings sometimes but not too often. I think I should be able to get that right.

Will playing better games against Iron entice voters on SSCAIT? I think it might happen. If so, I will quickly grow bored with similar Iron-Steamhammer games, but stream watchers may be pleased. Iron would likely lose a few elo points to Steamhammer on average, instead of gaining as it does now.

The upcoming version 1.4.2 has important improvements for all races, including some improvements I haven’t mentioned. Strategy, macro, and micro are better. Look forward to higher rankings for Steamhammer and Randomhammer.

The next version will be Steamhammer 1.4.2. I still have a bunch of work to do before it will be ready to release. I’ve implemented “side features” (meaning stuff I added for this version beside my main goals of map analysis and the opponent model) that will improve macro for all races, but especially terran and protoss. Micro is improved for all races, especially zerg and protoss. But I haven’t finished most of the main features that I promised! The map analysis works but is not well tied in to the rest of the code yet. The opponent model features will improve strategic play for all races—I expect they will improve play a lot. But the opponent model features are not ready at all.

So I’ve decided to get back to my main goals and skip further side features for now. Well, I’ll fix a broken improvement to wraith micro that I already wrote, but that’s all I plan. Pushing ahead on the main goals will get the release out sooner.

Earlier on this release, I thought I was working a lot on openings. I made a zerg AntiFactory opening to counter terran vulture openings and their followup, and it does its job. (By the way, more experience shows that even with AntiFactory, Steamhammer loses most games to Iron. Steamhammer stops the vultures, but has other weaknesses that Iron exploits. Still, zerg puts up a fight and does win occasionally, and that’s good enough for now.) As part of testing it, I made a terran VultureWraith opening, which is why I wanted an improvement to wraith micro. (VultureWraith seems to work well against unsuspecting zergs.) Plus I added various other openings, and fixed the accidentally broken OverpoolSpeed.

Now I feel as though I need to put in more time than I have on openings. I started working through Antiga’s new openings, beginning at the beginning with 6Gate. I got distracted after realizing that different followups for 6Gate put different pressure on the opponent, and had to stop when I saw that it was going to take too much time. I expect that I will slot Antiga’s openings into the configuration file, but I will probably not set any of them to be played, because I don’t have the time. Well, the following version 1.4.3 is planned to collect opening data itself and decide on its own how often to play openings, so I guess it’s OK. And for 1.4.2 I plan to play “never play this” openings when all else fails, so even in this version the new openings may help a little. Krasi0 will at least get to exercise its different reactions.

Since production goals are working well, upcoming versions will emphasize production goal features, alongside the map analysis features that will let me turn off BWTA. Each new production goal feature should further improve macro, until I can finally drop BOSS from Steamhammer altogether. In both BOSS and BWTA, I’ve come to feel that the B stands for Big and Bad.

The new production goal code that I announced yesterday is working great for its one use case, terran addons. I have a lot more testing to do, but so far it looks solid. There are no known bugs. Addons are reliably built when ordered, or as soon as possible afterward.

Building addons is not only more reliable and more timely, it’s easier. If you know you want a control tower as soon as possible, simply ask for it immediately after the starport, like this:

... "starport", "control tower", ...

Previously, you had to figure out where in the build order the starport would finish, and insert the control tower there. That was a pain and often delayed the build order.

When the control tower comes up, ProductionManager turns it into a goal. The goal looks around and finds the uncompleted starport it is to be added to (as soon as the starport does start–it may stay in the building manager for a while), and remembers it. (Or it finds a completed starport and executes immediately.) If the production queue is displayed, pending goals are shown in white and orange above the green units under construction (which are above the multicolored units queued for production). When the starport finishes, the control tower starts immediately, and the control tower goal is completed and deleted.

Of course, there are a lot of ways for goals to fail. If the starport gets canceled before it is started, or is canceled or destroyed after it is started, the goal will recognize (in a second or so) that it has failed, and be deleted. On the other hand, if the control tower starts but is then destroyed before it finishes, you have to order another control tower. The goal was already completed.

Next, I will work through the terran openings. Merely having the production goal code makes them more reliable. I think several of them can be tightened up to also produce key units sooner. Terran play will be slightly but unequivocally improved.

The new code never fails to build the addon when commanded. It seems strange. It builds the addon on the earliest possible frame, and it’s fine (just as Ankmairdor said in a comment). Building at a different time should be the only difference from the old code: The production goal code does exactly the same checks (“can I start this yet?”) and issues exactly the same command, because all I did was reorganize the code to do the same things at different times. I remain mystified about the cause of the original bug.

My initial goal code was beautifully simple. I was pleased. Of course, once I fixed the early bugs it was not quite so beautiful any more. I guess that’s how it goes. I found solutions, though, and it’s still good code.

Production goals work so well that I’m already considering adding another kind of goal for this version. When the opening ends, maybe Steamhammer should automatically post a goal to build workers as possible, for terran and protoss. Zerg has to make tradeoffs, but terran and protoss commonly want to build workers continuously until their bases are saturated. It’s not perfect play, but it’s better than Steamhammer’s current play. I would change the strategy code for terran and protoss to request no SCVs or probes, and leave it to the goal. The worker goal would build workers with priority over regular production. If you happen to want different behavior, create a different worker goal and post that instead. For example, for a rush opening, you could create a command to post a goal to make workers with low priority for some period of time.

I think the addition would be a substantial and relatively easy improvement over BOSS. Is it worth delaying other features to get that one in too?

Update: I’ve tested every terran opening multiple times in full games, and slightly revised about a third of them to get addons sooner. The production goal system is working perfectly. Macro is noticeably improved for everything that depends on addons: Comsats have more energy because they are made sooner, factories get more tanks out, and so on. I was able to remove a workaround for a BOSS comsat bug, because the production goals work around it automatically. There is one issue where BOSS occasionally orders far too many addons, partly because of bugs and partly because BOSS doesn’t know the bot’s full state. The system struggles to recognize that most of the addon goals will fail, and they stick around too long. So far this hasn’t caused any problem worse than looking stupid, but in the worst case it could cause a slowdown.

A couple days ago I wrote about Steamhammer’s addon bug, and everyone who offered advice suggested more or less the same plan: Keep track of addon production yourself. Fix the bug by retrying if necessary.

That plan happens to fit with another plan I’ve been nurturing, the idea of abstract opening strategies that I wrote about in March. In an abstract opening strategy, you specify a goal like “get me 3 hatcheries and spire tech, go!” That’s a high-level production goal, while adding a control tower to a starport is a low-level production goal. But they are both production goals, and both can be implemented by the same software system. After all, to achieve a high-level goal, you have to achieve several low-level subgoals.

Today I drew up the first draft of a ProductionGoal class. So far it can only represent goals to build addons, to solve the immediate problem. That will be enough for the next version. As a next step in a later version, I might add goals to create morphed zerg buildings with dependencies. Then you can order a lair, and it will reason “you have the hatchery and stuff, here’s your lair.” Or order a sunken and it will build the creep colony first if necessary. Right now if you ask for a sunken at the natural and there is not enough creep there yet, Steamhammer will build it in the main instead as a fallback (and it’s usually a mistake). With a persistent goal data structure, it will be easy to duplicate Killerbot’s skill of waiting until there is enough creep at the natural to start the building. It will also be easy to add goals like “make 1 sunken at each base,” which you might want when vultures are roaming. Protoss might want the goal of putting 1 pylon at each base, in case cannons are needed later.

I’ll work in stages toward full-power production goals. One of the steps will be to add a production status data structure, after which I’ll be able to turn off latency compensation, another thing that’s needed sooner or later. The plan is growing more concrete.

Simplifying MicroTransports.cpp reduced its length by about 150 lines of code. That was rather a lot of extra code for the small job of moving around the edge of the map—and the waypoint method that I’m sticking with is hardly the simplest way. The savings in memory use (it takes less than half as much) and runtime (ditto) are greater—not big enough to make an overall difference, but reducing overhead is always good. Most importantly, the code is much clearer, so the future improvements needed for drop will be easier. The detailed behavior is slightly different, not much. There is still a bug in choosing which direction to go around the map, but I’ll solve it.

In vaguely related news, dropping sometimes triggers Steamhammer’s addon bug. The bug is that when building a terran addon, such as the control tower for a starport, sometimes the addon is ordered but never built, wrecking the build order. BWAPI says that the addon will build, but when the order is issued, it doesn’t. In practice, it happens when the control tower comes up in the queue at about the same time that the starport finishes. My latest theory is that there is a latency period after the starport finishes before the control tower can start, and BWAPI doesn’t recognize it.

The last time I worked on this bug, I struggled a long time and finally gave up. I ended up inserting filler items into the openings to delay addons so that they are unlikely to be ordered early and trigger the bug. Of course that makes play worse, but it was a workaround. The bug came up again because queue reordering cleverly realized, “Hey, this addon can be moved up, let’s build it now!” and triggered the bug in half of games.

For now, I told queue reordering not to pull an addon to the front. 2 hacky workarounds for the same bug are too many. This time I’m determined to get to the bottom of it. So... any hints?

Steamhammer inherits from UAlbertaBot the use of waypoint navigation in 2 narrow cases, for moving the scouting worker around the edge of the enemy base, and for moving the transport around the edge of the map when dropping. The 2 implementations are completely separate.

Today I am fixing yesterday’s bug related to drop. Following my minimum energy trajectory, I naturally clean up any code that I work on. The drop navigation turns out to be extravagantly overcomplex; I imagine it was copy-pasted from the scout navigation with minimal changes, even though following the map edge is a far easier problem. In cleaning it up, while keeping the same general plan I am eliminating 1 persistent data structure (dropping _waypoints and keeping _mapEdgeVertices which I will rename to _waypoints) and 2 temporary data structures used unnecessarily to find the edge of the map. You seriously don’t need complex calculations to lay waypoints around the edge of the map. I decided to keep the overall waypoint plan because it provides flexibility for future uses, even though the flexibility isn’t needed now.

Back when I first worked on drop, I treated this code as a black box and touched it as little as possible while marveling at its opacity. Now it is becoming much shorter (and incidentally faster), and getting commented so it will be understandable. I also intend to decide accurately which direction to take around the edge. Steamhammer too often takes the long way around.

Waypoints seem like a good navigation tool whenever you want to plan movement several steps in advance. If you figure out a safe path to get an overlord to a good observation post, or to route vultures around the sunken to reach the mineral line from the far side, then you can represent the path as a sequence of waypoints. Executing the plan seems easy. I guess if you’ve moving a substantial ground army, you probably don’t want to send all units to a single point, but I can see ways to work with that (either plan ahead with “way zones” or react on the fly to keep to safe locations within some tolerance). Of course the plan may run into difficulties so that you have to replan, but that is always true.

If you sometimes plan only one step ahead, then you don’t need waypoints—but you can still use them. Waypoints seem like a general purpose representation of paths from A to B.

I’ve noticed the duplicated waypoint code before, between scouting and dropping, and thought of factoring it out into a waypoint class for wider use. I may do that. It would be part of the solution to the other and bigger bug, getting stuck on map obstacles.

Do people have opinions?

I thought Steamhammer would always locate the enemy. If the early game scout gets killed, the ground forces have orders to visit any unscouted bases. If the ground forces are held at bay, the recon squad will check the rest of the map, locating the enemy by eliminating other possibilities. Only if Steamhammer loses quickly should it be unable to find the enemy base, and then it doesn’t matter.

Today it happened, and it caused a bug. I was testing map analysis with a particularly difficult map. Steamhammer was terran, so scouting was on the ground only, and everything that left Steamhammer’s base got caught behind map obstacles. The strategy was vulture drop, and when it came time to drop, Steamhammer loaded up the dropship and... had nowhere to send it. It started throwing an exception over and over. It’s a basic bug, but it had never happened before.

The question is, how do I fix it? The simplest plan would be to disband the drop squad if there is no target. Maybe I should do that, since it’s a rare case. It would be more effective to use the dropship itself to scout for targets, since everything else failed. It’s a skill that will be needed anyway when drops start to happen later in the game, but on the other hand it would take time. Hmm....

Another fix needed, of course, is pathing so units don’t get stuck. It’s easy enough to implement, but I keep putting it off because it seems to add architectural complexity and invite bugs. I need to think of a clean way to do it.

Map analysis, by the way, is working great. I have eradicated all the bugs I could find, and now in the rare cases where it does something unexpected, it always turns out to be good enough. The one base on Match Point is still on the far side of the minerals; I think it’s reasonable. The upper left island on Lost Temple gets 2 bases because the resources are so far apart; it seems reasonable. On almost all maps, even large and irregular old Blizzard maps, every base is placed as expected.

Now I have to start the work of actually making use of the map analysis. BWTA is explicitly written into the code in a ton of places. I don’t think it’s smart to rewrite them all at once, big bang style, so I’ll do them a little at a time.

Update: I decided to follow a plan similar to the PurpleWave idea mentioned in a comment. Steamhammer now calculates a drop target instead of simply aiming for the enemy main base, and if there are no enemy bases or buildings known, the target will be an unexplored place. I’m still updating MicroTransports so it can recognize when the target changes, which could happen at any time. It turns out that the map edge following code is far more complicated than it needs to be. I think Dave Churchill must have originally written it for another purpose, and dropped it in with little simplification.

Simon Prins’s Tyr blog seemed to be mostly about a Starcraft 2 bot, so it had fallen off my radar. Now he has e-mailed me about a profile of Steamhammer, the latest post. It seems like a fair overview of Steamhammer for someone who’s looking around at starter bots and hasn’t made a choice yet.

In the same vein is a profile of UAlbertaBot. It seems there are a number of posts about Brood War bots after all; it is not all Starcraft 2. I liked the posts about human rush skills versus bot rush skills and rush defense, pointing out that bots still have room to improve.

Steamhammer occasionally likes to expand to mined-out bases late in the game. I have made a whole series of changes over different versions to fix it: I had it score bases by available resources, I had it avoid bases altogether which don’t have enough minerals to be worth it, then I extended it to avoid bases where the geyser is mined out. And still there was one recent game where Steamhammer took an empty base.

Finally it dawned on me that Starcraft is a game of imperfect information. If you choose your next base when you can’t see it, then of course you’ll sometimes choose the wrong base. Oh... I think I should have learned that by now. And yet just today I was fixing visibility mistakes in the base code, where it called getTilePosition() instead of getInitialTilePosition(). Somehow it’s easy to forget.

Does that account for all the cases? I’m not sure. It’s a somewhat rare bug, but I have a feeling that the most common empty base to take is the enemy’s natural after destroying it, when it should be visible. Maybe there’s yet another bug, which would be depressing.

How many more bugs are there because I am sometimes blind to the basic workings of BWAPI? I bet there are more than a few. Software is hard.

Steamhammer’s new base placement code works perfectly on all SSCAIT maps, and most other maps that I have tested—but not quite all. I found one case on Gaema Gowon (an old map that is not likely to come up in bot competition) where a gas geyser for a low-ground natural base was assigned to the nearby high-ground mineral-only base instead. That’s a bug that I’ll fix, and it’s the only mistake I’ve seen in assigning resources to the correct bases (I’ve been checking every base). A different surprise came up on Match Point, for the right-hand mineral-only base.

The background: Once it has determined the set of resources that belongs to a base, Steamhammer places the base by finding the legal spot with the minimum sum of distances to the resources, using a simplified distance measure that ignores diagonal offsets. In practice, it seems to work great for a base which has gas, even if all the resources are in a straight line. For a mineral only base, it occasionally places the base 1 or 2 tiles to the side of BWTA’s location, a spot which is just as good by Steamhammer’s distance measure and, to my eye, not significantly worse by any measure. Multiple locations might be equally good.

For the right-side mineral-only base on Match Point (and not the symmetrical one on the left), Steamhammer places the base on the opposite side of the minerals from the standard location. The base has id 6, labeled on the minerals and the base location. The large yellow box is the bounding box of the resources. The small yellow box is a tile near the geometric center of the bounding box, used as the starting point for base placement. The hatchery is placed in the standard position, in this picture.

I’ve never seen a game on this map with a base on the wrong side of these minerals (and I’ve seen enough games on Match Point, it’s a popular map). Looking at the mineral layout, I have to think that Steamhammer’s position will mine less efficiently (this is the only example I’ve seen where I thought the difference might be significant). And yet I can imagine tactical reasons that you might want to displace your base—workers might be able to run away more easily from an attack down the ramp, it might be scouted later, it might allow freer unit movement around the ramp. I’ve seen pro games with deliberately displaced bases at the mineral-only bases of Circuit Breaker.

It got me thinking. Maybe I should provide a way to calculate alternative base placements, so if the bot has a reason to, it can offset its base. Well, I won’t do that soon, but maybe someday.

Steamhammer’s new base placement code seems to be working well on the SSCAIT maps. It places most bases in the same locations as BWTA, and where it differs, its placements look to me to be as good. I’ll give it a more rigorous round of testing to be sure, but I’m close to the point of turning off that use of BWTA. The less important uses that remain can probably be cleaned out in the next version, and I can finally kick the clunky old library goodbye.

Update: The rigorous test is in progress. The upper right mineral-only base on Electric Circuit fails to place, and that is the only error I have found so far. Electric Circuit is not a current SSCAIT map, so it’s not urgent to fix. I will likely turn off BWTA base placement tonight or tomorrow.

A quick note on my busy weekend. Today I am testing a change to micro targeting. Steamhammer scores the possible targets and picks the highest score. For a long time, the score has included a measure of “how close is this target to the goal location?”—that is, to the position the squad has been ordered to attack toward. It was never a convincing measure, but it was what I came up with to push the squad toward its goal. I changed it to a simple bonus for targets which are closer to the goal. I also changed melee units to allow them to reject all possible targets; it used to be that they were forced to acquire a target if one was in sight anywhere on the map, which made the units super easy to distract.

I had become convinced that zergling micro was systematically off, and this change seems to show I was right. Zergling micro is visibly improved against Wuli and Killerbot by Marian Devecka, and win rates are up. Theoretically, zealot play should be improved too, but I haven’t tested it yet. Micro of ranged units is affected, but it’s not clear yet whether the change is an improvement.

The no-forced-targeting change makes zerglings play more forthrightly against Stone’s distracting SCV maneuvers. The wins didn’t take as long. We’ll see how it does against Tscmoo.

1.4.2 is looking to have several critical improvements. It should be good.

More delays for the burrow post. I have a busy weekend.

For some reason, I’ve been working on openings a lot for this version. Looking at Microwave’s openings, I noticed “5Pool Zergling Hell”, which researches speed for the zerglings after the second hatchery. That is very late zergling speed, and it didn’t seem to fit with the rush build. That may be why Microwave doesn’t use it; by the time speed finishes, the game is probably already won or lost. But it gave me an idea.

This morning I coded up a 6 pool speed opening. By using the extra drone on an extractor, the build can produce 3 zerglings before hitting the supply limit, just like 5 pool, and ends up with the same drone count. 5 pool gets the zerglings a little faster and also can start the second hatchery sooner because it spends less, but zergling speed is powerful and (I reason) should make up the difference. 6 pool is a little slower, but it’s still a fast rush.

During testing, I noticed that Steamhammer’s 5 pool opening was optimized for 3- and 4-player maps, an unfortunate choice since it is played most often on 2 player maps. The difference is the income produced by the scouting drone, which is not needed on a 2-player map. So I also coded up 5PoolHard2Player as a separate build, and configured it to be chosen over 5PoolHard on 2-player maps. The rush becomes a little bit meaner.

6 pool usually beats 5 pool head to head; the extra drone is used up, so the advantage is zergling speed. 6 pool puts up a surprisingly tough fight against 9-9 gate before losing (as it should, since 9 pool loses too), and it tends to beat the 8 barracks bunker opening that Steamhammer terran relies on to defend fast rushes. The rush is slower but need not do as much damage to succeed, because the extractor and zergling speed make it easier to transition to the middle game. Overall, I conclude that 6 pool speed is about as dangerous as 5 pool, and it poses a different challenge to opponents so it is worth having.

All the rush openings should become stronger when I fix the bug in the building manager which causes unnecessary worker movement before starting a building. It’s on my list to fix soon.