The CoG 2021 website is updated today with “accept joining PurpleWave,” though the Result page is updated only with a note, not in the picture showing the list of entrants. As expected, PurpleWave is officially in, and now they say so. Good!
Steamhammer understands that plaguing an archon doesn’t do much good. An archon has 350 shield points and only 10 hit points, and plague affects hit points only. But put enough archons together, and Steamhammer may calculate that it’s worth it anyway.
Steamhammer intentionally errs on the side of excess plague. Plague on 6 archons destroys at most 6 * (10 - 1) HP, only 54. It’s questionable whether that’s enough to pay for the 3 zerglings the defiler consumed (the lings have the adrenal upgrade and do damage fast, but then again, they’ll die almost instantly against mass archons so maybe they weren’t worth much). Dark swarm might have been a better choice, but I don’t mind. As I said, it’s intentional, and anyway, Steamhammer was losing this game no matter what.
In this game versus Krasi0 on BASIL, Steamhammer selected an unsafe ZvP build. Almost all ZvT builds come with a lair pretty early; the exceptions that come to mind are rushes. This was a multiple-hatch-before-pool into 6 hatch hydra build with a late lair, sensible against sufficiently slow protoss play, senseless against typical terran barracks play. Somehow Krasi0 steered right into it, starting with its thou-shalt-not-rush-me ramp bunker and continuing with goliaths. Hydras are strong against goliaths.
Both bots have a lot to learn about strategy.
Steamhammer-Joon is a funny game played today on SCHNAIL. (The player’s screen name is ZI7HMI and the game time was 21-06-30 08:48:50.) Steamhammer had played this opponent once before and correctly predicted cheese, so it started with 9 pool and a sunken in its main. Joon, being a crafty human rather than a bot, crossed this plan up by bunkering the natural below the ramp. At the time of this picture, the first terran barracks had lifted because it had started to burn, and the initial zerglings that escaped before the bunker were attacking SCVs.
Zerg was mining with more workers than terran, but was contained to its base—and terran sent most of the pulled SCVs back home, putting the human ahead in economy. Steamhammer kept sacrificing drones to the bunkers as it tried to expand (it’s on my list to fix soon with safe pathfinding), and losing overlords for lack of understanding of enemy visibility. But it also got lurkers, and terran was only just adding comsats. After a sharp struggle whose outcome looked uncertain at first, zerg broke its own natural—where terran had built a command center—and forced buildings to lift.
Now terran was far ahead in economy though with hands too slow to spend it, while zerg was ahead in army. Notice that terran is adding a starport while zerg is getting a spire. The zerg force, finding no buildings on the ground and unable to attack air, hurried across the map to the terran side. Immediately, Joon landed the buildings again, so that the drone which came down to expand could not take the natural but had to continue to another base to expand. Having crossed the map, lurkers forced the terran natural into the air and continued on to pillage the main, while terran quickly trained marines in the zerg natural and easily held it, restoring the containment—but with zerg already owning a base outside it.
In the picture you can see 2 vultures and a wraith, which proved of little value. Steamhammer scourged the wraith and a followup wraith (you can see the scourge in the production tab). At the opposite corner of the map, terran marines were supreme and Steamhammer chose a mutalisk switch, which was also of little value. The strategic situation completely reversed in a short time, with zerg ahead in economy and terran stronger in army. Steamhammer had taken the top center base, but was not mining there.
Steamhammer killed all SCVs in the terran main, left 1 lurker there to finish cleaning up, and returned the other 3 to visit the terran complex at the zerg natural. At the same time, the strong terran infantry easily broke the sunken in the zerg main, which had been waiting there since the early opening, and set about their own cleanup. Base race!
A crazy game, and a close one. Both players had opportunities to turn events in their favor at multiple points. I won’t spoil the end, though it’s predictable if you know how terran-zerg base races go. You can watch it to see.
The registered competitors for CoG 2021 were announced a few days ago on the results page. The submission deadline is not until 25 July.
Here are the new entrants. I sorted them in order of their current BASIL rank, which is a fair guess at how the tournament may work out.
As I write, BananaBrain and Stardust are rated identically on BASIL, at 3068 elo. BananaBrain has fallen a bit; recently it was higher. I think it is likely that Stardust will get a tournament update, since it hasn’t had a public update in half a year. BananaBrain has had frequent updates and is closer to current. If so, then Stardust remains the favorite to hold its #1 finish. But BananaBrain has improved a lot, and tournaments are decided by results, not predictions! CUNYbot is the baby here, rated about 200 elo lower than McRave zerg. But it also has gone a long time without updates, and I don’t expect it to play without a tournament update—plus it showed strong improvement before updates paused. It may be able to hold itself off the floor.
Granite is a new name. CoG does not list authors or any other info, so I know nothing more about it. Historically, new names are often disappointing, but occasionally one is great. I have hope.
Here are the carryovers. PurpleWave is last year’s version (I expect that Purple Dan is not satisfied with progress). The others are being carried over for the second year. I sorted these by their finish in CoG 2020.
That makes 6 protoss, 3 zerg, and 1 meager terran (the same lonely terran as last year), and the terran scored only 37% in last year’s tournament. The race balance is lopsided. XiaoYi and MetaBot are likely to end up as punching bags that stronger bots try to score almost perfectly against.
Last year, 8 bots competed. This year, 10 bots are expected. But one constant has been that not all registrants end up submitting an acceptable bot—last year also had 10 bots expected, and 2 dropped out. Maybe this year will be better?
In TvZ, sometimes terran stops marine production and goes with factory units (maybe with starport units), whether early in the game to play a straight mech strategy or later to switch to it. Usually terran lifts the barracks to get it or them out of the way. If you see a lifted barracks, that’s a clue to the enemy strategy. Seeing vultures or goliaths appear may be your first clue, but unavailable barracks say that marine production is stopped (or at least slowed), so it’s a stronger clue. It rules out marine-tank unit mixes.
I think human players can usually read the clue correctly, when they need to. Bot opponents go marine-tank often, so it may be a useful clue for bots. But it seems a little tricky to read with assurance. You can’t just say, “overlord spotted a lifted barracks, cancel lurkers,” you need to look at more context. Maybe terran is only rearranging their base, or moving the barracks to a blocking position for the sim city. (Though if it’s in a blocking position, you may see whether it is making units.) Even a floating barracks far from the terran base may be intended to land as a proxy, maybe making a couple firebats to toast some drones.
Maybe bots should take a graded approach. Early in the game, terran should have only 1 or 2 barracks. Seeing a barracks in the air is a big deal, and the longer it floats or otherwise produces nothing, the more sure you can be that infantry is deemphasized. Later in the game you should have a rough idea how many barracks terran may have tucked out of sight, or at least how many barracks the terran’s bases can support. The more flying barracks you see, the more confidence you should have that fresh marines will be few.
At least that’s what I would start with if I were coding it by hand. My plan is to draw inferences like that largely by machine learning.
Here’s a fun SCHNAIL game, Steamhammer-HitHat (screen name Joongwan). Steamhammer had played this opponent before, so it had an idea of what to expect and made an early sunken. The sunken is misplaced. The misplacement is better against other bots than correct placement, but you’ll see in the game why I call it a misplacement! After learning by the loser, the next game went differently. Another interesting game is this one on Fighting Spirit against a different opponent.
I’m not sure why there are separate screen names and game names. The website comes with an API that gives the screen name with replay, and the replay has the game name, so no information is hidden. Still, people use the feature a lot, so it must have appeal. Are names that much fun? I’m guessing it was a feature added at the request of players. I sure wouldn’t have thought of it.
Steamhammer 3.5.1 is progressing, though slowly. Since my energy ran down, I stopped working on my plan of using Steamhammer’s new opening data. After seeing many SCHNAIL games, I’m mostly making changes to improve Steamhammer’s play against humans. Humans know a lot of tricks that bots don’t know, and they’ve uncovered weaknesses that I want to fix. Better is better, even when it may not show against bot opponents.
I rewrote Steamhammer’s crufty old code for deciding when, and in what bases, to place sunkens and spores. Unlike bots, humans are quite good at attacking vulnerable bases first. (Steamhammer makes an attempt to get this right. Most bots don’t try.) I was running the first tests, demonstrating that it worked in a couple of simple situations, when I realized that I should have generalized it for all races. Terran and protoss desperately need the skills: Make mutas and win because terran doesn’t add turrets; make DTs and win because only one base gets turrets or cannons for detection. I’m not only working slowly, I’m thinking slowly.... I rearchitected it and rewrote nearly all the code a second time, in a new StaticDefense class. It’s cleaner and more capable, and should be easier to adjust. It’s just now ready to get back to testing.
Humans make very different opening choices than bots. Most stick with general-purpose safe openings; a few specialize in cheese. I don’t have any way to collect SCHNAIL opening data, so I started a new file to hand-write an anti-human configuration. I didn’t fill in much of it yet, but I’ll get to it.
I expect my tweaks and new features to help somewhat on SCHNAIL and a tiny bit on BASIL. But we’ll see.
My energy is low, but I’m still working on Steamhammer and checking out games. Crazyhammer is Steamhammer configured to choose purely at random from its library of over 200 zerg openings. It plays only on SCHNAIL, and only practice games, because it’s just for fun.
Crazyhammer doesn’t get many games, and it loses a lot because its builds are often hilariously inappropriate. As you’d expect! Today Crazyhammer played a fun game against terran TeChRapy on Fighting Spirit. Crazyhammer randomly chose its queen rush build, which will happen about 0.45% of the time—this is the first time I’ve seen Crazyhammer play it in a real game, though Steamhammer did give it a try versus Stardust in AIIDE 2020.
In the queen rush, Steamhammer makes 6 queens early on and researches broodling. It’s hard to think of an opponent plan that it counters. I don’t have the strength to take pictures and do the blow-by-blow, but here are a few points you might like to notice.
• Watch the swoopy way the queens fly around. It was the simplest idea I thought of to keep the queens apart so that they don’t often select the same target. It didn’t work this game! At about 9:30, 4 queens simultaneously and from different sides ensnared the same group of marines. I should bite the bullet and implement proper spell target tracking.
• Techrapy went with multiple barracks, no tanks. Nothing was worth a broodling, and the queens were useless at first.
• Crazyhammer reacted by researching ensnare and adding lurkers, both useful against marines. Techrapy got tanks against the lurkers, and then the queens had a broodling target.
• The queens sucked at staying safe. One of the 4 ensnaring queens retreated forward instead of backward, and got shot down. Later, 2 queens in a row flew into turret range and died trying to snipe the same tank.
• On the upside, the fast queen’s nest meant that the hive was not too slow. Defilers helped.
In the following game, Crazyhammer started with 8 hatchery 7 pool, and Techrapy won easily. Terrans at this level usually play a barracks-expand build which is safe against zergling openings, given scouting and a few easy reactions. Certainly safe facing Steamhammer’s level. In the queen game, maybe Techrapy was confused and made overcautious by the “unconventional” (aka bizarre) build.
Queens showed poorly this game, but I’ve been surprised how often they are successful. When terran turtles hard, Steamhammer’s queens can be as valuable as its defilers in breaking the shell. Knowing that queens are in play tends to make terrans spend on air defense and move around more slowly and cautiously. And I know what I need to do to make them more effective.
In 2017, I posted breaking scouting assumptions about a crazy trick terran can play: Lift off the initial command center and land it elsewhere, so that the opponent does not scout you at any starting base.
Today will go down in history, because somebody played this trick versus Steamhammer on SCHNAIL.
The game is LiberTY_ vs Steamhammer on Fighting Spirit, at 21-05-19 08:40:04 in SCHNAIL server time. Let the timestamp be forever honored in memory. Some background: Liberty (under a couple of related names) has played many practice games against Steamhammer, having some trouble at first but steadily improving and now winning nearly all games. This is someone who has learned Steamhammer’s weaknesses and has exploited them with increasing efficiency. Maybe the game was to accept a handicap and make Steamhammer a serious challenge again. Or maybe it was just a fun try to see if the bot would do something silly in the silly situation.
Liberty started in the bottom left. Here the command center is approaching to land in the bottom middle base. See the worker counts—lifting off your base interrupts mining for a long time in the critical early game, so it is a severe setback. Terran has no chance unless the trick breaks Steamhammer somehow. Steamhammer’s overlord is only halfway across the top of the map on its scouting trip, so it would have been possible to lift off later, losing less ground. A little less.
Steamhammer scouted the bottom right base last, so it believed that was Liberty’s start base. The drone scouted it thoroughly, over and over, even after finding it empty.
Wasting time with the scout drone was Steamhammer’s only real misreaction to the trick. The scout manager does not update its idea of what location needs scouting merely because the location is empty, but the information manager understands that no enemy base has been found. The initial 6 zerglings set about scouting the map for the terran buildings that must exist, checking base locations first (including bases that were already scouted). At about 5:30, a watch squad zergling arrived to keep a watch on the empty enemy “main”, and the scout drone could return home. By coincidence, at the same time, the now more numerous lings found the terran encampment and did some damage.
This was not a scouting squad, it was a combat squad, and it was only scouting because it hadn’t found a place to attack. The lings had speed and there were only 4 marines. The game could have been over right there, but Steamhammer controlled its units poorly (in part because of crummy code trying to join clusters that became separated), and terran suffered only moderately.
But zerg had made no fatal mistakes and was too far ahead. With little room on the tiny mesa for ground production, Liberty chose wraiths. The first 2 wraiths arrived at a zerg base and were scourged before they could do damage. Soon the wraiths did better with cloak, but paper airplanes were not going to stop any zerg army for long.
Steamhammer’s reaction was about as good as I expected, and easily good enough. Does your bot survive this crazy trick? Probably! The only critical skill is the ability to notice that an enemy base is not where you “knew” it was, and you need that skill in case an enemy command center lifts off or burns down, which can happen in a normal game.
The number of games on SCHNAIL exploded recently. I assume it’s related to the new SCHNAIL stream showing random replays of past games. Is there another source of publicity that I didn’t notice?
Nice job, Sonko and Bytekeeper! I especially like the viewpoint switching and the treatment of fog of war in the replay viewer. Of course, it is a universal constant that there is room for improvement. I wonder: Are new viewers able to tell the bot player from the human player? I can tell easily, but I already know all the bot names.
I learned a new trick from watching the ASL 11 games. The game was Sharp versus Best, the second game of group B in the round of 16. Watch with English commentary by Nyoken and Scan on Afreeca or on Youtube. On the Afreeca vod, the game starts a little after 55 minutes in. The Youtube vod was trimmed and it starts closer to 46 minutes.
Sharp scouted Best’s base with an SCV, which then left the base. Best blocked the entrance to his main with a zealot to prevent further scouting. But when the SCV returned for a second look, it mineral-walked through Best’s blocking zealot and got a look around anyway. I was surprised, and Nyoken (who knows more about Starcraft than I do) was also surprised: How did the SCV get vision of Best’s minerals to do the mineral walk? Sharp had no apparent way to see the minerals.
Scan explained it. The SCV was click-moved to a location far from the base (a location chosen so that the second-scout timing would come out right). As it was leaving, while it still had vision of the minerals, Sharp shift-clicked back to the minerals. That was the last time Sharp had the necessary vision. The SCV followed its orders to move far away, then followed the queued order to mineral walk back into the base. I had never seen it before.
I sometimes see bots using queued commands to move units across the map through waypoints. (In BWAPI you do that by setting the optional shiftQueueCommand parameter of a command to true; it defaults to false.) It is usually a mistake. When you queue a move command, the moving unit completes the command by coming to a stop at the destination before the next command in the queue executes. It adds a delay—a very visible delay. If you’re following waypoints, it is normally better to issue a new move command in real time before the unit reaches the waypoint, so that it never slows down or stops, and reaches its final destination sooner. But in the case of mineral walk, you may not still have vision of the minerals later when it’s time to issue that command. If you want to issue a sequence of moves ending with a mineral walk, you may want to queue them all while you still have vision. It will execute later whether you have vision then or not.
I tried it myself, and it works. What a complicated game!
It’s been a while since my last post, but I’m still working, however slowly.
In today’s SSCAIT report “By the skin of your teeth”, the last game of the broadcast is the same game I analyzed last month, Chobo-Steamhammer on Python, the corsair-reaver game, with commentary by the player himself. His analysis of the game seems similar to mine, except of course with insight into the human player’s thoughts rather than the machine’s.
AIST S4 results are published. Despite my optimism, Steamhammer scored 0-2 in its first match then 0-2 in the loser’s bracket to be the first knocked out, as in the past. In fact, it is the worst result ever; in its other two tries, Steamhammer scored 1-4 rather than 0-4 as here.
Here are the results in crosstable form, counting games, players in rank order. The tournament counted matches, not games, so you can’t directly read off the tournament results from here. But it may give a different perspective.
| # | bot | overall | star | purp | will | drag | bana | stea |
|---|---|---|---|---|---|---|---|---|
| 1 | stardust | 7-2 | 5-1 | * | * | 2-1 | * | |
| 2 | purplewave | 7-6 | 1-5 | 4-0 | 2-1 | * | * | |
| 3 | willyt | 4-5 | * | 0-4 | 2-1 | * | 2-0 | |
| 4 | dragon | 4-5 | * | 1-2 | 1-2 | 2-1 | * | |
| 5 | bananabrain | 4-4 | 1-2 | * | * | 1-2 | 2-0 | |
| 6 | steamhammer | 0-4 | * | * | 0-2 | * | 0-2 |
I watched the replays. PurpleWave 2-1 Dragon after Dragon crashed twice; the first game was a convincing win by Dragon. Again versus WillyT, Dragon won once and crashed twice. PurpleWave tried to counter Stardust with reavers, but suffered when bottlenecked at ramps. If you want the best games, I recommend the ones named in the replay pack Series 2, G1, and Series 10, G1.
The SCHNAIL web site was updated as promised, and looks much prettier. On the leaderboard, “Download” is still spelled “Dowload” though.
Today is an interesting game from SCHNAIL, Chobo (P) vs Steamhammer on Python. Chobo played corsair-reaver with mass reaver drops to destroy bases and an eventual switch into carriers, a classic strategy I have never seen used against Steamhammer. It’s a demanding strategy for both players. Protoss must be fast and aggressive with drops, never leaving its expensive forces long at home because zerg grows back fast. And zerg must cope with the overwhelming splash damage of reavers on the ground and corsairs in the air—the units may not work against Monster, but they are deadly against Steamhammer. Classic zerg play against corsair-reaver includes burrowed zerglings around the map to see the reaver drops coming, a skill that Steamhammer does not have.
Corsair-reaver depends on a heavy force of tech units, so it launches slowly. Chobo curiously did not take the natural, but blocked the ramp with 2 zealots and a dragoon while teching, then took the nearby island base—which, by the way, I think Steamhammer never discovered. Steamhammer luckily started with a 3-hatch strategy before it scouted the protoss base, so it did not fall behind right off. A one-reaver probing drop did light damage at the zerg natural, then the reaver relocated to the morphing zerg third to try to prevent it. But scourge chased the shuttle away and hydra-ling chopped the reaver. Chobo learned a little caution.
Seeing the reavers, Steamhammer elected to make mutalisks despite the corsairs. It does understand the tradeoff risk... in a vague way. Soon protoss moved down the ramp to take the natural as a third base. By this point, Steamhammer was worried by the powerful-looking protoss force and went with army over economy, starting to fall behind. Chobo tried a 2-reaver drop at the zerg third and killed the defending sunken, but the drones burrowed and protoss left rather than risk the reavers. Still, with 2 bases and another coming versus 3 undersaturated zerg bases, protoss was ahead. Chobo dropped again, again killing the replaced sunken and again retreating. Seeing the drones instantly burrow and unburrow as the reaver appeared and disappeared must have been amusing.
At this point I think the human player began to go wrong. Chobo made defensive cannons and moved by air to take a 4th base, dedicating reavers and adding ramp cannons for its defense. Chobo was perhaps concerned about APM and reaction speed, limited resources if you’re human. But a human can’t outmacro Steamhammer without keeping pressure on. The reavers in speed shuttles are highly mobile. If protoss wants to take another base, I think it’s correct to airlift in minimal defense and rely on the main force to fly to the rescue in case of trouble. In case of no trouble, those reavers want to be blowing stuff up, or at least threatening to. Anyway, a zerg base was morphing below the new protoss base, and the hatchery did not last long. But Steamhammer, seeing more cannons and not seeing more army, correctly concluded that it could make drones and tech up. At the time of the picture, defiler consume is researching.
Steamhammer poked the protoss main with its mutalisks, and Chobo responded by chasing the mutas back to the zerg base and eradicating them, with minor corsair losses. Steamhammer does not understand that air units can scatter and keep fleeing, it believes they have to make a last stand to defend the base. Zerg was reduced to 15 army supply versus 52 army supply for protoss.
It didn’t matter. Zerg had the economy and soon reached its drone limit of 75 (this was Steamhammer 3.4.8, not 3.5 which has a limit of 65). When the corsairs and shuttles moved toward the zerg army, they were plagued and then ensnared, so that the outnumbered mutalisks (11 corsairs with attack +2, 10 mutas with carapace +2) held the upper hand. Protoss dropped the zerg third again, this time with mass reavers and disruption web, and eradicated it. With an observer, the reavers wiped the burrowed drones too. Steamhammer countered in the protoss natural with dark swarm and zerglings and returned the favor. In the picture, Steamhammer has realized its mineral excess and is adding hatcheries to burn it off—and meanwhile, the overloaded human can’t keep up with macro (watch the APM figures).
Carriers arrived and there was more fighting, but the strategic position was decided. Drones and hive tech beat reavers and carriers. The picture is shortly after a base full of drones was destroyed, but as soon as the drones visible in the production tab finish, Steamhammer will have re-maxed its drone count.
I wish the game had lasted a little longer, so that I could see how well Steamhammer’s endgame scouting and clean-up of islands works. It theoretically has the skills, but so few opponents take island bases that they are untested in real games.
An entertaining game. A lesson for zerg bots: Defiler skills count! Steamhammer needed both plague and swarm to win. A lesson for human players: Keep the pressure on! There is one regular SCHNAIL opponent for Steamhammer who seems to enjoy playing tower defense as terran: Stay alive as long as possible with bunkers and tanks and turrets. The two have played dozens of times, and Steamhammer has won every game. Defending does not keep you alive, attacking keeps you alive.
Steamhammer 3.5 is uploaded to SCHNAIL, and will hit SSCAIT when SSCAIT comes back up. I need to collect more opening data before I can work with it seriously; it is taking longer than I expected. But I still made Steamhammer better.
I have been feeling lazy and haven’t gotten much done, according to me. I’m not sure you’ll be able to tell from this change list, but then again, I haven’t posted to the blog recently or done any of the SCHNAIL analysis that I still want to do. It’s in accordance with my motto: All things in due time, or later.
• Updated to VS 2019. When I upgraded to BWAPI 4.4.0, I followed the instructions, which said to use VS 2017. I didn’t realize until later that I could go further. This update was worth another 5% reduction in DLL size thanks to better optimization.
• Many files, not all of them, are reformatted with spaces instead of the grotesque mix of spaces and tabs that I’ve been living with out of indolence. Sometimes I think that the inclusion of the TAB character in ASCII in the 1960s has cost more confusion and dismay than the entire Unicode character set has since.
• The flying squad has a slight preference to attack the enemy main over other bases. The ground squad continues to prefer to attack the natural, other things being equal.
• The ground attack map the.groundAttacks now includes enemy sieged tanks and burrowed lurkers; formerly, it only counted attacks from static defense buildings. The idea is that units which often sit in place should be included in pathfinding for safe paths and minimum-damage paths (which are not implemented yet), while those that move around should be handled by reactive means, at least for many purposes. In the meantime, the attack map does affect other decisions, such as building placement, which will now become smarter (“doh, don’t place a building where it will be in tank range”).
• UnitInfo adds a powered flag to keep track of whether a protoss building had pylon power when last seen.
• Unpowered cannons are excluded from the combat sim, using the powered flag. Steamhammer used to be afraid of them, if they happened to be out of sight so that their powerlessness was not apparent.
• Declare that the workers at a base are in danger if the ground attack map says that the command center/nexus/hatchery is in enemy range. This is in response to SCHNAIL games where protoss did the proxy pylon-pylon-cannon trick behind the mineral line (the pylons and minerals block zerglings from the cannon). Steamhammer pulled its workers to safety, but they remained assigned to the base and were not transferred out (they danced behind the hatchery getting in the way). When the workers at a base are in danger, Steamhammer assigns them elsewhere when it can and assigns no new workers to the base until the danger has passed. It should react better now.
• Don’t assign a worker to mine any mineral patch which is in enemy range, according to the ground attack map. It’s common for an enemy proxy to reach part of the mineral line and not the rest. Now Steamhammer will know to abandon the mineral patches that are in danger, releasing workers for elsewhere. If worker self-defense is not triggered, it will continue mining the rest.
• Cancellation of doomed unfinished buildings and units in the egg or cocoon is improved. I originally added this long ago, and it used a simple hitpoint limit because there was no infrastructure for anything better (too low on HP, cancel it). Now it is updated to use ExpectedSurvivalTime(), which adds up the damage rates of the attackers. I expect it to be more accurate at canceling things at the last second.
• AbsoluteMaxWorkers is configured to 65 instead of Steamhammer’s traditional 75. I want to see how big a difference it makes. In the middle game, Steamhammer always aims for its max worker count, which tends to release pressure on the opponent until the late game—watch games and you can’t miss it. It needs the ability to do things like stop drone production at a point where the income and hatchery count are ideal for a given unit mix, and pour on the army production. This change is an experiment to gather some data and help me think about when and how to do that.
• Queens are more responsive. Among other points, a queen which is in the process of casting is controlled frame by frame rather than only once every 12 (!) frames. Queens will less often blunder into fire and more often escape after casting. Queens have proved effective in games versus terran with many tanks, so it’s important.
• Defilers are a little more responsive too. The change is smaller. Improving the use of dark swarm would be more important.... Maybe this summer?
• If a unit is under dark swarm and no enemy can hit it, it won’t retreat but will keep fighting, even if comrades outside the swarm run away. Units still don’t have the sense to run into dark swarm when they should, but this is a step along the way.
• Fixed: Defilers could repeatedly plague cannons, doing it again as soon as the last plague wore off. They got a constant bonus for plaguing a static defense building. Now they get a proper variable bonus depending on how many HP they expect to wipe off. There is a separate fix to prevent over-plaguing of terran buildings which are already in the red and burning down. Let terran repair it a little first.
• Add sunkens or spores in the opening to hold vultures or air attacks. Due to a bug inserted last December, these defensive reactions didn’t happen until Steamhammer got out of its opening book, which could be too late.
• Don’t make scourge at all versus mass corsairs or mass battlecruisers. They’ll shoot down almost all of it, at huge cost in gas and larvas. There are disadvantages to this decision, like loss of drop defense, and I’ll relax it when scourge gets smarter.
• Battlecruisers more strongly call for a hydralisk answer.
• Tanks more strongly contraindicate lurker production. I was still seeing some lurkers even versus mass tanks.
However long it may take, opening selection using data is coming. When it arrives, the advantages of having many builds will increase and the disadvantages will fade. I felt free to add as many ideas as I could come up with.
• Removed 4Scout, which is functionally identical to 5Scout, and added 7Scout 8Scout 8Overscout. 5Scout and 6Scout remain. These are fast scouting builds which leave all decisions to the strategy boss. They can be appropriate when the opponent is unpredictable but tends to play into the strategy boss’s strengths—it does happen.
• Added new 7PoolHarder 7Pool10Hatch 8PoolHard rush builds. Can’t have too many different rushes.
• Updated 8Hatch7Pool 8Hatch7PoolSpeed 8Hatch7PoolBurrow 8Hatch7PoolBurrowB to be more efficient.
• Added 9PoolFastLair 9PoolFastSpire 9PoolFastSpireB 9PoolFastLurker, which get the fastest possible lair after a 9 pool. The 9PoolFastSpire variant is more suitable versus zerg, and 9PoolFastSpireB versus protoss forge expand.
• Added OverpoolFastLair ZvZ_OverpoolFastMuta, which get the fastest possible lair after an overpool.
• Added Overpool14Hatch, which seems like a good opening stem versus protoss. After the spawning pool it makes 4 drones (not 3) and 2 pairs of zerglings (not 3), then the second hatchery. With appropriate followup, which doesn’t happen yet, it should be fine versus either 1 base or 2 base protoss play. If the strategy boss knew how to adapt properly, I would have marked this as a key improvement.
• Added 11Gas10PoolMutaB 11Gas10PoolLurkerB. When I first added the 11 gas 10 pool build, way back in Steamhammer 1.0, I debated whether to make 2 drones after the spawning pool and before the lair, or 3. I settled on 2, because it seemed safer in ZvZ; the third drone delays zerglings slightly. These minor variants make 3 instead.
• Added 12-11HatchStem, a 3 hatch before pool build which stops after the spawning pool finishes, without making any lings. Steamhammer already has a couple other variants, with specific continuations.
A few unrelated things I’ve noticed on SCHNAIL.
There are a couple of bad bots that don’t start up. One is named “test”. Since the starting elo of 1500 is near the top elo for bots, and the elo falls slowly since nobody plays many games against a bot that doesn’t work, in ranked play the bad bots tend to be matched against the stronger humans. That’s unfortunate.
In practice games, most humans seem to have favorite bot opponents, and don’t experiment widely. That’s interesting, and to me a little surprising. Most pick opponents that they usually lose to. I think either they are truly practicing, or else they’re taking it as a challenge. The strongest humans don’t have bots that they usually lose to, though.
I have the impression that there have been more ranked games over time, as a proportion of all games. Maybe players are getting familiar enough to feel comfortable with it. Many humans choose practice games every time, though, which is of course a perfectly good choice.
It’s curious, but human games are more stereotyped and less varied than bot games. At least at this level on SCHNAIL. (It’s not so at the highest level of human play.) Most humans on SCHNAIL seem to play the same base strategy every game, like the bot SAIDA does, with adaptations to what they’ve scouted.
Humans quit the game before any fighting in a surprising (and irritating) proportion of games. It’s impossible to know how much it’s due to “Oops, I messed up my split, try again,” versus “I’d better take this call,” versus “ack, why’d it freeze now?” From my point of view as a bot author, these are noise games that make the data harder to interpret.
When Steamhammer wins, it’s not due to better strategy (it’s worse than humans), or better tactics (it’s far, far worse), or better micro (better in some aspects, but overall worse). It’s occasionally due to a rush, zerglings or lurkers breaking in by surprise, but not often; humans are better at adapting and more resilient in defending than bots. Usually it’s due to better macro: “I lost this base, I lost that base, I didn’t kill any bases of yours, but I’m still ahead in workers. Say goodnight.”
Steamhammer’s inability to foresee an enemy army’s intent is a severe weakness. “Your army is over there, near my expansion? It’s out of position, I’ll move right up in front of your natural. Wait, you’re attacking my expansion now? Run run run to defend! Oops, too late.”
In games versus terrans, it’s clear that Steamhammer is now stronger with lurkers than with mutas. Lurker play is still crude, but the recent improvements have paid off.
As mentioned in the post the HumanOpponent flag, Steamhammer behaves a little differently when facing a human opponent. In particular, it gives up much earlier when losing. The rule is explained in the old post.
When I wrote that surrender rule, I doubted that it was tuned well. I have been pleasantly surprised, because it works great. In actual games, Steamhammer only surrenders when it is truly losing, and the timing is almost always reasonable: Late enough that it is also clear to the opponent that Steamhammer is losing, and early enough not to waste too much human time. I wish everything worked that well!
Next: I played around a bit with the SCHNAIL api. It’s easy to extract data in JSON format. I want to analyze it a bit.
Here is another valuable new Dave Churchill tool. It doesn’t seem to come with a name, but it is a web build order visualizer which uses BOSS behind the scenes. (I’m told it is a new and more powerful version of BOSS.) You enter up to 3 build orders, BOSS simulates them to find their timings, and it diagrams each one. The picture shows how inserting a drone into a 9 pool gas build, to get back to 9 workers, can delay the initial zerglings.
Partial instructions: + and - move a selected item up and down in the build order. X erases. X* erases the whole build. * selects the whole build. The various > and < buttons copy items between locations. In a diagram, hover over an item for info about its cost and timing.
It’s unfinished, and yet already valuable. Despite many limitations (and one bug I found, which has been fixed), I have already used it to analyze and optimize over a dozen builds. It’s much quicker than entering a build into Steamhammer and playing a game to get the timings. Some of the drawbacks in its current state:
I found it best for low-economy builds. For zerg builds I tested to up 9 pool, its timings match well with Steamhammer’s execution. In overpool builds, only slightly slower, Steamhammer is able to insert an occasional extra drone or zergling without slowing down the timings. I expect that is because mineral locking makes mining more efficient than BOSS assumes. On the other hand, BOSS seems to believe that gas mining is a little faster than Steamhammer accomplishes it. That might be an issue of the time it takes to get workers into the refinery when it finishes. Even so, I can optimize a build (if it’s within the limitations) in the visualizer and then drop it into Steamhammer to see if further improvements are possible. It’s easier.
From a quick glance through the page source, it looks as though BOSS has been compiled into javascript using emscripten, so it executes in your browser. The visualizer works offline.
Good stuff already. How much better will it get?