Model autorytetu serwera

W modelu autorytetu serwera serwer jest jedynym źródłem prawdy dla całego stanu gry, a klienci są jedynie zaufani do raportowania swoich własnych wejść. Ta architektura stanowi podstawę netcode'u sprawiedliwej, konkurencyjnej gry, ponieważ zapobiega całym klasom oszustw, takim jak flyhacks czy speedhacks, nigdy nie ufając klientowi w raportowaniu swojej własnej pozycji lub stanu.

Zalety

W naiwnej systemie własności 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 napotkałby znaczną latencję wejściową, ponieważ każda akcja gracza musiałaby podróżować do serwera, być przetwarzana, a wynik musiałby być wysyłany z powrotem do klienta, zanim mógłby być wyświetlony. W przypadku większości gier, szczególnie tych szybkich, opóźnienie w obiegu spowodowałoby, że rozgrywka wydawałaby się opóźniona, nieodpowiednia i niegrywalna.

W modelu autorytetu serwera Roblox latencja jest kompensowana przez to, że klienci natychmiastowo przewidują efekty swoich wejść, oprócz wysyłania ich do serwera. Na przykład, gdy gracz naciska klawisz, klient nie czeka na odpowiedź serwera; zamiast tego przewiduje kilka klatek do przodu od ostatniego znanego stanu serwera. To pozwala klientowi natychmiast pokazać wynik akcji wejściowej, skutecznie ukrywając latencję sieciową i sprawiając, że gra wydaje się responsywna.

Czasami klient może źle przewidzieć (misprediction), a z powodu latencji sieciowej klient nie będzie wiedział, że popełnił błąd przez kilka klatek. Na przykład:

Gdy wykryta zostanie błędna prognoza, klient musi skorygować swoje przewidywanie na podstawie autorytatywnego stanu serwera. Jeśli stan autorytatywny różni się od przewidywanego stanu klienta, klient musi cofnąć się i ponownie symulować swoje przewidywane klatki. Ten system przewidywania po stronie klienta, cofania i ponownej symulacji jest znany jako "kompensacja latencji" i pomaga sprawić, że wieloosobowe gry oparte na autorytecie serwera wydają się płynne i responsywne.

Konfiguracja

Model autorytetu serwera wymaga pewnych innych technologii silnika, aby działał poprawnie. Potwierdź następujące ustawienia właściwości na obiekcie Workspace w Eksploratorze:

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

Koncepcje

System autorytetu serwera działa na kilku podstawowych koncepcjach, jak poniżej.

Przewidywanie klienta

Dzięki przewidywaniu klienta klient symuluje kilka klatek do przodu od ostatniego znanego stanu serwera, aby natychmiast przewidzieć efekty wejść gracza. To ukrywa latencję wejściową, ale przewidywanie może później okazać się błędne (błędne przewidywanie klienta) i wymagać korekty. Klient stara się symulować wystarczająco daleko do przodu od ostatniego znanego autorytatywnego stanu serwera, aby jego wejścia dotarły do serwera w zamierzonym czasie. Liczba klatek, które klient przewidzi do przodu od znanego stanu serwera, opiera się na latencji między klientem a serwerem.

Błędne przewidywanie klienta

Gdy klient otrzymuje autorytatywny stan z serwera, sprawdza ten stan w porównaniu do historycznego zapisu tego, co przewidział lokalnie dla tej klatki. Gdy występuje różnica między tym, co klient przewidział, a tym, co serwer faktycznie zrobił, jest to błędne przewidywanie. Błędne przewidywania mogą wystąpić z kilku powodów, w tym zmian latencji sieciowej, działań innych graczy, które klient nie przewidział, logiki gry działającej wyłącznie na serwerze itp.

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

Cofanie się i ponowna symulacja

Gdy klient wykryje błędne przewidywanie, musi zresetować się do autorytatywnego stanu serwera, a następnie ponownie symulować, aby wrócić do swojej przewidywanej klatki. Na podstawie latencji sieciowej klient stara się symulować wystarczająco daleko do przodu od ostatniego znanego autorytatywnego stanu serwera, aby jego wejścia dotarły do serwera w zamierzonym czasie.

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 od stanu autorytatywnego do swojego przewidywanego stanu, ponownie stosując wszelkie lokalne wejścia.

Implementacja

Własność sieciowa i przewidywanie

