The best roguelikes do not just kill you. They make you want to die.

The best roguelikes do not just kill you. They make you want to die.

That sounds strange, but anyone who has lost a run at midnight and started another at 12:03 knows the feeling. Death stings. Your health drops to zero. The screen floods with failure. Yet your finger is already hovering over the play button. Something about the last twenty minutes mattered enough that you cannot leave the game where it ended.

This is the "one more run" loop, and it is not accidental. It is designed. If you are building a roguelike or any game with permadeath, your entire job is to balance two opposing forces. The player must lose enough to feel tension. They must keep enough to feel hope.

The Currency of Failure

In my latest project, Neon Survivor, I wanted that exact tension. When the player dies, everything gathered during the run disappears except for one thing: gold. That gold gets banked automatically. Back at the menu, they spend it on permanent upgrades. Then they jump in again, slightly stronger than before.

This simple loop carries the whole game. Without it, death is a full stop. The player walks away because the last run got them nothing. With it, death is a comma. The run became a farming trip. The loss hurts, but it also paid for tomorrow.

The trick is simple. You keep something even when you lose everything else. The difficulty is making sure the thing you keep matters without destroying the challenge. If the upgrades are too weak, the player stops caring. If they are too strong, the game plays itself. The loop collapses either way.

Two Clocks, Zero Confusion

To build this properly, I had to manage two separate timelines.

The Run Clock resets every time you hit play. It tracks health, current score, enemy wave count, and any temporary power-ups picked up during the session. When the character dies, this clock winds back to zero.

The Meta Clock never resets. It holds total gold earned across every attempt, the highest wave ever reached, and every permanent upgrade purchased. This clock keeps ticking no matter how many times the browser refreshes.

Mix these two together and you get bugs that are hard to track and painful to fix. I have seen developers accidentally wipe player progress during a routine scene reset because a cleanup function touched the wrong data store. The Meta Clock data evaporates. The player returns to zero gold and zero upgrades. At that point, the relationship between you and your player is broken. They are not starting a new run; they are starting a new grudge.

Keeping the clocks separate is not just a style choice. It is a survival strategy.

How Phaser v4 Handles the Split

I built Neon Survivor in Phaser v4, which offers two specific tools for this problem.

The Registry holds live data in memory for the current session. It is fast. It is simple. It also evaporates the moment the player refreshes the page.

LocalStorage saves data to the browser itself. It survives tab closures, browser restarts, and power outages. It is also slower and less reliable. Browsers can block it, throttle it, or wipe it if storage quotas fill up.

My design choice was strict. The Registry is the only source of truth during gameplay. The game reads from it, writes to it, and trusts it completely. LocalStorage does not act as a co-author. It acts as a mirror.

Here is how the flow works. The game writes an upgrade purchase to the Registry. A single manager class watches the Registry. When appropriate, that manager mirrors the Registry data to LocalStorage. If the browser blocks the write, the game does not stutter. If storage fails, the current session still runs perfectly. The player might lose progress only if they close the tab in the exact same second, but the session itself never crashes.

This pattern prevents a subtle disaster. If you let every system write directly to LocalStorage, you create dependencies on a fragile API. A player with privacy settings cranked up or a device low on storage could see the game slow down or freeze during combat because some background function tried to save stats. By making the Registry the sole source of truth, you keep the action fast and the risk contained.

Let the Code Breathe

I also used events to decouple the systems. When a run ends, the GameScene does not handle its own funeral. It does not call a save function. It does not import a storage utility. It simply emits a "run-ended" event with a payload of the relevant data.

A separate listener handles the bookkeeping. It receives the event, updates the Meta Clock, and tells the manager to mirror the new totals to LocalStorage.

This separation pays off immediately. I can rewrite the entire GameScene, swap out the player character, change the camera angle, or even shift the genre from survival to bullet hell without touching the save system. The systems are independent. They talk through events, not direct function calls. That means fewer merge conflicts, fewer bugs, and a codebase that does not turn into spaghetti after six months.

Upgrades That Change the Game

Having a technical backbone is useless if the rewards feel like a spreadsheet. I spent a lot of time on how upgrades actually feel to play.

Some upgrades are safe. Extra movement speed. Bonus health. Faster reload. These give the player more room for error. They are comforting. They shrink the game without changing its rules.

Other upgrades rewrite the rules entirely. In Neon Survivor, I added "Piercing Rounds." Before this upgrade, a bullet stopped on the first enemy it hit. After the upgrade, it punches through enemies, potentially clearing entire lines in a single shot.

The difference is dramatic. Speed and health might let you survive longer, but Piercing Rounds changes how you position yourself. You start lining up enemies. You stop kiting around the edges and start cutting through the center. The decision space of the game expands.

Good progression should change a player's decisions, not just increase their numbers. If every upgrade is a percentage bump, the player stops reading the descriptions. They click, they upgrade, they forget. If an upgrade makes them rethink their strategy, they remember it. They talk about it. They come back to see what else might flip the game on its head.

The Real Payoff

The "one more run" loop is not a single system. It is a relationship between loss and gain, built on clean architecture and meaningful rewards.

Build two distinct timelines and protect the Meta Clock like it holds your players' trust, because it does. Use your engine's tools to keep live data fast and persistent data safe. Decouple your scenes from your storage so you can iterate without fear. And when you design upgrades, ask whether they give the player more time, or more interesting choices.

Get this right, and your players will not just tolerate death. They will depend on it. Every run becomes a down payment on the next one. The game stops being a series of restarts and becomes a single, continuous climb.