what’s coming next for Steamhammer
The next Steamhammer version will be 2.2.1 for SSCAIT.
- Update terran and protoss openings for new Steamhammer skills.
- Because of other changes, terran and protoss need some building placement corrections.
- Test for and fix any new terran and protoss bugs.
- Test and probably tweak some code details that I didn’t have time to polish.
- Probably add a minor feature or two along the way.
After that, I want to switch to BWAPI 4.2.0 and undo my workarounds for BWAPI 4.1.2 bugs, especially the irritating ones that affect zerg. Zerg drop strategies will become more viable.
In the longer term, the big project is strategy adaptation, as decided here. It will take a long time and has to be done step by step.
Earlier, I laid out a 3 phase plan for the work: Abstract strategies, then data collection and decision-making, then exploiting the new infrastructure for decisions throughout the game, not only early on. Probably, though, it’s better to think of aspects rather than phases. I think I’ll do parts of each and spiral around until it’s wrapped up. Data collection and decision making are not so much parts that can be done separately as parts that need each other to be useful.
The outline and goals are clear, but I keep changing my mind about the exact steps. One early part will be replacing the separate opponent model files for each opponent with a unified database, because I will need to collect more data and do more varied calculations with it. Another early part will be building out the production goal system, which will do much of the work of turning an abstract strategy into a concrete build order (and will improve play for all races, but especially terran and protoss, before abstract strategies exist). I may implement the tree of concrete opening lines as an intermediate step before layering abstract openings on top. A third early step is a build order analyzer that predicts how long different builds will take, what resources they will need when, infers the existence of some enemy buildings that have not been seen, and related stuff; it will provide input both to the new strategy boss and to the new opponent model.
I have a general idea of how I want to represent an abstract strategy and tie it both to concrete opening lines and to production goals, which are 2 ways to carry out the abstract strategy. I have a rough sketch for how to represent the opponent’s partially known build state and predict the range of possible or likely strategies. I need to figure out a ton of details, and decide on a general mechanism to tie the predicted enemy plans to strategy reactions.
The total is definitely more than I can finish before AIIDE. I have to aim for a useful subset of the ultimate skills.
Soon: The AIST S2 results.
Comments
Joseph Huang on :
Bruce on :
To emulate a unified database file you would need to either store a file per opponent or per game, then read them all in at startup and build the unified database on-the-fly.
Jay Scott on :
Jay Scott on :
MicroDK on :
Jay Scott on :
Joseph Huang on :
Jay Scott on :
Antiga / Iruian on :
MicroDK on :