[MUD-Dev] HTML as a MUD client . . . was RE: [MUD-Dev] javascript

[John Bertoglio]

> -----Original Message-----

On using HTML/HTTP for a MUD client: This THE way to reach a mass market (or
even a niche within the mass market). Our company (barely) survived the
transition from dialup and telnet-based systems to the web. The notion of
universal client (the web browser) installed with every OS meant as
designers we could concentrate on content and not have to worry about having
to install a client program on user machines. Mature BBS environments had
much more power and flexibility than the early web. But they died because of
the need to mask the arcane Telnet interface with a sophisticated client
program. People did not care about the power. They liked the web The web
browsers got better and better.

While basic HTML is not as rich an environment for client building as
Delphi, PowerBuilder or VB, everyone understands it. The only real advantage
a custom client offers is the potential for a somewhat higher control
density as HTML tends to render things a bit loose. But with careful design
a very credible interface can be fielded. We had a fully functional MUD
running in an web browser with a X-Base back end some time ago. (It's in the
archives). It did some things much better than a standard telnet mud because
the ability to use buttons, drop down boxes and other elements allowed for a
large number of transactions per client send. Inventory management, mapping,
displaying exits were all much easier for the designer and the user. This is
not because of our skill as interface designer but the quality of the tool
set available in HTML. A person used to the web knows to click on the "N" on
the compass graphic. It is slowly being rebuilt in our new environment which
is much more powerful and easier to use. Unfortunaly, our professional
environment has forced an emphasis on "real work", so the MUD has suffered.

The client used a model similar to this post for the chat/action window:

> Laurel Fan
> Sent: Wednesday, March 15, 2000 11:59 AM
>
> If want to allow playing your mud from a web browser, consider doing
> something on the (web) server side.  There are plenty of html-only
> (with none or minimal JavaScript) chat/irc type applications.  The
> basic principle of these is usually:
>
> 1. Have two frames, 1 for input, 1 for output.
> 2. Keep a connection to the mud.
> 3. Have the output frame refresh every 10 seconds or so.  The mud dumps
>    its output into a file, and your script sends the tail of the file
>    every time it's loaded.
> 4. The input frame is a form, containing a text field that submits to
>    the script.  The script sends the contents of the text field as
>    input to the mud.

The same method of using a META REFRESH tag also updated character status
graphs, time of day, phases of the moon, etc. There are well documented ways
to insert a JAVA applet inside a frame to do real-time updates, but this
gets into performance problems as well as buying the fun of JAVA browser
incompatibility issues. (I know, the design is supposed to prevent this but
all but the simplest applets have browser issues.) This lack of absolute up
to the nanosecond refresh makes certain kinds of popular MUD design
elemements such as real-time, macro driven combat impractical. But like all
design compromises, it opens up other interesting possibilities. I suspect
that in the hands of a good team, a lot could be done.

The ability of the designer to use frames (we don't use frames anywhere in
our professional work, but they work for building a MUD client) allows the
user to redefine menus and screen areas to perform functions. It is much
easier to expose all the cool features of a mud with zero training if the
user can click through a series of menus. Of course, we included a command
line interface because some commands are more efficient [dr all; drop all]
than navigating a series of menus.

Using HTTP as a server protocol is a somewhat different proposition.
Clearly, being able to use a standard web server with a database backend
solves a number of design problems. The "serve and forget" model allows a
huge number of simultaneous users and the methods for scaling websites are
well known and documented. However, that same model presents the web
designer with some real challenges. We use InterSystems' Cache' which has
associated programs which preserve a user's variable stack from hit to hit.
(BTW, Cache' is not very well know but it would be an awesome - if
expensive - backend for a MUD, traditional or otherwise. If anyone is
interested, I would be pleased to discuss it off list. I love this product.)
I am sure that there are other systems which provide similar functionality.
This method allows us to "remember what is going on" with a user as they
navigate through the world. That also allows the system to validate user
input and fail attempts to hack the client and send "impossible" commands.

Some quick notes:

JavaScript: Great for little things like graphic rollovers, client side
validation (you don't trust it if course) and some frame manipulation. Keep
it simple and you get good cross platform performance. Get fancy and you end
up with a mess.

DHTML: Cool and powerful but very browser specific. Move too far down this
road and you are trying to VB stuff in a hostile environment. There are also
speed issues.

XML: A wild card. Some huge potential power here. We will know more (about
our current development environment) when we return from a Developers
Conference at the end of March, 2000.

CSS: (Cascading style sheets) Really cool, but will loose you some of the
fringe. In its simplest form, CSS allows for graphic consistency without
creating a bandwidth nightmare of formatting tags. Get fancy with CSS and
you can really get wild. Once again, simple means consistency across
platforms.

Design: Be reasonable. We serve (and maintain) four versions of our inline
poll ASP product because of the need to get a lot of information is a very
small space.

I guess the point here is try to look outside the box. Text based games can
find a home in a GUI world. The key is to present the text in a rich,
familiar user interface and suck the player into the world with depth and
mystery. We will not be the first to field a fully functional HTML-based MUD
(Actually, we might never field it). But someone will. If it is good, it
will be very successful.

John A. Bertoglio
PulsePoll.com <http://www.pulsepoll.com/>
| 503.781.3563
| jb at pulsepoll.com




> _______________________________________________
> MUD-Dev mailing list
> MUD-Dev at kanga.nu
> http://www.kanga.nu/lists/listinfo/mud-dev




_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev