Starcraft AI blog

Here’s a ZvZ SCHNAIL game where the human played an unusual strategy. It was a ranked game, so maybe the human shouldn’t be playing around... but they were clearly playing around. The game is Randomhammer - jki, appearing in the replay as Anonymous AI (rolling zerg) versus jk.

Randomhammer made an unfortunate choice of build, a hidden base with each base protected by a sunken. The goal is to survive a rush and hit back. Jki (who didn’t know at first that Randomhammer was zerg) went overpool then natural ahead of the hidden base, gaining an advantage from the start. And used the advantage ingeniously.

1. Contain Randomhammer to its main base with zerglings.
2. Get a spire.
3. Make scourge and repeatedly kill overlords. Overlords don’t cost gas and are usually a poor choice of scourge target, but since Randomhammer was already behind, it kept getting supply blocked and was unable to make enough units, air or ground, to break out. It didn’t help that it fought poorly.
4. Get lurkers too! The plan costs a lot of gas.
5. Win. If an overlord approaches to detect the lurkers, scourge it.

The picture shows the lurkers breaking down the hidden base. The lair is there because Randomhammer tries to morph the lair where it won’t be seen right away. Notice the human player’s much larger army supply.

In other ZvZ games, jki has played normal ZvZ strategies. The lurker plan was apparently an on-the-fly decision to have fun with Randomhammer’s poor start. Bots can’t do that... yet.

I’ve uploaded Steamhammer 3.5.2 to SSCAIT. It fixes the worst problems with the new static defense code introduced in version 3.5.1, the version with the big changes.

Smaller problems remain. Steamhammer now likes to build too many sunkens early in the game versus terran, a tuning issue. It is quick to defend the front line, but often strangely slow to defend other bases, which must be a bug. In combat decisions, units much more often mysteriously shy away from the fight, even when facing an undefended base. I think I know the cause. It is likely that this version will lose elo on BASIL, though we’ll see. It’s not easy to judge whether the new problems outweigh the improvements.

It’s time to go dark and prep for AIIDE. These problems and more will be banished. My aim is to come in ahead of the middle point, where I landed last year. And of course ahead of Microwave: Microwave must be utterly murderfied.

I uploaded Steamhammer 3.5.2 to SCHNAIL today. The version fixes the worst of the problems in the static defense code that was new in the previous version 3.5.1. They were problematic problems; Steamhammer dropped 200 to 300 elo. The change list is short.

• Added a new macro location MacroLocation::Tile for placing buildings at an exact position. Now code that knows how to place buildings can post those buildings to the production queue.

• Taking advantage of that, now the static defense code queues buildings to produce instead of dropping them directly into the building manager, as before. The old static defense code never had a problem doing that, but the new code is more capable and hits failure cases. The production manager that reads the queue already does all the work needed to cover those cases, though.

• Zerg more carefully limits the number of static defense buildings it makes. Sometimes it wanted to put down more than the drone count could support.

Meanwhile, for CoG 2021 my parsing code needs updates to read the detailed results file perfectly. This happens every year. It won’t take long.

After a long time, I finally discovered that Steamhammer 3.5.1 failed to update on SCHNAIL because I repeatedly uploaded the wrong file. This is because I am as dumb as a rock, and unmotivatedly checked a long list of other possible errors first. Although, unlike most rocks, I did eventually wake up.

Initial results are in for the new version, and they are poor. I notice only a few new bugs, but they are severe and must be fixed, preferably weeks ago. So 3.5.1 will not see SSCAIT; maybe 3.5.2 or 3.5.3 will be fixed enough.

Steamhammer has superhuman macro, or at least, its macro skills are far beyond those of human players around its level. I think pro-level zergs can probably macro better than Steamhammer in many situations, because of superior planning. But Steamhammer is utterly superhuman in some aspects. For example, humans can’t do mining optimization after the early game. And the bot can set every drone to work on the first frame that the drone becomes commandable.

And yet, and yet! Steamhammer’s macro is far from optimal. It feels strange that it can be at the same time so good and still have so much room for improvement. It’s not something I need to work on soon, because it’s a relative strong point even compared to other zerg bots, but in the long run there are steps to take.

For one, Steamhammer does not do all the mining optimizations that it could. Some bots ranked above it have put considerably more effort in.

For another, there is a limitation in the production system that it can only produce one queue item per frame (except commands; it can execute commands in the same frame as another queue item). The limitation reduces bookkeeping and simplifies the code. Usually, it makes little difference. When Steamhammer saves larvas to produce its first 3 pairs of zerglings, it hardly matters that the second and third pairs start a fraction late. But in the late game, occasionally there is a sudden need to produce many zerglings at a time when all the needed larvas are available (because production has been limited by gas). The last zerglings in the queue may be started over a game second later than they could have been, and that could affect the fight. It’s hardly a critical weakness, though. I’ll rework production eventually, but it is low on my priority list.

The big macro weakness is that Steamhammer does not plan ahead. It makes hatcheries and overlords at times decided by heuristics. The heuristics are not bad, but for hatcheries in particular it often ends up with too few or too many—commonly, too few and then it overcorrects and gets too many. It’s possible to do much better by predicting the needs of future production and adding hatcheries just in time. It could be tricky, because future production depends on how the game will go, which depends on the opponent’s play. Even if you knew exactly what combat unit mix you want (which you can’t be sure of), there’s a risk that you might lose drones and need to replace them, and drones are larva-intensive because they are cheap. But still, it’s definitely possible to do much better than Steamhammer’s current play. That change is sort of in the middle of my priority list.

Even the greatest strengths are not so great. It’s a hard game.

So, SCHNAIL believes I successfully updated Steamhammer back on 11 July, but it is still running the old version. It’s easy to tell, because of the orthogonal movement pattern and the jittering of Watch squad zerglings before burrow is researched. I’ve been too lazy to diagnose it and try again. Presumably I got something wrong in the zip file.

Nevertheless, I was surprised to see that Steamhammer is the #1 zerg on SCHNAIL as of now. Well, counting active zergs. The top zergs by elo are

1472 Steamhammer
1463 Chris Coxe (aka ZZZKBot)
1452 ZurZurZur
1440 Crona
1432 Monster
1384 Killerbot (aka Marian Devecka)

Chris Coxe is up there because of its rushy habits. I’m not sure why Monster and Killerbot are so far down; I would have expected them to do well against humans. Microwave is ranked above Steamhammer on BASIL, but below on SCHNAIL at elo 1280. In some cases, bots on SCHNAIL may be older versions. I know some bot authors update often on BASIL and rarely on SCHNAIL. Maybe they’ll read this post, update, and try to push Steamhammer back down where it belongs.

In other news, AIIDE 2021 registration is open. Steamhammer will be competing.

Many will have missed it since the original post was almost a year ago, but today Tully Elliston commented on the Steamhammer 3.1 change list from August 2020:

Tully Elliston: Looking at BASIL win rates, it looks like SH competitive performance dropped visibly after this version.

It does look that way. Here is BASIL’s graph of Steamhammer’s elo for 2020. BASIL throws in the ratings of top bots, which by coincidence is exactly what I want here. The version in question is the red dot on 20 August (delayed from the posting of the change list due to downtime).

Steamhammer improved slowly but steadily up until around that version hit the server, then more or less held steady while the top bots gradually lifted away. The cause might be the sudden ascendance of Stardust, pushing everyone else down; the theory would be that the other bots on the graph coped better with the killer dragoons. It seems plausible to me, but Stardust is only one opponent and should not have much effect. The cause might be that I had spent a year distracted by other things and worked slowly on Steamhammer. That seems more likely to me. Or it could truly be that a weakness was introduced in this version.

Notice that Steamhammer’s improvement on the graph occurred in between widely-spaced updates. In principle, there are 3 ways that can happen: 1. By chance. 2. By artifacts of the rating system as implemented, because of bots arriving and leaving. You can get elo inflation if bots arrive, lose games and fall in elo to push everybody else up, then are dropped (and BASIL has dropped a lot of bots). 3. By Steamhammer’s opening learning. I think the opening learning is most likely. That opens another hypothesis for why improvement stopped around this version: Maybe, due to weaknesses already inherent in Steamhammer from earlier versions, the learning reached a ceiling and could no longer contribute. This suggests that there may be a bottleneck weakness somewhere, and to make big progress I have to break the bottleneck.

Wah, that is a lot of hypotheses. I looked at the long-term elo graphs for a number of bots which have not been updated the whole time, and they all show elo increases. BASIL has elo inflation, which explains some proportion of the elo rise of all bots. It also means that if your elo does not increase, maybe your bot is not staying the same, but getting worse! (We could take an average of non-updated bots and subtract out their elo inflation to get an estimate of true strength over time. There is no reason to expect that the inflation is constant over time.)

Here is the same graph starting from 1 January 2019 and continuing until today. BASIL began a little before the start of the graph, but the early period shows startup transients as the initial elos are established, so I left it out.

When I compare Steamhammer to Hao Pan and BananaBrain on this graph, I can make out 3 periods. From the start until about October 2019, Steamhammer was neck-and-neck with them. From then until August 2020 or so, Steamhammer remained behind them; a gap had been opened, and the gap stayed roughly constant over that time. And since that time, Steamhammer has gained elo extremely slowly if at all, and has fallen further behind. Despite bug fixes and demonstrable improvements in some points of play, Steamhammer does not seem to be improving and (accounting for elo inflation) may be deteriorating. It is consistent with the distraction hypothesis, if you assume that I still haven’t recovered... but I think I have.

I suspect that the bottleneck weakness hypothesis is true. After watching many SCHNAIL games, I’ve concluded that Steamhammer’s tactical weaknesses in the midgame are critical. It loses too many units due to bad tactical decisions, must replace the lost combat units to stay safe, and (spending on combat units instead of drones) reaches its lategame economy too late. I suspect that if I fix the bottleneck tactical weaknesses, the other improvements I’ve made will start to show.

It’s hard to be sure, though! Gotta try it and find out.

By the way, I think the big point in these graphs is the relative decline of Krasi0. Krasi0 gained slightly over time, but lost its dominance and now is only another top bot. Subtracting elo inflation, perhaps Krasi0 is no longer improving at all.

Yesterday I uploaded Steamhammer 3.5.1 to SCHNAIL, as Steamhammer, Randomhammer, and Crazyhammer. At least some games today still seem to be running the old version, though. I’m not sure how the details of update work.

This version concentrates on changes to improve play against humans, though I expect some of the changes to help against bot opponents too. The headline skill is new static defense analysis, which should help Randomhammer’s terran and protoss against all opponents, and zerg against humans. If performance is as good as I hope, I’ll soon upload to SSCAIT too. But I expect real games to look different from my test games.

static defense

• New StaticDefense module makes decisions about static defense timing and placement for all races. (Special zerg reactions to events like rushes and proxy bunkers still exist, so the new code doesn’t handle all static defense.) The former code was only for zerg. The new code is more general and capable, and simpler in key aspects. It should be easier to work with. Like the old code, it understands that ground defenses at a natural base also protect the main base behind it, and it understands that drops bypass those defenses.

