[MUD-Dev] Dynamic Descriptions

[Nathan Yospe]

On Tue, 12 Aug 1997 clawrenc at cup.hp.com wrote:

:I suspect that the "true" solution will be to transfer dated, timed
:life, copies of objects sent to the client with the client then
:resolving on its own whether to present them as text, wire frame, 3D
:graphics, full hologram, whatever.  It calls for a detailed protocol
:between client and server for maintaining the transient copies of the
:IO objects at the client, but it also lowers the run-time overhead
:massively to the result that the breakdown becomes:

:  server -- handles all computation

:  client -- produces all IO

:  protocol -- from server is stream of IO directives indicating what
:IO to generate from what objects, to server is client and user
:responses.

:I have strong suspicions that this is what UO is doing under the
:covers.  Raph's comment on the client doing prediction of background
:movement etx would seem to require this sort of model implicitly.  I'm
:convinced that this is what M59 and company are doing.

Its also what GURU does. The problem is, I only have the server built, and
don't have the kind of machine I need to run it anyway... but there are
some _very_ interesting aspects to that. Without revealing too many
secrets, I have come up with a motion/behavior patter algorithm
transmission method, which the server attempts to apply to PCs as well,
predicting and updating their behavior patterns. This bypasses a great
deal of bandwidth problems, and creates an interesting situation... what
happens if someone makes a last minute switch, but someone else engaged in
combat with them suddenly gets hit by a network bottleneck? They will
observe incorrect behavior on the other person's part... and the graphics
_will_ be drawn before the correction is transmitted from the server.
There will have to be a bit of discontinuity introduced at this point.
Fortunately, I don't expect this to be common...

:Note that this requires massive devolution of the basic object model
:to the point where MUD objects become inherently fractured into a
:computational part, and a factory which produces IO objects which are
:then remoted to clients.  Potentially this also suggests a whole new
:model for the standard client/server MUD IO model, where instead of
:the server acting as a central computational store which delivers IO
:to its waiting clients, instead individual objects in the MUD world
:maintain interested party lists of those clients who are interested in
:what happens to them and as those objects are processed
:(independantly, in an MT environment no less), they individually
:generate their own IO messages to their waiting clients who then
:process the IO directives and (re)present them to the user.

I avoid this, primarily because it leaves the system vulnerable to cheats
and deception... It is an interesting avenue of thought, though.

:>I am against adopting Pueblo - it reeks of semi-proprietaryness.

:I don't expect their to be many non-proprietary clients for the next
:generation of MUDs.  There's nothing to drive the standards process. 
:The best we can hope and demand is a lack of platform bigotry (ie not
:Wintel only).

Java? Can't think of many other solutions... I would like to see multiple
ports, and I am indeed developing the clients for GURU first on BeOS,
MacOS, and NeXT/OPENSTEP with intent of porting to Rhapsody. Win32 can be
ported later. Bless Metrowerks.

:>This really could change mudding if we could get enough people to
:>support it. Everyone having their own conflicting standards is just
:>going to hold things back.

:I suspect that some of the Corba bits have addressed this area, but
:the key to the above I think is to develop a decent model for
:fracturing the computational and IO portions of basic objects, along
:with the factory/consumer model, such that it can be made very very
:simple for developers.

I've come up with some decent models for generation of new objects and
programming their behavior in the frame of reference of the rendering
system and server. (The name, incidentally, refers to the exact concept
you are describing here - Graphical User Rendered Universe. Ironic that I
designed the initial concept before I logged on to my first mud, and yet
only now is my mudbase starting to resemble GURU's server code...)

"You? We can't take you," said the Dean, glaring at the Librarian.
"You don't know a thing about guerilla warfare." - Reaper Man,
Nathan F. Yospe  Registered Looney                   by Terry Pratchett
yospe at hawaii.edu   http://www2.hawaii.edu/~yospe           Meow