Top Mud Sites Forum

Top Mud Sites Forum (http://www.topmudsites.com/forums/index.php)
-   MUD Coding (http://www.topmudsites.com/forums/forumdisplay.php?f=9)
-   -   Developing from scratch (http://www.topmudsites.com/forums/showthread.php?t=6163)

KaVir 07-30-2010 05:51 AM

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

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 07-30-2010 07:00 AM

Re: Developing from scratch
 
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 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.

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.

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 and 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 07-30-2010 08:39 AM

Re: Developing from scratch
 
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.

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.

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.

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.

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 07-30-2010 09:20 AM

Re: Developing from scratch
 
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.

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 07-30-2010 09:43 AM

Re: Developing 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).

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.

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.

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.

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 07-30-2010 10:50 AM

Re: Developing from scratch
 
That's pretty good, but do they permit you to host muds as well?

Depends on the documentation, but if the codebase you look at is too large and intimidating, you could just download a 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.


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?

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.

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.

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 07-30-2010 11:14 AM

Re: Developing from scratch
 
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 :p) on MUD hosting because it is written in Java as opposed to C.

Aeran 07-30-2010 11:22 AM

Re: Developing from scratch
 
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 08-02-2010 01:00 PM

Re: Developing from scratch
 
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:
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.

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.

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

Parhelion 08-02-2010 08:49 PM

Re: Developing from scratch
 
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 08-03-2010 12:59 AM

Re: Developing from scratch
 
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 08-03-2010 03:51 AM

Re: Developing 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 08-03-2010 04:56 AM

Re: Developing from scratch
 
Yesterday I posted a link to Tyche's list of . 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 , with the owner choosing to do .

Kylotan 08-03-2010 05:29 AM

Re: Developing from scratch
 
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...

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.

This is the original topic.

Kylotan 08-03-2010 05:47 AM

Re: Developing from scratch
 
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 08-03-2010 06:37 AM

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

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.

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 08-03-2010 07:25 AM

Re: Developing from scratch
 
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!

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.)

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.)

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 08-03-2010 08:48 AM

Re: Developing from scratch
 
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.

Bartle wrote an article a few years ago that mentioned much the same issue:

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)."


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.

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.

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

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 08-03-2010 10:32 AM

Re: Developing from scratch
 
You can filter by a wide variety of criteria at Mudconnect's advanced search.


Kylotan 08-03-2010 10:36 AM

Re: Developing from scratch
 
Ah, I just hadn't thought of leaving the keyword field completely empty.

Parhelion 08-03-2010 12:20 PM

Re: Developing from scratch
 
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 08-03-2010 06:09 PM

Re: Developing 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 08-03-2010 09:35 PM

Re: Developing from scratch
 
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 08-04-2010 02:09 AM

Re: Developing from scratch
 
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 08-04-2010 04:56 AM

Re: Developing from scratch
 
Well 10 years ago we had the - 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 08-04-2010 07:59 AM

Re: Developing from scratch
 
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 . One of the LPMud libraries appear to claim to be "custom" while the other two use already existing libraries.

KaVir 08-04-2010 08:38 AM

Re: Developing from scratch
 
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 08-04-2010 12:38 PM

Re: Developing from scratch
 
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 08-04-2010 02:55 PM

Re: Developing from scratch
 
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 08-04-2010 05:07 PM

Re: Developing from scratch
 
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.

Kylotan 08-04-2010 06:32 PM

Re: Developing from scratch
 
This was exactly my original point. I think people overestimate how much work a basic MUD is, because they look at something like Smaug and see how big it is. But sure, if you only have a couple of hours a week, or programming isn't your main skill, then it'll take quite some time to get anywhere.

KaVir 08-04-2010 07:07 PM

Re: Developing from scratch
 
In my experience it's usually the other way around - people underestimate how much work it takes to create a fully playable mud from scratch. They'll often view it from a purely technical perspective, without stopping to consider that that's one of the easy parts.

As a result you see quite a few people start work on creating a game from scratch, but few who actually succeed.

Kylotan 08-04-2010 08:25 PM

Re: Developing from scratch
 
The content itself is indeed a big problem; can't deny that. Not just rooms, mobs, and items, but skills, spells, commands, help files, etc. Still, I think there's scope for working smarter rather than harder in these areas.

Newworlds 08-05-2010 02:48 AM

Re: Developing from scratch
 
