Starcraft AI blog

MicroDK recently suggested in comments 2 ways to alter SparCraft’s input for better results.

1. Don’t feed in uncompleted units. As written, parent UAlbertaBot and the live Steamhammer will feed SparCraft our own uncompleted units when they are in the combat circle. SparCraft doesn’t know the difference and assumes that they can fight. It’s a bug. I fixed it for the next Steamhammer by not tracking our uncompleted units in MapGrid, since we should never care. It was a waste of resources to track uncompleted units.

2. Exclude out-of-range static defense. This is not a bug, but it is an interesting idea. SparCraft predicts which side will win a battle. If you have, say, zerglings and sunkens versus zealots, SparCraft may say that zerg wins. So the zerglings confidently rush forward out of sunken range and die unnecessarily. MicroDK suggests: If the sunkens are out of range of zealots, then don’t tell SparCraft about the sunkens. The zerglings will hang back as they should, unless and until they can win on their own.

I see a lot of related misbehavior in Steamhammer, where SparCraft takes everything into account but the bot could do better by considering a more restricted part of the situation. For example, in the live Steamhammer, when mutalisks see units that they can’t beat, they retreat out of sight range, including sight range of supply depots. It would be the right behavior if the plan was to circle around and try another angle (that’s why I put it in), but instead Steamhammer sits there, unwilling to move forward and unable to see or engage anything. If it isn’t going to circle around, it ought to at least take shots at a supply depot until chased away! The mutalisks could fight better by ignoring all anti-air units that they are out of range of, not only static defense.

SparCraft accounts for all units that you tell it to, and Steamhammer tells it to include all units in a large circle. Another example of the problems this causes: Melee units which are close by air but distant by ground may be in the circle and accounted for in the simulation. Or ranged ground units which are out of range of the battle and can’t reach it soon enough to help, because the ground distance is too great (they have to go around an obstacle, or whatever). In these cases the attacker may defeat the forward forces and then retreat before the distant forces arrive, while SparCraft expects them to wait around. Then you may fight when you should retreat until your forward and rear forces join up.

I will probably implement some kind of situation pruning to help. It seems easy and likely to be effective, and some of the errors it avoids seem hard to avoid otherwise. But there is also an underlying conceptual weakness in SparCraft that I would like to solve eventually.

SparCraft answers the question “which side wipes out the other?” It is not always the question that we want answered. It is a reasonable question given UAlbertaBot’s tactical model: Draw a line from our base to theirs, move forward along the line as long as we can win, move backward along the line until we can win. But UAlbertaBot’s model is ultra-simplified and isn’t suitable for drops, or vulture raids, or mutalisk harassment, or runbys, or picking off reinforcements... or most tactical maneuvers. For all these situations, SparCraft is not a natural fit, and at best you’ll have to use it carefully to get good answers.

The underlying issue is that we want SparCraft to answer different questions in different situations. Eventually I want to have a more flexible combat predictor that can cope with more questions: “Here’s the goal, can I achieve it?” Either I will upgrade SparCraft with new goals and behaviors, or I’ll find or write another combat predictor.

1. If these units run by the enemy position, how many will survive on the other side?
2. Will this drop or raid do enough damage to pay for itself before it is destroyed?
3. Will this harassment attempt kill at least one enemy unit and get away safely? (Mutalisks keep shooting as long as the answer remains “yes”.)
4. Will the enemy be able to surround and trap this squad, or can it escape? (Should I run away or make a last stand?)

Question 4 might be too hard for SparCraft, but for 1-3 I can see how to modify it to answer the question directly. When Steamhammer’s tactics boss becomes smart enough to know what question to ask, this will move to the top of my to-do list.

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

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

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

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

game analysis

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

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

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

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

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

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

I’ve been playing with the new version of SparCraft by Dave Churchill. I made 2 Steamhammer versions which are identical except for the SparCraft version, so I can test for differences in various scenarios.

My conclusions so far:

1. The new version was not too much trouble to integrate. Throw out the old SparCraft folder, drop in the new one, tweak one Visual Studio setting since I’m using an older version, and rewrite a small amount of initialization code and calling code. There is a new SparCraft configuration file that has to go into bwapi-data/AI/. It’s not much work at all for swapping out a major component. I also removed a small amount of debugging code from SparCraft, but that wasn’t necessary.

