An aim trainer asks you to hit a dot that is already there. A parry asks you to start moving at the right moment, in the right direction, and to stop. Those are three different failures, and the run separates them instead of averaging them into one accuracy figure.
The clock starts when the wind-up becomes visible and stops the instant the mouse leaves rest. Not when you hit something — when your hand decided to move. That separates reading the attack from executing it.
The direction the blade was travelling at the moment it crossed the guard ring, compared with the line it had to meet. A hundred per cent is dead on the line; forty-five degrees off is another line entirely.
How far past the ring the flick kept going before it turned back. This is the number that indicts a sensitivity: every degree past the line is a degree to travel home again before the next attack lands.
The guard ring sits at nine degrees of view rotation. At 30 cm/360 that is exactly 0.75 cm of mousepad; at 15 cm/360 it is 0.38 cm. Both are reachable. The difference shows up in what happens after you get there.
A sensitivity above what your wrist can stop does not fail on the way out — it fails on the way back. The blade arrives, carries three or four degrees past the line, and then has to travel that distance again before the next attack is readable. Twenty attacks in, that is most of a second spent recentring. The run reports it as one number in degrees, which converts straight back to centimetres because you told it your cm/360.
A site that measures input cannot ship a game where turning the graphics down changes the score. So the simulation and the renderer are separated, and the separation is a rule rather than a habit.
| System | Setting | Why |
|---|---|---|
| Simulation rate | 120 Hz, fixed | Never varies with frame rate, quality tier or device. A parry window is the same width on a 50 Hz laptop and a 240 Hz monitor. |
| Input path | Pointer lock with unadjustedMovement | Raw counts where the browser exposes them, coalesced events where it does not, so the operating system’s mouse acceleration never reaches the judging. |
| Judging clock | Simulation time only | Hit-stop, camera kick and every other effect run on a separate visual clock. Nothing the animation does can move a window. |
| Resolution | Dynamic, 60–200% | Frame time is answered by shrinking the framebuffer first, before any other setting moves. The canvas stays the same size on screen. |
| Randomness | Seeded | A seed is twenty attacks in a fixed order. The daily duel is the same duel for everyone, and any run can be replayed exactly. |
| Downloads | None | No model files, no textures, no audio samples. The room, the opponent and every sound are generated in code on the first frame. |
Three things, all of them properties of your hand and your mouse settings: how long you take to start moving once an attack is readable, how accurately a fast flick lands on a direction, and how far past the target that flick travels. Those are the same three quantities you trade off when you choose a sensitivity.
Move the mouse into the line the attack is arriving from — a cut coming at your left is met by moving left. The ring at the centre of the screen shows how far you have travelled; the guard commits when the dot crosses it. Thrusts are answered with the dodge key, not the mouse.
Because it is the most expensive habit in any first-person game. A thrust is deliberately unparryable, so a guard thrown at it is movement spent on nothing, with the blade out of position when the next real cut arrives. The run counts those separately as flinches.
Yes. Enter your cm/360 and DPI and the view turns by exactly the degrees per mouse count your game does, using the same yaw maths as the Keymap sensitivity converter. That is what makes the overshoot figure transferable: it is measured in degrees, so it converts straight back to centimetres of mousepad.
No. The simulation runs at a fixed 120 Hz whatever the renderer manages, and quality settings never touch the input or the timing. If a tab loses time to a pause or a background switch, the run is marked as not comparable rather than scored.
No. The whole duel runs in the browser, results stay on the page, and the only thing stored is your sensitivity and difficulty in this browser’s local storage.
No, but the numbers get more interesting with one. Any mouse that reports cleanly will do; if the reaction figures look erratic rather than slow, check the hardware first with the mouse tester before blaming your hand.
Keymap Labs builds browser tools for measuring gaming input. PARRY//ZERO is an original game made for this site; it is not affiliated with any published title, and the numbers it reports are properties of your mouse and your hand, measured by code that owns the whole chain from the pointer event to the verdict.