Memory Pulse: Tuning Four Numbers Instead of a Rulebook
A Simon-says format everyone already knows, and why getting the execution exactly right mattered more than any new idea would have.
A set of tiles lights up in a sequence. You repeat it back by clicking the same tiles in the same order. Get it right, and the sequence grows by one more step. Get it wrong, and the run ends. That's the entire format — I'm not claiming any originality here, this is the Simon-says pattern almost everyone's encountered in some form before. What I actually spent time on wasn't inventing the idea, it was making sure the execution of something this simple didn't have any rough edges, because a format this well-known gets compared instantly and unforgivingly against everyone's existing mental model of how it should feel.
The playback speed is the whole design problem
Almost everything interesting about this game lives in one number: how long each tile stays lit during playback, and how much gap sits between tiles in the sequence. Too slow, and an eight-tile sequence takes so long to play back that boredom sets in before you even get to test your memory. Too fast, and short sequences become a reflex-timing test for whether you can visually track a flash at all, rather than a memory test. I tuned playback speed to stay roughly constant regardless of how long the sequence has grown, rather than speeding up as sequences lengthen — the growing difficulty should come entirely from having more to remember, not from also making each individual tile harder to perceive as it flashes.
Where "no mistakes allowed" earns its harshness
A single wrong tile ends the entire run, all the way back to zero, and I did consider softening that — maybe a life system, or letting a near-miss slide. I backed away from it because the entire appeal of this format is that your score is a direct, honest measurement of how long a sequence you can actually hold in short-term memory. Any leniency added to that measurement muddies what the final number actually represents. A three-lives version tells you how well you did across several attempts blended together. The zero-tolerance version tells you exactly one true thing: this is the longest sequence you could reliably recall, on this specific attempt, no padding.
Spatial position over abstract order
Tiles are arranged in a fixed grid rather than appearing in a rearranged or randomized layout each round, and that consistency is doing real work. Keeping every tile's position fixed lets a player build spatial memory of the sequence — this corner, then that one, then back to the middle — instead of only relying on abstract memory of an ordered list with no physical anchor. Spatial memory tends to hold up longer than abstract sequence memory once you're past the first handful of steps, which isn't something I engineered on purpose so much as something that fell naturally out of keeping the layout stable and predictable round to round.
Highlighting the active tile had to be unambiguous
During playback, exactly one tile is visually active at a time, and I spent more effort than I expected making sure that highlight is impossible to miss or confuse with a neighboring tile, especially once the grid gets busy with tiles that have already flashed earlier in the same sequence. The failure mode I was most worried about wasn't the game being too hard — it was the game being unintentionally hard because someone genuinely couldn't tell which tile had just lit up, which isn't a memory failure at all, it's a legibility failure, and blaming the player's memory for a UI problem would be a dishonest way to make the game feel harder than it actually is.
I also made sure the tile a player clicks gives immediate feedback of its own — a distinct flash on click, separate from the playback flash — so there's never a moment of uncertainty about whether an input actually registered. A memory game that also makes you doubt your own input is measuring two different kinds of failure at once, and only one of them is the one this game is supposed to be testing.
Why the grid doesn't grow as sequences get longer
I considered growing the grid itself as a player advances — more tiles, more possible positions, a harder game in a second dimension beyond just sequence length. I backed off it because it would confound the one clean thing this game measures. A larger grid doesn't just make the game harder, it changes what's being tested, mixing in the challenge of scanning a bigger layout with the challenge of remembering a longer sequence, and those are different skills. Keeping the grid fixed means every player, at every skill level, is being tested against the exact same measuring stick — pure sequence memory, nothing else varying underneath it.
A deliberately small scope, and I'm fine with that
There's no theme, no unlockable tile sets, no combo scoring beyond how many steps you reached. For a format this established, I don't think it needs any of that to be worth having on the site. Sometimes the honest version of a well-known idea, tuned carefully instead of dressed up, is the right amount of game to ship, and I'd rather this be a clean, well-tuned version of something familiar than a bloated reinvention of something that already works.
If I'm honest, part of why I built this one is that it was a nice change of pace after Chess. That game demanded getting an enormous, precise rulebook exactly right. This one demanded getting four or five numbers — playback speed, gap timing, grid size, feedback clarity — exactly right, and nothing else. Different kind of hard, and a genuinely useful reminder that not every game on this site needs to be a big system to be worth building carefully. Small and exact beats big and approximate more often than the instinct to keep adding features wants to admit, and I suspect I'll need this exact reminder again the next time a project starts tempting me to bolt on one more system before the core one has even proven itself.
More from the Devlog