Idea Synthesis

A version of this article first appeared in the May 2008 issue of Game Developer magazine.

Getting your first design gig is often a combination of luck and who-you-know.  But once you’re there, moving up the ranks is typically entirely based on merit.  The junior designers who contribute rock star quality on the small projects they are given will quickly be granted larger responsibilities on bigger systems and more important parts of the game.  Leads love being able to hand off design projects to capable, reliable, low-maintenance designers.  So for those designers who feel they are banging their head against a glass ceiling, there is a clear path to move up – stop making game designs that suck.

The path to do so isn’t immediately intuitive, because it takes an entirely different way of thinking.  Too many junior designers have a habit of hoarding their ideas like precious gems, not collaborating with others, and avoiding showing design documents until they’re absolutely perfect.  They think that their job is all about idea generation, and this perspective lends them all sorts of bad habits.  They’re overprotective of their ideas.  They’re obsessed with getting credit and, at the same time, utterly terrified that their ideas will be rejected, feeling that it reflects poorly on them in the highly competitive field of game design.  The end result of all this self-consciousness all too often is designs that are too big, too safe, or too weird.

The best senior designers I’ve worked with have a different mindset.  They understand, inherently, that most ideas are bad – even their own.  They have less investment in getting their ideas into the game, and more in being sure the game rocks, no matter whose idea gets in.  Consciously or not, they focus on idea synthesis, a term I use to describe the informal game design philosophy that focuses heavily on collaboration, mass idea generation, and focused execution as the pathway to design success. 

Know what you’re building.  It is astonishing how many designers will go off into a bubble and design a system or a level without any clear idea of what this design is attempting to accomplish, or how it will serve the rest of the project.  The hard work that comes from this way of working is almost invariably doomed before the designer first moves his mouse across the computer screen.

Every designer should have an innate understanding about the project they are building.  What is the product’s unique selling point?  What will make it stand out?  Who is the market for the game?  What are the publisher’s expectations for it?  What does the license demand of the game?  Designs and ideas that support these goals have a much greater chance of success.

But that’s not enough.  When assigned a feature to design or an area to build, designers should try to schedule a kickoff meeting with their lead, in an effort of laying down expectations and boundaries and to nail down any unknowns.  Why is this feature here?  How central is it to the experience?  What does the market expect?  Being sure that you have a clear idea of your lead’s vision is one of the most essential paths to making a name for yourself on your design team.

Know your limits.  Perhaps the most important part of this conversation is to actually form an understanding with the lead designer about how ambitious this feature is meant to be.  Is this a core feature of the game.  Is it meant to be trumpeted as a key point of differentiation from competitors?  Or is the team committed to just matching the other guys? Or more drastically, is the feature there just to say you have it, so the marketing guys can justify putting the bullet point on the back of the box?

Junior designers often feel the need to innovate extravagantly  on every feature that they are asked to design.  But too much innovation can actually hurt the game.  If a game innovates on too many things, it risks spreading implementation resources too thin and doing none well.  Furthermore, reckless innovation risks being unfamiliar and confusing to new players and genre fans, and increases the odds of actually angering die-hard fans who prefer the old way of doing things.

Ultimately, most projects can only choose to truly take bold and daring risks on a handful of key ideas that the project leadership has identified as flagship features.  Unless you’ve been told otherwise, your feature probably isn’t one of them.  Delivering something that is too radical and out there is a sure-fire path to rejection.  Ask your lead how ambitious he was thinking the feature should be, and keep these boundaries in mind as you begin brainstorming.

Your idea is not a unique and beautiful snowflake.  Most of your ideas are bad.  But then most ideas are.  Perhaps the most important shift in mindset towards idea synthesis is to gain an inherent understanding: ideas are cheap, great ideas are rare, and creative minds must sometimes be prepared to kill their babies.

It’s not just the bad ideas that get killed.  Some great ideas are killed because they are technically or financially unfeasible to build.  Other fantastic ones die because they’re just inappropriate for the game.  Every now and then, you’ll stumble upon one so good the producer wants to save it for a sequel that may never come.  These things happen – get thick skin.

The first step towards being a more successful designer is the ability to keep perspective.  Don’t fall in love with any single idea – throwing temper tantrums because your pet feature died in committee is a rookie mistake, and in six months, you likely won’t even remember the sting.  You cannot expect to magically pull the best answer out of the hat while flying solo.  What you need is volume.

Reach out.  Mass idea generation is the key.  If you know that most ideas are bad, the best thing you can do is to play the numbers. Gather as many stray design musings as you can, and pick through them to find the best ones.  Hold full-blown brainstorm sessions, informal lunch meetings or just pick the brains of your colleagues on smoke breaks.  Use any excuse possible to get another point of view.

Reach out to subject matter experts.  Don’t fear the person who better knows the system than you, but rather ask his opinions.  And don’t be afraid of the guy who always has ideas better than yours – be sure you pick his brain.

Find out what worked on previous games and – more importantly – what didn’t work.  Do your research.  Don’t just look at the top competitors in your space.  Look at the little games and old forgotten ones.  And don’t be afraid to read a book or watch a documentary.

Write down every idea, no matter how silly.  Don’t be afraid to show your work.  Then let other people review the silly ideas – all too often, the crazy ones can build into amazing ones, simply because other people bring different perspective on how to make it work.  Do everything you can to encourage a positive and fertile environment for new ideas to sprout.

Cull the weak.  The most successful designers I’ve worked with know that their job is not to come up with a great idea, but rather to identify the best idea and execute on it.  So once you have a whole bunch of great ideas, it’s time to start thinning the herd.

But don’t just rely on your instincts.  Start by asking other people.  Show them a whole bunch of ideas, and ask them to put a mark by the one that immediately grabs them.   What you’re looking for is resonance – some ideas just grab people, the way a catchy pop song does.  If you’re lucky enough to get one of those ideas, lock onto it like a laser sight.

But while you’re doing this, don’t lose track of the big picture.  Compare the ideas you are generating towards the project goals, and the boundaries defined for you with your lead designer in your kickoff meeting.  The best idea in the world won’t get green lit if it undermines the project in other ways.

Keep it simple.  Fun is an elusive concept, almost impossible to predict before the game is tangible.  So your first design document should be kept as simple as possible, with an eye towards getting the feature in place quickly so the design idea can be validated in context with the rest of the game.

Keep your first draft simple.  Write a lightweight design document focused on the fun, highlight the innovation and call out the edge cases where the feature might break if not accounted for.

Don’t get lost in the weeds.  It’s a rookie mistake to overdesign – to design every unit, every bonus, every possible permutation of variables and flags a feature may ever need.   The resulting behemoth designs often actually hurt a feature more than help it.  Over my career, I’ve seen dozens of great features killed by design docs the size of the Old Testament. Programmers or project managers often torpedo a feature like that before they even finish printing the document out.

Knowing where that complexity can come in the future is a good thing, but don’t worry about it in the first draft.  Push to get a lightweight version of the feature built quickly. Let playtesters  get their hands on it so the design can be played and iterated on. Embrace all feedback.   Once the feature is tangible, it is tremendously easier to have a clear perspective on the feature.  Once you know what worked, what didn’t work, what’s fun, and what’s tedious, it becomes almost trivially easy to target the correct parts of the design to add complexity and depth.

The big picture.  Last but not least, give credit freely to those who contributed ideas to you, but don’t obsess over it yourself.  The credits page doesn’t list the designers for individual features or levels, and even if it did, having a megahit on your resume is vastly more important.

The days of one-man design teams generating blockbuster games in the garage are over.  The industry today is about huge teams working collaboratively to chase after a very elusive concept of fun.  Good designers understand this, and work within these constraints.  But the great ones don’t see this as a constraint – they’ve learned to leverage this extra brainpower to make better designs and better games.