Starcraft AI blog

In one of the recent SSCAIT casts, Nepeta said that he had seen every Brood War spell used by one bot or another. He’s ahead of me. I still haven’t seen one building, one unit, and several spells from bots. Of course, I do have a bad memory (if I recall correctly). What have you seen that I have missed or forgotten?

Optical flare, aka blind. Krasi0 can use medic restoration. Have I missed optical flare because it is hard to notice?

Nydus canal. Pablo Garcia Sanchez used to make nydus canal starting points, but never connected them to end points.

Infested terrans. Garmbot infests command centers, but doesn’t use them.

Ensnare. Garmbot and Tsmoo zerg can use parasite, and I think all bots that make queens know broodling. I don’t recall having seen ensnare, useful against wraiths or marines that clump up. I would dearly love to attract a clump of marines to one spot with mutalisk attacks, ensnare them, and then move to attack somewhere else.

Maelstrom. I’ve seen dark archons feedback and mind control, but never maelstrom.

Hallucination. It could a difficult skill for bots to use well, because it’s about fooling the opponent. On the other hand, bots may be easy to fool. A good first use might be hallucinated zealots to clear mines without detection. Another good use would be to hallucinate carriers to soak up scourge—zerg bots will not catch on but will keep drawing down their gas.

Disruption web. Surely some bot uses this? Roman Danielis? I don’t remember having seen it.

I thought of another theory to explain why Steamhammer’s elo might have changed after the last mini-tournament.

Your rating depends on the mix of your opponents. Elo measures average strength. You will generally do better than your average against some opponents, and worse against others. And because of the voting system on SSCAIT, your mix of opponents depends on what people think of your bot. If they think it’s more fun to watch you lose to enemies that have your number, your elo goes down, or vice versa. Because of voting, elo depends on reputation.

Before the tournament, Steamhammer was getting more matches against Bereaver. Maybe it still had novelty value; maybe voters liked seeing the powerful Bereaver get crushed by zerg exploiting a narrow window of weakness. Anyway, that tended to drive up Steamhammer’s elo. Since the tournament, in which Steamhammer did less well than people may have expected, it gets fewer matches overall and more of them are against opponents that give it trouble, like Wuli. Its elo ought to have fallen some because of that.

Somebody who was interested might dig through the game history and try to figure out the bias that reputation lends to each bot’s elo. How much would the elo change if the mix of opponents were exactly even? I think that elo is a pretty good system, and despite reputation effects, elo depends mostly on strength. Am I right?

Randomhammer, on an unrelated note, had a good day today. It scored a win as protoss against Iron with a zealot rush; Igor Dimitrijevic is apparently trying to reduce Iron’s overreaction to early aggression from the opponent, and it underreacted instead. Then it won as zerg against Krasi0 when terran played an 8 rax into vulture build against fast mutalisks. Neither game was interesting, but it was satisfying to beat the leaders.

Steamhammer’s elo stabilized over 2300 before the last mini-tournament. It is clearly the strongest version yet. Randomhammer’s elo rose to around 2100, as I forecast. All races are stronger than before.

Then Steamhammer’s elo crashed during the tournament. 5 Pool had just learned how to beat it, and Tscmoo protoss finally settled on its winning opening too. Also of course it was playing a larger proportion of games against Iron and Krasi0, and against Killerbot by Marian Devecka, which this Steamhammer scores about 50% against.

After the tournament, with 5 Pool disabled, Steamhammer’s elo still hasn’t recovered. It hovers around 2200. Tscmoo protoss hasn’t forgotten its winning opening. Also the zergs Ailien and Microwave have improved to beat it more often, getting better air defense and reducing their strategy mistakes. Even lower-ranked protoss Lukas Moravec has been winning games with its zealot rush, stealing gas in some games. Steamhammer doesn’t work around the BWAPI geyser bug and its game plan is derailed by a gas steal. I think Steamhammer’s #3 rank (since lost) and its status as the handle of a fork with many tines made it a target, and since it has plain weaknesses, people have figured out how to exploit them. Or maybe they’re trying to reprioritize my to-do list, “This is the important weakness, please help.” :-)

