The config file is named Steamhammer_1.0.json and controls settings including the bot’s choice of opening build order.
The config file is easy and fun to edit. Especially useful are the Debug section if you want to see what the bot is thinking, and the Strategy section if you want to change its openings. If you want to test your own play or any bot against a specific zerg opening, you can write out the opening build order and tell Steamhammer to follow it. (The config file is inherited from UAlbertaBot and you can do the same with UAlbertaBot for any race, though Steamhammer has more capabilities with zerg.)
The file is in JSON format. If you introduce a syntax error that you can’t find, drop it into any handy JSON checker (plenty are online).
I’ll go through section by section.
The bot’s name and author. If you fork Steamhammer, don’t miss this part!
SetLocalSpeed is 0 to let the bot play at its full speed in games you set up against other bots. Some bots set a slower local speed by default. If UserInput is true, then you can enter commands like /speed 30 to slow it down and /speed 0 to speed it up again. These commands work across bots, not only in Steamhammer, and there are other commands. Set CompleteMapInformation to true for the bot to cheat and see everything.
These two sections are little use to most people and I may end up removing them in a later version. But in the meantime you can play around if you’re interested.
In release versions, all the “draw” options are turned off. In development, I turn on the appropriate ones to see what the bot is thinking. They draw information on the screen. If you turn on too many at the same time, they’ll draw all over each other. DrawGameInfo and DrawProductionInfo are my favorites.
These options are useful mainly if you fork the bot and write code to replace some of the functions. Then you can turn off the corresponding module without having to find all the calls to it—only handy for certain kinds of coding experiments. I am in the process of removing these options, and not all of them work at the moment.
The map grid that Steamhammer uses to keep track of explored areas. I have never had a reason to change the number.
The next entries tell which opening to play when. Steamhammer inherited the opening specification from UAlbertaBot, but adds many features. In other parts of the config file I mostly removed features; here I added.
There are several different ways to tell Steamhammer which opening to play.
1. If you put in a line "Zerg" : "5Pool", then Steamhammer will play 5 pool whenever it is zerg, or in other words, always. (Don’t forget the comma that separates it from the next line.)
2. If you put in a line "ZvT" : "ZvT_2HatchMuta", then Steamhammer will play its 2 hatch mutalisk opening every time it faces a terran. In the matchup name, “U” means that the opponent chose random (the race is “unknown”).
3. Steamhammer can play different openings against opponents that it recognizes by name. Set UseEnemySpecificStrategy to true and, inside the EnemySpecificStrategy subsection, give an opening for each opponent that you want to treat differently. The example means “When playing Jakub Trancik as zerg, play the 9 pool expo opening.”
"Jakub Trancik" : { "Zerg" : "9PoolExpo" }
4. Steamhammer can choose openings randomly. Instead of the name of an opening, give a StrategyMix which lists different openings with weights for how often they should be played. The weights can be any positive integer, but I like to choose weights which add up to 100 so that they are percentages. This also works for opponent-specific openings. (Get the punctuation here exactly right.)
"ZvU" :
{ "StrategyMix" : [
{ "Weight" : 10, "Strategy" : "5Pool" },
{ "Weight" : 20, "Strategy" : "9PoolExpo" },
{ "Weight" : 70, "Strategy" : "9PoolSpeed" }
]},
Finally, the Strategies subsection defines the opening build orders themselves. The opening build order is a sequence of items to build one after the other. Each item can be a unit, a building, an upgrade, a tech to research, or a command. The name of each item is case-insensitive, that is, upper case and lower case do not matter.
Steamhammer provides a number of commands that can be executed during the build. All the commands start with the keyword “go”.
go scout - unconditionally send a scout drone to the enemy base and have it stay there watchinggo scout if needed - send a scout only if the enemy base location is not already known (by any means)go scout location - return the scout home (or don’t even send it out) as soon as the enemy base location becomes knowngo steal gas - take the enemy’s geyser with the scout dronego stop gas - stop collecting gas from all extractorsgo start gas - start collecting gas from all extractorsgo gas until [n] - collect amount [n] of gas, then stop (e.g. go gas until 100 for zergling speed)When you first build an extractor, Steamhammer assumes that you want to collect gas right away, so gas collection is turned on. I put “go gas until” commands right after the extractor: "extractor", "go gas until 100". Steamhammer remembers the intention and executes the steps at the right time (though it often collects 8 gas more than it should).
If you ask for “hatchery”, Steamhammer assumes you want the hatchery at a gas expansion. You can choose.
"hatchery" - at a gas expansion"hatchery @ expo" - at a gas expansion (the same)"hatchery @ min only" - at any expansion, whether it has gas or not"hatchery @ hidden" - at a “hidden” base somewhere far from both players’ mains"hatchery @ macro" - macro hatchery at the main baseIf you ask for "creep colony" to build static defense, Steamhammer assumes that you want it at the main base. You can choose—a little bit. This arrangement is awkward and limited and I will probably change it in a future version. Steamhammer does not have the smarts to place creep colonies in good locations (like toward the enemy), so it may do something silly.
"creep colony" - at the zerg main"creep colony @ main" - at the zerg main (the same)"creep colony @ natural" - at the zerg natural, if possible (otherwise at the main)Steamhammer plays zerg, but is it descended from UAlbertaBot which can play all 3 races. In making updates, I have tried to avoid breaking the ability to play all 3 races. But I only test with zerg, and we all know that nothing keeps working if you don’t test it. If you configure Steamhammer to play terran or protoss or random then no promises, but it is likely that you would have only a small number of problems to fix. Here is one problem: The random openings do not let you play a different set of openings depending on the race you get if you go random.
page originally created 31 January 2017