Game Design: Theory & Practice- P12

Chia sẻ: Cong Thanh | Ngày: | Loại File: PDF | Số trang:30

Thêm vào BST

Báo xấu

91
lượt xem 7
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Game Design: Theory & Practice- P12: My earliest recollection of playing a computer game was when I stumbled upon a half-height Space Invaders at a tiny Mexican restaurant in my hometown. I was perhaps six, and Space Invaders was certainly the most marvelous thing I had ever seen, at least next to LegoLand.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Game Design: Theory & Practice- P12

308 Chapter 16: Game Analysis: Myth: The Fallen Lords In Myth, every bit of technology is used to its greatest gameplay effect, as is typical of projects run by designer/programmers such as Jones. This hybrid devel- oper understands what the technology can do perfectly while also understanding what would be compelling in terms of gameplay, making for very economical game development. Thus, when the technology does something that can enhance the gameplay, the designer/programmer instantly notices it and is able to exploit it to its maximum effect. This differs greatly from so many projects where programmers implement complicated functionality that is never used because the designers never fully understand it. Of course, adapting gameplay from 2D to 3D is not without its drawbacks. For instance, despite being able to zoom in and out in Myth, one is never able to zoom Y out from the action quite as much as one would like. This is in part because of the FL precedent set by other RTS games, which, because of their 2D engines, can have a much more distant viewpoint, a viewpoint that lends itself to tracking and moving AM large numbers of units. A patch was released for Myth shortly after its publication which allowed players to zoom the camera out farther, but with the side effect of decreasing their frame rate, since more landscape and hence more polygons are TE now in view. Of course, the engine could probably support viewing the landscape from still farther away, but the amount of polygons on the screen would quickly become prohibitive, decreasing the game’s overall speed unacceptably. Thus, the limitations of a 3D engine come to limit the gameplay choices the designer can make. Another gameplay drawback that results from the technology is the often confusing camera. Though the camera is able to rotate to view whatever side of the action is desired, this camera rotation can often become jarring and disorienting, causing the player to lose track of where different locations and units are on the map. For a novice, a casual gamer, or anyone without a good sense of direction, the camera’s movement would probably be altogether unmanageable. Game Focus Myth is also a good example of a well-focused game design. As mentioned previ- ously, Myth came out several years after the success of two other RTS titles, Command & Conquer and WarCraft. In both of those games, the player builds structures which exploit the terrain’s natural resources in order to create additional units. The player is then able to direct these units against his opponent in a combi- nation of ways. Thus, those trend-setting RTS games are a mixture of gameplay— part resource management and building, part combat. Many of the subsequent RTS titles, both the successes and the failures, copied this general model, dividing the player’s efforts between unit creation, resource exploitation, and strategic unit deployment. Team-Fly®
Chapter 16: Game Analysis: Myth: The Fallen Lords 309 Myth’s gameplay is entirely focused on tactical combat, leaving out the resource management found in many other RTS games. But Myth does not feature any resources to be mined or structures to be built. Instead the player is focused entirely on the tactical side of the game, on the combat experience. The player starts out on a level with a given quantity of units, and for most of the levels in the game those are the only units she gets for that entire level. In some levels, additional units are acquired later in the level, but those levels are the exceptions rather than the norm. Myth does away with everything except for the combat elements of RTS games, which gives its gameplay a unique focus. This tactical emphasis has several ramifications on the overall game design. First, by not needing to worry about developing a resource exploitation system, Jones was able to focus on making the combat model as good as it could be. This resulted in more sophisticated and detailed combat than was found in any other RTS game at the time. In Myth, unit facing, formation, and placement matter more than they had in other strategy titles. Because the developers did not have to worry about how the player would use resources, more time could be spent on the physics system and other technologies that would enhance the combat experience. For example, this attention to detail meant that archers needed to worry about finding a clear shot through the trees, how the weather would effect the trajectory of their arrows, and how their vertical placement on the landscape would impact the dis- tance they could shoot. The lack of ability for the player to build additional units also affects the care he will take in using the units with which he starts a level. In WarCraft one can make a very substantial blunder early on in a level and still be able to win by wise resource usage and unit creation. In Myth, such an error is often fatal, with the lev- els becoming less and less forgiving as the game progresses. The player’s only
310 Chapter 16: Game Analysis: Myth: The Fallen Lords recourse when his plan of attack fails is to reload the level. This makes for a very different kind of gameplay than is found in WarCraft. In Myth, the player must think through his actions fully instead of just trying whatever first pops into his head. The units the player has are much more precious and, as a result, the player starts caring for their welfare. Since more can be made easily, the units in WarCraft may seem like just so much cannon fodder. Conversely, in Myth a particular unit may be crucial to finishing a level, and there is no way to bring him back once he is killed. Storytelling Despite its exemplary game design, a large component of Myth is its storytelling, which is conducted using a number of well-integrated devices. First are the cut-scenes which appear sporadically throughout the game, outlining major plot points and setting up certain levels. These are often used more as “teasers” than to really advance the story significantly. Second are the mission briefings which pre- cede each level. These contain a large amount of detail about the progression of the war between the Light and the Dark (the game’s two opposing forces). They also give meaning to the level the player is about to play, making the mission objective more than just some arbitrary task picked by the level designer. Third, and most interesting, are the in-game storytelling devices that are used. Of course, the levels are set in locations that match the needs of the story line, whether it be a frostbitten, barren mountain area or a smoldering lava pit. The bat- tles and missions contained in the level match up with the story as explained by the mission briefings. But the player can also see and hear exchanges within the game between different characters. For instance, a townsperson may advise the player of the location of a traitor. Your troops may provide advice such as, “We’d better get back to the bridge!” Though the player never loses control of his units, the game is able to trigger these bits of dialog at different key points in the levels. In one mis- sion, as the player’s troops approach an insurmountable mass of Myrmidons, the Avatara the player has been guarding steps forward and proclaims, “Let me handle this.” He begins a conversation with the Fetch leading the opposing forces and the story line unfolds right there in the game-world during game-time. In contrast to the majority of games which use storytelling as little more than an add-on to an already existing group of levels, Myth makes the story line, levels, and gameplay dependent on each other, strengthening each as a result. Players enjoy games because they enjoy the gameplay, not because the games are accompanied by long, non-interactive cut-scenes. Yet players do enjoy having stories in their games, since they can give the gameplay meaning. The best way to communicate a deep story is by making it integral to the gameplay and by revealing a little bit of it here and a little bit of it there during actual game-time, something Myth does
Chapter 16: Game Analysis: Myth: The Fallen Lords 311 Myth tells a compelling story through a combination of mission briefings, level design, and gameplay. expertly. Of course, the fact that Myth’s story line is top-notch, the script is well written, and the voice acting is professional certainly helps. Telling a story line through gameplay will not do a game a bit of good if the plot is hackneyed, the dia- log is contrived, or the voice acting is amateurish. Hard-Core Gaming Myth is a game design by hard-core gamers for hard-core gamers and makes no apologies about it. Far from trying to capture the “mainstream” or “casual” gamer market that so many companies have tried to court, Myth is a game that would quickly frighten away anyone who is not already familiar with other RTS games and who does not have the quick-clicking skills required by Myth. There is nothing wrong with this, of course, and it is pleasing to see a game which has the artistic conviction to know its audience and to stick to it. Indeed, since the game’s develop- ers are among the ranks of the hard-core gamers, it only makes sense that they will best know how to make a game that this audience will like. Often, when a group of hard-core gamers try to make a game that the mythical casual gamer will enjoy, they end up making a game they themselves do not like very much, and that the casual gamer does not care much about either. It is very hard for an artist to make art that appeals to sensibilities which are at odds with her own, the end result often being works that are without appeal to any group or demographic. But Myth did not have this problem; its developers created a game which no casual gamer would ever be able to pick up. One reason for this is the incredibly sophisticated and challenging set of controls. For instance, consider the control of
312 Chapter 16: Game Analysis: Myth: The Fallen Lords the 3D rotating camera. As opposed to other RTS games at the time, where the camera could only move horizontally along with the terrain, Myth’s camera can move horizontally, zoom in or zoom out, rotate around a point, or orbit around a point. Even experienced game players find it somewhat challenging to get used to this system. However, once one masters the camera’s movements, one finds that they are expertly designed and provide all of the freedom one could reasonably expect given the technology the game uses. The game is also littered with special keys for different actions, such as formations, special actions, and alternate attacks. Again, these commands, once mastered, provide the player with a large degree of control over how her units move and attack, but do take some time to learn. Indeed, these keys make the game impossible to play with only the mouse, something almost all other RTS games focus on. The “gesture-clicking” is another interesting feature, used for pointing units in a certain direction when they reach a given loca- tion. The system for gesture-clicking is quite powerful yet nearly impossible to learn without being taught in person or by practicing a great deal. Nonetheless, for the hard-core players who are willing to put in the time to learn the controls, the end result is an extremely enjoyable game-playing experience. Myth is also an inherently hard game. Even for players experienced at RTS titles, the game will prove to be extraordinarily difficult from the get-go. Custom- arily, games include a few simple levels toward the beginning of the game, in order to give the player a fighting chance while they are still learning the controls. Myth does not. Immediately, players are presented with barely accomplishable goals, where one mistake may make the level virtually unwinnable. The loss of a particu- lar unit will often cause the seasoned player to conclude that the level is now too hard to beat, so why bother? They will just restart the level instead. The sad thing is that, despite their great difficulty, the levels toward the beginning of the game are the easy levels, with the levels becoming exponentially harder from there. How- ever, this is the sort of challenge that truly hard-core game players thrive on. It is not that the challenges are unfair, arbitrary, or unpredictable, at least not always. In most cases, players can beat the levels on their first time through; it is just extraor- dinarily difficult to do so. Myth is the kind of game that many publishers would demand be simplified so that non-hard-core gamers would not be frightened off by its complex controls or sadistic level of difficulty. But if the game were simplified significantly, would it still be as compelling as it is now? Probably not. For whatever small number of casual gamers might be gained, large numbers of hard-core gamers would be lost.
Chapter 16: Game Analysis: Myth: The Fallen Lords 313 Multi-Player As with the Marathon games before it, Bungie created Myth to excel both as a single-player game and as a multi-player experience. What is most notable about this is that Bungie manages to do both so well. Many games are criticized for emphasizing one over the other. Quake and Quake II, for instance, were both praised for their solid network play while being lambasted for their lackluster sin- gle-player games. Many other games seem to add multi-player support as an afterthought, hoping to get another bullet point on the back of the box. Centipede 3D is a good example of this, where multi-player was added late in the project as a marketing consideration, and almost no design time was spent making it any fun. Bungie’s well-publicized strategy for making a game that excels in both the sin- gle- and multi-player arenas is worth noting. After they have established the core engine technology for their game, getting the networking functional is the next step. Once it works, the entire team starts playing network games, and keeps playing them until they are fun. At this point no work has begun on the single-player game, and the team is entirely focused on enhancing the network play experience. Only after the networking game’s core design is completed does the team start work on the single-player game. However, this is not to say that the single-player game is rushed. This merely means that the entire team knows what “works” and makes the game fun before any solo levels are even created, resulting in less reworking on those levels and leading to more entertaining levels in the final product. It is because the team has spent so much time playing the multi-player game that the net games have the depth to hold up over time. If the team were creating a shallow experience they would quickly grow tired of it. Myth’s multi-player allows players many different game types with a variety of goals, all of which require dif- ferent playing styles. The interesting pre-game unit trading system allows players to think up their own “killer” team, much like a player of Magic: The Gathering spends time developing the perfect deck of cards. Team play, where multiple people control one set of allied units and go up against another team, opens up many possi- bilities for strategies too complex for a single person to pull off. It is because of the time Bungie’s development team spent playing the multi-player game that it has the impressive staying power it does.
314 Chapter 16: Game Analysis: Myth: The Fallen Lords Overall Myth’s developers paid a lot of attention to detail, which helped to create a deep gameplay experience. Myth is also littered with little design touches that add a certain luster to the solid foundation of the core design. Whereas missions in other RTS games exist as sepa- rate, self-contained play-spaces, in Myth the missions become a part of the whole due to the use of “veteran” units. These units, if they survive a given battle, will be available for the player to use on the next level, and their skills will be noticeably stronger than the greenhorn units. This makes the player treat those units with spe- cial care, expending the greenhorns on more dangerous exploration. Another nice touch is the ability of the units to leave footprints in the terrain, which adds an inter- esting element to tracking down enemies on snow-covered levels. The variety of missions available provides a much more diverse set of goals than many other RTS games, causing the player to modify his gameplay style drastically from level to level. Of course, Myth is not without its problems, even if one can accept the chal- lenging controls and staggeringly difficult levels. Clicking around the overhead map sometimes causes the camera to rotate in ways the player does not expect, pos- sibly throwing off his orientation in the world. The overhead map is actually translucent and drawn over the play-field, which can sometimes cause players to click in it by accident. The desire to see more of the play-field at once is a valid one, even if it is a limitation of the technology. Nevertheless, these are truly minor flaws in an overwhelmingly impressive design. Myth represents how a great game can grow out of the marriage of technology and gameplay. This is not a shotgun
Chapter 16: Game Analysis: Myth: The Fallen Lords 315 wedding, however, but instead one where the bride and groom have carefully thought out how they can happily live together, enhancing each other’s strengths, thus creating something new and exciting in the process.
Chapter 17 The Design Document “It wasn’t until Ultima IV: Quest of the Avatar, that Ultimas really started hav- ing compelling, purposeful stories, and it was the first game in the series to have a social commentary subtext. Not only did I want to build worlds that were large, epic, and meaningful, I also wanted to add a subtext to each game which might not necessarily be obvious in the actions your characters took in the game, but one which ultimately would give the game a more last- ing meaning. So in Ultima IV you had to prove yourself to be a good person, one who could be an example to the people of Britannia. The game acted like a ’Big Brother,’ requiring gamers to behave in a ’heroic’ fashion in order to win the game. I thought that design was pretty cool, since gamers were accustomed to pretending to be the hero yet they would beat up all the townsfolk in order to become powerful enough to beat up the character who was supposed to be the big bad guy, even though he generally didn’t do anything bad in the game.” — Richard Garriott 316
Chapter 17: The Design Document 317 F or some years, while I was still an aspiring professional designer, I wanted someone to tell me what the official format for a design document was. I knew that Hollywood screenplays had a very precise format, and I figured there must be something comparably rigorous for design documents. What sort of information is it supposed to include? How should it be laid out? What format should it use? Only recently, after numerous years as a professional, did I figure out the big secret, and it is one that I am happy to pass on to you in this book. Yes, here my years of experience in the gaming industry will impart on you the precious information. There is no format! Everyone who writes a game design document just makes up their own format! Have you ever heard of anything so incredible? Whenever I have asked people what format I should be using for a particular document, they invariably answer “well, you know, the standard format.” No one really knows what this mythical “standard” format is, yet all refer to it. In the end, as long as it communicates the nature of the game effectively and in sufficient detail, whatever you hand over to the people who will review your document will be regarded as the “standard” format. There is definitely a certain type and quantity of information that belongs in a design document and which must be included for it to be useful, but there is no standardized form you must use in documenting that data. Certainly within some companies, especially large ones, there may be an agreed-upon format that all of the in-house designers must use for their documents. Your design document will end up standing out if it diverges too much from other design documents in the industry. It makes sense for you to get your hands on every official design document you can, just as you might seek out practice exams before taking major standardized tests. Optimally, you will be able to obtain some docu- ments that were used for games that were actually published. Or, at least, you will want to review documents written by designers who have completed and shipped games. This is hard to do, since gaming companies are fanatical about protecting their intellectual property and do not want to reveal how chaotic their internal development may be, but see what you can find. The Atomic Sam design document included at the end of this book is a good one with which to start. A design document is all about communicating a vision for a game, for map- ping out as much information as possible about how that game will function, what the player will experience, and how the player will interact with the game-world. Organizing and structuring all of this information into appropriate sections is one of the key challenges in writing a good design document. Again, many companies may prefer their documents in a format different from what I describe here, and you should certainly organize your data in the form desired by the people for whom you are writing. If the development team is familiar with navigating design documents written in a specific format, you should mold your data to fit that format.
318 Chapter 17: The Design Document Remember, the design document is not the end result of your efforts; the game is. As such, the format of the design document is relatively unimportant. As long as the format allows for the effective communication of the pertinent information, the design document will be a success. The Writing Style Before we delve into which sections your design document should contain and what areas it should cover, it is worth discussing the style you should employ when writ- ing your document. The design document is meant to be a reference tool and, as Y such, you want to make it as easy for people to search and refer to as possible. A big part of this will be maintaining a good Table of Contents, as we will discuss in a FL moment. In writing the text of your document, you will want to break it up with lots of titles, headings, sub-headings, and so forth. This will make it easier for the reader AM to skim over the document and zoom in on the information he is seeking. Breaking your information into lists, either numbered or bulleted, wherever possible will fur- ther allow readers to easily realize what different attributes a given part of the game TE will need to include. It is actually more difficult to write in a bullet-point style, as it requires you to constantly be shifting indentations around and bold-facing titles instead of just including all your ideas in a single narrative paragraph. You may find it easiest to write out your document first, and then go back and format it properly. That way you get all the content down, and when you go back to edit the document, you can simultaneously properly format it. Though writing in a bullet-point style may involve more work for you, the end result is a more useful document to the members of your team. Furthermore, the managers and executives will appreciate it, since it makes the document that much easier to skim. Some designers use special writing tools for composing their document. These might be applications better suited to writing text with lots of headings, subhead- ings, bulleted lists, and so forth. These various applications may allow for the auto-formatting and indenting of text, which could save you a lot of the time you would spend in a regular word processor dragging around indentation markers and tab stops. That said, I have never used such a tool, nor have I ever worked with someone who did. The primary problem with these tools is that once your docu- ment is done, you will need to pass it around electronically for everyone to read. Chances are slim everyone will have this unique formatting tool. Instead they will have a regular word processor. This will be read by everyone from the other mem- bers of your development team to the people in management to the executives at your publisher. You cannot expect all of these people to have installed whatever eclectic design document authoring tool you have chosen. If the tool you use pro- vides an exporter to a standard word processor file format such as Rich Text Format (.rtf), that will usually solve this problem, but make sure the exporter actually Team-Fly®
Chapter 17: The Design Document 319 exports a document that matches the one you have composed. Still, I have always been quite content using standard word processors for my own needs, and have not felt the need for a more capable tool. Though there is a great temptation to do whatever is necessary to “bulk up” your document in order to make it seem more thorough and complete, you want to avoid repeating information as much as possible. This is challenging as you talk about an element of gameplay that directly relies on another system which you dis- cussed ten pages back. Instead of redescribing the system, refer your reader to the system’s original definition. This is important since, as you find yourself updating the document over the course of the project’s development, you will need to change data in only one place instead of several. Often, if the same gameplay mechanism is described in detail in more than one place, when it comes time to make a change, only one of the descriptions will get updated. This leaves the other description out-of-date, thus resulting in an internally inconsistent document. Nothing is more frustrating to the reader than to find contradictory information in the design docu- ment. Inconsistent information in a specification can also throw up a red flag for producers, who will begin to question your competency to develop a game when you cannot seem to keep your facts straight. Many people like to read design documents on their computer, as it allows them to search for words and navigate the document more easily than with a large heap of paper on their desk. For these people, it makes sense to include hyperlinks wher- ever appropriate. Most modern word processors make it easy to create links from one part of your document to another, allowing the reader to quickly navigate to another relevant section. This can be quite helpful as you try to avoid repeating any Though comparisons to existing games, such as the oft-cited Super Mario 64, may be appropriate in the design document, the designer should be careful to fully explain what she means by the comparison.
320 Chapter 17: The Design Document more of your design than is absolutely necessary. Instead of repeating, include a hyperlink to the pertinent location so that the reader can jump there if they need to remember how a specific system functions. As you write your document, you want to write as well as you possibly can, but keep in mind that the design document is supposed to be a reference document for the creation of an entertaining game, not an entertaining document in and of itself. You want your writing to communicate the information necessary in as concise and succinct a manner possible. Do not spend a lot of time worrying about making the document stimulating reading. No one is looking for excitement when reading the bulk of a design document; they are looking for information. I usually try to make the Introduction and Story Overview the most readable sections of the document, where someone could actually sit down and read through those sections and be interested while doing so. But for the rest of the document, you will be successful if you simply manage to include all of the information necessary. Spending a lot of time dressing it up with fancy verbiage will do nothing to improve your game. Sim- ilarly, though you should try to write as correctly as possible, do not spend too much time worrying about editing the document for grammatical mistakes. If the readers of the document, the members of your team, are able to read it and get the information they need, they will be happy. They really will not care if you used a gerund correctly or not. As you write your document, it will be awfully tempting to compare elements of your design to other games, certainly ones the readers are likely to have played. Though in Chapter 5 I discouraged you from using such comparisons in your focus, in the design document comparisons can actually be useful, but with a caveat: you must fully explain your system, even if it is “just like the mechanic found in Super Mario 64.” A comparison to a popular game can provide the reader with a starting point to understanding a complex game system you are describing. If they can remember that game, they will instantly have some idea of what you are talking about. Of course, to prevent any confusion, you must still include a thorough description of that aspect of your design. Comparisons are almost always not useful enough to replace a thorough explanation of how a system is supposed to work. Therefore, do not rely on a comparison as a crutch to save you the trouble of docu- menting some gameplay. Nonetheless, having started with the comparison, your readers will have a better chance of understanding exactly what you are driving at when you go on to fully describe and document the system.
Chapter 17: The Design Document 321 The Sections The game design documents I write typically break down into the following major sections. Within each of these, there will be further subdivisions, and not every game may require that all of these sections be used. l Table of Contents l Introduction/Overview l Game Mechanics l Artificial Intelligence l Game Elements l Story Overview l Game Progression l System Menus Table of Contents The reader may laugh to think that I list this as an important part of the document. Of course a document over fifty pages in length and containing multiple sections will have a table of contents—why even mention it? What bears emphasis, however, is the nature of the Table of Contents. Since creating an index is a time- consuming task for a large body of text such as a design document, it is unlikely you will have time to make one. In the absence of an index, the Table of Contents ends up as the tool people use to navigate your document. When a member of the development team needs to find a specific piece of information in your document, she will be inclined to look first in the Table of Contents to try to find where that information is most likely to be. So the more detailed and inclusive your Table of Contents, the more likely she will be able to quickly find the information she needs. No simple novel-style table of contents will do in the design document—in other words, no listing of only eight separate sections with the reader left to navi- gate the pages within the sections on his own. The Table of Contents must include sub-sections, sub-sub-sections, and perhaps even sub-sub-sub-sections. We have already discussed how you will need to use bolded headings throughout your docu- ment to make it easy to navigate. In addition, any commercial word processor will allow you to turn these headings into entries in a table of contents. These entries will then automatically update for you as those headings move around within the document. Most word processors even allow someone reading the document on his computer to click on an entry in the table of contents and be taken directly to the appropriate part of the document. Making a detailed Table of Contents for your design document is crucial to making it useful.
322 Chapter 17: The Design Document Introduction/Overview or Executive Summary It is a good idea to have a single-page overview of your game’s design at the begin- ning of your document. This summary is not very useful to developers actively toiling away on the project, who, as you may remember, are the target audience for the document. However, for new team members who come on board the project, a summary will be a good starting point for understanding the game. Indeed, for any- one reading the document for the first time, be they a producer, an executive, or a marketer, getting an idea of the game’s “big picture” through a one-page summary can be quite helpful. Even if whoever reads the Introduction is not going to have time to read the rest of the document, this one-page summary should allow them to understand the essence of the gameplay. The Introduction should limit itself to a single page. Longer than that and the Introduction stops being an effective summary. Any information that does not fit on a single page is simply not part of the game’s core design. If you find yourself going over the limit, figure out what is least important among the data you have in the summary and cut it. Repeat this process until the summary fits on a single page. Think of the summary like your resume: longer than a page and you may lose your reader. Write a gripping first paragraph which sums up the entire game, with the following paragraphs filling in the structure outlined in the opening. Before writing the design document, you should have worked on defining your game’s focus, as I explored in Chapter 5, “Focus.” That focus is an excellent start- ing point for your summary. Recall that the focus is a summing up of your game’s most compelling points in a single paragraph. Start with your focus as the opening paragraph of your overview, and then use the following paragraphs to go into more detail about each compelling part of your game. One of the body paragraphs of your overview should sum up the game’s story, if any. In this paragraph, focus on the adventures the player will experience during gameplay, while not dwelling so much on the back-story or history of the game- world. Follow the game through to the story’s conclusion, mentioning the different types of worlds the player will navigate and characters they will encounter. Always keep in mind that this is just a summary, so it does not need to go into that much depth. Just touch on the high points of your story and move on to the next paragraph. The other body paragraphs of your summary should discuss different aspects of your gameplay, using the key parts as outlined in your focus. What features of the gameplay are most central to the game and will be most instrumental in making gamers want to play your work for hours and hours? Of course, you should not focus on features that all games have (“Project X includes the ability to save the player’s game at any time!”) but rather on features that will make your game stand out, the parts that define your game as a unique and compelling experience.
Chapter 17: The Design Document 323 The conclusion should then come in and sum up the entire overview, with a special emphasis on why this game will be so compelling to the user, what this game does that no other game has. The reader should finish the page on an up note, enthusiastic about the project. Think of this page summary as rallying the troops, psyching up the team, and getting people excited about the project without forcing them to read over the entire document. Game Mechanics The Game Mechanics section is the most important part of your document. It could also be called the “gameplay” section, since it describes what the player is allowed to do in the game and how the game is played. By describing what sort of actions the player can perform, the Game Mechanics section defines the game itself. As a result the Game Mechanics section is one of the hardest to write in the design docu- ment. Describing gameplay is an extremely challenging proposition, and as a result many bad game design documents skip this section entirely, preferring instead to focus on story, visuals, or menuing systems, all of which are easier topics to write about. The old saying goes, “Writing about music is like dancing about architec- ture.” Writing about gameplay is just as challenging and imperfect, yet it must be done for your design document to be useful to the team who will create your game. Sequels, such as Thief and Thief II, are often able to use an identical or extremely similar Game Mechanics section in their design documents. Pictured here: Thief II. Except for necessary references to the player’s character, you will want to avoid detailing any specific game-world objects or characters in the Game Mechanics section. Save those descriptions for the relevant content sections later in the
324 Chapter 17: The Design Document document. For instance, you will want to describe the possible effects of the different weapons the player might pick up, and how the player will control those weapons, but you will want to save the actual list of the different weapons found in the game-world until later in the document. The specific weapons represent instances of the functionality you describe in the Game Mechanics section. You can think of it in the following fashion: many different games could be made from what you lay out in the Game Mechanics section. For instance, the design documents for the Thief games follow a nearly identical Game Mechanics description. It is only the weapons, items, levels, and enemies that change from Thief to Thief II. The core game remains the same, and it is the core game you are documenting in the Game Mechanics section. It makes sense to introduce the player’s different capabilities in the same order someone playing the game for the first time would experience them. For instance, start out simple. What are the most basic moves the player can do? Say you are working on a game where a player controls a game-world surrogate (be it another human, a spaceship, an airplane, a robot, or whatever your imagination may have concocted). You should probably start with how that character moves forward and backward, turns left and right, and so forth. After you introduce the simpler moves, introduce more complex ones such as jumping, crouching, rolling, and so on, as appropriate. If your game is more of an RTS game or Diablo-style RPG, it may be that the player moves his surrogate(s) using point-and-click, and you will want to describe precisely how that works. How good does the player character pathfinding need to be? What does the game do when the surrogate cannot reach the place the player clicked? Do you have separate buttons to select a character and then to move it, or is it more of a one-button system? As you describe the character’s movements, you will want to list the physical commands the user needs to perform to pull off those movements. For instance, “To move forward, the player will need to press and hold the Forward Button. If the player just taps the Forward Button, the player character will only move a tiny amount.” It is probably a good idea to name the different keys or buttons the player has as her controls instead of referring to them specifically; use “Forward Button” instead of “Up arrow” or “Blue X Button.” This keeps your description of the player’s controls more platform-independent and allows you to change which keys do what later, without making you change a lot of instances of “the Up arrow” in your design document. A programmer who is implementing your control system does not care so much what the literal key assignment for a command is, but she needs to know how many different commands the user will have and what game-world actions are associated with which commands. Once you describe how the player commands his game-world surrogate, the next logical step is to describe the surrogate’s movement model. Does it follow a realistic physics model or something more simplistic? Does it ramp up to full speed
Chapter 17: The Design Document 325 slowly or does it achieve terminal velocity immediately? Does it move slower up inclines than on flat surfaces? Is its responsiveness quick and tight like Quake or slow and precise like Tomb Raider? How does it react when it bumps into an object—slide off, turn, or just stop? These are the sort of details you will need to consider and describe in depth. It may be that moving game pieces or player surrogates around is not the key operation in your game. Think of what a player starting a game would do first, and describe that. If you were describing Railroad Tycoon, for instance, you would want to talk about how the player lays down track and the rules governing that. If you were writing the design document for Lemmings, you might want to describe how the player can change a regular lemming into a special lemming, such as a blocker or a digger. If you were describing SimCity, you would want to explain how the player zones an area. RPGs such as Diablo II often start the game with the player creating her character. Of could this will need to be fully described in the design document. If your game starts out with the player needing to create her character, as she might in an RPG such as Diablo, you will want to describe that process, summariz- ing the significance of each statistic the player must choose. What does “strength” or “dexterity” represent? Later on in the Game Mechanics section, when you are describing an action that is affected by a particular statistic, you will be able to refer the reader back to that particular statistic’s original definition. Having started with the basics, you can proceed to the player’s more complex actions, trying to logically structure the document so that each subsequent action builds on the previous one as much as possible. You want your different game mechanics to flow one into the next so the reader can see the structure of the game
326 Chapter 17: The Design Document building. And, of course, you want to avoid referring to mechanisms you have not yet defined or detailed. Certainly the sort of topics you will cover will vary widely depending on what type of game you are creating. If your game involves combat, you will need to go over that in detail, explaining how the player uses different weapons and what the possible effects of those weapons are on the game-world. If the player’s surrogate is able to pick up and manipulate objects, you will want to explain fully how it picks them up, how it can then access them, how inventory management works, and so forth. The Game Mechanics section is also a proper place to lay out what sort of puz- zles the player might encounter in the game-world. Indeed, if your game is a puzzle game this will take up a large portion of the mechanics section. You will want to describe how puzzles function, how the player is able to manipulate them, and give direction as to how the puzzles will be created, without actually listing specific puz- zles. As with descriptions of specific weapons, save lists of puzzles for the content sections later in the document. For instance, say you were describing puzzles in the original Prince of Persia. You would want to explain that puzzles can involve hit- ting pressure plates, hidden knock-away ceilings, falling floor segments, gates which can be raised and lowered by the pressure plates, spikes that spring out from the floors and walls, special potions, certain types of magical effects, and whatever other components the game-world allows. You will not actually list any specific configurations of these components that will be found in the levels. Save that for the level-specific sections later in the document, or for the level designers to figure out on their own. Here you should list the palette of objects and behaviors from which the puzzles can be created. Describing the variety of puzzle components found in a game such as Prince of Persia is appropriate in the Game Mechanics section.
Chapter 17: The Design Document 327 If the game in question involves the player switching into different modes in order to accomplish different tasks, each of these modes should be described in detail. For instance, in Drakan the player maneuvers the player-surrogate, Rynn, through the world using forward and backward keys, while the mouse turns the character. However, when the player presses the inventory key, the game goes into inventory mode. From this mode the player no longer controls Rynn’s movements, but instead is presented with a mouse cursor with which Rynn’s inventory can be manipulated using standard drag-and-drop functionality. In the design document for Drakan, the designer would want to clearly describe how the player’s controls shift from one mode to the next, and how the game-world is manipulated in each. Some sections of the design document will be dependent on the technology the game will be using, whether 2D or 3D, indoor or outdoor, real-time or pre- rendered. Though one tries to separate the technological aspects of the game into the technical design document and keep them out of the design document as much as possible, what is being created is still a computer game, and as such it is inher- ently tied to the technology it will use. Writing a design document without having any sense of what sort of technology the game will have access to is usually impos- sible and at the very best impractical. You do not need to know how many polygons per second the engine will be able to handle, or whether it will support NURBS or not. However, you do need to have some base understanding of the tools that will be available to the designer. Designing a control or combat system that works in a 3D world and one that works in a 2D one are completely distinct and different tasks. You want to play to the strengths of the technology the game will use while dodging the weaknesses. For example, the Game Mechanics section will need to describe what the player sees while she is playing the game. This includes how the player sees the world, what sort of camera view will be used, and how the player will be able to affect that camera’s position. In order to write about this, you need to know what the camera will be capable of doing, which is entirely dependent on the game’s engine. It may be that the engine will only support a first-person view, only a side view, or any number of other limitations. Nonetheless, how the player sees the world is such a central part of the game’s design that you must discuss it in the Game Mechanics section. The in-game graphical user interface (GUI) is of critical importance to your game, and therefore, it should be described in detail in the Game Mechanics sec- tion. You should describe any data that is overlaid on the depiction of the game-world, such as, for an action game, the player’s health or other statistics needed during gameplay. The GUI section should also cover any other GUIs which are part of gameplay, such as what the player sees when his surrogate becomes involved in a conversation or when managing inventory. Describing the graphical interface is even more important for games like Alpha Centauri or The Sims which