this opening requires that map feature
Before the 1.4.x series is finished, Steamhammer will adapt its opening choices to the maps by experience, even when it faces an unknown opponent. In a tournament, it may also want to adapt immediately to an unfamiliar map, which means it will have to analyze the map for features that influence play, and it will need prior knowledge of which openings work for a map with those features. At first, hand coding will be the way to connect map features to opening choices. That will also make it reasonable to compete in AIST. It’s no fun to play on an island map like Sparkle without specialized island openings.
The topic came up in the comments to the post chokes and regions from February. Antiga proposed 3 map features he wanted to be able to take into account.
Here’s what I’m considering for the design.
- Code the map feature preferences in the configuration file, where they are easy to change.
- Attach preferences to the openings directly, not to the strategy mixes. The island openings will be marked good for islands on the opening, along with
RaceandOpeningGroup. Then they are included in the strategy mixes without further marks. - It needs to be kept simple. Something like
“Require” : { “feature” : “value” }, where you can put any number of features between the braces. Each gets only one value, though, unless I make it possible for the value to be a list. Maybe“Avoid”instead of or in addition to“Require”. - Require would mean that all the given features are required. Avoid would mean that all the given features are to be avoided.
- There should be at least one default value: Most openings are not suitable to play on an island map, and should be silently marked for no islands. Maybe there should be more defaults.
I may start with only a map feature, or only an island feature. Here are possible feature names and values for some features, including Antiga’s 3 features.
| feature | values | meaning |
|---|---|---|
| map | [map name] | this string is in the map name |
| island | yes, no | no 2 starting positions are connected by ground |
| main ramp | up, down, level | entrance to each main base |
| main choke width | [number] | main entrance must be no wider than this, in tiles |
| natural choke width | [number] | natural entrance must be no wider than this, in tiles |
A lot more feature values might make sense. To cover all island maps, there should be features for the number of bases and the number of gases at each starting positition, and probably more features beyond that. There are a bunch of different kinds of semi-island maps, and maybe each kind should have its own value. Some are specialized: For example, Iron Curtain (designed as a 2v2 map) has 4 bases with a divider that (initially) separates it into 2 islands, each with 2 starting locations—in 1v1, you might start on the same island as your opponent, or you might not. The main ramp feature might have a value “multiple” for maps which have more than one entrance to the main. And of course there are always irregular Blizzard maps where each starting base may have entirely different features. These things are complications that should be minimized on a first pass.
To be concrete, you might declare an island opening like this. (Beware: I edited this up in less than a minute and didn’t test it. It is not a tuned opening.)
"Island 2HatchMuta" : { "Race" : "Zerg", "Require" : { "island" : "yes" },
"OpeningBuildOrder" : ["4 x drone", "overlord", "4 x drone", "hatchery", "spawning pool", "extractor", "7 x drone", "Lair", "drone", "metabolic boost", "2 x drone", "spire", "3 x drone", "hatchery", "drone", "extractor", "2 x overlord", "12 x mutalisk"] },
The 80-20 rule applies. Does this plan meet 80% of needs? What do you think?
Comments
Antiga / Iruian on :
Paul Goodman on :
Jay Scott on :
Paul Goodman on :
Joseph Huang on :
Jay Scott on :
Joseph Huang on :
Joseph Huang on :
Anon on :
[1] The "map feature preferences" is a nice idea. You will "attach preferences to the openings directly, not to the strategy mixes". But that information WILL be useful for other decisions.
[2] Don't work with "magical hidden defaults". If 95% of the openings aren't suitable for islands, you should explicitly rewrite them all with this new little requirement.
[3] Require_Island_Yes is the same as Avoid_Island_No? Or maybe Avoid_Island_No means it shouldn't avoid islands? Sounds confusing... What about just "Suitability"? Suitability_Island_Yes is easy to understand. If there is no Suitability_MainRamp defined, it doesn't influence the decision. If you have Suitability_MainRamp_{up|level}, the opening shouldn't be played if the ramp value is "down". Finally, for the numeric values you should use something like "number" to express the suitability.
Anon on :
Jay Scott on :
Dan on :
jtolmar on :
Jay Scott on :
Jay Scott on :