This is not a full set of notes: it is an outline of what was discussed in the lectures. The topics here are not covered in the unit textbook or indeed any one book.
The textbook, and most of the lecture content and unit assessment, is concerned with how Internetworked Virtual Reality systems are implemented. This is a fascinating topic. But it is important to think about why anyone would want one in the first place. And since you can't have an internetworked VR without at least one other person involved, it is also important to consider what they will do with it.
A Networked Virtual Environment, or NVE, is what we build with Internetworked Virtual Reality technology.
NVEs are themselves a subset of what is called groupware or CSCW (Computer Supported Collaborative Work) software. People in NVEs are an example of CMC, Computer Mediated Communication.
LAN parties to play Quake or similar
Massively Multiplayer Online Games such as Ultima Online, Everquest
SIMNET/DIS based military simulators used for training.
Text based virtual environments.
|Time||same||Quake party, eScience lab||NVE, MUD, MMOG|
|different||Some art installations|
Almost all NVEs are same time: it's difficult to interact otherwise.
The first lecture gave a definition and taxonomy for virtual reality. Here are some additional definitions for NVEs:
The WWW is persistent: doesn't go away when you log out.
MUDs, MOOs, and MMOGs are persistent, as are the cyberspaces found in books and movies.
Most military NVEs are not: these sessional virtual worlds are set up for an exercise lasting hours or a few days at most, then thrown away.
convergence: Internet Protocol (IP) is becoming underlying transport mechanism for email, telephone, movies...
divergence: at the same time diversifying number of platforms: home computer, console, PDA, cell phone...
Real world task: military, scientific
Real world gaming: group of friends become online clan
Pure virtual: people meet only in cyberspace
What you access NVE with: computer, PDA...
Where: home, work, public space, aircraft,...
Who/Why: social/cultural frame
D&D is the archetype from early 70's
Cooperative game: multiple players sit around a table, exploring dungeons and fighting dragons, using only words and their imaginations.
A text based game written by Crowther & Woods in the early 70's, based on D&D. Led to Zork and the Infocom range popular late 70's, early 80's.
Single player games with a simple Command Line Interface (CLI). Player types simple commands, the computer responds:
It is dark. You are likely to be eaten by a grue.
I see no torch here.
Terminals connected to CPU through 9600 bits/second serial lines, slower than modern modems.
Text is extremely compact. It is not low resolution: text descriptions generate qualia, mental images, in the readers mind, and these are often more detailed than any current VR system.
Text descriptions are much easier to create and store than 2D or 3D graphical images.
MUD is Multi User Dungeon. Adventure extended to handle multiple players at once. Unlike original D&D, players frequently hostile to each other.
First MUD created by Richard Bartle around 1980.
Low storage and bandwith requirements suited to early Internet and dialup systems.
MOO is MUD Object Orientated, referring to the new scripting language used to implement them.
MOOs are (mostly) more sociable and non-aggressive than MUDs, although over time many MUDs have also become peaceful places.
The best known is LambdaMOO, founded at Xerox PARC in 1990 by Pavel Curtis, now with a population over ten thousand.
MUDs/MOOs are virtual realities. You don't need a headset for VR. Books are immersive! That said, the CLI is not transparent or behavioural for most computer users today. In the 1970s and 1980s, almost everybody who used computers was familiar with CLI systems.
Been there, done that. MUDs and MOOs have been in existence for many years, and the social aspects of how people behave in these NVEs are therefore well studied.
Stable systems. In most NVEs the focus is on the technical details of getting the thing to work at all: bandwidth, resolution, crashes... MUDs and MOOs are very reliable well-tested systems that let us concentrate on what people do.
What do people do in MUDs and MOOs? The answers turn out to be much the same for every NVE.
Important aspect of all NVEs: who is allowed in?
MUDs/MOOs often allow anyone guest access. Guests are severely restricted in what they can do, and often can be easily identified as such by the residents.
Most MUDs/MOOs have a hierarchy similar to that found in computer operations centres: normal residents (users), residents with programmer status who may modify the behaviour of the NVE, and a few wizards who as system administrators can do anything.
In LambdaMOO the wizards became overworked, and it is now a democracy with proposed changes being voted on by all residents.
Major activity, especially in the more peaceful MUDs/MOOs.
Designers of groupware or other CMD systems often try to distinguish between "work" related communication and purely social. This never succeeds. People will use your NVE to gossip, arrange parties, or whatever else regardless of any policies or regulations.
The original intent of MUDs. Can be broken into exploring, which is affected by other people, and puzzles, which generally are solved by individuals and have no effect on anyone else.
MUDs and MOOs are fully persistent. How many graphical NVEs have been running for ten years?
What happens to your online identity when you log out? Usually it stays there, "asleep."
Part of the original MUD environment was the capability to attack other people - they were more interesting opponents!
The Player Killer, PK, is anyone who wants to harass and annoy other players. This happens even in supposedly peaceful NVEs: the accepted estimate from commercial MMOG managers is that 10% to 15% of all participants will behave as PKs.
Unlike almost every graphical NVE, the MUD/MOO environment - rooms, objects, even people - is created within the MUD/MOO, by logged in residents. There is no separate authoring software or upload step.
This is a natural consequence of the text based medium. Programmers are accustomed to working with command line interfaces and tools, so it was easy to build them within the MUD/MOO itself.
MUDs and MOOs distinguish between private space, which belongs to the individual, and public spaces, which are open to everyone. Individuals may have their own "miniworlds" which while part of the MUD cannot be reached normally. The public spaces are controlled by the wizards, with "zoning laws" so that new sections can only be linked to the public space with their approval.
(This is a bit simplified: the topology of MUDs/MOOs can be seriously wierd.)
Any resident of a MOO can usually create new places and things, and give them text descriptions. Programmers can change the way the MOO environment interacts and behaves.
MUDs and MOOs are built with an interpreted programming language. Most MUDs have a very similar language, and most MOOs are built with the LambdaMOO language. Since it is interpreted, and the development environment is the MUD/MOO itself, programming is just another activity within the NVE. Again, this is something you just can't do in almost every graphical NVE.
MUDs and MOOs have long experience with PK behaviour, and have developed mechanisms (programming language based) and social conventions in response. Navigation, interaction, and even communication can be controlled or restricted.
The programming capabilities within MUDs/MOOs make it very easy to try out new ways of collaborating in NVEs.
A MUD or MOO has two components: the server and the database.
The server does low level network and file I/O, but is primarily the interpreter for the higher level MOOcode or MUDcode programming language.
The database is not a traditional row/column SQL type database, but more a persistent object store. Every object in the MUD/MOO has a single unique magic number identifier, which is never re-used. Every object also has a number of properties: name, description, interaction code, etc. Everything, including the online personas themselves, is described by an object and code.
The MUD or MOO is divided into rooms, objects which may contain other objects and participants. A park, spaceship, or town square is still a room. Every participant or object is always "in" some room, and navigation in a MUD/MOO is from room to room without your location being tracked to any finer level. Everybody in a room can see and hear each other.
The LambdaMOO server can be downloaded from SourceForge. It is 355K, about 37,700 lines, of C code. The LambdaMOO database, which is really what makes LambdaMOO a distinct place, is about 900,000 lines of MOOcode.
In 1999 LambdaMOO had a population of around 10,000 people, and was running on a host computer with 256M of real RAM and using around 360M of virtual memory. MOOs with a population less than 50 can be run on a Pentium/75 PC.
Written by Hugh Fisher