Amen. This is so completely true I think those that are arguing in this thread on how easy it is to develop a mud from scratch are extremely naive or think that having a few rooms with a simple say command is a viable MUD. I glance at the detailed combat in God Wars II and have to laugh at someone thinking they can duplicate that from scratch without a problem.

NWA is 12 years in development now, having utilized over 20 builders, 15 staff members, and tens of thousands of hours in development and we still find things that could be better. The sea faring code alone took months to create.

So, if you really want to build a MUD from scratch, creating the drivers, libraries, and rooms. Come back here in a few years and make a comment on how easy it was.:cool:

Milawe 08-05-2010 02:54 AM

Re: Developing from scratch
 
In addition to all of the skills, descriptions, etc., one of the biggest problems in most mud is the actual gameplay and game design. A lot of coders think of the code and the "cool" factor of having this or that feature, but how does it all fit together? Regardless of whether the game is hack 'n slash, RP-whatever, or PK, the design goals of the game should be laid out and determined, and I think that's probably the biggest challenge of developing from scratch. In most pre-made codebases, your gameplay is already somewhat designed and laid out for you. That's not true if you're developing from scratch unless you copy the features of another codebase. At that point, you might as well not develop from scratch. :)

Milawe 08-05-2010 03:01 AM

Re: Developing from scratch
 
It's easy! It only took us 6 years to build Primordiax from scratch and write a completely new driver in PIKE, design the map, plan the gameplay, build the mudlib, write the lore, write all the help files, design and predict the economy, code a custom client, create the website...

I won't even get started on the stuff that we've had to overcome once the mud opened.

Newworlds 08-05-2010 03:08 AM

Re: Developing from scratch
 
Don't forget your team of coders, creators, and staff. Remember, you cheated, you have to do this single handedly all within a couple of months. :p

Aeran 08-05-2010 04:58 AM

Re: Developing from scratch
 
In my opinion that is making a new MUD, and is how more MUDs should be created. Even if you start from a stock MUD you should have some plans on how the game play should work and decide how to make the game a bit different from other MUDs.

I wrote earlier that a "basic MUD" is fast to create. With that I did not suggest a MUD with all features but one that got the basics but also use lot of simplifications that you would continue to develop the game on.

Did you write an actual LPC interpreter in PIKE?

Milawe 08-05-2010 05:26 AM

Re: Developing from scratch
 
No, we didn't. I had to learn PIKE to do advanced building on Primordiax. PIKE itself is an interpreted language. You can read about the history of PIKE .

We actually wrote our mudlib in PIKE. Maybe I shouldn't say mudlib since that's a very LPC term, but the entire game is written in PIKE. Hope that helps.

Kylotan 08-05-2010 05:37 AM

Re: Developing from scratch
 
You've raised the bar somewhat by citing God Wars. The generic Merc/Envy/Rom/Smaug combat system however is a trivial (and unbalanced) copy of what is now called the d20 system, for instance. That is easy to duplicate - a different linear change in thac0 for each class based on level, armour balanced so that an almost-full set gives you an AC value proportional to your level, and a random number from 1 to 20 used when comparing the two to determine a hit or a miss.

I ripped out the combat system from an Envy MUD back in 1997 and completely replaced it with an entirely new system that was better balanced (including converting player and area files), and it took me a couple of weeks, back when I wasn't very good at C. There are lots of rule systems around, or you can stick with d20 if you like. Sure, making a game perfectly balanced isn't easy. Luckily virtually none of the stock mud codebases, which is what was being compared against, actually have balanced systems. Take a look at the values that go into the combat - you're clamped up against the top limit with a 95% chance of hitting all the time in most Diku derivative games once you're past level 12 or so with a decent set of equipment.

I'm happy if you guys want to continue insisting that doing this sort of thing takes years. At hobbyist rates of a few hours a week then maybe it does. But some of us are pretty good coders and also good designers and it really doesn't take that long to code a basic but functional mud engine if you know what you're doing. No, of course I'm not claiming it will be exactly as good as a mud you've spent 12 years coding and building on. How could that possibly be measured? But you can replicate 80-90% of a stock Diku's code functionality in well under a month using a modern language with modern libraries. In fact, as I understand it, the original Diku was put together - not just code, but the design too - in under a year in people's spare time. So why the pessimism now?

Milawe 08-05-2010 06:02 AM

Re: Developing from scratch
 
It would be awesome to do it in a few weeks or even months, but I'm not sure how you would accomplish that and have any kind of an original game. I think that if you completely copied the game designs of another codebase, then maybe it wouldn't take as long, but you would still have all the time spent in creating the content of the game. If you have anything more than "This is a sword. It stabs things." or "This is a garden room. It grows things.", that alone would still take a long time for a good size game.

We could be talking about completely different types of games, though. For Primordiax, we had to write the lore, which is completely original which, in and of itself, required us to establish a detailed timeline. The driver was being coded at this point which included connecting and all your basic commands. Then the wold map was designed. Then we had to decide what parts were given to the player, what parts were to be discovered in game, and then what parts were possibly never to be discovered. Then we designed many of the game systems around the lore. Then we generated the world map and created the three city maps. Then we coded the backbone of the systems which included combat, crafting, guilds, buffs, grouping, mob AI, skill trees, collectibles, task system, quest system, achievement system, etc. Then we had to design, describe, and code all the content for those systems. Then we had to code the three cities and their contents. I'm just going to stop there for now because the list goes on and on before we even start to try getting players.

I don't think I really see this as pessimism, though, but a description of what CAN go into building a game from scratch. I understand that many developers choose to get the basics in, develop a few areas, and then throw open the doors. I'm not sure that I think that's the best way to open a new mud and may perhaps kill several infant muds before they really have a chance.

You're right that a decent engine doesn't take that much time to code. It took far less time to code the engine than it did to design and code the game and its systems. I would never presume to tell you that the game is better than a game that was coded in a few months or a year. Time spent on something is definitely not the determining factor of how good a game is. Duke Nukem Forever was in development for almost 13 years, and I can't say that it was better for it... since it never got released. :)

KaVir 08-05-2010 07:38 AM

Re: Developing from scratch
 
That's exactly what I used to think, too. In fact the original plan for God Wars II involved only 3 months of development prior to beta testing.

It actually took 11 months, and the gameplay was still so basic that the beta testers soon lost interest and quit. After another 9 months I realised that I'd opened prematurely, so I spent 1 week creating another spinoff mud to test the engine - a much simpler pure PK game that had no mobs or character advancement, just player-versus-player combat.

It wasn't until after another 21 months that I finally had enough infrastructure in place to start properly beta testing God Wars II - that's a total of nearly 3.5 years development just to reach open beta. The mud then spent another 5 years in beta before I felt it was functional enough to be labelled "fully playable".

To put that in perspective with my earlier projects:

Creating a 16K mud from scratch: About 1 month of design, development, refactoring and testing, including extensive documentation.

Turning the above into a 7000-line pure PK mini-mud: Around 5 months, with most of the effort spent testing and reworking the mechanics.

Creating a fully playable game: Around 1.5 years of design and 8.5 years of development.

You want to know why the fully playable game took so long? Read my , and perhaps you'll get an idea of the sheer scale of it.

Producing a fully playable game from scratch is not a short-term project, but many people don't seem to believe that until they've actually tried it themselves. And of course most of them fail...which is a real shame, because some of the projects I've read about showed incredible promise.

Aeran 08-05-2010 08:32 AM

Re: Developing from scratch
 
Most who claim it can be done fast also links the word "basic" to the engine it would create though.

I read that one of the first compilers took 11 or so staff years to develop. One of the reasons it took that long was because it was a new field. Now there's a lot of nice theories and even tools to help develop compilers so that the time to make one is decreased. It should be similar for MUDs.

You often see claims such that the wheel shouldn't be reinvented associated with suggestions to use a stock MUD. That comparison is not correct because what is not reinvented is what a wheel is. People still keep making new wheels using the how-knowledge of the past. If you know how to make a MUD you could write any MUD you wish to create - but if you only know how to use already made MUDs then you are stuck on relying on what others provide.

scandum 08-05-2010 08:38 AM

Re: Developing from scratch
 
You do over 90% of the work on GodWars II Kavir?

If you have several skilled and experienced people it should be possible to make fast progress.

KaVir 08-05-2010 09:17 AM

Re: Developing from scratch
 
"Basic" is a relative term. This thread start out discussing muds comparable to Diku derivatives in terms of gameplay - that means a fully playable game. Producing a fully playable game is not a short-term project.

There was also some discussion about not wanting to be tied to pre-existing features. Producing a generic underlying codebase or driver for a mud is obviously less work than creating a full game, but there are already numerous options available that don't impose restrictive licences, don't force specific features on you, and which could save you months or even years of work.

And as I pointed out before, the first few months are crucial, particularly for a hobby mud. That's your honeymoon phase, when it's all new and exciting, and motivation is high. What happens when the honeymoon phase is over, and you've still got nothing operational?

I'm not saying you shouldn't start from scratch - that would be hypocritical. All I am saying is that it will take more time and effort than creating a mud using an existing codebase, and based on my past observations there will be a much greater chance of your mud failing.

No. You can create any mud you wish, from any codebase you wish - you are only limited by your time and skill, and starting from scratch requires more of both. Obviously it's far better to pick a codebase that meshes well with your vision of the mud, and in some cases that may mean going for something fairly barebones. But the only real reason to create a mud from scratch is because you want to. It can be kind of fun, after all! But recognise that it will not make your game better, or more original - all it will do is increase your workload.


Yeah, my management skills suck though. My staff tend to disappear.

I'm trying to push more in the direction of player-generated content, hopefully that'll speed up progress somewhat.

ArchPrime 08-05-2010 10:18 AM

Re: Developing from scratch
 
I started coding AoA in July of 2008 from scratch. By December of 2008, the game was in "test" -- and in February of 2009, it went live to production. Not only did I write the game single handedly, but the Flash client as well. Oh, and that was "part time" since I had to work a real job 40+ hours a week, spend family time with the wife and kids, and take care of other personal affairs. Let me also note that all the graphics for the Flash client were done solo(by me), too. As was the website and content supporting it. These things were all "done" (to the degree they were releasable) within a 6 month window, and polished for another 2 before opening. So, writing a MUD from scratch in a short time is completely doable. However, it certainly is no small task.

I have to agree with whomever (Kylotan?) posted that language and tool choice makes a world of difference.

I caveat this with saying that what AoA is today is definitely heads and tails over what it was a year ago. Regardless, if I would have cut out the custom client/protocol/gfx/website and left the game wholly telnet, I can say with a high level of confidence that I would have had the game from scratch to a decent release candidate in a couple of months. It really depends on how pedantic you want to get on terming a MUD as "release-able" and I personally feel that MUDs, by their nature, are in "constant development" ....

KaVir 08-05-2010 11:15 AM

Re: Developing from scratch
 
I agree that a mud is in constant development, which is why I didn't use the term "release-able", but "fully playable". Obviously the value of that term is relative, too - technically my 16K mud was fully playable, but it wouldn't have kept people entertained for long.

Within the context of this thread, we're comparing "starting from scratch" against "using an existing codebase", therefore it makes sense to compare equal feature sets. If you want features X, Y and Z, you need to compare the effort involved in writing them from scratch against the effort involved in downloading and modifying a codebase that has some or all of those features built-in.

ArchPrime 08-05-2010 12:03 PM

Re: Developing from scratch
 
Ah. Release-able to me is fully playable. And fully playable means people can create characters, join guilds/classes, beat up mobs, find and sell loot, work a puzzle or three, explore a world (albeit a "small" world... 1000 < rooms < 3000), interact with the world through a multitude of commands, etc. I think the general perception is that "release-able" means you can log in and "walk" between two rooms.... and that's about it. That is certainly NOT what I am referring to.

Anything pre-built is obviously going to have the upfront time advantage over something you must build yourself. And, building it yourself does not guarantee that you're going to lower your overall maintenance costs (time/money/however you measure "cost"). I have to agree 100%: if a person finds a codebase that meets all their needs, they are going to have a better time at it as they really only need to create content at that point in time.... still no easy task.

One a side note:
I still rail heavily against the concept that its impossible (or almost impossible...or whatever sort of impression folks like Newworlds are trying to imply) to write a "playable" MUD within of couple months, from scratch. "Time" in development is not a good indicator of feature set quantity or feature set quality, either. Stating that you've had an army of developers, content creators and volunteers also does not necessarily provide an inkling of truth to how many hours is required to "release a playable MUD". Whatever the case, it is NO EASY TASK.

Newworlds 08-05-2010 03:36 PM

Re: Developing from scratch
 
No pessimism, do it and stop talking about it and show us your end product.

Newworlds 08-05-2010 03:51 PM

Re: Developing from scratch
 
It's hard to comment on what your game looked like in Feb of 2009, since it is now over two years from when you started.

I'd be happy to look at your game but from what I can tell your website dictates that most of the features are "more to come" and "more coming" so I'm not really sure what that means. But again you are almost 2 1/2 years in the making now, not a few months.


All times are GMT -4. The time now is 09:56 AM.

Powered by vBulletin® Version 3.6.7
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Copyright Top Mud Sites.com 2022