¿Qué puede saber realmente el asistente de IA de un personaje desaparecido en un juego de misterio?

Separa los registros de la historia del acceso del asistente

Comienza con un registro completo de la historia destinado al autor: acontecimientos, declaraciones de personajes, objetos, mensajes y el orden en que entran en juego. Luego, define una vista más reducida para el asistente. Un dato puede existir en la biblia de la historia sin estar disponible todavía para el asistente. Esa distinción es la base de un misterio justo: el autor puede saber qué ocurrió, mientras que el asistente solo puede usar los registros que su rol ficticio le permite ver.

Las herramientas de ficción interactiva como Twine organizan las historias en pasajes y pueden usar variables y lógica condicional para cambiar lo que ve el jugador. Eso proporciona una analogía de diseño útil: trata cada registro creado por el autor como una unidad discreta y haz que el acceso a él dependa del pasaje, acontecimiento o elección relevante. Twine’s basic concepts

Por ejemplo, supongamos que un personaje ficticio llamado Mara está preparando una exposición para el huerto comunitario. El asistente podría tener acceso a una nota de planificación que ella compartió, a un cronograma publicado en el panel del grupo y a un mensaje posterior que ella envía sobre guardar los carteles pintados bajo techo. No debería deducir dónde está Mara simplemente por saber que le gusta la jardinería, y no debería ver un borrador privado que nunca se compartió con él. Esos límites provienen de las reglas de acceso creadas para la historia, no de una afirmación sobre a qué pueden acceder los sistemas de IA reales.

Asigna a cada dato una fuente y un momento en que se conoció

Un registro de datos útil responde al menos a cuatro preguntas: qué se afirma, quién o qué lo aportó, cuándo estuvo disponible para el asistente y si es directo o deducido. El modelo de procedencia del W3C describe los orígenes de la información en términos de entidades, actividades y agentes; también permite que los registros describan cómo se derivó un elemento de otro. Es un marco práctico para los registros de ficción, incluso si un juego utiliza etiquetas simples en lugar del modelo formal. W3C PROV Model Primer

Un registro compacto podría verse así:

Afirmación: Mara planeaba pintar los carteles del huerto; Fuente: Nota de planificación compartida; Conocido por el asistente desde: Lunes, 10:00; Tipo: Declaración directa

Afirmación: Los carteles se guardaron bajo techo; Fuente: Actualización en el panel del grupo; Conocido por el asistente desde: Martes, 16:30; Tipo: Actualización directa

Afirmación: Puede que Mara los haya guardado porque se pronosticaba lluvia; Fuente: Nota meteorológica más actualización; Conocido por el asistente desde: Martes, 16:30; Tipo: Deducción; sin confirmar

Las horas del ejemplo son ilustrativas. La distinción importante radica entre el momento en que ocurrió un acontecimiento y el momento en que el asistente se enteró de él. Si una nota creada el lunes se comparte el martes, el conocimiento del asistente comienza el martes, a menos que la historia le otorgue explícitamente un acceso anterior. Conserva ambas marcas de tiempo cuando difieran.

Mantén diferenciadas la observación, el informe y la deducción

Una fuente no convierte automáticamente su contenido en una certeza. Un personaje puede describir lo que vio; una nota puede estar incompleta; un cronograma puede registrar un plan en lugar de una acción que realmente ocurrió. Etiquetar el tipo de registro ayuda al asistente a formular su respuesta con precisión: «El panel dice que se guardaron los carteles» es diferente de «Mara guardó los carteles», y ambas difieren de «Probablemente los guardó debido al clima».

Utiliza un vocabulario reducido de manera coherente: observación directa, informe de personaje, registro de autor y deducción. Una deducción debe remitir a sus registros de respaldo y mantenerse marcada como deducción. W3C PROV modela explícitamente la responsabilidad de los agentes sobre las actividades y la derivación de una entidad a partir de otra; aplicar esa distinción a los diálogos ayuda a que el juego muestre de dónde surgió una conclusión en lugar de presentarla como un hecho nuevo. W3C PROV-O

