Planifica un juego de plataformas cooperativo con reglas claras

Especifica una condición compartida, comprueba la llegada de ambos jugadores y amplía el nivel solo cuando la recuperación funcione.

Seele Editorial TeamActualizado 14 de noviembre de 2026

Un juego de plataformas cooperativo necesita una condición compartida clara: qué hace cada jugador, cuándo cuentan juntas sus acciones y qué ocurre si alguien falla. Define ese ciclo pequeño antes de pedir un nivel largo. Twinspan Relay es un ejemplo de diseño original en papel, no un prototipo existente ni una prueba de juego. Su ventana de emparejamiento de 1,5 segundos y el puente de 4 segundos facilitan revisar las reglas; no son valores de equilibrio medidos.

Dos mensajeros se preparan para saltar hacia plataformas emparejadas sobre un barranco costero.
Ambos jugadores parten de un punto de control compartido y se dirigen a su propia plataforma al otro lado del mismo hueco.

Define el contrato cooperativo

Describe el ciclo de acciones como una secuencia de estados, no con una consigna como «haz que cooperen». Twinspan Relay da a ambos mensajeros los mismos movimientos de correr y saltar. En cada relevo, A debe tocar la plataforma azul y B la ámbar. El primer aterrizaje correcto inicia un temporizador compartido. Si el segundo jugador llega a la plataforma correspondiente a tiempo, aparece un puente breve; ambos deben cruzarlo antes de que se retire. El punto de control solo avanza cuando llegan los dos.

El contrato también define el fallo. Una plataforma incorrecta, una caída o el vencimiento del temporizador devuelve a ambos jugadores al último punto de control compartido y elimina el puente. En este diseño didáctico nadie queda esperando solo ni pierde una vida. Si uno llega al punto de control mientras el otro sigue cruzando, permanece inactivo hasta que estén los dos. Así el progreso depende del estado del equipo.

Acción del jugadorCambio del estado compartidoQué ocurre después
El primer jugador aterriza en la plataforma que tiene asignadaInicia una ventana de emparejamiento de 1,5 segundos y registra qué plataforma está ocupadaEl otro jugador aún puede completar el par
El segundo jugador aterriza en su plataforma correspondiente antes de que termine el temporizadorMarca el par como completo y abre un puente transitable durante 4 segundosAmbos jugadores avanzan hacia el mismo punto de control
Ambos jugadores llegan al punto de control antes de que se cierre el puenteAvanza el punto de control compartido y borra el temporizador del relevoPresenta el siguiente par de plataformas
Plataforma incorrecta, caída, aterrizaje tardío o vencimiento del puenteBorra el par activo y devuelve a ambos jugadores al punto de control anteriorPermite que el equipo vuelva a intentar el mismo relevo

La tabla hace visibles el tiempo y la recuperación para ambos jugadores. Antes de añadir escenarios o mecánicas, comprueba que cada fila indique un desencadenante, un cambio de estado y el estado siguiente. Si solo se indica que «se abre el puente», el prompt también debe especificar cuándo se cierra y cómo se recupera el equipo.

Prompt 1: escribe las reglas compartidas

Usa un prompt de contrato breve para fijar el número de jugadores, el alcance de pantalla, el objetivo conjunto y la regla de recuperación. Pide que se indiquen las suposiciones pendientes en vez de dejar que el creador rellene los vacíos en silencio.

Planifica un juego de plataformas cooperativo local para dos jugadores en una pantalla compartida. Ambos pueden correr y saltar con los mismos movimientos; ninguno tiene habilidades especiales. El objetivo común es cruzar tres relevos de plataformas emparejadas y llegar juntos a la salida.

En cada relevo, A debe aterrizar en la plataforma azul y B en la ámbar. El primer aterrizaje correcto inicia una ventana de emparejamiento de 1,5 segundos. Si el segundo jugador aterriza en la plataforma asignada antes de que venza, forma un puente transitable continuo durante 4 segundos. Ambos deben llegar al siguiente punto de control compartido antes de que se cierre el puente. Una plataforma incorrecta, una caída, perder la ventana o que venza el puente devuelve a ambos al último punto de control compartido y borra el temporizador y el puente activos. El punto de control solo avanza cuando llegan los dos. La salida se abre cuando ambos alcanzan sus plataformas finales correspondientes. Reiniciar devuelve a ambos al punto inicial y borra todos los temporizadores.

