# MUD system -> MUD system conversion...

Brandon Gillespie (brandon@tombstone.sunrem.com)
Thu, 14 Mar 1996 17:12:01 PST

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    I would like input on the following, for anybody who feels up to giving
    it.  The intention of such a system is to make converting VR aspects of a
    specific MUD system to another mud system.  It does this by abstracting
    the information to a command standard format.  The format is negotiable
    at this moment, what I use is primarily what I could think of at the
    moment.  The concept is workable; the format needs work, which is why I'm
    posting here :)

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

    While these templates do not follow a coordinated heirarchy of 'objects', they
    can be grouped within their own private inheritance tree.  For instance,
    another template could be defined using the generic location template,
    this second template would take on all of the aspects of the generic template,
    plus it would also further define a location.

    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

    The following are examples of template definitions:

    template described
        LIST desc                             // a list of strings

    template named
        STRING name                           // the exit name

    template location (named, described)
        LIST exits                            // a list of object references

    // a generic exit, it links two rooms, the concept of 'left' and
    // 'right' is abstract, this is just a link connecting both rooms.
    template exit (named, described)
        REF left
        REF right

    Using these templates as a standard, one could dump a few rooms simply with:

    // define the names first, sortof a 'prototype'
    define location $room_1
        name "Lounge"
        desc {"The lounge is a quite place where you relax"}
        exits {$exit_1}

    define location $room_2
        name "Closet"
        desc {"This is a dark closet, you can't see anything."}
        exits {$exit_1}

    define exit $exit_1
        name "Door"
        desc {"a reely bland door."}
        left $room_1
        right $room_2