# OpenDawnstar — status & roadmap ## Done (Stage 1) — boot to character creation - Reverse-engineered the jar's custom archive format (`name` + 4-byte offset + 2-byte length, repeated). Used for both `imgfiles.lmp` and `datfiles.lmp`. - Extracted all 43 sprites as real PNGs -> `assets/img/`. - Working browser UI (plain HTML/CSS/JS, no build step): boot -> first-time welcome -> main menu -> class select -> class info -> name entry (3-letter validation) -> character created. Persisted via `src/save.js` (`localStorage`, stand-in for the original's `RecordStore`). ## Done (Stage 2) — full data layer Every one of the game's 9 data files is now traced against the decompiled Java `DataInputStream` reads and parsed byte-exact (verified zero leftover bytes on every file) into clean JSON in `assets/data/`: | Source file | -> JSON | Contents | |---|---|---| | `charin.dat` | `charin.json` | 7 classes, 6 races, 14 skills, per-class stats | | `itemsin.dat` | `itemsin.json` | 101 items, 15 categories | | `droppeditemsin.dat` | `droppeditemsin.json` | 43x5 loot-tier table | | `spellsin.dat` | `spellsin.json` | 25 spells | | `monstersin.dat` | `monstersin.json` | 42 monsters, 17 stat bytes each | | `monsterfilenamesin.dat` | `monsterfilenamesin.json` | 5x7 monster sprite refs | | `geomin.dat` | `geomin.json` | 37x6 dungeon-generation seed table | | `helptext.dat` | `help_sections.json` | 12 assembled help sections (titles + bodies, matches the original's exact string-concatenation logic) | | `npcstrings.dat` | `npcstrings.json` | 10 groups of NPC/shop dialogue | Also ported `java.util.Random`'s exact LCG algorithm to `src/javaRandom.js` (`JavaRandom`), verified against known reference output (`new Random(42).nextInt() === -1170105035`). Dungeon generation seeds with `dungeonIndex * 8000`, so this is required for the procedural dungeons to come out the same as the original. Help screen is now fully wired and real (`showHelpStub`/`showHelpSection` in `main.js`) — 12 real sections pulled straight from the game's own text. ## Done (Stage 3) — walkable dungeon, with an honest caveat - `src/dungeonGen.js`: procedural room + corridor generator, seeded deterministically per dungeon (`dungeonIndex * 8000`, same seed formula the original uses) via `JavaRandom`. Verified deterministic (same seed -> identical grid) and produces a connected, walkable layout. - `src/dungeonView.js`: top-down Canvas renderer + keyboard movement (arrows/WASD) with wall collision, entrance/exit tiles. - Wired into the flow: "Character Created" -> **Enter Dawnstar** now drops you into a real, walkable, generated dungeon. "Continue Game" does too. **Caveat, deliberately not glossed over:** the original's actual generation algorithm (in decompiled class `c`) is a first-person corridor-view renderer with monster/chest placement tightly coupled to classes `d` (monsters), `a` (items), and `k` (some shared coordinate state) — porting it byte-exact means porting all of those together, and there's no running original here to verify the port against. Rather than ship an unverifiable "looks right" port of tangled legacy logic, this stage is an original-inspired generator (rooms + corridors, same seeding approach) with a clean top-down view instead of the original's first-person corridor rendering. Monster/item/chest placement isn't in the dungeon at all yet. If pixel-faithful first-person rendering matters, that's a distinct, larger fidelity pass — flag it and we can scope that separately. ## Done (Stage 4) — monsters, chests, combat, loot - `dungeonGen.js` now populates non-entrance/exit rooms with monsters and chests, sourced from the real `monstersin.json`/`itemsin.json` data (weaker monster pool in early dungeons, widening with `dungeonIndex`). - `src/combat.js`: turn-based attack/defend resolution. Player stats derive from the selected class's row in `charin.json` (`row[3]` as max HP, attack scaled off that) — again original-inspired, not the real formula (see caveat below). - `dungeonView.js`: monster tiles (red) and chest tiles (gold) block movement and trigger encounters instead of letting you walk through. - `main.js`: full combat screen (Attack/Flee, HP bars, defeat/victory, game-over-and-respawn), chest screen (grants a real item name + gold from `itemsin.json`, persisted via `save.js`'s new `addItemToInventory`/ `addGold`). - Verified end-to-end in Node before shipping: dungeon generation + monster/chest placement consistency, and a full simulated combat loop using real parsed data (see commands in this stage's chat log if useful as a regression check later). **Caveat, same spirit as Stage 3:** monster HP/attack and player HP/attack are reasonable derivations from the real data, not the original's actual combat formula — that formula lives in tangled `ESGame`/class-`d` code using the 17 opaque per-monster stat bytes and the 41-column per-class stat row, neither of which has confirmed field semantics (see "Not done yet" below). Treat current numbers as placeholder balance, not canon. ## Done (Stage 5) — real stats, sourced from UESP Checked https://en.uesp.net/wiki/Dawnstar:Dawnstar and its sub-pages against what we'd reverse-engineered. Big result: **Character Creation** has the actual starting-stat table for all 7 classes, which resolved the "unverified combat numbers" caveat from Stage 4 for the player side. - Cross-referenced all 7 classes' 13-field `charin.json` rows against the wiki table programmatically. Confirmed: position 9 (of 13) is a constant 40 across every class, matching LUC being 40 for all classes on the wiki — that's Luck. The last 3 fields (10,11,12) don't match any attribute in the wiki table at all (values are single/double-digit, table values are 30–170) — they're something else not yet identified, not attributes. The remaining 7 stored fields don't cleanly cover the other 9 wiki attributes 1:1, meaning some (as displayed on the wiki) are likely computed/derived rather than stored raw. Not fully solved — see below. - Rather than keep guessing, `src/wikiData.js` now hardcodes the actual documented Health/Magicka/Fatigue/STR/INT/WIL/AGI/SPD/END/PER/LUC, race, starting armor/weapon, and starting spells for all 7 classes, sourced directly from the wiki table. `initLivePlayer` and the class-select/ class-info screens now use this instead of the earlier `row[3]`-based guess. Player attack now derives from STR specifically, per Dawnstar:Dictionary confirming STR "affects the amount of damage your character can inflict." - Confirmed each class has one fixed race in actual gameplay (Barbarian is always Nord, Knight always Redguard, etc.) — despite `charin.dat` containing 6 race name strings, there's no independent race-picker in the real game. Dropped "race selection screen" from the roadmap below; it was based on a wrong assumption about how the original works. - From Dawnstar:Getting Started / the archived official "How to Play" page: confirmed real controls (1=attack, 3=cast spell, movement keys also work as flee), a hard 24-item inventory cap with 6 equip slots, and that dying sends you back to camp having lost non-equipped/non-gift loot (not a hard game over) — useful ground truth for later stages. - Monster-side stats are still the Stage 4 approximation — the Bestiary page (https://en.uesp.net/wiki/Dawnstar:Bestiary) documents creature names/locations/status-ailments but not raw HP/attack numbers in what's accessible here, so `monstersin.json`'s 17-byte rows remain unmapped. ## Done (Stage 6) — found and mined an existing reference port The person pointed me at https://github.com/jet082/TES-Mobile-Decomp-Python-Port — an existing, independent (AI-assisted, by their own admission, imperfect but substantial) Python decompilation of this exact game. This resolved essentially everything Stage 5 left open: - **Full field mapping for `charin.json`'s 13-value base row, confirmed exact for all 7 classes:** `[Level, RaceIndex, STR, INT, WIL, AGI, SPD, END, PER, LUC, innerLuck, height, weight]`. Row index 1 is a race index into the 6-entry race-name array (`charin.json.descB`) — confirmed exact for all 7 classes (e.g. Barbarian -> index 1 -> "Nord", matching UESP). Indices 10–12 (the "mystery trio" flagged in Stage 4) are an internal luck-like value used only in the Magicka formula (distinct from the LUC attribute at index 9!), height, and weight — not attributes at all. - **Exact, confirmed formula** for the three HUD stats (`j.f()` / `recompute_caps()` in the reference): `healthMax = (STR+END)/2`, `magickaMax = innerLuck * INT / 4`, `fatigueMax = STR+WIL+AGI+END`. Verified programmatically against all 7 classes' real `charin.json` rows — **exact match** for every class, every stat. `wikiData.js`'s `computeCoreStats(row)` now computes these straight from `charin.json`, no hardcoded numbers needed for Health/Magicka/Fatigue anymore (the earlier Stage 5 wiki-hardcoded version had a bug — it used the wrong "luck", the visible LUC attribute instead of the internal one; caught and fixed by cross-checking against this reference). - **Confirmed our dungeon-seeding approach was right in spirit**: the reference's `dungenc.py` seeds with `dungeon_id * 8000` via a `JavaRandom`-equivalent — same formula we'd already independently derived and used in `dungeonGen.js`. - **Found the real monster combat formula** (`attempt_attack` in `monsters.py`): hit chance vs. dodge chance, both dependent on the player's equipped armor slot, block value from all equipped gear, and status-ailment infliction on a strong hit. This is not yet ported — it depends on the full equipment/armor-slot system, which isn't built yet (see below). Left `combat.js` as the Stage 4 approximation for now rather than half-port an equipment-dependent formula with no equipment system to back it. - **Found the real dungeon generator** (`dungenc.py`'s `_generate`, ~200 more lines) including a hand-crafted camp/hub layout (dungeon 1, 19x19, not procedurally generated at all), a `CHEST_TIERS` table controlling loot quality by dungeon depth, and monster-level-range tables. Not yet ported — noted as the highest-value next target since our current generator is still the Stage 3 original-inspired one. ## Done (Stage 7) — real first-person rendering Ported the actual wall-perspective system from `canvas.py` (which itself is a faithful port of `e.java`'s rendering) into `src/firstPersonView.js`: - `WALL_TABLE` and `STRIP_X` copied verbatim from the reference — these are precomputed perspective lookup tables (which screen column shows which depth-sliced wall texture) that would have taken a long, unverifiable guessing pass to reconstruct blind from the raw bytecode, exactly the risk flagged back in Stage 3. Having them confirmed against a working reference made this tractable. - Implemented the heading-relative tile lookup (`seeTile`) ourselves (simplified from the reference's cached 9x5 vision-grid approach to a direct per-query transform — same math, less machinery) using our own dungeon grid format. - Verified the geometry with a synthetic straight-corridor test before touching the visual code: side walls correctly detected at increasing depth further from center, matching the expected receding-corridor perspective. - Renders with the real extracted sprites: `wallsr.png`/`wallsi.png` (ice dungeons use the `i` set, matching the reference's dungeon-1-is-camp special case), `floor3.png`/`floorIce.png`, `panel.png` for the HUD strip, `gate.png` support wired (unused — our generator doesn't place doors yet), `chestnearclosed.png` for chests directly ahead. - Movement changed to proper first-person controls: turn left/right, step forward/back, matching the original's facing-based movement instead of the top-down version's free 4-directional walk. - Kept the Stage 3 top-down map as a fallback — both views are mounted through the same `mountDungeon()` dispatcher in `main.js`, with a "Map View" / "First-Person View" toggle button that syncs player position between the two coordinate trackers. **Not ported:** the layered monster/NPC sprite compositing (`AD_TABLE`/ `A_TABLE`/`G_TABLE` in the reference — depth-scaled body/head/accessory sprites per monster type). A monster directly ahead currently shows as a flat red tint rather than an actual depth-scaled sprite. This is the next natural step for anyone continuing the graphics work. ## Done (Stage 8) — real layered monster sprites Ported `canvas.py`'s `_draw_layered` (itself a port of `e.c(Graphics, int, int)`) — the actual monster-compositing system, not the flat tint from Stage 7: - `AD_TABLE`, `A_TABLE`, `G_TABLE`, `MONSTER_O_FILES`, and the `bLookup` type-group ranges copied verbatim from the reference into `firstPersonView.js`. These map a monster type (1–42) to: which of the 26 body/head/accessory sprite sheets to use, the frame to select within each (multi-frame sheets are laid out horizontally, sliced by `blitFrame`), and anchor offsets to composite them at. - Boss types (41/42) get their own special case (`wardenbody.png`, frame 0 or 1) matching the reference's separate boss branch. - Verified programmatically before shipping: every body/head/accessory sprite-sheet index the tables can produce, for all 42 monster types, stays within the real 26-file `MONSTER_O_FILES` array — no out-of-bounds lookups possible. - `dungeonGen.js` now stores a 1-based `typeIdx` on every placed monster (matching the original's monster-type numbering, confirmed consistent with our own `monsterfilenamesin.json`'s 5 sprite groups lining up with `MONSTER_O_FILES`' 5 groups) so the renderer can look up the right tables. A monster directly ahead now renders as an actual composited sprite (body + head + gear, per its type) instead of a red tint. **Still not ported from `_draw_entities_ahead`:** the mid/far depth slots (monsters visible 2–3 tiles out, not just directly ahead) and NPC rendering — only the depth-1 "directly ahead" case is wired up, which is the only case our bump-to-fight encounter model actually needs. ## Done (Stage 9) — the real dungeon generator Ported `dungenc.py`'s `DungeonBuilder` (itself `c.java`) into `src/dungeonGenReal.js`, replacing the Stage 3 original-inspired room placer entirely: - **Room placement**: exact `_random_room`/`_try_place` port, including the real 1-tile-border adjacency check (a new room is rejected if its padded bounding box touches any already-carved tile) and Java's particular remainder semantics (`javaAbsMod`, added to `javaRandom.js`). - **Corridor connection**: exact nearest-neighbor MST-style port (`_connect_points`/`_connect`) — each room's random interior point connects to its nearest not-yet-connected neighbor with an L-shaped corridor, direction chosen by a coin flip, same as the original. - **The hand-crafted camp/hub layout** (`generateCamp()`) — the original's dungeon 1 isn't procedural at all, it's a fixed 19x19 map. Ported with the exact tile coordinates from the reference. Not wired into the game flow yet (no hub/dungeon-select screen exists), but ready. - Tested before shipping, not just eyeballed: flood-fill connectivity check across dungeons 1/2/5/10/20/36 confirms every room and the exit tile are actually reachable from the entrance (not just "no wall at spawn"); a 36-dungeon sweep confirms monster/chest/entrance placement never collides or leaves an inconsistent grid cell. - Monster count is notably higher now — the real algorithm spawns one monster per room (up to 15 per dungeon) rather than the ~50% chance Stage 4's approximation used. **Still adapted, not ported:** monster *type* selection (our own `monstersin.json` pool + difficulty scaling, not the reference's `monsters.random_archetype_for_level`) and chest *item* selection (our own `itemsin.json` roll, not `items.roll_dropped_item`/`random_gift_for_giver`). NPC champion rooms and the cross-dungeon edge-door connections (which use `geomin.json`'s adjacency data to link dungeon N to dungeon N+1 into a real overworld) are skipped — there's no multi-dungeon map/NPC system for them to plug into yet. `dungeonGen.js` (the Stage 3 version) is left in the repo unused, in case it's useful as a fallback reference. ## Done (Stage 10) — real equipment, real combat inputs Ported the equip-slot system from `items.py`/`character.py`, and rebuilt combat on top of real numbers instead of the Stage 4 placeholder: - `src/items.js`: mirrors `items.py`'s slot logic. Cross-checking against the reference confirmed our own `itemsin.json` field names already exactly matched its Java field letters (`effect` = `ITEM_TYPECAT`, etc.) — nice validation of the original binary-parsing work back in Stage 2. Empirically confirmed the slot mapping by cross-tabulating every item category against its `effect` value: 0=weapon, 1=armor, 2=boots, 3=gloves, 4=helmet, 5=shield, -1=not equippable (consumables/gifts). - `save.js`'s inventory is now structured (`{index, name}` per item) with a real 7-slot `equipped` array, not just a flat list of name strings. - Chests now auto-equip equippable finds (replacing whatever was in that slot), matching the original's actual pickup behavior — confirmed in `character.py`: every equippable pickup auto-equips and replaces, it doesn't just add to a passive inventory. - New Inventory screen (from Continue Game) shows real equipped gear per slot and everything carried. - Fixed a consistency gap: character creation's flavor text always said "armed with a Hatchet" etc., but no actual item existed until now — the starting weapon/armor names are looked up in real `itemsin.json` and actually granted + auto-equipped at creation. Verified all 6 classes' flavor gear names resolve to real item rows. - `combat.js` rebuilt: `armorClass`/`dodgeChance`/`blockValue`/ `weaponSkillIndex`/`weaponDamage` are now faithful-shaped ports of the reference's real formulas, using real equipped items and each class's real starting-skill pairs from `charin.json`. Weapon type correctly selects the governing skill (Axe/Blunt/LongSword/ShortSword), armor category correctly selects Heavy vs. Light Armor skill. - Tested before shipping: verified Barbarian's real Axe skill pair ((4,45)) and Hatchet's real damage value (16, matching the raw `itemsin.json` byte we'd printed all the way back in Stage 2) both flow through correctly; 200 simulated fights with no negative-HP bugs or stalemates. **Still simplified, not byte-exact:** `skillValue()` here is just the static starting skill level — no progression/leveling, no attribute bonus (the reference's `skill_value(idx, with_attrib)` adds an attribute-derived bonus we haven't traced). Monster-side hit chance and armor remain the Stage 4 approximation, since the monster `attr()` indirection (mapping the 17 opaque per-monster stat bytes to meaningful fields) still isn't mapped — that's the one piece of this system that resisted the reference too, since it's monster-specific and wasn't included as a clean lookup table the way items/skills were. ## Done (Stage 11) — combat formula is now exact, not approximated `monster.attr(idx)` turned out to be direct index access into the same 17-byte row already sitting in `monstersin.json` — no hidden semantic layer to reverse-engineer. Once the reference confirmed which index means what, both attack directions became a straight, verifiable port: - `combat.js` rewritten to mirror `character.py`'s `melee_attack` and `monsters.py`'s `attempt_attack` exactly: the delta/contest/outcome resolution, damage-vs-armor formula, and the `outcome===1` (double block/armor) / `outcome===3` (double damage) branches are all real now, not shaped approximations. - Monster HP is now `attrs[14]` directly (confirmed exact match to the reference's spawn code) instead of a difficulty-scaled guess — `dungeonGenReal.js` updated accordingly, and the placeholder `atk` field is gone entirely (replaced by the real multi-attribute formula). - Tested before shipping: ~1260 simulated fights across all 42 real monster types (30 trials each) plus a 300-trial run against a named real monster ("Sickly Bandit") with its actual attrs printed — zero negative-HP bugs, zero stalemates. - One deliberate, documented deviation: the reference's dice rolls reuse the seeded world-gen RNG for determinism; combat here uses `Math.random()` instead, since replaying an identical fight isn't something this app needs the way reproducible dungeon layout is. **Still simplified:** `skill_value()` remains the Stage 10 simplification (static starting level, no attribute bonus, no progression) — all the `spell_effect_active(N)` branches in the reference are correctly omitted since there's no spell system yet, not silently dropped. ## Done (Stage 12) — spells Ported `spells.py`'s casting logic for the specific spells the 7 classes actually start with — confirmed via `wikiData.js`'s `spells` lists cross- referenced against `spellsin.json`, only 5 unique spells needed covering (all 5 confirmed present, correct IDs): Damage (id 11), Heal Wound (21), Paralyze (16), Frenzy (1), Daedric Weapon (6). - **Damage, Heal Wound, Paralyze: faithful ports.** Real `_spell_roll` contest (skill vs. the spell's own resistance/opposition fields from `spellsin.json`), real resource-spend-on-partial-success formula, real damage/heal magnitude formulas (Destruction/Restoration skill-scaled). Paralyze's actual effect is simplified — the reference threads a tick-duration flag through the monster's turn loop (`monster.extra[6]`); here it's "skip N of the monster's next counterattacks," same shape, not the same underlying mechanism. - **Frenzy, Daedric Weapon: simplified stand-ins.** The reference applies these as duration-ticked buffs threaded through `attack_damage_base` via `spell_effect_active(N)` checks scattered across the codebase — real plumbing we haven't built. Here, a successful cast (real roll, real resource cost) just grants a flat damage bonus for the rest of the current fight. Clearly not the same mechanism, flagged as such in `spells.js`'s header rather than silently passed off as exact. - Player now tracks real Magicka (`computeCoreStats`'s already-verified formula), shown in the combat HUD alongside HP. Spell buttons in combat grey out when unaffordable. - Tested before shipping: verified all 5 spell names resolve to correct IDs in `spellsin.json`; 100 trials of damage/heal/paralyze against real monster data with a real Sorcerer's real Destruction skill pair — no negative HP/magicka, no over-heal past max. ## Done (Stage 13) — HUD: radar minimap + real stat bars The person shared a screenshot of the original's in-dungeon UI, which showed two things missing entirely from our first-person view: a 7x7 FOV radar in the top-left corner, and three colored HP/Magicka/Fatigue bars. Both ported with exact pixel specs from `canvas.py`: - **Radar** (`_draw_radar`/`vision_grid`): 7x7 grid, facing-relative sampling (rotates with the player, not just north-up), 3px cells with 1px padding, positioned at (10,20). Color legend matches exactly: black wall, white open floor, green center (player), red monster, blue chest, purple stairs/exit. A letter above (N/E/S/W) shows current facing. Sanity-tested the facing-relative transform against a synthetic corridor before shipping (center = player's own floor tile, ahead matches corridor continuation, off to the side correctly shows wall). - **Stat bars** (`_draw_stats_bars`): exact pixel spec — three 40x7 yellow background rects at y=130/138/146, colored fills inset 1px, width scaled `current/max * 38`. Health=red (top), Magicka=green (middle), Fatigue=blue (bottom) — confirmed this ordering directly from the reference rather than guessing from the screenshot alone. `mountDungeon()` now always calls `ensureLivePlayer()` before mounting so these have real data to draw from the moment a dungeon loads. - Fatigue is display-only (always shows full) — there's no fatigue-drain mechanic implemented, so `livePlayer.fatigue` is just a static max. **Bug caught during this stage, worth noting for future work on this project:** `node --check` did not catch a duplicate `const player` declaration in `firstPersonView.js` (two different variables — the opts-passed HP/Magicka stats object and the existing position/facing tracker — colliding on the same name in the same scope). Only an actual `import()` surfaced it. Went back and import-tested every module in the project after fixing it; everything else was clean. **Takeaway for whoever continues this: `node --check` alone isn't sufficient for these files — actually import them (`node --input-type=module -e "import(...)"`) before considering a change verified.** **Not done from the same screenshot:** the bottom panel's 4 icon+number slots (explosion/book/?/zzz with 3/5/7/0 below them) weren't ported — those are keypad-shortcut legends for the original's physical numeric keypad (3/5/7/0 = which key does what), not inventory or spell slots. Given this port already has on-screen buttons for those actions, a keypad legend has little value here — flagging the decision rather than silently skipping it. ## Done (Stage 14) — camp hub + dungeon selection Wired `generateCamp()` (ported back in Stage 9, but never actually reachable) into the real game flow, replacing the hardcoded "always enter dungeon 1" behavior: - `campAsDungeonShape()` in `dungeonGenReal.js` adapts the camp's raw x-major `{tiles,width,height}` into the same shape `generateDungeon()` returns, so the existing views render it with no special-casing. The cross-shaped layout's 4 arms naturally meet the outer ring at four points — marked as a new grid legend value (7 = portal, distinct from 4 = dungeon exit) so stepping on one opens dungeon selection instead of "leaving." - Both views (`dungeonView.js`, `firstPersonView.js`) and the radar got the new portal cell type wired through — walkable, non-blocking, its own color in both the top-down map and the minimap. - New flow: Main Menu / Continue Game -> **Dawnstar (camp)** -> walk to any gate -> pick from all 36 real dungeons (or Random) -> real generated dungeon -> reaching the exit or leaving returns to camp, not a dead end. - Tested before shipping: verified all 4 gate cells exist and are reachable from the camp's spawn point via flood-fill (not just "no crash") before wiring it into the UI. **Caught and fixed a duplicate-function-declaration bug while wiring this up** — same class of issue as Stage 13's variable collision, this time two `function enterDungeon` declarations in the same module scope after an edit. `node --check` did not catch it either time. Fixed, then re-verified by actually importing every module (`main.js` included, via stubbed `document`/`window`/`localStorage`/`fetch` globals since it touches the DOM at module scope) rather than trusting `--check` alone. **Not faithful, flagged in the UI copy itself:** all 4 camp gates currently open the same full 36-dungeon picker, rather than each gate leading to its own specific dungeon the way the original's `geomin.json`-driven edge-adjacency system does. That data is parsed (`geomin.json`, Stage 2) but the adjacency graph itself isn't built. ## Done (Stage 15) — NPC shops Ported the 4 real shop peddlers from `npc.py` (itself `k.java`) — names, camp positions, and wares all straight from `NPC_NAMES`/`NPC_X`/`NPC_Y`/ `NPC_WARES`: - Weapon Peddler, Heavy Armor Peddler, Light Armor Peddler, and Jakar's, placed at their exact real camp coordinates — all 4 confirmed to land on real floor tiles already carved by the Stage 9 camp layout (no adjustment needed), and confirmed reachable from spawn via flood-fill. New grid legend value 8 = NPC, blocking like a monster (bump to talk). - Wares use the reference's real 1-based item-id lists, resolved against our own `itemsin.json` — verified all 50 total ware entries across the 4 shops resolve to real items, zero missing. - Real dialogue: confirmed `npcstrings.json`'s groups 0-3 are exactly each peddler's [greeting, insufficient-gold, purchase-success] lines (this was actually the very first thing decoded all the way back in Stage 2 — "Welcome! Please peruse our manufactured mayhem makers." was sitting in the data the whole time without a UI to show it in). Real greeting shown on entering the shop; real success/failure line shown after each purchase attempt. - Buying deducts real gold, adds the real item, and auto-equips it if equippable — same mechanic as chests (Stage 10). - Champions and Eustacia (`NPC_NAMES` indices 4-8) aren't placed — those are quest-giver/companion NPCs tied to the clue-log/traitor subplot, not shops, and are a separate, larger feature (see below). ## Done (Stage 16) — skill progression, leveling, real fatigue Ported `character.py`'s `gain_skill` — the actual trigger condition and formula, not a guess: - **Real trigger, confirmed from two call sites**: skill exp only increases on a solid hit or better (`contest` result >= 2, excluding the weaker "result 1" grazing hit) — true for both melee (`melee_attack`) and spells (`_spend_spell_resources`, i.e. our `spendResources`). +1 exp per qualifying action, 10 exp = +1 skill level, 10 character Level XP (accumulated from skill-ups) = +1 character Level. - `src/skillProgression.js`: `gainSkill()` grows `skillPairs[idx]` from the `[level, cap]` pairs `charin.json` provides into `[level, cap, exp]` triplets at runtime. Combat and spell buttons now show real feedback ("Skill improved!", "Reached Level N!") and the HUD shows current level. - **Real fatigue drain on spell casts** — fatigue was display-only (always full) since Stage 13; now it actually depletes. Simplified vs. the reference's `5 * encumbrance()` (gear-weight-dependent, we don't model carry weight) to a flat 5 per cast — a real mechanic, not the exact original formula. - Leveling up is itself a simplification: the reference opens an attribute-allocation screen tied to which skills leveled (`skill_marks`); here it's a flat +2 max HP / +1 max Magicka and a full heal, a real reward but not the original mechanism. - Tested before shipping: 500 simulated attacks against an immortal target with real Barbarian/Hatchet data (Axe skill grew 4->51 with no cap-clamping — confirmed the reference doesn't clamp skill level against the cap value either, so this isn't a missing bound, it's faithful); 100 simulated Sorcerer Destruction-spell casts, confirmed fatigue floors at 0 and never goes negative, zero bugs in either run. **Not done:** the reference also reduces `skill_value` by 1 when fatigue drops below 7 — real fatigue now exists to make that meaningful, but the penalty itself isn't wired into `skillValue`/`armorClass`/`dodgeChance`/ `spellRoll` yet, so draining fatigue currently has no downstream combat effect. Small, cheap to add later, listed below rather than rushed in. ## Done (Stage 17) — audio + mobile touch controls The person asked for audio and UI/UX work. First checked whether there was anything to port: grepped the full decompiled source for `playTone`/`Manager`/`javax.microedition.media` — zero hits, and the jar contains no audio files at all (confirmed via the same archive-listing approach used since Stage 2). MIDP-1.0, no media APIs, genuinely silent game. So this stage adds two things rather than porting them: - **`src/audio.js`**: ~12 short synthesized sound effects (Web Audio API oscillators + one noise burst for hit impact) — click, move, bump, hit, miss, cast, heal, chest, gold, victory, level-up (an ascending arpeggio), defeat, door, paralyze. Wired into combat, spellcasting, chests, shop purchases, and portal/exit navigation in `main.js`. A mute toggle (persisted to `localStorage`) sits on the main menu. Verified every single `sfx.*` call is a safe no-op when `AudioContext` doesn't exist at all (not just muted) — tested by stubbing it as `undefined` and calling all 12 functions directly, zero throws. - **Touch controls for both dungeon views** — this was a real, unflagged gap: movement was keyboard-only, meaning the port was literally unplayable on a phone despite "playable in a 2026 browser" being the original ask. Added an on-screen d-pad (forward/back/turn or up/down/left/right depending on view, plus an act button for the first-person view) using real `