Haz legibles las oleadas antes de añadir más movimientos

Haz legibles las oleadas enemigas antes de añadir movimientos

Para diseñar con IA un brawler de desplazamiento lateral, empieza con una sala donde el jugador pueda leer un ataque, esquivar su carril y recuperarse antes de la siguiente entrada enemiga. El primer problema no es cuántos movimientos existen, sino si el orden de acción, los avisos y los tiempos permiten entender por qué un golpe alcanza o falla.

La sala y sus tiempos son parámetros de diseño ficticios; no provienen de un prompt, una versión jugable, prueba de jugadores ni resultado observado de SEELE. La comparación siguiente es un cálculo manual en papel sobre el tiempo de entrada del segundo enemigo. No hubo una ejecución real ni se midió diversión o dificultad.

Mantén acotado el primer ciclo: leer el aviso → esquivar el carril → recuperar la acción → castigar la recuperación → despejar el grupo → abrir la siguiente sala. La decisión principal es cuándo aparece el siguiente enemigo respecto al tiempo de espera de la esquiva. Esto es un tutorial de sincronización de grupo, no de sistemas de retroceso o daño.

Fija los dos roles enemigos y el orden de acciones

Llama Foundry Walk a la sala. Se extiende horizontalmente de x=0 a 12 y tiene un carril cercano y otro lejano. El jugador comienza en x=2, en el carril cercano; una puerta está en x=11. Un Rusher carga por el carril cercano. Un Guard aparece después y barre una zona fija que abarca ambos carriles. En cada instante, primero se resuelve la acción del jugador y después se comprueban los impactos enemigos.

La trayectoria del Rusher por el carril cercano cruza la posición inicial x=2. En t=0,75, la orden de esquivar se resuelve antes de la comprobación del embiste y mueve al jugador a x=3, al carril lejano. El Rusher termina en x=3, cerca, de modo que el cambio de carril evita ese impacto. La esquiva dura 0,25 s y luego tiene 0,75 s de enfriamiento: después de ejecutarla en t=0,75, vuelve a estar disponible en t=1,75.

Escapar al otro carril sirve contra el Rusher, pero no siempre es seguro: el rectángulo propuesto del Guard cubre ambos. Esta distinción enseña por qué importa el orden temporal. Si el Guard comienza con d=0,5, su aviso de 0,75 s termina en t=1,25, antes de que el jugador recupere la esquiva en t=1,75. El jugador sigue en x=3 y queda dentro del barrido.

Pide un encuentro pequeño con señales observables

Un prompt útil nombra la arena, los controles, los cambios de estado enemigos, el orden de acciones, las señales de fallo y el reinicio. También indica qué dejar fuera para poder inspeccionar la primera sala. La propuesta siguiente no se ha ejecutado.

Crea una sala compacta de brawler 2.5D lateral llamada Foundry Walk. Usa una arena horizontal de 0 a 12 con carriles cercano y lejano. Empieza con el jugador en x=2, carril cercano, y una puerta cerrada en x=11. Dale un golpe ligero que alcance al enemigo más cercano a 1,5 unidades en el mismo carril, un paso entre carriles de 0,25 s y una esquiva que se mueva una unidad horizontal y cambie de carril en 0,25 s, evite las comprobaciones de impacto durante ese instante y tenga un enfriamiento de 0,75 s al terminar. En cada marca de tiempo, resuelve la orden del jugador antes de comprobar los impactos enemigos.

Aparece un Rusher en x=0, carril cercano. Muestra un aviso claro de 0,75 s en ese carril; luego avanza +3 unidades y comprueba el impacto después de la acción del jugador. Dale una recuperación de t=1,0 a 1,75; durante ella puede recibir un golpe ligero. Aparece un Guard en x=2,5, carril cercano, tras el retraso d. Su aviso de 0,75 s muestra una zona fija de barrido entre x=1,5 y 3,5 que cubre ambos carriles. Comprueba esa zona después de la acción del jugador, luego dale al Guard 0,75 s de recuperación y vulnerabilidad a un golpe. Usa d=0,5 para el escenario inicial en papel; mantén fijos los demás valores al comparar d=1,5.

Muestra señales distintas para el aviso, la esquiva, el impacto, la recuperación, la derrota y la apertura de la puerta. Abre la salida solo cuando hayan caído ambos enemigos. Añade un reinicio que restaure salud, posiciones enemigas, retraso de aparición y puerta. No añadas armas a distancia, jefes, árboles de progresión, sangre, tiempos aleatorios ni enemigos adicionales. Facilita la inspección de las cajas de colisión, la línea temporal, el enfriamiento y el reinicio. Es un brief de diseño ficticio, no evidencia de un juego generado o probado.

Después de una futura generación, inspecciona la primera sala según estas reglas antes de añadir funciones. Comprueba que haya un Rusher y un Guard; que el aviso del Rusher dure 0,75 s; que la acción del jugador preceda a la comprobación del impacto en el mismo instante; que el barrido del Guard cubra ambos carriles; que el enfriamiento empiece tras la esquiva de 0,25 s; y que la puerta espere a la derrota de ambos. Son comprobaciones propuestas, no resultados ya observados.

Traza por qué la aparición a medio segundo se cruza con la esquiva

Usa una línea de tiempo en vez de decir solo que la oleada va «demasiado rápido». El retraso base del Guard es d=0,5 s; su aviso de 0,75 s termina y el área se comprueba en t=1,25. La esquiva del jugador terminó en t=1,0, pero no vuelve a estar lista hasta t=1,75. En esta situación escrita, la coordenada x=3 del jugador está dentro del barrido de x=1,5 a 3,5.

El rectángulo del Guard incluye los dos carriles, así que esquivar al Rusher no protege del barrido. En x=3, el jugador también está dentro del alcance horizontal del golpe ligero, pero ese ataque es una acción del jugador y no cancela por sí solo el impacto recibido. El primer conflicto es temporal: la segunda señal termina antes de que vuelva la esquiva.

Comprueba en papel un cambio de tiempo

Cambia solo el retraso de aparición del Guard, de 0,5 a 1,5 segundos. Mantén fija su posición x, el aviso de 0,75 s, la zona de dos carriles, el daño, el movimiento del jugador, el enfriamiento y el Rusher. El barrido del Guard se comprueba entonces en t=2,25; la esquiva ya está disponible desde t=1,75. El jugador puede moverse de x=3 a x=4 antes de la comprobación, fuera de la zona x=1,5–3,5.

Es un cálculo en papel de una sola variable. No demuestra que 1,5 s sea divertido, que el jugador pueda reaccionar cómodamente ni que una implementación respete esos eventos. Expone una hipótesis comprobable: el retraso permite recuperar la esquiva antes del barrido. Una prueba real aún debe comprobar señal, respuesta y resultado.

El resultado completo va más allá de esquivar con seguridad. El Rusher y el Guard deben entrar en estados legibles, ofrecer una ventana de castigo y luego pasar al estado derrotado. Solo cuando ambos indicadores están completos se abre la puerta. No presentes la puerta abierta como consecuencia de una sola esquiva o del cálculo de aparición.

Diagnostica la primera sala antes de ampliarla

Si una versión futura no sigue el encuentro previsto, identifica el primer punto donde su estado visible se separa de las reglas. Evita cambiar varios tiempos a la vez. Una secuencia de acciones y marcas explícita permite distinguir el aviso, el desplazamiento, la comprobación del impacto, el enfriamiento y la condición de puerta.

Registra los resultados observados aparte del horario en papel. En un prototipo real, anota la versión, las entradas exactas, la señal visible, la comprobación del impacto, la salud antes y después, la disponibilidad de la esquiva y el estado de puerta. Si hay diferencia, conserva el primer desacuerdo reproducible y cambia una sola regla. No rellenes esos campos con resultados inventados.

Usa un creador de juegos con IA como flujo inicial

La página actual Free AI Game Maker de SEELE describe un proceso general: explicar una idea de juego en lenguaje natural, generar una primera versión jugable 2D o 3D, probarla en navegador y refinarla con más instrucciones. Indica que Workspace muestra el modelo de IA elegido, el saldo Koin disponible y el coste antes del envío. Eso permite iniciar un prototipo y revisarlo; no valida por sí mismo los tiempos enemigos de Foundry Walk.

Para este diseño, incluye la arena, las acciones del jugador, los avisos, el orden por marcas de tiempo, las áreas de impacto, la condición de despeje y el reinicio en un brief enfocado. Si la primera versión cambia cualquier regla, apunta la diferencia exacta antes de pedir otra modificación. Prueba las entradas y los tiempos en el juego real.

Esta distinción hace útil el siguiente paso: se puede explorar la idea con un flujo general de prompt a juego, y a la vez validar cada regla dentro del prototipo. La página del producto respalda la descripción general del flujo; los tiempos y el resultado de este encuentro ficticio siguen sin comprobar.

Continúa con una sala de brawler legible

Limita el primer encuentro a un Rusher, un Guard, una regla de esquiva y una puerta que solo se abre al derrotar a ambos. Decide primero si cada aviso, acción del jugador y comprobación de impacto ocurre en el orden escrito. Añade enemigos o movimientos después de observar una versión real y comprobar sus estados.

Cuando quieras convertir el brief en un prototipo, empieza con creador de juegos Free AI, revisa el coste actual de generación e inspecciona el resultado jugable según el contrato de la sala. Conserva la tabla de tiempos, realiza una comprobación real de la versión e informa las diferencias observadas sin presentarlas como una prueba satisfactoria.

Preguntas frecuentes

¿Cuál es el primer ciclo en un brawler lateral?

Empieza con un aviso legible, una esquiva del carril, una ventana de recuperación y una respuesta clara al despejar el grupo. El jugador debe saber por dónde irá el ataque y cuándo puede volver a actuar antes de añadir más movimientos.

¿Por qué el retraso de 0,5 segundos del Guard provoca un impacto?

Después de esquivar en t=0,75, el movimiento termina en t=1,0 y no puede volver a usarse hasta t=1,75. Con d=0,5, el aviso de 0,75 s del Guard termina y comprueba el barrido en t=1,25, cuando el jugador sigue en x=3 dentro de la zona x=1,5–3,5.

¿La revisión de 1,5 segundos cuenta como prueba de juego?

No. Es un cálculo manual que muestra que la esquiva vuelve a estar disponible en la comprobación revisada del Guard en t=2,25 y que el jugador podría moverse a x=4 antes de ese instante. No mide diversión, legibilidad, equilibrio ni funcionamiento real.

¿Qué debo inspeccionar en un prototipo jugable de brawler?

Compara cada aviso con el área real del impacto, confirma que la acción del jugador se resuelve antes de la comprobación en el mismo instante, mide el enfriamiento tras la esquiva, comprueba las ventanas de recuperación y verifica que la puerta espere a ambos enemigos. Prueba el reinicio completo.

¿Un creador de juegos con IA puede garantizar estos tiempos enemigos?

El flujo general del producto que se describe aquí no garantiza un resultado temporal concreto. Un brief en lenguaje natural puede explicar el ciclo solicitado y generar una versión para revisar, pero las entradas, colisiones, tiempos y estados deben probarse en el juego real antes de considerarlos correctos.