Cómo hacer un matamarcianos (space shooter) con IA
Cómo hacer un matamarcianos (space shooter) con IA
Un matamarcianos se describe con cuatro piezas: una nave que se mueve, un disparo, enemigos que bajan en oleadas y vidas que se pierden al recibir impactos. Zugo lo genera como juego 2D de navegador, lo arranca en un entorno aislado antes de entregarlo y lo publica en tu-slug.zugo.run. La construcción cuesta 6 créditos.
Es un género generoso: la primera versión suele ser divertida enseguida. Lo que separa un prototipo de un juego terminado son las oleadas y la sensación del impacto, y ninguna de las dos cosas se acierta escribiendo más texto en el prompt inicial.
¿Qué versión del género conviene pedir?
La vertical clásica, con la nave abajo y los enemigos llegando desde arriba. Es la que menos ambigüedad genera, la que mejor se adapta a una pantalla de móvil y la que menos elementos necesita para resultar completa.
Las variantes horizontales, con desplazamiento lateral y escenario que avanza, son más exigentes: aparecen el fondo en movimiento, el terreno y la posición vertical libre, y eso multiplica los casos que hay que corregir después.
Si es tu primer juego, empieza por la vertical y guarda las ideas ambiciosas para las ediciones. El marco general de lo que se puede esperar de un prompt está en ¿puede la IA crear un juego?.
¿Qué funciona ya en la primera construcción?
Una nave controlable, disparos que suben y desaparecen al salir de la pantalla, enemigos que aparecen arriba y avanzan, colisión entre disparo y enemigo, colisión entre enemigo y nave, un marcador y una pantalla de fin de partida.
Lo que rara vez llega ajustado es la cadencia de disparo. O la nave dispara tan rápido que la pantalla se convierte en una pared blanca donde no se distingue nada, o dispara tan lento que jugar consiste en esperar.
Tampoco viene decidido cómo se pierde. Morir de un solo impacto y morir con tres vidas y un instante de invulnerabilidad tras recibir daño son dos juegos con públicos distintos. Si no lo dices, elige la generación.
¿Qué hay que especificar sobre disparo y enemigos?
Las reglas que gobiernan la cantidad de cosas en pantalla. Todo lo demás (colores, nave, fondo estrellado) es una edición barata que no toca la lógica.
| Elemento | Formulación floja | Formulación útil |
|---|---|---|
| Nave | "una nave" | "se mueve a izquierda y derecha con las flechas, no sube ni baja" |
| Disparo | "que dispare" | "dispara al mantener la barra espaciadora, con un intervalo mínimo entre balas" |
| Límite de balas | no se dice | "como mucho seis balas propias en pantalla a la vez" |
| Enemigos | "marcianos" | "bajan en filas, se desplazan en bloque y disparan de vez en cuando" |
| Vidas | no se dice | "tres vidas, con un instante de invulnerabilidad tras cada impacto" |
| Oleadas | no se dice | "al eliminar a todos, llega una oleada nueva algo más rápida" |
| Colisión | no se dice | "la zona de choque de la nave es menor que su dibujo" |
La fila del límite de balas es la que evita el desastre visual y también el de rendimiento: sin tope, mantener pulsado el disparo llena la pantalla de objetos y el navegador empieza a arrastrarse.
La de la zona de choque menor que el dibujo es la que decide si el juego se percibe justo. En un género donde esquivar es la mitad de la diversión, un roce en la punta del ala no debería costar una vida.
¿Por qué la pantalla se convierte en una alfombra de balas?
Porque el disparo enemigo se genera con probabilidad por enemigo y por instante, y esa cuenta escala mal. Con seis enemigos parece razonable; con veinticuatro, cada segundo caen tantos proyectiles que esquivar deja de ser posible.
La corrección se pide en términos de la pantalla, no del enemigo: que en el aire no haya nunca más de un número fijo de balas enemigas, sea cual sea la cantidad de naves vivas. Es una frase y arregla el problema de raíz.
El segundo remedio es la velocidad diferenciada. Balas enemigas más lentas que las tuyas dan tiempo de reacción y hacen legible la pantalla. Las dos son ediciones de 3 créditos, y conviene hacerlas por separado para saber cuál cambió qué. Cómo escribir correcciones que no arrastren otros cambios se explica en cómo editar después de generar.
¿Cómo se diseñan oleadas que suban de dificultad?
Con un patrón repetido y dos o tres variables que cambian. Pedir veinte oleadas distintas escritas a mano es caro y además innecesario: nadie percibe la diferencia entre la oleada nueve y la diez si el ritmo es bueno.
Lo que sí se nota son los cambios de tipo. Alternar entre enemigos que bajan rectos, otros que se desplazan en zigzag y otros que resisten dos impactos da variedad real con muy poca lógica añadida.
El otro recurso es el enemigo grande cada cierto número de oleadas: más resistencia, un patrón de disparo propio y una recompensa mayor. Funciona como signo de puntuación dentro de la partida y da al jugador la sensación de haber llegado a algún sitio.
Si prefieres partir de algo ya montado, una de las cinco plantillas de juego del catálogo (son 25 plantillas en total) es precisamente un matamarcianos por oleadas con enemigos finales: la plantilla Starforge se puede tomar como base y editar igual que cualquier proyecto generado.
¿Cómo se consigue que disparar se sienta contundente?
Con tres detalles pequeños que casi nadie pide y que cambian por completo la percepción del juego. Ninguno es lógica, todos son respuesta.
El primero es la destrucción visible: que el enemigo no desaparezca sin más, sino con una animación breve de explosión. Es la confirmación de que has acertado, y sin ella el disparo se siente vacío.
El segundo es la sacudida de pantalla al recibir daño, muy corta y muy leve. Comunica el golpe sin necesidad de texto y evita que el jugador pierda vidas sin darse cuenta.
El tercero es el sonido, y conviene pedirlo con moderación: un disparo repetido a volumen alto cansa en treinta segundos. Un efecto corto para el disparo, otro para la explosión y nada más suele ser suficiente.
¿Cuánto cuesta en créditos un matamarcianos completo?
La construcción es una fracción del total. Lo que se lleva el presupuesto es la serie de correcciones que convierten un prototipo en algo que aguanta cinco partidas seguidas.
| Acción | Créditos |
|---|---|
| Construir el juego | 6 |
| Una edición | 3 |
| Construcción en modo Hi-Fi | 12 |
| Edición en modo Hi-Fi | 6 |
Lo habitual son una construcción y unas seis ediciones: cadencia, tope de balas enemigas, zona de choque, tipos de enemigo, jefe y efectos de impacto. Veinticuatro créditos aproximadamente. El plan Pro son $25 al mes con 200 créditos, que dan para unas 33 construcciones o 66 ediciones; Business son $99 al mes con 800 créditos.
El plan Free incluye 5 créditos, menos de lo que cuesta una construcción, así que permite conocer la herramienta pero no terminar un juego con seis correcciones.
¿Qué no cabe en este formato?
Los juegos son 2D y de navegador. Un matamarcianos encaja de maravilla, pero de aquí no sale un ejecutable de escritorio ni una ficha lista para una tienda de aplicaciones.
Tampoco cabe el multijugador en red, ni un modo cooperativo entre dispositivos. Guardar récords entre jugadores distintos sí es posible, aunque exige base de datos, es decir conectar Supabase, y con eso el juego pasa a ser un producto que hay que mantener.
Y hay algo que no se genera: el equilibrio. La herramienta implementará con exactitud las oleadas que le describas, aunque sean aburridas o injustas. Esa parte se ajusta jugando. Para un producto complejo, Zugo no sustituye a un equipo de desarrollo, aunque el código sea tuyo y se pueda exportar a GitHub.
¿Cómo se escribe el primer prompt?
Seis frases: cómo se mueve la nave, cómo dispara, cuántas balas propias caben en pantalla, cómo llegan los enemigos, cuántas vidas tienes y qué pasa al limpiar una oleada. Sin jefes ni mejoras todavía.
Juega dos partidas enteras antes de pedir nada. Si la pantalla se ve confusa, tu primera edición es el tope de balas; si mueres sin ver de dónde vino el disparo, es la velocidad de los proyectiles enemigos. Monta el tuyo en Zugo.