Starcraft AI blog

For anyone who hasn’t noticed, the CIG 2019 tournament is announced. The key info:

Registration date: 17 June
Submission date: 10 July
BWAPI versions: 3.7.4, 4.1.2, 4.2.0, 4.4.0
Latency setting: LF6 (“Fastest”)

As I hoped and expected, they are supporting the latest BWAPI 4.4.0.

Last year, CIG 2018 had some issues. (Note: One item I listed as a tournament issue, Ziabot’s problem, was likely Ziabot’s own doing, and the build order breakdowns were apparently due to the LF6 latency setting that bots were supposed to be ready for, and can also blamed on the contenders—though you have to wonder why they decided to change the ground under the feet of returning bots.) The build order breakdowns affected Steamhammer and messed up its play in every game. Making the debacle worse, Steamhammer suffered a severe crashing bug, which was of course on me. All in all, it left me with an impression of unfairness and it was not a fun experience. I’m not inclined to play in CIG this year.

I do expect to analyze the results, though. If all goes well, maybe next year.

The AITT S2 tournament (not to be confused with AIST S2) has been announced, AI Tinycraft Tournament for bots with under 4000 bytes of source. Registration deadline is 1 April, submission is 1 May. For this edition, the maps are air oriented, with starting bases that are islands, or that begin isolated by ground with exits blocked by minerals that can be mined, or neutral buildings that can be destroyed. All 5 maps are difficult, and they have common points but they are quite different from each other.

• (2) Paradoxxx is an old island map with 2 bases worth of resources in each main: 14 mineral patches and 2 gas geysers. The only other gas expansions are overlooked by a wide high ground area that the players are to fight over. If you can control the central high ground, which has no resources itself, you can probably control both gas expansions in the long run.

• (2) Coulee is a Blizzard map from way back. Each starting base has a main and natural that are somewhat far by ground and close by air, and which together are blocked from the rest of the map by a row of mineral patches with 500 minerals each. There are corner bases blocked by a mineral patch of 24 minerals (modern maps generally have 8 or 0 minerals in that kind of blocking patch). And there are center bases that you can try to hold if you somehow gain enough map control. The 2 center gas geysers, with no minerals nearby, have only 2000 gas each. It takes a long time to mine through 500 minerals, so you probably want to go drop or air. You could also push 3 workers through the minerals (or build a command center and float it outside, then make 3 workers there) and take a corner base, but you’ll be lacking mobility.

• (3) Plasma from 2008 has several tricky features. The main is small, so not all your buildings will fit there. The ramp is narrow, so that large units cannot pass. There are arrays of neutral eggs blocking the paths between bases. You can mineral walk workers through the eggs, because there are mineral patches placed in view on both sides. Other units can only pass once eggs are destroyed to clear a path, and eggs are tough so that takes time. (Well, can only pass easily. It’s possible to push units through the eggs, but it’s not quick or reliable.) Next to each main are a mineral only natural near the ramp and a gas natural on the opposite side. The center area provides access to 3 high ground expansions, each of which overlooks 2 starting bases.

• (4) Sparkle is the 2018 island map that attempts to be fair to zerg. Each base comes with a natural that has a blocking building that must be destroyed before you can mine the gas. It also comes with a third that has 3 mineral patches and a geyser that only zerg can mine from. There are 4 center islands with a base each, but it is often preferable to take a second main because it has more resources.

• (4) Arkanoid is about destroying neutral stuff. Each starting position comes with 3 bases, a main and 2 equal naturals, one to each side. Each of the dual naturals is blocked by 4 neutral chrysalis units, though I’ve seen a number of games where players mine with an offset resource depot instead of clearing the position. There are 3 paths out of each base, but each path is blocked by neutral buildings, and then you have to destroy further neutral buildings to get anywhere else. It is key to know where you are going so that you can destroy the right buildings. Arkanoid historically favors terran and sneers at protoss.

Useful skills are drop, pushing units through minerals, mineral-walking workers through neutral units, destroying neutral stuff that is in the way, and floating terran buildings for scouting and for mobility. For example, on Coulee a terran could float a factory out of the base and make 1 tank to prevent the enemy from mining its own blocking minerals; there are unbuildable areas on the map, but not just outside the bases, so add turrets and more units and the enemy will be forced to stick with air or drop.

