[MUD-Dev] the design process

[Koster]

From: mud-dev-admin at kanga.nu 

> 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.

Well, I can't expound on it for ALL games this size, but I can tell
you how we do it for SWG (which is also basically the process we
followed for Privateer Online). UO had a radically different process
which I wouldn't recommend particularly as it can best be termed "ad
hoc."

First, I'll answer your general questions, then I'll describe the
process.

> Or take Raph, working on Star Wars: Galaxies. In a project that
> huge, how much detail work do you do, Raph?

On SWG, I am personally doing the detailed design of only a few
systems. And the "detailed" design I do is not as detailed as the
designs eventually need to be -- for any given system that involves
scripting, a technical design for the script implementation has to
be done, and I don't do those, the actual implementer does.

The specific systems I am doing include almost all of the user
interface, the core design for the AI system, and probably of a few
scattered professions (skill groupings). However, as far as "vision
statements" or design goal outlines or high-level design statements
for systems, I do almost all of them; there aren't many systems
where I haven't laid down some sort of guidelines about how it
should work or how it needs to relate to other systems. But we
believe in giving individual designers autonomy and control over
their individual systems, so they often evolve considerably from
what I specify.

> I presume you have other designers helping you, but what do they
> do?

I have two excellent leads working under me--one for systems and one
for content. Each of them then has a team. All members of the design
team have strong game system skills and all of them have scripting
ability (some of them are VERY good at it and a couple have worked
as programmers).

On the systems side, they design and document game systems,
implement the script side of game systems, and generate data for the
game systems. On the content side, they write, design, and implement
game content of various types. The content guys also happen to
handle all the SFX/music data.

>  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?

No to both. On the former, I'd say something like "We need an
archetype or two for players who like to play the ranger type role." 
On the latter, more likely they'd get a doc from me or a couple of
hours of design meeting (not just with me, but with everyone on the
design staff) that outlined the high level design of how the
economic system worked. So for example, for the SWG economy, I knew
I wanted player-run shops, a resource system for generating base
resources from which crafting is done, resource expiry, item decay
and damage, offline resource mining, Perlin noise distribution for
resources, shifting resource maps, offline manufacturing, and a
myriad of other things. So I outlined all of this stuff, and the
rest of the team tells me where I'm on crack, and we hash it out in
a brainstorm meeting.

> 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.)

Depends on the system. Let's take spawning. We talke about spawning
a bunch,

