New MUD design - Starting to redesign a MUD codebase

Long time no see Anywho, i'll skip right to what I'm thinking of here:

After fighting with Smaug for awhile, I've decided that I want to start over from scratch (maybe base it on TinyMUD to get the very basics out of the way), and also try a new design that came to me awhile back.

I'm thinking of using Python/Perl/Ruby (one of the three) sripting (maybe not as grand as Lua, but it would be a start, and people already know python, so there is part of the learning curve out of the way. I could go back in and modify it later to accept Lua scripts as well) for programs, spells, skills, ect.

Use a modular design, so if, say, the handler for movement and combat crash, the entire MUD won't die, and you can still talk, similar to the Linux design.

Avoid using Boolean values to keep the system more open to expansion.

Try to do the coding in C++ to hopefully shorten the length of the code, and maybe help optimize the system to decrease overhead and keep the same useability.

Use a DB program (possibly MySQL, or something else. UNdecided right now) to handle non-hard coded values.

Use a more or less modified traditional movement system, but with included upnorth, upsouth, ect. to make things like ramps more realistic.

Change the combat system to allow for a more open style, and using an in-room X,Y,Z coord system to allow for some interesting combat situations

An in-MUD trigger system to help simplify (nothing that you can bot off of, but something to make lif a bit easier) things like combat and basic survival

In the theme of combat, a more flexable system of stances, styles, positions, and whatnot to also make combat a hopefully more flexable system.

Some MAJOR command enhancements (fewer commands, but with added arguments to keep the same usefulness, but without a massive list of commands to try and search through)

An in-mud search system, coupled with a personal diary/journal, books, ect. to help with player information management, and also possibly a source of income.

That covers what I've got in mind at the moment, and as soon as things calm down around here, I'd like to have some feedback from MUD coding vets on these ideas and any possible enhancements that could be thought of.

Thanks in advance for your feedback.

I wouldn't count on it. It will be hard unless you prepare for it extremely well from the start, at which point you might as well do them all from the start.

Well, ok, but I'm not sure how useful that would be. If the MUD is basically dead, you probably want to detect that and restart the MUD as fast as possible. Better would be to aggressively use paranoid programming, with assert calls in very many places. Most importantly, try to arrange things such that no data loss occurs.

For instance, do not overwrite data files unless you have the full content ready to write. If you start overwriting, and the program crashes, that's bad times. (This happens in SMAUG and is the major source of data loss.)

I'm not sure how booleans are inherently an obstacle to expansion.

You could think about making a more flexible exit system, where directions are not important per se but all name-based. In SMAUG, as far as I know, the directions aren't important except for the occasional command like 'track'.

Good luck... :-) This is very, very hard to get right, mostly due to the interface problems posed by the text-only environment (both input and output).

I'm not sure how much this is saving you. It's moving complexity from one place to another. The real issue is that commands are so poorly indexed and the help files aren't top-down. The help files assume that you know what you want and just need a reference page.

Nick's indexed command page is very useful in this regard.

Journal, books, etc. sound good. I'm not sure what the search system would do? Searching what for what?




And now for a general thought, I would think hard about what you're doing and why you think a new codebase is necessary. Don't forget that you'll need a game design to code towards. Don't bother trying to make a codebase without having a game design: that's just not possible. Your codebase determines the basic physics (fundamental entities, if you will) of the possible game designs. Certainly, you can leave some factors open, but your choices will have effects that you might not predict at first glance. Think very, very hard about your game design, or at least, your universe of possible game designs.

You might or might not know that Nick and I have been collaborating with some others on a new codebase, BabbleMUD. But what you should know is that despite having worked on it for a while now (despite various setbacks relating primarily to me not having enough time) we haven't really written definitive code. Oh, sure, we've written several skeletons and prototypes, but every time we realized that we were coding too early, without having a clear picture of what exactly we were trying to do. For the past year or so, we've been working exclusively on game design, and we're not done yet. (Again, a lot of that is my fault for not having enough time, but still, it should give you an idea of how hard this is.)

Also do not forget that SMAUG was written by more than 10 programmers over several years.

All this to say that you should think hard about whether a new codebase is necessary, or if you could tweak something else to make it better, or at least change it slowly over time. That's what I've been doing with my copy of SMAUG; gradually replacing more and more chunks of it. The networking code, for example, is about 99% my own at this point.

Of course, if you're doing it to have fun, then by all means, go ahead! :) But keep in mind the scale of the problem.

You have a point as far as the Lua scripting is concerned. I'll keep that in mind.

As for using a modular design, my thoughts were that, say something was coded into combat (I've known of a MUD this happened on), and when a skill is used, it crashed. Well, restarting the whole MUD is an option, my thought would be to allow for that module to be rebooted, so that someone walking around in another area thats hard to get to won't end up totally screwed, but can wait a few and continue to fight. This also has another advantage I can think of in the sense of instead of having to reboot the whole MUD, that if you make a coding change, you can recompile that one section, then reboot that module to, in a sense, update the whole system without bringing it all down then bringing it back up. Granted the hotboot system can do the same thing, you could also have 2 versions you wish to test, and use something similar to
load_module ~/combat_testA 5 m
to load one, then if that doesn't work, or you want to see how well the other handles, run
load_module ~/combat_testB 5 m
to test it out so you can get all the compiling done at once. [Note: The 5 m would be for a 5 minute delay, to give players time to get ready for the module reload, or to warn an Imm that they need more time].

As for the Boolean values, I was refrencing the resist system mostly. Its annoying as hell, to say the least.

Movement I would like to keep to a somewhat Smaug feel, just to help keep it user-friendly. I've been in too many situations where a command was obscure to even enter a building, plus there is still always the "enter <exit>" command to use.

I know the combat system will be a royal pain. I'm planning on doing it last if at all possible, and doing the rest of the code with that system in mind. It will affect the move system as well to a point (allowing for movement within a room, but also just being able to move NORTH to enter the next room).

As for the command system, as well as the help system, I'm almost tempted to try an semi-emulate the info and man programs in Linux, only with slightly diffrent commands. For the most part I may use a fairly basic help system until I can figure out how to do that correctly, since I think it will require a client to handle it. As for the commands, I would look to a fairly simple setup thats similar to what is used, but instead of, like:
redit bexit...
rpedit...
ect, change it to something like:
roomedit/redit program <sends to buffer to work on script>
and the like. With players, like with a book/note:
Note read <#>
Note copy <#>
Book read <pg.#>
which, while looking at it, is pretty much basic, lol. I think it would affect imms more then anything, and could possibly (depending on how all it works), make the code easier to read and maybe maintain (having it all in once place instead of spread over 3 files would be very helpful)

The search system would mostly be like findnote, but will cover helpfiles (help reduce the time spend with hlist ?), notes, books/journals/diaries on your person, ect. Mostly just a handy-ness feature that I'm thinking of possibly expanding into area files, using special arguments so you don't end up searching every mod, room, and object for like, the word leather, lol.



In relation to your ending points, thats partly why I posted this: To get some input from others who know more about this then I do. I'm working on something that would be very similar to Smaug on the front, but with an almost totally diffrent engine. I'm hoping to avoid the flaws and problems the Smaug codebase has, while maintianing its strengths, and also not having to worry if removing code-block A will break everything, or if replacing code-block Z will royally mess things up. I'm hoping to keep things simple, yet powerful.

I also want to try and keep things open enough that if someone wants to add a feature, they can do so with a fairly simple proccess (maybe even allowing it to be scripted in and then run like that for a test, who knows).

Going back to a previous topic, I'm one for being able to work on a system that, if all hell breaks loose, then it suddenly stops (blu screen of death anyone?). My thoughts on the general development was to get a talker going first, then work from there, since that would be the very basis of the system, in a sense.

Hitting a point I missed previously, as for data loss, I'm hoping to be able (I'll need to find someone who knows a good DB inside and out to help with this) to keep from writing files in their entire form. I'd rather keep them to simple additions, revisions, and removing of data from a database, with an automatic back-up (depending on DB size, server speed, ect.) either every day or every 2 or 3 hours to keep things from getting too outdated, if something does fail.

I do have a question, though: Which would be better, to figure out how you want things to work up front, then work into the back-ends and core system, or to decide how to get the back-ends working, then get the front to work like you want?

It is gratifying to see someone else tackle a MUD codebase design. That is one of the most interesting things you can do. :)

I suggest you take a look at this thread:

http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=5959

In that I raise a whole heap of questions you might want to consider. I'm not saying I know the answers, but the questions themselves are interesting.



I think I see what you are trying to do here, the problem with hiving off various things into different threads (or processes) is synchronization. Assuming combat is in one thread, and movement in another, what happens if someone who is in combat, moves? Or, someone who is moving, enters a combat zone? Or, you use a skill while moving?

Probably the simplest thing is to simply save character data fairly frequently, so a MUD crash doesn't put everyone back to where they were half an hour ago.



I think you need to work out what you want the game to do first, from a design viewpoint. For example, if you have instanced dungeons, that will affect your code quite a lot.
Also, having X,Y,Z coordinates will affect quite considerably how you write the code.



Simply saving player data (location, contents of inventory etc.) should not take very long, and you could rotate the job (eg. save one player every 5 seconds, rather than all 100 players every 5 minutes).



Actually I wouldn't describe Lua as "grand". It is small and compact. Let me show you some comparisons:

• Lua download (lua5_0r2_Win32_bin.tar.gz) 72.5 Kb
  
• Ruby installer (ActiveRuby18.msi) 4.5 Mb
  
• Perl installer (ActivePerl-5.8.4.810-MSWin32-x86.msi) 12.4 Mb
  
• Python installer (ActivePython-2.4.3.12-win32-x86.msi) 18.7 Mb

Lua is the only one that comes in at under a megabyte, in fact well under (like, 1/10 of a megabyte).



I did a Tiny MUD server myself, is that the one you mean?

http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=4496

Good luck with the project, sounds interesting.

The X,Y,Z system I'm thinking of using mostly for combat purposes (and ambushes, but I'll entertain that a bit later). One MUD (Dack Legacy) uses an active system that has something similar, and I had been thinking about the same kind of thing, and it kinda got me to thinking about how it could add a new level to combat.

Example:

<room is 10x10x7. Character height comes into play here>

Player enters from North, and is placed at (5,5). Altitude doesn't play in right now.

Mod enters from South. Normally, it would put him at (5,5), but its occupied, so it places him at (5,4), 1 unit S of Player.

Mod innitates attack at range 0. Player "runs" to (1,1), and, being ranger, fires arrows while moving.

Mob follows, but is unable to attack due to range

<continue on>

I don't think the effect on move will be too much, and I think I could do it at least semi-simply, basing the whole system on direction and used space. The Z will make things like this interesting, though

Example:

Player reaches 1,1

Mob reaches 2,2 (range of 0 still, in adjacent unit

Player (halfling, 4' tall) "flies" to (1,1,4) <base the max altitude on height + units "flown", or subtract height from flight ceiling to give maximum altitude>

Mob (say, 5' goblin) swings at Player, but Player gets a bonus for A) Being higher, B) being almost out of reach

<change room now. Say its a 10x10x10 room>

Player flies to 6

Mob switches to evasive style (if its smart enough)

Player cannot attack via melee, so starts to fire bow.

Mob moves to 1,2, and starts to climb wall

Player remains in 1,1,6

Mob swipes at Player <insert long list of checks here>

Player moves to 5,5,6

<continue>


Personally, this all looks rather complex (My prompt code is going to be long, lol), but I'm hoping to make it simple(r) to use via built in reactions and the stance/style system.

Movement in general I want to keep simple, and I mean simple enough N, E, S, W, NE, SW, ect, will work (default them to the center of the room, or as close as possible), and depending I may see if I cann't just implement the X,Y,Z system in combat (make it like a virtual area of sorts) to also help reduce system overhead, but I'm unsure about which way to go.


Saving data I think I may do in one of two fashions:
Do it similar to how Smaug does it, and save automatically on some events
Timer-based (like what Nick mentioned)

Both have their up and down sides, both being:
If you save on events, you don't spend the CPU cycles to save pfiles for idling characters
if you keep it on a timer, you know there is less chance of missing something if something does fail.

I'm thinking atm to do both, like save on kills/exp gains, when you get something, drop, ect, and then have that add a timestamp to the file/entry, that is checked every, oh, 2 minutes, and if there hasn't been a save in X time, save, stamp, and continue.

As for trying to redirect input into the diffrent modules, I was thinking of running them through a parser to check where the command fits, and then run a system of checks to see about how to implement the system. Thats still in the works (as is most of this).

And yes, I ment your TinyMUD, Nick. It already has the very basics, correct? Since thats the case I'm assuming, I see no point in writing my own handler system for all that when one that is capable is already there.

-----------------------------------------------------------

On a side note, I was thinking of taking a *nix word proccessor, trimming it down, and using it for the text editor (maybe vim, or something much lighter if I can find it. Nano almost seems like a good idea on this, actually), so that people are not using a hacked up editor that handles like a flying brick.

-----------------------------------------------------------

In relation to that page you gave Nick, I'm looking over it. I've got two friends I'm going to talk to (they are players/admins, and not coders. I'm going to bounce my ideas off them and off this forum to see about feedback on what all to implement and whatnot) about all this, so hopefully I can get at least a skeleton design going.

If I need any help, I'll be sure to post it here, and in the mean time look into a few sources.

ALSO, if anyone has had any problems with design (ideas that are hard to run side-by-side, things that would conflict, ect), please tell me so I can try to avoid them. I'd rather avoid the major problems if I can.

One last thing: Flaws with a basic system (like DB problems, general data handling, and all that) that seem to be common, I'd appreciate some feedback on that. I want to try to keep this as simple on the back-end as I am going to try on the front, so the less I have to deal with trial-and-error, the better :)

Hotboot wouldn't really help you with a modular system, because hotboot reboots by changing the entire process. Even breaking things into threads won't really help you. The problem is that if one thread has a memory fault, it can bring down the entire program (with a segfault, for instance).

To be entirely safe you would have to isolate all of the threads into their own processes, so that one dying would not bring down the others. But now you have not only synchronization to deal with, as Nick pointed out, but also inter-process communication, which is a monster you really don't need to get into.

My recommendation would be to be paranoid as you program, write in fail-safes, and save data regularly. Modularity is very important in other senses of the term; honestly trying to substitute various pieces at runtime seems more trouble than it's worth.

Oh. These are game design issues more than programming issues. But, they're an example of how the data structures can limit your game design. I thought you meant not using booleans in your code at all, which didn't make a lot of sense to me.

What I suggested doesn't mean you can't use n/s/e/w/etc. It means that directions are symbolic rather than hard-coded, numerical directions. Does that make more sense? Basically you're mapping strings (e.g. "north") to exit structures, rather than integers (e.g. 1) to exits.

It might be more worth your while to use a powerful, external (and already written!) documentation system rather than try to code all this stuff into your codebase. A (perhaps read-only except for imms) help wiki would probably be a better solution than trying to make the in-game system too clever. Tying them together would be very interesting, though.


This could be accomplished by doing surgery on SMAUG, making it a gradual process. It wouldn't present you with such a daunting challenge, in any case. :) (And honestly, it might be a lot less fun, too!)

This would mean moving your code mostly to scripting. It's what we're leaning towards in BabbleMUD: use C++ only for the OS-level stuff like sockets, and using Lua to drive the engine.

I think it goes both ways, really. As I said, your back-end choices will dictate the universe of possible game designs. And of course, your design decisions will also constrain the back-end. I would recommend starting with the game design, though, because generally I have found that to be more challenging and the programming is (I find) a matter of expressing what I have in English for the game design. Programming first might mean you constrain yourself without having meant to, which can lead to serious grief later on.

A good idea, but keep in mind that most MUD clients, for various reasons, don't act at all like terminals, most notably regarding cursor movement. MUSHclient, for example, would not really be able to use vim at all; it just wouldn't work, because of all the screen redrawing vim (and other editors) do.

Basically the problem is that editors assume they can control the screen, going back and forth etc., whereas MUSHclient expects the text to be sequential. zMud has some support for this but as I remember (from admittedly several years ago) it was a little hackish.

It's sort of hard to list the most common mistakes. Basically the important thing is to be paranoid when you program and make as few assumptions as possible, and when you do make assumptions, make them explicitly and state them. A lot of mistakes (e.g. in messing around with SMAUG) come from quite simply not knowing what the assumptions were, and not realizing you're completely changing the assumptions by modifying an innocent-looking line.

I'm going to try to avoid using numerical code as much as I can. Hopefully that will make life a bit easier, both in maintaining and in expanding.

As for using a wiki-style help system, my biggest problem with that is how easily a player could access it. I've never seen a problem with the Smaug help system(s) besides some minor problems, and just making sure helpfiles are well written.

The point you made about scripting, actually, brought up a thought I had: I'm teaching myself Ruby atm, and am thinking of doing (when I start working on the actual coding) the initial coding in Ruby, and then once I shell out the basics, and can find the flaws with the system, I can then do the core coding in C++ to help, possibly, make things run a little lighter.


As for the text editor, I was thinking of doing some major work so that the escape commands were fairly compatable, hopefully. Its just one of those things I'll have to work on to make the editor compatable with a real word proccessor.

The wiki system would need to be tied in with your game's account/character system if you needed access control. But, that being said, I'm not sure why it's a big problem for players to see what the imm commands are. They're very likely to find out on their own anyhow, sooner or later, either by hearing about them from players/imms or just guessing.

Regarding scripting vs. C++, one thing to consider is that for a MUD, a scripting language is (probably) vastly sufficient in terms of speed. Unless you're doing something rather particular that just happens to be very expensive, scripting is fine. You get issues when you want to do OS-level things (e.g. sockets) but even then, most scripting languages have libraries that talk to the OS for you.

Your best bet is probably to do it in scripting first, and see what its performance is; it might turn out that rewriting it in C++ would be a waste of time.

The biggest problem with the text editor is one of cursor control. I expect that if I press the left arrow, my editor's cursor goes left. But MUD clients intercept that (in fact they intercept almost everything) and send it to the input box. I'm really not sure how you could make a more interactive text editor, although there would be ways to improve the existing one (maybe displaying a bit of the context of where you are, for example).

I'm just a fan of hard-coding the (mostly) final product, simply for the fact there is a lesser chance of something messing up, either from a messed up command (say, a missed rm?), or for a general system malfunction, because you are dealing with a binary, and not a text file.


As for the wiki system, I had a thought: Use global boards linked into the help system, so for instance:



and similarly:



and pass the notes through the PR imm(s) to have them posted. It would allow the players to give some general information (in limited format) to the players who may need help with something, while maintaining the helpfile system so that you KNOW there is help for something avalible.

With the cursors, there is the option of altering the code to accept commands similar to ^U to move up, and ^D to go down (which I think means you could, if you accessed through the shell itself, allow you to use Ctrl+Key to maneuver). Thats on the back burner ATM, since its of only minimal use without a real codebase.

I don't really understand your concern here. Why is a, say, .lua file more vulnerable than a .cpp or .c file? Scripting languages (including Lua) can for the vast majority be compiled to some kind of byte code if that makes you feel safer about it.

The issue here is one of display, not really of input. How are you going to show to the client that the cursor has moved? Would you reprint the whole line? You would have to, if you wanted to redisplay a line, because MUD clients typically aren't full terminal emulators.

Well, like I've said before: I'm still in the very early stages. I'll worry about the text editor later on.


As for the .c or .cpp files vs. script files, you don't HAVE to have the .c or .cpp files once its compiled, but then again I'm just weird when it comes to some thigns

Well, having the binaries without source is really just asking for trouble. I would suggest regular backups, or a CVS server on a separate machine (or simply a separate location on the same machine).

There are two main reasons I'm pushing this:
- it will take you a lot of time to rewrite code from one language to another, for perhaps very little gain
- you might find that some code in your scripting language is very hard to translate, because it uses idioms that C++ might not have natively

I'll keep that in mind. I may keep it to just script. We'll see how it all goes :)

Maybe I'll hard-code the core systems (that which won't need to be changed often), and then script the rest. I'll have to do some work with scripts before I make up my mind

I have done some preliminary work on writing a MUD in Lua, and the general idea has much to recommend it.

The problem - as I have found - with using something like C (or C++) is you have to commit to the data design early on, or have to recompile, and also change the loading and saving routines, for even adding a simple extra field (like a flag).

However by using Lua to actually store your data, since it has variables that can have any "type" (eg. number, string, boolean), you don't have to decide in advance what the various fields are (for a player, mob, room etc.).

Then you can save your player files by simply serializing the data back into a form that Lua can process (with dofile). For example:



Now if you later on add something (like "luck") then it just gets added to the list of things to be saved. If an existing player file does not have that field it will be nil, which you can test for. You can then make it take a default by using the short-circuit evaluation, like this:


player.luck = player.luck or 10


What this does is take the value from the file, or 10, if none is on file.