EPTOne month has passed since I dove into the world of Brood War AI Bot development. The exchange with the current top shots of BW AI Bots at IRC #BWAPI has been amazing. From kickstart help on Prolog to detailed information on the nitty gritty of BW to analyzing and testing strategies, there has always been somebody willing to support and the learning curve has been steep. Time to briefly reflect on progress, issues and the current “state of the game”.
Let’s do this result-oriented:
How good is the bot by now?
As outlined in my introduction post, I start with a reduced Brood War universe. The bot can only build marines and SCVs. Still, by now the bot is just about to beat the full-fledged built-in bot. In mainly comes down to whether he gets his bunker down or not. Mostly he does, which is a bit imba against marines only
.Even though restricted to producing marines only, the bot can quite accurately predict enemy income and expenditure. Probably the trickiest part is to get the effects of “waypoints” right, when calculating maximum possible income. Let’s say you want to know how fast I can have two tanks out. It’s not good enough to just calculate by when I can reach the necessary income for two tanks, one or two factories, machine shop, depot, and barracks and then subtract build times. Because every time when building something interrupts SCV production it will affect the future income curve, which has to be accounted for. This probably is worth dedicating a separate post.
The scouting algorithm works just fine. Here, the main concern for future work is a good “plain repair” in case scouting is prevented by enemy army. Right now, the scout just runs away from enemy fire and retries as soon as possible. It would be more reasonable to check out some other places once determined the place of interest is currently not accessible.
The current decision making is as simple as possible. Estimate enemy army size through income calculation, actual observation, and a small Fog-of-War bonus, then produce a build order to beat it. Once an army size has been reached that is considered to beat the enemy, attack. The build order is adjusted when new information is available.
Production: the above mentioned “on-line” strategy leads to quite sub-optimal production. At the start of the game the strategy (correctly) calculates it requires only 1 marine to kill the enemy. Hence it produces a build order “barracks, marine, attack”. Quite soon it decides that it requires more army, so it will produce something like “barracks, barracks, marine, marine, marine, marine, marine, attack”. If it had known this from the beginning it could have achieved the second build order more economically. Several solutions are possible, which shall be discussed in a separate post.
Current Issues
The development and testing environment is quite poor. I took some time to rewrite the entire program such that it can play multiple games in a row with the same instance. This allows me to run a couple of tests one after the other automatically. Apart from that, I mainly lack a good setup to play two bots against each other.
The “marines only” scenario reduces a lot of noise, such that I can focus on the more important underlying issues. But it also makes testing quite hard, because maps need to played in UMS or the enemy will just use all available units. The problem is, that the standard maps are not modifiable and cannot be played in single player. So I’m using a modified Lost Temple map for now, which of course introduces its own issues (e.g. only 8 patches in the main, etc.).
Minimum micro abilities are necessary to successfully test. So I ended up spending a considerable amount of time on basic concave, focus fire, pulling back weak units, and last but not least collision detection with walls. You wouldn’t imagine how often your own units walk straight into a wall and remain there until killed!
One last thing I have noticed: bwapi and bwmirror have some issues that makes programming a bit harder. Just to give some examples: When playing terran, bwapi says that feedback was researched for 100 minerals / 100 gas (probably because feedback was once an upgrade and then Blizzard made a hack during a patch just stating it has been researched already at the beginning of the game for all three races). Bwmirror does not always return the same object for the same unit, even though the unit ID is the same. So you can’t trust the equals method and essentially are forced to write your own wrappers for all units.
Finally, the non-object oriented nature of bwapi introduces a lot of potential pitfalls to developers. Basically everything is a “unit” and all possible operations of all units can be called on every unit (“mineralpatch.attack()”, “marine.gatherminerals()”, “mineralpatch.isBuilding() = true” etc.). I ended up writing a typed API for bwmirror. On one side this requires more effort by the developer, since you can’t just write “catch-all” code anymore. On the other hand, I am certain it will reduce developer bugs and it actually also reduces effort in other places. For example, there is no need to write code like “if (unit.getType().equals(UnitType.TERRAN_SCV)) {unit.gather(patch)}”. Rather, you just write “Worker.gather(MineralPatch)”.
What does "typed" and "strongly typed" mean?
Check e.g. en.wikipedia.org
I will let you know how this turned out in the next monthly report
