Starcraft AI blog

We interrupt your regularly scheduled AIIDE analysis for software releases that you may want to know about. These are both under MIT license, meaning the main requirement is that you pass along the license file if you include the code.

MCRS combat simulator library

MCRS is a combat simulator by Christian McCrave, author of McRave. My latest info is that it should be considered beta quality, not fully tested. It follows a different philosophy than SparCraft and FAP, which ask you to provide sets of friendly and enemy units and then simulate a fight with all the units. MCRS wants to know all the visible units all the time—friendly and enemy, every frame. Optionally, you can also inform it of a friendly unit’s target unit, telling it more about the bot’s intentions. When it’s time to simulate a combat, you say how long a simulation you want and pick out one of your units as the seed of the engagement. MCRS figures out for itself which friendly and enemy units should be involved. I gather that it is intended to work well for short durations only: “Do I gain if I fight right now?” not “Will I eventually win this fight if I pour it on?”

Here is the output struct you get back from a simulation. There’s missing capitalization in attackGroundasGround, a sign of the beta status. Scanning through the code, I see that it doesn’t do what I would call a simulation—there are no nested loops—it’s more of a strength comparison. That means it should be quite fast. Personally, I would call it a combat estimator instead of a combat simulator.

struct MCRSOutput {
	double attackAirAsAir = 0.0;
	double attackAirAsGround = 0.0;
	double attackGroundAsAir = 0.0;
	double attackGroundasGround = 0.0;
	bool shouldSynch = false;
}

Without documentation, I’m n0t entirely sure what this is supposed to mean. I’m guessing that the doubles tell you whether it is better to shoot enemy ground units first, or enemy air units. shouldSynch I guess means that, if true, your air and ground units should do the same thing: Both attack or both run away. That sounds useful!

The estimate takes into account DPS, HP, and armor including upgrades, the time to reach engagement range, and high/low ground. It recognizes some spell effects; for example, it knows that a unit under maelstrom can do nothing. But there is no provision for most spell effects. There are adjustments for splash damage, including protoss high templar but not zerg devourers. I don’t see any attempt to understand cloaked units and detection; that might be the biggest missing point.

aWeaponCooldown() looks wrong. It usually returns an air weapon cooldown duration, but for high templar and suicide unit types instead returns a damage amount. Hmm, but a long cooldown means that the unit will not attack again during the simulation, so I think it should work correctly that way. It’s still odd. Also, infested terrans can only attack ground, so that detail looks wrong too. Continuing, I see spider mines being given a ground strength of 0.0. Are those handled by some other means?

Is MCRS a good idea? That depends on how well it works in your bot! Since it behaves differently than other combat simulators, if you already use one then to switch to MCRS you need to revamp your decision making. I haven’t tried it myself, so I can’t speak to how accurate it is... but you could watch McRave play.

TorchCraftAI framework from CherryPi

TorchCraftAI (front page with big tutorial links and small other links) builds on TorchCraft to provide a machine learning framework for Brood War bots. TorchCraftAI is a framework, not a library. You don’t include it as part of your bot, you include your bot as part of it: You take it as a starting point and build your bot inside it by adding pieces and training machine learning models.

As a full framework, TorchCraftAI is big and complex. The high level documentation looks pretty good, but it is not deep; you will probably have to learn a lot by looking around. Apparently the machine learning stuff uses CUDA for both training and play, so it requires an invidious, I mean NVIDIA GPU due to successful proprietarianization of the community. There are instructions for Windows, Linux, and OS X, but I gather that Linux is TorchCraftAI’s native environment, and life should be easier there. There is way more stuff than I can dig into for this post, so that’s enough for now.

TorchCraftAI includes code for CherryPi. It looks as though CherryPi’s learned data files are optional, but “recommended”; they have to be downloaded separately (see instructions under Getting Started). You’ll need CUDA to use them. As I mentioned at the start, it’s MIT licensed, so if you want, you can fork CherryPi and start from there.