True Names and the Opening of the Cyberspace Frontier (20 page)

The largest part of the screen is devoted to the graphics display. This is an animated view of the player's current location in the Habitat world. The scene consists of various objects arrayed on the screen. The players are represent by animated figures that we call “Avatars.” Avatars are usually, though not exclusively, humanoid in appearance.

Avatars can move around, pick up, put down, and manipulate objects, talk to each other, and gesture, each under the control of an individual player. Control is through the joystick, which enables the player to point at things and issue commands. Talking is accomplished by typing on the keyboard. The text that a player types is displayed over his or her Avatar's head in a cartoon-style “word balloon.”

The Habitat world is made up of a large number of discrete locations that we call “regions.” In its prime, the prototype Habitat world consisted of around twenty thousand of them. Each region can adjoin up to four other regions, which can be reached simply by walking your Avatar to one or another edge of the screen. Doorways and other passages can connect to additional regions. Each region contains a set of objects which define the things that an Avatar can do there and the scene that the player sees on the computer screen.

Some of the objects are structural, such as the ground or the sky. Many are just scenic, such as the tree or the mailbox. Most objects, however, have some function that they perform. For example, doors transport Avatars from one region to another and may be opened, closed, locked, and unlocked. ATMs (Automatic Token Machines) enable access to an Avatar's bank account. Vending machines dispense useful goods in exchange for Habitat money. Habitat contained its own fully-fledged economy, with money, banks, and so on. Habitat's unit of currency is the Token, owing to the fact that it is a token economy and to acknowledge the long and honorable association between tokens and video games.

Many objects are portable and may be carried around in an Avatar's hands or pockets. These include various kinds of containers, money, weapons, tools, and exotic magical implements. Listed here are some of the most important types of objects and their functions. The complete list of object types numbers in the hundreds. Partial list:

Implementation

The following, along with several programmer-years of tedious and expensive detail that we won't cover here, is how the system works:

At the heart of the Habitat implementation is an object-oriented model of the universe.

The frontend consists of a system kernel and a collection of objects. The kernel handles memory management, display generation, disk I/O, telecommunications, and other “operating system” functions. The objects implement the semantics of the world itself. Each type of Habitat object has a definition consisting of a set of resources, including animation cels to drive the display, audio data, and executable code. An object's executable code implements a series of standard behaviors, each of which is invoked by a different player command or system event. The model is similar to that found in an object-oriented programming system such as Smalltalk, with its classes, methods, and messages. These resources consume significant amounts of scarce frontend memory, so we can't keep them all in core at the same time. Fortunately, their definitions are invariant, so we simply swap them in from disk as we need them, discarding less recently used resources to make room.

When an object is instantiated, we allocate a block of memory to contain the object's state. The first several bytes of an object's state information take the same form in all objects, and include such things as the object's screen location and display attributes. This standard information is interpreted by the system kernel as it generates the display and manages the run-time environment. The remainder of the state information varies with the object type and is accessed only by the object's behavior code.

Object behaviors are invoked by the kernel in response to player input. Each object responds to a set of standard verbs that map directly onto the commands available to the player. Each behavior is simply a subroutine that executes the indicated action; to do this it may invoke the behaviors of other objects or send request messages to the backend. Besides the standard verb behaviors, objects may have additional behaviors that are invoked by messages that arrive asynchronously from the backend.

The backend also maintains an object-oriented representation of the world. As in the frontend, objects on the backend possess executable behaviors and in-memory state information. In addition, since the backend maintains a persistent global state for the entire Habitat world, the objects are also represented by database records that may be stored on disk when not “in use.” Backend object behaviors are invoked by messages from the frontend. Each of these backend behaviors works in roughly the same way: a message is received from a player's frontend requesting some action; the action is taken and some state changes to the world result; the backend behavior sends a response message back to the frontend informing it of the results of its request and notification messages to the frontends of any other players who are in the same region, informing them of what has taken place.

The Lessons

In order to say as much as we can in the limited space available, we will describe what we think we learned via a series of principles or assertions surrounded by supporting reasoning and illustrative anecdotes.

We mentioned our primary principle above:

A multi-user environment is central to the idea of cyberspace.

It is our deep conviction that a definitive characteristic of a cyberspace system is that it represents a multi-user environment. This stems from the fact that what (in our opinion) people seek in such a system is richness, complexity, and depth. Nobody knows how to produce an automaton that even approaches the complexity of a real human being, let alone a society. Our approach, then, is not even to attempt this, but instead to use the computational medium to augment the communications channels between real people.

If what we are constructing is a multi-user environment, it naturally follows that some sort of communications capability must be fundamental to our system. However, we must take into account an observation that is the second of our principles:

Communications bandwidth is a scarce resource.

This point was rammed home to us by one of Habitat's nastier externally imposed design constraints, namely that it provide a satisfactory experience to the player over a 300-baud serial telephone connection (one, moreover, routed through commercial packet-switching networks that impose an additional, uncontrollable latency of 100 to 5,000 milliseconds on each packet transmitted).

Even in a more technically advanced network, however, bandwidth remains scarce in the sense that economists use the term: available carrying capacity is not unlimited. The law of supply and demand suggests that no matter how much capacity is available, you always want more. When communications technology advances to the point were we all have multi-gigabaud fiber-optic connections into our homes, computational technology will have advanced to match. Our processors' expanding appetite for data will mean that the search for ever more sophisticated data-compression techniques will still be a hot research area (though what we are compressing may at that point be high-resolution volumetric time series or something even more esoteric).

Computer scientists tend to be reductionists who like to organize systems in terms of primitive elements that can be easily manipulated within the context of a simple formal model. Typically, you adopt a small variety of very simple primitives, which are then used in large numbers. For a graphics-oriented cyberspace system, the temptation is to build upon bitmapped images or polygons or some other graphic primitive. These sorts of representations, however, are invitations to disaster. They arise from an inappropriate fixation on display technology, rather than on the underlying purpose of the system.

However, the most significant part of what we wish to be communicating are human behaviors. These, fortunately, can be represented quite compactly, provided we adopt a relatively abstract, high-level description that deals with behavioral concepts directly. This leads to our third principle:

An object-oriented data representation is essential.

Taken at its face value, this assertion is unlikely to be controversial, as object-oriented programming is currently the methodology of choice among the software engineering cognoscenti. However, what we mean here is not only that you should adopt an object-oriented approach, but that the basic objects from which you build the system should correspond more or less to the objects in the user's conceptual model of the virtual world, that is, people, places, and artifacts. You could, of course, use object-oriented programming techniques to build a system based on, say, polygons, but that would not help to cope with the fundamental problem.

The goal is to enable the communications between machines to take place primarily at the behavioral level (what people and things are doing) rather than at the presentation level (how the scene is changing). The description of a place in the virtual world should be in terms of what is there rather than what it looks like. Interactions between objects should be described by functional models rather than by physical ones. The computation necessary to translate between these higher-level representations and the lower-level representations required for direct user interaction is an essentially local function. At the local processor, display-rendering techniques may be arbitrarily elaborate and physical models arbitrarily sophisticated. The data channel capacities required for such computations, however, need not and should not be squeezed into the limited bandwidth available between the local processor and remote ones. Attempting to do so just leads to disasters such as NAPLPS, a format for sending data, used by videotex systems.

Once we begin working at the conceptual rather than the presentation level, we are struck by the following observation:

The implementation platform is relatively unimportant.