Just a bit of musing

[coder at ibm.net]

On 28/02/97 at 04:51 PM, "Carter T Shock" <ctso at umiacs.umd.edu> said:

>I think one of the common problems is viewing these as a dichotomy. Yer
>either on a TTY typing and reading, or you've got full blown
>texture-mapped baddies to blow up. Doesn't have to be that way.

Agreed.

>First off, I'm a _heavy_ proponent of clients. 

Partially agreed.  My favourite "client" for MUDding is still raw telnet. 
I don't like triggers, accellerators, scripting etc, and rather feel that
other's use of them detracts from the game (not counting the fact that I
feel that a game which can be so automated is fundamentally flawed).  

Outside of that about the only real point I'd argue vehemently agaist are
platform specific clients, whatever the excuse.  

>All of that junk that is
>sent as text these days could be compressed into short binary messages
>and allow for lots of customization in the process ("You OBLITERATE Ogg
>with your deadly flatulance" becomes a 2 or 4 byte header followed by a
>couple of bytes of state info.. how many points, who ya hit, etc). 

Hurm.  Raz I think talked extensively on Wout's list about externallising
the IO this way.  For a free programming MUD the problem quickly becomes
synchronising the client and server DB's -- especially when no strings or
string references are hard coded into the server anymore.  (Not to say it
can't be done, but it gets entertaining).

Consider the simple case of a newly user-programmed object which attaches
to a player to mutate the appearance (note: not the effect or result) all
incoming attack events in some manner (say relocating the apparently
damaged area, making the attack appear inefectual/very effectual, changing
the apparent attack weapon ("You are attacked with a wet noodle!") etc. 
JoeBloe user programmed this up a couple of hourse ago, and now your user
attaches and starts to play...

In-game IO filters and mutators get to be *real* fun when you seperate
them as you describe.  (NB I allow in-game objects to potentially trap,
redirect, filter, analyse, post- and pre-process all IO for other objects
such as players etc).

>The
>client becomes responsible for making text out of the binary spam. Now
>imagine a client that is primarily a text region for all the fancy
>descriptions, chat, hints, etc and has a small window where you show the
>player's orientation with the world using simple stick drawings. 

Cf Rogue/Larn/Hack.

--

J C Lawrence                               Internet: claw at null.net
----------(*)                              Internet: coder at ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...