Physics on Designing Virtual Worlds

Laws of Nature

Mon, 01 Jan 0001 00:00:00 +0000

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 Big Six

Mon, 01 Jan 0001 00:00:00 +0000

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.

Beyond Real-World Physics

Mon, 01 Jan 0001 00:00:00 +0000

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:

Objects

Mon, 01 Jan 0001 00:00:00 +0000

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.

Common Problems with Objects

Mon, 01 Jan 0001 00:00:00 +0000

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.

Solids: Assemblies

Mon, 01 Jan 0001 00:00:00 +0000

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?

Solids: Collections

Mon, 01 Jan 0001 00:00:00 +0000

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.

Solids: Containers

Mon, 01 Jan 0001 00:00:00 +0000

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.

Fluids: Divisibility

Mon, 01 Jan 0001 00:00:00 +0000

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.

Miscibility

Mon, 01 Jan 0001 00:00:00 +0000

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.

Gases

Mon, 01 Jan 0001 00:00:00 +0000

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.

Plasmas

Mon, 01 Jan 0001 00:00:00 +0000

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.

State Changes

Mon, 01 Jan 0001 00:00:00 +0000

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.

Properties

Mon, 01 Jan 0001 00:00:00 +0000

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.

Ownership

Mon, 01 Jan 0001 00:00:00 +0000

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.

Time

Mon, 01 Jan 0001 00:00:00 +0000

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

Proactive Physics

Mon, 01 Jan 0001 00:00:00 +0000

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.