Inspiration

A livestream is usually a finished game with a chat beside it. We wanted a small community to change the game together while everyone watches the result appear.

What it does

ChatForge turns Twitch chat into the game's dev team:

  • Viewers pitch features with !idea. An AI Producer turns the best ideas into three cards, and chat votes with !vote.
  • The winning idea becomes a real mod written live by the Codex SDK.
  • A deterministic Gatekeeper tests the mod before it can join the running Forge Keep game.
  • The overlay shows the build as it happens, credits the viewer who pitched the idea, and showcases the result. Chat can then trigger the new feature with its own command.
  • Unsafe ideas are refused by local rules and OpenAI moderation before they reach the broadcast.
  • The keep and patch history persist between streams. If a mod fails live, the game rolls back to the last good checkpoint.

How we used Codex

  • Codex built ChatForge. Codex built the project from an empty folder in one main thread, guided by the lead prompts preserved in brief/prompts/. The build log is in docs/CODEX_JOURNEY.md.
  • Codex is the live Builder. Inside the product, a separate Codex SDK Builder writes each winning idea as a single-file mod in a restricted workspace. It works against a typed mod API, and failures are repaired automatically within a retry budget. The overlay shows a sanitized tail of the code and a sprite preview while Codex works.
  • The final fixes and the video edit were finished outside Codex after the plan's Codex allowance ran out. These are documented in the journey log.

How we built it

  • A Node server receives Twitch EventSub events, runs the round state machine, and owns SQLite persistence.
  • A worker thread runs the deterministic game. Mods run only inside QuickJS and talk to the game through a command buffer.
  • The Gatekeeper runs static checks, two 900-tick simulations, a determinism hash and a spectacle score.
  • A Canvas overlay renders snapshots, and a React dashboard gives the streamer control.

Challenges we ran into

  • Keeping untrusted input away from the host. Chat text and generated code must never reach host execution, so ideas pass rules and moderation and code passes static and simulation checks.
  • Rollback without losing the world. We had to preserve world state when a live mod is rolled back.
  • Making the build watchable. A 45–60 second build needed to be interesting on stream.
  • Fixes found on real streams:
    • A mod could consume its own cooldown when deployed.
    • Real viewer ideas could lose to the simulated crowd.
    • A failed curation could stall a round.

Accomplishments we're proud of

  • A 45-minute SIM-only soak shipped 21 of 21 real builds.
  • A Twitch + SIM run shipped 3 of 3 on the first attempt, with a 40.3 s median build.
  • In the final demo take, a real Twitch idea from @vansyson1308 became card one, won the chat vote, and shipped as Keep Calm and Roar, credited to that account.
  • 249 automated tests pass. A live moderation regression check matched all 26 expected decisions.

These are measured runs, not claims that every generated mod will pass.

What we learned

The on-stream moment matters as much as the compiler result. We also learned to:

  • label simulated contributors clearly,
  • fail closed when moderation is unavailable,
  • report real test limitations instead of presenting a staged result as live.

What's next for ChatForge

Broader accessibility and mod-authoring tools, plus better admission checks and observability based on real streams.

Run it yourself: see the README in https://github.com/vansyson1308/chatforge. Viewers tagged (SIM) are a labelled simulated crowd; @vansyson1308 is a real Twitch account.

Built With

Share this project:

Updates

Submission history