[MUD-Dev] client UI written in server's language (was Re: Some thoughts...)

[Erik Ostrom]

Hi.  I'm pretty new to the list, and perhaps I haven't lurked long
enough, but I had to respond to the following paragraph before it got
away.  By way of introduction, I'm the current maintainer of the
LambdaMOO server (the software, not the site); I started using MUDs in
1990; my experience is largely in MOO and mostly in 'social' MUDs, but
I've spent some time on roleplaying/gaming MUDs as well as working on
'serious' MUDs (i.e., for work or for education).  Oh, and I played
the UO beta.

On Mon, 4 May 1998, Adam Wiggins <adam at angel.com> wrote:
> It seems that this would be a natural place to actually write the client's
> interface itself in mud-language plus a few commands to pop up different
> sorts of widgets, along the lines of tk/tcl perhaps.  I did something like
> this on my last commercial project.  The game's map editor began as a
> simple console where I could type commands and edit scripts (which were
> similar to shell scripts - the regular list of commands for interacting
> with the game map, plus a few conditionals/loops etc).  When everyone but
> me started whining for a mouse interface I coded up some simple slider,
> dialog, and button types that could have an attached script.  Thus it was
> pretty easy to do favorites buttons, or bookmark holders, or whatever,
> since each script could have its own local variables and such.

As part of a research project here at AT&T Labs, I've been working on
something very similar to this*.  We're planning to make a public
release of the software (free for non-commercial purposes, with
grant-backs to AT&T) very soon, and I'll post about it here if that's
appropriate.  Meanwhile, anyone who's interested in getting an advance
look at it should contact me (although I can't promise anything).
I'll now describe the system so you can tell if you're interested.

The core of our system (called TWin, for obscure reasons) consists of
three pieces:

  * a language for describing GUI layout
  * a set of standard widgets (buttons, text areas, labels, etc)
  * a protocol for communicating high-level events about the interface
    (e.g., "button was invoked", not "mouse moved to (512, 113)")

A client merely implements facilities to display these widgets and
pass user interaction events to the server; it knows nothing about
application logic (e.g., what a MUD is--although we do provide one
exception in our client).  What this means is that you can program
simple GUIs entirely on the server side, in whatever language the
server speaks.  This has been used already to implement things from
tic-tac-toe to pop-up notes to code browsers to a complex social MUD
(navigable through the UI, and with buddy lists and command help and
so on).  We expect to see a lot more range once we go public.

The protocol and our server-side API provide for sharing of state
between the server and multiple clients, so everything is potentially
shared--i.e., just as anyone can read a note sitting on the ground in
a text-based MUD, anyone can pop up a window to read the note in TWin,
and in fact one person can read the note while another is writing it,
and get updates as the text changes.  This makes the implementation of
much multi-user stuff pretty simple, since programs are written in
terms of getting and setting state on a single server-side object--the
application programmer doesn't have to worry about what messages are
sent around to keep the clients in sync.  (Clients of course can't be
kept perfectly in sync, but I'm not going to go into more detail
here.)

The current system is written in Java** (the client) and MOO*** (the
server, of course).  The protocol, though, is largely platform-
independent, so we expect servers could be written in any sufficiently
powerful MUD language, as well as ordinary programming languages like
Java and C++, and they would interoperate with the existing Java
client.  (Likewise, new clients could be written and work with any
conforming server.)

>I can easily imagine hackers going in to modify the client's functionality
>however they liked in order to get the interface just right for what they
>do.  Of course, maybe this isn't a good thing if it makes 'botting' too
>easy, something that having a custom client is sometimes useful to avoid.

I suppose the openness of our protocol does make us extremely
susceptible to 'botting'.  We've been thinking primarily about social
and 'serious' uses of the system, rather than games.  It occurs to me
that you could make a 'custom' client that still uses TWin--reuse all
the code from a stock client and server, but add an authentication
sequence that ensures to a first approximation that the client hasn't
been tampered with.  Anyway, a subject for further study.

Further info is available at <URL:http://tchat.research.att.com/>.
Also, TWin is built on MCP, an underlying message protocol that is
friendly to line-based MUD servers, which is documented at
<URL:http://www.moo.mud.org/mcp/>.

--Erik Ostrom
  eostrom at acm.org

* It's also very similar to the windowing aspects of the Jupiter
system developed at Xerox PARC.

** WRT a recent thread on this list: Our client was developed primarily
as an application under JDK 1.1; currently it does not run as an
applet except under Sun's 'Java Plug-In'.  We _also_ distribute it
as a standalone Windows program, so people on Windows don't have to
download the JDK.

*** WRT another recent thread, our TWin server is built on top of
JHCore, a core database (mudlib), so people can use existing MUD
functionality from that and don't have to build from scratch.  It's
also possible to build TWin-based systems that don't look anything
like JHCore.

--
MUD-Dev: Advancing an unrealised future.