Gymnázium Jozefa Gregora TajovskéhoTajovského 25, 974 01 Banská Bystrica

STREDOŠKOLSKÁ ODBORNÁ ČINNOSŤ

č. odboru: 11Informatika

AIRDANCE – realizácia multiplatformovej aplikácie typu klient – server

Riešiteľ2013 Juraj PančíkSlovenská Ľupča ročník štúdia: tretí

Gymnázium Jozefa Gregora TajovskéhoTajovského 25, 974 01 Banská Bystrica

STREDOŠKOLSKÁ ODBORNÁ ČINNOSŤ

č. odboru: 11Informatika

AIRDANCE – realizácia multiplatformovej aplikácie typu klient – server

Riešiteľ2013 Juraj PančíkSlovenská Ľupča ročník štúdia: tretí

KonzultantDoc. RNDr. Juraj Pančík, CSc.

Čestné prehlásenie

Ja, Juraj Pančík, čestne prehlasujem, že som prácu „AIRDANCE – realizácia multiplatformovej aplikácie typu klient – server“ vypracoval sám za pomoci uvedenej literatúry.

V Slovenskej Ľupči, 1. marca 2013

Juraj Pančík

Poďakovanie

Chcem sa poďakovať mojim rodičom za všetku podporu pri tvorbe tejto práce. Vytvárajú mi

doma prijemné prostredie, kde veľmi rád pracujem. Sú ochotní tolerovať, že neraz ostávam

do neskorého večera za počítačom.

Mojim spolužiakom a triednej učiteľke z Gymnázia Jozefa Gregora Tajovského za ich vždy

prítomnú podporu a motiváciu.

Obsah

1 Úvod.........................................................................................................................3

2 Problematika a prehľad literatúry............................................................................4

2.1 Úvod do vývoja mobilných aplikácií................................................................4

2.2 Definícia pojmov aplikácia a mobilná aplikácia..............................................4

2.3 Definícia architektúry klient – server...............................................................4

2.4 Definícia platformy...........................................................................................4

2.5 Definícia multiplatformovej mobilnej aplikácie..............................................5

2.6 Životný cyklus aplikácie...................................................................................5

2.7 Správa požiadaviek a procesné modely............................................................5

2.8 Modelovanie aplikácií v jazyku UML..............................................................6

3 Ciele práce...............................................................................................................7

3.1 Hlavný cieľ práce.............................................................................................7

3.2 Čiastkové ciele práce........................................................................................7

4 Materiál a metodika.................................................................................................8

4.1 Opis vývoja AIRDANCE.................................................................................8

4.2 Opis projektu AIRDANCE.............................................................................11

5 Výsledky práce.......................................................................................................16

6 Závery práce a diskusia..........................................................................................17

7 Zhrnutie..................................................................................................................18

8 Resumé...................................................................................................................19

9 Zoznam použitej literatúry.....................................................................................20

10 Zoznam príloh a obsah DVD-ROM/elektronickej prílohy................................21

2

1 Úvod

V každodennom živote sa v rozvinutých krajinách stretávame s viacerými

elektronickými zariadeniami, ktoré sú založené na nových mobilných platformách.

Zvládnutie uceleného riešenia pre vývoj na tieto platformy by poskytovalo ohromnú

príležitosť na pracovnom trhu a zároveň zefektívnenie prác v existujúcich organizáciách.

Mobilné aplikácie poskytujú pre ešte neznámych a mladých vývojárov, takých ako

som ja, jedinečnú možnosť ako sa presadiť a možno spôsob, ako si na seba v budúcnosti

zarobiť.

Predmetom tejto práce je opis kompletného procesu vývoja multiplatformovej

mobilnej aplikácie - hry, typu klient – server s názvom AIRDANCE. Zmysel použitia

architektúry typu klient – server som videl v čoraz väčšej potrebe používateľov po sociálnom

kontakte pri používaní mobilných aplikácií. Navyše, prezentovaná mobilná aplikácia je hra,

kde je takýto kontakt preferovaný. Multiplatformová aplikácia spočíva v tom, že mnou

navrhnutá aplikácia je spustiteľná na rôznych platformách, t.j. operačných systémoch (napr.

smartfón s operačným systémom Android alebo personálny počítač s operačným systémom

Windows alebo Linux a podobne).

Cieľom predkladanej práce je nielen navrhnúť a zrealizovať multiplatformovú

aplikáciu AIRDANCE,  ale aj zrealizovať efektívne riešenia pre všetky problémy, ktoré sa

pri takomto vývoji môžu vyskytnúť. Každý, kto si prečíta túto prácu, by mal dostať prehľad

o základných problémoch a ich riešeniach pri multiplatformovom vývoji.

Skúsenosti s vývojom hry pre mobilné zariadenia som mal už pred začatím projektu

AIRDANCE (operačný systém Android, hra Meteorites – dá sa stiahnuť z Google Play).

Chcel som sa však vo vývojárskej  práci zdokonaliť a postupovať a pracovať podľa určitých

princípov vývoja softvéru (Pančík, 2012).

V druhej kapitole sa venujem definícii pojmov, sú tam opísané niektoré zo

základných postupov pri vývoji mobilných aplikácií. Tretia kapitola jasne a stručne deklaruje

hlavný a vedľajšie ciele tejto práce. Ďalej, v štvrtej kapitole, je popísaná kompletná metodika

vývoja, od požiadaviek, ktoré vyplývajú z cieľov práce, cez ich rozvoj až ku ich finálnej

implementácii aplikácie. Práca nerieši len teoretickú úroveň problému, ale aj praktickú.

Výsledky práce, závery a diskusia sa nachádzajú za štvrtou kapitolou.

3

2 Problematika a prehľad literatúry

2.1 Úvod do vývoja mobilných aplikácií

Mobilné aplikácie sú v tejto dobe veľmi rozšírené a je to ideálna cesta pre mladých

vývojárov na získanie nových zákazníkov. Atraktívnosť tejto mobilnej platformy však

predstavuje nové problémy. Často je väčšina problematiky zdokumentovaná priamo od

výrobcu mobilnej platformy, avšak počas vývoja a testovania sa prakticky nedá nenaraziť na

problémy, ktoré sú jedinečné pre dané zariadenie. Je veľmi veľa typov mobilných zariadení,

ktoré majú rozdielne veľkosti obrazoviek, rôzne veľkosti pamäte RAM alebo aj rôzny výkon

grafického procesora a výpočtového procesora. Nehovoríme o rozdielnych rozhraniach medzi

jednotlivými komponentmi zariadenia, ako napríklad kamera, prístup k internetu alebo

zvukové a grafické drajvre. Vývoj je veľmi náročný, ale dobre navrhnutý systém je schopný

fungovať na väčšine zariadení bez problémov.

2.2 Definícia pojmov aplikácia a mobilná aplikácia

Aplikácia je súhrn programov, jedného alebo viacerých. Programy sa špecializujú na

jednotlivé aktivity, ako vykreslenie na obrazovku alebo načítavanie z dát. Program je

formulácia jedného alebo viacerých algoritmov v programovacom jazyku. Algoritmus

vyznačuje presný a jednoznačný postup na vyriešenie konkrétneho problému. Dôležitosť

algoritmu je v tom, že ho môžeme viac krát opakovať a má deterministický výsledok na

základe vstupu (Pour, a iní, 2009) .

2.3 Definícia architektúry klient – server

Aplikácia klienta (ďalej len klient) je aplikácia, ktorá je spustená u koncového

používateľa. Server je služobná aplikácia (ďalej len server) pre klientsku aplikáciu, zaisťuje

mu spracovanie jeho špecializovaných požiadaviek. U serverov sa predpokladá, že sú

spustené ihneď po štarte operačného systému, aby boli trvalo dostupné klientom. Klient má

preddefinovaný súbor požiadaviek a server je navrhnutý a zrealizovaný na základe znalosti

tohto súboru, preto server je veľmi úzko spätý s klientom (Pour, a iní, 2009) .

2.4 Definícia platformy

Platforma zahŕňa hardvérovú architektúru a softvérový programový rámec, ktorého

kombinácia umožňuje aplikačnému softvéru (t.j. aplikácii) beh. Platformy zvyčajne obsahujú

operačný systém, programovací jazyk a grafické rozhranie pre používateľa (WIKI, 2013).

4

2.5 Definícia multiplatformovej mobilnej aplikácie

Multiplatformová mobilná aplikácia je schopná bežať na viacerých platformách,

v našom prípade je aspoň jedna z nich mobilná. Napríklad, to môže byť platforma

personálneho počítača PC a Android, teda mobilná, platforma.

2.6 Životný cyklus aplikácie

Aplikácia od svojho počiatku prechádza svojimi vývojovými fázami a po určitej dobe svojho

chodu a rozvoja sa vracia na svoj začiatok, kde sa pripravuje vyššia úroveň aplikácie pre danú

oblasť, založená na nových aktuálnych technológiách a zodpovedá celkom novým potrebám

používateľov (Arlow, a iní, 2008).

Životný cyklus aplikácie sa delí takto:

1. Plánovanie a príprava aplikácie

2. Analýza a návrh aplikácie

3. Implementácia aplikácie

4. Zavedenie do chodu, migrácia

5. Chod a používanie aplikácie

6. Rozvoj a optimalizácia aplikácie

2.7 Správa požiadaviek a procesné modely

Rozlišujeme dva typy požiadaviek:

Funkčné – špecifikujú požiadavky na funkčnosť systému

Nefunkčné – špecifikujú isté vlastnosti systému, prípadne podmienky

obmedzujúce fungovanie systému.

Požiadavky by mali vyjadrovať to, čo bude systém ponúkať, a nie ako by to mal robiť.

Požiadavka je teda špecifikácia funkcie alebo vlastnosti systému. Zlyhanie správy

požiadaviek môže viesť ku kompletnému zlyhaniu funkčnosti projektu (Kanisová, a iní,

2007).

Procesné modely sa rozdeľujú na diagram hierarchie procesov a diagram procesných

vlákien. Diagram hierarchie procesov rozkladá procesný rozpad systému a pomáha nám

ujasniť rozsah vyvíjaného systému, jeho modularitu a vzájomné súvislosti medzi

jednotlivými procesmi na ich najvyššej úrovni. Diagram procesných vlákien je veľmi

zrozumiteľný aj pre človeka ktorý o ňom nikdy nepočul. Touto technikou modelujeme

udalosti, ktoré inicializujú spúšťanie firemných procesov a taktiež výsledok procesu.

5

Procesný reťazec je začatý vstupnou udalosťou a ukončený procesným výsledkom (Kanisová,

a iní, 2007).

2.8 Modelovanie aplikácií v jazyku UML

Modelovací jazyk UML (Unified Modeling Language, Zjednotený Modelovací Jazyk)

je výsledkom snaženia analytikov a dizajnérov o nájdenie metódy ktorá efektívne a

prehľadne umožní popísať objektovo orientovanú analýzu a návrh. K tomuto slúžia grafické

