Conflits de Game Saves et unités atomiques
Vue d’ensemble
Des conflits de sauvegarde se produisent lorsque vous modifiez les mêmes données de jeu sur plusieurs appareils. Le système doit alors décider quelle version conserver. Pour concevoir la structure de vos données de sauvegarde, vous devez comprendre comment le système détecte et résout les conflits.Quand des conflits se produisent-ils ?
Des conflits se produisent pendant l’opération de synchronisation (PFGameSaveFilesAddUserWithUiAsync) uniquement lorsque toutes les conditions suivantes sont remplies :
- Des modifications locales existent : vous avez modifié des fichiers localement depuis la dernière synchronisation.
- Des modifications cloud existent : un autre appareil a chargé des données plus récentes depuis la dernière synchronisation.
- Même unité atomique : les deux modifications se trouvent dans le même dossier de premier niveau.
Matrice de détection des conflits
Qu’est-ce qu’une unité atomique ?
Certains systèmes de synchronisation de fichiers traitent les conflits fichier par fichier : si le même fichier doit être chargé et téléchargé, il y a conflit. Dans Game Saves, chaque sous-dossier de premier niveau est traité comme une unité atomique.Chaque sous-dossier de premier niveau constitue une unité atomique.
- Préserver l’intégrité des données : les fichiers interdépendants restent cohérents entre eux
- Assurer l’isolation : les données indépendantes placées dans des dossiers distincts se synchronisent sans conflit
- Réduire les conflits : les modifications apportées à différentes unités atomiques sur différents appareils sont fusionnées automatiquement
Exemple de structure de sauvegarde
Scénarios de conflit
Fichiers de premier niveau : un cas particulier
Tous les fichiers situés à la racine de la sauvegarde partagent une même unité atomique. Le système regroupe en une seule unité atomique tous les fichiers que vous placez directement à la racine de la sauvegarde (en dehors de tout sous-dossier). Si vous modifiez localement un fichier de premier niveau et qu’un autre appareil modifie un autre fichier de premier niveau, cette différence déclenche un conflit.Options proposées à l’utilisateur
En cas de conflit, les joueurs choisissent entre :- Use Local Data (Keep Local) : conserver les données de sauvegarde actuelles de l’appareil.
- Use Cloud Data (Keep Cloud) : télécharger et utiliser les données de sauvegarde cloud.
Important : la résolution est globale
⚠️ Important : si les unités atomiques déterminent quand un conflit est détecté, le choix de résolution du conflit effectué par l’utilisateur s’applique à l’ensemble de la sauvegarde, et non à chaque unité atomique.
Exemple : scénario de conflit mixte
Pourquoi c’est important
- Keep Local entraîne la perte des modifications présentes uniquement dans le cloud : si vous choisissez “Keep Local” en raison d’un conflit dans SlotA, vous ne recevez pas la mise à jour cloud de SlotC effectuée par un autre appareil.
- Keep Cloud entraîne la perte des modifications présentes uniquement en local : si vous choisissez “Keep Cloud”, l’état cloud écrase vos modifications locales de SlotB et SlotD.
- Restauration possible : les deux choix conservent la branche écartée afin de permettre une restauration ultérieure.
Récapitulatif de la conception
Cette approche globale simplifie l’expérience des joueurs. Bien qu’une résolution par unité atomique préserve techniquement la cohérence des données (puisque les unités atomiques définissent les limites de cohérence), elle pose des problèmes d’expérience utilisateur :
- Les joueurs doivent comprendre la notion d’unité atomique et de limites de dossiers.
- Des résultats mixtes (certains dossiers issus de la version locale, d’autres du cloud) peuvent laisser les joueurs dans le doute quant à l’état final.
- Demander une confirmation séparée pour chaque unité atomique en conflit rend la résolution des conflits fastidieuse.
Quand aucun conflit ne se produit
Suppression des deux côtés
Si les deux appareils suppriment le même fichier (ou des fichiers de la même unité atomique), aucun conflit ne se produit. Le système reconnaît que les deux appareils s’accordent sur la suppression du fichier.Modifications dans des unités atomiques différentes
Si l’appareil A modifie des fichiers dansSlotA/ et que l’appareil B modifie des fichiers dans SlotB/, aucun conflit ne se produit. La synchronisation fusionne automatiquement les deux modifications.
Bonnes pratiques
1. Concevez soigneusement la structure des dossiers
Utilisez des sous-dossiers pour les unités de sauvegarde indépendantes :- Données de référence partagées : stockez les données susceptibles d’être utilisées par n’importe quel emplacement de sauvegarde, comme le contenu débloqué ou les succès, dans un sous-dossier dédié afin qu’elles se synchronisent indépendamment des emplacements de sauvegarde individuels.
- Grandes collections de ressources : si votre jeu stocke de grands ensembles de fichiers mis à jour indépendamment, comme des packs de contenu téléchargés ou des niveaux créés par les utilisateurs, envisagez de les répartir dans plusieurs sous-dossiers racine afin que les mises à jour d’une collection n’entrent pas en conflit avec celles d’une autre.