Traza el daño desde la intención hasta el resultado

571. Identidad de la lección

Módulo

2.1 — Combatee

Lección

Traza el daño desde la intención hasta el resultado

Tipo académico

Construcción guiada

Tipo de esquema

Práctica

Orden

2 del módulo

Tiempo estimado

35–45 minutos, incluida la práctica de diagramación

572. Objetivo de aprendizaje

Al terminar esta lección, podrás crear un diagrama del flujo de daño que asigne la responsabilidad de cada paso, identifique el cambio del estado de salud a cargo del sistema con autoridad exclusiva y revele fallos de autoridad duplicada antes de implementar.

573. Por qué importa

Un ataque no termina cuando se detecta una entrada o se reproduce una animación. Termina cuando una regla de combate válida produce un cambio de estado a cargo del sistema con autoridad exclusiva cuyo resultado pueden observar los demás sistemas de forma coherente.

Un flujo de daño preciso establece un límite claro para implementar y depurar. Cuando el resultado es incorrecto, puedes revisar en orden la validación, la resolución, la mutación del estado, la publicación del evento y la presentación, en vez de buscar a ciegas entre armas, volúmenes de impacto, animaciones e interfaces.

574. Conocimientos previos

Debes poder:

• Describir el combate como un contrato acotado con condiciones, autoridad y resultado.
• Separar las reglas de combate del contenido de armas o efectos.
• Identificar al atacante, al objetivo, el daño propuesto y los sistemas vecinos protegidos en un encuentro pequeño.

Estas capacidades provienen de la lección anterior, El combate es un contrato, no una lista de armas.

575. Concepto central

Un ataque exitoso debe seguir un único recorrido autoritativo desde la intención hasta el resultado:

1. La intención solicita un ataque.
2. La validación decide si la solicitud está permitida.
3. La resolución calcula el resultado del combate sin modificar la salud del objetivo.
4. El propietario del estado aplica y registra el resultado resuelto como cambio del estado de salud a cargo del sistema con autoridad exclusiva.
5. La comunicación del resultado informa a los observadores de la transición ocurrida.
6. La respuesta visible o sonora presenta ese resultado sin volver a calcularlo ni aplicarlo.

La separación de responsabilidades es esencial:

• El sistema de resolución de combate es responsable de calcular el resultado resuelto.
• El propietario de la salud o del estado de combate del objetivo es responsable de modificar la salud y registrar el nuevo valor.
• Los sistemas de presentación, animación, audio, IA y registro pueden observar el resultado, pero suscribirse a un evento no les concede autoridad sobre la salud.

Cuando la transición tiene éxito, un evento DamageResolved puede incluir el atacante, el objetivo, el identificador del ataque, el daño resuelto y la salud resultante o el desenlace de derrota. El evento describe un resultado que el propietario de la salud ya aplicó.

Una solicitud rechazada sigue otro recorrido. Puede emitir un evento AttackRejected con la identidad de la solicitud y el motivo del rechazo, pero no debe emitir un resultado de daño exitoso ni provocar una transición de salud.

576. Modelo mental

Usa la cadena de daño con autoridad única:

INTENCIÓN DE ATAQUE
        ↓
VALIDAR EL CONTRATO
        ↓
RESOLVER EL DAÑO UNA SOLA VEZ
        ↓
EL PROPIETARIO DE LA SALUD APLICA Y REGISTRA LA TRANSICIÓN
        ↓
EMITIR DAMAGE RESOLVED
        ↓
PRESENTAR U OBSERVAR EL RESULTADO

El invariante es: un impacto válido produce una sola cambio del estado de salud a cargo del sistema con autoridad exclusiva. La respuesta visual o sonora puede repetirse o llegar con retraso, pero la mutación de la salud no debe duplicarse.

577. Ejemplo concreto

Considera un ataque cuerpo a cuerpo con estos valores:

• Atacante: guard
• Objetivo: courier
• Daño resuelto: 12
• Salud del objetivo antes del impacto: 40
• El ataque está dentro del alcance y el objetivo no es invulnerable

Un flujo correcto sería:

Guard solicita un corte
→ El contrato de combate valida el alcance y el estado del ataque
→ El sistema de resolución calcula 12 de daño sin modificar la salud
→ El propietario de la salud de Courier aplica y registra 40 → 28
→ DamageResolved transporta { target: courier, amount: 12, healthAfter: 28 }
→ El destello, el sonido, el número flotante, el registro y otros observadores reaccionan

Un sistema de presentación puede mostrar 12, pero no debe restar otros 12. Si una función del volumen de impacto también modifica la salud, Courier podría terminar con 16 en vez de 28, aunque los datos mostrados por el evento parezcan correctos. Ese es un fallo de autoridad duplicada.

Un ataque rechazado sigue una rama distinta:

Guard solicita un corte
→ El contrato rechaza la solicitud porque el objetivo está fuera de alcance
→ No hay resolución ni transición de salud
→ Un evento AttackRejected opcional comunica el motivo
→ Una respuesta opcional presenta el rechazo

