sieciowanie dla wielu graczy z fizyką

Jestem ciekawy, jak w grach wyścigowych zaimplementowano sieciową rozgrywkę wieloosobową z fizyką. Mamy świat fizyczny z wieloma szybko poruszającymi się pojazdami kontrolowanymi przez różnych ludzi. Powiedzmy, że pojazdy mają broń i mogą się strzelać (Twisted Metal, Vigilante v8)

Niepokoją mnie uderzenia i kolizje. Autorytatywny serwer czy lepsza alternatywa?

physics networking synchronization

— Vitali Kotik
źródło

Zazwyczaj używany jest serwer, który przechowuje stan „prawdy”, który jest okresowo udostępniany klientom. Kolizje zdarzają się niezależnie w klientach i serwerach, a stany klientów są szacowane na podstawie poprzednich stanów przy użyciu procesu podobnego do tego, co zwykle nazywa się Dead Reckoning . Gdy stan serwera osiągnie klienta, jeśli występują różnice, klient dokonuje przejścia z obecnego stanu do stanu, który właśnie otrzymał głównie przez interpolację.

Jednak przy wielu obiektach kolizje mogą być prawdziwym problemem, dlatego często robi się to, aby utrzymać symulowany czas Klientów nieco za symulowanym czasem serwera, aby umożliwić różne dodatkowe poziomy elastyczności. Ten artykuł o kodzie sieciowym Valve Source Engine jest dość objaśniający. Ponadto, jeśli nadal nie jesteś zdecydowany, jakiego oprogramowania / biblioteki sieciowej użyć, proponuję zajrzeć do RakNet i jego komponentu „ReplicaManager3” .

— Neenster
źródło

Możesz zrobić kilka rzeczy.

Możesz scentralizować wszystkie obiekty fizyki na serwerze i zsynchronizować współrzędne z obiektami graczy na wszystkich klientach. Jest to najłatwiejszy i działa bez wielu wad, jednak zużywa dużo zasobów i wymaga dużej przepustowości. Możesz zoptymalizować wykorzystanie przepustowości, wysyłając tylko wartości do odtwarzacza innych graczy, które znajdują się w określonym promieniu.
Możesz zrobić, jak wspomniano Neenster, a serwer i klienci symulują fizykę, co jakiś czas serwer będzie poprawiał klientów. Oznacza to, że wszyscy klienci obliczają własną fizykę dla każdego gracza, a Ty zsynchronizujesz naciśnięcia klawiszy na serwerze, podając trajektorię każdego gracza na każdym kliencie. Co powiedzmy, 5 sekund, serwer rozgłasza swoją symulację fizyki i wszyscy klienci akceptują zmianę. Może to powodować niewielkie przesunięcia, które są niezauważalne przez większość czasu, ale podczas opóźnienia sieci i utraty pakietów (nieuniknione przy dużym ruchu UDP) zauważysz, że Twój odtwarzacz i / lub inni gracze migają wokół ekranu i szybko zmieniają pozycję. słowo?).
Możesz poprosić każdego klienta o obliczenie własnej fizyki i zsynchronizowanie jego współrzędnych. Utrudnia to symulację fizyki obiektów współdzielonych przez klientów. Jest to dość złożona koncepcja do wdrożenia, jeśli chcesz zrobić coś sprytnego, ponieważ określony obiekt niekoniecznie należy do żadnego klienta.

Pierwszy jest prawdopodobnie najłatwiejszy i powinien pozwolić ci mieć około 4-5 graczy z niewielkim opóźnieniem. Wymagałoby to, aby każde dopasowanie miało własny serwer. Jeśli robisz mecze w sieci LAN, jest to dobra droga.

Drugi jest prawdopodobnie najbardziej praktyczny, jednak może być trudny do wdrożenia. Uruchamianie symulacji fizyki na serwerze jest również bardzo przydatne. Jeśli masz scentralizowane serwery, prawdopodobnie będziesz musiał załadować saldo na kilka komputerów, być może pozwolić na 10 dopasowań na serwer, załadować nowe dopasowania na serwer z najmniejszymi dopasowaniami.

Trzeci jest zdecydowanie najmniej stresujący na serwerze i jest prawdopodobnie najlepszym rozwiązaniem, jeśli wykonujesz schemat sieci peer to peer. Jak wspomniałem, synchronizacja obiektów innych niż obiekt odtwarzacza może być trudna, ponieważ obiekty te mogą być modyfikowane także przez innych klientów.

Nie mogę ci powiedzieć, którego użyć, ponieważ nie wiem, jak działa twoja gra. Mogę tylko podać fakty. W razie jakichkolwiek pytań prosimy o komentarz.

— tsturzl
źródło

Sugerujesz, że pozwolenie klientom na wykonanie fizyki jest akceptowalnym rozwiązaniem, ale nie wiązałeś się z oszustwem.

— cubuspl42

@ cubuspl42 W trosce o pozostanie w temacie pominąłem szczegóły. Uważam za słuszne, że OP może dalej badać rozwiązanie, aby zbadać potencjalne sposoby złagodzenia oszustwa.

— tsturzl

jednym z takich sposobów jest ograniczenie odchylenia wartości każdego klienta do wartości progowej. Na przykład większość klientów twierdzi, że dany obiekt znajduje się w pozycji 5,8 lub 6,9, ale jeden zgłasza 12,19 jako współrzędną, która może spaść poza próg w porównaniu do tego, jak bardzo odbiega od innych klientów. Jest to tylko częściowe rozwiązanie, ale większość gier oferuje tylko częściowe rozwiązania oszukiwania, dlatego wciąż tak się dzieje. To rozwiązanie nie oznacza, że oszukują, ale oznacza, że ich pozycjonowanie musi zostać poprawione i pojawi się jako opóźnienie.

— tsturzl

Cóż, nieco się nie zgadzam. Niektóre rodzaje kodów można naprawić, niektóre nie. Na przykład, moim zdaniem, jest to zły projekt gry, jeśli można zrobić szybki hak dla konkurencyjnej strzelanki online. Albo jakiś szalony hack, który pozwala latać po mapie z trybem chrzestnym i nieskończoną amunicją (wierzę, że w pewnym momencie zdarzyło się to w Crysis 1). Można je naprawić, wystarczy poprawnie zaprojektować grę. Rzeczy takie jak wallhack są prawie niemożliwe do naprawienia (wymagałoby to ogromnych zasobów z serwera). Aimbot jest praktycznie nie do naprawienia. Twoje rozwiązanie nr 3 zwiększa ryzyko tego najgorszego rodzaju oszustwa.

— cubuspl42

@ cubuspl42 Myślę, że nie rozumiesz, czym jest przykład. Opcja 3 może zapobiec dokładnie temu problemowi, o którym mówisz. Zazwyczaj masz TCP, który dzieli prędkość, a następnie możesz łatwo sprawdzić prędkość między klientami i sformułować konsensus, możesz również zrobić prostą matematykę, aby ustalić, czy współrzędne z UDP są wiarygodne, biorąc pod uwagę podaną prędkość, zakładając, że Twoi klienci mają zsynchronizowany zegar (można ustalić przy połączeniu z zegarem HW).

— tsturzl