Starcraft AI blog

Games for SSCAIT 2021 will be starting any time now. Meanwhile, I have been working on an unrelated project which is well over half complete.

Steamhammer has participated in SSCAIT every year since 2016. This year makes six. Steamhammer finished at #11 in 2018, #11 in 2019, #11 in 2020. This year will be the first time Steamhammer has played without any special preparation or last-minute fixes. I expect it to finish at... #11, maybe a little better. If I had worked on it in the runup, it would have had a good chance to finish in the top half, because I’m at a point where big improvements are possible. I didn’t, but Steamhammer is still in good shape to finish as well as it has in past years.

Anyway, the proof is in the pudding. Let’s go!

The submitted Steamhammer was mistakenly configured to retain 100 game records per opponent. I had thought it was set for 200, and didn’t double-check. So of the 157 games against each opponent, of which 150 counted in the tournament, I have records for only the final 100. That’s 93 tournament games plus the 7 extra at the end.

My prepared data was successful. For all opponents which I prepared for, the prepared openings were among the highest scoring (including the zero score versus Stardust). It’s notable that Steamhammer’s gas steal was not successful against any opponent, perhaps another sign of an elite tournament. It was either infeasible or abandoned as a failure against every opponent except DaQin, and did no good then.

Steamhammer’s game records are rich with data. To show a little bit more of it, I added a new feature in the opening table. There are new “wins” and “losses” columns showing the median time that winning and losing games with that opening lasted. The median is a better measure than the mean, because we can expect the distribution of game times to be right-tailed: Games are limited to between zero minutes and one hour, but we expect a hump nearer to zero and a long tail of slower games. That inflates the mean and makes it misleading. For the tournament, I turned off surrendering, so Steamhammer played its losses out to the end.

Steamhammer lost every game, but there is still valuable info here. If you’re losing all games, the game duration is a plausible proxy for how much trouble you caused the opponent. Especially so if you tried a rush opening and ended up in a long game—either the rush did some damage, or the opponent overreacted and was slowed down. Here, a couple of 7 pool builds were among the longest games. Steamhammer probably should have repeated them.

Notice the 4 pool and the hive rush. Steamhammer tried the whole range. Steamhammer recognized Stardust’s build in 2 games as nexus without cannons, a reaction that Stardust did not have last year. Otherwise, results are similar to last year’s.

In the 150 tournament games, Steamhammer scored 25 wins versus BananaBrain. Of those, 15 were due to BananaBrain suffering a frame timeout. Ouch. The game scores say that BananaBrain was ahead in 11 of the 15 games when it timed out. So the win percentages and times need to be interpreted carefully. The wins overall were longer games than the losses, possibly because BananaBrain was more likely to time out in a longer game with a larger game state to model and more units to control.

11HatchTurtleLurker scored over 50% in 15 games! Is it particularly good at prompting BananaBrain to time out? If I’d known about it ahead of time, I could have added it to my preparation and perhaps scored higher.

The build 2x10HatchSlow is shown as tried 7 times with no wins. I know from watching games that the opening scored wins earlier in the tournament, before the final 100 games; that is why it was tried so often later on. The build is very similar to Broken Horn’s 10 hatch-9 hatch-pool, but (I think) slightly more efficient. Apparently BananaBrain learned to avoid lines that lose to the mass of slow zerglings.

Successfully stealing its gas caused BananaBrain to take its gas sooner. I haven’t seen that before. In any case, it was only 3 games; Steamhammer found the gas steal unprofitable.

The most successful openings were 5HatchPool (5 hatcheries before pool, a supremely greedy build to exploit bots that never attack early) and ZvT_3HatchMutaExpo, the two openings I selected as preparation. For bots carried over from the previous year, good preparation is easier.

Dragon has a chaotic play style. Steamhammer’s wildest game of the tournament may be Steamhammer-Dragon on Longinus (replay file). Dragon played a V strategy: Vultures, valkyries, and vessels.

Again two of my prepared builds, 9PoolHatchSpeedAllIn and ZvZ_OverpoolTurtle, were the top choices. Both are tough for most zerg bots to handle. My other prepared build, ZvZ_Overgas9Pool, does not appear in these 100 games. Apparently it flopped and was abandoned early. Rushy builds ended up winning faster than they lost, and more macro builds were the reverse, as you might expect. The timing table shows that McRave went spire nearly every game (overlords do not count as “air units” there), and not slowly. That’s normal for ZvZ, of course, but it shows that McRave did not favor builds to overrun the opponent with zerglings.

WillyT has become much stronger over the past year. It is better at handling Steamhammer’s lurker builds—except for the especially early 9 pool lurker build, which apparently catches it unready. Steamhammer’s improvements in lurker play were important to keep up with progress. I think Steamhammer’s diverse mix of openings was essential to counter WillyT, which has its own diverse mix and will figure out how to counter anything that is too predictable.

Steamhammer’s closest game of the tournament was Steamhammer-WillyT on Empire of the Sun (replay file). Steamhammer decisively stopped WillyT from taking the nearby north island base, but allowed it to hold the distant south island despite scouting it the instant it started. Notice WillyT’s interesting but somewhat uncoordinated dropship play throughout the game.

Microwave had too many weaknesses. Of the 4 openings with 80% plus win rates, 3 were from preparation and one was Steamhammer’s discovery during the tournament. It’s interesting that the 12 hatch build ZvZ_12HatchMain was faster to win than to lose. I think that means it won with zerglings from its extra larvas.

The plan table shows that Microwave followed its own broad range of plans. In the timing table, see the wide and matching variation in Microwave’s gas timing and air unit timing. Did Microwave never get zergling speed in long games?

After this upset, I think I’ll take DaQin as a test opponent and finally figure out the skills to defeat it. DaQin is a Locutus fork, so beating it probably means doing better against other protoss bots.

The timing table shows that DaQin was remarkably late with air units. That includes both corsairs and observers—DaQin was late with both of them. In fact, I don’t remember whether it makes corsairs at all. Mutalisks might be a good choice to win.

When I was preparing opponent-specific data, Steamhammer had an overwhelming score against FreshMeat on BASIL. This result is good but not overwhelming; FreshMeat improved a lot in a short time. I had recognized that FreshMeat had made great strides, but there was not enough recent data to show what was working in the most recent games. So I made no preparation at all. These tables show an example of how Steamhammer figures out an opponent from scratch. I think it did OK.

Comparing this year to last year, Steamhammer actually did a little worse against UAlbertaBot. The skills I improved over the last year didn’t include skills to defeat UAlbertaBot’s pressure builds, or to adapt better to its random race.

I picked five winning games to show off Steamhammer’s fearsome might, such as it is. I’m happy with the improvements in the tournament version, and if there’s more to do, then when it’s done I can be happy about that too.

Steamhammer used to defeat Locutus only when Locutus messed up severely, such as by trapping its own dragoons in its natural so that zerg didn’t have to face the whole army. And it still can’t touch Stardust. I was surprised to see a couple games where Steamhammer beat Locutus by straight up outfighting the dragoons. See Steamhammer-Locutus on Fighting Spirit where zerg won impressively with All The Macro, and Steamhammer-Locutus on Jade where zerg was unable to keep a third base up for long, but still wrested a win. Some of the credit is due to the smarter upgrade choices versus protoss, though the burrowed zergling preventing expansion was key, and Locutus did supply block itself. Here’s a picture from the second game. It may look as though zerg has 3 bases beyond its main and natural, but 1 is already destroyed (you’re seeing burrowed drones on the minimap) and the other 2 will be.

Steamhammer has also been taking games from Halo by Hao Pan. That’s not new, but I like the promise it shows. Some wins are with a one-base mutalisk build: Steamhammer-Hao Pan on Fighting Spirit. I was intrigued by Steamhammer-Hao Pan on Roadrunner where Halo was winning after a vulture-wraith build and putting on continual pressure, while Steamhammer struggled with awesome determination for longer than seemed possible. The new static defense code provides for stubborn defense. Instead of winning, Halo suffered some kind of production bug, fell behind on macro, and slowly lost. I suppose it is the result of Hao Pan concentrating on Fresh Meat, but Halo is still higher ranked than Steamhammer. This is why you don’t resign too early in bot versus bot!

Steamhammer-MadMixP on Medusa shows off cannon-related skills of both bots. MadMix cannoned behind the zerg minerals, a great skill which I haven’t seen from any other bot. Steamhammer could not fight so many cannons, but it showed its own rare skill: It mined only the mineral patches that were outside cannon range. It’s not a new skill, but I’m proud of it. Unfortunately the drones that were not allowed to mine dangerous minerals idled around the base “waiting for them to open up” instead of being transferred elsewhere, but one step at a time! Steamhammer knocked down the undefended protoss main, expanded there itself, and clumsily but inevitably defeated the cannons for the win.

I recommend making no more than about 4 cannons, then adding gateways at the proxy instead. Zealots have the power to, you know, move around and hit stuff that’s outside immediate reach. The only extra smarts the zealots need is the ability to retreat toward the cannons when outmatched and fight within cannon range.

UAlbertaBot comes with a system of timers: It divides the bot’s work into aspects, and for each frame times how much time was spent on each aspect. Steamhammer inherited it. Overkill also inherited it, and if you’ve seen Overkill play on the SSCAIT stream then you’ve seen its timer display in a big black box smack in the middle of the screen. On a standard Broodwar screen, much smaller, the box is in the lower right.

The display only shows the times for one frame. I found it less useful than it could be; you have to be watching closely to see any spikes in specific aspects. So yesterday I extended it to remember the high water mark for each aspect, the longest time it has taken during the game. If there are time usage spikes, I can quickly get an initial idea of where they are.

At the time of the picture, Steamhammer’s supply was 187. Some of the aspects of play named down the left are the same as UAlbertaBot’s; others are new or changed. The bars represent time in milliseconds for the previous frame, the same as the first column of numbers. The second column of numbers is the peak time in milliseconds. (I decided that drawing the peaks on the bar graph would compress the real-time display too much.) Worker management, production, building construction, and combat are the most expensive aspects. Search means BOSS search, which does not happen for zerg, so the 0.4ms peak probably means that the OS dropped in that much delay at some point. The Tasks are a couple of jobs that the bot already did that I converted into tasks, nothing new yet.

If I run into slowdowns in the future, maybe I’ll extend it more and keep a histogram for each aspect to see how often it is slow.

The code that does the timing is straightforward and exactly like UAlbertaBot. Here’s the code to time the Info line of the display.

    _timerManager.startTimer(TimerManager::InformationManager);
    Bases::Instance().update();
    InformationManager::Instance().update();
    _timerManager.stopTimer(TimerManager::InformationManager);

