Využití geolokačních dat v hrách pro přenosná PC a mobilní telefony

MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY

Využití geolokačních dat v hrách pro přenosná PC a mobilní telefony

BAKALÁŘSKÁ PRÁCE Jan Kučera

Brno, 2012

Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.

Poděkování Rád bych poděkoval Mgr. Lud’ku Bártkovi, Ph. D., vedoucímu mé bakalářské práce, především za podnětné návrhy a připomínky při tvorbě bakalářské práce a za ochotu poskytnout konzultace kdykoli byly potřeba. Děkuji svým přátelům za jejich názory na herní systém aplikace, za jejich podporu a trpělivost.

Shrnutí Práce se zabývá využitím geolokačních dat v hrách pro přenosná zařízení, popisuje některá stávající řešení a zahrnuje návrh a implementaci vlastní herní aplikace určené pro operační systém Android.

Klíčová slova Android, GPS, aplikace, RPG, mobilní přístroj, Internet, Google mapy, geolokace.

Obsah Úvod ...........................................................................................................1 1.

Stávající podobná řešení .............................................................3 1.1. Geocashing ...............................................................................3 1.2. Foursquere................................................................................4 1.3. Parallel Kingdom.....................................................................5

2.

Volba použitých prostředků ......................................................7 2.1. Eclipse, ADT a Android SDK ................................................8 2.2. PHP a MySQL databáze .........................................................8 2.3. Google mapy ............................................................................9

3.

Analýza a návrh aplikace .........................................................10 3.1. Specifikace požadavků .........................................................10 3.2. Analýza ...................................................................................11 3.3. Návrh ......................................................................................11 3.3.1. Model datové základny .................................................11 3.3.2. Model datových toků.....................................................13 3.3.3. Model tříd ........................................................................13

4.

Implementace .............................................................................14 4.1. Popis použitých algoritmů...................................................14 4.1.1. Přístup k datové základně ............................................14 4.1.2. Získávání dat o aktuální pozici ....................................15 4.1.3. Vykreslování do Google mapy .....................................16 4.1.4. Řešení soubojů ................................................................17 4.1.5. Seznamy ...........................................................................19 4.1.6. Práce s obrázky ...............................................................20 4.2. Analýza silných a slabých míst ...........................................21 4.3. Návrh možných vylepšení ...................................................22

Závěr .........................................................................................................23 Literatura ..................................................................................................24 Přílohy ......................................................................................................25

Úvod Postupem času jsme schopni získávat čím dál více informací, a to především díky rozvoji informačních technologií. Jednou z těchto technologií je Globální družicový polohový systém (GNSS, Global Navigation Satellite System), který umožňuje za pomoci elektronického přijímače získat informaci o aktuální poloze a přesném času na Zemi.[10] Tento systém byl zprvu určen pro armádní využití, ovšem dnes je dostupnost GPS (Global Positioning System – konkrétní aktuálně využívaný GNSS provozovaný Ministerstvem obrany USA) pro civilní uživatele samozřejmostí. GPS se zprvu využíval především v automobilových či turistických navigacích, avšak s příchodem přenosných počítačů a tzv. chytrých telefonů s GPS přijímačem se možnost využití značně rozšířila. Právě těmito novými možnosti se tato práce podrobněji zabývá. Cílem bakalářské práce je seznámit čtenáře s využitím informací o aktuální poloze v dostupných herních aplikacích pro přenosná zařízení. Především však navrhnout a vytvořit vlastní herní aplikaci pro uživatele chytrých telefonů, která bude využívat geolokačních dat. Byla zvolena herní aplikace pro operační systém Android patřící do skupiny RPG (Role-Playing Game), kde hráč zlepšuje svoji postavu sbíráním herních předmětů a souboji s protivníky. Hra je posazena do reálné mapy Země a pohyb postavy je shodný s pohybem uživatele zaznamenaným pomocí GPS či Internetových vysílačů. První kapitola se věnuje již rozšířeným aplikacím pro mobilní telefony využívající GPS jako je Foursqure[1] či Parallel Kingdom[2]. Popisuje jejich principy a vysvětluje rozdíly oproti aplikaci navržené v rámci této práce. Druhá

kapitola

se

zaměřuje

na

využité

prostředky

při

implementaci vlastní aplikace. Zdůvodňuje jejich výběr a osvětluje jejich způsob použití. Aplikace je navržena pro operační systém Android, je

1

tedy využito programovacího jazyka Java, ale také jazyka PHP a databáze MySQL. Třetí kapitolu tvoří formální návrh aplikace složený z Diagramu datových toků (DFD, Data Flow Diagram), Entitně-relačního modelu (ERD, Entity Relationship Diagram) a UML (Unified Modeling Language) diagramů. Seznamuje čtenáře se samotným principem aplikace a s možnostmi jejího využití. V poslední kapitole jsou přiblížena některá implementační řešení jako je přístup k databázi na serveru, vykreslování do Google mapy[3], zpracování geolokačních dat a jiné. Text práce se zde dále zabývá analýzou silných a slabých míst aplikace a návrhem možných vylepšení. Navržená aplikace je rozšiřitelná o další funkcionalitu, která zlepší hratelnost a zvýší zážitek ze hry. Jedná se například o zprovoznění výměnného obchodu, či možnosti komunikace. Také by bylo vhodné vytvořit zastřešující webové rozhraní s náhledem na vlastní herní postavu a s detailním administrátorským rozhranním. Tyto prvky ovšem nebyly zahrnuty do obsahu této bakalářské práce a budou předmětem dalšího vývoje.

2

1.

Stávající podobná řešení Aplikací pro mobilní telefony využívajících systému GPS je již

k dispozici velké množství. Jedná se zejména o poskytování různých druhů informací filtrovaných aktuální polohou uživatele jako je např. lokální předpověď počasí, odjezdy městské hromadné dopravy nebo seznam nejbližších restaurací či jiných užitečných míst. Pokud se ovšem zaměříme pouze na aplikace herní, již tak pestrou nabídku nenajdeme. I přesto se v tomto oboru vyskytují na trhu giganti, kteří svým herním systémem oslovili velké množství lidí po celém světě.

1.1.

Geocashing Geocashing[4] patří mezi nejstarší hry využívající systému GPS. Byl

založen v roce 2000 krátce poté, co Bill Clinton, tehdejší prezident USA, zrušil uměle vytvářenou nepřesnost systému GPS pro civilní využití. V té době se využívaly turistické GPS přijímače, mapové či nemapové, do kterých se vložily souřadnice cíle. Principem této hry je hledání předmětů schovaných ostatními hráči za pomoci informací o své poloze a o poloze hledaného předmětu. Ten může nabývat nejrůznějších forem. Základní podobu tvoří pevná schránka, ve které je kus papíru, na který se úspěšní hledači podepíší, a libovolný upomínkový předmět, který každý příchozí má možnost vyměnit za jiný. Geocashing se stal velkým hitem po celém světě. V dubnu 2012 uvádí autoři přes 5 milionů aktivních uživatelů a asi 1,7 milionů hledaných předmětů. Není tedy divu, že s příchodem moderních technologií v podobě chytrých telefonů byly v roce 2011 uveřejněny společností Groundspeak aplikace pro nejrozšířenější operační systémy (dále jen OS) pro mobilní telefony: Android, iOS a Windows Phone 7. Tyto oficiální aplikace jsou zpoplatněny (momentálně necelých 20 USD), což bylo jistě největší motivací k tvorbě neoficiálních neplacených aplikací. Na OS Android je to například aplikace c:geo, která mimo jiné umožňuje

3

prohlížení schovaných předmětů na mapě a režim navádění k vybranému z nich v podobě kompasu s informací o vzdálenosti. Nevýhodou této hry je, že ji není možné hrát ze své aktuální polohy. Hráč je nucen přesouvat se na určitá místa a to může být mnohdy zdlouhavé a v některých případech až nemožné. Tomuto problému se při návrhu aplikace vyhýbáme možností určitého dosahu do svého okolí. Postava je sice svázána s pozicí hráče na Zemi, může ovšem interagovat s objekty ve svém okolí až do určité vzdálenosti. Tyto objekty se navíc průběžně mění a tím je zajištěna dostatečná pestrost. Stejně jako v Geocashingu má hráč možnost v navrhované aplikaci hledat předměty. Jedná se ovšem o předměty virtuální, tedy viditelné pouze na mapě. Tyto předměty se však dají s výhodou v aplikaci využít k naučení se novému kouzlu či ke splnění zadaného úkolu. Hráč tedy není nucen k fyzickému pohybu, je do něj ovšem vřele motivován.

1.2.

Foursquere Foursquere[1] byl zprovozněn v roce 2009 a velmi rychle se stal

celosvětově populární. V lednu 2012 se může pyšnit více než 15 miliony uživateli. V České republice však dosud není příliš rozšířen. Podle měření Martina Hassmana[5] se v lednu 2011 jednalo pouze o necelé 4 tisíce uživatelů (odhadovaná nepřesnost je 10%), přesto je vidět rostoucí trend. Myšlenka je velice prostá: uživatel dojde na nějaké místo, např. restaurace, obchodu, divadla, ale třeba i do parku, a zde má možnost prostřednictvím speciální aplikace či webového rozhraní zaznamenat a uveřejnit dosažení dané pozice, tzv. „check-in“. Pokud pozice není dosud vytvořena, hráč ji může jednoduše na místě založit. Za „check-in“ obdrží uživatel herní body, za které lze získávat virtuální ocenění ve formě odznaků. V rámci zaznamenání dosažené pozice lze připojit komentář s hodnocením. Tyto komentáře pak mohou pomáhat dalším uživatelům uvažujícím o návštěvě daného místa. Důležitou funkcí je také možnost sledovat aktivity svých potvrzených přátel. Jednoduše lze poznat, které podniky vaši přátelé preferují a kdy v nich byli naposledy.

