Configurare e mantenere un server dedicato per un sandbox di sopravvivenza
Un server dedicato non è la stessa partita giocata con più persone: è un'infrastruttura che deve restare in piedi anche quando nessuno è collegato. La differenza si sente al primo arresto imprevisto, quando ci si accorge che l'ultimo salvataggio utile risale a quaranta minuti prima. Questa guida raccoglie i criteri che contano davvero, in ordine di impatto.
Dimensionare l'hardware sulle grandezze giuste
La quasi totalità dei server per sandbox di sopravvivenza è composta da un processo prevalentemente monolitico: alcuni sottosistemi girano su thread separati, ma il ciclo di simulazione principale resta legato a un singolo core. Ne segue una regola operativa poco intuitiva: fra un processore con molti core lenti e uno con pochi core veloci, per questo carico conviene il secondo. Il numero di core serve a evitare che backup, compressione e processi di sistema rubino tempo al ciclo principale, non ad aumentare la capacità di gioco.
La memoria si consuma in proporzione alla superficie di mondo caricata e al numero di entità costruite. Una base matura con migliaia di elementi costruiti e centinaia di contenitori occupa molto più di quanto suggerisca il requisito minimo dichiarato. È prudente considerare il valore minimo come un punto di partenza e prevedere almeno il doppio se il mondo dovrà durare mesi.
Il disco conta in un solo momento, ma è un momento critico: il salvataggio, quando l'intero stato viene serializzato e scritto. Su un disco meccanico questa operazione produce un blocco percepibile da tutti i giocatori collegati. Un'unità a stato solido riduce il fenomeno; separare il volume dei backup da quello dei salvataggi attivi lo elimina quasi del tutto.
I parametri che decidono il carattere del server
Ogni titolo usa nomi diversi, ma le voci che modificano davvero l'esperienza sono poche e ricorrenti.
| Parametro | Effetto pratico | Criterio |
|---|---|---|
| Intervallo di salvataggio | Quantità di progressi persi in caso di arresto anomalo | Intervalli brevi su mondi piccoli, più lunghi su mondi grandi per evitare blocchi frequenti |
| Tick rate | Reattività della simulazione e del combattimento | Alzarlo solo se il processore regge senza saturare il core principale |
| Decadimento delle strutture | Sopravvivenza delle basi durante le assenze | Va comunicato in anticipo: definisce l'orizzonte di pianificazione dei giocatori |
| Moltiplicatori di raccolta | Ritmo della progressione | Valori alti riducono la logistica a una formalità e accorciano la vita del mondo |
| Slot giocatore | Carico complessivo sulla simulazione | Meglio partire bassi e alzare dopo aver misurato i tempi di frame lato server |
Un errore ricorrente è modificare più voci insieme al primo segno di rallentamento. Se cambiano contemporaneamente tick rate, slot e intervallo di salvataggio, non si saprà mai quale intervento ha prodotto il miglioramento. Una modifica alla volta, con almeno una sessione completa di osservazione fra una e l'altra.
Salvataggi e backup: due cose diverse
Il salvataggio automatico serve alla continuità della partita; il backup serve a rimediare a un danno. Confonderli è la causa più comune di perdita definitiva di un mondo, perché un salvataggio corrotto sovrascrive quello precedente e, se non esiste altra copia, non c'è nulla da recuperare.
Uno schema minimo che funziona: copie orarie mantenute per un giorno, copie giornaliere mantenute per una settimana, una copia settimanale conservata più a lungo, tutte su un volume diverso da quello di lavoro. La copia va verificata almeno una volta avviando un'istanza di prova sul file archiviato: un backup mai testato è un'ipotesi, non una garanzia.
Prima di ogni aggiornamento del server conviene arrestare il processo in modo pulito e attendere che il salvataggio finale sia concluso. Interrompere il processo durante la scrittura è il modo più rapido per ottenere un file di mondo illeggibile.
Aggiornamenti e modifiche
Gli aggiornamenti sono il momento di rischio maggiore, soprattutto quando il server usa modifiche di terze parti. Una modifica compilata contro una versione precedente può impedire l'avvio o, peggio, avviarsi e scrivere dati incompatibili nel salvataggio. La sequenza sicura è sempre la stessa: arresto pulito, backup completo, aggiornamento del server, verifica delle modifiche una per una su un'istanza di prova, e solo alla fine riapertura al pubblico.
Vale anche la disciplina inversa: non installare una modifica su un mondo attivo solo per provarla. Molte modifiche aggiungono dati persistenti che restano nel salvataggio anche dopo la rimozione, e ripulirli richiede più lavoro di quanto la prova valesse.
Monitorare le cose giuste
Tre indicatori bastano a capire lo stato di salute di un server. Il tempo di elaborazione per tick lato server dice se la simulazione sta al passo; l'occupazione di memoria nel corso della sessione rivela le perdite progressive, che si manifestano come rallentamento crescente dopo molte ore; la durata dell'operazione di salvataggio, se cresce nel tempo, segnala che il mondo sta accumulando entità oltre la soglia gestibile.
Quando la durata del salvataggio raddoppia rispetto alle prime settimane, il problema quasi mai è l'hardware: è il numero di oggetti abbandonati, di strutture non più usate e di contenitori sparsi. Una pulizia periodica delle rovine inattive incide sulle prestazioni più di qualunque aggiornamento di componentistica.
Regole di gioco, non solo file di configurazione
Un server persistente è anche un accordo fra le persone che lo usano. Dichiarare in anticipo l'orizzonte del mondo — se e quando verrà azzerato — evita la frustrazione di chi ha investito settimane in una costruzione. Allo stesso modo, indicare le finestre di manutenzione consente ai giocatori di non farsi trovare a metà di una spedizione lunga. Sono dettagli che non compaiono in nessun file di configurazione, ma determinano la longevità di un server più di qualunque parametro numerico.