Labyricorn - Twungeon

Twungeon

Christopher Chambers — Mon, 17 Aug 2026 00:00:00 +0000

Twungeon is a Twitch-controlled cooperative dungeon game. Viewers watch a shared dungeon on the stream while controlling their own characters through a Twitch Extension. Followers join intentionally with !spawn, take turns using simple action points, fight or evade a Goblin Guard, and cooperate to reach the exit.

Concept image illustrating the intended mature stream and viewer experience.

The MVP is designed to prove the complete interaction loop with real Twitch viewers: eligibility, identity binding, spawning, movement, combat, healing, death, Channel Points resurrection, floor advancement, and total-party reset. It uses a deliberately small two-room floor with one Goblin Guard so the project can test the social game idea before investing in balance, polish, progression, or production art.

The stream-facing experience has three required regions: a compact control/status area, the shared game view, and a running action log. When no players are active, the current floor remains loaded in a dormant state and invites an eligible follower to type !spawn.

The runnable proof of concept uses an authoritative TypeScript game core, deterministic two-room floor generation, HTTP and WebSocket boundaries, and a shared broadcast/controller interface. Twurple supplies the production Twitch boundary for chat, follower verification, Channel Points redemptions, and a Twitch Extension identity flow. The RPGJS boundary remains an authority-free render adapter rather than a completed engine integration.

The product source of truth is the Twungeon MVP Product Requirements Document. The approved technical specification defines the authoritative architecture and game behavior. The acceptance-test and build checklist sequences implementation and maps evidence to all 33 MVP success criteria.

The repository can run locally with synthetic viewer identities and has passing lint, type-check, domain, integration, and production-build gates. This is a proof of concept, not an accepted MVP: live Twitch credentials, independent setup, first-time-viewer usability, and real-viewer concept validation have not yet produced acceptance evidence.

Twungeon begins with a shared design conversation

ChatGPT 5.6 Sol High Reasoning and Christopher Chambers — Mon, 17 Aug 2026 00:00:00 +0000

Twungeon's first phase was an extensive design conversation between ChatGPT 5.6 Sol High Reasoning and Labyricorn (Christopher Chambers). The conversation turned an early game idea into a testable product boundary: a shared dungeon where Twitch viewers watch the stream, join with !spawn, and control their own characters through a Twitch Extension.

The resulting MVP is intentionally a proof of the social interaction loop. A party of viewers receives two action points per player phase and can move, attack, heal, or pass. One Goblin Guard protects the exit on a small, procedurally varied two-room floor. Players may fight it or run past it. Death matters for the current floor, Bits can provide an immediate resurrection, and reaching the exit brings the party forward while a total-party wipe resets the run.

Several design decisions protect the experiment from premature complexity. The game remains dormant rather than resetting when no players are active. Twitch chat identity and Extension identity must resolve to the same stable Twitch user ID. The stream view needs only a temporary but understandable three-part layout, including a chronological action log. Balance, production art, progression, multiple classes, advanced enemies, anti-exploit systems, and long-term persistence are explicitly deferred.

The conversation also made operator readiness part of the MVP. A clean checkout must be connectable to a Twitch channel using documented dependencies, credentials, Extension configuration, EventSub/chat setup, follower checks, identity binding, Bits events, startup steps, and troubleshooting guidance. The technical direction is RPGJS, Twurple, and a Twitch Extension, while the game rules should remain portable enough to survive a later engine change.

The complete boundary and its 33 success criteria are recorded in the current Twungeon MVP PRD. This entry marks the end of product definition, not the beginning of implementation. Future devlog entries will record technical planning, build phases, validation evidence, scope changes, and what is learned from real viewers.

The canonical source for this product-definition milestone is commit d67d9fc5230985895de9dd8232525ea8ca474e05.

Twungeon moves from product requirements into technical specification

ChatGPT 5.6 Sol High Reasoning and Christopher Chambers — Mon, 17 Aug 2026 00:00:00 +0000

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.

Twungeon adopts an acceptance-led MVP build plan

ChatGPT 5.6 Sol High Reasoning and Christopher Chambers — Mon, 17 Aug 2026 00:00:00 +0000

Twungeon's technical specification was approved as the implementation baseline, and planning moved into an acceptance-led build sequence. This remains a design and execution milestone: no runtime feature, Twitch integration, or viewer test is represented as complete merely because its checklist now exists.

The build plan organizes implementation into ten gated phases after the planning baseline. It begins with reproducible tooling and a framework-independent domain core, then adds dungeon generation, the local turn loop, Goblin behavior, player and floor lifecycles, production-shaped APIs and views, Twitch identity and chat, Bits resurrection, and finally independent setup and real-viewer validation. Each phase has a checkpoint intended to catch failures before work moves into a more expensive external integration layer.

The acceptance matrix assigns AT-001 through AT-033 directly to the PRD's 33 success criteria. It distinguishes automated domain evidence from browser, clean-install, live Twitch, multi-viewer, documentation, usability, and concept- validation evidence. A mock cannot close a live Twitch criterion, and a checked item can be reopened if later evidence invalidates it.

The plan also defines standard quality gates, evidence records, clean-checkout verification, change control, and the final MVP acceptance decision. Planning work is checked off where it is complete; every implementation and validation item starts unchecked.

The execution baseline is the Twungeon MVP Acceptance-Test and Build Checklist, used with the approved technical specification and the authoritative MVP PRD.

The repository baseline for this planning milestone is commit f3688cd62bccc25c22a9780f65d719104989104f.

Twungeon becomes a runnable Channel Points proof of concept

Codex and Christopher Chambers — Mon, 17 Aug 2026 00:00:00 +0000

Twungeon now has a runnable proof of concept rather than only a product and technical plan. The implementation establishes a framework-independent, authoritative TypeScript game core with player phases, action points, AutoGuard, movement, combat, healing, death, resurrection, Goblin behavior, floor advancement, total-party resets, ordered action logs, and stale or duplicate command rejection.

The implemented dormant-state broadcast and controller view.

A seeded generator produces connected two-room floors, while HTTP and WebSocket boundaries expose snapshots and authenticated commands. The shared browser UI supports broadcast and controller use, including the required dormant banner, map, status, controls, and chronological log. Synthetic identities and events make the loop usable without Twitch credentials.

The Twitch boundary is production-shaped but not yet live-accepted. Twurple handles chat identity and follower checks, the Extension gateway verifies Twitch JWTs server-side, and EventSub listens for one configured Channel Points custom reward. Redemption IDs provide deduplication and the stable redeemer ID must match the dead character owner.

This milestone also corrects the MVP scope. Earlier planning records described Bits resurrection; the current PRD, technical specification, checklist, contracts, implementation, tests, and operator guides now use Channel Points. Bits and Cheers are explicitly outside the MVP and have no gameplay handler. The historical entries remain unchanged as a record of the earlier decision.

The automated gates pass with linting, strict type checking, 19 domain and generator tests, 6 integration and multi-viewer tests, and a production build. These results verify the implemented local proof of concept. They do not claim that live Twitch credentials, independent setup, first-time-viewer usability, or real-viewer concept validation have passed.

The implementation and scope correction are recorded in commit 222cf903f657dcceb5b309cbd6231d4522e9b077.

Twungeon reaches a live Twitch concept milestone

Codex and Christopher Chambers — Mon, 17 Aug 2026 00:00:00 +0000

Twungeon is now running as a live Twitch-connected concept on the Labyricorn Twitch channel. The deployed service connects Twurple chat and EventSub to the broadcaster account, verifies Twitch Extension identity on the server, and serves the Extension through the public Cloudflare tunnel at https://twungeon.labyricorn.com.

The authentication path required more than supplying a static token. Twungeon now provides a confidential OAuth authorization-code flow with state validation, checks that Twitch returned the configured broadcaster and required scopes, stores access and refresh credentials outside the repository with restricted permissions, and persists refreshed credentials atomically. The Extension exchanges its signed Twitch JWT for a short-lived Twungeon session; the shared Extension secret remains server-side.

The first setup attempt exposed several integration mismatches. The original Twitch application had been registered as a public client before the callback endpoint existed, so live server authorization required a new confidential application and the exact HTTPS /oauth/callback redirect. Enabling identity linking also made a privacy notice mandatory before the Extension version could advance. Both requirements are now reflected in the implementation and operator documentation.

The first live Extension view rendered the complete broadcast game instead of a compact control surface. The shared frontend now switches to a controller-only layout at /extension, while / remains the full game view used by the stream. Cloudflare also continued serving an older JavaScript bundle during testing; static responses now use Cache-Control: no-store, and the Extension loads a versioned script URL to force the current controller code.

Spawning revealed one final usability gap. Chat !spawn was not sufficient for the broadcaster because a channel owner cannot follow their own channel, and the Extension offered no direct alternative. The control panel now includes a Spawn character button backed by an authenticated server endpoint. It uses the verified Twitch viewer ID, applies the normal follower rule, and treats the configured broadcaster as eligible. The same eligibility correction also allows broadcaster chat spawning.

The current deployment reports healthy with the Twitch adapter ready. Viewers can authorize their identity, spawn from the Extension, and use the movement, attack, heal, and pass controls for their own character. The configured custom Channel Points reward drives resurrection through EventSub. The final automated run passed linting, strict type checking, 24 domain tests, 10 integration and multi-viewer tests, and the production build.

This establishes the live interaction concept, but it is not a claim that every MVP acceptance gate is complete. Broader real-viewer, multi-viewer, usability, fault-injection, soak, and independent-operator evidence remains to be recorded. Game state is still intentionally in memory, so restarting the service starts a new run.

The live Twitch integration and spawn-control milestone are recorded in commit df984690cedf84fc58d3eb6e2000d2df567a8d5d.

Twungeon controls move into the Twitch video overlay

Codex and Christopher Chambers — Mon, 17 Aug 2026 00:00:00 +0000

Twungeon's viewer controls now sit directly over the control area reserved in the stream instead of opening as a large Twitch Video Component popup. The production viewer uses Twitch's Video - Fullscreen placement with extension as its relative viewer path. The broadcast continues to provide the dungeon, players, Goblin, exit, status frame, and action log underneath the Extension.

The change deliberately reuses the existing controller and authoritative backend flow. Twitch identity sharing, short-lived Twungeon sessions, character ownership, movement, attack, self-heal, pass, action points, phase checks, and dead-character checks still use the same APIs and server-side rules. The root page remains the complete local and broadcast view, while /extension receives an overlay class before first paint and hides every noninteractive game surface.

Overlay placement is expressed through centralized percentage-based CSS variables for the control region rather than resolution-specific coordinates. Container-relative sizing keeps the directional pad and action buttons usable across normal, theater, fullscreen, narrow, and 4:3 players. The transparent document and empty overlay canvas reject pointer events; only the actual buttons restore them, so the rest of the video is not presented as a large clickable surface.

Development remains practical without Twitch. The loopback-only /extension?dev=1&debug=1 mode exposes the existing synthetic viewer login and draws control-region boundaries. The flags are ignored on the deployed host. Operator documentation now identifies the Twitch dashboard setting as Video - Fullscreen, records the extension viewer path, and separates the manual dashboard change from repository deployment.

Live testing exposed a subtle transparency failure after the correct viewer path was saved. Although the document, body, and control region all computed to transparent backgrounds, the root color-scheme: dark declaration caused Chrome to paint the iframe canvas black. Dark color scheme now applies only to the full game page; overlay mode explicitly uses the normal transparent canvas. The stylesheet fix was deployed without restarting the Twungeon service, so the active in-memory run was preserved.

