FUNDAMENTALS OF GAME DESIGN, SECOND EDITION
Upgrades and Technology Trees
In a game with a limited number of unit types, the players can sometimes 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.
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 role-playing games, 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 the upgrades out 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. They typically 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 her research when she goes on to the next level; she 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.
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 14.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 role-playing games, 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, particularly 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 to 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; you will undoubtedly modify them during testing.
 |
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 himself. 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.
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."
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 they often 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.
