W niniejszym blogu developerów przyjrzymy się kolejnym exploitom, sposobom, w jakie je naprawiliśmy oraz omówimy znaczenie wprowadzonych poprawek dla przyszłych exploitów.

OŚ CZASOWA

11-12 MAJA

• Na początku maja trzy exploity zaczęły lawinowo zdobywać popularność w społeczności Rainbow Six Siege – exploit z tarczą Clash, exploit min kierunkowych oraz exploity związane z rozkładanymi tarczami.
• Zespół monitorował sytuację przez weekend i szybko stało się jasne, że musimy potraktować tę sprawę priorytetowo.

13 MAJA

• Zespół rozpoczął badania nad exploitami. Naszym pierwszym krokiem było dokładne i wielokrotne odtworzenie exploitów na naszych wewnętrznych serwerach w celu zrozumienia problemu i rozpoczęcia identyfikacji jego fundamentalnej przyczyny.
• Wstępne śledztwo wykazało, że będziemy potrzebować więcej czasu na zrozumienie problemu i że wydanie szybkiej poprawki nie będzie możliwe.
• Exploit dalej rozchodził się po naszej społeczności, dlatego też zaczęliśmy rozmowy o planach, których celem byłoby zmniejszenie efektu exploitów w krótkiej perspektywie czasowej.

15 MAJA

• Zarząd projektu Rainbow Six Siege zebrał się w celu przedyskutowania exploitów. Musieliśmy ustalić – ilościowo, za pomocą danych – dokładne rozmiary wpływu exploitów na rozgrywkę.

16 MAJA

• Rankiem 16 maja, po zebraniu niezbędnych danych, podjęliśmy decyzję o wyłączeniu Clash, min kierunkowych oraz rozkładanych tarcz.
• Zespoły wstrzymały prace nad swoimi codziennymi zadaniami, a my zaczęliśmy badać rozmaite opcje stworzenia i opublikowania rozwiązania, dzięki któremu możliwe byłoby wyłączenie Clash, min kierunkowych i rozkładanych tarcz.
• Każde z potencjalnych rozwiązań było testowane natychmiast po ukończeniu. Zidentyfikowaliśmy pięć potencjalnych sposobów na rozwiązanie tego problemu i po szeregu nieudanych wdrożeń wreszcie znaleźliśmy skuteczną metodę.

17 MAJA

• Pierwsza i druga runda przyspieszonych testów zakończyły się sukcesem, dlatego też w charakterze awaryjnym aktywowaliśmy przełączniki, dzięki którym zablokowaliśmy Clash, miny kierunkowe i rozkładane tarcze.

24 MAJA/strong>

• Zrozumieliśmy, że wprowadzenie pełnej poprawki będzie wymagać więcej czasu, bo problem związany był z procesami systemów podstawowych, głównie z kolejnością pakietów wysyłanych do serwera. Rozumieliśmy jednak, że usunięcie Clash i kluczowych gadżetów znacząco wpływa na jakość rozgrywki, dlatego też zespoły rozpoczęły równoległe prace nad stworzeniem szeregu systemów zabezpieczających, które można było bezpiecznie wprowadzić do gry.

CZERWIEC

• W ciągu kilku kolejnych tygodni znów zaczęły się pojawiać doniesienia o exploitach.
• Dzięki wprowadzonym systemom zabezpieczającym mogliśmy szybko zareagować na nowe zgłoszenia i wyłączyć Clash oraz IQ.
• W tym momencie zespół zakończył już prace nad kompletną, działającą poprawką fundamentalnych przyczyn exploitów. Testy wewnętrzne wyglądały obiecująco, ale w pierwszej kolejności musieliśmy opublikować poprawkę na serwerze testowym w celu przeprowadzenia testów na większą skalę. Dopiero to dałoby nam pewność, że poprawka nadaje się do opublikowania na serwerach gry.

CZERWIEC-LIPIEC

• Pod koniec czerwca system globalnego wykonywania czynności pojawia się najpierw na platformie PC, a potem, w lipcu, na konsolach.
• W tym okresie monitorujemy jego działanie i sprawdzamy, czy nie pojawiają się żadne oznaki regresji.

PRZEŁĄCZNIKI I ZABEZPIECZENIA

Gdy część zespołu pracowała bezpośrednio nad poprawką, inna grupa już na samym początku procesu rozpoczęła prace nad kilkoma drobnymi zabezpieczeniami z zamiarem stworzenia bardziej długofalowego rozwiązania, które można by wdrażać krótkoterminowo. Te przełączniki i zabezpieczenia, które adresowały wyłącznie czynności związane z exploitami, nigdy nie miały pełnić roli kompletnej poprawki. Stanowiły one efekt decyzji podjętej przed zespół, po rozważeniu kosztu usunięcia Clash i dwóch gadżetów, jak również wpływu tej decyzji na ogólne zdrowie gry. Poprawki trafiły na serwery gry niedługo później, wraz z prośbą do społeczności o zgłaszanie kolejnych przypadków exploitów.

