It all really depends on what you want to make. Before doing anything, get a design for your game down on paper. Once you have that, look at what codebases out there have the most features in common with what you want to make.

That's for creating a "hobby" mud, if you want to go commercial your options are pretty limited.

What is your experience with any of the above applications? It seems Cold C and DGD both would be simply tools with which to build a mud from scratch. It seems DGD is under the Skotos umbrella, although I just recently discovered iChat uses it, and there appear to be numerous options open if you want to try to go commercial with it, though fundamentally it is indeed very expensive.

There are no codebases that in and of themselves seem to do what I want, though there is at least one implementation of a mud in MudOS, highly modified, that comes close, that being Accursed Lands.

The purpose of this thread for me though is not so much to find out what I need as to sort of lay out what the features are of all the codebases, applications, languages and so forth out there that could be used, and what if anything any of them have prepared already in the way of worlds that already exist.

Diku and LP are obvious choices, and I welcome input about them as well.

I want to create a chart basically, perhaps a little more involved than the website in terms of discussing in depth the capabilities of codebases that are actually up and running, rather than a list of ones that may or may not be up, may or may not be supported, and that sort of thing.

ColdC, languages like Ruby, and so forth, get tossed around when people ask about getting a game started as well, and I would like to see more in depth information on how it is people think they could be used, or even what exactly is already included in ColdC for that matter.

What would eventually come out would look something like this:

Name: LpMud
Function: Server software for telnet with included interpreted language based on C.
Pros: Free to use, widespread support.
Cons: Older codebase, may not be used commercially.
Comments: Here I would attempt to break down anything and everything anyone had to say about their experience with the software being discussed, including perhaps for LpMud the difference between the driver and the mudlib, for example.

ColdC, while I haven't personally used it yet, I have heard is pretty good.

When it comes to working from scratch... make sure you are a good coder, or have one on your team. Expect to spend tons of time, and have basically no free time(unless you want to spend many years coding it) until it is finished. We, at have been doing just that, and it can be stressful. luckily we've finally reached a point where the end can be seen, and that is a good feeling. Rapture has been great for speeding things up, and taking care of a lot of the networking side of things for us.

Name: Rapture
Function: Handles all networking things required to run a mud, allowing you to concentrate on the actual world development.
Pros: IRE gives really good support, thanks a lot for that Matt and Chris. Relatively simple(yet powerful) language that is designed specifically for muds. Stable. Can be used for commercial games.
Cons: Expensive.
Comments: We use this for and it has sped up development quite a bit.

Now, since you're obviously thinking about running a mud... I'd point you to an excerpt from circlemud.org

My favorite quote, and so true.

That was hilarious!

If I were to be interested in making a mud, I think I would volunteer at Accursed Lands if they would have me. I think a good mud needs a lot of people to work on it and a distinct vision of some sort. I would be truly amazed if a mud engine came out that was both truly powerful and had the capacity to be started up out of the box and run by someone with only limited coding experience.

Believe it or not, my interest is not in being a mud admin though. My interest is in facilitating the creation of a community to step into the growing gap between Diku and LP and the more advanced engines, most of which seem to be inexorably moving towards private use and inaccesible licensing fees.

No offense! Heck, if I could bring down 100k a year for a program I would too.

A big part of what has formed this hobby though is the up and down interchange between players and coders - coders who game, and gamers who code, and how the two distinct crowds contribute in their own special ways and interact and create one community. This dynamic simply is not going to be available if the hobby continues to move towards privately owned, licensed engines that are light years outside the reach of the typical hobbiest.

And thankfully we're not quite there yet, so that's a good thing.

Thanks for your input! I am not by any stretch of the imagination biased against the industrial strength software, and who knows, out there somewhere may be a sugar daddy willing to sponsor some sort of a wizarding process so people can work their way into coding on a Rapture based mud just like the good ol' days.

Let me pipe up with my totally biased opinion that Dead
Souls LP mudlib is super easy to set up. The windows version
you just download and run. The unix version you download,
compile, and run. It's specifically configured to be easy
to start up a mud with minimum hassle.

Take a look at the intall FAQ:

I'd be very interested to know your opinion of how that
lib stacks up to Accursed Lands.

I'd be delighted to have the lib I work on included in your list.

-Crat

It just occured to me that we are going to have to be very careful about licensing issues because I personally do not know how they all interact or which they all apply to.

Isn't MudOS under LpMud's license? Does it play nice with GPL?

I am also a little confused because this mudlib appears to be the driver and library all in one, at least on the Windows version as I peer at the installation instructions.

Ok, a quick primer on LP.

There are two parts to an LPMud. The driver, and the lib.

The driver is the C program that accepts telnet connections
and does i/o, calculations, etc.
The lib is the set of files that describe the mud: rooms,
combat, etc.

There are various LPMud drivers: MudOS, DGD, CD,
LDmud, etc.

Each driver has its own licensing. None that I'm aware of is
actually GPL.

There are various LPMud libs. Skylib, Lima, Dead Souls, etc.

Each lib has its own licensing. Dead Souls is GPL.

The way Dead Souls does it is to package the source
code with the mud distribution, so you get the lib and
the driver in one download. This is pretty standard practice
historically (though some libs don't do it). Nightmare, for
example, Lima, and Discworld come prepackaged with their
driver also. Minor clarification: Nightmare *came* with it.
Nightmare's no longer available.

In the case of the Windows DS version, the source code
is also included, and as a convenience to those who do
not have cygwin or dont know how to use it, a pre-compiled
binary of mudos is included.

As to being careful with the licensing, yes. Care
has been taken to comply with the known licensing
requirements of both cygwin and MudOS. The Dead
Souls lib itself is GPL, and for technical reasons, it's
pretty much not possible to violate the GPL license
with Dead Souls.

-Crat

The Shattered Worlds LP driver is licensed under the GPL. I can half remember there being some dispute over this at one time, but according to the distribution it is GPL.

Name: Inferno
Function: Handles all networking issues and offers a powerful object-oriented interpreter layered on top of the server. Install, log in and start coding.
Pros: Ridiculously stable. The language is simple, sort of a cross between Python and JAVA, and was built for the sole purpose of creating virtual text worlds. Contains a huge, rich set of predefined script functions for handling object location, dynamic string substitution, and just about everything else. Object specification is built in.
Cons: Largely undocumented. Runs in RAM.
Comments: The Inferno platform is a highly modified version of Lamda MOO.

The page you linked was our game, but we shut it down a year ago. The platform used to build that game is what I'm talking about. The only place you'll find it is on our server, so maybe I shouldn't have posted about it in your thread. We're using it to build .

Name: Dead Souls
Function:
Pros: Ease of installation, cross platformer.
Cons:  *shrugs*
License:
Comments: Take a look at the intall FAQ:

Name: Inferno
Function: Handles all networking issues and offers a powerful object-oriented interpreter layered on top of the server. Install, log in and start coding.
Pros: Ridiculously stable. The language is simple, sort of a cross between Python and JAVA, and was built for the sole purpose of creating virtual text worlds. Contains a huge, rich set of predefined script functions for handling object location, dynamic string substitution, and just about everything else. Object specification is built in.
Cons: Largely undocumented. Runs in RAM.
License:
Comments: The Inferno platform is a highly modified version of Lamda MOO.  .

Name: LpMud
Function: Server software for telnet with included interpreted language based on C.
Pros: Free to use, widespread support.
Cons: Older codebase, may not be used commercially.
License:
Comments:  Here I would attempt to break down anything and everything anyone had to say about their experience with the software being discussed, including perhaps for LpMud the difference between the driver and the mudlib, for example.

Name: Rapture
Function: Handles all networking things required to run a mud, allowing you to concentrate on the actual world development.
Pros: IRE gives really good support, thanks a lot for that Matt and Chris.  Relatively simple(yet powerful) language that is designed specifically for muds.  Stable.  Can be used for commercial games.
Cons: Expensive.
License:
Comments:  We use this for and it has sped up development quite a bit.

Are you making the engine available in any way? There doesn't seem much point including it on a list of tools people can use to create muds if it is not available to anyone else..

Which is why I said I shouldn't have posted. My apologies.

BUT, I would highly recommend Lamda MOO to anyone who considers himself a good coder and is looking for a clean, stable platform. Lamda comes with no strings. There are no licences so if you want to build a pay-for-play you're free and clear.

I'll probably split the list into open source and licensable sooner or later.

Will add MOO and MUX in as soon as I can, or if anyone else wants to lay them out in format, for for it. Then I will just cut and paste it together like I did the previous list.

I won't bother anyone to provide an explanation here on the thread, a link or reference will be just fine, but here's my question: Could someone give a quick overview of codebases and how exactly you go about setting them up?

What I'm shooting at here, mostly, is I'm wondering if it's possible to load a codebase (probably LP, that's the only one I have any experience at all in) and run it in my own PC with relative ease, and use that environment to play around with code in and see it compiled and executed?

