sanctuary-beta/docs/prochains-tickets.md

Prochains tickets — carte immersive, progression et New Game+

Cadrage du 13 septembre 2026, après l'essai de beta.006. Branche documentaire : codex/roadmap-progression-ngplus. Statut : MAP-03 implémenté en beta.007, PROG-02A en beta.008, PROG-02B en beta.009, PROG-02C en beta.010 ; CYCLE-01, PROG-03, FACTION-01 et NGP-01 sont réunis dans beta.011. Le cadrage initial organisait la prochaine séance, évoquée pour demain. Le créateur a ensuite demandé la carte immersive ; ses vérifications sont consignées dans la livraison beta.007.

La version beta.013 aligne les compétences sur une ligne et abaisse le dernier achat à 48 niveaux (contrat), après les transferts et barres rapides de beta.012. Les numéros suivants sont des cibles indicatives, à attribuer au moment des livraisons sans réutiliser une version. Les identifiants de tickets ci-dessous sont locaux au dépôt.

Ordre de travail

Le créateur demande désormais d'achever la progression avant le New Game+, et de concevoir les factions en lien avec celui-ci. Cela complète la priorité antérieure carte → Demeure → factions/claims → New Game+.

Ordre	Ticket	Résultat vérifiable	Prérequis	Livraison visée
Cadrage dès maintenant	CYCLE-01	Contrat commun progression, recommencement, prestige et factions	Décisions du créateur	Contrat beta.011
1	MAP-03	Carte plein écran, transparence et commandes superposées	MAP-02 livré en beta.006	beta.007
2	PROG-02A	Compétence Minage et vein mining jouables	Contrat des rangs et des entrées	beta.008
3	PROG-02B	Compétence Construction et vein building jouables	PROG-02A pour les commandes communes	beta.009
4	PROG-02C	Compétence Inventaire fonctionnelle, objets préservés	Politique d'inventaire CYCLE-01	beta.010
5	PROG-03	Parcours de progression complet et fin atteignable	PROG-02A/B/C et règle de fin	beta.011
6	FACTION-01	Factions persistantes et capacités articulées au prestige	CYCLE-01 ; progression complète avant validation finale	beta.011
7	NGP-01	Premier recommencement complet, du personnage aux factions	PROG-03, FACTION-01, CYCLE-01	beta.011

Le contrat commun beta.011 remplace les questions ouvertes ci-dessous pour les prix, les rôles et la conservation. Ces quatre tickets interdépendants sont livrés ensemble sur codex/factions-new-game-plus, à la demande du créateur. Les critères initiaux restent conservés ci-dessous. La suite est CLAIM-01 : le présent lot n'attribue aucune protection de chunk.

flowchart LR
    M[Carte immersive] --> A[Minage]
    A --> B[Construction]
    B --> I[Inventaire]
    I --> P[Progression complète]
    C[Contrat cycle et factions] --> I
    C --> F[Factions]
    P --> F
    F --> N[New Game+ et prestige]
    P --> N

CYCLE-01 — Définir ce qui termine et ce qui recommence

Branche prévue : codex/progression-cycle-contract. Résultat : une règle de fin de progression et une matrice de conservation suffisamment précises pour implémenter le reset sans inventer de règles.

Décisions déjà acquises : les six compétences sont Vie, Faim, Minage, Construction, Souffle et Inventaire. Une mort ordinaire conserve compétences et aptitudes ; elle suit la règle d'XP récupérable existante. Un recommencement de personnage est distinct : les compétences sont à remonter, les aptitudes acquises sont conservées. Demeure mesure l'habitation ; ce n'est pas une propriété ni une autorisation de modifier les blocs.

Condition confirmée par le créateur : les six compétences au maximum. Vie, Faim, Minage, Construction, Souffle et Inventaire doivent chacune atteindre leur plafond. Il n'est pas nécessaire d'avoir acheté toutes les aptitudes. Les aptitudes déjà acquises sont conservées au recommencement. Le serveur évalue les six rangs ; une future aptitude n'ajoute pas un prérequis au NGP.

À fixer dans ce ticket :

• La présentation des six compétences et de leurs plafonds dans le Blocodex, ainsi que le traitement d'une évolution future des plafonds : un équilibrage ne doit pas modifier silencieusement une fin de cycle déjà enregistrée.
• Le rapport entre New Game+, compteur de prestige et récompense : ce sont des notions à relier explicitement, pas trois synonymes à supposer.
• La règle des charges ou places de faction : capacité d'en créer une, d'agrandir une faction, d'en rejoindre plusieurs ou autre effet ; quantité, détenteur de la capacité et éventuelle mise en commun.
• Pour identité, bio, couleur, aptitudes, compétences, achats, XP restante, objets, recettes/découvertes, Atlas, Demeure, exploits, argent et affiliations : indiquer conservé, réinitialisé ou archivé. Les aptitudes conservées ne peuvent pas dépendre accidentellement d'un ancien rang qui les rendrait inutilisables.
• Le sort des objets quand les emplacements d'inventaire diminuent, et celui d'une faction lorsque son créateur recommence. Aucune suppression implicite d'objets, de membres, de constructions ou d'archives collectives.

