Jump to content
  • Advertisement
Sign in to follow this  
Endar

Design Doc contents

This topic is 4225 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've pretty much finished my previous project, which was a small demo, and I've started writing up a design document for my next project. Hopefully, my next project is going to be a fully-fledged puzzle game. My only problem at the moment is what exactly goes into the design document. Here's what I have so far:
  • Introduction
  • Game Play Description
  • Game Play Details (more in-depth that Description)
    • Player Input
      • Keyboard
      • Mouse
  • Player Profiles
    • High Score Handling (globally and level specific for each profile)
    • Saving
    • Loading
  • Implementation Notes
  • Development Tools/Kits to be used
    • Graphics/Rendering
    • Sound
    • GUI
    • Modeling
What else would be needed for a puzzle game?

Share this post


Link to post
Share on other sites
Advertisement
I'm not an expert on design but will give a few thoughts. If the introduction also describes the high-level concept of the game it seems enough before game play description. If the design document is (except for guiding the developers) used to "sell" the idea to someone it's a good idea to briefly catch interest by mentioning some selling points (maybe multiplayer goodness or cutting-edge physics, that would be cool BTW [grin]).

Is there a purpose or background to the game? If the background; "why" is answered then it's easier to answer to "how", so a background can be useful before game play description.

Sections for graphics (graphical style, effects that are important to game play) and audio (audio style, sound events) could be added to game play details. Even for a 'Tetris'-like game, a section that describes the graphics and sounds for specific interfaces/characters/items can be used to ensure a consistent look.

I've found it useful to have a technical specification for details that players of the game don't know about by playing it, for example code implementation details and development tools. The article Removing The 'Tech' From 'Design Document' described it well.

If you want more exact content, take a look at "Design Document templates" under Design Documents
Notice how they've also separated the concept/introduction into a separate document.

Share this post


Link to post
Share on other sites
Remember that there are various types of DDs. There is a conceptual one, a technical one, a graphical one, etc. For a puzzle game, the DD is obviously not as complicated. However, all you need to decide what goes in a DD is to answer the question "how would I explain this to someone?" That works for all types of games and all types of DDs. In fact, that is all you are doing. Explain things enough to remove ambiguity. Make it obvious what it is you want to do.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!