[casual_games] Res: Game design document

[Nic Cusworth]

For me the transition from pitch to GDD is pretty smooth. If you image the
situation is like this:

Pitch Doc = This is what we want to do and it's going to be cool
GDD = This how we are going to do it and make sure it's cool

It's pretty organic if you go through the 3 steps of pitch - concept - GDD.
You are just expanding on idea.

As for working with the programming (or art teams), I have never produced a
task list for a programmer. A good Lead Programmer will go through your GDD,
flagging potential issues and generating the tasks.

A lot of the time this is not a bad as it sounds. So long as your studio has
done a few titles you should have enough base tech to get going. It might be
that this new game will stretch your existing animation engine so time is
scheduled to update that.

Games get done by having a good pipeline. So long as the artists can get
their work into the game and the designers have enough access the engine to
affect the world (through scripting and editor) - the game will come
together. 

A GDD really just flags where a programming teams efforts should be focused
from day one.

GDD's (in my experience) are organic to a point. You have to sign off and
say we will make THIS game and try not to add anything else. At that points
it's a designers job to make sure the 'vision' is implemented as best as
possible. 

Obviously things do change in development but they are usually because of
the schedule. I.E. a player mechanic or level may be dropped because it will
make the project slip.

Nic.


-----Original Message-----
From: casual_games-bounces at igda.org [mailto:casual_games-bounces at igda.org]
On Behalf Of Allen R Partridge
Sent: 21 March 2007 13:28
To: IGDA Casual Games SIG Mailing List
Subject: Re: [casual_games] Res: Game design document

I'm curious about how people handle the transition between the 
conceptual / marketing aspects and the actual implementation of the 
game. IOW, to what extent do you attempt to design architecture, 
feature implementation etc. into the GDD?

Do folks generally pass a feature list on to the programming team and 
then leave that up to them, or is architecture generally designed as 
part of the GDD and the programming team then simply following the 
path laid out in the GDD?

One other thing that I would add is that for me the GDD is very much a 
living document. While it constantly challenges me to avoid feature 
creep, I have yet to see the game that didn't want some tweaking along 
the way? Do others let the game emerge in this fashion or is common 
practice to simply follow the document, regardless of the process?

--al

On Wed, 21 Mar 2007 12:57:44 -0000
  "Nic Cusworth" <info at medullacorp.com> wrote:

> Those slides are excellent, and see - doing this for 14 years and 

>still

> learning. 'User stories'. Really like that idea and will try doing 

>that in

> my next GDD.

> 

> Thanks for sending that link. They useful!

> 

> Nic.

> 

> P.S. His Power Point template is horrible :)

> 

> -----Original Message-----

>From: casual_games-bounces at igda.org 

>[mailto:casual_games-bounces at igda.org]

> On Behalf Of Adam Martin

> Sent: 21 March 2007 12:45

> To: IGDA Casual Games SIG Mailing List

> Subject: Re: [casual_games] Res: Game design document

> 

> On 20/03/07, oscar oscar <oscar.oscar.oscar at gmail.com> wrote:

>> Will NO ONE sacrifice one of their actual, completed design docs? 

>>^_^

>>

>> On 3/20/07, Jose Marin <jose_marin2 at yahoo.com.br > wrote:

>> >

>> http://www.gamasutra.com/features/20060516/carless_01.shtml

>> >

> 

> http://www.gamasutra.com/features/19991019/ryan_pfv.htm is what I

> point people to when they want to know how to get going with their

> design docs, and/or when they've submitted stuff to me that is just

> not good enough as a commercial pitch.

> 

> My general advice is to write a concept first, ideally 2-3 pages, as

> per the article, and then expand that into a small GDD (no more than

> 20-30 pages max - I prefer around 10-15 for smaller games) and

> eventually a large GDD (non-casual games generally need something

> which is > 75 pages, in some cases >> 75 pages ).

> 

> I would also strongly advise people to read the slides from Damion's

> game-design-docs talk at GDC a couple of weeks ago :

> 

> http://www.zenofdesign.com/Writing_Great_Design_Docs.ppt

> 

> As has been pointed out, just arbitrarily giving out design docs is

> not generally allowed. However, I feel strongly that it's also not

> that useful, if you have a rough template (like in Ryan's article):

> IME if you cannot follow a basic standard template and organize your

> own thoughts well enough to create your own sets of sub-headings

> appropriate to each major heading, then you probably aren't ready to

> write a design doc yet. Either you need to think more about your 

>game,

> or learn generally how to compose your ideas into clearer forms.

> 

> YMMV, of course.

> 

> Adam

> _______________________________________________

> Casual_Games mailing list

> Casual_Games at igda.org

> http://www.igda.org/casual-subscribe

> Archive: http://www.igda.org/casual-subscribe

> Archive Search:

> http://www.google.com/coop/cse?cx=010373383720242846960%3Az3tdwggxil8

> List FAQ:

> http://www.igda.org/wiki/index.php/Casual_Games_SIG/Casual_Games_List_FAQ

> 

> _______________________________________________

> Casual_Games mailing list

> Casual_Games at igda.org

> http://www.igda.org/casual-subscribe

> Archive: http://www.igda.org/casual-subscribe

> Archive Search: 

>http://www.google.com/coop/cse?cx=010373383720242846960%3Az3tdwggxil8

> List FAQ: 

>http://www.igda.org/wiki/index.php/Casual_Games_SIG/Casual_Games_List_FAQ


_______________________________________________
Casual_Games mailing list
Casual_Games at igda.org
http://www.igda.org/casual-subscribe
Archive: http://www.igda.org/casual-subscribe
Archive Search:
http://www.google.com/coop/cse?cx=010373383720242846960%3Az3tdwggxil8
List FAQ:
http://www.igda.org/wiki/index.php/Casual_Games_SIG/Casual_Games_List_FAQ