Die besten Roguelikes töten dich nicht einfach nur. Sie lassen dich sterben wollen.

Die besten Roguelikes töten dich nicht einfach nur. Sie bringen dich dazu, sterben zu wollen.

Das klingt seltsam, aber jeder, der einen Run um Mitternacht verloren und um 12:03 Uhr einen neuen gestartet hat, kennt das Gefühl. Der Tod schmerzt. Deine Gesundheit sinkt auf Null. Der Bildschirm flutet mit dem Scheitern. Und doch schwebt dein Finger bereits über dem Play-Button. Etwas an den letzten zwanzig Minuten war bedeutsam genug, dass du das Spiel nicht dort verlassen kannst, wo es aufgehört hat.

Das ist der „Noch ein Run“-Loop, und das ist kein Zufall. Er ist Design. Wenn du ein Roguelike oder ein Spiel mit Permadeath entwickelst, besteht deine gesamte Aufgabe darin, zwei gegensätzliche Kräfte auszubalancieren. Der Spieler muss genug verlieren, um Spannung zu spüren. Er muss genug behalten, um Hoffnung zu haben.

Die Währung des Scheiterns

In meinem neuesten Projekt, Neon Survivor, wollte ich genau diese Spannung erzeugen. Wenn der Spieler stirbt, verschwindet alles, was während des Runs gesammelt wurde, außer einer Sache: Gold. Dieses Gold wird automatisch eingezahlt. Zurück im Menü gibt er es für permanente Upgrades aus. Dann springt er wieder hinein, ein kleines Stück stärker als zuvor.

Dieser einfache Loop trägt das gesamte Spiel. Ohne ihn ist der Tod ein Punkt am Ende des Satzes. Der Spieler macht eine Pause, weil der letzte Run ihm nichts gebracht hat. Mit ihm ist der Tod ein Komma. Der Run wurde zu einem Farming-Trip. Der Verlust schmerzt, aber er hat auch das Morgen bezahlt.

Der Trick ist simpel. Man behält etwas, selbst wenn man alles andere verliert. Die Schwierigkeit besteht darin, sicherzustellen, dass das, was man behält, von Bedeutung ist, ohne die Herausforderung zu zerstören. Wenn die Upgrades zu schwach sind, verliert der Spieler das Interesse. Wenn sie zu stark sind, spielt sich das Spiel von selbst. In beiden Fällen bricht der Loop zusammen.

Zwei Uhren, null Verwirrung

Um dies richtig aufzubauen, musste ich zwei getrennte Zeitlinien verwalten.

Die Run-Clock setzt sich jedes Mal zurück, wenn du auf Play drückst. Sie verfolgt die Gesundheit, den aktuellen Score, die Anzahl der Gegnerwellen und alle temporären Power-ups, die während der Sitzung eingesammelt wurden. Wenn der Charakter stirbt, wird diese Uhr auf Null zurückgesetzt.

Die Meta-Clock setzt sich niemals zurück. Sie speichert das gesamte über alle Versuche verdiente Gold, die höchste jemals erreichte Welle und jedes gekaufte permanente Upgrade. Diese Uhr tickt weiter, egal wie oft der Browser aktualisiert wird.

Mischt man diese beiden, entstehen Bugs, die schwer zu verfolgen und schmerzhaft zu beheben sind. Ich habe gesehen, wie Entwickler versehentlich den Spielfortschritt während eines routinemäßigen Scene-Resets gelöscht haben, weil eine Cleanup-Funktion den falschen Datenspeicher angesprochen hat. Die Daten der Meta-Clock verdampfen. Der Spieler kehrt mit Null Gold und Null Upgrades zurück. An diesem Punkt ist die Beziehung zwischen dir und deinem Spieler zerstört. Er beginnt keinen neuen Run; er beginnt eine neue Fehde.

Die Uhren getrennt zu halten, ist nicht nur eine Stilentscheidung. Es ist eine Überlebensstrategie.

Wie Phaser v4 die Trennung handhabt

Ich habe Neon Survivor mit Phaser v4 entwickelt, das zwei spezifische Werkzeuge für dieses Problem bietet.

Die Registry hält Live-Daten im Speicher für die aktuelle Sitzung. Sie ist schnell. Sie ist einfach. Sie verdampft jedoch in dem Moment, in dem der Spieler die Seite aktualisiert.

LocalStorage speichert Daten direkt im Browser. Es übersteht das Schließen von Tabs, Browser-Neustarts und Stromausfälle. Es ist jedoch auch langsamer und weniger zuverlässig. Browser können es blockieren, drosseln oder löschen, wenn die Speicherkontingente voll sind.

Meine Designentscheidung war strikt. Die Registry ist die einzige Quelle der Wahrheit während des Gameplays. Das Spiel liest daraus, schreibt hinein und vertraut ihr vollkommen. LocalStorage fungiert nicht als Co-Autor. Es fungiert als Spiegel.

So funktioniert der Ablauf: Das Spiel schreibt einen Upgrade-Kauf in die Registry. Eine einzelne Manager-Klasse überwacht die Registry. Wenn es angemessen ist, spiegelt dieser Manager die Registry-Daten in den LocalStorage. Wenn der Browser das Schreiben blockiert, ruckelt das Spiel nicht. Wenn die Speicherung fehlschlägt, läuft die aktuelle Sitzung trotzdem perfekt. Der Spieler könnte seinen Fortschritt nur verlieren, wenn er den Tab in genau derselben Sekunde schließt, aber die Sitzung selbst stürzt nie ab.

Dieses Muster verhindert eine subtile Katastrophe. Wenn du jedes System direkt in den LocalStorage schreiben lässt, erzeugst du Abhängigkeiten von einer fragilen API. Ein Spieler mit extrem hohen Privatsphäre-Einstellungen oder einem Gerät mit wenig Speicherplatz könnte erleben, dass das Spiel während des Kampfes langsamer wird oder einfriert, weil eine Hintergrundfunktion versucht hat, Statistiken zu speichern. Indem du die Registry zur alleinigen Quelle der Wahrheit machst, hältst du die Action schnell und das Risiko begrenzt.

Lass den Code atmen

Ich habe auch Events verwendet, um die Systeme zu entkoppeln. Wenn ein Run endet, kümmert sich die GameScene nicht um ihre eigene Beerdigung. Sie ruft keine Save-Funktion auf. Sie importiert kein Storage-Utility. Sie emittiert einfach ein „run-ended“-Event mit einem Payload der relevanten Daten.

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.