12 April, 2018

5 min czytania

Opóźnienie wprowadzania komend w For Honor

Uwaga: w tym wpisie przyjmiemy za podstawową wartość częstotliwości wyświetlania na poziomie 30 FPS, ponieważ jest ona wspólna dla wszystkich platform.

CYKLICZNY ODCZYT AKCJI

Kunszt Wojenny stanowił rdzeń For Honor od samego początku, dlatego zawsze było dla nas bardzo ważne, aby atakowanie w różnych postawach oraz blokowanie były tak jasne i czytelne, jak to tylko możliwe. Oto przykład jednego z pierwszych problemów, jakie napotkał nasz zespół podczas tworzenia gry:

Video 1

Na pierwszym filmie widać, że zmiana postawy w celu udanego bloku podczas obrony następuje w ostatnim możliwym momencie.

Video 2

Porównaliśmy to z nieudanym blokiem, kiedy to broniący się używa przycisku zaledwie 33 ms później. Jak widać na drugim filmie, uznaliśmy, że różnica ta nie będzie wystarczająco jasna i okaże się źródłem frustracji dla graczy w defensywie. Zdecydowaliśmy, że w celu poprawy czytelności różnica między udanym a nieudanym blokiem powinna zawsze wynosić co najmniej 100 ms.

fh_inputlag_figure1

W tym właśnie celu stworzyliśmy system cyklicznego odczytu akcji, który synchronizował wszystkie działania graczy co 100 ms według globalnego zegaran. Jak widać na powyższym obrazie, mimo iż gracz 1 nacisnął przycisk ataku o 33 ms wcześniej niż gracz 2, ciosy te zostaną wyprowadzone w tym samym momencie, w tym wypadku prowadząc do trafień.

PROBLEMY Z CYKLICZNYM ODCZYTEM AKCJI

Największym kłopotem wynikającym ze stosowania cyklicznego odczytu akcji było dodatkowe, losowe opóźnienie 0, 33 lub 66 ms – w zależności od tego, kiedy gracz nacisnął przycisk. W czasie tworzenia gry nasz zespół uważał jeszcze, że była to akceptowalna różnica, jednak wkrótce zmieniliśmy zdanie.

Podczas pracy nad balansem i komfortem otrzymywaliśmy opinie od uczestników naszych wewnętrznych i zewnętrznych testów, w wyniku czego opóźnienie w zmianie postawy przestało nas satysfakcjonować. Wreszcie postanowiliśmy usunąć ten system w zakresie zmiany gardy, co rozwiązało pewne problemy, jednak jednocześnie osłabiło początkowy cel istnienia tej funkcji.

Po premierze gry zdecydowaliśmy się na usunięcie cyklicznego odczytu całkowicie, ponieważ chcieliśmy pozbyć się niespójności w reakcji na działanie gracza. Ponieważ jednak system ten działał też jako swego rodzaju ochrona przed opóźnieniem sieci, usunięcie go oznaczałoby też wiele innych skutków.

Spójrzmy na kilka różnych sytuacji, które lepiej wyjaśnią, jak działała ta funkcja, kiedy była aktywna. W celu uproszczenia załóżmy, że między atakującym a obrońcą istnieje 100 ms opóźnienia sieci.

fh_inputlag_figure2

Na powyższym obrazie atakujący wykonuje działanie w 400 ms, co oznacza, że cios jest rozpoczynany natychmiast. Obrońca otrzymuje i widzi go jednak dopiero po 100 ms.

fh_inputlag_figure3

Jeśli spojrzymy powyżej, widzimy, że atakujący naciska przycisk w 366 ms na globalnym zegarze, dlatego atak rozpoczyna się w 400 ms. To 33 ms opóźnienie działa jako swego rodzaju korekta opóźnienia sieciowego, ponieważ obrońca nie widzi teraz tylko 66 ms ciosu.

fh_inputlag_figure4

Wreszcie w ostatniej sytuacji atakujący używa działania w 333 ms, a więc atak nadal rozpoczyna się dopiero w 400 ms. Powoduje to 66 ms opóźnienia i sprawia, że obrońca efektywnie widzi go tylko 33 ms po jego rozpoczęciu.

Biorąc jednak pod uwagę, iż ta korekta opóźnienia sieci była losowa i nierzetelna, nie stanowiła idealnego rozwiązania zapewniającego graczom możliwości reakcji na ataki. Sądziliśmy, iż skoro średnio jeden na trzy ataki nie wymagały owej korekty, usunięcie cyklicznego odczytu akcji nie będzie miało negatywnego wpływu na możliwość reakcji graczy. Komentarze ze strony społeczności potwierdziły jednak, że musimy znaleźć rozwiązanie problemu utraty informacji spowodowanego usunięciem tego systemu.

AKTUALNE ROZWIĄZANIE

fh_inputlag_figure5

Aktualnie wprowadzone rozwiązanie to częściowe opóźnienie wprowadzania komend: wszystkie uznawane za „ofensywne” (lista poniżej) będą opóźnione o ustalony czas, 33 ms. Wartość ta nie będzie miała dużego wpływu na reaktywność, jako że dotyczy wyłącznie działań ofensywnych, które z natury trwają długo. Jak widać powyżej, jeśli atakujący wyprowadzi atak z bezczynności, zamiast rozpocząć się on od razu, zostanie opóźniony o 33 ms. W ten sposób część niewidoczna dla obrońcy zostanie skrócona o opóźnienie wprowadzania (od 100 do 66 ms), co zapewni mu więcej czasu na odpowiedź.

Czym jest komenda ofensywna?

  • Słaby atak jest zawsze uznawany za ofensywny.
  • Silny atak jest uznawany za ofensywny poza sytuacjami, kiedy stanowi paradę – w takiej sytuacji nie zostaje opóźniony.
  • Przełamanie gardy jest uznawane za ofensywne poza sytuacjami, kiedy jest używane w celu zablokowania innego przełamania gardy – w takiej sytuacji nie zostaje opóźnione.
  • Zmiana postawy w tej samej klatce co słaby lub silny atak spowoduje opóźnienie jej i rozpoczęcie wraz z atakiem.
  • Unik oraz anulowanie/zmyłka są uznawane za ofensywne, jeśli zostaną rozpoczęte w chwili trwania opóźnienia innej komendy ofensywnej, w celu uniknięcia ich zamiany i problemów z tzw. flickerem.
  • Puszczenie przełamania gardy, słabego lub silnego ataku są również uznawane za ofensywne, ponieważ mogą rozpoczynać ataki niektórych postaci (np. szarżę burz orochiego).

KOLEJNE KROKI

Po przeprowadzeniu testów wewnętrznych oraz wraz z naszą społecznością uważamy, że aktualne rozwiązanie stanowi dobry pierwszy krok do poprawy ogólnej reaktywności naszego systemu walki, choć będzie ono miało niewielki wpływ na czas wykonywania pewnych działań, na przykład serii, połączeń czy anulowań, ponieważ odpowiednie komendy będą musiały być wprowadzane o 33 ms wcześniej. Badamy też aktualnie inne sposoby na poprawę zarządzania opóźnieniem sieci w grze, jednak chcieliśmy udostępnić tę pierwszą zmianę jak najszybciej, aby zapewnić wszystkim graczom jak najlepsze wrażenia z rozgrywki, kiedy to tylko możliwe. Jak zwykle będziemy się, oczywiście, dzielić wszelkimi aktualizacjami w tej kwestii.

Sprawdź pozostałe media społecznościowe

twitch iconyoutube iconinstagram icon