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.