Validation covered linting, strict type checking, 24 domain tests, 10 integration and multi-viewer tests, and a production build. Browser checks at 1920×1080, 1280×720, and 1024×768 confirmed normalized placement, hidden noninteractive surfaces, button-only pointer handling, and transparent computed backgrounds. The deployed public stylesheet and viewer endpoint were verified after the final transparency correction.

The Twitch video-overlay implementation is recorded in commit a8a86852c0e06e518d816ea35400ef9878a365f3.

Private operations arrive with graceful viewer disconnects

Codex and Christopher Chambers — Mon, 17 Aug 2026 00:00:00 +0000

Live multi-viewer testing revealed an awkward failure mode: when a viewer left the channel, their character remained in the dungeon with unspent action points. Keeping the character was intentional because a refresh or temporary network failure should not destroy a viewer's progress, but waiting for its action-point deadline made each later player phase appear stuck.

Twungeon now tracks authenticated WebSocket connections per Twitch user. A viewer is marked disconnected only after their final socket closes, so a second tab remains valid and closing one of several connections does not incorrectly end the turn. On the last close, unused action points immediately become Guard. Extension-bound characters that remain disconnected also enter AutoGuard as each later phase starts. Their characters stay on the board for a safe reconnection while connected viewers can complete the phase normally.

The same milestone adds a private operator console for live troubleshooting. It runs on a separate listener rather than the public Twungeon origin. The production listener binds specifically to 10.138.4.44:3001, and the application rejects source addresses outside 10.138.0.0/16. Basic authentication, a unique generated deployment password, per-process form tokens, no-store responses, a restrictive Content Security Policy, and frame denial provide additional boundaries. The port is not exposed through the public web listener or reverse proxy.

The server-rendered console shows the current run, floor, phase, players, Twitch readiness, OAuth authorization, uptime, and the latest 40 action-log entries. An operator can disconnect a viewer into AutoGuard, remove a character, end the active player phase, or reset the run. These operations call the same authoritative game core used by viewer commands and broadcast the resulting snapshot to connected clients.

Configuration remains opt-in. The admin listener will not start unless it is explicitly enabled with a 10.138.x.x bind address and a password of at least 16 characters. Operator documentation records the environment settings, network boundary, authentication flow, and the requirement not to publish or proxy the private port.

Validation covered linting, strict type checking, a production build, 28 domain tests, and 13 integration and end-to-end tests. Deployment checks confirmed that the public service and Twitch adapter were ready, authenticated admin health succeeded on the private address, unauthenticated access was rejected, and the admin port was not listening on loopback.

The private operations and graceful-disconnect implementation is recorded in commit 8b1d14dceac8f9645f70cab106a045ed64bcd71c.

Four-player parties reform each floor with rolling turns

Codex and Christopher Chambers — Mon, 17 Aug 2026 00:00:00 +0000

Twungeon's party and turn rules have been tightened around a predictable four-player multiplayer loop. Each character now occupies one of four fixed slots with a stable color: blue, green, red, or yellow. A fifth spawn is rejected as party-full, and defeated characters continue to hold their slot until the floor concludes.

Completing a floor now clears the active party and returns the game to its dormant state with the next dungeon ready. Connected and authenticated viewers remain eligible to spawn again, so every floor begins with a fresh, first-come party formation instead of carrying character state forward.

The player phase now runs on a rolling five-second deadline. The first accepted command from each active player restarts that deadline from the command's arrival time. Repeat commands, rejected actions, and duplicate submissions do not extend the phase, keeping turns responsive without allowing one player to stall the game indefinitely.

The Twitch Extension now uses the same slot colors across dungeon markers, names, party status, action feedback, and administrative views. Its single frontend adapts to desktop and mobile contexts: mobile viewers receive larger movement and action controls plus an at-a-glance identity, color, health, action-point, and healing display.

Documentation and acceptance coverage were updated alongside the mechanics. The completed change passed the domain and integration suites, linting, type checking, production build, and desktop and mobile browser layout checks.

The implementation is recorded in commit 879cfd4fd071a240b79c25b5054a195578855130.