How Boxing Arcade Games Work Under the Hood

This is a look inside the machine. If you have ever wondered what a browser boxing game is actually doing between the moment you press a key and the moment a fighter falls over, this guide takes the lid off the one running on this site.

Everything described here is in the open. The engine lives in /js/game/ and each game's own logic is a single file at /games/<name>/game.js. Nothing is minified, and you can read any of it with your browser's developer tools.

The frame loop and why delta time matters

A game is a loop that runs once per displayed frame. The browser schedules it through requestAnimationFrame, which calls back roughly sixty times a second on a standard display — and roughly a hundred and forty-four times a second on a fast one.

That variability is the first problem any game has to solve. If a fighter moves "three pixels per frame", they move more than twice as fast on a 144 Hz monitor. The fix is delta time: each frame measures how many seconds have passed since the previous one, and every movement is multiplied by it. A fighter moves "two hundred pixels per second" instead, and the game plays identically on any display.

There is a second problem hiding behind the first. If the tab is backgrounded, or the browser stalls, the gap between two frames can be enormous — several seconds. Multiplying by that would teleport everything across the ring in a single step, and collisions would be missed entirely. So the delta is clamped: this engine never simulates more than 50 milliseconds in one step, no matter how long the real gap was.

The state machine a game runs through

Every game moves through the same seven states: loading, ready, countdown, playing, paused, game over and victory. Transitions between them are restricted — you cannot go from ready straight to game over, for instance — which sounds like bureaucracy until you have debugged a game that let a stray keypress end a run before it started.

Only playing advances the simulation. Everything else still draws, which is why a paused game shows the frozen frame rather than a blank canvas, and why the Ready screen has a real ring behind it rather than an empty rectangle.

The overlays you see in those states are real HTML, not drawn on the canvas. That is deliberate: the instructions on the Ready screen are text a screen reader can announce and a search engine can read, which would not be true of pixels.

How a punch is represented

A punch is not an event. It is a small state machine with a duration:

startup  →  active  →  recovery  →  idle

When you press the jab key, the fighter enters startup with a timer set to that punch's startup duration. When the timer expires, it enters active; when that expires, it enters recovery; when that expires, it is idle and can act again. The whole thing is driven by subtracting delta time from one number.

Those durations are the game's balance. The full table is in our punch mechanics guide, but the shape is consistent: bigger punches have longer startup (easier to see coming) and much longer recovery (more dangerous to throw).

What happens the moment a punch connects

Hit detection runs every frame of the active phase, not once at the start. That matters, because it means movement during a punch is meaningful — stepping back mid-jab genuinely makes it miss.

The resolution runs in a fixed order, and the order is the rules:

1. Range. Measure the horizontal gap between the two fighters. If it exceeds that punch's reach, the punch whiffs — no hit, and the attacker still pays the recovery.
2. Invulnerability. If the defender is inside the invulnerable frames of a slip, the punch is dodged. A slip beats everything, including the unblockable Surge punch in Neon Boxer.
3. Guard. If the defender is blocking, damage is reduced by 86% when the guard height matches the punch and about 47% when it does not, plus chip damage. The defender also loses stamina, which is why turtling is not free.
4. Connect. Otherwise the punch lands. If the defender was in their own recovery phase, it is a counter: 45% more damage, 40% more knockback and 70% more points.

A landed punch interrupts whatever the defender was doing, applies a short stun proportional to the damage, and breaks their combo. That last part is what makes the combo meter a measure of defence rather than just aggression.

What the opponent AI is actually doing

The opponent is the same Boxer object you control, with a decision layer attached instead of a keyboard. That is not a detail — it means it pays the same stamina costs, suffers the same recovery frames and obeys the same range rules.

The decision layer is a small state machine: approach, hold, attack, defend, retreat, recover. When a state's timer expires, the AI picks the next one by weighted choice rather than a coin flip, with weights derived from the current gap, its stamina, its health and its fighting style.

Five styles exist, and they change the weights rather than the rules:

The one rule that keeps an AI fair

Here is the most important line in the whole AI, expressed in English: the opponent cannot respond to your wind-up faster than its difficulty's reaction window allows.

When you start a punch, the AI does not act on it immediately. It sets a delay drawn from the difficulty preset — 0.5 seconds on Medium, 0.26 on Expert, with some random variation — and only then decides whether to block, slip or ignore it. An AI without that delay is trivial to write and feels dreadful to play, because it is reacting to information on the frame it appears rather than on the frame a person could have seen it.

How the fighters are drawn

There are no sprite sheets on this site. Every fighter is drawn from Canvas paths each frame: two tapered limbs for the legs, a rounded rectangle for the trunks, a rounded rectangle for the torso, a circle for the head, an arc for the hair, and two circles with a thumb and a cuff for the gloves.

