Starcraft AI blog

In one of the Undermind podcasts there came up the recent Rich Sutton essay The Bitter Lesson. The basic point of the essay is true: “general methods that leverage computation are ultimately the most effective.” (That is why, though I don’t post about it, behind the scenes I am implementing a machine learning method for Steamhammer.) Nevertheless, I have a complaint about what he says.

Rich Sutton (home page) is a big name in machine learning, and his opinions are worth attention. He is co-author of the major textbook Reinforcement Learning: An Introduction, which I recommend. On his home page you can find more short essays on AI topics; I particularly like Verification, The Key to AI. He’s a smart guy who thinks things through carefully.

Reading The Bitter Lesson, the first paragraph makes perfect sense to me. I might quibble with minor details, but I have no substantial objection; I agree with it, it’s correct or nearly so. Then he goes into examples, and there I feel that he misrepresents history in a cartoonish way. That’s not how the bitter lesson was or is learned.

In the computer chess example, “this was looked upon with dismay by the majority of computer-chess researchers” is false. The Chess 4.x series of programs by Slate and Atkin showed in the 1970s that massive search was more successful than any other method tried. Long before Deep Blue defeated Kasparov, work on knowledge-based approaches was a minor activity; I have a pile of International Computer Chess Association journals to prove it.

The example of computer go is also presented misleadingly. I subscribe to the computer go mailing list and have listened in on the conversations since before the deep learning revolution in computer go. In the old days, people were writing complex programs with too many varieties of hand-coded knowledge, not because they were sure it was the right way—I think everyone agreed that it was not very successful—but because nobody had found a better one. There were experiments with neural networks that intimated that a breakthrough might be possible, but until AlphaGo, the breakthrough was not achieved. The big lesson was not “use a general method of massive learning,” it was “here is the recipe for massive learning.” Finding the recipe was extremely difficult; people had been working on it for many years of slow progress, and victory did not arrive until there were technical breakthroughs in deep learning and DeepMind brought its great resources to bear. Knowing that you should use massive search and/or massive learning is only a tiny part of the battle; figuring out how to use them is the real fight.

That is exactly where we stand in Brood War. We know, and most agree, that search methods (as used in combat simulation) and learning methods (like deep learning) have the potential to be successful. And we have intimations of a breakthrough, bots that have achieved some of that success, like LastOrder with its macro model and CherryPi in TorchCraft with its build order switcher. But we don’t know the full recipe yet, and finding it is difficult work.

I thought that Sonko’s first SSCAIT cast yesterday was not particularly accomplished. Nepeta doesn’t always understand the flow of the game and sometimes misses events that are visible on the minimap, but with years of weekly practice he has developed a smooth presentation. Sonko chose good games, but is not all the way there yet.

Casting seems to me a difficult skill; I wouldn’t try it without rehearsing, which is time-consuming. The caster benefits from strong knowledge of game play, the maps, and the players, and needs to follow the events of the game in real time while both showing them on the screen in a way that viewers can understand and fluidly offering useful and interesting commentary. That’s a lot of different subskills to coordinate at the same time. There is a reason that pro casters work in teams, with a game observer plus two or more commentators who always have something to say and can report background information or banter with each other if the game situation is not interesting at the moment. If you watch closely, you can see that top game observers understand the drama of the game, and can deliberately ignore important developments until suddenly revealing them at the most exciting moment. That requires simultaneously interpreting the actions of the players and foreseeing the reactions of the viewers; it is nothing simple.

I’m sure casting is like other difficult skills: You can’t help but improve with attentive practice.

An enemy lurker or dark templar is in your base, and you have absolutely no form of detection nearby. Can you defeat it anyway? In many cases, yes.

An enemy unit can be in sight range but undetected if it is burrowed—a spider mine or a burrowed zerg unit—or if it is cloaked—a wraith, ghost, dark templar, observer, or a unit under an arbiter’s cloaking field. I’ve written before about countering spider mines, so I’ll skip that.

