Tải bản đầy đủ - 0 (trang)
Chapter 18. 'Post-Mortem: Mythic's' Dark Age of Camelot

Chapter 18. 'Post-Mortem: Mythic's' Dark Age of Camelot

Tải bản đầy đủ - 0trang

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

copies.



[ Team LiB ]



[ Team LiB ]



The Community

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 ]



Lessons Learned

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

for help.

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

Worlds

By Talin



Copyright 2002 by Talin. All Rights Reserved.

Used by permission of the author (www.sylvantech.com/~talin).

KEY TOPICS



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

Detection

Verification

Corrective Action and Remedies

Encouraging Desirable Behavior



AUTHOR NOTE

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)

online worlds.

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 ]



.



Tài liệu bạn tìm kiếm đã sẵn sàng tải về

Chapter 18. 'Post-Mortem: Mythic's' Dark Age of Camelot

Tải bản đầy đủ ngay(0 tr)

×