Much of this. I have enjoyed playing MUDs for some thirteen years now, and I've gone from playing on several to playing and staffing on a few to working on my own. I know that I am not the best coder in the world and I know that whatever product I create that may someday be open to public eyes will not have the brilliance under its hood that several other games represented on this forum will have - but the vision and creation are mine, and whatever time I have to plink at it will go towards something that is spawned of my brain.

I understand what you're saying, that fragmentation is a problem, and I agree that there are probably some people who say to themselves, "I have a good five hours every week that I can consistently dedicate to a MUD." and could do well to join with someone else's project instead of creating their own, but that's a very personal choice.

I think something that might be interesting would be to have a sort of looking-for-help database for games that actively want people to join as builders, miscellaneous staff or subordinate/training coders. I know there are the various staff request threads, but how many prospective builders come to a primarily-coding-site and go through no longer active threads to ask if the person still needs help? Anyone know if The Building Academy is still running and still gets any influx of people?

The problem with this is that it takes a lot of training and investment to bring somebody in as a coder; usually it involves giving them shell access and so forth, and people either can't do it or are loath to do so.

Contrast with much of the open source world, where the source is easily obtainable via public download or even full revision control. You don't even have to officially "bring somebody onto the team" – they can just submit patches.

IMHO this is why there is not much code collaboration: it's simply not very easy to do.

On my last 'live' MUD project (live in this instance meaning a functional game open to the public), I handled code collaboration much like a typical open source project. Source was available via a public read-only version control repository and anyone could submit patches to be reviewed. It made it easy for me to coordinate incoming changes from volunteers, but it did not alleviate much of the time investment in training new contributors.

I found that most of the 'mud coders' who were willing to contribute still had no experience with version control software or development in a team environment. Much of their willingness also disappeared if I merely directed them towards any sort of howto or other background reading to get them up to speed with the software and the process. The inexperienced contributors that stuck around only did so after a considerable amount of hand-holding and baby-stepping them through the whole process of checking out working copies from the repository, generating patches, and patch submission. For the one contributor who was already familiar with source control, it was a snap to get them involved – I pointed them to the repository and issue tracker and soon after had some incoming patches to review.

Well, there's a difference between making contributing easy, and teaching somebody how to program/use VCS/etc. I think it's quite reasonable for the head coder to welcome contributions without being willing to hold somebody's hand every step of the way. From a purely utilitarian point of view, the coder doesn't have a lot to gain by doing that other than being nice, I suppose.

Well, the fleeting "hiring pages" notion that spilled from my fingertips was really geared more toward building/staff - people who want to contribute to a MUD but don't know how to code their own (something we certainly see plenty of around here - they just think the solution is to code anyway). I'm not saying that wanting to run a MUD isn't a good reason for learning a coding language, but it's certainly less efficient to spend hours/weeks/months/years getting proficient with a programming language than it would be to join an existing team in some other capacity.

The problem, then, is that "help wanted" threads are fairly few and far between and quickly become out of date. The line you quoted (despite your appropriately not quoting the text regarding this) was really not aimed at getting coders.

I agree that it is reasonable to welcome contributions without being willing to invest in your contributors. If the goal is to increase collaboration then welcoming contributions may not be enough, especially in a narrow field like MUDs where, in my view, there are relatively few experienced developers.

In my case, the experience reaffirmed the old notion that version control systems are never a substitute for communication among developers. Having a low barrier to entry does much to help experienced developers get to work, but you will still need to expect to help less-experienced contributors along if you wish to receive their help.

Completely agreed. I'm just unsure how you get to the point where you have enough developers to communicate with. It's just not realistic to teach people how to program if they truly don't know how; that's a near-full-time job over many months (just look at university intro programming courses). It's more realistic to give somebody a little extra help for a few days/weeks as they learn the ropes of the particular codebase, but otherwise already know how to program.

Well, doesn't the topic title seem ironic now :lol:

When I made this part of the post, I meant to link to this thread. Yet another discussion of how developers should work together that eventuated to nothing, because it is an unworkable idea.

Reading other posts in this thread, brings me to one of many old proposals for connecting MUDs. And one of hundreds of past threads railing against the damage that undifferentiated/stock MUDs are doing. Or of a shortage of coders and whether there should be more proactive teaching.

How can the same sentiments what have been repeated here, be taken somewhere productive? Or is this just a bunch of dudes shooting the breeze?

This to me encapsulates the core problem.

Why on earth would they want to contribute to the work of others? Let's say they are working on the content for a given MUD, which they do not administrate. Then they are probably not allowed to start up a new MUD with the same content, when it comes to a point that they no longer find enjoyment in that MUD and its direction. So their work now effectively belongs to the person who administrates it. It has all been for nothing.

Really, it leaves "everyone" with only one option if they want to have a stake in the fruits of their labour. To start their own MUD.


This is pretty much every forum out there. But then again, what is the option? To amalgamate the results of every applicable discussion into a wiki?


No, this was not my suggestion. But my post was poorly worded.

I am saying that there is on some level a proportional representation for every MUD out there. Your decent MUD exists, and is one of N MUDs. Stock MUD X exists, and is one of N MUDs. So how to solve the problem of making your MUD more easily found, and doing so by raising its profile from a factor of 1/N to A/N where A > 1.

Of course, you can get players to review your MUD. And you can get them to vote on it, on whatever sites. And you can make an appealing web site. And you can make good use of the clients out there by exposing the metadata that they can make use of. Maybe even log on some fake players. Or lie in your advertisements. But these standard things have a limit of how high a factor they can effect your profile, once you have done all those things. You can try and raise the proportion of that factor you are taking advantage of, but at some level you are going to get diminishing returns. So now we have (1*fN)/N where fN has a independent value for each of the N.

So, what other ways thinking out of the box, can you raise your profile?

Well, what I was suggesting was that one MUD and its existing team could have data-driven content. So the same MUD could be visited, and it could appear to be a different MUD. Is it a practical to do this? Yes, I have worked on many similar systems. The main cost is in the extra content development – which might at the most simple approach be whomever describes the world filling out matching form entries for all related descriptions and names. With M "skins" in this manner, you now have (M*fN)/(N+M) profile and everyone else has (1*fN)/(N+M) profile.

Another more work intensive approach would to have the different MUDs that your game is published as be different areas in the same world, and potentially keeping that as opaque and indeterminate as possible to the players. This would require M distinctly different sets of content.

Now, I am assuming that if someone were to do this, they would present each MUD that is published as being a distinctly unique and isolated game. Different login screens. Different web sites. No advertised relation.

At no level, do I wish we could all hold hands and work together. People need their efforts to rewarded and worthwhile. Contributing effort to someone else's vision is not inherently that. It can be however, if the vision has a concrete form with players, and there is a reward in and of improving it because of that.

Right, I hope my last post clears up the difference in terms of the point I wanted to make.

Interfaces are one thing, but the primary intent was try and draw in more players through giving a MUD a higher presence (given the claimed predominance of lacklustre MUDs crowding our the ones in which quality effort has been put into).

In this way, you would still gain X many players for what was your only MUD. But you would also gain Y many players for the second publishing of it. Etc. If done right, the gain for one would not be at the loss of another of your publishings.

Anyway, this is just an idea. I think it is achievable, given that one has sufficient content creation resources at one's disposal. Is it worthwhile.. maybe not. But if you have a quality open MUD and the players are not coming, maybe.

I'm not suggesting you haven't invested a lot of time and effort into Lithmeria. What I'm saying is that you could just as easily have spent that time working on an existing mud. For example, there's a clear influence from the Avalon and IRE games on your design - what if, rather than creating a new mud, you'd worked on improving one of those older muds? You could have fleshed out the history, enlarged the world, improved the PK mechanics, and so on.

Likewise, rather than creating GW2, what if I'd spent my time improving one of the older muds? Perhaps redesigning the combat system on one of the better established HnS games, or integrating dynamic descriptions into one of the bigger RP muds, etc.

The point is that you can make the same argument about anyone. Sure we look at those stock muds and wonder why they bother, and we look at our muds and our visions and think of all the cool things we've got planned…but it's all relative. Those people with their stock muds have their own ideas and their own visions as well, and you're not going to convince them to give up their dreams any more than someone could convince you or I that we should discard our projects and invest our time into a more established mud.

As Raph Koster mentioned in the article I referenced earlier, "The thing is that people want to express themselves, and they dont really care that 99% of everything is crap, because they are positive that the 1% they made isnt."



One solution that springs to mind would be for someone (or a group of someones) to create, maintain and heavily promote an "elite mud list" - each mud hand-picked for its ability to fill a specific niche, ideally with balanced in-depth reviews of each entry.

This would require a huge amount of work, and would face a lot of opposition and criticism - not just from the many muds that would be excluded, but also from people who disagreed with the inclusion of certain muds, disagreed with criticism in the review/s of their mud, or simply disagreed with the "elitist" mindset behind the concept itself.

Perhaps it would be more viable if it wasn't quite as strict. To be included on the MudQuest list, each mud had to fulfill at least one of three quality criteria, and the emphasis was placed on the mud owner to demonstrate why their game should be included. MudQuest itself has long since ground to a halt, but I believe that was mostly due to the huge backlog of reviews. I think the workload could have been greatly reduced by requiring the owners to provide more extensive information and playing logs, allowing the reviewers to do little more than quickly check out the mud to make sure everything seemed in order.

