[MUD-Dev] Re: mud websites
Scatter
scatter at thevortex.com
Wed Jun 10 22:57:53 CEST 1998
I'm developing an LPmud using the MudOS driver. I worked for
a while on a mud with what I considered to be a superb
supporting website (if you're interested, it's at
http://eclipse.cs.pdx.edu) and having found that website
useful, I naturally wanted a similarly good supporting site.
A chance visit to http://www.imaginary.com/~beek introduced
me to "WWWlib" - a minimalistic HTTP 0.9 text/html webserver
written in LPC for MudOS.
Ding! Idea! Incorporate the webserver into the mud. I've now
written my own HTTP 1.0 webserver (not quite complete, as
yet no form support) in LPC and incorporated it into my
mudlib. Now suddenly there is so much potential for interaction
between the webserver object and other objects within the
mud that the possibilities seem overwhelming. Pages can be
read from static files or be generated on the fly by "page
objects" - transparent as far as the web browser is concerned.
The few help pages I'd already written were in a subset of
HTML with the intention of being able to use the same files
in the mud and on the webserver - my online help system uses
the tags to format and colourize the pages. Now, I have a
"help index" object that scans all the available helpfiles
and generates an HTML page dynamically containing a link to
each of them. So if I add a new help page, it's immediately
available on the web - no extra work needed, not even a
copy. Updates to help pages are also of course instantly
available.
Since every command on the mud is modelled as an object,
and contains within it help for that command, it was a
few minutes more work to create another "page object" that
would take URLs of the form "/help/commands.html?blah"
and generate a help page for the "blah" command, or an
index of links to such URLs if no "?blah" part is given.
Add a new command, and with no extra work that command and
its help are available on the website.
A webpage to show who's currently online was trivial.
Ditto pages to "finger" players.
I'm planning an interface to read the message boards, and
since pages can require character name/password authorisations
I can also provide secure (well, at least as secure as logging
in via telnet) interfaces for posting to the boards, and
reading and sending mud-mail. They'd be the same boards and
mail as available in the game, but with a much prettier and
friendlier interface than a command line can provide.
This is, of course, just the start. I want to put a web
interface up for new character creation. New players can
then make all the decisions needed to create a character
with _all_ of the muds help within easy reach and links
provided to appropriate help pages in context. No java or
javascript required! :) The "stateless" nature of HTTP
might cause a couple of hiccups but since I'm in the unique
position of being able to edit the webserver, I can add tricks
that avoid the need for cookies. State could be remembered
by the server (or maybe better, by the page objects) based
on the a simple key - the connecting IP perhaps, or a
hidden field containing a unique key embedded in the form.
Then there are the possibilities of allowing creators a web
interface for building standard rooms and objects (though
they'd still need to add LPC code to the generated files
for any non-standard features they want).
A web interface for my bug/suggestion report tracking system
would be nice too. Generated images are beyond me though,
so it would have to do without pie-charts and progress
graphs... :)
Something I could do is a web-based interface to allow you
to even play the game - doubtful though. Probably what I
would do is to find a free Java telnet applet and modify
it to connect directly to the mud.
I guess my point is really this:
Look how much you can do easily when your webserver is just
another object in your mud! It can talk to, gain information
from and build pages based on any other object in the mud, is
always up to date, can identify characters and grant them
the authorisations they have within the mud...
Writing a HTTP 1.0 compliant webserver was fairly easy - a
couple of hours work. It's less than 20k of LPC code. Since
practically any mud server is going to have socket, telnet,
network code already, would it take much more than that to
place a webserver in any server. With this in mind and all
the possibilities above, why wouldn't you want one? :)
There are only a couple of caveats I can see. Firstly the extra
overheads of CPU and bandwidth that the server would generate. I
don't find the former too worrying (unless you are anticipating huge
numbers of hits). The latter could be a problem, I intend to link
things like common images from a seperate website so that
they don't eat into the mud's bandwidth. The second is simply that
it does mean that if the mud is down, then the website is also
down.
Something to think about?
--
Scatter ///\oo/\\\
More information about the mud-dev-archive
mailing list