Building Poke
Building Poke from a design idea, reusing server code from a project still in progress, and how a debug tool became the most played mode.
Poke started with a pitch from a close one. She had the entire game idea mapped out: two coin colors in a grid, where piece placements push closest coins outward. She designed it. I just wrote the code.
To get a server running fast, I borrowed the WebSocket room architecture from A Game About Cars, a project still in progress. The session logic, state relays, and socket handling were already solid, so I lifted the backend module intact instead of writing a new one.
The hardest part of the build was animation synchronization between clients. Server state resolves instantly, but the visual push shockwave takes hundreds of milliseconds to play out. If one client started animating coins before the other received the turn payload, the board states drifted out of sync visually. I had to lock input queues and align tween playback to explicit server tick timestamps so both players see the exact same movement at the same time.
Quick game mode was not planned as a product feature either. It started purely as a local debug shortcut so I could spin up two browser tabs and test room connections without typing six-digit codes repeatedly. It worked so well in testing that I kept it in the main menu.
Invite that person to play!