Core Mechanics

The core mechanics in strategy games consist chiefly of tactical maneuvering mechanics and internal economics. The combat models occasionally use physics for projectiles. The nature of the experience tends to be emergent—that is, the events of the game arise from these mechanics and the player’s choices—so progression mechanics are rare.

Strategy games with simple rules, such as chess, don’t have an internal economy because they don’t deal in numeric quantities; either a piece is on the board or it isn’t. In war games, the internal economy centers on the production and consumption of resources such as units and factories and can be very complex indeed.

Designing Units

The units in war games almost always fall into types, such that all units of each type share a set of attributes, but some units or types of units will also have special capabilities that are unique to them and give them a special role. In this section, we’ll examine some design considerations for creating units.

The Rock-Paper-Scissors (RPS) Model

The Ancient Art of War, an early RTS game, ran on a 4.77 MHz IBM PC. The machine did not have enough CPU power to cope with a complex model of real-time combat, so the game used only three types of fighting units and a simple rock-paper-scissors (RPS) rule to resolve conflict among them. The unit types were knights, archers, and barbarians. (Spies, the fourth type of unit offered, could not fight.) Knights had an advantage over barbarians; barbarians had an advantage over archers; and archers had an advantage over knights. The player’s challenge, as in rock-paper-scissors, was to try to anticipate which units his opponent would use and deploy the ones most likely to beat them. Units could be deployed in mixed groups, and the player could choose different formations for them to fight in, which made the game more interesting.

While RPS-style models are easy to implement and naturally balanced, they are suited only to simple games, and you shouldn’t use these for a modern war game with large numbers of unit types. You can’t balance a complex game by simply declaring that some units are vulnerable to others; there are too many pairwise matchups to consider. These models also don’t take into account battlefield conditions. What if the knights sneak up on the archers from behind and engage them in close combat?

Instead, create numerical attributes that describe the combat strengths and weaknesses of unit types independently of whom they may fight. The relative combat effectiveness of different unit types against each other will then emerge from these attributes. This system, described in the next two sections, permits many more types of units and more interesting relationships among them.

Combat Attributes

Modern war games assign combat attributes to each type of unit. Each unit of a given type begins with the values that its type requires, but these values change as the unit sustains damage, consumes ammunition, and so on. The system is similar to that used to describe characters in role-playing games (RPGs). However, RPGs tend to be about small numbers of quite diverse individuals, while strategy games tend to be about large numbers of fairly similar units. Consequently, RPGs use more attributes than strategy games do.

The combat attributes most commonly used in a war game include the following:

• Health is measured in health points (HP). These are reduced as a unit takes damage. When a unit’s number of health points reaches zero, the unit is considered destroyed and therefore disappears from the game. An atomic unit does not have any pieces or parts that take damage individually, so it has only one health attribute and all damage is done to it as a whole. Compound units may have separate health attributes for each of the different pieces that make them up. (A cavalry unit, for example, might have one health attribute for the rider and another for the horse.) The maximum amount of health that a given type of unit may have is its maximum health. More robust units have a higher maximum health. Some units may also have armor, also measured in health points, which can absorb a certain amount of damage and protect the unit’s health. Armor, too, will have a maximum armor value that varies with the unit. You can either let the armor absorb all damage until the armor is destroyed (in which case it’s really just like extra health) or, more realistically, you can have the armor let more and more damage get through to harm the unit as the armor degrades.

• Units may have zero or more weapons with which to attack enemy units. (Typically transport units have no weapons; typically tanks have three or four, though many games limit the number of weapons per unit to one, to make the game simpler.) Each weapon has attributes that describe its characteristics. When a weapon hits an enemy unit, it reduces that unit’s health or armor by a certain number of health points. A weapon inflicts damage in individual instances called shots; the amount of damage it does per shot is its shot power, expressed in HP per shot. There must be a minimum period of time between shots; the number of shots per minute is the weapon’s rate of fire. (This terminology comes from firearms, but the same attributes also apply to swinging a sword; some swords do more damage than others, and some can be wielded more quickly than others.) If the game models ammunition consumption for a certain weapon, then that weapon also has a certain amount of ammo; each shot consumes one round, and the weapon ceases to operate when the number reaches zero.

• Range is the maximum distance at which a weapon can deliver damage. Some units have only hand-to-hand combat weapons and can attack only adjacent units, so the range of their weapons is small. A few long-range weapons, such as longbows, are useless in hand-to-hand combat, and so may also need a minimum range rating below which they are not functional. Fixed units such as gun emplacements cannot always point in all directions; if that is the case, you’ll need to define a traverse arc for the unit, two numbers that indicate the starting and ending bearings. All the bearings between these two constitute an arc through which the weapon may be traversed. A traverse arc of 0 to 90 degrees means the unit can fire in any direction between due north and due east.

• Small projectiles such as bullets and arrows should hit only one enemy unit each, but if your game includes large, solid projectiles like cannonballs, you’ll have to define the shot mass and shot velocity of each. Their kinetic energy is great enough to let them completely destroy small units and continue onward. The amount of damage they can do is reduced in proportion to the mass of the units that they have already hit, until they finally stop. Explosive projectiles, on the other hand, require a blast radius, a measure of the distance from their landing point to the farthest point that the explosion can affect; any unit takes damage if it is within the blast radius. In principle, the amount of damage done to enemy units within the blast radius should be reduced by the inverse square law—that is, the shot power of the projectile is reduced in proportion to the square of the target unit’s distance from the center of the blast; however, you may not wish to compute to that level of detail.

• Accuracy is a measure of the chance that a given weapon will hit the point at which it is aimed, expressed as a real number between 0 (never hits) and 1 (always hits). Note that this is accuracy of aiming at a point, not hitting a unit; if a projectile is slow, the unit may not be there when the projectile arrives, even if the weapon is highly accurate. Theoretical accuracy is the average accuracy of a weapon under all conditions, but you may also add to or subtract from the theoretical accuracy to compute the practical accuracy based on the prevailing conditions when the weapon is used, such as the distance to the target, whether it’s daytime or nighttime, and so on.

• Defensive dodging is a unit’s ability to successfully dodge an enemy shot; you may want to restrict its meaning to dodging solid projectiles such as bullets, not blast effects. Like accuracy, it should be expressed as a real number between 0 (never dodges) and 1 (always dodges). If your physics model is complex enough to include the velocity of shots, then defensive dodging should be less effective against faster-moving shots.

• If your game includes the fog of war, you’ll need to include a number that describes a unit’s range of vision; scouting units might have a larger number for this than other units. This value will naturally be modified by the altitude of the land relative to the region around it.

Note that accuracy and defensive dodging introduce an element of chance into the game. To determine if a weapon hits or misses the point it is aimed at, the software must choose a random number between 0 and 1; if the random number chosen is below the weapon’s accuracy rating, it shoots accurately; if the random number is above it, it misses. Obviously if the weapon’s accuracy rating is 1, it is completely accurate. You then have to determine whether a unit being shot at dodges the shot successfully (even if it is an accurate shot) by choosing another random number and comparing it to the target’s defensive dodging ability.

Naturally, the preceding is not an exhaustive list of attributes, but it covers the basics. If we apply this list to The Ancient Art of War mentioned earlier, the knights and barbarians have only close-combat weapons while archers have only a long-range weapon; barbarians have high defensive dodging (making them less vulnerable to archers), whereas knights have low defensive dodging (making them more vulnerable to archers); and knights have more armor and more shot power than barbarians, making them superior to barbarians in hand-to-hand combat. In other words, numeric attributes can duplicate the artificial RPS relationships of The Ancient Art of War, and they can create much more complex and subtle relationships as well.

Maneuver Attributes

The purpose of tactical maneuvering in a war game is to project force, control territory, or obtain a combat advantage (see Fundamentals of Game Design, Third Edition [New Riders, 2014] for a deeper discussion on tactical maneuvering). Here we’ll look at a few maneuver attributes that can affect combat:

• Units that move have a speed at which they are currently moving and a maximum speed that represents the fastest they can move over unrestricted terrain such as a road. Their actual speed at a given time degrades because of the difficulty of the terrain through which they are passing (a terrain attribute); difficulty is expressed as a real number between 0 (prohibits passage entirely) and 1 (allows maximum speed, like a road). Speed should also degrade by moving uphill; the altitude of each point in the landscape is another terrain attribute, and the relative altitudes of two adjacent regions give the steepness of the slope between them. Slopes above a certain steepness should be impassable to ordinary ground units.

• A unit’s size naturally determines how much space it takes up on the battlefield, and how much of a target it presents to an enemy. Its size also influences (but is not the only factor) how densely the units may be packed, which can have a large effect on battle. For example, Roman soldiers were a similar size to their opponents, but the Romans’ use of short swords and closely packed ranks meant that their opponents could not use longer swords against them; the opponents had no room to swing. On the other hand, with modern explosive weapons, force dispersal is essential to avoid mass casualties. Vehicles also need more room between them than people do, because they require more space in which to turn.

• The turn rate describes the rate at which a unit can turn to face a new direction; this applies both to moving and fixed units. The turn rate should not be so quick that the turn is instantaneous, or flanking maneuvers won’t work.

• If you are making a highly realistic strategy game about vehicles such as tanks, you might also want to include the unit’s mass, acceleration, and so on, but most strategy games don’t bother. Without taking mass and acceleration into account, units don’t speed up and slow down—they simply start to move at the maximum rate they can over the terrain, and they stop as soon as they receive a stop command.

Special Capabilities

Many units in strategy games have special capabilities that strongly affect the tactics and strategy of play. Some special capabilities influence the attributes of a unit; others simply allow the unit to do things that other units cannot. Here is a short list of possibilities:

• Stealth. A stealth unit can become invisible to enemy units. This capacity is extremely valuable because it enables the unit to sneak past guards posted by the enemy and attack a vulnerable point. Traditionally designers require stealth units to reveal themselves when they use their weapons. Units able to attack while remaining invisible would be too powerful. Some designers reserve stealth capability for unarmed units, which serve as scouts.

• Flying or sailing, that is, traversing terrain inaccessible to ordinary land-based units. Aircraft and ships tend to be specialized and incapable of operating in any other medium, but there is no reason you cannot create amphibious craft if you want to.

• Repair. You can design units to repair themselves; you can also devise special units that repair others—essentially, medical units. This valuable feature rewards players who keep a sharp eye on the health of their units and set up systems to repair them efficiently. The repair feature is especially beneficial if new units cost resources to manufacture, but repairs cost nothing—or, at least, less than building a new unit.

• Transport. Transport units allow the rapid conveyance of a certain number of other units around the landscape. Destroying a transport unit destroys the units it carries as well. Because rapid transport is a valuable feature, designers often make transport units unarmed, to offset this strength by increasing the transport units’ vulnerability. This requires the player to assign armed units to go with them in a convoy, which lends realism to the game.

• Constructing buildings and producing mobile units. As the earlier section “Strategic Conflict” describes, most modern war games use a construction unit to build and repair factories, and the factory constructs other mobile units, often of a specific type.

• Leadership. Some games, especially those that represent ancient warfare, include special leader units that give a fighting bonus to other units near them or under their command. This bonus is lost if the leader is killed, thus simulating the loss of morale and organization that occurs in those circumstances.

For every special capability you create for one side in a battle, you must also create a capability of similar military value for the other side or a means of defeating the special capability. If you give one side stealth units, you should either give the other side something equally useful or give them special units that can detect stealth units. The special capabilities of either side need not be symmetric—Carthaginians use war elephants and Romans use catapults—but there must be a balance between them. Otherwise one side will exploit its advantage ruthlessly and the game will be no fun.

Computing the Relative Value of Units

If your game allows the player to purchase or construct new units, you’ll have to decide on the relative cost of each type of unit, either in terms of the amount of time that the player will have to wait for it, the resources required to purchase it, or both. A unit’s cost should be a function of its military value. Of course, the value of a unit depends a lot on the conditions in which it fights; snowmobiles are useless in the desert, and infantry can’t do much against jet aircraft. However, you’ll still need some kind of baseline for determining how much a unit is worth in absolute terms, regardless of circumstances or what it’s up against, so that each side will pay roughly the same amount for the same amount of military effectiveness.

Following are two equations that serve as a first approximation of the military effectiveness, and therefore the value, of a unit type. The first is for units designed primarily for attack:

Attack unit value = maximum health × shot power × rate of fire × theoretical accuracy × range × maximum speed

Very roughly, this equation reflects a unit’s ability to accurately deliver damage from a distance, while surviving under fire itself. So, in comparing two types of attack units, if all the factors are equal except for maximum health, the one with the greater health survives longer under fire and therefore does more damage to the enemy before it is destroyed. Likewise, if two units are identical except for their rate of fire, the one that fires faster does more damage before it is destroyed. Speed is included because it is a measure of a unit’s ability to get out of the range of another enemy’s weapons. Any unit that is faster than an enemy can get in and out of harm’s way quickly, allowing hit-and-run operations.

Defensive units such as fixed gun emplacements use a slightly different equation:

Speed is left out because such units don’t move much and don’t generally need to; they’re supposed to protect the place where they are. The range is squared because a longer range means more than being able to shoot farther away; it means being able to deliver fire on an area of terrain, and the area is proportional to the square of the range. It is divided by two because most of the time, the enemy is in front of the unit, not behind it; being able to cover the area behind the unit is less valuable.

Warning: These equations produce completely different ranges of values and cannot be used to compare the value of attacking units with defensive units. They’re intended to compare only attacking units to other attacking units and defensive units to other defensive units. The equations are only a rough approximation, and you’ll almost certainly want to attach weights to the various factors they include. The equations also don’t take into account special capabilities such as stealth or leadership. A unit with a special capability should cost more than a unit that is otherwise identical but lacks that capability, but there is no rule of thumb for determining just how much more it should cost. Only play-testing and tuning can produce a balanced set of units for all sides in the war. (For more on setting attributes for units, please refer to Fundamentals of Game Design, Third Edition [New Riders, 2014].)

Production Rates, Unit Numbers, and Lanchester’s Laws

Frederick William Lanchester founded the field of operations research, which studies subjects such as logistics and production efficiency. In the course of his work, he devised two laws regarding the relative strengths of enemy forces. One, Lanchester’s Linear Law, states that in hand-to-hand combat the relative strengths of two armies are proportional to their numbers of troops. Since one fighter can engage only one other fighter at a time, the force relationship is simple.

His other law, Lanchester’s Square Law, refers to the relative strengths of forces made up of units that can aim and shoot at one another from a distance and can concentrate their fire. In this case, the strength differential is not proportional to the sizes of the forces but to the square of their sizes. Imagine two forces, Red and Blue, both made up of identical units. Blue has three times as many units as Red has. It seems as if Blue is three times as strong as Red. But in fact, it’s nine times as strong. Here’s why: Three Blue units are concentrating their firepower on each Red unit. But Red’s firepower is also diluted over a force three times as big. Each Red unit is firing at only one Blue unit, and two other Blue units aren’t being fired upon at all! The combined effect is that Blue is nine times as strong.

What this means in practice is that masses of concentrated firepower are not only effective, they’re very, very effective. For strategy games, this means that if you give one side twice as many units as the other, you’re actually giving it four times the advantage. You’re unlikely to do this intentionally, but it might happen by accident if you don’t set the production rates of units carefully. If one side can produce units faster than the other, its advantage is not the difference between the numbers of units but the square of the difference—assuming that we’re talking about units with ranged weapons. Hand-to-hand units still follow Lanchester’s Linear Law.

This also means that you can’t balance the effect of one side’s having twice as many units by giving the other side a twofold advantage in one of its units’ attributes. Even if you double the smaller side’s shot power, those shots are still being diluted over a larger force. You have to give the smaller side a fourfold advantage in shot power to compensate for the larger side’s squared numerical advantage.

Lanchester’s laws describe battle in abstract terms. They don’t take into account battlefield conditions, maneuvering, reinforcements, and so on. Nevertheless, they serve as a valuable warning to game designers trying to balance strategy games: Numbers and production rates make a huge difference. It’s critically important to balance your production economy well, or whichever player can turn out units faster—even if those units are relatively weak—can overwhelm the other by sheer numbers.

For a more thorough discussion of Lanchester’s laws, see the “Designer’s Notebook” column “Kicking Butt by the Numbers” in the Gamasutra webzine (Adams, 2004).

Health, Morale, and Fighting Efficiency

As with almost all other genres, units in war games fight at full efficiency until their health points are gone, even though that’s obviously unrealistic. Making wounded or damaged units fight at reduced efficiency introduces too powerful an effect of positive feedback in favor of the dominant side. Once a unit’s efficiency begins to suffer, it’s more likely to take further damage and so lose yet more efficiency, resulting in a quick demise. Reducing the fighting efficiency of damaged units also produces situations in which each side has harmed the other to the point that neither is able to fight effectively. The result is a long stalemate or a boring war of attrition, so in general, you should avoid this approach.

The same is true of most mechanisms that try to implement the effects of morale. In such systems, morale is represented by a number that either increases or decreases an army’s fighting effectiveness. If the number is positive, morale is high and the effectiveness goes up, perhaps by improving the weapons accuracy of all the units in the army. If the number is negative, morale is low and effectiveness is harmed. Morale goes up when the army is doing well (that is, losing fewer units relative to the enemy) and down if it is doing badly (losing a lot of units).

Again, this tight loop produces too much positive feedback. If one side starts to lose units, morale is lowered and fighting effectiveness goes down, so that side keeps on losing. Furthermore, the enemy’s morale has gone up at the same time, making the problem even worse. It’s better to avoid morale altogether or to give it only a small role in determining fighting effectiveness. The leadership bonus, mentioned in the earlier section “Special Capabilities,” is a better way to handle this; the value of the bonus is not based on how well the army is doing but on whether the leader is present, so there is no feedback loop.

In conflicts among small numbers of compound units, such as main battle tanks or capital ships, you may want to allow individual weapons or other systems aboard the unit to go out of commission as the unit takes damage. In a game about nineteenth-century naval warfare, for example, you can allow the guns aboard a 74-gun ship to be destroyed one by one, thus incrementally reducing the fighting capacity of the whole. The guns on a ship are analogous to the soldiers in an army, and like a soldier, each gun should fight at full strength until its hit points are gone.

Upgrades and Technology Trees

In a game with a limited number of unit types, sometimes the players can exhaust the interesting battle combinations too quickly. For example, the knights, archers, and barbarians of The Ancient Art of War aren’t enough to hold players’ attention over many campaigns. You can make a game more interesting by adding more unit types, but if all the unit types are available at the beginning of a game, the player will undoubtedly concentrate on the most powerful ones and ignore the weaker ones.

To resolve this problem, you should look for a way to introduce new units or to upgrade the existing ones as the game progresses. These upgrades can improve the values of units’ attributes or give the units entirely new capabilities. An upgrade might occur as a reward for some achievement. In checkers, for example, moving a piece to the opposite side of the board turns that piece from an ordinary unit that can only move forward into a king that can move both forward and backward. Because it takes a while to reach the opposite side of the board, kings don’t appear until well into the game. Tower defense games, by contrast, permit upgrades very early in the game because the enemy waves get larger early.

Researching Upgrades

Checkers is an abstract game with an arbitrary rule for upgrading units. In more representational games, the unit upgrade process is often characterized as a form of research that the player must initiate; it takes a certain amount of time and perhaps the expenditure of some resources. If your game offers several different upgrades, you may wish to organize them into a sequence, such that some upgrades become available only after others have been achieved. You may also offer the player a choice of upgrades to research at any given time, which gives her an interesting decision to make: Which is the most advantageous upgrade to choose given the units she has available and her preferred style of play? (A player who prefers a defensive style, for example, may wish to choose upgrades that enhance the defensive rather than the offensive capabilities of her units.)

Single-Unit, Unit Type, and Global Upgrades

You may create a number of different types of upgrades: those that apply to a single unit (such as the conversion of a piece to a king, as in checkers); those that modify the capabilities of all units of a given type (such as the siege tank upgrade in StarCraft, which gives all tanks the ability to operate in siege-tank mode once the upgrade has been researched); and those that modify the core mechanics globally (such as the Hoover Dam invention in Civilization, which improves its entire society’s productivity and reduces pollution). In RPGs, skill upgrades naturally apply only to the individual character that has learned the skill, but in strategy games it is more common to apply a unit type upgrade to all the player’s units of that type simultaneously. That makes the process of retrofitting the existing units unnecessary, so the player doesn’t have to think about it. If you’re making a highly representational war game, however, you may want to require the existing units to come back to headquarters to fit them with their new gun, engine, radio, or whatever other feature it is that the player has researched.

Permanent and Temporary Upgrades

In turn-based games with long, complex campaigns (such as Civilization or X-COM), designers often spread out the upgrades over time, spanning several levels. Each time an upgrade is achieved, it lasts for the rest of the game. These permanent upgrades strongly support the player’s sense of progression through an extended game. Typically they occur only infrequently and represent a major achievement when accomplished. Permanent upgrades are ideal for game-time periods that span months or years.

In RTS games, however, you may want to have the research and upgrade process work fast enough to produce big changes in the gameplay within a single level but not fast enough to carry over to the next level. These are called temporary upgrades. This puts more pressure on the player, who has to decide quickly whether to expend resources on research or on building new units to help fight a battle taking place in real time. Dungeon Keeper is a good example of this kind of game: In each level, the player’s creatures research a set of magic spells while still defending their dungeon against invaders. With temporary upgrades, the player loses the benefit of his research when he goes on to the next level; he has to research the technology over again. This seems a bit peculiar, but it works well if you don’t think of the levels as part of a continuing story. It’s more credible if you present each level as an independent scenario, unrelated to the others—as Dungeon Keeper in fact does.

Technology Trees

If your game has a large number of upgrades, you should organize them into a branching tree structure, in which achieving one upgrade makes available a choice of several others that are logically related to the preceding one. See Figure 3 for an example. Achieving the steam engine, for instance, could give the player the opportunity to research the railroad, steamships, or powered factories. Strategy games usually characterize these advancements as technological research, so such a structure is called a tech tree even though some of the upgrades may not actually be technological. In RPGs, a similar mechanism applies to upgrading a character’s individual skills; in that context it is called a skill tree, but the function is the same: It is a diagram of the available upgrade paths for a unit.

Once the player chooses to research an upgrade on a particular branch, you can force her to complete all the upgrades that are part of that branch before moving to another branch or prevent her from ever researching upgrades on another branch. So, for example, choosing to research agriculture might force the player to stick with agricultural advancements, and other upgrades such as fishing or animal husbandry would be closed to her—either until the agricultural branch has been completed or perhaps forever. This restriction encourages asymmetric play; if one player chooses agriculture and another chooses fishing, each is committed to the approach she has chosen. However, it will make your game tricky to balance and will discourage some players. Many players, including many women, dislike being forced to make irrevocable decisions whose consequences they do not know.

To design a tech tree, first think of all the upgrades that you would like to introduce in the course of the game. For each upgrade, note whether it applies to a particular unit, all units of a particular type, all units in the player’s forces, or the core mechanics generally. Also note what event will trigger the upgrade—the passage of a certain amount of time, the expenditure of resources, or some other achievement such as defeating a particular enemy unit or arriving at a certain place on the map. Once you have an idea of what upgrades you want to include, you can organize them into a logical sequence or tree; a simple diagram will show which upgrades lead to which others.

As a general rule, upgrades should strengthen the player’s side and give the player new choices to make. Researching horse breeding, for example, might make cavalry units available for the first time and thus require the player to start thinking about how to use them. Don’t worry too much about correctly setting the exact cost and length of time required by each upgrade. Pick some numbers that feel right; undoubtedly you’ll modify them during testing.

Logistics

Strategy decides where to act; logistics brings the troops to this point.

—General Antoine-Henri Jomini

Logistics is the management of supply: the production, distribution, maintenance, and replacement of personnel and materials. In real life, it’s an immensely complicated business. War games, on the other hand, tend to have simplified logistics. This is because real armies have huge general staffs to look after such things; in a war game, the player has to handle it all herself. Because the player is also busy with strategy and tactics, you should simplify the logistics. The next few sections discuss different aspects of logistics and how to handle them.

Supplies and Consumable Items

For the most part, computer war games ignore the soldiers’ human needs. Soldiers don’t eat and don’t sleep, so the game doesn’t track supplies such as food or sleeping bags. Similarly, vehicles don’t require fuel or spare parts. Keeping track of these supplies is simply too much of a nuisance. The one major exception to this rule is ammunition; some games track it and some don’t. In general, if ammunition is cheap, doesn’t do much damage, and is quickly expended (such as arrows or bullets), you should give units an unlimited supply because it’s not fun for the player to have to look after it all the time. If ammunition is particularly destructive, such as nuclear weapons, then you should make it rare and expensive and keep track of how much is around. To summarize it simply, “Don’t sweat the small stuff.”

Supply Lines

A supply line is the route over which fresh troops and war materiel must be transported from their source to where they are needed, usually the battlefield. Cutting the enemy’s supply line is a classic stratagem of war; it leaves the enemy troops without support and often they have to surrender when they run out of the things they need. Seizing bridges is a high priority in land warfare because a bridge is often a choke point through which troops and supplies must pass. Most computer war games model supply lines correctly for the troops themselves; fighting units do have to get from wherever they are produced (usually near their headquarters) to where the action is. Few games implement supply lines for items such as food and ammunition, however, for two reasons. First, supplying materiel is an additional task that players may not have the time (or inclination) to manage. Second, implementing supply lines realistically means creating transport units and modeling the supplies as individual objects. All this makes for a more complicated game engine and requires additional CPU time to execute.

Abstracting the Distribution Process

To reduce these problems—yet still require the players to create the resources that units need—you can make the production process concrete, but abstract the distribution process. For example, the troops in Warcraft eat food. The food is produced on farms (which may be destroyed by the enemy, thereby reducing production), but once the food is produced, it is magically available to all the player’s troops everywhere. The existence of the troops causes the food to disappear from storage, but the food doesn’t actually have to be transported to where the troops can eat it.

This decentralization of resources can permit unrealistic strategies if you do not handle it carefully. In Age of Empires, for instance, a player can send a lone peasant into a remote area to build a barracks, which has the function of creating troops. Assuming that the barracks is not spotted by the enemy, it immediately starts producing troops right on the enemy doorstep with no regard for supply lines or resource distribution. Although this is an imaginative way to exploit the decentralized-resources mechanic, it harms the players’ suspension of disbelief because it’s so unrealistic.

In his regular design column for the U.K.-based Develop magazine, Dave Morris suggested another alternative that rewards a player for maintaining supply lines without actually requiring her to personally manage the transportation of materiel (Morris, 2001). Morris was the lead designer on Warrior Kings, and for that game he proposed a special unit called the supply wagon. Supply wagons carried food, and so long as troops were near a loaded supply wagon, they regained health points (which consumed the food). When the food in the wagon ran out, the supply wagon automatically trundled back to the nearest friendly palace (palaces acted as storehouses) for more food. Units whose supply wagon couldn’t get back to a source of supplies couldn’t regain health. This rewards the player for keeping supply lines open but does not actually require her to do so. (Unfortunately this idea was not implemented in the final version of the game for lack of time.)

Road-Building

Another way to abstract the distribution of supplies while still requiring the player to pay some attention to them is to let the player build roads. Consider the territory map in Figure 4.

Town B has access to a forest—it has a road (supply line) leading directly to the forest, providing a ready source of lumber. This allows Town B to build wood-based units, such as catapults. Town A is linked to Town B via a road, which provides a readily available supply route between Town A and Town B. Hence, Town A has exactly the same production capabilities as Town B: Anything that is available to Town A is also available to Town B, and vice versa. Town C is a newly built town. No roads have been built to Town C, so it does not have access to the resources of Towns A and B until a linking road is built.

This is the approach taken by Civilization III. Of course, it’s still not an entirely accurate solution—materials are assumed to travel instantaneously along the roads. (It’s interesting to note, though, that previous iterations of the Civilization series did implement trade caravans, but Civilization III removed that feature to improve gameplay.)

Influence Maps

Another option is to assume that any unit within a certain distance from a supply depot can receive supplies from that depot even if no unobstructed route actually exists. This is a variation of the decentralized distribution of Age of Empires. Every supply depot magically transmits supplies to units within its circle of influence, but units that move beyond the range of any depot don’t get them. Designers often call this influence of objects on the terrain around them an influence map. They usually accomplish this by having the software track regions of influence on a map that it maintains internally. Most games that use influence maps include some means of displaying the areas of influence, either continuously or at the player’s option.

Two out of the three races in StarCraft use an influence map to indicate where their influence has spread (although the core mechanics use these maps only to determine where structures may be constructed and not to provide supplies to mobile units). For example, the Protoss power beacons, which provide power to the Protoss factories, have a limited radius of power distribution. When the player wants to construct a new factory, the game displays the influence map by color-shading the landscape, showing the areas where the factory may be built.