Plugin SMP : créer les règles qui font ton serveur

Ce qu'est vraiment un serveur SMP

SMP veut dire survie multijoueur : un monde partagé où un groupe construit, se bat et échange pendant des semaines. La survie vanilla te donne le monde. Ce qui transforme un monde en serveur où les gens reviennent, c'est l'ensemble des règles posées par-dessus.

Ces règles sont tout le produit. Deux serveurs peuvent tourner sur la même version, la même génération de monde et la même difficulté, et n'avoir aucun rapport, parce que chez l'un la mort enlève quelque chose pour de bon et chez l'autre elle agace cinq minutes. Ce sont aussi elles qui créent les histoires : une mécanique qui prend quelque chose au perdant, c'est ce qui rend un moment racontable.

Et chacune de ces règles est du code. Minecraft n'a pas de réglage pour les cœurs volés, pas de réglage pour une échelle de grades, pas de réglage pour une zone dans laquelle personne ne peut casser. Un plugin écoute ce qui se passe dans le monde, décide de ce que ça veut dire, enregistre la conséquence, et la réapplique à la prochaine connexion du joueur.

• Le monde est vanilla, les règles sont les tiennes
• Les règles qui enlèvent quelque chose sont celles dont on parle
• Rien de ce qui suit n'existe dans le jeu : tout est un plugin

Les cœurs qui se volent, la mécanique qui définit le genre

La règle tient en une phrase : tu tues un joueur, tu lui prends un cœur. Tu perds tous les tiens, tu es dehors. C'est simple à dire, et c'est la mécanique SMP la plus demandée, parce qu'elle donne un prix définitif à chaque combat.

Côté serveur, c'est moins simple. Le maximum de vie est un attribut porté par le joueur, pas un nombre qui reste posé quelque part : le plugin le règle, et il doit le remettre à chaque connexion, parce qu'une nouvelle session rend les vingt points par défaut. La vraie valeur vit donc dans ton propre stockage, associée au joueur, et l'attribut n'en est jamais que le reflet.

Viennent ensuite les cas qui décident si la mécanique paraît juste. Tomber dans la lave, chuter ou se faire tuer par un monstre, ce n'est pas un meurtre : personne ne devrait y gagner un cœur. Un joueur au maximum ne devrait pas en gagner plus. Et il te faut un plancher : à zéro cœur, le joueur est banni, passé en spectateur, ou renvoyé avec un seul cœur ?

• Le nombre de cœurs vit dans ton stockage, puis il est réappliqué à chaque connexion
• Seul un meurtre déplace un cœur, jamais une chute ni un monstre
• Un plafond et un plancher, et une réponse claire sur ce que fait le plancher
• Décide ce que vaut un meurtre répété sur la même victime

Vies limitées et retour possible

Cousine des cœurs volés, souvent posée à côté : chaque joueur commence la saison avec un nombre de vies fixe, et une mort en dépense une. Toute la tension arrive sur la dernière vie, quand un saut mal calculé efface un mois de construction.

Côté serveur, c'est un compteur par joueur qui doit survivre aux redémarrages, plus une décision sur ce qu'est un joueur sans vie. La plupart des serveurs préfèrent le verrouiller plutôt que l'expulser : il reste connecté, il regarde, il ne peut plus agir. Ça veut dire intercepter la réapparition, changer son mode de jeu, et refuser les actions que tu considères comme jouer.

Le plus intéressant, c'est le retour. Un objet de résurrection, coûteux à fabriquer, qu'un joueur vivant utilise sur un joueur mort, transforme l'élimination en événement collectif au lieu d'une sortie. Cet objet a besoin de sa recette, de son comportement, et d'une règle sur le nombre de vies rendues. Il doit aussi marcher sur un joueur hors ligne, donc la résurrection est enregistrée et appliquée à sa prochaine connexion.

• Un compteur de vies par joueur, qui survit aux redémarrages
• Un état clair pour un joueur à court de vies : spectateur, verrou ou bannissement
• Un objet de résurrection avec sa recette et ses règles
• La résurrection marche hors ligne, appliquée à la prochaine connexion

Des grades qui se gagnent

Un SMP classé colle une étiquette visible sur chaque joueur : un tag dans le chat, une couleur dans la liste des connectés, parfois une division qui monte et descend selon les résultats. C'est l'une des mécaniques les plus recherchées, parce qu'elle rend la progression lisible sans que personne ait à expliquer le serveur.

Le côté permissions est déjà très bien couvert par les plugins de permissions existants, et il n'y a aucune raison de le réécrire. Ce qui est propre à ton serveur, c'est l'échelle : ce qui compte comme résultat, combien vaut une victoire contre plus fort ou plus faible, si les points fondent quand tu ne joues plus, et où tombent les seuils entre divisions.

Le plugin à construire est donc celui qui possède le score. Il réagit aux événements que tu considères comme des résultats, met à jour un nombre, en déduit une division, puis met en forme le chat lui-même ou confie le grade au plugin de permissions que tu utilises déjà. Nomme-le dans ta description et le code sera écrit pour lui parler.

• Décide ce qui compte comme résultat avant de décider les points
• Battre plus fort ne peut pas rapporter autant que battre plus faible
• Les divisions sont des seuils sur un seul nombre : peu nombreux et lisibles
• Laisse les permissions au plugin de permissions, garde le score

Niveaux et progression

Un SMP à niveaux donne aux joueurs un nombre qui ne fait que monter, et accroche de petits bonus permanents dessus. C'est la progression la plus douce : personne ne perd rien, et il y a toujours une étape suivante visible.

Le vrai travail, c'est de choisir ce qui rapporte de l'expérience. Le temps de connexion seul récompense ceux qui laissent tourner le jeu. Les meurtres seuls récompensent les plus forts et ennuient les autres. La plupart des serveurs mélangent : blocs minés, monstres tués, distance parcourue, quêtes terminées, avec des poids différents, pour que plusieurs façons de jouer aient une route vers le haut.

Côté serveur, deux choses comptent : la courbe et le coût du comptage. Une courbe plate rend le niveau 50 insignifiant, une courbe trop raide bloque les nouveaux dès la première semaine, donc le coût par niveau augmente en général. Et le comptage doit rester gratuit : incrémenter un nombre en mémoire quand un bloc casse ne coûte rien, l'écrire sur le disque à chaque bloc cassé fait chuter le TPS. Garde le total en mémoire, enregistre-le sur une minuterie et à la déconnexion.

• Plusieurs sources d'expérience, donc plusieurs façons de monter
• Un coût par niveau qui grandit, sinon l'échelle s'aplatit
• Compter en mémoire, écrire sur une minuterie et à la déconnexion
• Des bonus qui ajoutent, jamais qui retirent, sinon ce n'est plus une progression

Terres protégées et zones privées

Dès qu'un SMP dépasse une poignée de joueurs, quelqu'un perd une construction. Un système de protection, c'est ce qui garde le serveur en vie après ce premier incident : un joueur marque une zone, et à l'intérieur seuls les gens en qui il a confiance peuvent construire, casser ou ouvrir un coffre.

Le cœur du sujet, c'est une recherche qui doit être rapide, parce qu'elle tourne à chaque bloc cassé, chaque bloc posé, chaque coffre ouvert, chaque seau versé, soit des milliers de vérifications par minute sur un serveur actif. Une liste de zones parcourue une par une tiendra à dix zones et fera mal à mille : on indexe donc par tronçon de carte, et on ne regarde à l'intérieur qu'ensuite.

Le reste, ce sont les règles de bordure, et c'est là que les serveurs se distinguent. Une zone peut-elle en chevaucher une autre ? Protège-t-elle des explosions, du feu, des pistons poussés depuis l'extérieur, des monstres ? Expire-t-elle quand le propriétaire ne se connecte plus ? Y a-t-il une limite de surface, et grandit-elle avec le niveau ? Écris ces réponses : ce sont elles que le plugin devra faire respecter.

• Indexe par tronçon de carte, sinon la vérification devient le goulot
• Décide pour les explosions, le feu, les pistons et les monstres, pas seulement les joueurs
• Une liste de confiance par zone, avec des rôles si tu veux mieux que oui ou non
• Une limite de surface, et une règle pour les propriétaires inactifs

Une économie dont les joueurs se servent

Une économie SMP ne vaut le coup que s'il y a quelque chose à vouloir. Un solde sans rien derrière, c'est un nombre qui monte. Ce qui la fait vivre, c'est un point de sortie : une boutique qui vend quelque chose de rare, une enchère où les joueurs se disputent un objet, une taxe qui retire des pièces de la circulation.

Techniquement, le registre lui-même est la partie facile, et la plupart des serveurs se branchent sur un service d'économie existant pour que tous les autres plugins lisent le même solde. Ce qui demande du travail, c'est l'échange entre joueurs : une boutique en coffre qui lit un panneau, vérifie le stock, déplace l'objet et l'argent d'un seul geste, et ne perd ni l'un ni l'autre si l'acheteur se déconnecte au milieu.

Le défaut à empêcher dès la conception, c'est la duplication. Tout chemin où l'argent est crédité avant que l'objet soit retiré, ou l'inverse, sera trouvé et exploité dans la semaine. L'échange se fait en une seule opération, et il est refusé en entier si une seule de ses parties ne peut pas aboutir.

• Un point de sortie compte plus que le solde lui-même
• Branche-toi sur le service d'économie que tes autres plugins lisent déjà
• Chaque échange est une opération unique : tout ou rien
• Journalise les transactions, sinon tu ne pourras jamais trancher une dispute

Pouvoirs, âmes et autels

Au-delà des règles de survie, la mécanique qui donne son goût à un SMP est souvent celle qui distribue des capacités. Les formes varient : une âme lâchée à la mort qui donne un pouvoir à celui qui la ramasse, un autel où tu sacrifies des objets rares contre un trait permanent, une capacité tirée au sort une fois par joueur et gardée toute la saison.

Ce que tout ça partage côté serveur, c'est un état par joueur qui n'existe pas dans le jeu : la liste des capacités possédées, un délai de recharge pour chacune, et un accrochage sur les événements où la capacité doit se déclencher. La capacité elle-même est en général minuscule, quelques lignes qui ajoutent un effet ou annulent des dégâts. C'est la comptabilité autour qui prend du code.

Deux décisions valent la peine d'être prises tôt. Est-ce que les capacités se cumulent, parce que deux effets qui modifient la même valeur vont interagir d'une façon que tu n'as pas prévue. Et est-ce qu'une capacité peut se perdre, parce qu'un pouvoir qu'un autre joueur peut te prendre raconte une bien meilleure histoire qu'un pouvoir acquis pour toujours.

• Un état par joueur : capacités possédées, délais de recharge, provenance
• Décide du cumul avant d'écrire la deuxième capacité
• Une capacité qui se perd crée plus de jeu qu'une capacité définitive
• Garde la capacité minuscule et la comptabilité stricte

Primes, équipes et fin de saison

Le dernier groupe de mécaniques sert à donner quelque chose à faire au milieu d'une saison. Une prime permet à un joueur de mettre de l'argent sur la tête d'un autre, ce qui transforme une rancune en événement public. Les équipes donnent un nom à défendre et une zone commune à construire. Un classement de fin de saison transforme tout le reste en tableau final.

Les primes demandent surtout de se protéger de l'abus évident : deux amis qui se tuent à tour de rôle pour faire tourner la cagnotte. Un montant minimum, un délai avant qu'une prime puisse être encaissée, et un refus de payer deux fois de suite sur la même victime couvrent l'essentiel.

La remise à zéro de saison est la pièce que la plupart des serveurs oublient jusqu'au jour où ils en ont besoin. Effacer la progression à la main, c'est comme ça qu'on perd un classement que personne n'avait exporté. Décide à l'avance ce qu'une remise à zéro efface, ce qu'elle garde, et où le classement final est écrit avant que quoi que ce soit soit effacé.

• Une prime a besoin d'un minimum, d'un délai et d'une règle contre la victime répétée
• Une équipe a besoin d'un nom, d'une liste de membres et d'une zone commune
• La remise à zéro de saison est une fonctionnalité, et elle passe après l'export, jamais avant

Comment décrire un plugin SMP pour qu'il sorte juste

Les textes ci-dessus sont des points de départ, pas des recettes. La version qui va à ton serveur, c'est celle où tu as remplacé les nombres, les noms de commandes et les messages par les tiens. Rien n'améliore un plugin généré plus vite que d'être précis là où tu as déjà un avis.

Écris la règle comme une suite d'événements : ce que le joueur fait, ce que le serveur vérifie, ce qui change, ce que tout le monde voit. Nomme tes commandes exactement comme tu veux qu'on les tape, dis qui a le droit de lancer chacune, et écris les messages du chat avec les mots que tes joueurs doivent lire. Indique ta version de Minecraft et ta plateforme, Spigot, Paper, Bukkit ou Folia, pour que le code vise la bonne API.

Ensuite, avance par passes. Une mécanique, testée, puis la suivante. Une seule description qui demande les cœurs, les vies, les grades, les zones et l'économie d'un coup produit un plugin qui fait cinq choses à peu près. Cinq descriptions produisent cinq plugins qui en font une correctement, et ils s'installent côte à côte.

• Remplace chaque nombre, chaque commande et chaque message par les tiens
• Décris la règle comme une suite d'événements, pas comme un nom de fonctionnalité
• Indique ta version de Minecraft et ta plateforme
• Une mécanique par plugin, un plugin par passe

Essaie-le avant d'ouvrir la saison

Une règle SMP se juge en jeu, pas dans le code. Un compteur de cœurs qui se lit bien à la relecture et s'oublie au redémarrage, c'est une saison pour rien, et tu ne le découvriras qu'en te connectant, en mourant et en revenant.

C'est pour ça que le .jar compilé peut être lancé en ligne sur un vrai serveur : tu te connectes, tu tapes tes commandes, tu déclenches la règle, tu te déconnectes, tu reviens, et tu vérifies que ce qui devait être conservé l'a été. C'est cette panne-là qui fait le plus mal, alors teste-la en premier, avant l'équilibrage des nombres.

Une fois que le comportement tient, télécharge le .jar, dépose-le dans le dossier plugins et redémarre. Le code source est à toi, et si une règle mérite un ajustement, renvoie la description corrigée plutôt que de bricoler autour du problème.

• Teste la conservation en premier : déclenche la règle, reconnecte-toi, vérifie
• Puis les cas limites : mort par monstre, cible hors ligne, joueur au plafond
• Et seulement après, discute des nombres

Questions fréquentes

Prêt à créer ton plugin Minecraft ?

Description en français, .jar compilé, gratuit. Sans une ligne de Java.