Cómo evitar que los diálogos de personajes con IA inventen pistas en juegos de misterio
Si un personaje con IA puede hablar sobre pistas, haz que cada afirmación procesable dependa de una fuente creada por el autor y de un estado de descubrimiento controlado por el juego. Proporciona al modelo únicamente las pruebas que el jugador haya encontrado, exige que identifique la fuente detrás de cualquier afirmación que parezca una pista y trata los detalles sin respaldo como no disponibles. Mantén las bromas y la ambientación en un canal separado de matiz («flavor») que no pueda actualizar el registro del caso ni desbloquear avances. Esto permite que los personajes hablen con flexibilidad sin que el diálogo improvisado reescriba el misterio.
Por qué las pistas inventadas arruinan un misterio
En un juego de misterio, los jugadores recopilan información, sacan conclusiones y usan lo que aprenden para buscar más información. Eso hace que la relación entre la pista y el conocimiento del jugador forme parte del bucle central del juego, en lugar de ser un simple detalle del estilo de diálogo. Un personaje que menciona con total seguridad una carta no ubicada o nombra a una persona que el jugador nunca ha encontrado puede crear accidentalmente una nueva pista. El jugador no tiene una forma fiable de saber si ese detalle es una pista deliberada, una mentira intencionada o relleno generado. El artículo «Generative Forensics: Procedural Generation and Information Games» describe los juegos de información en términos de reunir conocimientos y utilizarlos para comprender un misterio; aplicando ese marco, las afirmaciones generadas sin seguimiento pueden enturbiar el conocimiento a partir del cual se supone que el jugador debe razonar.
La solución comienza con una distinción clara: una pista es un hecho del juego sobre el que el jugador puede actuar; el matiz o ambientación («flavor») es un diálogo expresivo que no añade ni cambia hechos del juego. Un personaje puede sonar inseguro, evasivo, divertido o vívido, pero una línea no debería convertirse en prueba solo porque esté formulada de manera convincente.
Crea un registro de pistas de autor antes de generar el diálogo
Mantén un registro pequeño y explícito para cada pista procesable. Puede residir en una base de datos, un archivo de contenido o una herramienta narrativa; la clave es que el modelo no invente su contenido. Incluye campos que respondan a qué dice la pista, de dónde provino, quién puede conocerla y cuándo pasa a estar disponible.
Campo: clue_id; Lo que registra: Identificador estable para la prueba; Ejemplo (ilustrativo): note_blue_01
Campo: canonical_fact; Lo que registra: El hecho que establece el juego; Ejemplo (ilustrativo): “La nota está firmada con la inicial M.”
Campo: source_id; Lo que registra: Objeto, escena o línea creada por el autor que la respalda; Ejemplo (ilustrativo): archive_note_03
Campo: discovery_condition; Lo que registra: Estado del juego requerido antes de poder hablar de ella; Ejemplo (ilustrativo): found_archive_note_03
Campo: allowed_speakers; Lo que registra: Personajes autorizados a conocerla o hablar de ella; Ejemplo (ilustrativo): Mara, Ivo
Campo: certainty; Lo que registra: Si la fuente afirma un hecho o sugiere una interpretación; Ejemplo (ilustrativo): explicit
Campo: player_facing_label; Lo que registra: Cómo aparece la prueba en el diario, si corresponde; Ejemplo (ilustrativo): “Nota sin firmar”
Los nombres y valores anteriores son un ejemplo ficticio para mostrar un formato, no una afirmación sobre ningún juego en particular. Observa que el registro separa el contenido explícito de una fuente de una interpretación: una inicial en una firma no determina por sí misma quién escribió una nota. Esa distinción da margen al sistema de diálogo para que un personaje especule sin presentar la especulación como una prueba recién verificada.
Condiciona las pistas por el estado de descubrimiento, no solo por la conversación
Representa el descubrimiento como un estado propio del juego. Por ejemplo, found_archive_note_03 pasa a ser verdadero solo cuando el jugador encuentra la nota realmente. Al inicio de una conversación, pasa al personaje una lista de los hechos creados por el autor que tiene permitido discutir, filtrados por el estado de descubrimiento del jugador y el conocimiento del personaje. Una pista solo está disponible cuando se superan ambas comprobaciones: el jugador ha alcanzado su condición de descubrimiento y el interlocutor está autorizado a conocerla.
Esta es una aplicación práctica de la generación aumentada por recuperación (RAG): recuperar registros relevantes, colocarlos en el contexto del modelo y generar a partir de ellos. La descripción general de RAG de Microsoft describe ese flujo de recuperar-aumentar-generar y advierte que una recuperación deficiente o incompleta aún puede generar resultados inexactos. En un juego, la recuperación debe respetar las condiciones de descubrimiento antes de llegar al modelo. Decirle al modelo «no hagas spoilers» es más débil que retener por completo las pruebas aún no descubiertas.
Mantén la comprobación de permisos fuera del modelo siempre que sea posible. El juego, y no una línea de texto generada, es el que debe determinar si una prueba entra en un diario, resuelve un rompecabezas o desbloquea una interacción. Un modelo puede redactar un hecho autorizado; el estado del juego debe decidir en primer lugar si el hecho está autorizado.
Dale al modelo un contrato estricto y una respuesta alternativa segura
Un prompt útil debe especificar la voz del personaje, la escena actual, los registros de pistas permitidos y la diferencia entre pruebas y matiz decorativo. Establece qué hacer cuando una pregunta exceda las pruebas suministradas: negarse a confirmarla, decir que el personaje no lo sabe o responder con una línea no procesable que mantenga la personalidad del personaje. Incluye también instrucciones para registros contradictorios o ambiguos. La guía de ingeniería de prompts para RAG de Microsoft recomienda límites explícitos de fundamentación, comportamientos alternativos (fallbacks), identificadores de fuentes e instrucciones para conflictos. Estos son principios de diseño útiles tanto para el diálogo controlado de personajes como para asistentes de información.
Por ejemplo, si el jugador pregunta si la inicial M demuestra que Mara escribió la nota, la respuesta permitida podría decir: «La M está ahí, pero eso solo no nos dice quién la firmó». El sistema puede permitir esa redacción porque preserva la diferencia entre el hecho de la fuente y una conclusión. No debería improvisar un testigo, una coincidencia caligráfica o un segundo documento para que la respuesta sea más satisfactoria.
Haz que el modelo devuelva campos estructurados como spoken_text, claim_type y source_ids. Para una respuesta que contenga pistas, exige al menos un identificador de fuente válido y comprueba ese identificador con respecto a los registros suministrados para ese turno. En el caso del texto de ambientación, marca la respuesta como no probatoria y no permitas que active indicadores de pistas. El resultado estructurado no es una garantía de que el texto sea verídico; crea algo que el juego puede comprobar antes de mostrarlo o de cambiar el estado.
Etiqueta el contenido ambiental para que los jugadores reconozcan su valor
El texto de ambientación («flavor») puede incluir el estado de ánimo de un personaje, una broma inocente o una reacción inespecífica a la habitación. No debe introducir de forma encubierta una fecha, ubicación, objeto, testigo con nombre, motivo u otro detalle que los jugadores puedan considerar razonablemente como una pista. Si deseas que haya charlas especulativas, haz que la incertidumbre quede clara en la redacción y mantenla al margen de los sistemas objetivos, como la lista de pruebas, el estado de las misiones y las interacciones basadas en pistas.
La distinción puede reflejarse tanto en los datos como en la presentación. A nivel interno, etiqueta las líneas como prueba, interpretación o ambientación; en la interfaz, reserva el estilo visual de pruebas o las entradas del diario para las pistas creadas por los autores del juego. Un personaje puede decir: «Tal vez dejaron la nota con prisa», pero a menos que el juego haya establecido esa posibilidad como una interpretación permitida, no debería aparecer como una pista confirmada ni desencadenar una nueva ramificación. Este etiquetado triple es una recomendación de diseño que surge de la necesidad de preservar lo que dice la fuente, lo que alguien infiere y lo que es un diálogo meramente expresivo.
Usa herramientas narrativas para rastrear estados y condiciones
No necesitas un motor específico para aplicar este enfoque. Las herramientas de narrativa interactiva suelen admitir pasajes o secciones, variables y contenido condicional. La documentación oficial de redacción de Ink describe variables y lógica condicional para controlar el contenido de la historia; la guía de pasajes del Twine Cookbook explica los pasajes como secciones de contenido que también pueden contener código que afecta la forma en que el texto aparece o responde. Estas funciones pueden representar el estado de descubrimiento, el conocimiento del hablante y el diálogo condicional, tanto si el diálogo es generado como si está escrito por un autor.
Mantén los identificadores de pistas y los nombres de los estados de forma coherente en todo el registro narrativo y la lógica del juego. Una variable como found_archive_note_03 es más fácil de auditar que un indicador ambiguo como clue2, especialmente cuando diferentes escenas la leen o modifican. Añade un enlace rastreable desde cada línea procesable generada hacia su registro de origen permitido; si una línea no tiene una fuente válida, el entorno de ejecución puede rechazarla o solicitar una respuesta alternativa segura en lugar de tratarla como prueba.
Comprueba los límites con pruebas de juego específicas
Prueba las conversaciones en los límites del descubrimiento, donde es más probable que fallen las reglas de estado. Inicia una nueva conversación antes de encontrar la pista, inmediatamente después de encontrarla y después de que hable un personaje con un conocimiento diferente. Haz preguntas directas sobre pruebas no descubiertas, formula una pregunta que la fuente solo responda en parte y repite la escena si el juego lo permite. Compara la línea mostrada, los ID de fuente devueltos y cualquier cambio en el diario o en el estado de la historia.
Una lista de control compacta ayuda a mantener esas comprobaciones de forma concreta:
Cada afirmación procesable se corresponde con una pista creada por el autor o con una interpretación explícitamente permitida.
La condición de descubrimiento de la pista es verdadera antes de que aparezca como conocimiento disponible.
El interlocutor tiene permiso para conocer la información en esa escena.
Las preguntas sin respaldo reciben la respuesta alternativa predeterminada en lugar de un hecho específico nuevo.
Las líneas de ambientación no pueden añadir entradas al diario, satisfacer requisitos de pistas ni cambiar el estado de las pruebas.
Los registros ambiguos o contradictorios generan incertidumbre o una respuesta alternativa revisable, no una nueva resolución sin supervisión.
La fundamentación (grounding) reduce el margen para pistas inventadas, pero no garantiza que el texto generado siempre respete los hechos suministrados. La recuperación puede omitir un registro relevante y un modelo aún puede producir texto inexacto a pesar de la fundamentación, como señala Microsoft en su guía sobre limitaciones de RAG. Mantén la autoridad final sobre las pistas en los registros de autor y en la lógica del juego; utiliza la generación para dar voz a esos límites.
La regla práctica es simple: deja que el modelo elija las palabras, mientras que el misterio escrito por el autor y el estado actual del juego deciden qué se les permite establecer a esas palabras. Cuando cada pista procesable tiene una fuente, un control de descubrimiento y un estado claro, los personajes pueden sonar más naturales en sus conversaciones sin ofrecer a los jugadores pruebas que el juego nunca incluyó.