Why Restart Bugs Reveal Hidden Game State

zzzu2221 — Sun, 16 Aug 2026 07:02:49 +0000

A game can look correct until the player presses Restart. That button is one of the fastest ways to expose hidden state.

In a small browser game, I treat restart as a full lifecycle test rather than a visual reset.

What restart should clear

A restart should create a fresh run:

player position and health;
score and collected items;
enemy timers and active projectiles;
win and lose flags;
keyboard and pointer listeners;
pending animation and timeout callbacks.

Resetting only the score is not enough if an old enemy loop is still running.

A simple failure pattern

A common implementation keeps game objects in module-level variables and starts a new animation loop on every restart. The first run works. After two restarts, movement feels faster, collisions fire twice, and the result becomes inconsistent.

The bug is not in the button label. It is in ownership of the running state.

Make the lifecycle explicit

I prefer a small state machine: loading → playing → won/lost → restarting.

The transition into restarting should stop the current loop, remove listeners, cancel timers, and create a new run context. The new context then owns its entities and callbacks.

Test the failure path first

I run this sequence several times:

Start a fresh game.
Lose intentionally.
Restart.
Win or lose again.
Refresh the page and repeat.

If the second run differs from the first without a design reason, I inspect duplicated listeners, stale references, and callbacks that still point at the previous run.

The practical lesson

Restart is more than a convenience button. It is a compact test of whether the game has a coherent lifecycle. When restart is reliable, win, lose, refresh, and replay are usually easier to reason about as well.

A Game Wallet Is More Than a Number: Handling Retries and Concurrency

zzzu2221 — Sun, 16 Aug 2026 06:45:33 +0000

A game wallet often starts as a single balance field. That is fine for a prototype, but payment retries and unreliable networks quickly make the number hard to trust.

A player can tap “buy,” lose the connection, and try again. A store callback can arrive more than once. Two devices can spend the same account at nearly the same time.

The fix is to treat the balance as a cached view of a ledger.

Record every change

Instead of silently changing a balance, record events such as:

a verified payment granting virtual currency;
an item purchase spending currency;
a refund creating a compensating entry;
an administrative adjustment with an explicit reason.

The current balance remains useful for fast reads, but the ledger explains where it came from.

Make payment delivery idempotent

A payment callback is a message that may be retried. I use an idempotency key derived from the provider and transaction ID, then enforce uniqueness in the database.

The delivery flow is straightforward:

Verify the external transaction.
Record the payment.
Grant currency with the unique key.
Mark delivery complete.
Return the original result for later retries.

This prevents a temporary network problem from becoming a double grant.

Protect spending too

Client-side balance checks are useful for interface feedback, but they cannot protect an account. The server should lock the wallet row, check the available amount, write the ledger entry, and update the cached balance in one transaction.

The same request key should return the original purchase result instead of charging twice.

Keep payment, wallet, and item orders separate

A real-money payment, a virtual-currency movement, and item delivery are connected but different events:

payment order → wallet grant → item order → wallet spend

That separation makes refunds and reconciliation much easier. When something goes wrong, support can identify which step is missing instead of guessing from one mutable number.

Tests that expose the real failures

Before building a large shop UI, test repeated callbacks, crashes between payment and delivery, concurrent spends, timeout retries, failed item delivery, and refunds after currency has been spent.

The important shift is simple: a wallet is not just a number. It is a history of decisions. Making those decisions explicit and idempotent keeps payment failures explainable.

DEV Community: zzzu2221