A design document is essentially just that: documentation of every mechanic, every idea, every small tidbit of information that you can think of that is relevant to the game you want to make. Think of it as a movie script that has all of the camera direction and scenery included in the text.
Why do this? For a few key reasons:
-To lay everything out in an organized fashion to make sure your designs work well together.
-To show other people for feedback on ideas.
-To document everything. Nothing is useful if it's only in your own head. Programmers, artists and musicians need direction, and it's much easier to point to an already written set of criteria as a guideline than to make it up on the spot.
When I first decided to start work on Dead Gear, I quickly wrote up a 40+ page document detailing game synopsis, weapon mechanics, locations, etc. I then went and bugged all of my friends to read it.
In a way, the document was sort of a game pitch more than anything. Of the few willing to read the monstrosity, I was able to take some feedback and further polish the document.
Ideally, one should have a completely finished design document before programming even begins. Of course, in larger scale projects, this may prove unfeasible and extremely time-consuming. What designers should try to do is write a skeleton of a design document; write the beginning, middle and end. Know exactly what your goals for the project are, so you don't fall into the trap of not knowing when to stop adding to the document, and risk bloating the project with tons of cool, but unnecessary features or ideas. A designer needs to set a reasonable limit for the project.
Lots of amateur developers often disregard the design document, and jump straight into developing a game. While you could design that way, it's a pretty sloppy and difficult way to get everyone on the same page. Documentation is key!
-Kirb
No comments:
Post a Comment