[MUD-Dev] Re: mud client development systems
cg at ami-cg.GraySage.Edmonton.AB.CA
Sun Dec 6 21:57:29 New Zealand Daylight Time 1998
>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
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