push.cx
Peter Bhat Harkins
Technology Trees
This is part of a series of blog posts on the design process of my web game:
- 1. Ikariam
- 2. WeeWar
- Tangent: The Farming Genre
- 3. Tactics Ogre
- 4. Counter-Strike
- 5. X-Com
- 6. Kongai
- Tangent: Technology Trees
Talking about Ikariam reminded me about technology trees because it has a particularly big and complex one. When I was playing I created a graph showing how to unlock everything so that everyone in my guild could quickly develop as we needed.
In the diagram below, pink rectangles are buildings, green parallelograms are actions, solid blue circles are ships, red hexagons are military units (with their costs), and the empty circles are technology achievements (color indicating which of four tracks). It sounds really complicated and is overwhelming at first look, but it serves as reference for any player with a little experience.
{.alignnone .size-full .wp-image-895 width=”579” height=”592”}
It’s worth noting that this is long out-of-date; updates to the game have extensively added, rearranged, and repriced things. I created it with graphviz’s dot utility. It’s a great tool for easily making the directed graphs that show up over and over in computer science. (And read Anathem, it’s a captivating novel that, yes, prominently features directed acyclic graphs.)
OK, that’s all the “Yay, technology trees are keen!” that I can manage.
The Purpose of Technology Trees
They do have some uses. The first three are heavily intertwined:
First, tech trees linearly organize options over time. If a new player could choose from the start whether they wanted to produce smooth-bore or rifled barrels for their soldiers, they’d have to be a suicidal masochist to choose the former. Usually the later technology uses different, a higher quantity of, or more precious resources (like going from bronze swords to steel swords), but often the improved option is such an large improvement that it’s not a real choice which to use. A tech tree makes it possible to present these things in a linear fashion to players to make the game more rational and learnable.
Tech trees also act as gates on content consumption. Until you’ve reached a particular level of development, you can’t use the warp drive and are confined to exploring your solar system. This makes sure that players don’t skim over expensively hand-scripted characters and hand-designed locations (though most PBBGs procedurally generate content). Gating also ensures that players will have opportunities to recognize all the options presented by content — to continue the example, it’d be easy to overlook your mineral-rich asteroid belt if you could immediately cruise off to the stars, and you might end up hamstrung by lack of iron or the knowledge of where to find it and how to mine it. Gating keeps players from being overwhelmed by options and content until they’ve had some time to read help files and make some new friends they can ask questions of.
The third function of a technology tree is to greatly increase the power scale of players. MMORPGs have infamously large power scales: you go from barely triumphing over garden slugs to slaying gods in a casual manner befitting Richard Dawkins. The game Settlers of Catan has a smaller power scale: you start collecting resources from two towns and could grow to five towns and four cities. Chess has a flat or declining power scale.
The final use I’ve seen is as a sink. High-level players often have more resources than they know what to do with, so they lose the fun of hard choices (like equipment in Tactics Ogre). Technological advancements that provide quantitative improvements (that is, shave some percent off of sailing time as opposed to unlock the ability to build steamboats) act as sinks that excess resources can be poured down. This works especially well when the advancements are expensive, ineffective, and public so that players get bragging rights rather than becoming invincible powerhouses.
Technology Trees Usually Suck
Most persistent browser-based games take those first three purposes and crank the dials all the way up. Players use technology trees to go from pointed sticks to nova bombs, from a small space to the most fertile or productive places possible.
The biggest problem with trees is that they act as ratchets. Once you’ve learned The Pulley you always know it and can’t lose it. That’s fine in a game of bounded duration like Civilization or StarCraft, after an hour or few the game is over your research disappears. You don’t start your second game of Civilization back in the stone age knowing how to produce nuclear weapons. But PBBGs are open-ended, a player has a technology until they quit playing entirely (probably being driven to it by someone farther along).
So players get the height of an even bigger power scale to drop rocks on each other from, and if they don’t have a sink for their extra resources they’ll probably shower them onto a guildmate to ratchet themselves up with.
One StarCraft mechanic often shows up with horrible consequences. In StarCraft, there are a number of enhancements that give special powers to units (such as the ability to burrow into the ground or turn invisible) that mean a defender who hasn’t researched the countermeasure cannot attack those units at all. This works in a 40-minute game where the defender gains access to the countermeasure around the same time the attacker gains the power, but in a PBBG new players may be dropped in next door to someone who has played for months and the countermeasure may be weeks away. Awful!
Designers often don’t recognize how special technology is. A player might gift their resources, raze their buildings, move their cities, fire their workers, discharge their soldiers, quit their guild... but they’ll still have their technology. The advancements available rarely reflect that permanence.
Redesigning Technology
One of the joys of long games like MMORPGs and PBBGs is that they give players the opportunity to eventually try everything the game has to offer. Well, unless the player has to make an irreversible decision like character class, then they create alternate characters or logins and decry the grind back up through the tree.
Looking at StarCraft again, I’ve combined two mechanics to design an improved technology mechanic for my game. First, limit permanent technological advancements to the expensive but low-productivity sinks mentioned above. In StarCraft you produce advancements by constructing certain buildings or spending resources at them, like a Spire to be able to build flying units. If you lose the building, you lose the advancement and can’t build more flyers. The other mechanic is “supply points”, a cap on the number of units you can control at once. Certain buildings and units raise the point cap, and most units count for 1-2 points toward the cap. It’s not a resource you can bank, spend, or trade, it’s solely a limit to the number of units you can recruit. It prevents armies from growing too quickly in the beginning of the game and growing too large in the end of the game.
Combining these two ideas, players could build research buildings to unlock different abilities and advancements. They can’t unlock everything because the cap on research buildings is lower than the number of abilities. Abilities stop being an oddity and are better integrated into the rest of the game mechanics -- do you spend your money setting up a gasoline engine plant or buy more horses? Players choose where to specialize based on their opportunities and personalities and can raze and rebuild buildings to change their selection.
This is the eighth and final of a six post series on game design, weighing in at a surprising 6,200 words (I didn’t originally plan on these two tangents, but let’s all toast Douglas Adams while I’m about it). I’ve noticed I’ve picked up some new readers, so let me again let me say I really appreciate feedback. I’m going to return to my regular babbling about whatever shiny thing captures my attention -- which is to reiterate that you should feel free to comment, email, or IM because that’s where I tend to pick up topics from.