Starcraft AI blog

It has been announced that the island map Sparkle will be used in the ASL5 round of 24, to be played starting on 11 March. I first mentioned the map on 13 February. The original announcement by Afreeca (Google translate) goes into some detail on the map and the changes to it (also for the other new map Transistor).

The updates to Sparkle since it was first proposed are substantial, which gives me the idea that the map author is still struggling with the balance. It seems difficult to balance an island map. Also there isn’t much time before the tournament starts, and players need time to work out the best strategies—and sometimes surprising ideas eventually come up on nonstandard maps, like the guardian build on Monty Hall. Still, I hope we get at least a glimmering that play can be made fair for all matchups. I’m looking forward to the strategic variety, and if players believe that an island or semi-island map can be balanced (even if Sparkle never is), then the variety will be around to stay.

In a system inherited from UAlbertaBot, Steamhammer keeps a queue of items to produce (units, buildings, research, etc.). As soon as the prerequisites for the next item in the queue are satisfied, it produces the item: There have to be enough minerals and gas; for a spire the lair has to be finished; etc.

It’s kind of strange, but this isn’t always best! There are times when it is better to mine a little longer rather than sending a worker to construct a building right away. This is true even when the building is definitely the next thing to make, and you don’t want to schedule anything ahead of it.

I know a clear example among Steamhammer’s openings. In the terran BBS opening, terran builds 2 barracks at 8 supply. Steamhammer starts each one as the 150 minerals for the building become available. It’s best to start building the 2 barracks simultaneously: The SCV that would start the first barracks gets to mine a little longer, and the marines are not delayed (in fact, they’re stronger in a group, so there’s an advantage to producing them 2 by 2), so delaying the first barracks puts terran slightly ahead.

Building a spore colony because the enemy got mutalisks earlier is 2 examples in 1: First, as a game issue, you want to time the spore colony to finish just before mutalisks reach your base. Second, you need both an evolution chamber and a creep colony, and purely as an efficient production issue you would like to time the creep colony (300 frames to complete) to finish simultaneously with the evo (600 frames to complete), so that you waste as little mining time as possible. Another example is starting a hydralisk den to finish simultaneously with the lair, or to finish when you have just enough gas to start lurker research. I expect you can think of examples for other races.

How should this be implemented? Ideally, the bot should figure out for itself when it is better to delay production. Game issues like timing the spore colony should be decided by a tactical calculation outside the production system itself; somebody else needs to tell the production manager, “get this by time t.” For purely production issues, the bot might simulate the timings to find the most efficient, or it might set up a system of constraints and solve the optimization problem. These calculations are very elaborate—I might implement one of them someday, but not any time soon.

In the meantime, I’ve been wondering whether there is a good way to manually configure delays in common cases. It would be easy enough to add a command to the build order, like “wait for 300 minerals” that you’d put before starting the 2 barracks for BBS. The problem is that that is only one case. Sometimes you want things to start simultaneously (the barracks), sometimes to finish simultaneously (the evo and creep colony), sometimes to finish exactly when conditions are right for something else to start (hydra den finishes when you have 200 gas for lurker research). I haven’t thought of a simple way to specify the different conditions you might want.

Well, in the end, this is a minor optimization. Steamhammer has bigger problems with building stuff efficiently. Even so, I’d like to address it someday. So if anybody has ideas....

Combat simulation answers one question, and answers it pretty well. It adds a lot of strength to a bot’s play. But there are many related questions that the simulation does not answer, at least not simulation as we currently implement and use it.

Taking free shots. Combat simulation is all about armies fighting, but the enemy army is not the only thing you want to shoot at. When the combat sim says to retreat from the enemy, Steamhammer retreats, even if if is already out of range and could safely take shots at exposed supply depots or other valuable stuff that can’t shoot back. It’s not a problem with the combat sim in itself, but it is a side effect of relying on the combat sim as the big decision maker. I’ve been thinking I’d solve it by calculating safe places and advantageous places, and holding position in advantageous places that are safe.

