Deep Platformer – technologiczne demo prostej platformówki

Odpowiedz Nowy wątek
2018-09-18 22:33
9

Biorąc pod uwagę fakt, iż moje wpisy na blogu dotyczące projektu Deep Platformer cieszyły się jakimś zainteresowaniem i że gramolę się niemiłosiernie z wydaniem końcowej wersji, podjąłem decyzję, aby już teraz opublikować wczesną wersję platformersa.

title screen.png


Deep Platformer

Deep Platformer to otwartoźródłowy projekt prostej platformówki. Pierwotnie miał to być jedynie wizualny test paralaksy oraz efektu płynnej zmiany warstwy, jednak z ciekawości i chęci eksperymentów, szybko przerodził się w coś znacznie większego.

Celem gracza jest sterowanie bohaterem w kształcie sympatycznego klocka, pokonywanie wielowarstwowych labiryntów w poszukiwaniu świetlików i bramki wyjścia. Sterowanie ogranicza się raptem do kilku klawiszy, pozwalających na chodzenie i skakanie, a także na wykorzystywanie specjalnych bramek. Dzielą się one na cztery kategorie: do zmiany warstwy, do zmiany kierunku działania siły przyciągania, do zapisu pozycji gracza oraz do wyjścia z planszy. Tylko bramka do zapisu bieżącej pozycji bohatera nie potrzebuje interakcji – pozostałe wymagają wciśnięcia odpowiedniego klawisza.

Demo składa się z intra (długiego lub krótkiego), menu, ekranów tytułowych dla różnych światów, pierwszego świata jako tutoriala (bez ekranu tytułowego), czterech światów podstawowych i jednego dodatkowego, a także siedmiu outro i creditsów. Każdy ze światów docelowo zawierać będzie po kilka poziomów, a wiele z nich również będzie wyposażonych w tematyczne, animowane cutscenki (tym zajmuję się obecnie).


Klawiszologia

Podstawowa obsługa platformówki ogranicza się do kilkunastu klawiszy. Bohaterem na boki poruszamy strzałkami, skaczemy spacją, bramek używa się strzałkami w górę i w dół (w zależności od funkcjonalności danej bramki). Rozgrywkę pauzuje się i wznawia za pomocą Escape, klawiszem F3 się ją resetuje a F4 zamyka. Klawiszami + i - zwiększa się lub zmniejsza okno. Jeśli okno nie jest rozciągnięte na pełen ekran, możliwe jest jego przesunięcie za pomocą myszy, na dowolny ekran.

Klawisze Escape i Space służą też do przyspieszania (a raczej pomijania) animacji.

Pełna lista klawiszy (również tych służących do debugowania) znajduje się w pliku readme.txt. Docelowo ten plik będzie zawierał pełen opis gry, ale póki co posiada tylko listę klawiszy.


Technikalia

Projekt w całości został napisany we Free Pascalu (Lazarus 1.8.4) i dzieli się na sześć różnych aplikacji – pięciu generatorów oraz głównej gry. Gra służy do grania (a jakże), a generatory do tworzenia binarek z jej zawartością. Kod źródłowy wszystkich wymienionych aplikacji możliwy jest do skompilowania do postaci 32- i 64-bitowej. Niestety, z racji konstrukcji kodu obsługi okna, jedyną wspieraną platformą jest Windows. Szkoda… :/

Wiele informacji na temat niecodziennych założeń oraz historii tworzenia tego pojektu podałem w moim ciągu wpisów na blogu, więc zainteresowanych takimi informacjami odsyłam do tych materiałów. Na blogu znajdziecie też zrzuty ekranu oraz fragmenty kodu. Natomiast jeśli ktoś ma jakiekolwiek pytania na temat technicznych aspektów tego projektu to z chęcią odpowiem na każde z nich.

Demówka jest przenośna (portable) – nie wymaga żadnego instalowania i nie zapisuje żadnych informacji na dysku użytkownika. Można ją uruchamiać z dysku lokalnego, z pendrive'a, a nawet z CD (jeśli ktoś jeszcze pamięta co to).


Kod źródłowy

Źródła głównej aplikacji (docelowej gry) składają się z 33 modułów, o łącznej liczbie linii równej 11.133:

  • Platformer.Main.lpr – główny moduł projektu,
  • Platformer.Window.pp – zawiera klasę formularza i jego obsługi,
  • Platformer.CommandLine.pp – zawiera klasę do obsługi linii poleceń,
  • Platformer.UserInterface.pp – zawiera klasę do manipulacji rozmiarem i pozycją okna,
  • Platformer.Game.pp – zawiera główną klasę gry,
  • Platformer.Scenes.pp – zawiera zestaw klas dla wszystkich scen gry,
  • Platformer.Story.pp – zawiera zestaw klas do obsługi fabuły gry i zarządzania nazwami plików,
  • Platformer.Buffers.pp – zawiera obiekty tylnych buforów oraz klasę bufora cyklicznego z templatkami szumu,
  • Platformer.Renderers.pp – zawiera klasy służące do renderowania wszystkiego co widoczne na ekranie,
  • Platformer.Time.pp – zawiera klasę głównego zegara utrzymującego zadany klatkaż,
  • Platformer.Fonts.pp – zawiera klasy reprezentujące fonty,
  • Platformer.Input.pp – zawiera drzewko klas do obsługi klawiatury,
  • Platformer.Cheats.pp – zawiera klasę do manipulowania trybem cheatowania (debugowania),
  • Platformer.Animations.pp – zawiera klasy do opisu wszelkich animacji (cutscenek),
  • Platformer.TitleScreens.pp – zawiera bazową klasę dla ekranów tytułowych,
  • Platformer.Sprites.pp – zawiera klasy przechowujące sprajty bohatera i świetlików,
  • Platformer.Levels.pp – zawiera klasy reprezentujące wielowarstwowy poziom,
  • Platformer.Slots.pp – zawiera klasę przechowującą dane na temat pozycji gracza (save slot),
  • Platformer.Worlds.pp – zawiera klasę opisującą ekran tytułowy dla światów,
  • Platformer.Menu.pp – zawiera klasę obsługi głównego menu gry,
  • Platformer.Camera.pp – zawiera klasę przechowującą dane na temat kamery,
  • Platformer.Gates.pp – zawiera zestaw klas do opisu bramek zmiany warstwy, grawitacji, zapisu oraz wyjścia,
  • Platformer.Fireflies.pp – zawiera klasy reprezentujące pojedynczy świetlik oraz ich listę,
  • Platformer.Hero.pp – zawiera klasy przechowujące dane na temat pohatera,
  • Platformer.Pause.pp – zawiera klasę przechowującą dane na temat zapauzowań rozgrywki,
  • Platformer.Counters.pp – zawiera klasy z danymi na temat liczby zgonów oraz zebranych świetlików,
  • Platformer.Scores.pp – zawiera klasy przechowujące statystyki gracza dla danej sesji,
  • Platformer.Movements.pp – zawiera klasy służące do modyfikacji pozycji gracza oraz świetlików,
  • Platformer.Collectors.pp – zawiera klasy z wydzieloną logiką kolekcjonowania (póki co tylko świetlików),
  • Platformer.Utils.pp – zawiera zestaw uniwersalnych subrutyn do przetwarzania bitmap,
  • Platformer.Types.pp – zawiera kilka typów danych, wymaganych głównie do renderowania tekstu,
  • Platformer.Helpers.pp – zawiera klasy helperów dla typów prostych i klas z biblioteki standardowej,
  • Platformer.Constants.pp – zawiera mnóstwo stałych, służących do kalibrowania gry i wielu jej elementów.

Generatory to dość proste aplikacje konsolowe, o specyficznej budowie i sposobie użycia. Składają się raptem z kilku modułów, a kod każdego z nich napisany jest w takim samym stylu.

Kod źródłowy nie zawiera żadnych komentarzy (nie licząc informacji o twórcy i licencji w każdym module). Nigdy ich nie dodaję, wzamian staram się pisać kod w taki sposób, aby sam informował o swoim przeznaczeniu. W razie czego pytać o szczegóły.


Uniwersalne fragmenty kodu

Projekt nie zawiera zbyt wiele fragmentów kodu, które możnaby zastosować w innych projektach, np. w zwykłych aplikacjach okienkowych. Jedyne moduły, których zawartość może być faktycznie przydatna, to Platformer.Utils.pp oraz Platformer.Helpers.pp. Znajdziecie tam praktyczne przykłady użycia metody ScanLine i efektywnej obróbki bitmap, a także przykłady rozszerzania typów prostych o dodatkowe metody.


Dalsze plany

Prace będą kontynuowane jedynie do ukończenia pierwszej wersji z pełną, docelową zawartością. Jak już wszystkie binarki m.in. z poziomami i animacjami zostaną ukończone, projekt wyląduje na GitHub (który posłuży tylko jako taki backup, bo w przyszłości nie zamierzam go rozwijać). Przetestowałem to co chciałem przetestować (a nawet o wiele więcej), a to co trafi do repozytorium, najpewniej już nigdy nie będzie przeze mnie aktualizowane.

Źródła udostępniam na licencji GPL, więc każdy chętny będzie mógł forknąć repozytorium i stworzyć coś swojego. Ewentualni moderzy będą mieli prostą drogę do przeróbek, za sprawą otwartego kodu źródłowego i dostępu do narzędzi, z których i ja korzystam. Oczywiście informacje na temat używania generatorów i tworzenia plików konfiguracyjnych znajdą się docelowo w plikach readme.txt (póki co są puste, a uzupełnię je na samym końcu).


Załączniki

deep platformer – release.zip

Zawiera skompilowaną wersję platformówki, bez źródeł. Niektóre pliki są jeszcze nieuzupełnione. Do dyspozycji są dwa pliki wykonywalne i oba zawierają to samo, tyle że ten z postfiksem debug ma włączony stały tryb debugowania, dzięki czemu można się pobawić również dodatkowymi opcjami.

Pliki wykonywalne nie są podpisane cyfrowo, do tego są skompresowane za pomocą UPX, więc oprogramowanie antywirusowe oraz pewne usługi Windows mogą ostrzegać przed potencjalnie szkodliwą zawartością. Pliki te są jak najbardziej czyste, nie zawierają żadnych wirusów.

deep platformer – mirror.zip

Jest to kopia całego katalogu z projektem, zawiera pełne źródła wszystkich aplikacji, skompilowane pliki wykonywalne oraz pliki konfiguracyjne (i nie tylko) dla generatorów, do tworzenia testowej zawartości. Jednym słowem wszystko co potrzebne do zbudowania gry i tworzenia zawartości.

Zawiera też skróty do generatorów (*.lnk) z ustalonymi parametrami, tak aby móc tworzyć binarki dwuklikiem, bez koniczności otwierania konsoli i ręcznego podawania parametrów ze ścieżkami (a te są dość długie). Skróty powłoki zawierają ścieżki relatywne, więc śmiało można z nich korzystać.


Have fun. ;)


edytowany 21x, ostatnio: furious programming, 2019-01-28 21:48
Wiem wiem, dlatego o tym wspomniałem. W razie braku zaufania, zawsze można odpalić w antywirusowym sandboksie. ;) - furious programming 2018-09-18 22:56

Pozostało 580 znaków

2018-09-18 22:53
1

u mnie działa :)


Phi… też mi coś… :P - furious programming 2018-09-18 23:13

Pozostało 580 znaków

2018-09-18 23:21
1

Uściślając – gra będzie działać na dowolnym komputerze z systemem Windows, poczynając co najmniej od WinXP, aż po Win10 (w załącznikach pliki wykonywalne są 32-bitowe). Bez problemu się uruchomi i będzie działać prawidłowo – chyba że jakiegoś ważnego pliku braknie, wtedy strzeli focha i się po prostu wyłączy. ;)


To co może bardzo przeszkadzać to ”skacząca” animacja przewijania poziomu podczas ruchu bohatera oraz efekt rozrywania obrazu. Przewijanie poziomu ładnie (płynnie) wygląda na matrycach z wysokim czasem reakcji (głównie matowych lub po prostu starych), więc jeśli ktoś taką posiada, to może sobie okno gry na nią przeciągnąć. No i jasna sprawa – im mniejsze okno, tym mniej widoczne defekty animacji.

Natomiast w razie problemów z płynnością animacji lub wnerwiającą linią spowodowaną rozrywaniem obrazu, można spróbować uruchomić grę z okresleniem niższego klatkażu:

