Guide visuel de Unreal Damage, Health, Death, and Respawn System

Réponse directe

Conservez la santé dans un seul composant de gameplay auteuritaire, acceptez les dégâts via une requête typée, clampant la valeur une seule fois, et émettez des événements de changement d’état pour l’UI et les effets. La mort doit être une transition idempotente qui désactive toute logique de jeu supplémentaire, nettoie les effets temporaires, enregistre le tueur ou la cause, et demande au GameMode ou à la couche de règles propriétaire de respawner un nouveau pawn. Que la barre de santé, le ragdoll ou l’appel de destruction ne deviennent jamais la source de vérité.

Cette page gère le cycle de vie du combat. Elle ne remplace pas un système complet de Gameplay Ability System, une implémentation d’armes, un guide de persistance des checkpoints, ou un guide d’analytique de plateforme. L’objectif pratique est une tranche de construction de jeu qu’un autre développeur peut reproduire à partir d’un checkout propre. Conservez séparément le comportement moteur, la politique du projet et les preuves mesurées : la documentation Epic établit les concepts supportés, le projet définit la propriété et les budgets, et seule une exécution de test nommée prouve le résultat local.

Ce que ce guide apporte

• Un modèle de propriété concret pour système de dégâts santé mort réapparition unreal.
• Un flux de travail de mise en œuvre Blueprint/C++ en six étapes avec un exemple réel d’API ou de commande.
• Trois scénarios de production, incluant comportement normal, limites, et comportement de passation.
• Critères de récupération d’échec et de validation pour les builds éditeur et packagés.
• Un passage de relais SEELE borné qui mène au créateur Unreal sans modifier l’intention technique de cette page.

Architecture système et propriété

Demande de dégâts

Utilisez ApplyDamage, ApplyPointDamage, ApplyRadialDamage, ou une structure de projet portant instigateur, causeur, tags, données de hit et magnitude de base. Séparez la requête du delta de santé final pour que l’armure et l’immunité restent observables.

Revue de la demande de dégâts : capturez la demande de dégâts, l’instigateur, le causeur et le type et montrez comment l’autorité de santé reçoit ou observe le résultat accepté sans devenir un second owner.

Autorité de santé

Un HealthComponent répliqué ou un set d’attributs détient la santé actuelle et maximale, le clamp, l’invulnérabilité, les vérifications d’équipe et les notifications de changement. L’UI s’abonne aux résultats et ne modifie jamais directement la santé.

Revue de l’autorité de santé : capturez le delta pré-mitigation et le delta final, puis montrez comment la transition de mort reçoit ou observe le résultat accepté sans devenir un second owner.

Transition de mort

Passez de Alive à Dying ou Dead une seule fois, rejetez les dégâts ultérieurs, arrêtez les entrées et les capacités, effacez les timers, détachez ou désactivez délibérément la collision, et choisissez ragdoll, animation ou disparition comme présentation.

Revue de transition de mort : Capturez une transition d’état de vie unique et montrez comment les règles de respawn reçoivent ou observent le résultat accepté sans devenir propriétaire secondaire.

Règles de respawn

Un GameMode ou un autre propriétaire de règles fait autorité pour choisir le timing, le PlayerStart, la classe de pawn et l’état joueur conservé. Le Controller et le PlayerState peuvent survivre tandis qu’un pawn mort est détruit puis remplacé.

Revue des règles de respawn : capturez le timer et le nettoyage des effets à EndPlay et montrez comment la demande de dégâts reçoit ou observe le résultat accepté sans devenir un second owner.

Workflow de mise en œuvre

1. Étape 1 : Définissez des types de dégâts ou des gameplay tags pour les flux environnemental, mêlée, projectile, explosif et soins, y compris la politique de tir allié et d’invulnérabilité.
2. Étape 2 : Implémentez une seule fonction de mutation de santé faisant autorité côté serveur qui valide la demande, calcule la mitigation, borne la santé et enregistre les valeurs avant et après.
3. Étape 3 : Diffusez un événement structuré de changement de santé pour le HUD, les réactions aux coups, l’audio et la télémétrie. Les consommateurs reçoivent le résultat et la cause, mais ne peuvent pas appliquer un second delta.
4. Étape 4 : Rendez HandleDeath idempotent, annulez les tâches de combat actives, désactivez l’interaction et le mouvement, et conservez suffisamment de données de cause pour un kill feed ou un écran de redémarrage.
5. Étape 5 : Programmez la réapparition via le GameMode, sélectionnez un départ valide, faites apparaître et possédez le pawn de remplacement, puis initialisez la santé avant de rendre le contrôle.
6. Étape 6 : Testez les coups simultanés, les soins à zéro, le sur-dégât, les dégâts radiaux répétés, la déconnexion pendant la mort, le seamless travel, l’absence de PlayerStart et l’abonnement tardif à l’UI.

