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.


All times are GMT -4. The time now is 05:27 AM.

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