G.R.I.P.

Design is not a linear process. A game is not assembled piece by finished piece like some elaborate puzzle, much to the chagrin of our managers. The quest for good design is not accomplished through bullheaded determiniation in a forward direction. You can break out your process into as fine a detail you like, but if you think of it as linear steps, then you are wrong.

Design flows in four cycles. They are cycles, not steps, because you spin around inside them, picking up speed, excitement, and eventually, if it passes the test, you fling yourself to the next cycle; where, like before, the process of building up speed continues. Most importantly, if you fail to maintain your speed, you fall back to a previous cycle -- possibly out of the loop completely -- which means that idea didn’t make the cut.

Whether level or system design matters not, nor do the specifics of the system itself matter, as it always flows through the same four cycles: Goals, Research, Implement, Polish.

Goals

When forced to work within a strict framework the imagination is taxed to its upmost — and will produce its richest ideas. Given total freedom the work is likely to sprawl. – T.S. Eliot

You must, before anything else, define what you want. The sea of design is vast, dangerous, and has many a pirate cove waiting to waylay you on your journey, so make sure you got your sails pointing in the right direction -- a phrase I've said many times on the job.

The ultimate goal for any system is to ensure that the player’s hierarchy of experience is being met. The highest step of that hierarchy is Meaningful Choice, and that comes from defining the goals for your system before you start to build.

Goals are only half of the equation, though; constraints are just as important, as every game has need of constraints. Living in the pie in the sky is not as creative and freeing as you think, because it is only through constraints that true creativity is born.

I’m not immune to dreaming big. How many times have you scribbled in your notebook, "gta + elder scrolls + space", which was followed by several fervent scribbles of half-thought systems; I am sure, however, that if you tried to realize that vision it would result in a bloated, directionless, and ultimately bland game. It’s the "best thing ever" paradox. Trying to design the best thing ever usually results in the most boring thing ever.

The point is that you must study and understand your constraints, and they come in many types:

• IP – are you making futuristic or medieval; realistic or fantasy
• Staff – if you think that a staff of people that have made primarily shooters can just shift focus to an action game, then you are horribly, dangerously naive. The kind of staff you have constrains the kind of design choices you make.
• Time – as much as we all wish we were Valve the fact remains that we only have so much time available to us.
• Control – having more mechanics than buttons on your controller is a very real problem, and we are very realistically constrained by the type of control method you have for your game -- especially true in VR.
• Mechanic – some mechanics, while fun, simply do not work well in conjunction with others.
• Core – you must define the core of your game; and, consequently, you are then constrained by those choices. Never bloat your experience, and always ask yourself if you REALLY need a mechanic.

Constraints are not the enemy, as they are a very real part of the process.

Research

Originality lies in the struggle for authenticity, not eccentricity. – Robert McKee

So we know our goals and constraints, and now we start building, right? Nope! It seems like way too many designers skip this crucial step in the process: doing your damn research.

Research is key. All the best designers I’ve worked with have an encyclopedic knowledge of games, movies, books, and television. They just know their shit, and you should too. Me, I collect strategy guides. I have tons of them. My memory isn’t so great, and I knew that, but that was certainly not going to stop me from being the best game designer I could be, so I took to collecting strategy guides. Some are good, some are bad, but every once in a while -- I’m looking at you, Resident Evil 5 guide -- you get one that has some truly meaningful analysis of their own systems, with clear, clean, easily readable maps. Cherish those, and if you are an inspiring game designer, and you don’t study strategy guides, then you are basically the music major that doesn’t study sheet music. Talent only gets you so far, so you must hone your craft through research.

Research is not about letting someone do your work for you, though -- far from it. Yes, part of research is looking for ideas, but the more important aspect of research is context. You must first understand the context of a game’s systems before you use it in your own game, and if you are putting mechanics into your game for the simple pleasure of adding them to the checklist on the back of your box, then you are everything that is wrong with game design. Back of the box designers, as I like to call them, are a disease. Every mechanic must fit like a cog in the great machine, and part of doing your research is to study not only why it works, but also how it fits; and, more importantly, what other systems are tied into it.

Let’s say you are making an MMO, and you are interested in copying the dodge mechanic from vanilla World of Warcraft. Why did they have a dodge mechanic? Well, it’s not because dodging is something you put into your game, just because. No, they have a dodge mechanic because they also have a rogue class, and they require damage mitigation that works for a melee character that isn’t controlled through armor rating. If you remove the rogue class, then you no longer require the dodge mechanic. Really drink that in, because if the context of your game and the context of the game you are researching do not line up, then you should strongly consider if you need this mechanic. That brings us to the ultimate cross roads in the difference between cycles and steps.

Steps move forward, and going backwards is bad. Cycles pick up speed, but if you fail to maintain that speed you fall back, and that’s just what the research phase does for you. If doing research for your mechanic doesn’t get you excited then, just like an electron, you lack the charge to escape! FALL BACK. It’s time to return to your goals and constraints, because chances are you had something wrong. And this is ok!

Maybe, however, everything is falling into place. You are picking up speed, so it is time to jump out to the next cycle.

Implementation

The first draft of anything is shit – Ernest Hemmingway

Fact: the first time you implement anything it’s going to be shit. Which is why it is such a great idea to get things up and playable as soon as possible. It is critical you understand, however, that this phase is not, as much as you would like to to be, the "throw it over the wall and let the programmers take care of it" phase. Please don’t be one of those people. Please.

I guarantee there exists, in some fucked up fashion, a means to build a quick approximation of what you want with the tools you have. It won’t be perfect, and it will look like shit. None of that matters.

The key here is approximation. It doesn’t need to be perfect, but the sooner you can start showing it to others, the better, because it is in this phase, implementation, where you will be doing the most cross checking against the player’s hierarchy of experience, especially feel, and ensuring that your needs are being met. Does it feel good, is the mastery curve just right, does the weapon have a good purpose, and is it providing meaningful choice.

You have already planned for these back in the initial goal phase, I hope, but now we must reaffirm out hypothesis. Things almost never turn out the way we planned, which, because this is a cycle, means that we will spin around in here until the kinks get worked out. If things go wrong, then we fall back to the previous cycle and do some more research, or, eventually, once you are feeling super pumped and things look good, you fire off to the final and most difficult phase.

Polish

In theory, there is no difference between theory and practice, but in practice there is a great deal of difference. – Al Roth

We’re finally here. The polish cycle. It really is a massive amount of effort, and as the old saying goes, the last 10% of the polish takes 50% of the effort. It’s just not a statistic you really, truly believe until you have to see it first hand. It’s crazy talk, but it’s true.

If I had anything to say about polish, of which one could say lots, I would say that the key to polish is ownership. The one thing that peeves me off more than anything is the attitude some acquire in times of great turmoil, which is, when problems arise, to shrug their shoulders and say, "well that’s not my problem."

And, if I can be truthful with you, I am 100% guilty of saying that in my career. It's hard NOT to feel that way when it's late, you're tired, and you just want to ship this damn game.

But, see, actually it IS your problem. It is ALL of our problems, buddy, because we are ALL trying to make a game that matters, right? I fully expect, and appreciate, that if I ever say something like that, then someone would call me on my bullshit. If you don’t give a shit about what you are making, then why are you even here?