Re: Circle's net protocol

From: Blue Lang (blue@CALICO.GATOR.NET)
Date: 11/10/97

> presented solution.  In the case of a MUD, this won't work, because we
> can't expect people to download up-to-date data and binaries for the
> MUD everytime we change a feature or an area.  So, it's something like
> comparing apples and oranges.

Why not? What if it made the mud a lot more fun to play? There are enough
non-OS specific GUI libraries out there that a simple, portable interface
could be written fairly quickly.

Couldn't you (if you were a complete nutcase) have the client send data on
a second port, so that you'd still get the text data, but if you had the
client be able to get extra info as well? I dunno what good this would do
you in a hack and slash mud, (REALLY nice 3d hp/mana/mv bar graphs :) ),
but suppose you were playing that Mechwarrior MUD I keep seeing bandied
about. You'd need to keep track of enough different information at once
that a REALLY large prompt or conatantly typing 'sco' would be your only

With a client  loaded on client machines, the data requirements coming
from the mud suddenly drop drastically, and you could have some sort of
rudimentary graphics capability, even if it were just a few different
looking panels, ala Might and Magic I. Mobs and Obs could be represented
with just a few bytes of data, there's no position data (well, flying,
maybe) to really deal with (in the room).

Actually, just keeping the room data and text damage strings on client
machines would greatly reduce the amount of information sent out. Imagine,
every time you type 'look', it's instant!

I dunno.. this whole thing is something I've been kicking around in my
head for a few weeks.. I've seen a well-written unix ANSI mud, and it was
quite a bit of fun.

Of course, I _totally_ realize that the original thread was talking about
a non-client-based UDP mud, which I'm not so sure about, but I don't see
Client-Based Circle as so inconceivable an idea..


     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     | |

This archive was generated by hypermail 2b30 : 12/08/00 PST