Gamasutra: The Art & Business of Making Gamesspacer
The Anatomy of a Design Document, Part 1: Documentation Guidelines for the Game Concept and Proposal

Printer-Friendly VersionPrinter-Friendly Version
View All     RSS
April 23, 2014
arrowPress Releases
April 23, 2014
PR Newswire
View All





If you enjoy reading this site, you might also want to check out these UBM TechWeb sites:


 
The Anatomy of a Design Document, Part 1: Documentation Guidelines for the Game Concept and Proposal

October 19, 1999 Article Start Previous Page 4 of 4
 

Guidelines for the Game Proposal, continued

Legal analysis (if applicable): 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. Don't bother mentioning the necessity of copyrighting the game's title or logo, as these are par for the course and likely to change anyway.

Cost and revenue projections: The cost and revenue projections can be done in conjunction with the finance and purchasing departments. This data should give the reader a rough estimate of resource costs based on the technical analysis's estimated resources.

  • Resource cost: Resource cost is based on the estimated resources within the technical analysis. Employee costs should be based on salaries and overhead, which the finance or payroll department should provide. You can list these as average by title or level. Any hardware or software that you purchase should be listed as well, even if it will ultimately be shared by other projects or folded into the overhead budget. Use a table or embedded spreadsheet as it is easier to read and edit. For example:

Employee
Cost Per Month
Work Months
Total
2D Artists
$4,000
35
$140,000
Lead Artist
7,000
14
98,000
Level Designers
3,000
35
105,000
Total: 343,000

Hardware/Software
Price
Qty.
Total
Graphics Workstations
(PIII 500MHz/256MB/9GB/Voodoo2)
$4,200
3
$12,600
3D Studio Max Extended Site License (5-user pack)
3,000
1
3,000
Total: 15,600

  • Additional costs (if any): This section is an assessment of additional costs incurred from licensing, contracting, out-source testing, and so on.
  • Suggested Retail Price (SRP): You should recommend a target retail price before your game goes in the bargain bin - pray that it does not. 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. Of course, your distributors will likely push for a lower sticker price or work some deals to use your game in a promotion that will cut the price even further, but that will all be ironed out later. Keep in mind that the higher the sticker price, the lower your sales, especially in a competitive genre where there's not as much demand as supply.
  • 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. Other factors, such as marketing dollars and company overhead, should be left out of the picture as these are subject to change; if a minimum marketing budget is known, however, then you should certainly factor it in. Often the revenue projection is best represented with a pie chart or a bar chart. Be sure to indicate with an additional wedge or bar the costs incurred from any of the risks described in the technical evaluation and show totals with and without the risk assessment.

Art: If your game concept did not include any art, then the game proposal certainly should. The art should be created by skilled artists. Dispose of or replace any of the art in the concept document that was not created by the artists. The art will set the tone for the game. Assume that the readers may only look at the art to evaluate the proposal, so be sure that it expresses the feel and purpose of the game. Include a number of character, unit, building, and weapon sketches, in both color and black and white. Action shots are great. Include a GUI mock-up if your game is a cockpit simulation. Be sure to have good cover art. Paste some of the art into the pages of the documents, as it helps get your points across and makes the documents look impressive.

Presentation: The whole proposal, including the revised concept document, should be printed on sturdy stock and bound in a fancy report binder along with copies of the art. This document is to be presented to business people - you know, those people who walk around your office wearing fine suits to contrast with the t-shirts and cut-offs that you normally wear. Don't forget that you're proposing a major investment, so make the proposal look good and dress well if you're going to handle the presentation. Preparing a slide show in a program such as Microsoft Persuasion is helpful for pitching your key points and art.

Common Mistakes
Some common mistakes in preparing a game proposal include:

  • The analysis is based on magic numbers. Try to back up your numbers by listing your sources or explaining how you came up with them. Watching a producer pull some numbers from thin air and throw them in the document is almost laughable.
  • The proposal is boring. This is a selling document. Don't bore the readers. Give them facts, but make these facts exciting, concise, and convincing.
  • The proposal fails to anticipate common-sense issues and concerns. You should find out what this proposal is up against -- other proposals, competitive products, financing concerns, cost and time expectations, game prejudices, and historical mishaps. Your proposal will stand a much better chance of being approved if it addresses these issues preemptively rather than getting besieged by them during the review process.
  • The proposal writer is overly sensitive to criticism. My experience might be unique, but don't be surprised if the major promoter for your game proposal decides to play devil's advocate. Make sure your proposal is solid. Believe in it and remain confident, and you'll weather the criticism and make believers out of those reviewing your proposal.
  • The proposal writer is inflexible to changes to the game. Often during the process of gathering research or receiving criticism from the review committee, some reasonable suggestions will arise for changing or scaling back the design. Game development is a collaborative process. Take the feedback and change the design, or the game could die right there. The key word here, as tattooed on the arm of my buddy who served in the Vietnam War, is transmute. He had to transmute to stay alive and keep going, and your game idea may have to do the same.

This concludes part one of a two-part series on the anatomy of a design document. In the next part, I'll taunt you with some more colorful metaphors interspersed with some useful guidelines for creating functional and technical specifications and level-design documents. I'll also give you an overview of the document review process and how it facilitates the game development cycle.

Tim Ryan is a freelance game developer and software consultant. He has produced and designed computer games since 1992. His recent work can be seen in the PC game MechCommander: The First MechWarrior Game of Tactical Command. Please send your feedback, questions, and business inquiries to MuseOfFireProductions@yahoo.com.


Article Start Previous Page 4 of 4

Related Jobs

Treyarch / Activision
Treyarch / Activision — Santa Monica, California, United States
[04.23.14]

Associate Producer - Treyarch
Treyarch / Activision
Treyarch / Activision — Santa Monica, California, United States
[04.23.14]

Production Coordinator (temporary) - Treyarch
Vicarious Visions / Activision
Vicarious Visions / Activision — Albany, New York, United States
[04.23.14]

Software Engineer-Vicarious Visions
Sledgehammer Games / Activision
Sledgehammer Games / Activision — Foster City, California, United States
[04.23.14]

Desktop Support Technician, Temporary - Sledgehammer Games






Comments


Anupam Biswas
profile image
Thank you so much for this article Tim Ryan.

David Oso
profile image
eh?

the GDD needs to include the proposal as well as the concept design documents?

why should they both be included in the game design document?

the concept design document is used to get the publishers attention, proposal is used to pitch your idea to the publisher. So I don't know why both must be included in the GDD again.



do they have to be included?

Aaron Pierce
profile image
Why wouldn't they be? The proposal especially. It's the basis of the game, the "this is what we're going for" document. It's the backbone that says "Hey, we're off target on this feature" or "that feature is spot on" during the development process. And the concept design art is such an integral part of the games design process that I couldn't see it NOT being a part of the GDD. Now, mind you, chances are it be a supplement to the GDD (a concept design Bible of some sort), but it'd be a part of it none the less.

Danny Breen
profile image
thanks tim, this has helped me quite a bit with my coursework!

Narasimmarajan K
profile image
informative...

Celmar Galindez
profile image
Well, expressive thoughts. This is an useful tool for novice who had never been in the industry. Simple yet well-spoken.

Timothy Ryan
profile image
Wow, this is really dated. I should rewrite it. :) Thanks, Gamasutra. I'm glad this remains available.

Tynan Wyllie
profile image
That'd be great! I'm very much starting out and would love an update. Love what's here, though, and it is proving quite helpful.


none
 
Comment: