MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

re: MOO and VRML

>>>>> "Dmitri" == Dmitri Kondratiev <dima@paragraph.com> writes:

    Dmitri> I don't know any other working architecture of distributed
    Dmitri> VR of today, except for DIS, which is "war-games" oriented
    Dmitri> only. Do you ?

[from my resume at http://eli.wariat.org/~rj/resume/resume.html]

LORAL DEFENSE SYSTEMS. 1993-1994. Consultant Helped the client
    implement CTES (Common Tactical Environment Simulator), a reusable
    component for DIS (Distributed Interactive Simulation) combat
    trainer/simulators. CTES is a virtual reality component for networked
    simulators that simulates a world in which humans participate. This
    world is mirrored on each node on the defense simulation internet
    (DSI) that is participating in the simulation. I led the development
    team that was responsible for all the executive and communications
    components of CTES. I personally designed the scheduling and
    dispatching components, and guided the design of the shared memory and
    Ethernet communications component, and the object instantiation
    component, which included dynamic binding to other objects at
    instantiation time.

This propject was written in C++ with an eye towards ultimate
conversion to Ada-9X (now Ada-95).  We were really pushing the
envelope of what DIS was capable of on this project.  We actually had
our own internal representation for everything and only wrapped it up
in DIS packets to satisfy contractual requirements.  It would have been
a lot easier if we could have chosen the representation.

The overall architecture involved having a bunch of objects that all
lived on all the machines.  A given machine had the human in control
of any non-fictive object (an object operated by a person, instead of
a state machine or production rules), and other non-fictives had
humans on other (or perhaps the same) machines.  Everything was
message passing.  Message passing had to operate over shared memory
and over networks, so no pointers, etc. allowed in messages.

Every message was time-stamped with its delivery time, not its
origination time.  Think of it like a "do not open until Christmas"
warning on the envelope.  This way, if a message could be sent before
it was needed to be acted upon, then it allowed for a certain amount
of not-lag and still gave good fidelity.  Dealing with anachronistic
message arrivals can mean having to undo some action or side-effect :-(

The really demanding part of this DIS stuff is the speed things happen
with.  A fighter plane heqading north at Mach speed approaching an
enemy air-to-air missle at Mach speed fires an interceptor at Mach+
speed.  These targets are born and die in a few seconds, and there is
a *LOT* of action, including real-time video, in the meanwhile.

In a MOO, things generally happen at pedestrian speeds, which is a lot
easier.  Message deliveries are critical to within a second or so, not
a few miliseconds or so.  There is less need for animated fictives, as
we have lots of real people participating.  The only real difficulty
is in maintaining active state for mirror objects on machines that do
not host the owning person for that object.

I think educational/conferencing/social moos in message passing
peer-to-peer VR are quite doable.  Shoot-em-up MUDs could present a
problem if the action got too fast with a lot of players in the same
virtual location.  But then, *I* don't care about shoot-em-up's :-)
[except professionally, when I get paid to care.]

-- 
-----------  "...  And the men went up and viewed Ai."  [Jos 7:2]  -----------
Robert Jay Brown III  rj@eli.wariat.org  http://eli.wariat.org  1 847 705-0370
Elijah Laboratories Inc;  759 Independence Drive;  Suite 5;  Palatine IL 60074
-----  M o d e l i n g   t h e   M e t h o d s   o f   t h e   M i n d  ------
References:
Home | Subject Index | Thread Index