I expect we’re going to see some wacky strategies from the tiny bots. Carriers versus battlecruisers will not surprise me. On the downside, the maps have bad imbalances in human play, although bot play is known to be different. I expect that we will see mostly terran and protoss and few zerg.

The story of AIST S2 is Velocirandom, the winner that struck by surprise. Locutus defeated 5 other opponents and looked strong, but it lost two matches to Velocirandom. How did Velocirandom do it?

Velocirandom plays random on SSCAIT, but chose protoss for this tournament where random is not allowed. Velocirandom is a cheese loving bot with tailored builds for given opponents. Here are the names of the enemy-specific strategies it was configured for:

Ecgberht	Protoss_ZealDTGoonT
Hao Pan	Protoss_ZealGoonT
LetaBot	Protoss_Zerglings
BananaBrain	Protoss_ZealDTGoon
Locutus	Protoss_ZealotT
MadMix	Protoss_FourGoonA
PurpleWave	Protoss_ZealotT
Steamhammer	Protoss_ZealGoon
tscmoo	Protoss_ZealotT

Velocirandom was specifically prepared for everybody who was there, plus LetaBot which did not compete (and was set to face the strangely named Protoss_Zerglings build, nexus first into zealots and dark templar). The only opponents it actually faced were Steamhammer, Hao Pan, and Locutus. I have not checked whether Velocirandom’s preparation for the other opponents was as good as for these three. But I think it’s likely that each build is a timing attack or exploit to take advantage of a weakness of specific opponents. That’s certainly how I read the choice against Steamhammer.

The openings have short names, but they are long and detailed build orders. The ones with “zealot” in the name, for example, make a fixed number of zealots at fixed times, then a fixed number of dragoons, and so on. The lesson of the tournament is that even the strongest bots still have weaknesses that can be exploited by a well-chosen fixed build order.

The Velocirandom DLL is about 3.5KB bigger than the SSCAIT Velocirandom that was last updated on 18 February. That’s a reasonable chunk of code, but not huge. In the AIST vods, organizer Nathan Roth speculated that it may have some transplanted Locutus dragoon micro code. That seems plausible to me.

It was a near miss for Locutus, which had a hard road and made all opponents but one look weak. Hao Pan also performed well. I was impressed with McRave’s PvP play (and it still has those deadly scarabs).

The good news for Steamhammer is that it maintained its performance from last year even as the field grew stronger (always one of my goals): It lost 4 of its 5 games and was knocked out as early as possible. In a knockout tournament this strong, that’s within the expected range, so it’s only a little disappointing. Still, with different pairings Steamhammer could have won a few matches. Knockout tournaments are unpredictable.

I’m accomplishing things slowly for now, but that doesn’t stop me from laying plans—or rethinking my past plans. Rather than working hard, I’ve been adding new openings, including a couple that are quite different in idea from anything else in Steamhammer’s repertoire. New openings don’t help in the short run (they mainly make it harder to find the right opening), but I am looking ahead.

Anyway, given my slow progress and the decision to participate in AIST S2, here’s my changed plan for the near future (it should be stable at least until tomorrow). Rather than get Steamhammer 2.2 out at the end of SSCAIT, which I missed by a mile, I’ll release it after AIST S2 submission at the end of this month. Or possibly I’ll skip 2.2 and release 2.2.1 slightly later, because I’m again concentrating on zerg for the tournament and there may be fixes needed for terran and protoss. With people worried about shallow forks, I’m thinking about releasing source less often anyway.

As far as visible play changes goes, the tournament version has bug fixes, including a fix for the debilitating command jam bug that makes macro games ugly. And it has the usual fleet of minor improvements, and a couple which are not as minor. For a tournament I have to bring something more, so I’m aiming to add at least one strong and unexpected tactical feature. I have a shortlist.

In AIST S1 I lost a lot of time coping with the map Sparkle, and other maps caused trouble too. I’m not expecting difficulties in this edition. So far, I haven’t run into problems with any of the AIST S2 maps (well, not beyond the usual). I will run a lot more tests, but so far so good. Not that my expectations are particularly accurate, but I expect to be ready in good time.

