[arg_discuss] How long is your dev cycle?

[Dan Carver]

Well the Beast wasn't exactly grass roots, but it did have a very short fuse
for a project of its size.  We essentially had 2 1/2 months to go from
design to release of the initial episode. This was dictated by a hard
deadline (the release of the movie posters) rather than any scheduling on
our part.  As it happened we got some extra development and debugging time
(essentially 4 weekly updates) because no one found it for a month!

Personally I'm big on pre-production and I remember thinking that I would
have preferred 6 months to 9 months instead of the 2 1/2 that we had and a
year wouldn't have been out of line if there were a lot of dependencies and
programming. This of course assumes commercial development and substantial
team and content sizes.

The very nature of ARGs (at least as they've been mostly implemented to
date) allows them a shorter development cycle (up front) than traditional
games. This is because the game essentially releases with partial content,
then adds the remaining content over the course of the game.  Note that this
does not have to be this way, you could in theory build all of the game
before releasing it and I suspect that development times would start to look
more like traditional games. There is a down-side to releasing without all
your content in place, one that I think we've seen a lot of in ARGs: There
is a greater potential for failure after the initial content is used up.

On the Beast we probably had a week to do the initial design (which was
subsequently added to and modified over the rest of the product cycle). Add
another week or two to ramp up resources and assets to the point where we
could start serious production. From there on we essentially did all our
preproduction on the fly (i.e. planning out future updates while creating
the current ones). Silly us, we thought we had put together a couple of
months worth of content.  Imagine our shock when the players tore through it
in a couple of days instead.

Microsoft's resources did allow us to ramp up fairly quickly as did the fact
that the core team were all seasoned game-development veterans or the
equivalent in their fields. There were learning curves to be sure, but the
experience helped keep them short ones. Having a budget helped as well,
although it was on the small side and limited what we did in many ways (some
folks would have thought it was a huge budget, but when you have to pay
people real wages and pay going rates for web development services it goes
real fast).  We ended up scrounging for free or cheap stuff as much as any
grass roots effort would. But having the money did allow us to quickly
engage other professionals and services that could hit the ground running.

Another thing that speeded things up was isolating ourselves from MS and
Warner.  This kept the marketers and lawyers out of our hair and kept
interference and organizational overhead (read paperwork, meetings and dog
and pony shows) to a bare minimum.  Grass roots organizations sort of get
this for free which probably contributes to shorter development times.

However, I do have to say that we killed ourselves to get this done.
Burn-out after the project was very high, and although it was a memorable
experience it was an exhausting and physically costly one.  For this reason
alone I would be cautious about short preproduction and production times.
Too many people in the game industry in general think that every project has
to be a death march, and it just ain't so.  Especially in a grassroots
effort there's usually no reason to set a pace that's going to completely
exhaust your team (at least wait until you go live and don't have any
choice...).

So, I'd have to say preproduction and opening curtain production times are
largely governed by:

1) A pace that's reasonable given all the factors. For commercial or time
dependent projects this should be challenging but not back-breaking. For
grassroots efforts it should be short enough to keep interest and ensure
completion but not so short it stresses everyone out. I'm putting this one
first because it's usually missed, ignored or forgotten...

2) The size and run-time of the project. Pretty self-obvious, although some
folks may be tempted to skimp on preproduction of projects with long
run-times thinking they can make it up as they go along.  Frankly I think
that's an invitation to disaster.  You're better off if you have a complete
game arc at opening curtain.  Even if it gets modified or changed it forces
you to look at the entire game cycle and it makes what you do deliver more
cohesive. And if you're doing it right you go back through it and look for
places where you might need contingency plans.  You also want to prioritize
it all and then use the priorities to plan in cuts and how they'll be made
and what changes they require to the remaining bits.  You'll almost always
ending up cutting stuff and if you've preplanned the cuts it becomes just
part of the process instead of the panicky hair pulling exercise it so
frequently is. Commercial projects will usually demand more complete
preproduction than grassroots will, hence more time.

3) Dependencies.  Many projects depend on external teams to deliver, content
functionality, storage or other services.  These teams frequently have their
own schedules that are going to effect yours. The beast depended heavily on
outsourcing and delays on the external side led to delays in the game.  In
some cases these delays mean that the content just gets moved to later
updates or episodes, but if it needs to be there by the opening curtain then
your lead time is going to be effected.  Dependencies don't have to be
external.  If your team has a lot of complex programming involved then
that's going to effect your opening date as well.  Just make sure that you
examine all your dependencies and understand what their impact will be.  It
doesn't hurt to assume the worst for each and put appropriate contingency
plans in place.  Risk management goes a long ways here.  

4) Personnel. How many, dependability, availability, experience, and talent.
Up to a certain point the number of bodies you can throw at something makes
a difference at how much you can get done in a given amount of time.  My own
experience has been that more people get more done but not necessarily
faster.  Once you reach an optimal team size however, more people just slow
you down.  Finding an optimal team size and composition probably deserves
its own thread. Dependability and availability are probably frequently an
issue for grassroots projects, although they obviously cause problems for
commercial efforts as well. Experience generally has a huge effect on
production times.  Obviously you want folks who have worked on an ARG
before. Anyone else is going to have a learning curve to overcome, and, at
least initially, they're going to add to preproduction/production times.
Failing that I'd want someone who's worked on games, cross media, or other
entertainment products.  It probably helps if your people have played ARGS,
but I wouldn't set a lot by it -- just being a gamer is a notoriously bad
predictor of how good a game developer they will be and I would expect the
same of ARGs. So unless you have an experienced team that has worked
together before you should probably figure in time lost to learning curves
and turnover rates. I would expect turnover rates to be particularly high in
grassroots efforts.   

5) Company and personal resources.  This can actually have a pretty
substantial effect on development times.  Especially early on when you're
trying to ramp up.  This includes hardware, software, services, staff, etc.
Having lots of resources ready to hand definitely helped the Beast ramp up
fast.

6) Oversight.  By oversight I mean entities that the project must report to
and who can make decisions that affect it.  As stated before, the Beast had
a lot of potential oversight:  There were at least 3 entities involved:
Microsoft, Warner Brothers, and Spielberg and company. In addition each of
these had their own management, legal departments, marketing departments,
and their own agendas. It was a real potential nightmare and Jordan Weisman
essentially told the parties involved that there was no way the project
would happen in time, unless it was kept small (relatively) and under the
radar.  Amazingly enough everyone agreed (Jordan could sell roller-skates to
velociraptors) and each entity limited its oversight to the minimum number
of people. Imagine how long development would have taken if we had to run
everything by everyone's management, marketing and legal staffs? We did have
to run some stuff through MS legal and make sure the content didn't violate
the IP, but that was all minimal. So the less oversight you have the greater
the potential time savings.  Again, grassroots efforts score very high here.
Note that I'm not advocating that you always run your projects in the dark
(you can get in a lot of trouble that way...), but just that you have to
take oversight into account when estimating preproduction and development
times.

7) Budget. In a commercial effort budget is, of course, a necessity and can
make a substantial difference in how much you can accomplish and, to a
lesser extent, how fast. However, the larger the budget, the larger the
oversight so it can be a two-edged sword.  Large budgets can also promote
inefficiencies, extending preproduction and in some cases dooming projects
to a sort of perpetual production until they eventually run out of money and
someone finally has the guts to kill them.  Overall I would say that budget
can improve the amount of stuff you can get done in a limited amount of time
but you shouldn't count on it to shorten the process.  Raising/funding a
project can definitely lengthen preproduction/production cycles in that they
can delay even the start or completion of process. Grassroots projects have
a different sort of budget problem which is "can we get any at all" and
since the answer is usually "NO" or "VERY LITTLE" or "WHAT HAS IT GOTS IN
ITS POCKETS" I would expect budget to have minimal impact on their
preproduction/production rates.

8) Pad. Every project manager worth his salt pads his schedule (.i.e.
includes extra time to account for the unexpected: sickness, crashes,
turnover, disasters of all ilk, etc).  I've seen this vary from 5% to 30%.
Personally 5% is too low.  10% is probably minimal and if we're being
realistic we're probably talking 20%.  If the pad doesn't get used then
you're ahead of the game, but the pad almost always gets used.  This is more
of concern to commercial projects than grassroots projects, but if you've
got to answer to someone or something for your opening date or you've got a
hard date then pad becomes critical.  Without it you're assuming that
everything will go absolutely right, that you've thought of everything. A
lot of teams throw away the pad when they're running behind because of bad
scheduling or if their schedule indicates they'll have to make cuts.  They
then use the entire remaining pad to schedule completion of late features or
content. This almost always comes back to haunt them, as the things that the
pad was designed for happen anyway.  The right way to do it is to cut
features and content until the schedule fits including the pad. It's either
that or slip your date (which you will, one way or another if you keep your
full design). The caveat to this is that you can probably spend pad left
over from previous milestones (if you include pad in whatever you use it
for). If you consistently end up with lots of pad left over you should
probably revise your padding and schedule downward.  Large grassroots
efforts with hard dates should probably use a larger pad to account for high
turnover. It should probably be noted that padding is a dark and arcane art.

I'm sure I've missed something, but I seem to be blathering on a bit long so
I'll try and wind this up.  Essentially I think that there are so many
factors that go into this kind of estimate that preproduction and
development times are going to vary wildly, even with projects of similar
scope.  Ball park figures and such can be useful for general discussion
purposes but no one should be surprised or concerned if their own experience
varies wildly from idealized numbers.

Preproduction is critical, and if at all possible, should never be skimped
on.  You get better, play, stories, interfaces, consistency, content, and
estimates when you spend more time in preproduction.  If you do it right
you're better prepared for cuts and catastrophes and the fix for a problem
discovered in preproduction is a fraction the cost of one discovered late in
the development cycle.  OK, I'll stop preaching to the choir now.

--Dan C.

-----Original Message-----
From: arg_discuss-bounces at igda.org [mailto:arg_discuss-bounces at igda.org] On
Behalf Of Andrea Phillips
Sent: Wednesday, December 21, 2005 5:32 AM
To: Discussion list of the IGDA ARG SIG
Subject: [arg_discuss] How long is your dev cycle?

Here's something I'm really curious about. I know the development/pre- 
production cycle for existing ARGs has varied wildly from Heist's six  
weeks (was it?) to Perplex City at over a year. How long have you  
guys planned before launching, and what do you think is an ideal  
length for your preproduction phase?

It would be especially interesting to hear from grassroots teams who  
are presumably working with a different set of time constraints.

--
Andrea Phillips
http://www.perplexcity.com
http://www.deusexmachinatio.com


_______________________________________________
ARG_Discuss mailing list
ARG_Discuss at igda.org
http://five.pairlist.net/mailman/listinfo/arg_discuss