ALIBI THE GAME

The Story Behind ALIBI

Inspiration

The genesis of ALIBI was born from a specific psychological friction observed in traditional social deduction games like Mafia, Werewolf, or Among Us. We noticed that for many players, being assigned the role of the antagonist is not fun but rather a source of immense anxiety. The cognitive load of fabricating a complex lie while simultaneously monitoring the behavior of others often results in a stressful experience rather than a playful one. We wanted to dismantle this dynamic entirely.

We asked ourselves a fundamental question regarding the nature of guilt in gaming. What if the perpetrator was genuinely unaware of their own crime? This shift transforms the gameplay from a test of deception into a shared experience of confusion and emergent storytelling. To support this mechanic, we looked to the golden age of film noir. The aesthetic of the 1940s detective genre, with its shadows, moral ambiguity, and high stakes interrogations, provided the perfect narrative wrapper. We drew deep inspiration from the tension of films like The Maltese Falcon and the investigative mechanics of games like Return of the Obra Dinn to create an atmosphere where every player feels like a detective trapped in a room where the truth is slippery.

How We Built It

This project was architected as a full stack TypeScript application, relying heavily on the robust development environment provided by JetBrains WebStorm. The technical foundation is built upon a custom WebSocket implementation using the native ws library on the server and the browser's WebSocket API on the client. We chose not to use heavy frameworks like Socket.io to ensure we had granular control over the data packet size and latency, which is critical for the timing of the interrogation phase.

WebStorm was the command center for our entire workflow. We utilized its deep TypeScript integration to share type definitions between the client and server repositories. This meant that if we updated the structure of a Crime object or an Evidence interface on the server, WebStorm immediately flagged any inconsistencies in the client side UI code before we even ran the build. The integrated terminal allowed us to manage our Vite development server and Node.js backend processes in parallel tabs, streamlining the feedback loop. For the visual design, we used raw CSS variables to define our Noir palette, allowing us to tweak the exact hex values of our Inkwell and Brass tones and see the changes propagate instantly across the application via Vite's hot module replacement.

Challenges We Faced

The most significant design challenge was balancing the information asymmetry. We had to programmatically generate scenarios where the innocent players received alibis that were distinct enough to clear them, while the guilty player received a prompt that was vague enough to fit the situation but specific enough to sound suspicious under pressure. This required multiple iterations of creative writing and logic testing to ensure the game did not break if a player asked a specific question.

On the technical front, maintaining state synchronization across multiple clients was our primary hurdle. Because ALIBI relies on strict timed phases, from the two minute Alibi construction to the seven minute Interrogation, we had to implement a server authoritative clock. Handling race conditions where two players might accuse each other simultaneously required a robust locking mechanism in our state manager. We also had to account for network instability. Reconnecting a player to a live game without exposing the hidden state or resetting the timer required complex reconciliation logic that we debugged extensively using the breakpoints and variable watchers within the WebStorm debugger.

What We Learned

Developing ALIBI was a masterclass in Event Driven Architecture. We learned that in a real time multiplayer environment, the UI is merely a reflection of the server state. Every button click, every text input, and every timer tick had to be modeled as a discrete event that could be broadcast, validated, and rendered. This shifted our mindset from building static web pages to building a living, breathing application.

Furthermore, we gained a deep appreciation for the power of strictly typed languages in large scale projects. TypeScript saved us from countless runtime errors, and the tooling provided by WebStorm allowed us to refactor core game logic with confidence. We also learned that the most effective game design often comes from subtraction. By removing the guilty player's knowledge, we created a void that the players eagerly filled with interaction, accusation, and laughter, proving that the best graphics card is often the player's imagination.

Technical Implementation

System Architecture

The ALIBI platform operates on a client server architecture designed to prioritize low latency state synchronization. The backend is built on a Node.js runtime environment, utilizing the native ws library for WebSocket management rather than heavier abstractions like Socket.io. This decision allowed for manual optimization of the data frame overhead and provided granular control over the connection lifecycle. The frontend acts as a thin client, meaning it contains minimal game logic. Its primary responsibility is rendering the state provided by the server and capturing user intent to be serialized and transmitted back to the backend.

Real Time Communication Protocol

Communication between the client and server is handled through a strictly typed event system. We implemented a custom protocol where every message is a serialized JSON object adhering to a strict GameEvent interface. This interface requires a type property (such as PLAYER_JOIN, SUBMIT_ALIBI, or ACCUSE) and a generic payload. By sharing these TypeScript interfaces between the client and server repositories, we established a contract that prevents malformed data from ever reaching the game logic. If the server changes the structure of the GameState object, the client build process will fail immediately, catching integration bugs at compile time rather than runtime.

Server Authoritative State Machine

The core of the game engine is a deterministic finite state machine (FSM) residing on the server. The game loops through distinct states: LOBBY, SETUP, ALIBI_CONSTRUCTION, INTERROGATION, and RESOLUTION. Transitions between these states are time based or event based. The server maintains a "Single Source of Truth" for the game state, including the secret identity of the guilty player, the distributed clues, and the remaining time. The client never calculates the remaining time locally; instead, it subscribes to TICK events broadcast by the server, ensuring that all players see the exact same countdown regardless of their individual device performance or network lag.

Algorithmic Evidence Generation

To facilitate the unique "unaware guilty player" mechanic, we developed a procedural content generation algorithm for evidence distribution. When a round begins, the system selects a crime scenario and instantiates a Crime object. The algorithm then iterates through the connected players. It assigns the Guilty role to one random socket ID but withholds the specific CrimeLocation data from their client state. For the innocent players, the algorithm filters the available evidence pool to ensure no two players receive contradictory alibis that would make the game impossible to solve. This logic creates a solvable logic puzzle that is generated uniquely for every session.

Built With

• convex
• css
• db
• html
• javascript
• typescipt