Starcraft AI blog

CIG submission is closed. I received no acknowledgement other than “upload successful” with the second browser I tried, so I don’t have full confidence in the process. Anyway, here is the change list for Steamhammer 1.4.5, the CIG 2018 version. Instead of laying foundations as I have been doing in recent releases, this time I concentrated on making the biggest play improvements I could in a short time. Steamhammer should play visibly better, though I can’t judge how much. The most important changes are in bold.

As I mentioned yesterday, the CIG version is not quite right for SSCAIT. I need to undo small changes that uphold unhelpful CIG rules, and to test terran and protoss. Expect version 1.4.6 tomorrow or thereabouts.

overlord behavior

• Release the scout overlord when the enemy is seen to have anti-air. Against terran, almost any enemy unit or building implies anti-air tech, so the overlord tends to be released early. Normally, an overlord released early in the game leaves the enemy base; later in the game, it may not.

• Always send out a scout overlord. The exception of sending no overlord against terran is dropped, because the overlord is now safe enough. A terran base may be found sooner, and the response to a terran worker rush is improved because the overlord hangs around the enemy base.

• Overlords not assigned other duty now go into an Overlord squad. The overlord squad furnishes 2 easy skills: 1. It assigns 1 overlord to each base, so that Steamhammer stays ready for cloaked units. 2. If the enemy has flying overlord hunters, and Steamhammer has spore colonies, gather free overlords at the spores. The skills are crude; if neither condition applies, the overlord is left where it is, even if it is under attack from the ground—and even if it is a released scout overlord in the enemy base. Nevertheless, it’s a clear improvement, because Steamhammer used to have no overlord survival skills whatever. Better would be to retreat from danger and seek out safe places to watch from.

• If the enemy has no cloaked units, and the enemy does have anti-air, then assign no overlord to the Ground, Flying, or Recon squads. Missing the overlord is unfortunate, because the overlord provides a wider vision range and can see uphill, but keeping overlords safe has priority. The change saves overlords from being shot down by marines or dragoons. The game commonly proceeds: Overlords are assigned; enemy gets anti-air so overlords are released, and may be shot down but at least no further overlords are sent to die; enemy gets cloaked units so overlords are assigned again, because now it is worth the risk.

• Assign a detector to each defense squad, under the same conditions of cloaked enemies and anti-air. Defense squads used to simply hope that overlords were hanging around the base in detection range of intruding dark templar, and the hope was often dashed.

other tactical changes

• Predict enemy movement. When moving to attack a specific enemy unit, most units now move toward a predicted enemy position 8 frames in the future, rather than the enemy’s current position. Mutalisks and vultures don’t use prediction, because they are controlled by special-case code that works differently. The main purpose may sound surprising: To get rid of the enemy scouting worker! Using prediction, even a slow zergling can catch and kill an evading worker. I think Arrakhammer was the first zerg to demonstrate the skill, and Stone may have been the earliest bot to predict enemy unit movement. Besides more effective chases, unit micro is improved in general, because units come into firing range sooner.

• Squads defend and retreat toward the starting base, if we still own it, not the ever-changing “main” base where we add buildings. This change prevents one major cause of retreating through the enemy formation. There are other causes, so it still happens.

• When a unit in retreat finds itself blocked by an enemy (according to a simple geometry calculation), instead of continuing the retreat it stops to fight on the spot. I think this is probably a net win because it tends to delay the enemy advance, but sometimes units that could slip by safely instead stop to fight and are lost unnecessarily.

• When regrouping, air units stick closer together. Historically, regrouping treated air units and ground units the same. But air units stack, and often gain an advantage by being stacked, so now they get a special case. This modestly improves mutalisk play (on average) by grouping them tightly when they reach their retreat point.

• Defend is a regroupable order, or in other words, a defense squad retreats when the enemy is superior. I’m not sure whether this is a net win by itself; I didn’t have time to add the smarts that would make it a definite gain. It prevents the severe mistake of making a last stand outside of static defense range, but causes the severe mistake of fleeing from a stronger enemy when it should engage to delay as long as possible.

• Static defense is never considered 100% adequate; when under attack, Steamhammer always assigns at least 2 mobile defenders. Formerly, Steamhammer would calculate “eh, the sunkens will hold.” It was usually right, but that did not help when the enemy maneuvered to harass while staying out of sunken range. Iron does that, for example.

• If an enemy attacking a base has no anti-air, prefer to assign flying defenders. Mutalisks are better than zerglings against vultures, but also against tanks, zealots, and firebats.

• Because I was doing a bunch of work on squads, I clarified the hard-to-read squad info display for debugging. Map coordinates are converted to tiles rather than shown in pixels, which makes them shorter and easier to interpret. The Base Defense squads are renamed to Base squads for brevity. Most importantly, each squad shows its attack/retreat status at the top of the screen on its line of the squad info display, rather than at the bottom of the screen overlapping with the status of other squads.

player methods, not type methods

UAlbertaBot always got unit ability information from the unit’s type, and I copied that in Steamhammer when adding code. I was slow to realize the advantage of getting the information from the player object, which knows whether the unit has been upgraded.

After these changes, I can see the difference in hydralisk play, but I am not sure how important it is in practice. There was no time for a long test to find out.

• Changed unittype->topSpeed() to player->topSpeed(unittype) in several cases. The biggest effect is on kiting of hydras (since hydras have a speed upgrade). There is also a small effect on the decision of whether to chase after an enemy unit. Vultures have a speed upgrade but are not affected, because they are kited using the same special code as mutalisks, and that code works differently.

• UnitUtil::GetAttackRange() uses attacker->getPlayer()->weaponMaxRange(weapon), which simplifies the code and is probably accurate in more cases.

• Micro::KiteTarget() also uses unit->getPlayer()->weaponMaxRange(weapon) to find weapon ranges for both the kiting unit and its target. It affects hydra and dragoon kiting, because those units have range upgrades. It also affects whether kiting happens, which depends on whether the target unit has a longer range.

other stuff

• MacroLocation::Front added to represent “the front of the base,” the spot in either the main or natural where defenses should go. The calculation is done in a simplified way. If there is no natural and the main is the front, then because Steamhammer doesn’t understand chokes yet, the front is in the direction of the natural, which is often (but not always) close to the direction of the ramp to the natural. If the front is the natural, then for the same reason the front is opposite the minerals. See Bases::frontPoint() for the easy calculations. Passing units disturb building placement, and units often pass the front, so unexpected placements are possible.

In most cases, creep colony @ front is a much better place to put defenses. Sunkens are usually set close together instead of spread around the hatchery, and on most maps tend to be somewhat toward the natural choke and somewhat toward the ramp, defending both. There are times when Steamhammer blocks its own ramp with sunkens, though. You can get the old behavior with creep colony @ macro or creep colony @ natural.

MacroLocation::Front is used in most openings and in strategy reactions in the zerg strategy boss. It is not used for placing spore colonies, which should typically not be all the way in front.

• There was a serious bug in PlayerSnapshot::takeSelf(), which counts our units by type: All units had count zero. It worked when I wrote it, but suffered an editing slip later. It formerly wasn’t used, so the bug didn’t affect play, but now it is used.

• Recognize a cybernetics core as anti-air tech only when it completes. This is a tweak to convince the scout overlord to stick around an enemy protoss base until the cyber core finishes, so the overlord watches as long as it can without putting itself in danger.

• Added a new method InformationManager::enemyCloakedUnitsSeen(), which recognizes a different level of danger than enemyHasCloakTech() or enemyHasMobileCloakTech(). It’s used to make overlord decisions.

• The cloak tech recognizers now recognize cloaked units that they can’t identify by type because they are not detected. What an odd oversight.

• Certain air tech and cloak tech recognizers cross-set each other’s flags when appropriate: Yes, if you have overlord hunters, then you necessarily have air tech. This is a speedup optimization that does not affect play.

• The resource box is fixed. I changed BuildingPlacer::computeResourceBox(), which computed for the starting base only a box around the minerals where buildings should not be placed, to reserveSpaceNearResources() which marks as reserved those tiles at any base which should not be built on to avoid mineral or gas mining problems. Since sunkens are now normally placed @ front instead of surrounding the hatchery, the effect is not big. But spores are still placed around the hatchery, and this prevents spores from messing up mining.

• MicroRanged understands that dark swarm does not protect buildings. Units mistakenly believed they could not attack a building under swarm. Oops.

zerg strategy and reactions

• If too far behind in army size, make more army. Marian Devecka called out army size as a major weakness (too little army due to making too many drones), and Proxy suggested an easy way to repair it. I knew it was a weakness, but I had resisted making changes to the drone/army balance because it is difficult to do right. This way is not right; it is rough and will go wrong in common cases. Besides being crude, it is probably not tuned well due to lack of testing. But it is still much better than what Steamhammer did before. Play against protoss especially is clearly improved, though Steamhammer sometimes expands too little instead of too much.

• When rebuilding drones to recover from a severe setback, mix in zerglings if the enemy army is stronger. It should improve the odds to survive some major emergencies, especially in ZvZ.

• Be slower to make macro hatcheries, and place fewer of them at expansions. This was a critical weakness that made it difficult to survive heavy rushes, even given other adaptations. Steamhammer is now less likely to overbuild hatcheries, and more likely to float minerals. It can’t balance correctly without prediction skills that it does not have, but now it balances closer to correctly on average. It’s a net gain.

• Steamhammer classically made up to 4 defensive sunkens when necessary. I bumped the limit up to 5. It helped more than I expected.

• Be a little slower to expand solely to get more gas.

• Spore colony placement is a little smarter. Since it first gained the feature over a year ago, Steamhammer has always made only 1 spore colony, at whichever base is currently designated as the place to add buildings. Now it makes 1 spore when it sees a threat, and adds a second spore if the threat is high. Versus protoss, the first spore goes at the natural in case it is needed to help defend against dark templar, and the second spore goes at the current “main” (which may not be the starting base). Otherwise the placement is the other way around: Main then natural. There are cases where it builds the 2 spores at the same base. The spore colony change works together with the overlord changes to improve both overlord safety and dark templar defense.

protoss

• Added a one-base CorsairZealot opening for protoss, which I used to test zerg overlord reactions. The opening turned out to be strong against Steamhammer’s zerg, so I configured it to be played.

code changes

• Fixed a latent bug in CombatCommander::updateIdleSquad(). In aviation safety terms, this is a major hazard, which is defined as “you’re still OK as long as nothing else goes wrong.” Make programs as safe as flying!

• Various stuff related to bases moved from InformationManager to Bases. The process is still underway.

• Deleted the unused methods InformationManager::getIndex() and nearbyForceHasCloaked().

• Clearing of neutral “blocker” buildings was written for the map Sparkle. It turned out to have a bug on the map Pathfinder. At the natural of the top base, one of the neutral eggs was recognized as a blocker and destroyed—not ideal, but not much of a problem either. The bug is that Steamhammer failed to recognize that the egg had been destroyed, and units were permanently assigned to keep trying to destroy it. Instead of fixing the bug, I turned off the tactical reaction to blockers. It was easier and has bad effects only on rare maps like Sparkle.