Next: Longer range plans.

In Steamhammer, I made a change to construction that was supposed to fix 2 bugs, the delay in starting construction for some buildings, and the abandonment of drones whose buildings cannot be started (they sit idle sometimes for a long time before being sent back to work). I figured out a plan so simple that I thought it should work on the first try—but no, in reality it brought enough bugs for Noah’s ark. It was such a setback that my motivation faltered and I have been debugging desultorily. Everything is delayed further.

Meanwhile, AIST S2 tournament registration is opening. No announcement made it my way; I had to seek it out myself. I decided only a couple days ago that Steamhammer should participate again, though I haven’t tested it at all on the map Eddy. Even if I move slowly, the submission deadline is the end of February and I should be ready. It’s possible that tournament prep may cause more delays (last year it caused long delays; this year won’t be as extreme). I may or may not release the tournament version, depending on how it turns out.

I hope Steamhammer 2.2 will be worth the wait. The new map analysis should not affect strength much, though it will affect play to a certain extent. Some critical bugs are fixed, others are pending; if I get them all done, play should be visibly cleaner.

In between ASL 7, the SSCAIT round of 8, about 4 hours of video on DeepMind’s AlphaStar, and keeping up with Steamhammer’s games, I was watching Starcraft today nearly from dawn to dusk. Coding progress: Zero. Time to do something else for a while and write about it!

In SSCAIT, the hard-to-predict matches were PurpleWave-BananaBrain and Iron-Steamhammer. PurpleWave 3-2 BananaBrain was the expected close match. In the next round we can expect PurpleWave > SAIDA and Locutus > Iron, so PurpleWave and Locutus will fight it out in the semifinal. I think Locutus has an edge, but PurpleWave retains chances.

I was not surprised by Iron > Steamhammer, but I was surprised by Iron 3-0 Steamhammer. It was unlucky that it was so one-sided. When Steamhammer has ample learning data, it has a small advantage over Iron. On a 2 player map, the 2 hatch muta variant usually wins, but here Steamhammer played it on a 4 player map where it usually loses due to poor execution—Steamhammer didn’t have enough data to connect its past wins with 2 hatch muta to the map size. On other maps, the AntiFactory build wins 50% or a little more, and in this match Steamhammer was still casting about for ways to win and didn’t try AntiFactory. It’s because I knew that Steamhammer didn’t have enough data that I gave the edge to Iron. Steamhammer is likely to win in the next round and, as others have also predicted, drop out in loser’s round 4 to SAIDA.

Interestingly, commenters who predicted Proxy > Hao Pan were wrong. All the information I can find seems to indicate that Proxy has the upper hand over Hao Pan. Did somebody hit a learning transient?

AlphaStar in Starcraft 2 gives us a foretaste of what to expect from advanced neural network learning. On the one hand, they spent huge computing resources—weeks at a time of “many thousands” of simultaneous games with 16 of Google’s TPUs per player—to learn to play protoss versus protoss on a single map. On the other hand, AlphaStar came out of that work with exceptional micro and strong judgment, areas in which all Brood War bots are currently weak. Machine learning is the way to get strong judgment. But it’s not easy.

They say that AlphaStar plays with average APM around 280 and latency around 350 ms, both somewhat slower than human. That makes its strength more impressive. They didn’t say so clearly, but I got the idea that the 350 ms latency is for free: It takes that long to evaluate their deep and complex network, so they can’t react faster! They did not talk as much about how AlphaStar’s real advantage is not in speed, but in precision: It does not misclick (at least not harmfully). Humans have a tradeoff of speed versus precision; if you do something faster, you do it with more slop. AlphaStar is a little slower, but far more precise than a human, so in fact it stands higher on the speed-precision tradeoff. It should play better, given equal knowledge. Still, it certainly takes fewer liberties than a BWAPI bot.

