O tworzeniu gier i sztuczkach używanych w kodzie

Świat gier wideo jest pełen niespodzianek. Na przestrzeni kolejnych generacji konsol przewijały się te mniej i bardziej odkrywcze, a dla zwykłego Kowalskiego nieinteresującego się branżą (z życiowym mottem ,,wrzucasz płytę i grasz”), były niczym wiedza bezużyteczna o przeprowadzanych testach na klikalność myszki komputerowej, którą użytkuje na co dzień. Jednak specjalnie dla tych drugich — ciekawskich i głodnych wiedzy — złożyłem wybrane tajemnice oraz fakty skrywane na przestrzeni lat we wpisach składających się na cykl. Od klocków z Tetrisa, dziwnych dźwiękach wydawanych przez Xboxa i prostokątnych pudełkach PlayStation, po zarobki twórców, samochodzie w Silent Hill, easter eggach, sztuczkach używanych w speedrunach i alternatywnych okładkach z gier. W skrócie: 30 krótkich faktów i ciekawostek, o których mogłeś nie wiedzieć. Zapraszam do trzeciej części: „O tworzeniu gier i sztuczkach używanych w kodzie.”


Zanim jednak zacznę wyliczankę po wybranych zagadnieniach, zachęcam do przeczytania wcześniejszych wpisów mojego autorstwa: Tajemnicze dźwięki, nazewnictwa i inne fakty skrywane przez konsole oraz Pewne fakty o nośnikach, pudełkach i okładkach. Proces tworzenia gier to dosyć obszerna dziedzina i w tym artykule pominę omawianie poszczególnych stanowisk, czy dokładnej pracy wykonywanej w procesie produkcji właściwej. Czyli mozolnego kreowania obiektów 3D, projektowania map, ścieżki dźwiękowej etc. Bo to już było i ile można wałkować ten sam temat, który pojawiał się w czasopismach gamingowych, czy innych źródłach, o Wikipedii nie wspominając. Zajmijmy się więc mało rozpowszechnianym w opinii publicznej procesie preprodukcji. W końcu zanim panowie i panie zaparzą sobie kawki, zasiadając do komputerów, muszą mieć pełen zakres obowiązków, harmonogram pracy i ogólną koncepcję tworzonej gry. Jeszcze kilkadziesiąt lat temu w „garażowych” studiach zgodnie ze słowami mitologii greckiej „na początku był chaos”, szefostwo zbierało ekipę ludzi, każdy miał swoją koncepcję, ogólnie rozumując była tak zwana burza mózgów. Dzisiaj jest w sumie podobnie, ale jednak inaczej. Proces twórczy zaczyna się od wspomnianego chaosu w głowie dewelopera, jednak odpowiednia dokumentacja i narzędzia kompletnie różnią się od odręcznych notatek i harmonogramów pisanych na powieszonych arkuszach A2. W końcu tworzenie gier jest na tyle złożonym procesem, wymagającym masy poprawek, że nie sposób nad tym zapanować logistycznie do samego zakończenia prac. To nie film, gdzie nagrywane jest kilka scen zgodnie z ustaloną linią czasową, wstępem, rozwinięciem i zakończeniem oraz aktorami podążającymi za z góry ustalonymi linijkami tekstu scenariusza. To co wygląda super na papierze, niekoniecznie sprawdza się w koncepcyjnej wersji gameplayu. No ale, od czegoś trzeba zacząć, nieprawdaż? Obecnie składa się odpowiednią dokumentację projektową. Game concept, opisujący rodzaj gry oraz otaczający świat, vision document (mechanika, wstępne założenia rozgrywki), art design document (założenia dla grafików), project timeline document (harmonogram projektu z prezentacją stanu zaawansowania prac na poszczególnych zakresach i etapach), testing document (identyfikuje elementy gry narażone na błędy), technical document (zasady i elementy rządzące w grze) oraz game minute, który zawiera opis krótkich fragmentów rozgrywki, wskazujący w jaki sposób gracz ma na danym etapie się zachowywać.

Mike Dailly, jeden z głównych projektantów Grand Theft Auto – pierwotnie nazywany „Race'n'Chase” – udostępnił dokumenty projektowe kultowej gry, które pochodzą z 22 marca 1995 roku.Mike Dailly, jeden z głównych projektantów Grand Theft Auto – pierwotnie nazywany „Race’n’Chase” – udostępnił dokumenty projektowe kultowej gry, które pochodzą z 22 marca 1995 roku.


Niemal każda z tych dokumentacji jest tak samo ważna, ale teraz skupmy się tylko na dokumencie projektu gry i scenariusza, ponieważ artykuł też nie jest z gumy (hłe). Game design document (GDD) to w skrócie ogólny plan tworzonego oprogramowania tzn. gry, pomagający zdefiniować zakres prac nad produkcją i wyznaczający ogólny kierunek projektu, utrzymując zarazem cały zespół po tej samej stronie koncepcyjnej. Obejmuje on niemal wszystkie aspekty dotyczące tworzonego dzieła tj. gatunek, koncepcja, grupa docelowa, rozgrywka, GUI (interfejs użytkownika), zasady mechaniki, assety i wiele, wiele innych aspektów których nie sposób wymienić jednym tchem. Jednak wraz ze wzrostem elastyczności procesu tworzenia gry ewoluowało również podejście do dokumentacji. Obecnie GDD są pisane w grupie kilku osób, no chyba że ktoś jest niezależnym twórcą, jednoosobową armią jak Eric Barone i jego Stardew Valley. Rozpiski znajdujące się tam nie przekraczają zazwyczaj 50 stron, nie ma również ściany tekstu, a całość uzupełniona jest o stosowne grafiki. Chociaż to zależne jest od studia, w końcu na etapie produkcyjnym zmienia się zbyt wiele rzeczy, a pewne mechaniki, czy elementy w 15-30% są wywalane bezpowrotnie do kosza – dlatego niektórzy rezygnują z drobiazgowego omawiania jednej mechaniki na rzecz ogólnego konceptu, zadając sobie pytania i odpowiedzi: ile ma być światów, jak obszerne mają być lokacje, jaka jest liczba głównych bohaterów, czy ma być zastosowane drzewko rozwoju? itd. Na deser zostawiłem przykładową dokumentację do Silent Hill 2. Więcej dokumentów znajdziecie tutaj. Dotyczą głównie lat 90., jednak w doskonały sposób pokazują jak to wygląda w praniu.

