Die Geometrie des Kampfes: Hitboxen, Hurtboxen und Pushboxen
In den Kampfsystemen moderner Videospiele entspricht das, was Spieler auf dem Bildschirm sehen, nur selten den Berechnungen der zugrunde liegenden Physik-Engine. Hochdetaillierte 3D-Charaktermodelle, die aus Zehntausenden Polygonen, wehender Kleidung und detaillierten Fingergliedern bestehen, sind für physikalische Echtzeitberechnungen viel zu rechenintensiv. Aus diesem Grund entkoppeln moderne Game-Engines das visuelle Rendering vollständig von der physikalischen Kollisionserkennung. Sie erzeugen unsichtbare, stark vereinfachte Begrenzungsvolumen, um zu entscheiden, ob ein Angriff trifft, ob ein Charakter Schaden nimmt und wie Spielfiguren den Raum im Level einnehmen.
Um die Kampfmechaniken präzise zu strukturieren, unterteilen Engines die Kollisionskörper eines Charakters in drei funktionale Komponenten:
+-------------------------------------------------------------------------+
| DIE KAMPFKOLLISIONS-TRIADE |
+-------------------------------------------------------------------------+
| 1. HITBOX (Aktives Angriffsvolumen) |
| - Wird nur während der aktiven Frames eines Angriffs instantiiert |
| - Sucht im Raum nach überschneidenden, verwundbaren Zielen |
| - Löst Schadensberechnung, Hitstop und Rückstoßimpulse aus |
+-------------------------------------------------------------------------+
| 2. HURTBOX (Passives Verwundbarkeitsvolumen) |
| - Fest an Knochen des Skeletts (Kopf, Torso, Gliedmaßen) gebunden |
| - Aktualisiert Transformations- und Rotationsmatrizen mit Animation|
| - Passiver Empfänger: registriert Schaden beim Eindringen von Hitbox|
+-------------------------------------------------------------------------+
| 3. PUSHBOX / UMGEBUNGSKOLLIDER (Solides Physikvolumen) |
| - Meist eine aufrechte Kapsel, ein Zylinder oder einfacher Quader |
| - Verarbeitet den Kontakt mit Terrain (Böden, Wände, Hindernisse) |
| - Verhindert, dass Charaktere durcheinander oder durch Wände laufen |
+-------------------------------------------------------------------------+
Die strukturelle Notwendigkeit der räumlichen Trennung
Würde ein Spiel alle Interaktionen auf einen einzigen einheitlichen Kollisionskörper stützen, bräche das Kampfsystem zusammen:
- Würde die Kapsel für die Umgebungsnavigation Schaden registrieren, führten Angriffe, die lediglich die Luft neben ausgestreckten Armen streifen, zu unfairen Treffern.
- Teilten Waffen dieselben physischen Blockiereigenschaften wie die Spielfigur, würde ein beidhändiges Großschwert beim ersten Kontakt mit der äußeren Hülle des Gegners abrupt gestoppt, anstatt sauber durch den feindlichen Körper zu schneiden.
- Durch die Entkopplung von Hitboxen (Schadensverursacher), Hurtboxen (Schadensempfänger) und Pushboxen (solide Raumbarrieren) können Entwickler getrennte Kollisionsreaktionskanäle (Collision Response Channels) konfigurieren, die für bestimmte Ereignisse Überlappungen (Overlap) melden und für die Umgebung solide Barrieren (Block) aufrechterhalten.
Die zweiphasige Kollisionspipeline: Broad-Phase vs. Narrow-Phase
In modernen Actionspielen mit Dutzenden gleichzeitigen Akteuren, Zaubereffekten und interaktiven Requisiten würde das paarweise Testen aller Formen gegeneinander zu einer rechnerischen Explosion der Komplexität $O(N^2)$ führen. Befinden sich 100 kollisionsfähige Objekte in einer Szene, müsste ein naiver Algorithmus pro Physik-Tick folgenden Aufwand betreiben:
$$\frac{100 \times 99}{2} = 4,950 \text{ Schnittmengentests}$$
Um Physikschleifen mit 60 Hz oder 144 Hz stabil im Millisekundenbereich zu halten, teilen moderne Physik-Engines (wie PhysX, Chaos oder Havok) die Abfragen in zwei aufeinanderfolgende Phasen auf:
[ Alle dynamischen und statischen Entitäten der Szene ]
|
v
+-----------------------------------------------------------+
| BROAD-PHASE (Grobprüfung): Räumliche Vorpartitionierung |
| - Verwendet achsenparallele Begrenzungsrahmen (AABB) |
| - Durchläuft BVH-Bäume, Octrees oder Sweep-and-Prune |
| - Verwirft sofort 95% bis 99% aller nicht kollidierenden |
+-----------------------------------------------------------+
|
| (Nur Paare mit potenzieller Überlappung)
v
+-----------------------------------------------------------+
| NARROW-PHASE (Feinprüfung): Exakte geometrische Berechnung|
| - Prüft geometrische Primitive (Kugeln, Kapseln, OBBs) |
| - Wendet das Trennungsachsenschnitt-Theorem (SAT) oder GJK|
| - Berechnet Kontaktpunkte, Oberflächennormalen und Tiefe |
+-----------------------------------------------------------+
|
v
[ Spiel-Events ausgelöst: TakeDamage(), ApplyImpulse() ]
1. Räumliche Beschleunigung in der Broad-Phase
In der Broad-Phase werden komplexe Charakterdetails ignoriert. Jedes Objekt wird in einen achsenparallelen Begrenzungsrahmen (Axis-Aligned Bounding Box, AABB) eingefasst, dessen Kanten exakt an den Weltachsen $(X, Y, Z)$ ausgerichtet sind. Die Überlappungsprüfung zweier AABBs erfordert lediglich skalare Min-Max-Vergleiche:
$$\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)$$
Mithilfe hierarchischer Datenstrukturen wie Bounding Volume Hierarchies (BVH) oder Octrees fasst die Engine räumlich benachbarte Objekte in Baumknoten zusammen. Überschneidet sich der Begrenzungsrahmen eines Schwerthiebs nicht mit dem Elternknoten einer entfernten Gegnergruppe, überspringt das System Dutzende Abfragen in einem einzigen Rechenschritt und senkt die Komplexität von $O(N^2)$ auf $O(N \log N)$ oder annähernd $O(N)$.
2. Geometrische Exaktheit in der Narrow-Phase
Erst die von der Broad-Phase übergebenen Kandidatenpaare werden in der Narrow-Phase mit präzisen algebraischen Methoden geprüft:
- Kugel gegen Kugel: Der schnellste Test in 3D. Es wird lediglich geprüft, ob das Quadrat des Abstands der Mittelpunkte kleiner ist als das Quadrat der Summe der Radien $(|C_1 - C_2|^2 \le (R_1 + R_2)^2)$.
- Kapsel gegen Kapsel: Ermittelt den kürzesten Abstand zwischen den beiden inneren Knochensegmenten und vergleicht ihn mit der Radiensumme. Da Kapseln der Anatomie menschlicher Gliedmaßen optimal entsprechen, sind sie der De-facto-Standard für Hurtboxen.
- Orientierte Quader (OBB) und konvexe Hüllen: Werden über das Trennungsachsenschnitt-Theorem (Separating Axis Theorem, SAT) oder den GJK-Algorithmus (Gilbert-Johnson-Keerthi) berechnet. Lässt sich eine Ebene finden, auf der sich die Projektionen beider Körper nicht überschneiden, berühren sie sich nicht.
Polygon-Gitter-Kollisionen (das Berechnen von Schnittmengen zwischen Zehntausenden deformierten Dreiecksflächen animierter Meshes) werden im dynamischen Nahkampf strikt vermieden, da sie die CPU-Physik-Threads überlasten und drastische Framerate-Einbrüche erzeugen würden.
Diskrete Kollision vs. Kontinuierliche Kollisionserkennung (CCD): Das Tunneling-Problem
Der bekannteste Kollisionsfehler in Actionspielen ist das sogenannte Tunneling (unter Spielern oft als „Phasing“, „Geisterschlag“ oder „durchgehende Treffer“ bezeichnet). Tunneling tritt auf, wenn ein schnelles Objekt eine Kollisionsfläche zwischen zwei aufeinanderfolgenden Physik-Frames komplett überspringt, ohne dass die Engine eine Berührung registriert.
Die mathematische Ursache von Tunneling
Klassische Physikberechnungen nutzen standardmäßig die diskrete Kollisionserkennung (Discrete Collision Detection). Dabei wird die Position von Körpern nur zu festen Zeitschritten $t, t + \Delta t$ abgetastet:
Frame N (Zeit = t): Frame N+1 (Zeit = t + dt):
[ Kugel / Klinge ] --- Tempo v ---> [ Kugel / Klinge ]
o o
(bei x=10) (bei x=60)
| Schild / Körper |
| [x=30..35] |
Bewegt sich ein Objekt mit der Geschwindigkeit $v$, beträgt seine Verschiebung in einem Zeitschritt:
$$\Delta x = v \cdot \Delta t$$
Ist die Dicke des Zielobjekts $W_{\text{target}}$ zuzüglich des Durchmessers des Projektils $D_{\text{proj}}$ kleiner als diese Einzelschritt-Distanz:
$$W_{\text{target}} + D_{\text{proj}} < v \cdot \Delta t$$
Im Frame $N$ befand sich das Projektil vollständig vor dem Ziel; im Frame $N+1$ befindet es sich bereits vollständig dahinter. Da die diskrete Engine ausschließlich prüft, ob sich Körper zu den Abtastzeitpunkten überschneiden, wird zu keinem Zeitpunkt eine Überlappung festgestellt. Das Projektil durchdringt das Ziel, als wäre es immateriell.
Architekturen kontinuierlicher Kollisionserkennung (CCD)
Um Tunneling bei Hochgeschwindigkeitsprojektilen oder schnellen Schwertspitzen zu unterbinden, integrieren Engines Kontinuierliche Kollisionserkennung (CCD) über zwei Verfahren:
+----------------------------------------------------------------------------+
| CCD-IMPLEMENTIERUNGEN |
+----------------------------------------------------------------------------+
| 1. SWEEP-BASIERTES CCD (Swept Volume / Extrusion) |
| - Extrudiert die geometrische Form entlang des Geschwindigkeitsvektors |
| - Löst die kontinuierliche Schnittgleichung über das Intervall [0, dt] |
| - Berechnet den exakten Einschlagszeitpunkt (TOI ∈ [0, 1]) und Normalen |
| - Nachteil: Enormer CPU-Berechnungsaufwand pro aktivem Objekt |
+----------------------------------------------------------------------------+
| 2. SPEKULATIVES CCD (Speculative CCD / Vorhersagende AABB-Expansion) |
| - Vergrößert die AABB-Box des Objekts vorausschauend in Bewegungsrichtung|
| - Erzeugt Geschwindigkeitsbeschränkungen vor der physischen Überlappung |
| - Vorteil: Deutlich ressourcenschonender als geometrisches Sweeping |
| - Nachteil: Kann Geisterkollisionen bei abrupten Richtungswechseln haben|
+----------------------------------------------------------------------------+
In First-Person-Shootern verzichten Entwickler bei Schusswaffen meist vollständig auf physikalische Rigidbodys und setzen stattdessen auf Line Traces / Raycasts (Hitscan). Beim Abkrümmen projiziert das System eine mathematische Linie ohne Dicke von der Mündung zum Zielpunkt, wodurch getroffene Hurtboxen ohne jegliches Tunneling und mit minimaler Prozessorlast ermittelt werden.
Ursachen für die Diskrepanz zwischen visuellem Modell und Kampfphysik
Treten Diskrepanzen auf – etwa wenn ein Hieb den Körper scheinbar durchschneidet, ohne Schaden anzurichten, oder ein Treffer in die Luft einen halben Meter daneben registriert wird –, liegt dies an technischen Kompromissen zwischen Optik und Simulation.
1. Kapsel-Approximation vs. anatomische Körperkonturen
Das grafische Modell besitzt ausgeprägte Rüstungsteile, wehende Umhänge und muskuläre Konturen. Die für den Schaden zuständige Hurtbox besteht jedoch lediglich aus einfachen zylindrischen Kapseln, die am Skelett verankert sind.
Entwickler stehen vor folgendem Dilemma:
- Eng anliegende Hurtboxen (kleiner als das Modell): Verhindern Treffer im Leeren, führen aber dazu, dass sichtbare Treffer an Umhängen oder Schulterplatten wirkungslos durchgehen.
- Großzügige Hurtboxen (größer als das Modell): Gewährleisten, dass knappe Schläge zuverlässig treffen, führen aber dazu, dass Spieler bei Ausweichmanövern durch spürbare „Luftschläge“ getroffen werden.
2. Animations-Blending und Root-Motion-Desynchronisation
Moderne Spielfiguren nutzen komplexe Animations-Mischbäume (Blend Trees). Bricht ein Spieler einen schweren Angriff durch eine Ausweichrolle ab, interpolieren Shader auf der GPU die Vertex-Positionen über Hunderte Millisekunden sanft zwischen den Posen.
Hurtboxen aktualisieren ihre Koordinaten jedoch schrittweise über die Matrizen der Knochen-Sockets. Stimmt die Kurve des Animationsübergangs nicht exakt mit der physikalischen Verschiebung (Root Motion) überein, kann das sichtbare Modell für kurze Zeit von den realen Kollisionskapseln abweichen.
3. Vorgezogene Hitboxen (Disjoint) und Linger-Frames
In Kampfspielen setzen Entwickler häufig bewusst disjointe Hitboxen ein, die über die physische Klinge der Waffe hinausragen, oder belassen die Schadensabfrage für einige Frames nach dem Schwung aktiv (Linger Frames).
Dieses Design kompensiert menschliche Reaktionszeiten und stellt sicher, dass Sprungangriffe geduckte Gegner verlässlich treffen. Auch wenn Standbilder visuell ungenau wirken, erzeugt dieser Ansatz in der Spieldynamik ein deutlich befriedigenderes Trefferfeedback.
4. Visuelle Effekte (VFX) besitzen keine Kollisionsdaten
Feuerkegel, magische Partikelschweife und Klingenschimmer werden ausschließlich in der Grafik-Pipeline der GPU berechnet. Sie besitzen per se keinerlei physikalische Eigenschaften. Wenn der Programmierer dem Partikeleffekt nicht explizit eine eigene Hitbox zuweist, verursacht der sichtbare Ausläufer eines Effekts keinerlei Treffer.
Vergleichsmatrix: Kollisionserkennungsmodi
Die folgende Übersicht vergleicht die gängigen Architekturen zur Kollisionserkennung:
| Kollisionsmodus | Rechenaufwand | Tunneling (Statische Geometrie) | Tunneling (Dynamische Akteure) | Typische Anwendung | Nachteile und Grenzfälle |
|---|---|---|---|---|---|
| Diskrete Erkennung | Sehr gering (Einfacher Frame-Test) | Anfällig bei hohem Tempo | Anfällig bei hohem Tempo | Standard-Laufbewegungen, Level-Architektur, langsame Gegner | Starke Durchdringung bei FPS-Einbrüchen; dünne Wände versagen |
| Sweep-basiertes CCD | Sehr hoch (Kontinuierliche Geometrielösung) | Zuverlässig verhindert | Zuverlässig verhindert (wenn beidseitig aktiv) | Nahkampfwaffenspitzen, Wurfspeere, schnelle Fahrzeuge | CPU-Überlastung bei vielen gleichzeitigen Akteuren |
| Spekulatives CCD | Moderat (Vorausschauende AABB-Erweiterung) | Weitgehend reduziert | Weitgehend reduziert | Ragdoll-Physik, Trümmerteile | Risiko von Geisterkollisionen bei abruptem Vektorwechsel |
| Raycast / Hitscan | Gering ($O(1)$ Schnittpunkttest) | Auf der Linie verhindert | Auf der Linie verhindert | Schusswaffen-Projektile, Bodenhaftungsprüfung | Reines Linienelement ohne Volumen; schlüpft durch winzige Kapsellücken |
Diagnosewerkzeuge der Engine und praktische Fehleranalyse
Um Trefferprobleme nicht anhand trügerischer visueller Eindrücke zu beurteilen, können Entwickler und Spieler die echte Kollisionsgeometrie über interne Konsolen einblenden.
1. Konsolenbefehle zur Visualisierung
Unreal Engine (UE4 / UE5)
Über die Entwicklerkonsole (Taste ~) lassen sich Kollisionsgitter in Echtzeit zuschalten:
show collision # Zeigt alle aktiven statischen und dynamischen Kollisionsformen an
show CollisionPawn # Beschränkt die Anzeige auf Schadens- und Hurtbox-Kapseln der Charaktere
pxvis collision # Erzwingt die Low-Level-PhysX/Chaos-Drahtgitterdarstellung
- Türkise / Grüne Drahtgitter: Reguläre passive Begrenzungskörper (Kapseln, Sphären, Boxen).
- Rote / Violette Drahtgitter: Aktive Angriffs- und Sweep-Volumen des aktuellen Frames (Hitboxen).
Source / Source 2 Engine
Auf lokalen Servern von Valve-Titeln lässt sich die Server-Trefferberechnung visualisieren:
sv_showlagcompensation 1 # Zeichnet die vom Server zurückgewickelten Hitboxen zur Trefferprüfung
r_drawclipbrushes 1 # Macht unsichtbare Umgebungswände (Clip Brushes) sichtbar
2. Dreistufiger Ablauf zur Fehlerlokalisierung
Wenn ein scheinbar sicherer Treffer ins Leere geht:
- Schritt 1: Physik-Framerate und Performance prüfen
- Prüfen, ob im Moment des Treffers die Framerate eingebrochen ist (z. B. von 60 auf 20 FPS). Das Abtastintervall $\Delta t$ vergrößert sich dadurch schlagartig, was Tunneling extrem begünstigt.
- Schritt 2: Ausrichtung der Kollisionskapseln kontrollieren
- Im Debug-Modus prüfen, ob die Hurtbox-Kapseln der Animation im Treffer-Frame exakt gefolgt sind. Ein Nachhinken deutet auf einen Fehler im Animations-Blendtree hin, nicht auf einen Fehler der Physik-Engine.
- Schritt 3: Latenzkompensation analysieren (im Multiplayer)
- In Online-Spielen sind vermeintliche Hitbox-Fehler fast immer das Resultat von Lag Compensation. Während der Client einen Treffer anzeigt, stellt der autoritative Server beim Zurückspulen fest, dass der Gegner bereits hinter einer Mauer stand. Der Treffer wird serverseitig verworfen, wodurch Blut- oder Funkeffekte ohne Schadenswirkung entstehen.
Bei der objektiven Beurteilung, ob ein Trefferproblem auf geometrische Begrenzungsvolumen, Netzwerk-Rollbacks oder reine Animationsdiskrepanzen zurückgeht, bieten die fundierten technischen Analysen auf 365Finds verlässliche Orientierung, um Ursachen exakt einzugrenzen, anstatt sich auf vage Community-Gerüchte über vermeintlich „kaputte Engines“ zu verlassen.