sanctuary-beta/docs/arenas-beta073.md

# ARENA-01 — duels publics, arènes et paris — beta.073

Branche `codex/familiar-arenas-beta073`. Ticket du 15 septembre 2026.
**Implémenté, client natif, compilation et archives locales vérifiés.**

## Parcours en jeu

**Pause → Progression → Duels et arènes** ouvre la liste publique. Le même
accès figure dans le menu Duel historique. Aucune aptitude de familier ni
prestige n'est requis pour organiser un combat entre joueurs.

1. Créer un **duel** (deux inscrits) ou une **arène** (sans plafond de
   participants), à l'emplacement de l'organisateur dans sa dimension.
2. Choisir **familiers seuls**, **joueurs seuls**, ou **joueurs avec familiers**.
   Choisir un rayon de 24, 48 ou 96 blocs, une durée de 3, 5 ou 10 minutes,
   et l'autorisation de la nourriture, des potions et des perles. Les armes,
   boucliers et munitions restent utilisables. Les familiers gardent leurs
   statistiques, personnalités, ressources et recharges réelles.
3. Choisir l'objet commun dans l'inventaire débloqué, et une mise d'entrée
   de 0 à 64 objets. Zéro signifie gratuit. Par défaut, l'objet est l'émeraude.
   Les composants natifs doivent correspondre : un objet renommé ou un
   contenant rempli n'est pas équivalent à sa version vierge. La création
   inscrit l'organisateur et prélève sa mise après validation serveur.
4. Les autres joueurs consultent les règles, viennent dans le périmètre et
   s'inscrivent. Chacun valide **Prêt**. Tout changement de la liste invalide
   les validations. L'organisateur lance quand tous sont présents et prêts.
5. **Dix secondes de préparation**, puis chacun pour soi. Les inscriptions
   et les paris sont fermés dès le lancement de la préparation.

La liste présente les coordonnées, la dimension, les inscrits, les pots et
l'état du combat. Elle contient aussi les duels historiques à invitation,
qui gardent leurs deux mises libres et leur double validation. Pour ces seuls
duels historiques, le marché des spectateurs utilise des émeraudes ; les mises
historiques des deux adversaires restent dans leur menu existant.

Les annonces d'ouverture, de lancement et de résultat vont dans le chat du
serveur. Les combats terminés restent affichés cinq minutes. Les mises dues
restent disponibles aussi longtemps que nécessaire. La consultation se fait
par pages de douze entrées ; la pagination ne limite pas les inscriptions.
Il n'y a ni téléportation de spectateur, ni création automatique de terrain :
la carte de playtest se prépare normalement à côté.

## Combat et règles du monde

- **Joueurs : morts réelles**, selon le choix du créateur. Aucune santé
  artificielle à la fin, aucun inventaire restauré par l'arène. Inventaire,
  perte d'expérience, règles de conservation et tête-tombe suivent Sanctuary
  et les règles effectives du monde. La mort élimine après le chemin natif
  de création de la tombe.
- **Familiers : K.-O. existant**, santé persistante et récupération habituelle.
  En mode mixte, le K.-O. du familier laisse son joueur combattre. La mort du
  joueur élimine son camp. En mode familiers seuls, les propriétaires ne sont
  pas des cibles et ne frappent pas directement les familiers adverses.
- Le dernier camp encore en lice gagne. Abandon, déconnexion pendant le
  combat, changement d'individu, rappel du familier, sortie du périmètre ou
  passage en créatif/spectateur éliminent. Le rayon est une distance 3D au
  centre annoncé : l'altitude compte également.
- Une interruption du serveur, un rechargement du catalogue, l'expiration des
  inscriptions ou une durée écoulée sans vainqueur rembourse les mises.
  Un joueur déjà éliminé qui se déconnecte ne termine pas le combat des autres.
- Avant départ, se désinscrire rembourse son entrée et les paris placés sur
  soi. Les autres inscriptions restent ouvertes. Le départ de l'organisateur
  annule l'événement entier. Les duels historiques gardent leur contrat
  d'interruption/refund antérieur.
- La permission PvP du combat ne vise que les adversaires inscrits en lice,
  même si le PvP général est désactivé ou s'ils sont de la même faction.
  Les dégâts directs ne franchissent pas cette frontière ; les familiers
  hors combat n'apportent pas leur assistance aux combattants.
- Pose, utilisation et casse de blocs par les combattants sont désactivées,
  y compris les gestes de minage/construction groupés déjà commencés.
  Cela ne transforme pas le périmètre en claim : les mécanismes du monde,
  cosmétiques, pièges ou interventions d'opérateurs restent ceux de la map.

## Paris en objets

La mise d'inscription est identique pour tous ; son pot revient au vainqueur.
Les spectateurs choisissent un inscrit et déposent une quantité libre de
l'objet commun, jusqu'à 3 456 unités par geste et dans la limite de leur
inventaire débloqué. Plusieurs gestes sont possibles avant le lancement.
Il n'y a pas de commission.

Le pot des spectateurs est partagé **au prorata des mises gagnantes**. Les
unités indivisibles restantes sont réparties dans l'ordre stable des UUID.
Exemple : 4 objets sur A, 2 autres sur A et 3 sur B ; si A gagne, les deux
parieurs gagnants récupèrent respectivement 6 et 3 objets. Si personne n'avait
misé sur le vainqueur, les paris sont remboursés.

