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.
Comments
4 responses to “Prototypes vs. Design Documents”
I believe prototypes aren’t meant to replace design documents so much as isolate what makes a game fun. Once you figure out the integral elements of the gameplay, a design document can help you figure out the details.
Simple games might not need more than successful prototyping, but obviously larger games with larger teams need some document to tell people what they should be building. Otherwise, it is possible that someone could change an FPS into a top-down shooter, and no one will be able to show proof that it would be wrong.
Absolutely!
Unfortunetaly, I see more and more developers (not just for games) are eschewing the design document under the guise of “agile” development.
Obviously you need to know where you’re going in doing say an rpg or adventure game. But then in that you need an idea of where you’re heading, story wise. But the game itself can just be fleshed out and iteravely developed. And who says it’s wrong for an fps to turn into a top down. If that is what makes it fun, then it’s not wrong, and isn’t that what you’re trying to figure out anyways?
Keith
Fun is definitely the target.
I’m not at all saying that prototypes aren’t valuable. I’m simply saying that relying strictly on a prototype and not commiting your ideas to a design document is dangerous practice. Especially when working on larger more complex projects. At least this is my experience.