Tips From A Combat Designer: Get a G.R.I.P.

[In this reprinted #altdevblogaday piece, Vigil Games' senior designer Mike Birkhead continues his "Tips From a Combat Designer" series by going over the four cycles of game design.] 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. There is something compelling, though, in that mental image of an elaborate puzzle, but the quest for good design is not the quest for that single piece that you think might fit, and if only you searched hard enough you will find it. This gap between mental image and reality is hurting us dearly in the realm of game design, but it hurts, most of all, when it comes to planning and scheduling. 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 doing it wrong. Design is not linear, my friends, because it 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 out of that cycle to the next; where, like before, the process of building up speed continues and, most importantly, if you fail to maintain your speed, you fall back to a previous cycle — possibly out of the loop completely, which means, guess what, that idea didn't make the cut. Wether 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.

Defining Your Goals

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. The ultimate goal for any system is to ensure that the player's hierarchy of needs are being met, which, for me, means running through my checklist of the 5 Layers of Player Satisfaction. We will cover the first layer, implementation, in a second, and the second layer, feel, will come into play in the cycle after that, but for the remaining layers — mastery, purpose, and meaningful choice — we can begin to plan for them now. The ultimate goal is a fun experience, and a fun experience is crafted through ensuring the player's hierarchy of needs are being met. 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, "omg gta + elder scrolls + space", which was followed by several fervent scribbles of half-thought systems; I am sure, however, that if you actually 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, but that's another post. The point is that you must study and understand your constraints, and they come in many types.

Constraints are not the enemy, my friend, as they are a very real part of the process; and, ultimately, if you feel that constraints limit your creativity, then I can safely say, with full confidence, that you lack a single creative bone in your body. Deal with it.

Do Your Research

So we know our goals and constraints, and now we start building, right? Nope (Chuck Testa)! Pull back on those reigns buddy. Good designers know that it is execution and not innovation that really and truly keeps people engaged, but it seems like way too many designers skip this crucial step in the process: doing your damn research. I have written before about my feelings on ideas and stealing them. It is simply not a concern of mine, and, if current games are any indication, most designers live in fear of stealing. [Rant Mode On] Let's get real here for a moment. There is proof abound of this in our industry, but one particularly relevant example exists in Gears of War. One game session of the active reload system, and I knew I wanted it in every game after that. Every. Game. This was the mechanic. Screw cover based shooting, THIS, was the mechanic. Cliffy, if you are reading this, I know you agree with me, and I feel you bro. Seriously people, if I reload a weapon I want that system. How is this even a debate? It's gaming at it's most serene. Gamey, yet not too gamey, with an added element of timing and skill to an otherwise mundane activity. THIS WAS THE STICKY NOTE OF SHOOTER MECHANICS. Brilliant, simple, and the second you saw it you wondered how you had ever lived without it. How in the hell are we all the way to the end of the generation with no one else stealing that mechanic Of course people are going to say, "oh you stole that from Gears". Yeah, well, you know what? Fucking duh buddy! Man up and steal shit, people, because your game being shittier is not a defensible position in the war of originality. [Rant Mode Off] I feel much better.

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 god damn 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 cancer, and they have no place. In games that matter, it is a given that every mechanic fits 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 really start considering wether you really need this mechanic; which, my friends, 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. Starting Implementation

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, of course; it will look like shit, undoubtedly; and if you show it to anyone they will give you that look, you know the one. None of that matters. The key here is approximation. It doesn't need to be perfect, but the sooner you can start running it through your checklist the better. What checklist is that, you ask? Why the 5 Layers of Player Satisfaction, of course. It is in this phase, implementation, where you will be doing the most cross checking against the player's hierarchy of needs, especially feel, and ensuring that they 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. Final Polish

We're finally here. The polish cycle. It really is a massive amount of effort, and as the old saying goes, the last 10 percent of the polish takes 50 percent 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."

No, 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'm not saying I'm immune to this attitude, my friends, but that does not mean I revel in the feeling when it passes through me. No I shake it off and remind myself why the hell I am here: to make games that matter. And I would fully expect, and appreciate, that if I ever said 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? Get A G.R.I.P. Define your goals, do your research, implement and approximate, and finally, polish until it shines. I go through the same four cycles in every system I work on, as does every other designer I know; though they may not think of it in those terms. The key lesson here, besides the strong methodology this ascribes to your process, is to understand that design does not flow in steps. We are taught that going from Left to Right is good — Step 1, Step 2, Step 3, DONE — and if you ever go backwards you are wrong, or worse, stupid. I'm here to tell you THEY are wrong. A designer MUST go from Right to Left, and if you aren't constantly reevaluating your own work then you ARE doing it wrong. Get a grip on your systems, or they might just slip through your fingers. [This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions.]