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.