VIŠA POSLOVNA ŠKOLA - WordPress.com€¦  · Web viewВИСОКА ПОСЛОВНА ШКОЛА СТРУКОВНИХ СТУДИЈА. БЛАЦЕ. ЗАВРШНИ РАД. ПРОЈЕКТОВАЊЕ

ВИСОКА ПОСЛОВНА ШКОЛА СТРУКОВНИХ СТУДИЈАБЛАЦЕ

ЗАВРШНИ РАД

ПРОЈЕКТОВАЊЕ И ДИЗАЈН ВИДЕО ИГАРА НА АНДРОИД ПЛАТФОРМИ

СТЕФАН НИЧИЋ

У Блацу, 2016. год.

ВИСОКА ПОСЛОВНА ШКОЛА СТРУКОВНИХ СТУДИЈАБЛАЦЕ

ПРОЈЕКТОВАЊЕ И ДИЗАЈН ВИДЕО ИГАРА НА АНДРОИД

ПЛАФОРМИ- ЗАВРШНИ РАД -

Ментор: Оливер Поповић Кандидат: Стефан Ничић

У Блацу, 2016. год.

Sadržaj

1. UVOD .................................................................................................................................42. FRAMEWORK ILI ENGINE................................................................................................53. BUDŽET..............................................................................................................................54. OSNOVNA ARHITEKTURA IGRE..................................................................................6

4.1. „HIGH-LEVEL“ game petlja avanturističke igre.........................................................64.2. „HIGH-LEVEL“ game event-based petlja avanturističke igre.....................................74.3. „HIGH-LEVEL“ petlja za obradu grafike video igre...................................................8

5. ARHITEKTURA LibGDX-a..............................................................................................105.1. LibGDX core moduli...................................................................................................115.2. LibGDX backend moduli.............................................................................................12

6. ŽIVOTNI CIKLUS APLIKACIJE KOJA SE RAZVIJA SA LibGDX-om.......................137. KONCEPT VIDEO IGRE..................................................................................................168. PRAVLJENJE I EDITOVANJE TILED-BASED MAPE..................................................189. IMPLEMENTACIJA POČETNIČKIH KLASA ZA PROJEKAT....................................21

9.1. Opis AndroidLauncher klase.......................................................................................229.2. Opis Alternia klase......................................................................................................23

10. IMPLEMENTACIJA ASSET MENADŽERA SA UČITAVANJEM TEKSTURA I TILED-BASED MAPA...................................................................................................... 2310.1. Opis Utillity klase.............................................................................................24

11. IMPLEMENTACIJA KAMERE I MAPE U RENDER PETLJI........................................2511.1. Opis MainGameScreen klase............................................................................26

12. IMPLEMENTACIJA MAPA SA SPAWN POINTS I PORTALIMA................................2912.1. Opis MapManager klase...................................................................................29

13. IMPLEMENTACIJA IGRAČEVOG LIKA SA ANIMACIJOM......................................3213.1. Opis Entity klase...............................................................................................32

14. IMPLEMENTACIJA KONTROLA..................................................................................3714.1. Opis PlayerController klase.............................................................................37

15. ZAKLJUČAK.....................................................................................................................4016. LITERATURA....................................................................................................................41

III

1. UVOD

Razumevanje različitih tehnologija, prilikom projektovanja video igrice može biti veoma frustrirajuće, posebno ako imate osećaj da ako se posvetite samo jednom setu alata, ograničite sebe u startu. Pre nego što se utvrdi koja solucija je najbolja za realizaciju projekta, moramo odrediti i definisati tačne ciljeve projekta

Jedno od prvih pitanja koje treba da postavimo sebi, kada procenjujemo rešenje za video igru je: Da li želimo konačan proizvod (kompletna video igra spremna za tržište) ili da li smo više zainteresovani implementacijom specifičnih detalja igre, radije nego konačan produkt. Ako smo više zainteresovani za imlementaciju specifičnih detalja igre, onda je verovatno najbolje da napraviti svoj sopstveni engine u suprotnom na tržištu postoji dosta solucija za realizaciju vašeg projekta. Problem koji se javlja, je šta je najbolje izabrati.

Da bi napravili pravi izbor postavljamo sebi pitanje koju platformu izabrati)?.To zavisi od obima projekta i potreba projekta. Ovo je bitno pitanje zato što utiče dosta na vreme koje je potrebno da se realizuje projekat i izbor programskog jezika, takođe određuje soluciju, koja je najbolja za realizaciju projekta.

Pre nekoliko godina, odgovor na postavljeno bi bio jednostavan, ali danas kada se pravi komericijalna igra, treba uzeti u obzir sve mogućnosti. Pored ličnih računara koji koriste Windows ili Mac OSX , tu su mobilni uređaji iOS, Android ili Windows Phone, takođe i konzole kao što su PS4 ili XBOX one. Čak i sa framework ili engine koji podržava cross-platform , treba uzeti u obzir činjenicu , da video igra mora biti testirana u više faza, za svaku platformu.

Danas smart telefoni i tablet uređaji su postali glavni konkurenti konzolama kao što su Nintendo 3DS i PlayStation Vita. Njihovo pojavljivanje na tržištu je pobudilo interesovanje programera širom sveta i pokrenulo istraživanje koja mobilna platforma bi bila najpogodnija i profitabilnija. Apple IOS je izgledao kao dobar izbor kandidat ali zato što sistem nije otvoren, tj. ako bi želeli da podelimo naša iskustva sa drugim programerima ili svetom, morali bi prvo da tražimo dozvolu od Apple-a, pored toga neophodno je da posedujemo Mac OS, da bi mogli da razvijamo aplikacije za IOS.

Onda se pojavio Android OS, koji je odmah privukao dosta programera, zbog prednosti koje nosi sa sobom. Okruženje za razvijanje aplikacija je nezavisno od OS platformi i što je bitnije omogućava razvoj aplikacija i video igra na glavim OS platformama. Zatim je dozvoljeno da se dele naši projekti bez bilo kakve novčane nadoknade i jedna od glavnih prednosti je inovativni globalni market, koji omogućava pojedincima da lako unovče svoj projekat ako im je to cilj.

4

2. FRAMEWORK ILI ENGINE

Kada smo odlučili koje su ciljne platforme i da li želimo da napravimo video igru spremnu za tržište, sledeće pitanje koje sebi postavljamo je da li želimo da realizujemo projekat engine-om ili framework-om? Glavni motiv iza ovoga je: Koliko kontrole želimo i kako će ovo uticati na proces realizacije projekta?

Engine je obično solucija koja ima odlike “crne kutije “, gde mi razvijamo logiku igre u sklopu granica koje nam je engine postavlja, a za uzvrat engine obavlja kompleksne operacije „ispod haube“ (tj. mi nemamo kontrolu, nad tim procesima).

Framework sa druge strane, je kolekcija biblioteka sa izloženim API u vidu modula, predstavljajući viši nivo apkstrakcije „core“ komponenti, kao što su grafika, I/O fajlova i slično. Razvoj igre sa framework-om, u kontrastu sa engine-om, kao vlasniku kontrolu nad „main game“ petljom, da je pozivamo u bibliotekama po potrebi , tokom „zivotnog ciklusa „ igre .

Sledeća tabela predstavlja malu listu dostupnih solucija danas:

Name Engine/framework Ciljne platforme Programski jezici

Cocos2d Framework OS X, Windows, Linux Objective-C

LibGDX Framework Windows, OS X, Linux, iOS, Android i HTML5

Java

Source Engine Windows, OS X, Linux, iOS, Android, XBOX 360 i Playstation 3

C++

Torque2D Engine Windows, OS X, Linux, iOS, Android i HTML5

TorqueScript

Unity Engine Windows, OS X, Linux, iOS, Android, XBOX, Playstation i Windows phone

C#

Slika 1. Vizuelni prikaz high-level petlje

3. BUDŽET

Zadnje i najbitnije pitanje pre nego što krenemo sa realizacijom projekta je: Koje su vaše finasijke mogućnosti za projekat

5

Gornja tabela predstavlja solucije koje su dostupne timovima koji prave video igre i većina opcija ponuđenih u toj tabeli ima razumne troškove, čak i za nezavisne programere (indie developer), koji prvi put plasiraju svoju igru na tržište ( postoje besplatne solucije).

Sa svim izvrsnim idejama i planiranim odlikama igre , za bilo koji komercijalni proizvod „tripple costrain“, će se pojaviti i brzo usporiti projekat ograničenjima: trajanje razvoja projekta, cena i kvalitet. Ako se promeni jedno ograničenje, druga dva će takođe biti zahvaćenja promenom, što zahteva konstatni balans projekta.

Na primer , ako smo smo procenili da je neophodno 5000 eura, za „artwork“ video igre, a naš budžet ne prevazilazi 100 eura, očigledno je da će ovo značajno uticati na kvalitet izgleda igre, takođe će biti potrebno dodatno vremena (čak i kad bi crtali „stick“ figure, one su neophodne da se nacrtaju , a to znači da moramo stanemo sa programiranjem na neko vreme).