knowing that we didn't want static resets. I developed a little
chart of all the different types of spawning that have been known in
muds (it's in the design patterns presentation, I think). We talked
through them all. In the brainstorms, we settled on using random
encounters as the backbone of the system. It was assigned to a
particular designer, but after talking through it with him & the
lead systems guy, I had a set of requirements. I THINK I also added
in the concept of dynamic points of interest (ability to construct a
complete scenario as a random encounter) but that may have been
someone else. It's a very collaborative process, but at the same
time, I'd say that it's also somewhat comparable to
paint-by-numbers; I did the black and white outline, but they get to
fill in the colors of a given space any way they want as long as it
jibes with the spaces next to it.

OK, as far as the actual process:

The pitch is first; it's usually only a few pages, and offers a very
very high level statement of the game. I won't go into detail on
it. Only "core team" is involved in this--producers, leads. Everyone
else is, most likely, still on some other game at the time.

We start with a vision statement. This is a document of up to 40
pages, and I write it. Ours breaks into goals, themes, checklists,
and game summary.

The vision goals section is informed by service goals, monetary
goals, timeline goals, audience goals, etc. We set up specific
targets. These are things like "must continue to attract new users
for at least five years," "must have a profit margn of XX%," and so
on. We set up target technology platform here too, since that
informs audience composition.

Themes covers what the game is *about*. We use these to determine
what game systems need to be present. For example, some of the Star
Wars Galaxies ones

included, "Star Wars is about exotic locales," "...about an epic
struggle between good and evil..." "...about politics writ large,
played on the stage of the Galactic Civil War..." This sort of
high-school level thematic analysis keeps our eyes on the prize of
making the game feel cohesive.

The checklist is a massive checklist that mostly carries over from
prior games. It includes a wide array of things that we consider
vital to fulfill.  Examples include "must give the user a big payoff
in the first few minutes of play," "must support all of Amy Jo Kim's
principles of community building," and so on. Some of them will vary
based on the prior items: "must be upwards scaleable to future
platforms," or "the user interface will always favor ease of use
over

depth; depth will always be optional" are cases for SWG, but might
not be for a different game.

There's several hundred checklist items. Every signle design
document thereafter must include a list of checklist items that the
design attempts to address.  It's tedious paperwork whose primary
purpose is to get the designers to read and continually re-read the
vision statements so that they don't lose focus of what the game is
all about.

Lastly, the game summary. This I get to write, and it's a single
paragraph about each key game system in the game. It takes around
10-20 pages, and has a paragraph for characters, for economy, for
PvP, for spawning, etc. One for each key system. They are presented
not as designs but as sales pitches, because again, this is the
shining castle on the hill we're heading for.

I wrote two posts for the SWG boards on the design process, and I
will paste

them in here now, though they go over some of the same ground as the
above. They're not written for a designer audience, obviously.

  Source: http://www.legendmud.org/raph/gaming/designprocess.html

start quote--->
MMO Design and Satisfying a Varied Player-Base (posted December 13,
2000)

Good morning everyone... sorry for not posting yesterday, but as you
may have seen on the news, we've had a spot of bad weather here in
Texas (and probably also where many of you live). At the moment my
house is without power...

Since in the last couple of notes I talked a bit about the audience
we expect to get, and what sorts of different gameplay people in
that audience want, I thought that today I could maybe talk a little
bit about how we go about designing an MMO, and how we try to
satisfy that range of people.

To start with, I happen to believe that the four play styles I
mentioned should all be catered to. We play massively multiplayer
games in large part because of the other people. And if the game's
population consists entirely of other people just like us, well,
it's not going to be a very interesting world. Other people like us
won't challenge us in any way, won't expose us to new ideas, won't
surprise us with actions that we ourselves wouldn't have taken. And
that would make a massively multiplayer environment a lot poorer,
because we rely on the other players to provide unpredictability and
interest.

Yes, there's plenty of room for niche products that cater to one
play style or another. But if you want to try to convey a universe
(especially one as deep and rich as Star Wars) you have to have all
sorts of people. On top of that, all sorts of people love Star Wars,
and they're all going to try the game. I'd hate to disappoint
everyone except one particular play style.

So how do we go about trying to ensure that the game offers enough
for each of the types? Well, it all comes down to the design, like
so many other things.  Our first step was to create what we call a
vision document. This started out by identifying some things about
who we thought we were making the game for.  Right off the bat, we
established what sort of audience we thought we were looking at, and
that led to establishing a whole bunch of other things. As we came
to each statement, we put it into the vision doc.

For example, knowing that we were looking at a broader audience than
MMOs had likely seen before meant that we couldn't demand as much
time per play session or as much time per week as other MMOs did. As
a result, a bunch of design choices went right out the window: we
knew that we couldn't have game design elements that involved
spending tons of time online. No macroing, no camping, no lengthy
corpse recoveries, no long waits for public transportation.

This also led inescapably to the logic that a player who had less
time to spend per week couldn't be put at a severe
disadvantage. Now, obviously, someone who has more time to spend on
the game is going to accomplish more. But we CAN do things so that
people don't feel left behind. So into the vision doc went a
statement like, "players who play a lot and players who don't have
as much time to spend should still be able to play together
fruitfully."

We also had more concrete stuff in there. There are things we have
to put in to attract people to the game, like great visuals. There's
things we need to have in order to make money, like having enough
depth in the game so that players continue to subscribe for
months. We ended up with six pages of these one-liners. Some
samples:

  - It should have an intuitive user interface. If the choice for
  initial interface is between flexibility and ease of use, we will
  choose ease of use, and make the flexibility an option.

  - It should be possible to play a satisfying game session in less
  than an hour.

  - It must be easy to extend and add content to the game after
  ship.

  - Star Wars Galaxies must provide multiple ladders of advancement
  so that new ways to play the game become apparent over time.

  - The game system will encourage specialization.

  - Players should never feel ripped off by the game mechanics.

  - We must encourage a sense of player ownership in the world.

Tomorrow I'll talk about how we translated that into game
features. Stay tuned...

----

Design Process, Part Two -- What is the game ABOUT? (posted December
15, 2000)

Hello everyone. I'm suffering from a nasty cold that made me miss a
chunk of a day of work, but I still made it here to the boards to
post my promised next

installment of how we tackled the design.

I mentioned yesterday that we had built around six pages of "vision
statements" that reflected what we felt the game had to accomplish,
and I posted some examples. Now, I left something out there: the
context in which these visions had to be reached. The key element
there, of course, is the fact that this game was set in the Star
Wars universe. And that requires some vision elements of its own! :)

