MUD Coding

Building Mud From Scratch

I am interested in building a mud from scratch using C++ programming language during college but I am not quite sure where to start. Currently, I am just learning the language with a book I bought and I am going to take a class pretty soon on it. My question goes out to everyone that has built a mud from scratch. Where did you start exactly? I have so many different ideas I am not sure where to begin. Perhaps somebody has reference to early codebases I could glance at? Any help and/or advice would be greatly appreciated. Thanks in advance.

Where to start? Well, the most common mistake people make is to jump into something head first and code their way through it by brute force. Not smart. First plan out some things and ask yourself some horribly obvious yet revealing questions.

What? What do you REALLY want? A standard code base? Do you want character data stored in a database or as files? Do you want things to be persistant or do you want to add in the capability to reset things automagically at set times? Or perhaps both?

Why? Why cough up a code base from scratch while there are already decent codebases available. (or so they say, haven't touched a MUD in three years...) A reason might be to avoid legal hassles, as that kind of crap regulary rears it's ugly head on the forums. Make a nice small assesment of reasons, keeping in mind that planning, building and MAINTAINING a code base will cost you allot of time, grief and potentially money. Compilers, debuggers, source management software and all that doesn't grow on trees unless you are a masochist and code completely with OSS.

How? This is where you made your first mistake already; (sorry to be kind of blunt here) You first need to know what you want, how you want it and how you plan to keep it, before you can even start to think about ANY language. The programming language is inferior to the actual goal you're trying to achieve, for it is nothing but a tool to achieve that what you want. Pick the right tool for the right result.

When? Give yourself a REALISTIC deadline when you want to see some results. Keep it realistic, if you want unrealistic deadlines you should become a full time programmer instead. It's much easier to work when you've got a set date, makes for WAY easier planning and it's a nice a simple form of self-disipline.

My question goes out to everyone that has built a mud from scratch. Where did you start exactly?

I started by joining a few muds as a staff member, and getting familiar with general mud coding. After a few months of that, I took a stock mud and had a play by myself. After about five years of developing that mud, I wrote another one from scratch (just a small one).

Then I got together a team, spent about a year and a half working on the design of a new mud, followed by another year and a half of coding (once again from scratch). It's not really playable yet, but it's coming together quite nicely.

But the short of it is, expect to put in a lot of time and effort. The same is true of any decent mud, but with a scratch-written mud you'll have to put a lot of time before you even see any results.

I started by printing out portions of the stock Diku codebase and I would go through it at the same time I was taking my programming class. I ran through the code from the mindset of a player. Figuring out how logging in works, finding out how a player typed command turns into mud action, etc. I'd make little notes here and there, look up stuff in my text book, ask someone, or whatever I needed to do to understand what was going on.

When I decided I understood enough of the 'big picture' I figured a good place to start my own would be to make a C++ server class. The actual socket code isn't teriblly complicated so it turned out to be a good place to start. Then I added a 'Mud' class I think. It was mostly empty but provided a place to start game type stuff. Then I would add stuff piece by piece. I rewrote all of the early stuff at least a couple times and am always wanting to 'improve' something or other, but that's the way it goes.

Hi, even though the threads dead and all, I'd like to throw in my thoughts on that...

If you want to have some fun doing this, *don't* look at the insides of another mud. I didn't look at diku's low-level stuff when I made CVagrant, but I still knew how diku worked, so my little project turned out influenced by it. Code yours first, then take a look around, you might just come up with something new and exciting .

Why? Why cough up a code base from scratch while there are already decent codebases available. (or so they say, haven't touched a MUD in three years...) A reason might be to avoid legal hassles, as that kind of crap regulary rears it's ugly head on the forums. Make a nice small assesment of reasons, keeping in mind that planning, building and MAINTAINING a code base will cost you allot of time, grief and potentially money. Compilers, debuggers, source management software and all that doesn't grow on trees unless you are a masochist and code completely with OSS.

Hmm.

There aren't many decent codebases out there, for a reasonably demanding definition of 'decent'. I've not seen any Diku derivative that wasn't a horrible mess, and the general scheme of polling and ticks is horrible. Not to mention the fact they're nearly all in C (which is fine for those who like playing with pointers and fixing memory leaks rather than adding gameplay logic), full of hard-coded choices, and rely on non-standard data formats, often incompatible across very similar versions. There are some nice codebases out there but they are generally unfinished because it's just 1 guy working alone.

Coding on OSS is not a 'masochistic' option. Once installed, KDevelop is not significantly worse than Visual Studio 6 in any way that I can discern. And Source Safe is no better than CVS (which can also be managed by KDevelop). So what's missing? I don't want to get into an argument over open source vs. proprietary software, but I certainly don't think the quality or usability gap is as big as you make out. Visual Studio and Borland C++ Builder are just wrappers around console mode compilers too.

There aren't many decent codebases out there, for a reasonably demanding definition of 'decent'. I've not seen any Diku derivative that wasn't a horrible mess, and the general scheme of polling and ticks is horrible. Not to mention the fact they're nearly all in C (which is fine for those who like playing with pointers and fixing memory leaks rather than adding gameplay logic), full of hard-coded choices, and rely on non-standard data formats, often incompatible across very similar versions. There are some nice codebases out there but they are generally unfinished because it's just 1 guy working alone.

Coding on OSS is not a 'masochistic' option. Once installed, KDevelop is not significantly worse than Visual Studio 6 in any way that I can discern. And Source Safe is no better than CVS (which can also be managed by KDevelop). So what's missing? I don't want to get into an argument over open source vs. proprietary software, but I certainly don't think the quality or usability gap is as big as you make out. Visual Studio and Borland C++ Builder are just wrappers around console mode compilers too.

Ahh, maybe they aren't the nicest code around, but they work. Mostly anyways. That's the whole issue of starting with a prefab codebase; you're bound to what other people have coughed up for you and bound to their mistakes as well. But yes, I did browse through the smaug source code once and I have to give it to you, it made me want to claw my own eyes out.

That said, C is still a very nice language for running a mud server. Sure, it lacks the portability of Java, but neither does C gobble up resources like a... well, something that gobbles up resources pretty fast. C# is still mainly Microsoft so using that requires you to fork over allot of money for a C# compiler and to regulary bend over and take it from Billy-boy. Suppose C++ would work, inheritance, data hiding and various other C++ specific features are absolutely wonderful things even though the C problems of pointers (which aren't a problem imho, just an extremely abstract and complicated feature) and memory leaks. Still though, it's not a bad language. It beats Java and C# in my not-so-humble opinion )

Anyways, yeah, hard coded stuff is vile, like set text strings for spell failure and all that. Is it that hard to make it load strings into memory from an external file on run-time? It makes for easy translations at the very least. And storing data in a non-compatible way has been an issue for some time, though they pretty much solved that when they came up with databases and if you like dumping data in a plain text file, XML.

Also, OSS is not a masochistic option for people acostumed to it with prior OSS knowledge. That includes, I guess, you and me amongst other people on here. But how often do you hear about college kids with only experience in VC++, Source Safe and various MS applications? For those kind of programmers and common people, using OSS is still a bitch to use. Compare installing VC++ (Click OK, click OK, read license, click OK to be Bill's towel boy, click OK, click OK, wait, click OK a few more times, reboot, done! to install GCC (... which I don't have a clue how to do really, but I'm willing to bet it involves ./configure --with-ridiculously-long-line-of-compile-options, make, wait an eternity, make install, make clean) ... So remember, for us OSS might be a nice little challange to use that gives us the ability to CHOOSE what we want, while for the common people OSS would be near impossible to use. That said, I expect most people on these forums to be builders/non-coders who don't have a clue what GCC is in the first place... Hence why.

install GCC (... which I don't have a clue how to do really, but I'm willing to bet it involves ./configure --with-ridiculously-long-line-of-compile-options, make, wait an eternity, make install, make clean)

It's not so bad really... however, "eternity" is not NEARLY long enough... it's more like, run make in the morning, go to work, go eat out, go watch a movie, go watch a late movie... then go home and hope nothing went wrong

And THEN deal with customers complaining that the new compiler is broken because they made the compiler more strict and a nice warning free diku compile now terminates with dreaded Error: Too Many Warnings.

Compare installing VC++ (Click OK, click OK, read license, click OK to be Bill's towel boy, click OK, click OK, wait, click OK a few more times, reboot, done!) to install GCC (... which I don't have a clue how to do really, but I'm willing to bet it involves ./configure --with-ridiculously-long-line-of-compile-options, make, wait an eternity, make install, make clean)

I think installing VC++ is a lot more of a PITA =). You have to physically get up and find the CD, then laboriously insert it into the CDROM drive.

All I have to do is "apt-get install gcc" (or "apt-get upgrade" and it'll be automagically upgraded...). Or more likely on my servers, "cd /usr/ports/lang/gccXX;make install". And I'm done!

Quote:

Originally Posted by (Koryon @ foo)

And THEN deal with customers complaining that the new compiler is broken because they made the compiler more strict and a nice warning free diku compile now terminates with dreaded Error: Too Many Warnings.

Always install new compilers in a different location than the current one, so you have a strategy in case the new one doesn't work =).

Oh of course, I just didn't give it quite the rigorous testing on my home machine, I just compiled my own (cleaned up at the time) old RoM, but going from an egcs 2.96 to a brand new gcc 3.something release actually quite the lot of differences

Even a good coder on our machine got trapped because the C++ compiler would no longer accept code it never even gave warnings about before.