Deep Platformer – technologiczne demo prostej platformówki

3

Końcowa wersja platformówki posiadać będzie jeszcze kilka nowych funkcji, o których nie wspominałem. ;)


Pierwszą nową funkcją, wprowadzoną jakiś czas temu (podczas mojego ”urlopu”) jest rozszerzona funkcjonalność sterowania bohaterem. Teraz oprócz chodzenia i skakania, możliwe jest również rozglądanie się – trzeba trzymać klawisz Ctrl i przytrzymać jednocześnie klawisz strzałki (lub dwóch strzałek, jeśli chcemy przesunąć kamerę po ukosie). Kamerę można przesunąć w poziomie maksymalnie o pięć kafli (czyli o 80px) i w pionie o cztery kafle (czyli o 64px). Kamera pozostaje wychylona dotąd, aż zwolnimy klawisz Ctrl – wtedy ta płynnie centrowana jest względem bohatera, uwzględniając martwą strefę:

Wychylanie kamery i jej centrowanie jest zsynchronizowane z ruchem bohatera. To sprawia, że np. wychylając kamerę maksymalnie w prawo, następnie puszczając Ctrl, ale trzymając wciąż strzałkę w prawo, bohater zaczyna iść, ale kamera stoi w miejscu do momentu wejścia bohatera w martwą strefę i dotknięcia jej prawej strony (analogicznie dla wychylenia i ruchu w lewo). Dzieje się tak dlatego, że szybkość wychylania i centrowania kamery jest taka sama jak szybkość ruchu bohatera w poziomie. Wyszło bardzo fajnie:

Dodałem ten ficzer dlatego, że przy większych poziomach trudno jest określić czy coś znajduje się pod/nad ekranem czy nie – w końcu rozdzielczość pionowa jest bardzo mała, a martwa strefa kamery co prawda likwiduje efekt ”skakania” ekranu nawet przy niewielkim ruchu, jednak dodatkowo zmniejsza pole widzenia. No i kosztowało to raptem kilkanaście linijek kodu, może pół godziny roboty razem z przetestowaniem wszystkich przypadków.


Drugą nowością w projekcie jest nieco inne menu główne. Wcześniej logo gry było wyświetlone po lewej stronie, bohater stał na platformie po prawej stronie i po wciśnięciu spacji szedł w prawo poza ekran. Teraz bohater stoi na logo, a po wciśnięciu spacji najpierw zeskakuje z logo na platformę, a następnie – tak jak wcześniej – idzie w prawo i wychodzi poza ekran:

Bohater tak naprawdę wcale nie stoi na logo, bo ono nie jest elementem poziomu. Trik polega na tym, że pod bohaterem znajdują się hitboksy, tak aby mógł na nich stać i po nich chodzić, ale warstwa nie zawiera w ich miejscu graficznych detali (czyli platform). Gdyby nie renderować loga, to bohater wizualnie znajdowałby się w powietrzu. Logo jest wypozycjonowane w taki sposób, aby góra liter była równo z górą hitboksów – dlatego wygląda to tak, jakby klocek chodził po literkach i z ostatniej zeskakiwał.


Trzecią nowością jest odpicowana scena staffu, o której tle napisałem przedwczoraj wpis na blogu. Co prawda nie opisałem wszystkich jej szczegółów, ale coś musi przecież pozostać do odkrycia.

1

Chwilę trwało, zanim zajarzyłam, że jak nad głową pojawia się napis "exit", to trzeba nacisnąć strzałkę w górę.

Skakanie na krawędziach: Jak Kwadratek zbiega z krawędzi platformy (ale częścią podstawy jeszcze na niej stoi) to już nie może się odbić. Dlatego nie przeszłam 3-ciej planszy. (edit: dobra, przeszłam po podpowiedziach).

Oznaczyłabym jakoś inaczej miejsca, w które się wpada, bo czasem nie ma różnicy pomiędzy niższym poziomem a końcem świata, na którym nie da się stanąć.

Poza tym fajny oldskul :)

1
Freja Draco napisał(a):

Chwilę trwało, zanim zajarzyłam, że jak nad głową pojawia się napis "exit", to trzeba nacisnąć strzałkę w górę.

Musisz się zapoznać z treścią wszystkich moich postów w tym wątku, bo wszystko w nich wyjaśniłem.

Skakanie na krawędziach: Jak Kwadratek zbiega z krawędzi platformy (ale częścią podstawy jeszcze na niej stoi) to już nie może się odbić. Dlatego nie przeszłam 3-ciej planszy.

To już zostało dawno temu naprawione – poprawkę opisałem w tym posćie. Źródła zawierające poprawioną wersję znajdziesz z kolei w tym poście.

Ten poziom da się przejść i bez możliwości odbicia z samej krawędzi – wystarczy pamiętać o tym, aby przy skoku nie przywalić głową w platformę nad przepaścią (czyli aby użyć niepełnego skoku). No i wcześniej założenie tego poziomu było takie, aby w ogóle nie dało się tej przepaści przeskoczyć – dopiero sam przez przypadek znalazłem sposób i dlatego zmieniłem jej przeznaczenie. Ale o tym wszystkim dowiesz się z cutscenek i oczywiście z pozostałych postów tego wątku. ;)

