For my Family Feud project, I wanted the person running the game and the people watching it to have different experiences. I control the game from my iPhone, and the guests see the board on a TV.
The computer runs a server and a web app. Other devices connect to the server through their browsers. That means the host controls and the audience display are parts of the same game, and I don't need a separate native app for each device.
The project is on GitHub as FamilyFued. Under the hood it's a Flask app with a host page, an audience page, and the state needed to keep the board moving.
Two screens with different jobs
The host needs information that shouldn't show up on the TV right away. That includes the questions, the answers, the point values, and the controls for deciding what gets revealed.
The audience needs the show: hidden answers flipping over, round totals, team scores, strikes, and sound. Putting both on the same page would make that split awkward. The host page can be practical and dense, while the audience page can focus on the board.
My phone is the control surface. The TV is the shared display. The computer moves information between them.
Loading the questions
The host page can load a CSV file with questions, answers, and point values. The browser reads the file and turns each row into the structure the game uses.
That makes the question set an input to the game, not something I have to write into the audience page by hand. I can prepare the content in a spreadsheet, load it, and work through it from the host screen.
The host page also shows the current answers and whether each one is revealed. A checkbox marks an answer as flipped, and the host sends that state to the server. The board then shows what I've picked.
Keeping the game state shared
The server stores the active answers, the scores, the strike count, and the sound state. The host updates those values with requests, and the audience page asks the server for the current state.
In the code I wrote, the audience page polls the server on an interval and updates the board when something changes. It's a simple shared-state setup, not a WebSocket system.
That's how the devices relate. The phone never talks to the TV directly. Both connect to the computer's server, and the server is where the game state lives.
It also keeps the audience view swappable. Another compatible browser can show the board without changing how the host runs the game.
Making the board feel like a game
The audience page has answer panels that flip to show their contents. It also shows the points for each revealed answer, the round total, and the totals for both teams.
The host can award a round's points to a team and manage strikes. Those actions live on the control page because they're decisions I make as the game goes.
Sound is part of it too. There are controls for the intro music and the wrong-answer sound, along with playback on the audience side. A cue has to show up as a change the audience can notice. Otherwise, asking for the same state again and again would make it hard to tell a new event from an old one.
Those details take the app past a static board of questions. The host runs a sequence of reveals and reactions, and the audience sees the result.
Why this belongs in my project history
Family Feud is a good example of building something around how people will physically use it. I had a phone in my hand, a computer running the app, and a TV for the guests. Each piece needed a clear role.
The software combines file input, a server, browser interfaces, shared state, visual transitions, and sound. None of those parts is especially exotic, but together they make a setup that works.
I wouldn't call it a finished commercial game platform. It's a way to run this game across the devices I had around me, with one experience for the person running it and another for the people watching.
That's what I wanted to make work: controlling a game from my iPhone while the TV carried the show.