Game Design Documents

(1)

(2)

(3)

Disclaimer

The “Game Design Documents” is a collection of articles found on various sites on the internet. All the content is property of it's authors and no comercial exploitation is intended.

(4)

(5)

Pedersen Principles of Game Design and

Production

by Roger Pedersen Recently, I interviewed for a number of positions (specifically executive producer, producer and game designer) at various game companies. Throughout each interview, many principles learned from my 16+ years of industry experience were recalled. In keeping with my philosophy that game developers should share and exchange information relevant to our industry, I present ten principles of game design and production that everyone in the industry should be acquainted with.

Principle 1: Understand The Role of the Designer

and Producer

It’s vital to know what lines of responsibility are drawn within game development organizations. This knowledge gives you an understanding of which people are responsible for which game components, who makes design and production decisions, and so on.

The game designer. The game designer is the visionary, somewhat like a

book’s author. This person has outlined the scope and description of the product with sufficient detail so that others can understand and develop the product. Just as a book author sees his creation develop differently when made into a film, the game designer needs to accept and solicit modifications from the team members, the publisher and the public during the development process. Often , one of the game designer’s tasks is to create the project Bible – the game’s lengthy technical specification. This document details the gameplay, describes characters and settings (possibly including diagrams or drawings), includes level descriptions and possibly maps of areas to explore, positions and actions for each character or class of character, and so on.

The producer. The producer is the project’s manager, its champion. The

producer must keep the entire team productive and the lines of communication open. This person is a diplomat, a politician, a trouble-shooter, a force needed to produce the product. The producer must keep marketing, advertising and public relations teams up to date with the progress of the game, and honest about its features, performance, and other claims that will be made to consumers. These teams must understand the

(8)

gameplay, its features and story line to generate great ads, media hype, magazine previews, and so on. In return, these non-technical team members, by virtue of their continuous contact with the public, provide the game developers with feedback from the public, magazines and retail channel about what features are currently hot in games.

The producer needs to facilitate communicate between the whole team, and provide timely support for each developer, which includes ensuring that:

• Artists and animators provide artwork, animations, temporary placeholders to the programmers on time, until the final artwork is available.

• Programmers provide the artists with current versions as to see their artwork in a real time gameplay mode. The producer must also make sure that the programmers provide a current version of the game to the sales, public relations and marketing teams, along with various reports about the latest version of the game. These reports describe gameplay, special features, hardware requirements and supported hardware and peripherals, screen shots that best portray the product for ads, promotional sheets, previews and reviews for magazines. The producer also needs to make sure that programmers work with the quality assurance (QA) testers and provide them with the play instructions, special key combinations, hints, undocumented features and actions.

• Audio and sound engineers provide voice, background and atmosphere sounds and music. These engineers also need to view and play the current version to check and validate the timing, usage and clarity of their work.

• The designer (if not a member of the day-to-day team) sees the current version to confirm that the product is in line with the technical specifications and design originally set forth.

• The QA testers report problems to the producer. The problems must be categorized as major (crash, function or action not working), minor (text misspelling, character movement to fast or slow, response time feels wrong), glitches (sound or graphic problem), improvements (add a new feature, improve the character’s interaction or behavior, clarify a confusing aspect of the design or gameplay), a videogame standards issue (the triangle button does not perform as the standard function definition), and multi-platform inconsistency (PC

(9)

version vs. videogame version).

Whether one person assumes the role of both producer and designer, or several people handle these tasks, there must only be one producer whose word is final, whose decisions are followed and whose leadership is trusted and motivating.

Principle 2: No Designer or Producer Is an Island

Gathering information throughout the product development cycle and knowing what to do with it is the trait of a great designer and producer.

Designers should research their subject matter and evaluate outside suggestions and opinions. The audience demands and expects films and books to seem realistic and accurate. The computer and videogame audience should accept nothing less.

When undertaking the development of a sports game (e.g., Baseball), a designer may feel that he knows the sport from playing it as a child and viewing it on TV. However, much more research must be undertaken to create an immersive experience for consumers. Whether the game genre is sports, RPG, adventure or simulation, the first step is to research similar titles in that game genre. You can do this by surfing the Internet, visiting the local store and purchasing competitive games, reading reviews of similar genre titles, collecting marketing materials and advertisements from other publishers’ websites, and so on. This information is invaluable when you are designing a new product.

If you are the producer of an upcoming baseball game, you ought to know the common elements found in other Baseball titles, as well as special features that differentiate each product from its competitors. You should read reviews of similar titles and the competing titles’ list of features. From this freely collected information, a designer can understand which features and game play customers expect, special features that the competition offers, and the criteria upon which the reviewers will base their critiques.

As the designer and/or producer, you must ask yourself:

• Does your game suffer the same poor or awkward design flaw as a previously released title or similar genre titles? The design of the game needs to address how to be better than its competitors. The design must be able to handle flaws, difficulties and problems that

(10)

reviewers and customers have complained about in previous versions of this product or in other similar genre titles. As the decision maker, you must listen to your development team, your marketing and sales team, retailers, and your game playing audience.

• Do the ideas of the game designer and the team outweigh those of the reviewer(s)? The ideas that are made must have a good foundation. All reviewers try to accurately explain and criticize the product to the public. There’s a real difference between discarding a reviewer’s opinion and listing the problems and how your design addresses each one.

• Does the design consideration include comments from previous or potential customers? Customers enjoy great products. My experience (in producing sports, gambling and trivia/puzzle titles) indicates that customers (fans) will buy any product in the genre they enjoy. Their expectations are that your product will teach the something new about the activity, they will gain experience and be able to brag to their friends and associates, and/or that they’ll be able to someday beat the game. I’ve received a great deal of fan mail in which consumers have cited the aspects of my games that they enjoyed. These letters also tell me what additions to the game that they would like to see in future releases. Magazines publish reader’s letters that praise and criticize the products. Market research and beta test groups consisting of potential and previous customers can be worthwhile in the final design stages to tweak the product before its release.

• Are the team’s ideas and opinions seriously evaluated in the design of the product? See Principle #3 for more information about this. • Can the addition of a feature expand the customer base and get more

publicity?

In Villa Crespo Software’s Flicks, a product that reviewed 30,000 films, a field for "close-caption" was added during the development, instantly adding four million hearing-impaired and non-English speaking audiences to the product’s customer base. Newsletters reaching that consumer sector gave the product free, positive reviews because the product included information vital to their readership.

The producer should collect information from team members about improvements that can be made to the product, and relay this information to

(11)

the designer. The producer must be able to recognize a good idea when he hears it, and implement that idea in the game to make it a better product.

Designers should be adaptable and open minded to ideas that can make their games better. Producers need to be managers, leaders, and diplomats who can take information and in getting good suggestions understood by all involved with the final decisions.

Principle 3: Let Professionals do Their Jobs

Most projects have a team of talented professionals working on them, made up of designers, programmers, graphic artists, audio technicians, testers, marketing coordinators, and so on. Each of these team members brings their own unique, important talents to bear on the project. A producer and designer must rely on these professionals and their particular points of view to improve and facilitate the development process. Regardless of the product’s genre, each member can make a product better.

For instance, the quality assurance (QA) and testing people can suggest gameplay improvements before the product is shipped. No member of the team plays the game for hours at a time like a QA person does, therefore his/her suggestions are similar to that of the potential customer. In fact, members of the QA team have probably played more games in a particular genre than the rest of the team combined.

The producer must not only trust his team members, but also rely on them for input to create the best product.

Principle 4: KISS (Keep It Simple Stupid)

Every aspect of a product should be obvious and easy to understand. For instance, allowing players to access every option within two button clicks may be simpler than having thirty-seven unique keys to press. Forcing a player to press Alt-Ctrl-Shift A to get his character to kick an opponent would be ridiculous. Likewise, having to press "A," "B," "C" and "D" to control the movements of a plane in a flight simulator would drive the average player crazy. If a player has to repeatedly press four keys to perform a task, the game design should include a super key or a one-key macro to simplify the operation.

(12)

manufacturer, and the president of this company taught me a valuable lesson about design. He said if a player doesn’t grasp the interface of a computer game or videogame, that player will read the manual since $50 (or so) was invested in the game. With arcade games however, the player has only invested a quarter or two, so if the game isn’t understandable, addictive and compelling, the player moves on to the next machine. Who cares about wasting pocket change? While this is especially critical for arcade games, I think it’s important to remember when designing games for any platform.

Principle 5: Schedules Are Like Laws

Schedule are like laws; they are created by legislative bodies and meant to be obeyed, but they are also designed to allow exceptions if evidence warrants special circumstances.

Likewise, milestones are created at the beginning of the project may need to be changed based on problems that occur during development. For instance, the decision to change the original game specification (e.g., to support a new computer, a new 3D card, alter pre-planned artwork or audio clips) in order to make a better product is a situation which may warrant "breaking the law" that schedule spells out.

If another month of development time would greatly improve the gameplay, remove non-show-stopping bugs or allow for better visuals or audio effects, then circumstances justify deviating the schedule. To ship a game on a target day, month, or year regardless of the state of the product at that time can spell disaster for that product (not too mention the harm it does to the publisher’s reputation). Missing seasonal dates like Christmas is bad, but shipping buggy or a poorly made product is worse.

You should only modify a project schedule if there are valid reasons. The team and publisher must agree that the additional time will substantially benefit the product.

Principle 6: The Yardstick: One Day’s Pay for a

Week’s Worth of Fun

If a customer pays $50 (plus tax) for a game that I’ve worked on, that amounts to the average person’s one day net pay. (A person earning $21K a year brings home $14K which is $54 a day.) If the player reports enjoying the game that I worked on for at least one week, then I am happy. If the player

(13)

feels ripped off due to poor game design, numerous bugs, obstacles in playing the game (e.g., multi-CD swaps, memorizing numerous keystrokes, and so on), poor audio, or some other problem, then the game designer and any team members who knew of these problems beforehand are to blame.

Every member of the team should be proud of their product. They should consider the praise from consumers, reviewers and the industry as their reward for they time and work they spent on the game.

Principle 7: I Never Met a Genre That I Didn’t Like

A student who doesn’t enjoy math can study hard and still earn an "A" in class. Similarly, a designer or producer does not have to have experience working on a particular genre to create a good game within that genre. In fact, a designer or producer doesn’t have to even be an enthusiast of that genre in order to get good results. Putting together a team in which at least one member enjoys the genre (or studying competing products of the genre) is what is critical.

Often just one enthusiastic team member can show similar games that he/she has enjoyed, and thereby turn every team member into a knowledgeable player of the genre. Combining fanatical genre loyalists along with non-genre players on the development team can result in benefits you may not have considered. For instance, a non-genre player can suggest modifications to a game’s design by pointing out aspects of the genre he finds unappealing, whereas a fanatic of the genre can lend his expertise and advice to keep a game faithful to the genre.

A knowledgeable developer or producer may ask the entire team to play similar games in that genre and ask each team member to critique the products. This technique can help the development of your product, and it’s time well spent.

Principle 8: Be True to Your License

Games based on licensed products often cause players to make certain assumptions about those titles. There are preconceptions about the gameplay, content, and target audience. In stores, it’s the licensed titles that get noticed first, regardless of their marketing and advertising. Game designers must understand this customer mentality. The designer must understand everything about that license in order to provide the kind of

(14)

entertainment that the target consumers have anticipated.

For instance, a baseball game that uses a particular baseball team’s manager in its title suggests a strategy sports game. Players would probably assume that they would be responsible for making decisions about the players and batting order. On the other hand, a licensed product linked to a professional baseball player would suggest an emphasis on sports action, such as pitching and batting.

There’s a reason why licenses cost big bucks. Designers and producers must use the license, its characters, and leverage consumer preconceptions to title’s benefit.

Principle 9: Share Your Toys!

Throughout the years, many game developers have bounced ideas off me, asked me questions, and so on. I have, and will always, welcome these inquiries because I believe it’s for the greater good of the industry. Since I have always been interested in creating and exploring ideas, I feel that when someone wants information, I’ll gladly help. Three occasions in particular are worth relating:

• In 1985, an auto mechanic who owned an Atari 520ST called me and to pick my brain about game design and various game projects he was working on. For several months we talked, and often he sent me samples of his artwork as well as demos of the concepts we’d discuss. Sometime around 1987, he had an interview with a major publisher and discussed taking the demos and artwork with him. I encouraged him and wish him success. A few weeks later, he announced that he was hired as "platform level" designer. Within months, he became the top "platform level" game designer for this company, and he worked on the most well-known titles in the industry. He eventually left this publisher to join another equally large publisher as the head of game design. He appeared in several magazines displaying his platform level designs. To this day, I’ve never met him and have only seen him in the magazine articles that he sent me, but I feel very happy that I was a small influence in his life and in the industry.

• When I was working on All Dogs Go To Heaven, a game for the PC and Amiga based on the Don Bluth film, I met a young man who worked at an arcade. On several occasions, I gave him $10 in tokens

(15)

to show me the latest video games. As he played, I observed him and asked questions like, "How did you know to do that?". After we got to know each other better, he showed me several comic book sketches that he had drawn, which were great. When I was contracted to produce and develop All Dogs Go To Heaven, I asked him to do all the artwork. Since he was new to computer graphics and animation, I taught him the mechanics of using a Summagraphics Tablet and the functions and features of various graphics packages. He learned quickly and produced some of the finest artwork that CGA and EGA would allow. After the release of this title, he went to work for a Florida publisher as a computer and videogame graphic artist. When the company moved to California, he moved with them. The last I heard, he was moving on into one of the big publishers as a senior graphics person.

• A high school student sent me a concept for a game show. The description read well, but the demo he sent me was terrible. Over several months on the phone, we fixed many of the game’s rules and aspects of the gameplay which greatly improve the game show. I programmed the game, and hired an artist to provide the graphics. When I went to Villa Crespo Software outside of Chicago, we published this game show, which we called Combination Lock. The game was fun to play and it was the first product to feature on-screen players of all races. The high school student and I shared in the profits for several years.

The reason that I relate these stories is that I want to emphasize the benefit to those who help budding game developers. When the opportunity to help someone comes knocking on the door, offer that person hospitality and kindness. The results will benefit the "seeker of knowledge," will honor you "the master", and will benefit the industry as more creative thinkers join in.

Principle 10: There’s No Magic Formula for

Success.

Keep in mind that no one individual or company of any size has discovered the formula for "what makes a successful product." Like film, art and music, games appeal to a variety of consumer tastes, and of course taste is subjective.

(16)

underlying technology that their game used. Other developers claim that their game transported the player into a surreal and immersive universe. Yet others feel that their game’s success was due to the way it engrossed the player in a realistic simulation, challenged them with its compelling design , or simply made a great game accidentally. Behind each successful title is a unique list of traits that made it popular with consumers.

The bottom line is simple. A well-designed product based on a team effort with an user-friendly interface developed within a reasonable time frame will be successful.

(17)

Creating A Great Design Document

by Tzvi Freeman I've got to get product out. In the panic and dizziness, my head smashes against the CRT and next thing I know this genie whiffs up out of a virtual bronze-texture-mapped lamp and offers me three wishes. Without missing a beat, I answer, "I need...

• A great team of talented, skilled, and dedicated engineers and artists (including a very understanding wife) with strong interpersonal skills. • Enough time and money to allow for a mess-up or two.

• A first class design document.

Once upon a time, when coding a game involved one programmer (and maybe an artist) with a take-it-as-you-go budget and a loose deadline, documentation didn't need to be taken so seriously. You knew what you wanted to make and you made it. If there were a few major changes along the way, the only one to complain was you. Nowadays, a thorough and readable document can mean the difference between a swift descent to budgetless Hell and a smooth ride to shrinked-wrapped Nirvana.

How the System Works

Most games go through three development stages, from concept to design to production. Think of them as "flash," "paper," and "grind."

In the first stage, the concept paper acts both as a letter to yourself -setting out your goals clearly so you won't lose sight of them - and as a sales tool for whomever takes the product to market down the road. Sometimes, this stage involves a working mini-prototype as well, which gives you a chance to experiment and revise your ideas.

The intermediate stage of design involves a lot of discussions with artists, animators, musicians, and engineers - trying things out, and finding ways to organize and set down your ideas.

In the final stage, production management is often left up to some expert in moving trains and tracks without major collisions. The original designer may be an integral part of the team, but in many cases - especially

(18)

in large companies - the designer ends up as a kind of outside consultant. Without question, the design document is where the original parent of the project exercises the most influence on how this little baby is going to grow up. Even if you, the designer, have decided to double as project manager, don't delude yourself into thinking that you hold all the reins. A complex project involves many talented people. Skilled programmers and artists tend to have minds of their own. While you intend to create a horse, the artist may be envisioning a unicorn and the programmer a highly efficient camel. A good document ensures that you are all planning to make the same thing. A great document ensures you all have the same feel for the inner soul of this thing. Think of it as a big band jazz score - it puts everybody's mind in the same place, even when there's still plenty of room for the stars to improvise.

Your document is a sort of intermediary between your mind and the real world. It ensures that what you have in mind is something that the real world is able to handle, and that what you end up with will be what you originally had in mind.

Finally, remember the adage to which any salty gamer will attest: "Great art is in the details." Brilliant details flow naturally from the general gestalt as though they were present in that first flash of inspiration. But once you get into the hands-on implementation, it's easy to lose that spark.

The Challenge

Prototyping parts of the project yourself is definitely a good idea -make whatever rough sketches you can. But again, it's those details that count. The more details your imagination can hold, the greater a masterpiece your work will be.

Working from a document has a flip side, as well. Developing an exciting game has to be exciting. Some of the best parts of many projects were discovered in the heat of last-minute deadline panic. True, the pressures of time and cost budgeting don't allow for perpetual reiteration of concept, but you simply cannot expect a killer game to come out of dry, predictable work. The challenge is to create a design document that will allow your project to tolerate surprise adaptations without losing the integrity of its original direction and scope.

(19)

Contents Purpose 1. Concept

Paper Genre; target audience; description; most compelling features; market information; cost and time to develop.

It defines the concept, scope, worthiness and feasibility; sells the idea to your client, publisher, employer, and venture capitalist. 2. Design

Document Description of the body and soul of the entire project, with all the details, and the method by which each element will be implemented.

It ensures that what is produced is what you want to produce.

3. Production

Documents Time-management charts (Gantt, PERT, and so on); task database; budget spreadsheet; technical specifications; Q/A database.

It implements the design document on time and within budget.

Ten Points for a Successful Design Document

1. Describe Not Just the Body, But the Soul

If game development was just an automated input/output issue something like writing code and being able to predict how it's going to work -you could get by with a dry, descriptive document. The reality is that development is done by people, many of them creative people, who have their own minds; most will want to leave a stamp of that mind on everything they do.

It works like this: You provide specs to the artists and discuss with them what to do. You then visit the programmers and go over their specs. Both groups nod to everything you say.

That night, around 2AM, just as the constellation of C++ is rising in the west, the programmer reaches a mid-life crisis and begins to think, "What, a geek programmer the rest of my life? Is this what my mother expected from me? Why, I can design a game just as well as anybody else!" And the hands keep typing code.

(20)

Around the same time, the artist has just woken up before his machine, having fallen into a deep stupor while waiting for a complex 3D rendering to finish. Unsure and not really caring whether he's dreaming or is actually getting paid for all this, immersed in that wild world of artistic genius where fantasy and reality blend as one, the phosphors come together in ways previously unimagined - certainly not by you.

By the next morning, your horse has become a unicorn with two humps. With creative people, instructing is not good enough. You need to inspire.

In your design document, don't satisfy yourself with a detailed description of every article and nuance. Take time to describe the feel that the game should have, the purpose behind each element, the experience each user will have, and any other aspects of the game's soul you can envision and describe.

For example, say you're designing a shooter. You want to train your players to deal with certain challenges before they actually meet them, so you place less lethal mini-challenges a few steps in advance. You're going to have to explain that to everybody on the development team, so they'll understand why certain things are where they are and why they work the way they do. That way, even if (read: when) your team toys with and mangles your ideas as they exist on paper, you can still harbor hopes that the outcome will have the same or similar overall effect. Or maybe even better.

2. Make It Readable

Go ahead, provide your people with full pages of 10-point, sans serif, 80-characters-per-line text, and demand that they read it. You may want to bundle Advil in the package - for those who actually take the pains to obey orders.

• I try to follow at least some of the guidelines of good page layout: • Plenty of white space

• Serif font for body text • Bold headers

• Spaces between paragraphs • Short lines of text

(21)

• Direct the eye towards important material

Many instances call for a table, spreadsheet, or chart. Use them and make them sensibly attractive.

3. Prioritize

Now that you realize that you're working with other conscious egos, you'll appreciate the urgency of tagging certain game elements as sacred. True, there are no guarantees, but if you use the tag sparsely enough, it may get some respect. But don't stop there. As long as you're tagging ideas, you'll also want to distinguish between things that you intend to do and things that you'd like to do if time, budget, skill sets, and technicalities permit.

Then there's the trash bin - things that sounded great, but were trashed for good reason. Refer to them explicitly and explain the reason that they were trashed. If you don't, I can almost guarantee that they will be resurrected. Here's your list of tags:

• Indispensable • Important • If Possible • Rejected

You may wish to use visual symbols to represent these. Don't rely on color, since documents aren't always printed in color.

4. Get Into the Details

A document without details is useless. Generalities can be interpreted by anybody in any way that they like. "Thou Shalt Not Kill" meant one thing to Moses and another to a Spanish conquistador. Detailing whom you shouldn't kill and under which circumstances would have been more helpful. The same holds true for your document: Once you've described some practical details and given some examples, your idea becomes more concrete - and harder to shove around.

For example, don't just say, "Bronze bird is invincible." Describe exactly what happens to this creature in each possible instance of its being hit, and how it recovers afterward. True, if the animator has any spunk and artistic

(22)

dignity, you can rest assured that he won't follow your specifications. But at least he'll have a clear idea of what you want to achieve, and his modifications won't seriously alter the related portions of the game.

Don't just say, "At this point, users will have to press the jump key with the arrow key to climb the wall." Describe what will happen if a player tries anything else. Explain why you think users will be able to figure out the combination that you've provided. Explain what about the environment suggests that it's possible to climb this wall.

Again, your artist will come up with something else, perhaps something even more suitable than what you originally conceived. That's real success: When your developers' results come out even closer to your original flash of conception than what you were able to describe on paper. But this won't happen unless you first lucidly describe your concept.

Don't just say, "Bongo Man is stronger than Bongo Boy, but Boy has faster reflexes." Use tables, spreadsheets, and charts to assign real values to the character's speed of movement, how many hits the character can take, how much damage the character's hits do, how many cels it takes to animate a hit, and so on. This sort of spreadsheet is invaluable in the Q/A and tweaking stages of production.

Don't just say, "Most people will figure out the whole game in a few days." Make a chart of predicted product life in different households, indicating at which points in time you expect various features to be discovered. User testing will later provide valuable feedback for designing your next game.

5. Some Things Must Be Demonstrated

Sometimes a few rough sketches are enough, but if the idea is truly important to your concept of the project, you may want to make a rough animation yourself. When behaviors of elements become too complex and ambiguous to describe on paper, you'll want to make a prototype. A side benefit of prototyping is that this practice often leads to a simpler, more elegant solution.

Even when you provide animations and prototypes, put the concept in words as well. True, an animation is worth a gigabyte of words, but words can communicate in ways that animations can't. Words also clearly spell out the vital nuances that may be missed when watching the animation.

(23)

6. Not Just “What” But “How”

In the real world, the "how" determines the "what." For example, suppose you've opted for claymation. Work out the process of how the images will be captured and document everything. What material and what color should the backdrop be? What camera should be used and why? What are the steps for processing the captured frames? And on and on. If you've tried it, you'll know that any one of these factors can have a serious impact on the end result.

Or suppose you're working on a motorcycle racing game. You state that the motorbikes must be balanced by their differing pros and cons. You even provide a chart that shows how balanced they are. Then you state that tweaking will be necessary. State how you plan to tweak - what is the process? Suppose the main character in your game is the Phantom of the Opera. Describe how the player's keyboard is mapped as a pipe organ. Provide a map of each key. Specify how many channels of sound will be available. Talk it over with your programmer and work out every detail of how. Then document it. Two different "hows" can mean two very different results.

7. Provide Alternatives

Project managers spend a lot of time with their Gantts and PERTs. Personally, I can't really say that this stuff is effective for game development -principally because there are just so many unknowables. The more radical and pioneering your game technology, the less predictable the development stream is going to be. The best thing you can do to ensure that your team reaches your milestones on schedule is to provide more than one way of doing things.

Lets go back to the keyboard as pipe organ example. Your engineer describes to you the ultimate method of getting awesome and funky results with tremendous power and depth to the user - at a cost of about 50 person-hours to implement. As with everything else we've discussed, you document the whole thing.

You can't stop there. You've got to ask, "What would it take if we just wanted a trimmed-down, eight-channel pipe-organ? And what will we need to achieve the bare minimum? And what if we just had some assistant doing this?" And then you document all that as well. When the FedEx truck is on its way over for the final daily pickup, you'll be able to save your skin with a

(24)

simple, "OK, do Plan C."

One of the biggest mistakes I've made in product design is asking engineers, "Can it be done?" Unless you're asking a first-class programmer, the question is useless. More specifically, responses fall into one of three categories:

• Lousy programmer: "Sure, that's no problem." • Mediocre programmer: "Nope. Can't be done."

• First-class programmer: "I could do it like this and it'll take two weeks. Or I could make a slight modification like this and it'll take five hours."

Always ask for more than one alternative and an estimate of how long each will take. Then indicate your preference - do this is if we have time, or this if we don't.

8. Give It Life

I've already warned you against strangling the inspiration and spontaneous creativity that comes with the excitement and fun of seeing ideas become living objects in your hands. You've got to allow your document to tolerate change - by you or by (hopefully intelligent) others.

I first learned this lesson as a music composition major at the University of British Columbia. With much toil, I had written a neo-renaissance brass quintet of which I was quite proud. My professor liked it, too. When we brought it to the college's star brass quintet for rehearsal, however, I passed through several stages of horror, disbelief, indignation, and clinical depression within ten seconds. The quintet began to play, then stopped on signal from the tuba player. The fellow took out his pencil and began to change a few notes, and then everyone continued. It happened more than once.

My professor, noting my sudden faint state of health, turned to me and commented, "Don't worry, they did that to Mozart as well. And they're usually right."

The fact is, no matter how good something looks on paper, the greatest expert still modifies things when it enters the concrete world of objective perception. Nevertheless, you don't want to witness the ruthless rape of your

(25)

design and dreams. Rather, you're hoping for a kind of organic growth - ideas growing naturally out of the seeds you've planted without needing foreign limbs and bodies grafted onto them.

Here are some tips for creating a document that can tolerate change without corrupting the original idea or sabotaging the development process:

• Make certain to engrave in stone those aspects that are so essential to the game concept that they must not be changed.

• Make certain everybody understands the feel that the game is supposed to have and the purpose of each of its details.

• If information is repeated, it must be cross-referenced. Otherwise, if there are changes, you can end up with contradictory instructions. And here are some tips for the actual implementation stage:

• When a change is suggested, check back in your design document and see if it is in concordance with the "soul" of your game.

• Check whether this is just an isolated change, or it's of major global ecological impact (see "The Ecology of Improvement"). If it's the latter, save it for your next project.

• Update the design document and include the reasons for the change. Or if you didn't make the change, say so and explain why it was rejected.

• Changes, deletions, and rejected ideas should be retained in a master document to avoid discussing the same thing twice.

• Everyone must be working from the same version. Past versions should be destroyed.

• Crucial, Vital, and Urgent: The design document must be maintained under one person's supervision only.

9. Nobody Should Be Able to Say, “I Did It That Way

Because I Couldn't Find Any Reference to It In the

Document”

(26)

then they complain that people didn't follow instructions. Every good word processor will auto-number pages and print the date and title in the header or footer of every page. Some will even allow you to change the header at new chapters. Use bold text to direct attention to important material. Repeat yourself in different parts of the document as much as you like, as long as you cross-reference so you can update everything together as well. Make a thorough Table of Contents.