Devuelve una tabla de estados con la posición de ambos jugadores, las plataformas asignadas, el temporizador de emparejamiento, el del puente, el punto de control compartido y el estado de la salida. Enumera las suposiciones pendientes. Mantén el plan local y en una sola pantalla; no añadas red, poderes asimétricos, vidas ni eventos aleatorios.

Este prompt es una plantilla de diseño, no el registro de una partida. Pide al creador que muestre los estados necesarios para la revisión. Si el esquema de controles asigna botones distintos a los dos mandos, comprueba que ambos conserven las mismas acciones y que las instrucciones identifiquen las entradas de cada jugador antes del primer hueco.

Escribe el prompt para un solo hueco

Convierte el contrato en un encuentro breve con un inicio, una interacción y un punto de control reconocible. Usa un solo par de plataformas y un hueco para limitar las posibles causas de un resultado confuso. Especifica qué ven los jugadores antes del salto, cómo inicia el reloj el primer aterrizaje y cómo indica el puente el tiempo restante.

En Twinspan, las dos plataformas brillan con colores distintos y están en salientes opuestos. El primer aterrizaje válido inicia la ventana de 1,5 segundos; el segundo forma el puente. El camino temporal debe tener anchura suficiente para reconocerse como ruta, y el punto de control que hay al otro lado permanece inactivo hasta que llegan ambos mensajeros.

Dos mensajeros aterrizan en las plataformas correspondientes mientras se forma un puente de piedra compartido.
El puente confirma que el par tuvo éxito y su duración de cuatro segundos da a ambos jugadores la siguiente tarea compartida.

Prompt 2: solicita un relevo

Limita la solicitud del primer prototipo. Incluye el reinicio y una señal de estado visible junto al movimiento: ambos forman parte del ciclo cooperativo.

Crea un prototipo pequeño de plataformas cooperativo local para dos jugadores a partir de este contrato. Usa una pantalla compartida, dos mandos y los mismos movimientos de correr y saltar para ambos. Construye un único hueco alcanzable con un saliente inicial seguro, una plataforma azul para A, una ámbar para B y un punto de control compartido al otro lado.

Muestra a ambos jugadores, los colores de sus plataformas asignadas, la ventana de emparejamiento de 1,5 segundos tras el primer aterrizaje correcto y una indicación clara del temporizador de 4 segundos del puente cuando ambas plataformas correspondientes estén ocupadas. El puente debe ser una superficie transitable continua. Avanza el punto de control solo cuando ambos lo toquen antes de que se cierre el puente. Si un jugador cae, aterriza en la plataforma equivocada, llega después de la ventana o pierde el plazo del puente, devuelve a ambos al punto de control anterior y borra el estado activo. Añade un reinicio que los devuelva al comienzo.

Usa una cámara lo bastante amplia para mostrar a ambos jugadores y todo el hueco. Incluye una pantalla compacta de controles. No añadas otros huecos, coleccionables, ataques enemigos, poderes especiales, eventos aleatorios ni juego en línea. Indica qué reglas se implementaron y cuáles siguen sin verificar; no des por hecho que este encargo generó un prototipo satisfactorio.

Una buena especificación no garantiza su implementación. Si la usas con una herramienta de creación, revisa si la señal de estado cambia en cada desencadenante y si el segundo jugador puede actuar mientras espera el primero. Guarda el prompt real y la versión del prototipo antes de comparar cambios posteriores.

Amplía la ruta solo después del primer relevo

Cuando una versión real de un solo hueco supere las comprobaciones con los jugadores en cada posición, amplía la ruta sin cambiar las reglas básicas. Reutiliza colores, temporizadores, duración del puente, reinicio y comportamiento del punto de control. Modifica una característica geométrica cada vez, como la anchura del hueco o la altura del aterrizaje, para localizar con más facilidad los fallos posteriores.

EtapaMantener fijoCambiar solo cuando
Encuentro de un solo huecoDos jugadores, un par de plataformas asignadas, reinicio y punto de control compartidosLos dos órdenes de llegada y un caso de fallo coinciden con el contrato
Ruta de tres relevosMismos movimientos, asignación de plataformas, temporizadores y recuperaciónEl siguiente relevo empieza solo tras avanzar el punto de control conjunto
Salida finalObjetivo visible de cada jugador y condición de llegada conjuntaLa puerta se abre solo cuando ambos llegan a sus plataformas finales
Iteración del escenarioColisiones, señales, encuadre de cámara y lógica del relevoSe puede comparar un único cambio visual o espacial con la misma secuencia

