A stand at four in the afternoon, second day of a conference. People walk past with their merchandise bags, glance at the counter and keep going. Nobody wants a product explained to them while standing. But put up a big screen with a moving leaderboard and two tables shouting at each other, and they stop.
I've been building live games for conferences and stands for a while, and the main lesson is this: the technology matters less than the mechanic. A weak mechanic with WebSockets is still a weak mechanic. Here's what I've seen work.
It has to be playable in ten seconds
Rule one: nobody installs anything. Each team joins with a code or by scanning a QR from their tablet or phone, and they're in. Every extra step at the door (downloading an app, creating an account, remembering a password) loses you players before the game starts.
Rule two: the big screen isn't decoration. It's the reason the crowd around you keeps watching. They see answers come in, the leaderboard reshuffle and one team overtake another. Without that screen, the game is a solo experience on a phone. With it, it's a show.
The team quiz, with some tension
The base format is a team quiz, and on its own it's fine but predictable. What makes it work is the clock. In one of the games, the points for a correct answer depend on how much time is left when the team answers. The logic lives on the server, which holds the real clock:
$puntos = $correcta
? (int) round(1000 * ($restante / max(1, $duracion)))
: 0;A fast correct answer is worth almost a thousand points; one in the last second is worth almost nothing. That changes how people play: less debate, quicker decisions. And because time is calculated on the server, nobody gains an edge by tampering with their phone or having a worse connection. Each team can also answer only once per question.
A team's screen during a question: visible countdown and four options.If you want to see how everything stays in sync across screens, I wrote about it in more depth in my piece on real-time games with Laravel Reverb.
Wildcards: the mechanic people talk about
If I had to keep just one mechanic, it would be wildcards. Before a question, each team can pick an effect and fire it at another team: blurred vision, flicker or floaters (those specks drifting across your field of view). The team on the receiving end gets a fogged, flickering or smudged screen just as they try to read the question.
One table picks the wildcard and its target; next to it, the screen of the team about to receive it.It works for a design reason: it turns a quiz into an interaction between people. You're no longer only competing against the difficulty of the questions, but against the table next to you, who grinned at you before hitting you with blurred vision.
But wildcards without rules turn into a war. So each team gets one use of each effect, and the system stops you attacking the same team twice. The attacks spread the spotlight around and nobody ends up flattened. Those rules are in the code and can also be customized according to the needs of each game.
Different formats for different moments
Not every game suits every situation. My rule of thumb, after seeing them in real use:
Team quiz and topic wheel, for seated audiences with a moderator setting the pace.
Swipe against the clock, for quick decisions. You get it in five seconds and it works standing up.
Escape room by boxes, with chained challenges, for groups who'll stay a while and want to collaborate.
Memory, for the classic stand: one person, one tablet, two minutes.
Memory: the game for people just passing by
Memory is my favourite for stands because it solves the opposite problem to the quiz: it needs no group and no moderator. Someone walks up, taps two cards and they're playing. Each pair links a concept with its message, so you're telling a story while they play, without it feeling like a presentation.
Organisers tend to like one detail: every game is logged. The start time is stored when it begins, and when it ends we record the duration, the attempts, the pairs found and whether it was completed. That tells you how many people really played at the conference and how many got to the end, instead of leaving you with the feeling that the stand was busy.
What I ask of any game before it goes to an event
It mustn't break if the wifi drops. Conference venues have overloaded networks. The client reconciles with the server state even if a live message is lost.
The moderator is in control. Launching questions, relaunching them, showing the leaderboard or resetting the game happens from a panel, not by touching code.
Content can change without me. Questions, teams and pairs are edited from the admin panel.
It reads from a distance. Giant screen, large type and little text.
What really drives the cost of a project like this isn't the number of questions, but how many different formats you need, how much visual customisation you want and whether the game will be reused at more than one event. If you'll use it once, it's worth starting with one format and doing it very well.
If you're planning an activity for your next conference or stand, tell me what you want to achieve and we'll work out which format fits. You can see every game running in the project video.
