[libGdx] Małym krokami do przodu

Kolejne godziny w libGdx za mną. Udało mi się znaleźć przyczynę podwójnego ładowania ekranu gry (błąd widoczny jest w poprzednim wpisie) i teraz ludzik potrafi już samodzielnie chodzić po całej dostępnej planszy.

Uczenie się libGdx  z książki bywa jednak uciążliwe. Autor przeskakuje całe bloki kodu od tak sobie lub nagle do prawidłowego działania aplikacji potrzebny jest kod, który jest 10 stron dalej. W efekcie co chwila gra przestaje całkowicie działać. Szczęśliwie cały projektu  dostępny jest on-line, więc jeśli czegoś nie znajdę w treści książki to jest w dostępnym sieciowym zasobie. Tak czy inaczej, gdyby nie posiadane doświadczenie w programowaniu, gra zwyczajnie by nie działała.

Druga rzecz, jaka rzuciła mi się w oczy w czasie pracy z książką, to nieopisywanie w części przypadków dlaczego coś ma być wykonane w ten, a nie inny, sposób. Niektóre użyte w grze rozwiązania architektoniczne (lub programistyczne) nie są wystarczająco wytłumaczone. Odniosłem także wrażenie, iż autor pisze kod w dany sposób ponieważ robił tak do tej pory, ale nie wie właściwie dlaczego. Jako twórca książki można by z przekąsem powiedzieć Ależ to rozwiązanie jest oczywiste, powinieneś je już znać!, jednak po przerobieniu ponad 150 stron uważam, że część technik powinna być opisana trochę szerzej. Nie ma problemu ze znalezieniem odpowiedzi w internecie, ale jeśli autor używa jakiegoś elementu biblioteki to może warto wspomnieć dlaczego. Tego przynajmniej oczekiwał bym  od książki.

Mimo powyższych uwag pisanie dosyć skomplikowanej gry z książką przed oczami jest ciekawsze niż klepanie prostych, zwykle jednoklasowych, przypadków użycia libGdx. Zdecydowanie nie jest to jednak pozycja dla osób, które do tej pory nie miały wiele wspólnego z programowaniem.

Wojownik, libGdx i kolejna gra

To już ponad miesiąc od ostatniego wpisu! Patrząc na moją dotychczasową aktywność trzeba przyznać, że się opuściłem. Główną przyczyną takiego stanu rzeczy jest (powoli przechodzące) przemęczenie spowodowane pisaniem Wojownika Autostrady i nauką Angulara. Każdy ma pewien próg, powyżej którego głowa przestaje przyjmować wiadomości i potrzebuje odpoczynku.


 
Chciałbym pokazać wam statystyki użycia strony zawierającej Wojownika Autostrady (po prawej). Oczywiście największy pik zainteresowania nastąpiłwraz z pojawieniem się gry w Internecie i informacji o niej na stronie Kryształów Czasu oraz na profilu fb portalu czy tu na blogu. Z upływem czasu zainteresowanie znacząco spadło, ale jest to zrozumiałem. Po prostu ci - którzy mieli pograć - pograli :).

Podejrzewam też, że nikt nie dotarł do ostatniego - 350 - paragrafu ponieważ gra jest po prostu morderczo trudna. Nie zrobiłem niestety zapisu statystyk odwiedzin poszczególnych paragrafów, a powrót do programowania w PHP, co byłoby nieodzowne,  aby uzyskać te dane, uważam za średnie rozwiązanie. Wystarczy rzeźba w javascript.
Trzeba by (sugestia czegoja) wprowadzić tryb łatwy lub ogólnie możliwość wyboru poziomu trudności. 


A jakie mam plany?
Atakuje Androida oraz bibliotekę graficzną libGdx! I mam już pierwszy mały sukces. Poniżej zrzut z tworzonego na bazie książki prostego rpg-a. Na razie jako aplikacja desktopowa, którą docelowo będę chciał zportować do Androida. Zrzut jest statyczny (może w końcu nauczę się robić gify...) ale spieszę powiedzieć, że widoczny tam wojownik reaguje na naciśnięcie klawiszy kierunkowych i posiada animację kierunkowego ruchu.  I na razie nie wiem dlaczego mapa ładuje się podwójnie :P

Naukę libGdx i pisania gier opartych na tej bibliotece opieram o książki: Mastering LibGDX Game Development, Android Game Programming by Example oraz Killer Game Programming in Java. I wszystko oczywiście w javie. Normalnej javie :)
Generalnie czeka mnie trochę nauki, ale efekty są zachęcające.
p.s.
A moglibyście spytać dlaczego nie skorzystam z Unity? Przecież niemal 80% gier dostępnych na Androida powstałą w tym języku. Cóż nie znam C# :P I nie chce mi się go uczyć :P

Wojownik Autostrady Piekło na Autostradzie

Dzisiaj mamy niezbyt okrągłą rocznicę urodzin Joe Devera (dokładnie  62 rocznicę). Pisarza znanego
w Polsce głównie z cyklu gier paragrafowych opisujących losy Cala Phoenixa czyli Wojownika Autostrady. Dever ma na koncie dużo więcej gier paragrafowych z czego kilka jest o wiele bardziej rozbudowanych fabularnie niż przygody Cala. Więcej informacji znajdziecie na angielskiej wersji wiki dotyczącej Joe Devera.

Ale nie o  tym miało być.

