108 lines
6.8 KiB
Markdown
108 lines
6.8 KiB
Markdown
 
|
# Open questions
|
|||
|
|
|
|||
|
|
Ordered roughly by how much they block work. Q1–Q3 affect the design; the rest are preferences I can pick defaults for if you'd rather not decide up front.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### Q1 — Tolk DLL placement and how you launch the game *(blocking Phase 0)*
|
|||
|
|
|
|||
|
|
`ffi.load("Tolk")` goes through the Windows loader, so `Tolk.dll` + the screen-reader clients (`nvdaControllerClient64.dll`, `SAAPI64.dll`, …) must be next to the **executable** or on `PATH` — they can't live inside a `.love` archive.
|
|||
|
|
|
|||
|
|
Copies already exist on this machine at `D:\code\cafe`, `D:\code\dragonrpg-mapmaker`, `D:\code\DragonWarriorAccess`.
|
|||
|
|
|
|||
|
|
- How are you running the game right now — `love.exe "D:\code\Sulphur Memories..."` from a shortcut, or something else?
|
|||
|
|
- Is the end goal a **fused .exe** (via `build.lua` / love-build, DLLs shipped alongside) or a **source folder + system LÖVE**?
|
|||
|
|
- Are you happy for me to copy the DLLs into the project (or a `dist/` staging folder), or do you want them kept out of the tree?
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### Q2 — Object tracker semantics *(blocking Phase 3)*
|
|||
|
|
|
|||
|
|
I've assumed a three-level hierarchy:
|
|||
|
|
|
|||
|
|
- **Category** (`Ctrl+PgUp/PgDn`) → "Creatures", "Items", "Exits", …
|
|||
|
|
- **Item within category** (`PgUp/PgDn`) → distinct *kinds*: "rat", "beetle", "guard"
|
|||
|
|
- **Instance** (`Shift+PgUp/PgDn`) → the specific rat: "rat 2 of 3, 5 tiles north-west"
|
|||
|
|
|
|||
|
|
Is that the model you have in mind? The alternative reading is that PgUp/PgDn walks a flat distance-sorted list of every object in the category, and Shift only kicks in for same-named ones. Both are defensible; the first is more structured, the second faster to sweep.
|
|||
|
|
|
|||
|
|
Also: my proposed categories are **Creatures / Items / Exits / Interactables / Terrain features / Alchemy**. Anything you'd add, drop, or split? (Alchemy ingredient nodes are broken out separately because the game is built around harvesting them — tell me if that's over-thinking it.)
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### Q3 — Verbosity and how much to *add* vs. *relay*
|
|||
|
|
|
|||
|
|
The game already produces good description text (`getCursorMessage`, the popup lines). I can either:
|
|||
|
|
|
|||
|
|
- **(a) Relay only** — speak exactly what a sighted player reads. Faithful, low risk of the mod drifting from the game.
|
|||
|
|
- **(b) Relay + augment** — add distance, direction, passability, visible-vs-remembered, "has loot", etc.
|
|||
|
|
|
|||
|
|
I've assumed **(b)** for tile examination, since bare descriptions without spatial context aren't much use non-visually. Confirm? And should augmentation be a verbosity setting (terse / normal / verbose) rather than fixed?
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### Q4 — Auto-speak policy for the console
|
|||
|
|
|
|||
|
|
A single game turn can emit several log lines (combat flavour, status changes, ambient flavour). Options:
|
|||
|
|
|
|||
|
|
- Speak everything, queued, in order — thorough but can lag behind fast play.
|
|||
|
|
- Speak everything except `colorTemplate == "flavor"` (the greyed-out ambient text), which stays review-only.
|
|||
|
|
- Speak everything, but let a new keypress interrupt the pending queue.
|
|||
|
|
|
|||
|
|
I lean toward: **speak everything, queued; a new player action interrupts leftover queue**; with a config toggle to mute flavour. Sound right?
|
|||
|
|
|
|||
|
|
Related: the game **coalesces** repeated identical messages into `"message (x3)"`. Should speech do the same, or announce each occurrence?
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### Q5 — Wall tones: when do they fire?
|
|||
|
|
|
|||
|
|
You've supplied `walltone_{north,south,east,west}.wav`. Candidate triggers:
|
|||
|
|
|
|||
|
|
- **On bump** — the player tries to move into a wall and can't. Unambiguous, low noise.
|
|||
|
|
- **On adjacency** — a tone whenever a wall is directly adjacent, as an ambient orientation cue. Richer, but potentially constant in a corridor.
|
|||
|
|
- **On the surroundings-scan key only** — explicit, never intrusive.
|
|||
|
|
|
|||
|
|
What were you picturing? And should they be **positioned** audio (LÖVE's `TEsound.playPositioned`, panned by direction — the game already sets an inverse distance model) or flat stereo?
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### Q6 — Keybindings: integrate or stay separate?
|
|||
|
|
|
|||
|
|
The game has a proper rebindable-keys system with contexts and a `keybindings_menu` screen, persisted to `keybindings.json`.
|
|||
|
|
|
|||
|
|
- **Integrate:** register our commands into `models/keybindings.lua`'s tables so they show up in the game's own rebinding UI and get conflict detection for free. Nicer for the player; more coupling, and it writes our commands into the player's `keybindings.json`.
|
|||
|
|
- **Separate:** our own `accessibility/keys.json` and our own (spoken) rebinding flow. Fully decoupled; duplicates a system that already exists.
|
|||
|
|
|
|||
|
|
I lean **separate** for decoupling, but reusing `keybindings.checkForConflicts` to warn about clashes. Preference?
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### Q7 — How much game-file editing is acceptable, really?
|
|||
|
|
|
|||
|
|
`debug.getupvalue` lets us read menu focus with **zero** game edits, at the cost of depending on internal variable names (`selectedOption`, `optionsList`) that could be renamed in any future version. The alternative is ~13 small patches — one `access.announce(...)` call per state — which are far more robust but must be re-applied on every version bump (manageable via the git-rebase workflow in `02-hooking-strategy.md`).
|
|||
|
|
|
|||
|
|
My recommendation: **upvalue probing by default + a startup self-test that loudly reports any probe that stopped resolving**, so a broken version bump is obvious immediately. But if you'd rather have boring-and-robust over clever-and-fragile, say so now — it changes Phase 4's shape substantially.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### Q8 — Scope of "everything mouse-only"
|
|||
|
|
|
|||
|
|
Good news from the research: **all 28 states already implement `keypressed`**, and the ones I read (`inventory`, `craft`, `ingame`, `ingame_observe`, `ingame_dialogue`, `main_menu`) are genuinely fully keyboard-driven. So the gap is *narration*, not *reachability*.
|
|||
|
|
|
|||
|
|
I haven't yet exhaustively verified every state for mouse-only corners — likely suspects are the slider in `craft`/`refine`, the `worldmap` travel targets, and `keybindings_menu`'s key-capture flow. Do you want me to do a full keyboard-reachability audit of all 28 states as an explicit deliverable (adds a doc, moderate time), or handle gaps opportunistically as they surface during Phase 4?
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### Q9 — Testing and target screen reader
|
|||
|
|
|
|||
|
|
- Which screen reader do you use (NVDA, JAWS, SAPI)? Affects interrupt behaviour and punctuation handling.
|
|||
|
|
- Do you want me to actually **run** the game with `lovec.exe` during development to verify hooks fire (I can, LÖVE 11.5 is installed), or would you rather drive testing yourself and have me work from the source?
|
|||
|
|
- Is there an existing save file I can load to reach a populated level quickly, or should I plan around the tutorial start?
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### Q10 — Upstream intent
|
|||
|
|
|
|||
|
|
Is this purely a personal/community mod, or do you intend to offer it to the developer (Spellweaver) for upstreaming? If upstreaming is plausible, that argues for the clean-patches approach over upvalue probing, and for integrating with the game's own keybindings and settings systems rather than running parallel ones.
|