Minęło wiele lat, odkąd grałem w gamedev, ale oprócz ładnej odpowiedzi, jest kilka rzeczy, które chcę dodać i opisać szczegółowo.
Po pierwsze, wspomniano już, że dane wyjściowe są tylko wizualne i dźwiękowe przy ograniczonych ograniczeniach „krytycznych dla FPS” i budżetach obliczeniowych / pamięci. Pomysły poprawności stają się rozmyte, gdy pytania brzmią bardziej: „Czy to dobrze wygląda? Czy działa płynnie, bez żadnych zacięć? Czy brzmi świetnie?” podczas gdy programiści dostosowują, dostrajają i zbliżają, a współpraca projektantów / twórców prowadzi do tego, że z każdą szybką iteracją rzeczy wyglądają i brzmią nieco inaczej.
Kolejnym jest to, że testerzy mogą być niesamowici! Nigdy nie znalazłem bardziej oddanej grupy testerów w żadnej innej domenie, ponieważ tego chcąprzetestować oprogramowanie. Oni się bawią. Są uzależnieni i śpią przy komputerze, odkrywając każdy zakątek twojej gry. Łatwo jest odkryć nawet najdziwniejsze usterki, gdy ludzie naprawdę dobrze się bawią, testując każdy zakątek oprogramowania, będąc praktycznie od niego uzależnionym. W mojej obecnej branży testerzy są nieco trudniejsi do pracy, ponieważ wielu z nich to profesjonaliści przywiązujący się do oprogramowania, dlatego polegają na kilku funkcjach, aby wykonać swoją pracę i niekoniecznie są zainteresowani wyczerpaniem cały zakamarek cały czas. Oczywiście, gdy nie możemy polegać tak bardzo na testerach ludzkich, potrzebujemy więcej testów automatycznych.
Jeszcze inna jest to, że podstawa kodu dla gry zazwyczaj nie jest utrzymywana, modyfikowana i przedłużana przez lata. To nie jest tak, że twórcy Super Mario, którzy pierwotnie opracowali go w asemblerze 6502, musieli zachować wszystko, co przypominałoby ten oryginalny kod długo po wydaniu gry. Doom 3 prawdopodobnie używa zerowych linii kodu (lub zamykania) z Doom 1. Jeśli trwa ciągła seria, nowsze gry bardziej przypominają „kontynuacje” niż „aktualizacje”. Większość gier po prostu wysyła i być może wydaje niektóre łatki, DLC, a potem kod jest gotowy. To ogromny kontrast z moją branżą VFX, w której pracowałem nad utrzymywaniem kodu z czasów Amigi, który był przenoszony i utrzymywany przez dziesięciolecia. Gry zazwyczaj nie
Jednym z powodów tej krótkotrwałej natury baz kodowych gier jest to, że są one tak przywiązane do sprzętu. W połączeniu z ich najnowszą naturą i wymaganiami krytycznymi dla FPS, często nie można ich opracować w sposób, który wyodrębnia szczegóły sprzętowe, a nawet nie są blisko. Często są pisane bardzo konkretnie z myślą o docelowym generowaniu sprzętu i zwykle nie trwa długo, zanim PS3 zostanie zastąpione PS4, które następnie stanie się przestarzałe i zastąpione PS5 i tak dalej, i to wszystko bardzo szybko. Możliwości sprzętowe odgrywają tak istotną rolę w projektowaniu i rozwoju gry, że generalnie nie warto próbować utrzymywać dużo tego samego kodu napisanego dla PSX jak dla PS4, np. Większość serii gier trwających od pokoleń wciąż pisze silniki nowej generacji głównie od podstaw dla najnowszego sprzętu.
Z krótkotrwałą bazą kodu przychodzi ograniczony czas konserwacji (tj. Ograniczony czas, w którym kod musi zostać zmodyfikowany). W związku z ograniczonym czasem na zmianę kodu, który nie obejmuje lat, a zakres silnika rośnie z każdym uaktualnieniem, a wraz z faktem, że gry nie są bliskie krytycznej misji, nie ma tak absolutnie krytyczna potrzeba zastosowania najbardziej wyczerpujących testów jednostkowych i integracyjnych. Zapewnienie integralności przyszłych zmian nie przyniesie żadnych korzyści, jeśli przyszłe zmiany nie zostaną wprowadzone, a aspekt testowania i refaktoryzacji starszych baz kodów jest oczywiście nieistotny, jeśli w ogóle nie ma „dziedzictwa”.
Innym małym, który nie zawsze jest odpowiedni, jest to, że gra może być ukierunkowana tylko na bardzo wąski zakres sprzętu bez portów na pulpicie. W takich przypadkach eliminowane jest ogromne źródło nieprzewidywalnych usterek w tych kontekstach, czyli użytkownicy korzystający z oprogramowania z zupełnie innym sprzętem i sterownikami.
To powiedziawszy, testy integracyjne na najwyższym / najgrubszym poziomie wydają się być od razu bardziej przydatne. Na przykład wiele gier może wykorzystywać sposób rejestrowania zmian stanu gry w czasie dla „powtórek”. Takie funkcje odtwarzania mogą zapewnić deterministyczność gry, a także mogą być używane jako samodzielne narzędzie testowe do odtwarzania sesji gry zarejestrowanej wcześniej przez kogoś innego.
Zetknąłem się także z gamedevami pracującymi w małych studiach, którzy robili takie rzeczy, jak pisanie botów do swojej gry i kazali robotom grać w grę z maksymalną prędkością i uruchamiać tę symulację, początkowo napotykając niejasną awarię po dniu lub dwóch, potem naprawiłem, a potem ponownie uruchomiłem symulację i powtarzałem ją, dopóki nie było więcej zatrzymujących show awarii, nawet po kilkutygodniowym uruchomieniu. Istnieją więc interesujące podejścia pragmatyczne, takie jak te, które widziałem od gamedevów do testowania swojego oprogramowania, ale często w sposób, który przypomina najgrubszy poziom testów integracyjnych i bardzo ścisłą symulację rzeczy, w jaki sposób gracze faktycznie wchodzą w interakcję z grą.
Wreszcie, te duże silniki gry AAA zaczynają przypominać zupełnie inny rodzaj bestii: długowieczny, skutecznie udoskonalając sprzęt nieco lepiej, z większymi bazami kodów i dłuższymi okresami konserwacji, podczas gdy ich edytory poziomów zaczynają przypominać pełnowymiarowe środowiska programistyczne. Wyobrażam sobie, że te duże silniki prawdopodobnie wymagałyby dokładniejszej procedury testowej, zwłaszcza jeśli czas utrzymywania kodu znacznie się wydłuży. Wciąż wiele studiów gier nie pisze wielkich silników gier AAA: albo je licencjonują, albo opracowują mały, zastrzeżony silnik, który ma znacznie mniejszy zakres i nie będzie utrzymywany przez lata.