How a game runs on llvls

The runtime boundary

Your project contains a root llvls.json and an entry module such as src/main.ts. The platform validates the project, resolves supported libraries and produces a content-addressed build. The game runs in an isolated frame; the surrounding host owns player accounts, saves, scores, sharing and platform overlays.

1. Edit your game files and llvls.json in the Studio.
2. Run the project to validate and bundle it.
3. Play the result in the game frame.
4. Use the SDK to request saves, scores and other services from the surrounding host.

Use import llvls from '@llvls/sdk'. This is the same object exposed as the llvls global. Calling platform APIs through the SDK preserves the frame boundary. Do not call account or platform HTTP endpoints from game code.

Development sequence

1. Start with a Studio template or the complete example in the quickstart.
2. Declare the engine, entry, controls and platform features in the manifest.
3. Initialise the SDK and implement lifecycle and host events.
4. Read Code editor diagnostics, choose Run and test in the Studio preview.
5. Publish a release, then inspect its checks and review outcome.

A Studio preview build is not a live release. A manifest version label is not a build identity. Restoring project files does not switch the release players receive.

Find API help

Use the SDK reference and the linked feature guides for method names, arguments and outcomes. The full Studio Code editor also provides SDK type information. Check feature availability before relying on an optional API.