[MUD-Dev] Re: clients anyone?...

[Adam J. Thornton]

On Tue, Aug 11, 1998 at 07:06:44PM +0100, Andrew Wilson wrote:
> Tile based projects like UO and Furcadia and emerging RPG+Quake
> stuff represent one facet of client technology, funky pictures and
> a gaming feel with the graphics being the prime purpose of the
> exercise.

Ah, but it should, at least in theory, be possible to separate the client
data stream protocol model from how the client wants to represent that
data, so the same protocol could support a line-based MUD client or a
UO-style tiled interface.  3D would be a lot harder but not necessarily
impossible.  Impossible with finite bandwidth, maybe.

> My own interests centre around the development of UIs for MOO
> servers.  That is, line-mode, low bandwidth social environments
> with a room-based topology.  Sure you can build excellent RPG
> engines from this configuration, but I'm not interested in that.
> 
> I'm developing a range of products (for want of a better term), on
> the border between groupware and games, firstly there's a
> 'theme-neutral' chat client called tkMOO-light.  Theme-neutral
> means that it's not *obviously* biased towards a gaming environment
> or a particular mode of interraction or say, point&click navigation.
> The client can be the basis for developing stuff for any chat
> environment but right now it's happiest when used in conjunction
> with line-mode text sites like MOO, Cold etc.

Cool.  This is stuff that I will be addressing once I get my server design
sort of working.  One thing I'm working towards is a communications
protocol that lets the client negotiate the options it supports, so that
low-bandwidth clients can say "don't choke me with lots of expensive tile
data, since this is an 8-bit display" or "I can't handle music so don't
bother sending it."

Weirdly, the protocol I've been slowly creating looks a lot like NNTP.

In an ideal world, I'd support everything from a text-based Pilot interface
to 32-bit high-resolution tons-of-tiles lots-of-sounds-and-music interface,
based on what the client could support.  Dunno how flexible I will end up
being.

> Secondly the client can be extended with plugins which add new
> capabilities, navigation windows, desktop metaphores and other
> visible extensions.  Plugins can also be used to integrate with
> underlying OS services, like email, webbrowsers or other network
> demons.

Is this a matter of knowing which extensions a client and server may
support and having a framework by which new extensions can be added without
breaking anything?  If either end wants some protocol extension that the
other end can't handle, they just quietly agree not to use it, but as you
add new extensions, you register them somewhere and if the server is
similarly enabled, it just magically works?

>     All this happens without my being interrupted by the flow of
>     information from crab to ELIZA.  I don't see the messages, and
>     I don't need to be in the same room as the crab when people
>     speak to him.

Nice!  This sounds like a good way to implement relatively simple
scriptable NPCs, actually: if they just have their own client, can parse
the incoming data, and respond appropriately then I don't have to build it
explicitly into my server or my database model; I can just create an NPC
object and let its client script handle its responses.  (Phil Goetz had a
great model for low-budget interaction on rec.arts.int-fiction several
months ago: Artificial Stupidity.  Basically, it's Eliza except that there
are a few things each character knows about, and it operates under the
assumptions that a) it is the center of the universe, and you have to be
talking about *it* and b) everyone else is in cahoots against it, and c)
everything has to do with one of the things it knows about.  You end up
with something that behaves as if it were from New Jersey.)

>     The same structure can display useful navigational hints.  For
>     any room on the map you can display a set of buttons corresponding
>     to the exits out of the room.  The result resembles the cardinal
>     points dotted around the edge of a compass.  Clicking on a
>     button moves you the direction of that button and into an
>     adjoining room.  At the same time the set of buttons can be
>     updated to represent the exits leading from the new location.

Until you _do_ want complexly-connected maps.  At which point things get
ugly.  Doing the compass rose problem has been addressed several times on
rec.arts.int-fiction, and there are some neat Inform and Hugo libraries
that address navigation and automapping on ftp.gmd.de under /if-archive.

Adam
--
adam at princeton.edu 
"There's a border to somewhere waiting, and a tank full of time." - J. Steinman