Bryan Weber has no fear of building a hatchery in the face of the enemy. Bryan Weber - CerkoBot by Thomas Cere has an example that I couldn’t resist. Notice the one drone calmly mining minerals in the midst of a crowd of probes and surrounded by battle.
Bryan Weber - NUS Bot has a less extreme example, merely building next to the enemy main. This hatchery did not live long, despite the lurker that hatched and defended it.
There are more.
I’ve just finished implementing AutoGasSteal, which means that Steamhammer can make its own decisions about when to steal gas. I also added random gas stealing, just because it’s easy. As I wrote in November, my main purpose is to stop the gas steal code from bitrotting like it did before; regular gas stealing in regular games will be my test suite. I doubt that stealing gas will make much difference in Steamhammer’s strength, but it’s easy to imagine that a few opponents may find themselves confounded.
There are now 4 ways to order a gas steal:
"go steal gas". If Steamhammer hasn’t started scouting yet, this also sends out the worker scout to find the enemy base.StrategyManager could decide based on scouting information.RandomGasStealRate, a probability from 0 to 1. Steamhammer will randomly choose to steal gas in that proportion of games.AutoGasSteal as true. Steamhammer will decide based on the opponent model whether to steal gas.If any of these methods orders a gas steal, Steamhammer will go steal the opponent’s gas if it can. For now, the scouting worker that will steal gas heads out at the usual time (whenever "go scout" or one of its variations comes up in the build order). I added some data so that later Steamhammer can decide based on experience when to send the gas steal worker. I would like the bot to decide gas steal timing and scout timing on its own. I’m not sure whether I’ll get to that in this version.
For the first pass, I implemented auto gas stealing in a simple way, with the UCB1 algorithm that many bots use for opening learning. It keeps data for each opponent to remember how often it has tried stealing gas and how often it has won with and without, and chooses one or the other based on the UCB values. A small amount of fictitious data whispers the lie in its ear that it has tried stealing gas a couple times and lost. That makes it reluctant to pay the cost of stealing gas unless it sees a benefit. In a later version I may switch it to a contextual bandit algorithm so it can take more information into account—the opponent model has plenty more information available.
It works for all races. Just turn it on in the configuration file. I did find one new bug in the gas steal, a rare bug when emergency reactions interfere with starting the refinery building, but that will be fixed before long.
Now I need to go run a lot of tests!
When I rewrote Steamhammer’s scouting, I tested it widely and thoroughly. I’m disappointed to find out that it still hides bugs, though the bugs only show up in a few games here and there. I’ve seen a couple games where the scouting overlord stops in an empty base, when it should continue to seek the enemy. Plus there is one other bug.
Watch the game Steamhammer-Bryan Weber on the 4 player map Roadrunner, which shows a hard-to-notice but potentially fatal scouting blunder. Bryan Weber played 5 pool while Steamhammer made a hatchery first, which could lead to a build order loss. Bryan Weber’s overlord scouted the correct base first, while Steamhammer’s went in the wrong direction. The situation is bad so far, but Steamhammer’s scouting drone has a chance to make up for it. Watch it leave the base at 2:10 in the game, quickly spot the enemy overlord, and immediately turn around and go home. It looks like the smart inference paid off! The top base was known empty, and Steamhammer calculated that only 1 of the remaining bases was a possible origin for the overlord. The enemy base has been located, so the scout drone doesn’t need to look for it but can get back to mining.
The scout overlord of course wants to see what is in the enemy base. Check its path: At the same moment that the drone turned around, the overlord changed direction from the actual enemy base toward the empty bottom base. Steamhammer drew the wrong conclusion from the enemy overlord’s position. Somehow the “can this overlord have gotten from A to B by this time?” calculation ruled out the actual base A that the overlord came from to reach point B. A minute later, Steamhammer’s zerglings also aimed for the empty base, leaving its own base defenseless.
While this nonsense was going on, Bryan Weber skipped out on a chance to win over breakfast, then a chance to win over lunch, then a chance to win over dinner. It wasn’t hungry at all and chose to wait around instead. Steamhammer won the game despite a build order disadvantage and a scouting bug because the opponent played worse.
Why are there so many bugs? The overlord position inference worked (or correctly drew no inference) in every test I threw at it.
All players have now reached at least 30 games, so the rating list and crosstable have data for all entrants. That makes today a good time for a check on prospects.
By the way, the 2016 crosstable is missing from its old URL. Did it move, or is it lost? [Update: Last year’s crosstable was and remains here. ]
The elo rating is a better estimate of the eventual ranking than the win rate, because it takes into account whether the bot has played stronger or weaker opponents. On the other hand, the win rate is up-to-date with all games included, while the elo is calculated from older cached data so it may exclude recent games (like CherryPi > McRave, which was just played). Anyway, here are the top 10 by elo.
| bot | elo | win% |
|---|---|---|
| McRave | 2245 | 92.31% |
| Marian Devecka (Killerbot) | 2240 | 90.57% |
| tscmoor | 2223 | 94.59% |
| TyrProtoss | 2216 | 85.71% |
| Steamhammer | 2214 | 89.13% |
| Martin Rooijackers (LetaBot) | 2210 | 84.09% |
| Iron | 2207 | 88.57% |
| Neo Edmund Zerg | 2206 | 82.46% |
| Tomas Vajda (XIMP) | 2204 | 77.78% |
| Bereaver | 2182 | 91.18% |
The first point to strike me is that the rankings are extremely close. There is barely a difference between a rating 0f #9 2204 and #4 2223; 20 elo points is a 53% chance to win for the higher rated opponent. The difference from the top to the bottom of this list gives #1 McRave about 3:2 odds over #10 Bereaver, far from an overwhelming advantage. With little difference measurable between players, the ranking is not stable and the final results could look entirely different in detail.
Bereaver is the bot with the biggest difference between its rank by win rate and its rank by elo. It has played weaker opponents. That probably reduces the accuracy of its ranking.
Iron surprisingly lost 3 games early and fell far back. Since then it has lost only 1 more and climbed back upward.
Steamhammer has been pretty stable over time at rank #4 plus or minus 1 (currently at #5). I predicted that it would finish in place 4 to 8, and so far I haven't seen a reason to doubt my prediction.
The CherryPi-McRave game was sad to watch. CherryPi did its usual thing, with tons of zerglings plus a few mutalisks. McRave made many high templar and idly walked them into the middle of the map to die. Not once in the game did protoss cast a storm or merge an archon. Could this be related to the last-minute binary hot-fix? Against this unit mix, protoss could have gotten away with skipping storm research and merged archons right away. Other protoss mistakes in the game gave me a feeling that McRave is easy to beat if you can just get your basics up to a good enough level.
MadMix protoss lived up to its name and went to 4 bases before its first gateway against Steamhammer. You can’t beat Steamhammer that way, but you may make a very entertaining game!
Actually it would have been a short and boring game if Steamhammer opened with one of its mass zergling openings, as it often does. But Steamhammer went macro style, with 12 hatch 13 pool (squeezing out extra drones early) aiming for hydralisks. Also Steamhammer didn’t understand that the enemy had gone overboard and should be drowned for it (it’s an easy adaptation to code but not needed because Steamhammer wins those games anyway). Zerg thought, logically enough, “That’s a lot of bases, I’d better make a ton of drones to keep up!”
Steamhammer still made enough units to keep the pressure on and repeatedly kill probes. It didn’t take many; 4 bases before gateway is amazingly reckless. Despite concentrating on drone production, zerg was never in trouble.
Finally Steamhammer reached its goal of 75 drones and army production turned on full. The fury of the swarm swept away the fragments of the protoss bases.
Against TyrProtoss, Steamhammer played the same hydralisk opening. Despite playing on its worst map and messing up its macro, Steamhammer had (as I expected) an almost adequate army and held a chance to stop the big timing attack. Instead (as I also expected) it decided to move its forces through the enemy army without fighting and lose everything for nothing—the weakness is related to paths on the map. Steamhammer still makes many fatal blunders in big army fights.
Against ZurZurZur, Steamhammer got in trouble but managed to slowly claw ahead with better decisions. This could be an instructive ZvZ to study, with mistakes all around and all through.
It occurs to me that tournaments cause a paradox of motivation. Once the tournament is underway, nothing I do affects it. I want Steamhammer to defeat its strong opponents, giving them losses so Steamhammer can pull in front. If I have to lose some games, I would prefer to lose to the weaker opponents which pose no threat of placing higher.
In development, I don’t ignore the strong opponents by any means, but I have been concentrating on building a firm foundation, getting the basics down solid. Compare: Last year, Steamhammer scored many upsets against stronger players and many losses against the lower ranks. Today it is the other way around; Steamhammer can barely touch Iron or McRave (in last year’s edition it scored an upset over Iron), and it only now and then drops a game to the bottom half. Steamhammer has gone from upset-prone to consistent. I haven’t been trying to beat the top bots, I’ve been trying to play better. I put extra effort into analyzing Steamhammer’s losses against the weakest opponents in AIIDE, for example. It’s the opposite plan from trying to beat the current #1.
Well, I don’t plan to change course. I just thought the paradox of motivation was interesting. As soon as there is nothing I can do, my goals change.
How many workers does it take to mine a gas geyser at full efficiency? All bots that I’ve seen, including Steamhammer, assume that the answer is 3. In reality, it depends on the relative positions of the geyser and the resource depot (the command center, nexus, or hatchery that you return resources to). In some base layouts, you only get full gas income with 4 workers. On a professional map, like all the SSCAIT maps, the main bases are designed to mine gas at full efficiency with 3 workers. But expansions may be different. On original Blizzard maps distributed with the game, anything goes.
Also, exceptional situations can come up. It’s fairly common for bots to manner their own gas (meaning partially block it so that workers go around the obstacle). In that case you need more workers to maintain income, unless you’re smart enough to remove the obstacle. If a spider mine is blocking a base position, Krasi0 may offset the command center instead of clearing the mine. There are other reasons to offset a resource depot; maybe you’re trying to hide a base that the enemy won’t scout. If the primary hatchery at a base is destroyed but zerg has another hatchery at the same base, mining can continue. Or you might just be long-distance mining the gas.
How is a bot to judge the number of workers? The details are complicated.
Precompute it. One way is to make a table of relative positions. Go through all the maps and find the relative positions of the gas geysers and the resource depot for each base. On pro maps, I think the total set of relative positions is not large. Or enumerate all the relative positions up to some short distance. For each possible relative position, measure the number of workers needed to fully mine the gas. At runtime, the bot can look up the number of workers to assign in the table. Maybe you can find a rule, or a rule and a small set of exceptions, to make it more compact. It should be simple and fast at runtime, but it’s rigid and it doesn’t account for exceptional situations.
Figure it out on the fly. Assign 3 workers at first. Once they’ve settled into the task, check the geyser to see whether it is idle. I haven’t looked into the details, but the check is something like: There is no worker inside and it’s not in a latency period with a worker entering or leaving. If the geyser has idle time, or has idle time above some limit, assign another worker (at least if you need the gas income). This doesn’t have the advantage of instantly doing the right thing in known cases, but it does adapt to exceptional situations.
Human players do both, of course: They know what common positions need extra workers, and they notice unusual situations that also call for more workers. For Steamhammer, I think I will eventually add the on-the-fly method. It’s not high on my list, though.
I don’t know of any bots that are smart about the number of workers needed to mine gas, but maybe there are some. AILien, for example, will use fewer workers to mine if it is short of workers, but I’ve never known it to add above 3. Can anybody enlighten me?
How is the tournament going so far? Many games remain to be played, and bots have played different numbers, so all conclusions are tentative. But we can see some trends.
The top leaders at the moment by win rate are Bereaver 15-0, McRave 21-1, Tscmoo Random 17-1, Steamhammer 20-2, and KillAll at 25-3. Bereaver is a genuine candidate for a high finish, but most likely not #1. It has played relatively few games. McRave’s one loss is to Wuli. I think McRave is now the top candidate for #1 finisher. KillAll is the biggest surprise to me.
ICEbot at 13-2 is above expectations, but has also played few games. Iron has unexpectedly lost 3 games already and stands at 16-3. I won’t be surprised if its standing rises after more games. Killerbot by Marian Devecka is at 18-3 and can be expected to finish high. Microwave at 11-3 has a higher rate of losses than I expected. I may have overestimated it, as its author MicroDK said, but it hasn’t played many games yet. Microwave does have a win over Iron thanks to wall-busting skills.
CherryPi at 17-5 may be the bot in the tournament with the most smarts. Sometimes its play looks crisp and precise, with accurate reactions. But CherryPi is also immature, as you can guess from its slightly higher rate of losses. With less experience on SSCAIT, it is not ready for everything. It collapsed in the face of the cannon contain of Juno by Yuanheng Zhu, which the strongest bots all defeat easily. (Juno, I learned, builds a cannon contain not only at its enemy’s natural, but at every enemy expansion it finds. I hadn’t seen that before, though I’ve watched many Juno games from AIIDE.) Other CherryPi losses are to AIlien and to Steamhammer in strategically similar ZvZ games: CherryPi undertook a strategy of a rush-safe opening followed by attempted zergling domination (similar in idea to the ZvZ plan of Killerbot by Marian Devecka but with a less thoroughgoing execution), while its opponents chose less-safe hatchery first openings that in fact let them win the zergling war. Trying to win without risk is risky.
CherryPi showed up with a new version not long before the tournament. It reportedly did not show its strongest builds at first: If true, I take that to be a sign of lacking confidence. If you believe that your team, with its funding and top experts, has produced a better bot than all others, then you should also believe that others will be unable to catch up or to exploit its weaknesses, certainly not in a short time. I get the impression that the CherryPi team understands that their bot is not yet solid and mature.
Hannes Bredberg at 14-5 is impressing me as much improved. It used to scatter its marines to scout then gather them to attack, which was cool but not effective. Now it keeps its marines in formation and punches much harder.
Steamhammer is scoring at the level I predicted; it is now at #4 when I gave it places 4 through 8. The win over XIMP reassures me that I probably fixed the weakness that caused the recent test version to lose to XIMP. One point that worries me is that its losses are to MegaBot2017 which is much lower ranked, and to Neo Edmund Zerg which it should beat nearly 100% of the time. Except for CherryPi and XIMP, Steamhammer has not yet played most of its strongest opposition.
As always, the results will tell us. Now I have to hurry up and post this before the results change on me!
I ran a 15 game match of this year’s tournament Steamhammer versus last year’s tournament Iron. This is a true year-over-year comparison. By comparing the 2017 SSCAIT Steamhammer versus the 2016 SSCAIT Iron, we can get a measure of how much Steamhammer has improved.
Over the course of 2017, Iron has consistently stayed well ahead of Steamhammer, fixing weaknesses before Steamhammer was able attack them properly. I think Iron has even pulled ahead a little, which is impressive because Iron is stronger and therefore harder to improve. Last year’s Iron versus last year’s Steamhammer goes to Iron with a few losses, this year’s Iron versus this year’s Steamhammer goes to Iron with maybe a couple losses, maybe none.
It turns out that Steamhammer has more than caught up with last year’s Iron. The score was 10-5, new Steamhammer over old Iron. Steamhammer won both with mutalisks (which Iron at the time thought it was ready for) and with lurkers (which old Iron was not prepared for). 2016 Iron was already tough, so it’s a good result. The result table here is from Steamhammer’s point of view.
| map | opening | w/l | notes |
|---|---|---|---|
| Benzene | OverhatchLateGas | 0 | A mass zergling opening with slow tech. It can’t touch Iron’s vulture build. |
| Destination | 4PoolSoft | 0 | Iron has zergling rushes down cold. |
| Heartbreak Ridge | 9PoolSpeed | 1 | Steamhammer struggled with the map, as it often does, but eventually won with lurkers. |
| Moon Glaive | ZvT_2HatchMuta | 1 | Smash. |
| Tau Cross | OverhatchLateGas | 0 | Bad luck for this inappropriate opening to come up a second time. Steamhammer plays it in 1% of games. |
| Andromeda | ZvT_3HatchMutaExpo | 1 | A bit of a struggle, but the mutalisks prevailed. |
| Circuit Breaker | 9PoolSpeed | 1 | Iron defended too cautiously, pulling excess SCVs, letting Steamhammer draw ahead in macro. Zerg won with lurkers. |
| Electric Circuit | ZvT_3HatchMutaExpo | 1 | Smash. |
| Empire of the Sun | OverpoolSpeed | 0 | Steamhammer got lurker tech but decided to make no lurkers. It went hydra and lost after the tank numbers built up. |
| Fighting Spirit | ZvT_3HatchMutaExpo | 1 | Smash. |
| Icarus | 2HatchLurker | 1 | Iron was not ready. Spider mines and wraiths eventually cleared the lurkers, but the command center was already lost. Mutalisks finished the game. |
| Jade | ZvT_3HatchMutaExpo | 1 | The most hard-fought game of the match. Iron held on with good turret repair and its vulture containment, but Steamhammer slid drones past the contain to take the map and eventually win with hive tech. |
| La Mancha | ZvT_2HatchMuta | 1 | Another hard fight going to hive tech. |
| Python | 3HatchLurker | 1 | Smash. |
| Roadrunner | ZvT_13Pool | 0 | One of Steamhammer’s classic openings, but objectively weaker. The initial pressure looked good but was never enough to tip Iron down the slope. |
The games were varied, especially considering that Iron plays a single strategy, and both sides got to show their strengths. Some were one-sided smashes for one player or the other.
Steamhammer was able to prevent too much damage from Iron’s standard 3 vulture runby with zerglings. Iron’s vulture micro at the time was not slick enough to keep the vultures safe from speedlings in the zerg base. Or to say it differently, Steamhammer’s micro has improved enough to nab the vultures when they get stuck on a building or take a wrong turn.
In a number of games, Steamhammer won by getting ahead of Iron in workers. When mutalisks fly in, Iron has turrets ready and works hard to keep them repaired. Steamhammer likes to pick off the repairing SCVs. It’s costly in mutalisks and reduces the immediate pressure, but zerg gets ahead in macro and can win later in the game.
Iron’s forward turrets protecting its vulture contain sometimes confused mutalisks and distracted them from what they should be doing, but I don’t think the effect was decisive in any game. Loss of drones that tried to exit through the vulture contain was a problem, though.
It was striking that old Iron did not scout the map in the middle game. If Steamhammer squeezed a drone past the vulture containment and the game continued long enough, zerg could set up additional bases that remained safe throughout. It happened in both of the hive tech games.
What do the last 2 days’ results mean? In the SSCAIT 2016 round robin phase, Steamhammer 0.2 finished tied for places 16-17, and the latest Steamhammer is stronger than its much-improved successor Steamhammer 1.0. Iron finished 5th with 89% win rate, and the latest Steamhammer is stronger. Steamhammer improved tremendously in 2017, so much that it would have likely have finished in the top 4 last year if we sent it backward in time. Where did I leave that time machine?
We’ll see how it does this year. The tide has risen all around. Still, 2018 had better watch out!
To commemorate a year’s progress, I ran a 15 game match of the latest tournament version Steamhammer 1.4a3 versus Steamhammer 1.0, which was released on 28 January 2017. A true year-over-year comparison would have been this year’s tournament Steamhammer versus last year’s tournament version, Steamhammer 0.2, but that would have been a boring blowout. Steamhammer 1.0 is good enough to put up a fight.
The score was 11-4 in favor of the latest Steamhammer. The results below are from the point of view of the new version.
| map | w/l | reason for loss |
|---|---|---|
| Benzene | 0 | abdicating the fight for air superiority |
| Destination | 1 | |
| Heartbreak Ridge | 1 | |
| Moon Glaive | 1 | |
| Tau Cross | 1 | |
| Andromeda | 0 | gross tactical blunders |
| Circuit Breaker | 0 | build order |
| Electric Circuit | 1 | |
| Empire of the Sun | 1 | |
| Fighting Spirit | 1 | |
| Icarus | 1 | |
| Jade | 1 | |
| La Mancha | 0 | stupid drone chasing |
| Python | 1 | |
| Roadrunner | 1 |
It’s interesting that there is only one build order loss. In a couple other games where new Steamhammer randomly chose an inferior build order, it managed to hold on and turn the game around with stronger play. New Steamhammer has a wider range of better openings and was more likely to get a build order win. Also interesting is that every loss was for a different reason. It means there is no One Big Flaw to fix. I have handled the worst of them; the rest is a rabble of many lesser weaknesses. It is a sign of growing maturity.
Tomorrow: A different year-over-year match.
How will the tournament go? I can’t predict the final results because they come out of an elimination phase, which is unpredictable by nature. It depends on pairings and luck. But I have some insight into the round robin phase. There are 78 participants, much more than the 45 last year, so each will play each other only once, giving the announced 6006 = 78 * 77 games. I haven’t seen it explained, but I suppose that the top 16 will go to the elimination phase, like last year.
How bots do in regular ladder play can be very different from how they will do in the tournament. The voters have a big influence. Steamhammer has been underrated lately on the ladder and will finish high in the round robin.
With Krasi0 choosing to stand out of the picture, the top favorites, of course, are Iron and McRave. Microwave has become steady and reliable and should also finish near the top; it even has a chance to finish #1, because it is not as big a target as Iron and McRave. And there are old standbys like Bereaver and like Killerbot by Marian Devecka.
Tscmoo random is being allowed to play, which I did not expect. As a random bot, it won’t be allowed into the elimination phase, but it will compete in the round robin. It was last updated in October and will probably finish out of the top ranks. But it would have had a good chance to make it into the elimination bracket if that were allowed by the rules.
CherryPi is a hard case to figure out. This version of CherryPi follows what is at heart a simple game plan: It wants to win with masses of zerglings (sometimes it falls back on winning with masses of hydralisks). It seems to have some ability to vary its plan by massing early, or saving up and massing more later. A casual watch of its games gives me the impression that it may be learning how to beat its opponents by varying its timing, but without a close study I’m not sure; maybe it’s something else. In any case, CherryPi’s initial results are mixed, with losses to weaker bots and wins against stronger ones. And in a single round robin, CherryPi won’t have any additional games to learn about opponents; it will have to rely on what it already knows.
Steamhammer I expect to finish out of the top 3 but likely between ranks 4 and 8. It should beat lower-ranked bots consistently and its only sure losses are against Iron and McRave, though of course it will lose some other games too. Microwave will probably win, but not definitely. I give Steamhammer a 75% chance against former nemesis CasiaBot because I hand-coded in a counter to CasiaBot’s hand-coded Steamhammer-countering opening. Steamhammer’s other nemesis TyrProtoss is not participating. The last couple games against Bereaver give the impression that Steamhammer can now go toe-to-toe against the protoss bot in the middle game, which it could not do before (Steamhammer won early or not at all). So the game against Bereaver is likely also a win.
New tournament version with last-minute fixes! I set to work on version 1.4 for release around the end of the tournament, and thought, “Well, what could be a better start than a bug fix?” I ended up fixing 2 bugs that could help in the tournament and have low risk of causing other problems. I changed gears, and now 1.4a3 is uploaded.
• Why does Steamhammer sometimes make a hydralisk den versus zerg, when it is explicitly coded to never make hydralisks in ZvZ? Once I realized that it only happens when the opponent went random and rolled zerg, I was able to trace the bug. It turned out that the actions are out of order: Steamhammer first makes its strategy decisions, then checks to see if the enemy race is still Unknown. So in the strategy boss’s first production round after it finds out the enemy’s race (which is usually the first round out of book), it thinks it still doesn’t know. “Hmm, better be ready for anything.” Facepalm!
• In a test game after fixing the above bug, Steamhammer skipped lair tech (in ZvZ!) and rushed to hive for ultralisks. I’ve seen that misbehavior before. It hurts badly when it happens, and the fix turned out to be trivial. A condition was miswritten with && instead of ||.
There must be dozens of play bugs that are hard to trace or even to notice because their effects are rare or subtle....
I’ve uploaded the SSCAIT 2017 tournament version of Steamhammer, which is version 1.4a2. The reason for the strange version number: I promised that release version 1.4 would have a full-up opponent model, and even if I break every other promise, I can keep that one!
Randomhammer is disabled for the tournament (it took me a minute to figure out how to create an empty zip file, since zip refuses to do it directly...). For Steamhammer, I found a number of low-cost low-risk improvements that are enough to make a difference. The new version already has a win against McRave, for the first time in a long time, so I can’t have messed up too much.
• Fixed a crashing bug in assigning units to the Recon squad after losses in the main army require the Recon squad to be downsized. The bug only affected terran, and was related to medics.
• Ranged units target arbiters with a higher priority. By the way, in the strange world according to Steamhammer, scourge are ranged units.
• Fixed a bug in recognizing worker rushes. On one map, enemy workers busy mining could be recognized as “rushing”. Still a strange world.
• A few changes to zerg to be more careful in collecting gas. Turning gas off because there’s a gas excess compared to minerals now happens using the current minerals, not current minerals minus minerals reserved for buildings, so it is more conservative. If there are idle drones, always turn gas on (might as well put them to work). If short of gas, Steamhammer adds extractors faster—it always has, but now it is a little more eager.
• Account for gas usage in planned spending. Together with the gas changes above, this improves the midgame unit mix and army size. Watchers may not notice, but to me the difference is visible.
• Be more thorough in using all larvas. Steamhammer has long had a fallback rule to make zerglings with any spare larvas. I loosened the conditions, and had it also make drones if the army is “big enough” according to an arbitrary criterion. The rule usually fires later in the game, when there are plenty of hatcheries and Steamhammer wants to make more gas units than it has gas for. The result is a bigger army, and again, I can see the difference.
• Tweaks to make guardians less often. I think Steamhammer still makes guardians too often, but it should be closer to right.
Two posts today. They’re short.
Hao Pan is a new terran bot. (“Hao Pan” is apparently a person’s name; the bot is named Halo.) I watched some games to see what it was like. Watching the first game, I thought “Wow, it can build a wall, knows how to defend it, and knows how to open and close it, and that micro looks nice.” It seemed to have excellent skills for a new bot. Watching more games, I thought “Wait, this looks a lot like Iron, except it’s losing instead of winning.” Sure enough, the description says it is derived from Iron. And the AIIDE 2017 version of Iron comes with a license that says it’s OK.
It looks as though the macro is messed up, which could explain how a bot starting from such a strong base is doing poorly so far. My feeling about Iron is that its strong play depends on fine tuning of details relative to each other. If that’s true, then Iron may be a difficult point to start from; it may be easier to make it play worse than play better. But still, the allure of starting from Iron!
Randomhammer crashed in a game! It’s the first crash since May, except for the untraceable crash. Now I know exactly what to do next.
The crash was in an interesting TvP game against cannon-bot Jakub Trancik. It’s a shame not to see how it continued. Randomhammer went with marines and Jakub Trancik decided to build its proxy cannons below the ramp, so Randomhammer (seeing the pylon with its scout) didn’t pull SCVs but waited for combat units. The first marines were not quite able to stop the cannons, and retreated out of sight up the ramp. Terran and protoss have very few strategic reactions (unlike zerg), but there is one when the bot is making infantry and meets dragoons, tanks, lurkers, or static defense: It adds tanks. It was the correct move; the unit control is clumsy and loses stuff unnecessarily, but the tanks were sieging down cannons and I was starting to think that the play was good enough.
Then CRASH! The crash is in CombatCommander::updateReconSquad() which decides what units are in the Recon squad. It is complicated for terran because there may be medics in the squad, depending on size and composition, so it’s no big surprise that there’s a bug.
To work!
Today I went for a walk in the snowy woods, setting the first footprints on some of the paths. It’s kind of how I feel about working on Steamhammer: At some points I may leave the first prints, but the path was already there. And I feel as though I still have a lot of paths to walk before I can reach wilderness.
For the tournament, I have changed my plans. Trying to hit a deadline makes my code worse and messes with my motivation. Some people thrive on deadlines; I go wrong. So instead of turning on the next opponent model feature as I had been thinking, I’ll do whatever smaller fixes and features seem likely to help. I’ll have to comment out some stuff I’ve just done, but whatever. The tournament version will be 1.4a2 (anyone who’s not confused by the version numbers needs to get back to their real work), and hopefully not long after I’ll put out release version 1.4 with opening selection controlled by the opponent model. I expect that later 1.4.x releases will add more opponent model features, because the opponent model can do many things.
The switch is partly inspired by watching Steamhammer’s 2 recent losses to XIMP by Tomas Vajda. The loss on Heartbreak Ridge I can swallow, because Steamhammer has always played particularly poorly on that map. The loss on Icarus seems to show that Steamhammer is playing worse against the carriers (though it was a long, hard-fought game and many carriers blew up). Apparently delaying the hive, though often good, in this case left Steamhammer unable to batter down bases with ultralisks, because it used all its gas making scourge. Looking closely, I see that it was short of gas in part because it turned off gas for a full minute before seeing the carriers, seemingly due to a bug. Outside of emergencies, zerg should turn off gas only if gas piles up to at least 3 times the mineral count, and here it turned off gas with 1700 minerals and 300 gas. That should be possible only if the building manager reserved a huge pile of minerals to make buildings, and didn’t reserve any gas... it seems barely possible. This is something that can be fixed by a deadline.