All posts by Eyejinx

From the Archives: Pitfalls of the Working Game Designer: Too Many Cooks

This post was originally written back in 2004.  Some of the references are a little out of date, but the argument still stands, I think.

 

When it comes to design, everyone has ideas.  This is not a good thing.  In fact, the work of cutting away all the possibilities is far more difficult than coming up with them.  You may come up with a hundred ideas in a brainstorming session, but you’re going to have to cut half of those right off the bat because they’re too far out in left field; another half of what’s left is going to be easy to cross off because of technical and time limitations.  Of that last quarter, though, the hard work comes in getting down to the handful of ideas that will work coherently with the rest of the design, fit within your schedule, be implementable in your engine, and not blow-out your art asset and testing budget.  That’s fine as long as you have a well-defined gate for design decisions, but inevitably there are a few hitches in the system.

Have you ever sat down with a friend and had a great conversation about the possibilities of a game?  Sure you have.  It’s fun; it’s exciting; it gets you all fired up to see those possibilities in action.  This is what I like to call “The Two-Man Effect”.  It goes something like this: one person comes up with a statement, like “Wouldn’t it be great to have a first-person shooter where you could track someone’s stats over the lifetime of their playing the game”; the second person chimes in with “Yeah, that would be awesome, and you could keep track of all the people you had killed and who had killed you”, which leads the first person to elaborate “Yeah, and you could build grudges and track down people in different game sessions to have a go at them”, which leads to the second person to add “Yeah, and you could have duels—you know, like heavyweight boxing matches where you can call someone out and everyone else can watch”, and so on and so on.

In other words, one person thinking through something on their own might come up with an idea and feel rather attached to it.  Two people talking through an idea quickly get to the point where whatever idea they’re talking about is the best thing since sliced bread: not only is it a good idea, it’s a great idea, and anyone who doesn’t get it is simply too dense to get it.  It’s a natural process; each person in turn validates the ideas of the other, and the charge of being creative and having that creativity validated leads farther and farther out in a self-supporting castle in the air.

Now, when one of those people goes to the designer, you suddenly have a problem.  You see, the designer has to know all the problems with that idea: all the ways people have tried to realize that idea and why they haven’t worked, the ways that players will use the game system to disrupt the intended effect, the limited value of the idea relative to the other things the project includes, the issues that come with trying to implement it, etc.  In other words, the designer has to point out that just because it’s an interesting idea, that doesn’t make it a workable design.  That’s a serious buzz-kill.  Now the designer is the bad guy; he just killed your idea.  Or, even worse, he’s the one pushing it through, without realizing what the impact is going to be.

A similar problem occurs when one of the two people has the power to push the idea through even though it’s not a workable design, and suddenly the design of your whole project is broken.  Either the designer has to push back hard enough to stop the idea from making it in, or they have to work with it even though they know it isn’t going to work.  In either event, the designer is now alienated from the person who came to them with the idea, and that’s going to make everyone’s work a little harder.

A game design is, in many ways, like a spider-web.  Each element of the design needs to connect to all of the other parts.  So, the designer has to be an architect of game systems, making sure that everything balances and holds together as a coherent whole.  This is much easier to do (although by no means trivial) if the project has enough flexibility that you can shift emphasis around as things develop and the stresses on the project become clear.  If this isn’t done, you get the “sore thumb” section or feature that the reviewers and fans are bound to harp on.  

Every design mandate that comes down the pipeline ends up fixing some point of the design, which means that every other system is going to have to compensate.  Eventually, you can run out of places to shift, and if that happens, you might as well just cancel the project and save everyone a lot of time and money.  Of course, given the nature of the industry these days, that may mean you’re out of a job.

So, what can you do as a designer?  Well, first off, don’t ever respond to anyone’s idea with why it won’t work.  The flaws may be glaringly obvious to you; the idea may simply scream unworkable, but resist the temptation.  First, get into the spirit of the idea, try to capture a little of that collaborative magic.  Expand on it a little; get a sense of where it’s coming from, what’s exciting about it.  Then, try and present it back to the person in a summary form.  If you’ve gotten it right, they will know that you’ve taken the time and understand what they’re trying to get at.  Then, take them through how you’re trying to get at that same goal from within the existing design.  Bring them in on how that piece fits with all the other pieces.  If it still doesn’t fit, then make sure you record the idea somewhere for future reference.  You may well come back to it, and even if you don’t, it gives the idea a home rather than just being dismissed.

Second, don’t be that guy.  Designers are just as susceptible to the two-man effect as anyone else.  Don’t let your ideas run away with you.  From time to time, do a reality check: can the system be broken?  Can it be implemented?  Is it worth the cost relative to the other systems you need in the game?  Does it feed the central design or take you off on a tangent?  Who else has done something like this and what problems did that design have?  After you’ve vetted it, take it to someone else; if they don’t see it right away, if it doesn’t catch fire with them, re-consider the value.  After you’ve taken it to a second person, take it to a third.  And always keep in mind that you may need to ditch it later even if you do keep it now.

Again, the more structured the design process is, the less susceptible you are going to be to this problem.  As the design evolves, it needs to go through a reliable approval gate.  Once it’s been approved, you shouldn’t go backwards.  New ideas that disrupt the established design can be eliminated on that basis.  And any of these “left field” contributions can be taken through that same approval process, and if it denies them, then at least everyone knows that it got due consideration.

You’re never going to be able to cut off these contributions, from the team, from management, from your publisher, from testers, from fans.  Nor would you want to.  All of these can be sources of great insight and innovation.  At any time, one of them may offer you the missing piece that makes everything else work a little bit better.  Just make sure that the enthusiasm for an idea doesn’t cut into the workability of the design.  Treat your team with respect, respond to their ideas constructively, and you can become the “go to guy” when they get that itch to think creatively.

Design Skills: Forethought

Anyone who has been in the trenches as a designer for a while understands that designers have to have a wide-ranging skillset.  In fact, the list of roles that designers commonly have to play in team development efforts is so long that it’s not practical to write them all out.  Mixed in all of that are certain key skills that make the difference between mediocre designers and good ones.

Today, I want to focus on forethought.  Now, you could argue that almost all design work is forethought in some degree or other; after all, designers are usually a few steps ahead of the team, laying down the roadmap so that other team members know how what they’re doing fits into the larger picture.  But, generalizing to that degree loses detail.  There are a handful of key dimensions to forethought that designers (and those who hire and manage designers) need to be aware of.

One dimension is the ability to translate from a paper design to a player experience.  I had the pleasure of working with Brian Upton (co-creator of Rainbow 6 and lead designer of the original Ghost Recon) while I was at Red Storm, and he was an absolute master of this.  Not only could he look at a top-down level map and pick out blind spots, chokepoints, and dead zones, but he could look at a controller layout design and immediately parse what action combinations would be awkward or unintuitive for players.  Translating from a description of a system to being able to play the game in your head is a skill.  It’s not some strange talent or gift that only certain people have; like any skill, it gets better with practice.  Brian had been working on this for years by the time I encountered him, and his critiques of my designs inspired me to develop this skill for myself.  I don’t pretend that I’m as good at it as he is, but it has been an essential part of my toolset ever since.  Particularly when I was on the publishing side and working with designers in multiple genres on a variety of platforms, being able to think ahead about what the actual play experience was for a design helped me to identify problems early and get adjustments made at the design phase, when changes are their cheapest.

A different – but related – dimension of forethought is empathy.  Robin Hunicke gave a great talk at DICE last year about empathy and how important it is when making games that aim to have a real emotional impact on the players.  Regardless of what type of game you’re making, empathy is a key part of forethought.  When you imagine a player experience, you need to be able to imagine not only your experience as a player but also as many of the different types of players you might encounter as you can.  In today’s marketplace, you have to be able to reach hundreds of thousands of people to have a sustainable business.  Odds are, you’re going to get every type of player imaginable.  The more of those people whom you can empathize with, the better you can understand their play experience, the more likely you can make the game accessible, intuitive, and rewarding for them.  As a designer, you’re not designing for yourself (most of the time), you’re not just designing for the team (although that does happen), rather you’re designing for the player.  The more you can understand – not just clinically, analytically but emotionally – that player, the better.  At a minimum, it can help you identify roadbumps, moments in the game that will strike those players as false or even offensive and polish those out of the experience.

Finally, and I may just be making this term up, there is systems forethought.  This is critical when you are making large, complex games like MMO’s that have a variety of interlocking systems, but it is also endemic to most games that have mathematical progressions, whether you’re talking about builders, CCG’s, RTS, life sims, or RPG’s.  Individual systems can be mapped fairly easily, but interlocking systems can quickly turn into chaotic models (in the science sense) where small changes in values at one stage of the game lead to wildly variant outcomes down the road.  As a designer, you have to be able to think through the I/O process of a variety of systems and identify any runaway dynamics, hopefully before implementation.  This is different from translating a design into a player experience or empathizing with your players – although modeling the griefer/exploit type player can help in the process – because you have to look at the system models independent of player interaction.  You can get runaway game dynamics from procedural generation or AI as easily as you can from player inputs.  Like other skills, it takes practice, repetition, and time to develop, but this can save development teams months of work and hundreds of thousands of dollars in development and testing.

As you might imagine, forethought is something that junior designers are often lacking, but your senior designers – especially the successful ones – know how to do this along a variety of different axes.  Every detail that gets implemented into a game has some impact (if not, why are you doing it?), but being able to reliably see that impact ahead of time is an invaluable and essential skill that is a part of any good designer’s toolset.

Are there other aspects of forethought that I missed?  If so, feel free to leave a note in the comments.