Silnik znaleziony w niszy [FELIETON]

Znakomita większość współcześnie powstających gier korzysta z któregoś z gotowych silników. W tygodniu, w którym piszę te słowa, na itch.io pojawiły się 143 nowe produkcje wykonane w Unity, 125 tytułów korzystających z Constructa, 84 projekty w Godocie, 46 w Twinie, 24 w Game Makerze, 21 w Bitsy, 29 w Unreal Enginie, 25 w RPG Makerze, 23 w Ren’Py i 11 w LÖVE (plus pojedyncze pozycje korzystające z innych rozwiązań).

Na tę sumaryczną statystykę składa się wiele elementów. Pierwszy to uniwersalność narzędzi: w Unity powstają zarówno gry 3D, jak i 2D, więc jego całkowita popularność to suma obu podzbiorów. Druga kwestia to jakość i wymagania sprzętowe: w Unreal Enginie najłatwiej stworzyć fotorealistyczny trójwymiarowy świat, ale technologia ta potrzebuje najmocniejszego sprzętu, zarówno w przypadku developera, jak i gracza. Dalej dochodzą inne czynniki, takie jak przystępność i elastyczność silnika, jakość i dostępność narzędzi pomocniczych, łatwość dotarcia do dokumentacji i zdobycia pomocy i w końcu popularność nisz, w których poszczególne engine’y operują. Ren’Py został zaprojektowany z myślą o visual novels i do ich produkcji jest głównie wykorzystywany. Nawet jeśli możliwość pisania skryptów w Pythonie znacząco go uelastycznia, nikt nie używa go w tytułach dowolnego typu – wspomniane wyżej 23 pozycje to głównie powieści z elementami graficznymi.

Dostępność silników wywołała rewolucję w branży. Nawet pomijając zupełnie pionierskie lata 80., jeszcze pod koniec zeszłego stulecia często łatwiej było opracować własny engine od zera, niż znaleźć i zastosować gotowy. To powodowało, że stworzenie gry wymagało znacznie większego udziału programistów i ich wpływ na efekt końcowy był znacznie wyraźniejszy. Czasem miało to katastrofalne następstwa dla jakości powstającego dzieła. Wystarczy porównać rozgrywkę i generowany obraz w Lands of Lore II i Quake’u – ten pierwszy tytuł wyszedł rok po shooterze id Software, a mógłby posłużyć jako podstawa wykładu o chorobach wieku dziecięcego wczesnych silników 3D.

Dostępność gotowych narzędzi diametralnie poprawiła się w pierwszym dziesięcioleciu XXI wieku, a wraz z jej wzrostem wkład programistów w kolejne gry malał, za to rosły zespoły odpowiedzialne za scenariusz i assety takie jak modele 2D, 3D, tekstury… To oczywiście nie znaczy, że koderzy przestali być potrzebni, ale coraz mniejsza ich liczba zajmuje się pracą przy samym silniku. Na opracowywanie własnych technologii od zera pozwalają sobie tylko najwięksi. Techland od lat tworzy gry, korzystając ze swojego Chrome Engine’u. CD Projekt Red przygotował na potrzeby Wiedźmina 2 REDengine – ale w zeszłym roku ogłosił, że przesiada się na Unreal Engine 5, z czym prawdopodobnie związane jest zwolnienie sporej części zespołu podczas wakacji.

Niekiedy na własne silniki decydują się także optymistycznie nastawieni entuzjaści, choć koszty tego bywają poważne. Zrobiłem kiedyś szybką kwerendę wśród polskich studiów indyczych na temat ilości pracy włożonej w ich gry. Okazało się, że Exor Studio potrzebowało do ukończenia X-Morph Defense 70 osobolat, ponad trzy razy więcej, niż Astronautom zajęło przygotowanie The Vanishing of Ethan Carter (18 osobolat). Skąd różnica? Gra The Astronauts powstała w Unreal Enginie, a Exor Studio postawiło na własny silnik. Miało to pewien sens, bo kod był zoptymalizowany pod kątem wyświetlania hordy identycznie wyglądających i stosujące te same algorytmy działania przeciwników, ale trzykrotnie więcej pracy to trzykrotnie wyższe koszty, czyli kilka dodatkowych milionów złotych. Poza szczególnymi przypadkami tworzenie własnych silników odpowiedzialnych za renderowanie świata, oświetlenie i fizykę jest nieopłacalne, więc dzisiaj programiści w małych studiach koncentrują się na implementowaniu specyficznych dla danego tytułu mechanizmów rozgrywki.

