Loading...
Loading...

What I learned from building, hosting, and running a live technical game for 100 participants at my college symposium — the technical challenges, the near-disasters, and the energy of 50 teams competing in real-time.
My college IT department needed something fresh for the annual symposium. Not a paper presentation, not a coding contest — something interactive. I proposed a game that combined technical quizzing with a visual puzzle: answer questions to reveal pieces of tech logos hidden behind a card grid.
50 teams of 2. 90 minutes. One game master (me).
The platform had three components:
During the dry run 2 days before the event, the concurrent session handling broke. With 10 test teams, everything worked fine. But when I simulated 50 concurrent connections, the server started dropping sessions. The issue was naive session storage — I was reading and writing to a JSON file per request.
I rewrote the session layer to use in-memory maps with periodic persistence to MongoDB. It was a 2-hour emergency refactor that saved the event.
100 people showed up. The hall was full. I hosted from the stage while monitoring the backend on a laptop. The first 10 minutes were tense — would the server hold? It did. For the full 90 minutes, not a single crash, not a single lag spike.
The game mechanics worked exactly as designed, but what surprised me was the social dynamic. Teams were shouting answers, celebrating logo finds, and trash-talking other teams. The 3x3 grid format created natural pacing — every correct answer had a visual payoff (card flip) that kept engagement high.
Was this post helpful?
Comments
0Be the first to share your thoughts.