Tworzenie gry Mazer – Rozdział 1: Ku przygodzie!

Tydzień temu opowiedziałem Ci o moich początkach z grami na konsolę i komputerowymi oraz jak przyczyniły się do tego, że zaczałem uczyć się programowania. Około dwadzieścia lat później znajomy polecił mi grę zatytułowaną „The Witness”. Wszedłem na Steam (platformę, na której można kupować gry), przeczytałem krótki opis i zainwestowałem – na początku kilkadziesiąt złotych na jej zakup, a potem kilkadziesiąt godzin na rozwiązywanie zagadek w tej wspaniałej grze. Przez następne dwa tygodnie moje wieczory mógłbym opisać w następujący sposób:

W „The Witness” gracz chodzi po tajemniczej wyspie i rozwiązuje zagadki, które wyglądają jak labirynty. Aby rozwiązać zagadkę nie wystarczy jedynie znaleźć trasę od wejścia do wyjścia, ale znaleźć taką drogę przez labirynt, która uwzględnia wszystkie zawarte w nim „elementy”.

Rodzajów tych elementów jest bardzo dużo, podobnie jak kształtów labiryntów oraz sposobów ich przechodzenia. Dzięki temu twórcy gry mogli zaoferować setki unikalnych zagadek do rozwiązania, które gracz znajduje zwiedzając malowniczą wyspę, na której budzi się na początku rozgrywki.

„The Witness” momentalnie mnie wciągnął i po rozwiązaniu każdej zagadki, gdy wiedziałem, że powinienem już iść spać, myślałem:

Jeszcze tylko jedna.

Bardzo polecam „The Witness” – oficjalny opis na Steamie można znaleźć tutaj:

https://store.steampowered.com/app/210970/The_Witness

Jak to działa?

„The Witness” na długo utkwił mi w pamięci. Często zastanawiałem się nad tym jak napisane są algorytmy odpowiedzialne za sprawdzanie rozwiązań zagadek i jakie struktury danych są używane do przechowywania labiryntów i wyznaczanych w nich ścieżek.

Na początku myślałem, że każda zagadka ma tylko jedno rozwiązanie – wtedy sprawdzanie poprawności jej rozwiązania byłoby bardzo proste – wystarczyłoby jedynie porównać drogę wyznaczoną w labiryncie przez gracza do tej jedynej poprawnej, zaprojektowanej przez twórców gry. Szybko stwierdziłem, że takie podejście nie ma sensu, ponieważ bardzo zawęziłoby to pulę zagadek, które można przygotować, ponieważ byłyby one projektowane tak, by dać się rozwiązać tylko w jeden określony sposób. To przeczucie potwierdziłem, gdy ponownie uruchomiłem grę i popatrzyłem na niektóre zagadki, które wyraźnie miały więcej niż jedno poprawne rozwiązanie.

Decyzja

Programując zawsze najwięcej przyjemności czerpałem z projektowania algorytmów i rozwiązywania nietrywialnych problemów. Pamiętam, gdy wymyśliłem sposób na odkrywanie pól, gdzie na pewno nie ma miny, w jednej z moich pierwszych gier – „Saperku”. Ogromna ilość satysfakcji, jaką odczułem, umocniła wtedy moje postanowienie o chęci stania się programistą.

Poziom skomplikowania zagadek i ich rodzajów w „The Witness” oraz wrodzona ciekawość spowodowały, że rzuciłem sobie wyzwanie, by spróbować napisać uproszczoną wersję algorytmu, który sprawdzałby poprawność rozwiązania podobnych zagadek.

Ponadto, gdy skończyłem grać w „The Witness”, czułem niedosyt. Mój mózg po dwóch tygodniach wskoczył na tory rozwiązywania nietrywialnych zagadek i chciał więcej. Szukałem innych gier logicznych, które dałyby mi podobną frajdę i chociaż znalazłem tak rewelacyjne gry jak „The Talos Principle” czy „The Swapper”, to nadal brakowało mi szukania dróg w kolorowych labiryntach.

Gdy siedziałem i patrzyłem w monitor, zastanawiając się jak zaimplementować wymyślony przeze mnie algorytm, pomyślałem:

Fajnie by było porozwiązywać tego typu zagadki na telefonie.

I tak zapadła decyzja o stworzeniu gry, dla której w tamtym momencie nie miałem jeszcze nazwy.

---

Za tydzień ciąg dalszy – wtedy opowiem Ci więcej o Mazerze.