0% found this document useful (0 votes)
93 views22 pages

INB280 / INN280 Game Design Document Template: Splitting Up The Work

The document provides a template for a game design document (GDD) intended for use in a course focused on game design. It suggests how a team of three students could split up the work by assigning each member a major section to focus on. The template includes sections for vision, moment-to-moment gameplay, typical player experience sequence, player progression and customization, levels and environments, characters, story and dialogue, user interface, audio and visual design, development roadmap, and appendices. Brief explanatory text is provided under each section heading to guide content.
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
93 views22 pages

INB280 / INN280 Game Design Document Template: Splitting Up The Work

The document provides a template for a game design document (GDD) intended for use in a course focused on game design. It suggests how a team of three students could split up the work by assigning each member a major section to focus on. The template includes sections for vision, moment-to-moment gameplay, typical player experience sequence, player progression and customization, levels and environments, characters, story and dialogue, user interface, audio and visual design, development roadmap, and appendices. Brief explanatory text is provided under each section heading to guide content.
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 22

INB280 / INN280 Game Design Document Template

Please note that this Game Design Document (GDD) template is specially designed for use in this unit. Though it has much in common with a GDD used in a commercial project, this template is simplified and streamlined. In particular, it does not provide as much technical or artistic detail as a commercial GDD would. This is because this unit is focused on game design. Also, this template is organised to help a small team split up the work into clean sections that each team member can work on separately. The following is just one way of many to organise a GDD. The key goal is to describe the game with enough completeness and detail so that this document could be handed off to a new development team, and then with no other instructions from you, they would make a complete, enjoyable game similar to the one you have in mind.

Splitting up the work


Here is one way for a team of three to split up the sections, and end up with roughly the same amount of work. Team member A is the one best at moment-to-moment gameplay. Do the big section headed Moment-to-moment gameplay. Team member B is the one best at building the overall arc of the player experience from beginning to end, telling a story and varying the challenges. Do the big section headed Typical player experience sequence. Team member C is the one best at making player evolution and choice systems, communicating the overall spirit, and tracking the little details that might fall through the cracks. Do all the other parts of this document, and make the final edit.

You should adapt the above scheme to the needs of your team and your game. Some game genres are heavier or lighter than average in some sections. For example, an old-fashioned adventure game would have much less moment-to-moment gameplay and much more narrative than average, giving team member B much more work than team member A. The hardcore, brainless arcade action game would reverse this. Split up the work in a way that makes sense for your game, and gives equal work to each team member.

All of you need to work together! These sections refer to each other, so you cant each go off in your own direction and hope it all matches up at the end it wont. Make sure you know what each one of the others is writing.

Referring to theory
In several places in this documentat least once per sectioninclude a text box describing the theory that has informed your choices and the reasoning / justification behind your choices. You might also just describe your deeper reasoning for your decisions in more detail here. A GDD wont usually have these references to theory or the deeper reasoning, but for this assignment, these text boxes are important to show how you are applying the theory you are learning in the unit.

Amount of Detail
Your guiding principle in the GDD should be more detail on fewer things (rather than less detail on everything). For example, if your game has 20 levels you might describe 3 or 4 levels in detail (rather than providing brief detail on all 20 levels) and just list the other levels, similarly if you have a huge number of enemies you should list them all, but provide detail on a selection of them.

Including GUI and controls


In most sections, you need to put in details of the Graphic User Interface (GUI) and control scheme. The template below has indications of where these should go. In general, keep the GUI and controls as close as possible to the text where those functions are described. Use Balsamiq to generate the GUI layouts.

Use tables to describe what each control does, like this: Control X button Action Jump Notes Hold down X to jump higher

Left stick

Move avatar

Right stick Click left stick

Rotate avatar Toggle avatar walk/crawl

Left-right make avatar strafe from side to side, and slightly rotate. Forward-back make avatar move forward and backward. Backward movement is slower. Left-right rotate the avatar. Forward-back does nothing.

...or this, in a section describing a level-up screen: Control Left stick A button X button B button Action Select each skill Spend 1 training point on selected skill Undo 1 training point spend on selected skill Close this screen Notes Each skill is highlighted Makes negative buzz if there are no points to spend Makes negative buzz if there is nothing to undo for this skill

Adding graphics
In several places in this document, whenever you think it will add understanding and impact, include graphic references that illustrate what the text is describing. These are not required, but highly encouraged, to add impact, interest, and clarity. The graphics can range from very simple drawings to photographs and renders. The graphics dont need to be your ownborrow visual assets such as photos, movie stills, game screen captures, or the like. However, if you did not create the graphic asset, you must include a reference next to the asset. Cite where you got the asset from. Do not worry too much about the specific reference style, but make sure the reader could access the asset if they wanted to, based on your reference.

(From: Microsoft Word 2007 Clip Art) Now, onto the template. Include each of the following section headings. Remove the explanatory text under each heading, and insert your own text.

[Do not include the content above this line the first 3 pages in your submission] ________________________________________________________________________

(Insert game title here)


Include document version number, authors (name and student number), date, and workshop time

Vision
This is a compelling summary of your game in a few pages. First, capture the essence of your game in a few captivating sentences. Then briefly describe these, in any order, with no more than a sentence or two for each: Genreaction, adventure, FPS, etc. Platformcomputer, iPhone, Xbox, etc. Type of playsolo, multiplayer, or both The chief emotions and experiences players will have The mood, style, and visual treatment The main character(s) The basic thrust of the story being told, if any The major goals and challenges The key featuresjust the few most important things the player, enemies, and environment can do to each other The core audience The best way to do this is to name one or two recently made, popular games the players of which should enjoy your game, and describe why they will enjoy it For example, Players of Minecraft would find our game compelling due to our mine-and-build gameplay plus the added twist of dynamic biological evolution.

If this game is similar to others already in existence, what makes this game most distinctive?

Note: though this section briefly mentions the characters, story, goals, challenges, and features, these elements must also be described in more

detail in the sections to come. Dont put in the vision section a key element that you dont mention again later in the appropriate section of this document.

Table of contents
Make sure this includes all the subsections to make finding material easy. Also, make sure you have page numbers turned on.

Moment-to-moment gameplay
In this large section, describe what the player spends the vast majority of the time doing: making actions, facing challenges, and experiencing consequences. This is the bulk of the gameplay. Note that this does not include the ways the player chooses to evolve or customise the avatarthat comes in a later section. This section is the main meat of the gameplay, when the player is immersed in the rhythm and flow of the game. Use the following sub-sections to organise all this. For example, in this sections theory text boxes you might talk about Batemans (2009) notion of fiero and how it informed your gameplay; equally you might talk about Sweetser and Wyeths notion of gameflow and how it informed your decisions. You should aim to justify your choices and explain why you made them. In all your textboxes, you should reference the sources of the theories you apply, e.g., Bateman, C (2009). Beyond Game Design. Boston, MA: Course Technology. In the textboxes in this documents example theories are given. You should not feel that you have to reference the theories used for examples. Also, you should expect to go beyond the examples listed.

Gameplay modes
If there is more than one mode in which to play the game, list the modes here and say how they differ. Multiplayer and solo modes should be included in the list. In later sections, mention if a feature is exclusive to one mode or another. You should describe the theory that you have applied in making your decisions and more generally, explain/justify your choices for example, here you might talk about why your game does benefit from a multiplayer mode or why it doesn't need one.

Avatar actions and abilities


Describe the actions that the player (through the avatar) can take and how they interact with the game. This is a specific description of what the player can and cannot do in the game. The aim is to list all of the players possible actions and the results of same, including specific commands and actions. If there is more than one choice of avatar, its best to first describe what all the avatar choices have in common, and then describe aspects unique to each avatar choice. List all of the following that the avatar can do or use at any point in the game, including such things as: Powers Skills Moves Items Vehicles Weapons Defences

For the above, describe their properties in a way that shows how they compare to one another, and why one should be used over another in a given situation. For example, if the avatar can choose between using two different weapons, is one always superior? Or are they each good in their own way, in their own situation? The data you provide should show how they compare. You should describe the theory that you have applied in making your decisions and more generally, explain/justify your choices for example, here you might talk about shadow costs and balance issues (dont forget to reference your theory sources)

Main HUD and control scheme


Describe here the heads-up display (HUD), and show a GUI diagram with Balsamiq. This is the description of how the game communicates essential data to the player. This includes displays for items held and selected, score, control options, navigation (map or radar), ammo, health, speed, and the like. This typically is a set of overlays on the game screen that constantly shows

the player essential information. Include a table of all the controls the player can operate during moment-tomoment gameplay, and which of the above abilities are activated by each of the controls. Provide details on the point of view or camera controls, if they are not obvious. If the POV changes during gameplay, describe how and when it changes. You should describe the theory that you have applied in making your decisions and more generally, explain/justify your choices for example, here you might talk about usability issues. (dont forget to reference your theory sources)

Enemies and obstacles


This is a list of each enemy (or active obstacle) the player can encounter in the entire game, with details about each. The difference between an enemy, a fixed obstacle such as a trap, and an environmental element (which might appear in a later section) can be blurry. Categorise them in a way that makes sense to you, and dont duplicate them. If there is a timed lava spout, list it here as an obstacle, or list it later as an environmental element, but dont list it in both places. As with the avatar, describe the specific actions that the computer controlled enemies can take and how they interact with the rest of the game. The aim is to list each enemys actions and the results from the same, as well as an idea of how the AI and other coded routines decide which actions to take. For each enemy, list its powers (such as weapons, effects, moves) and its attributes (such as its speed, health, evasiveness). For the above, describe their properties in a way that shows how they compare to one another, and how each one causes the player to act differently. For example, if the player encounters one kind of enemy instead of the other, is one always more difficult? Or are they each threatening in their own way, in their own situation? What different tactics are required to deal with each one? The data you provide should show how they compare. If an enemy has a lot of intelligence and personality, include the same set of information listed in the NPCs and allies section below. You should describe the theory that you have applied in making your

decisions and more generally, explain/justify your choices for example, here you might talk about balance issues and challenge theory. (dont forget to reference your theory sources)

NPCs and allies


This is a list of agents that help the player, or are not usually a threat. This includes non-player characters (NPCs) that the player encounters briefly, or allies that come along for the whole journey. Again, distinctions here can be blurry: an NPC can start friendly, but act like an enemy if displeased. Put such an NPC in either this or the enemy section, but not in both. Also, an ally might be a beast the player summons, so it could be categorised as an avatar power. For key characters include details as needed which can include: Back story (insofar as it directly affects the characters presentation; in the GDD there is no need for long backstories that only serve to inspire the dialog writer) Personality Appearance (visual references are particularly helpful here) Special abilities Relevance to the game Relationship to other characters

Extensive story or dialog that an NPC gives out as the games plot progresses is best to detail in the later section called Typical player experience sequence. Here, just list those aspects that apply to all the situations the NPC might appear in. You should describe the theory that you have applied in making your decisions and more generally, explain/justify your choices for example, here you might talk about affect and emotional issues (dont forget to reference your theory sources)

Interactive environmental elements


This is a list of elements in the environment that the player can interact with or be affected by. This does not include passive scenerythat will be

described in the later section called Typical player experience sequence. These are discrete elements that can show up in multiple places, encountered again and again. As mentioned above, there can be some blurring among dangerous elements in the environment, hazards, obstacles, and enemies. Put each thing in a section that makes sense, and avoid duplicating them in multiple sections. If the game has special physics requirements, or the environment selfevolves or changes on its own, this is the place to describe that. You should describe the theory that you have applied in making your decisions and more generally, explain/justify your choices depending on what you include in this section a variety of theories might be appropriate. (dont forget to reference your theory sources)

Multiplayer
If the game is both solo and multiplayer, so far the description probably focused on the solo experience, with a few things that were tagged as multiplayer only. In this section, finish describing any remaining details of how moment-to-moment multiplayer gameplay differs from the solo experience. This should also include how the camera behaves differently, if there is a split screen, and the like. You should describe the theory that you have applied in making your decisions and more generally, explain/justify your choices here you might talk about theories related to the social aspects of gaming. (dont forget to reference your theory sources)

Evolution and customisation


This is a new major section, not a subsection of moment-to-moment play. This section describes what the player chooses outside of moment-tomoment play, to evolve and customise their character or agent in the game. This describes what happens during breaks in the action, and which changes the avatar in some way. It can include such things as: Inventory

Buying and selling items Gaining and spending experience points Choices for how to develop one set of skills instead of another Choosing a path through a tech tree Gaining and using resources in crafting Picking new powers and talents Attaining achievements

All of the powers, abilities, weapons, items, and so on that can be chosen here should already have been described in the section above called Moment-to-moment gameplay. This section talks about how those things are unlocked and chosen. If the player automatically gains new powers and abilities without having to choose them, its better to describe that in the later section called Typical player experience sequence. Here, focus on choices the player actively makes to steer a path through the game one way or the other. If the player makes choices about new areas of the game world to unlock, this is the best place to describe that, since this is just another kind of ability the player is developing. Again, the areas themselves are described elsewhere; here, just describe how those areas are unlocked. Provide here GUI diagrams, made with Balsamiq, for the screens that present these choices. Include a table of the controls used to operate these screens. You should describe the theory that you have applied in making your decisions and more generally, explain/justify your choices for example, here you might talk about theories regrading interesting player choices on a higher level. (dont forget to reference your theory sources)

Game shell
This section shows how a player gets into, out of, and around a game session the shell that wraps around the gameplay. It includes details about the following, as appropriate: Starting a new game

Loading game Making a new character or world Changing from one level to another via a selection screen Changing game modes Finding a new multiplayer game session Saving and exiting the game

Provide here GUI diagrams, made with Balsamiq, for the screens that present these choices. Include a table of the controls used to operate these screens. You should describe the theory that you have applied in making your decisions and more generally, explain/justify your choices for example, here you might talk about usability issues. (dont forget to reference your theory sources)

Information and options


This section gives details of how the player, outside of moment-to-moment play, sees deeper information. Usually, viewing these will pause the game and use the whole screen. This includes things such as: Map (a mini-map shown during gameplay should be in the HUD section instead) Quest list and status Journal Encyclopaedia of information about the game world Extensive mission details

Also provide in this section options the player can change such as: Game difficulty Graphic and audio options Ways to customise the controls and display

Provide GUI diagrams, made with Balsamiq, for the screens that present

these choices and information. Include a table of the controls used to operate these screens. You should describe the theory that you have applied in making your decisions and more generally, explain/justify your choices for example, here you might talk about usability issues and how to give or hide information strategically. (dont forget to reference your theory sources)

Tutorial and help system


Describe the way the GUI instructs the player how to play the game, the help system the player can consult, and any other ways the game takes explicit actions to teach the player. This can include pop-up instructions, rollover text, highlights on the GUI, audio messages, step-by-step walkthroughs for how to use the GUI, and the like. If the game starts with a tutorial level that heavily uses these instructions, describe that level, like all the other levels, in the section headed Typical player experience sequence. Here, just describe the individual elements that are used to give helpful information to the player. Provide here GUI diagrams, made with Balsamiq, as needed. You should describe the theory that you have applied in making your decisions and more generally, explain/justify your choices for example, here you might talk about usability issues. (dont forget to reference your theory sources)

Meta-game details and miscellaneous