2. Dave Churchill dubbed it “semi-stable”, and it’s true. It mostly works, but throws fairly often. I modified the try-catch in Squad to catch all exceptions, and return -1 “we lose” when SparCraft throws. Then the squads retreat, which simplifies the situation so that the errors don’t usually persist. It works well enough. Another idea would be to remember the results of the last successful run and reuse them. I didn’t try that.

3. It still doesn’t support bunkers, reavers, or carriers. That’s quite a limitation. The “let’s pretend this bunker is 5 marines” trick (or something like it) is still needed.

4. Results for battles among ground units seem about as good as before. Tests under controlled conditions would surely find differences, but I’m interested in real games first. For games which stay on the ground, the difference is smaller than I can see by eye and smaller than I can measure from game outcomes, at least so far.

5. Results for battles with air units are improved. Steamhammer with old SparCraft likes to suicide mutalisks. Steamhammer with new SparCraft will still do it, but less happily. It understands turrets and spore colonies better than before. It seems to have an advantage in straight air-to-air battles too, though that’s based on only a small number of test games.

6. Since air units have lost some of their overconfidence and retreat more often, the weakness of their retreating behavior shows more. Steamhammer has always had a tendency to string out its mutalisks due to poor retreating (and other causes), even when it should pull them into a tight knot. The new SparCraft makes it worse. The first couple mutalisks see a bunker and pull back “until reinforcements arrive,” and the reinforcements wait at home “until the outlook improves.” Fixing one weakness makes the next one starker! And it is an open question whether the cautious mutalisks will be as successful as overconfident mutalisks in harassment; they may pull back too early when they can’t win outright.

I haven’t measured the run time yet, which will be a crucial test. I hope the new version will turn out to be faster. Some day soon I will probably put up a test version on SSCAIT to see how it performs in the wide world. If I don’t hit any surprises, I may switch to the new SparCraft even if the remaining bugs don’t get fixed.

Randomhammer earned another upset, this time with protoss against Iron. The game is not too interesting, just a dark templar rush that Iron wasn’t ready for. Iron could have held by landing its barracks to close the wall until mines and turrets were done, but didn’t. Even so, it shows that Steamhammer can defeat any opponent with any race—at least occasionally when it gets lucky.

Two surprise upsets today caught my interest.

new from MadMix

The game MadMix by Oyvind Johannessen vs McRave surprised me.

McRave fell out of the top ranks a while back, but has lately been climbing back up. I’m guessing that some new subsystem was switched in a while back, and it has taken this long to work the bugs out. After a long drought and a bunch of tries, the new version of McRave notched its first recent win versus Steamhammer today (and another shortly after). I expect McRave will keep rising and return to the top 5 before long.

MadMix is brand new, but already has a big update. The initial version made most units for all races, but never researched upgrades or tech. Today’s version researches most upgrades and at least some tech, so the mix is even madder!

In MadMix versus McRave, random MadMix rolled zerg and started off with fast lurkers. McRave is much higher ranked and has a better build order, better tactics, and better micro. McRave had a vastly superior force in the early game, but for some reason chose not to engage—mistake #1. When the lurkers came out, McRave had no detection and was contained despite MadMix’s poor combat skills.

MadMix slowly expanded to many bases while McRave was contained. McRave made a robo facility but never added an observatory, so it had no detection—mistake #2. I’m sure it’s an oversight or bug and will be fixed before long. McRave still could have made a nexus at its natural, added cannons for detection, and maintained a chance to win, but instead when the protoss main mined out, McRave resorted to long distance mining—mistake #3. Even so, McRave’s macro was stronger and the protoss army remained dominant. In smaller attacks, MadMix retreated support units and unburrowed lurkers each time targets moved out of range, so the forward lurkers tended not to live long. For a lurker, staying underground and restricting your enemy’s mobility can be more important than having a target.

McRave was strangely passive this game, moving its army mostly in response to immediate threats. With zerg on many bases and protoss long distance mining, the writing was on the wall. Eventually MadMix started mass attacks and broke through to win. The picture is from shortly after MadMix’s army first became the larger one (notice the worker counts). In the upper left you can see lurkers holding an isolated protoss force at bay; for some reason, MadMix made better use of its lurkers during the breakthrough attack.