Komercijalni produkti , čak i 2D sa pixel izgledom, moraju da budu originalni i dobro izglađeni da bi se istaknuli i izdvojili na tržištu . „Stick „ figure bi možda bile dobra distrakcija da privuku pažnju ali većina audencije danas ima mnogo veća očekivanja, čak i za „indie“ video igre.

Ako se uzme sve obzir što je gore navedeno opcije dostupne za planiranje budžeta su:

Realizuj proizvod relativno brzo, sa odličnim izgledom i muzikom ali cena će biti visoka

Realizuj proizvod brzo sa „stick“ figurama i sopstvenim audio sadrzajem ali to nije najbolje rešenje

Dizajniraj zanimljivu igru sa jedinstvenim izgledom i stilom. Audio sadrzajem koji je kvalitetan i kreiran od tima koji radi besplatno , ali nedostak je što će ovaj proces zahtevati dosta vremena.

Kada planiramo realizujemo prvu igru sopstven engine, zvuči kao logično rešenje. Ali ako pitate sebe prvo pitanje , to zavisi od toga da li vam je bitnije da izbacite video igru na tržiste nego da pravite engine od početka. Postoji toliko razvijenih i proverenih opcija na tržištu da ce te verovatno brzo promeniti mišljenje, i opredeliti se za proverenu soluciju koja podržava više platformi.

Ovo je dovelo ka sledećem pitanju o platformama. „Cross-platform“ rešenja su zgodna zato što olakšavaju portovanje video igre na druge platforme ( abstaktuju spefične potrebe platformi), što nam olakšava da napravimo igru za jednu platformu (Android), bez brige o obimu koji bi bio potreban da se portuje na drugu platformu kasnije (npr Windows OS).

Sledeće nedoumica je da li, da izaberemo engine ili framework. To stvarno zavisi od toga da li želite kontrolu nad „game loop“ i da li ste spremni da posvetite vreme treningu za specifični engine kao i finasijkse troškove koji idu uz njega.

6

I na kraju pitanje u vezi budžeta. Ako , ste indie programer i želite da plasirate video igru sa ograničenim budžetom, onda imate ograničene opcije. Jedna od najboljih solucija u tom slučaju je LibGDX , i ovaj projekat je napravljen pomoću njega.

Postoji više razloga zašto baš LibGDX. Pre svega , LibGDX je razvijen sa namerom da ima što bolje perfomanse, „cross-platfom“ podršku, sadrži gomilu API-ja koji znatno olakšavaju proces pravljenja igre , jedan od bitan faktora je da ima aktivnu zajednicu , redovno se ažurira i besplatan je.

4. OSNOVNA ARHITEKTURA IGRE

Da bi bolje razumeli osnove tipične arhitekture igre , na visokom nivou (high- level), počećemo sa jednostavnom avanturističkom text baziranom video igrom.

4.1 „HIGH-LEVEL“ game petlja avanturističke igreSledeća slika ilustruje kako „high-level“ game loop (petlja) funkcioniše. Igra pamti

sve unose u toku svog životnog ciklusa , do trenutka dok ne dobije „input“ (unos ) od korisnika, preko komadne linije:

Slika 1. Vizuelni prikaz high-level petlje

Kada je tekst pročitan sa komandne linije, igra će onda parsirati („parse“) ceo string i podeliti sadržaj rečenice u celine. Najosnovniji sistem ima rečnik koji sadrži akcije ili glagole, koje korisnik može da koristi. Svaka reč u rečenici se onda poredi sa listom dostupnih akcija.

Na primer ako bi igrač želeo da pokupi flašu vode i prospe vodu na zemlju, igrač bi uneo komandu:

„prospi vodu“

7

Video igra bi obradila string , razbila rečenicu na male delove i uporedila sa glagolima i imenica u rečniku. Na kraju bi se javile dve liste liste. Akciona lista bi se sastojala od akcije „prospi“. Dok lista objekata , sadrži objekat „voda“.

„Prospi“ je primarna akcija sa pravilima koji izgledaju ovako:

„PROSPI“ [OBJEKAT 1] IS SUCCESSFUL (USPEŠAN)

IF IGRAČ IMA [OBJEKAT 1] IN INVETORY (INVETAR)

AND [OBJEKAT 1] IS POURABLE (TEČAN)

Pored toga bilo bi još uslova video da bi se utvrdila svojstva objekta, kao da li objekat može da se smesti u invertar, da li je tečan, da li može da se baci ili nosi. Dodatni uslovi mogu da se smeste u posebnu podlistu objekata, za svaku akciju.

4.2 „HIGH-LEVEL“ event-based petlja avanturističke igreNa visokom nivou („high-level“), GUI (Grafički korisnički interfejs), video igra obrađuje

događaje (events) iz „event“ petlje i samo prekine sa tim kada video igra dobije poruku za prekidanje. Glavna platforma ovog projekta je Android, tako da Android OS će generisati neku „event“ poruku baziranu na osnovu događaja kao sto je dodir ekrana i smestiti poruku u listu čekanja.

Listu čekanja obrađuje GUI video igre, tako što kreće od prvog elementa u listi čekanja , na principut FIFO (first-in-first-out), sa najnovijom porukom na kraju liste. Ovo se dalje nastavlja redosledom, u potrazi za „bitnim“ porukama i obraditi će poruku ako je ona bitna, zatim će proslediti odgovarajućoj proceduri ili menadžeru poruka za neki specifičan događaj.

4.3 „HIGH-LEVEL“ game petlja za obradu grafike video igre

Slika 2. Vizuelni prikaz game loop petlje

Slika ilustruje kako grafička game petlja funkcioniše na osnovnom nivou. Za razliku od prethodne dve petlje ova petlja funkcioniše drugačije.

8

Gore navedeni principi, prethodne dve petlje, ne bi mogle da funkcionišu u modernim igrama zato što nešto uvek mora da se ažurira svaki ciklus u petlji, čak i kada igrač ne radi ništa , naprimer potez AI (veštačke inteligencije), efekti fizike(physics) ili efekti čestica (particle).

Umesto da čeka na „input“ od strane korisnika petlja prikapulja događaje i obrađuje sve dostupne korisnikove „input-e“ (unose), dostupne u trenutku.Kada završi sa obradom petlja onda , pristupa objektima igre koji moraju biti ažurirani, bazirano na trenutnom stanju „sveta u igrici, na primer kretanje neprijatelja i rešavanje kolizije.

Kada petlja završi sa ažuriranjem, petlja će istrcati grafički prikaz, koji je baziran na proračunima odrađenih prethodno, i rendonovaće ih na displeju (render). Ova petlja se pokreće ponovo na početku sledećeg ciklusa. Jedan ciklus prikazan na slici se zove „Frame“ (ram). Pitanje se postavlja koliko brzo se može obraditi svaki „frame“ u game petlji.

Termin koji se koristi za određivanje koliko ciklusa je moguće završiti u fiksiranom vremenu je, koji se meri u FPS (frames per second ) se zove „frame rate“. Što više „frames“ se obrađuje to če iskustvo sa igrom biti prijatnije za igrača. Razlog za to je, zato što petlja mnogo češce , ažurira, prikuplja korisnikov „input“ i rendenuje. Što manje „frames“ , igra manje postaje igrljiva i iskustvo je lošije. U modernim igrama, standard je 30 FPS, sve ispod toga, se smatra ne pogodnim.

Dva faktora koja odlučuju o „frame rate-u“ igre su:

o Koliko brzo ciljani sistem može obradi svaki „frame“. To zavisi od od hardware-a sistema, na primer „clock speed“ (brzina ) procesora (CPU), i grafičke kartice (GPU). Još jedan faktor je sam operativni sistem.

o Drugi faktor je koliko logike mora da se obradi svakog „frame“. Proračunavanja za fiziku (koja se koriste za detekciju kolizije ili ubrzanja) i rendenovanje grafike visokog kvaliteta za dosta objekata igre, utiče značajno na to koliko je truda potrebno da se uloži za svaki frame, što dovodi do toga da se „frame-ovi“ duže renderuju. Drugim rečima , manje „frame-ova“ se obradi svake sekunde

S obzirom na broj platformi , ova dva faktora će pružiti drugačiji osečaj i iskustvo na različitim platformama. Na mobilnim uređajima, igra možda nema mogućnost da koristi GPU i onda CPU postaje usko grlo za proračunavanje svih „input“ korisnika, fizičkih efekata, AI i rendonovanja što može uzrokovati igru da radi na sa malim „frame rate-om“

Tipčno rešenje je da frame rate, zaključa (lock), tako da je iskustvo na svim platformama stabilno i isto.

Ovo nije najbolje rešenje, zato što na primer ako želimo da portujemo igru na Windows OS platformu, „refresh rate“ monitora možda nije sinhronizovan sa „locked frame rate“ , i onda se primećuju vizuelni artifakti , kao treperenje ekrana (screen tearing)

9

LibGDX rešava ovaj problem , tako što razvrstava „frame rates“ bazirano na osnovu uređaja, tako što koristi deltaTime vrednost prilikom svakog pozivanja rendonovanja za „frame“. Ova vrednost predstavlja ukupno vreme u sekundama , koliko je igri bilo potrebno da rendenuje zadnji „frame“.

