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

[Andrew Wilson]

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.

Mmm.  The data needed to support tile-based graphics, most likely
event updates with x,y,z,type records, is going to be pretty
different to the text content people might read in conversations.

In MCP terminlology you'd be looking at a pair of packages, one
for text messages, another for coordinate world updates.  The client
could render text in the output window, or overlayed on the 3d
scene, or in speechbubbles a-la palace.  Coordinate updates might
be handled by a different package, one which new about where you
were in relation to the disclosed event and how to render it on
the scene.  Plain text clients can chose to not support the
coordinates package.

[basic client outline, snipped]

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

Sounds familiar...

> > 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?

MCP specifies a negotiation phase which begins immediately after
the initial connection.  Both client and server send a list of
their capabilities as package,version records and work out the
overlapping capabilities according to a simple algorithm.  Thereafter
both parties know precisely what they can and can't talk about.
If the server says it can handle a package that the client can't
support then after the negotiation phase has ended it'll know the
client's limitations and so need not bother using that package.

The basic MCP spec details fundamental packages, and the messages
they support.  Stuff like the initial connection's "we speak MCP
here, how about you?" and the subsequent negoiation phase "cool,
here's a list of other packages I know about".

It's not magic.  It does work flawlessly however, which is almost
as good.

[talking crabs, NPCs powered by client-side code]

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

There are a couple of concepts scuttling around here.  Bots, that
is externally scripted NPC logic.  Distributed processing, or at
least RPC, which allows a client to offer a useful service to the
server and to other people using that server.  You don't *really*
need a chat client to do do either of these things of course.

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

Chatterbots recently emerged as a new tool for augmenting websites.
Providing a warmer and more natural interface to tricky stuff like
FAQ presentations and simple user support queries.  These techniques
are probably worthy of more attention by those who wish to make
their web/chat sites more attractive and engrossing.

Simon Laven has a good rundown on the state of the art.  Shallow
Red of 'Neurostudio Chatterbots' is a nice demo:

    http://www.toptown.com/hp/sjlaven/

I don't profess to any greater knowledge than this however.  I just
thought ELIZA was cute and wondered how to make use of it.
Technically it's kindergarten technology, but more than a match for me.

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

That's interesting, I'll have to hunt for the Inform/Hugo stuff.
There's certainly a limit on what topologies you can represent with
a simplified interface.  For office floor layouts, or room based
representations of real spaces it's bearable though.  If you want
to display the linkage from the magic-mirror to the land of the
little elves then you probably want to use some other tool.

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

Cheers,
Ay.

Andrew.Wilson at cm.cf.ac.uk http://www.cm.cf.ac.uk/User/Andrew.Wilson/
Voice/Fax: +44 (0) 1865 513 091