What a Game Designer Really Does

The job#

The title "game designer" gets thrown around in confusing ways, even in professional settings. So here's a straightforward answer.

A game designer conceptualizes and creates the overall blueprint of a game (a video game, a tabletop game or a live-event game) and defines the complete experience that both the people building it and the people playing it will have, from start to end.

A game developer and a game designer are not the same. A developer works with art, code, sound and writing to build a playable game. A designer is the one who knows how to glue those pieces together so they aren't worthless as a whole. (Marketers, community managers and publishers are part of that glue too.) Developer and designer need each other. You can't make a game with only one of them.

Think of the designer as a spider at the center of a web, connecting everyone. They tell people what needs to happen, and trust them to know how. Something like a director, an architect, a facilitator, a recipe maker.

That reaches far beyond the game itself:

• Outside the game, the designer has input on everything that happens before a player ever plays it: the marketing, the monetization, the community, the publishing, and how the project is built from its first version toward its ultimate form.
• Inside the game, the designer defines the abstract rules, structures, frameworks, architecture, systems, features and mechanics, and everything related to them.
• Across time, all of this is designed with the game's entire lifecycle in mind, from long before the first playable version to far into the future, when the game is finished but still maintained, kept alive and compatible with new platforms and operating systems. The whole lifecycle is the designer's responsibility.

In a team, a game designer does not code, script, draw, market or compose. They work with the people who do. But they study a little of each of those skills, enough to understand what it's like to be in those people's shoes, and to know what they need.

And a designer doesn't necessarily design the final content that appears in the game. More often, they design the support structure: how content works, how it's made and how it's managed, inside the game and outside it. The designer does the complicated, boring foundations work (Chapter 21), and the rest of the team gets to do the fun part of making the final content to their own taste, within the framework the designer built. A mastermind solving a very complex puzzle, using many fields of knowledge, to create something worth coding, worth drawing, worth writing for, worth marketing, and worth existing.

One designer per project#

For any project, there can only be one game designer. Everyone else is an expert the designer relies on, consults, communicates with, and gives clear blueprints to.

The person who holds the driving vision of the project has to be the designer. That role can't be delegated or shared, because it's the core problem-solver and decision-maker for every aspect of the game. The project lives and dies with its designer.

Look at how it's usually done instead, and what comes of it:

• In small and mid-sized companies, the design work is often dumped on a coder or an artist, who is expected to do the work of two people. The result is burnout, slow development, or one or both jobs done badly.
• Sometimes nobody takes the job. The team holds meetings, throws ideas around, and expects a coherent design to emerge from the pile on its own. No real design happens. It's darts thrown at a board.
• In large companies, it's often reversed: many designers, each siloed into one part of the game (characters, environments, weapons, interface, story, monetization), sometimes with sub-designers for parts of parts. Above them, a producer or director has the final say, and above them, the head of the company, each able to change design decisions at any point. And everyone expects a coherent whole to come out of it.

What comes out is usually an indecisive mess that tried to please everyone and truly fulfills no one. All the effort in the art, code, sound and writing goes down the toilet.

Why consensus can't do it#

"Can't the team just talk until they agree, so the design comes out coherent?" It won't work. Everyone is different, thinks differently and sees the project from their own angle. Those views often conflict and can't simply be combined. A unified vision can't happen if more than one person is putting the puzzle together. Too many chefs spoil the broth.

"Then the producer is the one central person, so it's fine to have many designers under them?" Sadly, no. The small design decisions are still being made by different people, each with their own idea of what the game is for, because each is a unique individual. Same problem, however you arrange it. The well-known designers whose games are famous for their coherence control the vision of their projects, and shape every design decision to fit it.

Games are fragile things, design-wise. The tiniest decision can have a huge effect on the future of the game: technical debt, a hollow core that can't be fixed, content that doesn't fit together, standards that don't hold, a business model painted into a corner. Those are often best fixed by starting over.

When the designer leaves#

If the designer leaves, a new one has to take their place, and from then on the vision will change, because no two people think alike. Every existing design decision needs to be re-examined, or the project's coherence breaks apart and its purpose ends up in conflict with itself. Pardon the food analogy, but it's like someone was baking a big cake, the staff changed, and now it's been decided the cake should be a soup. You can imagine how that goes. (Scenario 8, the sequel that failed its fans, is often this.)

One designer, many voices#

Please don't misread this as "the designer ignores everyone and decides alone". It's the opposite. The designer is the one person whose job is to listen to everyone. They find out what every expert needs, what each one is good at, what their limits are. They hear the partners' dreams with NVC, and recap them to make sure they heard them right (Chapter 2). They take in all of it, and then they make the decision that serves the purpose and meets the needs of everyone involved as fully as possible.

That's the difference between consensus and design. Consensus asks everyone to agree on the solution, and gets a compromise where everyone loses a little. Design asks everyone what they need, and then one person finds the solution that meets all of it. Working with People covers how.

Blueprints with leeway#

The designer's main output is blueprints: instructions and guidelines for every expert, so they know what needs to be done.

Good blueprints have leeway. As long as the design requirements are met, the expert (coder, artist, marketer, writer, community manager, even the boss) can do the work the way they find most comfortable and best. They can add their own personality and touch, and even do it in a completely unconventional way if that turns out better in their judgement. The designer defines the what. The expert owns the how.

To write good blueprints, the designer has to talk with each expert: how they work, their skill level, their limits and their specialties. A blueprint is tailor-made for the person who will follow it. The same feature needs a different blueprint for a veteran than for someone on their first project.

And a blueprint has to be readable. Words aren't the only tool. Documents formatted to be easy to read and straight to the point, with pictures, diagrams, charts or infographics where those show something better, are a form of communication too, with the team and with your future self.

How it should go#

Design work at its core is abstract problem solving. It starts with an idea that came as an epiphany: a new vision, exciting and full of potential, a new way to satisfy fundamental human needs better than what was available before.

The designer is the conduit who takes knowledge of human needs, gathers intelligence from the experts around them, maps out the limits, possibilities, strengths and weaknesses of the people, resources, time and circumstances, and finds the best solution that meets every goal within every limit. Every design decision flows through the designer, because they're the one who can judge whether a solution is right, including for marketing, community management and post-launch updates, since those are part of the game experience too.

Then: prototypes where the vision is unclear, to test the parts that are uncertain. Then the real game is built in order, starting with a minimal barebones version that's playable from start to end, however basic, and then adding systems and content, gradually building it up to its intended completion. That's how it's supposed to go, whether it's a solo project, a small team or a big one. The Design Process goes through it step by step.

If you're working alone#

Game design is a skill set of its own, as demanding as coding, art, sound, music, writing, marketing, publishing or community management. If you're making a game alone, you're taking on all of those jobs yourself. You wear both hats, designer and developer, which makes it even more important to know which hat you have on at any moment.

The good news: you don't have to communicate with anyone, which can be draining, slow and difficult. The bad news: you don't have anyone else's skills and resources to help.

To survive it, work smart. Use design thinking on your own working process, and plan a project that one person can actually finish. Use whatever lets you skip slow, painstaking work in favor of faster options.

• Don't try to match the expensive, ultra-detailed custom assets of large studios if you can't afford to make them.
• Don't code intricate systems if they'd take too long to build and be hard to maintain and expand.
• Use shortcuts: asset packs, generators, free or paid services, simple solutions, automation, tools of every kind, anything that gets your game into a fully playable state faster.

The beauty of well-done game design is that compelling games can be made with surprisingly simple, cheap solutions, which more expensive solutions aren't any better than in the end. It is possible to make something amazing alone. (Technically you're still relying on other people, through the tools and services they made, even if you never meet them. Such is the wonder of the digital age.)