sanctuary-beta/docs/property-titles-ticket.md

CLAIM-01 — Titres de propriété temporaires

Ticket local — conception en cours, décisions du 15 septembre 2026. Ce document prépare le résultat jouable ; la protection n'est pas implémentée. Branche réservée : codex/property-titles. Le checkout existant reste sur sa branche de travail pour préserver les travaux en cours. Aucun numéro de livraison réservé et aucune issue distante publiée.

Intention et décisions confirmées

Le joueur achète des titres de propriété temporaires donnant des privilèges sur un terrain. Il choisit un niveau de protection et constitue une réserve de saphirs pour l'entretenir. Le titre reste attaché au chunk ; la protection accordée est temporaire et renouvelable.

Un titre couvre un seul chunk, soit une emprise horizontale de 16 × 16 blocs alignée sur la grille Minecraft. Un même titre ne couvre pas plusieurs chunks à la fois. Son entretien utilise ensuite des saphirs.

Le titre est un objet à renommer avant utilisation. Le joueur fait un clic droit avec ce titre dans le chunk à revendiquer. Le nom donné au titre sert de nom à la propriété ; utiliser un autre titre portant le même nom dans un autre chunk étend cette propriété. Chaque chunk ajouté nécessite son propre titre, conformément à la règle « un titre = un chunk ». Les chunks d'une même propriété peuvent être séparés : aucune contiguïté n'est requise. Les chunks situés entre eux ne sont pas revendiqués par cette extension. Le moyen de renommer l'objet reste à préciser.

Les saphirs sont consommés successivement pour entretenir le niveau de protection choisi. Les titres restent attachés aux chunks. À niveau et emprise identiques, ajouter des saphirs prolonge l'entretien disponible. Cette décision remplace la consommation successive de titres envisagée au début de la discussion.

L'entretien se fait en temps réel, y compris lorsque le joueur est déconnecté, tant que le serveur tourne. Il ne dépend pas du temps de présence du titulaire. Le traitement du temps écoulé pendant un arrêt du serveur reste à décider séparément.

La protection disparaît immédiatement à épuisement de la couverture : lorsque la dernière période payée se termine et que la réserve ne contient pas assez de saphirs pour renouveler, aucun délai de grâce ni baisse progressive ne s'applique. Une réserve vide ne raccourcit pas la période déjà payée. Le titre reste attaché au chunk ; la possibilité pour un autre titulaire de revendiquer ce chunk sans protection reste à décider.

La protection envisagée rend les blocs plus longs à miner par les autres. Le créateur évoque un premier ralentissement doublé et une protection pouvant aller jusqu'à des blocs presque incassables, voire incassables. Les valeurs, les bénéficiaires et la limite exacte restent à décider.

Modèle proposé à préciser

Séparer dans le fonctionnement et l'interface :

• Niveau choisi : résistance appliquée et coût d'entretien associé.
• Réserve : saphirs disponibles pour les renouvellements successifs.
• Échéance en cours : moment de la prochaine consommation ou fin de couverture, selon le contrat temporel à retenir.

Proposition : un niveau plus élevé coûte davantage de saphirs. Le coût et la durée d'une période payée ne sont pas fixés ; l'emprise est d'un chunk par titre. La gestion des réserves pour plusieurs chunks reste à préciser. La consommation en temps réel est confirmée ; une consommation supplémentaire provoquée par les attaques n'a pas été demandée.

Pour le premier ralentissement, l'interprétation proposée est un temps de minage multiplié par deux pour un joueur non autorisé, à bloc, outil et conditions identiques. Cela reste à confirmer. Les privilèges supplémentaires du titulaire ne sont pas encore définis.

Économie : entretien en saphirs, acquisition à définir

Le saphir est retenu pour entretenir la protection des titres déjà posés. La vision lui attribue déjà la réservation et la sauvegarde de quantités limitées d'objets dans le catalogue. Ce nouvel usage prolonge son rôle de conservation, sans supposer cette économie déjà disponible.

Restent à choisir : monnaie et prix d'achat initial des titres, lieu et geste d'achat, obtention effective des saphirs, tarifs d'entretien, partage et éventuel transfert. Le titre utilisable en jeu est un objet renommable ; le registre serveur et le dépôt des saphirs dans la réserve restent à définir.

Arbitrages nécessaires au premier lot jouable

• Emprise d'un chunk par titre confirmée ; préciser la portée verticale, les dimensions concernées, le nombre maximal de chunks par titulaire et les règles de chevauchement. Choisir une réserve par chunk ou une réserve commune avec des règles explicites d'affectation des saphirs et de renouvellement lorsque le solde ne suffit pas pour tous les chunks.
• Création et extension par titre renommé puis clic droit confirmées ; préciser le moyen de renommage, les noms admis, leur comparaison et les collisions entre titulaires. Les chunks séparés sont autorisés. Définir comment départager le chunk du joueur et celui du bloc visé à une frontière, et l'effet d'un clic dans un chunk déjà revendiqué. Le nom sert au regroupement ; le serveur doit aussi vérifier les droits d'extension pour qu'un nom identique ne permette pas de prendre le contrôle de la propriété d'un autre titulaire.
• Titulaire : joueur, faction ou les deux ; droits des membres, invités et tiers, et rapport éventuel au prestige. Demeure mesure l'habitation et ne vaut pas attribution d'un titre.
• Paliers de résistance, privilèges et incassabilité éventuelle ; articulation avec les outils, enchantements et aptitudes de minage existants.
• Coût en saphirs et durée réelle de chaque période selon le niveau ; financement de la première activation ; traitement des chunks déchargés et du temps écoulé pendant les arrêts du serveur. La déconnexion du joueur ne suspend pas l'entretien.
• Changement de niveau : prise d'effet, traitement de la période payée et du temps restant, pour éviter de gagner de la couverture par des changements répétés.
• Avertissement avant épuisement, droits de réservation d'un titre sans protection et réactivation après réapprovisionnement. Le titre reste attaché au chunk et la protection disparaît immédiatement en fin de couverture.
• Abandon, transfert, conflits de réservation et devenir du stock restant.
• Portée de la protection face aux explosions, pistons, fluides, mobs, inventaires et actions groupées ; distinguer les droits d'interaction de la résistance au minage.

Réception de la future implémentation

Le premier lot doit permettre d'obtenir des titres par la voie retenue, réserver un terrain, choisir sa protection, approvisionner la réserve en saphirs et observer leur consommation successive ainsi que l'effet sur le minage, avec conservation du titre attaché au chunk.

• Renommer un titre « Verger » et faire un clic droit dans un chunk libre crée la propriété « Verger ». Utiliser un autre titre de même nom dans un second chunk admissible étend la même propriété à ce chunk. Une autre propriété, nommée différemment, conserve son emprise.
• Répéter l'extension dans un chunk séparé du premier par des chunks libres : les deux chunks appartiennent à la même propriété, sans revendiquer ni protéger les chunks intermédiaires.
• Un titre non renommé ne revendique aucun chunk et explique le renommage nécessaire. Un refus d'extension ou un conflit ne dépense pas de titre et ne modifie pas de terrain ; vérifier les collisions de noms entre joueurs.
• Deux joueurs vérifient les droits et le ralentissement de chaque palier, à conditions identiques, ainsi que les limites du terrain.
• Un titre couvre exactement le chunk désigné : sa protection ne déborde pas sur le chunk voisin. Couvrir deux chunks nécessite des titres distincts ; renouveler le même chunk ne modifie pas son emprise.
• Ajouter des saphirs à niveau et emprise constants prolonge l'entretien sans modifier la résistance choisie. Un renouvellement conserve la couverture et le titre attaché, sans exiger un nouveau titre pour le même chunk.
• Déconnecter le titulaire en laissant le serveur tourner : à son retour, la réserve et la couverture reflètent le temps réel écoulé, y compris si plusieurs renouvellements en saphirs ont eu lieu pendant son absence.
• Épuisement, réapprovisionnement et changement de niveau suivent les règles arrêtées, avec un état et une échéance compréhensibles en FR/EN.
• Avec une réserve vide ou insuffisante pour renouveler, vérifier la protection jusqu'à la fin de la période payée, puis sa disparition immédiate à l'échéance, y compris lorsque le titulaire est déconnecté. Le titre reste attaché ; le minage retrouve les règles ordinaires applicables, sans résistance résiduelle provenant des titres.
• Achat, consommation et droits font autorité côté serveur. Des requêtes répétées ou simultanées et un redémarrage ne dupliquent ni dépense, ni titre, ni saphir, et ne remettent pas gratuitement la durée à zéro.
• Un contrat de sauvegarde et de migration explicite précède toute donnée persistante. Le chargement d'une ancienne partie n'attribue aucun terrain implicitement ; aucune régénération de chunks n'est nécessaire.
• Tester les interactions retenues ci-dessus et les actions groupées, puis lancer ./gradlew check build. Une livraison de distribution exige aussi ./gradlew assemblePack et le versionnement mod/pack.

État actuel

L'emprise est fixée à un chunk par titre. Le titre est renommé puis utilisé par clic droit ; un même nom permet d'étendre la propriété à un autre chunk. Les chunks d'une même propriété peuvent être séparés. Les titres restent attachés aux chunks. La consommation successive de saphirs en temps réel pour maintenir un niveau choisi, y compris lorsque le joueur est déconnecté, est confirmée. La protection disparaît immédiatement lorsque la couverture est épuisée. Les autres arbitrages sont explicitement ouverts ou proposés ci-dessus. Ce cadrage est documentaire : aucun code, binaire, monde ou format de sauvegarde modifié ; aucun test de gameplay exécuté pour ce ticket.