Navodila za pisanje diplomskih nalog UM FERI

Transkripcija

1 UNIVERZA V MARIBORU FAKULTETA ZA ELEKTROTEHNIKO, RAČUNALNIŠTVO IN INFORMATIKO Peter Zlodej TEHNOLOŠKI VIDIKI RAZVOJA VEČIGRALSKE MOBILNE IGRE FLUFFY RUSH Magistrsko delo Maribor, februar 2017

2 TEHNOLOŠKI VIDIKI RAZVOJA VEČIGRALSKE MOBILNE IGRE FLUFFY RUSH Magistrsko delo Študent: Študijski program: Mentor: Lektorica: Peter Zlodej študijski program 2. stopnje Računalništvo in informacijske tehnologije prof. dr. Peter Kokol Nina Skube, prof. slov.

3

4 ZAHVALA Zahvaljujem se mentorju, prof. dr. Petru Kokolu, za pomoč in vodenje pri izdelavi magistrskega dela. Posebna zahvala gre tudi družini, ki me je podpirala vsa leta študija. i

5 Tehnološki vidiki razvoja večigralske mobilne igre Fluffy Rush Ključne besede: razvoj iger, večigralska igra, Unity, omrežna igra UDK: : (043.2) Povzetek V magistrskem delu proučujemo tehnološke vidike razvoja večigralskih mobilnih iger na primeru projekta Fluffy Rush. Obravnavamo pristope k razvoju komponent, skupnih vsem igram, posebno pozornost namenjamo tistim, ki so specifične za večigralske mobilne igre. Razvoj tako proučujemo z vidika implementacije uporabniškega dela igre, izvedbe mrežne komunikacije, organizacije in shranjevanja podatkov ter zagotavljanja zaščite in varnosti. V delu identificiramo odločitve o izbiri pristopov in tehnologij, s katerimi se razvijalci srečujejo med izdelavo tovrstnih iger, ter izpostavljamo razlike med možnimi izbirami. Podrobneje opisujemo rešitve, implementirane v obravnavani igri Fluffy Rush. ii

6 Technological Aspects Involved in the Development of the Multiplayer Mobile Game Fluffy Rush Keywords: game development, multiplayer game, Unity, online game UDC: : (043.2) Abstract In this master s thesis, we look at the technological aspects involved in development of the multiplayer mobile games in the example of the Fluffy Rush project. We discuss approaches to development of the components common to all games, and specifically focus on the components specific to multiplayer mobile games. The development is therefore explored from the perspective of front-end implementation, network communication implementation, data organization and storage, and security and protection strategies. In the thesis, we identify decisions on the choice of approaches and technologies that developers face during design of this kind of games, and point out differences among the available alternatives. We describe the solutions implemented in the game Fluffy Rush in detail. iii

7 KAZALO VSEBINE 1 UVOD Igra Fluffy Rush IZBIRA RAZVOJNEGA ORODJA Izbira igralnega pogona Igralni pogon Unity Principi dela v okolju Unity RAZVOJ UPORABNIŠKEGA DELA IGRE Uporabniški grafični vmesnik Izbira orodja za izvedbo grafičnega uporabniškega vmesnika Igralne mehanike Implementacija mehanike za nadzor gibanja igralnega objekta Implementacija dogodka ob medsebojni interakciji igralnih objektov IZVEDBA MREŽNE KOMUNIKACIJE IGRE Komunikacijski protokol Izbira rešitve za izvedbo mrežne komunikacije Implementacija modula za organizacijo iger Vzpostavitev igre med naključnimi nasprotniki Vzpostavitev igre med prijatelji Sinhronizacija položajev igralcev Interpolacija položajev igralcev Dead reckoning Sinhronizacija akcij igralcev SHRANJEVANJE PODATKOV iv

8 4.6 Game backend as a service ZAŠČITA IN VARNOST SKLEP LITERATURA v

9 KAZALO SLIK Slika 1.1: Glavni meni igre Fluffy Rush Slika 1.2: Primer tekme v živo v igri Fluffy Rush Slika 1.3: Okno za upravljanje s prijatelji Slika 1.4: Okno za oblikovanje avatarja Slika 1.5: Okno dobljenih značk za dosežke Slika 2.1: Grafični urejevalnik igralnega pogona Unity Slika 2.2: Scenski pogled na igralne objekte s pripetimi slikami in trkalniki Slika 3.1: Elementi maske (poudarjeni z oranžno) in prostorski elementi (poudarjeni z zeleno) Slika 3.2: Izsek izvorne kode za gibanje in kontroliranje glavnega karakterja igre GibanjeKarakterja.cs Slika 3.3: Položaj in zasuk igralnega objekta glavnega karakterja v času pred in med trkom z igralnim objektom goba ter po njem Slika 3.4: Implementacija proženja dogodka v začetni in končni fazi dotika igralnih objektov Slika 4.1: Potek komunikacije po protokolu TCP/IP [14] Slika 4.2: Tok podatkov pri igri, gostovani s strani igralca Slika 4.3: Tok podatkov pri uporabi namenskega strežnika Slika 4.4: Organizacija iger z uporabo rešitve PUN Slika 4.5: Diagram poteka organizacije igre med naključnimi igralci Slika 4.6: Implementacija organizacije iger med naključnimi igralci Slika 4.7: Okno za organizacijo igre med prijatelji v igri Fluffy Rush Slika 4.8: Diagram poteka organizacije igre med prijatelji Slika 4.9: Implementacija gostovanja igre med prijatelji Slika 4.10: Odsek programske kode, odgovorne za sprejemanje povabil in povezovanje v zasebno sobo Slika 4.11: Vpliv zakasnitve in frekvence pošiljanja na prikaz položaja karakterja igralca A z vidika obeh igralcev (prirejeno po [1])...42 Slika 4.12: Položaji objekta z vidikov obeh igralcev ob interpolaciji na strani igralca B (prirejeno po [1]) Slika 4.13: Napaka ob predvidevanju položaja z uporabo metode Dead reckoning (prirejeno po [1]) Slika 4.14: Klic metode RPC za izstrelitev rakete Slika 5.1: Povezava med igro in storitvami»game backend as a service« Slika 6.1: Potek pošiljanja sporočila šifriranega z javnim ključem [1] vi

10 KAZALO TABEL Tabela 1: Primerjava igralnih pogonov Unity in Cocos2d-x... 8 Tabela 2: Primerjava orodij za razvoj grafičnih uporabniških vmesnikov Unity GUI in Next-Gen UI Tabela 3: Razdelitev nalog strežnika in odjemalca v igri Fluffy Rush Tabela 4: Primerjava omrežnih orodij Unity networking in PUN vii

11 UPORABLJENE KRATICE XP (angl. Experience Points) točke za merjenje dosežkov v igri HUD (angl. Head-up Display) maska za prikaz elementov grafičnega vmesnika UI (angl. User Interface) uporabniški vmesnik GUI (angl. Graphical User Interface) grafični uporabniški vmesnik TCP (angl. Transmission Control Protocol) protokol za nadzor prenosa IP (angl. Internet Protocol) internetni protokol PUN (angl. Photon Unity Networking) orodje za implementacijo mrežne komunikacije v igrah RPC (angl. Remote Procedure Call) klic oddaljene procedure BaaS (angl. Backend as a Service) model za povezavo aplikacije s strežnikom»v oblaku«api (angl. Application Programming Interface) programski vmesnik viii

12 1 UVOD V preteklih letih smo bili priča velikemu napredku na področju mobilnih tehnologij. Mobilne naprave postajajo vedno pomembnejši del vsakdana, aplikacije in igre pa se v veliki meri selijo z namiznih računalnikov na pametne telefone ter tablične računalnike. Proces razvoja kompleksnejših mobilnih iger spremljajo pomembne odločitve o uporabi različnih pristopov in tehnologij, njihova izbira pa je v veliki meri odvisna od zahtev in narave igre. Uporabniki pametnih mobilnih naprav lahko danes izbirajo med več kot dvema milijonoma različnih mobilnih iger, razvoj ene izmed njih bomo z več tehnoloških vidikov proučili v tem magistrskem delu. Obravnavali bomo mobilno igro Fluffy Rush, ki smo jo razvili v okviru tričlanske ekipe. Proučili bomo postopke in razvoj komponent, ki so skupne vsem mobilnim igram, posebno pozornost pa bomo namenili tistim, ki so specifične za večigralske mobilne igre. Tako bomo najprej proučili dejavnike, prisotne pri izbiri razvojnega orodja, nato pa nadaljevali s poglavjem o razvoju uporabniškega dela igre, kjer bomo na primerih iz igre Fluffy Rush opisali implementacijo grafičnega uporabniškega vmesnika in igralnih mehanik. Posebej bomo izpostavili izvedbo elementov mrežne komunikacije igre, kot so komunikacijski protokol, organizacija iger in sinhronizacija položajev ter akcij igralcev. Nadaljevali bomo z opisom rešitev za shranjevanje podatkov, zaključili pa z vidikom zagotavljanja zaščite in varnosti v večigralskih povezanih igrah. Identificirali bomo odločitve o izbiri pristopov in tehnologij, ki jih morajo razvijalci sprejeti med načrtovanjem in razvojem tovrstnih iger, podrobneje pa bomo opisali rešitve, ki smo jih uporabili ob razvoju obravnavanega projekta. Oblikovali bomo celostno sliko razvoja večigralske mobilne igre s tehnoloških vidikov na primeru igre Fluffy Rush, ki je podrobneje opisana v nadaljevanju. 1

13 1.1 Igra Fluffy Rush Fluffy Rush je dvodimenzionalna večigralska igra za mobilne naprave, v kateri igralci med seboj tekmujejo v živo preko spleta. Cilj igre je prečkanje ciljne črte pred nasprotniki, na poti do cilja pa si igralci lahko pomagajo z mehanizmi, s katerimi upočasnijo druge igralce ali pospešijo svoj prihod na cilj. Dirka poteka v interaktivnem okolju, kar pomeni, da poleg medsebojne interakcije igralcev na potek igre vplivajo tudi elementi, ki so del okolice. Za uspešen razvoj igre Fluffy Rush je poleg osnovnih mehanik igre bilo treba razviti širok nabor funkcionalnosti, ki so igro povezale v smiselno celoto, te pa so uporabnikom dostopne iz glavnega menija igre (Slika 1.1) in so navedene v nadaljevanju. Slika 1.1: Glavni meni igre Fluffy Rush. Med glavne funkcionalnosti igre Fluffy Rush spadajo: Meniji in navigacija meniji in navigacijski elementi igralcem omogočajo dostop do vseh glavnih funkcionalnosti igre. Glavna naloga teh elementov je jasno usmerjanje uporabnika in sporočanje pomembnih informacij ob ustreznem času. Pomemben del predstavlja tudi lokalizacija menijev, kar pomeni, da so napisi prevedeni v jezik, ki ga izbere uporabnik. Tekma v živo predstavlja jedro igre Fluffy Rush. Igra omogoča tekmovanje v živo preko spleta s prijatelji ali z naključno izbranimi nasprotniki (Slika 1.2). Za 2

14 igro zadostujeta dva igralca, največje dovoljeno število udeležencev posamezne igre pa je omejeno na štiri igralce. Slika 1.2: Primer tekme v živo v igri Fluffy Rush. Upravljanje s prijatelji v okviru igre lahko igralci na svoj seznam prijateljev dodajo druge igralce, ki jih nato lahko povabijo v zasebno igro in z njimi komunicirajo s pomočjo vgrajene klepetalnice. Omogočena je tudi povezava z obstoječimi prijatelji na socialnem omrežju Facebook. Okno za upravljanje s prijatelji prikazuje Slika 1.3. Slika 1.3: Okno za upravljanje s prijatelji. 3

15 Personalizacija avatarja igralci lahko v namenskem oknu po lastnih željah oblikujejo podobo svojega avatarja z nastavitvami barve karakterja in z izbiro številnih dodatkov (Slika 1.4). Vsak igralec izbere tudi svoj vzdevek, ki v povezavi z avatarjem predstavlja identiteto igralca. Slika 1.4: Okno za oblikovanje avatarja. Posodobitve inventarja v inventar spadajo mehanizmi oziroma orožja, ki jih igralci uporabljajo med tekmovanjem z namenom upočasnitve nasprotnikov ali pospešitve lastnega napredka. Orožje je v meniju igre možno posodabljati in s tem povečati njegov vpliv v igri. Interna valuta igre v primeru igre Fluffy Rush valuto predstavljajo virtualni cekini, ki jih igralci zaslužijo z dosežki v igri ali z nakupom s pravim denarjem znotraj igre (in-app purchase). S to valuto se opravljajo vsi virtualni nakupi, kot so nadgradnje in presonalizacija avatarja. Lestvica najboljših lestvica predstavlja seznam imen najboljših igralcev s pripadajočimi doseženimi točkami. S pomočjo lestvice igralci dobijo predstavo o svoji uvrstitvi na globalni ravni, prav tako je na voljo ločena zasebna lestvica, ki prikazuje zgolj uvrstitve med prijatelji. Značke za dosežke poleg glavnega cilja igre, tj. priti prvi na cilj, lahko igralci med tekmo opravljajo tudi druge naloge, ki jim prinašajo dodaten virtualni zaslužek 4

16 in značke za dosežke (achievements). Značke popestrijo dinamiko igre in predstavljajo dodatno motivacijo za igranje (Slika 1.5). Slika 1.5: Okno dobljenih značk za dosežke. Sistem napredovanja s posameznimi dosežki v igri igralci nabirajo točke XP (experience points). Z večanjem točk XP se veča tudi raven igralca (level), od katere so odvisni drugi aspekti igre, npr. organizacija igre med igralci iste ravni (matchmaking). Sistem napredovanja prav tako predstavlja dodatno motivacijo za igranje in velja za standardno komponento modernih iger. Potisna sporočila potisna sporočila (push notifications) uporabljamo za komunikacijo med lastniki igre in igralci ter tudi za medsebojno sporazumevanje igralcev. Potisna sporočila omogočajo obveščanje igralcev o novostih in dogajanju v igri tudi, ko ti na svojih mobilnih napravah opravljajo druga opravila in niso aktivni v igri. Igra je zasnovana za pametne telefone in tablične računalnike, ki jih poganjajo operacijski sistem Android ali ios 7 in novejše različice. Igra je brezplačna in objavljena na digitalnih tržnicah Google Play, Amazon App Store ter Apple App Store. Širok spekter funkcionalnosti projekta Fluffy Rush in podpora več ciljnih platform se odražata v kompleksnosti razvoja igre, zato je bilo pred začetkom razvoja ključnega pomena izbrati najprimernejša orodja in tehnologije za razvoj posameznih komponent igre. 5

17 2 IZBIRA RAZVOJNEGA ORODJA Prvi izziv razvijalcev mobilnih iger predstavlja izbira najprimernejšega razvojnega orodja glede na zahteve igre. Ta odločitev je bistvena za uspešen razvoj in izdajo, saj so od izbire okolja odvisne hitrost razvoja, cena in kakovost končnega produkta. Kot večina razvijalcev smo tudi v primeru projekta Fluffy Rush igro želeli ponuditi čim večjemu številu uporabnikov, zato smo načrtovali razvoj in objavo na platformah Android ter ios, ki skupaj predstavljata več kot 90 % trga pametnih mobilnih naprav [9]. Ob začetku razvoja igre, združljive z dvema platformama, smo se najprej soočili z odločitvijo o tem, ali bomo vzporedno razvijali dve različici igre v naravni obliki za vsako platformo posebej (native application) ali pa bomo uporabili enega izmed igralnih pogonov (game engine), ki poleg ostalih uporabnih funkcionalnosti omogoča tudi enkraten univerzalen razvoj za obe ciljni platformi hkrati. Igralni pogon je orodje, specifično zasnovano za razvoj iger, in predstavlja številne prednosti v primerjavi z razvojem v naravni obliki: Enkraten univerzalen razvoj razvoj za vse ciljne platforme poteka hkrati in v istem razvojnem okolju (cross-platform development). Spremembe kode za posamezno platformo niso potrebne. Vgrajen napredni grafični pogon (rendering engine) grafični pogon je namenjen generiranju dve- ali tridimenzionalne animirane grafike in je pogosto zasnovan na podlagi obstoječih ogrodij za izvedbo računalniške grafike, kot sta Direct3D in OpenGL. Grafični pogon predstavlja osnovo za razvoj vizualno intenzivnih video iger. Vgrajen fizikalni pogon (physics engine) fizikalni pogon poskrbi za realistično simulacijo fizikalnih zakonov znotraj igre. Uporaba fizikalnega pogona je odvisna od narave igre. Vgrajen zvočni pogon (audio engine) zvočni pogon sestoji iz algoritmov, povezanih z generiranjem, obdelavo in kompresijo zvočnih zapisov. S pomočjo tega pogona se izvaja predvajanje zvokov znotraj igre. Nekateri pogoni omogočajo tudi prostorsko predvajanje zvokov (na primer jakost zvoka se poveča, ko se glavni karakter igre približa določenemu objektu). 6

18 Prednosti, ki jih predstavlja razvoj z uporabo igralnega pogona, so razlog za množično uporabo tovrstnih orodij v industriji mobilnih iger [1]. Igralni pogoni omogočajo hitrejši razvoj iger, saj so jedrne funkcionalnosti, kot sta grafični in fizikalni pogon, že razvite, razvijalci pa se lahko tako osredotočijo na izvedbo drugih aspektov igre. Prednost predstavlja tudi možnost enkratnega razvoja za več ciljnih platform hkrati, kar bistveno zmanjša čas razvoja in hkrati olajša kasnejše nadgradnje igre. Zaradi naštetih prednosti smo se v primeru projekta Fluffy Rush odločili za razvoj igre z uporabo igralnega pogona. 2.1 Izbira igralnega pogona Razvijalcem je na voljo širok nabor igralnih pogonov, za uspešen razvoj pa je ključno izbrati najprimernejšega glede na zahteve igre. Pogoni se med drugim razlikujejo v podprtih ciljnih platformah, razpoložljivih programskih jezikih, dimenzijah grafike, upravljanjem z dokumenti (asset management) in v izvedbi ter funkcionalnostih grafičnega urejevalnika. Seveda je treba upoštevati tudi vidike, kot so kakovost dokumentacije, velikost skupnosti razvijalcev (development community) in cena. V primeru projekta Fluffy Rush smo najprej identificirali glavne zahteve igre, na podlagi katerih smo izbirali igralni pogon. Ugotovili smo, da potrebujemo pogon z naslednjimi funkcionalnostmi: podpora za izdelavo dvodimenzionalnih iger, podpora za izvedbo mrežne komunikacije, možnost razvoja za mobilne operacijske sisteme Android in ios, fizikalni pogon, kakovostna dokumentacija in možnost testiranja igre v okviru igralnega pogona. Po pregledu različnih možnosti smo se znašli na točki, ko smo izbirali med dvema vodilnima igralnima pogonoma na trgu, ki sta omogočala razvoj igre z našimi zahtevami. To sta pogona Unity in Cocos2d-x. Čeprav sta obe orodji zadostili osnovnim tehničnim zahtevam, smo pri končni izbiri morali upoštevati določene razlike, ki smo jih izpostavili v tabeli V nadaljevanju bomo podrobneje opisali prednosti in slabosti obeh pogonov. 7

19 Tabela 1: Primerjava igralnih pogonov Unity in Cocos2d-x Funkcionalnost/Igralni Unity Cocos2d-x pogon Razvoj tridimenzionalnih iger Da Ne Razvoj dvodimenzionalnih iger Da Da Podpora za izvedbo mrežne Da Da, le z uporabo razširitev komunikacije Odprtokodni sistem Ne Da Kakovostna dokumentacija Da Da Preprost grafični uporabniški Da Ne vmesnik Možnost testiranja igre v Da Da, le z uporabo razširitev okviru igralnega pogona Podprti programski jeziki C#, UnityScript, Boo C++, Lua, JavaScript Podprte mobilne ciljne platforme ios, Android, Tizen, Windows Phone 8, Fire ios, Android, Tizen, Windows Phone 8 OS 5 Podpora za razvoj za igralne Da Ne konzole Brezplačna uporaba Na voljo omejena brezplačna in plačljiva različica Da Iz primerjalne tabele je razvidno, da sta oba pogona primerna za izdelavo dvodimenzionalnih iger, podpirata izvedbo mrežne komunikacije in omogočata razvoj za izbrani ciljni platformi ios ter Android. V primeru projekta Fluffy Rush sta torej obe izbiri zadostovali glavnim tehničnim zahtevam in sta bili primerni za razvoj načrtovane igre. Poleg osnovnih zmogljivosti pogonov pa smo pri izbiri upoštevali tudi druge aspekte. Pogon Cocos2d-x je odprtokodni sistem, ki ga vzdržuje, nadgrajuje in posodablja skupnost razvijalcev. Posledica tega je pomanjkanje uradne pomoči, ki pa jo omenjena skupnost dobro nadomešča. Dejstvo, da je pogon zasnovan na odprtokodnem sistemu, se 8

20 kaže tudi v nekoliko slabše organizirani, bolj razdrobljeni dokumentaciji. V primeru pogona Unity je na voljo uradna obsežna in kakovostna dokumentacija, kreatorjem iger pa je v pomoč tudi močna skupnost razvijalcev, aktivna na spletnih forumih in v namenskem portalu Unity Answers. Naslednji vidik, ki smo ga upoštevali, je grafični urejevalnik pogona (editor) in njegove funkcionalnosti. Pomemben del razvoja iger predstavljata postavljanje grafičnih elementov na sceno in nastavljanje njihovih atributov, kot so velikost, zasuk, barvni odtenek in drugi. Pogon Cocos2d-x zahteva izvedbo omenjenih opravil izključno z uporabo programske kode, kar lahko pri obsežnih igrah bistveno podaljša čas razvoja. Orodje Unity omogoča izvedbo istih opravil s pomočjo intuitivnega urejevalnika, kar pomeni, da za predogled postavitve grafičnih elementov na sceni nista potrebna prevajanje in izvedba programske kode, kar lahko močno skrajša čas, potreben za načrtovanje scene. S pomočjo vmesnika pogona Unity lahko relativno preprosto opravljamo tudi druge naloge, kot so animacija elementov (animation), izdelava sistemov delcev (particle systems), konfiguracija fizikalnega pogona in druge. Pomemben aspekt pri izbiri igralnega pogona so predstavljale tudi možnosti razhroščevanja (debugging) in predogleda oz. testiranja igre v okviru pogona. Pogon Unity podpira obe omenjeni funkcionalnosti. Z uporabo Unity lahko razvijalci igro v celoti razvijejo in testirajo znotraj pogona, kar pomeni, da za vsako novo razvito funkcionalnost igre ni potrebe po prevajanju in izvedbi kode na mobilni napravi. Ta možnost predstavlja izjemen prihranek časa pri razvoju igre. Cocos2d-x ponuja podobno rešitev, a le z uporabo razširitve (add-on), ki deluje na osnovi virtualnih naprav (emulators). Uporaba te tehnologije nekoliko skrajša čas razvoja, vendar pogon Unity to delo opravlja hitreje, saj ne izvaja izgradnje mobilne aplikacije, ki je potrebna za predogled na virtualnih ali dejanskih napravah, za vsak predogled, ampak ga izvaja neposredno v urejevalniku pogona. Nazadnje smo analizirali vse razlike in upoštevali še lastne izkušnje, ki so bile predvsem povezane z razvojem projektov v programskem jeziku C#. Ocenili smo, da bo razvoj zaradi naštetih razlik najhitreje potekal z uporabo igralnega pogona Unity 4.6 in jezika C#, zato smo ga izbrali za izvedbo projekta Fluffy Rush. Cena pri izbiri ni bila faktor, saj so vse opisane funkcionalnosti pogona Unity na voljo v brezplačni različici. 9

21 2.2 Igralni pogon Unity Unity je orodje za izdelavo video iger, razvito s strani podjetja Unity Technologies, in je trenutno vodilno na področju razvoja mobilnih iger [10]. Pogon ponuja širok nabor orodij, ki omogočajo razvoj dvodimenzionalnih in tridimenzionalnih iger za množico ciljnih platform. Med glavne funkcionalnosti pogona Unity spadajo grafični pogon, fizikalni pogon, zvočni pogon, orodje za animacijo, sistem trkov (collision system) in sistem pisanja ter organizacije programske kode oz. skript (scripting system). Grafični pogon je zasnovan na tehnologijah izrisovanja Direct3D, OpenGL in OpenGL ES, fizikalni pogon pa je podprt s tehnologijo PhysX. Unity omogoča uvoz dokumentov iz množice programov za modeliranje in grafično oblikovanje, kot so, Maya, 3ds Max, Blender, Adobe Photoshop, Adobe Illustrator in drugi, prav tako podpira uvoz zvočnih ter video datotek. Razvoj je podprt z zmogljivim grafičnim urejevalnikom, sistemom za upravljanje z dokumenti in vgrajenimi orodji za razhroščevanje kode ter profiliranje. Podjetje Unity poleg igralnega pogona ponuja tudi spekter brezplačnih in plačljivih storitev, ki so združljive z orodjem. Te omogočajo preprosto vgradnjo funkcionalnosti, kot so oglasi, analitika, nakupi znotraj igre in povezava igre s socialnimi omrežji. Na voljo je tudi uradna spletna tržnica Unity asset store, kjer potekata prodaja in nakup vključkov (plug-ins). Tukaj poleg paketov vizualnih efektov, tridimenzionalnih modelov in animacij najdemo širok nabor programskih knjižnic, ki olajšajo delo pri specifičnih opravilih, kot sta izdelava mrežno povezanih iger ali izvedba kompleksnih grafičnih vmesnikov [6]. Igralni pogon Unity je na voljo v brezplačni osebni različici in v treh plačljivih: razširjena, profesionalna in industrijska. Osebna in razširjena različica se v glavnem razlikujeta v podpori naprednih funkcionalnosti, ki so večinoma povezane z razvojem tridimenzionalnih iger, profesionalna in industrijska pa poleg naprednih funkcij ponujata še dostop do izvorne kode pogona ter do pomoči strokovnjakov podjetja Unity. Koncept dela in struktura ter organizacija programske kode se med igralnimi pogoni razlikujejo. Razvoj z orodjem Unity poteka s kombinacijo dela v grafičnem urejevalniku (Slika 2.1) in v urejevalniku kode. V nadaljevanju bomo natančneje opisali komponente urejevalnika in osnovna načela pisanja programske kode v igralnem pogonu Unity. 10

22 2.2.1 Principi dela v okolju Unity Izdelava igre v pogonu Unity temelji na sistemu scen (scenes) in igralnih objektov (game objects). Igralni objekti so jedrni objekti, ki lahko predstavljajo karakterje, kulise in druge komponente scene. Sami po sebi ne opravljajo specifičnih nalog, temveč jih uporabljamo kot vsebnike (containers) za komponente, ki izvajajo določene naloge. Tako lahko na igralne objekte pripnemo komponente, kot so slike, modeli, trkalniki (colliders), animacije, svetilni elementi, zvoki in skripte. Igralni objekti so hierarhično organizirani, vsak objekt lahko vsebuje podobjekt (child object), ki deduje določene lastnosti nadrejenega objekta (parent object) [3, 11]. Scene predstavljajo prostor igre in vsebujejo igralne objekte. S scenami razvijalci oblikujejo igro tako, da v njih postavljajo okolja, karakterje, ovire in druge komponente. Namenjene so izdelavi glavnega igralnega okna in tudi menijev ter drugih pogledov igre. Slika 2.1: Grafični urejevalnik igralnega pogona Unity. 11

23 Pomemben del razvoja iger z orodjem Unity poteka s pomočjo grafičnega urejevalnika, ki je sestavljen iz šestih glavnih pogledov (Slika 2.1) [11]: Scenski pogled (scene view) omogoča natančen pregled nad igralnimi objekti v sceni. V tem pogledu lahko razvijalci direktno manipulirajo z velikostjo, orientacijo in lokacijo igralnih objektov. Možen je pogled na sceno z več zornih kotov, omogočena je tudi povečava pogleda (zoom). Inšpekcijsko okno (inspector) namenjeno urejanju posameznih igralnih objektov. S pomočjo tega okna potekajo nastavljanje vseh atributov objektov in dodajanje ter odstranjevanje pripetih komponent. Hierarhija objektov (object hirearchy) v oknu hierarhije objektov potekajo ustvarjanje, brisanje in razvrščanje igralnih objektov v hierarhiji. Vsi objekti na sceni in njihove relacije so predstavljene v obliki drevesa (tree view). Brskalnik projekta (project browser) to okno omogoča pregled nad vsemi dokumenti (assets) igre, kamor spadajo scene, skripte, slike, modeli in drugi. V tem oknu potekata tudi uvoz in izvoz dokumentov. Pogled igre (game view) v pogledu igre se izvaja predogled igre in njenih funkcionalnosti. Tukaj si lahko razvijalci ogledajo, kako bo igra videti in kako delovala na različnih mobilnih napravah. Večina postopkov testiranja in razhroščevanja igre poteka v tem pogledu. Konzola (console) konzola prikazuje napake, opozorila in druga sporočila, ki jih generira pogon Unity. V istem oknu je omogočen tudi izpis lastnih sporočil, ki ga sprožimo v programski kodi z uporabo vgrajene funkcije. Konzola je pomembno orodje, uporabljeno predvsem v postopkih iskanja napak oz. razhroščevanja. Poleg grafičnega urejevalnika, kjer poteka velik del izdelave igre, je ključnega pomena tudi pisanje programske kode, ki se izvaja v urejevalniku kode. V igralnem pogonu Unity je koda organizirana v skripte (scripts), ki vsebujejo programsko kodo za interpretacijo vhodnih kontrol s strani igralca in za proženje dogodkov v igri ob ustreznem času. Skripte uporabljamo tudi za implementacijo grafičnih efektov, nadzor fizike igralnih objektov, algoritme umetne inteligence in druga opravila. V okolju Unity skripte običajno pripnemo na igralne objekte in tako ustvarimo samodejno povezavo med programsko kodo ter objektom v sceni. Pisanje skript poteka v okolju standard Mono runtime, za interakcijo in 12

24 dostop do komponent pogona Unity iz programske kode pa se uporabljajo vgrajene funkcije. Za razumevanje naslednjega poglavja je nujna obrazložitev naslednjih vgrajenih funkcij [11]: Start() Start se kliče ob nastanku skripte, ki vsebuje to funkcijo. Skripta nastane, ko je kreiran objekt, na katerega je skripta pripeta, kar je običajno ob zagonu scene oz. igre. V tej funkciji izvajamo začetno programsko kodo, kot je proženje uvodne animacije ali začetna postavitev igralnega objekta. Update() funkcija Update se kliče ob prikazu vsake sličice zaslona (frame), kar je pri optimiziranih igrah običajno med 30- in 60-krat na sekundo. V tej funkciji je pogosta implementacija elementov igre, kot so premikanje objektov, zaznavanje vhodnih kontrol (control inputs), merjenje časa in druge. Pomemben del iger predstavlja tudi zaznavanje trkov med igralnimi objekti. To omogočajo vgrajene komponente, imenovane trkalniki, ki jih je možno pripeti na posamezen igralni objekt. Unity za razvoj dvodimenzionalnih iger podpira kreiranje trkalnikov v obliki štirikotnika, kroga in večkotnika (polygon). Slika 2.2 prikazuje scenski pogled na tri igralne objekte s pripetimi slikami in trkalniki (poudarjeni z zeleno barvo). Slika 2.2: Scenski pogled na igralne objekte s pripetimi slikami in trkalniki. 13

25 Ob medsebojni interakciji trkalnikov se samodejno kličejo vgrajene funkcije pogona Unity, s pomočjo teh funkcij pa razvijalci določijo akcije, ki se izvedejo ob določenem tipu interakcije med objekti. Za razumevanje poglavja o izvedbi igralne mehanike je potrebna obrazložitev naslednjih funkcij, povezanih s trkalniki [11]: OnCollisionEnter2D() se samodejno kliče ob prvem medsebojnem kontaktu trkalnikov dveh igralnih objektov. Klic se izvede v vseh skriptah, ki vsebujejo to funkcijo in so pripete na kateregakoli od obeh igralnih objektov. OnCollisionStay2D() () samodejen klic te funkcije se izvede za vsako posodobitev oz. okvir zaslona, v katerem sta trkalnika dveh igralnih objektov v kontaktu. S to funkcijo je možno preveriti, ali se dva določena objekta v danem trenutku dotikata. OnCollisionExit2D() funkcija se samodejno kliče takoj po zadnjem medsebojnem kontaktu trkalnikov dveh igralnih objektov. Ta funkcija potrjuje prenehanje stika trkalnikov dveh igralnih objektov. 14

26 3 RAZVOJ UPORABNIŠKEGA DELA IGRE V prejšnjem poglavju smo identificirali odločitve, ki jih morajo razvijalci sprejeti ob izbiri glavnega orodja za razvoj mobilne igre, in natančneje opisali igralni pogon Unity, ki smo ga uporabili za izvedbo projekta Fluffy Rush. V tem poglavju se bomo osredotočili na vidike razvoja uporabniškega dela (front-end) obravnavane igre z uporabo opisanega igralnega pogona. V sklop uporabniškega dela igre štejemo vse elemente, ki jih uporabnik vidi in je z njimi v neposredni interakciji. Sem tako štejemo komponente grafičnega uporabniškega vmesnika (graphical user interface) in vse vidne elemente ter mehanike igre (game mechanics). V nadaljevanju bomo primerjali dve orodji za izvedbo uporabniškega vmesnika igre v okolju Unity in na primeru projekta Fluffy Rush predstavili primer razvoja igralne mehanike. 3.1 Uporabniški grafični vmesnik Zasnova grafičnega uporabniškega vmesnika predstavlja zahteven aspekt razvoja mobilnih iger. Med igro je igralcem treba predstaviti vrsto informacij, prostora za izvedbo te naloge pa je glede na velikost zaslonov mobilnih naprav relativno malo. Slaba zasnova uporabniškega vmesnika se lahko kaže v slabi uporabniški izkušnji, posledica te pa je slab nastop igre na trgu ne glede na kakovost izvedbe ostalih delov igre. Ob razvoju iger je treba upoštevati tudi tip vhodne naprave, kar je v primeru mobilnih iger zaslon na dotik. Uporabniški vmesnik mobilne igre mora biti tako zasnovan na način, ki omogoča preprosto interakcijo z uporabo standardnih gest, kot so dotik (touch), drsenje (slide) in uščip (pinch). Nazadnje izziv predstavlja tudi raznolikost ločljivosti (resolution) zaslonov mobilnih naprav, saj je za optimalni prikaz uporabniškega vmesnika potrebna prilagojena postavitev elementov na zaslonu glede na njegovo ločljivost. Elementi uporabniškega vmesnika opravljajo različne naloge in jih lahko razporedimo v logične skupine. V nadaljevanju bomo predstavili glavne tipe komponent uporabniškega vmesnika, ki smo jih implementirali v igri Fluffy Rush. 15

27 Glavni tipi elementov uporabniškega vmesnika igre Fluffy Rush [12]: Grafični kontrolni elementi (graphical control elements) predstavljajo komponente, s pomočjo katerih uporabnik v aplikacijo oz. igro neposredno vnaša ali bere podatke in sproža dogodke v igri. V primeru obravnavane igre v to skupino štejemo elemente menijev, kot so navigacijski gumbi (navigation button), drsni seznami (scroll list) in vnosna polja (edit box). Elementi maske HUD (Head Up Display) najdemo jih v glavni sceni, kjer poteka dejanska igra. Prikazani so nad vsemi ostalimi objekti igre in so vedno vidni uporabniku. Z njihovo pomočjo smo v igri Fluffy Rush prikazali podatke, kot sta število zbranih točk in trenutno zaporedno mesto igralca, ter povzetke nedavnih dogodkov v igri. Med elemente maske spada tudi akcijski gumb, s pomočjo katerega igralci sprožajo različne akcije (Slika 3.1). Prostorski elementi (spatial elements) prostorski elementi grafičnega vmesnika so neposredno povezani z igralnimi objekti in prostorom igre. Namenjeni so prikazu informacij, ki so odvisne od postavitve igralnih objektov v sceni. Ob razvoju igre Fluffy Rush smo ta tip elementov uporabili za prikaz vzdevkov igralcev nad njihovimi avatarji, ki so med igro neprestano v gibanju (Slika 3.1). Slika 3.1: Elementi maske (poudarjeni z oranžno) in prostorski elementi (poudarjeni z zeleno). 16

28 3.1.1 Izbira orodja za izvedbo grafičnega uporabniškega vmesnika Pred začetkom razvoja uporabniškega vmesnika igre Fluffy Rush smo morali sprejeti odločitev o izbiri orodja za izvedbo te naloge. Izbirali smo lahko med že vgrajenim sistemom Unity GUI in vrsto orodij tretjih razvijalcev, ki nudijo programske knjižnice ter pripomočke za izdelavo grafičnih uporabniških vmesnikov. Med slednjimi je bil v času razvoja najpopularnejši produkt podjetja Next-Gen UI, zato smo pred začetkom dela proučili razlike med tem orodjem in vgrajenim sistemom Unity GUI. Pred primerjavo smo določili želene lastnosti orodja za razvoj grafičnega vmesnika: podpora osnovnih elementov vseh naštetih skupin v podpoglavju 3.1, vključene funkcije za prilagajanje vmesnika glede na ločljivost zaslona naprave, delovanje s čim manjšo porabo računalniških virov, predvsem procesorske moči in pomnilnika, močna skupnost razvijalcev, kakovostna dokumentacija in dobra integracija v urejevalnik pogona Unity. Poleg naštetih lastnosti smo primerjali tudi druge vidike obeh orodij, kot sta razpoložljivost vnaprej izdelanih kompleksnih komponent uporabniških vmesnikov in cena. Razlike so izpostavljene v tabeli 3.1. Tabela 2: Primerjava orodij za razvoj grafičnih uporabniških vmesnikov Unity GUI in Next-Gen UI. Funkcionalnost/orodje Unity GUI Next-Gen UI Podpora osnovnih elementov uporabniškega Da Da vmesnika Samodejno prilagajanje vmesnika glede na Da Da ločljivost zaslona Optimizacija porabe računalniških virov Dobra Srednje dobra Močna skupnost razvijalcev Ne Da Kakovostna dokumentacija Da Da 17

29 Dobra integriranost v urejevalnik pogona Unity Da Da Vnaprej izdelane kompleksne komponente Ne Da uporabniških vmesnikov Takojšnja združljivost z vsako novo različico Da Ne pogona Unity Brezplačna uporaba Da Ne Orodje Next-Gen UI je med razvijalci zelo priljubljeno, saj je bilo z vidika funkcionalnosti mnogo let veliko zmogljivejše od vgrajenih rešitev pogona Unity. Zgodnje različice Unity GUI so namreč podpirale le izdelavo grafičnih vmesnikov z uporabo programske kode, prav tako je bila otežena animacija elementov vmesnika. Navedene pomanjkljivosti je odpravljalo orodje Next-Gen UI, zato je med razvijalci postalo standard za izdelavo grafičnih vmesnikov v pogonu Unity. Z izidom različice pogona Unity 4.6 se je vgrajeni sistem za razvoj uporabniških vmesnikov Unity GUI po funkcionalnosti zelo približal opisanemu orodju, zato je odločitev o izbiri najustreznejšega orodja postala težja. Popularnost orodja Next-Gen UI se kaže v močni skupnosti razvijalcev in dobri podpori na spletnih forumih. Čeprav je močna tudi skupnost kreatorjev iger s pogonom Unity, je ta nekoliko šibkejša, ko govorimo o razvoju grafičnega vmesnika, saj je prenovljeni sistem Unity GUI na voljo relativno kratek čas. Obe orodji sta podprti z dobro organizirano in podrobno dokumentacijo ter z video vodniki (video tutorials), ki razvijalce vodijo skozi razvoj posameznih komponent vmesnika. Dodatna prednost, ki jo predstavlja orodje Next-Gen UI, je obsežna zbirka vnaprej izdelanih elementov uporabniškega vmesnika, s pomočjo katerih je mogoč pospešen razvoj igre. Svoje prednosti pa predstavlja tudi uporaba vgrajenega sistema Unity GUI. Z uporabo tega orodja je zagotovljena najboljša integracija s pogonom Unity in posledično optimizacija porabe računalniških virov, kar je v primeru razvoja mobilnih iger zaradi šibkejše procesorske moči in velikosti pomnilnika še posebej pomembno. Prednost uporabe Unity GUI je tudi takojšnja združljivost orodja z vsako novo različico pogona Unity, česar orodje Next-Gen UI ne more vedno zagotoviti. Zadnja, največja prednost, ki jo predstavlja uporaba Unity GUI, je cena, orodje je namreč brezplačno, medtem ko je cena posamezne licence orodja Next-Gen UI 95 ameriških dolarjev. 18

30 Ob odločitvi glede uporabe orodja za izvedbo grafičnega vmesnika v projektu Fluffy Rush smo ugotovili, da sta za to nalogo primerni obe alternativi. Čeprav bi z uporabo Next-Gen UI razvoj lahko potekal hitreje in bi bil podprt z močnejšo skupnostjo razvijalcev, smo se odločili za uporabo vgrajenega sistema Unity GUI. Na odločitev sta vplivali predvsem boljša optimizacija porabe računalniških virov in neposredna podpora s strani pogona Unity. Pomembna dejavnika sta predstavljali tudi rast skupnosti razvijalcev in brezplačnost uporabe orodja. 3.2 Igralne mehanike Igralne mehanike so jedrna pravila, procesi in podatki, ki določajo, kako igra poteka, kdaj se prožijo dogodki v igri ter kakšni so pogoji za zmago oziroma poraz. Skupek vseh igralnih mehanik predstavlja izzive igre in nabor dovoljenih akcij igralca, ki jih skupaj imenujemo igralni način (gameplay). Dobro zastavljene mehanike so pri razvoju iger ključnega pomena, saj se te neposredno kažejo v kakovosti in uspešnosti končnega produkta na trgu [2, 8]. Poznamo več vrst igralnih mehanik, ki z različnih vidikov oblikujejo igralni način. V nadaljevanju so navedeni štirje glavni tipi, implementirani v projektu Fluffy Rush [2]: Fizika igre (game physics) med mehanike tega tipa spadajo fizikalni zakoni in omejitve v svetu igre (game world), ki pogosto niso v skladu z zakoni fizike realnega sveta. Z njimi sta omejeni smer in hitrost, s katero se lahko igralni objekti gibajo, prav tako definirajo dogodke ob medsebojni interakciji objektov. V primeru igre Fluffy Rush fizika igre določa, da je samodejno gibanje avatarjev igralcev v horizontali omogočeno samo v smeri z leve proti desni, v vertikali pa gibanje določajo vhodne kontrole igralca in simulirana gravitacija. Interna ekonomija (internal economy) interna ekonomija predstavlja pravila, povezana z elementi igre, ki jih je možno zbirati in porabiti ter z njimi trgovati znotraj igre. V to kategorijo v obravnavani igri sodijo mehanike, povezane s tokom interne valute, predstavljene z zlatimi cekini, ki jih igralci lahko služijo z dosežki znotraj igre in jih v virtualni trgovini zamenjajo za posodobitve orožij ali dekoracijske dodatke avatarja. 19

31 Mehanizmi napredovanja (progression mechanisms) med mehanizme napredovanja sodijo komponente igre, povezane z napredkom igralca, ki ga običajno spremljata večanje zahtevnosti in dostop do višjih ravni igre. Primer mehanizma napredovanja iz našega projekta so vgrajene misije, kjer za vsako opravljeno nalogo igralec prejme nagrado v obliki interne valute, s tem pa hkrati odklene dostop do nove, zahtevnejše misije. Družbena interakcija (social interaction) mehanike družbene interakcije so posebej izrazite pri povezanih večigralskih igrah, kot je igra Fluffy Rush. Sem spadajo vsi elementi igre, odgovorni za komunikacijo in interakcijo med igralci, kot so povezana dirka v živo, vgrajena klepetalnica in možnost povezave s prijatelji preko obstoječih družbenih omrežij. Načrtovanje igralnih mehanik je interdisciplinarno področje, ki zahteva znanja smeri, kot so grafično oblikovanje, načrtovanje uporabniške izkušnje, psihologija iger in strategije monetizacije. Po uspešnem načrtovanju vsaka mehanika zahteva tehnično implementacijo in integracijo v igro. Ob razvoju igre Fluffy Rush smo implementirali vrsto mehanik, odgovornih za oblikovanje končnega igralnega načina. Sem spadajo tako tiste, ki v ozadju skrbijo za potek igre, kot na primer interna ekonomija igre, kot tudi tiste, s katerimi so uporabniki med igranjem v direktnem stiku. Sem štejemo predvsem mehanike, kot so sistem kontrol igre, dogodki ob interakciji med objekti in omejitve dogajanja v svetu igre s strani simulirane fizike igre. V nadaljevanju bomo opisali postopek razvoja dveh pomembnih delov mehanike, implementiranih v obravnavani igri Implementacija mehanike za nadzor gibanja igralnega objekta Nadzor gibanja glavnega karakterja igre Fluffy Rush omogočajo preproste kontrole in pravila. Karakter se ob začetku igre z določeno hitrostjo začne samodejno gibati v smeri z leve proti desni, simulirana gravitacija pa poskrbi za njegov padec proti tlom. Z dotikom zaslona igralec povzroči sunek v navpični smeri, kar prepreči padec karakterja. Če ta pade na tla, se od tal odbije, hitrost v horizontalni smeri pa se nekoliko zmanjša. Slika 3.2 prikazuje programsko kodo, odgovorno za gibanje in kontroliranje karakterja. 20

32 Slika 3.2: Izsek izvorne kode za gibanje in kontroliranje glavnega karakterja igre GibanjeKarakterja.cs. Ker je predstavljena skripta»gibanjekarakterja.cs«odgovorna za gibanje in kontroliranje glavnega karakterja igre, smo jo s pomočjo grafičnega urejevalnika najprej pripeli na temu ustrezen igralni objekt v sceni. V skripti smo z izrazom»using«najprej definirali uporabo knjižnice UnityEngine, ki je potrebna za povezavo s komponentami 21

33 igralnega pogona. V četrti vrstici opazimo, da nov razred, imenovan GibanjeKarakterja, deduje lastnosti razreda MonoBehaviour. Ta razred je osnovni razred, njegove lastnosti dedujejo vse skripte, ki jih ustvarimo s pogonom Unity. V naslednjih vrsticah smo definirali naslednje spremenljivke: hitrostx predstavlja faktor hitrosti, s katero se glavni karakter igre premika v horizontalni smeri v svetu igre; dovoljenopomikanjevsmerix vklopi ali izklopi samodejno pomikanje karakterja v horizontalni smeri; vrednost te spremenljivke nastavljajo skripte, odgovorne za režijo igre, tako je samodejno pomikanje na primer onemogočeno ob prikazu menija za pavzo; omogocenekontrole določa, ali so v danem trenutku vhodne kontrole igralca dovoljene ali ne; podobno kot prejšnja spremenljivka je tudi ta nadzorovana s strani skript režije igre; zacetnapozicija v tej spremenljivki hranimo začetne koordinate glavnega karakterja v sceni; vertikalnisunek določa moč sunka v vertikalni smeri ob vhodni komandi igralca. Skripta vsebuje dve glavni funkciji, prva se izvede funkcija Start, v kateri postavimo igralni objekt glavnega karakterja na določeno začetno pozicijo. To omogoča komponenta transform, ki je namenjena branju in pisanju položaja, dimenzij ter zasuka igralnega objekta. Druga v skripti je funkcija Update, ki se, kot smo omenili v prejšnjem poglavju, izvede za vsak prikazani okvir zaslona, kar pomeni, da je število klicev te funkcije odvisno od zmogljivosti procesorja naprave, ki poganja igro. Na zmogljivejših napravah se tako funkcija Update vsako sekundo izvede večkrat kot na manj zmogljivih napravah, kar smo morali ob razvoju upoštevati. V tej funkciji smo najprej implementirali samodejno gibanje igralca v horizontalni smeri. Premik igralnega objekta smo ponovno izvedli z uporabo komponente transform, a smo tokrat uporabili metodo Translate, ki poskrbi za relativen premik objekta glede na trenutni položaj v dani smeri in določeni razdalji. Smer pomika smo določili z vektorjem smerdesno, razdaljo pomika pa z množenjem tega vektorja s faktorjem hitrosti hitrostx in z vrednostjo Time.deltaTime. Ta vrednost predstavlja čas trajanja zadnjega okvirja zaslona 22

34 v sekundah. Množenje s to vrednostjo zagotavlja, da premik izvedemo v odvisnosti od časa in ne v odvisnosti od frekvence prikazanih okvirjev zaslona. Tako zagotovimo enakomerno razdaljo premika objektov na vseh napravah [11]. V funkciji Update smo implementirali tudi detekcijo vhodnih kontrol igralca in proženje pripadajočega dogodka. Razred Input je namenjen zaznavanju dogodkov vhodnih naprav, kot so miška, tipkovnica ali v primeru mobilnih iger zaslon na dotik. Z dostopom do vrednosti Input.touchCount smo določili, koliko hkratnih dotikov je na zaslonu v trenutku preverjanja. Unity loči več faz dotika (touch phases), kot so začetek, pridržanje in prenehanje. V osemintrideseti vrstici smo zato za vsak prisoten dotik preverili, ali je trenutno v fazi začetka dotika in samo v tem primeru sprožili dogodek. Dogodek, ki ga sprožimo v primeru dotika zaslona, določa štirideseta vrstica obravnavane skripte. S klicem GetComponent lahko dostopamo do vseh komponent, pripetih na igralni objekt, v tem primeru do RigidBody2D. Ta komponenta vzpostavlja povezavo igralnega objekta s fizikalnim pogonom orodja Unity. Ta omogoča klic funkcije AddForce, s pomočjo katere v vertikalni smeri dodamo sunek objektu glavnega karakterja in s tem povzročimo skok oziroma preprečimo padec. Ta mehanika predstavlja glavni način manevriranja v obravnavani igri Implementacija dogodka ob medsebojni interakciji igralnih objektov Pomemben del igralnega načina v igri Fluffy Rush predstavljata zaznavanje trkov igralnih objektov in proženje dogodkov ob njihovi medsebojni interakciji. Slednje smo implementirali s pomočjo sistema trkov, podprtega s strani igralnega pogona Unity, ki ga sestavljajo komponente, pripete na igralne objekte, imenovane trkalniki, in z njimi povezane vgrajene funkcije, opisane v prejšnjem poglavju. Sistem trkalnikov smo uporabili pri implementaciji medsebojne interakcije avatarjev igralcev in tudi za proženje dogodkov ob stiku avatarjev z interaktivnimi objekti, ki predstavljajo okolico igre. V primeru igre Fluffy Rush v to kategorijo objektov spada tudi objekt»goba«, ki igralcem predstavlja priložnost za pospešen prihod njihovega karakterja na cilj. Ob stiku glavnega karakterja z gobo se njegova hitrost za nekaj trenutkov poveča v vodoravni in navpični smeri. V nadaljevanju bomo opisali razvoj te mehanike igre, dogajanje pred in med trkom omenjenih igralnih objektov ter po njem prikazuje Slika

35 Slika 3.3: Položaj in zasuk igralnega objekta glavnega karakterja v času pred in med trkom z igralnim objektom goba ter po njem. Kot prvi korak implementacije opisane mehanike smo na igralni objekt glavnega karakterja in na objekt goba s pomočjo urejevalnika igralnega pogona najprej pripeli dva trkalnika. Ta sta na Sliki 3.3. poudarjena z zelenim robom, v dejanski igri sta uporabniku nevidna. Po opravljenem delu v urejevalniku smo ustvarili novo skripto in jo pripeli na igralni objekt glavnega karakterja. Kot prikazuje Slika 3.3, med označenim časovnim trenutkom t1 in t2 objekta še nista v stiku, v trenutku t2 nastopi prvi stik, trenutek t3 pa predstavlja točko prenehanja trka. Slika 3.4. predstavlja programsko implementacijo dogodkov v začetni in končni fazi trka. Slika 3.4: Implementacija proženja dogodka v začetni in končni fazi dotika igralnih objektov. 24