burrow versus cloak

When a cloaked unit is in sight, a bot knows where it is. Without detection the cloaked unit cannot be targeted, but BWAPI gives its type and position.

A burrowed unit does not give itself away. If the bot did not see the enemy burrow, and did not detect it since it burrowed, then BWAPI does not reveal that it is there. Exception: A lurker can give away its position when it attacks. The lurker spines are a bullet, in BWAPI parlance. However, if you try to build on top of a burrowed unit, construction will fail. Many bots use that fact to infer that a spider mine is blocking an expansion position, but the principle is general. In theory, you could locate burrowed zerglings by starting buildings in different positions. It’s rare, but I have seen a game where hold lurkers waiting in ambush in an expansion were discovered by trying to build a turret before any mining SCVs arrived.

spider mines

Spider mines will attack cloaked enemies. They are popular for fending off dark templar.

splash damage

An undetected unit can’t be targeted, but it can be hit by splash damage. Psionic storm is the simplest way; burrowed and cloaked units are affected like any other. Nuke may be overkill, but is effective.

An example: For protoss, the most common way to deal with a single undetected lurker is to park a friendly zealot on top of the lurker and attack the zealot with an archon. The zealot will remain stoic as it takes full damage, and the lurker will take splash damage. You may need 2 zealots to finish off the lurker. Skynet by Andrew Smith has this skill, and I wrote it up in 2016.

Any unit or spell that does splash damage will work—well, it has to do ground splash for ground enemies or air splash for air enemies (archons do both ground and air splash). Besides archons, popular choices are reavers, lurkers, and sieged tanks. Corsairs and valkyries are good for air splash. Firebats and infested terrans can theoretically work, though I’ve never seen it done. You can also do the eraser: Irradiate a unit (preferably an air unit) and keep it next to a dark templar or ghost—but then, if you have a science vessel, you have a detector, so the eraser is for when you have no other forces around. Spider mines do not attack friendlies and are the only splash damage unit that cannot be used, but they do attack enemies so you don’t need to. Mutalisk bounce does not count as splash; glaive wurms do not bounce to undetected enemies. Also devourer acid spores do not splash onto undetected air units—they will reveal a cloaked unit that they are attached to, but they can only attach to a unit that is detected.

Also, any target that will splash onto the undetected enemy is good—anything directly next to the undetected enemy. Sometimes you can target a building or an enemy unit.

revealing cloaked units

The queen’s ensnare and the defiler’s plague are area effect spells that work on cloaked units, though not on burrowed units. Besides affecting cloaked units, the green or red goo reveals cloaked units so that they can be targeted.

EMP

Wraiths and ghosts need energy to cloak. Hit them with EMP, and they are forced to become visible. Of course, the science vessel can also directly detect them. EMP might be worth it if the vessel is at risk (perhaps from the wraiths, or perhaps from ghost lockdown), or if one EMP can hit a group of enemies which will then have to build up energy to cloak again.

drilling cloaked units

Sometimes you only need to gain a little time before you can deal with the cloaked enemy. You can delay the enemy if you can force one of your units to overlap with it; both units will move randomly, unable to act, until they separate. Zerg can do this by unburrowing from under the unit, or by turning a larva into an egg when the unit is very close to the larva. All races can do it with a worker drill: Send workers to a mineral patch so that their path will take them through the position of the enemy—mineral walk through the enemy—then stop or attack when they are overlapping.

Any other techniques? I won’t be surprised if I forgot a few.

Insanitybot was also updated today. It is another terran fork of Steamhammer, and it is not particularly strong but it has been growing more interesting with every update. It has some play improvements over Steamhammer, but it appears that the author has put more effort into adding terran skills like wraith cloak, spider mines, irradiate, and more. This version also makes ghosts and cloaks them; I’m guessing that nukes may be coming down the pike.

This BASIL game against zerg CUNYbot by Bryan Weber shows off its ability to use optical flare. Optical flare research finishes a little after 11:00 into the game, and the first optical flare that I saw was about a minute later (because the cowardly medics had retreated from the front). Starting at 16:25, more overlords are blinded. CUNYbot does not seem to notice, but maneuvers the blinded overlords as usual—no doubt many other bots would also fail to react. Steamhammer doesn’t notice blind units either; it has never mattered.

Optical flare is similar to parasite in that it is more fun than useful. There are occasional situations where it can be valuable, but usually something else is more important. But that’s in human play; bots may be different. If nukes are coming, as I guessed, then maybe insanitybot will cloak the ghost, blind every detector that shows itself, and nuke in safety.

Few bots have the ability to destroy an undetected unit. Maybe I’ll write about that soon.

RedRum is a new terran bot. I would say “Yay!” but this version of RedRum is identical to Steamhammer 2.3 playing terran. It’s the same binary with a different name, and there are no changes to the configuration file that affect play. It does give the author as Ayran Olckers, the bot name as SteamRoll v0.1, and the bot’s race surprisingly as protoss.

I suppose this is a test run to figure out how to do stuff. Version 0.1 implies a future version with a bigger number. When RedRum starts to become interesting, perhaps under a different name if it turns into protoss, I’ll write about it again.

Looking closely at the newly implemented queen play, I noticed a bug that caused delays in action. The queen would spot a good target and prepare to launch its parasite... then lose track of what it was doing and execute a move instead, find the good target again, etc. I fixed it to keep proper track of its intentions, and suddenly the queen’s actions were prompt to the point of being overeager: It would move into range and cast its parasite, then before the parasite landed, parasite the same target again! I had to fix that too; it was not enough to stick to targets which are not already parasited. Then I realized... oh... this must also be the long sought Third Defiler Bug. Queens and defilers have their own code, but they work about the same way.

Last fall I added defiler support. In the winter I fixed two serious bugs (see the zerg section) in defiler control. And I suspected that there was a third one, because defilers still reacted sluggishly. This is the third bug—I finally found it.

When the queen fix is properly generalized for defilers, I expect that defilers will start getting stuff done. As ground units they will still meander into traffic jams and struggle to coordinate with their food to consume, and dark swarm (which is extremely hard to use well) will still be restricted to narrow circumstances. Even so, I expect defilers to be much more active, more nearly what they should be.

So, as usual, the next release should have more improvements than planned.

Parasite works moderately well. On average the queen does not really pay for itself, but it’s a small expense (no research and the queen’s nest is there anyway), and I expect it will pay off in a few games. If the queen is lost, the strategy boss waits 3 game minutes before ordering up a new one, so even if the queen gets irradiated instantly it won’t be a big drain on resources. And every once in a while it can infest a command center.

The BASIL ladder was down for about a week, but now it is running again. The downtime can be seen as flat stretches in the elo curves.

This is an idea I came up with while working on building placement in the live Steamhammer. In that version I made the basic operation “can this building be put here?” faster by cleaning up redundant calculations. In the future I want Steamhammer to do complex building placement optimizations on the fly, requiring many steps, which means it will be useful to speed up each step even more. I haven’t implemented the idea, but it’s simple and seems broadly useful so I want to write it up for everybody.

Checking “can this building go here?” first of all means checking whether all the tiles the building will occupy are buildable and unobstructed. BWAPI can do this in one call. Steamhammer also checks certain adjacent tiles, and sometimes tiles adjacent to a neighboring building, to make sure there is free space and units can move around. The net effect is that certain rectangles of tiles are checked, one tile at a time: Is this one clear? The next one? The next one? There are a few extra checks like “is there pylon power?” but checking open space is the main part.

If you’re going to do a lot of building placements, as I am planning, then you can reduce the check of any one row or column of tiles to a single lookup in one of two simple precomputed data structures: How much room is clear to the right of/below this tile?

The algorithm is trivial. For example, to find out how many tiles are clear to the right of each tile on the map, start with a currentRoom counter set to 0, and scan each row of map cells from right to left. If a cell is open, increment currentRoom and store it; otherwise, reset the counter to 0 and store that. Done.

So if you want to place a 4x3 building with 1 tile space around it, you don’t have to check 6x5 = 30 tiles individually. You can check the 5 rows with 1 lookup each. Furthermore, if you’re going to compare different possible locations to choose the best, the minimum of those 5 values tells you how many tiles you can slide the building horizontally—you verify all those potential building placements with no further work. If you’re comparing many placements, you should easily earn back the investment of computing the extra data structure.

If you only want a fast first check for clear terrain, you can build the lookup table or tables once at the start of the game. If you want to take into account your own buildings and other stuff that you know about, you can build the table fresh when you need it, or you can update it incrementally as buildings come and go. The incremental algorithm is not hard. If you know the general area you want to build in, you can restrict the table to that area—for example, within the bounding box around the creep of a given base.

It’s simple and not entirely obvious, though I won’t be surprised if some bots already use the idea. I thought it would be useful to write up.

I’m starting to worry about the lack of new bots on SSCAIT. The old standbys are going strong, with updates and improvements, but there are no newcomers. With nothing added to the pipeline the pressure falls, that’s physics, and eventually it will run dry.

I don’t know the causes, but I know there are two places to look, outside and inside. How much is due to shifts of interest outside in the big world? What’s hot depends on factors like visibility and prestige, and I don’t feel that I can affect it—maybe you can. How much is due to the inside, shifts in perception of the BWAPI community? Do people feel discouraged from joining? It might be due to perceived difficulty in getting started, or perceived newbie-unfriendliness in some form (elitism, rudeness, etc.), or something else. I may be able to make a small difference on that side.

write a bot!

The game of Starcraft Brood War opens a huge range of strategies for players. The hundreds of bots that have been written to play the game are nowhere near exhausting them. In practice, that means that if somebody writes a bot and doesn’t flat out copy a strategy already used, then the bot will play differently than any other bot—it may be good or bad, but it will be fresh. That makes it a contribution to the community, which is why I want to encourage new bots.

Writing a Starcraft bot is sort of like drawing pictures. You have to learn some basic skills first, or your picture won’t be any use. But the most basic skills you need to draw a recognizable picture are not difficult, and it doesn’t take long to learn to draw a simple cartoon. To extend the metaphor, if the cartoon expresses an interesting idea, then it is an interesting cartoon even if the technical drawing skill behind it is not well developed (the secret of Randall Munroe). A Brood War bot that does something different from all others is an interesting bot.

Coding a bot is also like drawing in that you are free to choose your stopping place. You can draw one cartoon that expresses your idea and be done with it (I have literally done that and I think it was worth it), or you can devote your life to improving your skills and try to become Rembrandt. Or anything in between. Marine Hell is an example of a “first cartoon” bot. Its description says This bot was written from scratch in 5 hours following official tutorial. I would like to keep it “as it is” to show how easy can be to write simple bot which is capable of winning. Marine Hell is not a strong contender, but it wins games and it has been playing continuously on SSCAIT since March 2017. At the other end of the spectrum, I’ve been working on my bot Steamhammer since December 2016 and intend to continue for years, and I think that is worth it too; others started earlier and are still going. Do as little or as much as you want.

The AITT tournament series of bots with severely limited code size are another way to see that a bot does not need to be large and complex to be interesting.

If you decide to go ahead and write a bot, your first decision—before you type a line of code—is whether to start from scratch or to fork a starter bot. Both ways are good; both ways can be fairly easy or as hard as you like; both ways can lead to strong bots. Look around and take your choice.

If you are unsure about interesting play strategy, I offer two hints. A large proportion of bots follow one or the other of these broad strategic patterns: 1. Make tech switches. If you make one unit type and press aggressively with it, your opponent is forced to respond. Then you switch to another unit type, one that puts different pressure on the opponent, and you are sure to win some games. It can be a complex calculation (Steamhammer tries to figure out what tech switch will hurt its opponent), or a sequence of tricks (krasi0P goes cannon contain then dark templar then carriers), or it can be as simple as always making this, then at a fixed time making that instead. 2. Defend soundly, build up during the defensive phase, then when you’re big and strong, head out and go break stuff. Bots as varied as SAIDA, Johan Kayser, XIMP by Tomas Vajda, and ZurZurZur follow this pattern.

