Kod sieciowy
Kod sieciowy to ogólny termin najczęściej używany przez graczy w odniesieniu do sieci w grach online , często odnoszący się do problemów z synchronizacją między klientami a serwerami. Gracze często wnioskują o „złych kodach sieciowych”, gdy doświadczają lagów lub gdy ich dane wejściowe są odrzucane. Typowe przyczyny takich problemów to duże opóźnienia między serwerem a klientem, utrata pakietów , przeciążenie sieci oraz czynniki zewnętrzne niezależne od jakości sieci, takie jak czas renderowania klatek lub niespójna liczba klatek na sekundę . Kody sieciowe mogą być zaprojektowane w celu utrzymania synchronicznego i bezproblemowego działania między użytkownikami pomimo tych wyzwań sieciowych.
Typy kodu sieciowego
W przeciwieństwie do gry lokalnej, w której dane wejściowe wszystkich graczy są wykonywane natychmiast w tej samej symulacji lub instancji gry, w grze online istnieje kilka równoległych symulacji (po jednej dla każdego gracza), w których dane wejściowe od odpowiednich graczy są odbierane natychmiast, podczas gdy wejścia dla tej samej klatki od innych graczy docierają z pewnym opóźnieniem (większym lub mniejszym w zależności od fizycznej odległości między graczami, jakości i szybkości połączeń sieciowych graczy itp.). Podczas meczu online gry muszą odbierać i przetwarzać dane wejściowe graczy w określonym czasie dla każdej klatki (co odpowiada 16,66 ms na klatkę przy 60 FPS ), a jeśli wejście zdalnego gracza dotyczące konkretnej klatki (na przykład klatki numer 10) nadejdzie, gdy inna już jest uruchomiona (na przykład w klatce numer 20, 166,66 ms później), desynchronizacja między symulacjami graczy jest wytworzony. Istnieją dwa główne rozwiązania tego konfliktu i sprawienia, by gra działała płynnie:
Oparte na opóźnieniu
Klasycznym rozwiązaniem tego problemu jest użycie kodu sieciowego opartego na opóźnieniach. Kiedy wejścia zdalnego gracza docierają z opóźnieniem, gra odpowiednio opóźnia wejścia lokalnego gracza, aby zsynchronizować dwa wejścia i uruchomić je jednocześnie. To dodatkowe opóźnienie może być uciążliwe dla graczy (zwłaszcza gdy opóźnienie jest duże), ale ogólnie zmiana nie jest zbyt zauważalna. Jednak opóźnienia te mogą być niespójne z powodu nagłych wahań bieżącego opóźnienia. Jeśli opóźnienie między graczami przekroczy ustalone okno bufora dla zdalnego gracza, gra musi czekać, powodując „zamrożenie” ekranów. Dzieje się tak, ponieważ kod sieciowy oparty na opóźnieniu nie pozwala na kontynuację symulacji, dopóki nie otrzyma danych wejściowych od wszystkich graczy w danej klatce. To zmienne opóźnienie powoduje niespójne i brak reakcji w porównaniu do gry offline (lub do LAN ) i może negatywnie wpłynąć na wydajność gracza w gatunkach wrażliwych na czas i szybkim tempie, takich jak bijatyki .
Wycofanie
Alternatywnym systemem do poprzedniego kodu sieciowego jest wycofywanie kodu sieciowego. Ten system natychmiast uruchamia wejścia lokalnego gracza (aby nie były opóźnione jak w przypadku kodu sieciowego opartego na opóźnieniach), tak jakby to była gra offline, i przewiduje wejścia zdalnego gracza lub graczy zamiast na nie czekać (zakładając wprowadzą te same dane wejściowe, co w poprzednim tiku). Po otrzymaniu tych zdalnych danych wejściowych (załóżmy, że np. 45 ms później) gra może działać na dwa sposoby: jeśli prognoza jest poprawna, gra jest kontynuowana bez zmian, w sposób całkowicie ciągły; jeśli prognoza była błędna, stan gry jest przywracany, a gra jest kontynuowana od poprawionego stanu, co jest postrzegane jako „skok” do innego gracza lub graczy (odpowiednik 45 ms, zgodnie z przykładem). Niektóre gry wykorzystują rozwiązanie hybrydowe, aby ukryć te „skoki” (które mogą stać się problematyczne w miarę wzrostu opóźnienia między graczami, ponieważ jest coraz mniej czasu na reakcję na działania innych graczy) ze stałym opóźnieniem wejścia, a następnie cofnięciem . Wycofanie jest dość skuteczne w ukrywaniu skoków lagów lub innych problemów związanych z niespójnościami w połączeniach użytkowników, ponieważ przewidywania często się sprawdzają, a gracze nawet tego nie zauważają. Niemniej jednak system ten może być kłopotliwy, gdy gra klienta zwalnia (zwykle z powodu przegrzania), ponieważ mogą wystąpić problemy z rozłamem, prowadzące do wymiany biletów między maszynami po nierównych stawkach. To generuje usterki wizualne , które przerywają rozgrywkę tych graczy, którzy otrzymują dane wejściowe w wolniejszym tempie, podczas gdy gracz, którego gra jest spowolniona, będzie miał przewagę nad resztą, otrzymując dane wejściowe od innych w normalnym tempie (jest to znane jako jednostronne wycofanie ). Aby zaradzić temu nierównomiernemu przepływowi danych wejściowych (a co za tym idzie również nierównemu przepływowi ramek), istnieją standardowe rozwiązania, takie jak oczekiwanie na dotarcie późnych wpisów do wszystkich maszyn (podobnie jak w przypadku modelu kodu sieciowego opartego na opóźnieniach) lub bardziej pomysłowe rozwiązania, takie jak jeden obecnie używany w Skullgirls , która polega na systematycznym pomijaniu jednej klatki co siedem, tak aby gra napotkała dany problem i mogła odzyskać pominięte klatki w celu stopniowej synchronizacji instancji gier na różnych komputerach.
Wycofanie kodu sieciowego wymaga, aby silnik gry mógł przywrócić swój stan, co wymaga modyfikacji wielu istniejących silników, dlatego implementacja tego systemu może być problematyczna i kosztowna w grach typu AAA (które zwykle mają solidny silnik i wysoką -traffic network), co skomentował między innymi producent Dragon Ball FighterZ , Tomoko Hiroki.
Chociaż ten system jest często kojarzony z architekturą peer-to-peer i grami walki, istnieją formy sieci wycofywania, które są również powszechnie stosowane w architekturach klient-serwer (na przykład agresywne harmonogramy występujące w systemach zarządzania bazami danych obejmują funkcję wycofywania) i w innych gatunkach gier wideo .
Istnieje popularna, licencjonowana przez MIT biblioteka o nazwie GGPO, zaprojektowana, aby pomóc we wdrażaniu przywracania sieci do gier (głównie gier walki).
Potencjalne przyczyny problemów z kodem sieciowym
Czas oczekiwania
Opóźnienie jest nieuniknione w grach online, a jakość doświadczenia gracza jest z nim ściśle związana (im większe opóźnienie między graczami, tym większe poczucie, że gra nie reaguje na ich dane wejściowe). Że opóźnienie sieci graczy (które w dużej mierze jest poza kontrolą gry) nie jest jedynym czynnikiem, o którym mowa, ale także opóźnienie nieodłącznie związane ze sposobem uruchamiania symulacji gry. Istnieje kilka kompensacji opóźnień używanych do maskowania lub radzenia sobie z opóźnieniami (zwłaszcza przy wysokich wartościach opóźnień).
Tickrate
Pojedyncza aktualizacja symulacji gry nazywana jest tikiem. Szybkość, z jaką symulacja jest uruchamiana na serwerze, jest często nazywana częstotliwością taktowania serwera; liczby klatek na sekundę klienta , bez żadnego systemu renderowania. Częstotliwość taktów jest ograniczona długością czasu potrzebnego do uruchomienia symulacji i często jest celowo dalej ograniczana, aby zmniejszyć niestabilność wprowadzaną przez zmieniającą się częstotliwość taktów oraz zmniejszyć koszty procesora i transmisji danych. Niższa częstotliwość taktów zwiększa opóźnienie w synchronizacji symulacji gry między serwerem a klientami. Tickrate dla gier takich jak strzelanki pierwszoosobowe często mieści się w przedziale 128 tyknięć na sekundę (tak jest w przypadku Valorant ) , 60 tyknięć na sekundę (w grach takich jak Counter-Strike: Global Offensive i Overwatch ), 30 tyknięć na sekundę (jak w Fortnite i Battlefield V w wersji konsolowej) i 20 tyknięć na sekundę (takie są kontrowersyjne przypadki Call of Duty: Modern Warfare , Call of Duty: Warzone i Apex Legends ). Niższa częstotliwość taktów w naturalny sposób zmniejsza również precyzję symulacji, co samo w sobie może powodować problemy, jeśli posunie się za daleko lub jeśli symulacje klienta i serwera działają ze znacznie różnymi szybkościami.
Ze względu na ograniczenia w zakresie dostępnej przepustowości i czasu procesora potrzebnego na komunikację sieciową, niektóre gry nadają priorytet niektórym istotnym komunikacjom, ograniczając częstotliwość i priorytet mniej ważnych informacji. Podobnie jak w przypadku tickrate, skutecznie zwiększa to opóźnienie synchronizacji. Silniki gier mogą ograniczać liczbę wysyłanych aktualizacji (symulacji) do określonego klienta i/lub określonych obiektów w świecie gry, a także zmniejszać precyzję niektórych wartości przesyłanych przez sieć, aby pomóc w wykorzystaniu przepustowości. Ten brak precyzji może w niektórych przypadkach być zauważalny.
Błędy oprogramowania
Różne błędy synchronizacji symulacji między maszynami mogą również wchodzić w zakres „problemów z kodem sieciowym”. Mogą to być błędy, które powodują, że symulacja przebiega inaczej na jednej maszynie niż na innej, lub które powodują, że niektóre rzeczy nie są przekazywane, gdy użytkownik uważa, że powinny. Tradycyjnie strategiczne czasu rzeczywistego (takie jak Age of Empires ) wykorzystywały modele sieci peer-to-peer z blokadą, w których zakłada się, że symulacja będzie działać dokładnie tak samo na wszystkich klientach; jeśli jednak jeden klient wypadnie z kroku z jakiegokolwiek powodu, desynchronizacja może się pogłębić i być nieodwracalna.
Protokół warstwy transportowej i kod komunikacyjny: TCP i UDP
Wybór protokołu warstwy transportowej przez grę (oraz zarządzanie nim i kodowanie) może również wpływać na postrzegane problemy z siecią.
Jeśli gra korzysta z protokołu kontroli transmisji (TCP), opóźnienie między graczami będzie większe. Protokół ten opiera się na połączeniu między dwiema maszynami, w którym mogą one wymieniać dane i je odczytywać. Tego typu połączenia są bardzo niezawodne, stabilne, uporządkowane i łatwe do wdrożenia i są wykorzystywane w praktycznie każdej operacji, którą wykonujemy w Internecie (od przeglądania stron internetowych po wysyłanie e-maili lub czatowanie przez IRC ) . Połączenia te nie są jednak całkiem dostosowane do prędkości sieci wymaganej w grach z szybką akcją, ponieważ ten typ protokołu ( protokoły przesyłania strumieniowego w czasie rzeczywistym ) automatycznie grupuje dane w pakiety (które nie zostaną wysłane, dopóki nie zostanie osiągnięta określona ilość informacji, chyba że ten algorytm - algorytm Nagle'a - zostanie wyłączony), które zostaną wysłane przez połączenie ustanowione między maszynami, a nie bezpośrednio (poświęcając prędkość dla bezpieczeństwo). Ten typ protokołu ma również tendencję do bardzo powolnego reagowania za każdym razem, gdy gubią pakiet lub gdy pakiety docierają w niewłaściwej kolejności lub są zduplikowane, co może być bardzo szkodliwe dla gry online w czasie rzeczywistym (ten protokół nie został zaprojektowany dla tego typu oprogramowania ).
Jeśli zamiast tego gra korzysta z User Datagram Protocol (UDP), połączenie między maszynami będzie bardzo szybkie, ponieważ zamiast ustanawiać połączenie między nimi, dane będą wysyłane i odbierane bezpośrednio. Protokół ten jest znacznie prostszy od poprzedniego, ale brakuje mu niezawodności i stabilności oraz wymaga implementacji własnego kodu do obsługi niezbędnych funkcji komunikacji między maszynami obsługiwanymi przez TCP (takich jak podział danych przez pakiety, automatyczne wykrywanie utraty pakietów itp.); zwiększa to złożoność silnika i samo w sobie może prowadzić do problemów.