First to introduce myself as I have been lurking and never actually created an account. I am Xyre creator of the pile of junky code called Cypheria. Now that the formalities are over here is what I have come to say.

Here is an idea that I have been pondering upon for a while,

Why not unite coders under some sort of agreement and have them submit code for the creation of a advanced and a very stable MUD. With the help and ideas of many coders all working for the common good of MUDders it would bring about change in the entire MUDding world. Now yes I do understand that people may not always agree on the same things or may have different ways, but if it could be worked around then it may be the boost this community needs.

I'll leave some of the serious thinking up to the rest of you.
Please don't flame me or ridicule me. I would like some serious ideas and opinions here.

Thank you,
Xyre

United coding is usually done in the way of freshmeat projects - if you wanted to start something of that sort, look into it, and get one rolling for your codebase. Some codebases have publically shared snippets and addons for codebases, allowing many to customize the MUD with the features they may not have the time to code, or are new to coding and are taking the "snippet manager" approach, which is usually the easiest way to learn the codebase as long as you're learning the language cocurrently.

Too many coders sharing random ideas without a general agreement would be a migraine IMHO - That is also the same reason that many like to grab a codebase, and just do all of their own custom mods. If you have 234923424 MUDs with the same identical codebase loaded with features, the only difference in them would be the zones(both stock and custom created). Many that MUD are very intellectual / creative / analytical, and if they dont find what they're looking for in a MUD, they will go elsewhere.

I am more than happy working on any projects I feel I want to, or are critical without 40 other coders modifying my work, or making changes that I added, and they don't know why... only to have things fail as a result. Circle isn't the easiest codebase to play with, want to make 1 mod, you change 12 files - it's a spider web in that respect, but very stable as a result - in my eyes anyway.

To sum up my rambling: If you feel it's a good idea, check out freshmeat and get a project started for it, and advertise so those with like ideas can contact you and you can get your project rolling, just be ready for a headache if mass chaos results.

Zaroth-

I think standardization is a wonderful idea. Imagine, the best of Circle, Diku, MOO, MUSH, ROM, etc. etc...all written from scratch to function in a single codebase, with all the stuff that limits their current codes tossed aside or re-worked to make them more efficient and useable. Then adding other things that existing codebases might lack....

The possibilities for variety in muds would be just as endless as they are now, but the possibilities for -quality- muds would be improved a hundred-fold, because the code-base would be just -that- malleable.

How about creating a Basic Standardization. Nothing special just your basic code and being able to change it easily for say a H/S to a Roleplay. The possibilities are endless and the outcome would depend upon the ideas and choices of the creator.

How about making the codebase with "plugins" of a sort that could be used in place of snippets. This way people could continue to contribute without the hassle of explaining every step of the way just to create a new reset.

Now I do agree that it would be hard to control the massive input of the coders, but if some kind of system could be created for order, then it could work.

// Xyre

I am not a coder, but it sounds a lot like MudCore to me.

Hi.

Considering I probably account for anywhere from 10 to 50 percent of all the real coders to post on these boards (snippetmonkeys dont count) I felt obligated to notify you that this idea has been nominated as one of the worst ideas in the history of sentient thought.

If you could get such cooperation, it would be better to have all these contributing parties log in as players and have the MUD itself be right-out-of-the-box Diku.  With that many players, you'd win by default; but if they all participate as coders, you'll end up with yet another miserable failure which will slowly pass out of all knowledge as people condition themselves to ignore all the idiotic advertisement spamming on these forums.

Best of luck
Paul Erdos

Erdos seems to be taking a relatively negative perspective on this...

I think it's a good idea (as a non-snippet monkey; lets forget about my merits as a coder), but the real question does boil down to: what in a MUD should be standardized?

Combat is a pretty MUD-specific thing; different combat systems for different MUDs.

The same holds true for economics, roleplaying, MOBs and their versatility or lack thereof, etc.

Unless you were to define either a barebones code base that could be built upon (via snippets and the like) to customize, or you define a very specific MUD theme and develop a codebase based on that theme (ROM-style, basically), it's hard to see where you would start, or what your goals would be. Post some specifics on what you're trying to develop, and maybe you'll get some offers.

-Visk

To be honest I think that's the only way it could really work - provide a well written bare-bones codebase, and get each developer to write individual modules that can be plugged in, with as few dependencies as possible. Each developers would therefore work more or less separately, while those actually using the codebase would be able to select and plug-in the modules they wanted. You might also want a small team for giving modules some sort of official "meets our quality requirements" stamp, and to maintain a website with downloads and information.

If you tried to get everyone to work together it would almost certainly be a complete disaster (too many cooks, and all that).

Plug'n'play? :-)

However, yes. Simply put, the ideas of a "best" codebase, or of even of "best" features, or even of a good, cooperative venture that's generally preferred... are wrong. There is no such thing.

However, imho, the thread has ventured into unknown territory far, far away from the source.

Sounds like... open source. Aka, em, Sourceforge?

However, I should note that I have yet to see a good mud codebase come out of such a development process. Look at, say, AIME. Some of the worst code EVER (though, admittedly, functionality is not bad, and it's very appealing to my builder-side).

It's possible, sure. A quality-controlled open source codebase for which you would need to generate some very hefty interest from the better coders out there... Sure, possible. Difficult, though, and in the end it would just be another codebase, though potentially one with some nifty algorithms.

Well, don't know about that whole united coders thing, though it would be cooler than h ell, if you don't mind me saying that. But I think it would be near to impossible, but if it was accomplished I would sure use it.

This touches a bit on my earlier proposal for PTP - player transport protocol. Ignoring the social problems this kind of thing creates, it would be interesting to create the framework for a multi-MUD game and an administrative collection of IMPs who work together to maintain building/coding standards and inter-operability to allow all of their players to hop from one world and engine to another.

Perhaps this is what you're thinking of? I'm still not clear as to what you mean; your statements have been interpreted a few different ways now.

-Visk

Sounds familiar



We couldn't even agree on a license, a language or a platform.

You decided on a name (though admittedly a bit of a no-brainer). People underestimate the importance of deciding on a name!

Coder #56: hey guys, how's this for a first line?
[code] while ( TRUE ) update( );[/quote]

Coder #104: whoah, did they start a whitespace ration? Make it
[code] while ( TRUE )
    update( );[/quote]

Coder #37: update is too generic, it could easily conflict... let's make it
[code] while ( TRUE )
    update_MUD( );[/quote]

Coder #194: Wouldn't it be more elegant to do this?
[code] while ( update_MUD( ) )
   ;[/quote]

Coder #562: I think it'd be more readable if we did this:
[code] #define CONTINUE_MUD 1
#define STOP_MUD 2
...
while ( update_MUD( ) != STOP_MUD )
   ;[/quote]

Coder #62: Argh, the last thing we need is redundant and pointless definitions!! Anyway, we can just use exit() from the lower level functions, so I say we just do
[code] for (;; )
    update_MUD( );[/quote]

Coder #11: My "microsoft vbasic 101" teacher said if you use capital letters in a function name it makes baby jesus cry! Make it
[code] for (;; )
    update_mud( );[/quote]

Coder #73: This is purely aesthetic, but I prefer
[code] for (;; )
    update_mud ();[/quote]

Coder #99: Since this is open source, we need more comments. A better version would be
[code] for (;; ) /* Infinite loop */
    update_mud (); /* basic pulse of the mud */[/quote]

Coder #29: No, no, no, that's ugly! Make it
[code] for (;; )                   /*
    update_mud ();     *  Main game loop
                                *    -Coder 29, March 14 2004
                               */[/quote]

Coder #57: Whoah, whoah, are you trying to steal all the credit for these lines?! Freaking creep. I prefer this:
[code] /*                       *\
*     Main Loop    *
\*                       */
for (;; )
    update_mud();[/quote]

Coder #84: Guys! Guys! I've got it! This is perfect:
[code] while ( TRUE ) update( );[/quote]

(Return to top of message and re-read from beginning)

An amusing example erdos, but hardly a scenario with "individual modules that can be plugged in".

The biggest problem is actually getting started, as described in Tyche's example - but once you've got that sorted out, each person can do their own thing. And as long as they follow the agreed upon design approach, every contribution is potentially useful.

Coder #56: Here's my server module, what do you think?

Coder #104: I decided to do it this way instead.

Coder #37: Here's my multithreaded solution!

Coder #79: I don't want a mud, I just want to play on my own - he's my single-player solution.

Result: You've now got three different server modules that other developers can choose from, as well as a single-player module that could be plugged in and used by someone who just wanted to do some single-player gaming.

Now repeat the process for additional modules. Some of the later ones will no doubt have dependancies, being based upon other modules, but it would still give a great deal more flexibility than is currently available.

You know.. Maybe mudders are just not equipped to deal with this, considering the comments. lol

But seriously, look at something like the POV-Ray raytracer. This was developed by a small team, but giving out full source, so there is an official version plus MegaPOV (sometimes several). MegaPOV is the bleeding edge version that everyone tries to impliment new ideas in, which if they are decently documented and actually useful, will eventually end up in the official version. This system has worked quite well. The current version 3.6 is a bug fix beta for 3.5, which is the last major version before they do a complete redesign (and probably add quite a few additional features that where impractical in the current one).

In terms if capabilities, it runs on virtually anything, has 90% of the features of high end programs like Maya, can simulate much of the stuff not directly supported through its script, etc. It has no inbuilt modelling program, due to the complications of making such cross-platform, but that is about the only thing that keeps it from being noticed by the types of people that do buy Maya, Cinema 4D or the like.

Point is, a text based system, even if it provided the ability to extend itself and use things like graphics as well, is significantly less complicated than POV-Ray was even in version 1.0, when it was little more than a rewrite of DKBTrace. What you need is a core group that can build a really good base, then maintains control over the official version. As long as they allow feedback and pay attention to what features other people add in to the unofficial versions, these features can, if really useful, be integrated into the next official version. The result if done right can be a very stable and exceptional system.

The problem imho with most currently is that some group developes one that does what they need, release it to the public and a few years later you have no official version (since the originators don't want to deal with what anyone else did to it) and 500 variations, none of which are as good as version 1.0 of some new codebase that comes along. This cannot by definition generate the kind of long term progress needed to keep a codebase on the top of the list of ones new people will be using ten years from now. And it definitely doesn't improve the system any of those 500 variations are based on.

In the case of KaVir's and erdos's example, most likely you would end up with one server that combines #56's good ideas with #37's and an option to allow someone to change one setting to make it workl like #79 wanted. Plugin modules shouldn't imho be at that low a level anyway, though a single player module that included a 'client' that plugged directly into the driver for local control would make sense. You might therefor provide a 'internet' module that handles output over telnet or other methods and a single user one that just displays local. You could have one or both plugged in as needed. The other two though don't make sense as seperate entities. That is what you need a core group for, so that you don't get people designing stuff that makes no sense as seperate modules and screaming about how no one wants to try their new toy. Someone needs to decide what does make sense to modularize, what shouldn't be and how to adjust the code to keep the creation of such a module for some function doesn't flat out break the driver or library used on it.

Nethack.

Consider this...

Ever hear of the Imaginative Builder's Guild? Ok, if ya have or have not, it does not really matter, was just curious. It may have been relevant here as an example.

My point? Why not start the MSU (Mud Staff Union) back up. It would basically be a web site where contracts are held that programmers, coder, builders, admin and immortals can apply to themselves or MUD's apply to them that could possibly legally binding. It would probably more relevant now than in 1998.

I am still working on legally binding contracts, I will let you know in May if I can etch one out if this topic finds itself still relevant. Contracts require five main bits of info, but I have not perfected it enough for my teacher, who is also a lawyer, to give me a thumbs up. The class ends in May.

Anyways... the site would list contracts for specific positions, listings of union MUDs/resources and union members. It would take me some time, but I can attach it to the Mud Staff Resource Page (). I would prefer base it off Iluvatar's Bill of Rights since it is highly proclaimed as fair and balanced.

(snip rest)

You still seem to be making fun of something completely unrelated to what the rest of us are talking about...

Ok ok, lets stay on topic here.

Keeping everyone from coding their own way wouldn't be hard to control. Just put out some guidelines, or have whoever is higher up just go over the code and fix it to the style wanted.

It should also be cross-platform and definitely opensource. Basic 'plugins' would be offered by the team so from square one you can do any of the folowing: RP, H/S, SCI-FI, add religion, add color, add classes, add skill tree, or add races. This is where the ideas become limitless as do the mud possibilities.

With a team ideas that others may not of thought of arise although a simple system of how to deal with the ideas would have to be handled (POLL?) it could just turn out to be something very interesting.

In conclusion yes I understand the problems and some of the past history of people who tried, but it can be worked out learn from their mistaks as well as our own!

The basic problem to solve is creating an architecture not content.  All of the above things you list are content and have nothing to do with designing an extensible generic mud pluginable mud server.  The above is not even close to square one, it's square 37.

This is a concept I would very much like to see work. It's probably a couple of years of effort at least (from a dedicated team) to get something looking remotely cool, but it could spark the next generation of muds. Muds that interrogate clients about what capabilities they have and arrange their output accordingly. Muds that all support the high end of presentation abilities (MXP, MSP, etc.) as well as some other, long-established protocols (curses has been mentioned a lot recently). Muds that have an established, easy to use, builder's scripting language with plenty of good examples available. Ah, the sky's the limit.

The only problems, as far as I can see, would be coming up with a standard to work to, and getting out of analysis paralysis.

Well, despite a lot of name-calling and bad blood that I've seen in the past, I think we all can thumb through the user list of this site and pick out say 5-10 of the more accomplished (publicly or privately) patrons, and then recommend them as starters for the project. Otherwise, someone else can go form a team and hope for the best as far as quality goes.

Anyone want to raise a hand to go recruit?

*puts hand on the floor*

-Visk

Well why not get a adequate team of coders started and have like 3 people for a head team to oversee the coders incase a ruling is needed. That way if the coders can't agree on something the head team can rule.

I know this is experimental, but if the right people decide to help and people can agree without large arguments this could be something worth while.

Anyone who would like to help or join or has an idea leave a message here or email me and we'll see what we have to work with.

I took the liberty of creating a small site.   If anyone is interested just hop on over to and start writing.

Tyche, I like what you have done to get the ball moving. Now lets hope that people will begin to join!

Thanks.  Which one are you over there?  I haven't had much time to read the various boards.  

Hmm.. This is an added bonus for the mud community and another good reason to join up.  If you can keep me occupied with a big project, then I won't be trolling and terrorizing the various mud forums.  ;-)

I'm just patrolling the boards staying quiet for the time being. It would be nice if some people would begin to volunteer. Though with everyone else nobody wants to do something good for everybody, instead they are worried about themselves and self-image.

I'll keep in touch...

With a few exceptions, it's the shyest group of mud programmers I've ever encountered.  You think maybe I should start hot chatting or stripping for everyone in order to break the ice?  ;-)

My son suggested putting skulls on the front page and embedding some music like Ramstein's "Ich Will" into the front web page.  I thought it was silly, but on second thought...