Un jefe es un contrato legible

642. Identidad de la lección

Módulo

2.4 — Diseño de jefes

Lección

Un jefe es un contrato legible

Tipo académico

Concepto

Tipo de esquema

texto

Orden

1 del módulo

Tiempo estimado

25–35 minutos

Esta lección establece el contrato de diseño que hace legible un encuentro con un jefe antes de implementar sus comportamientos.

643. Objetivo de aprendizaje

Después de esta lección, podrás definir la promesa de un jefe y convertirla en una estructura de fases con una escalada justificada y señales accesibles y legibles.

644. Por qué importa

Un jefe no es simplemente un enemigo con más salud, más daño o mayor tamaño visual. Es un desafío concentrado que comunica qué dominio exige el encuentro y cómo cambia esa exigencia con el tiempo. Sin una promesa clara, añadir ataques suele producir ruido en lugar de profundidad.

Un contrato legible también establece límites útiles para la implementación. Los comportamientos solo pueden diseñarse y construirse con criterio cuando están explícitas la decisión del jugador, la función de cada fase, la escalada y las necesidades de señalización.

645. Conocimientos previos

Debes poder:

• Describir las responsabilidades de los actores y la orquestación del encuentro vistas en el módulo 2.3.
• Separar las responsabilidades del tablero de encuentro de las de los actores individuales.
• Identificar la acción del jugador, la respuesta del enemigo y el cambio de estado dentro de un encuentro.
• Describir un desafío a partir de las decisiones del jugador, no solo de sus detalles de implementación.

646. Concepto central

Un jefe es un contrato legible entre el juego y el jugador:

1. Promesa: ¿Qué desafío distintivo debe resolver el jugador?
2. Fases: ¿Cómo se desarrolla ese desafío durante el encuentro?
3. Escalada: ¿Qué aumenta la exigencia sin volver arbitrarias las reglas?
4. Señales: ¿Cómo se comunican el estado, la intención, el peligro, la recuperación y las transiciones?

Un enemigo grande puede tener estadísticas elevadas y aun así no cumplir esta función. Un jefe merece ese papel cuando el jugador puede formular una hipótesis útil, actuar a partir de ella, observar el resultado y ajustar su hipótesis a medida que escala el encuentro.

La promesa debe ser lo bastante específica para orientar el diseño. “Luchar contra un enemigo poderoso” no es una promesa útil. “Leer ataques de área retardados mientras conservas una ruta segura” sí lo es, porque identifica una decisión recurrente del jugador.

Las fases deben mantener una relación reconocible con esa promesa. Una fase posterior puede añadir presión, eliminar una opción fiable, alterar el ritmo o combinar exigencias conocidas. No debería sustituir el encuentro por un desafío sin relación, a menos que el cambio sea deliberado y se comunique con claridad.

647. Modelo mental

Usa la tabla Promesa–Fase–Señal:

El modelo Enseñar–Poner a prueba–Escalar asigna tres funciones útiles:

• Enseñar: presentar la exigencia central con espacio suficiente para observarla.
• Poner a prueba: variar el ritmo, la posición o las combinaciones sin abandonar la lógica subyacente.
• Escalar: aumentar la presión mediante un cambio deliberado que pueda identificarse.

Son funciones de diagnóstico, no un número obligatorio de fases para el encuentro final. Una fase puede cumplir más de una función, y un encuentro más largo puede dedicar varias fases a la misma función. Lo importante es relacionar cada fase con un propósito y explicar cómo la estructura completa enseña, pone a prueba y escala la promesa.

648. Regla de accesibilidad para las señales

La información crítica no debe depender únicamente del color ni de un solo canal sensorial. La intención, el peligro y las transiciones deben usar señales redundantes cuando perder una de ellas impediría tomar la decisión prevista.

Algunas combinaciones útiles son:

• Forma o símbolo más color.
• Movimiento o animación más una señal sonora.
• Límite espacial más un pulso temporizado.
• Texto o icono en pantalla más un sonido no verbal.

Redundancia no significa añadir efectos sin relación. Las señales combinadas deben comunicar el mismo estado y aparecer con suficiente anticipación para conservar la ventana de respuesta prevista. El diseño también debe indicar si esa ventana sigue siendo utilizable con los ajustes de accesibilidad compatibles que alteren la presentación, como movimiento reducido, colores alternativos, subtítulos o menor intensidad de efectos. Si todavía no se sabe, debe anotarse como una necesidad de prueba en lugar de asumir que la señal funciona.

649. Ejemplo concreto

Imagina un jefe cuya promesa es: mantener una ruta segura mientras lees impactos retardados en el suelo.

