- GAME PITCH - Used to sell other people on your game design - For independant developers, the pitch is used to get funding for the game - Sections - High concept - A paragraph or two that describes the game and why it is cool - The "elevator speech" for the game - Project overview - Two to five page overview of the entire game. - Graphics, diagrams are VERY helpful here, as they help sell the game - Should cover: - Key features - Backstory - Target demographic - Project risks - System requirements - For this class, will be a presentation, PowerPoint encouraged! - Grading criteria - 30% based on technical completeness Has all sections, sections are covered in depth - 25% based on the game design quality Game seems fun, mechanics are interesting - 25% based on design completeness Design is thought out, group can answer questions in detail - 20% based on misc quality of presentation Visual slides, audience engagement, etc - GDD (GAME DESIGN DOCUMENT) - 10 - 20 pages - Game pitch sections are at the beginning, other people will usually only read the game pitch sections! - Additional sections go into more depth, to make sure everyone is on the same page. - Should design backup plans in case certain features do not get in. - Sections - Table of Contents - High concept - Project Overview - Key features - Backstory - Target demographic - Project risks - System requirements - Game Mechanics - Core gameplay - Moment to moment and Minute to minute - Game progression - Game play -- specific elements of the game - Game physics (if applicable) - AI behaviors (if applicable) - Multiplayer modes (if applicable) - User Interface - Mockups help a lot - Functional requirements (what must the UI be able to do) - Flowchart of menu states (important for menu-based games like Tacticle RPGs) - Art and video - Concept art (not necesarry for this class) - 2D and 3D "in game" art (if important) - Listing of cinematics, cut scenes - Sound and music (if important) - Sound FX - Background music - Gameplay element sounds - Storyline (if applicable) - Levels (optional, but nice) - Diagrams of key levels - Level progression flowchart - Grading criteria - "Designer" role will have extra weight given to GDD in final grade - 50% based on technical completeness Has all applicable sections, sections are covered in depth - 20% based on scoping Reasonable back up plans, good choice of optional vs. required features - 20% based on misc quality of document Good diagrams, pretty layout, good use of pictures - 10% based on spelling, gramatical correctness - TDD (TECHNICAL DESIGN DOCUMENT) - 10 - 20 pages of documentation, covers APIs and implementation of difficult features - Rarely read outside of the development team - Proves that the game can get implemented technically, and enables developers to work in parallel because APIs are set in stone. - Sections - Table of contents - Platform and OS Target platforms. Should include at least WinXP - External Code All external code used by the game (SDL, FMod, etc) - Data Flow Where data is stored, loaded, saved. How data is passed around between different parts of the engine - Control loop High level ordering of the different subsystem updates - Graphics engine - Capabilities and API for graphics engine. - List supported FX, blend modes, particle systems, etc. - Sound and music - Capabilities and API for sound engine. - List sound support, positional sound, streaming, user-soundtracks, etc. - Game mechanics - Prove simple viability of each core mechanic - Do not need to specify exact implementation details - AI (if applicable) - List techniques for implementing behaviors - UI (if applicable) - Capability of widget system required for game - Game Physics (if applicable) - Multiplayer (if applicable) - Details of client / server communication - Level specific code (if applicable) - Any major tech needed to support specific levels - Art instructions (not necessary for this class) - Art pipeline description for artists. - Describes what formats will be supported, how they get integrated into the game - Budgets (not applicabel for this class) - Memory + file size budgets for different art assets - Heavily tied to target platform; consoles have constrained budgets - Risk analysis - Back up plans for potentially risky tech (3D vs. 2D engine, simpler AI, etc) - Grading criteria - "Tech Lead" role will have extra weight given to TDD in final grade. - 50% based on technical completeness Has all applicable sections, sections are covered in depth - 20% based on usefulness of doc Light documentation on obvious or trivial parts, heavier documentation on more complicated parts. - 20% based on misc quality of document Good diagrams, pretty layout, good use of pictures - 10% based on spelling, gramatical correctness - SCHEDULING - Prioritize your features, three levels - #1 - Must be fixed immediately, this is blocking someone - #2 - Must be implemented before ship for the game to be fun - #3 - Nice to have, but not strictly necesarry - Waterfall vs Agile - Waterfall concentrates on having a nice schedule up front - Fails to accomidate change of design later on - Agile works on refining the schedule every week - Fails to scope project well, schedule is not as accurate - BOTH ARE GOOD CONCEPTS! - Deliverable - Should have week-by-week tasks for every person - List priorities on tasks, are they optional (#3) or required (#2) - Should have critical path highlighted - Grading policy - "Producer" role will have extra weight given to Schedule in final grade - 35% based on technical completeness Game appears fully scheduled out - 35% based on appropriate use of priorities This is VERY important, it is the number one failure of game schedules - 20% based on a clear delineation of the critical path - 20% based on misc quality of document Good diagrams, pretty layout, good use of pictures