RSS

Hang on a second… A Starcraft post filed under “programming”? What sort of organizational shenanigans are going on here, Shamus? Is this some kind of trick? I’ll tell you: Last week I was pondering the mechanics of a Starcraft II rush. I wound up making the hilarious mistake of assuming it would be an easy thing to analyze with a bit of code.

A “rush” in Starcraft is where you forego building workers, constructing defenses, or expanding. Instead you begin the game by building as many of the most basic army unit as you can in the hopes of crushing your opponent before they have anything on the field. A rush is usually considered an “all in”, because if your initial attack fails then you’ll be at a massive disadvantage. You don’t have many workers, or defenses, or expansions. All you’ve got is this small handful of units. Your opponent will be far more wealthy than you, and will be able to out-spend you over the next five minutes or so.

It’s basically like a trick play in NFL. They’re rare because they’re risky, and the risk intensifies the more often you attempt them. It’s considered a lame, cheesy trick only used by the unskilled, the desperate, or (occasionally) the troll. There’s even a Sexy and I Know It parody song about it that makes fun of the notorious and meme-spawning Zerg rush:

Setting aside the jokes, the memes, the flame wars over game balance, and arguments over race: Just how much is the advantage of rushing, and how far behind will you be if you fail? What’s the damage, in a total numerical sense? How many units will you be ahead, and assuming there’s no game-ending engagement how long will it take for your opponent to pull ahead of you? I’m sure a pro player could intuit the answer just from the sheer volume of games they’ve played, but I wanted to see the breakdown on a chart where the rest of us mortals can visualize it. I so decided to write a little program to figure it out.

The cost of everything is right there in the game: The cost of the buildings, the time to construct them, the cost of the units, etc. It’s just like calculating compound interest, right? Just plug the numbers in and see what it gives you.

Well, no.

About twenty minutes into the project I realized I’d greatly oversimplified the complexity of the problem. About two hours later I realized that even my twenty-minute re-assessment had been overlooking important details. What was supposed to be a quick, slapdash problem wound up taking the better part of a day and at the end I have a very strange bit of code and a graph that may or may not be useful.

But before we look at the data, let’s look at how we get the data.

For the purposes of our test, we’re going to be looking at a series of hypothetical Terran players. Zerg have to worry about larvae spawn rates and Protoss have more expensive units. In the former I’d have an extra layer of complexity to worry about that might obscure the thing I was trying to observe, and in the latter it would give our chart less granularity. So what we’re doing is making a program to simulate a Terran player that will create some number of workers, construct appropriate supply depots, and then build one or more barracks structures that will begin pumping out marines as fast as possible. Also note that in the parlance of the game a barracks is often called a ‘racks. Because two syllable words are for people with too much free time.

Players identify early building strategies by how many workers you have when you begin building your production structures. So an 8-racks means you begin building your first racks once you have 8 workers on the field. (You actually need a supply depot first. I won’t get into it here, but for people familiar with the game I just want to note that I did take that into account.) A 10-racks means you build the barracks once you have 10 workers. You begin the game with six workers, so a 6-racks is the lowest you can go.

We keep the whole thing focused on simple barracks units. We ignore gas and we ignore expanding. This is complicated enough as it is.

The first thing I needed was some basic numbers on how fast you can acquire minerals with a worker. Like everything else in this project, this was less obvious than it seems. In the game, workers walk from the base to the minerals, spend a few seconds chipping away at them, and then walk back to base to deposit them in the “bank” where they can be spent. Repeat. This means that harvesting from nearby mineral patches is very slightly faster than harvesting from distant ones. If another worker is already harvesting from the desired mineral cluster, the worker will move to a free one. If there aren’t any free clusters available, it stands in line and waits its turn. This means that there’s some diminishing returns when you add more workers, and at some point more workers will do nothing to improve the yield.

This is really messy and involves way more complexity than I want in my program. I’m not interested in re-creating the precise movement mechanics of the game itself, and attempting to do so would run the risk of oversimulation. I just want a timer that counts seconds and minerals. I don’t want to have to simulate walking workers and worry about base layout and AI pathing.

Thankfully, someone else did the research for me. This post on Team Liquid gives us the breakdown on how fast the minerals come in. The yield between near and far minerals is narrow enough that we can just use the average. Without getting into the details (read the post if you want the full breakdown) the first 16 workers will each harvest 42 minerals a minute. The next 8 will only yield an additional 18 per minute each. Further workers do nothing but stand in line. So workers 6-16 make 42 MPM. Workers 17-24 make 18 MPM. Workers 25 and above will not speed up yield. (Although, they might still be useful. Workers are needed to make supply depots and barracks, and worker #25 could do that building so the other 24 can keep on mining. This would be a very small gain and would a take a while to pay for itself.)

The first question that seems obvious (but isn’t!) is: How many barracks do I build? If I’m doing a 9-racks, do I need to build one bunker? Or two? Three? If I build too few, then money will pile up and I won’t be as strong as possible. If I build too many, then they’ll sit idle most of the time and the resources spent on the barracks could have just been spent making more marines.

A barracks makes a marine every 25 seconds. Which means a single barracks produces 2.4 marines a minute. A marine costs 50 minerals. So it costs 120 minerals a minute to keep a barracks working at capacity. If I’m doing a 10-racks then I’ll have 10 workers who will bring in 420 minerals per minute. That’s enough to keep 3.5 barracks going. Hm. So what the AI (it does seem less like I’m writing numerical analysis and more like I’m writing AI at this point) will end up with is 4 total barracks. The first three will work continuously and the fourth one will be idle about half the time.

But wait! WHEN do we build these barracks? Let’s say I’ve got 3 racks pumping out marines. My bank has grown up to 150 minerals, which is enough for another racks. Do I build another racks right now? The other three racks are busy now, but what if – a single game tick from now – all three racks finish their current production and their marines all pop out? If I just spend my money on a racks, then marine production will stall for some period of time. Is it better to lose a little output now so I can have more capacity later, or should I focus on making marines and ONLY make additional barracks when I have enough cash that building the barracks won’t interfere with marines? Keep in mind that doing the later is actually really complicated. A barracks takes ages to make. I’d need to look at income, look at how soon the current barracks will complete. I’d need to take into account if this is the final barracks, because it might be worth losing production to get a barracks up UNLESS it’s that last odd barracks that’s going to be idle half the time anyway. And what about…

Wow. This question is more complicated than the original question I was trying to analyze. To keep this problem from getting away from me, I decide to simplify. I have it favor building barracks sooner at the risk of forgoing marine production in the short term. I don’t know if this is optimal, but finding the optimal strategy could take bloody ages and I don’t think I need to. As long as all of my tests use the same strategy we should have a pretty good apples-to-apples comparison.

This is a lot of code. I write a system to run a theoretical base, tracking income, counting off units, and building structures. Then I run into the next problem.

This is what a 6-racks looks like. We’re two and a half minutes into the game and we’ve got our first marine on the field.

As I mentioned before, supply is an important concept in the game. You need to build a supply depot for every 8 small units (workers or marines) on the field. A newbie player will forget to build depots until they run into the limit, at which point all production must halt until they can add a depot. It wouldn’t make for a good test if my program made this same mistake. So, when should you build a supply depot? Build it too soon, and you’ll tie up resources that should be spent on pumping out marines. Wait too long, and you’ll get supply blocked. Either way you can choke off production.

Players usually eyeball it at first, and as they master the game the supply depots become a natural part of the rhythm of their build order. But since we need to maximize production to make this test work, we need to build our depots at exactly the right time. It takes 30 seconds to build a depot, so we need to begin building one 30 seconds before we need it.

I don’t want to get too fancy with this, and this can get annoyingly cumbersome if I wanted to be precise. (If I have to start considering partially-built barracks and measuring the time left on current marines I could end up working on this for the next couple of days. It’s not hard code to write, but it’s murderously slow and fiddly to test and once again would complicate something I’m trying to keep as simple as possible.) Thankfully, the time to produce a marine (25) and the time to build a depot (30) are very close. I should be able to look at the number of barracks I have and throw down a supply depot when my supply is that many short of the limit. (Plus one, to give me a slight buffer. Building too soon is better than too late.) If the current supply limit is 19 and I have two racks going, then I should build the depot when (marines + workers + 1) >= 17.

This doesn’t actually work very well. In some cases, the 12-racks might out-perform (say) a 13-racks, both short and long term. That doesn’t make sense.

Eventually I realize that my program is still oversimplifying things. I see that in certain builds, the racks are spending a lot of time idle because the AI is broke. It’s built too many barracks and crippled its production.

It turns out that marines do not cost 50 minerals. Oh, that’s what they cost you up-front at the barracks, but in the long run you also need to account for the depots you’ll be building. A depot supports 8 marines, so each marine is 50 minerals plus 1/8 of a supply depot.

So how much does a depot cost? Well, up-front they cost 100 minerals to build, but remember that a worker must stop harvesting for 30 seconds to build it. (For the sake of my sanity, we’re going to ignore the time it takes the worker to walk over to the building site and walk back when it’s done.) So a depot costs 100 minerals plus it causes you to miss out on 24 units of mineral gathering. The total cost of a depot is 124, divided by 8 marines equals (rounding up) 16 minerals. So the cost of a marine is actually the base 50 plus this extra 16 of sunk costs for a total of 66.

Using this new value, I basically un-kink my production pipelines and all of the builds operate at near maximum capacity. I play a quick game of actual Starcraft 2, and the points of my 6-racks seem to roughly line up with the numbers I’m getting out of my program. As far as mineral values and marine counts, it’s all acceptably within bounds. I don’t guarantee my program is correct, but I’m reasonably sure the values make sense and the rules are being properly enforced. (It’s not spending itself into negative money or building units despite a supply block.) If there are flaws, they’re most likely inefficiencies in my AI and not in the simulation. The values we’re getting should be good enough for the purposes of our analysis.

I have the simulator run various builds and save the unit counts to a CSV file that I can load into Excel. Here is the build for a 6-racks compared to a player that aims for a more reasonable team of 16 workers.

This is the first ten minutes of the game. Our green player was aiming for 16 workers and red was going for a cheesy 6-racks. We see that red gets their first marine at around the 2:20 mark. Green doesn’t get their first marine until a full minute later. Note that it would be foolish for red to charge green’s base right when marine #1 pops out. Green has 13 workers at that point. Workers are terrible in combat, but 13 of them should be able to swarm and kill a single marine with minor losses.

But what if red waits another minute? By 3:20 red has four marines and green has zero. Right at this point in the game, green has finished one barracks and has a single marine in development. At the same time, green is building two more racks, one of which is nearly done and the other is only just started. Still, the rushing player has 4 marines, which should be able to mow down all the green workers. That’s a guaranteed win, right?

It would be, except for this:

It takes anywhere from 30 seconds to a minute to cross the average two-player map. The rushed army of four sets out from their base at 3:20. But by the time they arrive it’s 3:50 and green has 3 units on the field. 4 vs. 3 is still a win for the rushing player in an open fight, but red is likely fighting through a choke point and up a ramp to get into the base. When the fight is over red will have one or two injured marines, and the 16 workers should be able to mop them up. Red’s reinforcements are streaming in, but the rushing player doesn’t have the production capacity to sustain it. Red has two barracks and green has three, with number four on the way. Green has more income and more barracks. There will be minor skirmishes for the next minute or so, at which point the defender will begin to pull ahead and the rusher will never catch up.

You can think of production as a slider between aggression and greed. The sooner you attack, the more aggressive. The later you go, the more greedy you are. Greed will win over aggression in a long game. The trick is that you have to survive long enough for the greed to pay off.

Here is a chart showing a bunch of different builds:

Click to expand to some kinda readable size.

One final little bit of data is the chart below, which I generated for debugging purposes but might be kind of interesting to the reader. It shows the efficiency of the simulated builds.

Build

Marine Count

Average Minerals

Supply Blocked

Production Wasted

Barracks Built

6 Workers

31

51

0:00

1:57

2 (2)

8 Workers

38

46

0:00

5:52

3 (3)

10 Workers

46

61

0:00

1:48

3 (3)

12 Workers

51

50

0:00

5:15

4 (4)

16 Workers

60

60

0:00

4:14

5 (5)

24 Workers

63

67

0:00

2:33

6 (6)

Marine count is how many marines the player had on the field after ten minutes.

Average minerals is how much it had in the bank, on average.

Time supply blocked. Not a problem now, but during testing I had a lot of trial-and-error figuring out how to avoid this.

Production wasted is how many seconds the barracks were idle. If there are three barracks and they all sit idle for a single tick, that counts as three seconds of waste. This mostly happens in situations where the player has enough income to support 4.25 barracks and so barracks #5 spends 75% of its time idle.

How many barracks it built. (How many barracks it planned to build.) These numbers really only apply in shorter tests.

Well, it was a lot of work and in the end we just confirmed what we already knew: Rushing only works because it’s used rarely.

In a real game, people that fall to rushes are usually people who got a little too greedy. Instead of getting out those first couple of marines (or other starter unit) they built upgrade facilities, expanded, and invested too much in technology and too little in defense.

Given that this project was not properly thought out ahead of time, the source for this is pretty rough. Still, the source code is available if you want to mess around with it. It’s a handful of class definitions all crammed into a single .cpp file, because I find it obnoxious when people hand out tiny and self-contained 500 line programs spread over three modules and header files. However, if this project was going to grow beyond this point the next order of business would be some kind of multi-file organization.

You can’t really find hard numbers (it probably depends on the matchup quite a bit), but the optimal strategy is usually to go back to focusing on your economy once you have your rush force – any troops arriving after the initial fight are unlikely to make a difference (you’ve already won or lost the rush by that point), but even if you lose the rush you could have crippled the other guy’s economy just as much as you crippled your own (quite likely if they were just starting to produce troops when you showed up, and you were able to kill a lot of their workers). Getting straight back to your economy instead of throwing good minerals after bad means you’re still in the game.

That’s WAY too much complicated math for me (this is why I’m terrible at competitive Starcraft), but I will say that rushing is a totally awesome strategy against the AI in earlier RTS games like Command & Conquer: Generals. Some factions like the Global Liberation Army (GLA) have units that are structured in a fashion that you can easily rush the enemy base with 1 basic infantry (to capture buildings) and 2 rocket troopers (to kill enemy vehicles, especially the enemy’s initial worker bulldozer, which cripples his production), and the flat-bed truck you loaded those infantry into has a mounted machine gun in the back that will massacre enemy infantry the enemy tries to produce to stop you.

Reminds me of the old “Emperor, Battle for Dune” where rush was THE go-to tactic, especially in campaign.
Everyone started exactly the same: an MCV (mobile construction vehicle) and some units. Once you got to the second mission, you started having some anti-vehicle capabilities, at which point it was a no-brainer to send your initial troops to the enemy’s spawn location to go kill the MCV while you quietly started building. Given that there was a time-lag between the beginning of the map (where you started on sand) and construction (only on rocky plateaus, because of sand-worms and such) it was pretty easy to cripple the AI completely within the first few minutes.

Define the basic seeding build order: six workers
Define the mutations (build barrack, build marine, build Supply, build worker)
Launch the simulation: you can use ticks on a virtual timeline to speed up things, with the algorithm being able to push events on the timeline if conditions are met:
– tick: worker brought some money home
– tick: worker brought some money home, hey i have enough money to build this barrack, let’s do this and recalculate the money ticks coming after because i have one less worker.
– tick: barrack started
– tick: worker brought some money home
…
Evaluate the fitness of the strategy by counting the numbers of marines after ten minutes
Mutate the builds and start a new generation

If i may be so bold, i’d like to know whether you could simulate a bit of micro-harrassment to disrupt the workers of the other player.
For example the 6-rack player could try and disrupt a bit of the production, hence lowering the overall shape of the 16-rack player; It could be simulated by lowering either the amount of money during a period of time, or the worker count.
I’m asking this because i’ve been seeing harrassment tactics on the husky channel that look terribly effective (workers killed, or pushed away from the mineral line) yet don’t seem to provide any overwhelming advantage even though it looks like they should boost the player harassing.

I get the idea that harasment of the mineral line only works in certain tiers of starcraft. On the lower end of the scale (bronze) the harasment takes far too much attention from the harasser in terms of micro that his economy begins to slip.
On the higher tiers (Gold+), the opponent is capable enough to deal with it and likely won’t cause as much. The mid-rage is where I see this working, but I too would like to see the “math on this” as it were.

Actually harassment of the mineral line is done at high levels, including pro league and tournaments, pretty much all the time. Terrans seem to do it the most, because they can get medivacs (dropships with healing beams) fairly quickly and drop marines, mauraders, and/or hellbats, then pick them up when defense arrives. Protoss can do warp prism drops or warp-ins (teleporting units from the base production buildings to the location of the warp prism). Zerg seem to do it the least, usually using mutalisks or (on very rare occasions) overlord drops.

Basically, even a pro level player has to respond to harassment by pulling workers from the mineral line, bringing back (or creating new) army units, building static defenses (missile turrets, spine and spore crawlers, photon cannons), and so forth. It forces them to focus on the harassment (at least partly), can kill several workers if they mess up, and generally just helps the harassing player keep their enemy on the defensive/distracted while they build their own economy/move their army out.

In the recent World Cup Series (WCS), the terran players did so much “drop play” (using medivacs to drop attacking units on the mineral lines, then picking up and repeating) that it actually got kind of annoying to watch, at least for me. It was an extremely rare game when a terran player wasn’t doing multiple drops, often at the same time.

“Evaluate the fitness of the strategy by counting the numbers of marines after ten minutes”

That *really* doesn’t apply. The person that macros up (um, focuses more on collecting resources) will always be ‘fitter’ at that point. The entire point of a rush is to crush (or, when employed by people using /actual/ strategy, cripple) your opponent, at the expense of your own long-term viability. It doesn’t matter if you’d be completely outmatched at the 10-minute mark if they’re dead at the 5 :/

(For better play, rushing is more about reducing your opponent’s long-term viability – you hope to hurt them more than you hurt yourself (note that this requires the rusher to stop committing to the rush at a certain point, once it’s done its damage, and start playing ‘properly’). Also note that ‘better play’ is in no way guaranteed at higher levels ;P. Lots of cheesing in Diamond, ne?)

Then you’d introduce an extra input, “rush at x marines”. Your inputs are then how many workers to build barracks at, and how many marines to rush at. Your fitness is whether, after the rush is over, you are ahead of or behind the enemy.

I also was wondering about the harassment. You said it’s a bad idea to send a lone marine against all the SCVs, but with a range advantage and good micro it should be perfectly safe (unless SCVs are faster, I haven’t actually played), and SCVs either have to be pulled off the line to chase it off or they’ll die.

(Also wave rushes where you send marines off to harass and die would potentially lower the supply depot cost.)

The SCV’s can and will surround the marine with some good Micro on the opponents side and kill it. Usually you don’t rush with Marines though.

Either you try an SCV/Drone rush (Which is most effective as a zerg as they can have 2 drones over the limit with the extractor trick) or you actually put down your racks near the opponents base, reducing the time your marines need to get there.

Your reasoning is sound, Syal. FYI SCV’s are faster than marines, as are the workers of the other two races. Now that I think of it, that’s a crucial aspect of the early game balance, as marines oherwise would be able to ‘kite’ (shoot, run back, shoot, run back) workers all day.

What actually matters is having numerical superiority in the opponent’s base for the longest time.

In AoK, where I was more plugged into the community, most true rushes relied on forward building (and everything was called a rush because of a shift in the dominant strategies) You would walk a worker all the way across the map to build a barracks because the infantry walk times were more important than the lost work and delay in getting the barracks built. It’s a very different game, but the SC Terran analogue is building the barracks in your own base and flying it to the enemy, which requires no additional worker time. I’d suggest that (taking however much barracks time it takes to move the barracks across a 2p map) as an additional mutator.

“the SC Terran analogue is building the barracks in your own base and flying it to the enemy, which requires no additional worker time.”

SCVs move MUCH faster than flying buildings do (three times faster, in fact), so it’s much better to build to build a proxy near the opponents base than to fly your barracks towards a proxy location :/. You lose some minerals, but gain a lot of time.

Very cool :) In order to get it to compile on Linux I had to add #include “cstring”. I also changed the filepath of the output files to remove the e:, I guess you were writing to a specific drive? If anyone else on linux wants to play with it, this should work “g++ SCV_Ready.cpp -o scv_ready.exe”, then ./scv_ready.exe.

There is a strange thing where the number of marines is not being printed properly; (10:00 cï¿½BbBï¿½ï¿½Bï¿½ï¿½ï¿½Bï¿½Bï¿½ï¿½ï¿½ï¿½_ Marines:) but the number of SCVs and minerals is.

Very cool. As someone who has been quite interested in this sort of simulation in SC, gonna post a couple of things.

1) It was *physically* painful to see you type ‘racks’ over and over.
It’s ‘rax’. That is the shorthand! What’s the point of a shorthand that’s 50% longer than it needs to be to uniquely convey the concept??

2) The accuracy of your simplified model breaks down *sharply* after the completion of the first barracks, to the point of meaninglessness, as the defending player – and quite often a rushing player – will create an ‘Orbital’.

Terrans have a ‘macro’ mechanic called Mules: After they have completed their barracks, they can spend 150 minerals to convert their Command Center into an Orbital Command. This takes little over a minute to complete, during which time the Command cannot create new workers. When it completes, their Command Center can no longer carry cargo when flying, and has an energy build-up like a spellcaster unit. It can use this energy to cast one of three spells:

1) They can ‘scan’ an area of the map for instant vision. This is not relevant early-game.

2) They can spend 50 energy to ‘call-down’ supply. This *instantly* creates a supply depot, without spending any minerals, without using a worker in any capacity whatsoever. The only caveat is they must have an existing normal supply depot that has not already had call-down used on it.

This mechanic is quite interesting, is used in some rushes, and would probably markedly change your calculations if not for…

3) MULES. Mules are the 3rd spell. For 50 energy, terran creates a super-worker called a MULE. Mules harvest minerals *several times* faster than an SCV, and they have the unique ability to dual-mine a mineral patch that is already being mined, so no waiting in line and they will always mine at maximum efficiency. A Mule lasts 30 seconds then dies. It takes slightly less than this for the Orbital to gather 50 energy, so you will usually have 2 Mules per base operating for a few seconds per cycle.

A single Mule is worth FOUR (4) SCVs. This means the Orbital Command pays for itself almost immediately, so it is very, very rare that any build, even a rush build, would not get one.

Thus, the longer a player goes after barracks completion without making an OC, they CRAZILY amount behind they are economically than someone who has.

I spent an entire season doing 9 rax rushes against protoss, and my build used a supply-call-down and a delayed Orbital (after 3 barracks) to get the rush to their front door in the few second window where they were vulnerable, and I did a LOT of investigation into this sort of thing – isn’t it just astounding how such a simple small part of the game is so profoundly complex??

It’s relevant because any player not going for a blatant cheese play is going to get an orbital after their first barracks, so that needs to be factored into Shamus’ calculations. It does make a huge difference–it means Shamus is overestimating how many Marines a macro player will have early on, while simultaneously underestimating how many Marines they will have later.

Probably also worth factoring in the need for simplicity as regards this “little” project, as referenced several times in the post! I’m pretty sure Shamus could spend most of the rest of his life on this if he tried to account for every possible nuance … before realising on his deathbed he’d forgotten the early Reaper harass.

That’s not really a small nuance though, it’s going to have a large effect on the outcome. Sure, more economy is still going to come out on top in the long run, but that’s not what’s being tested for. If the rusher’s advantage is larger at the 3 minute mark, or extends past the 5 minute mark, that doesn’t just change the end result; it is the thing being investigated!

Shamus is also not taking into account one other thing: the canonical Terran cheese is the proxy 2-rax. You build 2 barracks out on the map close to your opponent, removing the 30-60s rush distance and thereby significantly reducing the defender’s advantage.

Still, this is very good analysis. I like that the break-even point on Shamus’s graph is at the 5:00-minute mark–it matches up with general wisdom that cheese and other 1-base plays generally must hit before the 6:00 mark if they’re to have any chance to succeed. And the whole sliding scale between early aggression and greedy expansion is the entire basis of early-game strategy, so it’s important to think about. Obviously this kind of analysis needs to be coupled with in-game experience to be useful, but it’s still really helpful to run the numbers to see where things should line up.

This isn’t correct–there is nothing stopping you from sending your building SCVs early so that you start the proxy rax at the same time you would start them in your base (i.e. exactly when you have enough money for them.) That means the rush actually hits the base that much sooner. Otherwise there would be no reason to proxy.

I don’t think including all that was strictly necessary, since as Shamus said this comparison was apples-to-apples. Maybe he COULD factor all that in but it’s unlikely that it would have much of an effect on the relative strength of the rusher vs the defender.

And things would get even more complicated if you would take into account proxys(is it better to have all the marines walk the map,or just one worker that will then be used only for building from that point),pulling in your workers(4 marines vs 3 marines and workers is a definite loss,but 4 marines and workers vs 3 marines and workers can be a win,also is it better to pull all your workers or leave a few to mine),and scouting(what if the map has multiple spawn points,and you pick the wrong one).Rushing does seem deceptively simple,but it is a very complicated thing.Less complex than doing a full game,but still very complex.

Well done, and thanks a lot for the info!
I bet Blizzard themselves have some similar (but much larger) piece of code and use it for balancing purposes.
That said, there are two “real-life” aspects that would probably be impossible to include:
1.: Scouting. If your opponent sees when you build your first racks, they know what to prepare for
2.: Advanced cheese: Don’t just rush with a handful of marines, send a worker with them to build a bunker just outside the opponent’s view. Then a very small amount of workers can cause a nice amount of damage, even if they’re not winning the game.

Ohh, and 3: Depending on your micro abilities, even if you have equal numbers of marines as the opponent, if you manage to kill a bunch of workers or delay a supply depot, that’s already helping.
But as I said, that is entirely beyond simulation.

Hmmm… there’s quite a bit of custom maps/games possible with SC2 — there isn’t by any chance a way of coding one’s own AI for the game and have AI-only tournaments? Because that would be awesome, and it would also reveal a lot about the limits of what’s theoretically possible in the game.
… and it would turn SC2 from an RTS into a programming competition/turn-based strategy game :)

Completely possible, here a video of a little “AI”, microing zerglings to avoid siege-tank splash-damage.
It’s completely written in Blizzard’s World Builder (or so the uploader claims). I don’t see a reason why you couldn’t program a proper all encompassing AI that way

“I don't see a reason why you couldn't program a proper all encompassing AI that way”

Resource cost and algorithm complexity.Sure doing it for just one task (avoiding splash by a bunch of zerglings) is not that difficult.But doing that for all the units,plus doing a bunch of other similar tasks,on top of everything else the ai already does,is next to impossible.

Nevertheless: one impressive feat, even though it’s “only a machine”, isn’t it? I’d have liked to have seen this kind of micro from the squids in Matrix:Revolutions-would have been a way more awesome battle, or not?

Btw: it reminds me of a friend of mine who used to hone his skills by programming AIs to train playing against common Bnet strategies. It was indeed pretty useful-way more useful than the standard AI opponents.

If that exists, there should be an SC2 AI tournament somewhere, or at least some time soon, I’d hope.

That said, I still think it’s impossible to make broad statements as in Shamus’ post about whether one strategy or another is better while taking into account such fine-grained information such as splash-damage avoidance micro. Because in the end, the result will depend on how well you can do it compared to your opponent, and who gets lucky by scouting the right way and so on. You might be able to derive probabilities (after some expensive monte-carlo simulations with AIs) for perfect players or one very specific skill level (which would therefore needed to be materialized in the form of an AI), but that would be it.
…and such results would be moot quickly because human creativity. In SC2 the metagame is almost as interesting as the real thing. Tactics and countertactics, and the occasional WTF tactic in between (oh, how I love those) can and will ruin any battleplan.
The only thing that is roughly predictable is, as Shamus did, macro analysis within a timeframe during which your opponent leaves you alone.

You have way too much free time Shamus, if you have the luxury to write 5-letter words like “racks” instead of the usual “rax” :p

Anyways, wonderful article. I remember trying something similar in the past, but I stopped quickly after realizing how complex this stuff get.

I don’t know if you have already tried it, but there is a brillant open-source build order optimizer application called SCFusion : http://www.teamliquid.net/forum/viewmessage.php?topic_id=168348
It’s a really impressive soft that modelize everything rigourously, including stuff like MULE, larvae mechanis for zerg, chronoboost etc.
You specify a benchmark, say 10 marines with stim, and scfusion will calculate the fastest build order to get to this benchmark (5:43:63 in this case). It’s very fun to toy with to find the most dangerous rush.

Also, you were very wise to avoid Zerg. Not only is their production complicated by:
1) larvae are required to make workers, which have set spawn times
2) multiple workers can be built simultaneously, if there are multiple available larvae
3) zerg buildings are created by sacrificing a worker
4) all zerg rush builds involve using ‘extractor tricks’ to obtain extra supply, which gives you an odd amount of remaining minerals (done by creating the cheapest zerg structure, the extractor, which removes a drone from supply, creating another unit with this supply, then cancelling the extractor, refunding 75% of the minerals and leaving you with more than the legal supply cap)
5) most weird, zerg units and structures both utilise the same larvae, so an attacking unit made means a workers is not made, and vice versa…

BUT ALSO, the zerg macro mechanic means that larvae become available in large amounts after a queen is produced, *effectively making zerg worker production exponential* instead of linear like the other two races: More workers produced means more workers can be afforded, limited only by the supply cap and the zerg needing to start producing units.

Can I suggest you might use Protoss to simplify your model, since protoss buildings have zero building time for the worker (he starts the warp then can go back to mining), and chrono boost is a lot simpler to model than MULEs.

All the data is in the html, so if there is a way to automate the javascript mouse events (to navigate the time bar), then it should be possible to skip writing most of the code, and just iterate based on the URL. Maybe.

Final thing that might be of interest if you’re spending time on this:

There are people who have been braving the complexity of early build calculations – the genetic build calculators have to take into account all the factors you mentioned and *many more*.

While these are build calculators, not AI in any sense, they highlight the weirdnesses a SC AI would have to embrace. When the infamous 7RR and 5RR (seven-roach-rush / five-roach-rush) builds were calculated, the genetic algorithm determined that a a point during the build you need to make three overlords at once. This seems totally counter-intuitive in-game, this build would simply never, ever have been created by a human. The supply timing works out however, shaving 15-25 seconds off the fastest rush build ever before made.

I dont know one thing about starcraft. But the rush strategy might be about getting fast win/loss. If you can get one win out of 10 time in less than 2 min, that mean you do better than a player having a win every 20+ minutes.

In SC2, I played mostly Protoss. The whole creep spread and larvae injection were two additional tasks that I just didn’t have room for in my brain. I’d forget to do one, or the other, or both.

Now that I’m a few weeks into the game I’m giving Zerg a try again. While Protoss is easy to macro, they’re murder to micro. Sentries, templars, blink stalkers, motherships… it seems like every dang unit has a cluster of special abilities.

In Starcraft&Brood War, I also was exclusively Zerg (though I played very irregularly, as I didn’t actually own the game – friend’s house, LAN, etc etc). Having seen a bunch of SC2 vids, I was pretty sure I’d go Terran if I ever actually got to play the game. Which, considering the Starter-Edition+Spawning-Up restrictions, is a pretty fortuitous choice :D

The great thing about this is that up to about Gold League, as long as you focus exclusively on making your macro play as efficient as possible, you often won’t have to even watch your battles to win your matches.

Haha, this is awesome. I remember I tried programming something like this in Python about a year ago. It was a complete failure. I’ve always been a big Starcraft fan. It’s nice to have my favorite video-game writer guy on the boat.

Production wasted is how many seconds the barracks were idle. If there are three barracks and they all sit idle for a single tick, that counts as three seconds of waste. This mostly happens in situations where the player has enough income to support 4.25 barracks and so barracks #5 spends 75% of its time idle.

This is a detail, but does it work like this? If you have enough resources to run 4 barracks for this tick, but you have five barracks, does the game in fact run 4 leaving one idle, or does it leave all five idle until you’ve got enough for all of them? (“Hope you brought enough minerals for everyone!”) For something as fiddly as this rushing appears to be, the difference could be important.

The way it works is actually more strange and fiddly than that. You pay for units up-front when you put them in the queue. So, for optimum resource consumption, you’ve got to micro each factory. Usually you just put all the factories on a control group and tell them all to produce at once, and if you don’t have enough, one or more of them won’t build units. Conversely, if you queue up three or four units in each factory, all of those resources are just sitting there being useless (except for the one that’s being built at the moment). It’s one of the many ways in which Starcraft (of all versions) rewards “skill” of the “mechanical twitchy obsessive” variety.

Except it isn’t twitchy at all. It takes exceedingly good mental discipline to be able to keep up with the mental checklist a typical build order requires. Seeing pros spamming their control groups constantly in a match is meaningless. You can easily match a pro in the early game just by being able to stick with your mental checklist of things to do. Being able to do this effectively means that you will naturally start speeding up your APM as you improve.

Wow, that’s a lot of analysis… forgive me if I’m missing something, but… it seems like this project was focused on rush instead of macro. And not in-game, but in the analysis itself. It looks like you rushed off and started writing code instead of macroing up and figuring out what exactly it was you were trying to solve.

In fact, couldn’t this analysis be done much more simply with a spreadsheet? hmm… yes it can. The trick is developing a unified model for the “total cost” of each unit (as you did by integrating the price of the supply depot into the cost of marines). At that point all you need is a simple calculation for the “time to next unit” and some time offsets for relevant events like depots and such. Instead of modeling time as a bunch of equal length time steps in which something may or may not happen, you model it as events of defined length and then abstract those into continuous time processes for the next level of simulation. Anyway, like you said, a lot more difficult to do it with direct simulation than it seems.

I’ve often wondered why there isn’t a “cyborg league” or even a “cyborg ladder” where players are allowed and encouraged to write their own automation tools and intermediate AI, and then just steer their own custom AI to victory. Tons of stuff (inject larvae, for instance, or building workers) could be easily and precisely handled by such a human-machine hybrid which is difficult for a human to handle on its own. Why doesn’t this exist?

AI League would definitely be exciting to see, if only for the myriad of ways in which the programming could ‘freak out’ and do weird things :D (I’ve done Botball, I know how easily programs can fail, especially on contact with the enemy ;D).

Truthfully, that’s being highly optimistic :/. After a little while, the format would become pretty stale, and basically filled with copy-pasted scripts. Programming freak-outs would become increasingly rare, plus the format would by definition be extremely hard to get into without copypasting things. At least in normal SC2, anybody can play Bronze League, and do unusual things. In AI League, most beginners would have to default to tried-and-true scripts, or else not play :/. And when that happens, there’s not really any ‘playing’ being had.

It would be better if they managed to kill all the enemy workers first. The best would be if you could somehow end up with neither player having any units at all (or the resources to make them). Taking towers into account, that’s probably possible (albeit unlikely).

As a (former) Starcraft II player who has experimented with rushing I have some thoughts on this particular topic. You are entirely correct in your conclusion that the a 6-rax build is not a particularly strong rush due to the fact that a Barracks without a reactor add-on trains only one marine at a time.

The Zerg, however, do not suffer from such an issue because of the larvae mechanic. Every 15 seconds a larva spawns from a Hatchery as long as there are less than 3 larvae already present at the Hatchery. The 6-pool tactic relies heavily on there being 3 larvae available when the Spawning Pool finishes. These can then immediately be morphed into three sets of two Zerglings for a total of six Zerglings. If I recall correctly these should start close to 1:50, hatch at around 2:10 and arrive at the enemy base between 3:00 and 3:10, followed up by another set of two 15 seconds later and a third set of two another 15 seconds later. By your graph a 13-rax Terran will be close to getting out his first marine when the first 6 zerglings hit.

Assuming the Terran has not walled himself in six Zerglins can kill any marines as they come out, prevent any further structures from being built and harass the enemy worker line. Six Zerglins won’t win a straight-up fight against a group of 15 workers, at that point, but WILL significantly disrupt mining / and are hard to catch before military units come out. Of course, it all comes down to micro, as the Terran player can use SCVs to shield his Marines from the Zerglins’ melÃªe attacks while they shoot overhead.

A typical Terran early-game all-in will quickly build a few Marines (between 1-5) and then attack with a large amount (if not all) SCVs, using the buff 45-health workers as a human shield for the Marines. Most of the time this will involve a so-called ‘proxy rax’, which is a Barracks constructed in an often-unscouted area nearby the enemy base so as to reduce the traveling time of attacking units and retaining the element of surprise.

– – – – – – – – – – – – –

On another note, one of the more powerful Terran rushes in Wings of Liberty is the 7-Barracks push (by which I mean, literally, 7 Barracks). This is not so much a rush that sacrifices economy as it does rely on having a healthy SCV count, but one that sacrifices advancement of tech for an early unit advantage.

The idea is to open with a 13-rax build and IMMEDIATELY seal off the ramp to prevent enemy scouting, skipping building a Refinery altogether. You upgrade the Command Centre to an Orbital Command at 15 supply as usual and slam down four additional barracks in the time it takes for the upgrade to finish and another two when resources allow.

With my sloppy mechanics of the day it goes a little like this:

By the time you reach 5:30 in the game you should have about 12 Marines and 16 SCVs or more (the build does skip SCVs in favour of infrastructure) and move out, arriving at the enemy base at around 6:20. While 12 Marines at the front door at this moment doesn’t seem to particularly strong considering your graph, bear in mind that most players will have invested resources in tech and field a significantly less forces around this time.
The push, unlike Zerg’s 6-pool, is not designed to kill with the first 12 Marines; it’s the continuous stream of 7 more inbound Marines each 25 seconds that seals the deal, as generally the enemy player will not have sufficient infrastructure to hold against the waves and waves of incoming Marines.

A Protoss player can typically hold this kind of a rush by using well-placed Forcefields and using Stalkers to ‘kite’ the marines.
Terran players are more vulnerable as Siege Mode for Siege Tanks (staple tech of the metagame at the time) is still several tens of seconds away from finishing by the time the 12-Marine squad is at the front door. Since the front is usually walled with Supply Depots and other unit-producing structures, he’ll take a lot of infrastructural damage.
Zerg players are most vulnerable to this rush as they have no good way to wall off the ramp to their base and stray Overlords (flying units that function as Supply Depots) can be picked off along the way, causing them to get supply blocked. Zergs also frequently take an early second base, which is even more exposed to the Marine onslaught. The only way a Zerg player can meet the incoming threat is either to have rushed Roaches himself (like the famous 7-Roach Rush, which has 7 Roaches coming out at around the 5-minute mark if well-executed), or to have Banelings out by the time the attack hits.

Now a friend of mine and I would use this strategy in ranked 2v2 games. In the case of isolated teammates, this means that ONE player has to deal with a whopping TWENTY-FOUR Marines at his front door by 6:20. Once the first player is decimated, the second player would generally be well-ahead on tech but still not have enough resources to hold off FOURTEEN additional Marines every 25 seconds. In the odd cases that the last opponent would prove a tough nut to crack, the two of us would both build two Refineries; one of us building Thors and the other going for Cloaked Banshees – this rarely failed to seal the deal. We ended up reaching rank 1 in our 2v2 Master League using this, and nothing but this strategy.

If anyone’s interested, I could dig up some old replays of these games.

What about the strategy of making a couple of marines, sending them to harass the enemy gatherers, and then making more gatherers? You lose the marginal benefit of the workers for the time it takes to make the marines, but if 2 marines and a barracks cost as much as 5 workers and take 80 seconds to build, they need to deny the enemy 400 worker-seconds to come out ahead. Killing a worker is worth about a worker-minute (the mineral cost to replace him), in addition to the total amount of time until your opponent gets to his planned number of workers (the time that he is down a worker from plan), and distracting one for a second is worth a second. If you can kill one and distract 12 others for 20-30 seconds by rushing two marines and then going to 16 workers, you get to 16 workers and two marines first.

But that’s a ton of micro to be able to manage, and it might be possible to kill two perfectly-microed marines with fewer than 400 worker-seconds of cost.

It’s true for a lot of RTS games that you can just take your starting units or produce a handful of new units, and rush to the enemy base – at least, this is the case with old RTS games like Warcraft II or Settlers III in singleplayer mode.

I’m surprised no-one has mentioned this, but…I’m pretty sure you can run your “simulation” by doing some calculations on paper, without having to code it. You’re basically talking about Queuing theory (think of marines like delivered packets and workers/barracks like processors), and while the processes involved in Starcraft are far from Poisson (making the math a bit hairy) you should be able to set up some sort of Markov chain calculations to definitively get an optimal marines vs. time line without having to resort to so many hand-waves.

If I had more time and knew more about SC2 I would do the analysis myself. I might still break it out and try it even though I don’t have the time, because it’s an interesting idea…

You know, many of the RTS games, especially in the Age of Empires/Kings/Mythology sequence had lots of clean math on rushing. One of my favorite rush/flush strategies was the English town center rush, where the rush included moving your base.