Modèle d'autorité serveur

Dans un modèle d'autorité serveur, le serveur est la seule source de vérité pour l'ensemble de l'état du jeu, et les clients ne sont fiables que pour signaler leurs propres entrées. Cette architecture est le fondement de la netcode d'un jeu compétitif équitable, car elle empêche de nombreuses formes de tricherie comme les flyhacks ou les speedhacks en ne faisant jamais confiance à un client pour signaler sa propre position ou état.

Avantages

Dans un système naïf où le serveur détient l'autorité, les clients envoient simplement leurs entrées au serveur et affichent les résultats du jeu renvoyés par le serveur. Bien que techniquement correct, un tel système ferait face à une latence d'entrée significative, car chaque action des joueurs devrait voyager jusqu'au serveur, être traitée, puis avoir le résultat renvoyé au client avant de pouvoir être affiché. Pour la plupart des jeux, en particulier ceux à rythme rapide, ce délai aller-retour donnerait aux joueurs l'impression que le gameplay est saccadé, non réactif et injouable.

Dans le modèle d'autorité serveur de Roblox, la latence est compensée par le fait que les clients prédisent instantanément les effets de leurs entrées en plus de les envoyer au serveur. Par exemple, lorsqu'un joueur appuie sur une touche, le client n'attend pas la réponse du serveur ; au lieu de cela, il prédit quelques frames en avant de l'état du serveur connu le plus récent. Cela permet au client de montrer instantanément le résultat de l'action d'entrée, cachant ainsi efficacement la latence réseau et rendant le jeu réactif.

Parfois, le client se trompe dans sa prédiction (misprediction) et, en raison de la latence réseau, le client ne saura pas qu'il a fait une erreur pendant quelques frames. Par exemple :

Lorsqu'une erreur de prédiction est détectée, le client doit corriger sa prédiction en fonction de l'état autoritaire du serveur. Si l'état autoritaire est différent de l'état prédit par le client, le client doit revenir en arrière et resimuler ses frames prédites. Ce système de prédiction côté client, de retour en arrière et de resimulation est connu sous le nom de "compensation de latence" et aide à rendre les jeux multijoueurs à autorité serveur fluides et réactifs.

Configuration

Le modèle d'autorité serveur nécessite certaines autres technologies du moteur pour fonctionner correctement. Confirmez les paramètres de propriété suivants sur l'objet Workspace dans l'Explorateur :

1. Workspace.AuthorityMode doit être Server (le fait de définir cela définit automatiquement les cinq éléments suivants).
2. Workspace.NextGenerationReplication doit être activé.
3. Workspace.PlayerScriptsUseInputActionSystem doit être activé.
4. Workspace.SignalBehavior doit être Deferred.
5. Workspace.UseFixedSimulation doit être activé.
6. Workspace.StreamingEnabled doit être activé.

Concepts

Le système d'autorité serveur repose sur quelques concepts clés comme suit.

Prédiction client

Grâce à la prédiction client, le client simule quelques frames à l'avance par rapport au dernier état connu du serveur pour prédire immédiatement les effets des entrées des joueurs. Cela cache la latence d'entrée, mais la prédiction peut plus tard s'avérer incorrecte (misprediction client) et donc nécessiter une correction. Le client essaie de simuler juste assez loin devant le dernier état authoritaire du serveur connu afin que ses entrées arrivent au serveur à la frame prévue. Le nombre de frames que le client prédit devant l'état du serveur connu est basé sur la latence entre le client et le serveur.

Misprediction client

Lorsque le client reçoit l'état autoritaire du serveur, il vérifie cet état par rapport à un enregistrement historique de ce qu'il a prédit localement pour cette frame. Lorsqu'il y a une différence entre ce que le client a prédit et ce que le serveur a réellement fait, c'est une misprediction. Des erreurs de prédiction peuvent se produire pour plusieurs raisons, y compris des changements de latence réseau, d'autres joueurs agissant de manière que le client n'avait pas anticipée, le jeu exécutant une certaine logique exclusivement sur le serveur, etc.

Si l'état autoritaire est différent de l'état prédit par le client, le client doit revenir en arrière et resimuler.

Retour en arrière et resimulation

Lorsqu'un client détecte une misprediction, il doit réinitialiser à l'état autoritaire du serveur et ensuite resimuler pour revenir à sa frame prédit. En fonction de la latence réseau, le client essaie de simuler juste assez loin devant le dernier état autoritaire connu du serveur afin que ses entrées arrivent au serveur à la frame prévue.

En résumé, le client :

1. Reçoit l'état autoritaire du serveur et le compare à son propre état prédit.
2. Si la prédiction du client était incorrecte :

   1. Le client revient à l'état autoritaire connu le plus récent reçu du serveur.
   2. Le client resimule depuis l'état autoritaire jusqu'à son état prédit, réappliquant toutes les entrées locales.

Mise en œuvre

Propriété réseau et prédiction

Dans le modèle d'autorité serveur, vous pouvez garder les objets de jeu principaux sous la propriété du serveur sans encourir le coût de latence d'entrée normalement associé à la propriété serveur. Des éléments comme des voitures, des personnages joueurs ou d'autres objets critiques pour le gameplay peuvent rester sous la propriété du serveur, même lorsqu'ils interagissent avec d'autres joueurs.

Par défaut, Roblox prédit automatiquement les propriétés avec accès à la simulation près du joueur local Character, mais si vous souhaitez un contrôle plus précis, vous pouvez explicitement forcer la prédiction d'une instance à activer ou désactiver avec RunService:SetPredictionMode().

Synchronisation de simulation

Dans le modèle d'autorité serveur, le client et le serveur doivent tous deux exécuter la simulation principale, et la simulation du client doit pouvoir revenir en arrière et resimuler lorsqu'une misprediction se produit. Pour y parvenir, écrivez votre logique principale à l'intérieur de fonctions liées via RunService:BindToSimulation() dans un ModuleScript qui est initialisé à la fois sur le client et le serveur.

Lors d'une resimulation, Roblox relancera les fonctions liées à la simulation via BindToSimulation(). Le traitement des entrées des joueurs, l'interaction avec des objets physiques synchronisés et la mise à jour de l'état du jeu principal doivent se faire à l'intérieur de ces fonctions liées.

ModuleScript nommé Simulation dans ReplicatedStorage :

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

local Simulation = {}

Simulation.Initialize = function()
	RunService:BindToSimulation(function(deltaTime)
		-- Lire les entrées des joueurs
		-- Mettre à jour l'état du jeu
	end)
end

return Simulation

Synchronisation d'état avec des attributs

Roblox synchronise automatiquement toutes les propriétés avec un accès à la simulation sur des instances prédites. Pour les données personnalisées, les attributs sont le moyen principal de synchroniser les instances marquées comme prédites ; sur ces instances, toute incohérence dans les valeurs d'attribut entre la source de vérité du serveur et la prédiction du client déclenchera un retour en arrière et resimulation complet.

Limites d'attribut

Pour qu'un attribut soit répliqué, il doit répondre à tous les critères suivants :

• Il fait partie des 64 premiers attributs sur son Instance.
• Son nom contient au maximum 50 caractères.
• Si c'est un attribut de type chaîne, sa valeur contient au maximum 50 caractères.

Accès à la simulation

De nombreuses propriétés et méthodes dans la référence API du moteur incluent l'étiquette Accès à la simulation, par exemple BasePart.CFrame. Les propriétés avec cette étiquette seront prédites par le système d'autorité serveur. De plus, seules les propriétés et méthodes avec cette étiquette peuvent être accessibles à l'intérieur de fonctions liées avec RunService:BindToSimulation().

Actions d'entrée

Dans un jeu à autorité serveur, le moyen principal pour un client d'affecter l'état du jeu est par le biais du système d'actions d'entrée. Ces entrées sont envoyées au serveur et sont rejouées lors de la resimulation sur le client. Par conséquent, InputActions devrait être utilisé pour toutes les entrées qui affectent la simulation principale et devraient être vérifiées pour leur validité avant d'être traitées.

Notez que InputContexts doit être un descendant d'un Player afin que le moteur sache qui a la propriété sur le InputContext. Une approche consiste à ajouter vos InputContexts à un dossier sous ReplicatedStorage et à utiliser un Script sous ServerScriptService pour cloner le InputContexts par joueur :

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

En utilisant ce modèle, vous pouvez lire les InputActions pour tous les joueurs dans RunService:BindToSimulation() à la fois sur le client et le serveur pour recevoir les mêmes données pour une frame donnée et enregistrer l'entrée de la frame précédente dans un attribut, par exemple pour déclencher une course de personnage lorsqu'une action d'entrée RunAction est déclenchée.

Événements distants

Les événements distants peuvent encore être utilisés dans le modèle d'autorité serveur pour faciliter la communication discrète entre le client et le serveur. Par exemple, les serveurs peuvent utiliser des événements distants pour diffuser des données sur les joueurs marquant des points ou ramassant des objets, et les clients peuvent utiliser des événements distants comme une API alternative pour envoyer des entrées au serveur, comme pour des pressions de boutons ou des interactions avec des objets dans le monde 3D.

Animations, sons et effets

Les effets côté client comme les animations et les sons doivent être écrits en sachant que la simulation côté client n'est qu'une prédiction de l'état autoritaire du serveur. BindToSimulation() limite quelles propriétés et méthodes peuvent être appelées à partir des fonctions liées pour vous aider à écrire uniquement l'état de simulation synchronisé. L'affichage des résultats de cette simulation, le déclenchement d'effets et de sons, etc. devraient être effectués dans une fonction distincte liée à RenderStepped qui lit les résultats de la simulation et déclenche les effets souhaités.

Des conseils supplémentaires sur le rendu d'une simulation prédites sont couverts dans le guide des techniques avancées.

Projets d'exemple

En plus de cette documentation, les modèles suivants peuvent vous aider à commencer :