archive by month
Skip to content

Steamhammer 1.4.x plans, more concretely

I’ve narrowed down some of the decisions of what to do in the 1.4.x series, which is about improving the opponent model until it becomes more clever than Clever Hans. Of course my plans tend to change frequently, so no promises. This is what I’m thinking now. I wrote up less specific plans in February.

As always, I’ll do a lot of things that I don’t call my primary goals. Here are some that I feel pretty sure about.

  • Make some necessary improvements to the plan recognizer.
  • Speed up and improve building placement. In particular, fix the bug with protoss.
  • Make a start on reworking the production system to accept more general goals. I thought of ways to take it step by step.
  • Try a few experiments with squad control, so that I have a toe on the ground when I move on to the 1.5.x series, which will be about mutalisk control. I might teach units to hold position in locations where they can hit targets from outside enemy range, for example, which seems like an important basic skill.
  • Protoss shield batteries.
  • Overlord safety! Steamhammer loses far too many.
  • At least 1 new terran skill and 1 or 2 new zerg skills, just to keep progress up.
  • Probably a few skills made easier by the new base and map code, such as running workers away from a base under attack.

There are also things I want to try but feel less sure about fitting in. There’s already too much. One is Antiga’s ideas about ramps and chokes and stuff.

1.4.2

  • Fine-tuning of opening choice: Tend to repeat successful openings, regardless of other considerations.
  • The opponent model will try to understand whether the opponent plays a single fixed strategy, or varies its play. Just knowing that gives a lot of leverage to learning.
  • New base placement code, a major step in dropping BWTA.
  • Make the opponent model work on BWAPI bot ladder and other tournaments. There are slight technical differences between SSCAIT and other competitions in when directories are cleared.

With Steamhammer’s large number of opening build orders, it would be very slow to learn which one to use against each opponent using an undirected algorithm like UCB. Every opening would have to be tried a few times—even a long tournament like AIIDE would not be long enough to find good openings against all opponents. We have to use knowledge to direct the search to try more promising builds first. The instant learning of the opponent model is one piece of that knowledge.

For this version, fine-tuning will consist of noticing which openings have been more successful against this opponent, and tending to repeat them. I may also add exploration, but only a limited amount because there is too much to explore.

1.4.3

  • Collect opening data.
  • Start to adapt opening choice to the maps.

Another piece of knowledge to direct the search for a good build is knowledge of which openings are similar to each other. If a lurker rush opening gets smashed hard, maybe try a mutalisk opening next, or at least a slower mass lurker opening. That’s only the simplest way to use the knowledge. I want Steamhammer to collect data about its own openings in real games, so it learns the timings of when production and tech get completed, and the variation of the timings due to maps and to pressure from real opponents. It’s a model of each build, you could say. The bot should be able to compare the opening models against the opponent model, so it can choose an opening likely to upset the opponent’s plan.

1.4.4

  • Represent the tree of openings, and make choices at each branch.

I expect to implement the opening tree for zerg only at first. I think that by combining the opponent model, the opening models, and the smarts of the zerg strategy boss, it should be possible to make good enough choices at each branch point in the tree. The idea is that the opponent model tells us what the opponent is planning, the opening models tell us what we’ll do for each branch we might choose, and the strategy boss understands counters and can tell which result is best. I could be wrong, and in that case I’ll have to find more knowledge to add.

If successful, this could be an amazing skill. I’m determined to try. We’ll see how it goes!

Trackbacks

No Trackbacks

Comments

Antiga / Iruian on :

I've got half a dozen new openings in Antiga that I've been testing. Please feel free to include anything you like, just grab it from my config file. Happy to contribute! The new stuff not in SH is : 6Gate, 9-9Gateprobepull, 9-9GateinNatural, 10-12GateExpo, "10-15SingleExpo", "10-15DoubleExpo", "10-15DT", "2GatewayGoonExpo", "4GatewayGoon, "DTExpand" and "GatewayFirstFE". 9-9GateinNatural is not in use atm due to a about 15-20% building placement failure rate (though quite effective when it does run). 4GatewayGoon also overbuilds gateways not in coherence with the build order for some reason and gets lost, and is also disabled in my bot due to it (Maybe you might have some ideas on why). GatewayFirstFE is very strong.... vs some opponets and as you'd expect terrrrrible vs heavy ling openings. Without global learning GatewayFirstFEis a crapshoot.

9-9 Gate and 9-9Gateprobepull both kill Cherrypi 95%+ of the time in their current versions.

Thanks again for all that you do!

Jay Scott on :

Thanks, those sound great! And the ones that suffer bugs... will work someday. I think the building placement steps are (this is just a little more detail than my last outline plan) 1. Fast building placement, which will be sooner, not later. 2. More map analysis, to identify chokes and directions of movement. Then it should be possible to place a pylon in the natural, or in the center, and expect that buildings will usually fit around it. 3. Actual smart building placement, which checks that everything will fit by planning it out.

Antiga / Iruian on :

Thanks! I'll give the new @ center stuff a try too and let you know how it goes.

krasi0 on :

What have you noticed about the clearing of read/ and write/ directories on the new ladder? I make use of Dave's TM (vanilla version) where I schedule each game to be in a new round, hoping that the TM will synchronize the folders after each game. I am not sure this happens in 100% of cases though.
On SSCAIT, the TM is a heavily modified, old version of Dave's TM. There, I've hacked in the Java code to force a write/ directory resync after each game. Seems to work all the time according to what I've seen.

Jay Scott on :

I’ll write it in my post about the ladder.

Antiga / Iruian on :

Been playing with the new macrolocation @ center. If I could somehow flag it to only be used on certain maps (not roadrunner, tau cross etc.) It'd be great and I think ready for use for proxy gateway openers.

I think a great feature would be able to take a map list, and then make a list of build orders that can't be used on those maps in the configuration file. Fairly simple way to do it / would help effectiveness a great deal.

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.