Empieza por la dependencia, no por las clases de personaje

Un juego cooperativo asimétrico funciona cuando cada jugador tiene información distinta y una acción que el otro no puede realizar. Empieza con un objetivo común, define una decisión necesaria para cada rol y comprueba que ninguno pueda resolver la sala por su cuenta. Este ejemplo, Lantern Relay, es un concepto didáctico ficticio de rescate en una cueva; no se ha construido ni probado.

Los prompts siguientes usan Lantern Relay, un concepto original de rescate en una cueva para dos participantes locales que se comunican por voz. El Guardián conoce una ruta fija y las opciones de compuertas remotas, pero no ve qué segmento del haz está iluminado. El Explorador ve el haz y maneja un espejo físico, pero no conoce el mapa completo.

Empieza por la dependencia, no por las clases de personaje

Antes de nombrar los roles, completa esta frase: «Llegamos a [shared goal] solo después de que un jugador use [private information] para realizar [action]y el otro use [different information] para realizar [different action]». Si cualquiera de las acciones puede eliminarse sin cambiar la solución, los roles tienen nombres diferentes, pero todavía no dependen uno del otro.

Para redactar un prompt de juego cooperativo asimétrico, escribe primero el objetivo compartido; después define un límite de información y una acción exclusiva para cada rol. Incluye la señal que debe comunicarse, el estado inicial, la respuesta visible a una acción incorrecta y la condición de reinicio.

Un ejemplo documentado de información dividida aparece en la guía oficial de juego remoto de Keep Talking and Nobody Explodes: el Desactivador ve la bomba, pero no el manual; los Expertos usan el manual sin ver la bomba. Lantern Relay tiene otro escenario y otra regla, pero sigue el principio de asignar información distinta a cada participante.

Asigna a ambos roles una tarea necesaria

En Lantern Relay, el Guardián conoce la ruta fija de la cueva y las opciones de compuerta remota, pero no puede ver qué segmento del haz está iluminado. El Explorador ve ese segmento y puede girar el único espejo físico, pero no conoce el mapa completo. El Guardián cambia la compuerta remota; el Explorador ajusta el espejo e informa qué parte del haz observa. Ninguna acción basta por sí sola.

Este es un contrato entre roles: cada lado tiene información privada, una acción vinculada a ella y una razón para comunicarse. Antes de redactar un prompt de juego completo, comprueba que el objetivo y la dependencia sean concretos.

La tabla también revela un fallo frecuente: si el mapa del Guardián ya muestra el segmento de haz activo, el informe del Explorador no aporta información nueva. Si el Guardián puede cambiar el espejo o el Explorador puede cambiar la compuerta remota, la dependencia desaparece. Asigna a cada rol una acción exclusiva y un estado que el otro no pueda ver directamente.

Usa tres prompts para pasar de las reglas a una sola sala

Mantén separadas las solicitudes para que cada respuesta tenga una tarea concreta. Primero define el contrato de roles. Después pide una interacción jugable compacta o, si la herramienta no puede crearla, una especificación de diseño que puedas revisar. Por último, compara observaciones reales con la especificación y propón una sola revisión acotada. No presentes una simulación como resultado de prueba.

Prompt 1: definir el contrato de roles

Diseña un concepto de juego cooperativo para exactamente [número de jugadores] participantes. Objetivo compartido: [una frase sobre lo que debe conseguir el grupo]. Suposición de comunicación: [voz local, texto o ninguna]. Para cada rol, especifica información privada, acción exclusiva, una señal que debe comunicar y qué ve el compañero. Indica la dependencia exacta entre las acciones y una respuesta visible para el éxito y el error. Evita añadir más roles o sistemas hasta que el contrato funcione.

Esta primera solicitud pide un contrato de diseño, no un mundo pulido. Comprueba que cada rol tenga algo que observar, algo que hacer y un informe que modifique la decisión de su compañero. Si un rol no afecta la solución, revisa la dependencia.

Prompt 2: delimitar la primera sala

Crea el diseño de una sala de rescate en una cueva llamada Lantern Relay. Es un concepto didáctico ficticio para dos participantes locales que se comunican por voz. El Guardián consulta un mapa fijo con un pasillo vertical y tres compuertas remotas: norte, centro y sur. El Explorador empieza junto a un espejo físico que solo puede girar. El Guardián no ve el segmento de haz iluminado; el Explorador ve el haz, pero no el mapa completo.

El objetivo es conectar el haz con el refugio y abrir la puerta. Al comenzar, la compuerta norte bloquea la ruta. El Explorador informa qué segmento alcanza el haz después de cada giro; el Guardián cambia una compuerta en respuesta. Solo se mueve un segmento por acción. Muestra el estado del haz y de la compuerta después de cada paso, proporciona una señal clara de acción inválida y permite reiniciar exactamente el estado inicial. No añadas temporizador, enemigos ni objetos aleatorios.

Después de recibir la respuesta, lee la tabla de estados antes de juzgar su dirección artística. Pregunta si una selección equivocada de compuerta produce una respuesta visible y recuperable, si el Explorador puede describir el haz con términos únicos y si el Guardián tiene que usar esa información.

Prompt 3: evaluar observaciones que realmente hayas reunido

Revisa las observaciones que aporto para este diseño cooperativo de una sala. No inventes acciones de jugadores, notas de pruebas ni resultados satisfactorios.

Contrato de diseño: [pega aquí las reglas y los roles].
Secuencia observada: [acciones, informes y respuestas, en orden].
Estado esperado: [qué debía ocurrir tras cada acción].
Estado observado: [qué ocurrió realmente].

Identifica la primera diferencia entre el estado esperado y el observado. Propón una sola revisión acotada y especifica qué observación futura permitiría comprobarla. Si no hay una secuencia observada, indica que no se puede evaluar el comportamiento de jugadores.

Lo importante es la información de entrada, no la palabra «evaluar». Sin una secuencia observada, solo se puede sugerir una comprobación de diseño; no informar cómo se comportaron los jugadores.

Comprueba si ambos jugadores importan

Una tabla de roles describe la intención; la sala aún necesita comprobaciones observables. Recorre el encuentro desde su estado inicial y pregunta qué sabe cada participante, cuándo comunica esa información y qué cambia la respuesta del otro. Distingue un turno de espera intencional de un rol que queda sin decisión.

Haz un cambio cada vez. Si el informe es ambiguo, aclara la señal antes de añadir un sistema de pistas. Si un rol está inactivo, reduce el número de pasos o dale una observación pertinente. Repite la misma secuencia después de cada revisión.

Revisar a partir de una observación real

Cuando puedas observar el diseño con jugadores, anota cuatro cosas: la acción, el resultado esperado, el resultado real y el primer momento de duda. No añadas motivos que nadie haya expresado. Ese registro distingue un problema de señal de uno de reglas o de ritmo.

Mantén igual el resto de la sala mientras revisas esa regla. Repite después el mismo estado inicial y comprueba si el informe cambia la decisión del compañero. Si no tienes observaciones, deja la revisión como hipótesis.

Llevar un brief acotado a un flujo de creación

Cuando el contrato en papel sea coherente, puedes probar la idea en un flujo de creación de juegos e inspeccionar el resultado. La página actual de Free AI game maker describe propuestas de juegos en lenguaje natural, revisión de resultados jugables en 2D o 3D e iteración en Workspace. También pide revisar opciones y costes antes de enviar. Esa descripción general no demuestra que haya compatibilidad con dos participantes locales, vistas separadas o voz.

Incluye en la solicitud el objetivo común, la primera acción de cada jugador, los estados de la sala y la respuesta esperada. Después comprueba si el resultado representa realmente cada condición. Una imagen o descripción no sustituye una prueba de interacción. La página del creador de juegos de puzles con IA puede servir para formular una regla, una pista visible, una acción de resolución y un resultado; no establece compatibilidad multijugador. Un buen primer resultado es el elemento más pequeño que puedes comparar con tu contrato. Conserva la sala solo si cada rol aporta información o una acción, el traspaso es necesario y los errores se distinguen de los aciertos.

Preguntas frecuentes