Hello

A couple of months ago I was writing an article series about real-time strategy game design. I never finished it (and I should!), but I wanted to make a small comment about one thing I wrote in one of the articles, let me quote myself:

In the current alpha build of Starcraft 2 the only remaining hero unit is the Zerg Queen. [...] Hopefully they will rename her, and allow the player to use strategies that involve building several.

Well, it turns out that I was right

Now all I want from the Starcraft 2 design team is to move the health bars to the feet of the units instead of flying around above their heads. Pleeeeaaase?!

In this part I will describe in more detail what abstract, or “hidden,” balancing is and how it can be used in your game. This is the last part I’ll post for a while, since I’m going on vacation for a few weeks, but I’ll be back next year!

What is Abstract Balancing?

As already mentioned, abstract balancing is changing how well a unit performs by modifiying calculations that take place “under the hood” in your game. Examples of abstract balancing are damage values, health counts, armor values, attack accuracies (attack probabilities), armor types and so on.

Abstract balancing is used when – to the player – two equivalent actions should yield different results. For example, a swordman attacking a horseman may not give the same effect as a pikeman attacking the same horseman. This is based on the “pikemen should deal more damage to cavalry” type of abstract balancing.

Damage Modifiers

This is abstract balancing at its purest form. Damage modifiers are needed to keep certain unit abilities in check and help mixing up an otherwise single-unit army. The problem with them is that they require practice on the player’s part to fully understand. When they are used, they should be kept as consistent as possible. For example, in C&C 3 all bullet type weapons are efficient against all infantry units.

Starcraft uses a fairly simple table for attack modifiers. It has four armor types and three damage types, as seen below:

•  ”Concussive” attacks deal full damage to soft armor, half damage to medium armor and one quarter damage to hard armor
• “Explosive” attacks deal half damage to soft armor, 75% damage to medium armor and full damage to hard armor
• “Normal” attacks deal full damage to everything
• Protoss shields take full damage from all kinds of attacks

In other words, one attack type is effective against small and organic units and another is effective against armored units and buildings, and a third that deals full damage to everything. This kind of system should suffice for most games, unless there are different kinds of instant-kill weapons, such as sniper rifles (which usually are completely ineffective against armored units). However, keep in mind that visible balancing is always better than abstract balancing, so an “Unable to attack target” message is better than dealing insignificant damage.

Chance to Hit Probabilities

Projectile accuracy is something that can be designed to be visible to the player. Age of Empires 2 does this beautifully, which I will describe in the part about visible balancing. However, projectile accuracy can also be designed as an abstract modifier called “chance to hit probability.”

Essential this kind of probability is a modifier which changes how much damage a unit inflicts when it attacks. This doesn’t need to be a bad thing, but it’s very important to make sure that it’s easy to recognize when an attack has hit or missed. In Dawn of War it can sometimes be hard to tell when this happens because 1) a missed shot may sometimes fly through a unit, 2) hits also fly through units because of a render bug and 3) units have a high rate of fire making it less relevant which of the shots that miss.

Hit Points

Health meters are so common in games that most players know exactly what they represent and how they work. That is not necessarily the case for new or casual gamers, but generally it’s a lesson quickly learned. However, health is still use of a kind of hidden balancing since people rarely memorize the health counts for all units in the game.

Using Feedback to Transform Abstract into Concrete Balancing

The problem with hidden balancing is that it can be difficult for players to understand why something is going well or bad for them. This can be remedied by including appropriate feedback for the events in the game. For example, if an attack with a “good” damage type is used on a target, show it to the player with a more spectacular impact effect and sound. Try to keep all units of the same armor type similarly-looking. Try to match hit points with the unit’s size. And so on…

In the indie game, Project: Aftermath (2008, Gamesfaction), they represent different damage/armor types with colors (red armor protects versus red attacks etc). Though simple, it works well and is an integral part of the game (unfortunately a little bothersome as well due to how the user interface is designed). You could consider something along those lines if you use a lot of abstract balancing in your game.

In any case, as I wrote in the previous post there are two main kinds of unit balancing, visible and hidden balancing. (I will alternately use the terms “concrete” and “abstract” balancing as well.) In this post I’m going to describe in more detail what visible balancing is, and give some examples. It’s worth mentioning that a lot of these suggestions aren’t restricted to RTS games only, but to game design and balancing in general.

Visible Balancing

Visible balancing is when the game’s mechanics prevents something from happening. For example, units that are unable to attack flying targets have been balanced using visible balancing. Visible balancing is easier for players to understand and learn than abstract balancing, but abstract balancing is usually required in order to maintain complete balance.

Another way of explaining the difference between visible and hidden balancing is that visible balancing gives explicit feedback while hidden balancing gives implicit feedback. Implicit is when you send in a group of soldiers in a melee and come out victoriously with half of the soldiers still alive. Explicit is when you send the same group of soldiers against a group of crossbowmen and have all of them shot down before they even get within reach.

A game should attempt to use visible balancing whenever possible.

Unit “Dimension”

“Dimension” refers to the units’ “plane of existence” and not unit size. For example, units that are walking on the ground are in one dimension (the ground dimension) and units which are flying are in another (the air dimension). Unit dimension is not the same thing as unit detection, which is described below. For example, in Warcraft 2 there are submarines that the opponent needs to detect in order to attack (using fliers or guard towers), but they still exist in the “ground” dimension (units which can attack ground targets can also attack submarines).

The number of dimensions in a game depends on the game’s setting, but can be tweaked by the game designer if necessary. Supreme Commander has three dimensions (air, ground and submerged), while the before-mentioned Warcraft 2 keeps it to two. Some games, such as Homeworld (Relic Entertainment, 1999) and Dawn of War have a single one.

Using dimensions is a very good way of adding concrete balancing to a game. They are usually easy to understand and easy to adapt to. They also make the tech tree more flexible and gives the game designer more options to explore.

Units that are able to attack units on multiple dimensions, or even cross dimensions themselves, are more valuable than other units. These are “versatile” units, and usually cost more than single-dimension units because they are harder to counter. Versatile units are sometimes balanced to be vulnerable to units that are specialized on attacking their dimension. For example, the Protoss Dragoon in Starcraft stand little chance against Zerglings, considering that they are about five times more expensive.

Attack Abilities

Attack abilities are things such as attack rate, range, projectile speed, area of effect and so on. These are visible ways of balancing attacks. Hidden ways of balancing is when using attack modifiers, such as damage and armor types. I will cover these in the next blog post.

Attack Ability – Rate

Attack rate, or rate of fire, is one attack ability which is easy to visualize. The rate of fire is controlled by a delay timer between attacks, and this delay can be placed before or after the attack, or distributed on both before and after. If the delay is placed before the attack, it will make the unit weaker compared to if the delay was placed after. This is because short reaction time will give the enemy units less time to move out of the way or shoot back.

The delay length will obviously control how quickly the unit is able to attack. In case you want to maintain the same “damage per second” ratio, short delays will make the unit weaker than longer delays. For example, imagine that a unit should deal 1000 points of damage over a second. If the delay is 0.2 seconds the unit would fire five shots that deal 200 damage each, and if the delay is a whole second, the unit would fire a single shot dealing 1000 damage. One big shot will give the enemy unit less reaction time and decrease its chance to get out of the fight alive. However, short attack delays are better against many weak units, so this type of balancing is useful if you want units to be good at different kinds of combat scenarios.

Attack Ability – Range

The attack range is  another visible type of balancing, since it’s quite clear to the player why a unit is able to attack or not. Attack range is a surprisingly strong unit balance modifier, because a unit with a range advantage will be able to deal damage without getting hurt at all.

Attack Ability – Projectile Speed

Projectile speed could also be called “the delay from attack until damage,” and is also clearly visible to the players. It’s not such as strong balancing modifier as attack range or rate, but having a quick projectile is better than a slow one. Slower projectiles can also create situations where units “waste” attacks on targets which are defeated while the projectile is still travelling.

Projectile speed has more impact in games where attacks are made on a position rather than a unit. Attacking positions makes sense, but will make balancing slightly more difficult since movement speed and micromanagement of units have more effect. For example, the Grenadiers in C&C 3 throw slow-moving grenades that aren’t homing, which means that if you pay attention you are able to move your units out of the way before impact. All attacks in Starcraft are homing (targets a unit instead of a position), which may feel unrealistic and inappropriate for your game.

Attack Ability – Accuracy

Projectile accuracy is another attack ability which can be both concrete or abstract depending on how the game presents it. Accuracy of archers in Age of Empires 2 is clearly concrete, because if an arrow hits a target it also deals damage. This is cleverly included in the game’s tech tree, as ranged attacks can be upgraded to aim in front of moving targets, increasing the accuracy in a visible way. Accuracy in Dawn of War, however, is implemented in an abstract way. Hit or miss is determined with secret dice rolls that are affected by a number of modifiers. This randomness is fine, but the problem is that visually it’s hard to tell if a shot has hit or missed. Additionally most weapons have a quite high rate of fire, which means that over time the accuracy is more or less a damage modifier rather than interesting gameplay.

Movement Abilities

Unit movement is also quite visible and can be used to balance units against each other. The most basic way of doing that is simply to change the unit’s movement speed (a very strong modifier), but you can also balance units by changing if they are allowed to move and attack, if they must turn and face the direction they are moving (turning speed), if they can pass obstacles (flyers) and so on.

Movement abilities are usually strongly attached to the look and feel of the unit, so maybe you’d rather prefer to fix the unit’s movement and then use other variables to balance it in global scope. As comparison, I haven’t heard of any games that has released patches which changed the movement style of units, but unit costs and damage values tend to hop up and down.

Cloaking and Detection

The title is somewhat mis-leading, because this ability is more about situation-based unit invincibility. These kinds of abilities are usually quite clear and visible to the players, but how they are countered can be a bigger problem. In other words, it’s usually easy to notice that an invisible unit is killing your troops, but it’s not as easy to know what to do to detect that unit.

The interesting aspect of these abilities is that their usefulness is based on the opponent’s access to a counter to the ability. Adding these kinds of abilities is more a question of technology tree balancing than unit balancing, and may require some player education due to the aforementioned problem.

Visible vs Hidden Balancing (or Concrete vs Abstract)

There are two main kinds of unit balancing, and I will write a separate blog post for each. The first one, which I will alternately call “visible” or “concrete,” is balancing which the player can see, hear or feel. Visible balancing are things such as unit speed, attack range and unit movement dimension (ground, air, water etc).

The second type of balancing is the “hidden” or “abstract” type of balancing. This kind of balancing is used in the game’s rules, changing probabilities for events or efficiencies of abilities. Examples of abstract balancing are unit health, damage/armor types and similar stats. Abstract balancing is usually presented to the player through text labels in the user interface.

As a rule of thumb, visible balancing is better than abstract balancing, but you will most likely need to use at least some kind of abstract balancing in order to tweak things.

Rock-paper-scissors vs Weakness Support

In most RTS games you would prefer if the players built several different kinds of units. A game could be interesting even with only one major unit type, but people may complain that it’s all about “massing units,” which will hurt your reviews. The standard way of enforcing this is to make sure that all units have at least one weakness. This weakness can be exploited by your opponent, and thus forcing you to mix up your units a little.

How you apply this unit mix enforcement depends on whether you want to use a rock-paper-scissors type of unit balancing, or if you want to go with “weakness support.” The first is when you design your units to be strong against a specific type of enemy unit (or type of units), and weak against another. For example, you may want your archers to be strong against infantry, but weak against cavalry (or whatever rocks your boat). This kind of balance can be created by simply using abstract balancing of unit stats (health and damage ratings), though your game will be more interesting if you are able to use visible balancing instead (more about this later).

The second option, “weakness support,” is when you make sure that all units have a certain weakness. The difference to rock-paper-scissors is that the weakness is based on an attribute of the unit, and not on the attribute of an enemy unit. For example, the weakness with infantry in the rock-paper-scissors scenario above is that it’s vulnerable to archers. In a “weakness support” scenario the infantry’s weakness would be slow movement (and maybe its inability to attack flying targets, if it’s a fantasy theme). The “support” in “weakness support” refers to how the players should reinforce the unit’s weakness. For example, if the infantry is slow-moving, then maybe its “weakness support” is wagons which can transport infantry quickly into battle. In other words, infantry lose to archers, wagons lose to archers, but infantry and wagons together win over archers thanks to the weakness support.

Adding Units to Your Design

I was going to write more in this section, but when it comes to adding new units to your game, you should probably listen to the advice of Dustin Browder, lead designer of Starcraft 2:

1. A unit should have a cool personality. A unit must be something that is fun to play with.
2. A unit should have their own very unique role on the battlefield.
3. A unit should be fun for the enemy to try to deal with. Generally this means good strengths and interesting weaknesses.

What that means, essentially, is that you should create units that you think are cool and see how they fit in your design. You shouldn’t try to design new units to solve a problems in your current design, but rather see how you can make your current units work better together. Add units that feel right and remove those that don’t. Unfortunately, not everybody has the luxury of infinite development time like Blizzard…

Macromanagement Limits

Macromanagement limit types, or macro limits, are obstacles that will prevent the player from getting too many units or too much resources. Examples of macro limits are unit supply used in Blizzard’s games and resource storage used in Command & Conquer and Supreme Commander (etc). Both these limits are upgradeable, and hence becomes a part of the macro itself.

Generally speaking, macro limits are not that good to gameplay. It adds things that the player must do that are not necessarily interesting or fun. For that reason, it’s important to make it interesting by letting it impact the player’s decision making, and offer a target for the opponent to destroy.

Unit Supply Limits

In games that use active resource gathering and multiple sources that can construct units, it can be a good idea to have unit supply limits. Supply limits will prevent the army from growing exponentially, and help balancing the cost of time (see previous post). During early-game the player will be forced to fill the supply with either military or economic units, and may choose to specialize on either. Unit supply limits may also improve your game’s performance, or at least prevent it from becoming too sluggish.

Starcraft also makes unit supply more interesting by adding additional functionality to the sources that increase the limit. The Protoss Pylon is used to enable other buildings, and the Zerg Overlord is a flying unit that can be used to detect cloaked enemies and transport units across the map. The supply limit is also used to give each faction a unique “feel”. On the contrary, they completely missed out on this in Warcraft 3, and made the unit supply limit very uninteresting and tedious.

In Dawn of War the unit supply limit is attached to the current technology level. That means that the army size grows as more advanced units are unlocked, and prevents the game from consisting of masses of level-one tier units. Though this kind of unit limit isn’t very interesting, it’s not tedious to player either. Some of the races have special kinds of supply limits, but in these cases they have multiple uses, such as acting as defenses or healing nearby friendly units.

Resource Limits

The other kind of macro limit is limiting resources that the player may have in stash. For example, the amount of money you are allowed to have in the bank is limited by the size of the bank, so you may be forced to buy a bigger bank if you are hoarding money. This kind of limit is quite poor and only penalizes new players to the game because a good player will know how to keep producing units. Also, the game’s feedback is usually incorrect – it will tell you to increase your stash limit, not to produce more units (which is the correct solution).

Frankly, all resource limits used in games so far have been bad. Take Supreme Commander as an example. The game has a passive income system that never runs out of resources, so having a maximum stash capability sounds like a reasonable idea. However, these buildings (mass and power storage) are not very interesting to build, and they are neither an interesting target for your opponent, since destroying them will not limit your capability to produce new units (you will still be more limited by the income from the passive resource gatherers). And finally, the mere appearance of the buildings in the user interface makes it more difficult to find the more useful construction options.

Lets say the game is about keeping a village running. If the game featured seasons, it would be quite fitting to have resource limits, such as saving up food for a harsh winter. They key is to keep it interesting.

Artificial Limits

As already mentioned, most games also include artificial macromanagement limits due to the finite processing power of our computers. An artificial limit is something imposed by the game, and can’t be affected by the players. In Starcraft there is an 1600 unit limit for all players, neutral units and mineral patches combined. If the unit count reaches this limit, all players will be unable to produce more units or buildings. In Supreme Commander this limit may be changed by the host, from 250 to 1000 units (including buildings) per player. In any case, these artificial limits are not intended to take effect, but are required in order to keep the game running.

Specific Unit Limits

This topic is related to unit balancing, which I will cover soon, but several games have limits on specific units in addition to other macromanagement limits. Usually the limit is “no more than one”, creating so-called “hero” units. Generally speaking this really hurts gameplay, because 1) too much focus is placed on the unit and 2) the unit is usually over-powered. Over-powered doesn’t necessarily mean imbalanced, but it means that when your opponent spots your unique unit, he must immediately devote all attention on attacking it, or countering it with his own unique, over-powered unit.

With that being said, limiting a unit type does make it less powerful. For example, imagine that the Protoss Arbiter in Starcraft was limited to only one at a time. The Arbiter is an expensive flying vessel with some very powerful spells (Stasis Field and Recall), as well as an area of effect that makes nearby friendly units invisible. If a player was only allowed to have one at a time, he would have to choose whether he wanted to use Stasis Field or Recall, since he wouldn’t be able to use both. Also, since the Arbiter takes such a long time to build and is so helpful for his main force, much devotion would be spent protecting it. However, it’s very difficult to protect the Arbiter from the EMP spell of the Terran Science Vessel or Lockdown of the Terran Ghost, so these counter-units would also have to be re-balanced as well. Needless to say, Starcraft would play a lot differently.

One game that heavily utilizes unique units is Dawn of War. Each army has a commander and a “relic unit”. These units are very powerful and take a central role in the player’s army (with a few exceptions, such as the Eldar Avatar of Khaine, who lives his life happily in the back of the base due to his passive powers). For example, let’s take a look at the Eldar Farseer. The Farseer is the commander unit of the Eldar, and she is mainly a spell-caster. The Farseer can be built already in the early game, and the player will almost always do that to counter the opponent’s commander (who also will be ridiculously strong). If you don’t believe me, play a game of Dawn of War with the Eldar faction vs a Space Marine opponent – without building a Farseer (or without using the Mind War spell) – and tell me how much fun it is.

The silly thing is that while the Farseer isn’t imbalanced, it would be easy to re-balance it to allow multiple Farseers (I’m ignoring Warhammer 40,000 canon problems now). Simply reduce her health and remove the most devastating of her spells, the Eldritch Storm. Multiple Farseers casting Psychic Storm (a weaker kind of spell) would obviously be fearsome, but the high cost of the unit (280 requisition and 80 power) and vulnerability to enemy fire would keep it maintainable.

In the current alpha build [note: this paragraph was written in August 2008] of Starcraft 2 the only remaining hero unit is the Zerg Queen. This is good news, because it means that both the Terran Thor and the Protoss Mothership have been re-balanced to allow the player to build several. Play-testers have reported that the Queen is fairly weak and can be killed by a small group of Terran Marines, so Blizzard seems reluctant to over-powering it. This also implies that the remaining reason why it’s unique is simply because it’s logical that a “queen” is the sole matriarch. Hopefully they will rename her, and allow the player to use strategies that involve building several.

I will begin with the topic of build orders and technology trees. In the next part I will discuss some imposed macro limits that are used in a lot of games.

Hit the jump for the stuff…

Build Options and Technology Trees

During a game each player will have a certain number of construction options, depending on the player’s current technology level. These levels are knows as “tech tiers”, and while they are different in different games and their factions, there’s always a level-one tech tier. This first tier determines the number of options the player has when the game begins, and this is interesting in two ways. First, it determines how easy it is for the player to choose his own strategy, and secondly it determines how easy it is to predict the opponent’s strategy. While the first point affects initial decision making and confusion to new players, the latter is very important when it comes to balancing the game to prevent the feeling of lottery.

For this reason it’s important to make the first tier as simple as possible. It should be reasonably possible for both players to find each other before they have more than one offensive unit type (but they may have several of that type), and that initial unit type should be predictable. If you allow several different kinds of unit types, these must either be very inefficient or similar in their behaviour. For example, in Supreme Commander you can immediately begin constructing flying units. These are, however, quite harmless and will not automatically win the game if the opponent expects ground forces. Another example is Dawn of War, in which the “Eldar” faction can choose between a number of different unit types early on, but they are quite similar (and initially quite inefficent too).

When the first tier has been settled it’s time to decide whether the technology tree should be linear or non-linear. Obviously you don’t want it to be completely linear, because that would not offer interesting options for non-standard units, but as with the first tier you don’t want it to be too wacky either. Following tiers should always be reasonably predictable, so the opponent is given a chance to prevent an easy win (see below for difference between “prevent” and “counter”). The question is, when somebody opts for one of the wacky choices, for how long should there be an advantage until the opponent has adjusted?

Another important thing to remember is to keep a balance between producing units and advancing to the next tech tier. If it’s too hard to advance, the game will always be settled with low-tier units (which was the problem with earlier versions of Dawn of War), and if it’s too easy it will flatten out the tiers and diminish the usefulness of the first tier limitation. These variables need play-testing, but a good starting point is that it should cost about 2-3 units of the current tier to advance to the next tier, but not much more than that.

Cost of Time

Anything that takes time without giving the player something in return is a cost and should be seen as a resource. For example, if a building only can construct one unit at a time (which is the norm), that structure is basically useless while the unit is being produced. Increasing the time it takes to produce units will make them more costly, even if the normal resource cost is the same.

Time is also a way of controlling the players’ “strategical agility.” The longer time it takes to do something, the less flexible strategies become, and the more impact your choices have. Imagine a game of rock-paper-scissors. You choose your hands, you reveal your choices, and one is deemed winner. The time from revealing your hands to determining the winner is the span of the game, and since it’s instantenous it is also infinite at a conceptual level. Imagine an RTS where you choose between three strategies and the time it takes to change your choice is infinite, then the strategy becomes a mind game which is settled even before you begin to play. Situations like these are called “rock-paper-scissor build orders,” and should be avoided if possible.

Counter vs Preventer

Sometimes you have strategies which involve a unit or upgrade which forces the opponent to get some kind of special technology to beat. A simple example would be cloaking and detection, where a cloaked unit would force the opponent to get detection in order to destroy. When your technology tree contains units like these, you should place them in such manner that they are not in the “linear path” of upgrades, so they create an alternative strategy and not the standard one. Likewise, the technology which counters this unit should also be on a alternative path, so the opponent would sometimes choose to skip it if he doesn’t expect the special unit to be used.

There are, however, two different types of counters, and your game should preferably offer both. The first one, which I will simply call “counter,” is the kind of technology which completely destroys the opponent’s attempt to defeat you with a certain unit. The other one, which I call “preventer,” stops the special unit from being effective, and leads the game to a stand-off rather than a win or lose situation. You could say that a “counter” is the sword, and the “preventer” is the shield.

Static defenses are good examples of preventers. They are usually quite powerful and also have abilities such as detection, which makes it difficult for the opponent to attack you until he has got something which counters these defenses. However, preventers do not offer the player a way of winning like counters do. If you are attacking your opponent with a strategy which counters the units that he has, then you are winning.

These concepts can also be extended to normal unit behaviour, and not just special abilities. I will discuss this more when I get in on the unit balance topics, but the point is that you should offer the player the choice of both the “sword” and the “shield,” and the shield should be cheaper and/or more accessible than the sword.

Rushing

“Rushing” is when one of the players sacrifices economy and technology to gain an early upper hand (or win the game quickly). You can design how useful rushing is by changing how effective the player’s starting bases are at defending themselves. Remember, however, that if you give weapons to workers, these may be used by the rushing player too. This also applies to starting units.

You should include at least some kind of defense early on. If the rushing player manages to get two attacking units in your base before you have your first, they will be able to destroy your unit when it appears, and then wear you down by continously sending reinforcements.

Resource Systems

Much of today’s resource systems can be tracked back to the games of the 90s. The basics of a resource system are resource collection and production. In Dune 2 (Westwood Studios, 1992) you have a single resource called melange (or simply “spice”), which is gathered from sand dunes and sold at refineries for credits. Credits are then used to buy both units and structures. Collecting spice is performed by slow-moving “harvesters.” The amount of credits you can have at the same time is limited, but can be increased by adding spice silos to your base. Dune 2’s resource system is also used in Westwood’s following game, Command & Conquer: Tiberian Dawn. The spice is replaced by tiberium, but the concept is the same.

Since then games have tried different number of resource types, different rate of expenses, and various forms of gathering them. Some of these variations will be covered here.

Continuous vs Discrete

One thing that is important is that the expense of resources in Dune 2 and Command & Conquer is that it’s continuous. What that means is that when buying structures or units, the credits count is continuously decreased until the purchase is completed. This has the effect that you can begin constructing something even though you don’t have enough credits, but it’s possible that you will have to wait for the next harvester to return before you get what you bought. In theory, especially in Command & Conquer 3: Tiberium Wars (EA Los Angeles, 2007) with its multiple build queues and upgrade options, you may end up buying several items of which none will be completed. It’s the player’s job to predict how much income that is arriving, and prioritize by holding or canceling production.

Total Annihilation (Cavedog Entertainment, 1997) and Supreme Commander (Gas Powered Games, 2007) use a full continuous resource system. Resources gathering is measured in “per second”, and so is resource expenses. If you have more income than expenses, the excess will be added to your stash, which is limited. The limit can be increased by adding silos and batteries, but generally it’s optimal to keep your resource stash close to zero at all time, and with a slightly negative income/expense ratio.

Blizzard Entertainment has used a discrete resource system in all their games. A discrete system is a system where resources are removed instantly, and it’s not possible to buy something that you can’t afford. This system is used in a lot of other games as well, such as Age of Empires (Ensemble Studios, 1997) and the spin-off series Empire Earth (Stainless Steel Studios, 2001).

The big difference between continuous and discrete systems is the implicit cost of time. With a continous system the player is allowed to save time by constructing something he can’t afford yet. For example, if the resources for a certain unit is gathered at twice the rate of the unit’s production time (and the player has two factories), the difference is the following:

1. The player wants to buy 2 units. In the continous system the player begins construction of both units. In the discrete system the player is only able to begin construction of one of them.
2. The player receives resources for the second unit. In the continous system, both units are at 50%, in the discrete system the player may begin construction of the second unit.
3. Full construction time. In the continous system the player receives both units. In the discrete system the player receives the first unit, while the other is still at 50%.

In the long run both systems will yield the same amount of units, since they are both restricted by the rate of income. However, it does affect the player’s decision making. In a continuous system, if you need something you should begin constructing it immediately to save time. In discrete systems you are forced to prioritize more, and is also more intuitive since it’s how you pay for things in real life. Discrete systems also give the player direct feedback on the economy; the player will receive the “you need more resources” error message when he tries to build something, instead of receiving it a couple of moments later. C&C 3 helps the player by displaying a purchase’s cost with red digits if it’s higher than the current stash of credits.

Active vs Passive

As already mentioned, in Dune 2 and C&C resource collection is handled by harvesters that move between resource fields and refineries. This is “active resource collection,” because a game entity is involved in the process. This entity can be micro’ed by the player if necessary, but generally it takes care of itself as long as there are resources remaining to collect. Warcraft, Starcraft and Age of Empires are other examples of games that use active resource collection.

In passive resource collection, resources are added through other means than entities picking them up. Passive income is also usually infinite or near-infinite and will continue until the opponent destroys it. Passive income is used in Total Annihilation, Dawn of War (Relic Entertainment, 2004) and in some extent Command & Conquer 3 (tiberium spikes) and Warcraft 3 (Night Elves collecting wood, Blizzard Entertainment, 2002).

In both systems the player will have to practice to understand how quickly resources are gathered, how many harvesters that are needed or how many passive resource points that is required for a certain technology build. Since passive income usually is connected to positions on the map, such resource systems will put more pressure on the players to be offensive and multi-tasking, forcing them to attempt to gain control of locations that may be difficult to defend. Most people will find RTS games with passive income to be “hectic” on a macromanagement level, because you need to get as many passive positions as possible, and when there are no more spaces you need to take your opponent’s positions instead. The game will consist of several small battles until either player gets the upper hand and can make a move on the main base.

Active income is more focusing on defending a handful of locations. As long as there are resources remaining to collect the player is allowed to sit tight and make plans for the next move. Active income is also limited by the number of harvesters, and not by the number of resource locations available, which gives the player a more comfortable situation of choosing their own economy. Obviously there is a need for expanding to new locations and preventing your opponent from doing the same. However, this is a decision that the player makes, and is not forced upon him by the way the resource system is made.

Resource Types

Most RTS games have several resource types. For example, Starcraft has minerals and vespene gas, and Age of Empires has four (food, wood, rock and gold). Resource types are used to balance units in the game, and offer the players methods of choosing different strategies. Resource types can be available in different amounts (vespene gas is collected slower than minerals), have relations to each other (wood creates food in late-game Age of Empires) or be gathered differently (requisition and power in Dawn of War).

The difference between having one and having several resource types is not how you gather them, but the option not to gather. Games that don’t utilize this option are less enjoyable and force players to do more “work”. To get a good example of this, check the Analyzing Supreme Commander section below. Not gathering allows players to focus on certain strategies and hopefully get an advantage over an opponent who wants it all. For instance, the stone resource in Age of Empires is mainly used for defensive structures. If you aren’t interested in defense, you can use those workers on gathering more gold instead (which allows for more technology and offensive units).

While adding more resource types to a game adds strategy options, it also adds confusion. Empire Earth 2 has ten resource types! Food, wood, stone, gold, tin, iron, salpeter, oil, uranium and technology points. Luckily, not all of these resources are available at the same time, but it’s still way too many. Mad Doc Software added these for historical accuracy, but it neither adds strategy nor entertainment.

There are no games that I know of which only has one resource and a discrete payment system, so it’s hard to analyze how that would play. Command & Conquer has a single resource type, but since the payment system is continous it wouldn’t make much of a difference if there were two. You would still buy what you wanted, rather than what you could afford.

Other Resource Systems

It’s not easy to invent fresh resource systems on-the-fly, but there is obviously room for other ideas than those used so far. In many cases, resources are about gathering something so that a number in the user interface is increased (the stash). It’s easier to invent new ways of gathering than new ways of increasing the number.

One way to make it more different is to avoid using a stash value. One example of this is our game Harvest: Massive Encounter (Oxeye Game Studio, 2008), where one of the resources is energy flying around in a network of energy links. The energy is a part of the game rather than a part of the user interface, and the player will have to make sure that the energy is at the right place and not just that there is enough of it. However, as you know, Harvest: Massive Encounter is a different kind of RTS than the other games in this article, but it’s a good example of how resource systems can be made differently.

Hit the jump for a couple of initial terminologies…

Strategy and Tactics

I should begin by defining what I mean with “strategy” in the context of real-time strategy games. Strategy is the players’ “global” decision making and planning. Strategy answers the questions of “what” and “when”, but not “how”. For example, quickly getting 10 flying units to make a surprise attack on an opponent is a strategy. How these are controlled and which targets they choose are tactics. In games like in the Total War series (Creative Assembly, 2000) the strategy is which units you select and where you place them before the battle begins.

Strategy is sometimes called the “meta game,” because when the players’ tactics improve new strategies will have to be developed and old ones adjusted. If this is not possible, the players would have found an end-game strategy which always wins, and your game may become boring (though it doesn’t need to, as I’ll discuss in later posts).

Macro- and Micromanagement

Two other common terms are macro- and micromanagement. Though these relate to strategy and tactics, they are meant in a more “mechanical” sense and relate to your ability to play the game rather than your ability to figure out things to do. Macromanagement is how well you are able to convert resources into an advantage over your opponent. If you are able to keep a high stream of income without hoarding, then you have good macromanagement. Macromanagement is also how well you are able to perform your strategy. For example, if your strategy depends on a certain technology, your macro skill determines how quickly you will achieve that technology.

Micromanagement is about making the most of each unit that you have. In practically all RTS games units act at full capacity as long as they are alive, regardless of how much damage they have taken. That makes it important to keep units alive for as long as possible, while making sure you get “that final hit” on your opponent’s units. This is the basics of micromanagement, but it’s also about using special abilities and helping out where the artificial intelligence fails (such as with path-finding).

Gosu macro by Savior

Early-, Mid- and Late-game

A usual RTS game progresses through a number of “phases” called early-, mid- and late-game. While the mid-game phase depends on what game we are talking about, the early- and late-game phases are easier to define.

The early-game phase is about build-orders, scouting and deciding on whether to aim for economy or a quick “rush” game. During early-game the players’ units are usually quite bad at destroying buildings, but a quick attack can gain either one an economic advantage or maybe map control. The early-game phase ends when neither player is able to do any useful damage with the initial units, and is forced to attain higher technology units to advance.

The late-game phase begins when either player has reached the highest technology possible and with a base big enough to support streaming macro. During late-game the players’ strategies have already been played out, so it’s a game of keeping unit count up (macro) while using good tactics (micro) to wear your opponent down.

In this series of blog posts I will take a look at unit movement, construction, resources, macro-game rules and similar topics. Though I will mainly inspect these objectively, I will apply my own opinions on the different subjects. One thing to remember, though, is that there’s rarely a “right” or “wrong” when it comes to game design. The question is rather, what game are you trying to create,  and for whom?

My original plan was to begin with some background history, but the article at Wikipedia already does that flawlessly. For mortals it’s only necessary to recall that Dune 2 (Westwood Studios, 1992) defined the RTS genre, and for geeks it can be interesting to know that there were games with RTS-like elements earlier than that. Dune 2 was however the first RTS game I ever played, and it has strongly influenced my taste in games.

I will post the first parts in the following days. Since you are reading this, it means that I’ve created at least 3 drafts already, because that’s my criteria for beginning this series.

/ jeb