The design constraint we keep coming back to: no individual should be able to move the outcome much on their own. It sounds like a limitation. It is the entire mechanism.
Why it matters
If one person can win, the rest are spectators. You get the loudest or keenest person in the room doing the work while several hundred others watch — which is a performance, not a crowd game.
When the input is a genuine aggregate, one person standing contributes a fraction of a percent. The immediate lesson, learned in about two seconds without anyone explaining it, is this is not about me. The immediate consequence is that people look at their neighbours.
That is the moment worth engineering for. Everything else is scaffolding.
What it rules out
Individual scoring. No leaderboards, no per-person results. The moment you can identify a contribution, you have re-created the phone quiz with extra steps.
Precision. An aggregate of hundreds of imprecise inputs is smooth and slow. Any mechanic requiring a fast exact value is out — the crowd simply cannot produce one.
Punishing failure hard. If a mistake ends the game, then one moment of collective hesitation kills the whole thing and the room feels blamed. Failure has to be survivable and legible.
What it demands
Visible aggregate feedback. The room has to see the number it is collectively producing, not just the outcome. Without it, nobody can tell whether joining in helped, and the incentive to coordinate evaporates.
A reason to keep going. Compliance gets you one round. What turns compliance into a game is escalation — the target moves, the gap narrows, the tower gets taller. That is where people start instructing each other, which is the actual product.
Tolerance for non-participation. A meaningful fraction of any room will not join in, for perfectly good reasons including mobility. If the game only works at ninety percent participation it does not work. Calibrating against the range the room actually produces, rather than a theoretical maximum, handles this automatically.
The uncomfortable implication
A game built this way is not much fun for one person to test. Our own prototyping is misleading by construction — a single developer waving at a webcam experiences none of the thing that makes it work.
We have started treating solo testing as strictly a check that the software runs, never a check that the design is good.