Co sprawia, że Apex gra i buczy: Zanurzenie w świecie serwerów i netcode'u.

Witajcie, tu @ricklesauceur, główny inżynier w Apex Legends. Dziś spróbuję wam nieco przybliżyć zasadę działania infrastruktury sieciowej podtrzymującej Apex Legends.

Dotąd raczej nie mówiliśmy otwarcie o serwerach, kodzie czy infrastrukturze Apex Legends, ale chcemy to zmienić. Krótko mówiąc, dziś zamierzamy:

• Pokazać wam, w jaki sposób pracujemy nad poprawianiem waszych wrażeń z gry sieciowej w Apex Legends;
• Zwrócić uwagę i wyjaśnić najczęstsze problemy sieciowe lub problemy z połączeniem, które mogą występować podczas gry w Apex;
• Przyjrzeć się z bliska najczęściej zadawanym pytaniom dotyczącym tematów takich jak spowolnione serwery, rejestrowanie trafień i nasz system kompensacji opóźnienia;
• Kompleksowo przedstawić kilka uwag dotyczących szybkości odświeżania naszych serwerów wraz z wyjaśnieniem, na co ma, a na co nie ma ona wpływu.

Uwaga: wpis jest długi, ponieważ ma stanowić wnikliwe i rzeczowe omówienie infrastruktury sieciowej Apex Legends – coś, o co niektórzy z was prosili od dłuższego czasu. 

Traktujemy to jako okazję do rozpoczęcia dłuższej rozmowy, dlatego choć poruszymy dziś wiele zagadnień, to znajdzie się jeszcze wiele tematów (ataki DDoS! Awarie serwerów! itd.!) , których omówieniu powinniśmy poświęcić więcej miejsca. Oczywiście jeżeli spodoba wam się ten wpis, koniecznie dajcie nam znać, o czym chcecie się dowiedzieć w następnym, a pójdziemy za ciosem.

Tych, którzy chcą pomóżdżyć na temat netcode'u, serwerów, tickrate'u i tym podobnych… zapraszamy! Zacznijmy więc od omówienia kilku ostatnio wdrożonych przez nas poprawek.

W sezonie 6. dodaliśmy możliwość wyświetlania wydajności. Przedstawia się następująco i służy do wyświetlania podstawowych informacji o osiągach.

„In” i „out” oznaczają wykorzystanie przez grę przepustowości (w kB/s). Mamy też opóźnienie (w milisekundach). Utrata pakietów i choke wyrażane są w procentach pakietów na sekundę.

Liczby te pomogą wam i nam zrozumieć zjawiska, które obserwujemy podczas gry. Innymi słowy, pozwoli nam to przełożyć wasze wrażenia z gry na faktyczne dane techniczne, które udzielą nam niezbędnych do działania informacji.

Przed wdrożeniem tej funkcji gracze twierdzili czasem, że „coś jest nie tak”, natomiast nie byli w stanie powiedzieć nam nic więcej. Teraz wiadomość może być jasna: „tracę 10% pakietów”, „mam 300 ms pingu” itd. To zmienia wszystko, ponieważ to właśnie te liczby stanowią najlepszą podstawę do zdiagnozowania problemu. Jeszcze się do tego odniosę.

Podczas naszych prac nad wyświetlaniem osiągów śledziliśmy także kluczowe wskaźniki osiągów dla naszych serwerów oraz graczy. Oznacza to, że jeśli ktoś zgłosi nam jakiś problem, będziemy mogli przejrzeć rejestr całej rozgrywki i przejrzeć dane wszystkich jej uczestników, w tym informacje na temat konkretnego serwera, który za nią odpowiadał. 

Był to nasz pierwszy, choć wielki krok na drodze do uzyskania spersonalizowanych wskazówek pozwalających nam zgłębić przyczyny problemów. Takie działania zdołały już przynieść nam kilka sukcesów, natomiast na dłuższą metę są one niewystarczające. Przede wszystkim potrzebujemy od was informacji, które następnie przekażemy naszemu specjaliście, który zbada przyczynę problemu, by wreszcie (w zależności od natury problemu) spróbować go naprawić.

W minionych sezonach powołaliśmy do życia cudowny zespół do spraw tych właśnie danych, który w pocie czoła zbierał i analizował dane z każdego tygodnia, by wykryć rażące przypadki utraty pakietów i zdiagnozować problemy z działaniem naszych serwerów. Takie podejście zaczęło już przynosić efekty. Odkryliśmy na przykład awarię jednego z urządzeń w naszym centrum danych, przez którą każda rozgrywka hostowana przez sporą część naszych serwerów była skazana na rażące problemy z wydajnością. Serwery działały bez zarzutu, jednak sam sprzęt odpowiedzialny za ich łączność z graczami powodował znaczną utratę pakietów. Natknęliśmy się na wiele innych, podobnych przypadków.

Największą zaletą systematycznej analizy takich danych jest możliwość zestawienia ich z danymi od graczy i odkrycia zależności pomiędzy nimi. Tak więc po kilku pracowitych tygodniach możemy z całą pewnością określić stan naszej serwerowej floty. Analiza danych to również doskonałe narzędzie, dzięki którym nasi partnerzy mogą rozwiązać problemy niezależne od nas. Zamiast mówić, że coś jest nie tak, możemy powiedzieć: „problemem jest ta konkretna rzecz”, co oszczędza czas wszystkim zaangażowanym. (Tak przy okazji: możecie w dowolnej chwili się z tego wypisać. Po prostu przejdźcie do opcji „Rozgrywka” i „Udostępnianie danych” w menu ustawień.) 

