archive by month
Skip to content

random Steamhammer notes

A few unrelated notes about Steamhammer:

The bug that causes Steamhammer to drop commands is due to a missing & in an inconspicuous declaration, causing a data structure to be copied instead of referred to. Updates are made to the copy instead of the correct data, then the copy is thrown away. Even after I deduced that something was being copied behind the scenes, it was tricky to nail the exact mistake.

I developed an opening that I feel I can properly call Fried Liverpool. Like the Fried Liver Attack from chess, mentioned in a comment, it’s crazy sharp and can put on tremendous pressure. Steamhammer can’t play it yet; it needs a couple new features. I tried it by hand and found it is effective against unprepared opponents. Maybe I’ll get it working in time for version 2.2.1 or thereabouts (the one after the upcoming 2.2).

Steamhammer just lost a game against the cannon bot Jakub Trancik. I don’t remember another loss against Jakub Trancik since early last year (maybe I have a bad memory). During the tournament I can’t log in to fetch the game records, but I assume it is the first game against this opponent since version 2.0. It takes a long time to collect enough game records. I’m glad I fixed the proxy recognition bug, or Steamhammer might have lost the next game too.

SSCAIT halfway mark

The SSCAIT round robin phase is halfway over, a good time to take stock. Plenty of places will yet change hands, but the ranks are starting to firm up. #1 SAIDA is on top with less than half the loss rate of #2 Locutus. #3 Iron and #4 PurpleWave follow, close to each other. Then comes a gap, and the rest of the possible top 16 are more closely spaced.

#3 Iron, #7 KrasioP, and #8 Skynet by Andrew Smith are performing better than I expected. Iron is still reliable at rolling up the lower end. KrasioP’s game plan of cannon push into dark templar into carriers is more effective than I anticipated—each step sets the opponent a different problem. Overall, it’s striking how much stronger the field is this year than last. #13 Bereaver and #14 Tscmoo protoss have been pushed well down the rankings. When the round robin is over, I want to do an analysis to compare the win rates of unchanged bots; SSCAIT has many more unchanged entrants than other tournaments.

#9 Steamhammer looks likely to finish at 9 or 10 (the middle of my forecast range of 7 to 13 or one slot above). Most of Steamhammer’s losses are unexpected; it’s annoying, but the same happened last year so it’s not a surprise. In upsets, #2 Locutus lost a game to #36 Ecgberht, and #3 Iron lost a game to #49 AIUR by Florian Richoux—everybody has surprise results, except for SAIDA whose only 2 losses are to high-ranked opponents. Even tail-ender #72 FergalOGrady, which fails to start most games and plays awkwardly when it does start, has a win over #25 ICEbot (though it’s a win by crash as its last buildings were being destroyed).

Getting into the top 16 of 72 bots is not easy. Most of the finalists can be predicted now, though not with certainty. Place 16, just below #15 Microwave, has high odds of changing hands; those above range from likely to nearly sure to be in the finals. Pairings in the finals have historically pitted the top finisher against the last finalist and so on toward the middle. Even once you’ve made it into the top 16, you can benefit from climbing up a place (except that climbing from 9 to 8 makes no difference).

Steamhammer status

As I write, in SSCAIT Steamhammer is tied with BananaBrain for #8-#9, at just under 80% win rate. I’m happy with it. But Steamhammer is one of only 2 bots (the other is #26 NLPRbot) which has not yet played any games against the current top 5. I expect to take losses and slip down in the ranking. A finish near the middle of my predicted range of #7-#13 seems likely.

For some reason I don’t feel like analyzing CherryPi and SAIDA yet, though I’m sure I’ll get around to it. I’ve been working on the upcoming Steamhammer 2.2 instead. I’ve removed all references to BWTA other than regions, and I’m making good progress in implementing my own regions; the outline of the code is there, and supporting data is calculated and looks correct. Finish that and replace references to BWTA regions, and only a few small odds and ends remain before I can drop BWTA. Debugging time is unpredictable, because my regions will be different and may affect play. But I’m likely to be done in time for the end of the tournament.

Today I decided to take a break from that and fix a critical bug instead. I verified what I have been suspecting: There is a deadly one in the new micro system, causing it to reissue commands far too often. That makes the APM shoot over 90K and probably saturates Starcraft’s queues so that commands are lost in transit. That explains unit freezing and misbehavior once the zerg army grows large, and I hope it explains the production freezes too. The bug is resisting me so far; something behind the scenes is mysteriously resetting the “yeah yeah, I already did that” marker. But the code is simple and I’ll nail it before long. The bug is responsible for a lot of bad play during the tournament, but strangely for only a few losses.

As the tournament approached I was trying to make low-risk changes. The code is simple, but I still misstepped. I think my first cut of the micro system was OK, since it passed tests then, and the bug was introduced in later changes as I “improved” it.