Per un server Minecraft con 1–20 giocatori, il punto di partenza più solido è view-distance=8 e simulation-distance=5. Con più di 20 giocatori, scendi a view-distance=6–8 e simulation-distance=4–5. Se il TPS crolla sotto 20, abbassa prima la simulation-distance, non la view-distance: è la leva che pesa di più sulla CPU del server.
Tre punti da tenere a mente subito:
- Il server imposta il tetto massimo di visibilità. Il client può scegliere un valore inferiore, ma non può superare quello del server.
simulation-distancenon può essere maggiore diview-distance: il server la riduce automaticamente se provi a impostarla più alta.- PaperMC è il software consigliato per qualsiasi server pubblico: ottimizza il tick loop e aggiunge chiavi di configurazione che Vanilla non ha.
Se il TPS rimane basso anche dopo il tuning, il problema è spesso legato all’hardware. Migliorare la CPU e lo storage può risolvere problemi che la sola configurazione non può affrontare.
Punti chiave
Abbassare simulation-distance prima di view-distance è l’intervento più efficace per recuperare TPS su qualsiasi server Minecraft con carico elevato.
| Punto | Dettagli |
|---|---|
| Abbassa simulation-distance per prima | Riduce il costo di tick senza togliere visibilità ai giocatori. |
| Valori di partenza consigliati | view-distance=8, simulation-distance=5 per server con 5–20 giocatori. |
| Pre-genera il mondo | Elimina i picchi di I/O durante l’esplorazione, recuperando TPS in modo stabile. |
| Misura con Spark prima e dopo | Confronta MSPT e TPS con lo stesso carico per valutare l’effetto reale di ogni modifica. |
| AtomSync per i limiti hardware | CPU single-thread veloce, NVMe SSD e pannello Pterodactyl per gestire la configurazione senza vincoli. |
Indice
- Cosa sono view-distance, render distance e simulation-distance?
- Quanto pesa davvero la view-distance sulle prestazioni?
- Quali valori scegliere in base al tipo di server?
- Come modificare view-distance e simulation-distance passo per passo
- Perché Paper (PaperMC) cambia le regole del gioco
- Come misurare l’effetto reale delle modifiche
- Nebbia, visibilità e differenze tra Java e Bedrock
- Quando è il momento di cambiare piano hosting?
- Latenza e posizione geografica: perché contano per la render distance
- Render distance e sicurezza: gli exploit da chunk da conoscere
- Come monitorare la render distance durante eventi e picchi di giocatori
- Un piano AtomSync per mantenere la render distance che vuoi
- Fonti
- Domande frequenti
Cosa sono view-distance, render distance e simulation-distance?
Tre termini, tre cose diverse. Confonderli porta a intervenire sul parametro sbagliato.
View-distance è il raggio in chunk che il server invia al client. Se vale 10, ogni giocatore riceve i chunk in un’area di (2×10+1)² = 441 chunk. È un costo server: CPU per la generazione, RAM per il mantenimento in memoria, banda per la trasmissione.
Render distance (distanza di rendering) è quanto il client disegna di quello che ha ricevuto. Pesa sulla GPU e sulla CPU locale del giocatore, non sul server. Un client può impostare render distance a 32 chunk, ma se il server ha view-distance=8, vedrà comunque solo 8 chunk di mondo reale, circondati da nebbia.
Simulation-distance è il raggio entro cui il server ticka attivamente i chunk: crescita dei raccolti, spawn dei mob, redstone, entità in movimento. I chunk tra simulation-distance e view-distance sono visibili ma congelati: il giocatore li vede, ma le colture non crescono e i mob non si muovono.
Come precisa Microsoft Learn, il client non può forzare una distanza superiore a quella del server, e simulation-distance viene automaticamente degradata se supera view-distance.
Un chunk misura 16×16 blocchi. Un raggio in chunk può essere tradotto approssimativamente in blocchi moltiplicando per 16, ad esempio un raggio di 12 chunk corrisponde a circa 192 blocchi in ogni direzione.
Quanto pesa davvero la view-distance sulle prestazioni?
L’area di chunk caricati cresce con il quadrato del raggio. Non è una crescita lineare: raddoppiare il raggio quadruplica i chunk da gestire.
L’area di chunk caricati cresce significativamente al crescere del raggio; per esempio, aumentando il raggio da un valore basso a uno maggiore, il numero di chunk da gestire aumenta di alcuni multipli, influendo apprezzabilmente su memoria e banda.
Come documenta la Minecraft Wiki su server.properties, ridurre la view-distance è la singola modifica più efficace per abbattere consumo di memoria e banda, proprio perché l’area scala quadraticamente.
Gli effetti si distribuiscono su livelli diversi:
- CPU server: generazione e tick dei chunk, logica delle entità nei chunk attivi.
- RAM: ogni chunk caricato occupa memoria; con 30 giocatori e
view-distance=12, i chunk unici da mantenere possono sovrapporsi parzialmente ma il totale rimane alto. - Banda: il server trasmette dati di chunk a ogni giocatore. Con
view-distance=10e 20 giocatori, il flusso dati in uscita è sensibilmente superiore rispetto aview-distance=6. simulation-distancee TPS: più chunk tickati significa più entità aggiornate, più redstone valutata, più crescita di colture. Questo è il parametro che affossa il TPS quando è troppo alto.
SyntaxMine chiarisce che render distance e simulation distance sono costi separati: abbassare la render distance del client non migliora il TPS del server, e viceversa.
Quali valori scegliere in base al tipo di server?
I valori dipendono dal numero di giocatori e dalla modalità di gioco. Questi sono punti di partenza, non valori definitivi: misura sempre dopo ogni modifica.
| Tipo di server | view-distance | simulation-distance | Note |
|---|---|---|---|
| Privato (1–6 giocatori) | 10–12 | 6–8 | Hardware dedicato, pochi chunk unici |
| Piccolo pubblico (5–20) | 8–10 | 5–6 | Buon equilibrio visibilità/TPS |
| Medio/grande (>20) | 6–8 | 4–5 | Priorità alla stabilità del TPS |
| PvP competitivo | 8–10 | 6–8 | Visibilità dei giocatori prioritaria |
| Survival con farm | 8 | 4–5 | Farm pesanti richiedono simulation bassa |
| Creative/building | 10–16 | 6–8 | Meno entità, più visibilità accettabile |
MineFixTools raccomanda view-distance=8–10 e simulation-distance=4–6 come punto di partenza sicuro per server piccoli e medi, con l’indicazione di abbassare prima simulation-distance se il TPS scende.
Esempio di snippet server.properties per un server pubblico medio:
view-distance=8
simulation-distance=5
Il valore di default per view-distance e simulation-distance è comunemente intorno a 10. Valori molto bassi possono rendere l’esperienza di gioco problematica, mentre aumenti eccessivi portano a costi di prestazioni elevati senza benefici significativi alla visibilità.
Come modificare view-distance e simulation-distance passo per passo
- Ferma il server dal pannello di controllo (Pterodactyl o il pannello del tuo hosting) oppure con il comando
stopnella console. - Apri
server.propertiesdalla gestione file del pannello. Cerca le righeview-distanceesimulation-distancee modifica i valori. - Salva e riavvia il server.
- Verifica con
/timings reportoppure con Spark (/spark tps) che i valori siano stati applicati e che il TPS sia stabile.
Per chi usa Docker con l’immagine itzg/minecraft-server, le variabili d’ambiente corrispondenti sono:
environment:
VIEW_DISTANCE: "8"
SIMULATION_DISTANCE: "5"
Su pannelli hosting come Pterodactyl, le stesse variabili sono spesso esposte come campi configurabili nell’interfaccia, senza dover toccare il file direttamente.
Un consiglio: cambia una sola impostazione alla volta. Se modifichi entrambi i valori insieme e le prestazioni cambiano, non saprai quale dei due ha fatto la differenza. Testa con lo stesso carico di giocatori e le stesse attività per confrontare i risultati in modo affidabile.
La guida SetupMC raccomanda esplicitamente questa procedura: una modifica, un riavvio, una misurazione. Pre-generare il mondo con strumenti come Chunky riduce gli spike di I/O quando i giocatori esplorano zone nuove, ed è un passo che vale la pena fare prima di qualsiasi test serio.
Perché Paper (PaperMC) cambia le regole del gioco
Vanilla Minecraft non offre controllo granulare sul tick loop. Paper sì, e la differenza si sente già con 10 giocatori.
Le impostazioni Paper più utili in relazione alla distanza di rendering:
entity-broadcast-range-percentage(inpaper-world-defaults.yml): riduce il raggio entro cui le entità vengono trasmesse ai client. Abbassarlo a 75–80 taglia la banda senza toccareview-distance.sync-chunk-writes(inpaper.yml): se impostato sufalse, la scrittura dei chunk avviene in modo asincrono, riducendo i picchi di I/O che causano lag durante l’esplorazione.max-tick-time: limita il tempo massimo che un singolo tick può occupare prima che il server intervenga, evitando freeze prolungati.
Paper ottimizza anche la logica di spawn dei mob e il pathfinding delle entità, che sono tra i principali responsabili del calo di TPS con simulation-distance alta. La compatibilità con plugin come Chunky (pre-generazione) e con mod client come Sodium (lato client, per migliorare FPS senza toccare il server) rende Paper la base di partenza per qualsiasi server che voglia gestire la distanza di rendering in modo serio.
Come misurare l’effetto reale delle modifiche
Modificare i valori senza misurare è come regolare un motore a occhio. Gli strumenti esistono e sono gratuiti.
Procedura consigliata:
- Baseline prima della modifica: avvia Spark con
/spark profiler start, lascia girare il server con il carico normale per 5–10 minuti, poi genera il report con/spark profiler stop. Annota MSPT (millisecondi per tick), TPS e uso RAM. - Applica la modifica e ricrea lo stesso scenario di carico (stesso numero di giocatori, stesse attività).
- Confronta: MSPT dovrebbe scendere, TPS dovrebbe avvicinarsi a 20. Se RAM e banda calano, la modifica ha funzionato.
- F3 lato client: mostra il TPS del server e la render distance effettiva ricevuta dal client. Utile per verificare che il server stia davvero applicando i valori impostati.
Segnali d’allarme da non ignorare:
- TPS costantemente sotto 18–19, anche con pochi giocatori.
- MSPT sopra 50 ms durante l’esplorazione (spike di generazione chunk).
- Stuttering delle entità visibile ai giocatori anche con
simulation-distancebassa. - Aumento improvviso dell’I/O su disco durante le sessioni di esplorazione intensa.
Se questi segnali persistono dopo il tuning, il problema è hardware, non configurazione.
Nebbia, visibilità e differenze tra Java e Bedrock
La nebbia non è solo estetica. Su Java, la nebbia nasconde il bordo della render distance e alleggerisce il carico GPU del client, che non deve disegnare geometria lontana con la stessa precisione. Aumentare la nebbia lato client (tramite le impostazioni video) può migliorare gli FPS su macchine deboli senza toccare nulla sul server.
Su Bedrock, simulation-distance e render-distance funzionano con la stessa logica di base, ma i valori predefiniti e i limiti massimi differiscono tra piattaforme (mobile, console, PC). Per i server che usano GeyserMC per il crossplay Java/Bedrock, la view-distance del server si applica a entrambi i tipi di client: i giocatori Bedrock vedono lo stesso limite dei giocatori Java.
Per i giocatori con PC poco potenti su Java, Sodium è la mod client più efficace per recuperare FPS senza chiedere al server di abbassare la view-distance. Riduce il costo di rendering lato client in modo significativo, permettendo di mantenere una distanza visiva decente anche su hardware datato.
Quando è il momento di cambiare piano hosting?
Il tuning della configurazione ha un limite. Se hai già portato view-distance a 6 e simulation-distance a 4, e il TPS rimane sotto 18 con 15 giocatori, il collo di bottiglia è l’hardware.
Segnali che indicano la necessità di un upgrade:
- CPU del core principale al 100% in modo persistente (visibile con Spark o con i monitor del pannello).
- RAM saturata: il server inizia a usare swap, il che causa lag imprevedibile.
- Banda in uscita limitata: i giocatori ricevono chunk in ritardo, con blocchi che “appaiono” mentre camminano.
- TPS basso anche durante la notte, con pochi giocatori connessi.
Cosa cercare in un piano di upgrade: CPU con alta frequenza single-thread (Minecraft è single-threaded per il tick loop principale), storage NVMe per la lettura/scrittura dei chunk, banda uplink generosa e protezione DDoS per mantenere la stabilità durante eventi con molti giocatori. La guida alla scelta del server dedicato di AtomSync approfondisce questi criteri con parametri concreti.
Latenza e posizione geografica: perché contano per la render distance
Un server fisicamente vicino ai giocatori trasmette i dati di chunk più velocemente. Con view-distance=10, il server invia una quantità significativa di dati a ogni giocatore connesso. Se la latenza tra server e client è alta (sopra 80–100 ms), i chunk arrivano in ritardo e i giocatori vedono il mondo “caricarsi” mentre camminano, anche con una view-distance moderata.
Per i server destinati a giocatori in Europa Centrale, un datacenter in Germania, Austria o Polonia riduce la latenza media rispetto a soluzioni ospitate fuori dall’area. La guida all’hosting in Italia di AtomSync analizza come la posizione geografica influisce sulle prestazioni percepite. Con latenza bassa, puoi permetterti una view-distance leggermente più alta mantenendo un’esperienza fluida; con latenza alta, abbassarla è spesso più efficace di qualsiasi ottimizzazione software.
Render distance e sicurezza: gli exploit da chunk da conoscere
Una view-distance alta espone il server a un rischio concreto: i chunk caricati a distanza possono essere sfruttati per caricare zone del mondo che normalmente non sarebbero accessibili, rivelando strutture nascoste o risorse rare prima che un giocatore le raggiunga fisicamente.
Su server PvP o con economia, questo diventa un vantaggio sleale. Tenere view-distance a 8–10 limita l’area esplorabile a distanza e riduce la superficie di questo tipo di exploit. Alcuni plugin di anti-cheat monitorano i pattern di caricamento dei chunk per rilevare comportamenti anomali, ma la prima difesa è una view-distance ragionevole.
Plugin o meccanismi che mantengono chunk caricati anche senza giocatori nelle vicinanze possono aggirare simulation-distance e causare lag persistente. Limitare o monitorare l’uso di chunk loader è parte della gestione della sicurezza del server.
Come monitorare la render distance durante eventi e picchi di giocatori
Durante un evento con molti giocatori attivi, le metriche cambiano rapidamente. Monitorare in tempo reale è l’unico modo per intervenire prima che il lag diventi visibile.
Alcune pratiche concrete:
- Tieni Spark attivo in background durante gli eventi. Il profiler continuo consuma poche risorse e permette di generare un report immediato se il TPS scende.
- Abbassa temporaneamente
simulation-distanceprima dell’evento, non durante. Cambiare valori con il server sotto carico può causare spike di I/O aggiuntivi. - Pre-genera la zona dell’evento con Chunky. Se l’evento si svolge in un’area specifica, generare i chunk in anticipo elimina il costo di generazione in tempo reale.
- Monitora la banda dal pannello hosting. Un picco improvviso di traffico in uscita durante un evento indica che il server sta trasmettendo più chunk del previsto, spesso perché i giocatori si spostano in aree non pre-generate.
Con 30 o più giocatori attivi nella stessa zona, anche una view-distance=8 può diventare pesante. Avere un piano di upgrade rapido disponibile, o la possibilità di scalare le risorse senza interruzioni, fa la differenza tra un evento riuscito e uno con lag costante.
Il tuning funziona, ma l’hardware decide il limite
Gestire la distanza di rendering su un server Minecraft è un esercizio di equilibrio continuo. Ho visto server con view-distance=12 girare perfettamente su hardware adeguato, e server con view-distance=6 arrancare perché la CPU era condivisa con decine di altri utenti.
Paper, Spark e i valori giusti in server.properties sono strumenti potenti, ma su hardware condiviso o sottodimensionato arrivano a un muro. Quando quel muro si presenta, l’unica risposta è cambiare piano.
La cosa che più spesso viene trascurata: la pre-generazione del mondo. Eliminare i picchi di generazione chunk durante l’esplorazione può recuperare più TPS di qualsiasi altra singola modifica alla configurazione. È il primo intervento da fare, prima ancora di toccare view-distance.
Un piano AtomSync per mantenere la render distance che vuoi
Raggiungere i limiti hardware è frustrante, soprattutto quando sai esattamente quale configurazione vorresti usare ma il server non regge. AtomSync offre piani Minecraft con CPU ad alta frequenza single-thread, storage NVMe SSD, protezione DDoS fino a 1 Tbps e pannello Pterodactyl per modificare view-distance e simulation-distance direttamente dall’interfaccia, senza accesso SSH.
Il supporto in italiano via Discord è disponibile nei giorni lavorativi: se dopo aver applicato le impostazioni di questa guida il TPS rimane instabile, il team AtomSync può aiutarti a diagnosticare il problema e a scegliere il piano giusto. Attivazione in meno di 60 secondi, nessun vincolo contrattuale, garanzia di rimborso nelle prime 48 ore. Prova un piano superiore per una settimana, confronta le metriche con Spark, e decidi con dati alla mano. Inizia su Atom-sync.
Fonti
Per approfondire ogni aspetto trattato in questa guida:
- PaperMC — server properties (View & Simulation Distance)
- Server.properties — Minecraft Wiki
- Render vs Simulation Distance in Minecraft 26.2 · SyntaxMine
- View Distance vs Simulation Distance in Minecraft Servers | MineFixTools
- View Distance vs Simulation Distance in Paper — SetupMC
Domande frequenti
Il server ha una sua render distance separata da quella del client?
Sì. Il server controlla view-distance (quanti chunk invia) e simulation-distance (quanti chunk ticka). Il client decide solo quanti chunk disegnare, ma non può riceverne più di quanti il server ne trasmette.
20 TPS è un buon risultato su Minecraft?
20 TPS è il massimo teorico e corrisponde a un’esecuzione perfetta del tick loop. Valori tra 18 e 20 sono accettabili; sotto 18 il gioco inizia a sembrare rallentato, e sotto 15 il lag diventa evidente per tutti i giocatori.
Quanto è lontano un raggio di 12 chunk?
Un chunk misura 16 blocchi. Un raggio di 12 chunk corrisponde a circa 192 blocchi in ogni direzione dal giocatore.
Quanta RAM serve per una view-distance di 32 chunk?
Impostare valori molto alti per view-distance richiede una quantità significativa di risorse di memoria e CPU, che potrebbe superare le capacità tipiche di hardware standard per server pubblici. È importante bilanciare la configurazione con le risorse disponibili.