[ning03]

There is no question about it. We have all at some point thought of creating our own MUD. Our minds race and fill with ideas but at the end of the day, ideas can only bring you half way. The internal matrix of a MUD, its codebase is what brings your ideas to life but unfortunately there are those out there, despite their profound creativity, are crippled by the lack of knowledge for coding.

They could always find a coder to do all the technical work for them or possibly learn basic coding and get a few months or years practice on another MUD. Although, no one is as dedicated and/or eager to the creation of a MUD as its creator. The coder becomes the catalyst to your MUD and a master to your domain, and since you don't know a thing about coding MUD, the coder is burdened with all the objectives you want him to complish and you are burdened with inconvience. Plus, you can only create when the coder can code.

And inconsideration to being employed by another MUD, your ideas are withheld and abilities limited to the MUD. While your swimming in your ideas and goals, your attention is focused on your employer's creation and fufilling his standards. It is definately an awesome way to learn coding and practice until you can create your own but what about those you just want to jump into creating their own. But hey, this is only my point of view.

What I ask for is a simplified step-by-step guide, a translation for all this technical jargon and easy "instructions" (for lack of a better term) to preparing, creating, and coding a MUD. Something like an Idiot's Guide to MUD Coding.

[Brody]

In which coding language? You'd need an Idiot's Guide to each and every publicly available type of MU* code. Not terribly practical. I recommend visiting Google, typing in the various MU* codes that might interest you, and check out any sites that are devoted to coding in those languages. I use PennMUSH, so is a good place to start for that.

[Kylotan]

Seriously, what you are asking for could fill a 300-page book, much like the "Programming RPGs in DirectX" or the like you see in the stores. The technical jargon isn't there just to put people off - it's because it's a technical field and new language evolves to fit complex things that can rarely be explained concisely. You're gonna have to learn about compiling code, about the programming language itself, about some basic programming concepts, and then you fit your game around that.

Probably the best way to start is by modifying an existing codebase, in conjunction with getting yourself an introductory text on the programming language that codebase is written in, and find a programming forum online that caters for beginners and which can answer your technical questions.

One thing to consider is that you can simplify your task a lot by using a simpler programming language, such as my favourite Python. Unfortunately this has the negative effect of severely reducing the amount of sample code you can work from, as well as the number of people who can help you with your project.

[Ilkidarios]

I can explain it in a few simple words: Hard as ####. And it requires some form of effort, and that's why I never made me one.

[Lanthum]

Coding a MUD; LEARNING to code a MUD - takes along with many other attributes: dedication, initiative, sacrifice, and to me a desire - NOT to build the best game YOU would like to play, but instead - to build the BEST game OTHERS want to play.

I'm sorry, but asking others to provide you with a step-by-step guide on how to code a MUD is just plain childish and selfish. Creating a MUD isn't like baking a cake. You can't get a recipe for it. You need to learn how to program in a language FIRST, then take that knowledge to a higher level by applying it - in this case - to creating a specific type of server application: the MUD game.

If you would have sacrificed some time, and took the initiative to use Google, TMS, and other sites like , you would have found plenty of suggestions on how to START learning how to code. Follow what those people say. There are MANY good suggestions out there. Don't ask others to do the research for you. That's your job!

Please understand I am in no way trying to be mean, or start a flamewar. It's just that people need to understand what they ask for BEFORE they ask for it.

[KaVir]

I'm afraid I'd have to completely disagree with that. Everyone has different preferences when it comes to muds, and no matter what you do you're not going to please everyone - so you're far better off creating something that you enjoy.

Create something that you don't like and you're unlikely to have the motivation to keep it going. But create something you do like, and you'll attract those who like the same style of gameplay as you do.

[MattCorley]

There are a lot of great resources for coding a MUD.  I suggest, personally, coding in a non-specific, non-MUD oriented language.   Aka, use a major language not tuned necessarily to MUD coding.  You are a lot less limited, and it is a lot MORE useful.   As for which language...well, that really is entirely up to you.  One of the most famous languages, especially for windows programming, would be C++...but it is also very hard to learn.

