Your phone is the controller. Tilt it. Roll the ball into the hole.
The Idea
The phone is the controller. Not buttons: the device itself.
Build a game that uses the phone's accelerometer to move a ball. Not a screen rotation, but continuous tilt. Hold the phone flat like a tray, and the ball rolls the way gravity would pull it. The whole screen becomes a physical surface.
On desktop, arrow keys or WASD give the same control without the tilt. The game works everywhere, but it was designed to be played on mobile, held in two hands, tilted.
The distinction that mattered: the game reads the raw gravity vector from the accelerometer, not the screen orientation event. This means the ball responds to how much you're tilting, not which way the screen is facing. It's the same mechanic as a real wooden marble labyrinth.
Playing It
The feedback that mattered came from using it on a real device.
Building iteratively, rather than from a complete spec upfront, meant quality came from playing it seriously and noticing what felt wrong.
Rage Bait Mode
A product idea raised mid-conversation. Shipped in minutes.
No ticket. No spec. Just a thought mid-session:
The toggle is on the menu screen, styled in red-orange so it reads as dangerous before you even turn it on. Off by default. When it's on, every input is flipped: tilt right, ball goes left. Arrow key up, ball goes down. Works on mobile tilt and desktop keys both.
It's a genuinely good feature: harder, funnier, and it reframes the whole game for people who've already completed the levels. It came from just playing it and asking “what if it was worse on purpose?”
The point: features that come from using a product are different from features that come from a brief. This one only existed because someone played the game and had a thought.
What's Different
Two builds. Two workflows. Both useful.
ZombieVault was spec-first: 900 lines written before a single line of code. Ball Tilt Game was iterative, starting as an idea, then a build, then a series of real observations from actually playing it. Different projects call for different approaches.
In both cases, the human role is the same: decide what to build, use what gets built, and describe clearly what needs to change. The tool executes. The judgment is yours.
