Starcraft AI blog

Yesterday I wrote up Steamhammer’s scouting improvements. Today is the rest of the change list.

stuff affecting squads and combat

• Added a parameter setting to each squad: For combat simulation, include either all known enemy units in the area (including remembered units that are out of sight), or include only visible enemy units plus known static defense. For most squads, it is useful to include all known enemy units, so that you don’t attack a superior force when you momentarily can’t see all of it. It’s especially useful for a squad of zerglings, which have a short sight range. The Recon squad is set to fear visible units only, because its purpose is to see what is there.

• The combat simulation radius is also a parameter setting for each squad. The primary combat squads have a large radius so they can try to understand the ultimate outcome of a battle (though it’s questionable whether this is a good idea). The Recon squad has a small radius, so that it does not fear distant units that it is out of range of. That lets it come closer and see more.

• If we can see the last known location of a remembered unit (its lastPosition) and the unit is not there, we flag it as goneFromLastPosition. We keep the lastPosition and know when it was set, so we can narrow down where the unit is now (which is not done yet, but someday). This is a feature from the when the enemy unit is out of sight post. Units which are goneFromLastPosition are skipped in combat simulation, which makes Steamhammer more aggressive. Of course the unit might still be nearby, so Steamhammer is taking a risk, but it seems better than fearing ghosts.

• Squads no longer single-mindedly attack the enemy main. The combat commander prefers to issue orders to attack the enemy base with the least static defense. It’s still not very smart, but the tactical play is much more interesting and varied. There are other tweaks.

• A bug in tactics calculation prevented the combat commander from issuing orders to a squad to attack enemy units, which it will do if there are no enemy bases the squad can attack. Fixed.

• Valkyries, corsairs, and devourers now play much better. Since they are unable to attack bases, the bug fix above to send them to attack units was critical. A new unit micro controller, MicroAirToAir, helps the flying squad make better use of these units. Steamhammer no longer sucks with devourers and protoss corsair openings are stronger.

• Ranged units like to hit air targets that have acid spores on them. Get full value from those devourers.

• Queens, defilers, and dark archons are recognized as combat units and assigned to squads. Steamhammer can’t use any of these spellcasters (yet), but there’s no reason to ignore them.

• Due to mis-nested conditions, if you asked a squad whether it had any air or ground units, flying detectors were counted as ground units. Fixed.

• UnitUtil::GetWeapon() makes the simplifying assumption that a bunker has marines in it. It used to ignore bunkers. Someday Steamhammer will attempt to keep track of whether a bunker is loaded, but not yet.

• InformationManager::getNearbyForce() includes enemy medics. They were mistakenly excluded by a weapons range check. It was a serious bug.

• InformationManager::getNearbyForce() checks enemy attack ranges more accurately. It makes little difference in practice.

• InformationManager::getNearbyForce() no longer returns detectors. It is used to feed the combat simulator, and FAP does not support detectors, so it was no help.

• In FAP, added N00byEdge’s September patches: A scarab is a suicide unit, medics heal less.

other

• Recognize some enemy opening plans. This is part of the opponent model. For now, only zerg takes advantage. The plans Steamhammer tries to recognize are named Proxy, WorkerRush, FastRush, HeavyRush, and SafeExpand (which means natural with cannons or bunker). It doesn’t always recognize them successfully, but when it does I find that it is rarely wrong.

• Added the macro act command "go nonadaptive" for zerg, affecting drone production. Zerg normally adjusts its drone production depending on the situation, even if it is playing a book opening. For example, if the book says “make zerglings” but the opponent has cannons, Steamhammer may decide to make a drone instead (it has even more freedom out of book, of course). The "go nonadaptive" command means to turn off this adjustment process for the entire game and trust that the opening book has the situation covered. The new command is used in openings which counter forge fast expand. This version doesn’t play any of those openings, though!

• Steamhammer’s event-driven base tracking system sometimes gets out of sync with reality. Past versions made corrections in some cases. Now all incorrect stored base information is corrected as soon as possible.

• MapInfo::getNextExpansion() skips bases without enough resources to be worth it. It should fix occasional cases where Steamhammer re-expanded to a base that was mined out.

• MacroAct::mineralPrice() and gasPrice() are now correct for upgrades beyond level 1. See upgrade prices in Steamhammer.

• The configuration file has new flags Config::IO::ReadOpponentModel and WriteOpponentModel. In this version the flags don’t do anything (the file I/O is turned off in code), but in the release version 1.4 they will work. Separate control of reading and writing the files is handy for debugging.

terran and protoss

