Tworzenie postaci, efektów i nagłej fabuły (4 filmy).
Witam wszystkich! Wydaliśmy pierwszy odcinek naszej logicznej platformówki w stylu retro 16-bitowych Amigi i Segi. Pierwszy odcinek to 10 poziomów z 40 do tej pory. Chcemy podzielić się naszym doświadczeniem w tworzeniu chociażby tego odcinka. (pobierz w Google Play dotychczas)
Ostatnim razem opracowaliśmy rdzeń potrzebnej mechaniki. Teraz można powiedzieć, że rozpoczął się drugi etap rozwoju: zaczęliśmy tworzyć indywidualne postacie, efekty itp.
Pierwszy w kolejce był robot, czy raczej Psycho-Robot, jak go nazywaliśmy. Psycho, bo strzela na wszystkie strony i nigdy nie wiadomo, gdzie trafią jego wyładowania.
Generalnie nie chcieliśmy myśleć o fabule i fabule gry, ponieważ zdaliśmy sobie sprawę, że tworzymy grę logiczną, w której trzeba będzie rozwiązywać zagadki poziom po poziomie ze wzrastającym poziomem trudności. Co więcej: nawet nazwa została wymyślona przez przypadek. Jeśli nie znasz rosyjskiego, prawdopodobnie nie zrozumiesz, czym jest „Chubrick”. A jeśli jesteś choć trochę zaznajomiony, zdasz sobie sprawę, że chubrick to mała osoba, którą często widujemy w komiksach memowych. Jest to zwykle abstrakcyjna i zabawna postać, a raczej „jednostka charakteru”. Jak więc zauważyłeś, „chubrick” jest dokładnie główną postacią, w którą można grać. Ale przesunęliśmy to słowo na koniec i nazwaliśmy to dziwne słowo jakąś starożytną cywilizacją (wiesz, jak Chozo w Metroidzie). Głupia decyzja, prawda? No cóż, w czym rzecz! Nawiasem mówiąc, ogólna nazwa „Space Takes” pierwotnie brzmiała także „Space Tales”, ale po googlowaniu zdaliśmy sobie sprawę, że taka gra już istnieje, więc postanowiliśmy jej nie powtarzać. A później okazało się, że słowo „bierze” jeszcze lepiej pasuje do znaczenia gry.
Dlatego postanowiliśmy całkowicie zapomnieć o fabule. My jednak między innymi kochamy i szanujemy sztukę pisania scenariuszy i już podczas oglądania filmu wpadliśmy na całe hobby polegające na umieszczaniu tego w blokach scenariusza. Tak więc, jak to często u nas bywa, na tym etapie fabuła zaczęła się narzucać sama. A jeśli zacznie być minimalnie identyfikowalny, to lepiej się tego trzymać, aby cała wiedza wydawała się integralna i nie pachniała bzdurami.
Ale jaka jest tutaj fabuła? Jakaś planeta ze słabą grawitacją, jakieś dziwne roboty – wszystko wydaje się przypadkowe. Ale automatycznie dostrzegliśmy minimalny wątek we wszystkim, co się działo, i postanowiliśmy ogłosić to oficjalnie.
Poziom po poziomie trzeba przechodzić do kolejnych sektorów, jednak starożytna cywilizacja Chubrick dbała o to, aby nie odwiedzały ich bardzo głupie stworzenia. Wynaleźli system przejść, w którym musisz podnieść ciężary w postaci liczb całkowitych, połączyć je i umieścić na skali przedstawionej jako kamienna płyta.
Ale co tu robią roboty? Bardzo proste. Ludzie niedawno odkryli tę planetę i zaczęli ją eksplorować, kopać, wiercić kilka jaskiń itp. Wszystkie roboty to ludzkie mechanizmy, w jakiś sposób powiązane z wykopaliskami. Pewnego dnia coś poszło nie tak i wszystkie roboty na planecie przestały działać. Konsekwencjami tego niepowodzenia została wyznaczona eliminacja jednego z zakontraktowanych likwidatorów. Wskazuje na to oznaczenie „LQQ-1701” (mała pisanka ze Star Trek) ze zmianą pierwszych trzech liter. Jeśli w Star Treku pierwsze litery „NCC” oznaczały „Kontrakt na budowę marynarki wojennej”, to w naszym przypadku skrót „LQQ” oznacza „Kolejka ofert likwidacyjnych”.
Po zrealizowaniu takiego spisku zarysowaliśmy w minimalnym stopniu przeszłość każdego robota. Na przykład robot Psycho otrzymał znak prądu, który powinien dać graczowi wskazówkę, że przed awarią masy był tylko skrzynką transformatorową i wcale nie rozprowadzał prądu we wszystkich kierunkach.
Następny w kolejce był metalowy żółw, który wygląda na jakiś pojemnik do przenoszenia, najprawdopodobniej czegoś ciężkiego, na przykład kamieni. W przeciwieństwie do metalowej odbijającej się kuli, która prawdopodobnie jest kurierem dla mniej ciężkich rzeczy, takich jak dokumenty lub małe próbki gleby, które trzeba dostarczyć znacznie szybciej.
Na tym samym etapie przerobiliśmy już układ płytek klifu, kompilując go automatycznie z 512 zasad, czyli maksymalnej liczby uwzględniającej przekątne położenia sąsiednich płytek. Nie korzystaliśmy z niczyich wtyczek do Godota, ale napisaliśmy własny skrypt, który automatycznie uzupełnia zestaw klocków na podstawie wypełnionych komórek i zgodnie z plikiem reguł, w którym ręcznie przepisano wszystkie możliwe warianty dla każdego z 512 przypadków. To było mnóstwo pracy i może kiedyś sformalizujemy ten scenariusz i opublikujemy go dla Was. W przeciwieństwie do reguł autotilingu w Tiled i innych programach, uważamy, że nasz format reguł w pliku jest łatwy do zrozumienia. Ale najpierw chcielibyśmy stworzyć małe narzędzie do wygodniejszej i szybszej kompilacji tych reguł.
W kolejnym etapie poprawiliśmy zachowanie obiektów. Ale co najważniejsze, dodaliśmy drzwi i płytę, na które mechanika ciężaru mogła już mieć bezpośredni wpływ. Jeśli na płycie znajduje się odpowiedni ciężar, drzwi się otwierają. Jeśli nie, zamyka się. Czujemy, że dodamy jeszcze kilka zagadek związanych z wagą, ale na razie skupiamy się tylko na tej najważniejszej – płycie i drzwiczkach.
W końcu zaczęliśmy ulepszać część wizualną: dodając tła, efekty i tak dalej. Ale najważniejszą innowacją było menu. Tryb gry, który widziałeś do tej pory (bieganie, skakanie itp.) ma przypisany odrębny stan spośród kilku, podobnie jak tryb menu i wszystkie tryby, które możesz napotkać w grze. Z uwagi na to, że rozdzielczość płótna gry jest bardzo niska, bo wynosi zaledwie 320×180 (to nawet nieco mniej niż w klasycznych grach z lat 90.), zaprojektowanie menu nie należało do najłatwiejszych. Zwłaszcza jeśli są zorientowane na urządzenia mobilne. Ostatecznie najlepszym rozwiązaniem było zrobienie menu na wzór z Dooma 1993 – jest ono najbardziej optymalne.
W przypadku menu strefy dotykowe powinny być odpowiednio ustawione, wszystkie elementy powinny mieć odpowiednią ilość miejsca itd. I niestety, nie ma wystarczająco dużo miejsca ze względu na naszą dziwną decyzję o renderowaniu wszystkich duszków wyłącznie na płótnie o wymiarach 320×180, tak aby wszystkie piksele miały jednakowy rozmiar i nie było duszków o różnych szczegółach. Bardzo nie lubimy, gdy pikselowe ikonki są dowolnie obracane i skalowane w grach z natywną rozdzielczością ekranu, co oczywiście zaburza wielokąty, na których są rysowane. Generuje to „efekt kartonu”, jak to nazywaliśmy. Taki kontrast jest bardzo stresujący dla percepcji, gdy np. na tle ogromnych pikseli o małej gęstości nagle pojawiają się duszki o zwiększonej gęstości. Naszym zdaniem wizualnie wygląda to bardzo nieprzyjemnie. Widzieliśmy to zjawisko w grach flashowych z początku XXI wieku, które wywarły silne wrażenie takiej grafiki jak śmieci, mimo że na flashu były gry bardzo dobrej jakości. Więc my, jako zwolennicy „pixel Perfect”, wybraliśmy tę metodę, ale niestety nie jest ona tego warta. Zbyt trudno jest myśleć o wyglądzie menu w takich ograniczeniach, więc następnym razem zrobimy tak, jak wszyscy. Najważniejsze jest utrzymanie jednolitej gęstości pikseli.
Mamy nadzieję, że powiedzieliśmy Ci coś interesującego. Będziemy kontynuować naszą historię później.
W międzyczasie możesz pobierz odcinek 1 i wypróbuj. Na pewno będzie jeszcze sfinalizowany i pełen wydarzeń, ale o tym wszystkim porozmawiamy później.