Nie rzuciłem pracy ani studiów, ale tworzę gry i dobrze mi z tym.

Hej. Nazywam się Tomasz Marciszewski. Jestem programistą od kiedy pamiętam. Graczem jestem jeszcze dłużej. Przez lata wymyślałem przeróżne pomysły na własną grę — jedne głupsze od drugich. Wszystkie jednak miały jedną wspólną cechę. Były tylko pomysłami. Nigdy nie doszło do implementacji. W 2015 roku postanowiłem to zmienić.

Programować już umiałem, ale okazało się, że tworzenie gier to o wiele szerszy temat, niż kolejny przewracacz cyferek dla banku. Przetestowałem kilka silników i w końcu trafiłem na Unity. Większość silników ma sporą barierę wejścia. Część ma własny język skryptowy, albo wymaga złożonej konfiguracji. Unity jest inne. Pozwala na właściwie dowolne rozbudowanie projektu — od bardzo prostej gry 2d do super zaawansowanych symulacji 3D na poziomie gier AAA. Przy okazji koduje się w C#, co likwiduje dla mnie kolejną przeszkodę. Co równie istotne — wszystkie projekty z Unity można bardzo łatwo przekonwertować, tak żeby działały zarówno na PC jak i na Androidzie czy iOSie (i wielu innych platformach).

Nauka podstaw zajęła mi kilka miesięcy, ale na początku 2016 roku czułem się już wystarczająco komfortowo w Unity, by przystąpić do produkcji pierwszego kompletnego projektu. Tak powstało Boulders (https://play.google.com/store/apps/details?id=pl.progmatic.boulders). Gra sporo czerpała z Boulder Dasha, ale ogólna rozgrywka, według mnie, różniła się wystarczająco od oryginału, żeby nie nazywać jej klonem. Projekt powstał jako kolejny krok w nauce. Jak łatwo się domyslić, ogromnego sukcesu nie było. Na Google Play grę ściągnęło trochę ponad 1000 użytkowników. Poza Play bardzo aktywni okazali się Chińczycy. Gra została dość szybko skopiowana na jeden z popularnych dalekowschodnich serwisów hostujących “pirackie” APK. Chińczycy pobrali Bouldersy ponad 5 tysięcy razy i do dziś grają w najlepsze, mimo że nie wrzuciłem update’u od dłuższego czasu.

Jak szybko się okazało, najtrudniejszą częścią produkcji gry nie było dla mnie samo kodowanie, czy tworzenie grafiki i modeli 3D. Najtrudniejszy jest marketing. Nie jestem specjalnie wylewny. Nie potrafię się chwalić tym, co robię — po prostu tak zostałem wychowany. Nagle okazało się, że żeby zainteresować graczy, trzeba stale pokazywać i opisywać nawet najmniejsze rzeczy, nad którymi się pracuje. Samo przełamanie wstydliwości było nie lada wysiłkiem. Zacząłem wrzucać materiały z produkcji gry na Twittera i (czasami) na Reddita. Początkowo zainteresowanie było minimalne, ale z czasem inni developerzy i gracze zaczęli komentować moje postępy. Moje aktualne podejście wygląda tak: trzeba wrzucać wszystko, nawet najmniejsze zmiany. Zrobiłeś nowy model — wrzucasz. Dodałeś nową animację — pokaż ją wszystkim. Do dziś nie udało mi się wykombinować, jak wywołać masowe zainteresowanie. Mam nadzieję, że kiedyś się uda.

Mimo, że Boulders nie okazało się ogromnym sukcesem, ja byłem zadowolony. Nauczyłem się MASY rzeczy. Po krótkiej przerwie zacząłem pracować nad następnym projektem. Moje podstawowe założenie było proste. Grę ma się kontrolować jednym palcem. Nie mam na myśli wyeliminowania tylko skomplikowanych gestów czy używania przycisków. Jedyną interakcją ma być dotknięcie ekranu, w dowolnym miejscu. Aktualnie moim ulubionym gatunkiem gier są rogue-lite, w swoich przeróżnych odmianach i smakach. W pierwszym odruchu pomyślałem: “stworzę rogue-lite, sterowanego jednym przyciskiem”. To był głupi pomysł. Może bardziej doświadczeni designerzy mogliby sie tego podjąć. Ja nie jestem jednym z nich. Z mojej perspektywy podstawą rogue-lite są wybory. Trudno dokonywać wyborów jedynie dotykając ekranu. Jakiś czas później trafiłem na świetny projekt o nazwie Reigns. Jego twórcy wprawdzie zakładają użycie swipeowania na lewo i prawo (coś jak Tinder albo inne, podobne apki), jednak podziwiam ich kreatywność.

W każdym razie, pomysł na rogue-lite upadł. Powstała nowa koncepcja — gra typu arcade o wiele bardziej pasuje do modelu uproszczonego sterowania. A chyba najbardziej oczywistą reakcją na tapnięcie w ekran, jest skok postaci. Po kilku zmianach gra zaczęła nawet mieć tytuł Crumpy Jump. Tak. Nie jestem wybitnie oryginalny. Znam takie pozycje, jak: Shooty Skies, Crossy Road itd., itp. Jednak pamiętajmy, że grę robimy nie dla siebie, tylko dla graczy. Podążanie za aktualnymi trendami nie jest złe. Struktura samego tytułu została częściowo wymuszona przez inny aspekt gry. Postanowilem bowiem odejść od grafiki 2D/pixelartu i spróbować moich sił w 3D. Tworzenie super skomplikowanych modeli jest chwilowo daleko poza moimi możliwościami… ale są jeszcze voxele. Okazuje się, że posiadając pewne doświadczenie w Pixel Art, jestem w stanie tworzyć sensowne i dobrze wyglądające “kwadratowe” modele 3D. Co ciekawe — użytkownicy je uwielbiają. Są słodkie i uruchamiają wyobraźnię. Sukces? (!)

Od słowa do słowa, pomysł powoli się wyklarował. Gra jest przeznaczona na urządzenia mobilne. Postać będzie skakała z wysepki na wysepkę. Na niektórych będzie się czaiło zło (pułapki, potwory itp). User ma unikać tych pułapek poprzez tapnięcie w ekran dwa razy. Proste. Gra ma mieć szokującą ilość bohaterów, którzy będą się poruszali po specjalnie dla nich stworzonych planszach.

Jako developer bez specjalnych sukcesów nie mam budżetu. To oznacza również, że do wszystkiego co robię, staram się używać darmowego oprogramowania. Początkowo tworzyłem modele w MagicaVoxel, ale okazało się, że przy eksporcie MagicaVoxel niespecjalnie dobrze optymalizuje wynik. Gra miała działać na urządzeniach mobilnych, a te nie lubią wyświetlać dziesiątek tysięcy trójkątów. Po dłuższych poszukiwaniach, trafiłem na nowe narzędzie — Qubicle. Mechanizmy edycyjne w Qubicle są lata świetlne ponad tymi w MV, a wygenerowane modele mają przynajmniej 3–4 razy mniej skomplikowaną geometrię. Jest jednak jeden problem. Qubicle nie jest darmowe. Początkowo używałem triala, który można znaleźć na Steamie — nie chciałem od razu inwestować w rozwiązanie, które potem porzucę. Po kilku tygodniach okazało się, że nie ma odwrotu. Trzeba wyskoczyć z tych paru stówek. Z jakością nie da się dyskutować.

Gra powstawała w najlepsze, ale jednej rzeczy poważnie w niej brakowało — dźwięku. Proste efekty dźwiękowe — takie jak skoki, zbieranie monet, lądowanie — po dłuuuugiej sesji prób i błędów, udało się wygenerować, przy użyciu BFXR’a. Po lekkich poprawkach w Audacity nawet nie brzmiało to najgorzej. Przy tych bardziej skomplikowanych pomógł mi kolega — Marcin Marzewski. To on jest autorem dźwięków, które usłyszycie w scenie odblokowywania nowej postaci. Inni życzliwi developerzy mogą być nieocenioną pomocą. Zawsze możesz liczyć na rzeczową, konstruktywną krytykę, a czasami nawet podrzucą jakiś fajny asset. Win! Kolejnym problemem była muzyka. Z nią już nie poszło tak łatwo. Mimo wielu prób, nie byłem w stanie skomponować i stworzyć sensownej ścieżki dźwiękowej. Kropka. Nie miałem również budżetu, żeby zapłacić komuś bardziej uzdolnionemu… Creative Commons to the rescue! Na Reddicie znalazłem fantastycznego kompozytora — Fabiana Grempera. Fabian był tak miły, że udostępnił część swojej (niesamowitej!) twórczości developerom gier. I Boulders i Crumpy Jump używają jego muzyki, jako podkładu. Jeżeli tylko będę miał jakiekolwiek rzeczywiste finansowanie na następne projekty, to będzie pierwszy człowiek, któremu zapłacę.

Tworzenie Crumpy Jump zajęło mi około sześć miesięcy. Praca po godzinach nie jest tak wydajna. Często też zdarzają się ważniejsze rzeczy do roboty, niż klepanie gierek. Nie wiem… na przykład żona, albo dzieci są ważne. Mimo, że na razie nie udało mi się odnieść wymiernego sukcesu w branży gier, jestem szczęśliwy. Robię coś ciekawego. Robię coś dla ludzi. Robię coś z ludźmi. To nie ma znaczenia, że nigdy nie zarobiłem złotówki na moich grach. Sama frajda z ich tworzenia jest na tę chwilę najlepszą nagrodą.

Jeżeli macie ochotę zobaczyć wyniki mojej pracy, znajdziecie je tutaj: https://play.google.com/store/apps/details?id=pl.progmatic.crumpyjump