How detailed and/or complete is/are your game design documents before starting a project?

Question

What I'm wondering is how complete your design documents typically are before beginning the implementation of a project? I'm talking about medium to very small projects with a very small team here where even fully fleshed out the entire document may only be a few dozen pages.

Do you start with a rough framework and start fleshing out the details at the same time implementation is starting?

Do you completely flesh out every section completely before any implementation is even started? If so, what percentage change have you seen after implementation starts?

If you have experience with one of the two scenarios I outlined, I'd love to hear your opinion on what issues going that particular route caused and what obstacles you feel it helped you avoid.

Answer 1

If the game idea is heavily based on some unusual gameplay concept, I prototype that right away from scratch, using a previous project as a template. 95% of the time this leads to realizing that it's not as fun as I imagined, and to make it fun would require more resources than it's worth.

If I'm working on another project in the meantime, I take my time, make a doodle to get an idea of what the prototype should look like (try not to get distracted by sketch art). Then I share it with friends, partly to see if they have any input, but mostly to make myself think of things that are not obvious right away (there are always tonnes of things, even for the smartest people thinking out the simplest ideas). After a couple hours like this, I'll jot down some key concepts that have to be in the architecture, literally ~20 words. Then I can build a prototype when I have time.

Answer 2

Currently my game designs have been adequately detailed before starting.

I'll flesh out most of the important classes, draw some mock-ups(drawings are usually horrible), do a description of the game.

Though this is mainly due to having a long commute to work, and nothing else to do. I would rather spend less time doing this, and more time programming, as fleshing out classes that are most likely going to change seems like overkill.

Answer 3

Working on small teams across small games (one-man teams on small casual games), I moved from "heavy design" to "quick design." I find iterative development (two weeks focused on a single goal, eg. core gameplay) helps flesh out the design, and gives you something to play, which means that you won't change your mind and invalidate 90% of what you designed which looked good "on paper" but not in-game.

Having said that, I do spend most of my design time on the core gameplay and mechanics (how the main game will function), and that rarely changes much -- it gets tweaks and sometimes I pick up new ideas or drop old ideas; but nothing goes without a working prototype.

On the technical side, anything should get at least a few minutes of thought before making the code real. But, you can always refactor later.

Answer 4

Design documentation has an upkeep cost; as things change you have to go back and re-read and update any existing docs. As such, it should be a production goal to minimize the amount of maintainable documentation because that will maximize time spent actually building the game.

From there, it follows that you don't want to design everything down to the tiniest detail in advance, because you know full well that half of it will change, and then you'll be dealing with a lot of wasted time. Do the minimum design needed to start making the core game. When that's done, iterate as needed, then repeat the process for each new feature.