150 THE GAME PRODUCTION HANDBOOK, 2/E
Think about how the player’s character will evolve and progress in the game.
This is one of the main things that will keep people logging back into the game.
Players become very attached to their characters and will spend several hours
customizing the character, and countless hours developing the character through
gameplay. Traditionally, games let you design your character’s appearance only
during an initial character creation phase at the beginning of the game. Now,
more games provide the player creative ways to further customize the character
later in the game. You will need to create art style guides that detail not just what
the weapons, items, and characters will look like, but also what they look like at
low-level, mid-level, high-level, and epic-level. This helps define relative scale if
better weapons are bigger, for example—especially if the game’s races and avatars
vary widely in their general sizes. Again, since bragging rights are such a big factor
in these highly social games, you want to create situations for the player where
he sees someone walking by with an epic glowing fire-breathing horse, and think
to himself—“How do I get that!!!???!!.” The player can tell by the visual contrast
of the object (in this case the horse), that the object is rare, but immediately plays
into the user’s desire to own the coolest and most rare items in the game.
Decide if the game is going to be focused more on Player Versus Player (PVP)
or Player Versus Environment (PVE) gameplay. A PvP centric design might have
many more map types focused on PvP game modes, like capture the flag maps, or
huge battlefields, or siege wars where cities battle against other cities.
A PvE game is where players interact with non-player characters (NPCs)
and battle AI controlled monsters. The player may talk with a townskeeper and
receive a quest—the player then has option to complete the quest on his own,
or to put together a party with other live players to fulfill the quest. PvE games
might have more open landscapes, and players might have more skills that give
them a powerful advantage over the computer-controlled enemies, like long
rooting abilities, which would prove frustrating for a player. (Rooting is a key
type of ability that is very useful in PvE but doesn’t work as well in PvP. Roots
are something like webs or ice blocks that freeze the character in place and
prevent him from moving.) So while the player is still interacting and competing
with live players, he is not trying to directly fight them to accomplish his goals.
When battling monsters, the player can choose which abilities to develop in his
character (stealth, fighting, magic) in order to defeat them.
Art Issues
While in pre-production, you also need to make some key decisions about the
game’s art. In traditional PC or console games, you have more control over how
many players will appear at one time in any environment. If you are working on
a single-player game, you have even more control over the player’s interaction
with the environment. In this case, you can afford to make certain art assets in
MASSIVELY MULTIPLAYER ONLINE GAMES 151
a higher resolution, because you know that the rendering limits of the game
will allow some combination of character models and environmental assets to
be displayed at the same time. In an MMO, rendering issues must be kept in
mind, because you will need to decide how to deal with a mass number of play-
ers on screen at a single time. For instance, how will the game render 50 players,
weapon effects, pets, and weather conditions all being displayed simultaneously
during a full-scale battle? Using character models and art assets that contain a low
polygon count and level of detail (LOD) helps the game render more easily. It is
a common pitfall for developers new to MMOs to create highly detailed charac-
ters and environments that look great when there are only one or two players on
screen, but then the game crashes when more people enter the game.
A project that gets involved too early with mass producing art assets, with-
out accurately measuring and continually evaluating the rendering specifica-
tions such as the number of objects in view, polygon counts, draw calls, and
so on will often turn into a situation where later on the assets must be cleaned
up via intensive and visually impactful LOD passes. It is important to define
at least rough art targets early in the process by creating prototype zones that
include all of the key situations that may occur in an area—for example, charac-
ters monsters that spawn in, environmental textures, and level clutter—so that
you can get an idea of what early efforts must be taken to either improve the
renderer or set guidelines for scenes and zones.
It is critical to have an understanding of how the game environment is laid
out as well. MMOs use instanced areas to deal with population congestion. These
are maps or zones, like a dungeon, that spawn on a server specifically for a player
or a single group of players. Decide what will be instanced, what won’t, and a
general idea of how many assets can be instanced in a space. Overall, you want to
iterate on test areas until you have a good idea of texture resolution, number of
objects in view, particle budgets, and so on, always keeping in mind that 50 play-
ers in the scene will impact your budgets. Also, lay out which areas of the game
are towns, open spaces (no buildings), and community spaces (town halls, banks,
and other places where large groups of player may congregate). Another chal-
lenge is that the content is vast, as in tremendously deep. The game will include
objects, animals, clutter, terrain types, multiple weather systems, and different
types of architectures. In addition to these assets that are used to build a level,
the game will also include NPCs, particle systems, skill systems, craft systems,
special combat effects, animations, and so on.
Production Team
You will encounter many of the same challenges when building an MMO devel-
opment team as you do when building other teams, but there are a few things
to consider when putting together the team. Like any game, it is very important
152 THE GAME PRODUCTION HANDBOOK, 2/E
to fill key roles early in the project with strong people who can work together
toward the unified game vision. For MMOs, the technology is one of the top chal-
lenges, so you will need strong server and client leads, and a technical director,
preferably all with previous MMO experience. A great and rare commodity is a
great graphics programmer who can be a huge bonus when evaluating rendering
engines and helping the client lead define initial technology needs. Obviously, you
also need a strong Art Director with a great deal of pipeline experience to help
with defining the initial art specifications and tool set-up. The more experienced
these leads are in MMOs, the better. There are certain walls you will always hit on
every MMO project and this experience will help the team get over these walls.
When evaluating middleware solutions, the capability and experience of
your engineering and art leads will make all the difference between customizing
what comes with the SDK and shoring up the areas of the pipeline and technol-
ogy that are not addressed by it. It is not advisable to start using incomplete
processes in the pipeline, because it is likely these areas will never be fixed once
full production starts, which is dangerous. If things are not fully functioning and
in place once production starts, time will be wasted by dealing with bottlenecks
and work-arounds that could have been correctly dealt with early in the process.
A large team only adds more pressure to these problem areas, so it is best to have
your small team take care of these issues sooner rather than later.
Because many MMOs have a four to five year average development cycle,
the team structure needs to be very flexible so that it can support people rolling
on and off project throughout the cycle. Because of the slow ramp up, there are
often situations where you may not need a certain person for six months or so,
but will find that this person is available much earlier. So you can either put him
on the project without much to do, or risk losing him to another project or even
another company. There is usually a tendency to take people when you can get
them, and this may create a situation where there are too many people ready at
the beginning of the project. They have to wait around for the tools and produc-
tion pipeline to be set up before they can start contributing to the game. The
trick is not simply finding work for everyone to do, that part is easy. The trick
is keeping true to your order of execution for initial infrastructure and pipeline
set-up without being lured by a large art or design team early on in the project
into working on features before the fundamentals are in place.
Cross-pollination between teams is paramount. Grouping the development
team into specific groups, such as content versus engineering, can be the kiss
of death. You will group teams under their particular umbrella, such as art,
design, and engineering, but you cannot let them isolate themselves from the
other teams because it separates them from the overall team, and diminishes
the overall sense of team for the entire development team. Due to the long
cycle, it is also common for one individual’s roles to evolve over the course of
that single project. For example, an associate producer may start the project by
MASSIVELY MULTIPLAYER ONLINE GAMES 153
helping to manage the schedule and task list, then work on refining and policing
the pipeline and release management system, and then may end up as the Live
Producer.
However, once pre-production work is “done” the team will ramp up very
quickly. Once the pipeline is working, and the infrastructure is ready, the team
needs to work full speed ahead to get all of the objects, weapons, characters,
etc., in the game. Because of the large amount of content, the team size can
grow quickly and the financial burn rates can get very high. Try to prolong
this transition to a large team as long as possible. For example, build a loaded
example of each type of zone, with a small team. This will help flesh out core
concerns that can be fixed and iterated on with the small group. At this point
bug fixes can be done more quickly, which can save time and expense later on
in the project.
9.4 PRODUCTION
While MMOs have similar production issues as other games, there are some
differences in the production modes that need to be considered when putting
together your game plan. Traditional game development cycles are usually date
driven—the game must release by Thanksgiving, or day and date with the movie.
Alpha, Beta, and Gold Master dates are scheduled and the team tries to hit these
dates on time to ensure that the game will ship when it needs to. In MMOs, the
production milestones are more event driven—when will the infrastructure be
ready, when is the art pipeline ready, when is alpha completed, etc. The team
focuses on iterating key gameplay concepts until they are fun. This allows the
game to be built around what works.
Later the focus changes to determining how many people you can get on
a server and for how long. The best way to do this (before you have access to
live players in an open or closed beta) is by creating robots (or “bots”) that can
function as players in the game. Bots can help the developers prototype polygon
budgets, zone layout, AI pathing, spawn points, server messaging, and so on.
This helps the developers optimize the game by minimizing the amount of data
that is sent between the client and server. One of the challenges with using bots
is figuring out when their behavior can be directly correlated to a live player’s
behavior. If a direct one to one comparison between players and bots is used,
erroneous data will be generated. For example, bots will never be able to
completely mimic player behaviors. Development time must be taken to try to
establish the relative ration of bots to live players. In some areas, like a combat
service, close to 50 bots may be needed to equal to the load generated by a single
player. For stressing a chat server, one bot could be worth 500 players.
154 THE GAME PRODUCTION HANDBOOK, 2/E
Traditional terms for key stages in MMO development are Friends and
Family, Alpha, Closed Beta, and Open Beta. The overall concept is to let people
who are furthest from anonymous target customers, and hopefully the most
patient, see the goods early on when the game is expected to be bumpy and
the schedules are inconsistent. Closed beta is when a selected group of users
are allowed to play the unfinished game, submit feedback, and identify bugs, all
under the umbrella of a non-disclosure agreement—which prevents informa-
tion from leaking about the game before the developer wants it to. For a closed
beta, the game is incomplete –assets are not 100 percent final, known issues are
present, and gameplay balancing is not completed. The closed beta is impor-
tant because it is the first opportunity the developers will have to stress test the
servers with humans and see how well the game handles a large amount of live
players. The closed beta will reveal any number of potential issues not limited
to rendering, latency, or game balance. It may pinpoint specific issues with the
game’s economy or class structure. Bugs may be uncovered that haven’t been
seen previously. If the closed beta gets positive feedback from the users, it is also
a good way to generate some early word of mouth buzz about the game.
Open beta is when the game is feature and asset complete, but there are
still bugs and possible play balance issues. Generally, the developer is within
about a month or more of launch and wants to gather huge amounts of data from
large player loads, in order to have longer and longer runs on the live servers in
anticipation of the sudden load of launch day. In the past, a game could hold a
closed beta and it was perfectly acceptable for it to have bugs, missing assets,
and even clunky gameplay. Everyone participating in the test was excited and
positive buzz was usually generated. Now that the MMO market is getting more
competitive and there are many more companies developing MMOs, there is a
lot of competition for beta testers. The game ends up effectively being judged
a stage earlier—when it is at closed beta. This means that target audiences may
make final purchase decisions based player reactions to the game before open
beta—the traditional stage where the developer feels the game is launch ready.
Because of this, the trend is moving toward a more polished closed beta, and
having the game basically launch ready when the Beta goes open. This puts pres-
sure on the team at the end of a long cycle.
Another key event that needs to be planned for in production is the launch
of the game. Because MMOs support thousands of live players in real-time,
24 hours a day, 7 days a week, a solid launch plan must be devised about three
to six months before the game launches. This plan includes information on how
often patches are released, when new content is added to the game, and general
goals for releasing expansion packs. The team handling any issues that occur
after launch (usually referred to as the live team), needs to be assembled and
prepared to handle anything that will occur. The live team generally includes a
QA Lead, Community Representative, Operations Director, Game Operations
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.