opponent modeling, scouting, and software development

Opponent modeling is coming along, though never as fast as I would like. Steamhammer now records a pretty informative model. Making best use of the model is not as easy—it has a ton of uses. If it works as well as I hope, Steamhammer will gain scary predictive abilities, even against opponents with multiple strategies.

Opponent modeling depends on good scouting. The more Steamhammer finds out about what the opponent does, the better the model. So today I added a new scouting command, "go scout once around" which sends the worker scout on a single circuit of the enemy base and then returns it home. (Usually. There are some funny cases because the waypoint numbering is not quite clean.) In a lot of openings, I used it to replace "go scout location" which only finds the enemy base and doesn’t look to see what’s there. I’m thinking of also adding "go scout while safe".

The command is a minor addition, but while hooking up the wiring I saw awkwardness in the communication among ProductionManager which executes the commands, GameCommander which initiates scouting, and ScoutManager which does the work. I ended up spending the whole afternoon refactoring it for simplicity and testing to make sure I hadn’t broken anything.

Is that what I should be spending my time on? And yet it makes Steamhammer better.

Trackbacks

No Trackbacks

Comments

Joseph Huang on Monday, August 14. 2017:

Easy fix for waffling around in cannon range: https://plus.google.com/u/0/+JosephHuangRMP/posts/9qfrsxGgFyV

krasi0 on Monday, August 14. 2017:

It's amazing how many different techniques and approaches we get to pit against each other and compare in a single place like SSCAIT. Let the best AI techniques win! :)

Alexander Wellbrock on Friday, September 15. 2017:

I really enjoy reading your blog and also the steamhammer source code. Right now I'm using it for my bachelor thesis to integrate an opponent model based on different machine learning techniques, so especially your posts about that topic are really helpful and motivating :)

While you seem to work on prediction skills to use them in handcrafted scenarios I concentrate on creating a complete strategic model, which leads in extracting even more data then you do. I think using the predictions your way could lead to a way more stable behavior, so I'm really curious what will happen.

I'm glad that you implemented that scouting feature :)

In principle the model depends implicitly on all other components (e.g. micro behavior, building placement) of Steamhammer as well. The recorded data is influenced by the play style of the bot and how the opponent reacts to that, if that changes (through bug fixes, optimizations or major changes) the model should be outdated and produce errors.

To answer your question, sometimes those refactoring sessions are kind of zen meditation practices :)

I'm looking forward to exchange my experiences once I'm done with the thesis and the source code is published.

Jay Scott on Friday, September 15. 2017:

It’s tough, the tradeoff between hand-sculpted design with many special features and general purpose design that tries to learn as much as possible on its own. The end goal is always to find a design that relies on a small number of general-purpose methods without much hand-tuning. It may be possible to do that with deep learning—but if so, it is beyond my resources. I feel forced by my goals and limits to proceed in a more patchwork way. Hats off to everyone who tries to leapfrog ahead! We may learn more from what you do.

Add Comment

Name*

Homepage

Comment*

In reply to

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