Starcraft AI blog

Tanks have long range. Tanks cannot shoot up. Dropping stuff on tanks is a standard way to fight them without getting blown to bits on the way in.

Protoss usually drop zealots: “zealot bombing.” Dark templar are also okay, and they’re especially okay against bots which are quick to scan when a dark templar walks into range. Zerg usually drop zerglings or ultralisks. (Fancy twist: Add a defiler for swarm. Drop other units first to soak up shots.) Terran can go with whatever mech units are convenient. But any units threaten to wreak havoc—probe bombing can be effective.

Here are IceBot’s undefended cliff tanks all but calling out to be bombed.

Sieged tanks have a minimum range, so drop right on them, ideally spreading your units to drop one or a few on top of each tank. The terran will be faced with a dilemma: Unsiege and lose defensive power, or stay put and let the tanks inflict splash damage on each other. Either way, this would be a good time for the rest of your army to rush in and break the push (a more advanced skill).

Terran has defensive options, of course. Anti-air can make drops impossible (you could go drop on an expansion somewhere instead). If the terran mix is tanks and vultures, then it may be inefficient to drop zerglings, but you could try ultralisks. If the terran mix is tanks and infantry, as LetaBot often favors, then dropping on the army may be a bad idea. But notice: Even the threat of bombing the tanks constrains the terran’s play. Anti-air and tanks must stay together for the defense to work. Whatever gives the terran enemy fewer choices gives you more.

The idea behind the protoss bulldog opening is to defeat rear tanks with zealot bombs while dragoons overrun frontal defenses. Bulldog would be a difficult opening to code because of the army coordination it calls for, but it would be cool to see a bot play it. Bulldog counters LetaBot’s siege-expand opening.

Drop has countless uses. A lot of the uses are complex and tough to code, though (I dare you to do reaver drop with all the trimmings). Right now, a few bots do simple harassment drops. No bot has much fun with other drops. I’m going to spend a few posts on drop ideas that seem to me like cool next steps. Who knows, I might even be right!

If you have a macro bot, why not take island expansions?

The SSCAIT map pack, as distributed, includes 3 maps with island expansions, out of 15 maps total (20% of the maps have islands). In all 3 cases, to take an island, you have to drop a worker, mine out the blocking minerals, and then build or float in the expansion. It makes a pretty small state machine. Maps without blocking minerals are thought to favor terran because command centers can float, so they are little used nowadays.

The SSCAIT maps with islands:

• Andromeda
• Empire of the Sun
• Python

Probably the hard part is not taking the island, but populating it efficiently. You want to be able to schedule a task to transfer workers when the expansion is ready to mine—whether by drop, nydus, or recall. (And if you’re thorough, you might want to be able to transfer the workers elsewhere when the island mines out. Nydus and islands are in love and belong together.)

Since no bots take islands yet, surely few bots are capable of attacking islands—probably only bots that already go air. Against many opponents you can get one or two invulnerable expansions, which ought to be a winning edge.

Of course most maps don’t include islands, and if opponents do attack then islands are harder to defend. But a chance at a big macro edge on 20% of maps is nothing to sneeze at. How many opponents will even scout the island?

Speaking of zerg being easiest, I’m pleased with the aggressive new zerg bot Zia (games cast by Nepeta). Zia’s description says it’s “just for fun.”

Zia goes for middle game play with mutalisks and zerglings, complete with upgrades that eventually reach 2-2. (One game in the video also has a hydralisk switch which did not seem advisable.) Other mutalisk bots follow the lead of the Berkeley Overmind and spread out their mutas for (what is advertised as) maximum overall damage rate. Zia doesn’t seem to care about bot fashion. Zia concentrates its mutas into a bunch more like a human player, which may be less efficient in creating damage from an operations research point of view but is aggressive and can be more efficient at actually killing targets—and that’s how you win games.

Attack-oriented opponents, even strong ones like Iron and tscmoo terran, seemed unable to defend against so many mutas flying so aggressively and backed by lings. Defense-oriented bots like LetaBot (which holds its base with active defense and saves up its strength for mighty strikes) didn’t have much trouble, though. I also saw Krasi0, a hardened veteran that learned mutalisk defense facing the Berkeley Overmind, adapt effortlessly and win.

I like Zia, but by now you must realize that I’m not psychologically capable of finishing a post without asking for more. Mutalisk targeting looks a little haphazard—too much zipping about, hitting the wrong enemies, and taking incidental damage. When you concentrate your force, it becomes much more important to concentrate it in the right place! One thing the Berkeley Overmind did right was to fly around the perimeter of the defended area looking for weak points. Also the lings are not attacking as much as they should, as if they were sometimes ordered to move while next to a target. Would that be fun stuff to improve?

Update: Zia starts +1 attack for its mutalisks before spending on the first mutalisk. That’s dedication!

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.

The secret motivation behind the last two days of posts is to remind us all how hard Starcraft is. Not that anybody forgot but—even when you know it’s hard, you don’t know. The amount of knowledge and skill it takes to play well is huge, and we don’t know how huge because most of it isn’t written down. Humans can’t write down everything they know, even when they try.

Adding knowledge to a program is also hard. People who worked on expert systems starting in the 1970s named the problem the knowledge acquisition bottleneck: The bottleneck in acquiring knowledge from humans and making it available to computers.

Right now, most knowledge acquisition in Starcraft bots happens by bot authors manually coding it in, the most direct and the slowest method. There are exceptions, of course. But if we want to make faster progress, we have to take faster ways. There are three broad classes of faster ways.

1. Code it better. One of the things expert system researchers did was invent knowledge representations to make it easier to encode knowledge. Computer code is procedural, but knowledge is declarative. You want a knowledge representation language to be as declarative as possible; some fixed set of coded procedures interprets the declarative knowledge to put it to use. LetaBot’s database of build orders is an example: LetaBot declares build orders and code compares the build orders against scouting information to decide what to do. I approve. A number of bots are coded in domain-specific language style, where the program implements what amounts to a higher-level language to describe Starcraft behaviors. Skynet is a good example. I approve of that too. Coding knowledge is still hard, but these kinds of steps make it easier.

2. Search bypasses knowledge acquisition. Chess as played by humans also requires huge knowledge to play well, but chess programs don’t need to encode most of that knowledge because search can discover stuff on its own. In a chess program, most of the skill comes from knowledge encoded procedurally in the search and the evaluation function. Most of the knowledge by bulk, adding a little more skill, comes from databases of opening and ending positions. And how were those databases created? By offline search, like the strategy catalog that I proposed.

In Starcraft we may want separate searches, and/or separate knowledge bases, at the strategic, tactical, and unit control levels. I don’t know any bot that does strategy search. MaasCraft does tactical search. The SparCraft library does unit control search.

3. Learning automates knowledge acquisition. The strategy learning that some bots do now is different; it is opponent modeling, learning the opponent rather than learning about Starcraft. Learning for knowledge acquisition means learning to play Starcraft better from data, whatever the data may be. A few old bots like BroodWarBotQ used to learn tactics and unit control, though they’re gone now so apparently it was not too successful. We’ve heard that Tscmoo is working on neural networks for strategic decisions, but have no details. Other than that, I don’t know any current bot that uses learning for knowledge acquisition, whether for strategy, tactics, or unit control. (Though I wouldn’t be surprised to hear of one.) If a bot learns from replays, it can learn from the replays of humans or of other bots as well as its own.

As an aside, I think learning for opponent modeling using replays would be good, but current tournaments don’t allow for it. Without replays during the tournament, replay learning can only be done offline ahead of time—which is cool for learning for knowledge acquisition.

For now, comments are allowed throughout, even on the oldest posts. After the first comment was spam (to no one’s surprise, I’m sure), I turned on moderation: Subscribers should see no junk, but comments may be delayed while I approve them.

If you don’t want to post a comment, you can e-mail me directly.

In Starcraft it seems that decisions have to be made at about 3 levels of abstraction, which go something like this:

• strategy - what tech to pursue, when to expand, etc.
• tactics - maneuvering the army, deciding when to fight
• unit control - moving, targeting, casting

Most people seem to like 3 levels. Maybe some prefer 2 or 4. For example, if you have opponent modeling or strategy learning then you might want to write it in at the highest level, a meta-strategy level at which decisions have effects over multiple games. And of course there’s no agreement on the names of the levels or on exactly which decisions each one includes (the decisions above are examples and don’t cover everything). But my list is similar to most.

One way to look at it is that plans made at a higher level last longer and have to be made less often: They are in effect for a longer period. At the strategy level, which tech path you take or how many workers you cut for a rush may be part of a plan that the bot follows for minutes. At the unit control level, which enemy you target in a fight may have long-term consequences (do you win or lose the battle?), but the decision itself may be over in a fraction of a second and then it’s time for the next one. The paper A Survey of Real-Time Strategy Game AI Research and Competition in StarCraft points this out, as well as other differences between levels of abstraction.

Bottom up. The way I think of it is this: It’s theoretically possible to make all decisions at the unit control level. Your initial nexus is a unit, each probe it makes is a unit, all you have to do is give the right commands at the right time. But it’s crazy hard to coordinate a strategy if you only think at the detail level. Abstraction is necessary if you want to have effective game plans; it is just plain infeasible to find a good strategy by trying different patterns of low-level actions until you hit on something that works, simulated annealing-style. If it’s possible at all, that kind of strategy search has to happen offline.

Top down. On the other hand, PerfectBot certainly doesn’t make strategy decisions without considering the tactical and combat situations. The levels of abstraction are not isolated. Remember mine laying from yesterday: Mines have long-term strategic, short-term tactical, and immediate combat uses. To decide how to best to place spider mines, PerfectBot has to consider every level of abstraction.

Someday actual bots will want to consider every level of abstraction too. Cue topic hierarchical search, which I’ll write about someday. Another idea for integrating levels of abstraction is mission command, a term from the real life military. In outline, the commander sets overall goals and the subordinates figure out how to achieve them. One implementation for Starcraft (quite different from how it’s done in real life) might go like this: The strategy boss, paying no attention to the tactical situation, figures out possible strategic goals and scores them. “We need resources most of all, 100 points for a new expansion. We need to counter lurkers, 50 points for vessels and enough tanks. The opponent is taking bases, 50 points for killing an enemy base. It would be nice to harass, 20 points for wraiths to hunt overlords or 20 points for small drops to get drones.” The tactics boss considers tactical plans and scores them in part by how well they achieve strategic goals. “We can’t expand (0 points) or kill bases (0 points), we’re lurker contained (curse KillerBot!). Tech to vessels and make tanks until we can break out (50 points); harassment is worth less.” You get the idea.

I’ve been thinking about mine placement. Where do you lay spider mines? It’s a tiny part of Starcraft, but even by itself it’s super complicated.

Attack units or see the map? IceBot lays mines in a wide grid pattern, each mine in sight range of its neighbors, that gives plenty of warning of incoming attacks or drops. But the mine grid doesn’t kill many units. WOPR lays mines in dense bunches along the shortest path between main bases. Bunched mines don’t scout as widely but are dangerous to force because they trigger in groups. Tyr lays mines in a tighter grid pattern, which could be a compromise between the two goals.

Offensive or defensive placement? IceBot and Tyr lay mines outside their own base to defend. Iron lays mines aggressively outside the opponent’s base as part of a containment game plan. Another good offensive mine placement is up ramps, taking advantage of high ground and vision. I haven’t seen any bots seem to do that intentionally.

Strategic versus tactical area denial. Iron’s containment mines are laid for a strategic purpose. “If you ever want to leave, you have to pass my minefield.” It’s also possible to lay mines for short-term tactical purposes: to block a retreat, to hinder reinforcements, to keep vultures unmolested for a short time while they massacre workers.

Strategic/tactical versus combat mine use. IceBot, WOPR, and Tyr lay mines to be triggered later. Tscmoo and Iron not only do that, but also attack sieged tanks by laying mines next to them that trigger immediately. In human play it’s popular to attack dragoons with mines, but that attack is trickier to pull off because the vultures have to coordinate to block the dragoons from running away.

Blocking an expansion. Several bots, including IceBot and Krasi0, lay mines at expansions. The mine scouts the expansion and delays the opponent from taking it. (By the way, dark templar or burrowed zerglings could do the same.) In principle, mines could block other buildings, but what other opponent building appears in a predictable place? Well, you could use mines to delay terran add-ons.

Luring is still too fancy for bots, but they’ll get there someday. For example, lay a mine in the enemy probe line and then try to entice a zealot in. Devastating when it works.

Mines can also be used to bypass map obstacles, to attack drones when triggered by a larva, and more. Besides the positive uses, a complication is that mines can harm friendly units, which the opponent may try to exploit by mine dragging. Skynet knows how to drag mines (at least its code says it does).

How will PerfectBot lay mines? Being perfect and all, PerfectBot knows the uses of mines and can judge which uses are more important when. I have to imagine that PerfectBot does all the things I mentioned above, and probably in an unpredictable adaptive way. I can’t wait until the end of time to see what it looks like!

Upgrade complete! That sure took a long time (I had insufficient vespine gas).

As promised, there is an RSS feed. Online services can turn the feed into e-mail notifications, if that’s what you prefer. Plus other new features. I’ll be working behind the scenes to clean up details and add categories.

Regular Brood War posting mania returns tomorrow.

GarmBot was reuploaded twice recently on SSCAIT. It looks as though it is under development again. Woohoo! Its description has added the message “Now with some lurkers. Big update coming to upgrade to BWAPI 4.1.2.” And I did see it build lurkers, which could spell trouble for some opponents (ones that GarmBot didn’t already overwhelm, I mean!).

GarmBot’s strategy is unsound, of course, but it’s also unique and delightful. It has a lot of room to improve without varying from its extreme macro, every-unit-for-itself game plan, so I’m interested to see how far Aurelien Lermant will go. Will some units get better micro or better decision-making? Will it make cleverer choices about which units to make where, such as not hatching drones to die instantly at a base that’s under attack? I would be interested to see whether it helps at all to build defensive units at a base that’s under light harassment and to waste as few resources as possible at a base that’s under massive attack—improvement or “so what?”

Not to put impossible expectations on anybody, but I can hope.

Update: The current GarmBot seems cleverer in some ways. For example, it is smarter with overlords. It’s also less aggressive about expanding and less successful overall. That’s OK—when adding ideas to a performance program it is normal to make the program worse at first, even when the ideas are good. The rest of the program may be optimized for the old behavior, and then you need a lot of updates.

The last two are not even completed and LetaBot is starting another tournament. The announcement post on Team Liquid: StarApple D/D+/C- man vs machine tournament.

I like these tournaments. Human players and bots both face game play that they haven’t seen before, which is a great way to get new ideas. I hope lots of bots will sign up.

Update from Martin Rooijackers, aka LetaBot, who runs the tournaments. He points out 1. In one of the still-running tourneys, all bots are eliminated so it is no longer a man-machine event, and in the other, one bot team is already eliminated. Bots have it tough. And 2. the bots are under active development and several have updates already. Play tourney, get smacked, fix weaknesses—sure is nice when the next event is soon!

Hey, as long as people keep signing up.

Games of Iron against different versons of LetaBot have been entertaining me. Iron has learned the same trick as Tscmoo of killing tanks by laying mines next to them. LetaBot often suffers unnecessary mine hits when it sieges up just as a mine triggers. On the other hand, LetaBot also has micro skillz and likes to kill mines after they trigger—I’ve seen it kill a mine with two fast-reacting SCVs!

The games go back and forth, but Iron has the upper hand for now. Iron has become strong against other bots. LetaBot could improve by sieging more cautiously, which is part of the terran technique of inching units forward to force a minefield. Or it could scan for mines. Scanning intelligently for mines is not that easy because the bot has to keep track of where mines are likely or possible, which seems like a lot of coding work to support a single skill.

in other news

Rob Bogie has uploaded MaasCraft (originally written by Dennis Soemers) to SSCAIT, and it plays like the replays I watched last month. MaasCraft is scoring poorly—the opposition is a lot stronger than in 2014. He also re-uploaded it, which sounds like an update. Is MaasCraft going to see major updates under its new ownership? I haven’t yet noticed any changes to its play.

PS Making slow progress on the website improvements. I chose a hard road for myself.

Here Tscmoo has discovered that Tyr built near the edge of its low-ground main base and is vulnerable to attack from outside. Blasting down buildings with no losses helped Tscmoo in its easy win.

Did Tscmoo’s tank just happen to wander into a good position, or did Tscmoo analyze the situation to find the opportunity?

Noticing when you can shoot across a barrier is a great skill. I’ve seen other bots miss chances for free kills with tanks and even with dragoons. And it’s not hard—all you have to do is figure out what’s in range from where, and recognize simple cases where it gives you an advantage. Human players are always on the lookout for chances like that.