View source for Game Design Document

[[Category:Game Design]]
[[Category:VR]]
[[Category:AR]]
[[Category:XR]]
[[Category: Design Management]]

{{Video game industry}}
A '''game design document''' (often abbreviated '''GDD''') is a highly descriptive [[living document|living]] [[software design document]] of the [[video game design|design]] for a [[video game]].<ref name="ox240">[[#Oxland|Oxland 2004]], p. 240</ref><ref name="bs14">[[#BrSch|Brathwaite, Schreiber 2009]], p. 14</ref><ref>[[#Bates|Bates 2004]], p. 276.</ref><ref>[[#Bethke|Bethke 2003]], pp. 101–102</ref>  A GDD is created and edited by the development team and it is primarily used in the [[video game industry]] to organize efforts within a development team.  The document is created by the development team as result of collaboration between their [[Game designer|designers]], [[Game artist|artists]] and [[Game programmer|programmers]] as a guiding vision which is used throughout the [[video game development|game development]] process. When a game is commissioned by a game publisher to the development team, the document must be created by the development team and it is often attached to the agreement between publisher and developer; the developer has to adhere to the GDD during game development process.

== Content ==
A game design document may be made of text, images, diagrams, [[concept art]], or any applicable media to better illustrate design decisions. Some design documents may include functional [[Software prototyping|prototypes]] or a chosen [[game engine]] for some sections of the game.

Although considered a requirement by many companies, a GDD has no set industry standard form. For example, developers may choose to keep the document as a [[Word processing|word processed document]], or as an online [[Collaborative software|collaboration tool]].

== Structure ==
The purpose of a game design document is to unambiguously describe the game's selling points, [[target audience]], [[gameplay]], [[Video game art|art]], [[level design]], story, characters, [[User interface|UI]], assets, etc.<ref>[[#Bates|Bates 2004]], pp. 276–291</ref><ref>[[#Bethke|Bethke 2003]], p. 102</ref> In short, every game part requiring development should be included by the developer in enough detail for the respective developers to implement the said part.<ref>[[#Bethke|Bethke 2003]], p. 105</ref> The document is purposely sectioned and divided in a way that game developers can refer to and maintain the relevant parts.

The majority of video games should require an inclusion or variation of the following sections:<ref>[[#Oxland|Oxland 2004]], pp. 274–186</ref><ref>[[#AdRol|Adams, Rollings 2003]], pp. 569–570, 574–576</ref>

===I. GAME OVERVIEW===
A. EXECUTIVE SUMMARY
B. STORYLINE (N/A) 
C. NAMES (N/A) 
===II. CORE GAMEPLAY===
A. MAIN GAME VIEW 
B. CORE PLAYER ACTIVITY 
C. GAME CONTROLS 
D. IN-GAME GUI
E. ACCESSIBILITY
===III. CONTEXTUAL GAMEPLAY===
*A. GAME SHELL FUNCTIONS
*B. GAME FLOW DIAGRAM 
*C. GAME MECHANICS 
*D. MULTIPLAYER MECHANICS (N/A)
*E. SPECIAL FEATURES (N/A)
===IV. GAME ELEMENTS===
*A. CHARACTERS
*B. LEVEL / MISSION / AREA DESIGNS 
*C. OBJECTS (N/A) 
*D. INTRO SCENE 
*E. MENU
*F. HOW TO PLAY 
*G. END SCREEN 
*V. SOUND 
*A. MUSIC 
*B. SOUND EFFECTS 
===VI. CHEATS===
===VII. MONETIZATION===
===VIII. APPENDICES===
*APPENDIX A: GAMEFLOW DIAGRAM

== External links ==
* [http://www.gamasutra.com/view/feature/3384/the_anatomy_of_a_design_document_.php Anatomy of a GDD] by Tim Ryan on [[Gamasutra]]
* [http://www.sloperama.com/advice/specs.html Game specifications] by Tom Sloper on Sloperama

=References=