Starcraft AI blog

“Somebody” voted in a bunch of Steamhammer versus PurpleWave games. PurpleWave played different openings. Past versions of PurpleWave dominated Steamhammer with the forge-expand opening, taking advantage of Steamhammer’s mistaken macro decisions and weak scouting and tendency to collapse tactically in a big fight. But this PurpleWave has been losing some; it has new weaknesses. So the games are not the best, but they are still interesting.

Some of the games were proxy 2 gates. There were wins and losses, but I found those games not as interesting.

on La Mancha

This is the Steamhammer-PurpleWave game that Nepeta cast last Sunday, so I won’t go into detail. PurpleWave suffered bugs that caused it to warp buildings near the zerg forces and pull probes for no reason, so it did not develop its usual big advantage. What I find interesting about the game is the turning point, when zerg pulled decisively ahead: It was when protoss attacked the zerg natural and dealt great damage, destroying the drones.

The returning zerg army finally cleared the attack. The protoss army was trapped and could not retreat toward home. It should have “retreated” into the zerg main to try to deal more damage (and to pull the zerg army away from the front), but instead turned fatalistic and gave up without a fight. Meanwhile, zerg had many drones at other bases and quickly restored the losses, while the lost protoss army was not as easy to replace. The value of destroying drones depends not on the number of drones you kill, but on the number that survive somewhere....

on Icarus

This game was also a forge-expand, but the play was quite different. No obvious bugs bit. PurpleWave built 4 cannons, which is plenty for most circumstances... and Steamhammer busted them anyway.

Steamhammer killed probes too. Then I tore my hair out in frustration, because instead of pressing for the win, Steamhammer decided it was more important to simultaneously plant a spire, hatchery, evo chamber, and hydra den, and also grow its economy. Notice in the picture that, although Steamhammer has spent 4 drones on buildings, it is still ahead in workers—and PurpleWave has cautiously pulled probes for defense. The spire, by the way, was left unused until late. With 2 bases, PurpleWave eventually caught up from far behind and the game was on again.

Fortunes turned again, like last time, when PurpleWave overpressed and lost too much army at Steamhammer’s natural. Seconds after this picture, protoss went from ahead in army size to well behind. Zerg quickly replaced drone losses and soon broke into the protoss natural in return.

on Destination

PurpleWave went 2 gate zealots into expansion. Neither bot had much understanding of the situation. Steamhammer massed lings, an all-in play to smash the opponent. In practice it’s successful against most bots, but zerg ends up way behind in economy. Protoss can play defensively for a while and then win easily—that’s how Tyr protoss beats Steamhammer.

The game is not long or exciting. PurpleWave expanded in the face of the zerg swarm and did not have enough zealots. I include it to show how little bots understand strategy. In the picture, Steamhammer has half the workers of protoss. With any insight into the army-economy balance, you have to conclude that it is not a time for protoss to take a risk like expanding or moving out. The zealots again went fatalistic; as soon as they realized that they had lost, they stopped fighting and (unable to retreat far) were caught and died. You can also see that in the picture. Steamhammer has related weaknesses that are different but as severe.

PurpleWave might have had a chance if it retreated to the ramp and canceled the nexus. It was the best option, at least.

I expect that PurpleWave will fix its bugs before long and start winning again.

Next: More games, versus McRave and KillAll.

Back in an early Steamhammer release, I tested stealing gas, concluded that it worked, and called it good. Since then I haven’t paid much attention.

Now I’m working through systematically to make sure that stealing gas always works when it should, and that it interacts correctly with scouting (which has grown more complicated since then). While I was looking away, the gas steal bitrotted as its surroundings changed and it did not keep up. For example, in testing with terran today I fixed a bug where the scout arrived at the enemy geyser, queued up a refinery on it... and then BuildingManager assigned a different worker to do the job, sending an SCV from the main. I even found and fixed a potential crashing bug, though it could only happen on very nonstandard maps.

Next: Steamhammer vs. PurpleWave games.

When I first promised Steamhammer-Tscmoo games, Steamhammer had been winning most games against Tscmoo terran, despite dangerously aggressive terran play. Some of the games were good. Since then, Tscmoo has been updated, and now most of the Tscmoo bots (all except protoss) are ranked just above Steamhammer. Games have gone both ways, but I think Tscmoo has the edge overall.

a September game

