Difference between revisions of "Game Design Document"
Abel Maciel (talk | contribs) (Created page with "{{Video game industry}} A '''game design document''' (often abbreviated '''GDD''') is a highly descriptive living software design document of the vid...") |
Abel Maciel (talk | contribs) (→References) |
||
(12 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
+ | [[Category:Game Design]] | ||
+ | [[Category:VR]] | ||
+ | [[Category:AR]] | ||
+ | [[Category:XR]] | ||
+ | [[Category: Design Management]] | ||
+ | |||
{{Video game industry}} | {{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. | 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= |
Latest revision as of 20:34, 13 April 2020
Template:Video game industry A game design document (often abbreviated GDD) is a highly descriptive living software design document of the design for a video game.[1][2][3][4] 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 designers, artists and programmers as a guiding vision which is used throughout the 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.
Contents
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 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 processed document, or as an online collaboration tool.
Structure
The purpose of a game design document is to unambiguously describe the game's selling points, target audience, gameplay, art, level design, story, characters, UI, assets, etc.[5][6] 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.[7] 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:[8][9]
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
- Anatomy of a GDD by Tim Ryan on Gamasutra
- Game specifications by Tom Sloper on Sloperama
References
- ↑ Oxland 2004, p. 240
- ↑ Brathwaite, Schreiber 2009, p. 14
- ↑ Bates 2004, p. 276.
- ↑ Bethke 2003, pp. 101–102
- ↑ Bates 2004, pp. 276–291
- ↑ Bethke 2003, p. 102
- ↑ Bethke 2003, p. 105
- ↑ Oxland 2004, pp. 274–186
- ↑ Adams, Rollings 2003, pp. 569–570, 574–576