Tracking Aim and Time on Target: How Motion Aiming Is Measured

One target. It strafes, it jukes, it will not hold still. Your job is simple and brutal: keep the crosshair on it. Not near it. On it. That is a completely different skill from the snap-flick your reaction time test hints at — flicking is one explosive movement, tracking is a continuous fight to stay glued down. Measuring it means watching every millisecond your aim held, and every millisecond it slipped.

Tracking is closed-loop control

Following a moving target is continuous control — the same family of skill that pilots and surgeons get tested on. The classic laboratory version is the pursuit or critical-tracking task, where the target follows an unpredictable path and the apparatus records how well you stay locked to it (Jex, McDonnell & Phatak, 1966). A tracking game does the same thing, with the target's path generated from a seed so the score can be re-checked against exactly the path you saw. Instead of one reaction, you produce a few thousand tiny corrections, and the interesting information is in how well they add up.

What tracking actually measures

We sample your cursor and the target position densely through the round and compare them moment to moment:

| Signal | What it tells you | |---|---| | Time-on-target % | The fraction of the round your crosshair was inside the target | | RMS tracking error | Your average distance from center when you drifted off | | Tracking lag | Whether you trail the target's movement instead of leading it |

The headline number is time-on-target % — literally your aim-lock uptime, from 0 to 100. It is intuitive and bounded, which makes it a clean thing to grind upward week over week.

How to read your score

Time-on-target answers "how much of the round did I win?" The other two answer "how am I losing it?" A big RMS error means you get flung off on direction changes — you can hold a straight line but the juke breaks you. High lag means you're reacting to the target instead of predicting it, so you're always a beat behind. Improving usually shows up as lag shrinking first, then error tightening.

There is no validated "good tracking is X%" band for these games yet, so we won't print one. Your score is your setup's score: compare it to your own trend and to like-for-like hardware, and let the in-app card show the exact figure. If you want a broader training framework around drills like this, see reaction time training drills; for where raw reaction speed fits in the aiming picture, read reaction time vs aim speed. The flick side of aiming — and its throughput metric — is covered in aim throughput and Fitts's law.

The honest limits

The time resolution of the error signal is capped by your mouse polling rate and the browser's sampling cadence — so we report the rate we actually achieved and never quote tracking lag more precisely than we sampled it, widening the ± confidence band when the trace is thin. A training game also stacks more hardware into the measurement than the simple test does (mouse, sensitivity, monitor), which is exactly why its scores stay relative. And we only ever see the browser-observed stimulus and your event.timeStamp response — never photons, nerves, or muscles. This is a training range, not a lab tracker.

Ready to see your aim-lock uptime? Start a tracking round in the Arena and chase the trend.

Sources & context

The critical/pursuit tracking paradigm behind this game is Jex, McDonnell & Phatak, 1966; that work used dedicated control hardware, not a mouse in a browser, so treat it as the model behind the metric rather than a fixed benchmark for your setup. The cursor and its timing come from the browser's pointer events (MDN documents PointerEvent and Event.timeStamp). For how PulsarMS timestamps what it can actually observe — and why every score ships with a ± band — read how we measure.