[KaVir]

This thread is split from another discussion, in response to a couple of comments about developing a mud from scratch.

Originally Posted by Kylotan Of course, all those same code changes could have been applied to a completely fresh code base written from scratch in a few weeks these days, so it is bizarre that Locke is so attached to them.

Originally Posted by Kylotan Personally I would prefer to program a MUD from scratch in a different language these days - Moores Law means that we have almost 10,000x more CPU power these days compared to when DikuMud was released, so there's no need to code glorified telnet servers in C any more. But that's an issue for the Coding subforum.

Put simply, creating a mud from scratch requires more time, effort and skill than creating a mud based on an existing codebase.

Of course that doesn't mean that someone has less skill (or has invested less time) just because they started out with an existing codebase. What it means is that, from an entry barrier perspective, it is quicker and easier to get a game up and running if a big chunk of the design and development work is already done for you. And even in the long-term, starting out with an existing codebase can give you a big headstart, as long as you pick one that meshes fairly well with your design.

While it's true that modern computers have far more RAM and CPU power available today than they did in the 90s, that doesn't help you much if you're using a mud hosting service that charges based on RAM and CPU usage. And even if RAM and CPU aren't an issue, a creative mud developer should have no trouble coming up with interesting features to take advantage of the available resources - there's no excuse for squandering them on sloppy development.

Your choice of language is likely to be influenced by a number of factors, with each language having its pros and cons. There's no "need" to use C (or indeed any specific language) but that doesn't automatically make it a bad choice - perhaps you have own reasons for favouring it. Indeed, there's no reason why you even need to limit yourself to just one language at all, maybe you'd rather use a combination of two or three languages for different levels of development.

Finally, telnet itself is just a network protocol, it doesn't define or limit what you can or cannot do. There is nothing stopping you from using it for a fully graphical mud if you wish.

[Kylotan]

Of course it requires more time, initially. But, just as there usually comes a time to trade in an old and creaking car for a new one because fixing it becomes too cost-ineffective, a similar time approaches when you take code that has been hacked at for 20 years and replace it with something cleaner and more maintainable.

Let's not pretend the Diku/Merc family is great code - you and I may know our way around it but it's still a mess, with little heed to the advances made in software engineering over the last 20 years.

In particular next to nobody is coding in plain C these days except those writing OS kernels or code for tiny devices, and for good reason - it's much harder to maintain and extend than a higher level language is. It has a niche role in 2010 and rightly so.

There's no "need" to use C (or indeed any specific language) but that doesn't automatically make it a bad choice - perhaps you have own reasons for favouring it. Indeed, there's no reason why you even need to limit yourself to just one language at all, maybe you'd rather use a combination of two or three languages for different levels of development.

There are many good reasons not to use C for a MUD server in the 21st century. The biggest one is a lack of an actual string type, which makes it an absurd choice for a program that spends 90% of its time pushing strings around. Another one is the lack of container classes. Nobody should be fooling about with #LINK macros and structs filled with next and prev pointers unless they're writing a filesystem or something.

While it's true that modern computers have far more RAM and CPU power available today than they did in the 90s, that doesn't help you much if you're using a mud hosting service that charges based on RAM and CPU usage. And even if RAM and CPU aren't an issue, a creative mud developer should have no trouble coming up with interesting features to take advantage of the available resources - there's no excuse for squandering them on sloppy development.

It's not 'sloppy development', it's 'software engineering', making the most of the tools available to you to create the product you want. Seriously, people used to level the same criticisms at those who chose to use C in the 90s instead of writing in assembly. It's an old and tired argument and holds no water these days. Nobody is at serious risk of incurring significant CPU costs on modern hardware for this kind of network-bound application. Our MMO server software can host over 1200 people on one server without going above 20% CPU utilisation, and that's doing a hell of a lot more work per player than almost any MUD would, not to mention having many more players. If you're using significant CPU time for your MUD, in 99 cases out of 100 your algorithm is broken, which means you'd have the same problem in C anyway. Sloppy development is choosing to manage your own pointer-based linked lists in 2010 and needing to keep around a #CHECK_LINKS macro in case you messed up somewhere.

Finally, telnet itself is just a network protocol, it doesn't define or limit what you can or cannot do. There is nothing stopping you from using it for a fully graphical mud if you wish.

That's not really relevant. Hardly anybody will be doing that, and those who are won't be using Diku as a base. The point is, for a typical text-based MUD running over plain text commands over telnet and playable on a telnet client (or spruced-up equivalent), you don't need to be squeezing out extra performance in C.

We're in an age where people are writing high speed servers in Javascript and Python which can handle much more traffic than any DIKU mud has ever or will ever have to serve, and with the advantages of being superior languages for high level text handling. You could probably host a typical DIKU on your phone these days. Yet still we have people thinking that we need C because every cycle counts.

