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.

This is a followup to this post: Core Cycle. If you haven’t read that yet, read it first.

—-

One of the most important lessons I learned working on the Sims was this: If you can’t communicate it to the player, it might as well be random.

As a new designer, I was excited about developing the most complex, deep system I could imagine. For The Sims 2 on consoles, I’d created a food creation system that had pages of stats that controlled all manner of possible results.

After working on designing the system for a week, I finally showed the lead designer the spec for the system. It had everything! Endless depth! A huge variety of possible results! Little subtle details could affect the outcome in radical ways!

“Simpler.” That was basically the advice I got for how to make the system better.

I was annoyed. The system was flexible, elegant, and deep! Beautifully designed! I mocked the whole thing up in Excel, so that using a simple drop-down list, players could choose from a variety of ingredients and cook them in a variety of ways to achieve a huge variety of results. I’d build the whole system, and show them that it worked!

Huge failure. I mocked up the thing, had one of our in-house testers mess around with it for an hour or two, and the result was clear as day. He had no idea how changing the inputs changed the result. I knew - I knew that a Meat with a Protein stat of +40 instead of +10 would change the result, but there wasn’t any reasonable way to communicate that to anyone - particularly when there were five other stats also changing the results simultaneously.

In the end, the solution was to radically simplify the system. Fewer stats on each ingredient. Each powerup was controlled by a single stat, and triggered at the same threshold for every item. It wasn’t as complex, but it was a thousand times more understandable.

Now, a player would (for the most part) understand that the goal was to pick ingredients that had specific high stats, combine them, and you could get something that would produce a specific power-up effect. Ingredients’ stats were clearly communicated to the player, and the power-up effects had their own visual indicators, and were clearly labeled on the end results. From my perspective, it was almost painfully simple.

The key, though, was that people understood it - they knew how to make repeatable, predictable results, and were willing to “explore” the system because every possible combination produced a useful result.

Players want to be able to understand what is going on. If you get shot in a game, you don’t want to die because you’d contracted pneumonia two weeks before. You want to die because you got shot. This means that the next time, if you don’t want to die, you can avoid being shot - there is a clear causal relationship between the action and the response.

What players want in most cases, is control, or the ability to learn. They want their actions to have consequence, and their decisions to be based on “perfect” information. If X happens, Y will happen. You can make the system relatively complex, as long as players feel that it’s ultimately predictable - like they *could* understand it given the right circumstances, even if they don’t understand it yet.

There is a threshold, however, where a system is either so complex that it’s completely unpredictable, or where a system’s inner workings are communicated so badly to the player that the result seems random - in which case, no causal relationship can be formed, and the result can’t help a player form new decisions. The end result is both frustrating and useless. Not good.

As a designer, you have to go back to the basic razor: “A game is when a user is presented with a compelling choice that allows him or her to make an informed decision that has consequence.”

Randomness means that any decision point associated with that randomness can’t be informed - because it’s… well, random. This makes the player’s involvement with the game essentially meaningless. No information matters. No choices matter, and there’s no consequence that you have any control over.

Again, it comes down to three things - consistency, communication, and consequence. To form causal relationships, the game’s systems need to be consistent. Not “predictable,” where the player understands them so completely that they can predict the result with 100% accuracy - that’s boring. But they have to establish a set of rules, and then communicate them clearly to the player.

And every step of that is helped when your system is simpler.

Next: The Four Stages of Grief.