Starcraft AI blog

Most of my attention is going to bugs, but I’m still poking at the new SparCraft version too (I also ran a few tests). My latest conclusions:

1. I’m still worried whether it will be fast enough. It feels slow. I’ll have to try a test on the SSCAIT server to find out.

2. It’s lying when it claims to support scourge. The provided UnitTypeSupported() call returns true, but with scourge in the sim it throws and you don’t get a result. I modified UnitTypeSupported() to exclude scourge, so that at least it’s honest about what it can do.

3. It also doesn’t support spore colonies correctly. I’ve seen it be startlingly accurate in predicting a small-scale fight of marines versus a sunken and a few zerglings (attacking with barely enough marines and scraping a win with 2 bleeding survivors), but in a fight of mutalisks versus spores it says “sure, 1 mutalisk can win, no problem.” This is the map to Suicide City; enter here and do not exit.

I decided to compensate with a crude adjustment. Don’t add enemy spore colonies to the combat sim. And for every enemy spore not added, drop 6 of our mutalisks (pro rated to the hitpoints of the spore colony). That’s about the number you need to beat a spore safely. In initial tests the adjustment seems not too silly. In reality 6 is too large a number, especially if there are separated spores, but I’m tired of the one-way trips to Suicide City.

Out of the huge range of unit combinations in the combat sim, I have hardly tested any. I expect to find more that SparCraft gets wrong.

Arrakhammer’s description changed recently to say that it supports infested terrans. As far as I know, it is the first bot to make them. Now it has played a game with infested terrans versus Randomhammer.

The game is on Destination, a 2-player map. Arrakhammer opened with hatchery on 9, and instead of playing the opening the natural way with mass zerglings, only made a handful, aiming to tech up fast. Randomhammer opened with 2 barracks and before long had enough forces to push to the zerg natural. Zerg was forced to make sunkens, but terran did not dare to break in, and lost medics due to a bug in retreating them.

Zerg went for lurkers against the infantry, but the expensive sunkens set Arrakhammer’s tech plans far back and the lurkers were slow. Terran accumulated marines to hold a strong contain while expanding. Randomhammer had an objectively winning game; with good play, zerg should never catch up (see the worker and army counts in the picture). But Randomhammer is not a good player.

Straight infantry with only scanners for detection is not a winning combination against lurkers, especially not if you try to attack across a narrow bridge and repeatedly lose medics to the retreat bug. As long as scanner energy held out, Randomhammer held its own. But the scanners ran down and Arrakhammer hesitantly pushed out into the open map.

In this picture the lurkers have defeated most of the infantry after scanner energy ran out during a big fight. The queen has just now infested a command center, and from the flashing ramp and the production tab you can see that an infested terran has already started. Before the base was taken, terran had 5 bases to 4. Zerg had more or less caught up, and both sides had chances.

The first infested terran was shot down barely before it reached its intended victim. Steamhammer knows that an infested terran is a high-priority target, even though this is the first time it has seen one. In the overall situation, marines continued to fight lurkers without enough scan energy, and zerg was pulling ahead.

In the next picture, terran has lost another base, but the marines gave a good account of themselves, clearing the attack and killing the infested command center before it could produce. Losing the base was down to poor tactical skill. The marine army was larger and had 1-1 upgrades versus 0-0 for zerg, and repeatedly fought well until collapsing when scanner energy ran out. The queen, by the way, broodlinged an SCV before the zerg attack.

Infested terrans are difficult units to use well. They’re similar to scourge: Suicide units that do a ton of damage, but are fragile and costly in gas. If you walk them into an enemy army, the army should normally kill them without much risk, as above—it only took 4 marines. If they walk in the open, they should attack SCVs or defenseless buildings. A few infesteds can clear out a dense mineral line, or demolish a substantial block of supply depots; they’re efficient for that. You can drop them on tanks, or on dense concentrations of units that can’t shoot up. Otherwise you need dark swarm to attack an army with infested terrans. You go to a lot of trouble to get them, and they’re a specialty unit which is complex to use.

Of course bots don’t know how to react, so walking into an army may work in practice. Steamhammer, for example, doesn’t react at all when retreating, so if you attack while the army is running away, you can do massive damage. 2 infested terrans did this, with excellent cost-efficiency, by catching the army in retreat:

Notice that even after the carnage, terran is ahead in army, though it has fallen behind in economy. Zerg is winning but has some fighting ahead.

The upcoming version of Randomhammer, by the way, has TvZ improvements so that Steamhammer can be a tough test opponent for itself. The upcoming version would have put up a fiercer fight, without the medic retreat bug and with a vessel and tanks against the lurkers.

About a dozen bots have been updated in the last week, and a bunch of new bots have been uploaded this month. We’re going through a burst of activity similar to the one around the previous SSCAI tournament.

The reason might be that the CIG tournament is coming up. The timing fits, but other evidence is not as clear. I don’t see an upcoming tournament as a good reason to release new rushbots, or to put out an instance of McRave playing terran (Sparks). But only the bot authors know their own motivations. Maybe some will comment?

A tournament in April or thereabouts might be a good way to maintain interest, if tournaments really are good motivation. Thinking about the timescale on which interest waxes and wanes, I guess April would be about right, depending on how long the tournament runs. The CIG and AIIDE tournaments are tied to academic conferences and can’t be moved around the calendar, and SSCAIT traditionally runs starting near the end of the year. It’s possible that a gap-filling tournament, if people see it as important, might keep the scene lively. Well, it’s a speculative idea, but spacing tournaments around the calendar makes sense. Authors should have time to make updates before the next submission.

Sparks, by the way, has a pretty good strategy. It is McRave set to play terran, and obviously some thought has been put into the terran, though McRave’s protoss play is more sophisticated (so it will presumably play as protoss in tournaments). I imagine it is named after “sparks terran,” which was traditionally a sunken bust timed for just before mutalisks came out. (Sparks terran is a strategy I’ve been keeping in mind as tough for a zerg bot to counter when following a mutalisk plan. Luckily for Steamhammer, it’s not easy to implement well. Tscmoo comes closest but is missing skills.) Today people often say “sparks terran” and mean nothing more than straight infantry play.

Anyway, Sparks the bot opens with 2 barracks and puts its first marines in the mineral line for safety. When it has enough it transfers them to the ramp, arranging them in a nice arc. When stim is done, upgrades are started, and medics are available, it moves out to attack. A terran should stop the attack easily; a protoss shouldn’t have much trouble if it saw what was coming; but a zerg needs to pay attention and defend smartly to hold. It’s a good attack timing.

One of my goals for Steamhammer is to remove the dependency on BWTA, a large, slow and troublesome library. Its startup time to analyze a new map for the first time is ridiculous, and I want full power to analyze map blocks. I could go to BWEM, and I may yet change my mind and do that. But I’m not 100% satisfied; I might have to modify the library to simplify hypothetical reasoning and add features like pathfinding for units which are pushed through minerals. Another idea is to start with UAlbertaBot’s existing distance maps. It calculates ground distances at build tile resolution (32 x 32 pixel tiles) rather than the walk tile resolution of the map (8 x 8 pixel tiles), but this doesn’t cause any obvious problems and is easy to change if necessary. UAlbertaBot doesn’t actually rely on many BWTA features.

I was leaning toward the native distance map solution already. It calls for writing more code, but not that much, and the final solution would end up simpler and better tailored. Now Dave Churchill has made exactly that change to UAlbertaBot. It smooths my path since I can borrow code, and I plan to follow.

Dave Churchill removed BWTA big-bang style from UAlbertaBot, dropping the dependency and replacing its major uses in one step. I think the largest piece was to add a BaseLocation class—not a large piece at all. My implementation strategy will be the opposite. I’ll replace uses of BWTA item by item, testing as I go, and when I’m satisfied I’ll drop BWTA. The development process should be gradual and stable.

As a first step I taught Steamhammer to pay attention to map blocks in calculating ground distance maps. It doesn’t notice when blocks are removed, or route units around blocks, it only calculates distances more accurately based on the map’s initial state. Even this small step improves play, since Steamhammer decides on expansion locations partly based on ground distance. Since I reflexively clean up any code that I touch, I also fixed a bug in checking whether a tile is walkable and reduced the unnecessarily large size of the data structures. Distance maps are better, faster, and cheaper—there should be less memory traffic in calculating a map, and lookups will be more compact in cache.

Bugs can be deeply interconnected in obscure ways. Sometimes one appears after changes that seem to have no relation.

If you watch the latest Steamhammer, you’ll sometimes see idle drones in its base, sitting on the creep doing nothing. It happens especially when the bot has been holding off heavy pressure for a long time, as if its APM were not enough to keep up with managing its base. And I haven’t seen the bug in older versions.

It’s actually a primordial UAlbertaBot design flaw that happens to manifest now because of changes in Steamhammer that have nothing to do with drones. When ProductionManager sees that a building is coming up next, it checks whether it can save time by moving a worker to the building location immediately, so that construction can start as soon as resources are available. If you then insert something into the production queue ahead of the building—which parent UAlbertaBot will do when it realizes a sudden need for detection—then the building will come up again in the queue and the bot may send another drone, leaving the previous one idle. There is no tracking except the order of items in the production queue, which is unstable. The newest Steamhammer triggers it more often because its urgent reactions, the things it does when under heavy pressure, more often insert stuff into the queue ahead of buildings. Then of course the bug causes mining to slow down, so that the pressure breaks through, and the reactions end up backfiring.

By the way, ProductionManager ought to also check when tech for the building will be available. If you watch Steamhammer build its spire, sometimes you’ll see the building drone waiting in place, twiddling its zergy thumbs instead of working, well before the lair is finished. ProductionManager only checked the resources, so it thought the spire could start earlier and sent the drone too soon. I’ll fix it eventually, but it probably doesn’t lose more than 24 minerals.

I have seen the same bug in Arrakhammer. Microwave solves the bug by catching idle drones and putting them back to work. One older Steamhammer version did the same. Unfortunately, a drone that was about to start a building may be put back to work instead, causing a construction delay—that’s why I undid the change in Steamhammer.

Another solution would be to return drones when the queue is messed with. Steamhammer sometimes decides that an upcoming production item is useless and should be dropped; if it drops a building from the queue, which it sometimes does, that could cause the same bug. Messing with the queue behind the scenes needs to notify ProductionManager.

A more thorough fix would be to delegate all the work to BuildingManager. It’s awkward for drone pre-positioning to be in ProductionManager while the rest is in BuildingManager; better to keep the related parts together. If buildings are sent to BuildingManager before they can be constructed and BuildingManager is responsible for positioning workers, then the existing BuildingManager state (with the addition of an “in preparation” label for buildings that can’t be started yet) can keep track of which worker has been assigned to each building and avoid some construction delays that happen now when workers move around unnecessarily before starting the building. It’s more complicated, because messing with the queue then needs to notify BuildingManager. So I might go with the simpler solution.

Getting all the errors out of the infrastructure is hard. I have fixed about 10 bugs for the next version, but there are other basic infrastructure bugs that are as bad as this one, and I have fixed zero of them. They’re tricky. Meanwhile, the zerg emergency reactions also indirectly cause other errors in the strategy boss, sometimes preventing necessary tech switches....

I’ve been playing with the new version of SparCraft by Dave Churchill. I made 2 Steamhammer versions which are identical except for the SparCraft version, so I can test for differences in various scenarios.

My conclusions so far:

1. The new version was not too much trouble to integrate. Throw out the old SparCraft folder, drop in the new one, tweak one Visual Studio setting since I’m using an older version, and rewrite a small amount of initialization code and calling code. There is a new SparCraft configuration file that has to go into bwapi-data/AI/. It’s not much work at all for swapping out a major component. I also removed a small amount of debugging code from SparCraft, but that wasn’t necessary.

2. Dave Churchill dubbed it “semi-stable”, and it’s true. It mostly works, but throws fairly often. I modified the try-catch in Squad to catch all exceptions, and return -1 “we lose” when SparCraft throws. Then the squads retreat, which simplifies the situation so that the errors don’t usually persist. It works well enough. Another idea would be to remember the results of the last successful run and reuse them. I didn’t try that.

