[MUD-Dev] Re: mud client development systems

Chris Gray cg at ami-cg.GraySage.Edmonton.AB.CA
Sun Dec 6 21:57:29 CET 1998


[Sunny Gulati:]

 >1. I want to build a world where the players take part in the economy
 >   and law of the world, where socializing is looked towards. [that's
 >   a whole 'nuther topic, and doesn't require dream #2 to be
 >   implemented first]

Been lots of discussion about that. No real conclusion, other than
"it would be good, but hard to do well".

 >3. I want to publish a framework/API/convention that makes it easy for
 >   OTHER people to build a client/server/mudlib combination, to make
 >   ultima-online type of worlds.  Make it open source :), see where
 >   the world takes it.

Sounds like DevMUD could fit that bill.

 >** Everything still depends on "telnetting" into a mud just as we do
 >nowadays.  I want to layer the client/server connections on top of
 >telnet.

I'm quite curious as to why you want to put stuff on top of telnet. Since
you are requiring a custom client anyway, why not use a custom binary
protocol of some kind? That cuts down on your communication, and avoids
altogether the problems of accidental interpretation.

 >I would like this system to be runnable over a 14.4 or 28.8 link.
 >Actually, i have my mom's laptop - its a 486/25 running win95.  If I
 >can get the client written in Perl/Tk, get it running on there,
 >connected to the mud via PPP on a nullmodem cable running at 19200 and 
 >it seems to work well, then I'll say i've designed a good system.

Should be doable. My AmigaMUD system uses a binary protocol to the custom
client, and it is actually playable over a 1200 bps link. At 9600 bps,
it responds very little different than a local connection.

 >** SERVER->CLIENT: "hey I want a connection to your object xyz,
 >   instance foom, and my socket id is 8192".  (different socket number
 >   for every connection)

Beware of running out of sockets in the server process!

 >0. Is there any previous work on this?  I've only been on this list
 >   for about 2 months now.  I've tried going through the archives..
 >   there's a LOT of stuff out there.  One of these days I'll just
 >   download all the .tar.gz's and less and grep through them. (JCL,
 >   I could not get the "search" function to work well.. it
 >   never returned on me.  waited about 5-10 minutes.)

A bit of what you are asking about was done in a primitive fashion in
my old AmigaMUD. Hopefully more will be done in a newer version. But,
that comes after some DevMUD fiddling, and some byte-code testing, and
writing a whole new client.......

 >7. Looking like this would involve a bunch of short packets.  I'm not sure 
 >   what the effect is of various packet sizes regarding congestion and stuff.
 >   Maybe some sort of buffering is in order; bundling several individual 
 >   messages into one ~...<CR> and MCSL...<CR> pair?   How much of a difference
 >   would this make?  Maybe the layers can be designed so that actual 
 >   interpretation of a ~message<CR> allows for decoding of an array of messages
 >   (though initial implementation, only one message is returned).

I can't think of any reason *not* to buffer things up. What I did was
to keep buffering until either my buffer was full or the output got
directed to a different client. A better approach would have buffers for
all clients. Then, you only force-flush them at the end of the top-level
event which caused all the activity. That would be something like a
command entered by a user, or a complete action step by an NPC.

--
Don't design inefficiency in - it'll happen in the implementation. - me

Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA




More information about the mud-dev-archive mailing list