Server-Autoritätsmodell

In einem Server-Autoritätsmodell ist der Server die einzige Wahrheitsquelle für den gesamten Spielstatus, und den Clients wird nur vertraut, ihre eigenen Eingaben zu melden. Diese Architektur ist die grundlegende Netcode-Basis eines fairen, wettbewerbsorientierten Spiels, da sie ganze Klassen von Betrug wie Flyhacks oder Speedhacks verhindert, indem sie einem Client niemals vertraut, seine eigene Position oder seinen Status zu melden.

Vorteile

In einem naiven, servergeführten System würden die Clients einfach ihre Eingaben an den Server senden und die Ergebnisse des Spiels anzeigen, die vom Server zurückgesendet werden. Während dies technisch korrekt ist, würde ein solches System erhebliche Eingabeverzögerung aufweisen, da jede Spieleraktion zum Server reisen, verarbeitet werden und das Ergebnis zurück an den Client gesendet werden muss, bevor es angezeigt werden kann. Für die meisten Spiele, insbesondere für schnelle, würde diese Rundreiseverzögerung dazu führen, dass sich das Gameplay verzögert, nicht reaktionsschnell und unspielbar anfühlt.

Im Server-Autoritätsmodell von Roblox wird die Latenz kompensiert, indem die Clients sofort vorhersagen, welche Auswirkungen ihre Eingaben haben, zusätzlich zu der Übermittlung an den Server. Wenn ein Spieler beispielsweise eine Taste drückt, wartet der Client nicht auf die Antwort des Servers, sondern vorhersagt einige Frames vor dem zuletzt bekannten Serverzustand. Dies ermöglicht es dem Client, das Ergebnis der Eingabeaktion sofort anzuzeigen, wodurch die Netzwerkverzögerung effektiv verborgen wird und das Spiel reaktionsschnell erscheint.

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

Wenn eine Fehlvorhersage erkannt wird, muss der Client seine Vorhersage basierend auf dem autoritativem Zustand des Servers korrigieren. Wenn der autoritative Zustand anders ist als der vom Client vorhergesagte Zustand, muss der Client zurückrollen und neu simulieren. Dieses System der Vorhersage, des Zurückrollens und der Neu-Simulation auf der Clientseite wird als "Latenzkompensation" bezeichnet und hilft, serverautoritative Mehrspieler-Spiele reibungslos und reaktionsschnell zu gestalten.

Einrichtung

Das Server-Autoritätsmodell erfordert, dass bestimmte andere Engine-Technologien korrekt funktionieren. Bestätigen Sie die folgenden Eigenschaften auf dem Workspace-Objekt im Explorer:

1. Workspace.AuthorityMode muss Server sein (dies setzt automatisch die folgenden fünf).
2. Workspace.NextGenerationReplication muss aktiviert sein.
3. Workspace.PlayerScriptsUseInputActionSystem muss aktiviert sein.
4. Workspace.SignalBehavior muss Deferred sein.
5. Workspace.UseFixedSimulation muss aktiviert sein.
6. Workspace.StreamingEnabled muss aktiviert sein.

Konzepte

Das Server-Autoritätssystem basiert auf einigen Kernkonzepten:

Client-Vorhersage

Durch Client-Vorhersage simuliert der Client einige Frames vor dem zuletzt bekannten Serverzustand, um sofort die Auswirkungen von Spieler-Eingaben vorherzusagen. Dies verbirgt die Eingabeverzögerung, allerdings kann sich die Vorhersage später als falsch herausstellen (Fehlvorhersage) und muss daher korrigiert werden. Der Client versucht, nur soweit voraus zu simulieren, dass seine Eingaben zum Server im beabsichtigten Frame ankommen. Die Anzahl der Frames, die der Client vor dem bekannten Serverstatus vorhersagt, basiert auf der Verzögerung zwischen Client und Server.

Fehlvorhersage

Wenn der Client den autoritativen Zustand vom Server erhält, überprüft er diesen Zustand gegen eine historische Aufzeichnung dessen, was er lokal für diesen Frame vorhergesagt hat. Wenn es eine Differenz gibt zwischen dem, was der Client vorhergesagt hat, und dem, was der Server tatsächlich getan hat, handelt es sich um eine Fehlvorhersage. Fehlvorhersagen können aus mehreren Gründen auftreten, einschließlich Änderungen in der Netzwerkverzögerung, anderen Spielern, die sich auf Weisen verhalten, die der Client nicht vorhergesehen hat, und der Tatsache, dass bestimmte Logiken ausschließlich auf dem Server ausgeführt werden usw.

Wenn der autoritative Zustand anders ist als der vom Client vorhergesagte Zustand, muss der Client zurückrollen und neu simulieren.

Zurückrollen und neu simulieren

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

Zusammenfassend:

1. Der Client:

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

      1. Setzt sich der Client auf den letzten bekannten autoritativen Zustand zurück, den er vom Server erhalten hat.
      2. Simuliert der Client von dem autoritativen Zustand zu seinem vorhergesagten Zustand zurück und wendet alle lokalen Eingaben erneut an.

Implementierung

Netzwerkbesitz und Vorhersage

Im Server-Autoritätsmodell können Sie die kernwertvollen Spielobjekte serverbesessen halten, ohne die normalerweise mit dem Serverbesitz verbundenen Eingabeverzögerungskosten zu tragen. Dinge wie Autos, Spielercharaktere oder andere spielentscheidende 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, aber wenn Sie mehr feinkörnige Kontrolle wünschen, können Sie die Vorhersage einer Instanz ausdrücklich mit RunService:SetPredictionMode() aktivieren oder deaktivieren.

Simulationssynchronisierung

Im Server-Autoritätsmodell müssen sowohl der Client als auch der Server die zentrale Simulation ausführen, und die Simulation des Clients muss in der Lage sein, beim Auftreten einer Fehlvorhersage zurückzurollen und neu zu simulieren. Um dies zu ermöglichen, schreiben Sie Ihre Kernlogik in Funktionen, die über 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 Funktionen, die über die Simulation gebunden sind, erneut ausführen. Das Verarbeiten von Spieler-Eingaben, das Interagieren mit synchronisierten physikalischen Objekten und das Aktualisieren des zentralen Spielzustands sollten in diesen gebundenen Funktionen erfolgen.

ModuleScript benannt Simulation in ReplicatedStorage:

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

local Simulation = {}

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

return Simulation

Zustands-Synchronisierung 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 diesen Instanzen löst jede Abweichung in den Attributwerten zwischen der Wahrheitsquelle des Servers und der Vorhersage des Clients einen vollständigen Rollback und eine Neu-Simulation aus.

Attribut-Einschränkungen

Ein Attribut muss alle folgenden Kriterien erfüllen, um repliziert zu werden:

• Es ist eines der ersten 64 Attribute seiner Instance.
• Sein Name enthält höchstens 50 Zeichen.
• Wenn es sich um ein Attribut vom Typ String handelt, enthält sein Wert höchstens 50 Zeichen.

Simulationszugriff

Viele Eigenschaften und Methoden in der Engine-API-Referenz enthalten das Label Simulationszugriff, zum Beispiel BasePart.CFrame. Eigenschaften mit diesem Label werden vom Server-Autoritä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.

Eingabeaktionen

In einem serverautoritativen Spiel ist die primäre Möglichkeit für einen Client, den Spielzustand zu beeinflussen, über das Input Action System. Diese Eingaben werden an den Server gesendet und während der Neu-Simulation auf dem Client wiedergegeben. Daher sollte InputActions für alle Eingaben, die die Kernsimulation beeinflussen, verwendet werden, und sie sollten vor der Verarbeitung auf Konsistenz überprüft werden.

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

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 auslesen, um die gleichen Daten für einen bestimmten Frame zu erhalten und die Eingabe des vorherigen Frames in einem Attribut aufzuzeichnen, um beispielsweise eine Charakterbewegung auszulösen, wenn eine RunAction-Eingabeaktion ausgelöst wird.

Remote-Events

Remote-Events können weiterhin innerhalb des Server-Autoritätsmodells verwendet werden, um diskrete Kommunikation zwischen Client und Server zu ermöglichen. Beispielsweise können Server Remote-Events verwenden, um Daten über Spieler, die Punkte erzielen oder Objekte aufheben, zu übermitteln, und Clients können Remote-Events als alternative API verwenden, um Eingaben an den Server zu senden, z.B. für Tastendrucke oder das Tippen auf Objekte in der 3D-Welt.

Animationen, Klänge und Effekte

Effekte auf der Clientseite wie Animationen und Klänge müssen mit dem Wissen geschrieben werden, dass die Client-Simulation lediglich eine Vorhersage des autoritativen Serverstatus ist. BindToSimulation() beschränkt, welche Eigenschaften und Methoden innerhalb gebundener Funktionen aufgerufen werden können, um Ihnen zu helfen, nur in den synchronisierten Simulationszustand zu schreiben. Die Ergebnisse dieser Simulation, das Auslösen von Effekten und Klängen usw. sollten in einer separaten Funktion, die mit RenderStepped verbunden ist und die Ergebnisse der Simulation ausliest, getriggert werden.

Weitere Anleitungen zur Darstellung einer vorhergesagten Simulation sind im Leitfaden zu erweiterten Techniken enthalten.

Beispielprojekte

Neben dieser Dokumentation helfen Ihnen die folgenden Vorlagen, einen Einstieg zu finden: