title_player_account dans l’espace de noms playfab.gamesave.
Événements
gamesave_version_finalized
Émis chaque fois qu’une version de sauvegarde de jeu est finalisée. Tous les fichiers sont téléversés et la version est complète. Cet événement est le principal signal permettant de suivre l’activité de sauvegarde.
Conflict (objet imbriqué, présent uniquement lors de la résolution d’un conflit) :
gamesave_version_marked_known_good
Émis lorsqu’une version de sauvegarde de jeu est explicitement marquée comme « fiable » (known good). Une version fiable sert de point de restauration de confiance : il s’agit de la version vers laquelle le système revient si un joueur ou le titre doit récupérer après un état de sauvegarde incorrect.
Scénarios
Scénario : utilisation multiappareil standard
Un flux multiappareil type consiste pour un joueur à sauvegarder sur un appareil et à reprendre sur un autre. Dans PlayStream, ce schéma se présente sous la forme d’une séquence d’événementsgamesave_version_finalized dont les numéros de Version sont incrémentés.
Ce que vous voyez :
- Un événement
gamesave_version_finalizedchaque fois que le joueur sauvegarde, avecDeviceTypeetPlayerIdentityProviderindiquant l’appareil et le fournisseur d’identité utilisés. NewFileCountetNewFilesSizeBytesindiquent la quantité de données modifiées par rapport à la version précédente. Une version dontNewFileCountvaut 0 signifie que le joueur a finalisé une version sans nouveau contenu de fichier (par exemple, une mise à jour portant uniquement sur les métadonnées).- Pour les sauvegardes normales,
ConflictvautnulletIsGeneratedByRollbackvautfalse.
- Fréquence des sauvegardes par joueur : suivez le rythme des événements de finalisation pour comprendre l’engagement des joueurs et leur comportement en matière de sauvegarde.
- Taille des sauvegardes dans le temps : surveillez
TotalSizeBytesetNewFilesSizeBytespour détecter une croissance inattendue des données de sauvegarde susceptible d’affecter les coûts de stockage ou les durées de synchronisation. - Répartition par appareil : agrégez
DeviceTypepour savoir à partir de quelles plateformes vos joueurs sauvegardent le plus souvent.
Scénario : résolution des conflits
Des conflits se produisent lorsque deux appareils finalisent une version de sauvegarde de jeu à partir de la même version de base. Par exemple, un joueur peut jouer hors connexion sur sa console et sur son PC en même temps, et les deux appareils tentent de se synchroniser lorsqu’ils reviennent en ligne. Ce que vous voyez :- Lors de la résolution d’un conflit, le client charge toujours ses fichiers locaux dans un nouveau manifeste et finalise ce manifeste. Ce processus produit un seul événement
gamesave_version_finalizedavec un objetConflictnon null. La version infonuagique existante (déjà finalisée lors d’un événement antérieur) ne produit pas de nouvel événement. Conflict.IsWinnerindique si les modifications locales du joueur ont remporté le conflit :true: le joueur a choisi keep local. Le nouveau manifeste devient la version canonique et la version infonuagique précédente est remplacée.false: le joueur a choisi keep remote. Le nouveau manifeste est conservé comme point de restauration (il contient les données locales rejetées), tandis que la version infonuagique existante reste canonique.
Conflict.ConflictingVersiondésigne la version infonuagique existante qui était en conflit.
- Taux de conflit : filtrez les événements
gamesave_version_finalizeddans lesquelsConflictest présent. Un taux de conflit en hausse peut indiquer que les joueurs changent fréquemment d’appareil sans synchroniser, ou que la cadence de sauvegarde de votre titre provoque des collisions de versions inutiles. - Préférence locale ou distante : comparez la proportion de
IsWinner = true(version locale conservée) et deIsWinner = false(version distante conservée) pour comprendre comment les joueurs résolvent les conflits. Une forte prédominance de l’une des deux options peut indiquer un problème d’expérience utilisateur dans l’invite de conflit. - Schémas de conflits multiappareils : utilisez
DeviceTypeetPlayerIdentityProvidersur les événements de conflit pour identifier les combinaisons de plateformes les plus sujettes aux conflits.
Scénario : version fiable et restauration
Le mécanisme de version « fiable » vous permet de marquer une version spécifique comme point de restauration de confiance. Si la sauvegarde d’un joueur est corrompue ou s’il doit récupérer ses données, le système peut revenir à la version fiable la plus récente et créer une nouvelle version à partir de celle-ci. Ce que vous voyez :- Un événement
gamesave_version_marked_known_goodlorsque vous désignez une version comme point de restauration, avec le numéro deVersionet l’horodatageMarkedAt. - En cas de restauration, le système émet un nouvel événement
gamesave_version_finalizedavecIsGeneratedByRollback = true. Le contenu de cette nouvelle version est basé sur la version fiable, mais elle reçoit un nouveau numéro de version incrémenté. - La version générée par la restauration peut également comporter des données
Conflictsi la restauration a été déclenchée dans le cadre d’une résolution de conflit.
- Fréquence des restaurations : suivez les événements
gamesave_version_finalizeddans lesquelsIsGeneratedByRollback = true. Des restaurations fréquentes pour un titre peuvent indiquer des problèmes de corruption des sauvegardes ou de logique de sauvegarde du titre. - Ancienneté de la version fiable : comparez la
Versiondegamesave_version_marked_known_goodà la dernièreVersionfinalisée pour le même joueur. Un écart important signifie que le joueur perdrait une progression significative en cas de restauration. - Corrélation entre restaurations et conflits : si les versions générées par une restauration apparaissent fréquemment avec des données de conflit, cela peut signifier que votre stratégie de résolution des conflits déclenche des restaurations comme effet secondaire.