In this game on Roadrunner Steamhammer played a 3 hatch lurker build that was a direct counter to Tscmoo’s fast academy. If zerg had played accurately, it would have been an easy win. As it was, zerg was unclear on the concept of defense and narrowly held by accidentally making just enough zerglings in a hardscrabble game. If Steamhammer had played a mutalisk opening, it would have lost, because the muta openings make fewer lings. Here Tscmoo’s last attack has broken through and the small terran force is frying drones—most of the drones in the picture died.

But lurkers were already out, and Steamhammer broke the attack with a hammer blow and then turned the hammer outward.

a recent game

Lately, Tscmoo terran has been playing sequences of tricky tech switches. Tscmoo played random on Destination in this game and got terran. It’s a 2 player map, and terran started with a barracks on 6 hidden in the corner of the zerg natural out of sight of the scouting drone, an early proxy that could be deadly. Luckily, Steamhammer tries to be ready for anything against a random player, and it opened with a safe overpool. Tscmoo in turn scouted Steamhammer’s safe opening and opted not to train marines right away (they would have died uselessly), but to move on to the next tech.

Early zerglings still did not spot the barracks. Tscmoo made marines in time for Steamhammer’s expansion; it may be a coincidence, but maybe Tscmoo is smart enough to know the timing. In any case, as you can see from the unit counts, zerg was more than prepared.

Most of Steamhammer’s lings went to the terran main, as you can see in the minimap above. Tscmoo has strong worker defense, and the fight was not entirely one-sided. And of course Tscmoo had been preparing its next tech, vultures. When they were done, the vultures chased the lings out. Steamhammer knew what was coming, though, and put down a sunken in its main for safety, and one in the natural a little later when the natural finished. The vultures also did not achieve much.

Meanwhile, Tscmoo started a starport, the next tech switch. Steamhammer saw that too and put down a hydra den while trying to catch up in workers; despite killing a few SCVs, zerg was behind because it had made too many combat units. But instead of putting on wraith pressure, Tscmoo made an extreme move while waiting for wraith cloak research to finish: It added a tank (without siege) and pulled almost all its SCVs across the map for an all-in attack.

Steamhammer knew how to defend this one. Zerg made an emergency switch to mass lings with a few hydras, and with the help of the sunken the attack was beaten back with heavy losses. Zerg went from behind to ahead, plus Steamhammer started a spire and was able to safely return to droning up. Zerg had wasted money on lurker research, but it no longer mattered.

Tscmoo finally pulled the wraith switch, but the long delay meant that Steamhammer was again ready. The first wraith was able to kill a couple drones before scourge hatched. The wraith instantly cloaked when it saw the danger, but cloak is no use when you have chosen to fly right next to an overlord.

Steamhammer realized, more slowly than it should have, that mutas were the right choice, and brought pressure back to the terran. Tscmoo switched again, to valkyries for air defense, but zerg scourged most of them and terran could not hold the line long enough to build a stable force. (If it had, Steamhammer was still ahead and I think it would have switched to hydras and won anyway. It knows how.) Here scourge are intercepting the first valkyrie—by coincidence, the scourge were waiting by the starport (someday I’ll add code to do that on purpose).

I think Tscmoo showed greater ability, but it took big risks which did not pay off in this game. The SCV pull in particular was not a smart plan. Even so, you can see how easily zerg could have made a mistake and lost; Tscmoo earned its high place in the ranking.

Here’s a human game with a similar sequence of terran tricks: July vs Firebathero from 21 September, on the map Hitchhiker. Firebathero’s sequence of bunker to vultures to wraiths is 100% standard. July was ready and had some zerg tricks in response. Even if you don’t have much Starcraft expertise, it should be easy to see that this game is on a way higher level than the bot game.

A quick note: I finally got devourers working sort of OK in the development Steamhammer. They are no longer horrible and useless as in the live version. Of course this means that I instantly get new items on my to-do list, like “teach other units to target enemies that carry acid spores” and “teach FAP about the effects of acid spores.” One step at a time!

As a side effect, corsairs and valkyries are also better. The corsair-dark templar opening is improved to the point that it is... not good, but within shouting distance of acceptable. The work was a combination of bug fixes, improved tactics, and adding a new MicroAirToAir unit controller for the air-to-air splash units.

Change of plans. I solved a bug that others should know about, so Steamhammer-Tscmoo games will wait until next time.

Steamhammer has a bug that shows up when a lurker starts attacking a building: The lurker becomes unable to switch targets until the building is destroyed. So, for example, if a lurker doesn’t see any other immediate target, it will go after a supply depot. Once it has started in on the depot, marines can wander up behind the lurker in perfect safety, and perhaps scan and kill it. Until the depot is destroyed, all the marines have to do is stay out of the line of fire between the lurker and its target.

The bug is not in targeting. MicroLurkers correctly recognizes that the marines are higher priority targets and issues a command to target them. The bug is that Micro::SmartAttackUnit() does not act on the command. The code is inherited from UAlbertaBot, so probably many UAlbertaBot and Steamhammer forks have the same problem. Here is the inherited code:

// if we have issued a command to this unit already this frame, ignore this one
if (attacker->getLastCommandFrame() >= BWAPI::Broodwar->getFrameCount() || attacker->isAttackFrame())
{
    return;
}

I think the isAttackFrame() test may be a good idea if you are controlling, say, a dragoon. Retargeting a dragoon while it is in the middle of its animation will at best cause extra delay before the dragoon can fire again. But when I looked closely, it turned out that for a lurker attacking a fixed target every frame is an attack frame. Steamhammer drops the command because the lurker is constantly attacking.

Instead, it should accept the slight delay of retargeting lurkers. I rewrote it like this:

// Do nothing if we've already issued a command this frame, or the unit is busy attacking.
// NOTE A lurker attacking a fixed target is ALWAYS on an attack frame.
if (attacker->getLastCommandFrame() >= BWAPI::Broodwar->getFrameCount() ||
    (attacker->isAttackFrame() && attacker->getType() != BWAPI::UnitTypes::Zerg_Lurker))
{
    return;
}

Lurkers behave better, and other unit types are not affected. I see improved lurker micro in test games.

In Starcraft, every unit type behaves differently. UAlbertaBot, and therefore Steamhammer, tries to treat different unit types the same, which is sure to be causing other weaknesses. At some point I will analyze micro thoroughly and make sure that every unit type realizes its potential. For now, I’m happy that lurkers are a little smarter.

Apparently I fixed enough bugs and added the right features to Steamhammer, because the bot is doing well on SSCAIT. It’s ranked #5 right now, high up in the mass of bots in the 2200 range. This Steamhammer version has negative scores against Krasi0 and Iron, and against several protoss bots—and that’s all. It is equal or winning in head-to-head score against every other opponent it has faced on SSCAIT, including all other zergs.

I don’t expect to do as well in AIIDE, because there are unfamiliar opponents that I can’t prepare for. But I hope to finish fairly high.

The upcoming 1.4 version has changes to improve results against protoss. The following version 1.5 plans mutalisk skills beyond other bots, which will be especially dangerous to terran. It should be able to notch some wins against Krasi0 and Iron. But it will take time, and everybody else is improving too....

Next: Games versus Tscmoo.

I have improved Steamhammer’s early game scouting and added midgame scouting. It’s far short of human scouting skill, but much improved. The first overlord and the drone scout cooperate to locate the enemy base as quickly as possible, and the overlord moves there to watch as long as it can. I also taught it to notice the enemy’s overlord and try to infer the enemy’s base location (ZZZKBot is the only other bot that I know has that skill). The effect is that Steamhammer finds the enemy sooner and collects more information. The midgame scouting ensures that enemy expansions are found, and in my testing often destroyed quickly.

I already find it hard to watch the release Steamhammer play on SSCAIT, since the new one is so much less clumsy at finding things. I think that Steamhammer 1.4 will be stronger than the current Steamhammer even with opponent modeling turned off, because of the improved scouting, slightly more flexible tactics to take advantage of the improved scouting, and a couple of key bug fixes.

It still doesn’t overlord scout versus terran, though. It has no concept that marines are dangerous or that cliffs are useful.

Overlord scouting, by the way, is a deep topic. Pros often send their first overlord straight to the closest possible enemy natural base. But they sometimes move the overlord on a complex path, trying to catch proxies, or avoid the enemy scout, or spot activity without being seen, or just to stay flexible so the overlord can move to its choice of locations depending on the situation. An overlord that always follows the most efficient scouting path is predictable, and the enemy may be able to save time by scouting for your overlord instead of directly for your base.

Steamhammer and Microwave are both rated close to 2200 at the moment, putting them in the top ranks on SSCAIT. There is a big pileup at that skill level; only Krasi0 and Iron are significantly stronger. And yet a few days ago, Steamhammer and Microwave struggled against each other in a game with so much nonsense play that I was raging at them the whole time, sitting on the sofa with a laptop and shouting “Why are you doing that? DON’T DO THAT! Aargh!” Facepalm. There is so far to go.

It had better be true that you learn the most from mistakes, because there are a lot of painful mistakes here that are hard to look at.

The game is Steamhammer vs Microwave on Icarus. Steamhammer opened overlord, then hatchery, spawning pool, and gas all on 9/17. Microwave opened spawning pool on 9 and gas. Steamhammer’s worker defense is poor and the 9 pool will win if Microwave sends its zerglings immediately in the right direction. Microwave scouted with a drone and found Steamhammer’s base on the second try, which was too late. But Steamhammer's zerglings were distracted by the scouting drone, and Steamhammer did well to survive with 2 drones lost. Microwave could have won on the spot if it had scouted with an overlord, or if it had inferred Steamhammer’s base location when it saw Steamhammer’s overlord.

Steamhammer continued to chase the scouting drone. Urgh. The misbehavior is still there because I haven’t found an easy way to prevent it that doesn’t cause other bad behaviors—if it ignores the scout, that’s bad too. My plan to fix it requires time and care, so I’m putting it off for now. Anyway, moving the zerglings out of position offered opportunities to Microwave to stab into the mineral line, but Microwave played overcautiously and did not. Aggressive play would be to rush all zerglings in to wreak havoc, then try to escape when Steamhammer reacts, so that you don’t lose to the counter. Safe play would be to detach 2 to 4 zerglings to try to catch a drone, while keeping the others back for defense; if the raiders are surrounded and lost it is no terrible setback, and if they kill a drone that is an edge.

Steamhammer finally killed the scout and started to realize the advantages of its build. With 2 hatcheries from the start, it was far ahead in zerglings, and Microwave was forced into static defense. Microwave added 2 sunkens in its main... and expanded, so then it added 2 more sunkens at its natural. 4 sunkens are a fatal expense, and Steamhammer was miles ahead. In the picture, Steamhammer has so many more zerglings that it should have attacked immediately.

There are a lot more mistakes in the rest of the game, but the story is getting tiresome. Steamhammer refused chance after chance to widen its lead or win outright. It held back when it should have attacked. It built an ultralisk cavern and researched the expensive ultra upgrades, then did not build a single ultralisk until they lost their value. It made guardians and devourers and used them wastefully (partly because it hit a bug which assigned units to the wrong squads). It became so lax in applying pressure that Microwave caught up in economy. You can watch the end of the game yourself, if you can stomach it.

It was much smoother than past Steamhammer games that I have blogged as disastrously bad. The bot is slowly getting more solid.

Today I solved a major cause of production freezes. Steamhammer did not understand that repeated upgrades increase in cost, and I didn’t register that BWAPI requires you to specify the level of upgrade to get the prices of upgrades above level 1. So if Steamhammer wanted to upgrade zerg carapace +2 (gas cost 225) and had 200 gas, then if gas collection was turned off it would never turn gas collection on. It concluded “the upgrade costs 150 gas so I have enough.” The upgrade sat in the queue waiting for enough gas to appear, and the gas never appeared.

I think it’s the most common permanent production freeze remaining in the live version 1.3.3. Most long-lasting production freezes happen when gas is turned off and stays off.

The fix is to add code to MacroAct::mineralPrice() and MacroAct::gasPrice(). I verified that all upgrade prices are fetched via MacroAct; prices that it fetches directly are always for units or buildings, which are constant price. I added this code to MacroAct::gasPrice() (and similarly for the mineral price):

	if (isUpgrade())
	{
		if (_upgradeType.maxRepeats() > 1 && BWAPI::Broodwar->self()->getUpgradeLevel(_upgradeType) > 0)
		{
			return _upgradeType.gasPrice(1 + BWAPI::Broodwar->self()->getUpgradeLevel(_upgradeType));
		}
		return _upgradeType.gasPrice();
	}

Finally! I didn’t trace all the consequences, but the fix probably corrects other bugs too.

I’m working on version 1.4 now, and the major feature in version 1.4 will be opponent modeling. But after the AIIDE rush I felt tired of opponent modeling, and discouraged by the bugs, so I’m improving scouting first. Good scouting is important for opponent modeling to work well, so I’m happy to do scouting in the same version. No more rush; I will take my time and do it right.

I added a Recon squad that scouts around with ground units in the middle game, as soon as there are enough ground units to spare a few for scouting. It doesn’t search efficiently, but it does catch enemy expansions sooner or later, and sends eyes around the map to places Steamhammer used to ignore. I also made a small tactical change so that the attack squads are less maniacally focused on the enemy main base and more willing to attack other bases. Besides improving opponent modeling, I think it should help directly against most opponents that try to mass expand or to hide expansions.

I also refactored code so that I can work on overlord scouting. The first overlord will coordinate its movement with the scouting drone. Currently, if Steamhammer sends out both its first overlord and a scouting drone, they both head for the same base. It’s disgusting, but it has been that way since December when I first hacked in crude overlord scouting. Overlord scouting in 1.4 won’t be a polished gem, but it shouldn’t be a dirt clod any more.

I’m also making the usual random improvements here and there to things I come across. I finally realized why Steamhammer keeps making guardians against XIMP by Tomas Vajda: It doesn’t recognize that corsairs and carriers counter guardians. Oops. I left out that bit of knowledge and only now caught the mistake.

biggest weaknesses

The worst news is Steamhammer is doing poorly against the top protoss bots lately, for two reasons. First, some are using multiple strategies, and the current Steamhammer’s random openings cannot counter all of them. Opponent modeling should help. Second, protoss is often playing forge expand or other big macro openings, which Steamhammer only partially understands. Opponent modeling will again help, because then Steamhammer should usually be able to find good strategies in response, instead of only occasionally. But opponent modeling won’t be enough (unless it sticks with timing attacks like hydra bust), because Steamhammer’s tactics tend to break down in a big macro game. To have the right units at the right time is no help if you throw them away. Fixing tactical play, the way I intend to do it, will be another major feature.

In other words, I expect to have to finish 2 more major features, opponent modeling and tactical analysis, before Steamhammer can score consistently against top protoss bots. It won’t happen soon. Opponent modeling is underway, but tactical analysis likely won’t be until next year.

I will be able to make progress on small features. The 3 biggest weaknesses that can be corrected with minor features are:

1. Better worker micro. Drills would help in a lot of defensive situations. Even without drills, better choices about engaging and running away would reduce losses.

2. Run workers away from enemy attacks. It’s a basic skill that top bots have to some degree and Steamhammer doesn’t. Steamhammer not only loses workers in a base under enemy attack, it transfers more to the base to try to keep mining gas. Keeping workers alive would be a big boost to resilience. I will likely stop the transfers as one fix, and run workers away as a later fix.

3. Pathing in the presence of map blocks. Units too often get stuck trying to take a path that is blocked. The work to fix pathing is started, and I see it as related to dropping BWTA. I’ll continue step by step.

I’m not working on any of these 3 at the moment. One goal at a time. In 1.4 I will probably take at least one more step toward removing BWTA.

Steamhammer 1.3.3 is uploaded. Fixing the disastrous “I seem to be making a command center, I’d better cancel it” bug was trickier than I expected. After I did fix it, I saw the game Steamhammer vs AyyyLmao, which was just as disastrous. I had to watch closely to see what happened: At about 1:15 into the game, Steamhammer moved a drone to start its spawning pool, and simultaneously sent out its scouting drone. The scouting drone momentarily blocked the spawning pool from starting, which happens from time to time and causes a slight delay. Not this time, though. The spawning pool was canceled on the spot due to another bug, and Steamhammer’s build order was disrupted. Steamhammer recovered poorly and lost the game against an opponent it should have beaten.

Anyway, I made several tweaks to the rules for giving up on buildings, and I tested more thoroughly with games against a variety of opponents. I think it’s mostly OK now. But the change is more fragile than I realized, and I won’t be surprised if more bugs are lying in wait.

Next: The full CIG 2017 results are posted, but they don’t come with the colorful crosstable (at least not yet). I’ll supply my usual red-and-blue crosstable.

Ack! I fixed one bug that happens when terran gives up on constructing a building, but I missed an even more serious terran bug in the same code. In Steamhammer 1.3.2, terran is unable to build a command center! The bot gives up on the building partway through and cancels it.

See Randomhammer vs ICEbot for an example. Randomhammer expanded late, and ICE had already placed a spider mine at its expansion spot, so Randomhammer gave up on its first attempt as intended. After its vessel came out, Randomhammer eventually cleared the mine and started the command center again—and again—and again, canceling it over and over. Mega ouch! I coded up a quick 14CC opening and verified that the bot can’t finish a command center at all.

The bug is so severe that it deserves a quick 1.3.3 release with a fix. Stand by, I’ll try to get it in today.

Steamhammer 1.3.2 change list. It amounts to the donated openings, 3 fixes for terran and protoss because I only tested zerg in the AIIDE version, and 2 minuscule tweaks to zerg—and of course configuration to play on SSCAIT instead of in the AIIDE tournament. Otherwise it is the same as the AIIDE version.

• New protoss openings from Antiga, donated by Iruian. Protoss play will be more varied and hopefully stronger.
• Version 1.3 had a configuration mistake, when Randomhammer rolled protoss or terran, affecting opponents Dave Churchill (UAlbertaBot) and Andrey Kurdiumov (a UAlbertaBot fork with software engineering changes rather than play changes). It was configured to always play a zerg opening, so when the bot was not zerg, the opening group was not set. Randomhammer played normally... except that it never built a combat unit. Combat units are made depending on the opening group. I corrected the configuration. Also see the next item.
• Added a workaround in case the opening group is not set to a correct value and it needs to be: Set a default opening group when the error is noticed. As it always has, it puts a message on the screen when the error is noticed, so you’ll know what’s wrong.
• The new “cancel a building if it takes too long or if too many workers are lost” feature included a bug for terran. Partly constructed buildings could be left around instead of being canceled. Fixed.
• I changed the formula for making lurkers as aux units, so that Steamhammer makes more aux lurkers. Aux units are extra units added to the regular unit mix. This should improve play when Steamhammer has lurker tech but isn’t using lurkers as a primary unit.
• If there are mutalisks, then devourers go into the flying squad with the mutalisks. They were mistakenly always put in the ground squad. It should improve devourer play, at least sometimes and a little.

Tomorrow I’ll update Steamhammer’s web page with the source. Then I will return to the opponent model.

The biggest new feature in Steamhammer 1.3.2 will be the new protoss openings from Antiga (thanks to Iruian). I sorted the openings into a different order and renamed a few to keep to a more consistent scheme. I’m leaving out the 9-10 gate opening for now; it is only slightly different from 9-9 gate and plays worse because of BOSS, and Antiga leaves it out too.

I’m not straying too far from Antiga’s weights, either. I question some of them, but they are tested and known good and provide variety. I’m making only relatively small adjustments. And that’s the story. It’s taking time to configure and test everything, but I’ll push out the new version before long.

If anybody else would like to donate openings, I’ll include them in the Steamhammer distribution as extras if they are remotely useful. If they’re good, I’ll configure them to play in the live Steamhammer. Since protoss has just been fed, the terran openings are now begging for their handouts.

Someday, when Steamhammer is smarter than now, I’ll build the opening tree and have Steamhammer choose opening lines on the fly. Possibly I’ll have both a concrete tree of macro actions and an abstract tree of strategic plans. At that point, the bot will be able to decide for itself under what circumstances an opening is good, and it will make sense to feed it as many variant openings as possible regardless of quality. I don’t mind accumulating data now for that future day.

Here’s what I found out about Antiga’s donated openings. (Thanks again to Iruian, by the way.) This post is only about the openings themselves. Also donated are weights, how often to play each opening in each matchup, which I’ll consider separately. My plan is to distribute the donated file along with Steamhammer’s source, so that whoever wants to can easily borrow the openings and weights. The openings are good, so I’ll also put most of them directly into Steamhammer’s regular configuration; Randomhammer will play them when it rolls protoss.

Going by names, Antiga’s openings are a superset of Steamhammer’s. But 3 of the openings with the same names are different, so it’s a little confusing.

identical openings

• 1ZealotCore
• DTRush
• DTDrop
• CorsairDT (weak because Steamhammer sucks with corsairs)
• 12Nexus
• 13Nexus

openings new in Antiga

These are good openings, so at the moment I’m thinking I’ll throw them into Steamhammer’s config for active use. The weights are a separate question.

• 9-10Gate
• NoZealotCore
• 10-15GateGoon
• 2ZealotCore
• 2GatewayGoonExpo
• Nexusfirst5zealotExpo

openings that are shared but different

