I think what we're looking for is basic improvements, not "features" that distinguish one game from another.

Like maybe someone has a really nice string.c to share.

Myself…. I suppose the obvious thing is my already released "reward" code, an improved autoquest.

There should be a goal in mind on what you want the project to achieve. Like with tbaMUD they keep to the traditional sense of what circlemud was. A easy to use multi-platform mud. Now enhancing the OasisOLC and DGScript features to make building that much easier for builders. Along with various other immortal commands and features, mostly all pointing to the same goal, the ease of use for immortals.

With RaM you should consider the same thing, do you want to use IvansOLC and clean it up to be easier on the builders while and more capable features to it. Or just write a new one from scratch.

Or is it going to go more player oriented, and add things for players? Depending on what the goal is, it might help people come up with better ways to improve on it.

– Elervan

There are still a lot of things that were not decided on in last night's roundtable discussion. Without coming to a decision on some basic things, the project will be delayed in getting off the ground. You make some valid points in your post, Elervan.



It was my hope that this project would improve upon the stock Rom 2.4b6 code by first debugging it. After that, features could be added that would allow admins to easily expand the game in whatever direction they choose. Adding a lot of classes/race/skills/spells won't really accomplish anything. It might even stifle the creativity of the admin that chooses to use RaM.

With that said, a solid decision needs to be made among those wanting to take part in the project. (1) Will we start with stock Rom2.4b6. -OR- (2) Will we start with Quickmud, 1stMUD, etc.?

If the decision is made to start with stock Rom2.4b6, what code will be added that is already in existence?

a) Ivan's OLC? If so, what version? As a builder, I vote for 1.81. It's a good system, just needs some debugging and progs reworked. I can vouch for MacGregor's prog system. It has a great deal of functionality and flexibility. At least take it into consideration. If it isn't used, he can offer some wonderful input. I understand Davion has done some interesting customization of OLC as well.
b) Erwin's noteboard system? Or will we go with a custom board system?
c) Color? Lope or custom?
d) Clan or guild system?
e) Quest system?
f) Help editor…definitely custom here I would think as my experience with the existing help editor system in QuickMUD is not the greatest.


I had also hoped that RaM could eventually be a place where fledgling builders could come for an environment that would encourage them to learn. They could stay for as long, or short, a period of time as they wanted. The builder could take the areas with them when they leave. Areas could also be released to the public similar to Romlama. Perhaps I'm getting off base, but these are some of the areas where I see a definitive decision needs to be made before work can really proceed. So many talented, creative people have signed on to help with this project. I think the work completed on RaM it will only strengthen the decision of many admins to use it as their choice for a startup codebase.

Any project of this size needs some kind of point person to organize, lead the charge, occasionally make decisions, and if need be, be willing to do more work than their share to get the ball rolling. It is an open question how this person(s) will emerge: it could be by vote, by natural emergence once work gets underway, by somebody just stepping up and saying "it's me" and getting approval, etc. But I think it's something that should be kept in mind as you go forward in this. It's one thing to have lots of people supporting and even willing to contribute, but you need a 'project champion' to keep things going.

I've got no dog in this hunt, so feel free to completely
disregard my opinion as it has zero impact on what you guys
are up to, but I'm kind of curious in that "how do other
people's projects emerge" sort of way, since I'm involved
in a codebase resurrection project of my own.

Having said that, I agree with David that big s/w projects
that succeed do seem to tend to have a point person, not
a committee. In my opinion, this tends to fail:

"Should we use Y? Or do folks prefer mX+b?"

This approach, from what I have seen, tends to signal
that a project is going to be more talk than action.
I'm not trying to harsh anyone's buzz here, just sharing
my experience. I've seen projects that are more process
than results because somehow nobody wants to be boss,
and as a result, somehow nothing happens. On the other
hand, this tends to win:

"I'm going to use Y because mX+b is a pain and I'm not doing
it. If you're with me, good. If you want to submit mX+b,
even better. Otherwise we're doing Y."

This works for a couple of reasons, paramount among them
that it actually gets code out the door, rather than
schedule meetings. It also signals that someone is
shouldering the burden of leadership, which opposed or
supported, is the key to success. Even if the leader
makes all the wrong decisions, her existence and
participation fires up the dynamic necessary to have
a vision coalesce that people are willing to contribute to.

I think that one of the reasons people want to avoid
that role is that it really kinda sucks. You basically
are managing always being wrong to *someone*, and it
often (maybe always?) takes a difficult balance of
both thick skin and sensitivity to the wishes of others.

But if you seek win rather than fail, someone's gonna
need to be up there taking the slings and arrows.

If you can manage not to take the inevitable drama personally,
it's a most rewarding experience.

-Crat
http://lpmuds.net

I agree wholeheartedly with Cratylus, and David. This is more or less how tbaMUD has been developed. Several people submit code, but only two people have svn access and therefore decide what in the end gets added and what doesn't. There's one lead man with tbaMUD that makes most of the decisions. Everyone who submits has an opinion and their opinion may be asked for, but in the end they don't decide if their submitted code actually gets added to the codebase or not. Strangely I have noticed though that many people seem to make a logical distinction that the most vocal person is is probably the 'leader'. ie. I've had several people in the past think I run TBA and am the 'head' person of the tbaMUD codebase, which I'm not, simply because I am the most vocal person related to it and have it in my signature on several mudding sites.

EEK, another novel sized posting from me. RUN!

Judging by Fizban's post, maybe I should just….. nah, you can suffer!

Yep, I agree. The question becomes, who knows ROM well enough to keep us in line at building a fixed-up, builder-friendly ROM derivative, instead of another add-more-classes/races/bubblegum-cannons monstrosity? I think I am reasonably good at the fixing, and probably decent at wanting to add builder features rather than game features, but I'm no Romulan!


I couldn't agree more. I'm all about mechanics. If we, for example, add the ability to give people multiple (or no!) classes by extending the data structures and underlying engine – that's making the lives of future admins easier. But since we want it to still work like a ROM (which is single-classed), it should ship with all the settings set to only allowing 1 class.

Leave it up to the local mud admin to actually add classes/races, or rebalance the data so multiclassing is the right difficulty, etc. That's gameplay mechanics, and I think that's beyond our scope.

For me, the question is simply a matter of simplicity. Does QuickMUD (or whatever) offer us a leg up on what we already want to do, or would we spend as much (or more!) time ripping things out and replacing them as just adding them to stock ROM to begin with? I'm not yet qualified to answer that, as I haven't looked at anything BUT stock ROM yet.


I think we actually did agree on Ivan's OLC 1.81. Fixing that, and adding to it, would be a solid direction to head, and it would keep us grounded in what people expect from a ROM base.

Is it stable and reasonably well liked? If so, that's probably a winner.
I see a board system as functionally similar to a mail system, so if it supports sending private messages, we'd get a nice consistent UI. If not, perhaps it could be extended to do so. It would also be a plus if you could have multiple physical boards link to the same data files…. IE: I can set message boards in several cities that display the same stuff, but have other private ones for guild halls, immortals, etc.

I think, in the interest of sanity, we have flogged that horse so far into the ground that the bones have cracked. We have to use Lope's. We can always extend it, but not starting there would just be obstinate at the expense of our potential customers, who will expect it to work that way.

Yes, and yes? :)

Players should be able to form their own personal clans/guilds/whatever. They expect that, and our code should support doing so. At the simplest level, it's just a tag that shows up in who, or when you look at someone. How far we want to extend that is another question… and there's a line somewhere that crosses from being an admin feature to being a game feature.

I would suggest doing the code that allows forming/disbanding them, joining, kicking, setting ranks, and private channels. But anything beyond that is drifting into gameplay mechanics (IE: guild halls, taxes, etc). Let the individual admins do that part, or we could release snippets later if someone really wanted to do that.

Another type of "guild" is what I think of as a soft class. That is, rather than setting a fixed class when you create your character, you can join "guilds" to gain your abilities. That is almost certainly outside the scope of this project, as it changes a fundamental way that ROM works. However, if the game could handle multi-classing, it could in theory be extended to handle these too… but that would be an exercise for the user.

At the level I'm looking at it from, it boils down to having things that care about class doing if(has_class(ch, foo)) rather than if(ch->iclass == foo). That's the kind of architecture improvements I'm hoping to see.

Hmmmm… That's a tricky one. It's very close to gameplay mechanics, but perhaps adding an underlying system to set bits on a character as tokens for having done things (Rutner's bit system sounds like a win here), and an editor to let them assign groups of those bits to "quests", with text strings as descriptions…

The actual mechanics of having mobs act on them, having objects/rooms/etc. respond based on their status…. that's gameplay. We might provide hooks into the mudprog system to test or set such bits though, then the builders themselves could do the rest.

To me, ALL editors should work the same way. Nobody wants to learn 50 different ways to do the same kind of thing. So, if the existing help editors don't work, we build a new one that has the same UI as Ivan's other OLC editors.

I think modifying anything that's data should be something you can accomplish from some in-game UI. Doing away with all the hard-coded limits and vnums is something that should be kept in mind. Ideally, you should be able to remove every area file, boot with an empty list, and just have the game default you to a single room (the void).


Even though that's a different side of the project from coding, I agree that a builder's site is a good thing, and an area exchange is also good. I would argue against us using the stock ROM format as our native file format (because, it sucks), and I think we covered that pretty well too. I'm absolutely in favor of being able to import stock areas, and being able to export them AS stock, allowing for the fact that we may have features that can't BE exported to stock. As long as that's an ok stipulation, it's all good. :)

And I just quoted the whole dang thing :devil:

This is how I see it too. We're not trying to make ROM a better game, we're trying to make a ROM that has better tools so the admin can make a better game. As such, we ship a game with levels and one class per player (ie, we don't go classless and/or levelless; leave that up to the admin). The game should have 60 levels just like ROM, but it should be possible to easily change the number of levels; preferably just by changing MAX_LEVEL in merc.h, make clean and make. Etc.

Since we already have a start with ROM2.4b6, why don't we stick with that? I really don't see it as a big issue to add olc, progs, etc. And it'll save us the trouble of ripping out a fair amount of stuff.

Actually, no, we didn't agree on Ivan's. I think the whole discussion was more or less along the lines of someone saying "Okay, let's use Ivan's. Next topic". Be that as it may, we can use Ivans. But I'd like to mention that I have an OLC that wouldn't take all that much to drop in. It's based on ILAB/Isles OLC, same thing that Ivan's is based on, and it's similar enough to Ivan's that builders who have worked on ROMs had no trouble at all picking it up. It's also been extended quite a bit; it features the following editors: aedit, medit, oedit and redit of course, mpedit, opedit, rpedit and epedit for mobprogs, obj progs, room progs and exit progs respectively, board edit for the noteboard system (so admins can add/change boards, set access limits, etc), clan edit (if we choose to do any clan work), command edit, hedit, racedit, skill edit, skill group edit and social edit. It's been in use for several years now, although it continues to evolve, and has been used to build something over 200 areas.

Erwin's has a couple 'quirks', and I've met a number of people who don't care for it. Its biggest selling feature, I think, is that it's somewhat better than stock. It's pretty stable as far as I know, though. I've got something along those lines I'd like to show the group, though.

And here we get dangerously close to exceeding our charter. I'd say that any sort of clan system should be minimal, if we do anything at all. I can see providing a framework perhaps, but that's about it.

I'd say that adding a quest system would be clearly exceeding the charter we've set for ourselves. Having said that, let's face it: Vassago's quest system is probably going to be one of the most popular snippets for this thing. But there are plenty of people who don't like its simplicity, especially as is. So I don't think this is something we should include.

See my comments on OLC above.

I too would argue against using the ROM format, for the same reason. I think we've all already agreed, though, that we need to be able to read stock ROM area files. Since it's likely we'll be adding to the information stored in them, exporting them in stock format may be problematic. I think we should make a good faith effort to do this, but it shouldn't be an ironbound requirement.

If a quest system is added, it should be as abstract as possible. A quest -system-, not quests.

Give mobs several different quest types to offer (fedex quest, kill quest, kill/harvest quest, escort quest), the player accepts the quest and the mob that gave it flips a bit, and adds a struct describing the quests type to the player Whenever certain events happen (player kills a mob, player gives mob to item, etc) the mud would check the struct to see if the event is important to the quest(s) the player is on, if so, increment them towards completion, if that finishes the quest, notify the player they can go turn in the quest and receive their reward.

The leave it to the builders to actually create the quests.

I'm fairly sure this wouldn't be too hard to write as a system, and willing to do it if it's something that is wanted for the RaM project.

That's fine with me. I just don't want to re-re-invent the wheel.


That's the main thing. I'm not a native ROM speaker, so I'm always inclined to take the pulse of people who do use ROM and know it. I don't think anyone will care where the underlying code comes from, as long as the UI works rather like what's popular, and it's mostly bug free.

By all means, let's take a look!


Same here, and I'd say there's even more leeway on a mail/note system. People expect color to work like all the other ROM's. They'd generally prefer OLC to be familiar (as opposed to a totally different feel, like Oasis from Circle, or Smaug's OLC). A note system is more likely to be judged on nice features and no bugs.


That's what I meant. Providing the data structures, file storage, routines to mange people belonging to the guild… those are all tools that work pretty much the same for any player organization. Anything else beyond that is game mechanics, and not our job.

I consider quests the same class of thing. Providing a way to store arbitrary bit sets, and hooks into the mudprog code so they can check if a particular bit is set, or toggle it. That feels like utility. Making that into "quests" is gameplay. You could just as easily use such a system to track what rooms you've explored (by vnum).

I'm delving into the gcc 4.3 bugfixes. Boy, what a mess. :)

Of course, this all has to be done to the code we merge in (OLC and everything), but at least I'm remembering my C coding style.

One thing I have observed with the FUSS project that might be relevant to this… While in the beginning it was more about fixing bugs, more recently it seems to be less clear what the exact mission statement is. Now, things like the weather system have been added – major feature changes that are far beyond the mandate of fixing bugs. On the one hand, presumably improving a codebase is great; on the other hand, it is obviously not just fixing bugs anymore. If your mandate is fixing bugs, and somebody proposes a feature change, you can easily get away with saying no because it's simply outside the mission statement. But if you start making feature changes yourself, you now have to justify why some features would make it in and some wouldn't.

Seeing some of the discussion here, it looks like many fascinating features are emerging, but I also have to remind myself that people aren't talking about making a new codebase. FWIW, I think that the mission statement should be laid out and agreed upon: what exactly are people trying to do? The nice thing about fixing bugs is that that goes into pretty much every mission statement, and so is a great place to start work as you hammer out the rest of it. :smile:

If we have a charter, it arises from someone pointing out that while other codebases had been handed off and were continuing development, ROM was released in '98, had some popular patches installed in '01 to produce QuickMUD, and has lay fallow ever since.

While there is obviously virtue to maintaining the look and feel of ROM, as Hartley Peavey is fond of saying, "If you want to be better, you have to be different!" What people are used to is QuickMUD. What they want is something better. Using Ivan's code, at this late date, would seem pointless to me. If we don't have something better to offer, what do we have? QuickMUD will always be there for those that want "the same old thing".

Stock ROM has some bugs that need fixing. The areas need dependencies removed. Perhaps the spell "slot" numbers should be removed. Each skill and spell has a value for level and difficulty. These could be replaced by types, as that would make expanding the classes and races more feasible (Sure, const.c looks fine now…). ROM needs more bits. There's a lot of old, space-saving code that seems really silly if you step back and look at it. Players are mobs. With extra stuff. Despite all the times it's been done, I still feel ROM is a poor platform for PvP because the mobs and players are so different. ROM cripples the leveling power of high level Mages for the sake of the pride of Warrior playerkillers.

Again, sticking old, broken snippets in an old, tired codebase has been done. It's what we had at the time, and at the time none of us were well informed (ain't hindsight wunnerful??). To hold it up as a "standard" is begging the question, IMHO.

I wouldn't be at all surprised if this project follows in the footsteps of SmaugFUSS and tbaMud. Initially we want to focus on bugfixes and cleanup, and providing admins with the tools they need to create their own game. Later on we can look at features that would truly enhance the system and have widespread appeal. Our guideline should be "is this proposed subsystem going to be something that a significant minority of admins would rip out?". As I mentioned elsewhere, Vassago's quest system is likely going to be one of the more commonly used snippets in this thing. But if we added it ourselves, I think there are a fair number of people who would rip it out again. So IMO we shouldn't include it; nor should we add another system that would preclude people from adding Vassago on their own. Contrariwise, although I'm not familiar with its implementation, FUSS's weather system is something that sounds to me like it's a good addition to their system.

The above is strictly my own opinion, by the way; if most of the others working on this thing think I'm way offbase I'll shut up. :smile:

Something to keep in perspective. Though the SmaugFUSS weather code is somehow being spun as a feature addition, it's actually not. Stock Smaug came with weather code already available. That weather system was not terribly good, and had some issues that people wanted to see fixed. A lot of debate went back and forth about how to fix that. Sticking strictly to "fix the bugs" would still have left a system that wasn't all that useful. I know of plenty of people who ripped it out, even though it's stock. So when it came time to act, Kayle stepped up with good solid weather code that is functionally superior in every way to what Smaug offered stock. He incorporated into it many of the things people wanted to see done, and the result was a vastly improved system, but it was still a system which existed before. I don't think that fixing something should be strictly limited to "make gcc shut up". If a system is poorly designed, I don't see it as out of scope to replace it with something that does the same in a better way.

The argument about adding on to the base is more appropriate to bring against the addition of MCCP support, and hotboot/copyover. Those things were never present in any form in the codebase to begin with. But it was widely known that they are popular additions as snippets, and indeed became two of the top support questions when people tried to add these themselves.

For just starting out, my feeling is it would be best to pursue getting the codebase to compile clean on gcc 4.3 with the default Makefile. Then tack on a couple of compiler flags, and clean those up too. Then a couple more, etc, until all of the desired flags compile clean. That alone is going to take a heap of effort, but will be worth it.

Once that's done the next logical step is to collect various bugfixes and apply those. I see some effort is being made toward that already. I'm not sure how well organized that kind of thing is for Rom, but it might be a good idea to get them setup into some kind of tracker. Even if they're just crappy forum posts like we use over at SmaugFUSS.

Once whatever fixes exist are applied, and documented somewhere accessible, then moving on to widely popular additions like color and OLC should be considered. Stuff that pretty much everyone will demand anyway that wouldn't make sense not to add. I imagine copyover will be among those. Just avoid using crashover code :P

Thanks, Samson. You say it better than I do.

Ok, here's something that is partly a bug fix, partly a code refactoring, and partly a new feature. :)

In my week of refactoring pleasure, I've pulled the bug() and log_string() routines out into their own file, with every intention of turning them into varargs functions (actually, merging them into one thing) with #defined macros to support the old syntax.

I already have a nice set of macros (log_bug, log_boot, log_info, etc…) and a bug routine from my own game, and I'd be happy to contribute that as a more flexible system. It only needs a few tweaks to adapt to ROM data structures.

However, before I just jump in and do it, I wanted to ask you guys how attatched to the "standard" log file format you all are? IE: Are there lots of log analyzer programs you all use, or do you just grep for things like I do?

MY format is a little different…. the date is compressed into something easily sortable (YYMMDD.HHMMSS.USEC). I could change that if it drives people nuts – I like it because it sorts clean.

After that, is the type of message (BOOT, ERROR, etc), then the environmental info (file/function/line #'s or ch/victim/room), and the actual message. Here's a couple sections from my logs so you can see what it looks like in practice.

If you prefer, I CAN just make it look like the more boring original output, I just figured I'd run this by ya'll as an idea and see if anyone's reading the forums this afternoon. :)

<: 1081019.192623.678 - BOOT - (db.c;load_db,284)
 : - Assigning command functions
<: 1081019.192623.681 - BOOT - (db.c;load_db,286)
 : - Assigning spell functions
<: 1081019.192623.685 - RESET - : Zone Reset - Limbo (0-10)
<: 1081019.192623.694 - RESET - : Zone Reset - Immortal Realms (11-1150)
<: 1081019.192623.724 - ERROR - (board.c;CloseBoardFile,114)
 : CloseBoardFile
<: 1081019.192623.753 - RESET - : Zone Reset - Woodland Glade (1151-1349)

and

<: 1081006.022453.069 - KILL - ch "Karrn, the Legendary Black Dragon of Despair" [#20950] victim "A large bat" [#20950]
 : A large bat killed by Karrn, the Legendary Black Dragon of Despair at Dense fog
<: 1081006.023014.067 - RESET - : Zone Reset - Cemetary of Shylar (25201-32000)
<: 1081006.023520.813 - INFO - (interpreter.c;nanny,1035)
 : Got Connection from: localhost
<: 1081006.023520.820 - INFO - (interpreter.c;ValidPlayer,1600)
 : Password checking disabled!
<: 1081006.023520.928 - INFO - (interpreter.c;nanny,1071)
 : quixadhal@localhost loaded.
<: 1081006.023523.568 - AUTH - ch "Quixadhal" [#-1]
 : WELCOME BACK Quixadhal (adork@localhost/127.0.0.1)!
<: 1081006.023525.066 - INFO - (interpreter.c;nanny,1337)
 : Loading Quixadhal's equipment
<: 1081006.023525.096 - INFO - (reception.c;load_char_objs,257)
 : Char has no rental data
<: 1081006.023525.101 - INFO - (comm.c;dump_player_list,1528)
 : Dumping player list
<: 1081006.023529.319 - BOOT - (act_wiz.c;do_shutdown,1656)
 : SHUTDOWN by Quixadhal at 3:35
<: 1081006.023529.326 - INFO - (weather.c;update_time_and_weather,369)
 : Time update.
<: 1081006.023529.329 - INFO - (weather.c;update_time_and_weather,376)
 : Weather update.
<: 1081006.023529.333 - INFO - (comm.c;close_sockets,1018)
 : Closing all sockets.
<: 1081006.023529.338 - AUTH - ch "Quixadhal" [#3008]
 : LINKDEAD Quixadhal (adork@localhost/127.0.0.1)!
<: 1081006.023529.343 - BOOT - (whod.c;close_whod,188)
 : WHOD port closed.
<: 1081006.023529.347 - BOOT - (ban.pgc;unload_bans,190)
 : - Unloading banned name list
<: 1081006.023529.350 - BOOT - (ban.pgc;unload_bans,196)
 : - Unloading banned ip list
<: 1081006.023529.353 - BOOT - (comm.c;run_the_game,241)
 : Normal termination of game.
<: 1081006.023529.364 - BOOT - (comm.c;main,207)
 : Disconnecting from database!

I personally value progress over keeping things the same just for the sake of keeping them the same.

But if the weather system is just a feature fix, and not a feature addition, then this is surely also just an improvement since its scope is much more minor. :tongue:

I think the log sample you presented looks better, and is probably the way to go. I always had difficulty finding things i was looking for in the logs with standard rom logging.

Hmmm….

Can't read your dates, even with a clue. Could it be you need to sort by date because you've split the log so sequential messages are no longer together?

The first thing I did after installing OLC was squelch those loading messages. I guess it's understandable the authors got terribly excited when something actually worked, but I prefer not to clutter my logs with things that ought to happen. Makes it easier to see what shouldn't happen. Now, sometimes, it matters whether players are on, sometimes it doesn't. I'd like to see groups of error messages that could be turned on and off "on the fly", depending on current debugging needs.

It looks like his dates have an extra digit in them: 1081019 should read as 081019

that said, I much, much prefer putting in four-digit dates: 20081019
or even better for readability: 2008-10-19