Así, la ausencia de daño es una consecuencia explícita de la validación y no un efecto accidental.

578. Error común

Un error frecuente es asumir que todo receptor de una señal de impacto o de resultado está autorizado para aplicar daño. Puede ocurrir cuando el script del arma, una función del volumen de impacto, el controlador del enemigo, un evento de animación y la interfaz contienen cada uno una resta o un cálculo.

El código puede parecer modular, pero la autoridad está duplicada. Cambiar el nombre de las funciones no soluciona el problema. La corrección consiste en mantener el cálculo en un solo sistema de resolución de combate, reservar la mutación para el propietario de la salud del objetivo y hacer que los demás sistemas consuman el resultado registrado sin recalcularlo ni volver a aplicarlo.

579. Práctica guiada

Crea un único diagrama canónico del flujo de daño. Añade al mismo diagrama dos recorridos de mutación no autorizados, claramente etiquetados: uno para el Caso A y otro para el Caso B. No necesitas dibujar un flujo completo independiente para cada caso.

Usa esta plantilla compacta:

[Intención de ataque]
        ↓
[Validación] ── rechazado ──→ [AttackRejected] → [Respuesta opcional]
        ↓ aceptado
[Sistema de resolución: calcula ______; no modifica la salud]
        ↓ resultado resuelto
[Propietario de la salud: aplica y registra ______ → ______]
        ↓
[DamageResolved: transporta ____________________]
        ↓
[Observadores y presentación: ____________________]

Recorrido no autorizado A: ____________________ → segunda mutación de salud
Recorrido no autorizado B: ____________________ → nuevo cálculo + segunda mutación

Caso A — El volumen de impacto duplica la transición de salud

El jugador ataca a un saqueador con un golpe cargado. El sistema de resolución de combate valida la solicitud y calcula 10 puntos de daño sin modificar la salud. Después entrega el resultado resuelto al propietario de la salud del saqueador, que aplica y registra la transición autoritativa de 30 a 20. Tras observar el resultado, una función del volumen de impacto realiza una segunda resta no autorizada de 10, por lo que el saqueador termina con 10.

Caso B — La presentación vuelve a calcular después de una transición válida

El jugador ataca a un mensajero con un golpe rápido. El sistema de resolución valida la solicitud y calcula 8 puntos de daño. El propietario de la salud del mensajero aplica y registra la transición de 24 a 16. Un presentador del número flotante observa DamageResolved, vuelve a calcular el daño a partir del valor base del ataque y aplica otros 8 antes de mostrar el número. El mensajero termina incorrectamente con 8.

Completa el diagrama y sus anotaciones:

1. Escribe la intención de ataque en una oración.
2. Enumera las condiciones de validación y añade una rama rechazada que no produzca una transición de salud.
3. Nombra el sistema de resolución de combate e indica que calcula el resultado resuelto, pero no modifica la salud del objetivo.
4. Nombra al propietario de la salud del objetivo e indica que aplica y registra el resultado resuelto.
5. Muestra la entrega del resultado resuelto entre ambos responsables.
6. Define los datos mínimos que necesitan los observadores en un evento DamageResolved exitoso.
7. Etiqueta el recorrido no autorizado A con el segundo sistema, la secuencia incorrecta 30 → 20 → 10 y la corrección.
8. Etiqueta el recorrido no autorizado B con el segundo sistema, la secuencia incorrecta 24 → 16 → 8 y la corrección.

Añade tres notas breves para cada recorrido no autorizado:

• Causa: ¿Qué observador adquirió autoridad de mutación sin autorización?
• Evidencia: ¿Qué valor cambió dos veces y qué valor final revela el fallo?
• Corrección: ¿Qué mutación debe eliminarse y qué datos del evento resuelto puede seguir consumiendo el observador?

El diagrama debe distinguir solicitud, decisión, cálculo, mutación del estado, comunicación y presentación. Una caja que solo diga “hacer daño” no constituye evidencia suficiente.

580. Validación y evidencia

581. Puntos clave

• Traza el combate desde la intención hasta el resultado en vez de comenzar por los scripts de armas.
• El sistema de resolución calcula el resultado; el propietario de la salud del objetivo lo aplica y lo registra.
• DamageResolved comunica un resultado exitoso ya aplicado, mientras que las solicitudes rechazadas siguen una ruta de rechazo distinta.
• La presentación y los demás observadores no deben convertirse en autoridades adicionales sobre la salud.
• La autoridad duplicada se hace visible cuando el mismo valor de salud cambia dos veces por un único impacto válido.

582. Siguiente lección

Continúa con 2.2 — IA enemiga. Los estados y las transiciones del enemigo pueden observar DamageResolved o un desenlace de derrota para decidir cómo reaccionar, pero esa observación no transfiere la autoridad sobre la salud fuera de su propietario.

583. Comprobación