Repository navigation
FR Creer Principes
English · Type : explication · Public : auteur · Contexte : dépôt du moteur, projet créé · Statut : prête · S'applique depuis : 4.3.0
Pourquoi un jeu quest'n'click s'écrit en données, pourquoi sa géométrie vit dans un fichier à part, et pourquoi tout ce qu'une sauvegarde retient porte un identifiant stable.
Cette page et les autres pages « Créer un jeu » s'adressent à qui écrit l'histoire : les salles, les répliques, les
énigmes. Elles décrivent le format que lit le moteur. Vous n'avez jamais à toucher au moteur (src/engine/) : tout le
jeu tient dans un dossier, games/<id>/ dans le dépôt du moteur, game/ dans un projet fait avec
quest-n-click create (organisation des deux).
Les types complets, commentés, sont dans src/engine/core/types.ts, qui réexporte
les fichiers de src/engine/core/types/ (découpés par sujet en 4.1.0). Votre éditeur les propose en autocomplétion.
La référence du DSL, générée, liste chaque commande et chaque condition.
Ces pages remplacent l'ancien docs/fr/CONTENT_GUIDE.md, découpé par question. Depuis la bascule de la 4.5, cet
ancien fichier est une page de transition : il garde toutes ses anciennes ancres, chaque ancien titre renvoie à
ses nouvelles destinations ici, et un lien de secours vers blob/v4.4.0/docs/fr/CONTENT_GUIDE.md marche toujours.
-
Du contenu, pas du code. Le contenu est fait de données : des objets, des listes, des textes. Aucune fonction.
C'est ce qui permet au moteur de vérifier le jeu tout seul (
npm run validate) et de prouver qu'on peut le finir (npm run solve). -
La logique d'un côté, la géométrie de l'autre. Vous écrivez ce qui se passe dans
rooms/<salle>.ts. Où sont les choses (rectangles cliquables, position des personnages, zone de marche) vit danslayout/<salle>.json, placé à la souris dans l'éditeur de placement (npm run dev, puis?edit=<salle>) ou dans le Studio. Vous ne tapez jamais de coordonnées à la main, sauf pour un déplacement scripté ponctuel (géométrie). - Rien n'est une impasse. Toute action reçoit une réponse. Sans réaction écrite, le moteur répond avec les réponses de repli du jeu (réactions).
- Des coordonnées logiques. Un décor mesure 640 × 400, origine en haut à gauche. Un personnage se place par les pieds.
Limite ·
custom-code-is-code« Aucune fonction » vaut pour le contenu. Ce dont un jeu a vraiment besoin au-delà du DSL, une commande sur mesure ou un mini-jeu, est du TypeScript à lui, à côté du contenu, nommé dans le jeu et qui déclare ses effets (code sur mesure).
Un nouveau jeu pose schemaVersion: 3 dans game.ts (le modèle le fait). Tout ce dont la position d'exécution
survit dans une sauvegarde porte un identifiant explicite et unique : chaque Rule, TalkTopic, Choice,
EventRule, et chaque bloc once, nth, cycle ou random. Un ScriptDef a déjà son id et ajoute une entrée
stepIds par commande de premier niveau. Le validateur refuse un jeu v3 dont un id manque ou se répète
(… requires a stable "id" in schema v3, duplicate stable id "…",
schema v3 script needs one stable step id per command). Réordonner le contenu ou traduire un texte ne change donc
pas le sens d'une sauvegarde.
schemaVersion: 3,
// …
{ id: 'open.pantry', verb: 'open', a: 'pantry', do: […] }
{ id: 'ask.key', topic: 'Où est la clé ?', do: […] }
{ once: […], id: 'arrival.first' }
{ id: 'clock', stepIds: ['wait', 'chime'], do: [{ wait: 1000 }, { sfx: 'chime' }] }Les répliques peuvent aussi porter un id ({ say: [...], id }, { id, text } dans une liste) : traductions et clips
de voix suivent alors l'id, pas la position de la réplique (npm run ids -- --lines).
npm run ids -- --write --map écrit ces ids dans un jeu existant, avec l'étape de migration dont ses sauvegardes ont
besoin ; renommer un id plus tard sans casser les sauvegardes est expliqué dans
état et sauvegardes. compileGame(source)
(src/engine/core/define.ts) clone et normalise la source une seule fois ; un
résultat v3 est gelé, si bien qu'un outil qui tente de le modifier échoue tout de suite. Moteur, validateur, solveur,
rejeu et outils d'énigmes consomment tous cette même représentation compilée. Lisez les
notes de passage v2 → v3 avant de convertir un jeu existant.
Limite ·
ids-not-renamesLes ids stables protègent une sauvegarde contre un réordonnancement et une traduction. Ils ne la protègent pas contre un renommage : changer un id change le sens, et demande une étape de migration (migrationsdansgame.ts).
Un jeu doit être vérifié, sauvegardé, traduit, comparé entre deux révisions, édité par le Studio et par un assistant, et prouvé finissable par une machine. Une fonction glissée dans le contenu ne permet rien de tout cela : aucun outil ne sait ce qu'elle fait sans l'exécuter. Des données, tous les outils les lisent. Le solveur fait même tourner le vrai moteur sur ces données : ce qu'il prouve, un joueur peut le faire (ce que prouve le solveur).
La géométrie est à part parce qu'elle s'édite autrement (à la souris, sur l'image) et change pour d'autres raisons (un nouveau décor déplace tous les rectangles, pas une règle).
- Des scripts dans un langage généraliste (des fonctions dans le contenu) : souple, mais le validateur, le solveur, le Studio et les outils de traduction perdraient le jeu de vue.
-
Des ids par position (la règle du schéma 2 : un sujet vaut
<salle>.<acteur>.<index>) : rien à écrire, mais insérer un sujet ou traduire un texte décalait ce que voulait dire une ancienne sauvegarde. Le schéma 3 a rendu les ids explicites.
Certaines idées demandent une commande sur mesure là où trois lignes de code auraient suffi, et le DSL grandit
lentement, une primitive par besoin réel. Écrire les ids est un travail de plus ; npm run ids -- --write en fait
l'essentiel.
- ADR 0002, le contenu est une donnée ; le code dont un jeu a besoin est de confiance et nommé
- ADR 0003, le solveur fait tourner le vrai moteur
- ADR 0026, les sauvegardes d'une révision à l'autre
- Sources :
src/engine/core/content-ids.ts(les ids stables),src/engine/core/define.ts(compileGame).
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)
Démarrer (6)
Jouer (9)
Installer (17)
- Prérequis
- Installer depuis l'archive de la release
- Installer depuis npm, une fois publié
- Installer depuis le dépôt pour travailler sur le moteur
- doctor : vérifier sa machine
- Outils pour les images
- Outils audio : ffmpeg, fluidsynth, Furnace, uv
- Mettre à jour
- Notes de mise à jour : 4.4
- Notes de mise à jour : 4.3
- Notes de mise à jour : 4.2
- Notes de mise à jour : 4.1
- Notes de mise à jour : v3
- Notes de mise à jour : v2 vers v3
- Venir de web-scumm
- Référence du paquet
- Dépannage de l'installation
Créer un jeu (55)
- Votre premier jeu
- Organisation d'un projet créé et du dépôt du moteur
- La boucle de travail
- Principes du contenu et contrat d'identité
- Salles
- Géométrie : placement, zones de marche, masques, calques, caméra
- Un objet est visible mais inaccessible
- Réactions
- Commandes du jeu
- Conditions
- Drapeaux, variables et événements : lequel choisir
- Code sur mesure
- Personnages
- Objets et inventaire
- Carte du monde
- Dialogues
- Scripts et événements
- Faire bouger les personnages : patrouilles et marches
- Sorties
- Chapitres et objectifs
- État et sauvegardes : persistant ou temporaire, renommer un id, migrations
- Mise en scène : salles larges et animations
- La scène : lumières, particules, sols
- Habillage et polices
- Titre et générique
- Héros : plusieurs personnages et choix du héros
- Mini-jeux intégrés
- Un mini-jeu sur mesure
- Traductions
- Musique en stems
- Bruitages
- Voix : par langue et par héros
- Images : prompts, découpe des planches, transparence, échelle
- Provenance des assets
- Le storyboard, source de vérité
- Concevoir des énigmes
- Mécaniques classiques
- Pages de relecture
- Référence du DSL
- Vérifier son jeu
- Ce que prouve le solveur
- Options du solveur
- Playtests
- Remix
- Speedrun pour les auteurs
- La fin scellée
- Modèle de production
- Jeux d'exemple
- Travailler avec une IA
- Construire et publier un jeu
- Publier sur GitHub Pages
- Le jeu statique sur Clever Cloud
- Autres hébergeurs statiques
- Sous-chemin, cache et service worker, déploiement incomplet, retour arrière
- Tester sur un téléphone en réseau local
Studio local (24)
- Le Studio local : présentation et lancement
- Modifier une salle
- Placement et scène
- Aperçu, application, annulation
- Storyboard
- Assets et découpe
- Vérifier : validateur, solveur, chemin critique, chaleur, santé, couverture
- Captures avant et après
- Diff sémantique
- Jouer et rejouer une session
- Explication des règles
- Langue et objectifs
- Voix et matrice héros × langues
- Carte
- Notes
- Remix dans le Studio
- Musique
- L'Assistant : votre propre clé
- Mode démo et studio-apply
- Sécurité en local et en réseau local
- API du Studio
- MCP local : configurer chaque client
- Outils MCP
- Dépannage du Studio
Studio d'équipe (21)
- Ce qui tourne où
- Concepts : révision, transaction, pan, bail, aperçu, build
- Débuter comme dev invité
- Travailler ensemble au quotidien
- Rôles et actions : la matrice complète
- Invitations
- Gérer les membres
- Écriture refusée sur le Studio hébergé : révision de base périmée (409)
- Écriture refusée sur le Studio hébergé : pan verrouillé (423)
- Reprendre après un bail perdu, une déconnexion ou un aperçu périmé
- Commentaires
- Carte et diff sémantique
- Publier des builds
- MCP distant
- Le jeu dans Git
- Mettre à jour le moteur d'un jeu hébergé
- Assets hébergés
- La ligne de commande du serveur
- Routes de santé et de métriques
- L'essayer en local avec compose.yml
- Limites connues
Clever Cloud (23)
- Clever Cloud : vue d'ensemble, coût et prérequis
- Applications et add-ons
- Domaines et TLS
- Keycloak
- OIDC générique et GitLab
- Configuration
- Premier déploiement
- Sauvegardes
- RPO et RTO
- Exercice de restauration sur une installation vierge
- Redéploiements
- Mettre à jour le serveur et vérifier l'état après une migration
- Limites du retour arrière
- Supervision
- Sécurité
- Renouveler les clés
- Récupérer l'accès administrateur
- Changer de domaine ou de fournisseur OIDC
- Worker, PostgreSQL ou Cellar en panne
- Exporter le jeu et quitter l'installation
- Rétention
- Dépannage sur Clever Cloud
- Coûts et démontage
Reality Bridge et connecteurs (16)
- Le Reality Bridge : ce que c'est
- Démarrage rapide
- Garanties
- Installer et lancer le Bridge
- Sauvegarde et restauration
- Plusieurs tenants
- Signaux et manifeste
- La ligne de commande du Bridge
- Vue d'ensemble des connecteurs
- Connecteur email
- Connecteur Telnet
- Connecteur SSH
- Connecteur Open Badges
- Le SDK des connecteurs
- Sécurité : Biscuit et signatures
- Dépannage du Bridge et des connecteurs
Contribuer (25)
- Bienvenue
- Préparer son poste de développement
- La boucle de développement
- Avant une pull request
- Conventions
- Écrire la documentation
- Architecture
- Visite du code
- Frontières d'import
- Quels tests tournent quand
- Tests de mutation
- Le cliquet de couverture
- La référence de qualité
- La CI expliquée
- Passes de terrain
- Mesures de performance
- Publier une release
- Paquets npm
- Décisions et ADR
- Gouvernance
- Pull requests des bots
- Contribuer avec des agents IA
- Politique de sécurité
- Code de conduite
- Licences et crédits