Acceptation : deux exemples chiffrés avant/après (premier puis second cycle), un cas avec inventaire plein et un cas avec faction existante. Vérifier qu'aucun prérequis ne forme une boucle impossible : finir la progression ne peut pas exiger une faction si sa création exige le premier prestige. Ce ticket ne régénère pas le monde et n'introduit pas la quête finale donnant collectivement accès au créatif ou aux droits opérateur.

MAP-03 — Faire de la carte le fond du Blocodex

Branche : codex/atlas-immersive. Implémentation : beta.007 et ses vérifications. Résultat : la carte occupe l'écran ; l'interface se pose dessus.

Le rendu de beta.006 était limité à 720 unités GUI en largeur, réservait deux lignes de commandes et un pied de coordonnées, puis découpait la texture dans la bande restante. Cette combinaison produisait le rectangle étroit observé en beta.006.

Demandes visuelles retenues :

• Étendre la surface cartographique jusqu'aux bords de l'écran, sous les zones assombries du haut et du bas. La partie directement lisible rejoint les boutons supérieurs et descend jusqu'au bouton de retour, actuellement Done / Terminé (appelé « down » dans la discussion).
• Conserver un carré éclairci au centre, avec la carte plus sombre autour. Ce carré est un traitement de lumière : il ne découpe ni ne limite la carte. Adapter sa taille au GUI ; régler les opacités sur des captures en jeu.
• Rendre transparent ce qui n'a pas de surface cartographique à dessiner. Le vide observé et l'inconnu gardent leurs états distincts côté serveur, même si leur représentation utilise la transparence. Le fond du menu peut rester visible ; aucun terrain cartographique inconnu n'est reconstruit.
• Superposer coordonnées et zoom en bas à gauche, avec contraste suffisant. Les onglets, le retour, le recentrage, le zoom, la grille, Demeure et le mode opérateur restent des commandes accessibles ; leurs panneaux n'enlèvent plus deux bandes de hauteur à la carte.
• Donner la priorité des clics aux boutons. Le reste de la carte, y compris les zones assombries, accepte déplacement et zoom. Garder les glissements successifs et le relâchement hors zone validés en beta.006.

Acceptation : captures à 640×480, 1280×720 et écran large, plusieurs échelles GUI ; carte visible jusque sous les habillages, coordonnées lisibles, commandes sans chevauchement. Vérifier transparence du vide, brouillard, panorama déplacé, zone sans relevés, mode verrouillé, vue opérateur, révocation et retour parent. La grille et les empreintes restent alignées avec la carte sur tout l'écran.

Données : rendu client et disposition ; conserver les relevés et identifiants existants. Aucun format de sauvegarde ou changement de génération attendu. Hors lot : minimap, marqueurs, partage et nouveaux droits de claim.

PROG-02A — Minage et vein mining

Branche : codex/progression-vein-mining. Implémentation : beta.008, contrat et vérifications. Résultat : acheter des rangs de Minage et extraire un groupe de blocs par un geste volontaire, prévisualisé et limité par la progression du serveur.

• Remplacer « À venir » par rang, effet présent, prochain effet et coût. Minage reste une compétence dans la colonne gauche.
• Reprendre la sélection historique de blocs identiques connectés par leurs faces, son aperçu, son arrêt et ses limites. L'orientation en plan, évoquée dans la vision, ne doit pas être annoncée comme déjà fournie par cet algorithme de veine ; son éventuel ajout demande un mode explicite.
• Une touche configurable maintenue avec le clic gauche engage l'action. Une souris sans bouton latéral doit pouvoir l'utiliser ; B garde le Blocodex. Prévoir le choix d'une taille inférieure à celle autorisée par le rang.
• Le serveur recalcule la sélection, applique les règles des outils, la durée, la durabilité, la faim, les enchantements et les permissions de chaque bloc. Interrompre au relâchement, changement d'outil, mort ou déconnexion.
• Utiliser les actions natives pour les drops et l'XP ; une casse effective produit une seule découverte/statistique/trace Demeure. La sélection et l'aperçu ne produisent aucune récompense ni influence.

Référence historique, à équilibrer : rangs 0–7, limites 1 / 4 / 8 / 16 / 32 / 64 / 128 / 256, recherche à sept blocs sur chaque axe. Le multiplicateur de vitesse historique va de 25 % à 100 %. Cette lenteur initiale, ces quantités et les anciens coûts ne constituent pas encore un équilibrage approuvé pour la bêta. Les valeurs d'essai seront documentées.