I’ve thought through the SSCAIT knockout bracket. The upcoming match between PurpleWave and BananaBrain could go either way, but I think PurpleWave has an edge. If PurpleWave wins, then it is likely to defeat SAIDA in the next round, then an easier opponent in the following round. In the semifinal, PurpleWave would likely face Locutus and have chances but stand at a disadvantage. SAIDA is likely to cruise through the loser’s bracket. If SAIDA faces Locutus, it is a probable win. If it faces PurpleWave, then maybe it will have played enough games for SAIDA’s learning to find a solution, but if not, then PurpleWave will win again. In the other case, PurpleWave loses to BananaBrain in round 2. In this case it will likely struggle on to face Locutus in the loser’s final, and again stand at a disadvantage. SAIDA will cruise through the top, and the final will be between SAIDA and Locutus or PurpleWave. So I think SAIDA and PurpleWave are the most likely winners, with SAIDA as the best single pick because it has fewer likely ways to lose twice.

Steamhammer defeated Krasi0P as predicted, and faces Iron next. The match could go either way, but Iron has better chances. I think if Iron wins, then Steamhammer will likely make it to loser’s round 3 or 4 before dropping out. If Steamhammer wins, in the best case it might get as far as the loser’s round 5. Last year, Steamhammer lost in loser’s round 4, so the relative level of play seems similar.

In unrelated news, I’ve re-uploaded Randomhammer. It’s the tournament version, Steamhammer 2.1.4. The last uploaded version of Randomhammer was 2.1, so there are improvements that were previously only visible in zerg play. But note that the drop openings are not working properly. Drops are working in the development version, but I still have a bunch to do before I release it.

On the BASIL ladder, Steamhammer in early days performed poorly. But today Steamhammer ranks #8, ahead of KrasioP. If we skip the BASIL participants which are not in the SSCAI tournament (Krasi0 terran and ChimeraBot), that corresponds to place #6 on SSCAIT, just behind BananaBrain, as compared to Steamhammer’s actual tournament finish at #11. The performance corresponds in general to Steamhammer’s performance curve in AIIDE 2018, starting low and rising strongly, but seems even more dramatic.

Many bots have different rankings on BASIL compared to SSCAIT. Random bots are handicapped on BASIL by comparison, since the opponent knows the race ahead of time. There are other differences in rules, plus the environment can cause different reliability and possibly different behavior. For most bots, I think these differences should not matter much—though anything could happen for a bot with reliability problems. Am I wrong? Am I missing something that can make a big difference?

If I’m right, then the important difference is that BASIL plays more games, so learning bots learn more. Other than environment-specific bugs, I don’t know another way to explain big differences in rank, such as Killerbot by Marian Devecka being #19 on BASIL while it came in #7 in SSCAIT 2018: Killerbot is not a learning bot. Another difference (just to give a second example) is that BASIL ranks Ecgberht one step below Arrakhammer, rather than far below (SSCAIT #16 versus #33): Ecgberht is a learning bot.

Steamhammer has a surprisingly high crash rate on BASIL, over 6%. It doesn’t crash remotely that often on SSCAIT. I’ll have to look into that.

The SSCAIT 2018 round robin is complete. The last few games were not interesting and were before dawn in my time zone, but I woke up and watched them anyway. Congratulations to the final 16, it was no easy road, and I now intend for Steamhammer to crawl its way to the top over your corpses. And congratulations to everybody else for the effort, even though others crawled upward over your corpses.

Now we can try to forecast the round of 16, which seems to be playing right now though the games are not being streamed. #1 SAIDA, #2 Locutus, #3 Iron, #4 PurpleWave, and #5 BananaBrain are all big favorites to win. Maybe somebody can work through future pairings in detail and try to tell whether SAIDA can be eliminated by facing both of the 2 opponents that scored 2-0 against it. At first glance it seems possible.

#6 Krasi0P is paired against #11 Steamhammer (I landed just below the middle of my predicted range #7-#13, which were tightly spaced after #7). In the round robin, Steamhammer won the first game, and I expected a win in the second game too, but it didn’t happen. I thought the plan recognizer would understand the cannon rush and react properly. The second game shows that it did not recognize the plan correctly, but it should at least have understood the plan in the second game. The plan recognizer is tested to work in this situation, so I’m still expecting a win in this match. But I was wrong once; maybe there’s a bug I haven’t found. There is a tipping point: If the plan recognizer is wrong often enough, it will make Steamhammer’s play systematically worse, and it will take more than 5 games of match play to overcome that.

#7 Killerbot by Marian Devecka lost to #10 Tscmoo protoss in the round robin, and may keep losing. I think #8 Bereaver, not updated, should be at a disadvantage to #9 Microwave. This pairing system benefits the top scorers, but also grants a relative edge to bots finishing just below the middle, who are paired against comparatively easy opponents.

Beyond the round of 16, I don’t want to forecast. Knockout tournaments by design are sensitive to every result, so mistakes compound quickly. I think you need a full Monte Carlo analysis to estimate probabilities.

I predicted that Steamhammer would score 4-3 in its last 7 games. Its actual score was 5-2. I made my prediction by individually estimating the probability of winning each game, and simply adding up the probabilities. Steamhammer was slightly lucky to win against Iron, which I gave a probability of 0.4 based on test games.

It looks as though SAIDA and Locutus will tie for #1-#2 in this SSCAIT. SAIDA has suffered 6 losses, as few as any bot, and it has played all games so nobody can pass it. Locutus is the only other player with 6 losses, and its remaining 3 games are against weaker opponents, so it will probably finish without another loss.

Locutus scored 2-0 against SAIDA, so I’m guessing that Locutus will be assigned #1 for pairing purposes. If the same pairing system is used as last year, #1 will be paired against #16 in the round of 16, #2 against #15, and so on. The exact pairings make a big difference in a knockout tournament.

With few games left to play, places #15-#16 are likely to be a tie between Arrakhammer and XIMP by Tomas Vajda, both with 44 losses. There is a small chance that one of them might lose and bring about a tie for place #16.

I predict that Steamhammer will score 4 wins and 3 losses in its last 7 games in the SSCAIT round robin phase. Its remaining set of games has an excess of opponents that give it trouble. Let’s see how accurate I am!

Look closely at this line from the latest SSCAIT results. (I edited it slightly so the links work from my site. The formatting is of course different.)

Steamhammer (Zerg, AI_MODULE)

Jakub Trancik (Protoss, AI_MODULE)

Bot 1

2019-01-12 14:06:58

.rep / watch

It claims to describe a game between Steamhammer and Jakub Trancik, but the replay and watch links point to a game between Steamhammer and Martin Rooijackers.

I haven’t seen an error like this before. I made a brief check of nearby game results, and they looked correct. The game numbers proceed in sequence. The replay is a genuine new Steamhammer-Martin Rooijackers game and the result is correct; only the opponent name is listed incorrectly. The unofficial crosstable shows Steamhammer as 0-2 versus Martin Rooijackers and 1-1 versus Jakub Trancik, although including this game I believe the results should be 1-1 and 0-1 respectively—I see only 3 games played in these two pairings. The only other sign of error I can find is that the replay does not appear on Steamhammer's SSCAIT page. Is it a one-off error, or are there other confused game results? Does it affect pairings?

I’ll report it directly to SSCAIT.

Update: Michal Certicky reports back that it is now fixed: It was a bug in choosing the replay file, not a mislabeled game bug. See the comment.

We don’t get many tournaments of bots versus humans. I don’t think there have been any with conditions controlled well enough that we can judge how strong bots are and how they are improving: Enough human participants, of known strength, with known levels of familiarity with computer play, finishing enough games. Then hold events across years so we can compare. We have to make do with seeing how bots are improving against other bots. Here is my best idea so far for comparing strength across tournaments.

1. We need 2 tournaments, preferably round robin, that share some participants—exactly identical bots, the more the better. We can’t do it with humans, because we can’t get exactly identical people across time. Ideally the maps should be the same too. AIIDE has more games, and SSCAIT has more shared participants; either should work, but I think SSCAIT may work better for this purpose despite being short by comparison. You could also compare between AIIDE and SSCAIT, but it would not work as well. It would take extra effort to make sure you know which players are exactly identical, and the different lengths of the tournaments means each provides a different amount of evidence to support the ratings, plus you could get confusing results for learning bots.

