Sprite Garden

Opening

Sprite Garden wants to be a lot of things at once: a Minecraft-flavoured circular-planet sandbox, a farming sim with growth timers, a block-placement editor, a water-physics playground, and — genuinely surprising for a solo hobby project — a built-in reinforcement-learning trainer, complete with Start/Stop/Test Agent buttons and Q-table import/export. Popping open the shadow DOM turns up something like 110 distinct interactive controls. There is a lot here.

None of it matters, though, because the version currently live cannot walk.

The bug that sinks it

Holding the right-arrow key, the "d" key, or the touch d-pad's right button does absolutely nothing while the player is standing on the ground — no velocity, no position change, nothing. Digging into the served src/update/player.mjs/checkCollision.mjs, the cause is a boundary condition in the ground-collision test: after computing a horizontal step, the game samples eight points around the player's bounding box against the tile grid, and two of those points sit exactly on the tile the player's feet are already resting on. Math.floor() on that exact boundary value resolves into the solid ground tile below, so the game concludes "collision" and zeroes the player's horizontal velocity every single frame, for every attempted step, as long as the player is grounded.

Confirmed with direct instrumentation of the live build: horizontalInput computes correctly (1 for the right press), movementScale reads correctly from storage (1), a real velocityX of 0.825 gets calculated — and is thrown away one line later because checkCollision reports true at ground level. The moment the player leaves the ground (mid-jump), the exact same movement code works perfectly: holding right while airborne moved the character smoothly and predictably. Land again, and you're stuck until the next jump. The only way to cross the map is bunny-hopping sideways forever, which is obviously not the intended way to play a farming-and-digging game.

This is not a mobile quirk. It reproduces identically with a real keyboard press on a focused canvas in a desktop browser and with a genuine CDP touch dispatch on a phone profile. It is a core logic bug in the shipped build, not a controls problem — but since walking is the single most basic verb of a platformer, it fails the game outright regardless of platform.

Touch controls, for what it's worth

Credit where due: once you can actually reach them, the touch controls themselves are built correctly. Every direction, jump, break, farm, and block-placement button is a real <div data-key> wired to genuine touchstart/touchend/touchcancel listeners that set a shared touchKeys state object read by the same isKeyPressed() helper the keyboard path uses — no synthetic-click hacks, no missed preventDefault. Long-press-to-repeat on break/farm actions works as intended. If the ground-collision bug is fixed, the touch layer underneath it should hold up fine.

Getting to that touch layer is its own small saga, though. The pad is hidden by default (a raw hidden attribute on the container) and only appears after opening the "Controls" legend panel in the bottom-left corner and tapping a plain-text "Mobile Controls" row buried at the bottom of a list of keyboard shortcuts — nothing on the title screen hints that this is where mobile input lives. The project's own README does mention "tap the bottom corner panel for mobile controls," but that instruction isn't surfaced anywhere in the game itself. A recurring "press W/Space/R to begin" tutorial toast can also pop back up and physically sit on top of that toggle row, occasionally intercepting the tap meant for it.

Separately, every load throws a page error — Failed to register a ServiceWorker: The origin of the provided scriptURL ('https://kherrick.github.io') does not match the current origin — because the service worker registration in service-worker/init.mjs points at an absolute GitHub Pages URL instead of a path relative to wherever the game is actually hosted. Harmless to gameplay (the service worker's absence doesn't block anything else observed here), but it's a sign the build wasn't adapted for hosting outside the author's own domain.

Final Verdict

There's a real, ambitious little game trying to get out here, and the parts that aren't broken (art, touch-control wiring, the sheer scope of side systems) are genuinely well made. But a sandbox platformer that cannot walk on the ground it's standing on is not reviewable as a game — it's a tech demo with a critical regression. Not recommended until the ground-collision check is fixed; worth revisiting after that lands.