One frame it examines the situation and makes a plan for what anti-ground and anti-air static defense is needed. The next frame it starts to carry out the plan, including building prerequisite tech like an engineering bay for turrets if needed. After a fixed delay, the cycle repeats. The terran plan only calls for turrets; it’s easily extended to make bunkers, but Steamhammer doesn’t have the skills to use bunkers properly as static defense (its only skill is to put marines that it already has into a nearby bunker if the enemy is nearby too). The protoss plan calls for cannons at all necessary places to defend against cloaked units, vultures, drops, and air attack. The zerg plan is comprehensive. It makes one spore at one or two selected bases to preserve overlords if needed, or the required number of spores at all bases to defend against air attack. Steamhammer should do better against mass wraiths and mass scouts, which human players occasionally go for, and better in ZvZ when far behind in mutalisks. Sunkens are concentrated at the front line base versus bots, because nearly all bots go straight there, and spread to all exposed bases versus humans, because humans like to wipe out unprotected bases first. (At some point I want to add a SkillKit skill to remember the opponent’s past behavior, so that Steamhammer doesn’t have to rely on a blanket heuristic.)

The overall effect should be that zerg is resilient in a slightly wider range of situations, while terran and protoss become better able to survive common attacks like DT rushes, mutalisks, and drops.

Detailed building placement is not improved. I did nothing with the building placer to ensure that that defenses cover approaches or buildings or the mineral line, etc. Sometimes turrets are in a tight line, so that half the mineral line is overprotected and half is open. One step at a time.

• To support this, I moved getMySpireTiming() from the zerg strategy boss to the information manager. I also updated it to work in the case where the bot is making more than one spire simultaneously (which it could do if the opening build explicitly codes it). In ZvZ, if your mutas are far enough behind then you have to start preparations for a spore colony before the enemy spire finishes.

• I moved the “front point” for defense from 7 tiles away from the hatchery to 5 tiles away. It helps zerg place sunkens in a tighter group, and should not hurt terran or protoss.

squad orders

• Assign more anti-air defenders when under attack by protoss scout air units. 2 hydras per scout were not reliably enough; 3 should do it.

• Watch squad: In ZvZ, don’t watch as many bases. Expansions are few in the matchup, and the zerglings are more valuable in combat.

• Watch squad: Don’t waste a ling trying to watch a base which is covered by enemy defense, such as a sieged tank or a cannon.

• Watch squad: Smaller combat sim radius—let the enemy get closer before fleeing.

• Watch squad: An unburrowed zergling watching a base tended to oscillate around the base position, rather than sitting still, churning useless commands. When originally implemented, the Watch squad did not misbehave like that. I found 2 bugs born since then, each of which independently caused oscillation: 1. Being at the order point automatically made a unit “near the enemy,” so that it might run away a short distance though not actually near the enemy. 2. In the distances grid used for pathfinding, the grid 0 point could be slightly offset from the true goal position. I decided to allow some tolerance.

micro

• Diagonal movement, lack of which I noted as a disadvantage in Steamhammer’s pathfinding. Units often get where they are going faster, which should help in all matchups versus humans or bots. On the other hand, I’ve noticed that the orthogonal movement can sometimes sneak past the opponent’s army and let Steamhammer make a surprise attack. There is always a tradeoff.

• Try to stay out of tank range when not actively attacking. Steamhammer mostly keeps retreated units out of enemy fire, but there are exceptions. The worst was leaving ground units nearly, but not quite, outside of tank range; given time, one enemy tank could destroy an entire ground army (common versus humans who benefit from zero-APM passive defense, rare versus bots). I made 2 changes to fix it. 1. A retreating unit checks an attack map to make sure it is out of range; if not, it hasn’t retreated far enough. 2. The combat sim seeks enemies in a wider circle if there is a risk of sieged tanks, so that it doesn’t overlook the enemy and wander back into range “because it’s safe.”

• Canceling buildings under construction, as well as unhatched eggs and cocoons, when they are under attack and about to die, works again. I introduced bugs when I “improved” it, causing it to nearly always fail. Now it is both improved and reliable, which (surprising though it may be) is better than either alone. It also cancels earlier, at a predicted 5 seconds left to live, which may be too soon. I’m guessing 2 or 3 seconds might be best; it depends on how accurate the predictions are.

