Zalecam czytać ten artykuł wraz z artykułem Lagometer - narzędzie diagnostyczne.
Od niepamiętnych czasów człowiek starał się znaleźć rozwiązanie na dwa fundamentalne dla jego ewolucji problemy - jak wznieść się w powietrze oraz jak zlikwidować laga w quake3. Niestety oba są wciąż dalekie od rozwiązania. Możemy jednak poznać mechanizmy jakie rządzą protokołem sieciowym quake3. Wersja protokołu sieciowego engine'u gry była inna w każdym PR i ostatnio od niej właśnie bierze się rozszerzenie dema - w 1.16n wersja 43, w 1.17 wersja 45, w 1.27 wersja 48 i w 1.29 wersja 66. To jednak tylko jako ciekawostka, ponieważ w kod protokołu nie można ingerować, ale można nim sterować poniższymi komendami.
1. com_maxfps [85] To jedna z najważniejszych komend całej gry, mająca wpływ na wiele czynników, w tym także na połączenie. Na słabym sprzęcie jej wartość powinna być równa średniemu fps zmierzonemu przy pomocy timedemo. Chodzi o to, żeby nie powodować lagów graficznych, kiedy fps nagle spada o kilkadziesiąt punktów wskutek przejścia z ubogiej w tekstury, kwadratowej komnaty do bogatszej, okrągłej. Lag graficzny nie będzie nigdy tak silnie odczuwany jak nagły skok pingu, ale może być szczególnie dokuczliwy przy grze lokalnej. Na lepszym sprzęcie nie ma on już tak wielkiego znaczenia. Niestety wartość com_maxfps równa średniemu fps ma jedną wadę. Chodzi tutaj o pewną właściwość gry, o której wciąż wie niewiele osób -
Im większy aktualny fps, tym dalej i wyżej można skoczyć. Przyczyna tego leży w kodzie gry. Znalazłem nawet opracowania wyjaśniające przy pomocy kinematyki tą właściwość, są one jednak zbyt złożone, żeby je tu umieścić. Przy normalnej nawigacji nie dostrzeżemy tej właściwości, jednak jest wiele miejsc na mapach, które potwierdzają tę prawidłowość, np. tylko przy wysokim fps można przeskoczyć Mgłę Śmierci na dm9, lawę na dm7, skakać z apteczki na apteczkę na drugim piętrze pomieszczenia z railem na t4, wyskoczyć z teleportu na górę na t2 czy najbardziej chyba znane miejsce - wskoczyć po mh na dm13. Bardziej zaawansowany gracz będzie z tego powodu zainteresowany wysokimi wartościami com_maxfps, nie bacząc na lagi graficzne.
2. snaps [20] Komenda dotyczy wyłącznie klienta i określa liczbę stanów gry otrzymywanych od serwera na sekundę, tzw. snapshot'ów. Zakres jej wartości mieści się od 10 do sv_fps serwera. Sv_fps dotyczy wyłącznie serwera i określa liczbę snapshotów wysyłanych do klientów. Wartości obydwu komend powinny być równe dla prawidłowej synchronizacji. Wartość domyślna obu jest równa 20 i w normalnych warunkach powinniśmy zmienić wartość snaps tylko jeśli na serwerze z jakiegoś powodu jest ustawiony wyższy sv_fps (można to podejrzeć w Server Info). Liczba snaps powinna być wtedy dzielnikiem sv_fps. Warto obniżyć wartość snaps, kiedy dysponujemy bardzo wolnym połączeniem o wysokim pingu przy jednocześnie wysokim com_maxfps i kiedy lagometer pokazuje sporo żółtego koloru zarówno na dolnym i górnym wykresie. Może to poprawić jakość połączenia.
3. rate [3000] Komenda klienta, kontroluje maksymalną ilość bajtów na sekundę (Bps), jaką będziemy otrzymywać od serwera. Domyślnie 3000, czyli około 2.9kB/sek - jest to prawie połowa możliwości modemu (56kB to rate 7000). Wniosek taki, że szybkie połączenie nie jest najważniejszym czynnikiem jego jakości. Quake3 zawiera w sobie mechanizm kompresji (zwłaszcza w 1.29), więc rate równy 3000 i tak pozwala na wymianę danych z większą prędkością (o kilkadziesiąt procent), ponieważ pakiety są skompresowane przed wysłaniem. Analogicznie pracują modemy - często przy ściąganiu np. dużego pliku tekstowego możemy obserwować prędkość przekraczającą możliwości modemu. Dzieje się tak ponieważ plik ten ulega skompresowaniu, a modem po dekompresji myśli że odebrał plik nieskompresowany i na tej podstawie oblicza prędkość tranferu. Odpowiednikiem tej komendy po stronie serwera jest sv_maxrate. Domyślnie jest ona równa zero, co oznacza, że serwer nie narzuca maksymalnej wartości rate. Gdyby taką narzucił, to zmiana rate po stronie klienta powyżej sv_maxrate nie miała by sensu. Sv_maxrate można również w większości przypadków podejrzeć w Server Info. Kiedy zmieniać rate? Jeśli sv_maxrate jest równe 0, to logiczne by było zwiększać rate dla szybkich połączeń typu LAN czy cable, a zmniejszać dla bardzo wolnych. O ile zwiększanie jest jak najbardziej prawidłowe, to zmniejszać nie ma za bardzo czego, ponieważ wspomniane wyżej 2.9kB jest właściwe dla modemu 28.8kbps, więc już dla modemu 56k wartość rate mogłaby być zwiększona. W przypadku wymienionym wyżej przy omawianiu snaps, kiedy lagometer wskazuje dużo żółtych linii na obydwu wykresach, wskazane jest obok zmniejszania snaps zwiększanie rate, co może działać synergicznie.
4. cl_maxpackets [30] Komenda kontroluje ilość pakietów UDP lub IPX wysyłanych przez klienta na serwer. Domyślnie 30, dozwolony zakres od 15 do 100. Komenda ma znaczenie w przypadku łącz o słabym upload'zie. Prędkość download'u nie ma dla niej znaczenia. Słaby upload występuje np. przy połączeniu przez sieć telewizji kablowej, a także trzeba pamiętać, że modem 56k nie może wysyłać szybciej niż z prędkością 33600bps. Nie ma jednak przelicznika wartości tej komendy na prędkość upload'u. W przypadku modemu 56k można eksperymentować z obniżeniem cl_maxpackets np. do 20, a na szybszym łączu ze zwiększeniem jej wartości. Powinna ona wtedy być równa średniemu fps lub stanowić dzielnik com_maxfps, żeby zapewnić synchronizację wysyłania pakietów z renderowanymi klatkami.
5. cl_packetdup [1] Komenda określa ilość zdublowanych pakietów UDP lub IPX wysyłanych przez klienta w celu minimalizacji strat pakietów. Możliwy zakres od 1 do 5, domyślnie 1. W przypadku idealnego połączenia można zmniejszyć wartość do 0, natomiast kiedy lagometer wskazuje na dużą ilość utraconych pakietów (czerwone linie na dolnym wykresie), dobrze jest zwiększyć wartość do 2 lub więcej.
6. cl_timenudge [0] Komenda służy do wywoływania opóźnienia na komputerze klienta (symulacja laga) lub do zwiększania predykcji ruchów modelu klienta przez serwer. Pierwszy efekt osiąga się przez użycie tej komendy z wartością dodatnią. Wpisanie np. 50 spowoduje 50-milisekundowe opóźnienie, co będzie symulowało ping o wysokości 50. Nie ma to jednak znaczenia dla poprawiania jakości połączenia, a wręcz przeciwnie. Wartość ujemna dostraja tzw. client side prediction, czyli pozwala klientowi na przewidywanie ruchów pozostałych graczy. W przypadku stałego pingu na poziomie 100 można eksperymentować z wartością ujemną równą 25-50% pingu, co może zmniejszyć laga. Lagometer w takim przypadku będzie wskazywał głównie kolor żółty. Wartości negatywnej nie stosuje się wraz z komendą cg_smoothclients 1.
7. cg_predictitems [1] Komenda steruje tym, kto decyduje, czy przedmiot został podniesiony. Wartość 0 pozostawia to serwerowi, przy wartości 1 decyduje o tym klient. W tym drugim przypadku przy wysokim pingu mogą zdarzyć się błędy predykcji, ponieważ broń którą wydaje się nam, że podnieśliśmy, w rzeczywistości wskutek opóźnienia nie została podniesiona.
8. cg_smoothclients [0] Wartość 1 aktywuje dodatkową predykcję klienta, dotyczącą pozostałych klientów. Czasami się zdarza kiedy inni gracze tracą pakiety, że na naszym komputerze pojawiają się oni co kilka klatek, co dość poważnie utrudnia celowanie do nich. Wtedy może pomocne okazać się włączenie tej opcji. Skutkiem ubocznym mogą być jednak błędy predykcji. Nie używa się tej opcji wraz z ujemną wartością cl_timenudge.
9. cg_lagometer [0] Lagometer jest bardzo dobrym narzędziem diagnostycznym i jego szczegółowe omówienie znajduje się w następnym artykule.
10. pmove-fixed [0] Komenda ta nie występuje w samym q3, występuje natomiast w osp oraz CPMA. Jej ideą jest zapewnienie równych warunków gry dla wszystkich graczy, niezależnie od fps każdego z nich. Jak wspomniałem na początku im większy fps, tym dalej i wyżej można skoczyć, co może w pewnym stopniu wpływać na większą efektywność jednego gracza, a jest zależne tylko od sprzętu. Komenda ta powoduje, że fizyka ruchu każdego gracza staje się niezależna od jego fps i jest taka sama dla wszystkich graczy.
Jest oczywiste, że nie da się poprawić pingu z 300 na 30. Można jedynie eksperymentować z powyższymi komendami, jeśli ping jest wysoki, ale w miarę stabilny i przyczyny takiego stanu są częściowo chociaż znane.
Poniżej zamieszczam zestawy komend teoretycznie właściwe dla każdego rodzaju połączenia. Można je wpisać w osobne configi i exec'ując sprawdzać, jaki mają wpływ na jakość połączenia.
Minimalne możliwe ustawienia: set cl_maxpackets "15"
set cl_packetdup "0"
set snaps "10"
set rate "2500"
Modem 56k: set cl_maxpackets "30"
set cl_packetdup "1"
set snaps "20"
set rate "5000"
ISDN double i SDI/HIS:
