MXP/Extending MUD Technologies (Was Re: [MUD-Dev] Object Representations?)

[Patrick Dughi]

On Tue, 22 Aug 2000, Nathan Clemons wrote:

> On Tue, 22 Aug 2000, Patrick Dughi wrote:
> 
> > On Tue, 22 Aug 2000, Lazarus wrote:
> >
> > > May I suggest you take a look at MXP?  Zugg has created a Mud eXtenson
> > > Protocol to allow you to indicate specific parts of text of interest as well
> > > as provide multi-media objects.  Docs can probably be found at
> > > http://www.zuggsoft.com/zmud/mxp.htm
> > 
> > 	Ack. I would most certainly _not_ look at MXP.
> > 
> > 	I won't list the old arguments, but I'll point you at two posts on
> > the circlemud mailing list; 
> > 
> > http://post.queensu.ca/cgi-bin/listserv/wa?A2=ind0007&L=circle&P=R7969
> > 
> > and my reply to a holdout who 'didn't get it'
> > 
> > http://post.queensu.ca/cgi-bin/listserv/wa?A2=ind0007&L=circle&P=R28378
> > 
> > 				PjD
> 
> A "holdout" who happens to still be interested in technologies of this
> nature. :)
> 
> It's still my feeling, that with care:
> 
> * HTML-like styles make it easy for server-side developers and clients to
> understand. Perhaps something more XML-ish is in order, but I wouldn't
> know. Never played with the stuff. Something along this line is also
> easier for the clients to develop and render to the viewer/player.

	It's easier for the clients, but has the same problem that was
described before with the LISP-based parsing engine; It's difficult for a
client to seperate what 'ought to be' in text to what 'is'.  Even with a
parsing scheme, there still exists the ability to spoof or fake out
someone.  Imagine something like IRC using a system like this - you could
easily fake out a client, and force them to download (maybe even run)
files, log off, basically run any command through clever use of output.

	Worse, if you're using this one channel for the data transfer,
everything else waits on it.  I'll assume you would just use the text
parsing method for describing where to pull the data from or how to act on
given info, instead of providing the data itself. 

	Easier to write, and easy to abuse.

> 
> * The ability to display images is going to become a very big "plus" in
> creating an ambiance or environment.
> 
	Yes and no.  Good continual, seamless artwork makes for a very
nice environment.  Poor artwork is barely tolerable by today's standards.
Lack of continuity is the worst thing ever though, as it can be likened to
jerking a person from one extreme to another.  Yes, you can see this vase,
and the castle from far away on the hill, and maybe these three swords,
but the rest is just text.  Ruins people's attitude more than providing
nothing.

> * Security is a matter of degree. I wouldn't allow people to pass HTML
> tags to my CGIs in most circumstances, nor would I allow players to pass
> MXP tags to the MUD, in most circumstances. The amount that the client has
> to "trust" the server, IMHO, is extremely limited.
> 
	Of course, in a CGI, you're reciving a specific sort of data in a
specific listed style, be it post, form whatever data.  The problem is not
your server though.  We're not worried if our mud server can parse the
data to act on it.  We're worried that our clients have to.  If we return
to your HTML metaphor, you're expecting your client (the browser) to know
which data is valid or not, and all it has to go on is the data itself;

  Your client gets "<run_command>some_command</run_command>", and it's the
same whether someone caused that to appear on their screen, or the mud
'legally' delivered that piece of info to them.  In the end, you're giving
them a text string with no source identifier possible (cause it'd be text,
and that can be duplicated). 

	I don't want to bring up the OSI layer model, but it clealy shows
flaws in this case. You're taking data intended for the presentation layer
("Uniform means for a remote host to inform the local client how to
present the data, like HTML code") putting in the application layer
("Direct interface to the user, shielding them from all underlying
layers"), and then forcing the client to work backwards, from the app
layer, to the presentation layer, and then your client still has to deal
with the layer below that (session) to actually affect the changes
described in the presentation layer.

	There are well-argued reasons for keeping the layers as seperate
as possible, I'll assume you've read them.

> Maybe MXP isn't the right technology for expanding the technical
> capabilites of the current text-bound (IMHO, read: moribund) flavor of MUD
> codebases currently extant.
> 
	Who is it who said print is dead?  Granted, it may not bring in
the same size playerbase as the high-dollar commerical interests with
advertising, packaging, nice gui and multiple man-years of artwork, not to
mention a team of dedicated professional programmers, but last I checked
the number of text-only muds out there was still growing.  That means
there's more people on them (even if only one per mud) than before...
which says text still has a ways to go.  Until everyone who wants to run a
mud has the ability to plunk down and generate whole graphical worlds,
artowork, code and all, they'll stick to something they can do, like
editing text descriptions.

> What other technologies are there? Still open to suggestion. :)

	If you're going to go through the trouble of making a client for a
mud, don't bother with the added trouble of encapsulating information,
sending it to a client, forcing the client to decode it, and then act on
it.  Just open a seperate socket, and force the information down that. 
You want an immersive 3-D world, you're going to need to do this anyway,
since you can hardly have real-time reactions on a multiplayer system if
you're dependant upon parsing text messages sent via telnet.  That's just
nonsensical.

	The other large hurdle is that bit about poor artwork.  Art is
hard to produce, at least as hard as good code is.  Given the fact that
theres the added specialization of computerized 3-d modeling artwork (or
at least computer art), and it's just a bit harder.  Now, look at the
field you're now competing with; Everquest, or Ultima Online.. they have
upwards of 4 man years of artwork in them.  You can't hope to compete if
you're a non-commercial venture without a huge backer, or have years of
your life to fetter away just doing computer art day in and day out.

	Not that you can't do it, just that it'd be pointless.

	The road some people are taking is to use all that artwork and
whathave you that's bundled with the ultima/everquest clients and use that
to connect to their own scratch made servers.  In the end though, it's
someone limiting.  You still have to buy the client, and you're limited to
what the game you're emulating can show.  At best, you can be exactly like
them.  Chances are you'll be a bit worse, and not 100% compatiable.

					PjD




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