Types of Mu*
 

I'm wondering if someone could tell me about the differences between the various types of MU*s, from both a player perspective and an administrative one.

I am NOT looking for "MUSHs are for RP, MUDs are for cool kids!" The purpose of this inquiry is so I can decide on what system would be best to use for my purposes (in this case, I plan on creating a custom MUD, but I want to "test run" the theme first to see if would even interest people in the first place, so am considering opening something less complex). Mostly, I am familiar with MUDs, but I am growing cruious about the different types of MUSH, MUX, and MUCKs out there (and others, if there are others) and how they actually differ. I'm not going to be looking for something that I will need to fully extend on my own -- just something to get up and running for a RP-type game and survey for ideas while I focus on work on another platform.

Looking for information on like: ease of installation, active development, adoption rate, syntax, admin tools, major player tools, etc. etc. Do they require special coding knowledge (i.e, custom scripting languages), can player permissions be turned on and off? Do any of them have combat engines? What are some of the best examples (in your opinion) of those systems out there (i.e -- best game that uses the system to its fullest).

Re: Types of Mu*
 

for my breakdown of the three main MUD families.

Re: Types of Mu*
 

Nice. Thank you, KaVir. I'll give it a look over.

Re: Types of Mu*
 

I've worked with LambdaMOO for years, and I have to say, I don't understand why more folks don't use it as a game platform. It's stable. It's infinitely extensible. It's still in active development, with a large community of users who are happy to answer questions. Its license allows you to do just about anything you want to with it, and it's a snap to install and maintain.

The real appeal of LambdaMOO to me is its scripting language. The MOO language is an always-on translator that's object-oriented, dynamically typed and robust. It allows you to make instant implementations without rebooting or interrupting the game at all. And the cool thing is, if I want to make additions or changes at the source level, I can do that too. For the scripting language, there's a detailed programming manual and multiple tutorials available.

LambdaMOO's "core" architecture lets you start a game from multiple development points, whether you want all the mechanics that come packaged with JHcore and LambdaCore or you'd rather start from scratch and build your own. All you have to do is launch whichever database type that you want. Or fire up a bunch. They use minimal resources and take seconds to get running.

JHcore and LambdaCore both include comprehensive admin/user tools and huge, well-developed help systems. MinimalDB starts you out in a single room and gives you an eval command to work with. LambdaCore has a syntax manual.

My perception is that MOO's are generally thought of as persistent realities where users wield the tools to and/or are responsible for building the world and its content. And I understand that that's not the type of thing most people are looking to construct when they talk about building the games of their dreams. But it doesn't have to be that way. You can customize your core however you want and build a "MUD" just as easily in LambdaMOO as you can with LPmud, Diku, SMAUG or any other code base.

As for my "MOO," it separates coding and world-building privileges from players and tiers those admin abilities among various levels of game staff, from those who code to those who use tools to build the world and create content. The game itself has a lot of design flaws. It's outdated in a lot of ways and is no longer being actively run. But the platform is very good, in my opinion, and if you're interested in knowing more or taking a look, shoot me a PM.

Like I said: I've used LambdaMOO for a long time. I have zero experience with anything else. If anyone wants to explain why MUD developers shy away from MOO and what makes the other code bases better/more attractive, I'm all ears. There are obviously reasons why other platforms have proliferated while MOO has not, and I'm genuinly interested in hearing about them.

Re: Types of Mu*
 

Will,

It is probably because no one remembers the song, "Lambda Lambda Lambda and...Omega Moo, sit down in that chair right there, cuz we gotta show for you. We gotta high tech rythem and a funky sound that will make you move your body down to the ground..." - ala Revenge of the Nerds.

Re: Types of Mu*
 

I think it's mostly an accident of history; in the early 90s the game players congregated around DIKU and LP and the academic and social communities did the same around MOO. There is some cross-over but once you have critical mass these things kind of perpetuate themselves.

Re: Types of Mu*
 

I tried a MOO once. It had lots of @ signs and never explained why, so I didn't look back.

Re: Types of Mu*
 

In my experience, "@" prepends "tool" commands, mostly for building and creating. It's a syntax convention that has been adopted by lots of folks who use the MOO platform because players in their games are allowed to build areas and create objects. But the use of "@" in commands is not native to LambdaMOO. People have chosen to do it for their own reasons, but it's not part of the platform. We chose LambdaMOO because it looked like the most stable, dynamic code base out there, and used it to build a game where players play and the staff creates the world--with zero @ commands on the player side.

Re: Types of Mu*
 

I was a builder on Will's moo-deriv for a few years. I was also a builder on a couple of Dikus, an LP, an LP-esque custom hybrid weirdness thing. Out of all, from a builder's standpoint, the MOO was the easiest, hands-down, to work with. It was the most fun to work with, it was the FASTEST to work with.

It had its moments of danger - I mistakenly used the wrong parent object to clone a child object, and got one of the Admins stuck in a room that wasn't a room, and therefore we couldn't make exits to get him out of it, and deleting the object would've deleted the Admin. I can't remember what it was that we did to fix that, but when it was done, he re-set MY parent link to a chair, and sat on me. And since I was no longer an NPC/PC/MOB, but instead, a sittable chair object, I couldn't talk, look, or report up to whine, or interact with the game in any way at all until he switched me back to being a mob again.

Fun times :)

Thinking back, I want to say we @moved the admin to an actual room and then reparented the object to its correct parent. The @ was exclusively a staff symbol though. @create, @dig, @adj, @move, etc... anyone else who tried using it would get a generic "I don't know what you're trying to do" or "What?" message.

Re: Types of Mu*
 

I took a look at a JHCore MOO -- was very nice and easy to set up.

My biggest issue with it is that some old habits die very hard. I'm used to LP muds, mostly because I could pull individual code files down, work on them offline or at my leisure, and then upload them back through FTP when I was done. The ability to work offline is absolutely CRITICAL for me, because I do spend about 2 to 3 days a week without predictable internet service (no thanks to an ISP that continues to gladly charge my household the full cost of its blazing "cable" speeds -- capped at 80 kb/s.).

Since I am utterly unfamiliar with MOOs in general, I cannot figure out how to do this, or whether it is even possible. The command structure is completely above my head, and while JHCore does have a pretty decent help system, it isn't very complete -- it's an instance where in order to know how to run one, you need the help of someone who already knows what they are doing.

Re: Types of Mu*
 

You use the @show verb to look at the props and verbs defined on an object and @list to dump code to the screen. Copy/paste it to a text editor and work offline all you want. To upload to the game, copy your code, log onto the server, paste and disconnect. I know you said you wanted to use FTP because of unreliable internet service, but connecting to a MOO server is no more bandwidth intensive than uploading stuff via FTP.

I have megs of script files on my HD. It's nice to have them at my fingertips when I want to make changes or restore something that someone has accidentally deleted or screwed up.

I'm not a big fan of LambdaCore (JH is a direct mod). I've spent some time messing around with it 'cause I wanted to see how stuff was implemented and copy some of its code, but it's way too open with player privileges for my taste. And everything in LambdaCore is so interconnected that it'd be more work to change all that basic tool-level stuff than it'd be worth. If you don't mind all the invasive tools LambdaCore gives to players and just want to start quickly, JHCore will work. You just have to spend some time playing with it to learn how everything works. If you're serious about creating a quality immersive experience, however, I suggest building your own core. It makes for a little more work, but the end results would be well worth the time and effort, in my experience.

Few tips for exploring LambdaCore:

• Type commands by themselves for syntax explanations.

• Look at the LambdaCore manuals:





• Join the MOO mailing list--ask questions, scour the archives:



• And I'm always willing to help. :)

I hope LambaMOO turns out to be what you're looking for.

Good luck!