Every kitchen needs a junk drawer: Anything else that does not quite fit into any other section, describe here. Include details on any special technology the game needs. If the player is given a tool to edit the game world, fully describe it here with the same care and detail used to describe gameplay. (There is no need to describe the tools the development team needs to use;

thats a whole document in itself that thankfully you dont need to make this time!) You should describe the theory that you have applied in making your decisions and more generally, explain/justify your choices depending on what you include in this section a variety of theories might be appropriate. (dont forget to reference your theory sources)

Typical player experience sequence


In the sections above, every single toy in the toybox has been described: what it looks like, what it does, how it interacts. This large section describes how you will arrange those toys on the floor of the playroom for the player to encounter, a little bit at a time. This section does not introduce any new information about any of the individual elements such as avatar abilities, objects, enemies, environmental elements. If you only mention those important details here, they may be missed when marking this assignment, not to mention missed by your development team. In this section, describe the sequence in which a typical player will experience each of the game elements. If yours is a linear game, this is straightforward: list each level in order, and within each level (or for a selection of key levels remember more detail on fewer levels is better than limited detail on all your levels if your game has many), narrate what the player encounters during his or her linear progress. If yours is a sandbox game, narrate one likely way a typical player will move through the game, experiencing everything there is to experience. This section shows the overall arc of the player experience. It tells a story, showing how the player is lured on with challenges, discovery, evolution, story, surprises, frustrations, mysteries, revelations, and rewards. This is the section to show the overall structure of the game experience, to show how you will craft high and low points, peaks and troughs of challenge, moments of tension and relaxation. Assuming the player makes choices to evolve the avatar, give some idea of when each of those evolution points will probably occur. For example, at the end of the section describing level 1, say that by this point, the player should have enough experience points to choose a new tier 1 power, or have enough money to buy a new tier 1 weapon. After going through a few areas or levels, mention how the player should now be able to pick some of the more

powerful items, weapons, or skillsand list them by way of example. This is also where you should have all the deep details of the storyline, plot, dialog, and twists and turns in the narrative progression. It includes both interactive sequences and cutscenes. Introduce characters and boss enemies in the order a typical player would encounter them. There is no need to have line-by-line scripts for each NPC and cutscene, but provide the beats or basic elements of the story being told. If this section seems like it will itself be 50 pages, then you are making your game a bit too epic! Tell a good, simple story with force. If the game starts with a tutorial level, include that just as you would any other level of the game. In sequence, describe all the ways the game uses pop-ups, voice-overs, overlays, camera tricks, or the like to teach the player how to play.

(Level, chapter, or area name)


Make a subheading like the one above for each level, chapter, or area the player can enter. Under this subheading, describe everything that happens and is encountered there. You should provide the following information for each level (or for a selection of key levels remember more detail on fewer levels is better than limited detail on all your levels), area, or chapter in your game: Gameplay overview Mood and visual style (providing visual references) List of the enemies, obstacles, items, and environmental elements. Again, none of these should be newall of them should have already been described in the major sections earlier on in the GDD! Schematic (line drawing) layout diagram of the level or area, showing: The rough shape of the area Where the avatar begins Location of significant subgoals, obstacles, and enemies End goals or exits

Here is an example of a schematic so hastily made, you could not possibly feel bad about how rough yours might be:

Key 1 2 3

Feature Player start Buried cache Feral rabbit warren

Fork

Marshmallow elemental fortress

Jungle

7 8 9

Crumbling rock gauntlet Fuel tree grove Zombie boss

Notes Tall grass, strangler trees, a few gems hidden here and there Need iron pick to break rock, then dig with shovel. Contains armor wax. Many rabbit holes. Swarm of feral rabbits emerges when in center. Pretty easy but can waste your health biscuits if you are careless. Chewed skeleton can be looted for a pack of poison darts. Choose upper or lower branch. Either way, slide down a steep bluff so you cant go back once you make your choice. You can see ahead to areas 5 and 6 to get an idea of what youre choosing. The view is very pretty, inviting player to take a breather. A very tough encounter with marshmallow elementals dug in behind large glass shields and glue moats. Easier if you use the flamethrower; makes you wish you had fuel if you are running low. High loot rewards, and lots of sugar crystals suitable for crafting. Heavy jungle with thorn bushes and the occasional strangler tree hidden among the scenery. A medium difficulty encounter with vorpal stags, ice lions, and mutant mossies. Lots of cover allows stealth to evade some of the fights. Low loot rewards, but good for skinning the hides for crafting. If you chose area 5, you can access this hard jumping challenge across spires of crumbling rock over lava. Several fuel trees here can be tapped for fuel sap. Chest with gems and armor wax. (You get the idea)

You should describe the theory that you have applied in making your

decisions and more generally, explain/justify your choices for example, here you might talk about varying the pace, building and releasing tension, flow or using emotion. (dont forget to reference your theory sources)

(The next level, chapter, or area name)


Repeat the above, describing each of these in the same order a typical player will experience them.

Appendices
Team member contributions
Team member contributions to Design Document (a description of each team members contribution to the design document)

Prototype description
Describe what you plan for your Kodu prototype to include. First refer to the lectures and workshops to learn the capabilities and limitations of the Kodu engine. Then list here the few features, powers, enemies, and obstacles that you will implement in the Kodu prototype, referring to things you already described in detail in the main GDD. In general, you should plan to implement a few fun minutes of play in a single level or area. You should only need to implement elements that come from the section Moment to moment gameplay, and only a fraction of those elements. Concentrate on making something that captures the feel, rhythm, and flow of gameplay, allowing fun choices, challenges, and consequences in realtime. If your game lets the player make choices to develop and evolve the avatar, the prototype should implement just one possible version of the avatar, with those choices already made, hard-wired in, and unchangeable. Its challenging in Kodu to allow the avatar to swap among many items or modes, so concentrate on implementing only as many weapons, powers, and abilities that can be mapped onto the Xbox controllers buttons and triggers. Your game as described in the GDD will probably start off easy, with lots of instruction and gentle introduction, and then get more complex and difficult. For this prototype, its best to implement a slice of gameplay from a point about 15% of the way into the players arc through the entire gamepast the

really simple, gentle instruction phase, but before play reaches full complexity. However, if you want, you can implement the very first level or area of the game, from the first moment of play onward. Avoid implementing the final boss battle. Keep in mind that Kodu works far better with the Xbox controller. Though your GDD may describe a game played on the PC with a mouse and keyboard, or with a mobile device with a touchscreen, the prototype almost certainly will need to be playable with the Xbox controller. This fact alone may influence what kind of game you want to design in this unit. Also keep in mind that though Kodu has only simple, childish shapes, agents, and sounds, these only symbolise what your actual game would have. Your GDD can describe the player avatar as a ninja with a chainsaw, dismembering hordes of zombies that gush blood and drop severed heads that you pick up as loot. Thats fine. In Kodu, you can use the floating fish to stand in for the ninja, a short stream of white blips to stand in for the chainsaw blade, and unicycles to stand in for the zombies, which, when they die, leave coins behind to stand in for the severed heads.

Prototyping and playtesting timeline and task allocation


Put here your timeline for building the prototype, completing playtesting, and writing assignment 3. Give rough time estimates for each task, in hours or days of work. Tasks should be allocated to each team member, splitting the work evenly among all team members.

General Comments: Be sure to: Describe of the body and soul of the project You need to include details and the method by which each element will be implemented Make it readable Prioritise game features Get into the detail describe practical details Make ideas concrete give examples

Use flow diagrams, tables, charts and concept art to flesh out and clarify details Describe not just what but how e.g. dont just indicate that a game element must be balanced, provide a chart that shows values that will influence balance

Source: Creating a Great Design Document http://www.gamasutra.com/view/feature/3224/creating_a_great_design_do cument.php

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy