This is a followup to this post: Complexity vs. Randomness - if you haven’t read that yet, read it first.

—–

So, one of the strangest things I’ve found working in the game industry is that a lot of people don’t really know what designers actually *do*. Hell, even a lot of designers I’ve worked with haven’t ever had a reason to put it into words. In some cases, designers create levels, in some cases, they design systems, but at a higher level, there are a couple major phases that game designers will have to work through in the course of building any game.

Today, I’ll tell you what I thought it was in 2007. In the following post, I’ll tell you why all that has changed in the last two years. But it’s good to start somewhere, so we’ll start here:

Unfortunately, this image was meant to be in a Keynote presentation - so only parts of it appear at any one time. When you see it all at once, it may be a little difficult to understand at first. I call this “The Designer’s Treadmill”. You can call it whatever you like.

The basic jist of it is that you have four major phases in the creation of a videogame:

• Creation of a Pitch
• Preproduction
• Production
• “The Endgame”

You also have four major things that designers will have to concentrate on:

• The Concept
• The Core Cycle
• Progression
• Balance

For each of those phases, you and your team must:

• Conceptualize
• Document
• Iterate
• Test

The idea for the graphic is this - when you create a pitch for a game, you’re trying to come up with something interesting that will grab someone’s attention. An idea that you think can be developed into something fun. Your primary focus during the Pitch phase is the high Concept (which is why they’re aligned on the wheel). You should also keep the Core Cycle in mind, because that’s what you’ll be doing next.

In the process of developing your pitch, you must come up with ideas - you must conceptualize the overall concept of the game. Then, you must document it. This is both for you, so that you’re forced to write things down and make those ideas concrete, and it’s for everyone else, so that everyone knows what you’re talking about. I can’t stress *how* important documentation is enough.

Without having things down in writing, it’s very easy to make exceptions to the rules you’re trying to create. Writing them down means that you can read through the rules, and say, “Hm. This is how the system’s supposed to work - it either accounts for this situation you’ve described, or it doesn’t.” If you handwave your problems away by BSing answers, you will get screwed by yourself. Every time. No exceptions. Write it down. And when you see that things don’t work, fix them here. You’ll still make your fair share of mistakes, but this part of the process will kill a lot of really big stuff that’s easy to miss when you’re only talking about an idea.

Once you’ve written a document, iterate on it. Show it to people. Have them give you feedback. If you can’t take honest feedback, you shouldn’t be a game designer. It sucks - you’ll often have your lovely ideas torn apart. You’ll have worked on things for days, maybe weeks, maybe years, and in ten seconds, someone will bring up something that you missed, or they’ll subjectively hate it. Take it all in. Sometimes you’ll stand your ground, but a lot of the time, this is where your ideas will get much, much stronger by absorbing the input.

Once you’ve iterated, test. Give the pitch to someone. Watch how they react. Take notes. Then do the whole cycle again until you’re happy with the results. If you get it done in one iteration, you’re not being ambitious enough.

The next step, then, is preproduction. Actually, let’s make that the next post, because there’s a lot to say about prepro, and why a lot of people spend a lot of time answering really, really stupid questions.