[MUD-Dev] the design process

[John Buehler]

Matt Mihaly writes:

> Say, I was wondering if some of the bigger commercial people
> (anyone from Sony, EA, Microsoft, even Mythic, etc) could expound
> on the design process for games of that size.

> For instance, in Achaea, every significant design decision goes
> through me, and I personally design all the major systems, down to
> writing most of the text (On the other hand, I'm considerably more
> removed from the content-building process, which is largely taken
> care of by others.)

> For instance, Dave Rickey designed, I believe, the economic part
> of DAoC, while some other guy (the company president maybe, if I
> recall properly) designed some other systems, and yet other people
> designed yet other systems.

> Or take Raph, working on Star Wars: Galaxies. In a project that
> huge, how much detail work do you do, Raph? I presume you have
> other designers helping you, but what do they do? How do you work
> it all out? Do you say, for instance, "Ok, I'd like a Mandalorian
> Knight class that is fairly mobile, has cool gadgets, can fly
> fighters, etc." or "Design me a closed (haha) economic system in
> which the principle way of earning money is managing NPC
> employees." and then just approve the final result?

> In other words, how broad are the strokes the lead designer (or
> creative director) generally paints on your team? (I'd imagine it
> differs widely.)

Although not asked, I'll comment on general software product design
methods that I've been involved with.

Coherent design is top-down.  A small team of from one to four
people comes up with the overall design for the product.  That
covers what broad feature sets it will have, what problems it will
solve and how it will do it.  Then others are brought on board to
flesh out the details of the systems and features.  That fleshing
out process extends down to the point of designing the important
data structures and individual algorithms.

There is a relationship between trust/skill and the importance of
the feature in the product.  If a product feature is critical to the
success of the product, then a highly trusted/skilled individual is
made responsible for that feature.  Usually a member of the core
design team.  If the product feature is complex/large, then the
individual is permitted to retain a team that consults/helps with
its design.  It is an assumption that the core design team discusses
things regularly in order to keep the vision alive.

Variations that take place are that a highly skilled individual is
brought on board after the startup team has structured the overall
product.  Such as a technology specialist (e.g. databases) or a
domain specialist (e.g.  economist).  This generally makes one
section of a product stronger than it would have been, but also
produces a reduced integration and flow with the rest of the
product.  The new designer has opinions on how to do things that may
or may not match up with the core design team.  The design ceases to
be as cohesive as it once was.

My use of the word 'trust' might be misleading.  It is an issue of
shared vision, not a paranoia that another member of the design team
will be malicious in some way.

When the vision is lost in the implementation and business details,
the product suffers and begins to fragment.  Customers don't know
what the problem is, but something is wrong.  A feature here becomes
useless.  A feature there results in a dead end.  Terminologies
start to diverse.  And so on.

JB

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