Game Design Documents

Game Design Documents

Page 1

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.

Disclaimer

Game Design Documents

Page 2

This page is intentionally left blank.

Disclaimer

Game Design Documents

Page 3

Table of Contents Disclaimer.........................................................................................................1 Table of Contents..............................................................................................3 Pedersen Principles of Game Design and Production.........................................5 Principle 1: Understand The Role of the Designer and Producer..................5 Principle 2: No Designer or Producer Is an Island........................................7 Principle 3: Let Professionals do Their Jobs.................................................9 Principle 4: KISS (Keep It Simple Stupid)......................................................9 Principle 5: Schedules Are Like Laws..........................................................10 Principle 6: The Yardstick: One Day’s Pay for a Week’s Worth of Fun.........10 Principle 7: I Never Met a Genre That I Didn’t Like.....................................11 Principle 8: Be True to Your License...........................................................11 Principle 9: Share Your Toys!......................................................................12 Principle 10: There’s No Magic Formula for Success...................................13 Creating A Great Design Document.................................................................15 How the System Works..............................................................................15 The Challenge............................................................................................16 Ten Points for a Successful Design Document............................................17 In Sum Check…..........................................................................................24 Documentation Guidelines for the Game Concept and Proposal.....................25 The Purpose of Documentation..................................................................25 The Benefits of Guidelines..........................................................................26 Guidelines for the Game Concept...............................................................27 Common Mistakes......................................................................................31 Guidelines for the Game Proposal.............................................................32 Common Mistakes......................................................................................39 Documentation Guidelines for the Functional and Technical Specifications....41 Functional vs Technical Specifications.......................................................41 Guidelines for the Functional Specification................................................42 Common Mistakes......................................................................................51 Guidelines for the Technical Specification..................................................53 Common Mistakes......................................................................................59 Guidelines for Paper Level Designs............................................................60 Step 5: Play Test........................................................................................62 Documentation Milestones and the Development Schedule......................63 Dealing with Change.................................................................................64

Table of Contents

Game Design Documents

Page 4

Artists and Game Design Documents: From Interpretation to Implementation .......................................................................................................................65 Designers: Many Are Autistic, Not Artistic..................................................65 Designs: Looking At the Big Picture............................................................65 Blue Sky Meetings......................................................................................66 Speak Now or Forever Feel Victimized.......................................................66 Communicate Via Imagery.........................................................................67 Get Ahead, Think Ahead............................................................................67 The Design Document................................................................................68

Table of Contents

Game Design Documents

Page 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 troubleshooter, 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 Pedersen Principles of Game Design and Production

Game Design Documents

Page 6

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 Pedersen Principles of Game Design and Production

Game Design Documents

Page 7

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

Pedersen Principles of Game Design and Production

Game Design Documents

Page 8

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 Pedersen Principles of Game Design and Production

Game Design Documents

Page 9

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. Keep design interfaces simple. I once designed games for an arcade Pedersen Principles of Game Design and Production

Game Design Documents

Page 10

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 Pedersen Principles of Game Design and Production

Game Design Documents

Page 11

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 Pedersen Principles of Game Design and Production

Game Design Documents

Page 12

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 Pedersen Principles of Game Design and Production

Game Design Documents

Page 13

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 onscreen 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. Some developers of past hits have credited their success to the

Pedersen Principles of Game Design and Production

Game Design Documents

Page 14

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.

Pedersen Principles of Game Design and Production

Game Design Documents

Page 15

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

Creating A Great Design Document

Game Design Documents

Page 16

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.

Creating A Great Design Document

Game Design Documents

Page 17

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 It ensures that what is soul of the entire project, produced is what you want to with all the details, and the produce. method by which each element will be implemented.

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.

Creating A Great Design Document

Game Design Documents

Page 18

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 Creating A Great Design Document

Game Design Documents

•

Page 19

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

Creating A Great Design Document

Game Design Documents

Page 20

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.

Creating A Great Design Document

Game Design Documents

Page 21

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 personhours 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

Creating A Great Design Document

Game Design Documents

Page 22

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 Creating A Great Design Document

Game Design Documents

Page 23

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” I've seen documents that didn't even have the pages numbered. And

Creating A Great Design Document

Game Design Documents

Page 24

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.

Creating A Great Design Document

Game Design Documents

Page 25

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.

Documentation Guidelines for the Game Concept and Proposal

Game Design Documents

Page 26

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.

Documentation Guidelines for the Game Concept and Proposal

Game Design Documents

Page 27

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 nobrainer 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.

Documentation Guidelines for the Game Concept and Proposal

Game Design Documents

Page 28

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 The background section of your game concept simply expands upon

Documentation Guidelines for the Game Concept and Proposal

Game Design Documents

Page 29

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 Documentation Guidelines for the Game Concept and Proposal

Game Design Documents

Page 30

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, turnbased 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.

Documentation Guidelines for the Game Concept and Proposal

Game Design Documents

Page 31

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

Documentation Guidelines for the Game Concept and Proposal

Game Design Documents

Page 32

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.

Documentation Guidelines for the Game Concept and Proposal

Game Design Documents

Page 33

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.

•

Top performers: List the top performers in the market. Express their Documentation Guidelines for the Game Concept and Proposal

Game Design Documents

Page 34

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 hitand-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.

Documentation Guidelines for the Game Concept and Proposal

Game Design Documents

•

Page 35

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 leadingedge 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 nontechnical 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 Documentation Guidelines for the Game Concept and Proposal

Game Design Documents

Page 36

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, industrystandard 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

Documentation Guidelines for the Game Concept and Proposal

Game Design Documents

Page 37

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 Documentation Guidelines for the Game Concept and Proposal

Game Design Documents

Page 38

not. The price should be based on the price of existing games and an assessment of the overall value being built into the product and the money being spent to develop and manufacture it. Of course, your distributors will likely push for a lower sticker price or work some deals to use your game in a promotion that will cut the price even further, but that will all be ironed out later. Keep in mind that the higher the sticker price, the lower your sales, especially in a competitive genre where there's not as much demand as supply. •

Revenue projection: The revenue projection should show pessimistic, expected, and optimistic sales figures using the costs that you've already outlined and the suggested retail price. Other factors, such as marketing dollars and company overhead, should be left out of the picture as these are subject to change; if a minimum marketing budget is known, however, then you should certainly factor it in. Often the revenue projection is best represented with a pie chart or a bar chart. Be sure to indicate with an additional wedge or bar the costs incurred from any of the risks described in the technical evaluation and show totals with and without the risk assessment.

Art If your game concept did not include any art, then the game proposal certainly should. The art should be created by skilled artists. Dispose of or replace any of the art in the concept document that was not created by the artists. The art will set the tone for the game. Assume that the readers may only look at the art to evaluate the proposal, so be sure that it expresses the feel and purpose of the game. Include a number of character, unit, building, and weapon sketches, in both color and black and white. Action shots are great. Include a GUI mock-up if your game is a cockpit simulation. Be sure to have good cover art. Paste some of the art into the pages of the documents, as it helps get your points across and makes the documents look impressive.

Presentation The whole proposal, including the revised concept document, should be printed on sturdy stock and bound in a fancy report binder along with copies of the art. This document is to be presented to business people - you know, those people who walk around your office wearing fine suits to contrast with the t-shirts and cut-offs that you normally wear. Don't forget that you're

Documentation Guidelines for the Game Concept and Proposal

Game Design Documents

Page 39

proposing a major investment, so make the proposal look good and dress well if you're going to handle the presentation. Preparing a slide show in a program such as Microsoft Persuasion is helpful for pitching your key points and art.

Common Mistakes Some common mistakes in preparing a game proposal include:

The Analysis Is Based On Magic Numbers Try to back up your numbers by listing your sources or explaining how you came up with them. Watching a producer pull some numbers from thin air and throw them in the document is almost laughable.

The Proposal Is Boring This is a selling document. Don't bore the readers. Give them facts, but make these facts exciting, concise, and convincing.

The Proposal Fails to Anticipate Common-Sense Issues and Concerns You should find out what this proposal is up against -- other proposals, competitive products, financing concerns, cost and time expectations, game prejudices, and historical mishaps. Your proposal will stand a much better chance of being approved if it addresses these issues preemptively rather than getting besieged by them during the review process.

The Proposal Writer Is Overly Sensitive to Criticism My experience might be unique, but don't be surprised if the major promoter for your game proposal decides to play devil's advocate. Make sure your proposal is solid. Believe in it and remain confident, and you'll weather the criticism and make believers out of those reviewing your proposal.

The Proposal Writer Is Inflexible to Changes to the Game Often during the process of gathering research or receiving criticism

Documentation Guidelines for the Game Concept and Proposal

Game Design Documents

Page 40

from the review committee, some reasonable suggestions will arise for changing or scaling back the design. Game development is a collaborative process. Take the feedback and change the design, or the game could die right there. The key word here, as tattooed on the arm of my buddy who served in the Vietnam War, is transmute. He had to transmute to stay alive and keep going, and your game idea may have to do the same.

Documentation Guidelines for the Game Concept and Proposal

Game Design Documents

Page 41

Documentation Guidelines for the Functional and Technical Specifications by Tim Ryan Did you ever look at one of those huge design documents that barely fit into a four-inch thick, three-ring binder? You assume that by its page count that it must be good. Well, having read some of those design volumes from cover to cover, I can tell you that size does not matter. They are often so full of ambiguous and vague fluff that it was difficult finding the pertinent information. So why does this happen? Because the authors didn’t follow guidelines. This article is part two of a two part series that provides guidelines that when followed will ensure that your design documents will be pertinent and to the point. Unlike the authors of those prodigious design volumes, I believe in breaking up the design document into the portions appropriate to the various steps in the development process – from concept and proposal to design and implementation. I covered the first two steps in part one of the article, providing guidelines for the game concept and game proposal. This part will provide guidelines for the two heaviest undertakings – the functional specification and technical specification, as well as some guidelines for the paper portion of level design.

Functional vs Technical Specifications Traditionally in the game industry, there was only one spec. How technical it was depended on who wrote it. Any documentation the programmers wrote afterwards to really plan how they were going to implement it was informal and often remained on white-boards or notepads. Yet in order to ensure the project would proceed without hazard and on time and on budget, the documentation needed to be more technical. Such detailed technical specifications took time – time wasted if the goals and function of the product should change or fail to gain approval. This problem was tackled as more and more seasoned programmers and managers of business software development moved into games. They brought with them new standards for documentation that helped ensure more accurate plans and less technical problems. They introduced a division in the design document between goals and method and between function and Documentation Guidelines for the Functional and Technical Specifications

Game Design Documents

Page 42

technique. They separated the design document into the functional specification and technical specification. This way, the clients, users or principal designers of the product could review the functional specification and approve the goals and functions of the proposed software – leaving the determination and documentation of the methods and technique up to the technical staff of programmers. Therefore, the technical staff waited until the functional specification was approved and signed-off before starting on the technical specification. They worked from the functional specification alone, ignoring any design changes that occurred after sign-off unless the spec was updated and a new schedule agreed to. Thus the division saved time for the programmers and gave them more control of the schedule, while still ensuring they had a complete plan for the methods and technique for implementation. Many companies still refer to the functional specification as the "design document" and yet also produce a technical specification. The term "functional" is a clearer term adapted by businesses and these guidelines to clarify what is expected in the document. In short, what goes into the game and what it does is documented in the functional specification. This is often written from the perspective of the user. How it is implemented and how it performs the function is documented in the technical specification. This is often written from the system perspective. Both form important deliverable milestones in the design stage of the game development process.

Guidelines for the Functional Specification The functional specification (or spec for short) outlines the features and functions of the product. The target audience is the team doing the work and those responsible for approving the game design. The functional spec is a culmination of the ideas, criticisms and discussions to this point. It fleshes out the skeleton of the vision as expressed in the game concept and game proposal. It is a springboard from which the technical specification and schedule is derived and the implementation begins. It’s important that it is all written from the user perspective. In other words, what is seen, experienced or interacted with should be the focus of the document. It’s often very tempting (especially to programmers) to create something that’s very system oriented. This often leads to distraction and hard-to-fathom documents. Readers are really just looking to this document Documentation Guidelines for the Functional and Technical Specifications

Game Design Documents

Page 43

to visualize what’s in the game, not how it works. The length can vary from ten pages to a few hundred, depending on the complexity of the game. You really should not aim for a page count. I’ve seen and written really GOOD design documents that were less than fifty pages and some that were much more. It is just important that each section under these guidelines be addressed. This will eliminate the vagaries and guesswork that comes with insufficient documentation and the apparent need to ramble-on that comes with aiming for a high page count. The time involved in writing the functional spec is anywhere from a few days for say a puzzle game, a month for a shooter, to a few months for a complex game such as an RPG or strategy game. The amount of time spent may not be congruent to the resulting length. The discrepancy comes with deliberation time, especially if the game has any unique, unexplored qualities or if the game play is particularly deep. Of course, how efficient the principal designers are in making their decisions is of enormous impact as well, especially if everyone is particularly imaginative and passionate about the game. For many, this functional specification is where the documentation begins. They skip the important research and review phase of the concept document and game proposal, which would otherwise help it anchor the vision and target market firmly in place. By skipping the first steps, they also put off the inevitable criticism from marketing, finance and technical staff, which leads to wasted efforts. The game’s lead designer usually produces the functional specification. It may be a compilation of other’s work and hence a cooperative effort or it could simply be a matter of putting the vision of the producer on paper. Sometimes the producer will produce the document him/herself; which is ideal for assuring that the vision expressed is indeed what the producer desires. Like the game of telephone, sometimes the message gets altered when it goes from the lead visionary to the author. Whatever the process and whoever the author, it’s important that the producer and lead designer totally agree with everything expressed in this document. They cannot be preaching one thing and documenting another or the documents will be ignored and serve no purpose. I’ve never seen a design that didn’t undergo some changes during implementation, but the process of communication has to be expressed through the specification, even if it requires updates or an addendum. Some

Documentation Guidelines for the Functional and Technical Specifications

Game Design Documents

Page 44

changes need to be fast and furious due to time constraints so the documentation may be light. So, even if it’s an electronic memorandum or notes on a piece of paper, be sure to distribute these and attach them to all future copies of the specification. If the vision of the game changes, however, it’s best to start from the beginning with a new concept document and proposal. The clarity the updated documentation brings will save time in the long run. Unlike the game concept and proposal, the functional specification is not a selling document. It merely breaks down and elaborates on the vision in very clear terms understandable by every reader. It can be a little boring or dry as the necessary details are filled in. I’d recommend putting in summary level paragraphs at the start of every section, so that readers can get the gist without skipping any sections or losing any confidence in the thoroughness of the specification. Why do I recommend this? Well, the question should really be "Why do some people never find the time to thoroughly read the project specifications?" While your company’s managers and team members might not fail in this regard, there’s always a third party, like the publisher or contractor. On the other hand, this document cannot be technically explicit, as its readers are mostly non-programmers. If you find yourself getting technical, stop. That’s what the subsequent technical specification is for. Besides, getting technical with a bunch of non-technical readers can make their eyes glaze over or open up a can-of-worms. You don’t want to give them an invitation to stick their nose into something they don’t necessarily understand and really shouldn’t care about. Likewise, you or the other authors may be nontechnical, and you shouldn’t be dictating to the programmers how they accomplish what you want them to do. Let them determine that when they write the technical specification. This document is purely for the communication and approval of what goes into the product as opposed to how to accomplish it. Limit descriptions of how something should be accomplished to those areas that are you believe are really important that it work a certain way. For example, you would not indicate what variables to use and how to use them to simulate a law of physics; however, you might want to indicate the factors involved in the physics equation. Similarly, telling a programmer how to define his data structures and objects is a bad idea, but proposing the interface for data entry and the delineation of data is certainly within the confines of function. The functional specification can be broken down into a few major

Documentation Guidelines for the Functional and Technical Specifications

Game Design Documents

Page 45

sections: •

Game Mechanics

•

User Interface

•

Art and Video

•

Sound and Music

•

Story (if applicable)

•

Level Requirements

Game Mechanics The game mechanics describe the game play in detailed terms, starting with the vision of the core game play, followed by the game flow, which traces the player activity in a typical game. The rest is all the infinite details. Core Game Play: In a few paragraphs describe the essence of the game. These few words are the seeds from which the design should grow. Planted in the fertile soil of a known market, they should establish roots that anchor the vision firmly in place and help ensure a successful game. This is similar to the description section in the game concept, except that it’s nonnarrative, and usually expressed clearest in bullet points, though this could vary depending on the type of game. Game Flow: Trace the typical flow of game play with a detailed description of player activity, paying close attention to the progression of challenge and entertainment. If the core game play is the root of a tree, the game flow is the trunk and the branches. All activity should actualize and extend from the core game play. Be specific about what the player does, though try to use terms like "shoot", "command", "select" and "move" rather than "click", "press" and "drag". This keeps the description distinct from how the actual GUI will work, which is likely to change. Refer readers to specific pages in the User Interface section when you first mention a GUI element such as a screen or window or command bar. Characters / Units (if applicable): These are the actors in the game controlled by the players or the AI. This should include a brief description and any applicable statistics. Statistics should be on a rating scale i.e. A to Z or Low to High, so that it’s clear where units stand in relation to each other in broad terms. It’s a waste of time plugging in the actual numbers until the Documentation Guidelines for the Functional and Technical Specifications

Game Design Documents

Page 46

programmers have written the technical specification and created an environment for you to experiment with the numbers. Special talents or abilities beyond the statistics should be listed and briefly described, but if they are complex, they should be expanded upon in the game play Elements section. Game Play Elements: This is a functional description of all elements that the player (or characters/units) can engage, acquire or otherwise interactive with. These are such things as weapons, buildings, switches, elevators, traps, items, spells, power-ups, and special talents. Write a paragraph at the start of each category describing how these elements are introduced and interacted with. Game Physics and Statistics: Break out how the physics of the game should function, i.e. movement, collision, combat etc., separating each into subsections. Describe the look and feel and how they might vary based on statistics assignable to the characters, units and game play elements. Indicate the statistics required to make them work. Get feedback from the programmers as you write this, as how the game handles the physics and the quantity of the statistics will severely impact performance issues. This can get a little dry, but avoid getting too technical. Avoid using actual numbers or programming terms. These will come later in the technical specification, written by the programmers who will want to do things their way (usually the right way). Just tell them what you want to accomplish. For example: "The units should slow down when going up hill and speed up when going down, unless they are a hover or flying vehicle. How much they are affected should be a factor of their climbing and acceleration statistic as well as the angle of the incline." You would not tell the programmers what math to use to adjust the speed. Assuming you are not a programmer yourself, they’re just better at that than you. Artificial Intelligence (if applicable): Describe the desired behavior and accessibility of the AI in the game. This includes movement (path finding), reactions and triggers, target selection and other combat decisions such as range and positioning, and interaction with game play elements. Describe the avenue through which the AI should be controlled by the level designers, i.e. using .INI files, #include files of game stats or C-code, proprietary AI scripts, etc. Multiplayer (if applicable): Indicate the methods of multi-player play (i.e. head-to-head, cooperative vs. AI, teams, every man for himself, hotseat)

Documentation Guidelines for the Functional and Technical Specifications

Game Design Documents

Page 47

and how many players it will support on the various networking methods. Describe how multi-player differs from solo-play in game flow, characters/units, game play elements and AI.

User Interface The interface changes so very often that it almost seems pointless to document it; however, it’s got to start somewhere. It’s structured here to minimize the impact of changes. It’s starts with a flowchart of the screen and window navigation, then breaks down the functional requirements of all the screens and windows. That done, the GUI artist is free to do what he or she feels is right as long as it meets the requirements. To get him or her started you should provide mock-ups. This often is to the designer’s benefit to think everything through. Then follow up with a description of all the GUI objects that need to be programmed to make all the screens work. Flowchart: This charts the navigation through the various screens and windows. Use VISIO or similar flowcharting tool to connect labeled and numbered boxes together, representing screens, windows, menus, etc. On the corner of each sheet, put a numbered list of all the items for easy referencing and ease of defining tasks for the programmers. Functional Requirements: This functional breakdown of every screen, window and menu lists the user actions and the desired results and may include diagrams and mock-ups. While the specific interaction (buttons, hotspots, clicks, drags and resulting animations) can be listed, it’s often best to keep this separate from the list of functional requirements as these can evolve during implementation. Of course if it’s just easier to think in terms of clicking a button or it’s really important that something work a certain way, then by all means get specific about the method of interaction. Mockups: Create a mock-up for all the screens, windows and menus. This may end up getting ignored, but it’s a good starting point for the artists if they have no idea what else they may want to do. Don’t waste your time creating anything really pretty. Just create simple line drawings with text labels. Color can be very distracting if it’s bad, but if it’s important, go ahead. Some drawing programs have templates that make creating mock-ups very quick and easy. GUI Objects: These are the basic building blocks used to create all the screens, windows and menus. This should not include the items seen in the main view portal, as these are covered in the art list in the next section. The Documentation Guidelines for the Functional and Technical Specifications

Game Design Documents

Page 48

GUI objects are primarily listed here for the programmers to know what pieces they’ll need to code and have for putting together the screens. You should explain in detail how each is interacted with and how they behave. It may seem a bit obvious and not worth documenting, but it really helps when drafting together the technical spec and schedule to know exactly everything the game will need. For some games, this can be a very quick list to put together – buttons, icons, pointers, sliders, HUD displays etc. But it’s much more complicated in games where the interface is at all different. However, keep in mind that the methods of interaction are not all that different. A button is still a button, even if it’s clicking on a gorgon’s head instead of a gray rectangle.

Art and Video This should be the definitive list for all the art and video in the game. We all know how things creep up, though, so add a couple of placeholder references for art to be named later, like mission specific art and art for marketing materials, demos, web pages, manual and packaging. Overall Goals: This is where you should spell out the motifs, characteristics, style, mood, colors etc. that make up the goals for the art. Gather consensus with the lead artists and art director and make sure they see eye to eye with the project’s director or producer. Doing so now will save a lot of time later if they end up redoing everything because the goals were never clearly defined. 2D Art & Animation: This is really just a huge list that can be thrown into the art schedule. It can also include descriptions if needed. Some art isn’t self-explanatory, and other may involve specific needs from a design standpoint. Be sure to explain it all. Break your art down into sections. The lead artist may have some particular way he or she would like you to do that. I’ll list the typical section and their contents. Read them all to be sure you don’t forget anything. •

GUI: Screens, windows, pointers, markers, icons, buttons, menus, shell etc.

•

Marketing and Packaging Art: You might as well list it here and the schedule, because they’ll ask for it. This includes web page art, sell sheet design, demo splash screens, magazine adds, press art, the box and manual.

Documentation Guidelines for the Functional and Technical Specifications

Game Design Documents

Page 49

•

Terrain: Environment backgrounds.

art

like

tiles,

textures,

terrain

objects,

•

Game Play Elements: Player and enemy animations (sprites or models), game play structures and interactive objects, weapons, power-ups, etc. Don’t forget damage states.

•

Special Effects: Salvo, explosions, sparks, footprints, blood spots, debris, wreckage.

3D Art & Animation: This serves the same purpose and has the same requirement of the 2D Art list above. The difference may be in how the work may be divided. Art teams like to divide 3D art task lists into models, textures, animations and special effects, as they usually divide the tasks this way to maximize talent and skill and maintain consistency. Cinematics: These are the 2D or 3D scenes often shown as an intro, between missions, and at the end of the game. These should be scripted like a film script as separate documents. This, however, is production work. For the purposes of the functional spec, just list them here with the general purpose, content and target length. If any video is involved, list it in the following subsection. Video: Unless you are doing an FMV (full motion video) game, this subsection is pretty light. If you have any video in your GUI for say pilot messages, break it down here. All video tasks will require scripting, but that is production work. List the general purpose, expected length, and general content like number of actors and set design, even if it ends up being bluescreened into a 3D rendered background.

Sound and Music Overall Goals: Stress the aesthetic and technical goals for the sound and music. Describe the themes or moods you want. Name existing games or films as examples to aspire to. Issue technical edicts and editing objectives, such as sampling rates, disk space, music formats, and transition methods. Sound FX: List all the sound FX required in the game and where they will be used. Include the intended filenames, but be sure to consult with the sound programmer and sound technician (or composer) on the file naming convention. This makes it easier for people to find the sound FX and fold them into the game.

Documentation Guidelines for the Functional and Technical Specifications

Game Design Documents

Page 50

Don’t forget about all the areas that sound FX may be used. You don’t want to overlook anything and throw off the schedule. Go through all the game elements and your art lists to see if there should be some sound associated with them. Here are some to consider: •

GUI: Button clicks, window opening, command acknowledgments.

•

Special Effects: Weapons fire, explosions, radar beeping.

•

Units/Characters: Voice recordings, radio chatter, stomping, collisions.

•

Game Play Elements: Pick-up jingle, alerts, ambient sounds.

•

Terrain (Environment): Birds, jungle sounds, crickets, creaks.

•

Motion: Wind, footfalls, creaking floors, wading, puddle stepping.

Music: List all the music required in the game and where it will be used. Describe the mood and other subtleties. Music will often reuse the same themes and melodies. Mention where these themes should be reused. Consult the composer on this. •

Event Jingles: Success/failure/death/victory/discovery etc.

•

Shell Screen: Mood setting for title screens, credits, end game

•

Level Theme: Level specific music (designers choose the theme)

•

Situations: Sets the mood for situations (lurking danger, combat, discovery)

•

Cinematic Soundtracks

Story Write the synopsis of the story told by the game. Include the backstory and detailed character descriptions if it helps. Indicate the game text and dialogue requirements so they can be added to the schedule. Some game designs focus so much on this that they overlook everything else that should be in the spec. Telling a story is not the focus of most games. Of course, if you are doing an adventure game, it is extremely important. Expand and organize this section as is necessary to tell the story.

Documentation Guidelines for the Functional and Technical Specifications

Game Design Documents

Page 51

Level Requirements Level Diagram: Whether this is a linear campaign, a branching mission tree, or a world-hopping free-for-all, this diagram should be the backbone upon which all the levels are built. A diagram isn’t necessary if the structure is so simple that a list would suffice. The following is an example of a typical success/fail branching mission tree. Of course this will vary greatly for each game. The important thing is that it just presents a road map for the level designers and for the readers. Asset Revelation Schedule: This should be a table or spreadsheet of what level the game’s assets are to be revealed to the player for the first time. There should be a row for each level and a column for each general type of asset. Assets include power-ups, weapons, enemy types, tricks, traps, objective types, challenges, buildings and all the other game play elements. The asset revelation schedule ensures that assets, the things that keep the players looking forward to the next level, are properly spaced and not over or under used. If it’s important to the game that certain assets stop being used, then the schedule might be better drawn as a Gannt chart with lines indicating the availability of assets. This gives the level designers a guide to what assets they have to work with so they don’t ruin their level or anyone else’s. Level Design Seeds: These are the seeds for the detailed paper designs to follow. Detailed paper designs at this point are less legitimate and unlikely to survive intact. Designs created after the designers have had time to experiment with the tools and develop the first playable level are much more likely to succeed. It’s best to just plant the seeds for each level with a description of the goals and game play and where it ties into the story (if applicable). A thumbnail sketch is optional, but very helpful if the designer already has a clear idea of what he or she wants. Be sure to list any specific requirements for the level, such as terrain, objectives, the revelation of new assets, and target difficulty level.

Common Mistakes Here are some common mistakes to look out for:

Documentation Guidelines for the Functional and Technical Specifications

Game Design Documents

Page 52

Insufficient Details The descriptions need to be specific enough to convey intent and function. Avoid using vague terms unless you follow up with specifics.

Patronizing Material You wouldn’t give a chef a recipe that told him how to make a marinara sauce, so you don’t tell artists how to manage their 256 color palette or programmers how to define a particular data structure. Just list the facts important to the vision. Not only does it waste their time (and annoy them), but it wastes the writers’ time. Such details are more appropriate for the technical specification anyway, which is written by the programmers.

Ambiguous or Contradictory Material Watch for this. It clouds the vision, creates misunderstandings, and invalidates the functional specification.

The Design Document from Hell Nothing stupid, nothing ambiguous, nothing lacking – it just is too damn much. Try to keep a mental total of how long the design is going to take to implement when fleshing out the specification. Cut extraneous, nonessential features and save them for the sequel; or be prepared to argue the merits of keeping the features and extending the ship date.

Getting Too Personal with the Design You are not your work. Your personal boundaries should not include the design. As I have stressed throughout this document, game design is a collaborative process. While you want people to take ownership and responsibility for their work, the functional specification should have joint ownership. This keeps people from feeling isolated and more a part of the process, and it makes the documents feel less like marching orders and more like a plan. The team members are also much more likely to read something that they helped put together. Criticism is then aimed at the design not the documentors who put is all together; thus making the team more comfortable and productive in offering their criticism.

Documentation Guidelines for the Functional and Technical Specifications

Game Design Documents

Page 53

Wandering Vision This may happen as you write the functional spec. Even with a good concept document and proposal championing the vision, there’s still some room for interpretation. Creative folks have a wandering imagination and may be influenced strongly by whatever game they may be playing at the moment.

Guidelines for the Technical Specification While the functional specification explains what is going into the product, the technical specification explains how. The technical specification (or tech spec) is a working blueprint for the game. It turns conjecture into reality by forcing the programmers to think through how the game will be implemented, by reducing implementation/integration headaches, and by delineating the program areas and tasks for the schedule. Many companies will skip this step, as it is time consuming and seemingly benefits only the programmers. However, time spent working on a tech spec is less than the time lost from pitfalls that come with not writing one. The primary author is the lead programmer or technical director, though it is often more timely and useful if the programmers responsible for implementing the various program areas be responsible for documenting them. In its compiled form, it should present a plan that any programmer can understand and work from. The target audience is the lead programmer on the project and the technical director of the company. Therefore it will generally be written from the system perspective as opposed to the user perspective. It will be boring and Greek to the producer and any other non-technical readers. By asking for one, the producer is just making sure the technical staff thinks everything through, even if he or she doesn’t understand it. To the lead programmer, it’s a way of organizing his or her thoughts and creating an accurate picture of the work involved. The process of writing it will flag any of the uncertainties on the programming side and any of the holes, ambiguities or absurdities in the functional spec. Many good technical specifications vary from the form described here. This form mirrors the functional specification to ensure that all areas of the functional specification are covered. Sometimes it’s easier for a team writing this spec to organize it differently, if only because they are splitting the work differently or because of the organization of the underlying system. If they do,

Documentation Guidelines for the Functional and Technical Specifications

Game Design Documents

Page 54

I’d recommend going through every line of the functional specification and do a correlation with a highlighter to make sure nothing has been overlooked. An overlooked detail can lead to undesirable results in the product, project and team dynamic. These guidelines will not tell you how to implement your game. It’s assumed that you are a technically competent, experienced game programmer. An inexperienced or untrained game programmer should not attempt this task. These guidelines are the result of what I’ve come to expect in a good technical specification, though I certainly couldn’t tell you how to program your game. These guidelines force you to define the most common elements one finds in all games. Some may not be applicable, but each should be considered carefully. It may spark a question you haven’t asked yourself yet; which is sort of the whole point of writing this spec.

Game Mechanics This is certainly the bulk of the document. Right away you’ll see that any attempt to match up specific subsections with the game mechanics section of the functional spec is totally ludicrous. The perspective must be from the system out as opposed to the designers’ or users’ perspective. This starts with the hardware platform and the operating system, the use of externally provided code objects (DLLs, EXEs, drivers), and the delineation of internally generated code objects (if any). Then it breaks down the specific mechanics of game code stemming from the control loop. Platform and OS: Indicate the hardware platform and the operating system and the versions supported. For PC/Mac games, mention the minimum system requirements and the target machine. If distributed on something other than a CD like a cartridge, indicate the target ROM. External Code: Describe the source and purpose of all the code used but not developed by the project team. This includes OS code and preprocessing tools of the various game platforms, drivers and code libraries like DirectX, any acquired 3D API, or any other off-the-shelf solution. Code Objects: Break down the purpose and scope of the various code objects coded, compiled and built into the EXE. If any out-of-process or inprocess code libraries (DLLs) are used, break them down as well, but be sure to explain the use of object instancing and their persistence (like Direct Draw objects).

Documentation Guidelines for the Functional and Technical Specifications

Game Design Documents

Page 55

Control Loop: Every game has one. Be specific about how control is transferred from the start-up code to the shell and down into the main game code. Spell out the names of the functions in the core loop and what they will do, like the collision, movement and rendering routines. Explain the use of multi-threading, drivers, DLLs and memory management. Of course further details on the likes of multi-threading and memory management will be covered in the areas that they will be used most, like the rendering or sprite engine, sound code and AI. This subsection summarizes the system and underlying framework that supports the core game play and game flow described in the functional specification. Game Object Data: Read carefully over the functional spec at all the character/unit descriptions and game play elements. Then list and formulate all the data structures and their identifiers that are required to support the described attributes, functions and behaviors. To a certain extent, these will not be complete until the game physics and statistics and AI subsections are completely thought through and documented. Add statistics for user interface or any other area of the game that have unit or game play object specific data (i.e. icons, HUD displays, animation or special effect references, etc.). If using object oriented programming methods, show the class inheritance tree and each class’ interface properties and functions. Describe the use of collections. Identify any variables that could possibly be made into global variables to increase performance, such as any objects variables that may be referenced multiple times during critical game routines such as collision, movement or rendering. Again, I’m not telling you how to program your game. I’m just trying to get you thinking about common technical issues, specifically in regard to optimizing data structures for neatness, versatility or speed. Data Flow: Explain how data is stored, loaded, transferred, processed, saved and restored. While references should be made to data entry or processing tools, separate functional and technical specifications should be made for any complex or user intensive tools. Game Physics and Statistics: This is the nitty gritty – movement, collision, combat – and probably the most fun to document and implement. However, it can also be the code that gets altered more than any other part of the program. Designers like to change things. It’s often only after they can play it for a while before they can really decide what is right. For this reason,

Documentation Guidelines for the Functional and Technical Specifications

Game Design Documents

Page 56

you should plan to implement things as modular and flexible as possible. Put all the factors that control behavior into data files read at run-time, so the designers can change and balance things at their leisure without involving coding changes and new builds. The specification should clearly identify the modularity and divisions between code and the data that controls it. Define each function or procedure. Describe its purpose. Define what statistics control its behavior (constants, variables etc.) and how they can be modified. Include the function prototype listing all the parameters. If using function pointers and function overloading, specify where the different versions of the function will be used. For example, you may have multiple functions that handle movement for the various unit types – one for land movement, one for air, one for water, etc. Briefly describe how the function will work. For complex functions, use pseudo code to specify exactly how you will code it. This is especially important for CPU intensive functions that do a lot of number crunching or are just called very often. Think about how they can be optimized to increase performance. Perhaps bit-shifting or macros could speed things up. Artificial Intelligence: This often grows to a major section unto itself and is then scaled back when the schedule dictates the necessity to keep it simple. This shows a growing enthusiasm for complex AI, but a lack of time and resources to make AI anything more than simulated intelligence or scripted behaviors. Be mindful of this when you design the AI scheme. Try to accomplish the behaviors and decision making described in the functional specification without adding a huge layer of unnoticed and therefore unappreciated realism to the process. The basic rule of production applies here. If something that costs less and takes less time to build does the job, then don’t spend more time and money creating something else. Of course, there are exceptions that should be mentioned. Sometimes something might take longer to build, but it saves the designers a lot of time working on their levels. Also, creating something more flexible or powerful may make it a valuable asset to the company for other projects or just make it more capable of handling design changes should they occur. Discuss these with your producer and director of development before making a decision. Be sure to include the methods of manipulating the AI as dictated by the functional spec, i.e. whether it’s data driven or embedded into compiled code, and whether it’s a scripted language or a fixed set of variables or a combination of both.

Documentation Guidelines for the Functional and Technical Specifications

Game Design Documents

Page 57

AI should include path finding, target selection, tests and events to attach reactionary behaviors to, and other decisions made by characters, units or intelligent game elements involving game situations and unit statistics. DO NOT include the actual scripts or data driving the AI. That’s production work. Merely be specific enough to explain how the decisions and behaviors will be derived. Break down the statistics used to control the behavior. Multiplayer: It’s extremely important that the implementation plan is reviewed from a multiplayer perspective. This subsection should break down all the multiplayer considerations in game mechanics and all the multiplayer specific requirements specified in the functional spec. Multiplayer over multiple PCs (as opposed to console sharing or hotseat) has a lot of unique requirements that should be addressed. What connection methods and protocols are supported? Is it client-server or peerto-peer? What are the packet sizes and how often are they sent? What is the structure of the packet? How are missed packets and latency issues handled? What messages are broadcast and what are sent to specific hosts? How many different messages are there and when are they used?

User Interface Look and feel is one area of the design that undergoes the most changes during development. Therefore, its necessary that the programming for the GUI be as flexible as possible, separating game purpose from GUI function, so that changes that occur to the user interaction methods will not affect other areas of the game or require significant reprogramming. Create a variety of GUI objects (controls) using inheritance to maintain a consistent code interface to the events and the values. This way a slider bar can be exchanged with a text box or radial buttons with little or no changes to the calling functions. Assume that any of the GUI objects can be exchanged at any point in the project. To this end, your documentation should be flexible and generic. While it should break down the GUI into the screens, windows and menus, it should not go any further into the specific interaction. Instead, document how the various GUI objects will work, wherever they are used. Make references to functions in the game mechanics documented in the previous section, but anything that’s interface related should go here.

Documentation Guidelines for the Functional and Technical Specifications

Game Design Documents

Page 58

Explanation of the drawing and clipping routines of the graphics engine should be left for the Art and Video section, but certainly they should be referenced here in terms of view ports and HUD attachments and anything the player can interact with. Document the names for any of the global variables, constants, macros, function names or interface properties, so that other programmers can refer to the documentation without having to dig through code. This also avoids replication and inconsistency and increases clarity. Game Shell: List all the screens that make up the game shell - all the screens and windows other than the main play screens. These are derived from the flowchart in the functional specification, but may include some additional screens that the lead designer may have overlooked or brushed over (like installation or setup screens). Each item listed should be its own subsection with a description of its purpose, its scope (i.e. before or after level specific data is loaded), the pertinent values it will be accessing and setting, and what functions it will call. Main Play Screen(s): These are the one or more screens in which the core of the game is played. Though many people think from the GUI perspective down to the complexities of what’s under the hood, this should be written from the low-level mechanics perspective (the engine and rotors) out to the GUI (the hood and the dash). This keeps it consistent even if the outward appearance of the GUI should change.

Art and Video While this section in the functional spec pretty much just listed the art and video, the technical spec has to explain how the art and video will be stored, loaded, processed and displayed in the game. This includes the animation system, whether it’s 2D or 3D, and the video decompression and streaming system. Of course some of these might be off the shelf solutions, especially the video code. But all the interfacing should be mentioned here. Graphics Engine: Whether you are using sprites, voxels or 3D-polygon rendering or a combination, break down their functions in very specific detail. While it’s only 2 sentences of description here, it will likely prove to be a very meaty piece of the spec. Describe areas like view ports, clipping, special effects, and the connection to the collision and movement functions described in the game mechanics.

Documentation Guidelines for the Functional and Technical Specifications

Game Design Documents

Page 59

Artist Instructions: Break out the details important to the artists, like resolutions, bit depth, palettes, file formats, compression, configuration file definitions and any other data the artists need to define to fold in the art. Consider what tools can be created to streamline the art pipeline, and indicate their specifications here or create separate specifications for the more complex or user intensive tools.

Sound and Music Describe how sound will be loaded and played. Be specific about the use of mixing, DMA, multiple channels, 3D sound, and methods of determining priority. If using third party drivers, describe their interface and purpose. Be sure to address all of the requirements specified in the functional spec. Sound Engineering Instructions: Break out the details important to the sound engineers and composers, like sample rates, the use of multiple channels, 3D sound definitions, sample length etc. If using MIDI, indicate the version to use and the number and type of instruments that can be used and possibly stored. Indicate the data path and file requirements including any specific configuration files that need to be created. Consider what tools can be created to streamline the sound pipeline, and indicate their specifications here or create separate specifications for the more complex or user intensive tools.

Level Specific Code Based on the level design seeds in the functional specification, describe how code specific to those levels will be implemented and how it will accomplish the desired effect. Also describe how any other level specific code can be interfaced to the game code should the need arise to add more. In general, you should try to make any of the level specific code as generic and as flexible as possible so that it may be freely used to accommodate similar needs for other levels or new ideas.

Common Mistakes Here are some common mistakes to look out for:

Documentation Guidelines for the Functional and Technical Specifications

Game Design Documents

Page 60

Hand Waving It’s very tempting to just list the functions and not fill in all the details that force you to really plan how you are going to implement them. Sometimes they are just glossed over, but really the hand waving should end with the functional spec. This spec is supposed to force the programmers to really think everything through ahead of time. How else are they going to estimate the task time correctly? While it can be very effective to assign portions of the technical spec to the individual programmers responsible for implementing it, it’s not always in the best interest of the game or indeed the programmer to do so without some supervision. An entry-level programmer should get some guidance, and all the programmers should discuss and critique their documentation before it gets all folded together. Some companies have regular code reviews where programmers critique each other’s work. That should start even sooner during the design phase.

Guidelines for Paper Level Designs The designers should do paper versions of level designs before they begin creating the levels in the editor. Ideally, the designers will be familiar with the design palette, the level editor and game engine capabilities before they get started. Paper level designs are creating during the implementation phase, though they are based off of level design seeds expressed in the functional specification. These seeds are the core idea for the level and/or the basic requirements that may indicate what new assets are being introduced or what to limit the design to. It’s best not to do all of the paper designs at once, either, as the designers usually learn a lot while implementing each new level. For some reason, producers often expect the cart to come before the horse, so before serious level design begins, push for a playable, prototype level to be created first. It’s often a milestone unto itself that ensures that the tools and game mechanics are working well enough to develop levels. It should also serve as a guide to what can be accomplished with the editor and engine and epitomize the vision for level design. Following the first playable mission, level design can start in earnest. Yet even here, documentation plays an important role in saving time and ensuring quality through meticulous planning and the critical process. The

Documentation Guidelines for the Functional and Technical Specifications

Game Design Documents

Page 61

process of level design that works:

Step 1: Thumbnail & Discussion The level designer conceives of a level layout that meets the requirements laid out in the functional specification and asset revelation schedule. He or she then produces a thumbnail sketch and discusses the concept with the lead designer. The thumbnail could be on a white board or a note pad. It is a visual aid in the discussion. It does not need to convey the entire idea or all the details for the level, as these often evolve during the discussion or get tossed out altogether. The benefit of doing a thumbnail sketch and discussion rather than forcing a designer to first think everything through and document it is that it saves time. A senior or lead designer can in a matter of minutes determine whether a proposed level design has merit and give valuable advice that can drastically alter the design. A fully detailed and documented paper version can take days or even a week to put together. Depending on the skill of the designer, a designer might get sent back to the drawing board many times. This is especially true near the beginning of the project, when the designer is still learning what the lead designer wants, and near the end of the project, when original, compelling level concepts are harder to come by.

Step 2: Detailed Paper Version With an approved thumbnail and level concept, the level designer can work on a detailed paper version of the level design. The layout (or map) of the level should be much more detailed than the sketch and should be drawn to scale. This is best done on a large sheet of graph paper using colored pencils. Information about objectives, behaviors, buildings, enemies, events, locations etc. should either appear on the map or on a separate document with reference points on the map. Any mission specific art or code should also be listed. This amount of detail can take a few days or as long as a week to draw and document, but it saves a lot of time that would otherwise be spent "searching" or "redesigning" in the actual editor. When completed, the lead designer, producer and any other principal decision-makers should subject the paper design to an approval process. They may approve it, throw in some changes, or kill the level right then and there. It’s also important that someone technical, preferably a senior

Documentation Guidelines for the Functional and Technical Specifications

Game Design Documents

Page 62

programmer, review the paper design from a technical standpoint. This gives the programmers a heads up on what the level designers are going to attempt to do with the tools and graphics engine. They might add some features to the tools or make some code adjustments to make the level possible or just easier to implement. They may also vote to eliminate or alter any level designs that may break the game or are similarly unfeasible. It’s often very tempting to skip this step and jump right into the editor as it’s often faster to just build a prototype of the level than to write up the paper version. This is especially tempting in tight schedule situations. Yet, it’s these tight schedules that make documentation that much more important, because it means there’s even more reason to get it right the first time and reduce the number of surprises and time to redo the work. The benefit of a detailed paper version is that it forces a designer to think everything through and express the fun and challenges before he or she implements it. It also ensures that the details that may involve more tasks for programmers, artists and sound technicians get documented and scheduled for completion before the designer begins working on the level. This article is focused on documentation, but for completeness to this section and to this process, here are the remaining steps to level design as I see them:

Step 3: Creating the Core of the Level The designers should establish the core game play of the level using broad strokes. They should get it to the point that it gives them the fun and challenge they envisioned in the paper design. The designer should then get feedback from the lead designer and producer, who will determine whether the level has merit or not. It may indeed prove impossible to accomplish what the paper design suggested, or it may prove to not be as fun as was expected. This is simply a review point in the level design that saves the designer time should drastic changes need to be made or the level dropped entirely.

Step 4: Filling in the Finer Details Once the core game play of the level is established, everything else should just make it better. These are all the things that establish the setting, flesh out the level, and liven up the fun by providing more options, solutions, or surprises.

Documentation Guidelines for the Functional and Technical Specifications

Game Design Documents

Page 63

Often new art or code assets may seem appropriate, so be sure the designers find out they can get them before putting placeholders in. Then update the paper design and task lists.

Step 5: Play Test Have the designers play their levels and get as much feedback as possible. Again, documentation plays a role here. Be sure they keep track of all their bugs, feedback and tasks with at least a notebook and pencil. It’s very easy to lose track of issues at times (not to mention sheets of paper), so a centralized database with level specific issues and feedback is ideal.

Documentation Milestones and the Development Schedule Below is a list of the typical milestones in a schedule and where the documents described in this series serve as deliverable items. Following each milestone would be a review of that milestone, which would require approval to go on to the next. As the production schedule isn’t due until after the bulk of the documentation, then there shouldn’t be an impact on the schedule if time needs to be spent going back to the drawing board and creating specifications that everyone can agree with. It’s a recipe for disaster to race into production with iffy design documents just because of the urgency to meet an arbitrary ship date. In the end, it usually doesn’t save you any time, and in fact often leads to wasted efforts and significant delays.

Conceptual Phase •

Document: Game Concept

•

Document: Game Proposal

Design Phase •

Document: Functional Specification

•

Document: Technical Specification

•

Documents: Tool Specifications (if applicable)

Documentation Guidelines for the Functional and Technical Specifications

Game Design Documents

Page 64

Production Phase (Sometimes Called Implementation Phase) •

Production Schedule

•

