Considerations When Creating A MMORPG
SDxWiki

DJH I didn't write this. It was on a web page whose lifetime was iffy, so I copied it here.

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.

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

drama is conflict, conflict is drama. 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.

DWM Thanks for posting this. A lot of food for thought. That's a lot of roles to fill, there.

Istvan Really thanks! This is great stuff. Still digesting.