Dlaczego niektóre gry sieciowe używają interpolacji, a niektóre szukają ścieżek do zdalnego przemieszczania się?

To trochę otwarte pytanie, ale chciałbym, aby ktoś wniósł dobre uzasadnienie dla obu.

Szybki przykład obu:

Model interpolacji

Pomyśl o modelu Valve, w którym klient często otrzymuje aktualizacje pozycji, a piloty aktualizują swoje pozycje za pomocą interpolacji tych danych.

Znalezienie drogi

W tym modelu pomyśl, że użytkownik wysyła miejsce docelowe i wszyscy do niego odnajdują.

Jakie rodzaje gier są odpowiednie dla każdego i kiedy należy z nich korzystać?

Pracowałem nad kodem sieciowym dla dwóch sieciowych gier AAA w czasie rzeczywistym, jednej dla smartfonów i jednej dla przenośnej konsoli.

Aby bezpośrednio odpowiedzieć na pytanie „dlaczego”, no cóż, niektóre gry używają jednej lub drugiej, ponieważ bardziej im odpowiada. Zależy to nie tylko od rodzaju gry, ale także od rodzaju sieci, o której mówimy (połączone arkadowe szafki mają inne warunki w porównaniu do gier, które mają być odtwarzane przez 3G). Niektóre gry korzystają z obu, a nawet całkowicie różne podejścia do synchronizacji danych!

Chciałbym uogólnić i wziąć pod uwagę nie tylko dane pozycyjne, ale praktycznie każdy rodzaj danych, które można synchronizować między dwoma klientami sieciowymi.

Zamiast dwóch możliwości, chciałbym zaproponować spektrum między twardymi i miękkimi aktualizacjami.

• Bardzo trudne aktualizacje to dyskretne zdarzenia, które natychmiast zmieniają stan na drugim kliencie, bez żadnego rodzaju interpolacji, albo dlatego, że dane mają charakter krytyczny (gracz zmarł), ponieważ nie jest to typ danych, których dotyczy interpolacja (online gra w szachy, wiadomości czatowe itp.) lub dlatego, że pozwala na to twoja sieć (pomyśl połączone arkadowe szafki, w których niezawodne wysyłanie całego stanu gry 60 razy na sekundę jest w granicach możliwości).

  Dzięki tej metodzie opóźnienia sieci będą niezmiennie pokazywane jako opóźnione aktualizacje i będą się pojawiać jako postacie skaczące.

• Trudne z aktualizacjami między / ekstrapolacyjnymi są podobne do bardzo trudnych aktualizacji, ale dla ciągle zmieniających się danych, dla których praktycznie nie jest możliwe niezawodne wysyłanie danych przy każdej zmianie. Pomyśl o wysłaniu pozycji i wektora prędkości; powinieneś być w stanie interpolować dane między dwoma punktami i ekstrapolować je po nich. Powinieneś mieć plan awaryjny, jeśli przychodzące dane nie zgadzają się z twoimi ekstrapolacjami. Powiedziałbym, że większość gier wymagających aktualizacji pozycji używa tej metody.

• Trudne z aktualizacjami synchronizacji są podobne do trudnych z inter / ekstrapolacją, ale rzadko wymagają synchronizacji. Powinieneś użyć tego do danych, które są naprawdę trywialne do inter / ekstrapolacji, takich jak zegar w grze walki (po ustawieniu po obu stronach, tak naprawdę nie jest konieczne późniejsza synchronizacja)

• Opóźnione twarde aktualizacje są podobne do twardych aktualizacji, ale widzisz dane z przeszłości. Podejrzewam, że w wielu grach arkadowych z muzyką w Japonii, w których możesz zagrać piosenkę przeciwko komuś innemu, grasz w oparciu o dane graczy zarejestrowane w przeszłości, być może kilka godzin, a nawet dni wcześniej. Oczywiście tego typu aktualizacje są użyteczne tylko wtedy, gdy tak naprawdę nie wchodzisz w interakcję z innym graczem.

• Aktualizacje miękkie obejmują wysyłanie danych planowania i uruchamianie planu na wszystkich hostach. To właśnie nazywasz „szukaniem ścieżki”. Ilość danych potrzebnych do synchronizacji danych w ten sposób jest znacznie mniejsza; możesz korzystać z tego rodzaju aktualizacji, gdy możesz uniknąć pewnych rozbieżności w sposobie prezentacji danych użytkownikowi, na przykład podczas synchronizacji setek wrogów.

  Oczywiście planowanie samych aktualizacji danych może być tak trudne / miękkie, jak chcesz.

• Bardzo miękkie aktualizacje są używane, gdy wynik działania można wiarygodnie obliczyć na długo przed jego wydaniem. Po prostu wysyłasz wynik, a drugi klient po prostu go odtwarza. Na przykład niektóre gry przeglądarkowe i na smartfony pozwalają toczyć bitwy z innymi ludźmi, ale faktyczna bitwa trwa kilka godzin (pomyśl o grach typu Travian). Jest bardzo możliwe, że te gry obliczają wynik w momencie rozpoczęcia bitwy, a Ty widzisz tylko wyniki tej bitwy.

  Innym przykładem nie podłączonym do sieci jest Civilization 4 z włączonymi animacjami bitewnymi. Kiedy kogoś zaatakujesz, wynik bitwy zostanie natychmiast obliczony, ale zobaczysz jego animację. Zapewniam cię, że bitwa nie jest obliczana, ponieważ jest animowana.

Jak widać, istnieje wiele sposobów synchronizacji danych i jestem pewien, że możesz sobie wyobrazić wiele innych. Wszystkie gry, z wyjątkiem najprostszych, najprawdopodobniej wykorzystają kombinację tych metod, w zależności od rodzaju synchronizowanych danych, rodzaju gry, a nawet stanu sieci (używaj twardych aktualizacji, gdy opóźnienie jest niskie, i idź do bardziej miękkich aktualizacji, gdy opóźnienie wzrasta.

Nie mam wglądu w proces rozwoju Valve, więc to tylko moja opinia, ale:

Interpolacja : Powiedziałbym, że lepiej byłoby w szybkich grach, takich jak na przykład FPS, w których ważne jest utrzymanie stałej pozycji wroga na czas wśród graczy. Interpolacja oznacza, że ​​nawet jeśli niektóre pakiety zostaną upuszczone (AFAIK, większość gier FPS dla wielu graczy używa UDP zamiast TCP / IP, co nie gwarantuje ani integralności, ani kolejności, w której przychodzą pakiety), będziesz płynnie poruszać się po ekranie.

wyszukiwanie ścieżki : jeśli czas nie jest kluczowym elementem gry, a twój algorytm znajduje spójną ścieżkę po ponownym uruchomieniu, wyszukiwanie ścieżki może być interesujące, ponieważ nie wymaga częstego wysyłania, a zatem ciężkich aktualizacji z pozycją każdego z nich jednostka. Powiedziałbym, że wydaje się to pasować na przykład do systemu turowego, w którym można następnie ograniczyć liczbę żądań sieciowych (jedno na początku tury, drugie po zakończeniu tury, aby upewnić się, że wszyscy klienci są „zdrowi” " stan.

Po raz kolejny nigdy nie pracowałem nad grą sieciową ani dużym studiem gier, ale z tego, co czasami czytałem, właśnie tak bym to zrobił :)

Odpowiedź Panda Pajama jest całkiem dobra.

Zasadniczo pytanie sprowadza się do tego, jaka jest minimalna ilość danych, które można wysłać, co spowoduje, że wielu klientów będzie w stanie uświadomić sobie ten sam stan i jak poradzić sobie z opóźnieniem, w którym w tym czasie klienci mogą znajdować się w innym stanie.

Tak więc generowane proceduralnie, gdzie wszystkie interakcje są znane wcześniej, jest najłatwiejsze, ponieważ jeśli wszystkie zmienne są znane, wynik jest znany. Na przykład izoluj kogoś w pokoju, który znasz metody przetwarzania, i podaj mu pewien zestaw danych, możesz dokładnie przewidzieć wyniki. Dlatego możesz dać każdemu klientowi wyniki bez czekania, aż ten zakończy swoje obliczenia.

Nie wspomniał jednak o jednej metodzie. Wymuszone wyniki.

Jeśli system oczekuje działania od jakiegoś elementu, a inne działania są zależne od tego działania, a inne obliczenia uwzględniają to działanie i zostały już wstępnie przetworzone z oczekiwanym wynikiem. Następnie, aby zachować synchronizację, cały system zostaje zatrzymany, a jedna jednostka, która nie znajduje się we właściwym miejscu, jest prawidłowo umieszczana z powrotem na swojej ścieżce.

Przykładem ze świata rzeczywistego są wszystkie inne podmioty, które utrzymują prawidłowy system wynagrodzeń, aby upewnić się, że wysłano mi odpowiednią rekompensatę.