Twungeon · Devlog
Twungeon moves from product requirements into technical specification
Technical specification work began for the Twungeon MVP, translating the approved product boundary into authoritative state, component contracts, deterministic game rules, integration boundaries, and a verification strategy.
With the MVP product boundary recorded, Twungeon moved into technical specification work. This is still pre-development: the new document describes how the required systems should behave and interact, but it does not claim that runtime implementation has begun or that Twitch integration has been proven.
The draft establishes one backend as the authority for identities, game state, command ordering, random outcomes, phase transitions, and the action log. It separates framework-independent Twungeon rules from Twitch, RPGJS, transport, and presentation adapters so the prototype engine can later be replaced without discarding validated game behavior.
Several rules that needed implementation precision are now explicit. Player commands are serialized and validated against the latest state; phase deadlines are decided at the backend boundary; attacks are orthogonally adjacent; players may share tiles while the Goblin remains blocking; and refreshes reconnect to an existing Twitch-user-owned character. The draft also defines late-spawn and resurrection timing, Goblin path selection, total-party-wipe ordering, seeded floor generation, structured events, and failure behavior.
The specification maps the system into an authoritative backend, a Twurple adapter, an authenticated Extension gateway, a portable domain core, an RPGJS adapter, and shared broadcast and Extension views. A verification section ties unit, integration, live-channel, and multi-floor tests back to the PRD's 33 MVP success criteria.
The working draft is recorded in
Twungeon_MVP_Technical_Specification.md.
It is a technical planning baseline derived from the
current Twungeon MVP PRD.
Version-specific Twitch scopes, event configuration, the Bits price, and local
endpoint values remain integration-time decisions that must be documented and
verified before live acceptance testing.
The repository baseline for this planning milestone is
commit f3688cd62bccc25c22a9780f65d719104989104f.