5 Commits

Author	SHA1	Message	Date
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	d8197885ca	Hide dead characters, suggest names, make the XP bar live ... The roster sent to clients now contains living characters only. Retirement stays server-side bookkeeping for archival; from the player's side a dead character is simply gone, and listing it offers a choice that cannot be taken. The XP bar only moved on a level-up or a character swap because it read the character roster, which is re-sent only when the SET of characters changes. Experience now rides the snapshot -- four bytes on a message already going out at 20Hz -- and the server mirrors each grant into the world immediately rather than only when a level is crossed. The create field starts with a suggested name instead of blank, and offers another after each creation. Two bugs found while testing, both mine: The first was a bad patch of my own: a change meant for the snapshot decoder also matched inside decode_characters, which then read a four-byte field its encoder never wrote and ran off the end of every packet. This is precisely the "encodes but decodes wrong" failure the codec tests exist to catch, and it was caught within a minute of the test being written. Chasing that exposed a real robustness gap: StreamPeerBuffer.get_utf8_string() pushes an engine error and returns garbage when the buffer is short, so a truncated or hostile character/roster packet produced error spam instead of degrading. Both decoders now bounds-check every field, with tests that slice each packet at many lengths and assert it degrades rather than inventing entries -- the same guarantee the input decoder already had. 206 tests. check.sh, test.sh, smoke.sh and both diagnostics pass.	2026-09-04 01:12:53 +02:00
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