Starcraft AI blog

• A medic can blind a zerg egg, and the unit that hatches will be blind. You might have thought that any eyes were hidden away inside the egg.... If 2 zerglings or 2 scourge hatch, they will both be blind. It’s a cute detail that has no practical use whatsoever. Ensnare and other effects work similarly with eggs, but it’s not as funny.

• If a science vessel irradiates a high templar, does the high templar have any chance to live? It could merge into an archon; that saves it. There is another way. If the high templar is next to a full shield battery, the battery has enough energy to save the templar by repeatedly charging its shields (the battery is left nearly empty). I don’t think I’ve never seen a high templar get irradiated in a game. Of course it’s the same for other biological protoss units besides the high templar, but why would you save another unit?

• A medic can heal biological units of any race. Zealots + medics make a fearsome combination. Ultraling + medics is nasty too, but harder to use well; healing close to the 400 hit points of one ultralisk will drain a medic, and the zerglings are too many and don’t stay put. These things come up in some kinds of nonstandard games. One day I wondered, “Wouldn’t medics go best of all with mutalisks?” But it turns out that medics can only heal ground units.

What’s your favorite curious and useless trivia about the game mechanics?

I notice a lot of bot authors want to control each unit independently for micro decisions, to make it an agent with a mind of its own. There are good reasons to write a bot that way.

• It’s simple. Fewer bugs and less implementation effort are strong reasons.
• Being simple, it can run fast.
• Frame-accurate control depends on each unit’s exact state at each frame. It seems much easier to handle unit by unit.
• Units can sidestep the stupidest behaviors, like moving too much without shooting. Each unit can act efficiently under its local circumstances.
• Cooperation: If a squad still gets orders from above, then the squad still acts together for higher-level goals.
• Cooperation: Units can still work together on low-level goals like focus fire by simple means like preferring targets that are already hurt. Cooperation occurs as an emergent behavior.
• Cooperation: At a cost in simplicity and speed, units can look at each other’s targeting and movement plans or expectations, to get more effective focus fire, to reduce overkill, to kite better, and so on.
• And hey, you can call it an agent architecture, which sounds great.

It doesn’t make sense to me. My micro plans in Steamhammer call for reducing the independence of units, calculating more things centrally at the squad level and leaving less for individual units to decide. For focus fire and avoiding overkill, I want a data structure in the squad to keep track of assignments of shooters to targets. For kiting and fleeing, I want a near-term prediction of when each of my units is likely to die, based on the rate it is taking damage or on the approach of enemy melee units. A planning algorithm can look at all the data to decide, “You, shoot at that” and “You, pull back.” It’s not as simple, but I expect it will have a higher ceiling in practice, because it is easy to change out the planner. And I think that, done right, it can execute fast. Units act frame to frame, but the squad-level planner needs to execute only about once per cooldown period, and it can be out of synchrony with unit actions.

That’s general micro, but there are also important micro skills that bots don’t have and would benefit from. I’ve never seen a bot do any of these effectively.

Zergling surrounds. Watch a bot attack zealots with zerglings: Each zergling heads for where the zealot is now, and the lings pile up. With fast zerglings and slow zealots, if the zealots flee then the zerglings end up trailing behind and getting a hit in now and then, and mostly waste their time getting in each other’s way. Arrakhammer does modestly better by predicting the zealot’s future location, react to the future style. Then watch a human do it: The zerglings move into or around the formation of zealots, then attack all at once. If the zealots are fleeing, they get surrounded and have to find or make a way out before they can escape. Any intermediate zerg player knows this micro.

I’m seriously considering implementing zergling surrounds in Steamhammer with human-like control, at least as a first cut. It’s 2 commands total for small fights with up to one control group of zerglings: Command lings to move as a group, command lings to attack as a group. Choosing the destination for the move command is the tricky part.

