Migration de schéma des sauvegardes de jeu et écritures récupérables

Une sauvegarde est une interface de longue durée

Un fichier de sauvegarde peut survivre au code qui l'a produit. Renommer un champ, changer des unités ou scinder une structure d'inventaire modifie cette interface, même si l'analyse du fichier réussit encore. Il faut concevoir la persistance autour d'un modèle de données documenté, d'une version de schéma et d'un mécanisme de récupération, plutôt que de sérialiser des objets actifs arbitraires.

Le format ne garantit pas la compatibilité

Le guide de sauvegarde de Godot illustre la sérialisation explicite de l'état du jeu ainsi que les limites des types JSON. [1] Protocol Buffers documente des règles de compatibilité, notamment la conservation de l'identité des numéros de champ et la réservation des numéros supprimés. [2] Un format de sérialisation aide à représenter les données ; la signification propre au jeu, les valeurs par défaut, les migrations et les plages de versions prises en charge restent des responsabilités de conception.

Exemple détaillé

Une sauvegarde illustrative en version 1 contient coins: 125. La version 2 remplace ce champ par wallet: {gold: 125}. La version 3 ajoute difficulty, avec la valeur normal uniquement lors de la migration d'une ancienne sauvegarde qui n'a pas ce champ.

Implémentez les transformations 1 → 2 et 2 → 3 sur les données décodées. Après la première étape, vérifiez que le montant de la monnaie reste 125 ; après la seconde, vérifiez la valeur par défaut et la conservation de toute la progression sans rapport. N'avancez la version enregistrée qu'une fois chaque transformation réussie. Une sauvegarde en version 3 ne doit pas recevoir d'attribution supplémentaire du simple fait qu'elle est rechargée.

Si une sauvegarde en version 5 est plus récente que ce que ce chargeur prend en charge, conservez-la et signalez l'incompatibilité. Deviner sa signification et l'écraser avec une version 3 transformerait un problème de compatibilité temporaire en perte de données.

Flux de migration et de restauration

Conservez des jeux de test immuables pour chaque schéma historique pris en charge, y compris avec des champs facultatifs absents et des valeurs limites. Validez les types de données, les plages de valeurs, les identifiants d'objets stables, les ressources requises et les références croisées avant de remplacer le monde actif. Lorsque c'est possible, construisez l'état restauré de façon isolée, puis activez-le après validation.

Séparez la migration de schéma du remappage de contenu : un objet retiré du jeu nécessite une politique de remplacement ou de compensation documentée, pas seulement un champ renommé. Rendez les erreurs exploitables et conservez la sauvegarde utilisable précédente jusqu'à ce que son remplacement soit vérifié.

Limites du commit et des défaillances

Pour les sauvegardes reposant sur SQLite, effectuez le commit des données et de la version de schéma dans une seule transaction ; la documentation de SQLite sur le commit atomique explique à la fois le mécanisme et les hypothèses sur le stockage. [3] Pour les sauvegardes sous forme de fichiers, préparez un remplacement complet et utilisez les opérations de remplacement atomique et de durabilité prises en charge par la plateforme. Un simple renommage ne constitue pas une garantie universelle en cas de coupure de courant.

Testez les écritures interrompues, le stockage plein, les entrées corrompues et l'échec de migration. Une somme de contrôle peut détecter une corruption accidentelle, mais elle n'établit pas la validité sémantique des données de jeu. Définissez explicitement la sélection de la sauvegarde de secours et la procédure de récupération, et ne signalez jamais un succès avant que l'opération de persistance choisie se soit terminée avec succès.

Sources

[1] Saving games — Godot Engine documentation.

[2] Proto3 language guide — Protocol Buffers documentation.

[3] Atomic commit — SQLite developers.