3. It still doesn’t support bunkers, reavers, or carriers. That’s quite a limitation. The “let’s pretend this bunker is 5 marines” trick (or something like it) is still needed.

4. Results for battles among ground units seem about as good as before. Tests under controlled conditions would surely find differences, but I’m interested in real games first. For games which stay on the ground, the difference is smaller than I can see by eye and smaller than I can measure from game outcomes, at least so far.

5. Results for battles with air units are improved. Steamhammer with old SparCraft likes to suicide mutalisks. Steamhammer with new SparCraft will still do it, but less happily. It understands turrets and spore colonies better than before. It seems to have an advantage in straight air-to-air battles too, though that’s based on only a small number of test games.

6. Since air units have lost some of their overconfidence and retreat more often, the weakness of their retreating behavior shows more. Steamhammer has always had a tendency to string out its mutalisks due to poor retreating (and other causes), even when it should pull them into a tight knot. The new SparCraft makes it worse. The first couple mutalisks see a bunker and pull back “until reinforcements arrive,” and the reinforcements wait at home “until the outlook improves.” Fixing one weakness makes the next one starker! And it is an open question whether the cautious mutalisks will be as successful as overconfident mutalisks in harassment; they may pull back too early when they can’t win outright.

I haven’t measured the run time yet, which will be a crucial test. I hope the new version will turn out to be faster. Some day soon I will probably put up a test version on SSCAIT to see how it performs in the wide world. If I don’t hit any surprises, I may switch to the new SparCraft even if the remaining bugs don’t get fixed.

Randomhammer earned another upset, this time with protoss against Iron. The game is not too interesting, just a dark templar rush that Iron wasn’t ready for. Iron could have held by landing its barracks to close the wall until mines and turrets were done, but didn’t. Even so, it shows that Steamhammer can defeat any opponent with any race—at least occasionally when it gets lucky.

Two surprise upsets today caught my interest.

new from MadMix

The game MadMix by Oyvind Johannessen vs McRave surprised me.

McRave fell out of the top ranks a while back, but has lately been climbing back up. I’m guessing that some new subsystem was switched in a while back, and it has taken this long to work the bugs out. After a long drought and a bunch of tries, the new version of McRave notched its first recent win versus Steamhammer today (and another shortly after). I expect McRave will keep rising and return to the top 5 before long.

MadMix is brand new, but already has a big update. The initial version made most units for all races, but never researched upgrades or tech. Today’s version researches most upgrades and at least some tech, so the mix is even madder!

In MadMix versus McRave, random MadMix rolled zerg and started off with fast lurkers. McRave is much higher ranked and has a better build order, better tactics, and better micro. McRave had a vastly superior force in the early game, but for some reason chose not to engage—mistake #1. When the lurkers came out, McRave had no detection and was contained despite MadMix’s poor combat skills.

MadMix slowly expanded to many bases while McRave was contained. McRave made a robo facility but never added an observatory, so it had no detection—mistake #2. I’m sure it’s an oversight or bug and will be fixed before long. McRave still could have made a nexus at its natural, added cannons for detection, and maintained a chance to win, but instead when the protoss main mined out, McRave resorted to long distance mining—mistake #3. Even so, McRave’s macro was stronger and the protoss army remained dominant. In smaller attacks, MadMix retreated support units and unburrowed lurkers each time targets moved out of range, so the forward lurkers tended not to live long. For a lurker, staying underground and restricting your enemy’s mobility can be more important than having a target.

McRave was strangely passive this game, moving its army mostly in response to immediate threats. With zerg on many bases and protoss long distance mining, the writing was on the wall. Eventually MadMix started mass attacks and broke through to win. The picture is from shortly after MadMix’s army first became the larger one (notice the worker counts). In the upper left you can see lurkers holding an isolated protoss force at bay; for some reason, MadMix made better use of its lurkers during the breakthrough attack.

The upgrades tab shows that MadMix did a ton of upgrades this game, even overlord sight range. You can see scourge, and offscreen is a devourer, even though McRave never made an air unit. The zerg unit mix is genuinely mad. It did not make queens, which may mean that it realizes it needs to know how to use the spells first.

