Game network physics collision

Nie znam idealnego rozwiązania i mam wrażenie, że takie nie istnieje. Nawet gdybyś mógł dokładnie przewidzieć przyszłą pozycję pojazdu, nie byłbyś w stanie przewidzieć sposobu, w jaki użytkownik będzie obsługiwał elementy sterujące. Problem sprowadza się więc do minimalizacji negatywnych skutków opóźnienia klient/serwer. Mając to na uwadze, podchodziłbym do tego z pozycji zasady najmniejszego zdziwienia (parafrazowanej z Wikipedii):

W interfejsie użytkownika design, zasada najmniejszego zdziwienia (lub zaskoczenia) mówi, że gdy dwa elementy interfejsu są sprzeczne lub niejednoznaczne, zachowanie powinno być takie, które najmniej zaskoczy ludzkiego użytkownika w momencie wystąpienia konfliktu.

W twoim przykładzie każdy użytkownik widzi dwa pojazdy. Własne, a także innego gracza. Użytkownik oczekuje, że jego własny pojazd będzie zachowywał się dokładnie tak, jak go kontroluje, więc nie jesteśmy w stanie bawić się tym aspektem symulacji. Jednak użytkownik może Nie wiem dokładnie, jak inny użytkownik kontroluje ich pojazd, i użyłbym tej dwuznaczności, aby ukryć opóźnienie przed użytkownikiem.

Oto podstawowa idea:

1. serwer musi podjąć decyzję o zbliżającej się kolizji. Algorytm wykrywania kolizji nie musi być w 100% doskonały, musi tylko być wystarczająco blisko, aby uniknąć oczywistych niespójności.
2. gdy serwer ustali, że dwa pojazdy zderzą się, wysyła każdy z dwóch użytkownicy komunikat informujący, że kolizja jest nieuchronna.
3. na kliencie A pozycja pojazdu B jest regulowana (realistycznie), aby zagwarantować, że dojdzie do kolizji.
4. na kliencie B pozycja pojazdu A jest regulowana (realistycznie), aby zagwarantować, że dojdzie do kolizji.
5. W następstwie kolizji, pozycja każdego pojazdu może być regulowana, w razie potrzeby, tak aby efekt końcowy był zgodny z resztą gry. Ta część jest dokładnie co proponował w swojej odpowiedzi .

W ten sposób każdy użytkownik ma pełną kontrolę nad własnym pojazdem. Gdy dojdzie do kolizji, nie będzie to nieoczekiwane. Każdy użytkownik zobaczy, że drugi pojazd porusza się w jego kierunku i nadal będzie miał wrażenie symulacji w czasie rzeczywistym. Miłe jest to, że ta metoda dobrze reaguje w warunkach niskich opóźnień. Jeśli obaj klienci mają połączenia z serwerem o niskim opóźnieniu, ilość regulacji będzie niewielka. Koniec wynik będzie oczywiście pogarszał się wraz ze wzrostem opóźnienia, ale jest to nieuniknione. Jeśli ktoś gra w szybką grę akcji przez połączenie z kilkusekundowym opóźnieniem, po prostu nie dostanie pełnego doświadczenia.

Być może najlepszą rzeczą, jaką możesz zrobić, to nie pokazywać rzeczywistej kolizji w czasie rzeczywistym, ale dać złudzenie, że rzeczy dzieją się w czasie rzeczywistym.

Ponieważ klient jest za serwerem (lag), a serwer musi pokazać wynik kolizji, być może po stronie klienta można pokazać błysk lub eksplozję lub inną grafikę, aby odwrócić uwagę użytkownika i kupić wystarczająco dużo czasu po stronie serwera, aby obliczyć wynik kolizji.. Kiedy skończysz z przewidywanie, wysyłasz go z powrotem do strony klienta w celu prezentacji.

Przepraszam, że odpowiadam "czego nie próbować", ale nigdy nie słyszałem o rozwiązaniu, które nie wymaga przewidywania wyniku po stronie klienta. Rozważmy uproszczony przykład:

Klient A jest nieruchomy i obserwuje pojazd klienta B zbliżający się do urwiska. Pojazd klienta B jest w stanie natychmiast zredukować prędkość do 0 i robi to w ostatnim możliwym momencie przed zejściem z urwiska.

Jeśli Klient A próbuje pokazać stan klienta B w czasie rzeczywistym, klient a nie ma innego wyboru, jak przewiduj, że Klient B spadł z klifu. Widać to często w grach MMORPG zaprojektowanych w taki sposób, że postać gracza jest w stanie zatrzymać się natychmiast po uruchomieniu pełnej prędkości. W przeciwnym razie klient A może po prostu pokazać stan klienta B, gdy pojawiają się aktualizacje stanu, ale nie jest to opłacalne, ponieważ klient A musi być w stanie współdziałać z Klientem B w czasie rzeczywistym w Twoim scenariuszu (zakładam).

Czy mógłbyś spróbować uprościć modele kolizji tak, aby ekstrapolacja była możliwa do przewidywania w czasie rzeczywistym? Może spraw, aby twoje "stawy i ciała" miały mniej intensywne modele fizyczne, takie jak kilka kostek lub kulek. Nie jestem zbyt zaznajomiony z tym, jak poprawić skuteczność wykrywania kolizji, ale zakładam, że odbywa się to poprzez wykrywanie kolizji modeli, które są mniej skomplikowane niż modele wizualne.

Odnośnie "czego nie próbować". Zakładasz, że musisz przewidzieć doskonale, ale nigdy nie znajdziesz idealnego rozwiązania w grze ze złożoną fizyką. Przybliżenie jest prawdopodobnie najlepszym, co możesz zrobić (na przykład większość komercyjnych silników fizyki może oddać kształt na scenie fizyki i zwrócić pierwszy punkt zderzenia).

Na przykład, zaimplementowałem kilka krytycznych części fizyki sieci dla najemników 2 pod kierunkiem Glenna (plakat na blogu you wspomniane). Niemożliwe było przepchnięcie całego niezbędnego stanu fizycznego przez przewód nawet dla jednego sztywnego ciała. Havok physics stopniowo generuje punkty styku każdej klatki, więc obecny "kolektor styku" jest niezbędną częścią stanu fizyki, aby utrzymać deterministyczną symulację. To też za dużo danych. Zamiast tego wysłaliśmy pożądaną transformację i prędkości oraz użyliśmy sił i momentów, aby delikatnie popchnąć ciała na miejsce. Błędy są nieuniknione, więc potrzebujesz dobrego błędu schemat korekty.

Kilka myśli.

Peer to peer jest lepszy w radzeniu sobie z opóźnieniami i dużymi prędkościami.

Więc jeśli to jest Twój własny silnik to przełącz się na peer to peer. Następnie ekstrapolujesz pojazd drugiego rówieśnika na podstawie jego przycisku, aby przejść do miejsca, w którym jest teraz. Masz ustawioną kolizję tak, że zderzasz się z innym pojazdem, jakby to był świat. To znaczy, że ty przyjmiesz cios.

Oznacza to, że gdy zderzasz się z drugim, odbijasz się, w sieci peera oni odbij się od ciebie, więc wygląda z grubsza poprawnie. Im mniejsze opóźnienie, tym lepiej działa.

1. Jeśli chcesz przejść do klienta / serwera to będzie to gorsze od p2p

Things to attempt o) Ekstrapoluj klientów do przodu, jak w p2p, aby wykonać wykrywanie kolizji. o) wysyłanie wyników kolizji z powrotem do klientów i ekstrapolacja do przodu

Uwaga, To nigdy nie będzie tak dobre jak p2p. zasadniczo wysoka prędkość & latency = błąd, więc usuwanie latencji jest najlepszą strategią. P2P robi to.

Oprócz przewidywania po stronie klienta, gdzie może być inny użytkownik i wysyłania informacji o kolizji i sposobu postępowania z nią do serwera, to co większość mmo robi, aby poradzić sobie z opóźnieniami jest to, że serwer działa" w przeszłości " tak, jak to było. Zasadniczo buforują Ostatnie wejścia, ale reagują tylko na to, co się stało .1sec w przeszłości. To pozwala "zajrzeć w przyszłość", gdy trzeba (tj. gdy kolizja ma się wydarzyć w Twoim przedziale czasowym, możesz spojrzeć na buforowane wejście, aby zobaczyć co się stanie i zadecyduje, czy kolizja jest prawdziwa).

Oczywiście, to dodaje dodatkową warstwę złożoności do programu, ponieważ trzeba wziąć pod uwagę, jakie dane wysłać do klientów i jak powinni na to zareagować. Na przykład możesz wysłać cały bufor" przyszłości " do klientów i pozwolić im zobaczyć, które możliwe kolizje faktycznie się wydarzą, a które nie.

Ross ma rację. Możesz uprościć model, którego używasz do wykrywania kolizji, abstrakując go do prostszej objętości (tj. szorstki, boxy kontur pojazdu). Następnie możesz wykonywać prognozy na podstawie prostej objętości i szczegółowych obliczeń na dokładnych objętościach, podczas gdy użytkownik jest rozproszony przez "eksplozję". Może nie jest idealny, ale pozwoli Ci przyspieszyć wykrywanie kolizji.