Spyfall may not be a super popular game, but I find it incredibly fun. I first discovered it while watching some videos on YouTube, and I immediately fell in love with it. As a huge fan of social deduction games, Spyfall hit all the right notes for me. The premise is simple: everyone knows a specific location (chosen randomly through cards or an app)—everyone except for the spy. The goal is for players to ask each other subtle questions about the location to figure out who the spy is. The twist? The spy can win by correctly guessing the location before being discovered.

I’ve played Spyfall online using some existing websites, but I wanted to create my own version. A couple of years ago, I made a for it, ambitiously aiming to offer the game to everyone, not just my group of friends. It had features like lobby management and a full-fledged game system, but it never gained much traction—mainly because it was on Telegram. I always knew the platform choice would be an issue, but I was limited by my skills at the time.

Now, with a better grasp of , I decided to revisit this project and build a web-based version. It was the perfect opportunity to combine something I loved and a chance to test out my new skills. Plus, this time, I wanted to make some tweaks to the existing game formula.

GAME LINK

In addition to basic Spyfall functionality, I wanted to improve the user experience with a few features that I felt were lacking in other versions:

It’s frustrating for the spy to ask, “What are the possible locations?” and immediately give themselves away. I wanted the spy to always have access to this information discreetly.

Inspired by , I envisioned a voting system where players could interactively cast votes on who they think the spy is.

I started by developing the backend using . My initial task was to create the lobby system. Right now, you can ping an API endpoint, and the backend will generate a lobby for you, returning a unique string code that allows other players to join.

For real-time communication, I had to learn —a protocol I had studied but never used before. Rather than follow a tutorial, I built everything from scratch. Here’s how I approached it:

Once the backend was functional, I moved on to the frontend. The main tasks were:

Handling corner cases was particularly tricky. For instance, I had to account for situations where:

One feature I planned to implement is . Before, if two players connected with the same name, the system treated them as the same player. I want to reject duplicate names and notify the player that they need to pick a unique one.

Additionally, I’m working on improving the . Currently, the system directly creates a WebSocket connection when joining a lobby. If the connection fails, it throws an error without providing details like “lobby full” or “game already started.” My new approach will poll an endpoint first, verify lobby details, and then create the WebSocket connection based on that information.

Finally, I forgot to strip players’ roles in the lobby update message. While I removed the spy’s identity, I left the player roles visible, which allows savvy players to deduce who the spy is. My fix was to only include the role of the player receiving the message, ensuring that no one can peek into others’ roles.

With the game logic and frontend done, I spent a few hours setting up the backend server. I used as a reverse proxy for incoming requests, forwarding them to the FastAPI backend.

One feature I’m considering adding is a for different phases of the game. Rather than use a timer, I can work with the expiration variable I mentioned earlier to dynamically calculate how much time is left in a phase. This would let the backend be more responsive without relying on timers that I might forget to clear.

I hope you give this version of Spyfall a try with your friends! Let me know what you think, and feel free to check out some of my other projects.

GAME LINK