Cómo hacer un puzle de piezas que caen con IA
Cómo hacer un puzle de piezas que caen con IA
Describe el tablero, las formas que caen, la rotación y qué ocurre cuando se completa una línea. Zugo genera un juego 200D de navegador, lo arranca en un entorno aislado antes de entregarlo y lo publica en tu-slug.zugo.run. La construcción cuesta 600 créditos y cada corrección posterior, 300.
Es un género engañoso: parece de los más simples porque las reglas caben en cuatro frases, y en realidad esconde una decena de casos límite que solo aparecen jugando. Nombrarlos en el prompt evita la mitad de las correcciones.
¿Qué cabe de este género en un solo prompt?
Cabe el núcleo completo: una rejilla vertical, piezas de varias formas que bajan solas, movimiento lateral, rotación, apilado y eliminación de filas llenas. Todo eso es lógica de tablero, que es justo lo que un generador de texto describe bien.
Lo que no cabe de una vez es el sistema alrededor: menús, modos de dificultad, tabla de récords compartida, animaciones de celebración y música. Cada una de esas capas es una petición aparte, y pedirlas todas juntas suele producir un resultado en el que ninguna queda fina.
La estrategia que funciona es construir el tablero, jugarlo hasta que el apilado se sienta correcto y solo entonces añadir adornos. El contexto general sobre qué sale de un prompt de juego está en ¿puede la IA crear un juego?.
¿Qué entrega la primera construcción?
Una partida jugable de principio a fin: piezas que aparecen arriba, teclado para moverlas y girarlas, colisión con el suelo y con lo ya apilado, filas que desaparecen al completarse y un final cuando la pila llega al techo.
Lo que rara vez llega bien calibrado es el ritmo. La velocidad inicial de caída, cuánto acelera con los puntos y cuánto tiempo tienes para colocar una pieza antes de que se fije son valores que la generación elige sin consultarte.
Tampoco llega decidida la previsualización. Ver la siguiente pieza cambia por completo la naturaleza del juego, porque convierte la reacción en planificación. Si no lo pides, puede aparecer o no, y esa moneda al aire es evitable escribiendo una frase.
¿Qué reglas conviene escribir en el prompt?
Las que decidan el comportamiento del tablero, no las que decidan el aspecto. El color de las piezas se cambia después en una edición barata; una regla de colisión mal entendida obliga a rehacer la lógica.
| Regla | Formulación floja | Formulación útil |
|---|---|---|
| Tablero | "una rejilla" | "rejilla de 10 columnas por 20 filas, vertical" |
| Piezas | "bloques" | "siete formas distintas de cuatro celdas cada una" |
| Controles | "con el teclado" | "flechas para mover, flecha arriba para girar, espacio para bajar de golpe" |
| Líneas | no se dice | "la fila completa desaparece y todo lo de arriba baja una posición" |
| Puntos | no se dice | "más puntos cuantas más filas se eliminen a la vez" |
| Final | no se dice | "la partida termina si una pieza nueva no cabe al aparecer" |
| Siguiente pieza | no se dice | "un recuadro lateral muestra la pieza que viene" |
La fila del final es la que más se olvida. Sin ella el juego no sabe cuándo parar, y lo habitual es que las piezas se sigan apilando fuera de la pantalla mientras la partida continúa en un estado absurdo.
La de la puntuación por filas múltiples es la que aporta más profundidad por menos palabras: es la única razón por la que un jugador se arriesga a acumular en vez de limpiar en cuanto puede.
¿Por qué la rotación pegada a la pared es el fallo número uno?
Porque es un caso límite que casi nadie describe y que aparece a los treinta segundos de jugar. Una pieza junto al borde intenta girar, la forma girada se sale de la rejilla y el juego responde de la peor manera posible: no hace nada, sin explicar por qué.
La corrección se pide en una frase: que la pieza se desplace hacia dentro lo justo para caber al girar, en lugar de rechazar el giro. Es una edición de 300 créditos y es la que más mejora la sensación de control de todo el proyecto.
El segundo caso límite del mismo grupo es el giro contra la pila. Ahí conviene decidir a propósito si permites que la pieza se empuje hacia arriba para encajar o si el giro simplemente no ocurre, porque las dos opciones dan juegos con dificultad distinta.
¿Cómo se ajusta la velocidad de caída?
Con ediciones cortas y una variable cada vez. Este género se rompe con facilidad si tocas dos números a la vez, porque el efecto de uno tapa el del otro.
La velocidad inicial es la primera. Descríbela en términos de sensación y no de cifras: "que al empezar dé tiempo de sobra a pensar dónde colocar la pieza" comunica mejor que cualquier número de milisegundos.
La curva de aceleración es la segunda y la que decide cuánto dura una partida. Si sube demasiado rápido, nadie pasa del primer minuto y el juego se percibe como injusto; si no sube nunca, la partida se hace eterna y aburre.
La tercera es el retardo de fijación: ese instante en el que la pieza ya ha tocado, pero todavía se puede deslizar. Pedirlo explícitamente elimina la sensación de que el tablero te ha robado la última colocación. Cómo redactar estas correcciones sin ambigüedad está en cómo editar después de generar.
¿Cómo se hace paso a paso?
- Escribe el prompt con las siete reglas de la tabla. Tablero, piezas, controles, líneas, puntos, final y previsualización. Nada de estética todavía.
- Espera la construcción comprobada. Un juego sencillo queda jugable en cerca de un minuto, y la construcción que no arranca se reporta como fallo en lugar de entregarse a medias.
- Juega tres partidas seguidas. Una para comprobar la rotación en las dos paredes, otra para llegar al techo a propósito y otra para eliminar varias filas de golpe.
- Corrige primero la rotación. Es la edición que más se nota y la que condiciona cómo juzgas todo lo demás.
- Ajusta después la velocidad. Con el control resuelto, ya puedes valorar si la dificultad sube demasiado pronto.
- Deja el aspecto para el final. Colores, tipografía y efectos son ediciones seguras que no vuelven a mover la lógica.
¿Cuántos créditos cuesta dejarlo terminado?
La construcción es la parte barata. El coste real está en las tres o cuatro correcciones de sensación que separan un prototipo de algo que apetece volver a abrir.
| Acción | Créditos |
|---|---|
| Construir el juego | 600 |
| Una edición | 300 |
| Construcción en modo Hi-Fi | 1200 |
| Edición en modo Hi-Fi | 600 |
Un puzle de este tipo suele quedar cerrado con una construcción y unas cinco ediciones: rotación, velocidad, retardo de fijación, puntuación y aspecto. Son veintiún créditos, que caben de sobra en el plan Pro de $25 al mes con 20.000 créditos (unas 33 construcciones o 66 ediciones). Business cuesta $50 al mes con 20.000 créditos.
El plan gratuito da 2400 créditos: cuatro construcciones u ocho ediciones.
¿Dónde están los límites honestos del formato?
Los juegos que salen de aquí son 2D y de navegador. Este género encaja perfectamente en ese molde, pero de aquí no sale un ejecutable de escritorio ni una ficha lista para una tienda de aplicaciones.
El multijugador en tiempo real, con dos tableros enfrentados y líneas que se envían al rival, queda fuera de lo razonable en un prompt. Una tabla de récords compartida entre jugadores sí es posible, pero deja de ser un juego suelto: necesita base de datos, es decir conectar Supabase.
Y conviene decirlo claro: la herramienta acierta con las reglas que le nombras, no con el equilibrio. Si la curva de dificultad está mal repartida, el juego funcionará sin un solo error y aburrirá igual. Para un producto complejo, Zugo no sustituye a un equipo de desarrollo, aunque el código sea tuyo y se exporte a GitHub.
¿Por dónde empezar hoy?
Escribe cinco frases: cómo es el tablero, cuántas formas caen, con qué teclas se controlan, qué pasa al completar una fila y cuándo termina la partida. Con eso ya tienes algo que se juega en pantalla.
Después dedica las dos primeras ediciones a la rotación y a la velocidad, en ese orden, y ninguna al color. Si quieres afinar el texto de partida antes de gastar la primera construcción, cómo escribir un buen prompt ahorra un par de intentos. Puedes montar el tuyo en Zugo.