Modello di autorità del server

In un modello di autorità del server, il server è l'unica fonte di verità per l'intero stato del gioco, e i client sono fidati solo per riportare i propri input. Questa architettura è la base fondamentale del netcode di un gioco equo e competitivo perché previene intere classi di cheat come flyhacks o speedhacks non fidandosi mai di un client per riportare la propria posizione o stato.

Vantaggi

In un sistema di proprietà del server naive, i client invierebbero semplicemente i loro input al server e visualizzerebbero i risultati del gioco inviati indietro dal server. Sebbene tecnicamente corretto, un tale sistema affronterebbe una significativa latenza di input perché ogni azione del giocatore dovrebbe viaggiare verso il server, essere elaborata e avere il risultato inviato indietro al client prima di poter essere visualizzato. Per la maggior parte dei giochi, specialmente quelli frenetici, quel ritardo di andata e ritorno farebbe sembrare il gameplay laggoso, non reattivo e ingiocabile.

Nel modello di autorità del server di Roblox, la latenza è compensata facendo sì che i client prevedano istantaneamente predire gli effetti dei loro input oltre a inviarli al server. Ad esempio, quando un giocatore preme un tasto, il client non aspetta che il server risponda; invece, prevede alcuni fotogrammi avanti rispetto all'ultimo stato noto del server. Questo consente al client di mostrare immediatamente il risultato dell'azione di input, nascondendo efficacemente la latenza di rete e rendendo il gioco reattivo.

A volte il client sbaglierà la sua previsione (misprediction) e, a causa della latenza di rete, il client non saprà di aver commesso un errore per alcuni fotogrammi. Ad esempio:

Quando viene rilevata una mispredizione, il client deve correggere la sua previsione in base allo stato autorevole del server. Se lo stato autorevole è diverso dallo stato previsto dal client, il client deve annullare e rieseguire i suoi fotogrammi previsti. Questo sistema di previsione lato client, annullamento e riesecuzione è noto come "compensazione della latenza" e aiuta a far sembrare i giochi multiplayer con autorità del server fluidi e reattivi.

Configurazione

Il modello di autorità del server richiede alcune altre tecnologie del motore per funzionare correttamente. Conferma le seguenti impostazioni delle proprietà sull'oggetto Workspace nell'Esplora:

1. Workspace.AuthorityMode deve essere Server (impostare questo imposta automaticamente i seguenti cinque).
2. Workspace.NextGenerationReplication deve essere abilitato.
3. Workspace.PlayerScriptsUseInputActionSystem deve essere abilitato.
4. Workspace.SignalBehavior deve essere Deferred.
5. Workspace.UseFixedSimulation deve essere abilitato.
6. Workspace.StreamingEnabled deve essere abilitato.

Concetti

Il sistema di autorità del server si basa su alcuni concetti fondamentali come segue.

Previsione del client

Attraverso la previsione del client, il client simula alcuni fotogrammi avanti rispetto all'ultimo stato noto del server per prevedere immediatamente gli effetti degli input dei giocatori. Questo nasconde la latenza di input, ma la previsione potrebbe successivamente rivelarsi errata (misprediction del client) e quindi richiedere correzione. Il client cerca di simulare solo abbastanza avanti rispetto all'ultimo stato autorevole noto del server in modo che i suoi input arrivino al server al fotogramma previsto. Il numero di fotogrammi che il client prevede avanti rispetto allo stato noto del server si basa sulla latenza tra il client e il server.

Mispredizione del client

Quando il client riceve lo stato autorevole dal server, controlla quello stato rispetto a un record storico di ciò che ha previsto localmente per quel fotogramma. Quando c'è una differenza tra ciò che il client ha previsto e ciò che il server ha effettivamente fatto, questa è una mispredizione. Le mispredizioni possono verificarsi per diversi motivi, inclusi cambiamenti nella latenza di rete, altri giocatori che agiscono in modi che il client non ha anticipato, il gioco che esegue certa logica esclusivamente sul server, ecc.

Se lo stato autorevole è diverso dallo stato previsto dal client, il client deve annullare e rieseguire.

Annullamento e riesecuzione

Quando un client rileva una mispredizione, deve ripristinarsi allo stato autorevole del server e poi rieseguire per tornare al suo fotogramma previsto. Basato sulla latenza di rete, il client cerca di simulare solo abbastanza avanti rispetto all'ultimo stato autorevole noto del server in modo che i suoi input arrivino al server al fotogramma previsto.

In sintesi, il client:

1. Riceve lo stato autorevole dal server e lo confronta con il proprio stato previsto.
2. Se la previsione del client era errata:

   1. Il client torna all'ultimo stato autorevole noto ricevuto dal server.
   2. Il client riesegue dallo stato autorevole al suo stato previsto, riapplicando eventuali input locali.

Implementazione

Proprietà di rete e previsione

Nel modello di autorità del server, puoi mantenere gli oggetti di gioco principali di proprietà del server senza incorrere nel costo di latenza di input normalmente associato alla proprietà del server. Cose come auto, personaggi dei giocatori o altri oggetti critici per il gameplay possono rimanere di proprietà del server, anche quando interagiscono con altri giocatori.

Per impostazione predefinita, Roblox prevede automaticamente le proprietà con accesso alla simulazione vicino al giocatore locale Character, ma se desideri un controllo più dettagliato, puoi forzare esplicitamente la previsione di un'istanza attivandola o disattivandola con RunService:SetPredictionMode().

Sincronizzazione della simulazione

Nel modello di autorità del server, sia il client che il server devono eseguire la simulazione principale, e la simulazione del client deve essere in grado di annullare e rieseguire quando si verifica una mispredizione. Per abilitare questo, scrivi la tua logica principale all'interno di funzioni legate tramite RunService:BindToSimulation() in un ModuleScript che viene inizializzato sia sul client che sul server.

Durante una riesecuzione, Roblox rieseguirà le funzioni legate alla simulazione tramite BindToSimulation(). L'elaborazione degli input dei giocatori, l'interazione con oggetti fisici sincronizzati e l'aggiornamento dello stato principale del gioco dovrebbero avvenire all'interno di quelle funzioni legate.

Usa time() per qualsiasi logica basata sul tempo all'interno di una funzione di simulazione legata, come guidare la velocità di un'animazione o oscillare un valore nel tempo. Quando Workspace.AuthorityMode è Enum.AuthorityMode.Server, time() è sincronizzato tra il client e il server e utilizza un tempo di simulazione a passo fisso. Durante la riesecuzione, torna al fotogramma autorevole e avanza mentre il client riproduce i fotogrammi, quindi restituisce un valore coerente ogni volta che un fotogramma viene simulato.

ModuleScript chiamato Simulation in ReplicatedStorage:

local RunService = game:GetService("RunService")
local Players = game:GetService("Players")

local Simulation = {}

Simulation.Initialize = function()
	RunService:BindToSimulation(function(deltaTime)
		-- Leggi gli input dei giocatori
		-- Aggiorna lo stato del gioco
	end)
end

return Simulation

Sincronizzazione dello stato con gli attributi

Roblox sincronizza automaticamente tutte le proprietà con accesso alla simulazione sulle istanze previste. Per i dati personalizzati, gli attributi sono il modo principale per sincronizzare le istanze contrassegnate come previste; su tali istanze, qualsiasi disallineamento nei valori degli attributi tra la fonte di verità del server e la previsione del client attiverà un completo annullamento e riesecuzione.

Limiti degli attributi

Per essere replicato, un attributo deve soddisfare tutti i seguenti criteri:

• È tra i primi 64 attributi sulla sua Instance.
• Il suo nome contiene al massimo 50 caratteri.
• Se un attributo di tipo stringa, il suo valore contiene al massimo 50 caratteri.

Accesso alla simulazione

Molte proprietà e metodi nell'API del motore includono l'etichetta Accesso alla simulazione, ad esempio BasePart.CFrame. Le proprietà con questa etichetta saranno previste dal sistema di autorità del server. Inoltre, solo le proprietà e i metodi con questa etichetta possono essere accessibili all'interno di funzioni legate con RunService:BindToSimulation().

Azioni di input

In un gioco con autorità del server, il modo principale per un client di influenzare lo stato del gioco è attraverso il Sistema di Azione Input. Questi input vengono inviati al server e vengono riprodotti durante la riesecuzione sul client. Di conseguenza, InputActions dovrebbe essere utilizzato per tutti gli input che influenzano la simulazione principale e dovrebbero essere controllati per la loro validità prima di essere elaborati.

Nota che InputContexts deve essere un discendente di un Player in modo che il motore sappia chi ha la proprietà sul InputContext. Un approccio è aggiungere i tuoi InputContexts a una cartella sotto ReplicatedStorage e utilizzare uno Script sotto ServerScriptService per clonare il InputContexts per ogni giocatore:

local Players = game:GetService("Players")
local ReplicatedStorage = game:GetService("ReplicatedStorage")

local InputsFolder = ReplicatedStorage:WaitForChild("Inputs")

local function onPlayerAdded(player)
	local clone = InputsFolder:Clone()
	clone.Parent = player
end

Players.PlayerAdded:Connect(onPlayerAdded)

for _, player in Players:GetPlayers() do
	onPlayerAdded(player)
end

Utilizzando questo schema, puoi leggere InputActions per tutti i giocatori in RunService:BindToSimulation() sia sul client che sul server per ricevere gli stessi dati per un dato fotogramma e registrare l'input del fotogramma precedente in un attributo, ad esempio per attivare una corsa del personaggio quando viene attivata un'azione di input RunAction.

Eventi remoti

Eventi remoti possono ancora essere utilizzati all'interno del modello di autorità del server per facilitare la comunicazione discreta tra client e server. Ad esempio, i server possono utilizzare eventi remoti per trasmettere dati sui giocatori che segnano punti o raccolgono oggetti, e i client possono utilizzare eventi remoti come un'API alternativa per inviare input al server, come per pressioni di pulsanti o tocchi di oggetti nel mondo 3D.

Animazioni, suoni ed effetti

Gli effetti lato client come animazioni e suoni devono essere scritti sapendo che la simulazione del client è semplicemente una previsione dello stato autorevole del server. BindToSimulation() limita quali proprietà e metodi possono essere chiamati all'interno delle funzioni legate per aiutarti a scrivere solo allo stato di simulazione sincronizzato. Visualizzare i risultati di questa simulazione, attivare effetti e suoni, ecc. dovrebbe essere fatto in una funzione separata collegata a RenderStepped che legge i risultati della simulazione e attiva gli effetti desiderati.

Ulteriori indicazioni sulla visualizzazione di una simulazione prevista sono trattate nella guida tecniche avanzate.

Progetti di esempio

Oltre a questa documentazione, i seguenti modelli possono aiutarti a iniziare: