El diálogo es un problema de estado y presentación

740. Identidad de la lección

Módulo

2.8 — Narrativa interactiva

Lección

El diálogo es un problema de estado y presentación

Tipo académico

Sistemas

Orden

Lección 1 del módulo

Tiempo estimado

30–40 minutos, incluida la práctica

Esta lección separa el contenido narrativo, las opciones disponibles, los modos de presentación y las consecuencias. El resultado evaluado será un diagrama de estados de diálogo acompañado de una tabla de transiciones o una descripción estructurada equivalente. Otra persona —o un asistente de programación con IA— debe poder implementarlo sin adivinar reglas ausentes.

741. Objetivo de aprendizaje

Después de esta lección, podrás elaborar una especificación de diálogo que coordine las transiciones narrativas con los modos de presentación e identifique condiciones, consecuencias, destinos y autoridad entre sistemas.

742. Por qué importa

Una conversación no es solo una secuencia de frases. También determina qué contenido está activo, qué puede elegir el jugador, qué modo de interacción está disponible y qué solicitudes o eventos siguen a cada elección. Si estas responsabilidades se condensan en un único guion o una sola pantalla, un cambio de texto puede alterar la progresión, la interfaz puede convertirse por accidente en la fuente de verdad del mundo o el juego puede conservar un modo de entrada incorrecto al cerrar el diálogo.

Separar las responsabilidades permite seguir el comportamiento y establece límites claros para la implementación.

743. Conocimientos previos

Debes poder identificar la autoridad de cada sistema y los límites entre eventos, como se trabajó en el módulo 2.7. En particular, distingue entre un sistema que solicita o anuncia un cambio y el sistema autorizado que valida y registra el hecho resultante.

744. Cuatro responsabilidades, dos recorridos coordinados

El diseño de un diálogo debe contemplar cuatro responsabilidades:

1. Contenido narrativo: Frases, personaje que habla, tono y texto asociados a un estado de diálogo.
2. Opciones de diálogo: Opciones seleccionables y condiciones que determinan si están disponibles.
3. Modo de presentación: Estado de la interfaz y de la entrada, como exploración, presentación del diálogo, selección de opciones o cierre.
4. Consecuencias: Solicitudes, eventos o cambios confirmados asociados a una opción seleccionada.

Estas responsabilidades no forman una secuencia única en la que la presentación aparezca al final. Represéntalas mediante dos recorridos coordinados.

Recorrido A: transición del diálogo

estado de diálogo actual
  -> determinar las opciones válidas
  -> el jugador selecciona una opción válida
  -> solicitar o emitir la consecuencia indicada
  -> aplicar la política de finalización declarada
  -> entrar en el siguiente estado, en un estado de fallo o salir

Recorrido B: modo de presentación

exploración
  -> presentación del diálogo
  -> selección de opciones
  -> presentación de respuesta o cierre
  -> exploración

Los recorridos se sincronizan en puntos explícitos:

El estado narrativo y el modo de presentación se coordinan, pero no son lo mismo. Un mismo estado narrativo puede presentarse primero como texto y después como selección de opciones. Del mismo modo, el modo de cierre puede seguir activo mientras el sistema de diálogo termina su transición de salida.

745. Autoridad y política de finalización de consecuencias

El sistema de diálogo controla las transiciones de la conversación. Puede emitir un evento o enviar una solicitud, pero el sistema de dominio correspondiente sigue siendo la fuente autorizada de los hechos persistentes del mundo. La interfaz presenta el estado actual y recibe la entrada; no crea la verdad del mundo.

El diagrama debe indicar qué significa completar cada transición que tenga una consecuencia. Elige una de estas políticas en vez de dar por hecho que todas las consecuencias terminan de forma síncrona:

• Avanzar después de emitir: El diálogo avanza en cuanto emite una notificación cuyo procesamiento posterior no afecta al recorrido de la conversación.
• Esperar confirmación autorizada: El diálogo queda pendiente hasta que el sistema receptor confirma que el cambio solicitado fue aceptado.
• Seguir rutas explícitas de éxito y fallo: El sistema receptor puede aceptar o rechazar la solicitud, y el diálogo indica un destino para cada resultado.

Un evento emitido, una solicitud y un cambio confirmado no tienen la misma semántica de finalización. En esta lección debes indicar la política; en la Lección 2 definirás el contrato detallado de la consecuencia y los sistemas receptores.

746. Ejemplo concreto

Considera una conversación inventada entre el jugador y una trabajadora del muelle llamada Mara. Es solo un ejemplo de sistemas y no representa un hecho documentado de ningún proyecto.

En este ejemplo, route_discussed utiliza la política esperar confirmación autorizada.

Recorrido de transición del diálogo

estado: saludo
  contenido: Mara pregunta si el jugador tiene una duda sobre una entrega
  opciones válidas:
    preguntar_por_la_ruta
      condición: heard_rumor = true
      consecuencia: solicitar route_discussed
      política: esperar confirmación autorizada
      destino si tiene éxito: respuesta_sobre_la_ruta
      destino si falla: saludo_con_aviso
    terminar_conversación
      condición: siempre
      consecuencia: ninguna
      destino: salida

