Tải bản đầy đủ - 0trang
Chapter 18. 'Post-Mortem: Mythic's' Dark Age of Camelot
realm-based RvR conflict.
This decision was not taken lightly; we had many discussions where we brainstormed about what players wanted to play.EQ, the most
popular graphical online RPG to date, did not even really offer PvP combat in any meaningful sense. Many players touted that feeling of
safety as one of the primary reasons why they played EQ, instead of other, more PvP-oriented games such asUO. We wanted our RvR
combat to be compelling enough to attract players who wanted to play such a game, but we also didn't want to alienate potential players
who were looking for a more sedate game style. Hence, we hit upon the plan of having safe zones where players could play the game
solely against monsters—where they could group up with other online players in a cooperatively, friendly fashion and adventure together.
Because the game would have three realms, we needed to have three different home areas—one for each realm. However, there would
also be a frontier area that was RvR-oriented; players would make the choice of whether they wanted to fight other players or not by
traveling (or not traveling) to the frontier areas.
Darkness Falls: The Crusade was developed around a good versus evil system where the three realms were Evil, Light, and Chaos.
This was compelling enough for a game of its type, and we started designing the game and working on the game's graphical engine.
Soon after development started, Mythic's president, Mark Jacobs, hit up on the idea of making the game based on the legends of King
Arthur. Having a recognizable background to the game would go far toward making the game more appealing to players. He decided the
game should be situated after the death of King Arthur, in the times not really covered by the legends, and that the game should be
appropriately entitled "Dark Age of Camelot." The only task left was to add the other two realms, and soon Viking Scandinavia (Midgard)
and Celtic Ireland (Hibernia) were added to Arthurian England (Albion).
At the time, we were far ahead of the technological curve. We had already created 13 online games by that point—most of which built up
on the code base of the previous games. In essence, we had been testing our technology—by having it in our older games—for five
years by the time Camelot's development started.
In general, Mythic's pre-Camelot games were separated into two distinct categories: text-based MUDs such asDragon's Gate and
Darkness Falls: The Crusade, and first- (and sometimes third-) person shooters likeRolemaster: Magestorm, Aliens Online, Godzilla
Online, and Spellbinder: the Nexus Conflict. As designed, Camelot would fuse the two technologies together—use the graphical frontend
from the shooters and the server backend from the MUDs.
The first versions of our shooters were software only; most were created before 3D-accelerated video cards became prevalent.
However, our most recent—Spellbinder— was our first 3D-accelerated game. It was built using the Netimmerse 3D API from NDL, Inc.
Because of this, we had a great head start on developing Camelot's client; we had a stable base to start from, which already supported
our messaging and art requirements.
Spellbinder's engine, while accelerated, still needed some major work in order to bring it up to the level that today's online gamer
demands. First, we had to add the concept of "outdoors" to the engine—Spellbinder's gameplay took place exclusively inside castles or
caves. We also needed to add rolling, organic-looking terrain, which again did not exist in Spellbinder. Rob Denton, Mythic's primary
programmer, made it his first task to upgrade the engine.
While Rob was hard at work on the client, Brian Axelson, the main programmer on Darkness Falls: The Crusade, was working on
Camelot's server, ensuring that the database, editor, and in-game tools fromDarkness Falls: The Crusade would work when accessed
from the new graphical client. Eventually, both would be done and would work exceptionally well. With some other code integrated from
Spellbinder (lobby, login, player authentication), we were ready to start content development on the game.
I cannot overstate the importance of this fusion of existing technology onCamelot's timely and stable development. Basically all parts of
the game's underlying systems had been tested for years by their inclusion in other Mythic games. All artists and programmers were
familiar with the tools needed to create content and new features. Once new versions started rolling out for testing, they were stable, and
we could test game balance and other features almost immediately without having to worry about stability.
We assigned co-lead artists Lance Robertson and CJ Grebb on the game. Lance was assigned management and technical art duties,
and CJ was in charge of the game's look and feel. Lance and Rob worked out a scheme for creating player and monster models,
animating them and putting armor/outfit textures on them. Their team then geared up to create figures and outfits, as well as other
in-game models such as houses, trees, rocks, and the myriad of other landscape features that are in the game.
Soon after getting the initial versions of the game running, our lead world developer, Colin Hicks, started assembling a team that would
place the art provided by the artists into the game. His team was responsible for quest development, terrain creation and object
placement, and the general background/stories that defined the player's interaction with the game.
I was responsible for class and race creation, which was made interesting by the fact that we had three separate realms, each of which
had separate races and classes. We didn't want to make the classes the same across all realms, so eventually I (with a lot of input and
help from everyone on the team) came up with 32 different classes and 12 races across the three realms, none of which were exact
[ Team LiB ]
[ Team LiB ]
Soon after Camelot's development started, we got serious about developing a fan base for the game. We enlisted the aid of the Vault
Network, who provided us with some message board space and a moderator. This gave us an outlet to the Internet community—we
could post ideas and updates on the game, as well as entice potential customers with screenshots.
The mood on the fan boards was initially quite dubious—no one had really ever heard of Mythic before, and few thought we could create
Camelot at all. Many other online RPGs had been announced, and most never saw the light of day. The gaming community was
frustrated by this and viewed any announcement of a new title with extreme skepticism.
However, after the game started Beta testing and word got out that the game was actually functional, the boards turned more and more
into a place for players to express their hope that Camelot would turn out well and for them to give us their ideas and comments on the
game design. Eventually we hired an Internet relations manager, Sanya Thomas, who was put in charge of managing the community
and for keeping all of us developers appraised of what the community was thinking.
[ Team LiB ]
[ Team LiB ]
The Beta Starts
After about six months in development, it was time to start testing the game. We identified the fans we thought would make the best
testers and invited them into Camelot's first Beta test. The test would eventually have four stages and would run for almost a year; the
first versions tested had only one realm and a limited number of classes, but as time went on, the game got more and more content.
The Beta test was very important to Camelot's maturation; it allowed players to tell us what was going on in the game, how the different
classes performed, and how the world was designed and set up. We made many changes and tweaks to all aspects of the game during
the Beta period; most were made because of tester feedback.
[ Team LiB ]
[ Team LiB ]
Server Backend Configuration
From our experience with our other online games, we had a rough idea of how many servers we'd need and how much bandwidth
would be required for Camelot. We standardized on Linux as our server operating system, as it was our standard server operating
system for other games. Linux was rock-solid and we had lots of in-house expertise with it. Because Linux runs so well on Intel-based
boxes, we shopped around and settled on Pentium 4 dual-processor Dell boxes. We contacted several PC manufacturers, but Dell
clearly rose above the others in terms of understanding what we were trying to do, as well as providing a great price/service combination.
We had planned on using Oracle or Microsoft SQL Server as the character/account database for Camelot. I had a lot of experience
developing and maintaining Oracle applications from my previous career in the IT industry, so I contacted Sales departments of both
companies and solicited bids. Oracle came back with the ridiculous price of about $975,000, while SQL Server, at $30,000, was more
reasonable. It was still far outside our price range. So, we instead settled on a hybrid of MySQL—a freeware Linux database—and an
in-house-developed flat-file character database. This solution cost us only the development time it took to create the databases; no
licensing fees were required. MySQL manages all account and customer service (CS) records, and the flat file handles all character
information. This combination has worked essentially without a hitch since launch.
[ Team LiB ]
[ Team LiB ]
The Business Arrangement
Almost as soon as Camelot started to be developed, we began to try to interest other companies in publishing it for us. The traditional
relationship between developer and publisher is that the developer handles all design and implementation of the game, while the
publisher handles business arrangements; distribution, advertising, marketing, and so on. Typically the publisher finances the game and
then takes a cut of all profits. For the first year that Camelot was in development, we simply could not interest a company in publishing it,
which left us in a financial bind; we couldn't afford to develop Camelot.
We then turned to the only source of revenue available to us: We sold a minority share of Mythic's stock to Abandon Entertainment, a
New York-based entertainment company. With this sale of stock, we financed Camelot's entire development, as well as some of its
marketing and advertising. It also paid for a booth at E3.
By the time E3 rolled around, we had two of the three realms done and were well on our way to hashing out the RvR combat system. In
fact, our primary focus at the show was to demonstrate our RvR system. By that time—five months before release—it was obvious that
the game was going to be done on time and that it was good. Publisher interest was heating up, but by that time, we didn't need
one—we had the game financed and produced. What we needed was a distributor, so we used E3 to set up meetings with many large
game companies interested in distributing Camelot for us.
One such company, Vivendi Universal, impressed us more than all the others, and we signed up with them to promote and distribute
Camelot. Vivendi has a great system of regional sales; through their sales chain,Camelot has been distributed to just about any retail
outlet that wants to sell it. Vivendi has been a stable, reliable, and overall a great partner for Mythic.
[ Team LiB ]
[ Team LiB ]
It wasn't all roses, of course, during the time thatCamelot was being created. We ran into problems just like everyone else who makes
an incredibly complex game like Dark Age of Camelot. Here's a sample:
We launched without nearly enough in-game and support tools for our CS department to be able to do their jobs effectively. It
took almost a month before we got them the tools they needed in order to answer questions, figure out who was having
problems, be able to see logs, and a myriad of other small utilities. Not having tools of this type made players wait far too long
We had big plans for in-game cities that would be "alive" with NPCs and would serve as hubs for in-game commerce and
player community building. Sadly, it took us far longer to create the cities than we estimated, so we had to launch with only
one city per realm.
Also lacking at launch were dungeons. We wanted many more dungeons than were included with the game at launch, a
problem we are still attempting to overcome. Because cities and dungeons are basically large models that don't use the
terrain system, we ran into many monster AI problems, as well as players getting "stuck" on geometries and even falling
through the floors.
In general, Camelot's development was a wonderful experience. Sure, we made some mistakes, but all in all, the game came out
beautiful, stable, and most of all, fun to play.
[ Team LiB ]
This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register
. it. Thanks
[ Team LiB ]
Chapter 19. Managing Deviant Behavior in Online
Copyright 2002 by Talin. All Rights Reserved.
Used by permission of the author (www.sylvantech.com/~talin).
What Are Some Kinds of Undesirable Behavior?
Why Undesirable Behavior Is a Complex Problem
Why Do People Engage in Abusive or Undesirable Behavior?
Establishing a Code of Conduct
Corrective Action and Remedies
Encouraging Desirable Behavior
Talin is one of those interesting, highly educated thinkers of the gaming industry with many years of experience in
both solo and persistent world (PW) games. Talin left the industry for greener pastures, much to our detriment. He
sees the problems and solutions to "grief" players more clearly than many of us.
This article has been around for some time, but the points Talin makes are still applicable today. Handing this article to
a community management team will probably save them a ton of time, heartache, and grief.
This article attempts to outline a number of strategies for managing "deviant" or undesirable behavior in massively multiplayer (MMP)
What is "deviant" behavior?
Webster's dictionary defines the word "deviant" as "straying from the norm"—in other words, behavior that is outside the envelope of
what is considered customary.
Unusual or idiosyncratic behavior is not in itself harmful and can sometimes be of great value. (The "good Samaritan," as described in
the Bible, was certainly a "deviant" by this definition.) However, when we think of a person who is a "deviant," we typically connote a
This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register it. Thanks
more pejorative meaning: someone whose behavior is somehow perverted, twisted, corrupt, or destructive.
Such "deviant" behavior may not be rare or idiosyncratic at all! If the online environment is such that destructive and abusive acts are
encouraged and rewarded, then such behavior all too quickly becomes the norm.
Thus, we can only speak of behavior being "deviant" in the context of an online world where there is a code of conduct, and in which the
vast majority of players adhere to this code. In this case, "deviant" behavior is simply behavior that violates this code of conduct.
I think it's important to avoid pejorative language, and in particular, "moralistic" language when discussing undesirable behavior. The
issues here can be both sensitive and emotionally charged. It's all too easy for us, as the creators and maintainers of the system, to feel
"besieged" by a deluge of abuse and to think of our less tractable customers as "bad" people. But the line between desirable and
undesirable behavior is fuzzy and often crossed inadvertently and innocently. What may be "bad" in our view may be perfectly legitimate
in the value system of the customer. Many of the violators of our codes of conduct are not "scum" but merely overzealous.
That is not to say that we do not have the right to take punitive action to protect the integrity of our world. But in my view, such action
should be taken dispassionately and without moral condemnation.
I believe that the best policy is to always treat our customers with a high degree of respect, even when they have gone "astray."
[ Team LiB ]