Top Mud Sites Forum - View Single Post

KaVir · 07-30-2010, 08:39 AM

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.

07-30-2010, 08:39 AM	#3
KaVir Legend Join Date: Apr 2002 Name: Richard Home MUD: God Wars II Posts: 2,052	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.