Why have game designers?
Why have game designers at all on your project? That’s not actually a rhetorical question; I know one major game studio that simply does not hire designers, and several others that do not have any senior design staff, just junior designers in level creation and mechanical tuning. Design is apparently optional, as a discipline and as part of a project’s leadership.
To be entirely fair, it is true that if you’re making a game that’s essentially a copy of another game with a twist thrown in, you won’t need senior design leadership (though perhaps senior design leadership could explain to you why you shouldn’t make that game). Game designs can’t be copyrighted, which means that your own take on the match-three genre or your entry in the world of action RPGs can benefit from the visionary leadership of design that someone else paid for, at another company entirely.
Let’s assume that you have a gut feeling that you need active design leadership on your game project, and while you’re not looking to make something entirely new and original (if you are, you shouldn’t, but that’s a topic for another essay), you’d like reviews to focus on your game, not on the games to which it’s similar.
What does a game designer even do?
I’ve had a lot of conversations that go like this: “Oh, you’re a game designer? So you program games? — no? So you make game art?” My job is cloaked in mystery, it seems; people outside the game industry can’t imagine there’s a role that neither writes code nor creates visual art. (It doesn’t help that some parts of the industry have inherited the Microsoft terminology where ‘developer’ means ‘programmer’, while other parts of the industry use ‘developer’ inclusively to mean the whole team.)
My answer depends largely on whether I’m expecting the conversation to continue. If I’m talking to someone at the counter of a retail place where I’m going to be walking away in just a minute or two, I usually answer “I’m the one who has the ideas.” That’s not accurate, but it positions the discipline of design somewhere near the truth, at least. (This rarely works, by the way; people who don’t have the entire industry explained to them will latch on to the notion that designers write code like it’s actual Gospel.)
If I’m going to have further conversation with the person — a 20 minute Lyft ride, a school meet-and-greet with my kid — I’ll try to give a more accurate idea of what I do, and it turns out that it’s actually surprisingly difficult to explain.
“I have the ideas” fails because more often than not, I’m working with someone else’s ideas. I’m turning their ideas into workable plans for an actual game, but I’m not sitting around in a realm of pure creativity, dispensing nuggets of divine wisdom as I receive them. Mostly I don’t have the ideas.
“I make the plans” is closer, but still not accurate. The overall plan is dictated by realities of production, by the budget and the available resources, by the timeline to release. I don’t think I’ve ever made a plan that didn’t fall apart the moment we started to execute it. Then I’m revising the design on the fly, accounting for all the things we’re learning as we go.
I’m going to propose a definition of the job of the designer. You probably won’t agree with it, but that’s okay. This is how I understand what I’m doing, what the particular value I bring to a game project is.
Game designers empathize with the players.
The job of the game designer is to visualize the experience of playing the game. What parts of it are fun? What parts are painful, or boring, or frustrating?
This act of visualization doesn’t really seem that momentous. Anyone can do that, you may say. It’s just using your imagination.
The skill involved in being a good designer is being accurate. Recognizing what parts of the game need revision before the programmers code them and the artists model them. The game designer is a defensive position: we’re defending the production from false starts and red herrings.
A good designer will be able to listen to a description of a game system, envision the player experience of that game system, and from that visualization identify what parts of the system are bad and what parts are good. They also can make the call: is overall idea is compelling enough to the hypothetical player to pursue further?
One of the rules I live by is that you can’t design games you don’t want to play. Your lack of enthusiasm for the game will come through in its design. If you don’t find anything interesting about the first person shooter genre, you will not be able to effectively design a first person shooter. The reason is simple: you, the designer, have to fill the player’s role in conversations about the game.
Your empathy for the player, your recognition that ‘this is fun’ and ‘this is boring’, is the value you bring to a project. If you think it’s all boring, because you would not choose to play that type of game, you’re going to produce a flaccid design, regardless of how many bullet-point features you include. If you’ve ever played a game and found yourself wondering ‘why does this have a crafting system?’ or ‘why is this game open-world?’, you’ve seen the effects of this lack of empathy.
When you have game designers on your team in any capacity, what you’re getting is moment-to-moment empathy with the player. A level designer is imagining the gameplay that will happen in the features she creates. A weapon designer is imagining the scenarios that will result from the range and accuracy of the weapon, the player experience of using it, the excitement or lack thereof when the player finds it. These designers are, at every moment, discarding ideas that are dead-ends, exploring possible outcomes and cutting any that aren’t interesting.
But when you have senior designers in a leadership capacity on your team, you’re applying that same player-centered analysis to the whole project. You’re identifying dead-ends on a much larger scale. You’re cutting out dead weight from the game before you even put it on the schedule. You’re streamlining the route between pre-production and a shipped game.
This is a scary prospect if you’re not a designer yourself. “How does she know this system is bad? How does she know this won’t be fun? It sounds fun to me!”
I want to dive further into the notion that anyone can do what a designer does in a future essay, so for now I’ll just say: it sounds fun to you because you’re not the designer. Your job isn’t to visualize the player experience of a game system. You can do that, to some extent, and you have to in order to meaningfully participate in conversations about design… but you shouldn’t mix up your surface-level understanding of the design discipline with the designer’s hard-earned skill set.
You hired us for a reason. This is that reason. Let us do our jobs.