La géométrie du combat : Hitboxes, Hurtboxes et Pushboxes
Dans les systèmes de combat des jeux vidéo, ce que le joueur observe à l'écran correspond rarement aux calculs bruts effectués par le moteur physique sous-jacent. Les modèles tridimensionnels de haute précision, dotés de dizaines de milliers de polygones, de vêtements dynamiques et d'articulations complexes, représentent une charge de calcul prohibitive pour les simulations physiques en temps réel. Pour surmonter cet écueil, les moteurs de jeu dissocient rigoureusement le rendu visuel de la physique géométrique en établissant des volumes invisibles et simplifiés chargés de déterminer si une attaque touche, si un personnage encaisse des dégâts et comment les entités se positionnent dans l'espace.
Pour structurer les interactions martiales de façon claire et performante, les moteurs divisent les volumes de collision d'un personnage en trois composantes fonctionnelles distinctes :
+-------------------------------------------------------------------------+
| LE TRIO DE COLLISION EN COMBAT |
+-------------------------------------------------------------------------+
| 1. HITBOX (Volume d'attaque actif) |
| - Instancié uniquement durant les images actives d'une attaque |
| - Scanne l'espace environnant à la recherche de cibles vulnérables |
| - Déclenche le calcul des dégâts, le hitstop et les impulsions |
+-------------------------------------------------------------------------+
| 2. HURTBOX (Volume passif de vulnérabilité) |
| - Lié aux os du squelette de l'animation (tête, torse, membres) |
| - Actualise ses matrices de position et de rotation à chaque pose |
| - Récepteur passif : enregistre les dégâts quand pénétré par Hitbox |
+-------------------------------------------------------------------------+
| 3. PUSHBOX / COLLISIONNEUR ENVIRONNEMENTAL (Volume solide) |
| - Généralement une capsule verticale, un cylindre ou un parallélépipède|
| - Gère les contacts avec le décor (sols, parois rocheuses, murs) |
| - Empêche les personnages de se traverser ou de passer sous la carte|
+-------------------------------------------------------------------------+
La nécessité architecturale de la séparation spatiale
Si un jeu devait unifier l'ensemble de ces rôles au sein d'un unique collisionneur, le système de combat s'effondrerait :
- Si la capsule de déplacement dans l'environnement encaissait également les dégâts, un coup d'épée effleurant l'air vide sous le bras écarté d'un joueur entraînerait des blessures injustifiées.
- Si les armes partageaient les propriétés d'obstacle physique des personnages, une grande épée s'arrêterait brutalement dès le premier contact avec la boîte externe de l'adversaire au lieu de trancher à travers son torse pour achever son mouvement.
- En séparant Hitboxes (sources de dégâts), Hurtboxes (récepteurs de dégâts) et Pushboxes (frontières solides), le moteur peut configurer des canaux de réponse aux collisions (Collision Response Channels) distincts, ignorant certaines interactions tout en déclenchant des rappels de chevauchement (Overlap) sur d'autres.
Le pipeline de collision en deux phases : Phase large vs Phase étroite
Dans les jeux d'action modernes mettant en scène des dizaines d'ennemis, des projectiles magiques et des débris physiques, tester chaque géométrie contre toutes les autres à chaque trame provoquerait une explosion algorithmique en $O(N^2)$. Si une scène réunit 100 entités physiques, une boucle naïve exigerait :
$$\frac{100 \times 99}{2} = 4,950 \text{ tests d'intersection par cycle}$$
Pour maintenir des boucles physiques stables à 60 Hz ou 144 Hz, les moteurs physiques contemporains (tels que PhysX, Chaos ou Havok) scindent les requêtes spatiales en deux phases successives :
[ Toutes les entités physiques de la scène ]
|
v
+-----------------------------------------------------------+
| PHASE LARGE (Broad Phase) : Élagage spatial grossier |
| - Utilise des boîtes englobantes alignées (AABB) |
| - Parcourt des hiérarchies BVH, octrees ou Sweep & Prune |
| - Rejette instantanément 95 % à 99 % des paires disjointes|
+-----------------------------------------------------------+
|
| (Paires candidates au chevauchement)
v
+-----------------------------------------------------------+
| PHASE ÉTROITE (Narrow Phase) : Résolution géométrique fine|
| - Évalue les primitives (sphères, capsules, OBB) |
| - Exécute le théorème de l'axe séparateur (SAT) ou GJK |
| - Calcule les points d'impact, normales et pénétrations |
+-----------------------------------------------------------+
|
v
[ Événements de gameplay : TakeDamage(), ApplyImpulse() ]
1. Partitionnement et accélération en Phase large
La phase large fait abstraction totale de l'anatomie détaillée. Chaque objet est encapsulé dans une boîte englobante alignée sur les axes (Axis-Aligned Bounding Box, AABB), dont les faces demeurent strictement parallèles aux axes du monde $(X, Y, Z)$. Vérifier si deux boîtes AABB se chevauchent ne nécessite que de simples comparaisons scalaires :
$$\text{Overlap} \iff (A_{\min}^x \le B_{\max}^x \land A_{\max}^x \ge B_{\min}^x) \land (A_{\min}^y \le B_{\max}^y \land A_{\max}^y \ge B_{\min}^y) \land (A_{\min}^z \le B_{\max}^z \land A_{\max}^z \ge B_{\min}^z)$$
Grâce à des structures hiérarchiques comme les hiérarchies de volumes englobants (BVH) ou les octrees, le moteur regroupe les objets spatialement proches dans les nœuds d'un arbre. Si la boîte englobante d'un coup de taille ne croise pas le nœud parent d'un groupe d'ennemis lointains, le moteur écarte des dizaines de vérifications en une seule instruction, ramenant la complexité de $O(N^2)$ à $O(N \log N)$ ou quasiment $O(N)$.
2. Résolution géométrique en Phase étroite
Seules les paires transmises par la phase large sont soumises aux calculs rigoureux de la phase étroite :
- Sphère contre Sphère : Le test le plus rapide en 3D. Il suffit de vérifier si le carré de la distance entre centres est inférieur au carré de la somme des rayons $(|C_1 - C_2|^2 \le (R_1 + R_2)^2)$.
- Capsule contre Capsule : Recherche le segment minimal reliant les deux squelettes internes et le compare à la somme des rayons. Épousant naturellement la forme des membres humains, la capsule constitue la primitive standard des Hurtboxes.
- Boîtes orientées (OBB) et enveloppes convexes : Résolues via le théorème de l'axe séparateur (SAT) ou l'algorithme de distance GJK (Gilbert-Johnson-Keerthi). Si l'on peut identifier un axe sur lequel les projections des deux solides ne se chevauchent pas, ils ne sont pas en contact.
La détection par maillage polygone par polygone (Per-Polygon Mesh) est bannie des combats dynamiques : soumettre des dizaines de milliers de facettes déformées par l'animation à des tests d'intersection saturerait les threads du processeur et provoquerait de graves chutes de fluidité.
Détection discrète vs Détection continue (CCD) : Le problème de l'effet tunnel
Le défaut de collision le plus perturbant dans les jeux d'action est l'effet tunnel (tunneling, communément appelé « coup qui traverse » ou « balle fantôme »). Il survient lorsqu'un objet se déplaçant à très haute vélocité saute par-dessus la boîte de collision de sa cible entre deux trames physiques consécutives.
Le mécanisme mathématique de l'effet tunnel
Par défaut, la majorité des moteurs exécutent une détection de collision discrète (Discrete Collision Detection). Dans ce mode, la physique n'évalue les positions des entités qu'à des instants fixes $t, t + \Delta t$ :
Image N (Temps = t) : Image N+1 (Temps = t + dt) :
[ Balle / Épée ] --- Vitesse v ---> [ Balle / Épée ]
o o
(en x=10) (en x=60)
| Bouclier / Cible |
| [x=30..35] |
Lorsqu'un projectile progresse à la vitesse $v$, sa distance parcourue en une trame physique correspond à :
$$\Delta x = v \cdot \Delta t$$
Si l'épaisseur de la cible $W_{\text{target}}$ cumulée au diamètre du projectile $D_{\text{proj}}$ est inférieure à cette distance parcourue :
$$W_{\text{target}} + D_{\text{proj}} < v \cdot \Delta t$$
À l'image $N$, le projectile se trouvait en deçà de la cible ; à l'image $N+1$, il se situe déjà au-delà. Comme le moteur discret n'interroge les volumes qu'à ces instants fixes, aucune superposition géométrique n'est enregistrée. Le projectile traverse son adversaire comme s'il était transparent.
Les architectures de Détection Continue des Collisions (CCD)
Pour neutraliser l'effet tunnel sur les projectiles véloces et les pointes d'armes de mêlée, les moteurs déploient la Détection Continue des Collisions (CCD) via deux approches :
+----------------------------------------------------------------------------+
| MODALITÉS DE LA CCD |
+----------------------------------------------------------------------------+
| 1. CCD PAR BALAYAGE (Sweep-based CCD / Volume extrudé) |
| - Extrude la primitive géométrique le long du vecteur de vélocité |
| - Résout l'équation d'intersection continue sur l'intervalle [0, dt] |
| - Calcule l'instant exact de l'impact (TOI ∈ [0, 1]) et la normale |
| - Limite : Coût CPU extrêmement élevé sur un grand nombre d'entités |
+----------------------------------------------------------------------------+
| 2. CCD SPÉCULATIVE (Speculative CCD / Dilatation prédictive d'AABB) |
| - Étend préventivement la boîte AABB de l'objet dans l'axe de son avance|
| - Instaure des contraintes prédictives de vitesse avant le contact réel |
| - Avantage : Nettement moins exigeante en calculs que le balayage pur |
| - Limite : Risque de « collisions fantômes » lors de changements brusques|
+----------------------------------------------------------------------------+
Dans les jeux de tir à la première personne, les concepteurs remplacent souvent les projectiles physiques par des lancers de rayons instantanés (Line Traces / Raycasts) (hitscan). Lors du tir, une ligne mathématique de rayon nul est immédiatement tracée de l'arme vers la cible, détectant sur-le-champ toute Hurtbox perforée, ce qui supprime tout effet tunnel sans surcharger le processeur.
Les origines du décalage entre le visuel et la physique de combat
Le sentiment de frustration d'un joueur affirmant « mon arme a visiblement tranché le boss sans faire de dégâts » ou « j'ai été touché dans le vide à un mètre » découle des compromis inhérents au moteur.
1. Approximation par capsules vs silhouettes anatomiques
Le modèle visuel affiche des renflements musculaires, des drapés et des épaulettes articulées. À l'opposé, les Hurtboxes chargées de recevoir les dégâts se résument à quelques capsules cylindriques attachées aux os.
Les équipes de développement doivent trancher :
- Hurtboxes ajustées (plus petites que le modèle) : Évitent les coups litigieux sur les bords, mais font que des coups visibles portés sur une cape ou une épaulière ne touchent rien.
- Hurtboxes larges (plus grandes que le modèle) : Garantissent que les coups rasants connectent, mais exposent le joueur à être touché dans l'air vide lors d'une esquive.
2. Mélange d'animations et désynchronisation du Root Motion
Les personnages modernes exploitent des arbres de mélange (Blend Trees). Lorsqu'un joueur interrompt un coup lourd par une roulade, les shaders interpolent en douceur la géométrie des maillages sur plusieurs centaines de millisecondes.
Toutefois, les Hurtboxes se mettent à jour par crans discrets d'après les matrices des os. Si la vitesse de déplacement physique (Root Motion) et la courbe d'interpolation divergent, le personnage affiché à l'écran peut s'écarter temporairement de ses capsules physiques réelles.
3. Hitboxes disjointes (Disjoint) et images rémanentes (Linger Frames)
Dans les jeux de combat et d'action exigeants, les concepteurs créent délibérément des Hitboxes disjointes, étendant la zone de frappe bien au-delà de la lame, ou laissent la détection active pendant quelques images après la fin du balancement visuel (linger frames).
Ce mécanisme compense les temps de réaction humains et assure que les frappes aériennes touchent les ennemis accroupis, offrant ainsi un retour de frappe gratifiant et percutant, bien que visuellement inexact.
4. Les effets graphiques (VFX) ne possèdent aucune propriété physique
Les gerbes d'étincelles, les flammes et les traînées lumineuses des armes sont traitées exclusivement par la carte graphique (GPU). Elles ne possèdent aucune boîte de collision. Si le programmeur n'a pas explicitement arrimé une Hitbox à l'effet de particules, frôler la queue lumineuse d'une magie ne causera aucun dégât.
Matrice comparative des méthodes de détection de collision
Le tableau ci-dessous résume les caractéristiques et compromis des différentes architectures :
| Mode de collision | Coût en calculs | Risque d'effet tunnel (Décor) | Risque d'effet tunnel (Acteurs) | Usage typique | Limites et points de rupture |
|---|---|---|---|---|---|
| Détection discrète | Minimal (Test simple par trame) | Élevé à grande vitesse | Élevé à grande vitesse | Marche des personnages, murs imposants, monstres lents | Pénétration accrue si les FPS chutent ; traverse les murs fins |
| CCD par balayage | Très élevé (Calculs géométriques continus) | Entièrement supprimé | Entièrement supprimé (si bilatéral) | Pointes d'armes blanches, javelots, véhicules rapides | Surcharge du processeur en cas de combats massifs simultanés |
| CCD spéculative | Modéré (Extension prédictive d'AABB) | Fortement réduit | Fortement réduit | Moteurs ragdoll, projections de décombres | Risque de heurter l'air vide lors de changements de direction |
| Lancer de rayon (Raycast) | Faible (Intersection segment-plan) | Supprimé sur la trajectoire | Supprimé sur la trajectoire | Tirs hitscan, détection du sol, champs de vision | Absence d'épaisseur ; peut s'infiltrer entre deux capsules disjointes |
Outils de diagnostic intégrés et méthodologie de dépannage
Pour élucider une anomalie de frappe sans se fier à des jugements visuels trompeurs, il est possible d'inspecter directement la physique via les consoles de débogage.
1. Commandes console pour visualiser les collisions
Unreal Engine (UE4 / UE5)
Dans les versions disposant de la console active (touche ~), les commandes suivantes affichent les volumes en jeu :
show collision # Affiche l'ensemble des formes de collision statiques et dynamiques
show CollisionPawn # Restreint la vue aux capsules de vulnérabilité des personnages
pxvis collision # Force le rendu filaire des géométries physiques de bas niveau
- Lignes cyan / vertes : Boîtes de collision passives régulières (capsules, sphères, boîtes).
- Lignes rouges / violettes : Volumes de balayage offensifs actifs sur la trame en cours (Hitboxes).
Moteur Source / Source 2
Sur les serveurs locaux des titres conçus avec l'architecture de Valve :
sv_showlagcompensation 1 # Dessine les Hitboxes rembobinées par le serveur pour le calcul du tir
r_drawclipbrushes 1 # Visualise les surfaces invisibles de blocage de la carte (clip brushes)
2. Procédure en trois étapes pour identifier la cause d'un coup manqué
Lorsqu'une attaque semble traverser mystérieusement un adversaire :
- Étape 1 : Vérifier la fréquence physique et les chutes d'images
- Contrôler si une baisse brutale de framerate (de 60 à 25 FPS) s'est produite lors de la frappe. L'intervalle $\Delta t$ s'élargit immédiatement, permettant à l'arme d'enjamber la silhouette adverse sans déclencher de contact.
- Étape 2 : Examiner l'ancrage des capsules sur l'armature
- Grâce aux tracés filaires, vérifier si la Hurtbox a suivi fidèlement la silhouette du personnage durant la trame d'attaque. Un retard d'ancrage traduit un défaut de calibrage dans l'arbre d'animation, et non un bogue du moteur physique.
- Étape 3 : Évaluer la compensation de latence (en multijoueur)
- En ligne, l'immense majorité des prétendues erreurs de Hitbox relève de la compensation de décalage (Lag Compensation). Si le serveur fait reculer l'état du monde et juge que l'adversaire s'était déjà réfugié derrière un abri au moment précis de l'action, il rejette la touche, ce qui se traduit localement par des gerbes de sang sans dégâts réels.
Pour déterminer avec rigueur si un échec d'impact découle de la conception des volumes, de la réconciliation réseau ou d'une simple discordance visuelle, les analyses techniques détaillées de 365Finds permettent d'isoler les causes réelles sans verser dans les habituelles conjectures communautaires sur les prétendus « moteurs défaillants ».