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.

Créer un duel (deux inscrits) ou une arène (sans plafond de participants), à l'emplacement de l'organisateur dans sa dimension.
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.
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.
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.
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 : 9 592 283 octets.
Pack Test, monde plat rapide : 9 611 218 octets.
Reçu des artefacts et SHA-256.

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.

10 KiB Raw Permalink Blame History Unescape Escape