The short version
Find Ten Seconds's idea is a genuine improvement on the memory-matching genre it comes from: pairs don't have to be an exact letter-and-number match to score. A pair sharing just a colour, or two odd numbers, or two vowels, still counts for something, so the puzzle becomes a running judgement call about the best available match rather than a binary hit-or-miss. That idea is well worth playing with. The problem is entirely about how it renders on a phone: measuring the canvas directly on a simulated 390-pixel-wide touch device found it rendering at 250×156 CSS pixels regardless of the much larger space actually available, which works out to roughly 15-pixel tiles in a ten-column board — well under any reasonable touch target size, and confirmed identical on the developer's own official page, not something this hosting introduced. The game's own `windowResized()` formula carves out side-panel space assuming a wide container and doesn't hold up on a narrow portrait phone, where it eats most of the available width. Pinch-zoom is technically available as a workaround, since nothing in the page disables it, but needing to zoom and pan a ten-second-countdown matching game to hit a tile at all is a real, decisive shortfall for a shelf built around phone playability.
Biggest strengths
- A genuinely good idea for the genre: partial-credit matching (colour, parity, vowel groups) turns a binary pairs game into a continuous best-available-option puzzle, confirmed functional and scoring correctly during testing
- Zero build step and the simplest install of any candidate reviewed this cycle — index.html and a plain js/ folder, no bundler, no missing assets
- No analytics anywhere in the source, confirmed by a direct scan
Biggest weaknesses
- Measured directly rather than assumed: the game canvas renders at 250×156 CSS pixels on a 390-pixel-wide phone viewport, producing roughly 15-pixel-wide tiles across a ten-column board — confirmed via the exact same measurement on the developer's own official GitHub Pages build, so this is a pre-existing layout limitation, not anything introduced here
- The root cause is traceable to the game's own `windowResized()` sizing formula, which allocates space for a side panel proportional to the board's column count before sizing the board itself — a calculation that holds up on a wide desktop window and collapses the playable area on a narrow portrait phone
- Two hardcoded absolute favicon and web-manifest paths would have 404'd against this site's root rather than the game's own folder; fixed here, but a reminder this project was built assuming it would only ever be hosted at a domain root
Who it's for: Desktop players who want a clever spin on tile-matching; not a fit for a phone unless you're willing to fight pinch-zoom for every move
Our recommendation: Play it on desktop — the phone experience needs a real layout fix first
5.5 / 10
Classic tile-matching games ask a simple, binary question: do these two match, yes or no? Find Ten Seconds, built for Ludum Dare 51, asks a more interesting one: how well do these two match? A pair sharing an exact letter or number scores the most, a shared colour scores something, and failing either of those, a pair of vowels or a pair of odd numbers still counts for a little. That's a genuinely clever adjustment to a well-worn formula, turning "find the pair" into "find the best pair available right now" — a small design change with real texture to it, confirmed directly by playing through several rounds.
A layout bug, measured rather than guessed at
Here's what actually happens on a phone, checked with direct measurement rather than assumed from a screenshot: the game's canvas renders at 250 by 156 CSS pixels on a 390-pixel-wide viewport, in a board ten tiles wide. That works out to roughly 15-pixel-wide tiles — smaller than a phone's status bar icons, and nowhere near the size a finger can reliably land on. This isn't a guess or a rendering fluke in this particular test environment: the identical 250×156 canvas appears on the developer's own official GitHub Pages build, measured the same way, which rules out anything about this hosting causing it.
Reading windowResized() in game.js explains why. The formula computes a minSize for the board, then subtracts six tile-widths' worth of space from it to make room for the side panel where a selected tile is displayed — a reasonable idea on a wide desktop window, where six tile widths is a small fraction of the available space. On a narrow portrait phone, where the container's width is already the constraining dimension, that same subtraction eats most of what was available, and the formula has no separate portrait-specific path to compensate. The practical result is a board that's technically present, technically touch-responsive — p5.js maps a tap to the same mousePressed callback a click uses, so the underlying input handling is sound — but sized for a device this game was never actually tested on.
Nothing in the page disables pinch-zoom, so a determined player can zoom in and pan around to hit individual tiles. That's a real workaround, not a fiction, but doing that continuously in a game whose entire hook is a countdown pressure timer is a genuinely awkward way to play, and it's not something this shelf can credit as "working on a phone" in the sense that matters.
What else turned up
Two absolute paths — the favicon links and web manifest — pointed at /favicon/..., which would have resolved against this site's root rather than the game's own folder; both are relative now. A Cannot read properties of undefined (reading 'clientX') error fires on most taps, traced to the CDN-loaded Materialize.js library rather than the game's own code — it didn't block anything in testing, but it's not a clean console, and it's present on the official build too. The project also still points at a 2016-vintage p5.js release from a CDN, the kind of thing that tends to happen once a jam entry stops being actively revisited.
Where that leaves it
A 5.5 reflects real, tested merit in the design — the fuzzy-matching idea deserves to be seen — weighed against a confirmed, specific, reproducible failure on exactly the device category this shelf exists to serve. This isn't a case of "might have issues on some phones"; it's a measured 15-pixel tile grid on the standard phone viewport this shelf tests against. Worth playing on a desktop browser; not ready for a thumb without the developer revisiting that resize formula.
Pros and cons
Pros
- A genuinely good idea for the genre: partial-credit matching (colour, parity, vowel groups) turns a binary pairs game into a continuous best-available-option puzzle, confirmed functional and scoring correctly during testing
- Zero build step and the simplest install of any candidate reviewed this cycle — index.html and a plain js/ folder, no bundler, no missing assets
- No analytics anywhere in the source, confirmed by a direct scan
- A real, if dated, technical foundation: p5.js's default touch-to-click mapping means the fundamental tap-to-select interaction works the same way with a finger as with a mouse — when the tile underneath is actually big enough to hit
Cons
- Measured directly rather than assumed: the game canvas renders at 250×156 CSS pixels on a 390-pixel-wide phone viewport, producing roughly 15-pixel-wide tiles across a ten-column board — confirmed via the exact same measurement on the developer's own official GitHub Pages build, so this is a pre-existing layout limitation, not anything introduced here
- The root cause is traceable to the game's own `windowResized()` sizing formula, which allocates space for a side panel proportional to the board's column count before sizing the board itself — a calculation that holds up on a wide desktop window and collapses the playable area on a narrow portrait phone
- Two hardcoded absolute favicon and web-manifest paths would have 404'd against this site's root rather than the game's own folder; fixed here, but a reminder this project was built assuming it would only ever be hosted at a domain root
- A recurring `Cannot read properties of undefined (reading 'clientX')` error fires on most taps, traced to the Materialize.js UI library loaded from a CDN rather than the game's own code — harmless to gameplay in testing, but a console that's never clean
- Relies on an old, unpinned CDN copy of p5.js 0.5.6 (from 2016) alongside a mismatched 0.5.7 DOM addon, the kind of dependency drift a project stops actively maintaining accumulates