Repository navigation
EN Install Upgrade
Français · Type: how-to · Audience: author · Context: created project · Status: ready · Applies from: 4.3.0
Moving a game to a newer engine is three commands: install the new engine, migrate, verify. This page gives them
with the checks around them, for a created project first, then for a game inside the engine repository and on a
hosted Studio.
# in the created project
npm install https://github.com/wanoo/quest-n-click/releases/download/v<version>/quest-n-click-<version>.tgz
npx quest-n-click migrate
npm run verifyOnce the engine is on npm, the first line is npm install quest-n-click@<version>. Read the upgrade notes of each
version you cross first; the rest of this page is the same procedure with its checks.
Your game on the new engine version: its sources at that engine's authoring format, checked by verify, its players'
saves still loading.
- A created project (the engine under
node_modules/quest-n-click). A game inside the engine repository and a game on a hosted Studio have their own section below. - This procedure is the one for a target of 4.3.0 or later, where
quest-n-click migratealso renames a project still under the former nameweb-scumm. Coming from before 4.2.5, read Coming from web-scumm too. - What each version changes is in the upgrade notes: 4.4, 4.3, 4.2, 4.1, v3, v2 to v3. Which versions are supported, and how long a deprecation lasts, is on Stability.
- Every upgrade is checked before a release: the candidate creates a game with an older release, makes a save in it,
moves the project to the new archives as below, and plays the old save to the ending (
npm run upgrade-check,scripts/external-consumer.mjs, on Ubuntu, macOS and Windows).
- The project committed (or copied):
migraterewrites sources in place. - The Requirements of the new version (Node 22.12, 22.13 for the local Studio).
- The upgrade notes of every version between yours and the target, read for what concerns your game.
In the created project's folder, on your machine.
-
Commit the project as it is, so the upgrade is one reviewable change:
# in the created project git add -A && git commit -m "Before the engine upgrade"
-
Install the new engine. Today, from the release archive (the engine is not on npm: Install from npm, once published):
# in the created project npm install https://github.com/wanoo/quest-n-click/releases/download/v4.4.0/quest-n-click-4.4.0.tgzOnce the engine is on npm, this step is
npm install quest-n-click@<version>.
-
Bring the sources to the installed engine's format.
--checkfirst says what is due and writes nothing:# in the created project npx quest-n-click migrate --check npx quest-n-click migratemigratedoes, in order: makestsconfig.jsonacceptable to TypeScript 7 (dropsbaseUrl, the paths made relative, 4.1.8); renames what still saysweb-scumm(imports,tsconfig.json,package.json's commands, 4.3.0); then, for a game still on authoring schema 2, writes its stable ids (ids --write --map) and prints what is left to do by hand. A game already on schema 3 gets✔ [<id>] authoring schema 3: up to date with this engine.
- If
migraterenamedpackage.json, install again:npm install.
-
Check the game, then rebuild its assets if the notes ask for it:
# in the created project npm run verify npm run assets
- Load a save made before the upgrade. In
npm run dev, continue from an autosave or a slot, or import an exported save from the pause menu, and play on.
- Build:
npm run build, then commit the upgrade.
Guarantee ·
migrate-check-says-due· referenced · scope self-checked by the author (AI), not reviewedmigrate --checkon a game still at authoring schema 2 exits with code 1 and saysauthoring schema 2: a migration to 3 is due.
The test runs it on a schema-2 fixture. That nothing is written is read in the code (--check exits before the ids
are written); the test does not assert it.
- A save from any 3.x or 4.x release loads in every later 4.x. Since 4.1.15 a save is written as envelope schema 4;
schema 3 (every save before 4.1.15) is still read and opens in the story world. The sample game keeps one save per
release, from 3.0.0 to 4.4.0, and each must load on the current engine and reach the ending
(
tests/save-v3.test.ts, "golden saves"). - A save newer than the game is refused, never half read: with a
saveVersionabove the game's, no chain of migrations reaches the game's version, and loading stops withsave version <n> cannot be migrated to <m>(src/engine/core/save.ts); the current session is left as it was. - When your content changes in a way that breaks saves, you raise
saveVersionand add onemigrationsstep per version: State and saves. - Downgrades are not supported: a save made by a newer engine may not load on an older one (a 4.1.15 save does not load on 4.1.14).
npx quest-n-click help prints the new version on its first line. npx quest-n-click migrate --check exits 0.
npm run verify passes. An old save loads and plays on.
| Symptom | Cause | Fix |
|---|---|---|
npm error 404 Not Found - GET https://registry.npmjs.org/quest-n-click |
npm install quest-n-click@<version>: not on npm |
Install the archive's URL (step 2) |
| ✖ tsconfig.json has baseUrl, which TypeScript 7 refuses: a migration is due | A project made before 4.1.8 | npx quest-n-click migrate |
✖ still under the former name web-scumm: … |
A project made before 4.2.5 |
npx quest-n-click migrate, then npm install (Coming from web-scumm) |
✖ [<id>] authoring schema <n> is newer than this engine's (3): install a newer quest-n-click |
The game was written for a newer engine | Install that engine, not an older one |
An import of web-scumm/content (or another web-scumm/…) no longer resolves |
Imports under the former name, gone in 4.3.0 | npx quest-n-click migrate |
package.json and package-lock.json (the engine's version); what migrate rewrites: tsconfig.json,
package.json's scripts, the game's sources (imports, and stable ids for a schema-2 game, with ids.migration.json
and ids.paths.json); public/assets/ after assets. Players' saves stay in their browsers: nothing on your side
rewrites them; the new engine reads them.
Before the release goes out: git reset --hard to the commit of step 1, then npm install to put the old engine
back. After players have played on the new version, going back is not supported: their saves may already be in a
format the old engine does not read.
In the engine repository the engine is the checkout itself: move it to the new version (git pull, or
git checkout v<version>), then:
# at the root of the engine repository
npm ci
GAME=<id> npm run migrate -- --check
GAME=<id> npm run migrate
npm run verify:gameThe owner upgrades a hosted game's engine from the Studio (POST /api/engine/migrate): the migration runs on the
worker, is judged like a revision, and is written as one undoable operation, or refused (422) with nothing written:
Upgrading the engine of a hosted game. Upgrading the server itself is
Upgrading the server.
- The upgrade notes: 4.4, 4.3, 4.2, 4.1, v3, v2 to v3
- Stability, State and saves, Changelog
-
tools/migrate.ts,scripts/upgrade-check.mjs,tests/save-v3.test.ts
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