> platformer.exe framerate pal

Wtedy gra działać będzie z prędkością pięćdziesięciu klatek na sekundę, co owy pal symbolizuje. Tu niespodzianka, bo niższy framerate to wolniejsze działanie gry (o kilkanaście procent) – można poczuć dawny klimat na odpierdziel portowanych gier z NES-a na Famicoma. ;)

W wersji z permanentnym trybem debugowania, w miejsce pal można podać liczbę z zakresu od 1 do 60.

Parametrów możliwych do podania z linii poleceń (lub skrótu powłoki, co w sumie na jedno wychodzi) jest więcej – w razie czego mogę je też podać. Ewentualnie można je wykukać w źródłach projektu (opcja dla hakerów).


edytowany 12x, ostatnio: furious programming, 2018-09-18 23:31

Pozostało 580 znaków

2018-09-18 23:30
0

Przeszedłem :-)
Pomysł na światy (te same) w różnych kolorach. Jak na moim Atari i grach ładowanych z kaset magnetofonowych :-D Dwa pytania:

  • Na końcu jest 'score' i coś jeszcze ale niechcący kliknąłem i zniknęło, a nie zauważyłem punktacji?
  • Dlaczego ten botnet żre 14% z mojego stacjonarnego procesora?

"Trolling is a art"

Pozostało 580 znaków

2018-09-18 23:46
2
Hispano-Suiza napisał(a):

Pomysł na światy (te same) w różnych kolorach. Jak na moim Atari i grach ładowanych z kaset magnetofonowych :-D

No tak, poziomy przede wszystkim będą się różnić kolorem tła, ale nie tylko. Póki co platformy są kwadratowe, zgodne z hitboksami, ale docelowo będą posiadać nieregularne kształty (np. trawka, krzaczki, kamienie, liany itd.), które nie będą podlegać kolizji.

To co obecnie gra posiada, czyli poziomy o dokładnie takiej samej zawartości, bez możliwości zmiany warstwy i kierunku przyciągania, służy tylko do testowania (krótkie, bo ostatnio sprawdzałem działanie klasy fabuły i punktacji). Docelowo będą o wiele bardziej ciekawe, z pełną funkcjonalnością i konkretnymi grafikami platform. Odcienie teł i styl ich gradientów mogą jeszcze ulec zmianie. Choć i tak pewnie nikt nie zauważy(ł), że tło jest gradientem. ;)

  • Na końcu jest 'score' i coś jeszcze ale niechcący kliknąłem i zniknęło, a nie zauważyłem punktacji?

To było outro z tymczasową informacją o tym, czy zatłukłeś bohatera co najmniej raz i czy zebrałeś wszystkie świetliki. Tylko takie informacje gra kolekcjonuje w danej sesji i używa ich tylko do dwóch rzeczy:

  • do określenia czy gracz zasłużył na dodatkową zawartość (obecnie: na dodatkowy świat),
  • do określenia które outro pokazać.

Podczas rozgrywki, w lewym górnym rogu widoczne są liczniki – jeden z liczbą zgonów, a drugi z liczbą zebranych świetlików. Polecam pobawić się wersją z włączonym trybem debugowania – w niej można manipulować stanem liczników.

  • Dlaczego ten botnet żre 14% z mojego stacjonarnego procesora?

Zapomniałem dodać – gra w tle kopie bitcoiny. Nie przejmuj się, u mnie żre 50%! ;)

A tak na poważnie – platformówka zawsze zjada całą dostępną moc jednego jądra procesora (nawet pisałem o tym na blogu). Głównym powodem takiego stanu rzeczy jest zbyd czasochłonne przetwarzanie i renderowanie grafiki, co wyklucza możliwość użycia procedur oczekujących, takich jak Sleep. A jest zbyt czasochłonne, bo w całości wykonywane jest przez CPU (jak wspomniałem, jednym z założeń było nieużywanie bibliotek do tworzenia gier).

Sleep używa zegara systemowego, o zbyt niskiej częstotliwości, przez co w przypadku tego projektu nie da się go wykorzystać do oczekiwania mniej niż 10ms. Gra na słabszych komputerach zużywa grubo ponad 10ms do przetworzenia grafiki, co zmusza do oczekiwania na kolejną klatkę nawet przez mniej niż milisekundę (w niektórych przypadkach). Dlatego mechanizm oczekujący na kolejną klatkę to po prostu zwykła pętla, ciągle sprawdzająca liczbę ticków procesora i to ona odpowiada za pełne zużycie mocy.

Taka konstrukcja zegara jest jednym z założeń – chciałem zaimplementować ”zegar” maksymalnie podobny w działaniu do tego z Famicoma. Na tej platformie nie używało się delty i wielowątkowości, a oczekiwało na sprzętowe przerwanie odblokowujące PPU (tzw. NMI). Wyszło elegancko, choć to takie zupełnie niedzisiejsze. W razie czego ten retro-smaczek znajdziecie w źródłach (i nie tylko ten).


edytowany 16x, ostatnio: furious programming, 2018-09-25 22:27
@furious programming: Pardon. Przyznam, że nie jestem na bieżąco z wpisami z mikro, aczkolwiek nadrobię ;-) - Hispano-Suiza 2018-09-19 00:00
Dlatego z chęcią odpowiem na ~wszystkie pytania. Mimo wszystko zachęcam do zapoznania się z wpisami na blogu (w kolejności od ostatniego wpisu), bo w nich opisałem i pokazałem również elementy, które finalnie nie będą użyte. ;) - furious programming 2018-09-19 00:04

Pozostało 580 znaków

2018-09-18 23:59
6

Nie mogę znaleźć mikropłatności, wtf? to jakiś bug?

Beta. Na zachętę. :-D - Hispano-Suiza 2018-09-19 00:01

Pozostało 580 znaków

2018-09-19 00:02
1

Damn it… zapomniałem… :/

W sumie to to co obecnie dodałem do załączników, co najwyżej w połowie oddaje wartość tego projektu. Sama ”labiryntowata” konstrukcja poziomów z nieregularnymi kształtami platform, ukrytymi przejściami i wieloma grywalnymi warstwami, a także cutscenki, powinny dość mocno uatrakcyjnić całość. Muszę je tylko skończyć…

Ewentualnie postaram się co nieco pokazać wcześniej, zanim skończę wszystkie poziomy.


edytowany 1x, ostatnio: furious programming, 2018-09-19 00:06

Pozostało 580 znaków

2018-09-19 00:15
0

Czy jesteś już na emeryturze, czy po prostu nie zajmujesz się żoną i dziećmi :D ?

Bo jednak to:

  • tworzenie gry non-profit;
  • takie szczegółowe opisy.

Trochę czasu to zajmuje...

edytowany 2x, ostatnio: Spine, 2018-09-19 00:17

Pozostało 580 znaków

2018-09-19 00:38
3
Spine napisał(a):
  • tworzenie gry non-profit;

Jeśli podzieli się liczbę linii kodu na liczbę dni spędzonych przy tym projekcie, to wyjdzie niewiele. Zresztą mnie pisanie kodu trudno nie przychodzi, po prostu siadam i piszę. Poważnych problemów z błędami w świeżo napisanym kodzie raczej nie miewam, więc mogę w kilka godzinek nastukać nawet tysiąc linijek działającego kodu (pod warunkiem, że dany algorytm z założenia musi działać i dokładnie wiem co mam zrobić).

Mimo wszystko nie wyszło mi to wcale tak szybko – projekt miał być gotowy grubo ponad miesiąc temu.

A jeśli o przydługie odpowiedzi na forum chodzi, to mam już w tym wprawę – odpowiadanie w wielu wątkach jednocześnie uczy szybkiego pisania, również jeśli chodzi o znaczniki formatowania tekstu.

  • takie szczegółowe opisy.

Cache to podstawa – pierwszy post zalegał dwa dni w notatkach Opery. ;)


edytowany 6x, ostatnio: furious programming, 2018-09-19 17:14
Wydaje mi się, że przy mniejszych grach kod to akurat najmniejszy problem - spirtesy/animacje/instrukcje lub po prostu sam koncept :P - WeiXiao 2018-09-19 00:41

Pozostało 580 znaków

2018-11-15 16:55
1

Przysiadłem do tematu – zrobiłem sześć poziomów pierwszego świata, który służy jako tutorial.

