« All hail the monstorus nerd - Choosing an engine »

Building a good design document.

4 May 2007

For those of you have who’ve seen some of my post, you know that I’ve been writing a little about building my own RPG. Before I go any further, I’d like to address one of the absolute most important things in any software project; the design document.

For the uninitiated, a design document is your project’s bible. It is where all of the high level decisions and features are documented. It should be the basis for all scheduling and planning. I’ll say it again another way, without a design document, any schedule or, talk of a percentage of tasks that are complete, is purely fiction. Having stated that about as strongly and politely as I know how, lets look at what I think a design document should be.

A design document contains every screen, every item, every piece of data, and every feature that will be in your product. It provides these items in detail enough for you to estimate how much time it will take to produce them. However, be cautious that it does not go to deep into detail that it hinders the actual development process.

Once your design document is finished, you can begin to plan your work at a high level and start scheduling tasks. You do this by taking all of the features in the document and breaking them down into task. You can then break these high level items down even further until you can look the time it take to accomplish the task in terms of weeks or months. Additionally, the design document is useful as it eliminates unnecessary discussions about requirements. When there is such a moment, all parties should consult the design document and move forward based on it.

At gamasutra, this article is a great example of a well written design document.

So, I hope you can see why I think that a design document is absolutely vital to the success of a software project. A well thought out and written design document eliminates developer time wasted on feature creep, it servers as a starting point for all scheduling activities and, it provides the big picture of your project.

For those reading that are interested in such things, drop me a note about what you think.


4 Responses to ' Building a good design document. '

Subscribe to comments with RSS or TrackBack to ' Building a good design document. '.

  1. Joan Planas said,

    on May 6th, 2007 at 2:08 am

    I agree totally with you. I started to develop a game with a friend (as I post in my blog) and the first thing we learned was that. Gdd is a must for every game project you face and will help you keep focused on the real work.

    Nice article and very nice blog.

  2. Chris Austin said,

    on May 6th, 2007 at 1:32 pm

    Thanks Joan,

    I appreciate the comments. I’m working on the GDD right now, and I am trying to be as detailed as possible. What I am realizing doing this myself is that I will need to be cautious about the scope of the game if I want to release it anytime this year :)

    Once I have something reasonable I’ll post portions of it here on the site. I don’t want to post everything since I want people to play the game and give some honest feedback.

    Thanks again.

    Chris


  3. on May 6th, 2007 at 2:17 pm

    […] in my little series about planning the RPG that I want to build. Before I got a bit off track with last post about the importance of a game design document (GDD) I was delving into some of the choices about game engines. In short I’ve decided to use and […]

  4. Stasigr said,

    on October 29th, 2007 at 8:08 am

    Hello, very nice site, keep up good job!
    Admin good, very good.

Leave a reply