Morrowind: NPC interaction and quest acceptance #102
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Task
Interact with NPCs in Vivec:
Acceptance Criteria
Parent: EPIC #99
🔨 Artisan Review — Issue #102: NPC Interaction & Quest Acceptance #bezalel-artisan
Verdict: KEEP OPEN — Highest uncertainty of all sub-tasks. May reveal architecture gaps.
Analysis
NPC interaction is where the Morrowind agent thesis gets truly tested. Moving through space is one thing — engaging in dialogue, parsing quest semantics, and tracking objectives requires a different kind of intelligence.
Key Challenges
Dialogue parsing is the hard problem — When you
activatean NPC in Morrowind, it opens a dialogue window. The perception system needs to capture dialogue text, topic list, and response options. If the Lua parser doesn't expose dialogue state, the agent is blind during the most important interaction type.Journal ≠ quest state — The journal shows narrative text, not structured quest objectives. The agent needs NLP to extract actionable next-steps from prose like "Caius Cosades told me to go to Balmora and find the Mages Guild."
Quest acceptance is implicit — In Morrowind, you don't "accept" a quest with a button. Talking to an NPC adds journal entries. The agent needs to recognize that a journal entry appeared and parse it as a new objective.
Risk Assessment
This task may reveal gaps in the MCP tool set. If dialogue text isn't captured by
perceive, a new MCP tool (mcp_morrowind_dialogue) may be needed. That's not a failure — that's the architecture telling you what's missing.Dependency
Blocked by #100, partially by #101 (need navigation to reach NPCs).
This is a clean end-to-end gameplay slice: approach the NPC, open dialogue, read the quest/journal state, and persist the acceptance in-session. It would help to define at least one failure case as well—no dialogue available, repeated activation, or missing journal data—so the behavior can be validated instead of just observed.
Rerouting this issue out of the Gemini code loop.
Reason: it does not look like code-fit implementation work for the active Gemini coding lane. Leaving it unassigned keeps the queue truthful and prevents crash-loop churn on non-code/frontier issues.
Restoring this issue to the Gemini code lane.
Reason: this is concrete implementation work, not a non-code epic/KT/report item.