Na razie platformy są zgodne z hitboksami (a więc zbudowane z kwadratów), bo ostateczne szczegóły takie jak trawa, krzaki, drzewa, kamyki itd. będą malowane na samym końcu, jak już będę miał przygotowane wszystkie poziomy wszystkich światów.

Ogólny zamysł na wygląd platform jest taki, aby sprawić wrażenie przebywania wewnątrz trójwymiarowej ”bańki”. Można powiedzieć, że silnie inspiruję się grą Limbo. Z tego powodu jeśli bieżąca warstwa posiada np. funkcjonalną półkę, to warstwa dalsza posiada jej dalszy ciąg. Jeśli mamy wąskie przejście, to zwęża się ono wizualnie z każdą dalszą warstwą. Bardzo fajnie to wygląda w połączeniu z efektem paralaksy. Docelowy kształt platform może się jeszcze nieco zmienić (jeśli chodzi o kwadraty, bo detale w postaci upiększających obiektów na pewno będą domalowane).

preview.png

Poziomy pierwszego świata (tutoriala) będą docelowo wyposażone w animowane przerywniki, tłumaczące w jaki sposób grać, ale tych jeszcze nie zrobiłem. Tak jak poprzednio – strzałki na boki służą do chodzenia, strzałki góra/dół do używania bramek i spacja do skakania. Czwarty poziom tutoriala zawiera pewien smaczek, ale nie będę go zdradzał – próbuj. ;)

Pozostałe światy posiadają krótkie, testowe poziomy – takie jak wcześniej.


Do załączników wrzucam dwa archiwa:

I tak jak poprzednio – w wersji release plik wykonywalny jest spakowany za pomocą UPX, a wszystkie exeki nie posiadają podpisu cyfrowego, więc zignorujcie ostrzeżenia przed potencjalnie szkodliwą zawartością.


edytowany 5x, ostatnio: furious programming, 2018-11-15 17:00
Przydałoby się zaktualizować pierwszy post o te nowe linki. - several 2018-11-23 09:33

Pozostało 580 znaków

2018-11-15 17:16
0

Ściągnąłem, pograłem. Całkiem spoko.

Doszedłem do planszy, gdzie jest przepaść. Niestety wyskok nie bardzo chce działać na krawędziach. Jak stoję i się nie poruszam to mogę podskoczyć w górę, ale skakanie "w biegu" w prawo po prostu nie chce zatrybyć.
screenshot-20181115171131.png

Może pozwól na skok jeszcze przez 0.15s od momentu stracenia gruntu pod nogami? To by drastycznie zwiększyło mobilność postaci ;)

Dopiero po wielu próbach przez przypadek wskoczyłem w planszę (pewnie to zamierzone?):
screenshot-20181115171416.png

Fajny ten mechanizm Deeper/Nearer ;)

edytowany 2x, ostatnio: Spine, 2018-11-15 17:19
Czemu krawędzie na tych obrazkach są lekko rozmyte? Rozciągałeś może te obrazki w jakimś edytorze, czy to oryginalne zrzuty (1:1)? - furious programming 2018-11-15 21:54
Wycinałem okienko ze screenshota. No i mam monitor z rozdzielczością powyżej full hd, więc ustawiłem sobie skalowanie w dół, żeby mieć większe ikonki/UI systemowe. - Spine 2018-11-15 22:19
Hmm… to dziwne… skalowanie nie powinno mieć żadnego wpływu na jakość obrazu. Choć w sumie to nie mam co do tego pewności, bo nie wiem jak dokładnie zachowuje się metoda StretchDraw na wszystkich systemach i różnych ustawieniach UI. Nie żeby w czymś to przeszkadzało – pytam z ciekawości. U mnie obraz jest ostry jak żyleta. ;) - furious programming 2018-11-15 22:30
Choć nie – może mieć to wpływ na końcową jakość obrazu. Jeśli system używa skalowania podczas renderowania zawartości okna, to możliwe, że najpierw jego obraz buforuje, a na koniec – podczas renderowania na ekranie – rozciąga go względem stopnia skalowania. I na to by wychodziło, bo kod renderujący obraz klatki na płótnie okna mam napisany w taki sposób, aby rozmywanie nie było wykorzystywane. - furious programming 2018-11-15 22:34

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0