No właśnie: szczególne przypadki. Z przeprowadzonej w 2016 roku z moim udziałem dyskusji o „grze minimalnej”, wymagającej komputera, ale wykorzystującej wyłącznie ogólnodostępne programy, urodził się pomysł na Pendrive’a znalezionego w trawie – produkcję będącą rodzajem zagadki kryminalnej opartej na informatyce śledczej. Gracz dostawał do ręki fizycznego pendrive’a i na podstawie jego zawartości miał spróbować ustalić, co się stało z jego właścicielką.

Technicznie gra nie wymagała żadnego silnika. Potrzebny był komputer z systemem operacyjnym pozwalającym na obejrzenie plików i programy do ich otwarcia – edytor tekstu, jakiś archiwizator, coś do przeglądania zdjęć. Można było sięgnąć po dodatkowe środki – jakiś łamacz haseł czy aplikację do odzyskiwania usuniętych plików, ale wszystko to były narzędzia zewnętrzne. Czyli – gra komputerowa, ale bez osobnego, będącego „grą”, programu.

To nie znaczy, że podczas jej tworzenia obyło się bez programowania. Opracowanie zawartości pendrive’a wcale nie było trywialne, bo musiał wyglądać jak autentyczny, używany przez wiele lat nośnik z prawdziwą historią, dodawanymi i usuwanymi w różnych momentach i z różnych powodów plikami. Takie działania zazwyczaj zostawiają na dysku ślady, do których można dotrzeć – jeśli się wie jak. Zrobienie realistycznego pendrive’a wymagało więc wielokrotnego kopiowania i usuwania plików oraz przestawiania zegara systemowego, żeby widoczne czasy operacji układały się w spójną całość. Robienie tego ręcznie było możliwe (tak powstały pierwsze przymiarki), ale szybko okazało się, że efekty części działań są trudne do przewidzenia.

Nie dało się łatwo sprawdzić, ile plików dodać, żeby nadpisać usuniętą wcześniej zawartość(*), albo wprost przeciwnie – ile wolno dorzucić, żeby jakieś dane można było jeszcze odzyskać. Najprościej było posłużyć się metodą prób i błędów, tworząc kolejne wersje minimalnie modyfikowanym między iteracjami skryptem kopiującym, zmieniającym daty operacji itd. Pliki z danymi również wymagały ręcznych ingerencji, żeby zgadzały się wszystkie daty i metadane, co też najprościej było oskryptować. Powstał do tego celu cały zestaw narzędzi, które wprawdzie nie stanowiły żadnego „silnika” i w samej grze nie ma po nich śladu, ale i tak pochłonęły wiele godzin pracy czysto programistycznej.

Pendrive znaleziony w trawie

Potem pojawił się pomysł na wersję Steam – opartą nie na fizycznym nośniku podłączanym do portu USB, lecz na dysku wirtualnym. Tu już potrzebny był solidny kawałek kodu potrafiący skomunikować się ze Steamem, wyświetlić trailer i podłączyć dysk, ale znowu trudno było mówić o silniku jako takim.

(*) Kasowane dane nie są fizycznie wymazywane z dysku, wykreślana jest z niego tylko informacja o tym, w których klastrach ich szukać.

I pewnie tu by się moje przygody z silnikami skończyły (choć były w planach kolejne historie na pendrive’ach, do których wszystkie narzędzia miałem już z grubsza gotowe), gdyby nie gracze. Gracze, których bardzo uwierał brak interakcji i konieczność uruchamiania gry z uprawnieniami administratora (bez nich nie da się zainstalować dysku wirtualnego; kiedy podłącza się pendrive’a, też są one potrzebne, ale Windowsy cichcem „zjadają” ostrzeżenie). Pojawili się także ludzie, którym koncepcja Pendrive’a znalezionego w trawie bardzo się spodobała, i nominacja do Paszportu Polityki dla mnie, w której produkcja ta miała przecież niebagatelny udział.

Z jednej strony naszła mnie więc ochota, by spróbować zrobić kolejny tytuł oparty na informatyce śledczej, z drugiej zaś oczywiste było, że muszę wykonać go zupełnie inaczej. Woziłem się z problemem jakiś czas, aż w końcu przyszło olśnienie. Olśnienie oznaczające konieczność napisania własnego silnika.

