Building Redblock: what multiplayer game dev taught me

Redblock Online started as an experiment: could I build a browser-based multiplayer aim trainer that felt responsive enough to actually be fun? The answer turned out to be yes, but it required solving problems I'd never encountered building traditional web apps.

The Stack Choice

Three.js for rendering, Next.js for the shell, WebSockets for real-time communication. I chose Three.js because I wanted to understand WebGL properly, not just use an abstraction on top of it. That decision made the project significantly harder and significantly more educational.

The Performance Constraint That Changes Everything

In a game, 60fps is the baseline expectation. That means your render loop has 16ms to do everything: process input, update state, draw the frame. In web development, a 100ms API response feels fast. In a game, 100ms of input lag feels broken.

This constraint forces you to think about performance differently. You can't allocate objects in the render loop—garbage collection spikes cause frame drops. You can't do synchronous work that blocks the main thread. Everything that can be pre-computed must be pre-computed.

What WebSockets Taught Me About State

In a request/response model, the client asks and the server answers. In a real-time game, both client and server are continuously emitting state. The client predicts movement locally and reconciles with the server's authoritative state.

This introduced me to the idea of optimistic updates—you apply the action locally immediately and then confirm or roll back based on server response. It's a pattern that shows up everywhere in product engineering, I just encountered it in an unusual context.

The Takeaway

Building something with hard performance constraints teaches you to think about efficiency in ways that transfer everywhere. After Redblock, I couldn't look at a React component re-rendering unnecessarily without noticing. The context changes. The habits stick.