Starcraft AI blog

Earlier I claimed that if Steamhammer has defilers out, it is probably winning. It’s true but misleading. Steamhammer’s game plan is such that it doesn’t try to win in the middle game (though it may win accidentally); the midgame is about holding the enemy off, getting upgrades, and growing the economy. When its drone count reaches 75, Steamhammer switches to all army production and its military strength grows rapidly—and that is the same time that defilers come into their own. When it reaches the late game, whether there are defilers or not, Steamhammer will be hitting hard and very likely winning, because if it weren’t winning it would probably have lost already. The late game is Steamhammer’s strongest phase.

Nevertheless, Steamhammer’s defiler usage has grown skillful enough that it definitely contributes to the bot’s strength. It’s an important milestone, because good defiler usage is critical to strong zerg play. Defilers are complicated, and zerg cannot reach its potential without mastering them. Steamhammer is far from mastering defilers, but I think it has become more adept with them than any other bot.

The original description of the defiler implementation is still accurate. Bugs have been fixed and refinements made, but the structure is unchanged.

that laser precision

I picked this game TyrProtoss-Randomhammer because it shows off Steamhammer’s precision and fluidity in defiler spellcasting. The precision was always there; the fluidity was reached by a long road with a year’s worth of bug fixes and other improvements. In the first picture, Steamhammer is about to start its decisive final attack. The attack would have won with or without defiler support. Accurate defiler spells made it effortless.

Steamhammer chooses plague because it looks like the fight will feature zealots versus hydras. The plague is actually a little weak. The defiler (selected and a little hard to see) is hemmed in by friendly units and cannot move forward, and Steamhammer hasn’t seen all the approaching enemies yet, so it plagues only 3 zealots. With a short delay for the opposing armies to close, it could have plagued more enemies, but it is not able to figure that out. Still, the plague helped in the battle.

Once the front zealots have died, Steamhammer has a fuller view of the situation, and realizes that the enemy has mostly dragoons left. The defiler (which has the energy upgrade) casts swarm, consume, consume, then a second swarm. The swarms are accurately placed to nullify the dragoons and drive the enemy back, bringing the fight into the natural. In the picture the defiler has just cast the second swarm, and it instantly consumes again.

The defiler is again stuck behind friendly units for a time, but protoss is forced back to the ramp. As zerg units spread out to raze the enemy natural, the defiler becomes free to move and drops a perfect plague on the ramp. Every protoss unit on the ramp is hit, and the zerg melee units that are in contact are untouched. No better plague is possible.

Steamhammer is awkward in maneuvering its defiler, and it is unable to foresee better opportunities that will arise in the near future. But when a spell goes down, it is often close to the best that is possible at that moment. It’s plenty good for now.

potential to turn the game

One defiler spell can make the difference between losing and winning. In practice, Steamhammer needs more skills before that will happen often in its games, but the examples here offer a foretaste. The game Steamhammer-McRave I picked to show the brute power of plague.

The first defiler of the game wandered carelessly into the front lines, stood on top of an isolated lurker, and got stormed to death. The defiler didn’t know the best place to go, that’s one weakness, and Steamhammer only makes 1 defiler at a time, that’s another weakness. An alert opponent can pick off the defiler and earn a respite. When the second defiler of the game joined the fray, this happened:

It’s a fun game, worth watching through. At the time of the picture, Steamhammer had been slowly twisting the situation into its favor from far behind, but McRave was still winning. The game could have gone either way. After this massive plague, turning a whole phalanx of zealots into straw, McRave’s army was broken and it quickly collapsed.

Here’s a picture from a different Steamhammer-McRave game. The red stuff all over the protoss natural is from 3 active plagues cast one after another by one defiler. The defiler just died; it sacrificed itself amidst the zealots (at the white spot of a dragoon hit) to get the third plague off, the one currently spreading over dragoons in the rear. The sacrifice was worth it. The protoss army was hollowed out, giving zerg time to consolidate an economic advantage and win. Without those plagues, McRave would have been able to move out and take the game with its bigger army (though I’m not sure it would have chosen to).

Here is a third example of a turnaround plague, from Steamhammer-MadMixT. After playing well much of the game, Steamhammer went astray and collapsed under a terran attack. It was about to lose its main and the game when a defiler risked its life to throw a plague over the core of the terran force, reducing the units to eggshells. Plague hurts terran more than protoss, which has shields. It then took only a few zerg units to clear the attack, partly due to terran’s disorganized movement, and with a return to superior play, Steamhammer slowly clawed its way to a win.

keeping active

Steamhammer is weak at using defilers in defense. I think it’s the widest remaining gap in defiler play. But it’s pretty good at using defilers in attack. I chose the game Steamhammer-MadMixP to show how, in the best case, Steamhammer can keep its defiler active through a long attacking sequence. The game itself is not very interesting, but watch the finishing attack which starts at around 17:30 from across the bridge to the terran natural.

