The short version
A neat, tiny Bitsy game with a genuinely nice dynamic torch-light rendering effect, and keyboard movement that works correctly on desktop - but the touch-swipe movement path in this specific exported build never actually moves the player, confirmed by direct position checks across every direction over dozens of incremental touch events, despite the game's own swipe-direction flags computing correctly. Since movement is the only way to do anything in this game, that failure is disqualifying for a touch shelf regardless of the game's other qualities.
Biggest strengths
- Keyboard movement confirmed genuinely correct on desktop - direct player-position reads before and after each arrow-key press showed real, expected tile-by-tile movement (and correctly showed a wall blocking one direction while the other three worked), not just a visual impression
- A distinctive, well-executed dynamic torch-light rendering effect that genuinely responds to the player's position in the dark, which is a nice atmospheric touch for a 64x64-pixel jam constraint
- Genuinely MIT licensed, with no analytics or external asset dependencies in the built file
Biggest weaknesses
- Touch movement is confirmed broken in the exported build, not just theoretically risky: the game's own internal swipe-direction flags (swipeLeft/swipeRight/swipeUp) correctly flip to true in direct response to genuine touch drag input, but the actual player-position tile never changes in any of the four directions, across dozens of incremental touch events and multiple full gesture repeats - a real disconnect between the touch-detection layer and the movement-execution layer that does not affect keyboard input
- Since movement is the only interaction the game supports (there is nothing to do or see without walking around), this specific failure means a touch-only visitor cannot play the game at all, not merely play it awkwardly
- A very short jam entry even when working correctly on desktop, in keeping with its 2018 LOWREZJAM origins
Who it's for: Not currently recommendable for a phone visitor - desktop players with a keyboard can enjoy a short, atmospheric Bitsy piece.
Our recommendation: skip
5 / 10
Opening
Torch is a tiny Bitsy game made for LOWREZJAM 2018, a competition built around a strict 64x64-pixel canvas. The hook is atmospheric: the player carries a torch, and a soft radial light follows them through the dark, revealing just enough of the world to navigate by.
Keyboard works; touch does not, and this was proven rather than assumed
This review's most important finding came from testing movement directly against the game's own internal state rather than trusting a screenshot. On desktop, arrow-key presses were confirmed to move the player exactly one tile per press, reading the player's x/y position before and after each key: left, up, and down all moved correctly, and right was correctly blocked by a wall at that specific spot - a real, working collision system.
On a simulated phone, the same rigor was applied to touch. The game's own internal swipeLeft() / swipeRight() / swipeUp() functions were confirmed to correctly flip to true in direct response to a genuine touch drag exceeding the game's 30-pixel swipe threshold - so the touch detection code is not at fault. But reading the player's actual position before, during, and after the swipe - across ten incremental touch-move steps, multiple full gesture repeats, and all three unblocked directions - the player's tile coordinates never changed once. The direction flag correctly reflects the swipe, but the movement code that keyboard input successfully triggers never fires from that flag on touch.
Why this is disqualifying here
Movement is the entire interaction model of this game - there's no menu, no separate action button, nothing to do but walk into the dark and see what the torchlight reveals. A control failure that prevents movement entirely, on the exact input method most visitors to this shelf will be using, isn't a rough edge to note and move past; it means the game genuinely cannot be played on a phone as shipped.
Final Verdict
A well-made, atmospheric little Bitsy piece let down by a real, confirmed break between its touch-swipe detection and its movement code in this exported build - not a matter of taste or difficulty, but a control path that simply doesn't connect. Recommended only for desktop players with a keyboard until that's fixed upstream.
Pros and cons
Pros
- Keyboard movement confirmed genuinely correct on desktop - direct player-position reads before and after each arrow-key press showed real, expected tile-by-tile movement (and correctly showed a wall blocking one direction while the other three worked), not just a visual impression
- A distinctive, well-executed dynamic torch-light rendering effect that genuinely responds to the player's position in the dark, which is a nice atmospheric touch for a 64x64-pixel jam constraint
- Genuinely MIT licensed, with no analytics or external asset dependencies in the built file
- Correctly identifiable and fixable build process - the repo's own build script was run cleanly with zero dependencies, producing a self-contained file with no CDN references
Cons
- Touch movement is confirmed broken in the exported build, not just theoretically risky: the game's own internal swipe-direction flags (swipeLeft/swipeRight/swipeUp) correctly flip to true in direct response to genuine touch drag input, but the actual player-position tile never changes in any of the four directions, across dozens of incremental touch events and multiple full gesture repeats - a real disconnect between the touch-detection layer and the movement-execution layer that does not affect keyboard input
- Since movement is the only interaction the game supports (there is nothing to do or see without walking around), this specific failure means a touch-only visitor cannot play the game at all, not merely play it awkwardly
- A very short jam entry even when working correctly on desktop, in keeping with its 2018 LOWREZJAM origins