Simon’s Brilliant Game Emporium

A Twitch-oriented multiplayer experience platform where private controllers, hidden roles, persistent state, and an AI host power interactive social games like Signal Lost.

Comment

Inspiration

I did not want to build a single Twitch game.

I wanted to build a system where a streamer could host many different interactive experiences for their community without rebuilding the underlying multiplayer infrastructure every time.

That became Simon’s Brilliant Game Emporium.

The Emporium is the larger platform. Signal Lost is its first attraction: a social-deduction experience designed around a shared public game screen, private player controllers, hidden information, persistent multiplayer state, and an AI host.

The larger idea is simple: build the venue once, then build new attractions inside it.

What it does

Signal Lost is a Twitch-oriented multiplayer social-deduction game.

Players join through private browser-based controllers while the main game state is presented publicly for the streamer and audience.

The experience includes:

  • private player controllers;
  • hidden clues and role-specific information;
  • a Saboteur role;
  • public decision and projection states;
  • Crowd Read mechanics;
  • Twitch authentication;
  • persistent multiplayer lobbies;
  • reconnect and recovery behavior;
  • role and information boundaries;
  • an AI host named Simon.

Simon can help present and operate the experience, but the AI is not the authority over game truth. Authoritative state, scoring, roles, and progression remain in the deterministic application runtime.

That separation became an important part of the architecture.

How we built it

I designed the product architecture, gameplay model, system boundaries, and engineering workflow, then used Codex extensively as an implementation and engineering agent inside those boundaries.

Codex helped me:

  • inspect the existing system;
  • implement bounded changes;
  • diagnose failures;
  • modify frontend and backend components;
  • run and repair tests;
  • investigate multiplayer and WebSocket behavior;
  • harden reconnect flows;
  • build deployment packages;
  • validate production behavior;
  • prepare a sanitized competition repository.

I used my own Workshop runtime to keep product authority separate from implementation work.

That meant Codex could move aggressively through engineering tasks without silently deciding what the product was supposed to become.

I made the product and architecture decisions. Codex operated inside the runtime I designed.

A large amount of the hardest work happened through Codex CLI directly on my VPS, close to the actual production environment.

Challenges we ran into

The biggest challenge was not creating a prototype. It was turning the idea into a system that could survive real multiplayer behavior.

One production issue involved a malformed WebSocket path capable of crashing the backend. I diagnosed the failure, reproduced it, and hardened the system against hundreds of malformed connection attempts.

Other challenges included:

  • reconnecting players without corrupting game state;
  • keeping private controller information private;
  • maintaining persistent multi-mission lobbies;
  • preventing repeated decisions after a state had already been locked;
  • handling final activation and projection states correctly;
  • recovering from interrupted deployments;
  • maintaining rollback capability;
  • reconciling development work back into the canonical project state.

I was also building over cellular internet, which meant unstable connections caused repeated disconnects during remote development.

Instead of allowing that to stop the build, I moved more execution directly onto the VPS and later reconciled that work back into the main development lineage.

That constraint changed how I thought about AI-assisted engineering.

Accomplishments that we're proud of

I am proud that this became more than a hackathon prototype.

The project reached a working production system with:

  • Twitch authentication;
  • private multiplayer controllers;
  • persistent game state;
  • reconnect handling;
  • hardened WebSocket behavior;
  • rollback and recovery tooling;
  • automated testing;
  • production deployment;
  • a reusable architecture for future attractions.

Signal Lost proved the first attraction could run.

The more important result is that the venue now exists.

What we learned

The biggest lesson was that using an AI coding system effectively is not just about giving it better prompts.

It is about giving it a better operating environment.

Codex became much more useful when it had:

  • explicit architectural boundaries;
  • clear authority limits;
  • persistent build state;
  • testing requirements;
  • recoverable execution;
  • evidence of previous work;
  • deployment context.

That allowed Codex to behave less like a code generator and more like an engineering component inside a larger system.

I also learned that building the reusable platform underneath a game changes the economics of everything built afterward.

Signal Lost required significant infrastructure because it was the first attraction.

The next attraction can inherit much of that work.

That is the real reason I built the Emporium.

What's next for Simon’s Brilliant Game Emporium

Signal Lost is only the first attraction.

The next step is expanding Simon’s Brilliant Game Emporium into a collection of streamer-hosted multiplayer experiences that reuse the same underlying identity, controller, lobby, state, recovery, and hosting infrastructure.

Instead of rebuilding multiplayer infrastructure for every game, future experiences can focus on what actually makes each attraction different:

the game itself.

Share this project:

Updates

Submission history