Esto también crea una prueba útil para el autor: ¿puede un jugador rastrear una afirmación segura del asistente hasta un registro al que se le permitió acceder? Si no es así, corrige la respuesta, añade el registro de autor que falta o haz que el asistente diga que no tiene suficiente información.

Define el acceso en el tiempo de la historia, no solo por personaje

Para cada registro, especifica el acontecimiento que desbloquea el acceso del asistente. Un mensaje compartido podría estar disponible en cuanto se envía; un aviso fijado en un panel podría estar disponible cuando el asistente revisa el panel; una conversación podría estar disponible solo después de que el jugador decida preguntar por ella. Evita depender de etiquetas imprecisas como «el asistente sabe todo lo que hay en el archivo», a menos que la historia establezca qué contiene ese archivo y cuándo se actualiza.

Una regla de acceso práctica tiene tres partes: la audiencia del registro, su desencadenante de disponibilidad y cualquier retraso. Por ejemplo: «El asistente puede leer las publicaciones del panel del grupo después de que el jugador abra el panel; no puede leer borradores personales». El retraso es importante en historias ramificadas. Si un jugador no ha visitado el panel, el asistente no debería comportarse como si hubiera visto la última publicación solo porque esa publicación existe en otra parte de los archivos del autor.

En Twine, las variables de historia pueden estar disponibles a través de los pasajes, mientras que las variables temporales se limitan al pasaje actual en Harlowe y SugarCube. Esa diferencia ilustra por qué los autores deben decidir deliberadamente si un dato persiste a lo largo de toda la historia o pertenece únicamente a una escena concreta. La implementación exacta depende del formato de la historia, así que toma la regla como un modelo de diseño y no como instrucciones de código. Twine Cookbook: Variables

Haz que la incertidumbre sea útil para el jugador

Cuando un registro falta, es antiguo o resulta ambiguo, deja que el asistente describa ese vacío en términos concretos. Puede decir que tiene el plan del lunes pero ninguna confirmación posterior, o que un personaje informó haber guardado los carteles mientras que el panel no contiene ninguna actualización. Esto le da al jugador un siguiente paso significativo: consultar otra fuente creada por el autor, retomar una conversación con un personaje o asumir que la pista sigue sin resolverse.

Ese enfoque favorece el misterio sin recurrir a una omnisciencia arbitraria. Las investigaciones sobre narrativa interactiva han examinado cómo el conocimiento limitado puede moldear el comportamiento del jugador, incluyendo un estudio que utilizó la ficción interactiva *Anchorhead* para explorar modelos de jugador. Para un asistente diseñado por un autor, la implicación de diseño es modesta: lo que el jugador y el asistente han aprendido puede afectar a sus siguientes elecciones, por lo que conviene registrar esos estados de conocimiento de manera explícita. Rivera-Villicana et al., “Informing a BDI Player Model for an Interactive Narrative”

Una revisión rápida antes de escribir los diálogos del asistente

Antes de redactar una respuesta, verifica estos puntos para cada afirmación importante:

¿Está la afirmación presente en un registro de autor, o está etiquetada como una deducción?

¿Indica el registro su fuente y distingue entre un plan, un informe, una observación o una confirmación posterior?

¿En qué momento de la historia obtuvo el asistente acceso a ella?

¿Permite el rol ficticio del asistente el acceso a esa fuente?

Si el registro está incompleto o resulta contradictorio, ¿preserva el diálogo esa incertidumbre?

Si la respuesta a cualquiera de estas preguntas no está clara, delimita la afirmación del asistente hasta que coincida con el registro disponible. El personaje resultante seguirá siendo útil: podrá resumir lo que ha visto, señalar lo que sigue sin confirmarse y orientar al jugador hacia la siguiente pista creada por el autor. Su fiabilidad proviene de un límite visible entre el registro completo de la historia y la información que realmente ha recibido.

Sigue explorando este tema