No więc automatyzacja jest bardzo pomocna. Ale to nadal za mało. 

Przy takim podejściu wciąż nie rozwiązujemy problemów dość szybko. To tydzień oczekiwania na samo zgromadzenie i przedstawienie nam rzetelnych danych i kolejny tydzień na przeprowadzenie wnikliwej analizy. Od czasu dostrzeżenia przez was problemów, znalezienie ich rozwiązania może zająć do dwóch tygodni, a jego wdrożenie nawet i dłużej, jeżeli wymaga to aktualizacji serwera.

Możemy być lepsi. Będziemy lepsi. Pomówmy zatem o rozwiązaniach.

Po pierwsze: oprócz naszych tygodniowych raportów wdrożyliśmy system powiadomień w czasie rzeczywistym. Dostarczą nam one tych samych informacji, tylko szybciej. Będziemy mogli od razu rozwiązać problemy ze sprzętem lub rozpocząć prace nad aktualizacją gry. Rozumiemy frustrację spowodowaną czekaniem, naprawdę staramy się skracać czas pomiędzy wykryciem problemu a jego rozwiązaniem.

Po drugie: zamierzamy poszerzyć wyświetlanie osiągów o odrębne ID dla każdego z serwerów („SID”), co pozwoli nam szybciej namierzyć serwer, na którym gracie. Na ten moment korzystamy z informacji o czasie i dacie, które zestawiamy z informacjami o was, aby namierzyć serwer, z którym się łączyliście. Wkrótce nie będziemy musieli tego robić. 

Wprowadzenia powyższych rozwiązań spodziewamy się w trakcie nadchodzącego sezonu Apex Legends: Dziedzictwo. Przyspieszy to, może nawet dwukrotnie, rozwiązywanie problemów z serwerem.

Czas się rozerwać – skategoryzujmy problemy z serwerem, jakie możecie napotkać. Poniższa lista nie jest może wyczerpująca, ale mam nadzieję, że odpowie na większość waszych pytań.

Serwer działa w zwolnionym tempie.

Coś, co wszyscy kochają. Serwery Apex działają z częstotliwością 20 Hz. Oznacza to, że symulacja całego świata przeprowadzana jest co 50 milisekund (1 sekunda – lub 1000 ms – dzielone przez 20).

Mówiąc o wydajności serwera, nie chodzi o FPS-y (klatki na sekundę), ponieważ serwer nie odpowiada za wyświetlanie obrazu. Odpowiada on za obliczanie zdarzeń zachodzących w rozgrywce, jednak zasada działania jest podobna. Pobiera on dane wprowadzane przez graczy, przelicza fizykę świata gry, wysyła podłączonym do niego klientom nowy stan zdarzeń, które zaszły w rozgrywce, i tak w kółko. Jeżeli proces ten trwa dłużej niż 50 milisekund, tempo rozgrywki zostanie spowolnione, aby umożliwić serwerowi przeprowadzenie symulacji. Stąd właśnie bierze się spowolnienie serwera.

Wykres wartości frametime serwera. Kolumna 5. powinna wskazywać 50 ms. Im niższa wartość, tym szybsza reakcja. Możecie dostrzec, że ten serwer działał stabilniej i szybciej niż powinien.

Dla porównania, ten serwer nigdy nie sprostał ustalonej granicy wydajności, a jego frametime wyniósł 200 ms (czyli był 4 razy wolniejszy). To typowe dla spowolnionych serwerów.

Istnieje wiele przyczyn takiego stanu rzeczy. Często są one związane z wadliwym działaniem sprzętu w centrum danych. Mowa tu o zbyt niskim taktowaniu procesora, przegrzewaniu się itd. 

Gdy wykryjemy takie przypadki, zazwyczaj pozbywamy się takich maszyn. Łączymy się wówczas z dostawcą usługi, wyjaśniamy, na czym polega problem i prosimy o odłączenie jej od sieci. 

Planowane przez nas rozwiązanie wykrywania błędów w czasie rzeczywistym, o którym wspomniałem wcześniej, powinno w dużej mierze takie problemy wyeliminować. Bardzo zależy nam na rozwiązaniu tej kwestii, dlatego będziemy się jej bacznie przyglądać.

Moje opóźnienie „faluje”.

Jeśli grasz przez WiFi, nie damy rady ci pomóc! W innym przypadku znaczne skoki opóźnienia mogą być związane z wydajnością naszego serwera.

Wszyscy wiemy, że nawet jeśli gra działa zazwyczaj w 60 kl./s, może się to zmienić, gdy na ekranie dzieje się zbyt wiele. Odczujesz to nawet w przypadku utraty kilku marnych klatek. W przypadku serwerów jest podobnie. Tu automatyczne wykrycie niewiele pomoże w określeniu głównej przyczyny problemu. Mieliśmy już sytuację, w której musieliśmy odtworzyć warunki spowalniające na serwerze deweloperskim, lecz było to dość czasochłonne, a my działaliśmy po omacku – wasze urządzenia prawdopodobnie nie łączą się z serwerem o podobnych parametrach lub ustawieniach.  

Na szczęście nasz zespół operacyjny stworzył specjalne narzędzie, które pozwala nam zdobyć tak zwany plik RPROF. Jest to pewnego rodzaju podgląd poczynań naszego serwera przy każdej renderowanej klatce (symulacja balistyczna, obustronna komunikacja, ruchy graczy itd.). Dzięki plikom RPROF jesteśmy w stanie określić, co jest przyczyną spowolnienia, a nasz specjalista może zacząć pracować nad optymalizacją. Problem wiąże się przeważnie ze zwiększeniem wymagań w kwestii osiągów w miarę dodawania kolejnych treści z sezonu na sezon. 

Być może pamiętacie spowolnienie towarzyszące wyświetlaniu ekranu czempiona na początku gry w sezonach 7. i 8. Wynikało to z pojawiania się wszystkich graczy jeden na drugim w tym samym miejscu. (Ale nikt nie mógł tego zobaczyć przez zasłonę interfejsu!) Symulacja fizyki naprawdę ciężko znosi nakładające się na siebie przedmioty, a nasz silnik stale próbował rozsuwać od siebie kolejne postacie, wywołując tym samym znaczne obciążenia procesora.

Procent gier obsługiwanych przez mało wydajny serwer (niekoniecznie spowolniony) według regionów. Możecie zauważyć, że w niektórych regionach sytuacja z czasem się poprawia, a w innych pogarsza (oś X oznacza czas).

Szczegółowy podgląd zachodniego regionu USA, pozwalający zlokalizować wadliwe maszyny (oś X oznacza czas). Przestój jest wyraźnie widoczny. Część maszyn sobie nie radzi, podczas gdy inne działają stabilnie.

Spodziewamy się, że w przyszłości wykorzystanie plików RPROF pomoże nam w optymalizacji dodawanych do gry funkcji i doprowadzi do ogólnego ograniczenia opóźnień. Zmniejszenie opóźnień dla wszystkich graczy to dla nas bardzo ważne wyzwanie, a tego rodzaju narzędzia bardzo nam pomagają. 

Zauważam widoczną utratę pakietów lub choke.

To jest szczególnie trudne. Wina prawdopodobnie nie leży po waszej stronie, ale często też nie po naszej! 

Tu wszystko zależy od tego, jak działa przepływ informacji od waszych urządzeń do naszego centrum danych i z powrotem. Na początku dane są przesyłane przez sieć waszych dostawców usług. Wasz dostawca usług może mieć awarię, w wyniku której wasze informacje oraz informacje innych klientów zostają zgubione / utracone. Sprawia to, że klient gry nie wie, co dzieje się z graczami blisko was albo serwer gry nie wie, że chcecie strzelić z broni lub ruszyć w określonym kierunku. Następne jest połączenie pomiędzy waszym dostawcą a siecią naszego centrum danych. Na tym etapie problemy mogą się pojawić dosłownie wszędzie.

Jeśli wszystko idzie gładko, mówi się, że zachodzi tzw. „peering”. W większości przypadków problemy z peeringiem występują przy słabym połączeniu dwóch takich sieci. Po drodze może się zdarzyć wiele takich wypadków. W końcu nasz serwer musi zwrócić wszystkie informacje z powrotem do waszych maszyn, niekiedy zupełnie inną drogą. Chyba już rozumiesz, dlaczego nie jest to takie proste. 

Jeżeli chcemy ten problem rozwiązać, najpierw musimy wykryć, na którym etapie wystąpiła awaria. Ciężko ten proces zautomatyzować, ponieważ niezbędne nam będą dane z waszych maszyn i dane z serwera , abyśmy mogli zbadać sprawdzić połączenie po każdej ze stron i określić, gdzie leży problem. 

Na razie prosimy graczy o przekazanie nam danych dotyczących połączenia z siecią – i to samo robimy po stronie naszego centrum danych, aby wykryć punkt spowolnienia transferu. To niezwykle czasochłonne, ponieważ w zależności od naszych wniosków, musimy się porozumieć z różnymi partnerami biznesowymi na całym świecie. Mamy nadzieję, że automatyzacja pomoże nam ten proces usprawnić, ponieważ mamy w zanadrzu kilka rozwiązań, nad którymi wciąż pracujemy. 

Jeśli chodzi o problemy z przepustowością sieci, o których teraz mówimy, dotyczą one z reguły większej grupy osób, a nie konkretnego przypadku. Oznacza to, że rozwiązanie takiego problemu u jednego użytkownika będzie jednocześnie rozwiązaniem dla innych. Aktywnie pracujemy również nad zmniejszeniem przepustowości wymaganej do działania gry, co także pomoże zniwelować ten problem.

