El comportamiento enemigo es un contrato de estados

584. Identidad de la lección

Etapa

2 — Sistemas

Módulo

2.2 — IA enemiga

Lección

1

Tipo académico

Concepto

Tiempo estimado

30–40 minutos

Esta lección define el comportamiento enemigo mediante estados observables y reglas explícitas para pasar de uno a otro. El objetivo no es que el enemigo parezca inteligente en términos generales, sino que su comportamiento sea legible, comprobable y esté regido por un contrato claro de selección de estados.

585. Objetivo de aprendizaje

Al terminar, podrás definir los estados, las condiciones de transición, las salidas, la responsabilidad de decisión y el comportamiento de fallo de una máquina de estados enemiga pequeña. Podrás representar la especificación mediante una tabla de contratos, una tabla explícita de transiciones y un grafo dirigido o lista de aristas etiquetadas que coincida con ella.

586. Por qué importa

«Haz que el enemigo sea más inteligente» no es un requisito implementable. No indica qué puede observar el enemigo, qué comportamiento puede seleccionar, cuándo debe cambiar esa selección ni qué ocurre si falta información o falla una operación.

Un contrato de estados convierte esa petición imprecisa en reglas inspeccionables. El grafo muestra las rutas permitidas, las salidas ausentes y los estados inalcanzables antes de implementar.

587. Conocimientos previos

Debes poder seguir un evento de combate desde la intención hasta el resultado, identificar qué sistema tiene autoridad para modificar la salud y distinguir el estado del juego de su presentación. Esta lección continúa el trabajo de 2.1 L2 — Trace damage from intent to outcome. No necesitas un controlador enemigo terminado.

588. Estado, condición de transición y salida

Una máquina de estados pequeña contiene tres elementos que debes distinguir:

• Estado: el modo de comportamiento actual, como IDLE, CHASE o ATTACK.
• Condición de transición: un hecho observable o un evento identificado que permite cambiar de estado, como «la distancia al objetivo es igual o menor que el alcance de ataque».
• Salida: una solicitud o acción observable producida mientras el estado está activo, como «solicitar movimiento hacia el objetivo».

Considera esta regla:

Mientras esté en CHASE, solicitar movimiento hacia el objetivo válido. Si el objetivo está dentro del alcance y el ataque está disponible, entrar en ATTACK.

En esa regla:

• CHASE es el estado;
• solicitar movimiento es una salida;
• objetivo dentro del alcance más ataque disponible es una condición de transición;
• ATTACK es el estado siguiente.

Una salida no equivale automáticamente a una consecuencia resuelta. ATTACK puede emitir una solicitud de ataque, pero el sistema de combate con autoridad todavía debe decidir si la solicitud cumple las reglas y si corresponde modificar la salud.

589. Un estado es un contrato

Un contrato de estado útil especifica:

1. Condición de entrada: qué debe ser cierto al comenzar el estado.
2. Salida observable: qué solicita o expone el estado mientras está activo.
3. Condiciones de salida: qué hechos o eventos permiten abandonarlo.
4. Responsabilidad de decisión: qué componente selecciona el estado y evalúa sus transiciones.
5. Comportamiento de fallo: qué ocurre si falta información o falla una operación solicitada.

CHASE está incompleto si solo significa «seguir al jugador». Un contrato utilizable podría indicar:

• Entrar en CHASE al detectar un objetivo válido fuera del alcance de ataque.
• Mientras esté activo, solicitar movimiento hacia ese objetivo.
• Entrar en ATTACK cuando el objetivo esté en alcance y el ataque esté disponible.
• Entrar en SEARCH cuando el objetivo permanezca fuera de la vista durante un intervalo definido.
• Entrar en RETURN cuando se alcance el límite de persecución.
• Si falla el movimiento, exponer el fallo y seguir una alternativa declarada en lugar de reintentar silenciosamente sin límite.

La responsabilidad de decisión se refiere a seleccionar estados de comportamiento. No implica autoridad sobre los resultados del movimiento, los cambios de salud, la reproducción de animaciones ni las recompensas.

590. Tabla de contratos de estado

Utiliza una tabla antes de solicitar una implementación:

La tabla identifica el componente responsable de seleccionar el estado. No transfiere a ese componente la autoridad para resolver las consecuencias.

591. Grafo de estados

La tabla define el contrato de cada estado. El grafo dirigido define las transiciones permitidas entre estados.

Dibuja un nodo por cada estado y una flecha por cada transición permitida. Marca el estado inicial y etiqueta cada flecha con una condición observable.

Usa esta forma:

ESTADO ACTUAL + HECHOS OBSERVABLES + CONDICIÓN → ESTADO SIGUIENTE

Por ejemplo:

CHASE + distancia al objetivo ≤ alcance + ataque disponible → ATTACK

«El enemigo se siente preparado» no es una condición útil. «El objetivo ha permanecido fuera de la vista durante 3 segundos» sí es medible y comprobable.

El grafo de un guardia podría incluir estas conexiones:

• IDLE → CHASE: se detecta un objetivo válido fuera del alcance.
• IDLE → ATTACK: se detecta un objetivo válido dentro del alcance.
• IDLE → IDLE: combate rechaza la solicitud de ataque en alcance; la salud no cambia.
• CHASE → ATTACK: el objetivo está en alcance y el ataque está disponible.
• ATTACK → CHASE: el objetivo sigue siendo válido, pero sale del alcance.
• CHASE → SEARCH: el objetivo permanece fuera de la vista durante el intervalo de pérdida.
• SEARCH → CHASE: se vuelve a detectar el objetivo.
• SEARCH → RETURN: termina la duración de búsqueda.
• CHASE → RETURN: se alcanza el límite de persecución.
• CHASE → RETURN: falla la solicitud de movimiento; exponer el fallo.
• ATTACK → CHASE: combate rechaza la solicitud; la salud no cambia.
• ATTACK → SEARCH: el objetivo deja de ser válido durante el ataque.
• ATTACK → ATTACK: termina el ataque, cooldown restante > 0, objetivo válido y en alcance.
• ATTACK → ATTACK: termina el ataque, cooldown restante = 0, objetivo válido y en alcance.
• SEARCH → RETURN: la última posición conocida es inválida.
• RETURN → CHASE: se detecta un objetivo permitido.
• RETURN → IDLE: falla el movimiento; detenerse en un lugar seguro.
• RETURN → IDLE: se alcanza la zona asignada y no existe un objetivo válido.

La tabla y el grafo deben describir la misma máquina. Si la tabla permite SEARCH → RETURN, pero el grafo omite esa conexión, los artefactos no coinciden. Si una flecha del grafo no tiene una condición documentada, el contrato de transición está incompleto.

592. 8b. Tabla de transiciones

La tabla de contratos describe cada estado. La paridad con el grafo se comprueba contra esta tabla de transiciones, no contra celdas agregadas de salida. Una lista dirigida de aristas etiquetadas es un equivalente aceptable a un grafo dibujado.

Toda arista permitida y toda ruta de fallo declarada debe aparecer como fila. «Sigue la transición de rechazo especificada» no es una fila.

593. Responsabilidad de decisión y resolución con autoridad

El controlador de decisiones puede seleccionar ATTACK y emitir una solicitud de ataque. En ese momento ha elegido un comportamiento y producido una salida. No necesariamente ha resuelto el daño.

El sistema de combate con autoridad todavía debe validar la solicitud conforme a las reglas aplicables antes de modificar la salud. Del mismo modo, una animación puede representar un ataque sin decidir si hubo daño.

En esta lección debes identificar estas responsabilidades al nivel del contrato:

• el controlador de decisiones selecciona el estado de comportamiento;
• las solicitudes de movimiento, combate y presentación son salidas;
• el sistema responsable de una consecuencia valida y resuelve esa consecuencia.

Los diagramas detallados de límites entre subsistemas y los criterios de aceptación de transiciones corresponden a la siguiente lección.

594. Comportamiento de fallo

El comportamiento de fallo debe formar parte del contrato, no quedar como una suposición implícita de la implementación. Define qué ocurre cuando:

• falta la referencia al objetivo o deja de ser válida;
• falla una solicitud de movimiento;
• se rechaza una solicitud de ataque;
• el objetivo permanece fuera de la vista más allá del intervalo definido;
• se alcanza el límite de persecución.

Una alternativa debe conservar un estado de juego válido. Si se rechaza un ataque, la salud no cambia. Un fallo de movimiento no debe provocar reintentos silenciosos sin límite. La ausencia de objetivo debe conducir a un estado o una alternativa declarados, no a un objetivo inventado.

Para cada fallo, pregunta:

1. ¿En qué estado puede ocurrir?
2. ¿Cómo se observa?
3. ¿Qué salida se detiene o cambia?
4. ¿Qué estado o alternativa declarada viene después?

Si el contrato no permite responder «¿qué ocurre después?», está incompleto.

595. Errores habituales

Tratar los estados como nombres de animaciones

ATTACK_ANIMATION describe la presentación, no por qué se permite un ataque, qué componente lo solicitó ni qué ocurre si se rechaza.

Usar intenciones como condiciones

«Cuando el enemigo se siente amenazado» no es inspeccionable. Reescribe la frase mediante hechos observables, como un evento detectado, una distancia, un temporizador o un umbral declarado.

Omitir el grafo

Una tabla puede parecer completa y aun así ocultar un estado inalcanzable, una ruta de fallo ausente o un estado sin salida. Compara la tabla y el grafo conexión por conexión.

Confundir una salida con una consecuencia

«Solicitar un ataque» es una salida. «Reducir la salud del objetivo» es una consecuencia de combate que requiere autoridad. No son equivalentes.

Usar responsabilidad y autoridad como sinónimos

Un componente puede ser responsable de seleccionar ATTACK sin tener autoridad para modificar la salud. La selección del estado y la resolución de la consecuencia son afirmaciones distintas.

596. Práctica guiada

Especifica un enemigo pequeño que:

• comienza sin objetivo;
• detecta al jugador a una distancia definida;
• se acerca, pero solo ataca dentro de un alcance definido;
• pierde al jugador después de una duración concreta sin verlo;
• deja de perseguir al alcanzar un límite definido.

Primero, completa una tabla de contratos con al menos cuatro estados y las seis columnas utilizadas en esta lección.

Después, dibuja el grafo dirigido correspondiente o entrega una lista dirigida de aristas etiquetadas. Incluye todos los estados de la tabla, marca el estado inicial y etiqueta cada conexión con una condición medible.

A continuación, señala un estado, una condición de transición y una salida.

Por último, decide si perder el objetivo conduce a SEARCH, RETURN o IDLE. Justifica la elección según el comportamiento deseado del encuentro e incluye la ruta elegida en ambos artefactos.

597. Validación y evidencias

598. Ideas clave

• Sustituye «una IA más inteligente» por estados, transiciones y salidas observables.
• Un contrato de estado define entrada, salida observable, condiciones de salida, responsabilidad de decisión y tratamiento de fallos.
• La tabla especifica los contratos; el grafo revela las rutas permitidas y las conexiones ausentes.
• Ser responsable de seleccionar ATTACK no concede autoridad para resolver el daño.
• Cada fallo importante necesita una ruta o alternativa deliberada.

599. Siguiente lección

Continúa con 2.2 L2 — Separar la decisión de la ejecución.

600. Comprobación