Guía del sistema de daño, salud, muerte y respawn de Unreal

Respuesta directa

Mantén la salud en un único componente de jugabilidad autoritativo, acepta daño mediante una solicitud tipificada, limita el valor una sola vez y emite eventos de cambio de estado para la interfaz de usuario y los efectos. La muerte debe ser una transición idempotente que desactive más jugabilidad, limpie efectos temporales, registre al asesino o la causa y pida a GameMode o a la capa de reglas propietaria que reaparezca un nuevo peón. Nunca permitas que la barra de salud, el ragdoll o la llamada de destrucción se conviertan en la fuente de verdad.

Esta página cubre el ciclo de vida del combate. No reemplaza una implementación completa de Gameplay Ability System, un sistema de armas, la persistencia de checkpoints ni una guía de analíticas de plataforma. El objetivo práctico es una porción de construcción de juego que otro desarrollador pueda reproducir desde un checkout limpio. Mantén separados el comportamiento del motor, la política del proyecto y la evidencia medida: la documentación de Epic establece los conceptos soportados, el proyecto define propiedad y presupuestos, y solo una ejecución de prueba con nombre demuestra el resultado local.

Lo que ofrece esta guía

• Un modelo de propiedad concreto para sistema de daño, salud, muerte y reaparición de unreal.
• Un flujo de trabajo de implementación en seis etapas en Blueprint/C++ con un ejemplo real de API o comando.
• Tres escenarios de producción, incluyendo comportamiento normal, de borde y de transferencia.
• Criterios de recuperación de fallos y validación para builds de editor y empaquetadas.
• Una entrega de SEELE acotada que conduce al creador de Unreal sin cambiar la intención técnica de esta página.

Arquitectura del sistema y propiedad

Solicitud de daño

Usa ApplyDamage, ApplyPointDamage, ApplyRadialDamage o una struct de proyecto que lleve instigator, causer, tags, datos de impacto y magnitud base. Separa la solicitud del delta final de salud para que la armadura y la inmunidad sigan siendo observables.

Revisión de la solicitud de daño: captura la solicitud de daño, instigador, causante y tipo y muestra cómo la autoridad de salud recibe u observa el resultado aceptado sin convertirse en un segundo propietario.

Autoridad de salud

Un HealthComponent replicado o un conjunto de atributos posee la salud actual y máxima, el clamped, la invulnerabilidad, las comprobaciones de equipo y las notificaciones de cambio. La interfaz de usuario se suscribe a los resultados y nunca escribe la salud directamente.

Revisión de autoridad de salud: captura el delta previo a mitigación y el final y muestra cómo la transición de muerte recibe u observa el resultado aceptado sin convertirse en un segundo propietario.

Transición de muerte

Cambia de Alive a Dying o Dead una sola vez, rechaza el daño posterior, detén input y habilidades, limpia temporizadores, desacopla o desactiva colisión de forma deliberada, y elige ragdoll, animación o desaparición como presentación.

Revisión de transición de muerte: Captura una sola transición de estado de vida y muestra cómo las reglas de respawn reciben u observan el resultado aceptado sin convertirse en un segundo propietario.

Reglas de respawn

GameMode u otro propietario de reglas con autoridad define el tiempo, PlayerStart, clase de pawn y estado de player retenido. El Controller y el PlayerState pueden sobrevivir mientras un pawn muerto se destruye y reemplaza.

Revisión de reglas de respawn: captura la limpieza de temporizador y efectos en EndPlay y muestra cómo la solicitud de daño recibe u observa el resultado aceptado sin convertirse en un segundo propietario.

Flujo de trabajo de implementación

1. Etapa 1: Define tipos de daño o gameplay tags para flujos de daño ambiental, melee, proyectil, explosivo y curación, incluyendo política de fuego amigo e invulnerabilidad.
2. Etapa 2: Implementa una única función de mutación de salud con autoridad del servidor que valide la solicitud, calcule mitigación, restrinja la salud y registre valores antes y después.
3. Etapa 3: Emite un evento estructurado de cambio de salud para HUD, reacciones de impacto, audio y telemetría. Los consumidores reciben el resultado y la causa, pero no pueden aplicar un segundo delta.
4. Etapa 4: Haz que HandleDeath sea idempotente, cancela el trabajo de combate activo, desactiva interacción y movimiento, y almacena suficientes datos de causa para un feed de bajas o una pantalla de reinicio.
5. Etapa 5: Programa la reaparición a través de GameMode, selecciona un inicio válido, genera y posees el pawn de reemplazo, e inicializa la salud antes de devolver el control.
6. Etapa 6: Prueba impactos simultáneos, curación en cero, sobrekill, daño radial repetido, desconexión durante la muerte, travel sin cortes, falta de PlayerStart y suscripción tardía de UI.

Ejemplo concreto de API o comando

