2.  A plan of attack for your games content  Or (more specifically)  A detailed description of all games mechanics, objects, characters, stats, ect… that will be used to create your game

3.  Why we make a game design document  Game design is not done on the fly  Collaborate as a team to agree upon the games content  Solve problems before they occur  To maintain a single game vision  Understand the scope of the game

4. How is this any different then what we did in ROG?

5.  Write the document for the people producing the game not the people buying the game.  Your not trying to sell the game. Don’t make it a marketing pitch  Anticipate questions the production staff may have about the game and answer those questions preemptively.  When everyone is on zero sleep and can’t think straight the design doc should serve as a reference.

6.  Nobody should be able to say, "I did it that way because I couldn't find any reference to it in the document.“  Answer all of the “What if…?” and “How…?” questions  Read through the TRC within the SGP syllabus. Does your design meet all of those requirements?

7.  You have to have clear and understandable descriptions.  Example  Bad: “The menus will have a transition effect”  Good: “When going from one screen to another in the menu interface, the previous menu will fade out while the new menu slides in from off of the right hand side of the screen. This transition effect should be completed within half of a second.”

8.  Some things must be demonstrated  If a shape is important, give us an example  If you have some extra path finding (unit formations and the like) give us diagrams

9.  Invest in a Table of Contents  Core gameplay should make up a chunk of the ToC  It’s much easier to expand from a defined core set, then to just blindly start typing

11.  Executive summary  Short description  Genre  Target Audience  Key Features

12.  Treatment  Dust Jacket Story  Game Walkthrough  Not a literal walkthrough, a description of an average user experience

13.  A style section  Describe the art style of the game ▪ Describe thoroughly what kind of art you are looking for. ▪ Give references to other games/movies/shows/theater that have similar styles if you can.  Describe the general style of the music and sound effects. ▪ What kind a music will be used in the game? ▪ How will sound be used in your game?

14.  How does the game play?  What is the goal?  What obstacles are there to the goal?

15.  Puzzle game?  What are the puzzles?  How do you solve them?  Mini games?  How do they work?  What are their goals?  What obstacles are there to the goal?  Each mini game should have a mini document explaining it fully.

16.  Does the game have resources?  How do you collect them?  How do you use them?  Turn based game?  What is the turn order?  What can you do in each turn?  How does the player interact with the computers turn?

17.  What equations are going to be used  Physics  AI decision making  …  How do you compile statistics  Creation  Leveling up  Damage per second  …

18.  Items, power ups, breakable objects, buildings, puzzle shapes, bullets, …  Every game object should be described  Name  Stats (actual numbers)  Visual description  Interactions  …

19.  For example, if you have characters we need to know:  Where are they?  What levels are the found in?  What do they do?  What abilities do they have?  What do those abilities do?  What animations do you need?  What are their stats?  HP, MP, speed  Do they have any special properties?  Do they fly?  Do they have dialog?  What do they say?  Does it ever change?  …

20.  All AI states should be described though flowcharts  Archer:

21.  Levels /Maps/Sections/Environments  Name/ID  Brief description  Starting conditions  Goal  Scale  Environmental interactions  Ambient environmental aspects  Objects  Enemies  Puzzles  Concept level design (yes an actual lay out /drawing )  …

22.  Controls  Controller defaults  Keyboard defaults  Interface flow chart (This is super basic. Your chart will have more than this.)

23.  Screen layouts (for every screen)  Short description of functionality  Image of an example layout

24. “Much as novice designers want to get their story out on paper, it has no place in the design document except in summary form.” – Brenda Brathwaite  Keep it short and to the point.

26.  It must describe everything in YOUR game  If your game contains aspects that were not mentioned in these slides (which it almost certainly does) you must describe and agree on those things as well

27.  A design document needs to cover every single thing in a game. If you see it on the screen or if it happens in the game, it needs to be documented.  Someone who doesn’t know how to program, design, or even play games should be able to understand everything in your game.

28.  Compile all the documents into 1 master design doc  Format the document  Spell check and grammar check the document.  Separate sections into separate pages  Put like types together  Put everything in an easy to understand order  (do not print this document, we want to save the trees)

29.  Your game. In all its glory  If it is in your game, it should be in the doc  If it is in your doc it should be in your game  Completed for Lab 3

30.  This is a lot of work  This will take a long time  This will end up being 50 pages or more  Most of this you have hopefully already written or agreed upon  This is normal  This will be immensely helpful

31.  Lab 2*:  Draft of Design Doc