Starcraft AI blog

As some people have noticed, Steamhammer’s “secret weapon” ZvZ opening, which when I first tested it scored overwhelmingly against all opponents including Steamhammer itself, is simply overhatch.

Overhatch means making up to 9 drones, spawning an overlord, and then starting a hatchery while still on 9 supply. Steamhammer’s version is overhatch 9 pool 9 gas (with drones in between buildings), parallel to its faster 9 hatch 9 pool 9 gas build. The overlord lets zerg get in a couple extra drones, so that when the spawning pool finishes the bot has 10 drones and can immediately spawn 8 zerglings. The timing is fast enough to hold off 5 pool except on 2-player maps. It puts the player in a reasonable economic position (by ZvZ standards), but also commits to zergling-heavy play because the lair will be later.

Overhatch is a rare opening and it is not written up on Liquipedia, and that is for a good reason: It is dominated by 10 hatch. In a ZvZ 10 hatch opening, you go up to 9 drones, spawn an overlord, and do the extractor trick to get a 10th drone. The 10th drone can mine for a while before minerals are available to morph the hatchery, so 10 hatch is always ahead of overhatch in minerals. There is no disadvantage to 10 hatch; it can only be better than overhatch (though only by a little). Steamhammer plays overhatch because it still does not work around the extractor bug (I have more important bugs to fix first).

results

The opening is strong against bots. Results on the SSCAIT server have been good, though less convincing than my original tests.

Steamhammer has lost several games by failing to build an extractor when it came up in the build order. It is a bug that I didn’t see in testing and haven’t solved. For some reason it hits overhatch much more often than other builds.

Steamhammer has also lost a game to Microwave’s 9 pool and another to Dawid Loranc’s 5 pool. Steamhammer’s zerglings were in time to defend with correct play, but Steamhammer pulled its drones too soon and lost some. It’s a severe defensive error. At some point I will teach Steamhammer how to defend with a drill, and then these losses won’t happen.

Steamhammer has also lost occasional games to strong opponents like Killerbot by Marian Devecka due to tactical errors. It does win most, though, even against opponents like Arrakhammer that know about the overhatch opening and are prepared to meet it.

counters

Like every opening, overhatch can be countered provided you know it is coming: You can safely open 12 hatch to end up equal in hatcheries, ahead in economy, and behind in nothing important. So Steamhammer doesn’t play overhatch every game. Steamhammer is set to play overhatch in half of games. Its other openings counter 12 hatch, which is a slow and risky opening in ZvZ. The random openings ensure that no opponent build can give a sure win; opponents have to either play better or get lucky.

If you want to counter overhatch safely, Liquipedia suggests that 12 pool gives a slight advantage. 12 pool is a safe ZvZ opening if played well. But I learned by experience that it is tough to teach a bot to play it well.

other matchups

The classic use of 10 hatch is in ZvP, where in old days it was considered a strong counter to 2 gate zealot play. 2 gate play is popular with protoss bots, so I tried overhatch against protoss too. It seems effective. I think it is doing better than overpool, which was already successful.

In ZvT, Steamhammer up through the current version has always played either zergling openings with heavy early pressure, or mutalisk openings with minimal zerglings and a heavy air attack. Thinking it through again after working on surviving early terran attacks, I decided to add a compromise opening for the next version. I picked an overhatch opening with early zergling pressure followed by a later, lighter air attack, at the cost of a weaker economy in the long run. I think it is objectively worse, but other zerg bots have been successful with similar approaches and it may work well against bots. It’s an idea that should be tried.

Tomorrow: Arrakhammer’s attempt to counter overhatch

Progress has been delayed by exhausting events in some kind of “real world” that I don’t fully understand. But whatever, it’s only a temporary distraction. A public repository should be up soon-ish; I have made some decisions but not all.

After that I will be, as anyone could have guessed, splitting versions again. I was planning for the next version 1.2.4 to be a mass bug fix release, but with the new SparCraft out, that doesn’t seem like the best plan.

• 1.2.4 - I’ll try the new SparCraft and incorporate it if it seems like an improvement. I expect it to be. Besides that, I plan to work on about a half dozen of the most critical bugs and weaknesses.

• 1.2.5 - Fix as many of the remaining bugs as possible. My list is way longer than I can get through.

• 1.3 - Start on opponent modeling.

I promised some form of opening learning or other opponent modeling for CIG 2016, and it is coming up fast. I have to get onto that soon and delay mutalisk work yet again. I regret the delay, because mutalisk micro is a key zerg skill and all bots are clumsy at it. When I finally get it implemented, terran bot authors in particular will be dismayed to see how hard mutalisks can hit when they are Less Stupid. But opponent modeling is also key.

I have already implemented a couple of fixes to regrouping. I corrected a conceptual error in weapon ranges versus ground distances. It remedies one case of mutalisks holding their position while under enemy fire, as well as less visible but related misbehavior. Also medics retreat with their squad when they should, instead of staying behind to “hold off the enemy while you escape.”

If I ever want to finish ahead of tscmoo in a tournament, zerg will have to learn how to survive terran early pressure. To make testing easier, I added a terran BBS opening. Like Tyr’s, it defeats Steamhammer’s mutalisk openings 100% of the time. So far, my attempts to react to it are too slow and zerg still loses. The BBS is so effective that I could not resist adding a “go pull workers” command to pull SCVs into the combat squad and make it even more vicious. Now it is easy to write all-in strategies like Oleg Ostroumov’s marine-SCV attack, or the zealot-probe all-in that Pinfel used to play.

Here’s a curious point about Steamhammer’s ZvT and Tyr by Simon Prins. Tyr has opening learning, and center map BBS is its answer to bots which don’t defend themselves early. The BBS has always beaten Steamhammer’s mutalisk builds and lost to its zergling builds.

In the past, Tyr has tried BBS against Steamhammer and given it up after a while after losing; it concluded that a regular opening was better. Past Steamhammer versions played zergling openings 25% of the time, which was apparently enough to deter BBS even though Tyr’s slower play didn’t consistently win 75% of the time (it varied by version).

This Steamhammer version plays zergling openings ZvT 20% of the time, because the mutalisk openings are improved more (that was my thinking, at least). Tyr apparently detected the shift in game results, and now it plays BBS every game and wins 4 out of 5, a huge upswing. Can improved play can lead to worse results when it highlights remaining weaknesses for the opponent’s learning to exploit? It could also be because Tyr was updated recently. Or it could be a chance change due to the interaction of opening learning, random choice of builds by Steamhammer, and historical changes in Steamhammer’s performance.

To fix the weakness I thought of a simple adaptation, and I hope to try it out in an upcoming version. Steamhammer is prepared for early pressure versus zerg or protoss opponents, but against terran it tries to exploit the tendency of most terran bots to sit back and macro for a while. So it only has to adapt in the case of early marine pressure, as played by Tyr (with BBS) and the latest tscmoo (with an academy rush) and a number of weaker marine bots like Kruecke and KaonBot. Steamhammer should have better chances to survive if it breaks out of its prepared build when it recognizes the early pressure, and lets the strategy boss do its default thing. I doubt my simple idea is good enough by itself for all cases, but I’ll try it.

I heard back from the CIG 2017 organizers. They wrote that the contest will support BWAPI 4.2.0 “if there’s no special issue,” and that details will be announced later.

So: They haven’t decided for sure. I expect that there will be no issues and they’ll adopt it, but the decision is not set in stone.

In my experience, most academics are extremely busy, which is not ideal since good scholarship calls for time and concentration. I think the CIG organizers are no different.

The new Steamhammer 1.2.3 zerg plays slightly but distinctly better than the previous version. It’s worse on some points, like focussing the attention of its mutalisks, but better on enough others to make up for it. The overall result is a small but clear bump up.

The new Randomhammer plays worse than the test version of Randomhammer, and I don’t know why. Apparently I did something harmful in the last week of development, and I can’t figure out what. I worked through the list of items I changed that week, and I don’t see a problem with any of them. But there must be one. Has anybody noticed something?

It’s possible that the unknown problem affects zerg too, and zerg could be even stronger if I fixed it.

