|
|
By
Gloria Stern
Gamasutra
December 19, 1997
|
|
|
Features

Discussing Multiplayer Online Games with Digital Arcana's Jeffrey Sullivan
Jeffrey
Sullivan is a partner with Bruce Onder in the company they formed together,
Digital Arcana. They have published several interactive projects and are
now at a very exciting point in their work. Digital Arcana is producing
a multiplayer, online game, or MPOG.
Would
you please describe for our readers what a multiplayer online game is
like?
A multiplayer online game (MPOG) is fundamentally this: a computer game
that can be played simultaneously by many people at the same time, and
in the same game. (By contrast, a game of solitaire on the Web could be
played by thousands of people at a time, but they're not playing together;
that's a single-player online game.) Some MPOGs are what we call persistent-world
games; in these games, players can drop in and out of the game at will,
but the "game world" is always there, hanging and evolving whether a specific
player is in the game or not. Some examples of this type of game include
MUDs (Multi-User Domains) like Meridian 59, Ultima Online, and our own
The Outer Limits Online. Other MPOGs have game worlds which only exist
for a specific game; when that game ends (or all players leave the game),
the game world goes away, only to be created anew when another game is
initiated. These games tend to be action- or strategy-based games like
Quake or Command and Conquer.
Online Multiplayer gaming is just now coming into the mainstream. Digital
Arcana already has established itself in the field. How did you and your
partner, Bruce Onder, get together on this?
We had been writing together since college -- first short fiction, then
screenwriting, and finally interactive writing and design. So we've actually
been at it (where "it" is writing together) for over 10 years. Our interest
in multiplayer online games (MPOGs) came from our exposure to the highly-addictive
text MUDs of years gone by, combined with computer- and paper-based role-playing
games. We've wanted to bring that level of depth and immersion to the
masses for many years, and now the technology is finally allowing that
in a compelling way.
Tell me, Jeff, what skills, interests or talents did you have when you
started?
Bruce and I had been trying to break into screenwriting for several years;
we had sold a script and done some rewrites, but the scripts had not been
produced. We had also done some TV animation writing, and had a short
film produced as part of an independent horror anthology film. So we'd
met with limited success -- lots of A-list companies had met with us and
told us we were very talented, but our feature film projects were not
getting made.
During this time, we were working in the computer field to support ourselves:
I was an AI programmer for a think tank (Information Sciences Institute)
and Bruce was a database consultant. All along, we have been very avid
gamers -- from card and board games up through paper role-playing games
and computer games of all kinds. I had been playing a lot of games and
reviewing CD-ROMs for a variety of magazines (CD-ROM World, Wired, MacWEEK,
MacUser, etc.), and when MYST came out, my eyes were truly opened. For
the first time, I saw an experience on CD-ROM that matched the quality
of experience of a TV show or movie or book. This, to me, was more than
just a fun game -- it was a mass-market quality entertainment experience.
(Bruce had different opinions about MYST, but since he's not here, I get
to present mine.) The long and short of it is that we figured "Hey, we've
got three great backgrounds for this stuff (screenwriters, gamers, and
techno-geeks), so let's do it."
We created a few original concepts, showed them to Activision here in
L.A., and they didn't buy them. But they did like us, and a few months
later, they brought us in to do a complete redesign of an espionage game
then called "The Colby Project." It later became known as Spycraft: The
Great Game, and has gone on to win many awards and tremendous critical
acclaim. We moved on from there to start a design for Planetfall 2: The
Other Side of Floyd (a graphical rebirth of a classic Infocom text adventure),
but departed the project when our vision diverged from the producer's.
At that point, we knew we wanted to have more creative control over projects,
and on our next deal, for The Outer Limits Online, we signed on to write,
design, and produce. We're still in production on that project, which
is a massively multiplayer role-playing game based on a few of the episodes
of the new science fiction TV show from Trilogy Entertainment.
What projects have you (Digital Arcana) already created?
We wrote and designed Spycraft for Activision, and did the initial design
of Planetfall 2 (the project was canceled about a year after we departed),
also for Activision. We also did a complete redesign on a FMV-based adventure
game for a company on the east coast, but that will be uncredited. We
are currently writing, designing, and producing The Outer Limits Online:
Beyond Resurrection for MGM interactive. It's a massively multiplayer
roleplaying game designed to appeal to the mass-market rather than just
hard-core gamers. We have written and designed another massively multiplayer
game based on the paper role-playing game Space: 1889. We licensed the
rights from its creator, Frank Chadwick, who is well-known in the roleplaying
game industry for his compelling game design. We're currently seeking
a publishing deal for that. We have also designed an online sports game
which we are currently in talks with investors to fund and develop internally.
Finally, we have done some initial proposal work on several online multiplayer
games for major studios which are currently being discussed.
What influenced you to enter this area?
Having been pretty hard-core gamers ourselves, as well as professional
screenwriters and technically-savvy computer programmers, we felt that
interactive entertainment was a natural fit.
What
are some of the factors to consider when creating a multiplayer online
game?
With respect to creating a story-rich multiplayer online game, we think
about four major points. I've listed them below. (Note: These points are
summarized from a lecture we gave at the 1997 Computer Game Developers
Conference.) These are only the tip of the iceberg. But the tip of the
iceberg is crucial in this case, if you don't get these steps right, it
doesn't matter how big the iceberg is, because nobody will see it. Here
are the four basic considerations:
Step
1: Choose (or create) an appropriate world to build. Appropriateness,
here, is the ability for the world to be scale up to allow thousands
of players to have fun.
Step 2: Develop a compelling backstory. Here the emphasis is on back.
You need to know what the state of affairs in your world is at the time
the world is "born" in order to have a shot at building it well, but
you shouldn't try to dictate what will happen in that world once you
let players through the gate.
Step 3: Choose a presentation style. Choosing the style of presentation
will say a lot about the kinds of things that are important (and even
possible) in your virtual world. Unfortunately, this choice is often
dictated by the game engine you're using.
Step 4: Provide powerful but appropriate tools. Make sure your players
have enough fun things to do, and also make sure you don't let them
do anything so "fun" that they ruin it for everyone else.
Do
you look over the tools available and form your game to accommodate them?
Or do you form a concept and go shopping?
We have done both. On The Outer Limits, we were handed a technology to
use. Unfortunately, it was not mature, so it was evolving as the design
was being created (and even afterward), so it was not a great situation.
On other original projects, we design to the limits of known technology,
but usually not to a specific technology. Since we have a pretty solid
grasp of what can be done, we design to that, plus a little (since capabilities
always increase faster than you expect). No matter what, there is going
to be some amount of redesign all the way through production, as certain
features turn out to have odd limitations, or just don't work quite the
way you expected.
This is a relatively new format. What do you look for in a suitable
concept? What influences your choice?
The
best way to answer this question is to again excerpt from our 1997 CGDC
lecture (since this was one of the topics). Let's step through the issues...
How do you go about choosing a world?
Obviously, few people are in a position where they can just "choose" to
develop Star Wars into an online virtual world. However, if you're working
in a company or have clients with properties, you'll want to spend a little
time thinking about the suitability of the company's various properties
(or about your various original ideas). Not all properties will have all
of the elements that would make for a great virtual world, but you may
be able to add them if they aren't there. Here are some questions to ask
yourself. These issues apply to worlds that you intend to create out of
whole cloth, too -- you will have to answer the same questions and deal
with the same obstacles and challenges. Is the world visually interesting?
A world based on Star Wars would be quite a feast for the eyes. A world
based on Waterworld might be more visually interesting underwater than
on top. The surface world would need some spiffing up. Is there a basic
tension in the world? Conflict is the basis of all drama. Make sure your
world has built-in tensions that are not easy to resolve. For example,
players could get involved on one or both sides of a conflict in a world
based on Independence Day. In fact, with a good design, players can create
additional tensions by forming groups that play off both ends against
the middle.
Other players may choose not to take either side, but they will undoubtedly
be affected by a major conflict. Is the genre of the world fresh?
Let's face it everybody and their mother is doing a fantasy role-playing
game. If your world has a different setting or genre that is also popular,
you can easily stand out from the crowd. For example, the retro-futuristic
setting of Space: 1889 makes it unique among a horde of SF games involving
either cyberpunk dystopias or alien-infested bug hunts.
Can the world scale up to let thousands of players have a good time?
The scalability issue has several major components. The world needs to
scale well in at least three primary ways:
Gameplay: The kinds of gameplay which are engaging with small numbers
of players can quickly get unwieldy or boring with large numbers of players.
For example, gameplay based purely around combat begins to get old after
a few months. Any world based on or dominated by a single element of gameplay
will not scale well over time. Players will get bored and the more players
you have, the faster more will get bored.
Geography: As more players join the game, you've got to make sure that
there's enough space to move around. A world that's big enough for 1,000
concurrent players probably is going to get crowded when you hit 5,000.
Population: Is there enough of everything to go around? This goes beyond
simple geography to things like social power, interesting quests, world
resources, and the like. You're creating an epic saga for thousands of
players make sure the world has an epic scope. Some source material makes
for a great virtual world, but lots of material just doesn't scale up,
usually because it's too focused on a single main character, or a small
cast of characters. Are the character choices interesting? Is there a
variety to choose from?
Make sure that there is enough variety in character choices to appeal
to a lot of players and to keep the gameplay interesting. In worlds where
the choice of characters is limited, homogeneity and boredom are the inevitable
results. Can you get thousands of players interested in playing in a world
based on the Island of Doctor Moreau? Quite possibly -- there's a lot
of interesting character types to choose from.
What
sorts of characters fit online multiplayer games? Locations? Game objectives?
Those are three key questions.
Characters: All sorts of characters fit into MPOGs. In fact, there is
more room for a variety of character types in MPOGs than in more traditional
computer games. One of the things that you have to keep in mind is the
scalability of the game experience. Since there is going to be a lot more
gameplay going on in your game than 90% of the other kinds of games that
exist, you want to supply both a wide variety of character types and a
rich depth to each of them. In a game like Quake, you only need to supply
a single type of player-character (a space marine) and a few monsters
to kill. After all, the only point of Quake is to kill stuff (stuff being
a technical term representing both creatures and other players), so any
kind of character that doesn't facilitate that end is a waste of effort.
On the other hand, most MPOGs, especially the kind we tend to do, are
more about creating a whole synthetic reality -- one that is both self-sufficient
and complete. We need to have a wide variety of characters who do all
of the things to keep that world self-sufficient and fill all the roles
which exist in that world. For example, if we have a game world where
food is important, character types who grow and harvest the food (farmers),
prepare the food (cooks), and sell the food (merchants) are all obvious
and necessary parts of the game. In a game like Quake, food and medicine
are just sitting around on the floor, and how it got there is immaterial.
Locations : The locations in a game need to meet a number of requirements.
Of course, they need to be interesting and appealing to players. But they
must also fit the internal logic of the game world (i.e., no anti-gravity
rooms in a realistic espionage game), and be practical within the technology
used to create the game (e.g., many real-time 3D game engines are optimized
to portray interior spaces with relatively flat walls and floors and limited
sight-lines; these engines are weak in portraying wide-open outdoor spaces).
Game Objectives: The game objectives (historically called puzzles)
in a MPOG differ from that of a single-player game in that they need to
be more general and encourage (or even require) interaction between players.
The most basic way to think about gameplay in a multiplayer game is that
it needs to be recyclable rather than disposable. One-off game elements
(e.g., learning the secret password to a speakeasy) are too costly; you
would need to keep creating new ones over time to keep the game world
fresh and challenging. Instead, you need to think of challenges and objectives
which are more circular in nature. For example, look at the game King
of the Hill; just because I become King doesn't mean the game ends, it
just means that I'm fighting to stay on top instead of get on top.
Puzzle Types: In addition to the social and exploratory aspects
of a game world, you will have a variety of puzzles and other gameplay
elements. These elements can be categorized into three basic categories:
solo, cooperative, and real-time.
Solo: Solo puzzles are puzzles which can be solved by a single player
without outside aid. We need a fair amount of these puzzles in the game
so that players logged in alone (or who are in an area which has no other
players at the moment) will still be able to have fun. Some examples of
this kind of puzzle include:
-
hacking
into a security computer to shut down a perimeter alarm
-
deducing
the secret entrance to a competing gang's home base
-
figuring
out how to operate an alien device.
Cooperative:
Cooperative puzzles require more than one player to be completely
solved. A cooperative puzzle may require characters to be in multiple
places at the same time to generate a solution or may require the physical
or mental efforts of more than one creature.
Some examples of cooperative puzzles include:
-
to
launch a nuclear missile, you need to turn two keys simultaneously,
and the keys are ten feet apart
-
to
open a jammed vault door, at least three people must push on the door.
Note:
While cooperative effort is the most likely way to achieve these ends
(hence the name), it is also possible to solve a cooperative puzzle by
tricking an opposing player into inadvertently "cooperating" with you
and doing part of the puzzle. (For instance, you might be able to trick
a character into thinking you'd already turned the keys for the nuke launch,
and when they try to turn one of them back, you turn the other one along
with them).
Real-Time: These puzzles require some form of real-time action to
effectively solve them. Obviously, real-time puzzles can be either Solo
or Cooperative, so they're not really another type of puzzle so much as
a dimension of the first two types. Some examples of real-time puzzles
include:
-
defusing
a bomb requires removal of the faceplate, penetration of the black
box, disconnection of the firing assembly, and neutralization of the
detonator, all within 90 seconds of breaching the faceplate, or the
fail-safe self-detonation will occur
-
sneaking
through a security compound requires you to avoid the security cameras
in five hallways, each of which sweeps its hallway in 30 second intervals,
you need to move around each corner and down each hall while the camera
is swinging away
-
in
the nuclear missile launch example above, if you don't turn the keys
simultaneously, an alarm will sound and trap you in the bunker until
a security detail arrives
Describe
the team needed for a MPOG and the job descriptions.
They are better described by job description.
Producer: The position responsible for fiscal project control and management.
An Executive Producer or Supervising Producer from the funding company
may be assigned to ensure appropriate progress and diligent fiscal responsibility
during project development.
Associate Producer: One or more assistants to the producer who will help
manage the production and oversee specific areas (e.g., sound and music,
ports, asset management, localization, etc.).
Production Coordinator: The person responsible for coordinating the process
of creating the game assets during the Production Phase of development.
May create shooting schedules, recording sessions, etc. Designer: The
creator of the world-model, settings, and rough storylines for the title.
Works closely with the writer (or may be the same person).
Assistant Designer: An assistant to the designer, this person is responsible
for contributing to the design of the game, keeping track of changes to
the game design, and assisting the producer and director on design issues
during Production.
Writer: The creator of much of the specific written content of the game,
Including character biographies, fleshed-out storylines, and complete
scripts. Works closely with the designer (or may be the same person).
Director: The position responsible for creative project direction. This
person oversees the overall tone and direction of the project, and approves
and directs the development of every aspect of the story, characters,
interface, and look of the project.
Visual Director: If required, this person oversees the production of the
visual elements of the game, directing storyboard development, camera
placement and movement, lighting, and often actor performance.
Art Director: The person responsible for generating the overall visual
style of the project. This person creates or oversees the creation of
models for all characters, costume design, scene layout and construction,
and interface elements.
Artist: The person(s) responsible for creating the art assets for the
game (including character images, animations, interface art, splash screens,
3D models, texture maps, etc.). Works under the supervision of the Art
Director
Composer: The person responsible for creating the soundtrack to the game.
Works with the Sound Designer (may be the same person).
Sound Designer: The person responsible for creating all ambient, Foley,
special effect, and environmental sounds in the game. Works with the Composer
(may be the same person). Developer: Oversees all programming tasks required
to produce the game. Designs and codes the game engine, special interfaces,
and all game logic for the game. May be responsible only for the lead
platform version, with ports handled by subcontractors or developers hired
later by the distributor.
Lead Programmer: The specific employee of the Developer who handles the
Technical implementation plan for the game. Creates a Technical Design
Document which mirrors the Game Design Document, indicating how each element
of the design will be implemented, who will be assigned to programming
what modules of the game, and oversees integration of all programming
into a fluid whole.
Programmer: The person(s) responsible for coding the game. They implement
the game logic in the game design, create the interface, integrate assets
and computer code, and handle all programming tasks related to delivering
the game. Works under the Lead Programmer.
Cast: The performing talent required to bring life to the characters in
the game. In animated projects, each performer can do up to three major
roles, which greatly limits the number of performers required. In live-action
projects, more talent will be required, since re-usability of performers
is more limited.
What does the development plan look like? By that I mean what documents
are needed to provide pace, deadlines, and division of labor (responsibility)?
What things do they contain?
First and foremost, you need the game design, which is the starting point
for all other development documents (see next question for more detail
about the game design). After you have the design and script (if any),
you create a technical specification (see next question for more detail
about the technical spec). From the design and spec, you create your budget
and schedule by breaking the spec down into tasks and assigning durations
and manpower requirements to each task. The schedule and budget are then
constructed from the tasks by applying costs to time and materials and
linking tasks which have dependencies together in the appropriate way
(e.g., if I need the raw animation frames before I can apply special effects
to them, then applying special effects depends on first creating the raw
animation frames).
Are there separate documents (scripts) for the creative staff and the
Technical people?
Yes.
The creative team works on a pair of documents: the Game Design and the
Script. The technical team works from a document (or collection of documents)
called the Technical Specification. The game design is a compilation of
everything we need to know to create the game. it is usually ordered in
some sort of way that makes sense to readers (e.g., chronologically, if
it's a time-based storyline type of game; or by object type, if it's an
object-interaction type of game); it includes all characters, storylines,
player abilities, game logic, objects, locations, and user interface for
the game. The script contains the dialog and actions for all characters
and scenes in the game. Sometimes these are contained in the game design,
and sometimes they are broken out into a separate document. The technical
spec contains much the same information as in the game design, but it
is organized to aid the technical team in creating the game. In addition,
all of the qualitative experiences described in the game design are nailed
down to specific functional definitions. For example, if the game design
calls for video to be "television quality," the technical spec may call
for all video sequences to run in 16-bit color in a 640x480 window at
a minimum of 15 frames per second (and will discuss the video compression
utilities to be used and the playback engine requirements). The technical
spec also contains a detailed analysis of the interface spec in the game
design, breaking the interface down into controls that will need to be
created and their interdependencies.
What things does a writer need to learn to enter the field?
A writer needs several key pieces of background to enter this field. First
off, you need to know how to write. That seems obvious, so I won't belabor
it too much, but keep in mind that you are the person who will crystallize
all the free-floating ideas about the game and communicate them to each
member of the team in a clear and exciting way. This is a non-trivial
task, and poor writing can really hinder the process. Second, you need
to love games. Creating games is a very difficult process -- much more
so than making a feature film, from the writer's perspective. You'll do
much more work and get paid much less money. If you don't love it, you'll
fail. Third, you need to know games and, to a lesser extent, computer
technology. You need to know what has been tried before; what worked and
what didn't -- and why it worked or failed. If you repeat the mistakes
of past games, your career will be short and unremarkable. Also, if you
keep calling for things that can't be done on your budget, you're of no
use to a game developer, no matter how great your ideas.
Thank you, Jeffrey. We'll be watching for Outer Limits and now that
you've told us all about it, we'll be right there, playing the game.
Before
becoming a computer guru, Gloria Stern tried her hand at racing sports
cars for prize money, navigating a small private plane in the Powder Puff
Derby, leading a dive expedition to a pre-Columbian wreck in the Caribbean
and panning for gold in Maine.
When Disney opened up in Florida, Stern formed a commercial production
company in Orlando and began telling the stories of her adventures. It
was an easy transition from there to the west coast and the entertainment
industry where she worked as an film editor. Story consulting, ghost writing,
teaching and a huge doses of curiosity, imagination and excitement lead
her right to the development of interactive media.
Ms. Stern is an Associate Editor of the Web Developer's Virtual Library,
a charter member of the Virtual Drama Society, a member of the HTML Writer's
Group, and founder of Two by Two, the Writer's Guru and The Mouse Trap.
She is the author of "Do The Write Thing: Making the Transition to Professional"
published by Myriad Press, and the Director of The Virtual Classroom,
a distance learning program for content creators. She can be reached at
cywrite@juno.com.
|