I have decided what tactical skills to work on. My list included skills for specific units: Mutalisks, the most important; lurkers, which I’m most interested in for now; scourge, which Steamhammer spends heavy gas on and doesn’t always use well, defiler skills because Steamhammer often reaches late game. But those are only single unit types. And unit coordination skills, like storm dodging, scarab dodging, mine clearing and mine dragging, making the best use of the dark swarm that is on the map—all needed, all narrow and specific. And tactical analysis, my initial favorite. I have an algorithm in mind, which calls for a fast combat evaluator. MaasCraft’s tactical search also uses a fast combat evaluator. My idea is different, and I’m not satisfied with MaasCraft’s evaluator. Thinking through what’s needed, I concluded that the first draft would be easy to write, but would produce poor results. I think it’s likely that it needs a sophisticated combat evaluator to work well—I have an AI algorithm in mind for that too, but I fear I can’t finish it in time for SSCAIT in December.

To make the most progress before SSCAIT, I decided to work on the next level of pathfinding skills. Steamhammer currently calculates terrain paths without regard to where the enemy may be. On an empty map, ground units reach their destinations without getting stuck on terrain. When a unit is trying to reach its destination safely despite the enemy, a scouting unit or a drone transferring to another base, the unit reacts to dangers by leaving its path and running away from the enemy. It is not able to figure out a way around (though it may blunder into one), and it is not able to tell when its path is completely blocked and it should give up. So overlords scout less safely and less efficiently than they could, and worse, drones trying to transfer may end up burrowed all over the map, wasting supply and risking their lives to achieve nothing.

Steamhammer needs true safe pathfinding. It has to recalculate safe paths when the enemy is sighted. That opens the door to a lot of more specific skills.

• Don’t send drones to a place you know they can’t reach. This alone would save many games.
• Don’t even spawn extra drones inside a tight contain. They won’t get out.
• Better scouting, from maneuvering the early scouting worker to moving overlords and the Recon squad.
• Calculate least-danger paths for harassment. You can take hits as long as you escape.
• Similarly for drops.
• Reach safe spots to attack walls or other stuff from outside enemy range.
• Enemy vision is a kind of danger too. Find sneaky paths.
• Path through nydus canals. Nydus canals are part of my plan to support islands.

I don’t know how many of these I’ll get to by SSCAIT. There is a lot to it: Ground units and air units have different needs, safe paths and least-danger paths are different, sneaky paths are different. Safe drone transfers are the biggest weakness and have top priority. Part of the solution is to spread hatcheries out more, rather than putting all macro hatcheries in the main.

The first part of the job was to create a task manager to run background tasks. It’s simple, I wrote it yesterday. The idea is that pathfinding tasks will update safe pathfinding data structures behind the scenes, so that the calculation load is spread out and the data is reasonably up-to-date. Over time, I expect to add a lot of other kinds of tasks. Steamhammer runs fast, and for now there is little risk of overstepping the frame time limit. (Even in the late game when maxed, most frames take a handful of milliseconds, and spikes above 20ms are rare.) But I have thought up plenty of complicated tasks, and it seems likely to become an issue someday. I want the infrastructure to be ready, so that I can implement a principled solution instead of refactoring a lot of code when the day arrives.

According to tradition, a new Steamhammer version drops in elo on BASIL at first. It takes around 2 months for changes to settle into the learning data before the elo reaches a new equilibrium. The new AIIDE tournament version has broken tradition and started out with an elo rise instead. It’s an early sign that I may have a successful version.

Last night I uploaded the “bug fix” version 3.5.11 to SSCAIT and SCHNAIL. It has 9 small changes over the tournament version of Steamhammer, a lot more than I planned. Only 3 changes are proper bug fixes. All of them are meant to prevent bad behavior or use resources more efficiently, so they fix play bugs if not code bugs. For debug flags, this time I turned on drawing of not only the clusters but also the combat sim info (drawn alongside the cluster info and in combat areas) and the static defense plan. It makes for a busy display.

operations

• Estimate when one of our bases is doomed to be destroyed, so that we can stop spending resources on it. Any code that wants to know can call base->isDoomed(). For this first pass, I made it conservative; it checks a few conditions and does a quick comparison of defenders to attackers to see if the fight is very lopsided. If it says the base is doomed, then it is under attack and there truly is little chance that it can be saved (though you never know, maybe the opponent will do something else). The feature has many uses that I’m sure I’ll get to, but for now only one is implemented (keep reading).

static defense

• Don’t add more sunkens or spores at a doomed base. They’ll die too and accomplish nothing. The weakness was glaring; now it should be only staring.

• Limit front-line sunkens versus terran to 6 at most, 5 at other bases. (Against bots, rather than humans, Steamhammer makes at most 1 sunken at other bases, to prevent casual raids. Almost all bots concentrate on attacking the main with its front line.)

• The plan/execute loop runs more often, to reduce the delay in adding defenses when in a hurry.

• The controller could mistakenly order multiple copies of a prerequisite building, like a forge for cannons or an evolution chamber for spore colonies. Fixed.

• There was one last place where a building was posted directly to the building manager instead of queued for production: The prerequisite building. Fixed. It caused no known bug, but queueing the building likely avoids rare problems.

zerg

• Fixed a production freeze that was possible when the enemy went mass air. This was an interesting one, because it was a completely different mechanism than any other production freeze I’ve seen. In the unit mix calculation, if the best unit for the mix was devourers and we already had as many devourers as we should, then the code rejected the choice it had committed to. The unit mix fell back on the default, drones as the only unit to make. By the time this happens, it is late in the game and Steamhammer already has as many drones as it wants. So it replaces lost or used drones, makes urgent units like scourge, keeps up with its upgrades... and produces no other units. The fix was to reject devourers up front in that case, so that the calculation finds a different best unit.

• If we have excess minerals and gas, make a lair and/or research burrow solely to use up some of the excess. It happens occasionally, and if the game continues we’ll want both eventually.

• If air carapace has reached +3 and we still have many mutalisks and/or guardians, start getting air attack upgrades too. Might as well, I figured. I uncommented a snippet of code that I wrote years ago, back when Steamhammer’s air upgrades never went beyond +2.

SCHNAIL players who try out Steamhammer often play a series of games one after another, and if they liked it they come back another day for more. I’ve watched enough of these series that I have a sense of the patterns they follow. Everybody’s different, of course, and Steamhammer’s play has random elements too. But often enough, a series with a terran or protoss opponent who is well-matched with Steamhammer more or less follows a prototypical sequence of four steps.

1. Get busted. Steamhammer is tuned against bots, where early aggression is successful, so it often starts out with a bust. Apparently many humans at this level are not quite prepared. Against terran it breaks in with zerglings or lurkers, against protoss with lings, hydras, or mutas. (Terrans are ready for mutalisks.)

2. Tighten up defenses. Players at this level figure out how to stop an incoming Steamhammer rush within a few games. That’s typically good for two or three wins before Steamhammer tries something else.

3. Get overrun by macro. Players at this level also tend to be too passive. Maybe macro and scouting and whatnot uses up their bandwidth, or maybe they’re used to being fine if they stay at home for a while. If the player goes active and begins attacks too late into the middle game, Steamhammer has already started to outmacro them and, even if it loses bases along the way, will finally win with hive tech.

4. Learn to attack actively. And players at this level don’t take long to understand how to react to zerg macro: Don’t let the zerg macro, but attack expansions aggressively. The new static defense code makes more sunkens at exposed outer bases against humans (not against bots), which helps them survive. But Steamhammer is not strong at defense, and players are fairly successful at taking the bases down anyway. After figuring this out, the human player will win games indefinitely, sometimes all games. If the two are closely matched, the games may be long and difficult.

Alternately, a terran may make one big timing attack into the zerg natural, and break through. Steamhammer can usually deter this plan versus protoss.

It seems to me that if you start out struggling to beat Steamhammer, and without using any special anti-bot tricks learn to defeat it, then you must have improved your play. Tight defense and active play are good. The same skills you polished to beat the bot will help you against other opponents.

Of course, many series don’t go this way at all. A player of different strength may get all losses or all wins. Several days ago one player played a long series of cannon rushes on the 2-player map Destination, first trying to push cannons from the side of the zerg base, then in later games switching to cannon the natural. The rush, after adding proxy gateways, often eventually destroyed the zerg main, despite being slowed by defenses, and units from the proxy gates were then able to move out and destroy more bases. But protoss was never able to stop zerg from expanding, and ended up losing every game, usually after defensive cannons in the protoss base suddenly fell. Steamhammer made many missteps, but I was pleased with the defense against cannon pushes. This was likely a player trying out the strategy for fun.

The AIIDE 2021 tournament version of Steamhammer is available for download at Steamhammer’s web page, as binary and source.

It’s a strangely long time since I have formally released a version. Well, hiatus over.

Steamhammer 3.5.10, the AIIDE 2021 tournament version, is uploaded to SSCAIT and SCHNAIL. I chose to turn on DrawClusters this time as the debug flag to entertain watchers, because it now draws enemy unit clusters as well as friendly ones. I’ll post the source before long.

Next up will be Steamhammer 3.5.11, a bug fix release. It seems that I often issue bug fixes shortly after tournament versions, because there are a few things I wish I had gotten done in time. I don’t intend to take long with it. It will include the production freeze fix that I mentioned in the change list, and likely a few other quick items.

After that, it is time to re-evaluate my priorities again. Earlier, I had planned work on opening timing, and started some of it. Then I had to wait for data to accumulate before I could dig in deep, and my motivation flagged. Now the data has accumulated, but the skills I wanted to gain from opening timing no longer seem like the most urgent for Steamhammer: It is losing games for different reasons than back then. When I made the analysis that led to the opening timing decision, Steamhammer was losing due to poor opening choices and strategic mistakes. Now it seems to me that its losses are more often due to tactical weaknesses. The old problems are not fixed, but neither are they foremost; the scene has passed them by and exposed different problems. Maybe my changed analysis comes from watching SCHNAIL games? That’s probably one reason.

I want to improve tactical play somehow. I wrote down a number of medium-size projects that promise progress and that I could reasonably complete in time for the annual SSCAIT tournament in December. Some are work on tactical control of units that need help, and some are more general skills.

They’re all important, and I haven’t decided. At the moment I’m leaning toward doing the tactical analysis that I’ve often mentioned. The tactical analysis would provide an information framework for squad tactics and other decisions, so it’s logical to do first. With new priorities, the version after the bug fixes of 3.5.11 will be 3.6.

Besides one multi-month project, I need to put some level of effort into solving a few critical tactical weaknesses. Number one is indecision between advancing and retreating, the constant back-and-forth of the front units. It causes losses that add up quickly, and it happens virtually every game. Number two is defense when closely contained outside the sunken line, which is outright broken—units take fire without shooting back. Against humans, much more than bots, a key ZvP weakness is lack of storm dodging. Bots storm poorly. Storm dodging is a solved problem, so I hope the implementation won’t be hard.

Steamhammer 3.5.10 is the AIIDE 2021 tournament version. The current version on SSCAIT and BASIL is 3.5.2. The change list covers everything in between. I’ll upload the new version shortly, and source before long.

I wanted to improve lurker play to the point of having working lurker contain skills, but it was too ambitious for the time available. Even so, the improvements to lurker play should be easy to see. I soon decided it would be more effective to work on smaller fixes. There are always many short to-dos that each make a difference... because they accumulate faster than I can retire them.

tournament preparation

• Special preparation against 9 prospective AIIDE 2021 opponents—the ones it might make a difference against, plus Stardust where Steamhammer is at risk of scoring zero. I followed the same preparation plan as last year: For each opponent, choose a small number of builds that have historically won, or that seem to have good chances, and enter them into history as fictional single winning games. Let learning do the rest.

It amounts to giving hints “try this a few times before giving it up.” Steamhammer has a better chance of finding good builds early, and is not weighed down with masses of outdated learning data if the opponent brings surprises.

information

• Remember whether the enemy has used psionic storm this game. I wanted to feed the information into lurker spacing decisions, but ended up not implementing lurker spacing, so the feature is unused for now. There are other potential uses.

static defense

Changes to static defense include tuning to make the right amount in different situations—zerg static defense is expensive, and needs to be worth it. I think the tuning is improved versus terran, fairly good versus protoss, and still weak versus zerg.

• Fixed a crash due to division by zero. The bug fix does not affect strength, because the crash only happened when Steamhammer had no bases left. Yes, it was dividing by the number of bases. How easy it is to forget that you may already be dead! For my part, I forget that nearly every day.

• Morph forgotten creep colonies into sunkens or spores, if and when they happen to be needed. The building manager sometimes slips up and forgets to morph a creep colony that was intended to become static defense. If defense is not needed, it will remain a creep for the time being. When the static defense planner decides that it is needed, it may turn into either a sunken or a spore. At some point I’ll implement tactical analysis and Steamhammer will have an idea of when the enemy might attack in strength. Then it will be able to leave all colonies until they are needed.

• Try to place spore colonies in the mineral line, rather than somewhere vaguely near the hatchery. This helps ZvZ the most.

• Make one sunken colony less per base, compared to before.

• If the enemy has many tanks with siege mode, sharply limit the number of sunkens. They become a waste of minerals.

• Make more spores versus mass wraiths and mass scouts.

buildings

• Anti-cannon sunken reaction failed due to errors in building placement introduced in a recent version. Fixed.

• Other attempted improvements to anti-cannon sunken placement.

• Added configuration option Config::Skills::UseSunkenRangeBug so that I can turn the feature off when it’s not allowed. It’s part of building placement; see BuildingPlacer::getAntiCannonSunkenPosition(). It’s off for AIIDE, where use of the bug is not allowed. It’s on for SCHNAIL, since it’s allowed in human games.

• Steamhammer might try to build a macro hatchery directly on top of the main hatchery in the opening. The hatchery failed to build and the drone assigned to build it was left idle for a time, a serious breakdown. Fixed.

• In rare cases, a building might be placed invalidly so that it could not be built. Fixed.

squad orders

• Each squad keeps track of the last time its order was changed to a different target. It also remembers the most recent frame that any cluster of the squad attacked, and the most recent frame of a retreat. (“Attack” usually means that the combat sim said “go attack”, not that any unit fired a shot.)

• The above info is used by the air squad in deciding whether to keep attacking its current target, or seek an undefended target of opportunity. If the last attack was a long time ago and the last retreat was just now, then the mutas are sitting around and should try another target. They look for the closest undefended thing and try that instead. Unfortunately, the closest undefended target is often as inaccessible as the original target—it can be attacked in theory, but Steamhammer doesn’t have the smarts to do it in practice. So far, the feature is not worth the effort I put into it. I think it will become worth it when I implement more pathing and harassing skills.

• In defense, defeat enemy proxy pylons when nothing more dangerous threatens. There was always code to do this, but it was broken in a subtle way. The method for assigning units to squads is too complicated; I’ve got to find a better idea.

• In defense, count an enemy proxy creep colony as 2 units, not 1. When pulling drones to defeat the proxy before it can finish morphing into a sunken, Steamhammer will pull 4 drones and win the fight instead of 2 drones and lose. (3 drones would be ideal, if no other unit interferes.)

recon squad

The Recon squad has been a valuable feature ever since I implemented it. But lately Steamhammer has become strong enough that Recon’s weaknesses are hurting. For example, classically the Recon squad only pays attention to units that it can see, ignoring the remembered positions of enemy units, because its purpose is to see what’s going on. But suppose the squad consists of 1 zergling and it wants to scout an area defended by a sieged tank. The ling approaches to see, gets splatted by the tank. Another ling is assigned, approaches, splatted, etc., until the target times out. The process is, as people say nowadays, unsustainable.

I made 3 changes. None is critical in itself, but together they make the Recon squad safer and more effective and count as an important improvement.

• Combat sim attends to all enemy units, as for other squads, not only visible enemy units.

• When the squad is restored after it has become empty (for any reason, not only losing all units to the enemy), reset its target to somewhere else.

• Don’t assign the squad a target that is already in view. If the Watch squad or an overlord can see the target, the Recon squad doesn’t need to. As always, if no targets need scouting, disband the squad.

irradiated squad

I improved the behavior of irradiated units, but it still doesn’t work as intended. I’m convinced that bugs are hidden somewhere in the infrastructure code, not in the top-level decision code.

• The code was already clean, but I simplified it a little more.

• An irradiated unit keeps farther away from its friends than before. This is the most important change, even though the old distance was already outside the irradiation splash range.

• Flying units seek in a wider radius to find enemy units to splash radiation onto. Mutas are fast and may get there in time to do a little splashing.

• A slight change to burrow decisions.

scouting

• Release the scout worker early in a few special cases: If there is an overlord nearby to continue the scouting work; if the scout runs into a completed enemy bunker or photon cannon. There are details to the conditions; for example, if no enemy unit type has been seen yet beyond those the enemy had at the start of the game, then the scout stays on the job. Steamhammer usually scouts early, and returning the scout is economically good. An enemy bunker or cannon (if not a proxy) means on the one hand that the scout cannot advance, and on the other that the enemy has no intention of attacking right away, so Steamhammer can return the scout now and wait for zerglings to arrive to keep watch.

squad tactics

• Don’t retreat forward if the enemy is near at all. The feature was meant to fix the case where one cluster of units is attacking the enemy, while a smaller cluster farther away was afraid to approach because it could not win on its own. But if an enemy was between the two clusters, which could happen despite a triangle-inequality test to try to prevent it, the cluster retreating forward would walk through the enemy and get shredded. Instead, a Regroup cluster close to an Attack cluster is itself changed to Attack in a second pass through the cluster status decisions before they are executed. The failure cases are non-horrible, and the change fixes one of Steamhammer’s biggest tactical weaknesses. At some point I’ll rewrite it so that clusters fighting the same enemies are treated together, not separately, but that’s for the future.

• Enemy unit clustering is turned on, so that known enemy units are grouped into clusters just as Steamhammer’s units are. The config option Config::Debug::DrawClusters draws the enemy clusters in red circles to contrast with Steamhammer’s clusters in white circles. The enemy clusters are used in various decisions at the cluster and unit level.

• An unhandled case led to poor lurker retreat decisions. I rewrote the code to simplify it and fix the bug.

• When retreated all the way to the retreat point, lurkers burrow and tanks siege. Formerly, both remained ready to move, which meant that they were unready if the enemy advanced. It may not sound important, but it’s a big improvement. Indecision between advancing and retreating is common, which causes the familiar burrow/unburrow frenzy, but it’s a net gain by a wide margin.

• When retreating, count a sieged tank or a burrowed lurker as immobile defense, an option to retreat toward. Formerly, Steamhammer only looked for static defense.

• When seeking a cluster ahead to join this cluster with, use the squad’s order distance instead of the air distance. The order distance is the ground distance for ground clusters or the air distance for air clusters. This fixes some poor decisions made by ground units near terrain features.

• The code to retreat behind static defense was rewritten to be correct for a change. The actual behavior doesn’t change much, though.

• Be a little quicker to declare overlord danger at a base, so that new overlords are not spawned there to die uselessly.

combat sim

• The configuration option Config::Debug::DrawCombatSimInfo now draws information for each cluster, rather than for the most recent cluster simulated. It shows both the raw and the smoothed attack/regroup results, so you can see how the raw results flip-flop more. Combat sim is that much more debuggable—still not very.

• A bug could leave the combat sim in an out-of-date state. Fixed. The bug (mentioned earlier in Steamhammer is progressing) is responsible for most or all of the 50-100 elo strength loss on BASIL in version 3.5.2. It’s what caused units to sit back instead of, say, attacking an undefended base.

• The radius to look for enemy units to include in the combat sim is altered to match what the Squad code does. I think this is a no-op; the enemy units that end up included are those in range to fire into the combat radius, which is different. But it looks tidy.

micro

• Cancel a dying egg, cocoon, or unfinished building 1 second before it is predicted to die, not 5 seconds as previously. Lurker eggs were being canceled almost the moment they came under attack, which was bad. The gain of canceling items later outweighs the loss of a few units that come under sudden massive attack and die before they can be canceled.

• In figuring out which direction to kite a hydralisk, Steamhammer knows not to kite back into its own ground units—they are in the way. But it did not check whether the units were burrowed. Hydras had trouble kiting when near burrowed lurkers, because escape paths appeared to be blocked. Fixed.

terran

• Slightly improve the stim calculation, so that marines overstim a little less. It’s a change made in passing while I was working on other stuff, under the rule “if you see it now, fix it now.” (If it were possible to follow this rule all the time, there would be no such thing as technical debt.)

zerg

• Macro: Steamhammer did not always make enough macro hatcheries due to a bug. That hurt a lot. Fixed.

• Macro: Make no macro hatchery unless there are at least 3 drones per base. Yeesh. It sounds basic, but the drone count never entered into Steamhammer’s calculation of whether it needed a macro hatch. This is a lenient limit that prevents rare egregious blunders (which I have seen happen). I expect I’ll tighten it in the future, one way or another.