Meanwhile, I’ve been spending most of my effort on skills for protoss and terran. The next Steamhammer will come with protoss DT drop and terran vulture drop, but no zerg drops. Overlords are more complicated, and I decided to save it for later. (Getting drop to work at all needed a mess of code changes across classes: CombatCommander, Squad, SquadOrder, MicroManager, other micro classes, StrategyManager—and that is accepting the limitation of dropping a fixed set of units, once, from one dropship or shuttle, and then transitioning out.) Terran will track its use of scan and have more infantry skills and smarter tanks, protoss will support more unit types and use them, both will have more transitions and other improvements. Also I’m making micro changes for all races which add flexibility but require tuning, so there may be new micro weaknesses until I figure out what works.

I hope to get in zerg specific improvements to overcome the biggest weaknesses. I know what to do, but the list is long and I’m not sure how far I’ll get. Anyway, the bottom line: I can’t promise that the next version will be stronger. What I know for sure is that it will be more interesting.

And I can’t wait to get back to zerg.

I enjoyed this game of m-khan’s KaonBot versus XIMP by Tomas Vajda, showing another way to beat the carriers.

As I write, KaonBot is rated about 1900, so it is a slightly worse than average bot. I would say that it is at the high end of the low-ranking terran bots. KaonBot goes mass marines every game (with medics and upgrades), which is a severe limitation, but it has above-average smarts in adapting its economy to the situation. Against XIMP, KaonBot quickly took the entire map, except the island bases. XIMP could not get a third base because they were all taken!

Marines are deadly efficient at shooting down interceptors, because they do normal damage rather than explosive damage like goliaths, dragoons, or hydralisks. The picture shows marines fighting interceptors and cannons. The carriers could not keep interceptors in the air. This first infantry force was not enough to clear the cannons, but a later one was.

KaonBot seems to score around 50% against XIMP, which is pretty good.

Ways to beat XIMP, with example bots:

• cloaked wraiths - WOPR by Soeren Klett (with goliath-tank followup)
• goliaths - Krasi0
• marines - KaonBot
• tanks - Tyr by Simon Prins (wipe out the cannons before the carriers are out)
• ghosts - nobody yet?
• hydralisks - Killerbot by Marian Devecka
• hydra-scourge - UAlbertaBot by Dave Churchill (special build order for XIMP)
• ultralisks - Ailien (ignore the carriers, kill the bases)
• dragoons - Steamhammer playing protoss (with a 13 nexus build)

Protoss has the most trouble against the carriers, but when Randomhammer rolls protoss, it goes with a straightforward nexus-first build that produces enough units to break the cannons. AIUR does the same thing sometimes, though not as consistently. If you get far enough ahead in macro, it should be easy to win with almost any strategy.

It should be, but it isn’t always. Steamhammer zerg still struggles against XIMP, losing games due to several bugs and limitations. On 2-player maps Steamhammer doesn’t finish its opening build order, and depending on how it scouts, it may not make a spire (which makes the win easier). In the most recent game, Steamhammer took many bases and crushed XIMP’s natural and main with ultralisks, leaving only the protoss third, then lost by streaming ultra-ling into the empty protoss main to be slaughtered by carriers until zerg finally mined out. It’s a combination of a scouting limitation, a tactical limitation, and an expansion bug. Too much to fix!

I have questions about patch 1.18. There must be discussion, but I haven’t seen it, so—can somebody pass along the state of affairs?

BWAPI of course supports only 1.16.1, and we’re stuck with that version for a time. Instructions on setting up a bot to play include a step “connect to battle.net and update to version 1.16.1”. It’s a necessary step; certainly my CD came with an older patch. And that ain’t gonna work no more. So... this doesn’t affect me directly or immediately, I’m already set up. But it seems critical for the community.

1. What is the best practical solution?

2. Is 1.16 legally available? Is it free too, or was only patch 1.18 made free-as-in-beer? Are people going to end up passing around bootleg 1.16.1 versions for the newbies?

Protoss Pinfel is reactivated. It is scoring few wins, but I enjoyed watching its games. It defeated Microwave and had narrow losses versus Johan Kayser and versus McRave. It’s a good result for a new bot made from scratch.

Pinfel makes the most extreme form of all-in attack. It brings every single unit, including all probes; the attack wins or loses, and that is that. Good micro counts but other skills do not come into play, so it is a fine choice for a new bot which doesn’t have many skills yet. It will encourage the bot author to work on micro, which will pay off even if the bot switches to a different strategy later.

