What would you like to see in a MUD?

[schilcote]

I'm coding a MUD (Multi User Dungeon), and I need some advice on the finer points. I have the general idea sketched out, and I have the TCP networking (though I might rewrite it in UDP) and command parser coded and (mostly) debugged. The server will be extensible, reading game data from files (a bit like Transcendence). I'm currently fleshing out the command set, and I wondered if anybody has any input.

[Aury]

Hmm... I think we'd need a little more detail. (is, what's this about?)

Anyways, I've never used a MUD before, so I wouldn't really be an expert on what you'd need.

[schilcote]

Well, there really isn't much detail to tell you about. The game is defined through map files and item files and that sort of thing. I'm writing the engine that reads the files and talks to the client. One neat idea I had was the way that the game would represent the world\room\item\player tree. I think I'll make it so that instead of big arrays and memory shuffling, I'd just store the world in a directory. In other words, if player Schilcote was in the room called White Room, holding a carton of cream, there'd be a folder in "world\White Room\" called "Schilcote", in which there would be a folder called "carton of cream". Pretty interesting idea, isn't it?

[Aury]

That's actually a very interesting approach to storing information. I take it the information doesn't change very rapidly or is needed very quickly?

[schilcote]

It does not change very quickly (it would need to be modified every time a TAKE or GO command is given, which is about once every 30 seconds for the average player), and also even if the language I'm using had the proper facilities for a complex tree structure, which I don't think it does, I probably wouldn't understand it very well anyway. The directory structure method is a very simple solution, plus, instead of storing the tree in memory and either losing it at every restart or having to save it, the world is allready stored on hard disk, so you don't have to worry about power failures or such things resetting your server. Also, the directory method provides a very easy way for an admin to move things about, just move the representation in the directory tree. It is a rather novel method, but I don't see anything wrong with it, and it seems like a pretty good idea, so I'll try to implement it and see what happens.

[Aury]

good luck! I'd like to see if this works!

[schilcote]

Here's a more sespific question: Should I put music in the game? Now, music would be a nice addition to an enviroment (play a MIDI of Rush's Jacob's Ladder in a dark dungeon, stuff like that) but it would either require a huge amount of bandwidth to carry sound buffers (which I can't get to work anyway) or require the player to download packs of MIDIs and complexify the client, which I would not like to do at all.

[Aury]

if you can keep the filesizes and amount of music to a minimum, it would probably be nice, but if you can't, it'd probably just be better to let the person running the client to have a media player program running in the background.

[hex]

Sounds cool! What language are you using?

Permanency and easy desktop editing of the game world are major advantages but there's other ways to get that if thats all you want. In general I would say that using directory's like that is letting your self in for a whole range of problems (I/O bottle necks and so on) but practicality beats purity, if implemantaion is simple and it works well then that's all that matters. It might even be the best thing if the language is as bad as you say.

Music might be interesting but I would leave it until you've got something basic running. As for other features make sure you have the obvious communication commands like shout and whisper, I personally would like puzzles (as in IF games) and the ability for players to add to the game world.