Files
sanctuary-beta/docs/property-titles-ticket.md
2026-09-16 11:41:27 +02:00

176 lines
10 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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](vision.md#les-trois-gemmes) 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](versioning.md) 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.