Introduction
EigenInteractive is an open-source, server-authoritative engine for turn-based multiplayer games. Your game ships as a single Cloudflare Worker that owns its own domain, database and players, plus a Flutter app for Android and the web that is almost entirely the engine's. You supply the rules.
The rules run on the server, so a client's move is always a proposal the server validates — hidden information never leaves the server except as a per-seat projection, clocks are authoritative, and finished games are replayable from an immutable log.
What you actually write
A game is two same-keyed registries: TypeScript rules that decide, and Dart rules and a screen that draw. That is the whole surface.
| You write | The engine owns |
|---|---|
| The rules — six hooks, on the server | Persistence, sockets, reconnection, timing, ratings, history, replay |
| Client-side legality, optimism, and the board, in Dart | Sign-in, home, lobby, friends, profile, settings, push, deep links |
| A creation dialog's declaration | The dialog, the countdown, the finished banner, the whole app shell |
For scale: Rock–Paper–Scissors, the reference game, is about 220 lines of TypeScript and 500 of Dart — and none of it mentions turns, deadlines, sockets, versions, persistence or ratings.
Start here
| If you want to… | Go to |
|---|---|
| Run both halves in the next five minutes | Quickstart |
| Add EigenInteractive to existing or separate repositories | Manual setup |
| See a whole game, both languages | Your first game |
| Write your own game | Build a game |
| Get it in front of players | Ship it |
| Understand why it is built this way | How it works |
| Look something up | Reference |
How these docs are organised
Task-first, and each page carries both halves. A page is a thing you are trying to do — model your payloads, render the board, handle hidden information, ship to a store — and it covers the server and the client side of that task together, because they are one change.
- Getting started — run it, then read it.
- Build a game — the contract, and each task within it, from payload types through to changing a game that has already shipped.
- Ship it — deploying the Worker, configuring both halves, deep links, branding, push, and the store.
- How it works — the engine itself: the kernel, Durable Objects, storage, identity, security, the failure model, the client transport and the app shell. Explanation only; you can build a game without reading any of it.
- Reference — the HTTP API (generated from
openapi.json), the TypeScript API (generated from source), the Envelope contract and the error model.
Every page is also served as plain Markdown — append .md to any doc URL. There
is an /llms.txt index and an
/llms-full.txt single-file bundle, and the HTTP
contract is available as a raw spec at
/openapi.json.
There is also a Claude Code skill that carries this contract — see Working with an agent.