estado: respuesta_sobre_la_ruta
  contenido: Mara ofrece una respuesta cautelosa
  opción válida:
    aceptar_respuesta
      condición: siempre
      consecuencia: emitir conversation_completed
      política: avanzar después de emitir
      destino: salida

Recorrido del modo de presentación

exploración
  -> presentación del diálogo: saludo
  -> selección de opciones
  -> respuesta pendiente mientras se evalúa route_discussed
  -> presentación de respuesta O selección con aviso de fallo
  -> cierre
  -> exploración

Tabla de transiciones equivalente

El diagrama no permite que la interfaz decida si se habló de la ruta. El sistema de diálogo envía la solicitud declarada y el sistema autorizado correspondiente la acepta o rechaza. La política de transición determina si el diálogo avanza de inmediato, espera o sigue una ruta de fallo.

747. Opciones no disponibles y presentación accesible

Si heard_rumor es falso, la opción sobre la ruta puede ocultarse o mostrarse desactivada, según una decisión explícita de diseño. Si permanece visible pero desactivada:

• su estado no disponible debe poder percibirse sin depender únicamente del color;
• debe identificarse con claridad como no disponible;
• conviene explicar el motivo cuando esa información favorezca la experiencia prevista;
• la navegación debe funcionar sin depender exclusivamente de un puntero;
• los controles no disponibles no deben romper un orden de foco lógico; y
• al cerrar el diálogo, el foco y la entrada deben volver de forma predecible a un objetivo adecuado de la exploración.

Todo diagrama visual debe incluir una tabla de transiciones o una lista estructurada con los mismos estados, condiciones, consecuencias, destinos, modos de presentación y datos de autoridad.

748. Errores comunes

Tratar la presentación como el último paso

La presentación interviene durante la entrada, la visualización del texto, la selección de opciones, la respuesta y el cierre. No es una capa final que se aplica únicamente después de una consecuencia.

Combinar una frase, una pantalla y un cambio del mundo

Una instrucción como «mostrar la respuesta sobre la ruta y desbloquear la misión» no aclara el momento del cambio, la autoridad, el comportamiento ante fallos ni el siguiente modo de entrada.

Suponer que emitir equivale a completar

Emitir una notificación puede permitir un avance inmediato. Enviar una solicitud que puede fallar quizá requiera confirmación y una ruta de fallo. La especificación debe indicar qué política se aplica.

Dar autoridad a la interfaz

El panel puede mostrar una opción, pero no debe convertirse en la fuente autorizada de los hechos relacionados con misiones, inventario, relaciones o progresión.

749. Práctica guiada

Especifica este escenario:

El jugador habla con un intendente. El intendente ofrece un saludo. El jugador puede preguntar por los suministros o marcharse. La opción de suministros solo está disponible cuando supply_token = true. Al seleccionarla, el diálogo envía una solicitud record_supplies_discussed. El sistema de dominio autorizado puede aceptar o rechazarla. Si la acepta, la conversación pasa a un estado de respuesta. Si la rechaza, vuelve a la selección de opciones con un aviso. El estado de respuesta ofrece una opción para terminar que emite conversation_completed. Marcharse o terminar cierra el diálogo y restaura la exploración.

Crea estos dos elementos:

1. un diagrama de dos recorridos que muestre las transiciones del diálogo y los modos de presentación; y
2. una tabla de transiciones o una descripción estructurada equivalente.

La especificación debe incluir:

• todos los recorridos desde la entrada hasta la salida;
• el contenido de cada estado de diálogo;
• cada opción de diálogo y su condición;
• un destino para cada resultado posible;
• cada consecuencia y su política de finalización;
• el sistema autorizado responsable de registrar supplies_discussed;
• los modos de presentación antes, durante y después del diálogo;
• los puntos de sincronización entre ambos recorridos; y
• la restauración predecible de la entrada y el foco al salir.

Decide si la opción de suministros no disponible se oculta o se muestra desactivada. Justifica la decisión en una frase. Si se muestra desactivada, especifica cómo se comunica ese estado y cómo funciona la navegación sin puntero.

750. Validación y evidencia evaluada

751. Ideas clave

• Las transiciones del diálogo y los modos de presentación son recorridos distintos que se sincronizan en puntos declarados.
• Cada opción necesita una condición, una consecuencia, un destino y una política de finalización explícitos.
• Los eventos emitidos, las solicitudes y los cambios confirmados no tienen la misma semántica de finalización.
• El sistema de diálogo controla el flujo de la conversación; el sistema de dominio correspondiente es la fuente autorizada de los hechos persistentes.
• Una tabla de transiciones permite revisar el diagrama sin depender de su disposición visual.

752. Siguiente lección

Continúa con 2.8 L2 — Diseñar elecciones sin escrituras globales ocultas. Convertirás una opción en un contrato explícito de consecuencias que identifique solicitudes o eventos emitidos, escrituras autorizadas, comportamiento ante fallos y sistemas receptores.

753. Comprobación