Diseñar fases sin crear un segundo sistema de combate | Curso de desarrollo de videojuegos con IA

656. Identidad de la lección

Módulo: 2.4 — Diseño de jefes
Lección: Diseñar fases sin crear un segundo sistema de combate
Tipo académico: Sistemas
Tipo de esquema: texto
Orden: 2 del módulo
Tiempo estimado: 35–45 minutos, incluida la práctica

657. Objetivo de aprendizaje

Al terminar esta lección, podrás elaborar una tabla de fases que especifique el activador de cada fase, los invariantes de combate que se conservan, la retroalimentación visible para el jugador, la ruta de recuperación y la responsabilidad de los sistemas de combate, encuentro, jefe y presentación.

658. Por qué importa

Un cambio de fase debe volver más exigente, más claro o más preciso el contrato de combate existente; no debe sustituirlo por un juego distinto. Reutilizar reglas de combate ya conocidas reduce la carga cognitiva del jugador y el riesgo de implementación para el equipo. Una responsabilidad clara evita que la lógica de fase duplique la resolución de combate o que la presentación se convierta en la fuente de verdad del juego. También proporciona a un colaborador de programación basado en IA una especificación acotada, en lugar de una invitación a añadir ataques, estados o recursos sin límite.

659. Conocimientos previos

Debes poder identificar la promesa de un jefe, la decisión del jugador, una amenaza legible y un error que pueda castigarse, tal como se trabajó en 2.4 L1 — Un jefe es un contrato legible. También debes conocer las reglas de combate y las convenciones de retroalimentación establecidas anteriormente en la Etapa 2.

660. Concepto central

Una fase de jefe es una variación controlada de un contrato existente. Puede cambiar el ritmo, la posición, la secuencia o la presión, pero debe conservar la decisión central del encuentro, salvo que el diseño declare de forma explícita un contrato nuevo. Toda fase necesita cuatro elementos:

Activador: la condición que inicia la fase.
Invariantes: las reglas que siguen siendo verdaderas durante la transición.
Retroalimentación: lo que comunica al jugador que la fase cambió y qué decisión se espera ahora.
Recuperación: la forma en que el jugador y el jefe regresan a un estado de combate estable y legible.

También necesita una asignación explícita de responsabilidades:

Combate resuelve: la detección de impactos, la aplicación de daño, la invulnerabilidad, la interrupción y la muerte siguen bajo la autoridad del sistema de combate.
Encuentro coordina: los activadores de fase, la secuencia, las condiciones de la arena y el ritmo de la conducta del jefe pertenecen a la capa del encuentro.
Jefe expresa la intención: el jefe selecciona o expone un patrón de ataque, una elección de movimiento o una conducta de recuperación dentro de los contratos de combate existentes.
Presentación comunica: la animación, el sonido, los efectos, la interfaz y las señales de la arena comunican cambios de estado, pero no deciden si hubo impacto o daño.

La tabla de fases hace visibles tanto el cambio de diseño como los límites entre sistemas antes de comenzar la implementación.

661. Modelo mental

Usa la Prueba de Diferencia y Responsabilidad de Fase:

Pregunta	Comprobación de diseño	Responsable
¿Qué cambia?	Nombra una o dos variables: ritmo, posición, secuencia, cobertura o ventana de recuperación.	Encuentro o jefe, según se trate de coordinación o intención
¿Qué permanece?	Conserva la promesa del jefe, los controles del jugador, la lógica de daño y el lenguaje reconocible de la amenaza, salvo que exista una razón deliberada para cambiarlos.	Contratos de combate y del jefe
¿Quién resuelve la interacción?	Confirma que la detección de impactos, el daño, la interrupción, la invulnerabilidad y la muerte siguen pasando por la resolución de combate establecida.	Combate
¿Cómo lo sabe el jugador?	Especifica una animación, sonido, cambio de arena, señal temporal u otra retroalimentación observable.	Presentación, dirigida por el estado del encuentro o del jefe
¿Cómo se recupera el combate?	Define la ventana de recuperación, el estado seguro, la interrupción o la condición de retorno.	Jefe y encuentro; combate conserva la autoridad sobre los resultados

Una fase funciona cuando su diferencia es significativa, sus invariantes mantienen reconocible el encuentro y cada sistema tiene una responsabilidad clara. La presentación puede revelar una fase, pero no debe crearla silenciosamente. La lógica del jefe puede solicitar un ataque, pero no debe aplicar daño saltándose la resolución de combate.

662. Ejemplo concreto

Supón que el contrato del jefe es: el jugador debe leer una embestida telegrafiada, apartarse de su trayectoria y castigar la ventana de recuperación.

Fase	Activador	Qué cambia	Invariantes	Retroalimentación	Recuperación	Responsabilidades
1 — Establecimiento	Inicio del encuentro	Ritmo estándar de la embestida y una ventana de recuperación	La embestida sigue estando telegrafiada; el movimiento y las reglas para castigar no cambian; el daño lo resuelve el combate	Animación clara de preparación y sonido de impacto distintivo	El jefe queda vulnerable después de la embestida	El encuentro inicia la fase; el jefe solicita la embestida; el combate resuelve contacto y daño; la presentación comunica la amenaza
2 — Compresión	El jefe llega al 60 % de salud	La preparación es más corta y aparece un segundo carril posible	La embestida conserva una advertencia legible; el jugador sigue escapando al leer la dirección; se aplican las mismas reglas de daño	La animación de preparación es más breve, pero mantiene su silueta; una marca de arena identifica el carril	El jefe no puede encadenar otra embestida de inmediato; vuelve a una posición neutral	El encuentro evalúa el activador de salud; el jefe selecciona el carril; el combate resuelve la embestida; la presentación señala el carril y el ritmo modificados
3 — Negación de la repetición	El jefe llega al 25 % de salud	El jefe puede invertir una vez su dirección después de fallar, cambiando el ritmo del castigo	El jugador sigue leyendo la dirección antes de comprometerse; el daño, las reacciones al impacto y los controles no cambian; el daño del jefe no evita la resolución de combate	Un sonido agudo y un giro visible señalan la inversión	Si la inversión falla, termina en el mismo estado de recuperación que la embestida original	El jefe controla la intención de invertir; el combate resuelve cualquier impacto; la presentación comunica la inversión; el encuentro impide una cadena inmediata e ilimitada

Este diseño aumenta la exigencia mediante el ritmo y la secuencia. No añade una barra de resistencia, una interacción de arma ni un sistema de movimiento separado. El jugador sigue resolviendo el problema original —leer, esquivar, castigar— en una versión más exigente del mismo contrato. La columna de responsabilidades también evita un error de implementación frecuente: el controlador del jefe puede solicitar o describir un ataque, pero el sistema de combate conserva la autoridad para decidir si impacta y cuánto daño produce.

663. Error común

El error habitual es tratar una fase como permiso para añadir contenido en vez de como un cambio de diseño controlado con límites claros entre sistemas. Un diseñador puede añadir proyectiles, invocaciones, un recurso nuevo y una regla nueva para la arena porque el jefe necesita sentirse diferente. Después, quien implementa puede permitir que el controlador del jefe aplique daño directamente o que un efecto visual determine un impacto. El resultado suele ser un segundo sistema de combate que compite con la promesa original y dificulta diagnosticar los fallos.

Evalúa cada característica propuesta con dos preguntas: ¿profundiza la decisión existente del jugador o le pide aprender un juego diferente? y ¿qué sistema es responsable de la decisión, la resolución y la comunicación? Si crea un juego diferente, elimínala, posponla o rediseña explícitamente el contrato del jefe antes de implementarla. Si duplica la resolución de combate, haz que pase por la autoridad de combate ya establecida.

664. Práctica guiada

Crea una tabla de fases para un jefe hipotético usando este contrato:

El jugador espera una apertura legible, evita un ataque comprometido y utiliza la ventana de recuperación del ataque para infligir daño.

Diseña tres fases. Para cada una, escribe:

el activador;
una variable que cambie;
al menos dos invariantes que permanezcan;
la retroalimentación que recibe el jugador antes o durante el cambio;
la condición de recuperación que devuelve el combate a un estado estable;
quién es responsable del activador, de la intención del jefe, de la resolución de combate y de la señal de presentación.

Después aplica la Prueba de Diferencia y Responsabilidad de Fase. Clasifica cada cambio propuesto como uno de estos tipos:

Profundiza: aumenta la presión de ritmo, posición o secuencia mientras conserva el contrato;
Neutro: cambia la presentación sin cambiar la decisión;
Compite: introduce un sistema de decisión nuevo que puede ocultar el contrato;
Responsabilidad incorrecta: pide al sistema equivocado resolver o comunicar la conducta, como cuando la lógica del jefe aplica daño directamente.

Revisa o elimina todo elemento marcado como Compite o Responsabilidad incorrecta. Tu decisión de diseño principal consiste en elegir qué escalada conservar cuando una característica más elaborada sería más fácil de describir, pero menos coherente con la promesa del jefe, y después asignar cada responsabilidad al sistema correcto.

665. Validación / evidencia

Tu evidencia es una tabla de tres filas, una por fase, con una columna de responsabilidades. Supera la comprobación cuando:

cada fase tiene un activador explícito;
la decisión central del jugador sigue siendo reconocible en todas las fases;
se nombran al menos dos invariantes, en lugar de dejarlos implícitos;
la retroalimentación comunica el cambio antes de que el jugador tenga que resolver la nueva exigencia;
cada fase tiene una ruta de recuperación;
la resolución de combate conserva la autoridad sobre impactos, daño, interrupciones, invulnerabilidad y muerte;
la lógica del jefe describe o solicita la conducta sin saltarse la resolución de combate;
la lógica del encuentro controla la secuencia de fases sin convertirse en un segundo resolvedor de combate;
la presentación comunica cambios de estado sin cambiar silenciosamente las reglas del juego;
ninguna fase requiere un recurso, esquema de controles u objetivo no anunciado y ajeno al contrato;
la tabla puede entregarse a quien implemente el sistema sin depender de frases como «hazlo más intenso».

Una comprobación final útil es ocultar los nombres de las fases y leer solamente las columnas de activador, retroalimentación, recuperación y responsabilidades. Aun así deberías poder explicar qué debe notar el jugador y qué debe hacer, qué sistema inicia el cambio y qué sistema resuelve sus consecuencias.

666. Puntos clave

Una fase de jefe es una variación controlada de un contrato existente, no necesariamente un sistema de combate nuevo.
Los activadores indican cuándo comienza una fase; los invariantes indican qué sigue siendo confiable.
El combate resuelve las interacciones; la lógica del jefe y del encuentro expresan intención y coordinación; la presentación comunica el resultado.
La retroalimentación debe comunicar que la fase cambió y qué decisión importa ahora.
La recuperación evita que la escalada se convierta en confusión permanente o en una cadena de ataques sin límite.
Una tabla de fases convierte la escalada y las responsabilidades de los sistemas en un diseño revisable antes de escribir código.

667. Siguiente lección

Continúa con 2.5 — Inventario, equipamiento y crafting.