[MUD-Dev] clients anyone?...

[Andrew Wilson]

Hi,

    there's been little talk about clients and how 
they integrate with servers.  I've seen a little about ansi colour
codes in text and Erik mentioned TWin's approach to building
windowing applications that interface with mud internals.  But
apart from that, um nothing...

I think this is odd, because I believe that clients are as important
as servers.  But then I would think that wouldn't I...

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.

Stuff like TWin, AstroVR, Jupiter, Supernova come from a desire
not so much to play games but to provide tools that let people do
work.  These are groupware applications with an integral realtime
communications aspect, more than just email.  Chat is common to
all of these though some also have video and audio capabilities.

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.

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.

For some examples of the applications you can build here are a
couple of gadgets I've been working on recently...

    I've got a crab (an NPC) at Waterpoint.  When you speak to him
    your message is passed, via a link through my connected client,
    to a PERL script sitting on my home UNIX machine.  The script
    performs an ELIZA transformation on the message and returns a
    reply which the crab then speaks.  Presto, talking crab.  When
    I'm not connected, and the link can't be made then the crab
    recovers by merely insulting the speaker.  The crab is grumpy
    you see.

    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.

    This was an exercise in adding to the server's capabilities by
    using external resources, without adding CPU intensive code to
    the server, and to examine ways in which the potential processing
    power of client software can be harnessed for the server.  Um,
    and hey, I already had the ELIZA script from CPAN and it seemed
    like a waste of time to recode it for MOO...

Navigating on muds is always tricky...

    I've looked a number of UI solutions to navigation on a MOO.
    MOO rooms are linked by exit objects which correspond to the
    cardinal directions (eg n,s,e,w,ne,...).  When a MOO's topology
    is constucted with a little bit of thought, no overlapping
    exits, then it's possible to interrogate the server and extract
    a data-structure representing the map of interconnected rooms.
    This structure can then be displayed in a number of ways, for
    example an overhead projection like a road-map.

    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.

    Buttons are all very well but they can obscure the nature of
    the place you inhabit.  What should be thought of as a virtual
    world topology containing people ends up resembing a glorified
    dialog-box.  There's a delicate balance in these things between
    utility, providing stuff that people need and can use, and
    transparency, stopping the UI from becoming more important than
    the content, your conversations.

    It's possible to improve on simple buttons and produce more
    visually interesting interfaces which still retain a degree of
    simplicity.

    We can take the grid blueprint for buttons and imagine it
    superimposed on a terrain map.  We can add a perspective look
    to the map, to make it look more like scenes we see every day.
    We can use visual cues to indicate the navigable areas on the
    map.  And we can also make use of additional 'WHO' information
    to represent the other occupants of the MOO.  Groups of people
    are represented by small face icons, and the names of room
    occupants are displayed on a small adjacent surface.

Some URLs...

    The client home page:
    http://www.cm.cf.ac.uk/User/Andrew.Wilson/tkMOO-light/

    Waterpoint's homepage, it's a JHCore derived MOO:
    http://waterpoint.moo.mud.org/

    Some notes on developing the navigation widgets:
    http://www.cm.cf.ac.uk/User/Andrew.Wilson/rose_who/

    Screen shot of the finished perspective look:
    http://www.cm.cf.ac.uk/User/Andrew.Wilson/visual/

    Messages to and from the crab and the delivery of mud topology
    data are all handled by the MCP/2.1 Out Of Band Protocol:
    http://www.moo.mud.org/mcp2/

Oh well, back to sleep for another few months...

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