• Terran and protoss turn off gas collection when there is too much gas, as zerg has always done. “Too much gas” is defined conservatively as 1. over 400 gas, and 2. over 4 times as much gas as minerals, and 3. more gas than is needed to fill all the orders in the production queue. I think the biggest benefit is that the bot can survive after many workers have been killed, when collecting gas causes mineral mining to slow or stop. Gas production starts again when the bot has a use for the gas.

• Adjusted the terran ratio of marines:medics to 5:1. It used to be 6:1, not enough medics. Some people prefer 4:1.

• Added a terran siege-expand opening. Steamhammer doesn’t adapt well enough to play the opening safely in many cases, but I think it should be adequate for TvT.

zerg

• In case of a recognized Proxy, WorkerRush, or FastRush enemy opening plan, possibly break out of the opening and react appropriately. If the opening is already doing something that looks sensible, let it. I did not follow IMP’s advice to not distinguish between plans with the same reaction, because I expect that the reaction will not always be the same (especially for forks).

• In case of a recognized HeavyRush, maybe build a sunken. It is a wimpy reaction, but may help sometimes. This Steamhammer version does not react to SafeExpand, but I hope that the tournament version will.

• Recognize corsairs, scouts, and carriers as countering guardians. What a blunder! That is why Steamhammer kept making guardians against XIMP.

• Recognize goliaths as countering zerglings. Properly, only enough goliaths counter zerglings; their long range makes them deadly in groups. Steamhammer is too primitive to understand that, so far.

• Also what-counters-what tweaks in ZvZ.

• In ZvT, prefer to get lurkers after mutalisks in the standard way. Steamhammer classically rushed to hive, crazy zerg style. I’m not sure whether this adjustment works as intended.

• Always get overlord speed before hive, except versus zerg. This is a concession to the BWAPI 4.1.2 bug that you can’t get overlord speed after hive.

• Prefer to make unit types that already have their upgrades. It’s not a strong preference, though.

• A new “do I have enough units to get away with this?” check to decide when it is safe to tech. For example, if the enemy has air and we don’t, delay less important spending.

• Added a bunch of openings to counter protoss forge expand. This version doesn’t play them, though. I hope the tournament version will.

• Added an overgas 9 pool opening for ZvZ, mostly because it’s fun but also because it’s a good opening.

• Added an OverpoolHydra opening similar to ZZZKBot’s 1 hatch hydra build that it used to defeat Iron in AIIDE 2017. It is a weak build, and I don’t know if it has any other use than to defeat that version of Iron.

• Lurkers can change targets away from a building. See fixing a lurker micro bug.

• Lurkers are little more eager to target a protoss observatory or robotics facility.

• At some point a bug crept in that made it impossible to research lurker aspect if you had a hive. Fixed.

• In ZvZ, get queen’s nest and hive only once you have at least 12 mutalisks. Steamhammer was losing games by teching at an insane rate.

• Other minor strategy changes to mildly encourage making more combat units.

• Never have more than 9 devourers at a time. See too many devourers.

• A new feature is supposed to prevent zerg from stopping gas collection if that will cause drones to go idle. If you have excess drones, you might as well collect gas whether you need it or not. Unfortunately, the feature doesn’t seem to be working, though I can’t find a bug.

code changes with no effect on play

• Renamed the MainAttack squad to Ground. MainAttack used to be a good name, because all the squad wanted to do was attack the enemy main, but now it has wider ambitions. The 3 combat squads are now named Ground, Flying, and Recon.

• The capitalization of MapGrid::getUnits() was nonstandard. Fixed.

• Removed the unused MapTools::_units instance variable.

• Renamed RegroupRadius in the config file, also known as Config::Micro::CombatRegroupRadius in the code, to CombatSimRadius, since that is what it is. A unit that can fire into this radius around the combat simulation center point is included in the combat simulation. Also it doesn’t hurt for the names to be consistent.

• Rewrote UnitData::updateUnit() to be slightly simpler.

• There was still a redundant mention of SparCraft in the VS settings. As far as I can see it caused no harm, but it’s gone now.

• Map-related data structures use short ints to push less other stuff out of cache. I cleaned up the typing of short ints so that the compiler understands that the type conversions are safe, though they were already.

• In FAP, I initialize the closestDist local variables in 3 routines, solely to avoid compiler warnings when warnings are set to a high level. The code was correct, but the compiler is not smart enough to tell.

• All the debug configuration “Draw...” options can be set manually during the game using /set. It can save time in debugging. I had added some options without adding corresponding commands.

• I renamed all the Micro::SmartX routines to Micro:X to reduce noise in the code text. It doesn’t need to brag. For example, Micro::SmartMove is now Micro::Move.