Pisanie scenariuszy w grach jest skomplikowanym zajęciem. W końcu odbiegają one od linearnych założeń kinematografii skupiając się na wszystkich wariantach zdarzeń poprowadzonych przez gracza poprzez np. wybieranie odpowiednich opcji dialogowych. A nawet jeśli owe rozwidlenia nie występują to należy wziąć pod uwagę kolejność wypowiadanych tekstów i znaczenie dla dalszej części rozgrywki. Parę lat temu w wywiadzie były scenarzysta Wiedźmina, Artur Ganszyniec, stwierdził, że jeszcze kilkanaście lat temu (przy okazji pierwszej części Witchera), większość decyzji odnośnie scenariusza podejmowali „na czuja”. Dziś kluczowe do opowiedzenia emocjonalnej historii jest stawianie gracza przed ważnymi, i mającymi zauważalne konsekwencje decyzjami w dialogach. Wartym odnotowania faktem jest to, że scenariusze gier zapisywane są przy pomocy odpowiednich narzędzi/programów i nie występują w formie wydrukowanego, filmowo sformatowanego tekstu. Zwykle praca nad scenariuszami odbywa się na drzewach dialogów i grafach misji w ramach edytora, na którym powstawała gra. No dobra, a ile znaków (albo słów) liczy scenariusz w grach? Według oficjalnych danych The Elder Scrolls V: Skyrim liczył około 60 tys. linijek dialogów, Fallout 4 mógł pochwalić się niemal dwukrotnie większą ilością (110 tys.). Nie tak dawno podczas transmisji Xbox Tokyo Game Show 2021 reżyser gry Starfield, Todd Howard podzielił się informacjami na temat wielkości scenariusza, oscylującego w granicach 150 tys. linijek dialogów. Z najnowszych gier wyróżniającą pozycją jest izometryczny RPG kładący duży nacisk na aspekt narracyjny. Mowa o Disco Elysium zawierający bagatela milion słów. Nic dziwnego bo w grze funkcjonuje 70 unikalnych postaci, a z każdą z nich można naprawdę długo porozmawiać odkrywając przy tym ich tajemnice. Ten moloch z początku nie doczekał się spolszczenia pomimo specjalnej ankiety zrealizowanej przez samych twórców ZA/UM (wygrał język turecki, polski był na 3 miejscu), jednak twórcy w końcu zapowiedzieli napisy PL. Lepiej późno niż wcale.

Game design document (GDD) z Silent Hill 2. Tutaj można się dowiedzieć, ile razy trzeba uderzyć potwora żeby padł. X oznacza, że nie można zadać mu obrażeń, a O że broń pojawia się w grze później.


Okej, omawianie dokumentów i scenariuszy nie jest może zbyt „chwytliwym” tematem, dlatego spróbuję zejść na ciekawszy tor tematyczny, odpowiadając na takie pytania jak: dlaczego tworzenie gier jest takie długie?, ile zarabiają twórcy? na czym polega certyfikacja skończonego produktu oraz dlaczego tak ciężko jest zaprojektować sztuczną inteligencję? Z każdymi kolejnymi latami proces produkcyjny wydłuża się niczym gumka od majtek. Ma na to wpływ kilka czynników. Pierwszym jest oczywiście skala gry, i nie ma co porównywać długości tworzenia takiego molocha jak Red Dead Redemption z dowolnym indykiem. Chociaż nie do końca jest tak, że open world z miejsca robi się zdecydowanie dłużej niż grę o mniejszej skali. Na przykład długość produkcji Resident Evil VII wynosi około 3,5 roku, jedynie pół roku krócej niż Marvel’s Spider-Man, który to przecież miał przeniesiony Manhattan w skali niemalże 1/4 o powierzchni całkowitej 4.6mi², a złożoność systemu walki jest trudniejszym aspektem do zrobienia niż projektowanie systemu strzelania. Tu dochodzimy do kolejnych punktów: zasoby ludzkie, zastosowany silnik graficzny, rodzaj gry (w końcu szybciej robi się wyścigi arcade niż rozbudowanego rpg z masą dialogów i postaci), czy skomplikowanie zastosowanych mechanik. Może się okazać, że grupka ludzi będzie korzystała z gotowego silnika, jednak ich projekt zakłada ingerowanie w kod, rozbudowę elementów, które znacznie wydłużą czas produkcyjny. Również specyfika pracy tworzenia tego medium jest nieprzewidywalna i może się okazać, że studio traci pół roku kalendarzowego, wywalając do kosza pomysł, który tylko dobrze prezentował się na papierze. Wystarczy wspomnieć, że CD Projekt 9 miesięcy przed premierą Wiedźmina musiał wyrzucić połowę planowanych postaci oraz lokacji i przepisać scenariusz tak, by pasował do nowych warunków – z przyczyn produkcyjnych. Pisząc o czasie produkcyjnym gier nie sposób podzielić się przykładami. Premierowa odsłona Ubisoftowego Assassin’s Creed była równo 3 lata w fazie produkcyjnej, czyli… niemal tyle samo ile ostatnia część, Valhalla. Jakim cudem, skoro ten ostatni jest bardziej rozbudowany, ma obszerniejszą zawartość i ogólnie trzymając się wypowiedzi – przecież teraz gry tworzy się dłużej? Przede wszystkim obecnie francuski moloch liczy oddziały rozlokowane w 20 krajach, posiada więcej rąk do pracy i gotowe silniki generujące otwarte przestrzenie z mocą i szybkością działania porównywalną do pstryknięcia palcami przez Thanosa (hłe, hłe).