Maybe another update soon will see MadMix using most tech, too. In any case, MadMix is already ranked higher than Travis Shelton, the other random bot with a wide choice of units.

Randomhammer gets a win over Krasi0

Randomhammer scored an upset win over Krasi0 with a vulture drop. I knew the drops would pull some good wins.

Randomhammer (this time) sent its dropship the short way around the edge of the map to Krasi0’s base. Randomhammer’s vulture micro was disappointingly poor, but even so the drop was moderately successful; it killed few SCVs, but stopped mining for a surprisingly long time as Krasi0 cautiously backed away.You can see in the production tab that Randomhammer is expanding and adding units while Krasi0 is producing nothing.

Krasi0 may have seen the building starport just before its scout was chased away by marines. In any case, it made goliaths with a few tanks mixed in, a good counter to the air units and vultures which were the only units it had seen indications of. But Randomhammer immediately switched to tanks (it’s a hardcoded tech switch—Steamhammer’s terran and protoss strategy is ultra-simple), and expanded not once, but twice.

Krasi0 delayed its expansion and did not have enough gas to make many tanks alongside the other tech it wanted. With 3 geysers, Randomhammer had greater tank numbers and was able to push through and win despite Krasi0’s superior tactics and unit control. Knowing how to position tanks on high ground is great, but if you have 2 tanks versus 6, it’s not great enough.

Why doesn’t this version of Steamhammer ever play its 5 pool on SSCAIT? I found a bug in parsing the configuration file.

There’s a bug in parsing a strategy combo which is nested inside another strategy mix. The syntax as I intended to implement it is inconsistent, and the parsing code only partially takes that into account.

In Steamhammer as configured, the effect of the bug is that whenever it should play 4 pool or 5 pool, it plays its default 9 pool speed instead. In other words, there’s not much difference, but it does reduce the bot’s unpredictability a little. In a bot with a different configuration, the effect might be worse.

the fix

If you are using the code, the fix is to make the syntax consistent.

1. In ParseUtils::ParseConfigFile(), make this snippet of code look like this. All you have to do is change "StrategyMix" to ourRaceStr in 2 places.

			// If we have set a strategy for the current matchup, set it.
			if (strategy.HasMember(matchup) && _ParseStrategy(strategy[matchup], strategyName, mapWeightString, ourRaceStr, strategyCombos))
			{
				Config::Strategy::StrategyName = strategyName;
			}
			// Failing that, look for a strategy for the current race.
			else if (strategy.HasMember(ourRace) && _ParseStrategy(strategy[ourRace], strategyName, mapWeightString, ourRaceStr, strategyCombos))
			{
				Config::Strategy::StrategyName = strategyName;
			}

2. Make the matching change in the configuration file. Everywhere it says "StrategyMix", change it to the race of the bot at that point, like "Zerg". It’s redundant, but it’s the same syntax for strategy mixes no matter the context.

Two strange events.

let’s put the expansion right there

In a game versus Krasi0, Steamhammer decided to go three hatcheries before spawning pool. It’s a greedy opening, a sensible choice against Krasi0’s slightly less greedy opening. Of course, when you’re trying to win by greed you tend to scout late, so when it was time to place the 3rd hatchery, Steamhammer did not know where Krasi0 was. The expansion drone walked past a bunker under construction and started the hatchery in the terran natural.

Steamhammer had the good sense to cancel the morphing hatchery before it died, but still.... Opening build: Failed.

When the enemy base location is unknown, MapTools::getNextExpansion() is supposed to choose the free expansion closest to home by ground distance. It should have chosen the 6 o’clock base, not the enemy natural. It’s a bug.

wait, is this the same game again?

Steamhammer played against Microwave 2 times in the last 2 days: Yesterday’s game and today’s game. Both games were on the map La Mancha, which is a little surprising since there are 15 maps. Both games had the same positions, Steamhammer in the upper left and Microwave in the lower left. OK, it could happen sometimes. And in both games, Steamhammer played its overgas 11 pool opening, a risky opening that it is set to play just under 1% of the time.

