Commencer par une boucle fonctionnelle, puis fiabiliser sa progression
Un jeu idle exige plus qu’un compteur qui augmente lorsque la page est ouverte. Les joueurs s’attendent à conserver leurs améliorations après un rafraîchissement, à recevoir une progression raisonnable à leur retour et à ne pas perdre leur travail lors des mises à jour. Traitez la sauvegarde, le calcul hors ligne et la compatibilité comme des comportements distincts, avec leurs propres vérifications.
Ce processus poursuit un concept de serre illustratif, pas un projet existant généré ou testé. Cliquer rapporte des pièces fictives ; chaque jardinier acheté produit une pièce par seconde. Le prochain jardinier coûte ceil(10 × 1.15^n), où n est le nombre déjà possédé. Commencez avec une boucle fonctionnelle de gains et d’achats. Vous définirez un contrat de sauvegarde, calculerez une récompense de retour plafonnée et préserverez la progression lors d’une modification ultérieure, sans confondre stockage local et sauvegarde cloud.
Préciser ce que le jeu doit mémoriser
Rédigez le contrat de sauvegarde avant de demander du code. Une version minimale comprend la version du schéma, le solde de pièces actuel, le nombre de jardiniers, les améliorations achetées et le moment jusqu’auquel les gains ont déjà été calculés. Conservez les règles de taux de production avec les définitions des améliorations. Sauvegardez les achats qui sous-tendent le solde affiché, pas des copies contradictoires d’un état dérivé.
Demandez un résumé lisible de la sauvegarde pendant le développement afin de comparer l’état du jeu à l’état stocké. Évitez d’exposer des informations privées dans les sorties de diagnostic. Distinguez également une sauvegarde locale d’une sauvegarde liée à un compte. Le stockage du navigateur appartient à un profil de navigateur et peut être effacé. Il ne promet ni progression entre appareils, ni soldes compétitifs sécurisés, ni récupération après suppression des données du site par le joueur.
Utilisez cette demande limitée :
Ajoute une sauvegarde locale versionnée pour les pièces, les jardiniers, les améliorations achetées et l’heure du dernier calcul. Restaure l’état avant d’afficher un écran jouable. Valide les valeurs chargées. Si aucune sauvegarde n’existe, démarre une nouvelle partie. Si une sauvegarde est invalide, explique le comportement de récupération au lieu de produire silencieusement des soldes impossibles. Garde inchangés les graphismes et les règles de gain existants.
Sauvegardez après les achats importants et définissez une sauvegarde périodique si le jeu en a besoin. Ne dépendez pas exclusivement d’un événement de fermeture de page : un navigateur ou un appareil peut s’arrêter sans transmettre le dernier événement attendu.
Calculer une seule fois les récompenses d’absence, avec un plafond clair
La progression hors ligne consiste généralement à calculer une récompense au retour du joueur. Elle n’exige pas que le script du jeu continue de tourner après la fermeture du navigateur. Une règle transparente est :
récompense = taux de production sauvegardé admissible × min(max(heure de retour − heure du dernier calcul, 0), huit heures)
Définissez le sens du taux admissible avant l’implémentation. Dans ce modèle simple, il s’agit du taux de production des jardiniers et améliorations sauvegardés au départ. Repoussez les simulations complexes jusqu’à ce que le calcul de base fonctionne.
Pour vérifier une valeur attendue, deux jardiniers produisant chacun une pièce par seconde rapporteraient 1 200 pièces sur un intervalle contrôlé de dix minutes. Une absence de dix heures ne compterait que huit heures avec le plafond de l’exemple. Utilisez ce calcul comme valeur attendue dans votre journal d’exécution.
Après attribution de la progression, le jeu doit mettre à jour l’état du calcul afin qu’un rafraîchissement ne récompense pas à nouveau la même absence. Demandez un message de retour indiquant la durée prise en compte et la récompense accordée. Décrivez la récompense calculée sans suggérer qu’un serveur fonctionne en permanence.
Exemples détaillés : récompenses hors ligne
Ces exemples supposent un taux de production fixe, des pièces fictives et un plafond de deux heures lorsqu’il est indiqué. Ils décrivent des calculs attendus, pas des résultats mesurés dans un jeu testé.
| Scénario | Calcul | Récompense attendue |
|---|---|---|
| 1 jardinier, absence de 10 minutes | 1 pièce/seconde × 600 secondes | 600 pièces fictives |
| 2 jardiniers, absence de 30 minutes | 2 pièces/seconde × 1 800 secondes | 3 600 pièces fictives |
| 1 jardinier, absence de 3 heures, plafond de 2 heures | 1 pièce/seconde × min(10 800, 7 200) secondes | 7 200 pièces fictives |
| Rechargement immédiat après le calcul | L’intervalle déjà calculé n’est pas compté à nouveau. | 0 pièce supplémentaire pour cet intervalle |
Tester la sauvegarde séparément du calcul du temps
Gagnez d’abord un solde connu, achetez un jardinier et rafraîchissez la page. Vérifiez que le solde et l’achat subsistent. Fermez ensuite le navigateur, attendez un intervalle mesuré et revenez. Notez l’état initial, le temps réel écoulé, la récompense observée et l’état final. Rafraîchissez immédiatement et vérifiez que la même récompense n’est pas répétée.
Utilisez une horloge de test contrôlée pour les longs intervalles et une véritable fermeture suivie d’un retour pour le parcours normal. Testez un temps écoulé négatif, un intervalle excessivement long, une sauvegarde vide et une sauvegarde endommagée. Définissez le comportement attendu dans chaque cas avant d’observer le résultat. Un intervalle négatif ne doit pas soustraire la monnaie gagnée. Un intervalle long ne doit pas contourner le plafond.
Le joueur peut modifier l’heure locale de l’appareil. Borner le temps écoulé aide à éviter des erreurs évidentes, mais ne rend pas une économie locale résistante à la fraude. Les économies compétitives ou payantes nécessitent une conception distincte de calcul faisant autorité et de sécurité.
Tableau de test du retour
| Action | Comportement attendu | Si la vérification échoue |
|---|---|---|
| Acheter une amélioration puis rafraîchir | Le solde sauvegardé et l’amélioration achetée sont restaurés ensemble. | Examiner quels champs ont été sauvegardés et à quel moment. |
| Revenir après un intervalle mesuré | La récompense suit le taux et le plafond de temps documentés. | Comparer l’horodatage de calcul stocké, le taux et le temps écoulé. |
| Recharger immédiatement après la récompense de retour | Le même intervalle n’est pas récompensé deux fois. | Vérifier que l’horodatage de calcul avance avec la récompense. |
| Ouvrir un autre navigateur ou appareil | Le comportement correspond au modèle déclaré, local ou lié à un compte. | Vérifier l’existence d’un mécanisme de synchronisation entre appareils. |
| Charger une ancienne sauvegarde après un changement de règle | Les achats et le solde suivent la migration documentée. | Examiner la version de sauvegarde et le processus de migration ou de récupération. |
Effectuer une amélioration ultérieure sans réinitialiser le joueur
Une fois la sauvegarde fonctionnelle, demandez une petite modification de contenu :
Réduis le prix de base du jardinier de dix à huit pièces pour les achats futurs, en gardant le facteur de croissance 1.15. Préserve les pièces, jardiniers, améliorations possédées, graphismes et calcul hors ligne existants. Prends en charge la version actuelle des données sauvegardées. Montre comment une ancienne sauvegarde est migrée si le nouvel état nécessite des champs supplémentaires.
Conservez une véritable sauvegarde antérieure et un build fonctionnel avant cette demande. Chargez cette sauvegarde dans la version révisée et comparez le solde, les achats et le taux de production obtenus. L’ajout d’un champ ne doit pas entraîner l’abandon de tout l’état simplement parce que l’ancienne sauvegarde ne le contient pas. Décidez si les achats antérieurs conservent leurs avantages avant de modifier l’économie.
Si des améliorations disparaissent, examinez la migration et le chargement avant d’ajouter des fonctionnalités. Un nouveau bouton ne prouve pas la compatibilité des sauvegardes.
Utiliser SEELE pour des modifications de persistance limitées
SEELE propose un processus guidé par prompts pour créer des jeux et demander des modifications ultérieures. Ici, l’entrée pertinente est l’économie fonctionnelle accompagnée d’un contrat de sauvegarde précis ; le résultat souhaité est une révision candidate dont vous pouvez examiner le chargement et le calcul. Demandez la plus petite modification de persistance avant de solliciter une migration ou de nouvelles améliorations.
Conservez un build fonctionnel et une sauvegarde de référence en dehors de la modification évaluée. Lorsqu’une vérification échoue, signalez les différences d’état exactes et précisez si le problème est survenu au chargement, au retour ou à l’achat. Le positionnement du produit ne prouve pas à lui seul l’existence de sauvegardes cloud, d’horloges sécurisées, de garanties de migration ni la fiabilité d’une implémentation particulière de stockage local.
Continuer seulement lorsque le retour est cohérent
Un jeu idle fiable doit expliquer d’où viennent ses nombres : ce qui a produit la récompense, quel intervalle d’absence a compté et quels achats restent possédés. Utilisez l’aide de l’IA pour modifier ces règles de façon limitée, puis jugez chaque changement dans le jeu en cours d’exécution. N’échangez pas une sauvegarde fonctionnelle contre une liste de fonctionnalités plus longue.
Utilisez SEELE pour demander une sauvegarde locale et une récompense de retour plafonnée dans votre projet existant. Conservez une version dont le fonctionnement est connu avant de demander une autre modification économique. La prochaine étape n’est pas une promesse plus ambitieuse : c’est un retour vérifié avec la progression antérieure du joueur intacte.
FAQ
La progression hors ligne signifie-t-elle que le jeu tourne lorsque mon navigateur est fermé ?
Pas nécessairement. Une approche courante sauvegarde l’état et l’heure du calcul, puis calcule une récompense lors de la visite suivante. Cela peut permettre des récompenses hors ligne sans processus de navigateur en fonctionnement continu. Vérifiez l’implémentation réelle avant de la décrire. Une simulation côté serveur est une autre architecture et ne doit pas être suggérée par une récompense calculée localement.
Une sauvegarde du navigateur passe-t-elle sur un autre appareil ?
Ne le supposez pas. Le stockage local du navigateur reste normalement lié à son profil et aux données du site. Les sauvegardes entre appareils nécessitent une synchronisation ou un système de compte explicite, ainsi que des décisions sur les conflits et la confidentialité. Indiquez aux lecteurs ce que la démo testée utilise réellement plutôt que de présenter un exemple de persistance locale comme une fonction de sauvegarde cloud.
Puis-je changer les prix des améliorations après que des personnes ont déjà joué ?
Oui, si la conception révisée définit le traitement des achats existants et de l’état sauvegardé. Conservez une sauvegarde de référence, décidez quels avantages restent acquis et testez la migration avant de publier la modification. Écraser simplement la liste des prix ne prouve pas que la progression antérieure reste valide. Si le comportement n’a pas encore été testé, présentez-le comme une exigence plutôt que comme une mise à jour réussie.
