Starcraft AI blog

Yesterday an epic, today a short sharp shock. The game McRave vs. MadMix is a brazen cheese. Why shouldn’t I build my first pylon next to your nexus? Maybe because it couldn’t possibly succeed?

MadMix placed its first pylon in McRave’s mineral line, at the corner of the nexus. I can suggest an improvement: Place the pylon slightly to the left so it blocks access to the indented mineral patch. That is called a manner pylon because it is ever so polite. A probe sent to mine there will run behind the mineral line, slowing down the opponent’s mining. If you’re going to push a pylon into the opponent’s face, you might as well make it a manner pylon, as in the famous game Bisu-Pokju from 2007.

A manner pylon is commonly worth it, given that you have an early probe in the opponent’s base, especially if (as in Bisu-Pokju) it blocks 2 mineral patches: In between trapped workers that have to escape (which I doubt bots have the knowledge to do), workers devoted to attacking the pylon, and workers sent behind the mineral line, it can slow down the opponent’s mining more than enough to make up for its cost. It occurs to me that a bot with mineral locking could avoid some of the cost provided it has the special case knowledge to avoid locking workers to the blocked mineral patch or patches. I doubt that any bot has that knowledge yet, since I’ve never seen a bot place a manner pylon! I would be interested to see how a manner pylon interacts with LetaBot’s path smoothing. If the smoothing is not smart enough, some SCVs might be unable to mine at all—I am imagining SCVs bumping against the pylon trying to follow the shortest path.

McRave assigned 2 probes to tear down the offending pylon. MadMix calmly continued the cheesemaking process, building a gateway, then replacing the destroyed pylon with 2 fresh pylons, then laying down a second gateway, all while sending fresh probes to make sure one was always on hand. McRave seemed unimpressed and carried on with its 1 gateway build.

McRave ought to have been impressed. McRave’s first zealot was out earlier, and it could have held easily with good play. But McRave didn’t seem to know how to react; as it was attacking proxy buildings and mining gas and starting its cyber core, MadMix was killing probes and pulling ahead. The proxy won. Correct play when you get proxied like this is to delay your tech until you have the situation in hand. Your opponent set itself back to perform the proxy, and you can always stay ahead in units.

Don’t blame McRave for missing knowledge. All the top bots, Iron and Tscmoo included, have knowledge gaps wide enough to drive a government cheese truck through. It was only shortly before the tournament that I added smarts to Steamhammer to react on the fly to this kind of in-base cheese (Steamhammer makes a spawning pool if it has 9 or more drones, and will cancel gas or a second hatchery if that helps it get the pool up faster). And Steamhammer doesn’t understand how to react to other proxies like Juno’s (by Yuanheng Zhu) cannon contain (it still relies on a hand-coded counter for that). Bots need a lot of knowledge and it takes a long time to acquire.

A zerg creep colony has a base health of 400 hp. A zerg sunken colony has 300 hp. The way it works is, just when a creep colony finishes morphing into a sunken, it suddenly loses 100 hp. If it falls below 0 it doesn’t die, though; there is a floor of 1, and zerg healing has instant effect so the sunken colony completes with 2 hp (I think it takes 1 frame for the second hit point to be granted). When you start morphing a sunken, the UnitType immediately changes from creep colony to sunken, but the hit points are not removed until the morph completes.

Good players exploit this. I don’t know of any bot that takes advantage. Steamhammer certainly doesn’t. It could be hard to notice in a bot’s play, though. Does anybody know of one?

If you’re attacking morphing sunkens, then you should avoid doing unnecessary damage. If a morphing sunken will heal to no more than 100 hit points before it completes, and your units will still be in range then, and there is something else in the area worth attacking, then you should probably switch to attacking the something else. You will normally be able to kill the brand new sunken with one hit before it can get a shot off, saving the time it would have taken to inflict nearly 100 hp of damage. Depending on the situation, you may also be able to stop early if for some reason you’re pre-emptively hitting creep colonies before they morph. (I think most bots don’t waste their time on that, though.)

If you’re considering morphing a sunken, you may want to hold off if the creep colony has less than 100 hp left, or any low number that would leave the sunken helplessly weak. That may be best if an enemy attack is near; don’t waste 50 minerals on a defense building that will die instantly, get a pair of zerglings instead (if you have a larva and supply). On the other hand, if you don’t expect enemy action for a long time, you may want to morph the sunken immediately. By losing less than 100 hp in the morph, you are effectively speeding up zerg healing compared to the case of waiting to morph the sunken later.

