[MUD-Dev] Clients

[Nathan F Yospe]

On Tue, 17 Feb 1998, Katrina McClelan wrote:

Hi, Kat!

:On Tue, 17 Feb 1998, Travis Casey wrote:

:> Why?  I mud from a variety of locations, and don't want to get used to
:> using an interface that I won't always be able to have.  If that
:> interface can only be used on some muds, I'd be even less likely to
:> want to use it.

:That's one of my problems in general with clients and the issue of telnet
:is bad.  I'll be the first to agree that telnet is a very silly protocol. 
:However, it's supported on almost any platform without extra downloads or
:such.  The solution I'd eventually use, and that I have mostly implemented
:is a [psuedo] terminal server, terminfo, and lib curses.  Yes, curses CAN
:be used on multiple "terminals" from within the same program.  I actually
:have the starts of a nethack like game over telnet for multiple players. 
:I got bored with the whole thing (mostly because the game system was
:stupid; the project was more a matter of getting menus to work over telnet
:sockets than it was to have a good game), so I didn't finish it, but you
:could log in and go through a character creation sequence that was all
:menu driven.  I suppose that curses limits features to text, but with full
:screen manipulation of it, it's still quite versitile.  Particularly if
:you use ncurses and expect (partually dangerous) the the receiving client
:supports colors in some way or another (doesn't have to be vt100 with
:ncurses).  The only real downside to this is character mode is required,
:and that sometimes locally handling text requires that you retransmit it.
:But if you're considering web based clients, character mode isn't THAT bad
::)

The real question is, do you want to support the client as well as the
server? There are a lot of "telnet" clients out there. Most suck. Most
players, now, are unfortunately servents of the Borg, and the MStelnet
is one of the worst. There are also a number of mud clients that don't
follow any sort of standard, and tend to cater to one of the big three
bases. So the options remain: Take your chances with telnet; Write the
client for M$ (and possibly a few other OS's); Write the client in the
form of a web extension; Write the client as a Java application... the
advantages and disadvantages of each are: Telnet really isn't that hot
a client; M$ is evil (and besides, there _are_ other OSs, and portable
code isn't as easy as it sounds); web extensions tend to bring in that
unspeakable element, and are slow to boot (even java applets); Java is
not the most stable or efficient language at the moment. As for what I
advocate... I chose the last option. I'm hoping Java1.1.x remains more
or less viable for a while to come, and counting on JITs and native or
optimizing recompilers, chunks of bottleneck code written in native on
the big three or so platforms (Solaris, MacPPC, PPC, and x86), and the
(hopeful) raw power of users' computers. I'm also releasing a hostable
version that runs in a unix csh, so that users can run it on accounts,
and thus get pretty close to the effect of a VT100 telnet interface. I
also have started working on a system for storing a datafile in a form
that is platform neutral, to be stored on a remote access account like
a .newsrc, allowing a player to run different copies of the client and
different machines at different locations with the same account setups
and the same characters. The problem is, this datafile is the core for
the neural net, and gets rather large. I anticipate sizes over 4MB, or
possibly larger... I'm hoping to find a way to store it by dated entry
modification files... The advantages to supporting a client is that it
becomes the repository for oft-repeated player by player computations,
data, and even communication, (I'm working on distributed hosting, and
the idea of interplayer message-only communication nodes appeals to my
sense of elegance in design, as does DCClike linkage between any pair,
or possibly even trio, of clients.) ... it can handle any protocol you
might need it to, (I'm creating my own data service protocols for both
alternate media (graphics and sound) and database updates (new regions
and materials, new behavior patterns, new models).) ... and it gives a
player the option of game related persistance beyond simple macros. If
I were to state one primary reason for supporting a client, however, I
would point to the massive text parsing effort of just about every mud
codebase I have seen. LP, Diku, Tiny*, or Cold, all use more cycles on
text parsing than anything else (OK, maybe not always, but generally.)
and none of them really even do anything fantastic with it. Now, where
I branched off was the generated text... and this almost demands a new
approach. What are the disadvantages to clients? Clients are not safe,
tucked away on the server. They can be hacked. They can be made to put
a programmer at an advantage in the game, if too much resides in them.
I really don't much care, as I see any hacking for smarter response as
advanced macro construction. ;) I don't have a typical mud, though, so
my lack of worry may be more a reflection of a mistaken belief in this
bulletproof solution to simulation. I don't think there is any data in
my model that can be recognized enough to be tweaked by a player for a
favorable balance through hacking, and not by any other means. The big
risk of a client, in my opinion, is that it tends to limit the changes
to the server, if not designed intentionally to maximum flexability. I
am extremely aware of this problem, and quite vulnerable. I expect the
client to be upgraded as often as the server, and only the datafile to
be secure, and even that not during the first couple of testing years.
--

Nathan F. Yospe - Aimed High, Crashed Hard, In the Hanger, Back Flying Soon
Jr Software Engineer, Textron Systems Division (On loan to Rocketdyne Tech)
(Temporarily on Hold) Physics student, University of Hawaii dept of Physics
yospe#hawaii.edu nyospe#premeir.mhpcc.af.mil http://www2.hawaii.edu/~yospe/