Repository navigation
EN Studio Edit A Room
Français · Type: how-to · Audience: author · Context: local Studio · Status: ready · Applies from: 4.2.1
The local Studio · contract: stable · verified by CI (support matrix of 4.4.0, 2026-10-23): Chromium end to end (the Studio's checks); Windows: the unit suite only · automated checks: jobs
e2e,windows; CI plane2e,windows; 2 test files · people's passes:studio-hero-matrixnot run (#238) · known limits:texts-only-literals
The Rooms tab edits a room's texts, reactions, talk topics and stage without opening its TypeScript file, and writes the change back into that file as readable code.
A room changed from the Studio: a look line added, a reaction edited through a form, a prop added and placed. Each
change is in rooms/<room>.ts (or layout/<room>.json) as if you had typed it, validated, and undoable.
The local Studio (npm run studio), in the engine repository or a created project. True from 4.2.1, when every
Studio write became one operation of the game's journal, judged before it is written. The hosted Studio uses the same
tab, with leases and roles on top (Working together day to day).
- The Studio running: The local Studio: overview and launch.
- A room declared in the game (
index.ts/game.ts); a room the game does not list answersroom "<id>" is not in the game (index.ts / game.ts).
In the browser, on the Studio page (http://localhost:5173/__studio/#rooms/<room>). The only command is the one that
starts the Studio, in the engine repository or the created project.
- Select something. Pick the room in the Rooms tab. The room is drawn by the engine with the placement editor on top; the list on the right holds its props, actors and hotspots. Selecting one, in the list or in the view, opens its sheet: name, kind, states, visibility, look lines, reactions (verb, targets, condition, and the commands as a list of lines: texts editable, other commands shown), and talk topics, as a list or as a tree (topics, lines, choices and their options, branches, each with its condition; tapping a node jumps to its editor). Under the view: the room's name, hints, on enter lines, the room's scripts and events (structure read-only, texts editable).
-
Edit a text. Change a field, then leave it (or press Enter): the text is saved. Escape cancels. Each save shows
a toast and runs Check in the background (Check). A placement in progress in the view is saved
first; the view reloads when the room file changes. The text is written into
rooms/<room>.tsin place: the string literal is replaced through the TypeScript parser, with the same quote style, and the file stays readable code. Look lines can be added, edited and deleted from the sheet.
-
Add a prop, a hotspot or an actor. "Add prop / hotspot / actor" creates the entry in the room file (the section
is created if absent) and gives it a place in the layout: a prop has its foot at the point given and a height of
60; a hotspot is a 60 × 60 box centred on it; an actor has its feet there. A prop or a hotspot needs a name. The id
is letters, digits and
_, not starting with a digit; an id the room already has is refused (409). The room file and its layout are written as one operation, undone in one step. Then drag it where it belongs (Placement and stage).
- Edit a reaction or the stage through a form (below, "Structured editing"): Edit… on a reaction, + Reaction at the end of the list, Stage… and the painter on the room sheet. Each form shows the diff before it writes (Preview, apply, undo).
- Check the timing of a script. Next to every cutscene, arrival script and world script, the Timeline toggle draws how long each command takes and what overlaps: lines, walks, animations, parallel branches, the player's turns in red. Tap a bar to jump to its line; double-click a bar to change a wait's, an animation's or a motion's duration.
-
Forms instead of code. Each reaction has Edit… (verb, targets, condition, commands as a form), and the list
ends with + Reaction. The room sheet has Stage… (layers with their image, role and condition; lights;
particle emitters; the transition; the logic of walk links) and the painter (the game's, DOM or canvas). The
forms come from one table of every condition and command,
src/studio/schema.ts, checked against the engine's types at compile time: a new command without a form does not compile. What has no simple field (a minigame's parameters, an animation's frame events) is a JSON box. -
Layers, masks, zones. Under the room sheet, the stage editor (
src/studio/rooms-stage.ts) draws the backdrop with the occlusion masks (red), the walk zones (green) and the links between zones; the geometry itself is described in Placement and stage. - Preview, then apply. "Preview the change" shows the diff the server would write, without writing; "Apply" writes it as code in the file's style, then the game is validated: an edit that adds a validation error is refused and nothing is written (Preview, apply, undo).
- Undo / Redo in the header (Ctrl/Cmd+Z, with Shift to redo), over every write of the session: texts, values, layouts, voices.
- Play. The Play tab shows the painter of every room (DOM or canvas, as the game says) and how fast it draws (frames per second, the canvas painter's repaints).
Applies from 4.3.0
For a game whose texts hold switches ({form?m=…|f=…}, {hero}), the Rooms tab keeps the raw braces in its text
editor. Under a text holding a switch, a read-only line shows the text as a player reads it with the values picked in
the Play tab's Text switches ((form=?) while none is picked). See
Play and replay a session and Heroes: several characters and hero choice.
Notes about the room or one of its entities appear at the bottom of the room's section ("Notes (n)"), with a box to add one (Notes).
Limit ·
texts-only-literalsOnly string literals the Studio recognises as texts are edited this way: names, look lines, lines ofsay, topics, hints, toasts, choices, hero lines in command lists. Ids, image references, flags and conditions are never texts, and the API refuses to edit them; a text the room builds with code (a shared constant, a helper) is not reachable. The full rule is in Studio API.
The toast says the text was saved; the engine view shows the change; git diff games/<id>/rooms/<room>.ts shows a
one-line change in the file's own style. The Check tab's badge shows whether the game still validates.
| Symptom | Cause | Fix |
|---|---|---|
refused: the edit adds N validation error(s): … (422) |
The change would break the game; nothing was written | Read the errors, change the value, apply again |
"<id>" already exists in room "<room>" (409) |
The id is taken in that room | Pick another id |
`name` is required for a prop or a hotspot |
Add prop or hotspot without a name | Give a name |
cannot undo "<what>": <file> changed since (409) |
The file was edited outside the Studio after that write | Undo by hand, or with git |
More: Studio troubleshooting.
-
games/<id>/rooms/<room>.ts(texts, reactions, stage, painter, added entities). -
games/<id>/layout/<room>.json(an added entity's place). - The journal of the game under
.cache/studio-journal/(the operations, for undo).
Undo in the header takes back the last write of the session, Redo puts it back. An undo refuses when the file was
changed since by someone else (an AI, an editor, git): then use git diff and git checkout -- <file>.
-
src/studio/rooms.ts,src/studio/rooms-sheet.ts,src/studio/structured.ts,studio-server/src/ops/core.ts. -
npm run e2e:studio -- <studio url>(a CI gate) creates a stage with the form, checks the diff, applies it, sees it in the game and undoes it (scripts/e2e-studio.mjs). - Rooms, Reactions, Dialogues.
Generated publication · publication générée — current documentation · documentation courante: quest'n'click 4.4.0 r1, documentation revision · révision de la documentation 8dc717c69acb62c4742b69c54a7e7dfb620f75d8.
Earlier versions and permalinks · versions précédentes et liens permanents: https://wanoo.github.io/quest-n-click/docs/
An edit made in this wiki is overwritten at the next publication · une modification faite dans ce wiki est écrasée à la publication suivante.
Edit the source · Modifier la source · Report an error · Signaler une erreur
Index (6)
Start (6)
Play (9)
Install (17)
- Requirements
- Install from the release archive
- Install from npm, once published
- Install from the repository to work on the engine
- doctor: checking your machine
- Image toolchain
- Audio toolchain: ffmpeg, fluidsynth, Furnace, uv
- Upgrade
- Upgrade notes: 4.4
- Upgrade notes: 4.3
- Upgrade notes: 4.2
- Upgrade notes: 4.1
- Upgrade notes: v3
- Upgrade notes: v2 to v3
- Coming from web-scumm
- Package reference
- Install troubleshooting
Create a game (55)
- Your first game
- Layout of a created project and of the engine repository
- The working loop
- Content principles and the identity contract
- Rooms
- Geometry: placement, walk zones, masks, layers, camera
- Something is visible but unreachable
- Reactions
- Game commands
- Conditions
- Flags, variables and events: which to use
- Custom code
- Characters
- Items and inventory
- World map
- Dialogues
- Scripts and events
- Moving characters: patrols and walks
- Exits
- Chapters and objectives
- State and saves: persistent or temporary, renaming an id, migrations
- Staging: wide rooms and animations
- The stage: lights, particles, floors
- Skin and fonts
- Title and credits
- Heroes: several characters and hero choice
- Built-in minigames
- A custom minigame
- Translations
- Music in stems
- Sound effects
- Voices: per language and per hero
- Images: prompts, cutting sheets, transparency, scale
- Asset provenance
- The storyboard, source of truth
- Puzzle design
- Classic mechanics
- Review pages
- DSL reference
- Checking your game
- What the solver proves
- Solver options
- Playtests
- Remix
- Speedrun for authors
- The sealed ending
- Production template
- Example games
- Working with an AI
- Build and release a game
- Publish on GitHub Pages
- The static game on Clever Cloud
- Other static hosts
- Sub-path, cache and service worker, incomplete deploys, going back
- Testing on a phone over the LAN
Local Studio (24)
- The local Studio: overview and launch
- Edit a room
- Placement and stage
- Preview, apply, undo
- Storyboard
- Assets and cutting
- Check: validator, solver, critical path, heat, health, coverage
- Before and after captures
- Semantic diff
- Play and replay a session
- Rule explainer
- Language and objectives
- Voices and the heroes × languages matrix
- Map
- Notes
- Remix in the Studio
- Music
- The Assistant: bring your own key
- Demo mode and studio-apply
- Local and LAN security
- Studio API
- Local MCP: setting up each client
- MCP tools
- Studio troubleshooting
Team Studio (21)
- What runs where
- Concepts: revision, transaction, span, lease, preview, build
- Starting as an invited dev
- Working together day to day
- Roles and actions: the full matrix
- Invitations
- Managing members
- Write refused on the hosted Studio: stale base revision (409)
- Write refused on the hosted Studio: span locked (423)
- Recovering after a lost lease, a disconnection or a stale preview
- Comments
- Map and semantic diff
- Publishing builds
- Remote MCP
- The game in Git
- Upgrading the engine of a hosted game
- Hosted assets
- The server's command line
- Health and metrics routes
- Trying it locally with compose.yml
- Known limits
Clever Cloud (23)
- Clever Cloud: overview, cost and prerequisites
- Apps and add-ons
- Domains and TLS
- Keycloak
- Generic OIDC and GitLab
- Configuration
- First deployment
- Backups
- RPO and RTO
- Restore the Studio on a fresh installation
- Redeploys
- Upgrading the server and checking state after a migration
- Limits of going back
- Monitoring
- Security
- Rotating keys
- Recovering admin access
- Changing domain or OIDC provider
- Worker, PostgreSQL or Cellar down
- Exporting the game and leaving the installation
- Retention
- Clever Cloud troubleshooting
- Costs and teardown
Reality Bridge and connectors (16)
- The Reality Bridge: what it is
- Quick start
- Guarantees
- Install and run the Bridge
- Backup and restore
- Several tenants
- Signals and the manifest
- The Bridge's command line
- Connectors overview
- Email connector
- Telnet connector
- SSH connector
- Open Badges connector
- The connector SDK
- Security: Biscuit and signatures
- Bridge and connector troubleshooting
Contribute (25)
- Welcome
- Developer setup
- The dev loop
- Before a pull request
- Conventions
- Writing documentation
- Architecture
- Code tour
- Import boundaries
- Which tests run when
- Mutation testing
- The coverage ratchet
- The quality baseline
- CI explained
- Field passes
- Benchmarks
- Releasing
- npm packages
- Decisions and ADRs
- Governance
- Bot pull requests
- Contributing with AI agents
- Security policy
- Code of conduct
- Licences and credits