Blink Started as a One-Trick Reflex Test

There isn't much to explain about what Blink does right now, and that's kind of the point of writing this one down before it inevitably grows. A dot appears somewhere on screen. You click it. Another one appears. You click that one. The game measures how fast you're doing this and gives you a time at the end. That's the entire feature list. I want a record of it looking like this, because I already know myself well enough to know it won't stay this small.

Why the simplest possible reflex test first

I wanted one game on the site that tests literally nothing but raw click-to-target speed, with zero decision-making involved. Every other reflex-adjacent thing I've built so far — 60 Sec Survival, Day Rider — asks you to read a scene and decide what to do about it. Blink asks nothing. A target appears, there's exactly one correct action, and the only variable is how fast your hand can execute it. It's less a "game" in the traditional sense than it is a stopwatch with a target painted on it, and I think that's a legitimate thing to build on its own rather than something that needs constant justification for being simple.

The one thing I did agonize over: target size

Even with a concept this stripped down, there was one number I kept changing: how big the clickable target is. Too large and everyone posts roughly the same time regardless of actual reflexes, because the target is basically impossible to miss — you're measuring monitor refresh rate more than the person. Too small and it stops being a reflex test and becomes a precision-aiming test, which is a different skill I already have a color-matching and shape-drawing game covering in other ways. I settled on a size where a genuinely fast reaction still has to be reasonably accurate to register, but where missing isn't the dominant outcome for an average player. It's a small tuning knob for how little else there is to tune.

What I'm deliberately not building yet

There's an obvious list of things this could grow into — decoy targets you're not supposed to click, a survival mode where the window to react keeps shrinking, some kind of tiered ranking instead of a raw millisecond number. I know this list because I already want all of it. I'm holding off specifically because I don't yet know if the core loop — click the dot, beat your last time — is actually fun enough on its own to justify building on top of it, and the only way to find that out is to ship the bare version first and see if it's worth returning to.

If this comes back later as something bigger, I want to be able to point at this exact post and see how far it moved from "a dot, a click, a timer." Right now that's genuinely the whole thing, and there's something useful about writing that down before I forget just how small the original idea actually was.

Where the actual latency lives

Measuring a click-to-target time sounds like it should just be "timestamp when the target appears, timestamp when the click lands, subtract." In the browser, that subtraction is measuring more than a person's reflexes — it's also measuring paint timing, event dispatch overhead, and whatever else the browser's main thread happens to be doing at that exact millisecond. A target that's technically rendered to the DOM isn't necessarily painted to the screen at the same instant, and the gap between those two things is small but not always negligible. I spent a chunk of time making sure the timer starts as close as possible to the actual paint rather than to whenever the JavaScript that spawns the target happens to run, since starting the clock even a few milliseconds early would quietly inflate everyone's times in a way no player could ever account for or notice.

It's a genuinely small amount of error either way, and I'll admit part of why I cared this much is that a raw-reflex game is the one place on this site where that kind of measurement noise is the entire product. A bullet-hell shooter can absorb a few milliseconds of imprecision without anyone noticing. A game whose only output is a millisecond number cannot — the measurement has to actually be trustworthy, or the whole thing is just theater.

No leaderboard yet, and that's deliberate too

There's no global high-score list wired up for this one at launch, which is unusual for a site where most games get leaderboards fairly early. Part of that is timing — the leaderboard infrastructure isn't built yet at all, this is one of the first few games on the site. But part of it is that I want to sit with the raw millisecond numbers myself for a while first and see what a genuinely good time actually looks like before I commit to ranking tiers or a "rank" label a player sees after every run. Slapping an S-rank or an A-rank on an arbitrary threshold I haven't actually validated against real attempts would be worse than no ranking at all — it would just be a made-up number pretending to be a meaningful one.

So this one ships quiet on purpose: no rank, no leaderboard, no fanfare. Just a number you can try to beat against yourself, and a game small enough that I can hold the entire thing in my head at once. That's not nothing. It's actually a pretty useful place to be able to reset back to, the next time I build something that starts sprawling before I've proven the core of it is worth sprawling around. It's a small game, shipped small, and I'd rather it stay boring for a while than get complicated before anyone's actually asked it to, or before I've watched enough real attempts to know what "complicated" should even mean here. Right now I genuinely don't know, and I'd rather admit that than guess.