(Bigger image) I’ve been looking into the matter of tech trees and talent trees lately as I hammer out the details of the system I want to use in my own game, and I was going to write a long post all about their points and purposes (and how there’s not much like this out there on the Internets), but then I found this smart post from Peter Harkins (whom I don’t actually know). It doesn’t quite do what I’m looking for, but it comes close, by taking a stab at explaining “The Purpose of Technology Trees.”
As Peter has it, there are four main functions:
- linearly organize options over time
- act as gates on content consumption
- increase the power scale of players
- act as a resource sink for high-level players
I’d add to and perhaps slightly modify this. As below:
On the surface, tech and talent trees seem to be about a creating a natural course of evolution and customization for a player’s character or forces. If you don’t look too closely at them, they just provide a framework for the progression of play, so that you don’t spend the whole game with the same set of abilities (which is actually just fine in other contexts, like platformers, for instance).
But look at tech trees from the other side of the code, and there’s a lot more to them. Below are a few random thoughts about some of the things tech trees can be made to do in games. Some of these are really different aspects of other entries in the list, but they bear examination in any case.
- create a sense of evolution and ownership through apparent (to the player) customization
- encourage specialization (which is different from customization)
- increase replayability (by offering a number of mutually exclusive specializations to explore)
- support various play styles within a single game
- tutor players in an unobtrusive way
- maintaining a consistent level of challenge without repeating experiences
- provide a framework of short- and long-term goals that frames the progress of the game in parallel with narrative elements that may be present
- give the min-maxers and tech-tree geeks a reason to whip out their Texas Instruments (or should that be Instrumentses?
- create grinds and time-sinks to increase the tenure of a player’s engagement, as well as contributing to virality and revenue
- in microtransaction-based social games: encourage spending
I’m sure there are more I’m leaving out — or ones on the list above that might not belong. Feel free.
What’s also really interesting to me (and perhaps fodder for another post) is the wide range of ways in which tech and talent trees can be implemented gameplay-wise. The ability associated with any given node must first be unlocked via prerequisites, and then (usually) purchased in some way, either with currency or via building units or infrastructure. The mechanics that can be used to create the prereq and purchase requirements are quite varied, if you give it some thought and attention. As are the ways in which specialization can be enforced — by limiting the “slots” or “cards” that can be active, or simply by making the pursuit of two different branches prohibitively expensive, to name two.
Peter (as well as the occasional blogger and other commenter) are right to point out that tech trees are too often samey, however — that is, there’s a limited range of implementations of the concept that can be found in the wild. I suspect that’s because there’s a limited range of implementations that work very well within the bounds that the RPS and strategy genres have developed. I would suspect that many variant implementations have been tried but have failed, and it’s those that we don’t encounter out there in obscure-game-land.
That said, I’m not someone who believes that a failed idea can’t be turned into a successful one, given the right set of eyes and hands working on the problem. Tech Tree X may have failed because it was attached to a game concept that didn’t support it well, not because it inherently sucked. Like everything else in games and game design, there’s a delicate balance here between the experiences that are engaging and those that are overly complex, between the tantalizing and the prohibitively frustrating, between the satisfying challenge and the offensive sales pitch. I’d be interested to hear about unusual tech tree implementations — that did or didn’t work! I imagine this could all make a really fascinating and engaging semester somewhere — especially if you included the technical aspects of storing and manipulating tech trees in code. Anyway, back to my research. (Get it?)