— evidência fonte para a escolha de geometria neste fluxo de unreal collision channels traces physical materials; verifique a versão da documentação em relação à branch de shipping.

Resposta direta

Mantenha a saúde em um único componente de gameplay autoritário, aceite dano por meio de uma solicitação tipada, aplique clamp no valor uma única vez e emita eventos de mudança de estado para UI e efeitos. A morte deve ser uma transição idempotente que desative o gameplay adicional, limpe efeitos temporários, registre o assassino ou a causa e peça ao GameMode ou à camada de regras proprietária para respawnar um novo pawn. Nunca deixe a barra de saúde, o ragdoll ou a chamada de destruição tornarem-se a fonte da verdade.

Esta página pertence ao ciclo de vida de combate. Ela não substitui um guia completo de Gameplay Ability System, implementação de armas, persistência de checkpoint ou analytics de plataforma. O objetivo prático é um recorte de construção de jogo que outro desenvolvedor possa reproduzir a partir de um checkout limpo. Mantenha comportamento da engine, política do projeto e evidência medida separados: a documentação da Epic estabelece conceitos suportados, o projeto define propriedade e orçamentos, e apenas uma run de teste nomeada comprova o resultado local.

O que este guia entrega

• Um modelo de propriedade concreto para sistema de dano de saúde, morte e respawn do Unreal.
• Um fluxo de implementação em Blueprint/C++ em seis etapas com exemplo real de API ou comando.
• Três cenários de produção, incluindo comportamento normal, de borda e de handoff.
• Critérios de recuperação de falhas e validação para builds do editor e de pacote.
• Uma transição controlada do SEELE que conduz ao Unreal creator sem alterar a intenção técnica desta página.

Arquitetura e propriedade do sistema

Pedido de dano

Use ApplyDamage, ApplyPointDamage, ApplyRadialDamage ou uma struct de projeto carregando instigator, causer, tags, dados de acerto e magnitude base. Separe o pedido do delta final de saúde para que armadura e imunidade permaneçam observáveis.

Revisão do pedido de dano: capture pedido de dano, instigator, causer e tipo e mostre como a autoridade de saúde recebe ou observa o resultado aceito sem se tornar um segundo dono.

autoridade de saúde

Um HealthComponent replicado ou um conjunto de atributos replicados é dono da saúde atual e máxima, do clamp, da invulnerabilidade, das verificações de equipe e das notificações de alteração. A UI se inscreve nos resultados e nunca escreve saúde diretamente.

Revisão de autoridade de saúde: capture pré-mitigação e delta final e mostre como a transição de morte recebe ou observa o resultado aceito sem se tornar um segundo dono.

Transição de morte

Mude Alive para Dying ou Dead uma vez, rejeite dano posterior, pare input e habilidades, limpe timers, desconecte ou desative colisão deliberadamente, e escolha ragdoll, animação ou desaparecimento como apresentação.

Revisão da transição de morte: capture uma transição única de estado de vida e mostre como as regras de respawn recebem ou observam o resultado aceito sem se tornarem um segundo dono.

Regras de respawn

GameMode ou outro dono de regras autoritativo seleciona tempo, PlayerStart, classe de pawn e estado do jogador retido. Controller e PlayerState podem sobreviver enquanto um pawn morto é destruído e substituído.

Revisão das regras de respawn: capture timer e limpeza de efeito em EndPlay e mostre como o pedido de dano recebe ou observa o resultado aceito sem se tornar um segundo dono.

Fluxo de implementação

1. Etapa 1: Defina tipos de dano ou gameplay tags para fluxos ambientais, melee, projétil, explosivo e cura, incluindo política de dano amigável e de invulnerabilidade.
2. Visual de Inkling 1M Context para seleção de evidências em grandes repositórios Implemente uma única função de mutação de saúde com autoridade no servidor que valide a solicitação, calcule mitigação, aplique clamp na saúde e registre os valores antes e depois.
3. Etapa 3: Faça broadcast de um evento estruturado de alteração de saúde para HUD, reações a hit, áudio e telemetria. Os consumidores recebem o resultado e a causa, mas não podem aplicar um segundo delta.
4. Etapa 4: Torne HandleDeath idempotente, cancele o trabalho de combate ativo, desative interação e movimento e armazene dados de causa suficientes para um kill feed ou tela de reinício.
5. Etapa 5: Programe o respawn pelo GameMode, selecione um início válido, faça spawn e possua o pawn substituto e inicialize a saúde antes de devolver o controle.
6. Etapa 6: Teste hits simultâneos, cura em zero, overkill, dano radial repetido, desconexão durante a morte, seamless travel, PlayerStart ausente e inscrição tardia na UI.

Exemplo concreto de API ou 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;
}

Três cenários de produção

Exemplo 1: Headshot de dano pontual

O resultado do impacto e o tipo de dano identificam uma superfície da cabeça ou osso; o servidor calcula o modificador e registra um único delta final. A arma não escreve Health e o HUD não recalcula o multiplicador.

A evidência para headshot de dano pontual deve incluir solicitação de dano, instigador, causador e tipo, a identidade da build proprietária e a condição que retorna esse cenário ao seu último estado conhecido bom.

Exemplo 2: volume de dano ao longo do tempo

Um efeito com duração possui sua cadência e identidade de origem. Sair do volume ou morrer cancela o handle para que um pawn respawnado não herde ticks antigos.

A evidência de dano contínuo por volume deve incluir pré-mitigação e delta final, a identidade da build proprietária e a condição que retorna esse cenário ao seu último estado conhecido como bom.

Exemplo 3: Respawn cooperativo

PlayerState mantém pontuação e equipe, GameMode aguarda o delay definido pela regra, encontra um spawn válido para a equipe e assume um pawn novo. Uma câmera espectadora permanece apenas de apresentação.

A evidência para co-op respawn deve incluir transição única de estado de vida, identidade do build proprietário e a condição que retorna este cenário ao seu último estado bom conhecido.

Modos de falha e recuperação

A morte acontece duas vezes

Proteja a transição de estado antes de tocar efeitos, conceder pontuação ou agendar respawn. Callbacks de dano simultâneos devem convergir para uma única transição.

Antes de encerrar a morte acontecer duas vezes, reexecute o headshot de dano pontual e prove que a transição única de life-state retorna ao limite esperado sem uma etapa de reparo não documentada.

A barra de vida atualiza, mas a saúde do servidor não

Verifique o componente autoritário e a notificação de replicação. A animação de um widget local não é prova de um resultado de dano comprometido.

Antes de encerrar as atualizações da barra de vida, mas a vida do servidor não, execute novamente o volume de dano ao longo do tempo e comprove que o timer de dano e a limpeza de efeitos no EndPlay retornam ao limite esperado sem uma etapa de correção não documentada.

Peão renascido mantém timers antigos

Possua timers e efeitos no pawn ou componente, limpe-os em EndPlay e na morte, e evite callbacks que façam referência forte a um pawn destruído.

Antes de encerrar, confirme que o pawn respawnado mantém timers antigos, reexecute o respawn cooperativo e prove que a seleção de spawn, a posse e a saúde inicializada retornam ao limite esperado sem uma etapa de reparo não documentada.

Jogador spawna dentro da geometria

Valide a ocupação do PlayerStart, forneça uma política de fallback e registre o início selecionado e o resultado de tratamento de colisão no spawn.

Antes de encerrar o spawn de jogador dentro da geometria, reexecute o headshot de dano pontual e prove que o pedido de dano, instigator, causer e tipo retornam ao limite esperado sem uma etapa de reparo não documentada.

Matriz de validação

• pedido de dano, instigator, causer e tipo: analise junto ao pedido de dano; aprove somente quando a morte acontece duas vezes não se repetir durante headshot de dano pontual e as evidências nomearem a build exata.
• delta pré-mitigação e final: Inspecione-o ao lado da autoridade de saúde; só aprova quando a atualização da barra de vida, mas a saúde do servidor não, não se repete durante o volume de dano ao longo do tempo e a evidência nomeia a build exata.
• transição única de estado de vida: analise junto à transição de morte; aprove somente quando o pawn respawnado manter timers antigos não se repetir durante respawn cooperativo e as evidências nomearem a build exata.
• timer e limpeza de efeitos no EndPlay: analise junto às regras de respawn; aprove somente quando spawn de jogador dentro da geometria não se repetir durante headshot de dano pontual e as evidências nomearem a build exata.
• seleção de spawn, posse e saúde inicial: analise-o ao lado da solicitação de dano; passe apenas quando a morte ocorrer duas vezes sem recorrência durante o volume de dano ao longo do tempo e a evidência citar exatamente o build.

Limites de versão e fonte

Estas etapas visam a superfície de documentação atual do Unreal Engine 5 em 2026-07-26. Padrões do engine, status experimental, empacotamento de plugins, assinaturas de API e suporte a plataforma podem mudar. Selecione a versão da documentação que corresponda ao projeto, teste o patch exato e o alvo, e mantenha uma revisão rollback. Documentação pública não substitui requisitos NDA de plataforma, revisão da loja, certificação de console ou evidência de desempenho específica do projeto.

Fontes oficiais

• Sistema de dano de gameplay — fonte de evidência para pedido de dano neste fluxo do sistema de dano, saúde, morte e respawn do Unreal; verifique a versão da documentação em relação ao branch de shipping.
• Referência rápida do Gameplay Framework — fonte de evidência para autoridade de saúde neste fluxo de sistema de dano, saúde, morte e respawn no Unreal; confira a versão da documentação em relação à branch de shipping.
• Actor Player Start — fonte de evidência para transição de morte neste fluxo do sistema de dano de saúde, morte e respawn do Unreal; verifique a versão da documentação contra o branch de shipping.

Unreal Engine é uma marca registrada da Epic Games. A SEELE AI é independente e este artigo não implica endosso da Epic Games ou da Valve.

Do plano técnico para um jogo Unreal da SEELE

Use esta página para definir o sistema, os testes de aceitação e os limites de falha; em seguida, leve esse briefing preciso para o [criador de jogos Unreal da SEELE](/features/create/unreal-game). A SEELE pode gerar um jogo nativo Unreal 5, fornecer uma prévia no navegador, suportar otimização e empacotamento na SEELE, e permitir que você baixe o projeto ou a saída empacotada para publicação externa ou publique-o como um jogo SEELE gratuito ou pago.

Essa passagem não altera a responsabilidade de produção nativa descrita acima. Aprovação de loja, vendas, receita, certificação, compatibilidade de plugins de terceiros e conformidade de plataforma não são garantidas. Mantenha o jogo Unreal de origem, logs de build, evidências de teste e decisões de publicação externas sob o controle da sua equipe.

FAQ

Qual é a arquitetura correta para o sistema de dano, saúde, morte e respawn no Unreal?

Mantenha a saúde em um único componente de gameplay autoritativo, aceite dano por meio de uma solicitação tipada, aplique clamp no valor apenas uma vez e emita eventos de mudança de estado para UI e efeitos. A morte deve ser uma transição idempotente que desative o gameplay adicional, limpe efeitos temporários, registre o causador da morte e peça ao GameMode ou à camada de regras proprietária para fazer o respawn de um novo peão. Nunca deixe a barra de saúde, o ragdoll ou a chamada de destroy se tornarem fonte da verdade. Comece com solicitação de dano e autoridade de saúde, depois mantenha a apresentação como observadora do estado de gameplay confirmado.

O sistema de dano, saúde, morte e respawn do Unreal deve ser construído em Blueprint ou C++?

Ambos podem funcionar. Blueprint é eficaz para lógica rápida de jogo e iteração de designers; C++ é útil para contratos reutilizáveis, ciclo de vida complexo, loops sensíveis a desempenho e testes automatizados. Preserve os mesmos limites de dono, validação, falha e recuperação em ambos.

Como o sistema de dano, saúde e morte no Unreal deve ser testado?

Teste um caso normal, uma entrada inválida, uma interrupção ou desmontagem, reinício limpo e paridade em build empacotado. Capture solicitação de dano, causador, originador e tipo, pré-mitigação e delta final, transição única de estado de vida com identificador de build e critério explícito de aprovação.

Qual é a falha mais perigosa no sistema de dano, saúde, morte e respawn do Unreal?

A morte acontecer duas vezes é um alerta precoce: proteja a transição de estado antes de tocar efeitos, conceder pontuação ou agendar respawn. Os callbacks de dano simultâneos devem convergir para uma única transição. Também verifique limpeza e retry para que a correção aparente não deixe estado obsoleto.

Para qual versão do Unreal este guia do sistema de dano de saúde, morte e respawn do Unreal é direcionado?

Utiliza a superfície de documentação do Unreal Engine 5 disponível em 2026-07-26. Confirme o seletor de versão, assinatura da API, status do plugin, cadeia de ferramentas da plataforma e comportamento do build empacotado na versão exata do engine que será lançada.

O que a SEELE pode fazer depois que esse plano do sistema de dano de saúde, morte e respawn do Unreal estiver pronto?

A SEELE pode gerar um jogo nativo Unreal 5, fornecer visualização no navegador, suportar otimização e empacotamento, e fornecer downloads do projeto ou empacotados para publicação externa ou um lançamento SEELE gratuito ou pago. Ela não garante aprovação em lojas de terceiros, compatibilidade, vendas ou receita.