Italiano
Il netcode è la parte del software di un gioco che permette a computer diversi di partecipare alla stessa partita. È un’etichetta ampia, non un singolo algoritmo: comprende l’invio di informazioni, la sincronizzazione delle simulazioni e le decisioni da prendere quando i messaggi arrivano tardi o non concordano.
È anche un bersaglio facile. Un colpo mancato, un salto improvviso di posizione e una risposta ritardata a un pulsante possono sembrare simili pur avendo cause diverse. Conoscere le tecniche principali rende la diagnosi più utile del semplice verdetto che il netcode di un gioco fa schifo.
Chi decide cosa è successo davvero?
In un gioco con server autoritativo, i client non hanno l’ultima parola sul risultato condiviso. La panoramica di Epic sul networking descrive un mondo gestito dal server autoritativo insieme alle versioni visualizzate dai client collegati.
Un server dedicato non ha un giocatore locale. Un listen server ospita anche un giocatore sulla macchina che funge da server. Entrambe sono configurazioni client-server; ospitare la partita sul computer di un giocatore non elimina automaticamente l’autorità dall’architettura.
Tieni distinta questa domanda da come viaggiano i messaggi. Peer-to-peer descrive la comunicazione tra partecipanti, non garantisce universalmente che nessun host abbia autorità o che un gioco non richieda matchmaking, relay o infrastrutture di supporto.
Tick, aggiornamenti e fotogrammi non sono intercambiabili
Un tick della simulazione fa avanzare lo stato del gioco. Un aggiornamento di rete comunica informazioni. Un fotogramma renderizzato produce un’immagine. Possono seguire tempi diversi. Anche i giochi offline fanno avanzare le simulazioni a passi; non diventano matematicamente continui perché manca un server.
A 60 tick al secondo, l’intervallo nominale è circa 16,67 millisecondi. Questo calcolo non stabilisce il tempo totale necessario perché la tua azione raggiunga lo schermo di un altro giocatore. Elaborazione, trasmissione, buffering e rendering possono tutti contribuire.
Un tick rate più alto può aiutare certe architetture, ma il dato da solo non certifica una migliore registrazione dei colpi. Conta anche ciò che il gioco registra, associa a un riferimento temporale e convalida.
La previsione rende reattivo il movimento locale
Aspettare la risposta del server prima di mostrare ogni movimento renderebbe i comandi lenti. Nel resoconto di Riot sul netcode di VALORANT, il client prevede il risultato dell’input locale mentre il server mantiene l’autorità. Se le simulazioni non concordano, il server corregge il client.
Questa riconciliazione può apparire come un salto o un effetto elastico, il rubber-banding. Serve a ripristinare l’accordo, ma correzioni frequenti possono comunque indicare un problema. La sola registrazione di un salto non rivela se la causa fosse la perdita di dati, un intoppo nell’elaborazione o un difetto della simulazione.
L’interpolazione rende più fluido il movimento remoto
Gli aggiornamenti non arrivano necessariamente a intervalli regolari. La dimostrazione di interpolazione degli snapshot di Glenn Fiedler mostra come chi riceve possa conservare temporaneamente le istantanee e disegnare posizioni intermedie tra stati noti. Si accetta un po’ di ritardo in cambio di una presentazione più fluida.
L’interpolazione è quindi diversa dall’estrapolazione. La prima stima tra campioni disponibili; la seconda proietta oltre l’ultimo stato noto. Nessuna delle due va descritta semplicemente come il computer che sa dove si trovi adesso l’avversario.
Il rollback corregge un passato previsto
Il rollback permette a un gioco di continuare prima che arrivino tutti gli input remoti. Se una previsione risulta sbagliata, ripristina uno stato precedente e simula nuovamente in avanti con gli input corretti. Il progetto GGPO è un’implementazione nota di questo approccio.
La sua guida per sviluppatori richiede una simulazione deterministica, uno stato salvabile e ripristinabile e la possibilità di far avanzare la simulazione senza renderizzare ogni passaggio intermedio. Documenta anche un limite alla previsione: se le informazioni mancanti superano quel limite, il gioco non deve continuare ad avanzare alla cieca.
Il rollback non promette ritardo zero o recupero perfetto. GGPO supporta un ritardo intenzionale degli input insieme alla previsione, e previsioni errate possono produrre discontinuità visibili. L’implementazione deve bilanciare reattività, lunghezza delle correzioni e feedback visivo del gioco.
Rollback e server possono lavorare insieme
Presentare rollback e networking client-server come scelte incompatibili è fuorviante. Nella spiegazione del gioco online di 2XKO, Riot descrive l’uso di entrambi, con il server che esercita autorità su input, stato e tempo.
L’articolo descrive anche un ritardo intenzionale degli input sia offline sia online. L’esempio conta perché smentisce due semplificazioni comuni: rollback non deve significare peer-to-peer e un gioco con rollback non deve eliminare ogni fotogramma ritardato intenzionalmente.
Perché un colpo può arrivare dopo che ti sei messo al riparo
I giocatori vedono informazioni relative a momenti diversi. La spiegazione di Riot su VALORANT descrive il controllo di un colpo contro uno stato precedente del mondo, corrispondente a ciò che vedeva chi sparava. Sottolinea anche la necessità di limitare quanto indietro possa tornare il server.
Questo aiuta a spiegare perché un difensore possa vedere il danno dopo essersi apparentemente messo in salvo. Non prova che ogni morte del genere fosse corretta o che la compensazione del lag sia l’unica causa possibile. Per giudicare un episodio servono regole del gioco e dati sui tempi, non soltanto l’immagine finale su uno schermo.
Cosa annotare quando una partita sembra funzionare male
Parti dalla diagnostica del gioco. Annota il tempo per fotogramma, il ping riportato, gli indicatori di perdita di pacchetti, la regione del server e se il problema si verifica offline. Il ping indica comunemente una misura di andata e ritorno; non è automaticamente il tempo di viaggio in una direzione di ogni messaggio di gioco.
Confronta una connessione poco occupata con una sottoposta a traffico intenso e, quando pratico, prova anche una rete cablata. Un buon risultato di velocità in download, da solo, non dimostra ritardi bassi, consegna regolare dei dati o condizioni adeguate per tutta la partita. Anche i requisiti di banda dipendono dal progetto del gioco.
Se la stessa risposta ritardata si verifica offline, indaga anche il percorso locale dall’input allo schermo. Se il problema compare soltanto in una partita, conserva l’orario e l’identificativo disponibile per una segnalazione utile.
Un buon netcode gestisce le divergenze entro dei vincoli. Non può eliminare le distanze o far funzionare ogni dispositivo nello stesso istante, ma le sue scelte possono rendere queste differenze molto meno fastidiose.
Traduzione italiana dell’articolo originale in inglese del 2026-06-24. Tradotto il 30 ottobre 2026 con assistenza IA; i riferimenti temporali restano quelli dell’originale.