You may wish to write your document using HTML and provide hot links. Some progressive word processors provide hot link capabilities without HTML. But remember that more often than not, people prefer to work from a hard copy. (That way there's something to read while rebooting after the hourly system crash.)

10. Deliver It In Good Condition

After all this, you need to do whatever you can to facilitate everyone actually reading and using the thing. A pile of papers doesn't get read - it doesn't look important enough. Only things with hard covers look important.

Create a list of everyone who is supposed to have a copy. Keep the list. Print out the whole thing with the date in the header of each page. Have holes made and put it in binders. Label the spine and cover of each binder. When there are updates, provide everyone with the revised pages. At some points, you may need to provide new books and throw out the old ones.

In Sum Check…

Movie makers use move scripts. Architects use blueprints. Musicians use a score. According to ancient hearsay evidence, even the Cosmic Creator created a design document - which He later let a few prophets take a peek at - before the primal "Let there be light!" So game developers, following their Supernal Role Model, can certainly do the same. Do it right and it's smooth sailing the rest of the way.

(27)

Documentation Guidelines for the Game

Concept and Proposal

by Tim Ryan The purpose of design documentation is to express the vision for the game, describe the contents, and present a plan for implementation. A design document is a bible from which the producer preaches the goal, through which the designers champion their ideas, and from which the artists and programmers get their instructions and express their expertise. Unfortunately, design documents are sometimes ignored or fall short of their purpose, failing the producers, designers, artists, or programmers in one way or another. This article will help you make sure that your design document meets the needs of the project and the team. It presents guidelines for creating the various parts of a design document. These guidelines will also serve to instill procedures in your development project for ensuring the timely completion of a quality game.

The intended audience is persons charged with writing or reviewing design documentation who are not new to game development but may be writing documents for the first time or are looking to improve them.

Design documents come in stages that follow the steps in the development process. In this first of a two-part series of articles, I'll describe the purpose of documentation and the benefits of guidelines and provide documentation guidelines for the first two steps in the process - writing a concept document and submitting a game proposal. In the next part, I'll provide guidelines for the functional specification, technical specification and level designs.

The Purpose of Documentation

In broad terms, the purpose of documentation is to communicate the vision in sufficient detail to implement it. It removes the awkwardness of programmers, designers and artists coming to the producers and designers and asking what they should be doing. It keeps them from programming or animating in a box, with no knowledge of how or if their work is applicable or integrates with the work of others. Thus it reduces wasted efforts and confusion.

(28)

Documentation means different things to different members of the team. To a producer, it's a bible from which he should preach. If the producer doesn't bless the design documents or make his team read them, then they are next to worthless. To a designer they are a way of fleshing out the producer's vision and providing specific details on how the game will function. The lead designer is the principle author of all the documentation with the exception of the technical specification, which is written by the senior programmer or technical director. To a programmer and artist, they are instructions for implementation; yet also a way to express their expertise in formalizing the design and list of art and coding tasks. Design documentation should be a team effort, because almost everyone on the team plays games and can make great contributions to the design.

Documentation does not remove the need for design meetings or electronic discussions. Getting people into a room or similarly getting everyone's opinion on an idea or a plan before it's fully documented is often a faster way of reaching a consensus on what's right for the game. Design documents merely express the consensus, flesh out the ideas, and eliminate the vagueness. They themselves are discussion pieces. Though they strive to cement ideas and plans, they are not carved in stone. By commenting on them and editing them, people can exchange ideas more clearly.

The Benefits of Guidelines

Adhering to specific guidelines will strongly benefit all of your projects. They eliminate the hype, increase clarity, ensure that certain procedures are followed, and make it easier to draft schedules and test plans.

Elimination of Hype

Guidelines eliminate hype by forcing the designers to define the substantial elements of the game and scale back their ethereal, far-reaching pipe dreams to something doable.

Clarity and Certainty

Guidelines promote clarity and certainty in the design process. They create uniformity, making documents easier to read. They also make documents easier to write, as the writers know what's expected of them.

(29)

Guidelines ensure that certain processes or procedures are followed in the development of the documentation - processes such as market research, a technical evaluation, and a deep and thorough exploration and dissemination of the vision.

Ease of Drafting Schedules and Test Plans

Design documents that follow specific guidelines are easy to translate to tasks on a schedule. The document lists the art and sound requirements for the artists and composers. It breaks up the story into distinct levels for the level designers and lists game objects that require data entry and scripting. It identifies the distinct program areas and procedures for the programmers. Lastly, it identifies game elements, features, and functions that the quality assurance team should add to its test plan.

Varying from the Guidelines

The uniqueness of your project may dictate that you abandon certain guidelines and strictly adhere to others. A porting project is often a no-brainer and may not require any documentation beyond a technical specification if no changes to the design are involved. Sequels (such as Wing Commander II, III, and so on) and other known designs (such as Monopoly or poker) may not require a thorough explanation of the game mechanics, but may instead refer the readers to the existing games or design documents. Only the specifics of the particular implementation need to be documented.

Guidelines for the Game Concept

A game-concept document expresses the core idea of the game. It's a one- to two-page document that's necessarily brief and simple in order to encourage a flow of ideas. The target audience for the game concept is all those to whom you want to describe your game, but particularly those responsible for advancing the idea to the next step: a formal game proposal.

Typically, all concepts are presented to the director of product development (or executive producer) before they get outside of the product development department. The director will determine whether or not the idea has merit and will either toss it or dedicate some resources to developing the game proposal.

(30)

The director might like the concept but still request some changes. He or she may toss the concept around among the design staff and producers or open it up to the whole department or company. The concept can become considerably more compelling with the imagination and exuberance of a wide group of talented people.

A game concept should include the following features: • Introduction • Background (optional) • Description • Key features • Genre • Platform(s)

• Concept art (optional)

Introduction

The introduction to your game concept contains what are probably the most important words in the document - these words will sell the document to the reader. In one sentence, try to describe the game in an excited manner. Include the title, genre, direction, setting, edge, platform, and any other meaningful bits of information that cannot wait until the next sentence. The edge is what's going to set this game apart from the other games in the genre. For example:

"Man or Machine is a first-person shooter for the PC that uses the proven Quake II engine to thrust players into the role of an android space marine caught up in the epic saga of the interstellar techno-wars of the thirty-seventh century."

Breaking the introduction up into several sentences for the sake of clarity is acceptable. Just know that the longer your introduction, the more diluted your vision will seem.

Background

(31)

other products, projects, licenses, or other properties that may be mentioned in the introduction; so it's optional. The background section is physically separated from the introduction so that readers can skip it if they already have the information presented. But the background section is important for licensed properties and sequels and concepts with strong influences from previously released titles in the same genre. If you intend to use an existing set of code or tools or to license a game engine, then describe these items and their success stories here.

Description

In a few paragraphs or a page, describe the game to the readers as if they are the players. Use the second-person perspective -- "you." Try to make this section an exciting narrative of the player's experience. Encompass all the key elements that define the core game play by describing exactly what the player does and sees. Avoid specifics such as mouse-clicks and keystrokes, but don't be too vague. You want the readers to become the player's character. Hover your detail level right above the GUI interaction. You would say something such as, "You scan your tactical radar and pick up two more bogies coming up the rear," instead of "You click on your tactical radar button and the window pops up revealing two bogies coming up the rear." The description section should make the content and entertainment value of the game obvious and convincing.

Key Features

Your game concept's key features section is a bullet point list of items that will set this game apart from others and provide goals to which the subsequent documentation and implementation should aspire. It's a summary of the features alluded to in the description. These bullet points are what would appear on the back of the game box or on a sell sheet, but include some supporting details. For example:

"Advanced Artificial Intelligence (AI): Man or Machine will recreate and advance the challenging and realistic AI that made Half-Life game of the year."

Determining how many features to list is a delicate balancing act. Listing only one or two key features is a bad idea if you're doing anything more complex than a puzzle game; listing more than a page of features implies that the project would be a Herculean task and may scare off the bean counters. Listing too few features might sell your concept short; listing

(32)

too many waters down the concepts' strongest features.

Keep in mind that you need not list features that are given, such as "great graphics" and "compelling music," unless you really think such features are going to be far superior to those of the competition. Great graphics, compelling music, and the like are the understood goals of every game project. On the other hand, if the particular flavor of graphics and music provides your game with an edge in the market, then you should spell that out.

Genre

In a few words, define the game genre and flavor. Use existing games' classifications from magazines and awards as a guide. For example, you could choose one of the following: sports, real-time strategy, first-person shooter, puzzle, racing simulation, adventure, role-playing game, flight simulation, racing shooter, god simulation, strategy, action-strategy, turn-based strategy, side-scrolling shooter, edutainment, or flight shooter. Then you can refine your game's niche genre with these or other words for flavor: modern, WWII, alternate reality, post-apocalyptic, futuristic, sci-fi, fantasy, medieval, ancient, space, cyberpunk, and so on.

Platform(s)

In a few words, list the target platform(s). If you think the game concept is applicable to multiple platforms, you should also indicate which platform is preferred or initial. If you intend multiplayer support on the Internet, indicate that as well.

Concept Art

A little bit of art helps sell the idea and puts the readers in the right frame of mind. Use art to convey unique or complex ideas. Screen mock-ups go a long way to express your vision. Art for the game concept may be beyond most employees' capabilities, so requiring it would limit the number of submissions; thus, it is optional. If a concept has merit, the art can come later from a skilled resource. Often art from previous projects or off of the Internet will jazz up a document. Just be careful with any copyrighted material.

(33)

Common Mistakes

Here are some common mistakes that developers make in creating a game concept:

The Concept Is Totally Off Base or Inapplicable to the

Company's Current Plans

If you don't want to waste your time writing up concepts that get tossed, find out what the company in question is looking for and keep an ear to the ground for opportunities with which your idea may be a good fit.

In Terms of Resources, the Document Asks for the Moon

Try to keep your concept within the realm of possibility. Keeping the budgets down by suggesting existing tools or properties to reuse is helpful. Limit your ideas to that which can be accomplished in a timely fashion and with a reasonable budget. Limit experimental technologies to one area. Don't suggest revolutionary AI as well as a new, state-of-the-art 3D engine. If you are being solicited to produce the game concept, find out what the time frame and budget expectations are first.

The Document Lacks Content

Simply saying, "It's Command & Conquer meets MechWarrior where you order your 'Mechs in tactical combat," is insufficient. Your description has to explain the actions that the player will perform and make them seem fun. A good description might read, for example, "You order your 'Mech to fire at point-blank range on the exposed right torso of the Clan MadCat OmniMech." This kind of descriptive content will help mitigate misinterpretations of the core game play that you envision.

The Game Isn't Fun

A useful exercise is to break down all of the player verbs (such as shoot, command, run, purchase, build, and look) and envision how player performs each. Then, for each verb, ask yourself if it's fun. Then ask yourself if the target market would find it fun. Be objective. If the action that the player takes isn't fun, figure out another action for the player to take that is fun or

(34)

drop the verb entirely.

The Game-Concept Document Employs Poor Language and

Grammar

Don't make yourself look like an ass or an idiot. Check your grammar and spelling and avoid four-letter words and sexual innuendo. You don't know who will ultimately read your document or whom you might offend with some particularly expressive words. Even the macho, politically incorrect, culturally insensitive, slang-using manager with whom you exchange dirty jokes over a beer at lunchtime can get quite sensitive with documented verbiage.

The Designer Gives Up

Don't give up submitting ideas. You never know when one of them will take off. Persistence pays off, believe me.

Guidelines for the Game Proposal

A game proposal is a formal project proposal used to secure funding and resources for a game development project. As a game proposal takes time (and therefore, money) to do correctly, it should only be developed for promising game concepts.

The proposal is an expansion upon the game concept. Writing a proposal may involve gathering feedback and information from other departments, especially the marketing department (if it exists). You may need your marketing department to perform some market research and analysis on the concept. If the game requires licensing, you may need your finance and legal departments to investigate the availability and costs involved in securing the license.

The programming staff, typically senior programmers or the technical director, should perform an initial technical evaluation of the concept. They should comment on the technical feasibility of the concept and the programming areas that may require research. They should assess the risks and major tasks in the project and suggest solutions and alternatives. They should give a rough estimate as to the required research and development time and resources.

(35)

The game proposal should include a revised version of the game concept. Technical, marketing, and finance feedback to the concept document might force you to scale back the concept. It might also suggest modifying or adding features. These changes should not take anyone by surprise, as this is the first time that the concept has been subjected to major criticism and the collaborative process. Giving copies of the feedback and analysis to the director of development (or whoever asked for the game proposal) before they are folded into the game proposal or effect changes in the concept is a good idea. This process not only provides written confirmation that the concept has been reviewed by certain people or departments, but it arms the director with the knowledge to veto, alter, or otherwise approve any proposed changes.

The game proposal includes the following features: • Revised game concept (preceding)

• Market analysis • Technical analysis

• Legal analysis (if applicable) • Cost and revenue projections • Art

Market Analysis

The marketing department and/or a market research firm, assuming your company can afford it, should compile this information. If you are compiling this information yourself, you should try to avoid pure guesses on numbers. Look for info on the Internet (www.gamestats.com is a good source) and use existing hits in the same genre as indicators for market performance.

• Target market: The target market is defined by the genre and the platform, issues that have been already addressed in the concept document. You can qualify this definition by mentioning specific titles that epitomize this market. The most successful of these titles will indicate the viability and size of the market. Also mention the typical age range, gender, and any other key characteristics. If this game involves a licensed property or is a sequel, describe the existing market.

(36)

sales numbers in terms of units, breaking out any notable data-disk numbers and any successful sequels. Include their ship date. You can be vague -- Q1 1998 or spring 1998. This research can go way back, so present your data in chronological order.

List their platforms if they vary from the platform for the proposed game. However, because the markets change depending on the platform, you should always present some title of the same genre on the target platform, even if it didn't perform as well as the others. Such data may indicate a sluggishness for that particular genre of games on the platform. For example, turn-based strategy games may have great sales on the PC platform, but have terrible numbers on the Sony PlayStation. This list of top performers should indicate this discrepancy if you're doing a turn-based strategy game.

• Feature comparison: Break down the selling features of these top performers. Compare and contrast them to the key features described in the concept document. Try to provide some specifics. For example: Tactical Combat: In Command & Conquer, Dark Reign, and Myth, you order your units to attack specific targets and move to specific places or ranges for an advantage. Most units have a unique strength and weakness that become apparent during play, thus encouraging you to develop superior tactics. Tanktics has a wider variety of orders to allow you to apply superior tactics, such as capture, ram, and hit-and-run. Unit position and target selection become even more important due to terrain, movement, and range bonuses; firing arcs; and soft spots in rear- and side-hit locations. All of the units have distinct weaponry, armor, and speed to differentiate their strengths and weaknesses and encourage tactics. Not only do you learn to master these tactics over time, but you can also script these tactics into custom orders.

Technical Analysis

The technical analysis should be written by a seasoned programmer, preferably the technical director or a lead programmer, and then edited and compiled into the proposal. Reviewers of this proposal will use this technical analysis to help them make their decisions. Be honest; it will save you a lot of grief in the end. Overall, this analysis should make the reviewers optimistic about the game's chance of succeeding.

(37)

• Experimental features: Identify the features in the design that seem experimental in nature, such as untried or unproven technologies, techniques, perspectives, or other unique ideas. Do not include features that have been proven by existing games, even if they are new to the development team. For example, if the team has never developed a 3D engine, don't list it as experimental. Rather, list it in one or more of the other categories in the technical analysis section. On the other hand, if your development team is working on a 3D engine using the theoretical system of quads, then this effort should be listed as experimental. Of course, by the time you read this article, quads could be in common use.

Include an estimate of the time that it will take to bring the experimental feature to an evaluation state, as well as an overall time estimate for completing the feature. Experimental areas generally need more time in the schedule, so the more experimental features you list, the longer the schedule will be. While some companies shy away from such 18- to 24-month projects, many see these experiments as worthwhile investments in creating leading-edge titles. So tell it like it is, but don't forget to tell them what they will get out of it. Make them feel comfortable that the experiments will work out well.

• Major development tasks: In a paragraph or a few bullet points, make clear the major development tasks. Use language that non-technical people can understand. Major means months of development. Give a time estimate that assumes that you have all of the resources that you'll need to accomplish the task. You could also give an estimate of the resources that you'll need. For example:

"Artificial Intelligence Script Parser: Three to four months with two programmers. The parser reads and compiles the AI scripts into lower-level logic and instructions that are executed at run-time."

• Risks: List any technical risks. If you don't foresee any technical risks, by all means say so. Risks are any aspect of research and development that will cause a major set back (weeks or months) if they fail. List technologies that, though they've been proven to work by competitors, your company has never developed or with which your company has little experience. List, for example, real-time strategy if your team has never developed a real-time strategy game before; or 3D rendering if this is your first foray into 3D. List any of the

(38)

major development tasks mentioned previously if you perceive any risk. All untried off-the-shelf solutions (3D engines, editors, code libraries and APIs, drivers, and so on) should be listed as risks because they may end up not fulfilling your particular needs. Any development done by an outside contractor should also be listed, as that's always a big risk. When assessing risks, you should also indicate the likely impact that fixing or replacing the technology will have on the schedule. Indicate the time in weeks or months that the ship date will slip. List the time impact on specific resources. List any new resources (people, software, hardware, and so on) that would be required to fix it. This section may seem pessimistic, but it creates a comfort level for your document's reviewers - they will come away with the impression that the game implementation is under control, especially if they can perceive these risks themselves. Plus you'll have the opportunity to say, "You can't say I didn't warn you."

• Alternatives (if any): Alternatives are suggestions for working around some of these experimental or risky features and major development tasks. By presenting alternatives, you give the reviewers options and let them make the choices. List anything that might cost more money or time than desired but might have better results, or vice versa (it may cost less money and time but it may have less desirable results). Whatever you do, be sure to spell out the pros and cons.

• Estimated resources: List the estimated resources: employees, contractors, software, hardware, and so on. Use generic, industry-standard titles for people outside of the company: for instance, the publisher or investor who might read your document. List their time estimates in work months or weeks. Ignore actual costs (dollars), as that comes later.

• Estimated Schedule: The schedule is an overall duration of the development cycle followed by milestone estimates, starting with the earliest possible start date, then alpha, beta, and gold master.

Legal Analysis

If this game involves copyrights, trademarks, licensing agreements, or other contracts that could incur some fees, litigation costs, acknowledgments, or restrictions, then list them here. Don't bother mentioning the necessity of copyrighting the game's title or logo, as these are par for the course and likely

(39)

to change anyway.

Cost and Revenue Projections

The cost and revenue projections can be done in conjunction with the finance and purchasing departments. This data should give the reader a rough estimate of resource costs based on the technical analysis's estimated resources.

• Resource cost: Resource cost is based on the estimated resources within the technical analysis. Employee costs should be based on salaries and overhead, which the finance or payroll department should provide. You can list these as average by title or level. Any hardware or software that you purchase should be listed as well, even if it will ultimately be shared by other projects or folded into the overhead budget. Use a table or embedded spreadsheet as it is easier to read and edit. For example:

Employee Cost Per Month Work Months Total

2D Artists $4,000 35 $140,000

Lead Artist 7,000 14 98,000

Level Designers 3,000 35 105,000

Total: 343,000

Hardware/Software Price Qty. Total

Graphics Workstations

(PIII 500MHz/256MB/9GB/Voodoo2) $4,200 3 $12,600 3D Studio Max Extended Site License 3,000 1 3,000 Total: 15,600

• Additional costs (if any): This section is an assessment of additional costs incurred from licensing, contracting, out-source testing, and so on.

• Suggested Retail Price (SRP): You should recommend a target retail price before your game goes in the bargain bin - pray that it does