World Design

The scientific view of the real world is that human beings and other organisms are under constant evolutionary pressure from the environment and from each other. The environment was not designed for humans, and neither were humans designed for the environment; this is because there is no “design.” Things got to be the way they are through complex combinations of chance events.

The religious view of the real world is that one or more deities created it. Normally, the deities put the world together before introducing humans into it (rather than creating both at once or the humans first). However, from the beginning, the deities intend to populate the world, and therefore design it with the humans who will live there in mind.

For the real world, you should decide for yourself which of these views is the more correct. For virtual worlds, discount the first one. Deities create virtual worlds; designers are those deities.

You know, when you start designing your virtual world, that it will have players. These are the people for whom you are designing your world. They won’t spend millions of years evolving to fit it; you have to create the world to fit them. The more you know about them, the better you will be able to do this. Therefore, you should look at players first; only then can you look at worlds.

We spent Chapter 3, “Players,” looking at players. Now we can look at worlds.

Scope

The nature of a virtual world’s design is determined by three factors:

• Business. What will it cost? How will it be sold?

• Technical. What can be implemented? How long will it take?

• Gameplay. What will people do? How will they have fun?

These are general terms. “Business,” for example, doesn’t necessarily mean commerce: Even a free, stock, textual world will need an investment of time, and its players still have to come from somewhere.

Using Chapter 2’s, “How to Make Virtual Worlds,” model of a massively multiplayer games development house, “business” covers company leadership, sales/marketing, finance/accounts, and HR; “technical” means software development, operations/IT, art/animation, and support/QA; gameplay is the design team.

This chapter concerns only gameplay.

Typically, business will want the virtual world to have certain features that it considers prerequisites for its success. Some of these just won’t work in a virtual world, and others will be unimplementable. Technical will want a heavily over-specified kit, on which it will implement everything in experimental, beyond state-of-the-art ways. Gameplay wants a world that won’t sell, and that would need more computers than there are atoms in the universe to support it.

There will thus almost certainly be criteria from the business and technical sections to which the designers must adhere. These will vary on a case-by-case basis, but the ones that are most frequently “a given” are

• Genre

• Platform

• Unique selling point

Designers of virtual worlds have very little influence on genre unless they had it explicitly written into their contract when they signed up. Designers of free textual worlds effectively run their own company, so in theory can do whatever they like; the availability of a suitable codebase may force their hand, though.

Nevertheless, within a genre there can still be a lot of leeway. Fantasy and Science Fiction are very broad areas, for example. Even within a license there can be freedom, although as noted in Chapter 1, “Introduction to Virtual Worlds,” some licenses are pickier than others.

Related to genre is the user base. Designers can’t choose where their players come from. Often they have to address a particular market. A virtual world expected to be played primarily by adolescent boys will be different than one aimed at homemakers. An inclusive virtual world that welcomes everyone has balance issues that a world for children aged eight years and under doesn’t. Designers can hope to expand beyond their core player base, but the core itself is often determined from the outset.

The technical platform of both server and client is also a given, although the client more so than the server. This isn’t too bad: Designers look on technology as physics that they can’t do anything about, so they accept it. It’s only an issue if programmers push their luck and claim that things can’t be done that can.

Architecture, however, is a technical consideration that may be imposed for business reasons. Designers are told whether the virtual world will be textual or graphical, and, if the latter, what sort of graphics they will be (2D, 3D). From a purely gameplay point of view, text is better for intimate, intense, imaginative worlds where thought is more important than action and individuals are preferred over parties or clans. Graphics are better for gregarious, large-scale, beautiful worlds where action is more important than thought and clans and parties are preferred over individuals. Designers have no say in which they get.

A unique selling point (USP) is a Big Idea that marketing people feel will attract players and interest to the virtual world. Examples are: “Inter-clan warfare!,” “Pay real money for game money!,” and “A five-year story arc.” Most of these aren’t as unique as the people who think them up like to imagine, and they’re often of dubious worth as selling points, too.

Designers can have a big idea, just the same as anyone else. Be very careful if you do, though. A big idea completely dominates a project, with everything becoming subservient to it. This makes the virtual world one-dimensional, preventing people from having multiple big ideas.

Sometimes, though, a big idea can lead to a paradigm shift. EverQuest may have been dominated by the big idea of having first-person graphics, but benefited because this really was a big idea (albeit one pioneered by Meridian 59).

So, designers will have constraints on what they can design. For the most part, these will be beyond their control, and represent a non-negotiable starting position. Within such parameters, however, designers have absolute dominion. It is here that the virtual world is shaped to their will.

This is the context that the remainder of this chapter assumes.

Major Decisions

Designers can’t leap right in and start work at the nuts-and-bolts level. Although such a “bottom-up” approach may work for smaller tasks, virtual worlds are too complex for this. If you were designing a cruise liner, you wouldn’t start by specifying the décor for cabins. Yes, at some point you would need to do it, but there are other things that are more important; some are even so important that they impact on it (the cabin’s dimensions, its window sizes, furniture access, and so on).

So it is for virtual worlds. Some things have to be decided first, because they affect what is decided later.

Most of these have already been introduced in this book, so now let’s look at them in detail.

Ethos

What kind of a virtual world do you want?

To a large extent, it depends on the players. Where will they come from? What will their background be? What player types will dominate? Why will people eventually leave?

Players bring aspects of their real-world community—their culture—into the virtual world with them. Part of the point of virtual worlds lies in being able to pick and choose what you leave behind. Culture is that which is passed from generation to generation without being inherited; virtual worlds let you rethink what you’ve been taught at every level.

One player may find this a liberating experience and take a more progressive attitude in real life; another might despair of the superficial values and reaffirm their real-life cultural anchors. It doesn’t really matter which: The point is that players must have the option of stepping out of their culture; whether they stay out or step back is irrelevant.

If players do step out, though, what do they step into? It can’t be a wild maelstrom of anarchy, because otherwise players could only interact transiently with one another and the virtual world would not survive. The virtual world must itself have a culture—one supported by its community in general. Sure, it’s not as deep as a real-life culture, but it’s a culture nonetheless.

How does this culture arise? It emerges consensually from the player community. As noted in Chapter 3, this is something designers can shape but can’t control.

The theory works as follows:

• The designer determines an ethos, and fixes the virtual world to reward activities that exemplify this ethos.

• Players who share the designer’s ethos seed the virtual world.

• The virtual world’s design attracts players hopefully compatible with its ethos.

• Thereafter, it’s mainly self-selecting (newbies either take the ethos on board or don’t like the atmosphere and leave).

• The live team can reinforce or undermine the ethos by example.

In practice, designers are often cheerfully unaware of the extent to which they set the tone of their virtual world. They seed it with people whose shared ethos is to find ways to exploit or otherwise abuse the virtual world. Cynical marketing techniques attract players to an image of the virtual world that doesn’t necessarily match the product. Newbies who don’t like the culture damage it before they leave. The live team spends all its time firefighting and doesn’t have the staff to do anything more cerebral ¹.

That said, the exercise isn’t entirely pointless. There may be obstacles piled at the window, but if a single shaft of light gets through it can be enough to see by. A virtual world drawing players from advertisements on first-person shooter web sites will be different from the same software drawing players from advertisements on chess web sites, but some attitudes may prevail in both.

As to what ethos to adopt, well that’s really up to the designer. Be sure you do have one, though; if players can’t sense how they should behave, the law of the jungle applies, and as with any question of morality, different people have different ideas. However, there are some things that are more conducive to the prosperity of virtual worlds than others. Many of these occur in multiple philosophies ² and will usually appear in some form by default anyway. Of those attitudes that don’t, you should probably consider promoting some or all of the following:

• Reality is another place.

• A virtual action with real-world effect is a real action.

• Yours is just one way of many to play.

• There’s no stigma to role-playing.

• Newbies aren’t children.

• Evilness is not a winning strategy.

• It isn’t rude to say hello.

Unending or Circular?

In a single-player computer game, when a player makes a mistake it means a restart from their last save. In virtual worlds, this is impossible—a restart for one player means a restart for all of them. How, then, can a player learn from their mistakes? Do similar situations arise regularly? How about the same situation? Does everything repeat in time, or does the world evolve?

This is basically a change and persistence issue.

Players consume content. There is certain content that they like, and which they are not averse to consuming several times.

Other content they can only really consume once. On the other hand, just because one player has consumed something, that doesn’t mean someone else wouldn’t like to try it. How can these differences be reconciled?

Well, that’s what you have to decide. In practice, you can’t have them all at once: It’s a sliding scale from low change/persistence (circular) to high change/persistence (unending). A fully circular approach reuses content but has nothing new; a fully unending approach abandons used content but offers fresh experiences.

Virtual worlds that don’t change much and don’t persist much have to be sufficiently broad and deep that players take an age to explore them; otherwise, only the activities of other players will provide novel experiences. Virtual worlds that do change or persist will retain players’ interest ¹, but be costly (because new content has to be created ²) and wasteful (because old content isn’t reused). Furthermore, virtual worlds need checks and balances to ensure that all new content is in keeping with the virtual world as a whole.

Virtual worlds that don’t introduce content are called fixed. Whether virtual worlds that do introduce content are fixed depends on whether the content is fixed. A predetermined storyline is not new content; it’s old content that hasn’t been added yet ³. Players have no more ability to change the future than they do in a virtual world that resets every two hours. If storylines are reactive or emerge from player actions, that means the virtual world is not fixed.

Note that by “virtual world” here I don’t mean just its physical geography; anything from its social structures and mobiles to its economy and combat systems can be changed. Asheron’s Call and Anarchy Online both have basically fixed storylines, but the former’s can involve the leveling of entire cities whereas the latter’s (because of how it’s implemented) can’t.

Does the virtual world have a future? If so, who decides it? You get to choose.

Hands On or Hands Off?

Intangible content in virtual worlds will arise naturally through the interactions of players. Designers can and should assist these interactions, by providing tangible means of support and encouragement. How far should they go, though? In particular, should they be proactive to the extent that they provide for live team “leader” players to catalyze these interactions?

In traditional tabletop role-playing games, the referee not only designs the game world but can lead the players through it. Players perceive a highly detailed world because the referee can resolve everything they do, to whatever depth. Referees don’t have to think up everything in advance; they can create some of it in response to the actions that players take.

In a virtual world, the designers have to put everything in to begin with. There’s a bedrock level of detail beyond which players can’t descend. This is most noticeable in the behavior of mobiles, none of which have remotely convincing artificial intelligence ¹. There is, however, something that can be done about this. People could be allowed to play on the same “side” as the virtual world, as an adjunct to it. There is already a community management team; why not allow specialized members to participate in the virtual world in character?

There are several levels at which such characters could operate:

• Undercover. Nobody knows they’re part of the live team, but they make life interesting for other players through what they do. They’re like audience plants who “volunteer” to help magicians ².

• Entertainer. Everyone knows these people are part of the live team, but by their ready wit and repartee they manage to make the world more fun.

• Performer. Players in a Lord of the Rings universe will want to meet Gandalf—he’s part of the package. The live team therefore hires an actor to play the role.

• Guide. “So you guys have never visited the caves of Drachen, huh? Stick with me and just maybe you won’t get hurt too bad….”

• Referee. These are guides that have out-of-context world editing abilities. If a player on a quest decides to do something inventive that wasn’t planned for, the referee can produce a tangible response.

• Unseen referee. The quest is managed behind the scenes. Players don’t know that the reason there’s a key lying in front of them is because they didn’t search the body of the troll and find it earlier.

The hands-on approach is used mainly for manufactured quests. It had been applied for other purposes right from the start: MUD1 had organized events called “spectaculars” that involved much hands-on activity by a wiz-level administrator. Only with plotted quests, however, were the virtues of participant management to become fully apparent. Avalon pioneered this idea commercially in the early 1990s, becoming formalized in Achaea circa 1996. Nowadays, some of the products of the innovative textual world company, Skotos, rely so much on the activities of highly experienced referees (which it calls storytellers) that they would be almost dead without them; with them, however, they are profoundly alive.

If a hands-on style can deliver this degree of immersion while fostering community, why would a designer not want it?

Firstly, it’s expensive. There may be players willing to do it for free, but quality control and time management are difficult to maintain. Also, developers are sensitive to accusations that they are exploiting their player base, and therefore prefer to have people on their payroll ³.

Secondly, the deeper levels of event management only really work in smaller virtual worlds. If there are 2,000 players milling around and 40 referees running quests, it’s harder for them not to tread on each other’s toes than if there are 100 players and 4 referees (despite the latter’s greater density of referees to players).

Thirdly, the players don’t all like it; specifically, the players who don’t get to participate in organized events don’t like it. To an achiever, seeing someone (particularly someone else) go up levels after being “walked” through a quest is galling. Getting help from community management—it’s like cheating! Socializers may view intervention as patronizing. It’s a virtual world, not a theme park. Skotos targets its games at players who do like this degree of personal touch; virtual worlds that don’t may not have the same results.

Fourthly, it’s very difficult to test quests and events prior to running them. There may be unwanted effects (such as bugs) or side effects (such as characters getting frequently killed). Occasional events with wide coverage can be very popular, but they tend to have a greater chance of going wrong, too.

Finally, no matter what spin you put on it, using real, live people to make your content interesting is like an admission of defeat. It says that a virtual world is neither sufficiently compelling to be interesting in its own right, nor sufficiently rich to enable players to make it interesting themselves. Of course, it could be argued that no virtual world is so compelling, but that’s not how designers see it. Besides, professional mourners can spoil a funeral, rather than enhance it.

Categories

Another major decision designers have to make is whether to categorize players or not. In many cases, the question they actually ask themselves is what categories to have, which rather jumps the gun. The categorization of players is not a fundamental component of virtual world design.

Chapter 3 described the differences between classbound and classless systems. There, I argued that a classless system can fake up a classbound one while offering more. Because some players (particularly newbies) can benefit from the provision of predefined character types, I suggested a “character kit” approach to allow them to choose a pseudo-class while retaining the overall flexibility of the classless ideal. Ironically, this means that even if a designer decides against a classbound regime, they could still have to produce something that looks like a list of classes (if only to placate newbies who are expecting to see one).

So what are the usual lines of partition?

The first one is, inevitably, gender. Textual worlds are hamstrung by language in this respect, and graphical worlds by images. Although it is quite conceivable to create a virtual world in which all the characters are of the same gender, it’s nigh impossible to create one in which characters’ gender is merely unspecified without convoluting the language ¹. Gender is probably the only categorization that virtual worlds are stuck with.

Gender is a physical difference, although in virtual worlds it is usually presented as a cosmetic one. The reasons for this are given in Chapter 5, “Life in the Virtual World,” but the basic explanation is that designers don’t want to offend anybody.

Another physical dimension for partitioning players into groups is by race. Given the way that virtual worlds are so politically correct about gender, one would expect that race was also a purely cosmetic issue, but that’s not the case: Races are presented as being fundamentally different, with significant strengths and weaknesses. The reason for this is that what virtual worlds call race, the real world would call sub-species; what the real world calls race, virtual worlds call nothing at all and do treat as a merely cosmetic aspect of a character. Some of the moral implications of this are discussed in Chapter 8, “Coda: Ethical Considerations.”

Races follow stereotypical lines. The short, stocky, bearded axe-wielders who live underground hate the tall, slender, pale archers who live in the forests, and vice versa. Scaled-up humans have more strength than brains, whereas scaled-down humans have more brains than strength. Nobody likes a lizard.

There are common sub-races, too, which also run along stereotypical lines. Fantasy worlds have half-elves and half-orcs, but never quarter-elves or half-dwarfs ², and there isn’t even a word that means the progeny of an orc and an elf.

Because races have physical differences, designing kits for them is tricky. It’s easy enough to make height, musculature, skin tone, ear and eye shape, hirsuteness, and so on be parameters that can be adjusted at character creation time, but this would allow players to customize races of their own—giant, puny, hairy lizards, for example—that didn’t make sense. Representing these graphically may introduce unnecessary complexities, too. For this reason, virtual worlds that must have races (because of their fiction) almost always have to hardwire them in. It’s limiting, but it’s a necessary compromise. Although people who start off as farmers may become politicians, nobody who starts off as a troll is going to become an elf ³.

Related to race is the notion of nationality, or, more accurately, country of origin. This is a less frequently used way to categorize characters, combining them by geographical proximity. The reason it’s not so popular is because players want to move around as their characters progress, to be close to the facilities they need (and things they want to kill). The result is that nations are often only nations of NPCs, as PCs are spread about all over the place.

Although one race may dominate a region, others are not excluded; also, the same race may dominate more than one region. Nationality is best used to engineer social conflicts between large groups of players, and in that sense it doesn’t necessarily play a part in a player’s sense of their character’s identity. However, when nations are typecast it can become a constraining influence. The cultures of the three realms in Dark Age of Camelot are quite distinct.

Beyond the physical and geophysical, categorization becomes harder to justify. The dominant approach is that of character classes, which derives from the old tabletop role-playing paradigm. Skills systems are usually grafted on to this, rather than being independent of it, which is rather a shame.

Both character classes and skills systems are fairly arbitrary: Depending as they do on the nature of the virtual world itself, there isn’t really a systematic way to determine which ones you “need.” I’ll describe the various ways to organize skills in Chapter 5; only in creating the skills will designers get a feel for what character kits might be appropriate. Thinking up the kits (classes) first and then imposing them on the skill set is the wrong way to go about it; I won’t be listing any of them here, but if you want ideas you should look at other virtual worlds ⁴.

The final common way to categorize characters is by alignment. This, too, is an old tabletop role-playing game concept, intended as an aid to role-playing. The idea is that players decide in advance how their character is to behave, and stick to it. If they step out of line, the referee penalizes them. The traditional alignment dimensions (from Advanced Dungeons & Dragons) are law/chaos and good/evil, with the crossing point of the two axes labeled “neutral.” A lawful good character is benevolent and just; a lawful evil character plays by the rules but is without mercy; a chaotic good character is a rebel with a conscience; a chaotic evil character is a self-serving bully who’ll do anything to further their ambitions. There are another five combinations involving the concept of neutrality.

Alignment is a useful concept for soft role-players because it’s moveable. By saying that your character is lawful neutral you’re making a statement about how you intend to role-play that character. If you consistently act good in situations where you could equally well act neutral or evil, eventually your alignment will shift to lawful good. Some actions may be outlawed altogether—paladins don’t get to douse beggars in burning oil no matter how bad they smell.

In tabletop games, the referee determines when alignment violations occur. In virtual worlds, much of what is good or evil, lawful or chaotic, is intangible; it can’t be tracked by the virtual world, therefore it can’t be enforced. If I attack another player, am I being good or evil? What if they had stolen something from me? What if it was theirs in the first place? What if they had attacked me in the past? What if I’d attacked them beforehand? What if I attacked because they’d killed a friend? What if the friend had started the fight and I only think they were innocent?

There is no point in trying to get the virtual world itself to track alignment.

So is attacking another player good or evil? If they’re evil, it’s good; if they’re good it’s evil. Put this way, good and evil are just badges. Players will say they’re evil without understanding in the remotest sense the depths of cruelty that this implies; players will say they’re good without ever having exhibited the slightest tendency toward compassion. They’re just labels: They may as well be green and yellow.

It may be possible to define an intangible concept like alignment ⁵ by asking other players to make judgments in a tangible fashion (for example, by voting). This isn’t without its problems, though: It’s immersion-breaking, it depends on player goodwill, and it’s too easy to subvert.

On the whole, alignment in virtual worlds works only as another shallow, artificial way to partition players into smaller communities. Unless it’s an important part of the virtual world’s fiction, it’s probably not worth having.

Intimate or Grand Scale?

Virtual worlds imbue a sense of size. Players have very definite views on how large the areas they cover are. Asheron’s Call feels bigger than EverQuest.

Size is affected by many factors. The most obvious is the number of discrete points that a character can occupy: A text world with 20,000 rooms will generally feel larger than one that has 500; a graphical world measuring 32K by 32K will feel smaller than one measuring 256K by 256K. Speed of travel affects size: If it takes you half an hour to traverse one virtual world and two hours to traverse another, the former may appear to be smaller than the latter even if it isn’t; if you can teleport anywhere, the world will feel smaller still.

The abstract size of the world being modeled is significant, too, especially in textual worlds. One room may only be 50 moves away from another, but if the locations in between are written to convey an impression of vastness and fraught with dangers and dead ends, players can be left with the feeling of having undertaken an epic journey.

As well as the physical size of the world, there are other features that can indicate its scale—the number of independent organizational substructures (dukedoms, countries, planets, and so on), for example. The reach of these can help convince players how big the virtual world is: If the non-player characters (NPCs) change language or religion, or the currency no longer works, or the buildings have onion domes instead of towers, it reinforces the notion that a place is remote.

Virtual world designers like the idea of creation on the grand scale. The more there is to design, the more designing they can do, and therefore the more fun they’ll have. Big worlds have interesting interactions that small ones don’t; a big canvas makes for more detail.

Unfortunately, virtual worlds can be too big. Scatter 100 people around a regular house and it will seem crowded; scatter them in the Sahara desert and they’ll never find each other; put them next to each other in the Sahara desert and they won’t see more than a fraction of the rest of it.

