💾 Archived View for gemini.spam.works › mirrors › textfiles › computers › CYBERSPACE › cyberter captured on 2020-10-31 at 22:07:17.
-=-=-=-=-=-=-
Article 4307 of sci.virtual-worlds:
Newsgroups: sci.virtual-worlds
Path: news.u.washington.edu!milton.u.washington.edu!hlab
From: snoswell@ucs.adelaide.edu.au (Michael Snoswell)
Subject: TECH: Info on CYBERTERM Open System (long)
Message-ID: <1992May31.221443.12742@u.washington.edu>
Originator: hlab@milton.u.washington.edu
Sender: news@u.washington.edu (USENET News System)
Organization: Information Technology Division, The University of Adelaide, AUSTR
Date: Sun, 31 May 1992 16:24:54 GMT
Approved: cyberoid@milton.u.washington.edu
Following is the document I promised a while back on the system I am
developing. I have received many requests for this data so here it is
(a little incomplete or it never would have been posted). I'm emailing
copies to those who requested it and will be in touch with programmers
who said they were interested (see later).
---------------------------------------------------------------------------
OSC
Open System Cyberterm
THIS DOCUMENT
This document is an overview of ideas and concepts that have evolved
over the last year or so. It is not meant to comprehensive, exhaustive,
complete or fixed. Any items mentioned herein are open for discussion
and modification through arbitration (ie if you've got a good idea, tell
me and we'll use it!). Criticism is most wellcome as this has chiefly
been only a two person project with various input from 1/2 dozen others.
Arguments and pointers from others would be gratefully received.
The first part of this document discusses some broad ideas and then
gives a brief description of the terms used. Following this is a 1/2
technical discussion on a walk though of some aspects of the system.
After that a more detailed examination is made of the various terms
described briefly earlier and finally a look at other, less related
topics is covered in cursory fashion.
After all that a brief description of the software as it stands is
given, along with projected milestones and pleas for
technical/programming assistance.
This document mentions many ideas and concepts that stem from the use
and implementation of the underlying protocols. This paper discusses
broad uses of the protocols and the resulting system rather than
focusing on the protocol itself. The reason for this is two-fold:
1) The protocol by itself would seem pretty meaningless without
describing how it works and how its resulting use affects the
dynamics of a system, and
2) The protocol isn't firmly set. As the system is developed, more
holes are found and things change. There are 1 dozen or so basic
messages and a dozen or so rules that are followed, but these are in flux.
It is hoped that this paper will give readers some familiarity with the
type of system that is beeing aimed for. A later paper, covering the
nitty gritty may be produced, but the detailed explanations may be left
to the source code itself when it is released.
Having read this discussion first, users and programmers will be in a
better position to criticise and aid in the systems development (by
discussion and programming support).
Note: Where possible I have put terms in capitals which refer to
concepts/objects whichare peculiar to this system. This is to try to
differentiate items when using English to describe some ideas etc, to
make things a bit clearer.
SYSTEM OVERVIEW
The need for a low cost, low bandwidth cyberterminal (CYBERTERM) has
arisen due to the increasing need to communicate over existing data
channels with existing hardware. The system is aimed for widespread use
over a number of platforms and data connections. Initial release is planned
for late '92 in a shareware format with full source code for all available
systems.
INTERFACE
The interface is simply using the screen with the keyboard and mouse to
provide a window view into a cyberspace area. As source code will become
available.
The addition of Power Glove, HMD and other devices will be
encouraged but not initally supported and will not be required.
The nature of the system will be such that if you have a PC XT with
hercules graphics then you can display only wire frame at 1 frame per
second (or whatever the software can manage). If you have an Indigo or
similar then you are lucky enough to be able to display 30 frames a second,
solid or rendered. The idea is that all the different systems will be able to be
functionally connected together in a meaningful manner. If you have a full
body suit, lucky you and you get better integration into the cyberspace etc etc
etc.
What this all means is that the code has a central communications core that is
common to all modules on all systems. The interface business is merely a
variable front end. All systems will use the same messages etc to
communicate, but the low end users' systems will not request the extra data and
will not be capable of producing some messages.
(eg if you don't have a mouse then movenment is via keyboard. If you have a
Data Glove then movement can be via gestures).
INITIAL SYSTEM
The system will initially be designed around a PC, with Amiga and X11 (on a
Sun IPC) mods being made as we go, but with no special provisos for these
machines at this point. Software is currently being written and a beta version
will be available in a few months (now is May '92). Release will be via
request to selected users for immediate feedback, followed by general
shareware release.
SYSTEM ARCHITECHETURE
The whole nature of the cyberspace is controlled by the messages that are
sent, which abstractly define the rules for objects, clients etc within the
cyberspace. To more clearly describe the nature of these rules and
messages, a number of terms have been borrowed and coined to describe
new/borrowed concepts. Once these terms are defined, then it becomes
much clearer as to how the whole thing fits together and the interaction of
objects and the nature of this interaction will become evident as you
understand the rules and contraints which define the behaviour of the
cyberspace.
DEFINITIONS
These definitions are brief and are given to allow a fuller understanding of
the descriptions to follow. A more detailed discussion of these terms
will follow later.
CLIENT
A CLIENT is the term to describe a person (USER) who is connected to a
system. The CLIENT may be automated (an AGENT).
SERVER
A SERVER is the central message handling facility which handles the data
flow between CLIENTS. (A bit like a BBS)
LOCAL SERVER (LS)
A LOCAL SERVER is a SERVER that resides on the same machine as the
CLIENT.
REMOTE SERVER (RS)
A REMOTE SERVER is not at the same physical machine as the CLIENT in
question.
CYBERTERM (CT)
This is the term to define the CLIENT and the LOCAL SERVER together which a USER
interfaces to. This all resides on his local machine.
SECTOR
A SECTOR is a region of CYBERSPACE which is controlled by a single
SERVER.
SECTOR CONTROLLER (SC)
This is another term for the SERVER, but which covers the CLIENT that is
local to that SERVER (akin to a News conference moderator or a BBS
sysop).
PERMASPACE (PS)
PERMASPACE is an area of the SECTOR which has been allocated to a
specific purpose. The data defining this region resides in the SC which
controls the SECTOR.
PRIVATE PERMASPACE (PPS)
PERMASPACE can belong to a single CLIENT (or else it belongs to the SC). If a
USER acquires a region of a SECTOR for their own use, that region is
called PRIVATE PERMASPACE and is controlled by the owner CLIENT's LOCAL
SECTOR CONTROLLER (ie the SERVER which resides on their own machine).
LINE
A LINE is the connection from the SERVERs to the CLIENTS, LINEs can be
virtual or real.
AGENTS
AGENTS are macros that use the messages and protocols of the system to
perform tasks as the USER himself would. There are 3 types of AGENTS
defined so far. PRIVATE AGENTS, SC AGENTS and INDEPENDENT AGENTS.
ASPECT
ASPECT is the description of an OBJECT and covers visual and audio
definitions in an extensible hierarchy of increasing complexity. All
objects have default ASPECTs.
CYBERSPACE CONFERENCING (CBC)
This is the initial "let's get together and have a chat" aim of the
system and is useful when people ask "So what are you working on?". You
say, "I'm working on a Cyberspace Conferencing system", or something
like that.
GUEST
A GUEST is a CLIENT who is remote to your location who is connected to
your LOCAL SERVER.
BBS
A bulletin board system, which when in "chat" or "conference" mode is a
good analogy for what this system will build upon (ie a graphical
version of a BBS CB channel.)
OBJECTS
OBJECTs are any things which exist within a SECTOR and and listed in a
SERVER database. This includes CLIENTS, AGENTS, PERMASPACE etc.
ID
ID applies to AGENTS, CLIENTS and SERVERS. It is a unique 4 byte number
where the top 4 bits define what type of object the ID belongs to.
FAR - 1,000 units
NEAR - 100 units
CLOSE - 10 units
VERY_CLOSE - 1 unit (ie 26 adjacent units)
A DEMONSTRATION RUN THROUGH
Perhaps the best way to show how the various features of the system interact
is to give a description of a typical session. This description will not
be exhaustive and will give some technical details of the message
passing that will take place during such a session. A complete
description of all the features will not be given here as that would
take too long and this is only meant to be an overview. However, what I
hope is to be able to give some insight into what the working system
will be like.
So here we go.
(by the way this description is of a screen and keyboard system, but as
stated above, you can use whatever hardware/imagination you have
available)
First off when you start up the CYBERTERM you have a blank screen with maybe
a few control buttons around the edges.
The first step is to log into the LOCAL SERVER. Now this is a SECTOR
CONTROLLER that resides on the same machine and in the first incarnation of
the software is all in the same executable.
This connection is done by hitting the 'connect' key
(or mouse button etc). This will send a REQUEST_TO_ENTER message to your
LOCAL SERVER, but first the interface will require that you enter some
parameters. These are:
1) your proposed entry point into the LOCAL SECTOR, and
2) the proposed viewing direction.
In a more advanced system these parameters will probably be pre-set in
an option menu so you don't have to enter these details each time, but
that's the way it is now
(Note: There are quite a few places where things can be pre-set like
this, as you'll see).
Once the CLIENT software has assembled this data it sends the message to
the LOCAL SERVER prepended by your ID, a unique identifying code (4
bytes) that defines you as a human CLIENT as well as giving you a unique
handle for reference purposes. An additional parameter, velocity, is set
to zero and is the final part of the message.
The connection between the CLIENT and the LOCAL SERVER is a buffer
that emulates a LINE.
A daemon type function transfers the message across to the SERVER's input
(and visa versa).
The reason this is done is so that the software for a REMOTE SERVER and
the LOCAL SERVER will be the same, except that the daemon will be
different (ie transfering data to and from a modem, serial line, socket,
or whatever). So as far as the SERVER is concerned it is running
autonimously from the CLIENT and the human interface handling software.
The SERVER checks its internal database of objects to see if you are
allowed to enter at the specified point (more on that in a moment) then
sends a MOVE_TO message back to the CLIENT. This includes the CLIENT's
ID to make sure the right person gets the message (not necessary
obviously as you're the only one logged into your machine), a location
tuple, a direction tuple and a velocity tuple (which is zero in this
case). Now it looks like we're already sending redundant information, but
these are generic commands that can apply to many situations.
You CLIENT software now gets this MOVE_TO message and can throw up
an image on the screen which shows what the SECTOR looks like from this
point.
What's there to display? Well by default the 'floor' of the sctor is
blue and can be displayed as a grid. The range of co-ords is 2**16
(32768) only positive, as a 32 bit fixed decimal number. This
effectively gives a cube 32768 units on a side. That seems small but
think of each unit as one metre. This means the SECTOR is about 32kms
cubed, with increments down to 1/30 mm. I really think this will cator
for system (and user) requirements for a long time to come. There is
room for much more detail than this actually (2**32 time more) as is
shown later under PRIVATE PERMASPACE.
Okay, so we see a blue grid below us. Our CLIENT software is keeping
track of our velocity and co-ords at the last vector change (ie time
stamped) in its internal object database (this is separate from the
SERVER's object database). So a simple look at the time and a scan of
the database will give the current location of all objects and the
screen can be updated accordingly. If your machine is slow this screen
update is slow etc.
Now that you're logged into the LOCAL SERVER things get a bit more
interesting. To make things a bit clearer I'll skip over the details a
bit here and get to a remote connection.
Suffice to say that the objects contained in the LOCAL SERVER all belong
to your PRIVATE PERMASPACE. There may be objects here, for instance that
represent your hard disk and so you may have a graphical operating system
where you can move files, launch applications etc. You can construct
objects and store them for later use. Certain areas may be defined as
dorrways to the control of real-world apparatus by telepresence etc. So
you now have your own SECTOR, a whole world really, in which to create
and move. Now all this on your own machine is nice but dull.
The next step is to send a TRANSFER_SECTOR command. This will move you
to another SECTOR. This will obviously be a REMOTE SECTOR. It's up to
you to specify a legal SECTOR you wish to transfer to and it's up to
your LOCAL SECTOR CONTROLLER to know how to connect to the SECTOR.
Asumming all this has been set up your LOCAL SC (for modem) dials up the
remote SC and identifies itself as an SC that has a CLIENT that wants to
enter. This is sent as a REQUEST_TO_ENTER command (as before). Your
CLIENT software knows that to issue a TRANSFER_SECTOR message you must
enter a location and view direction so it prompts you for them (or gets
it from pre-set options as before). The local SC passes the info on to
the remote SC. If the request message is okay, a MOVE_TO command is
sent from the remote SC to the local SC which now knows that any data
coming in from the CLIENT (on LINE x) is transfered straight to the
remote SC (on LINE y) and visa versa.
Now that your CLIENT software has a new location and viewdirection it
adjusts it's internal object database and updates the screen accordingly
(the blue grid).
When you entered the SECTOR the SC sent a message of its own to all
other users who are within NEAR (100 units) of where you entered.
These messages say what your ID is, your vector and location (this is
actually a PERSONAL_ASPECT_DATA message which has ID, vector and
location in the front of the message but without the ASPECT data as the
SC doesn't have this yet).
These other users may have their systems set up to ignore these
(unexpected) messages, but if they process them then you,
the new user, will appear on their screens in the appropriate place and will be
placed in their individual object databases. They may also have a
database of 'know ASPECTS' and can check to see if they already know
what you look like and so can display you in your full glory straight
away. Alternatively they may have their system set up to automatically request
your APSECT if it is unknown and to display it then.
Anyway, you've just entered this REMOTE SECTOR.
Now you can send a message (or a more sophisticated system would be
pre-set) to ask the REMOTE SC what the brief details are of all users
within NEAR of your location (that is, to send you PERSONAL_ASPECT_DATA
messages with ID, vector and direction). This data is added into your
CLIENT's object database (with a time stamp) and the objects appear on
your screen with the default ASPECT. You can request the details of
other users over different distances first off if you like. Once you know
the ID of other users you can REQUEST_ASPECT_DATA of a specific ID, to
whatever level of detail of ASPECT the REMOTE SC has in it's database.
So on your screen these other users appear as arrows (their default
ASPECT) or their real shape.
When you move (that is, change your velocity or direction) your CLIENT
automatically sends a message (MOVE_TO) to the SERVER. If this is okay by
the SERVER then it sends a MOVE_TO message to you telling you where to
move to (the reason for this is made clear later) and then the SERVER
distributes the message to all NEAR CLIENTS. In this way, as you watch
your screen with these objects moving around in straight lines until
they change vec/vel when you get a message from the REMOTE SC telling
you their new velocity/direction. If you turn around your system sends
a MOVE_TO message that is distributed and others see your shape turn around etc.
It is important to note that there is no collision control and it is quite
possible for you to move straight through someone else.
(Note: The only possible exception to this is stopping over a PERMASPACE
unit you do not own (see later) or the possiblity that two CLIENTS
cannot be at the same point at the same time. There is no logical reason
why this could not be so, it's just that it doesn't see right to me.
Being instantaneaously at the sam epoint is okay, (ie moving through
each other), but being stationary at the same point? Comments please.)
An optional message that you can send to the SC is CHANGE_UPDATE_RATE
which tells the SC how often to send you location, vel and vec updates
of all CLIENTS within a given distance of yourself. Normally you would
have to request this information specifically and the position of users
you see on the screen may be false (for example a user may drift out
of the NEAR distance from you but your object database is still tracking
them saying they are moving at such and such a vector and speed when
actually they may have changed direction etc. So with a CHANGE_UPDATE_RATE
message you can request to be updated on the stats of users who are
NEAR or FAR or whatever say every 10 seconds. Of course if they move when
they are within NEAR of you then you will be automatically updated anyway).
So now you can sit and watch these shapes going by.
Other commands within a SECTOR are SEND_MAIL, JUMP_TO,
REQUEST_SECTOR_TRANSFER etc.
Similarly to requesting the ASPECT of users in the area, you can
request the ASPECT of PERMASPACE in the area.
PERMASPACE is permanaent regions that default to blue.
These will usually consist of PRIVATE PERMASPACE but some regions may
be owned by the SC such as public database access areas and public
bulletin boards (more on these later).
Just like CLIENTS, PERMASPACE has a default ASPECT that is a blue cube
that occupies the unit cube that is the centre of its local co-ordinate
space. Requests for higher level ASPECTS may reveal these cubes to be
buildings, flashing lights or data structures etc.
A PRIVATE PERMASPACE ASPECT may reveal that it belongs to a friend of
yours. (It may his name on top or maybe you recognise his style of
castle!)
You can move through PERMASPACE but you CANNOT stop (ie have 0 velocity)
when in a unit cube of PERMASPACE which does not belong to you.
So you stop one unit away (VERYCLOSE) and send a
REQUET_TO_ENTER_PRIVATE_PERMASPACE. This is interpreted by the SC as
a TRANSFER_SECTOR message, to the LOCAL SERVER of the user who owns
that PP. If the request is okayed by the owner then you are sent a
MOVE_TO message that moves you to the coords of the PP.
Now you have transfered to a new SECTOR and are controlled by
the owner's private SC on his machine. The remote SC you were controlled
by now routes all your data straight to the LINE that that new SC is on.
(in a similar way to how your LOCAL SC is re-routing all your data
straight through to the modem).
Once again your screen is blank and you can request to see what's around
you. This person may have his SECTOR set up to look like a lounge room
or as rolling hills. All messages from users who you could see before
(ie those outside that unit cube of PP that you're in) are filtered out
to reduce bandwidth required (you may, for instance want to keep mail
coming through. If you have a powerful system you may still get all
'outside' messages but make the walls of the living room appear
transparent like smoked glass etc).
Now that you are in his SECTOR you must abide by his rules. If you send
a MOVE_TO message that will make you collide with object in his PP (eg a
chair or wall) then his sector can return okay for that request, but
when it calculates that you've hit a wall, it can send an addittional
MOVE_TO message that sets your velocity to zero. In this way you must
follow the rules he has set up in his PP. Obviously if he proves to be
obnoxious you can send a EXIT_SECTOR message that the main REMOTE SC
intercepts and so moves you back out into public cyberspace,
garuanteed.
Other users can enter the PP of your frined at the same time so you
can have a 'private conference with only those present'. At that time
his LOCAL SC daemon has set up secondary virtual LINES to allow the
messages from several remote CLIENTS to come down the one modem
connection. As each message is preceeded by the message senders ID, it's
a fairly simply task fo rthe daemon to put the incoming messages into
the appropriate virtual LINE buffers so the SC thinks there are lots of
people/modems connected up.
Of course, the main remote SC may also provide private conference rooms where
similar duscussion can take place.
This PP may alternatively be the front end to access a commercial
database, a game service, a ticket sales office etc.
So you want to establish your own PP within the public SECTOR? You send
a REQUEST_TO_AQUIRE_PRIVATE_PERMASPACE message that is sent via the SC
to anyone who is CLOSE to you (within 10 units). If less than 50% of
those nearby say 'no' to the SC then you aquire 1 unit of PP and this is
registered in the SC's object database. You can optionally send
PERMASPACE_DATA messages to the SC that define the ASPECT of your PP to
whatever level of detail you desire so others can see your new
aquisition. Clearly, you can aquire several PP units next to each other
and build up a composite structure that is more impressive.
This aquisition is monitored by the SC and there may be limits defined.
Some reqions of PP that belong to commercial users may be large (eg a
database service for stock information may have a large area of PP that
(when you request to see higher level aspects) may be large building
surrounded by wide grass areas with fountains and gardens). Maybe there
would be large areas within the owned PP that has no higher ASPECT so
that in a crowded area of many PPs the structure will stand out as it
has all this 'open' space around it.
You can send mail to a friend by several methods. The most straight
forward would be to use the SEND_MAIL message where you specify the
recipients ID and then the message (no set format, just specify the
length in 4 bytes). The mail will be sent straight to his LINE. If he is
currently transfered to another SECTOR, the mail is sent on to the next
SECTOR to which he travelled (he may have moved on from there too).
He may have his CLIENT software set up so mail appears as a flashing icon on
the screen or as a full letter box outside the little cottage that is
his PP.
Mail can also be send to a location and the SC will try to inform the
owner, if the mail is not received, a MAIL_FAILED message is returned.
Text mail may be appended to a PP ASPECT temporarily. In this way if
no-one is 'home' (maybe not logged in or in another SECTOR) then you can
send the mail to the PP location and when he person returns he will see
an added object on his normal PP aspect. This object may be a piece of
paper with the text message written on it.
In a similar way a true bulletin board could be set up, where people
could leave messages for others to read.
So you can conference with otheres, send mail, access commercial
services etc.
The commercial services may first connect to the system using their
original 2D flat screen interface, so when you enter their PP you just
see a single screen. In this way the interface changes would be minimal
to start with but they could develop better interfaces to make data
access more efficient. A statistics service could have a PP where data was
represented as dynamic 3D structures etc.
Probably the most useful items within the cybersapce are your AGENTS.
These items exist as packets of messages that together form an entity
that is a type of object. See the comprehensive definition later on for
details. Agents can do whatever you can do, in your place. Some agents
are simply objects that you use (for instance a 'design-an-aspect' agent
may allow you to draw items in 3D (walls, texture, motion etc) and will
then create the ASPECT data for you). It may be an access key tool (eg you
might guy a '10 shot' agent from a database service. When you want to
access that database you instruct the agent as to what you want. The
agent then goes off to the databases PP and gets a high prioirty of
service (because you paid for it!) and also knows how the database works
and so can access the data faster and then mail the data back to you (or
maybe return to you itself with its ASPECT changed to show you the data)
and after the tenth use it doesn't come back.
The last sort of agent is independant. These actually are macro
languages that are executed by the SC and may act as guides
to newcomers or perform tasks within the sector for you (ie like a
servant). They can exist by themselves. You can have an AGENT that
'lives' in you PP and answers requests to enter from other CLIENTS while
you are tied up somewhere else. Now this brings on all sorts of
possibilities. You could send an AGENT to a conference in your place and
it may respond to text as a human would, to gather data for you. For
this reason and others, there is one strict rule, and that is that the
default ASPECT of agents are a white star made of three perpendicular
axes, no matter what.
Another example is to have several agents that travel with you in unison
and which have ASPECTS that fit into yours to make one larger, more
impressive ASPECT.
One ASPECT detail that hasn't been mentioned is sound. Obviously a sound
interface would be good (so you can talk to people you meet other than
just sending mail or typing stuf in during a private conference). Sound
would be easy enough to implement into the SEND_MAIL message protocol
(you get mail from someone who is in such and such a direction
therefore the headphones position the sound source accordingly). But I
would like to incorporate it into the ASPECT as well so you could hear
someone comming, even if you were looking in the wrong direction.
(Note: Its clear that this system is open to abuse to rogue CLIENTS that send
invalid messages. The buck will have to stop at the SERVER and so this
could end up being a pretty awesome beast as far as functionality goes.)
DETAILED DESCRIPTIONS NOT COVERED BEFORE
(incomplete section)
(note: I covered a bit more detail than planned above, hope it suffices
for now or I'll never send this thing!)
===================================================================
===================================================================
- each CLIENT has an ID derived from their "login" address (eg internet
address) and so is unique. Along with ID, each CLIENT has an ASPECT
which describes how they appear to other CLIENTS. ASPECT by default
is an arrow with a single feather to indicate 3D orientation
ASPECT has levels, the one just stated
is the default level, 0. The next level is "wire frame" representation
that consists of a variable length list of points and vectors. They
have variable colour and have a DYNAMIC | STATIC parameter, if DYMNAMIC
is TRUE then motion paramters follow (undefined yet). The last parameter
is EXTENDED. If EXTENDED is TRUE then a further level follows defining
solid geometry descriptions, which end with the EXTENDED parameter
for future expansion. Things are designed this way so that a simple
system (AT with CGA graphics) can select only the minimum display
criteria because that's all it can handle. Better machines '486,
Silicon Graphics Workstation etc can go for full solid rendering etc.
===================================================================
===================================================================
SOFTWARE STATUS
The system so far has a CLIENT that connects to the LOCAL SERVER and
allows the user to move around within their own SECTOR, requesting
information on and displaying PERMASPACE objects that are already in the
SERVER's object database. This is all in wire frame (easily upgraded to solids,
but it goes too slow on the PC (386SX) for development work).
This system works on a PC and on a SUN (X11).
The graphics library used is VOGLE, but REND386 is being kept in mind
for PC stuff. An Amiga version is in the works (mainly just requires the
VOGLE driver). (VOGLE is available from most ftp sites I assume, I got
it from the Australian ftp mirror site, archie.au:/graphics/graphics/echidna)
The code is in ANSI C. This is ideal stuff for C++ but that would limit
the platforms we could easily port to (and not enough people are
comfortable with it yet).
HELP WANTED
As you can see, there are many ideas brewing here and so few
implemented. I really hope to have something significant done by the
beta release date later this year ('92) before tasks and improvements
can be farmed out to others. Ideas on modifying the concepts involved
would be wonderful, but programmers with time would be even better. Managing
remote development seems a difficult task. Breaking this into neat
packages isn't really possible at the moment. The only area that could
be done (perhaps) is the graphical operating system stuff for your
local computer. I hope people will disagree with me and show how this
can be done as a joint effort. My time for co-ordination of such an
effort is woefully limited which is why I have perservered with the
programming alone thus far.
As I think I mentioned earlier, I want to make this software freely
available with limited source distribution until it looks stable. But
in the long run, the source should be available for everyone to update
and use as they will. My main reasoning for this is to give everyone a
chance to have a working interactive system that they can connect up
together.
So far I have received about 30 requests for information/code. This
document will be posted to sci.virtual-worlds and sent to each of the
senders. If after reading this you want to help with programming, then
let me know. Any and all comments (public and email) would be
greatly appreciated.
Cheers
Michael Snoswell June 1st, 1992
snoswell@sirius.ucs.adelaide.edu.au
p.s. okay, so the doco's not complete...(sigh)
--
Michael Snoswell snoswell@sirius.ucs.adelaide.edu.au
Vision Systems Limited 08 343 0462
South Australia "Profound quote"