Ok, after a few days of thinking hard and long about what to do with the data file reading/saving system, I’ve finally come to a decision and plan for what to implement.

The CC engine originally used a very simple way of exposing every single object’s variables to the data files by serializing out their values in a certain order. The order of these values determined which variable they belonged to. It looks something like this:

Note the use of indentation to keep track of the class hierarchy, and # to mark line comments.

This is a very rickety and fragile way of storing game data. Leaving out or mixing up any values would make the order, and therefore the reading procedure get messed up in sometimes hard-to-catch ways. As soon a member variable is added to a class, the data files had to be updated with values for this added variable – Bad. But this old crappy way worked on the small proof-of-concept scale of the current CC Test build!

So what I’ve been thinking about is wheteher to completely replace the current system with something new and probably XML-based, or to just improve upon the existing code, or do something in between. I started going down the path of replacement with an article and sample code of Frederic My’s article in Game Programming Gems 4. It’s a very robust and complete system for custom RTTI (real time type identification, or reflection) and properties-based data persistence. Its files look like this:

Note how he definies how the classes and properties are structured before describing the values. He also uses the current pointer addresses as the unique identifiers for the object instances saved out.

It took some pondering to conclude that I’d probably spend more time gutting my existing code and replacing it with an adjusted and adapted version of My’s sample code to make it worth it. I also don’t have much use for some of the benefits of his techniques, since I’ve already engineered my code to work around the shortcomings of my original techniques.

After reading this excellent thread by the Moonpod guys on XML, I had to reconsider once more whether I should go with my own format or some XML flavor:
http://www.moonpod.com/board/viewtopic.php?p=15369#15369

Although the DTD’s are a compelling and really interesting feature, I’ve decided that readability and ease-of-editing are my highest priorities. XML just isn’t very readable or convenient to edit with all those closing tags and different ways of formatting things. I prefer to keep things simple and with little room for my formatting obsessive-compulsiveness to freak out when I change my mind about pointless conventions.

Another big priority is to keep things very self-documenting, and that was why I actually didn’t like My’s way of keeping the property definintions in a separate place in the file. When I’m editing something, I’d like for the documentation to be right there in some way so i don’t have to look it up in the code or somewhere elese. This’ll be even more important for any modders who want to change things around in these files and don’t have the code to refer to.

Finally, the last important benefit I’m seeking is to be able to omit as much redundant data as possible in these files. I found that even in the CC test, I ended up with really long files to scroll through, and much of it was just default value filler to keep the order intact. If I can just keep the defaults of an intialized and read object by omitting those values in the data files, I’ll be much better off. This’ll also help keep old data files working with new versions of the code since they’ll just define their old values and leave loaded objects’ undefined properties with safe default values.

Anyway, if you’re still reading this, here’s the way the new format I’ve come up with will look like:

# are still comments. Everything before an equal sign is the property’s name, and everything after is the corresponding value. % means to set the entire object’s data to that of one which is already defined. Properties can be in any order, or omitted. The big constraint is that the tab indentation now matters, so that’s a source for errors, but I think it’s a good tradeoff to having some kind of nested opening and closing brackets (e.g. { and }) all over the place. 

That’s all for now… my tired brain going to bed. Tomorrow is all about retrofitting the old code with this crazy new system.

You can follow any responses to this entry through the RSS 2.0 feed.
Both comments and pings are currently closed.