Z dniem dzisiejszym ogłaszam zakończenie prac nad większymi elementami silnika paragrafowego utrzymującego interaktywną wersję Wojownika Autostrady.  Przy okazji usunąłem ekran witający informacją o beta testach. W pełni uruchomiłem wszystkie przewidziane w projekcie funkcjonalności i oddaję teraz tę grę w wasze ręce. Mam nadzieję, że przechodzenie jej dostarczy wam tyle samo radości jak mi przerobienie jej w wersję on-line.
Droga do zakończenia projektu była dłuższa niż się spodziewałem, ale cieszę się, że podjąłem się tego zadania.
Wiec jeśli tu jesteś to zmierz się z przeciwnościami losu jakie czekają każdego kto chce przekroczyć spalone słońcem i zniszczone wojną bezdroża Teksasu jako:

WOJOWNIK AUTOSTRADY

interaktywna paragrafówka on-line

p.s.
Wszelkie uwagi nadal są miło widziane. Drobne poprawki będę wprowadzał na bieżąco.
Gra zostanie na podanym adresie do końca świata i jeden dzień dłużej , czyli do momentu w którym będę płacił za domenę :)  .

Dead line się zbliża

Już niedługo (12.02) założony termin zakończenia prac i ostatecznej prezentacji gry, a ja siedzę i dorabiam polsko-angielskie etykiety.

I jeszcze sporo przede mną. Mam nadzieję, że wyrobię się do poniedziałku .

Angularowy Wojownik beta testy ?

Pojawił się propozycja od osób, które widziały grę w aktualnej wersji, aby wystawić ją  do testów.  Takie typowe beta-testy przed ostatecznym wdrożeniem i zanim program zdobędzie wszystkie założone możliwości.

Po rozważeniu pomysłu powoli skłaniam się ku tej propozycji.  Jedyna trudność to postawienie gry w miejscu, do którego miałbym łatwy dostęp czyli serwer z ftp i zarejestrowana domena. A takowego miejsca w tej chwili nie mam :D  (co, patrząc na to co robię na co dzień, jest dziwne :) ) .

W najbliższych dniach zamierzam więc wykupić domenę oraz jakąś lokalizację w sieci, w której będę mógł zająć trochę miejsca. Przy okazji wystawię jakiegoś redmina czy inną jire / bugzille (heheheh)  na potrzeby samego procesu zgłaszania błędów przez zainteresowanych użyszkodników :).

A paragrafówka spytacie...
Poprawiam różne drobne błędy. To tu to tam czasem coś się przewróci. Dorobiłem kilka prostych ekranów powitalno - wprowadzających, wyciąłem sporo zbędnego kodu (mój kod nie przeszedł mojego code-review :D) i jeszcze drugie tyle muszę wyciąć, zmieniłem trochę wygląd menu postaci (teraz prawie mi się podoba) i dodałem rysunki.
Przez chwilę korciło mnie, aby całe menu postaci zrobić na html-owych canvas, ale na szczęście powstrzymałem swoje absurdalne zapędy. Patrząc na moją prędkość nocnego pisania kodu wydłużyłoby to proces powstawania gry o kolejny miesiąc :D

Pisanie kodu w nocy idzie mi dużo, dużo wolniej niż w dzień. Nie przeskoczę jednak tego problemu pracując na pełny etat. Koniec marudzenia, niedokończone rozwiązania wołają!

I randomowy zrzut :), przecież notka bez tego to jak brak notki.

Menu postaci wygląda już trochę inaczej ale co tam:)

Angularowy Wojownik Autostrady - rzuty kością

Ten wpis wrzucam w nocy ponieważ jestem z siebie nadzwyczaj zadowolony. W końcu udało mi się połączyć mój kod z kodem generującym rzut kością. Oczywiście okazało się, że wystarczy dopisać dosłownie kilka linijek, żeby całość zaczęła prawidłowo współpracować.
 Zanim to jednak zrobiłem minęło dobre 2-3h siedzenia przy kodzie i szukania rozwiązania.
Poniżej efekt

Wejście do paragrafu z testem. Wiać możliwość rzutu kością.

Po kliknięciu ikonki kostki wykonywany jest rzut z pomocą użytej biblioteki. Oczywiście kość obraca się i obija o granicę tak, aby była widoczna na ekranie. Pod kością widać wynik testu na który składają się wartość umiejętności (tu strzelanie równe 5) + bonus (tu +0 i docelowo bonusy =0 nie będą pokazywane) + rzut kostką ( tu oczywiście równe 9)

Na koniec, jak klikniemy ponownie na ekranie, kostka znika i ładowane jest wyjście wynikające z sumy przeprowadzonego testu.

I jeszcze jedna rzecz. Mapa została zintegrowana z menu postaci. Nie działa jeszcze skalowanie, ale efektem mogę się już pochwalić:

Angularowy Wojownik Autostrady cd...

Liczyłem na to, że uda mi się ukończyć grę na święta, aby zrobić prezent tak sobie jak i ewentualnym graczom. Wszelkie znaki na niebie i ziemi wskazują jednak, iż jest to termin nierealny :D Gdy siadałem do projektu nie spodziewałem się, że zajmie tak dużo czasu.
Nie mam jednak powodów do załamywania rąk. Dzięki włożonej w kod pracy nauczyłem się kilku nowych rzeczy, które w przyszłości wielokrotnie wykorzystam.
Dość marudzenia! Trzeba napisać trochę kodu.

