Void Protocol

5.Ejecting
4.Coding with friend
3.Playing with friends
2.Create Mission
1.Home page
6.Victory or Loss page

Inspiration

The idea for Void Protocol came from a simple observation:
games are engaging, but coding practice often isn’t.

While playing Among Us with friends, I was fascinated by how naturally it creates tension, collaboration, and deception. At the same time, platforms like competitive coding sites focus heavily on individual problem-solving, often lacking interaction and excitement.

I wondered:
What if solving coding problems felt like playing a multiplayer game with real stakes?

I also explored similar experimental projects online that tried to gamify coding, but most lacked real-time interaction or meaningful social mechanics. That motivated me to push the idea further — combining live code execution, multiplayer systems, and social deduction into a single experience.

This led to the creation of Void Protocol — a game where coding is not just a skill, but a survival tool.

What it does

Void Protocol is a real-time multiplayer social deduction game set in a futuristic space station.

Players are assigned roles: Crew or Saboteur
Crew members solve real coding challenges to stabilize the system
Saboteurs secretly disrupt progress and manipulate other players
Meetings allow players to debate, accuse, and vote

The game blends:

Competitive coding
Real-time collaboration
Psychological strategy

How we built it

We built Void Protocol using a modern real-time web stack:

Frontend: React + TypeScript + Vite
State Management: Zustand for handling complex game state
Backend (Real-time): PartyKit for WebSocket-based multiplayer synchronization
Storage: Durable state with SQLite for consistent sessions
Code Engine: A custom sandboxed runner to evaluate player-submitted code
UI/UX: Glassmorphism design with custom CSS and immersive animations

The biggest technical focus was ensuring low-latency synchronization so that all players see updates instantly.

Challenges we ran into

1. Real-time synchronization

Keeping all players in sync during fast-paced gameplay was difficult.
We had to ensure consistency across clients while handling events like voting, sabotage, and task completion.

2. Safe code execution

Running user-submitted code inside a game environment required careful handling to avoid unsafe execution and maintain performance.

3. Game balance

Designing challenges that are:

not too easy (boring)
not too hard (frustrating)

was an ongoing balancing act.

4. Blending logic with social gameplay

Ensuring that coding and deduction both feel equally important was tricky — neither should dominate the experience.

What we learned

How to design and manage real-time multiplayer systems
Handling shared state across distributed clients
Building a custom code evaluation engine
The importance of game design balance alongside technical implementation
How combining different domains (gaming + coding) creates powerful user experiences

We also realized that engagement can be modeled almost like a system:

$$ Engagement = f(\text{Challenge}, \text{Interaction}, \text{Uncertainty}) $$

Where increasing interaction and uncertainty significantly improves user retention.