[MUD-Dev] Dynamic Descriptions

[clawrenc at cup.hp.com]

In <Pine.GSO.3.96.970804123156.6816E-100000 at tay>, on 08/04/97 
   at 07:54 AM, Martin Keegan <martin at cam.sri.com> said:

>On Tue, 29 Jul 1997, Nathan Yospe wrote:

>> Some of you have markup languages... I have one myself, but I am seriously
>> thinking of replacing it. What I am concerned with is this - I want to be
>> able to switch from running a text game to a graphical game of whatever
>> sort without difficulty. To this end, I no longer pass any real text
>> around... instead, I create information objects, which can key stored text
>> (out of a database) or stored graphics, stored hyperlinks, etc. What is
>> transmitted to the client is negotiated at login, and the server daemon
>> (not the mud) resolves, for example, text from info objects to pass to a
>> raw telnet client. What I am wondering is, do any of you have anything
>> remotely similar to this, and if you do, are you willing to discuss
>> technical details of it?

>There have been various abortive attempts to discuss this on
>rec.games.mud.admin, one of which foundered over the actual NAME of
>the scheme. It's not possible to discuss this surrounded by people
>who think it should be done using spare telnet option codes though.

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.

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 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).

>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.

--
J C Lawrence                           Internet: claw at null.net
(Contractor)                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...