DEV Community: varun chaaras

What permadeath taught me about cooperative game design (7 games in 7 weeks – week 6)

varun chaaras — Mon, 19 Jan 2026 15:18:16 +0000

I’m currently doing a personal 7 Games in 7 Weeks challenge to get better at shipping small multiplayer games and learning from them quickly.

Week 6’s game is Dead Squad, a 3-player cooperative side-scrolling zombie survival game — and it’s the first one in the challenge where everything started interacting in messy, interesting ways.

You can play it here (free):

👉 https://join.rune.ai/game/QvqxHKXD-HQI

It’s built using Rune + Forge, which let me prototype real-time multiplayer without spending the entire week fighting infrastructure.

The core idea

Dead Squad is intentionally simple:

Three players move together through an auto-scrolling level. Zombies spawn in structured waves. Ammo is limited. When ammo runs out, you’re forced into melee. If all players die, the run ends.

There’s no traditional “win” state — the goal is to survive as long as possible and see how many enemies your squad can take down before everything collapses.

Designing cooperation without explicit rules

One of my main goals was to force cooperation through constraints, not tutorials or UI warnings.

Each player has a fixed role:

The center player is a melee-focused tank with higher health
The left and right players are hybrid gunners with strong ranged damage
Gunners automatically switch to melee when ammo runs out or enemies get too close

That single ammo constraint ended up doing a lot of design work.

Players naturally cluster around the tank.

They hesitate before spending bullets.

They panic when both gunners click empty at the same time.

No popups required.

The unexpected lesson: permadeath changes psychology

I added permadeath mostly for tension. What I didn’t expect was how dramatically it would change player behavior.

The moment one player dies:

Movement becomes tighter and more deliberate
Risk tolerance drops immediately
Players protect space instead of chasing kills
Coordination increases, even without voice chat

The mechanics don’t change — but the tone of the game does.

Difficulty sliders change numbers.

Permadeath changes how people think.

Systems that started colliding

Compared to earlier games in the challenge, Dead Squad forced me to juggle several systems at once:

Asymmetric player roles
Ammo economy and forced weapon switching
Structured wave escalation across a scrolling level
Boss encounters layered into continuous movement
Multiplayer state sync while the camera never stops

It’s still a small game, but it was the first one that felt like systems were colliding instead of politely taking turns.

Open questions

If I continue iterating on this design, these are the things I want to test next:

Are the player roles readable enough for first-time players?
Does the difficulty curve spike too hard once bosses appear?
Does permadeath feel tense and motivating — or just punishing over long sessions?

Right now it sits in an interesting middle ground where some players love the pressure and others bounce off immediately, which might be a feature or a design smell. I’m still figuring that out.

Closing thoughts

This project reinforced something I keep relearning:

Co-op games work best when systems quietly push players together instead of asking them to cooperate explicitly.

Dead Squad isn’t the biggest or flashiest game in the challenge, but it’s the one that taught me the most about how rules shape behavior — not just difficulty.

Built with Rune / Forge as part of a rapid multiplayer prototyping workflow.

Building a Social Deduction Game with a State Machine (7 Games in 7 Weeks – Week 4)

varun chaaras — Mon, 05 Jan 2026 06:13:10 +0000

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.

Building Bushido: Designing Tension with Only Two Buttons (7 Games in 7 Weeks - Week 3)

varun chaaras — Sat, 27 Dec 2025 13:21:27 +0000

Building Bushido: Designing Tension with Only Two Buttons

(7 Games in 7 Weeks – Week 3)

I’m currently running a personal challenge: building and shipping 7 small games in 7 weeks. Each game is intentionally scoped to explore one specific design or technical idea.

Week 3’s game is Bushido — a minimalist, timing-based samurai duel built around a single question:

How much tension can you create with almost no mechanics at all?

Bushido is a two-player duel with only two actions:

Attack
Block

There’s no movement, no health bars, and no combos. A successful hit scores a point unless the opponent blocks at the correct moment. First to five points wins.

Designing Around Commitment

One of the core design decisions was removing cancellation entirely.

Once a player commits to an action, they’re locked into it until the animation finishes. You can’t react halfway through. You can only predict.

That single rule turns very simple inputs into a psychological game. Every attack is a risk. Every block is a read.

Under the hood, the game is driven by a small, explicit state machine:

Idle
Attacking
Blocking

Keeping the states clear and deterministic helped avoid edge cases and made the outcome of each interaction feel fair — even when it was brutal.

Timing Over Reflexes

Attacks aren’t instant. They play out over a short window, and blocks only succeed if they overlap the attack within a narrow timing range.

Each attack is marked as a pending hit. When the animation ends, the game checks whether a valid block occurred during the correct window. If not, the attacker scores.

