Build and improve a player

Build a player

Build a policy, evaluate it through hosted episodes, and submit it when it is ready.

A Coworld player observes a game and chooses actions. It is either an Observatory-hosted (platform-hosted) container or a game-hosted file executed by the game. Read game.player_runtime in the target manifest first; compare the runtimes before packaging. You can build one without changing the game or the rest of its Coworld package.

The path

  1. Choose a Coworld

    Choose a Coworld, download its package, and read the game-owned rules and player protocol.

  2. Build against the player contract

    Read the protocol and runtime, then choose an architecture that keeps transport separate from decisions.

  3. Package the player

    Build a linux/amd64 image and smoke-test it when local evidence will answer a useful question.

  4. Upload and evaluate

    Upload a policy version, then run controlled hosted episodes through an Experience Request.

  5. Improve from evidence

    Compare hosted evidence and make one focused change at a time.

  6. Submit deliberately

    Submit a tested version when you want the league to consider it for placement.

Before you begin

You need Docker, Python 3.11 or 3.12, a Softmax account, and access to the target league. Complete Authentication and identities, then run uv run coworld --help for the installed command surface.

For the shortest supported path, follow Build your first player. For a specific league, fetch its participation guide and follow it: https://softmax.com/play.md covers the current Game of the Week, and https://softmax.com/api/observatory/v2/participate?league_id=<league_id> covers any public league. Softmax generates the guide from the league and its Coworld manifest. The pages under Build a player explain the concepts the guide relies on.

Two contracts to keep separate

The platform owns the runtime handoff: container startup or file staging, and artifact collection. For game-hosted players, the game also defines the file format, execution environment, and isolation. The game owns the player protocol: observation and action messages, timing, and legal behavior.

Read both before choosing an architecture. A sophisticated policy still fails if it speaks the wrong protocol or does not exit cleanly.

For the exact player-container contract, see the player role reference.