The Shot
A live crowd game
What if halftime wasn't something the crowd watched — but something the crowd played?
A concept video: the arena, the crowd and the game are a visualization. The Shot is in construction.
Building The Shot
The court stays empty. The game happens on the screen and in the crowd's hands.
Thousands of phones, two teams, one match on the big screen — and a result nobody controls on their own.
We're building it on three fronts at once, on top of a system that already runs a bingo night on the phones in one room and across four homes on four networks. The rules are written.
In construction. Every claim below says what it is: running, measured, or still a design.
Three fronts, built at once
The Shot is three pieces, each running its own part of the match on its own device. The rules of the game are the other half — they are written, and they come after this.
The phone
Your part of the match.
- Its own Puppet: your team, your role, what you did
- Draws the game itself — no video
The way in and a phone that keeps its own state. Drawing the match is what comes next.
Next A game client at 60 frames a second
The big screen
The show the whole building watches.
- Its own Puppet, with a memory of every fact
- Each screen can show something different
Switched off mid-match, it came back with nothing missing.
Next Real televisions, more screens
The console
Whoever runs the night.
- One app, for Android and iOS
- Every action recorded: who, and when
Screens paired by role; every moment goes out on its second.
Next The full console
Measured · 1 October 2026
Ten thousand phones press at once. 99 in 100 taps are on disk within 33 milliseconds.
Faster than the blink of an eye — and on disk before it counts. The same job on MySQL took almost three seconds: by then, the shot is already in the air.
83×
faster than MySQL
33 ms against 2,751 ms
4×
less CPU per message
111 µs against 473 µs
0
taps lost
in all 16 runs
How long a phone waits, on the same clock
99 of every 100 phones waited this long or less, at the busiest moment of the game. At this load MySQL ran out of room and its queue grew; the Puppet still had room to spare.
And with 4× less disk per message.
One desktop, 10,000 simulated phones, five taps per message and a burst of about 60,000 messages a second. Both confirm only once the tap is on disk. Puppeteer's FileSystem journal against MySQL 8.0.46 with Entity Framework Core, writing in groups.
Same promise on both sides: a tap is confirmed only once it is on disk, and both write in groups. Written one tap at a time, neither keeps up beyond 5,000 phones — and with 1,000 phones MySQL answers first.
What we tested
The same game, two places to keep it
Ten thousand simulated phones play the same game against the same server. Taps that arrive together wait in a queue and leave as one batch. The only thing that changes is where that batch is kept: a Puppet's journal, or a MySQL table.
The write each one does, shortened from the code of the test
foreach (var tap in batch)
db.Taps.Add(new TapRow {
Uuid = tap.Uuid,
Device = tap.Device,
N = tap.N });
db.SaveChanges();
// one transaction, committed to diskpuppet.Using("tally.TapBatch(@devices, @uuids, @ns);")
.WithParameters(p => {
p["devices", typeof(string[])] = devices;
p["uuids", typeof(string[])] = uuids;
p["ns", typeof(int[])] = ns; })
.PerformCommand();
// one journal entry, on disk before it returnsHow fast each one writes to disk, with no network in between: one writer in a loop for 8 seconds
| One at a time | In batches of 100 | ||
|---|---|---|---|
| Store | Time per writeless is better | Messages stored per secondmore is better | Messages stored per secondmore is better |
| Puppet journal | 0.40 ms | 2,477 | 219,837 |
| MySQL through Entity Framework | 1.15 ms | 866 | 10,714 |
| MySQL with plain SQL | 0.70 ms | 1,434 | 58,658 |
Even without Entity Framework, the Puppet is faster. Entity Framework sends each row of a batch separately; with plain SQL, the same MySQL stores five times more. The Puppet still stores almost four times more than that.
How the test was set up
- One machine, over loopback, without TLS. In a real deployment every MySQL write also travels to the database. The Puppet's journal is local to the game; replicating it is a separate step.
- MySQL in its best setup: native on the machine, a 1 GB buffer pool and no binary log.
Intel i9-14900 desktop with an NVMe drive, Windows 11. MySQL 8.0.46 with Entity Framework Core 8. Puppeteer with its FileSystem journal.
What it proves
Ten thousand participants, none of them alike
Every phone holds a different capability, and the same phone can hold another one the next turn. The result is the sum of all of them.
Design · modelledEvery device keeps its own history
The player on the phone and every fact on the big screen — each in its own journal, on its own device, replayed when it comes back.
Proven in the bingo · measured on the screenIt survives what breaks
A big screen switched off mid-match comes back with nothing missing. In our bingo, the night goes on while the organizer's phone is down.
Measured · proven in the bingoOne system, any sport
Swap the six roles and the same system plays soccer. Nothing underneath changes.
DesignHow it's played
Eight moments, in the order they happen. This is the game; the numbered steps after it are how we are building it.
Scan to enterScan to play
A code takes you in. It opens in the phone's browser — no app store, no account.
Two teams, one stand eachTeam Blue vs Team Purple
You enter as Blue or Purple according to your section. The building becomes two halves playing against each other.
The phone gives you a roleYour role
Not everyone does the same thing: some give the ball height, some aim it, some block. It changes every turn, so nobody is stuck with one verb all night.
One team attacks, the other defendsBlue attacks · Purple defends
Three moments inside one possession, and both sides are in all three: Lift against Block, Aim against Deflect, and then the shot goes up while the defenders charge. Next turn it flips.
Thousands of taps, one play
You act when your role is called, and only then. No single tap moves the ball — they add up, and your side's sum against theirs decides how high it goes and where it ends up.
The shot goes up, and everybody watches it landBucket!
The result is drawn on the big screen: the ball flies, and the whole building — not only whoever tapped — sees where it ends up.
New turn, new roles
Whoever was attacking now defends, and the six roles are dealt across the crowd again.
The side that is behind has to earn its last shotCOMEBACK SHOT EARNED!
When the turns run out, if somebody is ahead both stands build power at once — and the side that is behind only gets to shoot if it finishes with more. If the turns end level there is no race at all: sudden death, one shot each, for up to two rounds. The view pulls back, and what it pulls back to is thousands of people who were playing one match.
The frames are from the concept video at the top of the page — a simulation of the night, not a night that has happened. Its scoreboards are older than the rules: a game is four turns, every basket is worth two, and there are no quarters.
The shape of a game
Two to four minutes, with an arc — and the side that is behind has to earn its last chance.
Opening
Phones join; a draw on the big screen picks who attacks first.
The turns
The sides alternate. Four turns by default, six for a longer slot.
The Power Race
If somebody is ahead, both stands build power at once. The side behind has to finish with more.
The last shot — or none
Win the race and you shoot — one shot per basket behind, and you must make them all.
Sudden death
Level? One shot each, no power. Twice, then it is a draw.
How long a game runs depends on how it ends
- The leader holds the race~1:53
- A last shot that misses~2:13–2:28
- Decided in the first sudden-death round~2:34–3:08
- A second round, or a draw~3:14–3:48
From the first idea to the arena
Six steps done, five ahead.
01
Start with the crowd
The crowd is the controller. People join from their own phones — no account, nothing to set up.
02
Give everyone a role
Six roles, and your phone only ever shows you yours. Next turn it may hand you another.
03
Turn thousands of actions into one
No single tap moves the ball. Each side's roles add up against the other side's.
04
Make the arena react
Your phone gives you one instruction. The big screen shows what everybody did together.
05
Build a model we could watch
A full four-turn match we could step through and rewind — it is where Charge came from.
06
Put it in the arena
The arena view at the top of this page, to check the game reads from the back row.
07 Next
Play one phase end to end
One phase on real phones, real screens and the console, together.
08 Next
Put the screens on real televisions
The big screen on the hardware a venue hangs on its walls.
09 Next
Find where one machine breaks
The whole path of a tap, pushed until it drops something.
10 Next
Calculate the arena
What every device was measured to do, times the people in the building.
11 Next
Take it to an arena
With people. Nothing above substitutes for it.
Turn 1
Attack
Aim
Guide it toward the basket
Turn 2
Defence
Block
Keep the shot down
Same participant. Same game. Different capability.
One format. Any sport, any event.
Swap the six roles and the same system runs a different sport.
| Side | Basketball | Soccer |
|---|---|---|
| Attack | Lift | Build |
| Aim | Aim | |
| Shoot | Shoot | |
| Defence | Block | Press |
| Deflect | Block | |
| Charge | Counter |
Same format. Different sport. Same moment — your phone says SHOOT, you tap, and the whole building watches one ball.
First ideas · soccer
Where a sponsor fits
The screen is the product here, not a surface beside it — which changes what a brand can buy.
The ordinary places
The board, the frame around the play, the moment the teams are announced.
A brand that does something
A boost released into play, felt as part of the game. Both sides get the same — a brand cannot buy an advantage.
What comes back is participation
Not how many were in the building, but how many played: joined, acted, in which turn.
Who is part of the night
The crowd plays it, but the crowd isn't the only one with a part.
- Player
- Joins from a phone, receives a team and a role, and contributes to the play.
- Host / Operator
- Runs the night: starts the game, holds it at a safe break, releases the sponsor's moment, and can end it.
- Big Screen Controller
- Controls what the building sees — the game, transitions, sponsor moments and celebrations.
- Sponsor
- Has a place inside the experience: a branded round, an intervention, a reward, or a moment of its own.
Design · the night
Design · the admin
What it's built on
Not the first thing we've asked a room full of phones to do together — and the three below are not sketches. They run, and each has a page with the measurements on it.
The Village Hall
A bingo night running entirely on the phones in the room: no server holding the messages, no database holding the night.
The Village HallPeer to peer
The same bingo across four homes on four networks, over iroh — and what that does and does not establish.
Peer to peerPuppeteer
The substrate underneath: software subjects that carry their own identity, authority and history.
PuppeteerThis page grows as the work does. What's here is what we've decided, what we built to check it, and what we still don't know.
Same game. Different participants. Different capabilities. One shared result.