Virtual worlds have to be of a size appropriate to the number of players they attract. In textual worlds, a rule of thumb is to aim for a rooms per player ratio of about 40; 20 rooms per player is crowded but bearable; 60 rooms per player is sparse but you can still bump into people by accident. It’s possible through design to influence how crowded a virtual world feels—for example, by introducing honeypot rooms or thoroughfares to attract players to the same location, or by starting players near to one another or far apart when they enter the virtual world. In MUD2, I have self-contained flood-control areas that only open up when a certain threshold of players has been reached. On the whole, though, it’s better if you just get the size right to begin with.

Another problem with having a large virtual world is that it needs content. More content means either more designers or more time for them to design in, both of which are expensive. Players would rather play in a world that is small yet packed with interesting things than a world that is large but empty.

As I remarked, actual size does not have to coincide with apparent size. A small world can seem large, and a large world can seem small. A seemingly expansive world will impress relative newbies and give them the urge to explore new vistas; a seemingly cozy one will feel more secure to them and make conversation easier. Designers will therefore use a hybrid approach sometimes, whereby newbies are initially presented with an intimate ¹ environment, then see things on the grand scale when they emerge from it.

The apparent size of a virtual world helps contribute to its atmosphere. The actual size is important to ensure that players meet each other serendipitously often enough to form relationships yet not so often that these turn sour. Ideally, a designer can find such a balance. Sometimes, though, their hand is forced. In particular, if they are writing to a license, they could have problems. The licensed world may be impractically large (for example, Middle Earth) or impractically small (for example, Hogwarts School) for the numbers of players expected ². Designers then have to decide how faithfully to honor their virtual world’s sources. “Inspired by” can work: Dark Age of Camelot isn’t an authentic retelling of Arthurian myth, but is close enough in spirit not to disappoint newbies. However, DAoC didn’t pay money to use its sources; if designers had done so, the pressure to use the entirety of what they had bought would have been great (not least from the license holders wishing to protect the integrity of their universe).

Size doesn’t just pop out of a design. You have to think about it from the beginning.

Purposeful or Decorative?

You look at a wall. Hanging on the wall is a picture. You go up to the picture to remove it and find it’s actually part of the wall. In a textual world, it would be embedded in a room description; in a graphical one, it would be part of the texture for the wall. It’s purely decorative.

Some objects are in virtual worlds for tangible reasons; others are there for intangible ones. Should you give even the intangible ones some tangible purpose, or keep them as the props they are?

It might seem a little premature to decide at the very beginning of a virtual world’s design whether to assign meaning to everything. Surely you can figure all that out later, once the really important things have been done? Well yes, you can, but by that time you may discover that the decision has been made for you: It would be simply too much work to give everything meaning. This is why so many virtual worlds have windows that don’t break, chairs you can’t sit on, grass you can’t pull up, trees you can’t chop down….

If you know from the beginning that objects will all have tangible functionality, it means you can design for this from the beginning. If you know they won’t, you immediately increase the range of what you can design. You’ll have longer to do it, too: Depth eats into design time, but if it’s there from the start, it won’t eat anywhere near as much as it would if you added it later.

An example: Are clothes just costume or are they fashion? It’s possible to analyze what characters are wearing statistically and determine what is and isn’t in fashion. If you wear fashionable clothes, your status goes up; if your status is high, what you wear is fashionable until everyone is wearing it. Non-player characters will treat high-status characters in a tangibly different way than low-status characters. Should this gameplay element be added to push players into making choices about how their character looks? Or should they be free of such tyranny and be able to wear whatever clothes they like? Even those of the opposite sex?

Another example: Should coats of arms be regimented or freeform? Real coats of arms are steeped in symbolism. Should players send their characters to a college of heralds to compose their device from templates? Or can they scan a photo of themselves and use that? In the former case, NPCs could be expected to “read” the meaning and react appropriately (farriers may give a discount to a knight whose shield features a horseshoe; bandit rebels may decline to attack a character whose shield bears a holy symbol ¹). Uploaded images are meaningful to players, but meaningless to NPCs.

In general, designers do want a gameplay meaning for everything in their virtual world, because it makes the world more immersive. If they don’t determine this from the outset, though, they may be unable to have it when they’re at the point they need it (fleshing out the details after the framework has been implemented).

There’s a second issue here, though, which is more contentious. What we’ve been asking so far is whether things that are needed for out-of-context reasons should be given some contextual meaning. However, what about things that are needed for contextual reasons that have out-of-context meaning we don’t want? “I was lying across the tracks when the train ran over me: Why am I still alive?” “Because we thought you might stop playing if you died.”

This tension between what is good for tangible reasons but bad for intangible ones has claimed many victims in the past; it’s sure to claim more in the future. It isn’t only manifested by permanent character death (the virtual economy is the other big loser, and there are many smaller ones), but that’s where the battle lines are drawn ². The problem is that some things are really, really desirable for tangible, gameplay reasons and really, really undesirable for intangible, business reasons. If gameplay wins, business suffers; if business wins, gameplay suffers (and then business suffers).

The general policy with regard to whether gameplay or business imperatives have priority should have been decided when the parameters of the design were set out. For a well-known issue such as permanent character death, this will almost certainly be the case. However, there will undoubtedly be other instances where friction will occur. Be sure that the procedures for dealing with the resulting disputes are in place; you’ll need them.

Closed or Open Economic Model?

The first question you should really ask is whether your virtual world needs an economy at all. They don’t have to have one. If, for example, characters can take nothing with them between playing sessions, not only is an economy unnecessary, but you can’t have one anyway. The more persistent a virtual world, the greater its need for a means to facilitate the efficient transfer of goods between players, but even then this doesn’t imply the worlds need a formal currency. That said, the real world has money and therefore virtual worlds that want to seem real will have money too.

There are two ways to run a virtual economy: The one that designers want to have, and the one they end up having. The former is the closed economy; the latter is the open economy.

A closed model is internally consistent, with inbuilt defenses against abuse. It’s a cycle. Resources are taken from the virtual world at the rate they are returned to it. There is a set ¹ amount of money and a set amount in circulation, although the goods that can be bought with it may increase or decrease in number (that is, the economy can grow/shrink). On the whole, cash retains its value.

An open model is not internally consistent. It’s faucet/drain. Resources enter the system and resources leave the system, but there is no prescribed relationship between the two. If the cash sinks aren’t big enough, then players can hoard money, which therefore decreases its value; if the cash sinks are too big, then players have to spend money, which therefore increases its value.

The closed model is desirable because, done properly, it delivers many benefits ². There is no inflation; market forces control the price of goods; it allows for economy-driven gameplay. On the other hand, it’s very hard to balance, highly sensitive to bugs, not accepted by players, and (most devastating of all) too easy to gouge. Players will attempt to break it, and will invariably succeed.

The open model could, in theory, be balanced. In practice, though, it’s much easier to give characters money than it is to take it from them; rampant inflation is the result. Virtual money rapidly becomes worthless, and players adopt a barter economy instead.

Designers therefore have three options:

• Create an unbreakable closed economy. No one has done it yet for large-scale virtual worlds, but that doesn’t mean it’s impossible. The global economy of the real world taken as a whole is closed.

• Create a managed open economy. Put in checks and balances that will regulate both the flow of the faucet and the outflow of the drain such that if the two aren’t reasonably close to equilibrium, then measures to correct it are taken. No one has managed this yet, either.

• Don’t have a formal currency. Players are going to end up bartering anyway, so throw in the towel and build for a barter economy from the beginning. Perhaps have a throwaway currency that newbies can use, but accept they’ll rapidly be measuring their wealth using floating-point numbers and will then switch to the formal barter economy.

We’ll discuss these particular ways of handling virtual world economies later in this chapter.

There are other ways to look at economies, of course. Some, such as gift exchange, are promising but as yet unproven; they may work as part of a more general economy, but don’t seem strong enough to work alone.

A perennial favorite is to integrate the virtual economy into the real one. This does have merit—it works for the textual world Achaea ³, for example—but there are limits. Few players will object to another player paying real-world money for an item to be given properties that have no gameplay value. For example, a rich player could pay several thousand dollars to have a customized sound played whenever they unsheathed their sword. Other players may find it amusing, tacky, or “unfair” (that is, they’re jealous that they can’t afford something similar). However, if the sword doesn’t do any extra damage or convey any tangible benefits it didn’t have anyway, that’s fine.

Intangibility is the domain of the real world; paying real money for something intangible is justifiable. Paying real money for a tangibly better sword is another matter entirely, though; virtual worlds hoping to use exactly this as their business model should pay very close attention to the likes of Achaea to see how to do it—it requires some very careful balancing and only attracts a certain breed of player. Designers intending to extend the model by letting players take real money out of the virtual economy (Project Entropia ⁴ is the trailblazer here) have considerable cause to worry—even if they do by some miracle manage to get their virtual economy to work.

The final point to make about a virtual world’s economy is that at an abstract level ecologies work the same way. If you have a closed economy and open ecology (or vice versa) you should ask yourself why one works in closed form and the other doesn’t.

Information Versus Immersion

Which is better: to tell a player they hit a troll really hard, or to tell them they did 25 points of damage? The former is what the character would see; the latter is what many players want to see. If they do see it, though, it works against immersion: In the real world, you don’t see numbers appearing every time you hit something with a hammer, so why should you in the virtual world?

The last of the major decisions that designers have to make about their virtual world is the degree to which immersion should be sacrificed for the benefit of players’ spreadsheets. It’s easy enough to say, “Oh, let the players themselves decide,” but there are limits. Also, designers get to determine the default; what newbies see can have a lasting impact on the culture of a game.

The trade-off between information and immersion uses a sliding scale that can be split into three zones:

• Immersion always wins. Players don’t get to see the code that dictates mobile AI, and that’s final.

• Players choose. Some will see it as “the red bag,” but for others it’s “bag002.”

• Information always wins. You’re told the name of the nearby character, whether or not your own character has ever met them before.

Designers set the boundaries. Although the middle zone allows for multiple settings (“I want to know how much I’ve been hurt, but not the true names of objects”), in practice it works fine as a single, binary setting.

Again, the reason that this seemingly mundane decision assumes unusually high significance is because by the time it becomes an issue it’s normally too late to do anything about it. During testing, everybody wants as much information as they can get; the capability to switch it off can be left almost as an afterthought. It needs to be determined right at the beginning.

Players want to see numbers (or stats bars or labels) because it helps them play. Information given in more circumspect ways is an unnecessary encoding. Everyone is eventually going to get the data they want anyway, so why try to hide it? Once numbers are accepted as part of the virtual world then surely they won’t thereafter disrupt immersion? In the real world, some objects do have numbers on them: If I buy a bag of sugar, its weight is written in bold letters on the side; if I buy a car, it has a license plate that identifies it uniquely. Freedom of information is good.

Isn’t this obsession with “immersion” just pretentious nonsense?

In some respects, a designer’s decision of whether to favor information or immersion is a partial statement of their design philosophy. Players want information for achievement and killer purposes (explorers like it too, but then they also like deducing it when it’s not provided). If you give numbers to newbies, you’re telling them that this is a virtual world that they should take by the scruff of the neck and make their own; if you don’t, you’re saying it’s a mysterious, perhaps dangerous place, where knowledge reveals itself only through experiment or the experience of others ¹.

Decide what you want to tell them and why. Then tell them.

Geography

Authors of epic Fantasy novels often start with a map. Similarly, designers of virtual worlds often choose a map as the first concrete realization of their dreams. In any venture that has place or travel at its core, a map is the natural starting point. In constructing a map, not only are ideas given form, but new ideas are suggested. It’s unlikely that a designer will create a map only to go back and change it later to account for details that have arisen from fleshing it out. The design process rarely backtracks over maps, and therefore they’re an excellent way to begin developing content.

Virtual worlds have a more practical reason for doing maps first, in that there are technical constraints in operation. If the programmers insist on a zone-based approach, for example, that directly affects the topography of the world; if the designers want 200 zones, that affects the topography of the network the operations team has to support.

Geography is therefore where designers usually begin to turn their concepts into (virtual) reality.

Geographical Consistency

Throwing paint at a blank canvas does not create the geography of a virtual world. To be immersive, everything should be where it is for a reason. Much as a designer might relish the prospect of creating their planned Magic Shoppe that’s bigger inside than it is outside ¹, at this stage it’s only ever going to serve as a prototype to demonstrate the principles involved. Although not a bad thing in itself (actually, it’s quite a good thing—I usually recommend it to newbie developers), piecemeal development of individual structures is not the way to get a whole world. For that, you have to take a more top-down approach, through various levels of abstraction.

These levels (from most general to most specific) are

• The world

• Zones

• Regions

• Areas

• Rooms

Although in technical terms there may be a multiverse of parallel worlds (that is, different shards/incarnations), this is not something that directly affects the geography of a single such world.

The layout of a world depends, naturally, on its genre. A “world” for a space opera might consist of several planets; one for a prohibition-era gangster game could be a single city. At this level, the main geographic features are placed so as to make sense. Depending on the scale, this can mean suns, moons, oceans, continents, rivers, mountains, deserts, forests, parks, freeways, roads, and so on. The main aims of the designer are

• To create a believable overall map. Rivers run from mountains to seas; forests don’t appear in deserts; cities aren’t built on glaciers.

• To partition the world so that it can cluster players. The world may be huge, but you still want people to meet up (but not so much that they never go anywhere).

• To allow for the world to be extended, both internally (“Where can I put the new sponsor’s coffee shop?”) and externally (“Where do I put the expansion set?”).

• To have room for some ideas you want to put in. “I’d like a city on the edge of a desert, so I guess I’ll need a river or a major oasis or no one would have built a city there.”

• To provide for a meaningful ecology and (through resource placement) economy.

• To be attractive to more than one player type. Just because a place is a slug-fest, that doesn’t mean interesting flowers can’t grow there.

• To give themselves ideas. “Hey, that mountain lake would be perfect for a mystic kingdom of martial arts experts!”

Interestingly, these same aims (apart from external expansion) apply at all the other levels of abstraction, too. “Hey, that ox-bow lake would be perfect for a rowboat-leasing facility!”

Geographical consistency can be achieved in a number of ways. If spending a few hours learning about plate tectonics will help you place mountain ranges and volcanoes accurately, do so—your players will appreciate it. If something doesn’t make sense, there should be a very important reason for it not to do so. A player who wonders why there is a perfume factory in the middle of a quiet residential area ² should be able to figure out it’s a front for a bootleg distillery, rather than sloppy work by a designer. If something doesn’t make sense, it should fail for a reason that does make sense.

An obvious way to get guaranteed geographical consistency is to replicate parts of the real world virtually. This is particularly useful for non-game applications, where teaching or exploring a real location might be a primary aim (“Welcome to Virtual Venice!”). Fictional worlds that use real-world settings are more problematical. It can be argued that depicting an environment with which players are already familiar is good for immersion (players already know and understand it); however, unless the depiction is highly accurate, it could be bad (incorrect or missing details will jar against the player’s knowledge of reality). There are problems of data-gathering and data-maintaining, both of which are expensive, and if recognizable real-world buildings appear, there could be legal issues (a virtual bordello set up in a virtual building, the real-world twin of which is occupied by a mosque, would bring all kinds of real-world laws to bear). Another problem of using the real world to give authenticity to the virtual world is that it may not be authentic in the context: A post-apocalypse Washington, D.C. would be unlikely to contain many of its most famous monuments, for example.

Unless the designer is trying to make some kind of artistic point, replicating recognizable parts of the real world in the virtual world is usually a bad idea. As a rule of thumb, keep real-world proper nouns out of virtual worlds.

If you want geographic consistency, use the levels of geographic abstraction.

Levels of Geographic Abstraction

Geographers have many different ways to look at this and other real worlds. They’re experts, after all. Most players of virtual worlds are not geographers, however, and they’re only going to notice more obvious errors. A degree of knowledge beyond that of the average player is always a good thing for a designer to have, of course, but as soon as players stop noticing what you’re doing you can stop. Immersion is about not busting players into reality; it isn’t about teaching them erosion patterns for sedimentary rocks ¹. From this point of view, the levels of abstraction listed in the previous section are sufficient to give a virtual world all the geographic consistency it needs. Let’s look at them in more detail.

Zones are a functional partition of the virtual world, imposed for technical reasons. Not all virtual worlds will have them. Their usual impact is to consolidate geographical features into zone-friendly blocks. The mountain range will stop short of a zone boundary, rather than poke a couple of foothills across it; the river will run through a zone, but not weave over zone boundaries and back; the peninsula will jut out just far enough that it won’t entail a zone change to reach the end of it.

Zones are like the pages in a road atlas, except that you get to change the geographic features so they’re a tidy fit.

Regions are large swathes of territory that have distinct, thematic differences at the strategic level. “The north,” for example, may be cold, populated by hardy, hairy, expansionist barbarians; “the isles” may be beautiful, lazy paradises whose inhabitants have a penchant for human sacrifice; “Westside” may be a neighborhood full of big houses with pools and long driveways, populated by rich people who have nothing but contempt for those born across the river.

Regions fit natural geographic boundaries. If they spill across such a boundary, it’s a cause for conflict. In worlds that have zones, the two often coincide; this is because players feel zone boundaries with the same (if not more) intensity that they feel purely geographical ones. The zone/region relationship is not necessarily one-to-one—you can have several zones to a region or several regions to a zone—but it’s usually integral; you won’t find 1-region zones very often.

Areas are subdivisions of regions that, while thematically similar at the strategic level, are thematically distinct at the tactical level. “The north” may consist of “the mountains,” “the valleys,” “the frozen waste,” “the isle of the gods,” “the lava pits,” and so on. It’s often the case that areas are specified fully by individual designers, to ensure an atmospheric consistency within each area.

Areas are made up of rooms. This is the level at which players experience the virtual world. The definition of what constitutes a “room” depends on the way the virtual world is displayed to players. The options are

• Nodes

• Co-ordinates (tiles)

• Co-ordinates (polygons)

Nodes are points with (potentially) unlimited connections to other points. These are the dominant paradigm for textual virtual worlds, although some also use co-ordinate systems. Normally, a single node represents the smallest unit of position that players can share, which (in buildings) would be a room—hence the name.

Formally, tiled co-ordinates are nodal systems that enforce a rigid relationship between the nodes; you can, in theory, represent them as freeform nodes. In practice, though, tessellation is used because it can be implemented easily with an array. There are often other contributory reasons, but its mapping to a fast, random-access data structure is the main one. Arrays allow for automatic content generation for speedy, shortest-route path-finding and (most importantly) for display as (2D) graphics.

Textual virtual worlds that use tiled co-ordinates will usually give the tiles the same status as other nodes—that is, treat each as a room that more than one player can potentially occupy. Graphical virtual worlds go for a smaller granularity, with a tile representing the space that an individual character takes up; for this reason, they are single-occupancy only, and a subjective “room” consists of contiguous tiles bordered by ones that contain walls, doors, windows, and other architectural features.

Both the nodal and tiled approaches define a virtual world in terms of space. Polygons define it in terms of enclosures. Characters do occupy co-ordinates, but their world is defined in terms of barriers—planes through which they cannot move. As an analogy, consider a piece of graph paper: Nodes define the lines by numbering the squares; polygons define the squares by numbering the lines.

Virtual worlds that use co-ordinate systems can be displayed graphically. The resolution of the co-ordinates in a polygonal system is yet smaller than that in a tiled system, because characters themselves are made up of polygons. The concept of a “room” still exists, as an enclosed space that many characters can occupy, but it’s not atomic: Characters can be between rooms, in some kind of transition state; for a nodal system this location would itself constitute a room.

Of the three, a tessellated system is the least flexible. It doesn’t have the resolution to handle details; in particular, it doesn’t get along well with curves. Carefully drawn texture maps can create illusions of curves, but they’re exposed if players ever do anything to them (for example, walk on what looks like a gentle curve but is actually a step).

When 2D is used, it’s normally because it’s relatively easy to implement, to animate ², and to upgrade ³; it’s often the first choice for hobbyist virtual worlds such as Furcadia ⁴. This may change as cheap or free full 3D engines become more available ⁵, but some people prefer the “pieces on a board” look and the clear demarcations of space it offers; the 2D approach is therefore unlikely to go away.

A world made of polygonal planes better represents different facets of an environment, because of its higher level of detail. You can easily rotate large objects through arbitrary angles, not just 90 degrees. Curves still have angles, but these are small enough to hide behind texture maps without looking fake ⁶.

Node-based systems are the most flexible of all, because they allow for non-Euclidian geometry. In a nodal world, you can exit a room to the north to enter it from the east; you can walk into a wardrobe and find Narnia there; you can be inside a room that contains itself; you can have multiple exits leading to the same entrance; you can reconnect or destroy nodes, leaving a sealed void.

The most immediate benefit of a nodal approach is that you don’t have to use a constant scale. A journey to the top floor of a tower can take as long as the journey across a mountain range. Important details can thus be given close attention, whereas unimportant ones can be dismissed as part of a broad sweep. The world can focus on what matters, matching the way that a cognitive map built up in a player’s mind works. Worlds founded on a co-ordinate system are limited to real-world physics, and don’t have this level of refinement. On the other hand, they can be represented graphically, which can’t be said of an unrestricted nodal system.

An issue affecting all these approaches is what to do at their edges. If you keep walking east what happens? There are a number of tried-and-trusted ways to deal with this situation:

• Wrap around. If you go east forever, you end up back where you started—just like with the real world.

• Physical boundary. There’s an unclimbable cliff, unswimmable river, unnavigable ocean, impassable forest in the way.

• Big stick. If you walk too far into the desert, the sun is going to bake you dead no matter how well-prepared you thought you were.

• Emotional boundary. Your character “doesn’t want” to go any further. You might, but you don’t control your character.

• Notice. If you try to go too far, you’re given a polite message explaining that the designers have failed to provide the necessary content.

• Invisible wall. There’s no explanation, you just can’t move off the board.

Of these, the physical boundary is the most popular as it’s within the context of the virtual world and leaves open the door to further expansion. Unfortunately, it’s so popular that its expression can lead to cliché. “Hmm, the sea. Looks like I’ve reached the western edge of the map, then.” There is a great opportunity for imaginative solutions here.

Terrain

Terrain is what geography is made of. It also has levels of abstraction, matching the needs of the thematic levels. Someone designing a region might decide to place a forest; someone designing an area might decide to place a wood; someone designing a wood might decide to place a tree. Terrain is the paint that depicts the image a designer wants to convey.

The different types of terrain that are available to a virtual world depend on that world, of course. Swampland isn’t necessary for a virtual world set entirely indoors, for example. Tempting though it is to go straight to an atlas and look at the symbols it uses, there are more scientific ways of determining terrain that allow for more realistic tangible effects. For a generic, outdoors, continent-scale kind of virtual world, the following dimensions are likely to be more useful:

• Elevation

• Surface geology (rock, soil, water, sand, and so on)

• Vegetation (none, grass, scrub, cultivation, trees, and so on)

• Cover (none, snow, ash, and so on)

• Volume (air, water, mist, and so on)

Thus you can have a hill, a forested hill, a snow-covered, forested hill, and so on. The particular types of forest would depend on the level of abstraction (jungle, mangrove swamp, pine, oak, whatever).

Explicitly representing each layer allows for a virtual world to give different terrains different properties. Graphical worlds benefit the most from this as they need the texture maps, but they can use them for other things, too (movement speed, footprints/footfalls, ambient sounds). However, even textual worlds can profit from giving rooms a terrain property: Trivially, if you drop a glass bottle on a paved road, it’ll shatter; if you drop it on a sandy beach, it won’t. Multi-layered terrain will also allow you to spot incongruities, such as underwater snow, but to be honest anyone stupid enough to do something like that is going to be too stupid to check for it anyway.

Ah, yes, weather…

The first time I went to San Diego, U.S. customs hauled my bag out of the X-ray machine and made me open it because they couldn’t figure out what I had in it. The object perplexing them turned out to be my umbrella.

I’m from England. We have weather in England. Weather affects terrain. Calm seas can become rough, trees in forests can sway, snow can turn to slush, grassland can become marsh, streets can turn to rivers, hail stones the size of golf balls can appear with no warning in mid-July and set off the alarms of every car parked within a square kilometer ¹. A persistent world with a climate appropriate to its geography is more believable than one that’s the same the whole year round ². You don’t need a sophisticated model to decide the prevailing winds, the temperature, and therefore the cloud cover and likely precipitation. Just because it’s always blazing sunshine where you live, that doesn’t mean it should be like that in your virtual world. Those lush green pastures have to get their water from somewhere.

The second time I went to San Diego, I left my umbrella behind. It rained so hard it stripped the paper off billboards. The locals were unfazed, as it had been forecast for two weeks. Augh!

Using a systematic approach to terrain makes moderating the effects of weather much easier. It has another, equally nice feature, which although not yet used a great deal could nevertheless be the answer to some designers’ prayers: implicit terrain.

In Lord of the Rings, all the action takes place in just a few regions. Vast swathes of Middle Earth are not affected by the conflict to any great degree. If you were designing a virtual world in this setting, you’d want to ignore those places the players weren’t going to be interested in and concentrate on those they were. Unfortunately, the result would be rather patchy. In players’ minds, maps should at the very least be rectangular; if they’ve read Lord of the Rings, they’d expect the virtual world to match the maps in the books, too.

Content costs money. Even mundane content costs money. There may only be one or two sites of interest in the Misty Mountains, but if the entire map were being represented virtually, then some designer still has to place every tree on every slope leading to every jagged peak in the whole range. That’s a lot of effort, just to pacify the occasional player who wanders by.

The overall map shows what the general terrain in a region is, even down to the area level. It’s only when the map has to be realized as actual polygons that its creation becomes tedious. This is where implicit terrain comes in.

Implicit terrain uses a guiding terrain type (that of its area) plus a random number seed (based on its co-ordinates) to generate actual terrain on-the-fly. When a player enters an area, only then is the content for it created. Any changes made by the player (for example, burying treasure) are recorded so as to supersede the implicit definition, but everything else can be discarded after the player leaves. It’s less efficient in implementation terms than an explicit representation, but more than makes up for this in designer efficiency. Random mobiles can be created for an area to spice it up, but on the whole they are only there because players are passing through and would notice if they weren’t. Having terrain that’s defined in layers makes for easier fractal area generation than terrain that’s defined by natural language terms ³.

Most designers won’t have this problem of a map that’s too big. However, that doesn’t mean implicit terrain can’t be of use to them. In particular, it can step in to generate content whenever a player walks off the map. Players can be dissuaded from going too far by including ever-tougher mobiles, but then it doesn’t really matter if they do go on forever—the geography can always be generated for their co-ordinates. It won’t be compelling content, of course, but it removes the problem of clichéd boundaries. If you’re doing a virtual world set in space and you want an infinite universe, well, you can have one.

Movement

Movement in virtual worlds is, strictly speaking, merely a specific form of object state transition. Because it’s the tool that players use to construct their cognitive map of the environment, however, it has enhanced significance—at least in the minds of players (which is what designers are designing for). The geography of virtual worlds must account for how players will build it in their heads, which depends not only on what they see but also on how they see it. Because virtual world geographies are too big to experience in a single event, movement heavily influences both.

So, let’s take a brief look at the various ways to move through virtual worlds, and consider the geographical ¹ implications.

Basic movement occurs between contiguous locations. These locations will either be nodes or points. To transfer from one location to another, players must issue a movement command (or, in rare instances, fail to issue a cease-movement command). There are four main ways to do this, none of which are mutually exclusive (that is, you can have them all if you want):

• Absolute directions. These are the classic ones that use the points of the compass. North, northeast, east, and so on.

• Relative directions. These treat the character as the point of origin, and align with their line of sight. Left, right, forward, and so on.

• Contextual directions. Commands have different meanings depending on the context. In, out, back, and so on.

• Landmark directions. These move you toward a location that contains a major feature. Swamp, tower, shop, and so on.

Most textual and 2D graphical worlds favor absolute directions. Most 3D graphical worlds favor relative directions.

Absolute directions are preferred in textual worlds for three reasons:

• Room descriptions don’t have to take into account the point of view of each character. Note that if this is why you want absolute directions, you can’t simultaneously have relative directions.

• Absolute directions are much easier for players to map with than relative directions. Players prefer them, when given a free choice of which to use.

• In English, the four main compass points have unique, single-letter abbreviations; the four intermediate points have unique, double-letter abbreviations. None of these clash with other abbreviations for common commands. Abbreviations for relative directions are clunkier (“sl” for “slide left”) and they do clash with other common commands (“l” could be either “left” or “look”).

2D virtual worlds use absolute directions because they present a fixed view of the virtual world. They may allow 90-degree rotation, but it’s always clear which way is north. 3D virtual worlds present the player with a character’s eye view of the environment, therefore all movement is relative to the character’s line of sight. Absolute direction may be determined from a second, “radar scan” panel, but then again this could use relative directions too.

It’s possible to track absolute directions from relative ones, of course, but it’s tedious. Given that most players prefer absolute directions so that mapping (real and cognitive) is easier, absolute directions should usually be provided as a convenience ². Yes, relative directions are the more realistic (no one has a compass stapled to their nose), but if you insist on having them then expect players to get lost.

Getting lost is the main issue that virtual geography must address. Although occasionally losing your way isn’t necessarily a bad thing (especially if you’re exploring), if it happens often it means that players haven’t been able to build a working model in their heads of how the virtual world is laid out. Such confusion causes frustration (which is bad enough) and further it suggests to newbies that the whole system is confusing (which is worse). If a virtual world is so badly designed that you can’t even walk from A to B without getting lost, what chance is there you’ll be able to figure out spells or combat or the manufacture of horseshoes?

In order not to get lost, a player needs to measure two things: distance and orientation. In nodal worlds, distance is a problem because it’s measured in rooms, not in unit lengths. It’s possible to go north, east, south, and arrive at the same location as if you’d gone east five times. Worse, you could go northeast and southwest and not end up where you started. For this reason, contextual and landmark commands are used, so that players can get back to somewhere they know relatively easily. Most landmark commands are hardwired into the virtual world, but actually there’s no reason why players shouldn’t be able to create their own. Route-finding algorithms are fast and efficient, and as long as they don’t check things a player couldn’t know (such as whether an intervening door is open or locked shut) it should be fine to allow potentially any static geographical feature to be used as a landmark.

Graphical worlds satisfy the distance criterion for not getting lost, but they don’t deal with the direction one very well. Furthermore, they don’t normally have the interface to allow explicit lost-busting contextual or landmark commands, relying as they do on mouse and arrow keys ³. If they want such commands, they have to provide them implicitly in the environment. Players go “into” a room because there’s a single door. The tower is a “landmark” because it’s the tallest structure for miles around.

Landmarks are important because players use them as reference points ⁴. Not all reference points are landmarks in the “being highly visible” sense, though. Inns, underground caves, shrines, sunken oases—people may well regard these as points of reference, but not see them until they’re close up. In this event, graphical virtual worlds should provide players pointers to show directions: Roads, rivers, and (of course) signposts can help in this regard.

Some environments are more likely to get players lost than others. The main culprits are:

• Featureless landscapes, such as deserts.

• Landscapes packed with similar features, such as forests.

• Landscapes that frequently change. “The hills are alive!”

• Deliberately disorienting “crazy angle” vistas designed to convey alienness.

• Landscapes you have to traverse at speed with sudden, arbitrary direction changes. “Velociraptors! Run for your life!”

• Twisting, turning, irregular passageways. Mazes you can’t steer clear of are not fun.

If you don’t want people to get lost, avoid these. If you can’t, then be sure that entering them is optional.

So far, I’ve only discussed contiguous movement. Characters also regularly travel using discontiguous movement—that is, teleporting. This is like moving using landmark directions, except movement to the landmark is instantaneous. Teleportation has implications for several aspects of virtual worlds (particularly the economy), but we’ll just look at the geographical ones for now.

One of MUD1’s most influential early players, Mark Longley, used to go to London by train fairly regularly. On arrival, he’d take the underground to the stop nearest whatever museum, exhibition hall, or Science Fiction bookshop he was visiting, walk the short distance to his destination, then return the same way. He once explained to me that his geographical knowledge of surface London consisted only of disconnected small areas within a short radius of underground stations, and it was quite a surprise when he looked at a map and discovered just how close some of the stations were in real life.

Virtual worlds with teleports are like Mark’s version of London. They may be huge and packed with interesting things, but if people can use portals, then they’ll never see anything any distance from one. The fact that most virtual worlds (unlike London) rarely have anything worth seeing on the walk between portals only compounds the problem. It’s not so much a virtual world as a collection of virtual sub-worlds.

This may be okay with some designers. Content can gravitate toward portals in the same way that burger restaurants gravitate toward road intersections. It does, however, mean that much cohesion is lost, and it can greatly reduce the sense of awe that players experience on visiting a place for the first time. Atmosphere relies as much on anticipation as it does delivery; enchantment is enhanced by surprise, not by guide books.

These problems can be alleviated to some extent (at least in graphical worlds) by the use of better fiction that makes travel faster but not immediate. If characters can increase their speed by riding on a horse or taking a boat ride, they get to see the local terrain and will arrive at their destination with a better idea of where it is. Failing that, travel could proceed while the player is offline: Tramping across salt flats is boring, but if your character does it while you’re asleep in the real world, what’s it to you? Travel this way doesn’t have to be dangerous—it effectively works by “slow portals”—but at least it gives an idea of how far you’ve traveled (if not exactly where to).

So, when designing your virtual world’s geography, remember that people will have to experience it. Give them landmarks, give them maps, give them co-ordinates if you must—just make sure, however you do it, that they know where they are. Then, they can decide where to go.

Settlements

Many virtual worlds contain virtual buildings. Although some of these may be isolated (farmhouses, cottages, wizards’ towers), worlds created to a bigger scale will want settlements.

Settlements in this context are collections of buildings (or one huge building with lots of rooms—a castle, say, or a space station). Most of the time they will be occupied, but ruined settlements are also possible.

It should go without saying that settlements are positioned where they are for a reason. Virtual worlds are more believable if their settlements are built in locations that make sense. A town with no access to fresh water or no trade routes to other settlements will cause anyone who gives them a moment’s thought to raise an eyebrow. Unfortunately, many designers are oblivious to such formalities. They’re quite happy to put a ruined city on the side of a mountain and say it’s the site of a massacre of humans by dwarfs, but they’re less concerned about what the humans who lived there would have eaten.

There are many reasons why large-population cities in the real world are built where they are. Most grow from smaller settlements, although some are founded by rulers (for example, Baghdad, Munich, St. Petersburg, Washington D.C.). To prosper, all of them need

• Plenty of level ground

• Access to food and water

• Nearby building materials

• A non-threatening climate/geology/geography

• Communication links

• A population

If they are close to natural resources and are in an easily defensible position, so much the better.

Note that for many virtual worlds, some of these criteria are not necessary from a strictly gameplay point of view. Food and water are only needed if characters need to eat and drink; characters are generally impervious to the effects of climate; communication is often instantaneous. Indeed, people may only want to have a house at all so they have somewhere to store their stuff. That’s not how real-world settlements form.

For virtual worlds designed under license, settlements have to appear where the map says they do. Even so, it doesn’t necessarily hurt to put roads, springs, forests, and cornfields in the vicinity. Designers of other virtual worlds have more freedom to put cities where they want, but more responsibility to put them somewhere non-idiotic. As with many aspects of virtual world design, the key is to do your research: A few hours spent skimming through a textbook for first-year Town Planning undergraduates will give you the rudiments of settlement organization (which are all you need). With a virtual world, you don’t only get to place a settlement where you want it in relation to other settlements, but you can change the geography to accommodate it. There really is no excuse for carelessness. The usual rule of rule-breaking applies: If a settlement is in a place you wouldn’t normally find a settlement, there’s some in-context reason it’s in such a place (for example, the religious inhabitants don’t want contact with outsiders).

Note that smaller virtual worlds, especially ones that don’t have a high degree of persistence, may use social places, such as inns, as hubs (rather than resort to full-blown settlements). The placement rules for these will differ, but they’ll nevertheless still exist; don’t just plunk them down anywhere.

Given these basic laws for positioning settlements (or whatever), the next issue is applying them to derive the configuration that designers want. Settlements invariably serve some gameplay purpose; they’re not there merely to provide yet more background color. Although some locations are so natural that a settlement just has to occupy them (the estuaries of major rivers, the heads of deltas, the desert oasis on a major caravan route), the positioning of the rest depends on what designers want out of them—in particular, whether or not they want players to visit them. Often, settlements will be centers of trade, where players can go to sell their stuff and buy better stuff. They’re also frequently places where players get quests. Thus, they act as focal points and can foster a sense of community; in worlds that allow for property ownership, they can become the physical embodiment of communities.

If there are too few settlements, players will crowd out the ones that do exist. It’s less of a problem if there are too many, as players will gravitate to just a few and leave the others as testimonies to designers’ wasted time.

Ideally, settlements should fail or flourish by a process of survival of the fittest. At a superficial level, this looks easy: The ones that players frequent should expand to offer new opportunities and services; the ones that are forgotten should atrophy away to become ghost towns. Unfortunately, this is easier said than done: The majority population of most settlements consists of non-player characters, who won’t necessarily be easy to move (even from a purely implementational point of view). More worryingly, they could look useless but perform an important function indirectly. For example, players may never visit the mining town but if it produces all the iron that the artisans in the big city use to make armor, closing it down would be a mistake. In a sophisticated virtual world with interlinked economies, ecologies, and communities, measuring the success of a settlement merely by the number of player-occupied houses is not enough.

Should players be able to build their own settlements? This would allow for them to appear spontaneously where designers (deliberately or otherwise) left a hole. Ultima Online allowed it from the beginning, but other virtual worlds can have technical reasons for not permitting it: Asheron’s Call only lets players buy prebuilt housing, for example, because its long-term story arc could suddenly call for a volcano to appear beneath a shanty town otherwise. On the whole, though, player-built settlements are simply too powerful a retention tool to dismiss; for long-term persistent virtual worlds, if player-created settlements make any kind of sense at all then designers should aim to facilitate their creation.

This isn’t actually as easy as it sounds. Virtual worlds need virtual inhabitants as well as real ones. Settlements that don’t have NPCs in them won’t be as functional as those that do. From where do they acquire their denizens?

There are three main ways to do it:

• Sleight of hand. When the settlement reaches a certain size, NPCs appear. Other than in defining the boundaries (and therefore size) of a settlement, the only disadvantages of this to speak of are that it isn’t exactly convincing and it can lead to NPC inflation (that is, the more NPCs there are, the less the value of each one).

• Bought in. With these, buildings that operate services come with their own staff. If your community clubs together and funds the construction of a cobbler’s shop, it comes automatically with a cobbler. This is marginally more realistic and allows for a greater variety of towns, but can still lead to NPC inflation. If every town builds a cobbler’s shop, how does this affect the price of shoes?

• Economics. NPCs periodically look at how their business is going, and if it’s poor, they move to somewhere else where it won’t be poor. This is the most realistic solution of all, but it needs a good economic model to underpin it—one that can be used predictively so NPCs can speculate where a good market may be ¹.

Construction time is another issue. If major buildings can spring up overnight, then it doesn’t bode well for a sense of realism. Unfortunately, if it takes a realistic time, then it doesn’t bode well for community management: Impatient players will complain if it takes a whole week to build an entire castle, let alone a modest dwelling (although this can be alleviated if you make them build in stages). Let them build in stages. There’s a case for having some delay, even if the fiction can support instant houses (“Just plant the house seed where you want it to grow, then water it and stand back”). A wait can heighten the anticipation, especially if progress is visible. Too long, though, and it becomes frustrating ². It’s up to you where you draw the line.

Perhaps the most noticeable thing about the settlements in virtual worlds is that they aren’t actually all that large. EverQuest’s towns have perhaps 50 buildings in them—they’re mere hamlets. Big textual worlds can have many more, but they suffer from not “looking” big. If graphical worlds had 5,000 buildings, that would be more like it! Unfortunately, this would depend on their having a capability to support significant numbers of NPCs that most of them severely lack (because of the degree of AI needed to control the little dears). Also, many designers see little point in having large numbers of pretend people in a virtual world that can boast several thousand real ones ³.

Nevertheless, I look forward to the day when I can visit a virtual city populated by tens of thousands of virtual players, each of whom has their own life to live and their own place in their virtual society. That would really be quite something.

Population

Let’s take a closer look at the inhabitants of virtual worlds. Basically, there are three sorts:

• Characters. These are run by players.

• Non-player characters. These are run by the virtual world. They look like players’ characters, and would think they were the same if given the AI.

• Monsters. These are run by the virtual world, but neither look like nor think they are players’ characters.

We’ll start with the effect that NPC population has on the fabric of the virtual world because it raises issues important to the other two. Note that there is also a shadowy fourth sort of inhabitant, non-player players, which accounts for people who need to visit the virtual world but not play in it; I’ll consider these separately last.

Non-Player Characters

What are non-player characters for? They

• Buy, sell, and make stuff.

• Provide services.

• Guard places.

• Get killed for loot.

• Dispense quests (or clues for other NPCs’ quests).

• Supply background information (history, lore, cultural attitudes).

• Do stuff for players.

• Make the place look busy.

In buying, selling, and making stuff, they’re normally just fictional conveniences; they may as well be vending machines. Similarly, in providing services (training, repairs, healing spells, and so on), they are interface conceits: Designers want the players to be able to obtain the services in question, and NPCs are the mechanism that has evolved to dress up what’s happening so it fits in context. Their being player-friendly helps; they don’t look like vending machines.

Guards exist for the same general reason: They’re the way designers traditionally choose to enforce a range of gameplay elements that require some justification if not to seem arbitrary. For example, suppose players are to be prevented from attacking one another within a city’s walls; one way to effect this would be simply to tell them that they can’t. This is unsatisfactory because it’s out-of-context—why can’t they? Furnishing an explanation along the lines of “you’d never get away with it” is slightly better, but still not ideal: Let players be the judge of whether they’d get away with it, not some invisible commentator. By introducing guards, players can find out for themselves that they indeed won’t get away with it. Guards are almost invariably unbelievably tough. Characters that routinely hew down hordes of rampaging giants remain impotent against guards. This is because guards that are unable to guard might as well not be there. Guards that are regularly beatable are meant to be regularly beatable, and therefore aren’t guarding any location or state of affairs that the designer really doesn’t want to be violated. These “guards” therefore fall into the “get killed for loot” category. NPCs of this sort are basically just regular monsters that look like player characters (PCs). They may be slightly smarter than their monster brethren, but essentially they’re there to be hacked and slain. Rarely do these NPCs have names.

NPCs that dispense quests may double up as one of the other kinds of NPC, but in general they have a special status. Indeed, they may be so special that they’re elevated to having their own, distinct personalities. Even so, they’re still principally a front to allow players to communicate with the virtual world without feeling silly. Their job is to give players things to do and then to remunerate them once they have done it. Beyond that, they’re mere flavor text.

Quest dispenser NPCs get players to do things for them. With sidekick NPCs, it’s the other way round: They do things for players. Although nominally independent, sidekicks are in essence mere extensions of the player’s character. Though presented as henchmen/ henchwomen, servants or familiars/pets ¹, they’re really just a way to extend the powers of a player. Too many objects to carry? Employ a porter or pack animal. Can’t find someone to heal you after a fight? Hire the necessary skills in the form of a cleric. Sidekicks aren’t usually used in larger games, as players themselves are intended to undertake the necessary roles. Besides, if a group of 25 players and their 25 sidekicks were trying to act in concert all semblance of organization would rapidly disappear. Players do still need mules, but in those situations they create secondary player characters instead.

Lore providers are like online manuals. Players can consult them to find out things they want to know, or be accosted by them to be told things they don’t want to know but, dammit, it’s for their own good that they do. Lore providers can be standalone, but they will often have some other function too (for example, quest dispenser).

The final type of NPC is the extra. These wander around as part of the background. Any attempts by players to bring them to the foreground (for example, by communicating with them, stealing from them, shooting arrows at them) are rewarded with a canned or inert response. Extras don’t feature highly in virtual worlds; because players can routinely interact with one another, they are disappointed when confronted with NPCs that have no obvious reason to exist.

Okay, so I admit that this summary of NPC types is perhaps a little cynical. There are plenty of virtual worlds where even the monsters can have personalities ², let alone the NPCs. The problem is that there are too few such worlds. When a virtual world is alive with real players, designers don’t feel the need to make NPCs more than ciphers for interacting with the virtual world. Players objectify NPCs in a way that only killer types objectify PCs.

Again, though, things are changing. Virtual world technology is driven by the big, graphical games, which in turn are driven by their hard-core players. The hard-core players play other computer games, particularly single-player role-playing games. When they see NPCs in these games that are above and beyond what they encounter in virtual worlds, they perceive virtual worlds to be behind the times.

They have a point, too. Virtual worlds have a much longer lifespan than ordinary computer games. A game from five years ago will look very dated by current standards, of course, but it isn’t just a graphics issue: Gameplay that was cutting edge five years ago can seem dated, too (albeit less so). Virtual worlds have to adapt and evolve if they are to keep up with the times. There is an argument that textual games don’t become dated because people’s imaginations don’t become dated ³; in her tour de force 1994 exploration of the Internet ⁴, J.C. Herz asserts that no graphical virtual world could ever match the imagery present in LambdaMOO—a sentiment with which the players of many textual worlds would agree. This may be true of the imagery, but it’s not (yet) true of the gameplay.

NPCs embody gameplay elements; therefore, if gameplay seems dated, then its associated NPCs will seem dated, too. Players don’t want dated content.

Just because players want something, that’s not a reason to give it to them, of course. Design is about consequences, and players don’t always accept them. Creating a fully rounded personality for a non-player character has been demonstrably possible since the days of Floyd from Steve Meretzky’s Planetfall ⁵, but it takes a lot of effort. In a graphical virtual world, there’s also the issue of animating different personalities. Slimy, sycophantic advisors have different body language than confident, cruel despots.

Animating such differences is a painstaking art. Motion capture can help, but it doesn’t work for dragons.

In other words, creating fully rounded NPCs is an expensive business, especially in graphical worlds, and very especially if you want 10,000 of them. Players who require intelligent NPCs can expect to have to pay more to get them.

Yet the same applies to many single-player role-playing games. Baldur’s Gate II ⁶ has several hundred NPCs; some of these are so rounded that they can (act as if they) fall in love, but most are there either as plot hooks or local color. Nevertheless, it’s possible to speak to all of them, even if they don’t actually have anything meaningful to say. The mechanism for interaction is simplistic—the same, select-response-from-a-menu deal that the original Ultima series used—but it’s better than the nothing you get from unidimensional virtual world NPCs. Textual virtual worlds sometimes implement a similar approach that masks the actual number of choices available (you might have to “ask guard about prisoner” rather than selecting it as an option from a list), but only for a few specific NPCs. Beyond that, there are pattern-matching schemes ⁷ based on Joseph Weizenbaum’s classic Eliza ⁸, and hugely sophisticated bots like Michael Mauldin’s Julia ⁹ (although these don’t have a gameplay role).

Artificial Intelligence research is ever-advancing. It’s unreasonable to expect virtual world designers to ask programmers to endow NPCs with the latest technology, but even a few 20-year-old ideas would make a big difference. So why don’t virtual worlds contain more intelligent NPCs?

The usual explanations are as follows:

• They don’t need them because they have real players instead. (Yet they do need dumb NPCs?)

• Smartening up NPCs would be too expensive. (So how do single-player role-playing games seem to manage it?)

• It takes too long to add AI to NPCs in virtual worlds. So much other stuff has to go in beforehand that it’s just unnecessary icing on the cake. (But a small team of AI experts couldn’t work on it from the beginning?)

• Artificially intelligent NPCs are never convincing and always spoil immersion. (More or less than artificially unintelligent NPCs do?)

• Neither the designers nor the programmers are familiar with AI. (And they can’t ever become familiar with it ¹⁰?)

• Players don’t like NPCs that are too clever. (So don’t make them too clever ¹¹?)

• It’s inappropriate for this particular virtual world. (Finally, a valid excuse. You may have a fiction that explains why NPCs are stupid—time travel to Neanderthal times, for example)

In most cases, the reasons that virtual worlds don’t have intelligent NPCs are to do with complacency, inexperience, and (for free virtual worlds) lack of resources. However, there is also a view of “if it ain’t broke, don’t fix it.” There may be only scant justification for not making NPCs more rounded, but that hardly amounts to an incentive to unflatten them. Why should virtual worlds contain more intelligent NPCs?

There are only two reasons.

The first reason is that even minor personality quirks in an NPC can give players some reason to care. Players can anthropomorphize NPCs very well, and are happy to do so in a virtual world. It’s not that NPCs have any intrinsic meaning, but that players can invest them with it.

As an example, suppose that the NPC mother of a young NPC boy asks for your help to get a saucepan off his head. It’s just a little quest. Next time, she asks you to get him down from a tree he’s climbed. Maybe she hits him when he’s rescued, maybe she hugs him and cries with relief; it’s still just another little quest. The time after that, he’s got his head stuck in a fence; the time after that he’s locked himself in a cellar. You come to know the two NPCs—the reckless child and the self-critical mother—and if you need a small filler quest you’ll often pay them a visit. Then, one day, the mother comes running to you. Her son was dragged off before her eyes by some kind of red-eyed demon. She’s hysterical. He kept crying, “Mommy!,” she tried to save him but the beast hit her, by the gods, please, can’t you help?

Now the situation has meaning. You and the NPCs have a history. The mother didn’t go to any other PC, she went to you. Are you going to leave her son to be eaten alive? No way!

So that’s the first reason: It enables players to form emotional attachments to objects in the virtual world; these relationships can then be stressed to add drama and give players cause to ponder their own actions. The relationships aren’t anywhere near as strong as between real people, naturally, but they’re there. They give the player a reason to feel a part of the virtual world.

The second reason, you’ll either comprehend instantly or it’ll take an epiphany. It’s this: Imagine it! Imagine a virtual world with thousands of virtual people living virtual lives—each with their own goals, their own relationships, their own existence. A living, breathing, self-sustaining creation! Doesn’t that fill you with awe? Don’t you want to go there? Don’t you want to see what they’ll do, and do it with them? Wouldn’t that truly be a virtual world?

If so, you get it: I don’t have to explain further. If not, there’s little point in my trying to explain! All I can do is pose the following question: Should those lacking a god’s motivation assume a god’s powers?

There are other reasons why having intelligent NPCs is good, but their effects can be achieved using other mechanisms. The most important of these concerns the fact that even the biggest virtual worlds don’t have enough PCs to sustain their systems and, even if they did, few players would want to do the mundane things that occupy NPCs. Who craves a career as a city guard? Players visit virtual worlds because they offer experiences that they don’t get in the real one; they don’t want a “real life” in a virtual world. NPCs, on the other hand, live in the virtual world, so their “real life” consists of doing the kind of things players would do in their real “real lives.”

For example, some people want power. In this context, “power” means power over someone. Players won’t tolerate being under other players’ thumbs for long, therefore NPCs are needed to fulfill the roles of functionaries and foot soldiers. Similarly, players don’t buy or sell enough objects to sustain an economy, therefore NPCs should engage in commerce to ensure that prices rise or fall appropriately. The collective behavior of NPCs can be used to regulate reputation systems, consequences for high/low status/fashion, rumor propagation/decay, the growth/decline of settlements, elections to office, and many other useful “background” tasks that contribute prominently to the experience of players but in which players themselves are loathe to get involved. If NPCs report their feelings when asked, this can add even more: I might not care that the NPC wants to tell me about the nearby ruin I already visited five times, but I’d certainly care to know whether that NPC was thinking of voting for me in the upcoming Guild of Mercenaries elections.

Giving individual NPCs more capacity for self-determination is one way to implement these behaviors. Another way, though, is to model the actions of NPCs as a whole, rather than individually. For example, instead of each NPC deciding when they need to buy a new gown and the price they’re willing to pay for it, a general model of NPC buying habits can be used to calculate the overall demand curve for gowns and the impact that this has on price. This is easier to engineer, less expensive to program, and simpler to fine-tune than its micro-economic counterpart, although it’s also more predictable and not as robust. It’s a viable alternative to using hordes of independent NPCs to obtain the same effect. If you have those hordes for other reasons, though, it makes sense to arrange for their collective behavior to emerge from their individual actions, rather than simulating it and having the two diverge.

It could be argued that if a virtual world needs intelligent NPCs, making them artificially intelligent is the wrong route to take. Why not employ actors to control NPCs, and get intelligence of the natural variety? Set up an office in Hollywood where wannabe actors are endemic and it wouldn’t even be all that expensive.

I have two objections to this, one practical and one philosophical.

The practical objection I outlined earlier. Going hands-on works for small, intimate virtual worlds, but not for ones with large numbers of players—it’s hard to maintain non-superficial relationships with 200 people. Players are deeply suspicious of vendettas, favoritism, and other imagined ways to cheat; if they find that you sent one more monster against them than you did against some other group, they will whine incessantly ¹², no matter how much fun they had. They don’t generally like talking to patronizing, in-character, support staff at the best of times. Besides, it would be expensive to hire actors in quantity, even in Hollywood.

The philosophical objection is that one of the major goals of virtual worlds is self-reliance. Computers, not minds, model the physics; the same applies to the virtual inhabitants. If your virtual world design relies on people as components, it may be ahead of its time but it nevertheless crosses a boundary that stops it from being a virtual world. Players are necessary; community managers are acceptable; PC NPCs are a contradiction in terms.

Designers will determine the numbers and population density of NPCs depending on the roles they need them to fill. This raises a question: As a general rule, should it be possible for PCs to do anything that NPCs can? With some minor qualification for the virtual world’s fiction, the answer should be yes; it ensures flexibility in design. That in most virtual worlds it isn’t true shows just how inflexible designs are. The question also can be turned around: As a general rule, should it be possible for NPCs to do anything that PCs can? Again, the answer must be yes. Why yes? Players will usually have no trouble telling other players’ characters from NPCs, but that doesn’t mean NPCs also should be able to: If one NPC offers a quest, there’s no theoretical reason why some other NPC shouldn’t be able to undertake it. This can only add depth and variety to a virtual world—both good things.

From the foregoing discussion, it should be pretty obvious where monsters fit in to this equation: They’re simply NPCs that operate under different AI rules ¹³. What about players, though? Are they merely NPCs controlled by natural rather than artificial intelligence?

Would that it were so….

Player Characters

Players are the best things and the worst things about virtual worlds. They’re contradictions.

Players want an immersive experience. They want a virtual world that looks and feels like how they expect it should look and feel. They want to share it with thousands of other people. They want fully integrated, working systems that support a rich, eclectic mix of activities in a balanced way. Only when they have it do they change their minds.

Players’ desires completely overwhelm a virtual world. You could have a smooth-running, functionally luxuriant virtual world of 50,000 NPCs that would collapse if 50 players entered it (think Aztecs and Conquistadors here). There’s a conflict between what players want and what has to be true for them to have it.

For example, they like a huge playing field. The early textual worlds often advertised themselves in terms of the number of rooms they had, the bigger being implicitly the better ¹. However, when it comes to moving around in such a virtual world, suddenly distance becomes an inconvenience. Players want to be able to get where they want to go quickly. Why should the first half an hour of a session involve moving through uninteresting territory to where the action is? They want teleportation, portals, high-tech transporters—anything, so long as it bypasses the points between start and destination.

So they want a big world, then they want to shrink it.

A common outcome of players’ insistence on such luxuries is that only player characters get to use them. Mobiles don’t. There may be a public-transport teleport gate in the middle of town, convenient for all amenities, but NPCs saunter right past. Those NPCs who want to go anywhere have to walk. The same applies to many other situations: player characters might get better after they’ve been killed, but monsters certainly don’t—they’re well and truly gone ².

This special treatment for players is not in itself necessarily bad. It only becomes bad when it subverts systems, such as the ecology or (especially) the economy. Here’s an example of what I mean.

In medieval times, wine was a drink for the peasants in France but for the nobility in Scotland. Why? Because grapes grow in France and they don’t grow in Scotland. French peasants harvested the grapes and made it into wine. They kept some for themselves and handed the rest over to the local feudal lord, who would retain some and sell the excess to merchants. Those merchants would transport the wine to the coast, put it on a ship, and dispatch it to (among other places) Scotland. There, it would be unloaded and sold to another merchant, who would trade it to the nobility because no one else could afford it. The cost of transporting the wine from France to Scotland is what made it so expensive there (well, that and the import duty levied by the Scottish monarch).

Now assume that the people in Scotland could have materialized in France, undertaken some transactions, and then rematerialized back in Scotland. What effect would this have had on the price of wine in Scotland?

It would have fallen, obviously. Scots could have bought the wine at source. In fact, they could have done better: They could have bought the grapes at source and then made their own wine. If everywhere is local to everywhere else, this is exactly what happens. Nowadays, transport is much less expensive (although taxes are just as high), so the price of wine in Scotland is comparable with that of the local product, whisky. If transport were free and immediate, the only reason to make wine in France would be because that’s where the winemakers wanted to make it.

Now imagine you’re back in medieval times and you have access to a teleporter. You can buy wine in France and instantly sell it in Scotland at a far lower price than regular merchants can while making a far greater profit. At a stroke, you have completely wrecked the economy as it stood.

This leaves designers with a problem. NPCs have to use the same economy that players do. With instantaneous travel, there’s no such thing as a local market: Prices for goods are the same everywhere. Therefore, the virtual economy should at least simulate the ability of NPCs to use teleporters. Yet, defiantly, players don’t want this. They want tin to be cheap near tin mines and expensive elsewhere, just like in the real world. They want silk to come from China, wood to come from Scandinavia, spices to come from India, gold to come from Central America: That’s what they learned at school and that’s how it should be. If diamonds the size of tennis balls can only be mined on the planet Eebagum, then they should cost less in the gem markets of Eebagum than back on Earth. It stands to reason. Thus, when a player teleports from Eebagum to Earth with a sack full of diamonds and sells the lot, the price shouldn’t drop. Then, a month or so later, they can wonder why their immense wealth won’t buy them anything from other players.

The subject of player perversion of virtual economies is a big one. However, it’s something designers really need to know about, so let’s make a start.

Economics

Economics is a huge subject of immense importance. In the real world, it touches on absolutely everything that people do. Daily it occupies some of the finest minds on the planet, and yet still the mechanisms by which it functions aren’t completely understood. Even top economists can’t agree on everything.

Is it any wonder that it scares the willies out of virtual world designers?

As part of their trade, the designers of virtual worlds must accumulate a wide range of knowledge covering many specialist subjects; some of these they’d perhaps rather avoid, but none of them are truly avoidable. Economics is one such specialist subject. Unless it’s your own specialist subject, you’re in bother.

My advice in such circumstances is to visit your local university. Head for the bookstore and buy whatever book entry-level students are buying. This applies whether you want to know about economics, psychology, artificial intelligence, sociology, anthropology, astronomy, whatever ¹. Read the book you buy. If half of it or more makes sense, you probably have enough of a grounding to be able to apply your newly acquired knowledge to virtual world design. Complex though they may be, virtual worlds are nowhere near as complex as the real one; you may only have the gist of the subject, but when you’re working with something that’s only the gist of reality, well, that’s usually sufficient.

If you don’t understand even half of the book, hire a specialist. No sense in burning out your brain.

So, what, fundamentally, is economics about?

It’s about resource allocation. Resources are anything that people need or want for any purpose—land, food, labor, sports cars…. When resources are scarce (as they usually are), they can’t be allocated to satisfy every need or want, therefore some system of resource allocation must pertain. This system is the economy.

Some economies are more efficient than others. In a barter economy, I might raise chickens and buy the things I need using eggs. Other egg farmers could do the same. If two of us wanted to buy the miller’s last sack of grain, the one of us who was prepared to offer the most eggs would probably get it. If we both wanted the same Stradivarius violin, however, it would be more problematical: We might not have enough eggs, the seller might not have a use for that many eggs, and we could be up against someone else who wanted to pay in shoes. It’s likely that none of us will get the Stradivarius, even though we all want to buy it and the owner wants to sell it.

Most societies use currency to make transactions more efficient. I can convert my eggs into coins. I can save these up to buy a Stradivarius ², and the person from whom I buy it can use the coins to buy other things. Currency facilitates transactions.

The example with the eggs, although it uses a barter system, follows the principles of a free market economy. Prices fluctuate depending on supply and demand. If the miller had many sacks of grain, I could have got a sack at a lower price; if I had many spare eggs, I could have afforded to pay more eggs for a sack.

For virtual worlds, a free market is not the only option available. There are basically four types of economy you can have:

• None

• Fixed prices

• Free market

• Faddish

Having no economy is fine for worlds with very low persistence. It isn’t that there’s no economy at all, of course, just that there’s no formal economy. If you can’t save objects across sessions, for example, there’s very little reason to buy things; informal bartering is enough. It’s possible that there could be a service market (“I’ll train up your strength if you give me 400 units of currency, which I can save up to spend on improving my fishing skills”) but even this is amenable to simple barter.

Heavy role-playing-style textual worlds often have no formal economy (although some older custom codebases ³ omitted it, too). In these, it’s common for people to give things away that they don’t need, thereby encouraging a community-strengthening favor reciprocation system. The more persistent a virtual world is, though, the greater the need for a formal economy; otherwise, players wanting to exchange goods and services get very frustrated if their favors are not returned.

The fixed-price approach also works in low-persistence virtual worlds. If you can’t take your cash with you when you quit, fixed-priced objects retain their worth. If you can take some money, but only up to some moderate amount, that also can work. If you can keep arbitrarily large amounts of money, fixed pricing eventually equates to “free.” I’ll explain why shortly.

Prices in a free market change to reflect how much people are willing to pay and how much people are willing to be paid for particular goods or services. This is the approach used by most virtual worlds. It ought to work—it does in the real world—but there are a few problems that virtual worlds have which the real one doesn’t. Again, I’ll come to these shortly (after I’m done summarizing economy types).

The final common type of economy is whatever fad idea enthuses the designers enough that they decide to use it. Although the designers will thus be 100% committed to it, prospective players will generally be 100% the opposite. It may well work in practice as well as in theory, but the chances are it will do neither.

Most virtual worlds aim for a free market economy. There has yet to be a successful large-scale implementation of this, however. There are two reasons for this: Designers don’t make the economy as free as they think they’re making it; players beat it to a bloody pulp.

Let’s see how these situations develop.

Wealth enters the system: The main sources of this are monster drops, quest rewards, farming/mining, and newbies’ grubstakes. Characters accumulate wealth. By their efforts, they may create more wealth by adding value to items or by performing services. Wealth leaves the system: In a closed economy, what leaves goes into some simulation (for example, of the activity of unseen NPCs) to return in some form later. In an open system, what exits the system has no effect on what enters.

What happens when, because of players’ industry, wealth appears at a faster rate than it disappears?

In a closed system, the rate at which recycled wealth enters falls to compensate. There are fewer monsters and quests, or the rewards for success are lower. Players find they are receiving less money, so are more inclined to keep what they have ready for when they really need it; this means that the amount of wealth leaving the system falls again, leading to a fall in the amount entering. It’s a vicious circle, which guides the economy to a grinding halt. All it takes is for more people to hang onto their wealth than the designers had allowed for, and it’s guaranteed to happen. Given that organized griefers will figure this out and deliberately save money just to watch the whole edifice tumble, closed economies can always expect to dry up eventually ⁴.

Most virtual world economies are open. If more wealth comes in than goes out, then players accumulate wealth and can buy more things; if less wealth comes in than goes out, they go broke and can buy fewer things. This doesn’t matter in a truly free market economy, because prices can rise or fall to match income—even inflationary income. If today the average wealth of a character is 500 UOC and a new helmet costs 10 UOC, then in six months when the average wealth of a character is 5,000 UOC the price of a new helmet will be 100 UOC (if supply and demand remain constant). Thus, although absolute prices may change, relative prices only change when supply or demand changes.

In a fixed-price economy, this doesn’t happen. A 10 UOC helmet costs 10 UOC whether people have nothing in the bank or millions. It’s normally the latter; this means that after a while helmets are basically free—great news if you want a helmet, but terrible news if you’re a player whose character manufactures helmets. In any system with fixed pricing, inflation hurts everyone who crafts goods for which fixed prices pertain. It doesn’t matter if you can raise or lower your own prices: If NPC vendors buy and sell at fixed prices, you’re screwed.

The obvious solution to this is to have variable prices—that is, a fully free market. The problem is that unless all prices are variable, this doesn’t work. One consequence of this is that quest rewards and mobile drops should be variable, too. Who’d want to risk life and limb for 20,000 UOC if it wasn’t enough to buy an arrow? Yet how do designers make these price rises occur rationally in such a way that unscrupulous players ⁵ can’t screw over the system?

Actually, it’s surprisingly doable. The trick is to give goods rather than cash as rewards. Goods get their value from the free market; therefore their value varies in keeping with supply and demand. If you get a wolf pelt for killing a wolf, then the sum total of the wealth of the virtual world increased to the tune of one wolf pelt. The amount you can sell this for depends on the demand for wolf pelts at the time. If demand is low, you get a smaller return than if demand is high, therefore you go off and kill something else instead of wolves. This will lead to a drop in the supply of wolf pelts until there’s a shortage of them, whereupon prices will rise and you might think about killing wolves again. It all works very neatly.

Unfortunately, there are some consequences of the free market economy that require players and designers to accept some as-yet unpalatable truths.

Designers first. A free market economy operates using what Adam Smith famously called an “invisible hand” ⁶. Individuals work to promote their own self-interests, but in so doing promote the interests of society as a whole (generally unintentionally). Farmers sell us food because it’s in their interest to do so, not because we’d die if they didn’t. If all players act in their own best self-interest, the free market economy will flourish.

Unfortunately, in virtual worlds players’ best self-interest may be to make your economy collapse—and that’s not even the worst of it.

In the real economy, you have to participate because there’s nowhere else to go. Everyone can’t be rich; some people have to be poor. In virtual worlds, you do have somewhere else to go. If you’re poor, you can emigrate to some other world where you can be rich. In the real world, if no one buys the helmets of which you are so proud, you have to make something else instead; in the virtual world, you quit and go where helmet-making is valued. Helmets, potions, laser rifles—it applies to all crafted items.

Also, the free market model says that if a bunch of players want and can afford quality swords and there’s no one making them, the demand will prompt someone to get into the quality sword business. Unfortunately, that reasoning only applies within the context of the virtual world. The demand also can be satisfied by frustrated fighters decamping to some other virtual world where there is no sword shortage. No matter how much a designer might want it, his virtual world’s economy can never be truly closed because players are a part of it and players can come and go. The free market does work here—supply, demand, and prices do achieve equilibrium—but it works in a way that hurts your real-world profits.

It may be that a free market has unpleasant consequences on the virtual world itself, too. Take the example of bakery wars: A big guild with deep pockets sets up a bakery in a town that already has a bakery. The established shop has a loyal customer base, a long-standing reputation, and it makes tasty bread. The guild shop starts to give away free bread. People go to the guild for their free bread.

What does the local bakery do? It can give away bread for free too, but it still has to pay for the raw materials and it therefore takes a loss on every loaf (so does the guild, of course, but the guild is rich and can afford the loss). The bakery can continue to charge a fair price for its bread, but people won’t buy it because they can get something fairly similar for nothing from the guild. Eventually, the original shop is going to have to face facts and shut down. The guild will then hike the price of its own bread sky high so that it not only covers its losses but it becomes even richer. Do you, as a designer, allow such monopolistic bullying ⁷? It’ll cost you at least the local baker and perhaps some of the people who used to buy their bread there. If you thought about it in advance you can devise ways to stop this sort of thing from happening, but what about the ways for players to turn over your economy that you haven’t thought of? What checks and balances do you have in place to defend against unforeseen attacks?

Another example: pelt hoarding. Suppose a guild seals off the forest where the snow wolves live. No one goes in or out of the forest unless the guild guards get out of the way. If there’s a constant demand for snow wolf pelts (they’re used for making frost storm spells or something), then the price of snow wolf pelts will rise. Ordinarily, it may be that the forest spawns 20 snow wolves a day and the pelts fetch 50 UOC each. Now, it’s still spawning 20 a day but if the guild only kills two of them, then each pelt may fetch 1000 UOC. That means they double their profits. This is how cartels operate: By restricting supply, demand is artificially inflated and prices are kept artificially high. Do you have your world react to this, for example by spawning snow wolves in more places? If not, the players who need the pelts will wail about how your crock of an economy allows this kind of abuse to occur. But if so, the cartel will flood the market with snow wolf pelts until your spawning stops, then repeat—all the while complaining bitterly about your interference.

This brings us to the second group of people who have problems with a free market economy: the players.

Players will produce spreadsheets covering your economy. They will then gouge it. They will expect to gouge it, regard it as perfectly natural behavior, and be outraged if you make any attempt stop them. Everyone else, on the other hand, they regard as having no right to exploit the economy in any way remotely detrimental to their own well-being. This is true in the real world, of course, but you can’t quit the real world; you can quit virtual worlds.

In a free market economy, the activities that people undertake will sometimes be rewarded poorly. This acts as an incentive for those people to do other things that are better rewarded instead. Unfortunately, for a player of your virtual world, “better rewarded” might mean playing some other virtual world rather than yours.

Suppose you, as a player, like making clothes. It’s a big creative thing with you—you enjoy seeing characters walking around wearing your designs. Your entire aim when selecting a virtual world is to have your character be a tailor. So, you sign up to a world that lets you be a tailor, and start to churn out jackets and skirts and coats with which you’re immensely pleased. What happens if there are so many other tailors around that nobody wants to buy your clothes, no matter how much you advertise them?

In the real world, you would lose money to the extent that eventually you’d have to face facts and stop making clothes. In the virtual world, you would scream and scream and scream until the world was “fixed” so that there were always NPCs willing to buy your garments. If it wasn’t “fixed,” you’d eventually leave in disgust at its betrayal. Again, the virtual world’s free market economy is working, but the real world’s free market economy is also working; of course, the real world always wins.

Players want an honest day’s pay for an honest day’s work. If you don’t reward them, they feel cheated. If you set up yourself as a snow wolf hunter and make 50 UOC per pelt profit, you’re happy. If other people find that killing snow wolves is profitable, they’ll join in. With the resulting increase in supply, you’ll find you can’t sell your snow wolf pelts unless you drop the price. Now you’re making only 40 UOC per pelt ⁸. What do you do? Either you accept the realities of the free market or you dash off an email to the community service team screeching, “Your STOOPID game NERFED snow wolves!!!” ⁹.

Players like it when the free market works in their favor; they don’t like it if it doesn’t. This may be a problem that, in time, the maturity of players cures. Then again, if enough precedents for pandering to players are set then it may never get the chance to be tested. Players will complain—and get a hearing—if they do things that are blatantly stupid.

Player: “You killed my chickens!”

Community manager: “You built your chicken farm in a forest full of wolves. Didn’t you expect maybe they’d eat your chickens?” Player: “Are you hearing me? YOU KILLED MY CHICKENS!”

Telling players that the miserable time they’re having is all their own fault will not endear you to them. If they spend four hours hunting wolves when the price of wolf pelts is rock bottom, they don’t like being told to hunt something else instead. If they’re told that hunting itself is an over-subscribed activity (having designed their character to be a hunter), they will be absolutely livid. Players will spend a lot of time being miserable if the reward is high enough. They’ll mindlessly click on the same “mining” icon for three hours, hating every moment of it ¹⁰, if the result is that they find the diamond they need to give them an arrow of dragon-slaying. It’s when they make themselves miserable for no reward that the problems come. They want an honest day’s pay for an honest day’s work; they’ve done the honest day’s work, so now they want the honest day’s pay. It’s immaterial to them that what they’ve done is as useful as counting buttons.

It’s because players are frequently unwilling to accept this consequence of a free market economy that virtual worlds will guarantee prices for crafted objects. This assures a market, so players stop complaining, but then there’s no incentive for them to change to making something people really want. Besides, players have other requirements, too: Someone who makes clothes that no one buys may be temporarily pacified by being able to sell them to NPCs, but unless NPCs actually wear those clothes they’re still going to feel unfulfilled. Even then, NPCs aren’t PCs. Surely, PCs would buy your clothes if only their existing clothes wore out quicker? So it’s complain-to-live-team time yet again.

Note that designers don’t have to guarantee fixed prices, just decent prices. It’s perfectly within the power of the live team to change prices manually or to force a change by (again, manually) altering supply and demand—creating and destroying virtual goods is free for them, after all. In the real world, the social costs involved in doing this are too high for it to be successful; as economist Edward Castronova has pointed out ¹¹, however, these costs are absent from virtual worlds and therefore price-fixing could be considered a viable strategy in such an environment. However, as I’ve just illustrated, there would remain other undesirable effects to do with concepts of fulfillment and self-worth. So although live teams could indeed attempt to control prices, they’d have to know exactly what they were doing to succeed (and be ready for the inevitable accusations of bias and favoritism that would follow).

Fixed prices aren’t in keeping with a free market, and neither is fixed income. If all newbies get a grubstake of so many UOC, the purchasing power of that grubstake depends on prices. It’s better to give them a range of kit, but even that can lead to perceived unfairness if the exchange value of what today’s newbie gets is more (or less) than it was two months ago. It’s more palatable than giving inflation-adjusted grubstakes, though.

Similarly, if monsters drop a (relatively) fixed amount of coin when they die, what it will buy depends on current prices. Again, it’s better if you make them drop some resource that can be traded instead of raw money, even if the money is inflation-adjusted—players will moan if “last week I only got 600 UOC but this week my friend got 650 UOC, so you owe me 50 UOC.” You can still get a form of inflation with this, though: A mobile dropping a +1 sword is dropping nothing if everyone already has a +1 (or greater) sword.

Fixed prices and incomes are bad for an economy, as eventually either everyone can afford everything (inflationary world) or no one can afford anything (deflationary world). Fascinatingly, this same argument can be used to justify assigning constant experience point values to mobiles: The more experience points you have, the less the value of an “easy” mobile is to you. Therefore you have to go for the tougher mobiles that give higher returns (leaving the easier mobiles for relative newbies). A consequence of this “level inflation” is that eventually no mobiles are worth enough. Without sufficient sinks (that is, ways to lose experience points), new content must be added somehow, either by the live team or designed-in as an elder game.

Of early virtual world economies on a massive scale, Ultima Online’s was the best. It almost worked. The economy and ecology were interlinked and interdependent. It began as a closed system, but it soon became apparent that the sum total of the world’s wealth wasn’t large enough to go around. It switched to a faucet/drain economy, which held up for a long time despite having some fixed prices (for crafters) and periods of inflation due to bugs. What finally broke it was the lack of sinks: People didn’t have enough to spend their money on, so it simply accumulated.

Following on from UO’ s complex economy, there was a backlash. EverQuest and Asheron’s Call both had much simpler economies. Both of these suffered from inflation, although in EQ’s case the vast numbers of newbies entering the world managed to soak up the excess to some extent and eventually the economy became relatively stable. AC rapidly achieved hyperinflation (it wasn’t helped by some money-duping ¹² bugs that effectively gave players their own mints) and its economy never really recovered. Unsurprisingly, most of the EQ–inspired graphical worlds went for the EQ approach rather than the UO one, although Star Wars Galaxies sees the pendulum swinging back to a system that doesn’t require a newbie hose to sustain it (ironically, because SWG does have a newbie hose).

The interesting thing to note about formal economies is that when they do break, an informal economy will normally emerge to replace them. AC’s informal economy, based around gem shards (needed to make kick-ass armor), certain keys (giving access to spell scrolls and other kick-ass armor), and writs (required to lease a house), became highly robust and stable; the formal economy was only used for interactions with NPCs. It’s to the designers of AC’s credit that although the economy they originally put together fell apart, their virtual world was sufficiently deep that the informal economy that replaced it became something of an exemplar.

Interference in Economies

How much should you interfere with how an economy “should” work to facilitate its smooth operation?

Let’s start with something relatively mundane. Players don’t like being ripped off; if they want to trade, should there be a secure trading system whereby goods can be exchanged with no danger that anyone will take the money and run? It’s not very immersive, but players are accustomed to the idea and will accept it without thinking (in the same way that they accept slow scene dissolves in movies as a signal for the passage of time). The easier it is to trade, the more likely players are to engage in trade.

Trading, though, is tangible: Coins and objects are things the virtual world can track. Services are intangible: If I want to pay you to guard something, how can the virtual world track whether or not you did it? Similarly, although it’s possible to contrive a trade screen whereby I cast a heal spell if you give me money, it’s not so easy to do it for more complex arrangements (such as casting heals on you “whenever you need them,” in exchange for “a share of an expedition’s profits”).

There will always be unsecure trading, because designers can’t hope to model everything that players may want to trade. Given that they can’t model everything, the question that then arises is whether they should model anything at all?

The answer must be yes, because it’s the only way for low-AI NPCs to trade. Given that it’s therefore there already, allowing it for instant inter-player trade isn’t really going to hurt any. For transactions that take time, though, it’s trickier. If I pay an NPC to train me to use a crossbow, I know that the NPC is not going to disappear with my cash; with a PC, I don’t know that. This can be shoehorned into a transaction system, but the more complex transactions become, the harder it gets. There comes a point where to continue would be ridiculous, even if it’s short of what NPCs can do. Automated transactions are okay if they don’t stretch convention too far, but beyond that they hurt immersion.

If a smooth-running economy were the only aim here, this model could be further extended. For example, players could be allowed to trade with one another without being in physical proximity. Goods could be teleported immediately from point of sale to point of purchase, with the two not necessarily coinciding. This would greatly facilitate the exchange of goods, leading to greater satisfaction for all. In a Science Fiction virtual world, it may even make sense within the fiction.

Whether it would be any fun is another matter, though. One of the things about an imperfect economy is that it takes time for production and demand to fall into step. During that time, profits can be made. If response is immediate, this smoothes out the creases that make commerce interesting.

In some virtual worlds, the mobiles you fight are tuned to your combat abilities. In other words, no matter what you attack, it will adapt to be commensurate with your abilities to defeat it. The design thinking is that you’ll have a more exciting time if you’re pushed close to defeat but still manage to win. It’s flawed, though, because nearly-losing-but-then-winning is only exciting if there exists the possibility that you could actually lose. Because mobiles are bent to fit your abilities, there’s actually no real danger of this. Combat is ultimately dispiriting.

A similar thing applies to over-smoothed economies. If as soon as players think of something clever to do, checks and balances come into play that dampen the effect, in time people are going to wonder what the point of it all is. There has to be enough opportunity to make a success of something before the bandwagon arrives, otherwise it’s just not worth trying.

Interference in the low-level workings of an economy can thus be counterproductive: The easier you make it for people to trade goods and services, the less interesting it becomes. On the other hand, if you don’t interfere then the economy might not work at all. You have to achieve a balance.

There are other ways to interfere that could help.

National governments use interest rates to control their economies. Low interest rates cause people to spend; high interest rates cause people to save. If you have a virtual world where players are spending or saving too much, it shouldn’t be too hard to create a mechanism that corrects the problem (for example, by making NPCs change their prices, or by taxing PC bank accounts).

Regrettably, this isn’t as straightforward as it sounds. The problem is not the implementation, but players’ perception of it. Unlike with a secure transactions system (which is a transparent process), they don’t see the workings of the economy’s carburetor, just the effects. It’s very difficult for them to trust what’s going on. Even if you completely automate the checking and balancing, there’ll still be a deep suspicion that actually it’s the live team that makes all the decisions, with some “nerf knob” they can turn to make prices rise or fall.

It’s an issue of trust. If you must have a nerf knob, you might want to give control of it to a committee of players rather than automate it. They may screw up, but at least they’ll get the blame, not you!

Tips for a Successful Virtual Economy

I’ll wrap up this discussion of the economies of virtual worlds with a few tips to help you design one that works. Rather than merely repeat what I’ve already said (“Don’t use fixed prices, you idiot!”), I’ll concentrate on ideas that might not be immediately obvious. Not all of them apply to all virtual world economies, but hopefully they’ll spark a few ideas.

Have Stuff Wear Out

The normal problem in virtual worlds is inflation. The effects of this are alleviated somewhat if players have many ways to be separated from their cash. The easiest way to do this is to have stuff wear out so that replacements have to be bought. This hands money to NPC vendors or (if goods are bought from PCs) to NPC miners/farmers. If PCs do all the mining and farming too, it’s still of some use because it encourages trade; it’s best as a money sink, though. It helps keep scarce items scarce.

Players see it as a money sink, of course, which makes them suspicious. It’s basically a tax on action. However, as long as you make it “realistic” you can get away with it: Shields used in combat really do receive a battering, but you’d be hard-pressed to justify why a ring wore out.

Charge for Services

Players don’t like it when you take money from them, but they don’t mind so much if they think they’re spending it. They are quite happy to pay for things that reduce the amount of work they have to do.

For example, consider teleportation. When a player wants to go from A to B, the cost of teleporting compared to the time cost of walking should really be an issue. Players ought to have to think about whether they need a service enough to pay through the nose for it. Naturally, they’ll complain that teleporting is “too expensive,” and they could well be right. With a pricing structure that rises and falls depending on how many people use a teleporter, though, a balance should be achieved.

In considering services that can be charged for, anything that satisfies these three criteria is suitable:

• Player characters can do it.

• NPCs or the virtual world itself can do it for them.

• Players don’t like doing it.

Have Multiple Currencies

In the real world, there are many currencies. If a price is quoted in one currency and you want to pay in some other, you have to sell some of the latter currency to get some of the former. I can’t give a taxi driver in Paris dollars and I can’t give a taxi driver in New York euros ¹.

Exchange rates between currencies fluctuate. In theory, this happens because of trade: If a country manufactures goods that lots of other countries want, those countries will have to acquire the currency of the first country in order to pay for the goods, which will lead to a rise in the exchange rate in the first country’s favor. If a country needs more capital to invest in its industry and infrastructure, it can raise interest rates, thereby attracting investors who want a guaranteed return; this will also lead to an increase in the exchange rate.

A virtual world can have multiple currencies, and exchange rates between them. This can act as a form of trade tax (because converting currencies will almost inevitably incur a commission charge) and it’s also good for limiting the spread of inflation (the more money of one kind there is in circulation, the less money of another kind it is worth). The number of currencies doesn’t have to be high: Gold versus silver coins can work; Simutronics’ game DragonRealms successfully runs three “local” currencies.

In practice, real-world currency markets are dominated by speculators. In virtual worlds, the fact that you can tax each and every currency transaction would immediately put a stop to this (assuming you wanted to).

Give Money Weight

This is a great tip for virtual worlds with a pre-Victorian era setting.

If you have 100,000 gold pieces, that’s a lot of gold. Post-1982 U.S. 1 cent coins (pennies) weigh 2.5g; 100,000 of them would weigh 250kg, or about 550lbs. Coin quality gold is about 2.5 times denser than electroplated zinc. Moving that kind of mass is not easy without cheating physics.

When coin has weight, the act of transporting it is non-trivial. Someone who is rich in one city is not so rich in another. A local economy can therefore flourish because players can’t easily transport enough coin there to undermine it. It leads to a more stable overall economy. Objects genuinely do have different values in different places, and a career as a merchant suddenly becomes a possibility. Although giving coin weight gets in the way of trade, it also makes trade more interesting; it gives it gameplay elements that it didn’t have before.

Players can carry high-value items such as gems instead of coin, of course, but gems are like multiple currencies. Rubies are worth more in places far from ruby mines, and then only if PCs or NPCs actually have a use for them. You might be able to convert from coin to gems, but where you’re going you may find you can’t convert back, or that if you do you get a different amount of gold ¹.

A corollary to this is: No banks, no banknotes. For any world in a pre-renaissance setting, this is historically accurate; for any other world set prior to about 1900, it’s inaccurate for the very wealthy but is fine for the general population (who never saw banknotes nor visited banks). In Fantasy virtual worlds, banks are basically there as a convenience for players, acting as money teleports: You pay cash into one and withdraw it out of another. They’re effectively ATMs, and as such are somewhat out of place. It’s hard to imagine Gandalf visiting a bank in Lord of the Rings; likewise, it’s hard to imagine Elrond paying for a horse with a banknote.

Multiple Uses

Elves draw magical power from the number of trees that exist within a certain range. Humans in the nearby town want wood for housing. This is conflict. Economies can drive conflicts. Conflicts can also drive economies. Dwarfs need elf skins to enchant their forges.

Conflict like this is good for gameplay (if not overdone), and having multiple uses for resources is a neat way to introduce it. The same technique can be used to enhance trade (by driving up volumes) and challenge monopolies (because the opposition to them will be greater).

Similarly, having multiple resources for the same use ¹ can keep a virtual economy from being mugged. In practice, goods are usually implemented as being similar but not exactly equivalent, so a snow wolf pelt might have a slightly higher warmth factor than a snow bear pelt, but get mangy quicker. Nevertheless, if there were a sudden shortage of snow wolf pelts, people who made clothes out of them ² could switch to bear pelts. When people have choices like this, meaningful decisions must be made; meaningful decisions are at the heart of gameplay.

Charge for Advancement

Players are so pleased when their character has gained enough experience for them to advance a level or skill that they are quite happy to pay virtual coin to seal it. Whether this is through “training” (which for some reason only NPCs seem able to provide) or the acquisition of some expensive item (mithril cross, ebony staff, engraved armor) is not the point: The point is to provide a money sink.

Some designers adopt a “charge for everything” view and make characters pay to enter cities, to cross bridges, to speak to officials, and so on. This can backfire if people find it too tiresome or depressing. By charging for things that don’t happen all the time and that the player is happy about, these negative effects are greatly reduced. Charging for advancement is the perfect example of this idea in action.

Personally, I don’t like charging for advancement; it’s a little too cynical and opportunistic for my tastes. However, with plenty of players trained to accept it by existing virtual worlds, that’s no reason for you to overlook it.

Charge for Abstraction

Should player characters have to eat? If they do, should the food work its way through their digestive system or be beamed out of them at the last moment as seems to happen in Star Trek? If nature proceeds like it does in real life, are there consequences for not washing your hands afterward? Or is this all a level of detail too far?

Some textual virtual worlds have eating. Every so often, characters will feel hungry. If they eat, the hunger goes away; if they don’t, their attributes degrade increasingly until they do. Some foods are better at restoring attributes than others, but basically, eating remains a background maintenance task that adds authenticity but little gameplay.

Players deal with this by using clients that trigger on key phrases. When the “you are hungry” line arrives, the client automatically issues commands to remove a food item from the character’s backpack and eat it. The original message, the commands to address it and the messages confirming those commands are all stripped out. The player doesn’t know the maintenance has taken place, except that the backpack needs restocking with food occasionally.

If players routinely automate responses, why bother having the events that trigger the responses at all? They’re just hoops that players are being made to jump through. It may add realism, but the use of trigger code to make them transparent shows that it’s realism players would rather do without.

So players shouldn’t have to eat, then? In that case, what are all those NPCs doing working on the land? Only NPCs have to eat?

One solution is to make eating improve your character on a temporary basis. If you don’t eat, your stats stay low. This is actually pretty much the same as using eating to maintain your (higher) stats, with failure to eat incurring a penalty. However, when phrased so it sounds like it’s giving players something for performing an action (rather than taking something away for not performing it), it’s more acceptable. This is the Star Wars Galaxies approach.

Another solution is to abstract such activities out. Characters eat, perform their ablutions, and so on, only when the player is offline, in the same way that characters in movies go to the bathroom only when the camera is not on them (or when they’re about to be murdered). This allows players to get on with the serious business of having fun, without having to concern themselves with minutiae yet while remaining within the virtual world’s fiction.

If this abstraction is performed, the player can pay for it. In general, players are against their characters’ being taxed, but they can be persuaded to put up with something equivalent if it fits the fiction; a support fee to cover the incidentals that they run up while the player is offline is one such pseudo-tax. Incentives to increase payments—for example, by granting characters more status if they do—will often work. Characters without the means to pay could either suffer attribute/skill penalties or be allowed to subsist by explicit foraging, depending on the fiction of the virtual world.

The abstraction must be strictly adhered to, though: If characters eat while the player is logged in (perhaps when visiting a restaurant or taking part in a banquet), then their support fee for that period must drop accordingly. Characters who do buy their own food should ideally get a better deal than ones who rely on the abstraction, but this may be hard to organize in a free market economy.

This technique of charging for abstractions can be used for similar tiresome activities such as reloading ammunition and recharging batteries. In general, any unnecessary detail ¹ can be removed this way and its cost bundled into a support fee.

Non-Player Players

I did mention when I began this section that although the main virtual worlds were populated by characters, NPCs, and monsters, there was a fourth possibility: nonplayer players. These are the customer service representatives, techies, designers, and other members of the live team who need access to the virtual world but don’t want to play it as regular players. They generally need supra-world powers in order to help people, to test the world, to fix problems, and so on. How should the game fiction account for this?

The simplest answer is “it shouldn’t.” If you can’t ever hope to slip it unnoticed into the fiction why bother? Put non-player players in a uniform so that everyone else knows to expect odd goings-on when they’re around, and leave it at that.

The second-simplest answer is also “it shouldn’t.” Hands-on event co-ordinators, as I mentioned earlier, can merge in to the player base and appear to be regular players while actually having irregular powers at their disposal. This is fine for them, but it doesn’t work for programmers trying to track down bugs or for customer service representatives showing the human face of the live team.

The more traditional approach, at least in Fantasy worlds, is to have a formal hierarchy of gods/immortals/wizzes. In other words, find some in-context powerful beings and associate the non-player players with these. This may be unavoidable anyway in some virtual worlds—for example—it’s hard to conceive that an Ancient Greece world would work without any gods. Your main problem here is likely to be that the non-player players believe the labels and start acting like deities instead of programmers or whatever. A superior character doesn’t imply a superior human being.

There is also a danger that through their actions (or players’ beliefs of their actions), non-player players may inadvertently extend a virtual world’s fiction. If Thor shows up just as a character gets a lucky hit and kills a giant, that character may think Thor is responsible. Before you know it, web sites will be proclaiming that praying to Thor will help in battle, and unless this misconception is nipped in the bud it could become so widespread a belief that complaints from confused newbies occupy more community management time than the programmer time it would take to implement the idea.

Physics

The foundations of a virtual world are its geography and its population; they’re like a board and its pieces. Whenever designers begin work on a new virtual world, among the first things they consider are the geography and the ecology/economy.

With MUD1, Roy Trubshaw began with the physics.

Designers today inherit so much from what has gone before that often they don’t give thought to why things are the way they are. If they don’t give thought, they don’t have understanding; if they don’t have understanding, they can’t innovate. There are so many features of a virtual world that rely on its physics—geography and population included—that it’s staggering how much is taken for granted.

Physics concerns the fundamental systems of change; it’s the machinery of a virtual world. It’s no accident that it was the first statement in the definition of virtual worlds I gave in Chapter 1. It implicitly defines all a virtual world’s tangible possibilities; if the physics doesn’t allow it, you can’t have it.

Designers really should know everything about the physics of their virtual world. They should know what conventions have been adopted, they should know why they were adopted, and they should know their implications. Armed with this, they should consider ways and means to improve on them for the benefit of their virtual world and its players. If you do go with the flow, it ought only to be because the flow is going where you want to go.

Laws of Nature

The physics of virtual worlds is based on real-world physics. There is a reason for this.

If I push on a door, the door opens. If I push on a virtual door, the virtual door opens. I could just as easily make it that if I push on a virtual door, virtual birds fly out of a virtual mug. Unless the door was flagged as No Ordinary Door and the mug was flagged as No Ordinary Mug, this would confuse people. Why? Because human beings learn from an early age the cause-and-effect rules that govern the way reality works. In a virtual world, they are unable to stop themselves from applying these same rules except by an act of will. For virtual worlds therefore, anything that interferes with these rules acts as an out-of-context interrupt; anything that adheres to them implicitly supports the illusion that the virtual is real.

The real world operates under the laws of physics. The rules that people develop in their heads to model the laws of physics ¹ are simpler, but they’re good enough for almost all practical purposes. Virtual worlds wishing to be convincing to players must therefore implement at least these rules (and, paradoxically, perhaps no more; it’s players we’re trying to convince here, not reality).

Fundamentally, therefore, virtual world physics is concerned with implementing the obvious.

The key is transparency. Transparency means that players don’t have to suspend any disbelief, because their senses pass the information right by without comment. The more successful a designer is at creating transparency, the less his or her work will be noticed: This is great for immersion, if not so great for the designer’s ego.

The expectations that players have of a virtual world’s physics don’t have to map directly onto reality, if the context is right. The most conspicuous example is that of a genre boasting its own physics: cartoons. In cartoons, when you run off a cliff you don’t fall until you realize you ran off a cliff. The laws of nature do apply, just not in the same way ². As long as people buy into the fiction, this can work. Toontown can be as immersive as EverQuest.

The central issue for virtual physics is the level of detail at which it operates.

If I let go of an object, it will fall. That’s gravity in action. When it hits the ground, will it bounce? Will it become damaged, perhaps break? Maybe the ground will break? What if the ground is at an angle? Will the object roll down it? That depends on the object’s shape, its mass, what it’s made of, what the ground is made of, and so on. If there’s a wind, what effect will that have?

If there’s an object between the one I drop and the ground, what then? Will it trap the object; will it let it pass through; will the object bounce off or out? I could drop apples into a wicker basket, but how many would fit before it becomes full? Even if it were full, I could still add sand to it, if not apples. Then I could add water, which would be retained for a short while, but would eventually trickle out. Maybe if I’d added cement dust as well as sand it would have set instead.

That’s just the start of it. The physics of a virtual world must address all kinds of issues that the real world implements trivially. How long does a feather dropped out of a window take to land? Why does my compass point north? What happens when I shine my flashlight at a mirror? How long does ice last? Who will get wet if I throw a bucket of water at a crowd? Can I dismantle a bookcase and use the pieces to make a raft? What if I set fire to a wooden house?

The real world can answer all these questions because that’s how it works. It has molecules and atoms and atomic particles and quarks and who knows what else, all working together under the influence of at least four forces ³. Virtual worlds can’t hope to compete with real physics. Unfortunately, as the above examples illustrate, virtual worlds can’t cope with naïve physics yet, either.

That said, the virtual worlds of today have access to greater computational resources than those of yesterday, and it’s not unreasonable to suppose they could have better physics as a result. At a time when modeling tools are available to perform real-time ray-tracing, fluid mechanics, fabric deformation, and surface friction effects, it’s a little sad that virtual worlds rarely bother to implement concepts even as simple as “if you drop this in water it will sink.”

There are practical limits to what can be done. As detail increases, the number of active components increases and the number of interactions between them goes up exponentially ⁴. Throwing more computers at the problem will not even dent it. That said, if MUD2 can let you drop an object down a well into an underground stream which carries it off until it reaches a grate that may or may not trap it, all the while accounting for object density, impact damage, water damage, and the possibility of hitting or being caught by someone, then there’s no reason a large-scale graphical virtual world couldn’t do better. The trick is not to implement all of physics, or even all of a naïve physics, but to implement just enough naïve physics to satisfy players’ sense of detail.

That’s still harder than it sounds.

Virtual worlds operate at the level of commands. Players decide what they want to do in terms of effectively indivisible operations, and these make up the command set. They want to wear a pair of boots, they don’t want (for each boot) to loosen the laces, pull it on, tighten the laces, and then tie them in a double knot. Simple goals that in real life most people could achieve without really thinking should be implemented in virtual worlds as such. Believe it or not, for MUD1 Roy and I actually discussed these things before deciding exactly where to pitch actions. That’s why we went for “unlock door” rather than “put key in door; turn key; remove key from door.” It’s also why we made “lock” and “door” be synonymous nouns.

To implement physics, you only really need to go one conceptual level beyond that of the deepest command. Anything deeper than that, the players won’t see anyway. If a character can shoot an arrow, the virtual world engine should be able to show its flight and make its arrival be non-instantaneous; however, this doesn’t have to be done by applying Newton’s Laws to parabolic trajectories—it just has to look like it was done that way.

There is an argument that a deeper physics model can be used if it’s less complex than a shallower model or if several complex shallower models can be built from it ⁵. For example, if you have a good Newtonian simulator already built to implement your virtual tennis games, you may as well reuse it for arrows. This is reasonable, assuming you really did need the simulator for the tennis. In practice, it’s programmers rather than designers who are more susceptible to going too deep: You may have specified that characters’ breath should be visible in cold air, but it’s not you who’s spending 10 days implementing a brilliant new eddy-calculation routine.

So to summarize:

• Compiled into players’ heads is a sense of how the real world works.

• If the virtual world mimics this, it helps immersion tremendously.

• Players need rarely think beyond the level at which they can “just do” something.

• This is the level at which commands should be written.

• The physics usually needs to be constructed only at the next level beyond this.

• The problems come from the fact that in many cases the physics is not written even close to this next level, if indeed they’re written at all.

This being the case, designers have only limited ways to respond. In worst-first order, these are

• Brazen it out. The virtual world has ponds; players can walk on the surfaces of the ponds; big deal.

• Knee-jerk reaction. Players can’t walk into ponds, for no in-context reason.

• Remove the symptoms. Players can’t walk into ponds because the vicious fish that live there keep them out. This provides an in-context reason, but it’s invariably feeble.

• Paper over the cracks. There are no ponds in this virtual world.

• Implement the physics. Characters who walk into the pond can stand there with water coming up over their knees and wetting their clothes as expected.

Players’ commands imply the virtual world’s physics. In deciding the level of physics to implement, designers should therefore look at commands.

The Big Six

Surprisingly, there are only six categories of commands for virtual worlds, only half of which are in-context. Implement these and you have the makings of a basic virtual world. The big six are

• Exit the virtual world (“quit”).

• Get playing instructions (“help”).

• Make a note (“bug”) ¹.

• Communication (“tell,” “say,” “shout,” “pose,” and so on).

• Create/destroy object (“chop wood”).

• State change (movement, “get,” “drop,” everything else).

Of these, the last one is the most important from the point of view of the virtual world’s physics.

Tangible objects in virtual worlds have properties, which in turn have values. Properties can take many forms: “Mass” might be an integer; “label” might be a string; “location” might be a set of co-ordinates; “contents” might be a list of objects; “components” might be a treelike data structure. Some of these values may be independent; others may be recomputed each use because they depend on many factors (for example resistance to magic).

State-change commands alter properties. A simple “get,” for example, entails changing the location of an object from the floor to the character; movement involves changing the character’s location property from one point to another; “open door” means changing the door’s “opened” property to true.

It’s more complicated than this in practice, of course. There are all manner of preconditions that need to be satisfied (objects can be too heavy to pick up, or tied down, or on fire, or being stood on, or plenty of other irritating things); there is feedback to be generated (you see the door open, as do people on the other side of it); the properties themselves can take different forms (location as co-ordinates or as a contains/contained-by hierarchy). From the designer’s point of view, though, the actual mechanics aren’t particularly important; of more interest is what can be done with them. This is because everything tangible except object creation/destruction can be done with them.

This means that the properties you choose set the level of player commands, which in turn set the level of the physics. If the properties are fine-grained (as they might be if you kept a record of how many roses were growing in a bush, say), then the commands that change these properties must also be fine-grained—therefore, the physics that underlies the commands must be slightly finer-grained yet (because it’s what gives the properties their meanings). It makes no difference whether people use the commands frequently or infrequently; once you have that level of detail, you have to support it.

Similarly, by going the other way and having coarse-grained properties, you get coarse-grained commands. If flowers are properties of a garden rather than objects in their own right, characters can’t ever do so much with them (which means less detailed work for your physics).

As for what level of detail to go with, that depends on both the virtual world and the real one. It depends on the virtual world because some contexts need finer-grained properties that others can do without. A murder mystery detective game, for example, would need many detailed properties for each object, because meticulousness is a feature of detection; a space opera game would be able to gloss over most such properties because it concerns the grander scale. However, in all cases real physics is absolute. Players will have certain expectations, which they will proceed to act on. If you encourage them to look deeply, they may look deeper than you can manage; if you encourage them to look only superficially, it may be too superficial to satisfy their natural curiosity.

All that designers can really do here is to put themselves in the position of the player. Imagine what the completed virtual world would look like, then consider what players would want to do in it. Create objects to this level, set properties for objects at this level, and specify commands that operate at this level. From that, you’ll get your physics level.

I’ll discuss properties of objects in more detail shortly ². For the moment, though, we’ll keep with the basic underlying physical system and ask the question: What happens when you want to model something that’s impossible in the real world?

Beyond Real-World Physics

Reality can cope with more detail than virtual worlds ever can because it has more resources. However, there are two cases where the scope of virtual world physics extends beyond what reality can offer.

The first of these is that the virtual world interacts physically with a meta-world (reality), whereas reality does not ¹. Players in the real world can become personae in the virtual world, therefore a virtual world can influence the real one through its players (and vice versa). The commands that best illustrate this are those concerned with communication. There are four types:

• Within the world, within the fiction. Commands based on real-world physics are implemented within the context of the virtual world. Examples: “shout,” “say,” “whisper,” “pose”/“act”/“emote.”

• Within the world, without the fiction. Commands in the virtual world have functionality beyond what’s possible in the real. Examples: “tell,” “mail,” group channels.

• Without the world, within the fiction. Material that concerns what goes on in the virtual world is created in the real and presented in-context. Examples: newspapers, criers.

• Without the world, without the fiction. Material that concerns events in the virtual world is presented apart from it. Examples: IRC, email, rant sites.

The second example of where virtual physics can go beyond real physics is in the area of ultraphysics. This concerns things that people are prepared to accept as extensions to mundane physics, whether or not they’re actually compatible with it. Examples include faster-than-light travel, psychic powers, cybertechnology, prayer, time travel, and (everyone’s favorite) magic. None of these phenomena can be demonstrated today with any reliability, and for some it’s unlikely they ever could be. However, sufficient numbers of players have an understanding of the tropes that it’s possible to accommodate these ideas into virtual worlds. It’s sometimes necessary to produce a fiction to indicate which of several sub-tropes a virtual world is adopting (does this magic work using mana, spell memory, gesture programming, and so on), the decision having been made for gameplay reasons. As long as it’s something that fits into the players’ naïve ultraphysics, though, it’s acceptable to them.

Any ultraphysics needs to be implemented with the same rigor as regular physics. Players will not flinch while telling you that vortex-breathing dragons are unrealistic, whereas fire-breathing ones aren’t. In the same way that your virtual physics must adhere to players’ naïve physics, your virtual ultraphysics must adhere to players’ naïve ultraphysics. Ultraphysics is not as supportive of immersion as real physics, but jarred ultraphysics is every much as unsupportive of it as jarred real physics.

The level at which ultraphysics is implemented is determined by the commands that use it (as spells, through skills, using artifacts), which in turn depend on the same kind of properties as real physics. There is great scope for experiment here. Just because every other virtual world implements magic in terms of one-off, powerful spells, that doesn’t mean you have to. Why can’t mages cast spells as often as archers shoot arrows? Why can’t spells have continuous, streaming effects, so you can direct your healing stream towards whoever needs it? Why can’t magic take time to work, so you have to guess who’ll need the effect when it finally hits? There are many dimensions along which changes can be made, all of which can be adapted into the vague notions that players have of the ultraphysics that deliver it. You cast a spell, a fireball appears; how you cast the spell and how the fireball appears is for the virtual world to determine—players don’t care, so long as they get the fireball.

An awkward consequence of ultraphysics is that it doesn’t mesh well with genres that are based on real physics. Fantasy books may be able to ignore the consequences that winged horses have on castle construction, but they don’t have to deal with airborne cavalry units landing troops behind fortified walls and wreaking havoc. Player characters may take advantage of the inexpensive healing and curing facilities of temples, but if NPCs did then the world would be a very different place.

A final point to mention about ultraphysics is that it allows for hyperdimensionality. Graphical worlds are less capable of handling this than textual ones, because they have to present a view of the virtual world that’s rendered in the real one. Textual worlds can have objects inside themselves, objects bigger inside than outside, sounds you can pick up, and so on. Graphical worlds can have some hyperdimensionalities that textual worlds traditionally find difficult (such as portable holes), but on the whole they’re not as flexible.

Objects

The rule with objects in virtual worlds is integrate everything.

When a virtual world is implemented, the entities of which it is constructed are its objects. The relationships between these entities are their properties. Together, objects and properties comprise the tangible part of the virtual world, which the physics brings to life. It doesn’t have to be this way—you could in theory devise a system where objects are mere consequences of interactions between fundamental equations in the same way that numbers are. If you try that, good luck.

It is essential for designers to recognize that although many objects in their virtual worlds have wildly different characteristics from many others, fundamentally they’re the same. They can be arranged into conceptually useful groups—player characters, mobiles, containers, rooms, portable objects, fixed features, and so on—but it’s a big mistake to treat these as unrelated, partitioned sets. You’ll get much better coherence (and a much better understanding of your own world) if you consider them to be specializations of a general abstract object rather than the roots of their own abstract hierarchy.

For example, suppose you decide that your player characters should have a “health” attribute. It would be an obvious step to use this same property to record the health of mobiles. You might also want to give ordinary objects a “wear” rating to track how close they are to falling to pieces. It should then occur to you that “wear” is measuring the same kind of thing as “health,” therefore you should use “health” rather than “wear. ¹”

This may seem rather obvious, but all too often it’s not ². In the early days, all MUD designers were also programmers, and it wasn’t until they picked up on object-oriented programming language ideas that some of them were prepared to accept that hey, maybe rooms and player characters are just objects after all? This is somewhat ironic because it turns out that the objects of virtual worlds don’t correspond well to the objects of an object-oriented programming language like C++. To explain why, I’ll have to digress for a while (but I’ll try to keep it short).

In an object-oriented programming language, there is a hierarchy of object classes. Individual objects are instances of a class. Thus, you might say that doubloons are a kind of coin, coins are a kind of treasure, treasure is a kind of portable object, and portable objects are a kind of (root) object. Although I’ve used the word “object” here, in programming terms these would be classes. Doubloon33 might be an instance of the class “doubloon,” which would make it an object. The power of object-oriented programming lies in its removal of repetitions: I don’t have to define “get doubloon1,” “get doubloon2,” and so forth, I only need to define “get doubloon.”

If objects can be instances of more than one class, or classes can be subclasses of more than one superclass, you have a multiple-inheritance system. Otherwise, it’s a single-inheritance system. For virtual world design, a multiple-inheritance system is highly convenient. If a room contains a doubloon, a penny, and a Ming vase, then when I issue the command “get coin” I want to pick up the doubloon and the penny; if I try “get antique” then I want the doubloon and the vase. The doubloon is both a coin and an antique, but not all coins are antiques and not all antiques are coins. It’s a common occurrence: Not all mammals are carnivores and not all carnivores are mammals; not all pop stars are men and not all men are pop stars. Is the queen of diamonds primarily a diamond or primarily a queen?

Unfortunately, programmers are likely to want to use C++ or some derivative (for example, Java) that only uses single inheritance{Erratum: C++ does has a form of multiple inheritance, (somewhat ironically) using the virtual keyword.}. They’ll see that there are “objects” in the virtual word, they’ll tie these to the “objects” in their object-oriented system, and then 95% of the way through coding they’ll hit difficulties. It’s possible to fake multiple inheritance in a single-inheritance system, just as it’s possible to fake single inheritance in a flat system. It’s a lot of work and it involves a lot of repetition; it’s still doable, though.

What isn’t so doable is inheritance of commands. Object-oriented programming involves the association of items of code (called methods) to object classes. These are not themselves objects; they don’t exist in an inheritance tree. In other words, I can’t say that the method “punch” is a subclass of the method “hit.” If I want 30 different ways to hit something, I have to implement them separately. If I want the effects to differ depending on whether the objects I hit are soft or hard, I have to repeat for each. For large or complex worlds, this can rapidly get insanely tedious both to implement and to maintain. Object-oriented programming is about removing mindless repetition, not about enforcing it.

This situation arises because the virtual world “objects” were a bad choice for the programming language “objects.” Instead, commands should be the objects. If “hit object” and “hit soft_object” are defined as (object-oriented) classes, then a command like “slap cushion” is an instance of a command (in this case the second one), from which the associated code can be located and run. It’s essentially a programming issue rather than a design one, but because of the heritage of virtual worlds it has made it into the design paradigm. Designers often think in terms of objects and methods when they should be thinking of multiple inheritance hierarchies and commands.

Okay, end of digression.

So, object classes in virtual worlds are generally arranged in some kind of hierarchy. This allows the sharing of properties, which encourages integration, which in turn delivers coherence. The days when you had to “ring bell” because “hit” was already taken by “hit creature” are gone ³.

If asked, most designers would probably subscribe to the idea that integration is good. Sadly, though, they often don’t give it much thought. Spells and skills have much in common, for example—they’re the ability to perform a specialized task to a particular standard, which has to be learned. Few virtual worlds consider them at all related, though. Similarly, what player characters might have as skills or spells, artifacts could have as effects or enchantments. If I can learn to cast a lightning bolt spell, then why can’t a magical staff be taught to do it, too? This approach has been used in single-player role-playing games (for example, Larian Studios’ Divine Divinity), but it’s uncommon in virtual worlds.

Although much of this discussion on objects has concerned textual worlds, it applies equally well to graphical worlds.

Graphical worlds are generally nowhere near as functionally rich as textual ones, but the gap is closing; sooner or later, the limits of using single inheritance for virtual object classes will become an issue. You can get 95% of the way without multiple inheritance and the ability to quantify over actions, but then that last 5% becomes important.

Common Problems with Objects

Given that virtual objects are, on the whole, intended to exhibit behaviors at the physics level that are consistent with reality, it might be expected that there are common problems that recur whenever some particular aspect or other of reality is considered. This is indeed the case: Some facets of reality are easy to implement and others are downright impossible. Many of these issues arise because what human beings think of as an “object” is actually just a conceptual entity. It works for naïve physics, but naïve physics doesn’t have to implement it.

There are conventions to solve some of these issues, but, as usual, it’s better if designers understand why a convention is in place rather than merely accept that it is in place. Who knows, you might well be able to provide a better solution if you understand the issues.

Let’s look at them, then.

Solids: Assemblies

Assemblies are objects that are made of other objects. Is an iron key magnetic? Yes. Is a hatchet? Well, the head is. What about a pair of jeans? Not really, unless you include the zip and the rivets (if they’re steel rather than copper).

People think of objects as unitary items most of the time, but they’re quite happy to consider them as being made up of other objects should the need arise. In virtual worlds, this poses something of a problem. If objects are made out of other objects, those objects must also be made out of other objects, and so on until you reach a point where you just have to stop. Where does that point lie? Conversely, if objects aren’t made of other objects, how do you refer to components of an object? Doors must have keyholes if they have keys, right?

By convention, virtual worlds do not have assemblies. You can’t take objects to pieces. If you need to refer to a part of an object, the part is synonymous with the object as a whole. When I can look through a keyhole, I’m looking through a door.

The reason that assemblies don’t exist is, quite simply, that the physics to support the functionality isn’t up to it. Properties are associated with objects, not with configurations of objects; if you were to associate properties with configurations of objects, those configurations would themselves effectively be objects.

For example, suppose in real life I had a wooden ladder. I can climb up a ladder. I can’t climb up a xylophone. Nevertheless, I could dismantle my ladder and use the components to make a xylophone. I can play music on a xylophone, but I can’t on a ladder. The xylophone assembly uses the same objects as the ladder assembly, but the two have very distinct properties.

Now it’s possible to hack a solution to this. You could say that “dismantle ladder” or “dismantle xylophone” destroyed the original object and created two new objects, “poles” and “nails.” You could then allow “make ladder from poles and nails” and “make xylophone from poles and nails.” Unfortunately, unless you’ve thought of it in advance, the player who tries to “make fence from poles and nails” is going to be disappointed.

In the real world, objects are only objects because people say they are. It’s just a semantic ploy to describe certain manifestations within reality. Indeed, objects don’t even have to be real: “If I had a sister, her name would be Moira;” “Nobody followed me.” People routinely refer to objects that don’t exist, and not only in terms of counterfactuals or uninstantiated variables. Whatever your view on religions, you have to admit that Zeus, Jehovah, and Vishnu are mutually incompatible beings, yet to some people they are (or were, in Zeus’s case) as real as rocks.

In virtual world terms, all objects are as real as rocks (or at least as virtual as virtual rocks). They exist because that’s how players understand their environment. However, whereas people in the real world can call upon new objects when the muse takes them, in virtual worlds this can’t happen. Objects only get the properties they’re given; assemblies can’t be granted arbitrary emergent properties depending on their construction. You can’t invent objects, just new uses for existing objects.

Virtual worlds don’t have assemblies because it only pushes the problem one degree away. At some stage, you have to stop. If you’re going to have to stop anyway, why even start? Players will try to disassemble objects, fail, have their immersion hurt, then give up trying. If the precedent of assemblies has been established, they’ll keep on trying because sometimes it works and sometimes it won’t. Each failure will hit their faith in the simulation of reality.

However, taking the same line of reasoning that I did earlier with NPCs (that is, even rudimentary AI is better than none), it can be argued that any consistent-depth implementation of assemblies is better than none at all. An axe is made of a shaft and an axehead; an axehead is made of six pounds of iron; six pounds of iron is made of two three-pound pieces of iron melted together, and so on. By defining all objects to be constructed from other objects and a limited number of recognizable resource “atoms” (which break down into ever-smaller versions of themselves), assemblies can be implemented. Although not a perfect system (every object type needs a “recipe,” so new objects can’t be constructed unless a recipe for them exists), this is a definite improvement over no assembly at all: It allows for additional gameplay, and is even better in terms of the immersion it delivers.

Nevertheless, players who try to build a glider from sails and broken barrels are probably wasting their time.

Solids: Collections

Some objects are sets or collections of other objects. You might have a bunch of flowers, a pack of cards, or a wad of notes. Using a principle of no-disassembly, these should be unitary items. They all have problems with this, though.

A bunch of flowers is fine as long as you have no individual flowers anywhere. Put in a single rose, and suddenly you’re accepting the concept of unbunched flowers. Players will therefore want to take flowers out of the bunch.

A pack of cards only exists when no one is playing a game with it. Because cards are meant to be played with, you can hardly blame people for wanting to deal out the pack. When that happens, suddenly there are 52 individual cards (plus jokers) and no pack. You only get a pack again when someone collects all the cards.

A wad of notes has critical value. Although you might want to allow players to pick up pebbles from a beach arbitrarily, you can’t let them peel notes from a wad in that way or they’ll be rich in no time. However, if you make each note in the wad an individual object, how do you refer to the wad? Can you split it in two and get two wads?

These problems arise because although players will think of objects at a particular level a lot of the time, for similar objects (in particular) they like to stack them together and treat them as an abstract whole. Designers must decide whether to allow non-functional assemblies like this, and, if so, how to handle them.

There are two ways, alluded to in the preceding paragraphs. The first is to enumerate all the objects that make up a collection, but report them as a collection based on the number held. If you have three playing cards in your inventory, they’re shown separately; if you hold seven, they’re shown as a “hand;” if you hold 52 (plus jokers) they’re shown as a “pack.” Similarly, if you have a rose and a tulip, you have a rose and a tulip; if you have a rose, a tulip, and a daffodil, you have a “bunch of flowers.” The designer lays down the criteria for when individuals become (or cease to become) a collection.

The second way is to use a generator. There are so many flowers in the garden or nuts on the tree or locusts in the swarm that it’s pointless enumerating them. If a player wants one, they can have one. There is effectively an infinite number. For these collections, a dispenser function creates a new instance each time the collection is taken from; when an instance returns (or collections merge) the incoming items are deleted and the collection remains as it was ¹. If a graphical world has a beach texture-mapped with pebbles, characters can pick them up this way. The texture map doesn’t change, but the characters get an object they didn’t have before.

Collections are used as shorthand for quantities of objects. It’s possible (but not essential) to give them properties beyond what the individual objects have—for example, giving a set of collectible bubble gum cards a greater value than sum of the values of each individual card. Oh, and yes, every other designer in the world has thought of making collections of too many uranium chips invoke an atomic explosion.

Solids: Containers

Objects in virtual worlds can be in various hierarchies. The main one is the class hierarchy (X is a kind of Y), but other possibilities include an assembly hierarchy (X is a component of Y), a spatial hierarchy (X is on top of Y), and a container hierarchy (X is contained by Y). The latter two are related, as we’re about to see.

Container hierarchies are useful because they give players physical means by which to move around groups of objects in a virtual world. They’re not essential: In the same way that early computer operating systems didn’t have the equivalent of subdirectories or folders, so some early virtual worlds (most notably Shades) didn’t have containers. However, they’re very useful. In a nodal implementation of a virtual world, the work is already done anyway: Rooms can contain characters, characters can carry (that is, “contain”) objects, therefore, it’s not a huge leap of the imagination to allow objects to contain other objects too.

Virtual worlds that use a co-ordinate system to handle location typically have to switch to a nodal system for containership. Although it’s possible to extend the co-ordinate approach to allow objects to be carried around in backpacks and pockets and on belts and so on, in practice it’s too inconvenient for the players. It’s no fun for the programmers, either, having to lock arbitrary objects onto the co-ordinate frame of a character so that wherever the character moves, so do the objects. For this reason, most graphical virtual worlds maintain a separate inventory for containership, using a co-ordinate system only for the top level (which can more easily be displayed graphically).

Graphical worlds don’t have a problem illustrating the spatial relationship between objects. You can see that the bottle is on the table, the chair is next to the table, the boots are under the table, and so on. This is because of the rigid spatial structure imposed by the co-ordinate system. Nodal systems do not have this underlying structure: If two objects are inside a room, that says nothing about the spatial relationship between the two. Even the connectional relationships between two adjacent rooms are not implied; they have to be stated explicitly. Some nodal virtual worlds—for example, those developed by Skotos—do have a relationship network between objects. However, without absolute co-ordinates it’s hard to make deductions: If X is next to Y and Y is next to Z, is X next to Z? Co-ordinate systems have this problem too, of course, when it comes to modeling the contents of containers. Fortunately, most players don’t care to think beyond “X is in the bag”—they’re not really worried about where in the bag, so long as it doesn’t move around and they can get at it when they want it.

Containers are usually limited in what they can contain. They’ll hold only a certain volume (or number) of objects. Sometimes only objects below certain dimensions will go in (you can’t put a table spoon inside a beer bottle) and sometimes only objects above certain dimensions will stay in (you can’t store pencils in a net bag). The containers may be rigid or soft, opaque or transparent, closable or always open—the same kind of properties you get for many other objects. There are some particular issues that containers have which don’t affect other objects, however.

Most containers are endocontainers, in that they contain things inside them. Chests, bags, bowls, baskets—they all enclose what they contain. There is also, however, a smaller class of exocontainers; these contain other things outside them. Music stands, hat racks, and Christmas trees are examples of exocontainers. Exocontainers “wear” what they hold.

Some virtual worlds treat exocontainers and endocontainers as totally distinct, on the grounds that holding by enclosure is fundamentally different to holding by hooking or tying or anything else. The concepts are indeed disjoint, of course, but there is enough commonality that it’s generally better to treat them as the same thing. “Take music from stand” and “take stand from case” are essentially the same action and can be implemented using much the same functionality.

The key differences are in two areas.

Firstly, although the contents of an opaque endocontainer can be concealed from prying eyes, you always see what an exocontainer is holding. This isn’t too bad for textual worlds, but graphical worlds need to be able to construct animated images to match the almost arbitrary clothing permutations that players will try, which can be very tricky ¹.

Secondly, for endocontainers, the containers protect their contents. If you hit an endocontainer, the amount of damage suffered by what’s inside may be reduced. For exocontainers, the reverse applies: The damage suffered by the container may be reduced because it’s absorbed by what the exocontainer is holding. This is how armor works.

This brings up the subject of a very special endocontainer: the player’s own character. In Fantasy worlds in particular, things the character carries or wears are position-sensitive. You don’t put helmets on your arms, you don’t put boots on your chest. Graphical and textual virtual worlds both have problems with this.

Graphical worlds have adopted a standard from single-player computer role-playing games, whereby an image of the character is displayed with the “slots” (usually) indicated, and players dress it up paper doll style ². Although not exactly immersive, it’s in keeping with the way that the inventory in general works. Textual worlds have more to worry about because players want to refer to body parts. It’s okay to have “wear socks,” “wear cravat,” and so on, but players want “wear ring on left index finger.” This implies that bodies should be treated as assemblies. They’re not assemblies that players will typically want to dismember in a controlled fashion, and, except for in Horror genres, people aren’t going to care to reassemble new bodies from parts, either. Nevertheless, if players want to reference parts of an assembly then the assembly has to be constructed or faked up; either way, it’s very tiresome to implement and clue players in to the fact that assemblies are possible. First it’s bodies, then suits of armor, then horses, then carts—before you know it, you’ve gone way further than you ever wanted and it’s starting to have an impact on response times. If you do decide to implement bodies, make the decision then and there whether or not it’s a one-off, and stick to it. You won’t be swayed, you have a will of iron….

What about books, then? Books contain pages, but those pages are fixed in a certain order, so they’re basically assemblies. If someone wants to “read page 24” are you going to let them? Or are you going to keep your books really short, so they only ever have one page?

It can be very tempting to turn a container into an assembly. Be careful.

Turning containers into generators is also tempting, but much less dangerous. A bag of nuts that always has nuts in it no matter how many you take out is fine, as long as you don’t let anyone turn it inside out. A coat rack in a shop can have a fixed number of coats hanging from it, each of which is created using a lazy evaluation approach (that is, only when someone tries to access a coat is one created).

The final thing to mention about containers is the notion of encumbrance. This is an old (some would say dated) idea from table-top role-playing games. In general, the weight of objects that a container ³ can contain depends on its strength; the number it will hold depends on the dimensions of the container and of the objects concerned (although for exocontainers it also will involve some measure of viable contact points—that is, the container’s dexterity). However, objects are often so awkward that they slow you down much more than others of a similar weight or shape would. An open umbrella is harder to handle than a closed one; a helium balloon gets in the way more than a soccer ball (both of which are easier to keep a hold of if they’re deflated).

The idea behind encumbrance is to quantify how much something affects the attributes of its container by virtue of its own attributes. It’s an imperfect abstraction, but at times it can be a useful one. Even a virtual world that stored the exact dimensions of objects would still have to approximate some computationally expensive calculations—for example, knapsack-packing problems (emptying a full knapsack, then getting all that was in it back inside is non-trivial—it’s like doing a 3D jigsaw puzzle).

Fluids: Divisibility

Most objects in virtual worlds are solids, and that’s how they’re implemented. However, when modeling the real world it’s a little hard to avoid the presence of fluids, especially water ¹. I use the term “fluids” rather than “liquids” in order not to exclude those solids that (in naïve physics) act like liquids, such as sand, ash, and flour; I also mean it to discount substances like glass that are formally liquids but on human timescales act mainly like solids.

The central problem with fluids is that they’re indefinitely divisible. You can split them apart and combine them arbitrarily ². If someone has a bottle of water and a glass, they should be able to fill the glass with water and have the excess remain in the bottle. This can be faked by giving all fluid-tight containers a pair of properties to indicate what fluid they have in them and how much, or it can be implemented “properly” by creating separate objects for each chunk of fluid that have their volume as a property tied to them. The latter is generally preferable because it means that fluids can be referenced and that they can exist independently of containers (for example, if you tip them out onto the ground). Tiresome players may create thousands of fluid objects by decanting from a large container into a tiny one many times, but so long as you’re aware of this possibility it shouldn’t be hard to prevent it from causing problems.

Beyond a certain size, large bodies of fluid can be regarded as generators. You can take as much saltwater as you want from the ocean, there’ll always be plenty left. In practice, the amounts of fluid that can be used as generators can be much smaller; a beach has an inexhaustible supply of sand, and even ponds and private swimming pools can be considered effectively always full. Because virtual worlds aren’t real, it’s even possible to have small containers generate infinite amounts of a fluid ³.

There are potential difficulties when fluid is tipped out of a container into the environment. It’s not a problem if there’s already a fluid on the surface, as a large body of any fluid can safely be assumed to absorb (or otherwise disperse) any chunk of fluid added to it. Emptying oil into a (virtual) freshwater lake just destroys the oil no matter how often a player does it.

When the surface does not already have a fluid on it, that’s another matter. On a smooth surface the fluid may flow away downhill, whereas on a rough one it could form pools or puddles; for a rocky surface or a boardwalk it could disappear immediately between cracks; for dry earth it could simply be absorbed. What actually happens depends on the surface and the fluid. At the very least, it implies that all surface types need to be classified so that the physics can determine what to do.

The final divisibility issue concerns leaks. Leaks can be regarded as loss to volume that occurs over time. Although in real life a fluid that seeps from a leaky container can leave a trail, this is quite hard to implement in practice. In general, if a bucket has a hole in it then all means is that the amount of fluid it contains will lessen at a constant rate until there’s none left. It doesn’t mean you can fill the bucket with sand and try to write your name on a field.

Miscibility

Immiscible fluids pose few problems. If you have a pint jug containing half a pint of sand, you can top it up with water. Although in real life you’d be able to get more than half a pint of water in (because sand is a fluid, but not a liquid), in practice you’re not going to upset many players if you keep it to exactly half a pint. The same applies to adding fluids to containers that already hold solids: You may as well compute volumes assuming that none of the solid objects float, because even if you account for partial displacement you’ll never get it sufficiently accurate to satisfy anyone pedantic enough to check anyway. Immiscible fluids are implementation-friendly. Miscible fluids are implementation-unfriendly.

If you have half a pint of alcohol and add half a pint of water to it, what you get is a pint ¹ of weaker alcohol. If you added water to poison, you’d get a larger amount of weaker poison. If you added poison to alcohol you’d get something that was half toxic and half intoxicating. Mixing fluids involves mixing properties of fluids. This wouldn’t be so bad if it weren’t for chemistry ².

By default, all solids are immiscible with liquids. However, some solids are affected by fluids in a major way. You might be able to package sugar in a paper container, but water would rapidly disintegrate it. The result of the exercise would be water and sludge, neither of which has the properties that a paper bag has. With fluids, you can add an acid to an alkali and get salt and water; neither the salt nor the water has any of the corrosive properties of acids or alkalis. Thus, mixing fluids can involve not only the creation and destruction of objects, but also the creation and destruction of properties of objects.

The keener designers among you might at this point be envisaging a nice chemistry system with a wide range of properties that fluids can have and a series of rules that govern how two or more properties combine to create other properties from the list. This could actually work quite well, and explorers would certainly thank you for it. Whether it’s worth the effort involved when you could be doing something else is another issue, of course, and the fact that the recipes for anything that can be brewed will be on player web sites within days might take some of the fun out of it. If you have the time, though, hey, go for it!

One final point about liquids is that viscosity can be a pain. Apples and honey are immiscible, but if you dunk an apple in honey and take it out you’ll end up with a lot of honey stuck to the apple. Whether or not you want to make the apple a leaky exocontainer for the honey is up to you, but either way be sure you cover the inevitable player experiments with it (“How come honey drips off kittens at the same rate that it drips off apples? Surely the fur would retain…).

Gases

Virtual worlds rarely implement gases, and when they do it’s often as consequent properties of a location or some other object, rather than as objects in their own right.

The reasons for this are to do with the physical properties of gases (and of gas-borne particles, such as pollen and smoke). Gases are everywhere, they have miscibility and divisibility issues even worse than those of liquids, and they’re hard to contain.

Characters can do simple things like breathe them and smell them, but anything much more sophisticated entails capturing the gases, which then renders them inaccessible without the right apparatus. Some virtual worlds have gases dropped by certain monsters on death, but the result is rather clunky.

Air (or atmosphere) can conveniently be regarded as a generator object that’s available to all locations and containers. Sometimes, though, it’s useful to represent chunks of gases with unusual properties as separate objects. This allows for gusts of winds, clouds of dust, explosions, temperature gradients, swarms of tiny insects, foul stenches, and so on.

On the whole, though, the only gas that virtual worlds really need to consider is air, and then only for completion. Graphical worlds don’t need even air ¹—it’s “what there is when there’s nothing else there”—but textual worlds should account for it because players in that context reference objects by name, rather than by pointing device.

Plasmas

In most virtual worlds, the only significant plasma is fire. Fires are usually treated as individual objects, but not always entirely realistically. It’s easy enough to model them to emit virtual heat and light, but the problem is that in real life fires spread. In virtual worlds, they don’t. You can set fire to combustible materials and they’ll burn; they may even ignite nearby objects. However, they won’t usually spread to the environment.

There are two reasons for this. The defining one is that it’s very hard to do! Fires are transforming events: If you drop a lit match in dry grasslands, you transform it into a charred landscape; trees are replaced by blackened stumps, buildings are empty shells, and everywhere is bereft of life. Predicting the collapse of structures when arbitrary parts of them burn away is very difficult.

The second reason is that even if out-of-control fires could be modeled, it would be unwise to have them. Half of all real-world property fires are due to arson, and the temptation to destroy a virtual world that way would be irresistible. Even players who weren’t crazed vandals might try it out just the once. “Gee, do you think I’d get experience points for killing 200 bears if I set fire to the woods?”

State Changes

When you heat up water, it turns into a gas (steam); when you freeze it, it turns into a solid (ice). Similarly, gases can condense and solids can melt. These are state changes. Do you want them in your virtual world?

A virtual world can be satisfyingly convincing without state changes. If you don’t have any way to heat up things or cool them down, explorers might figure out why and get uppity but most of the population will take it in their stride.

On the other hand, state changes aren’t all that hard to implement and can impress the players. It can be done quite easily as a destruction/creation pair: Destroy the steam, create the water; destroy the lava, create the rock. In real life, state transitions take energy to effect (it’s how refrigerators work), but in virtual worlds where people don’t have accurate thermometers, there’s no need to worry about it.

Properties

Properties are abstractions of objects’ physical characteristics. In virtual worlds, this regularly extends to non-physical properties as we shall shortly see, but it’s the physical ones (mass, density, shape, color, and so on) that dominate.

Properties are often implemented as functions, so that rarely used ones can be computed on a when-needed basis. However, although properties don’t change any values when they are called, functions in general do: Checking the “diameter” property of a balloon won’t change its diameter ¹, yet calling the “inflate” function on the balloon might. In terms of implementation, though, they can look the same.

Properties have an uneasy relationship with object classes. Does a dropped bottle shatter because as a bottle it’s a subclass of “fragile objects”? Or does it shatter because it inherits a high-value “fragile” property? How much encapsulation do you need? Perhaps it shatters because it has a “made of” property with value “glass,” and glass has a high-value “fragile” property?

Creating a taxonomy that allows the physics to be implemented but doesn’t turn designers into programmers is a tricky area (made all the worse because many designers started out as programmers). Strictly speaking, it isn’t a naïve physics problem, but an issue of representation.

Unfortunately, there aren’t really any conventions at work here (yet). You just do what you have to for your physics to work. All I would recommend is that you allow for properties to be objects (in the object-oriented sense) too, so you can quantify over them. If you can get the virtual world engine to answer the question “give me a list of all the properties of this object and their associated values,” then that should be flexibility enough.

As an aside, lists of existing properties are very useful to have around when you’re looking for new ways to discriminate between objects. “What should this magic shield do apart from add the usual protection bonus? Hmm, characters have properties for height, mass, speed, hmm…eye color, hirsuteness—hey, I could make them hairy if they used the shield! That could really freak people out. I’ll make it a dwarfen shield because dwarfs value beards, females included, and….”

In an ideal world, could all functionality of objects be derived from their properties? Yes—in an ideal world. You could see that an object has a hard, thin, flat, robust, semi-sharp surface attached to a long, strong, lightweight but not brittle second component topped by a horizontal bar, and from that deduce that the object was suitable for digging a hole in a lawn. Virtual worlds are non-ideal, because this degree of functionality deduction would overwhelm it. Being non-ideal worlds, you can dig a hole with a spade because the “dig” action knows about spades (and maybe shovels and pickaxes). Beyond that, you can’t make a spade out of a busted shield and a fence post.

So sorry fans of assemblies: You’re unlikely to get them this way soon, either.

Ownership

It may seem odd to include a subsection on ownership when discussing physics, but (as pointed out in Chapter 3) ownership can be considered a physical quality for virtual worlds. Note that this is virtual ownership—that is, ownership within the context of the virtual world; real-world ownership of virtual objects is all about data and intellectual property (as is much else about virtual worlds).

There are two ways to implement ownership. The first is to give all objects an “owned by” property, which can be either empty (for example, no one owns characters) or point to some ownership-capable object (for example, a character, a guild). The second is to make it implicit: You own whatever you carry. The latter works for virtual worlds with low degrees of persistence.

The former would be preferred for ones with higher persistence, except that it gets horribly complicated; they therefore extend the “possession is nine tenths of the law” concept to stuff stored on player-owned property, but don’t track who owns individual objects in general.

At this point, you may be wondering why not. Computers are very good at bookkeeping tasks, and this is just bookkeeping, right?

Right, but the problem lies with formulating the rules.

Suppose character A owns a bottle of champagne and character B owns a bottle of orange juice. They both put their bottles on the ground; they still own them. I pick up the bottles; they still own them, and I’m a thief. I empty the contents of the bottles into a bowl and mix them up; who owns what now? I probably don’t own it, but does character A or character B? Most of it may be character B’s by volume, but character A’s by value.

This same sort of tracking problem arises for components of assemblies and collections. If I steal five units of currency from each of five players, then lose 18 UOC in a bet, who can lay claim to the 7 UOC that I have left?

The simple “if I hold it, I own it” rule doesn’t work universally, either. When your character picks up an object, it usually goes into a container; this will typically be some kind of backpack ¹. However, it could be a hand or a sack or…well, let’s see what it could be.

Solid objects in virtual worlds will usually fit into one of the following abstract categories:

• Things that can be worn (for example, a hat)

• Things that can be carried by an individual (for example, a book)

• Things that can be carried by several people (for example, a bench)

• Things that can be moved but not picked up (for example, a cart)

• Things that can move of their own accord (for example, a horse)

• Things that are immobile (for example, land)

• Things that can appear to be carried without actually being carried (for example, coins)

I can wear a hat or carry a book and be certain that it is mine. If I buy a bench and want to move it, though, how can I be sure it’ll remain mine? What about a horse or cart? As with land, some things do need to have their ownership tracked, like it or not.

Even tracking isn’t always the answer, though. If I steal a sword and sell it for gold, does the new owner have to hand it back to the original owner? If not, great: I’ll have my mule do the stealing and my main character do the buying. If so, also great: I’ll have my mule steal the sword and sell it to someone else, then give the newly laundered coin to my main character. In either case, the location of the original sword is known, but the person who stole it is likely to get away with the theft (at least as far as the virtual world is concerned—the players may have other ideas).

Here come the virtual lawyers….

Time

Time is the one dimension that players and characters both share, and therefore it is completely beholden to reality. This does not mean that it has to be identical to real time, but it does mean that it must directly map to it.

Most actions that take place in virtual worlds are pretty well instant (lag permitting). Because of the way that people often routinely regard complex series of actions as unitary commands, there may occasionally be commands that take time to execute (cooking a meal, for example). Also, naïve physics can sometimes call for the effects of a command to take place after the action has been executed (such as the explosion that follows from lighting a fuse). As we saw with fire, some commands can have potentially chaotic effects that last potentially indefinitely. Most commands, though, give an immediate response and do not propagate except in strictly prescribed ways (typically, by giving feedback to characters who can detect the effects of the command).

One consequence of this, which is felt particularly hard in nodal implementations of virtual worlds, is that travel is much faster than it “ought” to be. The time it takes to climb a staircase can be the time it takes to pass through a forest. Speed is measured in nodes per second, which, as nodes don’t necessarily conform to a fixed ground scale, makes a mockery of Newton’s laws of motion. Fortunately, players aren’t spooked by this; as long as travel between two locations that are conceptually “distant” takes longer than travel between two that are “near,” they’ll let it ride. It will be noticed, though.

In graphical virtual worlds, where speed can be measured using the traditional units of ground covered per second, travel isn’t so fast or it would look ridiculous. However, this degree of realism can brutally shrink a world. In the time it takes a character to jog across a “continent” in EverQuest, a real-world marathon runner could perhaps traverse Singapore. Think of the map of Norrath transposed onto the tip of Malaysia and suddenly it doesn’t seem all that huge.

Virtual worlds may be tied to real time, but they don’t have to use it. In some (particularly low-persistence ones), it’s always effectively the same time—the clocks may change, but there’s no night and day. Others take an accelerated, linear approach: DikuMUDs usually map 30 minutes of real time to 24 hours in the game world. A more player-friendly strategy is to do it non-linearly, so that time at night (when NPCs are asleep) passes quicker than time during the day (when there’s more content at large). The number of hours in a virtual day and the number of virtual days in a virtual week, month, or year may vary, but usually there’ll be 60 minutes in an hour and 60 seconds in a minute (if time divisions go that low). Whether or not years increment depends on the context: If a virtual world set in the 1920s ran at DikuMUD time, the whole decade wouldn’t last 11 real-world weeks. Seasons can have a gameplay use, but years rarely do (what, you want characters to get older?!). Virtual worlds with story arcs are a principled exception.

Some virtual worlds add seasonal content related to real-world time. MUD1 had a supply of festive mobiles and objects for Christmas, for example, and MUD2 added more for Easter, Halloween, April Fool’s Day, Bonfire Night (November 5 th—it’s a U.K. thing), and March (there’s a mad hare). Ultima Online introduced the idea into graphical worlds. Although in theory (and occasionally in practice) these are immersion-breaking, on the whole they’re popular with players as they give a sense of permanence; the very fact that a virtual world has seasonal content shows that it’s there for the long haul. Some meager fiction, such as having a “night of the dead” coinciding with real-world October 31 st, can provide any necessary cover. It only works for worlds that don’t have their own internal time, though. Celebrating Christmas in a world where it’s officially Spring is going to seem bizarre; similarly, if virtual Christmas trees appear fully decorated in real July there won’t be many players in the mood.

There are other issues of concern, to do with the religious nature of some of these ceremonies; these are discussed in Chapter 8.

Night and day: What’s the difference? High-permanence virtual worlds need to take a position on the subject; in any outdoor setting based on the real world, night and day are hard to ignore, but in general, one is going to be more fun for the players than the other. A strict implementation would have most NPCs asleep at night and a different set of monsters awake. This provides gameplay differences between the two that can make life more interesting for the players (but of course involves the creation of more content—expensive). As for the more physical differences, well the most obvious one is that it’s darker at night ¹. There are two ways to handle this: by plunging the virtual world into gameplay-changing darkness; by making the virtual world suggest darkness without actually being dark (for example, use a blue wash). Full darkness is probably going to be implemented anyway for expeditions underground, so there are no real practical incentives not to make night as dimly lit as in reality. The reason many virtual worlds go for a cosmetic night that looks more like dusk is because it’s less unfriendly for newbies that way (it’s either that or give them a soon-to-be-mislaid lantern). Graphical worlds also have issues concerning the ability of various video cards to display images with low light levels—what might easily be visible to some players could remain totally unseen by others.

The final point to make about time in virtual worlds concerns traveling through it. All characters do travel through it, of course, in the same direction and at a rate related to real time. They could, if content were available, all travel backward in time or forward at a faster rate (relative to real time). However, time travel for an individual character is not possible: One character can’t go back to yesterday because for the other characters it’s today ². Sealed time discontinuities are possible—you can put a character in a mock-up of yesterday and tell them it’s yesterday—but interaction is limited. If a character “goes back in time” and shuts a door, this can only have consequences for a player in “today” under exact, predefined conditions. Time travel on a global scale—that is, everyone in the virtual world together—is possible ³; on a local scale, though, it’s no more possible in the virtual world than it is the real one.

Proactive Physics

People who play in a virtual world are bound by that world’s physics, as implemented in computer code. Whatever tangible action they undertake in the virtual world, the consequences of that action are defined by the program. Players must accept this as part of the world, just as they must accept real-world physics in the real world. They may object to certain aspects of it, and they may even be able to persuade the live team to make changes, but they can’t opt out of particular rules they don’t like. If they get annoyed by the fact that their magic sword will eventually wear out, they can either continue under protest or quit.

Proactive physics uses this aggressively. Let’s say you didn’t want players to sell virtual objects to each other in the real world. You could give all objects a “sold on eBay” flag that was set (either manually or automatically) whenever an object was exchanged in this manner. Objects so flagged would wear out faster than unsold objects. Players who complain can be told that objects wear out anyway depending on how they’re used, and that being sold in a different world (the real one) puts interdimensional stresses on them that reduce their integrity. There would still be lawsuits from people who felt this unfair, and they may be able to make some argument about the intent (which is essentially the difference between normal and proactive physics); a consistent fiction is a strong defense, though.

Personally, I’m against using virtual-world physics to achieve real-world ends in this way except when it enhances individual freedom. That said, I’m very much of the opinion that all code and data belongs exclusively to the developers to do with as they wish. Virtual worlds are not tools like word processors, which folk use to create data that they own; virtual worlds are places that people visit. If you come to my house and use my paints on my paper to create an artwork, I’m sorry but you don’t own that artwork and you don’t get to sell it to someone else unless I say so.

Whatever deals players strike between themselves about rights of access to virtual entities, they don’t concern virtual ownership unless the developers say so. If players don’t like that, they can either quit and play in a virtual world where the developers cede data ownership to players (and hope that the real-world laws governing the changing of that virtual data are cast-iron) or they can set up and run their own virtual world.

The discussion in Chapter 3 about the rights of players and characters assumes good faith on the part of developers. Proactive physics can be an extension of this, but designers must be very careful not to set the wrong precedent. If a player uses the virtual world’s physics to make life tough for other players, the exploit can be fixed and the perpetrator banned; if the live team does it, only revolt or emigration can ensue.

Reset Strategy

Players consume content quicker than it can be produced ¹. To prevent a virtual world from becoming “played out,” therefore, some mechanism for reintroducing content must be installed—the reset strategy of the virtual world. There are two basic approaches: sudden and rolling.

In a sudden reset, the region to be reset (usually the entire virtual world) is closed down and its content reinitialized. This is a fairly quick procedure, but it can be very inconvenient for players who enter the virtual world at the wrong time or for players who are in the middle of doing something when the reset occurs. The sudden reset strategy is sometimes referred to as the Groundhog Day approach, because players relive the same day repeatedly, as in the movie Groundhog Day ².

In a rolling reset, content is returned piecemeal at a rate roughly equivalent to that at which it is consumed. There is no need for the virtual world to be closed down. Rolling resets as a concept emerged in the second age of virtual worlds, the original idea being to use a “watched pot never boils” system whereby content was slipped in where players weren’t looking (so as to conserve the fiction). This is rarely practiced today, however; indeed, in many virtual worlds players rely on being able to show up at the appointed place and time so they can have a crack at a monster ³. Besides, in a large-scale virtual world, the high probability that individual griefers would stake out a reset site just to stop it from resetting rules the idea out. When rolling-reset content resets, it usually involves only a simple adjustment such as the introduction of monsters or objects; in this context, it’s usually referred to as spawning (or respawning).

Sudden resets allow for much more complex content than rolling resets. Multi-stage puzzles in particular are notoriously difficult to reset in isolation. If a dam has burst and flooded a valley, putting back the water is a problem (more so if people are sailing on it) and so is restoring everything that was destroyed (except for what would have been destroyed but someone moved it first). Sometimes, events have such all-conquering effects that they impinge on all aspects of a virtual world and simply cannot be reset unless the whole world is reset. Thus, a rolling reset strategy is not going to be of any use in this situation. That said, rolling resets are more accessible—players can “drop in, drop out” better—and they are able to support ⁴ much higher degrees of persistence.

Sudden resets interfere with playing patterns more than rolling resets. Players who are present at the start of a reset will often stay for the whole period as they’ll have been able to kit themselves up; players who arrive later may decide that the best content is accounted for and leave; late-comers will consider sitting around chatting until the reset occurs, whereupon they’ll start playing in earnest. For rolling resets, session stickiness doesn’t depend on time of arrival anywhere near as much.

Both sudden and rolling resets are anti-immersion. With a sudden reset, you get a huge dose of reality, but it doesn’t last long; with rolling resets, you get smaller reminders of reality, but they drip, drip, drip the whole time.

Within the context of a sudden or rolling reset there are four main strategies in use to determine when and what resets:

• Fixed

• Contextual

• Requested

• Geographical

A fixed reset occurs after a set time period has elapsed. This is popular for virtual worlds using a sudden-reset approach, as it gives players fair warning of when they’ll be kicked off. It’s also popular for rolling-reset worlds, because spawn-on-timer is very easy to implement and achievers ⁵ like it.

A contextual reset is more sophisticated in that it has metrics to indicate when content is played out; these can then be used to trigger a reset. In practice, though, even with quite large differences in player flow a fixed reset is usually quite sufficient for most situations; virtual worlds using a wholly contextual reset strategy are therefore uncommon, although the occasional spawn-on-completion or spawn-on-character-properties isn’t so unusual.

The requested reset approach passes control of resets over to players. It’s commonly used in conjunction with other reset strategies, although MUD1 used it basically standalone. In a sudden-reset environment, resetting is mainly the preserve of administrators; where regular players are allowed to do it, there’s a vote first. In rolling-reset worlds it’s less of an issue: Players wanting to recycle content (especially bespoke content) for their own characters’ use will often have a quest system at their disposal for this purpose. Although communication with NPCs is the preferred method, spawn-on-character-action is by no means limited to it; there’s good scope for creativity here.

Geographical resets are mini sudden resets. Rather than a particular piece of content being identified as needing a reset, all content associated with a location is reset instead. This allows for slightly more complex content in a rolling-reset world, but in sudden reset worlds merely delays the inevitable. The location that is reset can be as small as a point, although it’s more common to do it by area or region (faking an ecosystem—that is, spawn-by-world-properties). Smaller geographical resets are often spawn-on-proximity, a character’s presence close to an area triggering the content introduction.