Logika gry na serwerze! Dobry czy zły?

Obecnie planuję prostą grę online dla wielu graczy. I oto pytanie. Czy warto logować całą grę na serwerze i wysyłać dane wejściowe od klienta na serwer? Jakie są zalety i wady, czy istnieją powody, dla których nie powinienem tego robić?

Nie chcesz wysyłać danych odtwarzacza na serwer. To, co prawdopodobnie chcesz zrobić, to wysłać abstrakcyjne przedstawienie tego, co gracz chce zrobić na serwer, a następnie uruchomić tam logikę.

Podobnie niekoniecznie chcesz odesłać wszystko, co klient musi zrobić. Na przykład możesz wysłać wiadomość z informacją „NPC X umarł”, a klient określa, jaką animację / dźwięki zagrać. Takie rzeczy.

Sztuką jest znalezienie linii, w której przepustowość i moc obliczeniowa (na serwerze) są atutami, uniemożliwiając oszustwo. Zwykle podejmujesz decyzję zmieniającą grę wyłącznie na serwerze i pozostawiasz wszystkie dodatkowe elementy wizualne klientowi.

Na stronie jest wiele bardziej szczegółowych pytań na ten temat. Na przykład:

Czy wykrywanie kolizji powinno odbywać się po stronie serwera czy kooperacyjnie między klientem / serwerem?

Kto wykonuje obliczenia AI w MMO?

Czy gospodarzem gry powinien być władza, czy inny głupi klient?

Masz odpowiedzi, ale twoją prawdziwą odpowiedzią jest „spróbuj sam”. Rzeczy różnią się w zależności od gry.

Zrobiłem kilka gier wieloosobowych na kurs z rozproszonego projektowania gier sieciowych. Najtrudniejsze było stworzenie gry akcji w czasie rzeczywistym, w której wielu graczy było zaangażowanych, i przesyłało informacje jak diabli. W tym momencie wszystko staje się problemem. Jak widzisz pierwszy link wysłany przez Tetrat, nawet ustalenie zmowy staje się problemem. Będziesz czytać terminy, takie jak lag, interpolacja, ekstrapolacja, przewidywanie ... Ale jeśli nigdy nie próbowałeś kodować od zera, po prostu zaakceptujesz te słowa i nie będziesz wiedział, co one naprawdę oznaczają.

Moja rekomendacja to:

Krok 1
Na razie zacznij od w pełni autoryzowanego projektowania opartego na serwerze. Jak powiedziałeś, po prostu wyślij dane wejściowe użytkownika na serwer i pozwól serwerowi zrobić wszystko, a klienci uzyskają wyniki. Twoja gra będzie działać w pełni spójnie. Ale kiedy spojrzysz na swoich klientów, zauważysz pewne opóźnienia, pewne problemy z teleportacją, a nie płynny ruch ... ect.

Krok 2
Rozpocznij rozwiązywanie problemów po stronie klienta. Na przykład problemy z teleportacją. Twoja postać była na (0,0), a serwer powiedział, że jesteś na (100,100). Twoja postać po prostu teleportuje się na (100,100), co nie jest miłe. Nadchodzi interpolacja. Po stronie klienta powinieneś mieć kod, który płynnie przesunie znak z (0,0) na (100, 100). Tak, przeniesiesz swoją postać z (0,0) na (100,100), ale jak szybko? Na razie możesz po prostu użyć różnicy czasu między każdą aktualizacją serwera. Jeśli Twój serwer wysyła 10 pakietów w ciągu sekundy, co oznacza 100 ms opóźnienie między każdym pakietem.

Krok 3
Teraz Twoja gra jest już dobra dla szybkich sieci, w których występuje opóźnienie (1-50) ms. Ale staje się to skazane, jeśli nastąpi utrata pakietu, duże opóźnienie lub obliczenia zajmą dużo czasu na serwerze ... ect. W takich sytuacjach zauważysz, gdy naciśniesz lewą strzałkę, zobaczysz, że twoja postać porusza się w lewo z opóźnieniem 200 ms. Opóźnienie między pakietem idzie na serwer, czas obliczeń i wraca do ciebie z ostatnią pozycją. To źle, najgorsza wada autoryzowanego projektu serwera. Gracz chce, aby jego postać przesunęła się w lewo, gdy tylko naciska on w lewo, nie możesz zmusić go do czekania. Na szczęście klient ma również ten sam kod co serwer, więc dlaczego nie wykonać go natychmiast na kliencie i naprawić ostateczny wynik z odpowiedzią z serwera? To jest podstawowa prognoza wejściowa. Klient naciska w lewo, kod po jego stronie przesunie go w lewo, po pewnym czasie powiedzmy 200 ms, rzeczywista pozycja pochodzi z serwera, a klient koryguje swoją pozycję za jej pomocą. Jeśli wszystko pójdzie dobrze, klient niczego nie zauważy, „krok 2” również nam w tym pomoże.

Cóż, sieć ma wiele samouczków i różnych rzeczy na ten temat. Ale są 2, które naprawdę lubię:

Naprawdę dobre, obejmuje ciemne punkty: Sieć dla wielu graczy Valve-Source Engine
Rodzaj historii, fajna do czytania i tego warta: 1500 łuczników na 28,8 ,

Plusy:

• takie podejście jest bardziej (najbardziej) odporne na piractwo
• łatwiej można zastosować aktualizacje
• scentralizowana społeczność

Cons:

• ogromne wymagania dotyczące przepustowości
• niektórzy użytkownicy mogą nie znosić tego podejścia (prywatność i inne rzeczy)
• problemy z lokalną rozgrywką (imprezy LAN), jednoosobowy

Logika po stronie serwera stwarza również problemy ze skalowalnością - musisz wykonać całą pracę dla wszystkich klientów na swoim serwerze - pozwala to każdemu klientowi na wykonanie własnego udziału w całej pracy.

Zależy od tego, jaką grę chcesz stworzyć i jaką część gry. Jeśli opracowujesz RTS (lub dowolną grę z zablokowanym modelem), zdecydowanie powinieneś wysłać tylko dane wejściowe i etap symulacji, który otrzymano.

Jeśli chcesz zrobić strzelankę, możesz użyć zarówno funkcji wejściowych, jak i abstrakcyjnych. Jeśli weźmiesz Unreal Tournament 3, stworzyli grę wieloosobową głównie poprzez replikowane wywołania funkcji.
Do ruchu pobierają dane wejściowe odtwarzacza (skompresowane w jednym bicie dla każdej akcji) delta rotacji, przyspieszenia i znacznik czasu i wysyłają je na serwer.
Do innych celów, takich jak broń, synchronizują się podczas strzelania (AFAIK, nie zagłębiłem się jeszcze w tę część).
W przypadku bardziej statycznych / rzadziej zmienianych wartości, takich jak kondycja, wysyłają zmienną do klienta lub serwera, w zależności od tego, co określił programista.

W przypadku gier innych niż RTS pamiętaj o prognozach klientów.