Starcraft AI blog

Steamhammer 3.0 is nearly ready, but I’m immoderately busy and don’t know how long it will take for the last adjustments. I can at least slip in short posts to show off some of what’s coming.

Steamhammer 3.0 changes the format of game records in the learning files of the opponent model. The original version 1.4 game record format has been in use since early 2018. The learning file for an opponent is simply a list of game records. Here is the new 3.0 game record format.

meaning	item
game record version	3.0
matchup	ZvP
map	(3)Longinus_200.scx
base ID of Steamhammer's start	5
base ID of enemy start, 0 if unknown at end of game	12
opening	Over10Hatch2SunkHard
predicted enemy plan	Heavy rush
recognized enemy plan	Unknown
0 for loss, 1 for win	0
frame of our first combat unit	4382
frame we first gathered gas	6814
frame the enemy scouted our base	3134
frame the enemy got a combat unit	3838
frame the enemy first used gas	5162
frame the enemy got an air unit	5182
frame the enemy got static anti-air (0 means never)	0
frame the enemy got mobile anti-air	5182
frame the enemy got a cloaked unit	5182
frame the enemy got static detection	0
frame the enemy got mobile detection	18686
frame the game ended	28553
skill kit data (2 skills)	gas steal: 0 0 0 unit timings: 60 6161 61 9565 64 2435 65 3815 66 13383 84 18696 154 3240 156 3240 157 3217 160 3263 163 5172 164 3194 165 6575 167 5195
end of the record	END GAME

As before, the frame number of an event is the frame when Steamhammer first noticed it, not when it happened. They are sometimes very different.

The game record version number can be “1.4” for old records or “3.0” for new records. Steamhammer can read them both and use the data; changing the format doesn’t mean I need to clear out existing learning files. Of course fresh records are written in 3.0 format.

Including the base IDs of the starting positions of the 2 sides means that Steamhammer can pay attention to starting positions. You have to know the map to interpret what the ID numbers mean. The information about enemy gas usage is new and helps with gas steal decisions. The gas steal items from version 1.4 records are moved into the gas steal skill.

There was no gas steal in the example game, so the gas steal recorded 0 0 0 for its data. The skill kit can record data for any number of skills; it is extensible. Each skill’s data is [name of skill]: [data for skill] on one line (the line can be arbitrarily long). The skill needs to know how to write one line of its own data and how to read it back, and that’s all; the central skill kit code takes care of everything else, including rewriting old records without change.

We got a new bot! We got a new bot! Protoss Slater is not very strong yet, but it has some nice initial skills and I expect it could jump up from the bottom of the ranking with fixes for a few of the bigger weaknesses.

Java bot Slater seems to play a fixed build: One zealot, cybernetics core, unit mix of dragoons and zealots, adding in reavers with shuttles. It’s not an aggressive build, but one that builds up strength over time. The build seems well-executed for a beginner, and Slater is good at keeping its money down. It gets upgrades like dragoon range and shuttle speed. Like most new bots, it is weak in combat skills.

This reaver drop was almost devastating. The reavers are in range, it’s too bad that scarabs can’t reach down the cliff.

Slater pulls nearly all probes to chase the enemy scouting worker in the early game, losing far too much mining time at a critical phase. That might be the biggest easy-to-fix weakness. I recommend ignoring the enemy scout unless it attacks something, at least until you have a unit that can catch it like a dragoon.

Update: Here is Slater’s best game so far, Slater-ZZZKBot by Chris Coxe on Tau Cross, played on BASIL. Slater’s build is adaptive; it played differently against the zergling rush.

For anyone who hasn’t noticed, SCHNAIL is in closed beta as of Friday, and all bot authors are invited. The fronting web site is unfinished, but that should not be an issue for early testers.

I’ll have more to say after I’ve tried it out myself.

Update: When will the mascot character get a proper radula? Mollusk pride!

Here is a first look at Steamhammer’s upcoming basic proxy skills. These are features that you can use to write a wide variety of proxy openings. I still have work to do before I can release Steamhammer 3.0, and I’m working slowly so it will be a while. I’m making infrastructure changes that tend to introduce bugs. But I’m looking forward.

• New macro locations @ enemy main, @ enemy natural, and @ proxy. Buildings for the enemy main or natural are placed in plain sight—MadMix has played that style of proxy with success against bots, and bunkering the enemy natural is standard in some situations. Buildings placed @ proxy go into a distant corner where they have a chance of remaining unseen. I also fixed a bug so that the existing macro location @ center works reliably.

To build in enemy territory, you need to know where your enemy is. Proxy locations interact with early game scouting. On a 2 player map you can always build at a proxy location. On a larger map, you’ll need to scout early enough to find the enemy first. I recommend go scout location with an early worker; on a 2 player map, the location is known so the scout is not sent. If the enemy is not found by the time building construction is to start, Steamhammer will fall back to building in the center of the map instead.

• Post workers to a macro location. You can command a worker to take up a post at a given macro location with, for example, go post worker @ proxy. The posted worker can build at that location (barracks @ proxy) and will remain there for further orders (bunker @ proxy). Release posted workers from a given location with go unpost workers @ proxy or from all locations with go unpost workers. A posted worker is different from a worker that was pulled and assigned to a combat squad; a posted worker expects to build stuff and will not try to fight.

The feature bypasses weaknesses in Steamhammer’s assignment of construction workers. A worker sent a long distance tends to arrive late; by posting the worker in advance you can avoid the loss of time. Also, Steamhammer likes to send one worker per building, so if you ask for 3 forward cannons next to your forward pylon, it will send 3 probes (after all, you need 1 worker per building for Steamhammer’s main race zerg). If you post a probe there instead, special case code makes sure that the one posted probe makes the 3 cannons one after another.

• Macro locations work for all actions that they make sense for. It’s essential so that you can control where production occurs: If you have a proxy gate and a gateway in your main, you can get your next zealot from the one you choose with zealot @ main or zealot @ proxy. Or similarly, if you have a forge in an exposed blocking position (which you’ll have to write code to place; Steamhammer doesn’t support that out of the box) and a forge in your main, you can specify ground weapons @ main to get your most important upgrade in a safer place. If you don’t specify, either building might be chosen.

The feature is a little fragile. The priority is to start the requested action as soon as possible, not to start it in the location requested. If you ask for a zealot at your proxy gate and that gate is already busy, the zealot will start in your main instead if that gate is free. That can be inconvenient in a hand-written build order, though it should be little trouble for a build order generated programmatically on the fly.

• Proxy locations can block bases. A minor tweak to building placement: Normally Steamhammer places its buildings so that they don’t block any future base you may want to take. If you’re building in enemy territory, you don’t care about that. bunker @ enemy natural will commonly be placed to block the base location.

No maps are special cases in the code; all placement decisions are made by analyzing the map on the fly. I think the decisions are good for a first cut, but there is plenty of room to improve them. I did find one map where a mystery bug causes a worker posted in the center to fail to build there (so that Steamhammer sends a fresh worker from its base), but that’s the only bug I know of. It’s complicated, though, and there are probably a lot of misbehaviors I have yet to see.

The features are enough to support a good range of proxy openings. I wrote two or three for each race, for testing and for the fun of having them. In Steamhammer 3.0 none of them are configured to be played frequently, but they should pop up now and again.

The skill kit will be the other major feature in this release. It may sound independent of proxy skills, but in my mind there is a close connection: I want to write skills to make dynamic decisions about whether and how to proxy. It’s possible, and it doesn’t seem too difficult, to do things like cannon the enemy base differently each game based on analysis of the map and the base layout. Many bots place buildings the same way every game, and that can be exploited too.

Stand by for Steamhammer’s next step up in versatility.

AIST S3 is coming up fast, with play to start on 1 March. As I expected, I did not register Steamhammer (the proxy skills are looking fun, though). Events coincided to leave me extremely busy over the last ten days or so.

Here are the registered players. I sorted them by BASIL elo, so we can take the table as a first guess at the likely winners. Of course participants are likely to have special tournament updates, so it’s only a guess.

race	bot	elo
protoss	PurpleWave	2878
protoss	Locutus	2805
zerg	Microwave	2624
protoss	BananaBrain	2610
terran	Dragon	2483
terran	WillyT	2358
terran	LetaBot	2255
zerg	McRave	2153

McRave chooses to participate as zerg, which is interesting—first, that he chose to play, and second, that he chose to play offrace. The sensational news is that LetaBot signed up! That implies that LetaBot is updated to BWAPI 4.4.0, and suggests that the long-awaited bug fixing work may be complete. If so, this version of LetaBot may be much stronger than the BASIL elo of the old version indicates. I’m looking forward!

As usual in recent years, protoss is on top, terran struggles, and zerg is scattered around. We’ll see whether the tournament results agree with that.

8 is a power of 2, so 8 players are a good number for an elimination tournament. AIST S1 had 5 players and S2 had 10, so byes had to be inserted into the pairings. None of that should be needed this time.

The maps for S3 are (2)Overwatch, (2)Tres Pass, (3)Power Bond, (4)Circuit Breaker, (4)Fighting Spirit, and (4)Gladiator. I linked the unfamiliar maps; bots have played on the others before and should be ready. None of the maps has difficult features that call for special-case coding, which must be a relief to participants. The strangest feature is that Tres Pass has a short air distance between the 2 bases and a long ground distance, which is not so strange at all. Power Bond does have a neutral command center on the center platform, which zerg could purloin with a queen (and land elsewhere to make infested terrans), but I doubt either zerg has the skills.

Since Steamhammer is not playing, may the second best bot win!

We have the next round of SSCAIT results. I was hoping for Killerbot by Marian Devecka over ZNZZBot, because Steamhammer is a favorite over Killerbot. But ZNZZBot squeaked a win by crash. Steamhammer will face ZNZZ in loser’s round 3 and almost certainly be eliminated. Oh well.

one little plague

A highlight from Steamhammer-Icebot on Fighting Spirit. In old days, Steamhammer would have finished a winning game like this by brute force, with mass ultralisks or mass guardians. The actual ending did feature brute force, but more elegantly applied.

Dark swarm ensured that zerglings would break the front. Rubble of bunkers and turrets lies everywhere. Tanks rain splash damage from above, but as zerg reduced the natural, the defiler (selected) threw a plague over every tank. When the mutalisks visited them, the tanks popped like so many bubbles.

Very satisfying. All that work on defilers was worth it.

Steamhammer 3.0 will be coming out “real soon now,” as we used to say, meaning “later than I ever thought,” thanks to my ambition to throw too many features into it. I originally wanted Steamhammer to participate in AIST S3, but I think I will probably skip it. I don’t expect Steamhammer to be upgraded to BWAPI 4.4.0 and working reliably by then. The last day to register is 15 February, so I have time to change my mind. But I want to concentrate on new features rather than on tightening the bolts for tournament play.

Here’s the main new stuff. I chose to delay work on pathfinding, overlord control, and scouting for now, though they are high priority features for good play, and are on my must-complete list for AIIDE 2020. (No plan survives contact with the next minute.) I suppose they’ll go into versions 3.1 and following. I was more interested in the skill kit and other infrastructure additions; they hardly help Steamhammer in the short run, but lay a foundation for faster improvement in the future. That’s what seems important now, foundation laying.

• The skill kit to make the opponent model extensible.
• Basic proxy skills, including new macro locations like @ enemy natural.
• Resource tracking to remember minerals and gas on the map.
• Followup on burrow, with many new burrow openings and tweaks to the Watch squad skill.
• Followup on queens, with slightly improved behavior and support for larger queen numbers.

The skill kit feels like my best new idea in a long time, so I was excited to do it right away. The initial skills will be gas steal (replacing the current opponent model code with something a little smarter) and a unit timing skill which doesn’t control anything in itself but only records information for the rest of the program to refer to. They both fit into the framework. I expect the skill kit to speed up strategy work and to help make Steamhammer more and more adaptive over time.

Proxy openings are amazingly complex to execute well. A bot needs building placement skills, the right worker control, and special unit production and tactical skills. Steamhammer 3.0 will have only some of the skills it needs, but it should at least be able to pull off a simple plan like building a barracks in the center and then bunkering the enemy natural. Even that takes infrastructure work that I haven’t finished yet (partly because I changed plans in the middle). The work will bring extra flexibility that will be useful in other situations too. For complex proxies that can’t be written in data as opening build orders but require code—write a skill for the skill kit, that is one of its purposes.

There are also, of course, the usual new openings and small fixes and tweaks.

In a game Steamhammer - McRaveZ on La Mancha, McRave pulled drones to try to survive.

But what happened to that one drone that seems to be leaning over the chasm? It collided with other units and was pushed across unwalkable terrain to a new position where it was trapped.

Steamhammer’s zerglings desperately want to get at that drone, but they can’t... quite... reach it. The zerglings were nearly useless for the rest of the game, distracted by the stuck drone every time they reached the enemy base. Steamhammer floundered until it finally remembered that mutalisks are also a unit it can make.

Here is the walkability map. Steamhammer actually checks that it can reach the drone target, but the check is incorrect in this case: There is a narrow corridor, one walk tile or 8 pixels across, leading to the little platform where the drone waits. No unit is narrow enough to walk there (even a ghost is 15 pixels wide), but Steamhammer doesn’t know that.

The imprisoned drone illustrates a flaw in the map design: Accidents should not push units into places where they will be permanently trapped. Freakling would never allow such a blunder! Of course it also illustrates a bug in Steamhammer. The bug makes a regular appearance on a few maps, like Fortress, but this is the first time I’ve seen it affect play on a regular SSCAIT map.

Next: Steamhammer status. Soon: Some of Steamhammer’s best recent games.