I have recently decided to try to build a MUD. I've been working on trying to get a decent layout of what I want to do, how I want to do it, and trying to build a basic design, but I want something to mess with, be it patching a current codebase to do what I want it to (to give me a place to try out an idea), or just to give me something to mess with as I try to write my own later on down the line.
What I am hoping to find is:
A fairly simple, clean codebase that is easy to work with
Written in C
Doesn't come with a huge host of features, but instead has The basics for gameplay (basic combat, movement, communications, the code to handle connections, ect)
I have been looking at merc 2.1 quite a bit, played with it some, and found it fairly pleasing to work with, but I want to see if there is anyone with a better idea for such a codebase. I have used, in the past Smaug and SmaugFUSS, but Smaug is, overall, much to large for me to work with (much of it would require removal, such as the scripting system and building system).
I think DoT is C++, but the bigger issue from the point of view of the original poster is, that DoT is, if anything, much larger than Smaug - as it is basically Smaug with a lot of extra stuff added.
I'm not sure that there is a simple, clean, codebase around that works reliably, but isn't overly bloated.
However this might help: There is a book by Ron Penton "MUD Game Programming" which teaches the basics of writing a code base, and has a fairly simple example one attached to the book (on CDROM). It is discussed here:
I actually own that book, I love the concept behind it, but I was never able to get the code to compile, even using everything exactly as he recommended it. For a while there was a project called NakedMUD that was the same idea, but it seems to have died from the looks of the Yahoo! Group.
It may not come with the basics of combat and movement, but you should consider SocketMUD. It is set up well and pretty nice to work with. Adding commands is simple and I was able to make some pretty rapid progress with it before I switched to C++.
I was going to use something like SocketMUD later on when I was going to actually start working on the real thing. I may start with thats instead of doubling my effort though.
@Nick:
Useful thread. I'll look a little deeper into it, but I can see I missed a few things already.
I actually own that book, I love the concept behind it, but I was never able to get the code to compile, even using everything exactly as he recommended it.
I got it to compile, but it wouldn't run unless I made some subtle change (something to do with the way it counted outstanding socket IO). Otherwise it sat there not accepting new connections.
The problem probably is, it may still be too simple for what you want, and may also be too complex. :) For example, he has two MUDs, "tiny" and "larger", the tiny one is pretty simple, the larger one uses Python, which you may or may not want to use.
However to do the book credit, it does go into a lot of detail about things, and if nothing else, helps clarify your ideas.
Penton's book is a good read the and code was very interesting, though I have never used it myself.
In relation to the other thread, I might note that Richard Bartle's book Designing Virtual Worlds has been an absolutely vital read. In fact, I would say it has given me a greater understanding of all game creation in general, not just virtual worlds. If you plan on really hacking together a code base I would make sure to read each and every part of the book (I've read the part on virtual economies a hundred times, but I'm also an Econ/CS double major). It is unlike Penton's book in that it is completely theory based and often analyzes the trade offs between two ideas that solve the same problem (for example, perm death v. infinite respawn).
Of course the design is completely up to you, but it is nice to look at the abstract in one book (Bartle) and see it applied in another (Penton). There are many free code bases to dissect and analyze if you are curious about various implementations of things.
To be honest, I think you'll make a better game if you start with something like SocketMUD, especially if you are the only programmer. You'll produce better code if you know how each piece of code interacts with each other instead of trying to identify why or how some existing feature is used and if it is safe to modify in some way. SocketMUD takes out the initial complexity of sockets and gives you an easy way to start creating content. The code is much easier to handle when you know exactly how characters and objects interact with rooms or some other means of movement, how combat logic is computed and damage is handled, etc.
Of course, that is assuming you know a lot about programming and virtual world game creation. If you know fairly little then I would take an existing code base and fiddle with it, just as you were mentioning above.
I think that I am going to try starting with Socket none the less, however. I have the merc src to look over if I become too lost, and to play with if I want to, but I think I may like working with Socket a little better after thinking about it.
I've been working on trying to polish the basic design some, though, and so far the notes at over 170 lines (many of which wrap 2-3 lines, but I never put a linebreak anywhere in them just to keep an idea on one line), and I am STILL going on it.
The books, however, will have to wait. I'm short on cash, so I can't afford them at the moment, but I may look to see if they are in the library.
One thing to keep in mind is that the Merc/Diku/SMAUG code bases are not always, ah, perfectly coded. It's good to poke around and see how things are done, but the architectural decisions in these code bases should not be taken as gospel.
I have a correction to my earlier statement, turns out that NakedMUD is still alive and well. The homepage is
http://homepages.uc.edu/~hollisgf/nakedmud.html
It's basically the same idea as Ron Penton used, but this one is taken farther. I haven't tried it (yet, downloading it now), but it is supposed to be fairly easy to use as a base to apply any rules or anything you want.
@David: Heh, that's for sure. Design flaws are the biggest reason I dumped those code bases in favor of my own. That way, if I hit a design flaw, I can't blame anyone but me ;)
It is an interesting challenging designing every part yourself. With so many ways to accomplish so many tasks it becomes very interesting to see which solution wins out and how it is picked from the others.
I know. I never understood (in Smaug) having both send_to_char() and act(), since the two did the same thing, nor the short-sighted magic system that they implemented (bool resistence checks vs. %-based)
Thats another reason I'm going to just work with my own. Like Whitheknight said, at least then there is no one to blame for problems other than myself.