If someone really wants a Diku-style game, and doesn't care much about adding new features, then sure, there's no point starting from scratch. But your extensibility and maintainability is crippled by comparison. And I do think the mud community has suffered from failing to move beyond the code of the early 90s.

[KaVir]

Originally Posted by Kylotan Of course it requires more time, initially. But, just as there usually comes a time to trade in an old and creaking car for a new one because fixing it becomes too cost-ineffective, a similar time approaches when you take code that has been hacked at for 20 years and replace it with something cleaner and more maintainable

Source code doesn't suffer from wear and tear, and if you're not competent enough to maintain and update an existing codebase, the chances are you're not going to do any better by starting from scratch. Furthermore, your choices are not limited to "scratch" and "Diku" - there are dozens if not hundreds of codebases out there, some of them pretty modern, many with unrestrictive licences (or even public domain releases).

Creating a mud from scratch can be an enjoyable and rewarding project, but there seems to be a common misconception that it will automatically result in a better game. In fact, the only thing it guarantees is more work. If your main goal is just to create a fun, playable game, I would suggest going with an established codebase.

Originally Posted by Kylotan There are many good reasons not to use C for a MUD server in the 21st century.

As I said, there are both reasons for and against. Perhaps it's your strongest programming language. Maybe one of your main reasons for writing the mud is to keep your professional C skills sharp. Perhaps you've got a whole archive of old C code you've written previously that you can reuse to massively cut down your workload. You could also compile the mud as C++, using just a few of the features you think would make things easier - such as the strings and containers you mentioned.

Take a look at NakedMUD for example - it's a compact and efficient mud server written in C, but it also supports embedded Python, allowing you to develop your own mud without ever messing with the underlying C code unless you want to. LPmuds are a similar story with their division of C driver and LPC mudlib.

Originally Posted by Kylotan It's not 'sloppy development', it's 'software engineering', making the most of the tools available to you to create the product you want.

Software engineering doesn't mean investing time and effort into reinventing the wheel purely for the sake of using a cool "modern" language, particularly when the end result is identical to the original except for a higher running cost.

Identify what you want to do, and then decide on the appropriate tool for the job. Don't pick the tool before you even know what needs to be done.

Originally Posted by Kylotan Nobody is at serious risk of incurring significant CPU costs on modern hardware for this kind of network-bound application.

These are the hosting costs for MudMagic, where I used to host my mud:

Basic cost for 2% CPU usage and 15MB RAM: $8

Increase CPU to 3%, 4%, 5%, 6%, or 7% = +$1, +$1.50, +$4,50, +$6, or +$7.50

Increase RAM usage: +$1 per 5MB.

I notice you're hosted with Wolfpaw - I'm pretty sure they used to have a similar pricing system, although they don't appear to offer hosting to new customers any more, so I'm not sure what their prices are now.

There are of course commercial muds out there, but for most of us this is just a hobby - all costs come out of our own pockets, and there is no income from the mud to offset it. There are usually no overheads for development, testing, licencing, etc - but hosting is one area where you'll often need to pay. However if the price of hosting rises too high, it will eventually reach a point where the owner can no longer justify or afford the expense. This results in a very different set of priorities compared to a commercially developed software project.

Originally Posted by Kylotan That's not really relevant. Hardly anybody will be doing that, and those who are won't be using Diku as a base. The point is, for a typical text-based MUD running over plain text commands over telnet and playable on a telnet client (or spruced-up equivalent), you don't need to be squeezing out extra performance in C.

With recent advances in mud clients I wouldn't be at all surprised to see an increase in the use of graphics over the next few years - and as this is handled at the client end, the codebase is irrelevant.

[Graham]

Originally Posted by KaVir These are the hosting costs for MudMagic, where I used to host my mud: Basic cost for 2% CPU usage and 15MB RAM: $8 Increase CPU to 3%, 4%, 5%, 6%, or 7% = +$1, +$1.50, +$4,50, +$6, or +$7.50 Increase RAM usage: +$1 per 5MB. I notice you're hosted with Wolfpaw - I'm pretty sure they used to have a similar pricing system, although they don't appear to offer hosting to new customers any more, so I'm not sure what their prices are now.

That is pretty expensive to be honest. I'm not sure why these MUD hosting companies still exist now VPSes are more commonplace. I pay $20 a month for a Linux VPS with 512 MB of RAM for hosting my websites. It shares a machine with 20 others, so you are guaranteed to be able to use 5% of the CPU power in the worst case and most of the time you can use more. This would definitely be more than enough for a small MUD server, and probably enough for most of the larger MUD servers that are running.

