The Lessons of Lucasfilm’s Habitat

This paper was presented at The First Annual International Conference
on Cyberspace in 1990. It was published in Cyberspace: First Steps, Michael
Benedikt (ed.), 1990, MIT Press, Cambridge, Mass.

Introduction

Lucasfilm’s Habitat was created by Lucasfilm Games, a division of LucasArts
Entertainment Company, in association with Quantum Computer Services, Inc.
It was arguably one of the first attempts to create a very large scale
commercial multi-user virtual environment. A far cry from many laboratory
research efforts based on sophisticated interface hardware and tens of
thousands of dollars per user of dedicated compute power, Habitat is built
on top of an ordinary commercial online service and uses an inexpensive
— some would say “toy” — home computer to support user interaction.
In spite of these somewhat plebeian underpinnings, Habitat is ambitious
in its scope. The system we developed can support a population of thousands
of users in a single shared cyberspace. Habitat presents its users with
a real-time animated view into an online simulated world in which users
can communicate, play games, go on adventures, fall in love, get married,
get divorced, start businesses, found religions, wage wars, protest against
them, and experiment with self-government.

The Habitat project proved to be a rich source of insights into the
nitty-gritty reality of actually implementing a serious, commercially viable
cyberspace environment. Our experiences developing the Habitat system,
and managing the virtual world that resulted, offer a number of interesting
and important lessons for prospective cyberspace architects. The purpose
of this paper is to discuss some of these lessons. We hope that the next
generation of builders of virtual worlds can benefit from our experiences
and (especially) from our mistakes.

Due to space limitations, we won’t be able to go into as much technical
detail as we might like; this will have to be left to a future publication.
Similarly, we will only be able to touch briefly upon some of the history
of the project as a business venture, which is a fascinating subject of
its own. Although we will conclude with a brief discussion of some of the
future directions for this technology, a more detailed exposition on this
topic will also have to wait for a future article.

The essential lesson that we have abstracted from our experiences with
Habitat is that a cyberspace is defined more by the interactions among
the actors within it than by the technology with which it is implemented.
While we find much of the work presently being done on elaborate interface
technologies — DataGloves, head-mounted displays, special-purpose rendering
engines, and so on — both exciting and promising, the almost mystical
euphoria that currently seems to surround all this hardware is, in our
opinion, both excessive and somewhat misplaced. We can’t help having a
nagging sense that it’s all a bit of a distraction from the really pressing
issues. At the core of our vision is the idea that cyberspace is
necessarily a multiple-participant environment. It seems to us that
the things that are important to the inhabitants of such an environment
are the capabilities available to them, the characteristics of the other
people they encounter there, and the ways these various participants can
affect one another. Beyond a foundation set of communications capabilities,
the technology used to present this environment to its participants, while
sexy and interesting, is a peripheral concern.

What is Habitat?

Habitat is a “multi-player online virtual environment” (its
purpose is to be an entertainment medium; consequently, the users are called
“players”). Each player uses his or her home computer as a frontend,
communicating over a commercial packet-switching data network to a centralized
backend system. The frontend provides the user interface, generating a
real-time animated display of what is going on and translating input from
the player into requests to the backend. The backend maintains the world
model, enforcing the rules and keeping each player’s frontend informed
about the constantly changing state of the universe. The backend enables
the players to interact not only with the world but with each other.

Habitat was inspired by a long tradition of “computer hacker science
fiction”, notably Vernor Vinge’s novel, True Names [1], as
well as many fond childhood memories of games of make-believe, more recent
memories of role-playing games and the like, and numerous other influences
too thoroughly blended to pinpoint. To this we add a dash of silliness,
a touch of cyberpunk [2,3], and a predilection for object-oriented programming
[4].

The initial incarnation of Habitat uses a Commodore 64 for the frontend.
One of the questions we are asked most frequently is, “Why the Commodore
64?” Many people somehow get the impression that this was a technical
decision, but the real explanation has to do with business, not technology.
Habitat was initially developed by Lucasfilm as commercial product for
QuantumLink, an online service (then) exclusively for owners of the Commodore
64. At the time we started (1985), the Commodore 64 was the mainstay of
the recreational computing market. Since then it has declined dramatically
in both its commercial and technical significance. However, when we began
the project, we didn’t get a choice of platforms. The nature of the deal
was such that both the Commodore 64 for the frontend and the existing QuantumLink
host system (a brace of Stratus fault-tolerant minicomputers) for the backend
were givens.

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, such as the
houses and tree you see here. The players are represent by animated figures
that we call “Avatars”. Avatars are usually, though not exclusively,
humanoid in appearance. In this scene you can see two of them, carrying
on a conversation.

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 20,000 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.

Object Class         Function                                                    
ATM                  Automatic Token Machine; access to an Avatar's bank         
                     account                                                     
Avatar               Represents the player in the Habitat world                  
Bag, Box             Containers in which things may be carried                   
Book                 Document for Avatars to read (e.g., the daily newspaper)    
Bureaucrat-in-a-box  Communication with system operators                         
Change-o-matic       Device to change Avatar gender                              
Chest, Safe          Containers in which things can be stored                    
Club, Gun, Knife     Various weapons                                             
Compass              Points direction to West Pole                               
Door                 Passage from one region to another; can be locked           
Drugs                Various types; changes Avatar body state, e.g., cure        
                     wounds                                                      
