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

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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:

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

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.

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

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?

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.

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?