Install

Spawnite installs from npm into a folder of its own: one command writes a game, and the install command it prints brings the engine, the command line tool spawnite and their dependencies into it. Each step below is a command or two in a terminal, so your agent can run them for you. The agent checklist is the same setup as steps an agent follows on its own.

What you need

Check that you have the following:

Node 24.2 or later. Run node --version to see yours, and install it from nodejs.org if it is older.
A package manager: npm, which comes with Node, or pnpm, yarn or bun. create spells each command it prints for the package manager a nearby project declares, or, where none does, for the one that ran it, such as npm install after npx.
git, if you want your game folder to start as a repository. Without it, create writes the game and says that nothing backs it up.

Create a game

Take the following steps in the folder where you keep your projects:

Create a game from the example template, and install its packages:
Terminal window
```
npx @spawnite/cli create my-game --template example
cd my-game
npm install
```
npx @spawnite/cli list names the other templates: games that play in a room with friends, games that play alone, and the parts spawnite add writes. --room makes the game play in a local room, which friends can join. A game created without it plays alone, and the game-builder skill does not add a room later: Make your game says how to add one by hand. It works on the templates that can play either alone or in a room, and list names them. --theme slate gives the game’s UI the slate look in place of the default glass.
Run the game with npm run dev, which prints the address to open in your browser. A game made with --room plays in its local room, so start it with npx spawnite play start instead, and open the address it prints. The first spawnite play command on a machine downloads the Chromium the playtest tools run the game in, once for every game.
Give your agent the plugin and its MCP server: npx @spawnite/cli plugin install connects whichever of Claude Code and Codex is on your PATH, and each loads them in its next session, or Claude Code when you type /reload-plugins. By hand, in Claude Code, run claude plugin marketplace add spawnite/plugin, then claude plugin install spawnite@spawnite. In Codex, run codex mcp add spawnite -- npx -y @spawnite/mcp, and add tool_timeout_sec = 600 under [mcp_servers.spawnite] in ~/.codex/config.toml. Codex reads the plugin’s skills from my-game/.agents/skills/, which create wrote, and Claude Code from my-game/.claude/skills/, which links to them. Connect your agent says what the plugin gives your agent and how to check that it answers.

When the game is ready for players, Publishing takes it from sign-in to a link.

create also writes the game’s AGENTS.md, which tells an agent how to work in the game, and a CLAUDE.md that points Claude Code at it. Each install of the game’s packages fills AGENTS.md with an index of the installed engine’s guide pages.

Run the spawnite command

create installs the command line tool into the game as the @spawnite/cli dev dependency. In the game’s folder, spawnite runs it:

spawnite --help

--help lists every command, and spawnite <command> --help its options. Most commands take --json for output a script or an agent reads.

Install the packages from npm

A game installs @spawnite/engine and the other packages from npm, with no token and no .npmrc. A project that the CLI’s create command writes installs them as it is.

To add the engine to a project you already have, install the engine and its peers:

pnpm add @spawnite/engine @spawnite/schema @spawnite/ui react react-dom @react-three/fiber @react-three/drei @react-three/postprocessing postprocessing @pixiv/three-vrm three three.quarks koota zustand

The engine’s peers are React and React DOM, React Three Fiber, drei, React Three Postprocessing and postprocessing, @spawnite/ui, @spawnite/schema, three-vrm, three, three.quarks, koota and zustand. Your game imports them too. A second copy of React, React Three Fiber, drei, koota or zustand would hold its own context, and a second copy of @spawnite/ui or three-vrm would be a second download. A published game’s page loads all of them from the engine’s release, as Publishing says.

The engine pins the exact version of each peer, apart from React and React DOM, which take any 19.x, and @spawnite/ui and @spawnite/schema, which take a caret range from the engine’s own release. pnpm warns about a peer that is missing or at another version. npm view @spawnite/engine peerDependencies prints each peer and its version. One copy of @spawnite/schema is shared by the engine, the UI and the devtools. vite and vitest are optional peers, for the engine’s Vite plugin and its test fixtures. The engine brings everything else it needs, including Rapier and Recast.

The shared models, avatars, animation clips, textures and sounds load from https://assets.spawnite.com, the engine’s own among them: its default clips, its ground textures and the models it scatters. A game in its own folder needs that host reachable the first time pnpm dev or spawnite play loads each file, and in a test that loads a file, so allow it in a sandbox that lists the hosts an agent may reach. A game names a shared file through @spawnite/assets, which a template that uses one already lists: pnpm add @spawnite/assets adds it to another game.

A dev server keeps each shared file it loads in one cache on your disk, shared by every game you run, so a game loads offline in development once it has run online. A production build, a test run, spawnite play profile and a boot smoke still load each file from the site, as the end of this section says. pnpm dev and spawnite play fill the cache on the first load of each file and read it after that; the first run of a file needs the network.

The cache lives in the following folder:

System	Folder
Windows	`spawnite/Cache/assets` under `%LOCALAPPDATA%`
macOS	`~/Library/Caches/spawnite/assets`
Linux	`~/.cache/spawnite/assets`, or `spawnite/assets` under `$XDG_CACHE_HOME`

To move it, set SPAWNITE_CACHE_DIR to an absolute path: the files go in its assets folder. The folder is a cacache store, the one npm keeps its own cache in, not a folder of named files: the store checks each file against its SHA-256 when it reads it. Delete the folder whenever you like; the next online run fills it again, and macOS may clear it on its own when the disk runs low.

Behind a proxy, start the dev server with NODE_USE_ENV_PROXY=1, because Node’s fetch ignores HTTPS_PROXY without it. A production build, a test run, spawnite play profile and a boot smoke still load each file from https://assets.spawnite.com.

The license

The packages are free to use under the Spawnite License 1.0, whose full text is LICENSE.md in each package. You own your game’s code, art and earnings share, you build and test on your own machine as much as you like, and a game is published through the platform. License says what the terms allow in plain words.

Import entries

A game imports from the following entries of @spawnite/engine. A name that no entry exports is not part of the engine’s API, and a later release may change or remove it.

@spawnite/engine: the components, hooks, traits and functions a game is built from.
@spawnite/engine/core: the simulation alone, with no React, for a script or a test that draws nothing.
@spawnite/engine/abilities, /weapons, /npcs, /inventory, /dragAndDrop, /tracks and /rounds: each plugin a game switches on, with its traits, components and hooks. The root exports the same names for every plugin but /rounds, which ships as readable source under readable/rounds/ and exports its names from its own entry alone.
@spawnite/engine/player-text: playerText() and what reads a player’s words, filterText and the comparisons, as Text players write says. Neither the root nor the core exports them, so a game that declares no playerText() field loads none of the text filter.
@spawnite/engine/devtools: what a game’s own devtools panel draws with.
@spawnite/engine/vite: the plugin a game’s vite.config loads.
@spawnite/engine/testing: the Vitest fixtures.
@spawnite/engine/replay: a recorded session’s records and a room’s actions, for a script of your own.
@spawnite/engine/three: three.js, for a game that reaches under the engine.
@spawnite/engine/looks/<name>: each named look.
@spawnite/engine/eslint: the lint rules.

Each entry’s declarations are one file beside its script. A readable plugin’s declarations are one per source file, beside each of its scripts.