Dragoon backstepping. Like most bots with a combat simulator, Steamhammer mostly attacks or retreats, and doesn’t know anything in between. But watch what happens in a human game when a strong terran early timing attack moves out and faces forward dragoons: The dragoons will lose if they stand and fight, they must step back... and back.... But if vultures pull too far in front of the tanks, or if any sloppy movement isolates a few terran units, the dragoons may suddenly stop and fire. The terran force must move slowly or be whittled down—usually some of both. Protoss gains time for more dragoons to take the field.

Related situations are common. FAP doesn’t understand vultures versus zealots, so if there are too many zealots, Steamhammer’s vultures will retreat in terror instead of pulling hit-and-run attacks. If an opportunity comes up, take it even if you weren’t intending to fight. I think the decision is best made at the squad level, so that the squad behavior stays coherent. I often see Tscmoo lose squad coherence and disintegrate; I want to avoid that.

Getting out of each other’s way. A large group of ranged units arrives to fight—hydralisks, say. The closest hydras get into range and stop to fire, and the ones behind maneuver around the sides to get into range (that is inefficient already). The ones behind those... push and shove, but can’t get into range and achieve nothing. Any human above beginner level will move the front hydras forward so that all can get into range, but bots don’t.

Climbing a ramp is similar. Bots see targets at the top of the ramp and stop to hit them, blocking the way so that the rest of the force is stuck below. Steamhammer is clever enough not to siege tanks on the ramp, but sieges them above the ramp and blocks the path anyway. Humans keep the front units moving until the whole force can get up. The difference in DPS is huge.

These decisions can be made by individual units, swarm intelligence style, but I find it hard to design good emergent behaviors. I think it is better to make the decisions at the squad level. It should be more efficient and more effective.

As its opponents have long since noticed, ForceBot has become a 5 pooler. It does an economic followup, so there is some interest.

The picture shows Oyvind Johannessen’s base from ForceBot versus Oyvind Johannessen. Random Oyvind Johannessen ended up zerg, and was ready for the rush. Unfortunately, the defending zerglings chose to follow a circling overlord, so Oyvind lost its opportunity to return the pressure.

ForceBot is trying to catch up in workers. As you can see in the minimap, it is 3 bases versus 2. Although it was ZvZ, neither side played aggressively, and the game went on for 45 minutes. It was fun, for a low-level bot game.

Oyvind barely defended itself while the zerglings were suffering from overlord fascination, and ForceBot started to dominate. ForceBot went hydra-lurker and took the map, rather a change from the 5 pool opener.

Oyvind understood how to hold on in a desperate situation. See all the blood? ForceBot could not coordinate an attack to climb the ramp. Oyvind is long-distance mining its natural and eventually retook it, while ForceBot went passive and sat around with its maxed army. The game ended when Oyvind mined out its natural and crashed. I expect that ForceBot would have won on points after the game time ran out.

This version of ForceBot seems to play similarly against all races: 5 pool, try to build an economy, lair, hydra-lurker. It’s quite different from the AIIDE 2017 ForceBot. It seems to have some added defensive smarts; it doesn’t appear to make pre-emptive sunkens willy-nilly any more, at least not often.

Stealing gas is irritatingly complicated in Steamhammer. Today I discovered another bug: If the scout worker has been ordered to circle the enemy base forever, and while it’s doing that you decide (this late in the day) to steal gas, then the building manager goes haywire and moves the worker into a corner or some other useless location. Now what??? It worked when I told to it to scout once around the enemy base and interrupted the circle in the middle by deciding to steal gas, but circling more than once somehow breaks it... in a different module.

Of course everything works perfectly if you decide up front to steal gas, so the worker arrives at the enemy base knowing what to do. That’s the usual case. It sure would be nice to support late decisions, but there are interactions with the scouting command.

I think I should write a general purpose plan sequencer and reduce the gas steal to a plan represented as data, not code. It will be more complicated, but I only have to debug it once and it will have tons of uses.

Last February, I made a few predictions about skills that bots would gain in 2017.