diagramy. Jazyk UML poskytuje možnosť modelovať jednoduché aj zložité aplikácie

jednotným jazykom. Vizuálne modely sú veľmi jednoducho pochopiteľné a možno ich

jednoducho navrhnúť. Je to jazyk na vizualizáciu, špecifikáciu, stavbu a dokumentáciu

softvérových systémov (Kanisová, a iní, 2007) (Arlow, a iní, 2008).

6

3 Ciele práce

3.1 Hlavný cieľ práce

Hlavným cieľom práce je navrhnúť a  zrealizovať aplikáciu – hru typu klient – server

s názvom AIRDANCE, kde klient bude spustiteľný a zároveň plne funkčný na viacerých

platformách. To znamená, že naša aplikácia musí mať rovnaké, deterministické správanie na

počítači typu PC a aj na mobilnom zariadení s operačným systémom Android. Klient musí

byť schopný pracovať nezávisle od servera a ak je možné sa pripojiť na server, asynchrónne

bude aktualizovať a získavať dáta, ktoré sa následne klientom zobrazia. Server musí byť

schopný fungovať nepretržite a odpovedať na požiadavky od viacerých klientov.

3.2 Čiastkové ciele práce

1. Klient sa musí vedieť prispôsobiť na všetky typy obrazoviek (displejov),

pretože nemôžeme dopredu predpokladať aké parametre bude mať platforma

na ktorej je klient spustený.

2. Ako grafická aplikácia, je nutné čo najviac optimalizovať spôsob

vykresľovania pre čo najlepší výsledok a plynulosť aj na starších zariadeniach

každej platformy.

3. Klient je perzistentný, to znamená, že ukladá svoje dáta na disk tak, aby vedel

z nich obnoviť stav po znovu spustení.

4. Server by mal byť odolný na pokusy o narušenie bezpečnosti a taktiež by mal

vedieť vyhodnotiť, kedy je vstup od klienta nesprávny, to znamená, že nebol

odoslaný od autentického klienta.

5. Komunikácia medzi serverom a klientom musí byť ochránená pred rušením

siete a jej výpadkami.

6. Server počíta s nečakanými vypnutiami, napríklad kvôli výpadku elektrickej

energie, a preto by mal pravidelne zálohovať všetky uložené dáta klientov a po

výpadku by mal byt schopný ich znova načítať.

7

4 Materiál a metodika

4.1 Opis vývoja AIRDANCE

4.1.1 Požiadavky na AIRDANCE

Ako prvú vec si potrebujeme zadefinovať súbor požiadaviek pre klientsku aplikáciu:

1. Aplikácia musí byť spustiteľný a plne funkčný program na rôznych

platformách, t.j. pod Windows a na mobilných zariadeniach so systémom

Android

2. Musí existovať grafické rozhranie na vykresľovanie aplikácie

3. Aplikácia sa bude prispôsobovať veľkosti okna v ktorom beží

4. Aplikácia sa vie pripojiť na server, vie poslať a získať z neho dáta

5. Aplikácia ukladá svoj stav na lokálny disk, aby sa vedela doňho po opätovnom

spustení dostať

6. Chceme urobiť interaktívnu aplikáciu, konkrétne jednoduchú hru, používateľ

bude dvoma prstami ovládať naklonenie svojho vznášadla a stúpať cez

náhodne generovaný „level“, a ak narazí do steny, odošle svoje skóre na server

pod ľubovoľným menom, ktoré zadá

Ďalej nasledujú požiadavky aplikácie určenej pre server:

1. Server musí byť program spustiteľný na operačnom systéme typu Linux kvôli

jeho jednoduchému hostingu (bezproblémový chod a inštalácia serverového

programu)

2. Server ukladá svoj stav na lokálny disk v časovom intervale kvôli menšiemu

zaťaženiu

3. Server by mal byť schopný odpovedať viacerým klientom naraz, bez

uprednostňovania jednotlivých klientov

4. Server môže bežať nepretržite aj niekoľko dní bez reštartu

5. Server musí zachytávať pokusy o narušenie integrity a bezpečnosti servera,

ktoré efektívne eliminuje a zároveň informuje o nich správcu

6. Server odpovedá klientovi na žiadosti o výške skóre pre meno, alebo

všeobecne vráti klientovi určitý počet najvyšších skóre, tiež prijíma správy

o navýšení skóre

8

4.1.2 Analýza

Klient by mal byť založený na jednotnej báze kódu, ktorá bude pracovať s knižnicou

ktorá skrýva do seba dve rozdielne implementácie ľubovoľnej jej funkcie pre každú

platformu. Takto sme schopní neduplikovať kód aplikácie, a veľmi sa zjednodušuje vývoj.

Grafická knižnica by mala byť čo najrýchlejšia pre každú platformu. Dáta ukladané na

lokálny disk musia byť uložené v binárnej alebo textovej forme. Aplikácia musí zachytávať

vstup a mať prístup na internet.

Server ukladá svoj stav na disk tiež v binárnom alebo textovom formáte. Po štarte

servera musí najprv načítať dáta, až potom začne vybavovať žiadosti. Tiež musí ukladať

logovacie výpisy na disk, aby mal ku ním správca jednoduchý prístup.

4.1.3 Návrh

Ako ideálne riešenie pre klienta je použiť voľne dostupné knižnice, ktoré umožňujú

multiplatformový vývoj. Tieto knižnice poskytujú základný prístup ku jednotnej grafickej

knižnici pre všetky platformy, zachytávanie vstupu a výstupu zvuku. Ako grafickú knižnicu

je vhodné použiť takú, ktorá používa rasterizáciu ako kresliaci proces a táto je akcelerovaná

