Chris Roberts napisał na Spectrum obszerny post, w którym dzieli się informacjami odnośnie wydajności 3.0 - patrząc na zawarte tam informacje, warto abyście się z nim zapoznali, bo na pewno odpowie na wiele pytań, jakie mogą się wam nasunąć.
W duchu Świąt pomyślałem, że warto podzielić się kilkoma spostrzeżeniami na temat wydajności 3.0.
Liczba graczy na serwerze ma znacznie mniejszy wpływ na wydajność klienta, niż mogłoby się wydawać. Podczas końcowych etapów PTU przeprowadziliśmy testy z 50 graczami, 40 graczami i 30 graczami na serwer. Chociaż nastąpiła niewielka poprawa wyników, nie była ona w ogóle proporcjonalna do liczby graczy, co widać z 3 próbek poniżej. Górna to serwer z pełnym 50-osobowym obłożeniem, środkowy to serwer z 40 graczami, a dolna - serwer 30-osobowy (oś X to FPS, oś Y to liczba próbek).
Podczas zmniejszania liczby graczy następuje niewielkie przesunięcie w prawo, ale jest ono względnie minimalne.
Z danych, które widzimy, wynika że znaczenie ma nie tyle liczba graczy, ale raczej to, CO ROBIĄ. W naszych wewnętrznych testach nie doświadczyliśmy problemów z wydajnością, które widzieliśmy na PTU lub Live, gdy tysiące graczy dostało się do gry i zaczęło robić różne szalone rzeczy. Wypełnij Caterpillara ładunkiem, wysadź go nad stacją lub księżycem i rzucisz klientów i serwery na kolana (jako że dodałeś setki, jeśli nie tysiące dodatkowych obiektów do symulacji dla wszystkich). Innym częstym problemem, który może zabić wydajność jest przenikanie się obiektów. Powoduje to przeciążenie fizyki, zwłaszcza w przypadku dużych obiektów. Przykładem tego jest misja asteroidowa (została wyłączona zeszłej nocy), która spawnowała się na szczycie lub w pobliżu Olisar i była wsysana do lokalnej sieci powodując różnego rodzaju problemy i blokady. Ponadto musimy zacząć lepiej radzić sobie z obsługą większych statków, które mogą wprowadzić tysiące dodatkowych elementów do aktualizacji, w przeciwieństwie do mniejszych statków, które mają o wiele mniej przedmiotów i geometrii. Jeśli masz gromadę ludzi latających Starfarerami i Caterpillarami obciążasz klientów i serwery o wiele bardziej niż gromadą Auror i Hornetów.
Mamy rozwiązania dla wszystkich tych kwestii, włącznie ze zmianą modelu aktualizacji fizyki z asynchronicznego na pakietowy (batch), co pozwoli znacznie lepiej skalować fizykę (obecnie jesteśmy ograniczeni jedynie do czterech wątków dla fizyki niezależnie od ilości rdzeni po stronie klienta lub serwera). Oprócz tego poziom szczegółowości aktualizacji dla obiektów na kliencie z serwera (nie aktualizuj lub aktualizuj rzadziej gdy klient jest daleko, usuń obiekt z sieci, jeśli jest daleko od widoku klienta), strumieniowanie kontenera obiektów (całe obszary gry są przesyłane do klienta tylko jeśli są potrzebne, co pozwala na znaczną redukcję ich ilości po stronie klienta). Te wszystkie optymalizacje są na różnych etapach postępu, ale nie jest to coś, co możemy ukończyć w ciągu tygodnia lub dwóch.
Podczas Citizen Conu ogłosiliśmy, że przechodzimy do kwartalnego harmonogramu wydań, który mniej skupia się na funkcjach, a bardziej na regularności aktualizacji. Wersja 3.0 to pierwszy krok w tej strategii. Moglibyśmy spędzić kilka tygodni na optymalizacji i wyłapywaniu błędów przed przejściem na "Live" po powrocie z przerwy świątecznej, ale ponieważ większość firmy ma wolne do drugiego tygodnia stycznia (ponieważ pracowaliśmy tydzień dłużej w 2017 niż w 2016) nie dostalibyście wersji live 3.0 przed początkiem lutego. Biorąc pod uwagę, że by dotrzymać terminu w pierwszym kwartale musimy mieć wersję dla Evocati w połowie lutego, znaleźlibyśmy się w tej samej sytuacji, co w tym roku, kiedy spóźniliśmy się koncentrując się na funkcjach a nie terminach. Wrzucenie 3.0 na serwery publiczne pozwala nam na merge kodu z główną jego wersją, kontynuację prac związanych z wydajnością i optymalizacją (co będzie istotną częścią przyszłych wersji) i dostarczenie jej po solidnym przetestowaniu w pierwszym kwartale 2018. Tak więc mimo iż problemy z wydajnością i błędy mogą być frustrujące, 3.0 to krok na drodze w podróży Star Citizena, podczas której gra będzie stawać się coraz lepsza i bardziej dopracowana.
Jeśli osiągasz wydajność poniżej 10-15 FPS, to zdecydowanie coś jest nie tak, szczególnie jeśli masz czterordzeniowy procesor, kartę graficzną z 4 GB VRAM i co najmniej 16 GB RAM. Widziałem zgłoszenia ludzi, którzy mieli 5 FPS, podczas gdy inni użytkownicy korzystający ze sprzętu o takiej samej mocy uzyskują 25-30 FPS. Prawdopodobnie jest to wynikiem przechodzenia przez grę na stronicowanie z dysk z powodu niskiej ilości pamięci RAM, choć czasami ma to miejsce na komputerach, które mają 16 GB lub nawet więcej, co wymaga dokładnego zbadania z naszej strony. Czy to inne aplikacje znajdujące się w pamięci? Zła alokacja stronicowania (potrzebne 10 GB, a alokowano 16)? Czy wycieki pamięci w grze? Pecety mają wiele zalet, ale jednym z kosztów ich wszechstronności jest ogromna różnorodność konfiguracji, co utrudnia odnalezienie konkretnych przyczyn pewnych problemów z wydajnością. Inwestujemy w dodatkową telemetrię zarówno na serwerach, jak i po stronie klienta. Dzięki temu możemy automatycznie wykryć, kiedy rzeczy nie działają jak powinny w oparciu o podstawowe specyfikacje maszyny i (miejmy nadzieję) określić pewne problemy, które powodują anormalnie niską wydajność. Oczywiście zajmie to trochę czasu, więc prosimy o cierpliwość.
Na koniec chcę podziękować wszystkim, którzy wspierają Star Citizena. Wasz entuzjazm i zaangażowanie naprawdę dodają energii zespołowi i mnie. Budujemy coś naprawdę wyjątkowego, co jest możliwe tylko dzięki wam.
Wesołych Świąt wszystkim!
Rekomendowane komentarze
Brak komentarzy do wyświetlenia