• Macro: I noticed that Steamhammer sometimes became briefly supply blocked in the early middle game. I tweaked an overlord timing parameter by 1 point of supply, which fixed it.

• Macro: Fixed a potential production freeze related to air upgrades. This is a rare freeze; I'm not sure it has ever happened. When I fixed it, I thought it was a less-rare freeze that can happen when the enemy goes mass air. Then I discovered I was wrong. I have fixed the more important freeze, but not in time to get it into this version.

• Queue sunkens ordered by the strategy boss (as well as those ordered by the static defense boss, a change made in version 3.5.2), rather than posting them directly to the building manager. I never saw the old code cause a problem, but it’s likely that the change fixes rare misbehaviors.

• Queens: Be more flexible about parasiting high-priority targets instead of waiting for a good ensnare or broodling. If there is no tank in sight and the queen suddenly notices an enemy dropship, it should know what to do. A parasited dropship cannot surprise you.

• Queens: Get ensnare much less often versus terran, and a little less often versus protoss. I find the improvement in terran play to be visible.

• Defilers: A defiler that is about to die wants to cast a last spell. It’s done in part by a hit point test. Formerly, if the HP were too low but the enemy was gone, the defiler might (say) swarm itself, then consume, then swarm again nearby because the HP were still low, etc. There was often little or no gain, and the consumed zerglings did not appreciate it. Now the defiler only casts its low-HP Hail Mary spell if the enemy is around to shoot at it. (Being irradiated, stormed, or plagued also brings a Hail Mary.)

• Lurkers: Avoid burrowing in tank or cannon range unless friends are along to help. This reduces the tendency of lurkers to rush in where angels fear to tread, though they’re still pretty foolish.

• Lurkers: Undetected lurkers look around harder for dangerous enemies nearby before unburrowing.

• Unit mix: Discourage guardians more overall. Discourage ultralisks and encourage hydralisks versus battlecruisers more. Favor hydras a little more versus wraiths. I think guardians may finally be tuned almost acceptably for Steamhammer’s current poor skill with them.

• Unit mix: When seeing 2 or more starports and no other air units, assume wraiths are likely and nudge the unit mix toward countering them. Steamhammer doesn’t make many predictions, but this one seemed important.

• Unit mix: Dark archons discourage queen production, though they don’t always eliminate it.

• I found that some urgent defensive reactions were happening too slowly. Therefore, first, call makeUrgentReaction() twice as often. Second, when making an anti-cannon sunken, it is allowed to start the creep colony before the spawning pool finishes. (Starting the creep before the prerequisite finishes for the final morph to a sunken or spore was already supported in other cases.)

• Upgrades: Better code for ground upgrades. Historically, in long games Steamhammer went for ultra-ling in all matchups, and I wrote rigid upgrade code to match. It got carapace and then melee attack upgrade, and that’s all, correct preparation for the ultra-ling unit mix, with an exception added later for ZvZ to get melee attack first. Today Steamhammer varies its unit mix more sensitively depending on the situation, and may stick with or switch to hydralisks in the late game if they’re called for. I rewrote the code to be simpler and more flexible. In the planning phase, code puts any or all of melee attack, missile attack, and carapace into priority order depending on the matchup and game situation. In the execution phase, code assigns the top priorities to available evolution chambers.

In ZvT, Steamhammer gets missile attack if it is making hydras to fight goliaths or battlecruisers, because the terran is likely to stick with them. In ZvP, Steamhammer likes hydras and usually gets missile attack first and carapace next, though it depends. In ZvZ, with less variety, upgrades are about the same as before, except that there are extra rules if hive tech is reached. To my eye, play is clearly improved, especially in ZvP. Though the behavior is a lot more complicated, the total code size is small and about the same as the old rigid code.

• Upgrades: Fixed a minor bug where Steamhammer thought it could upgrade in an uncompleted evolution chamber. The worst case result was that the bot might slightly underspend its money on this production round.

openings

• Overgas+1 build added to use more of that fast gas. Only one new opening! Is it a record low?

Tomorrow: What’s next for Steamhammer?

Steamhammer is all set for AIIDE. I’m still making checks and running tests to be extra-duper-sure, but I’m convinced that this is the strongest and least-buggy Steamhammer ever. It hasn’t been uploaded anywhere, so nobody will be 100% ready for it... though I guess Stardust will be 99% ready. I plan to submit it today, a day ahead of time.

I’ll post the change list in a day or so, and the code after the submission deadline is safely past.

Here’s a short and surprising game from SCHNAIL, Steamhammer vs leftchange (T) on Heartbreak Ridge. Terran played an unusual and sneaky proxy. Steamhammer scouted it thanks to the anti-proxy overlord, and its first reaction was almost good; it did things right except for misplacing the sunken because sunken placement is optimized for stupid bot opponents. Steamhammer countered the empty enemy main, and soon neither player was able to mine. But there was a clear winner!

Today’s ASL 12 matches had another surprising and close proxy game with much better play, Soma vs JyJ on Polypoid. It starts at about 34:00 in this round of 16 group A vod with commentary by Nyoken and Scan. (I watched it “excluding restricted content” and didn’t miss anything that I noticed.)

Steamhammer is feature-frozen for AIIDE 2021, so that I don’t risk breaking my good version. Well, maybe not entirely frozen, but reduced to a low temperature (keyword simulated annealing). I will fix bugs and prepare for specific opponents, and I’ll probably also make small feature tweaks if they are safe.

My change list right now has 54 items on it, 14 of them marked as important changes that significantly improve play. With that many, obviously none of them is a big project—there hasn’t been time! But major weaknesses are fixed or reduced, affecting the whole range of strategy, tactics, and micro; all levels have important improvements. I’m pleased and optimistic. (Of course I was optimistic before AIST S4, and then Steamhammer lost 0-4, so....)

For one new feature, I ran a test that involved adding a spore colony at every base. At supply 7 (very early, before the spawning pool), Steamhammer started an evolution chamber and made a spore in the main, and then added a spore at every new base for the rest of the game. The opponent didn’t matter for the test, so I ran it against the protoss built-in AI. I was tickled that, even with the giant handicap, Steamhammer won several games in a row with apparent ease.

In Steamhammer 3.5.1 (see the “zerg” section) I added a defense against cannon rushes which exploits the sunken range bug. The bug makes it possible, under specific conditions, for a sunken colony to target an enemy which is outside the sunken’s range. Exploiting the bug is allowed in human tournaments. In fact, it’s a standard defense against cannon rushes, one that players know and use. An example is ASL 11 Semifinal A, Mini vs Queen, game 1—see about 32 minutes into the vod for a complicated sequence where Mini eventually abandons the cannon rush knowing that it has been countered, and notice that casters Nyoken and Scan have little trouble understanding what happened and why.

At the time I wrote “Use of this bug seems to be universally legal,” but today I checked the AIIDE rules more closely. The rules include a list of allowed bugs to exploit, and add “All other bugs/exploits are forbidden.” The sunken range bug is not on the list.

I sent e-mail to Dave Churchill explaining the situation and its complexities. He’s busy and I don’t know if he’ll have time to look into it. Basically, I’m expecting to disable the behavior in Steamhammer for the tournament. I’m adding a configuration setting Config::Skills::UseSunkenRangeBug so I can turn it on and off.

Most likely no AIIDE 2021 protoss will cannon rush at all, so in a way the point is academic. But who knows?

what should the rules say?

It’s complicated!

The range bug is a game behavior, and it can happen unintentionally in real games, just because events happen to trigger its conditions. It’s fairly rare, but I expect all who play regularly have seen it (whether they recognized it or not). Bots should not be penalized for game behavior that they did not intend, and have no reason to even notice.

Steamhammer deliberately attempts to exploit the bug to beat cannon rushes. I have to interpret that as a violation of the AIIDE rules as they are written.

If you’re actively trying to enforce the rule, how would you do it? First, you’d have to examine the games, presumably with replay analysis software since there are too many to watch in person. Then you’d have to decide whether at least one instance of the bug was a deliberate exploit. That likely involves reading the code to be sure. Tournament organizers are not going to go to so much trouble, so probably the only practical enforcement would be for other authors or observers to point out possible infractions after the fact.

Then there’s the point that exploiting the bug is legal in human play, so presumably it should be legal in bot play. But that has a hidden assumption behind it: Humans can’t or don’t exploit the bug in any way that seems unfair, therefore bots won’t either. It might be true, but how sure are you? Bots with perfect timing and simultaneous view of all information might be able to exploit the bug in a way that feels unfair. Then the rules would be unfair.

Maybe it’s right to allow exploiting the range bug unless and until some bot implements an unfair exploitation.

Even if it may be a good idea to change the rules, it’s no good to change them close to the submission deadline. The rules for this year should stay put. Next year’s rules may be open to debate.

Update: I have mail from Dave Churchill. After some flip-flopping, the final ruling is “INTENTIONAL use of this bug via any specific code that invokes it is not allowed.” That follows the original rules.

When I uploaded Steamhammer 3.5.1 to SCHNAIL, with new weaknesses, the bot lost 200 elo or more and also lost its popularity as a SCHNAIL practice opponent. I guess it’s not as much fun to play an opponent that sometimes plays fine and other times arrays all drones in front of the natural to make sunkens and then has no money to morph them. The bugs are fixed now. Elo is still lagging—elo changes slowly because there are not many ranked games—but Steamhammer’s popularity for practice returned suddenly. The players are getting information from somewhere.

In unrelated news, the name “Leta” is pronounced by some “Leeta”, by some “Layta”, and by some “Lehta” (which I guess is the correct one). In today’s ASL 12 round of 24 group E cast, Nyoken pronounced it all three ways in the space of a minute! Did anybody else notice?

I estimate that the Steamhammer version active on SSCAIT and BASIL, 3.5.2, is about 50-100 elo weaker than the previous active version, 3.5. The improvements are outweighed by new issues, the most important of which came from an “optimization” of combat simulation which sometimes fed it stale data. Oops. Advice to all persons: Do not make mistakes, they can hurt.

I fixed that yesterday. The only remaining new weakness (that I can see) is a tendency to sometimes overdo it on the sunkens. I trimmed that back with limits based on additional information. It is less severe than the earlier weakness of forgetting the sunkens or leaving them until too late, and there are other improvements besides. I have the strongest Steamhammer yet.

I have time for more improvements. Early signs for Steamhammer in AIIDE 2021 look good, provided I can follow my own advice to all persons.