Big Red Button: Turn Your Team’s Phones Into One Big Console.

A bomb-disarming team game where everyone puts their phone on the table.

Most mobile games pull people into their own screens. Big Red Button does the opposite. It’s a team puzzle game on Games for Crowds where every player’s phone becomes one piece of a larger control panel. Phones go on the table, people lean in, and the team works together to read manuals, crack codes and disarm the device before the clock runs out.

If you’ve ever played a bomb-defusal game, the idea will feel familiar. It’s built for venues and events where you don’t want to haul in a lot of hardware but still want the game to feel bigger than people tapping away on their own phones.

This post covers the key ideas. If you’d rather follow along step by step, the full tutorial is in the video below.

The big idea: many screens, one console

A single phone can show one thing at a time. Big Red Button is designed so that one thing is never enough. The instructions for a puzzle are often in a long manual, the puzzle itself is somewhere else, and the clue you need might sit in a third document. Flipping back and forth on one device is slow and frustrating.

So the team spreads out across devices. One person keeps the manual open, another holds the puzzle, a third watches the timer. Together, a table full of phones gives everyone the helicopter view they need. That’s the whole point of the game: the more screens the team brings into play, the easier it is to solve.

Setting up a game

When you click Play now, you land on the host control screen. This is where you both set up and run the game.

Pick a scenario

The quickest start is to load a sample scenario, such as the bunker scenario shown in the video. Loading it updates everything at once: the theme, the timer, the game name, the lobby help text and the full set of modules. Samples are great if you just want to play, for example with family or friends, and even join in yourself.

Understand the modules

A scenario is built from modules. There are currently ten module types, and they fall into three groups:

• The timer. The clock counting down, 20 minutes in the sample.
• Documents. Written manuals that explain how the game is played and hold the information the puzzles depend on.
• Puzzles. Individual challenges such as cutting wires, flipping switches or entering a PIN. You might read the instructions in the defusal manual but enter the code in a completely different module.

The puzzles on their own are fairly simple. It’s the documentation that ties everything together and makes the game challenging. Some documents are long, which is exactly why you want them open on different devices.

Set up teams

The game is played in teams. Players within a team work together, while teams don’t interact with each other, they simply compete. Add or remove teams to match your group.

Three screens: host, presenter and players

• Host screen: where you configure and run the game. You can also move players between teams if someone joins the wrong one.
• Presenter screen: meant for a big screen. It shows a QR code and game code for joining, and during play it shows each team’s remaining time and a progress bar of solved puzzles.
• Player screen: what each phone sees. Players scan the QR code (or open a shared link), enter a name, pick a team and wait in the lobby.

No big screen? That’s fine. Just copy the player link and send it around.

The rules: time is everything

There’s no points system. The only score is the timer.

• Wrong answers cost time. Each incorrect submission takes 30 seconds off the team’s clock, bringing doom closer.
• Repeat offenders cool down. A player who answers wrong gets a cooldown before they can answer again: 10 seconds the first time, then 20, then 40, and so on. Guessing wildly quickly locks you out of answering, though you can still read documents and help the team.
• Win by disarming everything. The team wins only when every module is safe. They lose if the clock runs out, whether through slow progress or too many mistakes.

How a round plays out

Once the host starts the game, every player sees a dashboard listing all the modules and whether each one is armed or disarmed. Anyone can open any module at any time, so the team decides who does what: “You take the timer, I’ll open the defusal manual, can someone check the radio?”

In the video, the team tackles the main charge: a set of wires where the manual explains which ones to cut, with rules like “apply the first rule that matches.” Reading the rules on one device while cutting wires on another makes it far quicker. A correct answer disarms the module and shows a feedback message.

A few things make the teamwork flexible:

• Progress is shared. When one player disarms a module, it’s disarmed for the whole team.
• Several players can work on the same puzzle. Both can enter codes, but a wrong answer penalises the entire team.
• Modules can be solved in any order, unless the scenario is designed otherwise.

It’s not really a game, it’s a game interface

The sample scenario is simple: every puzzle can be solved straight from the documents. But the same building blocks support much trickier designs:

• Linear progress: the feedback from one solved puzzle unlocks the information needed for the next.
• Combined puzzles: a final module needs answers from several others before it can be solved.
• Scattered clues: a bit of information here, a bit there, and the team has to piece it together.

The story and the documents define how it all works. Big Red Button simply provides the interface. That’s what makes it so versatile: the theme doesn’t have to be a bomb at all.

Creating your own scenarios

There are a few ways to build a scenario:

• Start from a sample and modify it. A perfectly good, and often smart, starting point.
• Build by hand by adding modules yourself. It gives full control, but matching every module to its documentation takes care.
• Generate with AI. Choose the number of puzzles (up to 12), the difficulty and the setting, and the game builds a scenario for you. It works surprisingly well, but always play it through before using it with people, as the logic doesn’t always add up.
• Export, extend with your own AI agent, import. Export the game as a YAML file. It includes comments and a schema, giving an AI agent solid ground to work with. The agent can expand it well beyond 12 modules, and you import the result as a new scenario. This is the preferred route for larger, more complex games.

Whichever route you choose, playtest the whole game and fix anything by hand before your event. For a deeper dive into each method, read How to Create Your Own Big Red Button Scenarios.

One last tip: put the help in the documents

There’s a short help section for hosts on how to run the game, but no separate help for players on how to play it. All of that lives in the documents. If you want players to get more guidance on what’s happening and how things work, write it into the documents and it becomes part of the game.

🎥 Watch the full walkthrough in the video above, then grab a few phones, load a sample and give it a try.