[MUD-Dev] Design iterations (Was: R & D)

[Brian Bilek]

"Koster, Raph" wrote:

> We're all friends here, using names is OK. :)

Hehe, ok, got it :)

>> presented an example of the process he goes through when
>> designing a game.  I instantly recognized a great many parallels
>> to 'standard' software project management theory.  I have a
>> number of books that could have been used as guides to developing
>> that design process, adapted of course to the nature of the
>> project (as it would be for any project).

> Sure, and it's not like I haven't been reading some of that stuff
> myself. :)

I assumed you had, your design concepts looked too familiar for you
not to have been reading some of the same materials.

> There is one hugely critical difference, though. Game development
> tends to be much more iterative, because "fun" isn't really
> quantifiable. So in that post, I went through the initial stage of
> design. But after that comes much throwing away of documents,
> starting over, rework, etc, that isn't nearly as prevalent in
> other areas of software development. In most large-scale software
> development, the initial requirements set forth will, if done
> correctly, highly approximate the desired end result. The same is
> not true in game design.

Great stuff!  If you don't mind elaborating, I am curious at what
stage you see the iteration take place, or is it somewhat random?
(For me a 'typical' project goes through three planning stages prior
to development, I'll call them requirements, architecture, and
detailed design) I took what you are saying above to mean that you
will actually re-define the initial requirements, perhaps more than
once, in the game design process.  You see a lot of
back-to-the-drawing board events?  What circumstances might force
this?

> There is a general disdain among many game developers for
> academically trained programmers usually because games are

>   - technically not held to the same standard as other types of
>   software

>   - on much stricter schedules than code done for academic
>   applications

> ...but I have not generally seen a similar disdain for programmers
> from the business world.

Thank you for this, it explains quite a bit.  That bit about
stricter schedules jogged my memory.  On a slight tangent - I
actually followed the development of a recently released game,
having a close friend at this particular game company (no names in
case I'm giving away a trade secret, hehe).  One of the things which
interested me is the way the development house treated 'milestones.'

In the project management processes I am familiar with, a
'milestone' would be the completion of a major deliverable or a
critical piece of code, with associated initial scheduling
estimates.  Progress is tracked against those milestones.  Due to
the nature of code development, schedules are not 'strict,' but
rather the schedule is adjusted on a regular basis to reflect the
project's true progress and updated estimates of work.  There are
goals and objectives to be shot for, but a project manager would
rather have a true understanding of where the project is at than
making developers bust their butts trying to meet arbitrary
deadlines.

However, this particular game company treated milestones as timed
events - it was crunch time before a 'milestone,' everyone worked
late and worked weekends trying to complete their bits of code, art,
or design prior to reaching the 'milestone' date.  Is this just a
word used in a different way, what I would call 'staged releases,'
with those releases being held to a deadline?  Maybe this was unique
to that company?  Or is this a difference between game companies and
other software development groups that you've seen throughout the
industry?

> There is a general disdain for managers, marketers, execs from
> other businesses because they tend not to be knowledgeable about
> game-specific management issues (particularly the need for
> iteration, but also market issues, etc), but these are simply
> areas where a good manager will learn the ropes. So I view this as
> a shortsighted position. There definitely have been many mistakes
> made by executives new to the industry who try to treat it like
> the movies or like baked goods. But they can get better at it.

When you say shortsighted above, in other words that game companies
are perhaps shortsighted when it comes to those types of positions
in holding disdain for managers & marketers from other businesses?
Or am I mis-reading?

When it comes to business types, why do you think the disdain
exists?  I understand what you are saying, but it seems to me that
adjustments have to be made when a manager moves from any industry
to any other, and each industry has its own unique problems.  I have
rarely, if ever, seen an industry with so much disdain for outside
managers.

A friend of mine who recently joined SOE suggested to me that it may
be because a lot of the employees in the industry like the very
laid-back atmosphere of a game company, and fear that a more
'business' oriented manager would want to whip the employees back
into 'line.'  The sort of hard management that many people joined
the industry to escape.  Do you think this is close to the mark?

>> I would enjoy exploring if there are parallels between the effort
>> that Game Developer magazine is undertaking and the management
>> techniques developed in some of the knowledge houses like PMI,
>> SEI, and SEL.

> I've never attended any of the PMI or SEI sessions. But what I
> have heard back from those in the game industry who have is that
> they tend to miss the iteration factor above all, and to a lesser
> degree, tend to miss the fact that "good engineering" often has to
> take a backseat to business realities or fun.

I can tell you that the PMI training is idealistic, to be sure.  All
but the first two levels of SEI's CMM model are practically
impossible to reach even for extremely process-oriented companies,
and they have defined five levels!  Any training like theirs will
have to be adjusted for the practical environment, and may seem like
more trouble than it is worth when trying to adapt to a company that
strives to stay laid-back.

By the way, have you read any of Prima Tech's line of books on game
development, and game design?  If so, what do you think about them -
are they worth the money, if you're trying to learn more about the
'iteration factor' and what makes game development different from
'standard' business practices?

Thanks!

-Brian

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev