The Jon Shafer Approach

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!

Previous Post
Next Post
Leave a comment


  1. Carlos

     /  July 23, 2012

    On a very small scale I am able to satisfy my game design needs with modding. Usually my main two problems are having too many ideas and few time to work on them, but the most hurtful one is the second. When the system/engine/tool limits you to put into action your idea, then you have to take alternative routes but at least for me they are always bitter. BTW, I did a mod for Civ4 that wanted to replicate in Civ5, just couldn’t because there is no way to raze cities!!!… been waiting for the full SDK but I have given up my hopes.

  2. Laplace

     /  August 9, 2012

    With each post you keep making sense. So how come your games didnt turn out that good ? And now you even went to Stardock, which hasnt made an interesting game since…ever ?

    • Whether it’s with life in general or just game design, wisdom can only be gained through experience. The reason I created this website was so that I could share what I’ve learned during my journey through the games industry. My goal in writing these articles is to help new or aspiring developers pick up some of the lessons that I had to figure out the hard way.

      – Jon

  3. Bryan

     /  August 21, 2012

    Hi Jon, I read the article and enjoyed it greatly. As a tool programmer I too tend to get distracted by the books laying around the office or I will drop whatever JIRA issue I am working on to develop new features. I find that I am more productive when I have the freedom to work at my own pace.

    I do have a question though. Do you think it’s possible to cheat and become a great designer simply by using tools or methods that increase the frequency at which ideas can be evaluated, or in other words, by reducing iteration times? I recently read The Talent Code, which describes a 2-pronged approach to becoming world-class at anything: ignition (the desire to become world-class, which is in no short supply for gamers wanting to become game designers) and deep learning, which aims at building Myelin in the brain as quick as possible. Assuming the first 10 games you make as a designer are going to be bad, if you had a fantastic tool and all the assets you needed to make 10 games, couldn’t you design those 10 games as fast as possible and then move on to projects that will be good? How much life experience is required to be a good designer as opposed to “practice makes perfect?”

    • Great questions Bryan. I believe there are two main facets to becoming a good designer that is capable of putting out consistently solid games.

      First is: actually understanding game design! There are two parts to this:

      1) Trying things out and failing.

      2) Learning from those failures.

      If you can iterate much faster than the average person and are willing to put in the time and effort to take advantage of that then you have #1 covered, but it’s still crucial that you also get better along the way. If you never develop even SOME sense for what will and won’t work before actually spending time (and money) then you’re going to be in trouble. If a luminary is right 1 in 10 times and you’re an average Joe with no design sense who is right 1 in 500 you’re just not feasibly going to be able to bridge that gap with effort alone.

      But let’s back up a bit – is everyone capable of #2, making that whole concern moot? It’s honestly hard to say because very few people even spend the effort required by #1. My own feeling is that anyone who has the drive to legitimately try but still fail at something 100 times in a row and not give up is going to figure things out along the way, but hey, everyone has different talents!

      The other big aspect of being a good designer aside from just knowing design is being able to come up with interesting ideas – this touches upon your last question. I think every designer has to pull inspiration from somewhere, be it other games, books, movies – whatever. Maybe you know X really well and have always wanted to make a Better X. That can carry you a fair ways, but eventually you’re going to run out of ideas, even if it’s not until after you’ve finished Better X. Having a feel for design is the most crucial trait, but every designer should at least spend some time away from their own work in order to pull ideas from new places.

      – Jon

      • Bryan

         /  August 21, 2012

        In Alain de Botton’s “The Architecture of Happiness,” the idea that “beauty is the promise of happiness” is explored. Near the end of the book, De Botton compares Western and Japanese notions of beauty in architecture and gardens, and he concludes that perceptions of beauty change over time. This is very interesting to me, because it means that people’s perception of beauty in game design can change over time as well. If exposed to a particular style of design one may become sensitive to it. Even with deep learning, a designer is unlikely to map the space of beautiful game design in his lifetime, so I would agree with you when you say that inspiration must be drawn from elsewhere.

  1. Links, engage! | Cadenza Interactive

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s