Zastanawialiście się jednak dlaczego pewne produkcje były tworzone 2-3 krotnie dłużej? Osiem lat to wspólne „osiągnięcie” dla zgoła odmiennych od siebie dzieł sztuki: The Last Guardian i Cyberpunk 2077. Mówienie, że The Last Guardian nie przeszło zwykłego cyklu związanego z dewelopingiem byłoby niedomówieniem. Podstawową przeszkodą były problemy techniczne i decyzja o przeniesieniu produkcji, zmianie platformy docelowej z PlayStation 3 na PlayStation 4. Jak wspomniał Yoshida jeszcze podczas prac przy wersji PS3 – „Prace posuwały się bardzo powoli. Było sporo kłopotów technicznych. Gra nie działała płynnie… było widać, że zespół musi pójść na kompromis w kwestii możliwości”. W międzyczasie Fumito Ueda i Jinji Horagai założyli zewnętrzne studio genDESIGN przydzielając na nowo robotę nad projektem, dzięki czemu cały proces produkcyjny przedłużał się o kolejne miesiące. Z Cyberpunkiem było trochę inaczej. Jak wyjaśnił popularny dziennikarz Jason Schreier, 8 letni proces produkcyjny był jednym z głównych czynników, który sprawił że gra została wydana w takim stanie jakim każdy widział, czyli tragicznym. A dokładnie konflikt zespołu na linii tego, czym gra powinna być – RPG-iem w stylu Deus Exa, czy olbrzymią piaskownicą na modłę GTA V. Dlatego też ogromna ilość mechanik, czy obiecywanych zawartości została wywalona do kosza i po kilku latach od rozpoczęcia prac CDP Red musiało „zresetować” swoje dziecko i postawić na jeden właściwy dla nich i dla nas koncept. To jest również idealny przykład na to jak pewne pomysły mogą przerosnąć możliwości programistyczne. Kontynuując wątek, niewielu ludzi zdaje sobie sprawę z tego, że sporo czasu antenowego podczas powstawania gry wideo zajmuje sam marketing. Najlepiej to widać na przykładzie Rockstar i Grand Theft Auto V. Okres dewelopingu wypadał między 2008-2011, a premiera miała miejsce we wrześniu 2013 r. Na podstawie tych informacji można wywnioskować, że koniec cyklu rozwojowego po prostu nie przekłada się na datę premiery, ponieważ Rockstar spędził w tym przypadku niecałe 2 lata na obwieszanie plakatów w Time Square w Nowym Jorku i na przystankach, przygotowując produkt do premierowego postawienia na półce sklepowej.

Co mają zarobki ludzi tworzących gry do artykułu „O tworzeniu gier i sztuczkach używanych w kodzie”? Nie wiem, ale stwierdziłem że mogę sobie pozwolić na taką odskocznię. Od jakiegoś czasu na Twitterze sporym zainteresowaniem cieszy się hasztag #GameDevPaidMe pod postem, przy którym pracownicy z branży gamingowej chwalą (albo żalą) się zarobkami. Inicjatywa ma na celu pokazanie różnicy w zarobkach między różnymi krajami. Problem w takich porównaniach leży po stronie różnych dochodów oraz kosztów życia w danym kraju. Co z tego, że w Kanadzie ktoś zarobi dwa razy więcej jak piwo kosztuje 20 zł, a zostawienie dziecka w przedszkolu to koszt w granicach 3.000 zł. Z drugiej strony utrzymanie Amerykańskiego studia w centrum miasta to horrendalne koszty, którymi można się zasłaniać podczas wypłacania pieniędzy biednym testerom, czy dźwiękowcom nagrywającym odgłosy spuszczonej wody toaletowej służącymi w grze jako szum wodospadu. Cokolwiek, temat robi się dość gorący, na czele z pracownikami branży zaczynający zauważać pewne dysproporcje, z których nie do końca mogą być zadowoleni. Czas na garść liczb, a z racji tego, że w Polsce bardziej miarodajne są zarobki miesięczne niż roczne, przeliczyłem to za Was. Asystent programisty w Blizzard (19.000 zł), programista (24.200 zł). Artysta koncepcyjny w firmie Troika (16.000 zł), a w Obsidian (26.200 zł). Okej, lecimy dalej z największymi, może na początek francuski Ubisoft. Junior Designer (13.200 zł), Designer (19.700 zł) Senior Designer (27.200 zł). Te dane zostały przekazane przez Philippe Gregoire (Senior Game Designer) byłego pracownika Ubisoft Montreal z takim oto zdaniem poprzedzającym cyt. „Nie czekaj, aż pracodawca da ci podwyżkę, na którą zasługujesz, bądź otwarty na rozmowy z innymi firmami, nawet jeśli czujesz, że jesteś w „świetnym” miejscu.”. Była główna ilustratorka pracująca 10 lat w Rockstar Games, Roxie Vizcarra przyznała się, że w 2013 podczas produkcji GTA V zarabiała 28.000 zł, a w 2017 r. już 41.000 zł. Inne specjalizacje i studia? Bardzo proszę. Character Artist w Creative Assembly to zarobek ok. 10.000 zł. Lead Engine Programmer w Insomniac Games to 54.000. zł. Game designer w Naughty Dog – 31.200 zł. Contract Technical Designer w Sony Santa Monica trochę powyżej 30.000 zł. Polacy nie chwalą się, bo i pewnie nie ma czym. Pod hasztagiem GameDevPaidMe obecny projektant leveli w Flying Wild Hog, Marek Adamski, napisał po prostu: „Pracę w branży zaczynałem z umową na 2k zł (netto, umowa mieszana). Po 1,5 roku, gdy odchodziłem z tamtej firmy, na umowie miałem 4,5k zł”. Znów Michał Azarewicz, PR & Marketing Manager pod koniec 2019 r. (piszę o roku ponieważ teraz może być inaczej) porównał płace niektórych stanowisk w Warszawie. I tak: programista junior to granice 4-5 tysięcy złotych netto, programista senior to 8-10 tys., a graficy około 7 do 10 tys. Jak widać różnica między naszymi a zagranicznymi zarobkami jest kolosalna i nie potrzeba nam więcej danych, resztę zostawiam dla Waszej interpretacji, czy to dużo, czy mało?

Powyżej przedstawione informacje o zarobkach ludzi tworzących gry dotarły do szerszej publiczności, więc nie są już „korporacyjnymi tajemnicami”. Przyjrzyjmy się zatem innym ciekawostkom, zawartym m.in. w książce Krew, pot i piksele autorstwa Jasona Schreiera – popularnego dziennikarza zajmującego się grami. Serwis Metacritic każdy (nie)szanujący się gracz zapewne zna. Jest to strona internetowa wyciągająca średnią z sieciowych ocen, gdzie dzieją się różne rzeczy często nagłaśniane przez media. To jak niebagatelny wpływ na wynagrodzenie pracowników ma zwykła cyfra pokazał przykład studia Obsidian tworzącego Fallout: New Vegas. Wydawca, czyli Bethesda zaoferował producentowi milionową premię, jeśli tytuł ten osiągnie notę przynajmniej 85 na wspomnianym Metacritic. Kiedy zaczęły pojawiać się recenzje, z wiadomych przyczyn ocena zaczęła spadać i podnosić się. W ostateczności stanęło na… 84. Możecie sobie wyobrazić w jakim samopoczuciu byli wtedy pracownicy. Podobne wrażenia zbierają osoby, które zostają po godzinach kiedy należy „doszlifować” końcowy produkt – krótko mówiąc tzw. crunch. Oczywiście jest tak, że wszystkie studia siedzą po godzinach mniej lub więcej czasu, lecz niewiele z nich ma takie jazdy po bandzie, jak Naughty Dog. Jednym z motywów wpisujących się w serię Uncharted jest moment, kiedy Nathan Drake skacze na skałę lub dach, a ten zarywa się w ostatniej chwili. Podobną drogę musieli przejść pracownicy Niegrzecznego
Psiaka podczas wyczerpującego crunchu Uncharted 4. Ludzie pracowali po 60 godzin w tygodniu, niektórzy zostawali do drugiej nad ranem w dni powszednie tylko po to, aby nie pracować w weekendy. Jedni zostawali dłużej skupiając się na detalach – a nie na całości, drudzy ryzykowali zdrowiem i przybierali na wadze siedem kilogramów (w końcu przy zerowej aktywności tłuszcz szybko się zbiera). Jak bardzo niezdrowy był to moment tłumaczy projektantka gry, Emilia Schatz. – Im bliżej terminu byliśmy, tym wyraźniej dało się wychwycić w korytarzu spojrzenia mówiące: „Nie mam pojęcia, jak damy radę wszystko dokończyć. Przecież to niemożliwe”.
Tak samo niemożliwy był wyczyn Erica Barone’a i cierpliwość jego dziewczyny Amber Hageman. Kiedy odkryli, że oboje uwielbiają Harvest Moon: Back to the nature na PlayStation, Eric postanowił samodzielnie stworzyć współczesną wersję omawianej gry, a Amber wspierała go pomimo odwiecznych problemów życia codziennego; w końcu Barone siedział nad grą, a ona zarabiała na jedzenie, czynsz i inne wydatki. Jak mówiła: „pracował tyle, że nie mogłam się na niego złościć” (kobiety bierzcie z niej przykład, hłe hłe). Aby stworzyć klona HM samozwańczy introwertyk, używając zestawu prostych narzędzi Microsoft XNA i programu do produkcji dźwięku Reason, napisał każdą linijkę dialogu, narysował wszystkie projekty, animował postacie i samodzielnie skomponował muzykę przez okres 4,5 roku. Były to dla Erica ciężkie lata wyrzeczeń, wiecznie kasowanych mechanik, rysowania po 15 razy tego samego sprite’a, czy wyrzucania do kosza tygodniowej pracy. Tak narodził się Stardew Valley, świetnie oceniany tytuł i godny następca chłopca od dojenia krów, czyli Harvest Moon. Wystarczył zapał, szczypta talentu, Steam Greenlight, tysiące spędzonych godzin przed komputerem i trochę szczęścia, aby zarobić na swoim dziele krocie. Ile dokładnie? Około 135 milionów złotych. Od zera do milionera.

samodzielny twórca Stardew Valley, Eric Barone


