9 Commits

Author	SHA1	Message	Date
claude	7ef972e3b3	Hub character swapping, XP percentage, passive health regeneration ... Character swapping is hub-only, and refused by the SERVER rather than merely greyed out in the menu. Allowing it inside a dungeon would be an instant, uninterruptible exit from danger -- strictly better than the one-second escape channel, which would make that channel pointless. Creating a character in a dungeon is refused for the same reason. Both are covered by diag_progression. Health regenerates at 0.5% of MAXIMUM per second. A percentage rather than a flat rate so it does not become irrelevant at level 15: a capped character regains 1.2 hp/s against a level 1's 0.5, and both take about 200 seconds to heal from nothing. No out-of-combat gate -- at this rate it cannot out-heal anything actually shooting at you, and a trickle that never stops is easier to reason about than a timer players have to learn. A fractional carry is needed because a tick heals well under one hit point, so truncating each tick would heal exactly nothing; there is a test for that specifically. The XP bar now states the percentage and the level it leads to, since a bar answers "how far" vaguely and a number answers it exactly. Recorded the two Stage 3 answers: 4 inventory slots, and the boss's food item is player-instanced now so the mechanism gets exercised rather than deferred. Writing the swap guard's test caught my own mistake: the first version created its spare character through the store, which has no opinion about where you are, so it bypassed the guard it was meant to prove and left a stray character behind that broke a later assertion. 200 tests. check.sh, test.sh, smoke.sh and both diagnostics pass.	2026-09-04 00:56:29 +02:00
claude	4765bbce28	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
claude	afe76c22ce	Fix bullet atlas, animation speed, sprite flip, fire rate, silent shots ... Bullet sprites were wrong because I read the pack's layout backwards. Each of its 8 PNGs is one ANIMATION FRAME, and a column within a file is a COLOUR variant -- so walking columns cycled the palette while the shape sat still, and the rows I picked were in a region of larger multi-cell sprites, which is the scattered debris that showed on screen. tools/build_local_assets.py now composes a proper atlas: 8 frames across, one row per SimConfig.KIND_*. Animations ran at whatever the machine's framerate was, because they counted _process calls. At 240fps that is four times too fast on its own, before the requested halving. Both actor and bullet animation are now driven by elapsed seconds, so they look the same on any machine. The knight shifted sideways instead of mirroring: a Rect2 with negative width does not flip, the draw call normalises it, so the sprite kept its orientation and jumped right by its own width. Mirrored through the canvas transform about the sprite's centre instead. Shots were silent when a bullet spawned inside an enemy. The sound rode on BULLET_SPAWN, which is deliberately suppressed for a bullet resolved and removed within the same tick -- so no event, no sound, and this got more likely the closer you stood. Firing is now its own event (PLAYER_FIRED): the shot happened whether or not a bullet survived to be replicated. Protocol 3 -> 4, because inserting mid-enum shifts the wire value of every event after it. Fire cooldown 7 -> 14 ticks (4.3 shots/sec). Licence question 2, confirmed verbatim: the paid tier DOES grant commercial use ("You may use these assets in personal, commercial or non-commercial projects"), but its next sentence still forbids redistribution "no matter how much you modify it". Paying moves these from local-only-and-non-commercial to local-only-and-commercial; it never makes them committable. Only replacing them with permissively licensed art does that. Question 3: CREDITS.md now credits every pack, including the two whose licences do not require it and the unused ones in considering_dont_use_yet/. 158 tests. check.sh, test.sh and smoke.sh pass.	2026-09-04 00:03:04 +02:00
claude	7ee6c8e761	Close Stage 1: per-peer actor interest, boss room confinement ... The gap Stage 1 left open: snapshots were encoded once and broadcast to every peer in an instance, so clients were handed enemies the fog then hid. Fog is a rendering rule -- a modified client draws whatever it holds -- so that was no defence at all. Snapshots are now encoded per peer, and actors beyond ACTOR_INTEREST_RADIUS (800u) are never sent. Measured cost of four filtered encodes against one shared: 95.6us vs 24.9us, or 0.032 ms/tick amortised over the snapshot interval. Two asymmetries worth keeping: - The observer's own player record is never filtered, however far out the arithmetic puts it. The client reconciles its prediction against that record, so dropping it breaks the player's own movement rather than hiding someone. - Only bullet SPAWNS are filtered, never despawns. A client told about a bullet must always be told it died, or it keeps a phantom. Bullet spawns use a much wider radius (2200u) than actors, deliberately. An enemy appearing at the edge of sight is cosmetic; a bullet withheld at spawn that later flies into view is invisible damage. The floor is longest bullet travel + fog radius -- 1500 for the Warden's Collapse snipe -- and test_interest.gd recomputes that from live content, so adding a faster or longer-lived bullet fails a test instead of producing bullets that wink into existence. Also clamped bosses to their room. A no-op today since every boss is stationary, which is exactly when the invariant is cheap to establish: boss rooms have no door that locks, so the only thing keeping a fight in the boss room is the boss, and Stage 5's movement work would otherwise break it quietly. 146 tests (was 137). check.sh, test.sh and smoke.sh pass. Stage 1 has no partials left; docs/ROADMAP.md now records the three interest radii and the floor each must respect.	2026-09-03 23:33:32 +02:00
claude	7af439341d	Stage 1: tile maps, walls, fog of war, aggro, scrolling camera ... Replaces the fixed centred arena with per-world tile geometry, which is the foundation the remaining features sit on. - MapGrid: tile grid with three independent flags -- blocks movement, bullets, sight -- so a pit stops feet but not bullets or eyes, and a barricade stops feet and bullets but not eyes. Circle collision with per-axis sliding, and Bresenham line of sight shared by fog and aggro. - MapGen: rooms and corridors generated from (seed, depth), with hand-authored boss arenas from Rooms stamped in first so a corridor can never carve through a designed fight. Reachability from spawn to boss is asserted over 40 seeds -- "usually connected" is the failure mode that ruins one run in twenty. - Dungeons are populated at creation, per room, instead of gating on waves. You explore and choose your fights; the run ends when the boss dies, not when the map is swept. Boss rooms have no lock, so walking out is always available. - Aggro: enemies need range AND line of sight, so a dungeon stays quiet until engaged and cover actually protects. - Hard fog, scrolling camera, and terrain rendering. Maps are streamed per peer in chunks around that peer's player, and the seed is deliberately NOT sent -- a client holding it could regenerate the whole dungeon, which is a map hack for free. Stream radius (900u) is wider than view radius (460u) because the client predicts movement against walls and simulates bullets that die on them; the accepted cost is a cheater seeing a little further than the fog, never the floor plan. Partial map knowledge means wall deaths must be announced rather than derived. A test caught the subtle half of that: out-of-bounds tiles read as WALL by design, so checking geometry before bounds reported every bullet leaving the map as a wall kill. 128 tests (was 103); check.sh, test.sh and smoke.sh pass. 0.26 ms/tick with 4 players and a boss, ~65x headroom.	2026-09-03 20:49:27 +02:00
claude	e1f9fa8096	Unlock menu after failed join; remove contact damage; cover clean disconnects ... A failed connection left the connect buttons disabled forever. _show_menu() returned early when a menu already existed, so the set_busy(false) that re-enables them never ran on the way back from _abort_connect -- the player was locked out of both joining and hosting with no way out but a restart. Also guards against a second attempt stacking on an in-flight one. Contact damage is gone as a concept: nothing in this game hurts you by touching it, because every threat should be a bullet you can see and dodge. The Stalker walked at you and dealt contact damage and nothing else, so it now carries a point-blank shotgun instead -- five pellets, 62 degrees, 18-tick lifetime for about 78px of reach, so it still has to close and leaves nothing lingering. tests/unit/test_content.gd asserts every hostile enemy has an emitter, so a new enemy cannot quietly reintroduce the mechanic. The menu's "Disconnect" DOES get the anti-cheese protection -- verified, not assumed. It calls Net.shutdown(), the socket closes, and the server takes the same linkdead path as a SIGKILL, because the channel is keyed on the socket closing rather than on how it closed. Made permanent: a --leave-after bot flag and two smoke assertions covering the polite exit alongside the hard kill, so a future "clean leave" message that skipped the channel would fail a test. The menu now says so out loud in a dungeon -- the mechanic only reads as fair if the cost is known before clicking. 103 tests, 12 smoke assertions; check.sh, test.sh and smoke.sh all pass.	2026-09-03 19:37:26 +02:00
claude	f70de1b825	Fix permanent input-timing desync; no i-frames; UI respawn; guard dead joins ... The real cause of the ship/bullet separation, which the previous commit only half-addressed. The server dropped inputs past a lead of 12 while the client only re-synced past 16, so a client whose lead drifted into 13-16 had every input silently rejected while believing its timing was fine. The server coasted on held_input and then stopped; the client kept predicting. The two separated permanently and the reconciler fought it every snapshot -- "shoved around". It needed two independent clocks to drift, hence "only after some time", and nothing in the loop could notice, hence "then persists". The listen-server diagnostic could never reproduce it: one process, one physics tick, lead constant by construction. Two defences: INPUT_MAX_LEAD (40) is now far wider than the client's correction band (3..20), asserted by tests/unit/test_input_lead.gd so narrowing it fails a test; and an ack-stall detector re-syncs when last_input_tick stops advancing, which catches the whole class regardless of cause -- lead alone cannot, because a wrong lead looks normal from the client. diag_prediction.gd now injects a +14 tick drift and exits non-zero unless the gap recovers. Also: - No invulnerability frames. Every bullet that touches a player lands; i-frames made dense patterns safer than sparse ones, which inverts the genre. Measured: a stationary player survives ~13.6s of the Warden's opening phase, ~17.5s drifting. spawn_grace remains the only invulnerable state. - Death is exited with a HUD button, disabled for the first 3s. The lockout is enforced in SimWorld, not just by graying the button -- a client that ignores its own UI still waits. The interact key no longer respawns. - Joining a server that is not there no longer drops the player into an empty lobby they cannot act in. Net.join() only creates an ENet object; the game scene now waits for the server to actually place us in an instance, with an 8s timeout, and headless runs exit non-zero instead of idling. Protocol 2 -> 3. 98 tests; check.sh, test.sh and smoke.sh all pass.	2026-09-03 19:19:33 +02:00
claude	005679f1b5	Fix bullet/ship desync; rework death, escape, arrival and hub awareness ... (1) Bullets appeared to trail the ship. Two independent causes, measured with the new tools/diag_prediction.gd rather than guessed at: - ServerRuntime ticked before ClientRuntime, so input sampled on frame N was not consumed until frame N+1, leaving the drawn ship a constant one tick (4.00px at 240 u/s) ahead of the authoritative one that bullets spawn from. ClientRuntime now sets process_physics_priority = -10. Gap on a listen server: 4.00px -> 0.10px mean, 0.30px worst. - PLAYER_MUZZLE_OFFSET was PLAYER_RADIUS + 6 = 12px against a 13px drawn ship, so bullets were born inside the sprite. Regression from the previous commit's hitbox shrink; it now derives from PLAYER_VISUAL_RADIUS. (2) No more timed respawn. A downed player stays down until they ask for the hub (E), which is an ordinary input -- the server has no "revive me" message. (3) Escape channel 3s -> 1s, and damage no longer cancels it. An interruptible channel makes killing the process strictly better than using the button, so a dropped connection now runs the same channel: the player stays in the world as linkdead, still killable, and is only released once it completes. Instances refuse to close while a linkdead body is resolving, or a solo drop would delete it on the next tick and hand the exploit straight back. (4) Escape opens an in-game menu: return to hub (routed through the same held- escape channel, not a new message), disconnect, quit. (5) Server pushes a roster so the hub shows who is online and which dungeon they are in. Entering a dungeon grants 2s arrival protection -- invulnerable AND weapons-cold, since invulnerability alone would make the spawn a free firing position -- flagged in the snapshot and drawn on every protected ship. (6) Cleared dungeons hold the party 30s (was 5s) with a visible countdown. (7) The hub's grey circle was a 100k-HP target dummy that read as scenery. Now drawn as a bullseye so its purpose is legible. Protocol version 1 -> 2. 91 tests (was 78); smoke.sh gains a bot that is SIGKILLed mid-dungeon to prove the disconnect path end to end. check.sh, test.sh and smoke.sh all pass.	2026-09-03 18:43:19 +02:00
claude	c4beeae38f	Initial commit: Transcience MVP ... Top-down twin-stick bullet-hell, Godot 4.7, server-authoritative dedicated server with client-side prediction. Clients send input only; the server resolves every hit for both players and enemies (no PvP). - SimWorld: whole simulation as plain RefCounted objects (no nodes, no physics server), ~0.24ms/tick at peak load -- runs headless for free and drives 78 tests in under a second - BulletPool: struct-of-arrays bullet storage, replicated as spawn/despawn events rather than per-tick state - Emitter framework (Ring/AimedSpread/WallGap/ArcSweep) shared by trash enemies and bosses -- a new boss is data in src/content/content.gd, no simulation changes - The Warden of the Fold: stationary 4-phase boss built entirely on that format - Lobby hub with a portal into on-demand dungeon instances; one process hosts the hub plus every concurrent dungeon - Emergency escape: 3s server-owned channel, cancelled by damage - tools/check.sh, test.sh (GUT), smoke.sh (real server + bot clients over ENet), bench.gd; git hooks wired to the same scripts - docs/ARCHITECTURE.md, NETCODE.md, WORKFLOW.md, ROADMAP.md	2026-09-03 16:03:57 +02:00