Steamhammer 1.4.3 is uploaded. I cleared its learning data, so it is starting from zero and has to figure out on its own how each opponent plays. This is the AIST version. As I have mentioned, the changes affect play on SSCAIT so little that it will be hard to notice any difference.
Note: Because this is the same file I submitted to AIST, debug drawing is turned off. The stream will not show Steamhammer’s familiar game info and production displays.
AIST S1 submission is closed, so here is the change list for the new Steamhammer 1.4.3 which I submitted. I’ll upload this to SSCAIT tomorrow when I have energy again; I had an exhausting weekend. The SSCAIT upload will be the same file I submitted to AIST, and this would also be a good opportunity to clear Steamhammer’s learned data and start the blank slate test that I mentioned in this post.
Most of the work for this version was preparation to compete in AIST with its demanding maps. Play on other maps is barely different. This post is about what I did, and tomorrow I’ll go into the overall plan and what I didn’t do.
• MapPartitions provides information about walkability and ground connectivity per walk tile. It is used in various places, mainly for figuring out what places a worker or a ground squad can reach, as is needed to support island (Sparkle) and semi-island (Third World) maps. It also helps on land maps that have islands or plateaus, which are common. squad.mapPartition() tells which map partition a squad is on (a squad might have units in more than one partition—it picks any one unit arbitrarily and goes with that unit’s partition). On the map Third World, the narrow ramps from the main bases seem impassible to Steamhammer at build tile resolution (32x32 pixels), but MapPartitions at walk tile resolution (8x8 pixels) understands that units can pass through. It fixes the inability to expand on Third World.
• A bug in map analysis caused a crash on Transistor. Fixed.
• On the map Third World, BWTA doesn’t provide a region for the enemy base. Steamhammer uses BWTA regions for directing the worker scout to and around the perimeter of the enemy base. The missing region caused an endless stream of exceptions and left the scouting worker idle. At some point I will have to provide another way to direct the worker scout (Locutus shows one idea), but for now I worked around it by releasing the scout if there is no region when there should be. Third World is a 2 player map, so it is relatively less harmful to skip worker scouting.
• I wrote 3 openings for Sparkle, a map which requires specialized openings—seriously specialized openings for this map only. Zerg has to make the right number of zerglings at the right time, as dictated by the map design, to get the next gas geyser its strategy calls for.
• I wanted to provide the Require: feature to configure openings appropriate to given map features, but my design was crummy. First, as described it cannot work, it’s not correct for all cases; second, because of how opening selection is implemented, it seems to require a substantial rewrite; and third, it interacts with opponent model opening selection in ways that I didn’t account for. Major ouch. For now, I hardcoded “if the map is Sparkle, select from the Sparkle strategy mix” of the 3 Sparkle openings. Hold your nose, it’s a disgusting hack.
• Sparkle places a psi disruptor on top of the geyser at each starting island’s low ground natural base. You have to destroy the psi disruptor to mine the gas. To support Sparkle (and a small number of other maps, such as Arkanoid), I assembled a complex feature that destroys neutral buildings which obstruct the operation of bases. Actually I kept it simple: The feature destroys neutral buildings which are very close to bases; good enough. Each base, during the bot’s initialization when its data structure is created, finds any neutral buildings that it thinks are in the way and remembers them as blockers. The tactical analyzer, choosing targets for squads to attack, looks to see if any of our bases have blockers, and may assign a squad to destroy the blockers. That involved adding a new squad order DestroyNeutrals and new code in the squad to implement the order (this part at least can be reused when I get around to destroying neutral buildings that block paths). When a blocker is destroyed, InformationManager (responsible for unit tracking) notices and informs Bases, which keeps a reverse index for efficiency and tells the affected base that its blocker is gone. Whew. Not simple, but necessary to play an acceptable game on Sparkle. The feature usually works but fails occasionally, apparently because InformationManager prematurely decides that a blocker has been destroyed; I’m not sure how that happens.
• Island support: Steamhammer normally sends an overlord scout, unless the opponent is known to be terran. It has zero overlord survival skills, so it doesn’t send an overlord to look at a terran base. On island maps, it can’t scout by ground, so I changed it to send the overlord anyway (and lose it to marines) if Steamhammer starts on an island.
• Island support: The Recon squad was designed to perform reconnaissance in force with a small ground squad. On an island map, instead it assigns 1 overlord to be the Recon squad. Obviously that’s no longer reconnaissance in force. It works adequately, but the lone overlord is vulnerable and easily lost.
• Island support: Zerg strategy is adapted to islands. Mainly, zerg goes air only until nydus canals are established. Since zerg doesn’t know how to establish nydus canals, that’s the entire game. It does make plenty of zerglings with its excess minerals, which scout around the island they are on and pounce on any drops.
• Island support: Zerg delays ground upgrades to save gas for its air strategy. It turned out to be a necessary adaptation. Steamhammer is normally aggressive about getting evo chamber upgrades, and it ate up so much gas that the mutalisk fleet was stunted.
• Zerg gets air upgrades when appropriate. Well, it gets air armor up to +2 before greater spire. Steamhammer hasn’t had that feature since early days; I finally restored it. This isn’t technically an island support feature, since it could happen in any game, but it is especially important with the island air strategy.
• Island support: The plan recognizer and plan predictor do not try to recognize or predict island plans; the enemy plan is always Unknown. For one thing, I would need to add new and different island plans; the existing plans don’t fit. For another, Steamhammer doesn’t understand that island and non-island maps are fundamentally different, and that what it learns about an opponent on an island map is probably wrong on a land map, and vice versa. To handle this right, the map adaptation in the opponent model needs more smarts. Anyway, the upshot is that the opponent model is effectively turned off on an island map.
• I removed more uses of BWTA from various places in the code. There are still a lot more to go; I mainly removed the uses that got in the way for AIST.
• Fixed a nonfatal exception: A fresh Building object was initialized wrong in one case, so that canceling an expansion which could not be placed might throw. An expansion can almost always be placed (that is, can almost always have its final location set), so it was rare.
• Only print the “reserves wrong” debug message if the DrawBuildingInfo debug option is turned on. The “reserves wrong” message was supposed to shame me into fixing the underlying bugs, but it failed; the bugs are still there.
• In removing BWTA from the code which chooses where to place the next expansion, I removed a feature: Steamhammer will now happily expand to a base in a region where the enemy has buildings. I didn’t want to do extra work to keep using the BWTA region when I intend to drop BWTA. I may have to add the feature back if it causes problems.
• Squad status strings are a little more informative. Turn on DrawSquadInfo to see them. I should rewrite the squad display, because it’s tough to understand and messages from different squads can overlap on the screen.
• Tactical targeting: A lifted building will be assigned to a squad that can attack air. Clever, no? Oops, but a squad with zerglings and scourge qualifies... well, one step at a time.
• Micr0 targeting: A higher priority for air units to hit tanks. Picking off tanks can be critical, but Steamhammer didn’t think so.
• Micr0 targeting: Scourge are slightly more eager to hit carriers, as opposed to other targets.
• Changed instances of BWAPI::Position(0,0) to BWAPI::Positions::Origin.
• In the configuration file, I moved the debug log location from the Debug section to the IO section. Keeping the file stuff together seemed more important than keeping the debug stuff together, since the other debug options are unrelated to the debug log.
• Added the missing manual commands /set drawscoutinfo (forgotten long ago) and /set drawqueuefixinfo (forgotten recently).
• Formerly, if you asked for the center point of a squad with no units, you got (0,0) and (if it was turned on) a message on the screen. Not so useful. Now you get the location of the starting base—the spot where future squad members are most likely to appear—and no message.
• The Sparkle openings are Sparkle 1HatchMuta, Sparkle 2HatchMuta, and Sparkle 3HatchMuta. Simple. The 1 hatchery opening starts with 9 gas 9 pool to get mutalisks as fast as possible, and the others start with 12 hatchery. The followups are different from the land-based parent openings, though: They have few zerglings at specific timings, more drones, and earlier hatcheries and second gas. Details matter—it’s not so simple after all.
• New anti-factory variations to offer choices in defeating terran vulture-first play: AntiFact_13Pool and AntiFact_2Hatch.
• Fixed a problem that could make drones way over the limit. It was rare—except on island maps. I had been puzzling over this one for months.
• Fixed a typo in calculating gas reserves after ordering a carapace upgrade. It was a bug, but the effect is barely noticeable even if you know what to look for—it might delay a few gas units from this production round to the next round seconds later.
Next: The ordeal of supporting Sparkle.
AIST S1 registration has closed, and the participant list has been announced. In alphabetical order:
| protoss | MadMix |
| protoss | McRave |
| zerg | PurpleSwarm |
| zerg | Steamhammer |
| protoss | Tscmoo |
I expected McRave and PurpleWave, because their authors said they’d play. Instead of protoss PurpleWave we got zerg PurpleSwarm. I wonder why? Is it because of Sparkle? Is it because Purple Dan foresaw the protoss overload we would have gotten? Tscmoo has always been an ambitious bot, so it is not a surprise to see it. I was surprised by MadMix, and maybe I shouldn’t have been. These are bots that implement, or in Steamhammer’s case at least aspire to implement, a large number of skills for different situations. MadMix has been of that mold since its beginning. The challenging AIST maps demand those skills.
There are no terrans. That’s unfortunate.
The tournament format is double elimination, so we get a #1 and #2 finisher. I think the favorites are McRave for #1 and Tscmoo for #2. But if we knew the outcome ahead of time, we wouldn’t have to play the tournament.
5 participants is an awkward number for an elimination tournament. With an odd number in the first round, 1 player will get a bye and move on to the second round of the winner’s bracket without having to play a game. 2 players will drop to the loser’s bracket, and the second winner’s bracket round will again have an odd number of players. It’s no good to give the same player a bye twice, so this time one of the winners in the first round will get a bye to the third round of the winner’s bracket. With only 5 participants, the players that get byes have a significant advantage. The rules call for random seeding, so the choice should be purely the luck of the draw.
Nothing is perfect, but so far AIST seems to be thoughtfully and skillfully run. Decisions make sense and events are happening on time—not a given, organizing a tournament is no walk in the park. Keep up the good work!
Next: Expect the Steamhammer 1.4.3 change list on Monday, followed by posts about how I approached the tournament.
Zerg bot Proxy (which is not a proxy bot but a dll) is a nice start on a new bot. It plays only one strategy and has no outstanding skills, but its strategy is dangerous against many opponents. Most impressively, it holds a score of 2-0 against Tscmoo terran. It is currently rated not far below 1900, a decent performance for a new bot apparently made from scratch. (It does say that it uses BWEM and FAP.)
Proxy describes its strategy as “eco cheese into mass hydra.” “Eco cheese” means make lots of drones, which says that Proxy is vulnerable to almost any early attack. A lot of bots play rushes, so Proxy will never be a top scorer with this strategy. Once the mass hydras arrive, though, with that big economy behind them they seem endless and relentless. It mixes in zerglings as needed to balance minerals and gas; that may be its greatest skill. This game against Marine Hell is boring to watch, with no variety, but it shows what I mean about relentlessness. Proxy slowly battered its way up a ramp by sheer persistence.
Like any new bot, Proxy doesn’t have many skills yet. It takes 2 bases and never expands again. It cannot replace lost buildings. It is poor at scouting. It often makes weak tactical decisions. These things need time to implement. Considering how little it knows, I think it is performing well.
Good start!
Steamhammer is registered for AIST S1. It is almost done; I am working on final testing and fixes. After submission closes, I’ll release the new version as 1.4.3 and upload it on SSCAIT. Features that I formerly planned for 1.4.3 will be pushed to 1.4.4, and so on down the line. Expect the usual change list et cetera, plus discussions of the map features and how I chose to cope with them.
On SSCAIT, it will probably be hard to notice a difference from version 1.4.2, because most of the changes are to support the difficult maps of AIST. There are about 7 bug fixes and improvements that affect play on all maps, but in such subtle ways that neither stream viewers nor Steamhammer’s elo should see a change. Even so, there are a lot of changes, including entirely new features like MapPartitions. Judging the change bars by eye, I’d say I touched about 15% of the lines of StrategyBossZerg. There are also changes to tactics, micro, map exploration, the Recon squad, and scouting.
Steamhammer is not remotely ready for the tournament. The impossible is impossible. I took shortcuts to get as far as I did. But it can play games on the AIST maps without looking like a moth flying into a windowpane (“I see the light, it’s that way.” Wham! “Oh... I see the light again, it’s that way.” Wham!), and it can defeat some opponents. It’s a huge step up from crashing, or throwing endless exceptions, or playing a mass zergling opening on an island map. And I’ve made more progress toward removing BWTA, though it’s haphazard—I removed the parts that were in the way.
Next: The new bot Proxy.
Steamhammer and Tyr terran by Simon Prins played a hilarious game on Moon Glaive. I think that Steamhammer decided on a 3 hatchery before spawning pool build (it’s not entirely clear), but the zerg build became confused because Tyr’s scouting SCV delayed the natural hatchery, and because Steamhammer has an issue on this map where it sometimes sets its bases down unexpectedly far away. The build as executed was hatchery-pool-hatchery, with the third hatchery in Tyr’s natural because zerg hadn’t located the enemy yet. Something similar happened almost exactly a year ago in a game versus Krasi0.
Tyr reacted differently than Krasi0: Tyr ignored the zerg base in its natural!
The marines fired at the zerglings, but the hatchery and drones were in plain sight, and they just didn’t care. Their job, I gather, was to guard the natural against zerg attack, and the functioning zerg base was not an attack. They took their orders literally! Steamhammer was also unworried, and mined minerals contentedly.
Tyr was bright enough to figure out that it had to expand somewhere else, and planted a command center at what would normally be its 3rd base position. The zerg play was disorganized, but the terran play was more disorganized, and Steamhammer won effortlessly.
Regularly scheduled real world events are taking up some of my days.
I wanted to run a test on the map Arkanoid. It’s a concept map from 2006 with many destructible neutral buildings in blocking positions. Some of Steamhammer’s new code for the AIST maps should kick in, so I thought it would be a good test.
But the map crashed BWTA. I have to finish removing BWTA before I can test my own map code on Arkanoid. There is a disadvantage after all to my step by step replacement procedure.