4

Samotná aplikace je relativně jednoduchá. Skládá se především z možnosti vyhledávání již založených míst v okolí, informací o aktivitě vaší i vašich přátel a samozřejmě možnosti „check-in“. Foursqure je tedy spíše sociální síť založená na geolokačních datech. Herní prvek je minimální, naopak je kladen důraz na hodnocení zajímavých míst a spolupráci s majiteli restaurací, kin či jiných podniků, mnoho z nich totiž za zaznamenané návštěvy nabízí různé zákaznické slevy. Námi navrhovanou aplikaci lze ve spolupráci s majiteli různých podniků využít podobným způsobem, přidává ovšem navíc zde relativně zanedbaný herní prvek.

1.3.

Parallel Kingdom Parallel Kingdom[2] je tzv. MMORPG (Massive-Multiplayer Online

Role-Playing Game), volně přeloženo jako hromadná online hra na hrdiny. Hra je zasazena do virtuálního světa korespondujícího se světem reálným, do kterého jsou přimodelovány virtuální budovy, nepřátelé a předměty. Je využíváno informací o aktuální poloze k umístění do virtuálního světa, lze se ovšem po mapě pohybovat i jinými způsoby než je fyzický pohyb, a to především prostřednictvím zabírání území či kupováním možnosti průchodu přes území cizí. Hra byla původně navržena společností PerBlue v roce 2008 pro OS Android a iOS. Od roku 2012 lze však hrát nově i prostřednictvím webového prohlížeče. Momentálně probíhá 4. věk, neboli 4. hraná verze, které se účastní přes 1 milion uživatelů z celého světa. Parallel Kingdom se naší navrhované aplikaci podobá nejvíce a to především herním stylem. Uživatel vystupuje prostřednictvím herní postavy, kterou průběžně vylepšuje, bojuje s nepřáteli a sbírá virtuální předměty. Parallel Kingdom je ovšem méně zaměřený na využívání geolokačních dat. I když děj probíhá na mapě Země, pohybovat se hráč může klikáním do okolí, nikoliv fyzickým přesunem. Aktuální poloha uživatele je využívána pouze pro možnost transportovat se na danou pozici.

5

Další odlišností je malý důraz na pestrost soubojů, který ze strany soupeře probíhá pouhou akcí „zaútočit“, po které následuje automatické ubývání života na obou stranách. V naší aplikaci se jedná o průběžnou volbu jednotlivých způsobů útoku, čímž je možné zvolit ideální strategii pro danou situaci a ovlivnit tak výsledek souboje.

6

2.

Volba použitých prostředků Vytvořená aplikace je určena pro operační systém Android verze

2.2 a vyšší. Android je momentálně nejrozšířenějším operačním systémem pro mobilní telefony, přitom u 93 % přístrojů se Android vyskytuje právě ve verzi 2.2 nebo vyšší. (Viz obrázek 2.1.) Android využívá virtuálního stroje Dalvik, který pracuje se speciálními soubory převedenými z klasického Java byte kódu kompatibilního s virtuálním strojem Java (JVM, Java Virtual Machine). Dalvik je oproti JVM přizpůsoben k práci s omezenými prostředky mobilních přístrojů jako je paměť a procesní výkon. Využijeme tedy programu Eclipse, který nám s pomocí vhodných doplňujících balíčků převod do potřebných souborů zajistí.

Obrázek 2.1: Rozložení verzí OS Android v zařízeních přistupujících do Google Play v období 19. 3. – 2. 4. 2012.[8]

V naší aplikaci potřebujeme hrací plán, shodný s reálním světem, k tomuto účelu nám dobře poslouží mapy od firmy Google. Jsou volně

7

k dispozici jako externí knihovna, která kromě samotného zobrazení umožňuje především vykreslovat do mapy vlastní objekty. Aby byl vytvořený virtuální svět jednotný, je třeba zajistit sdílení všech herních dat mezi jednotlivými uživateli. K tomuto nám poslouží centrální databáze MySQL umístěná na serveru. Pro přístup k této databázi využijeme jazyka PHP a databázových dotazů v jazyce SQL.

2.1. Eclipse, ADT a Android SDK K vývoji aplikací pro OS Android je doporučované vývojové prostředí Eclipse, které spolu s přídavnými moduly ADT (Android Development Tools) a Android SDK (Android Software Development Kit) umožňuje příjemnou tvorbu i testování. Modul ADT umožňuje snadné vytvoření nového Android projektu a export aplikace do souboru „.apk“ potřebného k její distribuci. Dále nabízí přehlednou správu zdrojových XML souborů, které např. definují uživatelské rozhraní nebo obsahují definice textových řetězců či Android Manifest, který obsahuje základní údaje o aplikaci a jejím nastavení. Modul Android SDK nabízí potřebné knihovny k vytvoření Android projektu a také emulátor pro testování vyvíjených aplikací. Pomocí SDK manažera lze stáhnout kteroukoliv dostupnou verzi OS Android a spustit ji na virtuálním stroji simulujícím rozhraní mobilního přístroje.

2.2.

PHP a MySQL databáze Asi nejběžnějším způsobem, jak z OS Android přistupovat ke

vzdálené databázi je přes PHP server. PHP skript přijme hodnoty odeslané HTTP protokolem a využije je při dotazu na databázový server. PHP je běžně používaný v kombinaci s databází MySQL, proto i my jsme neudělali výjimku. Odpověď databáze nám v některých případech pomáhá zpracovat již samotný jazyk PHP, ve většině případů však pouze odesíláme získané data zpět na mobilní zařízení ve formátu JSON (JavaScript Object Notation), který nám pomůžou zpracovat běžné Java třídy. 8

2.3.

Google mapy K využití map od společnosti Google v naší aplikaci potřebujeme

získat

licenční

klíč,

který

vložíme

jako

hodnotu

atributu

android:apiKey objektu MapView. Ten získáme registrací na webových stránkách společnosti Google[6], kde je třeba vložit šifrovaný otisk podpisu naší aplikace. Podpis aplikace slouží k určení autora aplikace a není k němu potřeba žádná certifikační autorita. Postup získání šifrovaného otisku je dobře popsán u již zmiňovaného registračního formuláře.

9

3.

Analýza a návrh aplikace Před samotnou implementací bylo potřeba se zamyslet nad tím, co

vše naše aplikace má umět a na jakou cílovou skupinu má být zaměřena. Vzhledem k tomu, že projekt neměl externího zadavatele, byly požadavky nastoleny na základě poznatků posbíraných při studiu podobných řešení a po výměně názorů s majiteli chytrých telefonů. Tyto požadavky byly analyzovány a vyjádřeny Diagramem případu užití. Následně již byl vytvořen samotný návrh aplikace složený z Diagramu tříd, Entitněrelačního diagramu a Diagramu datových cest.

3.1.

Specifikace požadavků I když se přenosná zařízení vyvíjejí opravdu rychle, jejich výkon se

se stolními počítači či jinými nepřenosnými herními zařízeními nemůže rovnat. Naše aplikace se tedy nesnaží s herní konkurencí bojovat pomocí grafických či zvukových efektů ani složitou výpočetní logikou. Zaměřili jsme se na přednosti mobilních zařízení a tou největší je právě přenositelnost. Díky přijímači GPS, který již většina moderních přenosných počítačů obsahuje, lze pohyb přístroje zaznamenávat a snadno ho s výhodou využít. Rozhodli jsme se tedy pro virtuální svět postavený nad světem reálným. Uživateli jsme přiřadili virtuální postavu, jejíž pohyb ovládá vlastním pohybem na Zemi, a svět doplnili virtuálními objekty. Nebyla by to herní aplikace bez možnosti interakce, proto je možné s virtuálními objekty různě manipulovat. Aby byla možnost interakce úplná, je zde možnost interagovat i s ostatními hráči ve hře. Potřebné administrativní rozhraní by mohlo být prostřednictvím mobilního

přístroje

nepohodlné.

Rozhodli

jsme

se

tedy

umístit

administraci na webový server pro možnost přístupu i z jiných zařízení. V samotné aplikaci má administrátor možnost pouze přerušit resp. obnovit chod hry uložením příslušného nastavení do databáze. Plná administrace tedy není součástí vyvíjené aplikace a kvůli její potřebné rozsáhlosti není ani součástí této bakalářské práce. 10

3.2.

Analýza Při analýze požadavků jsme vytvořili Diagram případu užití

(obr. 3.1). Diagram vyjadřuje využití aplikace jednotlivými druhy uživatelů. Přístup na čelní stranu aplikace je povolen každému. Ten, kdo se chce stát hráčem, je nucen se zaregistrovat. Registrace je nutná pro opětovné přihlášení, tedy jednoznačnou identifikaci vlastníka herní postavy. Uživatelem může být i administrátor. Ten ovšem pochopitelně nevzniká klasickou registrací. Účet administrátora je vytvářen přes administrativní rozhraní. Hlavním uživatelem aplikace je hráč. Ten má po přihlášení možnost prohlížet si virtuální objekty ve svém okolí a interagovat s nimi. Virtuální objekty se dělí na věci, příšery a postavy. Věci v okolí může hráč sebrat a následně se z nich naučit nové kouzlo. Proti příšerám může, stejně jako proti ostatním uživatelům, bojovat. Postavy nabízejí odměny za splnění různých úkolů. Tyto úkoly mají hráči možnost přijmout a následně buď vzdát, nebo splnit.

3.3.

Návrh Při návrhu aplikace jsme použili Diagram tříd, Entitně-relační

diagram a Diagram datových cest. Všechny tyto diagramy jsou díky své velikosti přiloženy jako příloha. V této podkapitole si v krátkosti tyto diagramy přiblížíme. 3.3.1. Model datové základny Model datové základny byl navržen formou Entitně-relačního diagramu. Znázorňuje rozložení dat uložených na serveru formou jednotlivých entit a vztahů mezi nimi. Sám diagram je vcelku názorný, vysvětlíme si tedy jen dosud nezmíněné objekty, které některé entity představují. Aby se jednotlivé virtuální objekty lišily, mohou mít odlišné vlastnosti či schopnosti. Vlastnosti mají v našem případě pouze příšery a hráči. Jedná se například o počet životů, maximální počet životů či rychlost samovolného uzdravování. Schopnosti mají naopak kouzla nebo 11

Obrázek 3.1: Diagram případu užití

12

posuny hráče na vyšší úroveň. Schopnost určuje změnu něčí vlastnosti. Pokud je kouzlo přátelské, např. kouzlo Uzdravení, mění se vlastnost hráči, který kouzlo vyvolal. Pokud kouzlo přátelské není, ovlivňuje vlastnosti soupeře. Kvůli automatické kontrole splnění úkolů je potřeba zadání úkolů omezit. Úkoly se tedy mohou skládat až ze tří možných částí: zabij příšery, posbírej věci a dostaň se na nějaké místo. Vše kromě věcí je započítáváno až od chvíle přijmutí úkolu, věci může hráč vlastnit již dříve. 3.3.2. Model datových toků DFD diagram společně s kontextovým diagramem znázorňují práci s aplikačními daty. Do tohoto diagramu je již začleněna plná administrace, aby byla vidět celková herní logika. Diagram mimo jiné přibližuje způsob, jakým jsou vedeny souboje, jak mezi dvěma hráči, tak mezi hráčem a příšerou. Je tvořen sekvencí jednotlivých útoků, vykouzlených kouzel, které mají určitou dobu přípravy. Po této době se projeví následky kouzla a útočník může začít s přípravou kouzla nového. Pokud je protivníkem hráč, je informován již o začátku přípravy kouzla, které je určeno proti němu, aby mohl útok co nejdříve opětovat. 3.3.3. Model tříd Model tříd se již blíží samotné implementaci. Jsou zde zobrazeny jednotlivé třídy výpočetní logiky programu a vztahy mezi nimi. Každá třída zde má uveden seznam atributů a seznam metod, které je třeba naimplementovat. V úvodu aplikace je vytvořena instance třídy Game, která zajišťuje registraci a přihlášení uživatele. Podle druhu uživatele se po přihlášení vytvoří instance třídy Admin, nebo Player, které jsou obě potomky třídy User. Ty se pak již za pomoci dalších tříd starají o veškerou aktivitu přihlášeného uživatele.

13

4.

Implementace Na začátku implementace je třeba vytvořit databázi, případně ji

naplnit testovacími daty. Databáze je vytvořena podle ERD diagramu na míru příslušné databázi, v našem případě databázi MySQL verze 5. Poté si již v Eclipse vytvoříme nový projekt a přeneseme základní kostru výpočetní logiky aplikace z Diagramu tříd. Je nutné se seznámit se základními rysy projektu pro OS Android. Základním faktem je, že Android pracuje s tzv. aktivitami, mezi kterými je možné se pohybovat a předávat si mezi nimi informace pouze v omezené míře. Pokud chceme, aby nějaká data byla dostupná z celé aplikace, tedy ze všech aktivit, je třeba vytvořit potomka třídy Application a uložit příslušná data jako její atributy. Takováto data pak budou přístupná po celou dobu běhu aplikace. Tohoto využíváme především u instance třídy Player, kterou je třeba aktualizovat z různých aktivit. Nebudeme se zde však zaobírat základy programování pro OS Android, k jejich seznámení nám pomůže především portál Android Developers[9] obsahující mimo jiné dokumentaci standardních tříd. Ukážeme si řešení některých klíčových částí programu, jako je např. přístup k serveru, získávání dat o aktuální poloze či využití Google map. Následně se zaměříme na silná a slabá místa této aplikace a uvedeme některé návrhy na možná vylepšení.

4.1.

Popis použitých algoritmů Veškerý zdrojový kód je přiložen jako příloha k této práci, bylo by

tedy bezpředmětné jej zde podrobně popisovat. Některé klíčové momenty implementace však i přesto za zmínku stojí. 4.1.1. Přístup k datové základně Podstatnou funkcí aplikace je komunikace se vzdáleným serverem. Jak již bylo zmíněno v podkapitole 2.2, komunikujeme s PHP serverem, který následně komunikuje s databází. Jedná se tedy o dvojstupňovou architekturu. Nejprve si pro každou akci, kterou v databázi chceme 14

