Una misión es un conjunto de predicados

714. Identidad de la lección

Módulo

2.7 — Misiones

Lección

Una misión es un conjunto de predicados

Tipo académico

Concepto

Tipo de esquema

texto

Orden

1 del módulo

Tiempo estimado

30–40 minutos, incluida la práctica

715. Objetivo de aprendizaje

Al terminar esta lección, podrás redactar un contrato de misión que exprese los objetivos como predicados observables, nombre una fuente de evidencia con autoridad para cada predicado y defina la condición que permite completarla.

716. Por qué importa

Un objetivo como “ayuda al contacto” puede ser legible, pero no es ejecutable. Un sistema de juego necesita una condición comprobable a partir de un estado conocido. Si la condición es ambigua, la misión puede completarse demasiado pronto, demasiado tarde o debido al evento equivocado. Un contrato preciso también le da a la IA un objetivo de implementación delimitado: puede inspeccionar los predicados y sus fuentes de evidencia en lugar de adivinar qué significa “terminado”.

717. Conocimientos previos

Debes poder distinguir el estado que pertenece a la economía del resultado de una transacción, y comprender por qué una fabricación debe validar todos sus requisitos antes de modificar el estado. Como base relacionada, 2.5 L3 — Crafting is a transaction, not a second economy, aporta la distinción relevante: una misión puede observar el resultado de una transacción con autoridad, pero no debe convertirse silenciosamente en una segunda propietaria del estado económico. Esta lección usa esas distinciones sobre transacciones y propiedad para especificar la evidencia de una misión; no exige todavía conceptos posteriores de secuenciación ni de coordinación entre sistemas.

718. Concepto central

Una misión no es principalmente una secuencia de diálogos o marcadores del mapa. Es un contrato sobre el estado del juego.

Un predicado es una condición que, a partir de un estado observable, se evalúa como verdadera o falsa. Un contrato de misión combina predicados en una regla de finalización e identifica de dónde procede la evidencia.

Para cada objetivo, especifica:

1. Predicado: ¿Qué condición debe ser verdadera?
2. Fuente de evidencia: ¿Qué sistema posee o informa el estado que lo demuestra?
3. Autoridad de finalización: ¿Qué sistema tiene permiso para aceptar la misión como completada?
4. Momento: ¿Cuándo se evalúa o vuelve a evaluarse el predicado?
5. Regla de fallo o invalidación: Si corresponde, ¿qué hace imposible el objetivo o deja de hacerlo válido?

El sistema de misiones puede coordinar estas comprobaciones, pero no debe inventar hechos que pertenecen a otro sistema. Por ejemplo, el inventario puede demostrar que un objeto está en posesión del jugador. El sistema de misiones puede usar ese hecho para evaluar un objetivo. No debe mantener un contador duplicado y sin relación, y tratar esa copia como fuente de verdad. Un registro de misión puede anotar que se observó un predicado de adquisición o que hubo progreso; no duplica la propiedad del objeto ni se convierte en propietario de las cantidades del inventario.

719. Modelo mental

Usa el contrato de predicados para cada objetivo de misión:

La frontera de autoridad es la distinción principal:

Estado de un sistema con autoridad
        ↓ evidencia
Evaluación de predicados de la misión
        ↓ todos los predicados requeridos son verdaderos
Autoridad de finalización de la misión
        ↓
Evento de finalización y presentación

Un marcador, una línea de diálogo, una animación o la presentación de una recompensa son formas de comunicar una respuesta, no la fuente de verdad por sí mismas. La presentación puede informar de un cambio de estado, pero no debe ser su única prueba.

720. Ejemplo concreto

Considera este objetivo: “Recupera el libro de cuentas y llévalo al archivista.”

Una implementación débil podría completar la misión cuando el jugador entra en la zona del archivista. Ese evento de ubicación no demuestra que el jugador haya recuperado el libro correcto ni que lo haya entregado.

Un contrato más sólido separa los hechos necesarios y hace explícita la precondición de disponibilidad:

La regla de finalización de la misión es:

ledgerRecovered
AND ledgerAvailableForDeliveryAtDeliveryStart
AND deliveryAccepted(ledgerId, archivistId)

ledgerAvailableForDeliveryAtDeliveryStart es un predicado temporal: el libro debe estar disponible cuando se intenta la entrega. El resultado aceptado de la entrega es la evidencia con autoridad de que el libro correcto y disponible se transfirió realmente al archivista. Después de una entrega exitosa, el libro puede dejar de estar en el inventario del jugador; por eso la misión no debe volver a comprobar la posesión actual como condición continua de finalización. Si la misión guarda que el libro fue recuperado, ese registro representa únicamente progreso de misión; no duplica el registro de propiedad ni la cantidad de objetos que controla el sistema de inventario.

Entrar en la zona puede mostrar un aviso de interacción, pero no puede completar la misión sin una entrega aceptada. Si la transacción rechaza el libro, la misión permanece incompleta y el rechazo puede comunicarse al jugador.

721. Error común

El error común es tratar una acción del jugador o un evento de presentación como evidencia de finalización. “El jugador eligió una opción del diálogo” es un evento. No demuestra automáticamente que la transacción requerida haya tenido éxito. Del mismo modo, “desapareció el marcador del objetivo” es un cambio de presentación, no un estado de misión con autoridad.

Otro error es incluir un predicado en el contrato y omitirlo de la regla de finalización. Todo predicado requerido debe aparecer en la regla o definirse explícitamente como una precondición subsumida por un predicado con autoridad, como una entrega aceptada. Las etiquetas generales, como missionFeelsComplete, ocultan la evidencia que falta. Nombra el estado concreto y el sistema que lo posee. Un registro de progreso de misión puede referirse a un hecho que pertenece al inventario sin convertirse en una segunda autoridad del inventario.

722. Práctica guiada

Redacta un contrato de misión para este objetivo:

“Prepara un kit de reparación y entrégaselo al mecánico.”

Usa estas restricciones:

• El kit debe producirse mediante una transacción de fabricación aceptada.
• El kit debe estar disponible para la entrega cuando comience la transacción de entrega.
• El mecánico debe aceptar el kit correcto mediante una interacción de entrega aceptada.
• El sistema de misiones puede decidir la finalización, pero no es propietario de las cantidades de fabricación ni de inventario.

Completa esta tabla:

Después toma una decisión deliberada: exige los tres predicados o subsume explícitamente el predicado de disponibilidad en un resultado de entrega aceptado que verifique que el kit correcto estaba disponible al comenzar la entrega. Elige una opción, explica por qué y señala qué evidencia impide que tu elección invente la finalización. Tu regla final debe mostrar la disponibilidad como predicado temporal propio o como precondición documentada del predicado de entrega con autoridad. Si mencionas un registro de progreso de misión, distínguelo de los sistemas de fabricación o inventario que poseen el estado subyacente.

723. Validación / evidencia

724. Puntos clave

• Un objetivo de misión se vuelve implementable cuando se expresa como predicados observables.
• La evidencia debe proceder del sistema que posee el estado relevante o el resultado de la transacción.
• La disponibilidad en el momento de la entrega es un requisito temporal y no debe desaparecer del contrato.
• El sistema de misiones puede evaluar la evidencia y ser dueño del estado de la misión sin duplicar la autoridad de la economía o del inventario.
• Un registro de progreso de misión puede referirse a evidencia autorizada sobre un objeto sin poseer una segunda copia de su estado.
• La presentación comunica la finalización; no la demuestra por sí sola.

725. Siguiente lección

Continúa con 2.7 L2 — Coordinar objetivos entre sistemas.

726. Comprobación