Starcraft AI blog

Steamhammer 1.2.2 is uploaded. It is a bug fix release, mostly to fix strength-reducing bugs introduced in 1.2.1.

Next will be 1.2.3, primarily a feature release to help all races play stronger and more interesting games, then 1.2.4 to fix lingering bugs.

bug fixes

6 bugs are fixed, 3 serious bugs that caused losses for all races in version 1.2.1, and 3 zerg bugs that are smaller and didn’t cause any losses that I could identify. There are still no known crashing bugs.

• The bug in retreating to the natural is fixed. When retreating with no fresh units on the way, Steamhammer now retreats to the natural if it has been taken, or to the main otherwise. Retreating blindly to the natural caused many losses when the bot did things like retreat from the main to the natural when the enemy was at the ramp. (Squad::calcRegroupPosition())

The retreat system is confused in the first place. The first choice of retreat point is the closest friendly unit that is not “near” the enemy. It is supposed to close up gaps in the formation—that is why it is called “regrouping”. But in practice the closest friendly unit might be anywhere, and Steamhammer may retreat to the natural, to the main, or in a direction that makes no sense at all. Only when there is no friendly unit to retreat toward does it retreat to the natural or main as appropriate.

• Errors related to pulling workers for emergency defense are fixed. There were subtle issues causing workers to be left in the base defense squad after they were supposed to be released. It sometimes caused weird worker dances and other bad behavior. I also tightened it up; workers are now pulled to fight a proxy only if no combat units are out yet, and to fight zerglings only when they come very close to the mineral line, and otherwise not at all. Steamhammer will self-destruct less often, and (I hope) continue to successfully defend itself when it can. (CombatCommander::updateBaseDefenseSquads()—I renamed it for consistency.)

• A change in 1.2.1 to put more idle workers back to work introduced a bug where it also put building workers back to work before they started building, sometimes delaying the start of construction by as much as a few seconds. When timing is critical, it causes losses. In particular, it caused the 9 hatch opening to lose to 9 pool, when it should defend in time. Excess worker pulling contributed. (WorkerManager::updateWorkerStatus())

Lukas Moravec has found another bug that makes buildings start later, but the effect is smaller. I decided to delay fixing it until I understand it thoroughly.

• Zerg mistakenly made sunkens to defend against air attack. Oops. (StrategyBossZerg::checkGroundDefenses())

• Zerg was ignoring its absoluteMaxDrones value and making too many drones in long games, cutting into the supply available for its army. (StrategyBossZerg::updateGameState())

• Zerg catches more cases of deadlocks that cause production freezes. It should only have happened when Steamhammer was already in trouble, though. (StrategyBossZerg::nextInQueueIsUseless())

other improvements

• I tuned up the ZvZ 12 pool opening, and adjusted some opening settings.

• The true/false configuration options KiteWithRangedUnits, WorkersDefendRush, and ScoutHarassEnemy can now be set differently per race, to better support playing random. The feature is not used in the default configuration; all races are set to the same value. I also removed UseSparcraftSimulation, since it was already unused in the code.

Stone

This version does do worse versus Stone. In a test match, it scored 12-3 with 2 close calls where it went down to 2 drones. When worker defense was first implemented, Steamhammer scored 15-0 with 1 close call where it was taken down to 3 drones. The cause seems to be the return cargo bug fix. The effect is hard to see, but it makes workers more likely to stop and defend themselves in spots where other workers will not help them out. I decided that the correct fix is to improve worker micro, and I didn’t want to try something so delicate in a bug fix release.

Steamhammer 1.2.2 needs no more work, but the SSCAIT stream seems to be down so I guess there’s no point in uploading it right away. I’ll use the time to run extra tests and make extra sure that it’s extra solid. The last release was not tested carefully enough, but this one should be good.

I put in 3 serious bug fixes that affect all races, 3 lesser bug fixes for zerg, and 2 minor improvements. Version 1.2.1 was weaker than 1.2; if I did my job, version 1.2.2 should make up the difference and then some.

It’s April 1, time for Big Game Hunters, and—ack! Steamhammer is refusing to start up on the map! Another bug to fix, and one that may not matter again until next year. I regularly try it on maps outside the SSCAIT pack, but not on maps this strange.... Should I add another test to my release checklist?

Update: It’s working for me locally, with the WebMaps version of Big Game Hunters. What version of bgh is SSCAIT using?

Documentation is written, a bit slowly, as usual. Updating for future versions will be quicker, also as usual. I am now allowed to touch the code again.

It’s short. Is it good? Will it help people get started (or decide whether to get started)? It’s only possible to write documentation if you know details, and it’s only possible to judge documentation if you don’t, so... I’m listening.

version 1.2.2

Version 1.2.1 seems to be 100 points weaker than 1.2, rather than 20 points stronger as I expected. Almost all the strength loss seems to be due to the single retreat-to-the-natural bug. Nevertheless, doing my best to follow the zero-one-infinity rule, I’ve identified a half-dozen quick fixes for version 1.2.2. Expect it in 2 days, plus or minus 1 day.

1. The feature of retreating to the natural base if it exists is buggy. Steamhammer always retreats to the natural, whether it has been taken or not, causing trouble especially in ZvZ games. This is hilarious, if “hilarious” means “it’s bad, but at least it’s easy to fix.” I added the feature at the last minute with only a brief test: Tally another loss for poor testing and inadequate commenting!

2. Meanwhile, units that retreat to recover from their damage still return to the main, not the natural. In general, the code has confusions between retreating the squad and retreating individual units to regenerate (which only applies to melee units, and only if configured). It doesn’t seem urgent to fix, though.

3. A unit which is inside the minimum range of a sieged tank refuses to retreat with its squad. It doesn't necessarily attack the tank, but it attacks something. This behavior has only triggered a couple times, but so far it looks like a successful improvement.

4. The system of pulling workers for defense is questionable. If it made correct decisions, it would be great. As it stands, it is sometimes good and sometimes bad, and I can’t judge whether it is worth it overall. It averages out pretty close to zero, maybe?

5. I thought the loss against Stone was due to a new weakness, but on a closer look I don’t see one. It’s the first loss against Stone since worker harass defense was implemented, so I’ll test more closely to make sure.

6. Speaking of worker harass, gas workers now defend themselves the same way as mineral workers. I don’t know whether this will turn out to be a win, because harassed gas workers get switched out; harassment can potentially disrupt gas mining. So far, this behavior has triggered against LetaBot, when it looked highly effective. But LetaBot is a lazy harasser, so the jury is still out.

7. Other surprise losses by Steamhammer were due to randomly choosing openings that the opponent countered. For example, in the first ever loss against protoss Lukas Moravec, Steamhammer went 5 pool, which was objectively poor against the 2 gate opening. Steamhammer nevertheless pulled ahead and was winning until it bungled its tech switch.

I’ll be inserting another bug-fix release to solve the retreat-to-natural bug before I get down to features.

Steamhammer’s web page is updated with source. This time I’m not touching another line of code until the docs are all up to date. I was walking through the forest and I strayed from the path....

Steamhammer 1.2.1 is out. All races should play more strongly. Steamhammer 1.2 kept up an average elo in the high 2200s, peaking over 2300. I think 1.2.1 is likely to average over 2300.

I was originally planning more improvements for protoss than for other races, but it turned out differently. Terran got the most improvements, and protoss the least. Terran needed them more. Version 1.2.2 is planned to focus more on features than on bugs, and will have some protoss features.

Web site update tomorrow, with source code.

I tried to make this change list more thorough and detailed than earlier ones, since more people are using Steamhammer code. It’s a nice long change list; I got a lot done this time.

config file

• Some options can be set differently for each race, to support playing random.

• New build order commands “go defensive” and “go aggressive”. Defensive means that your units stay at home for the time being; aggressive means that they seek out the enemy. The default is to be aggressive all the time, which is good for zerg. For terran, “go defensive” is good at the start of most openings. For protoss, I had the dark templar rush stay defensive (with its one zealot and one dragoon) until the dark templar start. If you don’t go aggressive in the build order, aggression automatically turns on when the opening build order is over. For now, the only way to stay defensive longer is to write a longer build order (or write code).

• New debug option drawUnitOrders. Besides unit orders, it draws on the screen what a research building is researching and what is going to come out of an egg, cocoon, or production building. I’ve been using the option often.

macro changes

• Updated terran and protoss openings and production code.

• Terran and protoss build more workers.

• All races pay closer attention to the configured maximum number of workers per mineral patch. WorkerManager::getMaxWorkers() gives the largest number of workers that can efficiently mine your existing bases, based on the configured values and the resources at the bases.

• The scout defense worker (used only by terran, in the default configuration) is less likely to move out while carrying minerals. Losing minerals is bad luck.

• More idle workers are recognized and put to work.

• Choosing a new main base caused mostly minor but widespread confusion, now fixed. Various bits of code were unclear about the difference between the start location and the current main base. The most obvious effect was that the first expansion sought after a new main base was chosen was always the start location, which had usually just been destroyed and might still be occupied by the enemy.

• Protoss is less likely to overstep the time limit when its main fills up with buildings. The problem turned out to be fundamental to the building placer, and I resorted to cheap hacks. Someday I’ll spend a few weeks to write a proper building planner with more capability. For now I tightened up protoss building placement so that more buildings fit, spread pylons farther apart so they power a larger area, and taught the production manager not to retry the building placer on every frame after it fails once (which caused a huge slowdown). All 3 measures together are still not sufficient, so I may do more in the next version. One cause is that BOSS orders up more gateways than it needs; its production plans are not as efficient as promised.

• The zerg strategy boss discounts extractors at destroyed bases. It was a minor bug that I could fix in passing.

• Zerg doesn’t make double queen’s nests, a rare bug.

• Zerg will no longer order up a hive while overlord speed was still researching in the lair, causing production to pause until overlord speed finished.

• When zerg has extra larvas and minerals and is short of gas, it goes ahead and makes zerglings. Version 1.2 will often wait for gas, letting minerals build up and reducing total production. Steamhammer’s late game armies will tend to be larger.

micro and tactics changes

• Turned special vulture kiting back on. Vulture micro should be improved.

• Terran by default uses the scout defense feature, unlike protoss and zerg. Terran needs to take extra measures to protect SCVs that are constructing buildings.

• Terran loads and unloads bunkers as needed. It’s not very skilled at it, but it does the basic job. I added a new 8RaxDefense opening to illustrate it (and also to hold rushes for which the bot’s micro is too weak).

• Bunkers can be placed tight up against obstacles.

• Terran builds comsat stations and scans cloaked units (even if it doesn’t have anything around to fight them).

• When terran needs emergency detection, it builds 3 turrets, not 2 like before. It seemed necessary.

• Tanks unsiege to fight buildings, or to target enemy units that are too close for siege fire. Tank sieging behavior is still impressively stupid, but it’s a little less bad.

• Protoss is configured to retreat zealots and dark templar which are seriously hurt, hoping they can regenerate shields. (Zerg has retreated weakened zerglings for a long time.) See the RetreatMeleeUnitShields and RetreatMeleeUnitHP config options.

• When zerg sees vultures, it builds a sunken in its natural (unless it already has one). It’s a simple measure to reduce the harm of vulture raids. When Steamhammer accidentally places the sunken in a good spot, it holds out much better against Iron in particular. Future versions will put up stronger defenses.

• A zerg broodling attacks and does not retreat. It doesn’t live long, it can’t afford to waste time.

• For all races, a unit directly next to a sieged tank attacks and does not retreat. If it retreats, it will likely die to siege fire; better to do damage instead.

• Units retreat to the natural, not the main, if the natural has been taken. As suggested by MicroDK. It turned out to be only a couple lines of code, so I threw it in.

• Reavers are targeted with higher priority. It was an oversight.

• Gas workers now defend themselves against harassment, the same as mineral workers. It should reduce worker losses a little more.

• Bugs related to pulling workers for base defense are fixed. The main symptom was that workers at all bases froze in fear, even when another base entirely was under attack. The problem was that putting workers in a base defense squad did not change their job. I had assumed without checking that they would be given the job CombatWorker, but instead they kept the MineralWorker job, so the mineral worker self-defense code interfered. Now workers pulled for defense become combat workers, and WorkerManager is responsible for their combat orders; the squad knows not to issue orders of its own, and resets the workers to idle when they are released. I tried to make WorkerManager a trifle smarter about combat; we will see how that turned out. Finally, I adjusted the conditions under which workers are pulled and tried to make sure that they are never pulled across the map. Zergling rushes are defended again, if configured, and it is turned on by default although I’m not sure it’s a good idea—it sometimes helps and sometimes hurts. In any case, the worst misbehavior should be gone.

• Base defense against air attack now accounts for turrets, cannons, and spore colonies. Fewer defenders are called home if there is static defense to help. (Base defense against ground attack already accounted for static defense.)

• Steamhammer used to go on the attack when its supply went over 170, and revert to normal behavior when its supply fell below 170. When production was high enough it worked well, but other times it caused loops: “Attack! Oh, retreat. Attack! Oh, retreat....” I added hysteresis. Now it starts the attack when supply reaches 195, and does not stop until it falls below 160.

code fixes

• Some cleanups in CombatCommander.

• UAlbertaBot often uses double instead of int where it calls unit->getDistance(), which returns int. It’s not a bug, but it causes unnecessary computation. I fixed some of them, but not all.

• ProductionManager works around a BOSS bug in ordering up comsat stations. If you add a second CC and want a total of 2 comsats when you already have 1, BOSS sometimes orders up 2 new comsats instead of 2 comsats total.

• Removed unused code from CombatCommander, RangedManager and MeleeManager.

• Fixed a sneaky crashing bug in StrategyBossZerg::checkGroundDefenses(), the last known crashing bug.

I recently fixed 2 bugs that then turned around and bit me.

I fixed a bug that caused Steamhammer to make double queen’s nests in around 1 game out of 150. It was a simple missing condition. But I made a typo in the fix: Parentheses in a function call swallowed up the next condition in the if. In any safe language it would have failed to typecheck, but in any case, the result was that Steamhammer made 3 or more queen’s nests in every game. I think C++ was laughing at me—”Nyah nyah! I’m too sharp a knife for you!”

I also tracked down and fixed the last known crashing bug, a subtle oversight in the strategy boss that causes crashes in around 1% of games. I brought up a game for a first test of the fix and... crash! Somehow I replaced a rare crash with a frequent crash, and even though I only touched a little code, I haven’t found it yet.

Well, it probably won’t take long—though who knows? After that I have 2 other critical bugs, and then 1.2.1 will be ready.

By the way, Steamhammer does suffer from one other crash besides the “last known” crashing bug. In rare cases, it crashes on startup. But the crash happens before any Steamhammer code executes, so there’s not much I can do about it without taking a long detour.

Steamhammer 1.1.1 has a lot of resilience improvements over version 1.0. It can rebuild from scratch in a new base after its main is destroyed, for example. I thought that disaster resilience added little to the bot’s strength. In Starcraft, surviving a near-death experience usually means that death is still near.

But lately I notice that Steamhammer 1.1.1 is more consistent than earlier versions. It is rarely upset by much weaker bots, saving many elo points. Unlike in the tournament (version 0.2), most of its upsets are at the hands of opponents which are at least average in skill—and Steamhammer retains its knack of occasionally upsetting stronger opponents.

This game Steamhammer-UPStarcraftAI (elo 2303 versus 1825, compared to the average of 2000) was extremely badly played by both sides. Don’t watch this if you have sensitive eyes, it will hurt! Terran UPStarcraftAI blocked some of its own forces behind its mineral line and was unable to concentrate its strength, while Steamhammer made awful attacks and frittered its mutalisks away, then was unable to defend its natural and lost it. UPStarcraftAI did not know how to proceed and left its victorious army standing idle, and Steamhammer tried to help by suiciding drones and moving zerglings back and forth through the marine formation without fighting (it couldn’t decide which base to retreat to).

Steamhammer didn’t recover neatly, but it did recover. It cleared the idle terrans, built too many drones and took the map while getting upgrades, and finally realized that maybe an army would be useful after all and went ultra-ling, after which (despite some more bad play) the outcome was clear.

Another awful recent game is Steamhammer-DAIDOES (elo 1778), where Steamhammer lost its main but managed to power through its own stupidity—which included stopping at zergling tech level because of a stuck drone—and barely win after mining out.

Resilience against near-fatal disasters is good. Skill in one dimension can rescue blunders in another. The games saved are the ones that would have cost the most elo points—because against a stronger opponent, the game is not saved.

I added a feature to make random play more configurable. Steamhammer 1.2 (which is identical to Randomhammer 1.2) has configuration lines to set the maximum number of workers per mineral patch before a base is “full”.

"Terran_WorkersPerPatch"    : 2.8,
"Protoss_WorkersPerPatch"   : 2.6,
"Zerg_WorkersPerPatch"      : 1.8,

For the next version I simplified it (and decreased the numbers, they were too high; someday I’ll do mineral locking and maybe drop this).

"WorkersPerPatch"           : { "Zerg" : 1.6, "Protoss" : 2.3, "Terran" : 2.6 },

And I allow the same syntax for several other config options in the Micro and Macro sections.

"RetreatMeleeUnitHP"        : { "Zerg" : 8 },
"RegroupRadius"             : 600,
"UnitNearEnemyRadius"       : 600,
"ScoutDefenseRadius"        : { "Terran" : 400 }

You can specify an integer to get the same value for all races, or break out different values for each race. If you leave out a race, it defaults to 0. Here I want terran to pull an SCV to defend itself against the enemy scout (within a radius of 400 pixels) to protect its SCVs while they are building; the other races don’t have that problem and keep mining as much as possible (ScoutDefenseRadius 0 means “don’t bother”).

Steamhammer 1.2 should play zerg a smidgeon stronger than 1.1.1, because of a few fixes. But I doubt the difference is noticeable. I didn’t fix anything important to strength.

After 2 days, Randomhammer’s rating has settled near 2050, a little above the average rating and 200 points below Steamhammer. The bot’s protoss and terran came out far weaker than its zerg. I’ve been looking at the games and thinking about why.

The building placement slowdown bug turns out to be critical for protoss. Randomhammer protoss has reached winning games against tough opponents like LetaBot and Killerbot by Marian Devecka, but tough opponents do not roll over and die, they fight stubbornly. Randomhammer fills up its main with widely-spaced buildings, the building placer slows to a crawl, and the bot busts the time limit and kicks out a loss.

Indecisive army movement is also critical for protoss. It’s harmful for zerg, but deadly for protoss, because the bulky protoss army spreads across the map, and one dragoon or another will happen to see something unimportant that distracts the attention of the whole army. The correct fix is to replace the targeting priority system, a job that needs a lot of detail work. I may try a cheaper fix instead.

Incompetence with terran seems harder to improve. Terran needs a lot of skills to play well, including adaptation skills. I did find the reason behind some strange play when going siege tanks, and fixed it.

Randomhammer beats Steamhammer on average, because Steamhammer’s openings are weaker versus random. When you don’t know what you’ll face, you have to play a general-purpose build. For example, when Randomhammer rolls zerg, it usually plays an optimized anti-zerg opening while Steamhammer is stuck with a tamer 9 pool or overpool. Steamhammer does not have a pro’s ability to play a general-purpose opening as sharply as a specialized one.

As a result, having Randomhammer in the pool of opponents decreases Steamhammer’s equilibrium elo, especially if people think the matchup is interesting and vote for it. Well, difficult opponents make good inspiration—all the better if I can supply the difficult opponent myself.

changes to plans for the next versions

Critical problems are a good excuse to rework my plans. Of course the real reason is that no plan survives contact with the calendar—it has been two days already, it’s time to change it up. The schedule must be rendered meaningless!

I decided to split versions again, so I can make the most important fixes up front and see the results sooner. The fixes now planned for 1.2.1 should delight protoss and leave terran and zerg smiling too. I don’t want to go too deeply into protoss and terran skills, though, because they’ll distract me from my main goals.