36 Slika 3.4 prikazuje vsebino skripte»trkikarakterja.cs«, ki vsebuje dve funkciji in je pripeta na igralni objekt glavnega karakterja. V grafičnem urejevalniku pogona Unity lahko vsak objekt opremimo z značko (tag), tako smo objektu, ki ga upravlja igralec, določili značko»glavnikarakter«, igralnemu objektu, ki predstavlja gobo, pa značko»goba«. Funkcija OnCollisionEnter se samodejno kliče ob prvem stiku trkalnikov obeh objektov, kot argument pa prejme spremenljivko tipa Collision, ki vsebuje podatke o objektu, ki je pravkar trčil z objektom, na katerega je pripeta obravnavana skripta. Znotraj te funkcije smo najprej preverili, ali je objekt glavnega karakterja trčil v objekt z značko»goba«in v tem primeru sprožili ustrezna dogodka. Ob trku smo tako z dostopom do komponente Rigidbody2D s pomočjo fizikalnega pogona objektu glavnega karakterja dodali ustrezno silo oz. pospešek v vodoravni in navpični smeri, ki je definirana v četrti vrstici kode. Takoj za tem smo v enajsti vrstici dostopali do komponente AudioSoruce in s funkcijo Play predvajali pripeto zvočno datoteko pripeto na igralni objekt. Funkcija OnCollisionExit se samodejno kliče ob prekinitvi stika trkalnikov obeh objektov. V tej funkciji smo prav tako najprej preverili, ali gre za interakcijo z objektom z značko»goba«in v tem primeru dostopali do animacije z imenom»zasukkarakterja«, ki smo jo predhodno izdelali s pomočjo grafičnega urejevalnika ter jo pripeli na objekt glavnega karakterja. S klicem funkcije Play smo predvajali omenjeno animacijo, kar sproži zasuk glavnega karakterja za 360 stopinj okoli osi Z, kot kaže Slika 3.3 med časovnima trenutkoma t3 in t4. 25

37 4 IZVEDBA MREŽNE KOMUNIKACIJE IGRE Na trgu je na voljo množica enoigralskih iger (single-player games), v katerih so igralci soočeni z vnaprej določenimi izzivi ali virtualnimi nasprotniki, ki jih vodi umetna inteligenca. Takšni nasprotniki ravnajo v skladu z določenimi pravili in ne zmorejo človeških razmislekov ter nepredvidljivosti. Povezane večigralske igre (networked multiplayer games) so igre, ki omogočajo hkratno igro več igralcev preko spleta v istem virtualnem okolju in pogosto ob istem času. Zagotavljajo družbeno interakcijo med igralci, in sicer v smislu sodelovanja ali medsebojnega tekmovanja. Povezane večigralske igre pogosto omogočajo neposredno komunikacijo med igralci v obliki vgrajene klepetalnice (chat room). Poznamo asinhrone in sinhrone povezane igre. Med asinhrone štejemo tiste, ki ne zahtevajo hkratne aktivnosti vseh igralcev, ampak je v igri hkrati aktiven samo igralec, ki je na vrsti (turn-based). Primer takšne igre je spletni šah, kjer eden od igralcev vedno čaka na potezo drugega. V sinhronih igrah so aktivni vsi povezani igralci hkrati, stanje igre pa se neprestano posodablja, tako igralci v vsakem trenutku poznajo položaje in akcije nasprotnikov [13]. Med asinhrone igre spada tudi obravnavana igra Fluffy Rush. Za uspešen razvoj povezanih večigralskih iger je bistvena mrežna komunikacija med napravami igralcev, ki temelji na komunikacijskem protokolu in organizaciji toka podatkov med igralci. V naslednjem poglavju bomo predstavili uveljavljene postopke in načine mrežne komunikacije, potrebne za razumevanje nadaljnjih poglavij. 4.1 Komunikacijski protokol Pomemben del razvoja povezanih večigralskih iger najprej predstavljata uspešna vzpostavitev povezave med igralci in zagotavljanje zanesljive mrežne komunikacije med igro. V jedrnem delu igre je prav tako izrazitega pomena natančna sinhronizacija stanja igre, kar v praksi pomeni, da so prikazani položaji karakterjev in objektov okolja na napravah vseh igralcev prikazani enako ter ob istem času, prav tako je treba zagotoviti usklajeno proženje akcij igralcev. Za uspešno izvedbo naštetih opravil potrebujemo osnovni način za mrežno komunikacijo, torej prenos podatkov med povezanimi napravami. Najbolj razširjen način 26

38 izvedbe komunikacije večigralskih iger je metoda z uporabo standardnega protokola za nadzor prenosa TCP/IP (Transmission Control Protocol / Internet Protocol) in vtičnic (sockets). Protokol TCP/IP zagotavlja zanesljiv prenos sporočil v obe smeri ob ustreznem času, vrstnem redu in brez podvajanja [1]. Komunikacija po protokolu teče med programoma strežnika (server) in odjemalca (client). Med obema se vzpostavi povezava, določena s strežnikovim in odjemalčevim naslovom IP (IP adress) ter vrati (port). Program strežnika na svojem naslovu IP in vratih sprejema zahteve za povezavo ter pakete podatkov (packets), ki jih pošilja odjemalec, ta pa na svojih vratih in naslovu sprejema pakete s strani strežnika. Slika 4.1 prikazuje podrobnejši potek komunikacije po protokolu TCP z uporabo vtičnic [1]. Slika 4.1: Potek komunikacije po protokolu TCP/IP [14]. Strežnik s funkcijo bind najprej zapiše lokalni naslov IP, na katerem s klicem funkcije listen začne s poslušanjem zahteve za povezavo s strani odjemalca. Zahtevo za povezavo 27

39 odjemalec strežniku pošlje s klicem connect, strežnik pa jo lahko sprejme s klicem accept. Ko je povezava vzpostavljena, je s funkcijami write in read omogočena obojestranska komunikacija, torej izmenjava paketov, ki predstavljajo najmanjšo enoto informacije v mrežni komunikaciji. Po končani izmenjavi podatkov se povezava zapre [14]. V primeru igre Fluffy Rush smo s pomočjo omenjenega protokola med igralci izmenjevali podatke o imenih igralcev, položaju karakterjev, doseženih točkah posameznega igralca, postavitvi interaktivnih elementov v sceni in druge informacije, pomembne za potek igre. Pomembno vlogo pri toku teh informacij predstavlja strežnik, na katerega so povezani vsi igralci in služi kot agent za prenos informacij. Neposredna komunikacija med odjemalci ni mogoča. Če želi določen igralec poslati isto sporočilo trem drugim igralcem, ga pošlje najprej strežniku, ta pa poskrbi, da je sporočilo dostavljeno ostalim. Gostovanje igre je možno izvesti na več načinov, v nadaljevanju sta opisana dva najpogosteje uporabljena pri izdelavi povezanih iger [5]: Igra, gostovana s strani igralca z uporabo tega načina eden od igralcev gostuje igro in nastopa kot strežnik, ostali igralci pa se kot odjemalci nanj povežejo (Slika 4.2). Vsa komunikacija nato teče preko gostujočega igralca. Prednost uporabe tega načina je odprava potrebe po namenskem strežniku za gostovanje igre, slabost pa predstavlja odvisnost igre od gostujočega igralca. Če ta zapusti igro, se prekine povezava z vsemi odjemalci, posledično se prekine tudi igra. V primeru šibke internetne povezave gostujočega igralca nastopijo tudi druge težave, ki so posledica prevelikih časovnih zamikov in izpadov povezave. Slika 4.2: Tok podatkov pri igri, gostovani s strani igralca. 28

40 Uporaba namenskega strežnika (dedicated server) način z uporabo namenskega strežnika deluje tako, da igro gostuje namenska naprava, po navadi strežniški računalnik (Slika 4.3). V tem primeru vsi igralci nastopijo kot odjemalci, ki se povežejo na omenjeni strežnik, ki je odgovoren za vso komunikacijo. Prednost tega načina je zagotovljena robustna povezava, ki omogoča nemoten potek igre tudi v primeru, če katerikoli od igralcev zapusti igro pred koncem. Slabost tega pristopa predstavlja popolno nedelovanje igre v primeru odpovedi namenskega strežnika. Slika 4.3: Tok podatkov pri uporabi namenskega strežnika. Poleg opisanih prednosti uporaba namenskega strežnika ponuja več kot le osnovo za komunikacijo med igralci. Uporabimo ga lahko kot servis za organizacijo iger med naključnimi nasprotniki (matchmaking) in tudi za shranjevanje podatkov o aktivnih dirkah ter igralcih. Namenski strežnik lahko prav tako skrbi za komunikacijo vgrajene klepetalnice. Ob razvoju projekta Fluffy Rush smo zaradi navedenih prednosti izbrali izvedbo mrežne komunikacije z uporabo namenskega strežnika. Spekter nalog, ki jih namenski strežnik opravlja poleg osnovne komunikacije, je odvisen od odločitve razvijalcev. Sprejeti je treba odločitev o tem, kako bosta potekala organizacija skupin oz. dodeljevanje nasprotnikov in komunikacija med neaktivnimi igralci (npr. povabila prijatelja v igro), ter predvsem, kje se bo izvajala glavna logika igre. Pri tej odločitvi smo v projektu Fluffy Rush izbirali med tremi tipi namenskih strežnikov[15]: Neavtoritativni strežnik (non-authoritative server) ta izvedba strežnika opravlja le nalogo posrednika sporočil med odjemalci in ni na noben način povezana s potekom ali z logiko igre. Takšen pristop je z vidika preprečevanja goljufanja najmanj primeren, saj vsa logika igre teče lokalno na aplikacijah 29

41 odjemalcev, delovanje katerih je do nekatere mere možno manipulirati z javno dostopnimi programskimi orodji. Prednost tega načina so minimalne zahteve po procesorski moči strežnika. Avtoritativni strežnik (authoritative server) predstavlja najbolj varen način za izvedbo komunikacije v igrah. Na avtoritativnem strežniku teče celotna logika igre, kar pomeni, da se tukaj vodi tudi stanje igre, kot so izračuni položajev objektov v sceni, in drugih vrednosti. Odjemalci tako na strežnik le pošiljajo svoje akcije, ta pa jih interpretira, proži ustrezne dogodke in posodobi stanje igre. Ta način omogoča tudi spremembe določenih aspektov igre s strani razvijalcev, brez potrebe po posodobitvi aplikacije oz. igre na napravah igralcev. Slabost popolnoma avtoritativnih strežnikov predstavlja relativno visoka procesorska zahtevnost, kar se kaže v višji ceni najema strežnika. Polavtoritativni strežnik (semi-authoritative server) je kombinacija obeh opisanih izvedb. Tako del shranjevanja podatkov in logike igre opravljamo na strežniku, drugi del pa na odjemalcih. Na strežniku običajno hranimo podatke, ključne za izid igre, in tako preprečimo najosnovnejše načine goljufanja, večji del logike ter mehanik igre pa poteka na odjemalcih. V primeru igre Fluffy Rush smo se odločili za izvedbo komunikacije z uporabo polavtoritativnega strežnika. Razdelitev nalog strežnika in odjemalca prikazuje Tabela 3. Tabela 3: Razdelitev nalog strežnika in odjemalca v igri Fluffy Rush. Strežnik posredovanje sporočil med odjemalci; organizacija iger povezovanje igralcev v posamezno igro; vodenje podatkov o aktivnih igrah in igralcih; pošiljanje povabil za igro med prijatelji; vodenje ključnih vrednosti za izid igre čas začetka dirke, čas prihoda na cilj vsakega igralca. Odjemalec pogon logike igre izračun položajev objektov v sceni, zaznavanje interakcij in proženje dogodkov; sprejemanje in pošiljanje podatkov drugim odjemalcem preko strežnika podatki o avatarjih, vzdevkih igralcev, položajih in akcijah. 30

42 4.2 Izbira rešitve za izvedbo mrežne komunikacije Za razvoj komponent mrežne komunikacije z uporabo igralnega pogona Unity je razvijalcem na voljo vgrajena rešitev Unity networking in tudi množica orodij, razvitih s strani tretjih razvijalcev, kot so ulink, Photon Unity Networking, Forge in DarkRift. Ta vsebujejo programske knjižnice in pripomočke, ki razvijalcem olajšajo vključevanje elementov mrežne komunikacije v igro. Izbira pravega orodja je v veliki meri odvisna od žanra igre. V primeru projekta Fluffy Rush govorimo o akcijski dirki, ki zahteva natančno in pogosto usklajevanje položajev objektov, kar se odraža v potrebi po hitri ter stabilni komunikacijski rešitvi. V času razvoja igre je bil med orodji tretjih razvijalcev najširše uporabljen sistem PUN (Photon Unity Networking), zato smo ob razvoju projekta izbirali med omenjenim sistemom in vgrajeno rešitvijo Unity networking. Pri izbiri orodja za izpeljavo mrežne komunikacije v igri smo upoštevali naslednje vidike: zagotovljena stabilnost in hitrost povezave; nabor vgrajenih funkcionalnosti; model gostovanja igre (gostovanje s strani igralca ali namenskega strežnika); zahtevnost in čas, potreben za razvoj z uporabo orodja; gostovanje in razširljivost namenskega strežnika. Obe rešitvi sta namenjeni razvoju mrežne komunikacije v igrah in vsebujeta vse potrebne mehanizme za uspešno izvedbo. Kljub temu so prisotne razlike v načinu dela z obema orodjema, te so predstavljene v Tabeli 4. Tabela 4: Primerjava omrežnih orodij Unity networking in PUN. Funkcionalnost/orodje Unity networking PUN Podpora mrežne komunikacije z Da Da uporabo protokola TCP/IP. Omogočeno gostovanje iger s strani igralca (program strežnika teče na napravi enega od igralcev). Da Ne Omogočeno gostovanje iger na Da, le z lastnim Da, osnovne funkcije 31