Zasadniczą częścią zabawy musi być interakcja z prawdziwymi plikami, czyli trzeba dać je graczowi do ręki i skopiować na jego dysk, ale powinno to w jakiś logiczny sposób wynikać z konstrukcji gry. Postanowiłem więc uczynić odbiorcę pracującym zdalnie specjalistą, przyjmującym jednostkowe zlecenia typu „rozpakuj zabezpieczonego hasłem zipa”, „ustal nazwisko właściciela dokumentu” albo „zlokalizuj miejsce zrobienia zdjęcia”. Dzięki temu obecność plików i ich przekazywanie mają sens – zwłaszcza gdy do ich transferu korzysta się z „klienta” łączącego się z serwerem firmowym i służącego do wymiany informacji z innymi członkami zespołu. Dzisiaj takie rzeczy robi się raczej, korzystając z aplikacji przeglądarkowych, ale kilkanaście lat temu klient był zwykle specjalnie w tym celu napisanym programem uruchamianym na komputerze użytkownika (coś w stylu Lotus Notes).

I tak, żeby móc zrealizować opisaną wyżej ideę, musiałem napisać własny silnik, który można zobaczyć w akcji, grając w demo The Case of Andrew D. (jest na Steamie). Silnik udający klienta oraz symulujący wymianę informacji i interakcję z innymi ludźmi wchodzącymi w skład wirtualnej ekipy.

The Case of Andrew D. 

To w pewnym sensie krok w tył – cząstkowe zadania oznaczają, że gracz musi się poruszać zdefiniowaną przez scenariusz ścieżką i nie może drążyć sprawy po swojemu (Pendrive znaleziony w trawie dawał pod tym względem zupełnie wolną rękę). Niejako w zastępstwie odbiorca dostaje jednak możliwość interakcji z resztą zespołu (dość jednostronnej niestety) oraz dostęp do ujawnianych kolejno fragmentów historii odkrywanych w trakcie śledztwa. Okazuje się to kapitalnym narzędziem narracyjnym (a także sposobem na dopaminowe poklepywanie gracza po ramieniu: „Dobrze kombinujesz!”).

Ponadto doświadczenie zdobyte podczas pisania Pendrive’a bardzo się przydaje przy tworzeniu nowych śledztw. Oczywiście historie trzeba powymyślać na nowo oraz dopasować do innego sposobu przekazywania plików i ich analizy. Kluczowe dla powodzenia śledztwa będą metadane, stanowiące główne źródło informacji. Wiedza o tym, gdzie ich szukać, jak je rozumieć oraz jak są one generowane przez różne programy, nic a nic nie straciły ze swojej przydatności, podobnie jak przygotowane dla poprzedniej gry narzędzia do ich modyfikowania.

Wracając do zestawienia silników, od którego zacząłem: jestem w dość interesującym miejscu, bo dysponuję narzędziem od początku projektowanym tak, żeby edycja i tworzenie nowych śledztw były w miarę łatwe i by engine był wyłącznie interpreterem danych zapisanych w zewnętrznych plikach. Co więcej, żeby ułatwić pracę samemu sobie, jako część silnika stworzyłem edytor pozwalający na modyfikację śledztw i ich elementów. Do momentu, kiedy będzie go można upublicznić, jeszcze daleka droga (na razie efekty jego pracy regularnie wymagają ręcznego nanoszenia poprawek w opisującym śledztwa pliku XML), ale jest to jak najbardziej realne, więc jedną ze ścieżek, jakie rozważam, jest nie tylko wydanie gry, ale i wypuszczenie engine’u oraz próba zbudowania wokół niego środowiska zainteresowanych stworzoną niszą developerów. Nie mam wielkich złudzeń. Szanse na sukces komercyjny nie są wielkie, ale jest to jakiś potencjalny kierunek rozwoju.

No i w końcu wspomniany wcześniej mimochodem podział na silnik oraz assety i narzędzia do ich obróbki ma zastosowanie i tutaj. Mój engine jest uniwersalnym interpreterem odpowiedzialnym za wyświetlanie informacji i reagowanie – w sposób zdefiniowany w danych śledztwa – na akcje gracza. Informacje opisujące śledztwo, zarówno plik XML, jak i wszystkie pliki prezentowane graczowi, to assety. Na razie widoczna jest jedna różnica w stosunku do innych produkcji i silników: w moim przypadku nie ma osobnych członków zespołu zajmujących się technologią i assetami, wszystko spoczywa w rękach jednej osoby i opiera się na tych samych zwojach mózgowych.

Artykuł powstał we współpracy z Centrum Komiksu i Narracji Interaktywnej – łódzką instytucją, której celem jest popularyzacja powieści graficznych oraz gier wideo, a także edukacja przyszłych autorów tych mediów – seria doświadczeń i bogata baza wiedzy pozwolą graczom zostać twórcami, jedna ze ścieżek do gamedevu wiedzie zaś przez nurt indie.