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 possono essere fidati solo per riportare i propri input. Questa architettura è il fondamento del netcode per un gioco equo e competitivo poiché previene intere classi di imbrogli 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 naif, i client invierebbero semplicemente i propri input al server e mostrerebbero i risultati di gioco inviati indietro dal server. Anche se tecnicamente corretto, un tale sistema si troverebbe ad affrontare un significativo latenza d'input poiché ogni azione del giocatore dovrebbe viaggiare fino al server, essere elaborata e avere il risultato inviato di nuovo al client prima di poter essere visualizzato. Per la maggior parte dei giochi, specialmente quelli frenetici, quel ritardo di andata e ritorno renderebbe il gameplay impreciso, non reattivo e ingiocabile.

Nel modello di autorità del server di Roblox, la latenza è compensata facendo in modo che i client prevedano istantaneamente prevedere 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 conosciuto 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 può sbagliarsi nella 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 propri fotogrammi previsti. Questo sistema di previsione sul lato client, rollback e riesecuzione è noto come "compensazione della latenza" e aiuta a far sentire i giochi multiplayer con autorità del server lisci e reattivi.

Configurazione

Poiché il modello di autorità del server richiede alcune altre tecnologie dell'engine per funzionare correttamente, devi prima impostare le seguenti proprietà sull'oggetto Workspace nell'Esploratore:

1. Workspace.NextGenerationReplication deve essere abilitato
2. Workspace.PlayerScriptsUseInputActionSystem deve essere abilitato
3. Workspace.SignalBehavior deve essere Deferred
4. Workspace.UseFixedSimulation deve essere abilitato
5. Workspace.StreamingEnabled deve essere abilitato
6. Workspace.AuthorityMode deve essere Server (tutti i punti sopra devono essere impostati per primi)

Concetti

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

Previsione del client

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

Misprediction del client

Quando il client riceve lo stato autorevole dal server, verifica 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, tra cui cambiamenti nella latenza di rete, altri giocatori che agiscono in modi che il client non ha anticipato, il gioco che esegue certe 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 resettarsi allo stato autorevole del server e poi rieseguire per tornare al suo fotogramma previsto. In base alla latenza di rete, il client cerca di simulare appena abbastanza avanti rispetto all'ultimo stato autorevole del server conosciuto 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 allo stato autorevole conosciuto ricevuto dal server.
   2. Il client riesegue dallo stato autorevole al suo stato previsto, riapplicando tutti gli input locali.

Implementazione

Proprietà di rete e previsione

Nel modello di autorità del server, sei in grado di mantenere gli oggetti critici del gameplay di proprietà del server senza subire il costo della latenza d'input normalmente associato alla proprietà del server. Cose come automobili, personaggi giocatore 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 del 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 entrambi 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 legate tramite RunService:BindToSimulation() in uno ModuleScript che è 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 gli oggetti fisici sincronizzati e l'aggiornamento dello stato del gioco principale dovrebbero avvenire all'interno di quelle funzioni legate.

ModuleScript chiamato Simulazione in ReplicatedStorage:

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

local Simulazione = {}

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

return Simulazione

Sincronizzazione dello stato con attributi

Roblox sincronizza automaticamente tutte le proprietà con accesso alla simulazione sulle istanze previste. Per i dati personalizzati, attributi sono il modo principale per sincronizzare le istanze contrassegnate come previste; su tali istanze, qualsiasi mismatch 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

Affinché un attributo venga replicato, deve soddisfare tutti i seguenti criteri:

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

Accesso alla simulazione

Molte proprietà e metodi nella documentazione API dell'engine 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 dovrebbero essere usati per tutti gli input che influenzano la simulazione principale e dovrebbero essere verificati per coerenza prima di essere elaborati.

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

InputSetup
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

Usando 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.

Nota che se hai bisogno di scrivere dati personalizzati nel Sistema di Azione Input, dovresti usare una funzione collegata a RunService.RenderStepped o RunService:BindToRenderStep(), non RunService:BindToSimulation(). Inviare un InputAction in BindToSimulation() può causare ai client di produrre risultati errati durante una riesecuzione.

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

RunService:BindToRenderStep("CameraInput", Enum.RenderPriority.Last.Value, function()
	-- Invia al server il vettore di avanzamento della telecamera del client attraverso un InputAction
	local cameraForwardInputAction = Players.LocalPlayer.PlayContext.CameraForward
	local cameraForwardVector = Workspace.CurrentCamera.CFrame.LookVector
	cameraForwardInputAction:Fire(cameraForwardVector)
end)

Eventi remoti

Gli eventi remoti possono essere ancora 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 giocatori che segnano punti o raccolgono oggetti, e i client possono utilizzare eventi remoti come un'alternativa API per inviare input al server, ad esempio per pressioni di pulsanti o tocchi su oggetti nel mondo 3D.

Animazioni, suoni ed effetti

Effetti client-side come animazioni e suoni devono essere scritti sapendo che la simulazione del client è semplicemente una predizione dello stato autorevole del server. BindToSimulation() limita quali proprietà e metodi possono essere chiamati all'interno delle funzioni legate per aiutarti a scrivere solo nello 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.

Esempi di progetti

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