Twórcy Half-Life'a 2 stali się kolejną ofiarą drzwi w grach wideo, kiedy po 9 latach odkryli błąd, który najwyraźniej jakimś cudem zainfekował nawet oryginalne wydanie hitu Valve.
Oryginalny Half-Life’a 2 miał zostać „zainfekowany” przez „nowy” bug prawie 10 lat po premierze kultowego FPS-a.
Half-Life 3 nadal żyje jedynie w marzeniach graczy (przynajmniej oficjalnie), ale Valve nie zapomniało zupełnie o swojej kultowej serii. Po „wirtualnym” Half-Life: Alyx firma uczciła rocznice premier dwóch głównych gier z cyklu specjalnymi aktualizacjami, a także udostępnieniem za darmo obu epizodów „dwójki”.
Oczywiście, jak to często bywa, nie obyło się bez pewnych problemów, a obie gry otrzymały pomniejsze aktualizacje, m.in. w celu ugłaskania speedrunnerów. A to bynajmniej nie pierwszy raz, gdy powrót Valve do Half-Life’a zaowocował nowymi błędami. Nawet jeśli wcale nie były one „nowe”.
Szczególnie kuriozalny jest przypadek, o którym rozpisał się Tom Forsyth w serwisie Mastodon (via Games Radar). W 2013 roku były projektant Valve pracował z programistą Joe Ludwigiem nad przeniesieniem Half-Life’a 2 na nową platformę: Oculus Rift VR. Jednakże, ku zaskoczeniu obu, Forsyth natknął się na błąd, i to na tyle poważny, że praktycznie uniemożliwiał przejście gry.
Bug zdarzył się na bardzo wczesnym etapie rozgrywki i w praktyce spowodował, że Gordon Freeman utknął w pokoju już we wstępie. Co więcej, jego współpracownicy i znajomi potwierdzili, że jakimś cudem ten sam bug trafił także do oryginalnej wersji gry z 2004. Nie był to więc błąd wprowadzony przez Forsytha lub Ludwiga.
To o tyle zaskakujące, że w tym czasie Half-Life 2 miał już prawie 10 lat, a mimo to żaden z twórców nie pamiętał takiego błędu. Zresztą tak poważny bug nie mógłby zostać przeoczony. Mówimy przecież o sekwencji otwierającej grę, do tego na tyle ograniczonej w kwestii działań gracza, że nie było praktycznie żadnych szans, iż ta usterka wynikała z jego zachowania.
Innymi słowy, wyglądało to tak, jakby zupełnie nowy bug odbył podróż w czasie i zainfekował oryginalne HL2.
Jak to możliwe? W tym momencie ludzie wpadają w panikę – to nie jest zwykły błąd – wygląda na to, że cofnął się w czasie i zainfekował oryginał!
Oczywiście plany wydania Half-Life’a 2 na Oculus Rift VR szybko zeszły na dalszy plan. Najważniejsze było usunięcie tej usterki, i to szybko.
Po mniej więcej dniu (i przypomnieniu sobie, jak korzystać z odpowiednich narzędzi) jeden z deweloperów wreszcie odkrył źródło usterki. To okazało się wyjątkowo banalne: obecny w pokoju strażnik stał minimalnie za blisko drzwi, które przy próbie otwarcia de facto odbijały się od jego palców u nóg i – zgodnie z kodem – automatycznie zamykały na głucho. Wystarczyło więc przesunąć postać o „mniej więcej milimetr” i voila: Gordon Freeman mógł kontynuować swoją przygodę w City 17.
Jednakże wciąż pozostawała jedna tajemnica do rozwiązania: dlaczego ten błąd pojawił się dopiero po tylu latach, mimo że w teorii był on obecny już w premierowym wydaniu gry? Odpowiedzią okazała się „stara dobra zmiennoprzecinkowość” – i postęp technologiczny na PC.
Jak wytłumaczył Forsyth, HL2 zadebiutował w 2004 roku, a choć instrukcje SSE (Streaming SIMD Extensions) zostały wprowadzone do procesorów 5 lat wcześniej (pozwalając na wykonywanie jednego polecenia na wielu danych jednocześnie), to nie były one jeszcze powszechnie stosowane. Dlatego w Half-Life 2 wykorzystano starszy zestaw instrukcji matematycznych i liczb zmiennoprzecinkowych (w wielkim skrócie: sposobu zapisu liczb rzeczywistych w kodzie komputerowym), który operował na „dziwacznym”, niespójnym „systemie precyzji”, co dało ciekawy efekt w połączeniu z bodajże najważniejszą nowinką w grze: systemem wiarygodnej fizyki.
Half Life 2 został pierwotnie wydany w 2004 roku i chociaż zestaw instrukcji SSE już istniał, nie był jeszcze powszechnie stosowany, więc większość HL2 została skompilowana z wykorzystaniem starszego zestawu instrukcji matematycznych 8087 lub x87. Ma on dziwaczny zestaw precyzji — niektóre elementy są 32-bitowe, inne 64-bitowe, a jeszcze inne 80-bitowe, a dokładna precyzja poszczególnych fragmentów kodu jest nieco zagadkowa.
Jednakże dziesięć lat później, w 2013 roku, SSE było już od pewnego czasu standardem we wszystkich procesorach x86 – system operacyjny był od niego zależny, więc można było na nim polegać. Oczywiście kompilatory używają go domyślnie – w rzeczywistości trzeba się bardzo postarać, aby wygenerowały stary (nieco wolniejszy) kod x87. SSE wykorzystuje znacznie dokładniej zdefiniowaną precyzję 32 lub 64 bitów, w zależności od wymagań kodu – jest to znacznie bardziej przewidywalne.
To zderzenie [drzwi i buta – przyp. red.] jest właściwie odwzorowane – dużą innowacją w grze HL2 było szerokie wykorzystanie prawdziwego silnika fizycznego. Drzwi i strażnik są obiektami fizycznymi, oba mają pęd, wywierają na siebie wzajemny impuls i chociaż zawiasy drzwi nie mają tarcia, buty strażnika mają pewien opór na podłodze.
W obu wersjach drzwi mają wystarczającą siłę, aby bardzo nieznacznie obrócić strażnika. Tarcie strażnika o podłogę nie jest wystarczające, aby temu zapobiec, więc obraca się on o ułamek stopnia. W wersji x87 ten niewielki obrót wystarcza, aby przesunąć jego palec u nogi, kolizja zostaje rozwiązana, a drzwi nadal się otwierają. Wszystko jest w porządku.
Jednakże w wersji SSE wiele drobnych szczegółów jest nieco innych, a połączenie tarcia podłogi i masy obiektów sprawia, że strażnik nadal obraca się w wyniku zderzenia, ale tym razem obraca się nieco mniej.
Krótko mówiąc, choć w obu przypadkach but strażnika stoi na drodze drzwi, nieprecyzyjność starych instrukcji sprawiła, że „tarcie” buta strażnika było wystarczające, by umożliwić mu „obrót” wystarczający do otwarcia drzwi. Tymczasem na SSE palec postaci nadal je blokuje, a więc gra nie ma innego wyjścia, jak je zamknąć – i zablokować graczowi dalszą drogę.
Tak właśnie bug, który istniał w kodzie HL2 od samego początku, objawił się dopiero prawie 10 lat później: przez zmiany nie w samej grze, lecz w oprogramowaniu sprzętu. Trzeba przyznać, że nawet jak na standardy gier to dość kuriozalna usterka.
Nie żeby był to jedyny przypadek, kiedy drzwi przysporzyły deweloperom sporo frustracji. Po prawdzie seria wpisów Forsytha była odpowiedzią na kolejne dyskusje na temat tego, jak ten niepozorny element jest zmorą dla twórców gier.
Ba, istnieje nawet pojęcie „problemu drzwi” („door problem”): na określenie pozornie banalnych elementów, których dodanie jest wyzwaniem dla twórców gier. Termin ma swój wpis na Wikipedii, a zawdzięczamy go Liz England, która swego czasu pracowała w Insomniac Games oraz w Ubisoft Toronto.
Forsyth podsumował swoją historię krótko, dając wyraz niechęci twórców gier do drzwi i powiązanych z nimi problemów:
I o to jest. Dwie największe farmy błędów w gamedevie – drzwi oraz zmiennoprzecinkowość –sprawiły, że prosty błąd związany z umieszczaniem postaci niezależnych przerodził się w prawdziwą podróż w czasie. /koniec
Więcej:EA pęka z dumy. Battlefield 6 dominuje i nazywa grę „najlepiej sprzedającą się strzelanką tego roku”
GRYOnline
Gracze
Steam
1

Autor: Jakub Błażewicz
Ukończył polonistyczne studia magisterskie na Uniwersytecie Warszawskim pracą poświęconą tej właśnie tematyce. Przygodę z GRYOnline.pl rozpoczął w 2015 roku, pisząc w Newsroomie growym, a następnie również filmowym i technologicznym (nie zabrakło też udziału w Encyklopedii Gier). Grami wideo (i nie tylko wideo) zainteresowany od lat. Zaczynał od platformówek i do dziś pozostaje ich wielkim fanem (w tym metroidvanii), ale wykazuje też zainteresowanie karciankami (także papierowymi), bijatykami, soulslike’ami i w zasadzie wszystkim, co dotyczy gier jako takich. Potrafi zachwycać się pikselowymi postaciami z gier pamiętających czasy Game Boya łupanego (jeśli nie starszymi).