Where to get started in making a text based MUD?

So I have been making small games for over 3 years now and I'm comfortable in the programming languages that follow:

1. Python (I need a bit of practice with this)

2. C# (I am the most comfortable in this)

3. Java (I know quite a bit but might need to do a tad of research)

and I have also done a bit in:

4. JS (I know pretty much nothing here)

5. And some other stuff

Anyway, so now you know all that rubbish here goes. What I wan't to do is program a text based MMORPG or a text based MUD. I have basically no clue where to begin so I what I need is some places to start. If anyone has any information on the subject, anything at all, please post it bellow. I will be really appreciated.

There are countless MUD implementations created over last 30 or so years, so best choice is to download driver & mudlib and just boot it. Or you can just get the driver and write mudlib yourself. Unless you really know what you're doing, it requires quite an effort to write a real MUD and not just something that will display some text on somebody's terminal. Just mind that setting this up, compiling etc. is not an easy task either, and usually require some level of C programming. Plus mudlibs are usually written in specific language like LPC.

If you want to start from scratch, it's really hard to provide any guidelines because this is such a vast topic, covering a lot of areas like parsing, networking, memory management. Some projects are polished for decades and still being worked on and improved. So first clarify what is your goal and what you want to achieve. if it's going to be a toy project and nothing real, I think I saw some simple MUDs written in Python or C# that were not very complex, you can probably Google them for reference or just trying them.

Thanks that's a lot of help. I am just doing it as a small project so I'll check out these smaller projects first

It's not as hard as it's made out to be. I worked on a couple of MUDs back in the late 90s - early 00s, back when all of the cool kids were doing it. For laughs, I once whipped up a Diku clone in Visual Basic (pre-.NET era). But don't do that. Either find something that already exists (CircleMUD still holds up) or get ready to practice your C++/C# skills. You're probably wanting to do the latter, from your description, so I'm moving forward with that assumption.

First, you have to be a hundred kinds of motivated if you actually want it to turn out like anything. For an authentic "feel" we're talking about creating a Telnet server with a decent, consistent flow independent of the game clock, and presumably for multiple connections. Work in color codes while you're at it; you'll feel a lot more satisfied with yourself if you get that going from the outset.

Now, at this point, get used to the idea that you're just going to be making an extensive database and making your main engine do a few basic tricks with it. Do you like databases? Let's hope so. Make some decisions here on whether you want to plan and build your own structure from the ground up, or just use an existing database engine. I prefer to bake my own for various reasons, but that's just me. Either way, it's a bit of work, and you'll probably want to build your own tools to help interface with it. (Also: Do not use SQL. Just trust me on this.)

So you have a generally empty database at this point. You've almost certainly been plugging some test data into it, but that's not going to get you very far. Here's the part where you make CONTENT. You'll be doing a lot of writing. Probably a couple hundred hours worth in total before you're really happy with everything. Why? Because it's the only thing that the user can see. Also you'll be making interesting objects to stick in your little world; those are mostly only distinguished by their descriptions. Then Mobile OBjects (aka MOBs - ever wonder where that term came from?) and some interesting descriptions of their behavior. You'll probably want to enlist some friends or enthusiastic internet strangers for all the content you need, so make sure your tools are really user-friendly.

Oh yeah, you're maybe going to want to add some player classes, spells, skills, whatever your gimmick is. I hope you've been thinking about that a lot by this stage of the process. You'll be implementing and balancing all of that here. Then some basic messages ("You can't do that here" etc.) so that your players maintain some sense of pest and feedback about whether the things they're doing are actually working.

So yeah, basically just the usual game dev cycle, really, without quite as much helpful middleware or payoff when you're done. But you'll get a very nice feeling of self-satisfaction of it.

You'll probably get a lot out of reading old archives of rec.games.mud, if you have the time and interest.

MUDs were known as resource hogs in the '80s, but these days, a single core on a single CPU can run text commands and networking for a thousand users with no sweat.

Also, MUDs have the benefit of working well even with standard "select()" network programming, you don't need to go for fancy event-based I/O (which there are fewer tutorials for) and you absolutely should not spawn a thread per connection (unless your "threads" are co-routines like goroutines, Haskell lightweight threads, C# async/await, and such; then you CAN but don't have to use those.)

I recommended this the last time it came up, and I still recommend it: Build a web interface in front of your MUD. You can still support telnet of course, and/or SSH, but you'll have more players if you also let someone play in a browser. Some kind of websocket proxy or even long polling session handler on top of node.js would probably work great for this; it doesn't have to be built into the MUD itself.

If I were to do this today, I would probably do the single page app approach (client side javascript) with nodejs (server side javascript) handling the authentication/websockets (essentially network messaging transport). Then I would use python to run the game loop/state using redis as the middleware communication layer between nodejs and python.

Windows doesn't even come with telnet enabled by default and the games quickly become difficult without some client filtering and aliasing things anyway so the traditional bare tcp socket approach doesn't seem worth it to me anymore. I guess there is still a dwindling community of folks using variations of telnet clients specifically for text based MUDs and maybe that is your target audience. I still agree with hplus in that a web interface is probably the way to get the most people easy access. 

Thanks evillive2 and hplus0603... I think a web page approach would probably attract the most people but I'm gonna stick with people who use MUD clients purely because I'm more confident in those languages. Maybe once I have a base game out I might spread out to web pages. 

Also for anyone who is looking at this thread for help on the subject, I found this which I found very helpful.

Nothing stops him from using existing, well maintained drivers/mudlibs that can keep persistent worlds of thousands of hundreds of objects and so on, and hook it to a more sophisticated web client btw. A lot of muds from the past are already enriching user experience by doing this.