Editor’s note: Tadhg Kelly is a consultant game designer and creator of leading game design blog What Games Are. You can follow him on Twitter here.
There’s a number of us who claim the title of “game designer” but we aren’t really a contiguous group. Game design isn’t a set job description that applies evenly across all companies (or even projects within the same company). It doesn’t have a set of standard tools, or a standardized kind of output. Unlike engineers or artists, it’s hard to pin down what the deliverables of game design are, and as a result we tend look like geniuses or frauds. Given such haziness the question must be asked: Do you really need a game designer, or is “game design” just helium?
Three Design Ideals
In my travels I’ve encountered three ideas of what game design is or should be.
The first could be described as the “architect” model. In this model there tends to be one person at the heart of a large studio acting as the keeper of the flame. He’s the visionary leader and – although he usually leads a team of more junior designers who focus on individual areas (combat, mechanics, balancing, user interface, content, etc) – is perceived as the all round central creative voice of the game. Architect-style designers are few in number and often regarded as games industry celebrities.
The second model could be described as the “maker”. This game designer is a hands-on type who had an idea for a game and proceeded to draw, diagrammed, visualize, program and write the whole thing end to end. Either she did this alone or with some help, but the overall impression she exudes is of the talented core at the heart of a project. A lot of indies sit in this maker category and use tools like Unity3D to just make the thing that they see in their head and let the Universe sort out what it all means.
Then the third model could be described as the “engineer”. Some shops (large and small) declare that they don’t have any truck with “game design” and instead have product managers corralling coders who iterate endlessly on living projects. In this context “design” usually only equates to content creation (levels, quests, etc) but the fundamental dynamics of the game are held to be pure code. Everything is kept deliberately collaborative and the game will be done when it’s done, which sometimes means never (and sometimes that’s ok).
Three Design Problems
All three approaches have significant advantages depending on the type of game being made, but they also have their shortcomings.
The architect-designer runs into disconnects. While he knows the experience that he wants to engender, translating that into specifics is often a major problem. Architect designers become the most hated people in their own teams because they will set the course for what the team should deliver, but then throw out the resulting prototype three, six or twelve months later because it doesn’t match what they saw in their minds. They generate a lot of waste in the quest for a certain feel for a game, on a lot of grand experiments costing millions of dollars, and yet the end results are usually quite ordinary. The most common criticism against architect-designers is they are too egg-headed, too indecisive and too much about their own ego.
The maker-designer runs into a very different kind of problem. She may be cash-strapped and hacking her game together, but her larger issue is how she loses sight of the forest for the trees. The maker-designer barrels away on the minutiae of implementing her game but doesn’t realize that its core dynamic doesn’t extend well. Or that her premises for making the game are false. Or that there’s a big disconnect between the mechanics and the aesthetics (“ludonarrative dissonance”). Unlike the architect who can’t think down enough to turn ideas into action, the maker-designer doesn’t think up enough and consider how action is supposed to fit together.
Meanwhile the engineer-designers’ problem is that groupthink leads to conservatism. At first this sounds counter-intuitive as surely more minds approaching a solution should be more creative, but they’re not. This is one of those areas where developing games is different to developing software. In software there are direct solutions to definable problems like utility, ease of use or speed. In games the problems aren’t problems in that sense: They’re creative problems. How to make something fun, different, exciting and entertaining is rarely a matter of making better technology. But because engineer-designer groupthink tends not to see that, it demands validation for ideas before they are implemented (to avoid waste), and thus filters all innovations into those that will fit inside iterations and those that are never attempted. This is why engineer-designer studios get stuck making the same game over and over.
Formal Game Design
There is a fourth model.
There are some people who consider game design to be an emerging formal discipline. They’re the people for whom the mechanics of games, the user interaction patterns, the economics and their outcomes, are fascinating in the abstract. They tend to think that game design is actually a way of looking at games, seeing the operations of the mechanical machines underneath and then applying that learning to the design of new games.
They also believe that their approach to design is teachable. Many formalists operate in the academic sphere, trying to get the next generation of students to think on games. Some do so in the service of pure mechanics, others to impart design as a foundation upon which to then build aesthetic vistas or narrative experiences. Formalists view games both pragmatically and philosophically, as a language of communication and expression built on components like verbs and loops outside of either the technical or the aesthetic.
The potential value of the formal game designer is as a translator. The formal designer does the complex work of turning the architect’s high concept into mechanical specifications that make sense, saving studios millions of dollars and thousands of hours while preserving a creative direction. The formal designer helps the maker by assessing her ideas and prototypes, identifying the early gaps and then challenging her assumptions. The formal designer gives the engineers a direction that breaks them out of the cycle that they’re stuck in and maybe spins them off to somewhere else.
…Maybe
Well in theory.
When we formal designers go to dinner we talk animatedly about the ins and outs of our approaches. Napkins become instant design documents as we draw out circuit-like diagrams for the molecules of our games or their mechanical patterns. We talk of verbs and tokens, pools and emitters, actors and conditional rules, and we’re all roughly on the same page. The problem is that nobody else is, and so the biggest criticism of formal game design is that it seems to be bullshit. High concept bullshit perhaps, but bullshit nonetheless.
I think the answer lies in standards. The rejection of design has something to do with creative control, but mostly quality of output. The history of game design documents, for example, is an ignominious tale of massive and poorly-written bibles foisted upon engineering teams then left to figure out what they’re supposed to do with them. Since nobody knows what to look for in a design there’s often too much room for vamping, and therefore waste. The lack of solid answers to key early questions turns cheap design time into expensive code and art time, and this is why game design gets no respect.
For formal game design to help solve problems it has to becomes less dense and more deliverable-driven. The rest of the world is never going to sit down and learn our lexicon, so it’s up to us to figure out how to express design in a way that everyone else finds accessible. Then maybe design’s value will become apparent for all to see.