I like the concept Hades, think of this too, have areas by 'theme'.
Then if a builder wanted to delve into any one theme, he/she could sit down and put out areas to that effect. Like others, I don't _always_ want to build in the theme of my game.

Honestly too, the areas don't have to be monstrous world changers… One of my favorite stock areas is trollden heh, and it's like 10 vnums. Just a fun little 'POW have some adventure' area.

Think of them like the old D&D modules, add which ones you want, play house rules (rewrite heh), have fun with em etc.

That, I think would be a benefit.

While I think this would be an ambitious project, I would hardly go so far as to think that it would appear in every stock MUD. And if they did? My ego would be pretty pumped up having created such popular areas :p

Overall, as far as serious game developers ripping out the stock areas, I think that generally has more to do with the areas not fitting their theme or the areas not being of very high quality. Sure, a lot of people tear them out because they want to be all original, but I don't think that having some repeating areas between different games is a really big negative. Plus, with as "late in the game" as this would be coming into play, I don't think that would be quite as much of a concern.

The outcome of such a project would be hard to predict, surely, but I think its at least worth considering or discussing :p





Oh, I gotcha! I thought you were meaning why should -we- waste our time, not why would someone who is making a MUD want areas a bunch of other people have.

I do think that is a concern worth considering, but some of the most fun MUDs I've ever played had Midgaard, Dwarven Daycare, the Mob Factory, etc. Some people might really just be more concerned over the code aspect of the game and expanding on what's already there. I can't really speak for them, because we've torn out so much and worked so hard to have a very specific theme going on in our game, but with as many games that are out there have stock areas, I think it would stand a chance.





That's kinda of what I was considering. There could be a small handful of space themed areas, some fantasy, some mythology, some modern… Basically whatever a person felt like building. As far as the code aspect of the codebase, I think it would be beneficial to improve upon some of the systems that I think are definite weak points in the codebase. I'm sure many of us could really just work in some improvements we've made on our game and throw those into codebase.

If my area credit snippet didn't require new values added into the area files, that's the exactly the type of thing I would think would go well (and part of the point here, in my mind, would be to have the ability for plug n play areas). Other things like how we've actually made material matter and come from a table of defined materials would work well too, but again, that would be an issue. Actually, the more I think about it, the more and more of the improvements I could think of would actually keep the areas built in that codebase from working without any modification in others. So maybe it would be better just to focus on only area development unless we wanted to kind of work on our own branch like that which would basically be an improved ROM.



Yeah, I think something like that would work really well. That's what I was thinking in regards to basically have a codebase setup with the express purpose of "Hey, here's a good starting point, and there's already content you can pick and choose from!"

I clearly have some conflicting ideas on the direction I think would be best. On one hand, working on a collaborative area building project would be neat and maximize the ability for the areas to go wherever, but on the other hand, I think what might would be really good for ROM overall would be a collaboration that included new, immersive areas, but also improved features in the codebase that are obviously unfinished or just plain sloppy.

Anyway, I think this would be a good discussion to continue and see how many people might would be interested in such a project, and what the different ideas on how it should be approached would be.

If this is something that is going to go forward, I've got server space I could make available. I could easily host a stock Quickmud, make the area directory browsable so you can download your finished area, and just leave it for people to use as a building spot.

Keep in mind that the original areas in ROM were Original Areas, originally. :grinning:

DeepMUD still takes stock ROM area files, thanks to my preference for Gammon's Area Edit. And, as I find many of the old areas more entertaining than new ones, we have most of them still in play, and they've been edited and balanced for eight years. I'd be happy to make those available.

As to the code, I'm going to leap over asking if there is interest and propose two projects:

A QuickMUD deriv with the best of the old areas and an equal number of new areas. The codebase would get a onceover to fix remaining bugs and some small improvements could be made. This would go a long way to solving one of ROM's pitfalls: many stats are far out of whack. There are too many good weapons and soft mobs. With tighter balance, new admins would have a better chance of making things work.

A QuickMUD deriv jointly worked over by whoever wants to contribute. This would involve new features, not just fixes. In essence, instead of releasing our own codebases, we'd all be taking the best bits of our ROM hacking and releasing them together. I think this would take a bit of planning so the end result was neither pot pourri nor too focused on any certain style.

The last idea that comes to mind is putting up a place like TBA.

I was about to say the exact same thing, i have the space on my sever to offer the same if it was required, i think a project like this is a great idea and i like would offer my support in whatever way i can even tho i am not even a ROM user.

I've put up a stock quickmud that can be used for building at mud.entropic-dreams.com 4000. After you login, type "build" and you will be promoted to level 57, with security 9 so that you can use olc and necessary immortal commands. The area directory for the mud can be browsed at http://mud.entropic-dreams.com/area/. I beleive I have everything set up right, but if there's any problems just shoot me a PM.

I absolutely love the idea! Where can I sign up?



Hmmm that was quick, too :) So, who's in on the project?

And you thought I'd fallen into some cosmic rift or some such bunk eh?

Well, specifically which sorts of code fixes/changes would be necessary to bring rom to a more up to date? In quickmud there's the board bug I saw posted about recently, I'm fairly sure the Killer flag bug is still in (charm a mob someone is fighting, they get killer flag, then you kill them.) But other than that, I can't think of any bugs in quickmud.

As for small/medium changes, I think probably the biggest things that need changed are usability issues. Get rid of the limited bit system and put in a simple unlimited bit system, reorganize const.c to reduce redundant editing when adding classes, flesh out the clan system a bit more, finish the material system, make mobs use mana when casting.

Larger changes would be adding room/obj progs, and perhaps creating a better language for writing such progs in. (I've always hated mob-progs), and improve mob combat AI maybe.

I'm currently stuck in a rut on my current project, so I have some time to spend on this, and am more than willing to colaborate with anyone else who wants to work on it too. *laughs* as long as there's people to help provide direction.

Well, you could always make sure it's not suffering from a lack of const correctness, or any of the other strictness that GNU has been introducing into the compiler(s)* lately.

You could always remove the need to add classes in the code by making them OLC, and same with Races.

Or if you're really looking to bring it up to date, you could change it all over to C++. (But I guess not everyone is as insane as I am, rewriting smaug bit by bit to uses classes and encapsulation.. Meh. Learning a lot though. :P)


* - I'm not sure if gcc is getting the same strictness applied or if that's just g++

The latest version of gcc did indeed become stricter on a lot of things, but at least a fair amount of it's been covered already by the person who put together quickmud. To check this, i just recompiled stock Quickmud with -Wall -pedantic, and got something like 5 interesting warnings, 2 pointless warnings, and several i have no idea about. *laughs* (comm.c:2405:27: warning: non-ISO-standard escape sequence, '\e')


Moving classes and races into olc is certainly doable, Ivan already did it in olc 2. I didn't really much care for it though. It's not something you should be editing often enough to need an editor for imho, but neither is it as simple as it could be for a new admin.

As for bringing it to C++… :rolleyes: no. :P

More bits! (absolutely)

Reorganizing the spells is a great idea, but I didn't do it. What do you suggest?

I'm iffy on Clans. Not that it's not a skeleton, just that it would be an easy addition for a newbie.

Materials need a purpose. That might be a Phase II project.

Again, I'm not sure making mobs use mana fixes much. Though I've always felt the PvP flaw in DIKU was the mobs have a different structure. ROM, in particular, hamstrings Mages for PvP purposes so their high level soloing consists of blowing out their mana on maledictions then scratching the mob to death with a dagger. Maybe Phase II? Tell me more.

Myself, I'd fix things like the pulse system, mstat and ostat… gee, it's been a while. My notes don't go back that far. ;)

Anyway, don't mean to be negative, I just tend to be conservative (especially before my first coffee is done). I'm open to convincing.

Well, i'm not entirely sure what I would do with spells. I thought about attaching an array to each class that holds the spells/skills/groups it gets, the level it gets them at, and the cost for them. That way if you add a new class you only have to update it's information, instead of scrolling through all 200-300 skills/spells you might have.

Clans: True, it would be an easy addition for a newbie, better maybe to completely rip it out so the skeleton doesn't get in the way

Materials: I'd gotten the impression from reading through the code that they were intended to increase the durability of an item, or modify the damage they dealt, but that the item damage code never really got written, nor were the modifications added.

Mobs using mana: The reason i think this needs to be done is as a first step in replacing the standard spec_breath_any, spec_cast_adept type things. I imagine replacing them with the ability to simply add a list of spells/skills the mob can use while you're editing it in medit. Maybe the ability to create different packages of spells/skills in game. (that's something you might change often enough to warrent an editor)

What exactly do you want to work with on the pulse system? It's one of the things I never really messed with.

More bits is nice but in all honesty I'd go for something more like a hash map than using bits at all. Of course this has its drawbacks, it's more ideal but also requires a far more skilled programmaer and is more initial work.

Hash maps and bit vectors are pretty different concepts, no? I think the idea is to replace the current one-number-only bit system with something that lets you have an arbitrary number of bits. The correct abstraction for this is just a set of booleans. How you implement that is kind of immaterial but a bit vector happens to be the most memory and time efficient way. Wrapped in proper helper functions, you can transparently have as many bits as you want…