Elevator             Transportation from one floor of a tall building to         
                     another                                                     
Flashlight           Provides light in dark places                               
Fountain             Scenic highlight; provides communication to system          
                     designers                                                   
Game piece           Enables various board games: backgammon, checkers, chess,   
                     etc.                                                        
Garbage can          Disposes of unwanted objects                                
Glue                 System building tool; attaches objects together             
Ground, Sky          The underpinnings of the world                              
Head                 An Avatar's head; comes in many styles; for customization   
Key                  Unlocks doors and other containers                          
Knick-knack          Generic inert object; for decorative purposes               
Magic wand           Various types, can do almost anything                       
Paper                For writing notes, making maps, etc.; used in mail system   
Pawn machine         Buys back previously purchased objects                      
Plant, Rock, Tree    Generic scenic objects                                      
Region               The foundation of reality                                   
Sensor               Various types, detects otherwise invisible conditions in    
                     the world                                                   
Sign                 Allows attachment of text to other objects                  
Stun gun             Non-lethal weapon                                           
Teleport booth       Means of quick long-distance transport; analogous to        
                     phone booth                                                 
Tokens               Habitat money                                               
Vendroid             Vending machine; sells things                               

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 [5], 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 which 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 think we learned via a series of principles or assertions
surrounded by supporting reasoning and illustrative anecdotes. A more formal
and thorough exposition will have to come later in some other forum where
we might have the space to present a more comprehensive and detailed model.

We mentioned our primary principle above:

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:

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

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 bit-mapped 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:

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 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 would 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 [7,8].

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

The presentation level and the conceptual level cannot (and should not)
be totally isolated from each other. However, defining a virtual
environment in terms of the configuration and behavior of objects, rather
than their presentation, enables us to span a vast range of computational
and display capabilities among the participants in a system. This range
extends both upward and downward. As an extreme example, a typical scenic
object, such as a tree, can be represented by a handful of parameter values.
At the lowest conceivable end of things might be an ancient Altair 8800
with a 300 baud ASCII dumb terminal, where the interface is reduced to
fragments of text and the user sees the humble string so familiar to the
players of text adventure games, “There is a tree here.” At the
high end, you might have a powerful processor that generates the image
of the tree by growing a fractal model and rendering it three dimensions
at high resolution, the finest details ray-traced in real time, complete
with branches waving in the breeze and the sound of wind in the leaves
coming through your headphones in high-fidelity digital stereo. And these
two users might be looking at the same tree in same the place in the same
world and talking to each other as they do so. Both of these scenarios
are implausible at the moment, the first because nobody would suffer with
such a crude interface when better ones are so readily available, the second
because the computational hardware does not yet exist. The point, however,
is that this approach covers the ground between systems already obsolete
and ones that are as yet gleams in their designers’ eyes. Two consequences
of this are significant. The first is that we can build effective cyberspace
systems today. Habitat exists as ample proof of this principle. The second
is that it is conceivable that with a modicum of cleverness and foresight
you could start building a system with today’s technology that could evolve
smoothly as the tomorrow’s technology develops. The availability of pathways
for growth is important in the real world, especially if cyberspace is
to become a significant communications medium (as we obviously think it
should).

Given that we see cyberspace as fundamentally a communications medium
rather than simply a user interface model, and given the style of object-oriented
approach that we advocate, another point becomes clear:

However, our concerns about cyberspace data communications standards
center less upon data transport protocols than upon the definition of the
data being transported. The mechanisms required for reliably getting bits
from point A to point B are not terribly interesting to us. This is not
because these mechanisms are not essential (they obviously are) nor because
they do not pose significant research and engineering challenges (they
clearly do). It is because we are focused on the unique communications
needs of an object-based cyberspace. We are concerned with the protocols
for sending messages between objects, that is, for communicating behavior
rather than presentation, and for communicating object definitions from
one system to another.

Communicating object definitions seems to us to be an especially important
problem, and one that we really didn’t have an opportunity to address in
Habitat. It will be necessary to address this problem if we are
to have a dynamic system. The ability to add new classes of objects over
time is crucial if the system is to be able to evolve.

While we are on the subject of communications standards, we would like
to make some remarks about the ISO Reference Model of Open System Interconnection
[9]. This multi-layered model has become a centerpiece of most discussions
about data communications standards these days. Unfortunately, while the
bottom 4 or 5 layers of this model provide a more or less sound framework
for considering data transport issues, we feel that the model’s Presentation
and Application layers are not so helpful when considering cyberspace data
communications.

We have two main quarrels with the ISO model: first, it partitions the
general data communications problem in a way that is a poor match for the
needs of a cyberspace system; second, and more importantly, we think it
is an active source of confusion because it focuses the attention of system
designers on the wrong set of issues and thus leads them to spend their
time solving the wrong set of problems. We know because this happened to
us. “Presentation” and “Application” are simply the
wrong abstractions for the higher levels of a cyberspace communications
protocol. A “Presentation” protocol presumes characteristics
of the display are embedded in the protocol. The discussions above should
give some indication why we feel such a presumption is both unnecessary
and unwise. An “Application” protocol presumes a degree of foreknowledge
of the message environment that is incompatible with the sort of dynamically
evolving object system we envision.

