[casual_games] Res: Game design document

[Juan Gril]

IMHO, I do agree about some of the points made in the PPT and the
conversations here, but I have to say some of these assume bigger teams
and/or a very straightforward development process.

I disagree for example with the approach of doing an spec in the GDD of a
feature and breaking it down into what should be supported at the different
stages of development, at least for casual game development. It's just makes
the GDD bigger and I will just spec what needs to be built in my timeline
instead.

Here is an example while making a game like Zuma:

Prototype: Frog 0.3: first pass at its graphics, implement it spitting
balls.
Alpha: Frog 0.6: tune mouse control, polished graphics, implement right
button ball swap.
Beta: Frog 0.8: fine tune control and direction, final graphics, add
particle effect when spitting ball.

All the details on how the feature looks like should go on the GDD. But as
programmers like a task list, you are better off doing these small
descriptions in your timeline and letting them use the GDD (or calling you)
as a reference.

Oh, and all our tasks end up on 0.8. It's a way of reaching 80% of what we
ideally want to do. It helps to not get stuck on perfecting just one
feature. We do have some exceptions (like 0.85, 0.9) when we have to do
final corrections.

The technical specs of the game in our case are written in the Developers
Notes section. I don't see a need to have a separate doc, at least for
casual game development.

I never seen anyone writing a GDD and completing it effectively on an early
stage in the development. It they do, they a) are geniuses, b) are making a
clone or a crappy game. GDDs get modified till beta at least, that's why
using an online tool like Google Docs is very useful.

Cheers,

Juan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://seven.pairlist.net/pipermail/casual_games/attachments/20070321/37312a4a/attachment.htm>