Delimitar el requisito del mundo

814. Identidad de la lección

Módulo

2.10 — Mundo vivo

Lección

Delimitar el requisito del mundo

Tipo académico

Sistemas

Tipo de esquema

texto

Orden

2 del módulo

Tiempo estimado

35–45 minutos, incluida la práctica

815. Objetivo de aprendizaje

Al terminar esta lección, podrás especificar un comportamiento de mundo vivo como un contrato de estado acotado, con un responsable claro, transiciones permitidas y consecuencias deterministas.

816. Por qué importa

“Haz que el mundo parezca vivo” es una dirección creativa, no un requisito implementable. Si el requisito no tiene límites, todos los sistemas pueden acabar siendo responsables de él y cada consecuencia puede propagarse por todo el juego. Un contrato acotado convierte un comportamiento en algo que se puede diseñar, probar, explicar a un colaborador de programación basado en IA y modificar sin ampliar accidentalmente toda la simulación. El objetivo no es empobrecer el mundo, sino hacer fiable un comportamiento significativo.

817. Conocimientos previos

Debes poder distinguir entre un estado de mundo definido por diseño, un horario, una simulación acotada y una simulación sin límites, como se explicó en Mundo guionizado frente a mundo simulado. También debes poder describir un comportamiento mediante un estado, un evento desencadenante y un resultado observable.

818. Concepto central

Un requisito de mundo está acotado cuando responde a cuatro preguntas:

1. ¿Qué comportamiento se está especificando?
2. ¿Qué sistema es responsable de su estado y sus transiciones?
3. ¿Cuál es el contrato de estado mínimo que basta para este comportamiento?
4. ¿Qué consecuencia determinista sigue a cada transición permitida?

Un requisito no está acotado solo porque su descripción sea breve. Está acotado cuando sus responsabilidades, estados, entradas, salidas y límites son explícitos. La evidencia también debe indicar el modelo de comportamiento elegido —estado definido por diseño, horario o simulación acotada— y explicar por qué es la opción más sencilla que basta para producir el resultado visible previsto.

Por ejemplo, “el mercado debe reaccionar a la actividad del jugador” todavía no es un requisito acotado. No define la actividad, el estado del mercado, el sistema responsable, el momento del cambio ni la consecuencia. Una versión acotada podría ser:

El mercado del distrito mantiene una condición de suministro de tres estados: estable, tensionado o reabastecido, y comienza en estable. El sistema de mercado es responsable de esa condición. Consumir existencias disponibles mientras la condición es estable la cambia a tensionado; completar una entrega mientras está tensionado la cambia a reabastecido; consumir existencias mientras está reabastecido la devuelve a tensionado. Para cualquier combinación de evento y estado actual que no esté indicada aquí, la condición no cambia. Cada transición modifica únicamente el mensaje de existencias y el precio de una categoría de objetos definida.

Esto sigue siendo una decisión de diseño, no una implementación completa. Es lo bastante específico para evaluarlo sin prometer una simulación de todos los factores económicos.

819. Modelo mental

Usa el contrato BOUND:

Después añade cuatro decisiones complementarias:

• Estado inicial: el estado en el que comienza el contrato.
• Modelo de comportamiento: estado definido por diseño, horario o simulación acotada.
• Fuera de alcance: comportamientos que este requisito no controla.
• Evidencia: qué observarás para confirmar que el contrato funciona.

Puedes escribir un contrato compacto así:

Comportamiento: [un comportamiento del mundo]
Responsable: [un sistema]
Estado: [conjunto finito o valor acotado]
Estado inicial: [un estado válido o valor inicial acotado]
Transiciones permitidas: [evento + estado actual -> estado siguiente]
Consecuencias: [resultados observables concretos]
Modelo de comportamiento: [estado definido por diseño | horario | simulación acotada]
Por qué es el modelo mínimo suficiente: [justificación breve vinculada al resultado requerido]
Fuera de alcance: [comportamientos cercanos excluidos]
Evidencia: [observaciones comprobables]

El sistema responsable no es necesariamente el que origina el evento. Una acción del jugador puede activar una transición, pero el sistema de mercado sigue siendo responsable del estado del mercado. Separar ambos papeles evita que sistemas no relacionados modifiquen el mismo dato.

820. Ejemplo concreto

Supón que la ambición es: “El asentamiento debe recordar si el jugador lo ha ayudado.”

La frase es demasiado amplia. “Ayudar” podría significar entregar suministros, proteger habitantes, completar diálogos, gastar moneda o terminar un objetivo importante. También sugiere un número indeterminado de reacciones posteriores.

Una alternativa acotada sería:

Comportamiento: La puerta del asentamiento muestra una de dos condiciones de acceso después de una entrega de suministros.
Responsable: Sistema de acceso del asentamiento.
Estado: acceso_bloqueado | acceso_abierto.
Estado inicial: acceso_bloqueado.
Transiciones permitidas:
  entrega_de_suministros_completada mientras acceso_bloqueado -> acceso_abierto
  cualquier otro evento, o cualquier evento mientras acceso_abierto, deja el estado sin cambios.
Consecuencias:
  acceso_abierto cambia el texto de la puerta y permite atravesarla.
Modelo de comportamiento: Estado definido por diseño.
Por qué es el modelo mínimo suficiente:
  El requisito solo necesita conservar un dato y ejecutar una transición definida; no necesita actividad temporal ni agentes que interactúen continuamente.
Fuera de alcance:
  horarios de habitantes, precios, reputación, patrullas enemigas y memoria de diálogos.
Evidencia:
  después del evento de entrega, cambia el texto y se puede atravesar la puerta;
  las acciones no relacionadas no cambian el estado de acceso.

El diseño podría ampliarse más adelante, pero su límite actual es intencionado. Un sistema es responsable de un dato y se definen exactamente dos consecuencias. Ahora el diseñador puede decidir si este comportamiento merece construirse antes de añadir más memoria al mundo.

821. Error común

El error habitual es convertir cada consecuencia interesante en parte del mismo requisito. Se empieza con una puerta que se abre después de una entrega y se añaden reacciones de habitantes, cambios de precios, rutas de patrulla, clima, reputación y diálogos persistentes porque todo ello haría que el asentamiento pareciera más vivo. El requisito original se ha transformado en una simulación sin límites.

Crea un requisito separado para cada comportamiento con una responsabilidad independiente. Si dos comportamientos deben coordinarse, especifica el evento o contrato que los conecta en lugar de permitir que ambos sistemas editen el mismo estado.

822. Práctica guiada

Elige una de estas ambiciones de mundo vivo, o escribe una equivalente:

• “El puesto avanzado debe reaccionar ante la escasez.”
• “El distrito debe parecer más seguro después de que el jugador ayude.”
• “El mundo debe recordar que el jugador pasó por allí.”

Ahora crea un contrato BOUND para un solo comportamiento. Sigue estos pasos:

1. Concreta el verbo. Sustituye palabras como “reaccionar”, “parecer” o “recordar” por un cambio observable.
2. Nombra un responsable. Elige el sistema que almacena el estado y autoriza sus transiciones.
3. Limita el estado. Usa un conjunto finito pequeño o un rango numérico explícito e indica el estado inicial. No añadas estado solo porque una función futura pueda necesitarlo.
4. Escribe las transiciones permitidas. Para cada transición, indica el evento, la condición actual y la condición siguiente. Indica también qué ocurre con las combinaciones de evento y estado que no hayas listado.
5. Especifica las consecuencias. Para este ejercicio, enumera como máximo dos consecuencias inmediatas.
6. Elige y justifica el modelo de comportamiento. Selecciona un estado definido por diseño, un horario o una simulación acotada. Explica por qué es el modelo más sencillo que permite producir el resultado observable requerido.
7. Declara las exclusiones. Nombra al menos tres comportamientos cercanos que quedan fuera del requisito.
8. Define la evidencia. Explica qué podrá observar una persona encargada de probar o revisar el diseño para confirmar la transición prevista y la ausencia de una transición no prevista.
9. Valida el contrato. Compara la plantilla terminada con todos los criterios de la sección de validación antes de darla por completa.

Usa esta plantilla:

Comportamiento:
Responsable:
Estado:
Estado inicial:
Transiciones permitidas:
  - [evento] + [estado actual] -> [estado siguiente]
Combinaciones no listadas de evento/estado:
  - [permanecen sin cambios, o especifica otro resultado acotado]
Consecuencias:
  -
  -
Modelo de comportamiento:
  - [estado definido por diseño | horario | simulación acotada]
Por qué es el modelo mínimo suficiente:
  -
Fuera de alcance:
  -
  -
  -
Evidencia:
  -
  -

Antes de continuar, somete tu contrato a cuatro preguntas:

• ¿Puede otro sistema cambiar este estado sin pasar por el responsable?
• ¿Hay algún estado o transición que realmente no haga falta?
• ¿Dos desarrolladores podrían interpretar la consecuencia de forma distinta?
• ¿Has elegido un modelo de comportamiento más complejo de lo necesario para obtener el resultado observable?

Revisa el contrato si la respuesta a alguna pregunta es sí.

823. Validación / evidencia

824. Ideas clave

• Una ambición de mundo vivo solo se puede construir después de hacer explícitos su comportamiento y sus límites.
• El sistema responsable almacena el estado y controla sus transiciones; el origen del evento no es automáticamente responsable del estado.
• Los contratos de estado pequeños y finitos son más fáciles de probar y más seguros de ampliar.
• Las consecuencias deterministas hacen que un comportamiento sea observable y no solo atmosférico.
• Elegir el modelo de comportamiento mínimo suficiente evita horarios o simulaciones innecesarios.
• Declarar lo que queda fuera de alcance protege el requisito contra el crecimiento descontrolado del sistema.

825. Próxima lección

Continúa con 2.12 — Navegación, mapas y vehículos. Al definir un contrato de ruta, la representación de navegación debe exponer solo el estado acotado que necesita la ruta, sin convertirse en la fuente autoritativa del estado del mundo.

826. Comprobación