Le jour où le nuage a failli me trahir
J’ai lancé le jeu sur mon téléphone après une session sur la tablette. L’écran de départ affiche fièrement « Jour 12 », comme hier. Pourtant, quand je frappe le premier gardien, le marteau sonne creux : la batterie n’est pas chargée. Pire, le défi quotidien est à zéro. Le nuage a fusionné les sauvegardes, mais il a oublié qui j’étais.
En creusant, je découvre que l’identifiant du joueur — ce petit numéro qui me distingue des autres — n’était pas fusionné du tout. Si deux appareils se synchronisaient, chacun gardait son propre identifiant. Pour le classement, j’aurais compté comme deux personnes. Et si l’un des deux appareils avait une sauvegarde plus ancienne, la fusion aurait pu écraser la progression la plus récente.
Le problème venait d’une politique de fusion écrite des mois plus tôt, alors que le schéma de sauvegarde était plus simple. Huit champs avaient été ajoutés depuis, dont l’identifiant, et la fusion les ignorait purement et simplement. Le bug était silencieux : pas de crash, pas d’erreur visible, juste une progression qui s’effrite.
Trois erreurs en une, et comment les réparer
La première erreur était technique : la fusion ne couvrait pas tous les champs. Mais les deux autres étaient plus sournoises.
D’abord, l’identifiant s’échangeait au lieu de converger. Si mon téléphone avait l’identifiant 100 et ma tablette l’identifiant 200, une synchronisation mutuelle aurait pu créer une boucle sans fin : le téléphone envoie 100, la tablette envoie 200, et aucun des deux ne l’emporte. J’ai corrigé en imposant une règle simple : le plus petit identifiant gagne. C’est symétrique, déterministe, et ça évite les conflits.
Ensuite, le compte d’essais du défi quotidien se sommait. Si j’avais fait trois essais sur mon téléphone et deux sur ma tablette, la fusion aurait pu me donner cinq essais au lieu de trois. J’ai remplacé l’addition par un maximum : le plus grand nombre d’essais l’emporte. C’est idempotent — si je synchronise deux fois la même sauvegarde, rien ne change.
Enfin, un distant malformé (une sauvegarde corrompue ou incomplète) interrompait la fusion en plein milieu. Résultat : la sauvegarde locale était à moitié fusionnée, et donc corrompue. J’ai modifié le code pour ignorer les entrées problématiques et continuer la fusion. Une sauvegarde partielle vaut mieux qu’une sauvegarde brisée.
La boucle qui protège tout
Le système de synchronisation suit maintenant une boucle immuable : lire, fusionner, écrire. Toujours écrire, même si la fusion n’a rien changé. Cette boucle est appelée au lancement du jeu et à la fin de chaque marche. Elle garantit que la sauvegarde locale est toujours à jour, même si la synchronisation échoue.
J’ai aussi protégé le nuage des parties de test. Avant, lancer le jeu avec l’option « --depart » (qui permet de démarrer à un niveau précis pour les tests) aurait pu écraser la sauvegarde du joueur avec un état de test. Maintenant, le nuage est verrouillé dans ce cas : rien n’est écrit, ni en local ni en distant.
Pour valider tout ça, j’ai écrit un script de test qui simule cinq scénarios : synchronisation simple, conflit d’identifiants, distant corrompu, etc. Ces tests ne touchent pas à la sauvegarde réelle du joueur, mais vérifient que la fusion se comporte comme prévu. C’est devenu une routine : avant chaque mise à jour, je lance ces épreuves pour m’assurer que le nuage reste fiable.
Ce que j’en retiens pour d’autres jeux
Une fusion de sauvegardes, c’est comme une opération chirurgicale : il faut couvrir tous les champs, prévoir les cas limites, et ne jamais laisser le patient dans un état instable. Voici les règles que je me suis fixées :
- Tout champ doit être fusionné. Même ceux ajoutés après coup. Une relecture du code ne suffit pas : il faut éprouver la fusion avec des données réelles.
- Les règles de fusion doivent être symétriques. Si appareil A et appareil B se synchronisent, le résultat doit être le même quel que soit l’ordre. Le plus petit identifiant, le plus grand nombre d’essais, la date la plus récente… Choisissez un critère simple et appliquez-le partout.
- Un distant corrompu ne doit pas casser la sauvegarde locale. Ignorez l’entrée problématique et continuez. Une sauvegarde partielle est préférable à une sauvegarde brisée.
- Testez avec des scénarios extrêmes. Synchronisation mutuelle, distant vide, distant corrompu, conflit de versions… Écrivez des tests qui couvrent ces cas, et lancez-les avant chaque mise à jour.
- Protégez les parties de test. Un outil de debug ne doit jamais écrire dans la sauvegarde réelle du joueur. Ajoutez des verrous pour éviter les accidents.
La synchronisation est un des aspects les plus invisibles d’un jeu, mais c’est aussi l’un des plus critiques. Quand elle échoue, le joueur perd sa progression, et c’est souvent irréversible. Dans Koloss Adventure, le nuage est désormais une promesse : quoi qu’il arrive, votre marche vous suit.