In 2017 I predict multiple bots with new skills of taking island expansions and carrying out doom drops. For Steamhammer I also plan deeper map analysis so it can do things like backdoor attacks when the map allows it. The tactics and strategy in bot play will grow more complex, and everybody will be scrambling to keep up.

Well, the vague forecast that tactics and strategy will improve came true. None of the specific skills has been implemented, as far as I have seen: No island expansions, no doom drops, no backdoor attacks. Steamhammer progress is behind my expectation (what else is new?); I am still planning the map analysis, but it won’t happen this year.

There’s still time. Help make my predictions come true!

In AIIDE 2017, the tournament manager launched some games that did not start. These games were recorded with duration 0 and score 0 for both sides, and were ignored in the official tally. In the detailed results HTML page, the games are listed as crashes with the crashed player being “unknown”. I think of these games as unattributed crashes: If one bot identifiably crashed, then that bot lost the game. But some games failed without either bot crashing in a way that the tournament manager recognized and attributed to the bot, and those games had to be skipped.

And yet, looking at how often bots appeared in “unknown” crash games, there is one obvious conclusion. The % column here is the percentage of unattributed crash games that the bot participated in. Each unattributed crash game has 2 participants, so the percentages add up to 200% before rounding (even though the column total says 100%).

bot	crashes	%
ZZZKBot	4	2.20%
PurpleWave	7	3.85%
Iron	5	2.75%
cpac	7	3.85%
Microwave	8	4.40%
CherryPi	4	2.20%
McRave	6	3.30%
Arrakhammer	7	3.85%
Tyr	4	2.20%
Steamhammer	6	3.30%
AILien	4	2.20%
LetaBot	15	8.24%
Ximp	8	4.40%
UAlbertaBot	2	1.10%
Aiur	5	2.75%
IceBot	15	8.24%
Skynet	12	6.59%
KillAll	5	2.75%
MegaBot	168	92.31%
Xelnaga	8	4.40%
Overkill	12	6.59%
Juno	8	4.40%
GarmBot	9	4.95%
Myscbot	6	3.30%
HannesBredberg	6	3.30%
Sling	7	3.85%
ForceBot	10	5.49%
Ziabot	6	3.30%
total	182	100%

With these numbers in hand, the great majority of unattributed crashes can be attributed after the fact to MegaBot. MegaBot may have a bug that sometimes breaks the tournament infrastructure. Likely the bug is in the infrastructure itself, and MegaBot happens to tickle it—and other bots do too, though less often.

As a side effect, MegaBot’s official score could be considered too high. If we see the unattributed crashes with MegaBot as “MegaBot’s fault,” then the games should not be skipped in the results, but counted as wins for the opponent and losses for MegaBot. The change is unfair, though: Even if the bug is in MegaBot, which we do not know, then surely not all of the unattributed crashes are due to MegaBot. Other bots or the infrastructure must be responsible for some.

Running a big tournament is hard....

I’m still going through AIIDE 2017 games in which Steamhammer lost to weaker opponents. Steamhammer scored 98-12 against ICEbot. I thought this game on Tau Cross was full of depressing and/or informative mistakes.

The biggest mistake is that Steamhammer didn’t usually scout or react to enemy expansions. That is fixed in the development version. I think the new version would have won this game easily, despite the second mistake.

The second and interesting mistake came when ICEbot tried one of its 4 goliath drops.

Steamhammer’s notion of “this base is under attack” is not accurate. One goliath wandered outside Steamhammer’s danger recognition zone and found itself still in weapons range. It killed dozens of drones and eventually one of the hatcheries before dying. In the picture we see the totally non-dangerous goliath killing drones while Steamhammer does nothing because “the base is safe now.”

This weakness is not fixed. I’ve seen it before. The base defense code is inherited from UAlbertaBot and needs a bigger rewrite than I’ve given it.

ICEbot was playing weakly too, though, or else it would have scored more than 12 wins in 110 games. Zerg recovered from the huge deficit and made a fight of it. The game timed out after an hour with the map mined out and the winner still undecided. ICEbot was given the victory on points.

Steamhammer’s losses against ICEbot followed a curious pattern, by the way. Steamhammer lost in rounds 0, 2, 4, and 6. Then in the rest of the tournament, which ran to round 109, it lost 8 more games. Neither bot was learning, so the early losses of every second game were purely coincidence.

I thought this picture was funny. In a game yesterday against Iron, McRave fast expanded and walled off one of the bridges to its natural, but left the other bridge open. Vultures cannot pass the wall, but they happily took the other bridge and Iron won easily.

McRave seemed to mess up its build, getting dragoons too late. (The underlying mistake may have been taking gas at the natural instead of the main.) But the idea is sound. McRave is narrowing the entrance to its natural, making it easier to defend against vultures. A small number of dragoons can block a narrow entrance, either early in the game when there are only a few dragoons on the map, or later when the main army is away and the only dragoons around are those rallied from the gateways.

Its next game against Iron was on Roadrunner. McRave won using the same idea of narrowing the entrance.

McRave’s dragoons beat Iron, so they played well by bot standards. But I see room for improvement. Vultures can pass either left or right of the upper gateway. I think the first 2 dragoons should plug the gaps so that vultures are physically blocked. Iron will lay mines to force its way in, and then the dragoons can retreat to the defense line McRave actually held, the gap between the lower gateway and the nexus. The farther away the vultures and their mines are kept from the probes, the better.

I’ve been watching the replays of Steamhammer’s losses in AIIDE 2017 against its lowest-scoring opponents. I reason that if A beats B nearly every time, then a weakness which causes A to lose to B must be a severe weakness that I should fix.

Steamhammer scored 105-5 against Overkill in this tournament. The losses were all due to the same basic strategy blunder, teching too fast and not making enough mutalisks. One loss was an interesting one that taught me something: It involved making too many devourers.

Here’s the game. Steamhammer played its turtle opening, which it was set to do 1% of the time in ZvZ. (It’s a weak opening, but it is played rarely and it poses challenges that some bots can’t meet, so I don’t mind.) Meanwhile, Overkill also turtled, on 2 bases instead of 1 but with fewer drones.

As in the other losses, Steamhammer spent on zerglings and on teching to hive when it should have been making mutalisks. Overkill flew over, killed a lot of drones—then left for no apparent reason. Overkill was ahead, but Steamhammer could recover. Mistakes like that may explain how Overkill scored so poorly. Steamhammer still didn’t feel like making many mutas, but it did add scourge and morphed a greater spire, which (since it was behind and had already invested in a hive) was reasonable.

Steamhammer started morphing its mutas into devourers. It can’t catch up in mutalisks, so it was a good try to turn the game around. But as I watched, I realized there was a flaw in the strategy logic: It wanted to morph all the mutalisks and go straight devourer. The unit mix is declared as mutalisk + devourer, but because of how gas accounting works, the strategy boss preferred to turn gas-heavy mutas into mineral-heavy devourers.

Overkill finally moved out when it was maxed, with 72 mutalisks. Steamhammer had 20 devourers and 4 mutalisks, plus a fleet of scourge. Now, devourers are support units. They don’t do much damage; their benefit is that they splash acid spores which reduce the enemy’s attack rate and increase the damage taken, and to get the benefit you need fast-attacking units to deal the damage. Because acid spores only stack up to 9, it is not likely that 20 devourers will ever be useful, and definitely not if you fly them around in a group. I guess that about 6 devourers would have been best, certainly not more than 9.

The battle was hilarious. The devourers fought well enough, apparently not harmed by the known bugs, and instantly stacked their purple goop up to the limit of 9 on every Overkill mutalisk that appeared. Devourers are tough, and Overkill’s mutas had their attacks slowed, so the the devourers took a long time to die. But with only 4 mutalisks to deal damage, even though the damage per shot was 9+9 + 3+9 + 1+9 = 40 (spread over 3 enemies with mutalisk bounce) Overkill’s losses were minor.

The ultralisk cavern you can see in the picture was useless. Steamhammer never made an ultra. It shouldn’t have wanted to.

In the next version I’ve taken measures. Steamhammer tries to make more units, techs more moderately, and limits the number of devourers.

I’ve been thinking about how to get Steamhammer to keep trying the gas steal, so the code doesn’t bitrot again. Writing separate gas steal openings for each race doesn’t sound like much fun, and also doesn’t gain the full advantage. I might do a little of that, though.

I decided to build it into the opponent modeling mechanism. I’m not sure about details, but the basic idea is that, against any opponent that is causing trouble, it will try stealing gas to see whether it works. It will record the gas steals in its game records. Over time, the opponent model could learn many things: 1. Which opponents fail to cope; steal gas and win. 2. What opponent builds it is effective to steal gas against. If you see 2 gates and zealots out already (whether or not you’re playing Wuli) then you have the opportunity but there’s little point. 3. How to follow up a gas steal. The point of stealing gas is to channel your opponent’s play into a direction that you can exploit. Then you have to exploit it!

I would also like the opponent model to handle scout timing, but I’m not sure whether I can get to that for the next version.

Gas steal, by the way, is more or less working in my development version. I still have bugs to fix and testing to do, but it’s basically back again. It took a lot of changes.

I thought these 2 games showed interesting mistakes.

Steamhammer-McRave

This game on Circuit Breaker was kind of disorganized on both sides, but fun. Steamhammer played its usual low econ zergling pressure, and McRave opened with cyber core before second gate, which was slow enough to give the pressure a chance. After a few tries, Steamhammer killed enough probes to make up for its own weak economy, and the game was on.

The fight went back and forth, the sides seeming about equal in economic growth, tech progress, and missteps. It was fun to watch.

Steamhammer: It’s only an overlord. No need to keep it safe. And that? Oh, it’s only another overlord.
McRave: Huh? Why wouldn’t I awkwardly split my army?

Then dark templar came out, and Steamhammer fell over. Zerg did not understand.

Steamhammer: What danger? I don’t see any protoss units that I can’t fight.
McRave: Exactly.

Steamhammer-KillAll

This game was a win but... ugh. Only because KillAll went above and beyond to play worse.

KillAll did its thing and sunkened up for safety. Steamhammer understands in outline how to win these games: Place zerglings in a containing position so the enemy can’t expand or attack, make drones while teching, then win with mutalisks. But (as against ZZZKBot in AIIDE) Steamhammer did not execute well. It placed the zerglings in a position that contained nothing, and in fact left the barn door wide open. Steamhammer even stepped back to let enemies pass, in reflexive fear of the distant sunkens.

Below you can see that Steamhammer is ahead in economy, tech, and army—yet Steamhammer is in trouble because its force is out of position, standing outside an enemy base that it cannot threaten while its own base is under attack. Meanwhile, KillAll decided that its attackers should focus down the lair to the exclusion of all other targets, so that Steamhammer’s drones were able to clear the zerglings with no losses.

I can’t say it’s an undeserved win. The winner made smaller mistakes. Only not small mistakes.

Next: Thoughts on the gas steal.

“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.

I wasn’t expecting this: Afreeca in Korea pitted 2 low-ranked players against 3 bots each, then Stork against 4 bots (10 games total). The bots are MJbot (which I don’t know anything about), ZZZKBot, and Tscmoo playing random (in a version with a very strange zerg build). Stork also played against CherryPi.

• TeamLiquid thread
• Korean cast (skip ahead to about 40:00 for the first game)
• English cast (missing the first and last games)

Stork made it look easy. If you’re that good, it is easy. It was a treat to see Stork’s superior decisions and strong micro.

Tomorrow: The promised Steamhammer vs. PurpleWave games.

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.