sanctuary-beta/docs/backlog.md

Backlog de démarrage

Ce fichier prépare les premiers tickets à publier sur le Git du projet. Aucun identifiant ci-dessous n'est un numéro d'issue distante et aucun ticket n'est présumé publié. Les identifiants BOOT-* et WG-* servent seulement à relier les travaux tant que les issues n'existent pas.

Le document de vision conserve les idées à long terme. Ce backlog organise uniquement le socle et les premiers incréments de génération. Une fonctionnalité n'est considérée comme livrée que lorsque son résultat et sa validation figurent dans le dépôt ou dans son issue.

Premier jalon : un monde Sanctuary jouable

État au 8 septembre 2026 : BOOT-01 et WG-01 sont réalisés dans le premier commit. Le prototype WG-02 et l'initialisation du spawn WG-03 sont implémentés et passent les tests serveur décrits dans Validation. Les essais visuels, multijoueurs et de redémarrage indiqués dans ce document restent à faire avant de clôturer tous leurs critères. WG-04 à WG-07 restent proposés.

Résultat visé : un client et un serveur Fabric compatibles peuvent ouvrir un monde Sanctuary, plusieurs joueurs y arrivent sur une même île sûre et les chunks extérieurs restent vides. La génération est reproductible et ses limites sont documentées.

BOOT-01 — Initialiser le dépôt et la construction Fabric

But : disposer d'une base clonable et vérifiable pour travailler par tickets.

Critères d'acceptation :

• Les versions réellement utilisées de Minecraft, Java, Fabric Loader, Fabric API et de l'outillage sont fixées et documentées.
• La cible souhaitée 26.3 est distinguée de la version exécutée si sa disponibilité oblige à utiliser une version de développement ou à différer la migration.
• Une commande reproductible construit le mod ; le README explique le lancement et les prérequis.
• Les métadonnées identifient Sanctuary sans annoncer les fonctionnalités de la vision comme déjà présentes.
• Le dépôt contient les consignes de contribution et des modèles de tickets ; les binaires, caches et sauvegardes de jeu ne sont pas suivis par accident.

WG-01 — Auditer le générateur Sanctuary 26.2

But : identifier précisément le code et les ressources utiles avant de les adapter.

Critères d'acceptation :

• Les fichiers, commits ou références historiques consultés sont cités dans une note d'audit.
• La note explique l'algorithme de l'île, le vide, le point d'apparition, les dépendances et les paramètres structurants.
• Les éléments réutilisables, les défauts connus et les changements d'API de la cible sont séparés.
• La réutilisation de ressources est accompagnée de leur origine et de leur licence connue ; les inconnues sont explicitement notées.
• L'audit n'installe ni ne déploie l'ancienne version et ne modifie pas ses sauvegardes.

WG-02 — Enregistrer un monde Sanctuary avec île principale et vide

Dépendances : BOOT-01, WG-01.

But : créer le premier terrain identifiable comme Sanctuary.

Critères d'acceptation :

• Une procédure documentée permet de créer un monde utilisant le générateur Sanctuary sur la version testée.
• Une île principale est générée au point de départ prévu ; ses coordonnées, son altitude et ses dimensions sont explicites.
• Au-delà de son emprise, les chunks de contrôle sont vides, sans fondation ni terrain vanilla inattendu.
• Une même seed et une même configuration donnent les mêmes blocs aux positions de contrôle.
• Les jointures entre chunks voisins ne créent pas de fissures ou de parois artificielles dues à une discontinuité du calcul.
• Un monde Minecraft ordinaire reste créable sans sélectionner Sanctuary.

WG-03 — Assurer une arrivée commune et un redémarrage sûr

Dépendance : WG-02.

But : éviter qu'un nouveau joueur apparaisse dans le vide et vérifier le comportement multijoueur.

Critères d'acceptation :

• Le spawn du monde se situe sur une surface stable de l'île, avec l'espace nécessaire au joueur.
• Deux nouveaux joueurs arrivent dans la zone de départ commune, sans traverser le sol ni apparaître hors de l'île.
• Le comportement après une mort sans lit est vérifié ; l'ajout ultérieur des Backrooms n'est pas requis pour ce ticket.
• Après sauvegarde et redémarrage, le générateur, la seed et le spawn sont conservés.
• Un scénario manuel reproductible couvre le client et le serveur dédié, avec la version et la seed utilisées.

Deuxième jalon : des continents d'essai reproductibles

Ce jalon fournit un outil de développement du terrain. L'interface d'expansion et son coût collectif viendront dans des tickets distincts, lorsque la génération sera satisfaisante.

WG-04 — Décrire et placer un continent d'essai

Dépendance : WG-03.

But : pouvoir générer une terre suspendue à une direction, une distance et une taille explicites.

Critères d'acceptation :

• Un schéma décrit au minimum l'identifiant, le centre ou la direction et la distance, les dimensions, l'altitude et la seed du continent.
• Une configuration ou commande de développement documentée crée un continent reproductible.
• Les paramètres invalides et les chevauchements interdits sont rejetés avec un message compréhensible.
• Des limites de taille et de coût de génération sont définies à partir d'une mesure réelle.
• Le continent et ses paramètres restent identiques après rechargement du monde.

WG-05 — Ouvrir une expansion sans écraser l'existant

Dépendance : WG-04.

But : garantir que l'évolution du monde préserve les constructions et l'exploration.

Critères d'acceptation :

• La politique envers les chunks déjà générés est décidée et documentée avant l'implémentation : refus, réservation préalable ou mécanisme explicite de modification.
• Une nouvelle expansion ne remplace aucun bloc joueur silencieusement.
• Répéter la même demande ne crée pas de duplicata et ne décale pas les continents existants.
• L'état des expansions survit à un redémarrage et contient une version de format permettant de prévoir les migrations.
• Une interruption entre réservation et génération est simulée ; la reprise ou le refus reste cohérent et expliqué.

WG-06 — Ajouter reliefs, perforations et eaux retenues

Dépendance : WG-04 ; combiner avec WG-05 avant l'usage sur une sauvegarde jouée.

But : donner aux continents une géographie reconnaissable au-delà d'une simple masse de pierre.

Critères d'acceptation :

• Un jeu de seeds de référence montre des reliefs, montagnes, ravins et perforations traversantes.
• Des bassins accueillent lacs ou océans, et un premier type de rivière flottante est démontré.
• L'eau ne se répand pas de manière incontrôlée dans le vide lors du chargement et des mises à jour de blocs du scénario testé.
• Les profils du dessous et les bords du continent sont inspectés visuellement depuis les airs.
• La génération est mesurée sur une emprise et une machine indiquées ; les valeurs observées sont consignées, sans annoncer un objectif de performance non mesuré.

WG-07 — Introduire un premier biome distinct et une structure

Dépendance : WG-06.

But : valider les points d'extension avant d'ajouter un grand catalogue de contenus.

Critères d'acceptation :

• Le ticket choisit un premier biome, par exemple le Black Desert, avec des règles de surface et d'ambiance explicites.
• Une petite structure de référence se place sur un terrain compatible, sans flotter accidentellement ni détruire une construction existante.
• Le lien entre biome, végétation, ressources et règles de placement est documenté.
• La reprise du catalogue TerraMix natif d'Another World 26.2 est évaluée séparément ; « plus de cent biomes » reste une ambition tant que son adaptation n'est pas vérifiée.
• Les limites des futures zones Lost Cities et des structures uniques sont identifiées sans imposer leur livraison dans ce ticket.

Réserve de thèmes futurs

Ces thèmes servent à retrouver la vision, pas à demander leur implémentation immédiate. On en extrait un ticket seulement lorsqu'il devient utile au prochain incrément jouable.

Thème	Contenus à découper plus tard
Distribution et apparence	packwiz, mods communautaires, resource packs, shaders, icône, chargement, crédits et attributions
Expansion collective	deposit boxes, objectifs de production, ordinateur d'expansion, ouvertures persistantes
Progression	capacités, XP, inventaire, prestiges débloquant des slots de factions, recettes et advancements, capes et familiers
Économie	gemmes, mailbox, shop, offres horaires, bourse du navet (achat à la loterie du dimanche, revente au shop pendant la semaine), black market, catalogue, coffre-fort et drill
Groupes et métiers	couleurs, équipes temporaires, factions et slots liés aux prestiges, cloches et bannières, villageois et copper golems
Production et construction	convoyeurs, stockage, terminaux, ordinateur 8 bits, vein mining/building, plans et prefabs
Dimensions	cavernes, Alpha, Backrooms, indoors, salles secrètes et récupération des objets perdus
Faune et combats	zombies, fantômes, baleine, creepers, poules rares, Mooblooms, noms, armes et explosifs
Mobilité	waystones, téléporteurs, ziplines, grappin, aéronefs, Magic Carpet et interactions physiques
Temps et histoire	temps réel, calendrier, événements, loterie, étoiles, constellations, cube et sept boules
Objets et surprises	caméra, disque blanc, chunky, particuleur, lucky blocks et lootboxes
It's Alive !	agriculture localisée, ustensiles, recettes, fermentation, affinage et pages secrètes
Only Fun	interactions potaches, chanvre, anniversaires et intégration aux événements
Master Key	permissions communes, configuration, diagnostic et réparation du serveur

Définition pratique d'un ticket terminé

Un ticket contient un résultat observable, un périmètre limité et des critères d'acceptation vérifiables. Sa conclusion indique le comportement livré, la version testée, les vérifications réellement exécutées et les limitations qui subsistent. Les nouveaux besoins découverts deviennent de nouveaux tickets plutôt que des ajouts implicites à tous les systèmes.