That does not happen! This is a coincidence that should come up 1 time in 18,000, more games than Steamhammer has played. Did somebody take control of the random number generator?

Microwave was blue in both games, but Steamhammer got different colors. Whew. The games were similar, as you might expect. Microwave played overpool and was almost but not quite able to capitalize on its earlier zerglings...

... then lost to the fast mutalisks that Steamhammer got by going gas first.

A third game today between the two bots was completely different. That’s how it’s supposed to work.

I rather like Arrakhammer. It quickly differentiated itself from its parent Steamhammer and now plays quite differently. And its strategies are logical.

Look how Arrakhammer defeats Wuli: It holds off the raging zealots with mass sunkens and no units, objectively poor but perfect against Wuli. Then it techs up to hydra-lurker. Wuli is unable to cope with the lurkers and falls over.

XIMP by Tomas Vajda follows the same abstract plan of holding off the enemy with mass static defense and following up with tech units that the opponent cannot cope with. Some similar plan probably works against most non-adaptive bots (it might fail against bots which always make tanks or other siege units). The plan seems so general and effective that I’ve been thinking of coding it into Steamhammer as a use of opponent modeling. When Steamhammer realizes from experience that the enemy bot has a fixed unit mix, it may build mass static defense while it techs up to a countering unit mix.

overhatch versus overhatch

Arrakhammer is based on the previous, 1.2.2, version of Steamhammer, which did not have the overhatch opening yet. But the author has not been shy about looking into the newer 1.2.3 version. Here in Arrakhammer versus Steamhammer on Icarus, Arrakhammer borrows the overhatch opening and tries to tweak it for an advantage over Steamhammer’s variant of the opening.

The openings are identical up to supply 15. Steamhammer spent its first 100 gas on zergling speed, since it was playing a zergling opening. Arrakhammer instead started a lair and added a sunken to hold the zergling pressure. It’s not the natural way to play the opening, but it is a logical attempt to cross up an opponent that is committed to zerglings.

The plan commits Arrakhammer to defense until mutalisks come out, so it brought its zerglings home even before the sunken was started. Steamhammer had made 2 zerglings more (which didn’t matter because they were far away) and Arrakhammer lost 3 as they retreated up the ramp (which did matter). Unfortunately, Arrakhammer defended inaccurately and lost 2 drones, a severe loss. You can see the orange zerglings out of position in the picture. Good defense could have saved all drones.

Play was left, but in the next zergling attack Arrakhammer pulled drones too far from the mineral line (a classic Steamhammer blunder) and lost 5 more. After that it was irrecoverable. A picture of the drone blood:

The opening try was logical and it could have won if Steamhammer had made the mistakes, or had chosen an inappropriate build. Its weakness was that it depended on correct defense. Bots are strong in attack and weak in defense; that is why Steamhammer is aggressive whenever possible. As defense grows stronger, a wider range of strategies will become practical.

Steamhammer repeatedly threw away zerglings trying to approach the sunken and made other mistakes, but its advantage was unbreakable and it finally won by getting mutalisks first.

As some people have noticed, Steamhammer’s “secret weapon” ZvZ opening, which when I first tested it scored overwhelmingly against all opponents including Steamhammer itself, is simply overhatch.

Overhatch means making up to 9 drones, spawning an overlord, and then starting a hatchery while still on 9 supply. Steamhammer’s version is overhatch 9 pool 9 gas (with drones in between buildings), parallel to its faster 9 hatch 9 pool 9 gas build. The overlord lets zerg get in a couple extra drones, so that when the spawning pool finishes the bot has 10 drones and can immediately spawn 8 zerglings. The timing is fast enough to hold off 5 pool except on 2-player maps. It puts the player in a reasonable economic position (by ZvZ standards), but also commits to zergling-heavy play because the lair will be later.

Overhatch is a rare opening and it is not written up on Liquipedia, and that is for a good reason: It is dominated by 10 hatch. In a ZvZ 10 hatch opening, you go up to 9 drones, spawn an overlord, and do the extractor trick to get a 10th drone. The 10th drone can mine for a while before minerals are available to morph the hatchery, so 10 hatch is always ahead of overhatch in minerals. There is no disadvantage to 10 hatch; it can only be better than overhatch (though only by a little). Steamhammer plays overhatch because it still does not work around the extractor bug (I have more important bugs to fix first).

