Steamhammer wants opening learning 1: McRave
I still have some essential bugs to fix. Also I keep literally forgetting that I promised a public repository next, and having to remind myself; it’s not appealing work. But beyond all that, I’m thinking about the next step.
The next major feature will be a start on opponent modeling and opening learning. As I think about it more, I’m seeing how important a feature it is to add soon, so I don’t regret setting out down the path. I’m going to write a series of posts giving examples to show how key a feature opponent modeling is.
McRave
The current version of protoss McRave doesn’t play that strongly. Its new forge-expand strategy is not polished yet, and I think new weaknesses have been introduced. But even so, it beats Steamhammer. The live Steamhammer always plays low-econ pressure builds versus protoss, and (unlike most protoss bots, even Bereaver) McRave is a sturdy enough defender to hold off the pressure. While trying to pile on pressure, Steamhammer doesn’t make enough drones, and as the game wears on it can’t keep up.
It’s easy enough to change Steamhammer’s behavior. There is a standard opening which is slower than 12 hatch 11 pool and faster than 3 hatch before pool: It is 12 hatch 13 pool, squeezing in 2 extra drones before the spawning pool. Those 2 drones make a substantial difference in the economy, because the earlier you spawn a drone, the more it pays off. The trade is that zerglings come later and the opponent gets a window for early aggression. Anyway, this McRave version doesn’t go for early aggression, so I coded up a quick 12 hatch 13 pool into 3 hatch hydra build. Sure enough, my first draft won most test games against McRave.
I don’t want to make 12 hatch 13 pool a standard build versus protoss, because too many bots go for early attacks. Steamhammer’s low-econ openings are effective against most opponents. But I need economic openings to win against defensive opponents like McRave.
I could specify an enemy specific opening mix versus McRave and immediately turn a bunch of losses into wins, at least for a time. Steamhammer does that versus rushbots and a few others. Arrakhammer does it too; it has hand-made builds to beat Wuli and McRave, and one to give it a chance versus Iron. But it’s not satisfying. It’s not sustainable, because I have to keep updating the hand-made builds by hand as opponents appear and change. And it’s likely to fail in tournaments, because many opponents show up with surprise updates that are specifically intended to throw off opponents which tune against them.
The answer is so learn each opponent’s habits from experience.
Trackbacks
No Trackbacks
Comments
LetaBot on :
You could perhaps use those as a starting point, just like AlphaGo used expert human players are a starting point for their machine learning.
Jay Scott on :
Arrak on :
The builds I set otherwise are mainly for testing - lurkers, mutalisks, hydralisks, other things... In McRave's case, I set the build with the intention of helping the author improve his own bot, since his bot has helped me find bugs and weaknesses, and we'd talked some.
Looking ahead, there's definitely a need for reactive macro as well, especially for zerg -- the reaction to FFE is supposed to be 5-6 hatcheries, which is absurd against 1 base builds, but is safe to do after scouting FFE. A professional player can often infer the exact build they're playing against from timings.
My plan has been to improve the way my bot handles post-build macro (so I can take off silly followup drones in my set builds) and the variety of strategies it can execute correctly. There's been a lot of games where it needs to either continue building mutalisks, replenish drones, build a new base or extractor, or get hivetech early, where it simply doesn't do so. It still rushes hydralisks and lone mutalisks into marines/turrets, and lurkers into wraiths (instead of the other way around). This has been especially problematic against krasi0 and Iron.
By the way, I recently fixed the extractor trick (and a number of other bugs) when investigating why my bot stopped building extractors (presumably after an extractor was killed). There's a line in BuildingPlacer.cpp that needs to be rewritten as "closestGeyser = geyser->getTilePosition();" instead of getInitialTilePosition (which apparently returns an invalid tile for... "new" geysers?). This was not the bug I expected to find -- so it took me quite some time to track it down.
MicroDK on :
Jay Scott on :
krasi0 on :
Jay Scott on :
McRave on :
krasi0 on :
MicroDK on :