grafickým procesorom. Je to najefektívnejšia metóda a aj najrýchlejšia, hlavne na pomalších

Android zariadeniach. Dáta sa jednoduchšie ukladajú v textovej forme, a preto ich stačí držať

všetky, ktoré chceme uchovať, v jednom objekte a tento ich vždy zoserializuje do reťazca

znakov, ktorý sa dá následne jednoducho uložiť. Aplikácia by mala fungovať aj bez prístupu

na internet.

Server bude tiež svoje dáta ukladať v textovom formáte a všetky jeho dáta budú

uložené v jednom objekte, ktorý sa následne pri ukladaní na disk, zoserializuje. Keďže miesto

na disku nie je neobmedzené, server musí kontrolovať pri ukladaní, či netreba uvoľniť miesto

pre kompletné uloženie dát.

4.1.4 Implementácia

Čo sa týka programovacieho jazyku, ideálna voľba je Java, pretože je flexibilná

a dokáže okamžite fungovať na všetkých zariadeniach s implementovanou Java Virtual

Machine. Pre Javu je ako multiplatformová knižnica dostupná open-source knižnica

LibGDX, ktorá má zjednotený vstup a poskytuje vhodnú jednotnú grafickú rasterizačnú

knižnicu OpenGL a jednotnú zvukovú knižnicu OpenAL. Je určená pre vývoj aplikácií

a preto ma množstvo pomocných funkcií pre vývoj herných aplikácií. Na ukladanie dát je

možno použiť formát JSON, ktorý je často používaný aj na webových stránkach

9

využívajúcich JavaScript. Ak chceme serializovať a deserializovať formát JSON v Jave,

oplatí sa použiť knižnicu Gson kvôli jej malej veľkosti. Dáta by mali byť ukladané priebežne,

nakoľko používateľ môže ukončiť aplikáciu v ktoromkoľvek momente. Hra sa skladá

z obrazoviek, ako napríklad hlavná obrazovka, alebo obrazovka hry. Tieto obrazovky

obsahujú prvky používateľského rozhrania ako tlačidlá, ktoré sa budú prispôsobovať veľkosti

obrazovky v ktorej beží aplikácia. Všetko iné, ako prvky používateľského rozhrania, budú len

adekvátne zmenšené alebo zväčšené. Na pripojenie ku serveru možno použiť TCP protokol,

ktorý zaručuje bezchybný presun informácií medzi klientom a serverom. Ak sa chceme

vyhnúť natívnej implementácie TCP protokolu v Jave, môžem použiť knižnicu KryoNet.

Server použije tiež Gson serializáciu a KryoNet na odpovedanie klientom. Dáta bude

ukladať vo forme rotovacích súborov, to znamená, že naraz bude uložených napríklad

posledných 5 dní. Ak server potrebuje načítať dáta, jednoducho prevezme poslednú zálohu.

Vypisovanie logovacích zápisov bude tiež vo forme rotovacích súborov.

4.1.5 Testovanie

Testovanie klienta prebehne na Windowse a viacerých Android zariadeniach. Klient

musí minimálne byť spustiteľný, hrateľný a musí sa vedieť pripojiť na server, odoslať

a získať z neho dáta. Prvky používateľského rozhrania musia byť plne viditeľné a dobre

rozložené na každej obrazovke aplikácie. Zlyhanie tejto podmienky by znamenalo možnosť,

že bude aplikácia nepoužiteľná na niektorých zariadeniach. Ak má byť klientska aplikácia

uverejnená, treba vytvoriť zoznam minimálnych požiadaviek na zariadenie, aby sa potom

dala vylúčiť podpora istých zariadení.

Server musí spĺňať viacero podmienok, musí vždy spracovať všetok vstup ktorý

dostane, a deterministicky musí vrátiť rovnaký výstup pre každú žiadosť od klienta. Ďalej by

mal byť schopný zvládnuť viacero klientov naraz, server by tiež mal byť schopný sa vrátiť do

stavu pred výpadkom, preto treba testovať aj tieto varianty.

10

4.2 Opis projektu AIRDANCE

4.2.1 Zahájenie

Na zahájenie potrebujeme pripraviť všetky potrebné nástroje. Nainštalujeme vývojové

prostredie Netbeans, na vývoj a spúšťanie aplikácií na Androide Eclipse SDK + ADT Plugin,

Android SDK, program na prácu s grafikou GIMP, program na prácu so zvukom Audacity.

Veľmi užitočná vec pri väčších projektoch je aj verziovanie kódu, my sme použili Git

s hostovaním na BitBucket.org. Stiahneme knižnice LibGDX, KryoNet, Gson a  sme

pripravený na vývoj.

4.2.2 Plánovanie projektu

Keďže z návrhu možno vidieť, že server bude maličká aplikácia oproti klientskej, je

rozumným krokom začať vývoj najprv s klientom a keď je hotový z väčšej časti klient,

možno pristúpiť ku vývoju servera.

V klientovi bude najprv na implementovaná základná štruktúra LibGDX, následne

začne implementácia tzv. „engin-u“ (jadra) hry, ktorý sa bude starať o celú hernú logiku.

Herná logika sa skladá z náhodného generovania levelov, fyzikálnej simulácie vznášadla a

detekcii kolízií so stenami levelu. Hra bude prakticky jeden level, ktorý sa vždy vygeneruje

dopredu podľa potreby. Ide o to, ako keby vznášadlo letelo cez neustále sa meniacu jaskyňu.

Potrebné bude procedurálne generovať prekážky pred sebou a zároveň zabúdať prekážky za

sebou, aby sa limitovalo množstvo využitej pamäte pre hernú logiku. Jaskyňa môže byť

zložená z horizontálnych obdĺžnikov na ľavej a pravej strane, ktoré budú vždy rovnako

vysoké. Na detekciu kolízií budeme používať polygón definovaný okrajmi nášho vznášadla

a spomenuté prekážkové obdĺžniky. Ak je prienik polygónu s niektorým prekážkovým

obdĺžnikom, môžeme povedať, že vznášadlo zhavarovalo a malo by vybuchnúť, teda hra sa

skončí. Keď bude implementovaná kompletná herná logika, to znamená už možno letieť, buď

dvoma prstami na zariadení Android alebo ľavou a pravou šípkou na Windowse cez náhodne

generovaný level, bude sa dať naraziť do steny, po čom hra skončí, začnú sa pridávať herné

prvky, ako ukladanie záznamov, t.j. akú najväčšiu vzdialenosť vznášadlo prešlo bez

narazenia a bonusové predmety so skóre, ktoré sa dajú zbierať. Skóre sa potom sčítava a hráč

si môže zaň zakúpiť vylepšenia vznášadla alebo iný výzor vznášadla. Rekord vzdialenosti

a skóre budú ukladané na disk a budú sa uchovávať medzi jednotlivými spusteniami

aplikácie. Potom sa môže pristúpiť ku implementácii prvkov používateľského rozhrania ako

sú tlačidlá, alebo text na obrazovke, vytváraniu samotných obrazoviek a aj zvukových

11

efektov. Takto je prakticky takmer celá klientska aplikácia hotová a môžeme pristúpiť ku

vývoju servera. Server bude mať voči klientovi nasledovné správanie: po tom ako sa klient

pripojí, pošle mu náhodne vygenerovaný identifikačný kľúč, ktorým sa musí vždy klient

identifikovať. Potom môže klient pracovať so serverom troma rôznymi spôsobmi. Buď si

vyžiada od serveru skóre najvyšších niekoľko miest pre časový interval vo formáte

<deň/týždeň/mesiac>, alebo si vyžiada skóre od serveru pre všetky mená ktoré začínajú

textom, ktorý klient zadal tiež pre formát <deň/týždeň/mesiac>, alebo pridá skóre pre nejaké

meno. Server drží pre každé meno tieto premenné, sčítané skóre a hodnotu rekordnej

vzdialenosti, drží ich trikrát pre deň, týždeň a mesiac. Každý deň, týždeň a mesiac sa o

polnoci vymažú pre daný časový interval všetky údaje. Potom si uloží na disk stav, a ak je

záloh viac ako zadaná konštanta, vymaže tú poslednú existujúcu.

4.2.3 Realizácia projektu

Hlavná kostra grafickej knižnice LibGDX sa skladá zo šiestich členských funkcií –

inicializácia aplikácie, vykreslenie aplikácie, zmena veľkosti aplikácie, prerušenie aplikácie,

pokračovanie po prerušení aplikácie a ukončenie aplikácie. Vykreslenie bude volané najviac

60 krát za sekundu, takže nie je nutné implementovať vlastný časovač. V štarte aplikácie

načítame všetky grafické podklady, aby sme ich následne vedeli vykresľovať, uvoľníme ich

z pamäte až keď sa aplikácia ukončí. To isté platí aj pre zvukové súbory. Všetko ostatné bude

uložené v objekte obrazovka, ktorý bude mať členské funkcie – inicializácia, aktualizácia,

vykreslenie hry, vykreslenie prvkov používateľského rozhrania a ukončenie. Rasterizácia

používa na vykresľovanie matice, konkrétne projekčnú maticu, pohľadovú maticu a svetovú

maticu. Keď máme bod v priestore a vynásobíme ho týmito troma maticami, dostaneme

súradnice x a y ktoré reprezentujú pozíciu na obrazovke. Svetová matica slúži na posunutie

bodu v priestore, pohľadová matica zas upraví polohu bodu podľa toho ako by sme ju videli

a projekčná prevedie bod na finálne dve súradnice. LibGDX poskytuje pomocný objekt

ortografická kamera ktorá pomáha pre dvojrozmerné priestory vytvoriť pohľadovú maticu.

Toto nám umožňuje jednoducho približovať a odďaľovať pohľad. Preto budú v aplikácii

existovať dve ortografické kamery. Jedna bude slúžiť na vykreslenie herného sveta, to

znamená bude sa pohybovať a odďaľovať podľa veľkosti obrazovky, aby sa na každej

obrazovke približne vykreslila rovnaká časť herného sveta. Druhá bude pre prvky

používateľského rozhrania, bude vždy centrovaná na stred obrazovky. Vykresľovanie

aplikácie bude prebiehať takto:

1. Zachytí sa všetok vstup z klávesnice a myšky

12

2. Zavolá sa metóda aktualizácia na objekt obrazovky, ktorá ju aktualizuje aj na

základe vstupu

3. Vyčistí sa obrazovka od posledného vykresleného obrázku

4. Ako pohľadová matica sa nastaví tá ktorú vygeneruje herná ortografická

kamera

5. Zavolá sa metóda vykreslenie hry ktorá vykreslí engine hry

6. Pohľadová matica sa zmení na ortografickú kameru pre prvky

používateľského rozhrania

7. Zavolá sa metóda vykreslenie prvkov používateľského rozhrania

Obrazovka môže počas svojej aktualizácie zmeniť aktuálnu obrazovku za inú,

napríklad používateľ v obrazovke hlavného menu stlačí tlačidlo na spustenie hry, obrazovka

hlavného menu oznámi, že terajšia obrazovka sa má zmeniť na obrazovku hlavnej hry a už od

ďalšieho vykreslenia je aktuálna obrazovka hlavnej hry. Takto sa zabalí každá obrazovka do

vlastného objektu a zjednodušuje vývoj pre jednotlivé obrazovky. V konečnej hre je

implementovaných niekoľko rôznych obrazoviek ale poďme sa bližšie pozrieť na realizáciu

obrazovky rebríčka skóre a obrazovky hlavnej hry. Obrazovka hlavnej hry obsahuje engine

v ktorom je zakomponovaná celá logika hry, ďalej obsahuje prvky používateľského

rozhrania. Engine obsahuje viacero komponentov:

Level Manager sa stará o generovanie levelu a zisťuje či nejaký bod koliduje

s levelom

Entity Manager obsahuje všetky entity, v tomto prípade to je vznášadlo alebo jeho

časti

Collision Manager pri každej aktualizácii skontroluje či žiadny s bodov ktorý definuje

polygón vznášadla nekoliduje

Particle Manager sa stará o vizuálne efekty, ako napríklad výbuchy

Čo sa týka používateľského rozhrania, všetky prvky sú zadefinované pomocou

horizontálneho priradenia a vertikálneho priradenia. To znamená že tlačidlo môžeme

napríklad umiestniť horizontálne zľava posunuté o 50 pixlov a vertikálne zo spodku posunuté

o 25 pixlov. Tlačidlo je teda vždy zarovnané, nezáleží na veľkosti obrazovky, problém však

nastáva, ak by bola obrazovka tak malá, že by sa niektoré tlačidla mali prekrývať. Preto sme

implementovali nasledujúce riešenie. Ak je veľkosť obrazovky menšia ako 800 pixlov na

šírku alebo 480 pixlov na výšku, obidve ortografické kamery ostanú na veľkosti 800 pixlov

a 480 pixlov a následne sa premietnu na menšiu obrazovku. To znamená, že ak je obrazovka

13

menšia, používateľské rozhranie sa prestane zarovnávať a namiesto toho je zarovnané podľa

obrazovky 800 krát 480 pixlov akurát sa proporčne zmenší, tak aby presne pasovalo na

obrazovku. Uveďme si príklad, máme tlačidlo zarovnané z ľavého horného rohu o 10 pixlov

doľava a 10 pixlov dole. Používateľ má obrazovku o veľkosti 800x480 a tlačidlo je

zarovnané rovnako ako zadefinované. Obrazovka sa zmení na 1280x800 a tlačidlo stále

nezmení svoju veľkosť ani pozíciu. Avšak obrazovka sa následne zmení na 320x240 kde sa

tlačidlo zarovná podľa 800x480 a celý obraz sa zmenší na 320x240. Všetky prvky

používateľského rozhrania sú navrhnuté tak, aby fungovali pre 800x480. Týmto spôsobom je

zaručené že na všetkých veľkostiach obrazovky sa nebudú prekrývať. Avšak pri Android

zariadeniach narazíme aj na iný problém. Ak sú fyzicky dve obrazovky rovnako veľké,

neznamená to, že majú rovnaké rozlíšenie obrazovky, teda ak toto zanedbám, na niektorých

zariadeniach môžu byť tlačidla menšie. Preto pri spustení aplikácie je nutné zaznamenať dots

per ich hodnotu a ak je nutné, trošku ju zmenšiť. Potom stačí veľkosť tlačidla, jeho veľkosť

posunutia vynásobiť touto hodnotou, a naša aplikácia sa stáva DPI Independent, čo

v preklade znamená, že tlačidla budú mať rovnakú veľkosť na dvoch zariadeniach, ktoré

majú rovnakú fyzickú veľkosť displeja ale rozdielne hodnoty dpi. Týmto by sme mohli

ukončiť obrazovku hlavnej hry a prejsť ku obrazovke rebríčka skóre. Táto obrazovka

obsahuje viacero tlačidiel, ale podstatné je získavanie dát zo servera. Je nutné aby hra bola

responzívna aj keď chce vyžiadať dáta zo servera. Preto treba presunúť celé získavanie na

separátne vlákno procesora. Vlákno reprezentuje proces v počítači, vieme počúvať hudbu

a surfovať internet bez toho, aby sa hudba zasekávala, pretože dekódovanie hudby prebieha

na jednom threade a zas surfovanie na druhom. Presne rovnako je nutné, aby sa to správalo

pri získavaní dát. Vyžiadame dáta a zároveň ukazujeme používateľovi že aplikácia čaká na

odpoveď zo servera. Rovnaký princíp sa použije aj pri odosielaní dát. Použitie vlákien

predstavuje niekoľko synchronizačných problémov, ktoré treba vyriešiť, inak by sa aplikácia

mohla správať nedeterministicky. Ešte za zmienku pri klientovi stojí spôsob ako ukladá dáta

na disk. Všetky sú uložené v objekte profile ktorý je raz za sekundu skontrolovaný, či sa

v ňom niečo zmenilo. Ak áno, cez knižnicu Gson je zoserializovaný do reťazca znakov, ktorý

je triviálne uložiť na disk. Pri štarte aplikácie je zas profil deserializovaný zo súboru na disku,

ak existuje, čím sa uchováva stav medzi spusteniami. A takto sa dostávame ku realizácii

serveru. Najprv si presne zadefinujme čo bude server a klient medzi sebou posielať. Je to

správa o identikačnom kľúči klienta, správa o získaní skóre pre vrchných niekoľko skóre