Acceptation : rang zéro, achat et plafond, outil adapté/inadapté, usure jusqu'à rupture, Fortune/Silk Touch, cible indestructible, coffre exclu, arrêt immédiat, deux joueurs sur la même veine, chunk non chargé, permission refusée et requête client demandant un rang supérieur. Son du groupe maîtrisé et aperçu cohérent.

Données : rédiger le contrat d'évolution des rangs et de l'historique avant le code ; relire beta.003–006 sans changer les achats, aptitudes, identité ou couleur. Reconnexion, redémarrage et mort conservent les rangs acquis.

PROG-02B — Construction et vein building

Branche : codex/progression-vein-building. Implémentation : beta.009, contrat et vérifications. Résultat : acheter des rangs de Construction puis poser une surface annoncée par l'aperçu, en consommant les blocs réellement utilisés.

• Activer la compétence de gauche avec rang, effet et coût. Reprendre les plans historiques : face cliquée et orientation du joueur déterminent sol, mur ou plafond et ordre de pose.
• Partager les conventions de commande avec Minage : touche reconfigurable et clic droit, taille ajustable dans le plafond acheté, arrêt au relâchement. La touche B historique du Builder doit être remplacée.
• Recalculer la sélection sur le serveur ; poser par l'action Minecraft normale pour respecter orientation, supports, collisions et permissions. Revalider chaque cible si le monde change pendant l'opération.
• Consommer seulement les objets effectivement posés ; arrêter proprement à l'épuisement du stock. Préserver les refus et les contenus des blocs. Chaque pose réussie alimente une seule fois Blocodex, statistiques et Demeure.
• Séparer clairement capacités de construction, mode créatif et statut opérateur. Un opérateur en survie ne reçoit pas des matériaux gratuits.

Référence historique, à équilibrer : rangs 0–7, diamètres 1 / 3 / 5 / 7 / 9 / 11 / 13 / 15 ; cadence de survie historique 0,5 pose par tick. La portée 3–5,5 blocs historique est distincte du diamètre du plan. Décider explicitement si la compétence reprend aussi cette portée, sans modifier la portée d'attaque. Coûts et cadence à éprouver avec Minage.

Acceptation : sol/mur/plafond, quatre orientations, dalles et escaliers, stock insuffisant, cible occupée, annulation en cours, changement d'objet, limite de chunk chargé, deux bâtisseurs concurrents et permission refusée. L'aperçu ne consomme pas d'objet ; une pose refusée n'est pas comptabilisée. Les rangs et achats survivent à la mort et au redémarrage.

PROG-02C — Terminer la compétence Inventaire

Branche : codex/progression-inventory. Implémentation : beta.010, contrat et vérifications. Résultat : une sixième compétence achetable et utile, avec une capacité réelle, la même côté serveur et dans tous les menus.

Cadrer le nombre de rangées, le rôle de la barre rapide et les plafonds. La proposition historique d'une à six rangées reste une référence à confirmer, pas l'état actuel de beta.006. Les parties déjà remplies exigent un contrat d'adoption : activer un petit inventaire ne peut pas supprimer des objets.

Acceptation : clic, glisser-déposer, déplacement rapide, collecte, fabrication, conteneurs, mort, keepInventory, reconnexion et rechargement, sans duplication ni disparition. Contrôler le protocole des emplacements ; un client ne peut pas utiliser une case verrouillée. Préparer le cas de réduction au New Game+ selon CYCLE-01, sans activer un reset dans ce ticket.

PROG-03 — Rendre la progression achevable

Branche prévue : codex/progression-complete. Résultat : un nouvel habitant peut comprendre, financer et terminer le parcours retenu ; le serveur sait dire précisément ce qu'il lui manque.

• Les six compétences sont fonctionnelles et testées ensemble. Fixer rangs, plafonds et coûts, et éprouver les interactions Faim/Minage/Construction.
• Vérifier les aptitudes présentes, leurs conditions d'achat et leur conservation au prochain cycle. Les aptitudes futures gardent leurs tickets propres et ne retardent pas la fin des six compétences ; aucun bouton achetable ne promet un effet absent.
• Donner une indication accessible pour obtenir les premiers niveaux. Choisir entre tutoriel des sources d'XP existantes et objectifs de découverte à usage limité, puis vérifier un début de partie en survie sans commandes opérateur. Toute récompense de première découverte doit définir sa persistance au NGP.
• Appliquer la condition confirmée six compétences au maximum et afficher les compétences encore incomplètes dans le Blocodex. Le contrôle repose sur les rangs serveur. Des aptitudes non achetées n'empêchent pas le NGP.