Exemple concret d’API ou de commande

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;
}

Trois scénarios de production

Exemple 1 : Dégâts ponctuels à la tête

Le résultat du tir et le type de dégâts identifient une surface de tête ou un os ; le serveur calcule le modificateur et enregistre un delta final unique. L’arme n’écrit pas la santé et l’HUD ne recalcule pas le multiplicateur.

Les preuves d’un headshot en point damage doivent inclure la demande de dégât, l’instigator, le causer, et le type, l’identité du build propriétaire, ainsi que la condition qui ramène ce scénario à son dernier état connu stable.

Exemple 2 : volume de dégâts sur la durée

Un effet temporel possède son rythme et son identité source. Quitter le volume ou mourir annule le handle afin qu’un pawn repopulé n’hérite pas de ticks obsolètes.

Les preuves pour un volume de dégâts sur la durée doivent inclure le pré-mitigation et le delta final, l’identité du build propriétaire, et la condition qui ramène ce scénario à son dernier état valide.

Exemple 3 : Réapparition en co-op

PlayerState conserve le score et l’équipe, GameMode attend le délai défini par les règles, trouve un spawn valide pour l’équipe et possède un nouveau pawn. Une caméra spectateur reste en présentation.

La preuve pour le respawn en coop doit inclure une transition d’un seul état de vie, l’identité de build propriétaire, et la condition qui ramène ce scénario à son dernier état connu bon.

Modes de défaillance et reprise

La mort s’exécute deux fois

Protégez la transition d’état avant de jouer des effets, d’attribuer des points, ou de planifier un respawn. Les callbacks de dégâts simultanés doivent converger vers une seule transition.

Avant de clore le problème de mort double, relancez le point damage headshot et prouvez que la transition unique d’état de vie revient à la limite attendue sans étape de réparation non documentée.

Les mises à jour de la barre de santé mais pas de la santé serveur

Inspectez le composant faisant autorité et la notification de réplication. Une animation de widget local n’est pas une preuve d’un résultat de dégâts engagé.

Avant de clore les mises à jour de la barre de santé alors que la santé serveur ne change pas, relancez le volume de dégâts sur la durée et prouvez que le nettoyage des minuteries et des effets à EndPlay revient à la limite attendue sans étape de réparation non documentée.

Le pawn réapparu conserve les anciens timers

Gardez les timers et les effets sur le pawn ou le composant, effacez-les dans EndPlay et à la mort, et évitez les callbacks qui conservent fortement une référence à un pawn détruit.

Avant de clore, le pawn réapparu conserve d’anciens timers ; relancez la réapparition en co-op et validez la sélection du spawn, la possession et le retour de la santé initialisée à la limite attendue sans étape de réparation non documentée.

Le joueur réapparaît à l’intérieur de la géométrie

Validez l’occupation des PlayerStart, fournissez une stratégie de sélection de secours, et journalisez le start choisi ainsi que le résultat du traitement des collisions au spawn.

Avant de clore "player spawns inside geometry", relancez un point damage headshot et prouvez que la demande de dégâts, l’instigateur, le causeur et le type reviennent à la limite attendue sans étape de réparation non documentée.

Matrice de validation

• demande de dégâts, instigateur, causeur et type : inspectez-le à côté de la demande de dégâts ; validez uniquement si l’exécution de mort deux fois ne se reproduit pas lors d’un point damage headshot et si les preuves mentionnent le build exact.
• delta pré-mitigation et final : inspectez-le à côté de l’autorité de santé ; passez uniquement si les mises à jour de la barre de santé mais pas de la santé serveur ne se reproduisent pas pendant un volume de dégâts sur la durée et si les preuves nomment l’exacte build.
• transition d’état de vie unique : inspectez-le à côté de la transition de mort ; validez uniquement si le fait que le pawn réapparu conserve d’anciens timers ne se reproduit pas durant la réapparition en co-op et si les preuves mentionnent le build exact.
• Minuterie et nettoyage des effets à EndPlay : inspectez-le à côté des règles de réapparition ; validez uniquement si "player spawns inside geometry" ne se reproduit pas lors d’un point damage headshot et si les preuves mentionnent le build exact.
• sélection du spawn, possession et santé initialisée : Inspectez-le à côté de la demande de dégâts ; passez uniquement lorsque la répétition de mort ne se reproduit plus pendant le volume de dégâts sur la durée et que les preuves mentionnent le build exact.

Inspectez-le à côté de la présentation et de l’autorité ; validez uniquement lorsque plusieurs interactions déclenchées par une pression ne se reproduisent pas lors d’une porte avec état de verrouillage et que les preuves mentionnent le build exact.

