El jar de Mojang y Paper no son el mismo programa con otra ropa. Uno es una implementación de referencia que tiene que coincidir con el juego al detalle, bloque a bloque. El otro es una bifurcación construida para un solo trabajo: mantener ese mismo juego correcto haciendo muchísimo menos esfuerzo para conseguirlo.
Por qué el vanilla es lento a propósito, no por descuido
El servidor de Mojang tiene un trabajo por encima de todos los demás: ser la verdad de referencia de qué es Minecraft. Cada bloque, cada comportamiento de mob, cada caso raro de redstone tiene que coincidir exactamente con el cliente, porque millones de mundos de un jugador dependen de esa exactitud. El rendimiento es una preocupación secundaria para un código con esa responsabilidad.
Eso se traduce en coste real. El vanilla tica cada entidad y bloque cargado de la forma directa, sin ningún atajo que en teoría pudiera cambiar el resultado de un caso extremo. Manda datos de chunk completos a jugadores que no se han movido, recalcula cosas que un motor más listo guardaría en caché, y procesa el mundo en el orden en que se escribió el código y no en el orden que sería más rápido.
Qué cambia de verdad una bifurcación
| Optimización | Qué hace el vanilla | Qué hace el software de la familia Paper |
|---|---|---|
| Carga de chunks | Carga y genera en el hilo principal, bloqueando el tick | Manda la generación a hilos de trabajo; el hilo principal solo tica lo que ya está listo |
| Rango de activación de entidades | Cada entidad piensa cada tick, por lejos que esté de cualquier jugador | Las entidades lejanas se saltan la mayor parte de su lógica hasta que un jugador está lo bastante cerca como para que importe |
| Envío de paquetes redundantes | Reenvía datos que los jugadores ya tienen | Sigue qué sabe ya cada cliente y se salta las repeticiones |
| Pathfinding e iluminación asíncronos | Calculados en línea, en el hilo del tick | Calculados fuera de ese hilo donde el protocolo vanilla lo permite |
| Configuración | Un puñado de reglas de jugabilidad | Cientos de ajustes disponibles —cupos de mobs, comportamiento de la distancia de visión, límites de redstone— sin tocar el jar |
El coste en vanilla no es proporcional a los jugadores: es proporcional a lo que hay cargado —entidades, redstone, tolvas, chunks—. Un servidor vanilla con tres jugadores parados en una granja grande puede ir más lento que uno de Paper con treinta explorando con normalidad, porque Paper específicamente no está pagando el precio vanilla de esa granja.
Dónde encajan Purpur y Pufferfish
Paper es la bifurcación base sobre la que se construye casi todo lo demás: añade la API de plugins y el trabajo central de rendimiento, y se mantiene deliberadamente cerca del comportamiento vanilla. Purpur bifurca Paper otra vez y añade más —ajustes de jugabilidad extra, más afinado, algún cambio de comportamiento que va más allá de lo que Paper está dispuesto a incluir por defecto—. Pufferfish también bifurca Paper, apuntando de forma más estrecha al rendimiento puro de tick en servidores muy grandes o muy concurridos, a veces al coste de que alguna regla no coincida exactamente con vanilla. Ninguna de las tres obliga a reescribir los plugins para usarla: las tres hablan la misma API de plugins Bukkit/Spigot que estableció Paper.
Elegir entre ellas
| Quieres | Elige |
|---|---|
| La base más segura y con más soporte | Paper |
| Opciones de jugabilidad extra ya incluidas, sin instalar plugins para ellas | Purpur |
| El máximo rendimiento de tick en un servidor muy cargado | Pufferfish |
| Compatibilidad total con mods (no solo plugins) | Ninguna de estas tres — mira la nota sobre Forge/Fabric más abajo |
Un servidor de Paper, Purpur o Pufferfish lee el mismo formato de mundo que el vanilla. Pasar entre ellos, o de vanilla a cualquiera de ellos, es cuestión de cambiar qué jar de servidor corre; haz una copia antes por rutina, pero no hay ningún paso de conversión para el mundo en sí.
Forge y Fabric resuelven otro problema: añadir bloques, objetos y mecánicas nuevas que el juego vanilla no tiene. El software de la familia Paper resuelve rendimiento y añade una API para plugins, que corren dentro del juego que ya existe en vez de añadirle contenido nuevo. Un servidor con mods tiene su propia historia de rendimiento, tratada aparte, y no es «vanilla pero más lento por lo mismo»: ahí el coste sale de lo que calculan los propios mods, no de una base sin optimizar.
El cartel de la consola nombra Paper, Purpur o Pufferfish (no minecraft_server.jar), y /version dentro del juego dice lo mismo.