Kolejnym tematem wziętym na tapet jest sztuczna inteligencja w grach. Ile to już było narzekań na ten element rozgrywki. Wrogowie wpadający nam pod lufę karabinu, samochody jadące jak po sznurku, wartownicy spokojnie spacerujący wyznaczoną trasą. Czy rzeczywiście tak trudno zaprojektować AI, aby było mądre? I dlaczego inteligencja żołnierzy w F.E.A.R jest tak znakomita, ponadczasowa?  Przede wszystkim należy uświadomić sobie jedną bardzo ważną rzecz i nie będzie to wykład w stylu „a czym właściwie jest ta sztuczna inteligencja i jaka jest jego historia, bla, bla, bla”. W przeciwieństwie do tworzonej akademicko AI, w grach nie chodzi o to, aby stworzyć najdoskonalszą sztuczną inteligencję, ale o dobranie najlepszego wrażenia inteligentnego zachowania programu u osoby wchodzącej z nim w interakcję. To swego rodzaju test Turinga, czyli pewien sposób określania zdolności maszyny do posługiwania się językiem naturalnym i pośrednio mającym dowodzić opanowania przez nią umiejętności rozumowania w sposób podobny do naszego. Dlatego też chodzi o dobre wrażenie, niekoniecznie uber inteligentne i błyskotliwe, lecz sprawiające iluzję AI wymagającej, dostosowującej się do poczynań gracza, a niekiedy oszukującej, czy sprytnie kamuflującej pewne braki. Algorytmy sztucznej inteligencji są tworzone w taki sposób, aby dostosowywały się do poziomu umiejętności gracza. W Resident Evil 4 inteligencja wrogów spada, gdy pokonają gracza parę razy z rzędu, a w serii Mario Kart prawdopodobieństwo pojawienia się power-upów w pudełkach zmienia się w zależności od aktualnej pozycji w wyścigu. Znów w większości wyścigów jest rubber banding (hi Forza Motorsport i Need for Speed), czyli dynamiczne dostosowanie prędkości przeciwników do poczynań gracza. Dlatego też trudnością w programowaniu sztucznej inteligencji nie jest samo podporządkowanie algorytmów (ogólnych reguł bądź gotowych recept rozwiązywania określonego rodzaju problemów), które mówiąc dosadniej „dosrałyby” graczowi, ale znalezienie złotego środka między satysfakcjonującą rozgrywką, a sprawiedliwym wyzwaniem – nawet jeśli to miałby być poziom trudności „Normal”. Jak wiadomo z tym ostatnim jest różnie – dawniej bywała przeprawą przez mękę, a dziś raczej jest spacerkiem po polanie pełnej trupów. Tak samo jak konstruowanie AI, tworzenie algorytmów regulujących skupiska obiektów, procedury sterowania ruchem, podejmowanie ważnych decyzji, wchodzenie w nawet najmniejsze interakcje, budowanie szeroko pojętej strategii, czy tzw. sztuczne życie (Artificial life) – interdyscyplinarny kierunek badań, zorientowany na zrozumienie i wykorzystanie istoty życia.    

W większości współczesnych gier komputerowych wykorzystywanych jest kilka różnych algorytmów. Jest to najważniejsza rzecz, która definiuje poprawnie działające AI u przeciwników oraz NPC. Przychylę się do omówienia najważniejszych z nich, opisując wszystko w jak najłatwiejszym do zrozumienia języku, omijając szerokim łukiem pseudo naukowy bełkot. Najsłynniejszym i w sumie najważniejszym z punktu widzenia gracza lubującego się w FPS-ach, czy rozbudowanych RPG-ach jest model o nazwie automat stanów skończonych (ang. Finite-State Machine – FSM). Zasada działania jest w zasadzie prosta. Zachowania obiektów (drzwi, żołnierzy itd.), które mają być sterowane, są poszatkowane na drobniejsze fragmenty, mające jakiś zdefiniowany stan oraz warunki zmiany tego stanu lub przejścia do kolejnego w zależności od sytuacji skupiającej się gdzieś w tle, wokół nas. W grach z wirtualnymi przeciwnikami takimi stanami są pewne akcje wykonywane przez np. żołnierzy, typu: reakcja na pojawienie się gracza, patrolowanie terenu itd. Jednak aby przejście od stanu do stanu miało jakikolwiek sens, muszą być spełnione zdefiniowane i zależne od siebie warunki. Masę warunków. W grach nastawionych na skradanie przeciwnik może zauważyć otwarte drzwi, które były wcześniej zamknięte, i jest to pierwszy z takich warunków. A co jeśli twórca chce dodawać w nieskończoność kolejne zależności, dążąc do perfekcjonizmu na linii doskonałego AI? Mamy wtedy długi sznur z pętelkami, gdzie każda kolejna dokłada i winduje poziom trudności na wyższy pułap. Czyli strażnicy oprócz zmiany położenia wspomnianych drzwi, reagują również na zgaszone światło, hałas, ruch za szybą, czy mokre ślady zostawione przez antagonistę podczas obfitej ulewy (kłania się Metal Gear Solid 2). Jednak co nam po świetnym AI jeżeli ten po zauważeniu rozbitej szyby, nie wchodzi do wnętrza budynku, a jedynie zatrzymuje się w miejscu wpatrując się jak sroka w gnat. Mowa tu o Pathfindingu, czyli algorytmie wyszukiwania najbardziej optymalnej drogi obiektu od punktu A do punktu B. Najpopularniejszym jest A* (A Star), który wyróżnia się od innych podobnych do siebie algorytmów tym, że… jest kompletny i za wszelką cenę znajduje ścieżkę między punktami jeśli jest ona tylko możliwa. Dokładnie rzecz ujmując świetnie wykorzystuje heurystykę, kiedy to żaden inny algorytm, nie znajdzie bardziej optymalnej drogi, przy testowaniu mniejszej liczby węzłów niż omawiany A*. Maksymalizując dokładane warunki w FMS, i łącząc je z szeroko wykorzystywanym algorytmem do wyszukiwania ścieżek A Star otrzymamy prawdopodobnie najlepszą AI w grze wideo jaka powstała. Mowa oczywiście o F.E.A.R, i o oponentach zachodzących gracza od różnych stron, przeskakiwaniu przez przeszkody, sprytnym wychylaniu się zza winkla, atakowaniu naszej osoby podczas usłyszenia zmieniającego się magazynku w broni oraz inteligencji licznych szczurów, które spowalniały samą rozgrywkę.

AI żołnierzy w F.E.A.R opierający się na A star i FSM (ang. Finite-State Machine)


Pomówmy o certyfikacji gier, jako procesie testowania skończonej gry przed wydaniem na półki sklepowe tudzież platformy dystrybucji cyfrowej np. Steam. Certyfikacja to nic innego jak sprawdzenie określonych warunków, które każda gra musi spełnić, jeżeli chce być wydana na świat. W tym celu powoływany jest przez producenta konsol, bądź platformę do dystrybucji gier specjalny zespół zewnętrzny. Chociaż najczęściej jest to sam producent gier, który chce wziąć wszystko we własne ręce. Jednak zanim zespół certyfikujący położy swoje wścibskie łapska na dostarczonym buildzie gry, studio musi odpowiednio przygotować swój produkt, i jest to w sumie najbardziej czasochłonny proces. Kiedy firma/producent odpowiedzialny za nadanie certyfikatu otrzyma odpowiednio przygotowany kod zaczyna najpierw sprawdzać czy wersja gry oraz przesłane materiały spełniają wytyczne dla danej platformy. I wbrew pozorom to nie jest kwestia typu „czy gra działa płynnie”, a „musi po prostu działać”. W międzyczasie są sprawdzane takie „duperele” jak jakość grafiki w Full HD obrazka w osiągnięciu na PlayStation, funkcjonalność żyroskopu, poprawność wersji językowych, przenoszenie save’ów, poprawne wyświetlanie GUI, czy określenie sposobu obsługi Joy-Conów w grach Nintendo. Certyfikowana jest również zniżka premierowa, funkcje sieciowe, oficjalna strona produktu w sklepie, trailer, czy data premiery. Po zatwierdzeniu tego etapu zespół certyfikacyjny przechodzi do tak zwanej fazy testowej, podczas której zgłasza wszystkie napotkane nieprawidłowości. Jeżeli firma nie natrafiła na żadne problemy z „checklisty” daje pozytywny sygnał. Co się stanie jeżeli gra nie przejdzie testów? Można ją ponownie wysłać aż do skutku, chociaż przyjmuje się maksymalnie 2-3 testy, które jednak trochę trwają – a jak wiadomo dotrzymanie daty premiery dla wydawcy to rzecz święta (chociaż jak widać, nie w tych czasach). Każda platforma ma trochę inny sposób certyfikowania, a czas przekazania tytułu do certyfikacji przed premierą  nie powinna wynosić dłużej niż 1,5 miesiąca. Od jakiegoś czasu można skorzystać z systemu Rapid Patching, który pozwala na zaktualizowanie gry w ciągu kilku godzin po premierze, pod warunkiem, że nie będzie niczego, co wymagałoby nowej przepustki certyfikacyjnej. Zastanawiającym faktem jest zatem premierowy stan Cyberpunka 2077, czy RiMS Racing działający w 12 klatkach na sekundę. Po pierwsze: proces certyfikacji obejmuje rzeczy zawarte w spisie wytycznych, czyli powracamy do „gra musi działać” – nawet jeśli motocykl płynie nad asfaltem 20 centymetrów w powietrzu, a przechodnie rozkładają ręce tworząc popularną sylwetkę T. Najwięksi muszą przejść, bo są największymi i to oni rozdają karty pod obietnicą Day One Patcha, który skończy swoją krucjatę po kilku miesiącach, albo i latach. W końcu ze „spowiedzi” kierownictwa CD Projekt Red przed inwestorami, ci pierwsi wytłumaczyli się z tragicznego działania Cyberpunk 2077 na past genach. – Możemy jedynie się domyślać, że producenci konsol zaufali nam że naprawimy problemy do czasu premiery gry i, co oczywiste, nie poszło to po naszej myśli. Z drugiej strony… nie ma gry perfekcyjnie działającej i zespół certyfikujący musi przymknąć oko na błąd wywalający za 20, 50, 100 uruchomieniem gry, czy wykonaną akcją. No ale nie brońmy partactwa, za które płacimy ciężko zarobionymi pieniędzmi.

Na deser zostawiłem obiecane sztuczki deweloperów przy tworzeniu gier. Będzie ich cała masa, więc proszę mi wybaczyć niechlujność przy składaniu tekstu, ponieważ ciężko jest połączyć ze sobą tak różniące się od siebie tematy. Lustra w grach to odwieczny temat tabu rodzący się w głowach dociekliwych graczy, którzy zastanawiają się dlaczego odbicie jest zniekształcone, postać to obiekt low poly, nie wspominając o starych tytułach, kiedy sterowanego przez nas protagonisty nie było po prostu widać. Dodatkowo często deweloperzy unikają odbić w lustrze zasłaniając się… pękniętym lustrem lub jego brakiem. A przecież w większości ten efekt jest niczym więcej jak drugą kamerą, której obraz jest nakładany na ścianę przed nami, pamiętając o efekcie Fresnela – opisującego zależność odbicia światła od kąta padania i długości fali. Określający stosunek energii światła odbitego do energii światła padającego. To nie jest tak, że efekt ten był ciężki do uzyskania, chodziło o to, że potrafiły przeciążać silnik. Tym sposobem doszedłem do kilku ciekawostek z Silent Hill. Kto pamięta początkową scenę w miejskiej ubikacji i patrzącego się w lustro Jamesa Sunderlanda, ten nie zdawał sobie sprawy, że jego odbicie to w zasadzie skopiowanie zarówno sylwetki, jak i pomieszczenia, które znajdowało się po drugiej stronie obiektu. Taka sama sztuczka była użyta w Silent Hill 3 i pamiętnym żyjącym odbiciu lustrzanym, z tą różnicą, że efekty w drugiej „kopii” tekstur różniły w zależności od postępu i długości w jakim przebywaliśmy w przeklętym pokoju.

Silent Hill 2 i sztuczka programistyczna z odbiciem lustrzanym. Kto pamięta lustro w trójce?