Technology and Art Demo

•

First Playable Level

•

Documents: Paper Level Designs (not always a deliverable)

•

Alpha - Functionally Complete

Testing Phase (Quality Assurance) •

Beta - First Potential Code Release

•

Gold Master - Code Release

There could be more milestones, as it’s often necessary for publishers to have some means of determining and ensuring that progress is being made. Sometimes there are arbitrary monthly milestones for particular art, code, and design. The ones suggested here are the most common and have the greatest significance.

Dealing with Change It can be a beautiful thing to witness a project run smoothly following these guidelines, but what typically happens is some change to the vision due to inspiration or market trends. It’s very easy to slip into design-on-the-fly mode to try to adapt to the new vision without impacting the schedule. Of course it inevitably does anyway, because design-on-the-fly has its dangers. In these cases, the only way to make sure this doesn’t happen is to be adamant about the guidelines and the procedures they promote. This is easier if it’s spelled out in the contract. Don’t make any changes to the game without it going through the documentation. A change to the functional specification potentially invalidates the technical specification and subsequent schedule. It’s certainly grounds for reassessing the schedule. It should be very clear to the principle designers who may want these changes that when they sign-off on the functional specification and deliver it, they do so with no expectations on being able to make changes. Then, if they really want the change, the impact can be lessened with a period of updating the

Documentation Guidelines for the Functional and Technical Specifications

Game Design Documents

Page 65

documentation and a reassessment of the schedule. The threat of being stuck with what you got or being late is certainly compunction enough to put as much forethought as possible into the design and produce the best possible documentation. The guidelines presented in this series of articles should help you do just that.

Documentation Guidelines for the Functional and Technical Specifications

Game Design Documents

Page 66

Artists and Game Design Documents: From Interpretation to Implementation by Joshua Gordon Without question the biggest problem I find during the design and implementation of games is the lack of interactivity amongst the various team members of a project. We've all heard the comments (laments, shouts, etc.) "You wanted it to look like what?!?!?!", "This is the dumbest character I've ever seen!", "I said round! Not spherical!"--and so it goes. As someone once said "Without communication, chaos rules." This article will focus on the relationship and communication between artists and designers during the development process. Topics will include: "Blue sky" meetings, the design document, methods for streamlining the production process and a few other random thoughts. Now a couple of those random, but important, thoughts.

Designers: Many Are Autistic, Not Artistic While some individuals (show yourselves demons) are gifted with a plethora of skills- creative thinking, the ability to speak well, write well and create great art-others are not so lucky. Many designers find themselves in the position of being thoughtful, creative and having reasonable (hopefully) communication skills but a total inability to draw, model or otherwise communicate their ideas visually. Worse, many are not well versed in the diction of art (you know, "those dark highlights!" -or umm, shadows). Therefore, it's important to remember the "artistically challenged designer" needs your help. Designers can envision what we believe will be cool looking and we know the types of game play we are after, but without significant participation from the art team it is almost impossible to realize (much less enhance) the look and feel of the game.

Designs: Looking At the Big Picture. One final point before we dive into specifics. Design documents speak to a large audience: Programmers, artist, level designers, producers, marketing and business folks, etc- the whole enchilada. This can often make the document large, fragmented and a "hard read". While nobody loves Artists and Game Design Documents: From Interpretation to Implementation

Game Design Documents

Page 67

reading several hundred pages of semi-literate writing, understand that the document contains information that is crucial to an artist's ability to do his job. While you may want to skip over the treatise on AI (artificial intelligence), or the hyped up market speak this is almost always a mistake. Read the document, the whole document, you'll be surprised (hopefully pleasantly) to find information pertinent to the artistic content hiding in some of the strangest places--read the document, get the big picture.

Blue Sky Meetings For the purpose of this discussion, let' s define "blue sky" meetings as the pre-design meetings, discussions and other "social events" that take place during the formative stages of fame. Opinions of "blue skying" range from critical to crap; I believe the value lies (or dies) in the ability of each member of the team to speak his mind. Unfortunately, I also believe that all too often those who are less outspoken do not get heard, but rather are herded. Artist as a group generally fall into the latter category (the herded). I've participated in endless blue-sky meetings where you can identify each and every member of the art team as they're diligently doodling throughout the discussions. While I'm sure they're really, really good doodles they don't really help the process.

Speak Now or Forever Feel Victimized So, what does this have to do with the design document? Personally, I rely heavily on these meetings to help formulate the game design and, as importantly, to understand what the team is interested in making. -a great game design is worthless if the team doesn't want to make the specified game. Artists are as responsible for the creative game play content as any other member of the team. If you don't communicate during meetings your thoughts, ideas, characters and environments will not appear in the design. Conversely, if you do speak out you'll likely find many of your thoughts will be present in the document (even though the designer will take credit for 'em). I cannot stress the importance of this point. I like to think of designers as prospectors looking for ideas, some we'll dream up on our own, but a vast number of ideas, characters, situations and settings come from others. It is our job to absorb the input of the entire team and to coordinate and refine the creative vision. So, involve yourself in discussions.

Artists and Game Design Documents: From Interpretation to Implementation

Game Design Documents

Page 68

Communicate Via Imagery Here's a tip for the folks who don't feel all that comfortable trying to be heard through the debates, screams and other vocal exercises "blue sky" meetings often become-communicate your ideas through sketches and reference material. Some of the best ideas I've seen come from artists who appear at a meeting and drop a chunk of drawings on the table with a "how about these ideas" look. Remember the old (and overused) adage- "a picture is worth a thousand words"-give it a try. If you're bored, sketch a character, a scene, an object (anything related to the game as opposed to your personal doodle-glyphics). One final note, the drawings don't need to be high quality, quite the opposite, as long as they communicate your intentions you're "good to go". I'll be speaking more about concept imagery later.

Get Ahead, Think Ahead A great way to avoid being run over during discussions is to come prepared. Think about the topics for the meeting before you arrive. That way when you're in the middle of your idea and the pizza shows up, you'll have a note or picture to remind you of the point you wanted to make. It also give you the chance to gather your thoughts without some idiot saying "yea, so what! Get on with it!" If you're unsure about exactly which topics will be discussed, ask your team leader before the meeting. Following is a brief list of design items screaming for artistic input:

Overall Look and Feel The overall style of the game, from gothic to techno, earthy to industrial. What do you think the game should look like?

Characters From the player character(s) through bosses down to the smallest actor. Who are they? How do they appear? What do they do?

Levels/Environment What types of levels would you like to see? How should they look?

Artists and Game Design Documents: From Interpretation to Implementation

Game Design Documents

Page 69

Menu/Interface Screens They're almost always an after thought yet the player interacts with them constantly. How can you juice them up?

The Design Document OK. The meetings are over, time has passed and the designer appears with his magnum opus to the gaming world. What is this thing? What did the designer intend? How much latitude do you have artistically? These are hard questions to answer, game designs and designers come in all flavors, shapes and sizes. I've never seen two alike. However, most design documents should and will speak to a set of game elements critical to the art team. Following is a discussion of these elements and hopefully answers to the questions above:

Read the Whole Thing I said it above and I'll say it again-read the whole document. This discussion will focus on sections of the design that related specifically to artists but remember you will find pertinent and interesting items throughout the document. For, example, much of the business/marketing writing may seem like a waste of time, it's not. Held within are the desires, requirements and most importantly the expectations of people who you may not see but will definitely impact your work. Understanding how the folks outside your team are thinking is crucial. Another good example are the game play dynamics/mechanics-the basic rule system for the game. Understanding the core game play will help you avoid designing characters, objects or scenes, which won't work when placed in the game. While a ceiling dangling, fire-ball shooting slug boss may be a cool idea it won't be all that cool if the player character can't jump high enough to reach it and doesn't have a projectile weapon--meaning the player can't fight your cool boss (generally not a fun thing). Al is another area often overlooked. In my documents I include a small paragraph that outlines character/object- If the character kicks it better have legs. If it shoots rockets, it needs a rocket launcher. I think you get the point. Other Al items can be subtle. If the characters stop and look around when they hear the player, you need to make sure they have heads that swivel, bodies that rotate, etc.

Artists and Game Design Documents: From Interpretation to Implementation

Game Design Documents

Page 70

Game Look and Feel A section on the game's look and feel is intended to communicate and reinforce the overall graphical style of everything from the characters to the environments. Unlike many other areas of the game design, the game's look and feel is almost always decided up front-otherwise you end up the "Gamorama Eclectia"-a hodge-podge of imagery without a cohesive theme, look or style (generally not a good thing). Input should be given during the 'blue sky' meetings and/or art specific meetings during pre-production. It is during this formative period that you can affect the look of the game-and it's a look you will live with for the duration of the project. So keep you eyes and ears open during this process and when reviewing drafts of the design document. It is also helpful to clarify the look and feel during the design creation process. If the wording is ambiguous or unclear, don't hesitate to ask for clarification. Varying from the game's overall look and feel is ill advised. Following is a sample description of the look and feel of a mock game titled Mega-Game: Look Mega-Game will use an edgy, hyper-realistic style to portray a dark, alien, devastated look with some lighter environments used for balance and contrast. Each game environment will vary significantly from the others containing different music, sound F/X, color schemes, backgrounds, and NPCs. The look will generally become darker, stranger and less "normal" as game play progresses. At the game start the look will resemble that of Star Wars, toward the end it will have a more post-apocalyptic Terminator 2 look. Feel The feel will be that of a lone person or group on an almost hopeless campaign to stop a universe threatening evil. The player should feel an overall sense of an ongoing and increasing destructive force, veiled in mystery and intrigue throughout the game. As the player progresses, the story and the player's ultimate objective will become more clear while the feel becomes more and more twisted and evil. An increased sense of a maniacal and ruthless presence, which must be overcome, gets stronger and stronger. There will be a strong emphasis on ambience in Mega-Game. The backgrounds will be "alive" with activity; utilizing background animation, palette shifts, etc. The music and sound F/X will be used primarily to enhance this "live" and realistic feel.

Artists and Game Design Documents: From Interpretation to Implementation

Game Design Documents

Page 71

NPCs All NPCs (non-player characters) will be rendered in 3D. They will look and behave as "realistically" as possible. In general, this means that a large strong looking NPC would cause greater damage and have greater resilience than a smaller NPC. (Note: Obviously, some smaller NPCs will be capable of inflicting heavy damage, much as a rattlesnake can severely damage a human). NPCs will look and feel dangerous, aggressive and deadly (the bad guys). This is important, as the player will only be allowed to fight with "bad" dangerous entities. Mega-Game will NOT allow the player the opportunity to attack any entity which is non-aggressive. Backgrounds All backgrounds will be rendered in 3D. As discussed above, each level will look unique and, in general, the levels will become increasingly dark and twisted as the game progresses. Ideally, the player should be able to identify any level within the game purely by its background.

Level/Environment Description In general each level of the game will be described within the game document. There should be somewhat more latitude here than in the overall look and feel. That is, as long as the overall game look and feel is followed, the specific look of any level can vary somewhat. It is critical to understand the plot line as it relates to the current level. In the overall description above, it specifies that the game will become progressively darker and stranger. If the current level is at the beginning you'll have less latitude to "go-crazy", while if at the end of the game it is almost a requirement. During production you'll want to work closely with the level designer who will be laying out the level. A few important items to note when designing the look and feel of a level: •

Always keep in mind the player characters' skills-can the character jump, run, swim, climb, etc. While you may not end up laying out the level, your artwork will affect whoever does and ultimately the fun/challenge of the game.

•

Which characters are specified for the level and behave. Character behavior will often architectural/terrain style-wall climbers need lots of climb, water dwellers need lakes, rivers, aqueducts,

how do they dictate the open walls to fountains, etc.

Artists and Game Design Documents: From Interpretation to Implementation

Game Design Documents

Page 72

Fast characters need open or guided areas to move within; characters with projectile weapons or tools require room to shoot and objects to hide behind during firefights. •

What type(s) of game play are designed for the player in this level? Is there a significant amount of movement (hoppy-jumpy), hand-to-hand combat shooting? Each requires architecture, terrain and/or objects to aid the game play. A good example of game play affecting art is related to "jumping around". Does the game play dictate "death falls" (falls where the player is killed if a jump is missed). If the answer is yes, you need to create buildings/terrain with gaps high enough to "kill the character". If the answer is no, you'll need to avoid high jumps, or, create "nets" (objects/terrain that catch the player during a fall.) Following is a sample level description: The Final Chamber

A huge spacious cavern with organic walls similar to those in "aliens". The Final Chamber is suspended from the ceiling of the cavern. Several "bridges" lead to the chamber from the edges of the cavern. Thousands of characters are moving en-masse across the bridges and into the chamber where they are destroyed. The chamber pulses rhythmically creating a deep horrific sound, which emanates throughout the cavern. All visible light pulses to the beating sound. Due to the damage inflicted by the crashing ship (previous level) and the damage done by the player reaching the Chamber, the entire cavern is being rocked by sporadic quakes and explosions, falling debris rains downward and the bridges leading to the chamber shake, pieces snap off dropping to the cavern floor far below. The Chamber itself is a roundish structure with the sinewy biomechanical supports leading to the ceiling and floor of the cavern. Within the chamber are a handful of elite enemy characters who orchestrate the death march of the other characters as they enter the chamber and are absorbed by the machinery at the chamber's core. Additionally, there are large automatic defense systems used to guard this humongous machine and its ruler. 1.

Look/Feel: •

The inner sanctum-A holy worship of evil (think: Hellraiser).

Artists and Game Design Documents: From Interpretation to Implementation

Game Design Documents

•

A dark place, full of death and suffering.

•

Visually stunning, glowing, shaking, lots of movement.

•

Note: The last level of the game.

2.

Path: Diagonal down, Horizontal .

3.

Gameplay/Dynamics List:

4.

•

Intense action/platform.

•

Heavy fighting.

•

Slide dynamics.

•

Timed escape.

Page 73

Story Elements: •

Make way to the Final Chamber.

•

Fight to "inner sanctum".

•

Defeat Boss.

•

Escape the level before the cavern collapses killing the player

Note the inclusion of look/feel, the basic pathway, game play dynamics and story element bullet points. These are all intended to help the artist and level designer focus on items crucial to the game play and/or look and feel.

Characters Some of the largest parts of design document (at least in my case) are the character design sections for the main player character(s) and the numerous NPCs (non-player characters-enemies, monsters, etc.) Hopefully the designer will have created a template used to define each character. This helps the readers by providing a consistent format, which allows the focus to rest on each character's specific traits. Character design is an area ripe for artist creativity and input. As long as the artist understands the purpose of the character and its actions he can generally embellish and refine to his heart's content (limited by those two pesky restrictions: time and money). I break down my character designs into the following sections: description, reference, health and damage information, Al notes and animation list. Each is listed below with a brief description of its intended purpose. Combined the Artists and Game Design Documents: From Interpretation to Implementation

Game Design Documents

Page 74

information provides a set of guidelines while still leaving lots of room for interpretation. •

Description - A one or two paragraph outline describing the initial vision for the character and an overview of its attributes.

•

Character references - Visuals, drawings, videotape or other preexisting material used to clarify the look or actions of the character.

•

Health and Damage - How much damage the character can take and how much it can deliver (per attack type). This item is often overlooked by artists and can be extremely important. Does the character need recoil animation frames or death animation frames? How powerful is the character relative to other characters? Does a single blow significantly damage the player character(s)?

•

Character Al - A description of the character's behavior, movement and actions. Again, this section is often passed over by artist yet it is key to defining the character's structure, look and the set of animations required to enact the behavior.

•

Character Animation List - A summary list of the animations required for the character. It is strongly recommended that you complete any animation list with the other items that define the character, often the list will be missing animations (nobody's perfect), or they will be inadequate for the artist's purposes.

Artists and Game Design Documents: From Interpretation to Implementation