El prompt de ampliación debe conservar estas invariantes y pedir un resumen de la ruta que muestre el relevo activo y el punto de control. No añadas una habilidad solo porque el siguiente hueco sea más difícil; primero decide si el reto debe poner a prueba el tiempo, la comunicación o la distancia de salto.

Prompt 3: añade dos relevos más

Solo después de revisar la versión de un hueco con sus criterios de aceptación, amplía la misma ruta cooperativa local con dos relevos de plataformas emparejadas y una salida final. Conserva los mismos movimientos, asignación azul/ámbar, ventana de emparejamiento de 1,5 segundos, puente de 4 segundos, regla de punto de control conjunto, reinicio tras fallar o caer y comportamiento de reinicio. Cambia únicamente la separación entre huecos, la altura de aterrizaje y el escenario entre relevos.

Mantén visibles a ambos jugadores cuando aparezca una señal de emparejamiento. Muestra el punto de control compartido actual, el relevo activo y si cada jugador está antes del hueco, en su plataforma asignada, cruzando el puente o en el punto de control. La puerta final se abre solo cuando ambos llegan a sus plataformas de salida correspondientes. Devuelve un mapa compacto de la ruta y una lista de transiciones de estado. No añadas redes, nuevos poderes, enemigos ni reglas aleatorias. Si no se ha revisado una versión de un hueco, presenta esto como una ampliación planificada y no la marques como verificada.

Verifica los estados de ambos jugadores

Escribe secuencias de acciones repetibles antes de decidir si un momento cooperativo está claro. Registra las posiciones iniciales, quién aterriza primero, el tiempo entre aterrizajes, si se abre el puente y si avanza el punto de control compartido. Los valores siguientes son un cálculo en papel para Twinspan Relay, no observaciones de un prototipo jugable.

En el primer relevo, A aterriza en la plataforma azul en t=0; B aterriza en la ámbar en t=1.0. Un segundo está dentro de la ventana de emparejamiento de 1,5 segundos, así que el puente se abre en t=1.0 y vence en t=5.0. Ambos jugadores llegan al punto de control en t=3.2, antes de que se cierre, por lo que avanza el estado del ejemplo. En el segundo relevo, B llega en t=1.9, después de que venza la ventana de emparejamiento en t=1.5. No se forma ningún puente y ambos regresan al punto de control compartido anterior.

Secuencia de accionesEstado compartido esperadoQué comprueba
A aterriza en 0,0 s; B en 1,0 s; ambos llegan al punto de control en 3,2 sEl par tiene éxito; el puente permanece de 1,0 a 5,0 s; avanza el punto de control compartidoPlataformas coincidentes, inicio del temporizador, duración del puente y llegada conjunta
A aterriza en 0,0 s; B en 1,9 sEl temporizador vence a los 1,5 s; no se forma el puente; ambos se reinicianLa llegada tardía no abre el puente ni deja que un jugador avance solo
Cualquiera aterriza en el color incorrectoEl relevo falla y ambos regresan al último punto de control compartidoLa asignación de plataformas es legible y se aplica de forma coherente
Ambos aciertan sus plataformas, pero un jugador cae antes del punto de controlEl puente desaparece; ninguno conserva progreso individualLa recuperación del fallo sigue siendo compartida
Solo un jugador llega al punto de control antes de que se cierre el puenteEl punto de control permanece inactivo; ambos se reinician al vencer el tiempoUn jugador no puede hacer avanzar al equipo por su cuenta
Ambos llegan a las plataformas finales emparejadasLa salida se abre y se completa la ruta compartidaLa condición de finalización requiere a ambos jugadores
Se reinicia desde cualquier relevo activoAmbos vuelven al inicio; se borran los temporizadores y los puentesEl reinicio elimina cualquier estado compartido anterior

Estos estados esperados son casos de aceptación para ejecutar más adelante en un prototipo real. No son evidencias de prueba. Un registro útil incluye la versión de las reglas, ambos mandos, acciones, tiempos, posiciones, estado del relevo, punto de control y resultado. Si el resultado difiere, mantén fija la secuencia mientras investigas.

Ambos mensajeros llegan juntos a la salida abierta tras cruzar un puente temporal.
La meta compartida solo se alcanza cuando ambos mensajeros cruzan el último relevo y ocupan las plataformas de salida asignadas.

Corrige el fallo sin cambiar todo el ciclo