I basically took the design team back to high school English class
one day, and had everyone sit around and think about "What is Star
Wars about?  Thematically, and emotionally?" Everyone by now knows
the whole deal with Joseph Campbell and the Hero's Journey, so we
breezed by that bit. One big reason for breezing by it is that the
Hero's Journey is not very compatible with a massively multiplayer
mindset. Not everyone can be the predestined hero that will save the
world (or galaxy, in this case).

After discarding the Hero's Journey, we ended up with a short list
of key thematic elements that we thought every Star Wars fan would
have picked up on either consciously or unconsciously. We knew that
if we failed to represent these things in the game, then players
would (correctly) feel that the game wasn't truly Star Wars. Just as
you can't imagine The Sims without consumerism, just as you can't
imagine Ultimas without ethical dilemmas, you can't imagine Star
Wars without these things. These, then, were the things that the
game mechanics had to be ABOUT.

  - Exotic worlds and epic adventure. 

    This meant that we had to strive to reduce tedium and repetition
    from the game mechanics wherever possible. We had to strive for
    as dynamic an environment as possible, while still faithfully
    reproducing the SW settings players would be familiar with. The
    game had to be filled with discovery and surprise.

  - The struggle between the light and dark sides of the Force. 

    This meant that not only did we have to have this in the game,
    but that we had to allow players to feel like they had a
    meaningful impact on the struggle. Through their choices, they
    had to be able to make a difference. At the same time, people
    needed to be able to opt out.

  - Political battles to take control of the galaxy. 

    We don't tend to think of this one often, even though it's a
    clear backdrop to everything (expressed as warfare in the
    Classic trilogy, but more directly seen as political maneuvering
    in Episode I). There are plenty of people who are fighting in
    the Civil War not because of the Force, but because of more
    mundane political reasons. Again, we had to allow players to
    feel like they had a meaningful impact on political struggles in
    the game through their choices.

  - Interactions with other players. 

    This one is more driven by the needs of an MMO design than by
    the specifics of the Star Wars setting, but even in SW we
    repeatedly see the theme that people need each other. In an MMO
    this becomes even more critical, and we knew that this had to be
    one of the main thrusts of the game mechanics. Interestingly,
    this isn't something that MMOs thus far have done a very good
    job of rewarding with in-game mechanics. Sure, games have
    required you to group, and that sort of thing, but the game
    mechanics haven't explicitly rewarded all the people who make
    the game world a more livable place in other ways: the ones who
    are good roleplayers, the ones who provide entertainment, the
    ones who are in support roles or peaceful roles or economic
    roles. We knew that we had to make our game mechanics reflect
    this.

With these items, we had what the game was going to be about. And
with that, it was easy to see what sorts of features we would need
to have in the game, right? I think I'll be mean, stop now, and
leave it as an exercise for the reader.  :)
<---end quote

OK, then we go into pre-production. I generated a massive list of
every system that goes into a massively multiplayer RPG. It included
everything from attributes to chat system to friends list to
harassment reporting to physics to UIs. We then tasked out all of
the systems to members of the design team.

We held brainstorm meetings on each of the systems. I'd say roughly
what I was envisioning (based on the paragraphs written above) and
we'd hash them out until we had something we all liked. If we didn't
arrive at something we all liked, I'd make the call based on what
*I* liked.

For systems where a whole meeting seemed unnecessray, I'd often
write up a few paragraphs detailing how I wanted the system to work,
and the designer in charge would use that as a guide.

We did docs in two passes--overviews and detailed docs. Overviews
were allowed to get away with vagueness. Detailed docs have to have
all of the following sections:

  - title

  - author

  - rev num and last modification date

  - bulleted list of document goals

  - overview, an abstract of the system as a whole

  - list of all terms referenced in the document

  - features listing of all features called for in the document,
  broken into three tiers of priority

  - systems broken out by priority level in detailed form, with:

  - for each system covered, an overview of the system

  - a listing of each piece of data required by the system

  - a description of each key algorithm or method used by the system

  - a rough description of the user interface needed

  - any diagrams reauired to explain flow or UI

  - a scenarios section describing in narrative form how each system
  is experienced by the player (could include inner workings, but
  had to be narrative in nature). Some systems that are not
  experienced directly by the player had instead sample work-outs of
  possible mathematical results, for example the name generator had
  lists of sample names generated by a prototype.

  - an assets section listing all 3d assets needed, all 2d assets
  needed, all music needed, all SFX needed, all data needed, all
  templates needed, all scripts needed, etc.

  - a TBD section covering unanswered scenarios, unanswered
  questions raised by the design, mandates from LucasArts, etc.

A design document, once completed, was in theory supposed to be gone over by
me or the lead of that particular team (content or systems). In
practice, this process was not up and running at an appropriate time
in the project development, which led to grief. :P

I'll skip the document approval bits with LucasArts and LucasFilm
Licensing, since they are very project-specific.

While this is going on, there are weekly meetings. Not only are we
meeting weekly with the associate producer to go over the schedule
and see where each task stands, but there is also a weekly design
review meeting wherein each designer talks about the systems they
are working on and any challenges or issues that arose. Tips and
tricks are traded, code review are done, etc.  Sometimes, we need to
schedule additional design time where we apply more brains to a
given problem. The content guys hold near-daily brainstorms, for
example, where they hash out plots and quests and characters and so
on.

During all of this, I am scheduled at around 1/4 or less of the task
load that a regular design gets, and each team lead is at around 3/4
of a regular task load. This leaves room for management tasks.

When we get to production, there's strike teams, which consist of
the designer in charge of the system, the programmer they would be
working with, a producer, me, the team lead, an art representative,
and so on. Basically, key stakeholders. These meet weekly and not
only check the progress but critique the progress on systems, do any
adjustments in priority that need to occur, etc.

You asked what my role is like--well, I basically never touch a
number except to say something like "eight skin tones isn't enough,"
or "you're going to want more than a byte of granularity there." The
movie analogy is hackneyed and kind of inaccurate, but there are
definite correlations. I'm at the same level as the art director and
director of tech, and the levels of influence over a given system
vary for those roles depending on what the system is. In the design
case, I move around more than the other two do; Jeff and Jake get to
have their heads in their own discipline more, and I get to poke my
nose into what they're doing a little more. So the analogy to
"director," "director of photography," and "production designer" is
SORT of true, but I am less than what a director on a film is (for
one thing, the producers on a project do a lot of what a film
director does; for another, gaming has not thank god fallen to quite
the level of "auteur" theory that film has).

One of the things that I have come to realize is that the nature of
the roles of designer, lead designer, and design director or
creative director is not one of level, but of role. They're just
different jobs, despite the apparent overlap. Yes, we associate them
with level, but in practice, lead designer means "lots of ensuring
the designers are working at their best" and creative director means
"keeping everyone on the same page and seeing the big picture." In
fact, earlier this year we had problems because we blurred the line
between lead and director too much.

One of the perks I personally enjoy is that I am involved in code
and art to the extent I am; I am consulted or involved on fairly
technical issues, and I have a lot of input on visuals. I am not and
cannot claim to be as competent or knowledgeable in those areas as
Jeff or Jake, but I can make real contributions, and that helps me
serve as a sort of a fulcrum for helping something like, say, our
terrain system (which arose from my concept, but took a programmer
to make real, and then took artists to make look good) come
together. Terrain system is a good example, because it's a place
where the problems to be solved were not simply "how do we make
maps?"  but also things like "how do we let players build? how do we
ship on less CDs? How do we generate landscape faster and still hit
the quality bar?" I was able to supply an answer, but it takes a
team to make the answer work.

Fortunately, we have a kickass team. :)

First caveat--anyone on the team can chime in on anything.

Second caveat--it's very important to understand that with a project
this size, who you have on the team very much defines what sort of
roles you end up having. You could easily promote some of the guys
working for me into my role. But their job would end up being
different because of who they are. I feel very lucky in that the
role I have happens to also let me do all the various things I
enjoy--help solve cool tech problems, be involved in marketing and
community management, do detailed design work, see the game's big
picture and do conceptual work, be involved in look and feel, to
help craft story, to do a bit of scripting and coding, etc.

Hope that answers your question. :)

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