Some people would spend no more than 10 minutes to bring up a public repository, but I’m taking my time. I am a long-time darcs user for my personal projects and don’t know git. A public repo today should be a git repo, today’s standard, not a version system with beautiful theory and ugly popularity. I want to get up to speed.

On the side, I’m thinking about the large number of skills that bots want to know and I’m trying to figure out how to fit them into the smallest amount of code. I noticed that a lot of spells share similar structures and should share code.

All the spells I list below can share backbone code which is at least partially data driven. I’m imagining something like this for each spellcasting unit:

1. Does it have the energy and tech to cast?
2. Is some suitable target nearby?
3. Find the best target, taking into account the whole situation including any maneuvering needed to get into position first.
4. If the best target is not good enough, no spellcasting action. Carry on as usual.
5. If we’re too far away, move toward the position.
6. We’re in position. Cast.

Each spell would need its own evaluator code “how good is this potential target?” It looks to me as though everything else that differs between them can be kept in a table of data and the rest of the code can be shared. Unless I get a better idea, I expect I’ll implement this eventually and suddenly support a large number of spells.

All of the spells below, but I’m thinking especially of hallucinate and dark swarm, benefit strongly from tactical coordination. That can be made to fit the framework. The tactics boss could decree things like “broodling if it’s an emergency, otherwise hold on until we can make a coordinated attack” simply by adjusting the “it’s good enough” threshold value. But even uncoordinated spells, which is all that most bots ever implement, would be fun and would pose problems to the opponent.

Consume and recall may fit a little awkwardly into the framework. They both depend on prepared units standing ready. But even they seem doable.

target is a unit

• optical flare
• restoration
• defensive matrix
• irradiate
• lockdown
• yamato cannon
• hallucinate
• feedback
• mind control
• parasite
• broodling
• consume

target is an area

• EMP
• nuke
• psionic storm
• maelstrom
• disruption web
• stasis
• recall
• ensnare
• dark swarm
• plague

BWAPI 4.2.0 was released on 28 April. I have been thinking about when I want to switch over to it, and I haven’t decided.

Sooner? 4.2.0 fixes the zerg hive research bug, which pinches zerg strategy. The hive bug is nasty, so that counts for a lot. Code changes to switch to 4.2.0 seem minimal; I would want to revise the bits of the zerg strategy boss which encode the buggy tech tree. Dave Churchill has already switched UAlbertaBot over, so any problems should be minor. 4.2.0 supports Visual Studio 2017, so people wouldn’t suffer from old development tools. And of course there are various other improvements and fixes, and it’s common sense to stay as up to date as possible.

Later? Will competitions support 4.2.0? I wrote to the CIG 2017 competition organizers to see whether it would be supported in their tournament. The lead time may be short for them. We’ll see what they say. Also, given my development plans (fix bugs, work on mutalisks and opponent modeling), switching libraries would be overhead that slows me down for the moment. I’m not looking forward to switching to a new toolset when I’m still getting used to the one I’m using.

What do you think? Anybody have thoughts or experience?

Update: As Ailien points out in a comment, if you use BWTA you have to update it at the same time, and no new BWTA release is out yet. All DLLs have to be compiled with the same toolchain, per Microsoft. It may work if you compile BWTA yourself from source with vs2017 (no promises, I haven’t tried it). For BWEM, Igor Dimitrijevic suggests integrating it into your source code directly. If you did that, then it presumably does not have the same issue (I didn’t see any map-related changes in the BWAPI change list).

The new Steamhammer version plays worse against Iron. I expected it to—in fact, I intended it to play worse.

Iron sends vultures to roam the map. By the time mutalisks come out, the terran base is filling up with turrets and expensive to attack. The older Steamhammer, when it survived Iron’s vulture runby due to lucky timing or Iron’s mistakes, usually chased vultures and SCVs with its mutalisks as their numbers built up, which (given the bot’s limitations) was good play for the situation. Occasionally it won, when it protected drones long enough for mutalisks to build up to critical mass to take down the turrets, or for ultralisks to come out in number.

It played right, but for the wrong reasons: The mutalisks were under orders to attack the enemy base, and they didn’t. They were distracted by the enemy army. Any good play was accidental.

I want Steamhammer to play right for the right reasons. My first step was to make it play wrong for the right reasons. One of my goals for the tactical changes to unit targeting was to make squads obey their orders more faithfully. And... it’s somewhat successful. Squads still sometimes go on goose chases, and individual units often get distracted without good reason, but overall a squad with an attack order has a tendency to move toward its goal and attack it. With Iron it is particularly clear: Mutalisks take some passing shots at vultures but mostly move toward their goal. When they arrive, they underestimate the danger of the many turrets and die, so the game is lost; that is a different problem.

A future version will do more tactical analysis and pass along better orders to the squads. Then Steamhammer will start to play right for the right reasons.

I got 2 nearly simultaneous comments pointing out Randomhammer’s loss on time against LetaBot by Martin Rooijackers. Thanks! Randomhammer was winning, so it hurt. The problem is the “my main is full, I can’t find a place to put this building” bug, which I reduced but did not solve. A typical solution seems to be to choose a new “main base” from time to time. I would like to go further and put a pylon at each base, if for no other reason than to add cannons if needed.

Maybe it’s a good time to talk about my bugs. I have 39 bugs—so far—that I want to fix in the next version, not counting bugs I’m intentionally skipping for now. It’s far more than I can actually fix. If I fixed all the bugs, I wouldn’t have time to add more bugs! One of the worst bugs was introduced in version 1.1 in February and is still there.

The good news is that there are no known crashing bugs. Steamhammer has 1 crash dump on SSCAIT since 3 April, and it points to initialization code before Steamhammer runs. UAlbertaBot was already mostly good in that respect, and the majority of crashing bugs I fixed (though not all) were in my own code.

The bad news is that most games, both wins and losses, show the effect of bugs. Many events that may look to observers like ordinary poor play are secretly due to incorrect information tracking, or behaviors occurring at times they weren’t intended to, or something else going wrong behind the scenes. In other words, if I can fix the worst of them, then Steamhammer will play much more strongly just by working as intended.

This game McRave-Steamhammer is a bug-fest on both sides. Watch this replay only if you can bear to see an epic number of things go wrong for both players. At the end of the game, Steamhammer is mining minerals with 1 drone and gas with 3, while its other 18 drones are trapped behind a map block, and that is only one of many painful blunders. McRave did no better. The game went on far too long as both bots tripped over their own feet.

Here is one of the most frustrating bugs: In my tests at home, Steamhammer defeated Killerbot by Marian Devecka nearly 100% of the time. Since being uploaded, Steamhammer has played 3 games against Killerbot and lost 2 of them due to a new bug that I had never seen before. I can’t find the bug in games against any other opponent. Objectively, a bug that affects only one opponent is not the top priority to solve....

Steamhammer's web page is updated with source.

I enjoyed this game of Randomhammer versus Krasi0. It was played by the test version of Randomhammer, before the release version was ready.

Randomhammer ended up protoss and tried its dark templar drop strategy. Here the shuttle has taken the long way around the map, following the edge counterclockwise, and unloaded dark templar next to the mineral line. The dark templar killed a number of SCVs plus a goliath and delayed the academy, while disrupting mining.

Two tanks at the front had been keeping the protoss field army at bay. The tanks pulled back to help defend the drop (in this picture they are on the high ground), which allowed Randomhammer to break the bunker and wreak more havoc in the natural.

At the end of the fight, Randomhammer had its own natural up and was ahead in workers by 33 to 16, which should have been a decisive advantage. Then, of course, Krasi0 played the rest of the game much better and won regardless.

The dark templar drop is dangerous. Krasi0 was prepared: It had turrets up for detection and goliaths to shoot down the shuttle. Terran could detect the dark templar most of the places they went, and yet struggled to defend. Randomhammer did not understand that the turrets were key targets and ignored them. With sharper play during the drop, protoss might have won outright despite Krasi0’s preparation and fast defensive reactions.

It was a fun and instructive game. As protoss, Randomhammer plays the dark templar drop around 15% of the time, depending on the map and matchup.

