Analysis: On Theme And Game Design

[In this powerful analysis, game designer Daniel Cook considers the role of themes, from pirates to princesses, in game development, asking why games seem so limited in that area compared to film and literature -- and laying out some possible answers.] Recently, I was chatting with some friends about the role of "theme" in game design. Theme, in this discussion, was the setting of the game, be it fantasy, sci-fi, military, and so on. At first blush, the typical game designer's use of theme appears a bit primitive. First, there is a limited range in games compared to the wide variety of themes in movies or books. Games recycle a half dozen major themes, or in some cases, invent their own surrealist themes that make little sense outside the context of the game. Books, despite being grouped into narrow genres, have explored many thousands of powerful, evocative settings. You have books about bored European manuscript editors exploring the bizarre world of the pseudo occult, and you have books set inside the mind of a quadriplegic. The disparity in variety is intriguing. Secondly, it is often crudely applied. Theme is applied in broad strokes at the beginning of many games, but almost always plays second fiddle to interesting game mechanics. Goombas are mushrooms, but this matters little beyond the fact that they are squat, match the scale of the world, and can be squashed. If a novelist lazily integrated a character into their book's theme the way that game developer do on a regular basis, he would never be published. Develop-And-Switch The result is that theme is often seen as an interchangeable "skin" that can be applied after the fact to a set of working game mechanics. The task is typically left to marketers to round up a popular license so that it can be painted onto the latest hot collection of game mechanics. This attitude towards theme affects the very fabric of game development. And yet, something interesting occurs when we work this way. Very few licensed games turn into major long-term franchises. They often feel incomplete and the pieces ill-matched. On the other hand, seminal "grown from scratch" games like Bejeweled, Mario, Quake, Grand Theft Auto, and The Sims end up doing amazingly well. Despite their surreal and often disjointed themes, they are surprisingly fun. In these titles, the theme of the game mechanics and the theme evolved hand-in-hand, often undergoing major switches halfway through before settling into a successful partnership. The Sims was a game about architecture that morphed into a game about playing dollhouse. Grand Theft Auto was a cops and robbers chase game where you were the cop that evolved into a game about being a free roaming criminal. Quake was an Aztec-style world where you tossed about a giant Thor-like hammer that evolved into the story of a nameless soldier battling against the mutants in a series of brown dungeons. And BioShock was originally about Nazis on an island. If you start to dig into how games generate "fun," many of these thematic transformations are, if not inevitable, certainly commonplace. It turns out that most game designers are not complete idiots when it comes to integrating theme and setting into their game designs. Designers aren't ignoring theme, they are simply using theme in a manner appropriate to the medium in which they work. Some Logic Behind The Madness If you look at games as being about exploratory learning, they tend to teach the player a series of skills. First, the player learns basic skills (such as how to press a button) and, over time, assembles a scaffold of skills that lets him engage in more complex scenarios like "save the princess." Each moment of learning gives a burst of pleasure. These basic skills are utilized over and over again. If the player fails to learn them, the rest of the game is lost on them. Games reward involvement, yet there is a high cost the player must pay in terms of initial learning necessary to become involved. "Theme," from this perspective, is shorthand for a collection of preexisting mental tools, skills and mental models. I think of it as a tool chest of chunked behaviors that the designer can rely upon to smooth out the initial learning curve. The theme you select directly influences how you present your initial skills to the user. By saying "pirates," I turn on a particular schema in the player's brain and a network of possible behaviors and likely outcomes instantaneously lights up. If they see a pirate with an impressive sword facing a small soldier, the goal of fighting the enemy is self evident. With a small visual cue, I've eliminated minutes of painful initial learning. There is a fascinating moment in the sequence of exploratory learning where players say to themselves "Oh, I recognize and have mastered this situation already, so let me demonstrate my excellence." Because of the triggering of the theme, the challenge appears possible and attainable. If, on the other hand, I had substituted the pirates with gray blob A and orange blob B, the player might be quite confused, not even bothering to pick up the controller. Why So Few Themes? To a certain degree, this perspective on games explains the limited number of themes used in games compared to books or movies. A book uses theme as a hook to get people interested in plot and character dynamics. There are lots of potential hooks, and the more unique they are, the more intrigued the reader is to find out more. This encourages a proliferation of fascinating settings. On the other hand, a good theme in a game is one that triggers a number of clear mental models that are applicable to the game mechanics at hand. If you push too far outside the experience zone of potential players, you make them feel inadequate. It also suggests that occasionally a literary theme simply is not needed. Sometimes it is better to just tell the player, "Hey, it is a game and like any game you've played, we'll educate you as you go." The same triggering of appropriate schema occurs. If it is enough to grease the wheels of learning, then our mission as a game designer is accomplished. "Skinning" Is A Bad Practice When you look at game design from the "games as learning" perspective, the idea of creating a slap-on aesthetic skin for a set of game mechanics starts to break down. In the best games, mechanics and theme evolve in lockstep over the course of the many iterations. If a mechanic isn't working, you have a couple choices. You can adjust the rules or you can adjust the feedback that the player receives. The two act in concert to produce the player's learning experience. Often it makes sense to adjust the feedback side of the equation. What if people don't understand that the pirate is their character? Maybe it makes sense to make the pirate wear a right red outfit, and make the enemy a bit more evil-looking. When you do so, the theme of the game shifts ever so slightly. Over hundreds (or thousands) of tweaks, a theme for the game might emerge that is quite different than what you originally envisioned. This is often the case for the best game in the history of our industry. In fact, the final theme may be semi-incoherent if you attempt to analyze it as a literary work. However, that doesn't matter, because it provides the moment-by-moment scaffolding of feedback that helps the player learn their way through the game. As long as the game is fun and delivers value to the customer, we can often toss the literary definition of theme out the window. In fact, you start getting into trouble when you make the theme so rigidly defined that you can't adjust the feedback for specific game mechanics. What if you are dealing with a license where the pirate isn't allowed to wear a red outfit? That design option, which may have been the best one available, is taken off the table. The hundreds of little trade-offs that occur when theme coherence wins and gameplay loses diminishes the effectiveness of the game. So you can't just "skin" a set of game mechanics. When you do makes the attempt, a well executed iterative process of game design will often result in a game that is quite different than its source material. A poorly-executed process results in a game that plays poorly. Conclusion There are a few lessons here. First, the most effective game themes exist primarily to facilitate the learning process for the player. This may be a traditional narrative theme, but it doesn't need to be. Next, theme evolves in lock step with the rules of the game over a process of many iterations. You might as well plan for it. Early on develop vertical slices of your game. This will help you converge on working combinations of theme and rules. As you go, allow for iteration on production assets. Finally, note that locking in your theme too early and too rigidly can stunt the exploration of more effective feedback systems. A bit of flexibility often yields better gameplay. [Daniel Cook writes regularly on design, the business of games and product development techniques on his blog Lost Garden. He currently works as a game designer at Microsoft.]