0
furious programming napisał(a):

To już zostało dawno temu naprawione – poprawkę opisałem w tym posćie. Źródła zawierające poprawioną wersję znajdziesz z kolei w tym poście.

Pobrałam, uruchomiłam, nie widzę różnicy.

Da się skoczyć:

  • stojąc jedną nogą na krawędzi i wykonując sekwencję: prawo + skok,
  • stojąc jedną nogą na krawędzi i wykonując sekwencję: skok + prawo.

Nie da się skoczyć, biegnąc po platformie i wciskając skok, jak już nie całkiem na niej stoimy.

Ponadto nie wiem, czy rozpęd ma tu jakieś znaczenie czy może skok z miejsca da ten sam efekt.

W każdym razie po 2x próbach nie udało mi się przeskoczyć. Ale mogę zaakceptować jako rozkminnogenną wkurzawkę.

2
Freja Draco napisał(a):

Pobrałam, uruchomiłam, nie widzę różnicy.

Musisz potrenować. ;)

Nie da się skoczyć, biegnąc po platformie i wciskając skok, jak już nie całkiem na niej stoimy.

No takiego bubla to bym dawno zauważył, gdyby istniał. Da się bez problemu skoczyć nawet wtedy, gdy bohater wystaje poza kafel. Ba, wystarczy że stoi na platformie tylko jednym pikselem (właściwie to dwoma, bo w każdej klatce ruchu poziomego pozycja aktualizowana jest o 2px).

Sama zobacz (w dalszej części spowolniłem odtwarzanie):

Błąd dotyczący skoku z krawędzi dotyczył sytuacji, w której skaczemy w ostatnim momencie. To właśnie poprawiłem za sprawą sugestii ze strony @several i @Spine. Tak więc możliwe jest odbicie z platformy, bez względu na to jak dużo ciała bohatera wystaje.

Nie ma znaczenia nawet to, że nad głową jest platforma – choć jest to bardzo trudny skok (wymaga perfekcyjnego wyczucia, co do klatki), to i tak jest możliwy do wykonania, zobacz jak to w zwolnieniu wygląda:

Jeśli w dalszym ciągu masz problem ze skokiem z krawędzi to na pewno nie jest to wina logiki gry, bo tę sprawdzałem wielokrotnie, każdy przypadek z osobna. Już naprawdę nie mam co tam poprawić.

Ponadto nie wiem, czy rozpęd ma tu jakieś znaczenie czy może skok z miejsca da ten sam efekt.

Po wprowadzonej dawno temu poprawce, rozpęd nie ma żadnego znaczenia. W sumie to wcześniej też nie miał – z wyjątkiem sytuacji opisanej wyżej. Ale ten dotyczył sytuacji, gdy skaczemy z samiutkiego kraju platformy.

W każdym razie po 2x próbach nie udało mi się przeskoczyć. Ale mogę zaakceptować jako rozkminnogenną wkurzawkę.

Pograj, poucz się kontroli bohatera. W razie czego czytaj to o czym cutscenki informują. ;)

4

Wrzucam do załączników aktualne źródła projektu do potestowania.

Wprowadziłem jedną modyfikację w klasie okna gry, dzięki której pozbyłem się dodawania własnego komunikatu LM_AFTERSHOW do kolejki komunikatów okna, w celu wymuszenia pokazania okna na ekranie. Wcześniej główny obiekt gry uruchamiał ją w metodzie obsługi tego komunikatu, a teraz robi to bezpośrednio w zdarzeniu TForm.OnShow, uprzednio wymuszając pokazanie okna za pomocą metody ShowWindow z bieżącego widgetsetu. Pozbyłem się też handlera komunikatu LM_LBUTTONDOWN, w którym obługiwane było przesuwanie okna za pomocą myszy – teraz dzieje się to w zdarzeniu TForm.OnMouseDown. Czyli ogólnie pisząc, zamieniłem obsługę komunikatów na zdarzenia.

Kod projektu już wcześniej dało się skompilować np. pod Linuksem, jednak okno gry nie pokazywało się na ekranie (gra działała na niewidocznym oknie). Nie zagłębiałem się w ten temat, jednak obstawiam, że albo problemem było dorzucanie własnego komunikatu do kolejki, albo brak modułu CThreads w głównym module (nie mam doświadczenia z programowaniem na uniksy, więc to jedynie przypuszczenia). W każdym razie całkiem możliwe, że teraz nie tylko da się ten projekt skompilować, ale też i uruchomić. Jeśli w dalszym ciągu będą problemy z uruchomieniem gry po kompilacji na innej platformie niż Windows, to cóż… zawsze pozostaje wine. ;)


Tak więc do załączników dodaję – tak jak wcześniej – wersję release oraz mirror ze źródłami i ze wszystkimi plikami potrzebnymi do kompilacji i tworzenia zawartości. Poziomy są takie jak wcześniej, więc tutaj nie należy się spodziewać nowości (nad nimi teraz pracuję), jednak możecie się pobawić nowym ficzerem, czyli przesuwaniem kamery podczas rozgrywki, a także zobaczyć jak wygląda nowe menu gry i nowy ekran staffu.

3

Jeszcze taka mała aktualizacja, bo dodałem kilka małych usrpawnień.

Pierwszą zmianą jest nieco inny sposób renderowania warstw poziomu. Do tej pory np. podczas renderowania klatki gry (podczas rozgrywki), najpierw malowany był poziom (wszystkie warstwy od razu), następnie na nim bohater, świetliki i bramki, dalej oświetlenie (przyciemnienie klatki) i na koniec liczniki. To powodowało, że bohater zawsze był widoczny, nawet jeśli przechodził przez ukryte przejście (przez platformy). Wygląd bohatera i platform powodował, że podczas takiego przechodzenia przez ścianę, ciało bohatera zlewało się z platformami (jedno i drugie ma ten sam, czarny kolor) i było widać jedynie oczy klocka. Takie było pierwotne założenie, bo wyglądało to całkiem fajnie (oczy w ścianie), ale nie oddawało fizycznych właściwości poziomu.

Dlatego też rozbiłem algorytm renderowania poziomu na dwa mniejsze. Jeśli animacja zmiany warstwy trwa, malowane są wszystkie warstwy, a na nich kolejne obiekty, czyli między innymi bohater. Natomiast w normalnej sytuacji (animacja zmiany warstwy jest wyłączona), najpierw malowane są wszystkie warstwy oprócz bieżącej (tej czarnej), następnie renderowane są obiekty takie jak bohater i świetliki, a na koniec malowana jest bieżąca warstwa. To powoduje, że przykrywa ona bohatera i świetliki, więc podczas przechodzenia bohatera przez ukryte przejście w ścianie, jest on całkowicie niewidoczny (w końcu jest w ścianie) i ma to większy sens. Drugą zaletą jest to, że teraz można lepiej ukryć świetliki, bo te też są renderowane pod bieżącą warstwą. Dzięki temu można je nieco zamaskować detalami platform i tym samym utrudnić ich odnalezienie. Wiele kodu to nie kosztowało – raptem kilka nowych linijek.


Drugą nowością są dwie nowe dyrektywy dla kompilacji warunkowej – jedna pozwala pominąć sceny intra światów (aby móc testować tylko poziomy), a druga pozwala pominąć wszystkie poziomy we wszystkich światach (aby móc testować same intra światów). Kilka linijek kodu, a pozwolą szybciej stworzyć zawartość.


Jeśli o mniejsze poprawki chodzi, to zmniejszyłem wagę ikon dla projektów i ustawiłem ikonkę dla formularza (co prawda i tak nie posiada on ramki, ale to na wypadek gdyby system w którymś swoim narzędziu z niej korzystał). Zreorganizowałem też nieco strukturę katalogów – wyciągnąłem katalog z pomocniczymi grafikami z katalogu źródeł gry.

Pozostałych pierdółek nie ma co wymieniać, bo nie mają większego znaczenia. ;)

1

Na dziwną rzecz natrafiłem.

Po uruchomieniu gry, czas renderowania klatki w pierwszym poziomie tutoriala wynosi mniej więcej 46% (rozmiar zoom3x). Zwiększam okno stopniowo aż do pełnego ekranu, następnie powracam stopniowo do rozmiaru początkowego i czas renderowania wynosi już około 56%. Jeśli to samo zrobię tylko że pomniejszając okno od rozmiaru początkowego do najmniejszego, a następnie powiększę do początkowego to nic się nie zmienia – przed zmianą i po niej utrzymuje się około 46%. Test w trybie debug, poza debuggerem. W wersji release jest podobnie (40% po uruchomieniu, 50% po zabawie z rozmiarem okna).

Problem polega na tym, że zmiana rozmiaru okna nie wpływa na proces renderowania – okno co prawda jest większe/mniejsze, ale rozmiar tylnych buforów cały czas wynosi 224x128 pikseli. Natomiast finalny obraz klatki malowany jest na płótnie okna za pomocą metody Canvas.StretchDraw, bez względu na rozmiar formularza.

Sprawdziłem jak to wyglądało wcześniej i tego typu narzut też istniał, tyle że wynosił góra 2%, a nie 10%. Przekompilowałem stare źródła (są dwa posty wyżej w załącznikach) i to samo – różnica po zabawie z rozmiarem okna wynosi aż 10%. Ustawienia projektu (starsze i obecne) są dokładnie takie same i pomiędzy tymi wersjami źródeł nie ma żadnych różnic w mechanizmie renderowania.


Wygląda na to, że kod wynikowy projektu kompilowanego w Lazarusie 1.8.4 jest inny niż w wersji 2.0.0, pomimo dokładnie takich samych ustawień kompilacji i tej samej wersji samego kompilatora. Najpewniej coś zostało zmienione w bibliotece LCL, czego efektem jest utrata wydajności mojej gry… :/

1

Jeśli chodzi o efekty ekranu, o których wspominałeś we wpisie Dawno temu umieściłem wpis n... , sądzę, że zainteresowałaby Cię gra Riptale ( https://store.steampowered.com/app/616000/ ).
W opcjach można sobie zmieniać filtry obrazu ;) Mógłbyś do swojej gry dorzucić takie coś + opcje dotyczące scanlines.

screenshot-20190211123741.png
screenshot-20190211123753.png
screenshot-20190211123805.png
screenshot-20190211123813.png
screenshot-20190211123822.png

1

@Spine: żeby dodać jakiekolwiek opcje, to najpierw musiałbym zrobić funkcjonalność menu i jego obsługi, a takiego w ogóle nie ma w całej grze. No i pozostaje też kwestia przechowywania ustawień – trzebaby użyć plików lub rejestru, a gra ma być tak skonstruowana, aby niczego nie zostawiała w komputerze użytkownika.

Żeby się za bardzo nie narobić to można dodać wsparcie takiej opcji do linii poleceń, ale ze względu na spore ograniczenia (brak wsparcia jakiegokolwiek post-processingu), nie będę implementować żadnego filtru, który miałby modyfikować końcowy obraz klatki (o rozmiarze okna).

Nie mogę w kółko dodawać nowych ficzerów – muszę w końcu skończyć tworzyć zawartość i puścić ten projekt w świat. Może kiedyś jak mnie najdzie ochota na jego rozwinięcie to rozszerzy się jego funkcjonalność o różne wodotryski. ;)

2

Dawno mnie tu nie było, więc pasuje odświeżyć informacje na temat projektu, bo trochę się zmieniło. :]


Pierwsza ważna rzecz – kod został przeportowany na Uniksy i daje się skompilować na innych platformach niż Windows. Portowanie kodu było kłopotliwe i szło jak krew z nosa, pomimo tego, że tego specyficznego dla innych platform było raptem kilkadziesiąt linii. Klatki nie były renderowane prawidłowo, za co odpowiadają metody wykorzystujące ScanLine do obróbki bitmap. Koniec końców okazało się, że załadowana bitmapa z pliku zmienia format pikseli z natywnego dla Uniksów 32-bitowego na 24-bitowy, przez co metody używające załadowanych z plików bitmap czytały śmieci z pamięci i malowały ”dziwne” kolorowe pasy (albo się wykrzaczał wyjątkiem). Trzeba było dodać prosty mechanizm konwertujący bitmapę tuż po załadowaniu.

Teoretycznie teraz można ten kod skompilować na innych systemach, takich jak Linuks, FreeBSD czy macOS, ale jest pewien haczyk – wydajność jest kilka razy gorsza niż na Windows, więc aby utrzymać płynność działania na tych systemach, trzeba mieć dobry pecet (wystarczy, że będzie w miarę współczesny). Gra została też przetestowana na Raspbianie i choć uruchamiała się i działała, to miała problem z wydajnością (27fps zamiast 60fps, parametry sprzętu nieznane) i z renderowaniem warstw większych poziomów, przez co jest raczej niegrywalna.

Ciekawe jest to, że testerom (jako graczom) wcale nie przeszkadza niski framerate, co mnie mocno zdziwiło.


Jeśli chodzi o samo renderowanie obrazu, to tutaj też pojawiły się zmiany. Pierwsza jest taka, że napisałem swój odpowiednik metody TCanvas.StretchDraw – musiałem to zrobić, bo linuchowa biblioteka do GUI nie umie rozciągać bitmap bez antialiasingu (używa go pomimo jego wyłączenia). Plus jest taki, że mój odpowiednik dość wiernie imituje zachowanie oryginału i przyczynił się do zwiększenia wydajności kodu renderującego o około 10%. Nie dlatego, że działa szybciej niż np. windowsowy StretchBlt, a dlatego, że dzięki niej proces renderowania warstw poziomu jest prostszy – teraz każda warstwa renderowana jest bezpośrednio na buforze ramki, zamiast najpierw na pomocniczym, z którego po pomalowaniu platform na wybrany kolor była kopiowana do głównego bufora. Bufor pomocniczy został całkowicie usunięty, bo już nie był potrzebny.

Zmieniłem też ustawienia projektu i usunąłem wszystkie własne symbole debuggera. Teraz można wyłączyć konkretne sceny podając odpowiednie parametry przy rozruchu, dzięki czemu nie trzeba ciągle rekompilować projektu, aby móc szybciej testować grę. W sumie to w ogóle nie potrzeba do tego źródeł. Tak więc linia poleceń daje o wiele więcej możliwości niż wcześniej.

Poprawiłem też tryb dla speedrunnerów – dodatkowa zawartość dla trybu speedrun jest zawsze dostępna i tryb ten ma osobne outra, w których zawsze pokazywany jest czas rozgrywki, liczony w milisekundach (zwykły zegar cyfrowy w formacie H:NN:SS.ZZZ) oraz w klatkach. Tryb podstawowy natomiast nadal wymaga przejścia gry perfekcyjnie, aby odblokować dodatkową zawartość.

Reszta zmian dotyczy organizacji klas i ogólnie zwiększenia czytelności kodu, tego raczej nie ma co opisywać.


Do załączników dodaję bieżące źródła gry (razem z windowsowym plikiem wykonywalnym) – można się pobawić. Jeśli jest tutaj ktoś, kto używa Lazarusa na innym systemie niż Windows, to fajnie by było gdyby skompilował źródła, sprawdził jak gra działa i dał znać. :]

1

Lazarus 1.8.4. na Linux Mint 19.1 - kompilacja oraz uruchomienie poszło od razu, zero problemów.
Jedyne co mnie zastanawia, to efekt, który widziałem na ekranie. Piszesz o demo gry, ale tak naprawdę nie była to gra, a jedynie napisy końcowe. Pojawiają się gratulacje z powodu przejścia wszystkich poziomów oraz creditsy. Tak miało być?

1

A jak wydajność i jakie parametry sprzętu? Jak możesz to odpal grę z takimi parametrami:

> platformer cheatmode on

i napisz coś więcej. Głównie chodzi o licznik load podczas gry na dowolnym poziomie. ;)

cerrato napisał(a):

Jedyne co mnie zastanawia, to efekt, który widziałem na ekranie. Piszesz o demo gry, ale tak naprawdę nie była to gra, a jedynie napisy końcowe. Pojawiają się gratulacje z powodu przejścia wszystkich poziomów oraz creditsy. Tak miało być?

I tak i nie. :D

Zapomniałem usunąć parametry uruchomieniowe (okno Run Parameters) z ustawień projektu, w których zostały przełączniki dotyczące pomijania wszystkich scen prócz ostatniej, tak aby można było przetestować ekran staffu.

Zaktualizowałem załącznik w poprzednim poście i dodałem źródła bez żadnych parametrów.

2
furious programming napisał(a):

Teoretycznie teraz można ten kod skompilować na innych systemach, takich jak Linuks, FreeBSD czy macOS […]

Tego macOS chwilowo odwołuję – najwyraźniej ten gսpi system nie ma clock_gettime, więc muszę skorzystać z nanosleep. Ale dla Uniksów też skorzystam z nanosleep – gra nie będzie zżerała całej mocy CPU. Pod Windows niestety nadal będzie, bo ten system nie posiada Sleepa o dużej rozdzielczości. :/

2

Ok, świeżutkie źródła gry w załączniku. ;)


Zmodyfikowałem kod zegara, dzięki czemu gra korzysta z systemowej funkcji nanosleep do oczekiwania na kolejną klatkę (oczywiście na Uniksach, bo na Windows nic się w tej materii nie zmieniło). Po drugie, dodałem jeszcze jedną klasę, która przygotowuje ścieżki plików tuż przed ich (ścieżek) użyciem. Dzięki temu wykorzystywane są tylko absolutne ścieżki, zawsze zawierające natywne dla systemu separatory katalogów. Ścieżki bezwzględne są wymagane tylko dla macOS, bo pozostałe systemy potrafią korzystać z relatywnych. No ale już niech wszędzie będzie tak samo.

Dzięki tym dwóm zmianom, źródła powinny się kompilować i działać prawidłowo na wielu platformach i systemach operacyjnych, m.in. na Windows (od XP wzwyż), Linuks, BSD, Solaris czy macOS.


Jeśli ktoś chce to może przetestować – skompilować i uruchomić.

Feedback by się przydał, jeśli chodzi o systemy Uniksowe (na Windows śmiga). Przed zmianą kodu zegara wszystko na nich działało prawidłowo, ale nie wiem jak z nowym zegarem, bo choć źródła ludzie pobierali, to nikt nie dał znać co i jak. No i na macOS demówka nie była w ogóle testowana, więc co do tego systemu nie mam pewności… :/

1

Mała aktualizacja – na macOS kompiluje się i działa, ale okno jest niewidoczne… :D

2

Co do powyższego posta, to zrezygnowałem z portowania kodu na macOS – nie mam nerwów do tego systemu, a i widgetset jest w pewnych miejscach niekompletny, więc nie będę tracił czasu na szukanie innych rozwiązań i oczekiwanie na testy i feedback.


Jedną rzecz dodałem do kodu. Do tej pory bramki były niewidoczne, a po wejściu na nie wyświetlała się etytkieta z ich przeznaczeniem. Czyli normalnie nie było wiadomo gdzie one się znajdują – detale platform miały sugerować ich pozycję na planszy, a po wejściu na bramkę, etykieta miała informować o tym że stoi się w bramce i można jej użyć. Tyle że i tak trudno by było je znaleźć, więc trzeba było coś z tym zrobić.

Aby zawsze było wiadomo gdzie są bramki, zawsze wyświetlana jest animowana, skacząca strzałka. Jeśli bramka stoi na ”podłodze” to strzałka wyświetla się nad nią, jeśli jest na suficie to strzałka jest pod nią, a jeśli bramka jest w powietrzu to wyświetlane są dwie strzałki – jedna nad i jedna pod. Animacja jest prosta – byle się coś ruszało i przyciągało wzrok. Po wejściu w bramkę wyświetlana jest etykieta, tak jak wcześniej.

Deep Platformer — gate markers.png

Wyjątkiem są bramki zapisu pozycji – te są dostępne tylko jeśli orientacja bohatera jest zgodna z orientacją bramki. W przeciwnym razie bramki nie da się użyć, a strzałka nie jest wyświetlana w ogóle.

Oczywiście wszystkie bramki będą dodatkowo ozdobione detalami platform.


W załączniku dodaję krótkie nagranie przedstawiające nowy ficzer. :]

2

Aktualizacja. :]


Dodałem ostatnią brakującą część, czyli kod w klasie zegara, pozwalajacy oszczędzać moc procesora. Teraz na platformie Windows gra nie zżera już całej dostępnej mocy jednego rdzenia, dzięki poprawieniu obliczeń oraz oczywiście użyciu procedury Sleep. Ale aby móc precyzyjnie zamrażać działanie gry pomiędzy klatkami, pętla zjadająca też jest używana – tyle że znacznie rzadziej niż wcześniej, stąd oszczędność mocy.

Jednak wykorzystanie takiego sposobu tworzenia przerw między klatkami jest mniej dokładne i czasem powoduje wahania klatkażu, dlatego w kodzie zegara pozostawiłem kod pozwalający pominąć użycie procedury Sleep i – tak jak wcześniej – przerwy wykonywać wyłącznie zżerając całą dostępną moc. To w jaki sposób ma się zegar zachowywać można zdeterminować parametrami wejściowymi.

Wykorzystanie ”lekkiego” zegara, oszczędzającego procesor (wartość domyślna):

> platformer.exe clock light

Użycie precyzyjnego zegara, wykorzystującego pełną moc:

> platformer.exe clock precise

Drugim ficzerem jest przystosowanie zegara do luźnego wykonywania klatek w momencie, gdy gra jest zatrzymana (za pomocą klawisza F2 lub gdy okno gry jest nieaktywne albo zminimalizowane). W takim przypadku logika gry oraz renderowanie klatek nie są wykonywane – sprawdzany jest jedynie input oraz okno jest przemalowywane (używając bieżącej klatki). No i ten ficzer sprowadza się do użycia Sleep(100) w takiej sytuacji, co zmniejsza zużycie mocy procesora do poziomu kilku procent.


Jeśli chodzi o kod źródłowy to raczej już nic się nie zmieni, co najwyżej kosmetyka. Bieżące źródła dodaję do załączników i zabieram się konkretnie za tworzenie zawartości.

3

No dobra, jeszcze jedna aktualizacja kodu – i jeszcze jedna przede mną. ;)

Dodałem kilka funkcji pomagających mi w debugowaniu oraz z dodatkowymi informacjami – oba dostępne w trybie cheat mode. Po pierwsze, dodałem jeszcze jeden licznik, pokazujący rozmiar danych na stercie. Przynajmniej nie muszę używać menedżera zadań.

Drugi ficzer jest bardziej przydatny, bo są to hinty dotyczące używanych dodatkowych opcji debugowania, których to włączenia/wyłącznia nie widać na ekranie (np. zmiana framerate'u) lub w określonych sytuacjach mogą nie być widoczne (np. pokazanie bramek lub ukrycie świetlików). Teraz zawsze wiadomo kiedy te opcje są używane, bo wyświetla się w lewym dolnym rogu hint z krótką informacją. Oczywiście w formie animowanej – rozwija się, a na koniec zwija. Hinty są permanentne (globalne) – są pokazywane niezależnie od scen.

Deep Platformer — new look.png

Oprócz opcji pomagających debugować grę, dodałem jeden wodotrysk. Skoro gra rozpoczyna się animacją imitującą włączanie kineskopowego telewizora z szumem, przełączaniem kanałów i włączaniem konsoli, to gra powinna się kończyć jakąś animacją w tym stylu. Dorobiłem więc animację wyłączania telewizora, która jest odgrywana po zamknięciu gry (najpierw odtwarzana jest krótka animacja, a po niej okno gry jest niszczone). Wyszło przesłodko.

I w sumie to dobrze, że postanowiłem zrobić tę końcową animację, dlatego że dzięki niej namierzyłem błąd w klasie filmu, czyli w TMovie. Polegał on na tym, że przejście do kolejnej animacji (w obrębie jednego filmu) nie uwzględniało inkrementacji indeksu klatki, przez co animacja zawsze trwała o jedną klatkę za długo. Niby to tylko 1/60 sekundy, więc kto by to zauważył… No ale film składający się z jednoklatkowych animacji trwał dwa razy dłużej niż powinien, co już było baaardzo widoczne – dlatego trzeba było to poprawić. :]

3

Ściągnąłem projekt, by pooglądać źródła. Odpalam i pograłem chwilkę. Po pierwsze jestem zdziwiony, ale gra serio jest grywalna i ma potencjał. Lubię takie gry. Ciekawy pomysł. Mam nadzieję, na wiele poziomów, może system punktów i wysyłki do globalnego rankingu? Przydała by się też muzyczka. Szkoda generalnie, że taki mały ekran, i nie można powiększyć okna. Co do skakania nad przepaścią to zacząłem się wkurzać, aż ktoś mi powiedział, że mam ukryte przejście - a ciągle spadałem - fajne zagranie ;) Niemniej chciałem wyłączyć - nie wiedziałem jak bo esc robi pauzę więc nacisnąłem alt+F4 to spowodowało crash - to chyba do poprawki. Mam nadzieję na dalszy rozwój.

0
somedev napisał(a):

Po pierwsze jestem zdziwiony, ale gra serio jest grywalna i ma potencjał.

Pograć się da, ale niezbyt wiele jest w tej gierce do zrobienia – ot szukanie świetlików i wyjścia. Całość urozmaica wielowarstwowość poziomów i możliwość zmiany kierunku siły przyciągania.

No ale to tylko tyle. Nie ma np. ruchomych platform, przełączników, specjalnych znajdziek, nie ma też przeciwników i bossów. Wszystko dlatego, że to nie miała być pełnoprawna gra, a jedynie apka do sprawdzenia, czy da się zrobić ”lepszą” gierkę bez żadnej biblioteki do tworzenia gier. No i jak widać da się. ;)

Mam nadzieję, na wiele poziomów […]

Będzie mniej więcej 20-30, dokładnie nie wiem – zależy od pomysłów i czasu na ich robienie.

[…] może system punktów i wysyłki do globalnego rankingu?

Oj nie. Punktów jako tako gra nie liczy – cała rozgrywka opiera się o liczbę złapanych świetlików i liczbę straconych żyć. Na tej podstawie gra pozwoli odblokować dodatkową zawartość, czyli jeszcze jeden świat z kilkoma poziomami (bardzo trudnymi). I również na tej podstawie gra wybiera odpowiednią animację dla outro z informacją o tym czy udało się przejść grę na jednym życiu i czy nie pominięto świetlików.

Dodatkowo jest też tryb speedrun, który charakteryzuje się zawsze odblokowaną dodatkową zawartością i innym zestawem animacji dla outro, w których oprócz podania wyników, podaje też czas przejścia gry w postaci zegarka cyfrowego oraz liczby klatek:

Deep Platformer — speedrun time.png

Dodałem ten tryb głównie dlatego, że może kiedyś znajdą się chętni do pobijania rekordów (może nawet GDQ). A że kosztował mnie góra kilkanaście linijek kodu to warto go było dodać. Natomiast strony z rankingami nie ma sensu robić – jest przecież https://www.speedrun.com/

Przydała by się też muzyczka.

Tej na pewno nie będzie. Wszystko dlatego, że z założenia projekt ma nie używać żadnej dodatkowej biblioteki i żadnego dodatkowego pakietu (z rozszerzeniem .lpk), a sam pakiet LCL nie posiada multiplatformowych funkcji/API do odtwarzania kilku dźwięków jednocześnie. W sumie to w ogóle takich funkcji nie posiada (multiplatformowych), nawet do odtwarzania jednego dźwięku.

Szkoda generalnie, że taki mały ekran, i nie można powiększyć okna.

No tutaj dowaliłeś – użyj nienumerycznych klawiszy + i -. Gra obsługuje kilka rozmiarów okna (w tym dwa tryby pełnoekranowe) i wspiera stanowiska wieloekranowe. Okno można przesuwać za pomocą LPM.

Wiem że to niepopularne, ale polecam jednak otworzyć plik readme.txt i zapoznać się z jego zawartością. Nie tylko można się z niego dowiedzieć czym jest ta gra i o co w niej chodzi, ale też dowiedzieć się:

  • jaka jest klawiszologia,
  • jak włączyć tryb speedrun i czym się on charakteryzuje,
  • jakie opcje są dostępne do konfiguracji z linii poleceń,
  • jak włączyć cheat mode i pobawić się w boga,
  • jakie są wymagania systemowe i ograniczenia/problemy,
  • jakie są dodatkowe narzędzia (dla sceny moderskiej).

Co do skakania nad przepaścią to zacząłem się wkurzać, aż ktoś mi powiedział, że mam ukryte przejście - a ciągle spadałem - fajne zagranie ;)

Ten poziom samouczka ma z założenia poinformować gracza o tym, że poziomy mogą posiadać ukryte przejścia. Takie przejścia pozwolą dojść do ukrytych świetlików. Tak więc w podstawowym trybie, aby móc odblokować dodatkowy świat i pograć jeszcze trochę, trzeba będzie złapać wszystkie świetliki, czyli trzeba będzie znaleźć takie ukryte przejścia.

Przy czym tę przepaść da się bez problemu przeskoczyć, używając skoku regulowanego – sam zobacz.

Natomiast cutscenki z założenia mają być nieco wredne/ironiczne, tak aby wkurzać gracza uszczypliwymi docinkami. Być może dodam nieco bardziej wnerwiające cutscenki, ale tylko dla specjalnych przypadków – jako easter eggi, dla bardzo słabych lub dociekliwych graczy.

Niemniej chciałem wyłączyć - nie wiedziałem jak bo esc robi pauzę […]

readme.txt – sam F4 wystarczy. :P

[…] więc nacisnąłem alt+F4 to spowodowało crash - to chyba do poprawki.

Okienko które się pojawia po wyłączeniu gry to okienko z informacjami na temat użytej pamięci, wyświetlane automatycznie przez moduł HeapTrc. Bardzo mylące jest to, że tytuł okna to Error – to sugeruje że wystapił błąd. No ale tak to zrobili, więc cóż… Przy okazji możesz z niego wyczytać, że nie ma wycieków pamięci, co jest przeze mnie spodziewane.

To okienko wyświetlane jest jedynie w przypadku kompilacji projektu jako Debug – wersja produkcyjna nie będzie używała modułu HeapTrc, a więc to okienko nie będzie się pokazywało.

Mam nadzieję na dalszy rozwój.

Chciałbym ten projekt rozwijać, jednak ze względu na inne projekty (w tym również otwarte), zrobię pierwszą konkretną wersję i na tym póki co poprzestanę.

Natomiast liczę na to, że znajdą się moderzy i go przerobią/rozwiną. No i aby każdy chętny mógł stworzyć własną wersję tej gry (nieco przerobioną, np. tylko z innymi poziomami lub dużą, mocno rozwiniętą, również jeśli chodzi o logikę), dostępne będą źródła gry oraz źródła pięciu konsolowych narzędzi do generowania zawartości (plików binarnych z fontami, poziomami, ekranami tytułowymi i cutscenkami/animacjami). Udostępnię też snapshot deweloperski, ze wszsytkimi narzędziami i wszystkimi plikami potrzebnymi do budowy zawartości (z których sam korzystam).

0

Będzie mniej więcej 20-30, dokładnie nie wiem – zależy od pomysłów i czasu na ich robienie

A czy nie myślałeś, żeby zaangażować wolontariuszy do tworzenia leveli?

0

Raczej nie – w końcu nadal nikt nie wie (bo nikt nie widział) jak mają wyglądać docelowe poziomy. :]

Do tej pory wrzucane wersje gry posiadały poziomy z platformami, których kształt jest zgodny z hitboksami, czyli zbudowane były z kwadratów. No ale finalnie takie nie będą – kształty będą nieregularne, z różnymi detalami.

0
furious programming napisał(a):

Raczej nie – w końcu nadal nikt nie wie (bo nikt nie widział) jak mają wyglądać docelowe poziomy. :]

W moim ulubionym indyku: "Po prostu Łoś" autorzy oryginalne zrobili dwa zestawy poziomów i dorzucili edytor dzięki któremu powstało ich jeszcze dwieście a gra żyła (co prawda w niszy) przez dobrych kilkanaście lat.

0

A w World of Goo jest skończona ilość poziomów. Ale od samego początku mają one wysoką jakość. Gra wciąż żyje, lata po premierze ;)

Jeśli edytor poziomów nie obsługuje skryptowania, to nikt nie zrobi lepszych leveli niż sam developer. Bo programista może oprócz wyglądu, może oprogramować nieprzewidziane wcześniej akcje.

0

W moim platformerze będzie skończona liczba światów i poziomów. Aby moderzy mogli dodawać nowe lub przerabiać istniejące, będą mieli do dyspozycji odpowiednie narzędzia. Czyli będą mieli te same możliwości co ja.

Spine napisał(a):

Jeśli edytor poziomów nie obsługuje skryptowania, to nikt nie zrobi lepszych leveli niż sam developer.

Jako takiego edytora poziomów nie będzie, ani wbudowanego, ani w postaci zewnętrznej aplikacji – wszystko dlatego, że po prostu nie mam na tyle czasu. Być może w przyszłości taki dorobię, ale nie mam pojęcia kiedy i czy w ogóle to nastąpi.

Bo programista może oprócz wyglądu, może oprogramować nieprzewidziane wcześniej akcje.

Silnik tego platformera nie wykorzystuje skryptów, więc każdy może zrobić to samo co ja. Zresztą wcale nie jest powiedziane, że sam zrobię najlepsze poziomy jakie tylko się da. Być może ktoś będzie potrafił zrobić lepsze i zmodowana wersja będzie jeszcze ciekawsza niż moja – czego sobie życzę. :]

Ogólnie chodzi o to, że sam zrobię taką podsawę, która będzie na tyle dobra, aby cieszyła się zainteresowaniem i dało się w nią przyjemnie pograć. Natomiast zrobiłem ją w taki sposób, aby można było dokładać zawartość (używając dedykowanych generatów binarek) i aby rozszerzać logikę (korzystając z otwartego kodu i prostoty jego struktury).

0

@Bruno(M): ale co „super sprawa”? Platformer, czy to co linkujesz?

0
furious programming napisał(a):

@Bruno(M): ale co „super sprawa”? Platformer, czy to co linkujesz?

Platformer. wiesz ja nigdy nie siedziałem w grach. przyznam tobie, że od zawsze algorytmy w grach mnie przerastały. Ja wolę statystykę.

0
Bruno(M) napisał(a):

przyznam tobie, że od zawsze algorytmy w grach mnie przerastały.

A próbowałeś jakąś napisać? Sam spróbowałem – i tak zwykły PoC rozrósł się do sporego projektu. ;)

Ten platformer jest inny niż typowe gry, bo zamiast odmierzać czas (jako delta), zlicza klatki i wykonuje dane czynności przez zadaną ich klatek. Rozwiązanie bardzo proste – łatwe do zrozumienia i zaprogramowania.

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