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.
Un listener separato gestisce la contabilità. Riceve l'evento, aggiorna il Meta Clock e comunica al manager di rispecchiare i nuovi totali in LocalStorage.
Questa separazione si rivela immediatamente vantaggiosa. Posso riscrivere l'intera GameScene, sostituire il personaggio del giocatore, cambiare l'angolazione della telecamera o persino passare dal genere survival al bullet hell senza toccare il sistema di salvataggio. I sistemi sono indipendenti. Comunicano tramite eventi, non tramite chiamate dirette a funzioni. Ciò significa meno conflitti di merge, meno bug e una codebase che non si trasforma in un ammasso di codice spaghetti dopo sei mesi.
Upgrade che cambiano il gioco
Avere una spina dorsale tecnica è inutile se le ricompense sembrano un foglio di calcolo. Ho dedicato molto tempo a riflettere su come gli upgrade siano effettivamente piacevoli da giocare.
Alcuni upgrade sono "sicuri". Velocità di movimento extra. Salute bonus. Ricarica più veloce. Questi danno al giocatore un maggiore margine di errore. Sono rassicuranti. Rendono il gioco più facile senza cambiarne le regole.
Altri upgrade riscrivono completamente le regole. In Neon Survivor, ho aggiunto "Piercing Rounds". Prima di questo upgrade, un proiettile si fermava al primo nemico colpito. Dopo l'upgrade, attraversa i nemici, potenzialmente ripulendo intere linee con un singolo colpo.
La differenza è drastica. Velocità e salute potrebbero permetterti di sopravvivere più a lungo, ma Piercing Rounds cambia il modo in cui ti posizioni. Inizi a schierare i nemici. Smetti di fare kiting lungo i bordi e inizi a tagliare dritto verso il centro. Lo spazio decisionale del gioco si espande.
Una buona progressione dovrebbe cambiare le decisioni del giocatore, non limitarsi ad aumentare i suoi numeri. Se ogni upgrade è solo un incremento percentuale, il giocatore smette di leggere le descrizioni. Clicca, potenzia, dimentica. Se un upgrade lo costringe a ripensare la propria strategia, lo ricorderà. Ne parlerà. Tornerà per vedere cos'altro potrebbe stravolgere il gioco.
Il vero compenso
Il loop del "un'altra partita" non è un singolo sistema. È una relazione tra perdita e guadagno, costruita su un'architettura pulita e ricompense significative.
Costruisci due timeline distinte e proteggi il Meta Clock come se custodisse la fiducia dei tuoi giocatori, perché è così. Usa gli strumenti del tuo motore per mantenere i dati live veloci e i dati persistenti sicuri. Disaccoppia le tue scene dallo storage in modo da poter iterare senza paura. E quando progetti gli upgrade, chiediti se offrono al giocatore più tempo o scelte più interessanti.
Se ci riesci, i tuoi giocatori non si limiteranno a tollerare la morte. Ne dipenderanno. Ogni partita diventa un anticipo per la successiva. Il gioco smette di essere una serie di riavvii e diventa un'unica, continua scalata.