Reflections on Cyberspace Development 

by Simon Birrell. 

This is a modified version of a lecture given at CyberConf 5 in Madrid, 9th
June 1996.  Simon Birrell. All opinions are my own, and do not necessarily
reflect the views of E-spaces, or anybody else for that matter.

Introduction 

One of the things that we, at E-spaces, are most proud of in MILENA, are the
cool 3D graphics.  Jose Maria Gonzalez spent a great deal of time rendering
images of moodily-lit street buildings in 3D Studio and then importing them
into the Renderware scenes as textures. We played with the transparency and
wireframe features of the renderer in the rave zone. And, grudgingly, we tried
to cut down on our polygons to keep the scene running in real time on hardware
we like to think of as modest.

Im therefore being a little perverse in this essay, as I would like to argue
that 3D is not the key technology for cyberspace, and that the emphasis in our
industry on flashy 3D may actually be leading us down the wrong technological
paths. I think that our attention as a community should be focused on other
areas, and that we may be making hardware demands on the end-users that are
misguided.

Because face it, 3D graphics need a LOT of power. Many people reading this are
computer professionals, whether programmers or designers, and are used to
having their equipment upgraded at least annually. The home user still using
his or her 386 will be getting a very different impression of the development
of cyberspace.


A Different Approach 

Let us think about what is important in the development of cyberspace. Lets
take a specific example, that of a virtual teapot.

What is the most important thing we have to consider when constructing a
virtual teapot ? I suspect that typical answers from the cyberspace community
might be:

"It should have a nice decorative texture wrapped around the model, so it looks
like my aunts old teapot."

"It should have gouraud shading to give a rounded, china-like surface." 

"It should have a low polygon count, so that it can run in real time on normal
PCs."

These are all interesting answers, and all wrong. 

The most important thing about a virtual teapot is that it should make tea. 

A teapot is not a teapot because it is red, blue, textured or even round. A
teapot is a teapot because it makes tea. It may be a square teapot. It may even
be modeled in shape of a human head with a long nose acting as a spout. It is
still a teapot providing that we can make tea with it.

The point is that we should consider virtual objects by what they are and what
they do, not by what they look like. The physical model or representation of
our virtual object should be a secondary characteristic. Let us consider an
alternative way to represent a virtual teapot.

Plato believed that all the objects that we see in the world around us are
reflections, or imperfect versions of a perfect divine object inhabiting some
celestial non-physical space. In other words, all teapots on the earth are but
imperfect versions or variations on the single divine, essential teapot. The
essence of this divine teapot is its ability to make tea. It is quite clear
that Plato had in mind the intricacies of cyberspace development, as this is a
useful and practical way to think about the problems we are trying to solve.

His most famous analogy was that of the cave. Consider a cave, with a fire in
the centre, and imagine that there are animals and men moving around the fire.
They cast great moving shadows on the walls of the cave. Now imagine that we,
as terrestrial observers, are also in the cave. Our faces are turned to the
wall, facing away from the beings moving around the fire. In our ignorance, we
imagine the moving shadows to be the real thing, and forget that they are cast
by real essential objects out of sight.

The real objects moving around the fire are the real virtual teapots, and the
shadows are their 3D representations. VRML 1.0 and 2.0 are simply rendering the
shadows, ignoring the real objects, and even worse, are now trying to push the
shadows around by adding behaviours.

Behaviours are not something that should be tacked onto a 3D model as an
afterthought; behaviours define what that object is. The 3D model is attached
to the real object thus.



What does all this buy us ? 

First of all, it is clear than we can have multiple types of representation for
users who all share the same world. The lucky Silicon Graphics user can see a
beautiful 3D zillion polygon rendered teapot. Another user might have a simpler
model, or even a 2D icon on their desktop. Yet another user might see the same
teapot as the message "There is a teapot here" on their terminals.

Secondly, it simplifies many of the problems we may come across in simulating
worlds. Certain aspects of physics can be modelled as a graph of relationships
connecting objects with methods ("the teapot IS ON the table") rather than
having to worry about perfectly reproducing all the dynamics of the real
world.

Thirdly, it allows different types of representaions for different problems.
Many of the arguments that have flared across the mailing lists are of the type
"if we implement feature X then my game wont run fast enough" or "if we dont
implement feature X then I wont be able to make my virtual wind tunnel work
properly". The underlying assumption behind these arguments is that there
exists a single representation suitable and efficient for both a wind tunnel
and a game. Perhaps we should work on multiple graphical solutions that are
optimized for different problem domains.

Finally, with the ever-increasing demands on our hardware from 3D graphics
removed (or at least put to one side for a while), we could turn our attention
to all the other, burning issues of multi-user consistency, data availability
and behaviour modelling.


Step Backwards In Time 

As an example of what can be achieved in cyberspace development, I'd like to
describe a computer game made four years ago I helped work on, and show that it
implements many of the technologies that we should be concentrating on today.

The game in question is called "Jekyll & Hyde", made at the now-defunct Palace
Software in London. It was designed and programmed by a brilliant young
programmer called Chris Stangroom, and was an example of what we then called
adventure games, and that are now called interactive fiction.

Most modern interactive fiction has followed the same path as current
cyberspace development, and concentrated almost exclusively on adding ever more
sophisticated graphics to a firaly simple core program. They are usually based
on tree structures of decision points, where the user chooses from amongst a
set of pre-determined paths through story-space; each one accompanied by flashy
multimedia presentations. In no sense can we consider this type of game to be a
world.

Jekyll & Hyde worked on a different principle. It was a simulation of a small
60-zone world that contained autonomous characters (today we might say agents)
that moved from zone to zone and interacted with each other. Some characters
were controlled by their own internal programs (written in a custom-built
interpreted language called CCL) and other were controlled by human players
through a menu interface. The descriptions of where you were and what you saw
were represented mostly as text.

Characters had basic behaviours such as defend yourself if attacked, and more
specific behaviours for different people. They had goals, such as "work out the
antidote to the magic potion" for Dr. Jekyll or "make lots of money through
theft, blackmail and extortion" for the criminals. They had emotional states
and relationships with other characters that numerically reflected levels of
friendship, lust, suspicion and so on. These values were dynamic, altering the
characters behaviour towards others, and being modified by external events.
Somebody might begin the game as your friend, however if you persistently treat
him badly, his feelings and his behaviour towards you would soon change.

From the point of view of the world simulation, there was no difference between
a character controlled by a user, and a character controlled by a CCL program;
in modern terminology, the avatars were treated in the same way as agents.

This meant, for instance that it was trivially easy to implement a command to
switch characters at any point in the game. This was fun, but we had to
restrict it to give the game some degree of challenge. Otherwise you could win
a fight with an enemy by becoming the enemy, killing yourself, then swapping
back to your previous body.

It also means that things are going on in the background. While you as a user
are playing in one zone, two computer-controlled characters may be fighting (or
making love) in another zone. This made the game difficult to test. As Dr.
Jekyll, you might send the CCL-governed delivery boy off to fetch you a
much-needed ingredient. On the way back from the chemist, he might be mugged by
a CCL-governed thief who sells the ingredient and spends the money down the
pub.  All the gametester would see is that the delivery boy had gone off and
not returned. It was hard to tell what was a bug, and what was a legitimate
twist of fate.

It also, even though this is less relevant to cyberspace development and ought
to be the subject of another essay, threw up fascinating challenges in the way
in which we could impose story situations upen the player. In "Jekyll & Hyde"
there was no story imposed upon the world; all we could do was set up the
characters intial relationships and goals and let them get on with it. It was
rather like trying to program an ant colony, and our characters led us a merry
dance.

"Jekyll & Hyde" featured inanimate objects too, such as safes, jewels, money,
fire and teapots.  Everything was represented by text , with the occasional
spot graphic. But we could still model basic physical relationships and
properties in the manner described at the beginning of the essay.  "The teapot
is on the table" can be modelled as two abstract objects with a relationship
between them. You could put objects inside other objects (weighing the
container object would correctly return the combined weight), set fire to
objects, break them and so on.

Chris implemented liquids to allow the mixing of chemical ingredients together.
So ingredients such as mercury, acid and water could be mixed into a single
liquid that would additively combine the properties of each one. A games-tester
discovered an interesting side effect of this one day. There was a pub in the
game with a CCL-controlled barman, who would serve other characters who, being
thirsty, had come in for a drink. The tester discovered that you could pour the
potion that turned Jekyll into Hyde into the barrell of beer in the pub. This
meant that every character from then on who came in for a nice glass of beer
would instantly turn into a raving maniac, and within a few minutes the game
world would be littered with dead bodies.

Its important to understand that this was not explicity programmed into the
game; it emerged as an unexpected consequence of the way a high-level abstract
physics had been programmed into the game. It surprised and delighted the hell
out of the programmer. This seems such a fundamental aspect of any really rich
simulated world that I believe we can offer it as a necessary condition for a
virtual reality:

     A virtual world is not real, unless it can surprise its own creator. 

This all sounds great, but is it cyberspace ? Surely one of the defining
characteristics of cyberspace is that it is multi-user ?

"Jekyll & Hyde" was multi-user. Up to four PCs, Amigas and STs could be
connected into a ring via an eccentric use of the serial port, and a player at
every computer could control up to three characters each, all other characters
being CCL-controlled. Chris met with, and solved many of the issues that are
still being debated today in discussions on multi-user world consistency.

In summary then, "Jekyll & Hyde" had (a) a high-level abstract representation
of the world, including relevant physics. (b) autonomous agents with emotions,
relationships and goals. (c) avatars that could do the same things as agents,
and vice versa. (d) multi-user consistency (e) the ability to surprise its own
creator.

This to me, is a cyberspace, even if its interface is text-based and not 3D. It
is richer, more interesting, more sophisticated and more real than anything Ive
seen on the Internet, or anything indeed anything Ive seen on or off-line in my
three years in the VR industry.

It was written four years ago, and ran on a 286 in 1Mb. 

Chris Stangroom was tragically killed last summer, just as we were discussing
reviving the "Jekyll & Hyde" world engine as the basis for a new on-line 3D
cyberspace. A terrible loss, not just for his friends, but also for the
community as a whole. We can only guess at what he would have achieved.


The Way Forward 

The work though, is still there to be done, and there is still plenty of
unexplored territory. I hope that it is clear that one doesnt need a new
Pentium every six months in order to be able to contribute to this effort. By
concentrating on a different, more abstract way, of modelling cyberspace, I
believe we can soon achieve more sophisticated, interesting and rich worlds,
where we can work, live out fantasies, and make tea.

Madrid, June 1996.