Rozbudowuje dwa spore urozmaicenia, bez których gra spokojnie by się obeszła, ale nie była by tak fajna jak mogła by być. Są to pomysły, które pojawiły się przed stworzeniem pierwszego pliku gry.

Pierwszy z nich to możliwość rzucenia kostką k10 na ekranie gry. Taką generowaną w pełnym 3d ze wsparciem fizyki, odbijania się i toczenia. Wykorzystałem rozwiązanie stworzone z pomocą biblioteki Three.js (https://threejs.org/) przez Antona Natarowa (http://www.teall.info/2014/01/online-3d-dice-roller.html)  Napisał i udostępnił spory kawałek kodu js, który umożliwia rzuty wirtualną kostką. Chłopie - wielkie dzięki!
Musiałem zmodyfikować kod na swoje potrzeby oraz pogodzić nie-angularowy sposób pisania z angularowym. W tej chwili połączyłem swoje skrypty silnika paragrafówki ze skryptem generującym kostki . Brakuje jeszcze kilka szlifów, żeby oba rozwiązania w pełni ze sobą współpracowały. Sam efekt jest naprawdę fajny.
Poniżej zrzut ekranu z efektem działania powiązanych skryptów.

Trochę z czapy rzut 3k10

A tutaj już sensowny rzut na wytrzymałość

Druga rzecz nad, którą siedzę na zmianę z rzucaniem kostkami w 3d to interaktywna mapa gry. Chciałem, aby była możliwość zobaczenia jak nasz bohater przemieszcza się nie tylko w wymiarze tekstowym, ale także graficznym. W efekcie w oparciu o html-owy element canvas zaprojektowałem i niemal ukończyłem okno dialogowe (docelowo będzie stanowił jedną z zakładek charakterystyk postaci), na którym nanoszona jest aktualna pozycja gracza zgodna z jego postępami w grze paragrafowej. Mapa jest skalowalna, zawiera dane bohatera, można ją przesuwać. Sam plik mapy pochodzi ze strony amerykańskiego projektu Aon, którego uczestnicy otrzymali zezwolenie od samego Joe Devera na umieszczenie jego paragrafowych książek w Internecie! Strona projektu znajduje się tutaj: https://www.projectaon.org/ i zawiera chyba wszystkie wydane gry Joe Devera. Dostępne są w formie elektronicznej i oczywiście po angielsku. 
Dla poprawienia odbioru mapa przykrywana animowanym szumem, który daje lekko falloutowy efekt.  Poniżej zrzut ekranowy.

W tej chwili jeszcze nie zdecydowałem czy ten szum zostanie.  Niby nie jest męczący ale ...


 p.s.
Śmiechem żartem - jako że  testuję paragrafówkę w Chromie dopiero ostatnio wpadłem na pomysł, aby sprawdzić czy silnik działa w InternetExplorerze. Okazało się, że kilka rozwiązań wymaga specjalnego potraktowania (np. brak w IE funkcji Object.assign()), poprawiłem kilka drobnych błędów i proszz. W IE też można grać

Paragrafówka przygoda w Angularze cz5 - KONIEC PRAC

Udało się! Paragrafówkowy silnik (o tyle o ile może to powiedzieć autor jakiegokolwiek programu) ukończony. Możecie się z nim zapoznać grając pod tym linkiem:

Przygoda barbarzyńcy Sladuma

Życzę powodzenia w odkrywaniu sekretów świątyni Seta.

p.s.
W razie uwag, błędów cóż - piszcie :P

Paragrafówka przygoda w Angularze cz3

Powoli pracę nad angularowa paragrafówką dobiegają końca. Od ostatniego wpisu poprawiłem wiele niedoróbek, dodałem obsługę warunkowego wyłączania wyjść/wejść do paragrafów dzięki czemu np. nie da się dwa razy przeszukać pomieszczenia czy dwukrotnie wejść w tryb walki z raz pokonanym przeciwnikiem.

Po drodze powstała obsługa pułapek i kilka mechanicznych elementów gry. Niewiele zostało do dopisania (min.: wliczanie bonusów z przedmiotów w walce czy leczenie się).
Nadal nie ma modalnego okienka ekwipunku postaci! Nie udało mi się pokonać problemów z wyświetleniem głupiego modalnego diva ze wsparciem Angulara. W sieci znalazłem co najmniej kilkanaście przykładów opisujących jak to zrobić, ale żaden te z tych, które użyłem nie zadziałał. W końcu i to zaziała ale sądziłem że jest to rozwiązanie przysłowiowo dostępne prosto z pudełka.
Fajnie działa opcja sprawdzenia czy dane wyjście z paragrafu jest dostępne lub niedostępne. Efekt jest lepszy niż sobie obiecywałem po tym rozwiązaniu. Pokaże to na przykładzie działających paragrafów.
W ramach oryginalnego paragrafu 27 definicja była następująca:

Widać, że ilość obsługiwanych opcji jest duża i ew. gracz może po prostu ominąć te, które są dla niego niewygodne.
Dzięki wprowadzeniu kilku mechanizmów obsługiwanych z poziomy angulara pierwsze podejście do paragrafu wygląda następująco:

Co się stało? Otóż pojawiły się następujące rzeczy:

• Sprawdzane jest czy postać posiada w ekwipunku klucz do drzwi
• Jeśli go nie posiada, blokowane są wyjścia odpowiadające za obsługę klucza

A teraz chwilę pozwiedzaliśmy dostępne paragrafy (i nie wyważyliśmy drzwi) i mamy w ręce klucz pasujący do drzwi. Dostępne wyjścia prezentują się następująco:

jednocześnie dzieje się coś dodatkowego. Bez klucza (lub wyważenia drzwi) nie można było wejść do świątyni, ale i przejście ze środka świątyni na dziedziniec było zablokowane! (paragraf 11)

jednak w momencie gdy trafimy do paragrafu 11 z kluczem zdobytym na dziedzińcu (lub też wyważyliśmy drzwi) zmienia się ilość dostępnych możliwości:

Efekt jest przyjemny i intuicyjny. Chciałbym już oddać to co napisałem, ale jeszcze muszę się powstrzymać. Nie wszystko działa tak jak trzeba.

Paragrafowa przygoda w Angularze cz2

Wbrew pozorom prace nad angularowym silnikiem gry paragrafowej trwają dalej. W tej chwili dotarłem do momentu, w którym kod idzie w logikę obsługi  działania paragrafów niż naukę Angulara. Oczywiście staram się jak mogę wprowadzać rozwiązania angularowe, ale nie oszukując - nie da się wszystkiego napisać tak, aby powstało tylko na angularowy sposób.

W tej chwili próbuje nauczyć się jak wygenerować modalne okienko potrzebne do wyświetlania  stanu ekwipunku postaci. Już sprawiło mi to sporo kłopotów i ...  nadal nie działa.
Kolejny element framweworka jaki chce zastosować to fabryki do tworzenia źródła danych (teraz tworzonego statycznie w jednym z plików) oraz niemal najważniejszy element Angulara czyli dyrektywy. Tylko co ja tą dyrektywą będę robił to nie wiem :).

Takie podejście to trochę przerost formy nad treścią jednak bez użyci możliwie dużej ilości wbudowanych elementów frameworka nie da się go nauczyć na trochę bardziej niż podstawowym poziomie.

 Sam silnik w międzyczasie od ostatniego wpisu otrzymał kilka nowych funkcjonalności. W tym:

• testy warunkowe
• testy kumulatywne
• zbieranie przedmiotów po testach i po walce (przykład na zrzutach)
  

  

  Przed walką

  
  

  

  Po walce

• sprawdzenie czy postać posiada przedmiot potrzebny do przejścia paragrafu
• zapis historii poruszania się po paragrafach
• kilka poprawek blokujących wyświetlanie paragrafów
• dużo innych drobnych poprawek

Pojawił się już efekt kuli śnieżnej - drobna zmiana w miejscu X powoduje ZŹŻ zmian w 3 innych miejscach. Powoduje to standardowe zamieszanie - rzeczy które działały tydzień wcześniej nie działają dzisiaj.

Poważnie rozrosła się definicja pojedynczego paragrafu. Pierwotnie był tekst paragrafu plus linki przekierowań. Wraz z dodawaniem nowych funkcjonalności poziom komplikacji zmienił się i trzeba pamiętać o nowo dodanych rzeczach oraz o tym jak wpłyną na to co już jest napisane.

Poniżej przykłady jak wygląda definicja paragrafu w zależności od tego jak dużo operacji udostępnia.

Definicja zwykłego paragrafu z jednym przekierowaniem

new Paragraf({
    number: 2,
    text: '<p>Zajmujesz miejsce woźnicy. Brama otwiera się jak tyko do niej podjeżdżasz</p>',
    exits: [new Redirect({
        target: 30,
        text: '<p><a  class="more-link"  href="#/paragraf/30">Na dziedzińcu strażnicy podchodzą do Ciebie</a></p>'
    })],
    enemy: [],
    tests: [],
    treasure: []
}),

A tutaj mamy definicję paragrafu z wrogiem i możliwością zdobycia - po walce - przedmiotu, miecza do rąk dwóch. Oczywiście obiekt mieczDwureczny jest odpowiednio budowany wcześniej:

new Paragraf({
        number: 142,
        text: '<p>Paragraf na potrzeby podniesienia przedmiotu po walce</p>',
        exits: [
            new Redirect({
                target: 144,
                text: '<p><a  class="more-link" href="#/paragraf/144">Pokonałeś wroga</a></p>',
                type: FIGHT_WON
            }),
            new Redirect({
                target: 144,
                text: '<p><a  class="more-link" href="#/paragraf/144">Poległeś</a></p>',
                type: FIGHT_FAILED
            })
        ],
        enemy: [new Enemy({name: 'Czarodziej', hp: 1, deffence: 1, proffesion: MAGE, special: [], status: 1})],
        tests: [],
        treasure: [mieczDwureczny]
    }),

O i definicja miecza:

var mieczDwureczny =  new Treasure({
    id: 2,
    name:'Miecz dwuręczny',
    bonus:2,
    bonusType:'SF',
    diceType:'DYNAMIC_MD'
});

Tu zaś mamy definicję paragrafu z testem kumulatywnym. Sama definicja testu jest już skomplikowana...

new Paragraf({
        number: 139,
        text: '<img src="img/swiatynia_wejscie.png" style="width: 50%;height: auto;  float: right; margin: 0 0 10px 10px;"/> ' +
        'Test KUMULATYWNY (charyzmy) CH: 4(5)',
        exits: [
            new Redirect({target: 144, text: '<p><a  class="more-link" href="#/paragraf/144">Wyjscie jakie pojawi się ponizej 4 rund UDANE </a></p>'}),
            new Redirect({target: 144, text: '<p><a  class="more-link" href="#/paragraf/144">Wyjscie jakie pojawi się przy 4 rundach UDANE </a></p>'}),
            new Redirect({target: 144, text: '<p><a  class="more-link" href="#/paragraf/144">Wyjscie jakie pojawi się przy 5 próbach UDANE </a></p>'}),
            new Redirect({target: 144, text: '<p><a  class="more-link" href="#/paragraf/144">TEST NIEUDANY PO 5 probach</a></p>'}
            )
        ],
        enemy: [],
        tests: [new Test({parameter: CH, difficulty: 4, success: 5, cumulative: true, conditionalExits: ['WON:LT:4', 'WON:EQ:4', 'WON:GT:4', 'FAILED:GT:5']})],
        treasure: []
    }),

I tak dalej. Możliwości jest sporo w efekcie kod szybko puchnie.

Gdzieś przy okazji napisałem parser w javie, który przeniósł poprzednią wersję paragrafówki do wersji angularowej. Można prowadzić walki, przeprowadzać część testów i poruszać się między paragrafami. Dzięki temu zauważyłem też, że konstrukcja niektórych paragrafów stanowi poważny problem dla aktualnej wersji silnika.
Wygląda tak i jest w pełni grywalna (nie licząc problematycznych paragrafów)

Cyferki na górze ekranu to paragrafy, które minął bohater zanim dotarł do paragrafu 23.

 Tutaj przykład testu kumulatywnego i jego efekt:

i da się dojść do końca gry. Log paragrafów pokazuje co się działo po drodze :)






Mimo wszelkich problemów jadę z kodem dalej.


p.s.
Kod javascript generowany z hilite.me

Paragrafowa przygoda w Angularze cz1

Wspominałem w poprzednim wpisie o pewnej niespodziance przygotowywanej wraz z przygotowaną paragrafową grą Przygoda barbarzyńcy Sladuma. Tydzień temu nie wiedziałem jednak czy będę miał czas i chęci (jakże są ważne), aby zrobić to co miałem na myśli.


Zaczęło się niewinnie. Nie dalej jak dwa tygodnie temu stwierdziłem, że nauczę się AngularJS - webowego frameworka do JavyScript. Umożliwia on - podobnie jak jQuery - na zaawansowaną pracę na poziomie przeglądarki z wyświetlanym kodem HTML. Trochę takie jQuery na sterydach. Jak pewnie podejrzewacie, nauka czegokolwiek związanego z programowanie wiąże się z pisaniem miej lub bardziej skomplikowanych programów pokazujących podstawy języka czy frameworku. I w tym wypadku zacząłem tak samo, ale po przerobieniu tego i owego z książki (zawierającej błędy w napisanym kodzie!)  doszedłem do wniosku, że ten sposób nauki jest, ogólnie rzecz ujmując, mało wydajny i do dupy. Robienie pseudostron z opisanych w książce przykładów czy wyświetlanie przysłowiowego "Hello world" nie jest zbyt rozwijające i bynajmniej nie pozwala na nauczenie się czegokolwiek w sensownym czasie. Trzeba podejść do tematu tak, aby nie znudził po kilku godzinach nauki.

Z tego też powodu wpadłem na pomysł, aby przy nauce Angulara zrobić całkowicie interaktywną grę paragrafową. Połączę dzięki temu przyjemne (robienie gier) z  pożytecznym (nauka frameworku). Częściowo jest to też efekt malkontenckich uwag mojego kolegi, którego mierził obowiązek wyjmowania kości do gry w grę uruchomioną na przeglądarce oraz że jest tak mało interaktywna. 

 W efekcie mam na tapecie paragrafówkę Przygoda Sladuma przerabianą na, ni mniej, ni więcej, grę tekstową, w której interakcja, poza klikaniem na paragrafy i okazyjnie na aktywne przyciski, nie wymaga od grającego więcej wysiłku. Testy i walka rozwiązywane są przez wbudowany silnik gry paragrafowej napisany w javaScript na frameworku Angular.

W tej chwili postęp prac w stworzeniu w pełni interaktywnej paragrafówki oceniam na jakieś 50%. Zbudowałem mechanizm przekierowań między paragrafami (oparty $location), szablonów ekranów (angularowe szablony), prowadzenia walki, testów pojedynczej cechy, losowania kostek (angularowe serwisy), wyświetlanie paragrafów i wstępna obsługa błędów (angularowe kontrolery). Brakuje dobrej obsługi błędów przekierowań i kilku aspektów mechaniki gry paragrafowej. Muszę też popracować nad  wyglądem np. listy wyników rzutów przy walce czy wygląd ekraniku ekwipunku. 

Efekty są zachęcający. Wszystkie działania gracza oraz podjęte akcje trzyma w pamięci przeglądarka, nie trzeba przechodzić między stronami, aby otworzyć kolejny paragraf. Wbudowałem proste zabezpieczenie przed oszukiwaniem poprzez cofanie stron :p. Prace trwają.


Poniżej kilka zrzutów:

Walka:

Przykład walki z dwoma przeciwnikami

Ciąg dalszy walki, dla postaci Sladuma, w zależności od potrzeb, aktywują się umiejętności przydatne w walce. Oczywiście
paski Żywotności zmieniają się dynamicznie.

Wygląd paragrafu przed testem wymagającym jednego rzutu.

Test nieudany + przekierowanie

Test udany + przekierowanie

p.s.
Jeśli zajrzy tu ktoś zainteresowany ja działa Angular użyty do stworzenia gry oczywiście mogę o tym napisać.

Rogalik

Oho, ale zrobiłem długą przerwę.

Niestety spowodowana jest brakiem czasu na rozwój gry. Ciężko zmusić się do pisania kodu, gdy wolne godziny, które możesz na to poświęcić, mieszczą się w granicy od 23:30 do 0:30 :).
Może aktualizacje będą się pojawiać jak wrócę do tematu chociaż na 15 min dziennie?

Rozważałem (za namową kolegi) do umieszczenia kodu na jakimś githubie czy innym gicie online. Tak, abym sam miał do niego łatwy dostęp z dowolnego komputera jak i z tego powodu, że może tajemnicze ktosie będą chciały partycypować w projekcie (i nie zaorają kodu wirusami:) ) podsuwają pomysły i poprawiając istniejące rozwiązania.

Jednak w tej chwili kod podróżuje w mailach, a powyższa propozycja pozostaje w sferze marzeń :).

Rogalik - grafika cd

W weekend poprawiłem trochę kod, znalazłem kilka miejsc, w których nadmiernie zapychałem pamięć grafiką i pewnie jeszcze wiele takich miejsc zostało.
Ale.
W tej chwili połączyłem generator mapy (ten z kwadracików widoczny kilka postów temu) z główną pętlą graficzną rysującą mapę. Pokoje planszy generowane są w momencie wejścia z wszystkim elementami składowymi jak pułapki/potwory/skarby - tylko nie ma to jeszcze przełożenia na wygląd pomieszczeń. Może do końca tygodnia się to zmieni, problemem jest przygotowanie odpowiedniej ilości plików opisujących cięte na potrzeby gry obrazków.

Szybkość odświeżania grafiki to 60 klatek / sekunda - i to ze względu na to iż przewijanie mapy przy mniejszej ilości klatek generowało uciążliwy lag.
Sama mapa nie jest jeszcze generowana tylko w widocznym dla gracza obszarze, ale już przygotowuję kod, który jest gotowy na takie zadanie. Właściwi w tym co widać poniżej brakuje tylko wyświetlenia pozycji drużyny tak, aby było wiadomo w którym klocku jesteśmy i mogę dalej wrócić do rzeźbienia mechaniki gry oraz poprawienia błędów w animowaniu poklatkowym (niestey kilka dziwnych błędów się wdarło)

W międzyczasie znalazłem coś takiego:

Jest to jakieś przykładowe (chyba- nie mam pewności|) gui "plecaka postaci" jakiegoś rogalika. W ten deseń chciałbym zrobić to w swojej gierce.
Trzeba przyznać że to co ludzie linkują do Pinteresta jest inspirujące:)


Aktualizacja
Poziom wygenerowany z animującymi się potworami.

ps.
Spojrzałem ile pamięci zjada moja "gierka" - w skrócie tak z 10x za dużo w stosunku do tego co oferuje ...

Rogalik - grafika!

Ostatnie dni miałem uciążliwie męczące i po powrocie do domu niebardzo miałem ochotę na jakiekolwiek prace przy grze. Nie znaczy to jednak, że zarzuciłem jakikolwiek jej rozwój. Poświęciłem kilka godzin na napisanie podstawowego mechanizmu animującego aktorów na ekranie. Oczywiście wiązało się to z przeczytaniem masy dokumentów, kilku rozdziałów książki Killer Java Game Programming, kilku wątków na StackOverflow, czegoś o javiefx, paru (nastu?) wpisów z blogów o programowaniu...

Pierwsza wersja aplikacji rysującej (gdy zaczęła cokolwiek rysować) psuła się dosyć poważanie ponieważ zjadała nieograniczone ilości pamięci. Szukając rozwiązania problemu (rosnący w nieskończoność GrowableBuffer w obiekcie Canvas) ściągnąłem przykłady z sieci dotyczące animowania w javieFX. Te zaś zjadały kosmiczne ilości czasu procesora (jedna animująca gwiazdki
w ekranie 400x600px zjadała ... 25% czasu procka CoreI5!) lub zatrzymywały się po kilkunastu minutach pracy.

Moja pętla rysująca zawierała błąd, który powodował, że animacja zatrzymywała się samoczynnie po kilku minutach. Aktualnie  mam problem z tym, że animacja działa, ale spowalnia po ok 10 minutach pracy.  Spaliłem duuużo czasu na znalezienie prawidłowego sposobu animowania klatek z użyciem komponentów javyfx tak, aby ciężar rysowanego obrazu nie rósł w nieskończoność. Przy okazji przypomniałem sobie trochę o obsłudze wątków i grafiki.
No i  udało  się - przynajmniej w ramach ograniczonego testu jaki wykonuję.  W tej chwili aplikacja animuje i rysuje to co trzeba, a poniżej zrzut z efektu jej działania.

Z technicznego punktu widzenia na ekranie gry będzie sześć warstw (w tej chwili rysowane są 3)

• tło (jest)
• podłoga (aktualnie połączona z warstwą ścian)
• ściany
• dodatki do pomieszczeń (np. skrzynie)
• aktorzy (jest)
• efekty specjalne

Warstwy, które są odświeżane dynamicznie (co klatkę) to tylko aktorzy. W niektórych momentach dojdzie odświeżanie dodatków do pomieszczeń - np. pochodni oraz w miarę potrzeb animacje na warstwie efektów specjalnych. Zaoszczędza
to duużo czasu i obliczeń komputera.


Napisany kod nie jest w 100% optymalny i da się jeszcze ograniczyć ilość wykonywanych przy grafice obliczeń. Widoczne obok okienko "zjada" na stałe ~100 MB pamięci - nie udało mi się zejść poniżej tej liczby. Taka już chyba uroda javyfx połączonego z moim kodem.
Niestety z czasem (> 20 minut) animka zwalnia znacząco i jednocześnie zaczyna zjadać więcej pamięci. Coś z moim kodem jest jeszcze poważnie nie tak...


Nie zrobiłem jeszcze pełnego opisu wszystkich rysunków używanych w grze stąd brak jakichś upiększaczy na załączonym zrzucie - w tej chwili mam opisanych 16 bohaterów i ich dwuklatkową :) animację, niebieską podłogę oraz ściany, tło oraz drzwi.

Rogalik, pułapki

Małymi kroczkami do przodu. Pojawiły się drobne moduły:
- możliwość wylosowania (predefiniowanych) bohaterów i wejście na mapę. Niestety nie ma jeszcze możliwości dobrania czarów do postaci ale to już niedługo się zmieni.
- pułapki. Jest to pierwsza rzecz jaka jest sprawdzana po wejściu do nowego pomieszczenia. W tej chwili można wybrać postać która spróbuje - jeśli ma odpowiednią umiejętność - rozbroić pułapkę i efekty tego działania - czyli rozbrojenie i przejście do kolejnej fazy lub uwolnienie pułapki i otrzymanie obrażeń. Wersja mocno 'beta' ale działa nawet sprawnie. Postać może nawet zginąć!

Rogalik cd. :)

Projekt toczy się powoli do przodu.
Program (bo daleko mu jeszcze do jakiejkolwiek gry) rozrasta się i zyskuje kolejne moduły. Proces jest czasochłonny, ale z mojego punktu widzenia dosyć ciekawy. Pokazuje inne podejście do programowania i wymaga zmiany niektórych przyzwyczajeń.

Ekran gry. W pasku widać wylosowane potwory.

Sama gra - z punktu widzenia osoby patrzącej z zewnątrz - zmienia się niewiele. Od ponad tygodnia nadal mam tylko główne okno gry, które generuje labirynt. Z tą różnicą ze klocki są większe niż ostatnio - w oczekiwanej przeze mnie wielkości 112x112 px. Wynika to z tego, że krawędź pola pokoju będzie składała się z 6 grafik ścian i jednej grafiki drzwi. Tak ja widać poniżej - pole typu pokój. Wersja ASCI:


            ╔══─══╗
            ║               ║
            ║               ║
            │               │
            ║               ║
            ║               ║
            ╚══─══╝

Korytarze będą oczywiście węższe i opakowane grafiką. :).
Napisałem też pierwsze elementy, które wiążą rozsypany kod gry ze sobą. W efekcie rośnie poziom komplikacji i pojawiają się trudne w stworzeniu moduły - np. zarządzanie fazami gry czy główna pętla graficzna. Ale do rzeczy.

 W tej chwili jest (i działa - dodałem testy w JUnit :) ) :
- losowania zdefiniowanych przez grę bohaterów
- wstępny projekt gui dla statystyk i ekwipunku bohaterów (wzorowany na tym z Diablo / Torchligt ale bez grafiki)

Ekran bohatera

- moduł określający fazę gry (to chyba będzie, poza walką i rozpatrywaniem czarów, jeden z najbardziej skomplikowanych elementów gry)
- wyświetlanie okien wykrywania pułapek, przekupstwa, napotkania potworów, ekwipunku i statystyk postaci
- pełny mechanizm generujący labirynt (na tę chwilę 1 poziomowy)
- wylosowane w ramach labiryntu pomieszczenia otrzymują w pełni funkcjonalne wyposażenie w postaci pułapek/potworów/skarbów
- mechanizm generowania potworów i ich cech
- mechanizm generowania skarbów i cech skarbów
- wstępne mechanizmy dotyczące bufora grafiki i cięcia grafiki na klocki (będą w wielkości 16x16 pixeli)
- wstępny mechanizm silnika graficznego do animacji

Posiedziałem przy generatorze mapy (właściwie to główne okienko gry), tak aby był przyjazny użytkownikowi - np. poprzez centrowanie obszaru na klocku, w którym znajduje się drużyna czy też umożliwienie przeglądania obszaru z pomocą myszy. Jednak po zmarnowanych na to kilku godzinkach doszedłem do wniosku, że za wcześnie na ten element i powinna nim zarządzać pętla generująca grafikę, a nie z poziomu javaFX.
Zrezygnowałem też z włączenia wcześniej wykonanego generatora podziemi do gry bo efekt końcowy nie był tak fajny jak zastosowanie znalezionej grafiki.

Ale jeszcze go wykorzystam!

W tej chwili (nie liczę grafiki) gra "zbudowana" jest z ok. 68 klas, a pewnie dojdzie drugie tyle. Tak właśnie wygląd ta prostota :].

Ehh siadając przy tym nie sądziłem, że tyle tego wyjdzie, a nie oszukując się - to dopiero początek.

A może roguelike?

Idę za ciosem.

Zachęcony efektem działania generatora podziemi stwierdziłem, że użyję go w większym projekcie. Generator ma stać się częścią prostej (tak wydawało się na początku) gry roguelike.
Żeby nie wymyślać koła i zasad gry od zera wykopałem starą planszówkę znaną na zachodzie jako Citadel of Blood, a w Polsce skopiowaną (zpiraconą przez Encore) i znaną pod nazwą Labirynt Śmierci. Generator będzie odpowiedzialny za tworzenie wyglądu poszczególnych klocków z których będą się składać podziemia, tak aby nie korzystać z niezbyt pięknych kafelków z których składała się oryginalna plansza.
W tej chwili wersja 0,0001 beta tworzy planszę z możliwymi połączeniami oraz ustala typ pomieszczenia, do którego trafia drużyna. W tle dzieje się trochę magii programistycznej
i  staram się robić te elementy gry, które nie sprawiają mi kłopotów programistycznych. W tej chwili dostępne są pierwsze wersje maszyny losującej potwory i skarby oraz mechanizm zarządzający turami gry.

Poniżej widać przykładowy działania generatora.

Kwadracik zielony to aktualna pozycja „drużyny” zwiedzającej podziemi. Podziemia tworzone są na bieżąco przy przechodzeniu między klockami (niebieskie kwadratowe pola) i na bieżąco określana jest liczba dostępnych wyjść/wejść z pomieszczeń. Czarne ramki to oczywście nieprzekraczalne „ściany”.

A tu widać w pełni wygenerowany poziom podziemi.

W tej chwili kwadraciki mają 64x64 px wielkości a sama plansza to 8x8 kwadratów (docelowo nie będzie tak skalowana).

Dla każdego z kafelków – w oparciu o ilość wejść – chcę wygenerować z pomocą już napisanego generatora wygląd. I tak do obszaru o 3 wejściach kafelek będzie wyglądał tak:

A tak dwa połączone klocki – jeden z 3 wejściami i drugi z jednym.

Taki przynajmniej jest plan. Na razie jestem jeszcze parę kroków przed połączeniem generatorów ze sobą.


Rzeczy wymagające dużo pracy idą w tej chwili na później – min. obsługa walki, grafika, ekrany i sensowne gui. Co do grafiki - będzie pixelartowa (oczywiście). Znalazłem w międzyczasie komplet grafik, które w 100% pokrywają moje zapotrzebowanie na elementy składające się na gry. Chcę wykorzystać DawnLike - 16x16 Universal Rogue-like tileset v1.81



Wygląda tak:

Będę mógł przećwiczyć obsługę grafiki i tworzenie animacji.

Mądrzy ludzie mówią, że najtrudniej napisać swoją pierwszą grę. Cóż – zobaczymy czy uda mi się ją zrobić i doprowadzić do grywalnej wersji. W miarę postępów (widocznych) będę dodawał kolejne wpisy.

Jeśli kogoś interesuje kod i co wykorzystuję - to także mogę go wrzucać. Piszę oczywiście w javie ze wsparciem javyfx  i kilku zewnętrznych bibliotek użytkowych.

Generator map lekcje 5 / 6

Kolejny krok to zapewnieniu połączeń pomiędzy oderwanymi od siebie obszarami map. Lekcje zawierają się w ramach wpisów:  Connecting Rooms oraz Ensuring Connectivity

Lekcję dotyczącą tworzenia połączeń między oderwanymi do tej pory pomieszczeniami przerobiłem wraz z tutorialem. Jednak kolejną, w której zapewniamy połączenia pomiędzy wszystkimi obszarami mapy zrobiłem już samodzielnie bez zaglądania do tutoriala. W oparciu o zdobytą już wiedzę i własne umiejętności udało mi się to dosyć sprawnie zrobić. Ciężko mi ocenić czy mój kod jest tak dobry jak ten z tutoriala, czy może wręcz lepszy, ale działa i jestem z niego zadowolony bo jest mój :D.


Poniżej efekt pracy bez uruchomionego dodatkowo łączenia (lekcja Connecting Rooms):

i z łączeniem oderwanych obszarów (samodzielny kod):

Jak widać pojawił się nowy korytarz łączący oderwane strefy.


Teraz wyznaczone ścieżki trzeba przekształcić w korytarze. Czyli: Passageways.

Generator map lekcja 4

Przerobiłem lekcję 4 Detecting Regions , w ramach której mapka była sprawdzenia pod obecność artefaktów w postaci zbyt małych obszarów pustych lub zbyt małych obszarów wypełnionych.
Przykładowo :

Mapka z dosyć dużą krawędzią dla kwadratu ściany (wartość Długość boku) z regionem o zdecydowanie zbyt małej wielkości. Powinien on zostać usunięty (wypełniony ścianą). Oczywiście w efekcie mapka będzie w 100% niegrywalna, ponieważ w całości zostanie wypełniona ścianami. 

Poniżej mapka przepuszczona przez filtr, z której usunięto dwa (musicie uwierzyć na słowo :) ) zbyt małe obszary puste. Algorytm usuwa także zbyt małe ściany.

  

W poniższej mapce widać zbyt mały obszar ściany, który powinien zniknąć z naszej mapy:

 Lekcja poszła dosyć szybko. Nie ustrzegłem się kilku błędów, ale udało się je w miarę szybko ogarnąć (nie pamiętam kiedy ostatnio używałem w javowego PriotytyQueue!)