Documenting the Design


As part of their job, game designers produce a series of documents to tell others about their game design. Exactly what documents they produce and what the documents are for varies from designer to designer and project to project ”but they usually follow a common thread.

Why Do We Need Documents?

Beginning programmers, especially those who want to get into the game industry, often make the mistake of thinking up a game and then diving in and starting to program it right away. Programming is an immensely rewarding activity because you get to see the results of your work within seconds, and those programmers are seeking that reward as soon as possible. They can't wait to see at least some portion of their game up on the screen.

Back in the days when a single person designed and wrote an entire computer game, there wasn't really anything wrong with this. The programs were so small that even if the idea changed radically in the course of development, the programmer could modify the code within a few days. The games themselves were simple enough to be described in a page or two, so developers didn't feel any need for a formal design process.

In modern commercial game development, however, this kind of ad hoc approach is disastrous. Development teams often consist of 20 to 50 people. Millions of dollars are at stake. Critical release dates must be met to get the game on the shelves at a particular time ”usually right before the Christmas shopping season . You can't build a game consisting of hundreds of megabytes of software, artwork, animations, movies, and sound files with a "let's try it and see" approach; a job of this scale calls for some sort of methodology. Different developers require different degrees of formality , but all serious game companies now insist on having some kind of written design before they start work.

As we said before, a key part of game design is transmitting the design to other members of the team. In practice, a lot of that communication takes place not through the documents themselves, but through team meetings, bull sessions, and conversations over lunch . That doesn't mean that there's no point in writing design documents, however. The documents record decisions made and agreed upon orally; they create a paper trail. More important, writing a document is a process of turning vague, unformed ideas into explicit plans. Even if no one reads it at all, an idea written down is a decision made, a conclusion reached. If a feature of a game is not described in writing, there's a good chance that it has been overlooked and that someone will have to make it up on the fly ”or, worse , that each part of the team will work toward a different goal. It's far easier and cheaper to correct a design error before any code is written or artwork is created. Depending on the size of the game, wise developers will allot anywhere from one to six months for pure design work before starting on development, usually in combination with some throwaway prototype for testing out gameplay ideas.

Idea Versus Design Decision

Here's an idea: "Basilisks should protect their eggs."

Here's a design decision: "Whenever they have eggs in their nests , female basilisks will not move beyond visual range from the nest. If an enemy approaches within 50 meters of the nest, the basilisk will abandon any other activity and return to the nest to defend the eggs. She will not leave as long as a living enemy threatens the eggs, and will even defend the eggs to her own death."

See the difference? This is what creating design documents is about.

The Types of Design Documents

This section is a short introduction to the various types of documents a game designer might be asked to create. In chronological order, they are:

  • High concept (2 “4 pages)

  • Game treatment (10 “20 pages)

  • Game script (50 “200 pages)

The following sections briefly discuss these documents. Appendix A, "Sample Design Documents," contains samples (or pointers to samples) of each one and discusses their contents and formatting in much more detail.

The High Concept

Writing the high-concept document is the first step after scribbling down the initial idea. Its aim is to express the fundamental spirit of the game. Just as the purpose of a resum is to get you a job interview, the purpose of a high-concept document is to get you a hearing from someone, a producer or publishing executive. It puts your key ideas down on paper in a bite-size chunk that he can read in a few minutes. Like a resum , it should be short ”not more than two to four pages long. The high-concept document should take, at most, a week to create, of which four days are spent thinking and one is spent writing.

If possible, try to begin the document with a single, punchy sentence ”the high concept itself ”that describes the game in a nutshell . Unfortunately, publishing executives have notoriously short attention spans and a great many calls on their time. You need to grab them as quickly as possible. The high concept for Interstate '76 might have been, "Automotive vigilantes defend America's oil supply with heavily armed 1970s muscle cars in a high-octane, 3D action game."

The high-concept document covers these details:

  • The premise of the game

  • Its intended audience

  • Its genre (if it belongs to one)

  • Its unique selling points

  • The target platform(s)

  • The overall storyline

It must also describe the gameplay ”what the player is supposed to do, what type of environment or scenarios he will encounter, and a general overview of the game flow. You might also want to include a description of any special technologies that will be used to build the game and any special hardware it might require.

If you plan to use the high-concept document as part of a sales pitch to a publisher, you might want to include a section containing short profiles of the development team members, with details of relevant past experience. You'll need to explain why they are the right team to build your game. You might or might not also want to include a budget estimate, depending on who will see it and what your relationship is with them.

The high-concept document need not be a sales tool; it's also worthwhile to write one for yourself, just to record an idea that you might want to work on in the future.

The Game Treatment

The purpose of the game treatment is to present the game in broad outline to someone who's already interested in it and wants to hear more about it. The treatment is designed both to satisfy initial curiosity and to stimulate real enthusiasm for the game. When you give a presentation about your game to a publisher, you should hand him the game treatment at the end so he'll have something to take away and look at, something that will float around his office and remind him of your game. Your goal at this point is to get funding of some sort, either to create a more thorough design or a prototype, or (preferably!) to develop the entire game.

You shouldn't try to cover all aspects of the game in rigorous detail. This isn't the game's design script. It can be a tool for selling the game to a potential publisher or investor; if you're assembling a team of developers, it's a good way to explain it to potential candidates. The treatment should fill in a few of the gaps and answer some of the questions left by the high-concept document. This is the place for mocked-up screen shots, background on the key characters , a brief description of the overall story arc, and anything else that's crucial to understanding what the game will look and feel like to play. You should also include an analysis of the competition and indicate the ways in which your game will be different ”and better.

The initial treatment is still a simple document ”almost a brochure that sums up the basic ideas in the game. A good way of picturing what to write in a treatment is to imagine that you are making a web site to help sell your game; then throw in some business and development details for good measure.

The Game Script

The game script (or "bible") is the largest and the last in this series. It's not a sales tool; it's much too large and comprehensive for that. It's intended to document design decisions, not to persuade anyone of anything. The game script is the definitive reference for all matters relating to the structure and organization of the game, what the player does and sees ”the gameplay. It should also cover the game storyline, characters, user interface, and rules of play. It should answer all possible questions (except for technical ones) about the game.

The game script does not include the technical design. It documents the creative, conceptual, and functional aspects of the game, and it should include technical specifications where necessary. However, it does not address how the game is built or implemented in software. The technical design document, if there is one, is usually based on the game script and is written by the lead programmer or technical director for the game. Technical design is beyond the scope of this book. If you want to know more about technical design, read Game Architecture and Design (New Riders Publishing, 2004).

As a good rule of thumb, the game script should enable you to "play" the game. That is, it should specify the rules of play in enough detail that you could, in theory, play the game without the use of computer ”maybe as a (complicated) board game or table-top role-playing game. This doesn't mean you should actually sit down and play it as such, but it should theoretically be possible to do so, just based on the game script document. Sitting down and playing paper versions of game ideas is a very inexpensive way of getting valuable feedback on your game design. For designers without huge teams and equally huge budgets , we heartily encourage paper-play testing.



Andrew Rollings and Ernest Adams on Game Design
Andrew Rollings and Ernest Adams on Game Design
ISBN: 1592730019
EAN: 2147483647
Year: 2003
Pages: 148

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net