Un inscrit ne peut pas parier sur son combat. Un parieur ne peut plus s'y
inscrire. Les boutons utilisent des identifiants et des révisions contrôlés
par le serveur ; aucune pile fournie par le client ne sert de preuve de fonds.
Les fonds sont pris uniquement dans les rangées réellement débloquées.

Les gains se récupèrent dans **Duels et arènes**. Un inventaire plein conserve
le solde dans le registre ; libérer même une partie d'une pile permet de le
récupérer progressivement. Aucun paiement ne tombe au sol et un joueur mort
ne peut pas encaisser dans l'inventaire en cours de remplacement.

## Contrat de sauvegarde additif

Aucun registre historique, identifiant d'objet, génération ou monde personnel
n'est converti. Nouveau fichier séparé :
`sanctuary/arena-stakes-v1.json`, schéma 1. Nouveau reçu joueur persistant et
copié à la mort : `sanctuary:arena_receipt`.

Chaque dépôt est écrit avant le débit, puis l'inventaire natif et son reçu sont
sauvegardés ensemble dans `playerdata` et relus. Le journal confirme ensuite
le débit. Chaque résultat répartit la totalité des fonds en une écriture
atomique avant le paiement. Chaque paiement sauvegarde de même l'inventaire
et son reçu avant de retirer la dette du journal. Une collecte partielle garde
le reste et ne repaie pas une tranche déjà reçue.

Au redémarrage, les combats vivants ne reprennent pas : les mises réellement
débitées sont remboursées. Un résultat déjà réparti conserve ses destinataires.
Les dépôts inachevés sont résolus à la reconnexion du payeur d'après son reçu,
sans inventer de crédit. Une erreur disque, un schéma inconnu ou un journal
invalide préserve les fichiers et suspend les transactions.

Le journal a une borne de lecture/écriture de 32 Mio pour détecter les états
anormaux. C'est une limite de stockage des opérations en attente, pas un nombre
maximum de participants. Avant un retour à une ancienne version, terminer
les événements et récupérer les soldes ; sinon restaurer une sauvegarde
complète cohérente, jamais un seul registre ou un seul fichier joueur.

## Vérifications et limites

Minecraft **26.3-pre-2**, Java 25, Fabric API **0.160.0+26.3**.
`Arena073ClientChecks` utilise un client intégré et des joueurs serveur
synthétiques avec connexions natives, dans un monde plat de développement.
Aucun serveur personnel ni EULA de serveur dédié n'est modifié.

La validation couvre trois familiers en combat autonome, des joueurs avec
morts réelles, le mode mixte, les permissions PvP, les paris, le partage exact,
les remboursements, l'inventaire plein et les composants de contenants. Une
arène de 25 inscrits vérifie la pagination sans plafond de participants.
Les menus FR/EN et l'aller-retour réseau du bouton de création sont contrôlés.
Résultat client : **réussi**, `ARENA073_PASS`, 1 min 52 s. Les tests
`Duel054Checks` sont rejoués dans la même session : validation mutuelle, anciennes
mises, projectiles natifs, K.-O., refus d’un projectile tardif et remboursements
passent aussi. La mort pendant les inscriptions libère l’inscription sans
annuler les autres. Le journal est éprouvé avant débit, après sauvegarde du
débit, après sauvegarde du paiement et avec un schéma inconnu. Les essais
conservent les quantités exactes et refusent le schéma inconnu sans réécriture.

Journal client : `build/arena073-workspace/build/arena073-client.log`.
Captures copiées dans `build/arena073-evidence/`.

`./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest`
réussit en **2 min 56 s**, 124 tâches (108 exécutées). Les GameTests serveur
dédiés sont exclus conformément au refus d'accepter leur EULA ; les scénarios
multijoueurs de ce ticket tournent dans le serveur intégré du client natif.

Les **1 689 classes** compilées, les ressources et les sources Java correspondent
aux archives. Par rapport à beta.072, seules les classes de ce ticket et les
métadonnées de version évoluent ; les ressources existantes, les 88 profils et
le resource pack beta.070 restent identiques. Les **79 nouvelles clés FR/EN**
sont présentes dans les deux langues. Les archives beta.070 à beta.072 restent
inchangées.

- [Pack normal](../build/Sanctuary-beta.073.mrpack) : 9 592 283 octets.
- [Pack Test, monde plat rapide](../build/Sanctuary-Test-beta.073.mrpack) :
  9 611 218 octets.
- [Reçu des artefacts et SHA-256](../build/arena073-artifact.json).

La livraison a été construite dans `build/arena073-workspace`, copie isolée
incluant la version beta.072 vérifiée, puis les seuls changements de ce ticket
ont été réintégrés dans les sources partagées. Aucun canal distant, serveur
personnel ou instance Prism n'est mis à jour.

Ce ticket fournit un outil de playtest. Il ne constitue pas une validation
exhaustive de l'équilibrage des 88 espèces, un benchmark de très grand serveur,
ni une protection compétitive contre les complicités et abandons arrangés.
Les tests de reprise ne simulent pas une panne physique du disque.