I think it would be easier for me to code as an avatar in a text environment, playing around and building, than reading a textbook line for line.

Anyway, thank you, I hope I haven't taken the thread too far away from its intended purpose.

(Please keep in mind, if you do answer, that I'm only fluent in layman and novice language.)

Excellent idea Shane, I was just browsing the internet the other day looking for a similar listing. The andreasen/newmud listing was good but not updated regularly enough and didn't contain that much detail. Sourceforge was also another good listing but again, didn't contain all MUD projects. Perhaps its about time we got something set up? A central repository for new MUD projects that players could browse to view the progress, news and features of new MUD codebases. Something similar to that provides project listing, help for new developers and support for existing MUD engines.

Enough rambling, here you go:

Name: MUDCore
Function: Scratch built C++ MUD engine by Tarmon's Gary McNickle. Provides socket handling, account system, player system and basic area structure. Aimed at providing a starting point for new MUD developers.
Pros: Extremely well written, documented and commented, Easy to extend and work with.
Cons: May not be used commercially without permission of the author, Not actively supported (trying to change this), Windows environment (needs porting).
License: GPL
Website: (down)
Comments: MUDCore is IMHO one of the best starting points for MUD development available. I have yet to see another codebase that provides such a great example of good Software Engineering practices (Commenting, Structure, Documentation, Programming Standards). The codebase is highly dynamic which makes it easy to carry out additions such as adding races, skills, etc. The Codebase was withdrawn from the world due to a lack of Interest, however, I am trying to speak to Gary about getting it re-released and supported.

And my work based on the MUDCore Engine:

Name: AMC
Function: MUDCore based attempt at refreshing space MUDs. Aimed and providing a highly realistic, detailed yet balanced gameplay. A Team project open to the entire MUDing community's input.
Pros: Professional Games Design, Realistic Space Engine, Advanced AI and logical scripting, Inherits and maintains MUDcore's ease of extension and good Software Engineering.
Cons: Still in developmnet, May not be used commercially without Gary's written consent, Windows only.
License: GPL
Website: [Click the AMC link]
Comments: I can't evaluate my own work, but i will provide you with some of the goals of the project:
+ Highly dynamic and maintainable MUD codebase
+ Represent a True3D Spatial Environment
+ Provide advanced AI handling
+ Implement a rich, detailed and balanced Player System
+ Utilising an advanced combat system
+ Highly dynamic and maintainable MUD codebase

The website provides more details, its basically using MUDCore to produce a Space based engine.

Hope some of this helps,

-Owen

Err... not if it is GPL.

Once again this is not much use without the engine being available. I don't want to sound negative all the time, but if you guys just want to plug your own games or engines then there are other threads. I had thought this one was about tools that were available for other people to use.

As for speaking with the author to get it rereleased, if you have a copy under GPL then why not just upload it to game.org or mudmagic yourself?

a great link.

Name: ColdC
Pros: Makes no assumptions about the type of game you want to make (it doesn't even assume you necessarily want to make a game). No restrictive licensing. Lends itself well to the creation of persistent virtual worlds. Disk-based memory. Objects can be reprogrammed on the fly without having to reboot and without having to destroy and reload the objects.
Cons: Spotty documentation. Be prepared to do a lot of low-level work with the core (lib) before you have anything resembling a game to work with.
License: GPL

ColdC most closely resembles the MOO programming language, but is probably just as accessible to anyone familiar with LPC. There are a couple of minimal cores available for anyone wanting to essentially build a core from scratch.

The driver handles incoming and outgoing network connections, but leaves just about everything else to the code in the core. This leaves a mud developer with a lot more work than would be required with most of the more popular LP libs, but nowhere near the level of work that would be required to develop a mud from scratch in C/C++.

Name: AMC
Function: MUDCore based attempt at refreshing space MUDs. Aimed and providing a highly realistic, detailed yet balanced gameplay. A Team project open to the entire MUDing community's input.
Pros: Professional Games Design, Realistic Space Engine, Advanced AI and logical scripting, Inherits and maintains MUDcore's ease of extension and good Software Engineering.
Cons: Still in developmnet, May not be used commercially without Gary's written consent, Windows only. Editors Note: Seems to be a problem with GPL and the original author's intent to keep it not for profit.
License: GPL
Website: [Click the AMC link]
Comments:  I can't evaluate my own work, but i will provide you with some of the goals of the project:
+ Highly dynamic and maintainable MUD codebase
+ Represent a True3D Spatial Environment
+ Provide advanced AI handling
+ Implement a rich, detailed and balanced Player System
+ Utilising an advanced combat system
+ Highly dynamic and maintainable MUD codebase
The website provides more details, its basically using MUDCore to produce a Space based engine.

Name: ColdC
Pros: Makes no assumptions about the type of game you want to make (it doesn't even assume you necessarily want to make a game).  No restrictive licensing.  Lends itself well to the creation of persistent virtual worlds.  Disk-based memory.  Objects can be reprogrammed on the fly without having to reboot and without having to destroy and reload the objects.
Cons:  Spotty documentation.  Be prepared to do a lot of low-level work with the core (lib) before you have anything resembling a game to work with.
License:  GPL

ColdC most closely resembles the MOO programming language, but is probably just as accessible to anyone familiar with LPC. There are a couple of minimal cores available for anyone wanting to essentially build a core from scratch.
The driver handles incoming and outgoing network connections, but leaves just about everything else to the code in the core. This leaves a mud developer with a lot more work than would be required with most of the more popular LP libs, but nowhere near the level of work that would be required to develop a mud from scratch in C/C++.

Name: Dead Souls
Function:
Pros: Ease of installation, cross platformer.
Cons:  *shrugs*
License:
Comments: Take a look at the intall FAQ:

Name: Inferno
Function: Handles all networking issues and offers a powerful object-oriented interpreter layered on top of the server. Install, log in and start coding.
Pros: Ridiculously stable. The language is simple, sort of a cross between Python and JAVA, and was built for the sole purpose of creating virtual text worlds. Contains a huge, rich set of predefined script functions for handling object location, dynamic string substitution, and just about everything else. Object specification is built in.
Cons: Largely undocumented. Runs in RAM.
License:
Comments: The Inferno platform is a highly modified version of Lamda MOO.  .

Name: LpMud
Function: Server software for telnet with included interpreted language based on C.
Pros: Free to use, widespread support.
Cons: Older codebase, may not be used commercially.
License:
Comments:  Here I would attempt to break down anything and everything anyone had to say about their experience with the software being discussed, including perhaps for LpMud the difference between the driver and the mudlib, for example.

Name: MUDCore
Function: Scratch built C++ MUD engine by Tarmon's Gary McNickle. Provides socket handling, account system, player system and basic area structure. Aimed at providing a starting point for new MUD developers.
Pros: Extremely well written, documented and commented, Easy to extend and work with.
Cons: May not be used commercially without permission of the author, Not actively supported (trying to change this), Windows environment (needs porting). Editor's Note: seems to be a conflict between the GPL and the author's intent to keep it non-profit.
License: GPL
Website: (down)
Comments:  MUDCore is IMHO one of the best starting points for MUD development available. I have yet to see another codebase that provides such a great example of good Software Engineering practices (Commenting, Structure, Documentation, Programming Standards). The codebase is highly dynamic which makes it easy to carry out additions such as adding races, skills, etc. The Codebase was withdrawn from the world due to a lack of Interest, however, I am trying to speak to Gary about getting it re-released and supported.

Name: Rapture
Function: Handles all networking things required to run a mud, allowing you to concentrate on the actual world development.
Pros: IRE gives really good support, thanks a lot for that Matt and Chris.  Relatively simple(yet powerful) language that is designed specifically for muds.  Stable.  Can be used for commercial games.
Cons: Expensive.
License:
Comments:  We use this for and it has sped up development quite a bit.

SocketMUD

Function: Provides a core base for handling socket connections and logging in and has a say command.

Pros: Incredibly stable its very limited functionality has gone through so many tweks and tests that it just doesn't fall over. You can do anything you want, there is not even a room system holding you in.

Cons: You really need to know how to code quite well because it provides such flexibility.

License: Public Domain

Website:

is Java-based and usable on Windows/*nux or any system with Java installed.

All right, on some earlier advice in this thread, I checked out the Dead Souls mudlib, an LP codebase that uses MudOS as its driver.

The only other codebase I've worked with is Lima, so you'll have to bear with what isn't exactly a codebase authority's review.

I liked it very much, it was easy to grasp from starting and you can see it's been designed that way. Nonetheless, it seems fairly flexible, and it's my understanding that LP code is also very pliable in itself (for good or for worse), so it seems that it's very powerful for something so easy to start with.

The Quick Creation System is a godsend for administrators with severely left-brained staff; it eases and quickens the creation of items, NPCs, and rooms so that a number of rooms and objects can be laid down quickly without working the code out by hand in a third-party editor. If it's your thing to do it by hand that's always an option.

Cratylus has labored on this library clearly out of love, and it's been said that people have complained because it's updated too often, rather than too little.

All in all the system seems very forgiving to the virgin admin, and as I've learned through the I3 network connecting Dead Souls muds to another, it's versatile for the old pro as well.

It comes in both Windows and Unix, the former very convenient for, again, the inexperienced would-be admin (can you tell I'm talking from experience?) I definitely recommend it for people who'd like to learn LPC and make a mud at their own pace without signing on to a team with its own deadlines and agenda.

I've never had any crashes or bugs in the few weeks I've worked with it, and Cratylus is striving for his next release as we speak.

Here's the link again:



I'm as good as home with Dead Souls, and I'm sure it'll only get better as time goes on.

I second CoffeeMUD.

It's good for many reasons: It's stable, it runs on Windows, has a web-based room/area editor right in it, and has a lot of features I've never seen elsewhere. Like a complete mundane crafting system for one (don't see that too often), and the important systematic stuff like PK, death, etc is configurable through an .ini file. Its got a growing community full of helpful people.

The only cons I can think of is that not all MUD hosts allow it, mostly because of the fact it is java and uses a lot of memory. I've never personally noticed any problems really, but I host my own.

Nice Thread.

I have seen requests for a 'simple comparision of codebases' since I got in involved in Mudding so many years ago. The problem is that unlike most software there is so much that goes into making a codebase workable that any really useful 'list' ends up being rather large.

A useful addition to your format might be something along the lines of: % Complete Mud bult-in.

For Dead Souls it would be 100%, for ColdC and ColdCore at least it would be more like 10%.

This is a huge factor and deserves special attention.

Since I just spent a fair amount of time with ColdC I would like to add some comments about the documentation. I understand what the poster meant about 'spotty' but I had a different reaction. Most everything is documented. just not in english exactly. What you have is a very technical description of the functions and commands and an almost complete lack of examples. (I should mention that I first learned to program in oh 1973 or so, I am no stranger to technical descriptions but jeeze did'nt one of the Authors have a girlfriend of someone who could have written a little english for them?)


After a whole lot of dedicated web searches by two people we were only able to come up with a half-dozen pages with any useful information, and only a couple of those were really helpful. So few people use ColdC there there just is not the sort of support system that is so important when working with a huge piece of software like a codebase.

Dead Souls has my attention now, not for the commercial project I wanted to do, but for a project that will set the stage, and gather the people necessary for the next game.


A.T
(-)

While I'm all in favour of writing muds from scratch, there's no "just" about it - it's a lot of extra work, and for many people it's simply not worth reinventing the wheel.

It generally is, although it depends who you ask. And it doesn't have to be a "dungeon" - that's just a reference to a single player game (called Dungeon).

Has anyone mentioned yet? I am really looking forward to running a MUD off of this service. It appears to be at just above the core ROM/Smaug level, nowhere near as flexibile as LPC but probably takes 1/10th as much time as LPC does. Considering how you don't need to know any programming at all to make MUDs with it, it probably has the potential to blow up.

I was writing my own engine at one point, and that was good times, but time constraints and being able to get support (almost impossible if you're making your own thing after all) are unfortunate realities.

I was under the impression you couldn't change the code at all - in fact, I'm fairly certain you can't even get hold of the binaries, meaning you're totally reliant on their services for the continuation of your mud. If they shut down, your mud is dead. If they raise their prices, you have to pay more, or your mud is dead. If you have a disagreement with them and they ban you, your mud is dead. And so on.

There's also the issue of changes to the mud. If you're running a Smaug, ROM, LPmud, etc, and you want to implement a specific feature, you can do so (or get someone else to do it for you). But with mudmaker, the changes are outside of your control - the best you can do is try to convince them to add what you want.

Those are indeed some serious potential problems, but it'd still be so much faster and easier than using LPC. Now that you mention it though I probably will start saving everything I make in word pad in case they go under in the interests of saving time.

The flexibility can be a problem, but sometimes less is more if you know what I mean. They do their best to leave things open ended and I like what they've got going so far.

Yep, MudMaker was mentioned.  The next post will be the list again, with a little addition to ColdC's info, giving you the place to go to actually get human beings to talk to about it.  Sorry to be out of pocket so long.  Work, you know...

Feel free, anyone interested, to update this. Just try to keep a consistent format, but by all means cut and paste the whole list and edit it.

Name: AMC
Function: MUDCore based attempt at refreshing space MUDs. Aimed and providing a highly realistic, detailed yet balanced gameplay. A Team project open to the entire MUDing community's input.
Pros: Professional Games Design, Realistic Space Engine, Advanced AI and logical scripting, Inherits and maintains MUDcore's ease of extension and good Software Engineering.
Cons: Still in developmnet, May not be used commercially without Gary's written consent, Windows only. Editors Note: Seems to be a problem with GPL and the original author's intent to keep it not for profit.
License: GPL
Website: [Click the AMC link]
Comments: I can't evaluate my own work, but i will provide you with some of the goals of the project:
+ Highly dynamic and maintainable MUD codebase
+ Represent a True3D Spatial Environment
+ Provide advanced AI handling
+ Implement a rich, detailed and balanced Player System
+ Utilising an advanced combat system
+ Highly dynamic and maintainable MUD codebase
The website provides more details, its basically using MUDCore to produce a Space based engine.

Name: ColdC
Pros: Makes no assumptions about the type of game you want to make (it doesn't even assume you necessarily want to make a game). No restrictive licensing. Lends itself well to the creation of persistent virtual worlds. Disk-based memory. Objects can be reprogrammed on the fly without having to reboot and without having to destroy and reload the objects.
Cons: Spotty documentation. Be prepared to do a lot of low-level work with the core (lib) before you have anything resembling a game to work with.
License: GPL

ColdC most closely resembles the MOO programming language, but is probably just as accessible to anyone familiar with LPC. There are a couple of minimal cores available for anyone wanting to essentially build a core from scratch.
The driver handles incoming and outgoing network connections, but leaves just about everything else to the code in the core. This leaves a mud developer with a lot more work than would be required with most of the more popular LP libs, but nowhere near the level of work that would be required to develop a mud from scratch in C/C++.

Here's a handy place to find humans to talk to about it.


Name: Dead Souls
Function:
Pros: Ease of installation, cross platformer.
Cons: *shrugs*
License:
Comments: Take a look at the intall FAQ:

Name: Inferno
Function: Handles all networking issues and offers a powerful object-oriented interpreter layered on top of the server. Install, log in and start coding.
Pros: Ridiculously stable. The language is simple, sort of a cross between Python and JAVA, and was built for the sole purpose of creating virtual text worlds. Contains a huge, rich set of predefined script functions for handling object location, dynamic string substitution, and just about everything else. Object specification is built in.
Cons: Largely undocumented. Runs in RAM.
License:
Comments: The Inferno platform is a highly modified version of Lamda MOO. .

Name: LpMud
Function: Server software for telnet with included interpreted language based on C.
Pros: Free to use, widespread support.
Cons: Older codebase, may not be used commercially.
License:
Comments: Here I would attempt to break down anything and everything anyone had to say about their experience with the software being discussed, including perhaps for LpMud the difference between the driver and the mudlib, for example.

Name: MUDCore
Function: Scratch built C++ MUD engine by Tarmon's Gary McNickle. Provides socket handling, account system, player system and basic area structure. Aimed at providing a starting point for new MUD developers.
Pros: Extremely well written, documented and commented, Easy to extend and work with.
Cons: May not be used commercially without permission of the author, Not actively supported (trying to change this), Windows environment (needs porting). Editor's Note: seems to be a conflict between the GPL and the author's intent to keep it non-profit.
License: GPL
Website: (down)
Comments: MUDCore is IMHO one of the best starting points for MUD development available. I have yet to see another codebase that provides such a great example of good Software Engineering practices (Commenting, Structure, Documentation, Programming Standards). The codebase is highly dynamic which makes it easy to carry out additions such as adding races, skills, etc. The Codebase was withdrawn from the world due to a lack of Interest, however, I am trying to speak to Gary about getting it re-released and supported.

Name: Rapture
Function: Handles all networking things required to run a mud, allowing you to concentrate on the actual world development.
Pros: IRE gives really good support, thanks a lot for that Matt and Chris. Relatively simple(yet powerful) language that is designed specifically for muds. Stable. Can be used for commercial games.
Cons: Expensive.
License:
Comments: We use this for and it has sped up development quite a bit.