How many casual games use design docs?

There are many ways. Jeweltopia was the child of an evolutionary development process, for example. You can read more here.

 

Just use whatever suits you best. The most important thing is to test your prototypes so you can change them early. I would say you have to think carefully of what you want first (write about it, read it, think about it, change it, read it, change it, until you are comfortable with those ideas), before programming, and then test if it works well and change accordingly, so the doc will act as a guide, but will not the final word, the final word its on the testing.

 

I think design docs have their place in development. Typically the amount of doc and detail you need varies with the number of people you have working together. Imagine a big project with 4 artists or developers all trying to collaborate towards a final product with no documentation to keep a consistent vision. It's inefficient and it leads to rework and confusion. I also think it varies a little with the kind of game your making. A complex strategy game might benefit from some rules worked out on paper. I would suggest that a design doc for a small indie game where it's just a single developer working from home is not particularly useful in most cases. That person can probably just get away with simple todo lists. For my part, I think Docs come into play when there are teams of people or collaborations between companies.

 

At the Austin Games Conference, there was a presentation on design. A designer at PopCap contrasted the design docs he used at a more traditional game company with the docs he uses now. He compared the traditional game doc to a phone book, while the casual game doc was just 2-3 pages. Made the point that casual games tend to evolve much more radically over the course of development. So for some, a simple two sheet summary of how they envision the game is enough. I am sure you could certainly go the other route too, but I would suspect most people fall somewhere in the middle.

 

This sounds about right from my experience. I could spend days writing a novel sized design doc or instead, could stay flexible and write an overview with some sketches, bullet points etc and then hit the code and get that core functionality playable as a prototype first. I do the latter.

I have found that I go through so many changes/iterations/prototypes to "capture" that original vision (inspiration) that any written document quickly becomes outdated. I will however re-write a new focussed overview with a bit more detail when i'm confident that i'm on the right path and the prototype is working as intended (and feels fun even without all the bells and whistles).

Of course I work on my own so this is ideal, the largest part of the design overview is "in my head" and It's always there (every night while I try to get to sleep in fact) so it's always being refined in my head. I normally wake up with a fresh perspective and no need to re-read some convoluted document to tell me where i'm going.

In teams of course, I suppose it's essential. "real" game design docs I saw when I worked in the retail industry were sprawling and quite uninspiring but essential for co-ordinating a large team.