[casual_games] Game Design Document Process (tangent from "Gamedesign document")

[Nic Cusworth]

Some great stuff in there Tim and shows theirs no one approach to design and
development. It's good to see someone process through a project and there's
always stuff to be learned from peoples successes and failures. 

 

So maybe I should explain a little more about why I use a 'text book
approach'. 

 

The process I described is how all of our projects get out the door. At the
moment I'm working for Ideaworks3D - a high end mobile games studio. We work
with all the big boy publishers and I just recently finished work on a Final
Fantasy project for Square Enix. We have the luxury of being a large
developer that works with the large publishers on large projects (for small
devices) but we don't have the luxury of being lazy or undisciplined.

 

Publishers expect to see this kind of well thought out, well planned, and
accurately scheduled approach before investing in a game. They want a pitch
doc, followed by a concept doc, followed by a GDD (and LDD and TDD). Also
the process we have in place is pretty much the same as every developer I
know (and have worked for) and is what a publisher expects. We also use the
same process of license games and original IP that may not see a publisher
till it's finished.

 

However I don't think this process applies to just large teams. I used this
kind of process, if not on paper then in my head, for the casual game I'm
finishing at the moment. That's a 1 person project written in stolen hours.
Because I don't have a lot of time to spend writing the game I have to use a
stepped process similar to the more professional projects I work on.

 

My process was slightly different in the respect that I had points at which
I would drop the project if I didn't feel like it was working. Every time I
passed a cut off point successfully I created a new cut off point. The final
one being 'go beta end of March'. So with no formal planning and no
publisher I have to please (yet) the ingrained discipline of a defined
process for getting things out the door got this project to its deadline
exactly on time.

 

I've seen and worked with people who are adverse to processes like this.
Seen some incredibly creative people unravel and waste years on projects
that were going nowhere. I've been guilty of it in the past as well - but I
learnt from that bitter lesson!

 

So yes, I am (we are) disciplined. But I am (we are) also still here making
games :-)

 

Nic.

 

  _____  

From: casual_games-bounces at igda.org [mailto:casual_games-bounces at igda.org]
On Behalf Of Tim Turner
Sent: 25 March 2007 00:20
To: 'IGDA Casual Games SIG Mailing List'
Subject: [casual_games] Game Design Document Process (tangent from
"Gamedesign document")

 

Once upon a time I was reading the JOBS SECTION IN THE NEWSPAPER and FAXING
MY RESUME (tells you how long ago this happened!) to companies when I found
a job that required JCL.  I had no idea what this was at the time but I sent
my resume anyway.  (FYI this is a computer language that is a little closer
to cave painting than HTML)  Anyway, they scheduled me for an interview so I
bought a book on JCL and read it the night before I went in.  When they
asked me how much JCL I knew I said, "I know enough to pretend I know a
lot."  And I got the job.

 

A lot of the game design document posts remind me of that time in my career.

I was just starting to feel like I knew some shit and I could provide
something kinda like the right answer for most questions.  However, those
answers were very text book and often not representative of what really
happens.

 

I enjoyed Nic's post where he mentions how he would be fired if he turned in
one of the design docs that were referenced earlier in the thread.  His
advice was very text book though and throughout my reading I kept thinking,
"Where the hell does this guy work that they use this process?"  Not that
it's bad just...  I've never seen it actually (REALLY TRULY ACTUALLY) done
this way.  There is a saying, "No plan survives contact with the enemy."

Nic's life sounds like our plans before we reach enemy.  Maybe they just
have a great discipline.

 

Somebody (Adam?) said something about how if you need to ask what sections
to put in your design doc you don't know enough to write one.  I don't quite
agree.  I think it's more like...  If you are asking what sections to use in
your design document you don't know enough to ask the right questions.

Whoever is asking is at the "I've got this great idea" stage and wants to
get to the "I started making a game" stage and knows there is a design
document that happens in the middle so they are asking about that.  What
they really need to ask is, "after I come up with my cool idea what do I
do?"

 

I am going to specifically describe what we REALLY TRULY ACTUALLY do to get
from cool idea to making a game.  I am hoping to hear about some other
REALLY TRULY ACTUALLY processes.

 

Disclaimer:  This is not the best way or the only way to do get to your
design document.  In fact, it's more post-mortem than how-to.  This is like
a "how I built the bird feeder" article that includes things like, "measure
board, cut board and finger, staunch blood flow, realize measurement was
wrong, throw away board, get new board..."

 

Sidebar:  If you want to dig through the IGDA forum archives Chris Burke
wrote something very tongue-in-cheek a few years ago that I really enjoyed
where he said something like, "Step 1.  Think of a game idea- make sure it's
really good!"

 

For perspective's sake let me explain who I am and how my company is setup.

Intergalactic Crime Prevention Unit (ICPU) has three full-time resources, a
sound guy, and several part-time contractors in engineering, art, and QA.

The full-time resources are an Art Director, an Engineer, and me.  I handle
all of the producer/project manager duties and the design.  Because of this
setup I don't need to create preliminary pitch documents to formally sell an
idea internally before resources are dedicated to it.

 

So, here is what happens at ICPU once a cool idea hits our collective
consciousness.

 

Phase One: Ideas and Whiteboards

I have an idea and kick it around in my head for a while.  I find myself
doodling gameplay mock-ups and daydreaming about how great the game might
be.  After some period of time this starts to get distracting so, naturally,
I start distracting everyone else with it.  I'll spend a week or so bringing
the idea up over and over again with my team, the guy behind the counter at
Starbucks, the 411 operator, anyone who doesn't have clear means of escape
is subject to being turned into a sounding board.

 

If the idea has legs it will get mocked-up on a bunch of whiteboards and
notebooks.

 

Phase Two: Muse and Mock-up

If I am still interested after the whiteboard phase I create an entry in our
project folder and create sub-folders for muse and concept art.  Later this
directory will have about 10 sub-folders but for now everything is either
reference, concept art, or dumped in the root like dirty clothes on the
floor when your laundry basket is full of clean stuff.

 

The goal of this phase is to semi-formally document all of the juicy
goodness oozing from the idea.  I will make rough mock-ups, copy tons of
images out of Google and Yahoo, and create one or more Word docs or
spreadsheets with lists and blurbs.

 

One exercise I often perform during the phase is to create a special case
document where I blast all of the data from previous discussions and
daydreams.  I don't let myself do any formatting, spell checking, or use
punctuation.  I go as fast as I can for as long as can ignoring redundancy
or logical flow.  I've found that as soon as I start to structure my
thoughts I slow down and become inhibited.  Ideas that have value can't
escape my brain because they don't fit into the structure properly.  Lots of
good ideas get wasted that way.

 

At the end of this phase I have a set of tangible tools that allow me to
discuss and analyze the game.

 

Phase Three:  Prototype Design

Assuming everything is still exciting we prototype the game.  We know that
we don't have a very mature understanding of our game yet.  Sometimes its
two games in one.  Sometimes it's only half a game.  At this stage God and
Will Wright are probably the only people who can tell us how the game is
going to turn out.

 

So I write a Prototype Design Doc.  This is the first honest-to-goodness
formal document.  It's a complete design document in miniature.  Everything
in this document is likely to change but the engineer needs to know what to
build.  I specify the UI (with a mock-up), the game logic (lots of pseudo
code), and I specify the flow itself.  Usually I include a section on the
goals of the game.  The exact structure of this document varies from game to
game.

 

It's important to note that I work pretty close to hand in hand with
engineering on the prototype.  They don't need to extrapolate from the
Prototype Design at all- if something isn't clear they ask me and we sort it
out on the fly.  Once the prototype is functional we iterate, tweak,
experiment, and polish as we learn about the game and what makes it fun.

 

Phase Four:  The Pitch

As a small and young company we aren't well positioned to self fund titles.

So, if our prototyping is successful and we still think the game is going to
be great we need to look for a partner to provide funding.  Now we create
the pitch documents.

 

We do not use the 3 or 4 page approach that I've heard mentioned several
times in the previous thread.  Our experience is that there are several very
different sets of circumstances that a pitch will be reviewed.  No single
tool is going to serve in every case.  So we typically create some high
quality concept art, a one-sheet, a PowerPoint presentation, and we dress up
our prototype.  Occasionally we also write some user stories.  I think our
PowerPoint is probably the equivalent of the 3 or 4 page document other
people create earlier on.

 

Phase Five:  Formal Design Documents

At the point in a project where we have a funding partner (this applies to
work-for-hire gigs too) we do a formal design phase.  Here we write a
complete design document with game flow, story, mechanics, UI maps, logic,
etc...  An art bible describing our art goals, approach, and asset lists and
a technical design document cover all aspects of the technical
implementation.

 

Almost as soon as development begins we start, like in the prototype,
learning more about the game and evolving the design.  This is why people
call the design document a living thing.  Technically it SHOULD be a tool
the designer uses and be updated on the fly...  I've never seen that really
happen so periodically through development we will audit the document and
sync it up to reflect changes we made while iterating on features and
mechanics.

 

Thanks,

T

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://seven.pairlist.net/pipermail/casual_games/attachments/20070325/c4e4b5a4/attachment.html