• Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint


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[73] 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).

[73] These rules are called naïve physics, and are an example of qualitative reasoning. Patrick J. Hayes, The Naïve Physics Manifesto. Donald Michie (ed.), Expert Systems in the Micro-Electronic Age. Edinburgh, Edinburgh University Press, 1978.

Johan de Kleer, Qualitative and Quantitative Reasoning in Classical Mechanics. Patrick H. Winston and Richard H. Brown (eds.), Artificial Intelligence: an MIT Perspective. Cambridge MA, MIT Press, 1978.

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[74]. As long as people buy into the fiction, this can work. Toontown can be as immersive as EverQuest.

[74] See Cartoon Laws of Physics, which exists in several versions. http://funnies.paco.to/cartoon.html and http://www.bbc.co.uk/dna/h2g2/alabaster/A645095.

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[75]. 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.

[75] Gravity, electromagnetic, strong nuclear, weak nuclear. There may be others yet to be discovered.

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[76]. 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.

[76] As does the number of potential exploits.

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[77]. 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.

[77] A virtual world's physics can itself be regarded as a model for implementing higher-level effects. Consistency benefits from this: If you can get the physics to handle some set piece event, it's usually better than if you hard-code it separately.

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”)[78].

    [78] You could lump this under communication if you wanted, but I consider it to be more fundamental than that.

  • 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 coordinates; “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 coordinates 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[79]. 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?

[79] To save you from getting your hopes up, I'll warn you now that I'm not going to present a list of common object properties. The point of this section, after all, is to persuade designers to think about virtual world physics from first principles for themselves.

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[80]. 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:

[80] Anything reality interacts with physically is by definition part of reality. Theologians and philosophers may argue that there are worlds beyond reality that can coincide with it, but that's not quite the same relationship that virtual worlds have with the real one: We can prove that virtual worlds are part of reality.

  • 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, or what?), 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.


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”.[81]

[81] Just be sure that people don't get their wounds healed at a blacksmith's or get their swords resharpened by a healer.

This may seem rather obvious, but all too often it's not[82]. 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).

[82] There are still plenty of virtual worlds that consider dropping an object on the floor to be a completely different action to putting an object into a backpack.

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 situation: 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. 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[83].

[83] You noticed the sarcasm there?

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[84]. 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.

[84] Note that one false move by the programmers here and you get the duping bugs that are the bane of so many virtual worlds.

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 coordinate system to handle location typically have to switch to a nodal system for containership. Although it's possible to extend the coordinate 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 coordinate 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 coordinate 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 coordinate 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 coordinates it's hard to make deductions: If X is next to Y and Y is next to Z, is X next to Z? Coordinate 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[85].

[85] Even in two dimensions it's tricky. KiSS dolls (Kisekae Set System—digital dress-up-dolls for your computer) regularly have problems with things like flouncy shirts that stick out through jackets worn over them.

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[86]. 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 clues 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….

[86] This is KiSS dolls again. Check out http://otakuworld.com/kiss/ to learn more about KiSS. Warning: Kids love these things.

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[87] 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).

[87] Because they're exocontainers, this includes characters. It's object-oriented programming in action.

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[88]. 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.

[88] Potions and ale are commonplace, too.

The central problem with fluids is that they're indefinitely divisible. You can split them apart and combine them arbitrarily[89]. 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.

[89] Assembly “atoms” can be split apart, too, but combining them takes more effort.

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[90].

[90] As in the joke where a man gets three wishes from a genie. On his first wish he asks for a neverending bottle of beer. The genie obliges, and the man drinks enough from it to satisfy himself that it works. The genie asks him what his other wishes are. “I'll have another two of these please,” he replies.

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 this 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.


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[91] 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[92].

[91] Well, 98% of a pint if you want to be finicky about it.

[92] Chemistry is part of real-world physics; alchemy is the ultraphysics equivalent.

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 that will result (“How come honey drips off kittens at the same rate that it drips off apples? Surely the fur would retain…).


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[93]—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.

[93] Fog and distance haze, on the other hand….


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 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[94], yet calling the “inflate” function on the balloon might. In terms of implementation, though, they can look the same.

[94] Naïve physics doesn't have an uncertainty principle.

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, semisharp 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 them. 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.


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[95]. However, it could be a hand or a sack or…well, let's see what it could be.

[95] In most graphical virtual worlds, the invisible kind.

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 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 can't be 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 5th—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 31st, 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[96]. 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.

[96] The second most obvious, that it's colder, is rarely considered. Night in virtual worlds is primarily about darkness.

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[97]. 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[98]; on a local scale, though, it's no more possible in the virtual world than it is the real one.

[97] Actually, some virtual worlds do let individual characters roll back to some earlier state without affecting anyone else. I'm sure the designers of these worlds believe they have a perfectly good reason for sanctioning such acts of desperation.

[98] It can be fun, too. If you tell players in advance that there will be a time slip (save the database, let people play for an hour, then restore the saved version) they will show up in droves to take advantage of the temporary freedom from consequences offered.

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.

  • Creative Edge
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint