Starcraft AI blog

These tables show, for each bot, its win rate against each opponent, broken down by map. For example, the first table is for Stardust, and shows Stardust’s win percentages by opponent and map. The tournament played 200 round robins rotating between 5 maps, so each table cell shows the result of 200/5 = 40 games between the two opponents on that map, or slightly less than 40 if some games were not counted due to problems.

See looking forward to CoG 2020 for a general discussion of the maps. As a reminder, the maps are:

• (2)Blue Storm
• (3)Alchemist
• (3)Great Barrier Reef
• (4)Andromeda
• (4)Luna the Final

Stardust	overall	BlueSt	Alchem	GreatB	Androm	LunaTh
PurpleWave	86%	62%	92%	88%	92%	95%
BananaBrain	63%	55%	62%	72%	65%	62%
BetaStar	76%	100%	55%	80%	72%	75%
Microwave	96%	95%	100%	95%	95%	98%
XIAOYI	95%	98%	100%	98%	90%	90%
McRave	96%	100%	95%	92%	95%	100%
MetaBot	99%	100%	100%	100%	100%	98%
overall	87.61%	87%	86%	89%	87%	88%

Aha, details count! Stardust’s overall results look even across maps, but there are differences for the top protoss opponents. It had some trouble on Blue Storm against PurpleWave and BananaBrain, and on Alchemist versus BetaStar.

PurpleWave	overall	BlueSt	Alchem	GreatB	Androm	LunaTh
Stardust	14%	38%	8%	12%	8%	5%
BananaBrain	42%	40%	38%	45%	38%	48%
BetaStar	70%	85%	68%	75%	70%	52%
Microwave	84%	82%	80%	90%	85%	82%
XIAOYI	100%	100%	98%	100%	100%	100%
McRave	88%	92%	88%	85%	90%	88%
MetaBot	98%	100%	100%	98%	92%	100%
overall	70.82%	77%	68%	72%	69%	68%

Again, differences show mainly against top opponents, where PurpleWave favored Blue Storm and struggled on Luna against Stardust and BetaStar (though it liked the map against BananaBrain). Luna is a classic macro map. Maybe PurpleWave is not as skilled at the brute force just-make-more-units-and-win style.

BananaBrain	overall	BlueSt	Alchem	GreatB	Androm	LunaTh
Stardust	37%	45%	38%	28%	35%	38%
PurpleWave	58%	60%	62%	55%	62%	52%
BetaStar	67%	82%	68%	60%	62%	62%
Microwave	74%	72%	57%	80%	85%	75%
XIAOYI	98%	100%	95%	100%	98%	95%
McRave	64%	48%	90%	65%	68%	50%
MetaBot	91%	100%	88%	89%	89%	87%
overall	69.71%	72%	71%	68%	71%	66%

BananaBrain by contrast shows differences versus many opponents, most notably McRave where it dominated on Alchemist and suffered on Blue Storm and Luna. A big disparity like that must mean something.

BetaStar	overall	BlueSt	Alchem	GreatB	Androm	LunaTh
Stardust	24%	0%	45%	20%	28%	25%
PurpleWave	30%	15%	32%	25%	30%	48%
BananaBrain	33%	18%	32%	40%	38%	38%
Microwave	71%	92%	25%	65%	98%	75%
XIAOYI	46%	25%	30%	80%	32%	65%
McRave	70%	100%	20%	80%	90%	62%
MetaBot	90%	92%	100%	85%	91%	81%
overall	51.73%	49%	41%	56%	57%	56%

A checkerboard table. The middling overall percentages are averages of big wins and big losses. BetaStar comes across as strong but brittle.

Microwave	overall	BlueSt	Alchem	GreatB	Androm	LunaTh
Stardust	4%	5%	0%	5%	5%	2%
PurpleWave	16%	18%	20%	10%	15%	18%
BananaBrain	26%	28%	42%	20%	15%	25%
BetaStar	29%	8%	75%	35%	2%	25%
XIAOYI	82%	88%	80%	90%	78%	72%
McRave	42%	28%	60%	32%	48%	40%
MetaBot	86%	95%	82%	98%	75%	82%
overall	40.57%	38%	51%	41%	34%	38%

Also with dramatic variations, especially against BetaStar. Was there map-specific preparation, and if so, why did it not work on Andromeda, which is traditionally considered a zerg-favored map? There was an incorrect announcement of maps followed by a correction, but Andromeda appears on both lists, and in any case the map announcements are dated before the submission deadline.

XIAOYI	overall	BlueSt	Alchem	GreatB	Androm	LunaTh
Stardust	5%	2%	0%	2%	10%	10%
PurpleWave	0%	0%	2%	0%	0%	0%
BananaBrain	2%	0%	5%	0%	2%	5%
BetaStar	54%	75%	70%	20%	68%	35%
Microwave	18%	12%	20%	10%	22%	28%
McRave	100%	100%	100%	98%	100%	100%
MetaBot	76%	95%	92%	98%	57%	40%
overall	36.57%	41%	41%	32%	37%	31%

McRave	overall	BlueSt	Alchem	GreatB	Androm	LunaTh
Stardust	4%	0%	5%	8%	5%	0%
PurpleWave	12%	8%	12%	15%	10%	12%
BananaBrain	36%	52%	10%	35%	32%	50%
BetaStar	30%	0%	80%	20%	10%	38%
Microwave	58%	72%	40%	68%	52%	60%
XIAOYI	0%	0%	0%	2%	0%	0%
MetaBot	82%	98%	85%	78%	78%	72%
overall	31.64%	33%	33%	32%	27%	33%

MetaBot	overall	BlueSt	Alchem	GreatB	Androm	LunaTh
Stardust	1%	0%	0%	0%	0%	2%
PurpleWave	2%	0%	0%	2%	8%	0%
BananaBrain	9%	0%	12%	11%	11%	13%
BetaStar	10%	8%	0%	15%	9%	19%
Microwave	14%	5%	18%	2%	25%	18%
XIAOYI	24%	5%	8%	2%	42%	60%
McRave	18%	2%	15%	22%	22%	28%
overall	11.02%	3%	8%	8%	17%	20%

Upsetting XiaoYi on even one map is not bad.

I parsed the tournament manager’s detailed results log (text file of 5601 lines for 5600 games plus one header line) from CoG 2020 with my own software. Here is a crosstable which exactly matches the official results.

	overall	Star	Purp	Bana	Beta	Micr	XIAO	McRa	Meta
Stardust	1223/1396 87.61%		171/199 86%	126/199 63%	153/200 76%	193/200 96%	190/200 95%	193/200 96%	197/198 99%
PurpleWave	990/1398 70.82%	28/199 14%		83/200 42%	140/200 70%	168/200 84%	199/200 100%	177/200 88%	195/199 98%
BananaBrain	971/1393 69.71%	73/199 37%	117/200 58%		134/200 67%	148/200 74%	195/200 98%	128/200 64%	176/194 91%
BetaStar	718/1388 51.73%	47/200 24%	60/200 30%	66/200 33%		142/200 71%	93/200 46%	141/200 70%	169/188 90%
Microwave	568/1400 40.57%	7/200 4%	32/200 16%	52/200 26%	58/200 29%		163/200 82%	83/200 42%	173/200 86%
XIAOYI	512/1400 36.57%	10/200 5%	1/200 0%	5/200 2%	107/200 54%	37/200 18%		199/200 100%	153/200 76%
McRave	443/1400 31.64%	7/200 4%	23/200 12%	72/200 36%	59/200 30%	117/200 58%	1/200 0%		164/200 82%
MetaBot	152/1379 11.02%	1/198 1%	4/199 2%	18/194 9%	19/188 10%	27/200 14%	47/200 24%	36/200 18%

As usual, the results file is somehow different in every tournament. I got this table by excluding the 23 games in which the loser’s score is given as -1. 22 of these games are reported in the detailed results text file as NORMAL game end type, and in the HTML detailed results as NO_REPORT. It bothers me that the two sources do not match. The Starcraft AI Ladder documentation on game end states says “this could be caused by the Tournament Manager client crashing, or a network error, etc.” so it’s correct to exclude these games. The remaining game shows GAME_STATE_NEVER_DETECTED, where apparently neither side was able to start. The NO_REPORT results are not necessarily the fault of the bot, but in fact 2 of the games had Stardust as loser and the other 21 had MetaBot, so there is a strong correlation.

Here are the versus-race results. They are strongly skewed by protoss dominance, and of course there is only one terran participant. So these numbers are not much use.

bot	race	overall	vT	vP	vZ
Stardust	protoss	87.61%	95%	81%	96%
PurpleWave	protoss	70.82%	100%	56%	86%
BananaBrain	protoss	69.71%	98%	63%	69%
BetaStar	protoss	51.73%	46%	43%	71%
Microwave	zerg	40.57%	82%	32%	42%
XIAOYI	terran	36.57%	-	28%	59%
McRave	zerg	31.64%	0%	32%	58%
MetaBot	protoss	11.02%	24%	5%	16%

Next: Maps per player, in the same format as this post on AIIDE 2019. I need some updates to my software first.

The CoG 2020 results are out today. Overall results, a crosstable, a win rate per map table, and zip files of replays for each bot were released. Source code will be delayed until after AIIDE 2020. It’s not mentioned, but I expect that the tournament manager’s log of detailed results and the bot write directories will appear eventually, and then I’ll put up my colorful crosstables and other analyses. There is also an unspecific apology “We conflicted with several problems while running the competition. Sorry that I didn’t smoothly handle them. However, I hope to meet again with better competition in the future.” Something must have gone wrong.

The results give only 8 participants of the expected 10. Of the announced entrants, newcomer random Mikhail Golovach and old-timer zerg ZZZKBot do not appear in the results. Are they related to what went wrong? The effect is to tilt the tournament further toward protoss, 5 of the 8 bots.

As I predicted (probably along with most), the top winners were #1 Stardust 88%, #2 PurpleWave 71%, #3 BananaBrain 70%. PurpleWave was last year’s version (see the 89% frame timeout rate of a recent version on the Starcraft AI Ladder), which explains why it barely nosed out BananaBrain.

The three holdover bots scored much worse this year than last, and ended up in a different order. Progress has been strong, though it’s hard to compare because the field was much smaller and less varied this year, and had no low-end bots. Tail-ender MetaBot scored over 50% last year, so the field was stronger from the get-go. (The year-old version of PurpleWave scored 88.56% last year to 70.82% this year, but I didn’t include it in the table because I don’t know whether it’s the same year-old version.)

bot	last year	this year
#4 BetaStar	67.41%	51.73%
#6 XiaoYi	72.21%	36.57%
#8 MetaBot	59.04%	11.02%

There were exactly 3 upsets: #3 BananaBrain upset #2 PurpleWave, #6 XiaoYi beat #4 BetaStar, and #7 McRave zerg overcame #5 Microwave. Another surprising result is that #7 McRave zerg scored only 1 win out of 200 versus #6 XiaoYi, even though XiaoYi is a holdover that McRave could have tuned against. By comparison, #5 Microwave scored 163/200 versus XiaoYi.

The per-map table shows that #1 Stardust performed about equally well on all maps. I guess its fast-mass strategy is not sensitive to map layout. All other bots were more sensitive to the map. Most strikingly, Microwave scored well on the tricky two-entrance map Alchemist, while #8 MetaBot utterly collapsed on Blue Storm.

I looked through the CoG 2020 accepted papers and noted a couple that relate to Starcraft. One is Combining Influence Maps with Heuristic Search for Executing Sneak-Attacks in RTS Games by Lucas Critch and David Churchill.

This looks like a student Lucas Critch with advisor Dave Churchill. Including the advisor’s name on a student’s paper as second author is an academic convention, and does not give away how much work the advisor may have contributed to it; it may be a substantial effort not much less than the student’s, but it is often “OK, that’s good enough, you can add my name.” The advisor is generally better known than the student, which may draw attention to the paper and its first author. Alternatively, the advisor’s name may overshadow the student who is soon forgotten. I’m not sure which effect is bigger.

As usual, the title is bigger than the content. The paper is actually about how to route a dropship across the map so that the enemy is less likely to catch it along the way, so that the drop is not intercepted and comes as a surprise. It proposes to use the A* algorithm to find the dropship path, and assigns a higher cost to tiles which the enemy is thought to be more likely to see or shoot at; A* will find the lowest-cost path, trading off distance versus risk of being caught.

The paper proposes three influence maps to add up to figure the costs: An enemy vision map based on known or remembered enemy units and their vision range, to avoid being seen; an enemy damage map based on units that can shoot at the dropship, to avoid being shot down (if you are going to be seen, at least be seen by something that can’t kill you); and a weaker map of shortest paths between various bases, which the enemy is likely to be moving along. This figure from the paper shows a sample path:

The path looks fairly reasonable, except that the dropship should follow more diagonals and not exact horizontals and verticals. The paper says nothing about replanning the path when new information is discovered. Trying the system out in real games is future work, not yet done. Theoretically, the shorter safe paths might lead to faster drops which do more damage.

This is early stage work and not impressive so far. But I think it is a good reminder for bot authors: Most bots do not worry much about what the enemy sees, and pay attention mostly to what the enemy does. Finding good transport paths in real time is an important basic skill that bots will eventually have to master. The reaver-dropping protoss bots especially may want to think about that; aiming for the enemy army and aiming for the enemy base and workers call for different approaches.

Although a more important basic skill, that many bots also lack, is recognizing the danger and reacting properly when they do spot a transport moving across the map. Most bots are incurious and it never occurs to them that perhaps a drop is incoming, and perhaps defenders should be moved into position to intercept.

The CoG conference is underway from today through Thursday. It is of course entirely online in this plague year (did somebody let a defiler loose?). I expect the CoG 2020 tournament results to appear during the conference or not long after. The conference program does not announce a time, as far as I can see. You can look back at my expectations if you like.

I am working hard to prepare Steamhammer for AIIDE 2020. I have already uploaded 3 different test versions one after another to the Starcraft AI Ladder, and I have made good progress on the next test version to go up in a day or two. Each version shows some kind of progress in its play, though the win rate does not always go up. The AIIDE update will be much bigger than the update to the current 3.1 release.

I have been watching a huge number of replays and analyzing results with my software. The purple Dan Gant talked in an Undermind podcast about his tournament preparation process: He examines losing games only, identifies the most frequent game-losing weaknesses, and works to fix those. It’s great method, a direct way to improve tournament results in the short term, especially for a bot which can expect to finish near the top, meaning that it shows relatively rare game-losing weaknesses at its level of play. My goal is different, and I follow a different process. I also want to finish well, and make low-risk short-term improvements, but my top goal is to improve play in the long run rather than the short run. I identify ahead of time aspects of play that I think I can and must improve, and I examine both winning and losing games with an eye on those aspects, often looking at specific opponents that bring out those aspects. The weaknesses in winning games must be fixed too; they are by definition not game-losing, but fixing weaknesses improves play and that’s that, and to my eye winning games often show glaring blunders by Steamhammer. Anyway, at Steamhammer’s level of play, fixing a game-losing weakness often leads it to go wrong in a different way a little later and lose anyhow, so I may have to fix a string of weaknesses before I see results. Those are compound weaknesses, as it were, and I run into a lot of them.

