[MUD-Dev] A new MUD-standard

Kwon Ekstrom justice at softhome.net
Fri Feb 23 02:33:30 CET 2001


I've decided to write up a list of things that I'd like to see a new
standard to do, more detailed than the summary I posted earlier after
J C Lawrence's suggestion of a detailed report.  This won't be as
detailed as is likely to be needed, but it'll give a fair
approximation of what I think should be necessary.

The transport layer must be a 2 way connection which may or may not
support compression.  The protocol should allow multiple ways for data
to be passed between the server and client.  A client-side
presentation layer must support precise control over how input is
displayed.  It should allow, but not require multible areas to post
data to.  It should support at least 16bit color, 16 color ansi is
getting rather outdated.  It should allow data to be grouped in the
form of tables or lists.  The protocol should be easy to learn, and
use.  Bandwidth should be kept to minimum usage.

Now, this is still a very general list, the majority of the concerns
are with presentation, imho telnet is a wonderful connection to handle
text based games, although compression would be nice (MCP???) to save
bandwidth.  Now, here's how I'd use NWLayout for this new standard...

It's hardly fair to consider this a "new protocol" but a stack of
existing protocols...

Consider this model:

  transport layer: telnet
  interface layer: XML
  presentation layer: HTML+CSS???XSL-T???

The transport layer can be anyting you want it to be, including a
custom layer... My new codebase is being developed in Java, and I had
originally thought of passing java objects, but I think that would
limit it's potential in the long run.  telnet as I said would work
well for that, since it's a very low bandwidth versitile protocol.

XML is suited fine for an interface layer because XML allows you to
define data, likely a DTD or XML schema would be used to lower a
learning curve.

The model uses 100% existing and proven technologies, and supports an
almost infinite amount of option combinations to a creative developer.
The learning curve is low because these are all common standards and
several sites are already dedicated to helping people learn them,
including several books, and a large number of people already know
these technologies.

As for bandwidth, it's higher than just standard telnet, but that's to
be expected if you're defining the formatting on the fly.  But when I
can visit web pages with over 200 words on them in less than a second
using Mozilla Seamonkey 0.8 (it has a timer that shows you to the
millisecond how long it takes to download and display a web page) that
is hardly an issue.

I admit that this lends alot more power than is needed, but I'm lazy,
this is less work than defining my own specification, it yields
quicker results, and should have acceptable response times.  Naturally
for graphical systems it would be a poor protocol, but for the average
mud home-brewed mud, it's an acceptable arrangement.

I'd write a more detailed list of presentation needs, but I'd most
likely end up copying the w3c specification for cascading style
sheets, those alone provide enough power for a mud (Hrmm, XML with CSS
for a presentation layer?)

Naturally, I'm biased since I work a great deal with web technologies
IRL, but how long does it take to download a web page?  And remember
that with mud's you're receiving the data in smaller packets, instead
of a 20 page report at once you're getting maybe a page at a
time... unless you're playing GZ and someone drops napalm on the depot
you're sitting in... um, but that's a different story... heh.

Anyway, feel free to comment, poke holes in my thoughts, ideas, help
me refine it so it's perfect when I actually get around to it (come to
think of it, I have written a client in java that uses a swing text
area I could adapt to support html 3 for testing with).

-- Kwon Ekstrom

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



More information about the mud-dev-archive mailing list