[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