@volter/cyclotron 0.5.212 → 0.5.213

package/dist-node/create.js

@@ -13937,7 +13937,7 @@ var package_default = {
   name: "@volter/cyclotron",
   publisher: "volter",
   author: "Volter AI, Inc.",
-  version: "0.5.212",
+  version: "0.5.213",
   publishConfig: {
     access: "public"
   },
@@ -14005,31 +14005,31 @@ var package_default = {
         adapterRequired: true,
         workbench: {
           "darwin-arm64": {
-            release: "cyclotron-4a7cd45e4186-78f596095cf0-darwin-arm64",
-            tarballSha256: "f32ac81bcc072d7b84591affdead5dbb62621eb7480b8b89acece5d274e63624"
+            release: "cyclotron-624490512f0c-0ba7394f05b2-darwin-arm64",
+            tarballSha256: "4b752c3abd5595e2e4f7ae4d750b78d2f3c1a0da98140a8ee04c89893689a836"
           },
           "linux-x64": {
-            release: "cyclotron-4782d9a281ef-5b6840f8c154-linux-x64",
-            tarballSha256: "5fe9b6965453ad47a140f6ca939fbbc56a5b7ab9b2aec4b125d7d31f5adea5f9"
+            release: "cyclotron-624490512f0c-0ba7394f05b2-linux-x64",
+            tarballSha256: "6028c6d71df09bbb67ee90b936fc80fdc429d5ef0b1c78db07a6c39d9a4b2e1c"
           },
           "win32-x64": {
-            release: "cyclotron-4782d9a281ef-5b6840f8c154-win32-x64",
-            tarballSha256: "c623156000dff25c6dbb4d88992b4a3d4d5a7aeb42a1882f1b9e20c8f496df04"
+            release: "cyclotron-624490512f0c-0ba7394f05b2-win32-x64",
+            tarballSha256: "57e8fa6dbc439de5fba7da35fa17c710644d465842bd967c8ba7f1e73fcbee2f"
           }
         }
       }
     }
   },
   dependencies: {
-    "@volter/editor-core": "0.5.212",
-    "@volter/editor-blender": "0.1.151",
-    "@volter/editor-threejs": "0.5.212",
-    "@volter/chat": "0.5.212",
-    "@volter/blender-engine": "0.1.149",
-    "@volter/project": "0.5.212",
-    "@volter/sdk": "0.5.212",
-    "@volter/live": "0.5.212",
-    "@volter/play": "0.5.212",
+    "@volter/editor-core": "0.5.213",
+    "@volter/editor-blender": "0.1.152",
+    "@volter/editor-threejs": "0.5.213",
+    "@volter/chat": "0.5.213",
+    "@volter/blender-engine": "0.1.150",
+    "@volter/project": "0.5.213",
+    "@volter/sdk": "0.5.213",
+    "@volter/live": "0.5.213",
+    "@volter/play": "0.5.213",
     three: "^0.186.1",
     "@modelcontextprotocol/sdk": "1.32.1",
     typescript: "5.9.3",
@@ -14126,8 +14126,8 @@ var EXAMPLES = {
     dependencies: { i18next: "~26.7.2" },
     /** The goal the game's `play` scripts name in place of the starter's. */
     goal: "win",
-    /** std's starter files the example has no use for: its ground level, its walking characters and its chat. */
-    removes: ["levels/GroundLevel.tsx", "client/characters.tsx", "client/chat.tsx"]
+    /** std's starter files the example has no use for: its main level, its walking characters and its chat. */
+    removes: ["levels/MainLevel.tsx", "client/characters.tsx", "client/chat.tsx"]
   }
 };
 var isExample = (id) => Object.hasOwn(EXAMPLES, id);
@@ -14369,9 +14369,6 @@ export {
   PLAY_PACKAGES,
   UPGRADING,
   declaration,
-  productRoot2 as productRoot,
-  productVersions,
   refreshStarterGuidance,
-  writeGame,
   writeProject
 };

package/package.json

@@ -2,7 +2,7 @@
   "name": "@volter/cyclotron",
   "publisher": "volter",
   "author": "Volter AI, Inc.",
-  "version": "0.5.212",
+  "version": "0.5.213",
   "publishConfig": {
     "access": "public"
   },
@@ -70,31 +70,31 @@
         "adapterRequired": true,
         "workbench": {
           "darwin-arm64": {
-            "release": "cyclotron-4a7cd45e4186-78f596095cf0-darwin-arm64",
-            "tarballSha256": "f32ac81bcc072d7b84591affdead5dbb62621eb7480b8b89acece5d274e63624"
+            "release": "cyclotron-624490512f0c-0ba7394f05b2-darwin-arm64",
+            "tarballSha256": "4b752c3abd5595e2e4f7ae4d750b78d2f3c1a0da98140a8ee04c89893689a836"
           },
           "linux-x64": {
-            "release": "cyclotron-4782d9a281ef-5b6840f8c154-linux-x64",
-            "tarballSha256": "5fe9b6965453ad47a140f6ca939fbbc56a5b7ab9b2aec4b125d7d31f5adea5f9"
+            "release": "cyclotron-624490512f0c-0ba7394f05b2-linux-x64",
+            "tarballSha256": "6028c6d71df09bbb67ee90b936fc80fdc429d5ef0b1c78db07a6c39d9a4b2e1c"
           },
           "win32-x64": {
-            "release": "cyclotron-4782d9a281ef-5b6840f8c154-win32-x64",
-            "tarballSha256": "c623156000dff25c6dbb4d88992b4a3d4d5a7aeb42a1882f1b9e20c8f496df04"
+            "release": "cyclotron-624490512f0c-0ba7394f05b2-win32-x64",
+            "tarballSha256": "57e8fa6dbc439de5fba7da35fa17c710644d465842bd967c8ba7f1e73fcbee2f"
           }
         }
       }
     }
   },
   "dependencies": {
-    "@volter/editor-core": "0.5.212",
-    "@volter/editor-blender": "0.1.151",
-    "@volter/editor-threejs": "0.5.212",
-    "@volter/chat": "0.5.212",
-    "@volter/blender-engine": "0.1.149",
-    "@volter/project": "0.5.212",
-    "@volter/sdk": "0.5.212",
-    "@volter/live": "0.5.212",
-    "@volter/play": "0.5.212",
+    "@volter/editor-core": "0.5.213",
+    "@volter/editor-blender": "0.1.152",
+    "@volter/editor-threejs": "0.5.213",
+    "@volter/chat": "0.5.213",
+    "@volter/blender-engine": "0.1.150",
+    "@volter/project": "0.5.213",
+    "@volter/sdk": "0.5.213",
+    "@volter/live": "0.5.213",
+    "@volter/play": "0.5.213",
     "three": "^0.186.1",
     "@modelcontextprotocol/sdk": "1.32.1",
     "typescript": "5.9.3",

package/src/index.ts

@@ -1,9 +1,8 @@
-import packages, { productId } from 'volter:composition';
+import { productId } from 'volter:product-id';
 import { product } from '@volter/editor-core/frame';
 
 export const { mountVolter } = product({
   id: productId,
-  packages,
   workspace: 'model',
   logo: 'https://brand.volter.ai/logo/volter-cyclotron/svg',
 });

package/src/product-id.d.ts

@@ -0,0 +1,4 @@
+declare module 'volter:product-id' {
+  /** The product's id: its package name's last segment (`@volter/cyclotron` → `cyclotron`). */
+  export const productId: string;
+}

package/starter/AGENTS.md

@@ -43,7 +43,7 @@ but keep it short between visible steps. Throughout:
   Blender Text data-block named `Build Notes` with a fake user, and keep a
   readable copy beside the work as Text objects in a `Notes` collection (a
   text buffer alone is not visible in the viewport). Include the current step,
-  pending steps, and verified completed steps with their times; update both at
+  pending steps, and verified completed steps; update both at
   real milestones and preserve them across rebuilds and reopening. Keep notes
   out of the intended shot, renders, exports and gameplay: disable the `Notes`
   collection in renders (`collection.hide_render = True`), which keeps them on
@@ -71,26 +71,17 @@ Replace unused scaffold placeholders as the requested result calls for.
   and the intended viewpoints; add cameras when the requested shot needs them.
   A game-like reference can describe a static scene. Implement playable behavior
   when the user asks for a working game or interactive mechanics.
-- **A level and its pieces:** the level's `.blend` is the environment
-  (terrain, mountains, rocks, scatter). Each piece with its own identity, such
-  as a character, creature, vehicle, building or key prop, is its own `.blend`
-  with one collection and object names of its own (named for the piece),
-  linked into the level rather than copied, as in a Blender production. Make
-  a piece's file as Blender does, in one script:
-  `bpy.ops.wm.read_homefile(use_empty=True)`, build it, then
-  `bpy.ops.wm.save_as_mainfile(filepath=<piece file>)`: `src/models/<piece>.blend`
-  in a models project, `prefabs/<name>/<name>.blend` in a std game, whose
-  level is `levels/<level>.blend` and whose export writes each piece's
-  component (`02a-levels.md`, "Prefabs").
-  It opens as its own document; open the level again to link it. Link
-  its collection (`bpy.data.libraries.load(path, link=True, relative=True)`:
-  relative, so the link still resolves when the project moves) and place it as
-  a collection instance. A piece that animates or that the level changes is
-  then made a library override (`bpy.ops.object.make_override_library()` with
-  the instance active), and actions and NLA tracks can still be added to it in
-  the level. Each placement is its own override; rename it as the game
-  expects. Edits to the piece's own file reach every level that links it the
-  next time the level opens.
+- **A game's level and its models:** in a std game, models are made in
+  Blender, each its own prefab (`prefabs/<name>/<name>.blend`, which std's
+  export turns into its component), and the level lays them out in code
+  (`levels/<Name>Level.tsx`), blocked out there before its models are made.
+- **A scene or film's set and its pieces:** outside a game, the set's `.blend`
+  is the environment, and each piece with its own identity is its own `.blend`
+  (`src/models/<piece>.blend`) linked in rather than copied: link its
+  collection (`bpy.data.libraries.load(path, link=True, relative=True)`) and
+  place it as a collection instance, made a library override
+  (`bpy.ops.object.make_override_library()`) where it animates. Edits to the
+  piece's own file reach every set that links it the next time it opens.
 - **A character or an animation:** see Characters and Animation below; check
   motion in the Timeline at representative and extreme poses.
 - **An interactive model:** implement the requested interaction, preview it in
@@ -98,8 +89,6 @@ Replace unused scaffold placeholders as the requested result calls for.
 - **A working game:** follow Working games below, including Play, the game's bot
   goals and a few discrete manual checks. Match the mechanics and success/failure
   behavior to the requested game.
-- **A game's content:** its sounds, music, effects, tuning, items and words
-  are files with ids, as Content is data below says, never built in code.
 - **UI or a HUD:** follow React UI below. A standalone screen needs its own
   visual and interaction checks; UI attached to a game also needs checks in Play.
 - **An edit or repair:** inspect the existing result first and change the
@@ -111,14 +100,15 @@ Replace unused scaffold placeholders as the requested result calls for.
 
 Apply this section to models, scenes and the Blender parts of games.
 
-- `src/models/*.blend` are the saved documents, including full scenes.
+- The `.blend` files are the saved documents (`src/models/`, or a game's
+  `prefabs/` and `levels/`), including full scenes.
   `*.py` beside them record how they were authored. Editing a script alone does
   not update the document.
-- Look in the asset library before authoring an asset from nothing:
-  `GET <editor>/__editor/asset-library/search?source=local&type=model&q=<words>`
-  at the editor's address (the one `cyclotron edit` printed). Results carry
-  `tags` (such as `animated`), a license and attribution; fetch one with `POST <editor>/__editor/asset-library/download`,
-  import it through Blender, and record the asset and its license in the project.
+- Look in the asset library before authoring an asset from nothing. It is part
+  of the editor's automation API (`editor.assetLibrary`), reached with
+  `cyclotron eval`. Results carry `tags` (such as `animated`), a license and
+  attribution. A download lands in the project's `public/asset-library/` with
+  the asset and its license recorded in the project; import it through Blender.
 - Inspect the open scene with `get_scene_info` and `get_object_info` before
   changing it. Rerunning a script that clears the scene replaces existing work;
   update scripts to preserve user edits and the `References` and `Notes`
@@ -134,9 +124,8 @@ Apply this section to models, scenes and the Blender parts of games.
   editing another document, wait and retry, then switch to another document
   and back or run `editor.reloadPage()` in eval; do not build through `eval`
   instead.
-- Orient procedural closed-mesh faces outward and inspect their exterior in
-  Rendered shading (`eval 'return await editor.shading("rendered")'`) before
-  building many copies. Recalculate normals when needed.
+- A closed mesh's faces point outward (normals recalculated where needed),
+  checked shaded before many copies of it are built.
 - Verify object properties and inspect captures after meaningful changes.
   The editor saves the open `.blend` when Code-OSS autosaves it
   (`files.autoSave`), a moment after an edit, and not at all when the project
@@ -198,7 +187,7 @@ Apply this section to models, scenes and the Blender parts of games.
   window minimized or covered; `status()`'s `presence.visibility` says so):
   then a player's page is hidden, and one hidden since it loaded refuses
   `capture --region play`. Never raise the editor's tab or window for it. See
-  the game in the videos std records of the bot's headless plays
+  the game in the videos std records of the bot's plays out of view
   (`build/runs/<run>/video/`, each whole once its play ends), and read its HUD
   with `editor.inspect()`'s `inspection.screen` (its `objects` are empty on a
   page that has drawn no frame).
@@ -206,9 +195,13 @@ Apply this section to models, scenes and the Blender parts of games.
 ## Establish the visual match first
 
 For new visual work, match the requested view before adding behavior. For a new
-game, this first pass is the authored 3D scene and React UI composed as a static
-game screenshot; movement, scoring, opponents and items come afterward. A
-behavior-only repair preserves the established appearance.
+game, this first pass is the level and its models, lit, with the game's things
+in place and the React UI, composed as a static game screenshot: the game's
+first frame in Play. The level's document draws it as the game does
+(captured with `cyclotron capture --region document`)
+while it is laid out. Movement, scoring, opponents and item behavior come
+afterward. A behavior-only repair
+preserves the established appearance.
 
 - Match the reference's aspect ratio, crop, camera angle, perspective and object
   scale, with the real 3D model and React components at comparable resolution;
@@ -241,120 +234,99 @@ behavior-only repair preserves the established appearance.
 
 ## Working games
 
-A game here is a [std](node_modules/@volter-ai/std-dev/docs/00-overview.md) game:
-three.js, React Three Fiber, Rapier and Colyseus, used as their own docs describe
-them, with std adding only what they lack. std's guide ships with the game, in
-`node_modules/@volter-ai/std-dev/docs/`: read `01-write-a-game.md`,
-`02a-levels.md` and `04-bots.md` before writing game code.
-
-- Complete the visual pass before implementing gameplay for a new game.
-- A project with `std.json` is a std game. In a project without one, run
-  `npx --no-install cyclotron add-play`: it runs std's `std new` into the
-  project, moves `src/models/*.blend` into `levels/`, and installs the game's
-  dependencies with pnpm. The editor picks the game up as it is; nothing needs
-  a reload.
-- Where things go:
-  - `levels/<name>.blend` is a level, made in Blender. Each save runs std's
-    level export, which writes the files beside it (`<name>.glb`,
-    `<Name>Level.tsx`, its environment, canvas settings and grading). They are
-    std's: change the `.blend` or the game's code, never them. A Rigid Body
-    panel is a body, an object whose custom property `sensor` is true is a
-    sensor, a collection instance of a collection named `SpawnPoint` is a
-    spawn point, and the custom properties `role` and `aria-label` are what
-    bots read of an object.
-  - `server/index.ts` is the room, std's `StdRoom`, a Colyseus room: the
-    game's rules and state live here. `shared/state.ts` is its state schema.
-  - `client/` is the React Three Fiber app every player runs: `index.tsx`
-    joins the room and draws the level, `hud.tsx` is the HUD.
-  - `autopilot/index.ts` is the game's bot: its goals, each named by a word.
-    `autopilot/checks.ts` judges each goal's recorded play.
-  - `std.json` is the manifest.
-- Rules belong to the room. A client sends what its player does (a message),
-  the room decides (its state), and every client draws the state. std 0.8 has
-  no items, pickups, health or scores of its own: write them with the
-  libraries, a react-three-rapier sensor's `onIntersectionEnter` or a distance
-  check, and a room message the room validates.
-- Make the game's state readable on screen: a HUD element with `role="status"`
-  and an `aria-label` is what the person sees and what bots read.
-- Give the bot a goal for each outcome worth checking: at least `win` and one
-  that loses on purpose (`lose`). A goal records what it sees with
-  `driver.intent(text, facts)`; its check in `autopilot/checks.ts` judges the
-  recording. Run one with `npx --no-install cyclotron play autoplay on <goal>`:
-  std's headless play of that goal, its own bot pages out of view (the player
-  on screen and the Game panel's goal stay as they are). Read how it ended in
-  `npx --no-install cyclotron play` (`autoplay.state`) and
-  `npx --no-install cyclotron play-log [--since <time>] [--kind <kind>]`, and
-  explain what happened from it before changing code. Change no file while it
-  plays: the dev server reloads its pages on a change, which cuts the goal short.
-- Continuous play is the bot's, never yours by hand. Why: your inputs arrive
-  one tool call at a time, seconds apart, so a real-time game driven by hand
-  plays in stop-motion; it can't judge feel or timing, it rarely reaches an
-  ending, and an agent that falls into it can spend hours on one session. Use
-  a few discrete inputs for a manual check (`editor.document.key`, and a HUD
-  button pressed by its role and name,
-  `editor.document.click('role=button[name="Restart"]')`; at most about ten),
-  read the screen with `editor.inspect()` (`inspection.screen`) and the live
-  scene with it too, then hand back to the bot.
-- Play on a level saves it (std exports it) and opens the game's own page for
-  each player. Pause, step and speed (the Game panel, or `play pause`,
-  `play resume`, `play step [count]`, `play speed <x>`) hold every player's
-  page; the room on the dev server keeps running, as Colyseus cannot pause a
-  room, so a timer the room runs goes on while the pages are paused.
-- Say in Chat that the game is playable as soon as it is, then check its
-  endings with the bot's goals. Observe each terminal state, use the actual
-  Restart control and play again, and check that everything resets.
-- Run `pnpm check` (std's own check: TypeScript, lint and the web build)
-  before calling the game done, and show what it says.
+A game here is a [std](node_modules/@volter-ai/std-dev/docs/) game:
+three.js, React Three Fiber, Rapier and Colyseus, written as their own docs
+describe them, with std adding only what they lack. std's guide ships with the
+game, in `node_modules/@volter-ai/std-dev/docs/`; its pages "Write a game",
+"Levels" and "Bots" are where to start.
+
+The project's standards:
+
+- The room is the authority. A client sends what its player does, the room
+  decides in its state, and every client draws that state. std 0.8 has no
+  items, pickups, health or scores of its own: they are the game's own state.
+- Models are made in Blender; the level is code that lays them out. What std's
+  export writes from a `.blend` is generated: change the `.blend`, never its
+  output. A body is authored where it belongs: in the model's `.blend` as
+  Blender has it, or by the level that places the model (std's guide,
+  "Levels").
+- Content is data (Content is data, below).
+- What a player reads is labelled, on screen and in the world: the person, a
+  screen reader and the bots read the same.
+- Every game has its bot (`autopilot/`): a goal for each ending the game has,
+  and checks that judge each goal's recorded play.
+- The visual pass comes before gameplay.
+- `pnpm check` (TypeScript, lint and the web build) is clean before a game is
+  called done, and what its play was seen to get wrong (a goal, a check, a
+  press by hand) is fixed, not left for the person as a caveat. A fault in the
+  editor or std is shown with a focused reproduction and reported instead.
 - The game is made and played on the web. Roblox and Unreal are targets the
-  person adds when they want to ship there (`npx std target add roblox`, then
-  `npx --no-install cyclotron export roblox`); never add one they didn't ask for.
+  person adds when they want to ship there; never add one they didn't ask for.
+
+Where things go:
+
+- `levels/<Name>Level.tsx` is the level, a document of its own that draws it.
+- `prefabs/<name>/<name>.blend` is a model, and beside it what std's export
+  writes from it (`<name>.glb`, `<Name>.tsx`). A model's file has no lights of
+  its own: the level that places it lights it.
+- `server/index.ts` is the room, std's `StdRoom`, a Colyseus room;
+  `shared/state.ts` is its state schema.
+- `client/` is the React Three Fiber app every player runs: `index.tsx` joins
+  the room and draws the level, `hud.tsx` is the HUD. std draws nothing on
+  the page itself: what a player sees when the game can't go on
+  (`failure.tsx`) and a P2P host's invite (`invite.tsx`) are the game's.
+- `autopilot/index.ts` is the bot's goals, `autopilot/checks.ts` their checks.
+- `std.json` is the manifest. A project without one becomes a std game with
+  `npx --no-install cyclotron add-play`.
+
+Playing it in the editor:
+
+- Play (the Game panel, under every document) saves the Blender file you
+  changed (std exports it) and opens the Game view, with the game's own page for
+  each player: one unless the project's `volter.play.players` says
+  more (which the Game panel's Players [-][+] and `play players <n>`
+  set). The viewed
+  player is yours, the others are bots playing the Game panel's goal. The Game
+  view's Scene is the level live; the level's own tab stays as authored.
+  Pause, step and speed (the Game panel, or
+  `play pause`, `play resume`, `play step [count]`, `play speed <x>`) hold every
+  player's page; the room keeps running, as Colyseus cannot pause a room.
+- `npx --no-install cyclotron play autoplay on <goal>` is std's own play of a
+  goal, recorded and checked, as the Game panel's Autoplay is: on the viewed
+  player's page, which the person watches, while the Game view is on screen,
+  and out of view on std's headless device while it is not. It answers when
+  std says how the goal ended (`autoplay.state`, with how its checks ran:
+  `checks of <goal>: 2 passed (…)`, `…: 1 of 2 failed (…)` or `…: none ran
+  (…)`; the report's `checks.verdict` says which), so it
+  runs in the background. `autoplay.report` is its report. `npx --no-install cyclotron play-log` is what happened, the
+  room's own `console.log` among it (`server-output`).
+- Continuous play is the bot's, never yours by hand: your inputs arrive one tool
+  call at a time, seconds apart, so a real-time game driven by hand plays in
+  stop-motion and rarely reaches an ending. A manual check is a few discrete
+  key presses and HUD clicks (`editor.document.key`, `editor.document.click`;
+  at most about ten), then hand back to the bot.
+- Say in Chat that the game is playable as soon as it is, then check its
+  endings with its goals and by hand, restarting it as a player would.
 - Capture the running game, HUD included (`capture --region play`), at the
-  start, during representative actions and after changes; its labelled
-  nodes (`editor.inspect()`'s `inspection.screen`) say what the HUD reads.
-  Fix what you see, play again and report what was actually observed.
+  start, during representative actions and after changes; its labelled nodes
+  (`editor.inspect()`'s `inspection.screen`) say what the HUD reads. Report what
+  was actually observed.
 
 ## Animation
 
-- Characters and creatures that move are animated as in Blender: an armature,
-  and its motions as named actions in the `.blend`. Each becomes one of the
-  component's clips: a placed character's clips are its `animations`
-  (`THREE.AnimationClip.findByName(hero.animations, 'Run')`). Nothing plays
-  until the game plays it; the action the file assigns the armature
-  (`animation_data.action`) plays with its NLA tracks through `AnimationTracks`
-  (below).
-- Play clips as three.js does: three's `AnimationMixer`, or drei's `useAnimations`
-  in the game's client. What the mixer lacks, std adds in its style, in
-  `@volter-ai/std/animation/client`, each with a fiber hook beside it (std's guide,
-  `node_modules/@volter-ai/std-dev/docs/02bb-animation.md`):
-  - layers that go over each other by weight, as Blender's NLA does (an aim over a
-    run, an action keyed on the upper body alone): `AnimationLayers`,
-    `useAnimationLayers(root, { clips })`, then `layers.clipAction(clip, root?,
-    blendMode?, 'Upper')`;
-  - a character's NLA tracks as the `.blend` authored them: `AnimationTracks`,
-    `useAnimationTracks(layers, node, frame, { clips })`;
-  - run-time aims: mark a pose bone's Damped Track with the custom property
-    `std.runtime`, then `useAimConstraints(root, { layers, find })` and set
-    `aims.get('head', 'Look').influence` in `useFrame`.
-- Make another of a character with three's `SkeletonUtils.clone`
-  (`three/addons/utils/SkeletonUtils.js`); its clips come with it.
-- Give every action that may play a fake user (`action.use_fake_user = True`):
-  Blender drops an action nothing uses when the file saves, so an unassigned
-  clip library vanishes on the next save.
+- Motion is authored in Blender: an armature and its actions, in the
+  character's `.blend`, each a clip of its component. Clips play with three.js's
+  own animation system; what it lacks that Blender has (layers by weight, NLA
+  tracks, run-time aims), std adds in three's style (std's guide,
+  "Animation").
+- Every action that may play has a fake user: Blender drops an action nothing
+  uses when the file saves.
 
 ## Cutscenes and films
 
-- A moment inside the game (a launch, a set piece, an ultimate, an emote) plays
-  live in the game. Author it on the Timeline in a collection of its own (keyed
-  objects and cameras, markers bound to cameras, marker names for its events).
-  Play it with std's `TimelineUtils` (`@volter-ai/std/animation/client`; std's
-  guide, `02bb-animation.md`, "A level's timeline"):
-  - `TimelineUtils.timelineOf(level)` is the level's timeline;
-  - `TimelineUtils.frameAt(timeline, seconds)` is the frame;
-  - `TimelineUtils.cameraAt(level, frame)` with `lookThrough(camera, shot)` gives
-    its camera cuts;
-  - `useTimelineSampler(level, animations)` (or `new TimelineUtils.TimelineSampler(level, animations, timeline)`),
-    then `setFrame(frame, { collection, at, anchor })`, poses the level's own
-    animation: only that collection, placed at a game object when `at` is given.
+- A moment inside the game (a launch, a set piece, an emote) is authored on the
+  Timeline, in a collection of its own, and plays live in the game (std's
+  guide, "Animation", "A level's timeline").
 - A film as a file (an intro, a trailer) is rendered, not captured:
   `npx --no-install cyclotron render-movie --from <marker> --to <marker> --out <file>.webm`
   renders the span through Blender's Render Animation on the three.js engine,
@@ -430,23 +402,22 @@ A character is two jobs, in this order: how it looks, then how it moves.
 ## Content is data
 
 A game's content is data, as a game studio keeps it. Each asset is authored
-offline, saved as a file, and used by its path: a level or a piece is a
-`.blend` (Blender's own glTF export carries it to the game), a texture an
-image, a word a string the HUD shows. The code never builds at run time a mesh,
+offline, saved as a file, and used by its path: a model is a `.blend`
+(std's export carries it to the game), a texture an image, a word a string the
+HUD shows. The code never builds at run time a mesh,
 a texture or a sound a file could hold. Run-time construction stays for what is
 truly procedural: a trail's points, a destructible's fragments, a score's value.
 
-- Levels are `levels/<name>.blend`; a piece placed in levels is its own
-  `prefabs/<name>/<name>.blend` (A level and its pieces, above).
+- Models are `prefabs/<name>/<name>.blend`; the level that lays them out is
+  code (A game's level and its models, above). A block-out primitive in the
+  level stands only until its model is made.
 - A source sits beside the asset it makes: a `.blend` and the script that
   builds it (with its seed), an image's source.
 
 ## React UI
 
-- Build HUDs, menus and screens as React components in the game's client
-  (`client/hud.tsx` and beside it): plain DOM over the `<Canvas>`, reading the
-  room's state with std's and @colyseus/react's hooks. Label what a player
-  reads (`role`, `aria-label`): a screen reader and the bots read the same.
+- A game's HUD, menus and screens are React in its client (`client/hud.tsx`
+  and beside it): plain DOM over the `<Canvas>`, drawn from the room's state.
 - For a game HUD, verify the components over the running game against live
   game state (`capture --region play`, and its labelled nodes in
   `editor.inspect()`'s `inspection.screen`: role, name, bounds). For
@@ -472,9 +443,10 @@ diagnosing a problem. Do not call `editor.reloadPage()` to reveal new
 files, boards, references or scripts: a reload interrupts the editor and its
 chat, so reserve it for an explicit request or a diagnosed problem.
 
-The bottom area has two views, Game (the Game panel) and Animation (Blender's
-Timeline, Action Editor and NLA editor); they arrange the editor and do not
-change what plays, and a running game keeps running in either. Play is
+The bottom area is the Game panel. Below a model, it has two views, Game (the
+Game panel) and Animation (Blender's Timeline, Action Editor and NLA editor);
+they arrange the editor and do not change what plays, and a running game keeps
+running in either, and whatever tab is in front. Play is
 running the game.
 
 Commands, all through `npx --no-install cyclotron`:
@@ -500,11 +472,14 @@ Commands, all through `npx --no-install cyclotron`:
   game with its HUD, as that page captures itself.
 - `add-play`: make this project a std game. `play-log`: the running game's log.
 - The Game panel's controls, each printing its state: `play autoplay on
-  [<goal>]` (std's headless play of a goal, out of view) and `play autoplay
+  [<goal>]` (std's play of a goal, on the viewed player's page while the Game
+  view is on screen) and `play autoplay
   off` (that play ended, and the viewed player's bot where it drives); `play pause` and
   `play resume` (every player's page holds its clock); `play step [count]` (one
-  1/60 s frame each, pausing first); `play speed 0.25|0.5|1|2|4`; `play restart`
-  (the game's pages loaded afresh); `play mode game|animation` (the view).
+  1/60 s frame each, pausing first); `play speed 0.25|0.5|1|2|4`; `play players [1-8]`
+  (how many players Play starts: the project's `volter.play.players`,
+  which it sets); `play restart`
+  (the game's pages loaded afresh); `play mode game|animation` (a model's view).
 - `export web|roblox|unreal`: the game exported, as the Game panel's Export
   does: `web` its web build (`dist/`), an engine one of its targets
   (`npx std target add roblox` adds one, only when the person asks).

package/starter/game/levels/MainLevel.tsx

@@ -0,0 +1,24 @@
+/**
+ * The game's main level, laid out in code: what stands where, lit, as the game's first frame. A level is a React component
+ * the room renders into its world (for collision) and every page draws, the same on every target. The models it places
+ * are made in Blender, each its own `prefabs/<name>/<name>.blend`, whose export writes its component
+ * (`prefabs/ground/Ground.tsx`); their layout, their bodies, the lights and where the players come in are this file's.
+ * It is a document of its own in the editor, drawn as you change it. This file is the game's: change it.
+ */
+import { RigidBody } from '@react-three/rapier';
+import { SpawnPoint, stdSun } from '@volter-ai/std/level/client';
+import { Ground } from '../prefabs/ground/Ground.tsx';
+
+/** The level: the ground its bodies collide with, the sky's light and the sun, and the spawn point. */
+export function MainLevel() {
+  return (
+    <group name="MainLevel">
+      <RigidBody type="fixed" colliders="cuboid">
+        <Ground />
+      </RigidBody>
+      <hemisphereLight name="Sky" args={['#dbe9ff', '#6a994e', 1]} />
+      <directionalLight name="Sun" ref={stdSun} position={[10, 20, 8]} intensity={3} castShadow />
+      <SpawnPoint name="Spawn" position={[0, 1, 0]} />
+    </group>
+  );
+}

package/starter/game/prefabs/ground/Ground.tsx

@@ -0,0 +1,24 @@
+/**
+ * Ground: prefabs/ground/ground.glb as a component, written by std level (std-dev) as gltfjsx writes one: the prefab's
+ * model, its bodies react-three-rapier's (from the Blender file's Rigid Body panel, each following its object through
+ * std's useFollowObject), its markers std's, pure as what the room renders is. The room renders it where its level
+ * places it (std's root of the room, its bodies react-three-rapier's own), as each page does; its behaviour, the room's
+ * half, is the game's (`this.std.onBehaviour`). Export it again when the .blend changes; edit the game's code, not this
+ * file.
+ */
+import type * as THREE from 'three';
+import { useGLTF } from '@react-three/drei';
+import groundUrl from './ground.glb?url';
+
+/** The glb's nodes and materials this component reads, typed as gltfjsx's `--types` types them. */
+type GLTFResult = ReturnType<typeof useGLTF<string>> & { nodes: { Floor: THREE.Mesh }; materials: { Grass: THREE.Material } };
+
+/** prefabs/ground/ground.glb's scene: its meshes and markers, its bodies around the nodes that collide. */
+export function Ground(props: { name?: string; position?: [number, number, number]; rotation?: [number, number, number]; scale?: number | [number, number, number]; userData?: Record<string, unknown> }) {
+  const { nodes, materials } = useGLTF(groundUrl) as GLTFResult;
+  return (
+    <group name="Ground" {...props}>
+      <mesh name="Floor" geometry={nodes.Floor.geometry} material={materials.Grass} receiveShadow position={[0, -0.5, 0]} />
+    </group>
+  );
+}