A target blinks into existence. Your crosshair snaps across the screen, clicks it, and the next one is already up. It feels instant. It feels clean. But did you actually get faster this week, or did it just feel good? Your reaction time test answers a narrower question — how fast you respond to one cue — and it stays your cleanest baseline. Aiming asks for more: cross the distance, land on the target, and don't sail past it. To measure that, you need more than a stopwatch.
Aiming is a measured skill, not a vibe
Flicking to a target is the most-studied movement in motor science. In 1954, Paul Fitts showed that the time to hit a target follows a strikingly simple rule: the smaller and farther the target, the longer it takes — and the cost scales with the logarithm of the distance-to-size ratio, not the raw distance (Fitts, 1954). Decades later, that relationship was reframed in the language of information theory — aiming as a communication channel with a bitrate (MacKenzie, 1992). That "aim as a channel" idea is exactly how a flick can be scored.
What "aim throughput" actually measures
Throughput turns a flick into a single number — bits per second — by dividing how much targeting difficulty you cleared by how long it took. The clever part is that the effective target size is set by the spread of where your clicks actually land, so accuracy is baked in. Fast-but-wild and slow-but-perfect both score lower than fast-and-tight. That is the whole point: you cannot cheat throughput by spraying.
A single trajectory hides a lot of detail, and each piece is its own story:
| Signal | What it tells you | |---|---| | Reaction-to-first-move | How long before your aim even started moving | | Flick time | The fast ballistic sweep toward the target | | Overshoot and corrective submovements | Whether you sailed past and had to dial back | | Path efficiency | How straight your line was (ideal distance ÷ actual) | | Click precision | How close to dead-center you landed |
Throughput is the headline; the breakdown tells you where the time went. Slow to start is a reaction problem, lots of corrections is a stopping problem, low precision is a control problem.
How to read your throughput
The number that matters is your throughput trending up over your own sessions. These training games have no validated benchmark bands yet, so there is no honest "good aim is X bits per second" line to print — and we won't invent one. Compare yourself to your past self and to players on similar hardware, then let the in-app score card show the exact figure. Your simple-RT bands live on the reaction time test; they don't transfer to an aim metric.
Aim throughput is measured on the pointer the browser reports, in screen pixels — shaped by your mouse, sensitivity, DPI, and OS mouse acceleration. That's the pointer, not your hand, and it's not motion capture. So absolute throughput is same-setup relative: great for beating your own last run and for competing on equal hardware, not an absolute ranking of humans.
Because a training game puts your mouse, sensitivity, and monitor inside the score, it has more moving parts than the simple test, not fewer — which makes it richer to train and, honestly, noisier to measure. For the difference between raw reaction speed and aim execution, read reaction time vs aim speed. Flicking is only half of aiming — its moving-target cousin is tracking aim and time on target.
The honest limits
Sub-frame path detail depends on your mouse's polling rate: we record what we actually sampled and
widen the ± confidence band when the trace is sparse. The dimensionless numbers (path efficiency,
overshoot ratio) travel between setups a little better than raw bits-per-second, but none of it is
device-proof. And as always, we timestamp the browser-observed stimulus and your event.timeStamp
response — never a photon on your retina, a nerve firing, or a muscle contracting. This is a training
tool with real telemetry, not a lab-grade instrument.
Want to put a number on your own flicks? Step into the Arena and start a session, then watch the trend.
Sources & context
Paul Fitts's original paper on the speed-accuracy law is Fitts, 1954, and the information-theoretic "throughput" reformulation used here is MacKenzie, 1992. Those studies use controlled apparatus, not a browser and a gaming mouse, so treat them as the model behind the metric, not a promise of a fixed number for your setup. The cursor path itself comes from the browser's pointer events (MDN documents getCoalescedEvents and Event.timeStamp). For how PulsarMS timestamps stimulus and response — and why every score carries a ± band — read how we measure.