Game Design: Theory & Practice- P13 ppsx

Inauspicious Design Documents As I previously recommended, it may be useful to try to get your hands on some professional game design documents in order to give you an idea of what the indus - try expects in such specifications. However, you must be careful. It is likely that the document you obtain will not be any good. Many of the documents that have been used for published games and which were written by experienced professionals are truly terrible. By way of example, and in order to best teach you what to avoid, I will explore a few of the different types of horrible design documents, and why they fail so miserably at what they are supposed to accomplish. The Wafer-Thin or Ellipsis Special Document These thin little volumes, certainly none longer than thirty pages, startle and amaze the experienced game designer with their total and complete lack of any useful con- tent whatsoever. They use meaningless descriptions like “gameplay will be fun” and “responsiveness will be sharp.” In these documents, many comparisons to other games are made: “This plays like Super Mario 64” or “The game has a control scheme similar to Quake.” While such comparisons can be slightly useful, as I have discussed, the writer of the Wafer-Thin Document almost always fails to go on to explain the control scheme of Super Mario 64 or Quake in any detail, let alone the scheme to be used by the game in question. Often these documents spend a lot of time, maybe half their pages, talking about back-story. Usually this back-story is very weak and poorly developed and is only tangentially related to the game being developed. The Wafer-Thin Document also spends a lot of time talking about how the menus will work. Not the in-game menus, but the system menus where the user selects what type of game he wants to play, sets his options, and so forth. Many mock-ups are made and options carefully listed. What exactly the options will affect in the game is seldom described in any detail, since the game itself is barely defined. Figuring out the menu system is something best pursued once the game is working, when the designer knows what sort of options might be important and what different gameplay choices the player will have; it is certainly far from the most difficult part of game design, nor the most important system to nail down first. Wafer-Thin Documents are often constructed by managers who like to think they are game designers. The reason these can also be called Ellipsis Special Docu - ments is that they are often littered with ellipses. For example, the worlds the player will encounter in the game will be described in the following manner: “Jungle World is a very hot and sticky place where the Garguflax Monkeys swing around and torment the player ”Andthat will be all the document provides in way of description for the world, ending at an ellipsis, as if to say “insert game design 338 Chapter 17: The Design Document TEAMFLY Team-Fly ® here.” It is unclear whether the writers of these documents plan to come back and fill in at the ellipsis later or that perhaps they do not deem it worthy of their valu - able time to actually explain how their game works. They just assume someone somewhere will fill it in and make them look good. Another example of the content found in Ellipsis Special Documents might be: “The player will be given an option of many cool weapons. For example, the Gar - gantuan Kaboom does twice the damage of the player’s other weapons and has a special effect. The Barboon Harpoon will allow the user to kill enemies at a dis - tance with a nice camera effect. Other weapons will be just as fun and cool ” Here the writer of the Ellipsis Special fails to describe the weapons the game will have to any useful level of detail, and then, having listed two weapons, decides to leave the rest up to the imagination of the reader. Of course, readers are very use - fully told that the other weapons will be “fun and cool.” The writers of the Ellipsis Special mistakenly thinks that is all the description necessary to develop a game. The only advantage to the Wafer Thin or Ellipsis Special Document is that it allows whoever gets to implement the design to pretty much take over the project and turn it into her own. I say this is a good aspect, since usually the ideas the man- ager included in the Wafer Thin Document are beyond ridiculous and do not make for viable gameplay. But one must be wary. Problems arise when the manager shows up six months later and complains: “But that’s not what I wrote!” The Back-Story Tome Unlike writers of the Ellipsis Special Documents, the designer who writes the Back-Story Tome spends a lot of time working on his document. These books (it is hard to call them merely documents) usually stretch into the hundreds of pages— 300-, 400-, even 500-page documents are not out of the question. There’s a lot of information in there. The first mistake these documents make is usually a poor table of contents and the lack of an index. In a design document, well-ordered information and a good table of contents can replace an index, but the absence of both is a huge error. The problems are compounded when the document is as long as War and Peace. The primary reason for the existence of game design documents is to allow team mem - bers to quickly look up information about a section of the game they are working on. If a programmer wants to know how the AI for a particular enemy is going to work, she needs to find that information quickly and easily. If she cannot find it, she may just make something up. Similarly, when an artist wants an idea of the tex - tures that will be needed for a given area in the game, he wants to be able to find where that area is described as quickly as possible. Design documents are not read like novels. No one starts at the beginning and comes out at the end. Primarily, design documents are reference materials, and if team members cannot easily Chapter 17: The Design Document 339 retrieve the data they are seeking, they are liable to give up. However, once one starts hunting through one of these Back-Story Tomes, one is startled to find that, indeed, there is no information about the gameplay in there. It is all back-story. And at five hundred pages, it is far more back-story than most computer games will ever use. The history of all the characters in the game, the friends of those characters, and all the relevant parents and siblings are all described in minute detail. It may be very interesting stuff (though usually it is a disorganized mess), but in the end the reader is left with very little idea of how the game is supposed to function. A lot of games make storytelling one of their central concerns, and a story bible can be quite useful to game creation. In such a case, it makes sense to discuss the game’s story in the design document to some extent. But first and foremost, a design document is supposed to contain the game’s design, which is very different from a game’s story. Though these Back-Story Tomes are very impressive in terms of weight and will probably impress the venture capital- ists, the programmer who has to work with such a tome as his only guidance is going to end up designing the game himself. The Overkill Document Some designers think they can describe every last aspect of a game in the design document. It is certainly true that many design documents lack the necessary detail to be useful, as we found in the Ellipsis Special Document discussed above, but at the same time, going to an excessive level of detail can be a waste of the designer’s time as well as the person who has to sift through all of that excess information. Furthermore, excessive documentation can lead to the illusion that the designer has created a complete, thorough document, when in fact he has gone into far too much detail about certain subjects while skipping other areas that need to be addressed. For example, suppose that the game being documented has a number of charac - ters who perform certain actions in the game-world. Say the game has townspeople, and they need to walk around, sit down and stand up, talk to each other, and sleep. The document should describe these behaviors in the AI section. A truly thorough document might break this down into separate animations: stand from sitting, sit from standing, idle sitting, idle standing, walk, converse with hand gestures, and so on. Probably this is not necessary, since a good animator and lead artist will be able to break this down better than a designer can. But some designers may go over - board and actually sketch or list the individual animation frames. This is absurd. There is no way to know in the design document stage how many animation frames will be required for a given animation. This sort of decision can only be made and adjusted during the game’s production. Not to mention that listing animation frames is insulting to the animator who will only feel demoralized by this degree of micro-management. Furthermore, the design document should stick to gameplay 340 Chapter 17: The Design Document design, and not veer into the territory of the art bible or other art documentation. Another example might be what I call “balancing data.” These are the actual statistics for the weapons, items, and characters found in the game. The design doc - ument should probably list what different attributes weapons and characters will have. For instance, a weapon might have a range, an accuracy, a number of shots, and a rate of fire. Furthermore, the design document might want to describe the qualities of a given weapon: “The Double Barreled Shotgun has a short range and a low accuracy, but does a large amount of damage in a large area.” However, actu - ally listing the values for a weapon’s attributes is not very useful in the design document. Saying “Shotgun Accuracy: 2” does not really serve any purpose since the number “2” does not have any context and therefore no meaning. These values are best determined when the game is actually functioning, when a designer can balance the weapons as they will be used by the player and thus the designer can experiment with different settings to achieve the desired effects. Creating large tables full of data before this information is actually testable is by and large a waste of time. As with animation minutia and precise balancing data, source code also does not belong in the document. Designers who start writing out algorithms in their design documents are going too far. It does not matter if the designer is also a pro- grammer. There should be no code, not even pseudocode, in the design document. Including code will only serve to bloat the document and distract from omitted information which needs to be covered. If there is any useful information in the Overkill Document, it is so hidden in the river of useless data that team members will be too intimidated to look for it. The author of the Overkill Document thinks that he can preplan everything, and that he is far more talented than any member of his team. While such excessive attention to detail can be impressive to those who do not really know what they are doing, a design document that goes too far will only infuriate the team that has to work with it. The Pie-in-the-Sky Document These design documents often have noble intentions with grand ideas for truly mag - nificent gameplay. Sadly, the writers of them typically lack any technical grasp of what the computer is capable of or what a team of twenty people is likely to accom - plish in a year and a half. As a result, these overambitious documents put forth fancy ideas with no basis in reality or feasibility and end up frustrating and infuriat - ing the teams assigned to “make them happen.” Pie-in-the-Sky Documents include ideas such as “a fully modeled replica of Manhattan will be the player’s primary game-world, complete with AI agents repre - senting all of the city’s seven million inhabitants in real-time.” The authors of Pie-in-the-Sky Documents do not want to be bothered with messy details such as Chapter 17: The Design Document 341 the reality that no existing computer system can simulate seven million humans in any sort of reasonable time frame (let alone real-time). Another feature suggested in a Pie-in-the-Sky Document might be “a natural language parser will be included that allows users to type in full, complex English sentences which the characters will respond to with their own dynamically generated dialog.” The guilty designer does not want to hear that research institutions have been working for decades on natural language processors that still have trouble with short, simple sentences. Pie-in-the-Sky Documents are often combined with Ellipsis Specials into truly wretched design documents, where the guilty designer outlines a completely impractical project without bothering to go into much detail about it. The Fossilized Document Any of the above flawed design documents can also be a Fossilized Document. Indeed, a design document which does not necessarily suffer from any of the above problems and was once a fine reference tool will become a Fossilized Document over the course of a project if the designer is not diligent in her efforts to keep the document up to date. I know of no original game project whose design has not changed significantly during the course of its development, and when the design changes but the design document does not, that document starts to become a Fossil- ized Document. Suppose a programmer on the development team looks something up in the Fossilized Document. Say the information that person finds is out of date. They may start implementing the old, long-since-modified functionality. At some point, a designer or producer who is aware of the changes that have taken place in the design will notice that the programmer is creating a system that is no longer appro - priate, and will chastise the programmer for doing so. This creates frustration for both parties, not to mention wasting the programmer’s time. Furthermore, when - ever the programmer needs to know something about the design in the future, he will not trust the design document, and instead will go hunt down a designer or pro - ducer to find out how a given system is supposed to function. Of course, this defeats the purpose of the document, as the designer must stop whatever he is working on to explain the system to the programmer. This new system may be described correctly in the document, but the programmer is not going to get burned again by using the Fossilized Document. When the designer fails to update the doc - ument when design changes occur, the entire document becomes useless. No one can trust it, and as a result no one will bother to read it. 342 Chapter 17: The Design Document A Matter of Weight It is often joked that design documents are not read, they are weighed. This is not surprising given the heft of many design documents and the lack of desire among team members to read them. Shockingly, this statement is often true. I once heard an ex-producer from a major gaming publisher talk about her experience with design documents and the project approval process. She said that the “decision-makers” would bring a scale to their “green-light” meetings. When it came down to two sim - ilar projects that were both relatively worthy of funding, they would take the design document for each project and place it on the scale. Whichever one weighed more would get accepted, the other rejected. Much as it pains me to tell you, if you are in the commercial gaming business and groveling for dollars at publishers, you need to make your document hefty. You need it to be impressive to pick up and flip through. Many will never read it at all. Others will read only the Overview and Table of Con- tents at the beginning. But everyone will pick it up and remark on its weight. Of course, many of these super-thick documents contain a lot of information of negligible value toward the actual development of the project. They may be a stel- lar example of one of the failed types of documents I discussed earlier, such as a Back-Story Tome or an Overkill Document. It is your challenge as the game designer to make the document as practical as possible by providing only useful information in the document, while making it hefty enough to impress the suits. One might want to include a large number of flowcharts or concept sketches or choose to use a bigger font, all while not being too obvious. Indeed, a great game (though a simplistic one) can have a perfect design document only ten pages long. One wonders how many great, simple games have been cast aside by publishers who were unimpressed with the mass of their design documents. Getting It Read Once your design document is written, one of your biggest challenges may be get - ting anyone on the development team to read it. Often, many programmers, artists, or even other designers will not want to put the time into a careful reading of your document. Others may have been burned by bad design documents in the past and will jump to the conclusion that yours is of similarly poor quality. Keeping your document up to date, including only useful information, providing a detailed table of contents, and limiting yourself to practical, accomplishable gameplay elements will help. If your team members sample your document and find it to be of superior quality, they are more likely to return to it for reference when they are actually implementing a given system or working on a particular piece of art. As with any written document, you need to earn the trust of your readers if you hope to keep them reading. Chapter 17: The Design Document 343 Another key method of getting your design document read is to make it easily available to anyone who wants to read it. Keep it in the same source-control system that your team uses for asset management. You want your team members to be able to get the latest version of the design document as easily as they get the latest build of the game. Since you will be constantly revising and updating your document to keep it up to date with the project (and to prevent it from becoming a Fossilized Document), source control will be a valuable tool for keeping track of the previous revisions. When you check in the latest version of the document, send your team an e-mail telling them that it is available and explaining what has changed. That way, people can easily skim over the changes. If one of the changes is relevant to their work, then they can get the latest version of the document off the network and read over the relevant updates. Updating your document does not do any good if no one knows you have updated it, or if people are still reading old revisions. It is probably a good idea to use a version number with your document, such as 1.3 or 2.7. Include this version number, along with the date, in a header on every page. Often people will print out a design document and not realize how old or fossilized it is. If they can quickly compare a date and a version number, they will know which ver- sion of the document they have and whether they need to get a new one. Documentation is Only the Beginning Some designers seem to think that a thorough design document is, by itself, enough to build a game. It also seems to be the case that companies have bought design documents from designers, with those designers moving on to write other design documents while another team actually executes their design. A design document is a rough outline, more the suggestion of a game than anything else, and without being involved in a game’s creation until it goes gold master, one cannot truly be considered to have designed the game. A designer who takes any pride in his work will want to be there throughout the project, ready to change the design as necessary to make it the most compelling game possible and updating the document as the design is changed and revised (and rest assured it will be continuously changed and revised). A committed game designer will want to be there to balance the weapons, the AI, the controls, and certainly the levels, to make sure the game follows the focus through and the initial vision is realized. If a designer writes a design document and then passes it on to others to actu - ally build, the people who do the actual creation will change the design to match their own interests and artistic drives. The design document will be a springboard for their own act of creation, not the original designer’s. The design document is an integral part of the game’s creation, perhaps, but a design document is not all that is required. To claim any sort of meaningful authorship on the project, a designer 344 Chapter 17: The Design Document needs to be involved for the duration. In a way, writing the design document is the easy part of computer game design. Actually taking the document and creating a compelling gaming experience is much, much harder. Chapter 17: The Design Document 345 Chapter 18 Interview: Jordan Mechner The only complaint one could have about Jordan Mechner’s work in com - puter games is that he has not made more games. Each of the games he has designed and spearheaded—Karateka, Prince of Persia, and The Last Express—has had a unique elegance and sophistication that one seldom finds in the world of computer games. But the game industry has had to do without Mechner for several periods of time while he pursued his other great love, filmmaking. Indeed, it is Mechner’s knowledge of film that has helped to contribute to the quality of his games. But this quality does not come through the epic cut-scenes and barely interactive game mechanics that so often come about when developers attempt to merge film and gaming. Instead, Mechner has blended film and game tech - niques in unique and innovative ways, helping his titles to tell stories visually while still retaining the qualities that make them great games. 346 This interview was originally conducted around the release of The Last Express for Inside Mac Games magazine. For inclusion in this book, Mechner was kind enough to fill out the interview a bit, expanding it to cover the full breadth of his fifteen years in computer game development. What initially attracted you to computer games? Well, it was 1979, and I was a sophomore in high school. The first computer that I ever got a chance to play with was the PDP-11 that we had in our high school. But it was very hard to get any time on it, and the teacher who was in charge wouldn’t let the students read the manuals, for fear that would give us the ability to go in and change grades and stuff like that. So it was this guessing game of trying to learn how to get the computer to do anything. So when a friend of mine showed me his new Apple II, it was just like a dream come true, to have a computer in your own house that you could use whenever you wanted. And it was completely open; you could pop open the top and see how it was made and you could read all the manuals that came with it. And of course, the irony was that at that time I didn’t know of any manuals that explained assembly language. So I was just kind of look- ing through the assembly code of the computer’s operating system to try to figure out what the different commands meant. Over the years I picked that up, and more books came out. It was just this great toy. Did you always want to make games with the computer? Well, I guess games were the only kind of software that I knew. They were the only kind that I enjoyed. At that time, I didn’t really see any use for a word proces - sor or a spreadsheet. I played all the games that I could find, and in my spare time I tried to write games of my own. That was just the first use that occurred to me. So that was the origin of Karateka? It took a few years to get there. The first really ambitious project I did was a game called Asteroids. That was my attempt to do for Asteroids what a game called Apple Invaders had done for the other most popular coin-op game of the time. I fig - ured that if Apple Invaders was a big hit because it was exactly like the coin-op game, then I could do the same thing for Asteroids. But my timing was a little off. I actually finished an assembly language, high-resolution version of Asteroids and signed a deal with a publisher. But just about then Atari woke up to the fact that these computer games were ripping off its hugely profitable arcade franchises, so their lawyers scared everybody off and that Asteroids game was never published. So then you did Karateka? No, then I did a game that bore a strong resemblance to Asteroids except that instead of rocks you had brightly colored bouncing balls, and instead of wrapping Chapter 18: Interview: Jordan Mechner 347 [...]... player There are a number of proven action game formulas that have evolved since the days of Prince of Persia Part of what interested me about doing an adventure game was that it seemed to be a wide open field, in that there hadn’t been many games that had found a workable paradigm for how to do an adventure game So it wasn’t the inspiration of other adventure games? No, on the contrary in fact If you... most innovative design elements in the game is the save -game system you used Players never actually save their game, but Last Express automatically remembers everything they do, and they can “rewind” to any point in their game they want, if they want to try something a different way How did you come up with this system? I’m glad you asked I’m very proud of the save -game system The funny thing is that... in the game, as opposed to music in most adventure games that just plays in the background, never changing How did you approach the game s musical aspect? We knew that music would be very important to the texture of the game, and finding the right composer was very important And we found him: Elia Cmiral, a very talented film composer from Czechoslovakia, who, by the way, is not a computer game player,... noticed that The game is full of little things like that So is that why you don’t tend to like other adventure games, because they’re too set in “primrose path” style? Some adventure games have great moments, but in terms of the overall experience it’s rare that a game consistently keeps that high a level In Last Express too, Chapter 18: Interview: Jordan Mechner 367 there are parts of the game that don’t... story What’s right for one game might not be right for another I wouldn’t even begin to know how to use the Last Express engine to do a game that wasn’t set on a train Last Express seems to have not sold well because of the lack of an adventure game market Yet adventure games used to be very popular I’m wondering if you had any idea what happened to all of the adventure game players? That’s a good... caught by surprise when I woke up to find the adventure game market was dead, because I’d never really thought that much in terms of genres Even doing Last Express, the fact that Prince of Persia was an action game while Last Express was an adventure game, I just wasn’t thinking about it that way, right or wrong As a game player, I’m not a big adventure game player myself, for a lot of reasons Usually the... tapestry Again differing from many other adventure games, Last Express offers a fairly non-linear experience for the player, where there seem to be multiple ways to get 366 Chapter 18: Interview: Jordan Mechner through to the end Do you think non-linearity in adventure games is important? It’s crucial, otherwise it’s not a game There are a couple of game models which I wanted to steer away from, one... possible setting, that is, an express train All of your games have featured cut-scenes in one way or another, and in Karateka, Prince of Persia, and Last Express they’ve all been integrated into the game so as to be visually indistinguishable from the gameplay Was this a conscious decision on your part? Absolutely Part of the aesthetic of all three of those games is that if you sit back and watch it, you should... in the computer games industry He said, “It looks like it’s well programmed, we’re impressed with the smoothness of the animation and so on But it feels kind of old-fashioned Take a look at our new game, Choplifter.” Doug was kind enough to send me a copy of Dan Gorlin’s Choplifter, which was the number one selling game at the time, along with a joystick to play it with That was the game that really... and different languages, that what we were designing was an adventure game I consciously wanted to get away from the adventure game feel I don’t personally like most adventure games I wanted to have a sense of immediacy as you’re moving through the train, and have people and life surging around you, as opposed to the usual adventure game feeling where you walk into an empty space which is just waiting . about the gameplay in there. It is all back-story. And at five hundred pages, it is far more back-story than most computer games will ever use. The history of all the characters in the game, the friends. very little idea of how the game is supposed to function. A lot of games make storytelling one of their central concerns, and a story bible can be quite useful to game creation. In such a case,. discuss the game s story in the design document to some extent. But first and foremost, a design document is supposed to contain the game s design, which is very different from a game s story.