Una facción gestiona relaciones, no el mundo entero

772. Identidad de la lección

Módulo

2.9 — Sistemas de facciones

Lección

Una facción gestiona relaciones, no el mundo entero

Tipo académico

Concepto

Tipo de esquema

texto

Orden

Lección 1 del módulo

Tiempo estimado

25–35 minutos, incluida la práctica

Esta lección establece un contrato acotado para las relaciones de una facción. Un sistema de facciones debe responder por las relaciones que gestiona sin convertirse en una autoridad oculta sobre la moneda, las misiones, el diálogo, el combate o todo el estado del juego.

773. Objetivo de aprendizaje

Después de esta lección, podrás especificar un contrato para una relación de facción al nombrar su estado, sus entradas aceptadas, la autoridad que puede modificarlo, sus invariantes, sus reglas de umbral y sus consumidores autorizados.

774. Por qué es importante

Los sistemas de facciones se vuelven difíciles de modificar cuando controlan en silencio dominios que no les corresponden. Un valor de reputación puede comenzar como una medida de relación y terminar siendo una fuente accidental de recompensas, disponibilidad de misiones, texto de diálogo y cambios de dificultad. Un contrato acotado proporciona un límite que los colaboradores pueden inspeccionar. También permite discutir con precisión si un valor es el estado de la relación, una entrada que lo modifica, una clasificación derivada o una salida gestionada por otro sistema.

La autoridad explícita de mutación y los invariantes permiten comprobar ese límite. Indican quién puede cambiar la relación, cómo se aplica el cambio y qué condiciones deben seguir siendo verdaderas después de cada actualización.

775. Conocimientos previos

Ya deberías poder:

• Separar una decisión de diseño del sistema responsable de su consecuencia.
• Identificar escrituras globales ocultas y sustituirlas por cambios de estado explícitos.
• Describir una elección mediante un contrato que distinga la selección de la consecuencia.

Estas capacidades provienen del Módulo 2.8 — Decisiones de diseño sin escrituras globales ocultas.

776. Concepto central

Una facción gestiona el estado de la relación entre un actor y esa facción. No controla automáticamente todos los sistemas afectados por la relación.

Un contrato útil para una relación de facción identifica el límite en cada paso:

1. Estado: ¿Qué valor o categoría de relación gestiona la facción?
2. Entrada aprobada: ¿Qué eventos o comandos explícitos pueden solicitar un cambio?
3. Autoridad de mutación: ¿Qué sistema aplica el cambio y mediante qué operación nombrada?
4. Comprobación de invariantes: ¿Qué condiciones deben seguir siendo verdaderas después de la mutación?
5. Clasificación: ¿Qué umbrales convierten el estado resultante en una etiqueta documentada?
6. Consumidores: ¿Qué sistemas pueden leer el resultado y qué respuesta corresponde a cada uno?

El flujo completo es:

entrada aprobada → autoridad de mutación → estado de la relación → comprobación de invariantes → clasificación por umbral → respuesta del consumidor autorizado

Un umbral solo convierte el estado resultante de la relación en una clasificación documentada. Cruzar un umbral no transfiere al sistema de facciones la responsabilidad sobre las consecuencias posteriores.

Por ejemplo, una facción puede gestionar playerRelationship = -20, los eventos aprobados que modifican ese valor y las clasificaciones hostile, wary y trusted. El sistema de relaciones de facción puede ser la única autoridad autorizada para ejecutar adjustRelationship(input), mientras un invariante mantiene el valor entre -100 y 100. El sistema de misiones puede consumir la etiqueta resultante para decidir si una misión está disponible. El sistema de facciones no debería crear silenciosamente la misión, entregar moneda, reescribir el diálogo ni cambiar la salud de los enemigos porque la relación haya cruzado un umbral.

Mantén separadas estas responsabilidades:

Una decisión sobre la autoridad de mutación responde: «¿Quién puede cambiar este estado?». En un contrato acotado, el sistema de relaciones de facción lo modifica mediante una operación explícita que acepta entradas aprobadas. Un productor de eventos puede solicitar un cambio, pero no debe escribir directamente el valor de la relación.

Una decisión sobre invariantes responde: «¿Qué debe seguir siendo cierto después del cambio?». Algunos ejemplos son un rango numérico limitado, una única clasificación vigente derivada del valor actual y el rechazo de tipos de entrada desconocidos. Los invariantes protegen el contrato de relación; no conceden responsabilidad sobre las consecuencias posteriores.

777. Modelo mental

Utiliza el modelo Entradas → Autoridad de mutación → Estado → Invariantes → Umbrales → Consumidores.

solicitud de entrada aprobada
            |
            v
 [autoridad de mutación]
            |
            v
  [estado de la relación]
            |
[comprobación de invariantes]
            |
            v
 [clasificación por umbral]
         /       |        \
    misiones  diálogo/UI  recompensas
     decide     presenta     entrega

Completa este contrato para cada relación de facción:

Las filas de autoridad e invariantes son esenciales. Sin una autoridad definida, varios sistemas pueden modificar la misma relación mediante escrituras ocultas. Sin invariantes, un contrato puede nombrar un rango o conjunto de clasificaciones sin explicar cómo se protege. Las exclusiones explícitas evitan que el sistema de facciones se convierta en un controlador global.

778. Ejemplo concreto

Supón que el juego tiene una facción llamada Liga del Puerto. Su contrato de relación podría ser:

• Estado: harborLeagueStanding, un entero entre -100 y 100.
• Entradas: completar una entrega para la Liga suma +10; robar carga de la Liga resta -15.
• Autoridad de mutación: solo el sistema de relaciones de facción aplica estos cambios mediante adjustRelationship(input); los productores de eventos no asignan directamente el valor.
• Invariantes: el valor permanece entre -100 y 100; una entrada desconocida se rechaza; exactamente una etiqueta de relación se deriva del valor actual.
• Umbrales: menos de -25 es hostile; de -25 a 24 es wary; 25 o más es trusted.
• Consumidores: el sistema de misiones comprueba la clasificación antes de ofrecer un encargo de la Liga; el sistema de diálogo elige una variante de relación escrita de forma explícita; la interfaz muestra la etiqueta actual.
• Exclusiones: el sistema de facciones no paga la recompensa de la entrega, no crea la misión, no selecciona las líneas de diálogo ni modifica las estadísticas de los enemigos.

Cuando se completa una entrega, el evento envía una entrada aprobada. El sistema de relaciones de facción valida la entrada, aplica la mutación mediante su operación nombrada y comprueba los invariantes. Después clasifica el valor resultante mediante los umbrales documentados. Los consumidores autorizados leen el estado o su clasificación y realizan únicamente las responsabilidades que les corresponden.

Este diseño permite respuestas distintas ante el mismo resultado. El sistema de misiones puede denegar una misión a un jugador hostil mientras el sistema de diálogo presenta una advertencia. Ninguna de las dos respuestas tiene que estar incorporada en la actualización de la facción.

779. Error frecuente

Un error frecuente es tratar el cruce de un umbral como permiso para que el sistema de facciones ejecute todas las consecuencias. Por ejemplo: «Cuando la reputación llegue a 25, desbloquea la misión, entrega 100 créditos, reemplaza el árbol de diálogo y reduce el daño de los guardias». Eso mezcla la clasificación de la relación con responsabilidades de misiones, economía, diálogo y combate.

Otro error es permitir que cualquier manejador de eventos asigne directamente el campo de relación. Eso elude la autoridad de mutación y puede omitir la validación, los límites u otros invariantes.

Un diseño mejor expone un resultado claro, como el valor subyacente y su clasificación trusted, y permite que cada consumidor autorizado decida cómo utilizarlo dentro de su propio dominio. Las consecuencias necesarias deben documentarse como contratos de los consumidores, no ocultarse dentro de la actualización de la facción.

780. Práctica guiada

Escribe un contrato de una página para una facción inventada. No lo implementes. Completa la siguiente tabla:

Después, prueba el contrato con este escenario:

La relación del jugador pasa de wary a trusted después de un evento.

Escribe seis frases:

1. ¿Qué entrada aprobada se acepta?
2. ¿Qué autoridad aplica la mutación?
3. ¿Qué estado subyacente de la relación cambia?
4. ¿Qué invariante se comprueba o preserva?
5. ¿Qué clasificación se deriva mediante los umbrales y qué consumidor la lee primero?
6. ¿Qué decide ese consumidor y qué consecuencia tentadora permanece fuera de la responsabilidad de la facción?

Las decisiones de diseño obligatorias son la autoridad de mutación, la lista de invariantes y la lista de exclusiones. Elige al menos una consecuencia que sería conveniente colocar en el sistema de facciones y asígnala deliberadamente a otro sistema.

781. Validación y evidencias

782. Ideas clave

• Una facción gestiona el estado de la relación y las reglas para modificarlo y clasificarlo.
• Las entradas deben ser explícitas y la autoridad de mutación debe concentrarse en una operación nombrada.
• Los invariantes protegen el contrato de relación después de cada mutación.
• Los umbrales producen clasificaciones documentadas; no transfieren la responsabilidad sobre las consecuencias posteriores.
• Los consumidores leen los resultados de la facción y gestionan las respuestas propias de su dominio.
• Las exclusiones explícitas impiden que el sistema de facciones se convierta en un controlador global oculto.

783. Siguiente lección

A continuación: Mantén las consecuencias de facción acotadas y explícitas, la siguiente lección del Módulo 2.9 — Sistemas de facciones.

784. Comprobación