Clients

[Matt Chatterley]

I have a sneaking suspicion that this is a kick-start of an old thread,
but I don't really recall. There has certainly been some debate about
clients, and it seems quite interesting to bring up.

I'm raising this in a specific context: Over the next few months I will be
creating a mud client to run as a Java application, with switchable
operation modes (gui/non-gui for unix cli), with the intent that players
on my mud will use it in preference to others.

While I may not exclusively require use of this client (then again, I
might!), I will be adding features in it via its own client<->server
communication protocol which will allow a greater degree of integration
between the mud and the client.

Java was my choice of language for three real reasons - firstly I have
been intending to launch a serious project in it as a learning exercise,
secondly it allows me to cover all the main platforms in one foul sweep (I
believe that windows, mac and popular unixes all have JREs now, and others
are accumulating) and thirdly I wish to potentially apply a quite modular
design (for instance a client 'core' and optional tool-kits).

Although initially intended as a custom client, I figured that I could
fairly easily add a run-time option to enable or disable the special
protocol features (and even mask this from the user) so the client would
behave normally when used on a 'non-compliant' mud (and would simply obey
the telnet protocol to the degree that the mud required). Incidentally I
also quite like the idea of implementing some pueblo-like features (or
pueblo-compliance) but have no idea where this would stand on legal
grounds.

This leaves me with two main topics of conversation - client features and
protocol features.

I think the most popular client features which people have described to me
are an easy to view command line for entering commands (with no limit on
length of lines), and a command history as well as a 'scroll back' of
sorts (aka tf's /recall).

The ability to make log files of events, connect to multiple worlds
simultaneously and macros are also popular.

I'm interesting in hearing not only which software you folks use, but also
*why you use it* - what does the software have that you like? What is
missing? Personally I use tf since it is straightforward to use and has a
nice, uncluttered display (something I will strive to recreate!).

On the protocol side, one thing in my mind is to allow my mud to
communicate its menus (currently done using the input_to() features of
MudOS/LPC) to the client so that they appear in 'pop-up' windows which are
clickable, and easy control of features, such as a 'spell selection
window' for using special skills and magic, but again, considering this in
a general fashion is harder:

I thought about menus and decided that they and the other windows to make
decisions or selections could be handled via an extension of the macro
module to create 'choice windows' which communicate the choice made and
the menu or list from which it was made to the server, allowing it to act
appropriately.

This should also allow the server to tell the client to open a window and
display picture or information (perhaps using an HTML parser, although
that is veering into a rather more extensive project than I wish, so
perhaps just launching the configured browser or other helper
application - with this theory sounds and such can easily be integrated).

Also a simple information communication system so that screens such as
'score' and 'stats' which are popular names for similar things on many
games can be permanently displayed or toggled (dynamically updated via
communication from the server to the client), perhaps on an 'information
window' which works as a 'pinboard' allowing iconisation of each window
and such.

I'll stop here as I'm beginning to get confus(ed/ing), and throw this
issue specifically and its implications generally open to your thoughts.

Regards,
	-Matt Chatterley
	ICQ: 5580107
"We can recode it; we have the technology."