I don’t have to offer more detail than that. By the time your bot is able to play a complete game, at the latest, you will have your own ideas. I promise.

In the meantime, I am making slow progress myself. I bought new hardware to replace a laptop that’s 10 years old (seriously!), and I have workflows and stuff to migrate, mostly things that have nothing to do with Starcraft.

The BASIL stats page includes a table of unit types with how many of the type have been created and destroyed on BASIL in the last month. From this we can gain boring insights, such as that buildings are more likely to survive the game than units. But I also see a few interesting points.

Here are the basic units with their chances of dying. The cheaper the unit, the less likely it is to survive. Marines should have a lower chance to live than zealots, because sometimes you make marines only in the early game. To me, it’s not obvious that zerglings should have a lower survival rate than marines. Notice that zerg (48.5%) has a slightly higher overall winning rate than terran (47%). Maybe zerg mines more and burns more units overall.

type	% destroyed
zealot	71%
marine	75%
zergling	80%

What units had the best chance to survive? It seems that most unit types (leaving aside buildings and temporary units like eggs) are more likely to be destroyed than not. The table includes units with less than 40% destruction chance. The champion is the terran siege tank. I think that’s because when terran is able to make a lot of tanks, terran wins! The low death rate for dropships (but not shuttles at 45%) may mean that dropships maneuver more cautiously—reaver drops call for aggressive shuttle movement. It’s striking that, except for the tank, every unit in the table is a flyer. Most have ample hit points; tanks, vessels, carriers, queens, and guardians have long range and can stand off from the hottest part of a battle. Another possibility is that only stronger bots use high-tech units at all. Notably missing are the terran valkyrie and zerg devourer.

type	# made	% destroyed
siege tank	184860	13%
carrier	24013	18%
arbiter	3367	23%
dropship	3168	27%
science vessel	15635	33%
queen	14992	34%
battlecruiser	5133	36%
guardian	4021	37%

Some units you don’t expect to often survive the game, but sometimes they do anyway. My thoughts: If the scarab count includes scarabs made but unfired and remaining in the reaver’s inventory, the number seems too low; if it includes only scarabs in flight at the end of the game, it seems too high. Maybe it doesn’t count a scarab as destroyed if it was inside a destroyed reaver? That’s a lot of expensive unused nukes! Is the high number of active scans at the end of the game because some bot or bots scan for unseen bases when all targets are cleared? It’s too bad that only scanner sweep is included in the table. Other spells like psionic storm [an error; see comments], disruption web, and dark swarm are also represented as units; the difference is probably that scanner sweep is owned by the player, while other spell units are neutral.

type	# made	% surviving
scarab	149590	0.23%
nuclear missile	449	18.26%
scanner sweep	148478	1.80%
broodling	14184	1.03%

Earlier, I pointed out 2 rare game-over bugs in Steamhammer 2.3. It turns out that there are 2 other serious bugs in this version, which are not rare; they are causing a good proportion of the bot’s losses.

One is a bug in turning gas collection on and off. The bug can turn off gas collection even when the bot needs gas to continue production, causing a production freeze that can last for the rest of the game (not likely to be long with no production). It may have been introduced when I refactored the code for gas decisions. The other is a bug that cancels vital hatcheries (and perhaps other buildings) for no apparent reason. I suspect an error in one of the emergency “uh oh, no drones!” or “panic! I need those resources back NOW!” tests. There are other possibilities.

Critical bugs go straight to the top of my list.

The bugs also point out a weakness in Steamhammer’s design: Decentralized decision making. Decision rules that take direct action are scattered through the code. Of course a bug in any rule can cause bad behavior; that’s inevitable. The weak point of the design is that the separate rules, sometimes far away from each other in the code, have to cooperate so they don’t override each other’s decisions. The gas collection bug is clearly a coordination bug; one rule says “I need gas for the next production item” and some other rule is incorrectly overriding the decision, “nah, I wanna turn off gas.”

Compare the unit mix decision, which is made using a more indirect method: Rules collect evidence, then in a second stage the evidence is weighed and the decision is made. The evidence is explicit, so bugs are easier to trace, and evidence-collecting rules do not need to cooperate with each other, they only need to weight their evidence consistently. Machine learning systems conventionally follow this collect evidence, then decide paradigm as a matter of course.

One of the items on my list is good lurker targeting: Lurkers should aim for the target that will bring about the most total damage, with the lurker’s line of splash damage. In the current release, Steamhammer’s lurkers use the same targeting as most units, choosing the closest available target when other things are equal. It’s not so smart, but improving lurker targeting has been a low priority; the full analysis is more effort than it’s worth for the time being. Lately I hit on a simple idea to improve targeting without doing any deeper analysis. It’s a rule of thumb that I notice when I play myself, but for some reason I never thought of implementing it before.

Suppose a lurker is to choose one of 2 targets, and it knows how far away each is but nothing else. It has to choose blindly. Which target is the better choice? Does one of the targets offer a better chance of blindly landing splash damage on the other, with the lurker spines reaching out in a line? It might be counterintuitive, but geometry gives an answer: The more distant target is better. If you aim for the near target, the far target subtends a smaller angle from the point of view of the lurker. If you aim for the far target, the near target subtends a larger angle, so you are more likely to hit it by chance. If you don’t believe me, draw some circles on paper, or start up the game and try it!

The same reasoning works if there are 3 targets; pick the farthest. If targets are dense, it doesn’t matter where you shoot, and if targets are sparse and you do no further analysis, then aiming for the farthest is best. It’s dead simple, so I implemented it in Steamhammer, choosing the highest priority target at the greatest distance rather than the smallest distance. It is a small but real improvement, and it was hardly any effort. There is a disadvantage, which is that the more distant unit may be better able to sidestep the lurker spines, since it has more time to react. But not many bots dodge lurker spines.

Of course it’s much better to do the full analysis: For each target, calculate which enemies the lurker will hit and what the hit is worth. Ideally, predict how the enemy units will move, taking into account their likely decisions, and correlate their paths with the extending line the lurker spines will follow. And optimize the fire of all lurkers at a location as a group, so that they cooperate to kill more efficiently (2 lurker shots kill a marine, so these 2 lurkers should aim here and here to overlap their splash damage). It is an elaborate calculation, and I don’t think it’s worth the effort for now; better to improve Steamhammer’s other decisions first.

Today I revisited the BASIL stats page with its collected numbers. The random bots got me thinking.

Over the stats period, the random bots collectively scored 56.8%, making random the most successful choice of race. On BASIL, the server chooses the random race before the game starts so that the opponent knows it, so theoretically there should be no game play advantage to being random. There could still be an advantage in confusing the opponent by playing a wider range of strategies, each less often—or that could be a disadvantage, depending on how the learning of each side works. In practice, does playing random give an edge, or did stronger bots choose to play random?

It seems impossible to answer the question by comparing strength numbers between the randoms and the rest. Do the random bots have higher elo? Well, they scored better! The result says nothing about the direction of causation, if any.

Another line to answer the question is, do the random bots score better or worse than their component races playing independently? We can answer by averaging the elo ratings, because elo is designed so that strength differences can be added and subtracted. I compared PurpleDestiny, tscmoo, and ChimeraBot.

PurpleDestiny has elo 2273 at the moment, and I get 2333 for the mean elo of its 3 components. There is no evidence of an advantage for playing random while purple.