The change list is big this time. I took over a month to do it, but I did a lot. This is primarily a feature release to add skills for terran and protoss, and to improve tactics and micro for all races.

History says that my feature releases are sometimes weaker than the previous version due to bugs. I already see new bugs that never came up in testing, bugs I did not see even in the Randomhammer test version. Sigh. Yesterday’s bug list was longer than I could hope to finish before July, and today’s....

drop

Terran and protoss have limited support for drop strategies. Dave Churchill implemented part of it in UAlbertaBot, and I filled in the many gaps and made it work.

Terran and protoss can drop once, with a predetermined unit mix, from 1 dropship or shuttle, near the mineral line in the enemy main base. The transport cannot pick its units up again. The transport cannot return to pick up a new load (it idles in the enemy base after unloading). If you make a second transport, there’s no support for loading it up and making a second drop. The transport follows a fixed sneaky path around the edge of the map. (It would be easy to change the drop target, though.) Even with these severe limitations, drop strategies can be worth playing.

Zerg drop is not supported because it’s a little more complicated. Zerg has to research drop and then choose an overlord, and usually research overlord speed too. Also dropping once with 1 overlord is not as useful for zerg. I’ll probably implement multiple-ship drops and repeated drops around the same time as zerg drop. I have made a start, and it will get better.

As written, the setup for the drop—arranging the production of the tech and units—is fully in the hands of the opening book. The opening book sets the OpeningGroup to "drop" to declare a drop build. The StrategyManager can then do as it will with the drop opening group; I had it transfer to another opening group. It should be no problem to move drop setup into StrategyManager so that drop can happen or not depending on game events.

The drop is coordinated by CombatCommander using newly added squad order types. See CombatCommander::updateDropSquads(). To change the units to drop, modify CombatCommander::unitIsGoodToDrop(). The transport movement is carried out by MicroTransports, most of which was written by Dave Churchill with additions, tweaks, and bug fixes by me.

Terran plays a vulture drop strategy around 10% of the time (depending on the matchup and map). Protoss plays a dark templar drop strategy around 15% of the time (ditto). The dark templar drop especially can be deadly.

tactical changes

• Every race (not only zerg) gets separate ground and flying squads. See CombatCommander::updateAttackSquads().

• Every race is supposed to get a mobile detector for each squad, as zerg does, provided the detector has been made. I noticed that it doesn’t work for terran science vessels, which sit by the starport. Another bug for the list. I’ve seen it work for observers, so I hope there is not a regression.

• Don’t assign an air target to a squad that can’t shoot at air units, or a ground target to a squad that can’t shoot those. See CombatCommander::getMainAttackLocation(). One hydralisk among the ultra-ling will get the squad assigned to shoot down carriers, so bad behavior is possible, but it is... self-limiting.

• Overlords are an acceptable tactical target in CombatCommander::getMainAttackLocation(). It’s made possible by the above fix. In UAlbertaBot, overlords are explicitly skipped over so that zealots and zerglings aren’t sent to chase them.

micro changes

• Targeting is more flexible, relying on a combined score rather than separate priority and range (which was brittle). The change needs more tuning to approach its potential. The change allows others:

• To reduce goose chases, fast enemies score lower when they are moving.

• Workers are always acceptable micro targets in MicroManager::execute(). UAlbertaBot and former Steamhammer versions often ignore workers in the middle of the map to reduce goose chases. The code was complicated and introduced a harmful limitation.

• Targeting priorities are adjusted, especially priorities related to workers.

• When regrouping, do not retreat from an enemy unit that cannot attack you. Retreating units used to stand back 128 pixels even from enemies that could not harm them, so you would sometimes see mutalisks fleeing from firebats.

• When retreating from an enemy that can harm you, retreat beyond enemy sight range as well as beyond enemy firing range. This often results in retreating farther. I added bonus distance for retreating from tanks, though I see in games that it is still not far enough. Units try to retreat out of range but don’t understand how to navigate around each other.

• Detectors, such as overlords, are a little more cautious and should wander into enemy fire slightly less willingly. They still die a lot.

• UnitUtil::CanAttack() had a bug inherited from UAlbertaBot. Instead of only fixing the bug, I rewrote the function to understand more unit types, which made it possible to simplify other code. It now understands that bunkers, reavers, and carriers should be treated as able to attack.

• UnitUtil::GetAttackRange() tried to understand bunker range, but had a bug, and it didn’t know about reavers or carriers. I think it now understands bunker, reaver, and carrier range correctly.

• The bot surrenders when all hope is lost. It says “gg” and goes idle for 1.5 seconds before leaving the game. See GameCommander::update() and GameCommander::surrenderMonkey(). The behavior can be turned on or off by a new config option Config::Strategy::SurrenderWhenHopeIsLost.

terran

• Terran tracks the locations and times of comsat scans to avoid scanning redundantly. I implemented a very simple system using MapGrid. It’s not fully accurate but it’s a huge improvement over the previous version, which would blow 100% of scanner energy of all scanners the moment it spotted a dark templar. Now it scans only moderately more often than it should (it scans cloaked units it notices whether it can fight them or not).

• Marines and firebats use stim, an important skill.

• Medics mostly stay near marines and don’t run ahead. This is a bigger improvement than stim. Medics still have a problem with regrouping. Even so, infantry play is much improved.

• Tanks stay sieged while an enemy is in range. They still siege and unsiege way too often, but now they behave better when fighting in sight of enemy buildings.

• StrategyManager::getTerranBuildOrderGoal() is updated to research stim, to make more transitions, and stuff like that.

• The 2 factory openings are more efficient: The vulture opening and the tank opening. My inexperience with terran openings was showing.

protoss

• Protoss supports more units: Reavers, carriers, and archons (which all require special handling). Reavers crawl around and try to join the army; they work reasonably well. Carriers stay home until they have 4 interceptors (well, occasionally they wander off). Carriers (like scourge) should be put into the flying squad only if there are other flying units; otherwise they stay with the ground squad. Since there is no support for psionic storm, high templar as they are produced automatically merge into archons. I didn’t implement a way to ask for an archon, you get one when you make 2 high templar.

• StrategyManager::getProtossBuildOrderGoal() is updated to use the new units. Zealot openings add archons and carriers later in the game. Dragoon openings add reavers after the second nexus. Plus various other less important changes.

• The 10-12 gate opening is improved.

zerg

Zerg has the most changes by count, but they are simpler. Except for the openings, all the changes are in StrategyBossZerg.

• No longer get scourge before they are known to be needed. It turned out to hurt more often than it helped.

• Make a second evo chamber only if the first is busy. The bot too often started a second evo before it had scared up funds to upgrade carapace in the first, or made 2 evos when rebuilding even when no more upgrades were needed.

• Fixed an oversight allowing a rare production freeze related to overlord speed.

• Make a spire for air defense, even if it is not otherwise needed.

• Make emergency zerglings when under dangerous ground threat.

• Ground emergencies end after 20 seconds, not 30. I’m considering whether 15 or 10 seconds might be better.

• Choice of air or ground units is improved versus all races. For example, if the enemy has too many spores, the bot will stop mutalisk production. A bug causes a useless hydra den to be made against terran; I fixed that once, it is a regression.

• Go ultra-hydra much less often. The bot was way overusing that unit mix.

• When the enemy makes static defenses, respond with drones. The change is simple but effective, as seen in the recent game against XIMP by Tomas Vajda where Steamhammer took the map much faster than before. You can see Steamhammer make a burst of drones when it finds more cannons, until it reaches the maximum 75 drones.

• New overhatch openings, other opening tweaks. Some openings are shortened because the strategy boss can now do the right thing.

configuration file

• Strategy mixes can get different weights depending on the map size, and repeated strategy mixes can be factored out into strategy combos. It's explained in this post and implemented in ParseUtils. (Tech note: I used BWTA to count the start locations, so I had to move map analysis ahead of config file parsing in UAlbertaBotModule. I didn’t realize in time that BWAPI can count the start locations. All you should have to do is change BWTA:: to BWAPI::Broodwar-> in the call to getStartLocations().size() to remove that point of dependency.) All races use the map size feature to prefer some strategies on appropriate maps.

• I added a boolean strategy option SurrenderWhenHopeIsLost to control surrendering.

• I added a macro option AbsoluteMaxWorkers and set it to 75 for all races. Zerg already adhered to the 75 maximum, so this affects terran and protoss. Making too many workers is bad because it reduces the army size in the late game. 75 workers leaves 125 supply for army.

• I added another macro option ProductionJamFrameLimit and set it to 1440, which is 1 minute. If no macro action (like producing a unit or starting research) is carried out in that time, the production manager assumes that production is frozen by a deadlock and clears the production queue. This at least prevents production freeze bugs from bringing Fimbulwinter, and it doesn’t cause harm if production is slow because of lack of workers. Terran and protoss have many production freeze bugs, and zerg has a few despite an eradication campaign.

• I added a debug option DrawMapDistances.

• I removed the debug option DrawStrategySketch since it was limited and only for zerg. Use DrawStrategyBossInfo to get the same zerg info and more.

code

• The regex bugfix in MacroAct::MacroAct(const std::string & name). I learned it from gnuborg, who credits jaj22.

• I fixed bugs related to finding the unit type of a MacroAct that is not a unit. The bugs probably caused occasional bad behavior, though I don’t know what.

• Renamed the micro managers with a Micro- prefix. RangedManager became MicroRanged, TransportManager became MicroTransports, etc. More specific names make the code easier to understand.

• Removed unused files HardCodedInfo.* and snips of unused code throughout. Some unused code I left in place, when it seemed potentially useful.

• No longer time MapTools every frame, since the class doesn’t have a job that it does per frame. It’s a utility to be called by others.

• SquadData::addSquad() no longer redundantly requires the squad’s name (already known by the squad itself).

• SquadOrder::isCombatOrder() and SquadOrder::isRegroupableOrder() factor out decisions that used to be scattered through the micro managers.

• I changed many cases of for (auto & unit : units) to (const auto unit : units). A unit is already a pointer, no need to take a reference to it. I hope the optimizer comes up with the same code in both cases, but redundant references are bad style.

• CombatCommander::update() updates all squad memberships in one go. In a previous version I tried to optimize it to spread the work across frames, which turned out to risk problems.

Steamhammer 1.2.3 is uploaded, playing zerg as Steamhammer and random as Randomhammer. The previous version 1.2.2 was clearly stronger than earlier versions, though it was overtaken by newcomers during its long life. If this version lives up to its test results then it will be stronger yet. For example, in my tests 1.2.3 zerg crushes #3 Killerbot by Marian Devecka like an egg.

The first version of Randomhammer came out 100 elo weaker than its parent UAlbertaBot, due to playing more varied and less aggressive openings. The test version running lately was maybe 50 elo stronger than UAlbertaBot on average (though it’s hard to estimate, because UAlbertaBot’s rating is unstable). And its openings have become a little more varied yet. New version 1.2.3 should be even stronger. So I think Steamhammer should be a reasonable starter bot no matter what race you have in mind.

Next up: The rest of the release tasks. Then I’ll bring up a public repository. After that I’ll finally be free to look into the new SparCraft.

• the change list (blog post)
• update Steamhammer’s web page
• update the documentation
• public repository

I did get an “argh, how did that go wrong?” A new bug is affecting terran. I hadn’t seen it before, but suddenly, in game after game, BOSS started ordering up 2 spare barracks when the bot is playing a mech strategy with no barracks units. The BOSS goals look correct, so I must have changed something to tickle a bug. Argh, etc.

Look for the Steamhammer 1.2.3 release tomorrow. Surely I’ll be able to work around it by then, and surely nothing else critical will go wrong....

The Steamhammer 1.2.3 release will be tomorrow unless a surprise comes up, where “surprise” means “argh, how did that go wrong?” Nothing is left but testing and minor tuning.

Even though it has only been a few days, I got a lot done. In some situations, the release version will play dramatically differently. Compared to the test version that’s live now as Randomhammer, it has these brand new improvements:

• I added a corsair-dark templar opening for PvZ. Steamhammer plays it weakly, but I set it to happen only 5% of the time. The bot won’t be worse overall, and it will add variety. Mostly I wanted to put an example out there as inspiration.

• Terran and protoss flying units usually go into a flying squad separate from the “main attack squad” on the ground. Zerg has worked that way since December. Each squad gets a detector, if one is available, just like zerg.

• A squad is only sent to fight enemy flyers if it has at least one unit that can shoot up, and to fight enemy ground only if it can shoot down. This should—not entirely fix, but mitigate the problem of dispatching ultra-ling to fight carriers.

• With that in place, overlords can be acceptable tactical targets. (They’ve always been micro targets, which is different. A tactical target is one that you send a whole squad after.)

• Targeting is improved in a number of ways (I mean micro targeting for individual units). I fixed a bug in calculating the attack range of a bunker and added the ranges of reavers and carriers. Fast units that can escape are less likely to become targets. Targeting of workers is tweaked in a couple cases.

• The zerg strategy boss understands how to react to enemy static defense, both in economy and unit mix. I cut a few zerg openings much shorter to give the new skill a chance to work. In some situations, it is awesomely effective.

This is just a sketch of the latest. Details on all changes will come with the release.

The test version of Randomhammer has done well over its first 2 days. Its elo has crept above Steamhammer’s, and having watched the games, I think this Randomhammer may truly be better as random than the older Steamhammer is as zerg, even though its terran is still weak. Anyway, the important conclusion is that I didn’t introduce any major weaknesses this time. There are some new weaknesses, but they are more than offset by new strengths.

The worst bug came in a game against Krasi0, when Randomhammer randomly became terran and decided on its vulture drop strategy. I would have liked to see that, but when it came time to add the control tower to the starport, no control tower started. The vultures waited in vain for the dropship. Randomhammer fell into a production freeze, which ended only after it timed out—it’s a new feature to prevent permanent freezes, but the timeout has to be long, so it doesn’t help that much. Terran addons are finicky because the production code is not robust enough. I’ll work on it.

Some problems that I worried about did not come to pass. My work to make the army less distractible has made it more distractible (it’s not an easy problem to solve), but the changes seem to help on average. The bot is less willing to concentrate its forces when it should, but it is more skilled at splitting its forces when it should, and it appears to be a net gain. It’s another issue to work on.

Terran has a revamped tank opening that brings a stronger economy and includes a vulture and several marines in the early army. I think it should be more effective against most opponents: The marines and vulture should help early defense, and the stronger economy should mean that tank numbers build up faster. I was disappointed to find that the tank opening does not beat XIMP by Tomas Vajda, due to bad tactics. The mixed force arrives with 1 tank at the cannons and... sits there, unwilling to engage even though siege mode is finished. Only after more tanks arrive does Randomhammer siege down the cannons, and by then the carriers are nearly ready. Tanks are complicated.

Protoss still beats XIMP, now with dragoon-reaver instead of straight dragoons. A game with zerg versus XIMP hasn’t come up yet. I fixed the problem that caused Steamhammer to often skip spire against the carriers, so it should do better. I did not fix the problem that causes ultra-ling to seek out carriers and stand underneath them dying, though I have put infrastructure in place for the fix. After I get that one, surely XIMP will be toast.

As promised yesterday, a test version of Randomhammer is uploaded to SSCAIT. The most important changes:

• Terran supports several new skills. Infantry play in particular is improved.

• Protoss supports more units that need special handling: Reavers, carriers, archons. The middle game has more transitions and makes use of the new units.

• Drop is supported, in a limited way. Terran and protoss have new drop builds. Terran plays vulture drop about 10% of the time. Protoss plays dark templar drop about 15% of the time.

• Zerg has a number of minor improvements, but benefits most from reworked openings in ZvP and ZvZ.

• For all races, some openings are chosen differently, or at different rates, depending on the map size.

• There are tactical and micro changes. The biggest is that targeting decisions are made in a more flexible way. In the long run, the extra flexibility will improve play, but the current implementation has drawbacks. I’m curious to see whether it does better or worse overall.

• The bot surrenders without waiting for you to finish off its last buildings.