Ažuriranjem proračuna koristeći deltaTime, elementi igre bi trebalo da su redovnije sinhronizovani za sve uređaje, koristeći ovaj pristup umesto „locking“( zakljucavanja ) video igre sa specifičnim „frame rate-om“.

5. ARHITEKTURA LibGDX

5.1 LibGDX backend moduli

Sledeći dijagram ilustruje, osnovne interfejse LibGDX-a. Ovo su apstrakcije visokog nivoa („high-level), koje pružaju većinu sredstava potrebnih da bi se napravila video igra.

Slika 4. Vizuelni prikaz Backend modula

10

Ovi interfejsi su univerzalni za svaku platformu, tako da možete da se bacite na pravljenje igre, koriščenjem ovih aplikativnih interfejsa i da ne brinite o specifičnim potrebama platformi.

Opis interfejsa:

Application.java : Ovaj interfejs operativni sistem koristi kao ulaznu tačku da pokrene igru. Svaka implementacija biće odgovorna za upravaljanje aplikacijom, tokom njenog životnog ciklusa i slično. Specifično Application.java pruža module za grafiku, audio, input , fajl I/O , kao i logovanje i podrsku za druge biblioteke

Graphics.java: Ovaj interfejs sadrži gomilu pomoćnih metoda za komunicaranje sa grafičkim proceserom platforme , na primer rendonovanje prikaza na ekranu i ispituje dostupne modove displeja , kao što je rezolucija i dubina boja (color depth). Takođe sadrži metode za konvecionalno generisanje „pixmaps“ (piksle mapa i tekstura.

Audio.java: Ovaj interfejs sadrži gomilu pomoćnih metoda pravljenje i upravljanje audio resursima. Ovaj interfejs se koristi da kreira zvučne efekte, pušta zvučne materijale i pruža direktni pristup audio hardveru za PCM audio I/O.

Files.java: Ovaj interfejs sadrži gomilu pomoćnih metoda za pristup fajl sistemu platforme kada upravlja resursima igrice , kao što je upis i učitavanje fajlova. Takođe pruža abstrakciju različitih tipova skladišta, za smestanje fajlova: internal files (unutrašnji fajlovi) i external files (eksterni ili spoljašni fajlovi).

Input.java: Ovaj interfejs sadrži gomilu pomoćnih metoda prikupi (ili obradi događaje –events ) korisnikov „input“, sa tastature , miša , touch screen-a. Druge pomoćne metode služe za upravljanje vibracijom, pristup kompasom , on-screen tastatura.

Net.java: Ovaj interfejs sadrži gomilu pomoćnih metoda za obavljanje specifičnih za obavljanje određenih mrežnih operacija, kao što je upravljanje HTTP/HTTPS GET i POST zahteva i kreirajući TCP server/klijent soket konekcije.

Preference.java: Ovaj interfejs sadrži gomilu pomoćnih metoda za smeštanje i pristup podešavanjima igrice, služi kao malo skladište za čuvanje opcija/podešavanja.

11

5.2 LibGDX core moduli

Ostatak funkija i sredstava koju koristimo prilikom pravljenja video igre pripada sledećim modulima LibGDX-a. Moduli u levoj koloni (audio, files, graphics, input, net), su već pomenuti u prethodnom poglavlju.

Slika 4. Vizuelni prikaz LibGDX core modula

Opis interfejsa je sledeći:

Maps: Ovaj modul sadrži klase za obračunavanje sa različiim implementacije mapa, kao na primer mape generisane sa Tiled (XML baziranim formatom, koji se zove TMX) i Tide. Sadrži metode za konvecionalno referisanje „assets“, učitavanje mapa, rendenovanje mapa. Pristup svojstvima i izbor različitih slojeva.

Math: Ovaj modul sadrži klase sa konvecijalnim metodama za obračunavanje sa različitim matematičkim proračuna , kao što je trigonometrija. Linearna alerba i verovatnoća

Assets: Ovaj modul sadrži klase za učitavanje i smeštanje „assets“, kao što su teksture, bitmap fontovi, particle efekti, pixmaps, UI skinove, tile (pločice), mape, zvukovi, muzika.

Scenes: Ovaj modul sadrži klase za kreiranje 2D scenskih grafova koji se koriste za koriščenje UI elemenata kao što su , meniji i HUD.

Utils: Ovaj modul ima ulogu kao švajcarski nož. Ovaj modul podržava čitanje i upisivanje u XML-u i JSON-a (sa podrškom za serilizaciju).

12

6. ŽIVOTNI CIKLUS APLIKACIJE KOJA SE RAZVIJA SA LIBGDX-om

Sa boljim razumevanjem core modula koji su sastavni deo LibGDX, možemo sada da pogledamo kako izgleda životni ciklus tipične igre napravljenje LibGDX-om.

Slika 5. Vizuelni prikaz živtnog ciklusa

Dijagram predstavlja ciklus game petlje, a jedna petlja kroz logiku predstavlja jedan frame. Opis dijagrama i koraka je sledeći:

1. LwjglApplication klasa, će se inicializovati u isto vreme kad i prva instanca, početne klase i konfiguracije koja je prosleđena u njenom konstruktoru. Konstruktor LwjglApplication će inicijalizovati izvestan broj podmodula LibGDX-a, dopunjavajući Gdx (com.badlogic.gdx) klasu za okruženje, statičnim instancama Application, Graphics, Audio, Input, Files i Net modula, koji su navedeni na Slici 4. LwjglApplication će zatim stvoriti nit, koju ćemo nazvati main loop (glavna petlja), životni ciklus te petlje je dok se video igra ne prekine.

2. Sledeći čvor u petlji nakon prve inicilizacije je akcioni čvor, koji se naziva create(). Create() metod je interfejs koji mora biti implementiran kada se pravi video igra, da bi pokrenuli životni ciklus LibGDX-a. Prilikom pokretanja niti game petlje, create() će biti pozvan samo jednom. Ovo je mesto gde bi trebalo da

13

smestimo kod za inicilizaciju video igre, preload assets, inicilizaciju za game screen-ove i podsisteme video igre.

3. Nakon create () metode sledi korak koji predstavlja prvu odluku u petlji, koja se provera na početku svakog ciklusa, tokom game petlje ili jednom u toku svakog frame-a. Test je da se proveri da li video igra i dalje radi ili ne i da nam dozvoli da prekinemo igru ako se stanje promenilo na not running.

4. Pause() je jedan od intefejs metoda koja mora biti implementirana kada se pravi igra. Taj metod garantuje pravilno upravljanje video igrom, na primer u njoj se čuva trenutno stanje video igre.

5. Dispose () je interfejs metod koji garantuje pravilno „ciscenje“ resursa igre, koji su još uvek u upotrebi čak i kad je video igra u procesu da bude „unistena“.

6. Kada je dispose() metoda obavila svoju ulogu, grafički prikaz je „unisten“ ,i oslobađa audio hardver koji je još u upotrebi i onda poziva System.exit ().

7. Tokom ciklusa game petlje ako se stanje „isrtavajuće“ površine promenilo (drawing surface), da li je igra i dalje maksiminizirana pa minizirana, onda se poziva pause(). Kada se ovo završi prelazi se na korak 9.

8. Tokom ciklusa game petljeako se stanje stanje „isrtavajuće“ površine promenilo iz statusa „minimizirana“ u status „maksimizirana“, resume () se poziva. Resume () još jedan interfejs metod koji mora biti implementiran kada se video igra pravi. Ovaj metod garantuje pravilno upravljanje prethodnih „pauziranih“ stanja kao što su, ponovno učitavanje sačuvanih podata iz skladišta.

9. Ovaj korak predstavlja odluku koja odlučuje da li su se dimenzije „iscrtavajuće površine“ promenile ili ne, od zadnjeg ažuriranja frame-a. Ako su se dimenzije promenile prelazi se na korak 10-ti ako ne onda na korak 11-ti.

10. Ako su se dimenzije „iscrtavajuće površine“ promenile od zadnjeg ažurianja frame-a, resize() metod će biti pozvan. Ovo je još jedan metod koji mora biti implementiran, kada se pravi video igra i njegovi parametri predstavljaju nove dimenzije, širini i dužinu u pikselima. Ove informacije su obično prosleđenje displeju ili „iscrtavajućoj površini“ da budu ažurirane kada je tokom sledećeg „render“ poziva. Kada se ovaj korak završi prelazi se na 11-ti korak.

11. Ovaj čvor sa dobija informacije input-a koji je korisnik zadao. Uključuje ažuriranje deltaTime intervala za trenutni frame, ažurira poziciju prsta i beleži „događaje“ koji su prouzrokovani pritiskanjem displeja i slično.Kada je ovaj korak završen prelazimo na 12-ti korak

12. Ovaj čvor obrađuje informacije input-a koji je korisnik zadao. Obično podrazume, prosleđivanje trenutne lokacije prsta, pritiskanje displeja i slično , klasi koja obrađuje input „događaje“ InputProcessor. Kada je ovaj korak završen prelazi se na 13-ti.

14

13. Ovaj čvor ažurira audio resurse za trenutni frame, zatim se prelazi na 14-ti korak.

14. Ovaj čvor predstavlja odluku tj.test da li rendenovati „iscrtavajuću površinu“ ili ne . Ako je potrebno rendenovati, onda se prelazi na 15-ti korak. Ako ne, onda je jedan ciklus game petlje završen i počinje se ponovo od 3-ćeg koraka.

15. Render() je još jedan intefejs metod koji mora da bude implementiran kada se pravi igra. Ovaj metod je najbitniji u životnom ciklusu video igre. Komanda da se prikaže video igra na ekranu game screen-ovi, na displeju se nalaze ovde, zajedno sa obradom UI elemenata, fizičkih proračuna, AI rutina i ažuriranja objekata video igre.

Sledeća slika prikazuje interfejs ApplicationListener, u kome su smešteni create (), resize(), render(), pause(), resume() i dispose() metode.

Slika 6. ApplicatioListiner UML dijagram

Dijagram klase prikazuje ime metoda i njihove tipove, promenljive koje moraju biti implementirane. Mali podsetnik za šta su ove interfejs metode odgovorne:

create (): Ovaj metod se poziva jednom kada je aplikacija kreirana. Ovo je obično najbolje mesto da se smesti ceo kod koji služi za inicilizaciju igre.

Resize( int width,int height: Ovaj metod se poziva svaki put veličina game screen je promenjena i kada igra nije u „pauziranom“ stanju. Takođe se poziva jednom nakon create () metode.

render(): metoda koja je pozvana od strane game petlje svaki put kada rendovanje treba da se izvrši. U ovom metodu se takođe ažuriraju logika video igre.

pause (): Kod Android ovaj metod se poziva kada se pritisne home dugme ili je dolazeći poziv primljen.

resume (): Ovaj metod samo postoji kod Android platforme i on se poziva kada se video igra budi iz pauziranog stanja

dispose (): Ovaj metod se poziva kada je video igra „unistena“. Pre ove metode se poziva pause().

15

7. KONCEPT VIDEO IGRE

Tema ovog diplomskog je RPG (Role Play Game), u suštin ovaj tip je video igre je igra koja ima definisan sistem sa pravilima i radnja se odvija oko jednog lika u nekom zamišljenom svetu.

Jedan od primera RPG igre, je kada igrač preuzme ulogu jednog heroja i učestvuje u raznim bitkama na fizičkom minijaturnom bojnom polju. Ovo se drugačije zove table-top-roleplaying. Drugi primer bi bio pen and paper sistem koji je D&D započeo. Treći primer bi bio CRPG, koji je postao popularan kada su video igre kao što je ,Adventure tekst bazirana igra i grafičke bazirane igre Ultima i Wizards pojavile.

Sada kada smo definisali koncept RPG igre, vreme je da se navede koje karakterstike CRPG video igra u ovom projektu sadrži:

Razvijanje likova statičnim atributima. Kako igrači napreduju u igri i rešava razne izazove, treba da postoji mehanizam koji će igračima omogućiti da ojačaju svog lika. U ovoj igri postoje nekoliko atributa, na primer: strenght ( snaga) kao kriterujum za oružje koje lik može da koristi, kao i za jačinu napada i intellegence (inteligencija) kao kriterijum za koje vrste čini lik može da koristi , kao i da odluči jačinu magičnog napada. Drugi atributi su hit-points (predstavlja koliko lik može da izdrži napad fizičkog tipa pre nego što izgubi život), magic points ( predstavlja koliko čini lik može da iskorsti pre nego što se iscrpi) i experience points (nakon svakog nivoa, postoji set bodova koji lik mora da stekne putem borbe ili zadataka kako bi napredovao do sledećeg nivoa)

Leveling sistem, koji služi da prezentuje koliko je lik postao snažan tokom igre. U ovoj igri nivoi čudovišta se ne rastu u isto vreme kao i novia lika, to znači da kako lik bude napredovao, raniji nivoi i susreti sa neprijateljima će postajati sve lakši i lakši.

Detekcija kolizija, animacija, pomeranje lika i elementi fizike.

NPC likovi u igri sa speech prozorima i imerzivnim dijalozima tipa tree. Drugim rečima interakcija sa stanovnicima u selima i malim gradovima, što je vitalno za sakupljanje informacije o različitim lokacijama i zadacima

Neprijatelji sa zanimljivim sposobnostima, mestima pojavljivanja (spawn points) i AI pathfiding.

Interakcija sa svetom putujući kroz portale i tranzicije između različitih delova mape.

HUD layout koji prikazuje trenutni status health i magic bara. Ovo je bitan igrački element igre, zato što pruža igraču koristan alat koji mogu da koriste da donese ispravne odluke u toku bitke i van bitke.

16

Sistem za upravljenje invertara, koji služi za kao skladište sklupljenih stvari i za opremljanje lika tim stvarima. Upravljenje resursima je vitalna komponenta svakog RPG-a.

Profili za čuvanje i učitvanje sačuvanog stanja ( save and load). Na ovaj način igrači mogu da nastave igru od trenutka gde su stali, kada su zadnji put igrali.

Skriptovane scene da doda elemente priče i drame. Ova karakteristka je inspirisana igrama iz Final Fantasy serijala.

Quest sistem služi proširi i doda sadržaj igre. Ovaj sistem stvara zadatke za igrače, koji nakon uspešnog završetka nagrađuju lika sa zlatom i experience poenima, i takođe daju povoda za istraživanje sveta.

Korisnički interfejs za prodavnice, sa stvarima i transakciju novca. Prodavnica će demonstrirati kako da se pregladuje stvari, kupe i prodaju, kao deo upravljanja resursima tj. valutom u video igri , koja je zlato.

S obzirom na stil video igre koja je tema ovog diplomskog rada, karakterstike koje neće biti deo igre su:

U igri ne postoje drugi creation scree-ovi osim za ime lika i početnih statičnih atributa

Ne postoji izbor klasa lika

Neprijatelji u igri imaju statične nivoe, to znači da neće dinamički napredovati i izjednačavati sa nivom lika.

Ne postoji party sistem za upravljene sa više likova ili borbu sa više neprijatelja od jednom.

Priča nema više završetaka. Priča će napredovati (sa scenama), linearno kako igrač bude rešavao zadatke

Nema skill stabla zato što u ovoj video igri ne postoji takav sistem

Borba će biti potezna, nema borbe u realnom vremenu

Svet video igre je kreiran tile editorima i setom zadataka, tako da nema proceduralnog generisanog sadržaja

Ova igra je kreirana da bude igrana od strane jednog igrača. Dakle nema multiplayer.

8. PRAVLJENJE I EDITOVANJE TILE-BASED MAPE

17

Lokacije za ovaj projekat, su napravljenje koristeći tiles, to su sprites u obliku kvadrata. LibGDX ima ugrađenu podršku za ovaj tip mapa, tako da je najlakše raditi sa njima. Najednostavniji metod da se naprave ovi tipovi mapa, jeste preko tile-based editora. Editor korišćen za ovaj projekat je Tiled.

Slika 7. Tiled editor

Opis elemenata na koji mogu da se vidi na slici su sledeći:

Map View (1): Ovaj deo editora, je gde su prikazane mape i koje se mogu editovati pojedinačno. Nove mape se kreiraja tako što se otvori pod meni File zatim New. Kada se prikaže novi prozor New Map prvo se biraju dimenzije Tile size, za ovaj projekat dimenzije su 16x16. Nakon toga se bira Map Size koja predstavlja veličinu mape u unit veličini. Na primer ako je mapa 100x100 units, i ako je Tile Size 16x16 piksela, veličina mape je onda 1600x1600 piksela.

Layers(2): Ovo predstavlja različite slojeve, trenutno učitane mape. Postoji 6 tipova slojeva:

o Background_layer: Ovo predstavlja prvi sloj kreiran za tilemap. Ovo je element koji se koristi za „zemljane“ elemente (trava, voda, putevi...)

o Ground_layer: Ovo je drugi sloj kreiran tilemap. Ovaj sloj se koristi da prikaže zgrade ili druge objekte kao što su planine, drveće i sela.

18

o Decoration_layer: Treći sloj sadrži elemente koji se koriste da ukrase okolinu, sa ciljem da otklone ponavljanje i učine scene interesatnijim.

o MAP_COLLISION_LAYER: Četvrti sloj je specijala sloj dizajniran da bude sloj objekata. Ovaj sloj ne sadrži tiles ali ima objekte i oblike. Ovo je sloj koji se koristi da bi se napravile oblasti gde NPC i heroj igre ne mogu putovati, kao što su zidovi zgrada, planine, okean i dekoracije kao što je fontanta.

o MAP_SPAWN_LAYER: Peti sloj je još jedan specijalni sloj, dizajniran samo za igrača i NPC tačke pojavljivanja, kao na primer ljudi u gradovima. Ove tačke pojavljivanja, predstavljaju različite početne lokacije, gde se likovi prvi put rendenuju na mapi.

o MAP_PORTAL_LAYER: Ovo je zadnji sloj dizajniran da uzrokuje događaje, koji omogućuju kretanje od mape do mape. Drugim rečima ovo je lokacija, kroz koju igrač može da prođe i time pokreće prelaz na drugu mapu.

TileSets (3): Ovaj deo editora predstavlja sve tilesets koji su korišćeni za trenutnu mapu.Svaki tileset ili sprite sheet, dobija svoj sopstveni tab, što olakšava kretanje među njima. Dodavanje novog tileset-a je lako, sve što treba da se uradi je da se klikne New ikona u Tilesets area.

Properties(4): Ovaj deo editora predstavlja dodatna svojstva koja možemo iskoristi za selektovan element mape, kao što je tile ili objekat. Sledeći primer, demonstrira kada properties mogu biti korisne. Kada napravimo objekat tipa portal, na sloju portala, možemo kreirati svojstvo koje definiše ime ovog objekta tipa portal koji predstavlja mapu, koja će se učitati. Dakle, kada dođemo do tile koja izgleda kao grad i pokrenemo događaj, znamo tačno da mapa koja će se učitati je TOWN, zato što ime svojstva ovog objekta tipa portal je TOWN.

Sada kada smo se upoznali sa kako da se koristi Tiled editor za ovaj projekat, obradićemo mape kreirane za video igru. Prva slika je mapa TOWN, to je lokacija gde heroj prikuplja informacije od stanovnika, preuzima zadatke, i kupuje oružje i oklop. Grad ima prodavnice, krčmu, kao i nekoliko malih kuća koje pripadaju lokalnim stanovnicima.

19

Slika 8. Town mapa

Sledeća slika je TOP_WORLD mapa, koja predstavlja lokaciju gde se heroj vodi bitke, pronalazi tragove za rešavanje zadataka i vremenom stigne do zamka gde se krije zadnji neprijatelj. Na slici može da se vidi kako je „zlo“ počelo da se širi i uništiva useve i obradivu zemlju.

Slika 9. TOP_WORLD mapa

20

Konačno zadnja mapa je mapa zamka, nazvana CASTLE_OF_DOOM, gde se odvija zadnja bitka, kada heroj postane dovoljno snažan. Ovde će se heroj susreti sa najačim neprijateljima, kao i sa stvarima najboljeg kvaliteta.

Slika 10. CASTLE_OF_DOOM mapa

9. IMPLEMENTACIJA POČETNIČKIH KLASA ZA PROJEKAT

Sada kada su mape za različite lokacije projekta napravljenje, možemo početi sa programiranjem inicijalnih delova, kako bi učitali ove mape i kretali se po svetu video igre.

21

Slika 11. Dijagram početnih klasa

Ovaj dijagram klasa služi da prikaže ne samo klase već i relacije između klasa. Glavna ulazna tačka projekta je AndroidLauncher, koja će inicijalizovati Alternia i dodati zajedno sa par informacija o konfiguraciji LibGDX-ovom životnom ciklusu. Alternia je izvedena iz klase Game kako bi smanjili posao potreban da se implementira životni ciklus, koji je neophodan za ApplicationListener interfejs. Alternia održava sve screen-ove za video igru. MainGameScreen je glavni gameplay screen koji prikazuje različite mape i igrača koji se kreće po njima. MainGameScreen takođe kreira MapManager, Entity i PlayerController. MapManager se sastoji od pomoćnih metoda za upravljanje različitim mapama i njihovim slojevima. Entity je glavna klasa za lika kog igrač kontroliše u igri. PlayerController implementira InputProcessor i to je klasa kontroliše igračev input i sadrži kontrole. Na kraju, tu je Utillity klasa koja sadrži nekoliko pomoćnih metoda za učitvanje asset-a, koji se koriste u projektu.

9.1 Opis AndroidLauncher klase

AndroidApplication klasa je odgovorna za upravljanje događajima koji menjaju veličinu, rendenovanje površine i upravljanje aplikacijom tokom njenog životnog ciklusa. AndroidApplication pruža module za obračunavanje sa grafikom, audiom, input i upravljanjem I/O, logovanje, informacije o memorijskom footprint-u i hooks za proširujuće biblioteke.AndroidApplicationConfiguration definiše svojstva objekta i instance početne klase, Alternia, i onda ih prosleđuje backend implementaciji AndroidApplication klase

22

public class AndroidLauncher extends AndroidApplication { @Override protected void onCreate (Bundle savedInstanceState) { super.onCreate(savedInstanceState); AndroidApplicationConfiguration config = new AndroidApplicationConfiguration(); initialize(new Alternia(), config); } }

9.2 Opis Alternia klase

Game klasa je abstrakna klasa koja obmotava ApplicationListener intefejs i prepušta implementaciju ovog interfejsa Screen klasi. Ovo pruža pogodnost postavljanja video igre sa različitim screen-ovima, uključujući jedan za glavni meni, opcije, scene i gameplay.

MainGameScreen je primarni gameplay screen, koji će igrač videti dok bude pomerao heroja, po svetu igrice.

Kasnije u toku dalje demonstracije implementacije projekta, otkrićemo ostale screen-ove koje klasa Alternia poseduje, za sada je samo MainGameScreen bitan. Metoda create () mora da se override-uje, kako bi postavili početni screen, kada se Alternia inicijalizuje i postane deo životnog ciklus igre. setScreen() metod služi da proveri da li je screen aktivan. Ako je aktivan, onda će on biti skriven, dok screen koji je već bio prosleđen metodi prikazan umesto njega. Takođe je potrebno da se override-uje metoda dispose(), zato što Alternia poseduje reference screen objekta. Bitno je da se uvek rešimo objekata kako treba, kada izlazimo iz igre.

10. IMPLEMENTACIJA ASSET MENADŽERA SA UČITVANJEM TEKSTURA I MAPA

Glavni fokus ovog poglavlja je klasa Utility. Ona predstavlja, placeholder za raznovrsne metode uključujući i metode za učitavanje i rasterećivanje game asset-e.

23

ublic class Alternia extends Game { public static final MainGameScreen _mainGameScreen = new MainGameScreen();

@Override public void create(){ setScreen(_mainGameScreen); }

@Override public void dispose(){ _mainGameScreen.dispose(); }}

10.1 Opis klase Utillity

Sledeći dijagram Utillity klase prikazuje atribute i vrednosti metoda implementacije.

Slika 12. Dijagram Utillity klase

Grafika video igre je rasterskog tipa, što znači da će biti prikazana pikslelima sa specifičnim bojama i njihovim vrednostima. Alternativa je vektorska grafika, ali razlog zašto nije korišćena u projektu je zato što ima težak uticaj na perfomase.

Da bi premostili jaz od slike koja je predstavljena 2D nizom u 3D prostor OpenGL-a, sve slike moraju biti transformisane u teksture. Onda, je neophodno mapirati teksturu u geometriju koju GPU može obraditi i prikazati. Zatim je neophodno, otpremiti ovu informaciju direktno GPU platforme, da bi se renderovalo na displeju. LibGDX olakšava ceo proces, tako što obmotova sve ove funkcionalnosti i abstraktuje svu kompleksnost klasom Texture.

Texture klasa svaki put kada se učitava asset tipa slika i da pomogne sa upravljanjem grafičkih asset-a video igre.

TextureLoader klasa predstavlja asset loader za teksture. Ono na šta treba obratiti pažnje je da se podaci o teksturama, učitavaju po default-u asinhrono, što znači da se prvo treba pobrinuti da pre nego što koristimo neki asset sa TextureLoader on prvo bude učitan.

InternalFileHandleResolver klasa se koristi za upravljanje fajlova, na primer za definisanje radnog direktorijuma, putanje do određenog asset-a i slično.

TiledMap klasa naslađeju Map klasu, ona predstavlja generalizovanu implementaciju mape. Map je osnovna klasa koja sadrži samo svojstva mape, koja opisuju generalne atribute i slojeve. TiledMap klasa proširuje funkcionalnost sa dodatnim poljima za tiles i tilesets.

TmxMapLoader je pogodna klasa za učitavanje TMX baziranih tilemaps i smešta ih kao TiledMap instance. AssetManager klasa upravlja učitavanjem i skladištanjem asset-a: teksture, pixmaps...

24

UnloadAsset metod je pomoćni metod koji proverava da li je asset učitan i ako jeste, onda će rasteretiti asset iz memorije.

LoadCompleted metod prikazuje progres AssetManager-a, koliko je procenata ostalo do zavšetka. NumberAssetsQueued beleži koliko je preostalo asset-a preostalo da se učita iz liste AssetManager-a. UpdateAssetLoading obmotova poziv za ažuriranje i može biti pozvan u render () petlji ako se assets učitavaju asinhrono, kako bi se obradila preload lista. IsAssetLoaded vraća da li je asset učitan ili ne.

LoadMapAsset metod preuzima putanju TMX fajla koja je relativna sa radniom direktorijumu i učita TMX fajl kao TiledMap asset. LoadTextureAsset metod preuzima putanju slike koja je relativna sa radnom direktorijumu i učitava sliku kao Texture asset.

11. IMPLEMENTACIJA KAMERE I MAPE U RENDER PELJI

MainGameScreen klasa predstavlja glavni gameplay screen, i koristi se da prikaže mapu, avatara heroja i UI elemente.

25

public static void unloadAssets (String assetFilenamePatch){ if (_assetManger.isLoaded(assetFilenamePatch)){ _assetManger.unload(assetFilenamePatch); }else{ Gdx.app.debug(TAG, "Asset is not loaded; Nothing to unload : " + assetFilenamePatch); }}

public static float loadCompleted(){ return _assetManger.getProgress();}

public static int numberAssetsQueued(){ return _assetManger.getQueuedAssets();}

public static boolean updateAssetLoading(){ return _assetManger.update();}

public static boolean isAssetLoaded (String fileName){ return _assetManger.isLoaded(fileName);}

11.1 Klasa MainGameScreen

Slika 13. Dijagram MainGameScreen klase

Dva primarne metode u Screen klasi koja moraju da se override-uju su: show() i hide(). Kada se nov postavi sa setScreen() metodom u Alternia klasi, pozvaće se hide() metod na trenutni screen i show() na novi screen. Zato što trenutno ne prelazimo preko implementacije ostalih screen-ova, hide () metoda je prazna. U show () metodi prvo postavimo viewport sa dimenzijama 10x10.

26

@Overridepublic void show(){ setupViewport(10,10); orthographicCamera= new OrthographicCamera(); orthographicCamera.setToOrtho(false, VIEWPORT.viewportWidth,VIEWPORT.viewportHeight);

mapRenderer= new OrthogonalTiledMapRenderer(_mapMgr.getCurrentMap(),MapManager.UNIT_SCALE); mapRenderer.setView(orthographicCamera);

Gdx.app.debug(TAG, "Unit scale value is : " + mapRenderer.getUnitScale());

_player= new Entity(); _player.init(_mapMgr.getPlayerStartUnitScaled().x , _mapMgr.getPlayerStartUnitScaled().y);

currentPlayerSprite=_player.getFrameSprite();

_controller= new PlayerController(_player); Gdx.input.setInputProcessor(_controller);

}@Overridepublic void hide(){}

Jedinica za ovu dimenziju je unitScale atribut koji mapira koorditni sistem tiled mapem, od screen piksel koordinata u realne koordinate (world coordinates ). Jedna od prednosti unitScale-a je u tome što se pojednostavlja detekcija kolizije. Ako imamo piksel poziciju (160, 320), koja bi predstavlja poziciju na mapi, ona ne odaje tačno relativnu poziciju tile, tile mape. Ali ako su tile 16 piksela, možemo postaviti unitScale da bude 1/16, tako da umesto pozicije (160, 320) dobijemo (10,20) što je mnogo lakše razumeti.

Kamera koristi glavni konstruktuor OrthographicCamera. OrthographicCamera klasa koristi ortografsku projekciju da prezentuje 3D objekte u 2D prostoru. Metoda setToOrtho() treba da bude false, kako bi koordinatni sistem imao pozitivan y smer. OrthogonalTiledMapRenderer preuzima vrednosti Tiledmap i unitScale.

MainGameScreen sadrži takođe statičnu instancu Entity, koja predstavlja igrača u video igri.

Metod render() se poziva za svako frame i on je primarna lokacija za rendonovanje, ažuriranje, proveru kolizije tokom životnog ciklusa igre. Prva stvar koju treba uraditi jeste da centriramo viewport (poziciju kamera), na trenutnu poziciju igračevog lika, tako da je lik uvek na sredini screen-u. Zatim se provera da li je igrač aktivirao portal, provera kolizije sa slojem kolizije mape i ako kolizija postoji, neće se ažurirati pozicija lika. Na kraju isrctavamo lika na screen-u, ali bitno je da se pozove getBatch() metoda, kada veliki broj objekata treba da se ažurira. Na taj način se rasterečuje GPU, zato što će primati i obrađivati jednu strukturu u jednom trenutku, umesto svaku posebno istovremeno.

27

@Overridepublic void render (float delta){ Gdx.gl.glClearColor(0,0,0,1); Gdx.gl.glClear(GL20.GL_COLOR_BUFFER_BIT);

orthographicCamera.position.set(currentPlayerSprite.getX(), currentPlayerSprite.getY(), 0f); orthographicCamera.update();

_player.update(delta); currentPlayerFrame = _player.getFrame();

updatePortalLayerActivation(_player.boundingBox);

if (!isCollisionWithMapLayer(_player.boundingBox)){ _player.setNextPositionToCurrent(); }

_controller.update(delta);

mapRenderer.setView(orthographicCamera); mapRenderer.render();

mapRenderer.getBatch().begin(); mapRenderer.getBatch().draw(currentPlayerFrame , currentPlayerSprite.getX(), currentPlayerSprite.getY(),1,1);

mapRenderer.getBatch().end();}

Metoda setupViewport(), služe za korišćenje unutrašnje klase VIEWPORT. To je klasa koja nudi pogodnosti za održavanje svih parametara koji čine viewport kamere. Takođe ova klasa brine o tome da održava pravilan aspect ration.

Metoda isCollisionWithMapLayer (), se poziva za svaki frame u render() metodi, sa likovim pravougaonim objektom. To je objekat koji definiše dodirnu tačku lika, ako se u bilo kom trenutku ivica pravougaonika preklapa sa objektima, iz sloja kolizije, onda je došlo do kolizije.

28

private boolean isCollisionWithMapLayer(Rectangle boundingBox){ MapLayer mapCollisionLayer=_mapMgr.getCollisionLayer();

if (mapCollisionLayer == null){ return false; }

Rectangle rectangle=null;

for (MapObject object:mapCollisionLayer.getObjects()){ if (object instanceof RectangleMapObject){ rectangle=((RectangleMapObject)object).getRectangle(); if(boundingBox.overlaps(rectangle)){ return true; } } } return false;}

private boolean updatePortalLayerActivation(Rectangle boundingBox){ MapLayer mapPortalLayer= _mapMgr.getPortalLayer();

if(mapPortalLayer== null){ return false; }

Rectangle rectangle= null;

for (MapObject object: mapPortalLayer.getObjects()){ if (object instanceof RectangleMapObject){ rectangle = ((RectangleMapObject)object).getRectangle(); if(boundingBox.overlaps(rectangle)){ String mapName = object.getName(); if(mapName== null){ return false; } _mapMgr.getClosestStartPositionFromScaledUnits(_player.getCurrentPosition()); _mapMgr.loadMap(mapName); _player.init(_mapMgr.getPlayerStartUnitScaled().x, _mapMgr.getPlayerStartUnitScaled().y); mapRenderer.setMap(_mapMgr.getCurrentMap());

} }

Metoda updatePortalLayerActiviation () je slična isCollisionWithMapLayer, zato što ima sličan način provere kolizije. Glavna razlika je da ako dođe do kolizije sa specijalnim lokacijama, pokrenuće se poseban dođaj (event), koji nas obaveštava da je igrač aktivirao portal. Kada se portal aktivira prvo se kešira najbliža tačka pojavljivanja (spawn point), u klasi MapManager, na taj način prelazak iz stare u novu lokaciju i nazad je jednostavniji. Zatim se učitava nova mapa koja je definisana specifičnim imenom portala, restartuje se likova pozicija i rendenuje se nova mapa, u sledećem frame-u.

12. IMPLEMENTACIJE MAPE SA SPAWN I PORTALIMA

12.1 Opis MapManager klase

MapManager klasa poseduje pomoćne metode za učitavanje TiledMap mapa, kao i metode za pristup različitim MapLayer i MapObject objektima u slojevima.

29

Slika 14. Dijagram MapManager klase

Koriste se TiledMap(TXT format) mape, koje se rendenuju instanci Screen koristeći OrthogonalTiledMapRenderer klasu u rendenovoj niti. Svaka mapa poseduje nekoliko MapLayer objekta čiji redosled počinje od indeksa 0. Postoje i drugi MapLayer objekti koji se ne rendenuju već sadrže MapObject koji se koriste za testiranje kolizije, portalovih pokretača (triggers) i tački pojavljivanja ( spawn). Početna pozicija i lika u igri i njegova trenutna pozicija se realizuje Vector2. Ova klasa se je implementacija 2D vektora, koje možemo da iskoristmo za definisanje pozicije.

Za ovu iteraciju MapManager klase, koriste se dva kontenjera za menadžment mapa. Prvi kontenjer je HashTable, u kome se smeštaju relativne putanje TMX fajlova. Ključevi koji

30

public MapManager(){ _playerStart = new Vector2(0,0); _mapTable = new Hashtable(); _mapTable.put(TOP_WORLD, “maps/topworld.tmx”); _mapTable.put(TOWN, “maps/town.tmx”); _mapTable.put(CASTLE_OF_DOOM, “maps/castle_of_doom.tmx”);

_playerStartLocationTable = new Hashtable();

_playerStartLocationTable.put(TOP_WORLD, _playerStart.cpy()); _playerStartLocationTable.put(TOWN, _playerStart.cpy()); _playerStartLocationTable.put(CASTLE_OF_DOOM, _playerStart.cpy());

_playerStartPositionRect = new Vector2(0,0); _closestPlayerStartPosition = new Vector2(0,0); _convertedUnits = new Vector2(0,0);}

se koriste za haširanje su statični stringovi, definisani od strane MapManager-a. Drugi kontenjer je takođe HashTable koji služi da kešira najbližu tačku pojavljivanja lika, na trenutno učitanoj mapi. Ključevi za kešitanje su takođe statični stringovi definisani od strane MapManager-a.

Metod loadMap() je metod čija je uloga da proveri, da li je string koji je prosleđen dodeljen validnoj putanji i da proveri da li asset postoji. Ako postoji onda ga učita, takođe se kopiraju reference objekata različitih slojeva, za brz pristup kasnije, kao što je sloj kolizije, sloj portala i sloj tački pojavljivanja.

Меtod getPlayerStartUnitScaled() konvertuje je početnu lokaciju lika iz piksel koordinata u unit koordinate. Tako da kada se ovaj metod pozove lik će se pojaviti na ispravnoj lokaciji.

31

public void loadMap(String mapName){ _playerStart.set(0,0); String mapFullPath = _mapTable.get(mapName); if( mapFullPath == null || mapFullPath.isEmpty() ) { Gdx.app.debug(TAG, “Map is invalid”); return;. }

if( _currentMap != null ){ _currentMap.dispose(); } Utility.loadMapAsset(mapFullPath); if( Utility.isAssetLoaded(mapFullPath) ) { _currentMap = Utility.getMapAsset(mapFullPath); _currentMapName = mapName; }else{ Gdx.app.debug(TAG, “Map not loaded”); return;

public Vector2 getPlayerStartUnitScaled(){ Vector2 playerStart = _playerStart.cpy(); playerStart.set(_playerStart.x * UNIT_SCALE, _playerStart.y * UNIT_SCALE); return playerStart;}

Меtod setClosestStartPosition(), kešira najbližu lokaciju trenutne mape na kojoj se lik pojavio. Ovo se koristi kada se portal aktivira kako bi se lik pozicionirao na pravilnu početnu lokaciju, kada putuje iz nove lokacije ka staroj. Takođe koristi se dst2() metoda iz klase Vector2, uglavnom kada se provera distanca između objekata, bitna je relativna ne apsolutna distanca. Аko bi hteli da dobijemo absolutnu distancu, trebamo da izračunamo koren vrednosti i to je kompleksna operacija koja ima uticaj na perfomanse.

13. IMPLEMENTACIJA IGRAČEVOG LIKA SA ANIMACIJOM

13.1 Opis Entity klase

Entity klasa predstavlja primarni objekat video igre, uključujući lika kog igrač kontroliše kao i likove u igri koji nemogu da se kontrolišu (NPC), koji mogu da se kreću i imaju interakciju sa okruženjem.

32

private void setClosestStartPosition(final Vector2 position) {

_playerStartPositionRect.set(0, 0); _closestPlayerStartPosition.set(0, 0); float shortestDistance = 0f;

for (MapObject object : _spawnsLayer.getObjects()) { if (object.getName().equalsIgnoreCase(PLAYER_START)) { ((RectangleMapObject) object).getRectangle(). getPosition(_playerStartPositionRect); float distance = position.dst2(_playerStartPositionRect); if (distance < shortestDistance || shortestDistance == 0) { _closestPlayerStartPosition.set( _playerStartPositionRect); shortestDistance = distance; } }

_playerStartLocationTable.put( _currentMapName, _closestPlayerStartPosition.cpy()); }

Slika 15. Dijagram Entity klase

TextureRegion se koristi često priliko kreiranje igre i ona je primarni kontenjer za korišćenje grafickih asset-a ( slika). Sledeća slika ilustruje kako se TextureRegion klasa može upotrebiti.

Slika 16. Primena TextureRegion klase

Kada se učita asset tipa slika, on se smešta u Texture objekat klase AssetManager, korišćenjem loadTextureAsset () i getTextureAsset() pomoćnih metoda iz Utillity klase. Texture objekat, uključuje celu koja se sastoji od 16 sprites. Da bi uspostavila referensa za specifičan sprite (za rendenovanje), TextureRegion može da se iskoristi, da bi se pristupilo podregiji Texture objekta.

Druga klasa Animation je vizuelno prikazana na sledečoj slici:

33

Slika 17. Vizuelni opis Animation klase

Kada god se Animation objekat konstruiše, prosleđuje je se frame tokom njegovog trajanja, TextureRegion reference i tip petlje koja je korišćena za animiranje tih TextureRegion.Svaka TextureRegion, je indeksovan keyframe koji predstavlja jedan frame u ciklusu animacije. Neka animacija se sastoji od kruženja keyframe-ova, za vreme trajanja cele animacije.

Metoda update() se poziva za svaki objekat igre pre nego što se rendenuje. Jedno od stanja koje je mora da se održava da bi sve proteklo glatko tokom ciklusa animacije je frameTime, to je ustvari samo hrpa delta između ažuriranja frame-ova. Stvar na koju treba obrati pažnju je da zavisno od toga koliko se video igrica, dobra ideja bi bilo da se rast promeljive ograniči na neku fiksnu vrednost, kako bi sprečili ponavljanje ili još gore preklapanje. U ovo primeru fiksna vrednost je 5 sec, tj. frameTime se restartuje na svakih 5 sekundi.

34

public void update(float delta){ _frameTime = (_frameTime + delta)%5; setBoundingBoxSize(0f, 0.5f);}

Metod setBoundingBoxSize () nam omogućava da menjamo dodirnu tačku različitih entiteta. Zavisno od grafike tileset-a, glavna oblast dodirne tačke za igrača je širina i dužina sprite-a. Ovo može uzrukovati probleme se putuje kroz šumovite predele sa kolizijskim pravoguaonicima ili kretanje u podnožju planina ili da plovenje po jezeru. Rešenje je da se širina tačke dodira smanji na pola, odnosno dodirna tačka pravougaonika je od struka pa do podnožja lika. Ovo pruža bolji osećaj kretanja lika i takođe izgleda mnogo bolje kada se kreće kroz prepreke.

35

public void setBoundingBoxSize(float percentageWidthReduced, float percentageHeightReduced) {

float width; float height; float widthReductionAmount = 1.0f - percentageWidthReduced;

float heightReductionAmount = 1.0f - percentageHeightReduced;

if (widthReductionAmount > 0 && widthReductionAmount < 1) { width = FRAME_WIDTH * widthReductionAmount; } else { width = FRAME_WIDTH; } if (heightReductionAmount > 0 && heightReductionAmount < 1) { height = FRAME_HEIGHT * heightReductionAmount; }else{ height = FRAME_HEIGHT; } if( width == 0 || height == 0){ Gdx.app.debug(TAG, "Width and Height are 0!! " + width + ":" + height); } float minX; float minY; if( MapManager.UNIT_SCALE > 0 ) { minX = _nextPlayerPosition.x / MapManager.UNIT_SCALE; minY = _nextPlayerPosition.y / MapManager.UNIT_SCALE; } else{ minX = _nextPlayerPosition.x; minY = _nextPlayerPosition.y; } boundingBox.set(minX, minY, width, height);}

Metod loadAnimation () se jedino poziva kada prvo inicijalizuju objekti entiteta. Za ovu iteraciju ove video igre, sprite sheet za animaciju lika izgleda kao na slici 16. Texture, uključuje celu sliku koja se sastoji od 16 različitih sprite-ova. Svaki red predstavlja različiti smere animacije od četiri frame, kao što je „hodaj dole“, „ hodaj levo“, „hodaj desno“, „hodaj gore“. Kada je potrebno da se sprite razdvoje tako da se koriste pojedinčno koristi se split() metoda TextureRegion klase, prosleđujući Texture i širiniu i dužinu dimenzija koje predstavljuju jedan sprite. Tada dobijamo niz TextureRegion objekata koji predstavljaju pojedinačne keyframe-ove za animaciju. Ovi objekti mogu da se rendenuju, zato što svaka TextureRegion referenca specifira podregiju Texture. Zatim možemo uzeti ove nizove TextureRegion objekata i kreirati četiri Animation objekta za svaki smer.

36

private void loadAllAnimations(){

Texture texture = Utility.getTextureAsset (_defaultSpritePath); TextureRegion[][] textureFrames = TextureRegion.split (texture, FRAME_WIDTH, FRAME_HEIGHT); _walkDownFrames = new Array<TextureRegion>(4); _walkLeftFrames = new Array<TextureRegion>(4); _walkRightFrames = new Array<TextureRegion>(4); _walkUpFrames = new Array<TextureRegion>(4); for (int i = 0; i < 4; i++) { for (int j = 0; j < 4; j++) { TextureRegion region = textureFrames[i][j]; if( region == null ){ Gdx.app.debug(TAG, "Got null animation frame " + i + "," + j); } switch(i) { case 0: _walkDownFrames.insert(j, region); break; case 1: _walkLeftFrames.insert(j, region); break; case 2: _walkRightFrames.insert(j, region); break; case 3: _walkUpFrames.insert(j, region); break; } } } _walkDownAnimation = new Animation(0.25f, _walkDownFrames, Animation.PlayMode.LOOP); _walkLeftAnimation = new Animation(0.25f, _walkLeftFrames, Animation.PlayMode.LOOP);

Metod setDirection() ažurira animacione keyframe-ove zavisno od trenutnog smera. Ovaj metod se poziva svaki put kada se obrađuje input sa liste događaja. Tokom svakog frame-a, render petlje, trenutni TextureRegion frame igračevog heroja se preuzme i rendenuje.

Metod calculateNextPosition se pozove svaki put kada se detektuje igračev input.

37

public void setDirection(Direction direction, float deltaTime) { this._previousDirection = this._currentDirection; this._currentDirection = direction;

switch (_currentDirection) { case DOWN: _currentFrame = _walkDownAnimation.getKeyFrame(_frameTime); break; case LEFT: _currentFrame = _walkLeftAnimation.getKeyFrame(_frameTime); break; case UP: _currentFrame = _walkUpAnimation.getKeyFrame(_frameTime); break; case RIGHT: _currentFrame = _walkRightAnimation. getKeyFrame(_frameTime); break; default: break; }}

public void calculateNextPosition(Direction currentDirection, float deltaTime){ float testX = _currentPlayerPosition.x; float testY = _currentPlayerPosition.y; _velocity.scl(deltaTime); switch (currentDirection) { case LEFT : testX -= _velocity.x; break; case RIGHT : testX += _velocity.x; break; case UP : testY += _velocity.y; break; case DOWN : testY -= _velocity.y; break; default: break; } _nextPlayerPosition.x = testX; _nextPlayerPosition.y = testY;

_velocity.scl(1 / deltaTime);

Ponekad kolizija nije detektovana tokom ažuriranja frame-a za to što je ubrzanje previše brzo da bi se izračunalo u trenutnom frame-u. Do vremena kada sledeći frame proveri koliziju, objekti igrice će proći jedan kroz drugi. U suštini ovaj metod predstavlja jedan način za detektovanje kolizije između dva koja su u pokretu. Da bi se rešio ovaj problem, treba da se „predvidi“ sledeća pozicija koju trenutno ubrzanje koristi i vreme potrebno da se rendenuje zadnji frame. Ako se pomnoži trenutni vektor ubrzanja _velocity sa skalarom deltaTime, koristeći sc1() metod, dobijamo vrednost koja predstavlja pomeraj. Zatim se pomeraj sabira ili oduzima sa sledećom pozicijom zavisno od smera.

14. Implementacija kontrola

14.1 Opis PlayerController klase

Ova klasa je odgovorna za upravljanje svim input događajima i pruža mehanizme za obradu tih događaja u listi čekanja. Radi lakšeg testiranja ovog projekta, implementirane su kontrole za desktop pc računare, kao i kontrole za Android platformu.

Slika 18. Dijagram PlayerController klase

38

InputProcessor je interfejs koji se implementira kako obradili input događaji kao što su: prevlačenje prsta, pozicija dodira prsta na displeju, kretanje kursora, detektovanje pritusnutih tastera miša i tastature.

Metode keyDown () i keyUp(), obrađuju input korisnika, tj. detektuju kada su tasteri pritisnuti a kada ne, tako što ih keširaju u Hashtable objekat. Ovo omogućava da se input obradi kasnije i za eleminisanje suvišnih key događaja sa liste.

39

@Overridepublic boolean keyDown(int keycode) { if( keycode == Input.Keys.LEFT || keycode == Input.Keys.A){ this.leftPressed(); } if( keycode == Input.Keys.RIGHT || keycode == Input.Keys.D){ this.rightPressed(); } if( keycode == Input.Keys.UP || keycode == Input.Keys.W){ this.upPressed(); } if( keycode == Input.Keys.DOWN || keycode == Input.Keys.S){ this.downPressed(); } if( keycode == Input.Keys.Q){ this.quitPressed(); } return true;}

@Overridepublic boolean keyUp(int keycode) { if( keycode == Input.Keys.LEFT || keycode == Input.Keys.A){ this.leftReleased(); } if( keycode == Input.Keys.RIGHT || keycode == Input.Keys.D){ this.rightReleased(); } if( keycode == Input.Keys.UP || keycode == Input.Keys.W ){ this.upReleased(); } if( keycode == Input.Keys.DOWN || keycode == Input.Keys.S){ this.downReleased(); } if( keycode == Input.Keys.Q){ this.quitReleased(); } return true;}

Metode touchDown () i touchUp(),obrađuju input korisnika, tj. detektuju kada su tasteri miša pritisnuti ili kada je displaj dodirnut prstom a kada ne , tako što ih keširaju u Hashtable objekat. Ovo omogućava da se input obradi kasnije i za eleminisanje suvišnih događaja sa liste.

Metoda processInput() je glavna business logika ove klase. Prilikom početka svakog frame-a u render petlji, processInput () se poziva pre nego što se rendenuje grafika. Ovo je trenutak kada se input koji keširan obrađuje. Prvo se izračuna sledeća pozicija, kao što je objašnjeno u prethonom poglavlju, kako bi izbegli problem, objekata koji se prebrzo kreću, sudaraju i pritom zaobilaze detekciju kolizije.

40

@Override public boolean touchDown(int screenX, int screenY, int pointer, int button) { if( button == Input.Buttons.LEFT || button == Input.Buttons.RIGHT ){ this.setClickedMouseCoordinates(screenX, screenY); }

if( button == Input.Buttons.LEFT){ this.selectMouseButtonPressed(screenX, screenY); } if( button == Input.Buttons.RIGHT){ this.doActionMouseButtonPressed(screenX, screenY); } return true; } @Override public boolean touchUp(int screenX, int screenY, int pointer, int button) { if( button == Input.Buttons.LEFT){ this.selectMouseButtonReleased(screenX, screenY); } if( button == Input.Buttons.RIGHT){ this.doActionMouseButtonReleased(screenX, screenY); } return true; }

15. Zaključak

U ovom projektu obradili smo kako se projektu i dizajnira jedna RPG video, specifično CRPG. Koje osobine treba da ima i obrazložili razloge iza tih odluka. Takođe smo obradili proces projektovanja video igre, prešli preko bitnih pitanja vezano sa izbor plaftorme, engine-a i framework-a. Na koje stvari treba obratiti pažnju prilikom njihvog izbora, koji se problem javljaju i kako ih prevazići ili napraviti kompromis.

Glavni alat za realizaciju ovog projekta je LibGDX. Obradili smo tematiku zašto baš taj alat, koje su prednosti u odnosu na ostale i zbog čega se smatra jednim od najpogodnih rešenja za početnike. Takođe smo obradili samu arhitekturu ovog framework-a u detaljima.

Ostatak projekta se tiče samog temelja video igre. Prvo smo obradili mape, specifično tile-based mape, zbog čega baš njih i kako da se naprave koristeći Tiled editor. Nakon toga smo detaljno obradili arhitekturu high-level klasa i implentaciju početničkih klasa koje se koriste za povezivanje LibGDX-ovog životnog ciklusa sa video igrom ovog projekta.

Dalje naučili smo o teksturama, TMX formatiranim tile mapama i kako da se upravlja sa asset menadžerom. Jedan od najvažnijih i osnovnih koncepta ovog projekta je ortogonalna kamera, obradili smo kako ona funkcioniše i kako se implementira. Takođe je detaljno objašnjeno kako se prikazuje mapa sa unutar render() petlje.

Implementacija menadžera mapa koji je neophodan za detekciju kolizije, definisanje tački pojavljivanja i implementaciju sistema za portale koji omogućavaju igraču da se kreće između lokacija je takođe obrađen.

I na samom kraju opisano je kako se implementira lik ili heroj, kog igrač kontroliše. Kao i kako se on animira, tj. detaljna procedura animacije i implementacija kontrola, kako bi igrač mogao da kontroliše heroja

Ovaj projekat je namenjen da ilustruje i objasni osnovnu proceduru projektovanja i dizajn jedne RPG igre, kroz primere implementacije, dokumentaciju i slike ali može se da se koristi i kao referensa za druge koncepte video igrica, zato što teme koje su obrađene kroz ovaj projekat su univerzalne.

41

16. Literatura

1. https://en.wikipedia.org/wiki/List_of_game_engines2. Swords & Circuitry: A Designer's Guide to Computer Role Playing Games. Roseville,

CA: Prima Tech, 2001. Print. 3. Nystrom R. Game Programming Patterns. Genever Benning. 9780990582908. Web.

04 Apr. 2015

4. https://libgdx.badlogicgames.com/nightlies/docs/api/

5. https://github.com/libgdx/libgdx/wiki

6. Beginning Android Games by Robert Green, Mario Zechner (Paperback 2012)

42