It starts with a plague. If I didn’t miss anything, the sequence that follows is consume, consume, swarm, consume, consume, consume, plague, consume, consume, swarm, consume, consume, swarm, consume, consume, consume, swarm, consume, plague, consume, consume, consume, plague, consume, consume, consume, plague, consume, consume—and the last enemy building is destroyed. The defiler was stuck behind friendly units for short stretches, and otherwise busy every moment supporting the raging attack. Even though not all the activity was useful, the ability to keep constantly active is valuable.

blunders

Steamhammer does make mistakes in casting defiler spells, though rarely serious ones. Plague doesn’t account for moving units. It can miss fast-moving enemies altogether, for example trying to plague a group of corsairs and smearing only bare ground. In an active fight it can unintentionally plague its own units, which do not realize that they are moving into a danger zone. (It’s also perfectly willing to intentionally plague its own units, if that lets it splash more enemies. The calculation simply adds damage done to enemies and subtracts damage done to self.)

Dark swarm is thorny. Steamhammer only partially understands it. In Randomhammer-tscmoop2 the defiler cast a swarm that helped the enemy—with hydras on hand versus zealots and a reaver as well as the cannons and dragoons, swarm was a poor idea in the first place, and this swarm placement defends the enemy and does not open a path to attack. Oops. The research tab shows that plague was almost but not quite finished.

improvements needed

Why is Steamhammer weak with defensive dark swarm? To lay down swarm over lurkers and hold a position, or to force marines back with zerglings under swarm, you have to coordinate the swarm with the combat units. The defiler knows that swarm over lurkers is a great idea, and the combat simulator knows it too, in an approximate way. The lurkers themselves have no inkling; when their targets retreat, the lurkers will pick themselves up and obliviously step out of the swarm and die. Even something as simple as rendering hydralisks invulnerable to air attack is beyond Steamhammer. The hydras pay no attention.

Steamhammer’s squad code is already fragile from having too many skills tacked on, and needs to be rethought and rewritten. I’m reluctant to add complicated coordination skills before tackling that, so this weakness will likely be around for a while. It is a severe weakness, though, because defense is a critical use of defilers. Darn it, but there are times when only invulnerability can save you.

Besides the lack of coordination, there is no planning ahead. Defilers live in the moment and know nothing beyond. With prediction and planning, greater things could be accomplished with fewer resources.

More basically, the tendency of the defiler to get stuck behind friendly units reminds me that Steamhammer needs another fundamental skill: Smooth unit movement. Human players know that the defiler’s position is important, and move other units so that the defiler gets where it needs to be. And more generally, the missing skill shows in things like awkward movement through choke points, and clumsy collisions when squads cross paths.

I have a few simple ideas for how to control multiple defilers at once without blowing out cpu usage or seeing them simultaneously plague the same enemies. I expect I’ll implement that before SSCAIT this year. With 2 or 3 defilers in the Ground squad, defenders won’t have time to draw breath between spells.

Someday I’ll implement defiler drops. Zerglings with adrenal glands upgrade might as well be wrecking balls. Drop a defiler and some zerglings off to one side, swarm, swarm, and pick up the defiler for another go later while the lings rip down buildings. It’s cheap to do and expensive to defend against.

I finally uploaded the source for Steamhammer 2.3.5; see Steamhammer’s web page. Sorry about the delay. As I’ve mentioned, this is the same code as the AIIDE 2019 competition version, but configured to play all races rather than zerg only.

One of my steps in uploading a new version is to calculate the performance numbers of the previous version. By SSCAIT win rate, Steamhammer 2.3 (from last April) with 69% wins is the most successful version since Steamhammer 1.2 with 70% wins, way back in March 2017. And I’ve seen that the following test versions are stronger yet. This version 2.3.5 (and the tournament version 2.3.4 since it’s identical) has a new combat sim bug which makes it slightly weaker than the previous test version, 2.3.3, but I think it is still stronger than version 2.3. Steamhammer is doing well at the moment.

Before long I plan to release a new point version which fixes the combat sim bug and (just for fun) adds new queen skills. After that I’ll dig into strategy adaptation, which I expect will cause strength to plummet, because that is what major new features do at first. When strength recovers, though, it will recover to a higher level.

Next: A long post about defiler play, with examples and explanations. I also found a few research papers that I want to write up.

After every new Steamhammer version it’s time to come out with new plans for the following versions—plans that are always updated and sometimes changed beyond recognition. No plan survives contact with further consideration.

Despite my intention to stick to low-risk changes in the latest Steamhammer, I seem to have introduced a severe bug into combat simulation. I’m seeing cases of pointless fear, like ultralisks fearful to attack an assimilator, and Games Are Being Lost, which must not be. I need to make a point release to fix this bug, and possibly a few minor bugs besides.

But I don’t have the energy to fix bugs right now. I want to do something fun instead. I’m adding broodling for queens, and thinking about how to adjust the strategy boss so it can make more than 1 queen at a time without ever going overboard. Hmm. The rest of the code already supports any number of queens, at least in principle, but not the strategy boss. This is, by the way, another change of plans; I was originally intending to implement ensnare before broodling.

Related stuff that’s high on my list: Simple sample configuration file, for people who prefer to ignore the complex default config file with features piled over their heads. Up-to-date documentation. I promised a post on defilers. Oh, and I forgot to release source, I’d better do that next. I’d forget the period at the end of the sentence if it weren’t there on the keyboard to remind me

In the longer term, I need to go to BWAPI 4.4.0 and make progress on strategy adaptation. My thinking at the moment is that I’ll make the most progress by working with timings: The opponent model should record the timings and unit mix of opponent attacks, and compare them against the measured timings of Steamhammer’s openings to figure out how to counter an opponent. That’s only a small part of the full strategy adaptation suite, but it’s critical and it seems like a good piece to do early.

If you look closely at the source—you know, the source I forgot to release—you’ll find an unfinished and unused class BOSimulator which is a start on another essential part of strategy adaptation. I need to rename it, the name is confusingly similar to Dave Churchill’s BOSS.

For this upload of Steamhammer to SSCAIT, I turned on display of the strategy boss information. It’s kind of cryptic, so I thought I’d explain.

The top section, with all yellow labels from “bases” to “build”, describes the game situation and some automatic reactions that can happen at any time, including during the opening. The top section displays all game long. Then comes a slight break, and the bottom section, with multi-color labels from “eco” to the end, describes the strategy boss’s plans and conclusions after the opening is over. The bottom section only appears after exit from the opening book.

The strategy boss also cares about the game’s mineral count, gas count, and supply count. That’s why I draw the strategy boss info directly underneath Starcraft’s info.

bases 3/12 Steamhammer owns 3 of the 12 bases on the map.

patches 20 These 3 bases have 20 mineral patches total. This determines the upper limit of how fast it is possible to mine minerals.

geysers 2+0 Steamhammer has taken 2 gas geysers, and no more are available. If a geyser is in the process of being taken—the extractor is morphing—then it doesn’t count on either side. With 3 bases and 2 geysers, it could be that Steamhammer has 2 gas bases and a mineral only, or 3 gas bases and the final geyser is in the process of being taken.

drones 27/39 Steamhammer has 27 drones, including drones that are in the egg and haven’t hatched yet. It will spawn up to 39 drones; it believes that, taking into account the mineral patches and geysers, 39 drones are as many as it is reasonable to make.

mins 23 23 of the drones are mining minerals.

gas 0 None of the drones are mining gas. That leaves 4 drones on neither minerals or gas; they may be still in the egg, or may be carrying out other business, like building or scouting. But in any case, gas collection is turned off at the moment so that Steamhammer can collect minerals faster.

react +16 Based on what we’ve seen the opponent do, aim for 16 drones more than what we would normally build in this situation; they are “reactive drones.” A number as large as +16 usually means that the opponent is playing very defensively with many cannons, so that we can safely make extra drones to get ahead in economy.

larvas 0 There are no larvas available to spawn more units. Steamhammer takes a shortage of larvas as evidence that it may need more hatcheries (other factors count too). That might be why gas is turned off: To collect minerals faster to make a macro hatchery ASAP. (Though it might have concluded only that 911 gas is more than it needs for now.)

build +0g +0h This describes a complex strategy reaction that can occur in the opening book, and cannot occur later in the game. It connects with the “react” item above, the count of reactive drones. If there are too many reactive drones in the opening, they will bring in excess minerals, so Steamhammer takes actions to use resources more efficiently and prevent the excess minerals from building up unused. The actions are that it can take extra geysers—“g”—or make extra hatcheries—“h”. The extra geysers bring in extra gas so that income is balanced, and the extra hatcheries bring extra larvas for faster production. The result is that the unplanned resources can be spent efficiently and Steamhammer runs through its opening line faster, entering the middle game in a stronger position. In this game, it did not add anything extra in the opening; most of the +16 reactive drones must have been decided after the book line was over.

eco 0.35 5/43 describes plans for economic growth. 0.35 is the proportion of larvas planned to be made into drones on average over the long run. Actual moment-to-moment drone production can vary from all drones to all combat units, depending on circumstances, but Steamhammer aims for a given ratio. 5/43 is the actual ratio of drone production: It made 5 drones out of the last 43 larvas morphed, a ratio of about 0.11—Steamhammer is behind on planned drone production. Reactive drones are implemented behind the scenes by manipulating the ratio.

army 24 40 bad gives army sizes: Steamhammer’s army size is 24 (in an arbitrary measure), including static defense, and the enemy’s army size is 40, counting only mobile units. This is “bad” in red because it means that Steamhammer may be overrun. When the army size is “bad” Steamhammer makes combat units to defend itself; that explains why it is behind on drone production.

The 7 orange unit types lings, hydras, lurkers, mutas, guardians, devourers, ultras, are the candidate units for Steamhammer’s main unit mix. Overlords, queens, and defilers are support units that are made on the side and do not count toward the main unit mix. The number after each unit type is the strategy boss’s score for how important the unit type is in the current situation. The scores are used for two purposes: First, to decide on the combat unit mix. Second, to decide on the tech target, the next unit type that the bot should aim for.

The starred unit types are those that Steamhammer has the tech for. They are candidates for the unit mix. The starred unit with the highest score will be part of the unit mix. The rest of the unit types are candidates for the tech target.

Zergling Hydralisk 1 Lurker is the combat unit mix. Hydras had the highest score, so they are part of the unit mix. The full rules for choosing the unit mix are complex. Lurkers had the next highest score, but the strategy boss decided that it is enough to have only 1 lurker for now (which really means at least 1 lurker; if there happen to already be more, that is OK). Minerals not spent on hydras or the 1 lurker (or on drones or whatever else) will be spent on zerglings.

plan Mutas gives the tech target: A tech switch to mutalisks is planned. Mutas are a candidate for the tech target because they have a higher score than any of the starred units that Steamhammer already has the tech for. Guardians and ultras have higher scores yet, but Steamhammer doesn’t have a hive so mutalisks can be gotten much faster. If mutas did not score higher than hydras, the strategy boss would have picked guardians as the tech target.

This is too much. When I wrote about the 26 AIIDE 2019 registrants, I expected that not all of them would end up competing. It would have been surprising if a bot that looked as unfinished as Ophelia were ready in time. But this is too much.

See the list of participants. One extra holdover from last year was added, #11 LastOrder. Of the now 27 entrants, 13 dropped out, including the added LastOrder, so that 14 competitors remain. 4 are listed as withdrawn, 9 as not submitted.

The withdrawals are MetaBot, and the holdovers CSE, LastOrder, and SAIDA. MetaBot is supposedly unchanged, so in practice it is a holdover too. I suspect that LastOrder was added and marked withdrawn at the same time; the order of events suggests that it had already withdrawn before my write-up of the registrants. I especially miss LastOrder—last year, Steamhammer scored 25% against LastOrder, despite finishing higher in the rankings, and I would have enjoyed revenge.

Of the 9 unsubmitted bots, I will especially miss Dragon and Murph, which are both apparently protoss derivatives of CherryPi.

I’m sure circumstances are different in each case, but the large number of dropouts suggests a common underlying factor. What could it be?

I have uploaded Steamhammer 2.3.5 to SSCAIT. It is the same code as the AIIDE 2019 tournament version 2.3.4. The main difference is that it is configured to play all races. I did a little work on the openings, since that’s autonomic and proceeds without volition. Also I didn’t include pre-learned data files; they’re not helpful for SSCAIT and BASIL.

Source release soon.

change list

• Fixed the protoss ForgeExpand opening. At some point it was edited incorrectly and started to place the cannons in the main, where they were nicely protected since the enemy tore down the natural first.

• Added a protoss 10-12ForwardGateExpo opening. It puts gateways in the natural and tries to scare the enemy with some zealots before expanding. Whether the gateways successfully fit in the natural may vary by map....

• Added a zerg UltraRush opening. It’s not useful as written, unless maybe some opponent is extremely passive and at the same time highly skilled in stopping defilers. But I left it in.

The change list is longer than I originally predicted! This is the Steamhammer version that I submitted to the AIIDE 2019 tournament. The list includes changes from unreleased versions 2.3.1, 2.3.2, and 2.3.3 that played on SSCAIT for testing, as well as final changes in version 2.3.4 that never played on SSCAIT.

This version is configured to play zerg only, and all changes affect zerg play. A few of them should also improve play by terran and protoss. As usual, the most important changes are in bold.

opponent model

• Support pre-learned data files. If Steamhammer does not find a learning file for a given opponent in the read directory, it looks next in a “static” directory to see if there is a data file for the opponent there. The config variable Config::IO::StaticDirectory points to the static directory, and is set to bwapi-data/AI/om/ in the release version (“om” stands for “opponent model”). After the game, it proceeds as usual: It writes the pre-learned game records, followed by the game record for the current game, into the write directory; after write is copied to read, there is no reason to refer back to the static directory. Locutus does it essentially the same way.

The AIIDE version of Steamhammer includes pre-learned opponent model files for 12 of the registered bots. Most of these files don’t have much in them beyond a few sample strategies that have won in the past, so that Steamhammer doesn’t have to cast about blindly to find a likely build. Best play against Iron is more complicated—Steamhammer knows 3 very different successful openings with varying win rates depending on the map—so the pre-learned file for Iron includes 50 games to give Steamhammer an excellent winning rate right from the start. All the game records were originally extracted from Steamhammer’s learning files on BASIL.

operations

• Squad targeting: In deciding what enemy base to attack, count defenders in a smaller radius, unless the enemy is terran and has siege mode (then we need the wide radius to include any tanks that may be sieged). This helps Steamhammer more accurately choose the least-defended enemy base to attack next.

• There was a copy-paste error in the code to detect whether the enemy has siege mode. The siege mode information was returned correctly, but it mistakenly set the flag that means “the enemy has static air defense,” so Steamhammer would believe there were turrets whether there were or not.

• Squad targeting: Don’t order a squad to attack an addon. I changed ranged units to never attack addons, to avoid wasting time when they should be attacking something else. (Melee units will, though, because it may be the closest thing.) That unexpectedly caused difficulties in finishing off games versus terran, when units might collect around an enemy addon and never attack it, rather than attacking a known building that was perhaps farther away.

• Squad targeting: If no enemy buildings are known, seek enemy units which may still be findable. This can help Steamhammer finish off winning games faster.

• A terrific bug caused enemy unit counts to be horribly wrong in many cases. Steamhammer sometimes believed that the enemy had a negative number of units of some type. The broken unit counts were not used by many decisions—the most important decisions use the player snapshot unit counts, which are accurate—but decisions that did use them could be completely wrong.

• UnitInfo projects when enemy buildings will complete, based on their HP when last seen. It’s not entirely accurate; the calculation leaves out some factor that I haven’t figured out yet. To see the calculated times on the screen, turn on the config option Debug::DrawEnemyUnitInfo. In code, the call getEnemyBuildingTiming() is one way to get the information. This data could make plan recognition more accurate, but is not used for that yet; it is used only to check the enemy spire timing in ZvZ.

tactics

• Calculate map tiles in range of enemy static defense and keep the data available. There are separate grids of ground danger zones and air danger zones. A few uses of the data are implemented; many more are possible. Steamhammer will not place buildings in a ground danger zone; this is a vital skill to survive cannon rushes, and has saved games for Steamhammer against AIUR by Florian Richoux. The information also feeds into unit targeting decisions. Steamhammer’s units prefer to fight outside enemy static defense range when possible; Steamhammer has a stronger preference to pick off undefended targets.

• Squad detectors avoid danger and seek cloaked enemies. Formerly, detectors stayed with their squads and otherwise ignored the world around them. Steamhammer lost overlords freely, a major weakness. Now they retreat out of range of enemies that could shoot them down, and move toward cloaked enemies that need to be detected. Science vessels and observers benefit too. It’s usually a big improvement, but there are cases where enemy ranged units zone out the overlords, or enemy cloaked units distract them from where they need to be. Overlords that are not acting as squad detectors (some act as base detectors and some are left idle) are as carefree as ever and can still be lost at a high rate.

• A squad detector is supposed to move back home when it finds itself abandoned—when the squad it was detecting for is gone. I don’t think this feature works, or at least, detectors still make all sorts of illogical movements.

• Better combat sim results against cloaked enemies. If all enemies in the area are undetected and they can hit us, retreat without further calculation. If some enemies are detected, do the sim to see whether to fight or run. The change makes play vastly stronger in certain situations.

• FAP accounts for cost of scarabs and interceptors, and the full cost of zerg morphed stuff. It doesn’t make a big difference, but combat sim scores are a little more accurate.

• Ranged units are better at ignoring enemy zerg larvas when moving somewhere else. They’ll get distracted less often.

micro

• Issue at most 1 move command per 3 frames in the micro system. Zerglings get stuck less often. I still see it happen from time to time, but I think most watchers will see zergling movement as smooth. The underlying code can send move commands to the micro system every frame if it likes, but the micro system will skip or delay some of the commands if they are too closely spaced.

• MoveNear() had a potential crashing bug. It never happened as far as I saw, but a unit being given its first command ever could execute invalid code and crash.

• Use MoveNear() rather than Move() in more cases, to reduce unnecessary commanding. MoveNear() ignores commands that “don’t make a difference”—it says, “eh, we’ll end up close enough, don’t bother.” It’s for use when precision doesn’t matter, which is a lot of the time.

• Builder workers were being issued an unnecessary move command on the same frame that they were told to start construction. In the worst case, which was not frequent, building construction might be delayed by 1 frame. Still, it’s fixed.

• Steamhammer’s melee units can be configured to retreat when low on health, to regenerate health (by zerg regeneration or terran medic healing or protoss shield regeneration). The change is, this no longer happens if the unit is irradiated. Net regeneration will not happen, and since it’s a melee unit it’s likely to be right next to the enemy, exposing enemies to the radiation. This mainly helps ultralisks.

• Clip the result of DistanceAndDirection() to the map boundaries, instead of returning a bad result for the caller to deal with. In practice, the effect is that in some situations a unit will move to the edge of the map rather than not moving at all. I’m not sure it’s an improvement in play terms, but the code is safer.

zerg defilers

• An outrageous bug could put a defiler into both the defiler controller and the melee unit controller, meaning that defilers were issued zergling commands intermixed with their defiler commands. “Now AttackUnit() that building!” I was floored. The error was in code that was “so simple it could not have a bug,” and the bug was caught by an error check in the micro system, far away from the underlying problem. At least it was easy to fix.

• Cast dark swarm over enemy ranged units, not only over enemy buildings. Formerly, Steamhammer could not use swarm against, say, marines on the open field; it had to reach the enemy base before the conditions for the spell were triggered. It was a severe limitation (justified by Steamhammer’s poor swarm skills at the time).

• Choose the nearest zerglings as defiler food, not the first zerglings that happen to come up in looping through units. Defilers consume sooner and cast swarm and plague at a higher rate. A defiler generally arrives at the front line already charged up with energy, so even if it is irradiated instantly it is still likely to get a swarm or plague off.

• A typo prevented research of Metasynaptic Node, the defiler energy upgrade. I fixed it and adjusted the conditions to be safer.

• Slightly loosen the conditions for making a defiler in the first place. They work better now, make ‘em sooner.

• Swarm and plague scoring adjusted for better effect. The thresholds are reduced, so that the spells can be cast in more situations. Swarm over lurkers counts double. Plague counts more on carrier interceptors, less on buildings. Various other tweaks.

• Fixed a bug in avoiding the overlap of dark swarms. Swarms less often overlap wastefully (though it still happens, for at least 3 reasons).

• FAP bugs in understanding dark swarm are fixed (I added dark swarm to FAP, so all the bugs are my doing). There was an error in recognizing melee units that can hit under dark swarm because of a confusion between range and squared range (I renamed stuff and added comments to make it clearer). FAP also now realizes that a worker cannot do damage under dark swarm, while a reaver can. The effect of the fixes is that units under dark swarm make more accurate decisions about whether to keep attacking.

• A rare bug could allow multiple defiler mounds.

zerg scourge

• Do not target an enemy that is covered by enemy static air defense. Steamhammer used to throw scourge away by the ton to cannons or turrets; this solves the issue. Scourge will chase the enemy, but turn around for home if the enemy reaches a defended area. (Mobile enemies might still shoot down the scourge; retreating in that case is decided by combat sim and the regular advance/retreat logic.)

• Do not target overlords or interceptors. Shooting down those targets is usually a waste of gas. Neither the scourge squad nor the scourge units will seek overlords or interceptors. This solves another serious issue.

• Predict the target’s movement. This helps scourge hit the target directly, instead of doing that weird little loop before suiciding. It also means that scourge cut corners in a turn, but only a hair.

• There was a bug in choosing scourge squad targets that were goneFromLastPosition, that is, known to no longer be where they were last seen. It caused wasteful scourge movement.

• In choosing a scourge unit target, pay less attention to target priority (“the science vessel is more important to destroy than the wraith”) and more attention to target distance (“it’s right here, just hit it!”). That wraith is now less likely to shoot the scourge down while the scourge chases a more distant science vessel.

• If we have lurkers, then enemy observers are higher priority to destroy.

• Further limit scourge production. I tuned it down repeatedly, but Steamhammer was still sometimes spending too much gas on scourge, leaving too little for everything else.

other zerg skills

• Sometimes make 1 queen, use parasite, infest command centers. The queen likes to parasite expensive units like carriers and arbiters, and it also likes shuttles and dropships. It will parasite something else if it has excess energy or gets irradiated. As I expected, few enemies understand what to do when they get parasited. A common outcome is that the parasited unit gets scourged at the first opportunity. If the parasited unit stays in a safe place instead, it’s often a valuable spy. The infested command centers don’t do anything but sit there and get in the way; I haven’t yet seen this cause Steamhammer any problems in game, but it could happen. If the queen dies, which happens a lot because it plays recklessly, the strategy boss waits 3 game minutes and makes another queen.

• There was a critical crashing bug affecting spellcasters in the late game. Fixed, whew.

• In an emergency, set the drone production rate to 0.15 rather than the previous 0.10—that is, make a drone instead of a combat unit 15% of the time. This helps Steamhammer build up its economy even while under heavy pressure, without falling to the pressure. It increases the win rate against zealot rushers and other opponents that press attacks over a long period, like Gaoyuan Chen.

• Prefer to make units at hatcheries with more larvas. Steamhammer used to often lose production capacity by using up all the larvas at one hatchery before moving to the next hatchery. A hatchery with 3 larvas will not produce more larvas, so that meant the total rate of larva production was lower, and more total hatcheries were needed to cover the next surge of zergling or drone production (cheap units that call for a lot of larvas).

• Prefer to make drones at undersaturated bases. It is a smaller improvement than it may sound. Formerly, Steamhammer used a cheap but effective trick: It preferred to make drones at the base farthest from the main base. It was the right choice most of the time, but could go wrong if the main was attacked and lost drones. The new method balances workers well in all cases, not only the common case.

• Steamhammer tries to make fewer macro hatcheries before expanding beyond its first and second bases. I saw games where it made as many as 4 hatcheries in its main before taking the natural—it might be OK if the bot is contained, but not the other 6 days of the week.

• Delay the second gas a little. Steamhammer consistently took the second geyser too soon. I think it’s still usually too soon, but the loss is reduced.

• Dark templar more strongly indicate the need for static defense. They hit hard.

• Make a defensive spire in reaction to enemy drop or certain air units. Formerly, only overlord hunters like corsairs would trigger a defensive spire.

• In ZvZ, prefer to counter hydras and especially lurkers with mutas, not lings only. Steamhammer usually did the right thing, but in a few games made a severe strategy mistake.

• In ZvZ, Steamhammer formerly made an evolution chamber if it saw an enemy spire, no matter the state of its own spire. That’s a mistake; the evo is often unneeded, and in ZvZ the drone to make the building is valuable. Now Steamhammer attempts to time the enemy spire and make the evo only if needed. I don’t find it particularly accurate, but it is an improvement.

• In ZvZ, enemy scourge more strongly discourages Steamhammer from making guardians and devourers. See the game I posted last time, where Steamhammer scourged Microwave’s devourers. Devourers and guardians have little ability to defend themselves against scourge; they can only survive with the help of escorts.

• Limit devourers further. Devourers are support units, so try to keep more mutalisks than devourers.

• A lost defiler mound could cause a production freeze. It was rare, but a production freeze can be a game-losing bug. It’s frustrating, but there remain rare production freezes that I have not traced.

• Emergency reactions: When there are 0 drones, Steamhammer can cancel upgrades and more building types. Formerly it could cancel only units and a few building types.

• Emergency reactions: Correctly account for the gain of canceling a building (you get 3/4 of the cost back). It helps in making the right cancelation decisions.

• Emergency reactions: A bug could allow a planned hatchery to be dropped even though it was the only hatchery.

• ZvZ mutalisk target selection adjusted in a few cases.

• Lurkers prefer the most distant target. It helps visibly.

• Fixed lurker vibration: Sometimes lurkers would move back and forth, achieving nothing, instead of advancing on the enemy.

• Attackers can no longer permanently drive overlords away from the spore colonies where they are sheltering. This was a bug introduced in a recent version.

zerg openings

• 3HatchLingBust2 makes the minimum number of drones and goes all-in on the bust. This version is now configured in place of the original 3HatchLingBust as one counter to protoss forge-expand builds.

• 12Hatch_4HatchLing makes the right number of drones for continuous zergling production from 4 hatcheries. It’s similar to 3HatchLingBust2.

• 2HatchMutaPure and 3HatchMutaPure each make only 1 pair of zerglings, and instead get as many drones as possible without delaying the mutalisks. The 2 hatchery one is especially elegant. These are for use against opponents that sit back and defend for a time before moving out.

• Overpool2HatchLurker and 3GasMuta similarly are more effective against opponents that are late to attack.

• DefilerRush rushes for defilers to support highly-upgraded zerglings. I used it mostly in testing defilers, but there are opponents it could be strong against. The defiler rush is similar to the existing HiveRush build, but better optimized (and of course it also makes a defiler).

• 12PoolHydra is configured as one counter to terran factory-first openings. 12PoolLurker fills a gap in the lineup of lurker openings. ZvZ_12PoolLingB is a minor variant of ZvZ_12PoolLing. ZvZ_12Gas11Pool is a gas-first stem that fills a gap.

• Overpool_3HatchSpeed, Overpool_3HatchLing, and Overpool_4HatchLing try to combine the early zerglings of overpool, which can keep the opponent in the dark and defensive, with a mass zergling followup. Overpool_4HatchLing is configured to be played 1% of the time in ZvZ versus an unknown opponent—it’s risky but can also be hard for the opponent to understand and counter (it makes a third base that the opponent is not likely to scout in time).

• 10Pool9Gas and 10Pool9Hatch fill small gaps in the ZvZ opening repertoire.

• 7Pool6GasMuta is derived from one of my 7 pool 6 gas dawn lurker rush builds. It’s quite easy to defeat, even without air defense, with an early attack. I suspect it is useful mainly against opponents which want to defend and fail to figure out how to defend so early.

• Minor tweak to 2HatchHydra. Bigger adjustments to OverpoolTurtle so that it can more consistently beat those (weak) opponents it is intended to beat.

Next: Expect Steamhammer 2.3.5, which again plays all races, on Tuesday or Wednesday.

I have submitted Steamhammer 2.3.4 for AIIDE 2019, a day ahead of the deadline. The latest changes help in specific situations: Better decisions against dark templar, less time wasted when the defiler wants to consume, more accurate strategy choices in ZvZ when the opponent goes hydras, that kind of thing.

Overall, I’m pleased with this version. It is far more solid than any previous tournament version of Steamhammer. There are a couple of game-losing bugs that I did not solve, but they are rare. There are rough edges, but fewer than before. In last year’s AIIDE, Steamhammer was version 2.0, with many new features including unit clustering and defilers—and they were buggy. This year it is version 2.3.4, and the version number is deserved: The strength improvements over 2.0 are due to bug fixes and refinements, not new features.

This means, of course, that it is time to get back to work on version 3.0, with new strategy adaptation features. Add bugs for victory!

Before long I’ll either upload version 2.3.4 on SSCAIT as zerg only, or I’ll come out with version 2.3.5 that can play as any race.

By the way, I counted the number of zerg openings. There are now 142.

Steamhammer-Microwave rivalry

Microwave was forked from an early version of Steamhammer, and the two have been struggling against each other ever since.

• AIIDE 2017 - Microwave 70.86%, Steamhammer 64.14%
• SSCAIT 2017 - Steamhammer 83.12%, Microwave 79.87%
• AIIDE 2018 - Steamhammer 54.97%, Microwave 54.16%
• SSCAIT 2018 - Microwave 74.65%, Steamhammer 72.54%

The two bots have different strengths, but most results have been close. Which will edge out the other this time? On BASIL, Steamhammer and Microwave have been trading the top zerg position back and forth. Microwave has an advantage in head-to-head fights, but I think Steamhammer has a slight edge overall. We’ll see how the tournament goes!

Randomhammer (Z)-Microwave is a ZvZ with devourers and defilers. Microwave wins the majority of games, but Steamhammer has better hive tech skills.

A comment to Undermind Episode 31, which mentions non-programmers entering build orders into Steamhammer. I tried to comment directly at Making Computer Do Things, but WordPress thought I was a bot... which was kind of ironic. So I expanded and posted here instead.

There is documentation for the Steamhammer configuration file. It is not up to date, but it is complete except for newer features. It should be plenty for a non-programmer to enter build orders. Telling Steamhammer to play the build order will look difficult if you only read the config file, because the default config is complex, but if you read the documentation you’ll see it’s trivial. Other tricky parts: Steamhammer doesn’t always play build orders literally; queue reordering will be really confusing for beginners. The unforgiving JSON syntax plus uninformative error message might cause trouble (one misplaced comma and it’s “ha ha, it didn’t work, and I won’t tell you why!”).

Thanks, good discussion! I have new ideas about how to make it easier for people to get started. At some point I’ll try to do them.

• Add a simple sample configuration file for people who don’t feel like being overwhelmed by the performance config.

• Add documentation for non-programmers, that concentrates on the most useful features for them.

• Smooth out some of Steamhammer’s in-game behaviors so they are more intuitive. Somehow. They are there because they help sometimes, but they add complexity and can trip me up too.

I wasn’t planning to work more on defiler play for the time being, but then I discovered two more sets of bugs affecting defiler play. Since defilers are bugs, does it follow that you can’t have defilers without bugs? First, my additions to FAP to understand dark swarm had multiple errors in determining which units can hit under swarm. That could cause Steamhammer to cast swarm over its units, then needlessly retreat from under it. Second, there was an unbelievable bug which assigned defilers not only to the defiler controller, but to the melee unit controller at the same time. In between their regular orders, defilers were being interrupted with nonsense orders to act like zerglings. How did defilers ever work? Because in the buggy live version, defiler play is, somehow, already valuable.

Rule of thumb for the upcoming tournament version: If Steamhammer survives to the late game and has defilers out, it is probably winning.