Originally Posted by KaVir Source code doesn't suffer from wear and tear, and if you're not competent enough to maintain and update an existing codebase, the chances are you're not going to do any better by starting from scratch.

Lots of the codebases out there are pretty large and intimidating to someone that hasn't looked through them before. I think for a very large codebase (where you might only use a fraction of the available features) it could be easier to write your own one.

For example, I am programming my MUD server from scratch in Java but before I had a look at some of the existing codebases out there. CoffeeMUD has 370,000 lines of code and so many features that I wouldn't have required or used (or even known about). I think the only person that probably knows it very well is the author of it! Whereas if I make my own one, it's just got the things I require and I will know all of the code well enough to be able to develop features much quicker (once the 'core' code is done).

[Kylotan]

Originally Posted by KaVir Source code doesn't suffer from wear and tear, and if you're not competent enough to maintain and update an existing codebase, the chances are you're not going to do any better by starting from scratch.

The cost of code maintenance is not constant across all languages. It's much easier to maintain something written in a modern language like Python than to dig into a C app, especially apps that have to do low level things like manage their own intrusive linked lists (and sometimes use 'last' and 'prev' interchangeably - thanks, Smaug people).

Furthermore, your choices are not limited to "scratch" and "Diku" - there are dozens if not hundreds of codebases out there, some of them pretty modern, many with unrestrictive licences (or even public domain releases).

The original discussion was specifically about someone choosing to start up with a Diku. I would certainly hope that there are alternatives, and that maybe some of them are good, but unfortunately they have much less traction with the community. And I still wouldn't recommend anyone uses C; I'd suggest C++ as an absolute minimum for application development.

Software engineering doesn't mean investing time and effort into reinventing the wheel purely for the sake of using a cool "modern" language, particularly when the end result is identical to the original except for a higher running cost.

You talk as if other languages are inherently slow, and that C is inherently fast. Yet the libraries and runtimes that other languages use to get their work done are typically written in C, and written and tested by highly skilled people. These skilled people know full well how to use C, and yet choose not to where possible.

It's far faster, for example, to use a Python dict for object lookups based on a name than it is to do a linear search in a linked list in C for an object with that same string. Of course, someone with sufficient skill could write something broadly equivalent to a Python dict in C for your mud - after all, the Python dict is written in C. But Python already has it there for you. It's quicker both in terms of development time and in execution time. If you invest the extra development time you have a chance of coming close in terms of speed, a tiny outside chance of beating it in speed, but you'll never get that initial time back. Is it worth it?

Same thing goes for networking - why have a naive select() loop in C when you have a platform-independent equivalent that uses more efficient alternatives like poll() or event-driven I/O in Python? Why hand-code your own 25-line bubble-sorts as you see in Smaug when you can use the list sort() method in Python and get a more efficient mergesort algorithm into the bargain? This is the problem with low level code machismo - people write code that does the wrong thing quickly and think that they're saving on some mystical overhead.

Identify what you want to do, and then decide on the appropriate tool for the job. Don't pick the tool before you even know what needs to be done.

If what you want to do is "write an extensible and maintainable MUD server" then C is almost never the right tool these days. Almost every other mainstream language does it better. They have strings, they have containers, they have standard libraries that would condense about 50% of a typical Diku MUD into a few one-liners. C was the right tool when Diku started out so this is no criticism of the original authors. But we've learned a lot about how to write software since then, we've developed new tools that make it quicker, easier, and safer, and we have much better computers to run it on.

Basic cost for 2% CPU usage and 15MB RAM: $8

Today that is almost extortionate considering Google App Engine will give you 25% (of a 1.2 GHz processor) for free. If a host wants to charge $8 for various other maintenance costs, that's fine, but to pay $8 to share a server with 50 other games, none of which are allowed as much memory as even trivial desktop apps use today, then you're paying over the odds. Not that I think the CPU usage argument is a good one for choosing C, for the inefficiency reasons stated above. Admittedly you'd have trouble running a Python or Java server in 15MB but I think that's just an unreasonable expectation on the part of the hosts and that it's not worth enduring all the other pains of programming text applications in a systems language to cut a few megabytes of RAM.

[KaVir]

Originally Posted by Graham I pay $20 a month for a Linux VPS with 512 MB of RAM for hosting my websites.

That's pretty good, but do they permit you to host muds as well?

Originally Posted by Graham Lots of the codebases out there are pretty large and intimidating to someone that hasn't looked through them before. I think for a very large codebase (where you might only use a fraction of the available features) it could be easier to write your own one.

Depends on the documentation, but if the codebase you look at is too large and intimidating, you could just download a smaller codebase instead.

Don't get me wrong, I think it's great to see people creating muds from scratch. I just disagree with the idea that it should be done because it's easier than using an existing codebase.

Originally Posted by Kylotan The cost of code maintenance is not constant across all languages.

For a typical hobby developer, the cost of maintenance is indeed a constant $0 regardless of language - which is more than can be said for the hosting costs.

However if you're using a well-developed codebase, it shouldn't require much in the way of maintenance anyway. How often do LPmud developers need to maintain their drivers?

Originally Posted by Kylotan The original discussion was specifically about someone choosing to start up with a Diku.

A fair point, but you did also respond to the discussion by suggesting writing a mud from scratch as the alternative. My argument is that there are many other alternatives, and I wouldn't suggest starting from scratch purely because you don't want to use Diku, at least not without first considering the other alternatives out there.

Originally Posted by Kylotan You talk as if other languages are inherently slow, and that C is inherently fast. Yet the libraries and runtimes that other languages use to get their work done are typically written in C, and written and tested by highly skilled people. These skilled people know full well how to use C, and yet choose not to where possible.

The primary advantage of languages such as Python is in terms of development speed. If you're writing commercial software, faster development means it's cheaper to produce. If the codebase already has the core functionality you require, then you don't need to develop it yourself, because it's already been done for you. You don't see people taking large C programs and translating them into Python just for the sake of having them in Python.

Originally Posted by Kylotan If what you want to do is "write an extensible and maintainable MUD server" then C is almost never the right tool these days.

And what if you don't?

What if you want to write "a tiny and highly optimised mud server with embedded support for a high-level scripting language"?

What if you want to write "a fun mud using no more than 16K of source code"?

What if you want to write "a mud with processor-intensive functionality but a low hosting cost"?

What if you want to write "a mud that lets me showcase and/or reuse my extensive archive of C snippets"?

What if you want to write "a mud just like my favourite Diku derivative, but with a few changes here and there"?

Maybe you even just want to write "a mud in a particular programming that I personally enjoy using". As I said before, identify what you want to do first, and then decide on the appropriate tool for the job. If it really is simply the case that you enjoy programming in Python, and the mud is your hobby, then of course you should take that into account - the hobby isn't going to last long if you don't enjoy it! But even if you decide you want to write the mud in Python, that doesn't mean you have to start from scratch.

[Graham]

Originally Posted by KaVir That's pretty good, but do they permit you to host muds as well?

Yeah, you can basically do anything so long as it isn't illegal (although I think IRC servers aren't allowed in some of the data centres). What is also great with a VPS is you have root access and complete control over the system/the software on it. I probably wouldn't be able to host my MUD (when it is ready, if that ever happens ) on MUD hosting because it is written in Java as opposed to C.

[Aeran]

Originally Posted by KaVir For a typical hobby developer, the cost of maintenance is indeed a constant $0 regardless of language - which is more than can be said for the hosting costs. However if you're using a well-developed codebase, it shouldn't require much in the way of maintenance anyway. How often do LPmud developers need to maintain their drivers?

I looked into LPMuds a while ago out of curiosity. A LPMud "driver" could be compared to a Python interpreter or to a Java interpreter(the JRE).

A MUD that runs on a LPMud driver is written in the script language lpc, and lpmud people call the actual MUD code for a "library" or "MUD lib" or something like that.

So like Java developers wouldn't usually need to edit their Java interpreters, I doubt lpmud developers would need to edit theirs as the coding work would be done in the "MUD lib".

[Kylotan]

Originally Posted by KaVir The primary advantage of languages such as Python is in terms of development speed. If you're writing commercial software, faster development means it's cheaper to produce. If the codebase already has the core functionality you require, then you don't need to develop it yourself, because it's already been done for you.

For me the issue is maintenance. If you just want to run a Diku, fine. But as soon as you want to change something, you have to start getting your hands dirty. And the language you're using dictates just how dirty they're going to get. At some point, the linear cost of dealing with C code written in an inconsistent style over 20 years will exceed the constant cost of writing from scratch added onto the smaller linear cost of dealing with a MUD written in a higher-level language. I believe that point comes quite soon in the maintenance lifetime of a MUD (especially given that coders have always been hard to come by).

I'm not seriously arguing that everybody should be coding from scratch, just that it should be considered because it's not actually all that hard. I had basically 2 concerns which you quoted to begin with:

• Locke has an extreme attachment to his changes to Diku - yet anybody who is familiar with the productivity of a higher level language would find the argument laughable because there is so little functionality there. This is something that might be lost on C developers, especially amateur C developers who are only familiar with MUD coding.
• The MUD world has mostly relied on Diku derivatives for too long which has held back the wider community from making significantly more interesting games, due to the relative difficulty of extending and improving an old program written in C. This is just a bit of a shame really.

You don't see people taking large C programs and translating them into Python just for the sake of having them in Python.

The 'sake of having them in Python' is for maintainability and extensibility. That's why more and more game developers are embedding Python (or Lua, or whatever) into the apps. They don't need to, but they do, because it's simply better for the task. And over time what does actually happen is that code that used to be C code is replaced by Python code. It's a slow translation, but a translation nonetheless. Most of us don't want to be fiddling with typedef structs and #macros and the like forever so we gradually change our software to something that makes life easier.

And what if you don't? What if you want to write... <snip>

Your examples are all well and good but it's easy to come up with unusual or uncommon requirements if you're making something for vanity purposes. It doesn't change the underlying fact that a language such as Python is intrinsically better suited for networked text games.

What if you want to write "a fun mud using no more than 16K of source code"?

Far easier in Python than C, really. (I wonder how many besides you and I remember the 16k mud competition...)

[Parhelion]

Is it just me, or did this go from "why scratch" to, "RAWR PYTHON > C!!!!!"?

Language selection is an issue of personal choice when it comes to MUDs. We are not developing heavy or professional software that will be distributed to millions. And even if we were, language selection often is determined by the type of software you are making. C and C++ are used in intensive software such as professional games. C#, Java, Python, etc. are more often used in utility applications, where development speed and patch releases are a much bigger deal.

Can we please return to the original topic, now?

[ArchPrime]

My biggest argument AGAINST using an existing codebase --- specifically DIKU based -- is the damndable license. I have read more flamewars, taunts, hate posts, moronic wanna-be-lawyering and just plain old community disdain attached to just about any thread that deals with someone violating the license (or the spirit of the license) in some fashion. It makes one want to go out and write a server from scratch! ;-)

[Threshold]

Originally Posted by ArchPrime My biggest argument AGAINST using an existing codebase --- specifically DIKU based -- is the damndable license. I have read more flamewars, taunts, hate posts, moronic wanna-be-lawyering and just plain old community disdain attached to just about any thread that deals with someone violating the license (or the spirit of the license) in some fashion. It makes one want to go out and write a server from scratch! ;-)

That license is also what pretty much doomed MUDs to never be more than a niche hobby. Look at everything else that exploded on the internet. Most of it was open source and allowed people to take a concept, run with it, and if it did well commercialize it.

But for MUD designers, as soon as they could get a job anywhere else in the gaming industry they jumped at the chance. I've spoken to a lot of old game developers with 10-20+ years of experience over the past few years at gaming conferences and other gatherings, and it is a common point. MUDs were awesome, but since most people couldn't make a living at it they moved on. Some really brilliant programmers and designers totally left the MUD market out of necessity due to license limitations.

And as you mention, the flamewars and vitriol that evolved from the license issue was poison for our "community."

[KaVir]

Originally Posted by ArchPrime My biggest argument AGAINST using an existing codebase --- specifically DIKU based -- is the damndable license. I have read more flamewars, taunts, hate posts, moronic wanna-be-lawyering and just plain old community disdain attached to just about any thread that deals with someone violating the license (or the spirit of the license) in some fashion. It makes one want to go out and write a server from scratch! ;-)

Yesterday I posted a link to Tyche's list of open source mud servers. That's 46 muds that meet that requirements of OSI's Open Source Definition (meaning no restrictions on commercial use), ranging from barebones codebases like the public domain SocketMUD to feature-rich games like CoffeeMUD, with servers available in C, C++, Java, Python, Ruby and various other languages.

As an example, the barebones NakedMUD codebase (written in C and Python) was used as the starting point for Maiden Desmodus, with the owner choosing to do most of his work in Python.

[Kylotan]

Originally Posted by Parhelion Is it just me, or did this go from "why scratch" to, "RAWR PYTHON > C!!!!!"?

The only reason I seriously suggested developing one from scratch is because there are languages that make it easy to do so. Python is the one I know best, although there are many better than C, including Ruby, C#, Java, even Javascript...

Language selection is an issue of personal choice when it comes to MUDs.

If people want to make their lives harder by choosing a more difficult language to develop in, I'm fine with that. I just think it's time people realised that they could achieve a lot more with something other than C.

Can we please return to the original topic, now?

This is the original topic.

[Kylotan]

Originally Posted by KaVir Yesterday I posted a link to Tyche's list of open source mud servers. That's 46 muds that meet that requirements of OSI's Open Source Definition (meaning no restrictions on commercial use), ranging from barebones codebases like the public domain SocketMUD to feature-rich games like CoffeeMUD, with servers available in C, C++, Java, Python, Ruby and various other languages.

The problem has not been that these code bases never existed, but that the community for whatever reason has ossified around Diku derivatives to the exclusion of the others.

Perhaps the problem is that these other code bases don't support Diku/Merc/Smaug/whatever area files and building a world from next to nothing has always been very daunting. (Of course, that gets us on to a 'Building a world from scratch' thread...) Was there ever any progress on a universal file format for muds?

