archive by month
Skip to content

Steamhammer 1.4.2 status

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 addon code works well

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.

production goals (and addons)

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.

a few brief notes

1. SAIL seems to be down. The last game result is 24 April. I don’t see a note on the web page, so that’s all I know.

2. New protoss bot skyFORKnet says “it’s mostly skynet” by Andrew Smith. I’ve only watched a few games, and so far I don’t notice any differences from Skynet. Anybody know? Skynet is under a GPL license, so source code should be available somewhere (or else the author is violating the license). Anybody know this either?

3. I had to look up the name “toothpick cactus” to find out what kind of cactus it was. What’s next? Octopus Cactus? Giant Chin Cactus?

MicroTransports improvement and the addon bug

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?

waypoints

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?

rare bugs

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.

Tyr blog post about Steamhammer

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.

unnamed ladder now named SAIL

The unnamed ladder has gotten an official name: SAIL, the Starcraft AI Ladder. That will make it easier to talk about!

Another update since my last mention is a line on the web page giving the last time SAIL was updated by copying bots over from SSCAIT. It says they do it weekly. From the point of view of a bot author, SAIL can be treated as an annex of SSCAIT: Submit your bot in one place and get the advantages of both. It would be nice of SSCAIT to advertise that, so that authors know what they are getting into.

Steamhammer occasionally takes a barren base

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.

alternative base placements

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.

displaced base

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.

the 500 uses of burrow

Burrow is like The 500 Hats of Bartholomew Cubbins—it doesn’t have infinite uses, each more elaborate than the last, but it does have more than you expect. At the same time, burrow is like the hats in that is it not often practical. It’s fairly rare to research burrow in pro games, though there are situations where it is common.

The Liquipedia article on burrow is fairly thorough, though I know more than it does. I’d like to organize the information differently, by the tactical or micro purpose. Of course, it’s common for one use of burrow to have more than one purpose. As far as I can tell, my list of purposes is exhaustive. Did I miss anything?

First, an observation: Many bots don’t get detection unless and until they know that they need it. Also many bots don’t recognize or react to burrowing when they see it (though Steamhammer does). In bot play, I think burrow is highly abusable, in other words it has a strong chance to exploit the opponent’s weaknesses.

Also, coordination always helps. If the enemy is camping your burrowed units to keep them down, maybe you can pressure somewhere else to release them. If you’ve laid a burrow trap, maybe you can lure the enemy into it, or force detection somewhere else to distract. And so on.

To hide for safety. When a reaver comes in to drop, there is probably no observer around. Drones can keep mining until the reaver appears on the ground, then burrow before they are targeted. (It’s not good against storm drops, though.) If outnumbered units can’t get away (they are slow or are cornered), they may be able to burrow and hide; at worst, the enemy will have to make extra effort to detect them, and at best they may live. If you think the enemy doesn’t have detection, you can burrow almost any time that you don’t want to fight. It may complicate the enemy’s tactical reasoning. Of course the enemy could choose to stand around on top of your burrowed units until they can be dealt with, so it may also complicate your tactical reasoning.

To hide in ambush. This is something I tried as a beginner: Burrow zerglings on the map where marines will pass by, and when they unsuspectingly walk over, unburrow for a surprise attack. It’s hard to do successfully, and the few times I’ve seen it tried in pro games it usually fails, though in the best case it can be devastating. It’s easier to burrow outside the enemy base for a backstab after the enemy army leaves. Or burrow in position for a sandwich; for example, burrow outside your base and unburrow when the enemy approaches your sunkens.

Against corsair-reaver play, it is common to burrow hydralisks in places where shuttles may appear. Ideally, you can snipe shuttles before any reavers land.

You can burrow near a base location that the enemy should take, and wait for the base to start construction, or to finish construction, or even for workers to arrive, before springing the ambush.

An infested terran does tremendous damage, and an infested terran can burrow. (That’s some extreme infestation.) Infested terran burrow traps are tempting. If terran is making mass tanks, maybe there’s not much gas left over for vessels and you can burrow in position to wipe out clustered tanks. 3 infested terrans kill a command center. You can try to burrow them where a base will be. If the queen is still around and you want another infested command center, you only need 2 infested terrans. But in most situations, probably drop is more practical than burrow for deploying infested terrans.

Hiding has many tactical uses. If you are short of overlords near the enemy base (perhaps on purpose so they’re not spotted), you can elevator a force piece by piece into an unseen corner and keep them burrowed there until the attack force is complete. It’s not a skill worth implementing in a bot, but I want to show that creative uses are out there.

To gain vision. Also common in corsair-reaver is to burrow zerglings around the map to reveal where the enemy is flying. It’s especially useful in corsair-reaver, because observers do not come along so the enemy rarely finds the burrowed lings. It’s potentially useful whenever the enemy moves around without detection. You can burrow zerglings at chokes, or in between bases to catch when workers transfer.

You can burrow in the enemy base to watch. A scout that survives until burrow is researched but then is in danger of being caught—burrow. A zergling force sneaks in to pick at probes, but 1 burrows by the gateways to see what comes out, or near the ramp to see what passes by. If you see the robo, maybe you can find a spot away from the path that observers will take.

To block building construction. Some terran bots place spider mines at every base location. A zergling works just as well for gaining vision and for blocking construction, and it has the option of unburrowing to chase off the enemy worker, or to look around the area, or to flee if in danger. Because it can unburrow, it has a chance to spot the start of the enemy base, rather than just the presence of the enemy.

It’s theoretically possible to use burrow to spoil a wall, or to prevent a terran addon from being made. I find it hard to imagine when that would be useful. But consider: Many bots are unable to adapt when they fail to place a building, and simply try to place it in the same location again. A burrowed unit anywhere that one of these bots tries to build may mess it up severely.

To take advantage of stacking. Burrowed units stack, somewhat like air units. In other words, units under the ground never collide with each other. You can burrow arbitrarily many units in the same patch of ground, one group after another. You can make a large force look like a small force, even to a detector, by burrowing units on top of each other. If you stack lurkers on top of each other, the lurkers will probably fire at the same time at the same target and their damage will also stack. Strong players do this all the time, to make it unclear how many lurkers there are, to make it hard to irradiate all the lurkers, and to get the effect of the stacked damage.

Units above the ground of course do collide when their collision boxes overlap. When you unburrow units which overlap with other units you are unburrowing, or with units already on the surface, then the units don’t all fit in the space they occupy. They get stuck on each other and start to glitch and spread out. Sometimes that’s bad; it causes awkwardness all the time for Steamhammer when unburrowing lurkers. There are also ways to exploit the collisions.

The Hoejja build is a way to exploit the collisions. It uses burrow and unburrow to glitch early zerglings through the blocking mineral patch on some maps—not all the lings get through, but it can be enough. It relies on the opponent to play a build with no early mobile defense, namely protoss forge expand. On the one hand, the only SSCAIT map suitable for this trick is Destination. On the other hand, a bot should be able to do the burrow-unburrow trick much faster and more precisely than a human, and a machine opponent is unlikely to understand how to react.

You could try the same burrow-unburrow trick to pass units through a wall. Does it work against Iron?

Another way to exploit the collisions is to spring a burrow trap which causes the enemy units to glitch. If other forces attack at the same time, it won’t matter at all that some of your unburrowing units are glitching too.

To prevent spell effects. Burrowed units avoid some spells with area effects.

These spells leave burrowed units unaffected: Maelstrom, stasis, recall, ensnare, plague. Of course recall only works on your own units (which you must have gained by mind control if they can burrow), so inability to recall a burrowed unit is a limitation. (I imagine that the limitation is because burrowed units stack; the designers don’t want you to be able to recall an arbitrarily large zerg force.) For the other spells, you may be able to avoid the effect by burrowing early enough.

These spells affect burrowed units as usual: EMP, defensive matrix, yamato cannon, hallucination, psionic storm, disruption web, broodling, parasite. The visual effect of defensive matrix is not visible on a burrowed unit. Disruption web is mostly useful for disrupting burrowed units which are lurkers, because others can’t attack while burrowed. If you dweb burrowed zerglings, they can unburrow and leave the area of effect to attack.

You can broodling a burrowed unit. The 2 broodlings appear above ground and cannot burrow. (Liquipedia says that all ground units other than ultralisks can burrow. They forgot about broodlings.) You can hallucinate a burrowed unit. The hallucinations appear above ground and cannot burrow.

Not on either list above is irradiate. You can irradiate a burrowed unit as usual. But the splash damage of irradiate is absorbed by the ground: It does not splash from or to any burrowed unit. If one hydralisk in a group is irradiated, you can burrow it to save the others. Or you can burrow drones when terran tries the eraser trick, flying an irradiated science vessel overhead. Both ways prevent irradiate from causing splash damage.

To prevent splash damage. Burrowed units avoid some splash damage. Liquipedia explains it as a splash damage effect of dark swarm, but dark swarm is another topic. As far as I know, the only important splash avoided is tank splash. I didn’t test it to find out, but it’s possible that they also avoid the outer ranges of nuke damage.

If you set up an array of zerglings and have a tank fire once at the central ling, then tank splash works like this: The central ling and some around it are killed, while others a little farther away are damaged. If you burrow the zerglings and then have the tank fire once, then the central ling and some around it are killed, while those a little farther away are unharmed. The splash damage was eliminated outside an area of central effect.

Under dark swarm, the tank shot is offset from its aim point. It still kills zerglings in its area of central effect, so the terran may be able to analyze the pattern of units under dark swarm and aim at one that puts the actual impact point where desired. Or zerg can arrange the units so that important units cannot be hit by aiming at another unit. When I tested it, I found some unexpected tank splash outside the impact point, so it may be that dark swarm has more complicated effects. At least, there’s probably something I don’t understand.

To prevent slow effects. I haven’t tested this, but it seems likely to work. Some attacks, like the reaver scarab and the ensnare spell, are slow and you can see them coming because they have a “bullet” that has to travel to the target. Burrowing takes time too, but it is fast. I think you can probably avoid slow effects in some cases by burrowing immediately.

I thought of another tricky idea to stop reaver shots using burrow. It’s not practical, but it’s cute: Burrow a tight line of units in front of or around a target (likely across a choke). When the reaver scarab comes, you should be able to unburrow in time to block the shot. I expect the scarab would be unable to find a path to the target and would dud out. Then you can burrow again before the next shot. If you want it to look impressive, predict the scarab’s path and unburrow just the units needed to block it at each moment, like playing Pong with a scarab. (Seriously. Somebody should try to code scarab Pong, just for fun.)

The hold lurker trick. This isn’t about burrow specifically, but it is common in human play and it is related. It’s worth a mention. See the Liquipedia article for details.

Steamhammer’s base placement code is looking good

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.

testing a Steamhammer micro targeting change

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.

6 pool speed opening build

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.