Acceptation : cinq compétences maximales et une incomplète refusent le NGP ; les six maximales l'autorisent même si des aptitudes restent non acquises. Vérifier parcours début/milieu/fin, insuffisance d'XP, achats doublés, mort avant et après achat, déconnexion, sauvegarde et reprise. Le futur NGP reste inaccessible tant que ses prérequis ne sont pas remplis. Documenter les réglages retenus et les limites ouvertes avant de déclarer la progression terminée. Fournir un MRpack d'essai de cette boucle complète.

FACTION-01 — Factions persistantes, capacités et prestige

Branche prévue : codex/factions-foundation. Résultat : créer, rejoindre et administrer une faction avec des identités stables, et expliquer les capacités liées au prestige dans le Blocodex.

Définir rôles, invitations/acceptation, départ, transfert et dissolution, ainsi que la distinction entre couleur d'habitant et identité de faction. Implémenter les charges/places selon CYCLE-01 ; leurs montants et bénéficiaires ne sont pas déduits des anciens « slots ». Fournir l'opération serveur qui recevra la récompense d'un cycle une seule fois ; NGP-01 en sera le déclencheur.

Acceptation : au moins deux habitants, invitations concurrentes, absence de l'administrateur, déconnexion, rechargement et capacité épuisée. Un reset personnel ne peut pas effacer implicitement une faction ou ses membres. La progression ordinaire, les permissions opérateur et les rôles de faction restent distincts. Aucun droit de modification de terrain n'est déduit d'une empreinte Demeure ou de l'appartenance à une faction.

NGP-01 — Premier cycle complet

Branche prévue : codex/new-game-plus. Résultat : un habitant éligible termine son parcours, choisit de recommencer, retrouve ses aptitudes et reçoit l'effet de prestige/faction convenu.

• Afficher avant le choix ce qui est conservé, remis à zéro et archivé. Le déclenchement est volontaire et validé côté serveur.
• Appliquer ensemble la nouvelle progression, le traitement d'inventaire et l'effet de prestige/faction. Identifier le cycle pour qu'une répétition de requête ou une reprise après interruption ne donne pas deux récompenses.
• Garder la mort ordinaire séparée ; annuler une demande ne modifie aucune donnée. Le caractère individuel du recommencement ne permet pas de déduire une régénération du monde commun.
• Enregistrer un événement daté de cycle, avec identifiants stables d'habitant et de faction lorsque pertinent, pour la mémoire du serveur et le futur site. Ce lot ne construit pas la connexion Web.

Acceptation : premier puis deuxième cycle, une compétence sous le maximum, six compétences au maximum sans toutes les aptitudes, aptitudes conservées, compétences remises à leur départ décidé, objets traités sans perte, faction existante, répétition de requête, interruption et redémarrage. Tester la reprise à chaque étape de la transition ; aucune récompense de découverte ou de prestige ne doit être encaissée deux fois pour un même événement.

Après ce jalon

CLAIM-01 traitera la réservation et la protection des chunks à partir des factions et d'un contrat dédié : emprise, capacités, droits, conflits, abandon et incidence du prestige. La grille et Demeure restent des lectures du monde jusqu'à ce ticket. Mini-carte, marqueurs, partage, recettes, plans et autres aptitudes gardent leurs tickets propres. Leur absence ne bloque pas le New Game+ lorsque les six compétences sont au maximum.

Le cadrage CLAIM-01 — titres de propriété temporaires précise les décisions du 15 septembre 2026 : un titre couvre un seul chunk ; il faut renommer l'objet puis faire un clic droit pour revendiquer le chunk. Un autre titre portant le même nom permet d'étendre la même propriété, y compris à un chunk séparé, sans revendiquer les chunks intermédiaires. Les titres restent attachés aux chunks ; une réserve de saphirs consommés successivement entretient leur protection en temps réel, même lorsque le joueur est déconnecté, tant que le serveur tourne. À la fin de la période payée, sans assez de saphirs pour renouveler, la protection disparaît immédiatement. Acquisition des titres, tarifs d'entretien, paliers, durée des périodes, traitement des arrêts du serveur et droits de réservation sans protection restent à décider ; ce mécanisme n'est pas encore implémenté.

Références et validation des livraisons

La référence historique est consultée en lecture seule dans ../26.2/sanctuary : contrat de progression, limites par rang, sélection des veines et plans de pose. Ces sources attestent les mécanismes cités, sans prouver leur portabilité. La cible de travail reste celle de gradle.properties, actuellement 26.3-pre-2.

Pour chaque ticket de code : contrat de données préalable si nécessaire, libellés FR/EN, ./gradlew check build, tests natifs ciblés et parcours client adaptés au comportement, puis ./gradlew assemblePack et MRpack immuable lors d'une livraison. Incrémenter mod et pack ensemble. Les actions groupées respectent les protections effectives ; aucun test ne doit inventer des claims absents. Conserver les mondes personnels et les anciens artefacts.