I seen a lot of custom MUD bases out there and a wide range of handling RP and Combat, but I want to get to the very basics of what goes into building a MUD.

First thing is I have seen two main ways of handling Players and their PC's. One is to have an account for each PC, and verify each one with a unique e-mail address, the other is to have the Player create and verify one account, and make a set number of PC under the Player account.

I want to know if allowing a player to have Alts under a main account is easier or harder to regulate than individual PC accounts?

Another linked Item to this is using the Main account to control the number of PC's possible, and controlling the number of PC's a character can have online at one time.

Since Players are what makes or breaks the MUD, how to hand;e giving them enough, without giving them to much?

(Sorry for any strange grammar. I have Dyslexia, and it causes me to rely on the spell check more than I like)

Alright, over a hundred reads and no replies tells me I may have been a little to vague on my first post.

Right now I'm focusing on the database for the player log in and PC recognition.

With having a main log in, and a number of PC under that log in, all of the PC'c can be promoted to Admin, demoted from Admin, given limited access, or be banned all at once.

Since coding for accessing the database different in each case, and the Player needs the option to switch between PC's without fully leaving the system, you are looking at a lot more code to go this route.

I want to know if allowing a player to have Alts under a main account is easier or harder to regulate than individual PC accounts?

[....]

Since Players are what makes or breaks the MUD, how to hand;e giving them enough, without giving them to much?

I think multiplay, on a mud with an account system, is easier to regulate because you can add incentives that encourage players to keep all characters on one account. However there's nothing about an account system that prevents multiplaying any more than with no accounts.

For that matter, you don't even need a 'main account' system; you can have an ad hoc system where players can link individual PCs as they wish. Then you get the option to add incentives but you don't need to write 'extra' account code -- like a login shell, switching characters in-game, etcetera. You might be better off just letting player clients handle account management, assuming you're not restricting players to a custom client that you're going to write.

To answer your second question, let me just say this. Worry about multiplaying when you have players. At this point you have no mud, and no players. One step at a time.

Alright, over a hundred reads and no replies tells me I may have been a little to vague on my first post.

Or maybe no one knows. ;-)

To answer what seems to be your original question regarding regulating player accounts, I'd say from a software design perspective, its going to be more beneficial to have the players create a single user account then create related characters up to MAX limit. If you're using a relational database, then you're properly normalizing your data doing it this way.

That being said, since you want to regulate player security levels on a PC by PC basis, you'll definitely need to have a field that stores that data. Having the PCs linked to the user account also gives you the benefit of easily banning/promoting/demoting ALL characters linked to a given user account.

Actually, I have a list of things I want to include, but I need some information on some other before I event know what I'm looking for in a codebase.

Starting with the order in which the players will see things, and since any builder or admin will start out as players, what they see there will start to form an impression on the theme of the MUD.

Also, in the early stages of developing, much of the code will have to be altered to the theme I am looking for, and PC's will have to be created and deleted for testing.

It sound like by going with the Main account path, I could have the Player database control who has what rights, and thus the rights the PC has while operating in the MUD.

If you look at it from the basic list, altering or creating a custom database for handling the Player accounts will need to be the first thing on the list to reduce the amount of time it saves in the long run of not having to stop and promote a new PC to admin or builder, or builders and Admin having to remember what rights they have been given under a any given PC.

Since I want to have the Character creation process in MUD so that related help topics are pointed to at each step, giving future Players quick access to the relevant information so they can make choices without hunting through Pages of information in Forums just to decide on what to make.

Next on the list would probable be Dealing with some things about the Rooms, Mobiles, and Objects to make them easier to manage for builders, but that part is already pretty well listed out for me.

After the Modifications to the basic parts, will come the work on the tutorial. part of the tutorial will be included in the Creation process, but the combat, crafting, emoting, spells, interactions, and extras will need a dedicated area of the MUD that the PC's can access for in depth information and help.

I've seen a lot of people comment on the different things they want in a tutorial, but very little about HOW to set up a tutorial that could do those things. The one thing that is clear is that the tutorial area needs very streamlined coding to access all the relevant data. This is a part of the coding I don't know a lot about, but will need to as soon as possible to make the tutorial feel usable, useful, and part of the actual MUD world.

Would it be quicker to set up a single dedicated help database that only contains all the help files, or should I attack each help file to the database where the information is being used (such as placing the weapon-smith help file within the database accessed by the code for crafting weapons.) ?

Actually, I have a list of things I want to include, but I need some information on some other before I event know what I'm looking for in a codebase.
...
Would it be quicker to set up a single dedicated help database that only contains all the help files, or should I attack each help file to the database where the information is being used (such as placing the weapon-smith help file within the database accessed by the code for crafting weapons.) ?

