LAFS PREPRO Session 2 - Game Documentation

  • 234 views
Uploaded on

Project Management Lecture for Session 2 of The Los Angeles Film School's Game PreProduction course.

Project Management Lecture for Session 2 of The Los Angeles Film School's Game PreProduction course.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
234
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
7
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Session 2 David Mullich Concept Workshop - Game PreProduction The Los Angeles Film School
  • 2. Core Pre-Production Team  Producer  Lead Designer  Lead Programmer  Lead Artist
  • 3. Game Documentation The game documentation is the bible from which the producer preaches the game’s goals, through which the designers champion their ideas, and from which the artists and programmers get their instructions and express their expertise.
  • 4. Game Documentation The purpose of game documentation is to:  Express the game’s vision  Describe the game’s contents  Present a plan for implementation
  • 5. Game Documentation The three principal documents:  Game Design Document (GDD)  Technical Design Document (TDD)  Art Document
  • 6. Game Documentation  In broad terms, the purpose of documentation is to communicate the vision in sufficient detail to implement it.  It removes the awkwardness of programmers, designers and artists coming to the producers and designers and asking what they should be doing.  It keeps the team from programming or animating in a box, with no knowledge of how or if their work is applicable or integrates with the work of others.  Thus it reduces wasted efforts and confusion.
  • 7. Game Documentation  Documentation does not remove the need for design meetings.  Getting people into a room or similarly getting everyone's opinion on an idea or a plan before it's fully documented is often a faster way of reaching a consensus on what's right for the game.  Design documents merely express the consensus, flesh out the ideas, and eliminate the vagueness.  They themselves are discussion pieces. Though they strive to cement ideas and plans, they are not carved in stone. By commenting on them and editing them, people can exchange ideas more clearly.
  • 8. Game Design Document (GDD)  The lead designer is the principle author of all the game design document.  To a programmer and artist, it is the instructions for implementation.  However, design documentation should be a team effort, because almost everyone on the team plays games and can make great contributions to the design.
  • 9. Game Design Document (GDD) The GDD addresses:  User Interface  Control Scheme  Game Mechanics  Storyline  etc.
  • 10. Game Design Document (GDD) Game features may be ranked as follows:  Tier One: The core features of the game  Tier Two: Adds value to the core features  Tier Three: Designates what would be nice to have inside the game
  • 11. Game Design Document (GDD) Tips for a good GDD:  Describe Not Just the Body, but the Soul: Take time to describe the feel that the game should have, the purpose behind each element, the experience each user will have, and any other aspects of the game's soul you can envision and describe.  Make it Readable: Plenty of white space, bold headers, short lines of text, direct the eye towards important material.  Prioritize: Categorize your game elements as: indispensable, important, if possible, rejected
  • 12. Game Design Document (GDD) More tips for a good GDD:  Get Into The Details: A document without details is useless. Generalities can be interpreted by anybody in any way that they like.  Some Things Must Be Demonstrated: Sometimes a few rough sketches are enough, but if the idea is truly important to your concept of the project, you may want to make a rough animation yourself.  Not Just "What" But "How": In the real world, the "how" determines the "what." For example, suppose you've opted for claymation. Work out the process of how the images will be captured and document everything. What material and what color should the backdrop be? What camera should be used and why? What are the steps for processing the captured frames?
  • 13. Game Design Document (GDD) Even more tips for a good GDD:  Provide Alternatives: There are too many things about game development that are unknowable at the beginning. Give the development team some options about what to do.  Give It A Life: No matter how good something looks on paper, the greatest expert still modifies things when it enters the concrete world of objective perception.  Include a Table of Contents, Headings, Page Numbering: Nobody should be able to say, "I did it that way because I couldn't find any reference to it in the document."  Deliver It in Good Condition: Do whatever you can to facilitate everyone actually reading and using the thing.
  • 14. Technical Design Document (TDD)  The TDD describes the plan for creating the game  While the GDD provides the “what”, the TDD provides the “how”  The TDD is written by the Lead Programmer, with input from the Lead Designer and Lead Artist
  • 15. Technical Design Document (TDD) Project Overview  Project Summary: The "Elevator Pitch"  Technical Summary: What engine and other software is being used to create the game; how long it will take to make it; what platforms it will run on.  Target Minimum System Requirements: What configuration the end user will need to run the game.  Technical Risks  Third Party Tools
  • 16. Technical Design Document (TDD) Hardware and Software  2D Software  3D Software  Sound Software  Programming  Development Platforms  Engineering Development  Content Development
  • 17. Technical Design Document (TDD) Evaluation  Engine  Platform Gameplay  Physics  Collisions  AI  Multiplayer
  • 18. Technical Design Document (TDD) Code Overview  Main Game Loop  Comments  Naming Conventions  Coding guidelines  Source Control  Memory Map  Video Memory  Source Memory
  • 19. Technical Design Document (TDD) File Formats  2D  3D  Audio User Interface  Menus  Controls
  • 20. Technical Design Document (TDD) Guidelines  Don't write a Victorian novel: Use bullet points and tables, and keep sentences short. The object is to describe the technical design as concisely and precisely as possible.  When documenting object-oriented designs, make sure readers can quickly find and grasp each class' name, responsibility, and relationships to other classes  A picture is worth a thousand words: use diagrams. Keep them simple and make it easy on yourself.
  • 21. Art Document The Art Document is written by the Lead Artist and addresses:  Style Guide  Asset Lists  Tool Instructions
  • 22. And Don’t Forget… Each of the three documents should have:  Game Title  Author Name  Version Number  Date Created  Date of Last Update
  • 23. The Pre-Production Problem Extra Credits: The Pre-Production Problem
  • 24. Answer these questions:  Who is on the core production team?  What 3 documents are written during preproduction and which team member is responsible for each?  What does it mean to “describe not just the body, but the soul” of a game?  What is The Pre-Production problem and what does Extra Credits recommend as the solution?