about Steamhammer 1.0
Change of plans. Today and tomorrow I’ll download my thoughts about Steamhammer 1.0 before I dive into 1.1 and start to forget which feature came when. After that I’ll return to tournament coverage. Keeping up with real time? I may have heard of that.
Steamhammer’s web page is updated. Get the 1.0 source and binary releases there. Downloading from SSCAIT is another way to get the binary. Don’t miss the config file, the bot needs it to run.
new skills
The configuration file lets you specify more possibilities as part of the opening build orders. One of my goals is to be able to play every opening, and I’m making progress.
- scout on command: always, or only if necessary, or only to find the enemy
- build a macro hatchery, or mineral only base, or a gas base, or a “hidden” base
- stop and restart gas gathering, or gather a specified amount of gas then stop
- build static defense in the main or natural
For example, you can code “go scout if needed” to send out a worker scout, right then, only if the enemy base location is not already known. Or “go gas until 100” to get 100 gas for zergling speed and then put the drones back on minerals. Or “hatchery @ min only” to start a new base that does not need to have gas. These are items that can go into the production queue to be executed when they come up; the strategy boss uses the same underlying code to communicate its dynamic plans to the production manager.
New openings use all these features. The old openings in Steamhammer have also been reworked extensively. Even when it looks like it’s doing the same thing as the previous version, there are differences. Some openings have fancy optimizations, like stopping and restarting gas more than once to smooth production. It’s easy to edit the config file, so it’s no special effort to try out tricks like that.
The strategy boss copes with emergencies like having no drones and has some basic reactive skills, like queueing up scourge when corsairs are sighted. Overall Steamhammer is much more robust when things go wrong; there are still bugs that can freeze it, but only on cool days.
The strategy boss also improves macro. Steamhammer still sometimes runs its minerals up into the thousands, but it recovers reasonably soon, and in many cases macro is fine from the beginning of the game to the end. Far from perfect, still much better.
random openings
Steamhammer 0.2’s ZvT configuration looks like this. It plays one fixed opening.
"ZvT" : "ZvT_12Pool",
Steamhammer 1.0’s looks like this.
"ZvT" : { "StrategyMix" : [ { "Weight" : 3, "Strategy" : "4PoolHard" }, { "Weight" : 2, "Strategy" : "4PoolSoft" }, { "Weight" : 5, "Strategy" : "5Pool" }, { "Weight" : 10, "Strategy" : "9PoolSpeed" }, { "Weight" : 25, "Strategy" : "ZvT_12Pool" }, { "Weight" : 35, "Strategy" : "ZvT_13Pool" }, { "Weight" : 10, "Strategy" : "ZvT_2HatchMuta" }, { "Weight" : 10, "Strategy" : "ZvT_3HatchMuta" } ]},
The bot chooses randomly among 8 openings, 4 zergling openings and 4 mutalisk openings. I haven’t worked seriously on lurker skills yet. The weights can be any positive integers, but I chose weights that add up to 100 so that I can interpret them as percentages. The 4 and 5 pool openings are slight variations of the same thing and happen 10% of the time in total. (With better scouting skills and followup, Steamhammer plays these fast rushes more strongly than UAlbertaBot.) The 9 pool overruns surprisingly many terrans and happens another 10% of the time. The 12 pool and 13 pool are similar muta rushes and together happen 60% of the time. Most people won’t notice the difference between the similar openings, but many details vary. The 2 hatch and 3 hatch muta openings are actual genuine honest-to-Betsy true-blue manufacturer-guaranteed mainstream builds with stronger economy, but Steamhammer is not yet adaptive enough to play them safely, so together they happen only 20% of the time. I’m curious to see how well they do in practice—hmm, I predict results will vary!
Steamhammer also chooses randomly in the other matchups, including versus random. You have to scout it to know what it is doing.
other stuff
The configuration file includes the version number: Steamhammer_1.0.json
. That way I can conveniently run more than one version from the same directory.
I blogged about the fixes for original UAlbertaBot bugs. There were 10 in total, and only a couple were already in version 0.2. Stream viewers may not notice, but Steamhammer makes slightly fewer absurd blunders.
There are many small improvements to tactics and targeting, which together make a noticeable difference. The bunker obsession is reduced but still claims its toll. The bot is less eager to send out drones for emergency defense, but doesn’t run them away when they are under attack (“keep working, you cowards!”). And Steamhammer now has basic overlord vision skills thanks to hints from AIL, so it makes more informed engagement decisions and can fight cloaked units like dark templar.
And that’s about it. All other changes are minor.
future plans
Alongside further work on adaptivity in the strategy boss, next I want to improve the defense against worker harassment. Aggressive harassers like Iron and Bereaver often kill 2 or more drones, a grave setback (very like being set back in the grave). After that, I want to finally fix the mutalisk tactics and put those terrans in their place. When the mutas meet a strongpoint they should not call a dance party, they should turn aside (“you’re no fun!”) and fly around it. After comparing ideas and thinking ahead to how I want to integrate it someday with machine learning, I’m leaning toward Berkeley Overmind-style convex hull analysis rather than Overkill-style pathing analysis or ZerGreenBot-style reactive movement. But we’ll see.
One thing at a time. Mutalisk skills first, then lurker skills, then drop skills. Once I have all those, opponents will need real smarts to foresee what is going to happen to them.
Tomorrow: Some of Steamhammer’s opponent-specific openings.
Comments
AIL on :
I only tested it for 3 games because in game 3 it crashed. First thought it was my bot crashing, but nope, it was Steamhammer.
The 2 games played were 1:1.
Game 1: Steamhammer went for fast Mutas but was by far not as vulnerable during that transition as before. He built quite a few lings and even a Sunken.
AILien had 3 hatches, better Eco and more lings. It could eventually overwhelm the lings and sunken and kill Steamhammers Eco. But at this point Steamhammer had way too many Mutas already, who first killed my workers and then my Mutas and Lings in defense. So 1:0 for Steamhammer.
In Game 2 Steamhammer had a greedy opening and AILien some sort of weird freestyle 7 pool into 3-hatch-ling. So SH was overwhelmed by the lings before he could get too far.
However, what I wanted to talk about was that I think I got some insights into issues bot of us suffer from. Namedely "Bunker-Obsession" and slacking around in the enemies range.
I changed several methods to get some positive effects here.
1. Bunkers are underestimated by the simulation for a simple reason: Sparcraft does not really know about Bunkers, so there was a workaround in place: The bunker was counted as 4 marines who's health was relative to the bunker-health. So something that often happened was: Bunker is being attacked by lings and it's very close and then it dies. But "oh snap!" Now there's 4 Healthy Marines AGAIN!
So what I did was to add 4 Healthy Marines with not scaling HP to Bunker-Simulation. Basically considering the Bunker as 8 Marines now. This should produce more realistic results in the prediction and not result in an inconsistency in behaviour after destroying a bunker.
While I was at it, I substituted 2 not-supported units for SparCraft:
The Carrier now strikes the same fear as a BC.
The Reaver now strikes the same fear as a Siegetank.
2. CalculateRegroupPosition does not seem to know that Bunkers have range. Now a Bunker will be considered a Marine with Range + 1 when it comes to calculating the regroup-position.
But that's not all. Goliaths are even worse, because the method did not consider the possibility of Charon boosters. And while there is a 128-Range safety Margin, it is also allowed for units to be 100 pixels away from the gatherpoint, which meant the gather-point could well be in the reach of Goliaths. I also added +64 to the range of Goons, Marines and Hydralisks to take their Range-Upgrade into account as well as considering an unsieged-siege-tank as a sieged one.
3. MutaDance ... I think the Mutas overestimate their own range against certain things. Bunkers and most likely Cannons aswell.
My theory is that the distance to those is measured from their edge but in order to attack them, you have to attack their center.
So the Mutadance tries to attack the bunker but very often doesn't hit it because the Mutas aren't close enough!
I don't remember if I added or substracted distance in that methods calculations. But I think it actually worked.
I also dramatically changed the Target-Prio-Methods. The RangedPrio for example did not really consider Stuff like Reavers or Templars as a thread. Air-Units did not consider Ground-Only-Units and Ground-Units did not consider Air-Units. But most importantly, Workers were all moved up to be equal with other units in priority and even surpass them when they are attacking or repairing.
All of that makes Muta-Harass look much more like it does in Pro-Games: The Mutas pick off whatever they can and are much more consistent in their decision. I'm pretty sure there's still bugs and oversights that will show with more games. But it is a good start.
Jay Scott on :
Jay Scott on :
AIL on :
I mean I can also imagine a more sophisticated way where stuff like armor, remaining hitpoints and potential damage are considered aswell. But most of the time attack the closest unit will probably be the best decision anyways.
Jay Scott on :
AIL on :
It's basically down to 4 by now:
1. Repairing/Fighter Workers
2. All sorts of units/buildings that can fight (including workers), except those that are currently moving and faster than my unit
3. Buildings that can't fight
4. Units that are moving and faster than my unit
That way looks quite "right" to me. Especially for melee-units, where moving not only costs a lot of DPS but in many cases lives.
Jay Scott on :
Jay Scott on :
Jay Scott on :
AIL on :
Canceling buildings has been working fine for me with little to now additional coding.
AILien usually crashes when it loses a building or so, but not regularly. If I knew how to reproduce it, I could probably find the cause. The cause that lead it to crash all the time is fixed. It had to do with overlords being assigned to fly to units that didn't exist.
Maybe it still has to do with overlords, but I doubt it. Gonna find out after I've redone overlord-usage. There's massive potential in improving scouting here.
AIL on :
It crashed in the 8th.
Right at the start of the game before even moving a unit.
And since I've never seen that with the old version, I suspect that being caused by something new. Probably tied to a specific strategy.
One of the games was absolutely hilarious:
SH went for a 2-hatch-1-base-speedling-BO.
AILien replied by building a lot of lings on it's own.
That developed into the most massive UAB-shuffle I've seen so far. SH took all the expansions on the Map while AILien only had main and natural. AILien, however also got 1-2-Upgrades for it's lings and got to Max-Supply sooner.
Then the Max-Supply-Broodforce-override kicked in and AILien ...
while starting to mop up Steamhammers lings and getting some mutas on the freed up-supply decided to ... crash 8[
I need to change the Max-supply-broodforce-thing a bit to have different activation and deactivation-thresholds cause otherwise it would snap out of it too soon and go back to the Shuffle. But it simply happens too rarely to be of much impact.
I think one of the changes I made earlier to AILien, which was: "don't save up for tech when you are under pressure" led to it not even trying to go for Mutas, while SH, who indeed did apply said pressure, most of the time did try and lost the initiative on the ground. The very not pulling out gas-drones to get more minerals to deal with pressure, you suggested me to do was what brought it into trouble and gave me the advantage.
Jay Scott on :
Jay Scott on :
AIL on :
Maybe that should be an opponent-faction-specific value being higher for Zerg.
Thanks for the hint with the gas, definitely should do something about it.
I should do more tests with Steamhammer. He seems so much better than before. With the 0:2 version, that 15-games-series was like 2:13, so the improvements are massive. I think the builds he plays now look very solid.
krasi0 on :
Keep up the good work! :)