Shane and I shipped this during Phase 3 at Flatiron. Rails handled accounts and scores. The browser handled the game loop. The Web Audio API gave us timing data from the track. It was not a production game, but it was one of the first projects that made me feel how unforgiving interactive software can be.
He leaned more into the Ruby side and the analyzer that turned audio data into something we could schedule against. I spent more time in the JavaScript that translated that stream into hit windows and feedback. Pairing meant we both touched pieces we would not have chosen alone.
Feel
Rhythm games are tuning problems before they are feature lists. If the input feels late, the whole thing feels cheap. We adjusted timing, feedback, and scoring until playtests stopped complaining about the game lying to them.
Stack
Rails and Postgres handled users, scores, and a leaderboard. JavaScript handled the canvas and interaction. For a school deadline, that was enough. For me, the useful part was learning that audio, UI, and state all have to agree in the player's hands.
problem
We wanted to make a rhythm game in the browser with persistent scores, even though timing-sensitive UI was a rough fit for a school-project timeline.
constraints
- The game loop, audio timing, and button feedback all had to agree closely enough to feel playable.
- Rails handled accounts and scores while the browser handled the part players actually felt.
- Collaboration meant splitting ownership without turning the project into two disconnected halves.
what it taught me
- Interactive work exposes timing problems fast. A few milliseconds can make a feature feel broken.
- Pairing works better when the boundaries between systems are explicit.
- Early projects are useful when they show how you learned, not when they pretend to be production products.