Starcraft AI blog

After every release, I traditionally post about my plans for what’s next. Sometimes I carelessly follow the plans before I can change my mind, though usually I can catch myself before I slip into a rut.

The next release should be 3.4, or 3.4.x if I give numbers to some test versions. Like last year, I will treat the tournament season as over, and go into infrastructure work of the kind that introduces new bugs, so that there’s time to iron them out before the next tournament season starts in the fall. The last time I considered plans, I had not decided between the opening timing project and the machine learning evaluation function project. I have to eventually do both and they support each other, so I may end up doing one after the other no matter the order. But for now I’ve decided that opening timing data (with other statistics) is my next item. I think it will make a bigger difference as a first step. I have updated the version number in the code and opened the next file to edit, the work is notionally underway.

When this project is complete (and I may do it in stages rather than all at once), Steamhammer will no longer need long sections in its configuration file telling what openings to play against each race and what the counters are to different enemy strategies. It will decide for itself based on its data. I will likely remove the configuration features altogether, since they don’t fit well with a data-driven architecture. It’s another step toward getting Steamhammer to think for itself rather than to slavishly follow instructions.

All details are up in the air; my plan remains an outline. Writing the code to collect the data I want is easy. Collecting the data I expect to be lengthy but straightforward. The hard part, I think, will be rewriting the opening selection code. The current version uses tricks to shortcut the work, and I won’t be able to get away with that any more, so I expect I’ll have to write it more or less from scratch, adding complexity in the process. On the upside, I can code it for modifiability, so that future opening adaptation changes (that I already know I want) will be easier.

Without more planning work, I can’t estimate how long it may take. 3.4 may be ready for AIST S4, or I may enter the current version 3.3.5. Or possibly I’ll fork an interim version with surprise improvements; anything’s possible.