Zigi testuje AR

Przeglądając ceny co większych zestawów LEGO, Zygfryd rozumiał, że hobby ma prawo być drogie. Karnet na siłownię albo na różnego rodzaju sporty kosztował... 150? 200 zł? Za taką kwotę fascynat klocków mógł kupić zestaw, którego ułożenie zajęłoby mu niecałą godzinę. Jeśli przyjemność układania miałaby trwać dłużej, to wówczas cena zestawu musiałaby iść w tysiące. Jeszcze gorzej od fanów LEGO mieli fani technologii i wszelkiej maści gadżeciarze. Ceny nowych telefonów, konsol, smartwatchów i ostatnio modnych gogli AR-owych i VR-owych potrafiły opróżnić kieszenie nawet sowicie opłacanych deweloperów. Zygfryd cieszył się więc, że ma okazję w pracy pobawić się drogim sprzętem nie musząc go kupować na własność. Zwłaszcza wizja najbliższego projektu sprawiła, że nasz tester chętnie sięgnął po najnowsze gogle jednego z największych producentów na rynku. W najbliższym czasie miał testować grę AR-ową, a później aplikację mobilną wykorzystującą moduł do rozszerzonej rzeczywistości. 

Sam headset wyglądał na solidny, kontrolery pewnie leżały w dłoni, a doświadczenie użytkowania po kilku pierwszych minutach zabawy było bardzo pozytywne. Zigi zagrał w kilka zainstalowanych gier oraz ściągnął i uruchomił kilka wersji demo. Oczywiście wszystko w godzinach pracy. Skoro miał testować grę, zrobienie researchu pod tytułem “jakie gry robi konkurencja?” wydawało się być krokiem w dobrą stronę. Kilka gier ruchowych, kilka shooterów, dwa typowe RPG - tyle wystarczyło, by Zygfryd wyrobił sobie opinię o stanie gier AR i VR-owych oraz o samym headsecie. Największy problem miał jednak z błędnikiem, przez który o mało nie zwrócił śniadania. Poruszanie się w grach VR-owych, kiedy samemu stoi się w miejscu, było w jego przypadku zabójcze. Słynne motion sickness objawiło się w pełnym zakresie. Czy dało się do tego przyzwyczaić? Zygfryd cieszył się, że gra, którą będzie testować, nie będzie wymagała od gracza dynamicznego poruszania się.

Kilka dni później nasz tester po raz pierwszy spotkał się z resztą zespołu, z którym przez najbliższe miesiące miał pracować nad grą. Co na ten moment Zygfryd mógł powiedzieć o testowaniu tego typu rozrywki? Po pierwsze, przed uruchomieniem gry wymagane było zeskanowanie pomieszczenia, w którym miała odbywać się rozgrywka. Służyło to wykryciu ścian, krzeseł i innych przeszkód oraz ustaleniu granic obszaru grywalnego. Zigi oczywiście zastanowił się, co będzie, gdy ktoś będzie chciał sobie pograć na dworze. Urządzenie dawało możliwość automatycznego dopasowania pola gry na podstawie skanowania terenu (które oczywiście można było dopasować) lub ustaleniu własnego pola gry o kształcie koła. Czy wybór jednej lub drugiej opcji mógł mieć wpływ na rozgrywkę? Lista pytań do developerów powiększyła się więc o kolejne pytanie. Bawiąc się wcześniej sprzętem, Zygfryd zauważył, że w jednej z salek, w której lampy były inne niż w reszcie biura, wyświetlany na goglach obraz migotał. Odkrył to zupełnie przez przypadek, co niestety już na starcie skłaniało do zadawania pytania: w jakich warunkach użytkownicy będą grali w grę? Światło naturalne czy sztuczne? LED-y czy inne rodzaje oświetlenia? A może w całkowitej ciemności? To były pytania, które należało zadać już na samym początku testów, od nich bowiem zależał wybór środowiska, w którym odbywać się będą testy gry. 

Na szczęście pierwsze calle z klientem i rozmowy z zespołem rozwiały większość wątpliwości. Klient był właścicielem salonu gier i chciał dołożyć dodatkowa atrakcję. Gra będzie przebiegać w zamkniętym pomieszczeniu, przy sztucznym oświetleniu i polegać będzie na tym, że ściana, na którą skierowany jest wzrok gracza, zacznie pękać, a następnie wyjdzie z niej robot, którego trzeba pokonać. W dużym uproszczeniu tak to wyglądało. Zygfryd, który nigdy nie pracował w game devie, był mocno zdziwiony tym, jak pomysły zmieniają się w czasie. Sam wygląd robota od wersji próbnej do finalnej zmienił się tyle razy, że Zigi ledwo już pamiętał, jak pierwotnie wyglądał prototyp. Wygląd broni, pocisków i same scenariusze gry również ewoluowały w czasie. Jedynie ustalona na początku mechanika gry pozostawała niezmienna: gracz nie będzie mógł strzelać serią, ale trzymając spust będzie ustalał trajektorię lotu pocisku i puszczając go odda w ten sposób strzał. W lewym kontrolerze dostępne będą tarcze do obrony. Sam robot będzie miał pięć różnych trybów ataku, które będzie aktywował w odpowiednim czasie podczas gry. Rozgrywka miała trwać między 5 a 7 minut, ponieważ klient chciał, żeby ludzie szybko kończyli grę i szli do innych aktywności. To też była ważna informacja. 

Pierwsze testy gry miały miejsce dopiero po miesiącu developmentu. Wtedy programiści stwierdzili, że mają gotowe coś, co można już testować. W grze był więc robot (który się nie ruszał), gracz miał do wyboru dwa rodzaje broni (gdzie jedna w ogóle jeszcze nie działała) i mógł strzelać, ale obrażenia zadawane robotowi nie były w żaden sposób odnotowywane. Na szczęście tarcza działała bez zastrzeżeń. Czy nasz tester był już w stanie powiedzieć coś o jakości na tym etapie? Oczywiście! Zygfryd najpierw dokładnie obejrzał modele broni, które przyczepione były do kontrolera. Przybliżając ją do oka (poprzez podniesienie kontrolera w stronę twarzy) był w stanie zajrzeć do środka. Nie widział tam nic ciekawego, natomiast miejsce wydawało się idealne na jakiegoś easter egga. Później pobawił się samą tarczą rozkładając ją i składając kilkukrotnie. Już wtedy zauważył, że FPS-y to będzie coś, z czym pewnie będą musieli walczyć. Gogle pozwalały wyświetlić HUD (ang. Head-Up Display) z informacjami o klatkach na sekundę, zużyciu procesora, baterii i innych mierzalnych rzeczach. Zauważył też, że trzymając włączoną tarczę dalej da się strzelać, czego nie omieszkał zgłosić programistom. Sprawdził także rzeczy niekoniecznie związane z samą grą. Kontrolery były na baterie; co się stanie, jeśli jeden z nich rozładuje się w trakcie gry? Co, jeśli gracz wyjdzie poza obszar grywalny albo w trakcie rozgrywki zdejmie choć na chwilę headset? Były to ważne pytania, na które Zygfryd, nie mający żadnego doświadczenia w tym zakresie, nie znał odpowiedzi. 

Dni mijały, powstawały kolejne, pełniejsze wersje gry, a Zygfryd wiedział już, że testowanie gier to ciężki kawałek chleba. Przede wszystkim nudził się jak mops. Po tylu godzinach grania był w stanie pokonać robota niemal bez trudu, nie dostając przy tym ani jednego trafienia. Samo testowanie mechaniki było proste i nie przysporzyło mu większych problemów. Tutaj trafienie nie odejmowało zdrowia na pasku życia, tam animacja zaczynała się za wcześnie, gdzie indziej dźwięki nachodziły na siebie. Największy problem Zigi miał właśnie z otoczką audiowizualną. W grze dostępnych było ponad 100 dzięków, które miały być słyszalne w odpowiednim miejscu (strzał, przeładowywanie, trafienie itp.). Sam robot też miał całą gamę ruchów i strzałów, które wykonywał w odpowiedniej kolejności. Całe szczęście, że do pomocy Zygfryd miał osoby odpowiedzialne za animacje i dźwięki, które nie znając warsztatu testerskiego, mogły skupić się tylko na sprawdzeniu otoczki audiowizualnej, a całe sprawdzenie mechaniki gry było po stronie naszego testera. Zigi zdawał sobie również sprawę z tego, że po tylu godzinach grania nie jest już obiektywny. Jak szybko powinien strzelać robot? Jak długo powinna przeładowywać się broń? Ile zdrowia powinien mieć gracz? Zygfryd był ostatnią osobą, która byłaby w stanie odpowiedzieć na te pytania. Na szczęście zbliżała się impreza firmowa, a więc idealny moment na to, żeby pokazać grę szerszej publiczności i przy okazji zebrać feedback. 

Alfa testy. Patrząc na zebrane feedbacki Zygfryd stwierdził, że to, co widzi przed oczami, to czyste złoto. Dokładnie tego potrzebował. Ludzie chętnie zgadzali się pograć w grę, a ilość spożytego alkoholu sprawiała, że opinie były szczere. Do bólu szczere. Okazało się, że absolutnie nikt nie używał tarczy. Wszyscy natomiast chcieli strzelać serią i byli bardzo zawiedzeni, gdy okazywało się, że tak się nie da. Na pewno będą mieli co poprawiać przez najbliższe tygodnie. 

Termin dostarczenia gry zbliżał się nieubłaganie. Na szczęście prace szły w dobrym tempie. Programiści zaczęli zastanawiać się nad ekranem startowym oraz nad zakończeniem gry. Normalnie w grze pojawiłby się napis Game Over i przycisk do restartu czy coś w tym stylu; tutaj jednak klient nie chciałby, żeby gracz mógł sobie zagrać w grę raz jeszcze. Miał oddać headset obsłudze i iść dalej. Jak wówczas restartować grę do ekranu początkowego? 

Należało też zablokować możliwość “buszowania” po urządzeniu. Z gry nie powinno dać się wyjść do menu głównego. Były to wyzwania, z których Zygfryd wcześniej nie zdawał sobie sprawy. Pewnego dnia prawie dostał zawału, gdy usłyszał, że być może klient będzie chciał, aby statystyki z gry były wysyłane do ich wewnętrznego systemu. To wymagałoby, aby gra miała połączenie z Internetem. Oczywiście stały dostęp do Internetu generowałby całą gamę kolejnych test case'ów. Kto mógł przewidzieć, że gry mogą wymagać dostępu do sieci? Na pewno nie Zygfryd. Z ulga przyjął więc informację, że póki co żadnych statystyk zbierać nie będzie trzeba. Jednak kolejny stan przedzawałowy miał miejsce, gdy okazało się, że ludzie mogą być leworęczni. Tymczasem w grze tarcze miało się zawsze przy lewym, a broń przy prawym kontrolerze. 

Jednym z plusów testowania na konkretnym modelu gogli było to, że testy można było wykonywać tylko na jednym rodzaju sprzętu. Nie jak w przypadku telefonów, gdzie ekrany były mniejsze i większe, dało się je trzymać w pionie i poziomie, co wymagało testów na wielu rodzajów urządzeń. Ale i to założenie Zigi musiał zweryfikować, gdy okazało się, że jednak z bibliotek graficznych używanych przez programistów crashuje się w 1 na 10 urządzeń. Wymagało to niestety kupna kolejnych takich samych urządzeń tylko po to, by zweryfikować tego rodzaju sytuacje. Grywalność była kolejnym zagadnieniem, które spędzało sen z oczu całemu zespołowi. Zigi w tym zakresie absolutnie nie był obiektywną osobą. Tak naprawdę testów z różnymi grupami ludzi (tych, co nigdy nie mieli do czynienia z AR-em, tych co grali w gry codziennie itp.) powinni wykonać dużo więcej, ale czas i budżet skutecznie ograniczały zapęd zespołu. 

Grę zespół dostarczył w terminie i to bez crunchu*, co było ewenementem w środowisku gamedevu. Klient zgłosił kilka drobnych błędów i sugestii (np. dodanie wibracji kontrolera, gdy gracz zostanie trafiony). Tutaj Zigi pluł sobie w brodę, że całkowicie zapomniał o tej możliwości, którą dawał sprzęt. Ostatecznie jednak nasz tester był zadowolony ze swojej pracy. Dużo się nauczył, nabrał pokory i wiedzy o tym, że testowanie AR/VR diametralnie różni się od tego, z czym do tej pory miał do czynienia testując aplikacje webowe i mobilne. 

*"crunch time" - w branży gier wideo odnosi się do okresu intensywnej pracy bezpośrednio przed ukończeniem projektu, gdy zespoły programistów pracują nadzwyczaj długo, często w godzinach nadliczbowych i w weekendy, aby dokończyć grę, naprawić błędy, dopracować mechaniki itp. przed ustalonym terminem wydania.

Podoba Ci się? Przypominamy, że od niedawna możecie poznać przygody Zigiego w wersji "pełnometrażowej". Książkę "Przygody testera Zigiego" znajdziecie w księgarniach Helion, a recenzję publikacji znajdziecie tutaj.