jpmschweitzerandClaude Opus 4.6
9f91fd077f
3-round workshop (7 participants + Qatux + SI) deciding content generation architecture for NPC observable behaviors and dialogue. Key decisions: - D-138: LLM re-voicing pipeline (Gemma 2B Q4, llama-cpp-rs, bundled) - Behaviors + dialogue both re-voiced; tells always passthrough - Tells as read-only context inputs shaping surrounding content tone - Cache-as-determinism, separate thread pools, layered hardware detection - Two-spike validation: plumbing first, then integration - D-123 amended (authoring tool + runtime enhancement) - D-124 superseded (door walked through) - Q-012 and Q-057 resolved Artifacts: Krenn injectors v2, NI-1-5, culture template, 6 dialogue constraints, tell-tone injectors, spike payloads, 12-risk register. 9 tickets created (#638-#647). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
3.0 KiB
LLM Voice Pipeline Workshop — Round 3 Inputs
Source: Team lead interview with Jeroen after Rounds 1-2 Date: 2026-03-07
Jeroen's Decisions
These are binding inputs for Round 3. The team produces the D-record and implementation plan around these.
1. Scope: Behaviors + Dialogue (full pipeline)
"We don't introduce a precision laser cutting tool and then use it only to open boxes." Both observable behaviors AND dialogue get re-voiced. This is the long-term architecture.
2. Tell Treatment: Passthrough with Context Influence
Tells are mechanical signals, not culture. They stay as base text — always. Swapping them confuses the player.
However, tells INFORM the LLM context for dialogue and behavior. When a player engages an NPC who has an avoidance tell, the NPC's dialogue should be phrased in an avoiding way. The tell itself is untouched; the tell's presence shapes the re-voicing prompt for surrounding content.
This is a critical distinction: tells are read-only inputs to the LLM, never LLM outputs.
3. Spike Strategy: Two Spikes
Spike 1 — Plumbing + Quality (no integration):
- Build the Rust llama-cpp-rs wrapper. Load Gemma 2B and Phi-3. Prove the plumbing works: accept prompt, return text.
- Then Jeroen, Mellanie, and Paula manually craft prompts — culture injectors, behavior seeds, dialogue seeds — and feed them through by hand.
- Test both models against the same prompts. Answer the question: "does this even play?"
- No game integration, no queue, no cache. Just the inference tool and manual prompt experimentation.
Spike 2 — Integration:
- Wire the validated runner into the pre-voicing pipeline.
- Queue, cache-as-determinism, thread pool isolation, baked content generation, fallback behavior.
- The full architecture as designed by the team.
- Uses whichever model won Spike 1.
4. D-123 Amendment
Amend D-123 to cover both baked (build-time, human-reviewed) and pre-voiced (runtime background) modes. Supersede D-124. Paula's distinction between the two modes must be explicit in the amended record.
5. Model Provenance
Strong preference against Chinese-origin models (Qwen/Alibaba). Gemma (Google) is the primary candidate. Phi (Microsoft) is the fallback. Reconsider the constraint only if benchmarks on both fail to meet the quality bar.
6. Distribution: Bundled
Model ships with the game install. No optional download step. ~1.5GB added to install size is acceptable.
7. Hardware Detection: Layered
- Layer 1: CPU/RAM check — can the model even load?
- Layer 2: Time-per-token benchmark on first enable — is inference fast enough to be useful?
- Layer 3: Recommendation to disable if below threshold, but player can always override
- No hard minimum spec floor. If they're patient, let them run it.
- Always an option to disable ("AI-Enhanced Dialogue" toggle).
8. No Minimum Spec Floor
The question isn't "what hardware do we refuse to run on" — it's "when do we recommend turning it off." The system runs on anything that passes the RAM check; the recommendation threshold handles the rest.