I have learned some things by analyzing the ladder results with my software. One of the things I learned is that I could figure out even more if I wrote more software, and if I had Steamhammer record more information that I could correlate with the game results. I may do that soon, and post data.

The Ladder has new participants since I last wrote about it. Besides Stardust, MadMixP is new and StyxZ is reactivated. Just today, CherryPi joined too. That makes 11 active participants, enough for a small but lively scene. I still recommend joining the ladder if you intend to compete in AIIDE 2020, because it is the best way to test that your bot runs correctly in the AIIDE environment, adhering to the strict time limits and so on. Just letting it run for a day is enough to test for basic correctness (the ladder runs games much faster than BASIL), and if you have a problem you want to find out about it early so there’s time to fix it.

Most terran bots that lay spider mines don’t pay much attention to where the mines are relative to where their own units are, or to where their own units will be, only to where opponents are expected. Spider mines do massive splash damage to all units nearby, enemy or friendly, so it’s safest to keep your own units away from them. These pictures show what can happen when you leave a spider mine in your own mineral line.

In this case, the mineral line was thinly populated, so only 5 SCVs died along with the 1 zergling that triggered the mine. “Only” 5.

Laying a spider mine in an enemy mineral line can be good. Maybe you can lure a zealot to trigger it. In a neutral base, it will tell you if the enemy takes the base and may not give away that you know. If you take that neutral base yourself, your mine is a danger to yourself. You should kill it.

Most terran bots (even Krasi0) will happily set up a tank line in the midst of their own minefield. When a pro feels the need to do that, they kill their own mines if there is time. In bot world, most opponents don’t particularly notice the opportunity of triggering the enemy mines on purpose, so they score mine hits on enemy units by chance if at all. Some do it deliberately, though. Skynet by Andrew Smith has code which purports to drag mines into the enemy. I also see mine dragging code in PurpleWave, and I expect other top bots have the skill. It’s high on my list for adding to Steamhammer, because it is devastating when it works.

KangarooBot has returned. Its github repo claims many bug fixes, and critical enhancements such as “Improved retreating to the point where retreating is no longer an option.” (Steamhammer takes that attitude with lurkers, btw, with mixed success.) The goal of the update is said to be “to see what Bot v Bot stuff i need to fix.” The answer appears to be a lot. KangarooBot was disabled on BASIL with a win rate under 6%; it has scored better on SSCAIT with 16% wins.

On the topic of funny bot names, do you suspect a secret connection between StarCrusher and Stardust?

SSCAIT’s web site is back up, though so far it doesn’t seem to be playing games. (Is this the service being moved to its new home?) I uploaded Steamhammer 3.1 there as soon as I saw. It should pass through to BASIL as usual.

I’m pleased with 3.1’s performance on the Starcraft AI Ladder. It was a small update, and the win rate went up by a small but consistent amount. If that holds on BASIL too (I expect it will), then Steamhammer stands a good chance of overtaking Microwave, which just recently stole the top zerg crown. Steamhammer and Microwave have been swapping top zerg honors for a long time now.

Stardust has joined the Starcraft AI Ladder with a 93% win rate, pushing everybody else’s win percentages down. That’s good. But with few participants and those changing over time, it’s difficult to check progress week to week; you can’t simply compare your win rate this week to your win rate last week. Maybe at the end of the week I’ll calculate elo ratings.

Steamhammer has suffered a regression: Scourge has mysteriously started to target floating buildings again, a mistake that I originally fixed long ago. Somewhere bits have decayed.

Steamhammer 3.2 and up

Steamhammer 3.1 is no longer running on the Starcraft AI Ladder; I already uploaded a version I called 3.2. I decided that the plan is to leave Steamhammer 3.1 on SSCAIT and BASIL until after the AIIDE submission deadline, and upload frequent test versions to the eponymous Ladder (as opposed to the ladders with other names). They’ll be called 3.2, 3.2.1, and so on, so the AIIDE 2020 version will be 3.2.something.

I won’t be going into detail yet, but 3.2 has 3 changes. 2 are the cheese responses, and if they’re successful you won’t often see them because opponents will learn better. The other you won’t see at all: I lifted the limitation which made Steamhammer unable to mine out blocking mineral patches which contain a non-zero amount of minerals. Once I looked at it, I realized it was only 2 lines of code, trivial to write and easy to test. None of the ladder maps (for any of the ladders), and none of the AIIDE 2020 maps, has blocking minerals like that; all their mineral blocks are stacked 0-mineral patches. But there will be another “unknown maps” contest at AIIDE, and maybe one of those maps will.

I tested on Sin Peaks of Baekdu, by the way, which has mineral patches with 40 minerals to block a useful path next to each main. The difference between stacked 0-mineral patches and single small mineral patches is usually not important to the player; you have to return the minerals you mined, which eats frames, but the blocks are normally close and have few minerals so it’s not many trips. But if the opponent wants to mine out the block to attack you, it’s a different story. Stacked o-mineral patches can be mined out in one go by sending one worker for each patch in the stack (mining out all patches in the stack simultaneously), so it can allow early-game cheese. The single mineral patch has to be mined out 8 minerals at a time, so the prospective cheese victim has more opportunity to react.

