Masarykova univerzita Fakulta informatiky
Bakalářská práce
VÝVOJ HER PRO MOBILNÍ PLATFORMU ANDROID™
Ondřej Masopust 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. ............................................... Ondřej Masopust
Poděkování V první řadě bych rád poděkoval vedoucímu práce doc. PhDr. Josefu Prokešovi, Ph.D. za trpělivost a ochotu vést tuto práci. Dále nemohu opomenout své kamarády Jiřího Pohanku a Marcela Brože, kteří mě neustále motivovali k vyšším výkonům. Také chci poděkovat své rodině, která mě vytrvale podporuje po dobu mých studií. Děkuji!
ii
Shrnutí Má bakalářská práce popisuje vývoj her pro platformu Android od návrhu hry po její implementaci. Teoretická část se částečně zabývá systémem Android a obecnými informacemi o vývoji her. Práce je určená především pro začátečníky v programování, které varuje před častými chybami a nabízí ověřené postupy. Praktická část v podobě hry pak demonstruje využití popsané teorie v praxi.
Klíčová slova Vývoj her, Android, Google Play, OpenGL ES, trh s hrami, vzdušný hokej, Java, Eclipse
Vedoucí práce doc. PhDr. Josef Prokeš, Ph.D.
iii
Obsah Prohlášení ................................................................................................................. ii Poděkování ............................................................................................................... ii Shrnutí ...................................................................................................................... iii Klíčová slova ........................................................................................................... iii Vedoucí práce .......................................................................................................... iii Obsah .........................................................................................................................iv 1
Úvod .................................................................................................................... 1
2
Platforma Android ............................................................................................ 2 2.1
Krátká historie Androidu .......................................................................... 2
2.2
Fragmentace ................................................................................................ 3
2.3
Volba úrovně API ....................................................................................... 5
2.4
První kroky s Android SDK ...................................................................... 6
2.4.1 3
Vývoj her ............................................................................................................ 8 3.1
4
Instalace a nastavení vývojového prostředí .................................... 6
Typy her ....................................................................................................... 8
3.1.1
Casual hry............................................................................................. 8
3.1.2
Akční a arkádové hry ......................................................................... 8
3.1.3
Simulátory .......................................................................................... 10
3.1.4
Strategie .............................................................................................. 10
3.2
Trh s hrami pro mobilní systémy ........................................................... 10
3.3
Metody distribuce ..................................................................................... 12
3.4
Nároky na kód hry v jazyce Java............................................................ 13
Návrh vlastní hry ............................................................................................ 14 iv
4.1
Vzdušný hokej........................................................................................... 15
4.2
Herní mechaniky ...................................................................................... 16
4.3
Grafika ........................................................................................................ 17
4.3.1 4.4
Zvuk............................................................................................................ 18
4.5
Obrazovky a přechody ............................................................................ 18
4.6
Herní systémy ........................................................................................... 21
4.6.1
Unity3D............................................................................................... 21
4.6.2
AndEngine.......................................................................................... 22
4.6.3
Corona ................................................................................................. 23
4.7 5
6
Herní framework ...................................................................................... 23
Implementace hry ........................................................................................... 24 5.1
Herní framework ...................................................................................... 24
5.2
Hlavní smyčka .......................................................................................... 25
5.3
OpenGL ES ................................................................................................ 26
5.3.1
Inicializace OpenGL ES .................................................................... 26
5.3.2
Objekty v OpenGL ES ....................................................................... 27
5.4
Vytvoření textur ........................................................................................ 28
5.5
Herní objekty, detekce kolize a její reakce ............................................ 29
5.6
Hudba a zvuk ............................................................................................ 30
Závěr .................................................................................................................. 31 6.1
7
Vykreslení grafiky ............................................................................. 17
Možné rozšíření hry ................................................................................. 31
Citovaná literatura .......................................................................................... 32
v
1 Úvod Když v roce 2007 vydala firma Apple svůj první iPhone, chytré mobilní telefony se staly velmi oblíbeným produktem. To mělo za následek zaměření vývojářů na tvorbu mobilních aplikací, tzv. „apps“1. Spolu s představením dotykového displeje jako hlavního vstupního zařízení, byly mobilní aplikace jednou z nejzajímavějších novinek, které iPhone přinesl. Každý uživatel, který vlastnil iPhone, si tak mohl rozšířit svůj přístroj o novou funkcionalitu, a to jednoduše a rychle, pomocí služby AppStore. V roce 2008 vstoupila na trh firma Google se svým open-source operačním systémem Android, který ještě zvýšil zájem vývojářů. Díky otevřenosti této platformy může psát mobilní aplikace mnohem více programátorů, zvláště se pak systém uchytil u open-source komunity, kterou Apple odradil svými četnými omezeními a licenčními podmínkami (1). V současné době poptávka po mobilních aplikacích rychle roste, což činí jejich vývoj velmi zajímavým. Důkazem toho je i skutečnost, že denně je zaregistrováno přes 500,000 nových zařízení se systémem Android. Cílem této práce je poskytnout čtenáři základní vhled do současné situace na trhu
s
mobilními
aplikacemi
stejně
jako
popsat
hlavní
rysy
nejrozšířenějších mobilních operačních systémů. Druhá část práce se zaměřuje na popis návrhu a vývoje jednoduché hry na platformu Android ve vývojovém prostředí Eclipse IDE.
app (z anglického application) - software, který se dá stáhnout a nainstalovat do mobilního telefonu 1
1
2 Platforma Android 2.1
Krátká historie Androidu
První zmínka o Androidu je z roku 2005, kdy Google koupil malý start-up2 pojmenovaný Android, Inc. Tři roky poté, v roce 2008, byla vydána první verze nového operačního systému běžícího na procesorech ARM3, čímž Google vstoupil na trh s mobilními telefony. Protože je Android open-source, výrobci mobilních telefonů nemusejí platit za licenci pro jeho použití. To se pozitivně odráží v ceně telefonů a díky tomu není Android výsadou pouze drahých přístrojů, ale může být použit i v low-end4 zařízeních. Získává tak větší počet uživatelů, než konkurenční systémy, které jsou uzavřené. Důležitým momentem pro úspěch Androidu bylo založení Open Handset Alliance (OHA) v roce 2007. Tuto skupinu vytvořili přední výrobci hardwaru týkajícího se mobilních telefonů, jako jsou HTC, Motorola, NVIDIA, Qualcomm. Cílem tohoto sdružení bylo vyvinout otevřené standardy pro mobilní zařízení. Přestože jádro systému spravuje a vyvíjí Google, všichni členové OHA se na vývoji nějakým způsobem podílejí nebo podíleli. Systém Android je založen na Linuxovém jádře verze 2.6 a je volně dostupný ke komerčnímu i nekomerčnímu využití. Někteří členové OHA si pro své vlastní zařízení vyvinuli upravenou verzi systému s různými nadstavbami a upraveným uživatelským prostředím. Jako příklad je možné uvést prostředí HTC Sence od firmy HTC, MOTOBLUR od firmy Motorola nebo TouchWiz+ od korejské firmy Samsung.
2
Start-up – nový podnikatelský záměr s ambiciózním plánem
3
ARM – Advanced Reduced-instruction-set-computer Machine
4
Low-end zařízení – zařízení v nízké cenové kategorii
2
Od představení první verze v roce 2008 do doby psaní této práce5, vydal Google devět zásadních updatů, všechny pojmenované podle dezertů6. Každá verze přinesla novou funkcionalitu, která je nějakým způsobem důležitá pro vývoj her. Ve verzi 1.5 byla představena podpora pro vkládání nativních knihoven7. Do této verze bylo možné používat k vývoji pouze jazyk Java. Nativní kód přináší nejvíce užitku v případech, kdy je potřeba velká výkonnost. Verze 1.6 (Donut) představila podporu displejů s různým rozlišením a velikostí. (2) Od verze 2.0 (Éclair) umí Android pracovat s multi-touch8 obrazovkou, verze 2.2 (Froyo) přidala podporu just-in-time9 (JIT) kompilace, což zrychlilo spouštění Java aplikací dvakrát až pětkrát. Verze 2.3 (Gingerbread) přinesla nový výkonnější Garbage-collector10. Ve verzi 3.0. (Honeycomb) byla hlavní novinkou podpora pro tablety, dále se systém dočkal vylepšeného multitaskingu a hardwarové akcelerace animací. V současné nejnovější verzi 4.0 (Ice Crem Sandwich) bylo radikálně změněno uživatelské prostředí. Google také představil nové webové stránky http://developer.android.com/design, které radí vývojářům, jak si poradit s designem aplikací, aby dodržovali Androidí look and feel11.
2.2
Fragmentace
Velká flexibilita Androidu přináší i svoje nevýhody. Výrobci vytvářející vlastní nadstavby uživatelského rozhraní se přizpůsobují novým verzím
5
Rok 2012
6
Cupcake (dortík), Icecream Sandwich (zmrzlinový sendvič), apod.
7
Knihovny NDK – Native Developement Kit
Multi-touch display – obrazovka, která dokáže snímat více než jeden dotek v jednom okamžiku 8
9
Just-in-time kompilace – také dynamický překlad, metoda urychlení kompilace
10
Garbage-collector – nástroj pro automatické uvolňování paměti
11
termín z grafického designu – obecný vzhled a reakce systému
3
systému
pomalu,
což
pro
koncové
uživatele
znamená,
že
jsou
tzv. „zaseknutí“ na staré verzi Androidu a nemohou využívat nejnovější funkce. Tento jev se nazývá fragmentace a pro vývojáře z něj plyne nutnost opatření, které zaručí bezproblémový běh aplikace na všech verzích Androidu. Zatímco aplikace cílené na staré verze systému poběží na nových většinou bez problémů, opačně to neplatí, někdy je tedy potřeba psát oddělený kód pro různé verze. Při vývoji her fragmentaci pocítíme v omezené míře, protože není potřeba využívat příliš mnoho Android APIs12. Naopak se setkáme s hardwarovou fragmentací, která je problémem i na jiných platformách, jako třeba iOS. Na trhu je více než 681,900 (3) zařízení od různých výrobců a každé zařízení má odlišné parametry, jako je velikost, rozlišení a hustota pixelů displeje, výkon procesoru, velikost paměti RAM. Musíme tedy počítat s menším výpočetním výkonem starších zařízení. V tomto ohledu se při vývoji hry můžeme vydat dvěma směry, buď napíšeme oddělený kód, který bude výpočetně méně náročný (např. bude využívat textury s menším rozlišením), nebo málo výkonná zařízení nebudeme podporovat.
Graf 1: různá rozlišení displeje na dostupných zařízeních
12
Application programming interface
4
2.3
Volba úrovně API
Důležitým rozhodnutím před návrhem aplikace je výběr cílové verze systému Android, pro kterou je aplikace vyvíjena. Pokud je zvolena verze příliš nová, vývojář přichází o potenciální zákazníky, kteří výsledný produkt mohou použít. Google v tomto ohledu vychází vývojářům vstříc a pravidelně zveřejňuje zastoupení jednotlivých verzí systémů, které přistupují na službu Google Play (viz Graf 2). Na základě těchto dat se vývojář může snadněji rozhodnout, které verze jsou pro něj lukrativní podporovat. Výsledné rozhodnutí je pak otázkou kompromisu. Já jsem jako cílovou verzi zvolil 2.2 (více než 90% zařízení).
Graf 2: Verze Androidu přistupující do služby Google Play k 1. 5. 2012
5
2.4
První kroky s Android SDK13
Před samotným vývojem je potřeba nainstalovat a nastavit vývojové prostředí. V této kapitole si ukážeme jak na to. 2.4.1
Instalace a nastavení vývojového prostředí
Android SDK je velmi flexibilní nástroj, který je schopný se integrovat do podporovaných vývojových prostředí. Lze s ním pracovat i přes příkazový řádek, já jsem zvolil pohodlnější způsob, tedy použít IDE14. Googlem doporučené IDE je vývojové prostředí Eclipse, které je dostupné pro operační systémy Windows, Mac OS X a Linux v 32 i 64bitových verzích. Eclipse
IDE
je
open-source
vývojové
prostředí
určené
především
pro programování v jazyce Java. Po případném doinstalování zásuvných modulů zvládá i jiné jazyky jako C/C++, Python nebo PHP, já ovšem tyto jazyky nepotřeboval. Kromě Eclipse IDE je potřeba nainstalovat ještě tento software:
Java Developement Kit (JDK)
Android Software Developement Kit (Android SDK)
The Android Developement Tools (ADT) plug-in pro Eclipse IDE
Java Developement Kit lze stáhnout ze serveru http://www.oracle.com a to pro téměř všechny operační systémy. JDK je soubor základních nástrojů, potřebný pro vývoj aplikací v Javě. Android SDK lze stáhnout z portálu http://developer.android.com/. Obsahuje potřebné knihovny pro vývoj, ladící nástroje, emulátor zařízení se systémem Android, dokumentaci, ukázky kódu a základní návody.
13
Android Software developement kit
14
Integrated developement environment
6
Obrázek 1: Emulátor zařízení se systémem Android
ADT zásuvný modul získáme pomocí nabídky Help > Install New Software v Eclipse IDE. Zvolíme adresu repositáře se zásuvným modulem (https://dlssl.google.com/android/eclipse/) a modul nainstalujeme. Po úspěšném dokončení se v Eclipse IDE vytvoří nová perspektiva DDMS15, která slouží k spouštění a ladění aplikací, optimalizaci výkonu a simulování běžných aktivit telefonu, jako je příchozí hovor, vypnutí při slabé baterii, nebo úprava dat z čidel (gyroskop, GPS).
15
Dalvik Debug Monitor Server
7
3 Vývoj her 3.1
Typy her
Hry lze třídit podle mnoha kritérií, která zahrnují například tématiku (do jakého prostředí je hra zasazena), způsob vedení kamery (nejčastěji pohled z první či ze třetí osoby), apod., nicméně nejběžnějším kritériem klasifikace je nepochybně žánr, který hry dělí na základě rozdílných způsobu interakce s hráčem. 3.1.1 Casual hry Pravděpodobně největším segmentem her na Google Play jsou tzv. Casual hry. Jsou to hry pro hráče nenáročné, cílené především na zákazníky, kteří nemají velké zkušenosti s hraním her. Každá hra by měla trvat nejdéle několik minut, návykovost hry ale dokáže hráče zaměstnat i na hodiny. Casual hry bývají označovány jako opak hardcore her16. Herní mechaniky můžou být od jednoduchého puzzle přes jednotlačítkové plošinové hry až k absurdním titulům, jako házení zmuchlaného papíru do vzdáleného koše. Možnosti jsou nekonečné, právě díky nejasné definici tohoto žánru. 3.1.2 Akční a arkádové hry Akční a arkádové hry mají největší potenciál plně využít možnosti platformy Android a hardwaru přístroje. Tyto hry jsou často plné nejrůznějších 3D a částicových efektů. Tento žánr lze rozdělit do těchto kategorií:
3D akční hry o Střílečky z vlastního pohledu o Střílečky z pohledu třetí osoby
16
Hardcore hra – velmi těžká hra určená pro zkušené hráče
8
Plošinové hry
Logické
Závodní
Jedna z důležitých plošinových her je Replica Island (Obrázek 2), vydaná v březnu roku 2010. Autorem této hry je Chris Pruett, přední vývojář Googlu. Jeho cílem bylo ukázat, že lze na Android vytvářet hry v Javě, bez použití nativního kódu. Vývoj této hry trval tři měsíce a byl zakončen přednáškou na Google I/O, kde autor radil potenciálním vývojářům, čeho se mají vyvarovat.
Obrázek 2: plošinová hra Replica Island
Cílem hry je pomocí malého robota získat záhadný artefakt. Herní mechaniky se podobají starým plošinovým hrám na 16bitovém SNES17. Ve výchozím nastavení se robot ovládá pomocí akcelerometru a dvou tlačítek, jedno pro zapnutí trysek, druhé pro útok na nepřátele ze vzduchu. Hra je open-source, je tedy možné se inspirovat jejím kódem.
SNES – Super Nintendo Entertainment Systém, herní konzole vyvinutá firmou Nintendo v roce 1990 17
9
3.1.3 Simulátory Hry založené na přesné simulaci různých (fyzikálních, společenských, ekonomických, aj.) aspektů skutečného světa. Zpravidla jsou uživateli zpřístupněny rozsáhlé možnosti nastavení jednotlivých stránek simulované skutečnosti, což umožňuje přizpůsobit věrnost hry na požadovanou úroveň (čím věrnější skutečnému světu, tím složitější a náročnější hra je). Existuje velké množství různých druhů simulátorů, avšak mezi nejrozšířenější lze zařadit především simulátory řízení (závody aut), letecké simulátory či simulátory společenského života. 3.1.4 Strategie Strategické hry kladou důraz na schopnost uvažovat a plánovat za cílem dosažení vítězství. Vyžadují, aby hráči podnikli sérii kroků proti jednomu či více oponentům, na základě které získají na protivníky převahu. K vítězství zpravidla vede schopnost jednoho z hráčů lépe plánovat a promýšlet strategii dalšího postupu, přičemž element náhody hraje méně významnou roli. Nejběžněji jsou strategické hry děleny podle dynamiky střídání se hráčů v hraní, a to na tzv. real-time strategie, ve kterých všichni účastníci hrají zároveň, a turn-based18 strategie, ve kterých se hráči v pevném pořadí střídají. Dalším možným rozdělením je podle toho, zdali je hra více zaměřena na strategickou, nebo taktickou stránku.
3.2
Trh s hrami pro mobilní systémy
Trh s hrami pro mobilní systémy je velmi dynamický. Lze sice nalézt „tvrdá data“ popisující vývoj rozložení sil v předchozích letech, avšak aktuální situaci je možno bez spekulací odvozovat pouze nepřímo, a to na základě očividných trendů.
18
Hra je členěna na kola – hráč není časově omezený při rozmýšlení dalšího tahu
10
Prvním z nich je neustálý růst poptávky po aplikacích pro mobilní platformy, který je logickým vyústěním masového rozšiřování chytrých telefonů s dotykovým displejem z důvodu jejich vzrůstající cenové dostupnosti. To znamená, že trh s aplikacemi je velmi perspektivní a pro vývojáře zajímavý. Tím pádem, kromě jiného, důsledkem zvyšující se konkurence, se kvalita aplikací zvyšuje též. Dalším trendem, který zároveň souvisí i se zmiňovanou vzrůstající konkurencí na straně nabídky, je zvyšující se podíl her (a aplikací obecně) využívajících tzv. freemium19 business modelu, tedy neplacených aplikací generujících zisk na základě reklamy či in-game20 nákupech. Co se mobilních platforem týče, hlavními hráči na trhu jsou iOS a Android. V současné době sice stále existuje více aplikací na iOS, nicméně množství aplikací na Android přibývá výrazně rychlejším tempem. Toto je způsobeno rozdílem v požadavcích na developery, zatímco vývoj pro iOS vyžaduje zakoupení licence (99USD/rok, nutnost každoročního obnovování) a projetí schvalovacím procesem, na Android lze po registraci a jednorázovém zakoupení licence (25USD) již volně vyvíjet. Navíc již v současné době je počet nezpoplatněných aplikací na Android vyšší než na iOS.
Freemium bussines model – produkt je v základní verzi zdarma, zpoplatněny jsou pokročilé funkce 19
20
In-game nákup – nákup přímo ve hře
11
3.3
Metody distribuce
Hotovou hru máme možnost distribuovat následujícími způsoby:
Google Play
Krabicový systém
Google Play je internetová služba, která především slouží pro snadnou distribuci aplikací na platformu Android. Vývojářům umožňuje po registraci a zaplacení jednorázového poplatku své aplikace nahrát a spravovat. Ostatní uživatelé tyto aplikace mohou komentovat, hodnotit a samozřejmě stahovat na svá mobilní zařízení. Vývojářské rozhraní též umožňuje vývojářům po nahrání aplikace sledovat některé relevantní informace.
Celkové hodnocení nahrané hry a počet hodnotitelů
Komentáře od ostatních uživatelů
Kolikrát byla aplikace doposud nainstalována
Počet aktivních instalací
Chybová hlášení
Tímto způsobem se k vývojářům dostává jak cenná zpětná vazba a zajímavé statistické informace, tak informace o případných nedostatcích jejich aplikací. Druhý způsob distribuce, tedy krabicový, nám zdaleka nenabízí takovéto výhody, naopak je nákladnější, protože musíme nakoupit obaly a média, na kterých
bude
hra
přenesena.
Zároveň
musíme
uzavřít
smlouvu
s distributorem, který si naúčtuje větší provize než Google Play.
12
3.4
Nároky na kód hry v jazyce Java
Pro bezproblémový běh hry je potřeba dodržovat určitá pravidla. Virtuální stroj (tzv. Dalvik VM), ve kterém běží všechny aplikace v systému Android napsané v Javě, je náchylný na některé konstrukce. Největším nepřítelem herního vývojáře je garbage-collector (GC). Jakmile se GC spustí, hra „zamrzne“ v některých případech i na 200ms. Takové prodlevy si uživatel všimne a rozhodně nebude rád. Jediným způsobem, jak zamezit, aby GC vykonávalo svou práci je nevytvářet zbytečné objekty, obzvláště v hlavní smyčce (4). Objekty se ovšem vytvářejí i v momentech, kdy to méně zkušený programátor nečeká. Měli bychom se proto vyvarovat následujících konstrukcí v hlavní smyčce:
Iterátory – iterátory vytvářejí vnitřní objekty při každé iteraci, neměli bychom vůbec používat třídy implementující rozhraní Set a Map
Spojování řetězců operátorem „+“ – namísto toho použijeme třídu StringBuffer
Volání metod je výpočetně drahé – v určitých případech je lepší přistupovat k atributům přímo, namísto volání getterů a setterů. (Přímý přístup je 3-7 krát rychlejší, než přístup přes metodu)
Co bychom naopak používat měli, jsou:
Primitivní typy
Statické objekty – statické objekty bývají znakem špatného návrhu, přesto při vývoji her jsou užitečné a vhodnější, než pomocné objekty. Vytvářejí se totiž při startu aplikace, tedy jejich načtení nikdy neproběhne v hlavní smyčce.
13
4 Návrh vlastní hry Protože jsem s vývojem her neměl téměř žádné praktické zkušenosti, rozhodl jsem se zvolit jednodušší žánr a hru zpracovat kvalitně. Velkým obloukem jsem se chtěl vyhnout hrám, které obsahují rozsáhlý příběh a pokročilé grafické efekty. Můj cíl bylo vytvořit 2D hru, ve které bude nutné zabývat se především
fyzikou.
Jako
nevhodnější
žánr
jsem
zvolil
simulaci,
konkrétně simulátor vzdušného hokeje (5). Před začátkem implementace je třeba si hru patřičně navrhnout. Často se stává, že motivovaný vývojář začne po prvotním nápadu vytvořit hru ihned programovat. V takových případech je celkem velká pravděpodobnost, že jeho projekt skončí dříve, než se dopracuje k nějakým výsledkům. Tímto způsobem je možné vytvořit prototyp hry a ověřit si, zda dané herní mechaniky fungují, nikdy by ovšem tento kód neměl sloužit pro další vývoj. Prototyp by měl být zahozen a hra nejdříve řádně navržena. V mém případě jsem si návrh rozdělil na následující body:
Hlavní herní mechaniky
Hrubé skeče grafického stylu
Skeče všech obrazovek hry, diagram přechodů mezi obrazovkami spolu s podmínkami přechodů (např. kdy se hra ukončí)
Jako součást návrhu jsem zařadil i výběr jména pro hru. Mé požadavky byly, aby název nebyl příliš dlouhý a bylo z něj na první pohled zřejmé, o čem hra je. Na základě hokejové tématiky jsem zvolil název Hockey Mania.
14
4.1
Vzdušný hokej
Vzdušný hokej je hra pro dva hráče, kteří se snaží pomocí kulaté pálky
(Obrázek 3) dostat puk do soupeřovy branky. Obrázek 3: hrací pálka (angl. mallet)
Pro hru je potřeba stůl, který je specifický tím, že z hladké hrací plochy je skrz malé dírky pod tlakem vyháněn vzduch, který nadnáší puk a částečně i pálky obou hráčů. Puk se tak nedotýká hrací plochy, tedy na něj kromě odporu vzduchu nepůsobí tření. Na okrajích stolu jsou několik centimetrů vysoké mantinely, od kterých se puk odráží zpět na hrací plochu. Stůl je v polovině rozdělen čárou na dvě části, každá příslušící jednomu z hráčů. Základní pravidla vzdušného hokeje (6) jsou: 1. První hráč, který dosáhne sedmi bodů, vyhrává. 2. Jakmile se puk ocitne v hráčově bráně, soupeř získává jeden bod. 3. Hráči si po každé dokončené hře (sedm bodů) střídají strany. 4. Hráč, kterému byl vstřelen gól, rozehrává. 5. Dokud nebyl vstřelen gól, hráč se nesmí puku dotknout žádnou částí těla. 6. Hráč smí používat pouze jednu pálku. 7. Hráč smí použít pálku pouze na jeho polovině stolu. 8. Pokud se puk dotýká středové dělicí čáry, oba hráči mají dovoleno hrát.
15
4.2
Herní mechaniky
Při návrhu herních mechanik musíme vzít v potaz dostupné funkce zařízení. Protože jsem jako cílový systém vybral Android ve verzi 2.2 (viz. sekce 2.3), mohu využít podporovaný multi-touch displej. Oba hráči budou své pálky ovládat pomocí prstu. Abych zamezil přesunu pálky na soupeřovu polovinu, podél dělicí čáry displej na dotek nereaguje. Tím se zároveň vyvarujeme nechtěnému pohnutí soupeřovy pálky. Dalším prvkem hry je puk. Na začátku hry bude umístěn vprostřed herního pole. Jeden z hráčů puk pomocí pálky odrazí na soupeřovu polovinu, čímž hra začne. Hráči mohou využívat mantinelů a pokoušet se puk pomocí odražení umístit do brány. Odrážení puku od pálek a mantinelů bude co nejvěrněji napodobovat reálné fyzikální zákony. Při styku puku s bránou se hra zastaví a hráči budou informováni o vstřeleném gólu. Poté se spustí nové kolo, s tím rozdílem, že puk bude posunut na polovinu hráče, který dostal gól, aby se dodrželo pravidlo 4 ze sekce 4.1. V okamžiku, kdy jeden z hráčů nashromáždí sedm bodů, se místo spuštění nového kola hráčům oznámí vítěz a hra se přesune do hlavního menu. Po celou dobu hry bude na obrazovce zobrazeno aktuální skóre. Herní mechaniky jsem si shrnul do následujících bodů:
Hráči budou své pálky ovládat pomocí dotykového displeje.
Puk se bude odrážet od pálek a mantinelů
Pokud se puk dotkne brány, hráči, který gól vstřelil, se přičte jeden bod.
Pokud hráč získá sedm bodů, hra oznámí vítěze a skončí – přesune se zpět do hlavní nabídky.
16
4.3
Grafika
Nyní, když máme definované herní mechaniky, se můžeme pustit do návrhu grafického stylu. V této fázi je dle herních vývojářů nejlepší vzít si papír, tužku a nejdříve si načrtnout hrubý grafický návrh (7). Vzal jsem tedy v potaz vše, co jsem navrhl, a vytvořil si skeč herní obrazovky (Obrázek 4).
Obrázek 4: Návrh grafického prostředí herní obrazovky
Všechny nabídky ve hře budou řešeny podobným stylem, aby byla zachována konzistence aplikace. 4.3.1 Vykreslení grafiky Systém Android umí vykreslit grafiku dvěma odlišnými způsoby. Jedním z nich je použití tzv. Canvasu, procesorem řízené vykreslování bitmap a grafických primitiv. Druhý způsob je pomocí grafické knihovny OpenGL ES. Vykreslování pomocí OpenGL ES má na starost grafický čip (GPU), je tedy hardwarově akcelerované. V Hockey Manii jsem použil druhou metodu a to ze vzdělávacích důvodů, hra by pravděpodobně běžela plynule i při použití Canvasu.
17
4.4
Zvuk
Součástí každé dobré hry je i hudba a zvukové efekty. Jako hudba se označuje déle hrající zvuková stopa, která může být ve smyčce. Ta bývá spuštěna po zapnutí hry a její přehrávání není závislé na ději ve hře. To samozřejmě neplatí pro složité hry, ve kterých se často mění atmosféra prostředí, které je hudba nedílnou součástí. V naší jednoduché hře ovšem atmosféru neměníme, a proto budeme hudbu používat pouze jako podbarvení. Zvukové efekty jsou krátké stopy (často dlouhé pouze jednu až pár sekund) spouštěné jako reakce na určité podněty. Konkrétně v Hockey Manii je vhodné přehrát zvuk při odrazu puku od pálky nebo mantinelu a při vstřelení gólu. Také reakce uživatelského prostředí na stisknutí tlačítka je doprovázena zvukem.
4.5
Obrazovky a přechody
Prvně je důležité si ujasnit, co vlastně taková obrazovka představuje.
Obrazovka je atomická jednotka, která vyplňuje celý displej a je zodpovědná za právě jednu část hry. (Např. hlavní menu, menu s nastavením, nebo herní obrazovka, ve které bude probíhat samotná hra)
Obrazovka může obsahovat další podřízené prvky jako tlačítka, ovládací prvky, počítadlo skóre.
Obrazovka dovoluje uživateli interakci s jejími prvky. Ty mohou spustit přechod mezi obrazovkami, nebo provádět jiné akce uživatelského prostředí (např. vypnout přehrávání hudby)
18
Obrazovky jsem si nejdříve načrtl na papír a navrhl přechody mezi nimi, jak je vidět na obrázku 5.
Obrázek 5: Náčrtek všech obrazovek i s jejich přechody.
První obrazovka po spuštění hry, která se ukáže uživateli, je hlavní nabídka. Ta by měla obsahovat následující prvky:
Zobrazení jména hry – dobrý způsob jak uživateli pomoci, aby si hru lépe zapamatoval.
Aby hlavní nabídka vypadala více konzistentní se zbytkem hry, rozhodl jsem se použít pozadí herního stolu. To jsem ve středu překryl tmavým obdélníkem s funkčními tlačítky.
Tlačítko Play, které spustí hru.
Tlačítko Credits, které zobrazí obrazovku se jménem autora hry a hudby.
Tlačítko Quit pro vypnutí hry.
19
Tlačítko Music, pomocí kterého bude možno vypnout hudbu. Vypnut zvuk může uživatel i hardwarovými klávesami pro ovládání hlasitosti, bývá ovšem běžné uživatelům ve hrách takové tlačítko poskytnout. Uživatel pak má možnost ztlumit pouze hru, zatímco na pozadí může hrát přehrávač hudby.
Po stisknutí tlačítka Play se uživatel přesune na herní obrazovku. Aby hra nezačala hned a uživatel měl čas se připravit, je před startem hry požadováno kliknutí na obrazovku. Tato funkce nemění obrazovky, počáteční pauzu jsem v rámci herní obrazovky implementoval jako stav hry. Dále je potřeba, aby měli uživatelé možnost hru přerušit v průběhu. Tato funkce je nabídnuta ve formě tlačítka Pause na herním poli. Aby nedocházelo k neúmyslným stiskům při pohybu s herní pálkou, tlačítko reaguje, pokud z něj je prst zvednut, nikoli pokud se přes tlačítko prstem pouze přejede. Toto se dá na Androidu implementovat jednoduše, systém totiž rozlišuje tyto dotykové události:
MotionEvent.ACTION_UP
MotionEvent.ACTION_DOWN
MotionEvent.ACTION_MOVE
Dotykové události pak lze jednoduše filtrovat podle typu. Po stisknutí se změní stav hry a ve středu obrazovky se objeví nabídka s možností pokračovat ve hře (Resume) a návratu do hlavní nabídky (Quit). Pokud je vstřelen gól, informuji uživatele a po doteku obrazovky hra pokračuje. Po sedmi vstřelených gólech oznámím uživatelům výsledek hry, po následném doteku obrazovky ukončím herní obrazovku a zobrazím hlavní nabídku. V herní obrazovce tedy máme 5 stavů. Ty si můžeme představit jako podobrazovky. Stavy jsou:
Ready – počáteční čekání před začátkem hry
Running – hra probíhá 20
Paused – hra je pozastavena s možností opětovného spuštění, nebo vypnutí
AfterGoal – podobrazovka s informací o gólu čeká na stisk obrazovky
GameOver – zobrazení konečného skóre; po stisku přesun do hlavní nabídky
4.6
Herní systémy
Herní systém (engine) je systém určený pro vývoj her. Herní engine obvykle zajišťuje vykreslování scén (renderování) pro 2D nebo 3D grafiku, výpočet fyziky, detekce kolizí (a jejich reakce), zvuk, skriptování, animace, umělou inteligenci, vytváření sítí, správu paměti, správu vláken a lokalizaci. Proces vývoje her se při využití některého dostupného enginu často výrazně zlevní, z velké části díky opětovnému použití již napsaného kódu (8). Herní systémy také výrazně usnadňují portování21 her na jiné platformy. Nevýhoda herních systémů je, že vývojářům „diktují“ jak při vývoji hry postupovat. Nejpropracovanější systémy dokážou proces vývoje hry změnit natolik, že vývojář kromě skriptování scén a objektů nemusí napsat ani řádek kódu. 4.6.1 Unity3D Unity3D je komplexní herní systém pro vývoj multiplatformních her spolu s vlastním vývojovým prostředím (IDE). Unity umí kompilovat hry pro webový prohlížeč (použitím WebGL), technologii Flash, operační systémy Windows, Apple Mac OS, konzole Xbox 360, Nintendo Wii, PlayStation 3 a mobilní operační systémy Android a iOS (Obrázek 6). Portování her postavených na Unity3D je triviální, IDE se o všechno postará samo, vývojář jen zvolí, pro jakou platformu chce hru zkompilovat.
21
Portování softwaru – úpravy softwaru za účelem jeho fungování na jiných platformách
21
Obrázek 6: Vývojové prostředí Unity – volba platformy pro kompilaci
Unity3D je zdarma pouze v základní verzi, ve které lze kompilovat pro webový prohlížeč, MS Windows a Mac OS. Vývoj na Android je zpoplatněn 400 dolary v základní verzi a dalšími 1500 dolary za verzi Android Pro. Tato cena se zdá být vysoká, Unity3D je ovšem velmi propracovaný systém a pro profesionální studia může být jeho koupě dobrým strategickým tahem. Naštěstí je dostupná verze Trial22 Unity3D Android, která funguje 30 dní od registrace, takže i já jsem měl možnost si Unity osahat. 4.6.2 AndEngine AndEngine je zdarma Open Source 2D OpenGL herní systém pro platformu Android. Tento systém je vyvíjen komunitou okolo herního vývojáře Nicolase
Gramlicha
a
je
populární
především
mezi
nezávislými
nekomerčními vývojáři. Repositář se systémem uvolněným ke stažení lze nalézt na adrese https://github.com/nicolasgramlich/AndEngine.
22
Označení zkušební verze, platné jen krátký časový úsek
22
4.6.3 Corona Corona SDK byl vytvořen Walterem Luhu, spoluzakladatelem společnosti Ansca Mobile. Corona umožňuje programátorům vyvíjet mobilní aplikace pro iPhone, iPad a Android zařízení. Corona používá integrovaný jazyk Lua, vrstvený nad C++ a OpenGL, k vytváření graficky bohatých aplikací, které jsou velmi rychlé jak výkonem, tak i dobou vývoje. K získání Corona enginu je potřeba platit tzv. „členské příspěvky“ které jsou pro platformu Android 199 dolarů za rok. Spolu s SDK pak získáte přístup do fóra vývojářů a můžete využít nástroj LaunchPad, kterým se dá analyzovat provoz vaší aplikace. (9)
4.7
Herní framework
Kromě herních systémů, které jsou pro můj projekt zbytečně rozsáhlé, existují ještě herní frameworky. Při použití frameworku má vývojář plnou kontrolu nad kódem, musí ale implementovat věci, které engine řeší za něj. Vzhledem k tomu, že jsem se chtěl věnovat základům vývoje her, zvolil jsem pro svou práci vypracování vlastního jednoduchého frameworku.
23
5 Implementace hry 5.1
Herní framework
Hlavní přínos herního frameworku je abstrakce komunikace s operačním systémem. Usnadňuje tak některé často používané operace, které bych musel při každém použití těžkopádně volat. Místo toho komunikace probíhá pouze s frameworkem a ten zařídí vše potřebné sám. Herní framework se většinou dělí na jednotlivé moduly, které vykonávají určitý typ operací. Já jsem svůj framework rozdělil na tyto moduly:
Screen management (správa obrazovky) - tento modul je zodpovědný za vytvoření View23, do kterého se renderuje obraz hry. Také spravuje akce, jako minimalizování, pozastavení a obnovení hry.
Input (Vstup) - pracuje se vstupními senzory (dotykový displej, klávesnice, akcelerometr) a předává jejich data v přívětivém formátu.
File I/O (Čtení a zapisování do souborů) – ulehčuje práci se soubory na kartě SD.
Graphics (Grafika) – nahrává a vykresluje grafiku na obrazovku pomocí modulu Screen management.
Audio (Zvuk) – nahrává a přehrává hudbu a zvukové efekty.
Game (Hra) – spojuje všechny moduly pomocí kompozice (ostatní moduly jsou uloženy jako členské atributy) a umožňuje jednoduché vytvoření hry jejím rozšířením.
Každý z těchto modulů obsahuje jedno nebo více rozhraní a patřičné implementace. Tyto implementace mohou být změněny a tím zajištěna kompatibilita s jinými verzemi systému Android. Navíc framework dodržuje architekturu MVC (Model-View-Controller).
23
View (pohled) – zobrazitelná část uživatelského prostředí v Androidu
24
5.2
Hlavní smyčka
Protože se objekty ve hře pohybují v reálném čase, je potřeba co nejčastěji obnovovat obrazovku aktuálním obrazem. To se provádí v tzv. hlavní smyčce, jejíž kód se opakuje, dokud není hra ukončena. Jedna iterace hlavní smyčky se nazývá snímek. Počet snímků za sekundu (FPS24) je velmi důležitá hodnota, protože pokud klesne pod 30, lidské oko začne vnímat trhání obrazu. (10) Také musíme sledovat čas, který uplynul od minulého snímku. To je důležité pro tzv. „frame-independent“25 pohyb objektů, který nám zaručuje, že se herní svět bude pohybovat stejnou rychlostí na výkonných i méně výkonných zařízení. Pro ilustraci se podívejme na pseudokód herní smyčky: createWindowAndUIComponents(); Input input = new Input(); Graphics graphics = new Graphics(); Audio audio = new Audio(); Screen currentScreen = new MainMenu(); Float lastFrameTime = currentTime(); while( !userQuit() ) { float deltaTime = currentTime() – lastFrameTime; lastFrameTime = currentTime(); currentScreen.updateState(input, deltaTime); currentScreen.present(graphics, audio, deltaTime); } cleanupResources();
Zdrojový kód 1: Pseudokód hlavní smyčky
24
Frames per second – počet snímků za sekundu
25
Frame-independent – nezávislý na počtu snímků za sekundu
25
5.3
OpenGL ES
OpenGL ES26 je průmyslový standard pro programování 3D grafiky, především zaměřený na mobilní zařízení. Je udržován a vyvíjen skupinou Khronos, což je konglomerát společností jako ATI, NVIDIA a Intel. V současné době existují tři verze, OpenGL ES 1.0, 1.1 a 2.0. pro potřebu mé hry bohatě postačuje verze 1.0, která je podporována všemi zařízeními se systémem Android. 5.3.1 Inicializace OpenGL ES První, co potřebujeme, abychom mohli vykreslovat scénu pomocí OpenGL je pohled (view). Pro tento účel souží třída GLSurfaceView z Android API, potomek
třídy
View.
Součástí
GLSurfaceView
je
i
oddělené
vlákno
pro vykreslování scény. To je potřeba, aby vykreslování neběželo v UI vláknu a aplikace neustále reagovala na uživatelské vstupy. Pro jeho využití je
třeba
implementovat
GLSurfaceView.Renderer.
a
zaregistrovat
posluchač
(listener)
Ten obsahuje tyto metody:
interface Renderer { public void onSurfaceCreated(GL10 gl, EGLConfig config); public void onSurfaceChanged(GL10 gl, int width, int height); public void onDrawFrame(GL10 gl); }
Zdrojový kód 2: Rozhraní GLSurfaceView.Renderer
Nejdůležitější z těchto metod je onSurfaceCreated(), která je zavolána při vytvoření GLSurfaceView pohledu, a onDrawFrame(). V té volám hlavní herní smyčku. Jako další krok musíme nastavit výřez (viewport) prostoru, který má OpenGL zobrazit. To uděláme metodou GL10.glViewport(int x, int y, int width, int height).
26
Open graphics library for Embedded Systems
26
Poslední částí inicializace je nastavení OpenGL do módu paralelního zobrazení. K tomu slouží metody GL10.glMatrixMode(GL10.GL_PROJECTION) a následně GL10.glOrthof(int left, int right, int bottom, int top, int near, int far).
5.3.2 Objekty v OpenGL ES Základním stavebním kamenem každého objektu v OpenGL ES je trojúhelník, tvořený třemi vrcholy. Protože je moje hra dvoudimenzionální, zobrazená v paralelním zobrazení, při tvoření objektů jsem si vystačil se čtverci. Ty lze vytvořit pomocí dvou trojúhelníků, po třech vrcholech. Díky tzv. indexaci vrcholů lze takový čtverec vytvořit čtyřmi vrcholy, což usnadní OpenGL práci. Na vytvořené čtverce lze vzápětí nanést texturu. Tu je nejprve potřeba nahrát do video paměti a nastavit filtry, které definují, jak s texturou manipulovat při změně její velikosti. Tento proces je vidět ve zdrojovém kódu 3. Bitmap bitmap = BitmapFactory.decodeStream( game.getFileIO().readAsset("texture.png")); int textureIds[] = new int[1]; gl.glGenTextures(1, textureIds, 0); int textureId = textureIds[0]; gl.glBindTexture(GL10.GL_TEXTURE_2D, textureId); GLUtils.texImage2D(GL10.GL_TEXTURE_2D, 0, bitmap, 0); gl.glTexParameterf(GL10.GL_TEXTURE_2D, GL10.GL_TEXTURE_MIN_FILTER, GL10.GL_NEAREST); gl.glTexParameterf(GL10.GL_TEXTURE_2D, GL10.GL_TEXTURE_MAG_FILTER, GL10.GL_NEAREST); gl.glBindTexture(GL10.GL_TEXTURE_2D, 0); bitmap.recycle();
Zdrojový kód 3: Načtení textury do video paměti a nastavení filtrů
27
5.4
Vytvoření textur
Načítání textur je poměrně výpočetně drahý proces. Na každé obrazovce je alespoň pět textur a načítat každou zvlášť by na pomalejších zařízeních způsobilo rapidní pokles FPS. Naštěstí existuje trik, kterým jsem tento problém obešel. Všechny textury aplikace jsem umístil do jedné bitmapy (Obrázek 7), která se načte do video paměti pouze jednou. Takovému obrázku se říká atlas textur. V něm jsou pak textury definovány pomocí souřadnic. Za povšimnutí také stojí fakt, že do video paměti lze nahrávat pouze čtvercové bitmapy s rozměrem, který je mocninou dvojky, v mém případě 1024px na 1024px.
Obrázek 7: Atlas textur použitých ve hře
28
5.5
Herní objekty, detekce kolize a její reakce
Abychom mohli hýbat s herními objekty a řídit jejich kolize, je potřeba vytvořit pro každý objekt odpovídající třídy. Ty uchovávají informace o poloze, rychlosti a velikosti a tvaru objektu. Zároveň implementují metodu update(float
deltaTime),
která upraví pozici objektu na základě jeho
rychlosti. Tyto objekty jsou:
Pálka (Mallet)
Puk (Puck)
Brána (Goal)
Všechny tyto objekty jsou součástí třídy World, která má na starost jejich interakci. Abych mohl jednoduše testovat kolize, napsal jsem třídu OverlapTester, která obsahuje metody pro kontrolu překrývání objektů na základě jejich pozice, velikosti a tvaru. V každém snímku testuji, zda se puk nepřekrývá s nějakou z pálek, branek nebo krajními mantinely. V případě, že se objekty překrývají, reaguji na kolizi patřičnou reakcí. Pro jednoduchost počítám s dokonalou pružností objektů.
Překrytí puku a mantinelu – úhel odrazu se rovná úhlu dopadu. To lze implementovat nastavením opačné hodnoty horizontální složky rychlosti, pokud puk narazil na vertikální část mantinelu, a nastavením opačné hodnoty vertikální složky rychlosti, pokud došlo ke kolizi na horizontální části mantinelu.
Překrytí puku a pálky – znovu platí, že úhel odrazu vůči tečně v bodu doteku se rovná úhlu dopadu vůči této tečně. K výslednému vektoru rychlosti musíme přičíst současnou rychlost pálky.
Překrytí puku a brány – reakce na tuto událost je zapsání vstřeleného gólu.
29
5.6
Hudba a zvuk
K vytvoření zvukových efektů jsem použil sfxr, skvělý nástroj od Tomase Petterssona (11). Program slouží jako generátor zvukových efektů do her, přičemž je možné nastavit jednotlivé parametry požadovaného zvuku, nebo vybrat jednu ze sedmi kategorií a nechat si zvuk vytvořit náhodně.
Obrázek 8: Generátor zvukových efektů sfxr.
Vytvoření hudby je podstatně složitější, využil jsem proto server http://www.freemusicarchive.org/,
odkud
se
dá
stáhnout
komunitou
vytvořená hudba. U každé skladby je určeno, za jakých podmínek lze použít. Já pro svou hru zvolil skladbu „Hokusai“ od interpreta pojmenovaného theAudiologist, vydanou pod licencí Creative Commons (BY-NC-ND 3.0). Ta říká, že dílo nesmí být upravováno, nesmí být využito pro komerční účely a vždy musí být uveden autor. Tyto podmínky jsem splnil, autor je ve hře uveden v obrazovce Credits. 30
6 Závěr Cílem této práce bylo uvést čtenáře do problematiky vývoje a distribuce her pro mobilní platformy, především pro systém Android. Většina zdrojů na toto téma je v anglickém jazyce, přínos první části práce vidím obzvláště v tom, že umožňuje českému čtenáři dozvědět se bez delšího hledání důležité informace na jednom místě.
Druhá polovina práce se zabývá
návrhem a následnou implementací jednoduché hry. Výstupem je optimalizovaná hra – simulátor vzdušného hokeje. Hra využívá grafické knihovny OpenGL ES a ctí návrhový vzor MVC. Zdrojové kódy hry jsou přiloženy na CD.
6.1
Možné rozšíření hry
Během vývoje hry jsem postupně dostával nápady na další funkcionality hry, které jsem však nestihl implementovat. Jako nejpřínosnější rozšíření by byla implementace umělé inteligence protivníka. Hra by se tak dala hrát v jednom hráči. Uživatel by měl před začátkem hry možnost zvolit z několika obtížností, které by definovaly rychlost reakcí protivníkovi pálky. Další vylepšení, které bych rád přidal do hry, je možnost nejrůznějšího uživatelského nastavení. Na výběr by byla např. barva pálky a vzhled stolu.
31
7 Citovaná literatura 1. Apple Inc. iOS Developer Program. Apple Developer. [Online] [Citace: 28. 4 2011.] https://developer.apple.com/programs/ios/. 2. Google Inc. Android API Levels. Android Developers. [Online] [Citace: 11. 5 2012.] http://developer.android.com/guide/appendix/api-levels.html. 3. OpenSignalMaps. Android Fragmentation Visualized. opensignalmaps.com. [Online] [Citace: 10. 5 2012.] http://opensignalmaps.com/reports/fragmentation.php. 4. Pruett, Chris. Google I/O 2009 - Writing Real-Time Games for Android. YouTube.com. [Online] [Citace: 6. 2 2012.] http://www.youtube.com/watch?v=U4Bk5rmIpic. 5. Wikipedia. Air Hockey. Wikipedia.org. [Online] [Citace: 3. 5 2012.] http://en.wikipedia.org/wiki/Air_hockey. 6. United States Air hockey association. Rules. Air Hockey World. [Online] [Citace: 3. 5 2012.] http://www.airhockeyworld.com/usaarules.asp. 7. Zechner, Mario. Beginning Android Games. místo neznámé : Apess, 2011. 978-1430230427. 8. Ward, Jeff. What is a Game Engine? GameCareerGuide.com. [Online] [Citace: 3. 5 2012.] http://www.gamecareerguide.com/features/529/what_is_a_game_.php. 9. Ansca, Inc. Corona SDK Subscription Pricing. Anscamobile.com. [Online] [Citace: 11. 5 2012.] http://www.anscamobile.com/pricing/?ref=nav. 10. Koen Witters. Dewitters Gameloop. Koonsolo Games. [Online] [Citace: 13. 5 2012.] http://www.koonsolo.com/news/dewitters-gameloop/.
32
11. Pettersson, Tomas. sfxr. DrPetter's homepage. [Online] [Citace: 24. 4 2012.] http://www.drpetter.se/project_sfxr.html. 12. MEIER, Reto. Professional Android™ 2 Application Development. Indianapolis : Wiley Publishing, Inc., 2010. str. 543. ISBN: 978-0-470-56552-0. 13. Jirkovský, Jan, a další. Game Industry. D.A.M.O., 2011. 978-80-904387-1-2.
33
