I was talking to someone today, and ended up looking for a specific image I'd made a long time ago. In the process, I happened upon this document, and even though it's six+ years old, it's still full of stuff that might be useful to an aspiring game designer. It's something I wrote as a companion to a presentation I gave back when I was working at Factor 5. The goal was to try to help the rest of the company understand what a designer does, how they make decisions, etc. in order to help better some communication issues the teams were having. With some minor edits, here it is:
This class began simple as “An Introduction to Game Design.” When I started putting it together, I thought, “What does that mean?” Do people want to know what we do from day to day? They see that, in theory, every day! The idea behind this class was to instead give people some insight into how designers think – the kinds of tools we use that they may or may not see, and how we look at games, with the hope that it’ll foster communication. In the end, I hope it also forces everyone in the company to hold designers to a high standard.
So to that end, the simple answer to the question of, “What do game designers do?” is quite simple – we design games. But what is a game? There are dozens and dozens of definitions of what a game is. In the end, none of them matter all that much. The heart of the answer is quite simple – we design interactivity.
The thing that makes a game a game is the user’s interaction with it. The controller – whether a joystick, keyboard, mouse or mind-reading hat.
So, what does interaction mean? Here’s a definition. It’s a lot like Sid Meier’s definition of what a game is, though only game-design dorks will actually care. Still, that’s it? Seems awfully reductionist. What about story? What about graphics? What about blowing stuff up in awesome ways?
There you go. In those six phrases – Narrative, Risk, Reward, Presentation, Systematic Consistency and Progression, all of which tie into making decision points compelling, informed, and consequential – you have everything else that makes a videogame a videogame.
Where’s the decision point in Rock, Paper, Scissors? If statistics show that the results can’t possibly be random, how are players making decisions?
If you look at the way people play RPS, any single instance really is almost a random result generator. But over time, you begin to notice trends. You try to place yourself in the mind of the opponent. You use history and body language to try to predict the result. Some people are good at it, some people are not. Adding some risk and reward to the mix – playing RPS “for” something, like driving to lunch, adds a layer of consequence and reward to the mix.
The point is that the decision point – the “game” of RPS – isn’t in the moment when you throw the result. It’s in the moments prior to the action, when you’re trying to find any piece of information you can use to make a better decision. RPS becomes a real “game” only in aggregate, when the players can accumulate data on their opponent to begin making informed decisions.
Now, compelling decision points where the player is well informed are fine and dandy – but decisions without consequence are fundamentally meaningless. Consequence, functionally, is feedback. Get something good for a good decision? Great example of positive reinforcement. Bad consequence for a “Good” decision? Not good feedback. Essentially, if it’s not one of the four above feedback types, it’s not feedback that matters.
Just as an aside – one of the major “lessons” of the meteoric rise of casual gaming is that the good casual games tend to mitigate all feedback types except positive reinforcement. This eliminates what’s called “Avoidance Learning,” where people learn to not do things out of fear of negative reinforcement. Jump off a cliff and die? You’ll be a lot more cautious about jumping off other things. By working to eliminate negative feedback, you encourage exploration, risk, and discovery.
That said, there is a definite benefit to the threat of punishment. Living on the “edge” is exciting and fun. Eliminating these forms of feedback altogether has definite downsides. But the current lesson is that for the mainstream audience, games have been focused far too much on punishing bad behavior.
The things that make feedback matter the most are immediacy and consistency. When you’re teaching a dog to sit, if they sit on command and you give them a treat, they quickly form an association between the treat (reward) and their action (sitting). If you tell them to sit, they sit, and you give them a treat ten minutes later, no association is made.
Similarly, if you give them a treat some of the time, and you slap them some of the time, they don’t make any positive association with sitting – sometimes it results in a reward, sometimes in punishment, and the causal relationship appears to be arbitrary. That’s really bad – both for the dog, who’s confused, and you, who are trying to teach them something. Players – hell, almost everyone in every situation – respond to feedback in exactly the same manner.
Feedback’s effectiveness also depends on how much the player wants or fears the reward or punishment (respectively). If a player has a million gold pieces, giving them 1 gold to slay the evil dragon is the same as giving them nothing. If they have 1 gold and you give them a million, they’ll go slay the dragon.
In an ideal world, the magnitude of the feedback should also be proportional to the risk.
Why does feedback matter? Because games aren’t long strings of events that never repeat. Games are functionally a small collection of mechanics that repeat again and again. You have to teach players to play well.
The Core Cycle is the closed loop between execution of action and feedback. Here’s an example – the 30 seconds of fun in Halo:\
A player enters an area, makes some assessment of the threats in the area, plans their approach, shoots a bunch of stuff, then takes their downed enemies’ weapons. They then move on to the next area. This process repeats over and over from the start of the game to the end. The key is that the cycle evolves.
As players loop through Halo’s core cycle, or the core cycle of the Sims, the loop evolves. The basic actions remain the same, but the actions themselves change. In Halo, you acquire new, more powerful weapons. The environment geometry changes. Enemy placement and enemy type change. Your ability to move changes (you get new vehicles at times), and therefore, the way you kill things changes as well. The entire chain of events, over the course of the game, evolves.
A counter-example is Lair. As the player progresses through the game, they can earn medals/Carnage, which unlocks new melee moves. But the core mechanics don’t actually describe Fight Mode, because it’s not necessary, and not something that the player does on a moment-to-moment basis.
As the player earns Carnage, and unlocks new Fight Mode Combos, the core cycle doesn’t evolve. As a flight game, the environment changes, but not in a way that affects how the player flies around in any substantial way. The targets do evolve over the course of the game, but the vast majority of enemies available in the game have been exposed by the third or fourth mission. Killing stuff consists almost entirely of “Dumbstrike” attacks and fireballs, neither of which change substantially over the course of the entire game. The Carnage values earned via these attacks never changes, either.
So when you play through Lair, it becomes repetitive. The 30-second(ish) loop the player experiences repeats over and over, but never evolves to mask the repetition.
An effective core cycle needs two major things: It needs to be fun in one instance, and it needs to evolve.
One quick rule to note, before we get into the meat of things. The Rule of 10 is something that almost anyone in Manufacturing learns quickly. If you have to make a change, the earlier you make it, the cheaper it is. At every stage of the process, (and the graph doesn’t reflect this accurately) the cost increases by a factor of ten. So when you move from preproduction to full-blown production, if you have to make a change, the change will cost ten times as much. The designer’s job is to make the mistakes that need to be made early.
That’s it. That’s a game designer’s job. Through the different parts of the development cycle – Pitching, Preproduction, Production, and what I’m calling the “Endgame”, they will repeatedly Conceptualize, Document, Implement and Test. This center cycle is the designer’s “Treadmill” – they will run on that through the entire course of development, on every stage of the process.
During the Pitch phase, the primary focus is the game’s core concept. This isn’t simply saying, “It’s a game where Zombie Unicorns fight Zeus with their rainbow-beams!”
As much as I wish it was the case, a Game Designer’s job isn’t simply to “create fun.” Unless you work at one of the very few companies in the industry with an effectively unlimited budget, the Game Designer’s job is to create the “most fun for the money.”
If developers could create everything, there wouldn’t really be a need for a designer. A designer’s biggest job is to find the best subset of reality to simulate under the particular constraints of time, budget, and manpower.
Colin Chapman, the founder of Lotus, said the things above. Sounds pretty salient to me.
To be a bit more straightforward about it, the last point is really key. Piling fun features on a game whose core cycle isn’t fun doesn’t result in a fun game. Cut away anything that isn’t in the core cycle, spend the resources making the core cycle really pop, and now you’re getting somewhere.
Here’s a simple game – Wii Sports Baseball. There are a lot of things that make baseball fun.
Almost all of them aren’t in the game.
Wii Sports Baseball contains the minimum set of things that are awesome using the motion control of the Wii Remote and nothing else. By focusing on making that core entertaining, and applying that concept to multiple sports, they’ve made a masterpiece that revolutionized the industry.
The other main thing that a designer will have to do during the pitch phase is to clearly document their ideas. You might have the greatest ideas in the universe – stuff that makes Will Wright look like an incompetent buffoon – but if you can’t communicate them, they don’t exist.
So, you practice writing – you learn to describe things in florid detail, and so you write stacks of documents. Genius stuff that would move a reader to tears of ecstasy. No one reads them, and once again, your ideas don’t exist.
Functionally, your documents have to grab a reader’s attention. You might think that it’s your coworker’s job to read your documents and understand them. To some degree, you’re right. But it’s the designer’s job to write accessible, understandable and engaging documents. Think of it as a game – you’re trying to “hook” the reader and then keep them engaged.
Pictures can do this – reference images, diagrams and the like. But they’re also not as precise as words, which can go into greater detail. Balance precision and immediacy. Use your reference images to get readers interested, then twist those into something new and make your ideas clear with well written text.
Here’s one way to quickly communicate a lot of information. It’s also a great way for the designer to actually plan out the game’s core mechanics. This is a System Diagram. In the boxes are the core mechanics of the game. While brainstorming, designers might draw up a simple cloud of boxes with different potential mechanics.
The next stage is to figure out how all those stages connect. Strike, and it drives the character back? Draw an arrow from “Strike” to “Movement,” and label it with the fact that it’s a backwards movement. Repeat with every possible connection you can come up with. The end result will look like complete spaghetti nonsense.
After this stage, once all the mechanics and connections have been brainstormed, the next job is to reduce and reorganize. The designer(s) take the core mechanics and move them around – the main things the player does most go in the center. Things that they do less are moved progressively out from the center.
Connections are reorganized, trying to create a diagram with the most aesthetically pleasing look. I know that sounds like a trivial way to organize a diagram, but conceptually, it makes sense. Players want to understand the connections between these systems. Visual simplicity, in this case, is the same as organizational simplicity. If it works in diagram form, and is easily understood, the player will understand the core mechanics and how they work together.
This doesn’t mean the core mechanics are all simple themselves – but it means the relationships between mechanics are.
Another thing to consider is balance – it’s not just about drawing the most arrows connecting the most systems. If you have a system with many arrows going out from it, it’s a clear visual indicator that this system affects many things. If it has no input arrows, though, nothing affects it! This is usually a bad state. If you have an attack, for instance, that has no input arrows, how do you stop someone from attacking? This might prompt you to add something you forgot – block. If that’s not enough to balance things out, think of other ways to stop attacks – dodge, parry, etc, and use those to create a good balance.
“A good balance” doesn’t necessarily mean # of inputs = # of outputs. It means that the total weight of the inputs equals the total weight of the outputs. If you have one easy-to-execute, powerful counter to an attack, it might be enough on its own to balance three or four separate-but-lightweight outputs.
This is where a designer’s sort of discretion can be quite useful, and experience will help you understand how to weight these things beyond any simple rules of thumb.
Another tool at the designers’ disposal is what EA calls “Finding the X.” This is basically a one-sentence description of the entire game that communicates its core message quickly and easily. Ideally, it’s the kind of sentence anyone on the team can internalize and use as a reference for what’s important to the game and what’s not.
It seems, again, like a trivial thing. But each word needs to be carefully pored over. Should we add a cover system to Cyclone? Is it “kick-ass”? Maybe? Is it “hyper-agile”? No, certainly not. Does it help you “gun and run”? Gun, maybe. Run, absolutely not. Is it “with style”? Could be. All in all, just by reading through that sentence, you can get a pretty clear idea that a cover system isn’t necessarily useful – or even better, what a cover system would need to be to be appropriate for this kind of game.
It might be appropriate if you can take traditional cover mechanics, use them to encourage hyper-agility, and to allow the player to gun and run while in cover. Such a thing is not impossible, but just that thought might spur someone to a creative solution that fits the core of the game.
There’s that hamster wheel again. You’ve spent a bunch of time trying to find the core mechanics and the core idea of the game. You’ve spent time documenting everything. Then something comes along:
This piece of art took what we knew about Cyclone and brought it to the next level. The sense of speed, the unique pastel color palette – these things made us re-examine core aspects of what we thought we knew about Cyclone, because this image adhered better to the ‘X’ than what we’d previously created did.
Is that a bad thing? ABSOLUTELY NOT. It meant we went back and made everything better. We iterated on the core concept, and it became stronger and more compelling. We continued to do that several more times, and the end result was even better as a result.
Being a designer isn’t about having all the best ideas. Being a designer is about finding the right ideas for the project, wherever they come from, and absorbing them into the concept. Give credit to the right people, don’t be a dick, and the level of involvement, ownership, and creativity from everyone will go up as a result.
Where the Pitch phase of the cycle focused primarily on the Concept, and partially on the Core Cycle, the Preproduction phase focuses primarily on developing a strong Core Cycle, and partially focuses on just keeping in mind how Progression will be built into the game. The two major things designers will be focusing on during this phase are codifying the game concept in clear documents, and prototyping the hell out of the Core Cycle.
During Preproduction, designers should be writing a LOT of documentation. Just as in the Pitch phase, this is all about communicating ideas quickly to the team. Yes, the process is iterative. Many of the documents will change quickly. But here’s the key: until you write something down, it’s not concrete. It’s easy to subconsciously (or even willfully) gloss over details that don’t work because your mind isn’t willing or able to work out inconsistencies.
Writing things down forces you to confront things that don’t work – in part because you’ll be unable to write down things that are obviously at odds with each other, and in part because once they’re written down, other people can point out how ridiculous something is.
That’s fine. You’ll make mistakes. Lots of them. This is the period where making mistakes is relatively cheap. If you see an error, and you assume it will get fixed later, this is a huge recipe for disaster – remember the Rule of 10!
It’s also easy to get personally wrapped up in an idea. This can cause you to hang on to something long after it’s useful to do so. Part of being a good designer is knowing when to let go. If something isn’t working, take a step back – put it off and try something else. When it’s done right, preproduction HAS to allow for iteration.
A second point, and one you might find ironic if you’re reading this – keep your docs short and to the point. Bulleted lists where possible, images where you can, and expanses of text only where absolutely necessary.
Here’s a simple example of a character movement diagram. This shows, in theory, everything that was necessary for Cyclone’s main character’s movement. This was something that was written down relatively early in the preproduction process, and was iterated on several times. This allowed everyone on the team to see what the designer was thinking was required, and to give feedback on it before any investment was made getting the mechanics in-game. Iterating on this was a five minute process, and we were able to go through dozens of iterations cheaply and quickly. It was, in essence, a prototype for the character’s movement scheme.
Which brings us to a point about prototyping. Prototyping isn’t a way to make a bad, broken version of your final game quickly. Prototyping is functionally about taking your highest-risk questions and answering them in the right fashion. Have a game where the character movement is just like another game? Don’t bother prototyping it – you know it’ll work eventually. Prototype the core mechanics – things in the core cycle – that you don’t know will work. Things that are new, or different. In the end, you might also have to implement things like basic character movement, but that’s not the default! That’s a side result of trying to answer the right question first.
This kind of thing doesn’t have to be in-game, but it helps if it’s “playable” in some form. This can be anything from taking a turn-based strategy game and playing the rules in a card game format, or it can be building an environment quickly out of LEGO and running little LEGO guys through it. As long as it answers the right question properly, find a cheap, fast, iterative way to come to a solution.
Here’s the thing about failure, and it sounds trite: If you’re not failing, you’re not trying hard enough. Games are, at this point in the industry’s history, still a developing medium. Much of their appeal comes from surprise and unpredictability. If you can imagine every facet of a game and get it to work right the first time, so can the player. As a result, it won’t be surprising or unpredictable. It’ll be boring – a ripoff or derivative of something that’s come before.
So fail. Fail often. But fail early. Fail when (remember the Rule of 10) it’s cheap, and the impact on the project is low.
A second point – when you fail… walk it off. Seems dumb, but I’m serious – get up, walk around – go outside, and get away from the problem for a bit. When you get carsick (bear with me), you feel nauseated because the balance mechanism in your ears doesn’t agree with the visual input you’re getting from your eyes. The disagreement hits your brain, and it causes your brain to think you’ve been poisoned. The sinking feeling in your gut? The sick feeling that makes you want to barf? That’s caused by this disagreement. Your brain’s trying to get your body to expel the poison that’s caused the mental picture you had of your system and the awful reality to disagree.
The problem, of course, is that reality’s right, and your mental image was wrong. That’s fine – you can make those two things agree – but it’s hard when you’re not feeling well. So get up and get away from the problem for a bit. Let your stomach settle, and think about what happened. Why do they disagree? How can you make them agree?
Obviously, you didn’t start with a concept you thought would fail, so where did it go wrong? How can you make it succeed? When you get the picture in your mind and the reality to agree, you may still be disappointed, scared, upset and frustrated, but at least the physical nausea will disappear.
Use the failure to figure out how to make things stronger. It’s a step in the right direction – a temporary, unpleasant one, but one you probably needed to take.
There’s a lot to say about the production cycle of development. I’m not gonna dwell on it, because frankly, it’s another huge topic on its own.
One of the main things to consider is that Production is where you focus on Progression, and keep an eye on tuning and balance. During preproduction, you’ve tested and iterated on your core cycle, so hopefully by now, you know where the core “fun” experience is.
During Production, you want to now figure out how that cycle evolves over the course of the game. Sometimes, that’s in weapon and level design, sometimes it’s more systematic. It depends on the game – so much so that it’s even hard to talk about absent a concrete example. So we’ll skip that for now.
Just keep in mind – the focus is progression and evolution of the Core Cycle.
The “Endgame” comes after most of the content is made – when the designer starts to tune and balance the game. Balancing generally consists of a designer looking at a giant wall of tuning variables, and poking it until it plays well.
This is a difficult process – at its core, you want to tune the game to really be focused on the core concept of the game. If the game’s about kicking ass, don’t make the easy enemies hard – make the player feel powerful. If the game’s about feeling weak, don’t make the easy enemies easy – make them difficult! Sure, it’s obvious, but it’s really easy to lose sight of the core concept of the game. Go back to the X, and make sure that when you’re balancing, you’re balancing the game in such a way that emphasizes the core!
Now, you’ve given it your best shot. You think the game’s feeling great, that it’s got a good progression, a good reward structure, that it’s communicating things clearly to the player. Awesome. Good job. Now step away from the game. Get someone else to play it – someone new.
You’ll find they get confused, certain parts are incredibly difficult, things you thought were trivial get them stuck for hours at a stretch. They don’t see the same game you see. They don’t see the potential brilliance – all they see is what is.
You, on the other hand, don’t see reality anymore. As a designer, you know how the game works. You know how to exploit its little things, how to avoid annoyances, how to make the game work right. They don’t know any of that. They don’t see the potential. They don’t know anything other than what the game tells them.
Believe them. They’re right. They’re not here to make you feel bad. They’re not here to knock you down. They don’t know how long it took, and how hard you tried. All they know is what is.
You can’t. You’ve lived with the thing, both in your head and in your hands, for far too long. You have to get a new player’s input. Get it as early as you can – as early as you can to answer a concrete question about the game. Is this mechanic fun? Is this communicated well to the player? Where are players getting stuck? These are questions, as a designer who’s worked on the game, you can’t answer any more.
That’s fine – that’s human nature. If you couldn’t internalize the thing and work around the frustrations, you’d be a defective human being. But you have to realize that that’s the case – that your instincts are shot, and your feedback at this point is functionally useless.
Once you’ve realized that, and you’ve accepted that the feedback you’re getting isn’t meant to personally destroy you, and that their confusion/frustration/boredom is sincere and honest, you’re well on your way to actually being able to see the problems with your game… and fix them.
Functionally, that’s the core of what we do, as designers, when we’re doing our job well. Focus on the core, cut away everything else, and make sure the core mechanics are fun, evolve over the course of the game, and allow players meaningful, informed, compelling interaction… that kicks ass.
It's a little bit surprising that even six years later, almost all of this still feels right to me. The things that I think are more important are the "iterating fast" part - making mistakes, learning from them, focusing on answering the right question in the best/cheapest/fastest way. The other thing is that there's a whole presentation that should now go after this one that is basically, "Oh, you shipped a game? Great, now your work is JUST STARTING. Hahahahhahaha." Maybe one day I'll put that together. It's a new skill that a lot of us are just learning now, but some folks have been doing it for a very long time (Everquest, anyone?). But there's something really distinct about the pace at which you can iterate live now, and being able to shift from a "shipped-once-and-done" to a "continually evolving" experience is a huge change. It doesn't change any of the underlying design skills, which is why this doc is still useful, but it does change how you weigh a lot of the decisions you might make, and the push toward faster, bolder experimentation goes a lot further than most people might think.
Anyhow. If this is useful to you, please let me know, and please feel free to share with anyone. Thanks for reading!