results

The opening is strong against bots. Results on the SSCAIT server have been good, though less convincing than my original tests.

Steamhammer has lost several games by failing to build an extractor when it came up in the build order. It is a bug that I didn’t see in testing and haven’t solved. For some reason it hits overhatch much more often than other builds.

Steamhammer has also lost a game to Microwave’s 9 pool and another to Dawid Loranc’s 5 pool. Steamhammer’s zerglings were in time to defend with correct play, but Steamhammer pulled its drones too soon and lost some. It’s a severe defensive error. At some point I will teach Steamhammer how to defend with a drill, and then these losses won’t happen.

Steamhammer has also lost occasional games to strong opponents like Killerbot by Marian Devecka due to tactical errors. It does win most, though, even against opponents like Arrakhammer that know about the overhatch opening and are prepared to meet it.

counters

Like every opening, overhatch can be countered provided you know it is coming: You can safely open 12 hatch to end up equal in hatcheries, ahead in economy, and behind in nothing important. So Steamhammer doesn’t play overhatch every game. Steamhammer is set to play overhatch in half of games. Its other openings counter 12 hatch, which is a slow and risky opening in ZvZ. The random openings ensure that no opponent build can give a sure win; opponents have to either play better or get lucky.

If you want to counter overhatch safely, Liquipedia suggests that 12 pool gives a slight advantage. 12 pool is a safe ZvZ opening if played well. But I learned by experience that it is tough to teach a bot to play it well.

other matchups

The classic use of 10 hatch is in ZvP, where in old days it was considered a strong counter to 2 gate zealot play. 2 gate play is popular with protoss bots, so I tried overhatch against protoss too. It seems effective. I think it is doing better than overpool, which was already successful.

In ZvT, Steamhammer up through the current version has always played either zergling openings with heavy early pressure, or mutalisk openings with minimal zerglings and a heavy air attack. Thinking it through again after working on surviving early terran attacks, I decided to add a compromise opening for the next version. I picked an overhatch opening with early zergling pressure followed by a later, lighter air attack, at the cost of a weaker economy in the long run. I think it is objectively worse, but other zerg bots have been successful with similar approaches and it may work well against bots. It’s an idea that should be tried.

Tomorrow: Arrakhammer’s attempt to counter overhatch

Progress has been delayed by exhausting events in some kind of “real world” that I don’t fully understand. But whatever, it’s only a temporary distraction. A public repository should be up soon-ish; I have made some decisions but not all.

After that I will be, as anyone could have guessed, splitting versions again. I was planning for the next version 1.2.4 to be a mass bug fix release, but with the new SparCraft out, that doesn’t seem like the best plan.

• 1.2.4 - I’ll try the new SparCraft and incorporate it if it seems like an improvement. I expect it to be. Besides that, I plan to work on about a half dozen of the most critical bugs and weaknesses.

• 1.2.5 - Fix as many of the remaining bugs as possible. My list is way longer than I can get through.

• 1.3 - Start on opponent modeling.

I promised some form of opening learning or other opponent modeling for CIG 2016, and it is coming up fast. I have to get onto that soon and delay mutalisk work yet again. I regret the delay, because mutalisk micro is a key zerg skill and all bots are clumsy at it. When I finally get it implemented, terran bot authors in particular will be dismayed to see how hard mutalisks can hit when they are Less Stupid. But opponent modeling is also key.

I have already implemented a couple of fixes to regrouping. I corrected a conceptual error in weapon ranges versus ground distances. It remedies one case of mutalisks holding their position while under enemy fire, as well as less visible but related misbehavior. Also medics retreat with their squad when they should, instead of staying behind to “hold off the enemy while you escape.”