Tak wygląda zapis połączenia (wraz z opóźnieniem) modemu zawodowego gracza z jednym z naszych serwerów. Przeprowadzamy wiele prób, aby ocenić faktyczny stan połączenia internetowego. Możecie zauważyć, że w najlepszym wypadku cieszy się on grą z opóźnieniem sięgającym 31 milisekund. Za to w najgorszym wynosi ono nawet 522 ms. W takim przypadku wrażenia z gry są wręcz okropne, ponieważ różnica w czasie reakcji obu maszyn wynosi 500 milisekund. Połączenie po stronie lokalnej sieci jego dostawcy bywa czasem niestabilne, ale średni wynik wskazuje na to, że nie zdarza się to zbyt często (średnia równa 31 ms z najgorszym wynikiem 264 ms to musi być odosobniony przypadek.) Możemy jednak zauważyć wyraźny skok opóźnienia pomiędzy lokalnym dostawcą a dostawcą 1, który to jest jednym z węzłów łączących gracza z naszym serwerem. Możemy być zatem prawie pewni, że to tam występuje utrata pakietów i problemy trasowania pomiędzy nimi. Znajduje się to już poza naszą kontrolą, jednak możemy poinformować administrację tej sieci o zaistniałym problemie. Rozwiązanie tej kwestii jest przeważnie w interesie nas wszystkich.

Ginę, mimo że ukrywam się za drzwiami lub ścianą, a czasem mimowolnie wracam do mojej poprzedniej pozycji.

To bardzo gorący temat. Zjawiska te są związane z kompensacją lagów. 

Już od samego początku ery rozgrywek sieciowych głównym problemem twórców było znalezienie sposobu na przeprowadzenie akcji w czasie rzeczywistym w środowisku, które w czasie rzeczywistym nie działa. Zasadniczo wszystko, co robisz w grach sieciowych, odbywa się z opóźnieniem. Chodzi o czas potrzebny na przekazanie danych do serwera i z powrotem. Dochodzą do tego jeszcze inne czynniki: dane wejściowe, renderowanie, a nawet tickrate serwera. 

Co gorsza, do tego wszystkiego dochodzi jeszcze przeciwnik, który prawie na pewno łączy się z grą z innym opóźnieniem niż wasze. Aby temu zaradzić, nasze serwery muszą bez przerwy obserwować nie tylko to, co w danej chwili dzieje się z tobą i przeciwnikiem, ale także, co działo się u każdego z was w chwili wprowadzenia danych o wykonywaniu akcji. Kompensacja opóźnienia to sztuka łączenia nieznacznie różnych doświadczeń w jedną wspólną rzeczywistość. 

Idealne rozwiązanie nie istnieje. Tak jak i nie ma uniwersalnej prawdy. W końcu serwer to pewnego rodzaju wehikuł czasu. Stale przywraca dawny stan świata, aby zweryfikować, czy strzał kogoś trafił, a następnie, zgodnie z tą weryfikacją, aktualizuje go dla wszystkich uczestników. 

Aby lepiej wam to zilustrować, mój kolega Earl Hammon napisał krótki esej o sprawiedliwości i kompensacji opóźnienia – oraz jak to działa w Apex Legends. Udostępniam go poniżej:

Omówmy różne scenariusze w Apex Legends na przykładzie dwóch graczy o nazwie WYSOKI i NISKI. WYSOKI będzie miał ping rzędu 300 ms, a niski – 50 ms. Różnica w opóźnieniu tej dwójki to 250 ms.

Co się stanie, jeśli wystrzelą do siebie w tym samym momencie? Cóż, strzał NISKIEGO pojawi się na serwerze długo przed strzałem WYSOKIEGO, dlatego NISKI ma wyraźną przewagę.

Co się wydarzy, jeżeli jeden z nich wyjrzy zza rogu tak, by obaj dostrzegli siebie nawzajem? W tej sytuacji NISKI znowu ma przewagę. NISKI nie przebywa w aż tak „odległej przeszłości”, więc szybciej dostrzeże WYSOKIEGO. NISKI znowu zyskuje przewagę dzięki mniejszemu opóźnieniu. Jego przewagę umacnia również fakt, że pociski NISKIEGO trafiają na serwer wcześniej.

Te sytuacje są „niesprawiedliwe” w świetle wyraźnej przewagi NISKIEGO, a jednocześnie są one o tyle „sprawiedliwe”, że gracz o mniejszym opóźnieniu zyskuje tę przewagę w sposób naturalny.

Co więc się stanie, jeżeli to NISKI znajdzie schronienie gdzieś za rogiem? W tej sytuacji WYSOKI wciąż jest w przeszłości, kiedy to NISKI jeszcze nie znalazł schronienia, dlatego WYSOKI może wystrzelić w NISKIEGO, zanim ten znajdzie się za osłoną, a NISKI dowie się o tym dopiero wtedy, gdy dane WYSOKIEGO dotrą na serwer, a stamtąd do niego. NISKI jest przekonany o swoim bezpieczeństwie, a mimo to obrywa. NISKI ma prawo postrzegać to jako nonsens.

Ta sytuacja jest jednak dokładnym odwzorowaniem przykładu, który wcześniej działał na korzyść NISKIEGO! Kiedy NISKI wyskoczy zza zasłony, by zaatakować WYSOKIEGO, ujrzy go i zrani go pierwszy, podczas gdy WYSOKIEMU wydaje się, że NISKI wciąż kryje się za osłoną. Tym razem WYSOKI może zobaczyć brak sensu – w końcu postrzelił go ktoś, kto ukrywa się za zasłoną. Takie sytuacje są nie do wyeliminowania i gracze są na nie skazani, a to wszystko przez prosty fakt, że opóźnienie jest zjawiskiem realnym i u każdego gracza jest trochę inne. 

Niektórzy mogą powiedzieć, że to niesprawiedliwe wobec NISKIEGO, że WYSOKI może go zranić, gdy NISKI schował się za zasłoną. Rozwiązaniem, jakie gotowi są zaproponować, jest to, aby WYSOKI sam rekompensował swoje już i tak duże opóźnienie. Rozwiązanie to wymagałoby od nas wprowadzenia nierównej i asymetrycznej metody zarządzania opóźnieniem. 

Kiepsko jest z powodu opóźnienia oberwać, gdy myślisz, że już jesteś bezpieczny, co właśnie może się przytrafić naszemu NISKIEMU. Równie kiepsko jest jednak z powodu opóźnienia dostać kulkę od kogoś, nim się go jeszcze zobaczy, co może się przytrafić takiemu WYSOKIEMU. Te sytuacje zachodzą jednak symetrycznie.

Chcemy powiedzieć jasno: nie wszystkie gry online działają na tej samej zasadzie, co Apex. Niektóre gry zawsze zapewnią przewagę graczom z niższym opóźnieniem, my jednak decydujemy się tego nie robić. Taką decyzję podjęliśmy w pełni świadomie, badając różne kompromisy i bardzo poważnie rozpatrując kwestię sprawiedliwej rozgrywki sieciowej. 

Mówiąc prościej, w naszym systemie gracze z mniejszym opóźnieniem nie zawsze mają przewagę nad graczami z większym opóźnieniem – i mogą czasem mieć wrażenie nonsensu (dla nas to termin fachowy). 

Jest to zabieg w pełni przez nas zamierzony. Jego zaletą jest fakt, że w Apex Legends można sobie radzić względnie dobrze, nawet jeżeli wasze opóźnienie jest powyżej średniej, co jest dość istotne dla graczy spoza obszarów miejskich lub innych regionów, w których połączenie nie jest stabilne. Sądzimy, że taki „nonsens” powinno się likwidować przy każdej okazji, lecz w sytuacjach odbiegających od ideału pragniemy równych szans dla każdej ze stron.

Dlatego w niemal każdym przypadku, kiedy doświadczacie nonsensu pokroju strzału zza ściany czy zza rogu, jest ono prawdopodobnie wynikiem nieuniknionej różnicy w opóźnieniu pomiędzy graczami i sposobu, w jaki nasz system radzi sobie z tym problemem. Mimo to wciąż pracujemy nad rozwiązaniem tej kwestii. Nie tylko pragniemy, by każdy gracz miał równe szanse, ale zależy nam również na tym, abyście po prostu dobrze się bawili.

Gra nie rejestruje wszystkich moich strzałów.

Pomówmy zatem o rejestrowaniu trafień. Brak zarejestrowanego trafienia oznacza, że wydaje ci się, iż trafiłeś cel, ale nasz serwer temu zaprzeczył. Z waszego punktu widzenia otrzymujecie wszelkie możliwe potwierdzenia w rodzaju rozprysku krwi, dźwięku, ale nie widzicie naliczonych obrażeń. W strzelance takiej jak Apex Legends jest to wyjątkowo uciążliwe. 

Dzieje się tak z wielu powodów. Bywa, że duże opóźnienie lub utrata pakietów powodują nieznaczną desynchronizację waszej lokalnej symulacji świata gry z tą na serwerze. Strzelasz tam, gdzie kogoś widzisz, ale w rzeczywistości strzelasz w miejsce, w którym tego kogoś już nie ma. Niestety, nie dowiecie się o tym, dopóki wasza lokalna wersja świata nie nadgoni tej na serwerze.

Czasami jest to po prostu błąd w symulacji fizyki. Aby zapewnić możliwie najszybszą informację zwrotną, wykorzystujemy zjawisko zwane przewidywaniem. Znamy właściwości balistyczne broni, dlatego kiedy strzelasz, możemy przewidzieć tor lotu pocisku bez włączania w ten proces serwera. Dzięki temu gra staje się bardziej responsywna. 

Przeważnie między klientem a serwerem zachodzi zgoda i pocisk trafia tam, gdzie przewidziano. W przeszłości zdarzały się pewne błędy z obliczeniami balistycznymi i trajektorią pocisków (dla każdej broni strzelającej większymi pociskami, jak na przykład snajperki). Wykrycie takiego błędu bywa niezwykle trudne, dlatego na etapie playtestów wspomagamy się specjalną wizualizacją, która to zadanie ułatwia. Niestety, ten kod diagnostyczny jest zbyt potężny, aby wprowadzić go do gry (z powodu przepustowości sieci), możemy zatem polegać wyłącznie na naszych wewnętrznych testach.

Za każdym razem, gdy trafienie nie zostanie zarejestrowane, rysujemy hitbox i trajektorię pocisku (powinna się ona nieco wykrzywiać, ale nie jest źle!). Jest to nasza pomoc wizualna, która pozwala określić, co się zdarzyło, i znacznie usprawnia interpretację zapisów z serwera.

Radzimy sobie z tym problemem na dwa sposoby:

Pierwszy to stała kontrola rozmaitych błędów powodujących problemy z rejestrowaniem trafień. Stworzyliśmy kilka narzędzi, które ten proces automatyzują, aby uniknąć powstawania nowych problemów tego rodzaju. Nieustannie pracujemy nad tym zagadnieniem.

