Hello,
First; thanks to all of those who responded with their input. I appologize for the delay in this message, I've had a lot of stuff going on and haven't really had much time to mess with this. I did, however get a bit of work done on actually starting the mud skeleton I have wanted to build for a while now.
I was considering just going with a flat-file, right now I've got something that just writes each value to the file, for example it might write 3 ints and a string. The only current drawback to this is that I have to read 3 ints and a string when next I read. This poses a problem if I were to do something like add housing, banks, etc. This would mean that I have to go through a pwipe every time something new is added to the player.
I really haven't had a lot of experience with data storage techniques, so I'm looking for suggestions on the easiest way to extend the files without doing a pwipe.

I've also considered xml, but it seems as if this just adds unneeded bloating that I'd rather avoid. While I do plan on imbedding web-capabilities into the mud, I almost find it easier to allow the mud to run the server, or at least use a pipe for communication with a protocol that will allow for sending and receiving data needed to generate the needed pages. Rather than using xml/mysqll files, I'd prefer doing it this way so that any changes made to either a players account or any other data that can be potentially modified could be made on-the-fly through the mud rather than having to set up some type of locking mechenism that would prevent the mud from writing over the changes made from the website. So the issue right now is just getting the extendable files working so that I can easily add or remove fields without to much dificulty.

Thanks,

You should never need to do a player wipe, there's NO reason for it.

What you do is keep your old file I/O routines intact, and when you have your new versions working correction (on a test copy!), you can easily write a routine to load every file using the old input routines, and then write them back out using the new output routines. Any data conversion or default values can be done between those two steps.

If you have a way to distinguish the file versions, you don't HAVE to convert everything in a batch, you could just convert folks as they log back in… if not, it's best to do this all at once and then make sure your new format DOES have versioning.

Yes and no. Certainly, you should never need to do a player wipe due to code changes; this much I absolutely agree with. This is all automated on SH, where characters from an older save revision are converted on login, and players have no idea that any extra effort was necessary.

That said, sometimes you* just want a player wipe, and there may be situations that call for this. Shoddy coding is not an excuse, but intentional game design may be. :tongue:

I use "you" because it certainly wouldn't be me.

Player wipes can sometimes be necessary. For instance, on SW:TSW, we're currently open for a bit of Alpha play-testing. When we switch to Beta, we'll likely have a pwipe, and reset the timeline back to when the MUD is supposed to take place within the Star Wars timeline. And then when we actually switch from Beta to Live (Open, whatever you want to call it.) there will most likely be another timeline reset/pwipe.

So, basically what I'd do is just increase the versionn when I make my changes? that's going to be really messy when it ends up with something like 50 versions because of new features or something that will actually mean that I have to add a new variable to the player, no? I'll have to do some sort of testing for each version, then fill in the blank values on the class and just write the data. Is there a cleaner way of doing this?

Version doesn't have to be stored anywhere but on the file itself. You don't have to store it on the player at all.

And yes, version'd loads can get extremely messy. Which is why sometimes, using a shell script to open and convert the files over to the new format can be a better choice. Of course, you have to be careful and keep backups.

I do periodic player culls, tho. They key on criteria like "last logged in over 6 months ago AND total age is less than 5 minutes",
that sort of thing. Hits get wiped. No point tying up names on token users that aren't likely to come back.

-Crat
http://lpmuds.net

You only need to change the version when the format can no longer be read by your loader. If pfiles are stored using the 'KEY' method, you can get away with missing certain keys (use defaults when possible) and you can get away with unexpected keys (just ignore). You don't need to increase the version when you make every single change; just when that change requires code changes.

Hello,
I've seen the "key system" a bit, but not really sure how it works; here was my idea. I had planned on setting it up so that each key would have a name, terminated by a NULL character, then the key type (1,2,3), if it's an int, short, string etc, and then the value. Then when I load it, I can just put it in a mapping of sorts. I can write the number of values to the file before the map and just put that at the end of the file, but I'm not quite sure how to serialize objects and that using a mapping like that. For example, I want to build housing eventually, and I plan on loading the players house when they log in, then unloading it when they log out to save memory, but I'll have to store the houses either in separate files (which works), but still requires flat-file work if I were to add a new feature..

Thanks,

Hello,
I'm sorta dead-ended on this one; help would really be appriciated here.
I've been told to look at the boost serialization functions,, but that doesn't seem like much more than I have now. I've also been playing with versioning, but I have to have a versioning system on everything that gets serialized (objects, rooms, etc) just in case there is a change made. This is starting to look really messy. Is there a better way of doing this? I'm not really to picky in terms of flat proprietary vs xml/something else, I just want to find a solution so I can get on with dev. I've got lots of ideas, this just seems to be my holdup. :(

The question is… do you really NEED to serialize your objects, or is that just the easiest way to do it? Serializing isn't meant to produce pretty output, it's meant to export complex data structures so they can be recreated with the same state.

Personally, I prefer a key/value system where each distinct scalar is one key to one value. Then you also need a method of nesting, or otherwise doing a one-to-many relationship. You can roll your own, or use a simple parser like JSON (or a more ugly/complex one like YAML/XML).

Trying to keep track of versions is complicated if you're actually serializing your data, since you have not be able to restore an older dump into a newer object…. if you have to pick it apart anyways, you lose half the benefit of serialization. As David said, reading it yourself means you can fudge values as needed (defaults, conversions, whatever) to fit the old stuff into the new format.

I don't really need to serialize, but I'm going to have to take this key-value thing and set it to the same state as it was before using the data, so I'm not really sure how this should work. Using the key/value thing is going to require some complex format be used so that I can keep track of what type of variable it is, etc etc. I don't mind the code-time, I"m just looking for something easily extendable. I love the key/value thing in xml, but this isn't making much sense so far, because I'm going to have to check for properties and read them in one at a time when I load the structure, which is going to still require some sort of versioning implamentation, no?

Not knowing what you're using it for, I can only speculate… but why does the format need to worry about the types of variables?

IE: If you are loading in (for example) an NPC, and you find a field called "MaxHitPoints", your loading code expects the value for that key to be an integer, no? The file doesn't need to explicitly specify that it's an integer.

OTOH, if you really are serializing arbitrary objects, then you probably need to use whatever library does that and accept that the result won't be human-editable (unless the human is very very careful). If you're going down that road, you aren't really loading and saving data, you are loading and saving objects. You may need to keep legacy object templates around so you can load something and then copy the values into a new "new-format" object, and re-serialize it back out.

If that makes any sense…

It can depend on the format and language, for example a yaml or json (or xml maybe) file in Python is eminently readable, but when you save/load the file you can load either objects, key/value pairs to instantiate objects in the calling code, etcetera. Of course these solutions are rather slower than other options.

I have finally released this. Below is the post I made with the release info. As stated in the post, suggestions from anyone would be more than welcome; I'd love to make this a better codebase with help.
post link:
http://www.mudbytes.net/index.php?a=topi...