Itérations : améliorer le jeu sans le casser
Les jeux cassent plus facilement que les sites : physique, vitesses et collisions sont liées entre elles. La boucle sûre : une modification → jouer → la suivante, sauvegarder les versions et réparer avec « décris le symptôme ».
Vous avez demandé « rends les astéroïdes plus rapides », et maintenant le vaisseau les traverse comme du beurre. Voici le couplage du code de jeu. Avancez prudemment.
La boucle : une modification → jouer → la suivante
La règle du vibe coding « une modification à la fois » est presque une loi dans les jeux : chaque retouche change le ressenti, et le ressenti doit passer par vos mains. Vous avez changé une vitesse ? Jouez trente secondes. Ajouté un bonus ? Jouez. Jouer après chaque modification, ce n'est pas de la procrastination, c'est du contrôle qualité.
Conservez vos versions
Dans le chat, demandez : « donnez-moi le code actuel complet sous forme de fichier » et enregistrez-le sous game-v3.html avant toute grosse manœuvre. Si ça casse sans espoir, vous revenez à la v3 et vous commandez autrement. (Lovable et Replit versionnent tout seuls : là-bas, cliquez sur annuler.)
Réparer par symptôme
Pas « répare mon jeu » : décrivez ce que vous voyez.
- « Le vaisseau sort par le bord de l'écran et ne revient jamais »
- « Après un redémarrage, la vitesse reste au maximum alors qu'elle devrait se réinitialiser »
- « Un seul bonus compte les points deux fois »
Un symptôme précis obtient une réparation précise. Ça marche parce que l'IA voit le code et vous voyez le comportement : à vous deux, ça fait une équipe complète.
Régler l'équilibre avec des nombres
Demandez ceci : « regroupez les réglages dans un bloc en haut du code, avec des commentaires : vitesse du joueur, fréquence des astéroïdes, montée de difficulté ». Désormais, équilibrer revient à changer un nombre dans le fichier, sans passer par le chat. C'est votre premier pas vers la lecture du code, et il est indolore.
Short questions on the lesson — with an explanation for every answer.