Les joueurs reviennent pour l’épisode suivant avec des routes choisies, des scènes débloquées et du temps investi. Traitez la compatibilité des sauvegardes comme une fonctionnalité à entretenir à chaque sortie. Renommer des éléments de l’état, supprimer des scènes ou modifier des objets sérialisés peut rendre les anciennes sauvegardes inutilisables, même si une nouvelle partie fonctionne correctement.
Les systèmes de sauvegarde varient d’un moteur à l’autre. Consultez la documentation de la version exacte de votre moteur et consignez les versions concernées. Servez-vous de ce guide pour définir votre engagement de compatibilité et le tester ; ne supposez pas qu’un script de migration universel puisse rendre toutes les mises à jour du moteur compatibles.
Énoncer le contrat de compatibilité
Décidez quelles versions déjà publiées la prochaine version compilée prendra en charge avant de modifier l’état qu’elle sauvegarde. Définissez des politiques explicites pour les sauvegardes ordinaires, les déblocages persistants, les paramètres et les sauvegardes exportées depuis le navigateur ; ces catégories peuvent nécessiter des traitements différents. Prévenez les joueurs à l’avance lorsqu’un redémarrage de la partie pourrait être nécessaire.
Conservez un identifiant de version et, lorsque vous maîtrisez le format de sauvegarde, une version de schéma. Séparez la progression dans le contenu des paramètres de présentation et des données dérivées. Avant de modifier un champ persistant, consignez sa signification et sa valeur par défaut.
Privilégier des identifiants stables
Attribuez aux routes et aux scènes des identifiants stables qui restent valables après les réécritures et la traduction. Conservez ces identifiants tels quels aussi longtemps que vous promettez la compatibilité. Si l’un d’eux doit changer, prévoyez une migration ou indiquez clairement la limite au-delà de laquelle les anciennes sauvegardes ne sont plus prises en charge.
Si vous gérez votre propre format de sauvegarde, stockez des données simples, documentez le schéma et validez les données entrantes avant de les utiliser. Les sauvegardes natives du moteur peuvent reposer sur d’autres règles de sérialisation. Suivez les recommandations du moteur avant de remplacer un système de sauvegarde fiable par un sérialiseur maison.
Planifier une migration avant de modifier l’état
Rédigez le plan de migration avant de modifier un champ : l’ancien champ, le nouveau champ, la règle de conversion et la solution de repli pour les données absentes ou inattendues. Lorsque le format le permet, veillez à ce que les migrations soient déterministes et puissent être répétées. L’absence d’un champ sans rapport ne doit jamais accorder de progression.
Pour Ren'Py, suivez les recommandations sur les sauvegardes et le retour en arrière ainsi que les notes de compatibilité qui s’appliquent à vos versions. Pour SugarCube, vérifiez la version exacte du format et les API de sauvegarde. Pour un état personnalisé dans Godot, implémentez et testez le schéma que vous gérez. Une règle qui fonctionne dans un système ne s’applique pas nécessairement à un autre.
Conserver une bibliothèque de sauvegardes représentatives
Constituez une bibliothèque de sauvegardes couvrant le début, les moments juste avant les choix importants, chaque route majeure et l’approche de la fin. Incluez différents déblocages et paramètres, ainsi que les anciennes versions que vous prenez encore en charge. Utilisez des états de développement anonymisés et évitez de recueillir des données de joueurs dont vous n’avez pas besoin.
Effectuez les tests sur des copies, en laissant les originaux intacts. Consignez la version d’origine de chaque sauvegarde et l’état attendu après son chargement. Un chargement sans exception n’est que le premier contrôle : une sauvegarde peut encore placer un joueur sur la mauvaise route, dupliquer une récompense ou faire perdre un paramètre.
Tester une véritable mise à jour
Testez la version distribuable en suivant le parcours de mise à jour que les joueurs utiliseront réellement : installez-la ou servez-la selon le cas. Chargez une ancienne sauvegarde, poursuivez jusqu’au bout d’une scène significative, sauvegardez de nouveau et rechargez. Vérifiez séparément la progression persistante et les paramètres.
Pour les versions navigateur, vérifiez l’origine, le comportement du stockage et le contexte d’hébergement intégré. Un changement d’URL ou de contexte de stockage peut affecter l’accès aux données existantes, même si la logique du jeu reste inchangée. Si vous proposez l’exportation et l’importation, vérifiez ce moyen de récupération et expliquez ses limites.
Publier des informations claires sur la récupération
Publiez le parcours de mise à jour pris en charge, la méthode de copie de secours et les limites de compatibilité connues là où les joueurs pourront les trouver. Faites en sorte que le formulaire de signalement de bugs demande les informations de version utiles. Si une version ne peut pas préserver sans risque une catégorie de sauvegardes, expliquez cette limite avant qu’un joueur n’écrase sa dernière copie fonctionnelle.
Archivez la version testée, les notes sur le schéma et la matrice de sauvegardes avec chaque sortie. Conservez un lien entre les décisions de migration et les révisions du code source. Des contrôles réguliers de compatibilité facilitent la maintenance et vous permettent de détecter les problèmes avant les joueurs.
Décisions clés
- Indiquez les versions prises en charge et définissez une politique pour chaque catégorie de sauvegardes.
- Conservez des ID stables et documentez la signification et la valeur par défaut de chaque champ.
- Après la migration, vérifiez la progression, puis sauvegardez et rechargez.
- Protégez les sauvegardes originales et expliquez aux joueurs comment les récupérer.
Fichiers du guide
Matrice de test ↓Les communautés externes consacrées aux modèles et les sites de publication externes peuvent contenir du contenu explicite. Les liens vers les sources s’ouvrent dans un nouvel onglet ; ce guide ne charge pas leurs aperçus.
Sources et lectures complémentaires +
- Documentation Ren'Py sur les sauvegardes et le retour en arrière ↗
- Modifications incompatibles de Ren'Py ↗
- Sauvegarder des parties avec Godot ↗
- Documentation SugarCube ↗
Dernière vérification 5 octobre 2026.