The next programmatic problem I am tackling is the one about save games. Now, first I'd like to preface this discussion with several limitations in common save game implementations.
The first limitation is the notion of a version history of a user's particular progress. Most games don't really handle this, you either have multiple saves that can be like a history, or you just don't have one at all. There are several saved game bugs that can be difficult to diagnose, and would be easier with a kind of built-in versioning system to saved games. Imagine a player gets assigned "Quest A" and does part, but not all of it. Then the player decides to start and finish Quests B-E. Lastly, they go back to A only to find a bug, and the quest is broken. As a developer, you typically would load up the save, and see why its broken. However, lets say its broken because a value in the actual save file is wrong. The problem is when did the value become invalid? If you don't have multiple saves, then all you can do is ask the user (Beta Tester if your lucky), and you'll get a laundry list of things to try to reproduce (which may or may not be helpful). For the most part your simply SOL. However, lets say you have multiple saves. In this case you have a little more to work with. You could manually go through the saves and load them up and look for the 2 saves that represent the region where the value became invalid (It was fine in Save X, but broken in Save Y). This is usually a fairly tedious process, but it is your best bet. Bottom line is this is something I'm hoping I can improve upon.
The next limitation of common save games (actually more of a missing feature), is the ability to transfer your saved games. Lets say you have all of these: Mac OSX, iPhone, and iPad. And lets say you really, really like a particular game and so you download it on all three devices (Play on iPhone while waiting in line, iPad while on a plane, and Computer while at home). Now, the problem is you can't really play the game on all three because your save is only on one. However, many large game studios have started working on putting saves games in the cloud (Mainly Valve). Again, this is something I'd like to work towards.
So what I've decided to use is an SQL database to store the user saves. Each Class gets a table and each object a row with a Version ID. I then have an Object Header table that associates the Table Name with the object. Then I select all the objects from one table with the matching Version ID and build the objects. Once I've done this for all relevant tables, I build the hierarchy.
I considered using one of the new Object Oriented Databases, but these seem too new. Also, they don't have a lightweight version like SQLite. The closest I found was one called EntropyDB, but this is written in cocoa (not very portable). For this particular game, I will save the a screen every time the user leaves it. And this will provide me a nice automated save system that's not too large. Plus, if the Database starts to get too big I can always delete some of the old revisions. The nice thing about using a database, is it's really easy to inspect the contents of the save. There is a nice visual editor for SQLite files called SQLite Studio. I just load it up and run a couple select statements to see the values of certain objects.
Lastly, whats easier to replicate into the cloud than a database. It would be that hard to hook up an Amazon EC2 server with an elastic replicated database in the backend and then just periodically sync user saves to that database. Now, I probably won't do this on release, but I may try to do it sometime after launch (if the game is popular enough).
