Member Discussions

I have recently played on some MUDs and I would like to build a world on my own (I'm a coder).

I want to know where can I find a modern (2005) article comparing the various codebases that one can use to set up a new MUD. My feeling is that while there is a bunch of information out there, it is too scattered for me to get a good idea of which codebase would i like to choose. I can't tell you how many times I have come across broken links, or pages describing packages that no longer exist.

I am going to describe what I'd like; however, a good, decent, modern webpage comparing the various codebases available today would be absolutely great.

*Extensible parser.
*Is well documented.
*I can easily remove 'stock' data if I don't want it.
*Can handle combat-stuff, but also adventure-stuff like 'pull lever' or 'unlock chest'.

I appreciate all replies. Thank you!

Well, Ive been mudding for about 4 years and one of the codebases that ive seen that can handle what your talking about is Smaug. I dont know anything about coding, but a good Smaug codebase might be what your looking for. I dont know anything about the coding process of muds, just building :)
Well, hope that helps.

You may want to take a look at NiM5,
http://www.mugs.net/~theisles/files

We have some more advanced features, and it can be
expanded upon rather easily, or core functionality removed
and added to other codebases.

Also, http://www.mudolc.org which discusses some of the
features of MUDs, as well as has a good overview set of
links to a variety of different articles on the subject.

Smaug, while popular and stable, has some very difficult
commands and isn't as well designed, though it does have
an extensive (probably the most) set of features available
to a MUD administrator (many specific features, which I
won't get into here, could be automated through use of a
more powerful scripting language).

One thing that makes NiM5 unique, aside from its powerful
easy-to-use OLC, is that it has a scripting language which
can be used to write spells without recompiling the
server. Skills, also, can be added, and then scripts can
be written that create commands on an object to use those
skills. You may want to take at least a gander at it's
language, and if you have any questions about it, feel
free to email Locke or post at www.mudolc.org.



(Comment added by m_m on Sat Aug 6 21:39:27 2005)

re: Well documented

I'm not sure if it is well documented or not. I made some
extensive documentation, but something happened and it
disappeared or is inaccessible due to an error in the help
command. If you read through the help files, you should
be able to get a good picture of what is going on- or
better, yet, scan through bit.c for the flags used in the
OLC editor.

The OLC version that is written for NiM5's currently
available version has a few minor errors in it: one of
which is an error in the cmd_pedit cmd_oedit functions
which make it impossible to be used properly. I'm not
sure why this is: but a simple adjustment to the arguments
in the functions fixes this error. If you encounter it,
send me a message and I'll explain what's wrong. It's a
simple fix: just change arg1 to arg2 in these functions
and it's fixed.

The "trace" command is probably the most nifty feature for
automating "artificial life" -- also, the OLCs are more
efficient in their use of filespace and are more robust,
as are most user commands (I hand tested all of them to
make sure they don't cause crashes) . . . I think I've
discovered 1 or 2 exceptions, which are unfortunate, but
they are also easy fixes. I might get around to releasing
a new version one day, but it will have very few changes
to its core structure. I'm happy with the way the
interpreter works (albeit ugly to look at in the code),
it's pretty efficient and elegantly written, as is the
AGE, which offers limitless possibilities for
"ascii-graphicalization" of the routines. The graphics
routines are written similar to a standard graphics
toolkit, but for ASCII text.

I'll look into this, thanks for posting

It sounds to me like you'd be pretty happy with an LP MUD. Most LP MUDs will allow you to do much more actual coding than DikuMUD derivatives, plus you can avoid all the legal issues of the latter.

http://en.wikipedia.org/wiki/LPC_programming_language has some info about the LPC programming language (it's a full language, not just a simple scripting language like described elsewhere in this thread). Because you can program everything, if you run even the simplest LP MUD, basically, it'll be powerful enough that you can rewrite the entire game from inside the game, and not have to reboot or disconnect your players or anything like that. I'm not talking about editing some entries in a database or something like that, I mean everything including all of the mechanics of everything, all the commands, every function that any object has, etc. You can even edit the in-game editor from in-game.

Unfortunately, most are not very user-friendly to install unless you're familiar with *nix, so to get the best idea of what it's like, you might want to just go check out some existing LP MUDs and ask them if you can look around first. I would suggest trying something like the Merentha Mudlib or Lima or Discworld if you want to try it alone (simply because I've tried them, there are many other good starting points which I just haven't had the time to try yet).

I am personally biased, because on the MUD that me and my friends work on, I primarily do the adventure-stuff you were talking about. For me, the difference is letting me program and implement a pullable lever without having to reboot the MUD versus the alternative (program the pull command, test it at home, update it on the main server, restart the game on the main server so that the changes take effect, add a flag to a database saying which items are pullable).

It's hard to explain the differences because they're so big, but it would help to try one out.

I was precisely going to check Discworld, just to play. I didn't know it was an LPMUD. Coincidentally, the links section of their web page contains a link to some LPMUD coding documentation though it's relatively small and outdated (1993). Thanks for the suggestion. I'll look into these stuff more in depth.

Thanks, let me know if you have any problems.

-mm