But, to give a small summation as to part of the tasks to coding a MUD:  You have to create a client-server frame... aka, something capable of sending packets and then the application running on the host computer that can receive them and interpret the data.  Also, you'll need to create a database backend, something where the players abd objects and data fields... ETC... are stored.  Thats just the basic guts of the thing.  From there, you have to program content based upon whichever game concept design you've thought of for it.  In essence: coding a game is not *for* Idiots, and therefore a 'for Idiots' guide is impossible. (Note, this overly simplified to a very, very large degree)

But you can learn if you are dedicated, and you aren't daunted by technical information.

[Jedediah]

I have to completely agree with KaVir. Create the vision you have and if it is compelling to others, they will come. If not, at least you've had a good time, and didn't slave for months all for naught.

[Lanthum]

I hate to post something against the theme of the thread ... but let me explain myself:

I was NOT saying build what you dislike INSTEAD of what you like. What I was meaning is that too many people build ONLY what they like, and don't give any thought to what others might want in a MUD. I mean after all, are you making your game only for you - or for others. I don't know about you - but if I am spending all of my time and effort into building something ... I want it to be something that the most amount of people will enjoy and come and play. Including myself. Otherwise it IS a waste of time and effort. There are many things I might not desire in a MUD - but others might. It's those features I need to be willing to put in my game.

And the most important part of what I was saying is what it takes to build a successful MUD. I don't think enough people really ask themself why they are building a MUD. And if they do - too many answer that with some version of "because I think it would be cool if ..." or "I would love to see ..." There are so many MUDs out there to work on, that if those are your reasons for creating a new game - I feel you are doing it for the wrong reasons.

You know, in my opinion - agreeing with the quoted mentality is exactly why there are 4,328,102 MUDs out there. And why many new players flee from MUDs in general after only a short time of playing them. Too many people after playing a MUD for a while start thinking "Hay, I have all these great ideas for a MUD ... so I should run off and make my own game!"

Instead of all these MUD creators slamming the "pay-for-perks/play" niche or the MMORPGs, maybe they could learn something from them. Instead of every disgruntled, bored, or new player in the MUD community running out to build the "bestest UBERest kewlest" MUD in the world "that he would love to play" ... maybe more people could work on larger projects together and create truly great games.

But then again, maybe that's like asking for "World Peace" and "No more world hunger", and $15,000,000 in my bank account and a Lamborghini in the garage.

[the_logos]

[KaVir]

And what I was saying is that everyone likes something different, so no matter what you do you'll never please everyone.

Which leaves you with a choice. Do you want to create something you like, or something that a random player likes? Because I can tell you from experience, if you don't enjoy the mud it's very difficult to motivate yourself to keep it going (unless you have some other major motivation, such as financial renumeration).

I'm making my game for myself, and by extension, everyone else who likes the same style of game that I do.

That's like advising restaurant owners to open McDonalds and Burger Kings. Sure they're popular, and sure you'll appeal to a wide audience - but there are plenty of people who would far prefer to go to proper restaurants, and I'm one of them.

No, my sort of mentality - the willingness to stick to your own vision - is the thing that encourages diversity and gives rise to the next generation of muds. To appeal to the masses you need to stick with the same old tired features. Sure, you can give those features a polish, but if everyone limited themselves to what the masses wanted, muds would never progress.

[Lanthum]

[KaVir]

Then in both cases we appeal to ourselves, as well as to others.  The difference, as far as I see it, is that I will only cater to the players within the scope of my vision.

And I feel the same about your approach, as you'll be trying to appeal to the lowest common denominator, which will require 'dumbing down' your features.  If you add every feature that 10,000 other people want, then I can guarantee you that your mud will suck.  Badly.  In fact, I doubt that any of those 10,000 people would still enjoy the awful hodge-podge that you'd end up with.

The masses in the mud world don't want truly novel features; they want the tried-and-true (i.e., what they're used to), with a little spin on it and a lot of polishing.  If you're developing something really cutting-edge, then you're only going to appeal to a niche market.

[cron0s]

Your own games illustrate this point extremely well. If one compares Achaea to Avalon, you are still a long way behind them in terms of features, yet you have by far the more popular game. I also wouldn't mind betting that you make a #### of a lot more money than they do.

Wow, I hope in the interests of religious fairness that the word heaven is censored too.

[the_logos]

Yes, plenty of people would prefer to go to proper restaurants. And in proper restaurants, the chef and owner have conspired to create a menu and experience that appeals not to themselves, but to other people. Other people who enjoy good food. Appealing to other people has nothing inherently to do with creating MacDonalds. Appealing to other people is what professionals do when they want to achieve financial solvency and thus continue to practice their trade.

You're not completely wrong. I don't know any top chefs that would advocate running polls and basing their cuisine on that. Most I've talked to (and that's more than a few, as my family was in the business) generally attempt to provide what the general upscale restaurant goer might enjoy and then throw in a couple dishes or specials that offer a challenge to the average upscale diner. Very few of the top chefs these days maintain an "I know best, eat what I give you" attitude.

For intsance, Andre Soltner (of the legendary Lutece in NYC) said, "My whole life -- well, the last 45 years of it -- I gave my blood for the customers."

Jeremiah Tower (of Stars. Founder of California cuisine when he was at Chez Panisse) had a policy where the staff was not permitted to tell a customer 'no'.

Jean-Georges Vongerichten (Vong and JoJo in NYC) cooked in Thailand for awhile, and -hated- Thai food at first. He didn't stop making it for people though, because the market wanted Thai food.

Jasper White (Jasper's in Boston, though it's closed now) once said, "I listen to what people want, and I believe in making people happy. Over the years I've had many requests for vegetable plates, so about three years ago I put it on the menu."

Even the man who is arguably at the top of the heap currently, Thomas Keller (French Laundry in Napa and Per Se in NYC), reknowned for serving 4 hour meals with up to 12 courses, doesn't simply make what he wants, particularly as what he wants is often just a simple roast chicken (few top chefs go home and eat the style of food they serve at the restaurant), which would NOT go over with the customers, who are there for an experience different from simple roast chicken. Keller also cut back somewhat on some of the more esoteric preparations (too many froths, purees, etc) after the market rejected them, and this is at a restaurant in one of the most sophisticated food markets in the world.

The thing it's not about the extremes. Catering to your player or customer doesn't make you MacDonalds. It makes you service-oriented, and that's the name of the game. Alice Waters (Chez Panisse in Berkeley and the person responsible for the style of cooking that's come to dominate the food scene for the last 20 years) said, "I like to think that we're helping them to moderate what they're eating, and showing them that you don't have to eat a 12-ounce T-bone steak - you can enjoy just a couple ounces of meat cooked quickly on the grill. But in case I'm not persuasive, I try to accomodate them. If I have the time, I'll really go to an extreme to do so."

Now that is the mark of a professional chef. She wants to help the customer elevate his level of food appreciation, but if the customer isn't interested, she gives him what he, the customer, wants. THAT is a professional, not someone who says, "I will only cook what I personally feel like cooking that day." That person may be a great cook, but being a great cook and running a restaurant are hardly the same thing, which accounts for why so many restaurants fail.

It's a bit different in MUDs, as hobbyists have no external pressure to get players (the opposite in fact, as players = higher hosting bills), but regardless, to equate those MUDs who actually care about providing people with what they want is as silly as condemning all the chefs I mentioned above for trying to please their customers. Pleasing customers is a good thing.

--matt

[the_logos]

That's for sure. And if anyone doesn't believe it, check out World of Warcraft.

--matt

[the_logos]

Hahaha.

--matt

[Earthmother]