Twórcy GTA III zmagali się z błędami w grze przez większość czasu produkcji. Wynikało to przede wszystkim z faktu, że tytuł powstawał od zera, ale sprawy nie ułatwiał też niezbyt stabilny silnik.



Zanim Obbe Vermeij zdecydował się usunąć większość postów ze swojego bloga, pojawiło się na nim kilkanaście bardzo ciekawych wpisów. W najbliższych tygodniach będę przytaczał tutaj poruszone w nich tematy. Szkoda żeby utonęły w odmętach internetu.

Silnik RenderWare, na którym działały części serii wydane w latach od 2001 do 2007, nie był jeszcze dojrzały kiedy powstawało GTA III. W czasie produkcji rzadko udawało się ukończyć misję bez awarii gry, a płynność rozgrywki oscylowała w okolicach 10 klatek na sekundę. Szczególnie dużo problemów sprawiała twórcom detekcja kolizji.

To, że widzimy różne obiekty w grze, i że one przez siebie nie przenikają to często dwie osobne rzeczy. Wykrywanie kolizji pochłania sporo zasobów, więc trzeba oszczędnie z niego korzystać. Niestety często prowadzi to do powstawania w mapach niewidzialnych dziur. Liberty City w Grand Theft Auto III było nimi wręcz usiane.

Przy GTA IV problem był jeszcze bardziej złożony, bo postacie potrafiły przenikać przez mapę lub nie w zależności od aktualnie odtwarzanej animacji. Testerzy nie byli w stanie sprawdzić wszystkich możliwych scenariuszy, w których błąd występował, więc Alexander Roger stworzył dla nich specjalną broń strzelającą... modelami postaci. Odtąd testerzy mogli ostrzeliwać obiekty w grze w poszukiwaniu dziur i dzięki temu znacznie szybciej wyłapywać najbardziej rażące błędy.

Osobną sprawą są zmiany wprowadzane w grze na przestrzeni całego procesu produkcyjnego. Każda może spowodować pojawienie się nowego błędu. Jak wspomina Obbe bywało, że od implementacji czegoś nowego w grze do przygotowania kolejnej wersji poglądowej dla kierownictwa w Nowym Jorku, nie mijało dużo czasu. Testerzy urządzali prawdziwe speedruny by upewnić się, że do gry nie wkradły się jakieś błędy uniemożliwiające jej ukończenie. GTA III byli w stanie sprawdzić tak w mniej więcej 1 godzinę i 20 minut. Całkiem nieźle biorąc pod uwagę, że aktualny rekord wynosi niespełna godzinę.

Za czasów Grand Theft Auto III, zanim powstała baza błędów, informacje o nich były drukowane i wędrowały między biurkami. Raporty niejednokrotnie tworzyły pokaźnych rozmiarów stosy.

Podczas produkcji GTA San Andreas konieczne było poprawienie łącznie około... 70 tysięcy różnego rodzaju błędów. W przypadku Grand Theft Auto IV liczba ta była prawie dwa razy większa.

Po sukcesie pierwszego Grand Theft Auto, DMA Design znalazło się w centrum zainteresowania branżowych gigantów. Do 1998 roku nastąpiła seria przejęć. Studio kilka razy zmieniało właścicieli, by ostatecznie trafić pod skrzydła Take-Two Interactive i zostać wcielonym do rodziny Rockstar Games.



Zanim Obbe Vermeij zdecydował się usunąć większość postów ze swojego bloga, pojawiło się na nim kilkanaście bardzo ciekawych wpisów. W najbliższych tygodniach będę przytaczał tutaj poruszone w nich tematy. Szkoda żeby utonęły w odmętach internetu.

W roku 1999 otwarte zostało nowe biuro w Edynburgu. Członkowie zespołu otrzymali propozycję przenosin, na którą większość przystała. Kilka miesięcy później biuro w Dundee zakończyło działalność.

Był to okres, w którym ekipa w Edynburgu nie miała wiele do roboty. Kierownictwo w Nowym Jorku nie przysyłało żadnych wytycznych, więc ludzie zaczęli rozwijać projekty poboczne. Leslie Benzies i Aaron Garbut pracowali nad grą w uniwersum Godzilli. Chodziły słuchy, że David Jones może pozyskać potrzebne prawa do marki. Obbe zaangażował się w projekt gry wyścigowej.

W pewnym momencie Benzies i Garbut zaczęli jednak myśleć o kolejnym GTA. Plan był taki, żeby po prostu przenieść rozgrywkę w trójwymiar. Większość osób ze starego zespołu stojącego za Space Station Silicon Valley dołączyła do projektu. Pozostali zaangażowali się w rozwój innego pomysłu, którym później okazał się być Manhunt.

Co ciekawe, jeszcze zanim pełną parą ruszyły prace nad GTA III, w Dundee przez chwilę powstawało coś co wewnętrznie było nazywane GTA 2,5. Była to odsłona serii, której akcja toczyła się w Miami, a wydarzenia gracz obserwował w widoku izometrycznym. Za projektem stali oryginalni twórcy Grand Theft Auto, ale został on porzucony wraz z zamknięciem biura.

Wszyscy wiemy jak działają kody w serii Grand Theft Auto. Co, że niby nie używacie? Taa, jasne ;) A wiecie jak to jest, że gra rozumie co jest kodem, a co nie?



Zanim Obbe Vermeij zdecydował się usunąć większość postów ze swojego bloga, pojawiło się na nim kilkanaście bardzo ciekawych wpisów. W najbliższych tygodniach będę przytaczał tutaj poruszone w nich tematy. Szkoda żeby utonęły w odmętach internetu.

Aby aktywować cheata w dowolnej trójwymiarowej części serii GTA, wystarczy zacząć wstukiwać określoną kombinację na kontrolerze lub klawiaturze. Jeśli nie pomylimy kolejności przycisków, po wciśnięciu ostatniego w sekwencji, gra aktywuje kod. Zostanie to również potwierdzone przez wyświetlenie na ekranie stosownego komunikatu.

Na komputerach kody są o tyle specyficzne, że mogą składać się z ciągów liter układających się w konkretne słowa. I tak dla przykładu możemy wpisać ILOVESCOTLAND by zaczął padać deszcz lub GUNSGUNSGUNS by uzbroić się po zęby.

Gra zapamiętuje zawsze około dwudziestu ostatnich naciśniętych przycisków/klawiszy i porównuje je z listą cheatów. W razie dopasowania następuje aktywacja kodu. Najprościej byłoby porównywać ciągi bezpośrednio, ale przez to lista dostępnych cheatów byłaby bardzo prosta do odczytania z pamięci urządzenia. Pierwszy lepszy haker mógłby odkryć i udostępnić wszystkie kody w dniu premiery gry. Z tego powodu, zamiast zapisywać kody otwartym tekstem, Obbe zdecydował się wykorzystać skróty.

Skrót to liczba obliczona na podstawie tekstu, np. z wartości ASCII przypisanej do każdego znaku. W prostym algorytmie wartości te można by do siebie dodawać. W ten sposób skrót dla ciągu ILOVESCOTLAND wyniesie 983, a dla GUNSGUNSGUNS - 951. Następnie tak samo obliczamy skrót dla ostatnich dwudziestu znaków i porównujemy wynik z listą. To oczywiście tylko przykład. W rzeczywistości algorytm jest bardziej skomplikowany.

To rozwiązanie spełniło swoje zadanie. Dostępne kody nie zostały szybko odkryte, a ludzie trafili na nie dopiero z czasem, próbując wprowadzać losowe ciągi. Wtedy okazało się jednak również, że podejście zastosowane przez Obbe nie jest idealne. W sieci zaczęły pojawiać się działające kody, które nijak nie przypominały tych faktycznie ustalonych przez twórców. Przykładowo HDLMAAXOPK daje taki sam efekt jak ILOVESCOTLAND.

Problem wynikał z tego, że skróty obliczane przez algorytm powtarzały się dla różnych ciągów. Wracając do naszego przykładu, nie ma przecież znaczenia w jakiej kolejności dodamy do siebie wartości ASCII. Tak samo, różne zestawy liczb po zsumowaniu mogą dać ten sam wynik. To była przyczyna całego zamieszania.

Ograniczona pamięć urządzenia, na którym działa gra to nie tylko problemy z pojazdami powtarzającymi się na drodze. Znacznie większym wyzwaniem jest ładowanie samej mapy. I tu do akcji wkracza... strumieniowanie.



Zanim Obbe Vermeij zdecydował się usunąć większość postów ze swojego bloga, pojawiło się na nim kilkanaście bardzo ciekawych wpisów. W najbliższych tygodniach będę przytaczał tutaj poruszone w nich tematy. Szkoda żeby utonęły w odmętach internetu.

Na początku prac nad Grand Theft Auto III twórcy mieli nadzieję, że uda się zmieścić całe Liberty City w pamięci PS2 i będzie można ładować wszystkie modele tylko raz, przy uruchamianiu gry. Niestety szybko okazało się, że ceną za to byłby zbyt wysoki poziom kompresji tekstur i konieczność ponownego ich wykorzystywania na różnych obiektach o wiele za często.

Wtedy zapytano Adama Fowlera czy mógłby opracować system strumieniowania. To technika polegająca na dynamicznym ładowaniu modeli i usuwaniu ich z pamięci w miarę jak gracz przemieszcza się po mapie. Urządzenie przechowuje wtedy w pamięci jedynie fragment świata gry w najbliższym otoczeniu gracza.

Rozwiązanie jest sprytne, ale też posiada mankamenty. W tamtych czasach wąskim gardłem był nośnik, a więc płyta CD, a raczej czytający ją napęd. Szybkość ładowania modeli uzależniona jest od rozmieszczenia danych na ścieżkach płyty. Im dalej od siebie umieszczone są kolejno czytane dane, tym więcej czasu tracimy na przesunięcie głowicy z laserem. Napęd bardziej też wtedy hałasuje, co może przeszkadzać graczowi w zabawie.

Adam spędził dużo czasu na optymalizowaniu układu plików na płycie. Chodziło o to żeby modele umieszczone blisko siebie na mapie, sąsiadowały również na nośniku. To jednak nie wystarczyło. W dalszym ciągu zdarzało się, że strumieniowanie nie nadążało za szybko przemieszczającym się graczem. Gdy więc nie było innego wyjścia, trzeba było go jakoś spowalniać.

Początkowo w Portland istniała długa aleja, biegnąca przez całą wyspę. Gracz mógł podróżować nią bardzo szybko, a do załadowania było mnóstwo budynków stojących wzdłuż drogi. Strumieniowanie tutaj nie wyrabiało. Ostatecznie artyści musieli zmienić układ mapy i najzwyczajniej w świecie postawić pośrodku alei budynek. Teraz gracz musiał zwolnić żeby go objechać, dając strumieniowaniu dodatkowy czas na doładowanie kolejnych modeli.

Z czasem na mapie rozpoznano więcej takich problematycznych obszarów. Utworzono na nich strefy, w których opór powietrza wobec pojazdów jest nieco większy (o pięć albo dziesięć procent). Bardzo to pomogło, a różnica była niemal niezauważalna.

Efekty pogodowe w serii Grand Theft Auto, jako jeden z budulców wiarygodnego otwartego świata, zawsze robiły wrażenie. Czy jednak pogoda dobierana przez grę w danym momencie była całkiem losowa?



Zanim Obbe Vermeij zdecydował się usunąć większość postów ze swojego bloga, pojawiło się na nim kilkanaście bardzo ciekawych wpisów. W najbliższych tygodniach będę przytaczał tutaj poruszone w nich tematy. Szkoda żeby utonęły w odmętach internetu.

Pogoda w GTA nigdy nie była losowa. Co to, to nie. Jakkolwiek przypadkowo by to nie wyglądało, za wszystkim prawie zawsze krył się schemat. Systemem zjawisk pogodowych kierował prosty, acz dość sprytny algorytm oparty na tablicy predefiniowanych ustawień.

Co godzinę czasu gry z tablicy wybierany był kolejny typ pogody. Tablica taka zawierała około 40 wpisów, więc jeśli "teraz" na przykład pada deszcz to możemy mieć pewność, że za 40 godzin czasu gry znowu będzie padało.

Okres zmiany typu pogody również trwał jedną godzinę. Czyli przykładowo jeśli o godzinie 14:00 było słonecznie, a o godzinie 15:00 miało już być pochmurnie, to wtedy:

• o 14:15 pogoda była w 75% słoneczna, a w 25% pochmurna,


• o 14:30 pogoda była w 50% słoneczna i w 50% pochmurna,


• o 14:45 pogoda była w 25% słoneczna, a w 75% pochmurna.

Dzięki temu zmiana odbywała się płynnie, bez zwracania uwagi gracza. Oczywiście w tablicy często zapisywano taką samą pogodę na okres kilku godzin, abyśmy nie mieli wrażenia, że zmienia się ona cały czas.

Możliwa jest również zmiana typu pogody za pomocą skryptów. Pozwala to programistom wymusić konkretny rodzaj pogody na potrzeby jakiejś misji albo sceny przerywnikowej.