Kompensacja opóźnień w grach 2D w sieci


31

Chcę stworzyć grę 2D, która w zasadzie będzie oparta na fizyce piaskownicą / aktywnością. Jest jednak coś, czego tak naprawdę nie rozumiem. Z badań wynika, że ​​aktualizacje z serwera powinny być wykonywane co około 100 ms. Widzę, jak to działa dla gracza, ponieważ może on jednocześnie symulować fizykę i kompensować opóźnienia poprzez interpolację.

Nie rozumiem, jak to działa w przypadku aktualizacji od innych graczy. Jeśli klienci otrzymają powiadomienia o pozycjach gracza co 100 ms, nie widzę, jak to działa, ponieważ wiele rzeczy może się wydarzyć w ciągu 100 ms. Gracz mógł w tym czasie dwukrotnie zmienić kierunek. Zastanawiałem się, czy ktokolwiek miałby jakiś wgląd w tę kwestię.

Zasadniczo, jak to działa w przypadku fotografowania i tym podobnych rzeczy?

Dzięki

Odpowiedzi:


58

Podsumowanie dla tych, którzy nie lubią długich odpowiedzi ...

Można to zrobić, ale niemożliwe jest wykonanie doskonałej fizyki dla wielu graczy, jeśli występuje jakieś opóźnienie. Wyjaśniono, dlaczego opóźnienie wpływa na fizykę, a następnie podano wskazówki dotyczące zmniejszenia wpływu opóźnienia na symulację fizyki.


Tworzenie fizyki dla wielu graczy może być obarczone niebezpieczeństwem. Nie można stworzyć „doskonałej” fizyki online dla wielu graczy. Są rzeczy, które możesz zrobić, aby to poprawić, ale nie ma sposobu na stworzenie doskonałej fizyki przy założeniu jakiegokolwiek opóźnienia.

Problem polega na tym, że fizyka musi być szybka i wrażliwa, aby była realistyczna, ale jednocześnie musi być obliczona na podstawie połączonych działań WSZYSTKICH czynników - czyli połączonych działań wszystkich graczy. A jeśli występuje opóźnienie, nie można tego zrobić w czasie rzeczywistym.

Jako programista musisz zdecydować, czy możesz kontrolować różne czynniki, i zrozumieć, że doświadczenie gracza ulegnie pogorszeniu, jeśli opóźnienie stanie się zbyt duże. Jeśli możesz z tym żyć (i twoi gracze mogą), to idź. Na końcu tego postu znajduje się kilka notatek na temat tego, jak można zachować płynność działania.

Przykład pokazujący, jak coś może się popsuć

Wyobraź sobie grę, w której dwóch graczy (klientów) jest podłączonych do serwera. Przekazanie wiadomości w Internecie od klienta do serwera zajmuje 100 milisekund (1/10 sekundy). Gdy gracz coś robi, na serwer wysyłana jest wiadomość z informacją o tym, co zrobił. Serwer następnie przesyła wiadomość do innych graczy, aby wszyscy wiedzieli, co zrobił gracz.

Teraz stwórz scenariusz, w którym dwóch graczy ma na ziemi skrzynię, która jest przedmiotem fizyki. Gracz A uderza go z jednej strony, wysyłając go w pewnym kierunku. Jednak w tym samym czasie gracz B uderza go z innej strony, wysyłając go w innym kierunku.

Spójrzmy na różne sposoby radzenia sobie z tym i jakie byłyby wyniki ...

Co jeśli fizyka jest obliczana tylko na serwerze?

Załóżmy, że fizykę obliczamy tylko na serwerze. Gracz A wysyła komunikat „Uderzyłem w ten sposób w skrzynkę” na serwer, 1/10 sekundy później serwer otrzymuje komunikat. Gracz B wysyła komunikat „Uderzyłem skrzynię w inny sposób”. Serwer oblicza zmianę fizyki na podstawie kombinacji dwóch akcji i wysyła wiadomość do obu graczy, mówiąc: „OK, porusza się w ten sposób”. Doskonała fizyka odbywa się na podstawie działań obu graczy łącznie.

Problem polega jednak na tym, że minie 2/10 sekundy, zanim którykolwiek z graczy zauważy skrzynię. Wiadomości od obu graczy docierają do serwera w 1/10 sekundy, a następnie kolejne 1/10 sekundy, aby wyniki obliczeń serwerów zostały wysłane dla obu graczy.

Podsumowując, opóźniona rozgrywka.

Co jeśli fizyka jest obliczana na kliencie?

Załóżmy, że mamy fizykę obliczoną tylko na kliencie. Spójrzmy na to z punktu widzenia gracza A. Gracz A uderza skrzynkę i natychmiast zaczyna iść w ich kierunku. Na serwer wysyłany jest również komunikat o tym, co zrobił Gracz A.

Jednocześnie jednak B wykonał trafienie i zobaczył, że skrzynia idzie w ich kierunku, i wysłał do serwera wiadomość o tym, co zrobili.

2/10 sekundy później wiadomość dociera z serwera do klientów. Powiedziano A, co zrobił B, a B dowiedział się, co zrobił A. Problem polega na tym, że obaj klienci mówią: „Cóż, gracz X mógł zrobić to trafienie w tym miejscu, ale w tym miejscu nie ma już skrzynki, więc ich trafienie nic nie zrobiło”.

Podsumowując, dwie gry nie są zsynchronizowane i gracze nie mają wspólnych doświadczeń. Jaki jest sens gry wieloosobowej, jeśli oboje widzą różne rzeczy?

Co jeśli fizyka jest obliczana zarówno na kliencie, jak i na serwerze?

W tym przypadku fizyka jest obliczana na kliencie, więc gracze widzą natychmiastową reakcję bez opóźnień, ale jest również obliczana na serwerze, więc jest „poprawna” dla wszystkich graczy.

Obaj gracze uderzyli w skrzynkę w odpowiednich kierunkach i każdy widzi ruch skrzyni na podstawie samego trafienia. Ale potem 2/10 sekundy później serwer wraca i mówi: „No cóż, oboje się mylicie. Skrzynia poszła tą drogą”. Nagle obaj gracze widzą, że skrzynia drastycznie zmienia kierunek i zepsuła się w nowej lokalizacji.

Podsumowując, jest to glitchy gra.

Wniosek

Zasadniczo nie ma możliwości stworzenia doskonałej gry fizyki z wieloma graczami, gdy istnieje jakikolwiek rodzaj opóźnienia. Możesz stworzyć całkiem niezłą grę, ale zawsze będziesz mieć ryzyko nadmiernego opóźnienia, które może powodować złe wrażenia dla niektórych graczy. Są jednak rzeczy, które możesz zrobić, aby Twoja gra była dobra.

Rzeczy, które możesz zrobić, aby gra wieloosobowa działała dobrze

Używaj prostych kolizji. Nie zawracaj sobie głowy modelowaniem każdego szczegółu kształtu za pomocą fizyki, gdy wystarczy prosty kształt sześcianu. Kolczasta piłka nie musi być modelowana jako kolczasta piłka dla fizyki. Zamiast tego po prostu zamodeluj go jako kulę.

Twórz małe, nieistotne obiekty tylko dla klienta. Przykładem mogą być kawałki potłuczonego szkła z wybitego okna. Możesz pozwolić każdemu klientowi na samodzielną symulację i nie będzie to miało znaczenia, jeśli będą inni.

Twórz obiekty obiektów fizycznych tylko wtedy, gdy muszą być obiektami fizyki, aby utrzymać niską liczbę aktywnych obiektów fizyki.

Uruchom grę w zwolnionym tempie, wykonując fizykę dla wielu graczy. Pomyśl może „czas na pocisk”. Gry w zwolnionym tempie kompensują opóźnienia i pozwalają wielu graczom na interakcję z fizyką.

Pozwól graczom na ustawienie pewnego rodzaju sytuacji razem, a następnie, w pewnym momencie, fizyka jest symulowana dla obu graczy i oboje obserwują wynik ich połączonych działań. Gracze nie mogą zakłócać sekwencji, dopóki nie zostanie ona ukończona.

Oddziel graczy od fizyki, aby nie mogli sobie przeszkadzać. Byłoby to świetne w przypadku gry w kręgle lub bilard, w której tylko jeden gracz ma kontrolę lub każdy z nich ma swoją „piaskownicę” (jak tor do gry w kręgle).

Jeśli nie możesz ich pokonać, dołącz do nich i spraw, aby lag fizyki stał się częścią twojej gry. Wyobraź sobie historię o byciu w glitchy wszechświecie ze złamanymi prawami fizyki czy coś takiego :)

Dodatek: Jak sobie z tym radzą strzelanki

Gry strzelanki radzą sobie z tym, nie wykonując zbyt skomplikowanej fizyki. Używają efektów ubocznych klienta, aby gracze szybko widzieli rzeczy, ale wtedy serwer wykonuje ostateczne sprawdzenie tego, co się stało.

Wyobraź sobie scenariusz, w którym gracz A strzela do gracza B. Twoja typowa strzelanka zrobi coś takiego ...

  1. A obliczy lokalnie, jeśli trafi B, a jeśli wygląda na to, że jest trafienie, gra efekt „trafienia” jak zaciągnięcie się krwią. Odbywa się to po stronie klienta, dzięki czemu gracz natychmiast widzi reakcję na swoje działanie. Jeśli tego nie zrobisz, gra będzie opóźniona.
  2. A wysyła również wiadomość do serwera z informacją: „Strzeliłem wzdłuż tego wektora”
  3. Gdy serwer otrzyma wiadomość, sprawdza, gdzie IT myśli, że gracze są, i decyduje, czy wektor strzału A uderza w B.
  4. Jeśli serwer zdecyduje o trafieniu B, decyduje o trafieniu B i wysyła wiadomość do OBU klientami, informując o tym, co się stało.
  5. Jeśli serwer zdecyduje, że A NIE uderzył B, B jest w porządku, a A „nie trafia”. Może wyglądać na „A”, jakby uderzyli („Widziałem obrzęk krwi!”), Ale to połączenie z serwerem, które przegapili.

Jak więc A mogła przegapić B, kiedy wyglądało na to, że ich uderzyli? Ponieważ B mógł się przenieść, ale A jeszcze go nie widział, ponieważ serwer nie wysłał jeszcze komunikatu „B przeniósł się tutaj” do klienta.

Valve ma na ten temat dobry komentarz na swojej stronie. Zobacz http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking


2
Dotyczy to serwera z dobrym połączeniem. W wielu przypadkach zawodzi fizyka w grach wieloosobowych i jestem pewien, że w grach Garry's Mod jest mnóstwo złych doświadczeń fizycznych. Jeśli jednak wystąpią opóźnienia, opisane przeze mnie problemy będą istnieć. Nie można obejść faktu, że fizyka musi być obliczona bardzo szybko, aby była płynna. A jeśli masz opóźnienie, nastąpi opóźnienie. Opóźnienie oznacza opóźnienie.
Tim Holt,

1
Możesz wrócić i ponownie przeczytać mój post. Pomijając trochę opinii z przodu, dokładnie opisuję, co dzieje się w symulacji fizyki z wieloma graczami - w tym sesjami gry Garry's Mod. Nie można obejść faktów.
Tim Holt,

2
Ok, zmieniłem mój głos w upvote. Ale malujesz naprawdę negatywny obraz dla gier wieloosobowych z fizyką, kiedy to naprawdę zostało zrobione wcześniej i stosunkowo bezbłędnie.
AttackingHobo

7
@AttackingHobo: „Glitch free” jest względny. Pracowałem nad grą z dobrą prognozą sieci, teraz widzę usterki, których wcześniej nie widziałem. Rzadko wpływają znacząco na mechanikę, ale są obecne. Cały sens przewidywania polega na tym, że mała niedokładność w czasie rzeczywistym jest lepsza niż opóźniona dokładność; to nie zmienia faktu, że zawsze jesteś niedokładny.

1
+1 za „Wyobraź sobie historię o byciu w glitchy wszechświecie ze złamanymi prawami fizyki czy coś”.
Patryk Czachurski

13

Napisałem serię artykułów na ten temat tutaj: http://www.gabrielgambetta.com/fpm1.html

Pierwsze trzy artykuły dotyczą wprowadzenia do tematu, przewidywania po stronie klienta, uzgadniania serwera i interpolacji jednostek (jest to część, która odpowiada na konkretne pytanie). Czwarty artykuł (już wkrótce) dotyczy „strzelania” :)

Odpowiedź Tima Holta jest w zasadzie na to. Moje artykuły zawierają kilka diagramów, które mogą pomóc ci zrozumieć, co się dzieje, ale Tim i ja w zasadzie mówimy to samo.


Dobre rzeczy ggambett!
Tim Holt,

2
Tak wielu graczy nie rozumie, jak to działa, ale tak ważne jest zrozumienie odwiecznego: „WTF DLACZEGO NIE MAM?” pytanie.
Tim Holt,

Albo „dlaczego moja postać jest przywiązana do tej kolumny gigantyczną gumką?” po
zerwanym

Wiki Valve zawiera opis, który również dotyczy tych problemów. Strona znajduje się pod adresem developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
Tim Holt

1
Uwielbiam prezentację na żywo. Co za świetny sposób na wizualizację tego, co się dzieje.
Richard Marskell - Drackir

2

Nie jest nierozsądne, aby w pełni przewidzieć własną postać w celu szybkiego reagowania i mieć opóźnienie innych postaci o 100 ms dla zachowania spójności. Jeśli wygląda to źle, rozważ nieznaczne opóźnienie postaci, aby zachować synchronizację. Tak czy inaczej nadal będziesz potrzebować mechanizmów korekcyjnych, aby wygładzić nieprawidłowe prognozy w przypadku skoków opóźnienia, a ten system poradzi sobie z sytuacjami takimi jak ta, którą opisujesz. Nie ma znaczenia, czy opóźnienie wynosi 100 ms, czy 1 ms - klient zawsze jest w pewnym sensie „spóźniony” i dlatego zawsze musi zachowywać się tak, jakby miał do czynienia ze starymi danymi i zastosować efekty kosmetyczne, takie jak interpolacja, aby wyglądać rozsądnie.


0

Na koniec chodzi o to, aby zrobić z dostępnymi zasobami sieciowymi. Idealnie byłoby żyć w świecie z zerowym opóźnieniem i wszystko można idealnie zsynchronizować. Realistycznie aktualizujesz klientów co 100, 200, 300 ms, a klient musi mieć logikę, aby to, co się stało, wyglądało gładko. „Gładkość” jest bardzo ważna, w końcu gra musi być gładka, nawet jeśli na zapleczu zachodzi chaotyczna synchronizacja między klientem a serwerem.

Dobry post i lepszą odpowiedź można znaleźć:

Jak napisać grę sieciową?


0

Problemem nie jest tak naprawdę opóźnienie. Można to zrekompensować i przewidzieć całkiem dobrze, aby ukryć wszelkie spowodowane przez to problemy. Utrata pakietów również nie stanowi problemu - system sieciowy powinien być napisany tak, aby był solidny i tolerowany w przypadku utraty pakietów. Problemem są jednak opóźnienia i nieprzewidywalne opóźnienia. Pakiety niesynchronizowane, niektóre z nich są odrzucane tylko z powodu wahań latencji, niemożności przewidywania i interpolacji z powodu wahań latencji itp.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.