The sunken defense of outlying bases in Steamhammer 3.1 has the effect of keeping drones alive and allowing it to play its favorite macro game. Not that Steamhammer is feeble at fast rushes, but in the late game once it has all the drones it wants it rarely loses. Cheese defenses also discourage the opponent from trying to win fast, and allow Steamhammer to select macro openings more safely. Against Halo by Hao Pan, Steamhammer has been favoring one-base muta play, which can defeat both Halo’s bunker rush and its 2-port wraith strategy (it’s amazing to watch mutas and scourge pummel the 2-port wraiths—soon cloaked—with less than half of terran’s worker count). In fact, Steamhammer prefers pool-first builds against a surprising number of opponents. My hope is to tighten the early game and get a big economy more often.

Steamhammer 3.1 source and binary are available at Steamhammer’s web page.

With the new Steamhammer 3.1 version running only on the Starcraft AI Ladder, I played over a bunch of ladder games to see how it is doing. The ladder runs games at a high rate, so after one day there were already plenty to see. As I expected, so far the overall win rate is not much different, though that might change with more time or a larger variety of opponents. I was amused that the ZvZ games tended to be the longest (due to Microwave’s cautious play style); the ZvT and ZvP games were more aggressive and shorter.

I’m pleased with the new feature to sunken bases which are at risk of vulture raids. Some games versus Halo by Hao Pan looked tighter; Steamhammer could take bases and retain most of their drones in the face of the fast-roaming vultures (it lost drones mostly in transferring between bases, the next worker safety issue I should address). It seemed to make the sunkens at a reasonably efficient timing, including against protoss, early enough to help and not wastefully early. A small step, but a good one.

For AIIDE 2020, submission deadline at the end of September, I’m thinking of uploading test versions to the ladder as I go. I expect to get more work done before then than went into version 3.1. In fact, already today I wrote 2 new reactions to enemy cheeses that cause trouble, and each by itself is more complex than the sunken feature of 3.1. (It will take longer than a day to test them, though.) Steamhammer will become more robust. For AIIDE, I’m still considering whether to concentrate more on basic skills, or more on sneak attacks from my bag of tricks, techniques that bots may be unready for because no other bot has played them yet.

For all who want to participate in AIIDE, I strongly recommend joining the Starcraft AI Ladder. I wrote up the signup process. It runs the same tournament software as the AIIDE tournament, and enforces the same strict time limits. It is the best way to find out whether your bot will run correctly in the tournament. The games become public, and nothing else. If you worry that the games themselves may give away your secrets (other bots might use the ladder as training data), you can work around that too: Deliberately weaken your strategy. You’ll still test correctness and adherence to the time limits, but you don’t test your strength so you don’t give away your true weaknesses to others.

I uploaded Steamhammer 3.1 to the Starcraft AI Ladder. Not to SSCAIT, since it is down. The update is a small one, there’s not much new stuff and no major new features; my rate of work has been low. It should be stronger than version 3.0.2, but not by a wide margin (of course I predicted the same about that version, which made a big gain). Steamhammer’s weakest race terran got the most additions. In a startling break with tradition, I wrote no new openings.

I expect that the next released version will be Steamhammer 3.2, which I will put out after the AIIDE 2020 submission deadline. My to-do list includes a deep bag of tricks that I can select from....

expansion order

• Take bases in a better order. Reading the code that chooses the next expansion showed me a few gross bugs, which I fixed. I also adjusted values to be a little less wrong. It’s still none too smart; for example, it doesn’t understand that zerg base order versus terran should be much different than versus protoss. The worst remaining problem, though, is caused by a bug in the building manager: When workers repeatedly die before reaching the building site, the building manager may cancel the building without unreserving the tiles, so that the base can never be taken for the rest of the game. That’s bad, but I intentionally left it unfixed for now because some of the bug’s effects are good. If you repeatedly fail at taking a base, then, well, maybe you shouldn’t try to take that base. Steamhammer’s base-taking behavior becomes adaptive. I don’t want to fix the bug until I can provide that adaptivity on purpose rather than by mistake. Failing to expand to the same unsafe base over and over is not a winning plan.

• I added a debug option to the configuration file, DrawExpoScores, which draws Steamhammer’s idea of the value of taking each base. It’s generally a positive number for bases near Steamhammer’s main and a negative number elsewhere on the map (which doesn’t matter, it simply picks the highest value). If the base cannot be taken, it draws the reason instead.

micro

• Ranged units give higher priority to targeting tanks. This was inspired by games in which Steamhammer’s hydralisks saw a factory with a tank on the other side, and decided to shoot at... the factory.

• Bug fix: A worker that had just mined out a mineral block might go idle. When it happened, the worker not only wasted its life doing nothing for the rest of the game (not even watching cat videos), it also blocked the path that it had been given the task of clearing. Now that’s some powerful laziness!

terran

The terran changes are related to repair of buildings and to lifting of buildings.

• Bug fix: It understands that it can’t repair a building which is not completed. I believe the effect of this aboriginal bug in the code is that an SCV is assigned to repair, can’t start because the building is not repairable, and gets reassigned the next frame. I didn’t verify it, but it must slow down mining.

• Mass-repair a bunker or turret. The response time is slow, so it doesn’t work as well as it should. A simplified calculation makes a rough guess at the right number of SCVs to assign (it does get the correct answer in the case of repairing a bunker under attack from dragoons).

• It can repair multiple buildings at once. The original code, inherited from UAlbertaBot and little changed until now, could repair one building at a time. For buildings other than bunkers and turrets, it assigns one SCV each. Only a fixed proportion of the total SCV force is allowed to repair at a given time, so that mining is not impeded too much.

• It repairs buildings other than bunkers and turrets only after they fall to half health. If it’s only a hurt a little, it’s not worth it. Mining is the priority.

• In a build order, the command "go lift [terran building type]" lifts all buildings of that type which are able to lift. For example, "go lift engineering bay" lifts all engineering bays that can lift. If a building is producing a unit or researching, it is not able to lift and ignores the command.

I originally wrote up lifting while working on the scout boss. Since the scout boss is deferred, there is currently no code to tell the lifted building to do anything. It can’t land and it doesn’t move, it just floats in place. Lifting is limited, but it does free room in the base for other buildings.

• The strategy manager automatically lifts any barracks and engineering bays when the opening is complete and the build calls for factory production only. So you should rarely need to use the lift command in a build.

zerg

• In build orders in the config file, some upgrades used to require the race name, like "zerg flyer attacks". That still works, but now if you prefer you can leave out the race and write only "flyer attacks". It was a missing case in the parser.

• Build sunkens at outlying bases to provide some defense against vulture raids, sneaky dark templar, and small drops. If Steamhammer suspects that one of those specific things may be coming, it builds a single sunken colony at each base that it expects may be in danger—for drops, that means every base, while for ground raids it skips the sunken at main bases in the hope that a sunken at the natural will be enough. The aim is to add the minimum of static defense. ZvZ is not affected. I expect this to be most effective against terran vulture raids, reducing drone losses and giving the zerg main army time to react.

• Against valkyries or corsairs, get air armor a little earlier. It will help for the rest of the game.

• If we have gas-heavy hive tech, make extractors more freely. I keep telling Steamhammer, “Hey, this is late game already, what’s the holdup? Why haven’t you taken gas at every base?” Somehow I can never accelerate the late-game extractors enough.

Steamhammer 3.1 is almost ready. It needs a small amount of tuning and a larger amount of testing. The new feature I wrote should help with a certain weakness in ZvT and ZvP; it is less than 50 lines of code plus a tidbit or two of infrastructure, hardly a major feature. If no big issues come up in testing, I’ll upload it in a day or two.

Earlier I wrote up a game proxy versus proxy of Steamhammer and Krasi0P, where Krasi0P played its cannon contain strategy. To show Krasi0P’s other choice, here’s a game where Steamhammer played similarly and Krasi0P played its defensive cannon strategy, like so:

In the picture, Steamhammer has calmly morphed its proxy hatchery into a lair and started spawning drones in what it sees as a perfectly normal expansion. Never mind that the lair should be morphed where it won’t be seen immediately, and where it is less likely to be destroyed in passing. It happened to turn out well, since the lair had more HP. In the minimap we can see that zerg has also made a third hatchery at its natural. No hurry, after all protoss made cannons so a nice slow macro game should be in the cards, Steamhammer seems to believe. And in fact Krasi0P is adding another cannon beside its nexus for no apparent reason, and making its cyber core. First tech, then act, is its plan.

When zealots arrived, Steamhammer still had not made an army to handle them, much less a sunken as you would expect at a proxy hatchery. The drones had the sense to run away, and the zealots had the foolishness to chase them instead of focusing down the lair. They chased drones that they could not catch (almost all drones fleeing the proxy reached the zerg natural), and the proxy survived to keep making units.

Spawning drones that will soon have to make a run for it across the width of the map... is not objectively good. But it happened to turn out well, it distracted the enemy from what it should have done. That’s the story of this game, bad moves that worked.

Steamhammer chose lurkers as its first tech. It could not immediately cope with the corsairs, because most of its hydralisks morphed into lurkers. A number of overlords were shot down, and overlords were needed on the scene because dark templar were out for protoss. The lurkers succeeded regardless, though, because Krasi0P never answered them. Protoss made no observers, and the lurkers were in little danger from dark templar because they know not to unburrow when an undetected enemy is around to hit them.

Steamhammer not only narrowly saved its lair, it upgraded it to a hive. Proxy hive, have you seen that before? Once overlord speed finished, Steamhammer’s strong economy and steady upgrades meant that the day of corsairs and dark templar was over; the overlords accompanied an army strong enough to protect them; overlords were relatively safe and protoss with no expansion was outnumbered. Zerg busted the ramp cannons while starting to take additional bases, and the rest was cleanup.

Neither side had the skills to play the situation correctly. Krasi0P’s mistakes were more serious: It failed to kill the lair, it failed to counter lurkers, and it failed to send out a probe to expand to a more distant base. (Look at the mineral and gas counts. Krasi0P’s higher supply is because it has excess probes, enough for 2 bases even though it never expanded.) Steamhammer’s aggressive opening followed up with a macro game plan risked a quick loss, but because of protoss mistakes, it ended up putting zerg far ahead.

Well, I posted this game to have fun showing silly stuff. But I can’t help analyzing it.

Starcraft has 3 suicide units: spider mines, scourge, and infested terrans. They need to be handled much differently than other units. All of them do high damage but are easy to destroy, so they are units with a lot of leverage (meaning that using them well brings a lot of benefit). Spider mines are difficult because they don’t move after they’re placed; you have to foresee the future to place them well. Scourge is difficult because it does move. Infested terrans are difficult because they are rarely any use unless they coordinate with other units.

Steamhammer is one of the best bots at scourge usage, but objectively it is distressingly weak. It often hits a target with more scourge than are needed to destroy it, is overcautious about attacking targets defended by ground units, suicides scourge against mass air units that can defend themselves, retreats scourge that have no immediate target too far from the fight, and other blunders. But it’s daunting to think of all the work needed to play well with just this one unit type.

How many scourge per target? Well, each hits for 110 damage, so divide. If a mutalisk target (120 HP max) is hurt more than slightly, you can kill it with 1 scourge, and you don’t want to waste any. But if there’s a long chase to catch it, it might heal during the chase and you’ll need 1 extra. Theoretically you could account for that beforehand. Or a target might recharge at a shield battery, or suddenly be mass-repaired, or d-matrixed. That’s hard to predict, and if it happens you might want to turn the scourge away—unless extras are already handy.

Scourge can be shot down on the way to the target. A battlecruiser has 500 HP, so it dies to 5 scourge. It can fire one shot before the scourge strike, and the shot can kill one scourge, so you need to send 6. Well, actually whether it kills the scourge depends on upgrades. 2 scourge kill a corsair. 4 scourge kill 2 corsairs. But 12 scourge do not kill 6 corsairs; the corsair damage splashes and protoss may defeat most or all of the scourge. In general, any enemies nearby may cooperate to kill your scourge. I don’t have a better idea than to simulate the attack and see how many scourge may be shot down, to decide how many are needed and whether it is worth it.

Usually you want to send enough scourge to kill the target. Don’t sent 2 at a time against that lone battlecruiser (as many bots do, including Steamhammer and PurpleSwarm), because only 1 will hit and you’ll need twice as many. Usually, but not always. A mutalisk has 120 HP, so a scourge hit leaves it with 10. A muta with 10 HP is nearly useless in an air fight, so if you follow up the scourge with your own mutas then the enemy muta will flee or die, or both. Neutralizing an enemy mutalisk with 1 scourge hit is a crazy-efficient use of gas.

What tactics? Scourge see corsair and chase; corsair sees scourge and flees toward safety (like a cannon or a group of dragoons). The corsair can try dodging micro moves to throw the scourge off; I doubt that works well against a bot. Pro players like to predict the path of the fleeing corsair and intercept it with another pair of scourge sent from another direction. I don’t know any bot that tries that.

Later, there may be many scourge and many corsairs. To minimize the splash damage to the scourge, try converging in a wide arc. That may make it worth while.

With lurkers versus protoss, you want to snipe observers. Undetected lurkers can delay protoss a long time, so it may easily be worth it to spend several scourge to kill a single observer that tries to stay safe among dragoons. But don’t fly in headlong, try to analyze the dragoon locations and choose the best angle.

In general, good scourge planning and pathing is complicated and depends on the tactical situation. And how are you supposed to do the planning, which has to happen before you can do an accurate combat simulation, without combat simulations first to figure out what works? I guess expensive methods may be needed.

Where to go when there are no immediate targets? Scourge are fast, so if the enemy has little anti-air, which is common versus protoss early in the game, a good idea may be to swoop around the map looking at stuff. But scourge have short sight range, so that’s dangerous once the enemy is good at shooting up. Scourge want to stay near where enemy air units may appear: Over or near the front-line army (which will protect them), above cliffs or unwalkable areas near the fight, along paths where dropships or corsairs may fly, or in your own base to defend against air raids. Making the best choices means predicting the enemy, not a simple skill.

The bottom line: Scourge use is awesomely complex. I don’t want to code all the details, I think I have to aim for more general methods of search and machine learning.

Registration for the AIIDE 2020 tournament opened today. The registration deadline is 31 August, and the submission deadline is 30 September. Steamhammer will be competing.

Most details seem to have no change from last year, but after using the same 10 maps from 2011 to 2019, this year there is a new pool of 10 maps. In the 2 player maps, Benzene is dropped in favor of Polaris Rhapsody. In 3 player maps, Tau Cross is out and Longinus is in. In 4 player maps, Andromeda and Fortress give way to Fighting Spirit and Roadkill. Other maps remain the same.

That’s 4 new maps. All 4 appeared in the “unknown map” secondary tournament last year, so they are tested in bot play. (That tournament ran with 5 maps; only Arcadia was not moved into the new map pool.) All the choices seem standard and conservative, unknown only in the sense that they were unannounced beforehand. By the way, the “unknown map” tournament will be repeated this year. Maybe the map choice will be a little more daring this time?

• (2)Destination Back door mineral block to each main base, and other features favoring cheese play. The most logical third base location is immediately above a wide ramp and hard to defend; bots have even more trouble defending the thirds.
• (2)Heartbreak Ridge Back door mineral block to high ground over each side’s natural base, on the path to the third. The many ridges benefit bots which understand high ground. The center base breaks the middle of the map into two paths; you can go above or below the center.
• (2)Polaris Rhapsody Follows the three-paths map pattern; you can move your army down the center, or by a longer path down either side.
• (3)Aztec Low-ground main bases. This causes problems for bots which wall off inside their main.
• (3)Longinus Level-ground main bases, like Tau Cross which it replaces.
• (4)Circuit Breaker is an old standard.
• (4)Empire of the Sun is another map with level-ground mains.
• (4)Fighting Spirit is another old standard, likely the most played map of all time.
• (4)Python is an old map which I take to be an attempt to rework the aboriginal Lost Temple into a balanced map. Compared to most maps, there is more contrast between close and distant main bases; the enemy may be near or far depending on starting locations.
• (4)Roadkill is the most recent of the maps, not to be confused with Roadrunner. It has low-ground mains and the famously thorough Freakling technical design.

Maps not in the SSCAIT pool are Polaris Rhapsody, Aztec, Longinus, and Roadkill. The maps are also outside of BASIL’s extended map pool (“2019Season1”), so some bots may not have played them.

The changes seem designed maintain the variety and balance of the map pool. I don’t expect any big shift in results; a tournament on the previous map pool would likely have a similar outcome. The new pool is slightly less tricky due to dropping Benzene and Fortress, on which a bot with specialized map knowledge has a chance to gain an advantage. That may mean that old bots and new bots with more specific skills can be compared a little more fairly, but I expect that the difference is small.

Overall the map pool change seems fine, unlikely to cause difficulties either in the tournament or in comparing with past tournaments. Given that, I wonder why the change was made. For my part, I’m pleased to see Longinus. I will miss Fortress, though. I like that map.

Update: I asked Dave Churchill why the change after so many years of the same maps. He said he just hadn’t gotten around to it before—the maps were originally meant to be changed every year.

Results of this year’s CoG tournament will be announced later this month. I am later than usual with my take. The new participants of CoG 2020 will be these 7:

• Stardust (see yesterday)
• PurpleWave
• Microwave
• Mikhail Golovach (random bot apparently named after its author)
• BananaBrain
• McRave
• ZZZKBot

The only unknown newcomer is random Mikhail Golovach, who is listed as a hobbyist. Most brand new bots from individual programmers turn out to be weak, but there are occasional startling exceptions like Bereaver. At a minimum, going random shows ambition, so we can hope it’s strong and interesting!

I predict #1 Stardust, #2 PurpleWave, #3 BananaBrain as the most likely top winners, based on past records plus my look at Stardust yesterday. But there are surprises every tournament. I think McRave cannot be counted out for the #3 place because it is strong at PvP, and of course Mikhail Golovach is an unknown.

There will also be 3 carryover bots from last year:

• MetaBot
• BetaStar
• XiaoYi

These 3 bots are pretty good, especially BetaStar which is a Locutus fork, but opponents will be prepared. I expect most of the 7 new entrants to perform well against them.

That makes 6 protoss, 2 zerg, 1 terran, 1 random. Protoss outnumbers all others together. Protoss dominance is becoming entrenched. I don’t like that, I should work harder on Steamhammer.

I wrote earlier about the CoG 2020 map pool. Now the specific 5 maps to be played have been selected from the pool.

• (2)Blue Storm has 2 exits toward the center of the map from each base. One is direct but narrow, only passing small units; dragoons and lurkers don’t fit, for example. The other is wide but the path is longer. Only bots with size-sensitive pathfinding will maneuver their armies correctly in long games; others risk getting units stuck. Do any bots have size-sensitive pathfinding? I don’t know of any, but I haven’t looked.

• (3)Alchemist has a circular layout with 2 entrances to each base, so you can go around the map in either direction to reach the enemy. Since it’s a 3 player map, one direction is short and the other is long. This map has appeared in past CIG tournaments, where the 2 entrances confused many bots and led to bad games. On the other hand, I predict that the map will cause little trouble in PvP games, which will be the majority this tournament.

• (3)Great Barrier Reef has mineral lines around the edge of the map that can be mined out to open new paths. Any bot that knows how to take advantage of this map feature may gain an advantage. Bots that can’t take advantage will probably be OK in most games, though; the edge paths are longer, so no matter whether you rely on native pathfinding or roll your own, you should normally find perfectly adequate paths through the center.

• (4)Andromeda is familiar from SSCAIT.

• (4)Luna the Final is a classic macro map, as standard as they come, sometimes criticized for leading to boring standard games. Bots should be fine on it.

Update: An anonymous commenter points out that McRave is playing zerg, not protoss. Oops, I didn’t pay enough attention! I changed the coloring in the list of entrants to reflect that, but did not update the commentary. To correct the counting, protoss is half of the total pool of participants and equal with zerg among the new entrants.