- Introduction
- Game Play Description
- Game Play Details (more in-depth that Description)
- Player Input
- Keyboard
- Mouse
- Player Input
- 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
Design Doc contents
Author
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:
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.
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