alebo správa o navýšení skóre pre dané meno. Server teda pri spustení najprv skontroluje

súbor, v ktorom je uložený zoznám posledných záloh. Ak súbor existuje a nie je prázdny,

14

server deserializuje, znova s pomocou knižnice Gson, dáta a nastaví ich do svojho skladu.

Následne server otvorí TCP socket na porte 54555 a začne prijímať správy. O túto časť sa

stará KryoNet, poskytuje jednoduché rozhranie na odosielanie a príjem dát, s jedinou

nevýhodou, že server bude spracovávať dáta len na jednom threade. To je však zanedbateľné

pri malej aplikácii ako je táto. Server ma zapnutý timer ktorý oznamuje kedy má server

resetovať dáta pre deň, týždeň a mesiac. Timer tiež určuje kedy sa majú zoserializovať dáta

na disk. Po dokončení prác nasleduje poriadne pretestovanie každého komponentu.

O testovanie serveru sa postará jednoduchý klient, ktorý vygeneruje niekoľko mien a tie

pošle na server, následne server musí pre každú správu o stave skóre korektne odpovedať. Čo

sa týka testovania viacerých platforiem, je dôležité otestovať každú obrazovku hry na

viacerých počítačoch a zároveň aj na viacerých Android zariadeniach, ideálne na zariadení

s rozlíšením menším, rovným a väčším ako 800 pixlov na šírku a 480 na výšku.

4.2.4 Ukončenie

Po realizácii projektu ostáva ešte server niekde spustiť, teda nájsť miesto pre hosting.

Keďže server sa správa ako normálna Java SE aplikácia, nie je možné nájsť hosting zadarmo.

V čase písania práce je server spustený u mňa doma na maličkom počítači o veľkosti

kreditnej karty tzv. Raspberry Pi. Je to veľmi slabučký server, aj keď úplne ideálny pre

testovacie účely. Server by sme chceli časom presunúť na cloudový hosting od Amazon Web

Services, kde je prvý rok zadarmo. Keďže aplikácia je plne funkčná na Android zariadeniach,

ďalším krokom je uverejnenie na Google Play Store aby si to mohla stiahnuť široká

verejnosť.

15

5 Výsledky práce

Po ukončení prác nám vznikla hrateľná interaktívna multiplatformová aplikácia

s architektúrou klient - server s názvom AIRDANCE.

Aplikácia klient pozostáva z okolo 9500 riadkov kódu v programovacom jazyku

JAVA a aplikácia server z okolo 900 riadkov v JAVA, ktoré som sám napísal a odladil.

S pomocou hardvérovo akcelerovaného rasterizátora vykresľuje klientská aplikácia

AIRDANCE grafické podklady dodané v bežných formátoch. Prehráva hudbu a zvukové

efekty. Obsahuje kompletný herný systém, kde hráč môže preposielať svoje skóre na server,

vie zo serveru získať svoje skóre a skóre ostatných hráčov. Obsahuje náhodne generované

úrovne s prekážkami, vznášadlo, ktoré je založené na fyzikálnej simulácii a používateľ je

schopný svoje vznášadlo vylepšovať alebo meniť jeho výzor.

Klient je multiplatformovaný, funguje na väčšine dostupných počítačoch a navyše na

Android zariadeniach.

Zrealizovaný server AIRDANCE je schopný dlhodobého behu, zálohy vitálnych dát

a vie odpovedať viacerým klientom naraz. Klientská aplikácia sa okrem iného prispôsobuje

všetkým typom obrazoviek, čo je hlavne ideálne pre zariadenia Android. Z pohľadu

objektovo orientovaného dizajnu, dostáva sa nám do rúk projekt s jednoduchou údržbou a s

ľahkým rozvojom funkcionality do budúcnosti.

16

6 Závery práce a diskusia

Po dokončení aplikácie môžeme skonštatovať, že hlavný cieľ projektu AIRDANCE je

splnený. Úspešne sa nám podarilo zrealizovať aplikáciu – hru s architektúrou klient – server

a navyše to, že klient je spustiteľný na viacerých platformách. Podporuje až dokonca 4

platformy: Windows, Linux, Mac, Android.

Čo sa týka vedľajších cieľov, možno povedať, že boli tiež takmer všetky splnené.

Avšak, stále sa nájdu zariadenia, kde aplikácia nie je úplne funkčná, dosť často sa vyskytujú

problémy s klávesnicou na platforme Android alebo problémy s rýchlosťou behu programu.

Aj keď sa klient prispôsobí všetkým typom obrazoviek, pri istých konfiguráciách by sa

mohlo stať, že obraz by bol nepekne roztiahnutý. Položené základy riešenia prvkov

používateľského rozhrania je škálovateľný aj pre nové typy prvkov.

Práca prináša unikátny spôsob riešenia problému optimalizácie pre rôzne veľkosti

obrazovky a dal by sa využiť pri vývoji nielen mobilných aplikácií. Multiplatformovosť ako

taká, je veľmi dôležitý koncept hlavne pri vývoji. Stolný počítač je veľmi rýchly a vývoj len

na ňom nás ušetrí zbytočného presunu binárnych spustiteľných súborov na platformu pre

ktorú vyvíjame. Takto je prakticky možné vyvinúť drvivú väčšinu aplikácie na počítači

a potom ju len spustiť na zariadení s operačným systémom Android.

Server nie je až na toľko robustný, a môže sa v budúcnosti stať, že bude nestabilný.

Tiež nie je maximálne zabezpečený, a používateľ by bol schopný neférovo meniť skóre, aj

