Starcraft AI blog

What race is easiest to write a bot for? I have an opinion.

Ground rules: The goal is to write a bot that plays strongly by today’s bot standards, not a world-beater necessarily but a bot that has a fair chance to place. You’re lazy, and you want to do it with the least labor so you can go watch anime instead. What race do you pick?

Some people give the same answer for bots as for humans: Protoss, because protoss needs less micro to play at a fairly good level.

It’s reasonable, but I don’t quite buy it. Micro is hard for bots, but it’s not the hardest part. The hardest part is coordinating units or groups that have to work together: Planning and executing a multi-part action whose parts have to fit. Humans do this naturally (though limited by hand speed), and bots struggle with it. Difficulty with coordination is why no bots are good with arbiters. “Where do I stasis to help the battle the most?” is a coordination question; the arbiter and the combat units have to coordinate their actions. In other words, “where do I stasis?” and “how do I line up this attack?” are questions that are best answered jointly, not severally. Difficulty with coordination is why no bots are good with defilers (“where do I swarm?”). It is why no bots successfully drop with more than one dropship or shuttle. It is why bots that make both ground and air units often look awkward. It is why bots struggle to pull off complex attacks—even an attack as simple as “siege down the static defense efficiently” is complex—and why bots are usually so fragile in defense.

Terran units are micro-intensive and terran armies are coordination-intensive. Terran, I think, must be the hardest race to code well. The terran bots tscmoo, Tyr, Krasi0, Iron, and LetaBot have all seen major work in recent months, but the top spot on the SSCAIT ranking is usually a protoss or zerg that has not been updated as recently.

Protoss basic units can get by with little micro and little coordination, at this level of play, but at some point protoss needs to add reavers or high templar to keep up. The protoss advantage is high tech, and high tech units need careful micro and good coordination with the rest of the army. No bot does reaver-shuttle micro, and no bot is good with psionic storm, and protoss bots suffer for it. That’s how it seems to me.

Zerg is the easiest in my view. Zerg micro is not too hard, not at the level needed for a good bot today: Mutalisk micro is practically standardized, and zergling micro of the caliber “move into or around the enemy formation before you start to attack” is unheard of. Hydras, ultras, and guardians can all get by with simplified control. Lurkers call for coordination, but defeating lurkers also calls for coordination. Zerg benefits from surrounding the enemy before attacking, a kind of coordination but (it seems to me) a particularly easy kind. I think an uncoordinated zerg is more effective than an uncoordinated protoss, and the coordination zerg needs most seems easier to me than protoss. I think it’s no coincidence that the top finishers of the big 2015 tournaments are zerg.

Well, it’s purely my opinion and it’s kind of a close call. I won’t argue if you disagree. It’s not that zerg won’t benefit hugely from coordinating its army, even before defilers are out. Mutaling is an industrial-strength combination, and bots so far can’t use it effectively. Zerg only seems to suffer less for being uncoordinated.

At a higher level of play, coordination is no longer the bottleneck skill and the answer might be different.

If you want to tackle coordination head on, by the way, the keyword is search. A bot that foresees the future of its units can consider different courses of action until it sees something good.

Update: If you want to argue against me and claim that protoss is easier than zerg, here are a couple arguments you could try. I won’t change my opinion easily since I’ve already thought about this stuff, but then again, I won’t argue against you either.

1. ZvZ is a super-technical knife-edge matchup where tiny details count. Building one extra drone at the wrong time can lose the game, but squeezing out one extra drone at the right time can win. Playing ZvZ well calls for deep understanding and close adaptation to the opponent. PvP is not as tricky.

2. Because a larva could become anything, zerg is freer than the other two races to trade off between economy and army. And that freedom is hard for bots to take advantage of. None of the zerg bots that aims for middle-game play is good at adapting its defense to the threat it faces, which zerg has to do to maximize its economy.

Starcraft Brood War is supposed to be a balanced game. The three races, even though they have different units and abilities and strategies, are equally strong. To be sure, one race has the advantage in these situations and another in those, but that’s what makes it a strategy game.

Well, but we know better, or if you don’t then you will as soon as you think about it. Are Blizzard’s original maps from Brood War’s release balanced today? Not remotely. When a groundbreaking new idea or strategy is developed for one race, from the terran wall-in to the Bisu build, does the game’s balance stay the same? No, it shifts because groundbreaking means groundbreaking.

Competitive maps in any era, unless at the very start of professional play, are carefully designed to be balanced for the play of that era (or at least of the previous era!). Every mapmaker checks exactly how far a tank can shoot into each base from outside, weighs the situations in which zerg can get the crucial third gas, considers the positioning of obstacles to keep games fair in each matchup, and on and on in painstaking detail. Maps provide the degree of freedom that keeps Brood War balanced even as the game balance shifts when new ideas arise.

The same for bots. Bots have different skills than humans, so game balance for bots is and should be different. In other words, for fairness, ideally bots should play on different maps than humans do.

Well, it’s not a problem yet. We’re still at an exploratory stage and all balance issues can be blamed on “bots are dumb.” Because they are dumb, right? If something is imba against you, you need to add smarts to fix it—so far nobody’s ranting otherwise. But someday, if we care about balance (which we may or may not), then we’ll want our own maps that are balanced for bots.

Or automatically design bot-balanced maps. It would be a fun research project.

I like CerkoBot by Tomas Cere. Its play is complicated and interesting and entertaining. One bit I especially like is its way of defending its choke: It will chase harassing enemies away, but only up to a limit—it maintains a frontier beyond which it doesn’t stray while defending. Though it’s old, it still puts up a stiff fight against many new bots.

But being old, it has a lot of weaknesses. It’s hardly fair to criticize a bot which hasn’t been updated since 2012, but I’ll catalog the big weaknesses anyway. I must be cruel at heart (but there’s a method to my meanness).

• Its early build order is not safe and it often loses to rushes.

• Reavers are its backbone, but it has poor reaver targeting and doesn’t understand how to position other units to avoid blocking reaver shots. A reaver that is in range of an enemy building will never move forward to target units, no matter how urgent. (Luckily for CerkoBot, reavers are so strong that they often turn the tide anyway.)

• It sucks at keeping its army together. When fast-moving units encounter opposition, they often have to retreat because the reavers have been left behind. That’s only right, but instead of gathering the army at an intermediate point, CerkoBot retreats the distant reavers too, staying scattered. Learn from vector units, they have both scatter and gather!

• It mispositions its observers so that it sometimes has no detection at critical points. It also bunches them together, often losing them all at once.

• In the late game it builds arbiters, but it can’t use them efficiently. It loses them too easily, doesn’t maneuver well to cloak more units, and never uses stasis or recall.

• It can’t cope with a spider mine blocking an expansion spot. I think that’s the main reason that it loses to IceBot.

• It dies against mutalisks.

• Like many bots, it hasn’t bothered to read the victory conditions and wants to fight the enemy’s army instead of the enemy’s bases. (Except the reavers, which shoot buildings over workers.) It will ignore an undefended expansion to lose its army against an entrenched terran formation elsewhere.

If CerkoBot were ever to become a contender again, as it was in its heyday, it would have to fix a bunch of these weaknesses. Eh, probably more. Why not clean the Augean stables instead? That’s why we need starter bots on the one hand (Peneus), and search and learning tech on the other (Alpheus).

Starcraft is hard, therefore bot coding is also hard. A bot needs complex behavior to play a reasonable game without too many gross blunders. Bot authors who start from scratch have a ton of work to do to catch up with the state of the art. I’m thinking of Sungguk Cha’s new terran bot, though I don’t know whether it was coded from scratch. It has a bunch of smart behaviors, but it is scoring poorly so far. It plays well in some ways, but to score well it has to play adequately in more ways yet.

I think the community understands the problem and has done a good job of reducing it. We have starter bots that people can modify (UAlbertaBot is popular, but most bots are open source), and frameworks and libraries that solve common problems (Atlantis, BWTA2, Igor Dimitrijevic’s terrain analysis BWEM, BWSAL, SparCraft and BOSS which are both included with UAlbertaBot). To get well underway in bot coding is still hard, but it’s not for lack of support from the community.

I’m hoping even more people will contribute reusables. If you think you have a good solution to a common problem, why not package it up as a library? It’s good coding practice to have a clear API between modules, so it could help you grow your bot. If the API is light enough, as it should be in good code, then coding the module as an independent library enforces a kind of cleanliness. Then you can distribute it separately to make it easier for others to use. With documentation, of course (that may be the hard part for a lot of people).

As I think about the right way to structure a bot, I keep returning to composable software ideas. For example, the blackboard architecture is an AI classic. (Nova claims to have a blackboard architecture.) Modules are relatively independent of each other because they share data only through the blackboard; it’s easy for different people to work on different modules at the same time; it’s easy to add or replace modules. If it’s done right, it’s even easy to pull out a selection of the blackboard modules and reuse them in another bot that maybe has a different overall architecture. Maybe a modular idea along those lines would help.