archive by month
Skip to content

no opponent modeling in AIIDE :-(

I am bitterly disappointed. I wrote my opponent modeling code. I kept it as simple as I could, since it’s the first draft of a major new feature. When it seemed to work I hooked it into the strategy boss, which then made decisions based on the enemy’s predicted future unit mix, not based on the current observed unit mix. I ran a few test games without visible problems. Then I tested more thoroughly, and turned up severe bugs. It is not close to solid enough to enter into a major tournament. And as far as I am concerned, frantic last minute debugging is not a plan.

I got what I deserved for hurrying to meet the deadline. I should have run careful tests earlier. I still think I had enough time to polish up the basic features, if I had only worked wisely. It’s not that complicated. It’s a simple idea that nobody happens to have implemented before (that I know of).

Anyway, for the AIIDE version I’ll turn off opponent modeling and remove the hookup into the strategy boss. I’ll release it as version 1.3.1, with a configuration file specially tuned for the tournament. It does have bug fixes and other improvements over the current version 1.3, so it should play a little better. (I count 19 bug fixes and small improvements plus 1 minor new feature, as well as new 2 hatch and 3 hatch lurker openings.) Then I’ll take my time with opponent modeling and release version 1.4 when it is good and ready.

The opponent model has strong capabilities in principle. It can meet most of the goals I laid out. If there is data—enough data from past games and enough from the current game—it can estimate the enemy unit mix at any future time during the game, and can predict the times of important events like “enemy gets air units” and “enemy gets detection.” An opponent that plays a fixed strategy should turn transparent by the second game. An opponent with a modest number of fixed strategies should become predictable as soon as Steamhammer has seen all the strategies—and when the current game has progressed far enough to distinguish them. I do expect trouble predicting opponents which successfully hide their tech, or which make important decisions in the middle game randomly, or which (like Steamhammer itself) play a wide range of strategies.

The downside is that it is only a data structure. Each use of the prediction capability has to be coded into the bot separately. I coded the prediction routine to estimate the enemy’s future unit mix. I coded 2 uses of the prediction in the strategy boss, one to set the tech target and one to set the unit mix (using different time horizons). When I want to use predictions to make spore colonies in time, or to get the right number of scourge at the right time to counter XIMP’s carriers as they show themselves, I’ll have to separately code more uses into the strategy boss, because of the scattered way the strategy boss works. When I want to use it for opening selection, I’ll have to code a different prediction routine and use it. And so on. The ability to predict is powerful, and you have to pay for the power.

Since I kept things simple for the first cut, predictions may be a little unsteady. It should be good enough to be useful, but whether it is or not, there is room for improvement.

I’m bitterly disappointed not to get opponent modeling into AIIDE. It’s an easy idea—to me it’s obvious, and I have to imagine that nobody else has done it only because they’re concentrating on other aspects. But it’s also new and I expect it to be successful. If I’m right, then other authors will soon be borrowing my opponent modeling code or writing their own along similar lines. The actively developed bots may take a step up in ability.

Trackbacks

No Trackbacks

Comments

LetaBot on :

Still looking forward to seeing it on the SSCAI ladder

Joseph S Huang on :

I'm not sure the cost benefit would be worth it, for a zerg. Zerg can switch unit mixes very quickly, if we need more hydras we can build many at the same time, and have them pop in the time it takes for 1 to finish. A creep colony could be built, and delay the morph into the spore or sunken until needed.

I might try to do the route that Dave Churchill used with Combat Search stuff, and try different unit additions to figure out which would be the most effective, but using FAP and possibly some kind of custom build order search instead of Sparcraft and BOSS.

MicroDK on :

Zerg needs to tech before units are available. But after that zerg can switch very quickly. With more unit types the decision tree gets bigger and more complicated. Combat search sounds useful and with FAP it is practical since its very fast compared to Sparcraft. But how would it be implemented? Try different units vs the known enemy units? How many units would you put into the sim?

Joseph Huang on :

Not sure yet, I need to have a build order search up first.

krasi0 on :

I am impressed that decent opponent modeling seems like an easy and obvious task to you! More power to you! :)
Let's wait and see how it pans out when you get it implemented.

MicroDK on :

I agree! The opponent modeling as you describe it does not sound easy to implement. Finding out which units we need and when in the future vs a opponent sounds difficult. Happy that you found the holy grail. ;) I am looking forward to see how it performs when SH gets it.

Jay Scott on :

In a few days I should have time to post a description of how it works. Then you’ll see how little there is to it.

krasi0 on :

Not just a description. I'd rather see your bot on SSCAIT using it. In other words and as I like to say: talk is cheap, show me the bot! :D

MicroDK on :

I am wondering if enemy modelling would work at all... it would work against bots with static strategies that never changes. But many bots change their strategy / unit mix based on the opponent and if SH plays the strategy / unit mix that the model learned it should play, the bots would just adjust to that. So it would just become a self oscillating system. On the other hand the opponent learning has the advantage that SH will become the one that dictate the strategy / unit mix instead of the slave that just adjust to the opponent.

Jay Scott on :

It’s an open question, of course. My thinking is that it will help against reactive bots, because current bots react in idiosyncratic but predictable ways. With enough experience, Steamhammer should learn to predict the reactions, gaining an edge. The countermeasure is to be strategically unpredictable: Choose randomly (or at least based on factors that Steamhammer doesn’t pick up) whether to meet the mutas with goliaths or with valkyries. I’m not aware of any current bot that is unpredictable in that way.

LetaBot on :

You could also have a bot that does a BBS rush every once in a while ( perhaps using rand() seeded with the current time ).


Either way, a reactive bot like mine could still win with a better late game play. As the task of the build order flow chart is to ensure that my bot at least survives until the mid game, after which the MCTS can do its thing.

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.