quest'n'click 4.5.0 · r1

Construite pour quest'n'click 4.5.0, révision r1. Si elle est publiée, et laquelle est la courante, est dit par publication.json.

Bienvenue

English · Type : explication · Public : contributeur · Contexte : dépôt du moteur · Statut : prête · S'applique depuis : 4.4.0

quest'n'click est un petit projet, avec un seul mainteneur, @wanoo. Une contribution est la bienvenue quand elle est petite, testée et expliquée : un correctif accompagné de son test de non-régression, un cas qui manquait au validateur, une page plus claire. Cette page dit pourquoi le projet fonctionne comme il fonctionne ; les pages qu'elle cite disent comment.

Pourquoi le projet fonctionne ainsi

Un jeu est une donnée, jamais du code. Le moteur, dans src/engine/, lit un dossier de jeu games/<id>/ et ne sait rien d'autre de lui. C'est ce qui permet au validateur, au solveur, au rejeu, au Studio et à un assistant IA de lire et de vérifier le même contenu. Une modification du moteur tient cette promesse : le gameplay reste déclaratif dans games/<id>/, et la géométrie reste dans layout/*.json (voir Architecture).

La plupart des mécaniques existent déjà. Avant de demander une nouvelle commande ou un nouveau champ, lisez les mécaniques classiques du genre (Mécaniques classiques, l'ancien docs/fr/CLASSICS.md) : les duels d'insultes, les objets qui fondent, les rondes, le marchandage et les énigmes à plusieurs personnages sont des combinaisons de règles, de drapeaux, de scripts et d'événements que le moteur possède déjà. Une demande de nouveauté part du modèle d'issue « feature », après cette page.

Chaque affirmation a sa vérification. Le projet préfère une barrière qui échoue à une promesse qui dérive. Les seuils de couverture ne font que monter (Le cliquet de couverture), le comportement du moteur est figé dans une référence (La référence de qualité), et chaque mutant survivant est nommé avec sa raison (Tests de mutation). Ce que seuls des gens et de vrais appareils peuvent vérifier est une passe de terrain, rapportée à chaque release (Passes de terrain).

Ce qui est public est une promesse ; le reste peut bouger. Le DSL public, l'enveloppe de sauvegarde et les contrats de plugin suivent le versionnage sémantique depuis la v3, sauf sur la ligne d'incubation 4.1.8–4.1.15, où une rupture était documentée avec sa migration (Stabilité et support). Les modules internes ne sont pas des promesses de compatibilité, sauf si une page dit le contraire (Frontières d'import).

Comment se passe une contribution

  1. Préparez la machine une fois : Préparer son poste de développement.
  2. Lisez le code avec Architecture, puis suivez la Visite du code (une demi-heure).
  3. Changez une chose, avec la boucle de La boucle de développement. Restez petit ; un correctif arrive avec le test qui l'aurait attrapé.
  4. Nommez la branche, la pull request et le fragment du CHANGELOG comme le dit Conventions.
  5. Lancez les vérifications d'Avant une pull request, ouvrez la pull request depuis le modèle, et lisez ce que dit la CI (La CI expliquée).

Travailler avec un assistant IA est attendu, et a ses propres règles : Contribuer avec des agents IA.

Limite · private-assets N'ajoutez jamais d'assets sources privés, ni de matériel dont les droits commerciaux sont flous. Tous les assets du jeu d'exemple sont sous CC BY 4.0 (Licences et crédits).

Conduite et sécurité

Chacun ici suit le Code de conduite. Une vulnérabilité se signale en privé, jamais dans une issue publique : Politique de sécurité. Comment les décisions sont prises, et par qui, c'est dans Gouvernance et Décisions et ADR.

Décisions et ADR

Modifier la source de cette page · Signaler une erreur