The upgrades tab shows that MadMix did a ton of upgrades this game, even overlord sight range. You can see scourge, and offscreen is a devourer, even though McRave never made an air unit. The zerg unit mix is genuinely mad. It did not make queens, which may mean that it realizes it needs to know how to use the spells first.

Maybe another update soon will see MadMix using most tech, too. In any case, MadMix is already ranked higher than Travis Shelton, the other random bot with a wide choice of units.

Randomhammer gets a win over Krasi0

Randomhammer scored an upset win over Krasi0 with a vulture drop. I knew the drops would pull some good wins.

Randomhammer (this time) sent its dropship the short way around the edge of the map to Krasi0’s base. Randomhammer’s vulture micro was disappointingly poor, but even so the drop was moderately successful; it killed few SCVs, but stopped mining for a surprisingly long time as Krasi0 cautiously backed away.You can see in the production tab that Randomhammer is expanding and adding units while Krasi0 is producing nothing.

Krasi0 may have seen the building starport just before its scout was chased away by marines. In any case, it made goliaths with a few tanks mixed in, a good counter to the air units and vultures which were the only units it had seen indications of. But Randomhammer immediately switched to tanks (it’s a hardcoded tech switch—Steamhammer’s terran and protoss strategy is ultra-simple), and expanded not once, but twice.

Krasi0 delayed its expansion and did not have enough gas to make many tanks alongside the other tech it wanted. With 3 geysers, Randomhammer had greater tank numbers and was able to push through and win despite Krasi0’s superior tactics and unit control. Knowing how to position tanks on high ground is great, but if you have 2 tanks versus 6, it’s not great enough.

Why doesn’t this version of Steamhammer ever play its 5 pool on SSCAIT? I found a bug in parsing the configuration file.

There’s a bug in parsing a strategy combo which is nested inside another strategy mix. The syntax as I intended to implement it is inconsistent, and the parsing code only partially takes that into account.

In Steamhammer as configured, the effect of the bug is that whenever it should play 4 pool or 5 pool, it plays its default 9 pool speed instead. In other words, there’s not much difference, but it does reduce the bot’s unpredictability a little. In a bot with a different configuration, the effect might be worse.

the fix

If you are using the code, the fix is to make the syntax consistent.

1. In ParseUtils::ParseConfigFile(), make this snippet of code look like this. All you have to do is change "StrategyMix" to ourRaceStr in 2 places.

			// If we have set a strategy for the current matchup, set it.
			if (strategy.HasMember(matchup) && _ParseStrategy(strategy[matchup], strategyName, mapWeightString, ourRaceStr, strategyCombos))
			{
				Config::Strategy::StrategyName = strategyName;
			}
			// Failing that, look for a strategy for the current race.
			else if (strategy.HasMember(ourRace) && _ParseStrategy(strategy[ourRace], strategyName, mapWeightString, ourRaceStr, strategyCombos))
			{
				Config::Strategy::StrategyName = strategyName;
			}

2. Make the matching change in the configuration file. Everywhere it says "StrategyMix", change it to the race of the bot at that point, like "Zerg". It’s redundant, but it’s the same syntax for strategy mixes no matter the context.

Two strange events.

let’s put the expansion right there

In a game versus Krasi0, Steamhammer decided to go three hatcheries before spawning pool. It’s a greedy opening, a sensible choice against Krasi0’s slightly less greedy opening. Of course, when you’re trying to win by greed you tend to scout late, so when it was time to place the 3rd hatchery, Steamhammer did not know where Krasi0 was. The expansion drone walked past a bunker under construction and started the hatchery in the terran natural.

Steamhammer had the good sense to cancel the morphing hatchery before it died, but still.... Opening build: Failed.

When the enemy base location is unknown, MapTools::getNextExpansion() is supposed to choose the free expansion closest to home by ground distance. It should have chosen the 6 o’clock base, not the enemy natural. It’s a bug.

wait, is this the same game again?

