środa, 8 marca 2017

LibGDX uruchamiamy pierwsze okno aplikacji


Obecny wpis poświęcony będzie zapoznaniem się z LibGDX, czyli frameworkiem do tworzenia gier na wiele platform jednocześnie przy użyciu języka Java, jako że będzie to forma nauki, kroki będą rozpisane szczegółowo. Na pewno Pojawią się problemy przez które trzeba będzie przejść. Zaczniemy od stworzenia pustego projektu i przyrostowego dodawania nowej funkcjonalności. Z  czasem na pewne elementy będą widoczne lepsze rozwiązanie, w sposób bardziej elegancki, więc do nich wrócimy. Po drodze pojawi się masa elementów, które będziemy używać w projekcie, nie pozostawiając je bez komentarza. Na pewno każdy cos wartościowego z tego wyniesie. Więc, do roboty!

Pobieramy LibGDX kreator projektu

Przechodzimy do zakładki download LibGDX twórców badlogicgames i pobieramy aplikację instalującą. Powinien pokazać nam się do zapisania plik .jar gdx-setup. Tak wygląda okno po uruchomieniu.


Klasa i pakiet wyjaśnienie

Powyjaśniajmy terminy. Zakładam że czyta to początkujący, a często zapomina im się wyjaśnić szczegóły, tylko kliknij to, odznacz tamto. Ktoś znający te kroki z pewnością już to przewinął. Zacznijmy od pakietu (package), przyznam się nie jest łatwo to zdefiniować. Przed Wami logika wg Krzycha ;d. na początku potrzeba zdefiniować pojęcia klasy. Weźmy sobie z otoczenia jakiś przedmiot np. leżący obok banan. I chcemy zrobić Fruit Ninja. Banan jak wiemy jest owocem. Właśnie ten owoc możemy uznać za jakąś kategorię, ponieważ mamy różne owoce. Kategorii (klasie) owoce możemy przypisać ujednolicone cechy: np. kolor, smak, zapach, wielkość, kształt. Jednak każdy owoc różni się tymi parametrami (np. kolor: banan – żółty, arbuz – zielony). Oprócz parametrów możemy owocom przypisać możliwe zachowania (np. owoc pachnie, owoc gnije – niefortunne skojarzenie, owoc uśmiecha się do nas żeby go zjeść), a w grze np. (owoc spada, owoc rozcina się w pół, owoc znika). Mając już stworzoną klasę (ogólna rama), łatwo nam tworzyć poszczególne owoce przypisując im poszczególne parametry, jakie owoc posiada. Mówimy wtedy o tworzeniu obiektu, podsumowując banan jest właśnie obiektem klasy owoc.

Teraz pakiety, tu już łatwiej. Pakiety można uznać za analogię dla folderów jakie znamy z komputerów, telefonów. Służą przede wszystkim porządkowaniu, grupowaniu w jakieś logiczne, znaczeniowo struktury. Klasy grupuje się identycznie. Weźmy przykład pakiet java.lang w którym znajduje się masa różnych klas. Jak widać są one porozdzielane, klasa String (ciąg znaków) jest zupełnie czym innym niż klasa Math (klasa do wykonywania obliczeń numerycznych). Więc pakiety dla nich będą wyglądać następująco: java.lang.string i java.lang.math. W nazwach pakietów stosuje się wyrazy pisane małymi literami oddzielone kropkami.
Game Class będzie główną klasą w naszej grze, właściwie można nazywać ją dowolnie, ale co ważnie zapisuję się łącznie i najlepiej jak nazwa sama w sobie coś mówi. Kolejno w Android SDK należy wskazać miejsce na dysku, gdzie mamy zapisane SDK androida. Przy tworzeniu projektu możliwe jest ustawianie opcji na załączenie pod projektów na kilka platform jednocześnie: aplikacja desktopowa, Android, iOS i Html. My skupiamy się na opcji na android i desktop. Desktop aby można było bezpośrednio wyświetlać na komputerze w celach szybkiego testowania. Poniżej jest możliwość zamieszczenia wiele rozszerzeń do projektu: 

Możliwe rozszerzenia LibGDX - przegląd

Wcześniej to pomijałem, a teraz dla ciekawości trzeba się w końcu temu przyjrzeć jakie możliwości oferują ;d
Bullet - silnik fizyki
Freetype - silnik do obsługi różnych font-ów
Tools – narzędzia, edytory, procesory plików
Controllers – służy do obsługi gamepada
Box2d – silnik grafiki 2d
Box2dlight – framework do renderowania (wyświetlania) różnych efektów świetlnych i cieni
Ashley – lekki framework służący do budowania aplikacji wielowarstwowych (np. osobno warstwa prezentacji, warstwa klienta itp.)
Ai – framework odpowiedzialny za sztuczną inteligencję

