In Hollywood, there is a particular book that few outside the hallowed realm of those who work on movies are aware of but which everyone who goes to movies today is affected by.
Save The Cat! The Last Book on Screenwriting You’ll Ever Need lays out a meticulous formula for story beats that describe when the hero should get dressed down by a superior to what minute of the movie there should be a dark night of the soul moment. Everything is laid out with precision, from when the B storyline should be introduced to what order the antagonists of a film should be disposed of.
Something much like this happens in game development, though in the case of game development there is no single work that describes the problem we developers face with quite this degree of exactitude.
Whether one is talking about console games, mobile games, social games, MMORPGs, RTS, FPS or simulators, there have grown up a number of conventions that are virtually never challenged.
For example, in MMORPG game design today, the concept of characters having explicit levels is not merely assumed, it is sacrosanct. To be sure, there are exceptions, but they are vanishingly small (Ultima Online and EVE, in this particular area).
RTS mix the tactical (moving units around) with the strategic (building) and have tech trees. MMORPGs have enshrined the Holy Trinity of DPS (damage)/Healer/Tank (though this has started cracking a bit thanks in part to games like Guild Wars 2).
Are there good reasons for levels? Sure. Similarly, there are good reasons for tech trees (they make balancing much easier, for one, and make it easier for players to conceptualize reasonable development paths) and even the much-maligned Holy Trinity (communicates clearly to players what they are “supposed” to do in a group).
The problem lies in that these things have come to be assumed; they are rarely challenged, and because they are so rarely seriously challenged the reasons for their existence has become lost, enshrined on altars of design dogma.
During the conceptualization phase of a project, instead of following a policy of parsimony – that is, a principle of the smallest number of changes to get a job done – game development has a tendency to regard these bastions of design as necessary. After all, they’re proven, right?
And here lies the second problem: Why do levels work? Why do paywalls work? Why does an MMORPG need items at all? (By the way, “Because players expect it” or “World of Warcraft does it” are the wrong answer to both of the above).
There are glib answers to all of the above, but when they are applied at the very start of a project’s conception and early design they inevitably ram the game down a particular path, and one of the facts of development is that every design choice you make limits the next choice down the line, which itself limits the next one down and so on.
Take my admittedly favorite example of this that I started talking about above – levels.
As soon as you make the decision to have levels, you then all but mandate the number of items you must make, the number of zones you must build, the number of environments your artists must craft, the number of skills you must design and a dozen other major aspects of gameplay.
This is one reason why the first Guild Wars was so radical, even if in the end it blinked and backed away from a leveless system. In the first Guild Wars there were indeed twenty levels, but those twenty levels were easy to obtain and represented the smallest portion of even the average player’s gameplay time. Instead, most of the player’s time was spent hunting down specific skills that weren’t quantitatively better, but rather qualitatively different.
This was, to put it mildly, brilliant. Moreover, it was brilliant not simply from a design point of view, but also from a development point of view – if your character’s abilities are not level gated or scaled, then there is no minimum number of abilities you have to make. Instead, you can make as many as you can make distinctive and interesting.
Similarly, Skyrim‘s lack of classes meant that designers didn’t have to budget a precise number of skills for each class to make sure each class was equally viable and balanced. Instead, the criteria for a skill was that it was interesting, fun and useful.
It’s an ugly fact of game development that game studios live or die based as much on their developmental rigor and discipline as they do on the brilliance of their design team. A development team that can’t hit its targets or can’t rapidly scale up or down the scope of their game is a development team that is probably going to be looking for a new job.
Design defines development even more than development constrains design.
Conventions do exist for a reason, and it’s true that changing conventions too haphazardly can risk players feeling lost or not knowing what to expect for your game. It can, too, cause serious headaches for marketing in the effort to identify and evangelize to appropriate demographics.
(This is where indie games have a huge advantage; because they depend on word of mouth rather than large marketing budgets, they can afford to find their own audience rather than needing to establish an audience and establish it quickly).
In the end, though, a game benefits immensely where the design is built to consider development – which includes post-launch maintenance, expandability, database bloat and a hundred other factors – from the very beginning.
It’s fine (really) to make a game with levels or tech trees or any of a hundred other design conventions. Just don’t assume it, and understand exactly what the cost is in design freedom or development realities when you create those designs.
So when you are staring at a blank computer screen and starting to conceive of a design, whether for a single mob or an entire game – don’t be afraid to kill the cat.