Coordinar objetivos entre sistemas

727. Identidad de la lección

Módulo

2.7 — Misiones

Lección

Coordinar objetivos entre sistemas

Tipo académico

Integración

Tipo de esquema

práctica

Orden

2 del módulo

Tiempo estimado

35–45 minutos, incluida la práctica

Esta lección presenta los contratos de eventos como puente entre los predicados de misión y los sistemas con autoridad. El sistema de misiones observa hechos producidos por los sistemas de combate, inventario, alarma y facciones; no reescribe sus estados.

728. Objetivo de aprendizaje

Al terminar esta lección, podrás dibujar un mapa de dependencias que ordene objetivos de misión mediante eventos de distintos sistemas, identifique rutas de interrupción y reversión, y marque objetivos opcionales sin transferir al sistema de misiones la propiedad de estados ajenos.

729. Por qué importa

Una misión rara vez avanza porque un único sistema posea todos los hechos relevantes. El combate puede informar que un objetivo fue derrotado, el inventario puede confirmar que un objeto fue depositado y un sistema de facciones puede comunicar un cambio de reputación. El sistema de misiones coordina esos hechos sin invadir la autoridad de los sistemas que los producen.

Los contratos claros también ofrecen a la IA un objetivo de análisis acotado. Puede ayudar a detectar predicados ambiguos, casos de fallo ausentes o dependencias sin etiquetar, pero no puede decidir por la persona responsable del diseño qué sistema tiene autoridad.

730. Conocimientos previos

Debes poder:

• Definir un objetivo de misión mediante predicados observables y fuentes de evidencia.
• Distinguir la evaluación de una misión de los sistemas que poseen el estado del combate, del inventario, de la alarma y de las facciones.

La lección anterior, Una misión es un conjunto de predicados, proporciona la base para elegir evidencia en lugar de depender de una bandera ambigua como missionFeelsComplete. Esta lección introduce el vocabulario de contratos de eventos necesario para conectar esos predicados con evidencia procedente de otros sistemas.

731. Concepto central

Una misión coordina sistemas mediante eventos y predicados, no mediante la propiedad directa de sus estados.

Un contrato de evento responde cinco preguntas:

1. ¿Qué ocurrió? Usa un nombre estable como target_defeated o item_deposited.
2. ¿Quién tiene autoridad? Identifica al productor que posee ese hecho.
3. ¿Qué evidencia transporta? Incluye solo los datos necesarios para evaluar los objetivos, como target_id, item_id, location_id o mission_context_id.
4. ¿Cuándo puede consumirlo la misión? Indica si el evento puede llegar antes, durante o después de que el objetivo esté activo.
5. ¿Qué sucede si el hecho cambia o queda invalidado? Define el comportamiento de interrupción, reversión o reevaluación.

El sistema de misiones puede registrar progreso derivado de esos eventos. No debe modificar directamente la salud de un enemigo, añadir un objeto al inventario, cambiar el estado de una alarma ni alterar la reputación de una facción solo para que un objetivo se cumpla.

Los objetivos opcionales requieren la misma disciplina contractual. Pueden contribuir a una rama, recompensa, puntuación o predicado posterior sin bloquear la ruta obligatoria. Marcar un objetivo como opcional es una regla de misión; no autoriza a debilitar los límites de autoridad.

732. Modelo mental

Usa la cadena productor → evento o contrato de consulta → predicado de misión → estado del objetivo.

Para representar la secuencia, muestra cada objetivo como un nodo y cada evento o consulta necesaria como una conexión. Añade rutas explícitas para:

• Interrupción: una condición suspende temporalmente el progreso o cambia el objetivo activo.
• Reversión: una evidencia autorizada posterior invalida progreso ya registrado.
• Rechazo: otro sistema deniega con autoridad una transición solicitada.
• Rama opcional: una ruta que puede cambiar el resultado, pero no bloquea la finalización obligatoria.

No es obligatorio usar un diagrama visual. Puedes entregar una tabla equivalente de nodos y conexiones con estas columnas:

El diagrama y la tabla representan las mismas relaciones. Si una dependencia cruza un límite entre sistemas sin un evento o contrato de consulta, el diseño está incompleto.

733. Ejemplo concreto

Considera una misión con estos objetivos:

1. Obligatorio: Encontrar el estuche sellado.
2. Obligatorio: Depositar el estuche en el refugio.
3. Opcional: Completar el depósito sin dañar el estuche.
4. Obligatorio: Informar del resultado al contacto de la misión.

Un mapa de dependencias podría expresarse así:

inventario: item_acquired(case_7)
              |
              v
      [estuche obtenido]
              |
              v
inventario: item_deposited(case_7, safehouse)
              |
              v
    [depósito completado] ---------> [informar del resultado]
              |
              +----> [opcional: estuche intacto]
                         |
                         v
                  [rama opcional de resultado]

La misma estructura puede registrarse en una tabla de nodos y conexiones, sin necesidad de inspeccionar un diagrama. La condición opcional no bloquea el objetivo de informar ni debe convertirse en un requisito oculto. Si el refugio deja de estar disponible antes del informe, un evento autorizado del estado del mundo o de una facción puede interrumpir la misión y exigir un destino nuevo.

Si el inventario emite después una reversión autorizada, como item_deposit_invalidated(case_7, safehouse), el contrato de misión debe indicar si el depósito vuelve a estar incompleto, pasa a un estado fallido o queda a la espera de evidencia compensatoria. La misión observa y evalúa el resultado; no lo fabrica.

734. Error común

El error más frecuente es tratar un evento de misión como una orden para otro sistema. Por ejemplo, un manejador puede recibir deposit_requested y añadir directamente el estuche al inventario o marcar un cambio de facción. Eso transfiere la propiedad del estado a la misión y dificulta razonar sobre fallos, repeticiones y reversiones.

Una misión debe consumir un resultado autorizado como item_deposited, no asumir que una solicitud ya produjo ese resultado. Si hace falta una orden, represéntala como una solicitud separada, con un responsable claro, y espera la evidencia de éxito, rechazo o fallo emitida por el sistema propietario.

735. Práctica guiada

Crea un mapa de dependencias para este encargo:

Recupera un libro contable de una zona vigilada. El libro debe colocarse en el archivo. Si el jugador destruye al capitán de la guardia, el contacto del archivo rechazará la entrega. Si el jugador recupera el libro sin activar una alarma, la misión puede conceder un resultado opcional de recuperación limpia. La misión puede interrumpirse antes de la entrega si el archivo deja de ser accesible. El sistema de misiones no debe poseer el estado del combate, del inventario, de la alarma ni de las facciones.

Puedes usar un diagrama de nodos y conexiones o la tabla equivalente descrita antes.

Completa estos pasos:

1. Escribe los objetivos obligatorios y opcionales como predicados con sus fuentes de evidencia.
2. Nombra al menos cuatro eventos o consultas e identifica a sus productores autorizados.
3. Representa la secuencia normal desde la recuperación hasta la entrega.
4. Añade una ruta de interrupción para un archivo inaccesible.
5. Añade la ruta de rechazo del capitán de la guardia: si el sistema de combate informa con autoridad que el capitán fue destruido, el sistema de facciones o del contacto del archivo debe proporcionar el resultado de rechazo, y el objetivo de entrega debe permanecer incompleto.
6. Añade una ruta de reversión o invalidación para una colocación del libro aceptada previamente.
7. Marca la recuperación limpia como rama opcional y especifica exactamente qué puede cambiar sin bloquear la finalización obligatoria. La mera ausencia de un evento de alarma no constituye evidencia duradera: define un punto de evaluación y exige una consulta al sistema de alarmas o un evento de resumen autorizado que confirme cero alarmas para el contexto de misión correspondiente.
8. Revisa cada dependencia que cruce un límite entre sistemas. Sustituye cualquier mutación directa por un evento, una consulta o un par explícito de solicitud y resultado.

Toma una decisión de diseño sobre un evento previo a la activación o fuera de orden: explica qué ocurre si ledger_retrieved llega antes de que su objetivo esté activo. Elige una de estas políticas:

• Conservar la evidencia hasta que el objetivo pueda evaluarla.
• Consultar el estado actual del productor autorizado cuando se active el objetivo.
• Rechazar el evento con una razón documentada.

Justifica por qué la política elegida se ajusta a la vigencia de la evidencia y al comportamiento durante una repetición.

736. Validación y evidencia

737. Puntos clave

• Las misiones coordinan hechos autorizados; no son dueñas de todos los sistemas implicados en un objetivo.
• Un contrato de evento necesita un productor, evidencia significativa, supuestos temporales y un comportamiento ante invalidaciones.
• Un evento previo a la activación o fuera de orden necesita una política explícita de conservación, consulta o rechazo.
• Las rutas de interrupción, rechazo y reversión deben diseñarse de forma explícita.
• Los objetivos opcionales pueden cambiar el resultado sin bloquear la finalización obligatoria.
• La ausencia de un evento no constituye una prueba duradera salvo que un contrato autorizado confirme ese hecho en un punto de evaluación definido.

738. Próxima lección

A continuación: 2.8 — Narrativa interactiva. Lleva contigo los nombres de eventos, los límites de autoridad, la ruta de rechazo del capitán de la guardia, la rama opcional y las decisiones de interrupción y reversión documentadas aquí. Esos elementos servirán como entradas para diseñar el estado narrativo; no transfieren la propiedad del estado de la misión, el combate, el inventario, las alarmas ni las facciones.

739. Comprobación