Informatycy kochają pisać programy. Chociaż nie – wyrażę się precyzyjniej. Programiści kochają tworzyć programy. Informatyka bowiem to jedna z tych dyscyplin nauki, czy też techniki, w której – podobnie jak w medycynie – postępuje proces daleko posuniętej specjalizacji.
I tak jak już od dawna nie udajemy się z naszymi rozlicznymi dolegliwościami po prostu do lekarza, lecz raczej do specjalisty – okulisty, gastrologa, kardiologa czy choćby seksuologa – tak też i nie każdy informatyk rozwiąże nasze problemy dotyczące komputerów. Specjalista baz danych, projektant serwisów internetowych, analityk data science, „sieciowiec”, można by długo wymieniać. Każdy z nich jest ekspertem jedynie w swojej wąskiej dziedzinie wiedzy. U wielu z nich zaś umiejętność programowania uległa – jako sztuka nieużywana – atrofii. Nawet zaś jeśli potrafią jeszcze napisać jakiś nietrywialny program, to szczerze tego nienawidzą i traktują jako zło konieczne.
Wśród wszystkich tych specjalizacji istnieje oczywiście także grupa elitarna – prawdziwych programistów, którzy żyją po to, by tworzyć kolejne linijki kodu źródłowego. Odżywiają się głównie pizzą i kawą (niektórzy co prawda przedkładają nad tę ostatnią colę, choć raczej w odmianie Jolt), zaś jakiekolwiek urządzenie wyposażone w mikroprocesor traktują jako wyzwanie do napisania przeznaczonego nań programu. Oczywiste jest zatem, że jedyną akceptowalną przez nich rozrywką są gry komputerowe. Klasyczna gra, która została stworzona z myślą o zwykłych śmiertelnikach takich jak my, będzie jednak dla nich zbyt nudna – nie da się przecież wykorzystać podczas zabawy umiejętności programowania! Dopiero takie tytuły, w których samo tworzenie kodu – czy też dokładniej budowanie algorytmu – stanowi meritum rozgrywki, mogą być dla nich odpowiednie. Ośmielę się je określić mianem „programistycznych” i zaznaczę przy tym, że prawdziwa taka gra powinna spełniać warunek kompletności Turinga (tak, tak, sprawdźcie w Wikipedii – albo przyjmijcie dla uproszczenia, iż chodzi o gry, które można by wykorzystać – przynajmniej teoretycznie – do stworzenia innych gier). Laser Squad, X-Com i Robo Sport się zatem nie kwalifikują…
Oczywiście tego rodzaju oprogramowanie rozrywkowe to nisza – a nawet nisza nisz, jest to bowiem podgatunek gier logicznych, które same nigdy nie były specjalnie popularne. Nawet jednak pomimo ich niewielkiej liczby da się wśród nich wyróżnić pewne rodzaje. Mamy tu zatem klasyczne łamigłówki – gdzie należy stworzyć algorytm, który rozwiąże postawione przed graczem zadanie (na przykład „odszyfrować kod” czy „znaleźć wyjście z labiryntu”). Równie ważna jest kategoria gier bitewnych, w których tworzymy cyfrowego wojownika i wyposażamy go w program (tak jest, w „sztuczną inteligencję”), który zawiadywać będzie jego poczynaniami tak, aby pokonał innych podobnych sobie wojowników. Wreszcie kategoria pewnie najciekawsza – ale też i najmniej liczna – gry hybrydowe, z pozoru klasyczne (przygodówki, RPG, FPS), w których gracz może – tworząc program komputerowy – bezpośrednio zmieniać mechanikę gry. Co więcej, na samym początku rozgrywki może nawet nie być oczywiste to, że programowanie będzie potrzebne do jej ukończenia – czy wręcz to, iż jest dla gracza dostępne.
Jako rzekłem, to nisza. Nie zdziwię się zatem, jeśli okaże się, że o tego rodzaju grach nigdy nie słyszeliście. Nie oznacza to jednak, że jest to pomysł nowy. Bynajmniej.
Pierwszy tytuł, który można by określić mianem gry programistycznej, pochodzi z czasów prehistorycznych. Już bowiem w 1961 roku Wiktor Wysocki z Bell Labs opublikował artykuł (naukowy, a jakże) traktujący o systemie DARWIN, który pozwalał programom, napisanym w języku maszynowym komputera IBM 7090 (słowo „maszyna cyfrowa” wydaje się tu pewnie bardziej na miejscu, jako że rzeczony komputer to typowy mainframe, zajmujący sporej wielkości pokój), na walkę o jego zasoby. Dokładniej zaś o pamięć operacyjną – celem graczy było stworzenie takiego programu-wojownika, który odnajdzie miejsce w pamięci, gdzie znajduje się kod przeciwnika, po to by go skasować i w tak stworzone puste miejsce replikować własne instrukcje.
DARWIN nie był popularny, bo i taki być nie mógł. Liczba osób, które miały dostęp do dużych maszyn IBM, była, delikatnie mówiąc, znikoma. Co gorsza, tworzenie walczących programów wymagało znajomości kodu maszynowego, co nie było wiedzą powszechną nawet wśród tych, którzy mieli szczęście używać tych komputerów. Pomysł uległ zatem na kilkanaście lat zapomnieniu, aż do 1984 roku, kiedy to panowie Dewdney i Jones zdecydowali się stworzyć poprawioną i przede wszystkim uproszczoną wersję DARWIN-a. Zamiast prawdziwego komputera walczącym programom oddano do dyspozycji wirtualne pole walki (ciągły i zapętlony obszar komórek pamięci) możliwe do implementacji w dowolnej maszynie, zaś ich kod gracze implementowali nie przy wykorzystaniu instrukcji rzeczywistego procesora, lecz w specjalnie zaprojektowanym języku Redcode – co prawda wciąż przypominającym asembler, niemniej jednak dużo łatwiejszym do opanowania. Całość nazwano Core War (czyli „wojna rdzeniowa”, choć w Polsce przyjęła się forma mnoga tej nazwy), co oczywiście wydaje się określeniem kompletnie idiotycznym do momentu, w którym nie przypomnimy sobie, iż aż do lat osiemdziesiątych najpopularniejszym rodzajem pamięci komputerowej była pamięć rdzeniowa, zbudowana z malutkich pierścieni (rdzeni właśnie) ferromagnetyka nanizanych misternie na pajęczynę drucików. Wojny rdzeniowe pozostałyby ciekawostką mało znaną poza środowiskiem akademickim, gdyby nie to, że Dewdney przejął po Douglasie Hofstadterze redagowanie słynnego działu rozrywek matematycznych w „Scientific American” i tamże tę grę opisał. Efekt był łatwy do przewidzenia – zaczęły powstawać rozliczne implementacje, pozwalające na rozgrywanie bitew Core War (w latach dziewięćdziesiątych jedną wydała krakowska firma Cordat), organizowano konkursy i turnieje (także w Polsce).
Szybko jednak pojawiły się też problemy. Po pierwsze, o ile samo pisanie kodu programów-wojowników jest jak najbardziej ciekawe, o tyle już obserwowanie ich potyczki – szczególnie przez osoby postronne, które nie przestudiowały uprzednio owego kodu – raczej nudne. Ot, na ekranie przesuwają się kropki w dwóch kolorach, pojawiając się w pozornie losowych miejscach, po czym jednego koloru zaczyna robić się coraz więcej i więcej, aż następuje koniec. Po drugie zaś, Redcode, pomimo iż łatwiejszy niż asembler, jest wciąż językiem trudnym w opanowaniu i interpretacji. Tworzenie bardziej zaawansowanych programów bardziej przypomina rozwiązywanie zagadek logicznych niż klasyczne programowanie. Tego zaś już tak bardzo programiści nie kochają. W efekcie dziś w Core War grają jedynie najbardziej zagorzali fanatycy…
Cóż było zatem robić – niezbędne było zmodyfikowanie koncepcji (walka sztuczno-inteligentnych wojowników) i powrót do korzeni (klasyczne programowanie – najlepiej w języku wysokiego poziomu). Łatwo zgadnąć, czym to się skończyło – tak, mam na myśli gry pozwalające wystawić na arenę walczące roboty. Pierwsza z nich stworzona została przez Silasa Warnera w 1981 roku (a zatem nawet wcześniej niż Core War – ale później niż DARWIN). Nazwana niezbyt oryginalnie RobotWar, przeznaczona była dla terminali systemu PLATO, którego posiadały bogatsze szkoły w Stanach Zjednoczonych – już wtedy próbowano przemycić treści rozrywkowe, udając, iż służą one wyłącznie celom edukacyjnym. Jako że do PLATO mało kto miał dostęp, Warner szybko stworzył wersję dla Apple’a II, która stała się najbardziej popularna. Rozgrywka była prosta – ale wciągająca. Do pięciu uzbrojonych robotów na arenie (obserwowanej z góry), każdy sterowany przez program w języku nieco podobnym do BASIC-a – oczywiście wzbogaconym o komendy służące do obsługi radaru (odnajdywanie przeciwników), broni (ich niszczenie) i oczywiście przemieszczania robota. Grywalność była zdecydowanie powyżej przeciętnej, zatem szybko zaczęły powstawać modyfikacje, pisane przez zwolenników (o przepraszam, wyznawców – mówimy wszak o programistach) innych języków programowania. Dziś bawić się walkami robotów mogą miłośnicy Pascala (P-Robots), C i C++ (CRobots), Javy (Robocode), a nawet o dziwo asemblera (AT-Robots), zresztą liczbę odmian tej gry trudno już zliczyć.
Za najbardziej chyba rozbudowaną jej inkarnację uznałbym Omegę – dzieło Stuarta Marksa, wydane przez (tak, tak) Origin w 1986 roku (są też wersje dla PC, Atari ST i Amigi, nieróżniące się zbytnio od siebie). W dalszym ciągu budujemy i programujemy tu autonomiczne maszyny wojenne – nie są to już jednak abstrakcyjne roboty. Tym razem stajemy się pracownikiem korporacji o groźnie brzmiącej nazwie Organization of Strategic Intelligence, zaś nasze kreacje to czołgi (o przepraszam, cybertanks). Całość opakowana jest w bardzo zgrabną otoczkę korporacyjnego systemu informatycznego, co razem z dokumentacją, jaką znajdujemy w pudełku, w którym gra była sprzedawana (różne dokumenty – na przykład „New Personnel Orientation Guide” i podręczniki opatrzone pieczęcią Top Secret), pozwalają się poczuć jak świeżo zatrudniony pracownik zbrojeniówki. To zresztą strategia typowa i dla późniejszych gier Origin – weźmy choćby Strike Commander i jego instrukcję obsługi udającą gazetę dla najemników. Poza powyższymi aspektami podstawowa różnica pomiędzy Omegą i RobotWar to świat, w którym nasze kreacje toczyć będą bitwy – mamy tu do czynienia z dość bogatym środowiskiem pełnym dróg, mostów, drzew i bunkrów (za którymi można się choćby schować), podczas gdy w tej drugiej arena jest pusta.
Pisząc o Omedze, nie sposób nie wspomnieć o Digital Warriors – polskiej grze o dość podobnej fabule (choć wydanej dużo później, bo dopiero w 1994 przez Xland), a której jednym z autorów jest znany czytelnikom Pixela Borys Zajączkowski. Szkoda tylko, że język programowania nie jest w niej bardziej rozbudowany (na to zresztą zżymał się Borek, recenzując tę grę w Top Secret) i przypomina bardziej asembler niż język wysokiego poziomu.
Walka i zniszczenie to rzeczy miłe sercu większości graczy – nie dla wszystkich są jednak akceptowalne. Nie oznacza to jednak, że programiści-pacyfiści nie znajdą nic dla siebie wśród gier programistycznych. Przeciwnie. Jak zaznaczyłem na wstępie, znamienitą część populacji tych gier stanowią różnego rodzaju łamigłówki. Jedna zaś z najstarszych to Robot Odyssey, w której musimy pomóc nieszczęśnikowi, który podczas snu został wciągnięty do podziemi miasta Robotropolis i z których musi się teraz wydostać. Pomagać mu w tym będzie zaś trzech przyjaznych mieszkańców tegoż miasta (oczywiście roboty). Nie są oni (one?) jednak zbyt rozgarnięte, a zatem musimy wyposażyć je w inteligencję. Ale tu czeka nas niespodzianka – nie będziemy tego dokonywać, pisząc program. Zamiast tego grzebać będziemy we wnętrznościach robotów, łącząc przewodami i bramkami logicznymi ich czujniki i silniki. To też rodzaj programowania, a co więcej, jest łatwiejsze do zrozumienia dla osób, które nigdy informatyką się nie parały (i na dodatek uczy logiki matematycznej i elementów elektroniki). Nic zatem dziwnego, że wydawcą Robot Odyssey była The Learning Company, znana z wielu innych programów edukacyjnych, w szczególności dla małych dzieci. Zresztą – jeśli jesteśmy rodzicami właśnie małego dziecka, to Robot Odyssey (i jej wersjom – Rocky’s Boots i Gertrude’s Secrets) powinniśmy się przyjrzeć – co od niedawna jest nietrudne dzięki projektowi Robot Odyssey Rewired, który pozwala zagrać bezpośrednio w przeglądarce internetowej.
Powyższe nie znaczy oczywiście, że tego paradygmatu (to jest łączenia elementów drucikami) nie da się wykorzystać i w mniej niewinnych grach, w tym w szczególności tych bitewnych. Najlepszy przykład to dość już nowoczesny (bo pochodząca z 2000 roku) MindRover, gdzie w taki właśnie sposób projektujemy walczące roboty (dodatkowo, poza samą „inteligencją” mamy także wpływ na ich wygląd i parametry techniczne) – zaś wybuchów i dymu jest tu aż nadto. Gra się świetnie, ale niestety do całości dorobiono wątpliwej jakości historyjkę science-fiction (podtytuł gry to „The Europa Project” i bynajmniej nie chodzi tu o kontynent na naszej planecie) i promowano jako program – a jakże – edukacyjny. Prawdę mówiąc, wydaje mi się, że to właśnie zadecydowało o tym, iż sukcesem komercyjnym MindRover nigdy się nie stał, zaś o wydawcy – malutkiej, praktycznie jednoosobowej firmie Kenta Quirka CogniToy – nikt już dziś nie pamięta.
Czemu tak uważam? Cóż, zaryzykuję stwierdzenie, iż dopiero po nabraniu pewnej biegłości w rzemiośle programowania można osiągnąć prawdziwą satysfakcję z zabawy z tego rodzaju grami. A mimo to edukacja (kiedyś sama nauka programowania, dziś zaś słynne STEM – czyli Science Technology Engineering and Mathematics) używana jest niemal do znudzenia jako temat przewodni wielu gier tego gatunku, które mogłyby być znacznie lepsze, gdyby ich twórcy po prostu skupili się na samej frajdzie, jaką mogą osiągnąć gracze. Mimo to i tak lista znamienitych (czyli takich, w które warto zagrać) tytułów z pozoru edukacyjnych nie jest taka krótka. Znajdzie się na niej choćby stareńkie (bo z 1984 roku) ChipWits – w którym zastosowano wizualny – oparty na ikonach ustawianych na kwadratowej siatce – język programowania do sterowania robocikiem zwiedzającym mniej lub bardziej bezpieczne labirynty. Język zresztą bardzo zgrabny, który później (od 1995 roku) wykorzystali Japończycy z Artdink, aby stworzyć serię gier programistycznych Carnage Heart. Artdink w Europie znana jest przede wszystkim z genialnej strategii ekonomicznej A-Train, ale na koncie ma bardzo wiele innych porządnych gier – z czego miłośnicy tych programistycznych powinni szczególnie spojrzeć też na HR2 – perełkę, symulator budowy wysokościowca, w którym koparki i inne maszyny budowlane należy… zaprogramować. Wróćmy jednak do Carnage Heart. Tu już nie ma mowy o pokojowej eksploracji ani budowaniu czegokolwiek, tu programujemy maszyny bojowe (dokładniej mechy, nazwane tu pięknie Overkill Engines), których jedynym celem jest eksterminacja przeciwnika…
Ach, no tak, znowu okazuje się, że opowieść o grach logicznych i edukacji doprowadziła nas na pole bitwy – tak często bywa i w rzeczywistości. Dlatego też na szczególną pochwałę zasługuje podejście Bartha Zacha (tego od Infiniminer i SpaceChem), który swoimi grami programistycznymi nikogo nie usiłuje czegokolwiek nauczyć. Zamiast tego dostajemy skomplikowane łamigłówki, stawiające nas w roli pracownika korporacji produkującej sprzęt elektroniczny (Shenzen I/O), informatyka rozgryzającego tajemniczy sprzęt komputerowy (TIS-100) czy wreszcie hakera przyjmującego zlecenia włamania się do kolejnych systemów, aby otrzymać tak potrzebną mu „działkę” (Exapunks). Wszystkie te gry mają jedno ze sobą wspólnego – jeśli programowanie was nudzi albo jest dla was zbyt trudne, nawet nie czytajcie ich opisów. Ale jeśli to rzemiosło was interesuje – cóż, każda z produkcji Zachtronics to kilka tygodni wyrwanych z życiorysu.
Na koniec kilka jedynie (Pixel nie jest bowiem z kauczuku) słów o ostatniej kategorii gier programistycznych. Takich, w których programowanie wydawać się może jedynie nieistotnym dodatkiem do głównej mechaniki gry. Gdy rzeczywiście jest niezbyt potrzebne, to stanowi swego rodzaju przyprawę – jak choćby we francuskich grach z serii B.A.T. (Bureau of Astral Troubleshooters), które są zwykłymi (no, upraszczam) przygodówkami, ale w których możemy dowolnie modyfikować działanie wszczepionego w nasze przedramię komputera (aby ostrzegał nas przed chorobami, tłumaczył język czy też choćby działał jako prosty zegarek).
Czasem jednak programowanie okazuje się niezbędne, choć jego wplecenie w fabułę i mechanikę gry nie jest proste. Często się nie udaje – jak w CodeSpells, grze FPS, w której programowaniem, w języku podobnym do JavaScript, mieliśmy tworzyć czary, umożliwiające między innymi modyfikację terenu i walkę z przeciwnikami, a która już od kilku lat pozostaje jedynie bardzo obiecującym demem technologicznym. Czasem zaś powstaje małe arcydzieło, takie jak Else Heart.Break(). Z pozoru przygodówka TPP – do momentu, w którym znajdujemy terminal pozwalający na oglądanie i modyfikację kodu źródłowego sterującego elementami gry. To zaś otwiera przed graczem zaskakujące możliwości. Nasz bohater czuje się zmęczony? Zmieńmy kod sterujący właściwościami wody, tak aby wypicie tego płynu usuwało potrzebę snu. Nie znamy kombinacji otwierającej szyfrowy zamek do drzwi? Zajrzyjmy do jego kodu źródłowego – może znajdziemy tam odpowiednie wskazówki. Skojarzenia z wiadomym filmem braci Wachowskich? Ależ oczywiście!
Czas kończyć. Mam nadzieję, że udało mi się choćby zgrubnie zarysować krajobraz tajemniczej i mało znanej krainy gier programistycznych i zachęcić do jej odwiedzenia – choć ten krótki tekst to tylko rzut okiem na nią. Pominąłem wiele „obowiązkowych” tytułów (fani Colobot/CeeBot, nie obrażajcie się), nie wspomniałem o grach massive multiplayer (choćby Screeps), nic też nie napisałem o najnowszych tytułach, które pozwalają implementować graczom już nie tylko proste algorytmy, ale też prawdziwe mechanizmy uczenia maszynowego – na przykład while.True.learn(). Ale o nich może następnym razem?
Artykuł ukazał się w Pixelu #50, którego nakład został już wyczerpany. Zapraszamy jednak do sklepu Pixela po inne wydania drukowanego magazynu oraz po wersje cyfrowe Pixela.
