Another MUD Update
Posted in MUD Development
First watch, 2 bells (9:08 pm)

Yeah, you're probably getting bored of these. You're probably wondering: "Jacob, what exactly is a MUD, anyway? Well, at least some of you are. But I'm not going to get in to that. The Internet is a big place, you can find that on your own. Suffice (for me) to say, it's my current hobby, a "pet project" of mine spanning nearly a decade. Off and on. Okay, so mostly off, but some on.

On with the update! If you keep up with this blog (and I can only assume you do if you read this), you know I've run in to issues with unstructured text files and saving complicated data objects to a storage media and then restoring them. I began a search for the right solution—a white whale, a magic bullet, whatever you wish to call it. My first instinct was to leap to XML because it can surely solve this small problem with ease. Right?

Wrong! XML is complicated, both to read and write (by machines anyway). Yes, there are libraries to help with that. Oh there are such libraries that you have no idea what you may be getting yourself in to (most of you, anyway).

Throwing out XML, and going with a cow-orker's recommendation of implementing JSON, I began writing a proof-of-concept program to save and restore data, but quickly ran in to a serious issue: JSON doesn't support multi-line strings.

Yet more searching around yielded a link to YAML, which I posted about the other day. YAML is easy to read from a human standpoint, and even has a couple of C++ libraries to help read it. YAML supports everything I want to do. So I scrapped the JSON project and started a proof-of-concept for YAML. I quickly ran in to an issue reading YAML, but it turned out to be my own fault: I didn't understand how a part of the library worked. Shortly after that, though, I did uncover a bug in the yaml-cpp library with indicator characters used as scalars (this is where you non-technical people either stop reading, or stick your fingers in your ears—metaphorically—and ignore me from here on out). With that issue wrapped up, serious work began and the proof-of-concept grew wings and took off. Just like I hoped it would.

Now I'm in the midst of tearing out underlying serialization code (the part that handles the loading and saving of objects), and it looks like it may take many hours to get things back up and working again. But hopefully by that time I'll have a full-blown, ready-to-use system that will require very little future modification.

Since then I have also become aware of (thanks Keith) the Boost Serialization library. It does the same thing I'm looking at doing, but a little more generically, just like Boost always does. Now the dilemma is: do I go forward with the YAML code, or switch to boost::serialization? Perhaps another proof-of-concept program should be written to determine this, but I need to do a little more research. Right now I have no idea how the serialized data looks to human eyes, and I haven't found any examples yet. It's important to my project to have these files as easily modified by humans as by machines.

In summary, that's where the project sits today. I may have some time this week to work on it, but if it's anything like last week I'm not going to have the brainwidth (I just came up with that word!) to work on it. Fortunately, Lorien and I plan a vacation to see family in Oregon in another week, so I should have a few idle days to work on it then.

PS. And wouldn't you know it, I just ran across Google's Protocol Buffers, yet another solution for basically the same problem. I have my work cut out for me!

Leave a Comment »

Leave a Reply