I think you need to pick a codebase and make sure it even has a database before you can ask meaningful questions about it.

Also, what is your level of coding experience? Your question makes me think that it's not great, so that's another thing to focus on, then post here with specific problems.

I think you need to pick a codebase and make sure it even has a database before you can ask meaningful questions about it.

Also, what is your level of coding experience? Your question makes me think that it's not great, so that's another thing to focus on, then post here with specific problems.

Well, I you want specific problems:

1. I only have basic programming experience to go with my degree in Game and Web Design.

2. The only way I can increase my experience is to do coding and programming.

3. The only programming languages I have had experience with are C, C++, HTML and C#.

Since this is going to be my fist time coding a MUD, it's going to be more of a dissection of the code to learn what it does, how to manipulate the code to do what is needed, and gaining experience with altering and debugging code.

~

As for the Databases, they can hold a lot of information that a simpler code can access and process for the result, and if the base code doesn't support it, I get the experience and my own code for making it access a database for the information.

I do know that C and HTML can both be programmed for accessing information stored in a database, and can use the same database.

Based on what I've heard so far, I think your problem is overdesign. It's pretty clear that you don't know enough about the problem and/or programming language to know what's easy or hard, new and unusual versus tried or tested. You're probably not going to learn what you need to know in tidbits here and there - it will only come with experience.

You're going to make mistakes, you're going to find out that parts of your design are unimplementable, and some are simply bad ideas. But if you're actually building and testing code, you're already miles ahead of the competition: I've seen more mud projects fail due to overdesign than for any other reason. It's fun and easy to endlessly theorize about game additions and think about how awesome a given feature would be. It's quite another to actually implement that and create a functional product.

As my dad used to say when I was growing up, 'do something, even if it's wrong'. As I get older, I find that advice becoming more and more apt.

Well, it takes time and practice to get what you want, and taking apart a couple of codebases and databases to figure out what makes some things work is one way to learn.

Also, I just got a copy of the code for TinyMUD...

Got to say, I'm not impressed with the commenting job that was done in it. Getting the code figured out to see what it is doing is going to take a lot of effort, and adding my own comments just to see what is defining what, and what is being operated on in any given block of code.

The files are labeled in a way that makes very little since, and there are NO comments on why the files need some of the others included. Got to say, the commenting is so minimal, that it borders on creating addition confusion as to what is being defined.

I'm going to chime in here and say that i agree with Dentin-my mud projects failed because of over design.
Disregard html and databases. Disregard account creation. Nothing is wrong with help files actually being files, but even disregard that for now. You are months away from needing a newbie tutorial and--depending on how fast you go--weeks to months away from needing a coherent mythology and world. I'll come back to tutorials at the end.
If you are going to make a codebase from scratch, here's what I'd have to say:
-start with an echo server. This is simple, typically about 50 to 100 lines, and examples can be found on the internet,. Code from it will probably not survive into later steps, but it will teach you about sockets. All it does is send every line you send it back to you. If you already know about the c/c++ notion of sockets, not the javascript one, you can skip this; even so I wouldn't. You can use a number of frameworks, but which one you use doesn't really matter, and Berkley sockets is good enough for your purposes.
-from there, disregard account creation and make a server that lets you walk around in rooms. They can be hard coded, it doesn't matter. The server will ask you for a name but doesn't care about password, and nothing will be saved. You can log on and walk around in rooms, no authentication. After you have that, make it read rooms from a file. If you call them rooms a, b, c, and d that's fine, not important at this point--this isn't your world. Implementing say at this point may not be a bad idea. This will give you a starting point to build off of.
-from there, you can do a number of different things, but I'd look at two of them specifically: character authentication and simple building commands. Don't worry about e-mails or linking with accounts. You want to be able to make a new character, and you want to be able to log into said new character again later.

If you need to get stuff to the web site, you can always make the mud into a tiny web server, or make the mud write out HTML files, but I'd not worry about that right now either. If you don't know databases, get everything working with files first and have a game that is at least playable. If you know SQL well, there's nothing saying don't use it, but it's not something I'd try to learn at the same time as everything else. Flat files are good enough for very, very large muds. Come back to the HTML side of it later, and you can use websockets from c/c++. You don't need a web site yet.

And the promised return to tutorials. After you have implemented a combat system and a way for builders to build stuff, you can look at this. If you haven't implemented a scripting language for builders, I'd wait a bit longer-being able to put signs in rooms works, but is boring. You don't typically hard code special rooms in c, you let builders code them in lua or mobprogs or whatever you implemented. If you have to recompile the mud every time someone has to fix a typo or script in an area, your builders will hate you and so will your players. Newbie tutorials--if your system is powerful--can be done entirely by builders, and this will ensure they can implement cool quests for you too.

Finally, nothing is wrong with using a preexisting codebase. You can modify that--so far as you don't try to go a hugely big distance outside the box--easier than you can code one from scratch. Finding a well-commented mud codebase will not happen.

First off, I am glad you are exploring programming for a MUD environment. It can be very interesting and at times even quite challenging. Most existing codebases are written in C (or some variant) and since you are already familiar with the language and syntax that is a definite bonus.

Camlorn's post includes a very good method for approaching your goals. While I have a new account on this website, I have been coding and programming since the late 90's. The "path" Camlorn laid out for you is very similar to how I tackled my first "from scratch" project: sockets, chat server, read/write files, rooms and movement, character info, combat, etc. Each step builds on the other (even if the actual code itself gets re-written multiple times) until you have something that resembles a working MUD. I would venture to say that most people have a similar experience with their first "from scratch" project. One of the advantages of using an existing codebase is that this part is already done for you and you can focus on making changes and modifications instead. You can still learn a great deal by dissecting and exploring existing code.

As far as the organization and commenting of existing mud code (or lack of it) ... that is the normal state of things in the mud world. Programmers writing original code only for themselves rarely comment their work, so if that code is then shared with the greater community, it lacks comments. Keep in mind as well, a majority of mud programming is done as a hobby and not as a job, so even if a programmer has professional training (most actually didn't when they first got started) the "professional standards" of always commenting and following a set formal coding style were usually ignored. Also, some of the work was done in a modular fashion, at least partially. Mud programmers who are asked to write a section of code to read/write a character file will most likely write two files: character.c and character.h that are then added to the Makefile and referenced in the base program with a read_character_file() function. Most are unlikely to dig through an existing, all encompassing, read/write file to make their additions. Which brings us to one of the major benefits of writing your own codebase: you can organize and comment (or not) to whatever degree you are comfortable with.

Either way, I strongly endorse Camlorn's suggestion if you decide to write from scratch. I feel it would offer you the best chance at having a rewarding experience and seeing a positive result for your efforts. Best wishes and good luck with your future MUD!

Actually, the very first step for people practicing game creation (including MUDs) is a step simple referred to as "Documentation and Research" Which is basically you studding what has been done, what works, studying the working code, and talking with others who have tried similar things.

As you go through this step, you create a list of goals you want to have in the finished game. Then you start working to break each goal on the list down into it's most basic elements. Once you have the list of basic elements down, you organize them into the order in which they need to be created.

Since I am going to want the experience, and need to get back into the programming habits, I will very likely be starting with what Camlorn said. My goals may make the project look over designed, but I know that many MUDs have created similar elements in them. I don't have a lot of the key elements broken down all the way yet, but I also realize it will be about 3 to 4 months of work to event get close to a point where it's ready for event the Alpha play testing.

Beta Testing could require another 3 to 5 months of coding and building, and Open Beta could require 3 more months.

Sadly, I also know that this project will be left mostly complete and in Open Beta state for the remainder of it's active life.

Do to the nature of MUDs and the MUD community, very few MUDs will see their Gold stage completed. This is because there is very little to learn from a truly completed MUD. Builders are not needed, Coding is done, and usually the Players have already explored the entire MUD by then.

You are over thinking this. Few muds have alphas and betas. You can implement everything in my list without any clue what you want your mud to be, including combat system or magic or whatever. You don't write a mud for programming experience, you write a mud to write a mud, and that typically means that you already know what you want to see in it. Muds don't typically have design documents, and if you spend a month pondering this project before starting you won't get anywhere. Even some successful muds just started; i don't believe Dentin started with a game design and planning phase for example.

Like others here, I'm a deep proponent of TDD and agile development. That said, given that our field is populated exclusively by enthusiasts, and given that the OP clearly enjoys planning very much, maybe we should adjust our views on what constitutes a 'failed project' that 'goes nowhere'. So what if someone spends months planning and never reaches the doing stage? If they get some enjoyment and edification out of it, then maybe the project should be considered a success.

You are over thinking this. Few muds have alphas and betas. You can implement everything in my list without any clue what you want your mud to be, including combat system or magic or whatever. You don't write a mud for programming experience, you write a mud to write a mud, and that typically means that you already know what you want to see in it. Muds don't typically have design documents, and if you spend a month pondering this project before starting you won't get anywhere. Even some successful muds just started; i don't believe Dentin started with a game design and planning phase for example.

Um, yeah - Approaching development of a MUD should be exactly NO different than any other software engineering project. Planning is very important - knowing is half the battle. ;-) Thagrahn's process oriented nature has my vote.