I tested the shared openings by playing them against each other head-to-head. I’ll call it Steamhammer versus Antiga, though both sides were running identical Steamhammer code. I didn’t pay attention to the results of the games, which varied depending on how battles happened to come out. I paid attention to macro: Who had more income, who produced units more efficiently, who was able to expand sooner.

• 9-9 gate The 2 openings proceeded in lockstep until Antiga went out of book. Then Steamhammer’s beautifully optimized UAlbertaBot zealot rush quickly pulled ahead. It evened out somewhat after Steamhammer also went out of book, but not entirely.

• 10-12 gate Steamhammer’s 10-12 gate opening is not as highly optimized. Again the openings were identical until Antiga went out of book. Steamhammer pulled ahead, but not dangerously. I don’t see any big difference in strength between the openings, only a small advantage to Steamhammer’s existing opening.

• ForgeExpand The openings are the same, except that Antiga adds a third photon cannon at the end of the opening. It barely delays the early zealots and dragoons, so I judge it an improvement: Safer and practically as aggressive. I will switch Steamhammer’s opening to this version.

Iruian donated some protoss openings with weights as used in the bot Antiga. I will distribute them with Steamhammer, but I’m still pondering exactly how. The openings are supposed to be straight from Liquipedia, and the ensemble is claimed 50 to 100 elo stronger than Steamhammer’s default protoss openings. I don’t have any reason to doubt it, but I’m still in the process of checking the openings myself.

Unfortunately, there are reasons not to take openings straight out of Liquipedia without testing. Most of Steamhammer’s provided openings are modified from Liquipedia versions, and sometimes the changes are major. (Some were taken from other sources, and a few were developed from scratch, starting with no more than the opening stem and a plan.)

Sometimes Liquipedia is unhelpful, if not outright wrong. I think the 12 pool lurker build on this page is a prime example. It says you should adhere to the build strictly. But if you build everything that the build order calls for, then lurkers are severely delayed, and the build order makes no sense (at least to me); use a 12 hatch build instead. If you minimize the build to get lurkers as fast as possible, then you end up with 4 or more larvas for a long stretch after the second hatchery finishes, meaning that there was no reason to get the second hatchery so soon; you should have stuck with a single hatchery build. Presumably a pro can weigh the situation and decide what extra stuff is good to make, but Steamhammer doesn’t have that skill. So I found the Liquipedia build order unhelpful.

Often Steamhammer plays poorly in the middle game, and the weak play can be worked around or delayed by extending the opening. This is the main reason to deviate from standard builds: Alter the opening so that Steamhammer plays it better.

BOSS is weak, which causes terran and protoss to play poorly after the opening. BOSS tends to build too many production buildings—I often see 6 or 7 gateways on a one-base income that can support 4 gateways, which is wasteful. BOSS also likes to bunch the production of similar things, not keeping the nexus and gateways busy at the same time, but rather “probe probe probe probe zealot zealot zealot zealot”, where first the nexus is busy, then the nexus goes idle and the gateways become busy. It’s crazy inefficient.

That is why Steamhammer’s 9-9Gate opening is so long and detailed. If it ended early like the Liquipedia build, then BOSS would take over sooner and build inefficiently, and the bot would fall behind in probe count and zealot count for the rest of the game. I know this for sure, because I’ve run the different variants head-to-head. Dave Churchill optimized the 9-9 gate opening already for UAlbertaBot, and he did an excellent job. I optimized the 10-12 gate opening myself in a similar way and did not do it as thoroughly; it has room for improvement.

Someday I’ll write a new macro system and drop BOSS, but not yet. I might be able to get to it this year....

Sometimes the middle game strategy decisions are silly. Terran and protoss are especially short on strategy smarts, but the zerg strategy boss also has many weaknesses. In one frustrating example, if the opening build makes a spire but doesn’t make the mutalisks, Steamhammer may decide that lurkers were a better idea after all, get no lair units for a long time, and lose. There are many ways for the strategy boss to misunderstand the strategy behind an opening, so that you have to write a long explicit build order. Some openings I have shortened after improving the strategy boss. Some openings have legacy endings that it might be good to remove.

Anyway, the bottom line is that Steamhammer is not strong enough to play Liquipedia opening builds uncritically. Some are fine, some will confuse the poor bot.

On the other hand, Steamhammer’s existing protoss openings leave a lot to be desired. They’re more a demonstration of what’s possible than a sound selection. It’s no surprise if Antiga’s openings are stronger.

Next: Looking at the donated openings.