Transkrypt Filmu
Opowieść o bugach trzeba zacząć od pewnej istotnej kwestii, która nie jest oczywista dla wszystkich. Twórcy gier, są świadomi wielu bugów.
Czasami po premierze gier, padają komentarze, jakim cudem oni tego nie zauważyli? Mają tych testerów czy nie? Otóż mają.
Gry to ogromne projekty, nad którymi pracują dziesiątki albo i setki ludzi. Przy takiej układance łatwo o błąd. Szczególnie, że firmy często dzielą pracowników na zespoły, które pracują nad swoją częścią i potem dopina się to do całości. Więc dany element musi pracować sam w sobie, ale też zgrywać się z pozostałymi.
Podziały mogą być różne i zależą od firmy, ale możemy mieć prosty podział na np. grafików i programistów, albo bardziej zaawansowane podziały, gdzie tworzone są mniejsze zespoły mające designera, grafika, programistę i dostają mały wycinek gry, który mają przygotować. Wszystko zależy od projektu i firmy, więc nie będziemy w to wnikać, ale chodzi o pokazanie, jak rozbudowana siatka zależności może nam wyjść.
To nie sam podział zadań jest tutaj winowajcą, a to co zniszczyło już wiele gier… czas. Premiery gier są znane i twórcy muszą się wyrobić z terminami. Przez to, mimo wiedzy na temat wszystkich bugów, muszą podjąć trudne decyzje. Bugi się kategoryzuje i ustala się im priorytety. Ważniejsze jest załatanie błędu, który wywala całą grę, niż przenikającą przez ścianę paprotkę. Ważniejsze jest naprawienie błędu, który pojawia się często, niż takiego, który zobaczy ułamek graczy, bo wspięli się na stół o godzinie 6:08 nosząc złote pantalony poklasku +5.
Każdy kto pracował z oprogramowaniem wie, że jest jeszcze jeden problem łatania błędów. Problem hydry. Czyli, czasami naprawienie błędu X, powoduje, że pojawia się problem Y, Z, A, C, R oraz 8. Ostatecznie, przy ograniczonym czasie, zostawienie błędu X jest mniejszym złem.
Również istotniejsze jest ładnie błędów z początku gry, bo te zobaczy każdy, niż te z końca, albo z misji pobocznej, bo mamy kilka dodatkowych dni na ich naprawienie, kiedy na początku trafią na nie tylko zapaleńcy, grający w naszą grę po 24 godziny na dobę.
Pracę nad znajdowaniem błędów utrudnia również sprzęt. O ile w przypadku konsol, każdy gracz ma to samo co deweloperzy, testowanie jest łatwiejsze. W przypadku PC, nie ma fizycznej opcji sprawdzenia wszystkich dostępnych konfiguracji, więc może się okazać, że jakaś płyta główna, albo jakiś procesor źle sobie radzi z zarządzaniem pamięcią i gra się sypnie, tutaj zbawienne mogą być popularne ostatnio zamknięte bety.
Problemem mogą być też sami gracze, którzy czasami potrafią wykorzystać grę w sposób kompletnie nieprzewidziany przez twórców, generując nowe błędy.
Pamiętajmy też, że po każdej dawce nowego kodu z naprawą błędów, wszystko trzeba ponownie przetestować, więc czas naprawy nie jest nieograniczony, trzeba działać szybko, sprawnie, ale też rozważnie i sprytnie.
Żeby nie kończyć materiału w tym miejscu, postanowiłem rzucić okiem na bardzo częste, drobne bugi, które pojawiają się w różnych grach i spróbować wyjaśnić, skąd się mogą brać. Oczywiście pomijam błędy np. w balansie gry, bo to kwestie designerskie i one swoje źródło mają w innym miejscu.
Przenikające tekstury
Źródła tego problemu mogą być dwa. Źle przygotowany model, gdzie po prostu mamy dziurę – bardzo powszechny błąd u początkujących grafików 3D to odwrócenie normali, czyli sytuacja gdzie tekstura na danym trójkącie renderuje się, ale jak by do środka obiektu, a od zewnątrz jest przeźroczysta. To się raczej nie zdarza, przynajmniej w większych studiach.
Drugi problem to ustawienia kamery. Kamera to obiekt w świecie gry, który decyduje co w zasadzie jest renderowane i wyrzucane na ekran. Mogą się tu zdarzyć dwie rzeczy. Jedna to źle dobrane krawędzie renderowani, czyli mówiąc wprost, od jakiego miejsca do którego renderujemy obraz. W takim przypadku, jeśli uda się stanąć za blisko jakiegoś obiektu, zacznie znikać.
Często w grze mamy tak naprawdę kilka kamer, które renderują różne rzeczy. Np. w strzelankach, broń często jest renderowana przez inną kamerę niż reszta gry. Gdyby robiła to jedna kamera, w momencie gdybyśmy podeszli do ściany broń by w niej znikała. Tak, kamera z bronią nie widzi ścian i renderuje broń zawsze w całości.
Błędna linia dialogowa lub tekst
Tutaj mamy do czynienia z problemem excela. Często teksty z gry, są trzymane w zewnętrznym pliku np. csv, aby można było łatwo je edytować bez zewnętrznych narzędzi. No i czasami się zdarzy tak, że dana komórka w pliku będzie pusta, albo źle wypełniona. Wina może też leżeć po stronie programisty, który w danym miejscu umieścił zły klucz, przez co tekst został wzięty z innej komórki, albo widzimy dziwnie wyglądające teksty jak ten na ekranie.
Za szybko działające elementy
W przypadku silnika Unity, podstawową funkcją jest funkcja Update, która wykonuje się co klatkę. Klatki są zależne od mocy sprzętu. Więc jeśli jakaś istotna akcja, np. prędkość biegu jest umieszczona w tej funkcji i nie jest to odpowiednio napisane, to np. zmęczenie będzie malało zależnie od liczby klatek na sekundę. Taki błąd miało Red Dead Redemption 2, gdzie bohater gry stawał się głodny szybciej na mocnym sprzęcie.
Błędy kolizji
Czasem dzieje się tak, że obiekt przenika przez ścianę, albo inny obiekt na którym powinien się zatrzymać. Mówimy tutaj o kolizji. Problem z kolizjami jest taki, że to też obliczenia, więc nie są wykrywane bez przerwy. Jeśli źle dobierzemy metodę lub prędkość przesuwania obiektu, może się okazać, że przedmiot zdąży minąć wykrywanie kolizji. Przemieszczanie obiektu, to też tak naprawdę zmienianie jego pozycji w świecie o jakąś wartość. Jeśli prędkość jest np. uzależniona od klatek, na mocnym sprzęcie, któreś dodawanie przemieści obiekt, nawet za ten z którym miał kolidować, sprawiając wrażenie, że przez niego przeniknął.
Blowanie się NPC
Chyba nic nie wkurza tak, jak blokujący się NPC. Wyszukiwanie ścieżki wydaje się rzeczą skomplikowaną, ale większość branży stosuje jeden algorytm – A*. Kluczem jest optymalizacja tego algorytmu. W przypadku Unity, możemy wykorzystać NavMesha, który generuje siatkę po której można się ruszać. Problem może się pojawić, jeśli designer dodał jakiś element, ale nie obliczył siatki na nowo i NPC nie są świadomi obiektu, w który wbiegają. Algorytm może również nie uwzględniać obiektów ruchomych, wtedy wystarczy, że naszemu NPC drogę przetnie inny bohater niezależny i mamy problem.
Inny potencjalny problem to nieuwzględnienie rozmiaru postaci. Jeśli cała ścieżka jest obmyślana o normalnych bohaterach, a gdzieś wstawimy np. większego bossa to ten goniąc bohatera może gdzieś utknąć.
Dziwne zachowanie postaci
Pomijam tutaj błędy w samym AI rywali. Ale czasami po przejściu w pewne miejsce, coś powinno się zdarzyć. W grach wykorzystuje się eventy, po wejściu w wyzwalacz, zdarzenie powinno się wydarzyć. Niby proste, ale często te wyzwalacze operują na podobnych zasadach co kolizję, więc znów gracz poruszający się szybciej niż przewidzieli to twórcy, może nie wyzwolić zdarzenia.
Wyzwalacze są też ustawiane w wąskim gardle, czyli obszarze przez, który gracz musi przejść. Jednak gracze nie byliby graczami, gdyby nie wchodzili od innej strony i wtedy zdarzenie się nie uruchomi. Ponownie przykładem może być Red Dead Redemption 2, gdzie jadąc do zadania wdałem się w bójkę i niestety zginąłem. Gra pojawiła mnie w obozie. Dokładnie w tym, do którego kierowała mnie misja. Obóz był pusty, wystarczyło odejść jakiś kawałek od obozu, aby NPC związani z zadaniem się w nim pojawili.
Mam nadzieję, że ten materiał sprawi, że twórcy dostaną od was mały kredyt zaufania i nieco wyrozumiałości, bo niektóre błędy to naprawdę nie ich wina i bądźcie pewni, że robią wszystko, żeby błędów było jak najmniej.