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 nel riportare i propri input. Questa architettura è la base del netcode per 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 il proprio stato.

Vantaggi

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

Nel modello di autorità del server di Roblox, il ritardo è compensato facendo sì che i client prevedano istantaneamente l'effetto dei propri 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 conosciuto del server. Questo consente al client di mostrare istantaneamente il risultato dell'azione di input, nascondendo efficacemente la latenza di rete e rendendo il gioco reattivo.

A volte il client può sbagliare 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 propria previsione in base allo stato autorevole del server. Se lo stato autorevole è diverso dallo stato previsto dal client, il client deve tornare indietro e rieseguire i fotogrammi previsti. Questo sistema di previsione lato client, rollback e riesecuzione è noto come "compensazione della latenza" e contribuisce a rendere i giochi multiplayer autoritari del server fluidi e reattivi.

Configurazione

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

1. Workspace.AuthorityMode deve essere Server (impostare questo configura automaticamente le 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 client

Attraverso la previsione client, il client simula alcuni fotogrammi avanti rispetto all'ultimo stato conosciuto del server per prevedere immediatamente gli effetti degli input del giocatore. Questo nasconde la latenza di input, ma la previsione potrebbe successivamente rivelarsi errata (client misprediction) e quindi richiede correzione. Il client cerca di simulare giust sufficientemente avanti rispetto all'ultimo stato autorevole del server in modo che i suoi input arrivino al server nel fotogramma previsto. Il numero di fotogrammi che il client preverrà rispetto allo stato del server conosciuto è basato sulla latenza tra client e server.

Mispredizione 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 previsto, il gioco che esegue determinate logiche esclusivamente sul server, ecc.

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

Rollback e riesecuzione

Quando un client rileva una mispredizione, deve ripristinare lo stato autorevole del server e quindi rieseguire per tornare al fotogramma previsto. Basandosi sulla latenza di rete, il client cerca di simulare giust abbastanza avanti rispetto all'ultimo stato autorevole del server in modo che i suoi input arrivino al server nel 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 indietro all'ultimo stato autorevole 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, sei in grado di mantenere gli oggetti di gioco principali di proprietà del server senza sopportare il costo della 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 preverrà automaticamente le proprietà con accesso alla simulazione vicino al personaggio locale Character, ma se desideri un controllo più dettagliato, puoi forzare esplicitamente la previsione di un'istanza attivando o disattivando 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 tornare indietro e rieseguire quando si verifica una mispredizione. Per abilitare questo, scrivi la tua logica principale all'interno di funzioni collegate tramite RunService:BindToSimulation() in un ModuleScript che viene inizializzato sia sul client che sul server.

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

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 su istanze previste. Per i dati personalizzati, gli attributi sono il modo principale per sincronizzare le istanze contrassegnate come previste; su tali istanze, qualsiasi discrepanza nei valori degli attributi tra la fonte di verità del server e la previsione del client attiverà un completo rollback 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 nella documentazione dell'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 collegate con RunService:BindToSimulation().

Azioni di input

In un gioco di 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à su InputContext. Un approccio consiste nell'aggiungere i tuoi InputContexts a una cartella sotto ReplicatedStorage e utilizzare uno Script sotto ServerScriptService per clonare i 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

Gli eventi remoti possono ancora essere utilizzati all'interno del modello di autorità del server per facilitare comunicazioni discrete tra client e server. Ad esempio, i server possono utilizzare eventi remoti per trasmettere dati sui punti segnati dai giocatori o sul sollevamento di oggetti, e i client possono utilizzare eventi remoti come API alternative per inviare input al server, come nel caso della pressione dei pulsanti o del tocco 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 è solo una previsione dello stato autorevole del server. BindToSimulation() limita quali proprietà e metodi possono essere chiamati all'interno delle funzioni collegate per aiutarti a scrivere solo allo stato di simulazione sincronizzato. Mostrare 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 resa di una simulazione prevista sono trattate nella guida delle tecniche avanzate.

Progetti di esempio

In aggiunta a questa documentazione, i seguenti modelli possono aiutarti a iniziare: