We all know Nintendo Switch doesn't allow access to game saves, and the end users wanted to back them up. I wanted to think about how cloud saves really work in terms of functionality and safety, and jot them all down like a written document, so I can sort of understand clearly what it is. I don't have a lot of expertise in technology, so if I'm wrong in some areas, let me know, because I'm learning about it.
Assuming that a game developer is implementing a cloud save feature, and Nintendo is actually providing the functionality, then the game developer needs to look into what the limitations are for cloud saves.
Since video games are programs / applications in general, the first thing that comes to mind in regards to the Nintendo Switch, is that all apps use dedicated memory and resources. This means, unless the app is an applet, there are no ways for an app (video game) to run in the background while another app (video game) is running. This would mean each app will be locked to 1 active session, and will only be able to read/write game saves when that app is active. No other apps can access the game saves, so we can deduce game saves are safe to read/write, and it will be unique to said app.
Because game saves will always be unique to apps, this means each game saves are "sandboxed" away from other game saves. An app would not be able to overwrite another app's game saves, nor would it be able to read from it.
Currently, the Nintendo Switch OS has access to the game saves and can manage them by deleting them from the internal storage, but it would not read from nor write to them. It would not expose the data to the end users, so that the game saves are 100% reliable to Nintendo and to the cloud service providers. Only the apps can choose to delete the game saves or when the users choose to delete them.
Cloud saves, if implemented, would be an OS feature. The game developer would be able to call a function to start the process of putting the game saves into the cloud, but it needs to satisfy the conditions in order to do so:
- The user needs to be signed in to the respective Nintendo Account.
- The user's Nintendo Account has the purchased game listed.
- The Nintendo Switch is connected to the Nintendo servers.
- The user agreed to have the Nintendo Switch phone home in order to upload a game save or data.
- (I don't know if at this point, there would be an agreement about privacy data concerns and other things, but I would suppose the user has agreed to this.)
- Purchased game has not been in sync with the Nintendo servers.
Once the process has started, cloud saves would be in sync with the game saves on the Nintendo Switch, and that's it.
Cloud saves are triggered when Nintendo Switch connects to the Nintendo servers. By the time the Switch is connected, it would run the automated process to verify if any of the locally stored game saves are newer than the ones on the cloud. If yes, it would overwrite the old ones with the new ones. However, there wouldn't be a way to determine if the new ones are the bad ones via automated means.
But what would happen if some terrible situations happen?
If a game app corrupts a game save, the game save data would be messed up, but it would still be data that the Switch OS can manage. The moment that corrupted game save is in the cloud, it's all over. The user would have to know the game can no longer read the game saves, and the user would acknowledge they have lost hours of game time. Even if the Nintendo Switch is never online, or the cloud save functionality is turned off, the user would still have to replay the game.
If the cloud save is implemented similarly to always sync from the server to the local Switch device first, the local game saves would always be overwritten until either the game calls the OS to upload it or the user tells the OS to do so. If for some rare occasions the game saves are corrupted on the server, that game is technically dead on arrival, because no matter what the user does, the game wouldn't be able to save.
Writing all of these down, makes cloud saves pretty viable...