How games work

The mental model behind every game — a React frontend in your browser plus a backend reducer running sandboxed on our servers; input events processed one at a time into a shared timeline of turns; ticks that let a game act on a clock without the player; many screens (your devices, or several players) connected to one running session; and where the AI characters sit in the loop. Ends with what the platform is and isn't good at.

Every game on AI Chat Games — whether the coding agent built it from a single sentence or you hand-tuned it in the Code surface — runs on the same simple model. Knowing it helps you ask for the right things and understand what a game can (and can't) do.

Two parts, one game

Each game is a small TypeScript project with two entry points:

  • The frontend — a React component that runs in your browser (in an iframe in the Game Studio, or a dedicated window in full screen). It draws the game and turns your actions — a message, a button press, a card played — into input events.
  • The backend — a reducer: a function that receives input events and updates the game state. It runs in a sandbox on our servers and is the single authority on what's true in the game.

The frontend never owns the state — it renders whatever the backend last published. That split is what makes everything else on this page work: the game's real life is on the server, not in a tab, so any number of browsers can watch the same game — and, with your permission, a game can even keep playing after you leave.

Events, one at a time

The backend handles events serially — one at a time, each running to completion before the next begins, in the order they arrive. While handling an event, game code can update state, talk to its AI characters, kick off image generation, and stream narration back to the screen. Everything one event produced is recorded together as a turn in the game's timeline, then pushed to every connected screen.

Turns also record the AI's actual responses, so the timeline can be replayed exactly — that's what makes editing or retrying a past turn possible.

Ticks: acting without you

Events only happen when someone acts. Games that live on their own — a farm growing, a pet getting hungry, a countdown running out — also declare a tick: a handler the engine calls on a fixed cadence (every second or slower). Ticks run on the game clock, which only advances while the game is running — a suspended game's time stands still until you return.

Ticks are deliberately cheap bookkeeping — they can't call AI directly. When a tick decides something interesting has happened ("the timer hit zero", "the pet is starving"), it emits an input event, and the normal event flow takes over, AI and all.

With your permission, a game can keep ticking after you leave — for up to 48 hours — spending credits and even sending notifications. See background-play for the player-facing controls and time-and-ticks for how builders use the clock.

Many screens, one game

A playthrough is a session: one running backend holding one authoritative state. Any number of browsers can connect to the same session — your laptop and your phone, or several players — and every screen receives the same broadcast timeline, kept in sync live.

The engine treats every connected screen identically — it has no built-in notion of "player 1" and "player 2". A multiplayer game creates that itself in game code, for example by asking each player to pick a name and tagging their input events with it. Hidden information and per-player views are likewise the game's job: the frontend decides what to show whom from the shared state.

Where the AI sits

The AI characters live inside the backend. While handling an event, game code talks to its agents — LLM-backed characters, each with its own persistent conversation memory — and can request images; the characters' replies stream into the turn as they generate (images resolve in the background), and everything is recorded with the turn. The AI is never in the frontend, and never in a tick.

What works well — and what doesn't

The platform is built for AI-driven, turn-based experiences. Some game types are a poor fit:

  • Real-time action (platformers, shooters, racing) — no frame-rate rendering; the UI is React, not a game canvas
  • Twitch/reflex gameplay — the fastest tick is ~1s and every event makes a network round-trip
  • Physics simulations — no physics engine; you can model simple state (like a hunger/stamina system) but not collision detection or rigid bodies
  • Large persistent worlds — each session is independent; there's no cross-session persistence or shared world state
  • Purely visual/spatial games — the platform shines when AI narration adds value; if the game is entirely spatial with no text, an AI agent has nothing to contribute

The sweet spot is games where AI narration, conversation, and decision-making are core to the experience — RPGs, visual novels, social sims, board games, puzzles with dialogue.

Where to look next