Choosing the save system for your game
For games that are integrating Xbox services, there is a requirement that the user's game saves
migrate seamlessly when the same game is played on different devices. While games are free
to implement their own solutions, this can quickly become a very expensive feature when you
start to consider what the gamer might expect. Typical gamer expectations are:
- Saves are backed up seamlessly to the cloud without user interaction
- When moving to a new device to play the same game, the user can easily resume their progress from where they were on the previous device on which they played
- When re-installing a game, the previously made progress is restored as well
- If the game supports offline play, progress can be saved when offline and will be uploaded later when there is connectivity
- There is an easy way to resolve conflicts from saves that originate from different devices, typically because one of those devices may have previously been offline
The GDK offers a variety of options for game developers to choose from.
If your game requires a constant online presence, the game being an MMO is such an example,
the simplest choice is to just save game progress on your already connected game servers.
This has the advantage that gamers will never need to sync their game saves, there is no
potential for conflicts when moving between devices, and will easily scale to multiple
platforms.
Many games need to support offline play. Role-playing and action games are just a small sample of games in this category. For games needing a robust solution that works well with both online and offline play, the best solution is XGameSave. XGameSave provides support for batched writes of data as atomic actions.
For a detailed comparison between XGameSave and XGameSaveFiles, see Win32 file IO with Game Saves.
Many games might need to support offline play; however, they may also want more flexibility in how they want to implement their game save system. XGameSaveFiles doesn't have the robustness that comes with XGameSave; however, it does allow the game to leverage standard Win32 file IO APIs such as CreateFile and WriteFile to create their own save system. This solution is optimal for developers who already have such a system on PC and are wanting to minimize their porting costs to a solution that will work for PC Game Pass.
For a detailed comparison between XGameSave and XGameSaveFiles, see Win32 file IO with Game Saves.
Game developers wanting robustness while using XGameSaveFiles would need to implement a solution similar to the following:
- The game should check their save system "digest" file to find the location of the last good save. In this example, assume it points to file1.dat.
- The game's next write would be to file2.dat. The game shouldn't overwrite an older save unless they know it is fully written out.
- After successfully writing their update to file2.dat, the game can update their "digest" file to now point to file2.dat.
- The game then keeps toggling between file1.dat and file2.dat so that the game always knows their last good saves and has a fallback if something goes wrong.
Some games coming to PC Game Pass might require a no-code save game system. Good examples of this include the following:
- Game is x86 and can't directly consume the GDK outside of packaging
- Game might have been created without developers using something similar to Blueprint with Unreal or Bolt with Unity
For games that are in this category, the GDK provides a no-code game save solution. Using no-code cloud saves, games just read and write from their desired save directory, using the standard Win32 file IO APIs, and synchronization will be handled automatically. Games do not need to write special code to handle the synchronization and upload. Synchronization will happen prior to the game launch.