In this post and the next one I’m going to tackle the topic of macromanagement. As I’ve said before, macromanagement (or “macro” for short) is closely related to strategy, so when designing the macro part of a game you will strongly influence the strategies which will be available to the players.

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.