Ces étapes ciblent la surface de documentation Unreal Engine 5 actuelle au 2026-07-26. Les valeurs par défaut du moteur, le statut expérimental, le packaging des plugins, les signatures API et la prise en charge des plateformes peuvent changer. Sélectionnez la version de la documentation qui correspond au projet, testez le patch exact et la cible, et conservez une révision de rollback. La documentation publique ne remplace pas les exigences NDA de plateforme, la revue en store, la certification console ou les preuves de performance spécifiques au projet.

Sources officielles

• Système de dégâts Gameplay — preuve source pour la demande de dégâts dans ce flux unreal damage health death respawn system ; vérifiez la version de la documentation par rapport à la branche shipping.
• Référence rapide du Gameplay Framework — preuve principale de l’autorité de santé dans ce flux de travail du système Unreal de dégâts, santé, mort et respawn ; vérifiez la version de la documentation par rapport à la branche de distribution.
• Acteur Player Start — preuve source de la transition de mort dans ce flux de travail du système Unreal Damage Health Death Respawn ; vérifiez la version de la documentation par rapport à la branche shipping.

Unreal Engine est une marque déposée d'Epic Games. SEELE AI est indépendant et cet article n'implique pas l'approbation d'Epic Games ou de Valve.

Du plan technique au jeu Unreal de SEELE

Utilisez cette page pour définir le système, les tests d'acceptation et les limites de défaillance ; puis transmettez ce cahier des charges précis dans [le créateur de jeu Unreal de SEELE](/features/create/unreal-game). SEELE peut générer un jeu natif Unreal 5, fournir un aperçu dans le navigateur, prendre en charge l'optimisation et le packaging dans SEELE, et vous permettre de télécharger le projet ou la sortie packagée pour une publication externe ou de le publier en tant que jeu SEELE gratuit ou payant.

Ce transfert ne modifie pas la responsabilité de production native décrite ci-dessus. L'approbation du magasin, les ventes, les revenus, la certification, la compatibilité des plugins tiers et la conformité de la plateforme ne sont pas garanties. Gardez le jeu Unreal source, les journaux de compilation, les preuves de test et les décisions de publication externes sous le contrôle de votre équipe.

FAQ

Quelle est la bonne architecture pour le système Unreal de dégâts, santé, mort et respawn ?

Conservez la santé dans un composant de gameplay unique faisant autorité, acceptez les dégâts via une requête typée, bornez la valeur une seule fois et émettez des événements de changement d’état pour l’UI et les effets. La mort doit être une transition idempotente qui désactive tout gameplay supplémentaire, nettoie les effets temporaires, enregistre le tueur ou la cause, et demande à GameMode ou à la couche de règles propriétaire de faire réapparaître un nouveau pawn. Ne laissez jamais la barre de santé, le ragdoll ou l’appel de destruction devenir la source de vérité. Commencez par la demande de dégâts et l’autorité santé, puis gardez la présentation comme observatrice de l’état de gameplay engagé.

Le système Unreal damage health death respawn doit-il être développé en Blueprint ou en C++ ?

Les deux sont possibles. Blueprint est efficace pour une logique de jeu rapide et l’itération des designers ; C++ est utile pour des contrats réutilisables, des durées de vie complexes, des boucles sensibles aux performances et des tests automatisés. Conservez les mêmes limites de propriété, de validation, d’échec et de récupération dans les deux cas.

Comment tester le système Unreal de dégâts, santé, mort et respawn ?

Testez un cas normal, une entrée invalide, une interruption ou un démontage, un redémarrage propre, et la parité du build empaqueté. Capturez la demande de dégâts, l’initiateur, la source du dégât et le type, les conditions pré-mitigation et delta final, une unique transition d’état de vie avec un identifiant de build et des critères d’acceptation explicites.

Quelle est la défaillance la plus dangereuse du système Unreal damage health death respawn ?

L’exécution de mort deux fois est un signal d’alerte précoce : protégez la transition d’état avant de jouer les effets, d’attribuer le score ou de planifier la réapparition. Les callbacks de dégâts simultanés doivent converger vers une seule transition. Vérifiez aussi le nettoyage et la relance afin que la correction apparente ne laisse pas d’état obsolète.

Quelle version d’Unreal ce guide unreal damage health death respawn system cible-t-il ?

Il utilise la surface de documentation Unreal Engine 5 disponible le 2026-07-26. Vérifiez le sélecteur de version, la signature API, l’état du plugin, la chaîne d’outils de plateforme et le comportement packagé dans le patch moteur exact qui sera livré.

Que peut faire SEELE après que ce plan de système de dégâts, santé, mort et réapparition Unreal soit prêt ?

SEELE peut générer un jeu natif Unreal 5, fournir une prévisualisation navigateur, prendre en charge l'optimisation et l'empaquetage, et fournir des téléchargements de projet ou d'application empaquetée pour une publication externe ou une sortie SEELE gratuite ou payante. Il ne garantit pas l'approbation par des magasins tiers, la compatibilité, les ventes ou les revenus.