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

Re: MUD system -> MUD system conversion...

On Sat, 16 Mar 1996, Gregory D Lewis wrote:
> > 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 :)

You are right, it can go further.

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

Well, look at this middle language as an abstraction, you are specifying 
the topology, so you look at an exit as a seperate unique item.  In the 
example the exit was more of a 'link' going both ways, which is really 
not a very functional solution in any VR system I know of.

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

I know this is off topic for the MOO list, but Cold does have what you 
are referring to (my copy that is), known as 'native' methods.

> Oh well, my two gold coins, or two pennies worth, depending on what brand I'm
> on :).

-Brandon Gillespie-
Home | Subject Index | Thread Index