Zapisz oczekiwany wynik, zanim zaczniesz grać
Test gry nie powinien polegać wyłącznie na kilkunastu minutach swobodnej zabawy. Taka obserwacja jest cenna, lecz trudno ją powtórzyć i ustalić, czy poprawka usunęła konkretny problem. Dla najważniejszych reguł przygotuj scenariusz wejścia, działanie i oczekiwany rezultat. Osobno zapisuj uwagi o odczuciu trudności, a osobno sprzeczność z ustalonymi zasadami.
Jeżeli gracz ma trzy próby, sprawdź pierwszą pomyłkę, drugą i ostatnią. Jeśli wynik zależy od kolejności działań, przygotuj dwa przebiegi z tymi samymi elementami ułożonymi inaczej. W ten sposób powstaje zestaw, który można uruchomić po zmianie mechaniki. Nie trzeba od razu automatyzować każdego ruchu; najpierw potrzebna jest jednoznaczność oczekiwań.
Oddziel symulację od zegara i rysowania
Logika możliwa do uruchomienia z kontrolowanym czasem jest łatwiejsza do sprawdzenia niż reguły zależne od przypadkowego tempa ekranu. Można wtedy porównać stan po określonym kroku bez czekania na ręcznie mierzony upływ sekund. W animacji przeglądarkowej requestAnimationFrame dostarcza znacznik czasu; częstotliwość wywołań nie powinna być mylona ze stałym zegarem gry.
Sprawdź, jak program zachowuje się przy dużej przerwie między aktualizacjami. Czy obiekt przechodzi przez przeszkodę, licznik staje się ujemny, a gracz otrzymuje kilka nagród naraz? Wybór sposobu obsługi takiej sytuacji zależy od mechaniki. Ważne, aby nietypowy krok czasu miał określone zachowanie, zamiast przypadkowo wykonywać reguły przeznaczone do idealnie płynnej sceny.
Testuj granice obszaru i kolizji
Wykrywanie kolizji często korzysta z uproszczonych kształtów otaczających obiekty. Dokumentacja MDN pokazuje między innymi prostokąty, koła i sprawdzanie ich przecięcia. Dobór kształtu jest kompromisem między kosztem a dokładnością. Ważne, aby widoczna grafika i obszar kolizji nie dawały graczowi sprzecznych informacji o bezpiecznym ruchu.
Przygotuj przypadki tuż przed zetknięciem, dokładnie na granicy i po niewielkim przekroczeniu. Sprawdź narożniki, obiekty o różnej wielkości oraz ruch poza ekran. Jeśli wynik ma zależeć od środka przedmiotu, nie oceniaj go przypadkowo według całego obrazka. Wiele pozornie losowych błędów okazuje się nieuzgodnioną regułą tego, co uznaje się za trafienie.
Losowość powinna dać się odtworzyć do analizy
Przy testach można używać kontrolowanego generatora i zapisywać jego punkt startowy. Pozwala to wrócić do podobnego układu poziomu po zgłoszeniu problemu. Nie zakładaj jednak, że sam zapis ziarna gwarantuje identyczną symulację na każdej platformie i po zmianie kodu. Potrzebne są również wersja zasad, uporządkowanie działań i ustalone obliczenia.
MyTworzymy.pl tworzy rozwiązania dla klientów z całej Polski, w tym gry przeglądarkowe. W zleceniu warto uwzględnić możliwość przekazania konkretnego przebiegu błędu, a nie tylko zrzutu końcowego wyniku. Krótki opis działań i wersja gry pomagają wykonawcy odtworzyć problem oraz odróżnić pomyłkę użytkownika od nieprawidłowości w mechanice.
Przerwij rozgrywkę celowo
Ukrycie karty, zmiana aplikacji i powrót po dłuższej chwili to zwykłe sytuacje, nie wyjątkowe awarie. Page Visibility API informuje o zmianach widoczności, ale sposób reakcji należy zaprojektować w samej grze. Sprawdź stan ruchu, dźwięku i czasu po powrocie, a także to, czy użytkownik otrzymuje możliwość świadomego wznowienia.
Dodaj próby zamknięcia w trakcie zapisu, utraty sieci przed wynikiem i ponownego uruchomienia po aktualizacji. Gra może zachowywać się inaczej w każdej sytuacji, lecz nie powinna udawać potwierdzenia, którego nie otrzymała. Przy projekcie bez zapisu postępu jasno określ utratę bieżącej próby, aby test nie wymagał funkcji, której świadomie nie przewidziano.
Oddziel wydajność od poprawności
Powolna animacja i błędna punktacja to różne kategorie problemów. Sprawdzaj je osobno, choć mogą się wzajemnie ujawniać. Przygotuj scenę obciążającą renderowanie oraz zestaw reguł działający bez grafiki. Dzięki temu wiadomo, czy spadek płynności zmienił sam przebieg symulacji, czy jedynie sposób jego pokazania na ekranie.
Przy odbiorze gry od MyTworzymy.pl warto połączyć krótką sesję swobodnej rozgrywki z ustalonym zestawem kontroli. Pierwsza pokazuje zrozumiałość i tempo zabawy, drugi potwierdza konkretne warunki techniczne. Taki podział ułatwia rozmowę także z zespołem rozproszonym po Polsce: „nie podoba mi się tempo” i „nie naliczono punktu według reguły” stają się dwoma odrębnymi zadaniami.
Zachowuj mały zestaw regresji
Po naprawieniu błędu dodaj przypadek, który go wywołał, do stałych testów. Nie musi zawierać całej historii użytkownika; wystarczy najmniejszy przebieg pozwalający odtworzyć problem. Przed kolejnym wydaniem sprawdź początek, koniec, restart, zapis i najważniejsze granice zasad. Nowa dekoracja poziomu nie powinna niepostrzeżenie zmieniać warunku zwycięstwa.
Raport z testów powinien podawać wersję gry, środowisko i zakres, którego nie sprawdzono. Emulator telefonu nie jest tym samym co rzeczywiste sterowanie dotykiem na urządzeniu. Nie ma potrzeby udawać pełnego pokrycia wszystkich kombinacji. Rzetelny odbiór wskazuje, jakie zachowania potwierdzono i gdzie nadal pozostaje ryzyko wymagające obserwacji po publikacji.
W zgłoszeniu błędu oddziel stan początkowy od obserwacji i oczekiwania. Informacja „po trzeciej pomyłce nadal mogę poruszać postacią, choć wynik końcowy jest widoczny” wskazuje konkretną sprzeczność. Sam opis „gra się zacina” nie pozwala ustalić, czy problem dotyczy sterowania, reguł, animacji czy połączenia z serwerem.