43 namenskem strežniku. Omogočena izvedba avtoritativnega namenskega strežnika (simulacija fizike, interakcij med igralci in vodenje občutljivih vrednosti tečejo na strežniku). Razvita funkcionalnost za sporočanje stanja igralnih objektov (položaj, zasuk in dimenzije). Razvita funkcionalnost za samodejno organizacijo iger dodeljevanje in povezovanje nasprotnikov. Podpora za preprosto gostovanje in razširljivost zmogljivosti namenskega strežnika. razvojem strežniškega programa. Da Da Ne Ne strežniškega programa so že razvite. Ne Da Da Da Rešitev Unity networking je vgrajena v igralni pogon in omogoča gostovanje iger z uporabo namenskega strežnika ali s strani enega od igralcev. Ker smo se pri razvoju igre Fluffy Rush odločili za izvedbo z namenskim strežnikom, smo primerjali zahteve in funkcionalnosti obeh rešitev. Unity networking zahteva samostojen razvoj celotnega strežniškega programa. Tako morajo razvijalci sami razviti osnovne komponente, kot sta sistem za organizacijo iger in dodeljevanje nasprotnikov ali vodenje trenutno aktivnih igralcev in iger. Razvijalcem je prepuščeno tudi gostovanje strežniškega programa in zagotavljanje razširljivosti (scalability), stabilne povezave, zaščite ter varnosti na strežniškem koncu. Navedene lastnosti lahko pomenijo znatno podaljšan čas in povišane stroške razvoja ter vzdrževanja igre [15]. Del omenjenih pomanjkljivosti vgrajene rešitve Unity networking odpravlja orodje PUN, ki ga dopolnjuje storitev gostovanja strežnika v oblaku Photon Cloud. Ta ponuja 32

44 izvedbo gostovanja igre z namenskim strežnikom z že razvitimi osnovnimi funkcionalnostmi, kot so izvedba osnovne komunikacije, organizacija iger in vodenje evidence aktivnih igralcev. Razvijalci lahko tako s pomočjo programskega vmesnika PUN iz programa odjemalca dostopajo do funkcij strežniškega programa in preko njega komunicirajo z drugimi odjemalci ter ga konfigurirajo s preprostimi ukazi. Implementacija omrežne komunikacije igre z orodjem PUN predstavlja najhitrejšo pot, saj za osnovne tipe iger odpravlja potrebo po razvoju strežniškega programa. Prav tako je s strani servisa Photon Cloud poskrbljeno za zanesljivo povezavo, preprosto razširljivost, zaščito in varnost na strani strežnika. Kljub omenjenim prednostim pa PUN spremljajo določene omejitve. Na strežniku PUN je sicer možno voditi določene vrednosti in implementirati lastne funkcije, povezane z igro, a omenjena rešitev ne podpira izvedbe popolnoma avtoritativnega strežnika, kar pomeni, da mora večji del logike igre, proženje dogodkov in zaznavanje interakcij med igralci potekati na strani odjemalcev. Takšna izvedba pomeni manjši nabor funkcionalnosti strežniškega programa in nekoliko nižjo stopnjo zaščite pred goljufanjem, a hkrati ne zahteva visoke zmogljivosti strežnika, kar se odraža v nižji ceni gostovanja [5, 15]. Ob razvoju igre Fluffy Rush smo se pri izbiri orodja odločali glede na osnovne potrebe igre in čas oziroma zahtevnost implementacije z obema rešitvama. Največjo fleksibilnost v smislu funkcionalnosti strežnika predstavlja avtoritativna izvedba, ki jo od obeh podpira le vgrajena rešitev Unity networking. Kljub temu smo se odločili za izvedbo s polavtoritativnim namenskim strežnikom in orodjem PUN, predvsem zaradi možnosti gostovanja s servisom Photon Cloud. Tako smo se izognili potrebi po lastnem gostovanju in zagotavljanju razširljivosti na strani strežnika. Ker so vgrajene funkcionalnosti PUN zadostovale vsem zahtevam naše igre, smo se prav tako izognili lastni implementaciji funkcij strežniškega programa. Na tak način smo lahko izjemno hitro razvili komponente mrežne komunikacije v igri. V nadaljevanju bomo opisali razvoj jedrnih elementov mrežne komunikacije v projektu Fluffy Rush s pomočjo PUN. Proučili bomo izvedbo organizacije iger, sinhronizacijo položajev in akcij igralcev ter obravnavanje zapletov pri komunikaciji. 33

45 4.3 Implementacija modula za organizacijo iger Organizacija iger in dodeljevanje nasprotnikov predstavljata osnovno funkcionalnost vseh večigralskih iger, ki jo je možno izpeljati na več načinov. Tako lahko igra omogoča tekmovanje z naključnimi igralci, prijatelji ali igro med igralci iste skupine (na primer povezovanje igralcev z enakim nivojem spretnosti igranja). V projektu Fluffy Rush je modul za organizacijo odgovoren za povezovanje aktivnih igralcev v skupine po dva, tri ali štiri člane, ki lahko po uspešni povezavi začnejo z medsebojno igro. V projektu smo implementirali dva načina organizacije iger. Prvi predstavlja vzpostavitev igre med naključnimi igralci, drugi pa zasebno igro med prijatelji. Za razumevanje implementacije obeh načinov je treba razložiti strukturo iger, kot jo določa uporabljeno orodje PUN (Slika 4.4). Slika 4.4: Organizacija iger z uporabo rešitve PUN. Orodje PUN ponuja vgrajeno rešitev za organizacijo iger na strani strežnika, ki temelji na sistemu predprostora (lobby) in sob (rooms). Ob zagonu igre in prihodu v glavni meni se v ozadju vsak igralec samodejno poveže na strežnik ter se uvrsti na seznam aktivnih igralcev v predprostoru, kjer mu je omogočen dostop do seznama sob. Sobe predstavljajo posamezne seje iger, v katerih lahko v primeru projekta Fluffy Rush sodelujejo do štirje 34

46 člani. Igralci se lahko povežejo v eno od obstoječih ali ustvarijo svojo sobo. Te so lahko vidne ali nevidne. Vidne so javne in dostopne vsem igralcem, do nevidnih pa lahko dostopajo samo igralci, ki poznajo identifikacijsko oznako oziroma ime sobe. PUN loči tudi med odprtimi in zaprtimi sobami, pri čemer odprte dovoljujejo priključitev novega igralca v sejo, zaprte pa prošnjo za povezavo zavrnejo [16]. Na Sliki 4.4 opazimo, da je prva soba vidna in odprta, kar pomeni, da se lahko v to igro priključi katerikoli od aktivnih igralcev. Druga soba je vidna vsem igralcem, a se vanjo ne more priključiti nihče, saj je zaprta zaradi zasedenosti vseh mest. Tretja soba je zasebna oziroma nevidna vsem uporabnikom, v to sejo se lahko povežejo samo igralci, ki poznajo identifikacijsko oznako sobe, določeno s strani igralca, ki je sobo ustvaril. To oznako lahko prejmejo v obliki povabila v igro. Četrta soba je nevidna in zaprta, torej se vanjo ne more pridružiti nihče, saj je zasedeno največje dovoljeno število mest. V nadaljevanju bomo opisali razvoj modula za organizacijo iger med naključnimi nasprotniki ali prijatelji z uporabo PUN na primeru igre Fluffy Rush Vzpostavitev igre med naključnimi nasprotniki V glavnem meniju igre Fluffy Rush lahko igralci s klikom na gumb»quick Race«začnejo z iskanjem naključnih nasprotnikov, ki v danem trenutku prav tako iščejo soigralce. Potek organizacije igre med naključnimi igralci prikazuje diagram na sliki 4.5, kjer začetni dogodek predstavlja klik na omenjeni gumb. Slika 4.5: Diagram poteka organizacije igre med naključnimi igralci. 35

47 Ob kliku na gumb»quick Race«program odjemalca od strežnika najprej zahteva seznam vidnih sob. Če v pridobljenem seznamu ni nobene odprte sobe, odjemalec strežniku pošlje ukaz za kreacijo nove. Če seznam že vsebuje odprto sobo, se odjemalec vanjo poskusi povezati. Pri povezavi v obstoječo igro lahko pride do zapletov, kot sta zaprtje sobe med povezovanjem ali sočasna pridružitev več kot štirih igralcev v isto igro. Če je povezava neuspešna, odjemalec prav tako od strežnika zahteva vzpostavitev nove sobe, v katero sam takoj vstopi in začne čakati na ostale igralce. Implementacija opisanega postopka organizacije iger med naključnimi igralci je z uporabo PUN relativno preprosta. V igri Fluffy Rush za to nalogo skrbi skripta»organizatornakljucnihiger.cs«, odsek katere je prikazan na Sliki 4.6. Slika 4.6: Implementacija organizacije iger med naključnimi igralci. Glavne funkcije orodja PUN so dostopne z uporabo razreda PhotonNetwork. Tako se v funkciji Start ob začetku igre odjemalec s klicem ConnectUsingSettings poveže na strežnik z danimi nastavitvami, v tem primeru nizom»v1.0«, kar strežniku ob povezavi sporoča različico programa oziroma igre, ki teče na odjemalcu. S klicem JoinLobby igralec vstopi v predprostor, kjer sta omogočena pridruževanje in vzpostavitev sob. Ob kliku na gumb»quick Race«iz zunanje skripte gumba kličemo funkcijo PridruziSeNakljucniSobi, znotraj katere opravimo klic vgrajene metode JoinRandomRoom, s katero se odjemalec poskuša 36

48 pridružiti naključni odprti sobi. Če povezava ni uspela ali trenutno ni odprta nobena soba, se izvede povratni klic (callback) OnPhotoRandomJoinFailed, kjer kličemo vgrajeno metodo CreateRoom, ki je odgovorna za kreacijo nove sobe z danimi lastnostmi. Z argumenti ob klicu določimo ime nove sobe, odprtost in vidnost ter največje dovoljeno število članov sobe. Ime sobe smo tako sestavili iz niza»room_«in imena igralca, s čimer smo se izognili podvajanju imen sob. Prav tako smo z argumenti novo sobo naredili vidno in odprto ter nastavili zgornjo mejo dovoljenih članov s številom štiri. Če je ob klicu JoinRandomRoom povezava v obstoječo sobo uspešna, se izvede povratni klic funkcije OnJoinedRoom, kjer je igralec preusmerjen v čakalnico in kasneje v igro z dodeljenimi nasprotniki Vzpostavitev igre med prijatelji Mnoge večigralske igre poleg tekmovanja med naključnimi igralci omogočajo tudi igro s prijatelji. Vzpostavitev takšne igre v primeru obravnavanega projekta temelji na dveh sistemih: Sistem za upravljanje s prijatelji (friend management system) v okviru igre lahko igralci na svoj seznam prijateljev dodajo druge igralce. Omogočena je tudi povezava z obstoječimi prijatelji družbenega omrežja Facebook. Sistem povabil (invitation system) uporabnikom je omogočeno pošiljanje in prejemanje povabil v zasebno igro s strani igralcev, ki so na njihovem seznamu prijateljev. Povabila je možno prejeti s pomočjo pojavnega okna znotraj igre ali v obliki potisnega sporočila, kadar prejemnik povabila ni aktivno prisoten v igri. V igri Fluffy Rush je s pomočjo namenskega okna omogočena organizacija zasebne igre med prijatelji (Slika 4.7). Seznam na desni strani okna vsebuje vse prijatelje organizatorja igre, zelene pike ob imenih pa označujejo tiste, ki so trenutno aktivni v igri. S klikom na gumb»+«lahko organizator pošlje povabila aktivnim in tudi neaktivnim igralcem. Ko se igralci pridružijo, organizator s klikom na gumb»start«začne igro. 37

49 Slika 4.7: Okno za organizacijo igre med prijatelji v igri Fluffy Rush. Kot smo omenili na začetku poglavja, organizacija zasebne igre med prijatelji poteka z uporabo nevidnih sob, v katere lahko vstopajo samo uporabniki, ki poznajo identifikacijsko oznako oziroma ime sobe. To oznako lahko prejmejo v obliki povabila s strani organizatorja igre, ki je lastnik sobe. Diagram na Sliki 4.8 prikazuje potek organizacije igre med prijatelji. Slika 4.8: Diagram poteka organizacije igre med prijatelji. 38

50 V našem projektu za opisani potek vzpostavitve igre med prijatelji skrbita dve skripti. Ena je namenjena organizaciji igre in pošiljanju povabil, druga pa prejemanju povabil ter povezavi v sobo. Slika 4.9 prikazuje odsek programske kode za organizacijo prijateljske igre»organizatorprijateljskeigre.cs«, ki jo izvaja program gostujočega igralca. Slika 4.9: Implementacija gostovanja igre med prijatelji. Ob naloženi sceni za gostovanje prijateljske igre se izvede metoda Start, kjer kličemo funkcijo UstvariNovoSobo(). Tukaj najprej generiramo naključno štirimestno število, ki ga nato skupaj z nizom»room_«in imenom gostujočega igralca uporabimo za tvorbo imena nove sobe. Naključno število služi kot varnostni mehanizem oziroma geslo za vstop v sobo. S klicem funkcije CreateRoom v sedemnajsti vrstici strežniku ukažemo vzpostavitev nove sobe. S prvim argumentom sobo poimenujemo, z drugim in tretjim pa določimo, da je soba nevidna, a odprta, kar pomeni, da se lahko vanjo pridružijo igralci, ki poznajo ime sobe. Zadnji argument predstavlja največje dovoljeno število članov sobe. 39

51 Ko organizator vzpostavi sobo, lahko v igro povabi druge igralce. Za pošiljanje povabil skrbi funkcija PosljiPovabilo, ki kot argument prejme identifikacijo oziroma ime povabljenega prijatelja. S pomočjo razreda InvitationController in funkcije sendinvitation danemu igralcu pošljemo povabilo, ki vsebuje ime gostujočega ter identifikacijsko oznako sobe, kar igralcu omogoča povezavo v zasebno igro. Ob povezavi povabljenega igralca v igro se s povratnim klicem izvede vgrajena funkcija OnPhotonPlayerConnected s podatki o ravnokar povezanem igralcu. V tej funkciji znižamo število prostih mest v igri in v primeru popolne zasedenosti sobo zapremo, kar pomeni, da se vanjo ne more povezati več nihče in je pripravljena na začetek igre. Drugi del implementacije organizacije prijateljske igre predstavlja skripta»upravljalnikpovabil.cs«, ki je odgovorna za sprejemanje povabil in priključitev povabljenega igralca v sobo (Slika 4.10). Slika 4.10: Odsek programske kode, odgovorne za sprejemanje povabil in povezovanje v zasebno sobo. Ob prejemu povabila v prijateljsko igro se v skripti UpravljalnikPovabil samodejno kliče funkcija OnInvitationReceived z informacijo o pošiljatelju povabila in identifikacijsko oznako sobe. Tukaj se s klicem InvitationMessageBox.Show igralcu prikaže povabilo v obliki pojavnega okna z gumboma za sprejem ali zavrnitev. V primeru sprejema povabila se kliče metoda SprejmiPovabilo, znotraj katere se s klicem PhotonNetwork.JoinRoom igralec poveže v zasebno sobo s prej prejeto identifikacijsko oznako. 40

52 4.4 Sinhronizacija položajev igralcev Enega pomembnejših delov povezanih večigralskih iger predstavlja sinhronizacija položajev igralcev med igro. Končni cilj je gladka, usklajena in pravična igra za vse igralce, za dosego tega cilja pa morajo biti položaji nasprotnikov ter stanje igre vsem udeležencem prikazani enako in ob istem času. Zaradi dinamike obravnavane igre Fluffy Rush se igralni objekti gibljejo z veliko hitrostjo, smeri gibanja pa se neprestano spreminjajo glede na vhodne kontrole igralcev. Ob implementaciji usklajevanja položajev igralcev morajo razvijalci pri razvoju dinamičnih večigralskih iger upoštevati dva pomembna dejavnika: Zakasnitev (latency) vsak igralec med igro s pošiljanjem paketov podatkov preko strežnika sporoča svoj položaj nasprotnikom. Vsak paket potrebuje določen čas, da prispe od pošiljatelja do prejemnika, čas potovanja paketa (network travel) pa je omejen s hitrostjo povezave. Zaradi zakasnitve prihoda paketa z informacijo o lokaciji pošiljatelja je prejemniku tako vedno znana nekoliko zastarela lokacija nasprotnika, medtem ko se je njegov dejanski položaj že spremenil. Tako prejemnik v nobenem trenutku ne pozna dejanske lokacije nasprotnika, kar lahko povzroči težave pri zagotavljanju pravične igre (na primer: igralcema je prikazan različen razplet igre). Frekvenca pošiljanja posodobitev položaja v dinamičnih igrah se spremembe položaja igralca prikazujejo med 30- in 60-krat na sekundo. Zaradi omejitve omrežja igralec svojega položaja ne more vedno pošiljati tako pogosto, kar pomeni, da prejemnik v sekundi prejme manj položajev nasprotnika, kot jih lahko prikaže. Posledica tega je na pogled nezvezno pomikanje nasprotnika, saj ta ob vsaki spremembi položaja obstane na mestu, dokler prejemnik ne prejme podatka o novem položaju. Takšno vedenje objektov deluje nenaravno, zato je za privlačen igralni način nujno treba zagotoviti kar se da gladke prehode med znanimi prejetimi položaji nasprotnika. Za soočenje z navedenimi izzivi smo ob razvoju projekta Fluffy Rush uporabili že uveljavljene metode. V nadaljevanju bomo s pomočjo diagramov opisali, kako omenjena dejavnika vplivata na prikaz igralnih objektov pred uporabo rešitev in po njej. 41

53 Ob opisu naslednjih primerov predpostavljamo, da komunikacija teče med dvema igralcema v igri, to sta igralec A in igralec B. Označeni karakter na vseh slikah predstavlja objekt, nadzorovan s strani igralca A, ki svojo lokacijo pošilja igralcu B. Območje, označeno z modro, prikazuje dejanski položaj objekta skozi čas, kot ga vidi igralec A, rdeče obarvano območje pa prikazuje položaj istega objekta, kot ga vidi igralec B. Obravnavamo pošiljanje podatkov o gibanju objekta ob skoku karakterja na mestu v vertikalni smeri. Ob omenjenem dogodku se objektu skozi čas torej spreminja le vrednost koordinate Y. Predpostavljamo pošiljanje paketov z informacijami o položaju igralca petnajstkrat na sekundo. Slika 4.11 prikazuje vpliv zakasnitve in frekvence pošiljanja na prikaz položaja karakterja z vidika igralca A in prejemnika igralca B. Slika 4.11: Vpliv zakasnitve in frekvence pošiljanja na prikaz položaja karakterja igralca A z vidika obeh igralcev (prirejeno po [1]). Na Sliki 4.11 je z modro obarvan prikaz dejanskega položaja igralca A. Opazimo, da je ob začetku skoka vrednost koordinate Y enaka ena, nato enakomerno narašča do najvišje točke skoka, do vrednosti deset, nato pa s padcem objekta začne padati tudi vrednost Y. Igralec A igralcu B prvo posodobitev svojega položaja pošlje takoj na začetku, ta pa za pot 42

54 do prejemnika potrebuje petdeset milisekund. Igralec B posodobi prikaz položaja karakterja glede na prejeto vrednost. V tem primeru vrednost Y ostane enaka, kot je bila pri predhodnem položaju. Igralec A naslednjo posodobitev pošlje čez približno sedemdeset milisekund. V tem času se je dejanska vrednost njegovega položaja spremenila že štirikrat, tako je poslana vrednost Y v trenutku druge posodobitve že enaka pet. V stosedemnajsti milisekundi paket z informacijo o posodobljenem položaju doseže igralca B. V tem trenutku igralec B posodobi vrednost Y z ena na pet in v tem stanju čaka na naslednjo posodobitev igralca A. Ta prispe v stotriinosemdeseti milisekundi, ko je vrednost koordinate Y enaka devet. Opazimo, da se prikaza položaja istega objekta s pogleda igralca A in igralca B razlikujeta na dva načina. Prva je razlika v zveznosti vrednosti Y. Dejanski položaj igralca A se tako v opazovanem času posodobi dvanajstkrat, medtem ko igralec B skupno prejme le tri posodobitve položajev. Posledica tega je nenaravno in nezvezno pomikanje objekta s pogleda igralca B, kar se odraža v slabi uporabniški izkušnji. Neskladje položajev s pogledov obeh igralcev opazimo tudi ob pogledu na časovno premico. Zaradi časa potovanja paketov in frekvence pošiljanja igralec B prejema nekoliko zastarele položaje igralca A in jih zato prikazuje z zamikom. Tako na primer igralec A dejansko doseže vrednosti Y devet v stopetdeseti milisekundi, igralec B pa ga na isti točki vidi šele trideset milisekund za tem. Zakasnitve so v praksi pogosto daljše kot v opisanem primeru. V nadaljevanju bomo opisali dve rešitvi opisanih težav, ki smo ju uporabili ob razvoju igre Fluffy Rush Interpolacija položajev igralcev Nenaravno gibanje in preskakovanje objektov zaradi omejene frekvence pošiljanja paketov lahko omilimo s pomočjo interpolacije položajev na strani prejemnika. Z uporabo interpolacije ob sprejemu vsakega novega položaja objekta ne prestavimo v trenutku na novo pozicijo, ampak ga v določenem času postopno pomikamo s trenutnega do novega prejetega položaja. Čas, v katerem gladko pomikamo objekt med dvema znanima položajema, imenujemo interpolacijska doba (interpolation period), čas med odposlanima paketoma pa doba paketa (packet period). Z uporabo interpolacije tako zagotovimo gladek prikaz pomikanja objekta, a interpolacijska doba poveča zakasnitev prikaza natančnega 43

55 prejetega položaja, saj določen čas porabimo za gladek prehod med trenutnim in novo prejetim položajem [1]. Slika 4.12 ponovno prikazuje pošiljanje položaja igralca A igralcu B. Tokrat igralec B v času med prejetimi paketi izvaja interpolacijo položaja objekta. Ob časovnih trenutkih prikaza pomikanja objekta na strani igralca B smo zapisali prejeto vrednost Y, ki jo igralec pozna, in interpolirano vrednost Y, ki jo trenutno prikazuje. Slika 4.12: Položaji objekta z vidikov obeh igralcev ob interpolaciji na strani igralca B (prirejeno po [1]). Opazimo, da igralec B informacijo o prvi dejanski spremembi položaja objekta prejme v stosedemnajsti sekundi, ko se vrednost poznane koordinate Y spremeni z ena na pet. Namesto takojšnjega prikaza premika objekta na novo znano pozicijo ga v dobi interpolacije postopno pomikamo od trenutne do nove znane vrednosti, torej koordinato Y skozi čas postopno povečujemo od ena do pet. Pomembno je zagotoviti, da sta seštevek dobe paketa in časa potovanja paketa ter doba interpolacije čim bolj podobna, saj želimo, da se gladek prehod med dvema položajema konča ravno, ko že prispe paket z novim znanim položajem [1]. Tako lahko v vsakem trenutku zagotovimo gladko pomikanje 44

56 objekta. Usklajevanje trajanja dobe interpolacije z dobo paketa predstavlja ločen izziv, saj je čas potovanja paketa nepredvidljiv in odvisen od omejitev omrežja. Tako je ob implementaciji treba opravljati meritve časa potovanja paketa in jih upoštevati pri sprotni nastavitvi dobe interpolacije. Na Sliki 4.12 opazimo tudi, da se dejanski skok objekta na strani igralca A v vertikalni smeri začne že takoj ob začetku opazovanja, s pogleda igralca B pa objekt začne s pridobivanjem višine šele v stosedemnajsti milisekundi. Igralec A tako še vedno prikazuje zastarele položaje objekta, torej težav, povzročenih zaradi zakasnitve z interpolacijo, še nismo odpravili. V nadaljevanju bomo opisali metodo, ki je namenjena omilitvi omenjenih težav Dead reckoning Ob sinhronizaciji položajev so igralcem zaradi zakasnitve vedno znane nekoliko zastarele informacije o položaju nasprotnikov. Če želimo zagotoviti bolj natančno časovno uskladitev položajev s pogleda vseh igralcev, moramo oceniti, kje objekti dejansko so. Ker prejemnik pozna dobo paketa in čas potovanja paketa, ob prejemu paketa izve natančen položaj objekta, na katerem je objekt bil pred znanim časom. Če želi izvedeti, kam se je objekt dejansko pomaknil v času od zadnjega prejetega paketa do zdaj, mora predvideti trenutni položaj objekta glede na predhodno gibanje. Postopek predvidevanja položaja na podlagi vedenja, hitrosti, pospeška in smeri objekta imenujemo Dead reckoning. V omrežnih igrah omenjena metoda predvidevanja položajev objektov temelji na predpostavki, da bo objekt nadaljeval z istim vedenjem, kot ga je kazal v zadnjem znanem stanju. Če je objekt v fazi premikanja, predpostavljamo, da se bo premikal v isti smeri z isto hitrostjo, če je v fazi ustavljanja, predpostavljamo, da bo z ustavljanjem nadaljeval. Ob predvidevanju položajev upoštevamo tudi lokalne omejitve s strani logike in fizike igre, tako se na primer izognemo nenaravnim premikom objekta skozi zid ali izven vidnega polja [1]. Z uporabo metode Dead reckoning tako omilimo učinek zakasnitve, saj namesto čakanja na nov znani položaj s predvidevanjem objekt premikamo že vnaprej, ob vsakem novem prejetem realnem položaju pa trenutni ocenjeni položaj le popravimo. Velikost popravka je odvisna od uspešnosti predvidevanja. Ker je objekt nadzorovan s strani nasprotnika, obstaja možnost, da sta se smer in hitrost objekta znatno spremenili od 45

57 nazadnje znanega stanja. Slika 4.13 prikazuje položaje enakega objekta, kot jih vidita igralec A in igralec B. Igralec A tako prikazuje dejanske položaje objekta, igralec B pa položaje, kot jih vnaprej predvideva z uporabo metode Dead reckoning. Slika 4.13: Napaka ob predvidevanju položaja z uporabo metode Dead reckoning (prirejeno po [1]). Na sliki spremljamo položaje in hitrosti istega objekta, prikazane s strani igralca A in igralca B. Položaji so opisani s parom koordinat X in Y, hitrosti pomikanja objekta pa prav tako z dvema vrednostma, kjer prva predstavlja hitrost pomikanja v horizontalni, druga pa v vertikalni smeri. V primeru predpostavljamo, da oba igralca ob začetku opazovanja poznata trenutni položaj in hitrost objekta. Začetni položaj je na koordinatah (0,0), hitrost, s katero se pomika, pa je ena enota na tisočinko sekunde v smeri X. Zgornja polovica diagrama predstavlja dejansko pomikanje opazovanega objekta skozi čas. Tako se objekt od začetka opazovanja do šestdesete milisekunde pomika v horizontalni smeri. Pot v tej smeri nadaljuje še nadaljnjih petnajst milisekund, nato pa ob 46

58 vhodni kontroli igralca A spremeni smer. Do stodvajsete milisekunde se tako pomika v vertikalni smeri vse do položaja (75,45). Predpostavljamo, da igralec A pošilja svoje položaje igralcu B v intervalu šestdeset milisekund, vsak paket pa za pot potrebuje petnajst milisekund. Tako igralec A svoj položaj pošlje prvič takoj na začetku, drugič v šestdeseti milisekundi in tretjič v stodvajseti milisekundi. Spodnja polovica diagrama predstavlja položaje istega objekta, kot jih z metodo Dead reckoning predvideva igralec B. Vrednosti, zapisane s črno, predstavljajo položaje in hitrosti, ki jih igralec B v danem trenutku predvideva ter prikazuje, vrednosti, zapisane z modro, pa informacijo o položajih, ki jih je poslal igralec A. Prvi položaj, ki ga igralec B prejme v petnajsti milisekundi, je položaj (0,0). Ker igralec B pozna čas potovanja paketa, ve, da je to bila aktualna pozicija pred petnajstimi milisekundami, ker je že poznal začetno hitrost objekta, pa lahko potrdi, da je trenutno na pravem položaju. Pomikanje zato nadaljuje v smeri X z nespremenjeno hitrostjo vse do dvainosemdesete milisekunde, ko prejme posodobitev položaja objekta s strani igralca A. Tokrat je prejeti položaj na koordinatah (60,0). Sprememba med obema nazadnje prejetima položajema se ujema s predvidevano hitrostjo in smerjo pomikanja, zato igralec B nadaljuje s prikazovanjem pomikanja objekta v smeri X z nespremenjeno hitrostjo vse do stopetintridesete milisekunde, ko prejme novo posodobitev položaja s strani igralca A. Nov položaj je opisan s koordinatami (75, 45), kar pomeni, da je med zadnjima znanima položajema objekt spremenil smer, ko se je ob položaju (75,0) začel pomikati navzgor v vertikalni smeri. Metoda Dead reckoning je do te točke uspešno opravljala svojo nalogo predvidevanja položajev, a te spremembe smeri ni mogla predvideti, saj jo je povzročila vhodna kontrola igralca A, zato so bile od tiste točke naprej predvidene vrednosti s strani igralca B napačne. Točka, obarvana z zeleno, prikazuje položaj, kamor je treba premakniti objekt, da bo njegov položaj usklajen z dejanskim. Opisana metoda na podlagi predvidevanja hitrosti in smeri časovno dobro sinhronizira položaj objekta s pogleda obeh igralcev, ko pa pride do primera nenadne spremembe smeri med prejetima posodobitvama, pa nastopi omenjeno odstopanje. V tem trenutku moramo izvesti popravek, torej posodobiti položaj objekta in ga vrniti na pravo pot. 47

59 Popravek položaja lahko izvedemo na tri glavne načine [1]: Takojšnja posodobitev stanja (instant state update) s tem načinom takoj, ko prepoznamo odstopanje, objekt v trenutku prestavimo na pravi položaj. Posledica takšnega popravka položaja je hiter preskok objekta, kar je lahko med igranjem igre moteče. Pri uporabi tega načina se je treba odločiti, ali je v danem trenutku bolj pomemben gladek potek igre ali natančen položaj objekta. Interpolacija (interpolation) objekt lahko med odstopajočim in pravilnim položajem postopoma pomikamo s pomočjo interpolacije, kot je opisano v prejšnjem poglavju, po interpolaciji položajev pa nadaljujemo s predvidevanjem na podlagi naslednjega prejetega položaja. Posodobitev stanja drugega reda (second-order state adjustment) s tem pristopom popravek položaja izvedemo s prilagajanjem parametrov, kot je na primer pospešek objekta in ga tako skozi čas postopoma vračamo na pravo pot. Takšen pristop je lahko z vidika razvoja kompleksen, a pogosto problem popravkov položajev rešuje na najmanj moteč način. Ob razvoju igre Fluffy Rush smo s kombinacijo metode Dead reckoning in interpolacije dosegli zadovoljivo stopnjo natančnosti sinhronizacije položajev objektov v igri. Za usklajene in gladke premike objektov smo poleg omenjenih razvili tudi nekaj podpornih metod, ki rešujejo sinhronizacijske težave, specifične za naš projekt (na primer uskladitev starta in povečana natančnost sinhronizacije ob koncu dirke). Po zagotovljeni uskladitvi položajev igralcev smo morali poskrbeti tudi za sinhronizirano proženje dogodkov v igri s strani igralcev. Pristop k razvoju tega dela bomo opisali v nadaljevanju. 4.5 Sinhronizacija akcij igralcev Poleg časovne uskladitve položajev igralcev je v večigralskih povezanih igrah treba zagotoviti tudi sinhronizacijo akcij igralcev in z njimi povezano proženje dogodkov. Med igro igralci prožijo dogodke, ki so pomembni le za lokalni prikaz igre, pa tudi dogodke, ki vplivajo na potek igre nasprotnikov. Med slednje spadajo na primer izstrelitev naboja, trk igralca ob oviro, proženje animacij avatarja, pošiljanje sporočila v klepetalnico in drugi. 48

60 Za implementacijo proženja tovrstnih dogodkov uporabljamo klice oddaljenih procedur oziroma klice RPC (Remote Procedure Call), s pomočjo katerih lahko posamezni igralec pokliče metodo, ki se izvede lokalno in tudi na strani njegovih nasprotnikov [5]. V igri Fluffy Rush je eden izmed mnogih dogodkov, ki zahtevajo sinhronizacijo, izstrelitev rakete proti nasprotniku. Ko igralec izstreli raketo, želimo ta dogodek sprožiti in ga prikazati tudi na strani vseh nasprotnikov. Igralec A lahko tako s klicem RPC proženje tega dogodka izvede hkrati na svoji strani in na strani igralca B. Časovni zamik proženja dogodka na strani igralca B zaradi zakasnitve rešujemo glede na naravo dogodka. V primeru izstrelitve rakete lahko podobno kot v prejšnjem poglavju položaj rakete predvidevamo glede na hitrost in smer objekta, samega začetnega trenutka izstrelitve pa ni mogoče predvideti, saj je v celoti odvisen od odločitve igralca. Slika 4.14 prikazuje odsek programske kode za klic RPC z uporabo orodja Photon Unity Networking. Slika 4.14: Klic metode RPC za izstrelitev rakete. Ko igralec s klikom na gumb v igri ukaže izstrelitev rakete, kličemo metodo UkaziIzstrelitevRakete, ki kot argumenta prejme začetni položaj rakete v obliki para koordinat in začetno hitrost rakete v smeri X ter Y. Znotraj te funkcije s pomočjo komponente PhotonView izvedemo klic RPC. Ob klicu najprej navedemo ime metode, ki jo želimo izvesti na strani nasprotnikov, v našem primeru je to»izstreliraketo«. Kot drugi argument navedemo prejemnike, ki bodo izvedli izbrano metodo. Z izrazom PhotonTargets.All določimo, da se bo metoda izvedla tako lokalno kot tudi na strani vseh ostalih igralcev. Nazadnje kot argumenta podamo tudi začetni položaj in hitrost rakete. Do zdaj opisan del kode se izvede samo na strani igralca, ki je sprožil dogodek. Po klicu RPC se na strani vseh igralcev izvede funkcija IzstreliRaketo, kot je ukazal pošiljatelj akcije. Omenjena funkcija je označena z izrazom»[rpc]«kar pomeni, da jo je možno priklicati strani drugih igralcev z oddaljenim klicem. Znotraj te funkcije izvedemo kodo, ki raketo dejansko izriše na zaslonu in začne pomikanje v dani smeri. 49

61 5. SHRANJEVANJE PODATKOV Pomemben vidik razvoja večigralskih mobilnih iger predstavlja implementacija shranjevanja podatkov. Hraniti je treba podatke o identiteti igralcev, napredku v igri, stanju interne ekonomije, prijateljskih povezavah in uporabniških nastavitvah. Podatke lahko shranjujemo dva načina: Lokalno shranjevanje podatke hranimo na napravi, na kateri je igra nameščena. V okolju Unity je takšno shranjevanje omogočeno z uporabo razreda PlayerPrefs, ki temelji na hrambi podatkov v namenski datoteki v obliki slovarja (dictionary), kjer ima vsak vnos določen tip (type), ključ (key) in vrednost (value). S funkcijami razreda PlayerPrefs so tako omogočeni pisanje, branje in brisanje podatkovnih vnosov z danim ključem. Drugi način lokalnega shranjevanja je možno izvesti z uporabo vključkov, ki poskrbijo za vzpostavitev in delo z lokalno bazo SQL Lite. Ob tej izvedbi podatke urejamo s standardnimi poizvedbami SQL. Mnogo preprostih enoigralskih iger uporablja le lokalno shranjevanje podatkov. Slabosti tega načina so šibka zaščita pred goljufanjem in izbris vseh podatkov v primeru, da uporabnik igro izbriše ali menja mobilno napravo, kar se odraža v slabi uporabniški izkušnji. Shranjevanje na strežniku podatke hranimo v podatkovni bazi na spletnem strežniku. Z uporabo tega pristopa lahko zagotovimo zanesljivo shranjevanje podatkov o igri, ki so vezani na uporabniški račun, ki ga igralec ustvari ob prvem zagonu igre. Tako se lahko v primeru ponovne namestitve ali menjave naprave uporabnik preprosto vpiše s svojim računom in prenese vse hranjene podatke ter nadaljuje z igro. Poleg shranjevanja podatkov o igri posameznih uporabnikov lahko podatkovno bazo na strežniku uporabimo tudi za vodenje globalnih lestvic najboljših, shranjevanje prijateljskih povezav in povabil v igro. Poleg omenjenih prednosti ta način lastnikom igre omogoča pregled in analizo podatkov, na podlagi katerih lahko igro optimizirajo. Shranjevanje podatkov na strežniku pa spremljajo tudi izzivi. Pojavi se potreba po gostovanju strežnika, razvoju modulov za nalaganje in prenos podatkov ter zagotavljanju zaščite in varnosti podatkov. Omenjene naloge podaljšajo čas dela in povečajo stroške razvoja ter vzdrževanja končnega produkta. Ob razvoju igre Fluffy Rush smo uporabili kombinacijo obeh omenjenih načinov. Manj relevantne podatke, kot je na primer nastavitev jakosti zvoka, shranjujemo lokalno na 50

62 napravi, medtem ko pomembnejše podatke, kot so račun uporabnika, količina cekinov, nakupi znotraj igre in napredek igre, shranjujemo na strežnik. Zaradi želje po čim manjši obremenitvi strežnika vseh relevantnih podatkov ne pošiljamo na strežnik ob vsaki spremembi vrednosti, ampak jih začasno hranimo lokalno. Spremenjene vrednosti tako zapišemo na strežnik v določenih časovnih intervalih ali ob vnaprej definiranih dogodkih. V podatkovni bazi shranjujemo tudi podatke, povezane z lestvicami najboljših igralcev, prijateljskimi povezavami in povabili v igro. Omenjene funkcionalnosti lahko implementiramo v celoti z lastnim razvojem odjemalčevega in strežniškega programa ali z uporabo vključkov ter storitev, ki integracijo teh funkcij olajšajo. Takšen tip storitev imenujemo»game backend as a service«. 4.6 Game backend as a service Game backend as a service (Game BaaS) predstavlja način za povezavo med igro in storitvami za shranjevanje ter obdelavo podatkov v oblaku. Vključevanje omenjenih storitev je podprto s programskimi vmesniki (API), ki so združljivi z različnimi platformami. V našem primeru smo iskali rešitve, kompatibilne z orodjem Unity in operacijskimi sistemi Android ter ios. Poznamo vrsto ponudnikov tovrstnih storitev, kot so PlayFab, GameSparks, Kii, App42 in drugi. Slika 5.1 prikazuje diagram povezave med igro in storitvami Game BaaS [17]. Slika 0.1: Povezava med igro in storitvami»game backend as a service«(prirejeno po [17]). 51