sanctuary-beta/docs/capes-gameplay.md

CAPE-01 — Des capes rares aux pouvoirs durables

Ticket local rédigé le 15 septembre 2026 — à arbitrer, puis à implémenter. Cette livraison prépare le ticket ; les effets et l'acquisition décrits ci-dessous ne sont pas implémentés.

• Branche documentaire réservée : codex/capes-ticket.
• Branche d'implémentation prévue : codex/capes-gameplay.
• Aucun numéro beta.xxx réservé pour cette préparation documentaire.

Ce que le joueur doit pouvoir faire

Trouver une cape Sanctuary doit être un événement : un objet très rare, reconnaissable et désirable, que l'on a envie de porter pour son pouvoir. Les capes donnent généralement un bonus passif permanent. Certaines peuvent offrir un pouvoir exceptionnel, voire volontairement « cheaté », si son impact reste acceptable dans la partie collective.

Un catalogue riche est souhaitable : il peut contenir beaucoup de modèles, y compris plusieurs capes très puissantes. La diversité du catalogue et le nombre d'exemplaires en circulation sont deux choix distincts.

Intentions exprimées par le créateur

• Privilégier les bonus durables et l'envie d'utiliser les capes.
• Faire des capes des objets très rares.
• Garder ouverte la possibilité de malus ou de contreparties.
• Accepter des pouvoirs très forts ; leur puissance seule ne les exclut pas.
• Examiner leurs conséquences réelles sur le gameplay et les autres joueurs.
• Envisager la rareté et des périodes de fonctionnement comme moyens d'équilibrage, sans rendre toutes les capes temporaires.

Interprétation proposée de « permanent »

Le pouvoir reste disponible tant que la cape est équipée dans sa case dédiée, sans renouveler une potion ou appuyer régulièrement sur une touche. Posséder la cape dans un coffre ou l'inventaire n'accorde rien. Le retrait arrête son effet ; découvrir plusieurs capes ne donne pas plusieurs bonus permanents au personnage. Cette interprétation reste à confirmer avant le code.

Les exceptions temporaires sont annoncées cape par cape. Proposition : la cape reste un objet de collection après sa période active ; c'est son pouvoir qui s'endort. Une cape consommable ou détruite à l'expiration serait un autre choix, à expliciter, pas une conséquence implicite du mot « temporaire ».

État réel du socle

La beta.018 a livré la case cape, les gestes d'équipement, la sauvegarde et le rendu partagé. Le code consulté contient une seule cape, sanctuary:zero_cape, disponible en créatif ou par /give. Cape Zéro est actuellement visuelle : aucun bonus de gameplay n'est appliqué par son service. Son apparence est provisoire. Le filtre d'équipement et le rendu reconnaissent explicitement cet objet ; un catalogue demande leur extension.

Les lootboxes de capes appartiennent à la vision. Elles ne constituent pas une acquisition en survie déjà livrée. Les familiers, la progression, le portage, les bateaux et le temps réel existent et devront être pris en compte lors des essais des effets retenus.

Périmètre proposé pour un premier lot jouable

Livrer trois capes aux usages distincts, leur description FR/EN, leur effet serveur et une première voie d'obtention rare effectivement jouable. Le choix des trois capes ci-dessous est une proposition de prototype, pas un catalogue approuvé. Les autres modèles pourront suivre par petits lots.

Piste FR / EN	Pouvoir envisagé	Point d'équilibrage à éprouver
Cape de la Brise / Breeze Cape	Bonus permanent de vitesse de déplacement au sol.	Utilité quotidienne ; cumul avec Sprint, potions, familiers et ralentissement du portage. Un bonus simple peut rester sans malus.
Cape du Brasier / Ember Cape	Forte augmentation des dégâts de mêlée ; réduction de la vie maximale comme contrepartie possible.	Gain offensif réellement sensible ; risque assumé et lisible. Vérifier si le malus influe sur les combats ou s'annule facilement par une combinaison.
Cape de l'Éclipse / Eclipse Cape	Vol libre pendant une courte fenêtre récurrente, pouvoir volontairement exceptionnel.	Accès entre îles, exploration, transport et sortie de fenêtre en plein vol. Durée, fréquence et éventuelles restrictions à décider après essai.

Pour chaque cape sélectionnée, renseigner avant implémentation : nom FR/EN, identifiant stable, visuel et provenance, effet chiffré, conditions, éventuel malus, cumuls, acquisition, fréquence d'obtention et règle temporelle complète. Le devenir de Cape Zéro reste une décision distincte : ne pas attribuer automatiquement un nouveau pouvoir aux exemplaires existants.

Ce lot réutilise la case existante. Il ne nécessite ni nouveau monde, ni nouvelle génération, ni économie complète, ni système général de quêtes ou de lootboxes. La source de récompense doit être choisie parmi les mécanismes effectivement disponibles au démarrage ; si elle exige un chantier autonome, la référencer comme dépendance. Un prototype accessible uniquement par /give valide les pouvoirs, mais ne clôt pas le résultat « trouver une cape rare en survie ».

Équilibrage : mesurer ce que la cape change

La rareté ne suffit pas à prouver l'équilibre. Une cape obtenue une seule fois peut servir quotidiennement, être prêtée à tout un groupe ou aider son détenteur à en obtenir d'autres. Une faible probabilité répétable peut finir par produire beaucoup d'exemplaires. À l'inverse, une cape très forte dans un contexte précis peut créer un moment mémorable sans dominer toute la progression.

L'objectif proposé est que plusieurs capes aient des usages désirables, tout en gardant un parcours intéressant sans cape. Les exceptions qui court-circuitent une étape doivent être identifiées et assumées dans leur fiche.

Axe	Essai à réaliser et décision à en tirer
Exploration et vide	Comparer un trajet entre îles sans cape, avec cape et avec moyens de transport existants. Identifier les risques supprimés, les accès anticipés et l'utilité restante des infrastructures.
Combat PvE et PvP	Mesurer dégâts, survie et possibilité de réponse à équipement comparable, puis en combinaison forte. Décider explicitement du traitement PvP ; ne pas le désactiver par défaut dans la conception.
Progression et production	Relever temps gagné, ressources et XP obtenues. Vérifier si une cape rend superflus une compétence, une potion, un familier ou une étape collective.
Cumuls et coopération	Éprouver cape + familier + équipement + potions, portage et prêt entre joueurs. Une seule case cape ne limite pas les autres sources de bonus.
Rareté dans le temps	Estimer les exemplaires et détenteurs après une semaine et un mois, pour un joueur occasionnel, un joueur intensif et un groupe qui mutualise les récompenses.
Plaisir et choix	Observer si les joueurs veulent réellement porter chaque cape, changent selon l'activité ou choisissent toujours la même. Un malus qui conduit à tout laisser au coffre rate l'intention.

Ajuster en priorité le contexte d'utilité, les cumuls, l'acquisition ou la période active lorsqu'ils permettent de conserver un pouvoir spectaculaire. Réduire la puissance ou ajouter un malus reste possible, sans imposer une pénalité à chaque cape. Une cape maudite à malus seul reste une piste à arbitrer.

Rareté et circulation

• Fixer la source, les joueurs éligibles, la fréquence des tentatives, le taux ou quota éventuel et la possibilité de renouveler la récompense.
• Distinguer rareté d'un modèle et rareté de l'ensemble : beaucoup de modèles très rares peuvent rendre l'obtention d'une cape quelconque fréquente.
• Examiner les prêts, échanges, doublons, récompenses rejouées et New Game+. Liaison au joueur et exemplaire unique au serveur sont des options, pas des règles acquises. Les nouveaux arrivants doivent être inclus dans l'essai.
• Documenter les hypothèses de calcul et confronter la rareté attendue à des essais. Un taux de butin bas, seul, n'est pas un critère d'acceptation suffisant.

Périodes d'activité des capes exceptionnelles

Choisir, pour chaque cape concernée, un modèle temporel explicite : fenêtre commune récurrente, durée depuis l'obtention, ou budget de temps d'utilisation. Une période d'obtention limitée et une période d'effet limitée sont distinctes.

Le contrat précise l'horloge utilisée, début, fin, fréquence, temps hors ligne, arrêts serveur et effet des changements de mode Vanilla/Real Time. Une fenêtre liée à une heure réelle doit aussi être essayée du point de vue des joueurs qui ne peuvent pas se connecter à cette heure.

Le serveur fait autorité. Retirer, rééquiper, prêter, mourir, se reconnecter ou redémarrer ne doit pas réinitialiser involontairement une durée ou une recharge. L'interface indique l'état actif/dormant, le temps restant et la prochaine occasion lorsqu'elle est prévisible. Prévoir l'avertissement et la transition de fin : pour le vol, définir une sortie praticable, sans mort surprise ni prolongation illimitée par rééquipement.

Contrat technique à écrire avant le code

• Une seule cape active par joueur ; effets et conditions calculés côté serveur. Une préférence visuelle ne peut pas accorder ou prolonger un pouvoir.
• Appliquer et retirer uniquement la contribution de la cape. Préserver un effet identique venant d'une potion ou d'un familier ; préciser addition, multiplication, priorité ou plafond pour chaque cumul pertinent.
• Traiter changement de cape, mort, tombe, keepInventory, changement de dimension, reconnexion et New Game+ avec les règles d'inventaire existantes. Définir aussi le retrait d'un bonus de vie ou d'un malus de vie maximale, sans soin gratuit par alternance de capes.
• Conserver sanctuary:zero_cape et les emplacements existants. Tout ajout de données persistantes, notamment temporelles, exige un contrat de migration explicite et des essais sur des copies de sauvegardes de développement.
• Décrire en FR/EN bonus, contrepartie, conditions et durée avant équipement. Vérifier le rendu porté et les élytres sur la version Minecraft exacte du lot.

Critères d'acceptation de la future livraison

• Les trois fiches sont complètes ; valeurs, obtention, cumuls et traitement temporel sont fixés, avec les conséquences fortes assumées par la conception.
• Un joueur peut obtenir une cape par la voie de survie retenue, l'équiper, comprendre son pouvoir et constater son effet réel. Une récompense unique ne peut pas être réclamée plusieurs fois par reconnexion.
• Le bonus permanent reste actif au-delà de la durée d'une potion ordinaire tant que la cape est portée. Stockage et retrait ne laissent aucun bonus indu.
• Deux joueurs voient un équipement cohérent ; changement rapide de cape, effet concurrent et prêt ne produisent ni cumul résiduel ni duplication.
• Les limites de période fonctionnent avant, pendant et après la fenêtre, y compris après arrêt/reprise et transfert ; la sortie d'un pouvoir dangereux respecte la transition annoncée.
• Mort/tombe, keepInventory, dimension, reconnexion, redémarrage et New Game+ conservent les objets et durées selon le contrat de migration.
• Un compte rendu compare sans cape, chaque cape seule et les combinaisons les plus fortes, en début et en fin de progression, en solo et à 2–4 joueurs. Il relève gains, abus possibles, circulation attendue et ajustements retenus.
• Aucun pouvoir n'est déclaré équilibré sur la seule base de sa rareté ou d'un build réussi ; les limites de l'essai sont documentées.
• ./gradlew check build passe avec les tests utiles aux effets retenus ; ./gradlew assemblePack vérifie la distribution. Versions et note de livraison suivent le compteur bêta. Parcours client FR/EN vérifié.

Décisions encore ouvertes

1. Confirmer « permanent tant que porté » et le rôle des capes à malus seul.
2. Choisir les trois premières capes, leurs valeurs et le devenir de Cape Zéro.
3. Choisir la première acquisition jouable et la rareté visée, puis décider des échanges et des éventuels quotas.
4. Choisir la règle temporelle des exceptions, leurs cumuls, leur traitement PvP et les étapes de progression qu'elles peuvent volontairement dépasser.

Références vérifiées pour cette préparation

• Vision : progression et récompenses.
• Service actuel des accessoires, filtre et stockage et rendu.
• Catalogue des familiers beta.032, à confronter au code courant lors des essais de cumul.

Validation de ce ticket : lecture du socle, vérification des références locales et relecture du diff documentaire. Aucun essai de gameplay ni build exécuté pour cette rédaction ; les critères ci-dessus concernent la future implémentation.