[MUD-Dev] Re: clients anyone?...

[Andrew Wilson]

Adam J. Thornton:
> Cool.  This is stuff that I will be addressing once I get my server design
> sort of working.  One thing I'm working towards is a communications
> protocol that lets the client negotiate the options it supports, so that
> low-bandwidth clients can say "don't choke me with lots of expensive tile
> data, since this is an 8-bit display" or "I can't handle music so don't
> bother sending it."
> 
> Weirdly, the protocol I've been slowly creating looks a lot like NNTP.
> 
> In an ideal world, I'd support everything from a text-based Pilot interface
> to 32-bit high-resolution tons-of-tiles lots-of-sounds-and-music interface,
> based on what the client could support.  Dunno how flexible I will end up
> being.

The MCP protocol sends messages in plaintext.  It was developed on
MOO systems which are 7-bit places.  A few unicoded 8bit places
exist for kanji and cyrillic text, but they're rare.  But anyway,
the protocol itself assumes only 7-bit messages.  So this means
that you can't send raw binary over MCP unless you base64 encode
it.

If you wanted to send gazillion megabyte images from server to
client then MCP would be useful to send a message like:

	#$#image url: "http://xxxx/foo.gif"

Meaning, "here's a reference to an image, go get it".  Of course
a client containing some HTTP logic would grab the GIF from the
given webserver.  The point being that you wouldn't think of sending
large images or audio over MCP.

MCP's logic is pretty simple.  The protocol doesn't demand a VM or
anything fancy, it's really an agreed way to encode and decode
lines of text.  I've got a complete MCP parser/encoder in 500 or
so lines of TCL including the package negotiation logic, and I took
no special care to keep it small.  I'm not aware of any publically
available MCP libraries in C++, though a couple of different Java
implementations are being used successfully.

Pilot would be a nice platform to get this running on.  That
processor has more than enough juice to handle the extra load of
MCP messages combined with the normal flow of text.  If the thing
can run ICQ (as was recently announced) then it'll have no problems
MCP.

All said and done, MCP is just a way to shovel data from one end
of the wire to the other.  You *can* keep all your game/presentation
logic in the server and use plain text to control it but if you're
interested in making more of the client (consider every one of your
users running a P200 that is 99% idle...) then a technique that is
sensitive to different clients' capabilities (MCP's negotiation
phase) is a godsend.

I wouldn't last too long on a Pilot RPG though:

    The mighty troll slashes you with the rusty blade.
    [pen down, up, right, up, down (command not recognised)]
    The mighty troll leaps high and stomps donw on your head.
    [pen down, left, up, right, down (command not recognised)]
    The mighty troll grabs your arm and swings you into the tree.
    [pen down, up, down, left, up (command not recognised)]
    You die!  The troll eats your leg.
    [pilot dropped on floor, stamp, stamp, stamp, *crack*, go out
    for pizza...]

> Adam

Cheers,
Ay.

Andrew.Wilson at cm.cf.ac.uk http://www.cm.cf.ac.uk/User/Andrew.Wilson/
Voice/Fax: +44 (0) 1865 513 091