Okej, zostawmy w spokoju te nieszczęsne lustra, a przyjrzyjmy się innym sztuczkom zastosowanym w Cichym Wzgórzu. Jedna z zagadek znajdująca się w katakumbach w Silent Hill 2 polegała na przesuwaniu różnych twarzy na kamiennej kości, która to z kolei zmieniała układ drzwi w kolejnym pokoju w kształcie sześcianu. To czego nie możemy dostrzec jest zaskakujące, bowiem ściany pomieszczenia przemieszczają się w czasie rzeczywistym w tym samym momencie, kiedy kręcimy kostką.  Z innych ciekawostek warto zaznaczyć, że w Silent Hill: Shattered Memories po każdym zgonie gracza, SI potworów była zmieniana, a kiedy zaczęły nas gonić i oglądaliśmy się za siebie, specjalnie zwalniały by wywierać na graczu presję ciągłego pościgu. Chyba każdy szanujący się gracz kojarzy trik z portalami, które zastosowane były w Portal, czy Prey. Tutaj duplikowanie pomieszczeń, które sprawdziły się we wspomnianych lustrach, byłoby zbędne z racji tego, że chodzi głównie o przemieszczanie przedmiotu, a nie jego odbicia. Magiczne portale to nic innego jak przeniesienie się w inny punkt tej samej lokacji, manipulacja ruchem gracza i obliczanie procesów, które odbywają się zarówno przy wejściu do portalu i jego wyjściu (odległość, korekcja kamery, prędkość itd.). Jednak swego czasu deweloperzy z Valve skomentowali, że przy początkowych przymiarkach przejście między portalami trwało prawie pół sekundy co było słabym wynikiem (dokładnie precyzując: rozgrywka przez to nie była płynna). Spowodowane było to przez różne obliczenia bezpośrednio działające w samym procesie tworzenia portali i przenikających przez niego przedmiotów. Sprytnym rozwiązaniem było stworzenie zamkniętych obszarów, które upraszczały owe obliczenia w stosunku do reszty otoczenia. Z portalami wiele wspólnego miał Duke Nukem 3D wydany w 1996 r. Spytacie się, ale jak to? Z racji tego, że gra była tak na prawdę 2D trzeba było zamaskować ten fakt – dlatego też każde przejście przez schody, okno, czy podróż windą na inne piętro były efektem… przeniesienia się w oddzielne pomieszczenie za pomocą niewidzialnych portali, a nie (jak się wydawało) spacerkiem przez lokacje z kondygnacjami położonymi na różnych wysokościach. Połączeniem tematyki luster i portali jest pewna sztuczka użyta w Half-Life 2 i większości gier, które mogą odtwarzać podobne sekwencje. Mowa o hologramach, wielkich ekranach na których postać wypowiada swój monolog. W rzeczywistości twórcy musieli stworzyć osobne pomieszczenie, usadowić takiego delikwenta, który streamował samego siebie, a obraz przekazywany był czy to w telewizorach, czy na hologramach. 

Kreatywność pewnych sztuczek nie kończy się na radzeniu sobie z efektami odbicia lustrzanego, czy tworzeniu portali. Gry z otwartym światem jak Fallout, czy Skyrim muszą sobie radzić z ogromem obiektów, które przecież pożerają ogromną ilość pamięci. Dlatego programiści tworzą pewne obejścia rodem z czasów NES-a kiedy to np. tekstura chmurki w Super Mario była skopiowana i pokolorowana na zielono, i służyła jako zwykły krzak. W open worldach pewne obiekty są wtapiane w tekstury podłoża imitując zupełnie inny przedmiot: stół może być górną częścią szafki, a krzaki to nic innego jak wierzchołek korony drzewa – w sensie, że cały model drzewa jest „zatopiony” w podłożu do pewnego momentu, a jego widoczną część widzi gracz w formie właśnie pospolitego krzaka. W Perfect Dark pewnie niektórzy zastanawiali się dlaczego wiatrak prądotwórczy jest wykrywany jako przeciwnik. Aby wprawić w ruch łopatki programiści połączyli je do obracającego się działka, tak, tego strzelającego nabojami. W drugiej odsłonie przygód Nathana Drake’a, kiedy musimy pokonywać przedziały w pędzącym pociągu bez względu na to jak szybko będziemy się poruszać to otoczenie zacznie się zmieniać bez przerwy. Okazuje się, że pociąg ten naprawdę jeździ po torze, ale w ogromnej pętli, więc po jakimś czasie zobaczymy takie same obrazki. Sztuczki polegają również na manipulacji wielkością przedmiotu. Robert Morrison, pracujący nad God of War (2018 r.) oznajmił, że w momencie, kiedy Kratos sięga po swój topór, narzędzie staje się większe. Deweloper sprecyzował, że różnica wielkości wynosi około 20 procent, a oręż trzymany na plecach bohatera musiał być mniejszy, ponieważ kamera znajduje się bliżej broni i Lewiatan zasłaniałby większość ekranu. To samo tyczyło się pewnej osoby w przerywniku filmowym z The Darkness. W nim protagonista rozmawiał z dziewczyną Jenny w jej pokoju, a kamera była ustawiona w taki sposób, że jej wzrost musiał się dynamicznie zmieniać, aby nie sprawiała wrażenia zbyt dużej. Są również sztuczki niejako oszukujące gracza, ale ten nie jest w stanie tego zauważyć gołym okiem. Swego czasu Ken Levine zdradził, że w premierowym Bioshocku, pierwszy strzał w naszą postać zawsze będzie niecelny, tylko po to, aby gracz mógł odpowiednio zareagować. Znów w Bioshocku Infinite, pomagająca nam Elizabeth nie znajduje przedmiotów, te są magicznym sposobem wrzucane przez grę do jej rąk, jeśli gracz ich potrzebuje. Innym przykładem szemranej pomocy jest stosowana w starszych platformówkach technika tzw. Kojota Williego. Chociaż można to zaobserwować również w niektórych FPS-ach. Jeżeli oglądaliście kreskówki Looney Tunes, to pewnie domyślacie się, jak ona działa (hłe, hłe). Gra tworzy nam niewidzialną półkę z której odbije się nasza postać zamiast spaść w przepaść, jeśli dochodzimy do krawędzi i naciśniemy przycisk skoku zbyt późno. Proste a skuteczne rozwiązanie, które mogło się przydać w serii Tomb Raider na PlayStation. Jak widzicie, wiele sztuczek deweloperskich polega na sprytnej manipulacji, schowaniem elementów w niewidocznych dla nas rejonach stworzonych z oteksturowanego, zamkniętego pudełka.   

Binary Space Partitioning w Doom. Pomieszczenia wyświetlają się tylko wtedy, kiedy znajdują się w promieniu wzroku 


Na zakończenie artykułu postanowiłem omówić pewne techniki, które w zamierzeniu doskonale udają coś, czym nie są. Może to się okazać wielkim zaskoczeniem, ale takie gry jak wspomniany parę akapitów wcześniej Duke Nukem 3D, a także m.in. Wolfenstein 3D oraz Doom, udawały gry w pełnym trójwymiarze, a w praktyce były najzwyczajniej w świecie tytułami 2D. Po pierwsze: ówczesne komputery klasy PC nie potrafiły generować środowiska 3D, po drugie: chwytliwe nazewnictwo sugerowało coś rewolucyjnego, dlatego często pierwsze gry z techniką renderowania „scen 3D” Ray Castingiem sztucznie podnosiło cyferkę przy literze D. Magia ray castingu polegała na wyprowadzeniu stożka promieni z oczu bohatera (coś na kształt odległości widzenia strażników na radarze np. Metal Gear Solid, czy Hitman), który to wykrywał zbliżający się płaski obiekt (ścianę). Znów, im obiekt był mniejszy, tym dawał złudzenie oddalonego, a im bliżej postać podchodziła do ściany, tym rozmiar automatycznie stawał się coraz większy. Lepiej maskował się Doom, który używał innego sposobu renderowania otoczenia o nazwie Binary Space Partitioning. Pozwalał on na znaczne uproszczenie procesu określania widoczności obiektów przez obserwatora, dzielił pomieszczenia na mniejsze sektory pojawiające się wtedy kiedy grający na nie spojrzał, a te „za naszymi plecami” były usuwane. (z podobnego systemu skorzystało Guerilla Games blisko 25 lat później, w Horizon Zero Dawn – dop. Venom). Dzięki temu można było stworzyć ogromne światy bez większego wpływu na płynność rozgrywki, z iluzją w postaci schodów (to pojedynczy sektor o różnej wysokości sufitu i podłogi), oraz przeciwników znajdujących się wyżej (śmieszne jest to, jak bohater celował na wprost, a zestrzeliwał wroga na balkonie).  Zupełnie odwrotnym przypadkiem do powyższego jest Shovel Knight. Ale to przecież jest gra 2D i co może być w tym zaskakującego? – zapytasz. Ano to, że twórcy z Yacht Club Games od początku używali silnika 3D do stworzenia produkcji, dlatego poszczególne sprite’y można dowolnie obracać w trójwymiarze, i tylko pod jednym kątem widzenia udają grę w dwóch wymiarach. Jak przyznają twórcy, po prostu łatwiej jest obecnie tworzyć gry 2D na silniku 3D, dają znacznie więcej możliwości bez specjalnych ograniczeń.

Ograniczenia zaś były w renderowaniu ogromnego terenu jaki był do udźwignięcia przez PlayStation 2 w produkcji Team Ico, Shadow of the Colossus (2005 r.). Zespół pokusił się o ciekawą sztuczkę polegającą na zamianie obiektów 3D, w 2D w zależności od tego, jak daleko protagonista znajdował się od nich. Jeżeli np. wieża znajdowała się 200 metrów dalej, używana była tekstura super low, a miarę przybliżania się do budynku podmieniana była na warstwę low res, aż w końcu na high res i pełną detali bryłę. Skoro jesteśmy przy SotC, prawdopodobnie najlepiej zaprojektowanej gry pod względem technicznym, grzechem byłoby nie wytłumaczyć fenomenu zachowania futra znajdującego się na kolosach. Futro  to zestaw 6-8 warstw wielokątów w 3 wersjach: białej, szarej i jeszcze jednej, ciemniejszej. Odpowiednio nakładane, zmieszane objętościowo i z nadanym kierunkiem, doskonale imitują poruszające się owłosienie. W przypadku objętości, programiści użyli różnej jasności tekstur i warstw, aby sfałszować głębię, znów przy przejściach między skórą a futrem zastosowali rozsiane kępki tekstur. Ponieważ liczba owych tekstur była ograniczona, twórcy zastosowali kilka sztuczek, aby uniknąć nudnych i powtarzających się wzorów na kolosach. Najpierw odwrócili niektóre obszary UV, dzięki czemu tekstura wyglądała jak lustro, a z pomocą pewnego sposobu byli w stanie wyznaczyć nowy kierunek dla sierści, podczas gdy tekstura była wciąż taka sama. Więcej informacji znajdziecie tutaj.


Uff, nie będę się silił na podsumowanie bo zapewne klawiatura mnie już nienawidzi. Jest 2 w nocy, na biurku czeka na umycie zaschnięty ślad po kubku od kawy, a ja mogę już zdjąć zapałki wetknięte między powieki i leniwie powłóczyć się do łóżka. Jeżeli dotrwaliście do końca, gratuluję i zapraszam do kolejnego artykułu, w niedalekiej przyszłości.

 

2 thoughts on “O tworzeniu gier i sztuczkach używanych w kodzie

  1. Dużo ciekawostek, jak i przydatnej wiedzy “pod ręką”, w jednym miejscu, czyli tak jak być powinno w dzisiejszym świecie. Jeżeli w następnym tekście będziesz kontynuował wątek AI, to nie zapomnij o Alien:Isolation!😉

  2. Świetny wpis tak jak i cała Twoja seria. Jednak ten temat najbardziej mnie zainteresował. O lustrach czytałem, tak jak o hologramach. Ale najciekawszy fragment dotyczy jednak certyfikowania. Zawsze mnie to zdumiewa, że kiedyś nie było łatek day one, narzędzia programistyczne były trudniejsze w obsłudze, a ograniczenia sprzętowa realnie nie pozwalały na realizacje pewnych pomysłów. I gry wydawano kompletne i grywalne, a teraz gdyby usunąć łatki to 90% gier jest zwyczajnie niedokończonym produktem.

    Wielkie dzięki za przybliżenie tego zagadnienia. Czekam na kolejne intrygujące materiały.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *