Every talented designer I have ever known, with only a few exceptions, has suffered from impostor syndrome. Designers seem plagued by the notion that they’ve somehow tricked their way into their positions, fooled hiring managers into believing their facile bullshit is actual skill and experience.
I think this tendency comes from a larger problem in the field of game design which I’ll come back to in a future essay, but for now I’d like to talk about the specifics: what does a game designer actually do from moment to moment? I’ve previously talked about the craft of game design, and how it’s a skill that you can develop through practice, but I haven’t really addressed what that skill is.
Design as Vocabulary
When I’m in a meeting with a mixed selection of co-workers — game designers and people from other disciplines — and we’re talking about design, whether it’s proposals for our project or analysis of other projects, there’s a thing that happens, and it happens almost every time. A designer will say something like “We could do [X], but…” and all the other designers in the room will nod. That’s not a good idea. Then a non-designer will speak up: why can’t we do X? And in almost every case, a completely different designer will speak up, explaining what’s wrong with X, in precisely the same terms as the original designer would have used.
Design, in a sense, is a shared language. It’s a shorthand born of experience and analysis, a common pool of knowledge that we all draw from and recognize when it’s being employed. When designers talk, we can use a term like ‘talent tree’ or ‘skill tree’ and every designer in the room knows, not just what we mean by that, but all the possible negative and positive connotations it carries with it. Designer 1 can say “I’m thinking about something like a talent tree,” and Designer 2 can reply with “What about respecs?”, and Designer 1 can say “Well, I was imagining it would be completable,” and that’s a whole design conversation and both designers know what the proposed system is, how it would work, and the likely impacts it will have on the game.
(Designer 2 will, of course, reply with “So there’s no specialization in the end game?” because that’s a logical concern, and Designer 1 needs to either explain where specialization will come from, or explain why the game doesn’t need specialization in the end-game.)
A real-world example of this language in practice (though honestly I’d say I’ve had the example conversation above at least a half-dozen times in one form or another): there was a casual MMO that I was peripherally associated with, though my team’s input was eventually not included because of budget and time constraints. This casual MMO was PvE — there was no player-on-player conflict — and was intended to be a platform for minigames, with the MMO serving as a kind of connective tissue between them.
The question was raised: what will keep people playing? What’s our endgame strategy? The game had no real advancement system outside of whatever individual minigames offered; the wrapper MMO was basically flat, with no real long-term chaser goals or levels or increased power to act in the game’s environment.
The person in charge said “We’ll just make content faster than the players consume it.”
Every designer I knew thought this was hilarious; that line, “We’ll make content faster than the players consume it,” became a punchline, with the joke being the entire game. Of course, the game failed, and while the vagaries of business development mean that nobody except the senior staff on the game knows why it failed, no designer who heard that punchline was surprised when it happened.
Knowing why ‘we’ll make content faster’ is a hilarious punchline is an example of the language of design. It’s an in-joke in the sense that there’s context needed to understand it, but that context is the practical experience of a working game designer.
Let’s describe the first aspect of the skill of game design as breadth of experience. A designer knows a lot of games. She knows how their systems work, she has opinions about which elements were successful and which were not, and theories as to why. For almost any game, a designer is familiar with it, or familiar with a game adjacent to it. Using a particular game’s mechanics to illustrate a point will usually work while talking to a designer, and if she doesn’t know the specific game you’re using, she’ll know enough to understand what you meant from a cursory explanation.
This isn’t a surface familiarity with the games, though. A gamer’s opinion about a game is usually going to be a surface-level take: was it fun? A designer’s opinion is going to be both more deeply investigated and less focused on the specific question of enjoyment. I can’t think of a single game I’ve played that didn’t have something to teach me. There have certainly been some where many of those lessons have been negatives: don’t do this. But every game is a data point, if you’re willing to dig into it and figure out what it’s doing and what it’s failing to do.
A designer has a mental library of dos and don’ts, sourced from a thousand different games across genres, platforms, and styles. That library is the greatest resource a designer brings with her to a new project — a knowledge of almost every permutation of game mechanics, content, user experience, and implementation that your team can possibly think of.
Here’s the practical advice for this part of our exploration of impostor syndrome: play a lot of games and think about them while you play them. Not just the games you think you’ll like, and not just to enjoy them. Play ones you don’t think you’ll like, and play them critically. Look for how they work and how their parts fit together. Develop your own library of examples and outcomes.
Design as Grammar
I’ve talked before about the designer as a stand-in for the player, and that the key value the designer brings to a project is empathy. That’s the second half of what the designer does. The mental library of experiences is the raw material; the other part is synthesis of that material into something useful.
Specifically, what the designer is doing when she places herself in the player’s shoes is exploring player motivation. It’s one of those so-obvious-in-hindsight concepts, where you hear it and think ‘well, of course’: players don’t have to play your game. Players choose to play your game. Your challenge is to answer the question ‘why?’ Why do players choose to play your game?
It’s a moment-to-moment choice, too. Consider that at every instant a player could quit your game and watch a TV show or a movie, or read a book, or go out with friends, or take a nap, or eat a microwave burrito. Every moment a player spends with your game is a choice to keep playing; every moment is one you, as the designer, have to earn.
I think of the disciplines of game development like this: the programmers create the infrastructure that everything else depends on. The artists convince the player to come in and look around, and then make sure the player’s first impressions are sustained throughout the experience. The writers give the game all its post-play impact, and create conversations about the game after it’s over. But the designers? They keep the player from walking out the door. They keep the player wanting to come back as soon as possible. They’re the reason the player wakes up in the morning and thinks ‘I can’t wait to get home after work so I can play more of that game.’
To effectively keep a player in your game, engaged with it and wanting more, you have to understand motivations. The question you need to be asking is ‘why should the player do this?’ The user experience team can convince the player to try something out for the first time, but you, the designer, have to give them a reason to do it again after that first exploration.
Motivation is a rabbit-hole, of course. It can lead you to asking questions like ‘why do people play games at all?’ and ‘what is fun and what is play’ and if you go down that hole too far you’ll find yourself reading Sartre and wondering about the meaning of life. And it’s such a rabbit hole that I think I’ll hold off on exploring it in detail, because it deserves its own essay, maybe two. But we can make some broad statements about player motivation.
First, motivation is not the same thing as enjoyment. ‘Fun’ can be a strong motivator, but it is not the only motivator.
This image is one of my favorite steam reviews of my game BATTLETECH. I love it so much that I put it on my LinkedIn page. It perfectly captures the difference between enjoyment and motivation. Nobody puts 500 hours into a game without being highly motivated, even if their conclusion after those hours is that they didn’t enjoy it at all (though I suspect there were some definite moments of… let’s call it ‘satisfaction’ so as not to call this reviewer a liar).
For every element of your game, you should be asking: what does this motivate the player to do? What motivations would compel the player to explore this aspect of the game?
For the answers to those questions, you look back at your vast library of game knowledge that we discussed above. You may not have a solid philosophical basis for asserting any answers — most of us don’t, because we’re working game designers, not academics — but what you do have is an absolutely enormous data set: every game ever made, how players reacted to them, whether they were hits or flops, what elements players cited about them for good or for ill.
With enough data, you can handwave certainty. With enough data, you can do something like science. You can use specific data points and assert conclusions from them. You can say ‘this is too grindy’ and support your argument with a dozen or a hundred games that were described as ‘too grindy’ and another hundred that were not.
None of it is an exact science, of course, and every example will have multiple counterexamples. Humans are weird and complex, and culture is weird and complex, and tastes are unpredictable. If we could do exact science about player motivations and game design, we’d all be out of jobs, and all our games would be replaced with a single Ur-Game that perfectly motivated everyone. But we can certainly get within the ballpark, and maybe closer than that.
A deep knowledge of games is like the vocabulary of the design language; a deep understanding of player motivations is the grammar of that language. An experienced designer will speak that language without thinking about it; we’ll intuitively grasp whether a system is good or bad, compelling or ineffective. I’ve occasionally described my design sense as ‘designing from the gut’, but what I actually mean is that, given enough time with the language of design, it will become a native language, and you will become fluent in it.
Here’s the practical advice for this portion of our exploration: when you play games, you have to quit eventually. You have to turn off the game and go eat dinner or sleep or go to work. Look at the moments where you say to yourself, ‘I have to quit now’. Why then? Why did you realize it was late just then? Why did you realize you hadn’t eaten dinner yet at that particular moment? What was happening in the game?
Obviously games can’t be so completely motivating that you forget to eat entirely (though the ‘one-more-turn’ cycle in games like Civilization have certainly led to some sleepless nights for me), but the moments where we think about the world outside the game are moments where the game’s motivators are weakest. What characterizes those moments?
I didn’t really enjoy any of the Warcraft games, and I generally don’t like RTS games. What I discovered was that the moment when I like them the least, when I most want to quit, is immediately after winning a mission. At that moment, I’ve overcome a peak challenge, I’ve scaled a mountain of difficulty and come out on top. The level abruptly ends with very little denouement, just a ‘VICTORY!’ pop-up and the briefing for the next level. The sudden drop-off in intensity was a natural exit point for me. I wanted to enjoy my victory, and going directly into another challenge seemed unfair, especially as I could be pretty certain it was going to be more difficult than the last.
That’s an example of how my own motivation rises and falls over a specific genre of game, and I can think of ways to address it if I were given the chance to revise those games to my own tastes. And I can generalize from my experiences, looking at other games and discussing my reactions with other players, and build a more complete picture of how the motivations used by and provided by Warcraft work, and how they don’t work, and how different players will respond to them.
Conclusion
If I were to summarize this whole discussion into something pithy, I’d say “To be a designer, play a lot of games, and think about how they work to keep you playing.” If you do those two things, you’re not an impostor; you’re a designer. Welcome to the team; it’s awful, but you get used to it eventually.
