I know that one of the main goal's of this project is to update the RoM codebase from C to C++, to clean it up, take out some of the fat and make it more efficient. But, featurewise, are you looking to improve it any? As I said, I will likely try to look at the code when you get a release version, because I want to learn more. But my biggest contribution to this would consist of useful ideas that would add to the codebase as a whole. Some of the ideas could be challenging, some could be fairly easy, but the question is whether or not you're willing to consider adding to the codebase with new features, etc…
The initial goals of the project, as I understood it from my outsider's perspective, were to just clean things up and modernize the code, not add new features. But of course, as with any such project (including FUSS, for instance) the itch to improve gets stronger over time, and besides there is a fine line between merely modernizing a feature's implementation and actually improving it as far as the player is concerned.
I've done a ton with OLC that I wouldn't mind sharing if people want. Basically more information when building, so like say liquid containers show drinks vs liquid type, alcohol percentage etc. Or like items have limits based upon game limits (IE a sword is D4-D12, but if we did a short sword say D4-D6, or a Dagger is a D4 weapon). I know they could seem limiting but it seems to help keep a handle on stats. Also checks that X info put into X vfield is the right kind (basically so you don't end up with it just reverting too 0 on some table because it didn't find the thing on the table).
Another thing, fountains in RoM were never finished; I've gone back and made them empy/refill as people use them (refill in update.c X amount based on total volume).
Anyway, there are _tons_ of changes that I'm sure we've done to our games that don't affect area formats and more, that maybe we want to have a kind of 'committee vote' on? Propose X change, here's the code, here's the overview, etc etc.
Oh, another thing is IN gameplay. I did a command parsing within the functions to strip out words and arrive at 'get map box' from 'Get out my map from the box', basically with every object interaction command. The idea being that the game works for new players also, rather than frustrating them with the 'why can't I get my sword from my backpack?'.
(I know this thread is going to blow-up with suggestions)
Maybe another thread is a better place to discuss new feature suggestions, as opposed to discussing whether new features are even appropriate in the first place. (Ideally, actually, there'd be one thread per suggestion, to keep things organized and manageable.)
EDIT: that said, I think your suggestions are excellent and should definitely be considered…
Yeah, I just posted this one to ask before I exerted the effort. But after having played the MUD I play for a few years, I've run into many things that are certainly doable, but no coder for the game wants to implement them because they want to add more new stuff as opposed to a smaller feature that, while nice, is not on their list. Custom code bases can get bulky, etc… having more of those features in the stock code would be extremely valuable.
I think so too yeah. Ones like OLC improvements that don't change the game format/etc, might be allowed? It's hard to say I know, basically they just give the builders information (and limit fubar building). Perhaps if they were all in merc.h as a #define AXE_DICE_MIN 4, #define AXE_DICE_MAX 12, and then people could simply 'uber-ify' things in merc.h if they wanted. Anyway, we'll see how things go. I know I've got loads of those kinds of modifications to OLC (started as a builder aeons ago, was frustrated that OLC blew).
I would love to give the code for X, Y, and Z, but unless I can get up to speed on C++ really quick (and that's doubtful with my workload) the best I can manage is pseudo-code. The hope is that the idea is reasonable enough and enticing enough that coders wont mind adding it in.
Well, I guess the best way to tell is whether or not you are using the "-ansi" flag for gcc – anyhow just curious because you specify ANSI C as opposed to just C, so I was wondering if you had a reason for using ANSI C. There are some things that gcc/friends let you do in C that they don't let you do when in ANSI C compliance mode.
29 Jan, 2009, quixadhal wrote in the 16th comment:
As the psuedo-leader of the ragtag RaM mafia, I'll make a stab (heh, punny) at tossing a few goals out. :)
The initial goal was to clean up the code and fix known bugs in the process. I think we've gotten a good chunk of that completed, although there are surely still many bugs lurking. At least *I* think the code is a bit easier to read and follow now. YMMV.
After that, the idea was to merge in the "must-have" features that would make builders and admins happier. OLC is the big one, followed by colour support (using the traditional defacto-standard ROM colour codes) and copyover. That would get us a driver that was functional for most people out of the box, without tons of extra stuff you'd feel compelled to rip out if you had your own ideas.
Then, the next couple of steps had no particular order, but since most of the folks involved wanted to shift to C++, that one got bumped up a bit.
One step was to convert the data file formats into something a little easier to maintain and expand (making them more properly key/value pairs and eliminating magic values or magic ordering of values). Since we still want to maintain backwards compability with ROM areas, they'd have to be recognized and converted as they were read in. The idea of exporting in ROM classic format was floated around, but you'd likely lose some features as time goes on.
The C++ conversion is the most tedius, but probably the most promising in terms of stability gains. Removing all the char * buffers and all the complicated memory recycling tricks and replacing them with std::string and STL containers would both make the driver cleaner to follow AND less prone to errors caused by array overruns or dangling pointers. It is, however, a very large and tedius task, so it's slow going.
The eventual end-game is to remove as much of the hard-coding as possible and bring it into line with the SmaugFUSS project's level of loading much of the game state from files (classes, races, flags, etc), with only a single default of any thing (in case no file exists – no race file means everyone is the default race). Likewise, if you have no area files, the game should still load and boot, with two rooms – The Void (the catch-all room), and a second room which could be used to build off of.
Righto, well at least I can be a tester while learning! I think I'm going to put down a few hobbies to reenter programming and try once more to Master the basics of it at the very least. I haven't found many terribly good free tutorials beyond the fundamentals of "what is a variable" etc… that stuff I can remember after a reference. It's using classes, structures (and unions), etc… focusing on OOP and using dynamic memory that got me wobbled.