Inspiration
On a coding stream, chat has ideas all the time. Usually those ideas disappear into a scrolling conversation. I wanted the audience to shape the thing they are watching, and to see the moment their idea becomes playable.
What it does
Patch Party turns a Twitch coding stream into a collaborative arcade show. Viewers send !build suggestions in chat. The streamer approves two to five ideas, opens a ballot, and lets chat choose the next game change with !vote commands. Each Twitch account has one ballot and can change its vote before the timer ends. Eligible channels can use native Twitch polls instead.
The winning request goes to the project's existing Codex conversation. Codex writes a plan and a complete game module, then delivers it through a local file bridge. Patch Party runs fixed contract checks in an offline Docker container. The OBS overlay shows the idea, plan, test results and game. Passing checks unlock Put on stream; the streamer reviews the result and decides when to release it. A failed candidate leaves the previous game available.
The original game is Orbit Catch: move a paddle, catch stars and avoid comets. Chat can propose changes such as double points or a shield. Ordinary chat ballots avoid the channel-point and native-poll requirements of a new channel. Suggestions have a 30-second per-viewer cooldown, and the moderation queue holds up to 30 ideas.
The streamer can stop the round, terminate the displayed game or roll back to a previous released version. Candidate code runs in a container without network access or host secrets. During play, generated code runs in a terminable Worker with no Window or Document and a restricted drawing interface. Chat text is treated as feature data throughout.
How I built it and used Codex
I built Patch Party from scratch in one Codex conversation during the competition window. Codex wrote the Node.js server, Twitch EventSub WebSocket adapter, moderation and voting logic, original game, offline Docker runner, browser Worker player, OBS overlay, tests and run instructions.
I also used Codex to investigate failures across those components: the official CLI's subscription requirements, container file permissions, Worker startup and an overlay that exceeded 1080p. The checks ran against Docker, Chrome and the official Twitch CLI. A clean local clone then ran the README setup without a Twitch account or Client ID.
In a full review in the same conversation, Codex reproduced and fixed sandbox result forgery, Stop races during container and Worker startup, and Twitch reconnect races, then verified the fixes with regression tests and another clean-clone run.
Codex also added an account-free chat/poll rehearsal with tests for actual vote counts, native poll results and malformed input. It leaves the live adapter unchanged and opens no Twitch connection.
The show's build loop returns each winning task to that same conversation; the live round in the demo video resumes it. Codex reads the current module and game contract, implements the selected change and sends one replacement module through the bridge. The app exposes the plan, test outcome and release decision to the audience.
Codex session ID
Codex session ID: 01a17ae4-aa44-7143-8293-a76f106057f2
This is the existing conversation used to build the project from scratch.
How to run
Use Node.js 22.9+, npm and a running Docker Engine. The application serves native JavaScript directly, with no compilation step. Initial tool and image downloads need internet; candidate checks run offline.
From the repository root:
npm ci --ignore-scripts
npm run mock:install
docker pull node@sha256:fe4f6d74e20370acb04ad889077d14d0f64a9c8ea6a42bc60cddf1e844699914
For the interactive chat/poll demo, run npm run demo:local and follow the README terminal-event examples. It ignores .env, uses run/local-rehearsal/, and visibly labels all events as simulation. Its bridge command is PORT=3210 PARTY_RUN_DIR=run/local-rehearsal npm run bridge -- --file run/local-rehearsal/proposal.json. Stop this demo before starting the official CLI flow below.
Alternatively, run the official mock and the application in separate terminals:
npm run mock
npm start
Open http://127.0.0.1:3210. Use the two event commands in the README to populate the queue, approve both ideas and open the rehearsal ballot. The CLI emits synthetic reward events, not chat messages; with no chat votes, a tie selects the first listed idea. The UI and recordings label this path as rehearsal.
For an automatic end-to-end software check, run npm run test:twitch. It sends official CLI fixtures, delivers a fixed game patch through the bridge, runs real Docker checks, releases the result, reconnects EventSub and exercises stop. This is a reproducible software test, separate from the live Twitch/Codex demonstration.
For a manual build, give the winning task from run/current-task.json to the project's existing Codex conversation. Write run/proposal.json with buildId, plan and the complete module in code, then deliver it:
npm run bridge -- --file run/proposal.json
After passing checks, inspect the mechanic and choose Put on stream. The fixed contract checks exports, initial state, movement, simulation and drawing; playing the change confirms the requested behavior.
For a real channel, register a Public Twitch application and create an ignored local .env:
PORT=3210
TWITCH_MODE=live
TWITCH_CLIENT_ID=YOUR_PUBLIC_TWITCH_CLIENT_ID
Replace the Client ID placeholder locally. Leave the mock broadcaster/user IDs out. Start the app, click Connect Twitch and approve the device grant as the broadcaster. Wait for Live Twitch EventSub · chat connected, then send suggestions and votes in that channel. Live mode uses outbound WebSockets and needs no public webhook or server. Tokens stay in ignored local runtime files.
Add http://127.0.0.1:3210/overlay as a 1920 × 1080 OBS Browser Source on the machine running Patch Party. The README covers manual Twitch CLI installation on platforms other than Linux x64, required scopes, controls and troubleshooting. Stop the app and mock terminal processes when finished.
Challenges
The released Twitch CLI does not generate chat-message events. I kept its supported reward-event WebSocket rehearsal and added a separate local chat/poll driver, which feeds synthetic EventSub envelopes through the same parser. Its visible rehearsal label and isolated state keep simulated votes distinct from live-channel evidence.
A live build can fail, arrive late or finish after the streamer presses Stop. Each candidate belongs to a specific build ID, and a stopped or stale result cannot release itself. Native polls also need a fallback for new channels, so chat voting is the primary flow.
The review showed that candidate code could forge a passing test receipt and that delayed startup or reconnect work could outlive the action that cancelled it; separating the test controller from the candidate and checking cancellation across asynchronous work closed those failures.
Accomplishments
The complete local round runs from a clean clone: suggestions, approval, ballot, bridge delivery, offline tests, release, play and rollback. The verification suite passes 50 core/game/HTTP/adapter/bridge/local-rehearsal tests and 6 Docker integration tests, plus the official CLI and browser checks. The browser checks exercise desktop, mobile, the 1080p overlay, Stop during delayed startup, malformed Worker messages and Worker isolation.
On 2 November the whole loop ran on the real Twitch channel oll4com: two !build messages arrived through EventSub, the streamer approved them, a chat ballot chose "Double star points", the same Codex conversation changed one line and delivered the module through the bridge in about a minute, the offline Docker checks passed, and the streamer released it. Stop, rollback to the original module and an app restart that reconnected to chat were checked in the same session. Only the broadcaster account took part, so it shows the integration, not a crowd.
The streamer can see what Codex plans to change, whether the checks passed and which version is running. Tests unlock a release decision; the streamer keeps that decision.
What I learned
The moment I wanted to preserve is the handoff from a chat idea to a mechanic someone can play. Showing the plan and checks makes that handoff understandable. Keeping the previous game available lets the show continue while a candidate needs repair.
What's next
More small original games and feature-specific checks for the mechanics viewers request. The first version keeps one game, one channel and a build loop that fits into a stream.
Log in or sign up for Devpost to join the conversation.