Hi Jake. It seems that you are asking unrelated questions about something that may seem like it’s the same thing.
Let’s break this down into the various parts.
- Backups
iOS will automatically backup the files in system.DocumentsDirectory. They won’t be shared with other devices owned by the same iCloud account. This is used if you need to restore your device for some reason. If you delete your app and reinstall it, I don’t believe you will be able to recover the saved files since you took the step to remove it yourself. I believe Android has some backup facilities, but I’m not sure how they work. Regardless, these type of backups are not for sharing saved games between devices or saving checkpoints to resume from later.
- Shared data
Based on your original descriptions and videos, this is what it sounds like you’re customers are asking for. This is what I described above. For iOS, saved/shared game data is iCloud based, but Apple uses different iCloud technology. The iCloud plugin supports simple key-value pairs, saved documents, and a full-fledged relational database for more complex data needs. You could use the documents mode of the iCloud plugin to save your settings.json file and then other apps can be be granted access to get it and update it. However, this isn’t that great of a way to save game data that will be shared between the devices. Uploading and downloading files are a bit slower and you have to take the whole file, then open it and read it in your other app. It’s more management on your side. The ideal way is to take each variable you want to save and write them as their own key.value pair. You could do something like (untested code)
for key, value in pairs(yourSavedDataTable) do iCloud.set( key, value ) end
Then reverse that to load it:
local yourSavedDataTable = {} yourSavedDataTable.score = iCloud.get( "score" ) yourSavedDataTable.currentLevel = iCloud.get( "currentLevel" ) etc.
Of course you have to include the iCloud plugin in your build.settings, and require it in the modules where you want to use it. And there are some entitlements that have to be setup in your developer profile’s App settings and then you will need to generate a new provisioning profile that has those entitlements in them. (scarier than it sounds)
For GPGS, you’re going to use Snapshots which stores a string of data. The best way to make that is to json.encode() your saved data table, much like the loadsave.lua module does to write the settings to storage. This string is saved in your snapshot. You can load it in, json.decode() it back to a Lua table. When I did this:
local myTable = { play = 1 }
I was just making up a sample table with a sample value in it. You would use your settings table instead of mine with whatever content you have in it.
Rob