A better model would be to substitute a different pair of top layers:
a Message layer, which defines the means by which objects can address one
another and standard methods of encapsulating structured data and encoding
low-level data types (e.g., numbers); and a Definition layer built on top
of the Message layer, which defines a standard representation for object
definitions so that object classes can migrate from machine to machine.
One might argue that these are simply Presentation and Application with
different labels, but we don’t think the differences are so easily reconciled.
In particular, we think the ISO model has, however unintentionally, systematically
deflected workers in the field from considering many of the issues that
concern us.

World Building

There were two sorts of implementation challenges that Habitat posed.
The first was the problem of creating a working piece of technology —
developing the animation engine, the object-oriented virtual memory, the
message-passing pseudo operating system, and squeezing them all into the
ludicrous Commodore 64 (the backend system also posed interesting technical
problems, but its constraints were not as vicious). The second challenge
was the creation and management of the Habitat world itself. It is the
experiences from the latter exercise that we think will be most relevant
to future cyberspace designers.

We were initially our own worst enemies in this undertaking, victims
of a way of thinking to which we engineers are dangerously susceptible.
This way of thinking is characterized by the conceit that all things may
be planned in advance and then directly implemented according to the plan’s
detailed specification. For persons schooled in the design and construction
of systems based on simple, well-defined and well-understood foundation
principles, this is a natural attitude to have. Moreover, it is entirely
appropriate when undertaking most engineering projects. It is a frame of
mind that is an essential part of a good engineer’s conceptual tool kit.
Alas, in keeping with Maslow’s assertion that, “to the person who
has only a hammer, all the world looks like a nail”, it is a tool
that is easy to carry beyond its range of applicability. This happens when
a system exceeds the threshold of complexity above which the human mind
loses its ability to maintain a complete and coherent model.

One generally hears about systems crossing the complexity threshold
when they become very large. For example, the Space Shuttle and the B-2
bomber are both systems above this threshold, necessitating extraordinarily
involved, cumbersome and time-consuming procedures to keep the design under
control — procedures that are at once vastly expensive and only partially
successful. To a degree, the complexity problem can be solved by throwing
money at it. However, such capital intensive management techniques are
a luxury not available to most projects. Furthermore, although these dubious
“solutions” to the complexity problem are out of reach of most
projects, alas the complexity threshold itself is not. Smaller systems
can suffer from the same sorts of problems. It is possible to push much
smaller and less elaborate systems over the complexity threshold simply
by introducing chaotic elements that are outside the designers’ sphere
of control or understanding. The most significant such chaotic elements
are autonomous computational agents (e.g., other computers). This is why,
for example, debugging even very simple communications protocols often
proves surprisingly difficult. Furthermore, a special circle of living
Hell awaits the implementors of systems involving that most important category
of autonomous computational agents of all, groups of interacting human
beings. This leads directly to our next (and possibly most controversial)
assertion:

The constructivist prejudice that leads engineers into the kinds of
problems just mentioned has received more study from economists and sociologists
[10-15] than from researchers in the software engineering community. Game
and simulation designers are experienced in creating virtual worlds for
individuals and small groups. However, they have had no reason to learn
to deal with large populations of simultaneous users. Since each user or
group is unrelated to the others, the same world can be used over and over
again. If you are playing an adventure game, the fact that thousands of
other people elsewhere in the (real) world are playing the same game has
no effect on your experience. It is reasonable for the creator of such
a world to spend tens or even hundreds of hours crafting the environment
for each hour that a user will spend interacting with it, since that user’s
hour of experience will be duplicated tens of thousands of times by tens
of thousands of other individual users.

Builders of online services and communications networks are experienced
in dealing with large user populations, but they do not, in general, create
elaborate environments. Furthermore, in a system designed to deliver information
or communications services, large numbers of users are simply a load problem
rather than a complexity problem. All the users get the same information
or services; the comments in the previous paragraph regarding duplication
of experience apply here as well. It is not necessary to match the size
and complexity of the information space to the size of the user population.
While it may turn out that the quantity of information available on a service
is a function of the size of the user population, this information can
generally be organized into a systematic structure that can still be maintained
by a few people. The bulk, wherein the complexity lies, is the product
of the users themselves, rather than the system designers — the operators
of the system do not have to create all this material. (This observation
is the first clue to the solution to our problem.)

Our original specification for Habitat called for us to create a world
capable of supporting a population of 20,000 Avatars, with expansion plans
for up to 50,000. By any reckoning this is a large undertaking and complexity
problems would certainly be expected. However, in practice we exceeded
the complexity threshold very early in development. By the time the population
of our online community had reached around 50 we were in over our heads
(and these 50 were “insiders” who were prepared to be tolerant
of holes and rough edges).

