176 lines
10 KiB
Markdown
176 lines
10 KiB
Markdown
# 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.
|