The pose is derived entirely from the Boxer's live state. The lean comes from the punch phase. The glove position is interpolated along the punch's reach using an easing curve — a hook arcs, a straight punch does not, an uppercut rises. The yellow ring you see around a glove during a wind-up is drawn because phase === 'startup', which means the telegraph and the hit detection can never disagree.

Drawing this way has a practical consequence beyond originality: a game is a few tens of kilobytes of JavaScript with no assets to download, and it scales to any resolution without a second set of artwork. The canvas is letterboxed — a fixed logical stage of 960×540 fitted into whatever size the page gives it — so one coordinate system works from a 360-pixel phone to a 4K monitor.

Where your score goes

Nowhere. Specifically, into localStorage under the key boxingarcade:scores, in the browser you played in.

When a run ends, the engine assembles the fields that game reports — best score, longest combo, furthest round, best accuracy, fastest reaction — and merges them with what is already stored, keeping only genuine improvements. Reaction times are the one place we filter: anything under 60 milliseconds is discarded, because it is an anticipatory press rather than a real response, and storing it would make the record meaningless.

There is no server. There are no accounts. There is no leaderboard. If your browser blocks site storage, the games still work and the page tells you your scores will not be remembered, rather than silently losing them.

One frame, traced end to end

Here is everything that happens in a single frame of a duel game, in order. At 60 frames per second this whole sequence runs in under 16.7 milliseconds.

1. The browser calls the loop with a timestamp. The engine schedules the next frame immediately, before doing any work, so an exception in the middle of a frame does not stop the game permanently.
2. Delta is computed and clamped. Now minus last time, divided by a thousand, capped at 0.05 seconds. Non-finite or negative deltas are discarded.
3. Global keys are checked. Pause works in every state; start works in ready, game-over and victory.
4. Combo, particles and screen shake advance. The combo decays, particles move and die, trauma falls by roughly 1.9 per second.
5. The game's update runs. Player input is read as named actions, the player boxer advances its phase timers, hit detection runs if a punch is active, the AI decides and acts, the opponent advances its own timers, positions are clamped to the ring and pushed apart if they overlap.
6. End conditions are evaluated. Health at zero, round timer expired, ladder complete.
7. The HUD is written. This is the only place per frame that touches the DOM, and it writes text and widths rather than creating elements.
8. The canvas is cleared at device resolution, including the letterbox bars.
9. The transform is applied — one setTransform combining the letterbox scale, the device pixel ratio and the centring offset, so the game draws in logical coordinates and never thinks about screen size.
10. Screen shake is applied as a translate, if trauma is non-zero.
11. The game's draw runs inside a clip rectangle: ring, fighters back to front, name plates, round band, callouts.
12. Particles and the flash overlay draw on top.
13. Input edges are cleared. Everything that was "pressed this frame" stops being pressed, which is why a single key press can only trigger one punch.

Why the canvas is letterboxed

Every game declares a fixed logical stage — usually 960×540 — and the engine fits that stage into whatever size the page gives the canvas, centring it and leaving bars where the aspect ratios disagree.

The alternative, stretching the logical stage to fill the element, distorts everything: circles become ellipses and a fighter on a tall phone looks squashed. The other alternative, making the logical size match the element, means a wide monitor shows more of the ring than a phone — which is a gameplay difference disguised as a rendering decision.

Letterboxing keeps every player looking at exactly the same playfield. It costs some screen area and it is the right trade.

The transform is also where pointer input is undone. A tap at a screen coordinate is converted back through the same scale and offset before the game sees it, which is why tapping a target works identically on any screen shape.

Common misconceptions

"The AI must be reading my inputs." It is not, and the code is open. It observes your wind-up after a delay drawn from the difficulty preset. What makes an Expert opponent feel psychic is that 0.26 seconds is genuinely short, not that it has extra information.

"The difficulty just gives enemies more health." It changes eleven values, and opponent health is not one of them. Health is set per game and per opponent; difficulty changes reaction window, timing window, speed, aggression, guard rate, damage in both directions, spawn rate, score multiplier, ramp rate and mistake budget.

"Canvas games must be heavy." These are tens of kilobytes each. The weight in most web games is assets, and there are none here — the artwork is paths and the audio is synthesised.

"Random input should be able to score well." It cannot, and we checked. The automated test harness drives every game with randomised keyboard and pointer input for forty-three seconds and typically produces a few hundred points and an accuracy in the 40–70% range. A human playing attentively scores an order of magnitude more, which is a reasonable sign that the games reward attention rather than volume.

"The games must share code by copy-paste." They share an engine and five kits. Twenty-six of the thirty games are 40–120 lines of configuration plus hooks; the other four are written directly against the engine. Change a punch's recovery time in combat.js and every game changes at once — which is a feature and also a good reason to be careful.