archive by month
Skip to content

Steamhammer 1.2 OpeningGroup feature

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.

Trackbacks

No Trackbacks

Comments

MicroDK on :

Nice feature... I am wondering if you can add af map option? I would like to be able choose openings based on the size of the map. Lets say I want to choose between 12Hatch, Overpool, 9Pool and 5Pool on 4 player maps and between Overpool, 9Pool and 5Pool on 2-3 player maps.

Jay Scott on :

I’m interested in a feature like that, but I haven’t thought of a satisfying way to implement it. 1. Add info to the matchups, like “ZvT_2player”, “ZvT_3player”. That gives complete control but gets bulky fast. 2. Add it inside the weight spec: { “Strategy” : “5Pool”, “Weight” : 5, “Weight_2player” : 15 }. I think that’s better. 3. Add options to the opening build itself, to enable or disable the opening for given maps or adjust weights in a generic way. It gives less control overall. 4. Add a “maps” subsection to the config that somehow specifies how openings and maps interact. The design space is big, and the whole idea may be overtaken by opening learning later, so I’m not in a hurry. How do you think it should work?

MicroDK on :

Yes, I have been thinking of how to implement this, and I also think your 2nd option would work best. You still have relatively good control of how often openings should be used (if at all) on which maps and vs which races.

Jay Scott on :

Here’s one way that BOSS works better for terran and protoss than zerg: For zerg, if you ask for drones and combat units, BOSS thinks “hmm, the order doesn’t matter, it’s more efficient to make all the drones first” and you pause combat units for a while, which can open a window of vulnerability. You’re forced to keep the BOSS goals short to avoid that. For terran and protoss, BOSS calculates a good interleaving.

MicroDK on :

Im still using BOSS since Microwave is based on v1.0 and it is using short goals which work fine. Maximum two units of every kind.

Add Comment

E-Mail addresses will not be displayed and will only be used for E-Mail notifications.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA

Form options

Submitted comments will be subject to moderation before being displayed.