Sauvegarder la progression d'un joueur sans perdre de données

Écrire moins, mais au bon moment

Le DataStore accepte environ une opération toutes les six secondes par clé. Sauvegarder à chaque gain de pièce dépasse ce budget en quelques secondes et remplit une file d'attente dont les demandes finissent par être abandonnées.

Garde l'état en mémoire dans une table indexée par UserId. Écris toutes les 60 à 120 secondes, à la sortie du joueur, et dans BindToClose pour vider la file à l'arrêt du serveur.

UpdateAsync plutôt que lire puis écrire

Lire avec GetAsync puis écrire avec SetAsync laisse une fenêtre pendant laquelle une autre session peut écrire : la seconde écriture écrase la première. UpdateAsync fait les deux en une opération et évite ce cas.

Entoure chaque appel d'un pcall, avec trois tentatives espacées, et journalise l'échec. Un pcall qui avale l'erreur sans rien dire transforme une perte de données en mystère.

Les profils vieillissent

Un profil sauvegardé avant l'ajout d'une fonctionnalité ne contient pas ses champs. Le code qui les lit trouve nil et plante — c'est ce qui casse à chaque mise à jour.

À la lecture, complète le profil chargé à partir d'un profil modèle, et préfixe tes clés par une version pour pouvoir migrer proprement.

• Des données simples uniquement : nombres, chaînes, booléens, tables. Jamais d'Instance, de Vector3 ni de CFrame.
• Une clé versionnée, par exemple « v1_joueur_ ».
• Un profil modèle qui complète les champs absents à chaque chargement.

Questions fréquentes