• Bug fix in handling irradiated units: They feared splashing their radiation onto zerg buildings, though radiation does not affect buildings. Buildings apparently have rad shielding. This was a minor bug with trivial effects. I found the bug while searching for known serious bugs in handling irradiated units, bugs that regularly cause severe mistakes in games, but I could not pinpoint any of them. Except for its deadly flaws, the code appears flawless.

queens

Queens are surprisingly valuable against turtling human terrans, so I put effort into improving them. But not much; these are all simple changes. Big improvements need more complicated work (but will happen in time).

• Configured to make up to 8 queens, up from the previous limit of 6.

• Get the queen’s nest a little earlier if we have reason to want queens or defilers, or a little later if we don’t. This should help Steamhammer get queens and/or hive tech sooner when needed, and delay the expense otherwise.

• Get ensnare less often in ZvT. The combat sim understands ensnare reasonably well, but the queens cast it at inappropriate times when it does no good. Broodling is more valuable with Steamhammer’s skills.

• Don’t get broodling if the enemy has too much air-to-air strength. Wraiths and corsairs love to shoot down queens.

• Versus both terran and protoss, a higher threshold to get broodling in the first place, but once the threshold is crossed, a greater number of queens to use broodling. It’s an efficiency improvement.

• Changes to the scoring for queen broodling targets: A bigger bonus for a target which is defense matrixed. A discount for a plagued target. A bonus for a target under dark swarm. A slight increase to the bonus for already being in range, so that the queen doesn’t have to move in.

zerg

• Defense against proxy cannons: Attempt to exploit the sunken range bug. This is one of 2 main expert defenses against cannons behind the minerals (the other is to push workers through the minerals to fight). If it can, Steamhammer will place a sunken which is in range of a pylon and out of range of the cannon or cannons that the pylon powers. When the cannon fires on the hatchery (or on anything else), the Brood War bug will cause the sunken to target the cannon even though the cannon is out of range and cannot fire back at the sunken. Use of this bug seems to be universally legal. If it works as intended, it should stop many tries to put cannons behind the minerals (if the cannons are too early, the hatchery will instead be canceled, or never started, and Steamhammer will have to destroy or play around the cannons).

No bot yet has tried to cannon behind Steamhammer’s minerals. Human protoss players do it often. It doesn’t always win, but with the right followup it’s effective.

• Defense against proxy cannon pushes: More often place multiple sunkens versus surrounding cannons. Opponents, both humans and MadMixP, are increasingly creeping cannons around the edges of the defense zone of Steamhammer’s single anti-cannon sunken.

• A high score for a defiler to place dark swarm over burrowed lurkers, and a lower score over unburrowed lurkers. A minor change.

• Adjust defilerScore higher against protoss dragoons. That will make Steamhammer get defilers earlier—see the item about the queen’s nest timing above under queens.

• The remaining zerg items are adjustments to the unit mix scoring. I adjusted existing scoring terms to reflect results against humans on SCHNAIL, adding only one new term. Human players pose unit mix problems that bots do not. ZvT unit mix adjustments: Wraiths more encourage hydras. Valkyries more strongly discourage guardians and encourage devourers.

• ZvP unit mix adjustments: Lower global bias toward ultralisks. All protoss air encourages hydras. Corsairs and scouts more discourage guardians and encourage devourers. Carriers discourage devourers. The new scoring term is that merely having a stargate (which could be an inferred stargate; it doesn’t have to be directly scouted) discourages guardians. Steamhammer has been making too many guardians against protoss, and uses them in a way that’s strong enough against bots, but fatally weak against humans.

• ZvZ unit mix adjustment: Guardians and devourers are both more discouraged in general. They should be rare.

openings

• In many terran and protoss openings, replaced go scout once around with go scout, meaning that the early worker scout stays inside the enemy base if it can. Compared to zerg, terran and protoss have more workers and can better afford to dedicate one to looking at stuff.

Steamhammer (as the random-build Crazyhammer) played a particularly difficult game yesterday on SCHNAIL, a Crazyhammer versus kkt2108 (T) at server time 21-07-08 18:28:46. As background, this terran player had just lost a couple of games to randomly-selected zergling busts with different timings, and apparently decided that it would not happen again. It didn’t!

I trimmed out the minimap and everything below, so that you can’t tell who’s winning. But see the signs of tough combat: The zerg natural being replaced, the rubble of terran buildings at its entrance (at the very bottom edge of the picture), the zerg main nearly mined out and with destroyed buildings, a couple of terran stragglers still not ejected, and few zerg combat units visible though apparently zerg survived the battle that just finished.

Don’t miss the simultaneous attacks by both sides at the end.

Steamhammer’s BASIL win rates by matchup surprised me:

matchup	%
ZvT	62%
ZvP	60%
ZvZ	61%

What the what?!? The numbers are indistinguishable! That’s not what I expected at all! Steamhammer has always been worse at ZvP, and always by a wide margin. What happened? I went so far as to suspect a bug in BASIL and compared other bots to see if anything was glaringly suspicious, but no, nothing was obvious.

Here are the same matchups as played by Randomhammer, which plays zerg identically except for what it may have learned.

matchup	%
ZvT	63%
ZvP	65%
ZvZ	78%

Randomhammer plays weaker opponents because it is lower ranked, so its zerg rates are higher. ZvZ stands out as much stronger, the other two are again virtually equal. Compare the rates from February this year, when ZvT and ZvZ were close and ZvP was waving to them from far below.

What changed in the last few months? Steamhammer or its BASIL opponents? I’m sure the higher ZvZ win rate for Randomhammer is due to fewer ZvZ games versus Monster and Crona. But the fact that Steamhammer and Randomhammer have similar ZvP rates despite facing a different mix of opponents suggests that the ZvP change is in Steamhammer, not in the opponents. New versions since February are Steamhammer 3.4.8 and 3.5. I looked back at the change lists and nothing stood out as clearly advantageous for ZvP. Maybe the change of AbsoluteMaxWorkers from 75 to 65 is good for ZvP? It seems plausible, compared to anything else I can think of. (When Steamhammer reaches that worker count, it goes into late game big-army macro mode.)

Bot performance is sometimes mysterious. Intuition does not always bite. Does anybody have a theory?

As an aside, the matchup win rates of adias (aka SAIDA) are amazingly similar: They varied from 69.17% to 69.62% when I checked. Was that achieved by intense optimization of the play? Is it an effect of the learning system?

Next version Steamhammer 3.5.1 is mostly ready. The major work is done and it is passing many tests. There are tweaks in waiting and some fixes needed...

... but I’m not expecting serious issues.

The changes are intended to improve play versus humans, so I’ll test on SCHNAIL first. I made tactical changes that are hard to test and may be risky; if they don’t work out, I’ll have more to do for the next version. Some changes will help versus bots too, so if it looks good it’ll be on SSCAIT shortly after.

Today on BASIL, Steamhammer scored its first win over Stardust in months (no exaggeration). Steamhammer-Stardust on Destination is a zergling rush and not that interesting, other than in being a rare win.

The build is the 6 pool speed opening that I wrote up in 2018. It is a little slower than 5 pool, in exchange for getting zergling speed to make the lings more dangerous. I suspect the build may have winning chances only on 2-player maps, because Steamhammer has to drone scout on bigger maps to find the enemy, and sending 1 drone out of only 6 total gives up a lot.

Did Stardust misdiagnose the opening because it saw the gas being mined? If so, I don’t think it was critical. After zerglings broke in, the probes felt unsafe and stopped mining; that was the real mistake. I think it’s a good guess that the overreaction has been fixed in the CoG 2021 version.

Steamhammer understands that plaguing an archon doesn’t do much good. An archon has 350 shield points and only 10 hit points, and plague affects hit points only. But put enough archons together, and Steamhammer may calculate that it’s worth it anyway.

