Diseña un primer caso detectivesco con pruebas rastreables

Un buen prompt para un juego de detectives hace más que pedir una sala misteriosa y unas cuantas pistas. Define qué ocurrió, qué puede inspeccionar el jugador, qué hechos se pueden relacionar y cuándo puede cerrarse el caso. Empieza con un caso fijo y vincula la conclusión a las pruebas. El pequeño misterio del museo es un diseño ficticio en papel: su recorrido de reglas se resuelve a mano y no se afirma que se haya ejecutado un prompt, creado un prototipo jugable o realizado una prueba.

Vincula la conclusión con las pruebas

Un primer caso justo ofrece hechos observables que respaldan una respuesta concreta. Antes de escribir diálogos o sospechosos ramificados, decide qué ocurrió y haz que cada pista revele parte de la verdad. Indica qué aporta una inspección, qué pares de pistas cuentan como conexiones, qué desbloquean y qué sucede tras una respuesta incorrecta.

Así se evita esconder el juego dentro de una petición vaga como «haz que el misterio sea ingenioso». Un buen encargo se comprueba paso a paso: ¿puede el jugador encontrar cada pista, relacionar los hechos correctos, entender por qué se deduce la respuesta y recuperarse de una elección equivocada?

Escribe la verdad antes que las pistas

Para el primer caso, determina la verdad antes de redactar las pruebas. En The Label in the Drying Room, falta una etiqueta de latón con una muesca en forma de creciente de la vitrina de la galería a las 16:20. Una restauradora la trasladó a un soporte acolchado de secado en el estudio a las 16:02, antes de que empezara una gotera en el tejado a las 16:05, y olvidó actualizar su ubicación. La etiqueta está a salvo; no hubo robo ni acto malicioso.

El mapa tiene tres salas —Galería, Vestíbulo central y Estudio de restauración—, todas visibles desde el inicio. Encontrar pruebas no crea ni revela salas. Mantener fijo el mapa convierte el reto en conectar pistas, no en generar un mapa.

La imagen ilustra un estado del juego propuesto. No muestra una interfaz de SEELE ni un prototipo observado. Los cuatro objetos de prueba son el contorno vacío de la vitrina, un aviso de gotera, la tarjeta de trabajo de la restauradora y el soporte acolchado con la etiqueta de la muesca coincidente.

Define las pistas, conexiones y condición para concluir

Usa un único contrato de estado para todo el caso. Cada pista entra una vez en el cuaderno; revisarla de nuevo no aumenta el progreso. Una conexión cuenta solo si ambas pistas respaldan la relación indicada. La tarjeta de trabajo y el aviso de gotera establecen el orden de los hechos; la tarjeta y la pista del soporte demuestran que el mismo objeto llegó al destino.

Las dos conexiones responden preguntas distintas. El par tarjeta/gotera demuestra que el traslado ocurrió antes de la filtración. El par tarjeta/soporte identifica la muesca creciente y establece dónde está esa misma etiqueta. Se permite seleccionar en orden inverso, pero un par irrelevante o una conexión repetida nunca aumenta el contador.

Usa una secuencia de tres prompts

Separa la comprobación de reglas de la solicitud de construcción. Primero pide un informe de ambigüedades; después entrega un contrato pequeño de implementación y reserva el tercer prompt para una observación concreta cuando exista un prototipo real. Así la herramienta tiene menos margen para inventar mecánicas y tú cuentas con un estándar claro para revisar la respuesta.

Prompt 1: comprueba el contrato del caso

Diseña un juego detectivesco determinista de apuntar y hacer clic llamado The Label in the Drying Room.
El jugador investiga un caso ficticio en un museo con un mapa fijo y visible: Galería,
Vestíbulo central y Estudio de restauración. Todas las salas están visibles desde el inicio.

Verdad: una restauradora trasladó una etiqueta de exposición de latón con muesca creciente
desde la vitrina de la galería hasta un soporte acolchado de secado en el estudio a las 16:02.
Una gotera en el tejado comenzó a las 16:05. La etiqueta está a salvo en el soporte; la restauradora
olvidó actualizar su ubicación. No hubo robo ni acto malicioso.

Pruebas: (1) soporte vacío en la galería; (2) aviso que indica que la gotera comenzó a las 16:05;
(3) tarjeta de trabajo que indica que la restauradora trasladó la etiqueta con muesca al soporte
del estudio a las 16:02; (4) la misma etiqueta con muesca, apoyada en el soporte acolchado.
Estado inicial: cluesFound=0/4 y linksSolved=0/2. Cada pista cuenta una sola vez.
El par tarjeta/aviso registra una conexión temporal. El par tarjeta/soporte registra una conexión
de identidad y destino. Ambas deben existir para abrir exactamente tres conclusiones: (1) un
visitante retiró la etiqueta; (2) la etiqueta sigue en la galería; (3) la restauradora la trasladó
al soporte a las 16:02, antes de la gotera. Solo la opción 3 es correcta. Las opciones 1 y 2 dejan
el caso abierto y muestran una pista neutral. Reiniciar borra pistas, conexiones y respuesta, pero
conserva el mapa fijo y el texto del caso. No inventes más opciones.

Devuelve una tabla de reglas, el texto exacto de las pistas, las transiciones de estado, las
conclusiones y una lista de ambigüedades. No añadas salas, sospechosos, sucesos aleatorios,
temporizadores, puntuaciones ni pistas ocultas. Si una pista no respalda la respuesta, señala
la laguna en vez de rellenarla.

Lee la hoja de reglas antes de solicitar una primera versión jugable. Comprueba que la muesca identifique el mismo objeto en la tarjeta y en la pista del soporte, que las 16:02 precedan a las 16:05 y que la conclusión siga bloqueada hasta establecer ambas conexiones únicas. Si la respuesta introduce otra cronología o una cuarta sala, resuelve el conflicto antes de construir.

Prompt 2: solicita el primer caso mínimo

Construye un pequeño misterio detectivesco de museo en primera persona y de apuntar y hacer clic según el contrato aprobado.
Muestra el mapa fijo de tres salas, una acción de inspección con lupa, un cuaderno de cuatro pistas
y un tablero de pruebas para conectar los pares exactos. Usa una interfaz sobria solo con iconos.

Al inicio, muestra 0/4 pistas y 0/2 conexiones. Inspeccionar cada uno de los cuatro objetos
añade una pista una sola vez. Conectar la tarjeta de trabajo con el aviso de gotera establece
linksSolved en 1/2. Conectar la tarjeta con la pista coincidente del soporte establece 2/2 y
abre exactamente tres conclusiones: (1) un visitante retiró la etiqueta; (2) sigue en la galería;
(3) la restauradora la trasladó al soporte a las 16:02, antes de la gotera. Solo la opción 3 cierra
el caso. Las opciones 1 y 2 muestran una pista neutral de revisión sin perder pruebas. Reiniciar
vuelve a 0/4 y 0/2 y conserva el mapa fijo. No añadas otras opciones.

No añadas elecciones de diálogo, mapas que se construyan al descubrirlos, campañas, puntuación,
temporizadores, combate, pruebas aleatorias, robos ni animaciones de acusación. Haz visibles el
objeto inspeccionado, la respuesta al conectar pistas, el tablero de conclusiones bloqueado o abierto
y el resultado del reinicio. No afirmes ni simules una interfaz real de producto.

Esta solicitud define la acción del jugador, los objetos, los cambios de estado, las respuestas esperadas y las exclusiones. Pide un misterio inspeccionable, no solo un museo con ambiente. Si el resultado muestra la etiqueta pero no permite inspeccionar ni conectar pruebas, no cumple el contrato de interacción propuesto.

Resuelve el caso a mano y planifica las comprobaciones

Antes de confiar en un resultado generado, recorre las reglas escritas a mano. Las cuentas son simples, pero permiten detectar un error frecuente de diseño: desbloquear la respuesta antes de encontrar las pruebas decisivas. Esta ruta se calcula a partir de reglas ficticias; no es una ejecución de software.

El mapa inicial y el soporte vacío establecen la desaparición; la hora y la gotera determinan el orden; la muesca vincula la tarjeta de trabajo con el objeto del soporte. Por tanto, la conclusión deriva de pistas visibles, no de una suposición sobre un sospechoso oculto ni de una revelación del narrador.

Usa una lista breve de aceptación cuando exista un prototipo jugable real. El comportamiento esperado no es el observado: registra por separado las acciones y los resultados reales y revisa solo después de poder reproducir una discrepancia.

Revisa a partir de una observación

Cuando exista un prototipo real, no pidas una revisión general como «mejora el misterio». Registra una acción reproducible, el estado esperado y el observado. Después solicita la corrección mínima que resuelva la discrepancia sin cambiar reglas de pistas no relacionadas.

Acción observada: [una acción exacta de inspección, conexión, respuesta o reinicio]
Estado inicial: [cluesFound y linksSolved]
Estado esperado: [lo que indica el contrato de reglas aprobado]
Estado observado: [lo que mostró realmente el prototipo]
Cambio solicitado: Corrige solo la regla o respuesta responsable de esta discrepancia.
Conserva: el mapa fijo de tres salas, la identidad de la muesca creciente, la cronología 16:02/16:05,
la otra conexión válida, la recuperación tras una respuesta incorrecta y el comportamiento del reinicio.
Devuelve: la regla cambiada, el estado correspondiente antes y después y una comprobación para este caso.
No afirmes que el cambio funciona hasta repetir y observar la misma acción.

Sin prototipo ni observación reproducible, esto sigue siendo una plantilla. El recorrido manual puede mostrar si el diseño es coherente, pero no demuestra que una interacción generada lo siga ni que los jugadores entiendan la interfaz.

Lleva el encargo a un espacio de creación

La página actual de Free AI Game Maker de SEELE describe cómo redactar una idea en inglés sencillo, revisar un resultado jugable en 2D o 3D e iterar en Workspace. Es un flujo general de creación y revisión, no una garantía de que se implementen el cuaderno de pistas, las conexiones de pruebas o la condición para concluir de este ejemplo. Usa el contrato como entrada, compara la interacción real con la ruta de estados y revisa el modelo seleccionado, el saldo disponible de Koin y el coste mostrado antes de generar.

Si faltan la inspección, las dos respuestas distintas al conectar pistas, el tablero bloqueado o el reinicio, solicita directamente ese estado. Si la herramienta no puede representar una regla, conserva el contrato como especificación de diseño y decide qué simplificar. No tomes una maqueta visual ni una escena plausible como prueba de lógica jugable.

Empieza con un caso justo

Fija la verdad, define cuatro pistas observables, exige dos conexiones únicas y abre las conclusiones solo cuando respalden una respuesta. Usa la ruta resuelta a mano para comprobar el diseño y compárala con un prototipo real antes de decir que algo se probó. Cuando quieras desarrollar una idea pequeña e inspeccionar el resultado, abre la página Free AI game maker y lleva un encargo concreto. Revisa el resultado real y corrige una discrepancia cada vez.