Tscmoo random is at 2348, while its components average to 2146. It may be that playing random is effective for cows (“moo!”). But it could also be that the apparent components aren’t actually part of tscmoo. They were updated at different times, and I expect that they are configured differently too, with different sets of strategies allowed. If so, the comparison may not mean anything.

ChimeraBot (made of Iron, McRave, and ZZZKBot by Chris Coxe) is at 2342, while its components average to 2330. But Iron and McRave have both been updated since ChimeraBot was assembled, and I believe the updates were improvements. If so, the true mean of the components should be lower, but in any case it is probably different. There is at best weak evidence of an advantage for playing random while chimeric.

The bottom line is that the result is inconclusive. I haven’t found enough information on BASIL to judge whether playing random is an advantage, or a disadvantage, or a wash.

By the way, the stats page says there are 18 random bots, but I count 11 on the ranking page (2 disabled). Does the ranking page not show all bots?

When I announced that Steamhammer 3.0 would be next, I forgot a step: I want to upgrade to BWAPI 4.4.o. I actually want to make a 2.3.1 release first with the upgrade. I think I can probably do it this month, along with other additions, even though I may not start the work until next week.

Just now I don’t feel like any serious work, so I started to implement queens. Queens are not essential; you can be a great zerg and never spawn one. Often enough, queens are not useful at all. But queens are fun, and I feel like doing fun stuff.

I’m starting with parasite, and I’m thinking the order should be parasite, then infest command center (you get both of these with no research), then ensnare, then broodling. I don’t expect to do them all at first, but I will eventually.

My initial plan is to always make 1 queen versus terran, if the situation permits, in hopes of infesting a command center. And to make 1 queen against protoss if Steamhammer spots juicy parasite bait, like a carrier. In ZvZ a queen is too expensive, unless maybe you can broodling defilers and ultralisks if the game goes that late.

In the longer run, I want Steamhammer to learn for itself which tactics work, and which work against each individual opponent. It should be possible to measure whether parasite brought in information, whether ensnare harmed the opponent, and so on, and estimate whether the queen and the research to use it paid dividends. Decisions based on data are better decisions.

parasite

Parasite is rare in pro games, though it has been used. If you have queens at all there is usually a better use for their energy. But bots are not as knowledgeable as pro players. Could parasite be useful?

I am going to try parasiting flying critters, on maps that have them, to see if it’s useful. And I’ll try parasiting expensive enemy units: Science vessels, battlecruisers, carriers, arbiters. I expect that a few strong terrans will react well, and the bulk of bots will not notice the parasite and will give Steamhammer free information. But we’ll see!

By the way, parasiting a science vessel is not too dangerous if done carefully. Irradiate has a range of 9 tiles, while a queen has vision range 10 tiles, so a queen that approaches cautiously has good chances to launch a parasite without getting irradiated. Parasite has range of 12 tiles (the same as the range of a sieged tank), so if other units spot for the queen then parasite can be always safe.

How to react? If you spot a parasited neutral unit (and it’s not your parasite), kill it. If you’re terran and one of your units gets parasited, you can research restore for medics and remove the parasite. That will take time, though (unless you’re Krasi0, which researches restore pre-emptively and cures spell effects in moments). Zerg has 2 ways to remove parasite (if it ever happens, which is unlikely in ZvZ), both with limited use: 1. If a drone is parasited, you can turn it into a building. 2. If you have a queen of your own, you can place your own parasite on your unit, which overrides the enemy parasite. Protoss doesn’t have any options, and can only be rid of the parasite by killing its own unit.

You can also move a parasited unit away from your army, or use it to show the enemy what you want the enemy to see. The opposite approach is to put it in the front of your forces, so it is the first to be killed.

infest command center

What’s to say? If you bought the queen already and you can infest a command center, you should! For now, I won’t bother with infested terrans, or with details like stopping the attack when the command center falls below half HP so that it is not destroyed before the queen can infest it. Leaving the infested command center where it is may slow the enemy from retaking the base.

ensnare

Ensnare is useful against fast units in groups. I’ll try it first against marines, wraiths, and corsairs. Vultures are hard to tag, but I might experiment. It’s also useful to reveal cloaked units, so it may also be worth researching against dark templar, arbiters, and maybe ghosts.

An ensnared unit moves much more slowly (usually at half speed), and most unit types also shoot a little more slowly. It will be difficult to retreat, or to complete any other tactical maneuver. A logical reaction is to hold your ground until the green goo wears off; you lost a lot of mobility and only a little firepower, so rely on firepower.

broodling

Broodling is expensive to cast; it costs 150 energy, which takes a long time to build up. It’s also the only queen ability that can justify making more than a few queens. It’s good against expensive ground units like tanks and high templar—provided you keep the queens alive so they can do it again (the 100+100 cost of a queen plus the cost of the time to build energy is worth more than one 150+100 tank). Broodling is most valuable in the very late game, when the map is mined out; at that point you want to favor spellcasters no matter your race, because you won’t have the resources to replace units.

There are 2 counters to broodling: 1. Kill the queens. 2. Make units that cannot be broodlinged (wraiths, reavers, archons), or are not worth the cost of broodling (marines).

I’m pleased with how the new Steamhammer 2.3 is doing. Not only is it scoring wins where it could not before, its play looks sharper and cleaner. It’s mostly due to bug fixes. It beats XIMP by Tomas Vajda again (command jam bug fixed in 2.2), and it is back to its former success with heavy early zergling pressure (unit movement fixes in 2.2 and 2.3 plus zergling value fix in 2.3). I added many new openings in 2.2, and the unsound “dawn hydra rush” (those hydras arrive in the morning gray) is scoring well against SAIDA due to SAIDA’s broken reaction. The same opening worked against Iron when I wrote it, but one of Iron’s updates added a reaction and Iron is now safe. The value of the other new openings, positive or negative, will take time to show.

Randomhammer’s better building placement make bases look prettier. Having fewer buildings bursting into the center of the map can only help play, though I think that most opponents which are able to exploit the vulnerable buildings were going to win anyway. The tank improvements make terran factory play look almost... non-ridiculous. The tank play was awesomely bad before; now it gives the impression of trying to do something sensible, though it doesn’t always succeed. And, of course, drop openings work again; that may not be reflected in performance right away, because Randomhammer remembers the results of its previous version, which learned to avoid the broken drops against some opponents. Still, I’ve seen a few crushing drop games.

BASIL is better than SSCAIT for strength measurements. Here is Steamhammer’s elo graph from BASIL:

Version 2.3 was uploaded 2 April, and includes the improvements in 2.2 and 2.3, since the previous running version was 2.1.4. The graph shows a strong rise on 3 April, 75 elo over its base, with a peak nearly 50 elo higher than the next highest peak in the graph. It’s pretty good evidence that Steamhammer is improved; the elo increase is likely 50 or more.

The same for Randomhammer:

This is not as clear. The peak begins to rise on 4 April; I think that is mostly because of game scheduling. It is about as high as previous peaks on the graph, and it is not convincing that it is statistically meaningful rather than a random winning streak. I’d say there is weak evidence for a strength increase. I will be disappointed if Randomhammer doesn’t end up showing a detectable elo rise.

I did a round of work on overlord safety last fall, and improved it enough that it was no longer one of the top weaknesses. Now other aspects of play have improved enough that overlord safety is again a critical weakness. There are also 2 game-over bugs that guarantee a loss. One causes drones to hang out with the minerals instead of mining; it’s rare. The other causes general confused behavior, and it is extremely rare. Rare bugs with no identifiable trigger condition are tough, but they have to go.

Nathan Roth aka Antiga has announced AIST S3 (passing it on in this comment). The tournament will be held next year, with the same end-of-February submission deadline as the S2 edition. Plenty of time to prepare!

Don’t miss the key changes at the top: Source will be published, and BWAPI 4.4.0 is required (or later, if we have a later BWAPI by then).

Next: Experience with Steamhammer 2.3 so far.