• Fase 1 — Establecer: El jefe marca una zona, espera y golpea después de un retraso constante. El jugador aprende que la marca es una advertencia y no daño inmediato.
• Fase 2 — Presionar: Se marcan dos zonas en momentos distintos. El jugador debe elegir una ruta en lugar de alejarse sin más de la primera advertencia.
• Fase 3 — Escalar: El jefe cierra brevemente una ruta antes de marcar una zona. El jugador debe leer tanto la posición del jefe como la advertencia del suelo, mientras se conserva el lenguaje de señales anterior.

La misma habilidad prometida—leer y conservar una ruta segura—se aplica bajo restricciones más severas. Una advertencia de peligro podría combinar la forma diferenciada del límite y un movimiento de expansión con un sonido sincronizado. Una transición de fase podría combinar un cambio de postura con una señal sonora y una breve ventana de recuperación. El color puede reforzar estas señales, pero no debe transmitir por sí solo la información crítica.

El diseño debe comprobar que el movimiento reducido, los colores alternativos, los subtítulos u otros ajustes compatibles no eliminen la advertencia ni reduzcan su ventana de respuesta útil. Por ejemplo, si el movimiento reducido suprime la animación de expansión, la forma del límite y el sonido sincronizado todavía deben comunicar la zona afectada y el momento del impacto.

650. Errores comunes

Escalar el contenido en lugar de las decisiones

Una lista de ataques cada vez más espectaculares añade contenido, pero no necesariamente profundiza la decisión prometida. Si una mecánica nueva no se relaciona con la promesa, el jugador debe adivinar si las reglas anteriores siguen vigentes. La confusión no equivale automáticamente a una dificultad significativa.

Tratar las señales como decoración

Una advertencia que aparece cuando el jugador ya no puede responder no es una señal legible. El momento de la señal forma parte de la mecánica y no es solo una cuestión de acabado.

Depender de una sola señal

Una zona peligrosa comunicada solo con el color rojo puede resultar ambigua con ajustes de color alternativos. Una transición comunicada solo mediante sonido puede pasar inadvertida si el audio no está disponible. La información crítica necesita una combinación redundante adecuada para su función.

Considerar obligatorias las tres fases

Enseñar–Poner a prueba–Escalar es una estructura de diagnóstico. Forzar todos los encuentros a tener exactamente tres fases puede crear transiciones innecesarias o dividir de forma arbitraria una función coherente.

651. Práctica guiada

Prepara un contrato de una página para un encuentro inventado con un jefe. No escribas código.

1. Formula la promesa en una frase mediante una decisión recurrente del jugador, no una estadística.
2. Esboza las fases e indica qué función de Enseñar–Poner a prueba–Escalar cumple cada una. Puedes usar la estructura de tres fases o justificar otra cantidad.
3. Describe para cada fase la decisión recurrente, su propósito y la nueva presión.
4. Identifica señales para la intención del jefe, el peligro y la transición de fase.
5. Especifica al menos una combinación redundante para comunicar información crítica. No dependas solo del color.
6. Indica si la ventana de respuesta sigue siendo utilizable con los ajustes de accesibilidad compatibles que sean relevantes. Si no se sabe, define qué debe probarse.
7. Explica qué permanece constante entre las fases.
8. Elimina un ataque que no apoye la promesa o explica con precisión cómo la refuerza.

Usa esta plantilla:

Promesa del jefe:
Decisión recurrente del jugador:

Cantidad de fases y justificación:

Fase:
- Función de Enseñar/Poner a prueba/Escalar:
- Decisión del jugador:
- Propósito de la fase:
- Presión nueva:
- Señal de intención:
- Señal de peligro:
- Señal de transición:

Elemento constante entre fases:

Combinación redundante para información crítica:
- Señal 1:
- Señal 2:
- Información compartida:

Ventana de respuesta con ajustes de accesibilidad compatibles:
- Utilizable, no utilizable o requiere pruebas:
- Justificación o prueba necesaria:

Ataque eliminado o justificado:
Justificación de la escalada:

La decisión central consiste en aumentar la presión temporal, la presión espacial, las combinaciones de decisiones o las restricciones sobre la recuperación sin abandonar la promesa.

652. Validación y evidencia

653. Puntos clave

• Un jefe se define por un desafío distintivo para el jugador, no por su tamaño o sus estadísticas.
• Las fases deben cumplir funciones claras de Enseñar–Poner a prueba–Escalar, pero no tienen que ser exactamente tres.
• La escalada modifica la presión mientras conserva una promesa reconocible.
• Las señales críticas deben ser redundantes y no depender solo del color.
• El momento de la señal debe conservar una ventana de respuesta utilizable con los ajustes de accesibilidad compatibles pertinentes.
• Los comportamientos que no sirven al contrato deben eliminarse o justificarse.

654. Siguiente lección

Continúa con 2.4 L2 — Diseñar fases sin crear un segundo sistema de combate.

655. Comprobación