keď to je už riziko, ktoré prichádza s tým, že v architektúre máme anonymných klientov. Ak

sa pozrieme na ostatných vývojárov aplikácií pre Android, možno povedať, že sa stýkavajú

s rovnakými problémami a čo sa týka konkrétneho vzťahu klient – server, je teoreticky

nemožné vyvinúť odolný systém pred všetkými útokmi.

Ďalší rozvoj pre túto aplikáciu typu klient – server vidíme v rozširovaní podpory

platforiem. Práve teraz knižnica podporuje aj platformy HTML5 a iOS, akurát na podporu je

potrebné urobiť isté zmeny v kóde, ktoré môžu meniť kompletne celú architektúru aplikácie.

Server má potenciál pre veľký rozvoj a keďže je presne zadefinovaný súbor správ ako sa

môže klient a server dorozumieť, môžeme navrhnúť a vyvinúť kompletne nový server

a pritom spraviť len minimálne zmeny na klientovi. Ak sa stane že útoky na server budú

príliš časté, budeme musieť pristúpiť ku autorizácii klienta cez email a heslo.

17

7 Zhrnutie

Práca sa zaoberá kompletným vývojom multiplatformovej softvérovej aplikácie – hry

s architektúrou klient - server s názvom AIRDANCE, a to od počiatočnej definície

požiadaviek aplikácie až po samotnú implementáciu a testovanie. Multiplatformovosť prináša

so sebou niekoľko problémov, ktoré sme museli počas práce efektívne vyriešiť. Nakoľko

aplikácia je aj interaktívna, presnejšie hra, optimalizácia je veľmi potrebná a taktiež zaručenie

rovnakej hernej skúsenosti pre všetky typy platforiem a zariadení. Jeden zo závažných

problémov je podpora viacero typov veľkostí obrazoviek, ktorý je však elegantne vyriešený.

Úspešne je zrealizovaný typ aplikácie klient – server, kde server vybavuje špecifické žiadosti

od klienta a je dlhodobo dostupný a obsluhuje viac klientov naraz. Klient aj server využívajú

na svoju realizáciu niekoľko knižníc, čo urýchľuje vývoj a predstavuje menšiu chybovosť ako

pri písaní vlastných knižníc.

18

8 Resumé

Project is focusing on definite solution for developing cross-platform software

application with name AIRDANCE, from the initial definition of application requirements to

implementation of them and final testing. Developing for several platforms at the same time

is not an easy task and brings a lot of problems with it. This work presents an elegant solution

to most of them. Because the application is also an interactive game, optimization for

different kinds of hardware is required and so is the need for the same game experience on

every platform and device. One of the more serious issues is the support for multiple screen

sizes. This one is solved by nice and scalable solution. Successfully a client – server type of

application is created, where server is responding to specific requests from clients. Server is

capable of long up-times and serving multiple clients at the same time. Both, client and the

server, are built on several open-source libraries, which speeds up the development process

and is less error-prone than writing custom libraries from scratch.

19

9 Zoznam použitej literatúry

Arlow, Jim a Neustadt, Ila. 2008. UML2 a unifikovaný proces vývoje aplikací.

Brno : Computer Press, a.s., 2008. ISBN 978-80-251-1503-9.

Gson. 2012. [Online] 2012. http://code.google.com/p/google-gson/.

Kanisová, Hana a Muller, Miroslav. 2007. UML zrozumitelne. Brno : Computer

Press, a.s., 2007. ISBN 80-251-1083-4.

KryoNet. 2012. [Online] 2012. http://code.google.com/p/kryonet/.

LibGDX. 2013. [Online] 2013. http://code.google.com/p/libgdx/.

Pančík, J. 2012. Meteorites - Android Apps on Google Play. Google Play . [Online]

2012. [Dátum: 01. 03 2013.] https://play.google.com/store/apps/details?

id=com.pancik.android.meteorites&hl=en.

Pour, Gála a Šedivá. 2009. Podniková informatika. Praha : GRADA Publishing,a.s.,

2009. ISBN 978-80-247-2615-1.

WIKI. 2013. Computing platform. [Online] 2013. [Dátum: 28. 2 2013.]

http://en.wikipedia.org/wiki/Computing_platform.

20

10 Zoznam príloh a obsah DVD-ROM/elektronickej prílohy

Obsah DVD-ROM/elektronickej prílohy

Táto práca obsahuje prílohu, fyzicky na priloženom DVD-ROM nosiči, elektronicky

v priloženom .ZIP súbore.

V prílohe sa nachádza spustiteľná verzia hry pre platformu PC, v súbore NAVOD.txt

je opísaný postup ako spustiť hru na operačných systémoch Windows, Linux a Mac. Taktiež

sa nachádza verzia pre Android zariadenia vo forme .apk súboru. Okrem toto sa tam

nachádza samotná práca a obrázky z prílohy.

Zoznam príloh

Obrázok 1 Architektúra klient - server........................................................................22

Obrázok 2 Zobrazenie obrazovky hry AIRDANCE....................................................22

Obrázok 3 UML diagram - Diagram tried klientského programu AIRDANCE..........23

Obrázok 4 UML diagram - Diagram aktivít klientského programu (LibGDX, 2013).24

21

Obrázok 1 Architektúra klient - server

(vlastné spracovanie)

Obrázok 2 Zobrazenie obrazovky hry AIRDANCE

(vlastné spracovanie)

22

Obrázok 3 UML diagram - Diagram tried klientského programu AIRDANCE

23

Obrázok 4 UML diagram - Diagram aktivít klientského programu (LibGDX, 2013)

24