La geometría del combate: Hitboxes, Hurtboxes y Pushboxes
En los sistemas de combate de los videojuegos, lo que los jugadores observan en pantalla rara vez coincide con lo que el motor de física subyacente calcula en tiempo real. Los personajes tridimensionales de alta fidelidad, compuestos por decenas de miles de polígonos, vestimentas dinámicas y articulaciones complejas, resultan inviables para los cálculos de colisión directos. Para resolver este desafío, los motores desacoplan por completo el renderizado visual de la física geométrica, construyendo volúmenes invisibles y simplificados que determinan si un ataque acierta, si un objetivo recibe daño y cómo se ocupan los espacios físicos del mundo virtual.
Para organizar las mecánicas de combate con precisión, los motores dividen la interacción física de un personaje en tres volúmenes funcionales independientes:
+-------------------------------------------------------------------------+
| TRÍADA DE COLISIÓN DE COMBATE |
+-------------------------------------------------------------------------+
| 1. HITBOX (Volumen ofensivo activo) |
| - Se instancia únicamente durante los fotogramas activos del ataque |
| - Rastrea el espacio en busca de objetivos vulnerables |
| - Desencadena el cálculo de daño, el hitstop y las fuerzas de empuje|
+-------------------------------------------------------------------------+
| 2. HURTBOX (Volumen pasivo de vulnerabilidad) |
| - Vinculado a los huesos del esqueleto (cabeza, torso, extremidades)|
| - Actualiza sus matrices de rotación y traslación con la animación |
| - Receptor pasivo: registra daño al ser penetrado por un Hitbox |
+-------------------------------------------------------------------------+
| 3. PUSHBOX / COLISIONADOR DE ENTORNO (Volumen físico sólido) |
| - Generalmente una cápsula vertical, cilindro o prisma simple |
| - Resuelve el contacto con el terreno (suelos, muros, desniveles) |
| - Impide que los personajes se atraviesen entre sí o caigan al vacío|
+-------------------------------------------------------------------------+
La necesidad estructural de la separación espacial
Si un juego intentara unificar todas las interacciones en un único colisionador, las mecánicas de combate se desmoronarían:
- Si la cápsula de navegación ambiental recibiera daño, cualquier ataque rozando el aire alrededor de un brazo extendido causaría impactos injustos.
- Si las armas compartieran las propiedades de bloqueo físico del personaje, blandir un espadón contra un adversario detendría la hoja en seco en cuanto tocara el límite exterior de su modelo, impidiendo que el arma atraviese el cuerpo del enemigo para asestar un golpe cortante.
- Al separar Hitboxes (daño), Hurtboxes (vulnerabilidad) y Pushboxes (bloqueo sólido), el motor puede definir canales de respuesta de colisión (Collision Response Channels) independientes, ignorando ciertas interacciones mientras activa funciones de llamada (callbacks de solapamiento) en otras.
La canalización de colisión en dos fases: Fase amplia frente a Fase estrecha
En un juego de acción moderno con docenas de enemigos simultáneos, proyectiles mágicos y objetos dinámicos, comprobar todas las formas geométricas contra todas las demás en cada fotograma generaría una explosión computacional de orden $O(N^2)$. Si una escena contiene 100 actores físicos, un bucle directo requeriría:
$$\frac{100 \times 99}{2} = 4,950 \text{ pruebas de intersección por ciclo}$$
Para sostener frecuencias de actualización de 60 Hz o 144 Hz, los motores de física (como PhysX, Chaos o Havok) dividen las consultas espaciales en dos fases consecutivas:
[ Todos los actores físicos en la escena ]
|
v
+-----------------------------------------------------------+
| FASE AMPLIA (Broad Phase): Partición espacial gruesa |
| - Emplea Cajas Envolventes Alineadas con los Ejes (AABB) |
| - Evalúa Árboles BVH, Octrees o algoritmos Sweep & Prune |
| - Descarta de inmediato entre el 95% y el 99% de pares |
+-----------------------------------------------------------+
|
| (Únicamente pares con solapamiento potencial)
v
+-----------------------------------------------------------+
| FASE ESTRECHA (Narrow Phase): Resolución geométrica exacta|
| - Evalúa primitivas reales (Esferas, Cápsulas, OBB) |
| - Aplica el Teorema del Eje Separador (SAT) o GJK |
| - Calcula puntos de contacto exactos, normales y empuje |
+-----------------------------------------------------------+
|
v
[ Eventos de juego despachados: TakeDamage(), ApplyImpulse() ]
1. Partición y aceleración en la Fase amplia
La fase amplia prescinde por completo de los detalles anatómicos. Cada objeto se encierra en una Caja Envolvente Alineada con los Ejes (AABB), cuyas caras son paralelas a los ejes coordenados $(X, Y, Z)$. Comprobar si dos AABB se solapan solo requiere comparaciones aritméticas directas entre sus valores mínimos y máximos:
$$\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)$$
Mediante estructuras de datos jerárquicas como Árboles de Envolventes (BVH), Octrees o el método Sweep and Prune, el motor agrupa las entidades contiguas en nodos de árbol. Si la caja envolvente de un espadazo no interseca el nodo padre que agrupa a una patrulla enemiga lejana, se descartan decenas de comparaciones en una sola instrucción, reduciendo la complejidad de $O(N^2)$ a $O(N \log N)$ o $O(N)$.
2. Resolución geométrica en la Fase estrecha
Aquellos pares que superan el filtrado de la fase amplia pasan a la fase estrecha para resolver su intersección geométrica exacta:
- Esfera contra Esfera: La prueba más rápida en 3D. Basta con verificar si el cuadrado de la distancia entre centros es menor que el cuadrado de la suma de sus radios $(|C_1 - C_2|^2 \le (R_1 + R_2)^2)$.
- Cápsula contra Cápsula: Calcula la distancia euclidiana mínima entre los dos segmentos óseos internos y la compara con la suma de los radios. Al coincidir de forma natural con la geometría de los miembros humanos, es la primitiva estándar para las Hurtboxes de los personajes.
- Cajas Orientadas (OBB) y Envolventes Convexas: Se resuelven mediante el Teorema del Eje Separador (SAT) o el algoritmo de distancia GJK (Gilbert-Johnson-Keerthi). Si es posible trazar un hiperplano separador entre dos poliedros convexos en cualquier proyección, los cuerpos no están en contacto.
La colisión por polígonos individuales (evaluar decenas de miles de triángulos deformables por animación) se evita categóricamente en combates dinámicos, ya que saturaría los hilos de CPU dedicados a la física y provocaría caídas drásticas de fotogramas.
Detección discreta frente a Detección continua (CCD): El problema del efecto túnel
El fallo de colisión más común en los juegos de acción es el efecto túnel (tunneling, conocido comúnmente como "atravesar con la espada" o "balas fantasma"). Ocurre cuando un proyectil u objeto a gran velocidad se salta por completo el volumen de colisión de su objetivo entre dos fotogramas consecutivos.
La física matemática del efecto túnel
La mayoría de simulaciones físicas utilizan por defecto la Detección de Colisiones Discreta. En este modo, el sistema solo calcula la posición de los cuerpos en instantes discretos de tiempo $t, t + \Delta t$:
Fotograma N (Tiempo = t): Fotograma N+1 (Tiempo = t + dt):
[ Bala / Espada ] --- Velocidad v ---> [ Bala / Espada ]
o o
(en x=10) (en x=60)
| Muro / Enemigo |
| [x=30..35] |
Si un proyectil viaja a velocidad $v$, su desplazamiento durante un único intervalo de simulación es:
$$\Delta x = v \cdot \Delta t$$
Si el grosor del objetivo $W_{\text{target}}$ más el diámetro del objeto en movimiento $D_{\text{proj}}$ es menor que dicho desplazamiento:
$$W_{\text{target}} + D_{\text{proj}} < v \cdot \Delta t$$
En el fotograma $N$, el objeto se encuentra completamente antes del objetivo; en el fotograma $N+1$, se encuentra completamente detrás. Dado que el motor discreto únicamente evalúa si existe solapamiento en esos dos momentos estáticos, nunca registra colisión alguna. La bala o la espada atraviesan al objetivo limpiamente como si fuera intangible.
Arquitecturas de Detección Continua de Colisiones (CCD)
Para mitigar el efecto túnel en balas, puntas de armas de cuerpo a cuerpo y personajes con traslaciones rápidas, los motores implementan Detección Continua de Colisiones (CCD) mediante dos estrategias principales:
+----------------------------------------------------------------------------+
| MODALIDADES DE CCD |
+----------------------------------------------------------------------------+
| 1. CCD POR BARRIDO (Sweep-based CCD / Volumen extruido) |
| - Extruye la forma geométrica a lo largo del vector de velocidad |
| - Resuelve la intersección temporal continua en el intervalo [0, dt] |
| - Determina el instante exacto del impacto (TOI ∈ [0, 1]) y la normal |
| - Desventaja: Consumo elevado de CPU; inviable para cientos de cuerpos |
+----------------------------------------------------------------------------+
| 2. CCD ESPECULATIVA (Speculative CCD / Expansión predictiva de AABB) |
| - Ensancha la caja AABB del objeto en la dirección de su movimiento |
| - Introduce restricciones predictivas de velocidad antes del impacto |
| - Ventaja: Mucho más rápida que el barrido geométrico continuo |
| - Desventaja: Puede causar "colisiones fantasma" ante giros repentinos |
+----------------------------------------------------------------------------+
En shooters competitivos, los desarrolladores suelen prescindir por completo de cuerpos rígidos simulados para las balas, recurriendo a Trazados de Rayo (Line Traces / Raycasts) instantáneos (hitscan). Al disparar, el motor proyecta un rayo matemático unidimensional desde el cañón hacia el objetivo, detectando al instante cualquier Hurtbox que intersecte la trayectoria sin sobrecarga física.
Causas del desfase entre el modelo visual y la física de combate
Cuando los jugadores sienten que "el golpe atravesó visiblemente al rival sin registrar daño" o que "fueron golpeados a medio metro de distancia", la discrepancia suele deberse a compromisos técnicos entre renderizado y física.
1. Aproximación por cápsulas frente a contornos anatómicos
El modelo visual luce pliegues de ropa, armaduras con relieves y capas ondeantes. Las Hurtboxes, en cambio, son cápsulas cilíndricas simplificadas acopladas a la estructura ósea.
Los desarrolladores deben optar por:
- Hurtboxes ajustadas (menores que el modelo): Protegen de impactos injustos en los extremos, pero provocan que golpes visibles en capas o hombreras no causen daño.
- Hurtboxes permisivas (mayores que el modelo): Garantizan que los roces impacten, pero exponen al jugador a recibir daño en el aire adyacente a su cuerpo.
2. Mezcla de animaciones y desincronización de Root Motion
Los personajes modernos emplean árboles de mezcla de animaciones (Blend Trees). Al cancelar un ataque pesado con una esquiva, el pipeline gráfico interpola suavemente los vértices de la malla visual durante cientos de milisegundos.
Sin embargo, las Hurtboxes actualizan su posición según la matriz rígida de los huesos. Si la velocidad de desplazamiento por física (Root Motion) sufre fluctuaciones de rendimiento o desfases temporales, la representación visual puede desviarse temporalmente de las cápsulas de colisión reales.
3. Hitboxes desarticuladas (Disjoint) y fotogramas residuales (Linger Frames)
En juegos de lucha y acción táctica, muchas Hitboxes se configuran intencionadamente como desarticuladas (disjoint), extendiéndose más allá de la hoja de la espada, o permanecen activas durante unos fotogramas tras concluir el golpe visual (linger frames).
Este ajuste compensa la latencia perceptiva del jugador y asegura que los ataques aéreos conecten consistentemente sobre enemigos agachados, logrando una sensación de impacto más gratificante a costa de una fidelidad visual estricta.
4. Efectos visuales cosméticos (VFX) sin datos de colisión
Los rastros de luz, llamaradas o destellos de energía asociados a un arma existen exclusivamente en los sombreadores de la tarjeta gráfica (GPU). No poseen propiedades físicas. A menos que el programador adjunte deliberadamente un colisionador al efecto, tocar el resplandor visual de un ataque no produce daño alguno.
Matriz comparativa de sistemas de detección de colisión
A continuación se comparan los principales enfoques de detección y sus compromisos técnicos:
| Modo de colisión | Coste computacional | Riesgo de túnel (Estático) | Riesgo de túnel (Dinámico) | Aplicación común | Desventajas principales |
|---|---|---|---|---|---|
| Detección discreta | Muy bajo (Prueba estática por frame) | Alto a velocidades elevadas | Alto a velocidades elevadas | Desplazamiento estándar, obstáculos grandes, enemigos lentos | Fallo de penetración severo si caen los FPS; atraviesa muros delgados |
| CCD por barrido | Alto (Ecuaciones continuas complejas) | Nulo | Nulo (si ambos cuerpos lo activan) | Puntas de armas blancas, jabalinas, choques de vehículos | Sobrecarga de CPU extrema en combates masivos multitudinarios |
| CCD especulativa | Moderado (Ampliación predictiva) | Muy reducido | Muy reducido | Físicas de muñeco de trapo (ragdoll), escombros dinámicos | Riesgo de colisiones en el aire si la trayectoria cambia abruptamente |
| Trazado de rayo (Hitscan) | Bajo (Intersección línea-plano) | Nulo en la trayectoria | Nulo en la trayectoria | Fusiles de precisión, detección de suelo, líneas de visión | Carece de volumen tridimensional; puede pasar por huecos diminutos entre cápsulas |
Diagnóstico y resolución de colisiones en el motor
Para identificar el origen de un fallo de impacto sin caer en impresiones subjetivas, es posible visualizar la geometría de colisión real mediante consolas de desarrollo.
1. Comandos de inspección en motores habituales
Unreal Engine (UE4 / UE5)
En versiones con la consola habilitada (tecla ~), los siguientes comandos exponen los volúmenes en tiempo real:
show collision # Renderiza todas las formas de colisión activas (estáticas y dinámicas)
show CollisionPawn # Restringe la vista a las cápsulas de daño y recepción de los personajes
pxvis collision # Muestra las líneas de malla física de bajo nivel de PhysX / Chaos
- Líneas cian o verdes: Colisionadores pasivos regulares (cápsulas, esferas, cubos).
- Líneas rojas o violetas: Formas de barrido ofensivo activas durante el fotograma actual (Hitboxes).
Motor Source / Source 2
En servidores locales y partidas personalizadas de títulos basados en Source:
sv_showlagcompensation 1 # Dibuja las cajas de impacto rebobinadas que el servidor utilizó para el cálculo
r_drawclipbrushes 1 # Muestra las superficies de bloqueo invisible del entorno (clip brushes)
2. Protocolo de diagnóstico de anomalías de impacto
Ante un ataque que falla inexplicablemente, se recomienda seguir tres pasos de verificación:
- Paso 1: Examinar la tasa de actualización de física y caídas de FPS
- Si la tasa de fotogramas desciende bruscamente durante el combate, el intervalo $\Delta t$ se amplía, facilitando que el arma atraviese el cuerpo del enemigo sin coincidir temporalmente con él.
- Paso 2: Comprobar la alineación entre huesos y colisionadores
- Mediante la visualización de depuración, verificar si las cápsulas de daño acompañaron de forma precisa el movimiento de la malla visual durante el fotograma de impacto. Un desfase suele delatar un error en el árbol de animaciones.
- Paso 3: Analizar la compensación de retardo (en multijugador)
- En partidas en línea, la inmensa mayoría de supuestos errores de colisión son consecuencia de la compensación de lag (Lag Compensation). Si el servidor autoritativo rebobina el estado del mundo y determina que el adversario ya se había cubierto al momento del disparo, el impacto se descarta, aunque el cliente local haya mostrado sangre o chispas.
Para distinguir con objetividad si un fallo en combate procede del diseño de los volúmenes, de la reconciliación de red o de discordancias en el renderizado, el análisis técnico estructurado de 365Finds permite identificar la causa raíz sin sucumbir a las habituales conjeturas de la comunidad sobre supuestos "motores rotos".