DefSave - Easy Persistent Save/Load


This should still be tested more before used in real projects. I’ll be doing so in near future.

Some features I plan to add are automatic backup system (auto backup multiple save files and keep loading older versions until one works) / version depreciation (if save data version is older than current depreciated version then it’s cleared and set to default) / basic encryption or just a little more obfuscation.



Cranking out the assets! Great job @Pkeod!



I’m adding basic key based XOR obfuscation now. Only works with ASCII right now but I’ll be adding UTF-8 support soon.

For encryption, going to go with AES.

Turning on obfuscation and encryption will both be options. Neither will protect against people determined to get into or modify the files but it will prevent most normal people from casually modifying even more so. You don’t want to store sensitive info in the files either it will just be an option for devs who don’t want their saved games to be modified so easily.

1 Like


Using zlib.inflate() and zlib.deflate() for the individual keys and values would probably work as well.

1 Like


DefSave now has a Profile extension.



I plan to use this in my game.

Do you think saving on mobile devices is fast enough to do it on the fly in an action packed game?
In my game, you can deploy ‘smart bombs’ which have a very limited quantity. Would calling mid-fight be feasible, or do I risk running into slight file system waits doing so?

1 Like


That depends entirely on how much data you are saving. Your best bet is to test and see if there is an impact. Nothing DefSave does should have more of an impact over using the features it uses directly, it is purely a convenience tool.

If you are saving small changes in large files then it would be better to save those small changes in their own files if possible.

DefSave’s concept of “files” internally puts everything into one big blob if I remember right so you would want to save more often saves into smaller instances of DefSave probably. I’ll read the source in a bit to check… “Files” should be separate in DefSave as far as IO goes so you should only need one instance of DefSave for multiple files.

If you want absolute fastest performance you would need to make a custom solution for your data types with low level IO.

I don’t think built in file IO is async, may be worth someone making a native extension which can do that.

tl;dr test and see if there are issues. With flash memory it should be too fast to notice for small data even with no async IO.



I tried this using my Samsung Galaxy S7 and it works perfectly to immediately at firing off my smart bomb save this onto the DefSave profile, to flash memory. No visible hiccup whatsoever.

I wonder if there’s a risk of that for older devices? Probably not, is my guess.



There is a breaking change in v.1.2.0 with get() which now returns nil on a nil key value instead of returning an empty table. This makes more sense to me now. A version 1.1.0 is still available with the old behavior if needed.

Apparently it was nil a long time ago then was set to returning an empty table for some reason. I don’t remember why or if that was even necessary. For anyone who uses this please let me know if there are issues. :thinking:



Imho, I think a breaking change warrants a “bigger bump” in version number than a minor version?



About a week ago I had to spend quite a lot of time debugging the save/load in Fates of Ort because I wanted/expected nil instead of an empty table… So I guess what I’m saying is I’m okay with the change :laughing:



You are right, fixed! :slight_smile:

1 Like