An all-in attack can be less extreme. “All-in” means that the attacker is deliberately setting itself far back in order to make a stronger attack, and will be losing if the attack is not successful. The attack is successful if it harms the enemy enough to make up for the setback. It’s a threshold: Do this much damage or probably lose.

The goal of going all-in is do fatal damage, so if you’re bringing workers it rarely makes sense to bring only a few workers. (Exception: A zerg versus zerg sunken rush.) Bring many workers. If you bring all workers, your damage threshold is: Wipe out the enemy entirely. Pinfel’s narrow losses against Johan Kayser and McRave came when it almost but didn’t quite meet the threshold; the enemy’s last two or three surviving units were enough to turn it around.

If you leave some workers behind, your damage threshold is lower. You’ll have fresh production, though it will be slow, and you can still win if a few enemies survive. Pinfel would likely be stronger if it left a few of its probes at home. Using the few workers to best effect requires more skills, but simply making extra units as the cash comes in is easy and gives you a chance if the enemy narrowly survives.

If an all-in attack catches an enemy with its army out of position to defend, the enemy may decide to go after your defenseless base instead, triggering a base race. If you’re planning to all-in, it makes sense to prepare: Build a pylon, or supply depot, or zerg extractor, in some hard-to-scout spot on the map. You can lose your entire base and still win if the enemy doesn’t find your hidden building.

I count 10 bots updated since the mini-tournament. That’s a lot. 5 Pool started losing some games and was disabled, with a message “Want to create a bot which doesn’t only 5 pool.” I think the strategy is showing its limits. Once you’ve seen the range of followups, it seems to me not all so hard to counter all of them.

I miss Pinfel, disabled before the mini-tournament with a losing score of 3-10. It played a zealot-probe all-in bringing every single unit, unlike any other bot. I recommend occasional all-ins for strong bots, even if they’re risky. If you have opponent modeling, recognize greedy opponents and bust them; if you have good judgment, recognize opportunities and seize them; if you’re not that bright, like Steamhammer, then randomly all-in (say) 5% of the time to keep ’em on their toes, to challenge their opponent models and judgment.

A few observations on Krasi0’s new play:

• I thought Krasi0 was more cautious about detaching groups and sending them forward without enough support. That’s an improvement. It also seemed even more hesitant than before to expand, at least while under pressure. I suspect that a bot which could keep up constant pressure while simultaneously defending its expansions from vulture raids and harassment drops might starve out Krasi0 and win.

• Against Iron, Krasi0 backed up its bunker with a vulture, which appeared to forestall Iron’s runby—and then went 2 port wraith! Is that a new build, or is only the vulture new? An early vulture seems normal in a 2 port wraith build. Anyway, it worked well enough; Krasi0 beat Iron, which it has rarely done lately.

2 port wraith could be deadly against macro zergs, or against any bot which doesn’t grasp air defense. For terran against Iron, for the middle game I suggest a tank-heavy army with some goliaths mixed in. I think that meets all of Iron’s preferred unit mixes.

• In the most recent games, I noticed that against Steamhammer’s mutalisk play, Krasi0 made turrets only near the bunker where Steamhammer persistently maneuvers. Against 5 Pool’s mutalisks, Krasi0 made turrets all over its base before any attack, which was helpful given how that zerg plays. What’s the difference? Is it a hard-coded behavior, or is it the result of opponent modeling? Or did I watch the wrong games?

The bot bftjoe by Joseph Huang fixes a bug in UAlbertaBot that I did not catch.

bool UnitUtil::CanAttack(BWAPI::Unit attacker, BWAPI::Unit target)
{
    return GetWeapon(attacker, target) != BWAPI::UnitTypes::None;
}

Easy to type, easy to read past... and totally wrong. Unit type None is 228, which does not match the value of any weapon type, so it will always return true. “All ints are the same type, right?” Bjarne Stroustrup: “Uh, sure.”

bool UnitUtil::CanAttack(BWAPI::Unit attacker, BWAPI::Unit target)
{
    return GetWeapon(attacker, target) != BWAPI::WeaponTypes::None;
}

In UAlbertaBot, CanAttack() is used only in the tank manager, so the damage, er, fallout, er... severity is limited. Steamhammer additionally uses the function in controlling lurkers, which it does not build by default because its control is so poor. So the next Steamhammer version should be a little less clumsy with tanks and lurkers. Still pretty clumsy, though; the clumsiness runs deep.

Tomorrow: The newly uploaded Krasi0 seems to be playing new builds.

It’s decided. The next Steamhammer version will support drop. Dave Churchill had already implemented most of the skill: Choosing a transport for the job, sending it on a sneaky path around the edge of the map, and unloading it near the enemy’s mineral line. The remaining bits are proving surprisingly tricky: Choosing units to load, keeping them together until everything is ready, loading them up (seems like a key step), and not doing anything too ridiculous after they land (“oh no it’s scary here, let’s skip this job and go home”). Even so, I expect to get it working reasonably well by tomorrow, the day after at worst.

It’s limited. It only supports 1 transport, and after dropping it does not know how to reset itself for a second drop. Better make the one try count! I wrote a dark templar drop build for protoss. I’ll try to add a terran drop build, though it won’t be as dangerous. If I feel ambitious I’ll do the bit of extra work for a lurker drop too.

It’s a good start. Fancier versions can come along later.

Update: The first time I got a dark templar drop to land in a terran base, the dark templar said “Uh oh, our own base is under attack. We must ignore the enemy in front of us and walk across the whole map to defend!” Not doing anything too ridiculous after they land is a vital skill....

SSCAIT’s mini-tournament is not quite finished as I write.

The irritating news of the tournament: Steamhammer played 2 tournament games versus XIMP by Tomas Vajda, plus one game shortly before the tourney, on the same map (Benzene) with the same starting positions (protoss on the left, zerg on the right). Just how random is it? The 3 games were nearly identical, down to individual army movements, and Steamhammer lost, as it should have, because it doesn’t understand map blocks and couldn’t finish its opening build. Sometimes luck hits like a truck.

The interesting news of the tournament: Tscmoo protoss is doing surprisingly well, including against opponents that it has a mixed record against. Did its opening learning, which was reset in December, finally gather enough data to make good decisions? We’ve seen before that Tscmoo brings its best against strong opponents. What’s behind that?

A razor close game between Steamhammer and Microwave on Python: Steamhammer opened with overpool into fast spire, while Microwave went overpool with zergling speed and mass lings, leading to a later spire. Steamhammer made 2 sunkens with its spire. When Microwave’s zergling numbers grew large enough, it defeated Steamhammer’s lings and pushed in; the sunkens and 2 fresh zerglings were barely enough to hold them off. When its faster second hatchery came online, Microwave attacked again; the second wave killed the sunkens and a couple of drones, but the first mutas cleaned up. The third wave left 2 Steamhammer drones alive, and by then Microwave’s spire was up too, and soon Microwave destroyed Steamhammer’s spire. Steamhammer scourged an overlord, which delayed Microwave just enough. Here Microwave is adding drones when it should be replenishing its army.

If you make too many drones in ZvZ, you die. Microwave was behind in air power and did not keep the pressure on. Steamhammer killed another overlord, outmicroed the scourge...

... and brought down the excessive number of drones while defeating mutalisks that spawned one at a time. Microwave helped by transferring drones from its natural to the main where the mutas were. Microwave might have held if it had gotten up a spore colony in time, but it was too late.

Krasi0 wonders what should be done about the flood of related zerg bots. As Californians know, it may relieve the drought, but it is still a flood. Some bots play very similarly and could be boring to watch. Anyway, the ideal SSCAIT should have a good balance of races and play styles and not grow too lopsided, at least not for long.

It’s the kind of decision that should be made pluralistically. Stream watchers have a legitimate interest in seeing a variety of styles of play. It’s more fun. Bot developers have a legitimate interest in trying out adjustments to other bots: I think this change is a good idea, am I right? That’s fun too. But the interests can come into conflict, especially with a new bot like Steamhammer: It is accessible, it is successful, it is easy and fun to modify, and it has obvious flaws in its play that call out for correction. We might get too many near-identical Steamhammer clones.

Doing nothing for now is a choice. There is no serious problem yet (if you ask me), only a threat of one. When you first get into bot development, it’s natural to start with small tweaks to a starter bot; I did it too. Historically, most bots are developed for a while and then left to age and slowly turn into vinegar. Nobody will object if a near-clone bot is turned off after its active development ends. Some bots get ongoing development, and those won’t be clones for long. They will diverge. If that’s how things go, then we don’t need a new policy, we only need to continue the current policy of disabling bots which are boring and not under active development.

Here are some ideas if we want to make a change. They are not mutually exclusive; we could do all of them.

1. Make rules. Admins could decree that clone-like bots will be summarily disabled unless and until they do something interesting. It might be a good idea if stream viewers get tired.

2. Implement a server-side incentive for more varied behavior. For example, let people vote bots up and/or down, maybe with a long-term effect on how many games to bot gets to play. Or maybe adjusting a public “interestingness” ranking value that bot authors may be happy or unhappy with. (I would like to have that measure, if somebody can think of a good way to implement it distinctly from a measure of strength: Roman Danielis is interesting but not strong; Marian Devecka is strong but has predictable play). Or have admins flag near-clone bots in their opinion, which (say) counts for -1 vote for that bot in the existing match voting system. Many designs are possible. The goal would be that boring bots are allowed, but get less stream time or are otherwise discouraged. A related idea is to somehow mark bots for similarity, so that when one bot plays, others that are similar to it get less time depending on how similar they are seen as being.

3. Promote bots other than Steamhammer on the SSCAIT site. I think Skynet by Andrew Smith would be a good protoss starter bot. It is Gnu licensed. It is old code and still on BWAPI 3.7.4, which may be a drawback, but it comes with a cool strategy programming system that lets you specify behavior at a high level. It should be relatively easy to give it fun new behaviors, plus it already has a large number of skills that could be improved one by one. I’m not sure what a good terran starter would be.

4. Make Steamhammer better at terran and protoss. Not me; I’m itching to get back to zerg after the upcoming batch of terran and protoss features. Once my collaboration site is set up (hopefully by early May), it will be easier to propose improvements to Steamhammer. I’ll incorporate any that make sense to me, even if race-specific. In general, the different strains will more easily cross-fertilize. Alternately, maybe some developer is interested in starting a terran or protoss fork that will get ongoing development.

5. Supporting more units and skills will also help Steamhammer forks be more diverse. Does anyone want to implement spider mine placement, or psionic storm, or arbiter recall? If you do a good job, I’ll be glad to put it into Steamhammer with credit. I will eventually get to these skills myself, but it is not a priority so it will be a long wait.

6. UAlbertaBot and Steamhammer carry out simpleminded tactics that obstruct alternate styles of play, as PurpleWaveJadien pointed out in comments to the previous post. So one mitigation is to put a smarter tactical boss into Steamhammer, one that supports more varied tactics. It’s not a matter of using SparCraft or not, it’s the tactical framework. “Main force here, sandwiching force there, go!” A new tactics boss is a priority for me, and I’ll be working on it over the year. I may start with mutalisk tactics only, but in the end I want an easy-to-adjust framework that represents its goals explicitly, works for all races, works with all kinds of unit mixes, carries out a wide variety of tactical plans, and has hooks to apply machine learning. I expect it will come piece by piece over months, so no quick fix.

7. Keep Steamhammer temporarily closed-source after a new feature release. Publish the source only after some suitable period, or when the following feature release is ready. Maybe it would help? I’m not sure. At least Steamhammer itself would be more distinct from its recent clones.

8. Seek a super-configurable starter bot whose behavior can be radically changed by changing data files, or which provides a Starcraft-specific higher-level language that makes it easier to code strategies and tactics. If we had that, clones might diverge more rapidly. Well, it’s a long-term aspiration more than a plan. Somebody would have to be convinced to do it, and then figure out how.

The world is full of more ideas than one person can think of. What do you think?

For anyone who hasn’t noticed, the second weekly SSCAIT Ladder Tournament is underway. Here’s the tournament series main page so you can follow along as more of these little competitions come up.

Now, if you’ll excuse me, I need to go do something to prevent the zerg column in the tournament participant tables from growing even longer. 6 of the 13 bots this week are zerg and share common heritage in their family trees. Tonight I’m implementing stim for terrans. Steamhammer’s terran infantry skills are almost good enough to pose a serious threat to zergs—just a couple more skills....

The bot 5 Pool is being updated often, and changing its play very noticeably. I took another look.