EDIT: incidentally this is the kind of stuff that's a lot easier to do transparently in C++… you don't need to convert the whole base to C++ in order to use C++ features.

There may be some other bugs still in place such as being able to order a charmed mob to perform commands like 'mob oload' or other "mob ___" commands.

I'm not sure how many bugs are in the codebase by default, but there are small loopholes like that I'm unsure as to whether or not have been addressed in QuickMUD. We started out as stock ROM, so there have been a lot of things we've had to add in or change ourselves.

Like Sandi I think we are looking at two options, 1) fix some bugs and focus on areas, 2) fix some bugs, build some areas, update the codebase. It sounds like we have a number of individuals on board with this so I guess we should decide which route we should go with it.

If we go with #2, I think its also worth considering whether or not we would want to limit ourselves to making sure that the areas would be plug-n-play with other stock ROM games. I know a lot of the mobprog and OLC improvements we've made (that's been one of my main focuses as a coder) would make such areas require some form of conversion to work in another ROM game. Like Sandi, I also do see merit in pooling many of our improvements into one codebase. I know I have no intention of releasing End of Time, but there are a number of things we have in the codebase I wouldn't mind seeing getting more use than just outside of our game.

So I guess the question becomes for any interested parties:

#1 or #2?

Personally, I'd vote for #2.

Updating the codebase and making it easier to customize and build will, itself, encourage people to use it and build new areas with it. That's a good thing!

As for compatibility with stock ROM…. I guess I wouldn't limit the updated driver (which I can't resist suggesting the name RAM – Rivers and MUD) to stock only, but I would put code in to allow it to import stock areas. It might be possible to allow it to export a limited subset AS stock areas too, just in case.

I'm also in favor of ditching the bits entirely. It's much more portable and clear to have code that does if(room->isdark && room->isoutdoor), rather than trying to cobble up macros. Yeah, you have to do a pass to replace all those chunks in the code, but it's not a huge deal, and it makes debugging or moving storage to a database much easier.

Yes, it would take more memory unless you used C++ booleans, or C bit-fields (messy!), or a set of bit vector macros I suppose, but still… how many people are really having problems running out of memory these days? Even replacing every bit with a 8-bit unsigned char would probably still keep our memory footprint way under something done in Java, for example.

Java memory is worse than C precisely because they do the kind of thing that you suggest isn't a problem. So you might be surprised if you were to compare memory footprint of your proposal to Java's. :wink: The memory consumption of a Java program isn't as utterly terrible as most people seem to think. A small program will look bigger than it should be because it's loading up the JVM, but that's a one-time cost and not proportional to the amount of memory actually used by the program.

Anyhow, here are some numbers. For now let's not consider structure padding. If you assume 32 bits, each going to an unsigned char, that is an increase of 32*7 = 224 bits = 28 bytes. Assuming, oh, 5,000 characters, 10,000 objects, 5,000 rooms, each of which has flags, that is an increase of 560,000 bytes, which is indeed not really a problem. (Same goes for Java, ne?)

Note that if you used OOP, you could keep the bitvector efficiency, and still have convenient access via methods like room->isDark().

I, personally, would go for option number two as well. Partly because i'm a crappy builder. heh. Though i feel it's important that changes stay with the feel of rom.

As for the bit stuff, there's at least one already written, pure C option that you can simply drop into rom fairly easily, right here in mudbytes repository. (http://mudbytes.net/index.php?a=files&am...) As far as i can see from looking at it, you use it in very close to the same way you do roms current bit functions with the exception of only being able to check one bit per line.

As a builder, I can tell you that being able to search and replace bits in .are files by their flag names would be heavenly.

That part is easy. AGES ago, I converted my old Diku to use ASCII file formats, and taking it a step further so that you read and write strings instead of numbers isn't at all hard. Yes, that new format wouldn't be compatible with stock ROM bases, but the new game could easily look at the first (non-comment) line to see if it's a "new" file and work accordingly.

For example:
instead of storing the room flags as "124" which is 64 | 32 | |16 | 8 | 4, better known as NO_SUMMON | NO_STEAL | PEACEFUL | INDOORS | NO_MOB, you can simply store it as a string like:

RoomFlags NoSummon NoSteal Peaceful Indoors NoMob~

That can easily be read in with standard routines, and with a key of RoomFlags, you route it to a routine which splits the string on whitespace and looks up the flags. That's been done.

The trick is, providing data fields to match each entry in code means the code also becomes easier to maintain and modify. Want a new flag? Fine… add a new field and the appropriate chunks to load/save it and you're done.

David's suggestion of using bitvectors and accessor functions is perfect, if you're willing to go the C++ route. That's another question. :)