Moreover, a virtual world such as Habitat needs to scale with its population.
For 20,000 Avatars we needed 20,000 “houses”, organized into
towns and cities with associated traffic arteries and shopping and recreational
areas. We needed wilderness areas between the towns so that everyone would
not be jammed together into the same place. Most of all, we needed things
for 20,000 people to do. They needed interesting places to visit — and
since they can’t all be in the same place at the same time, they needed
a lot of interesting places to visit — and things to do in those
places. Each of those houses, towns, roads, shops, forests, theaters, arenas,
and other places is a distinct entity that someone needs to design and
create. We, attempting to play the role of omniscient central planners,
were swamped.

Automated tools may be created to aid the generation of areas that naturally
possess a high degree of regularity and structure, such as apartment buildings
and road networks. We created a number of such tools, whose spiritual descendents
will no doubt be found in the standard bag of tricks of future cyberspace
architects. However, the very properties which make some parts of the world
amenable to such techniques also make those same parts of the world among
the least important. It is really not a problem if every apartment building
looks pretty much like every other. It is a big problem if every enchanted
forest is the same. Places whose value lies in their uniqueness, or at
least in their differentiation from the places around them, need to be
crafted by hand. This is an incredibly labor intensive and time consuming
process. Furthermore, even very imaginative people are limited in the range
of variation that they can produce, especially if they are working in a
virgin environment uninfluenced by the works and reactions of other designers.

Running The World

The world design problem might still be tractable, however, if all players
had the same goals, interests, motivations and types of behavior. Real
people, however, are all different. For the designer of an ordinary game
or simulation, human diversity is not a major problem, since he or she
gets to establish the goals and motivations on the participants’ behalf,
and to specify the activities available to them in order to channel events
in the preferred direction. Habitat, however, was deliberately open ended
and pluralistic. The idea behind our world was precisely that it did not
come with a fixed set of objectives for its inhabitants, but rather provided
a broad palette of possible activities from which the players could choose,
driven by their own internal inclinations. It was our intent to provide
a variety of possible experiences, ranging from events with established
rules and goals (a treasure hunt, for example) to activities propelled
by the players’ personal motivations (starting a business, running the
newspaper) to completely free-form, purely existential activities (hanging
out with friends and conversing). Most activities, however, involved some
degree of pre-planning and setup on our part — we were to be like the
cruise director on a ocean voyage, but we were still thinking like game
designers.

The first goal-directed event planned for Habitat was a rather involved
treasure hunt called the “D’nalsi Island Adventure”. It took
us hours to design, weeks to build (including a 100-region island), and
days to coordinate the actors involved. It was designed much like the puzzles
in an adventure game. We thought it would occupy our players for days.
In fact, the puzzle was solved in about 8 hours by a person who had figured
out the critical clue in the first 15 minutes. Many of the players hadn’t
even had a chance to get into the game. The result was that one person
had had a wonderful experience, dozens of others were left bewildered,
and a huge investment in design and setup time had been consumed in an
eyeblink. We expected that there would be a wide range of “adventuring”
skills in the Habitat audience. What wasn’t so obvious until afterward
was that this meant that most people didn’t have a very good time, if for
no other reason than that they never really got to participate. It would
clearly be foolish and impractical for us to do things like this on a regular
basis.

Again and again we found that activities based on often unconscious
assumptions about player behavior had completely unexpected outcomes (when
they were not simply outright failures). It was clear that we were not
in control. The more people we involved in something, the less in control
we were. We could influence things, we could set up interesting situations,
we could provide opportunities for things to happen, but we could not dictate
the outcome. Social engineering is, at best, an inexact science (or, as
some wag once said, “in the most carefully constructed experiment
under the most carefully controlled conditions, the organism will do whatever
it damn well pleases”).

Propelled by these experiences, we shifted into a style of operations
in which we let the players themselves drive the direction of the design.
This proved far more effective. Instead of trying to push the community
in the direction we thought it should go, an exercise rather like herding
mice, we tried to observe what people were doing and aid them in it. We
became facilitators as much as we were designers and implementors. This
often meant adding new features and new regions to the system at a frantic
pace, but almost all of what we added was used and appreciated, since it
was well matched to people’s needs and desires. We, as the experts on how
the system worked, could often suggest new activities for people to try
or ways of doing things that people might not have thought of. In this
way we were able to have considerable influence on the system’s development
in spite of the fact that we didn’t really hold the steering wheel — more
influence, in fact, than we had had when we were operating under the illusion
that we controlled everything.

Indeed, the challenges posed by large systems are prompting some researchers
to question the centralized, planning dominated attitude that we have criticized
here, and to propose alternative approaches based on evolutionary and market
principles [16-18]. These principles appear applicable to complex systems
of all types, not merely those involving interacting human beings.

The Great Debate

Among the objects we made available to Avatars in Habitat were guns
and various other sorts of weapons. We included these because we felt that
players should be able to materially effect each other in ways that went
beyond simply talking, ways that required real moral choices to be made
by the participants. We recognized the age old story-teller’s dictum that
conflict is the essence of drama. Death in Habitat was, of course, not
like death in the real world! When an Avatar is killed, he or she is teleported
back home, head in hands (literally), pockets empty, and any object in
hand at the time dropped on the ground at the scene of the crime. Any possessions
carried at the time are lost. It was more like a setback in a game of “Chutes
and Ladders” than real mortality. Nevertheless, the death metaphor
had a profound effect on people’s perceptions. This potential for murder,
assault and other mayhem in Habitat was, to put it mildly, controversial.
The controversy was further fueled by the potential for lesser crimes.
For instance, one Avatar could steal something from another Avatar simply
by snatching the object out its owner’s hands and running off with it.

