Starcraft AI blog

Steamhammer 3.5 is uploaded to SCHNAIL, and will hit SSCAIT when SSCAIT comes back up. I need to collect more opening data before I can work with it seriously; it is taking longer than I expected. But I still made Steamhammer better.

I have been feeling lazy and haven’t gotten much done, according to me. I’m not sure you’ll be able to tell from this change list, but then again, I haven’t posted to the blog recently or done any of the SCHNAIL analysis that I still want to do. It’s in accordance with my motto: All things in due time, or later.

code

• Updated to VS 2019. When I upgraded to BWAPI 4.4.0, I followed the instructions, which said to use VS 2017. I didn’t realize until later that I could go further. This update was worth another 5% reduction in DLL size thanks to better optimization.

• Many files, not all of them, are reformatted with spaces instead of the grotesque mix of spaces and tabs that I’ve been living with out of indolence. Sometimes I think that the inclusion of the TAB character in ASCII in the 1960s has cost more confusion and dismay than the entire Unicode character set has since.

squad orders

• The flying squad has a slight preference to attack the enemy main over other bases. The ground squad continues to prefer to attack the natural, other things being equal.

infrastructure

• The ground attack map the.groundAttacks now includes enemy sieged tanks and burrowed lurkers; formerly, it only counted attacks from static defense buildings. The idea is that units which often sit in place should be included in pathfinding for safe paths and minimum-damage paths (which are not implemented yet), while those that move around should be handled by reactive means, at least for many purposes. In the meantime, the attack map does affect other decisions, such as building placement, which will now become smarter (“doh, don’t place a building where it will be in tank range”).

• UnitInfo adds a powered flag to keep track of whether a protoss building had pylon power when last seen.

• Unpowered cannons are excluded from the combat sim, using the powered flag. Steamhammer used to be afraid of them, if they happened to be out of sight so that their powerlessness was not apparent.

defense reactions

• Declare that the workers at a base are in danger if the ground attack map says that the command center/nexus/hatchery is in enemy range. This is in response to SCHNAIL games where protoss did the proxy pylon-pylon-cannon trick behind the mineral line (the pylons and minerals block zerglings from the cannon). Steamhammer pulled its workers to safety, but they remained assigned to the base and were not transferred out (they danced behind the hatchery getting in the way). When the workers at a base are in danger, Steamhammer assigns them elsewhere when it can and assigns no new workers to the base until the danger has passed. It should react better now.

• Don’t assign a worker to mine any mineral patch which is in enemy range, according to the ground attack map. It’s common for an enemy proxy to reach part of the mineral line and not the rest. Now Steamhammer will know to abandon the mineral patches that are in danger, releasing workers for elsewhere. If worker self-defense is not triggered, it will continue mining the rest.

• Cancellation of doomed unfinished buildings and units in the egg or cocoon is improved. I originally added this long ago, and it used a simple hitpoint limit because there was no infrastructure for anything better (too low on HP, cancel it). Now it is updated to use ExpectedSurvivalTime(), which adds up the damage rates of the attackers. I expect it to be more accurate at canceling things at the last second.

zerg

• AbsoluteMaxWorkers is configured to 65 instead of Steamhammer’s traditional 75. I want to see how big a difference it makes. In the middle game, Steamhammer always aims for its max worker count, which tends to release pressure on the opponent until the late game—watch games and you can’t miss it. It needs the ability to do things like stop drone production at a point where the income and hatchery count are ideal for a given unit mix, and pour on the army production. This change is an experiment to gather some data and help me think about when and how to do that.

• Queens are more responsive. Among other points, a queen which is in the process of casting is controlled frame by frame rather than only once every 12 (!) frames. Queens will less often blunder into fire and more often escape after casting. Queens have proved effective in games versus terran with many tanks, so it’s important.

• Defilers are a little more responsive too. The change is smaller. Improving the use of dark swarm would be more important.... Maybe this summer?

• If a unit is under dark swarm and no enemy can hit it, it won’t retreat but will keep fighting, even if comrades outside the swarm run away. Units still don’t have the sense to run into dark swarm when they should, but this is a step along the way.

• Fixed: Defilers could repeatedly plague cannons, doing it again as soon as the last plague wore off. They got a constant bonus for plaguing a static defense building. Now they get a proper variable bonus depending on how many HP they expect to wipe off. There is a separate fix to prevent over-plaguing of terran buildings which are already in the red and burning down. Let terran repair it a little first.

• Add sunkens or spores in the opening to hold vultures or air attacks. Due to a bug inserted last December, these defensive reactions didn’t happen until Steamhammer got out of its opening book, which could be too late.

• Don’t make scourge at all versus mass corsairs or mass battlecruisers. They’ll shoot down almost all of it, at huge cost in gas and larvas. There are disadvantages to this decision, like loss of drop defense, and I’ll relax it when scourge gets smarter.

• Battlecruisers more strongly call for a hydralisk answer.

• Tanks more strongly contraindicate lurker production. I was still seeing some lurkers even versus mass tanks.

openings

However long it may take, opening selection using data is coming. When it arrives, the advantages of having many builds will increase and the disadvantages will fade. I felt free to add as many ideas as I could come up with.

• Removed 4Scout, which is functionally identical to 5Scout, and added 7Scout 8Scout 8Overscout. 5Scout and 6Scout remain. These are fast scouting builds which leave all decisions to the strategy boss. They can be appropriate when the opponent is unpredictable but tends to play into the strategy boss’s strengths—it does happen.

• Added new 7PoolHarder 7Pool10Hatch 8PoolHard rush builds. Can’t have too many different rushes.

• Updated 8Hatch7Pool 8Hatch7PoolSpeed 8Hatch7PoolBurrow 8Hatch7PoolBurrowB to be more efficient.

• Added 9PoolFastLair 9PoolFastSpire 9PoolFastSpireB 9PoolFastLurker, which get the fastest possible lair after a 9 pool. The 9PoolFastSpire variant is more suitable versus zerg, and 9PoolFastSpireB versus protoss forge expand.

• Added OverpoolFastLair ZvZ_OverpoolFastMuta, which get the fastest possible lair after an overpool.

• Added Overpool14Hatch, which seems like a good opening stem versus protoss. After the spawning pool it makes 4 drones (not 3) and 2 pairs of zerglings (not 3), then the second hatchery. With appropriate followup, which doesn’t happen yet, it should be fine versus either 1 base or 2 base protoss play. If the strategy boss knew how to adapt properly, I would have marked this as a key improvement.

• Added 11Gas10PoolMutaB 11Gas10PoolLurkerB. When I first added the 11 gas 10 pool build, way back in Steamhammer 1.0, I debated whether to make 2 drones after the spawning pool and before the lair, or 3. I settled on 2, because it seemed safer in ZvZ; the third drone delays zerglings slightly. These minor variants make 3 instead.

• Added 12-11HatchStem, a 3 hatch before pool build which stops after the spawning pool finishes, without making any lings. Steamhammer already has a couple other variants, with specific continuations.