I got the saving gem working in Astra. I had to modify it a little to work within the system I've setup, but that was expected. As I was implementing it, I realized that some of the reservations I had about using the gem were wrong. It serializes any of the actor classes that implement the "SaveGameState" interface, and it's up to those actors to decide how they serialize themselves. That way, you can decide what information each serializable actor needs to save and how to restore that information when you deserialize them. I decided not to use WillyG's save system only because I didn't want to make a separate class for each thing I wanted to save. I suppose that instead I could have packed every variable for each actor I wanted to save into one "SaveObject" class and only set the variables that pertained to each actor, but that seems like bad programming practices and leaves a bad taste in my mouth. I also decided to use the gem because it has implemented a way to save more complex objects by saving their name and archetype and at load time either pulling it out of the persistent level by it's name or spawning it dynamically from its archetype. Next I want to implement some kind of encryption/encoding so that the data in the save file can't be manipulated so easily. Some of the data is binary, but a lot of it is just text. I'm thinking of using a DllBind and writing something in C++ to abstract the string data before saving it and decoding it when it loads. Since the data is just text, I could even do a full-blown encryption algorithm and it wouldn't take that much time (I don't think). Also, I suspect that I'll need to separate out some of the functionality into different systems for saving the player's progress and simply saving some state (like inventory and player stats) between level switching. |
Development Blog >