We had imposed very few rules on the world at the start. There was much
debate among the players as to the form that Habitat society should take.
At the core of much of the debate was an unresolved philosophical question:
is an Avatar an extension of a human being (thus entitled to be treated
as you would treat a real person) or a Pac-Man-like critter destined to
die a thousand deaths or something else entirely? Is Habitat murder a crime?
Should all weapons be banned? Or is it all “just a game”? To
make a point, one of the players took to randomly shooting people as they
roamed around. The debate was sufficiently vigorous that we took a systematic
poll of the players. The result was ambiguous: 50% said that Habitat murder
was a crime and shouldn’t be a part of the world, while the other 50% said
it was an important part of the fun.

We compromised by changing the system to allow thievery and gunplay
only outside the city limits. The wilderness would be wild and dangerous
while civilization would be orderly and safe. This did not resolve the
debate, however. One of the outstanding proponents of the anti-violence
point of view was motivated to open the first Habitat church, the Order
of the Holy Walnut (in real life he was a Greek Orthodox priest). His canons
forbid his disciples to carry weapons, steal, or participate in violence
of any kind. His church became quite popular and he became a very highly
respected member of the Habitat community.

Furthermore, while we had made direct theft impossible, one could still
engage in indirect theft by stealing things set on the ground momentarily
or otherwise left unattended. And the violence still possible in the outlands
continued to bother some players. Many people thought that such crimes
ought to be prevented or at least punished somehow, but they had no idea
how to do so. They were used to a world in which law and justice were always
things provided by somebody else. Somebody eventually made the suggestion
that there ought to be a Sheriff. We quickly figured out how to create
a voting mechanism and rounded up some volunteers to hold an election.
A public debate in the town meeting hall was heavily attended, with the
three Avatars who had chosen to run making statements and fielding questions.
The election was held, and the town of Populopolis acquired a Sheriff.

For weeks the Sheriff was nothing but a figurehead, though he was a
respected figure and commanded a certain amount of moral authority. We
were stumped about what powers to give him. Should he have the right to
shoot anyone anywhere? Give him a more powerful gun? A magic wand to zap
people off to jail? What about courts? Laws? Lawyers? Again we surveyed
the players, eventually settling on a set of questions that could be answered
via a referendum. Unfortunately, we were unable to act on the results before
the pilot operations ended and the system was shut down. It was clear,
however, that there are two basic camps: anarchy and government. This is
an issue that will need to be addressed by future cyberspace architects.
However, our view is that a virtual world need not be set up with a “default”
government, but can instead evolve one as needed.

A Warning

Given the above exhortation that control should be released to the users,
we need to inject a note of caution and present our next assertion:

This may seem like a contradiction of much of the preceding, but it
really is not. Designers and operators of a cyberspace system must inhabit
two levels of virtual world at once. The first we call the “infrastructure
level”, which is the implementation, where the laws that govern “reality”
have their genesis. The second we call the “percipient level”,
which is what the users see and experience. It is important that there
not be “leakage” between these two levels. The first level defines
the physics of the world. If its integrity is breached, the consequences
can range from aesthetic unpleasantness (the audience catches a glimpse
of the scaffolding behind the false front) to psychological disruption
(somebody does something “impossible”, thereby violating users’
expectations and damaging their fantasy) to catastrophic failure (somebody
crashes the system). When we exhort you to give control to the users, we
mean control at the percipient level. When we say that you can’t trust
anyone, we mean that you can’t trust them with access to the infrastructure
level. Some stories from Habitat will illustrate this.

When designing piece of software, you generally assume that it is the
sole intermediary between the user and the underlying data being manipulated
(possibly multiple applications will work with the same data, but the principle
remains the same). In general, the user need not be aware of how data are
encoded and structured inside the application. Indeed, the very purpose
of a good application is to shield the user from the ugly technical details.
It is conceivable that a technically astute person who is willing to invest
the time and effort could decipher the internal structure of things, but
this would be an unusual thing to do as there is rarely much advantage
to be gained. The purpose of the application itself is, after all, to make
access to and manipulation of the data easier than digging around at the
level of bits and bytes. There are exceptions to this, however. For example,
most game programs deliberately impose obstacles on their players in order
for play to be challenging. By tinkering around with the insides of such
a program — dumping the data files and studying them, disassembling the
program itself and possibly modifying it — it may be possible to “cheat”.
However, this sort of cheating has the flavor of cheating at solitaire:
the consequences adhere to the cheater alone. There is a difference, in
that disassembling a game program is a puzzle-solving exercise in its own
right, whereas cheating at solitaire is pointless, but the satisfactions
to be gained from it, if any, are entirely personal.