2. Pool all the games from both tournaments and compute elo ratings. If some participants which are not identical have the same names, distinguish them somehow—Steamhammer 2017 versus Steamhammer 2018, or whatever.

3. The identical players have identical strength in both tournaments, so consider their elo ratings as fixed. For each tournament separately, compute the elo ratings of the remaining players while keeping the ratings of the identical players fixed. The fixed ratings are benchmarks that keep the elo comparison stable for the remaining players (the idea has been used before).

It’s the best way I’ve thought of to get strength comparisons across time. We can get a pretty accurate measure of how individual bots have improved—Steamhammer 2018 is this much above Steamhammer 2017. We can treat elo as a linear measure of strength (a given elo interval always represents the same win rate difference), so we can simply average together the ratings of any set of bots to compare: The top 16 are x points stronger this year, the protoss are y points stronger, the spread between best and worst has widened to....

I may do this analysis for SSCAIT once it finishes. It’s a bit elaborate, but I’m interested.

The SSCAIT round robin phase is halfway over, a good time to take stock. Plenty of places will yet change hands, but the ranks are starting to firm up. #1 SAIDA is on top with less than half the loss rate of #2 Locutus. #3 Iron and #4 PurpleWave follow, close to each other. Then comes a gap, and the rest of the possible top 16 are more closely spaced.

#3 Iron, #7 KrasioP, and #8 Skynet by Andrew Smith are performing better than I expected. Iron is still reliable at rolling up the lower end. KrasioP’s game plan of cannon push into dark templar into carriers is more effective than I anticipated—each step sets the opponent a different problem. Overall, it’s striking how much stronger the field is this year than last. #13 Bereaver and #14 Tscmoo protoss have been pushed well down the rankings. When the round robin is over, I want to do an analysis to compare the win rates of unchanged bots; SSCAIT has many more unchanged entrants than other tournaments.

#9 Steamhammer looks likely to finish at 9 or 10 (the middle of my forecast range of 7 to 13 or one slot above). Most of Steamhammer’s losses are unexpected; it’s annoying, but the same happened last year so it’s not a surprise. In upsets, #2 Locutus lost a game to #36 Ecgberht, and #3 Iron lost a game to #49 AIUR by Florian Richoux—everybody has surprise results, except for SAIDA whose only 2 losses are to high-ranked opponents. Even tail-ender #72 FergalOGrady, which fails to start most games and plays awkwardly when it does start, has a win over #25 ICEbot (though it’s a win by crash as its last buildings were being destroyed).

Getting into the top 16 of 72 bots is not easy. Most of the finalists can be predicted now, though not with certainty. Place 16, just below #15 Microwave, has high odds of changing hands; those above range from likely to nearly sure to be in the finals. Pairings in the finals have historically pitted the top finisher against the last finalist and so on toward the middle. Even once you’ve made it into the top 16, you can benefit from climbing up a place (except that climbing from 9 to 8 makes no difference).

The SSCAIT rules include 2 items about copying other bots. Here’s the first item:

The SSCAIT admins reserve the right to disqualify any bots that are implementation-wise too similar to previous entries (e.g. clones and forks) without adding anything novel / original to the table.

On the upside, it openly admits that the decision is a judgment call, and otherwise it is simple. On the downside, it offers little guidance on what counts as “too similar.” On balance, I like this rule.

The second item is listed separately and seems to have been inserted independently:

If you copy other bots or use IP/files/source code/logic/techniques etc from other bots, you must familiarize yourself with their licenses and ensure that you are not infringing their licenses. Copying other bot(s) is allowed, so long as it does not infringe their licenses and so long as you modify their logic or if you use/wrap it without modifying it and add some of your own logic on top of it, similar to how MegaBot used Skynet/Xelnaga/NUSBot in year 2017, or wrapping/modifying Randomhammer/UAlbertaBot/CommandCenter etc. If you do something like this, you must provide the source code and compilation instructions etc of the bots that you use, so that we can compile them. We decided that to foster research it is best to have the next generation of programmers stand on the shoulders of giants, rather than re-invent the wheel. We encourage authors to take code from old years of this competition and improve it. If you copy a bot, please uphold the spirit of competition and ensure you make significant modification or addition before you submit it. We don’t want multiple apparently near-identical copies of the same bot competing! Additionally, please contact the original bot (in case it has been updated at least once during the past year) author and ask them for permission to upload it.

This paragraph looks like it was partly copied from CIG rules, which were themselves partly copied from old AIIDE rules. Not all of it makes sense for SSCAIT. It gives the impression of having been dropped in without careful thought. It declares multiple rules. In more detail:

The rule about obeying licenses is good, except that borrowing a “technique” from another bot is universal. If you use MCRS, do you have to obey the license of UAlbertaBot because UAlbertaBot with SparCraft invented the technique of making Starcraft decisions by combat simulation? The technique that has been accepted as standard and used nearly everywhere? That makes no sense at all. The word “technique” without qualification is too vague to interpret; leave it out.

Next is some wording about when it’s OK to copy other bots. It’s unclear how much this is establishing a rule and how much it is providing guidelines to interpret the rule already established that something must be “original / novel.” In any case it overlaps with the first item, and if it’s worth keeping at all, part at least should be combined into that paragraph.

Then there’s a strange and awkwardly-worded rule that seems to require source code of the original bot that you wrap or modify, “so that we can compile” it. I don’t think SSCAIT does this. Am I wrong? Is anything similar to this rule enforced at all, or even understood by the organizers? It has the smell of a copy-paste error.

Finally, there is a rule about asking the author for permission. I don’t like that rule. I deliberately chose a license that does not require forks to ask permission, or even to let me know. As far as I am concerned, the license grants permission; to require anything from me is a waste of my time. Instead of this rule, I propose a suggestion to authors that they may want to consider whether to add a permission requirement to their license. Then the obey-the-license rule is all that’s needed.

ambiguous cases

Here are 3 edge cases related to Steamhammer. Maybe they can get people discussing what guidance to add to the rules.

Steamhammer 0.2 was forked from UAlbertaBot and played in SSCAIT 2016 after about 3 weeks of development. I made bug fixes and macro changes and stuff, but 3 weeks is not long enough for substantial code changes. Nevertheless, from the start Steamhammer’s strategy and game plan were very different from UAlbertaBot’s. Nobody suggested that it might be too similar, even though the tactics and micro were nearly identical.

NLPRBot is a 2017 fork of Steamhammer, and has not been updated. The link is to a blog post where the comments discuss what to do about shallow forks. It was accepted in tournaments in 2017 under the rules of the time. SSCAIT chose to accept it in 2018 too, though if today’s rules had been in effect in 2017 it probably would have been rejected then. I think that allowing it in 2018 is fair; NLPRBot plays like an old Steamhammer, differently from the current one, so it still adds variety. But it is an edge case, and there is an argument for rejecting it.

insanitybot is a recent fork of Steamhammer. It adds wraiths and minelaying skills and has other changes, but you could argue that it is a shallow fork; its play is in many ways closely similar to how Randomhammer plays terran. I think it is right to accept it into the tournament, because of the improvements and because Steamhammer doesn’t play terran except as random. But again, it is an edge case.

I am amused: As I write, Steamhammer is ranked #11 in win rate in SSCAIT. It has played 4 games against players ranked higher—and won all of them. The games are 1-0 Krasi0P (I expect the second game to also be a win), 2-0 Killerbot by Marian Devecka, and 1-0 Hao Pan (the second game could go either way). All the losses that pushed Steamhammer down to #11 were against weaker players. That’s a change from last year, when Steamhammer performed consistently and had comparatively few upsets in either direction. Some losses are caused by bugs (0-1 XIMP by Tomas Vajda) or by Steamhammer’s standard weak play (0-1 AILien), but I think the lion’s share are due to poor opening choices by the opponent model: Steamhammer is performing inconsistently because it is thinking on its own.

Current #14 LetaBot by Martin Rooijackers has a similar record: It has played 6 games against higher-ranked players and won 5 of them, including its game against Steamhammer (it happens sometimes).

Overall, I think the biggest upset so far is #50 KillAll 1-0 #2 PurpleWave. Of course the tournament is only about 1/4 over.