Decyzja o usuwaniu operatorów i zmianie wyposażenia jest dla nas niezwykle poważna. Musimy szanować czas i wysiłek, jaki gracze włożyli w odblokowanie zawartości wewnątrz gry, jak również zdawać sobie sprawę z tego, jak gigantyczny wpływ na metę i ekosystem Rainbow Six Siege wywiera usunięcie fundamentalnych mechanik gry. Jednak w tej sytuacji uznaliśmy, że czekanie na pełną poprawkę nie jest dopuszczalnym rozwiązaniem. Musieliśmy zniwelować exploity i ustabilizować rozgrywkę tak szybko i tak bezpiecznie dla graczy, jak tylko to było możliwe.

Rozwiązania związane z zabezpieczeniami musiały spełnić szereg wymagań. Musiały być: chirurgicznie precyzyjne, aby nie wywołać żadnego rodzaju regresji ani niezamierzonych uszkodzeń w innych systemach; modyfikowalne w celu wprowadzania natychmiastowych zmian; musiały też być łatwe w testach, aby umożliwić ich szybkie opublikowanie. W wyniku tego podejścia przygotowaliśmy przełączniki operatorów i gadżetów, co stanowiło nasze pierwsze rozwiązanie na jak najszybsze zniwelowanie problemu exploitów. Podczas testów naszych zabezpieczeń i przełączników rozumieliśmy również, że stanowiły one rozwiązanie awaryjne i całkowicie tymczasowe.

CZYM JEST GLOBALNY SYSTEM WYKONYWANIA CZYNNOŚCI?

Każdy operator, gadżet, granat, tarcza, kamera, ściana i roślina w Rainbow Six stanowi obiekt. Każdy obiekt w Rainbow Six Siege wysyła wiadomość (pakiet) do serwera, gdy tylko wykonywana jest w jego kontekście jakaś akcja. Na przykład: gdy używasz swojego gadżetu, twój operator wysyła wiadomości „Wyposażam swój gadżet” oraz „Używam swojego gadżetu” w takiej właśnie kolejności. Jednocześnie twój gadżet wysyła informacje do serwera, takie jak „gadżet aktywowany” czy „gadżet podłożony”. Serwer wysyła te informacje pozostałym graczom w twojej rozgrywce.

Do czasu wydania poprawki, kolejność dostarczania tych wiadomości do serwera była gwarantowana jedynie dla danego obiektu. To oznaczało możliwość wystąpienia błędu, gdy wiadomości ginęły albo serwer otrzymywał je w niewłaściwej kolejności. Exploity wykorzystywały ten błąd w naszym protokole sieciowym, spamując jednocześnie rozmaite czynności, co zwiększało prawdopodobieństwo nieprawidłowego odebrania wiadomości przed serwer. Wynikiem była nieprawidłowa replikacja czynności przez serwer, co oznaczało, że klient gry (czyli to, co widzą gracze) niepoprawnie wyświetlał prawidłową i zamierzoną czynność.

Nasze rozwiązanie tego problemu, czyli globalny system wykonywania czynności, modyfikuje w taki sposób nasz engine sieciowy, aby wszystkie wiadomości uporządkowane były w globalnym ujęciu. Wysyłane są one również wielokrotnie w celu zapewnienia stabilnego przepływu danych. To oznacza, że każda gra otrzyma tę samą sekwencję wiadomości i replikacja we wszystkich klientach będzie zsynchronizowana.

Gdy zrozumieliśmy, że wszystkie działające exploity były powiązane z tym fundamentalnym procesem, musieliśmy skrupulatnie zaprojektować system globalnego wykonywania czynności. Musieliśmy zadbać o to, aby w wyniku tej zmiany nie wystąpiły żadne niepożądane efekty. System globalnego wykonywania czynności oznacza zwiększone użycie łącza, ale uznaliśmy, że korzyści płynące z jego wdrożenia warte są niewielkiego zwiększenia wymaganej przepustowości i podjęliśmy decyzję o włączeniu go do systemów naszej gry.

CO TO OZNACZA DLA PRZYSZŁOŚCI GRY

Dzięki nowemu systemowi globalnego wykonywania czynności, wszystkie akcje są konsekwentnie replikowane dla wszystkich graczy w meczu, ponieważ teraz ich kolejność wykonywania ustalona jest na poziomie globalnym, a nie na poziomie klienta. Zmierzyliśmy i oceniliśmy dodatkowy koszt związany z przepustowością łącza i wprawdzie liczba przesyłanych danych nieznacznie się zwiększy, ale nie wpłynie to na wrażenia płynące z rozgrywki. Dzięki wprowadzeniu tego systemu nie powinny się już pojawiać żadne dalsze problemy z nieuporządkowanymi wiadomościami ani żadne exploity z tym związane.

Exploity i ich wpływ na społeczność podkreśliły również wysoką wartość przełączników operatorów i gadżetów, jak również potrzebę zwiększenia naszej kontroli nad operatorami i konfiguracją wyposażenia na działających serwerach gry. Gdy zdaliśmy sobie z tego sprawę, przeznaczyliśmy dodatkowe zasoby na zaadresowanie tej potrzeby, aby w przypadku przyszłych exploitów móc szybciej reagować na zaistniałą sytuację.