This structure made the outcome feel earned rather than random, especially in close matches.

Solo Play and Multiplayer

Although Bushido is designed as a multiplayer duel, it’s fully playable solo.

If only one player joins, the game spawns an AI opponent that follows the same rules — no cheating, no hidden advantages. If a second real player joins mid-session, the AI cleanly drops out and the match restarts.

What This Game Taught Me

Simple mechanics don’t mean simple design
Commitment creates tension faster than speed
Clear state machines make timing-based games feel fair
Constraint is a design tool, not a limitation

🎮 Want to Play?

Think you’ve got the timing?

You can play Bushido right now on Rune — solo against the AI or in a tense two-player duel:

👉 https://join.rune.ai/game/cBxaHQpQ-FAI

If you’re interested in building small multiplayer games like this, I’m using Forge by Rune to prototype and ship these weekly builds:

👉 https://forge.rune.ai

I’ll be continuing the 7 Games in 7 Weeks challenge and sharing breakdowns as the series goes on.

I Lost a Week to a Physics Bug in a Multiplayer Golf Game

varun chaaras — Sun, 21 Dec 2025 14:10:30 +0000

While building a small turn-based multiplayer golf prototype, I hit a bug that completely soft-locked the game.

The ball would roll, slow down… and never actually stop.

Visually, it looked stationary.

Numerically, it was still moving.

In a turn-based multiplayer game, that’s fatal - the turn can’t advance unless the ball fully stops.

What went wrong

I was applying friction every update, assuming velocity would eventually reach zero.

It didn’t.

Floating-point math meant the velocity just kept approaching zero forever. The game thought the ball was still moving, so the turn never ended.

The fix

I moved all physics logic into the authoritative game logic and added a hard “snap-to-zero” threshold.

Once the ball’s speed dropped below a small value, I forced it to stop and advanced the turn.

One line of logic fixed the entire multiplayer flow.

Takeaway

If your game logic depends on something ending, you can’t rely on “almost zero.”

You need to define what zero actually means.

I wrote a deeper postmortem about building this game in a week - including procedural generation, multiplayer decisions, and what I’d do differently next time - here:

👉 [https://medium.com/@chaarasvarun/7-games-in-7-weeks-building-backyard-golf-on-rune-week-2-0fd3737f935f]

Edit 1:
hey guys I wanted to record a youtube video for my game and here it is!
https://youtu.be/1wQWDLnT2BI
lmk what you think!

🚇 I Built a Mini Metro–Style Multiplayer Game on Rune (And Learned a Lot About Real-Time Sync)

varun chaaras — Thu, 20 Nov 2025 11:06:13 +0000

🎮 The Game Concept

The game is basically a cooperative Mini Metro: multiple players share the same transit map and have to keep it running as stations spawn across the city. Anyone can draw new train lines, extend existing ones, delete segments, or reroute an entire area if congestion hits.

It starts out peaceful.
Then new stations appear faster.
Then passengers start piling up.
Then someone accidentally deletes a key connection and everything collapses.

That mix of clarity and chaos is what makes it fun — and multiplayer turns it into a kind of friendly group puzzle where communication becomes the real mechanic.

⚙️ Why I Expected Multiplayer to Be Hard

Real-time syncing is normally the hardest part of a project like this. You’ve got:

stations spawning at random positions

multiple players editing the same network

passengers moving every second

timers that need to match on every device

reconnects that shouldn’t break everything

I assumed most of my weekend would go into networking.

Rune ended up handling almost all of it for me.

When a player dragged a line, everyone saw the update simultaneously. When a new station spawned, it appeared for every user at the same moment. Even refreshes and rejoins restored the full current state automatically.

Instead of debugging netcode, I spent my time actually designing the game.

🛠️ Building the Game Loop

The core of the game revolves around a single shared state: the list of stations, the train lines, the passenger queues, and the timers for new spawns. Every player action — adding a node, removing a segment, extending a connection — updates that state directly.

Passenger movement runs on a short timer. On each tick, passengers look for valid routes, move toward their destinations, and contribute to overcrowding if the network isn’t efficient enough.

When any station gets too full, the game ends.
Simple rule.
Guaranteed drama.

It’s fun watching players frantically coordinate, arguing about which line should get priority, or yelling when someone accidentally nukes the wrong segment.

🧩 What I Learned

Minimalist games are deceptively deep.
It took surprisingly careful tuning to make the rush of new stations feel fair but urgent.
Real-time multiplayer isn’t always painful.
Having most of the networking handled freed me up to iterate on the gameplay loop instead of server logic.
Chaos is a feature.
The best moments happen when players misunderstand each other and everything snowballs.

🎮 Try It Out

If you want to experience the multiplayer chaos yourself, you can try it here:
https://forge.rune.ai