# 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:

• 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 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:

• 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 behavior.
• Lives, health, resurrections and tagging between player characters.
• List of moves, including the secret and special-purpose moves appearing in specific situations.

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 behavior 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 enerate play-by-play text (or audio) files automatically.
• A discussion of game pricing, marketing strategy, and prizes.

# 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 behavior (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.

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:

• 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 modelers 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.

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!

Report Article

## User Feedback

There are no comments to display.

## Create an account

Register a new account

• 2
• 0
• 0
• 1
• 1

• 14
• 10
• 25
• 9
• 57