claude 4765bbce28
ci / verify (push) Successful in 47s
Stage 2: accounts, characters, permadeath, levels and experience
Identity is shaped like Steamworks so swapping to it is one subclass and no
schema change: the client presents an opaque ticket, the server validates it
into a stable 64-bit account id, and nothing downstream sees anything else.
LocalAuthProvider takes any ticket at face value -- insecure on purpose, and
labelled as such everywhere, because the point is the shape rather than the
security. Do not ship it.

Characters persist as JSON keyed by account. Account ids are written as decimal
strings because they are 64-bit and JSON numbers are doubles, which would
silently round them. A corrupt store aborts the server rather than starting
empty: starting empty looks like it worked and then saves over every character
on the first level-up.

Levels 1-15, +10 max health each, level DERIVED from lifetime experience rather
than stored beside it, so a hand-edited save cannot produce a level 12 character
with a level 3's experience. Experience is shared undivided across everyone
alive in the instance -- splitting it would make bringing a friend cost you
progress. A level-up heals by what it added, so gaining one mid-fight is relief
rather than a bar that moved further from full.

Death is permanent and unbinds the character entirely: no "return to the hub as
the character who just died", because the run is over. The record is retired,
never deleted. The five-character cap counts LIVING characters only -- counting
the dead would lock a player out of their own account after five deaths.

Verified by tools/diag_progression.tscn, which drives the real server through
kill -> xp -> level -> health and death -> retire -> roster. The bot smoke test
cannot cover that: bots are poor shots and rarely kill anything. Writing it
caught two real ordering bugs -- the death event was dispatched before the
payload that tells the player they died, and the dead character stayed bound to
the peer.

Also added --account and --store so several clients and test runs can coexist
on one machine. The smoke test now uses a scratch store; without it a rerun
resumed the previous run's characters and "a character was created" quietly
stopped being true.

193 tests. check.sh, test.sh, smoke.sh, diag_progression and diag_prediction
all pass.
2026-09-04 00:44:34 +02:00
2026-09-03 16:03:57 +02:00
2026-09-03 16:03:57 +02:00
2026-09-03 16:03:57 +02:00
2026-09-03 16:03:57 +02:00

Transcience

Top-down twin-stick bullet-hell with a dedicated, server-authoritative backend. Godot 4.7, GDScript, no external runtime dependencies.

Play

tools/server.sh                      # dedicated server on :27015
tools/client.sh --join --name ada    # connect a client

Or run one client and press Host and play for a listen server.

Controls — WASD move, mouse aim, LMB fire, E on the ring in the hub to enter a dungeon, hold F for three seconds to escape back to the hub.

Develop

tools/check.sh    # parse-check every script      ~5s
tools/test.sh     # GUT suite, headless           ~2s
tools/smoke.sh    # server + 2 bot clients, ENet  ~35s
godot --headless --path . --script tools/bench.gd

Read CLAUDE.md first — it is short, and the Godot CLI gotchas in it will otherwise cost an afternoon.

What is here

Twin-stick bullet hell Server-simulated bullet field, ~350 concurrent bullets at 0.24 ms/tick.
Authoritative multiplayer Clients send input only. Hits, damage, death and instance transfers are server decisions. Prediction + reconciliation for the local player.
Enemies Four readable behaviours (static, drift, orbit, approach, strafe) composed with bullet emitters.
Boss The Warden of the Fold: stationary, four phases, each adding one idea. Defined entirely as data.
Lobby hub Shared persistent instance with a portal into dungeon runs.
Emergency escape Three-second channel back to the hub, cancelled by damage.

Docs

S
Description
No description provided
Readme 2.4 MiB
Languages
GDScript 98.6%
Shell 1.1%
Python 0.3%