float UHealthComponent::ApplyHealthDelta(float Delta, AController* Instigator)
{
    if (LifeState != ELifeState::Alive || FMath::IsNearlyZero(Delta)) return 0.f;
    const float Before = Health;
    Health = FMath::Clamp(Health + Delta, 0.f, MaxHealth);
    OnHealthChanged.Broadcast(Before, Health, Instigator);
    if (Health <= 0.f) EnterDeathOnce(Instigator);
    return Health - Before;
}

Tres escenarios de producción

Ejemplo 1: daño puntual en la cabeza

El resultado de impacto y el tipo de daño identifican una superficie o hueso de la cabeza; el servidor calcula el modificador y registra un único delta final. El arma no escribe Salud y el HUD no vuelve a calcular el multiplicador.

La evidencia de un headshot de daño puntual debe incluir solicitud de daño, instigador, causante y tipo, la identidad de build propietaria y la condición que devuelve este escenario a su último estado conocido correcto.

Ejemplo 2: volumen de daño prolongado

Un efecto con temporización controla su cadencia e identidad de origen. Abandonar el volumen o morir cancela el identificador para que un peón reaparecido no herede ticks obsoletos.

La evidencia para el volumen de daño continuo debe incluir el delta previo a mitigación y el final, la identidad de build propietaria y la condición de que este escenario retorna a su último estado conocido como bueno.

Ejemplo 3: reaparición cooperativa

PlayerState mantiene la puntuación y el equipo, GameMode espera la demora definida por la regla, encuentra un punto de inicio válido para el equipo y posee un peón nuevo. Una cámara de espectador permanece en presentación.

La evidencia de respawn cooperativo debe incluir una sola transición de estado de vida, la identidad de compilación propietaria y la condición que devuelve este escenario a su último estado conocido bueno.

Modos de fallo y recuperación

La muerte se ejecuta dos veces

Bloquea la transición de estado antes de reproducir efectos, otorgar puntuación o programar respawn. Las devoluciones de daño simultáneas deben converger en una sola transición.

Antes de cerrar 'la muerte se ejecuta dos veces', vuelve a ejecutar el headshot de daño puntual y demuestra que la transición única de estado de vida vuelve al límite esperado sin un paso de reparación no documentado.

La barra de salud se actualiza pero la salud del servidor no

Inspecciona el componente propietario y la notificación de replicación. La animación de un widget local no es evidencia de un resultado de daño confirmado.

Antes de cerrar las actualizaciones de la barra de salud si el servidor no refleja la salud, vuelve a ejecutar el volumen de daño continuo y demuestra que el temporizador y la limpieza del efecto regresan al límite esperado en EndPlay sin un paso de reparación sin documentar.

El pawn repuesto mantiene temporizadores antiguos

Ten en propiedad los temporizadores y efectos en el pawn o en el componente, límpialos en EndPlay y muerte, y evita callbacks que referencien de forma fuerte a un pawn destruido.

Antes de cerrar, el pawn reaparición mantiene los temporizadores antiguos, vuelve a ejecutar la reaparición cooperativa y demuestra que la selección de spawn, la posesión y la salud inicializada vuelven al límite esperado sin un paso de reparación no documentado.

El jugador reaparece dentro de geometría

Valida la ocupación de PlayerStart, proporciona una política de selección de respaldo y registra el start elegido y el resultado del manejo de colisión en spawn.

Antes de cerrar el spawn del jugador dentro de la geometría, vuelve a ejecutar el headshot de daño puntual y demuestra que la solicitud de daño, instigator, causer y tipo regresan al límite esperado sin un paso de reparación no documentado.

Matriz de validación

• solicitud de daño, instigador, causante y tipo: Revísalo junto con la solicitud de daño; aprueba solo cuando la muerte se ejecuta dos veces no vuelva a ocurrir durante un headshot de daño puntual y la evidencia mencione exactamente el build.
• delta de mitigación previa y delta final: revísalo junto con la autoridad de salud; pasa solo cuando las actualizaciones de la barra de salud pero no la salud del servidor no se repiten durante el volumen de daño por tiempo y la evidencia nombra la build exacta.
• transición única de estado de vida: Revísalo junto con la transición de muerte; aprueba solo cuando el pawn reaparición conserva temporizadores antiguos no vuelva a ocurrir durante la reaparición cooperativa y la evidencia mencione exactamente el build.
• temporizador y limpieza de efecto en EndPlay: Revísalo junto con las reglas de reaparición; aprueba solo cuando el spawn del jugador dentro de la geometría no vuelva a repetirse durante un headshot de daño puntual y la evidencia indique exactamente el build.
• selección de spawn, posesión y salud inicial: Inspecciona junto a la solicitud de daño; aprueba solo cuando la muerte se ejecuta dos veces y no se repite durante el volumen de daño prolongado y la evidencia nombra la compilación exacta.

Presentación y autoridad: verifica únicamente que múltiples interacciones por pulsación no se dispare más de una vez durante la puerta con estado de bloqueo y que las evidencias indiquen la build exacta.

Estos pasos apuntan a la superficie de documentación actual de Unreal Engine 5 al 2026-07-26. Los valores predeterminados del motor, el estado experimental, el empaquetado de plugins, las firmas de API y el soporte de plataforma pueden cambiar. Selecciona la versión de documentación que coincida con el proyecto, prueba el parche exacto y destino objetivo, y conserva una revisión de reversión. La documentación pública no sustituye los requisitos de NDA de plataforma, revisión de tienda, certificación de consola o evidencia de rendimiento específica del proyecto.

Fuentes oficiales

• Sistema de daño de juego — evidencia fuente para la solicitud de daño en este flujo del sistema de daño, salud, muerte y reaparición de unreal; verifica la versión de la documentación con respecto a la rama de shipping.
• Referencia rápida de Gameplay Framework — fuente de evidencia de autoridad de salud en este flujo de trabajo del sistema de daño, salud, muerte y respawn de Unreal; verifica la versión de la documentación frente a la rama shipping.
• Actor de inicio de jugador — evidencia fuente para la transición de muerte en este flujo de daño, salud, muerte y respawn de Unreal; verifica la versión de la documentación contra la rama shipping.

Unreal Engine es una marca registrada de Epic Games. SEELE AI es independiente y este artículo no implica respaldo de Epic Games ni de Valve.

Del plan técnico a un juego de Unreal de SEELE

Utiliza esta página para definir el sistema, las pruebas de aceptación y los límites de fallo; luego lleva ese planteamiento preciso al [creador de juegos Unreal de SEELE](/features/create/unreal-game). SEELE puede generar un juego nativo de Unreal 5, proporcionar una vista previa en el navegador, soportar la optimización y empaquetado en SEELE, y permitirte descargar el proyecto o el resultado empaquetado para publicación externa o publicarlo como un juego SEELE gratuito o de pago.

Esa entrega no cambia la responsabilidad de producción nativa descrita anteriormente. La aprobación de la tienda, ventas, ingresos, certificación, compatibilidad con complementos de terceros y cumplimiento de la plataforma no están garantizados. Mantén el juego de Unreal de origen, registros de compilación, evidencia de prueba y decisiones de publicación externa bajo el control de tu equipo.

FAQ

¿Cuál es la arquitectura correcta para un sistema de daño, salud, muerte y respawn en Unreal?

Mantén la salud en un solo componente de gameplay con autoridad, acepta daño mediante una solicitud tipada, limita el valor una vez y emite eventos de cambio de estado para UI y efectos. La muerte debe ser una transición idempotente que deshabilite más gameplay, limpie efectos temporales, registre al asesino o la causa y solicite a GameMode o a la capa de reglas propietaria que respawnee un nuevo pawn. Nunca dejes que la barra de salud, el ragdoll o la llamada de destrucción se conviertan en la fuente de verdad. Comienza con solicitud de daño y autoridad de salud, y luego trata la presentación como observadora del estado de gameplay ya confirmado.

¿El sistema de daño, salud, muerte y respawn de Unreal debe construirse en Blueprint o en C++?

Ambos pueden funcionar. Blueprint es efectivo para lógica de juego rápida y para la iteración de los diseñadores; C++ es útil para contratos reutilizables, ciclos de vida complejos, bucles sensibles al rendimiento y pruebas automatizadas. Mantén los mismos límites de propietario, validación, fallo y recuperación en ambos.

¿Cómo se debe probar un sistema de daño, salud, muerte y respawn en Unreal?

Prueba un caso normal, una entrada inválida, una interrupción o desmontaje, reinicio limpio y paridad de compilación empaquetada. Captura la solicitud de daño, instigador, causante y tipo, la mitigación previa y el delta final, una sola transición de estado de vida con un identificador de compilación y criterios de aprobación explícitos.

¿Cuál es el fallo más peligroso en el sistema de daño, salud, muerte y respawn de Unreal?

La muerte ejecutada dos veces es una señal de alarma temprana: protege la transición de estado antes de reproducir efectos, otorgar puntuación o programar la reaparición. Las callbacks de daño simultáneas deben converger en una sola transición. También verifica la limpieza y el reintento para que la corrección aparente no deje estado obsoleto.

¿A qué versión de Unreal se dirige esta guía del sistema de daño, salud, muerte y reaparición de unreal?

Utiliza la superficie de documentación de Unreal Engine 5 disponible al 2026-07-26. Confirma el selector de versión, la firma de la API, el estado de los plugins, la toolchain de plataforma y el comportamiento empaquetado en el parche exacto del motor que se enviará.

¿Qué puede hacer SEELE AI después de que este plan del sistema de daño, salud, muerte y reaparición de unreal esté listo?

SEELE puede generar un juego nativo de Unreal 5, proporcionar previsualización en el navegador, soportar optimización y empaquetado, y proporcionar descargas del proyecto o empaquetado para publicación externa o un lanzamiento gratuito o de pago de SEELE. No garantiza la aprobación de tiendas de terceros, compatibilidad, ventas o ingresos.