The mental model: referee, devices, onlookers

You'll learn: who runs your code, who sees what, and the one rule that follows from it. You'll need this when: you write anything that moves, shows or decides something.

Three roles

Inside, players get the full scene at the plot's tick, plus their UI and channels. Near onlookers already have a lobby chosen for them and get the scene at 10 Hz; far ones, the featured lobby at 2 Hz. Nobody outside runs plot code. (The base is Inventery's own map tiles, dimmed; the plot is a player's monument plot in the Wild, and the Spawn's square beside it is protected land, not a plot.)

The same thing as a flow:

Role	Runs your code?	Sees
The room (server)	yes: the authoritative run, in a wasm sandbox	everything
A player inside your plot	only if your package has client exports: the same module in a Worker, to predict and present (In progress: in the plots dev page; otherwise the engine predicts the standard controllers)	the scene for their lobby, plus their own UI
An onlooker (outside, walking past, on the map)	never	the scene's public parts, at lower rates and detail

The rule that follows

If others should see it, it's in the scene. Onlookers render only the replicated scene. So:

• A thrown fireball's trail: an entity with an Emitter in the scene. Everyone sees it.
• A screen shake for the player who got hit: local, in their own client code (In progress) or a UI effect. Only they see it, which is right.
• A secret role card: UI to one player, or an entity with a visibility set of { players: [id] }.
• A message on a custom channel: game logic only. Onlookers never receive channels, so anything visual sent there is invisible from outside. (The lint flags it.)

The server is the referee

The room decides everything that matters: hits, deaths, scores, who has what. Inside your plot it also runs the base game's own rules (breaking and placing, beds and doors, PvP, drops and pickup, hunger) on the player's lobby, and your hooks filter them (Runtimes and mods), so a Minecraft-style plot starts with Minecraft. Devices predict so that play feels instant, and the room corrects them. That's why a shooter checks hits on the server with lag compensation, and why nothing a device says is trusted on its own.

Your code keeps its own shape

The host API is a thin boundary: about a dozen modules of plain calls with plain data (scene, world, players, ui, storage...). Your game keeps its own loop, object model, ECS or physics. Talk to us at the edges, the way a game talks to a renderer and a network library. Convenience libraries (@inventery/minecraft, @inventery/lobby) sit on top, and you can skip them.

Only six things are enforced, and the rest of these concept pages explain them one at a time:

1. the replicated scene (this page);
2. lobby scoping;
3. visibility sets;
4. the trusted layer and the reserved controls;
5. budgets;
6. entry protection, stashed items and kept items.

Contexts: plot level and lobby level

Every call runs in a context:

• Lobby context: a lobby hook (onPlayerEnter, tickLobby, onBlockBreak...). Calls act on that lobby.
• Plot level: top-level code, init, chooseLobby, tickPlot, tickAllLobbies, onUpgrade. No current lobby; reach one with lobbies.runWithin(id, fn) (runtime only), or lobbies.switchTo(id) in tickAllLobbies.

A call in the wrong context is refused with HostError rule wrongContext, and the lint catches most of these before you run anything.

Memory isn't saved; the host keeps the rest

Your sandbox can be restarted at any time (a crash, a suspend when nobody's near, an update). The host keeps the scene, block edits, storage and timers. Your code runs init again, then each lobby's onLobbyLoad, and rebuilds what it needs from storage. Keep anything that matters in storage, not in variables.

Next

Runtimes and mods: who owns what in a plot.