Modèle d'autorité du serveur

Dans un modèle d'autorité du serveur, le serveur est la seule source de vérité pour l'état entier du jeu, et les clients ne sont de confiance que pour rapporter leurs propres entrées. Cette architecture est le fondement du code réseau d'un jeu compétitif équitable car elle empêche toute une classe de tricheries telles que les hacks de vol ou de vitesse en ne faisant jamais confiance à un client pour rapporter sa propre position ou état.

Avantages

Dans un système de propriété du serveur naïf, les clients enverraient simplement leurs entrées au serveur et afficheraient les résultats du jeu renvoyés par le serveur. Bien que techniquement correct, un tel système souffrirait d'une latence d'entrée significative car chaque action du joueur devrait voyager jusqu'au serveur, être traitée, et avoir le résultat renvoyé au client avant de pouvoir être affichée. Pour la plupart des jeux, en particulier ceux au rythme rapide, ce délai aller-retour rendrait le gameplay lent, non réactif et injouable.

Dans le modèle d'autorité du 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 que le serveur réponde ; au lieu de cela, il prédit quelques images à l'avance de l'état serveur connu. Cela permet au client d'afficher instantanément le résultat de l'action d'entrée, masquant efficacement la latence réseau et rendant le jeu réactif.

Parfois, le client fera une erreur de prédiction (misprediction) et, en raison de la latence réseau, le client ne saura pas qu'il a fait une erreur pendant quelques images. 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 images 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

Comme le modèle d'autorité du serveur nécessite certaines autres technologies du moteur pour fonctionner correctement, vous devez d'abord définir les propriétés suivantes sur l'objet Workspace dans l'Explorateur :

1. Workspace.NextGenerationReplication doit être activé
2. Workspace.PlayerScriptsUseInputActionSystem doit être activé
3. Workspace.SignalBehavior doit être Deferred
4. Workspace.UseFixedSimulation doit être activé
5. Workspace.StreamingEnabled doit être activé
6. Workspace.AuthorityMode doit être Server (tout ce qui précède doit être défini en premier)

Concepts

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

Prédiction du client

Grâce à la prédiction du client, le client simule quelques images à l'avance de l'état serveur connu pour prédire immédiatement les effets des entrées du joueur. Cela masque la latence d'entrée, mais la prédiction peut plus tard s'avérer incorrecte (misprediction du client) et donc nécessiter une correction. Le client essaie de simuler juste assez à l'avance de l'état serveur autoritaire connu de manière à ce que ses entrées arrivent sur le serveur à l'image prévue. Le nombre d'images que le client prédira à l'avance de l'état serveur connu est basé sur la latence entre le client et le serveur.

Misprediction du client

Lorsque le client reçoit l'état autoritaire du serveur, il vérifie cet état contre un enregistrement historique de ce qu'il a prédit localement pour cette image. 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. Les erreurs de prédiction peuvent se produire pour plusieurs raisons, y compris les variations de la latence réseau, d'autres joueurs agissant de manière que le client n'avait pas anticipée, le jeu exécutant certaines logiques 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 puis resimuler pour revenir à son image prédite. En fonction de la latence réseau, le client essaie de simuler juste assez à l'avance de l'état autoritaire serveur connu pour que ses entrées arrivent sur le serveur à l'image 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écemment reçu du serveur.
   2. Le client resimule de l'état autoritaire à 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é du serveur, vous pouvez conserver les objets de gameplay principaux en possession du serveur sans encourir le coût de latence d'entrée normalement associé à cette propriété serveur. Des choses comme des voitures, des personnages joueurs ou d'autres objets critiques du gameplay peuvent rester en possession du serveur, même lorsqu'ils interagissent avec d'autres joueurs.

Par défaut, Roblox prédira automatiquement les propriétés avec accès à la simulation près du joueur local Character, mais si vous voulez un contrôle plus granulaire, vous pouvez explicitement forcer la prédiction d'une instance à être activée ou désactivée avec RunService:SetPredictionMode().

Synchronisation de simulation

Dans le modèle d'autorité du 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 permettre cela, écrivez votre logique principale à l'intérieur de fonctions liées par RunService:BindToSimulation() dans un ModuleScript qui est initialisé à la fois sur le client et le serveur.

Lors d'une resimulation, Roblox exécute à nouveau 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 principal du jeu devraient se faire à l'intérieur de ces fonctions liées.

ModuleScript nommé Simulation dans ReplicatedStorage :

Simulation
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 accès à la simulation sur les 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 arrière et une resimulation complets.

Limites des attributs

Pour être répliqué, un attribut doit remplir tous les critères suivants :

• Il figure parmi les 64 premiers attributs de son Instance.
• Son nom comporte au maximum 50 caractères.
• Si un attribut de type chaîne, sa valeur comporte 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é du serveur. De plus, seules les propriétés et méthodes avec cette étiquette peuvent être accessibles à l'intérieur des fonctions liées via RunService:BindToSimulation().

Actions d'entrée

Dans un jeu à autorité serveur, le moyen principal pour un client d'affecter l'état du jeu est à travers le Système d'Action 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 doit être utilisé pour toutes les entrées qui affectent la simulation principale et elles doivent ê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 possède le InputContext. Une approche consiste à ajouter vos InputContexts à un dossier sous ReplicatedStorage et à utiliser un Script sous ServerScriptService pour cloner les InputContexts par joueur :

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

En utilisant ce modèle, vous pouvez lire 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 image donnée et enregistrer l'entrée de l'image 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.

Notez que si vous devez écrire des données personnalisées dans le Système d'Action d'Entrée, vous devez utiliser une fonction connectée à RunService.RenderStepped ou RunService:BindToRenderStep(), pas RunService:BindToSimulation(). Déclencher un InputAction dans BindToSimulation() peut amener les clients à produire des résultats incorrects lors d'une resimulation.

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

RunService:BindToRenderStep("CameraInput", Enum.RenderPriority.Last.Value, function()
	-- Envoyer le vecteur avant de la caméra du client au serveur via une InputAction
	local cameraForwardInputAction = Players.LocalPlayer.PlayContext.CameraForward
	local cameraForwardVector = Workspace.CurrentCamera.CFrame.LookVector
	cameraForwardInputAction:Fire(cameraForwardVector)
end)

Événements à distance

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

Animations, sons et effets

Les effets côté client tels que 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 les propriétés et méthodes pouvant être appelées à partir de fonctions liées pour vous aider à écrire uniquement à l'état de simulation synchronisé. Afficher les résultats de cette simulation, déclencher des effets et des sons, etc. devrait être fait dans une fonction séparée connectée à RenderStepped qui lit les résultats de la simulation et déclenche les effets souhaités.

D'autres conseils concernant le rendu d'une simulation prédite sont couverts dans le guide techniques avancées.

Projets d'exemple

En plus de cette documentation, les modèles suivants peuvent vous aider à démarrer :