I’m currently running a personal challenge: shipping 7 small multiplayer games in 7 weeks.

Each week, I force myself to explore a completely different design problem. After a physics-heavy multiplayer golf game last week, I deliberately pivoted in the opposite direction.

This week’s experiment: a social deduction game where almost nothing moves, but the tension comes from psychology, synchronization, and constraint.

The result is Odd One Out.

The Core Idea

Odd One Out is a fast-paced social deduction game for 3–6 players.

Each round:

• All players receive a secret word
• Most players get the same word (e.g. Coffee)
• One player gets a slightly different word (e.g. Tea)

Players take turns giving one-word clues to prove they belong, without revealing too much. After all clues are revealed, everyone votes on who they think the Odd One Out is.

If the Odd One Out blends in, they score. If they’re caught, everyone else wins.

Simple rules — surprisingly tense outcomes.

Why This Game Is State-Driven

Unlike my previous game (which revolved around physics and continuous simulation), Odd One Out is driven almost entirely by a state machine.

In social deduction games, synchronization is everything. You can’t have:

• One player voting while another is still typing a clue
• One client revealing results early
• Late actions sneaking into the wrong phase

To avoid this, the game moves through explicit phases:

• Role Reveal
• Giving Clues
• Voting
• Round Results
• Game Over

Every action checks the current phase before executing. If the phase doesn’t match, the action is rejected.

This made the multiplayer logic dramatically easier to reason about and eliminated an entire class of desync bugs.

When Randomness Feels Broken

One unexpected issue was content repetition.

Originally, word pairs were selected using simple randomness. Statistically valid — but players would occasionally see the same pair twice in a short session.

Even though that’s “correct,” it felt like a bug.

The fix was simple: track which word pairs have already been used, and only reshuffle once everything has appeared. Essentially, bag randomization instead of pure randomness.

That small change made sessions feel far more intentional and fair.

What I Learned This Week

A few takeaways from building this:

• Explicit state machines are safer than scattered boolean flags
• Randomness often needs curation to feel good to players
• Text input introduces very different UX and validation challenges than movement or physics
• Tension doesn’t come from complexity — it comes from constraints and consequences

Odd One Out has almost no mechanical depth, yet players still hesitate, bluff, overthink, and second-guess each other. That was the most interesting part to watch.

Play the Game

Odd One Out is playable right now on Rune with friends:

👉 https://join.rune.ai/game/v8uzM6DU-HwI

All the games in this challenge are built using Rune / Forge, and the focus is on rapid multiplayer prototyping rather than polish.

If you’re building multiplayer games yourself, I’d love to hear how you approach synchronization, state flow, or randomness in similar designs.