[MUD-Dev] Supporting multiple output formats

Nolan Darilek nolan_d at bigfoot.com
Fri May 26 17:58:56 CEST 2000


Since I now have some time off, I've begun hacking at a project which
I began work on during December. I'll soon have the infrastructure
established to support this (I need to write an XML parser first), and
I wanted to toss this out to the list to receive ideas and/or
pointers while I'm near the beginning of my design phase.

One of my goals is to support multiple input and output formats. I'd like to
support text and HTML, and since my world will be spatial, I'm hoping
to establish a foundation atop which it is possible to describe a 2-D
layout of tiles or an arrangement of 3-D polygons. Instead of
supporting operations which send raw strings to users, I'm trying to
support a system in which all MUD output is represented internally as
XML, with server-side code reformatting the XML into whichever format
is requested. (Note that this XML is never seen by the client; it is
instead transformed into text, HTML, MCP, etc. which the client gets.)

Under the model which I am pondering, output is divided into two broad
categories. The first is a simple message. Messages are items which
can't be represented using a broad variety of methods. For example,
the message "I don't understand that command." would probably appear
as text (or HTML or whatever) regardless of what type of client you're
using. I may attach an attribute to the message tag such as
type="error", and I may add additional tags to support simple widgets
in cases where the message indicates that a choice can be made
(<message>Which sword do you mean? The <choice
id="$broadsword">broadsword</choice> or the <choice
id="$shortsword">shortsword</choice>?</message>, in which case you may
receive a clickable menu.)

The other broad category is the structure. Since items such as rooms
may appear differently in different clients, the data describing a
room and its features needs to be encapsulated in a markup language
which identifies the various components of the description. Structures
can also be nested; the room structure can contain a structure for
rendering the room textually, alongside another structure which
specifies tile positions. Structures are also used for poses, speech,
weather changes and other VR events, thus allowing for the possibility
of graphics and animations in some clients.

I haven't quite thought of how I will handle commands. I'd like to
destroy the notion that a command is a string which maps to a method
call. Instead, I'd like to define commands in an IDL-ish fashion which
is handled differently based on the client's interface, but I'm not
entirely sure how that should work.

Having made my requirements vaguely clear :), is there an open
standard which I might be able to use? I've delved into SOAP, but I'm
not sure if that would be overkill for the solution, if it might
work nicely for the command-to-interface mappings, etc. Is anyone
familiar with SOAP, and if so, how difficult/practical would it be to
use in this situation? Or, would I be better off if I simply used
SOAP, XMLRPC, etc. as guidelines, and instead drew up my own DTD's,
writing sample interactions in them to determine how well they'd work?




_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list