The Game Design Process

Some of the issues I will talk about here I have learned the hard way (i.e., by discovering late in development that a crucial point had not been thought out well), others I have gleaned from a variety of sources and integrated into my own routine.  I have had the chance to work with people who had backgrounds in film, animation, sales and marketing in addition to games, and my design has improved a great deal thanks to them.  I recommend that you take the time to look at Digital Arcana's methodology (which has strong film-making influences) and at Ben Sawyer's Ultimate Game Developer's Sourcebook (ISBN: 1-883577-59-4) for very good discussions of the game design process.

Note that, while I write with computer game design in mind (being that this is what I usually do), many elements also apply to board, role-playing, or play-by-email design.

Game Design in Six Easy Steps

• All games should begin with a design treatment, i.e., a quick discussion of your product's unique features and target audience.
• Then, you should move to a preliminary design, discussing the game's rules, content and behaviour in a purely qualitative way.  This document should be circulated and discussed as widely as possible given the situation.
• A final design is a re-write of the previous document, which etches the product's features in stone.
• The product specification (which only really makes sense for interactive products) details how the features adopted in the final design will be implemented.
• The graphic bible determines the look and feel of the game's characters, maps, props, etc.
• The interactive screenplay, if appropriate, contains the dialogs and the storyline implemented into the product.

A word to the wise: as long as you are still in design, it is never too late to cancel a project.  Even if you have a final design document and a full screenplay in hand and are ready to turn your creation over to a producer, you have probably spent less than 10% of your total production budget.  Unless everyone in the company (studio staff, sales, press relations, everyone) is convinced that the game is going to be a winner, pull the plug now.  Six months from now, when you have a million dollars committed, it will be too late.

The Design Treatment

The design treatment is a short (4-8 pages) description of what kind of product you would like to do and what you would need to do it.  The document's purposes are multiple: it helps the designer to structure the "creative spark" into something tangible that can be discussed, it establishes a framework for future design work, and it serves as a marketing tool to generate interest in the product in company executives and/or publishers.

The exact content of a design treatment may vary according to the intended audience, but not by much.  Financial information may not be appropriate for a first contact with a publisher, but otherwise, everyone who you will want to submit your treatment to will need to see the following:

• The game's genre and key features.  For example, a design treatment for Doom might have read: a shooting game, with a first-person perspective based on a 3D ray-casting engine.
• A short description of the experience you want to give to the player.  Is the game a comedy?  An adrenaline thriller?  A puzzle?  Will it be a technology showcase, a graphic wonder or a story?  Linear or not?  Is it single-player or multi-player?  Playable over a LAN or the internet?  What are the key elements of gameplay and of the interface?
• What kind of look-and-feel do you want?  A realistic 3D style?  Cartoons?  Isometric?  Lots of intricate move combinations and secret rooms, or straightforward gameplay suitable for children?
• How will you structure the game: levels?  Missions?  Episodes?  How many?  How long will each be?  How will you provide replay value?
• What resources will you need?  How many people will work on the game, for how long?  Do you need senior engineers with knowledge of 3D, of network programming, of Artificial Intelligence?  (Do you have them on staff, and if you don't, can you hire them?)
• Will you need an engine?  New development tools (i.e., a new version of Softimage 3D)?  Will you buy, or develop in-house?
• Will you acquire a license to some well-established intellectual property, or create your own?  The right license at the right time can mean "free" extra sales, but it can be expensive.  And you must buy now a license that will have value in two years; Looney Tunes are a safe bet, the Macarena is not.
• Who are your major characters/units/game pieces?
• Who is your target audience?  A trivia game, a Barbie clothing designer, a chess engine and a Quake killer will appeal to very different people.
• What platform(s) will you develop for?  Which will come first?  Will you port the game to other platforms yourself, or hire sub-contractors to do it for you?
• How is your team qualified to deliver this product?  Industry experience and a track record make publishers relax, but even if you are relative beginners, you may have more to sell than you think.  If your brother-in-law is the pit crew chief for last year's Winston Cup winner and he agrees to consult on your NASCAR racing game, you have a winner.  Same thing if you are working on a simulation of the Crusades and you can bring a historian from a local college on board.
• A preliminary estimate of the budget and production schedule.  At this stage, something as vague as "about 10-12 months, for a team of 6; will cost 500K to 750K with tools and fixed costs" will be enough; no one expects a precise budget from a five-pager, but the reader will need to know whether this is going to be a tight-budget production or a main-eventer.

I have posted a sample design treatment on my page; you can find it here.

All in all, a design treatment should not require more than 100 to 150 person/hours of work; 75 if it doesn't include any graphics.  If you put more work than that into it, you are wasting your time.  If you are an amateur designing for fun, then it's no big problem, but if you work for a professional game development house, these 100-150 hours you have already put in probably cost the company 5K to 7K$ in various expenses.  Since odds are that your treatment will never lead to a full design (more on that later), it's enough.  If your creative juices are still flowing, go work on another treatment.
 

A few words of caution

Good.  Stay seated for a while.

Stuff your treatment in a drawer, take a deep breath, go bowling, call your aunt Maria in Portugal, and do not think about your great idea for, oh, at least two weeks.  Then, if you still think it's great, go ahead and send it out in the world.

Nothing kills so many game development companies as two-in-the-morning ideas that get implemented just because no one stopped to look them over and realize that they stunk.  As an executive for a small computer game publisher, I saw tens of finished or highly advanced products that should never, ever have gone beyond the treatment stage.  I remember meeting with a group of young hopefuls at the 1997 CGDC; the game they had worked on for months and months was technically sound, visually adequate and easy enough to play, but it was based on an idea so ludicrously bad that it didn't deserve a shareware release, much less the million-dollar contract these guys were looking for.  There wasn't five minutes of gameplay in there.  They wasted their time.  And the worst thing is, their production values showed that these guys had talent; with the right design, they could have made it.  I hope they will, someday.

Circulate your design treatment as widely as possible, and if it generates some interest, then (and only then) go on to a full design and a demo.  Sure, you run the risk that your ideas will get stolen; it happens all the time.  However, there is not a whole lot you can do about it, unless you have the funds (or the spare time) to work on a complete design and a working demo before you start looking for a publisher.  And that is the second most-popular reason why development studios fail: they bet the farm on a product and then find no channel to market.  If at all possible, walk in small steps.
 

Game Development Food Chain

• Out of 10 design treatments written and submitted, maybe 3 or 4 will attract enough interest to warrant a preliminary design, and 2-3, a complete design.
• Out of 3 final designs, it is likely that 1 will not be produced at all, or that it's production will be cancelled midway because of lack of funding.
• Out of 10 completed computer games, 2-3 will get wide distribution, 4-6 will get more modest market penetration, and some will never be distributed at all.  Publishers break contracts when they run into financial trouble; if you are (very) lucky, the advances they paid will allow you to survive and develop another game.
• Out of the 1,200 to 1,600 PC games released every year, it is estimated that fewer than 100 break even financially, and only a few dozen really make significant money.

The Preliminary Design Document

The preliminary design is a discussion document, and it may (should?) go through several iterations.  If you are writing a role-playing or board game, you can start play-testing at this stage, which will help you weed out elements that don't work.  Computer games are a little trickier, since you have no software to play with until much later in the production process; nevertheless, discussing the design document as openly as possible, with other designers in your company and with lead artists and programmers, will serve much the same purpose.

The content of a PDD depends so heavily on the type of game being considered that it is not even worth trying to define a standard.  As an example, here is a partial list of contents for a 3D PlayStation game I once co-wrote:

• Technical specifications: frame rate, texture resolution and color depth, number of player characters, single and multi-player modes, camera handling, etc.
• Backstory, including a storyboard for the game's FMV intro.
• Cast of characters: the player characters and their unique talents, the villain, his ships, the supporting cast, etc.
• List of the game's environments and the missions taking place in each.  About 1-2 pages of general information on the unique characteristics of each mission (i.e., slippery surfaces, low visibility, types of monsters, race vs shooting, etc.)
• Special ammunition, power-ups, traps, bombs, equipment.
• Monsters and the statistics that define them: endurance, hit potential, type of behaviour.
• Lives, health, resurrections and tagging between player characters.
• List of moves, including the secret and special-purpose moves appearing in specific situations.

While great care should be taken not to waste time in endless discussions, when in doubt, keep talking.  Cutting design time short to save money is a sure-fire way to run a production into a wall.  Preliminary design can take anywhere between 4 and 10 weeks for the designer, and 10 to 30 hours for the other people involved in brainstorming.

I have posted the revised design document (an advanced form of the preliminary design) for a pro-wrestling simulation play-by-email game here.  Of course, it is a very simple game, and the document for a commercial computer game would be a lot more complicated, but the level of detail and the completeness, given the subject matter, is about right.

The Final Design Document

A good final design document goes into as much detail as possible.  If you are in doubt as to whether a certain bit of information should be in there, then it should.  EVERYTHING that you can put in is relevant, because it forces you to think your design through before production begins, and nothing helps smooth a two-year development cycle as much as a design which leaves no (or few) crucial decisions to make midway.

There can be a certain amount of overlap between the contents of a final design and those of a product specification.  If the designer happens to be a senior programmer, for example, he should write down the algorithms for some of the unique software features he wants in the game; after all, he thought of them, and no one else knows what behaviour he wants the software to exhibit more than he does.  Something that definitely should be in the FDD (although I have rarely seen it) is a list of priorities: what features the game can not live without, what would be really great to have, and what will be added at the last minute if there is time to spare (or delayed until the sequel if there is not).  It is a fact of life that some productions go wrong; the game industry is not very strong on software engineering techniques, and even highly organized studios can get in trouble if key people leave at the wrong time.   A lot of trouble can be avoided if you know in advance what should be cut if you risk not being able to deliver in time for Christmas; besides, such "risky" stuff can be scheduled for later, so that if it needs to be taken out, it won't have wasted your team's time and effort.

By the time the Final design document is deposed, the lead designer can have spent 150 to 400 hours on his product, or even more.  Final design documents can range in size between 75 pages (for simple action games, when most of the level design is written down in a Graphic Bible or handled informally) and 200 pages or more.  My personal record is around 160.  Interactive movies have screenplays that occupy 300-500 pages by themselves!

All the Final design documents I have ever written are either subject to non-disclosure agreements from former employers and clients, or lost in the dawn of time.  Therefore, I can not post any here.  However, just to give you an idea of how much detail you should put in, here is a partial table of contents for a typical play-by-mail multi-player sports simulations:

• The length and timing of seasons (how many per year, when do new leagues open their doors, etc.)
• The hierarchy of leagues necessary to support thousands of teams, with promotions/demotions between leagues of different levels for strong/weak teams.
• The procedure to create a new team: standard and custom team colors, creation of new players, stadium building, expansion draft.
• The database of fantasy player attributes and statistics: over 40 attributes covering talent (current and potential), health, luck and personality; a list of every statistic which will be compiled by the system and of the record books which will be maintained.
• Scouting process: what is visible to the players (and how clearly), and what remains hidden in the database.
• The reports which will be sent to players: contents, layouts, frequency.
• Detailed description of the data-entry application's interface, including a list of menus and dialog boxes.
• Franchise management: hiring and firing players, recruiting minor leaguers, training, trades and trade adjudication mechanism (to prevent one-sided trades from boosting a team unduly), scouting, ticket prices, salary cap, contract offers, how to generate revenue from TV and from press releases, etc.
• Game management options: what orders the player will be able to send, and how mistakes in player commands will be handled.
• The manual which will be sent to players at registration..
• The game's simulator algorithms, in great detail (including the effects of weather, fatigue, injuries, etc.)
• Random events: accidents, "real-life" problems influencing fantasy player performance, grudges, etc.
• Game Definition Language: allows to store games in compact form and to generate play-by-play text (or audio) files automatically.
• A discussion of game pricing, marketing strategy, and prizes.

The Product Specification

This may mean sitting down with the lead artist to sketch the main characters, spending time with the lead programmer to make sure that the algorithm which manages transfer of information between non-player characters will produce the appropriate behaviour (i.e., let some characters place variable levels of trust in what they hear from others), making sure that the proper development tools will be ordered at the appropriate time, etc.

The product specification itself is a blueprint for the development process.  In theory, the designer could leave the team once the product spec is written, and everything would be fine.  Although things are never this simple in reality, every effort should be made to ensure that the product specification is as thorough and realistic as possible, because any mistake can result in a delay of final delivery, extra costs, and extra overtime in the last months of production.

The product spec should contain the following:

• A list of the sound effects and music tracks required in the game.
• A list of the animations, 3D models, textures and other graphics which need to be produced, in as much detail as possible.  If you can list the exact "idle animations" which will be attached to your main character at various points in the game, do it.  If not, at least decide how many there will be.  The lead artist should estimate the amount of effort required for each element of content.
• A list of the algorithms which must be developed to implement/upgrade the game engine and in-house tools.  The lead programmer should estimate the effort required for each major feature.
• A list of all other materials which must be produced by the team: press materials, demos, screen shots, box art, manual, etc.
• A detailed project plan and schedule, including a preliminary assignment list for each member of the production team, a list of dependencies (i.e., a Pert chart), reasonable milestones, and contingency plans.
• A detailed production budget.  Knowing who will work on the project for how long and what expenses must be made to equip the team, the producer is now in a position to pinpoint the expected cost of the product, and to re-arrange priorities accordingly.  Very expensive subsidiary features can be assigned lower priority, so that they can be dropped (before being spent upon) in case of an emergency.

The Graphic Bible

Basically, a graphic bible defines the look of your product.  It contains the following:

• Style sheets and color schemes (i.e., pantone) for your characters and monsters.  These may specify 4-10 different views of each character, which will guide animators and 3D modellers in maintaining consistency throughout the product; they allow you to let more than one artist work on the same character at the same time if necessary.
• Style sheets for the major objects, vehicles and props.
• Maps of the levels and environments.  This may include the graphical part of level design.
• Background drawings.
• A storyboard for the intro and for any other FMV/animation sequences in the product.

The Screenplay

As far as I know, there are still no good tools on the market to facilitate non-linear writing.  Some packages support simple branching stories, but that's it.  For anything more complicated than that, you are on your own.

Not very many people can write a convincing interactive screenplay, or explain how to do it.  I recommend you look up Lee Sheldon's writings on Gamasutra or his CGDC tutorials if you are interested in this topic; he is one of very few masters of the genre.

During Production

Of course, this is a lot easier if the designer and the producer are one and the same; however, the skills required for the two positions are quite different, and not everyone can excel at both.  While a good designer/producer may be the single most effective person a game studio can hire, a good team can perform just as well, assuming that both members can keep their egos in check and work collaboratively.

Unless the designer is also the producer, lead artist or lead programmer, he should not be busy full-time on a project which is in production.  This should leave him with plenty of time to start working on the team's next project!