In the past I've also discussed the idea of "one hour reviews", the idea being to pick a selection of muds, play each one for an hour, and describe my experiences. Of course many muds will object to this, with comments about how you have to play for X hours to really get into the game…but IMO, if you can't offer newbies a fun first hour, then you've got a serious problem - because most of them will be long gone before that hour is up. And as long as you make it clear that these literally are "one hour reviews", specifically intended to describe what you might encounter in your first hour of play, I think it would be difficult for people to level any real criticism at you.

I actually planned to do something similar for GW2. The idea was that each admin would have their own "minimud" - a separate port number, login screen, and themed starting world. Each minimud would have its own class selection, but after classing players could leave their realm and travel to the "Nexus" - the point in space and time where different realities meet.

Thus I was going to run "God Wars II: The Supernaturalis", with its traditional four GodWars classes of vampire, mage, werewolf and demon. Kastagaar (who is/was big on dragons) might run "God Wars II: Isle of the Dragons", with a selection of dragon-oriented classes. Another admin might run "God Wars II: Age of the Titans", another might run "God Wars II: The Elemental Planes", and so on.

Of course it would have been clear that they were all related, but the idea was to give each its own mud listing. I don't recall discussing websites, but I guess each could have had its own subdomain name, with links to the main metamud website.

However other than some initial testing of the concept, it never happened. It might have made a fun marketing gimmick, but I'm not sure it would really have added anything to the game.

I have no fewer than six dragons on my desk at work right now ;)

I do remember those "meta-mud" discussions on having the mud faux-separated/skinned. I still think it's a very interesting concept, though the implementation would be a lot of work. But realistically you could compare it to something like DAoC or even WoW, where a third (or a half in the latter case) essentially play a similar, but different game to the remainder.

The MUD would likely be free, so that would leave the people afraid of flying, or too stupid to fly. Fortunately those people are well accommodated by existing MUDs.


There would likely be a fantasy, sci-fi, forced rp, and pure pk version. The sci-fi version would eventually grow apart, but some effort could be made to borrow from each other.


This would be more of a MUD that people with little time can occasionally write some code for. I've had pretty talented programmers provide snippets for tt++ over the years. I'm not suggested to get rid of all MUDs.


I wouldn't mind if the new environment would be inviting and contributions are appreciated. There's a pretty good culture on most MUDs when it comes to building.


A better question would be if I'd contribute to mushclient if it accepted and implemented patches, and while I might be willing to add VT100 support to mushclient - it would never be included in the main branch. So knowing that I'm not even going to bother. Most project are very inaccessible, or have a big dog in charge with specific visions on what is hot or not.

TinTin++ fills a niche that isn't covered by graphical clients, if it was just a cheap rip-off of CMUD it might be a different matter. Regardless, I might spend some of my time on a group effort under the right conditions.

Aka not in my backyard.

I think you need to do a little work to establish that adding X skins effectively multiplies your exposure by X…

I'm not convinced that people will be fooled for longs that two games – behaving exactly the same but with different text, using what are effectively synonyms – are truly different and deserve equal publicity, play-time, etc.

It seems to be working quite well for Zynga with Facebook games, to the point where someone has created a Cow Clicker game to highlight the problem of all Zynga games: clicking pre-defined things at certain timed intervals; only with different skins on them. Identical game play, different skins. I'd say it works pretty well, as I'm sure Vampire Wars attracts many more teenage Twilight fans than Mafia Wars.

And you believe that such trivial reskinning is possible for the kind of game we're talking about?

A MUD is not a click-the-button game or a Mafia Wars. I'm not sure the comparison is terribly convincing.

Regardless, I still think that work needs to be done to establish that there is a linear relationship between the number of skins you (somehow) put onto the (entire!) game and game mechanics, and the exposure you get. The reason I ask this question is that it might turn out that you get more bang for your buck by working on different games in the first place. After all, as donky said himself, there is a considerable extra cost in content creation here.

When I first opened GW2 for (private) beta testing, I did so too early really. The basic mechanics worked okay, but the classes only had a handful of functional powers, there were only (as far as I remember) 3 types of mob, and the world was just one vast barren plain. After about 9 months of further work the playtesters had long lost interest - there just wasn't any real gameplay, and they no longer logged on.

So I spent 1 week stripping out all the unfinished stuff - the classes, the advancement, the mobs, all the help files for "future stuff", etc. Then I added some buildings, some new help files, polished off a few rough edges and advertised it as a new mud - a pure PK mud called Gladiator Pits III. I made it clear that it was a test engine for GW2, but it was advertised as a fully playable game, and people really liked it.

I've sometimes wondered about doing the same thing again - spend a week giving the codebase a new image, a new "skin", and advertise it as a brand new mud. Perhaps try out some of the wierd mud ideas I've often thrown around, and see how they work out in practice.

My main concern is that I'd end up cannibalising players from my "real" mud. But recently I've been wondering if it might be viable to create a simple fully graphical mud using a stripped down version of my codebase and a MUSHclient plugin. If it worked out, perhaps it could be turned into a browser (or android) mud.