19 Commits

Author	SHA1	Message	Date
claude	b8332b697d	Documentation pass for a cold start ... Audited the whole set rather than appending to it, and the two files a fresh session reads first were both wrong. README claimed the emergency escape takes three seconds and is CANCELLED BY DAMAGE. It takes one, and damage explicitly does not interrupt it -- that is a settled decision with its own entry in DECISIONS.md, and the front page said the opposite. It also described one stationary boss, one hub portal, and none of characters, permadeath, levels, inventory, loot, upgrades, settings or credits. Rewritten, with the "not ready for the internet" warning made explicit. ROADMAP had no "what is next" at all: every stage reads *done*, which for a cold start is a dead end. It opens with where things stand and a table of candidates -- auth, a reason to play past level 15, an economy, hit feedback, replacing the non-redistributable packs, DTLS -- each with what blocks it, and says plainly that the user has chosen none of them. Open questions renumbered from the orphaned 8-11 they were left at, with the solved one dropped and three real ones added. ARCHITECTURE's file map listed two files twice, missed five subsystems (upgrades, stats, poison, settings, credits, the UI theme), and still said MapGen.build() is "the entry point both sides use" -- it is server-only, and the whole anti-map-hack story depends on that. Rebuilt by layer and audited against the tree: every path listed exists, and every one of the 64 source files is covered. CLAUDE.md's security paragraph said a client can send "exactly two things" plus two roster requests. There are five client -> server messages. That number is the security model, so it is now a table naming each one and what it carries. Also records that nothing automated can see the screen. Smaller: a stale 156/156 test count in ASSETS.md, and test counts refreshed to 468 where they are quoted. check.sh clean, 468 tests, SMOKE PASS, all four diagnostics green, no broken internal links. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-07 16:20:10 +02:00
claude	61680d00d7	Style the rest of the interface: panels, sliders, scrollbars, cards ... Buttons were the easy half. This is everything else. Dialogs sit on panels now rather than being text over a dimmed world -- the pause menu, character select, upgrades, settings and credits all root through UiTheme.dialog_panel(). The panel stylebox is the pack's frame MODULATED DARK. The set is cream throughout, which is right for buttons and wrong for a dialog over a dark dungeon; tinting keeps the pixel border and the corner shape and lets every label the game already draws in light colours stay readable, instead of recolouring every label in five screens to suit the art. Sliders and scrollbars are the pack's too, section headings sit on its banner ribbon, and an upgrade card's rarity is now its frame rather than a word on it -- three choices are compared at a glance and a colour reads faster than a label. Two bugs of the same shape, and neither was findable without looking at the screen. A Slider and a ScrollBar take their THICKNESS from the stylebox's minimum size, which for a StyleBoxTexture is its content margins. Mine were zero, so both resolved the correct stylebox, reported the correct texture, and drew a groove zero pixels tall. A probe confirmed the theme was resolving perfectly while the track was invisible. Tests now assert every slider and scrollbar stylebox has a non-zero minimum, and it is gotcha 7 in CLAUDE.md. The first attempt at the slider groove also used the pack's HOLLOW bar sprite, whose middle is transparent -- tinting it dark left an outline and nothing else. It uses the solid one. tools/screenshot.tscn gained the upgrade screen, which it has to stage: the game scene owns that screen's visibility and re-asserts it every frame, so setting `visible` lasted exactly one frame, and standing the player at the NPC client-side lasted until reconciliation pulled them back. It now moves the player on both sides and holds it until the shot. That tool has caught four bugs the automated gates all passed. check.sh clean, 468 tests, SMOKE PASS, all four diagnostics green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-07 11:45:46 +02:00
claude	132646f6c3	Rework the UI on Crusenho's pack; credit it in the game, not just the repo ... Crusenho's Complete UI Essential Pack is CC BY 4.0 -- redistributable and commercial-friendly, confirmed from the License.txt the pack itself ships -- so unlike the two bdragon packs a subset is committed: twelve PNGs, 48 KB, under assets/sprites/ui/. Only what is used, because each committed PNG costs a Godot .import sidecar and a directory nothing references is one nobody prunes. UiTheme builds a Theme in code from it -- button states, panels, line edits -- and every screen roots itself through UiTheme.themed_root(). The HUD's bars are the pack's frame with a tinted fill, drawn as three horizontal slices because Godot's nine-patch lives on nodes and the HUD is drawn rather than built from controls. Inventory slots use the pack's slot art at exactly twice the source size; a non-integer scale on a 1px border reads as a wobble along every edge. The credits screen is the other half of the request and it is a licence obligation, not a nicety: two packs are now CC BY, which asks for attribution "in any reasonable manner", and a markdown file in a source repo is not reasonable for someone who downloaded a build. Settings -> Credits shows every source with its terms and a link to the licence text. test_credits.gd asserts CREDITS.md and docs/ASSETS.md name every entry, so the three cannot drift. Two things found by actually looking at the screen, which is the point: - The FIRST version of this styled nothing. A Control inherits its theme from Control ANCESTORS only, and the chain breaks at the first plain Node or CanvasLayer -- which is every screen here. get_window().theme set the property, changed nothing, and read as correct. check.sh, 458 tests and a clean smoke run all passed with the entire interface unstyled. The theme test now instantiates every screen and asks what its buttons resolve. - The settings screen showed Fire bound to the right mouse button, because the test suite was writing the player's real user://settings.cfg -- rebinding calls save() and nothing had redirected the path. Settings.path is now redirectable, the fixture points it at a scratch file, and a test asserts the default is still the player's own. tools/screenshot.tscn is what found both. It boots the client windowed and saves the menus, the HUD, settings and credits. Manual, needs a display, and the only thing in the project that can tell you the interface rendered. check.sh clean, 460 tests, SMOKE PASS, all four diagnostics green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-07 11:12:13 +02:00
claude	872922e9e2	Fix boss jitter; add a settings screen for controls and volume ... The jitter had two causes, and the larger one is embarrassing: boss_state() handed back the newest snapshot raw while players and enemies both went through the interpolator. The boss therefore stepped at the 20Hz snapshot rate instead of the frame rate. Invisible for as long as every boss stood still, and the first one that moved looked broken. It is interpolated now -- but not across an instance change, where the previous snapshot describes a different fight in a different room and lerping to it would fling the new boss across the map for a frame. The smaller cause was server-side: a CHASE boss corrects by the SIGN of its distance error, so at the standoff the sign flipped every tick and the boss vibrated a couple of pixels at 60Hz. It has a dead band now. The settings screen covers rebindable controls and volume, reachable from both the main menu and the in-game menu. Bindings are stored as physical keycodes -- following key position, the choice setup_input_map.gd already made -- and labelled back through the active layout so an AZERTY player reads the letter on the key their fingers are on. A rebind replaces every event on the action rather than the first, because an action that kept its alternates would still answer to the key you just moved away from. A key already in use is refused and the clash is named. Reset restores what the PROJECT shipped, captured once before anything overrides it -- captured later it would restore the last session's choice, which is the thing being undone. Effects play on an SFX bus created at runtime, so both sliders are real mixer settings rather than a number multiplied into every play() call. Worth recording: the test suite AND the smoke test both passed while a client logged twelve engine errors on every startup. ConfigFile.get_value(s, k, null) does not mean "no default" -- it means the key is absent and no default was given, and the engine logs an error per action. Nothing caught it because the smoke refutations matched SCRIPT ERROR and friends, and a plain ERROR: is none of those. It surfaced from running the client and reading the output. smoke.sh now asserts no plain engine errors either, excluding by name the one line Godot prints on every clean exit, and reintroducing the bug makes it fail. One mutation caught nothing and should not have: the early return in linear_to_db_clamped was dead code, since the clamp beneath it already prevents negative infinity. Removed rather than left looking tested. check.sh clean, 439 tests, SMOKE PASS (23 assertions), all four diagnostics green, and a real client boots with zero engine errors. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-07 10:56:44 +02:00
claude	4a98cf4b0e	The Cantor gets its own portal; bullets stop strobing ... A dungeon now names the boss arena it ends in, and the arena decides the boss. Three entrances in the hub: Warden's Descent, The Choir Vault, Proving Grounds. That replaces the seed coin-flip from the last commit, which was the wrong call. Which boss you are about to fight is the single thing a player decides before walking into a dungeon, and rolling it for them makes that decision unavailable. Only the Proving Grounds still leaves its arena open, because a harness you re-enter every couple of minutes wants whichever fight comes up first -- and it is the one place where "either will do" is true. test_every_boss_has_a_dungeon_that_reaches_it is the check that matters here: adding a boss and forgetting to give it a way in is now a failing test rather than a boss nobody meets. The smoke test asserts all three portals open over a real socket -- bots pick theirs by account id, so a run exercises each. Bullets no longer animate. The sheet's eight frames are a COLOUR cycle rather than a shape change, so running it had every bullet on screen strobing through a palette in unison, which with a few hundred in the air is exactly as hard to look at as it sounds. Each bullet holds one frame and turns slowly instead, offset by its own id so a ring of twenty does not rotate as one rigid wheel. The rate is slow enough that nothing completes a full turn inside its own lifetime, so it reads as drift rather than spin, and a test pins that against the longest-lived bullet in the game. The renderer slices four textures at startup now instead of thirty-two. check.sh clean, 414 tests, SMOKE PASS (22 assertions), all four diagnostics green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-07 10:36:06 +02:00
claude	42568a40ad	Fix: every zone change was handing the player a blank character ... SimWorld knows nothing about characters, so Instance.add_peer builds a fresh SimPlayer -- level 1, base stats, empty inventory. Something has to give that player back its character, and only character SELECT ever did. Every portal into a dungeon and every escape back to the hub therefore reset the player's level, experience, upgrades and bag. The record on disk stayed correct throughout, which is what made it read as a display glitch: the level shown was 1 because the level being played really was 1, and the first kill's experience grant partially repaired it, so the numbers appeared to come and go. _place now adopts, through a single _adopt_character that every transfer runs. That let _enter_world_as drop its adopt/reset/adopt dance -- three lines that existed only because reset_for_instance clobbered the health adopt had just computed -- and let the level-up path derive maximum health through recompute_max_hp instead of keeping a second copy of the formula. diag_upgrades now walks hub -> dungeon -> hub after taking an upgrade and asserts level, experience, upgrades, damage, maximum health and inventory all survive each leg. With the fix reverted it reports exactly what was described: level 1, no upgrades, base damage, empty bag. One of the new checks compared health against a formula fed the player's own level, which agrees with itself even when the level is wrong; it compares against the character record instead. Also drops "(every upgrade)" from the choice cards. That a flat bonus rides along with all of them is a design principle, not something a player needs told -- the number is enough. check.sh clean, 409 tests, SMOKE PASS, all four diagnostics green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-07 10:13:14 +02:00
claude	e0c1e0d5c6	Stage 5: bosses that move, attacks that warn, and a second boss ... Boss movement is a property of the PHASE, not of the boss -- a fight that stands still and then starts hunting you is one boss with two phases. Four modes (STATIC, ORBIT, CHASE, WAYPOINTS) handled generically in SimWorld._move_boss, so a boss that moves is still data. BossDef.stationary is gone rather than kept beside the phases: a flag claiming the boss stood still while a phase walked around would be a second source of truth and the wrong one, so moves() is derived. CHASE holds a distance instead of closing, because a boss standing on top of you is a boss whose bullets cannot be read. Waypoints are fractions of the arena so one phase works in rooms of different sizes. Every mode is speed clamped in one place -- ORBIT computes an absolute destination and would otherwise snap onto its circle on the first tick -- and movement slides against geometry so a boss cannot walk through the pillars its own arena was designed around. The room clamp moved to after movement, where it is finally load-bearing. It was a no-op while every boss stood still, which is exactly when an invariant is cheapest to establish: boss rooms deliberately do not lock, so walking out is always an escape, and that only holds if the boss cannot follow. TelegraphedStrikeEmitter marks spots and fills them a moment later. The moment between is the feature: a burst at your feet is a coin flip, the same burst with a second of notice is a question. It stays stateless like every other emitter -- they are shared resources and two bosses of the same kind must not stomp each other -- so strike positions are derived from the volley number and a test asserts the burst lands where the marker promised. Markers are drawn through fog and through walls, unlike everything else in the view, because a warning you cannot see is an unavoidable hit with extra steps. The Cantor of the Vault fights in the choir vault: static, then a four-corner circuit, then a chase, then orbiting while marking. It exists to prove the format stretched, and a test asserts it uses both new mechanisms. Which boss a run has now comes from its SEED rather than its depth. Depth is a dev flag nothing in play raises, so the arena was keyed to something no player can change and the second boss was unreachable in an actual game. Two things found while finishing: - tools/export_content.gd had a hand-maintained boss list and had already gone stale, silently not writing the Cantor. Content.ALL_ENEMIES and ALL_BOSSES now feed the export tool, the renderer and five tests that each kept their own copy. - diag_loot failed intermittently after another diagnostic. Taking over from the bot cleared its input queue but not its HELD input, so a starved server coasted on the bot's last movement vector for half a second and walked the player off the item it had been placed on. The press arrived correctly, which is why "the press reached the simulation" passed while everything it should have caused failed. check.sh clean, 409 tests, SMOKE PASS (19 assertions), all four diagnostics green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-06 16:32:12 +02:00
claude	b351bc2d55	Stage 4: upgrades, and a quartermaster to spend them at ... Every level banks one choice. Choices queue, and are spent at an NPC in the hub: walk to it, press E, take one of three weighted options. Seven upgrades, all data — split shot, glass cannon, spread, sniper, doubleshot, poison, eraser — and SimWorld gained no per-upgrade branch to run any of them. The four ambiguities in the brief were settled with the user first, since each changes what gets written: damage base x (1 + sum additive) x product multiplicative. The flat +5% every upgrade carries, spread's -10%, doubleshot's -50% and glass cannon's +100% pool; sniper multiplies on top, so two snipers is 4x and not +200%. glass half the LEVELLED maximum, multiplying if taken twice, so the price does not fade to a rounding error by level 15. poison independent stacks, not a refresh. split +/-45 degrees from the original heading. Independent poison stacks sound expensive and are not: every dose lasts the same number of ticks, so doses expire in the order they were added, the pending expiries are a plain FIFO, and PoisonTrack only ever looks at its front. O(1) per actor per tick however many are live. Stats are derived from the upgrade list and never stored, the way level is derived from experience -- a saved stat cannot disagree with the upgrades that produced it. Upgrade riders (split charges, poison, erase chance) travel on the bullet instead, because a shot in flight has to keep what it was fired with rather than gaining Poison because the shooter just took it. Two invariants this collided with, both now pinned: - bullet speed gained a ceiling. Wall collision samples once per tick, so anything over a tile per tick tunnels; two snipers asked for 2480 u/s against a 1920 threshold, and a tunnelling bullet looks like a bullet. - BULLET_INTEREST_RADIUS rose to 2900, because an upgraded player shot is now the longest-travelling bullet in the game. test_interest measured the worst case from static content, which upgrades quietly invalidated. Choosing is intent checked three ways: a choice must be owed, the index must name one of the three options the SERVER put on the table, and the player must be standing at the NPC. The offer is rolled once and persisted, so closing the screen is not a reroll and neither is a crash. tools/diag_upgrades.tscn covers level -> banked choice -> refused in a dungeon and refused across the room -> taken at the NPC -> new stats -> on disk. Bots never walk to the quartermaster, so the smoke test cannot. Known gap recorded in the roadmap: at PLAYER_BULLET_DAMAGE = 6, the +5% the first upgrade carries rounds back to 6 and visibly does nothing. It comes out right in aggregate, but the fix is a balance edit across content.gd and so is the user's call. check.sh clean, 357 tests, SMOKE PASS (18 assertions), all four diagnostics green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-06 15:34:58 +02:00
claude	a943aa19f6	Add a second dungeon: the Proving Grounds, a test harness you walk into ... Two labelled portals now stand side by side in the hub. The Proving Grounds runs the same generator, the same rooms, the same enemies and the same four-phase Warden -- enemies at a fifth health, the boss at 288 instead of 3600, and trash dropping potions 80% of the time instead of 8%. A manual pass over loot, the inventory, dropping and every boss phase takes a couple of minutes rather than a quarter of an hour. It is multipliers over the shared content rather than a parallel copy: a duplicated Content would drift the first time anything was tuned, and "identical but easier" would quietly stop being true. And it is a portal rather than a launch flag, so the two can be compared back to back without restarting the server -- which is most of the point. Which dungeon you enter is resolved from the player's server-side position, and PORTAL_USED carries the answer. There is deliberately no client message that names a dungeon: one would let any client ask for the generous loot table and bring the results back to the hub. Instance matching compares dungeon ids too, so walking into one entrance can never drop you into the other's run on timing alone. SimWorld.portals replaces portal_pos/portal_enabled, enter_instance carries the portal list and the dungeon id (the client needs the latter to scale the boss bar's ceiling the way the server scaled the boss), and Protocol.VERSION goes to 7. Also pins what happens when two players reach for one item on the same tick: exactly one gets it -- the loop is sequential and the pickup erases the entity before the next player looks. The tie-break is join order rather than distance, which is arbitrary rather than designed, so it is recorded as such. Stale doc fixed while here: MapGen.build() still claimed the client rebuilds the map from the seed, which has not been true since map streaming landed and is the opposite of the rule. check.sh clean, 288 tests, SMOKE PASS (18 assertions, both dungeon kinds opened over a real socket), all three diagnostics green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-04 21:34:41 +02:00
claude	050b8251a7	Stage 3: inventory, ground loot, and two loot visibilities ... Four always-on-screen slots, items as data, and loot tables on enemies and bosses. Health potions drop rarely from trash and always from the Warden; the Warden also drops a Warden's Ration, one per living player, which does nothing at all. The ration is not filler. Player-instanced loot is a separate code path from shared loot -- a distinct entity per owner, filtered per peer in the snapshot encoder -- and the cheapest way to keep that path honest is to have something in the game that exercises it on every boss kill. Item actions ride the input frame rather than becoming new client messages. InputFrame gained BTN_USE, BTN_DROP and a slot byte, which buys the packet-loss redundancy, the replay guard on last_input_tick, ordering against movement on the same tick, and a rate limit of one action per tick -- all of which a separate RPC would have needed bolted back on. The cost is that anything in the frame which must not repeat has to be edge-triggered, since frames are resent and a starved server coasts on the last one it holds. Instanced loot is enforced in NetCodec.encode_snapshot, beside the actor interest radius: a peer is never told another player's copy exists. Hiding it client-side would have been the same mistake as relying on fog to hide enemies. Inventories live on the character and are written to the store on every transaction, so a crash between "picked it up" and "wrote it down" cannot lose or duplicate an item. Anything dropped becomes world-shared whatever it was before, and a potion used at full health is refused rather than spent. tools/diag_loot.tscn covers drop -> snapshot -> pick up -> persist -> use -> drop plus both visibilities on the wire, for the same reason diag_progression exists: bots are poor shots and almost never produce a drop. It asserts each input frame was actually consumed, after an early version silently dropped its first press and every later check passed for the wrong reason. check.sh clean, 266 tests, SMOKE PASS, all three diagnostics green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-04 21:16:15 +02:00
claude	ded7bf96d5	Documentation pass before context compaction ... The roadmap was actively misleading: an earlier stage renumbering left Stage 2's completed work sitting under a "Stage 3 -- todo" heading, and the inventory table orphaned with no heading at all. Since that file is the primary handoff document, a fresh session would have started by re-implementing accounts and characters. Rewritten. Captured in full, from the original brief rather than from memory, the two stages not yet built: - Stage 3 (inventory and loot): 4 slots, potions rare from trash and guaranteed from bosses, world-shared loot, and the player-instanced food item -- with a note that two loot visibilities must exist from the start, because proving the instanced path works is the food item's entire purpose. - Stage 4 (upgrades): every upgrade with its exact stated effect, plus the two constraints it will collide with -- sniper's 2x bullet speed against the tunnelling threshold, and per-player bullet travel against the interest radius that test_interest.gd currently derives from static content. Ten open questions are listed as explicitly do-not-guess, seven of them blocking Stage 4. ARCHITECTURE.md still claimed "the arena is a rectangle" and "no tilemap collision", both untrue since Stage 1. Rewritten around MapGrid, with what the grid costs (axis-aligned, 32px-quantised, bullets under a tile per tick) rather than only what it buys. Added a "verification traps" section to WORKFLOW.md recording six mistakes made during this work, each of which cost a round trip of reporting something fixed that was not: verifying the artefact rather than the behaviour, dumping the wrong channel, measuring a configuration where the bug cannot exist, a test whose setup silently invalidated it, git checkout reverting real work alongside a probe, and a pattern edit matching in two files. They are specific enough to be actionable. Also documented the diagnostics in CLAUDE.md -- they were undiscoverable -- and recorded the current verification surface so "everything passes" has a stated meaning. 206 tests, 15 smoke assertions, both diagnostics pass.	2026-09-04 20:34:45 +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	de48afcbd9	Fix aiming under a scrolling camera; add status and decisions docs ... The aim bug was collateral from the camera work. "Mouse relative to the centre of the screen" WAS the cursor's world position while the world was drawn fixed at the origin, so subtracting the player position gave the right vector. Once the camera scrolled, that expression became the aim vector itself, and subtracting the player position again made the ship aim at a fixed world location -- walking around swung the crosshair with the mouse held still. Fixed by inverting the transform the view actually draws with (world = screen - world_view.position, published by the game scene each frame) rather than assuming the player is centred, so it still holds if the camera later clamps at map edges or gets shake or look-ahead. tests/unit/test_aim.gd pins it, including the regression directly: moving the player must not move the crosshair. Documentation, for other sessions picking this up cold: - docs/ROADMAP.md rewritten as the status map -- every feature in the brief against its state and the file implementing it, the known gaps called out (actor interest management is the notable one), and the ten design questions that are genuinely unspecified and should not be guessed at. - docs/DECISIONS.md, new: settled decisions with their reasoning, so a session does not re-litigate or re-ask. Several are not the obvious default -- no i-frames, no contact damage, non-interruptible escape, and never sending the map seed. - CLAUDE.md and README point at both. 137 tests; check.sh, test.sh and smoke.sh pass.	2026-09-03 20:58:03 +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	d9a59fff03	Fix lobby/HUD UI pinned at (0,0); shrink player hitbox below visual size ... The lobby connect menu and three pieces of the HUD (hit-flash overlay, boss bar centering, death-message centering, hint label) were all silently broken by the same Godot gotcha: set_anchors_preset(preset) with the default keep_offsets=false does NOT zero the offsets to the preset's margins -- it recomputes them to preserve the control's *current* rect, which for a freshly constructed Control is (0,0). Anchors end up correct; the actual rect stays pinned to the top-left corner regardless. Fixed by switching to set_anchors_and_offsets_preset() everywhere a Control is built in code, and by using offset_left/offset_top (anchor-relative) instead of .position (absolute) for the HUD hint label. Documented as gotcha #5 in CLAUDE.md. Also split PLAYER_RADIUS into two constants: PLAYER_RADIUS (6.0, the authoritative hitbox used by SimWorld) and PLAYER_VISUAL_RADIUS (13.0, view-only, used by world_view.gd). The client renders every ship a little late relative to the server -- interpolation delay, reconciliation smoothing -- so a hitbox that matched the sprite would let bullets connect against a ship the player watched dodge clear of them. A smaller hitbox means the occasional bullet visibly clips the sprite without a hit, which reads as more forgiving of latency than the reverse. Verified headlessly: a throwaway scene instantiating MainMenu/HUD under a real 1280x720 viewport, asserting the panel is centered and _canvas.size / hint position resolve correctly, before and after each fix. check.sh, test.sh (78/78) and smoke.sh all pass.	2026-09-03 16:58:42 +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