Publishers of technology books, eBooks, and videos for creative people

Home > Articles

Game Designers Just Play Games All Day, Right?

  • Print
  • + Share This
Debunking common misconceptions about the job, game designer Zack Hiwiller, author of Players Making Decisions: Game Design Essentials and the Art of Understanding Your Players, explains the breadth of knowledge a game designer is expected to leverage. Learn why game design is more work than play.
From the author of

In the mid-2000s, when I told people that my job title was "Game Designer," I received confused stares and often naïve questions: "So you just play video games all day?" Was it really so difficult to understand what a game designer does? I chalked it up to the newness of the field. Until very recently, the job of "game designer" barely existed. Now game design is offered as a major in colleges all over the world.

I now teach and develop game design curricula at one of those colleges. I assumed when I started teaching that students who grew up with games would have a good insight into what a game designer does. Yet even today, at one campus tour after another, I receive the same muddled answers when I ask prospective students why they want to be game designers. They just don't know what the job actually involves. That happens largely for two reasons:

  • We game designers have done a poor job of explaining what we do.
  • People who want to be game designers routinely ignore the reality of game design because it doesn't mesh with their preconceived notions.

I wrote the book Players Making Decisions: Game Design Essentials and the Art of Understanding Your Players to help students and fledgling game designers get a handle on what's involved in being a game designer. I believe the book will be a really helpful tool to build a foundation based on the reality of what game designers actually do. Most game design books are filled with anecdotal evidence based on a single designer's career. Instead of following that format, I filled Players Making Decisions with citations of research and other published examples to show how the best practices in game design circles relate to research in psychology, economics, and business.

In this article, I'll tackle some of the key misconceptions about game design. Even if you never read Players Making Decisions, this article will give you a better handle on what a prospective game designer needs to know.

Misconception 1: Game Design Is All About Great Ideas

The primary misconception I hear constantly is that the game designer is the "idea guy" (or gal). People think the designer sits in a padded armchair with a glass of brandy, telling all the plebeians these great ideas for the game, and then those peons labor to make it a reality. After all, the ideas have to come from someone, right?

The truth is that no one is going to pay you for your ideas. Everyone has ideas. Programmers have ideas. Producers have ideas. Testers have ideas. The money people don't need your ideas. Ideas are not a dime a dozen—they're actually worth far less than that. Instead of ideas, game teams need people who can create systems that meet targeted aesthetics and are testable. You may very well have the best game ideas anyone has ever seen or heard, but you can't prove that until those ideas are given functional form.

Misconception 2: Great Ideas Always Work

Which brings us to our next point: Designers need to be able to implement their ideas in order to test them. In video games, this means some level of programming and/or scripting. I've lost count of the "great ideas" I had that looked good on paper and turned to dust when they were actually tried.

Misconception 3: Players (and Programmers) Follow Your Lead

Humans are notoriously tricky problem solvers. They rarely do things in a predictable way. That's why games are developed through an iterative process. We create prototypes and test them with real humans to see what they do and how they feel when using those prototypes. That data then informs our next iteration, and we keep looping until we decide that the game or feature is done.

You can't really predict the results of real human playtests until they happen. If you knew what people were going to do, you wouldn't need to test.

I mentioned earlier that programmers have their own ideas. If the programmers could solve the problems and implement the solutions of their games, why would game companies need designers? The concept of the "idea guy" is a joke in the industry and in education. It's shorthand for a person who wants the power of directing a game without having to put in the actual work required to make the thing.

Misconception 4: Because You Play Games, You Know How to Create Games

Programming can be difficult, and it's certainly scary for people who are completely new to it. Developing digital games requires you to adapt to an entirely new way of thinking, complete with its own nomenclature and symbology. This fact scares off potential designers who want to skip straight to being the "idea guy." But the only "idea" people who still exist in the industry started out by implementing and testing concepts so well that they received the trust to establish those jobs. Everyone can learn rudimentary implementation skills, and that step is required in order to understand the scope, application, and edges of your ideas.

Analog games like board and card games have a similar prototyping and development process. It doesn't require programming, but it still needs rigorous development and iterative testing. There is no avoiding the step of putting your work in front of people in order for them to tear it to shreds. No creative endeavor escapes this process. There is no role for a person to come up with the "idea" for an invention. The inventor actually has to make the thing, test it, and find a market for it.

Ready for Reality? Here's What Game Designers Really Do

A game designer creates game mechanics to meet certain goals. Those goals could be based on game dynamics ("We want players to fight over this spot on a game map"), or aesthetics ("We want players to feel scared here"), or be project-centered ("We need a level where we can use all these set pieces again").

How a game designer solves these problems is unique to the type of game being developed and the circumstances of the team. However, there is usually a workflow to the process of game design that roughly follows the scientific method. Designers identify the problem, hypothesize a possible solution, implement the solution (sometimes with help), test that solution by involving real potential players, and then evaluate how successful (or unsuccessful) the test was. This process requires a broad set of skills beyond what the common preconceived notions of the occupation entail.

Truth 1: Game Design Is All About Solving Problems

A game designer solves problems. These problems could explore something as large as the mission statement for a game, [1] or something as rote as figuring out why players don't notice a particular quest area. [2] The game designer helps to direct the work and effort of team members with more specialized knowledge, in order to best solve as many problems as possible in the process of building the game. For instance, if the designer's video game runs at an unacceptably low frame rate, the game's engineering team puts their specialized knowledge to work on solving that problem.

Truth 2: Game Designers Need Knowledge (Not Just Ideas)

The game designer's specialty is—literally—everything not covered by someone else on the game design team. Let's consider some examples:

  • When a team doesn't have producers, the game designer has to understand how a software project is structured and managed. [3]
  • The designer has to understand the mathematics of systems. Why does the player who chooses the sword always win? [4]
  • The designer has to understand the psychology of players to understand how their decisions shape their experiences. [5]

Game designers need a working knowledge of composition, rhetoric, drafting, architecture, art history, philosophy, economics, business, history, education, mythology, and many other disciplines. Why does a game designer need to know all this? If not the designer, then who? [6]

You can see why teaching game design can be difficult, and why writing a useful book about game design seems next to impossible. The goal of Players Making Decisions is to develop the game designer's intellectual curiosity so that he or she will seek out all those little facets of human knowledge that can then be leveraged in a game. That internal "game library" in the designer's mind grows at whatever speed the designer can learn.

The Final Truth: The Market for Game Designers Is Huge But Narrow

Many people want jobs as game designers. By the laws of supply and demand, salaries for game designers are lower than that of people with similar skill sets in less oversupplied fields. Even with the massive pool of applicants, many software design studios have a hard time finding employable talent. Professional game design takes passion, a willingness to learn, a willingness to both be wrong and be told you're wrong, and a knack for persuasion. Professional game designers have to be able to add value to a project at all stages, test their ideas, be honest about the success or failure of those ideas, objectively analyze a market, and apply a laser focus on the tiniest details.

Designers need to be able to navigate the choppy waters in a market where, for instance, 11,000 games were released in a single month in the Apple App Store alone. The designer has to be able to make a project both internally consistent and successful, and be ready to battle for consumer dollars in a blood red ocean.

You can see why "idea guy" is a joke that's not really funny.

Reference Notes

[1] Players Making Decisions addresses game problem statements in Chapter 2.

[2] For attention and memory issues, see Chapter 27.

[3] For details on project structure and management, see Chapter 3.

[4] System mathematics are covered by Chapters 19–22 and Chapter 29.

[5] The bulk of the book is about player psychology and experience, but those topics are covered in detail in Chapters 23–27.

[6] Chapters 28–32 address designer and team communication.

  • + Share This
  • 🔖 Save To Your Account