If I ever want to finish ahead of tscmoo in a tournament, zerg will have to learn how to survive terran early pressure. To make testing easier, I added a terran BBS opening. Like Tyr’s, it defeats Steamhammer’s mutalisk openings 100% of the time. So far, my attempts to react to it are too slow and zerg still loses. The BBS is so effective that I could not resist adding a “go pull workers” command to pull SCVs into the combat squad and make it even more vicious. Now it is easy to write all-in strategies like Oleg Ostroumov’s marine-SCV attack, or the zealot-probe all-in that Pinfel used to play.

Here’s a curious point about Steamhammer’s ZvT and Tyr by Simon Prins. Tyr has opening learning, and center map BBS is its answer to bots which don’t defend themselves early. The BBS has always beaten Steamhammer’s mutalisk builds and lost to its zergling builds.

In the past, Tyr has tried BBS against Steamhammer and given it up after a while after losing; it concluded that a regular opening was better. Past Steamhammer versions played zergling openings 25% of the time, which was apparently enough to deter BBS even though Tyr’s slower play didn’t consistently win 75% of the time (it varied by version).

This Steamhammer version plays zergling openings ZvT 20% of the time, because the mutalisk openings are improved more (that was my thinking, at least). Tyr apparently detected the shift in game results, and now it plays BBS every game and wins 4 out of 5, a huge upswing. Can improved play can lead to worse results when it highlights remaining weaknesses for the opponent’s learning to exploit? It could also be because Tyr was updated recently. Or it could be a chance change due to the interaction of opening learning, random choice of builds by Steamhammer, and historical changes in Steamhammer’s performance.

To fix the weakness I thought of a simple adaptation, and I hope to try it out in an upcoming version. Steamhammer is prepared for early pressure versus zerg or protoss opponents, but against terran it tries to exploit the tendency of most terran bots to sit back and macro for a while. So it only has to adapt in the case of early marine pressure, as played by Tyr (with BBS) and the latest tscmoo (with an academy rush) and a number of weaker marine bots like Kruecke and KaonBot. Steamhammer should have better chances to survive if it breaks out of its prepared build when it recognizes the early pressure, and lets the strategy boss do its default thing. I doubt my simple idea is good enough by itself for all cases, but I’ll try it.

The new Steamhammer 1.2.3 zerg plays slightly but distinctly better than the previous version. It’s worse on some points, like focussing the attention of its mutalisks, but better on enough others to make up for it. The overall result is a small but clear bump up.

The new Randomhammer plays worse than the test version of Randomhammer, and I don’t know why. Apparently I did something harmful in the last week of development, and I can’t figure out what. I worked through the list of items I changed that week, and I don’t see a problem with any of them. But there must be one. Has anybody noticed something?

It’s possible that the unknown problem affects zerg too, and zerg could be even stronger if I fixed it.

BWAPI 4.2.0 was released on 28 April. I have been thinking about when I want to switch over to it, and I haven’t decided.

Sooner? 4.2.0 fixes the zerg hive research bug, which pinches zerg strategy. The hive bug is nasty, so that counts for a lot. Code changes to switch to 4.2.0 seem minimal; I would want to revise the bits of the zerg strategy boss which encode the buggy tech tree. Dave Churchill has already switched UAlbertaBot over, so any problems should be minor. 4.2.0 supports Visual Studio 2017, so people wouldn’t suffer from old development tools. And of course there are various other improvements and fixes, and it’s common sense to stay as up to date as possible.

Later? Will competitions support 4.2.0? I wrote to the CIG 2017 competition organizers to see whether it would be supported in their tournament. The lead time may be short for them. We’ll see what they say. Also, given my development plans (fix bugs, work on mutalisks and opponent modeling), switching libraries would be overhead that slows me down for the moment. I’m not looking forward to switching to a new toolset when I’m still getting used to the one I’m using.

What do you think? Anybody have thoughts or experience?

Update: As Ailien points out in a comment, if you use BWTA you have to update it at the same time, and no new BWTA release is out yet. All DLLs have to be compiled with the same toolchain, per Microsoft. It may work if you compile BWTA yourself from source with vs2017 (no promises, I haven’t tried it). For BWEM, Igor Dimitrijevic suggests integrating it into your source code directly. If you did that, then it presumably does not have the same issue (I didn’t see any map-related changes in the BWAPI change list).