Game Design: Theory and Practice (2nd Edition) (Wordware Game Developers Library)

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.

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 section. 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 navigate the pages within the sections on her own. The Table of Contents must include subsections, sub-subsections, and perhaps even sub-sub-subsections. We have already discussed how you will need to use bolded headings throughout your document 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 her 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.

Introduction/Overview or Executive Summary

It is a good idea to have a single-page overview of your game s design at the beginning 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 anyone 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 that 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 starting 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 players 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 players 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 Introduction 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.

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. When looking at a design document for the first time, this is the section that I look at first to determine what the gameplay really is for the game. Indeed, the Game Mechanics section could also be called the gameplay section, since it describes what players are allowed to do in the game and how the game is played . By describing what sort of actions players can perform, the Game Mechanics section defines the game itself. Because of this, the Game Mechanics section is one of the hardest to write in the design document. 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 architecture. 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.

Except for necessary references to the player 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 document. For instance, you will want to describe the possible effects of the different weapons players might pick up and how players 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.

Sequels are often able to use a Game Mechanics section in their design documents that is identical or extremely similar to the original game. Pictured here: Thief II .

It makes sense to introduce the players 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 players can do? Say you are working on a game where players control a game-world surrogate (be it a 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 players move their 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 players 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 users need to perform to pull off those movements. For instance, To move forward, players will need to press and hold the Forward Button. If players just tap 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 players have as their controls instead of referring to them specifically ; use Forward Button instead of Up arrow or Blue X button. This keeps your description of the players 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 users will have and what game-world actions are associated with which commands.

Once you describe how players command their 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 slowly or does it achieve terminal velocity immediately? Does it move more slowly 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 sorts 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 players starting a game would do first, and describe that. If you were describing Railroad Tycoon , for instance, you would want to talk about how players lay down track and the rules governing that. If you were writing the design document for Lemmings , you might want to describe how players 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 players zone an area.

RPGs such as Diablo II often start the game with the player creating her character. Of course this will need to be fully described in the design document.

If your game starts out with players needing to create their character, as they might in an RPG such as Diablo , you will want to describe that process, summarizing the significance of each statistic players 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 players 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 building. And, of course, you want to avoid referring to mechanisms you have not yet defined or detailed.

Certainly the 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 players use 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 they are picked up, how they are accessed, how inventory management works, and so forth.

The Game Mechanics section is also a proper place to lay out what sort of puzzles players 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 and how players are able to manipulate them, and give direction as to how the puzzles will be created, without actually listing specific puzzles. As with the 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 hitting pressure plates, hidden knock-away ceilings, falling floor segments, gates that 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.

If the game in question involves players switching into different modes in order to accomplish different tasks , each of these modes should be described in detail. For instance, in the original Drakan: Order of the Flame, players maneuver the player-surrogate, Rynn, through the world using forward and backward keys, while the mouse turns the character. However, when players press the inventory key, the game goes into inventory mode. From this mode players no longer control Rynn s movements, but instead are 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 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 inherently 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 impossible 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 players see while they are playing the game. This includes how the players see the world, what sort of camera view will be used, and how players 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 players see the world is such a central part of the game s design that you must discuss it in the Game Mechanics section.

The GUI is extremely important to games such as Alpha Centauri , and will need to be thoroughly described in the design document.

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 section. You should describe any data that is overlaid on the depiction of the game-world, such as, for an action game, the players health or other statistics needed during gameplay. The GUI section should also cover any other GUIs that are part of gameplay, such as what players see when their 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 include many different GUIs and in which players constantly use the GUI to play the game. The descriptions of these GUIs can either all be included in one part of the Game Mechanics section, or can be detailed during the description of the system to which they are relevant. Remember that you want your design document to be as reader-friendly as possible. If the art director is looking for the different GUIs that need to be created and they are scattered throughout the Game Mechanics section, some may be missed. On the other hand, a programmer might prefer to find the GUI for a particular system included with the description of that system. You need to decide which approach is in the best interest of your document and the project. In the Game Mechanics section, you want to describe only the GUIs that are used in the game and are therefore relevant to gameplay. Any of the front-end GUIs used when players are starting a new game or loading an old one are not really part of the gameplay. As such, the front-end GUIs should be separated into the System Menus section, which I discuss later in this chapter.

It is easy to assume a lot when writing a Game Mechanics section, but a good designer will avoid assuming anything. For instance, a designer may be working on a first-person shooter in the Quake mold. She may make the assumption that when players run over an object, their character will automatically pick it up. The designer has played so many first-person shooters that it is totally obvious to her that this is how she wants it to work. But if she fails to write it down in the document, the programming team may assume it will function some other way, copying their own favorite game. Do not assume that the same gameplay components that are obvious to you will be obvious to whoever is reading your document. Spell everything out explicitly so there is no room for confusion.

You can almost think of the Game Mechanics section as an extremely detailed first pass on the manual. You are describing in intense detail how players will accomplish every different action in the game-world ” what commands players will use and what the results of those commands will be. If you are writing your game design document as a journalist might write a news story, in the Game Mechanics section you should be concerned with the what and how ” what players do in your game and how they do it. Later in the document, you will get to the where, when, and why.

Artificial Intelligence

If the Game Mechanics section describes how players can interact with the game-world, then the Artificial Intelligence section documents how the world will react to the players actions. How will the opponents that players face in the game-world behave? What will they do in which situations? This section may also describe how the game-world behaves when players are not doing anything. For instance, it could discuss ambient behaviors such as how townspeople go about their daily business.

In games such as Doom II , the player mechanics and the behavior of the AI agents are discrete enough to be described in separate sections of the design document.

Some design document authors may prefer to include the Artificial Intelligence section in the Game Mechanics section, but I prefer to keep them separate if possible. Whether or not to include the Artificial Intelligence section within the Game Mechanics section depends on the nature of your game. For some games such as Tetris , the AI is so negligible that it does not warrant its own section. For a game such as Lemmings , where player controls and the AI are tightly intertwined, it makes perfect sense for the author of the design document to discuss them in the same section. But for a game such as Doom , where the players manipulation of their game-world surrogate, the Space Marine, is relatively distinct from the behavior of the enemies he fights, it makes sense to split up the information into two sections. Such separation makes the programmer s navigation of the document easier, since the process of working on the players movement and the creatures they will battle are customarily separate coding tasks.

In the AI section you will want to do your best to fully describe how you expect the game to behave for players. If you are working on a game in which the players move their character around in a game-world where it encounters other characters, you will want to describe how those characters react. Do they ignore players until they initiate a conversation or are they attracted to the players? Can they pathfind around the area in an apparently intelligent manner or are they walking on predefined paths? Some NPCs may initiate combat with players; when and why do they decide to do this? Is it based on seeing the character? Hearing it? Are they activated by level-designer specified triggers? Perhaps all three actions initiate combat in different situations. How smart are the characters? Are they able to hide around corners, sniping at players from safe locations? Do they flee when wounded? There are a number of questions you should answer in the AI section, enough to give the AI programmer an idea of what she needs to implement. The more questions you answer, the more likely the programmers will create behaviors in the game that match your expectations and vision.

Designing an AI for a strategy game can be a significantly more involved process. Suppose you are working on an RTS game like WarCraft or a turn-based strategy title such as Civilization . What sorts of strategies will the enemy use to overwhelm the players units? How will the units work together? If applicable , when will the computer player decide to build more units, and how many will it make? Will the AI pick up on and defend against different attack types performed by the players, such as flanking maneuvers? Is the enemy AI supposed to be a real match for players or is balance achieved because the computer simply has more powerful equipment? If necessary, you can provide a walk-through of a single game experience and how the enemy AI would behave at different junctures of that game.

Describing the collaborative tactics the AI will use is very important in the design document for strategy games such as WarCraft II.

Working on the Artificial Intelligence section is a good place to enlist the help of programmers on your team. Find out what sorts of AI they have experience working with, and explore how that might be applicable to your project. Find out what is difficult to accomplish and what is easy. It is often hard for a designer ( especially if she is a non-programmer) to comprehend that getting an AI agent to flee when wounded is a trivial task, while getting it to pathfind up some stairs and jump over a ledge can be extremely difficult. Instead of going for pie-in-the-sky notions of what you would like the AI in your game to be capable of, work only with real, accomplishable goals. Remember that a programmer who reads a design document filled with descriptions of implausible AI that is in no way grounded in reality is likely to become irritated at the document, and it will be a challenge for that document to be taken seriously in the future. Having a programmer work with you on the game s AI documentation will help make that section of your document that much stronger, as well as assuring that the AI programmer really understands what is expected of the agents in the game.

In working on your Artificial Intelligence section, try to follow the same rules you did when writing the Game Mechanics section. Do not refer to specific NPCs in the game, but rather to general behaviors that different agents may exhibit. You will get to the specific NPCs and what set of behaviors they will use in the Game Elements section later in the document. Again, try not to assume anything. Put in as much detail as you can about how the agents in your game will behave, even if it seems obvious to you.

Game Elements: Characters, Items, and Objects/Mechanisms

If you think of the level designers on your team as painters , then the game elements are the colors they have on their palette. These elements are the different parts of your game that will be brought together in the levels to create a compelling experience for players. The designers will be able to take these elements and, by combining them in unique and interesting ways, create a variety of levels that will keep players interested for hours. Of course, not every game has levels, but nearly every game has game elements. Whether these elements are the various types of foes players fight in Robotron: 2084, the different sorts of special buildings that can be created in SimCity , or the different blocks in Tetris , they need to be listed and detailed in the Game Elements section.

Now that you have spent a good many pages focusing on the more general game mechanics and artificial intelligence capabilities of your game, it is time to move on to specific content. Remember that you kept the Game Mechanics and AI sections general enough that one could make many different games using them. These sections may even remain relatively unchanged for a sequel, should your game have one. But the enemies, NPCs, objects, items, and mechanisms players will encounter in the game-world will probably be unique to this game. This content is usually closely tied to the story, which you will delve into later in the Story Overview and Game Progression sections of your document. It is actually a toss-up if you want to list your characters, items, and objects before or after the story sections. It is up to you to determine what makes the most sense for your particular document and game.

I customarily use three classifications of game elements: characters, items, and objects/mechanisms. You may wish to create a separate section in your design document for each of the classes, or you can make each class a different subsection in one all-inclusive Game Elements section.

Again, depending on the type of game you are working on, you may not need to use all three classifications. A shooter like Half-Life would have all three: the aliens players fight would be among the characters, the weapons they find would be listed under items, and the different game-world mechanisms players encounter, such as the redirectable laser beams, would fall under the third classification. An RTS game like StarCraft, however, might instead have a units listing (which is essentially a combination of characters and items) detailing all of the different units that the players or their adversaries can control, along with an objects/mechanisms list that details any objects players interact with, such as doorways or teleporters. If the RTS being designed is one in which units could pick up objects, however, you might want to create a third classification after all. An RPG such as Diablo might add fourth and fifth groupings for listing the players skills and spells respectively, since these are game elements that do not really fall into any of the three classifications I have discussed. Try to separate your game-world elements, whatever they may be, into the most logical groupings possible. Depending on the nature of your game, it is not unreasonable to have only one class or as many as ten; compelling games can be created in either case.

The design document for Diablo II might contain separate Game Elements sections for describing the player s spells and skills.

Within each class, try to list the objects in the most logical order possible and group different subclasses of objects together. For instance, if you are working on an RPG, you might want to list all of your potions in one spot, all of your bladed melee weapons in another section, and all of your ranged weaponry in another. An RTS might want to separate its units into offensive, defensive, and construction, or perhaps static and mobile. Again, take a look at the kind of game you are making, and try to divine the method of representation that best suits the data you are presenting and that makes it easily navigated and understood by readers. The Game Elements section should provide information for both the art and programming teams . The art team will need to make sure art assets get created for all of the elements you describe. The programming team will want to read the Game Elements section in combination with the Game Mechanics and AI sections to get a full understanding of what the game will be expected to do. Keep the artists , other designers, and programmers all in mind as you work on cataloging the game s characters, items, mechanisms, and whatever other classifications your game may demand.

In listing and describing these game elements, you want to avoid assigning actual statistics to any of them. This level of detail about the items or enemies is simply not something you can predict before you have a functioning game in which you can test the behavior of the AI or weapons and balance them properly. Statistics that you come up with in preproduction, where you have no real chance of play-balancing or trying them out, are a waste of your time as well as that of anyone who might have to read them over.

Instead, try to write descriptions of the game elements in question and their relation to the other elements. How do they compare in difficulty to each other? What traits does a particular AI agent have? Is this one more or less likely to run away in combat? Which AI capabilities will this element use and to what intended effect? How do the entity and its various effects appear to the player? How big is it compared to other objects? Include enough information for a programmer to understand what code will be required for the entity and sufficient description that an artist will be able to make a concept sketch. You want to provide as much useful detail as possible without overdoing it. Readers, whether artists, programmers, or other designers, will know when you are just documenting for documenting s sake, in which case your document stops being practical and useful. Do not waste their time by making them read reams of fluff to get the information they need.

Story Overview

Though not strictly necessary for a design document, I think having a brief Story Overview can be quite helpful in a design document, assuming your game has a story at all. Properly written, the overview provides all of the document s readers with an easy-to-read narrative of what transpires in the game. Much like the design document s overview, the Story Overview is a quick way for everyone on the team to understand the story s big picture. To achieve this, you must keep the overview to an easily readable length while trying to include all of the major story points. A couple of pages should be sufficient, though this may vary depending on the complexity of the game s story; a shooter might only require one page, while an RPG might take a few more.

Certainly you do not need to include all of the game s sub-quests or describe every conversation players will engage in or every character players will meet. Try to make the Story Overview as compelling and readable as possible, so people will want to read it. While the Game Mechanics section may be difficult to read with its bullet-point lists and attention to detail, your Story Overview should be a pleasure to read. Indeed, if it is not a pleasure , try to figure out why not. Is it because your story is not that compelling? Do you need to refine and improve it in order to make it more interesting?

Game Progression

Depending on the nature of the game, the Game Progression section may well turn out to be the longest in the design document. This is where the game designer breaks the game down into the events players experience, and how they change and progress over time. This section will provide a guide for both the art team and the level designers as to what types of environments they will need to create for the game. The level designers take this section as a guideline for what each level is supposed to include and then fill in all the details as they build out each level, bringing all of the components of the game together.

For many types of games, including RPGs, RTS games, first-person shooters, action/adventures, and mission-based flight simulators, the Game Progression breakdown will be best done by level. For each level, you should describe in detail what challenges players will face, what story (if any) transpires on them, and the visual aesthetics of the levels. Figure out and describe what the major challenges will be on a given level: fighting with a horde of enemies at location A, meeting and talking to a specific character at location B, and solving a gameplay puzzle at location C. You certainly do not need to break down the level to the point where every single conflict is listed in minute detail. As with the character statistics, this is something that you will only be able to do when you are actually working with the level, when you are able to try the conflict a certain way and test it out. Explain how the appearance of the level will communicate the game s story, if applicable. What objects and items must be in what locations for the story to progress properly? Also discuss which elements from the game s palette will be available on this level. Which types of enemies will players expect to encounter and what types of items will they find along the way?

More than anything, try to put into words how the level should affect players, not just in terms of how difficult the level will be, but what sort of gameplay experience players will have. How do you want players to feel when they are playing the level, and how should those feelings fluctuate over the course of the level? Should players feel constant conflict and challenge, or is this level more slow-paced and centered on exploration? Is the story at a climax in this level, resulting in increased tension, or is the level more slow-paced, focusing on filling in the game s back-story? As you write your Game Progression, always keep in mind how players should feel when playing a given level, and try to communicate that emotional state in your writing.

Of course, not every game has levels, and so your Game Progression may not break down so easily into self-contained units. But most games have stages of some kind. Try to determine what the stages of your game are, and break down your Game Progression into these stages. For example, the original arcade game Centipede has a series of waves players play through. In that game, once players kill all the segments of the centipede, they progress to the next wave. The waves are cyclic, with each subsequent wave throwing in a different centipede, either in terms of its length or speed.

Free-form strategy games such as the SimCity series will not require a Game Progression section, since what happens during the game is entirely determined by the player s choices and the game mechanics. Pictured here: SimCity 2000 .

Also, from each wave to the next, the conditions under which certain enemies appear change. For instance, the flea never comes out in waves in which there is a twelve-segment centipede on the play-field. If one were to write a Game Progression for Centipede (which would not need to be very long at all), one would want to break it down by waves, clearly delineating how the game changes from wave to wave.

Some games may not need a Game Progression section at all. For instance, a design document for a strategy game like Civilization or a software toy like SimCity could describe all of the relevant gameplay in the Game Mechanics, AI, and Game Elements sections. Since the levels in these games are randomly generated anyway, there is not much use in having a Game Progression section. However, if the game in question is to include certain scenarios that do start on predefined levels in specific configurations (as the SimCity games do), a Game Progression section would be the ideal place to describe these different scenarios and how they will challenge the player.

System Menus

The System Menus section is where you should detail the main menu and whatever other options screens players will be presented with at various points outside of the game itself. These menus do not actually impact the gameplay in any significant way, and as a result should be separated into their own unique section. You should include descriptions of how players will save their game and how they will load it later. Describe what type of interface players will have with these menus: will they use mouse-pointer-based point-and-click, or will they use the Enter and arrow keys, or both? Try to be as complete as you think is necessary to ensure that the system menus are intuitive enough to allow players to enjoy playing the game itself. Producers love to see that you have fully described the flow of these menus, so it may be important that you include a System Menus section, though, in my opinion, such a section is not truly required for a complete design document. It might even make sense to make the System Menus section into its own separate document, since they are so divorced from the gameplay proper.

Related

Категории