Entries in Blizzard (21)

Saturday
Mar142009

UC Berkeley StarCraft Class, Week 7

UC Berkeley's StarCraft team defeated MIT's team by a score of 3-2 this week. I think I was supposed to feel happy about that because there I was attending the Berkeley class. But then I was supposed to feel sad because I went to MIT. In truth, I never bought into the us-vs-them concept of school rivalries in the first place but congratulations to the winners.

This week's class was about scouting. Somehow, this involves a bunch of equations and graphs that I don't have time to reproduce for you (nor do I even know how on the web, really) so you will suffer, just like last week. Or maybe you're actually happy about that because it means I'll explain the equations in regular English, so the non-math people will be able to understand more easily?

Choices

Before we get to scouting, let's lay some groundwork. Consider the difference between choices that are discrete and choices that are continuous. If you want to get really technical, just about every choice in StarCraft is discrete because it eventually comes down to the pixel and the clock cycle, but let's not be quite that picky. The categories wouldn't be so useful if we put everything into one of them.

In a discrete choice, we get only the extremes and nothing inbetween. For example, you choose between building a robotics facility or a templar archives. These are different tech trees so this one decision has a lot of implications and you can only have one or the other (early on when you can't afford both). You can't decide to go halfway on that and build half a robotics facility and half of a templar archives.

Continuous choices have much more leeway though. When to make an expansion?

Click to read more ...

Saturday
Mar072009

UC Berkeley StarCraft Class, Week 6

I think I'll skip the math this time because I can explain things just as well without it for this week in particular. Last week we talked about macro (building lots of units), and this week we looked at macro from another angle. The idea is to look at the entire process of manufacturing units to look at the bottlenecks.

Professor Feng emphasized that the entire point of good macro is to create units you can USE. Units that sit around not attacking, don't help. Piles and piles of minerals in your bank don't help. These things are only potential, but we have to cash in the potential to create an actual effect. Here's the six-step process of macroing up some useful units:

 

  1. Get income (minerals and gas)
  2. Make buildings that can produce units
  3. Make sure food/supply is high enough (supply depot / pylon / overlords)
  4. Produce units
  5. Get units out of your base
  6. Actually USE the units in battle

Think of this like an assembly line where a bottleneck at any point will shut down the line. Also note that dropping the ball at a certain point does NOT negate the steps before it, but does shut down the steps after it. If you forget to build pylons at step 3, for example, everything after that is stalled but any work you did on building your income is still valid. It's just that that work stockpiles in the form of "potential" that you'll have to cash in at some later time once you fix your assembly line (build the pylons).

Rolling Dice

Professor Feng also asked us to think about how at each step, we can imagine some theoretical "perfect" execution on our part, but we can also imagine making a lot of mistakes. For example, you can imagine building every single probe at the first possible moment, never putting any in a build queue, never missing a probe. But you can also imagine forgetting to build a probe for a few seconds here and there, or wasting some minerals queuing them, etc. So there's some range of possible executions here when you take human error into account. Remember that EVERY step has this range.

Click to read more ...

Saturday
Feb282009

UC Berkeley StarCraft Class, Week 5

We started out this week briefly talking about a problem from the homework about marines and medics. If H is the hit points of a marine, t is time, and B is the rate the marines take damage over time, then

H - Bt is the hit points of the marine. Set that = 0 for when the marines die and we can solve for t = H/B.

Meanwhile, let A be the rate at which medics heal marines. H - Bt + At is the equation for marine hit points in this case. Again set to 0 and solve for t to get t = H /(B-A).

The ratio of these two cases (marines only vs marines + medics) is proportional to B /(B-A). Looking at the limits, you can see that as A approaches B, the limit goes to infinity, meaning that marines never die. If A = 0.8B, a value reasonable to achieve in actual gameplay, then the limit shows that marines live five times longer. I think the non-math way of saying this is, "against Zerg, use marines + medics." Zerg units (because they have low hit points) can get rocked really bad by marines that live longer, and in some cases, can't even keep up with medic healing.

Economy

First consider an idealized form of the in-game economy, and the exponential growth it has. Imagine you build probes as fast as you can, and then build a new nexus at every earliest opportunity. You do this because building new nexuses (nexi?) is the only way to increase the rate you can produce probes.

If P(t) is the number of probes you have over time, then the rate of change, d/dt of P(t), is proportional to N*B, where N is the number of nexi and B is your rate of building probes. Also, d/dt of P(t) is proportional to P, the number of probes you have. Or at least I think that's what Professor Feng meant here. Solving these differential equations yields P(t) = A0eN*B*t, an exponential graph.

We then saw an example of of this in action on a ridiculous map called "fastest" which starts with your nexus so close to the mineral patch, that the probes have no travel time. By building only probes, then nexus, then probes, then more nexus, etc as fast as possible, you could see the explosive growth of the income. Of course, there are limits here. You can have only 200/200 supply, each mineral patch has limited number of minerals, lots of probes cannot simultaneously mine a mineral patch, etc. Also, you can't have fractions of a probe mine, and you can't spend 25 minerals to build only half a probe, so the idealized exponential graph is not exactly right, but we can start with it to approximate the real state of affairs.

Click to read more ...

Friday
Feb202009

UC Berkeley StarCraft Class, Week 4

I was not able to attend the week 3 class, but here's the summary of week 4.

Professor Feng started with an analogy of the game Battleship (you know, that game where you say "H2," then the other guy says "You sunk my battleship!") What if you played a game of Battleship where the number of attacks you get per turn is equal to the number of ships you have left, he asked. Feng is pointing out the essential slippery slope nature of the game, that your ability to attack is reduced as you start fall behind (as opposed to many games where your ability to attack is unaffected by falling behind--I wrote about this here).

Perfect Micro

Then we explored the math behind this idea. To make it easier, we considered the damage done between two packs of marines assuming all marines are within range of each other in an idealized situation. One player has N1 marines versus the other player's N2 marines. Assume the first player has perfect micromanagement while the other player has the worst micromanagement possible. In perfect micromanagement, as many of your units as possible deal damage for as long as possible. In other words, you focus fire on a single enemy marine and kill him as soon as possible so that the enemy's damage output is reduced. You then immediately switch to a new marine, focus fire on him to kill, switch targets, and so on. Meanwhile, your opponent is attacking in the worst way possible: he spreads out his damage evenly amongst your marines, not killing any of them (thus allowing you to keep your overall damage per second high while his declines).

If each marine deals D damage per shot, then after volley 1, player 1 dealt N1D damage while player 2 dealt N2D damage. Player 1 killed N1D/K marines where K = the hit points of a marine. Player 2 killed 0 marines though.

After a second volley, player 1 still deals N1D damage and again kills N1D/K marines. Player 2 only has N2 - (N1D/K) marines left though, so he deals (N2 - (N1D/K)D damage and kills 0 marines again.

After m volleys of this, how many marines are left on each side? Player 1 will have the same number of marines he started with (N1) for a long time, then they will all suddenly die at about the same time. This is because the opponent is attacking in the least efficient way possible here, basically keeping player 1's marines alive as long as possible. Calculating player 2's remaining marines is more tricky though. Player 2 will deal this much damage after m volleys:

Click to read more ...

Thursday
Feb052009

UC Berkeley Starcraft Class, Week 2

Week 2 of the class was better than week 1 because most of the administrative stuff was out of the way so more time could be spent discussing StarCraft itself.

This week was about units. Professor Feng started by explaining that units are your eyes, ears, and hands in the game. Units give you vision through the fog of war (eyes) and are they are what you use to perform actions such as attacking, repairing, building, moving (hands). What he said we might not realize is that they are also your ears. He mentioned one match where the famous player Boxer put an SCV kind of near some minerals to scout, but it was actually the sound effect for gathering minerals he listening for, rather than the sight the SCV provided.

The next topic was something I refer to as local imbalance, though that term wasn't used in class. Explained in my terms, a game is supposed to have global balance (Zerg vs. Terran for example) but it's supposed to NOT have local balance, or it would be too boring on homogeneous. StarCraft has massive local imbalance amongst units and that is a very good thing.

One example was siege tanks. The longest range Protoss ground unit is

Click to read more ...