Game design is an art. And like all art, there’s no ‘right’ way to do it. Each practitioner crafts a unique style that works for them, and – as any creative sort can tell you – there’s no single methodology that will consistently churn out masterpieces. What I’ll be describing in this article is my personal approach, which has evolved quite a bit since I joined the industry. My purpose in writing this is to share some of the lessons I’ve learned along the way, perhaps helping designers still in the process of refining their own style. For those who are not themselves designers I hope you find this peek behind the curtain entertaining and informative!

…

Have a Chat with Yourself

It’s not just for crazy people! No, really!

Okay, just to be clear – I don’t actually talk out loud with myself, but people who look at my design docs often inquire as to who I was having a conversation with, and the answer is… myself! Many writers and editors suggest reading your work out loud as this process will often uncover grammar quirks or unpolished wording that aren’t obvious in written form. I’ve found that while designing, posing questions to yourself and then answering them has a similar effect.

• “What is the purpose of feature X? How does it make the game better?”

• “What is the player deciding with X? Is it really a meaningful choice? Why?”

• “Does X surreptitiously undermine my goals for another system, or even the game as a whole?”

Inexperienced designers nearly always skip the crucial evaluation step. Designing interesting games and features means relying heavily on ‘gut feel,’ but that’s just one piece of a much bigger puzzle. An idea that initially sounds fun might have serious flaws that aren’t discovered until after effort has been spent on implementation, or worse, after the game has been released. It’s easy to fall into the trap of casually adding something to a list, or hooking it up in the game simply because it sounds cool or seems like an obvious fit – without really thinking about its impact.

The exercise of posing and then resolving questions often leads me into some fairly deep introspection. On occasion I’ll end up with an answer vastly different from what I was expecting. One good example was a game where a major component of the combat system was giving me all sorts of trouble. It was a cool concept, but I just could not figure out how to make the decisions it offered the player truly meaningful. In an attempt to resolve this I tried adding other features, but I remained unhappy with the results. I was on the verge of giving up and simply cutting the system (no matter how cool it is, a feature without any real purpose is just clutter) – but after thinking about what made the component intrinsically sound cool, I realized that an idea I’d scrapped many months ago was the key to making it all work.

I probably spent weeks on that feature, but I never would have come to a satisfactory conclusion without such an in-depth inquiry. Had I given into the ever-present temptation to say “ahhh, whatever, it’s fine as it is!” the game would have undoubtedly been worse off as a result. These sorts of keep-you-up-at-night problems are extremely challenging, and even trying to solve them is mentally exhausting. But the capacity and motivation to do so is what separates true designers from those who wrongly believe “anyone can do game design!”

 

Embrace Criticism

The sad truth is the most of your ideas will be bad. Horrible, even. Unfortunately, it’s nearly impossible to immediately come to this realization – they’re your ideas, after all. If you thought they were bad, you wouldn’t have thought of them! But each individual’s brain is trained to produce and recognize patterns completely unique to them. Everyone has blind spots where something will sound great inside the little bubble of our head, but upon entering the real world its flaws become obvious. The sooner designers acknowledge the cold hard truth that much of their work will be broken and unfun, the better. That doesn’t mean designers should just not even try, but it does mean they need to have an open mind.

It took quite a while, but I eventually learned the importance of ruthlessly hunting for flaws in my designs. When considering an idea I’ll always start with “hmmm, how could this be fun?”, but if I come up with a good answer the next question is always “okay, is there any way this won’t work?” When I was younger and less secure I would often skip that second part. Let’s be fair – there aren’t too many mentally-stable folks out there who enjoy coming up with ways they might screw up or fail. But after seeing my pet ideas flop time and time again, I came to the realization that the only way to make something good is to seek out problems and fix them.

A designer can’t be afraid to revise or completely throw out ideas, features or even entire games. (Hopefully the latter doesn’t happen too often though!) You need to always be wearing the hat of “how can I make this better?” and that means trying really hard to poke holes in your own work. Once you let go and fully embrace the philosophy of “better at any cost” you’ll find the quality of your work will improve dramatically. It can be painful at times, but a designer has to decide whether his or her goal is to make a good game, or if it’s simply to stroke their own ego.

I’ve also learned to encourage those around me to be brutally honest. Being able to self-critique is vital, but no one can figure out everything on their own. Even with almost a decade in the industry now, I’m often still blindsided when, after spending days on a feature, someone puts a fresh pair of eyes on it and after 30 seconds casually notes a massive flaw or opportunity that had never once occurred to me. Value those around you who are both willing and able to provide harsh, valid criticism. Better this come from a few trusted partners during development than thousands or millions of players after it’s too late…

 

Other Design Maxims

Aside from engaging in awkward conversations and soliciting feedback from myself and others, there are a few other design principles I keep in the back of my mind.

Finding ways to encourage players to adapt is always near the top of my priorities list. Putting together a plan and executing it flawlessly is fun, but you also want something tugging the player from another direction – be it a mysterious threat or an unexpected opportunity. This is something I talked about in detail not long ago.

Another one of my goals is to explore the design space offered by a feature as far as possible. When providing feedback, a suggestion I’ll often throw out is “make it stronger, just to see what happens.” Just like an inventor, often times a designer’s best inspirations are stumbled into by accident. Wacky ideas rarely work out, but when they do you usually end up with something incredibly unique and interesting. It’s nearly impossible to get that sort of payout any other way.

On a related note, I try to design concepts in terms of mechanics rather than numbers. For example, say you’re designing a Civilization title and you want one of the races to have a research bonus. The easy way to go would be to give it a 20% cheaper technologies, but this ‘numbers’ solution is, well… boring. A much more interesting option would be to give the race a special unit which can covertly steal technology from other players. This type of mechanic is much harder to balance and, hey, it might not be any fun at all, but if it works you’ll have struck design gold. Mechanics VS numbers is a topic I’ll be talking about more in the future.

The last of my maxims that I’ll discuss is my #1 goal when I put on my designer hat – staying focused on crafting the best experience possible for the player. It can be tough fighting the urge to get dragged down into detail work that doesn’t really pay off, or give in to the temptation to add a system that’s fun to design or is academically interesting, but ultimately results in a game that is less enjoyable or harder to understand. When you catch yourself doing this, it’s good to get into the habit of pinching yourself and saying “Hey dummy! This isn’t going to make the game any better!”

 

Nuts and Bolts

With our deep dive into the philosophical side of game design wrapped up, let’s talk about some more mundane parts of the job.

First off, I have to come clean and admit that I’m a huuuuge Google Docs fanboy. Having access to everything, everywhere is awesome for someone like me who uses at least 3 computers every day and travels fairly often. In mid-2011 Google came out with an offline mode plugin for Chrome which allows users to view and even edit docs without an internet connection. The only big downside I’ve found to using Google Docs is that its support for iOS is quite poor – so bad, in fact, that I don’t even bother using it on my Apple devices. This is fairly a minor inconvenience though, particularly with Google recently adding the ability to edit offline docs.

When I’m going to perform the sort of in-depth analysis I outlined in the first section of this article, I set aside docs specifically for brainstorming. It’s important to keep this separate from the docs which outline implementation details (the thing most people think of when they hear “design doc”). Having the two mixed together can be inconvenient. Much of the time developers will simply need the nitty gritty “this is how Feature X should work.” Other times there might be questions as to how you came to the conclusion that Feature X should work that way, and it’s nice when you don’t have to hunt down the brainstorming you did 16 months ago. Documentation needs to be easy to navigate, and a lack of organization will inevitably result in it becoming an unintelligible mess. As anyone who’s been a designer at a large-ish studio can lamentably attest, design docs are often completely ignored, so the last thing you want to do is make people even less likely to use them!

Okay, that’s enough about docs – let’s discuss workflow.

The reality is that some days I’m just not feeling ‘it’. And on others I really am and knock out a full week of tasks in just a few hours. Everyone has unique work habits, but I know many creative types also have this (sometimes awesome, often frustrating) trait. The most important lesson you can learn about creativity is that you can’t force it. As a designer it is especially important to have downtime and let your brain get some R&R. Read books, play sports, clean your house, whatever – good ideas can start flowing at any time, but if your brain is tired or overworked this flow can dry up and become a trickle. As long as you’re not missing deadlines or holding anyone up don’t feel bad about having a mix of ‘productive’ days and ‘slow’ days. I’ve found that forcing myself to do an even 8 hours of work per day results in getting less done than when I follow my natural workflow.

If you happen to actually, you know, get a paycheck for doing game design (lucky you!) then depending on the individual administering your yearly reviews, having ‘slow’ days may not be acceptable. My first bit of advice would be to find a new job where management recognizes that creativity can come in fits and starts, and as a dedicated employee you still get done what needs to get done (you are a good performer, right?). Of course, switching jobs isn’t possible for everyone, so one alternative to finding a more accommodating supervisor is keeping more than one iron in the fire. Maybe you’re not feeling up for designing quests today, but instead of hammering your head against the quest you’ve been working on the past few days, you instead start brainstorming ideas for map design. One of the coolest parts about being a game designer is the wide variety of tasks that need to get done. If you’re a little burned out on one, there might still be others where you can make progress.

Being a designer isn’t easy. The craft isn’t well-understood by those who haven’t served in the role, and in some circles the value designers provide is – ignorantly and unfortunately – questioned. Every designer has to carve out a niche for him or herself, and improving is a lifelong process that can never be considered complete. Hopefully describing my own approach to design has been helpful, or – at the very least – enlightening!

– Jon

Oh, and before anyone asks… I agree that this article would have been improved if I directly referenced some of my design documents, but unfortunately there aren’t any I can publicly share at this time. However, when I am able to I’ll be sure to put up my work here on the site. When that day comes my plan is to use a full article to discuss it in detail, if only to make up for my inability to talk about them right now!