Cómo hacer un tower defense con IA: torres, oleadas y coste
Cómo hacer un tower defense con IA
Un tower defense se describe en texto: un camino por el que avanzan enemigos, casillas donde colocar torres, dinero que ganas al matar y oleadas que suben de dificultad. Zugo genera un juego 2D de navegador, lo prueba en un entorno aislado antes de entregarlo y lo publica en tu-slug.zugo.run. La construcción cuesta 6 créditos.
El género se genera bien porque sus reglas son numéricas y explícitas. La parte difícil no es que las torres disparen, sino que las cifras se aguanten entre sí, y eso se afina jugando y corrigiendo.
¿Qué hace difícil un tower defense frente a otros juegos?
Que es un juego de economía disfrazado de juego de acción. El jugador no controla nada durante el combate: decide antes, gastando dinero, y luego mira si acertó. Todo el interés vive en si esa decisión era ajustada o evidente.
De ahí sale el problema central. Si las torres son baratas respecto a lo que pagan los enemigos, el jugador llena el mapa y gana sin pensar. Si son caras, la primera oleada arrasa y se cierra la pestaña. El margen entre las dos situaciones es estrecho y no se adivina desde el prompt.
Por eso conviene tratar la primera construcción como una maqueta de reglas y no como un juego terminado. Está todo conectado y funcionando, pero los números iniciales son una propuesta, no un equilibrio. El contexto general de lo que sale de una descripción está en ¿puede la IA crear un juego?.
¿Qué hay que escribir en el prompt?
Nombra el camino, la moneda, las torres y la condición de derrota. Un prompt que solo pide "un tower defense" deja esas cuatro decisiones al azar, y luego cada corrección cuesta una edición.
| Elemento | Formulación débil | Formulación fuerte |
|---|---|---|
| Mapa | "un mapa" | "una cuadrícula con un camino fijo de la entrada a la salida" |
| Colocación | "poner torres" | "se coloca con clic en las casillas libres junto al camino" |
| Economía | no se dice | "empiezas con dinero para dos torres y cada enemigo muerto paga" |
| Torres | "varias torres" | "tres tipos: rápida y débil, lenta y fuerte, y una que ralentiza" |
| Enemigos | "enemigos" | "avanzan por el camino, tienen vida y velocidad propias" |
| Derrota | no se dice | "cada enemigo que llega a la salida quita una vida, con diez pierdes" |
| Oleadas | no se dice | "botón para llamar a la siguiente oleada antes de tiempo" |
La fila de la economía es la que decide si hay juego. Sin una cifra inicial explícita, la generación suele dar demasiado dinero de partida, y el jugador construye la defensa completa antes de la primera oleada.
La del botón de oleada anticipada parece un detalle y no lo es. Convierte la espera en una decisión, porque el jugador puede arriesgarse a solapar dos tandas a cambio de terminar antes. Es la mecánica que más rejugabilidad aporta por menos código.
¿Cómo se equilibra la economía sin pelearse con los números?
Ajustando una sola palanca por edición y jugando entre una y otra. Hay cuatro, y con esas cuatro se resuelve la práctica totalidad de los desequilibrios.
El precio de la primera torre respecto al dinero inicial es la primera palanca. La regla cómoda es empezar con lo justo para dos torres: obliga a elegir dónde ponerlas y crea la primera decisión interesante del juego en los diez segundos iniciales.
El pago por enemigo es la segunda. Si la oleada completa paga más de lo que cuesta una torre nueva, la defensa crece más rápido que la amenaza y el juego se resuelve solo hacia la mitad. Pedir que una oleada pague aproximadamente una torre mantiene la tensión.
La tercera es la mejora frente a la torre nueva. Si mejorar una torre existente sale siempre mejor, el mapa se queda vacío; si sale siempre peor, nadie mejora nada. Que las dos opciones sean defendibles según la situación es lo que hace que el jugador piense.
La cuarta es la vida de los enemigos por oleada. Un crecimiento suave aburre y uno brusco frustra. Descríbelo en consecuencias: "que la oleada diez se pueda perder si has jugado mal, pero se gane si has repartido bien las torres".
¿Cómo se diseñan las oleadas para que no aburran?
Cambiando el tipo de amenaza, no solo la cantidad. Multiplicar enemigos idénticos sube la dificultad y baja el interés, porque la respuesta correcta sigue siendo la misma de antes.
Con tres perfiles ya hay decisiones distintas: uno normal, uno rápido y con poca vida que castiga las torres lentas, y uno muy resistente y lento que obliga a concentrar daño. Descríbelos por comportamiento, que es lo que se traduce bien a código, y no por su aspecto.
El grupo mixto es lo que da el mejor momento de la partida. Una oleada de rápidos con dos resistentes detrás rompe cualquier defensa demasiado especializada, y esa es exactamente la lección que el jugador aprende y aplica en la siguiente partida.
También merece la pena pedir una vista previa de lo que viene. Saber que la oleada siguiente trae enemigos rápidos permite prepararse, y prepararse es lo que convierte la espera en juego en lugar de en pausa.
¿Qué falla siempre en la primera versión?
Tres cosas concretas, y las tres se corrigen con una edición cada una. Conocerlas de antemano evita interpretar un resultado normal como un fracaso.
Las torres disparan a través de las paredes o al enemigo equivocado. Lo habitual es que apunten al más cercano, que casi nunca es la elección correcta. Pedir que ataquen al que va más adelantado en el camino cambia por completo la eficacia de la defensa.
El dinero no se ve o no se actualiza. Es fácil que la cifra exista en el código pero no en pantalla, y entonces el jugador coloca torres a ciegas. Compruébalo antes que nada, porque sin ese número no hay juego que valorar.
La victoria no existe. Muchas primeras versiones tienen derrota pero no final: las oleadas siguen indefinidamente y el jugador nunca gana. Decide si quieres un modo con final o uno infinito con récord, y dilo, porque son dos juegos distintos.
¿Se puede jugar con el dedo en una pantalla táctil?
Sí, y este género se adapta mejor que casi cualquier otro, porque colocar torres es tocar. Aun así hay que pedirlo, o el resultado saldrá pensado para ratón.
Los dos puntos que hay que nombrar son el tamaño de las casillas y el menú de compra. Una cuadrícula pensada para un cursor tiene celdas demasiado pequeñas para un pulgar, y el menú de torres suele quedar en un lateral que en vertical desaparece de la vista.
La confirmación es el tercer punto. En una pantalla táctil es facilísimo colocar una torre por error en la casilla de al lado, y sin poder deshacer, ese error arruina la partida. Pedir un paso de confirmación o un botón de vender resuelve el problema entero. Cómo redactar estas peticiones para que salgan a la primera está en cómo escribir un buen prompt.
¿Cuántos créditos cuesta terminarlo?
La construcción es la parte barata y previsible. El gasto de verdad está en las pasadas de equilibrio, que son varias por definición.
| Acción | Créditos |
|---|---|
| Construir el juego | 6 |
| Una edición en el chat | 3 |
| Construcción en modo Hi-Fi | 12 |
| Edición en modo Hi-Fi | 6 |
Un tower defense presentable suele salir con una construcción y entre ocho y diez ediciones, porque el equilibrio exige más idas y venidas que cualquier otro género. El plan Pro cuesta $25 al mes y da 200 créditos, que son 33 construcciones o 66 ediciones, margen de sobra para llevar dos juegos en paralelo.
El plan gratuito da 5 créditos, menos de lo que cuesta una construcción. Sirve para ver la herramienta por dentro y clonar una plantilla de la galería, no para terminar un tower defense desde cero. Business cuesta $99 al mes con 800 créditos.
¿Qué no vas a conseguir con este formato?
Los juegos son 2D y de navegador. Un tower defense clásico entra perfectamente ahí, pero no esperes una versión 3D, un ejecutable ni una ficha de tienda de aplicaciones a partir de esto.
Un juego con árbol de mejoras, varios mapas desbloqueables, progreso guardado entre sesiones y tabla de clasificación no cabe en un prompt. Se levanta por capas con ediciones sucesivas, y guardar partidas entre dispositivos requiere base de datos, es decir conectar Supabase. La lógica de negocio muy específica se afina corrigiendo, no describiendo mejor.
Y el límite más importante: el equilibrio no se genera. La herramienta implementa fielmente los números que le des, y unos números malos producen un juego que funciona sin fallos y no engancha a nadie. Zugo no sustituye a un equipo de desarrollo en un producto complejo, aunque el código sea tuyo y puedas exportarlo a GitHub. Si prefieres un género donde la economía sea el juego entero y no un soporte, mira cómo hacer un juego incremental.
¿Cuál es el primer paso?
Describe un mapa con un solo camino, dos tipos de torre, tres oleadas y diez vidas. Es lo mínimo que ya se puede jugar y juzgar, y es mucho más barato de corregir que un diseño completo mal calibrado.
Después juega tres partidas seguidas antes de tocar nada. La primera enseña si funciona, la segunda si hay decisión y la tercera si aburre, y esas tres respuestas valen más que cualquier ajuste hecho a ciegas. Puedes construir el tuyo en Zugo.