🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Design Documents

Started by
6 comments, last by InsaneBoarder234 18 years, 2 months ago
I've only ever made simple beginner games such as breakout and I've never sat down and wrote a design document before making a game but I figured it would be a good idea for 4E5 seeing as this will hopefully be my first successful big game project. As I've never done one before, I'm not quite sure where to start and I've a feeling there may be other people taking part in this contest who are in the same position. Has anyone got any tips or suggestions etc for creating a game design document? Cheers!
Progress is born from the opportunity to make mistakes.

My prize winning Connect 4 AI looks one move ahead, can you beat it? @nickstadb
Advertisement
Dig around in the referece section a bit, there should be some design document templates hiding somewhere in there.
Design Documents is a good place to start looking around. Unfortunately, you'll quickly find that many of the good articles are located on Gamasutra, which annoyingly requires your Title, company, company position, mailing address and random demographics to sign up and view anything. Then, you receive too many emails from them, and realize that nobody grammar- or error- checked the dumb articles anyway.

Just for kicks, here's the definition from the GDNet dictionary:
Quote: A document that the designer creates which contains everything that a game should include. Sometimes referred to as a "design bible", this document should list every piece of art, sound, music, character, all the back story and plot that will be in the game. Basically, if the game is going to have it, it should be thoroughly documented in the design document so that the entire development team understands exactly what needs to be done and has a common point of reference.
gsgraham.comSo, no, zebras are not causing hurricanes.
Here's what I gleaned from one of the Gamasutra links:

==========
What to Do
==========


1. Ask Questions
- You need to problem-solve everything!
- Try to find the holes in your design early by asking questions
- Focus your ideas!

2. What Are the Current Trends?
- Scan through some gaming magazines and see what's new and big
- Blur genres
- Control Over the Environment

3. What is Marketing Looking For?
- Also, what are gamers looking for?

4. What Current Tools Do We Have Access To?
- 3D authoring, 2D design, compilers, level editors, sound equipment, engines, etc
- Know how these tools will enable or limit your ideas

5. What's Good in the Music/Game World Right Now?
- Some genres lend themselves towards certain kinds of music
- Can you get good voice acting?

6. What's Been Done and How Was it Done?
- Don't tell a story that's already been told or develop a game that's already out there
- Know what's out there, what's been done, and how high the bar has been set (in this case, look at some previous 4E entires, too)

===========================
The Working Design Document
===========================


The design doc acts as a full script. It keeps everyone - or just you - on the same page, and gives everyone a firm idea of what's supposed to happen.

The type of game document that you should write (compared to the summary that gets lost in management's trash bin) is the kind that gives the Yellow Pages a run for its money. "Every imaginable detail" should be included!

Due to problems, problem-solving, circumstance, limitations, or talent, you will need to make changes. Keep track of them!

The Feature-Oriented Design Document
(This section was completely incongruous with the rest of the article, but I'll try to summarize anyway)

In the author's case, their doc started as a basic method of keeping their six workers up to date. It was fluid and living, and was able to survive the development of three different games. MS Word's version control allowed members to edit the document cleanly, and one at a time.

The doc had major headings like AI, game modes, and others; each of these sections explained features and functions. These sections were written in a numbered template with an inclusive table of contents.

The entire document was linked to the technical design document, as well (which was not described in the article).

============
The Template
============


0. TABLE OF CONTENTS
- Every major heading should be included here

1. FEATURE HEADING
- Describe and number the feature

1.1 Contact and "See Also" Information
- Who designed the feature, their contact information, and directions to other relevant sections

1.2 Goals
- A bullet list of goals and problems you may encounter, with solutions

1.3 Implementation
- How will the feature be used in the game?
- Include formula, diagrams or flowcharts that show the feature in question

1.4 Impact
- How will this feature impact the status quo (of the game, or of the industry)?

1.5 - 1.8 Tasks and Questions for:
Designers
Programmers
Artists (2D, Modelers, Motion, Textures, etc)
Sounds
- There must be a Tasks and Questions section for each arm of the team, so this part of the template is flexible, and should be customized by you. The purpose is to allow the design team to skip straight to their relevant section and ask better questions.

==============
In Conclusion
=============


If you edit or remove a feature, keep track of it in your design doc. Don't simply delete the section for the feature - you might just forget why you ever removed it.

Get the design doc online if you're in a team setting. Be able to send hyperlinks to relevant pages of the document through email when changes occur:

"Feature 7 (Wallabee Movement) has changed - Skip to relevant page"
gsgraham.comSo, no, zebras are not causing hurricanes.
Quote: Original post by Avatar God
Design Documents is a good place to start looking around. Unfortunately, you'll quickly find that many of the good articles are located on Gamasutra, which annoyingly requires your Title, company, company position, mailing address and random demographics to sign up and view anything. Then, you receive too many emails from them, and realize that nobody grammar- or error- checked the dumb articles anyway.

I haven't noticed that - did you leave one of the mailing list checkboxes ticked when you registered? Personally, I find the gamasutra articles to generally be good quality.

John B
The best thing about the internet is the way people with no experience or qualifications can pretend to be completely superior to other people who have no experience or qualifications.
One of the GameDev articles provides much of what that Gamasutra link was missing:

Tom Sloper's Format for Game Design Specifications
He suggests more emphasis on the game description, objectives and gameplay. In addition, he lists characters, licensing, the world, controls, graphics, sound and music.
Also worth looking through.

Chris Taylor's design doc template is also good, but would need to be fleshed out into much, much greater detail. The problem with it is that it doesn't include many things that need to be included. The Gamasutra template is excellent so long as you remember to include all your features (UI, cameras, etc).

The Design Doc Templates files are broken into several DOC files. The first is an overview of the game concept, and should be included in any design document you make. The game proposal file probably isn't necessary here (for the contests - you've already decided to make the game!). The technical design file is much too broad, though it may remind you of a few things. However, the game design file is good. The other doc templates seem to have forgotten the stories and characters that your games are supposed to be showing off. Levels, plot, and character development should be included here.

Lastly, GDev's link to Monolith Production's Claw Design Document is well done, though it does not include much of the technical work. For a function-based doc, though, it's excellent and worth more than a few glances. It's fairly specific in some places, and is sure to put in placeholder headings even if the details aren't ready yet.

I would suggest reading the Gamasutra articles if you decide to register an account - there's a good bit to learn from them.

[Edited by - Avatar God on June 4, 2006 5:43:19 PM]
gsgraham.comSo, no, zebras are not causing hurricanes.
Quote: Original post by JohnBSmall
Quote: Original post by Avatar God
Design Documents is a good place to start looking around. Unfortunately, you'll quickly find that many of the good articles are located on Gamasutra, which annoyingly requires your Title, company, company position, mailing address and random demographics to sign up and view anything. Then, you receive too many emails from them, and realize that nobody grammar- or error- checked the dumb articles anyway.

I haven't noticed that - did you leave one of the mailing list checkboxes ticked when you registered? Personally, I find the gamasutra articles to generally be good quality.

John B
No, I made sure they were unchecked (thankfully, the default was actually for them to all be unchecked!), but I've already received a few confirmation emails (just your standard automatic ones) about my account, the newsletters, etc. The articles are good! Don't get me wrong; I just wish someone had taken the time to edit them first.
gsgraham.comSo, no, zebras are not causing hurricanes.
Thanks a lot all, I'm sure I have enough to get started now, thanks!
Progress is born from the opportunity to make mistakes.

My prize winning Connect 4 AI looks one move ahead, can you beat it? @nickstadb

This topic is closed to new replies.

Advertisement