Czy istnieją metody automatycznego testowania gier?
Doceniane są konkretne doświadczenia, wraz z odpowiednimi informacjami na temat projektu, takimi jak platforma i rodzaj gry, jeśli to pomaga w wyjaśnieniu.
Czy istnieją metody automatycznego testowania gier?
Doceniane są konkretne doświadczenia, wraz z odpowiednimi informacjami na temat projektu, takimi jak platforma i rodzaj gry, jeśli to pomaga w wyjaśnieniu.
Odpowiedzi:
Niezależna gra jednoosobowa. Była to gra czołgowa dla wielu graczy z niszczycielskim terenem, a niszczycielski teren i kod zderzenia okazały się nieco niestabilne.
Skończyło się na przygotowaniu podstawowych głupich AI (przez „głupie”, mam na myśli „absolutnie idiotyczne” - losowo wybrali „jedź w kierunku wrogiego czołgu”, „jedź od wrogiego czołgu” i „jedź w losowym kierunku” ”, podczas losowego strzelania z głównej broni) i grania z maksymalną szybkością klatek podczas nagrywania naciśnięć klawiszy. Mam około 10-15 razy w czasie rzeczywistym. Kod został mocno potwierdzony, więc jeśli coś pójdzie nie tak, zrzuci cały dziennik naciśnięć klawiszy na dysk wraz z raportem błędu i początkowym losowym początkiem. Mógłbym wtedy przejść i odtworzyć dziennik naciśnięć klawiszy, aby dokładnie powielić stan, lub po prostu debugować z raportu o błędach.
Pozostawiłem to działające nieprzerwanie przez dosłownie miesiące. Na początku rzadko bywało godzinę bez awarii - musiałem tam siedzieć i opiekować się nim przez tydzień, zabijając kilka niejasnych błędów dziennie. W końcu doszło do tego, że działał przez tydzień między awariami, co przekłada się na około 1500 godzin gracza na awarię.
To było bezcenne i serdecznie polecam.
W przypadku MMO, nad którym pracowałem (100-stu programistów, skupionych na komputerach PC), próbowaliśmy dodać ogromną różnorodność automatycznych testów z różnym powodzeniem. Oto, co zadziałało:
Co nie działało:
Pracujesz nad strategią 4x z walką 3d (myśl, że Homeworld spotyka Masters Of Orion), która niestety nigdy nie ujrzała światła dziennego, ponieważ firmie zabrakło funduszy.
Zawsze zapewniałem, że możesz grać w tę grę bez ludzi, dzięki czemu możemy pozostawić grę uruchomioną na noc.
Moglibyśmy wyłączyć walkę 3D (uproszczoną do losowego wyniku) i zostawiliśmy silnik strategii AI sam w sobie. Znalazło to wiele błędów i problemów. Nie tylko pokazują błędy stoppera, ale także błędy strategii, w których (np.) Strategie AI zostałyby zakleszczone i spędziłyby tysiące tur, nie robiąc „właściwej rzeczy”. Tego rodzaju błędy były trudne do wykrycia po prostu podczas „gry”.
Na strzelance FPS, nad którą pracowałem (Descent 3 - Linux / Mac / Windows, ~ 30 osób w zespole w 1999 r.), Możliwość nagrywania / odtwarzania demo okazała się niezwykle przydatna. Udostępniłem opcję, w której można odtwarzać demo tak szybko, jak gra może renderować klatki, i stał się to świetny sposób na sprawdzenie wydajności po zmianie wielu rzeczy.
Ćwiczył także dużo kodu poza systemem renderowania, więc był to dobry test poprawności. Po wprowadzeniu wielu zmian mogłem po prostu uruchomić odtwarzanie demo 10 minut gry. Wiele razy łapałby błąd w obszarze, o którym bym nie pomyślał.
Mieliśmy strzelankę OpenWorld (x360, PS3, PC), która zastosowała szybki test smoketest na serwerze kompilacji - załadowała grę, przeszła przez interfejs, uruchomiła [awatara] do przodu, zrzuciła zrzut ekranu i wyszła. Jeśli cctray wykryje czyste wyjście, kompilacja zakończyła się sukcesem.
Pracowaliśmy nad nim przez ostatni rok projektu, a zespół liczył około 100 programistów.
Był skuteczny w wykrywaniu błędów związanych z showstopowaniem, ale łatwo było stworzyć kompilację, która przeszła najdelikatniejsze, ale zawiodła większość „prawdziwych” poziomów, nie działała w trybie dla wielu graczy lub niszczyła AI, więc nie była idealna. Zdecydowanie warto było to zrobić.
Słyszałem, że odkąd opuściłem, zaczęli organizować większą liczbę testów smoketestów, przeznaczonych dla wielu komputerów. Najwyraźniej utrzymywanie testów smoket to problem, a niewielki zespół zajmuje się utrzymywaniem serwerów kompilacji i oprogramowania, więc nie mogę powiedzieć, czy to był sukces, czy nie.
Moje doświadczenie z automatycznymi testami podczas tworzenia Crysis 2 jest dostępne tutaj: http://yetanothergameprogrammingblog.blogspot.com/2010/06/aaa-automated-testing.html
Podsumowanie:
Rozwój gry jest w rzeczywistości jednym z tych przypadków, w których testowanie jednostkowe wydaje mi się mieć sens, ponieważ interakcje między systemami dyskretnymi są tak powszechne. Projektowanie na podstawie umowy jest oczywiście częścią tego i powinno być planowane od pierwszego dnia rozwoju, ale nie rozumiem, dlaczego nie można go wdrożyć później, zakładając, że istnieje taka możliwość.
Najtrudniejsze jest oczywiście testowanie integracji. Wiele gier można przetestować po prostu zapętlając wersję demo lub coś w tym stylu, ale te rzeczy są dość łatwe do debugowania - bardziej interesuje mnie odsłonięcie błędów, które pojawią się, gdy gracz coś zrobi, z myślą, że błąd, którego gracz nigdy nie widzi, jest oczywiście mniej ważny niż błąd, który robi gracz.
Co oczywiście jest dość trudne. Taktyki, które działają w innych aplikacjach (fuzzowanie, oczekiwany przebieg / oczekiwany błąd itp.) Nie działają tutaj tak dobrze. W systemach skryptowych wydaje się, że budowanie zestawu testowego skryptów do symulacji gracza jest właściwą drogą (patrz odpowiedź JZiga). Ale testowanie konkretnie rzeczy, które gracz może napotkać bezpośrednio, wydaje mi się najlepszym miejscem do skupienia czasu zarówno na testach ludzkich, jak i automatycznych.