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 [email protected].