The author’s plan, as I see it, is to beat lower-ranked opponents with an opening that is difficult for them to cope with, and higher-ranked opponents with hand-chosen counterbuilds. And, of course, to show off by striking a pose with a disco ball, or that is, by doing it all with variants of 5 pool. It’s kind of a cheesy way to use a cheesy opening, but if it promotes progress then I don’t mind.

The method is to make minimal changes to a Steamhammer fork and code up several variants of 5 pool. Earlier versions of 5 Pool stuck with zerglings, but found themselves too easily hard-countered. Newer versions code in mutalisk openings for some opponents. The play is closely similar to Steamhammer’s, strengths and weaknesses alike, but I am able to spot a few improvements in 5 Pool over its parent.

This version of 5 Pool uses Steamhammer’s random opening choice in ZvT and ZvP, playing 3 different 5 pool variants against each. It plays only one variant versus zerg or random (the first one listed below). So terran and protoss can’t simply survive the opening and call it a win, they have to be able to cope with the variants:

• 30% - straight zerglings with 4 drones
• 30% - zerglings with 6 drones (a slightly weaker first hit but a much stronger followup)
• 40% - zerglings with 6 drones and an early second hatchery (the most natural approach)

Bereaver, Iron, Krasi0, Steamhammer, and Stone get hand-chosen counterbuilds. Bereaver and Stone will suffer, since they have weaknesses and aren’t being updated. Iron faces exploitation of its predictability: Terran overcommits to defense against the fast zerglings and has lost games where zerg instead macros up and goes mutalisks. But Iron improves at an incredible rate and, I expect, will soon tighten up its defense decisions. 5 Pool is set to play the same build against Krasi0 as against Iron, and Krasi0 did lose a game to it, but Krasi0 has opening learning so it has a chance to adapt. This version of Steamhammer plays a fixed build against 5 Pool and, like Iron, can be exploited because of the predictability of the strategy boss. Steamhammer hasn’t lost a game to 5 Pool yet (as I write), but I think 5 Pool is getting close to a successful exploit and this version or the next is likely to score wins. Therefore the next Steamhammer version will play random openings against 5 Pool and become difficult to exploit.

5 Pool has set itself a hard task. Its opening is easy for strong bots to counter, so to win it must play better in the followup. Even so, it is scoring some wins against the top bots, forcing them to improve. And that is good.

Update: As I forecast, today’s version of 5 Pool can finally beat Steamhammer. 5 Pool exploits a weakness in the strategy boss, which does not adapt to the enemy’s static defense. It ought to make fewer of the units that the static defense counters and spend more on drones and tech to stay ahead. There is no sustainable plan behind 5 Pool; the author put out new versions for days before success, around 3 times as long as it will take me to improve it. I don’t even need to improve it, because I can prevent any fixed counterbuild from succeeding with random opening choices, since opening with 5 pool puts 5 Pool far behind. Anyway, 5 Pool can take its wins and brag for a while. Stand by for the next Steamhammer version around the end of April. Protoss now supports reavers and carriers, and today I need to test the carrier play some more.

Oops, Steamhammer became the #1 bot on the SSCAIT ranking.

It pulled ahead of Krasi0 by a hair. I don’t expect it to stay #1 for long. It still can’t beat Iron or Krasi0 more than occasionally. Iron has lost rating points lately because Igor Dimitrijevic is putting it through a strategy change, and it will take time to tune up Iron’s new play. As that proceeds, Iron will work to claw back its first place. In the meantime, apparently Steamhammer has been defeating lower-ranked bots about as reliably as Krasi0 does.

I have to give in and admit that Steamhammer is no longer merely a threat to the top bots, it is a top bot itself, even if it struggles head-to-head against the very best. Well, I predicted all along that bug fix release 1.2.2 would restore the strength of 1.2 and then some, after the dip caused by bugs in version 1.2.1.

Meanwhile, Randomhammer has been getting fewer games and its rating has not stabilized yet. I’m expecting it to reach about 2100, maybe a little more. The bug fixes should make all races stronger.

Moral: Experience shows that feature releases are sometimes stronger and sometimes weaker, but bug fix releases are always stronger. Fix more bugs!

BWAPI 4.1.2 has two bugs that (it seems to me) pinch zerg hard. One is the hive research bug that prevents a bot from doing lair research in a hive (and related bad stuff). This bug is why Steamhammer so rarely gets overlord speed; it wants a fast hive. Someday I’ll work around it as best I can, either making a second lair or spending on overlord speed first whether or not it is needed at the time.

But today I want to talk about the other bad bug, the extractor bug. In BWAPI 4.1.2, when a gas mining building of any race is destroyed or canceled, the geyser goes dark: It is treated as a unit which is out of your vision, and you can’t get information about it. geyser->exists() returns false, even when you are standing next to it and it’s in plain sight.

UAlbertaBot and Steamhammer are unable to take the dark geyser. That is why, when Steamhammer loses its gas, it never retakes it. The geyser is permanently lost to it.

I’ve never seen it done, but in principle the bug could be used offensively: Take your opponent’s gas but cancel your refinery building immediately. Do it again in the natural, if you like. Against a BWAPI 4.1.2 bot, the geyser goes dark permanently. Steamhammer would have little chance to recover. Rules don’t forbid it; after all, it is in a sense Steamhammer’s own fault that it can’t recover—nobody required it to use a buggy library.

I hit this bug back in Steamhammer 1.0 when I implemented the extractor trick: At 9/9 supply, start an extractor which uses up a drone and takes you to 8/9 supply; make a new drone, returning to 9/9; cancel the extractor, getting 10/9 supply. I wanted to try the old school 10 hatch opening which is strong against 2 gate zealot rushes. The extractor trick is a slightly fancy skill with a lot of potential failure cases, but I thought it through and implemented it with all the checks—then never used it in production or advertised the feature, because once the extractor was canceled it could never be taken again. That’s why I say that the bug is particularly harmful to zerg: The extractor trick is a basic zerg skill for getting an extra unit in certain openings, and for restoring the health of a drone in the field which has gotten into a scrape (which could count as the offensive exploitation of a bug, which I don’t want to do).

Is there a workaround? I hope that there is still a way to take the geyser after it goes dark. I tried a couple of quick fixes and did not find a workaround yet. The issue discussion says that getAllUnits() returns the real geyser, but it did not work for me. I will have to dig into the code to see what’s happening, and I’m a little reluctant to put in the effort without knowing whether it will help. So I ask: Does anybody know a workaround? Do other 4.1.2 bots cope successfully?

I took a little time to look into the bot named 5 Pool, checking the version just uploaded. I had noticed that it didn’t play exactly the same version of 5 pool in every game.

It’s a Steamhammer fork (which I already knew from watching its behavior). It no longer comes with a separate configuration file, but that’s no hindrance to understanding it. It uses the go defensive/go aggressive commands, so either it is a fork of 1.2.1 or 1.2.2, or it has backported recent changes to an older version.

It plays the same version of 5 pool usually, but it has exceptions for 5 specific opponents. Killerbot by Marian Devecka, bftjoe, and Krasi0 get a different 5 pool that makes 2 extra drones after the pool (which is stronger overall, but does require an earlier overlord so it may hit less hard at first). Stone gets its own specialized variant of 5 pool which makes 2 further extra drones (for 4 total after the pool) after the first round of zerglings. And finally, Steamhammer gets an even more specialized variant that makes a bunch of drones after the pool, uses go defensive and go aggressive at specific timings, and switches into 3 hatch ling in an attempt to overwhelm the 2 hatchery build that Steamhammer plays against 5 pooling bots. Ha ha, that is what I get for playing a fixed opening! I deserved it! The next version will regain support for random choice of openings when playing specific opponents, which will put paid to that.

Well, Steamhammer’s anti-5 pool build in the dev version is a little tighter than in the last release version (it’s been days already, I can’t leave an opening alone that long, it will grow sad). 5 Pool’s counter may work against version 1.2.2, I haven’t tried it. But I did run a test game against the dev version, and Steamhammer won with surprising ease. I think it is quite hard to counter a 9 pool with a 5 pool, even if you know the exact 9 pool build order and aim for its weakest points.

I have a bit of a philosophical question: How far can you get by tailoring variants of the same extreme opening to different opponents? At the moment, 5 Pool is #6 on the rating list, very high for a bot that plays a fixed opening which all strong opponents have seen before and should be ready for. And it has room to grow: There are tactics that 5 Pool does not know which could make it much scarier. For example, it doesn’t know how to run by a bunker. Martin Rooijackers thinks that the cheese openings are dead, but I think they still have some life in them.