W modelu autorytetu serwera możesz utrzymać podstawowe obiekty rozgrywki jako własność serwera, nie ponosząc kosztów latencji wejściowej, które normalnie są związane z własnością serwera. Takie rzeczy jak samochody, postacie graczy czy inne obiekty krytyczne dla rozgrywki mogą pozostać własnością serwera, nawet gdy wchodzą w interakcje z innymi graczami.

Domyślnie Roblox automatycznie przewiduje właściwości z dostępem do symulacji w pobliżu lokalnego gracza Character, ale jeśli chcesz mieć bardziej szczegółową kontrolę, możesz jawnie wymusić przewidywanie instancji włączone lub wyłączone za pomocą RunService:SetPredictionMode().

Synchronizacja symulacji

W modelu autorytetu serwera klient i serwer muszą obaj uruchamiać podstawową symulację, a symulacja klienta musi być w stanie cofnąć się i ponownie symulować, gdy wystąpi błędne przewidywanie. Aby to umożliwić, napisz swoją logikę podstawową wewnątrz funkcji powiązanych przez RunService:BindToSimulation() w ModuleScript, który jest inicjowany zarówno na kliencie, jak i serwerze.

Podczas ponownej symulacji Roblox ponownie uruchomi funkcje powiązane z symulacją za pomocą BindToSimulation(). Przetwarzanie wejść graczy, interakcja z synchronizowanymi obiektami fizycznymi i aktualizacja podstawowego stanu gry powinny odbywać się wewnątrz tych powiązanych funkcji.

Użyj time() do wszelkiej logiki opartej na czasie wewnątrz powiązanej funkcji symulacji, takiej jak prowadzenie prędkości animacji lub oscylowanie wartości w czasie. Gdy Workspace.AuthorityMode jest ustawione na Enum.AuthorityMode.Server, time() jest synchronizowane między klientem a serwerem i używa stałego czasu symulacji. Podczas ponownej symulacji cofa się do autorytatywnej klatki i postępuje, gdy klient odtwarza klatki, więc zwraca spójną wartość za każdym razem, gdy klatka jest symulowana.

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 takich instancjach wszelkie niezgodności w wartościach atrybutów między źródłem prawdy serwera a przewidywaniem klienta spowodują pełne cofnięcie się i ponowną symulację.

Ograniczenia atrybutów

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

• Jest jednym z pierwszych 64 atrybutów na swoim Instance.
• Jego nazwa zawiera maksymalnie 50 znaków.
• Jeśli jest atrybutem typu string, jego wartość zawiera maksymalnie 50 znaków.

Dostęp do symulacji

Wiele właściwości i metod w dokumentacji 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. Dodatkowo, tylko właściwości i metody z tą etykietą mogą być dostępne wewnątrz funkcji powiązanych z RunService:BindToSimulation().

Akcje wejściowe

W grze opartej na autorytecie serwera głównym sposobem, w jaki klient może wpływać na stan gry, jest System Akcji Wejściowych. Te wejścia są wysyłane do serwera i są odtwarzane podczas ponownej symulacji na kliencie. 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 przed ich przetworzeniem.

Zauważ, że InputContexts musi być potomkiem Player, aby silnik wiedział, kto ma własność nad InputContext. Jednym z podejść jest dodanie swoich 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 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

Używając tego wzorca, możesz odczytać InputActions dla wszystkich graczy w RunService:BindToSimulation() zarówno na kliencie, jak i serwerze, aby otrzymać te same dane dla danej klatki i zarejestrować wejście z poprzedniej klatki w atrybucie, na przykład, aby uruchomić postać, gdy wywołana zostanie akcja wejściowa RunAction.

Zdarzenia zdalne

Zdarzenia zdalne mogą być nadal używane w modelu autorytetu serwera do ułatwienia dyskretnej komunikacji między klientem a serwerem. Na przykład serwery mogą używać zdarzeń zdalnych do nadawania danych o graczach zdobywających punkty lub podnoszących obiekty, a klienci mogą używać zdarzeń zdalnych jako alternatywnego interfejsu API do wysyłania wejść do serwera, takich jak naciśnięcia przycisków lub dotykanie obiektów w świecie 3D.

Animacje, dźwięki i efekty

Efekty po stronie klienta, takie jak animacje i dźwięki, muszą być pisane z myślą, ż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, aby 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 odbywać się w osobnej funkcji połączonej z RenderStepped, która odczytuje wyniki symulacji i wywołuje pożądane efekty.

Dalsze wskazówki dotyczące renderowania przewidywanej symulacji są omówione w przewodniku zaawansowanych technik.

Przykładowe projekty

Oprócz tej dokumentacji, następujące szablony mogą pomóc ci zacząć: