The Game Design Process

There is no such thing as a "standard" game design document, and for good reason.  It would be insane to try to fit an interactive fiction adventure and a Tetris-like puzzle into the same mold.  However, all forms of entertainment do have a certain number of characteristics in common, and over the years, I have developed a methodology which provides structure to my game design activities and help focus my work.  This page describes, in a nutshell, how I start with an idea and develop it into a finished product which can be handed over to a producer and turned into a game.

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

Depending on the type of game you are creating and on how you expect to get it produced, you may want to develop as many as six different documents at various stages of the creative process.  If it sounds like a lot of work, then you are beginning to get my point ;) The game designer may or may not be qualified to write all of these documents.  A product specification for a computer game, for example, requires considerable input on the part of the game's producer, lead programmer and lead artist, while a screenplay should be crafted by a professional writer.  However, as "guardian of the vision", the designer should have final say on what goes into his product, and be involved in all aspects of the process, if only as an overseer.

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

I have seen several different definitions of the "design treatment", "design proposal", "game outline" or "spec sheet".  Mine is more or less a middle ground between all of them.

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:

As the design treatment is your project's business card, it should be short, factual and representative.  If you have some preliminary sketch art available (i.e., your main characters and a scene or two), by all means, include it.  If your game is going to be a comedy, the text should be funny.  And unless you have a compelling reason to do otherwise, limit the document's size to 4-5 pages of text, plus 2-3 pages of art if available; publishers receive hundreds of these documents, so anything longer may not be read at all.

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

All done?  Your treatment is finished, and you believe that you are sitting on a gold mine?

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

The smart designer never gets too attached to his ideas.  The reason why can be summarized as follows: The situation is a bit rosier in the game console market, but you get the point: smash hits are few and far between, and not necessarily because of flawed designs.  Even if you have really great ideas, they may not turn into a best-seller, because of a problem somewhere in the distribution channel.  If you and your team make good livings and enjoy your work, be content; that's more than many of your peers are able to say.

The Preliminary Design Document

A preliminary design document can be thought of as an organized list of features.  It describes what you want your product to offer in terms of gameplay, technology and look, without worrying too much about how it will be implemented.  (Of course, if you know that something is impossible, save everyone useless aggravation and take it out now!)

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:

I have seen preliminary designs ranging in size between 20 pages (for a shooter) and 60 pages (for a very detailed strategic sports simulation.)

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

Discussions on the preliminary design may lead you to drop some features, scale back others, and introduce new ones.  Once everyone agrees on the functionality the game is going to implement, the design document is ready to go Final.

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 Product Specification

Once the design itself is over, it is time to move to pre-production.  In this step, the designer's job is to work with the producer, the lead artist and the lead programmer to ensure that the project plan being developed will support his vision for the product.

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 producer should devote 2-4 weeks to building the list of materials for a project, and another week to prepare a preliminary schedule.  The designer should be ready to spend the equivalent of 2 weeks of his time supporting this effort.

The Graphic Bible

The graphic bible is a common animation industry tool which the interactive entertainment world would be wise to adopt.  When we started introducing graphic bibles into our design document packages and submitting them to publishers, back in 1996, they were considered a novelty and attracted quite a few compliments.

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

A designer who happens to be an artist can produce the graphic bible, alone or in collaboration with others.  (It is a lot of work.)  Designers without an artistic background should still collaborate and supervise this effort, so as to ensure that the look of the game will be consistent with their vision.

The Screenplay

An interactive screenplay is just like an ordinary movie screenplay, except that instead of a linear list of scenes, you (or the writer you hire) will have to write independent bits and pieces which can be played in a potentially large variety of sequences.  Not only does this make interactive screenwriting very complicated (as it is both imperative and excruciating to ensure consistency), it also makes it long: a typical screenplay for a two-hour interactive movie contains about six hours of material.  Writing an interactive movie typically requires 4 to 6 months of work, depending on the author's level of expertise with the medium.

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

Once production is under way, it will be the producer's responsibility to update the product spec during development, to keep track of the project's progress, re-assign duties to meet important deadlines, etc.   The designer's job will be to make sure that what gets done is satisfactory, and that the producer has all the appropriate information to make his decisions.

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!

By Francois Dominic Laramee