provést, vytvoříme PHP soubor s příslušným SQL dotazem (popř. dotazy), který tiskne výsledek ve formátu JSON. K tomu nám poslouží PHP funkce print() a json_encode(). Druhým krokem je zavolat z aplikace požadavek na vytvořený PHP skript. Použijeme tedy funkce s balíčku org.apache.http, pomocí kterého navážeme spojení přes HTTP protokol. Dostaneme odpověď ve formátu JSON, který přeložíme pomocí balíku org.json. Komunikace probíhá prostřednictvím Internetu, nesmíme tedy zapomenout na příslušná oprávnění v Android Manifestu. Komunikace navíc může být zdlouhavá, zvláště pokud uživatel není v dosahu Wifi. Je tedy vhodné umístit ji do vedlejšího vlákna, aby nezatěžovala vlákno obstarávající uživatelské rozhraní. To by mohlo způsobovat špatnou plynulost aplikace. Při využití vedlejšího vlákna je nutné ošetřovat chyby, či jiné akce potřebující přístup k uživatelskému rozhraní, prostřednictvím zpráv zasílaných mezi vlákny. K tomu v Javě slouží třída Handler. V našem případě je největší zátěží pro systém nutná automatická aktualizace, která aktualizuje informace o okolních objektech, zjišťuje, jestli na uživatele nezačal někdo útočit a také zajišťuje automatickou regeneraci v případě zranění hráčovy postavy. Tato aktualizace pracuje ve speciálním vlákně a využívá opakovaně nastavovaný časovač, třídu CountDownTimer. Součástí pravidelných aktualizací je také pravidelné ukládání hráčovy polohy. Pravidelnost je vynucena, i když je poloha neměnná, jedná se totiž zároveň o informaci, že uživatel je online a je tedy možné na něj útočit. 4.1.2. Získávání dat o aktuální pozici Data o aktuální pozici přístroje lze získat v OS Android třemi způsoby. První a většinou nejméně přesná možnost je prostřednictvím Internetového připojení mobilního operátora. Druhou možností je prostřednictvím sítě Wifi, přičemž není nutné být k této síti skutečně připojen. Poslední možností je pomocí vestavěného GPS přijímače. Systém GPS dokáže být na volném prostranství přesný na jednotky metrů, v budovách však vykazuje relativně velkou nepřesnost, či dokonce

15

nemožnost lokalizace. Ideální je tedy zapojení získávání polohy jak pomocí Internetu, tak prostřednictvím GPS. Android však nedovoluje skrze aplikační kód zapnout přijímač Wifi ani GPS, a je tedy jen na uživateli, které funkce nám dá k dispozici. Jediné co můžeme udělat, je nabídnout uživateli otevřít nastavení, kde může přijímače sám zapnout a následně se do aplikace vrátit. Když se zaměříme na samotné získávání geolokačních dat, zjistíme, že využijeme balíku android.location. Vytvoříme si instanci třídy LocationListener, kde využijeme především funkce onChange, jejímž přepsáním předepíšeme činnost programu při získání nové polohy. Následně pomocí třídy LocationManager, jejíž instanci získáme ze systémových prostředků, se přihlásíme k odběru dat jak z Internetu, tak ze systému GPS. Každá z těchto variant vyžaduje vlastní oprávnění. V okamžiku, kdy již nepotřebujeme být informovaní o změně polohy, měli bychom se z odběru dat zase odhlásit, a to především z důvodu energetické zátěže. V našem případě chceme, aby hráč byl online, i když aplikace není na popředí, proto ukončujeme odběr dat až při ukončení aplikace. 4.1.3. Vykreslování do Google mapy Podmínky použití map od společnosti Google byly zmíněny již v podkapitole 2.3. Zde se zmíníme o možnostech, které tento externí balík nabízí a jak jsme jich v naší aplikaci využili. Hlavní třídou celého balíku je třída MapActivity, která je speciálním potomkem třídy Activity. Při inicializaci zobrazení je nutná přítomnost objektu MapView, do kterého je mapa automaticky načítána. Pomocí třídy MapController můžeme kontrolovat přiblížení, či zaměřit pohled na určité zeměpisné souřadnice, čehož využíváme při nastavení mapy na aktuální polohu uživatele. Důležitou funkcí Google mapy je možnost vykreslování vlastních objektů. To využijeme ke znázornění polohy uživatele a všech herních předmětů a postav v okolí vykreslením různobarevných koleček.

16

Pro přehlednost je také zobrazen poloprůhledný kruh se středem v pozici uživatele, který znázorňuje již zmíněné hráčovo okolí. (Viz obr. 4.1.) Pro možnost interakce s okolními objekty je po klepnutí na příslušné

kolečko

otevřena

vyskakovací

bublina

se

základními

informacemi a možnostmi. Mimo jiné je zde zobrazena adresa, na které se objekt nachází. Ta je získávána přes zeměpisné souřadnice pomocí třídy Geocoder. (Viz obr. 4.2.) Získání profilového obrázku je popsáno v kapitole 4.1.5.

4.1: Vykreslení okolí.

4.2: Zobrazení informační bubliny.

4.1.4. Řešení soubojů Nejdůležitějším herním prvkem naší aplikace je možnost soubojů jak s virtuálními protivníky, tak s reálnými protihráči. Samotný soubojový systém je popsán již v kapitole 3.3.2, zde si ukážeme jeho implementační řešení.

17

Pro souboj je určeno speciální zobrazení, kde jsou pohromadě základní informace o obou bojujících a o probíhajících útocích. Také je zde nabídka kouzel pro započetí nového útoku. (Viz obr. 4.3.) Tato nabídka je vytvořena pomocí horizontálního posuvného seznamu, který standardně není pro Android k dispozici, bylo tedy třeba využít volně dostupné třídy, jejímž autorem je Paul Soucy[7].

4.3: Souboj.

Po zvolení kouzla se začátek útoku uloží do databáze a nastaví se odpočítávání na hodnotu délky přípravy kouzla. V průběhu odpočítávání se upravuje ProgressBar zobrazující proces přípravy. Konec kouzla se vyhodnotí, pokud na konci příprav dosud není ani jeden ze soupeřů mrtvý. Následky jsou vyhodnoceny zvlášť v databázi pomocí PHP při pravidelné kontrole nových útoků a zvlášť v aplikaci po skončení odpočítávání příprav.

18

Pokud se jedná o souboj s virtuální příšerou, je v okamžiku prvního útoku uživatele odstartován sled automatických protiútoků, které se kromě automatického výběru použitého kouzla obstarávají shodným způsobem. V případě, že uživatel souboj opustí, příšera po dokončení probíhajícího kouzla přestane útočit. Pokud se při pravidelné kontrole zjistí, že na uživatele útočí někdo, s kým momentálně nebojuje, je na to uživatel upozorněn notifikací ve stavovém řádku a krátkou vibrací přístroje. V případě, že je s útočníkem již otevřeno zobrazení souboje, předá se informace o útoku aktivitě souboje, která spustí odpočet zbývajícího času přípravy kouzla. Vítězem souboje je pochopitelně ten, kdo soupeři sníží život na hodnotu nula. V takovém případě hráč získává určitý počet zkušeností a všechny věci poražené příšery a příšera již dále není zobrazována. Pokud byl soupeřem jiný hráč, získá vítěz pouze část věcí a poražený je uvržen do 5 minutové ochrany, během které na něj není možné útočit. Má tedy možnost se díky automatické regeneraci připravit na další střet. 4.1.5. Seznamy Jedním z důležitých prvků, kterých jsme v naší aplikaci využili, jsou seznamy zprostředkované třídou ListActivity. Jedná se o potomka třídy Actvivity, která v zobrazení vyžaduje objekt ListView. Protože chceme ke každému řádku zobrazit také ikonu, je třeba vytvořit si potomka třídy ArrayAdapter a obsloužit zobrazení přepsáním metody getView(…). Rozložení jednotlivých řádků nadefinujeme ve speciálním XML souboru, na který se v metodě odkážeme. Výhoda využití třídy ListView je mimo jiné také v rychlosti zobrazování, neboť se snaží recyklovat řádky, které momentálně nejsou viditelné. Seznamy jsme využili pro zobrazení věcí (viz obr. 4.4), naučených kouzel či výčtu úkolů. Sekce „Nastavení“ je také seznamem. Zde ovšem nebylo zapotřebí vytvářet vlastního potomka třídy ArrayList.

19

4.4: Seznam vlastněných věcí.

4.1.6. Práce s obrázky Abychom hráče upoutali alespoň náznaky grafického znázornění jednotlivých objektů, využijeme k tomuto účelu obrázky vztahující se k určité věci, úkolu, kouzlu či příšeře. Tyto obrázky jsou uloženy na centrálním serveru tak, aby se mohly v průběhu hry společně s novými objekty přidávat bez nutnosti aktualizace aplikace. Využijeme tedy třídu URL pro ustanovení spojení směřující k potřebnému obrázku a příchozí datový proud dekódujeme. Pokud obrázek není k dispozici, využije se obecná ikona příslušného druhu objektu z lokální paměti. Bylo by však přenosově náročné stahovat obrázky pomocí Internetu při každém zobrazení. Využijeme proto paměťovou kartu, pokud je v přístroji k dispozici, k uložení již stažených obrázků. Toho docílíme využitím standardních Java tříd pro práci se soubory.

20

Aby se hráči necítili ochuzeni, je pro ně připravena možnost nahrát vlastní profilový obrázek. Tomu jsou upraveny rozměry na požadované hodnoty a je odeslán protokolem HTTP metodou POST kódováním „multipart/form-data“ PHP skriptu na serveru, který příchozí data rozšifruje a obrázek uloží.

4.2.

Analýza silných a slabých míst Tak jako každá aplikace má i ta naše svá silná i slabá místa. Asi

nejsilnější stránkou naší aplikace je zřejmě její samotný návrh, který počítá s možnými nadstavbami a dalším vývojem. V samotné implementaci je to pak asi důraz, který byl kladen na ošetření chybových stavů, jako je náhlá absence Internetového připojení či problémy se získáním informace o poloze. Mezi slabé stránky patří určitě nutnost Internetového připojení a získávání geolokačních dat. Bez splnění těchto dvou požadavků se uživatel nemůže přihlásit, nebylo by totiž možné uživatele autentifikovat, respektive určit okolní objekty, s kterými má právo hráč manipulovat. Pokud ovšem dojde k výpadku Internetu po přihlášení, přejde hráč automaticky do režimu offline, kdy není viděn jinými hráči, sám ovšem také nemůže vykonávat žádnou aktivitu, pouze prohlížet lokální verzi vlastního profilu. To je výhodné především při krátkodobém výpadku spojení např. při přechodu z připojení mobilního operátora na Wifi či naopak. Pokud není po dobu 20 sekund k dispozici dostatečně přesná poloha, je hráč upozorněn dialogovým oknem a vyzván k trpělivosti či ke změně nastavení GPS přijímače. Akceptování výrazně nepřesné polohy by mohlo způsobit velké polohové skoky hráče, které by mohly být zneužitelné. Kvůli nutnosti pravidelné komunikace se serverem a stálého sledování informací o změně polohy je aplikace vcelku náročná na přenos dat a spotřebu energie, tomu se však implementačně nevyhneme.

21

4.3.

Návrh možných vylepšení Koncept hry umožňuje připojení široké škály nových funkcí. Velké

možnosti jsou v oblasti předmětů, kterých hra dosud příliš nevyužívá. Jedná se např. o směnný obchod, využití předmětů v boji nebo skládání předmětů do větších, užitečnějších celků. Volný prostor je však také v oblasti kouzel, kde lze vymýšlet kouzla, která se nemusí týkat samotného souboje, jako je např. krátkodobý teleport, možnost interakce se vzdálenějšími objekty, různé obranné štíty nebo pokus o kapsářství. Důležitou součástí vylepšení by měl být úvodní tutoriál, vytvoření profesionálního designu a možnosti komunikace mezi hráči.

22

Závěr Tato práce má za cíl seznámit čtenáře s rozšířenými herními aplikacemi pro přenosná zařízení, které využívají znalosti polohy, především ale popsat návrh a implementaci aplikace nové. Seznámili jsme se díky ní se způsobem návrhu her typu RPG a s některými pokročilejšími možnostmi, které OS Android programátorům nabízí. Ukázali jsme si práci s Internetem, GPS přijímačem, Google mapami a zjistili jsme jak přistupovat ke vzdálené databázi či jak stahovat obrázky ze serveru. Vytvořená aplikace byla umístěna do Google Play, oficiálního distribučního centra nejen pro aplikace určené pro OS Android, pod názvem Street Wizards. Pokračování na projektu bude ovlivněno ohlasy uživatelů.

23

Literatura [1] foursquare [online]. foursquare, 2009– [cit. 11. 04. 2012]. Dostupné na: < https://foursquare.com >. [2] Parallel Kingdom [online]. PerBlue, 2008– [cit. 11. 04. 2012]. Dostupné na: < http://www.parallelkingdom.com >. [3] Google maps [online]. Google Inc., 2005– [cit. 11. 04. 2012]. Dostupné na: < http://maps.google.cz >. [4] Geocashing [online]. Groundspeak, Inc, 2000– [cit. 11. 04. 2012]. Dostupné na: < http://www.geocaching.com >. [5] HASSMAN, Martin. Jak se daří Foursquare v ČR? Kolik tu má uživatelů? [online]. 2011– [cit. 11. 04. 2012]. Dostupné na: < http://hassmanm.posterous.com/jak-se-dari-foursquare-v-cr-kolik-tuma-uziva >. [6] Android Maps API Key Signup [online]. Google Inc., [cit. 11. 04. 2012]. Dostupné na: < http://code.google.com/intl/cs-CZ/android/add-ons/googleapis/maps-api-signup.html > [7] Soucy, Paul. HorizontalViewList [online]. 2011– [cit. 18. 04. 2012]. Dostupné na: < https://github.com/inazaruk/DevsmartLib-Android >. [8] Android Developers: Platform Versions [online]. Google Inc., [cit. 19. 04. 2012]. Dostupné na: < http://developer.android.com/resources/dashboard/platformversions.html >. [9] Android Developers [online]. Google Inc., [cit. 19. 04. 2012]. Dostupné na: < http://developer.android.com >. [10] RAPANT, P. [online]. Družicové polohové systémy. VŠB-TU Ostrava, 2002. 200 str. ISBN 80-248-0124-8. [cit. 23. 04. 2012]. Dostupné na: < http://gis.vsb.cz/dokumenty/dns-gps/at_download/file >.

24

Přílohy Veškeré

přílohy

byly

umístěny

do

informačního

Masarykovy univerzity.

Diagramy 

Entitně-relační diagram



Diagram datových toků



Diagram tříd

Zdrojové kódy 

PHP skripty



Eclipse projekt včetně dokumentace JavaDoc



Export databáze do SQL včetně testovacích dat

Aplikace 

Spustitelný soubor ve formátu “.apk”

25

systému