In action and fighting games, responsiveness is everything. A player who inputs a punch or a kick expects the visual collision to align perfectly with the gameplay logic. If a punch clearly passes through an opponent's head but fails to register a hit, the game feels broken. Conversely, if a player is hit by an invisible attack, the game feels unfair.
To establish combat consistency, developers rely on the math of **Hitboxes and Hurtboxes**. These invisible geometric shapes dictate physical contact, strike regions, and defensive block frames. In this post, we will explain the collision logic behind browser-based action games like *Neon Stick Fighter*, exploring the code and math of fighting game physics.
1. Hitboxes vs. Hurtboxes
Although game characters look like complex stick figures or sprites, calculating collisions on detailed character outlines is extremely slow. Instead, developers represent the character as a set of simple bounding shapes:
- Hurtbox: The geometric zone representing the character's physical body. If an opponent's attack overlaps this area, the character takes damage.
- Hitbox: The zone representing the range of an active attack (like a sword slash or punch). This zone is only active during the strike frame of the animation.
When the code runs, it constantly checks if any player's active **Hitbox** intersects with any enemy's **Hurtbox**. If an overlap is detected, a strike is registered, triggering damage and knockback physics.
2. The Mathematics of Bounding Box Collision (AABB)
In 2D browser brawlers, characters are usually oriented vertically. This allows developers to use **Axis-Aligned Bounding Box (AABB)** collision detection. AABB is the fastest method of checking for rectangular overlaps because it requires no complex trigonometry or matrix math.
For two rectangles, Box A and Box B, a collision occurs if and only if they overlap on both the X and Y axes. The formula in Javascript is:
- const isOverlapping = (rectA.minX < rectB.maxX) &&
- (rectA.maxX > rectB.minX) &&
- (rectA.minY < rectB.maxY) &&
- (rectA.maxY > rectB.minY);
Because these checks consist of four simple comparison queries, a browser can process hundreds of AABB calculations per frame without dropping below 60 FPS.
3. Coding Parry Windows and Block Frames
To make brawlers deep and engaging, developers implement blocking and parrying. A block reduces incoming damage, but a **Parry** stuns the attacker, turning the tide of the battle.
A parry is scheduled based on precise frame timings:
- Defensive State: When a player presses the Block key, the game sets the character state to `blocking`.
- Parry Frame Window: If an enemy's hitbox collides with the player's hurtbox within the first **6 to 10 frames** (approx. 100-160ms) of the block starting, it is declared a "Perfect Parry."
- Outcome: The game cancels the player's hit stun, inflicts `hitStun` (stun state) on the attacking enemy, plays a parry sound ring, and spawns impact particles.
- Late Blocks: If the collision occurs after the parry window has expired but while the block key is still held, the player registers a normal block, taking reduced damage and zero knockback.
Conclusion: Consistency yields responsiveness
Understanding hitbox overlap algorithms and parry mechanics allows developers to create responsive combat systems in browser sandboxes. By combining efficient AABB rectangle checks with precise, frame-rate-independent state updates, browser games can achieve the tight, competitive feel of classic arcade brawlers.