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

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 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. 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. This multilayered model has become a centerpiece of most discussions about data communications standards these days. Unfortunately, while the bottom four or five 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 important, 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:

Detailed central planning is impossible; don't even try.

The constructivist prejudice that leads engineers into the kinds of problems just mentioned has received more study from economists and sociologists 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 twenty thousand Avatars, with expansion plans for up to fifty thousand. 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 fifty we were in over our heads (and these fifty 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 twenty thousand Avatars we needed twenty thousand “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 twenty thousand 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 that 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 preplanning 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.