Prototypes vs. Design Documents

GBGames has an interesting discussion going on about the importance of prototypes and design documents in game design, specifically casual games in direct reference to the Gamasutra article with James Gwetzman of Popcap Games.

It seems that Popcap has an “extremely prototype heavy” development process.

Some of GB’s reader comments focus on this importance of prototypes in game development and feel that all they need is a prototype in order to develop their games. While this approach may work for some, I would follow this approach with caution.

I agree that prototypes are of great value, but I am also a believer of design documents.

Not necessarily designs that specifiy how every little thing is going to be built, software development is much too fluid and organic for that.

I realize that Popcap is a casual game pupblisher; but in the case of a complex RPG, it simply can’t be built without a design document. Well, at least not a good RPG. There are too many story possiblities, event points, and interactions to just make up as you go along.

Outlining the overall story arch and connecting the important events, characters, and items that populate the game is pretty much a requirement or else you run a very high risk of forgetting something, building a non-sensical story, or even a game that can’t be won.

I think where people get caught up is thinking that a design document has to be a detailed technical design. When you are a single developer on a small project, chances are you don’t need to write everything down, because you aren’t communicating it to anyone else.

I can see the advantage of detailed technical designs in a MMOG where you really need to have detailed descriptions of the network layer and protocols, how game state will be persisted, and how game assets will be managed, maintained, and updated.

Additionally, the second you have a development team of more than one person you need some sort of design document. How else do you make sure everyone is on the same page and is developing code that will work with the rest of the system?

Writing a design document doesn’t mean that you can’t be agile or proceed in an iterative manner. It is just a tool to help ensure that you don’t forget things, a tool to help facilitate communication, and a tool to jog your memory when you return to the development of a project that you haven’t touched in months.

Yes prototypes are valuable and in some cases all you may need. But, design documents are equally important. They are both simply tools in a software developer’s tool set. It would be silly to dismiss one of the most useful tools available to you.

4 thoughts on “Prototypes vs. Design Documents

Comments are closed.