Can you run away? You’re in a hot fight, and the sim says you’re going to lose. Steamhammer runs away, and sometimes it is a mistake. If you’re fighting ranged units, you may die before you’re out of range; better to stay and do some damage first. If you’re fighting faster units, they can catch you and get free kills. Unupgraded marines should not flee from speed zerglings; if they are going to die no matter what, at least take some of the enemy along. It’s complicated, though. If you have friends nearby, maybe you can run and live. Or the dragoons can run and leave the reaver behind. The reaver is too slow to escape, so it should stop and fire when it can. In general, you want to simulate different cases and see which one comes out best. It amounts to performing a search over different tactical actions.

Harass versus big battle. FAP author Hannes Bredberg suggested (see comments to separate, independent unit control for micro) running the simulation for a very short period such as 0.5 second, a poke at the enemy. If you gain from the poke, do it. It’s a smart idea; a bot might do well without once looking ahead beyond the next moment. But instant gratification is not the only gratification. What if the first zerglings die to firebats, but once those are gone you mop up survivors and come out ahead? What if you lose more than you gain in the battle itself, but the enemy is wiped out and afterwards you can go to town on the enemy base? To recognize chances for delayed gratification, you want to look further ahead.

Maybe the right idea is to sample the outcome-so-far periodically as the simulation runs. If you’re ahead after 0.5 second, stop there and attack. If you’re behind then but ahead after 1.0 second, that’s a higher risk so maybe you should attack only if you’re a little further ahead. And so on. You can also cut the sim short if you’re too far behind. Maybe you can estimate whether losses are accelerating, or decelerating and possibly turning around. It’s both cheaper than running a simulation of the entire battle, and potentially more valuable. It’s an idea, anyway.

Tactical coordination. Here’s a common blunder made by Steamhammer, and also by related bots like Microwave: Zerglings and mutalisks are assigned to different squads, and act independently. There is no explicit coordination. The combat simulator acts as an implicit coordinator. It runs separately for each squad, and if the squads are in the same place then in each run it will pit the same friendlies against the same enemies and give the same answer. The mistake comes when both squads are deciding whether to attack (say) an enemy base strongly defended by sunken colonies and zerglings. Combat sim says, “Well, the zerglings are toast, but the mutalisks eventually win, so yeah! Go attack!” The right decision is to keep the zerglings back to stave off any attempted breakout, and go win with the mutalisks alone—losing your own zerglings lets the enemy’s run free, forcing the mutalisks to give up the attack and defend. The combat sim itself is unable to understand. In this case we could work around it by handling each squad separately, but that is a special case; in general, arbitrary units might be unhelpful in a given battle. I’ve seen Tscmoo do it right, at least in some cases.

Screening. Steamhammer likes to keep its army forward, just out of contact with the enemy. The forward position is aggressive and also risky. One advantage is that Steamhammer gets to see what the enemy has and what the enemy is doing; the corresponding disadvantage is that the enemy gets to see Steamhammer too. One of the skills I want for Steamhammer is screening: Maintain a small screening force forward to keep tabs on the enemy, and hold the bulk of the army farther back, in a more flexible position where it is also out of enemy sight. The screening tactic is common in pro zerg games, especially earlier in the game.

How does that affect combat simulation? It’s perfectly possible to simulate a fight between distant enemies, but the result will be less accurate. Imagine a zerg army gathering far outside the range of photon cannons and defending zealots. Should the zerg attack? SparCraft and FAP will assume that the armies approach each other and fight in the middle, far from the cannons, and will keep saying “zerg wins!” until the zerg army actually approaches the cannons and finds that the zealots are still in defensive positions. The combat sim needs more smarts to get the right answer.

Andrey Kurdyumov (aka Andrey Kurdiumov on SSCAIT—I’m sure it’s only a different transliteration) modified his AK Bot to include both SparCraft and FAP. This github issue is about the change, and comments today to this old post about Steamhammer 1.3.1 start to compare the two combat simulators.

