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.

別のリスナーが管理業務を担当します。そのリスナーはイベントを受け取り、Meta Clockを更新し、マネージャーに新しい合計値をLocalStorageに反映させるよう指示を出します。

この分離はすぐに恩恵をもたらします。セーブシステムに一切触れることなく、GameScene全体を書き換えたり、プレイヤーキャラクターを入れ替えたり、カメラアングルを変更したり、あるいはジャンルをサバイバルから弾幕系へとシフトさせることさえ可能です。各システムは独立しています。それらは直接的な関数呼び出しではなく、イベントを通じて対話します。つまり、マージコンフリクトやバグが減り、半年経ってもスパゲッティ状態にならないコードベースを維持できるということです。

ゲーム体験を変えるアップグレード

技術的な基盤が整っていても、報酬がまるでスプレッドシートの数値のように感じられるなら意味がありません。私は、アップグレードが実際のプレイフィールにどう影響するかについて、多くの時間を費やしました。

安全なアップグレードもあります。移動速度の向上、ボーナスヘルス、リロードの高速化。これらはプレイヤーにミスをカバーする余裕を与えます。これらは安心感をもたらし、ルールを変えることなくゲームの難易度を下げてくれます。

一方で、ルールを完全に書き換えるアップグレードもあります。『Neon Survivor』では、「Piercing Rounds（貫通弾）」を追加しました。このアップグレード以前は、弾丸は最初に当たった敵のところで止まっていました。アップグレード後は、敵を貫通し、一撃で列全体をなぎ倒す可能性さえあります。

その差は劇的です。スピードや体力は生存時間を延ばしてくれるかもしれませんが、Piercing Roundsはプレイヤーの立ち回りを変えます。敵を並べるように動くようになり、端で引き撃ち（kiting）をするのではなく、中央を突き進むようになります。ゲームにおける意思決定の幅が広がるのです。

優れた成長要素とは、単に数値を増やすのではなく、プレイヤーの決断を変えるものであるべきです。もし全てのアップグレードが単なるパーセンテージの上昇であれば、プレイヤーは説明文を読まなくなります。クリックして、アップグレードして、忘れるだけです。もしアップグレードが戦略の再考を促すものであれば、プレイヤーはそれを記憶します。それについて語り、ゲームを根底から覆すような他の要素がないか、再び戻ってくるのです。

真の成果

「もう一回だけ」というループは、単一のシステムではありません。それは、クリーンなアーキテクチャと意味のある報酬の上に築かれた、喪失と獲得の間の関係性なのです。

2つの明確なタイムラインを構築し、Meta Clockをプレイヤーの信頼を預かっているかのように大切に扱ってください。実際、そうなのですから。エンジンのツールを活用して、ライブデータを高速に、永続データを安全に保ちましょう。恐れずにイテレーションを繰り返せるよう、シーンをストレージから切り離してください。そしてアップグレードを設計する際は、それがプレイヤーに「より多くの時間」を与えているのか、それとも「より面白い選択肢」を与えているのかを自問してください。

これを正しく行えば、プレイヤーは単に死を受け入れるだけでなく、死を求めるようになるでしょう。すべてのプレイが次のプレイへの投資となります。ゲームは単なる再起動の繰り返しではなく、一続きの、絶え間ない挑戦へと変わるのです。