Drugi to współpraca z wami! Kiedy gracze nadsyłają nam nagrania ukazujące problemy z rejestracją trafień, możemy się przyjrzeć, czy nie ukazują one kolejnych błędów do usunięcia. Często zdarza się tak, że nadesłane filmy są powiązane ze wspomnianym już wcześniej opóźnieniem, nie zaś z wykryciem trafienia, dlatego przed zgłoszeniem nam takiej usterki sprawdźcie najpierw swój wyświetlacz osiągów. Jednak, jak już przed chwilą wspomniałem, udało nam się w ten sposób wykryć i naprawić kilka błędów, dlatego zgłaszanie podobnych problemów może się przysłużyć wszystkim graczom. Z góry dziękujemy!

A co z błędami uniemożliwiającymi zalogowanie się, np. „code:net”?

„Code:net” to ogólny komunikat o błędzie, który pojawia się za każdym razem, kiedy gra straci połączenie z serwerem. Może to być spowodowane dowolną liczbą problemów – zarówno po naszej, jak i po waszej stronie. Odkryliśmy wręcz, że część krytycznych błędów z rodziny code:net (i im pokrewnych, takich jak code:leaf itd.) może być powiązanych z usługami Respawn wspierającymi grę, które będzie trzeba sprawdzić.

Podjęliśmy zdecydowane kroki, aby ograniczyć prawdopodobieństwo występowania błędu code:net. Wielu graczy może taki problem rozwiązać poprzez kontakt z naszym zespołem wsparcia. Jeżeli nie możesz się zalogować i otrzymujesz komunikat code:net lub podobny, rozważ zgłoszenie problemu za pośrednictwem strony pomocy EA.

Ponieważ code:net jest komunikatem ogólnym, może się on odnosić do wielu problemów. W ostatnich tygodniach udało nam się zażegnać część tego rodzaju problemów, ale czeka nas jeszcze sporo pracy. Zgłaszajcie nam te problemy, a postaramy się jak najszybciej je rozwiązać. Uwierzcie nam, te błędy wkurzają nas tak samo jak was.

Teraz dopiero się zacznie. Spróbujmy przedstawić tę kwestię w sposób jak najbardziej przystępny. Wielu graczy pytało nas o tickrate naszych serwerów i dlaczego po prostu go nie zwiększymy, tak jak zrobiono to w przypadku wielu innych strzelanek. 

Nakreśliliśmy już, jak tickrate wpływa na ogólną częstotliwość odświeżania tego, co dzieje się na ekranie, więc to pytanie jest jak najbardziej uzasadnione. Jednak porównanie tickrate'u jednej gry z drugą może być dużo trudniejsze, niż się to wydaje.. Postaramy się to wyjaśnić. 

Tickrate serwera to liczba symulacji przeprowadzanych przez serwer w czasie jednej sekundy. Jest to liczba stała (zajrzyj do sekcji o spowolnieniach serwera). Apex korzysta z modelu działania opartego o replikację danych. Oznacza to mniej więcej tyle, że każda taka synchronizacja zapisuje stan świata gry i wysyła kopię tego zapisu do wszystkich klientów. Zawiera ona wiele informacji, które pozwalają utrzymać możliwie największą dokładność wszystkich broni, map i legend. 

Chcąc dobrze grać w Apex Legends, trzeba uważnie śledzić informacje dostępne na całej mapie. Mowa tu o użytych zdolnościach taktycznych, zdolnościach pasywnych i specjalnych, nadlatujących zrzutach zaopatrzenia czy oddziałach wchodzących w kontakt z dronem Crypto. Nie chcemy, aby gracze coś przegapili. Nasi projektanci są w stanie stworzyć rozmaite gadżety i narzędzia o prawdziwie globalnym charakterze. Wiele gier nie przetwarza stanu świata w całości przy każdym odświeżeniu, co nieraz prowadzi do mylnych porównań pomiędzy jedną grą a drugą w oparciu o pojedynczy aspekt pokroju „20 Hz” kontra „30 Hz”. 

Pytanie brzmi: co dokładnie dzieje się z każdym odświeżeniem? Pragniemy, aby stan świata był możliwie jak najbardziej dokładny – dlatego też nasze serwery każdorazowo zapisują go w całości. Gdybyśmy zrobili inaczej, prawdopodobnie oszczędzilibyśmy część mocy obliczeniowej serwerów, ale tym samym utracilibyśmy dokładność symulacji, a to nie jest warte takiego ryzyka. 

Krótko mówiąc: im wyższy tickrate, tym większe zużycie przepustowości łącza każdego z graczy. Gdybyśmy zamienili serwer o taktowaniu 20 Hz na taki o 60 Hz, oznaczałoby to trzykrotnie większe zużycie przepustowości. Obecnie Apex Legends zużywa około 60 kB/s na początku gry. Serwer o częstotliwości 60 Hz zużywałby 180 kB/s. Może to wyglądać niepozornie, ale w rzeczywistości to dość dużo, a my zawsze szukamy sposobów na zmniejszenie wymaganej przepustowości. 

A co by się stało, gdyby zużycie przepustowości choć trochę wzrosło? Utrzymanie niskiego zużycia przepustowości ma większe znaczenie w grach niż, dajmy na to, w nadawaniu materiałów wideo. W przypadku aplikacji o wysokim zapotrzebowaniu na przepustowość (streaming, pobieranie itd.) nietrudno zamaskować odchylenia i niedoskonałości dzięki buforowaniu minutowemu, obniżeniu jakości itd. Wszelkie trudności z pobieraniem powinny pozostać ukryte, a różnica w prędkości i tak nie należy w tym przypadku do kwestii kluczowych. 

W grach nie ma takiego luksusu. Pominięcie nawet paru 50-milisekundowych interwałów może się dać we znaki. Pominięcie kolejnych może skutkować prawdziwą spiralą komplikacji poprzez pobieranie coraz większych aktualizacji stanu, aby go nadgonić. Pobranie tych aktualizacji w całości jest konieczne, ponieważ wersja świata waszego klienta musi być dokładnie taka sama, jak ta na serwerze.

Powyższy przykład ukazuje złożoność kwestii różnic w odświeżaniu serwerów poszczególnych gier, ponieważ mówimy o całkowicie różnych od siebie zestawach informacji. Napotykamy też inną komplikację, mianowicie ograniczenie otrzymywanych i wysyłanych przez serwer danych wejściowych nie zawsze ma taką samą wartość, nawet w przypadku identycznego tickrate'u. Mówiąc ściślej: serwery wielu gier taktowanych na 60 Hz mogą przesyłać dane wejściowe jedynie w 60 Hz. Wystarczy, gdy grasz w 60 klatkach na sekundę, ale jeżeli cieszysz się grą w 120 kl./s, stracisz połowę wprowadzanych danych. W przypadku Apex Legends tak nie jest. Nie mamy problemów z przetwarzaniem zmiennych wartości danych wejściowych. (Na marginesie: im więcej klatek na sekundę w Apex, tym większe zapotrzebowanie na przepustowość.)

W porządku, omówiliśmy pewne negatywy związane ze zwiększeniem tickrate'u serwera. Jakie są zatem zalety przejścia z, powiedzmy, 20 na 60 Hz? No, Respawn! Czy to nie sprawi, że serwery będą trzy razy szybsze i trzy razy lepsze? Co wam szkodzi!

Z naszych ustaleń wynika, że nie byłoby to szczególnie zauważalne – i już spieszę z wyjaśnieniem. 

Na potrzeby naszej dyskusji przyjmijmy, że wasze średnie opóźnienie oscyluje w granicach 50 ms. Pamiętajcie, że opóźnienie oznacza czas potrzebny danym do przebycia trasy od waszej maszyny do naszego serwera. Zakładając, że nie napotykamy żadnych problemów, takich jak skoki opóźnienia czy opóźnienie sprzętowe (np. wyświetlacz również tworzy opóźnienie rzędu 20-50 ms), serwer otrzyma wasze dane wejściowe po 25 ms (połowa opóźnienia) od wciśnięcia przycisku lub ruchu myszą. 

Ponieważ nasze serwery są taktowane w 20 Hz, aktualizacje zachodzą co 50 ms (1000 ms w każdej sekundzie / 20 aktualizacji na sekundę = 50 ms na jedną). Dlatego w najgorszym wypadku dane wejściowe będą przetwarzane przez serwer po 75 ms (25 ms + 50 ms). 

Aby się dowiedzieć, co tak naprawdę oznacza opóźnienie 75 ms, musimy pochylić się nad waszą liczbą klatek. Tutaj matematyka nieco się komplikuje, ale należy pamiętać, że przy grze w 60 klatkach każda trwa około 16,67 ms (1000 ms w każdej sekundzie / 60 klatek na sekundę = 16,67 ms na klatkę). Jeżeli wasze dane wejściowe są przetwarzane przez serwer po 75 ms według naszych przykładowych założeń, a gra działa w 60 kl./s, oznacza to, że czas pomiędzy wprowadzeniem danych a ich wpływem na grę wynosi około 5 klatek (75 ms na każdą aktualizację / 16,67 ms na klatkę = około 4,5 klatki zaokrąglone do 5, jako że klatka jest niepodzielna). 

Jeżeli przeprowadzimy takie obliczenia dla serwera 60 Hz, otrzymamy 41,67 ms maksymalnego opóźnienia pomiędzy wprowadzeniem danych a reakcją serwera (25 ms opóźnienia + [1000 ms / 60 aktualizacji na sekundę = 16,67 ms na aktualizację] = 41,67 ms). 

41,67 ms brzmi zdecydowanie lepiej niż 75 ms, ale jak to działa w oparciu o liczbę klatek w grze? Raz jeszcze przyjmijmy stałe 60 klatek na sekundę. Każda z nich trwa 16,67 ms, dlatego opóźnienie pomiędzy wprowadzeniem danych, a reakcją serwera wynosi około 3 klatek (41,67 ms na aktualizację / 16,67 ms na klatkę = około 2,5 klatki, w zaokrągleniu do 3, bo przecież klatka jest niepodzielna). 

Po zestawieniu naszych obliczeń okazuje się, że serwery o taktowaniu 20 Hz mierzą się z opóźnieniem rzędu 5 klatek, zaś te o 60 Hz – 3 klatek. Dlatego więc trzykrotne zapotrzebowanie na przepustowość i moc procesora oszczędzają w najlepszym wypadku jedynie dwie klatki opóźnienia. Dostrzegamy tę zaletę, jednak nie jest ona wystarczająca i nie rozwiązuje problemów związanych z opóźnieniem (takich jak otrzymanie trafienia zza osłony), problemów dostawcy usług czy błędów (typu rejestrowania trafień czy spowolnionych serwerów). 

Nasz przykład przedstawił zaletę przejścia z serwera o taktowaniu 20 Hz na ten o 60 Hz. Podobne obliczenia można wykonać dla innych przeskoków, np. z 20 na 30 czy nawet 40 Hz, jednak łatwo wykazać, że zmiany w liczbie klatek będą podobnie niskie. Częstotliwość serwera musiałaby zatem wzrosnąć drastycznie, aby faktycznie dało się ją odczuć – nawet przeskok z 20 na 60 Hz byłby podobny w odczuciu co z 58 na 60 kl./s. Nie możemy powiedzieć, że to żadna różnica, ale uważamy, że jest zbyt mała, aby podnosić taktowanie serwerów kosztem innych, bardziej istotnych usprawnień.

Na koniec chcemy podkreślić, że rozumiemy frustrację, jaką wzbudzają u graczy problemy z połączeniem. Mogą to być opóźnienia, nierejestrowane trafienia, spowolnione serwery – to wszystko potrafi wkurzyć. Odbiera przyjemność z gry i zwyczajnie zniechęca do dalszych zmagań w rankingu, próbowania nowych zagrywek ze znajomymi lub po prostu miłego spędzania czasu. 

Częściowe trudności w dyskusji o problemach występujących w sieci wynikają z potrzeby wyjaśnienia zasad działania naszych systemów lub naszego podejścia do kompensacji opóźnień czy taktowania – może to być przyczyną irytacji dla tych, którzy chcą, aby gra była po prostu lepsza. Jeżeli napotykacie problemy z opóźnieniem lub błędami rujnującymi serwer czy wasze własne konta, lub napotykacie jakiekolwiek inne trudności podczas gry w Apex Legends, raczej nie chcecie słuchać o tym, czego nie zamierzamy zrobić. 

W końcu zależy nam, aby gra stawała się coraz lepsza. Im lepsze są wasze wrażenia z rozgrywki sieciowej, tym więcej graczy przyłącza się do zabawy, dzięki czemu możemy dalej robić to, co kochamy. 

Dlatego w tym wpisie poruszyliśmy kwestię licznych usprawnień, które zamierzamy wdrożyć w najbliższej przyszłości. Mianowicie:

• Korzystanie z systemu powiadomień w czasie rzeczywistym, który umożliwi nam diagnostykę problemów i przyspieszy ich rozwiązywanie;
• Wprowadzenie narzędzi pomagających zidentyfikować serwery, abyśmy mogli pozbyć się tych, które stwarzają problemy;
• Skupienie się na problemie spowolnionych serwerów – usunięcie problematycznych jednostek to jedno, ale ostatecznie pragniemy zażegnać ten problem poprzez zmiany w kodzie;
• Redukcja opóźnień dzięki lepszemu zoptymalizowaniu nowych funkcji;
• Usuniecie błędów w rejestrowaniu trafień i stworzenie narzędzi automatyzujących ten proces, aby zapobiec powstawaniu nowych błędów tego rodzaju;

Zapewniamy, że to nie wszystkie nasze plany. Współpracujemy z partnerami od serwerów i usług internetowych, aby rozbudować naszą infrastrukturę sieciową, co ma się przełożyć na mniejszą ilość zgłaszanych błędów, a co za tym idzie – lepsze wrażenia z gry. Nad tym tematem zamierzamy pochylić się przy następnej okazji, kiedy już dostrzeżemy efekty naszych starań w tym kierunku. 

Mamy nadzieję, że poprzez podtrzymanie dialogu wokół tych nurtujących tematów dojdziemy do lepszego porozumienia w kwestii głównych przyczyn problemów, jakie napotykamy. Dlatego właśnie napisaliśmy ten post. Mamy nadzieję, że przybliżyliśmy wam nasz proces myślowy i objaśniliśmy kwestie techniczne, jakimi rządzi się strzelanka sieciowa. Mamy również nadzieję na więcej takich okazji.

Dziękujemy za lekturę! 

- Samy (Ricklesauceur) i zespół Apex Legends

Graj w Apex Legends za darmo* na PlayStation4, PlayStation5, Xbox One, Xbox Series X|S, Nintendo Switch oraz Origin i Steam na PC.

Obserwuj Apex Legends na Twitterze i Instagramie, subskrybuj nasz kanał YouTube i zaglądaj na nasze fora.

Zaprenumeruj nasz biuletyn już dziś, aby otrzymywać pocztą elektroniczną najnowsze aktualności, materiały zakulisowe i informacje o wyjątkowych promocjach dotyczących gry Apex Legends (a także o produktach, wydarzeniach i ogólnych promocjach EA).

Ponieważ bierzemy pod uwagę opinie społeczności i nieustannie rozwijamy nasze usługi oraz tworzymy nową zawartość, informacje te mogą ulec zmianie. Dołożymy wszelkich starań, by informować naszych graczy na bieżąco. Aby dowiedzieć się więcej, udaj się na stronę z informacjami o usługach sieciowych EA, dostępną pod adresem: https://www.ea.com/pl-pl/service-updates.

* Do gry może być wymagane konto i abonament na odpowiednią platformę (sprzedawane osobno). Niezbędne jest stałe połączenie z Internetem oraz konto EA. Obowiązują ograniczenia wiekowe. Zawiera płatności w grze.