Steamhammer played against Microwave 2 times in the last 2 days: Yesterday’s game and today’s game. Both games were on the map La Mancha, which is a little surprising since there are 15 maps. Both games had the same positions, Steamhammer in the upper left and Microwave in the lower left. OK, it could happen sometimes. And in both games, Steamhammer played its overgas 11 pool opening, a risky opening that it is set to play just under 1% of the time.

That does not happen! This is a coincidence that should come up 1 time in 18,000, more games than Steamhammer has played. Did somebody take control of the random number generator?

Microwave was blue in both games, but Steamhammer got different colors. Whew. The games were similar, as you might expect. Microwave played overpool and was almost but not quite able to capitalize on its earlier zerglings...

... then lost to the fast mutalisks that Steamhammer got by going gas first.

A third game today between the two bots was completely different. That’s how it’s supposed to work.

Did you see the new bot MadMix by Oyvind Johannessen?

As a brand-new bot made from scratch, it has little combat skill. But it is exceptional in that it plays random and makes nearly every unit for every race. I got the impression that it didn’t make protoss archons or dark archons. It doesn’t research anything, so it can’t get units which require research: Broodlings and lurkers. It probably doesn’t know how to make infested terrans, which are complicated to get.

Those might be the only exceptions. It makes high templar, and because it never does research and doesn’t merge them into archons, they are useless. It makes tanks and doesn’t research siege mode. It makes science vessels and battlecruisers. It makes guardians. It makes carriers and 4 interceptors for each, it makes reavers. I didn’t see devourers or arbiters, likely because they didn’t happen to come up. Maybe it leaves out valkyries? It gets all the tech but I haven’t seen it make them.

It already deserves the name MadMix!

motivation

Motivation comes from having goals. It’s a long road, and you won’t get far without strong motivation.

Winning is a good goal, but a slow one to reach if you are starting from scratch. People who want early progress often start with a rushbot, which can easily stall an author from improving. Another try for early progress is mass static defense (with some kind of followup), like Johan Kayser. Personally, I expect that authors who can accept slow early progress are more likely to stick with it over the long haul.

Being unique in some way, like MadMix, is a good goal. The bot’s description says “The goal is to find an entertaining mix of units, strategies and madness.”

Providing an inspiring example of a strategy or style of play is a goal that doesn’t demand a long-term commitment. ZerGreenBot raised the level of play of top protoss bots by pioneering potential field-controlled reaver drops, overlord hunting with corsairs, and forge expand build orders, inspiring imitation. Other bots have still not caught up with ZerGreenBot’s zealot bombs, which made IceBot look like a beginner.

All kinds of goals exist. Your goals provide your motivation whether or not you know what they are, but it may help to know.

I rather like Arrakhammer. It quickly differentiated itself from its parent Steamhammer and now plays quite differently. And its strategies are logical.

Look how Arrakhammer defeats Wuli: It holds off the raging zealots with mass sunkens and no units, objectively poor but perfect against Wuli. Then it techs up to hydra-lurker. Wuli is unable to cope with the lurkers and falls over.

XIMP by Tomas Vajda follows the same abstract plan of holding off the enemy with mass static defense and following up with tech units that the opponent cannot cope with. Some similar plan probably works against most non-adaptive bots (it might fail against bots which always make tanks or other siege units). The plan seems so general and effective that I’ve been thinking of coding it into Steamhammer as a use of opponent modeling. When Steamhammer realizes from experience that the enemy bot has a fixed unit mix, it may build mass static defense while it techs up to a countering unit mix.

overhatch versus overhatch

Arrakhammer is based on the previous, 1.2.2, version of Steamhammer, which did not have the overhatch opening yet. But the author has not been shy about looking into the newer 1.2.3 version. Here in Arrakhammer versus Steamhammer on Icarus, Arrakhammer borrows the overhatch opening and tries to tweak it for an advantage over Steamhammer’s variant of the opening.

The openings are identical up to supply 15. Steamhammer spent its first 100 gas on zergling speed, since it was playing a zergling opening. Arrakhammer instead started a lair and added a sunken to hold the zergling pressure. It’s not the natural way to play the opening, but it is a logical attempt to cross up an opponent that is committed to zerglings.

The plan commits Arrakhammer to defense until mutalisks come out, so it brought its zerglings home even before the sunken was started. Steamhammer had made 2 zerglings more (which didn’t matter because they were far away) and Arrakhammer lost 3 as they retreated up the ramp (which did matter). Unfortunately, Arrakhammer defended inaccurately and lost 2 drones, a severe loss. You can see the orange zerglings out of position in the picture. Good defense could have saved all drones.

Play was left, but in the next zergling attack Arrakhammer pulled drones too far from the mineral line (a classic Steamhammer blunder) and lost 5 more. After that it was irrecoverable. A picture of the drone blood:

The opening try was logical and it could have won if Steamhammer had made the mistakes, or had chosen an inappropriate build. Its weakness was that it depended on correct defense. Bots are strong in attack and weak in defense; that is why Steamhammer is aggressive whenever possible. As defense grows stronger, a wider range of strategies will become practical.

Steamhammer repeatedly threw away zerglings trying to approach the sunken and made other mistakes, but its advantage was unbreakable and it finally won by getting mutalisks first.

As some people have noticed, Steamhammer’s “secret weapon” ZvZ opening, which when I first tested it scored overwhelmingly against all opponents including Steamhammer itself, is simply overhatch.

Overhatch means making up to 9 drones, spawning an overlord, and then starting a hatchery while still on 9 supply. Steamhammer’s version is overhatch 9 pool 9 gas (with drones in between buildings), parallel to its faster 9 hatch 9 pool 9 gas build. The overlord lets zerg get in a couple extra drones, so that when the spawning pool finishes the bot has 10 drones and can immediately spawn 8 zerglings. The timing is fast enough to hold off 5 pool except on 2-player maps. It puts the player in a reasonable economic position (by ZvZ standards), but also commits to zergling-heavy play because the lair will be later.

Overhatch is a rare opening and it is not written up on Liquipedia, and that is for a good reason: It is dominated by 10 hatch. In a ZvZ 10 hatch opening, you go up to 9 drones, spawn an overlord, and do the extractor trick to get a 10th drone. The 10th drone can mine for a while before minerals are available to morph the hatchery, so 10 hatch is always ahead of overhatch in minerals. There is no disadvantage to 10 hatch; it can only be better than overhatch (though only by a little). Steamhammer plays overhatch because it still does not work around the extractor bug (I have more important bugs to fix first).

results

The opening is strong against bots. Results on the SSCAIT server have been good, though less convincing than my original tests.

Steamhammer has lost several games by failing to build an extractor when it came up in the build order. It is a bug that I didn’t see in testing and haven’t solved. For some reason it hits overhatch much more often than other builds.

Steamhammer has also lost a game to Microwave’s 9 pool and another to Dawid Loranc’s 5 pool. Steamhammer’s zerglings were in time to defend with correct play, but Steamhammer pulled its drones too soon and lost some. It’s a severe defensive error. At some point I will teach Steamhammer how to defend with a drill, and then these losses won’t happen.

Steamhammer has also lost occasional games to strong opponents like Killerbot by Marian Devecka due to tactical errors. It does win most, though, even against opponents like Arrakhammer that know about the overhatch opening and are prepared to meet it.

counters

Like every opening, overhatch can be countered provided you know it is coming: You can safely open 12 hatch to end up equal in hatcheries, ahead in economy, and behind in nothing important. So Steamhammer doesn’t play overhatch every game. Steamhammer is set to play overhatch in half of games. Its other openings counter 12 hatch, which is a slow and risky opening in ZvZ. The random openings ensure that no opponent build can give a sure win; opponents have to either play better or get lucky.

If you want to counter overhatch safely, Liquipedia suggests that 12 pool gives a slight advantage. 12 pool is a safe ZvZ opening if played well. But I learned by experience that it is tough to teach a bot to play it well.

other matchups

The classic use of 10 hatch is in ZvP, where in old days it was considered a strong counter to 2 gate zealot play. 2 gate play is popular with protoss bots, so I tried overhatch against protoss too. It seems effective. I think it is doing better than overpool, which was already successful.

In ZvT, Steamhammer up through the current version has always played either zergling openings with heavy early pressure, or mutalisk openings with minimal zerglings and a heavy air attack. Thinking it through again after working on surviving early terran attacks, I decided to add a compromise opening for the next version. I picked an overhatch opening with early zergling pressure followed by a later, lighter air attack, at the cost of a weaker economy in the long run. I think it is objectively worse, but other zerg bots have been successful with similar approaches and it may work well against bots. It’s an idea that should be tried.

Tomorrow: Arrakhammer’s attempt to counter overhatch

Progress has been delayed by exhausting events in some kind of “real world” that I don’t fully understand. But whatever, it’s only a temporary distraction. A public repository should be up soon-ish; I have made some decisions but not all.

After that I will be, as anyone could have guessed, splitting versions again. I was planning for the next version 1.2.4 to be a mass bug fix release, but with the new SparCraft out, that doesn’t seem like the best plan.

• 1.2.4 - I’ll try the new SparCraft and incorporate it if it seems like an improvement. I expect it to be. Besides that, I plan to work on about a half dozen of the most critical bugs and weaknesses.

• 1.2.5 - Fix as many of the remaining bugs as possible. My list is way longer than I can get through.

• 1.3 - Start on opponent modeling.

I promised some form of opening learning or other opponent modeling for CIG 2016, and it is coming up fast. I have to get onto that soon and delay mutalisk work yet again. I regret the delay, because mutalisk micro is a key zerg skill and all bots are clumsy at it. When I finally get it implemented, terran bot authors in particular will be dismayed to see how hard mutalisks can hit when they are Less Stupid. But opponent modeling is also key.

I have already implemented a couple of fixes to regrouping. I corrected a conceptual error in weapon ranges versus ground distances. It remedies one case of mutalisks holding their position while under enemy fire, as well as less visible but related misbehavior. Also medics retreat with their squad when they should, instead of staying behind to “hold off the enemy while you escape.”

If I ever want to finish ahead of tscmoo in a tournament, zerg will have to learn how to survive terran early pressure. To make testing easier, I added a terran BBS opening. Like Tyr’s, it defeats Steamhammer’s mutalisk openings 100% of the time. So far, my attempts to react to it are too slow and zerg still loses. The BBS is so effective that I could not resist adding a “go pull workers” command to pull SCVs into the combat squad and make it even more vicious. Now it is easy to write all-in strategies like Oleg Ostroumov’s marine-SCV attack, or the zealot-probe all-in that Pinfel used to play.

Here’s a curious point about Steamhammer’s ZvT and Tyr by Simon Prins. Tyr has opening learning, and center map BBS is its answer to bots which don’t defend themselves early. The BBS has always beaten Steamhammer’s mutalisk builds and lost to its zergling builds.

In the past, Tyr has tried BBS against Steamhammer and given it up after a while after losing; it concluded that a regular opening was better. Past Steamhammer versions played zergling openings 25% of the time, which was apparently enough to deter BBS even though Tyr’s slower play didn’t consistently win 75% of the time (it varied by version).

This Steamhammer version plays zergling openings ZvT 20% of the time, because the mutalisk openings are improved more (that was my thinking, at least). Tyr apparently detected the shift in game results, and now it plays BBS every game and wins 4 out of 5, a huge upswing. Can improved play can lead to worse results when it highlights remaining weaknesses for the opponent’s learning to exploit? It could also be because Tyr was updated recently. Or it could be a chance change due to the interaction of opening learning, random choice of builds by Steamhammer, and historical changes in Steamhammer’s performance.

To fix the weakness I thought of a simple adaptation, and I hope to try it out in an upcoming version. Steamhammer is prepared for early pressure versus zerg or protoss opponents, but against terran it tries to exploit the tendency of most terran bots to sit back and macro for a while. So it only has to adapt in the case of early marine pressure, as played by Tyr (with BBS) and the latest tscmoo (with an academy rush) and a number of weaker marine bots like Kruecke and KaonBot. Steamhammer should have better chances to survive if it breaks out of its prepared build when it recognizes the early pressure, and lets the strategy boss do its default thing. I doubt my simple idea is good enough by itself for all cases, but I’ll try it.

I heard back from the CIG 2017 organizers. They wrote that the contest will support BWAPI 4.2.0 “if there’s no special issue,” and that details will be announced later.

So: They haven’t decided for sure. I expect that there will be no issues and they’ll adopt it, but the decision is not set in stone.

In my experience, most academics are extremely busy, which is not ideal since good scholarship calls for time and concentration. I think the CIG organizers are no different.

The new Steamhammer 1.2.3 zerg plays slightly but distinctly better than the previous version. It’s worse on some points, like focussing the attention of its mutalisks, but better on enough others to make up for it. The overall result is a small but clear bump up.

The new Randomhammer plays worse than the test version of Randomhammer, and I don’t know why. Apparently I did something harmful in the last week of development, and I can’t figure out what. I worked through the list of items I changed that week, and I don’t see a problem with any of them. But there must be one. Has anybody noticed something?

It’s possible that the unknown problem affects zerg too, and zerg could be even stronger if I fixed it.

Some people would spend no more than 10 minutes to bring up a public repository, but I’m taking my time. I am a long-time darcs user for my personal projects and don’t know git. A public repo today should be a git repo, today’s standard, not a version system with beautiful theory and ugly popularity. I want to get up to speed.

On the side, I’m thinking about the large number of skills that bots want to know and I’m trying to figure out how to fit them into the smallest amount of code. I noticed that a lot of spells share similar structures and should share code.

All the spells I list below can share backbone code which is at least partially data driven. I’m imagining something like this for each spellcasting unit:

1. Does it have the energy and tech to cast?
2. Is some suitable target nearby?
3. Find the best target, taking into account the whole situation including any maneuvering needed to get into position first.
4. If the best target is not good enough, no spellcasting action. Carry on as usual.
5. If we’re too far away, move toward the position.
6. We’re in position. Cast.

Each spell would need its own evaluator code “how good is this potential target?” It looks to me as though everything else that differs between them can be kept in a table of data and the rest of the code can be shared. Unless I get a better idea, I expect I’ll implement this eventually and suddenly support a large number of spells.

All of the spells below, but I’m thinking especially of hallucinate and dark swarm, benefit strongly from tactical coordination. That can be made to fit the framework. The tactics boss could decree things like “broodling if it’s an emergency, otherwise hold on until we can make a coordinated attack” simply by adjusting the “it’s good enough” threshold value. But even uncoordinated spells, which is all that most bots ever implement, would be fun and would pose problems to the opponent.

Consume and recall may fit a little awkwardly into the framework. They both depend on prepared units standing ready. But even they seem doable.

target is a unit

• optical flare
• restoration
• defensive matrix
• irradiate
• lockdown
• yamato cannon
• hallucinate
• feedback
• mind control
• parasite
• broodling
• consume

target is an area

• EMP
• nuke
• psionic storm
• maelstrom
• disruption web
• stasis
• recall
• ensnare
• dark swarm
• plague

BWAPI 4.2.0 was released on 28 April. I have been thinking about when I want to switch over to it, and I haven’t decided.

Sooner? 4.2.0 fixes the zerg hive research bug, which pinches zerg strategy. The hive bug is nasty, so that counts for a lot. Code changes to switch to 4.2.0 seem minimal; I would want to revise the bits of the zerg strategy boss which encode the buggy tech tree. Dave Churchill has already switched UAlbertaBot over, so any problems should be minor. 4.2.0 supports Visual Studio 2017, so people wouldn’t suffer from old development tools. And of course there are various other improvements and fixes, and it’s common sense to stay as up to date as possible.

Later? Will competitions support 4.2.0? I wrote to the CIG 2017 competition organizers to see whether it would be supported in their tournament. The lead time may be short for them. We’ll see what they say. Also, given my development plans (fix bugs, work on mutalisks and opponent modeling), switching libraries would be overhead that slows me down for the moment. I’m not looking forward to switching to a new toolset when I’m still getting used to the one I’m using.

What do you think? Anybody have thoughts or experience?

Update: As Ailien points out in a comment, if you use BWTA you have to update it at the same time, and no new BWTA release is out yet. All DLLs have to be compiled with the same toolchain, per Microsoft. It may work if you compile BWTA yourself from source with vs2017 (no promises, I haven’t tried it). For BWEM, Igor Dimitrijevic suggests integrating it into your source code directly. If you did that, then it presumably does not have the same issue (I didn’t see any map-related changes in the BWAPI change list).