CGDC Presentation: The Rules of Online World Design

Brief intro

These are gathered from a number of sources, and we’ve tried to find examples of them from many online worlds in the last twenty years. Special thanks to the many folks whose pithy statements made it into the presentation (Damion Schubert, Dr Cat, Mike Sellers, J C Lawrence, Richard Bartle, Darrin Hyrup, Amy Jo Kim, Randy Farmer et al).

It’s Not Just A Game

It’s a service, it’s a world, it’s a community.

Service:

You are going to have to keep a team on this forever. Otherwise your game will stagnate and die over time. This is an expense you will need to budget for from the get-go. You can use volunteers, but you’ll still need to manage them.

Simutronics

A great job of continuing expansion & development. Note that even a newer engine did not replace the older game—it keeps going.

Neverwinter Nights

AOL shut this down, and received a firestorm of criticism. Shutting down one of these games erodes gamers’ faith that you will run the next one as long as it should be run.

It’s a World, it’s a Community

Many players—your most valuable ones—will not regard this as just a game. The common events such as funerals & weddings demonstrate that amply. If it is treated as only a game, it is easy to migrate out of.

The Well

A discussion site, and email site. But the WELL’s conferences attracted a vibrant community. A female persona there grew to be so popular that when they vanished, a real-life detective search came into being—just to find a man behind the persona, which shocked the community to its core.

LambdaMOO

Julian Dibbell’s cyberrape story in the Village Voice described how a virtual rape can send tremors through an online community. It led to the design of a governmental system within the game, whereby the game’s designers were actually beholden to balloting and voting by the playerbase. He’s got a book coming out about this.

UO’s player-run cities

Player governments, player businesses, player militias, weekly sporting events.

Technical Issues

The following are technical and design factors to keep in mind.

Don’t trust the client

It may seem that people have exaggerated this. It may seem that you can get away with some things. It may seem that you have it all covered. You’re probably wrong. People can and will release handy GUI hack programs that will bypass anything you do client-side.

Light levels in UO

Seemed like a good candidate to keep client-side: send a packet to alter the light level. Ah, but players intercepted the light level packet & blocked it, to allow brightly lit dungeons and middle of the night. The effect of dungeons was spoiled, & hacker players gained a great advantage over non-hacker players.

Diablo

Everyone knows about this one, so ‘nuff said.

If it can be abused, it will be

Some problems seem innocuous. You quickly learn that NO problems are minor.

Habitat

On Habitat, the seminal graphical MUD done in the mid-eighties by Lucasfilm, there were vending machines. There was an economic loophole that allowed players to earn infinite tokens from the vending machines. Eventually, the production of items hurt the server because of database size issues.

Object spamming

On many muds, items are listed textually one after the other on the ground. Older muds did not list similar items on a single line. This led to “object spamming” whereby thousands of, say, fish, were dropped in one room to spam someone’s connection and force them to drop link. “Dropping all” also led to this. Even stacking items does not get around this. In UO we had the problem with people who were creating “black holes” with potion bottles macroing overnight using a 3rd party program. We put in tile limits to get around this problem. Which led to…

Strange creativity

An example of how creative players will get searching for bug exploits: there was a way to delete invulnerable NPCs in UO. You had to create a pile of items that stacked high enough to hit the tile limit. Then they would gate a vendor onto the stack, and force a “restack” by yanking out the bottom item. The result: a deleted vendor.

Static Data, or Keeping the Game Fresh

Static data is the best solution for latency issues, for game balance, for ongoing staffing. But it doesn’t work real well. Why?

Data publication

Any static information you have will be published. Stratics website has a great example of this. Quests on statically designed muds are traditionally published and made widely available. Not very different from the world of unofficial hint guides, only much worse, and MANY times faster.

You cannot keep pace

A good, solidly designed quest that took a month to write will be publicly known within a matter of days. This is just a fact of life.

Player Expectations and Player Retention

The Holy Grail is a low churn rate. This means that you want to keep players in.

The More People You Get, The Versions of What You’re Really Doing You’ll Get

This is an observation by J. C. Lawrence that seems obvious on the face of it, but has a lot of scary implications.

Bartle’s Player Types

Richard Bartle, co-author of the original MUD (with Roy Trubshaw) back in 1979, wrote a paper for the Journal of MUD Research in which he described four player types: Achievers, Socializers, Explorers, and Killers. According to him: you have to cater to all four, or else your game stagnates.

Players Expect More of the Virtual World

They have higher standards for virtual interaction. They expect profit from all labor (the Hula Hoop example). They expect a perfectly trouble-free experience, even though they know there are other players competing with them for resources (kill stealing, camping, etc). And they expect not to be interfered with, but expect to be able to interfere (Playerkilling). Violence is inevitable, the issue is what form it will take.

The Schubert Triangle

Three apexes: Simulation, Gameplay, and Community. A game of all three is ideal; a game of any single one will fail to retain players. Too much sim and the game will not be welcoming. Too much game and it will be shallow and not encourage community. Too much community, and your game becomes superfluous—they could get that in a chat zone after all.

Depth

Depth is the key to an online game’s success. Arguably, Quake has won out over competitors because of QuakeC and player mods and maps, not just its technology. This created ongoing games & a new type of player community.

The More Depth, the Harder to Run

It becomes more difficult to administrate the game as the game gets deeper. The amount of interactions makes rule balancing extremely difficult, and perfectly logical actions (such as normal laws of physics) may result in undesirable activity. Houses in UO, which could be broken into by any number of legitimate means, are a great example (healers ressing through windows, for example). What’s more, these are very hard to fix.

Players will always want more

Meridian 59 had a nice spell system. Players asked for more spell system. UO didn’t have necromancy. Players demanded it, and even complained of broken promises even though they invented it. They want the ability to repair bows, even though they were not designed to be repaired (and it makes little sense to).

The Sellers Hypothesis

Mike Sellers was a design guy behind Meridian 59. His hypothesis is that online games are trying to provide the range of experience that the real world does. None come close yet. But players crave it. And if you don’t supply the depth, then not only will you not retain players, but you’ll start to see behavior that can be described as “sociopathic” or disturbed. A narrow game will not retain players well, and what’s more, they will arguably “burn it down” on the way out (Diablo?)

Dynamic world

Another Holy Grail. Players want the ultimate. We gave them crafting of leather goods, they wanted lacquering and embroidery. We gave them herding of animals, they want animal husbandry and a genetic system for animal breeding. Why? Because they want to shape their space, and leave a lasting mark. You must provide some means for them to do so. Which brings us to…

Ownership

Players must have a sense of ownership in the virtual world. Why? Because, for all we talk about community, social bonds are out-of-character bonds. Players form friendships that migrate OUT of the game. So you have to have ties that tie them to the game proper, rather than to their friends.

Identity

This is the most obvious candidate. Even from the get-go, muds had equipment that allowed players to look unique. Unique appearance, name, history, background, and the like are absolutely key. Even if it’s just a point standing on a rankings chart. But identity is portable in many ways…

Land, houses, barriers to exit

Some way of making a mark in the world is the best way to retain players. A sense of ownership of some part of the virtual space. Player housing has been around on muds for a very long time. MOOs and MUSHes allow player creation of almost anything. This is very important, because there is emotional investment in what is built. But guilds and clans and friends are NOT enough, because entire guilds will defect (Air Warrior & Diablo guilds picked up wholesale to move to UO. The Mercs as an example exist on MANY games).

Strive for “expressive fertility”

Another observation by J C Lawrence. You don’t want to make the game perfect. You don’t want a utopia. You don’t want to make it limited either. You want to provide scope for players to seek their own destiny. Make the game’s features capable of player expression, so that you get a fertile environment in which players can express themselves.

Useful links

This is just a starter list, there’s far more critical study and analysis of online worlds than there is of game design in general.