It’s a strange behavior, and the considerations it induces are strangely complicated. You can only make the best choices if you have skill in seeing the unclear future. Taking all considerations into account is too hard, but I think the top bots have become strong enough that they could gain from taking into account the basic considerations.

Spore colonies have 400 hp and don’t show the same strange behavior.

How many workers does it take to mine a gas geyser at full efficiency? All bots that I’ve seen, including Steamhammer, assume that the answer is 3. In reality, it depends on the relative positions of the geyser and the resource depot (the command center, nexus, or hatchery that you return resources to). In some base layouts, you only get full gas income with 4 workers. On a professional map, like all the SSCAIT maps, the main bases are designed to mine gas at full efficiency with 3 workers. But expansions may be different. On original Blizzard maps distributed with the game, anything goes.

Also, exceptional situations can come up. It’s fairly common for bots to manner their own gas (meaning partially block it so that workers go around the obstacle). In that case you need more workers to maintain income, unless you’re smart enough to remove the obstacle. If a spider mine is blocking a base position, Krasi0 may offset the command center instead of clearing the mine. There are other reasons to offset a resource depot; maybe you’re trying to hide a base that the enemy won’t scout. If the primary hatchery at a base is destroyed but zerg has another hatchery at the same base, mining can continue. Or you might just be long-distance mining the gas.

How is a bot to judge the number of workers? The details are complicated.

Precompute it. One way is to make a table of relative positions. Go through all the maps and find the relative positions of the gas geysers and the resource depot for each base. On pro maps, I think the total set of relative positions is not large. Or enumerate all the relative positions up to some short distance. For each possible relative position, measure the number of workers needed to fully mine the gas. At runtime, the bot can look up the number of workers to assign in the table. Maybe you can find a rule, or a rule and a small set of exceptions, to make it more compact. It should be simple and fast at runtime, but it’s rigid and it doesn’t account for exceptional situations.

Figure it out on the fly. Assign 3 workers at first. Once they’ve settled into the task, check the geyser to see whether it is idle. I haven’t looked into the details, but the check is something like: There is no worker inside and it’s not in a latency period with a worker entering or leaving. If the geyser has idle time, or has idle time above some limit, assign another worker (at least if you need the gas income). This doesn’t have the advantage of instantly doing the right thing in known cases, but it does adapt to exceptional situations.

Human players do both, of course: They know what common positions need extra workers, and they notice unusual situations that also call for more workers. For Steamhammer, I think I will eventually add the on-the-fly method. It’s not high on my list, though.

I don’t know of any bots that are smart about the number of workers needed to mine gas, but maybe there are some. AILien, for example, will use fewer workers to mine if it is short of workers, but I’ve never known it to add above 3. Can anybody enlighten me?

I notice a lot of bot authors want to control each unit independently for micro decisions, to make it an agent with a mind of its own. There are good reasons to write a bot that way.

• It’s simple. Fewer bugs and less implementation effort are strong reasons.
• Being simple, it can run fast.
• Frame-accurate control depends on each unit’s exact state at each frame. It seems much easier to handle unit by unit.
• Units can sidestep the stupidest behaviors, like moving too much without shooting. Each unit can act efficiently under its local circumstances.
• Cooperation: If a squad still gets orders from above, then the squad still acts together for higher-level goals.
• Cooperation: Units can still work together on low-level goals like focus fire by simple means like preferring targets that are already hurt. Cooperation occurs as an emergent behavior.
• Cooperation: At a cost in simplicity and speed, units can look at each other’s targeting and movement plans or expectations, to get more effective focus fire, to reduce overkill, to kite better, and so on.
• And hey, you can call it an agent architecture, which sounds great.

It doesn’t make sense to me. My micro plans in Steamhammer call for reducing the independence of units, calculating more things centrally at the squad level and leaving less for individual units to decide. For focus fire and avoiding overkill, I want a data structure in the squad to keep track of assignments of shooters to targets. For kiting and fleeing, I want a near-term prediction of when each of my units is likely to die, based on the rate it is taking damage or on the approach of enemy melee units. A planning algorithm can look at all the data to decide, “You, shoot at that” and “You, pull back.” It’s not as simple, but I expect it will have a higher ceiling in practice, because it is easy to change out the planner. And I think that, done right, it can execute fast. Units act frame to frame, but the squad-level planner needs to execute only about once per cooldown period, and it can be out of synchrony with unit actions.

That’s general micro, but there are also important micro skills that bots don’t have and would benefit from. I’ve never seen a bot do any of these effectively.

Zergling surrounds. Watch a bot attack zealots with zerglings: Each zergling heads for where the zealot is now, and the lings pile up. With fast zerglings and slow zealots, if the zealots flee then the zerglings end up trailing behind and getting a hit in now and then, and mostly waste their time getting in each other’s way. Arrakhammer does modestly better by predicting the zealot’s future location, react to the future style. Then watch a human do it: The zerglings move into or around the formation of zealots, then attack all at once. If the zealots are fleeing, they get surrounded and have to find or make a way out before they can escape. Any intermediate zerg player knows this micro.

I’m seriously considering implementing zergling surrounds in Steamhammer with human-like control, at least as a first cut. It’s 2 commands total for small fights with up to one control group of zerglings: Command lings to move as a group, command lings to attack as a group. Choosing the destination for the move command is the tricky part.

Dragoon backstepping. Like most bots with a combat simulator, Steamhammer mostly attacks or retreats, and doesn’t know anything in between. But watch what happens in a human game when a strong terran early timing attack moves out and faces forward dragoons: The dragoons will lose if they stand and fight, they must step back... and back.... But if vultures pull too far in front of the tanks, or if any sloppy movement isolates a few terran units, the dragoons may suddenly stop and fire. The terran force must move slowly or be whittled down—usually some of both. Protoss gains time for more dragoons to take the field.

Related situations are common. FAP doesn’t understand vultures versus zealots, so if there are too many zealots, Steamhammer’s vultures will retreat in terror instead of pulling hit-and-run attacks. If an opportunity comes up, take it even if you weren’t intending to fight. I think the decision is best made at the squad level, so that the squad behavior stays coherent. I often see Tscmoo lose squad coherence and disintegrate; I want to avoid that.

Getting out of each other’s way. A large group of ranged units arrives to fight—hydralisks, say. The closest hydras get into range and stop to fire, and the ones behind maneuver around the sides to get into range (that is inefficient already). The ones behind those... push and shove, but can’t get into range and achieve nothing. Any human above beginner level will move the front hydras forward so that all can get into range, but bots don’t.

Climbing a ramp is similar. Bots see targets at the top of the ramp and stop to hit them, blocking the way so that the rest of the force is stuck below. Steamhammer is clever enough not to siege tanks on the ramp, but sieges them above the ramp and blocks the path anyway. Humans keep the front units moving until the whole force can get up. The difference in DPS is huge.

These decisions can be made by individual units, swarm intelligence style, but I find it hard to design good emergent behaviors. I think it is better to make the decisions at the squad level. It should be more efficient and more effective.

I thought this picture was funny. In a game yesterday against Iron, McRave fast expanded and walled off one of the bridges to its natural, but left the other bridge open. Vultures cannot pass the wall, but they happily took the other bridge and Iron won easily.

McRave seemed to mess up its build, getting dragoons too late. (The underlying mistake may have been taking gas at the natural instead of the main.) But the idea is sound. McRave is narrowing the entrance to its natural, making it easier to defend against vultures. A small number of dragoons can block a narrow entrance, either early in the game when there are only a few dragoons on the map, or later when the main army is away and the only dragoons around are those rallied from the gateways.

Its next game against Iron was on Roadrunner. McRave won using the same idea of narrowing the entrance.

McRave’s dragoons beat Iron, so they played well by bot standards. But I see room for improvement. Vultures can pass either left or right of the upper gateway. I think the first 2 dragoons should plug the gaps so that vultures are physically blocked. Iron will lay mines to force its way in, and then the dragoons can retreat to the defense line McRave actually held, the gap between the lower gateway and the nexus. The farther away the vultures and their mines are kept from the probes, the better.

Back in an early Steamhammer release, I tested stealing gas, concluded that it worked, and called it good. Since then I haven’t paid much attention.

Now I’m working through systematically to make sure that stealing gas always works when it should, and that it interacts correctly with scouting (which has grown more complicated since then). While I was looking away, the gas steal bitrotted as its surroundings changed and it did not keep up. For example, in testing with terran today I fixed a bug where the scout arrived at the enemy geyser, queued up a refinery on it... and then BuildingManager assigned a different worker to do the job, sending an SCV from the main. I even found and fixed a potential crashing bug, though it could only happen on very nonstandard maps.

Next: Steamhammer vs. PurpleWave games.

A quick note: I finally got devourers working sort of OK in the development Steamhammer. They are no longer horrible and useless as in the live version. Of course this means that I instantly get new items on my to-do list, like “teach other units to target enemies that carry acid spores” and “teach FAP about the effects of acid spores.” One step at a time!

As a side effect, corsairs and valkyries are also better. The corsair-dark templar opening is improved to the point that it is... not good, but within shouting distance of acceptable. The work was a combination of bug fixes, improved tactics, and adding a new MicroAirToAir unit controller for the air-to-air splash units.

I have improved Steamhammer’s early game scouting and added midgame scouting. It’s far short of human scouting skill, but much improved. The first overlord and the drone scout cooperate to locate the enemy base as quickly as possible, and the overlord moves there to watch as long as it can. I also taught it to notice the enemy’s overlord and try to infer the enemy’s base location (ZZZKBot is the only other bot that I know has that skill). The effect is that Steamhammer finds the enemy sooner and collects more information. The midgame scouting ensures that enemy expansions are found, and in my testing often destroyed quickly.

I already find it hard to watch the release Steamhammer play on SSCAIT, since the new one is so much less clumsy at finding things. I think that Steamhammer 1.4 will be stronger than the current Steamhammer even with opponent modeling turned off, because of the improved scouting, slightly more flexible tactics to take advantage of the improved scouting, and a couple of key bug fixes.

It still doesn’t overlord scout versus terran, though. It has no concept that marines are dangerous or that cliffs are useful.

Overlord scouting, by the way, is a deep topic. Pros often send their first overlord straight to the closest possible enemy natural base. But they sometimes move the overlord on a complex path, trying to catch proxies, or avoid the enemy scout, or spot activity without being seen, or just to stay flexible so the overlord can move to its choice of locations depending on the situation. An overlord that always follows the most efficient scouting path is predictable, and the enemy may be able to save time by scouting for your overlord instead of directly for your base.

Working on scouting reminded me: There is a trick that terran can play to mightily confuse the opponent’s early scout. At the start of the game, make SCVs as usual, then when it nears time for the opponent’s scout to approach, lift off the command center and move it out of sight. Of course you have to build any supply depots or other buildings out of sight too, or away from your base (you could proxy 8 rax, or build your first depot in an empty main base). It can only conceivably be a good idea if there is another base close by to land the command center at, so the trick should be saved for maps like Electric Circuit which have an inside “backdoor” base near the main.

The opponent will scout every main base and see you at none of them.

This trick has been used in one pro game to my knowledge, Boxer versus Yellow from 2003, where the CC move was meant to keep the proxy barracks unknown; a base without barracks would have given it away. If it were a good trick it would have been used since then. It’s objectively bad, and human players who see that all bases are empty are able to figure out what happened. But in bot play, you might fool your opponent into doing something nonsensical or even cause it to crash.

When UAlbertaBot’s scout is looking for the enemy base and finds an enemy building in a starting base region, is assumes that that marks the location of the enemy base. Steamhammer inherited the heuristic and still uses it. So a low-cost way to fool these bots is to build a supply depot or pylon next to the ramp of an empty main base before it is scouted. Zerg could build an extractor at the empty base, if the gas is toward the ramp. 50% of the time, the scouting worker will find the decoy building first and will not scout other bases. Nobody has tried this trick yet, as far as I have seen.

One of the themes of today’s SSCAIT broadcast by Nepeta is that too much static defense is bad for you. He repeatedly showed in ZvZ that the side which made too many sunkens tended to fall behind. Static defense can’t go attack; it costs resources and it offers initiative to the opponent. In a well-played game, static defense has to pay for itself with a countervailing advantage: You have to use the temporary safety it brings to get ahead in economy, as in a protoss forge-expand opening or as Killerbot by Marian Devecka tries to do, or to get ahead in tech, as when in ZvZ you make a sunken to tide yourself over until your spire finishes.

But there is a reason that so many bots play turtle strategies. Turtling is strong against bots which do not adapt, which is most of them. For Steamhammer, I added 1 base and 2 base turtle openings which crush Wuli, an opponent that Steamhammer otherwise struggles against. Wuli does not adapt.

Steamhammer does adapt to static defense and pulls ahead of opponents that turtle too much. When the opponent makes static defense, you have 3 broad strategic choices. They are the same 3 choices you always have, but the opponent has offered you initiative so any of them might give you an advantage. 1. You can pull ahead in army and bust the defenses. Example: Hydralisk bust versus protoss forge expand. It can win outright, but it is risky. 2. Use the opponent’s passivity to pull ahead in tech. If you made a sunken, other things being equal I can safely skip a few lings and get a faster spire. 3. Or similarly, pull ahead in economy. If you made sunkens, I can make drones.

Steamhammer primarily adapts by making drones. A protoss or terran bot might expand sooner instead, so it can build workers faster. But whatever the choice, you want to adapt so that you don’t end up crushed like Wuli.

The game Steamhammer vs KillAll (correcting the unfortunate typo in the bot’s name) is an example. KillAll opened 9 pool with extractor trick to get 10 drones, and Steamhammer unluckily chose 5 pool. It is a build order win for KillAll—if both sides play well, the 9 pool wins with little risk.

But instead of making a second hatchery to win with mass lings, or getting quick gas to win with mutalisks, KillAll turtled. It threw away its advantage.

You may want 1 sunken, because the 5 pooler starts making lings sooner and can be a little ahead. 5 sunkens are 4 too many and put KillAll behind despite its stronger opening. They are not well placed; they don’t protect either the approaches or the mineral line.

If I had been playing, I would have made a moderate number of drones, teched fast, expanded once for a second gas to guarantee that I would stay ahead, and aimed to win with mutalisks. Steamhammer made many drones and teched slowly (fast enough not to fall behind), spending the extra income on zerglings. It went up to 5 hatcheries to produce a biblical flood of zerglings. The picture shows 3 of the 5 hatcheries; the other 2 are in the natural. Steamhammer is slightly ahead in economy and tech and way ahead in army and production capacity. Steamhammer can only lose if it blunders.

The zerglings were so many that they cracked the turtle shell and overran KillAll. GG. KillAll lost drones right off because the sunkens were misplaced, but it took only a fraction of the zerglings to finish off the sunkens. Steamhammer had a completed spire but did not need any mutalisks (see how many purple zerglings are already en route).

Steamhammer’s reaction to static defense is effective. You can beat it with a turtle strategy, but only by exploiting weaknesses. The reaction to static defense is not a weakness.

In a comment to next up for Steamhammer, MicroDK speculated (correctly) about the purpose of getting an extra pair of zerglings using the extractor trick. Liquipedia has an entry on the extractor trick but does not mention all of its uses. Steamhammer’s upcoming “go extractor trick drone” and “go extractor trick zergling” only scratch the surface.

An extra drone. The most common use of the extractor trick is to get an extra drone early, going to 10 drones while your overlord and hatchery provide only 9 supply. When you are at 9 supply, as your minerals approach 100, start an extractor. Using up the drone takes your supply down to 8, so you can start another drone and return to 9 supply. Then cancel the extractor to get the drone back and you have 10 supply in units. You can do it any time you are supply blocked, but it usually only pays off at 9 supply when your build order is such that otherwise the extra drone would wait a long time.

Extra zerglings. The second most common use of the extractor trick is to get an extra pair of zerglings when rushing with a 4 pool or 5 pool. When you reach 9 supply, instead of starting an overlord right away, do the extractor trick and spawn zerglings. They’ll be earlier than if you waited until after the overlord, which puts more pressure on the opponent. 4 pool rushbot ZZZKBot never builds a second overlord, but keeps its supply down by constantly attacking and uses the extractor trick whenever it can to get more zerglings.

Exceed max supply. Protoss mind control famously allows protoss to exceed the 200 supply limit. Zerg can also exceed the 200 supply limit with the extractor trick. It’s not practical and I’ve never seen it happen, but I can imagine the situation: You’re at 197 and you want just one more ultralisk (4 supply) before your attack....

The double extractor trick. If you have 2 drones and 2 geysers, you can do a double extractor trick: Make 2 extractors and go over your supply limit by 2. It’s rare, but I have seen it in a pro game. Or if you have 3 geysers, etc., though I’ve never seen that and doubt it would be useful.

Field repairs. Another side effect of starting and canceling a zerg building is that an injured drone is restored to full health. It’s still called an extractor trick even though the purpose is different. If your scout drone is harassing the enemy base and gets hurt, it can use the geyser in the enemy main or natural to bring its hit points back and harass some more. It’s common in pro games, and I intend to eventually implement it in Steamhammer. Or if you’re being rushed, you may be able to rescue a drone that is in danger of dying.

Other buildings. Nothing says that you have to use an extractor for the trick. Any zerg building will do. An extractor is the cheapest, 50 minerals, and can be built away from the zerg base wherever there is a geyser. If you have creep available but no geyser (maybe you’ve already taken your gas), you could build a creep colony instead, 75 minerals. If all you have is open ground, you could build and cancel a hatchery at 300 minerals—though it’s hard to imagine a situation where that would pay off.

It’s kind of depressing how limited and stereotyped bots are in using flexible tricks like this. Someday we’ll do better!

PurpleTickles is a new bot in the Purple family. It plays a 4 probe rush, mining only with the 1 probe it makes with its initial 50 minerals. It never sets more probes mining, either, so the 4 probe rush hits hard but builds slowly.

On a 2 player map it’s a dangerous rush that gives trouble to strong defenders like Krasi0. The 4 probes arrive in a group and stick together to fight in coordination, so the defender needs skill to hold. The style is quite different from Stone’s SCVs, which act independently most of the time and gang up only when they spot an opportunity.

I haven’t seen a game on a 3 player map. On a 4 player map, the rush is naturally much weaker. PurpleTickles scouts with 2 probes and leaves 2 in the center to join in faster when the enemy base is located. Consider the 4 player scouting options for a 4 probe rush; there are 3 bases to scout:

1. Scout with 2 probes and leave 2 at home mining until the enemy is located. The worst case is when the enemy is at the unscouted base. That happens 1/3 of the time and has 4 probes arriving more or less simultaneously at the enemy. The extra minerals make the followup stronger.
2. Scout with 3 probes and leave 1 at home mining. This always gets 1 probe to the enemy base as soon as possible, and the others arrive more or less simultaneously. Compared to option 1 it hits a little harder 1/3 of the time in exchange for a slightly weaker followup.
3. Scout with 4 probes, sending 2 to one base. Compared to option 2, it hits harder 1/3 of the time when the double probes reach the enemy first, and the followup is a little weaker again.
4. Scout with 2 probes and leave 2 in the center, the PurpleTickles option. The center probes can join the fight sooner than a probe at a base, whether it is the home base or an empty base. So there’s a 2/3 chance that the enemy is hit by 1 probe, then 2 more after, then another; and a 1/3 chance that the enemy is hit a little later by 2 probes, then 2 more after.
5. Scout with 3 probes and leave 1 in the center. The enemy is hit by 1 probe, then 1 after, then the final 2 probes.

Intermediate plans are possible, with probes mining part of the time and staged in different locations depending on the map distances, but these 5 seem to be the main options. I don’t see much difference between them, but the PurpleTickles option seems plausible if you believe that hitting as hard and early as you can is best, and that the followup is less important.

I noticed that the rushing probes choose their attack goals along a straight line from the base entrance. They are more successful when they arrive at one end of the mineral line and attack from one end to the other, when they face few enemy workers at a time. They are less successful when the minerals lie at right angles to the line from the base entrance, so that the probes aim for the center of the mineral line and meet many enemy workers at once. An injection of smarts might improve that.

PurpleTickles is moderately successful overall, but it does have wins versus Iron (Iron apparently suffered a bug and never built a barracks) and versus Krasi0. Notice Krasi0’s trick of building its depot and barracks in an out-of-the-way location so that the attacking probes never bother them. It seems like a clever idea versus a probe rush.

Yuanheng Zhu coincidentally uploaded shortly after with nearly the same strategy, though the code is unrelated. On a 4 player map, it scouts with option 3 above. It also crashes when its probes arrive at their scout locations, so we haven’t seen how well it plays yet.

Update: Yuanheng Zhu succeeded in playing one game versus Sungguk Cha. Maybe it works on 2 player maps? The strategy turns out to be quite different from other worker rushes: 1. The 4 rush probes initially attack mostly buildings, not workers, presumably to stay safe for the followup. 2. The bot does not send more probes to attack, but sets new probes mining. 3. It builds a pylon and forge in its main, then adds a pylon and cannons in the enemy base, switching into a cannon rush. Most cool.

Other good stuff to build in or near the enemy base are a shield battery and gateways. I’m sure bots will do that too one of these days.

Arrakhammer’s description changed recently to say that it supports infested terrans. As far as I know, it is the first bot to make them. Now it has played a game with infested terrans versus Randomhammer.

The game is on Destination, a 2-player map. Arrakhammer opened with hatchery on 9, and instead of playing the opening the natural way with mass zerglings, only made a handful, aiming to tech up fast. Randomhammer opened with 2 barracks and before long had enough forces to push to the zerg natural. Zerg was forced to make sunkens, but terran did not dare to break in, and lost medics due to a bug in retreating them.

Zerg went for lurkers against the infantry, but the expensive sunkens set Arrakhammer’s tech plans far back and the lurkers were slow. Terran accumulated marines to hold a strong contain while expanding. Randomhammer had an objectively winning game; with good play, zerg should never catch up (see the worker and army counts in the picture). But Randomhammer is not a good player.

Straight infantry with only scanners for detection is not a winning combination against lurkers, especially not if you try to attack across a narrow bridge and repeatedly lose medics to the retreat bug. As long as scanner energy held out, Randomhammer held its own. But the scanners ran down and Arrakhammer hesitantly pushed out into the open map.

In this picture the lurkers have defeated most of the infantry after scanner energy ran out during a big fight. The queen has just now infested a command center, and from the flashing ramp and the production tab you can see that an infested terran has already started. Before the base was taken, terran had 5 bases to 4. Zerg had more or less caught up, and both sides had chances.

The first infested terran was shot down barely before it reached its intended victim. Steamhammer knows that an infested terran is a high-priority target, even though this is the first time it has seen one. In the overall situation, marines continued to fight lurkers without enough scan energy, and zerg was pulling ahead.

In the next picture, terran has lost another base, but the marines gave a good account of themselves, clearing the attack and killing the infested command center before it could produce. Losing the base was down to poor tactical skill. The marine army was larger and had 1-1 upgrades versus 0-0 for zerg, and repeatedly fought well until collapsing when scanner energy ran out. The queen, by the way, broodlinged an SCV before the zerg attack.

Infested terrans are difficult units to use well. They’re similar to scourge: Suicide units that do a ton of damage, but are fragile and costly in gas. If you walk them into an enemy army, the army should normally kill them without much risk, as above—it only took 4 marines. If they walk in the open, they should attack SCVs or defenseless buildings. A few infesteds can clear out a dense mineral line, or demolish a substantial block of supply depots; they’re efficient for that. You can drop them on tanks, or on dense concentrations of units that can’t shoot up. Otherwise you need dark swarm to attack an army with infested terrans. You go to a lot of trouble to get them, and they’re a specialty unit which is complex to use.

Of course bots don’t know how to react, so walking into an army may work in practice. Steamhammer, for example, doesn’t react at all when retreating, so if you attack while the army is running away, you can do massive damage. 2 infested terrans did this, with excellent cost-efficiency, by catching the army in retreat:

Notice that even after the carnage, terran is ahead in army, though it has fallen behind in economy. Zerg is winning but has some fighting ahead.

The upcoming version of Randomhammer, by the way, has TvZ improvements so that Steamhammer can be a tough test opponent for itself. The upcoming version would have put up a fiercer fight, without the medic retreat bug and with a vessel and tanks against the lurkers.

How many people remember my catalog of cheese from last August? Of the “no current bots do this” cheeses that I listed then, only early proxy gates (by PurpleCheese) have appeared since. The field is still unplowed.

In other words, hardly anyone pays attention to my suggestions, so I can be the first to point out an idea and also, much later, the first to get around to implementing it in a bot. The best of all worlds!

