TAKE CONTROL GAME DESIGN DOCUMENT

Transcription

1 TAKE CONTROL GAME DESIGN DOCUMENT 04/25/2016 Version 4.0 Read Before Beginning: The Game Design Document is intended as a collective document which guides the development process for the overall game design of an individual product. Italicized areas in the template should be filled in with the appropriate information per section and template guidelines should be followed. Adaptation of the GDD structure must be approved before being implemented as the new standard. Additional information and instructions are included in these boxes throughout the document, they should be deleted from the final version. Page 1 of 20

2 REVISION LIST Version Author Date Comments 1.0 Mary Fran Thompson 1.0 A very rough draft. Items that need to be addressed/subject to change are highlighted in yellow with comments. I'll need input from Nora for graphics and Will for coding. 2.0 Will Altizer 9/30/15 Reviewed 3.0 Maria Gaiser 10/30/15 Reviewed the document for consistency and detail. 4.0 Kimberly Workman 4/25/16 Updated for current version Within this section, all changes to the document are noted and a new revision saved to the shared drive [with the author's initials and version number]. Comments should be descriptive as to what changes were made between the prior version and the current version. Page 2 of 20

3 Table of Contents Take Control Game Design Document... 1 Revision List Introduction Take Control Core statement Game Design Document Development Flow Of Development Internal and External Review Overall Components Game Engine Code Components Types of Artwork Sound Components Target Platforms Technology Requirements Overall Framework Setting Player Interaction Objective Interactive Structure... 9 Layout... 9 Functionality Interactive Features Menu Selection: Verbal Integration Purpose Basic Functionality Start screen Layout Functionality Time Estimate Graphics Coding Select a Substance to Take Control Over...13 Layout Functionality Time Estimate Page 3 of 20

4 Graphics Coding Select a Location (background) Layout Functionality Time Estimate Graphics Coding Tutorial Screen Layout Functionality Time Estimate Graphics Coding Play Screen Layout Functionality Time Estimate Graphics Coding End Level Menu: Summary Layout Functionality Time Estimate Graphics Coding Team Game Design Document Graphics Functionality and Live Release The Table of Contents is automatically generated from the headers included in the document. To update the ToC, right-click on the ToC and select Update Index/Table. Page 4 of 20

5 1. INTRODUCTION This design document is meant to define the over-arching features that will be included in Take Control. These features include the user interface (UI), navigation, core game-play mechanics, functionality, and visual assets. The introduction to the GDD is meant to give an overall summary of the document, interactive features to be used in the product, etc. 1.1 TAKE CONTROL CORE STATEMENT Take Control is a treatment support video game for adults in treatment for alcohol, tobacco, or non-medical use of prescription drugs, as well as those having issues of addiction with gambling, food, or video games. The fun, low-stress game will empower players to take control over their addictions. The product's core statement should be clearly defined here. Explanation of what the product is meant to do, topics of education included, and the overall core purpose should be mentioned. 1.2 GAME DESIGN DOCUMENT This document is intended to be read by the designers, developers, and management team involved in the production of these interactive features. After this document has been completed, any additions / revisions / suggestions to this document will be made in a different color before becoming final and included in the next revision. This section is pre-defined and does not need to be altered. Page 5 of 20

6 2. DEVELOPMENT 2.1 FLOW OF DEVELOPMENT The development process for the evolution of these features is as follows: Completion of Game Design Document (GDD) Internal Review Adaptation of GDD Subsequent Review and Refinement of GDD Elements (Internal/External) Prioritization of Features Graphic Mock-Ups of Framework and Features Adaptation of Visual Design Basic Framework and Functionality Integrated Internal Review Adaptation of Functional Prototype External Review Adaptation of Functional Prototype Live Release This section is pre-defined and does not need to be altered. 2.2 INTERNAL AND EXTERNAL REVIEW Internal review of development will occur through blog comments, during initial review of the GDD, and internal testing, during review of the functional prototype. All comments will be collected and actions taken to refine based on these notes. External review of the GDD will occur through contact and external review of the functional prototype will occur through the use of links and descriptions being sent to the reviewer (consultant). All comments will be collected and actions taken to refine based on these notes. This section is pre-defined and does not need to be altered. Page 6 of 20

7 3. OVERALL COMPONENTS 3.1 GAME ENGINE Take Control will use DirectX 11. The technology engine that the overall game will utilize will be described here. 3.2 CODE COMPONENTS All code for the game will be written in C#. The coding that will be used in the overall game should be described here. 3.3 TYPES OF ARTWORK The following types of artwork will be utilized in the game: 2D backgrounds (photographs for in-game backgrounds, illustration for UI background) 3D bottles, cigarette packs, prescription drugs, gambling chips, candy bars, video game controllers 2D bottles, cigarette packs, prescription drugs, gambling chips, candy bars, video game controllers The artwork that will be used in the overall game should be described here. 3.4 SOUND COMPONENTS The following sound components will be utilized in the game: fireworks sound effect for swatting substance background music telephone ring for telephone sponsor (support item) The sound features that the game will utilized should be described here. 3.5 TARGET PLATFORMS The game will be featured on the following platforms Windows 8.1 Kinect for PC Page 7 of 20

8 The platform(s) that the game will be designed for should be described here. 3.6 TECHNOLOGY REQUIREMENTS Operating System Windows 8.1 Hardware 64-bit (x64) processor 4 GB Memory (or more) Physical dual-core 3.1 GHz (2 logical cores per physical) or faster processor USB 3.0 controller dedicated to the Kinect for Windows v2 sensor DX11 capable graphics adapter A Microsoft Kinect v2 sensor, which includes a power hub and USB cabling Software Kinect for Windows v2 SDK Visual Studio 2012, 2013 The full specifications of what technology requirements for each platform should be described here. Page 8 of 20

9 4. OVERALL FRAMEWORK 4.1 SETTING The setting of Take Control will be one of the following options: Alleyway Bakery Candy Aisle Convenience Store Dive Bar Dumpster Kitchen Liquor Store User-uploaded image The setting of the game should be fully described here. 4.2 PLAYER INTERACTION Take Control will be a 1-player experience wherein the player will select a substance over which they wish to take control and the setting in which they would like to accomplish this task. Full descriptions of the number of players the game supports, whether the player can choose an avatar / how they are represented in the game, as well as how they interact with the game features should be described. 4.3 OBJECTIVE Players should strive to dodge and hit as many substances as possible, as well as successfully grab a phone when prompted with a call from their sponsor. The objective of the game, what gaps it is trying to fill, as well as what the overall goal is should be described here. 4.4 INTERACTIVE STRUCTURE LAYOUT Start screen background image Page 9 of 20

10 brief instructions Tutorial and wrapper User interface (UI) substance icons 3D cigarette pack 2D cigarette pack 3D Rx bottle 2D Rx bottle 3D bottle 2D bottle 3D gambling chips 2D gambling chips 3D candy bar 2D candy bar 3D video game controller 2D video game controller player-uploaded image location icons alleyway bakery wine bar candy aisle convenience store dive bar dumpster kitchen liquor store player-uploaded background illustrated background instructions game starts/in-game activity selected background selected substance fireworks sound when substance is successfully hit fireworks animation when substance is successfully hit Page 10 of 20

11 score indication time indication phone image animation when phone is successfully grabbed flashing animation when phone is about to disappear on timeout ringing sound flashing avatar animation when phone is hit end level menu selected background score indication time indication retry button continue button quit button FUNCTIONALITY start screen through visual cues and sparse text, the player is instructed to say the trigger words or place hand over the menu selections to initiate the game tutorial/wrapper explains how to play the game and the reasons behind game-play game starts/in-game activity selected substance comes flying towards player (few in numbers to start) speed, number of substances increases over levels (physics become more varied) 60 seconds before level ends end level menu player may choose to retry the level player may choose to continue to next level points are erased and player starts from 0 option is disallowed if player has not reached the 100 points necessary to proceed player may choose to quit and end the game end game screen is presented when quit is selected Full, textual descriptions of both the visual layout and the functionality needed should be described for the overall framework of the game. Descriptions should cover all needed elements of basic layout (images needed, placement, color examples) for the framework. The detailed functionality and visual/functional elements of the interactive features should be described in the relevant section. A visual screenshot to illustrate the idea can be included, but should not be relied on over textual description. Page 11 of 20

12 5. INTERACTIVE FEATURES 5.1 MENU SELECTION: VERBAL INTEGRATION This mechanic would be functional within the: start screen button/menu UI (selecting options, navigating the menu) end level menu (choosing where to go next) The integration point is meant to describe where the interactive element would fit into the overall product. Descriptions of what information it is meant to illustrate should be fully explored, and a screenshot of the proposed integration point should be utilized, if applicable. Purpose The purpose of the interactive element is to provide a clear, consistent selection mechanic that is both reliable and easy to use. A mechanic that is simple to learn and use will help to build the player's confidence. We decided not to use in-game mechanics here, primarily because we were concerned with consistency (teaching players to select substances by swatting them could be confusing). The purpose of the interactive element should be described so that we can define why the interaction is needed and what purpose it would serve in the overall experience. Basic Functionality Players will select their desired options by speaking the initiation phrase, as instructed on the screen, or placing their hand over the phrase. Players will then move on to the next screen and/or set of instructions. The Basic Functionality section should be used to give a brief overview of the functionality type and a short sentence on what the overall interaction will be. Start screen LAYOUT full-screen background simple text instructions that will read When you are ready, say Take Control to begin or place your hand over Take Control! FUNCTIONALITY Players will begin the game by stating the initiation phrase When you are ready, say Take Control to begin! or placing their hand over the phrase. This functionality also needs to support non-english speakers with visual instructions of how to utilize hand gestures. Page 12 of 20

13 Full, textual descriptions of both the visual layout and the functionality needed should be described per screen. Descriptions should cover all needed elements of layout (images needed, placement, color examples) and functionality (interactive features, how the elements interact, what occurs at each step of the player engagement on the screen, how the screen bridges to the next or ends / resets the experience). A visual screenshot to illustrate the idea can be included, but should not be relied on over textual description. Time Estimate GRAPHICS full-screen illustrated background instructions ESTIMATED TIME NEEDED FOR GRAPHICS: 1 hour CODING start functionality transition animation integration between start screen and UI selection mechanic graphics integration ESTIMATED TIME NEEDED FOR CODING FUNCTIONALITY: 3 hours Estimates should be given for the visual and functionality development for the overall interactive feature. Time estimates may be broken down by screen, as well as total time, if necessary. Select a Substance to Take Control Over LAYOUT full-screen illustrated background all selectable substances will be onscreen text in the center of the banner will read Choose the item you wish to Take Control over or place your hand over the item FUNCTIONALITY Players will select a substance to take control over by saying the selection phrase, as indicated onscreen: alcohol, cigarettes, pills, gambling, candy, video games. Additionally, hand selection of objects can be Page 13 of 20

14 supported. This functionality also needs to support non-english speakers with visual instructions of how to utilize hand gestures. Additionally, support for player-generated upload of images should be included. Full, textual descriptions of both the visual layout and the functionality needed should be described per screen. Descriptions should cover all needed elements of layout (images needed, placement, color examples) and functionality (interactive features, how the elements interact, what occurs at each step of the player engagement on the screen, how the screen bridges to the next or ends / resets the experience). A visual screenshot to illustrate the idea can be included, but should not be relied on over textual description. Time Estimate GRAPHICS full-screen illustrated background substances (2D or 3D) 3D cigarette pack 2D cigarette pack 3D Rx bottle 2D Rx bottle 3D bottle 2D bottle 3D gambling chips 2D gambling chips 3D candy bar 2D candy bar 3D video game controller 2D video game controller player-uploaded image instructions under each object to tell players to say key phrase or place their hand over the object ESTIMATED TIME NEEDED FOR GRAPHICS: 2 hours CODING graphics integration selection integration for all substance options transition animation integration between select substance screen and select setting screen ESTIMATED TIME NEEDED FOR CODING FUNCTIONALITY: 3 hours Page 14 of 20

15 Estimates should be given for the visual and functionality development for the overall interactive feature. Time estimates may be broken down by screen, as well as total time, if necessary. Select a Location (background) LAYOUT full-screen illustrated background all selectable settings will be onscreen Text instructions will read Say the name of one of the locations below to use as a background or place your hand over the background you wish to choose A back option will be included for navigation FUNCTIONALITY Players will select a location by saying the initiation phrase associated with the background they would like to choose (alleyway, bakery, wine bar candy aisle, convenience store, dive bar, dumpster, kitchen, liquor store) or placing their hand over the object. This functionality also needs to support non-english speakers with visual instructions of how to utilize hand gestures. Additionally, support for player-generated upload of images should be included. Full, textual descriptions of both the visual layout and the functionality needed should be described per screen. Descriptions should cover all needed elements of layout (images needed, placement, color examples) and functionality (interactive features, how the elements interact, what occurs at each step of the player engagement on the screen, how the screen bridges to the next or ends / resets the experience). A visual screenshot to illustrate the idea can be included, but should not be relied on over textual description. Time Estimate GRAPHICS full-screen illustrated background location icon options alleyway bakery wine bar candy aisle convenience store dive bar dumpster kitchen Page 15 of 20

16 liquor store player-uploaded image instructions under each object to tell players to say key phrase or place their hand over the object ESTIMATED TIME NEEDED FOR GRAPHICS: 2 hours CODING graphics integration selection integration for all setting icon options transition animation integration between select setting screen and game-play screen ESTIMATED TIME NEEDED FOR CODING FUNCTIONALITY: 3 hours Estimates should be given for the visual and functionality development for the overall interactive feature. Time estimates may be broken down by screen, as well as total time, if necessary. Tutorial Screen LAYOUT Chosen background Chosen icon / substances Visual rendering of play onscreen FUNCTIONALITY Players will be taught how to play through a tutorial situation, having their selected background and object integrated into a play-through prior to full game-play, as well as how scoring will be achieved. Additionally, a wrapper will supply information on the purpose of game-play and what is expected to be achieved as a result of the game. This should be repeated at each level to incorporate changed play actions (new objects) and to monitor status of player if they are ready, more confident, etc. This information is pulled from the GamePlay component of the user manual ( The game should ascertain the player s stage of change in order to accommodate that level of game-play. Full, textual descriptions of both the visual layout and the functionality needed should be described per screen. Descriptions should cover all needed elements of layout (images needed, placement, color examples) and functionality (interactive features, how the elements interact, what occurs at each step of the player engagement on the screen, how the screen bridges to the next or ends / resets the experience). A visual screenshot to illustrate the idea can be included, but should not be relied on over textual description. Page 16 of 20

17 Time Estimate GRAPHICS full-screen illustrated background illustrated substance / icon wrapper instructions of how to play and what the purpose of game-play is ascertaining the player s stage of change ESTIMATED TIME NEEDED FOR GRAPHICS: 2 hours CODING graphics integration transition animation integration directions for game-play and object integration ESTIMATED TIME NEEDED FOR CODING FUNCTIONALITY: 5 hours Estimates should be given for the visual and functionality development for the overall interactive feature. Time estimates may be broken down by screen, as well as total time, if necessary. Play Screen LAYOUT Chosen background Chosen icon / substances Scoreboard on upper left Timer on upper right Visual rendering of play onscreen FUNCTIONALITY Players will begin playing with their chosen substance / icon and background. They will hit / kick / destroy the chosen substance / icon in an attempt to take control over their addiction. For each destroyed object, the player will gain points. Objects should begin at the same speed and then increase as the level increases. The play of the objects should adapt based on the person s height and reach. Full, textual descriptions of both the visual layout and the functionality needed should be described per screen. Descriptions should cover all needed elements of layout (images needed, placement, color examples) and functionality (interactive features, how the elements interact, what occurs at each step of the player engagement on the screen, how the screen bridges to the next or ends / resets the experience). A visual screenshot to illustrate the idea can be included, but should not be relied on over textual description. Page 17 of 20

18 Time Estimate GRAPHICS full-screen illustrated background illustrated substance / icon scoreboard timer ESTIMATED TIME NEEDED FOR GRAPHICS: 2 hours CODING graphics integration transition animation integration tracking of person throughout game to retain main player and guide their ideal location integration of second hit functionality first hit stops object and second hit destroys it ability to utilize all body parts for hits variation in scoring based on actions how had object is hit, what body part is utilized, direction of hit ESTIMATED TIME NEEDED FOR CODING FUNCTIONALITY: 12 hours Estimates should be given for the visual and functionality development for the overall interactive feature. Time estimates may be broken down by screen, as well as total time, if necessary. End Level Menu: Summary LAYOUT 1 round summary retry option continue option quit option FUNCTIONALITY The end level menu will appear at the end of the level (when the timer reaches 0). The menu will provide players the option to retry, continue, or quit the game. Players are only allowed to proceed to the next level is they have achieved the points level necessary (100 points total). If this has not been achieved, players must retry the level until total points are accumulated. Page 18 of 20

19 Full, textual descriptions of both the visual layout and the functionality needed should be described per screen. Descriptions should cover all needed elements of layout (images needed, placement, color examples) and functionality (interactive features, how the elements interact, what occurs at each step of the player engagement on the screen, how the screen bridges to the next or ends / resets the experience). A visual screenshot to illustrate the idea can be included, but should not be relied on over textual description. Time Estimate GRAPHICS Menu text/icons ESTIMATED TIME NEEDED FOR GRAPHICS: 1 hour CODING Navigation functionality Reset of level (retry) Continuing to next level (continue) increased speed and points system based on increased levels End of game (quit) ESTIMATED TIME NEEDED FOR CODING FUNCTIONALITY: 3 hours Estimates should be given for the visual and functionality development for the overall interactive feature. Time estimates may be broken down by screen, as well as total time, if necessary. Page 19 of 20

20 6. TEAM 6.1 GAME DESIGN DOCUMENT Initial completion of the GDD will be done by the Take Control team and reviewed by the collective employees of Clinical Tools, Inc. through the use of blogs and access to the shared drive document. Refinements and adaptations to the document will be made by the Take Control team and prioritization of features will occur with the same team. A description of the employee(s) who are responsible for initial creation, and further refinement, of the GDD should be included here. The process by which review of the GDD and how revisions are made should be fully described. Also, the completion point of this stage of the development should be indicated. 6.2 GRAPHICS Graphic mock-ups, based on the GDD, will be done by our graphic designer. She will utilize the GDD to create visual examples of the features described. These visual mock-ups will be available and reviewed by the collective employees of Clinical Tools, Inc. through the use of blogs and access to the shared images folder where they will be stored. Refinements and adaptations to the images will be made by our graphic designer until such time as the layouts are approved. A description of the employee(s) who are responsible for the graphic design of the interactive elements should be included here. The process by which review and revisions of the graphics are done should be fully described, and the completion point of this stage of the development should be indicated. 6.3 FUNCTIONALITY AND LIVE RELEASE Once the graphics are approved, integration of basic functionality will be completed by our programmer and reviewed by the collective employees of Clinical Tools, Inc. through the use of blogs and access to the testing pages where these features are stored. Refinements and adaptations to the functional prototypes will be made by our programmer during both internal and external review. Once the functional prototype has been reviewed and approved by both internal and external reviewers, the code will be integrated into the relevant pages by our programmer. A description of the employee(s) who are responsible for the functionality integration should be included here. The process by which review and revisions of the functional prototype are made should be fully described. Page 20 of 20