Just a bit of musing

[Nathan Yospe]

On Sun, 2 Mar 1997 coder at ibm.net wrote:

: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.

Very enthusiasticly agreed. There are many ways around this... even my
text mud has potential for inlined graphics with an active client, and
without it, there is still the option of using a fully enabled client.
Anything that supports pine/pico/gopher etc. will at least benefit from
traversable menus, multipart windows, and several other similar features.
As for a gmud, it hardly needs to be socially deficient... code it right,
and a keyboard is fine for interfacing. A command window has a lot of
potential, even w/ texmapped graphics.

:>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).  

Clients are more important for gmuds. *grin*

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

Hmmm. You suggest instead that everything be Java? I hate to be abrubt,
but for a gmud, the most you can expect to support is X-Windows, Win32,
and MacOS. With the exception of AmigaMUD (Hi, C.G.) the majority have,
admittedly, been Win32 exclusive. I'm working on one that runs the above
three, with seperate clients, but right now, its the server I'm designing.
With text muds, of course, there is no excuse for platform specificity.

:>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).

Of course, the free programming issue does complicate things. I had been
thinking about impulse passing, with a massive array of strings at the
highest level of the IO being pulled for impulses, thus allowing possible
d/l and impulse passing to the client... even further extension leads to
clients that display this graphic instead of this text, etc... I decided
to skip, however, because of the increasing complexity of my concept
containment. This was never inteded to be that sort fo MUD, and if anyone
ever wants to make it such a MUD, they could pair impulses with the passed
String references.

: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...

Possibly impulse substitution could solve this... I can think of a few
ways.

: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).

That was the reason I abandoned impulse passing... I have the same... but
I still wonder if impulses couldn't be screened in the same manner? Or
the impulses might be dereffed by such a situation.

:>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. 

That part could be done by a sophisticated telnet compatible program. Done
it. But... there is so much more that could be done by such a system. I
mentioned my gmud project before... it is based entirely on passing binary
impulses and bytecoded prototypes (frames), states, and methods. Of
course, a method is much harder to program than a standard mud object, and
a frame is a geometric def of an object, with inlined physical state
constants, flex points, movement patterns, skin textures... The irony is,
with all of this, we will be designing a text interface to be run off of a
UNIX machine, into a telnet session. You see the advantages....

:Cf Rogue/Larn/Hack.

Huh?

   __    _   __  _   _   ,  ,  , ,  
  /_  / / ) /_  /_) / ) /| /| / /\            First Light of a Nova Dawn
 /   / / \ /_  /_) / \ /-|/ |/ /_/            Final Night of a World Gone
Nathan F. Yospe - University of Hawaii Dept of Physics - yospe at hawaii.edu