# EigenInteractive

> An open-source, server-authoritative engine for turn-based multiplayer games. A game ships as a single Cloudflare Worker that owns its own domain, database and players, plus a Flutter app for Android and the web. The implementor writes the rules; the engine owns everything else.

This file contains links to documentation sections following the llmstxt.org standard.

## Table of Contents

- [Introduction](https://eigeninteractive.com/docs/intro.md): What the EigenInteractive engine is, what building a game on it actually involves, and how these docs are organised around that.
- [Set up without the scaffolder](https://eigeninteractive.com/docs/getting-started/manual-setup.md): Create the Worker and Flutter halves by hand, in one repository or two, using only the published EigenInteractive packages and game-contract.json.
- [Prerequisites](https://eigeninteractive.com/docs/getting-started/prerequisites.md): The system-level tools an EigenInteractive game needs — Node, a package manager, Flutter, the Android and web toolchains, and the Cloudflare and Fi...
- [Quickstart](https://eigeninteractive.com/docs/getting-started/quickstart.md): Scaffold a game Worker and Flutter app, generate the shared payload contract, and run both halves locally.
- [Your first game](https://eigeninteractive.com/docs/getting-started/your-first-game.md): Rock–Paper–Scissors in both languages — the rules that decide, the screen that draws, and the fixture file that keeps them agreeing.
- [Bots](https://eigeninteractive.com/docs/build-a-game/bots.md): Writing an engine bot brain — a move function that ships inside your game module.
- [The creation UI](https://eigeninteractive.com/docs/build-a-game/creation-ui.md): Declaring valid player counts, timing modes and game-specific options — and why the rated flag is an assertion the server checks rather than a pref...
- [Hidden information](https://eigeninteractive.com/docs/build-a-game/hidden-information.md): Fog is one hook on the server; on the client it is two nullable fields and a decision not to predict. Plus the same-view rule that makes simultaneo...
- [The hooks](https://eigeninteractive.com/docs/build-a-game/hooks.md): The six server hooks, what the engine has already guaranteed before each is called, and what each one produces on the client.
- [Recipes — common game shapes](https://eigeninteractive.com/docs/build-a-game/recipes.md): Sequential, simultaneous, team, elimination and phased games — all expressed through pendingPlayers and computeObservation.
- [Rendering the game](https://eigeninteractive.com/docs/build-a-game/rendering.md): buildContent and everything it receives, the frame model that makes animation sound, and how to hide latency without lying — plus the server-side c...
- [Payload types](https://eigeninteractive.com/docs/build-a-game/schemas.md): Declare state, observation, action, and config once and generate immutable Dart payloads from the game contract.
- [Testing](https://eigeninteractive.com/docs/build-a-game/testing.md): One fixture file, two runners, two repos — plus the widget and integration layers, the CI that runs them, and the coupling CI cannot see.
- [The contract](https://eigeninteractive.com/docs/build-a-game/the-contract.md): A game is two same-keyed registries — a TypeScript one that decides and a Dart one that draws. What you write, member by member, and what the engin...
- [Timing](https://eigeninteractive.com/docs/build-a-game/timing.md): Two server touchpoints and a display-only client — deciding what a timeout costs, widening one action's window, and rendering a clock that cannot d...
- [Changing a shipped game](https://eigeninteractive.com/docs/build-a-game/versions.md): What to do when the rules change after players are using them — a new unit on both sides, why draining and replay retire at different times, and th...
- [Working with an agent](https://eigeninteractive.com/docs/build-a-game/with-an-agent.md): The Claude Code skill for writing EigenInteractive games, the retrieval surface behind these docs, and the mistakes an agent makes on this contract...
- [Branding & the website](https://eigeninteractive.com/docs/ship-it/branding.md): One set of source images becomes the app icon, the splash, the web assets and the game's whole public website — plus the legal documents you must a...
- [Configuration](https://eigeninteractive.com/docs/ship-it/configure.md): Both halves of a deployment's runtime config — the Worker's bindings and secrets, the app's AppConfig, and the Firebase project they share.
- [Deep links](https://eigeninteractive.com/docs/ship-it/deep-links.md): The Worker generates the verification files and the app declares the same host — three places that must agree, and the path prefixes that stop the ...
- [Deploy the web app](https://eigeninteractive.com/docs/ship-it/deploy-the-web-app.md): Build Flutter into the game Worker so the SPA, API, app links, legal pages, and native download page share one canonical origin.
- [Deploy the Worker](https://eigeninteractive.com/docs/ship-it/deploy-the-worker.md): The fifteen lines of glue that turn a GameModule into a Worker, what wrangler.jsonc must declare, running it locally with nothing simulated away, a...
- [Push notifications (FCM)](https://eigeninteractive.com/docs/ship-it/push.md): Native notification channels, FID registration, safe category fallback, and the browser service worker and VAPID path.
- [Store release](https://eigeninteractive.com/docs/ship-it/store-release.md): Android release hardening, the app's CI pipeline and its secrets, and the fastlane lanes that upload a binary and deliberately nothing else.
- [Account lifecycle & the cron](https://eigeninteractive.com/docs/how-it-works/account-lifecycle.md): Why deletion is ordered games → Firebase → D1, and what the daily cron backstops.
- [Bots](https://eigeninteractive.com/docs/how-it-works/bots.md): Three bot types, the seating gates, and the derived-key HMAC that authenticates external bots in both directions.
- [Failure model](https://eigeninteractive.com/docs/how-it-works/failure-model.md): Single attempt, no retry machinery — and why that is safe when everything is either idempotent or self-healing.
- [The game session](https://eigeninteractive.com/docs/how-it-works/game-sessions.md): One Durable Object per game — its SQLite schema, lazy initialization, the command pipeline, and why versions are strictly serial.
- [Identity & the social graph](https://eigeninteractive.com/docs/how-it-works/identity.md): Firebase ID tokens verified in-worker, guest accounts, usernames, and the friends/blocking model.
- [The kernel](https://eigeninteractive.com/docs/how-it-works/kernel.md): The pure decision core — a function from inputs to a commit plan, with no I/O and no platform APIs.
- [The game lifecycle](https://eigeninteractive.com/docs/how-it-works/lifecycle.md): Creation, the waiting room, active play, finish and history compaction, cancel and abort.
- [Push notifications](https://eigeninteractive.com/docs/how-it-works/notifications.md): Best-effort turn and finish pushes via FCM HTTP v1, addressed to Firebase Installation IDs.
- [What the engine is](https://eigeninteractive.com/docs/how-it-works/overview.md): The single principle the whole system is built around, and the three properties that fall out of it.
- [Security model](https://eigeninteractive.com/docs/how-it-works/security.md): Authorization enforced explicitly in application code — token gating, uid-scoped reads, the game-visibility capability model, and seat ownership.
- [Data & storage](https://eigeninteractive.com/docs/how-it-works/storage.md): Two stores with two jobs, the D1 schema, the concurrency-safe rating CAS, and how history and replay work.
- [Shape of the system](https://eigeninteractive.com/docs/how-it-works/system-shape.md): Four packages split by trust and purity, one Worker with three request spaces, and the path a single move takes through them.
- [The app shell](https://eigeninteractive.com/docs/how-it-works/the-client-app.md): Package layout, startup order, local persistence, offline UX, navigation, analytics, guests and haptics — all infra-owned.
- [Timing & the deadline alarm](https://eigeninteractive.com/docs/how-it-works/timing.md): Three timing modes, the deadline precedence chain, and why one grace constant replaces a timeout-sweep cron.
- [The client transport](https://eigeninteractive.com/docs/how-it-works/transport.md): Auth, the generated API client, the error model, how seat identity is resolved before render, and how one WebSocket per game reconciles without eve...
- [Versions and compatibility](https://eigeninteractive.com/docs/reference/compatibility.md): Which engine, client and docs versions pair with each other, what the scaffolder picks for a new project, what a breaking bump actually means pre-1...
- [The cross-repo contract](https://eigeninteractive.com/docs/reference/cross-repo.md): Engine packages are dependencies; a deterministic game contract carries payload schemas and fixtures between a game's Worker and Flutter repositories.
- [Dart API](https://eigeninteractive.com/docs/reference/dart.md): The hosted, versioned API reference for eigen_flutter and its testing library.
- [The Envelope, determinism & errors](https://eigeninteractive.com/docs/reference/envelope.md): The return shape of every hook, the RNG contract, and what to throw.
- [The HTTP surface at a glance](https://eigeninteractive.com/docs/reference/http-surface.md): Every route grouped by the three request spaces, plus the error model and its stable codes.
- [Project layout](https://eigeninteractive.com/docs/reference/repository-model.md): What a game repository owns, which generated files cross the Worker/app boundary, and when to use one repository or two.
- [TypeScript API](https://eigeninteractive.com/docs/reference/typescript.md): This reference is generated from the published package barrels. Start with the
- [@eigeninteractive/kernel](https://eigeninteractive.com/docs/reference/typescript/kernel.md): `@eigeninteractive/kernel` — the pure decision core. Given the current row, a state
- [@eigeninteractive/rules](https://eigeninteractive.com/docs/reference/typescript/rules.md): `@eigeninteractive/rules` — the contract a game implements. A `GameModule` bundles one
- [@eigeninteractive/server/testing](https://eigeninteractive.com/docs/reference/typescript/server-testing.md): `@eigeninteractive/server/testing` — the test-auth recipe, for the engine's own
- [@eigeninteractive/server](https://eigeninteractive.com/docs/reference/typescript/server.md): `@eigeninteractive/server` — everything that deploys: the
- [@eigeninteractive/testkit](https://eigeninteractive.com/docs/reference/typescript/testkit.md): `@eigeninteractive/testkit` — drive a game's rules through the real kernel without a