Aha… co to framework może przy okazji. To krótko mówiąc służy jako szkielet do budowy aplikacji, zawiera komponenty i  biblioteki do realizowania określonych zadań.
Po ustawieniu co chcemy, a co nie, klikamy Generate. Prawdopodobnie program zapyta nas czy chcemy użyć nowszej wersji niż jest zalecana. Zgadzamy się i powinno rozpocząć się generowanie. Jeżeli wszystko przebiegło prawidłowo powinien widoczny być komunikat BUILD SUCCESSFUL.


Projekt istnieje już w folderze którym wskazaliśmy, więc pora zaimportować go do android studio. W android studio wybieramy opcję otwarcia istniejącego projektu.


Kolejno zostajemy pytani o wybór korzystania z SDK android studio, bądź sdk zdefiniowanego w projekcie. Właściwie oba podejścia działają jeżeli wszystko jest poprawnie skonfigurowane. My użyliśmy SDK projektu.


Program informuje o możliwości aktualizacji Gradle, jednak najnowsza wersja nie jest wymagana. Możemy pominąć ten krok i zrobić to jeżeli wystąpiłyby jakieś problemy.


Gradle – narzędzie do budowania projektów, znacząco ułatwia konfigurowanie i pobieranie rozszerzeń do naszego projektu.
Projekt zacznie się budować, może to zająć sporą chwilę. Więc czekamy.

Testowanie i konfiguracja wyświetlania (desktop launcher).

Tak powinna wyglądać struktura katalogów która stworzyliśmy. W folderze android i desktop znajduje się klasa odpowiedzialna za wyświetlanie odpowiednio na telefonie i komputerze. W folderze core znajdować będzie się cała logika gry.


Pierwsze co zrobimy to przetestujemy co właściwie zostało utworzone i czy działa poprawnie jako aplikacja okienkowa. W tym celu klikamy prawym przyciskiem na klasę DesktopLauncher i wybieramy „Run ‘DesktopLaunche…main()’”


Teoria wielkiego wybuchu

Powinno wybuchnąć, czyli pojawi się wyjątek (exception). Wyjątek pojawia się w momencie pojawienia się jakiegoś nieprzewidzianego zdarzenie, bądź błędu. Wyjątek powinien skutkować zatrzymaniem stanu programu, zapamiętanie go, a następnie obsługą i powrotem do przerwanego kodu. W naszym przypadku powód jest dość prosty, launcher desktopowy nie ma wskazane gdzie znajduje się przykładowy plik graficzny (asset) badlogic.jpg, który nasz kod chce wyświetlić. 

Naprawa Desktop Launchera

Aby go naprawić należy na pasku, przed zieloną ikoną run rozwinąć listę i wybrać zakładkę Edit Configurations…


W oknie edycji konfiguracji klikamy na znaczek + znajdujący się w lewym górnym rogu, z listy wybieramy typ Application. Dalej tak jak na obrazku poniżej w konfiguracji wpisujemy nazwę np. Desktop. wybieramy główną klasę klikając na znak rozwinięcia „…”, a z listy wybieramy Desktop Launcher. Teraz najważniejsze wybieramy Working directory wskazując na folder android/assets z lokalizacji naszego projektu. Ostatnią rzeczą jest wskazanie Use class path of module wybierając desktop. Możemy w końcu kliknąc Apply i OK. Cała ta konfiguracja jest właściwie wskazaniem co gdzie się znajduje. Od teraz powinno wszystko działać poprawnie, pierwsze uruchomienie i kompilacja może jednak chwilę potrwać. W Efekcie powinno uruchomić się okno z logiem BAD Logic na czerwonym tle.


Podsumowanie

Udało nam się poprawnie przygotować środowisko do późniejszej pracy. Chcąc nie chcąc zawsze zajmuje to sporo czasu i pracy, niestety nie da się tego uniknąć. Nikt tego także za Ciebie nie zrobi, więc uzbrój się w cierpliwość, no chyba że w przyszłości coś wymyślą. Dosyć często pojawiają się problemy związane z niezgodnością oprogramowania, ale jednocześnie jest to pozytywny przejaw ciągłego rozwoju. Na początku może być to jednak trochę zniechęcające, z czasem nabiera się wprawy i robi to sprawniej. Co do postu to było czasochłonne opisanie tego w odróżnieniu od samego wykonania tych kroków, tak więc na dzisiaj wystarczy. Następny wpis poświęcony będzie założeniom projektu i w jakiś sposób opisania idei całej tej gry. Zobaczymy jak w przyszłości odbiegniemy od rzeczywistości ;d

Do zobaczenia wkrótce

Brak komentarzy:

Prześlij komentarz