boxmegle | Devpost

Inspiration

We saw Omoggle, and we saw the Omegle Pushup fades, and thought we could do something that’s actually fun, interactive, useful and technically complex. Boxing… the ability to turn user input with just your webcam into a full boxing match, paired with realtime sync and events.

What it does

Instead of passive camera feeds or simple repetition counters, boxmegle turns your browser into a real virtual boxing ring. There’s a real queue that users can enter, and join up with other random players who want to box. There’s real combat detection (jabs, hooks, uppercuts), and even tracks dodges and blocks so that real boxing technique can be put to good use.

How we built it

This app might sound stupid, but trust us it was actually pretty hard to pull off.

System Design

The entire boxing experience lives on a webserver. It sends data to this webserver through a game loop that carries its own state machine that manages room lobbies, validates physical movement vectors, executes authoritative hit detection, and broadcasts state updates back to both peers in real time.

The game loop is a whole beast of its own. Every frame, both clients stream lightweight arrays of joint coordinates (wrists, elbows, shoulders, ears) over WebRTC data channels (for video calling), and within the websocket. This happens at 60Hz, where we needed to address decoupling the client and server connections.

Challenges we ran into

System design??? We knew that for this, blindly vibe coding wasn’t going to cut it. We had to actually understand how data was moving because coding agents aren’t capable of making decisions, like how the state machine handles data, or how we use that data to create telemetry values so we could serve movement stats to the user.

Accomplishments that we're proud of

Video calling worked, websockets worked, the hit detection and computer vision worked. We had fun building our project. We got to explore the city. Thanks Summerhacks!

What we learned

Building a real-time multiplayer game over WebRTC turned out to be way harder than a typical web app. We had to build a 60Hz server state machine that handles network lag, tick synchronization, and hit detection without freezing the browser. Offloading computer vision tasks to Web Workers and WebGPU was the only way we could keep the canvas rendering at a smooth 60 FPS. Along the way, we learned how to use Kalman filtering to clean up noisy webcam tracking and balance WebSockets with WebRTC DataChannels for low-latency networking.