Every Thursday at four in the afternoon, West Africa Time, the developers on my team stop working for an hour. That is the whole rule. We get on a Google Meet, cameras on, and for sixty minutes nobody is allowed to bring up a ticket, a deploy or a deadline. We talk about the company, we talk about our lives, and then we play something. It is the best hour of my week and it is not close.
Our game for a long time was Pictionary on Gartic.io. One person draws, everyone else guesses, and the drawing is always worse than the drawer believes. I loved it. Not the drawing, which I am bad at, but what it did to the room: the guessing, the jokes, the person who types the right answer two seconds after someone else, the argument about whether that was really a horse. It brought us together in a way that a stand-up never will.
The guy in the mall
There is a creator on TikTok who goes by The Ezz Show. His format is simple and it is genius. He walks up to strangers in a mall, shows them a puzzle, a rebus or a word teaser, and gives them a moment to crack it. Get it right and he hands over cash. People squint, they mutter, they get it or they do not, and either way it is a delight to watch.
I wanted to play that. Not watch it, play it, with my friends and with the people I sit in that Thursday call with. It is a better fit for a room of engineers than drawing is: everyone can solve a puzzle at the same time, nobody has to hold a pen, and the smug feeling of getting it first is exactly what our group runs on.
Looking for the platform that did not exist
My first assumption was that he already had somewhere to play. I went looking for the site where the puzzles live and found nothing of the sort. What I did find was The Ezz Show Brain Teasers, Volume 1, a puzzle book he sells online. I paid three dollars and some change and read it cover to cover.
That book turned out to be the most useful three dollars I have spent this year. Reading a hundred of them in a row teaches you the anatomy of a good teaser: a phrase everybody knows, a visual trick that hides it in plain sight, and one deliberate misdirection so the first guess is wrong. It is a format with rules, and rules are something I can build against.
I had mentioned the idea to my colleagues a while earlier, half hoping someone knew a site where we could play it. Nobody did. So at the next Thursday call I said the sentence that starts most of my projects: "This time next week, we will be playing it."
Friday to Sunday
Saying it out loud in front of eight developers is how I make sure I actually do things. I gave myself the weekend. Friday and most of Saturday went to planning, and by planning I mean writing a plan, throwing it out, and writing a smaller one, several times over. The questions that survived the iterations were small and stubborn:
Nobody installs anything. You get a link and a room code, and you are playing in under a minute.
A round takes about five to ten minutes, because that is the budget a sixty-minute call can spare.
The server decides who solved what and when. Half the room are engineers; if the client scored the game, somebody would win from the browser console by the second Thursday.
The puzzle supply must not run dry, and no puzzle reaches a player unless somebody has confirmed it can actually be solved.
Then I built. The first commit is dated Friday, 7 August, and the whole first version, from the empty repo to a working arena, landed that weekend.
What The Ezz Show is
It is a real-time multiplayer puzzle arena. You open theezzshow.games, create a room, share the code, and everyone races the same puzzle at the same time. Rebus and word puzzles across many categories, points for solving, more points for solving first, and a scoreboard that resets the trash talk every round.
Under the hood it is the same shape as everything I run, on purpose: an Nx monorepo, a NestJS API with a Socket.IO gateway that owns the game loop, and two Next.js apps, the player client and an admin studio where puzzles get reviewed and published. PostgreSQL through Prisma and Kysely, Redis for presence, Docker Swarm on my own box. It has 116 unit tests, an end-to-end suite that drives two browsers through a full round, and load tests, because a game that dies when the ninth person joins is a game you only get to demo once.
The puzzles are the interesting part. The book was the teacher and the first seed of puzzles, but not the source: I distilled its rules into a rulebook and used a language model to generate a catalogue against it. Every generated puzzle has to get past a blind solver, another model that has never seen the answer, before it even reaches the review queue, and I went through the queue myself to make sure each one was fair and answerable. By demo day the arena had a book's worth of puzzles I had personally signed off on; today it is more than two hundred and I keep generating and adding more puzzles when I get the time.
Demo day
The following Thursday, four o'clock, cameras on. I dropped the link in the chat, everyone joined the room, and for the next half hour nobody talked about the company or their lives either. We just played. It was exactly the room I had wanted: the squinting, the muttering, the person who types the answer two seconds too late.
I won most rounds. This was not a fair fight, and I would like the record to show that I admit it: I had written the rulebook, reviewed every puzzle and read the book they came from. The surprise was the rounds I lost. A handful of puzzles beat me outright, because I run so many generations that I had forgotten them, or had skimmed them in review without ever solving them cold. There is a lesson about test coverage in there somewhere, and I have decided not to look for it.
What broke
Room state lived in memory. It is what made the weekend possible, because an in-process map is the fastest thing you can write, and it is also why the API can only ever run as one replica. Scale it to two and half the players in a room would be talking to a process that has never heard of that room. A restart clears every room, which the players see as a polite "room not found" card and I see as a limit.
The fix is on the ship log and, as of this week, specified in full: presence and room state move into Redis behind a Socket.IO adapter; each room gets one owner instance that holds a short lease and runs the loop; the other instances proxy a player's moves to it; and when an owner disappears, another instance picks the room up from its last snapshot and re-arms the timers, so a deploy or a crash no longer ends a game. Until that lands, the status on my site says boarding, not shipped, because statuses on that board are true.
Where it stands
More than fifty rooms hosted, more than two hundred puzzles live, and a Thursday call that now has a game of its own. The generation pipeline waits behind an API key I have not funded yet, so the catalogue grows by hand for now, which is fine: reviewing puzzles is the fun kind of work. If you want to try it, it is at theezzshow.games. Bring people who like to be right first.
And if you are the guy in the mall: the book was worth every cent, and the room is yours whenever you want it.
Comments
No comments yet.