But it might also be that having a mud written in C is daunting to many people and so they just enter a cycle of relying on snippets and borrowed expertise to make tiny incremental changes to their game. By comparison, thousands of people who don't normally consider themselves programmers make server or client mods for WoW, Civilization 4, Baldur's Gate, Crysis, Oblivion, any of the Unreal-based games, etc., since they have an easier language to work with.

[KaVir]

Originally Posted by Kylotan If people want to make their lives harder by choosing a more difficult language to develop in, I'm fine with that. I just think it's time people realised that they could achieve a lot more with something other than C.

The programming language is just a tool, and what you can achieve with it is limited only by your skill.

Originally Posted by Kylotan The problem has not been that these code bases never existed, but that the community for whatever reason has ossified around Diku derivatives to the exclusion of the others.

It's the "familiarity" thing. It's a commonly made observation that players will use their first mud as the measuring stick when judging other muds - if their first mud was a SMAUG, for example, then they're probably going to stick with SMAUGs. They might try a ROM or Envy, because they have a somewhat similar feel (due to all being derived from Merc). They're less likely to try a Circle or Silly, but they might. They're even less likely still to play an LPMud or a MUSH. Even players who complain about stock features, demanding something new and original, rarely want something that deviates too much from what they're used to.

The same holds true when it comes to creating a mud. The budding mud owner has a general vision of what s/he wants to create, and that vision will almost always be in terms relative to their former mud. If they're from a Diku background, then in most cases they'll want to create something very much like their former DikuMUD, and so it makes sense to simply download DikuMUD as a starting point. The same with LPmuds, MUSHes, and so on. It's a very difficult mindset to break out of, particularly if all your experience comes from just one mud.

If you look at the people creating muds from scratch, in many cases you'll find that they're former players of a mud that isn't available for public download. An obvious example of this would be Avalon, which inspired the IRE games, which in turn have inspired several more muds. Sooner or later one of those muds will lower the entry barrier by releasing its source code, and then you'll see a surge of "stock" Avalon-style muds.

Originally Posted by Kylotan Perhaps the problem is that these other code bases don't support Diku/Merc/Smaug/whatever area files and building a world from next to nothing has always been very daunting.

I've seen a few muds that can import them, including CoffeeMud. It seems fairly unlikely to me that someone who's willing to move away from Diku would want to have a stock Diku world, though.

[Kylotan]

Originally Posted by KaVir The programming language is just a tool, and what you can achieve with it is limited only by your skill.

I look forward to hearing about your future career in digging tunnels with spoons.

It's not just about what is possible - it's about how long it takes to get there!

The same holds true when it comes to creating a mud. The budding mud owner has a general vision of what s/he wants to create, and that vision will almost always be in terms relative to their former mud. If they're from a Diku background, then in most cases they'll want to create something very much like their former DikuMUD, and so it makes sense to simply download DikuMUD as a starting point. The same with LPmuds, MUSHes, and so on. It's a very difficult mindset to break out of, particularly if all your experience comes from just one mud.

Do you think the mud community is more conservative in this regard? In other areas of games and hobbyist game development, the problem seems to be more the other way - people are too quick to move to something newer and shinier. People start a mod based on one game, then another will get released and they'll flock to the new game and port the mod over, often never finishing it because they keep rewriting. (To be fair it's not just hobbyists that do this, either. 3D Realms and Ion Storm come to mind.)

If you look at the people creating muds from scratch, in many cases you'll find that they're former players of a mud that isn't available for public download. An obvious example of this would be Avalon, which inspired the IRE games, which in turn have inspired several more muds. Sooner or later one of those muds will lower the entry barrier by releasing its source code, and then you'll see a surge of "stock" Avalon-style muds.

How often has this happened over the years? I haven't really heard of there being a significant surge of any brand of stock mud since the Smaug days. A rudimentary sampling on Mudconnect.com suggests LP and Circle are the most popular, which suggests that there hasn't been much change over the years. (Incidentally, is there a good list of muds categorised by codebase, or by any other criteria? The search engine on Mudconnect is awful.)

I've seen a few muds that can import them, including CoffeeMud. It seems fairly unlikely to me that someone who's willing to move away from Diku would want to have a stock Diku world, though.

It's useful for bootstrapping purposes to have a decent data set ready to play with from day one. And personally I would quite enjoy playing through all the old favourite areas with new rules and an improved interface.

[KaVir]

Originally Posted by Kylotan I look forward to hearing about your future career in digging tunnels with spoons. It's not just about what is possible - it's about how long it takes to get there!

Well I've written two muds from scratch, so I think I've got a fairly good idea of what's involved and how long it takes.