If, however, a computer game involves multiple players, delving into
the program’s internals can enable one to truly cheat, in the sense that
one gains an unfair advantage over the other players of which they may
be unaware. Habitat is such a multi-player game. When we were designing
the software, our “prime directive” was, “The backend shall
not assume the validity of anything a player computer tells it.” This
is because we needed to protect ourselves against the possibility that
a clever user had hacked around with his copy of the frontend program to
add “custom features”. For example, we could not implement any
of the sort of “skill and action” elements found in traditional
video games wherein dexterity with the joystick determines the outcome
of, say, armed combat, because you couldn’t guard against someone modifying
their copy of the program to tell the backend that they had “hit”,
whether they actually had or not. Indeed, our partners at QuantumLink warned
us of this very eventuality before we even started — they already had
users who did this sort of thing with their regular system. Would anyone
actually go to the trouble of disassembling and studying 100K or so of
incredibly tight and bizarrely threaded 6502 machine code just to tinker?
As it turns out, the answer is yes. People have. We were not 100% rigorous
in following our own rule. It turned out that there were a few features
whose implementation was greatly eased by breaking the rule in situations
where, in our judgment, the consequences would not be material if people
“cheated” by hacking their own systems. Darned if people didn’t
hack their systems to cheat in exactly these ways.

Care must be taken in the design of the world as well. One incident
that occurred during our pilot test involved a small group of players exploiting
a bug in our world database which they interpreted as a feature. First,
some background. Avatars are hatched with 2000 Tokens in their bank account,
and each day that they login the receive another 100T. Avatars may acquire
additional funds by engaging in business, winning contests, finding buried
treasure, and so on. They can spend their Tokens on, among other things,
various items that are for sale in vending machines called Vendroids. There
are also Pawn Machines, which will buy objects back (at a discount, of
course).

In order to make this automated economy a little more interesting, each
Vendroid had its own prices for the items in it. This was so that we could
have local price variation (i.e., a widget would cost a little less if
you bought it at Jack’s Place instead of The Emporium). It turned out that
in two Vendroids across town from each other were two items for sale whose
prices we had inadvertently set lower than what a Pawn Machine would buy
them back for: Dolls (for sale at 75T, hock for 100T) and Crystal Balls
(for sale at 18,000T, hock at 30,000T!). Naturally, a couple of people
discovered this. One night they took all their money, walked to the Doll
Vendroid, bought as many Dolls as they could, then took them across town
and pawned them. By shuttling back and forth between the Doll Vendroid
and the Pawn Shop for hours, they amassed sufficient funds to buy
a Crystal Ball , whereupon they continued the process with Crystal Balls
and a couple orders of magnitude higher cash flow. The final result was
at least three Avatars with hundreds of thousands of Tokens each. We only
discovered this the next morning when our daily database status report
said that the money supply had quintupled overnight.

We assumed that the precipitous increase in “T1” was due to
some sort of bug in the software. We were puzzled that no bug report had
been submitted. By poking around a bit we discovered that a few people
had suddenly acquired enormous bank balances. We sent Habitat mail to the
two richest, inquiring as to where they had gotten all that money overnight.
Their reply was, “We got it fair and square! And we’re not going to
tell you how!” After much abject pleading on our part they eventually
did tell us, and we fixed the erroneous pricing. Fortunately, the whole
scam turned out well, as the nouveau riche Avatars used their bulging bankrolls
to underwrite a series of treasure hunt games which they conducted on their
own initiative, much to the enjoyment of many other players on the system.

Keeping “Reality” Consistent

The urge to breach the boundary between the infrastructure level and
the percipient level is not confined to the players. The system operators
are also subject to this temptation, though their motivation is expediency
in accomplishing their legitimate purposes rather than the gaining of illegitimate
advantage. However, to the degree to which it is possible, we vigorously
endorse the following principle:

Wherever possible, things that can be done within the framework of the
percipient level should be. The result will be smoother operation and greater
harmony among the user community. This admonition applies to both the technical
and the sociological aspects of the system.

For example, with the players in control, the Habitat world would have
grown much larger and more diverse than it did had we ourselves not been
a technical bottleneck. All new region generation and feature implementation
had to go through us, since there was no means for players to create new
parts of the world on their own. Region creation was an esoteric technical
specialty, requiring a plethora of obscure tools and a good working knowledge
of the treacherous minefield of limitations imposed by the Commodore 64.
It also required a lot of behind-the-scenes activity that would probably
spoil the illusion for many. One of the goals of a next generation Habitat-like
system ought to be to permit far greater creative involvement by the participants
without requiring them to ascend to full-fledged guru-hood to do so.

A further example of working within the system, this time in a social
sense, is illustrated by the following experience. One of the more popular
events in Habitat took place late in the test, the brainchild of one of
the more active players who had recently become a QuantumLink employee.
It was called the “Dungeon of Death”.

For weeks, ads appeared in Habitat’s newspaper, The Rant, announcing
that that Duo of Dread, DEATH and THE SHADOW, were challenging all comers
to enter their lair. Soon, on the outskirts of town, the entrance to a
dungeon appeared. Out front was a sign reading, “Danger! Enter at
your own risk!” Two system operators were logged in as DEATH and THE
SHADOW, armed with specially concocted guns that could kill in one shot,
rather than the usual 12. These two characters roamed the dungeon blasting
away at anyone they encountered. They were also equipped with special magic
wands that cured any damage done to them by other Avatars, so that they
wouldn’t themselves be killed. To make things worse, the place was littered
with dead ends, pathological connections between regions, and various other
nasty and usually fatal features. It was clear that any explorer had better
be prepared to “die” several times before mastering the dungeon.
The rewards were pretty good: 1000 Tokens minimum and access to a special
Vendroid that sold magic teleportation wands. Furthermore, given clear
notice, players took the precaution of emptying their pockets before entering,
so that the actual cost of getting “killed” was minimal.

One evening, one of us was given the chance to play the role of DEATH.
When we logged in, we found him in one of the dead ends with four other
Avatars who were trapped there. We started shooting, as did they. However,
the last operator to run DEATH had not bothered to use his special wand
to heal any accumulated damage, so the character of DEATH was suddenly
and unexpectedly “killed” in the encounter. As we mentioned earlier,
when an Avatar is killed, any object in his hands is dropped on the ground.
In this case, said object was the special kill-in-one-shot gun, which was
immediately picked up by one of the regular players who then made off with
it. This gun was not something that regular players were supposed to have.
What should we do?

It turned out that this was not the first time this had happened. During
the previous night’s mayhem the special gun was similarly absconded with.
In this case, the person playing DEATH was one of the regular system operators,
who, used to operating the regular Q-Link service, simply ordered the player
to give the gun back. The player considered that he had obtained the weapon
as part of the normal course of the game and balked at this, whereupon
the operator threatened to cancel the player’s account and kick him off
the system if he did not comply. The player gave the gun back, but was
quite upset about the whole affair, as were many of his friends and associates
on the system. Their world model had been painfully violated.

When it happened to us, we played the whole incident within the role
of DEATH. We sent a message to the Avatar who had the gun, threatening
to come and kill her if she didn’t give it back. She replied that all she
had to do was stay in town and DEATH couldn’t touch her (which was true,
if we stayed within the system). OK, we figured, she’s smart. We negotiated
a deal whereby DEATH would ransom the gun for 10,000 Tokens. An elaborate
arrangement was made to meet in the center of town to make the exchange,
with a neutral third Avatar acting as an intermediary to ensure that neither
party cheated. Of course, word got around and by the time of the exchange
there were numerous spectators. We played the role of DEATH to the hilt,
with lots of hokey melodramatic shtick. The event was a sensation. It was
written up in the newspaper the next morning and was the talk of the town
for days. The Avatar involved was left with a wonderful story about having
cheated DEATH, we got the gun back, and everybody went away happy.

These two very different responses to an ordinary operational problem
illustrate our point. Operating within the participants’ world model produced
a very satisfactory result. On the other hand, what seemed like the expedient
course, which involved violating this model, provoked upset and dismay.
Working within the system was clearly the preferred course in this case.

Current Status

As of this writing, the North American incarnation of Lucasfilm’s Habitat,
QuantumLink’s “Club Caribe”, has been operating for almost two
years. It uses our original Commodore 64 frontend and a somewhat stripped-down
version of our original Stratus backend software. Club Caribe now sustains
a population of some 15,000 participants.

A technically more advanced version, called Fujitsu Habitat, has recently
started pilot operations in Japan, available on NIFtyServe. The initial
frontend for this version is the new Fujitsu FM Towns personal computer,
though ports to several other popular Japanese machines are anticipated.
This version of the system benefits from the additional computational power
and graphics capabilities of a newer platform, as well as the Towns’ built-in
CD-ROM for object imagery and sounds. However, the virtuality of the system
is essentially unchanged and Fujitsu has not made significant alterations
to the user interface or to any of the underlying concepts.

Future Directions

There are several directions in which this work can be extended. Most
obvious is to implement the system on more advanced hardware, enabling
a more sophisticated display. A number of extensions to the user interface
also suggest themselves. However, the line of development most interesting
to us is to expand on the idea of making the development and expansion
of the world itself part of the users’ sphere of control. There are two
major research areas in this. Unfortunately, we can only touch on them
briefly here.

The first area to investigate involves the elimination of the centralized
backend. The backend is a communications and processing bottleneck that
will not withstand growth above too large a size. While we can support
tens of thousands of users with this model, it is not really feasible to
support millions. Making the system fully distributed, however, requires
solving a number of difficult problems. The most significant of these is
the prevention of cheating. Obviously, the owner of the network node that
implements some part of the world has an incentive to tilt things in his
favor there. We think that this problem can be addressed by secure operating
system technologies based on public-key cryptographic techniques [19, 20].

The second fertile area of investigation involves user configuration
of the world itself. This requires finding ways to represent the design
and creation of regions and objects as part of the underlying fantasy.
Doing this will require changes to our conception of the world. In particular,
we don’t think it will be possible to conceal all of the underpinnings
to those who work with them. However, all we really need to do is find
abstractions for those underpinnings that fit into the fantasy itself.
Though challenging, this is, in our opinion, eminently feasible.

Conclusions

