Real-time · production
Fenderesky فندرسکی
Party games played live on everyone’s phone — join a room by code.
Stack
- Backend
- FastAPI Django WebSockets
- Frontend
- JavaScript
01 The problem
A party game on phones only works if everyone in the room sees the same moment at the same time — the same prompt, the same vote, the same score.
And nobody at a party will install an app or make an account to join.
02 What I built
Designed, built and run by one developer.
A real-time party-game platform. One player opens a room, everyone else joins with a short code, and the game runs over WebSockets with live voting and scores. Four modes: Faztomime (acting), Who’s most likely to, Whose line (funniest answer) and Dr. Fenderesky.
- Rooms that players join from their phone browser with a short code, no sign-up.
- Four game modes: Faztomime (acting), Who's most likely to, Whose line (funniest answer) and Dr. Fenderesky.
- Live voting, with results and scores pushed to every phone as they change.
- A real-time backend over WebSockets and a plain-JavaScript client light enough for any phone.
03 Screens
The live product.
01 / 04
Pick a character and a name. That's the whole sign-up.
The lobby, where the host picks a mode and the rounds.
The lobby on a phone, where the game is actually played.
The join screen on a phone.
04 Architecture
How Fenderesky fits together.
- Component
- Request
Connections
- Player phones to JavaScript client
- JavaScript client to WebSocket hub , WebSocket
- WebSocket hub to Game server
- Game server to Rooms by code , join · leave
- Rooms by code to Game modes , rounds
- Game modes to WebSocket hub , votes · scores
05 Key decisions
What I chose, why, and what it cost.
-
Decision
WebSockets, not polling
Why
Votes, reveals and round changes have to reach every phone at once. A persistent connection lets the server push the moment something changes.
Trade-off
Long-lived connections to manage, and phones that sleep or switch networks mid-game need to reconnect cleanly.
-
Decision
Join by room code, no accounts
Why
At a party the barrier to joining has to be zero. A code and a name are enough to play.
Trade-off
Identity only lasts as long as the session; a player who drops has to rejoin with the code.
-
Decision
The server owns the game state
Why
Phones only render state and send inputs, so a vote can't be counted twice and a player who joins late sees the current round, not a stale one.
Trade-off
Every mode is a state machine on the server, so adding a mode is backend work, not just a new screen.
06 Try it yourself
Fenderesky is running. Go and use it.
No account needed. Open a room, then join it from a second phone or tab with the room code.