Last week I had the privilege of speaking to students at Cal Poly in beautiful San Luis Obispo. Many of the students are just beginning their journeys to become game designers, so I took the opportunity to share my own experience from consumer to creator. I also talked about how game designers of various skill levels conceive of games and approach game creation.

No matter what level of game designer you are, I hope taking a broader look at the process will give you some insights on how to make your next game even better!

The Creator’s Journey

Stage 1: Consumer

We all begin our game designer lives as game consumers. Most children play games, and for many people games are significant and meaningful. If you want to make games, you probably already love games.

To consumers, game design is pure magic. Consumers believe that a game designer imagines a game, then creates it exactly as he or she envisioned it. (That’s not how it works, fyi.)

Stage 2: Tinkerer

Games like Little Big Planet and Starcraft offer their players an awesome gift: a level editor. These allow players to get involved in a whole new way. Almost any non-digital game can be tweaked in this way, and programs like Magic Set Editor make it especially easy.

Tinkerers tend to imagine new games in terms of modifications (often additions) to existing games, sticking closely to their underlying rule sets. Tinkerers begin to realize that game design is not magic, but it is a lot of work.

Stage 3: Masher

At this point, the designer is creating entirely new games, but the design process tends to involve mashing existing genres, mechanics, and themes together.

Mashers envision new games as collages of existing game components. They tend to focus on the mechanics and theme rather than on the player experience.

Stage 4: Creator

Before long, a game designer will shift his or her focus and work style. Instead of having visions of a specific game, the designer will be interested in exploring broad or incomplete ideas: the way reflections ripple on almost still water; the way that digging through a discard pile can return to the past; the way it feels to end a date by watching the sunset together. The ideas can be about theme, they can be about mechanics, they can be about player experiences… really, they can be about anything.

What’s important is that the ideas do not make strict, specific demands on the final game. In fact, designers at this stage approach new games with a healthy emotional distance. Obviously, they are excited by their ideas, but they know many ideas never work out, so it’s dangerous to become attached to an untested one. They also know that the initial conception is very rarely the best implementation, so keeping an open mind and keeping nothing sacred will tend to result in better final games.

By this point, designers should have discovered and embraced the iterative design process, an extremely useful tool for guiding game design.

The Game’s Journey

Every game takes its own journey from concept to product, but skilled designers use the iterative design process.

Ideas

All games start out as ideas. Some games come from one powerful idea, but most are formed by combining many ideas to create a unique whole. It’s very possible that initial ideas will be (or should be) abandoned, and lots of new ideas will be considered during the process.

Advice about ideas:

– Come up with more ideas than you’ll need.

– Never rule out an idea as bad until you’ve tested it.

– Never accept an idea as good until you’ve tested it.

– Do not get emotionally attached to ideas.

Planning & Prototyping

Once a designer has promising ideas, it’s time to test them. Here, the keys are minimalism and focus.

Your playtest (coming up next) is an experiment, so be prepared for it. Identify what the most important questions you want to answer are and figure out the quickest way of discovering those answers.

Your questions will change as your game develops. Here is the typical progression of questions:

1. Potential: For your first prototypes and playtests, identify the core ideas of your game and test them as simply as possible. Do they have potential? Do they seem interesting and fun?

2. Requirements: You will almost certainly have more ideas than should be in your game. Early on, determine what your game actually needs.

3. Problems: Throughout the process, identify problems and attempt to fix them.

4. Accessibility: Some people might play your game over and over, but everyone who plays your game will play it for the first time. Make sure people can easily learn your game without your help.

5. Balance: It’s essential that your game has no dominant strategies or options that are so bad no one would ever want to use them. Don’t worry about this until you’ve solidified your basic game structure.

6. Aesthetics: For most games, you will not want to worry about how they look (and sound and feel) until everything else has settled. That said, games often need a bare minimum of art to concisely communicate the game state to players, and some games (very few) have aesthetics at their core. In these cases, test aesthetics earlier.

Create a prototype that answers the questions at hand. Resist the urge to add anything else to the prototype. You will often need some supporting structure to test what you need to test, but that extra stuff should only have a support role–don’t waste time on it.

If your goal is to honestly test your game (as opposed to promoting it or looking for praise), it’s better for your prototype to be ugly. It needs to be functional, but investing time and energy into making it look nice will leave you less willing to change it.

Here are some tips for planning and prototyping:

– First thing’s first: figure out what you need to know about your game. These are your questions.

– Design your prototype to answer your questions.

– Don’t include anything in your prototype you don’t need to answer your questions.

– Your prototype needs to be functional, but it shouldn’t be pretty.

– Don’t get emotionally attached to your prototype.

Playtesting

Playtesting is how game designers get real information about their games. Empirical evidence is vastly superior to intuitive judgements, especially judgements tainted by pride. Playtesting allows you to gather valuable data so you can make informed decisions.

When you playtest, your goal should be to answer questions you have about your game. Take your playtest seriously. Write down important information (how long the playtest took, scores throughout the game and at the end, very good or bad experiences, etc). Write down feedback from your playtesters, and honestly consider it. Don’t accept it as dogma, but don’t reject it outright.

Taking criticism is a skill that many of us lack. When playtesters have negative things to say, remember that it’s about the game, not you. Don’t interrupt your playtesters, don’t get defensive, and don’t tell them they’re wrong, even if a playtester is technically wrong. Remember that perception of your game is as important as how it actually works.

When playtesting:

– A playtest is not a way to boost your ego. Take it seriously as a way to gather information.

– Focus on the questions you want to answer. Don’t waste your playtesters’ time by asking them to do irrelevant things (like play a part of your game you’re not testing).

– Take notes so you can compare relevant information between playtests.

– Take the feedback from your playtesters seriously.

Evaluation

After you playtest, consider your data. How does it answer your questions? If you were testing the quality of an idea, did it pass the test, or should it be thrown out? If you saw problems, what caused the problems, and what can you do to fix them?

Evaluation is difficult because there are no hard and fast rules. The data may be quantitative, but your interpretation is subjective. The more information you have to make you decisions, the better, but the information will never make your decisions for you.

Knowing when to give up can be difficult. Throwing out ideas is a natural part of the game design process. Not every idea will work, and you won’t know if an idea will be good or bad until you experiment with it. When big problems persist, it might be time to put the idea aside. You can always come back to it later; sometimes, a break is all you need for a fresh perspective.

Knowing when a game is finished can be even more difficult. A game is never finished, it’s just due. But you often won’t have external due dates, so it can be tempting to go on making tiny tweaks ad infinitum. Eventually, you’ll have to accept that a game is as good as it’s going to get. I look back on every game I’ve released with both pride and embarrassment since there are so many things that could have been better. But I couldn’t look back on them at all if I hadn’t eventually released them, imperfect as they may be.

Why All the Fuss?

Prototyping and playtesting allow you to test the quality of your ideas. That’s really important for a number of reasons:

– Ideas are extremely plentiful, but most of them suck. It might not seem like they are so abundant when you start coming up with game ideas, but with time you’ll have more ideas than you know what to do with.

– Most games require many, many ideas, so you’re going to need to evaluate many moving parts and systems. Bare bones prototypes can help you test these in isolation.

– Turning ideas into a game takes a lot of time and money (as indicated by my own experience with Corporate America). Make sure you invest your resources into something that will be worth it.

– Even if your initial prototype is awesome, that particular implementation probably isn’t optimal. Experiment with similar (and very different) alternatives to look for a better option.

An Ongoing Journey

This post has followed my own personal journey to becoming a game designer, but I believe most game designers follow a similar path. Where are you on the path? Perhaps this will help you avoid some of the mistakes I’ve made.

Before I go, I want to emphasize that we all have the potential to grow and improve, just like our games. After giving this talk, I took the opportunity to evaluate one of my current projects, Factions (described briefly towards the end of this post). The game is far from complete, but it has been heavily tested and shows a lot of promise.

However, I realized I’ve been guilty of a beginner mistake: I’ve tested the game with many frills, but still don’t have a great grasp of the core. Writing this has inspired me to create a bare bones prototype to get a better understanding of what makes the game tick. This should help with balancing and should also provide a more robust skeleton those exciting special rules will eventually flesh out.

Here’s hoping that this perspective inspires you to approach your current project in a new way too.