1. 1.2.1 - fix critical bugs, add critical skills
2. 1.2.2 - further skills
3. 1.2.3 - other lingering bugs

Now that Steamhammer 1.2 is out, I want to think back over the lessons of version 1.1.1.

Steamhammer 1.1.1 was shockingly successful. The high end of my expectation was that it might reach an elo a little over 2200, and that seemed unlikely. In fact it had a final elo of 2285 and maintained a position as the #3 bot on SSCAIT, behind only Iron and Krasi0. Even when it hit a losing streak (which I helped along by voting for lower-rated opponents that were likely to beat it), it quickly bounced back. What did I accidentally do right?

Compare Steamhammer to AILien. They’re about the same age and both are descended from UAlbertaBot. We’ve helped each other out with bug fixes and ideas. AILien is ahead of Steamhammer in most zerg skills: It has better scouting, better tactical decisions, better building placement, better worker defense, better overlord safety, better cooperation of mobile units with sunkens—I have a lot to do to catch up with it, if I ever can. And yet Steamhammer is stronger by 100 elo, a large difference. What’s going on?

I didn’t expect it and I can’t explain it. Some of the bugs introduced in this version seem devastating, but they turned out to hurt results only against a small number of opponents. All I can do is explain my choices and conclude that somehow they were good choices.

1. Play efficient openings. Steamhammer’s builds are not all perfectly tight, but they’re pretty good and they put pressure on the enemy. I haven’t seen such good builds from any automatic code, whether BOSS or AILien or Steamhammer’s own strategy boss or any other bot. Handmade is still better—so far!

2. Keep the pressure on. Steamhammer plays the full range from fast rushes to economy-heavy openings, but it prefers low-economy pressure builds. I thought: Bots are good at attack and poor at defense, so keep attacking! AILien prefers a strong economy; it’s not a mistake, but it may be less effective at exploiting weaknesses in other bots.

3. Stay strategically crisp. Zerg larva management means that zerg can switch its unit mix suddenly to push the opponent off balance. I took the attitude: Don’t adapt to the situation, drive the situation so that the opponent has to adapt. That’s why Steamhammer makes explicit unit mix and tech target decisions. I directly coded in bias and hysteresis, so that it doesn’t change its mind lightly:

bool StrategyBossZerg::vProtossDenOverSpire()
{
	// Bias.
	int denScore   = 3;
	int spireScore = 0;

	// Hysteresis. Make it bigger than the bias.
	if (_techTarget == TechTarget::Hydralisks) { denScore   += 13; };
	if (_techTarget == TechTarget::Mutalisks)  { spireScore +=  9; };
	...

4. Fix bugs and stay resilient. As it stands, at least half of Steamhammer’s lost games show severe bugs—maybe not game-losing bugs, but deeply harmful bugs that destroy resilience and take away opportunities to come back. The bugs I fixed between version 1.0 and 1.1.1 likely made a big contribution to Steamhammer’s strength.

Are these the real reasons? Well, I already said that I don’t know. If you’ve watched the games, what do you think?

Tomorrow: Early returns from Randomhammer.

Steamhammer 1.2 is out. Headline feature: It plays random (like UAlbertaBot). Steamhammer continues to play as zerg, and Randomhammer is the same code playing random. In its first game, thanks to the voting system, Randomhammer played Steamhammer. Randomhammer rolled protoss, opened 10-12 gate, and won easily.

Randomhammer’s elo is likely to end up lower, since zerg is way more polished. But the protoss is not bad, and it will be a good test. Terran and protoss hit bugs more often than zerg.

The change list is not long.

• In the configuration file, you specify the target number of workers per mineral patch separately for each race, as a floating point number. I set it to 1.8 for zerg, down from 2.
• New middle game production code, with longer tech paths than UAlbertaBot.
• Openings.
• 4 terran openings and 7 protoss openings, with random choice.
• Terran and protoss openings use the OpeningGroup feature to share middle game production code.
• Fixed a bug that prevented “2 x dark templar” from working due to the space character in “dark templar”.
• Zerg’s 9 pool speed opening is updated to fix a mistake introduced in 1.1.1.
• Worker defense: Attack stuck as well as non-moving enemies. (An unnoticeable tweak—for now.)
• Emergency cloaked unit defense: Fixed a bug that caused the queue to explode.
• Terran resumes construction after a building SCV is lost. (UAlbertaBot leaves the incomplete building there forever.)
• Small updates to the zerg strategy boss.
• Fixed a potential crashing bug.
• Fixed a bug that could explode the queue when there were fewer than 3 drones.
• Fixed a bug that could cause double ultralisk caverns.
• Minor adjustments to the heuristics.

It was not hard to get protoss to play a decent game, but terran is tough. In my tests, Steamhammer 1.2 terran scores much worse than zerg or protoss. In a random-on-random test with a development version versus UAlbertaBot, Steamhammer protoss scored 8-1 and terran scored 1-7 (there were no mirror matchups). Another example: Against Stone, Steamhammer protoss survived on the first try. Terran did not, because Stone gangs up on building SCVs. Resuming buildings which lose their building SCVs was a necessary skill to give Steamhammer terran any chance at all; it can survive Stone occasionally. Terrans that beat Stone reliably have 2 other skills that I did not implement, replacing the building SCV when it gets hurt and pulling SCVs to drive the attackers off.

UAlbertaBot’s building placer started to show problems in longer games. UAlbertaBot plays rushes and doesn’t see many long games. The building placer wants to build everything in the main; when the main fills up, placement slows down drastically and may overstep the time limit.

I made a forge fast expand opening for protoss, but I have reservations because of other limitations of the building placer. In Steamhammer, you can ask for buildings to be made in the natural, and it works. The building placer knows to leave the nexus spot open. But it doesn’t know the plan, and may place the pylon in a spot without room for a forge, 2 cannons, and a gateway. If there’s no room, the build freezes and the bot will lose. I worked around it for now by inefficiently building extra pylons in the main for the gateway and everything after. Even so, it fails sometimes on SSCAIT maps when it can’t place the forge. Someday I’ll drop the building placer for a building planner, but that will probably be a long time from now.

version 1.2.1

I didn’t get everything done that I wanted, so I’m changing my plans for future versions. 1.2.1 will be mainly a feature version. Here are the features I hope to add, in order of priority.

1. loading and unloading for terran bunkers
2. simple measures so zerg can better survive vulture attacks
3. basic drop skills for terran and protoss
4. reavers
5. psionic storm
6. stim for marines
7. mixed strategies versus specific opponents when playing random
8. generalize certain zerg smarts so that terran and protoss can benefit

It seems to me the best tradeoff between getting key skills and getting finished. I’m leaving out a bunch of other basic skills: Overlord hunting (needed for wraith and corsair play versus zerg), mine laying, keeping medics close to marines, carriers, picking up dropped units....

There are also critical problems I want to fix. Others are likely to come up.

• the bot falsely believes that mining SCVs block the comsat from being added
• aimless play when the army gets distracted by units all around

version 1.2.2

Then the following version, 1.2.2, becomes the cleanup bugfix version. There are 2 bugs that pass invalid parameters to Micro::SmartMove(), at least 3 bugs that cause expansions to fail to be made, and 2 bugs that cause workers to go idle unnecessarily. I hope to stomp at least 5 of those 7, plus of course anything that turns up from playing random on the server.

version 1.3

Version 1.3 will be my start on mutalisk skills.

Steamhammer 1.2 is taking longer than I expected. It may end up being a few days later than promised. It’s not as fun to work on protoss and terran, and I’ve been putting less effort in.

I have given it a workable set of a half-dozen protoss openings to play in a different mix versus each race. There are still a couple of critical bugs (why can’t it make a photon cannon?). The terran openings are giving me more trouble. UAlbertaBot turns out to be short of terran skills. It doesn’t know how to stim marines, so bio builds are weak, and it doesn’t know where to lay spider mines, so mech builds are weak. (There’s a routine to lay mines, but it is never called.) And I’m not excited about adding the skills. The terran openings will not keep up with the other races.

BOSS truly does work much better for protoss than for zerg. Steamhammer’s protoss play using BOSS with simple goals shows better macro than Steamhammer’s old BOSS versions did with carefully-chosen goals.

UAlbertaBot does include a protoss drop skill, which in a test almost worked. It built a shuttle and flew it in a cautious path along the edge of the map to the enemy base—all it forgot was to load zealots first. If I don’t run into any surprise trouble, I’ll get it working for protoss and terran and include a drop opening or two. With XelnagaII disabled, no bot currently plays dark templar drop, and that’s a shame.

Also, Steamhammer 1.1.1 is showing some severe bugs that sabotage its play, especially in long games. So before I get into the 1.3 series, I’m planning a bug fix version 1.2.1 that fixes the worst bugs and restores good macro in long games. That includes protoss and terran bugs that may come up in version 1.2.

OK, this is officially Too Much. Steamhammer hit a string of good luck and its elo went over 2300—it should be about as high as this version gets. After its first loss to Steamhammer, Krasi0’s opening learning is still struggling to find the answer (which is: go back to the default build and win almost all games). After many losses against Iron, Steamhammer scored back-to-back wins, which can only be called luck. The wins came with opposite opening styles. One game was 9 pool speed. Steamhammer transitioned to mutalisks, which fought well enough to stop serious drone loss from the vultures. Iron built mass turrets but was unable to cope on the open map, and ultralisks eventually put in the final word. The other was 3 hatch muta. In the second game, the mutalisks were early and numerous and cut down Iron where it stood. A bunker and a couple rings of turrets are not enough; this mainstream opening is a flat-out counter to Iron’s build. If zerg took a little more care in defense, Iron would stand no chance against the 3 hatchery mutalisks.

Steamhammer also scored two fluke wins over LetaBot versions when LetaBot crashed while far ahead. Skynet by Andrew Smith finally put an end to the incredible winning streak—with a dark templar rush! Ha ha! Skynet played it well, killing spotting overlords with a dragoon and taking full advantage of Steamhammer’s blindness to its build.

For the upcoming Steamhammer 1.2, I added a feature today to simplify the coding of similar middle game production for different openings. In older versions of Steamhammer, StrategyManager checked the name of the opening build order to decide what to build. There were a bunch of zergling openings, so I coded in: If the opening is this, or this, or this... build zerglings. If the opening is that, or that, or that... build mutalisks. It was bulky and hard to maintain, but I let it stand because I knew I was throwing the code away when the new strategy boss was ready (and I did).

I don’t want to write a new strategy boss for protoss and terran, so BOSS will be the way. BOSS works better for protoss and terran than for zerg, anyway. To solve the maintenance problem, you can add an optional OpeningGroup string to each opening, and check the OpeningGroup in the code instead of the opening name. If OpeningGroup is zealots, make zealots, and so on. It doesn’t matter how many zealot openings you write, StrategyManager doesn’t need to be updated. Of course nothing stops you from using the opening name too, if you want to fine-tune, but then keeping it in sync is up to you.

Here is the start of UAlbertaBot’s zealot rush:

"Protoss_ZealotRush" : { "Race" : "Protoss", "OpeningBuildOrder" : ["Probe", "Probe", "Probe", "Probe", "Pylon", "Probe", "Gateway", "Gateway", ...

Here is the same part of the identical opening in Steamhammer 1.2 development version. There is also a “10-12Gate” opening in the zealots OpeningGroup. Liquipedia lists other two gate zealot openings if you want to code them in yourself.

"9-9Gate" : { "Race" : "Protoss", "OpeningGroup" : "zealots", "OpeningBuildOrder" :
    ["4 x probe", "pylon", "go scout location", "probe", "2 x gateway", ...

I made a couple of simple and necessary improvements to the followup, too. When it transitions to dragoons, Steamhammer (unlike UAlbertaBot) gets dragoon range and eventually zealot legs. If given the same openings, Steamhammer will play them better than UAlbertaBot does. I intend to give it random openings that are a little different, though.