Element Puzzle

Element Puzzle asks a small elemental creature to reach an exit tile across a short sequence of screens, changing between fire, earth, water and air forms to get past obstacles each form can or can't cross. It's a real, ranked competition entry — js13kgames.com's own record shows it finished 7th out of 129 games at js13k 2014, a genuine top-6% result rather than an inferred or unconfirmed accolade — and the game itself backs that up with a clean pixel-art presentation, a move counter, and 20 levels packed into a 13-kilobyte build.

None of that matters here, because the game cannot be started on a phone.

Every touch input misses its target, and the reason is visible in the source

The very first screen is a title card with a single "START" button, drawn on one full-page canvas with a plain click listener. On desktop, clicking it works immediately and drops straight into a level-select grid. On a simulated phone, it was tapped at its exact visual location — verified against a screenshot of exactly where the button renders — a dozen separate times: quick taps, held presses of 300ms and a full 1000ms, and a grid of seven points scattered around the button to rule out a small measurement error. None of them worked. The title screen never advanced once across the entire test.

Reading the page explains why. This build has no <meta name="viewport"> tag anywhere in its HTML, so a mobile browser treats it as an old desktop-oriented page and falls back to a legacy behavior: render it at a phantom 980-pixel-wide layout, then shrink the whole thing down to fit the actual screen (measured directly at roughly 40% scale on a 390-pixel-wide phone). That part is mostly harmless on its own — plenty of old pages get shrunk and still work — but a diagnostic listener attached directly to the page caught the actual bug: the click event's own clientX/clientY come through in the shrunk, on-screen coordinate space (exactly where a finger touched), while the canvas element's own layout geometry — what the game's click handler uses to work out where on the canvas that tap landed — is reported in the original, unshrunk 980-pixel space. Divide one by the other the way this 2014 codebase does and every tap resolves to the wrong point on the canvas, nowhere near where it visually landed. The game's own tutorial text later says "tap it to go there," so this was clearly meant to be a touch game; the viewport tag needed to make that math consistent on a modern mobile browser was just never added.

What's actually there, judged from the one platform that works

Desktop confirmed the underlying design is sound: a level-select grid (only level 1 unlocked to start), a short onboarding hint pointing at the exit tile, a visible move counter, and restart and quit buttons handled as clearly as the rest of the interface. The elemental-transformation hook — becoming fire, earth, water or air to cross different obstacles — is a reasonable, well-worn puzzle idea, and a 7th-place finish against 128 other competition entries says other people found the execution solid enough to rank it highly. It's also worth noting plainly that this build silences its own sound effects on any mobile user agent by design, a decision visible directly in the source (navigator.userAgent.match(/Android|iPhone|iPad|.../)) — so a fixed version of the touch bug would still ship silent on a phone.

Final verdict

A confirmed top-10-of-129 js13k placement and a legitimately designed touch-first puzzle are undone by one missing tag: without a viewport meta declaration, this build's touch coordinates and its canvas geometry disagree with each other on a real mobile browser, and the result is a title screen that cannot be pressed by any tap, of any length, at any of the several points tested. That is a complete failure of this shelf's central requirement, not a rough edge, and no amount of puzzle quality on the other side of that button changes the score.