I was in a panel discussion last week (having to do with the future of online communities). I was 'the wiki guy.'
The broader focus of the colloquim was whether companies should 'back' efforts in blogging, or richly-featured Content Management Systems. I heard breathless boosterism for ideas that 'someday, in the future' (and the subtext of those messages was that we're still waiting for more powerful tools), online communities will be fairly close analogs to our daily existence.'
I was tempted to say bosh! -- but as an invited guest, I thought of a better tack.
I asked them to imagine the kind of online world we'd been talking about for two days...
Imagine an online world with upwards of several thousand people interacting at any one time. Imagine an online world that has a working economy, that has good people doing good and bad people doing, well, shit. Imagine that world with law enforcement standards and lawyers. Imagine an online world where participants have not only a 'home page,' but a virtual home or office or store that they can design, construct and supply. Imagine an online world that has several THOUSAND distinct 'regions' within its confines.
and then...
Imagine that to gain access to this phantasmagorical world, you needed only to have anything equal to (or more powerful than) a 20-something year old Commodore64 and a 300bps modem.
This future world exists. To be accurate, it existed over 20 years ago (the mid 1980's) and it was called Habitat.
Twenty-six years later and we're still talking about things Habitat did -- in the misty-eyed future tense.
If you have time for ONE article on building online communities. If you have any interest in seeing why MySpace is such a rich destination and why almost every corporate site in the world isn't -- read the following article by Chip Morningstar and Randy Farmer.
I promise. You'll like this.
---------------------------------------------------------------------------
The Lessons of Lucasfilm's Habitat
Chip Morningstar and F. Randall Farmer
This paper was presented at The First International Conference on
Cyberspace held in May 1990 at the University of Texas at Austin. It was
published in Cyberspace: First Steps, Michael Benedikt (ed.), 1991, 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 details of the technology used to present this
environment to its participants, while sexy and interesting, are of relatively
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 (Vinge, 1981), 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
added a dash of silliness, a touch of cyberpunk (Gibson,
1984; Sterling, 1986), and a predilection for
object-oriented programming (Sussman and Abelson,
1985).
The initial incarnation of Habitat uses a Commodore 64 for the frontend (see note 1). Figure 1 is a typical screen from this version
of the system. 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".
Figure 1 -- A typical Habitat scene (© 1986 LucasArts Entertainment Company).
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 (see note
2). Vending machines dispense useful goods in exchange for Habitat money.
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. Table 1 lists some of the most important types of
objects and their functions. The complete list of object types numbers in the
hundreds.
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 |
Table 1 -- Some important object classes
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 (Goldberg and Robson, 1983), 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:
• 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 driven 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 routed, moreover,
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) (Drexler, 1986).
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:
• 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 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 (ANSI, 1983; Alber, 1985) which
couples dreadful performance with a display model firmly anchored in the
technology of the 1970s.
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.
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:
• Data communications standards are vital.
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 in the future. Once the size of the system's user base has grown
modestly large, it becomes impractical to distribute a new release of the system
software every time one wants to add a new class of object. However, we feel 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
(ISO, 1986). This 7-layer model has become a centerpiece
of most discussions about data communications standards today. It is so firmly
established in the data communications standards community that it is virtually
impossible to find a serious contemporary publication on the subject that does
not begin with some variation on Figure 2. 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.
Figure 2 -- The 7-layer ISO Reference Model of Open System Interconnection
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 that the model
itself 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 that at least some characteristics of the display are embedded in the
protocol. The discussions above should give some indication why we think that
such a presumption is both unnecessary and unwise. Certainly, 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 (Figure
3): 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. However,
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.
Figure 3 -- A possible alternative protocol model
I was chatting with