Z cyklu "Łopatologia stosowana", a zaczęło się od tego wątku:
gamecorner.pl/gamecorner/1,86013,8116666,OnLive___jak_sie_sprawdza_w_tescie_opoznien_.html
Napisałem tam @Sławkowi, że napiszę prostą aplikację pokazującą opóźnienie w
strumieniowaniu w praktyce i porównującą do lokalnie odpalonej gry. Jak
obiecałem tak zrobiłem. Odpisałem w tym samym wątku, ale ten juz uciekł
daleko, a szkoda mi lunchu, który poświęciłem na napisanie tej gierki
Poniżej przeklejam swój komentarz:
Gra-test do ściągnięcia tutaj:
rapidshare.com/files/405950385/DelayTest.jar
Napisałem to w Javie, więc jest cross-platformowa. Pamiętacie "Galaga", to coś
w tym rodzaju, ale to nie jest istotne.
O co w tym chodzi? Otóż po odpaleniu ( wymagana java 1.6 ) pojawi się okno, w
którym będą dwa viewporty. Ten po lewej to gra odpalona lokalnie, ten po
prawiej symuluje strumieniowanie. W polu tekstowym można wpisać wartość od 0
do 30. Jest to liczba klatek opóźnienia. Gra przyjmuje, że jedna klatka to
33ms czyli lock framerate'u jest na 30FPS ( aczkolwiek to java i Swing, więc
może chrupać, niewiele na to mogę poradzić, ale chodzi o koncept, generalnie
jak lewy chrupnie to i prawy chrupnie, na jedno wyjdzie ). Jako test polecam
wpisać np. 10fps i próbować grać używając tylko prawego viewportu.
Jeszcze krótka instrukcja jak to odpalić. Powinno się dać po prostu klikając
na plik JAR, a jeśli ktoś chce "z palucha", to w command line: java -jar
DelayTest.jar
Sterowanie - lewo, prawo, spacja by strzelić oraz jeśli wpiszemy jakąś liczbę
w polu tekstowym, to może zajść konieczność naciśnięcia TAB, by przywrócić
focus głównemu oknu gry.
Jeszcze co do opóźnienia o którym @Sławek pisał. Jeśli gra lokalnie ma
opóźnienie między reakcją na przycisk i akcją na ekranie, to oznacza, że ta
sama gra będzie miała takie opóźnienie również w OnLive i wypadałoby to dodać.
W każdym razie jest to w dużej mierze kwestia designu, jeśli chodzi o drogę
kontroler->akcja i nie dotyczy tylko gier konsolowych.
Co mi dał ten test? Z jednej strony sam przekonałem się, że przy pewnym
rodzaju gier może nie być tak źle. Poślizg przy 5-6 klatkach ( 33ms * 6 =
196ms ) jest zauważalny, ale chyba przy strategiach i innych niezbyt
dynamicznych grach nie będzie raczej odgrywał znacznej roli. Sieć ma jednak to
do siebie, że lubi sobie "beknąć" i raz będzie 200ms, a raz skoczy do 1000ms i
tu zaczną się zapewne nerwy, bo to co strumień już wysłał musi zostać
przetrawione nim serwer skoryguje "frameskip" i zacznie dosyłać "aktualny"
obraz. Takie "czkawki" będą miały z pewnością wpływ na rozgrywkę i nim nastąpi
korekta to opóźnienie może po prostu rosnąć.
A to co @Sławkowi chciałem pokazać, to fakt, że sam świat gry lokalnie się nie
opóźnia, natomiast w strumieniowaniu opóźnione jest wszystko. Stąd np.
programista ( no i animatorzy ) ma wpływ na to, kiedy lokalnie postać
rozpocznie ruch oraz kiedy się zatrzyma ( to że strzał np. zabiera 200ms to
nie znaczy, że obrót, czy ruch również tyle zjedzą, tu wiele naprawdę zależy
od kodu gry i animacji ), w przypadku OnLive nie będzie już nad tym kontroli,
świat gry będzie szedł kilka klatek przed tym co widzi gracz, w
przeciwieństwie do gry lokalniej.
Have fun
