archive by month
Skip to content

technical difficulties, please stand by

After falling behind on my own, I was beset by technical difficulties and ended up having to restore stuff from backup. I hate that. I follow safe practices so I didn’t lose work, only time and motivation, but I still hate it. Now I feel Hopelessly Far Behind.

In other news, when Steamhammer was pushed down the ranking by McRave and Microwave, suddenly Steamhammer got many fewer games on the server. Apparently the second string is not nearly as interesting to vote for, or maybe people got bored since it has been over a month since the last update. Either way, it is kind of relaxing.

Nobody objected to my idea of uploading test versions to SSCAIT without doing the extra testing and documentation work of a proper release. I think I’ll add another wrinkle. Tomorrow I’ll upload Randomhammer only, not Steamhammer zerg, in the almost-ready development version. I figure that that way I can get it tested and I won’t be overwhelmed with games to watch, so I’ll get on faster with the last half-dozen items I have planned. We’ll see how it goes.

McRave and Microwave

The SSCAIT news is that McRave and Microwave have been steadily climbing up the ranking. I’ve been watching it happen for a while. Just recently McRave edged past Steamhammer in elo, pushing Steamhammer down from #4 to #5. Today Microwave has moved ahead of McRave. The 3 bots seem quite close in strength for now.

Maybe the two authors would like to comment on their improvements?

According to my machine learning algorithm, the important common factor between protoss McRave (made from scratch) and zerg Microwave (a Steamhammer 1.o fork) is the -ave name. I speculate that there may be a connection with Aves, the birds. In any case, the hypothesis suggests that PurpleWave may be the next climber, and I hear that plans have been laid.

Now back to work. My tactical changes have introduced some new misbehavior that must be addressed, and not with “hello, misbehavior.”

new configuration features coming in Steamhammer

For the upcoming Steamhammer version, I’ve added a set of configuration features that make the strategy mixes more expressive. A strategy mix is a set of openings with numeric weights, which Steamhammer chooses among randomly according to the weights.

1. In a strategy mix, you can specify different weights depending on the map size—actually the number of starting positions, from 2 to 8. A weight given as “Weight” is a default weight that applies to all map sizes. A weight given with a number, like “Weight2”, is specific to that map size and overrides the default weight. This line says that the 9PoolSpeed opening should be played more often on 2-player maps:

    { "Weight" : 5, "Strategy" : "9PoolSpeed", "Weight2" : 15 },

MicroDK wanted this feature, and now it is done.

2. You can use strategy mixes in the EnemySpecificStrategy section. In the current version, you can only specify fixed openings against specific opponents. The syntax is slightly different, to make it possible to play random: Instead of one list headed “StrategyMix”, you can write up to three lists headed “Terran”, “Protoss”, and “Zerg” for the race you end up as.

3. I added a new subsection StrategyCombos which defines strategy mixes that you can refer to by name. For example, Steamhammer knows the names of a bunch of zerg rushbots, and will follow the same strategy mix against all of them. So in the EnemySpecificStrategy section, it lists each one and tells it to follow the AntiRush strategy mix, which gives 6 alternate zerg openings, plus a protoss and a terran opening to defeat 4 pool and 5 pool.

A strategy combo can be given anywhere that you can give a strategy name, including recursively in another strategy mix. (Suggestion: Do not make an infinite loop.) That way you can build strategy mixes piece by piece. Steamhammer does this for its 4 and 5 pool openings. It knows 3 variants, and it is tedious to write them all into each matchup’s strategy mix, so they are pulled out into a separate FastPool strategy mix in the StrategyCombos section:

    "FastPool" : {
        "Zerg" : [
            { "Weight" :  0, "Strategy" : "4PoolHard", "Weight2" :  5 },
            { "Weight" :  0, "Strategy" : "4PoolSoft", "Weight2" : 15 },
            { "Weight" : 80, "Strategy" : "5Pool" }
        ]
    },

Nested strategy mixes are resolved one at a time. If the outer strategy mix says to play FastPool 5% of the time, then that’s what happens (it may vary depending on the map size). Then FastPool says “oh, this is a 2-player map, I’ll play 5Pool 80% of the time and the others less often,” or it says “this is a 4-player map, I’ll always play 5Pool.”

an example

I made a strategy mix to try against Krasi0 which happens to use all the features. Maybe it will provide an edge over the default. Here’s how it stands today:

    "krasi0" : {
        "Zerg" : [
           { "Weight" :  3, "Strategy" : "FastPool" },
           { "Weight" : 17, "Strategy" : "9PoolSpeed" },
           { "Weight" : 15, "Strategy" : "ZvT_12Pool" },
           { "Weight" : 20, "Strategy" : "ZvT_2HatchMuta" },
           { "Weight" : 25, "Strategy" : "ZvT_3HatchMuta", "Weight2" : 0 },
           { "Weight" : 20, "Strategy" : "3HatchPoolMuta", "Weight2" : 0 }
        ],
        "Protoss" : [
           { "Weight" : 10, "Strategy" : "1ZealotCore" },
           { "Weight" :  5, "Strategy" : "DTRush" },
           { "Weight" : 25, "Strategy" : "DTDrop" },
           { "Weight" : 10, "Strategy" : "12Nexus" },
           { "Weight" : 50, "Strategy" : "13Nexus" }
        ]
    },

There are zerg and protoss entries. If Randomhammer rolls terran against Krasi0, it will fall back on its default strategy mix.

Krasi0’s favorite thing is to sit back and macro up, so I selected a mix of some fast openings (that stand a chance of busting early, or that may cause trouble if terran should lose and try another build), and some macro openings to try to keep up (including a greedy three hatchery before spawning pool build that Steamhammer doesn’t normally dare to play). I de-emphasized the middle range that seems to me less successful against Krasi0.

Also, the 3 hatchery openings do not happen on 2 player maps. That is because Steamhammer is likely to get a drone stuck behind map blocks, which is a sure loss against a strong opponent. A future version will understand the map blocks, and then I’ll change the weights.

Dave Churchill has updated SparCraft

The SparCraft combat simulator is an important feature of UAlbertaBot. Dave Churchill has updated SparCraft to a new “semistable” version, on a branch at the UAlbertaBot repository: sparcraft update branch.

I haven’t looked closely at the new SparCraft yet, but I have glanced through. I thought the headline features were:

  • More and better control over the details of the simulation. Part of it is a fancier configuration file. You can tweak details of the simulation to more closely match your bot’s actual micro (matching the enemy is not as easy).
  • Flying units are “supported correctly”.
  • No limit on the number of units in the simulation.

There are new data structures that use less memory and the simulation is more faithful in some respects, so we can hope that results are more accurate. I see changes to the implementation of healing, so maybe medics will be better simulated.

Time will tell, but on the face of it this is an important update. I’ll be trying it out as soon as I get through immediate priorities.

release cycles

I’ve been thinking about release policies.

Eh, let’s try it. I think most people tinker with their bot for a while, then when they want to see how they’re doing they upload it and—see how they’re doing. It’s immediate and low-overhead. Good stuff.

Stamp a version number on it and throw it over the wall. Without thinking hard, I have fallen into an old-fashioned release cycle where I complete a bunch of work and hold a big release party. Releasing and documenting each version is overhead work, so I have incentive to stretch out the cycle to reduce overhead. It is not exactly Ideal Software Development Methodology.

My idea was that people would be unhappy if they saw advances on the server that they couldn’t get their hands on yet. I imagined, “Yo, hurry up and release already, I want that feature.” But is that true? I could switch to a compromise release cycle.

Kick development versions over to the server freely, and then when it looks done when poked with a fork, give it a version number and do the release work. On the downside, it seems more complicated for users. Official “stable” versions with updated documentation would only occasionally be running on the SSCAIT server, so what you see is not what you get. On the upside, there would be more variety for viewers (“look, it’s the bug of the week!”) and stable versions would be better tested.

It would affect how bots are updated in reaction to each other. My reaction cycle would be shorter, so new ways to beat Steamhammer might not survive as long. Equally, new Steamhammer behaviors would appear earlier on the server, so they might be countered sooner. Theoretically, it might speed up bot progress overall by some tiny amount.

The whole process would be more freeform and unpredictable, or in other words, modern. Even freer policies are possible, but I want to keep stable reference versions so that people aren’t tempted to fork broken unfinished code. And I have to minimize work; updating documentation as I go can cause extra work if I end up redesigning a feature that I document before it is tested enough.

What do you think?