A MUD is a multi-user dimension, otherwise known as a role playing game. I am trying to create one browser based, but I am not exactly to proficient in Perl, or any other script for that matter. I was hoping someone would be willing to undertake the task of creating a MUD with me. I am willing to learn :)
COntact me at NinjitSerge@aol.com, thanks!

I'm not interested in being a major part of this, but a few suggestions: you'll want to get some sort of session management happening, so you can identify each individual user. You'll need to store this somewhere not just in a variable, because otherwise it will probably go out of scope immediately after each page view. Pretty much anything can connect to databases, though, so you could do something like that. You might also use a system to host your scripts that can manage session data (Apache::ASP or asp come to mind)

You'll also need to keep the clients updated. I'm inclined to suggest not having the whole page updated every 10 seconds or something; instead, I'd suggest having a frame that reloads every 5 seconds the content of which would be a set of commands to be interpreted by javascript elsewhere on the page (in different frames). This javascript can be trigged by the onload event.

Those are the major issues that I can see. If you'd like any more suggestions, feel free to ask. I suggest starting by just getting some code working; making it possible to walk around, with two simultaeneous users, would be a good starting point.

I used to play a MUD called Shattered Kingdoms, you should try and find that. I think that the people will be pretty helpful in answering your questions (although they may not (Im taking a fairly long shot on this one)).

HTML/HTTP is not a suitable platform for an interactive application like a MUD. The problem is that only the client is able to initiate changes to the application's interface. This means that much bandwidth is wasted in polling the server. Also, the response time is limited to the polling interval.

This is a major deficiency of the Internet today. There needs to be an efficient platform for interactive applications. This platform needs to be free and unencumbered by licenses and patents.

HTML is great when you use it for what it was designed for--hypertext. That means links to other documents. HTML was intended to be a way to easily describe the structure of the document and to reference other documents. That way you could leave the display up to the renderer. Sadly, some people decided that wasn't good enough and started to abuse things like tables to make their sites pretty.

As much as I hate to reiterate what everyone else has already said, please _don't_ write a HTML based mud, because it was not designed to have to be re-sent every five seconds. I could go into bandwidth calculations, but needless to say, if you had a thousand users and were sending out thousand byte pages every 5 seconds to each of those... yeah.

So, instead of learning perl, learn java, write an applet (as many, many MUDs already have) and some executable that each instance of the applet connects to.... of course, that isn't _much_ better bandwidthwise, but it saves you from having to resend all the table information each time.

Use the Learning Group! (it will make it easier!)

The key to internet (or networks in general) games is to transmit as little as possible. Leave screen drawing to the client PC and let the server keep all the clients synchronised. Use death reconing to know where every player is. For example: have the client transmit a message when the user start walking north, transmit another one when he stops or changes direction and every minute you let the client transmit the user's coordinates.

RedX