Originally Posted by Kylotan Do you think the mud community is more conservative in this regard? In other areas of games and hobbyist game development, the problem seems to be more the other way - people are too quick to move to something newer and shinier. People start a mod based on one game, then another will get released and they'll flock to the new game and port the mod over, often never finishing it because they keep rewriting.

Bartle wrote an article a few years ago that mentioned much the same issue: Why Virtual Worlds are Designed By Newbies - No, Really!

In particular:

"The market for regular computer games is driven by the hardcore. The hardcore finishes product faster than newbies, and therefore buys new product faster than newbies. The hardcore understands design implications better than newbies. They won't buy a game with features they can see are poor; they select games with good design genes. Because of this, games which are good are rewarded by higher sales than games which are bad.

In virtual worlds, the hardcore either wanders from one to the next, trying to recapture the experience of their first experience or they never left in the first place. Furthermore, in today's flat-fee universe, the hardcore spends the same amount of money as everyone else: developers aren't rewarded for appealing to the cognoscenti, except maybe through word of mouth that always comes with caveats (because of point #3)."

Originally Posted by Kylotan How often has this happened over the years? I haven't really heard of there being a significant surge of any brand of stock mud since the Smaug days.

SMAUG was pretty big when it came out - but then it was spawned from a big mud. All those Realms of Despair players suddenly had the opportunity to own their own version of their favourite mud, fully functional out-of-the-box with no programming skill required. It was the same to a lesser extent with GodWars - all of those early GodWars muds were run by former players of the original God Wars mud, who suddenly had the chance to be the king of their own little kingdom.

To repeat the process again would really require a big mud to release its source code. That would probably be rather undesirable.

Originally Posted by Kylotan A rudimentary sampling on Mudconnect.com suggests LP and Circle are the most popular, which suggests that there hasn't been much change over the years.

There seem to be more custom muds today than there were in the past, but these require more effort to get up and running - I've followed a number of custom muds that showed promise but sadly never quite made it.

The three main Aber-inspired mud families (Diku, LPmud and Tiny) have never really mingled much, and that hasn't changed. But Diku is probably still the easiest to get up and running. Cratylus did try to lower the entry barrier for LPMuds, but as far as I'm aware LPMuds are still the least numerous of the three.

Originally Posted by Kylotan (Incidentally, is there a good list of muds categorised by codebase, or by any other criteria? The search engine on Mudconnect is awful.)

TMC or here are about the best you're going to get.

Originally Posted by Kylotan It's useful for bootstrapping purposes to have a decent data set ready to play with from day one. And personally I would quite enjoy playing through all the old favourite areas with new rules and an improved interface.

Diku areas don't require specialised technical skills to create, they don't impact the familiarity of the mechanics, and they're thoroughly paraded in front of the players. As such, the stock areas are often one of the first things people start changing if they start up a new Diku mud.

That aside, if you're creating an original custom mud then the hardcore Diku players probably won't like it - so you'll be marketing your game at those who are willing to try something different. If the first thing they see when they connect is stock Midgaard, the chances of them staying are minimal.

[Ide]

Originally Posted by Kylotan (Incidentally, is there a good list of muds categorised by codebase, or by any other criteria? The search engine on Mudconnect is awful.)

You can filter by a wide variety of criteria at Mudconnect's advanced search.

mudconnect.com: The Mud Connector - Mud and RPG game index, mudlist and reviews

[Kylotan]

Ah, I just hadn't thought of leaving the keyword field completely empty.

[Parhelion]

Like many others, it appears, I've been working on my own game for quite some time, and I'm challenged by having to write from scratch.

There are two main reasons I'm going with scratch:

1. No MUD codebase that I've found thus far has an agreeable license; too many good licenses even make donation for the sake of upkeep illegal, and I would like to have the OPTION of accepting donations, merchandising, or investing into a related business without having the entire community come down on my head for it.

(( As for the Open Source link that was posted, very few of the games listed there linked to a working page or download link; with no contact, there's no way of tracking those codebases down, thus making listing them rather moot. ))

2. No MUD codebase really offers what I'm looking for in terms of features. I'm not looking for stock, but I'd gladly rip out world content if that was my only barrier. A few games do offer -some- of the mechanical feature sets that I'm looking for, but are done so in a complicated manner or in a way that would make adding other features a headache. We have a truckload of codebases and MOST of them work almost precisely the same (or so it would seem).

[KaVir]

Originally Posted by Parhelion Like many others, it appears, I've been working on my own game for quite some time, and I'm challenged by having to write from scratch.

Challenged in a good way, or a bad way? I found the first year really hard to keep motivated - I actually stopped working my mud a couple of times, and nearly gave up completely, as I just didn't feel that I was making any progress. But once I had enough in place to start bringing in playtesters it got a lot easier.

I think this is one of the areas where it can be really beneficial to start out with an existing codebase, even if it's something barebones - NakedMUD, ColdMUD, LPMud, etc. These can all speed up the initial development without forcing lots of unwanted features on you, allowing you to get something available for playtesting before the honeymoon phase wears off.

It wasn't so bad with Gladiator Pits, as the mud was pretty small, and I was able to finish it off within a few months. But when it takes longer than that, that's when most scratch-written muds seem to start dragging their heels - muds such as The Cathyle Project or The Inquisition II, which showed incredible promise, but ground on so long that their developers lost interest.

[Threshold]

Originally Posted by KaVir Yesterday I posted a link to Tyche's list of open source mud servers. That's 46 muds that meet that requirements of OSI's Open Source Definition (meaning no restrictions on commercial use), ranging from barebones codebases like the public domain SocketMUD to feature-rich games like CoffeeMUD, with servers available in C, C++, Java, Python, Ruby and various other languages.

That's awesome. It is too bad we didn't have that 10+ years ago when MUDs could have really taken the internet by storm.

[Newworlds]

Originally Posted by Threshold That's awesome. It is too bad we didn't have that 10+ years ago when MUDs could have really taken the internet by storm.

Agreed. You have to admit most of the "out of the box" MUDs are what proliferated the MUD market making it very hard for players to find quality text games.

[KaVir]

Well 10 years ago we had the 16K MUD competition - 18 barebones codebases written from scratch. But I'm not aware of any muds built on them, other than a very recent adaption of the winning entry that's being used to demo a new web client.

And even today, despite the availability of all those open source codebases, most of the new muds starting up choose to go with one of the older established codebases. Right now on TMC's "new muds" list there are:

3 LPMuds
13 DikuMUDs
16 TinyMUDs (15 if you don't include MOO)
3 CoffeeMUDs
3 Custom
4 Unknown

The presence of open source codebases doesn't change the fact that most up-and-coming mud owners already have a good idea of what sort of game they want to run...and it's usually just like the mud they used to play, except with their own "cool idea" that's going to make it ten times better.

Change takes time. You need to wait for a generation of new mudders to grow up on custom muds, and then use those as their measuring stick.

[Aeran]

Originally Posted by KaVir And even today, despite the availability of all those open source codebases, most of the new muds starting up choose to go with one of the older established codebases. Right now on TMC's "new muds" list there are: 3 LPMuds

I don't think LPMud is a codebase - it is more of a runtime. You could write a MUD from scratch and then run it on a LPMud interpreter. You would have to look at what library is used to determine what the actual "codebase" is.

Edit: Found the new MUD list. One of the LPMud libraries appear to claim to be "custom" while the other two use already existing libraries.

[KaVir]

Originally Posted by Aeran I don't think LPMud is a codebase - it is more of a runtime.

I'm just listing the muds based what they wrote in their own "codebase" fields.

The advantage of using an existing LPMud driver is that it handles the low level stuff for you - much like using NakedMUD, or IRE's engine, or ColdMUD, etc. However the LPMud drivers often come with restrictive licences (for example DGD used to cost $100K/year for commercial use). What I'm trying to point out is that there are plenty of alternatives that don't have restrictive licences.

And sure, you could write the driver as well, but then you're literally writing everything from scratch. The point I'm making is that you don't need to start from scratch just to avoid restrictive licences. You can, if you want to, but there are plenty of options there if you'd prefer to skip over the low-level stuff and get right onto the game building.

[Newworlds]

Originally Posted by KaVir And sure, you could write the driver as well, but then you're literally writing everything from scratch. The point I'm making is that you don't need to start from scratch just to avoid restrictive licences. You can, if you want to, but there are plenty of options there if you'd prefer to skip over the low-level stuff and get right onto the game building.

I totally agree with this. There are numerous free options without licenses to attach onto. Who would write from scratch. It would be years before they finished and by then they'd need to start over because of variences in style, code, and languages which caused them to write from scratch in the first place.

[Threshold]

Originally Posted by KaVir And even today, despite the availability of all those open source codebases, most of the new muds starting up choose to go with one of the older established codebases.

Indeed. But imagine if the codebases available 10+ years ago were the open source ones, rather than the ones with restrictive licenses. I think the history of MUDs and their viability/success would have been much different (and better).

[Aeran]

Originally Posted by Newworlds I totally agree with this. There are numerous free options without licenses to attach onto. Who would write from scratch. It would be years before they finished and by then they'd need to start over because of variences in style, code, and languages which caused them to write from scratch in the first place.

You can make a basic MUD codebase very fast though. If you aim to make a new MUD that isn't just the "stock MUD experience" then chances are you would have to throw away a lot of a pre-written codebase anyway.