Le jar de Mojang et Paper ne sont pas le même programme habillé différemment. L'un est une implémentation de référence qui doit correspondre exactement au jeu, bloc par bloc. L'autre est un fork bâti pour un seul travail : garder ce même jeu correct en faisant beaucoup moins d'efforts pour y arriver.
Pourquoi le vanilla est lent exprès, pas par accident
Le serveur de Mojang a un travail au-dessus de tous les autres : être la vérité de référence de ce qu'est Minecraft. Chaque bloc, chaque comportement de créature, chaque cas limite de redstone doit correspondre exactement au client, parce que des millions de mondes solo en dépendent. La performance passe après cette responsabilité.
Cela se traduit par un vrai coût. Le vanilla tique chaque entité et bloc chargé de la façon la plus directe, sans le moindre raccourci qui pourrait théoriquement changer le résultat d'un cas limite. Il renvoie des données de chunk complètes à des joueurs qui n'ont pas bougé, recalcule des choses qu'un moteur plus malin mettrait en cache, et traite le monde dans l'ordre où le code a été écrit plutôt que dans l'ordre le plus rapide.
Ce qu'un fork change vraiment
| Optimisation | Ce que fait le vanilla | Ce que fait le logiciel de la famille Paper |
|---|---|---|
| Chargement des chunks | Charge et génère sur le fil principal, bloquant le tick | Envoie la génération à des fils de travail ; le fil principal ne tique que ce qui est prêt |
| Rayon d'activation des entités | Chaque entité réfléchit à chaque tick, aussi loin soit-elle d'un joueur | Les entités lointaines sautent l'essentiel de leur logique jusqu'à ce qu'un joueur soit assez proche |
| Envoi de paquets redondants | Renvoie des données que les joueurs ont déjà | Suit ce que chaque client sait déjà et saute les répétitions |
| Pathfinding et éclairage asynchrones | Calculés en ligne, sur le fil du tick | Calculés hors de ce fil là où le protocole vanilla le permet |
| Configuration | Une poignée de règles de jeu | Des centaines de réglages disponibles — plafonds de créatures, comportement de la distance d'affichage, limites de redstone — sans toucher au jar |
Le coût en vanilla n'est pas proportionnel aux joueurs — il est proportionnel à ce qui est chargé : entités, redstone, entonnoirs, chunks. Un serveur vanilla avec trois joueurs plantés dans une grande ferme peut être plus lent qu'un serveur Paper avec trente joueurs qui explorent normalement, parce que Paper, précisément, ne paie pas le prix vanilla de cette ferme.
Où se situent Purpur et Pufferfish
Paper est le fork de base sur lequel presque tout le reste s'appuie : il ajoute l'API d'extensions et le travail central de performance, et reste délibérément proche du comportement vanilla. Purpur bifurque Paper à nouveau et ajoute davantage — des options de jeu supplémentaires, plus de réglages fins, quelques changements de comportement qui vont au-delà de ce que Paper accepte d'expédier par défaut. Pufferfish bifurque aussi Paper, visant plus étroitement la pure performance de tick sur des serveurs très grands ou très chargés, parfois au prix d'une règle qui ne correspond plus exactement au vanilla. Aucun des trois n'oblige à réécrire les extensions pour lui : tous parlent la même API d'extensions Bukkit/Spigot établie par Paper.
Choisir entre eux
| Vous voulez | Choisissez |
|---|---|
| La base la plus sûre et la mieux supportée | Paper |
| Des options de jeu supplémentaires déjà incluses, sans installer d'extensions pour elles | Purpur |
| La performance de tick maximale sur un serveur très chargé | Pufferfish |
| Une compatibilité totale avec les mods (pas seulement les extensions) | Aucun des trois — voir la note sur Forge/Fabric plus bas |
Un serveur Paper, Purpur ou Pufferfish lit le même format de monde que le vanilla. Passer de l'un à l'autre, ou du vanilla vers l'un d'eux, revient à changer le jar serveur qui tourne ; sauvegardez d'abord par routine, mais il n'y a aucune étape de conversion pour le monde lui-même.
Forge et Fabric résolvent un autre problème — ajouter de nouveaux blocs, objets et mécaniques que le jeu vanilla n'a pas. Le logiciel de la famille Paper résout la performance et ajoute une API pour les extensions, qui tournent à l'intérieur du jeu existant plutôt que d'y ajouter du contenu. Un serveur moddé a sa propre histoire de performance, traitée séparément, et ce n'est pas « du vanilla mais plus lent pour la même raison » — le coût y vient de ce que les mods eux-mêmes calculent, pas d'une base non optimisée.
La bannière de la console nomme Paper, Purpur ou Pufferfish (pas minecraft_server.jar), et /version en jeu rapporte la même chose.