Model autorytetu serwera

W modelu autorytetu serwera, serwer jest jedynym źródłem prawdy dla całego stanu gry, a klienci są jedynie ufani w raportowaniu własnych wejść. Ta architektura stanowi podstawowy fundament netcodu w uczciwej, konkurencyjnej grze, ponieważ zapobiega całym klasom oszustw, takim jak flyhacki czy speedhacki, nigdy nie ufając klientowi w raportowaniu własnej pozycji czy stanu.

Zalety

W naiwnej systemie z autorytetem serwera, klienci po prostu wysyłaliby swoje wejścia do serwera i wyświetlali wyniki gry przesyłane z powrotem przez serwer. Choć technicznie poprawne, taki system miałby znaczną latencję wejściową, ponieważ każda akcja gracza musiałaby dotrzeć do serwera, zostać przetworzona i mieć wynik wysłany z powrotem do klienta, zanim mogłaby zostać wyświetlona. W przypadku większości gier, zwłaszcza tych szybkich, opóźnienie w tej wycieczce spowodowałoby, że rozgrywka wydawałaby się ociężała, nieskuteczna i niegrywalna.

W modelu autorytetu serwera Roblox latencja jest kompensowana poprzez to, że klienci natychmiast przewidują efekty swoich wejść oprócz ich przesyłania do serwera. Na przykład, gdy gracz naciska klawisz, klient nie czeka na odpowiedź serwera; zamiast tego przewiduje kilka klatek do przodu na podstawie ostatniego znanego stanu serwera. Dzięki temu klient może natychmiast pokazać rezultat akcji wejścia, skutecznie ukrywając latencję sieciową i sprawiając, że gra wydaje się responsywna.

Czasami klient może się pomylić w swoim przewidywaniu (misprediction) i, z powodu latencji sieciowej, klient nie będzie wiedział, że popełnił błąd przez kilka klatek. Na przykład:

Kiedy wykryje się błąd w przewidywaniu, klient musi skorygować swoje przewidywanie w oparciu o autorytatywny stan serwera. Jeśli stan autorytatywny różni się od przewidywanego stanu klienta, klient musi cofnąć się i ponownie zasymulować swoje przewidywane klatki. Ten system przewidywania po stronie klienta, cofania się i ponownej symulacji znany jest jako "kompensacja latencji" i pomaga sprawić, że wieloosobowe gry z autorytetem serwera wydają się płynne i responsywne.

Ustawienia

Model autorytetu serwera wymaga, aby niektóre inne technologie silnika działały poprawnie. Potwierdź następujące ustawienia właściwości na obiekcie Workspace w Eksploratorze:

1. Workspace.AuthorityMode musi być Server (ustawienie to automatycznie ustawia następne pięć).
2. Workspace.NextGenerationReplication musi być włączone.
3. Workspace.PlayerScriptsUseInputActionSystem musi być włączone.
4. Workspace.SignalBehavior musi być Deferred.
5. Workspace.UseFixedSimulation musi być włączone.
6. Workspace.StreamingEnabled musi być włączone.

Koncepcje

System autorytetu serwera opiera się na kilku podstawowych koncepcjach.

Przewidywanie klienta

Dzięki przewidywaniu klienta, klient symuluje kilka klatek do przodu w stosunku do ostatniego znanego stanu serwera, aby natychmiast przewidzieć skutki wejść gracza. Ukrywa to latencję wejściową, ale przewidywanie może później okazać się błędne (misprediction) i będzie więc wymagało korekty. Klient próbuje symulować wystarczająco daleko przed ostatnim znanym autorytatywnym stanem serwera, aby jego wejścia dotarły do serwera w odpowiedniej klatce. Liczba klatek, o które klient przewidzi przed znanym stanem serwera, opiera się na latencji między klientem a serwerem.

Błąd w przewidywaniu klienta

Kiedy klient otrzymuje stan autorytatywny z serwera, sprawdza ten stan w stosunku do historycznej rejestracji tego, co przewidywał lokalnie dla tej klatki. Kiedy istnieje różnica między tym, co klient przewidział, a tym, co serwer faktycznie zrobił, to jest to błąd w przewidywaniu. Błędy w przewidywaniu mogą wystąpić z różnych powodów, w tym zmian latencji sieciowej, działań innych graczy, których klient nie przewidział, logicznego przetwarzania wyłącznie na serwerze itp.

Jeśli stan autorytatywny różni się od przewidywanego stanu klienta, klient musi cofnąć się i ponownie zasymulować.

Cofanie się i ponowna symulacja

Kiedy klient wykryje błąd w przewidywaniu, musi zresetować się do autorytatywnego stanu serwera, a następnie ponownie zasymulować, aby wrócić do swojej przewidywanej klatki. Na podstawie latencji sieciowej klient stara się symulować wystarczająco daleko przed ostatnim znanym autorytatywnym stanem serwera, aby jego wejścia dotarły do serwera w odpowiedniej klatce.

Podsumowując, klient:

1. Otrzymuje autorytatywny stan z serwera i porównuje go z własnym przewidywanym stanem.
2. Jeśli przewidywanie klienta było błędne:

   1. Klient cofa się do ostatniego znanego autorytatywnego stanu otrzymanego z serwera.
   2. Klient ponownie symuluje z autorytatywnego stanu do swojego przewidywanego stanu, ponownie stosując wszelkie lokalne wejścia.

Implementacja

Własność sieciowa i przewidywanie

W modelu autorytetu serwera możesz utrzymać główne obiekty rozgrywki jako będące własnością serwera bez ponoszenia kosztów latencji wejściowej, które zwykle są związane z własnością serwera. Takie rzeczy jak auta, postacie graczy czy inne obiekty krytyczne dla rozgrywki mogą pozostawać własnością serwera, nawet podczas interakcji z innymi graczami.

Domyślnie, Roblox automatycznie przewidzi właściwości z dostępem do symulacji w pobliżu lokalnego gracza Character, ale jeśli chcesz mieć więcej szczegółowej kontroli, możesz wymusić przewidzenie instancji włączonej lub wyłączonej za pomocą RunService:SetPredictionMode().

Synchronizacja symulacji

W modelu autorytetu serwera klient i serwer muszą uruchamiać podstawową symulację, a symulacja klienta musi być w stanie cofnąć się i ponownie zasymulować w przypadku wystąpienia błędu w przewidywaniu. Aby to umożliwić, napisz swoją podstawową logikę wewnątrz funkcji powiązanych przez RunService:BindToSimulation() w ModuleScript, który jest inicjowany zarówno po stronie klienta, jak i serwera.

Podczas ponownej symulacji, Roblox ponownie uruchomi funkcje powiązane z symulacją za pomocą BindToSimulation(). Przetwarzanie wejść graczy, interakcja z synchronizowanymi obiektami fizycznymi oraz aktualizacja stanu gry powinny znajdować się w tych powiązanych funkcjach.

ModuleScript nazwany Symulacja w ReplicatedStorage:

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

local Symulacja = {}

Symulacja.Initialize = function()
	RunService:BindToSimulation(function(deltaTime)
		-- Odczytaj wejścia graczy
		-- Zaktualizuj stan gry
	end)
end

return Symulacja

Synchronizacja stanu z atrybutami

Roblox automatycznie synchronizuje wszystkie właściwości z dostępem do symulacji na przewidywanych instancjach. Dla danych niestandardowych, atrybuty są głównym sposobem synchronizacji instancji oznaczonych jako przewidywane; w przypadku takich instancji każda niezgodność w wartościach atrybutów między źródłem prawdy serwera a przewidywaniem klienta wyzwoli pełne cofnięcie się i ponowną symulację.

Ograniczenia atrybutów

Aby atrybut mógł być replikowany, musi spełniać wszystkie poniższe kryteria:

• Należy do pierwszych 64 atrybutów na swoim Instance.
• Jego nazwa może zawierać najwyżej 50 znaków.
• Jeśli jest atrybutem typu ciąg, jego wartość może zawierać najwyżej 50 znaków.

Dostęp do symulacji

Wiele właściwości i metod w odniesieniu do API silnika zawiera etykietę Dostęp do symulacji, na przykład BasePart.CFrame. Właściwości z tą etykietą będą przewidywane przez system autorytetu serwera. Ponadto tylko właściwości i metody z tą etykietą mogą być dostępne w funkcjach powiązanych z RunService:BindToSimulation().

Akcje wejściowe

W grze z autorytetem serwera głównym sposobem, w jaki klient może wpłynąć na stan gry, jest System Akcji Wejściowych. Te wejścia są przesyłane do serwera i są odtwarzane podczas ponownej symulacji po stronie klienta. W związku z tym, InputActions powinny być używane do wszystkich wejść, które wpływają na podstawową symulację i powinny być sprawdzane pod kątem poprawności, zanim zostaną przetworzone.

Zauważ, że InputContexts musi być potomkiem Player, aby silnik wiedział, kto ma własność nad InputContext. Jednym ze sposobów jest dodanie InputContexts do folderu w ReplicatedStorage i użycie Script w ServerScriptService, aby sklonować InputContexts dla każdego gracza:

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

local FunkcjaWejść = ReplicatedStorage:WaitForChild("Inputs")

local function onPlayerAdded(player)
	local clone = FunkcjaWejść:Clone()
	clone.Parent = player
end

Players.PlayerAdded:Connect(onPlayerAdded)

for _, player in Players:GetPlayers() do
	onPlayerAdded(player)
end

Używając tego wzorca, możesz odczytać InputActions dla wszystkich graczy w RunService:BindToSimulation() zarówno po stronie klienta, jak i serwera, aby otrzymać te same dane dla danej klatki i zapisać wejście z poprzedniej klatki w atrybucie, na przykład w celu wywołania biegu postaci, gdy wywołana zostanie akcja wejściowa RunAction.

Zdalne zdarzenia

Zdalne zdarzenia mogą być nadal używane w modelu autorytetu serwera, aby ułatwić dyskretną komunikację między klientem a serwerem. Na przykład serwery mogą używać zdalnych zdarzeń do transmitowania danych o punktacji graczy lub podnoszeniu przedmiotów, a klienci mogą używać zdalnych zdarzeń jako alternatywnego interfejsu API do przesyłania wejść do serwera, na przykład w przypadku naciśnięcia przycisku lub stuknięcia w obiekty w wirtualnym świecie 3D.

Animacje, dźwięki i efekty

Efekty klienckie, takie jak animacje i dźwięki, muszą być pisane z wiedzą, że symulacja klienta jest jedynie przewidywaniem autorytatywnego stanu serwera. BindToSimulation() ogranicza, jakie właściwości i metody mogą być wywoływane z wewnątrz powiązanych funkcji, by pomóc w pisaniu tylko do zsynchronizowanego stanu symulacji. Wyświetlanie wyników tej symulacji, wywoływanie efektów i dźwięków itp. powinno być realizowane w oddzielnej funkcji połączonej z RenderStepped, która odczytuje wyniki symulacji i wywołuje pożądane efekty.

Dalsze wskazówki dotyczące renderowania przewidzianej symulacji są omówione w przewodniku po zaawansowanych technikach.

Przykładowe projekty

Oprócz tej dokumentacji, następujące szablony mogą pomóc w rozpoczęciu: