Istnieją różne metody na zmniejszenie lub ukrycie opóźnień, choć wiele z nich ma swoje wady i mogą nie mieć zastosowania we wszystkich przypadkach. Jeśli synchronizacja nie jest możliwa przez samą grę, klienci mogą być w stanie wybrać grę na serwerach w geograficznej bliskości, aby zmniejszyć opóźnienia, lub serwery mogą po prostu zdecydować się na odrzucenie klientów z wysokimi opóźnieniami, aby uniknąć konieczności radzenia sobie z wynikającymi z tego problemami. Nie są to jednak rozwiązania optymalne. Zamiast tego, gry będą często projektowane z myślą o kompensacji opóźnień.
Wiele problemów można rozwiązać po prostu pozwalając klientom śledzić ich własny stan i wysyłać stany bezwzględne do serwera lub bezpośrednio do innych klientów. Na przykład, klient może dokładnie określić, na jakiej pozycji znajduje się postać gracza lub kogo postrzelił. To rozwiązanie działa i praktycznie eliminuje większość problemów związanych z lagiem. Niestety, opiera się również na założeniu, że klient jest uczciwy. Nic nie stoi na przeszkodzie, aby gracz modyfikował dane, które wysyła, bezpośrednio u klienta lub pośrednio przez proxy, aby mieć pewność, że zawsze trafi w swój cel. W grach online, ryzyko oszustwa może uczynić to rozwiązanie niewykonalnym, a klienci będą ograniczeni do wysyłania stanów względnych (tj. wektor, po którym się poruszał lub w który strzelał).
Client-sideEdit
Jako że klienci zazwyczaj nie mogą definiować głównego stanu gry, ale raczej otrzymują go z serwera, głównym zadaniem kompensacji po stronie klienta jest renderowanie wirtualnego świata tak dokładnie, jak to możliwe. Ponieważ aktualizacje przychodzą z opóźnieniem, a nawet mogą zostać porzucone, czasami konieczne jest, aby klient przewidział przebieg gry. Ponieważ stan aktualizowany jest w dyskretnych krokach, klient musi być w stanie oszacować ruch na podstawie dostępnych próbek. Dwie podstawowe metody mogą być użyte, aby to osiągnąć; ekstrapolacja i interpolacja.
Extrapolacja jest próbą oszacowania przyszłego stanu gry. Gdy tylko pakiet z serwera zostanie odebrany, pozycja obiektu jest aktualizowana do nowej pozycji. W oczekiwaniu na kolejną aktualizację, następna pozycja jest ekstrapolowana w oparciu o aktualną pozycję i ruch w czasie aktualizacji. Zasadniczo klient zakłada, że poruszający się obiekt będzie kontynuował jazdę w tym samym kierunku. Kiedy nowy pakiet zostanie odebrany, pozycja może zostać nieznacznie skorygowana.
Interpolacja działa poprzez buforowanie stanu gry i renderowanie go graczowi z niewielkim, stałym opóźnieniem. Kiedy nadejdzie pakiet z serwera, zamiast natychmiastowej aktualizacji pozycji obiektu, klient zacznie interpolować pozycję, zaczynając od ostatniej znanej pozycji. W przedziale interpolacji, obiekt będzie renderowany płynnie poruszając się pomiędzy dwoma pozycjami. Idealnie, interwał ten powinien dokładnie odpowiadać opóźnieniu między pakietami, ale z powodu strat i zmiennego opóźnienia, rzadko ma to miejsce.
Obydwie metody mają zalety i wady.
- Interpolacja zapewnia, że obiekty będą poruszać się tylko między ważnymi pozycjami i daje dobre wyniki przy stałym opóźnieniu i braku strat. Jeśli upuszczone lub nieuporządkowane pakiety przepełnią bufor interpolacji, klient będzie musiał albo zamrozić obiekt na pozycji do czasu nadejścia nowego pakietu, albo zamiast tego skorzystać z ekstrapolacji. Wadą interpolacji jest to, że powoduje ona renderowanie świata z dodatkowym opóźnieniem, zwiększając potrzebę zaimplementowania jakiejś formy kompensacji opóźnienia.
- Problem z ekstrapolacją pozycji jest dość oczywisty: niemożliwe jest dokładne przewidzenie przyszłości. Będzie ona poprawnie renderować ruch tylko wtedy, gdy ruch jest stały, ale nie zawsze tak będzie. Gracze mogą losowo zmieniać zarówno prędkość, jak i kierunek. Może to spowodować niewielką ilość „wypaczenia”, gdy nowe aktualizacje dotrą i szacowane pozycje zostaną skorygowane, a także spowodować problemy z wykrywaniem trafień, ponieważ gracze mogą być renderowani w pozycjach, w których nie są w rzeczywistości.
Często, aby umożliwić płynną rozgrywkę, klient może dokonywać miękkich zmian w stanie gry. Podczas gdy serwer może ostatecznie śledzić amunicję, zdrowie, pozycję itp., klient może być upoważniony do przewidywania nowego stanu gry po stronie serwera w oparciu o działania gracza, takie jak umożliwienie graczowi rozpoczęcia ruchu, zanim serwer odpowie na polecenie. Zmiany te będą generalnie akceptowane w normalnych warunkach i sprawią, że opóźnienie będzie w większości przypadków przejrzyste. Problemy pojawią się tylko w przypadku dużych opóźnień lub strat, gdy przewidywania klienta zostaną w bardzo zauważalny sposób cofnięte przez serwer. Czasami, w przypadku niewielkich różnic, serwer może nawet pozwolić na „niepoprawne” zmiany w stanie gry w oparciu o aktualizacje od klienta.
Server-sideEdit
W przeciwieństwie do klientów, serwer zna dokładny aktualny stan gry, i jako taki przewidywanie jest niepotrzebne. Głównym celem kompensacji opóźnień po stronie serwera jest natomiast zapewnienie dokładnych efektów działań klienta. Jest to ważne, ponieważ w momencie, gdy polecenie gracza dotrze do celu, czas się zatrzyma, a świat nie będzie już w stanie, który gracz widział, gdy wydawał polecenie. Bardzo wyraźnym przykładem tego jest wykrywanie trafień dla broni wystrzelonych w strzelankach pierwszoosobowych, gdzie marginesy są małe i mogą potencjalnie powodować znaczące problemy, jeśli nie są odpowiednio obsługiwane.
Rewind timeEdit
Innym sposobem na rozwiązanie tego problemu jest przechowywanie przeszłych stanów gry przez pewien czas, a następnie przewijanie lokalizacji gracza podczas przetwarzania polecenia. Serwer wykorzystuje opóźnienie gracza (w tym wszelkie nieodłączne opóźnienia spowodowane interpolacją; patrz wyżej), aby przewinąć czas o odpowiednią wartość w celu określenia, co widział klient strzelający w momencie oddania strzału. To zazwyczaj skutkuje tym, że serwer widzi klienta strzelającego w starej pozycji celu, a więc trafiającego. W najgorszym przypadku gracz będzie tak daleko w tyle, że serwerowi zabraknie danych historycznych i będzie musiał zacząć prowadzić swoje cele.
To jest rozwiązanie WYSIWYG, które pozwala graczom celować bezpośrednio w to, co widzą. Ale ceną jest pogorszenie efektów opóźnienia, gdy gracz jest pod ostrzałem: nie tylko jego własne opóźnienie odgrywa rolę, ale także opóźnienie atakującego. W wielu sytuacjach jest to niezauważalne, ale gracze, którzy właśnie się ukryli, zauważą, że otrzymują wiadomości o obrażeniach/śmierci z serwera dłużej, niż ich własne opóźnienie może to uzasadnić. Może to częściej prowadzić do (fałszywego) wrażenia, że zostali zastrzeleni przez osłonę i (nie do końca niepoprawnego) wrażenia „laggy hitboxes”.
Jednym z problemów projektowych, które powstają w związku z przewijaniem jest to, czy przestać przewijać opóźnione komendy martwego gracza, jak tylko umrze na serwerze, czy kontynuować je, dopóki nie „dogonią” czasu śmierci. Natychmiastowe odcięcie kompensacji uniemożliwia ofiarom pośmiertne atakowanie swoich zabójców, co spełnia oczekiwania, ale zachowuje naturalną przewagę poruszających się graczy, którzy okrążają róg, zdobywają cel i zabijają go w czasie krótszym niż podróż w obie strony do klienta stacjonarnej ofiary.
Przywracanie może być krytykowane za to, że pozwala wysokim opóźnieniom jednego gracza negatywnie wpływać na doświadczenia graczy o niskich opóźnieniach. Serwery z kompensacją lagów czasami zmniejszają długość przechowywanej historii gracza lub wymuszają limity pingów, aby zredukować ten problem.
Zaufaj klientomEdit
Możliwe jest, aby klienci mówili serwerowi co robią, a serwer ufał danym, które otrzymuje. Unika się tej metody, jeśli jest to w ogóle możliwe, ze względu na podatność na oszustwa: prostą sprawą jest przekierowanie danych sieciowych przez drugi komputer, który wstawia sfabrykowane wiadomości o trafieniach lub modyfikuje istniejące, co jest techniką niemożliwą do wykrycia przez narzędzia anty-cheatowe.
Jednakże sama skala niektórych gier uniemożliwia zastosowanie kosztownych obliczeniowo rozwiązań, takich jak przewijanie. Na przykład w Battlefield 3 stosowany jest system „hybrydowego wykrywania trafień”, w którym klienci informują serwer o tym, że trafili, a serwer przed zaakceptowaniem tego twierdzenia przeprowadza jedynie niejasny test wiarygodności.
Zaufanie wynikom klienta ma te same zalety i wady co przewijanie.
Spraw by klienci ekstrapolowaliEdit
Mniej popularnym rozwiązaniem jest nie robienie nic na serwerze i kazanie każdemu klientowi ekstrapolować (patrz wyżej) by pokryć swoje opóźnienie. Daje to nieprawidłowe wyniki, chyba że zdalni gracze utrzymują stałą prędkość, dając przewagę tym, którzy robią uniki tam i z powrotem lub po prostu zaczynają/zatrzymują się w ruchu.
Dłuższa ekstrapolacja powoduje również, że zdalni gracze stają się widoczni (choć nie podatni na ataki), gdy nie powinni być: na przykład, jeśli zdalny gracz biegnie do rogu, a następnie zatrzymuje się nagle na krawędzi, inni klienci będą renderować go biegnącego dalej, na otwartą przestrzeń, przez czas ich własnego opóźnienia. Po drugiej stronie tego problemu, klienci muszą dać zdalnym graczom, którzy właśnie zaczęli się poruszać, dodatkowy zryw prędkości, aby popchnąć ich do teoretycznie dokładnego przewidywanego miejsca.
DesignEdit
Możliwe jest zredukowanie postrzegania opóźnienia poprzez projekt gry. Techniki obejmują odtwarzanie animacji po stronie klienta tak, jakby akcja miała miejsce natychmiast, zmniejszanie/usuwanie wbudowanych timerów na maszynie hosta oraz używanie przejść kamery w celu ukrycia wypaczania.