Cuando falle un par, localiza el primer estado que difiere de la secuencia prevista. Si un jugador no vio la asignación de plataforma, mejora la señal o el encuadre antes de cambiar el temporizador. Si se registra el aterrizaje correcto pero no se abre el puente, revisa la coincidencia de plataformas y el inicio del temporizador. Si alguien avanza solo, corrige la condición del punto de control antes de añadir nivel.

En una revisión real, cambia una sola causa cada vez y repite la misma secuencia. Un ajuste de cámara no debería cambiar también la ventana de emparejamiento; iluminar más la plataforma no debería alterar la regla de reinicio. Anota por separado lo observado, la causa que sospechas y el cambio realizado. Sin prototipo ni observaciones de jugadores, presenta una corrección propuesta como idea de diseño, no como una mejora demostrada.

Prompt 4: solicita una revisión acotada

Con la secuencia real de acciones y el registro de estados que te proporcionaré, identifica el primer punto donde el relevo cooperativo difiere del contrato escrito. Distingue un error de implementación de un problema de visibilidad, cámara o controles. Propón un cambio pequeño, indica qué debe permanecer igual y vuelve a escribir la misma secuencia como comprobación de repetición.

No inventes comentarios de jugadores, resultados de prueba ni una revisión exitosa. Si no hay registro de observación, devuelve una lista de causas probables sin afirmar que alguna ocurrió. Conserva el punto de control compartido, la asignación de plataformas, los temporizadores y las reglas de reinicio, salvo que la evidencia indique específicamente cuál cambiar.

Usa un escenario multijugador pequeño como punto de partida

La página Multiplayer Game Maker de SEELE describe cómo planificar el número de jugadores, los roles, los objetivos compartidos, las reglas de interacción y un escenario breve. También indica que el juego en línea requiere implementación específica, redes, sincronización, alojamiento y pruebas. Esta orientación ayuda a plantear el concepto cooperativo, pero no verifica los controles locales de Twinspan Relay ni hace funcionar sus tiempos exactos. Antes de ampliar el modo, revisa los cambios de estado de ambos jugadores en el resultado real.

Empieza por escribir el objetivo compartido y una secuencia de aceptación. Cuando quieras plantear ese concepto multijugador breve, usa el Multiplayer game maker. Usa la página como referencia de planificación y confirma el comportamiento necesario en el proyecto que construyas.

Preguntas frecuentes

¿Cuántos jugadores debería tener un primer juego de plataformas cooperativo?

Empieza con dos jugadores en una pantalla compartida. Basta para comprobar si ambos tienen una acción útil y si el movimiento de uno cambia un resultado compartido. Añade más jugadores solo cuando la asignación de plataformas, el temporizador, el punto de control y las reglas finales sigan siendo legibles al repetirlas con el primer par.

¿Los jugadores cooperativos necesitan habilidades diferentes?

No. Dos jugadores pueden coordinarse mediante el tiempo, la posición o los objetivos compartidos usando los mismos movimientos. Los poderes distintos añaden otro sistema que explicar; incorpóralos solo cuando el ciclo básico funcione y la nueva habilidad cree una decisión que ninguno pueda resolver a solas.

¿Qué ocurre si solo un jugador llega al punto de control?

En el diseño de Twinspan, el punto de control no avanza hasta que llegan ambos jugadores. Si el puente vence antes, ambos regresan al punto de control compartido anterior. Así se evita que la llegada individual deje al otro jugador atrás o cree un estado del que el equipo no pueda recuperarse.

¿Un creador de juegos con IA puede garantizar el modo cooperativo en línea?

Ningún prompt demuestra por sí solo que funcionen las redes, la sincronización, el alojamiento o el juego entre varios dispositivos. Una página de planificación ayuda a definir el número de jugadores y las reglas de interacción, pero un proyecto real aún necesita implementación y pruebas en los dispositivos y condiciones de red previstos. Distingue el juego local en pantalla compartida de las afirmaciones sobre juego en línea.

¿Se probaron los tiempos de emparejamiento y del puente?

No. La ventana de emparejamiento de 1,5 segundos y la duración de 4 segundos del puente son valores ilustrativos del ejemplo en papel. Muestran cómo especificar los tiempos en un prompt. Usa acciones observadas en un prototipo real para decidir si cambiarlos y registra cada revisión por separado.

SEELE AI

Convierte esta guía en un proyecto jugable.

Empieza con una idea concreta y desarróllala en el espacio de trabajo de Seele AI.

Empezar a crear