对于集成 Xbox 服务的游戏，当在不同设备上玩同一游戏时，要求用户的游戏保存无缝迁移。 虽然游戏可以免费
实现自己的解决方案，但当你开始考虑玩家可能期望的内容时，这可能会很快成为一项非常昂贵的功能。 典型的玩家期望是：
- 无需用户交互即可将保存无缝备份到云
- 移动到新设备以玩同一游戏时，用户可以轻松地从他们玩游戏的上一台设备上恢复进度
- 重新安装游戏时，也会还原预先取得的进度
- 如果游戏支持脱机玩游戏，则可以在脱机时保存进度，稍后在连接时上传
- 有一种简单的方法可以解决来自不同设备的保存冲突，通常是因为其中一台设备以前可能已脱机
GDK 提供了多种可供游戏开发人员选择的选项。
始终联机 - 基于服务器的保存
如果你的游戏需要恒定的在线状态，则作为 MMO 的游戏就是一个示例，最简单的选择就是在已连接的游戏服务器上保存游戏进度。
这有一个优点，即玩家永远不需要同步其游戏保存，在设备之间移动时不会发生冲突，并且可以轻松扩展到多个平台。
支持离线玩游戏，最可靠的解决方案 - XGameSave
许多游戏需要支持离线玩游戏。 角色扮演和操作游戏只是此类别中的一小部分游戏。 对于需要适用于在线和脱机游戏的可靠解决方案的游戏，最佳解决方案是 XGameSave。 XGameSave 支持批量写入数据作为原子操作。
有关 XGameSave 和 XGameSaveFiles 之间的详细比较，请参阅 Win32 文件 IO 和游戏保存。
支持脱机游戏、简单 API、最大灵活性 - XGameSaveFiles
许多游戏可能需要支持脱机游戏；但是，他们可能还需要在实现游戏保存系统的方式方面具有更大的灵活性。 XGameSaveFiles 没有 XGameSave 附带的可靠性；但是，它确实允许游戏利用标准 Win32 文件 IO API（如 CreateFile 和 WriteFile）来创建自己的保存系统。 对于已经在电脑上拥有此类系统的开发人员而言，此解决方案是最佳的，他们想要最大程度地将移植成本降到适用于电脑 Game Pass 的解决方案。
有关 XGameSave 和 XGameSaveFiles 之间的详细比较，请参阅 Win32 文件 IO 和游戏保存。
使用 XGameSaveFiles 时，想要可靠程度的游戏开发人员需要实现类似于以下内容的解决方案：
- 游戏应检查其保存系统“摘要”文件，以查找上次良好保存的位置。 在此示例中，假定它指向 file1.dat。
- 游戏的下一次写入操作将是 file2.dat。 游戏不应覆盖较旧的保存，除非他们知道它已完全写出。
- 将更新成功写入 file2.dat 后，游戏可以更新其“摘要”文件到现在指向 file2.dat。
- 然后，游戏会在 file1.dat 和 file2.dat 之间不断切换，以便游戏始终知道其上次良好的保存，并在出现问题时进行回退。
游戏需要无代码解决方案 - 仅限电脑
某些进入电脑Game Pass游戏可能需要无代码保存游戏系统。 这方面的好示例包括：
- 游戏属于 x86，不能直接在打包外部使用 GDK
- 游戏可能是在没有开发人员使用与使用 Unreal 的蓝图或使用 Unity 的 Bolt 类似的内容的情况下创建的
对于属于此类别的游戏，GDK 提供 无代码游戏保存 解决方案。 使用无代码云保存，游戏只需从所需的保存目录读取和写入，使用标准 Win32 文件 IO API，同步将自动处理。 游戏无需编写特殊代码即可处理同步和上传。 同步将在游戏启动之前进行。