Référence du paquet

English · Type : référence · Public : auteur, contributeur · Contexte : dépôt du moteur, projet créé · Statut : prête · S'applique depuis : 4.3.0

Ce que contiennent les paquets npm du moteur, les commandes que le paquet quest-n-click donne à un projet de jeu, et comment chaque release les vérifie. scripts/pack.mjs les fabrique depuis les fichiers que git suit ; leur installation est décrite dans Installer depuis l'archive de la release.

Le moteur en paquet

Depuis la 3.9, un jeu n'a plus à vivre dans le dépôt du moteur. Le moteur est empaqueté en quest-n-click (le moteur, ses pages, ses outils et la commande quest-n-click, le modèle de jeu), create-quest-n-click (npx create-quest-n-click) et, depuis la 4.1.1, quest-n-click-bridge (le Reality Bridge de référence). Depuis la 4.1.9, les connecteurs forment un quatrième paquet, quest-n-click-connectors, et depuis la 4.2.1 le Studio hébergé un cinquième, quest-n-click-studio-server.

Jusqu'à la 4.2.4, ils s'appelaient web-scumm, create-web-scumm, web-scumm-bridge, web-scumm-connectors et web-scumm-studio-server (le projet s'appelait web-scumm, D47). Pendant toute la 4.2.x, chaque release les livrait aussi sous leurs anciens noms, et les anciennes commandes et les anciens imports (web-scumm dev, web-scumm/content) marchaient encore, après une ligne d'avertissement. La 4.3.0 les retire : npx quest-n-click migrate renomme ce qu'un jeu dit encore (Venir de web-scumm).

Aucun n'est encore sur npm : chaque release les joint sous forme d'archives (Installer depuis npm, une fois publié).

quest-n-click

Contenu

Les fichiers suivis sous src/, tools/, studio-server/, cli/, games/_template/, public/icons/, public/fonts/, public/og.png, les fichiers de stockage et de migrations que le journal du Studio partage avec le Bridge (bridge/src/store*.ts, migrations.ts, allowlist.ts), index.html, studio.html, vite.config.ts, tsconfig.json, requirements.txt, ops/studio/worker-requirements.lock et LICENSE. Jamais un jeu du dépôt, un test, une page de documentation source ni un build. Laissés aussi hors de tools/ : l'audit des assets, la vérification croisée et les jeux de données du Bridge, le harnais de fuzz des connecteurs.

Points d'entrée

La commande quest-n-click (cli/quest-n-click.mjs), et cinq entrées publiques : quest-n-click/content, /player, /minigames, /testing, /reality (API publique), plus quest-n-click/cli/*. Tout le reste est interne.

Dépendances

Les dépendances d'exécution du moteur (earcut, howler, navmesh, zod) et ce dont les outils ont besoin dans un projet de jeu : Vite et vite-plugin-pwa, tsx, @typescript/typescript6 (l'API du compilateur qu'utilisent les outils), @types/node, @types/howler, Tweakpane, le SDK MCP. Les tests et Playwright restent dehors : c'est pourquoi quest-n-click doctor demande un contournement dans un projet créé (doctor). Le paquet ne porte pas de verrou : npm résout ces plages à l'installation.

Sa documentation, docs-bundle/

fonction apparue en 4.5.0

Depuis la 4.5.0, le paquet porte la documentation de sa version, écrite par npm run wiki -- bundle dans le dossier préparé avant npm pack (jamais commitée) : index.json, md/<lang>/<id>.md, legacy/<NAME>.md, assets/ et bundle-manifest.json avec le sha256 de chaque fichier. Deux empaquetages d'un même commit donnent les mêmes octets. Le serveur MCP d'un projet créé la lit (read_doc, search_docs, list_docs).

create-quest-n-click

Un seul fichier, index.mjs, qui lance quest-n-click create depuis le moteur dont il dépend (quest-n-click à la même version) : npx create-quest-n-click my-game "Mon jeu" une fois sur npm.

quest-n-click-bridge

Le Reality Bridge de référence, seul : bridge/src regroupé par esbuild en un seul module (src/cli.mjs, compilé depuis la 4.1.2, il tourne donc avec Node seul), ses politiques Datalog et ses migrations SQL, la commande quest-n-click-bridge (init, serve, grant, rotate, revoke, doctor, compact, migrate, tenant, backup, restore). Le WebAssembly de Biscuit et zod sont des dépendances ; pg et OpenTelemetry ne sont chargés par leur nom que s'ils servent. Il porte son npm-shrinkwrap.json (depuis la 4.1.19) : une installation ne résout rien. La CLI du Bridge.

quest-n-click-connectors

Le SDK des connecteurs, la commande quest-n-click-connector <email|telnet|ssh|open-badge> --config <fichier.json> et les quatre connecteurs regroupés en un module, avec le worker du lecteur MIME à côté ; ssh2 est une dépendance. Un paquet d'opérateur, qui tourne à côté d'un Bridge, jamais celui d'un jeu. Installez-le sans code natif : npm install --omit=optional --ignore-scripts quest-n-click-connectors-<version>.tgz. Il porte son npm-shrinkwrap.json. Expérimental (4.1.9). Les connecteurs.

quest-n-click-studio-server

Les commandes quest-n-click-studio-server et quest-n-click-studio-worker, qui font tourner le serveur et l'application de traitement du moteur installé à côté (la même version, sinon elles s'arrêtent sur … runs with quest-n-click <v>, not <w>), et la page du Studio construite une fois. Ses propres dépendances sont verrouillées dans son npm-shrinkwrap.json ; installé depuis le fichier d'archive plutôt que depuis le registre, npm les résout depuis leurs plages (quest-n-click-studio-server deps dit lesquelles). Installer depuis l'archive de la release.

Les commandes d'un projet créé

npx quest-n-click help les liste. Le package.json du projet nomme les habituelles comme scripts npm (dev, studio, assets, verify, build, release, preview) :

Elles tournent avec le projet comme dossier de travail (WEB_SCUMM_PROJECT) : le moteur dans node_modules/quest-n-click est lu, jamais écrit. Toutes les options sont dans Ligne de commande.

Comment c'est vérifié

• npm run fresh-install (un job de CI, quand un paquet, le modèle ou un chemin d'écriture a changé) : empaquette le moteur (npm run pack), crée un jeu depuis le modèle empaqueté dans un dossier vide hors du dépôt, installe l'archive, lance assets, verify et build, et joue le jeu jusqu'à sa fin dans Chromium. Un fichier du nouveau projet qui nomme le dépôt le fait échouer.
• npm run external-consumer (chaque candidat de release, sous Ubuntu, macOS et Windows) : les archives du candidat lui-même, jamais réempaquetées, installées hors du dépôt : un jeu créé sur une release plus ancienne et passé à elles, une ancienne sauvegarde jouée jusqu'à la fin, le bundle de documentation vérifié contre son manifeste et lu par un vrai client MCP, create-quest-n-click, le Bridge et les connecteurs depuis leurs archives.
• npm run readme-quickstart : le démarrage rapide du README, lancé comme un lecteur le copie.
• npm run upgrade-check -- --from=<version> : un jeu passé d'une release plus ancienne à celle-ci.
• scripts/studio-install-smoke.mjs : les archives du moteur et du Studio Server installées ensemble, un jeu servi.

Chaque release joint les cinq archives avec leurs SBOM et leurs sommes. Les publier sur npm revient au mainteneur (un jeton, les noms des paquets) : Paquets npm.

Identifiants liés

• npm run pack (node scripts/pack.mjs [--out=<dossier>] [--publish-dry-run] [--build-id <id>] [--allow-dirty]), qui écrit par défaut dans .cache/pack
• npm run locks (les verrous du Bridge et des connecteurs, scripts/locks/ ; un verrou qui ne correspond plus arrête pack)
• Installer depuis l'archive de la release, Ligne de commande, Paquets npm
• scripts/pack.mjs, scripts/fresh-install.mjs, scripts/external-consumer.mjs

Modifier la source de cette page · Signaler une erreur