Case study
Games for the room
I build party games to give people something to do together. The interesting design problem is deciding when software should take their attention, and when it should give it back to the room.
Problem
A multiplayer game can keep everyone busy on a phone and still give them very little to do with one another. For a hosted game, I want the conversation, guesses, disagreements, and reveal to happen between people. The screens need specific jobs.
My contribution
| Area | What I built and why |
|---|---|
| Divide the screens | Built separate presenter, host, and team-buzzer views for Family Feud. The audience sees the board; the host can see unrevealed answers and make rulings. |
| Give the host control | Built game phases, reveal controls, pauses, and corrections. The host can leave space for a reaction or fix a ruling without treating every interruption as a restart. |
| Keep the match together | Built shared room state, controller recovery, and official result publication. Devices can return to the room state, and the event platform can consume the result separately. |
Decisions
| Choice | Why it matters |
|---|---|
| Send each role the information it needs | Family Feud builds snapshots for each role. Unrevealed answer labels stay out of the public view while the host can use them to judge an answer. |
| Let people decide when to continue | Timers bound timed play, while host controls handle reveals, pauses, and rulings. A countdown cannot know when the room has finished reacting. |
| Record the result alongside the game | The Redis room update and official result are saved together before delivery is attempted. Event scoring receives that result separately, so the match does not need to know the event points rules. |
- Shared displayPrompt, revealed answers, scores, and the next public beat.
- Host phoneUnrevealed answers, rulings, pause, correction, and continue.
- Team buzzerA brief input when the team needs to act, then attention back to the room.
What it enables
Family Feud is the worked example: two teams, a public board, a host controller, and optional team buzzers. Other games use different arrangements, including shared devices and private prompts.
The design goal is more attention on the people playing together. Reconnect and scoring behaviour can be checked in software; whether the pace and rules work for a new group needs play in the room.
Lesson
The useful abstraction is the repeatable machinery: joining a room, reconnecting, sharing state, and publishing results. The game still owns its rules and rhythm. Keeping those separate leaves room for a word game and a social-deduction game to feel different.