Un juego cooperativo de disparos contra zombis necesita algo más que dos jugadores y una cantidad creciente de enemigos. Requiere un objetivo compartido, tareas claras para cada jugador y breves ventanas de decisión donde compitan la munición, las reparaciones y el progreso. Esta guía convierte la premisa en una secuencia compacta de prompts y una ruta de tres oleadas resuelta a mano.
El ejemplo, Dead Air at Beacon Four, es un ejercicio de diseño ficticio. No se ejecutó ningún prompt ni se proporcionó un prototipo jugable o una sesión cooperativa; las cifras siguientes tampoco son datos de equilibrio probados. Úsalas como contrato en papel para adaptar y verifica los resultados en un prototipo real antes de describirlos.
Empieza con un objetivo compartido
«Dos jugadores disparan a los zombis» deja al generador la tarea de inventar por qué permanecen juntos. Dales una misión común que vincule el combate con un resultado visible: cargar una baliza de emergencia, mantener una puerta en pie y alcanzar juntos un punto de extracción. Esto plantea tres preguntas relacionadas para el primer prototipo: quién gasta munición en cada amenaza, qué puede hacer la pareja entre oleadas y qué estado cuenta como victoria del equipo.
Mantén pequeña la primera versión propuesta: un patio de estación bajo la lluvia, una carabina fija por superviviente, tres oleadas breves, una baliza, una puerta y un vehículo de rescate. El supuesto de diseño es que ambos comparten pantalla y usan mandos genéricos separados. El stick izquierdo mueve, el derecho apunta, el gatillo dispara e Interact activa la baliza o reanima. Es un plan ficticio de controles, no una afirmación de que una herramienta concreta admita cooperación local o conectividad.
Fija las reglas básicas antes de describir la horda
Anota el estado inicial, los costes, los tiempos y el reinicio antes de pedir el escenario. Una tabla breve revela reglas que adjetivos como «intenso» o «cooperativo» no pueden definir.
| Sistema | Regla propuesta para la primera versión | Qué debe solicitar el prompt |
|---|---|---|
| Supervivientes y arma | A y B empiezan con 3 puntos de salud, 2 cartuchos cargados y 4 de reserva. Cada uno lleva la misma carabina semiautomática. Cada disparo consume un cartucho cargado y un impacto derrota a un caminante con 1 punto de salud. | Muestra la salud y la munición de ambos jugadores y conserva el arma fija. Un fallo también consume el disparo, pero no inflige daño. |
| Oleadas y presión | Tres oleadas de 20 segundos generan 2, luego 3 y finalmente 4 caminantes básicos. Cada caminante que sobreviva inflige 1 punto de daño a la puerta al terminar la oleada y después abandona ese encuentro. | Haz legibles el temporizador de la oleada y los objetivos restantes. Indica que, si dos supervivientes empatan en la ruta más corta, el caminante se dirige a A. |
| Objetivo compartido | La puerta de acero empieza en 5/5 y la baliza en 0/3. El equipo gana solo después de la oleada 3, con la baliza en 3/3 y ambos supervivientes dentro de la zona del vehículo. | Mantén visibles por separado la integridad de la puerta y la carga de la baliza. Que solo un jugador llegue al vehículo no es una victoria. |
| Intermedio | En cada intervalo seguro de 8 segundos, cada superviviente realiza una acción: cargar, recargar hasta 2 cartuchos desde la reserva o reparar 1 punto de puerta hasta un máximo de 5. Se obtiene como máximo una carga de baliza por intervalo, aunque ambos elijan Cargar. Las decisiones se resuelven simultáneamente. | Especifica la resolución simultánea y el máximo de una carga. La segunda acción Cargar no produce efecto. |
| Caída y recuperación | Con 0 de salud, un superviviente queda caído durante 10 segundos. Un compañero a menos de 2 metros puede mantener Interact durante 2 segundos para restaurarle exactamente 1 punto de salud y borrar el temporizador. Cada superviviente puede ser reanimado una vez por partida; si vuelve a caer después de gastar esa oportunidad, la partida termina en derrota. | Solicita explícitamente el alcance, la duración de la pulsación, la salud restaurada, el efecto sobre el temporizador, el límite por jugador y la condición de derrota. |
| Reinicio | Reiniciar devuelve a la oleada 1 con 3 de salud por jugador, puerta 5, baliza 0, cargadores con 2 cartuchos cada uno, reserva de 4, sin temporizadores de caída y las oportunidades de reanimación de ambos disponibles. | Solicita un reinicio completo. Evita que la munición, el daño de la puerta, la carga de la baliza o los indicadores de reanimación pasen a la siguiente partida. |
Estas cifras permiten inspeccionar el prompt, pero no demuestran que el juego resulte justo. Por ejemplo, una oleada de 20 segundos requiere objetivos legibles y tiempo suficiente para decidir; solo un prototipo real puede revelar si la velocidad de movimiento, la separación de los enemigos y la respuesta de disparo permiten ese ritmo.
Sigue la carga, recarga y reparación a través de las oleadas
El intermedio convierte el objetivo compartido en una decisión de equipo. Cargar acerca la extracción, recargar repone disparos futuros y reparar protege la puerta. El diseño limita el avance de la baliza a una carga por intervalo para que ambos jugadores no completen el objetivo con acciones duplicadas.
| Fase | Acciones y resultado | Munición A / B | Puerta | Baliza | Salud A / B |
|---|---|---|---|---|---|
| Inicio | Dos jugadores entran en el patio; todavía no han disparado. | 2+4 / 2+4 | 5/5 | 0/3 | 3 / 3 |
| Oleada 1 | Aparecen dos caminantes. A y B alcanzan uno cada uno; ambos son derrotados. | 1+4 / 1+4 | 5/5 | 0/3 | 3 / 3 |
| Intermedio 1 | A carga una vez. B recarga un cartucho. | 1+4 / 2+3 | 5/5 | 1/3 | 3 / 3 |
| Oleada 2 | Aparecen tres caminantes. A y B alcanzan uno cada uno; queda uno, que inflige 1 punto de daño a la puerta al terminar el tiempo. | 0+4 / 1+3 | 4/5 | 1/3 | 3 / 3 |
| Intermedio 2 | B carga una vez. A recarga dos cartuchos. | 2+2 / 1+3 | 4/5 | 2/3 | 3 / 3 |
| Oleada 3 | Aparecen cuatro caminantes. Cada superviviente derrota uno; quedan dos, que infligen 2 puntos de daño a la puerta. | 1+2 / 0+3 | 2/5 | 2/3 | 3 / 3 |
| Intermedio 3 y extracción | A carga una vez. B repara 1 punto de puerta. Después ambos entran en la zona del vehículo. | 1+2 / 0+3 | 3/5 | 3/3 | 3 / 3 |
Las cuentas son fáciles de revisar: cada disparo resta un cartucho cargado; el caminante restante de la oleada 2 quita un punto de puerta; los dos restantes de la oleada 3 quitan dos; la reparación final añade uno. La baliza gana un punto en cada uno de los tres intervalos. En esta ruta redactada ningún superviviente recibe impactos, por lo que la salud permanece en 3/3 y no se usa ninguna reanimación. Este recorrido en papel no simula la búsqueda de rutas ni la puntería en tiempo real; hacen falta una implementación y una partida observada para afirmar que funcionan.
Usa una secuencia de prompts por etapas
No pidas en un solo prompt enorme que invente las reglas, construya la arena, equilibre las oleadas y pula el resultado. Divide el trabajo para corregir una regla ausente antes de que se convierta en un problema visual o de interacción.
1. Solicita el contrato de reglas y estados
Diseña un juego ficticio de disparos contra zombis con vista superior y controles twin-stick, cooperativo local en una misma pantalla, llamado Dead Air at Beacon Four. Antes de añadir arte, devuelve una tabla compacta de estados para dos supervivientes, un patio de estación, tres oleadas de 20 segundos (2/3/4 caminantes con 1 de salud), una carabina fija para cada uno, salud 3, cargador 2, reserva 4, puerta 5, baliza 0/3 e intervalo seguro de 8 segundos. Cada disparo consume siempre un cartucho; cada impacto derrota a un caminante; cada caminante restante al final de una oleada daña la puerta una vez y luego se retira. En cada intervalo, cada jugador puede cargar, recargar hasta dos cartuchos o reparar un punto de puerta; las elecciones se resuelven simultáneamente y el equipo obtiene como máximo una carga de baliza. Incluye las reglas de caída y reanimación, extracción de ambos jugadores, derrota y reinicio completo. Enumera ambigüedades en vez de inventar mecánicas en silencio. Es una solicitud de diseño, no una afirmación de que exista un prototipo.Este prompt solicita primero un modelo explícito de estados. Si la respuesta cambia el máximo de una carga, comparte la reserva o permite reiniciar con una reanimación ya gastada, resuelve el conflicto antes de pedir la escena.
2. Solicita solo la primera parte jugable
Usa la tabla acordada para solicitar una arena jugable con dos jugadores en la misma pantalla, una carabina idéntica para cada uno, una puerta, una baliza ámbar, tres oleadas crecientes, un intermedio de 8 segundos y una zona de extracción. Muestra la salud, munición cargada y de reserva, integridad de la puerta, carga de la baliza, oleada actual y tiempo restante con indicaciones claras. Implementa las elecciones simultáneas del intermedio, temporizador de caída de 10 segundos, reanimación de 2 segundos a menos de 2 metros que restaure 1 de salud, una reanimación por superviviente, derrota cuando la puerta llegue a cero y un reinicio que restablezca todos los valores indicados. Excluye campañas, jefes, mejoras de armas, desvíos, arenas adicionales y juego en línea. Devuelve los controles y una lista breve para inspeccionar los estados; no presentes como terminada una prueba que no se haya observado.Una solicitud acotada reduce las variables, pero aun así hay que inspeccionar el resultado generado. Si el flujo actual ofrece una versión jugable, compara sus controles y estados visibles con el contrato en vez de suponer que implementó cada mecánica solicitada.
3. Corrige una discrepancia tras una observación real
Cuando proporcione una acción real y el estado observado, compáralos con este estado esperado: [pega la fila exacta de oleada/intermedio]. Cambia solo la regla o indicación responsable de la discrepancia. Conserva sin cambios el estado del otro jugador, la puerta, la baliza, la munición y los tiempos. Devuelve la regla cambiada, los valores esperados antes y después y una comprobación repetible. Si no se adjunta una partida observada, no inventes un fallo ni afirmes que esta comprobación se superó.El tercer prompt es condicional intencionadamente. Este paquete no incluye una partida observada para pegar, por lo que sigue siendo una plantilla y no una iteración completada. Mantén esa distinción al publicar un tutorial: un ejemplo resuelto a mano puede enseñar qué revisar, pero no sustituye un resultado de prueba.
Comprueba la interacción, no solo el número de enemigos
Cuando exista un prototipo real, comprueba un estado observable cada vez. Estas son comprobaciones de aceptación planificadas, no resultados. Registra la entrada, el cambio esperado y el valor observado para mantener acotadas las correcciones.
| Comprobación planificada | Resultado esperado | Qué revelaría una discrepancia |
|---|---|---|
| Ambos jugadores eligen Cargar en un intermedio. | La baliza aumenta solo en uno. | Falta el límite de carga del equipo o la resolución simultánea. |
| Dispara con el cargador vacío. | No se produce ningún disparo; la munición sigue en cero. | La indicación de entrada o el coste del disparo no están claros. |
| Recarga con 1 cartucho cargado y 4 de reserva. | Se transfieren como máximo dos cartuchos; quedan 2 cargados y 3 de reserva. | Difiere la cantidad transferida o el límite de reserva. |
| Deja un caminante vivo al terminar la oleada. | La puerta pierde exactamente un punto y luego el caminante de ese encuentro se retira. | La limpieza al final de la oleada o el daño se aplica dos veces. |
| Deja caer a un superviviente y reanímalo dentro del alcance y el plazo. | Mantén Interact durante 2 segundos a menos de 2 metros; restaura 1 de salud y borra el temporizador de 10 segundos. | Hay que corregir el objetivo, el alcance, la duración o el estado de recuperación. |
| Vuelve a derribar al mismo superviviente cuando ya gastó su oportunidad. | La partida termina inmediatamente en derrota. | El indicador de reanimación por superviviente no persiste. |
| Termina la oleada 3 con la baliza cargada y un jugador fuera de la extracción. | No hay victoria hasta que ambos entren en la zona del vehículo. | La condición de finalización compartida está incompleta. |
| Reinicia después de recibir daño y una reanimación. | Oleada 1, salud 3 para cada uno, puerta 5, baliza 0, cargadores 2, reserva 4 y ambas reanimaciones disponibles. | Parte del estado de la partida persistió tras el reinicio. |
No llames «probada» a una interacción porque aparezca en el prompt o una ilustración conceptual muestre su respuesta. Una prueba necesita un prototipo real, una entrada repetible y un resultado observado. Hasta entonces, etiqueta la tabla como plan.
Usa la página general de supervivencia como referencia acotada
La página oficial actual de AI Survival Game Generator describe un flujo general de planificación de supervivencia: suministros limitados, presión ambiental legible, un objetivo seguro y recuperación tras errores. Son ingredientes útiles para formular un primer encargo de supervivencia. La página no define reglas específicas de zombis, controles para dos jugadores, cooperación en una pantalla ni redes. Incluye esas mecánicas en tu contrato de diseño e inspecciona qué admite realmente un resultado actual.
Como punto de partida general del producto, usa la página AI survival game La ruta de origen es actual, pero la ruta propuesta para este Blog es provisional y el slug de atribución solo es local. Confirma la URL aceptada del Blog y concilia el slug antes de publicar. No infieras que la página creó este ejemplo ni que admite sus sistemas cooperativos.
Haz una revisión basada en una observación
Cuando haya un resultado jugable, compara la primera discrepancia de estado con la tabla de reglas. Si quedan dos caminantes al terminar la oleada pero la puerta recibe tres daños, revisa el evento de cierre de la oleada antes de cambiar al mismo tiempo la velocidad de los enemigos, la salud y la baliza. Cambia una causa, repite el mismo caso y registra el estado nuevo. Así la iteración queda vinculada a la evidencia.
Como aquí no se proporciona una versión jugable, lo adecuado es tratar el ciclo ficticio como una especificación en papel y las comprobaciones como no ejecutadas. Adapta los valores y solicita una primera versión acotada; solo después sustituye los ejemplos por observaciones medidas. Añade jefes, mapas de campaña o configuraciones de armas cuando el ciclo básico para dos jugadores sea visible e inspeccionable.
Preguntas frecuentes
¿Qué hace cooperativa la primera oleada?
Dales a ambos jugadores un objetivo común y suficientes decisiones simultáneas para que sus acciones importen. En este ejemplo ficticio defienden una puerta y cargan una baliza, mientras cada uno apunta a un caminante distinto. El diseño no presupone cómo se implementan las entradas de cada jugador; los controles y el comportamiento del equipo deben revisarse en un prototipo real.
¿Cómo deberían aumentar las primeras tres oleadas?
Cambia un valor de presión legible cada vez. El ejemplo empieza con 2 caminantes, luego 3 y finalmente 4, manteniendo a cada uno en 1 de salud y cada oleada en 20 segundos. Son cifras propuestas para el ejemplo en papel, no una dificultad medida. Un prototipo real requeriría comprobaciones repetidas de la separación de apariciones, el tiempo para apuntar y la presión sobre la puerta.
¿Ambos jugadores deberían compartir munición?
Este diseño da a cada superviviente su propio cargador y reserva para que los disparos de uno no gasten en secreto los recursos del compañero. Cada disparo consume un cartucho cargado y la recarga transfiere como máximo dos. También se podría compartir la munición, pero el primer prompt debe elegir un modelo y mostrar sus valores antes y después.
¿Qué ocurre cuando derriban a un superviviente?
En este conjunto de reglas propuesto, llegar a cero de salud inicia un temporizador de 10 segundos. Un compañero a menos de 2 metros mantiene Interact durante 2 segundos; si tiene éxito, restaura exactamente 1 de salud y borra el temporizador. Cada superviviente puede ser reanimado una vez por partida; si vuelve a caer después de gastar esa oportunidad, la partida termina en derrota. Es una regla de diseño ficticia, no una función probada.
¿Un prompt garantiza cooperación en línea?
No. Un prompt es una solicitud, no una prueba de implementación. La página oficial del producto ofrece un contexto amplio de planificación de supervivencia; no define juego contra zombis, controles cooperativos locales ni redes. Inspecciona un resultado actual antes de describir funciones y no afirmes que este ejemplo ficticio se haya generado o probado.