He tentatively concludes “for early game SparCraft should be better, but in the mid/late game FAP could be better.” He’ll test more, but for now it seems that the plan is for AK Bot to choose the better combat simulator for each situation. Simple and logical!

AK Bot, by the way, plays very similarly to its parent UAlbertaBot. The zerg and terran opening builds look identical to UAlbertaBot’s, and as terran it opens BBS while UAlbertaBot gets marines later. It makes sense that SparCraft, as a part of UAlbertaBot, would be optimized for low-economy play like UAlbertaBot’s.

At some point I opened the istream of bugs, and now I can’t find the close method. I think the bugs are holding the valve open by force.

Yesterday I fixed a basic bug in choosing tech targets. I rewrote that code for current release version 1.4. It fixes a number of bugs, and in testing it came out better than the old version, especially in ZvP. After release, I started seeing puzzling mistakes in ZvT—Steamhammer refused to switch to lurkers after opening with mutalisks, no matter how much it needed them. Getting that decision correct was one of the reasons for the rewrite!

When I read the code closely, the cause was easy to see. A condition was reversed: Where it should have been “no need to do this step if we already have a hive,” it was written to mean “do this only if we have a hive.” I have to imagine that I made some late change and didn’t check it carefully. Quick tests show that the fix improves play in both ZvT and ZvP. With more experience, we’ll see how that holds up.

In other news, Steamhammer has been on a losing streak against Killerbot by Marian Devecka. I started to worry that I had introduced a bug, so I laid in a short match to find out. Steamhammer scored 11-4, good but not as good as in days past. I guess the losses were mostly due to a string of bad luck. I did spot a couple of contributing issues: The opponent model can sometimes cause a bad strategy reaction when it misdiagnoses Killerbot’s opening, and mutalisks which are busy destroying the enemy base are unable to return home to defend (due to a change that improves play on average, but harms it here). If I fix those plus a few longstanding defensive and tactical weaknesses, Steamhammer should score near 100% against Killerbot.

My list shows 18 improvements made for the next version 1.4.1 already, and yet I haven’t solved the uncommon crash bug. I’m thinking I’ll have to resort to dragnet methods.

What upgrades should you get? In what order? I often see bots get upgrades in an order that doesn’t make sense to me. I’ll mention 2 big examples.

If you’re terran and you’ll be making marines for a long time, you want the academy upgrades. Standard is to get stim first and then range. Stim helps in almost every situation, and it helps a lot, while range has a smaller effect and gives the greatest boost to large groups of marines. Stim also takes less time to research. When I added stim to Steamhammer, I found it clear that stim made the marines much more dangerous, despite the fact that (like most bots) Steamhammer tends to overstim and run down the energy of its medics. Probably the most important change needed to stim is not reducing overstim, but making sure that stim is always researched as early as possible. BOSS doesn’t understand priorities, and just throws research in whenever.

And yet I think most bots that get both stim and range, get range first. Even sophisticated Tscmoo gets range first. Why is that? Maybe there’s a good reason—every bot is different, and you want to tune for its skills. Or maybe it’s a mistake.

The other example is zerglings versus zealots in ZvP. Unless you’re going all air like XIMP by Tomas Vajda, protoss should get +1 ground attack as the first forge upgrade. Bots generally do that right. (The second forge upgrade should be +2 attack, and the third should be +3 attack. Get armor, and maybe then shields, only if you’re upgrading at multiple forges, or after +3 attack finishes.)

If you opened forge first, you may be able to start the upgrade very early. It’s worth it. A zergling has 35 health. A zealot does 16 base damage, so it takes 3 hits to kill a zergling. A zealot with +1 does 18 damage, and 18 * 2 = 36 so it kills a zergling in 2 hits (the zergling will regenerate 1 hp, so the 36 is exactly what’s needed). 2 hits versus 3 is a giant difference. Zerglings suddenly turn into tofu.

A zealot has damage factor 2, meaning it hits twice in each shot: It doesn’t do 16, it does 8 + 8. So a zergling with +1 carapace avoids 2 points of damage. If zerg can get as many carapace upgrades as protoss has attack upgrades, then zerglings remain zerglings and do not become bean curd.

CherryPi gets +1 zergling attack instead of +1 carapace. It is effective against a protoss that does not upgrade at all. Against a protoss that gets +1 attack, it is a mistake. I’ll do the arithmetic. A zergling does 5 damage; a +1 attack zergling does 6. A zealot has 60 shields: That’s 12 hits versus 10 to remove the shields. A zealot has 1 armor and 100 hp: That’s 25 hits (100 hp divided by 5-1=4 damage per hit) versus 20 to finish the zealot off. I’m ignoring shield regeneration, because it gets complicated. That makes 37 hits versus 30, a nice improvement. 30/37 is .81; it takes about 4/5 as many hits after the upgrade. But 2/3 is .67—the zealot’s attack upgrade outweighs the zergling’s attack upgrade.

There are other examples. These are the ones that jump out at me.

Yesterday I thought, “You know, it would be easy to add a MacroLocation “center” so the bot could build proxies in the middle of the map. Why don’t I just do that?” It only took 10 minutes to hook all the pieces together, and a few more minutes to code up a quick version of center BBS to try it out with.

On the first try, I realized “Oh, 2 x barracks @ center doesn’t work because I never fixed that parsing bug.” You couldn’t have both a multiplier “2 x” and a macrolocation “@ center” at the same time, you had to say “barracks @ center” twice to get the same effect. So I went and fixed the bug, and now it works. That’s a good step.

On the second try, I noticed that the constructing SCVs were sent out from the base much too late. There is code that sends out builders early to try to start buildings as soon as possible, but it is not able to cope with buildings that are so far away. The result is that the barracks are constructed much later than they should be, which defeats the purpose of making them in the center of the map in the first place. The limitation does not seem easy to lift. The code to send builders early ties in with both the building manager and the worker manager, and it’s fragile; in the past, most things that touched it caused bugs. I need to figure out a more robust mechanism, throw out the old code and write it better. Or I could add a command to explicitly send builders early for proxy openings. Or something.

After a few more tries, I found an even worse problem. Where the center of the map is inaccessible, as on the map La Mancha, one or both of the barracks can be dropped. An SCV is assigned but it goes idle and never starts to build. Building placement is supposed to find the nearest clear area to build in, but in this case it apparently fails altogether, another bug.

Now you know why bots progress so slowly. Even an easy skill, only 10 minutes to code, can take days to debug. I’m not sure whether I’ll end up fixing the 2 problems any time soon. They definitely deserve to be fixed, but there are more serious bugs that deserve it more. In the meantime, “@ center” is available (well, it will be after the next release) but it is not useful.

In sort of related news, I ripped out the crufty old DistanceMap code inherited from UAlbertaBot and replaced it with shiny new DistanceMap code from UAlbertaBot—in a later version. When Dave Churchill removed BWTA he redid that part. The new version is much, much cleaner and was well worth borrowing. That portion of Steamhammer’s code will be easier to work with thanks to the improvement, and I loved being able to delete ugly stuff from MapTools. Though it was only a small refactoring, it took me a whole day to fix the bugs I introduced in making it. A valuable code improvement that is not even visible in the bot’s play can still take a lot of time.

Speaking of maps, the map Bloody Ridge is giving me grief. The version named Bloody Ridge 2.1_iCCup.scx is strange in this way: It is a 2 player map, but BWTA2 says it has 3 starting positions, while BWAPI says it has 8 starting positions. I found out because the unexpected numbers caused a crash.

I found an older version named (2)Bloody Ridge 1.2.scx which seems fine.

Does anybody know what’s going on?

Update: The 8 start positions are (in tile coordinates) the real start locations (117,6) and (7,86) plus an array of 6 others in the upper left at (6,5) (10,5) (14,5) (6,8) (10,8) (14,8). I’m guessing this is an observer map? Though it’s supposed to be the regular version and there is a separate observer version. The original ICCup map page is broken now, so it’s hard to be sure. I don’t understand how observer maps work. Does BWAPI provide enough information to reject the spurious start locations? There is a base in the upper left, so apparently BWTA says “one of these looks like a real start location,” but BWAPI itself doesn’t do any further analysis.

Yesterday’s brief post about the exotic island map Sparkle unexpectedly connected with a past and continuing discussion about maps. I’ve written about map choice before: See choosing tournament maps, and also tournament map selection as a prod.

One widespread opinion, and I agree, is that a new map should not break old bots, but should provide opportunities to new bots. Existing bots that have not been updated in a long time should be able to play on the map with their usual skill. Bots that understand the special features of the map should be able to exploit them to gain an advantage. For example, pure island maps break old bots, but a regular map with some island bases is playable for all bots and provides an exploitable map feature (and we already have some maps with islands). Maps with map blocks that disrupt pathing also break many old bots, but map blocks designed to allow smooth pathing outside the blocked regions provide an exploitable map feature. The map Fortress used in AIIDE is an example, with blocked off corner bases. There are many other examples of maps with exploitable features.

Lately, I’ve been feeling that the SSCAIT maps are becoming stale. They are fine in themselves, but I’m tired of them staying the same. The advantages of maps that stay the same for years are that old bots continue to work as well as ever, and you can compare over time. The disadvantages are that new challenges are lacking, and that it can get boring. Fun is a critical mission requirement, if you don’t mind me putting it that way. And the April Fool prank of playing on Big Game Hunters for a day doesn’t quite fulfill it.

SSCAIT has an official map pack with 15 maps, and uses 14 of them. Electric Circuit is included but disabled, because its blocked paths cause a lot of bots to mess up (Steamhammer included, by the way). One idea to provide variety without breaking continuity is to keep using the familiar 14 official maps and add one more map that changes periodically, perhaps the Map of the Month. That fills out the map pool to the full 15 and provides a small touch of variety and new challenges, but not so much that bot authors are forced into extra effort to keep up. That idea seems to me like a good compromise. Of course other ideas are good too; maybe commenters will suggest some.

Of course it’s easy for me to suggest. I don’t do any of the work of running the service! Kudos to those who do, and I hope they can find time to realize map variety in some form.

One of the maps proposed for the Afreeca Star League season 5 (ASL5) is an island map: Sparkle. In my 2016 post on novelty maps I wondered whether it was possible to balance an island map using modern map-balancing tricks. Sparkle is a serious attempt to do that, and I’m interested. At the moment, the public is voting to help decide which maps will be included in the tournament.

Steamhammer got another mystery crash. It was assigned a crash loss with no crash record and no replay saved, while playing as zerg, the best-tested race, against Ecgberht at 2018-02-13 16:22:50 server time. There’s a longer than usual time gap between games, which might mean that the game went to late game and something rare went wrong, or might mean a server problem. Either way, with no information saved there’s nothing I can do about it except cry the news.

BWTA provides 2 main features that Steamhammer relies on. Other features are minor and easy to replace. 1. It figures out where the bases are on the map. I’m implementing this myself right now (I have the basics written, but it doesn’t work right yet). This accounts for most uses of BWTA in the code. 2. It figures out regions and chokepoints between them. Steamhammer uses both, though not for many purposes. Later, when the bot starts doing tactical analysis, the feature will become critical. I’m always thinking ahead, so today I’m pondering how to implement regions and chokes.

The usual way of breaking the map into meaningful regions is to first identify chokes. A choke is meaningful in itself, because it is easier to defend than open ground where the enemy can come at you from every direction. Then a region is defined as a walkable area which is connected to other regions only by chokes. You end up with a graph of regions that you can use for pathfinding (as BWEM does), for recognizing threats (“there’s an enemy in my base region!”), for planning tactics (like MaasCraft), and no doubt more.

So we earn a high return if we know what a choke is. But what is a choke? Suppose we think of a choke first as a more defensible narrowing of the terrain. If you have a large army, then even a slight narrowing of the terrain makes an area more defensible. In the early game when you have only a few units, a wide choke is hardly different from open ground. If the potential choke is a ramp, then being on the high ground side makes it more defensible no matter what, while being on the low ground is sometimes worse than standing on open terrain. The defensibility of a choke is valuable information, and defining regions in terms of their defensibility seems useful, but it is also slippery. Defensibility depends on context.

Bots that are too rigid in defining a choke make characteristic mistakes. For example, on Andromeda many bots recognize a choke between the main base and the in-base mineral-only. The terrain is a little narrower there.

Bots that want to defend at the first choke and recognize the first choke as being between the main and mineral-only will misplace their defenders. Zia does this when in the upper left start position, as one example. It’s better to defend at the ramp, which is nearly as close, much narrower, and offers high ground to the defender.

Any rigid definition “this narrow or narrower and it is a choke” will cause this kind of mistake on some maps, or else the opposite kind where the bot fails to recognize a good defensive location. Of course you can tweak it so it works well on a given set of maps, like the SSCAIT maps. To completely solve it, you want to do a topological analysis of the map to find single points of defense, which is easy if you have the graph of regions. To guard the main on Andromeda, there are 3 single points of defense: The wide choke between the main and mineral-only, the ramp, and the outer choke between the gas natural and the rest of the map. Defending any one of those spots protects the main from ground attack. Of the 3, the ramp offers by far the best defensive location, which you might recognize by a score including the width, whether you hold a ramp down from high ground, and maybe closeness to the defended area or to production buildings. Of course if you want to guard both the main and the gas natural, there is only the outer choke.

For Steamhammer, I definitely want to be able to score every choke that the bot might care about during the game, whether I use it to divide regions or not. I’m thinking of scoring every tile on the map for width-between-walls, the length of the shortest bar you can place that blocks a path. I see a simple algorithm that I think is likely suitable. With that, you can decide “is this a good place to siege up, or will it block my other units?” With that and a knowledge of ramps, it should be possible to score any place on the map for “is this a good spot to make a stand?”

I haven’t decided what to do about regions. If I think of good uses, I might go with multiple sets of regions using different definitions of chokes. For example, I can imagine it might be useful to change the regions used for tactical analysis during the game. “I have a lot of tanks now, might as well treat this whole area as one big choke.”

I was expecting a flood of new bots after SSCAIT re-opened for submissions, but apparently the flood this time came before the tournament. We don’t have many brand new bots. Nevertheless, authors are working hard and progress seems at least as fast as last year. I count 9 enabled bots updated today or yesterday! Here are 2 that caught my eye.

Ecgberht (almost as hard to spell as it is to pronounce) is updated and is tearing the place up. Its strength is stepped up much higher, and its ranking is sure to rise—its only loss in its most recent games is a crash. It likes to build up to a big attack with infantry and sometimes tanks, rather like LetaBot. Some games: an easy win over ForceBot’s lurkers for zerg (more impressive than the smash of CherryPi). A win over Hannes Bredberg with defensive play for terran. A win over PurpleWave for protoss, the best of the 3 games. Ecgberth was not seriously threatened in any of these games.

PurpleSwarm is a new zerg from the PurpleWave family. So far, PurpleSwarm’s play is not inspiring. PurpleWave’s protoss is suffering in this version too; in its latest game against Steamhammer, when at an overwhelming advantage, it suddenly pulled all 75 probes into the middle of the map and did not mine for the rest of the game, a fatal bug. Even so, PurpleWave can now play all 3 races, and that’s nice.

One of my age-old traditions, which has gone on for over a year now, is to announce my plans for upcoming versions before I change my mind. After I change my mind, I get to announce new plans. No wonder there are so many posts!

1.4.1 will be out as soon as I can fix the not-so-common crash that Antiga reported. Tracebacks are inconsistent, which points to memory corruption, which points to a bad pointer without admitting where it might be. Or it might be something else. So I’m not sure how long it will take. In between checks to catch the bug, I’m carrying on development of features. So far I’ve made only a couple small changes, including adding the new 21Nexus opening coded up by Antiga.

For 1.4.1 and/or 1.4.2 I want one of the opponent model features I mentioned earlier (see the last long paragraph of that post), plus progress on removing BWTA, plus progress in fixing at least one of the major weaknesses. For BWTA I will do the base information stuff like fetching the base’s geysers and so on. That will take me 90% of the way toward getting rid of BWTA, which by the standard rule of thumb means that the work will be 50% done. Having base info handy will make it easier to implement running workers away when a base is under attack, which is a major weakness, so that will be the other one. As always, I’m sure to do a lot of little fixes and improvements too.

I’m not sure how many more minor versions I’ll make, 1.4.3 and so on. However many there are, each of them will have one more important opponent model feature. I’ll keep it up until I find that the opponent model is Pretty Damn Good, whose definition is to be discovered empirically.

It’s also time to add new units and basic skills. It has been a while. Protoss will get shield batteries, which are already implemented almost correctly. Other top candidates are spider mine laying and tank micro for terran, and midgame drop and defilers for zerg. Drop and defilers are both complicated, so expect the first cut to be limited. I also want to give zerg overlords a sense of danger, because Steamhammer loses far too many of them, another major weakness. Before the 1.4.x series is over, I want to get shield batteries, at least one terran thing, and one or two zerg things. We’ll see how it goes.

Pretty vague plans, but this is what I’m thinking.

Steamhammer’s documentation is updated for version 1.4. I hope it will help people get started with the code and configuration.

I took a preliminary look at how far creep spreads from a hatchery. Here’s a picture from my first experiment.

The numbers on each tile are the distance from the hatchery, determined by hatchery->getDistance() and scaled to tiles instead of pixels. Tiles for which BWAPI::Broodwar->hasCreep() is true get orange numbers. Boxed tiles are unwalkable according to Steamhammer’s walkability map: A 32x32 tile is walkable if all its constituent 8x8 walk tiles are walkable, taking into account terrain and fixed neutral units only.

Creep spreads in an oval pattern, similarly to power from a protoss pylon. Of course creep spreads bit by bit, unlike the instantaneous power from a pylon, but at the start of the game the initial hatchery has its full spread of creep, so in that case we can ignore the spreading process.

After trying this on a variety of maps, including some irregular Blizzard maps, I found that the initial hatchery’s creep, though its outline seems a little odd, takes on a tile-for-tile identical outline on all maps. I’ll test further, but it looks as though I can predict the creep for the initial hatchery without much trouble: Hardcode one pattern of creep spread, match it to the hatchery location, clip it at the edges of the map, and trim away the minerals, geyser, and any terrain features that don’t allow creep. So far I haven’t tried a map where this method would give a wrong answer.

If it continues to look good, then an upcoming 1.4.x version of Steamhammer will be a little faster to find the bases of zerg opponents. Early game scouting units will definitively identify the occupied base when they see creep, and definitively identify an empty base when they don’t see creep that should be there.

Later versions will also have the ability to infer the existence of a zerg base by seeing creep later in the game. It’s strange to see bots pass in sight of creep and not realize what it means—“must keep looking, where is that last enemy base?” That feature will be a little more complicated. We don’t want to infer the existence of a base which was just destroyed, or get confused because outlying creep colonies of one base extend the creep as far as another base.

Next: Other near-term plans for Steamhammer.