Colorfall

An online party game I designed, built, and launched to 68 players, with real-time multiplayer, bots, rooms, and a physics-based slingshot loop.

LiveGitHub

What it is

Colorfall is a browser party game for up to eight blobs. Every round reveals a safe color, gives everyone a short window to aim, then launches every blob at once. Players bump each other off course, try to stay inside the board, and survive until one blob is left.

I built it because the core idea was easy to explain but hard to make feel right: one slingshot input, a readable shared board, and just enough uncertainty that another player's move can ruin yours.

Aim
Arrow reveal

The multiplayer loop

Each round has a planning phase, a short arrow reveal, simultaneous movement, collision resolution, and a pause before the next safe color. The arrow shows intent, not the exact landing point, so velocity and contact still matter.

The input had to work anywhere on desktop or mobile. Your first press becomes the reference point; pulling away and releasing launches your blob in the opposite direction. That keeps your hand from covering the blob on a phone and lets you keep aiming even when the pointer leaves the board.

Everyone moves together

Building the full game

The interface and account flows run in Next.js and React. Cloudflare Durable Objects own live room state and authoritative match simulation, while Convex stores durable product data such as profiles, inventory, purchases, leaderboard records, and final match summaries.

Around the match loop I built public and private rooms, human-only matchmaking, a separate bot mode, mobile controls, room chat, Google sign-in, streaks, cosmetics, PostHog analytics, and a sandbox purchase path. Most of the work was not adding screens. It was keeping timing, replay animation, reconnects, and responsive layouts consistent while the game state changed underneath them.

Round events change the board

Wind adds a quick final push.

Launching it

I shipped Colorfall publicly and recorded 68 players. That was enough to prove strangers could enter the game and understand the interaction, but not enough to prove they would return or reliably find another human at the same time.

I added analytics after the first versions, which made the gap obvious: a multiplayer game needs more than visits. It needs coordinated activity, fast rooms, and a reason to play another match.

What stalled

The hardest product problem was cold start. Human-only matchmaking feels better when people are online, but an empty room makes the product look broken. Bots solve availability, yet leaning on them too heavily weakens the promise of an online party game.

I also expanded accounts, leaderboards, cosmetics, and payments before proving repeat play. Those systems made the product more complete, but they did not create the missing retention loop by themselves.

What I learned

Instrument the smallest fun loop before launch. Measure whether people finish a match and choose to play again before building the economy around it. For multiplayer products, distribution and concurrency are product requirements, not tasks to solve after the game is finished.

Colorfall is still live and playable. The useful result was not just the 68-player number; it was learning where polished engineering stopped compensating for an unproven return loop.