TikBox
Four games driven by a TikTok Live stream. Chat messages, likes and gifts are the inputs, the viewers are the players, and the whole thing renders into the 9:16 frame the stream actually captures.
- Role
- Solo — architecture, game engine, interface, content
- Period
- 2025 — 2026
- Type
- Lab
- Status
- shipped
- 3,610
- Words with definitions
- 1,200
- Trivia questions
- 27
- Letters per rosco
- 13.6k
- Lines of TypeScript
Showcase
Overview
A live stream is already thousands of people sending input every second — it is just usually treated as chat. TikBox turns that into a controller: comments, likes and gifts are the inputs, viewers are registered as players the moment they type, and the game renders into a 9:16 frame captured straight into TikTok LIVE Studio. Nobody installs anything or leaves TikTok.
Built for my own streams and finished: four games, a word bank written for the format rather than scraped into it, and a simulated event source so the whole thing can be developed at three in the morning with no audience.
The aspect ratio is the constraint that shapes everything else. Nine by sixteen is not a preview size here, it is the canvas — what fits on screen is decided before a component gets written.
The demo runs the real client with the event generator moved into the browser, so the four games play out against a simulated audience with no server behind them. Open it and the chat, gifts and likes are being produced in your own tab.
Architecture
From chat message to screen
Scroll to pan
Screens
Stream connection — the handle is validated before any game runs 
Lobby — four games, live player counts per game 
Chat stream — every event typed and filterable 
Race — viewers auto-join the grid, then the countdown starts 
Race complete — winner overlay, then the next race 
Per-game settings — the streamer tunes the rules live 
Trivia — question on the clock, answers arrive as chat 
Reveal — scoring resolved, top three updated 
Pasapalabra — the rosco tracks 27 letters in real time 
Mock control — the whole stream simulated, rate by rate
Modules
Stream as input
TikTok Live events — chat, gifts, likes, follows, viewer count — translated into typed game events before anything else sees them, so a change in the underlying library never reaches a game.
Four surfaces, one shell
Chat, Race, Trivia and Pasapalabra share the same shell: connection state, player registry, config dialog, winner and timeout overlays. A new game is the rules, not the plumbing.
- Pasapalabra — the 27-letter rosco, themed generation, three scoring modes
- Trivia — multiple choice on the clock, points for speed and streaks
- Race — every message, like and gift pushes a car toward the line
- Chat — the stream on screen, filterable by event type
State split three ways
Every game store is divided into state, actions and timers. Timers are the part that rots first in a real-time game, so they live in their own file and the rest of the store stays readable.
Settings declared as data
Each game describes its options as an array of typed fields with ranges and validation, and the settings dialog draws itself from that. Adding a setting is adding an object, not editing a form.
The simulated stream
A generator that produces chat, gifts, likes, shares and follows at configurable rates and probabilities, controllable over HTTP while the app runs — including a pause, which turns out to be the most used debugging tool in the project.
Engineering
A word game is only as good as its dictionary
Pasapalabra needed 3,610 Spanish words, one set per letter including the Ñ, and a flat list would have been useless. Every entry carries its own definition, difficulty, topics, length and — the detail that actually changes the game — a list of alternative answers. Without those, half the room types something perfectly reasonable and the game tells them they are wrong.
Developing a chat game with no chat
A game whose only input is a live audience cannot be built in front of a live audience. The mock service generates every TikTok event type at tunable intervals and probabilities over a pool of fake viewers, and exposes them over HTTP so a specific gift or message can be fired by hand. Freezing the stream mid-round to inspect a state that would otherwise keep moving is what makes the games debuggable at all.
Timers are where real-time games rot
Countdowns, per-question limits and automatic round transitions all run against events that arrive whenever they want. Isolating them in their own module per game — separate from state and from actions — is what keeps the rest of each store something you can read without holding a clock in your head.
A question that never finished typing
The typewriter effect rescheduled a timeout per character, so with live events arriving the timeout was cleared and re-armed faster than it could fire: roughly 500ms per character against the 30ms configured, which meant a 40-character question needed 20 seconds and the round moved on before it was readable. One interval with the index held outside React state brought it back to 28ms. It only appears under event load, which is exactly why it survived so long.
Stack
- 01Next.js 15
- 02React 19
- 03TypeScript
- 04Zustand
- 05Framer Motion
- 06Node.js
- 07Express
- 08WebSockets
- 09TikTok Live
- 10Docker