Steamhammer intentionally errs on the side of excess plague. Plague on 6 archons destroys at most 6 * (10 - 1) HP, only 54. It’s questionable whether that’s enough to pay for the 3 zerglings the defiler consumed (the lings have the adrenal upgrade and do damage fast, but then again, they’ll die almost instantly against mass archons so maybe they weren’t worth much). Dark swarm might have been a better choice, but I don’t mind. As I said, it’s intentional, and anyway, Steamhammer was losing this game no matter what.

In this game versus Krasi0 on BASIL, Steamhammer selected an unsafe ZvP build. Almost all ZvT builds come with a lair pretty early; the exceptions that come to mind are rushes. This was a multiple-hatch-before-pool into 6 hatch hydra build with a late lair, sensible against sufficiently slow protoss play, senseless against typical terran barracks play. Somehow Krasi0 steered right into it, starting with its thou-shalt-not-rush-me ramp bunker and continuing with goliaths. Hydras are strong against goliaths.

Both bots have a lot to learn about strategy.

Steamhammer-Joon is a funny game played today on SCHNAIL. (The player’s screen name is ZI7HMI and the game time was 21-06-30 08:48:50.) Steamhammer had played this opponent once before and correctly predicted cheese, so it started with 9 pool and a sunken in its main. Joon, being a crafty human rather than a bot, crossed this plan up by bunkering the natural below the ramp. At the time of this picture, the first terran barracks had lifted because it had started to burn, and the initial zerglings that escaped before the bunker were attacking SCVs.

Zerg was mining with more workers than terran, but was contained to its base—and terran sent most of the pulled SCVs back home, putting the human ahead in economy. Steamhammer kept sacrificing drones to the bunkers as it tried to expand (it’s on my list to fix soon with safe pathfinding), and losing overlords for lack of understanding of enemy visibility. But it also got lurkers, and terran was only just adding comsats. After a sharp struggle whose outcome looked uncertain at first, zerg broke its own natural—where terran had built a command center—and forced buildings to lift.

Now terran was far ahead in economy though with hands too slow to spend it, while zerg was ahead in army. Notice that terran is adding a starport while zerg is getting a spire. The zerg force, finding no buildings on the ground and unable to attack air, hurried across the map to the terran side. Immediately, Joon landed the buildings again, so that the drone which came down to expand could not take the natural but had to continue to another base to expand. Having crossed the map, lurkers forced the terran natural into the air and continued on to pillage the main, while terran quickly trained marines in the zerg natural and easily held it, restoring the containment—but with zerg already owning a base outside it.

In the picture you can see 2 vultures and a wraith, which proved of little value. Steamhammer scourged the wraith and a followup wraith (you can see the scourge in the production tab). At the opposite corner of the map, terran marines were supreme and Steamhammer chose a mutalisk switch, which was also of little value. The strategic situation completely reversed in a short time, with zerg ahead in economy and terran stronger in army. Steamhammer had taken the top center base, but was not mining there.

Steamhammer killed all SCVs in the terran main, left 1 lurker there to finish cleaning up, and returned the other 3 to visit the terran complex at the zerg natural. At the same time, the strong terran infantry easily broke the sunken in the zerg main, which had been waiting there since the early opening, and set about their own cleanup. Base race!

A crazy game, and a close one. Both players had opportunities to turn events in their favor at multiple points. I won’t spoil the end, though it’s predictable if you know how terran-zerg base races go. You can watch it to see.

Here’s a fun SCHNAIL game, Steamhammer-HitHat (screen name Joongwan). Steamhammer had played this opponent before, so it had an idea of what to expect and made an early sunken. The sunken is misplaced. The misplacement is better against other bots than correct placement, but you’ll see in the game why I call it a misplacement! After learning by the loser, the next game went differently. Another interesting game is this one on Fighting Spirit against a different opponent.

I’m not sure why there are separate screen names and game names. The website comes with an API that gives the screen name with replay, and the replay has the game name, so no information is hidden. Still, people use the feature a lot, so it must have appeal. Are names that much fun? I’m guessing it was a feature added at the request of players. I sure wouldn’t have thought of it.

Steamhammer 3.5.1 is progressing, though slowly. Since my energy ran down, I stopped working on my plan of using Steamhammer’s new opening data. After seeing many SCHNAIL games, I’m mostly making changes to improve Steamhammer’s play against humans. Humans know a lot of tricks that bots don’t know, and they’ve uncovered weaknesses that I want to fix. Better is better, even when it may not show against bot opponents.

I rewrote Steamhammer’s crufty old code for deciding when, and in what bases, to place sunkens and spores. Unlike bots, humans are quite good at attacking vulnerable bases first. (Steamhammer makes an attempt to get this right. Most bots don’t try.) I was running the first tests, demonstrating that it worked in a couple of simple situations, when I realized that I should have generalized it for all races. Terran and protoss desperately need the skills: Make mutas and win because terran doesn’t add turrets; make DTs and win because only one base gets turrets or cannons for detection. I’m not only working slowly, I’m thinking slowly.... I rearchitected it and rewrote nearly all the code a second time, in a new StaticDefense class. It’s cleaner and more capable, and should be easier to adjust. It’s just now ready to get back to testing.

Humans make very different opening choices than bots. Most stick with general-purpose safe openings; a few specialize in cheese. I don’t have any way to collect SCHNAIL opening data, so I started a new file to hand-write an anti-human configuration. I didn’t fill in much of it yet, but I’ll get to it.

I expect my tweaks and new features to help somewhat on SCHNAIL and a tiny bit on BASIL. But we’ll see.

My energy is low, but I’m still working on Steamhammer and checking out games. Crazyhammer is Steamhammer configured to choose purely at random from its library of over 200 zerg openings. It plays only on SCHNAIL, and only practice games, because it’s just for fun.

Crazyhammer doesn’t get many games, and it loses a lot because its builds are often hilariously inappropriate. As you’d expect! Today Crazyhammer played a fun game against terran TeChRapy on Fighting Spirit. Crazyhammer randomly chose its queen rush build, which will happen about 0.45% of the time—this is the first time I’ve seen Crazyhammer play it in a real game, though Steamhammer did give it a try versus Stardust in AIIDE 2020.

In the queen rush, Steamhammer makes 6 queens early on and researches broodling. It’s hard to think of an opponent plan that it counters. I don’t have the strength to take pictures and do the blow-by-blow, but here are a few points you might like to notice.

• Watch the swoopy way the queens fly around. It was the simplest idea I thought of to keep the queens apart so that they don’t often select the same target. It didn’t work this game! At about 9:30, 4 queens simultaneously and from different sides ensnared the same group of marines. I should bite the bullet and implement proper spell target tracking.

• Techrapy went with multiple barracks, no tanks. Nothing was worth a broodling, and the queens were useless at first.

• Crazyhammer reacted by researching ensnare and adding lurkers, both useful against marines. Techrapy got tanks against the lurkers, and then the queens had a broodling target.

• The queens sucked at staying safe. One of the 4 ensnaring queens retreated forward instead of backward, and got shot down. Later, 2 queens in a row flew into turret range and died trying to snipe the same tank.

• On the upside, the fast queen’s nest meant that the hive was not too slow. Defilers helped.

In the following game, Crazyhammer started with 8 hatchery 7 pool, and Techrapy won easily. Terrans at this level usually play a barracks-expand build which is safe against zergling openings, given scouting and a few easy reactions. Certainly safe facing Steamhammer’s level. In the queen game, maybe Techrapy was confused and made overcautious by the “unconventional” (aka bizarre) build.

Queens showed poorly this game, but I’ve been surprised how often they are successful. When terran turtles hard, Steamhammer’s queens can be as valuable as its defilers in breaking the shell. Knowing that queens are in play tends to make terrans spend on air defense and move around more slowly and cautiously. And I know what I need to do to make them more effective.