Accessibility ModandClaude Opus 5
c17c5277d4
Game-file footprint unchanged: still one line in main.lua.
Three-level navigation as specified in D2: Ctrl+PageUp/Down cycles categories,
PageUp/Down cycles kinds, Shift+PageUp/Down cycles instances of that kind, Home
announces where it is.
- categories.lua: flag-first classification into Creatures, Items, Alchemy,
Interactables, Exits and Terrain features, reusing the game's own 'exit' tag
and excluding the six nameless mechanical templates.
- tracker.lua: scan, cache, navigation, announcements.
Caching keys on level name, player position and turn: position because
everything sorts by distance to the player, turn because creatures move and
containers empty. Scans run on keypress, never per frame.
FoV is respected throughout -- creatures only when currently visible, tiles when
visible or remembered -- so the tracker never becomes a cheat.
Home reports path length alongside the offset, via the game's own
calculatePathFromPlayer. Straight-line distance is misleading indoors, where a
chest three tiles north through a wall can be twenty steps away.
Corrects D4 in docs/05-decisions.md. I had claimed tile.tryInteract cleanly
separates 'the player can do something here' from scenery. It does not: 'wall'
carries a flavour-only tryInteractFunction ('You touch the wall. It's cold and
rough.'), so every wall segment was promoted into Interactables -- 13 in the
starting house, burying the chest and cauldron. Structural tiles
(blocksMovement and blocksVision) are now excluded before the tryInteract test;
containers and furniture block movement but not sight, so they survive.
12 kinds/19 instances instead of 13/32.
13/13 testbed checks, history unit tests passing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Accessibility mod — documentation
Research and planning for making Sulphur Memories: Alchemist 0.4.2 blind-accessible.
| Doc | Contents |
|---|---|
| 01-architecture.md | How the game is built: states, console, level model, keybindings, where text already exists. |
| 02-hooking-strategy.md | How to attach the mod with (near) zero edits to game files. |
| 03-implementation-plan.md | Six phases, each independently testable. |
| 04-open-questions.md | Decisions needed before/while building. |
| 05-decisions.md | Answers given so far, and what they imply. Supersedes Q1/Q2/Q7/Q10. |
The short version
Three findings shape everything:
-
The game is already keyboard-complete. All 28 states implement
keypressed; there's a full rebindable-keys system with contexts. The accessibility gap is that nothing announces what is focused — not that things are unreachable. This makes the job much smaller than a typical mouse-driven game. -
The game already writes the text we need to speak.
console.printis a single chokepoint for all log messages.level.getCursorMessage()returns tile/creature descriptions.getCursorPopupStats()feeds the item popups in five screens. We are mostly re-routing existing strings to speech, not writing a description engine. -
Everything is a
required singleton, anddebug.getupvalueworks. Module functions can be monkey-patched in place, and the file-localselectedOptionvariables in menu states are readable from outside. A one-line bootstrap inmain.luais the only unavoidable edit.
Proposed footprint: 1–3 lines added to main.lua, everything else new files under accessibility/. A git baseline tagged vanilla-0.4.2 makes re-application on future versions a rebase.