1. Anatomy of a Design Doc parts 1 and 2 Why Design Docs Matter
Readings 9
Anatomy of a Design Doc parts 1 and 2
Why Design Docs Matter

2. Guidelines for game concept and proposal
The purpose of design documentation is to express the vision for the game, describe the contents, and present a plan for implementation
Design documents come in stages that follow the steps in the development process
Documentation does not remove the need for design meetings

3. Guidelines for game concept and proposal
A game-concept document expresses the core idea of the game. It's a one- to two-page document that's necessarily brief and simple in order to encourage a flow of ideas
A game concept should include the following features:
Introduction
Background (optional)
Description
Key features
Genre
Platform(s)
Concept art (optional)

4. Guidelines for game concept and proposal
Introduction: The introduction to your game concept contains what are probably the most important words in the document.
In one sentence, try to describe the game in an excited manner. Include the title, genre, direction, setting, edge, platform
Breaking the introduction up into several sentences for the sake of clarity is acceptable.

5. Guidelines for game concept and proposal
Background (optional): The background section of your game concept simply expands upon other products, projects, licenses, or other properties that may be mentioned in the introduction; so it's optional

6. Guidelines for game concept and proposal
Description: In a few paragraphs or a page, describe the game to the readers as if they are the players
Make this section an exciting narrative of the player's experience.
Encompass all the key elements that define the core game play by describing exactly what the player does and sees.
Avoid specifics such as mouse-clicks and keystrokes

7. Guidelines for game concept and proposal
Key features: Your game concept's key features section is a bullet point list of items that will set this game apart from others
Provide goals to which the subsequent documentation and implementation should aspire.
It's a summary of the features alluded to in the description

8. Guidelines for game concept and proposal
Genre: define the game genre and flavor.
Use existing games' classifications from magazines and awards as a guide

9. Guidelines for game concept and proposal
Platform(s):
list the target platform(s).
If concept is applicable to multiple platforms indicate which platform is preferred or initial.
If you intend multiplayer support on the Internet, indicate that as well

10. Guidelines for game concept and proposal
Concept art (optional): A little bit of art helps sell the idea and puts the readers in the right frame of mind.
Use art to convey unique or complex ideas.
Screen mock-ups help to express your vision

11. Guidelines for game concept and proposal
common mistakes
concept is inapplicable to the company's current plans
concept outside the realm of possibility
document lacks content
game isn't fun
The game-concept document employs poor language and grammar
The designer gives up. Don't give up submitting ideas

12. Guidelines for game concept and proposal
A game proposal is a formal project proposal used to secure funding and resources for a game development project
The proposal is an expansion upon the game concept. Writing a proposal may involve gathering feedback and information from other departments
The programming staff should perform an initial technical evaluation of the concept. They should comment on the technical feasibility

13. Guidelines for game concept and proposal
The game proposal includes the following features:
Revised game concept
Market analysis
Technical analysis
Legal analysis (if applicable)
Cost and revenue projections
Art

14. Guidelines for game concept and proposal
Market analysis
The target market is defined by the genre and the platform. Identify specific titles that epitomize this market. The most successful of these titles will indicate the viability and size of the market
List the top performers in the market. Express their sales numbers in terms of units
Identify the selling features of these top performers. Compare and contrast them to the key features described in the concept document. Try to provide some specifics

15. Guidelines for game concept and proposal
Technical analysis
Identify the features in the design that seem experimental such as untried or unproven technologies, techniques, perspectives, or other unique ideas
Major development tasks: In a paragraph or a few bullet points, make clear the major development tasks. Use language that non-technical people can understand
List any technical risks
Alternatives are suggestions for working around some of these experimental or risky features and major development tasks

16. Guidelines for game concept and proposal
Technical analysis
List the estimated resources: employees, contractors, software, hardware
Estimated Schedule: an overall duration of the development cycle followed by milestone estimates, starting with the earliest possible start date, then alpha, beta, and gold master.

17. Guidelines for game concept and proposal
Legal analysis
If this game involves copyrights, trademarks, licensing agreements, or other contracts that could incur some fees, litigation costs, acknowledgments, or restrictions, then list them here

18. Guidelines for game concept and proposal
Cost and revenue projections
Resource cost: Resource cost is based on the estimated resources within the technical analysis. Employee costs should be based on salaries and overhead. Include any hardware or software that you purchase
Suggested Retail Price (SRP) The price should be based on the price of existing games and an assessment of the overall value being built into the product and the money being spent to develop and manufacture it

19. Guidelines for game concept and proposal
Revenue projection: The revenue projection should show pessimistic, expected, and optimistic sales figures using the costs that you've already outlined and the suggested retail price.
Art: If your game concept did not include any art, then the game proposal certainly should. The art should be created by skilled artists

20. Common Proposal mistakes
The analysis is based on magic numbers
The proposal is boring
The proposal fails to anticipate common-sense issues and concerns
The proposal writer is overly sensitive to criticism
The proposal writer is inflexible to changes to the game

21. Design Doc part 2 pg. 6
Documentation Milestones and the Development Schedule
Conceptual Phase
Document: Game Concept
Document: Game Proposal
Design Phase
Document: Functional Specification
Document: Technical Specification
Documents: Tool Specifications (if applicable)
Production Phase
Production Schedule
Technology and Art Demo
First Playable Level
Documents: Paper Level Designs (not always a deliverable)
Alpha - Functionally Complete
Testing Phase (Quality Assurance)
Beta - First Potential Code Release
Gold Master - Code Release

22. Why design documents matter
most common objections to writing design documents is that nobody reads them - - most design documents aren’t intended to be read but referred to
Prototypes are made first, why not add features and go? Prototypes are testbeds, quick and dirty assemblies, not designs. Prototypes are used mostly to test mechanics and user interfaces

23. Why design documents matter
Reason 1. Executive producers want to see something in writing. No document, no money
Reason 2: Design documents are sometimes the basis for contractual obligations
Reason 3: Design documents communicate your intentions to the rest of the team, and let them plan their tasks
Reason 4: Design documents turn generalities into particulars
Reason 5: Design documents are a record of decisions made; they create a paper trail

24. Why design documents matter
communicates, organizes, and guides the entire process. A project manager can’t create a schedule, task list and staffing allocation - and follow their progress - without knowing exactly what needs to be built, and that information must exist in written form.
Ultimately, writing (and sketching, and diagramming, and making tables and lists, and writing pseudo-code) is design.
You shirk it at your peril.