Just a bit of musing

[S001GMU at nova.wright.edu]

>Along the lines of a graphical mud and clients...
>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.

>First off, I'm a _heavy_ proponent of clients. 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). 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. Things that move
>can be sent as binary locations and things that don't move can be
>sent/cached by the client as a map. If you want the texture-mapped
>run-around, play Quake (which, of course, I do :)  There's no reason that
>the player's "view" can't be abstract. Make it a 2-D bird's-eye view (red
>dots are mobs, blue dots are players, white squares are buildings,
>whatever). The possibilities are really endless and not necessarily
>complex. Now we stay sort of "open" because we can use arrow keys to move
>around (out in the open an arrow might mean "head towards" while inside it
>might mean "depart thru this exit"). 

>It all depends on how "real" you want it.

amen brother!  preach on!  :)

actually, what you suggested sounds frighteningly similar (ohmygosh!  other ppl
thought up the same idea????  *grin*) to what I did for my undergrad honors
thesis (a mud of course! :).  I just compressed everything into codes that are
passed around and then interpreted at either end.  the real problem with this
system is (as was pointed out nicely by one of the guys on this list) it
requires foreknowledge of everything that can possibly be sent across by all
porcesses.  Granted, there are several ways that immediately pop to mind to
get around the problem.  The 'easiest' is to build all descriptions/images
from a set of primatives.  Instead of sending the entire list of primatives
across every time, create macros so you can send 'The huge, black sword of
enemy killing" as just obj description macro #27 or something.  When something
new comes along, just send the entire primative list once and assign a macro
to it and from then on, just pass the macro around.  Adding a new primative
can lead to problems, but there is always a level at which things break down.
;)

FYI, the project I mentioned above was aimed mainly at building a mud that
could have different types of clients (text based, graphics based, whatever)
running at the same time and interacting transparently.  Rather an ambitious
project for a 3 quarter project (count most of 1 quarter for the project
presentation/paper preperation!).  needless to say, most of the ideas
are still quite un-coded.  ;)   gives me something to work on when my two
programming jobs and various CS classes just aren't enough work.  ;)

the main goal was that if someone felt like it, they could build whatever kind
of user interface they wanted to run and have it connect to and interact
seamlessly with the game mechanics at the same time as other people using
"stock" clients. 

-Greg