Fifty-Six Lily Pads

Fifty-Six Lily Pads asks a simple question with a nasty twist: every lily pad a frog jumps away from sinks behind it, so a pond that starts with fifty-six tiles only ever shrinks. Two players — or one player and a basic AI — place three frogs each on a procedurally generated pond, then take turns hopping them along the pond's own connective paths to eat flies (worth one to three points) and a rare lotus (worth five), until neither side has a legal jump left. It's a clean, well-scoped idea for a Ludum Dare 56 entry, and reading the source confirms it's exactly as advertised: the board is a real Voronoi diagram relaxed into hexagon-like cells, not a disguised grid, so no two matches look alike.

On this shelf, none of that gets a chance to matter, because the board cannot be touched.

The board never receives a single touch

The "Movement Phase" — select a frog, tap a destination — is the entire game once the opening placement is done, and on a phone it simply does not respond. This was not a hunch from reading the code; it was tested directly, repeatedly, and conclusively. Real touch events were dispatched through Chromium's input pipeline (not synthetic page-script events, which would only prove the game's listeners exist rather than that touch actually drives them) at a quick tap and then at held durations of 150ms, 500ms, 1000ms and 2000ms, on multiple different board tiles. In every single case, mousePressed() — the one function every placement and movement action in the game funnels through — was called exactly zero times. A phone player who gets past the start menu is looking at a fully rendered, fully generated pond that will never place a single frog for them, no matter how they tap or how long they hold.

Reading the shipped code explains exactly why. The two start-menu buttons are built with the p5.touchgui library, which registers its own document-wide touchend listener and — regardless of whether that touch landed on a button or not — unconditionally calls preventDefault() on it. That single call blocks the browser's synthetic mousedown/click compatibility events a real touchscreen would otherwise fire after a tap, and it turns out that compatibility event is the only path this game's own mousePressed() was ever wired to for touch input: the sketch never defines p5.js's touchStarted(), which is the correct, direct way to receive real touch events. The result is a game where a single small UI library, pulled in only to skin two menu buttons, quietly disables touch for everything else on the page.

Even the menu buttons it was added for aren't fully reliable. p5.touchgui polls a single-frame isPressed flag once per animation frame rather than reacting to the press event itself, so a normal-speed tap that completes before the next frame is sampled gets silently swallowed — testing found a deliberate ~150ms hold worked every time, while a quick, natural tap on the same button repeatedly did nothing at all. That's a survivable rough edge on its own; combined with a completely inert game board, it isn't the deciding factor here, just further evidence that touch was never seriously tested before release.

What the game actually is, once you can reach it

Wiring input directly to the game's own logic (to separate "does the mechanic work" from "does touch reach the mechanic") confirms the underlying design is sound on a mouse. Placement, selection and movement all update the board, score and turn order exactly as the in-page "How to Play" panel describes, and watching a frog's old lily pad visibly sink after it jumps away gives the scarcity mechanic real weight — later turns force real trade-offs between chasing points and keeping an escape route open. The AI opponent plays a simple greedy strategy (always taking the highest-value reachable tile), which is enough to give a single player something to react to without pretending to be a serious challenge.

The presentation earns real credit for a 48-hour jam entry: an original music theme, four distinct sound effects for placing and moving frogs, and hand-illustrated pink and blue frogs, flies and lotus flowers on a calm teal pond, rather than default engine placeholder art. The project page even carries a Zenodo DOI and a genuine MIT LICENSE file at the repository root — verified by reading it directly rather than trusting the registry note, which is worth confirming given how often jam repos skip a licence entirely.

What it doesn't have is much length: three frogs each on one small board is a five-minute match, and the randomised layout is the only thing bringing a player back for another round. That's a reasonable trade for a jam game judged over a weekend; it's a thin one for a shelf that's asking for a recommendation with no time limit attached.

Final verdict

The mechanic here is genuinely interesting and the presentation punches above its jam-game weight, but none of that is reachable on a touchscreen. This isn't a case of clumsy touch controls costing a point or two — the board accepts precisely zero touch input, tested across a quick tap and holds up to two full seconds, so a phone player cannot play the game at all past the title screen. That is the exact failure this shelf exists to catch, and it's disqualifying regardless of how the underlying game plays on a mouse. Fifty-Six Lily Pads is not recommended for this shelf, and would need the p5.touchgui preventDefault() behaviour fixed (or the library dropped entirely in favour of p5's own touchStarted()) before it could be reconsidered.