Tracer: Memorizing a Path You Can't Look Back At

I built Tracer the same week as Blink, and they make an interesting pair precisely because they're testing opposite things. Blink is pure reflex with zero memory involved — the target is on screen the whole time you're reacting to it. Tracer removes the target entirely before you're allowed to act on it. You watch a glowing path, it disappears, and only then do you trace it from memory. Same general shape of game — draw a line, get scored on it — completely different muscle being tested.

Why the preview has no time pressure

One decision I'm fairly happy with: there's no clock running during the memorization phase. The path shows itself for a fixed duration and then it's gone, but you're not being rushed while you're trying to encode it. All the pressure lives in the tracing phase afterward, once the thing you're supposed to reproduce is no longer visible. I tried a version early on where the preview itself was timed against you — see it faster, score higher — and cut it almost immediately, because it turned memorization into a second reflex test instead of what I actually wanted, which is a clean read of "how much can you hold in your head after one look."

Scoring speed and accuracy against each other

Once you start tracing, both how closely your line follows the real path and how quickly you finish feed into the score, and neither one is allowed to dominate completely. If accuracy alone decided the score, the smart play would be to trace agonizingly slowly, treating every pixel like it's load-bearing, which turns a memory game into a steady-hand game. If speed alone decided it, you'd get people flailing a rough approximation of the path as fast as possible and still scoring well. Splitting the score between both means a fast, reasonably faithful trace and a slow, near-perfect one can land in roughly the same range, which is the trade-off I actually want players making in real time instead of a single obviously-correct strategy.

Sharp turns are where memory actually breaks

Watching my own test traces back, the failure pattern is really consistent: smooth curves survive the memory gap fine, but a sudden direction change is where a traced line drifts off the real path almost every time. That tracks with how visual memory actually seems to work — you retain a general flow or gesture more easily than you retain an exact coordinate where something abruptly turned. I didn't design the scoring around that on purpose, it's just what fell out of testing paths with more corners in them versus paths that were mostly one long curve. It does mean path design matters a lot here — a path that's all gentle arcs is a very different difficulty than one with three hard-angle turns in it, even at the same total length.

Longer paths get harder in a way that isn't just "more distance to cover" — they're testing whether you can hold an increasingly long sequence in your head at all, the same way a growing Simon-says pattern does. I don't have a generator that deliberately dials in corner count versus arc length yet; paths are still closer to hand-placed than procedurally tuned for difficulty. That's the honest state of it at launch — the scoring logic is solid, the content pipeline behind it is still fairly manual.

Touch drawing needed its own accuracy allowance

The same accuracy formula runs whether you're tracing with a mouse or a finger, but a finger is a genuinely worse pointing device than a mouse cursor — it's wider, it occludes the exact spot you're drawing over, and touch coordinates just carry more natural jitter than mouse-move events do. Scoring both input types against an identical accuracy threshold meant touch users were structurally worse at this game than mouse users regardless of actual memory or steadiness, purely because of the input device. I added a small tolerance allowance specifically for touch input once I noticed my own phone attempts scoring consistently lower than equally careful desktop attempts at the same path, which isn't a difference I want the game accidentally measuring.

I'm treating that tolerance value as provisional rather than final. It's based on my own hand and my own phone, which is not exactly a rigorous sample size. If it turns out to be too generous or not generous enough once more people are actually playing this on a wider range of screen sizes, it's a one-line number to adjust — I'd just rather launch with a reasonable guess than hold the game back trying to perfectly solve input parity before a single other person has touched it.

Why the path glows instead of just being drawn as a line

The preview renders as a soft neon glow rather than a plain thin line, and that's not just an aesthetic choice, it changes what you actually encode into memory during the preview window. A crisp thin line invites you to memorize exact coordinates — this pixel, then that pixel — which is a brittle way to remember anything and falls apart the moment the line disappears. A glowing, slightly diffuse stroke reads more as a gesture, a general flow through space, which happens to be closer to how visual memory actually seems to hold onto motion. I didn't set out to design the visual style around memory science, but once I noticed that a softer render made my own recall noticeably better in testing, keeping it that way stopped being a style decision and started being a functional one.

I'll be curious to see how this one and Blink get compared once both are out at the same time, since they're both testing something a person can't consciously improve just by trying harder in the moment — reflex speed on one side, short-term visual memory on the other. Neither one has a strategy you can think your way into mid-round. You either have it that run or you don't, and the only lever you actually control is whether you keep coming back for another attempt.