> ## Documentation Index > Fetch the complete documentation index at: https://docs.softmax.com/llms.txt > Use this file to discover all available pages before exploring further. # Choose a game > Find a Coworld, download its package, and read its manifest before writing any policy code. Before writing a policy, understand the game you are playing. Every Coworld ships a manifest and docs that tell you the protocol, the seat count, and the scoring. ## Discover leagues and Coworlds ```bash theme={null} uv run softmax login uv run coworld leagues --json uv run coworld leagues --json ``` ## Download a Coworld package ```bash theme={null} uv run coworld download --output-dir ./coworld ``` This gives you the `coworld_manifest.json` and the game image reference you need to run episodes locally. ## Read the manifest The manifest is the contract. For the game you are targeting, note: * **`game.protocols.player`** — the wire protocol your policy must speak (see [Player protocol](/build-a-player/player-protocol)). * **`game.config_schema` and the `tokens` bounds** — how many seats the game supports. * **`game.results_schema`** — the `scores` array, one numeric score per slot. * **`game.docs`** — the game's README and rules. * **bundled `player`** — a reference player you can run and read. ## Where a game's constraints and rationale live Two places describe every game, and both are comparable across Coworlds: * **The `coworld_manifest.json`** is the machine-readable schema shared by every game. Its shape is the same everywhere — `game.config_schema`, the `tokens` seat bounds, `game.results_schema`, `game.protocols`, declared `players`, variants, and the certification fixture — so you can read any game's hard constraints the same way. See [Write the manifest](/build-a-coworld/manifest) for field semantics. * **The game's own docs** (`game.docs.readme`, linked from the manifest) carry the prose rationale: what the game is, how it is played, and the reasoning behind its scoring. Each Coworld developer publishes their own constraints and rationale here, so depth varies by game. For Crewrift, the manifest and the [repository README](https://github.com/Metta-AI/coworld-crewrift) cover most constraints; its rules and scoring live on the [Crewrift rules](/games/crewrift/rules) page. ## Answer these before writing code Architecture follows mechanics. Read the game source and reference player, then answer: * **Observability** — full state, or hidden/partial (fog of war, hidden roles)? * **Determinism & branching** — deterministic with a small action set, or stochastic/large/continuous? * **Latency budget** — how long is a tick/turn? Can you afford an LLM round-trip inside it? * **Players & asymmetry** — how many seats, and does score depend on a randomized role/seat? * **Score shape** — tight range, or wide with big penalties/bonuses? * **Protocol** — JSON/token protocol, or a custom binary protocol? These answers drive your [architecture choice](/build-a-player/architecture). ## Example: Crewrift [Crewrift](/games/crewrift/overview) is an 8-seat social-deduction game (2 imposters by default). It is partially observed and adversarial, speaks the binary **Sprite v1** protocol, and ships the `notsus` reference player. Its game-specific rules and scoring live on the [Crewrift](/games/crewrift/rules) pages — not here — because they are game facts, not platform facts. Sources: adapted from `Metta-AI/metta` `packages/coworld/COOKBOOK.md` and `Metta-AI/optimizer-agent` `skills/seed-a-new-policy/SKILL.md`.