We feel that the defining characteristic of cyberspace is the shared
virtual environment, not the display technology used to transport users
into that environment. Such a cyberspace is feasible today, if you can
live without head-mounted displays and other expensive graphics hardware.
Habitat serves as an existence proof of this contention.

It seems clear to us that an object-oriented world model is a key ingredient
in any cyberspace implementation. We feel we have gained some insight into
the data representation and communications needs of such a system. While
we think that it may be premature to start establishing detailed technical
standards for these things, it is time to begin the discussions that will
lead to such standards in the future.

Finally, we have come to believe that the most significant challenge
for cyberspace developers is to come to grips with the problems of world
creation and management. While we have only made the first inroads onto
these problems, a few things have become clear. The most important of these
is that managing a cyberspace world is not like managing the world inside
a single-user application or even a conventional online service. Instead,
it is more like governing an actual nation. Cyberspace architects will
benefit from study of the principles of sociology and economics as much
as from the principles of computer science. We advocate an agoric, evolutionary
approach to world building rather than a centralized, socialistic one.

We would like to conclude with a final admonition, one that we hope
will not be seen as overly contentious:

In a discussion of cyberspace on Usenet, one worker in the field dismissed
Club Caribe (Habitat’s current incarnation) as uninteresting, with a comment
to the effect that most of the activity consisted of inane and trivial
conversation. Indeed, the observation was largely correct. However, we
hope some of the anecdotes recounted above will give some indication that
more is going on than those inane and trivial conversations might indicate.
Further, to dismiss the system on this basis is to dismiss the users themselves.
They are paying money for this service. They don’t view what they
do as inane and trivial, or they wouldn’t do it. To insist this presumes
that one knows better than they what they should be doing. Such presumption
is another manifestation of the omniscient central planner who dictates
all that happens, a role that this entire article is trying to deflect
you from seeking. In a real system that is going to be used by real people,
it is a mistake to assume that the users will all undertake the sorts of
noble and sublime activities which you created the system to enable. Most
of them will not. Cyberspace may indeed change humanity, but only if it
begins with humanity as it really is.

References

[1] Vinge, Vernor (1981), “True Names”, Binary Star #5,
Dell Publishing Company, New York.

[2] Gibson, William (1984), Neuromancer, Ace Books, New York.

[3] Bruce Sterling, ed. (1986), Mirrorshades: The Cyberpunk Anthology,
Arbor House, New York.

[4] Sussman, Gerald Jay, and Abelson, Harold (1985), Structure and
Interpretation of Computer Programs, MIT Press, Cambridge.

[5] Goldberg, Adele, and Robson, David (1983), Smalltalk-80: The
Language and Its Implementation, Addison-Wesley, Reading, Mass.

[6] Drexler, K. Eric (1986), Engines of Creation, Anchor Press,
Doubleday, Garden City, New York.

[7] American National Standards Institute (December 1983), Videotex/Teletext
Presentation Level Protocol Syntax, North American PLPS, ANSI.

[8] Alber, Antone F. (1985), Videotex/Teletext: Principles and Practices,
McGraw-Hill, New York.

[9] International Standards Organization (June 1986), Information
Processing Systems — Open System Interconnection — Transport Service
Definition, International Standard number 8072, ISO, Switzerland.

[10] Hayek, Friedrich A. (1978), New Studies in Philosophy, Politics,
Economics, and the History of Ideas, University of Chicago Press, Chicago.

[11] Hayek, Friedrich A. (1973), Law Legislation and Liberty, Volume
I: Rules and Order, University of Chicago Press, Chicago.

[12] Hayek, Friedrich A. (1989), The Fatal Conceit, University
of Chicago Press, Chicago.

[13] Popper, Karl R. (1972), Objective Knowledge: An Evolutionary
Approach, Oxford University Press, Oxford.

[14] Popper, Karl R. (1962), The Open Society and Its Enemies (fifth
edition) , Princeton University Press, Princeton, New Jersey.

[15] Sowell, Thomas (1987), A Conflict of Visions, William Morrow,
New York.

[16] Miller, Mark S., and Drexler, K. Eric (1988), “Comparative
Ecology: A Computational Perspective”, in Huberman, B.A., ed., The
Ecology of Computation, Elsevier Science Publishers, Amsterdam.

[17] Miller, Mark S., and Drexler, K. Eric (1988), “Markets and
Computation: Agoric Open Systems”, in Huberman, B.A., ed., The
Ecology of Computation, Elsevier Science Publishers, Amsterdam.

[18] Drexler, K. Eric, and Miller, Mark S. (1988), “Incentive Engineering
for Computational Resource Management”, in Huberman, B.A., ed., The
Ecology of Computation, Elsevier Science Publishers, Amsterdam.

[19] Rivest, R., Shamir, A., and Adelman, L. (February 1978), “A
Method for Obtaining Digital Signatures and Public-Key Cryptosystems”,
in Communications of the ACM, Vol. 21, No. 2.

[20] Miller, Mark S., Bobrow, Daniel G., Tribble, Eric Dean, and Levy,
David Jacob (1987), “Logical Secrets”, in Shapiro, Ehud, ed.,
Concurrent Prolog: Collected Papers, MIT Press, Cambridge.