Iteraciones: mejorar el juego sin romperlo
Los juegos se rompen con los cambios más que las webs: física, velocidades y colisiones están entrelazadas. El ciclo seguro: un cambio → jugar → el siguiente, guardar versiones y arreglar con «describe el síntoma».
Pediste «haz que los asteroides vayan más rápido» y ahora la nave los atraviesa como si nada. Te presento el acoplamiento del código de juego. Toquemos con cuidado.
El ciclo: un cambio → jugar → el siguiente
La regla del vibe coding de un cambio cada vez es casi ley en los juegos: cada retoque cambia cómo se siente el juego, y eso hay que pasarlo por las manos. ¿Cambiaste una velocidad? Juega treinta segundos. ¿Añadiste un bonus? Juega. Jugar después de cada cambio no es procrastinar, es control de calidad.
Guarda tus versiones
En el chat, pide: «dame el código completo actual como archivo» y guárdalo como game-v3.html antes de nada grande. Si se rompe sin remedio, vuelves a la v3 y lo pides de otra manera. (Lovable y Replit versionan solos: ahí dale a deshacer.)
Arreglar por síntoma
Nada de «arregla mi juego»: describe lo que ves.
- «La nave se sale por el borde de la pantalla y ya no vuelve»
- «Después de reiniciar, la velocidad se queda al máximo; debería resetearse»
- «Un mismo bonus suma puntos dos veces»
Un síntoma preciso recibe un arreglo preciso. Funciona porque la IA ve el código y tú ves el comportamiento: entre los dos, sois un equipo completo.
Ajustar el balance con números
Pide esto: «saca los ajustes a un bloque al principio del código con comentarios: velocidad del jugador, frecuencia de asteroides, subida de dificultad». Ahora balancear es cambiar un número en el archivo, sin pasar por el chat. Es tu primer paso hacia leer código, y encima indoloro.
Short questions on the lesson — with an explanation for every answer.