[937] in Coldmud discussion meeting

Re: [COLD] MUD system -> MUD system conversion...

daemon@ATHENA.MIT.EDU (Fri Mar 15 13:39:53 1996 )

From: Gregory D Lewis <glewis@maths.adelaide.edu.au>
To: coldstuff@cold.org
Date: Sat, 16 Mar 1996 04:33:17 +1030 (CST)
In-Reply-To: <Pine.BSF.3.91.960314180636.4097A-100000@tombstone.sunrem.com> from "Brandon Gillespie" at Mar 14, 96 06:12:01 pm

> Most MOO's, MUSH's, etc have a generic object system which is relatively
> similar (i.e. they all have rooms, or some such similar concept for a
> location).  The following idea is to create 'templates' which objects
> from any system can be dumped to, and which any other system can read back
> into their own db format.  The intention is to create a generic high-level
> specification for Virtual Environment System topology, so that the topology
> can easilly convert from driver to driver.

It seems to me to be fairly restrictive to only include members of the 
Tiny* family or derivatives thereof.  The Genesis driver reminds me much more
of the lpmud drivers than say raw tinymud, or even MUSH.  I may be taking a 
naive view I guess since I haven't messed with the internals.  But certainly 
someone has already used one of the lpmud drivers to do a MOO simulation :)

> To reexamine; the purpose of this system is to create a standard set of
> templates which can be used to abstractly represent the topology of most
> systems (MOO, MUSH, TinyMUSH, etc).  With this abstraction one could easilly
> convert from one system to another.  The level of detail/depth that is created
> would be restricted.  However, this system would enable one to convert
> the grunt portion of a system's topology easilly.
> 
> Along with templates there is also a generic set of 'data' types
> (dropping back to C for syntax conventions):
> 
>     INT (integer)                       125
>     STR (string, lists of characters)   "string"
>     LIST                                {item, item, item}
>     REF                                 $object

All these data types convert to LPC easily.  The possible exception being the
REF one, but that could easily become the name of an LPC file.

> The following are examples of template definitions:
[list deleted for brevity]

Again, these could all easily be translated into lpc rather than into db 
objects from this high level format.  The only slight difference was that
most Tiny* muds treat an exit as a separate objects, while most LP muds treat
exits as part of a room.  This isn't a big hurdle though, and certainly one
could write a Genesis core that treated exits as part of rooms or an LP mudlib
that treated exits as separate objects.  And certainly the listed format for
exits could easily be translated into LPC.

Anyway, I don't think you should overlook the possibility of cross fertilisation
between mud types that have traditionally not been close.  Certainly I've
had it on my mind to write a package for the Intermud-3 protocol currently
being used by LP's and some Aber's in ColdC.  I also wonder if ColdC could
benefit from some LP concepts like the LPC->C conversions some drivers now
do to speed up core or mudlib code (a ColdC->C conversion could convert some
of the central db "library objects" into modules for compilation into the
driver possibly).
 
Oh well, my two gold coins, or two pennies worth, depending on what brand I'm
on :).

							- Greg