Server-Autoritätsmodell

In einem Server-Autoritätsmodell ist der Server die einzige Wahrheitsquelle für den gesamten Spielzustand, und Clients dürfen nur ihre eigenen Eingaben melden. Diese Architektur ist das grundlegende Netzwerkfundament eines fairen, wettbewerbsorientierten Spiels, da sie gesamte Klassen von Cheats wie Flyhacks oder Speedhacks verhindert, indem sie niemals darauf vertraut, dass ein Client seine eigene Position oder seinen Zustand meldet.

Vorteile

In einem naiven, serverbesessenen System würden die Clients einfach ihre Eingaben an den Server senden und die Ergebnisse des Spiels anzeigen, die vom Server zurückgesendet werden. Obwohl dies technisch korrekt ist, würde ein solches System signifikante Eingabeverzögerungen aufweisen, da jede Spieleraktion zum Server reisen, verarbeitet und das Ergebnis an den Client zurückgesendet werden muss, bevor es angezeigt werden kann. Für die meisten Spiele, insbesondere für schnelllebige, würde diese Hin- und Rückreiseverzögerung dazu führen, dass das Gameplay verzögert, nicht reaktionsschnell und unspielbar erscheint.

Im Server-Autoritätsmodell von Roblox wird die Latenz dadurch kompensiert, dass Clients sofort die Auswirkungen ihrer Eingaben vorhersagen und diese zusätzlich an den Server senden. Wenn zum Beispiel ein Spieler eine Taste drückt, wartet der Client nicht auf eine Antwort vom Server; stattdessen vorhersagt er einige Frames im Voraus auf den zuletzt bekannten Serverzustand. Dies ermöglicht es dem Client, das Ergebnis der Eingabewirkung sofort anzuzeigen und effektiv die Netzwerkverzögerung zu verbergen, wodurch das Spiel reaktionsschnell erscheint.

Manchmal wird die Vorhersage des Clients falsch sein (Fehlvorhersage) und aufgrund der Netzwerkverzögerung wird der Client nicht wissen, dass er einen Fehler gemacht hat, bis ein paar Frames vergangen sind. Zum Beispiel:

Wenn eine Fehlvorhersage erkannt wird, muss der Client seine Vorhersage basierend auf dem autoritiven Zustand des Servers korrigieren. Wenn der autoritative Zustand vom vorhergesagten Zustand des Clients abweicht, muss der Client zurückrollen und neu simulieren. Dieses System der klientseitigen Vorhersage, Rücksetzung und Neu-Simulation wird als "Latenzkompensation" bezeichnet und hilft, serverautoritare Mehrspieler-Spiele reibungslos und reaktionsschnell zu gestalten.

Einrichtung

Da das Server-Autoritätsmodell bestimmte andere Engine-Technologien benötigt, um ordnungsgemäß zu funktionieren, müssen Sie zuerst die folgenden Eigenschaften des Workspace-Objekts im Explorer festlegen:

1. Workspace.NextGenerationReplication muss aktiviert sein
2. Workspace.PlayerScriptsUseInputActionSystem muss aktiviert sein
3. Workspace.SignalBehavior muss Deferred sein
4. Workspace.UseFixedSimulation muss aktiviert sein
5. Workspace.StreamingEnabled muss aktiviert sein
6. Workspace.AuthorityMode muss Server sein (alle oben genannten müssen zuerst festgelegt werden)

Konzepte

Das System der Serverautorisierung basiert auf einigen Kernkonzepten wie folgt.

Client-Vorhersage

Durch Client-Vorhersage simuliert der Client einige Frames vor dem zuletzt bekannten Serverzustand, um die Auswirkungen der Spieleraktionen sofort vorherzusagen. Dies verbirgt die Eingabeverzögerung, aber die Vorhersage kann sich später als falsch herausstellen (Client-Fehlvorhersage) und muss daher korrigiert werden. Der Client versucht, sich nur so weit im Voraus zu simulieren, dass seine Eingaben beim Server im vorgesehenen Frame ankommen. Die Anzahl der Frames, die der Client im Voraus vor dem bekannten Serverzustand vorhersagen wird, basiert auf der Latenz zwischen Client und Server.

Client-Fehlvorhersage

Wenn der Client den autoritativen Zustand vom Server erhält, überprüft er diesen Zustand gegen einen historischen Verlauf, was er lokal für diesen Frame vorhergesagt hat. Wenn es eine Abweichung zwischen dem gibt, was der Client vorhergesagt hat, und dem, was der Server tatsächlich gemacht hat, ist dies eine Fehlvorhersage. Fehlvorhersagen können aus verschiedenen Gründen auftreten, z. B. durch Schwankungen in der Netzwerkverzögerung, andere Spieler, die sich anders verhalten, als der Client es erwartet hat, das Spiel, das bestimmte Logik ausschließlich auf dem Server ausführt, usw.

Wenn der autoritative Zustand vom vorhergesagten Zustand des Clients abweicht, muss der Client zurückrollen und neu simulieren.

Rücksetzung und Neu-Simulation

Wenn ein Client eine Fehlvorhersage erkennt, muss er zum autoritativen Zustand des Servers zurücksetzen und dann neu simulieren, um zum vorhergesagten Frame zurückzuspringen. Basierend auf der Netzwerkverzögerung versucht der Client, nur so weit im Voraus zu simulieren, dass seine Eingaben beim Server im vorgesehenen Frame ankommen.

Zusammenfassend:

1. Der Client empfängt den autoritiven Zustand vom Server und vergleicht ihn mit seinem eigenen vorhergesagten Zustand.
2. Wenn die Vorhersage des Clients falsch war:

   1. Der Client rollt auf den zuletzt bekannten autoritativen Zustand zurück, der vom Server empfangen wurde.
   2. Der Client simuliert vom autoritativen Zustand bis zu seinem vorhergesagten Zustand neu und wendet alle lokalen Eingaben erneut an.

Implementierung

Netzwerkbesitz und Vorhersage

Im Server-Autoritätsmodell können Sie die Kernspielobjekte serverbesessen halten, ohne die normalerweise mit dem Serverbesitz verbundenen Eingabeverzögerungen zu erleiden. Dinge wie Autos, Spielercharaktere oder andere für das Gameplay kritische Objekte können serverbesessen bleiben, auch wenn sie mit anderen Spielern interagieren.

Standardmäßig wird Roblox automatisch Eigenschaften mit Simulationszugriff in der Nähe des lokalen Spielers Character vorhersagen, doch wenn Sie eine genauere Kontrolle wünschen, können Sie die Vorhersage einer Instanz gezielt aktivieren oder deaktivieren mit RunService:SetPredictionMode().

Simulationssynchronisation

Im Server-Autoritätsmodell müssen sowohl der Client als auch der Server die Kernsimulation ausführen, und die Simulation des Clients muss in der Lage sein, zurückzurollen und neu zu simulieren, wenn eine Fehlvorhersage auftritt. Um dies zu ermöglichen, schreiben Sie Ihre Kernlogik innerhalb von Funktionen, die durch RunService:BindToSimulation() in einem ModuleScript gebunden sind, das sowohl auf dem Client als auch auf dem Server initialisiert wird.

Während einer Neu-Simulation wird Roblox die an die Simulation gebundenen Funktionen über BindToSimulation() erneut ausführen. Die Verarbeitung von Spieler-Eingaben, die Interaktion mit synchronisierten Physikobjekten und die Aktualisierung des Kernspielzustands sollten in diesen gebundenen Funktionen stattfinden.

ModuleScript mit dem Namen Simulation in ReplicatedStorage:

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

local Simulation = {}

Simulation.Initialize = function()
	RunService:BindToSimulation(function(deltaTime)
		-- Spieler-Eingaben lesen
		-- Spielzustand aktualisieren
	end)
end

return Simulation

Zustands synchronisation mit Attributen

Roblox synchronisiert automatisch alle Eigenschaften mit Simulationszugriff auf vorhergesagten Instanzen. Für benutzerdefinierte Daten sind Attribute der primäre Weg, um Instanzen zu synchronisieren, die als vorhergesagt markiert sind; bei solchen Instanzen wird jede Abweichung in den Attributwerten zwischen der authentischen Quelle des Servers und der Vorhersage des Clients eine vollständige Rücksetzung und Neu-Simulation auslösen.

Attributgrenzen

Um repliziert zu werden, muss ein Attribut alle folgenden Kriterien erfüllen:

• Es gehört zu den ersten 64 Attributen auf seiner Instance.
• Sein Name enthält höchstens 50 Zeichen.
• Wenn es sich um einen Attributtyp handelt, darf der Wert höchstens 50 Zeichen enthalten.

Simulationszugriff

Viele Eigenschaften und Methoden in der Engine-API-Referenz enthalten das Simulationszugriffs-Label, zum Beispiel BasePart.CFrame. Eigenschaften mit diesem Label werden vom Serverautoritätssystem vorhergesagt. Darüber hinaus können nur Eigenschaften und Methoden mit diesem Label innerhalb von Funktionen aufgerufen werden, die mit RunService:BindToSimulation() gebunden sind.

Eingabemaßnahmen

In einem serverautoritativem Spiel ist der primäre Weg, wie ein Client den Spielzustand beeinflussen kann, das Input Action System. Diese Eingaben werden an den Server gesendet und während der Neu-Simulation auf dem Client wiederholt. Daher sollte InputActions für alle Eingaben, die die Kernsimulation beeinflussen verwendet werden, und sie sollten vor der Verarbeitung auf Plausibilität überprüft werden.

Beachten Sie, dass InputContexts ein Nachkomme von Player sein muss, damit die Engine weiß, wer das InputContext besitzt. Ein Ansatz besteht darin, Ihre InputContexts in einen Ordner unter ReplicatedStorage hinzuzufügen und ein Script unter ServerScriptService zu verwenden, um die InputContexts pro Spieler zu klonen:

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

Mit diesem Muster können Sie InputActions für alle Spieler in RunService:BindToSimulation() sowohl auf dem Client als auch auf dem Server lesen, um dieselben Daten für einen bestimmten Frame zu empfangen und die Eingabe des vorherigen Frames in einem Attribut zu speichern, zum Beispiel, um einen Charakterlauf auszulösen, wenn eine RunAction Eingabemaßnahme aktiviert wird.

Beachten Sie, dass Sie, wenn Sie benutzerdefinierte Daten in das Input Action System schreiben müssen, eine Funktion verwenden sollten, die mit RunService.RenderStepped oder RunService:BindToRenderStep() verbunden ist, nicht RunService:BindToSimulation(). Das Auslösen einer InputAction in BindToSimulation() kann dazu führen, dass Clients während einer Neu-Simulation falsche Ergebnisse produzieren.

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

RunService:BindToRenderStep("CameraInput", Enum.RenderPriority.Last.Value, function()
	-- Sendet den Vorwärtsvektor der Kamera des Clients an den Server über eine InputAction
	local cameraForwardInputAction = Players.LocalPlayer.PlayContext.CameraForward
	local cameraForwardVector = Workspace.CurrentCamera.CFrame.LookVector
	cameraForwardInputAction:Fire(cameraForwardVector)
end)

Remote-Events

Remote-Events können weiterhin innerhalb des Server-Autoritätsmodells verwendet werden, um die diskrete Kommunikation zwischen Client und Server zu erleichtern. Zum Beispiel können Server Remote-Events nutzen, um Daten über Spieler, die Punkte erzielen oder Objekte aufnehmen, zu übertragen, und Clients können Remote-Events als alternative API verwenden, um Eingaben an den Server zu senden, z. B. für Tastendrucke oder Berührungen von Objekten in der 3D-Welt.

Animationen, Geräusche und Effekte

Client-seitige Effekte wie Animationen und Geräusche müssen so geschrieben werden, dass die Client-Simulation nur eine Vorhersage des autoritativen Serverzustands ist. BindToSimulation() beschränkt die Eigenschaften und Methoden, die innerhalb von gebundenen Funktionen aufgerufen werden können, um Ihnen zu helfen, nur auf den synchronisierten Simulationszustand zu schreiben. Das Anzeigen der Ergebnisse dieser Simulation, das Auslösen von Effekten und Geräuschen usw. sollte in einer separaten Funktion erfolgen, die mit RenderStepped verbunden ist und die Ergebnisse der Simulation liest und die gewünschten Effekte auslöst.

Weiterführende Hinweise zur Darstellung einer vorhergesagten Simulation sind im Leitfaden zu fortgeschrittenen Techniken zu finden.

Beispiels Projekte

Neben dieser Dokumentation können die folgenden Vorlagen Ihnen dabei helfen, zu starten: