Steamhammer 2.1 change list
Steamhammer 2.1 is uploaded. The headline feature is that terran and protoss play acceptably well again, unlike in version 2.0, so Randomhammer is updated. Zerg should also play significantly better: Zergling micro is fixed, scourge are more effective (I hope), and defilers are more active.
I reset Steamhammer’s learned data for version 2.0, because 2.0 plays differently. Since then it has learned enough to play its best against some opponents, but it is still short of equilibrium. It reached final elo 2164, which is probably lower than its elo if it had enough games under its belt. Version 2.1 is not that different from 2.0, so it is continuing with the same data.
I reset Randomhammer’s data for 2.1, since the existing data is for version 1.4.7. It will have to figure its opponents out from scratch again, which will take months.
Stand by for source. I’m way behind in updating Steamhammer’s web page. Here is the change list:
opponent model
• Fixed a bug in InformationManager that could fail to recognize an in-base proxy.
macro
• Configured WorkersPerPatch to 2.0 for terran and protoss, to reflect mineral locking. Mineral locking helps terran and protoss over zerg, because bases tend to have more workers. Reducing the maximum worker count per base while maintaining full mining efficiency means that much more cash and supply to spend on tech and army.
tactics
• Medics and tanks act in clusters. They are controlled by their own code, which needed updating.
• Bug fix: A cluster of all medics which happened to reach the front line would then continue to advance heedlessly into the enemy position and die. Now it falls back toward the base—normally it will soon merge with another cluster that is on the way. To implement this, I split the former “no fight” case into 2 cases, “I have no fighting units” and “there are no enemies nearby,” which behave differently. All medics is an example of no fighting units.
• Steamhammer knows a number of places that a cluster of units can retreat to. I moved “retreat to join up with another cluster” (which can be an advance rather than a retreat) ahead of “retreat to the location of a cluster unit which is not near the enemy” in priority order. It helps clusters merge a little more often.
• When there are many clusters, Steamhammer saves execution time by not updating all clusters every frame. It divides the clusters into “phases” and updates one phase per frame. In Steamhammer 2.0, the phases were calculated incorrectly, which contributed to bad micro (though it wasn’t the biggest cause). Fixed.
combat sim
• Combat sim scores are based on the cost of units, not the destroyScore, because destroyScore is sometimes strange. For now I set score = mineral cost + gas cost.
• Steamhammer uses the combat sim scores in an unusual way to decide who won the simulation: It’s the side that ended up with more stuff surviving. It seems illogical, but it tested better than alternatives I tried, such as the side that lost less. Still, there are pathological cases where it gives a wrong answer. I fixed this pathological case: If you lost nothing, then you won the simulation, even if you finished with less stuff surviving. (If the other side also lost nothing, then you still won, because a draw counts as a win.)
• I also changed the units included in the combat sim in special cases. 1. If you have nothing but ground units that can’t shoot up, then ignore enemy air units that can’t shoot down. Because the side with more surviving stuff wins, this can affect who wins the simulation. This fixes another pathological case, where for example zerglings might run away from corsairs. 2. If you’re scourge, include only ground enemies that can shoot up. Scourge are never afraid of the air units that they want to destroy, only of useless death by ground enemies.
At some point I’ll add the other natural special case, for air units that can’t shoot down. All this combat sim stuff could be way more sophisticated....
micro
• I fixed the biggest cause of poor micro in Steamhammer 2.0. As part of choosing an enemy target, the melee and ranged unit controllers called CanCatchUnit() to see whether the enemy unit would be able to escape if chased. It was meant to reduce goose chases. Anyway, the results of CanCatchUnit() are apparently wrong. I haven’t looked into what the trouble was, because I found that removing the calls had no effect on goose chases—long chases have become rare due to other changes. The error caused units to overlook targets that they could, and often should, attack. Zergling micro became weak, and zealot micro was worse. It’s all back to normal now.
• Vultures and wraiths would become fixated on their targets, unable to switch away even to retreat in an emergency. Fixed.
• Like clusters, defiler actions are divided into phases. There was a bug in coordinating the cluster phases and defiler phases, so that defiler actions might be skipped for a long time depending on the phase of the cluster the defiler was in. Fixing it makes defilers more active, though they still don’t swarm or plague as often as they should.
• Scourge is allowed to spread out more in regrouping. Mutalisks should usually group tight, scourge should spread out some. Formerly, all air units behaved the same.
• I made a couple adjustments to defiler plague. 1. Plague on a building was formerly worth 0.6 of plague on units with the same hit point loss; I changed the discount to 0.3, half as much, so that defilers will try harder to plague units. Buildings have a lot of hit points and threaten to dominate the scoring. (Static defense buildings are treated the same as mobile units, though.) 2. Plague gets a bonus for carrier interceptors, to exploit the plague-on-interceptor behavior, but I didn’t see Steamhammer trying hard to plague XIMP’s interceptors (only the carriers themselves). I increased the bonus by a factor of 4.
zerg
• Scourge are in their own squad, the Scourge squad. They behave somewhat better in my tests, but it’s primitive and they still have a long way to go. I mentioned a couple other improvements to scourge behavior above. It was surprisingly difficult to get scourge to do anything sensible.
• Get an evolution chamber and a spore colony for air defense when needed even if still in book. Steamhammer formerly waited until the book line came to an end before it dared defend itself. I think this will be a net gain, though it will make mistakes sometimes.
• Tweak: Enemy dragoons and dark templar loom a little larger as reasons to make static defense.
• Fixed a bug in deciding to get defilers. Battlecruisers are an excellent reason to get defilers; valkyries, not so much.
• Strongly avoid spawning mutalisks versus large valkyrie counts. Valkyries in numbers pass through mutas like they’re hardly there.
openings
• Fixed a typo in the opening name Over10Hatch2SunkHard in the AntiZealot strategy combo. When this opening was selected, Steamhammer couldn’t find it and played its default 9 pool instead, a poor choice against mass zealots.
• Added the zerg opening AntiFactoryHydra, which may be better against SAIDA’s unit mix than Steamhammer's original AntiFactory, and the terran opening 10-10-10FD in a form close to that popularized by Flash. 10-10-10 is an opening stem that gets a super-fast factory, and 10-10-10 FD is a followup that continues into an attack with 2 tanks and 8 marines, which is strong against protoss that techs too hard or expands fast.
• I configured terran and protoss counters to Naked expand by protoss. That means configuring which openings are to be tried as counters to an expected enemy plan. 10-10-10FD should be a good counter to protoss Naked expand.
debug drawing
• In the game info display (drawn in the upper left of the screen when turned on), Steamhammer 2.0 added an overall score versus this opponent, shown next to the opponent name, “2-3” meaning 2 wins and 3 losses. Steamhammer 2.1 also adds a score for the chosen opening, drawn next to the opening name. The context makes it easier to interpret Steamhammer’s choices. The numbers are specific to the matchup. Randomhammer will show different numbers depending on what race it rolled.
• Squads have 2 settable flags, “fight visible only” (only include visible enemies in the combat sim, not all known enemies) and “meatgrinder” (be more aggressive, willing to accept high losses). Visible-only is used by the Recon squad, and meatgrinder tested poorly and is not used. If the squad info display is turned on, it draws cyan V and M left of the squad’s information line if the flags are turned on.
Trackbacks
No Trackbacks
Comments
Antiga / Iruian on :
Tully Elliston on :
My thoughts on watching the most recent SSCAIT SH game vs Sungguk Cha - specifically the interactions between small groups of SH zerglings vs small groups of Marines, is that SH throws SO many winnable fights by endless dive-retreat-dive-retreat with Zerglings while the marines just stand still and fire. So frustrating to watch!
It feels like the command structure - strategic, operational, tactical, agent - needs a cascade of decisiveness built in that prevents costly retreats (or prevents the rapid switching between advance and retreat) and enables SH to trade units poorly where the situation calls for it.
At the agent level, a Zergling that is adjacent or near adjacent to a Marine (or most ranged units) should be far more reluctant to retreat than one that isn't. A Zergling that is adjacent to a Siege Tank, High Templar or other fragile high value target probably should never retreat. A Zergling on very low hitpoints that is also in the presence of ranged units should probably never retreat as it will likely be destroyed as it withdraws, whilst if it stuck around it might deal another 10-20HP of damage.
If the tactical level decides that retreat is likely to be very costly (eg. we are fighting a Terran ball) then retreat should be almost prevented entirely - if the Operational level is willing to pay the high cost to attack the Terran ball, Tactically we shouldn't then chicken out upon taking losses when closing the distance. If the tactical level has been informed by the Operational level that SH has overall superiority in army and that losses can be proportionally x% higher, that should be reflected not just in the willingness to attack but also in the willingness not to retreat.
At the Operational level, aside from Banzai or not Banzai, there doesn't seem to be much sensitivity to viability (or not) of trading poorly. It seems like there should be a sliding scale where depending on the situation report passed down from the Strategic layer, Operational behavior should have sliding scale from "preserve forces above all" to "trade recklessly to destroy enemies above all" - with a smooth gradient of stances between. Such a sliding scale would be useful to a small degree in slightly adjusting the the logic behind whether to attack, but useful to a much larger degree in defining the logic as to whether to retreat.
Dilyan on :
McRave on :
"should be far more reluctant to retreat than one that isn't"
"likely to be very costly (eg. we are fighting a Terran ball)"
"smooth gradient of stances between"
They're valid points and I agree 100%. The difficulty comes from trying to design code to correctly identify these statements. No amount of coding skill will help you, as this is trying to translate human inference and abstract thoughts into literal 1s and 0s.
Dilyan on :
Jay Scott on :
Tully Elliston on :
Very simple:
Just a blanket adjustment to the weights in the retreat decision depending on opponent race (specifically, ranged DPS of opponent race) would pay dividends.
eg.
VS Zerg: retreat at current level
VS Protoss: accept higher losses before retreat
VS Terran: accept much higher losses before retreat
Or:
When running FAP to calculate whether to retreat, separately check the total ranged DPS of all enemy units captured. Check the ratio of total enemy ranged DPS to total remaining HP of involved SH forces.
use the outputted ratio this generates to alter the calculation as to whether to retreat or not.
Tully Elliston on :
Now that has been solved, watching SH games I think the logic behind WHEN to retreat is now the biggest weakness.
MarcoDBAA on :
Vs terran mech it is also good (for example: game vs Iron bot), but as Tully Elliston already said vs bio (or zerglings vs marines) it looks very buggy.
Against protoss there is a bug where hydras do not spit and the bot already lost some games because of this. Else it looks ok so far.
Jay Scott on :
Bruce on :
https://github.com/N00byEdge/Neohuman/blob/master/FAP.cpp#L179
MarcoDBAA on :
Well, need to expect virtual positions of the enemy army to change too, at least for some time (until you decide to check). Expect that the rest will also follow, if you have no vision.
Probably difficult to do? Just storing last combat sim values as an easy solution (for some time)?
Jay Scott on :
PurpleWave has mechanisms to mitigate these problems, so ideas are out there.
Tully Elliston on :