Skip to navigation
Well, that’s a pretty straightforward question.
Yes, I do use GDDs. Not always as detailed as Chris Taylor’s template. My GDDs are a mix of template and todo-lists
Like Jake: Yes for bigger things. No for small tests and such.
For work Yes, and for anything big. For small fun stuff, no.
I’m in the “yes and no” camp. Design documents can be very useful in some situations, such as when the game is really large or when you need to coordinate between a lot of people. Experienced people can also use a game design document as a guide to fleshing out a game.
But, I don’t use design documents as a monolithic pronouncement of what is set in stone. I think anyone who tries to do that is in for a world of hurt. But, enough information to provide some structure is invaluable.
Absolutely yes. I’ve worked on games both with and without design docs. The latter result in level review meetings where something happens, and someone asks, “Well, wait, what’s SUPPOSED to happen here?” and NO ONE KNOWS.
I remember writing it some months ago. Don’t ask me where it is today. The new level editor kicked me out of track.
I’m sure, the doc is somewhere in my bedroom… have to clean up… :(
Yes, definitely. While going on a limb is the “easy” way to do it, without the organization and streamline qualities a design document offers, things can get off track quite rapidly.
We generally document critical things (EG: how the user will interact with the world editor or something) but not everything, there is a point where it just seems like you’re wasting time documenting everything. We do however document all of our code (Using Doxygen) and have our code server set up to be able to automate the generation of this code. (Only semi-related but whatevs)
I always start with a design document but I usually end up abandoning it in favor of a to-do list that encompasses everything I need to get done.
Design documents are a good start – but they’re a pain to update once major concepts change after some prototyping. A simple list is a lot more flexible, but I can see something that not working for bigger teams.
For the publisher we use big, pretty, not very precise and not so useful for development documents.
For internal use we utilize few concrete, precise and more low level documents. Some of them may end up into the publisher’s docs at some point.
@Andy: quite interesting. :) Do you find the doc interesting? I thought that I could make a poll, but wanted to see what kind of answers I get..
Russell: what an interesting statement. Why you use games at the studio, but why not for other games? Are your own games smaller or less complex… or what’s the reason for not using docs on your side games?
Yes and no. Yes on games we make at the studio, and no for games I make on the side.
We always use 1 to 5 pages GDDs, no more than that.
Yes (a pretty straightforward answer)
Yes, of course.
I can’t even imagine making a complex game without using a design document.
Strangely enough I downloaded the “Chris Taylor Design Doc” yesterday and have been working on one for a new project.
Mainly because of that contest you posted about yesterday.
I’m surprised you’ve not done a poll on this?
Yes. We’re working on an point’n’click adventure game. We can’t make it without a design doc.