To show how wide the unplowed field is, here’s a pro ZvZ game on the map Jade, played on 2 June in the Afreeca Clan League. Watch it before reading on, if you want to be surprised.

ggaemo (Z) versus Effort (Z) (with commentary in Korean)

game analysis

Effort at bottom left opened 12 pool. It is a popular build in human play because it is the most economic ZvZ opening that is mostly safe against faster pools, and the pool first (instead of hatchery first) gives it a lot of versatility: You can get fast gas or not, you can expand quickly or not, in any combination. It is not popular in bot ZvZ because it requires a lot of adaptation, and the versatility is hard to take advantage of.

ggaemo at bottom right opened with 12 hatchery, the slowest and riskiest ZvZ build that players dare. The 12 hatch is not safe against most faster pools, but pros still like it because it gives an edge over 12 pool, and 12 pool is popular. Also pros are good at defending, so unlike bots they have a chance to survive even if countered.

So the opening choices, which the players had to make before they scouted each other, favor ggaemo. But the starting positions gave Effort a countervailing advantage because of scouting patterns. Overlords prefer to scout over the opponent’s natural first, so ggaemo’s overlord went up. Effort’s first overlord went across and spotted the morphing hatchery without being seen itself, and overlords did not cross paths so Effort knew he had an information advantage.

I don’t know any bot that could exploit the information advantage, but pros have options. Effort sent 3 drones to the enemy bases, at first holding 2 out of sight range as if only scouting, but then showing 1 in the main and the 2 others at the morphing natural. When the natural finished, he made all 3 drones into offensive creep colonies.

ggaemo was able to save his natural, but the offensive sunken in the main prevented mining and, with support from zerglings, survived a last-ditch defensive pile-up to win.

When bots can do that, we’ll be getting somewhere.

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

I think most Brood War skills are hard to implement well. Every skill I add seems to give me some difficulty or other.

stim

Krasi0 noted that most bots which use stim tend to overstim so that the medics are constantly low on energy. That didn’t seem all so hard to avoid, I thought when I first considered it. Add up the total medic energy, and stim more freely when you have more medics or they have more total energy. Well, it can make sense to stim when you have no medics at all. And how many marines do you want to stim when one zergling runs in as a scout? Hmm, it’s tricky....

The right way to make the decision is to weigh the cost and benefit. The cost is 10 hit points per unit stimmed over the time period until the damage is healed, plus the medic energy to heal it—something like that. The benefit is faster movement and faster shooting until the stim ends, whose value depends on the whole situation. Both cost and benefit should take into account what you expect to happen next (“better save some energy for the next fight”). Tricky is not the word, it’s infeasible to do it optimally! Tradeoffs must be made.

For now, I followed a simple plan not far from my first thought. Steamhammer adds up the medic energy, counts down the amount used by each unit stimmed, and stims more conservatively when it is gone. It overstims, like most bots, but at least not to the point that it runs down its hit points.

Even with poor decisions, stim makes Steamhammer’s infantry stronger. It’s a net gain.

merging an archon

Stim is hard for gameplay reasons. Merging an archon is hard simply because it’s unreliable. Sometimes the two high templar you’ve ordered to merge end up circling around each other and never get together. Sometimes they start to approach each other, run into obstacles, and give up. If you try again, they are likely to run into the same obstacles and give up again, so you have to move them somewhere else first—but where?

Steamhammer doesn’t support psionic storm yet, so I don’t have to worry about the tradeoff between keeping high templar and making archons. I added a micro manager for high templar, with the sole job of merging archons. After high templar learn how to storm, maybe the strategy manager should decide when to merge high templar.

It took me hours to get archons to merge reliably. At least, I hope, mostly reliably. I check templar->getLastCommand(), templar->getLastCommandFrame(), and templar->getOrder() in different combinations to recognize different cases. I picked a point next to a corner of the main nexus as a gathering place for high templar that get stuck and need to be told to move first. Of the high templar ready to merge, I find the closest pair and merge only them, then call it a day for that frame. The combination of measures seemed to be enough.

In one test game, an archon merged at the gathering point and between two other high templar. The archon could not escape because it was trapped among buildings and high templar, and the high templar could not merge because an archon was between them. I didn’t fix this case, I arranged for it to be rare enough that I hope it doesn’t hurt much. Meanwhile, there are failure modes that I didn’t run into in tests....