rok pov se razvoj iger za ios diplomsko delokeywords: ios, iphone, ipad, ipod touch, game...

Rok Povse

RAZVOJ IGER ZA iOS

Diplomsko delo

Maribor, april 2011

DIPLOMSKO DELO UNIVERZITETNEGA STUDIJSKEGA

PROGRAMA

RAZVOJ IGER ZA iOS

Student: Rok Povse

Studijski program: univerzitetni, Racunalnistvo in informatika

Smer: Informatika

Mentor: izr. prof. dr. Ales Zivkovic

Somentor: doc. dr. Peter Peer

Maribor, april 2011

ZAHVALA

Zahvaljujem se mentorju izr. prof.

dr. Alesu Zivkovicu in somentorju

doc. dr. Petru Peeru za pomoc in

vodenje pri opravljanju diplomskega

dela.

Zahvala je namenjena tudi druzini in

punci Daliji za podporo in spodbudo

v casu solanja.

Stran vii

Razvoj iger za iOS

Kljucne besede: iOS, iPhone, iPod Touch, iPad, razvoj iger, OpenGL, UIKit, Core

Graphics, Core Animation, cocos2d, zasnova iger

UDK: (659.2:004):004.92(043.2)

PovzetekDiplomsko delo predstavlja kljucne znacilnosti in omejitve platforme iOS ter navaja razlicne

poslovne modele za trzenje mobilnih aplikacij. Predstavljene so kljucne tehnologije za delo z

zvokom in graficnim vmesnikom, pri cemer je podrobneje predstavljen odprtokodni pogon za

igre, cocos2d za iPhone. Navedene so najboljse prakse in nacini za optimizacijo pri razvoju

iger za platformo iOS. Zadnji del diplomskega dela obsega implementacijo prakticne resitve,

igre Traffic Master. Igra je implementirana v skladu s stopnjami, katerim moramo slediti pri

razvoju iger in izkorisca tehnologije predstavljene v diplomskem delu.

Stran vii

Stran viii

Stran viii

Stran ix

iOS game development

keywords: iOS, iPhone, iPad, iPod Touch, game development, OpenGL, UIKit,

Core Graphics, Core Animation, cocos2d, game design

UDK: (659.2:004):004.92(043.2)

AbstractIn this diploma thesis our aim is to present key features and limitations of the iOS platform

and different available business models for mobile applications. A variety of key technologies

used for developing audio and graphics interface are described, including a more detailed pre-

sentation of an open source game engine cocos2d for iPhone. Furthermore, the best practices

and possible optimizations for iOS games development have also been discussed. The last part

of the diploma thesis describes the development of a game called Traffic Master. The game

takes advantage of the technologies presented in the thesis and is developed in accordance with

the game design and development stages.

Stran ix

Stran x

Stran x

KAZALO Stran xi

Kazalo

1 Uvod 1

2 Operacijski sistem iOS 3

2.1 Naprave zdruzljive z iOS . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Sloji tehnologij . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3 Xcode in iOS SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.4 Druge mobilne platforme . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.5 Omejitve pri razvoju . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Poslovni modeli aplikacij za iOS 12

3.1 Trznica mobilnih aplikacij App Store . . . . . . . . . . . . . . . . . . . 12

3.2 Placljive aplikacije . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3 Lahke aplikacije . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.4 Oglasevanje v igrah . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.5 Nakup znotraj igre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.6 Navade uporabnikov naprav iOS . . . . . . . . . . . . . . . . . . . . . . 21

4 Ogrodja za graficni vmesnik v iOS 24

4.1 Ogrodje UIKit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2 Ogrodje Core Graphics . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.3 Knjiznica Core Animation . . . . . . . . . . . . . . . . . . . . . . . . . 25

KAZALO Stran xi

Stran xii KAZALO

4.4 Programski vmesnik OpenGL ES . . . . . . . . . . . . . . . . . . . . . 30

4.5 Platforma Adobe Flash . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.6 Izbira tehnologije . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5 Ogrodja za avdio v iOS 36

5.1 Ogrodja Core Audio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.2 Kodiranje zvoka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.3 Tipi datotek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.4 Izbira standarda za kodiranje in tipa datoteke . . . . . . . . . . . . . . 41

5.5 Programski vmesnik OpenAL . . . . . . . . . . . . . . . . . . . . . . . 41

6 cocos2d za iPhone 43

6.1 Integracija ogrodja z Xcode . . . . . . . . . . . . . . . . . . . . . . . . 44

6.2 Kljucni gradniki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.3 Slikovni formati za teksture . . . . . . . . . . . . . . . . . . . . . . . . 55

6.4 Pogona za fiziko Box2D in Chipmunk . . . . . . . . . . . . . . . . . . . 57

7 Optimizacija in najboljse prakse 59

7.1 Najboljse prakse za cocos2d . . . . . . . . . . . . . . . . . . . . . . . . 59

7.2 Optimizacija delovanja pogona za fiziko Box2D . . . . . . . . . . . . . 61

7.3 Optimizacija na nivoju prevajalnika . . . . . . . . . . . . . . . . . . . . 62

7.4 Orodje Instruments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

8 Igra Traffic Master 64

8.1 Stopnje razvoja iger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

8.2 Konceptualizacija . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

8.3 Prototipiranje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

8.4 Dokument zasnove igre . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Stran xii KAZALO

KAZALO Stran xiii

8.5 Model razvoja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

8.6 Prva iteracija implementacije . . . . . . . . . . . . . . . . . . . . . . . 70

8.7 Druga iteracija implementacije . . . . . . . . . . . . . . . . . . . . . . . 79

8.8 Tretja iteracija implementacije . . . . . . . . . . . . . . . . . . . . . . . 84

8.9 Objava igre v trznici AppStore . . . . . . . . . . . . . . . . . . . . . . . 87

9 Sklep 89

Literatura 91

KAZALO Stran xiii

Stran xiv SLIKE

Slike

2.1 Sloji tehnologij v iOS. . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.1 Razlicni nacini sodelovanja med oglasevalcem in razvijalcem [29]. . . . . 14

3.2 Razporeditev aplikacij glede na trajanje uporabe [29]. . . . . . . . . . . 16

3.3 Nivo vkljucenosti oglasa v okolje igre [30]. . . . . . . . . . . . . . . . . 16

3.4 Brezplacna razlicica igre Angry Birds z oglasi izven okolja igre. . . . . . 17

3.5 Igra Baseball Superstars integrira oglase v okolje igre. . . . . . . . . . . 18

3.6 Oglasni igri korporacije Coca-Cola. . . . . . . . . . . . . . . . . . . . . 19

3.7 Nakup produkta Mighty Eagle v igri Angry Birds. . . . . . . . . . . . . 21

3.8 Dinamika uporabe aplikacij za torke in sobote [40]. . . . . . . . . . . . 23

4.1 Preddefinirane funkcije casovnega poteka. . . . . . . . . . . . . . . . . . 28

4.2 Dva nacina projiciranja geometrijskih objektov v prostoru na projekcij-

sko ravnino v OpenGL ES. . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.3 Podprti nacini obravnave vozlisc v OpenGL ES. . . . . . . . . . . . . . 32

5.1 Ogrodja in paketi za delo z zvokom na platformi iOS [43, 44]. . . . . . 37

6.1 StickWars, ena izmed najbolje prodajanih iger. . . . . . . . . . . . . . . 44

6.2 Kreiranje novega projekta cocos2d v okolju Xcode. . . . . . . . . . . . 45

6.3 Uporabniski vmesnik programa Hiero. . . . . . . . . . . . . . . . . . . . 48

6.4 Posebne funkcije spreminjanja casovnega poteka v cocos2d [73]. . . . . 52

Stran xiv SLIKE

SLIKE Stran xv

6.5 Ucinek CCRipple3D. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.6 Uporabniski vmesnik programa ParticleDesigner. . . . . . . . . . . . . 55

6.7 Vmesnik igre Paper Bridge za iOS, ki uporablja pogon za fiziko Box2D. 58

8.1 Graficna predstavitev stopenj razvoja iger [83]. . . . . . . . . . . . . . . 65

8.2 Preprost programski prototip igre Traffic Master. . . . . . . . . . . . . 67

8.3 Iterativen proces testiranja igralnosti, ovrednotenja testiranja in vnasanja

popravkov [83]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

8.4 Razredni diagram sloja za avtomobile in poti. . . . . . . . . . . . . . . 72

8.5 Simulacija ognja s sistemom delcev. . . . . . . . . . . . . . . . . . . . . 78

8.6 Igra ob koncu prve iteracije. . . . . . . . . . . . . . . . . . . . . . . . . 79

8.7 Puscica, ki pomaga usmeriti avtomobil v izvoz. . . . . . . . . . . . . . 79

8.8 Igra z urejenim izrisom krivulj. . . . . . . . . . . . . . . . . . . . . . . 80

8.9 Opozorilo pred trkom. . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

8.10 Funkcija, ki glede na pretecen cas igranja doloca frekvenco kreiranja

avtomobilov. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

8.11 Vmesnik igre ob zakljucku igre. . . . . . . . . . . . . . . . . . . . . . . 86

8.12 Scena za prikaz najboljsih igralcev. . . . . . . . . . . . . . . . . . . . . 87

SLIKE Stran xv

Stran xvi TABELE

Tabele

2.1 Pregled kljucnih znacilnosti naprav iPhone. . . . . . . . . . . . . . . . 4

2.2 Trzni delezi mobilnih naprav glede na operacijski sistem [7]. . . . . . . 7

2.3 Cas delovanja naprave pri razlicnih frekvencah izrisovanja v urah in mi-

nutah [21]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

6.1 Primerjava kljucnih lastnosti ogrodij izpeljanih iz ogrodja cocos2d. . . . 44

6.2 Cas v sekundah, ki je potreben za nalaganje tekstur razlicnih slikovnih

formatov na razlicnih napravah iOS [73]. . . . . . . . . . . . . . . . . . 57

6.3 Priblizno stevilo slicic na sekundo, ki jih dosega sistem delcev z razlicnim

tipom in velikostjo teksture [73]. . . . . . . . . . . . . . . . . . . . . . . 57

8.1 Preprost dokument zasnove igre. . . . . . . . . . . . . . . . . . . . . . . 68

Stran xvi TABELE

IZVORNA KODA Stran xvii

Izvorna koda

4.1 Primer implicitne animacije. . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2 Primer eksplicitne animacije. . . . . . . . . . . . . . . . . . . . . . . . . 29

4.3 Primer animiranja z razrednimi metodami razreda UIView za iOS 4.0. . 30

4.4 Ukazi za geometrijske transformacije nad vozlisci. . . . . . . . . . . . . 32

6.1 Najenostavnejsi nacin kreiranja primerka CCSprite. . . . . . . . . . . . 48

6.2 Primer uporabe razreda CCSpriteBatchNode. . . . . . . . . . . . . . . 49

6.3 Osnovni primer animacije s cocos2d. . . . . . . . . . . . . . . . . . . . 50

6.4 Primer sestavljene animacije. . . . . . . . . . . . . . . . . . . . . . . . . 51

6.5 Primer uporabe CCCallFunc razreda. . . . . . . . . . . . . . . . . . . . 53

7.1 Definicija parametra kot konstante za dodatne optimizacije. . . . . . . 63

8.1 Dolocanje zacetne scene igre. . . . . . . . . . . . . . . . . . . . . . . . . 71

8.2 Kreiranje gumbov glavnega menija. . . . . . . . . . . . . . . . . . . . . 71

8.3 Prehod na sceno igre s posebnim ucinkom. . . . . . . . . . . . . . . . . 71

8.4 Postopek dodajanja novih tock za pot avtomobila. . . . . . . . . . . . . 73

8.5 Postopek iskanja parametra krivulje za zahtevan premik avtomobila. . . 74

8.6 Ustvarjanje telesa za zelene povrsine. . . . . . . . . . . . . . . . . . . . 75

8.7 Dodajanje novih delov zelenih povrsin. . . . . . . . . . . . . . . . . . . 76

8.8 Nacin dostopa do teles in tocke trka iz objekta b2Contact. . . . . . . . 76

8.9 Sistem delcev za simulacijo ognja. . . . . . . . . . . . . . . . . . . . . . 77

IZVORNA KODA Stran xvii

Stran xviii IZVORNA KODA

8.10 Ukaza za dolocitev barve in debeline crte. . . . . . . . . . . . . . . . . 80

8.11 Preprost nacin predvajanja ponavljajocega zvoka. . . . . . . . . . . . . 81

8.12 Struktura za opis stanja avtomobila. . . . . . . . . . . . . . . . . . . . 82

8.13 Postopek shranjevanja opisan s strukturo v jeziku C. . . . . . . . . . . 83

8.14 Postopek nalaganja shranjenih podatkov o stanju igre. . . . . . . . . . 83

8.15 Shranjevanje dosezenih tock na streznik cocoslive. . . . . . . . . . . . . 86

8.16 Zahtevek za prenos seznama dosezkov igralcev s streznika cocoslive. . . 87

Stran xviii IZVORNA KODA

UPORABLJENE KRATICE Stran xix

Uporabljene kratice

MB – Megabyte

GB – Gigabyte

ARM – Advanced RISC Machine

RISC – Reduced Instruction Set Computing

GPU – Graphics Processing Unit

GPS – Global Positioning System

IDE – Integrated Development Environment

ADT – Android Development Tools

API – Application Programming Interface

SDK – Software Development Kit

.NET CF – .NET Compact Framework

HVGA – Half-size Video Graphics Array

MVC – Model View Controller

FPS – Frames per Second

CAD – Computer-Aided Design

SWF – Shockwave Flash

CPM – Cost per Thousand Impressions

PCM – Pulse Code Modulation

MP3 – MPEG-1, Audio Layer 3

UPORABLJENE KRATICE Stran xix

Stran xx UPORABLJENE KRATICE

MPEG – Moving Picture Experts Group

AAC – Advanced Audio Coding

ALAC – Apple Lossless Audio Codec

ADPCM – Adaptive Differential Pulse Code Modulation

AMR – Adaptive Multi-Rate

GSM – Global System for Mobile Communications

UMTS – Universal Mobile Telecommunications System

iLBC – Internet Low Bitrate Codec

CPE – Centralna procesna enota

AIFF – Audio Interchange File Format

WAV – Waveform Audio File Format

JPEG – Joint Photographic Experts Group

PNG – Portable Network Graphics

PVRTC – PowerVR Texture Compression

XML – Extensible Markup Language

URL – Uniform Resource Locator

Stran xx UPORABLJENE KRATICE

Stran 1

Poglavje 1

Uvod

V danasnjih casih je na voljo mnozica naprav, ki omogocajo igranje racunalniskih

iger. Med njimi, poleg igralnih konzol in osebnih racunalnikov, najdemo se prenosne

igralne konzole, tablicne racunalnike in mobilne naprave. Slednje so danes vedno bolj

pomembne, saj gre v prvi meri za naprave, ki nas spremljajo na vsakem koraku. Poleg

tega v njih vgrajujejo vedno bolj zmogljivo strojno opremo in s tem omogocajo izvajanje

naprednejsih aplikacij. Med omenjene mobilne naprave uvrscamo tudi naprave iOS.

Poleg tega, da so dovolj zmogljive za poganjanje iger, imajo se to prednost, da se

aplikacije na njih namescajo s pomocjo trznice za aplikacije, imenovane AppStore. Ta

razvijalcem mocno poenostavlja delo pri ponujanju aplikacij, uporabnikom pa zagotovi

centralizirano mesto za dostop, placilo in prenos aplikacij.

Namen diplomskega dela je predstavitev poslovnih modelov mobilnih aplikacij, tehnolo-

gij, ki jih lahko uporabimo pri razvoju iger za iOS, omejitev platforme iOS in najboljse

prakse za razvoj ter postopke za optimizacijo delovanja iger. Razen tega bomo preucili

se stopnje razvoja igre in v skladu z njimi implementirali igro Traffic Master za iOS.

Diplomsko delo je sestavljeno iz osmih poglavij. Drugo poglavje je namenjeno predsta-

vitvi platforme iOS. V njem bomo spoznali naprave, katerim je platforma namenjena,

primerjali trzne deleze s konkurencnimi platformami, predstavili potrebna razvojna

orodja za platformo iOS ter podali omejitve, ki jih je potrebno upostevati pri razvoju

za platformo iOS. Ker je podjetje Apple s platformo iOS predstavilo nov nacin trzenja

mobilnih aplikacij, bomo v tretjem poglavju predstavili poslovne modele za aplika-

cije iOS. Poleg le-teh bomo predstavili se navade uporabnikov naprav iOS, kar lahko

upostevamo pri izbiri poslovnega modela. Pri razvoju iger za iOS se je potrebno se-

znaniti tudi s tehnologijami, ki so na voljo pri razvoju. V ta namen bomo v cetrtem

Stran 1

Stran 2 POGLAVJE 1. UVOD

poglavju pregledali tehnologije, ki so potrebne za izdelavo graficnega uporabniska vme-

snika. Ob koncu poglavja bomo podali se smernice pri izbiri ustrezne tehnologije. Ker

je, poleg graficnega vmesnika, zvok zelo pomembna komponenta vsake igre, bomo v

petem poglavju pregledali, katera ogrodja in formate datotek ponuja podjetje Apple

za delo z zvokom. Pri razvoju iger mnogokrat uporabimo katerega izmed ze obstojecih

pogonov za igre, zato bomo v sestem poglavju podrobneje predstavili lastnosti in nacin

uporabe pogona cocos2d za iPhone, ki je namenjen platformi iOS. V sedmem poglavju

bomo predstavili razlicne dobre prakse in nacine za optimizacijo delovanja igre, s ka-

terimi si pomagamo pri skrbnem ravnanju z omejenimi viri in pri zagotavljanju dobro

delujocih iger za razlicne naprave iOS. Zadnje, osmo poglavje, bo namenjeno predsta-

vitvi razvoja igre Traffic Master. Sprva bomo pregledali stopnje razvoja iger, katerim

je potrebno slediti, nato pa implementirali omenjeno resitev.

Stran 2 POGLAVJE 1. UVOD

Stran 3

Poglavje 2

Operacijski sistem iOS

iOS je mobilni operacijski sistem, ki ga proizvaja podjetje Apple. Gre za izpeljanko

operacijskega sistema Mac OS X in se po naravi obnasa podobno kot operacijski sis-

temi Unix (angl. Unix-like). V primerjavi z operacijskim sistemom Mac OS X je precej

tehnologij enakih, nekatere pa so kljub vsemu na voljo samo v iOS. Taksni tehnologiji

sta na primer zaslon obcutljiv na dotik, ki zazna vec hkratnih dotikov in merilec po-

speskov. Prvotno je bil operacijski sistem razvit za napravo iPhone in se je imenoval

iPhone OS. Ob izidu cetrte razlicice so ga preimenovali v iOS [1, 2].

2.1 Naprave zdruzljive z iOS

Operacijski sistem iOS je namenjen napravam iPhone, iPod Touch in iPad. Naprava

iPhone je pametni telefon, ki poleg funkcionalnosti mobilnega telefona vsebuje se pred-

vajalnik avdia in videa, spletni brskalnik, Wi-Fi in Bluetooth povezljivost ter omogoca

nalaganje aplikacij. Vse naprave iPhone, razen tistih iz prve generacije, vsebujejo se

sprejemnik GPS. Tabela 2.1 prikazuje kljucne specifikacije vseh stirih generacij naprav

iPhone.

Stran 3

Stran 4 POGLAVJE 2. OPERACIJSKI SISTEM IOS

iPhone iPhone 3G iPhone 3GS iPhone 4

Procesor 412MHz Samsung RISC ARM 600MHz

Samsung

RISC ARM

800MHz

Apple A4

RISC ARM

Graficni procesor PowerVR MBX Lite 3D GPU PowerVR SGX535 GPU

Delovni pomnilnik 128 MB DRAM 256 MB

DRAM

512 MB

DRAM

Zunanji pomnilnik 4, 8, 16 GB 8, 16 GB 8, 16, 32 GB 16, 32 GB

Operacijski sistem iPhone 3.1.3 iOS 4.2.1 iOS 4.3 in no-

vejsi

iOS 4.3 in no-

vejsi

Locljivost 480×320 960×640

Tabela 2.1: Pregled kljucnih znacilnosti naprav iPhone.

Naprava iPod Touch je multimedijski predvajalnik, ki uporablja enako strojno plat-

formo kot naprava iPhone. Naprava iPhone ima v primerjavi z napravo iPod Touch

se nekatere dodatne lastnosti, kot sta dostop do mobilnih omrezij in sprejemnik GPS.

Posledicno je naprava iPhone v primerjavi z napravo iPod Touch vecjih dimenzij.

Tako kot obstajajo stiri generacije naprav iPhone, obstajajo tudi stiri generacije naprav

iPod Touch. Ce omenjene kljucne specifikacije naprav iPhone primerjamo z napravami

iPod Touch po generacijah, lahko identificiramo naslednje razlike: naprave iPod Touch

ponujajo razlicice z vec zunanjega pomnilnika, iPod Touch druge generacije ima hitrejsi

procesor, iPod Touch cetrte generacije pa ima polovico manj delovnega pomnilnika.

Naprava iPad je tablicni racunalnik, ki ima glavni in graficni procesor enak kot naprava

iPhone 4, zaslon locljivosti 1024×768, 256 MB delovnega pomnilnika in 16, 32 ali 64

GB zunanjega pomnilnika [3].

2.2 Sloji tehnologij

Jedro operacijskega sistema iOS temelji na razlicici jedra, imenovanega Mach, ki ga naj-

demo tudi v operacijskem sistemu Mac OS X. Nad jedrom se nahajajo sloji tehnologij

(slika 2.1), s pomocjo katerih implementiramo aplikacijo.


2.3. XCODE IN IOS SDK Stran 5

Slika 2.1: Sloji tehnologij v iOS.

Najnizji plasti Core OS in Core Services vsebujeta temeljne vmesnike operacijskega

sistema. Ti vmesniki vecinoma temeljijo na programskem jeziku C in vkljucujejo teh-

nologije, kot so Core Foundation, CFNetwork, SQLite, vmesniki za delo z nitmi, itd.

Na visjih nivojih najdemo naprednejse tehnologije, katerih vmesniki mesano temeljijo

na programskem jeziku C in Objective-C. Sloj Media tako vsebuje na jeziku C teme-

ljece tehnologije OpenGL ES, Quartz in Core Audio. Med drugim vkljucuje tudi na

programskem jeziku Objective-C temeljec pogon za animacije, imenovan Core Anima-

tion. Na najvisjem, sloju Cocoa Touch, vecina tehnologij uporablja Objective-C. Na

primer, Foundation Framework nam omogoca objektno-orientirano delo z zbirkami,

upravljanje z datotekami, delo z omrezjem, itd. Sloj Cocoa Touch med drugim vsebuje

tudi ogrodje UIKit, s katerim gradimo in upravljamo uporabniski vmesnik.

Vsako novo aplikacijo pricnemo graditi z uporabo najvisjega sloja Cocoa Touch, na-

tancneje z ogrodjem UIKit. Priporoceno je, da po ogrodju na nizji plasti posezemo

samo v primeru, ce zelimo specificno obnasanje, ki ga ne moremo doseci z uporabo

ogrodij na visji plasti [2].

2.3 Xcode in iOS SDK

Za razvoj aplikacij iOS je potrebno na racunalnik z operacijskim sistemom Mac OS X

namestiti razvojno okolje Xcode in iOS SDK. Po koncani namestitvi imamo na

voljo popoln nabor orodij za razvoj aplikacij iOS. Glavna orodja za razvoj le-teh so

integrirano razvojno okolje Xcode, Interface Builder, iOS Simulator in Instruments.

Poleg omenjenih programov se namestijo se ogrodja za razvoj aplikacij, namenjenih

operacijskemu sistemu iOS [4].

2.3. XCODE IN IOS SDK Stran 5


Razvojno okolje Xcode

Xcode je integrirano razvojno okolje (IDE), s katerim ustvarjamo in upravljamo iOS

projekte, izvorne datoteke, prevajamo izvorno kodo in jo testiramo. Za vsako aplikacijo

moramo ustvariti nov projekt, ki shranjuje vse informacije povezane z aplikacijo, na

primer izvorne datoteke in nastavitve za prevajalnik.

Xcode vsebuje napredni tekstovni urejevalnik, ki prepozna sintakso programskega

jezika. Podpira se zacasno skrivanje blokov kode, prikaz opozoril in napak ter

integracijo z razhroscevalnikom.

Orodje Interface Builder

Interface Builder je orodje, s katerim poenostavimo gradnjo uporabniskega vmesnika

aplikacije. Tega zgradimo tako, da na okno, ki predstavlja uporabniski vmesnik

aplikacije, povlecemo posamicne komponente, kot so gumbi in tekstovna vnosna polja.

Dodanim komponentam lahko dolocimo razlicne atribute in nacin povezovanja z

izvorno kodo [5].

iOS Simulator

iOS Simulator simulira razlicne naprave za iOS in tako omogoci testiranje aplikacij za

iOS na racunalniku, kjer jih razvijamo, ne da bi racunalnik povezali s fizicno napravo

za iOS. Zmogljivost aplikacije, ki se izvaja na fizicni napravi iOS, se lahko razlikuje

od tiste, ki jo poganjamo v iOS Simulatorju. Zato je priporocljivo, da aplikacije

testiramo tudi na fizicni napravi. Poleg razlik v zmogljivosti ima iOS Simulator se

druge omejitve. V simulatorju, na primer, ni mogoce testirati aplikacij, ki izkoriscajo

vgrajeno video kamero, uporabljajo podatke o pospesku ali lokaciji naprave [6].

Okolje Instruments

Okolje Instruments je zbirka posebnih orodij za analizo zmogljivosti aplikacije.

Omogoca zbiranje in prikaz razlicnih podatkov o aplikaciji, kot sta poraba pomnil-

nika in obremenjenost procesorja [5].


2.4. DRUGE MOBILNE PLATFORME Stran 7

2.4 Druge mobilne platforme

V letu 2010 so naprave iOS predstavljale 15,7 odstotka vseh prodanih pametnih

telefonov. Tabela 2.2 prikazuje podatke o prodajnem delezu naprav glede na namescen

operacijski sistem za zadnja 4 leta [7]. V nadaljevanju bomo podali nekaj kljucnih

informacij za vsakega izmed omenjenih operacijskih sistemov.

Leto Symbian Android RIM iOS Microsoft Ostali2010 37,6% 22,7% 16,0% 15,7% 4,2% 3,8%2009 46,9% 3,9% 19,9% 14,4% 8,7% 6,1%2008 52,4% 0,5% 16,6% 8,2% 11,8% 10,5%2007 63,5% /% 9,6% 2,7% 12,0% 12,1%

Tabela 2.2: Trzni delezi mobilnih naprav glede na operacijski sistem [7].

Platforma Android

Android je brezplacna, odprtokodna, na operacijskem sistemu Linux temeljeca mobilna

platforma. Ta je v lasti zdruzenja Handset Alliance, ki zdruzuje 65 tehnologij in znanih

podjetij iz razlicnih podrocij. Med njimi najdemo podjetja Google, Intel, Nvidia, Nec

in Vodafone.

Za razvoj aplikacij Android je potrebno namestiti Android SDK, ki vkljucuje ustre-

zna orodja in knjiznice za razvoj aplikacij v programskem jeziku Java. Android SDK

ne vsebuje integriranega razvojnega okolja, zato obicajno namestimo se integrirano

razvojno okolje Eclipse in vticnik, imenovan ADT (Android Development Tools).

Pri razvoju strojno pospesenih iger lahko uporabimo OpenGL ES API [8, 9], vendar

moramo pri tem upostevati, da Android tece na napravah razlicnih proizvajalcev, ki v

naprave vgrajujejo razlicno zmogljivo strojno opremo. Poleg le-te se naprave Android

razlikujejo se v razlicici namescenega operacijskega sistema, ki je lahko se dodatno pri-

lagojen dolocenemu proizvajalcu ali mobilnemu operaterju. Razvijalci ugotavljajo, da

je edini nacin, da ugotovimo, ali aplikacija deluje dovolj dobro na dolocenih napravah,

da jo na teh napravah tudi testiramo. Ker je trenutno naprodaj precej razlicnih naprav

Android, predstavlja strosek nakupa le-teh precejsen problem za manjse razvijalce [10].

Operacijski sistem Symbian

Operacijski sistem Symbian je bil nalozen na kar 63,5 odstotka vseh naprav, ki so bile

2.4. DRUGE MOBILNE PLATFORME Stran 7


prodane v letu 2007. Trzni delez naprav z operacijskim sistemom Symbian je nato

vsako leto nekoliko upadel in je v letu 2010 znasal samo se 37,6 odstotka [7].

V zacetku leta 2011 je podjetje Nokia, ki je tudi lastnik operacijskega sistema Symbian,

spremenilo poslovno strategijo in se povezalo s podjetjem Microsoft. Novi pametni

telefoni tako ne bi temeljili na operacijskem sistemu Symbian, temvec na Windows

Phone [11].

Windows Mobile in Windows Phone

Windows Mobile je zaprtokodni mobilni operacijski sistem, ki temelji na operacijskem

sistemu Windows CE. Razvoj strojno pospesenih iger je podprt s pomocjo Direct3D

in DirectDraw nativnih knjiznic ter Direct3D .NET, ki je na voljo kot del ogrodja

.NET Compact Framework (.NET CF) za naprave z novejsim operacijskim sistemom

Windows Mobile [12]. Trzni delez naprav, z operacijskim sistemom Windows Mobile,

je v letu 2010 znasal samo se 4,2 odstotka [7].

Windows Phone je naslednik operacijskega sistema Windows Mobile. V primerjavi

s predhodnikom ima nov graficni uporabniski vmesnik, ki ga oblikujemo s pomocjo

novega jezika, imenovanega Metro, podprti razvojni platformi pa sta, namesto .NET

CF, XNA in Silverlight [13].

Operacijski sistem BlackBerry

Operacijski sistem BlackBerry, proizvajalca Research in Motion, je v osnovi namenjen

poslovni rabi. Na severnoameriskem trgu ima zavidljiv 55% trzni delez [14].

Programska podpora za OpenGL ES 1.0, ki omogoca gradnjo strojno pospesenih iger,

je na voljo sele od pete razlicice operacijskega sistema dalje in ga trenutno podpira

samo pet naprav BlackBerry [15].

2.5 Omejitve pri razvoju

Pri razvoju za platformo iOS se srecamo z dolocenimi omejitvami. Nekatere izmed teh

so skupne vsem mobilnim platformam, druge pa so specificne za platformo iOS.


2.5. OMEJITVE PRI RAZVOJU Stran 9

Okna in vecopravilnost

Za razliko od obicajnih operacijskih sistemov za osebne racunalnike, kjer programi

upravljajo in odpirajo vec oken hkrati, imamo v iOS na voljo eno samo okno nespre-

menljive velikosti, znotraj katerega poteka vsa interakcija z uporabnikom.

Poganjanje vec aplikacij hkrati je v iOS podprto od razlicice 4.0 dalje in omogoceno

samo novejsim napravam. iPhone 3G je primer naprave, ki ne omogoca poganjanja

vec aplikacij hkrati. Kljub podpori operacijskega sistema za poganjanje vec aplikacij

hkrati je razvijalec sam odgovoren za to, da zagotovi pravilno obnasanje razlicnih

stanj aplikacije in prehode med njimi. Eden taksnih prehodov je, ko aplikacija preide

iz izvajanja v ospredju v izvajanje v ozadju. Pri izvajanju aplikacij v ozadju moramo

uporabo dolocenih virov, kot je zvok, vnaprej napovedati. V primeru, da tega ne

storimo, se bo predvajanje zvoka ustavilo, ko bo aplikacija presla v ozadje. Pri

izvajanju v ozadju je potrebno upostevati se druga priporocila in omejitve. Primer

taksne omejitve je, da ne smemo izvesti nobenega klica OpenGL ES, saj se bo v

nasprotnem primeru izvajanje aplikacije nemudoma zakljucilo [16, 17].

Omejen dostop

iOS omejuje, kje v datotecnem sistemu se lahko aplikacija skupaj s podatki in nasta-

vitvami nahaja. Ta omejitev je del varnostnih lastnosti, imenovanih sandbox aplika-

cije. Sandbox podrobno doloca omejitve aplikacije pri dostopu do datotek, nastavitev,

omrezja, strojne opreme, itd. Sandbox zasciti aplikacijo pred skodo, ki bi jo lahko

povzrocile druge aplikacije, ne more pa je zascititi pred neposrednimi napadi. Primer

taksnega napada je prekoracitev medpomnilnika (angl. buffer overflow) [17].

Kljub strogim omejitvam uporabniki ugotavljajo, da je dostop do dolocenih datotek

in zbirk se vedno mogoc. Na primer, omejitve, da aplikacije ne morejo uporabljati

skupnega prostora, so dodali sele v razlicici iPhone OS 2.1. Tehnicno gledano sicer

lahko dostopamo do dolocenih obcutljivih delov sistema, a je smiselnost taksnega

pocetja vprasljiva. Podjetje Apple objavo taksnih aplikacij v trznici za mobilne

aplikacije App Store, praviloma zavrne [18].

Omejen odzivni cas

Aplikacije za iOS morajo biti dobro odzivne. Glavno okno aplikacije mora postati

vidno v nekaj sekundah po tem, ko smo aplikacijo zagnali.



Kadar se izvajanje aplikacije prekine, moramo v petih sekundah shraniti stanje aplika-

cije, da ga lahko kasneje obnovimo. Izvajanje aplikacije na napravi, kjer vecopravilnost

ni podprta, se prekine vedno, ko s pritiskom fizicne tipke zapustimo aplikacijo oziroma

izvajanje prekine zunanji dogodek, na primer telefonski klic. Pri napravi, ki podpira

vecopravilnost, se izvajanje prekine v primeru pomanjkanja pomnilnika [16, 17].

Locljivost in velikost zaslona

Naprave iPhone in iPod Touch prvih treh generacij imajo vgrajene zaslone z locljivostjo

HVGA (320×480). V primerjavi z zaslonom za namizni racunalnik, locljivosti

1680×1050, ima namizni vec kot 11 krat toliko tock kot HVGA zaslon. V napra-

vah iPhone in iPod Touch cetrte generacije je vgrajen zaslon z locljivostjo 960×640.

Kljub visoki locljivosti naprav zadnje generacije, so vsi zasloni omenjenih naprav enakih

dimenzij, pri cemer je diagonala zaslona 89mm. Aplikacija mora biti zasnovana tako,

da bo, kljub majhnosti zaslona, udobna za uporabo. Zaradi razlicne locljivosti zaslona

bomo morali v dolocenih primerih graficne elemente, ki smo jih izdelali, pripraviti v

razlicnih locljivostih, ce bomo zeleli ohraniti enako velikost objektov.

Zaslon naprave iPad ima diagonalo 243mm in locljivost 768×1024 [3]. Visja locljivost

zaslona iPad lahko predstavlja tezavo za poganjanje obstojecih aplikacij, ki so obicajno

prilagojene locljivosti 480×320. Podjetje Apple je taksnim aplikacijam zagotovilo dva

nacina kompatibilnosti. Prvi nacin je poganjanje aplikacij v originalni locljivosti, kjer

je aplikacija centrirana na sredino zaslona. Zaslon je tako precej neizkoriscen, zato je

podprto se raztezanje aplikacije cez celoten zaslon. Slabost tega je, da zaradi raztezanja

izgubimo kvaliteto grafike [19].

Podjetje Apple je med drugim ponudilo navodila, kako pristopiti h gradnji univer-

zalnih aplikacij za iOS. Osnova ideje je ta, da namesto celotnih aplikacij za vsako

napravo pripravimo zgolj specificen uporabniski vmesnik, ki jih je nato zaradi uporabe

nacrtovalskega vzorca MVC enostavno uporabiti [20].

Poraba energije

Na mobilnih napravah je poraba energije pomemben faktor, saj so naprave odvisne od

omejenega baterijskega vira energije. Ene izmed najzahtevnejsih tipov aplikacij, ki zelo

obremenijo strojno opremo in posledicno izpraznijo baterijo, so prav igre. Tabela 2.3

prikazuje cas delovanja naprav iPhone 3GS in iPod Touch 1. generacije, pri igranju igre



Armageddon Wars, pri razlicnih frekvencah izrisovanja (FPS) v urah in minutah [6, 21].

60 FPS 33 FPS 25 FPS 1 FPS

iPhone 3GS 3:25 4:15 5:19 8:45

iPod Touch 1. generacije / 2:29 3:05 3:51

Tabela 2.3: Cas delovanja naprave pri razlicnih frekvencah izrisovanja v urah in minu-tah [21].

Omejeni sistemski viri

Cetrta generacija naprav iPhone ima vgrajenega 512 MB delovnega pomnilnika. Vse

stiri generacije naprav iPod Touch, naprava iPad in naprave iPhone prvih treh genera-

cij imajo vgrajenega 128 ali 256 MB delovnega pomnilnika. Del delovnega pomnilnika

potrebuje za delovanje sam operacijski sistem. V primeru, da imamo napravo s 128

MB delovnega pomnilnika, ga bo za aplikacije ostala manj kot polovica. Potrebno

je omeniti se, da iOS nima mehanizma podobnega navideznemu pomnilniku, ki ga

najdemo na modernejsih operacijskih sistemih. To pomeni, da je kolicina pomnilnika,

ki ga lahko uporablja aplikacija, omejena na kolicino neuporabljenega delovnega

pomnilnika naprave. V primeru, da je kolicina prostega pomnilnika premajhna, bo

aplikacija prejela opozorilo. Aplikacija mora v takem primeru sprostiti pomnilnik, ki

ga ne uporablja, saj lahko operacijski sistem v nasprotnem primeru prekine izvajanje

aplikacije [16, 3].

Omejitve pri razvoju v primerjavi z Mac OS X

Najbolj kljucne omejitve pri razvoju za platformo iOS, v primerjavi z razvojem za

platformo Mac OS X, so:

• Mehanizem imenovan garbage collection, ki sicer skrbi za sproscanje neuporablje-

nega pomnilnika, ni na voljo. Za sproscanje pomnilnika, ki ga zasedajo neupora-

bljeni objekti, smo dolzni poskrbeti sami.

• Nekatere knjiznice, ki so na voljo pri razvoju za operacijski sistem Mac OS X, so

pri razvoju za platformo iOS samo delno implementirane [6].


Stran 12 POGLAVJE 3. POSLOVNI MODELI APLIKACIJ ZA IOS

Poglavje 3

Poslovni modeli aplikacij za iOS

Trznice za mobilne aplikacije postajajo vedno pomembnejsi vir prihodkov, predvsem

na racun Applove trznice App Store, ki pa seveda ni edina za mobilne aplikacije.

Podjetje Microsoft ponuja resitev Windows Phone Marketplace, trznica za aplikacije

Android se imenuje Android Market, resitev podjetja Nokia pa se imenuje Ovi Store.

Raziskovalna hisa Gartner napoveduje, da se bodo prihodki trznic za mobilne aplikacije,

ki so leta 2010 dosegli 8,2 milijarde ameriskih dolarjev, v letu 2011 povisali na 15,1

milijarde dolarjev. Med drugim je Gartner mobilne tehnologije, ki so v letu 2010 bile

6. najpomembnejsa tehnologija, za leto 2011 uvrstil na 3. mesto najpomembnejsih

tehnologij, neposredno za tehnologiji racunalnistva v oblaku in virtualizacijo [22, 23].

V nadaljevanju bomo predstavili, na kaksne nacine lahko trzimo aplikacije iOS v trznici

za mobilne aplikacije App Store.

3.1 Trznica mobilnih aplikacij App Store

App Store je storitev namenjena napravam iOS, ki jo ponuja podjetje Apple. Uporab-

nikom omogoca prebiranje in prenos aplikacij iOS iz trgovine iTunes Store, kar lahko

storimo s pomocjo programa iTunes ali pa neposredno na napravi iOS, s pomocjo vgra-

jene aplikacije App Store. V zacetku leta 2011 je bilo uporabnikom na voljo skoraj 400

tisoc aplikacij, stevilo prenosov pa je preseglo 10 milijard.

Storitev App Store je edini podprti nacin namescanja aplikacij na naprave iOS, ne da bi

unicili garancijo naprave. Da lahko aplikacije objavimo v App Store, morajo biti le-te

izdelane v skladu s smernicami, ki jih doloca podjetje Apple [24]. Vsako aplikacijo, ki


3.2. PLACLJIVE APLIKACIJE Stran 13

jo zelimo objaviti, podjetje Apple pregleda glede na omenjene smernice, ki zdruzujejo

tehnicne, vsebinske in oblikovne kriterije. Aplikacija mora zadostiti tem kriterijem, da

se ji odobri objava v AppStore. Ceprav podjetje Apple trdi, da s taksnim pristopom

zagotavljajo zanesljive in delujoce aplikacije, brez zaljivih in neprimernih vsebin [25],

je bilo v preteklosti mnogokrat tarca kritik na racun subjektivnosti, pri odlocitvah o

zavrnitvi ali sprejetju dolocene aplikacije v App Store. Mnoge aplikacije so namrec

brez utemeljenih razlogov bile zavrnjene [26].

Aplikacije, ki jih nudimo v trgovini App Store, lahko ponudimo kot placljive ali kot

brezplacne. Ce avtor aplikacijo ponudi kot placljivo, mu pripada 70 odstotkov prihod-

kov od prodaje, preostalih 30 odstotkov pa pripada podjetju Apple [24]. V nadaljevanju

si bomo podrobneje pogledali poslovne modele, ki jih je mogoce uporabiti pri trzenju

aplikacij iOS.

3.2 Placljive aplikacije

Z aplikacijo, ki smo jo ponudili kot placljivo, bomo prihodek ustvarjali neposredno

s prodajo aplikacije. Preden lahko uporabnik aplikacijo prenese, mora zanjo odsteti

dolocen znesek, ki ga doloci ponudnik aplikacije.

Ceprav je delez placljivih aplikacij v App Store kar dvotretjinski, je potrebno preuciti,

ce je izbira taksnega modela res najboljsa [27].

Povprecna cena vseh aplikacij znasa 2,45 USD, medtem ko povprecna cena igre znasa

1,06 USD [28].

3.3 Lahke aplikacije

Lahke (angl. lite) aplikacije so aplikacije, ki nimajo vseh lastnosti polne placljive

razlicice, kar pa seveda ni nov koncept. Mnogo aplikacij za operacijski sistem Windows

ali Mac OS X se ponuja kot poskusna (angl. trial) ali demo razlicica. Taksne aplikacije

porabnikom omogocijo, da jo pred nakupom preizkusijo in se sele nato odlocijo ali jo

bodo kupili.

Aplikacija, ki nima vseh lastnosti polne razlicice, mora biti na voljo kot lahka razlicica,

ce jo zelimo ponuditi v App Store. Lahka razlicica se od poskusne ali demo razlicice

3.2. PLACLJIVE APLIKACIJE Stran 13


najbolj razlikuje v tem, da gre za v celoti delujoco aplikacijo, brez zaklenjenih moznosti.

Njena uporaba ne sme biti casovno omejena, hkrati pa med delovanjem ne sme na

motec nacin opozarjati uporabnika na nakup polne razlicice. Lahke aplikacije ne smejo

vsebovati napisov demo ali trial. Aplikacije, ki se omenjenih pravil ne drzijo, niso

sprejete v AppStore.

V primeru, da bomo poleg polne razlicice ponudili se lahko razlicico, ne smemo pozabiti

na dodatno delo, ki ga prinese razvoj, testiranje in vzdrzevanje lahke razlicice aplikacije.

Vecina razvijalcev poroca, da se delez uporabnikov, ki so se za nakup polne razlicice

odlocili po tem, ko so prenesli lahko razlicico, giblje med 0,5 odstotka in 3 odstotki.

Ceprav se ti odstotki zdijo majhni, je potrebno upostevati, da lahko najveckrat prene-

sene brezplacne aplikacije dosezejo vec milijonov prenosov [27].

3.4 Oglasevanje v igrah

Oglasevanje je zelo popularen nacin ustvarjanja prihodkov, ki omogoca, da igro

ponudimo brezplacno. Vloge v mobilnem oglasevanju lahko razdelimo na nacin, ki ga

prikazuje slika 3.1. Na eni strani se nahajajo znamke ali oglasevalci, ki zelijo oglasevati,

na drugi pa razvijalci, ki razvijejo igro za koncne uporabnike. Med njimi najdemo

oglasevalske agencije, ki za oglasevalce planirajo in kreirajo oglasevalske kampanje.

Ce ni neposrednega sodelovanja med agencijo in razvijalcem, poteka oglasevanje s

pomocjo oglasevalskih mrez. Te razvijalcem ponujajo ogrodja za enostaven prikaz

oglasov razlicnih oglasevalskih agencij. Za prikaz oglasov je mogoce uporabiti tudi

ogrodja, ki integrirajo oglase razlicnih oglasevalskih mrez.

Slika 3.1: Razlicni nacini sodelovanja med oglasevalcem in razvijalcem [29].

Glede na opisane moznosti oglasevanja za mobilne naprave, lahko nacin sodelovanja

med oglasevalcem in razvijalcem razdelimo v naslednje tri skupine:

• Sponzorstvo, ki zahteva neposredno dogovarjanje med razvijalci in oglasevalcem

ali oglasevalsko agencijo. Sponzorstvo zaloznikom omogoci boljse zasluzke,


3.4. OGLASEVANJE V IGRAH Stran 15

oglasevalcu pa boljso integracijo oglasa s samo igro. Taksen nacin sodelova-

nja zahteva vec napora zaradi neposrednih stikov z oglasevalcem, uporaben pa je

samo za igre, ki se dobro skladajo z oglasevano vsebino.

• Ekskluzivno oglasevalsko omrezje, ki nam ponuja ogrodje za enostavno integra-

cijo oglasov, katere ponuja oglasevalsko omrezje. Namenjeno je tako manjsim

kot vecjim razvijalcem. Zasluzek je praviloma visji pri vecjih razvijalcih, saj

si lahko izborijo boljse pogoje pri oglasevalski mrezi. Zelo pomembni lastno-

sti oglasevalskih mrez sta, da jih je enostavno integrirati, prihodek pa pricnemo

ustvarjati zelo hitro. Problem taksnih mrez je, da mnogokrat ne uspejo zapolniti

inventarja (angl. fill rate), ki ga imajo na voljo.

• Zdruzitev vec oglasevalskih omrezij, ki nam omogoca enostaven prikaz oglasov

razlicnih oglasevalskih omrezij. V primerjavi z uporabo ekskluzivne oglasevalske

mreze, dosegajo taksna ogrodja boljse stopnje zapolnitve inventarja, ki je na

voljo. Zaradi slabse kakovosti oglasov pa dosegajo nizji prihodek na tisoc prikazov

(CPM).

Ce zelimo ugotoviti, ali je ponujanje brezplacne igre z oglasi ustrezen model, si lahko

pomagamo z umestitvijo aplikacije v eno izmed skupin, kot jih prikazuje slika 3.2.

Aplikacije so razporejene glede na dve dimenziji, in sicer, kako dolgo je aplikacija v

uporabi po tem, ko smo jo prenesli, ter kako intenzivno bo v tem casu uporabljena.

Najprimernejse aplikacije za model z oglasevanjem so tiste, ki so dlje casa intenzivno

uporabljene [29].



Slika 3.2: Razporeditev aplikacij glede na trajanje uporabe [29].

Na oglase v igrah lahko gledamo se z vidika stopnje integracije oglasa z okoljem

igre. Slika 3.3 prikazuje razlicne stopnje integracije oglasa z igro, ki jih bomo tudi

podrobneje predstavili.

Slika 3.3: Nivo vkljucenosti oglasa v okolje igre [30].

Oglasi izven okolja igre

Oglase, ki niso vkljuceni v okolje, pogosto zasledimo pri igranju iger na spletu. Taksni

oglasi se pojavljajo v spletnem brskalniku neposredno okoli same igre. Pogosto so

prikazani kot video oglasi pred nalaganjem igre ali pa se prikazejo, ko smo igro uspesno



zakljucili. Podobne koncepte lahko uporabimo tudi v igrah, ki so namenjene platformi

iOS [30].

Ena izmed iger, ki izkorisca taksen nacin oglasevanja, je brezplacna razlicica igre

Angry Birds, ki uporablja storitev AdMob podjetja Google, kot je razvidno iz slike

3.4 [31]. Poleg storitve AdMob, je na voljo se veliko drugih ponudnikov, ki omogocajo

enostaven nacin integracije oglasov z igro. Med njimi najdemo tudi podjetje Apple

s storitvijo iAd, s katero so naredili korak dlje od preprostega odpiranja spletnega

brskalnika Safari, ob pritisku na oglas. Oglasi iAd so bolj interaktivni, odprejo se

znotraj aplikacije, obsegajo lahko vec strani, vsebujejo lahko video in zvok, dostavijo

lahko kupone, itd. [32]

Slika 3.4: Brezplacna razlicica igre Angry Birds z oglasi izven okolja igre.

Oglasi v okolju igre

Prikazovanju oglasov so namenjeni posebni prostori ali objekti znotraj okolja igre, ki

jih igralec vidi, interakcija z njimi pa ni mogoca. Oglas je lahko dvo-dimenzionalna

tabla, filmski plakat, procelje trgovine, itd. Lahko pa je tudi tri-dimenzionalen objekt,

kot na primer avtomobil, plocevinka pijace ali sportni pripomocek. Taksni oglasi so

lahko staticni, shranjeni v sami igri, lahko pa se tudi dinamicno spreminjajo s pomocjo

omrezne povezave. Ena taksnih iger je igra Baseball Superstars, ki integrira oglase v

okolje igre, kot prikazuje slika 3.5.



Slika 3.5: Igra Baseball Superstars integrira oglase v okolje igre.

Interaktivni oglasi v okolju igre

Interaktivni oglasi, ki so integrirani v okolje igre, prihajajo v raznih oblikah. Njihov

namen ni samo staticen prikaz dolocenega objekta ali slike, temvec omogocajo tudi

interakcijo z igralcem. Primer taksnega oglasa je, da lahko poleg izmisljenih mode-

lov avtomobilov v igri vozimo tudi model avtomobila, ki obstaja v resnici. V igrah

zasledimo predvsem naslednje tipe interaktivnih oglasov:

• Vecje vsebine, ki so pripravljene v povezavi z oglasevalcem in jih je mogoce pre-

nesti, na primer dodatne stopnje v igri.

• Manjse, v povezavi z oglasevalcem pripravljene vsebine, ki so vgrajene v igro ali

pa so placljive in na voljo s pomocjo mikrotransakcij. Primeri taksnih izdelkov

so kostumi, mobilni telefoni, avtomobili, itd.

• Sponzorstvo, kjer je vsebina in nacin prikaza oglasov v celoti odvisna od spon-

zorja.

Oglasne igre

Oglasne igre (angl. Adgames ali Advergames) so igre, ki so oblikovane v povezavi z

doloceno oglasevano vsebino, na primer storitvijo ali znamko, in so tako ze same po

sebi oglas. Taksne igre na spreten nacin zdruzujejo sporocila oglasevalca z zabavno,

interaktivno igralnisko izkusnjo. Elementi oglasevalca so integrirani v igro z namenom,

da zagotovijo edinstven izgled in funkcionalnost uporabniskega vmesnika, kar pogosto

zahteva razvoj popolnoma novega koncepta igre. Oglasne igre morajo nuditi jasno

povezavo med oglasevano vsebino in igro. Najboljse oglasne igre so razvite do te mere,

da bi odstranitev oglasevane vsebine negativno vplivala na igralnisko izkusnjo [30].


3.5. NAKUP ZNOTRAJ IGRE Stran 19

Primera taksnih iger, ki prihajata od mednarodne korporacije Coca-Cola, sta igri

Push! + Play in Sprite City. Sliki 3.6a in 3.6b prikazujeta vmesnika omenjenih

iger. Pri prvi igri si moramo v pravilnem zaporedju zapomniti vrstni red pritiskov

na zamaske. Druga igra pa je strateska, v njej moramo z avtomobili razvazati pijaco

Sprite in paziti, da ciljne lokacije ne ostanejo brez nje.

(a) Igra Push! + Play (b) Igra Sprite City

Slika 3.6: Oglasni igri korporacije Coca-Cola.

3.5 Nakup znotraj igre

Nakup virtualnih dobrin, novih stopenj iger, narocnine in druge oblike mikroplacil je

podjetje Apple podprlo v iPhone OS 3.0 in ga poimenovalo nakup znotraj aplikacije

(angl. In-App Purchase) [33]. Taksne nakupe podpremo z ogrodjem Store Kit. Placilo

produktov lahko ponudimo tako v brezplacnih kot v placljivih aplikacijah. Delitev

prihodkov od prodaje produktov je podobna kot pri placljivih aplikacijah; 70 odstotkov

prihodkov pripada ponudniku aplikacije, preostalih 30 odstotkov pa podjetju Apple

[27]. Ogrodja ne moremo uporabljati za nakup produktov iz resnicnega sveta. Vsi

produkti morajo biti dostavljeni v aplikacijo v digitalni obliki.

Ogrodje nudi podporo samo za placilo produktov, ne pa tudi za njihov prenos v apli-

kacijo. Zato locimo med dvema nacinoma dostave produkta uporabniku. Pri prvem,

enostavnejsem nacinu, so produkti, ki jih je mogoce kupiti, vgrajeni v aplikacijo. Ob

uspesnem nakupu aplikacija samo odklene produkt oziroma omogoci njegovo uporabo.

Pri drugem nacinu pa produktov ne shranjujemo v aplikaciji. V procesu nakupa in do-

stave izdelka pa poleg trznice App Store in aplikacije sodeluje se streznik, ki aplikaciji

3.5. NAKUP ZNOTRAJ IGRE Stran 19


na zahtevo zagotovi seznam produktov, ki jih je mozno kupiti. Ob zakljucku placila

zagotovi se preverjanje veljavnosti racuna v App Store ter dejanski prenos produkta v

aplikacijo.

Vsak produkt, ki ga bomo ponujali, je potrebno registrirati s pomocjo iTunes Connect,

kjer dolocimo ime, ceno, opis in druge podatke o produktu. Vsakemu produktu se

dodeli unikatni identifikator, s katerim se sklicujemo na produkt. Produkte, ki jih

smemo ponujati, lahko razdelimo v stiri skupine:

• Vsebine, ki obsegajo digitalizirane knjige, revije, fotografije, stopnje v igrah, like

v igri in druge produkte vsebinske narave.

• Funkcionalnosti, s katerimi omogocimo oziroma odklenemo dodatne funkcional-

nosti, kot je dostop do visje tezavnostne stopnje ali moznost shranjevanja.

• Storitve, ki omogocijo zaracunavanje storitev ob vsaki uporabi, na primer storitev

VoIP.

• Narocnine, s katerimi lahko uporabnik dlje casa dostopa do storitve ali vsebine.

Preverjanje, ce so narocnine potekle in mehanizem za podaljsanje narocnine,

moramo zagotoviti sami.

App Store omenjene tipe poenostavlja in produkte razdeli po trajnosti na:

• Porabljive, ki jih moramo kupiti vsakokrat, kadar jih zelimo uporabiti.

• Stalne, ki jih uporabniki placajo samo enkrat, nato pa so trajno na voljo.

Dolznost razvijalca je, da uporabniku zagotovi dostop do taksnih produktov na

vseh napravah, ki jih uporabnik uporablja.

• Narocnine, ki imajo lastnosti tako porabljivih kot stalnih produktov. Tako kot

porabljive produkte jih je mogoce kupiti veckrat, hkrati pa moramo zagotoviti

dostop do njih na vseh uporabnikovih napravah.

Za uporabnika je taksen nacin nakupa izdelka zelo prirocen, saj za nakup uporabi

svoj obstojeci iTunes racun, sam nakup pa je zelo enostaven. Uporabnik v igri izbere

izdelek, ki ga zeli kupiti, potrdi placilo in po potrebi vnese se geslo za svoj iTunes racun

[34, 35]. Sliki 3.7a in 3.7b prikazujeta primer nakupa v igri Angry Birds. Uporabnik,

ki ima tezave pri dokoncanju dolocene tezavnostne stopnje v igri, ima moznost, da z


3.6. NAVADE UPORABNIKOV NAPRAV IOS Stran 21

nakupom produkta Mighty Eagle enostavno unici vse nasprotnike in tako napreduje

v naslednjo tezavnostno stopnjo. Produkt Mighty Eagle lahko uporabimo veckrat,

vendar samo enkrat na uro [36].

(a) Odlocitev za nakup produkta (b) Potrditev nakupa

Slika 3.7: Nakup produkta Mighty Eagle v igri Angry Birds.

Ce produkte ponujamo na taksen nacin, da je za dostavo produkta potreben streznik,

si lahko pomagamo z nekaterimi obstojecimi resitvami, kot je storitev Urban Airship

[37]. Storitev se placuje po porabi, zato odpade tudi problem nakupa, vzdrzevanja,

varnosti in skalabilnosti strojne opreme [27].

3.6 Navade uporabnikov naprav iOS

Pri odlocanju o ustreznem poslovnem modelu si lahko pomagamo tudi s podatki o nava-

dah uporabnikov naprav iOS. Druzba Admob, ki ponuja resitve za mobilno oglasevanje

za razlicne platforme, analizira zahtevke za prikaz oglasov, rezultate pa predstavijo v

porocilu, ki ga objavijo na spletni strani.

Februarja 2010 so anketirali 963 uporabnikov naprav Android, iPhone, iPod Touch in

webOS1. Prisli so do naslednjih zanimivih ugotovitev:

• Povprecen cas uporabe aplikacij na napravah iPhone in Android je 1,3 ure dnevno.

• Uporabniki naprav iPod Touch kupijo povprecno 12 aplikacij mesecno, uporab-

niki naprav Android in iPhone 8 in uporabniki naprav webOS povprecno 6 apli-

kacij mesecno.

1Mobilni operacijski sistem razvit v podjetju Palm, trenutno v lasti podjetja HP.



• Povprecen uporabnik naprave iPod Touch prenese 37% vec brezplacnih aplikacij

kot uporabniki naprav iPhone in Android.

• iPhone uporabniki prenesejo vec placljivih aplikacij kot uporabniki naprav iPod

Touch, Android in webOS.

• Uporabniki naprav iPod Touch mesecno za nakup aplikacij zapravijo povprecno

11,39 USD. Uporabniki naprav Android in iPhone zapravijo podobno, in sicer

nekaj cez 8 USD mesecno.

• Povprecna cena aplikacij je najvisja za webOS uporabnike, in sicer 3,82 USD.

Najcenejse so aplikacije za Android. V povprecju stanejo 1,67 USD.

• Uporabniki naprav iPhone, Android in webOS so glede na starost enakomerno

porazdeljeni po starostnih skupinah, medtem ko je 65% uporabnikov iPod Touch

mlajsih od 25 let.

• Najbolj zadovoljni s svojimi napravami so uporabniki naprav iPhone, najmanj

zadovoljni pa uporabniki naprav webOS [38].

Ponudnik mobilnih storitev O2 je v Zdruzenem Kraljestvu, junija 2010, prenehal po-

nujati neomejeno kolicino prenosa podatkov v cenejsih paketih, ki so jo uporabniki

lahko koristili vse od izida prve naprave iPhone. Uporabniki so bili ogorceni, revija

Macformat pa je objavila rezultate ankete, kjer so skoraj 1000 uporabnikov povprasali

o kolicini mesecnega prenosa podatkov. Ugotovili so, da je 81% uporabnikov mesecno

preneslo manj kot 500MB podatkov. Mesecno povprecje je znasalo 720MB. Ce pri

izracunu povprecja ne upostevamo 1% uporabnikov, ki mesecno prenesejo najvec po-

datkov, je mesecno povprecje komaj 221MB [39].

Podjetje Localytics ponuja resitev za razlicne platforme, ki ponudnikom aplikacij

omogoca analizo nacina uporabe njihove aplikacije. Localytics je dva meseca zbiral

podatke uporabnikov iz ZDA in Kanade ter analiziral uporabo aplikacij glede na

dan v tednu in uro v dnevu. Ugotovili so, da se uporaba aplikacij med vikendi

in delavniki razlikuje tako po kolicini uporabe kot po dinamiki uporabe. Uporaba

aplikacij je med vikendi za 7% visja kot med delavniki. Pri analizi dinamike so

rezultate normalizirali za vsak dan v tednu; za vsak dan so stevilo sej v vsaki uri

delili s stevilom sej v uri, v kateri je bilo sej najvec. Izkazalo se je, da pricne ob

vikendih uporaba narascati ob 6. uri zjutraj, do 11. ure doseze 90% najvecje uporabe

in ostane blizu 100% vse do 21. ure. Ob delavnikih promet raste pocasneje in



enakomerneje skozi ves dan ter doseze vrh ob 21. uri zvecer. Slika 3.8 prikazuje

dinamiko uporabe aplikacij za sobote in torke. Avtorji clanka zakljucujejo, da je

iPhone naprava, ki se vecinoma uporablja v zasebne namene, izven delovnega casa [40].

Slika 3.8: Dinamika uporabe aplikacij za torke in sobote [40].


Stran 24 POGLAVJE 4. OGRODJA ZA GRAFICNI VMESNIK V IOS

Poglavje 4

Ogrodja za graficni vmesnik v iOS

Grafika in animacija sta eni izmed kljucnih komponent vsake igre, od njiju pa je mno-

gokrat odvisen tudi uspeh igre. Zato je potrebno ogrodja, ki jih lahko uporabimo pri

razvoju graficnega vmesnika, na platformi iOS, podrobneje preuciti. Izbira napacnega

ogrodja ima lahko za razvoj igre usodne posledice. Lahko se pripeti, da bomo igro

razvijali predolgo ali pa ne bo delovala dovolj tekoce.

4.1 Ogrodje UIKit

Ogrodje UIKit je eden najenostavnejsih nacinov za gradnjo uporabniskega vmesnika.

Ogrodje sestavljajo razredi Objective-C, ki imajo predpono UI. Vsi razredi, ki so

namenjeni prikazu, so izpeljani iz razreda UIView. Ta razred implementira osnovno

obnasanje gradnikov uporabniskega vmesnika. Razred podpira sprejem razlicnih do-

godkov, izris in animacijo dolocenih lastnosti. Pogledi oziroma primerki razreda UIView

so urejeni v hierarhijo, ki je lahko poljubno globoka. To dosezemo z dodajanjem no-

vih pod-pogledov (angl. subview). Vsak pogled je odgovoren za upravljanje s svojimi

pod-pogledi [41].

Razred UIView je izpeljan iz razreda UIResponder, s katerim zagotavlja verigo odgo-

vornosti za obravnavo dolocenih dogodkov, kot je dotik na zaslon [42].

Razrede izpeljane iz razreda UIView lahko razdelimo v naslednje kategorije: vsebo-

valniki, kontrole, razlicni pogledi za besedila in spletne strani, pogledi za opozorila,

pogledi za navigacijo med pogledi in okno (angl. window), ki je korenski vsebnik za

vse ostale poglede [41].


4.2. OGRODJE CORE GRAPHICS Stran 25

Z ogrodjem UIKit je, poleg prikaza slik, zelo enostavno dodajati v igrah uporabne

komponente, kot so opozorilna okna, napisi in vnosna polja. Gradnike ogrodja UIKit

je mogoce uporabljati tudi v programu Interface Builder, s katerim si lahko mocno

poenostavimo izdelavo menijev in drugih staticnih elementov igre [43].

UIKit lahko uporabimo tudi za samo dolocen del igre. Ce igro programiramo z OpenGL

ES, si lahko z uporabo ogrodja UIKit in Interface Builderja mocno poenostavimo gra-

dnjo razlicnih menijev. Prepletanje obeh tehnologij tehnicno gledano ni zahtevno, lahko

pa povzroci slabo zmogljivost taksnih aplikacij. Se posebej problematicna je uporaba

vecjega stevila komponent za UIKit in uporaba prosojnih komponent [45].

Kljub enostavnosti prikazovanja in postavitve slik, ostaja UIKit relativno hiter, zaradi

strojnega pospesevanja grafike. UIKit je tako dobra izbira za igre, ki ne vsebujejo

veliko graficnih elementov ali animacij in ne potrebujejo izrisovanja pri najvecji mozni

hitrosti, to je 60 slicic na sekundo (FPS) [43].

4.2 Ogrodje Core Graphics

Quartz 2D, poznan tudi pod imenom Core Graphics, je nizjenivojsko ogrodje za risanje

vektorske grafike, bitnih slik in PDF vsebin. Vmesnik za programiranje (API) je napi-

san v jeziku C. Vsi podatkovni tipi in metode povezane s tem ogrodjem imajo predpono

CG. Quartz 2D obicajno uporabimo takrat, kadar potrebujemo boljse zmogljivosti 2D

risanja. Le-te izkoriscajo tudi visjenivojska ogrodja, kot je UIKit [46, 47].

Nacin uporabe Quartz 2D je podoben slikanju na platno. Vedno nanasamo nove plasti

barve. Rezultat risanja je tako odvisen od vrstnega reda izrisovanja. Izrisovanje poteka

na graficni kontekst (angl. graphics context), ki je tipa CGContextRef. Predstavljamo

si ga lahko tudi kot cilj za izris ali platno. Kreiramo lahko graficne kontekste za risanje v

PDF dokumente in v bitne slike. Za izrisovanje neposredno na zaslon s klicem dolocene

metode pridobimo ze obstojeci graficni kontekst. To storimo v implementaciji privatne

metode drawRect: v razredu, ki smo ga izpeljali iz razreda UIView [47].

4.3 Knjiznica Core Animation

Core animation je namenjen izdelavi dinamicnih animiranih graficnih uporabniskih

vmesnikov. Pri tem ni potrebe, da uporabimo nizjenivojske vmesnike za programiranje

4.2. OGRODJE CORE GRAPHICS Stran 25


grafike, kot je OpenGL, z namenom, da bi dosegli dobre zmogljivosti. Vmesnik za

programiranje je napisan v jeziku Objective-C. Razredi knjiznice imajo predpono CA.

Razrede knjiznice Core Animation lahko razdelimo v naslednje kategorije:

• razredi za plasti,

• razredi za animacije in spreminjanje casovnega poteka,

• razredi za razporejanje (angl. layout) in omejitve,

• razred za zdruzevanje animacij.

Razredi za plasti so osnova knjiznice Core Animation. Njihova temeljna funkcionalnost

je implementirana v razredu CALayer. Ta razred je nadrazred vsem Core Animation

razredom za plasti. Tako kot so primerki razreda UIView, ki jim bomo rekli pogledi,

urejeni v hierarhijo in imajo svoje nad in podpoglede, tako so tudi plasti oziroma

primerki razreda CALayer urejeni v drevo plasti in imajo svojo nadplast in podplasti.

Core Animation ne nudi nacina za neposreden prikaz plasti v oknu, temvec moramo

plast povezati s pogledom. Vsak pogled avtomatsko kreira primerek razreda CALayer

oziroma plast, ki je dostopna preko, samo za branje namenjene lastnosti layer.

Kadar uporabljamo razrede UIView, moramo razsiriti razred in implementirati me-

todo drawRect:, ce zelimo prikazati doloceno vsebino. Pri uporabi razreda CALayer

razsirjanje razreda obicajno ni potrebno, saj lahko vsebino obstojeci plasti, podamo se

na naslednja nacina:

• preko lastnosti contents dolocimo sliko tipa CGImageRef ali

• preko lastnosti delegate dolocimo delegat, ki implementira metodo

displayLayer: in doloci sliko plasti preko lastnosti contents, ali pa v

dolocen delegat sam implementira izris plasti v metodi drawLayer:inContext:.

Razred CALayer lahko shranjuje pare kljuc-vrednost. Delegat, ki implementira metodo

displayLayer:, lahko te informacije izkoristi in se odloci, katero sliko bo nastavil za

vsebino plasti.

Animiranje s Core Animation poteka avtomatsko, v loceni niti, brez dodatne interakcije

z aplikacijo. Za animiranje imamo na voljo naslednje razrede:


4.3. KNJIZNICA CORE ANIMATION Stran 27

• CABasicAnimation, namenjen za preprosto animiranje zeljene lastnosti plasti, od

ene vrednosti do druge.

• CAKeyFrameAnimation, razred, ki je podoben razredu CABasicAnimation, pri

cemer lahko namesto ene dolocimo vec ciljnih vrednosti za animirano lastnost.

Ce animiramo pozicijo ali sidrisce plasti, je dodatno podprto se animiranje po

poti, ki je tipa CGPathRef.

• CATransition, namenjen ucinkom za prehode, ki ucinkujejo na celotno vsebino

plasti. Primera taksnega ucinka bi bila, da sloj zbledi od zgoraj navzdol ali pa

vsebina sloja pridrsi z desne.

• CAnimationGroup, omogoca grupiranje animacij, ki jih zelimo izvajati hkrati

[48, 49].

Animacija je po najenostavnejsi definiciji spreminjanje vrednosti skozi cas. Casovni

model za Core Animation je opisan v protokolu CAMediaTiming. Model doloca casovni

odmik, trajanje, hitrost animacije in lastnosti za ponavljanje animacije. Kako so vme-

sne vrednosti animirane lastnosti porazdeljene skozi cas, doloca funkcija casovnega

poteka (angl. animation pacing). Izbira pravilne funkcije casovnega poteka je po-

membna, saj lahko bistveno vpliva na vtis uporabnika. Funkcija preslika vhodni cas,

ki je glede na trajanje animacije normaliziran na interval [0.0,1.0] v izhodni cas. Ta pa

je normaliziran na enak interval. Slika 4.1 prikazuje preddefinirane funkcije casovnega

poteka, ki jih predstavljajo naslednje konstante:

• kCAMediaTimingFunctonLinear, ki predstavlja linearni casovni potek,

• kCAMediaTimingFunctionEaseIn, pri kateri se animacija zacne pocasi in je proti

koncu vedno hitrejsa,

• kCAMediaTimingFunctionEaseOut, kjer se animacija pricne hitro, nato pa proti

koncu upocasni,

• kCAMediaTimingFunctionEaseInEaseOut, kjer je animacija na zacetku pocasna,

nato pospesuje do sredine in upocasnjuje proti koncu.



Slika 4.1: Preddefinirane funkcije casovnega poteka.

Omenjene konstante uporabimo pri kreiranju primerka razreda

CAMediaTimingFunction. Primerek pa lahko kreiramo tudi tako, da dolocimo

kontrolni tocki kubicne Bezierjeve krivulje in tako definiramo lastno funkcijo

casovnega poteka. Kreiran primerek dolocimo razredu CAAnimation preko lastnosti

timingFunction [49].

Animacijo lahko pozenemo na dva nacina. S kreiranjem implicitne ali s kreiranjem

eksplicitne animacije. Implicitna animacija se kreira avtomatsko, to pa se zgodi, kadar

spreminjamo katero izmed lastnosti, ki jih je mozno animirati na plasti. To pomeni, da

spreminjanje vrednosti lastnosti nima takojsnjega ucinka, temvec se ustvari animacija,

ki zagotovi postopen prehod iz prejsnje na novo vrednost. Privzeto dolzino implicitne

animacije, 0,25 sekunde, je mogoce spremeniti. Izvorna koda 4.1 demonstrira uporabo

implicitne animacije, ki postopoma spremeni lokacijo in prosojnost plasti.

1 layer.position = CGPointMake (500.0 ,500.0);

2 layer.opacity = 0.0;

Izvorna koda 4.1: Primer implicitne animacije.

Pri eksplicitni animaciji sami kreiramo instanco enega od prej omenjenih razredov za

animiranje, nastavimo zacetne in koncne vrednosti ter dolocimo lastnost, ki jo ani-

miramo. Animiranje se pricne, ko objekt za animacijo dodamo plasti preko metode

addAnimation. Ze z uporabo najbolj osnovnega razreda za animiranje, imenovanega

CABasicAnimation, lahko kontroliramo vec lastnosti animacije v primerjavi z implici-

tnimi animacijami. Izvorna koda 4.2 demonstrira, kako ustvariti animacijo, kjer plast

pocasi postane prosojna in se zatem ponovno prikaze, pri cemer vsak prehod traja 3

sekunde. Celotna animacija se nato se enkrat ponovi [48].



1 CABasicAnimation *theAnimation;

2 theAnimation = [CABasicAnimation animationWithKeyPath:@"

opacity"];

3 theAnimation.duration = 3.0;

4 theAnimation.repeatCount = 2;

5 theAnimation.autoreverses = YES;

6 theAnimation.fromValue = [NSNumber numberWithFloat :1.0];

7 theAnimation.toValue = [NSNumber numberWithFloat :0.0];

8 [theLayer addAnimation:theAnimation forKey:@"animateOpacity

"];

Izvorna koda 4.2: Primer eksplicitne animacije.

Animiranje v UIKit je se dodatno poenostavljeno, saj so podporo za ustvarjanje anima-

cij vgradili neposredno v razred UIView. Prvi korak pri animiranju z razredom UIView

je, da s klicem metode beginAnimations napovemo blok za animacijo. Blok zakljucimo

s klicem razredne metode commitAnimations. V bloku, preko drugih staticnih metod

razreda UIView, nastavimo lastnosti animacije, nato pa na primerku, ki ga animiramo,

spremenimo vrednost lastnosti, ki jih animiramo. Po klicu commitAnimations bodo

vrednosti, ki smo jih spremenili, postopoma presle na nove vrednosti. Lastnosti pogle-

dov, ki jih lahko animiramo, so:

• frame, ki doloca pozicijo in velikost pogleda glede na koordinatni sistem nadpo-

gleda,

• bounds, ki doloca pozicijo in velikost vsebine glede na lasten koordinatni sistem,

• center, ki doloca sredisce glede na koordinatni sistem nadpogleda,

• transform, ki doloca matriko za transformacijo pogleda, s katero dosezemo

razlicne ucinke, kot so translacija, rotacija in povecava,

• alpha, ki doloca nivo prosojnosti [41].

Pri razvoju za iOS razlicice 4.0 in novejse, lahko animiramo enake lastnosti, sam

postopek pa je nekoliko spremenjen. Animiranje izvedemo z enim samim klicem,

in sicer uporabimo eno izmed metod animateWithDuration:. Vsaka izmed metod



animateWithDuration: poleg casa trajanja animacije, prejme se blok kode kot argu-

ment, v katerem spremenimo lastnosti, ki se bodo nato animirale. Primer animiranja

za iOS 4.0 z uporabo razrednih metod razreda UIView prikazuje izvorna koda 4.3.

1 [UIView animateWithDuration :1.0 animations :^{

2 firstView.alpha = 0.0;

3 secondView.alpha = 1.0;

4 }];

Izvorna koda 4.3: Primer animiranja z razrednimi metodami razreda UIView za iOS

4.0.

4.4 Programski vmesnik OpenGL ES

OpenGL ES je brezplacen, vecplatformski programski vmesnik za razvoj 2D in 3D gra-

fike. Je poenostavljena razlicica namizne razlicice OpenGL in je namenjen izkoriscanju

moderne graficne strojne opreme v vgrajenih sistemih. Vmesnik za programiranje je

v nasprotju s tehnologijami Core Graphics, Core Animation in UIKit, na zelo nizkem

nivoju in temelji na jeziku C. OpenGL ES funkcije posiljajo graficne ukaze neposre-

dno strojni opremi, ki je namenjena obdelavi teh ukazov. Zaradi tega je izrisovanje z

OpenGL ES obicajno izredno hitro [50].

OpenGL ES nima visokonivojskih ukazov za opisovanje 3D objektov, temvec moramo

sami zgraditi zelen model iz majhnega nabora geometrijskih gradnikov - tock, daljic in

mnogokotnikov. OpenGL ES prav tako ne vsebuje ukazov za interakcijo z uporabnikom

in upravljanje z okni.

OpenGL ES je avtomat. Njegovo stanje spreminjamo s spremenljivkami stanj. Kadar

stroj postavimo v doloceno stanje, ostane v tem stanju vse dokler ga ponovno ne

spremenimo. Veliko spremenljivk je taksnih, ki enostavno vklopijo ali izklopijo doloceno

stanje. Kot primer spremenljivke stanja navedimo osvetlitev, ki bo onemogocena za

vse izrise, dokler je ne bomo omogocili. Za vkljucitev stanja uporabimo komando

glEnable(GLenum capability), v nasem primeru glEnable(GL LIGHTING) [52].

Ortogonalna in perspektivna projekcija sta v OpenGL ES dva nacina projiciranja geo-

metrijskih objektov v prostoru na projekcijsko ravnino. Ortogonalna projekcija je eno-

stavnejsa. Objekte pravokotno projicira na projekcijsko ravnino in je tako uporabna


4.4. PROGRAMSKI VMESNIK OPENGL ES Stran 31

za 2D grafiko, na primer za programe CAD in 2D igre. Pri perspektivni projekciji je

velikost objekta pogojena z njegovo oddaljenostjo. Blizje kot je projekcijski ravnini

v vidnem volumnu, vecja je njegova projekcija. Slika 4.2 prikazuje isti objekt, ki je

projiciran prvic z ortogonalno in drugic s perspektivno projekcijo.

(a) Ortogonalna projekcija (b) Perspektivna projekcija

Slika 4.2: Dva nacina projiciranja geometrijskih objektov v prostoru na projekcijskoravnino v OpenGL ES.

Za lazjo prenosljivost kode definira OpenGL ES lastne podatkovne tipe, ki imajo pred-

pono GL. Predponi obicajno sledi ime pripadajocega tipa iz jezika C, kot na primer

byte, short, float, itd. Imena funkcij in procedur v OpenGL ES so sestavljena iz

predpone knjiznice, ukaza in dveh neobveznih delov, ki dolocata stevilo in tipe argu-

mentov. glColor3f(...) je primer ukaza, ki sprejme tri argumente tipa GLfloat.

Vozlisca v prostoru dolocimo s funkcijami OpenGL ES, katerih ime se pricne z

glVertex. Z njimi lahko dolocimo prej omenjene osnovne geometrijske objekte. Ukaze

glVertex uporabljamo med ukazoma glBegin in glEnd. Ukazu glBegin moramo

podati argument, s katerim dolocimo nacin obravnave tock. Vsi podprti nacini v

OpenGL ES so razvidni iz slike 4.3. OpenGL ES privzeto pricakuje, da bomo vo-

zlisca trikotnika nanizali v matematicno pozitivni smeri, ce vidimo povrsino trikotnika

s sprednje strani, v nasprotnem primeru pa vozlisca nanizamo v obratni smeri.

4.4. PROGRAMSKI VMESNIK OPENGL ES Stran 31


Slika 4.3: Podprti nacini obravnave vozlisc v OpenGL ES.

Ce zelimo model rotirati, premakniti ali skalirati, uporabimo ukaze OpenGL ES, ki jih

prikazuje izvorna koda 4.4. Ti ukazi spreminjajo trenutno matriko, ki ima dimenzije

4×4. Za transformacije modela mora biti trenutna matrika, ki jo spreminjamo, matrika

pogleda modela. Ob uporabi vozlisc modela, bo OpenGL ES vsako vozlisce pomnozil s

to matriko in tako izvedel zahtevane transformacije. Ukaz za translacijo bo spremenil

matriko tako, da bo vsako vozlisce premaknjeno za vektor (x, y, z). Ukaz za rotacijo

spremeni matriko tako, da vsako vozlisce rotira za dolocen kot φ okoli podanega vek-

torja (x, y, z). Ukaz za skaliranje spremeni matriko tako, da se vsako vozlisce vzdolz

osi x, y, z skalira za podane vrednosti sx,sy,sz [43, 51].

1 glTranslatef(GLfloat x, GLfloat y, GLfloat z);

2 glRotatef(GLfloat angle , GLfloat x, GLfloat y, GLfloat z);

3 glScalef(GLfloat x, GLfloat y, GLfloat z);

Izvorna koda 4.4: Ukazi za geometrijske transformacije nad vozlisci.

Kot smo pokazali v tem poglavju, lahko z OpenGL ES ze izris preprostega lika zahteva

precej vec truda, kot ce bi to storili z visjenivojskimi ogrodji. Zaradi tega OpenGL ES

obicajno ne uporabljamo neposredno, temvec se zanasamo na visjenivojska ogrodja,

ki temeljijo na OpenGL ES. Med njimi sta tudi ogrodji UIKit in Core Animation,

cesar pa razvijalec ne zazna. Ce OpenGL ES uporabimo za razvoj iger, obicajno sprva

razvijemo na OpenGL ES temeljec igralni pogon ali pa uporabimo katerega izmed ze

obstojecih igralnih pogonov.

Za platformo iOS je na voljo precej razlicnih igralnih pogonov, ki jih lahko uporabimo

pri razvoju iger [58]. Najpomembnejsi so iTorque 2D [53], cocos2d [54], Unity [55], SIO2


4.5. PLATFORMA ADOBE FLASH Stran 33

[56] in Oolong [57]. Odprtokodni igralni pogon cocos2d bomo v poglavju 6 podrobneje

predstavili.

4.5 Platforma Adobe Flash

Flash je uveljavljena multimedijska platforma, ki se uporablja za prikazovanje videa,

animacij in drugih interaktivnih vsebin na spletu in v samostojnih aplikacijah. V

spletnih brskalnikih je za uporabo tehnologije potrebno imeti namesceno razsiritev

Flash Player, za samostojne aplikacije pa Adobe Air. Omenjena produkta predstavljata

izvajalno okolje za Flash oziroma aplikacije Air, s tem pa je zagotovljena prenosljivost

aplikacij med razlicnimi sistemi. Na mobilnih napravah je tehnologijo ze nekaj casa

mogoce najti v okrnjeni razlicici, imenovani Lite, intenzivno pa pripravljajo tudi polno

razlicico za mobilne naprave. Polna razlicica Flash Playerja 10.1 in Adobe Air 2.5

je ze na voljo za platformo Android. Od zadnje razlicice dalje vsebuje tudi podporo

za zaznavanje vec hkratnih pritiskov na zaslon (angl. multitouch), sprejem podatkov

pospeskometra in izkoriscanje lastnosti specificne za mobilne naprave, kot so strojno

dekodiranje zvoka in videa ter varcevanje z energijo [59].

Flash tehnologija ni podprta na iOS. Vsaj ne v obliki, ki jo poznamo na drugih sistemih,

kjer lahko namestimo samostojne aplikacije Air oziroma predvajamo datoteke SWF

v Flash Playerju. Podjetje Adobe je konec leta 2009 izdalo produkt Packager for

iPhone, s katerim lahko aplikacijo Flash pretvorimo v nativno aplikacijo iOS. Podjetje

Adobe je razvoj Packagerja v letu 2010 prekinilo za vec mesecev, saj je podjetje Apple

s spremenjenimi pravili onemogocilo objavljanje tako pripravljenih aplikacij, vse do

septembra 2010. Trenutna razlicica Packagerja nosi oznako Preview 2, z njim pa je

pripravljenih ze vec iger, ki jih najdemo na App Storu [60, 61].

Tehnologija Flash lahko na iOS do dolocene mere izkorisca strojno pospesevanje gra-

fike. To omogoca rasterizacija vektorskih objektov v obliko bitne slike, ki se shrani

za kasnejso uporabo. Shranjena bitna slika je rasterizirana brez transformacij. Zaradi

tega rasterizacija pri ponovnem izrisu scene ni potrebna, tudi ce smo objekt prema-

knili, rotirali ali skalirali. Omenjena bitna slika je shranjena v graficnem pomnilniku

kot tekstura in jo uporablja graficni procesor (GPU). Transformacije in kompozicijo

objektov ravno tako izvede GPU. Strojno pospeseni so tudi objekti tipa Bitmap, ki

so namenjeni prikazovanju bitnih slik. Ti objekti imajo dejanske podatke shranjene v

objektu tipa BitmapData. Na podlagi obstojecega objekta BitmapData lahko kreiramo

4.5. PLATFORMA ADOBE FLASH Stran 33


nove objekte Bitmap, kar pomeni, da smo kreirali vec slik z enako vsebino, vsi pa bodo

imeli skupno teksturo v graficnem pomnilniku. Kompozicijo in transformacije bo po-

novno izvedel GPU. Za uporabo omenjenih zmogljivosti je potrebno objektom nastaviti

lastnost cacheAsBitmap na vrednost true in dolociti transformacijsko matriko, ki jo bo

uporabil GPU preko lastnosti cacheAsBitmapMatrix.

Pri tem ne smemo zanemariti zmogljivosti aplikacij Flash. Te se interpretirajo na

strojni opremi, ki je precej pocasnejsa od osebnih racunalnikov [61, 62].

4.6 Izbira tehnologije

Na vprasanje, katero tehnologijo izbrati, nimamo enotnega odgovora, saj na izbiro

vplivajo razlicni dejavniki. Zaradi tega bomo izbiro ustrezne tehnologije predstavili z

vidika zmogljivosti, zahtevnosti uporabe in vidika prenosljivosti.

Zmogljivost

OpenGL je z vidika zmogljivosti najboljsa izbira za razvoj tako 2D kot 3D iger. Ce ne

razvijamo 3D igre in ce igra ne vsebuje velikega stevila premikajocih se objektov, ki

se morajo gladko animirati, je enostavneje uporabiti preostale tehnologije za grafiko

in animacije iz sloja Cococa Touch, in sicer UIKit, Core Animation in Core Graphics.

Zahtevnost uporabe

Tehnologija OpenGL je zahtevnejsa za razumevanje, njena uporaba pa zahteva vec

truda. To pa ne velja za UIKit in Core Graphics, kjer je prikazovanje slik in grafike

zelo enostavno, omejitve graficne strojne opreme pa zaradi visokonivojskega vmesnika

ni potrebno upostevati.

Kljub temu, da se igre med sabo zdijo razlicne, uporabljajo obicajno z vidika razvijalca

zelo podobne funkcije, kot so nalaganje in dodajanje objektov, premikanje, prozenje

dogodkov, odzivanje na dogodke, itd. Igralni pogoni za igre so nacrtovani tako, da

pokrivajo kar najvecji del omenjene skupne funkcionalnosti. Kot smo ze omenili, za

razvoj igre ni nujno potrebno, da razvijemo lastni igralni pogon, saj je na trgu veliko

dobro dodelanih tako placljivih kot brezplacnih igralnih pogonov.


4.6. IZBIRA TEHNOLOGIJE Stran 35

Prenosljivost

Ob pravilnem pristopu lahko vecino izvorne kodo igre, ki uporablja OpenGL, prenesemo

na drug sistem. To pa ne velja za tehnologije UIKit, Core Animation in Core Graphics.

Te tehnologije so specificne za sistema MAC OS X in iOS. Po prenosljivosti vsekakor

izstopa tehnologija Flash, ki je se posebej uporabna, ce ze imamo razvito igro v jeziku

ActionScript [43, 45, 58].

4.6. IZBIRA TEHNOLOGIJE Stran 35

Stran 36 POGLAVJE 5. OGRODJA ZA AVDIO V IOS

Poglavje 5

Ogrodja za avdio v iOS

Preproste zvocne ucinke so vsebovale ze prve igre v sedemdesetih letih prejsnjega sto-

letja. V igrah, ki jih igramo danes, so zvocni ucinki vse prej kot preprosti. Novejse igre

imajo pogosto kompleksne zvocne ucinke, ki so zelo podobni tistim, ki jih srecamo v

filmih. Zvocni ucinki v igrah so lahko celo interaktivni in se prilagajajo vzdusju v igri

ter uporabnikovim akcijam. V nekaterih igrah je zvok celo najbolj kljucna komponenta,

od katere je odvisna celotna uporabniska izkusnja. Taksne igre so zanra ritmicnih iger

(angl. rhythm games), ki od uporabnika zahtevajo dolocene akcije, glede na zvok, ki

ga igra predvaja. Zaradi pomembnosti komponente zvoka v igrah, bomo predstavili

zmoznosti za delo z zvokom na platformi iOS [63].

5.1 Ogrodja Core Audio

Core Audio je zbirka ogrodij, ki pokriva z zvokom povezane storitve v aplikacijah

namenjenih platformam iOS in MAC OS X. Core Audio na platformi iOS, za razliko od

platforme MAC OS X, vkljucuje dodatna orodja in je optimiziran za naprave iOS. Slika

5.1 prikazuje ogrodja in pomembnejse pakete, ki vsebujejo implementacijo vmesnikov

in orodij za delo z zvokom na platformi iOS.


5.1. OGRODJA CORE AUDIO Stran 37

Slika 5.1: Ogrodja in paketi za delo z zvokom na platformi iOS [43, 44].

Audio Units

Audio Units so nizkonivojske storitve v Core Audio z izredno fleksibilnostjo. Na-

menjene so zagotavljanju nizke latence zvoka v aplikacijah in so kompleksne za

uporabo. iOS ima avtomatsko vgrajenih vec taksnih storitev, kot so 3D Mixer unit,

Multichnanel Mixer unit in Voice Processing I/O unit.

Audio File Services

Audio File Services omogocajo abstrakcijo za shranjevanje in branje zvocnega zapisa

ter metapodatkov v datotekah.

Audio File Stream Services

Audio File Stream Services ima podobno nalogo kot Audio File Services, s to razliko,

da je namenjen delu s tokovi namesto delu z datotekami.

Audio Converter Services

Audio Converter Services omogoca pretvorbo med razlicnimi formati zvocnih zapisov.

5.1. OGRODJA CORE AUDIO Stran 37


Audio Session Services

Audio Session Services je pomembna storitev, ki je pogosto spregledana, ker se

ne osredotoca na osnovne, z zvokom povezane storitve, temvec na obnasanje in

koordinacijo zvoka z drugimi aplikacijami v ozadju.

System Sound Services

System Sound Services je namenjen predvajanju kratkih zvocnih zapisov in opozoril.

Omogoca tudi uporabo vibre, ce je le ta podprta na napravi.

Audio Queue Services

Audio Queue Services je namenjen predvajanju in snemanju daljsih zvocnih zapisov.

Omogoca se dolocene operacije nad predvajanjem, kot so pavza, nadaljevanje in

ponavljanje predvajanja ter sinhronizacija vec kanalov. V igrah je najbolj uporaben

za predvajanje glasbe v ozadju ali daljsih zvocnih zapisov [43].

Ogrodje MediaPlayer

Ogrodje MediaPlayer vsebuje razrede, s katerimi omogoca dostop do vsebin iz knjiznice

iPod in njihovo predvajanje. V tej knjiznici se nahajajo glasbene in video datoteke, ki

smo jih na napravo iOS prenesli z osebnega racunalnika s programom iTunes [44].

Ogrodje AVFoundation

AVFoundation je ogrodje v Core Audio, ki vsebuje razrede za predvajanje

(AVAudioPlayer), snemanje (AVAudioRecorder) in nastavitve obnasanja pri uporabi

zvokov v aplikaciji (AVAudioSession). AVFoundation v iOS 4 vsebuje se dodatne

splosnejse razrede za razlicno delo z video in zvocnim zapisom, kot so kreiranje,

urejanje in zajemanje [43].


5.2. KODIRANJE ZVOKA Stran 39

5.2 Kodiranje zvoka

Vecina storitev v Core Audio uporablja in manipulira zvok, ki je predstavljen v ne-

kompresiranem digitalnem formatu PCM1. Podatki v PCM se ustvarijo tako, da v

dolocenih casovnih intervalih (frekvenca vzorcenja) izmerimo magnitudo analognega

zvocnega signala in ji priredimo numericno vrednost. Standardni avdio CD je vzorcen

pri frekvenci 44,1kHz, vsak vzorec pa je opisan s 16 bitnim celim stevilom. PCM je

sicer enostavno predvajati, vendar zasede precej prostora. Za boljsi izkoristek prostora

obstajajo razlicni standardi za kodiranje. Pri njihovi uporabi se moramo zavedati, da

prihaja pri nekaterih standardih do izgub v kakovosti zapisa in da lahko nekateri stan-

dardi bolj obremenijo strojno opremo kot drugi. V Core Audio so podprti naslednji

kodirniki/dekodirniki (codec):

• MPEG-1, Audio Layer 3 (MP3): Je zelo razsirjen format, izvira iz video specifika-

cije MPEG-1. Pri kompresiji pride do izgubnega stiskanja (angl. lossy compres-

sion2). MP3 lahko zasede tudi komaj 111

prostora v primerjavi z nekompresiranim

nacinom, pri cemer vecina poslusalcev ne opazi razlik med njima.

• Advanced Audio Coding (AAC): Je naslednik formata MP3 in privzet format

naprave iPod. V primerjavi z MP3 nudi pri enaki kakovosti se boljso kompresijo.

• Apple Losseless (ALAC): V primerjavi z nekompresiranim nacinom je velikost

datotek od 40% do 60% manjsa. Pri kompresiji ne pride do izgubnega stiskanja.

• IMA/ADPCM/IMA-4: Razvit v 70-ih za namene kompresije govora. Pri kom-

presiji pride do izgubnega stiskanja. Zasede priblizno 14

prostora v primerjavi z

nekompresiranim zapisom.

• Adaptive Multi-Rate (AMR): Optimiziran za kompresijo govora. Uporablja se

pri standardih GSM in UMTS.

• Internet Low Bitrate Codec (iLBC): Je brezplacen za uporabo in optimiziran za

kompresijo govora.

• µLaw in aLaw: Kompresijska algoritma, ki sta uporabljena v telekomunikacijskih

sistemih [43].

1Pulse Code Modulation2Del informacij se pri kompresiji izgubi, originalnega zapisa ni mogoce vec pridobiti.

5.2. KODIRANJE ZVOKA Stran 39


Podjetje Apple omenjene standarde za kodiranje v iOS deli v dve skupini. V prvi

skupini so prvi trije omenjeni standardi: MP3, AAC in ALAC. Ti uporabljajo namen-

sko strojno opremo za dekodiranje, s tem pa se razbremeni centralna procesna enota

(CPE). Ce bomo hkrati predvajali vec zvokov iz omenjene skupine, se bo zvocni zapis

dekodiral programsko, kar je podprto od iPhone OS 3.0 dalje. Programsko dekodiranje

bo v tem primeru opazno obremenilo CPE. Vsi preostali standardi spadajo v drugo

skupino. Zvocne zapise, ki so kodirani s standardi iz druge skupine, lahko predvajamo

hkrati, brez da bi s tem pretirano obremenili CPE [45, 64].

5.3 Tipi datotek

Zvocni zapis kodiran s prej omenjenimi standardi, najdemo v naslednjih datotecnih

formatih, podprtih v Core Audio:

• AIFF: V 80-ih razvit format za shranjevanje Linear PCM, ki ima koncnico .aif

ali .aiff.

• WAV, WAVE: Microsoftov format za shranjevanje zvocnega zapisa Linear PCM

s koncnico .wav.

• MP3: Namenjen kodirnemu standardu MP3. Obicajno uporablja vsebnik ID3 za

metapodatke. Datoteke imajo koncnico .mp3.

• MP4, M4A, 3GPP, 3GP2: Temeljijo na skupni specifikaciji. ALAC vedno upo-

rablja format M4A, AMR lahko uporablja 3GP in 3G2, AAC vcasih uporablja

MP4 ali M4A. Koncnice datotek so .mp4, .m4a, .3gp in .3g2.

• AAC: Podobno kot MP3, tudi kodirni standard AAC obicajno uporablja format

datoteke AAC.

• AMR: Obicajen format za AMR kodiranje.

• CAF: Format je razvilo podjetje Apple. Namenjen je vsem standardom kodiranja.

Nima omejitve velikosti in omogoca shranjevanje velikega stevila metapodatkov.

Datoteke imajo koncnico .caf [43].


5.4. IZBIRA STANDARDA ZA KODIRANJE IN TIPA DATOTEKE Stran 41

5.4 Izbira standarda za kodiranje in tipa datoteke

Kaksen standard kodiranja bomo izbrali za posamicen zvok, je odvisno od potreb.

Ce ne bomo predvajali vec zvokov hkrati in nam je vseeno, da uporabimo standard

kodiranja z izgubnim stiskanjem, potem izberemo AAC. AAC ali kaksen drug standard

kodiranja iz prve skupine je v igrah primeren za predvajanje glasbe v ozadju. Ce bomo

predvajali vec zvokov hkrati, pa je dobra izbira IMA-4, ki nudi zelo dobro kompresijo,

brez da bi bistveno bolj obremenil CPE kot PCM [43, 45].

5.5 Programski vmesnik OpenAL

Open Audio Library (OpenAL) je vecplatformski programski vmesnik za 3D avdio. V

iOS je implementirana specifikacija OpenAL razlicice 1.1, ki je vkljucena v CoreAudio

in je namenjena uporabi v igrah. OpenAL omogoca:

• predvajanje z nizko latenco,

• avtomatsko mesanje zvokov, ki se predvajajo hkrati,

• pozicijski 3D avdio,

• utisanje zvoka glede na oddaljenost od vira,

• sprememba frekvence zvoka pri spreminjanju razdalje med virom in opazovalcem

(doplerjev pojav),

• zajemanje zvoka (kar pa ni podprto v implementaciji OpenAL 1.1 za iOS).

Na njegovo zasnovo je mocno vplival OpenGL. OpenAL tako sledi podobnim konvenci-

jam za poimenovanje funkcij in je avtomat, tako kot OpenGL. Tudi koordinatni sistem

je skupen, kar olajsa sinhronizacijo pri premikanju graficnih objektov in pozicijo virov

zvoka. OpenAL neposredno uporablja Audio I/O unit.

Zvocni zapis, ki ga zelimo predvajati, mora biti kodiran s PCM in se nahajati v delu

pomnilnika, ki smo ga alocirali z OpenAL. Omenjeni medpomnilnik je analogen textu-

ram v OpenGL. Nanj se sklicujemo s celostevilcnim ID-jem. Uporabimo ga pri objektih

imenovanih Source. Ti predstavljajo vir zvoka v prostoru. Dolocimo jim lahko pozicijo

v prostoru, hitrost in druge lastnosti. Poleg medpomnilnika in objektov Source je tu se

5.4. IZBIRA STANDARDA ZA KODIRANJE IN TIPA DATOTEKE Stran 41


tretji kljucni gradnik v OpenAL, in sicer poslusalec (Listener). Podobno kot objekti

Source ima tudi poslusalec razlicne lastnosti, kot so lokacija, hitrost in orientacija.

Dvokanalni stereo zapis ne more biti vir zvoka v prostoru v OpenAL. Uporabimo lahko

samo enokanalen mono zapis. Dodatno moramo imeti na voljo vec kot en zvocnik, ce

zelimo slisati iz katere smeri prihaja zvok. Na napravah iPod Touch ali iPhone, ki

imata vgrajen samo en zvocnik, lahko to dosezemo s slusalkami ali zunanjimi zvocniki

[45, 64].


Stran 43

Poglavje 6

cocos2d za iPhone

cocos2d za iPhone je odprtokodno, brezplacno ogrodje za razvoj 2D iger ter drugih

graficnih in interaktivnih aplikacij za platformi iOS in Mac OS X. Ogrodje izkorisca

strojno pospesevanje grafike, sledi najboljsim praksam za razvoj aplikacij OpenGL ES

in uporablja optimizirane podatkovne strukture. Zasnova ogrodja cocos2d za iPhone

temelji na originalnem projektu cocos2d [65], ki je napisan v programskem jezik python,

medtem ko cocos2d za iPhone uporablja programski jezik Objective-C [54]. Ko bomo

v nadaljevanju omenjali cocos2d, se bomo sklicevali na projekt cocos2d za iPhone in

ne na originalno ogrodje cocos2d.

Prvotno je bil cocos2d namenjen igram in aplikacijam za naprave iPhone in iPod Touch

locljivosti 480×320. Kasneje je bila dodana podpora za naprave iPad ter zaslone novih

naprav iPhone in iPod Touch z zaslonom resolucije 960×640. Najvecje spremembe pri

podpori naprav je cocos2d dozivel konec leta 2010, saj so poleg platforme iOS podprli

se gradnjo aplikacij za operacijski sistem Mac OS X. Poleg tega so bili na osnovi

cocos2d ustvarjeni trije novi projekti, in sicer cocos2d-x [66], cocos2d-android-1 [67]

in cocos2d-javascript [68]. Tabela 6.1 prikazuje, na kateri razlicici cocos2d temeljijo

izpeljani projekti ter kateremu programskemu jeziku in platformi so namenjeni.

Stran 43

Stran 44 POGLAVJE 6. COCOS2D ZA IPHONE

Ciljna platforma Programski jezik Razlicica cocos2d

na kateri temelji

cocos2d [54] iOS, Mac OS X Objective-C -

cocos2d-x [66] iOS, Android,

Win32, uPhone1C++ 0.99.4

cocos2d-android-1 [67] Android Java 0.99.4

cocos2d-javascript [68] Spletni brskalnik HTML5 / Javascript 0.99.5

Tabela 6.1: Primerjava kljucnih lastnosti ogrodij izpeljanih iz ogrodja cocos2d.

O popularnosti ogrodja lahko sklepamo tudi po seznamu iger [69], ki so izdelane z

ogrodjem cocos2d. Seznam, na katerega lahko razvijalci prostovoljno dodajajo igre, se

vsakodnevno podaljsa za nekaj iger. Med razvitimi igrami je tudi nekaj taksnih, ki se

jim je v trznici App Store uspelo uvrstiti na lestvico desetih najbolje prodajanih iger.

Primer je igra StickWars (slika 6.1), z zelo zanimivim nacinom igranja. Igra je kar tri

mesece vztrajala na lestvici desetih najbolje prodajanih iger [54].

Slika 6.1: StickWars, ena izmed najbolje prodajanih iger.

6.1 Integracija ogrodja z Xcode

Pri starejsih razlicicah ogrodja cocos2d smo morali nov projekt cocos2d ustvariti na

podlagi klasicne OpenGL ES predloge za iOS in kasneje rocno dodati ogrodje cocos2d

ter ga povezati s projektom. Novejse razlicice ogrodja cocos2d nam s skripto install-

templates.sh v razvojno okolje Xcode namestijo predloge Mac OS X in iOS, s tem pa

1Prilagojena Android platforma podjetja Unicom


6.2. KLJUCNI GRADNIKI Stran 45

nam poenostavijo kreiranje novih projektov. Slika 6.2 prikazuje posodobljen vmesnik

za kreiranje novega projekta v okolju Xcode, ki nam poleg predlog cocos2d aplikacij

za Mac OS X in iOS ponudi se predlogo za aplikacijo iOS z Box2D ali Chipmunk

pogonom za fiziko. Po potrditvi izbire predloge, ki ne vkljucuje pogona za fiziko, se

ustvari delujoc projekt s sceno, ki prikaze sliko z napisom Hello World. V primeru, da

smo izbrali predlogo s pogonom za fiziko, pa scena vsebuje primer, ki izkorisca pogon

za fiziko [54].

Slika 6.2: Kreiranje novega projekta cocos2d v okolju Xcode.

6.2 Kljucni gradniki

CCDirector

Razred CCDirector je eden kljucnih razredov v cocos2d. Implementira vzorec

edinec in je odgovoren za shranjevanje globalnih nastavitev za cocos2d, inicializacijo

OpenGL ES, upravljanje s scenami in prehode med njimi. Podpira se pavzo, s katero

lahko zacasno spremenimo interval osvezevanja na 14

sekunde in tako pripomoremo k

varcevanju z energijo.



CCNode

CCNode je skupen nadrazred vsem razredom, ki se lahko izrisejo. Razred definira

lastnosti in metode, ki so skupne vsem razredom CCNode. Najpogosteje uporabljeni

razredi, ki razsirjajo CCNode, so: CCScene, CCLayer, CCSprite in CCMenu. Objek-

tom tipa CCNode dodajamo in odstranjujemo sinove tipa CCNode in tako gradimo

kompozicijo. Sinu, ki smo ga dodali, lahko dolocimo vrednost atributa z, s katerim

dolocimo vrstni red izrisa glede na ostale sinove. Dolocimo mu lahko se atribut tag,

s cimer sinu podamo identifikator, preko katerega lahko na enostaven nacin ponovno

pridobimo njegovo referenco. V objektih tipa CCNode lahko registriramo periodicne

klice dolocene metode (angl. timer). Periodicne klice urejamo z metodama schedule

in unschedule. Se ena izmed pomembnih zmoznosti v CCNode so animacije, ki jih

bomo predstavili v nadaljevanju.

CCScene

Tako kot primerki CCNode in CCLayer tudi primerki CCScene sami po sebi nimajo vi-

dne predstavitve in se uporabljajo samo interno, kot abstraktne komponente. Objekte

CCScene uporabljamo v kombinaciji z objektom CCDirector, kateremu ukazemo,

kaksno sceno naj prikaze oziroma s katero sceno naj nadomesti trenutno. Primerek

razreda CCScene mora biti oce na najvisjem nivoju v kompoziciji objektov CCNode.

Pri scenah lahko omenimo se razred CCTransitionScene, ki razsirja razred CCScene.

Razred CCTransitionScene predstavlja skupen nadrazred za doseganje posebnih

ucinkov pri prehodih med scenami. Eden taksnih razredov je CCPageTurnTransition,

ki ustvari animacijo podobno obracanju strani v knjigi.

CCLayer

Razred CCLayer razsirja CCNode in implementira protokola

CCStandardTouchDelegate ter CCTargetedTouchDelegate. Implementacija proto-

kola CCStandardTouchDelegate omogoca, da smo obvesceni o vseh dotikih zaslona in

z njimi povezanimi dogodki. V tem primeru bomo implementirali metode, kjer bomo

z objektom tipa NSSet, pridobili enega ali vec objektov UITouch z informacijami o

dotiku. Protokol CCTargetedTouchDelegate se prav tako uporablja za zaznavanje

dotikov zaslona, vendar za razliko od CCStandardTouchDelegate omogoca zaznavo

samo enega dotika naenkrat.



CCMenu

Razred CCMenu je namenjen izdelavi menijev. Konkretne gumbe na meniju dodamo

primerku CCMenu tako, da mu dodajamo primerke razredov, ki razsirjajo CCMenuItem.

Nekateri izmed teh razredov so:

• CCMenuItemImage, ki gumb kreira na podlagi slike. Gumbu lahko dolocimo se

sliko, ki se prikaze ob pritisku gumba in sliko, ki je prikazana takrat, kadar je

gumb onemogocen.

• CCMenuItemFont, ki gumb izrise kot niz znakov s pomocjo razreda CCLabelTTF.

• CCMenuItemAtlasFont, ki gumb izrise kot niz znakov s pomocjo razreda

CCLabelAtlas.

• CCMenuItemToggle, ki ga kreiramo z vec obstojecimi objekti CCMenuItem. Ob

vsakem pritisku, se trenutno prikazani objekt CCMenuItem zamenja z naslednjim v

takem vrstnem redu, kot smo jih podali ob kreiranju objekta CCMenuItemToggle.

CCLabel

Kadar bomo zeleli prikazati niz znakov, bomo uporabili razred CCLabelTTF ali razred

CCLabelBMFont. Prvi uporablja TTF1 tip pisave za prikaz niza, zato je enostaven za

uporabo, vendar pocasen, saj ob vsaki spremembi niza na novo ustvari teksturo. Drugi

razred, CCLabelBMFont, razsirja razred CCSpriteBatchNode, ki ga bomo predstavili v

nadaljevanju. Da bi lahko uporabili razred CCLabelBMFont, moramo vnaprej pripraviti

teksturo z vsemi znaki, ki jih potrebujemo. To je sicer zamudno in nam omogoca samo

doloceno velikost pisave, po drugi strani pa pridobimo na fleksibilnosti, kot je upo-

raba razlicnih barv ali sencenje pisave. Vsak znak tako uporabljene pisave je primerek

CCSprite, kar omogoca, da lahko posamicen znak rotiramo, skaliramo, obarvamo, pre-

maknemo ali pa mu spremenimo prosojnost. Kreiranje in spreminjanje niza je izredno

hitro, saj kreiranje nove teksture ni potrebno.

Pri kreiranju ustrezne teksture za pisavo si lahko pomagamo z brezplacnima orodjema

Hiero [70] in Bitmap Font Generator [71]. Orodje bo, poleg teksture z zelenimi znaki,

kreiralo se tekstovno datoteko z informacijami o lokaciji in velikosti posameznih znakov

1TrueType je vektorski format pisave



v teksturi. Format datoteke je podprt v cocos2d. Primer uporabe orodja Hiero prika-

zuje slika 6.3, kjer smo ustvarili teksturo z malimi in velikimi crkami slovenske abecede

ter stevilkami. Znake smo obarvali z barvnim prelivom, z rdece na rumeno. Program

je uspel znake razporediti tako, da je tekstura velika 256×128 tock, kljub izbrani vecji

pisavi.

Slika 6.3: Uporabniski vmesnik programa Hiero.

CCSprite

Sprite je po definiciji dvodimenzionalna slika ali animacija, ki je del scene. Za prikaz

spritov uporabljamo razred CCsprite, ki je najpogosteje uporabljen razred v cocos2d.

Primerek razreda CCSprite lahko ustvarimo na vec nacinov, najlazjega pa prikazuje

izvorna koda 6.1. V tem primeru se slika sprva nalozi v teksturo tipa CCTexture2D,

na podlagi katerega se ustvari objekt CCsprite. Razred CCsprite deduje od razreda

CCNode, zato se privzeto nahaja v tocki (0,0) glede na starsa, sidrno tocko pa ima v

srediscu. Sidrna tocka (angl. anchor point) doloca, kateri del slike se bo nahajal na

tocki, ki jo bomo dolocili za lokacijo, hkrati pa je to tudi tocka, okoli katere se bo

izvedla morebitna rotacija in druge transformacije.

1 CCSprite* sprite = [CCSprite spriteWithFile:@"image.png"];

2 [self addChild:sprite ];

Izvorna koda 6.1: Najenostavnejsi nacin kreiranja primerka CCSprite.

Poglejmo si se, na kaj je treba paziti pri kreiranju objektov CCsprite, ce uporabimo

nacin, kot prikazuje izvorna koda 6.1 in zakaj taksen nacin obicajno ni najboljsi.



Vsaka slika, ki jo uporabimo v iOS, mora imeti taksno dimenzijo, da sta tako

sirina kot visina potenci stevila 2 in ne presegata 1024 tock oziroma 2048 tock

na napravah tretje generacije. V primeru, da se tega pravila ne drzimo, bo kre-

irana tekstura toliko vecja, da bo ustrezala omenjenim kriterijem. V praksi to

pomeni, ce na primer nalagamo 32 bitno sliko velikosti 130×260 tock, bo slika

nalozena v teksturo velikosti 256×512 tock in bo tako namesto 132kB zasedla 512kB

pomnilnika. To omejitev je potrebno upostevati ze pri graficni zasnovi igre. V

primeru, da kreiramo vec spritov, ki imajo skupno ime datoteke, cocos2d poskrbi, da

je v pomnilniku nalozena samo ena tekstura in da vsi spriti uporabljajo enako teksturo.

CCSpriteBatchNode

V primeru, da veckrat izrisemo isto teksturo, lahko uporabimo razred

CCSpriteBatchNode. S pomocjo tega razreda je potrebno strojno opremo samo

enkrat pripraviti na izris dolocene teksture in samo enkrat obnoviti stanje, ko koncamo

z izrisom. S tem mocno izboljsamo zmogljivost. Problem pri uporabi tega razreda

je, da lahko urejamo globino sprita samo znotraj sloja CCSpriteBatchNode. Poleg

tega lahko razred vsebuje samo sprite, ki uporabljajo isto teksturo. Omenjenima

problemoma se delno izognemo tako, da zdruzimo vec slik v eni sami teksturi. Izvorna

koda 6.2 prikazuje primer uporabe razreda CCSpriteBatchNode. V tem primeru smo

ustvarili en primerek tega razreda, na katerega smo dodali vec objektov tipa CCSprite,

ki so kreirani z isto teksturo.

1 CCSpriteBatchNode* batch = [CCSpriteBatchNode

batchNodeWithFile:@"bullet.png"];

2 [self addChild:batch ];

3 for (int i = 0; i < 100; i++) {

4 CCSprite* sprite = [CCSprite spriteWithFile:@"bullet.png"

];

5 [batch addChild:bullet ];

6 }

Izvorna koda 6.2: Primer uporabe razreda CCSpriteBatchNode.

Pri kreiranju teksture, ki vsebuje vec slik, si lahko pomagamo z orodjem Zwoptex.

Poleg placljive razlicice orodja, je na voljo tudi brezplacana razlicica [72]. Orodje



je uporabno predvsem zaradi dveh lastnosti. Prvic, da nam pomaga pri iskanju

optimalne razporeditve slik, in drugic, da poleg teksture generira se XML dokument

z informacijami o posamicnih slikah. Nalaganje omenjenega tipa dokumenta pod-

pira razred CCSpriteFrameCache. To omogoci, da se na posamicne slike znotraj

teksture sklicujemo enostavno z njihovim originalnim imenom, ne da bi se ukvarjali

s tem, kje znotraj teksture se dejansko nahajajo, kako so velike, itd. S klicem

metode spriteFrameByName: nato pridobimo okvir slike oziroma primerek razreda

CCSpriteFrame, na podlagi katerega lahko enostavno ustvarimo objekt CCSprite.

CCAction

Razredi za animiranje v cocos2d so izpeljani iz razreda CCAction. Animiranje la-

stnosti izrisljivih objektov ni njihov edini namen. Spreminjajo lahko tudi lastno-

sti, ki ne morejo imeti vec vmesnih vrednosti. Primer taksne lastnosti je lastnost

visible, ki ji lahko nastavimo samo dve razlicni vrednosti, in sicer YES ali NO. Kon-

kretni ucinki, s katerimi animiramo lastnosti izrisljivih objektov, dedujejo od enega

izmed dveh razredov. Tisti, ki lastnosti spreminjajo postopoma, dedujejo od razreda

CCActionInterval, preostali pa od razreda CCActionInstant.

V primerjavi s Core Animation, kjer smo podali ime lastnosti, ki jo zelimo animi-

rati, definira cocos2d za vsak tip animacije drug razred. Razredi cocos2d s koncnico

By, spremenijo trenutne vrednosti atributov za kolicino, ki smo jo dolocili, medtem

ko razredi s koncnico To spremenijo trenutne vrednosti atributov do izbrane kolicine.

Izvorna koda 6.3 prikazuje primer dveh animacij. Animacija z razredom MoveBy bo

s spreminjanjem lastnosti position, v dveh sekundah s konstantno hitrostjo prema-

knila objekt sprite glede na trenutno lokacijo, za 50 tock v desno in 10 tock navzgor.

Animacija z razredom MoveTo bo namesto animiranja premika za doloceno kolicino,

animirala premik na izbrano lokacijo (50,10).

1 [sprite1 runAction: [CCMoveBy actionWithDuration :2 position

:ccp (50 ,10) ]];

2 [sprite2 runAction: [CCMoveTo actionWithDuration :2 position

:ccp (50 ,10) ]];

Izvorna koda 6.3: Osnovni primer animacije s cocos2d.

Med razredi, ki dedujejo od CCActionInterval, najdemo posebne razrede, ki nam

omogocajo sestavo kompleksnejsih animacij (kompozicije), pri cemer sestavljeno ani-



macijo se vedno obravnavamo enako kot posamicno. Za sestavljanje animacije imamo

na voljo naslednje razrede: CCSequence, CCSpawn, CCRepeat in CCRepeatForever.

CCSequence podane ucinke izvaja v zaporedju, CCSpawn pa jih izvaja hkrati. CCRepeat

ucinek ponovi kolikokrat zelimo. CCRepeatForever pa ucinek ponavlja tako dolgo, do-

kler ga ne ustavimo. Izvorna koda 6.4 prikazuje primer animacije, ki bo objekt v dveh

sekundah povecala na dvojno velikost trenutne, za tem pa se nadaljnji dve sekundi

premikala za dolocen vektor in hkrati rotirala za dolocen kot. Celotna animacija se

nato se enkrat ponovi.

1 id actionRotate = [CCRotateBy actionWithDuration: 2 angle:

720];

2 id actionMove = [CCMoveBy actionWithDuration :2 position:

ccp (180 ,180)];

3 id actionScale = [CCScaleBy actionWithDuration :2 scale

:2.0];

4 id action1 = [CCSpawn actions:actionRotate , actionMove , nil

];

5 id action2 = [CCSequence actions:actionScale , action1 , nil

];

6 id action3 = [CCRepeat actionWithAction:action2 times :2];

7 [sprite runAction: action3 ];

Izvorna koda 6.4: Primer sestavljene animacije.

Podobno kot Core Animation tudi cocos2d pri animiranju lastnosti omogoca spremi-

njanje casovnega poteka animacij. Pri Core Animation smo to dolocili s konstanto, ki

je dolocala funkcijo casovnega poteka, pri cocos2d pa je koncept nekoliko drugacen. Za

spreminjanje casovnega poteka uporabimo posebne razrede za sestavljanje animacij, ki

imajo predpono CCEase. To so posebni razredi za gradnjo kompozicije animacije s ka-

terimi spremenimo casovni potek. V primerjavi s Core Animation, podpira ogrodje co-

cos2d vecje stevilo razlicnih moznih casovnih potekov animacije. Nekatere izmed njih,

ki jih v ogrodju Core Animation ne moremo ustvariti, prikazuje slika 6.4. Poleg tega

nekateri razredi za spreminjanje casovnega poteka, podpirajo dodatne parametre. Pri-

meri teh razredov so: CCEaseElasticIn, CCEaseElasticOut in CCEaseElasticInOut,

ki jim lahko dolocimo stopnjo elasticnosti preko parametra period.



Slika 6.4: Posebne funkcije spreminjanja casovnega poteka v cocos2d [73].

cocos2d podpira se posebne vrste ucinkov, ki namesto spreminjanja obicajnih lastnosti,

kot so opacity, position ali scale, spreminja lastnost grid. Ta lastnost omogoca

pomnjenje mreze tekstur, ki bodo uporabljene pri izrisu objekta v primeru, da upo-

rabljamo posebne ucinke. Posebni ucinki spreminjajo omenjeno mrezo tekstur in tako

ustvarijo razlicne vizualne ucinke. Slika 6.5b prikazuje objekt 6.5a, nad katerim smo

uporabili ucinek CCRipple3D z mrezo 32×24.

(a) Objekt brez sprememb (b) Ucinek CCRipple3D nad objek-

tom

Slika 6.5: Ucinek CCRipple3D.

Ce zelimo pred ali po doloceni animaciji izvesti klic dolocene metode, uporabimo razred

z imenom CCCallFunc, ki je izpeljan iz razreda CCActionInstant. Razred uporabimo

v kombinaciji z razredom CCSequence, kot kaze primer kode 6.5. Uporabimo lahko tudi



iz razreda CCCallFunc izpeljan razred CCCallFuncN ali pa se dodatno razsirjen razred

CCCallFuncND. Prvi omogoca, da metoda, ki jo poklice, prejme posiljatelja oziroma

objekt, nad katerim se je animacija odvijala. Drugi pa omogoca, da funkcija poleg

posiljatelja prejme se kazalec na podatke.

1 id actionBy = [CCMoveBy actionWithDuration: 2 position: ccp

(80 ,80)];

2 id actionCallFunc = [CCCallFunc actionWithTarget:self

selector:@selector(doATask)];

3 id actionSequence = [CCSequence actions: actionBy ,

actionCallFunc , nil];

Izvorna koda 6.5: Primer uporabe CCCallFunc razreda.

CCParticleSystem

Razred CCParticleSystem je namenjen posebnim vizualnim ucinkom, ki jih re-

aliziramo z oddajanjem velikega stevila majhnih delcev, kar imenujemo sistem

delcev. Primeri taksnih ucinkov so eksplozije, ogenj, dim, dez, iskrenje, ipd.

CCParticleSystemPoint in CCParticleSystemQuad sta razreda, ki razsirjata razred

CCParticleSystem. Uporabili ju bomo za ucinke z delci. Sistemu lahko dolocimo

naslednje lastnosti:

• emissionRate, ki doloca stevilo delcev na sekundo,

• duration, s katerim dolocimo, koliko sekund naj sistem deluje,

• texture, s katerim dolocimo teksturo, ki predstavlja delce.

Dolocimo lahko se specificne lastnosti za delce, med katerimi so:

• startSize in endSize, ki dolocata velikost delca na zacetku in koncu njego-

vega zivljenskega cikla. Za koliko lahko velikosti odstopajo od tistih dolocenih z

startSize in endSize dolocimo s startSizeVar in endSizeVar.

• startColor, endColor, startColorVar in endColorVar, ki dolocajo barvo delca

in prosojnost na enak nacin, kot prej omenjene lastnosti za velikost.



• startSpin, endSpin, startSpinVar in endSpinVar, s katerimi dolocimo vrtenje

delca.

• life in lifeVar, s katerima dolocimo zivljenjsko dobo delca v sekundah.

• angle in angleVar, s katerima dolocimo zacetni kot delca.

• position in posVar, ki dolocata lokacijo, kjer se delci oddajajo (angl. emitter).

Sistem lahko deluje v dveh nacinih. Privzet nacin je imenovan gravity, nanj pa vplivajo

naslednje lastnosti sistema:

• gravity, ki doloca gravitacijo sistema delcev,

• speed in speedVar, ki dolocata zacetno hitrost delca,

• tangencialAccel in tangencialAccelVar, s katerima dolocimo tangencialni po-

spesek,

• radialAccel in radialAccelVar, s katerima dolocimo radialni pospesek.

Od razlicice 0.99.3 je poleg nacina delovanja sistema, imenovanega gravity, na vo-

ljo se nacin imenovan radius. Nacin delovanja spreminjamo s pomocjo metode

setEmitterMode:. Lastnosti, ki vplivajo na delovanje sistema kadar je v nacinu radius,

so:

• startRadius, startRadiusVar, endRadius in endRadiusVar, ki dolocajo

zacetno in koncno oddaljenost delcev,

• rotatePerSecond in rotatePerSecondVar, ki dolocata hitrost vrtenja.

Za nekatere najbolj pogoste ucinke lahko uporabimo katerega od vnaprej pripra-

vljenih razredov za sistem delcev in tako prihranimo nekaj casa, ki bi nam ga

sicer vzelo iskanje zelenih nastavitev sistema. Ti razredi so: CCParticleFire,

CCParticleFireworks, CCParticleSun, CCParticleGalaxy, CCParticleFlower,

CCParticleMeteor, CCParticleSpiral, CCParticleExplosion, CCParticleSmoke,

CCParticleSnow in CCParticleRain.

V primeru, da zelimo uporabiti bolj specificen sistem delcev, moramo poiskati ustre-

zne nastavitve sistema delcev. Pomagamo si lahko s programom Particle Designer


6.3. SLIKOVNI FORMATI ZA TEKSTURE Stran 55

[74], katerega vmesnik prikazuje slika 6.6. Program omogoca, da spreminjamo razlicne

parametre sistema delcev in hkrati opazujemo, kako vplivajo na delovanje sistema.

Nastavitve parametrov je mogoce izvoziti v taksen format datoteke, ki je podprt v co-

cos2d. Tako lahko neposredno na podlagi datoteke kreiramo sistem delcev z lastnostmi,

ki smo jih dolocili v programu Particle Designer.

Slika 6.6: Uporabniski vmesnik programa ParticleDesigner.

6.3 Slikovni formati za teksture

Obicajni formati za kompresijo slik, kot sta JPEG in PNG, niso primerni za uporabo

kot teksture, zaradi nacina stiskanja, ki ga uporabljajo. Strojna oprema bi morala v

tem primeru veckrat dostopati do pomnilnika, da bi pridobila podatke o barvi dolocene

tocke. Nakljucen dostop do tock teksture je namrec ena izmed zahtev strojne opreme,

da lahko teksture uporablja. Datoteke JPEG in PNG je zaradi tega pred uporabo

potrebno pretvoriti v zapis brez kompresije. Uporaba formata JPEG ali PNG zmanjsa

velikost datoteke, vendar pretvorba v obliko brez kompresije upocasni kreiranje teks-

ture. Taksna tekstura med delovanjem igre zasede enako pomnilnika kot tekstura, ki

je ustvarjena na podlagi slike brez kompresije.

Boljsa izbira za shranjevanje slik, ki bodo namenjene teksturam, je slikovni format

PVRTC, ki omogoca dolocen nivo kompresije z izgubnim stiskanjem. Slikovni format

PVRTC ne omogoca taksnega nivoja stiskanja datotek, kot ga omogocata formata

PNG ali JPEG. Glavna prednost uporabe slikovnega formata PVRTC je, da ga lahko

neposredno uporabimo kot teksturo, saj je podprt v graficni strojni opremi uporabljeni

v napravah iOS. Za pridobitev barve dolocene tocke teksture, kjer tekstura uporablja

6.3. SLIKOVNI FORMATI ZA TEKSTURE Stran 55


kompresijo PVRTC, bo poskrbelo vgrajeno vezje brez negativnega vpliva na zmoglji-

vost igre [75, 73].

iOS SDK vkljucuje program texturetool, s katerim lahko slike razlicnih slikovnih for-

matov pretvorimo v format PVRTC [50]. Ker ima program mocno omejen nabor na-

stavitev, je program TexturePacker [76] boljsa izbira. TexturePacker omogoca izvoz v

datoteko PVR. Ta lahko vsebuje teksturo PVRTC s kompresijo ali teksturo, ki zmanjsa

velikost datoteke, na racun zmanjsanja stevila bitov za dolocanje barve in prosojno-

sti posamezne tocke. Ti posebni formati so: RGBA8888, RGBA4444, RGBA5555,

RGBA5551 in RGB565. Znaki R, G, B in A dolocajo kratice za rdeco (R), zeleno

(G), modro (B) barvo in prosojnost (A). Pripadajoce stevilke pa dolocajo, s kolikomi

biti bomo opisali posamezne, prej omenjene, osnovne barve in prosojnost. Na primer,

format RGBA5551 doloca, da bomo vsako izmed osnovnih barv opisali s 5 biti, prosoj-

nosti pa namenimo 1 bit. Na nekaterih teksturah, na primer na ozadju, ne potrebujemo

prosojnosti, zato je v tem primeru smiselna izbira RGB565, ki zasede toliko prostora

kot RGB4444 in nudi vec podatkov o barvi tock kot format RGBA5555. V primeru,

da uporabimo kompresiran format PVRTC, imamo na voljo dve moznosti. PVRTC2

uporabi za vsako tocko 2 bita in tako doseze nivo kompresije 16:1, v primerjavi z nesti-

snjenim 32bitnim formatom RGBA. PVRTC4 uporabi 4 bite na tocko in doseze nivo

kompresije 8:1.

Datoteke, ki uporabljajo omenjene formate, zasedejo v primerjavi z JPEG in PNG

vec prostora, zato cocos2d omogoca uporabo dodatne kompresije datotek PVR. Prvi

nacin dodatne kompresije PVR dosezemo s pomocjo programa gzip, drugi nacin pa

dosezemo z uporabo programa ccz, ki ga dobimo ob namestitvi ogrodja cocos2d. V

obeh primerih sta datoteki podobnih velikosti, vendar se datoteke ccz nalozijo nekoliko

hitreje kot tiste stisnjene s programom gzip. Podrobne podatke o casu nalaganja tekstur

razlicnih formatov na razlicnih napravah iOS, merjene v sekundah, prikazuje tabela 6.2.

V vseh primerih nalagamo teksturo locljivosti 1024 x 1024. Teksture PVR so v formatu

RGBA4444.


6.4. POGONA ZA FIZIKO BOX2D IN CHIPMUNK Stran 57

PNG PVR PVR.GZ PVR.CCZ

iPod Touch 1. generacije 0.76 0.44 0.24 0.24

iPod Touch 2. generacije 0.52 0.16 0.17 0.15

iPhone 3GS 0.25 0.11 0.09 0.08

iPad 0.15 0.03 0.06 0.05

iPod Touch 4 0.19 0.04 0.07 0.06

Tabela 6.2: Cas v sekundah, ki je potreben za nalaganje tekstur razlicnih slikovnihformatov na razlicnih napravah iOS [73].

Velikost in format datoteke za teksture ne vplivata samo na cas nalaganja, temvec tudi

na zmogljivost aplikacije. Tabela 6.3 prikazuje zmogljivost sistema delcev na napravi

iPod Touch 2. generacije. Sistem sestavlja 2500 delcev. Zmogljivost sistema delcev

je prikazana v obliki stevila slicic na sekundo (FPS). Test je bil izveden na podlagi

delcev stirih razlicnih velikosti, ki so bili nalozeni kot 32 bitna in 16 bitna tekstura

brez kompresije ter kot 4bitna tekstura PVRTC [73].

32 bitna tekstura 16 bitna tekstura 4 bitna tekstura PVRTC

4×4 tock 60 60 60

8×8 tock ≈42 ≈44 60

32×32 tock ≈12 ≈12 ≈20

64×64 tock ≈4 ≈4 ≈6

Tabela 6.3: Priblizno stevilo slicic na sekundo, ki jih dosega sistem delcev z razlicnimtipom in velikostjo teksture [73].

6.4 Pogona za fiziko Box2D in Chipmunk

Box2D [77] in Chipmunk [78] sta dva pogona za fiziko, ki sta vkljucena v ogrodje

cocos2d. Z njuno pomocjo lahko definiramo telesa in jim dolocimo nekatere fizikalne

lastnosti, pogon pa bo taksna telesa indirektno premikal in rotiral s preracunavanjem

sunkov, sil in navorov. Telesa so dolocena z enim ali vec geometrijskimi liki, med

katerimi sta najpogostejsa lika krog in pravokotnik, uporabimo pa lahko tudi mnogo-

kotnik, ki ni konkaven. Telesa so lahko staticna ali dinamicna. Med staticnimi telesi ne

more priti do trka, saj se ne premikajo. To informacijo lahko pogon izkoristi v namene

optimizacije in preskoci preverjanje trka med dvema staticnima telesoma. Dinamicno

6.4. POGONA ZA FIZIKO BOX2D IN CHIPMUNK Stran 57


telo lahko trci z drugim dinamicnim telesom ali staticnim telesom. Lastnosti, ki poleg

lokacije dolocajo dinamicno telo, so masa ali gostota, koeficient trenja in restitucijski

koeficient trka. Slednji doloca razmerje med relativno hitrostjo po trku in relativno

hitrostjo pred trkom. Dinamicna telesa je s pomocjo spojev mogoce povezati z drugim

dinamicnim ali staticnim telesom in tako omejiti gibanje teles na razlicne nacine [80].

Oba pogona, Box2D in Chipmunk, omogocata podobne funkcionalnosti, vendar med

njima obstajajo nekatere razlike. Prva najbolj ocitna razlika je ta, da je Box2D napisan

v jeziku C++, Chipmunk pa v jeziku C. Box2D se zaradi tega nekoliko bolje integrira

v objektno orientiran Objective-C. Poleg C++ implementacije obstajajo razlicice tudi

za druga programska okolja in jezike, med katerimi so C#, ActionScript, Python in

Java, zato lahko Box2D uporabimo tudi na napravah Android. Med drugim ima tudi

nekatere funkcionalnosti, ki jih Chipmunk ne ponuja. Ena taksnih funkcionalnosti je,

da lahko resimo problem hitro premikajocih se teles, kjer se lahko zgodi, da zaradi

hitrosti telesa, trka z obicajnim pristopom preverjanja trkov sploh ne bi zaznali. Slika

6.7 prikazuje vmesnik igre Paper Bridge, ki se zanasa na pogon Box2D.

Slika 6.7: Vmesnik igre Paper Bridge za iOS, ki uporablja pogon za fiziko Box2D.

Pogon Chipmunk je del ogrodja cocos2d dlje casa kot Box2D, na voljo pa je

tudi knjiznica Chipmunk SpaceManager [79], ki Chipmunk pogonu dodaja vmesnik

Objective-C. Poleg njega obstajajo tudi implementacije pogona Chipmunk za nasle-

dnje programske jezike: Ruby, Python in Haskell [80, 81, 82].


Stran 59

Poglavje 7

Optimizacija in najboljse prakse

Eden izmed ciljev pri razvoju igre je, da omogocimo dobro delovanje le-te na kar najvec

razlicnih napravah. Da bi lahko to dosegli, moramo izvesti razlicne optimizacije in

slediti uveljavljenim dobrim praksam. Poleg dobre zmogljivosti in podpore razlicnim

napravam iOS, lahko s tem dosezemo tudi druge pozitivne ucinke. Eden izmed taksnih

je nizja poraba energije, s cimer podaljsamo cas delovanja naprave. V nadaljevanju

bomo predstavili razlicna priporocila za izpolnitev omenjenih ciljev.

7.1 Najboljse prakse za cocos2d

Scene

Pri upravljanju s scenami moramo biti pozorni na porabo pomnilnika. Kadar sceno

nadomescamo z novo, se moramo zavedati, da sta v pomnilniku pred zamenjavo

potrebni obe, trenutna in nova. To seveda pomeni visjo porabo pomnilnika za kratek

cas. Na porabo le-tega moramo paziti tudi pri dodajanju scen na sklad razreda

CCDirector, saj morajo biti vse scene na skladu nalozene v pomnilniku.

Posebni ucinki

Za posebne ucinke, se posebej za tiste, ki so sestavljeni iz vec drugih, je priporocljivo,

da jih shranimo. Tako jih lahko kasneje ponovno uporabimo. Ustvarjanje instanc

kompleksnih sestavljenih ucinkov je namrec lahko zelo pocasno, saj zahteva veliko

klicev za rezervacijo pomnilnika.

Stran 59

Stran 60 POGLAVJE 7. OPTIMIZACIJA IN NAJBOLJSE PRAKSE

Kreiranje CCNode objektov

Instance razredov CCSprite, CCLabel in CCLayer ter instance drugih razredov,

izpeljanih iz CCNode, je najbolje kreirati vnaprej v metodi za inicializacijo, imenovani

init. Izogibati se moramo inicializaciji taksnih razredov v metodah, ki se klicejo

periodicno, na primer ob vsakem izrisu objekta. Pristop z inicializacijo vnaprej ne

upocasnjuje izvajanja igre s kreiranjem instanc CCNode, ima pa negativen vpliv na

porabo pomnilnika, saj redko potrebujemo vse vnaprej pripravljene objekte hkrati.

Katere objekte kreirati vnaprej in katere po potrebi, se razvijalec lahko odlociti sam,

pri cemer mora upostevati omejeno kolicino pomnilnika, ki je na voljo.

Periodicni klici metod

Za periodicne klice metod ne smemo uporabljati razreda NSTimer s sloja Cocoa Touch,

ki bi ga sicer uporabljali, ce bi gradili aplikacijo Cocoa Touch. cocos2d ima lasten

mehanizem za periodicne klice. Le-te v objektih CCNode registriramo z metodami, ki

se pricnejo z imenom schedule. Prednosti omenjenega mehanizma so:

• podpiranje ze omenjene funkcionalnosti za pavzo razreda CCDirector,

• samodejna aktivacija periodicnih klicev v objektu CCNode, kadar je objekt del

scene, ki se trenutno izrisuje,

• samodejna deaktivacija periodicnih klicev, kadar objekt CCNode ni vec del scene,

ki se trenutno izrisuje,

• informacija o casu, ki je pretekel od prejsnjega periodicnega klica (cas delta).

Izris in spreminjanje stanj objektov

Metodo draw objektov CCNode bomo predefinirali izkljucno za potrebe izrisovanja. V

primeru, da bi v tej metodi spreminjali dolocene lastnosti objekta, se bi ta koda izvedla

pri vsakem izrisu objekta, kar obicajno ni zazeleno, funkcionalnost za pavzo pa ne bi

delovala pravilno. Vendar, ce izrisa ne izvedemo v metodi draw, temvec v doloceni

metodi, ki se periodicno poklice, bo zaradi funkcionalnosti za pavzo in poljubne

frekvence periodicnih klicev obnasanje objekta napacno. Pri izrisu izven metode

draw, se pojavi se dodaten problem, in sicer, da transformacije nimajo vpliva na


7.2. OPTIMIZACIJA DELOVANJA POGONA ZA FIZIKO BOX2D Stran 61

izris. To pomeni, da lastnosti kot so rotate, scale, itd., pri izrisu ne bodo upostevane.

CCSpriteBatchNode

Ceprav smo razred CCSpriteBatchNode ze predstavili, se enkrat poudarimo, da ta

omogoca kreiranje objektov CCSprite na podlagi velike teksture, ki zdruzuje vec

dejanskih tekstur. Taksen pristop sicer prinese nekaj dodatne kompleksnosti, ki pa

jih odtehtajo velike prednosti v zmogljivosti. Od razreda CCSpriteBatchNode deduje

razred CCLabelBMFont, ki je namenjen prikazu besedila in je po zmogljivosti veliko

boljsa izbira od razreda CCLabelTTF.

Teksture

Kako lahko z izbiro ustreznega slikovnega formata zmanjsamo porabo pomnilnika in

pohitrimo delovanje, smo ze predstavili. Nismo pa se pojasnili, da se vsaka tekstura,

ki je bila kdajkoli uporabljena, tudi ce je trenutno ne uporablja noben objekt, se vedno

nahaja v pomnilniku. Taksen pristop po eni strani pohitri kreiranje novih objektov s

teksturo, ki je ze bila kdaj uporabljena, po drugi strani pa poveca porabo pomnilnika.

Za pomnjenje tekstur samodejno skrbi razred CCTextureCache. Razred omogoca se

odstranitev tekstur, ki trenutno niso v uporabi ali odstranitev vseh tekstur. Odstra-

nitev neuporabljenih je smiselna na primer v metodi dealloc objekta CCScene, saj

je malo verjetno, da bomo se kdaj potrebovali teksture, ki v tistem trenutku niso v

uporabi. Metodo za odstranitev vseh tekstur uporabimo samo takrat, kadar se sprozi

metoda didReceiveMemoryWarning, ki nas opozarja na pomanjkanje pomnilnika [73].

7.2 Optimizacija delovanja pogona za fiziko Box2D

Box2D je implementiran tako, da za vse izracune uporablja metricni merski sistem.

Torej, za dimenzije uporablja metre, za maso kilograme, itd. Box2D deluje optimalno,

ce uporabljamo telesa, ki so velika med 0,1 in 10 metri. Najboljse pa je, da so telesa

velika blizu enega metra. Box2D deluje tudi, ce uporabimo telesa, ki niso optimalnih

velikosti, vendar lahko to privede do nepredvidljivega obnasanja. Objekti na zaslonu so

obicajno vecji od 10 tock, zato potrebujemo ustrezno pretvorbo v metre. To pretvorbo

naredimo tako, da vsako dimenzijo ali lokacijo delimo z doloceno konstanto, preden

podatek uporabimo v Box2D. Konstanta je pogosto poimenovana PTM RATIO in

7.2. OPTIMIZACIJA DELOVANJA POGONA ZA FIZIKO BOX2D Stran 61


predstavlja stevilo tock na meter. Dobra izbira za vrednost konstante je 32. Iz tega

sledi, da bo zelo majhen objekt velikosti 8×8 tock velik 0,125×0,125 metra, ogromen

objekt velikosti 256×256 tock pa bo velik 8×8 metrov [80].

7.3 Optimizacija na nivoju prevajalnika

Razvojno okolje Xcode omogoca spreminjanje stevilnih optimizacij za prevajalnik. Na-

stavitve najdemo pod lastnostmi projekta, in sicer pod zavihkom Build. Najbolj ocitna

nastavitev, ki vpliva na zmogljivosti, je nivo optimizacije prevajalnika (angl. optimi-

zation level). Lahko jo nastavimo od vrednosti brez optimizacije (-O0), do polne opti-

mizacije (-O3). Poleg tega imamo se moznost izbire optimizacije porabe pomnilnika (

-Os), ki je v vecini primerov najboljsa izbira.

Uporaba optimizacije ima nekaj negativnih posledic, in sicer onemogoci uporabo raz-

hroscevalnika ter podaljsa cas prevajanja aplikacije. Najelegantnejsa resitev prvega

problema je, da poleg privzetih konfiguracij za gradnjo aplikacije debug in release, za

gradnjo optimizirane aplikacije ustvarimo novo konfiguracijo. Ta resuje tudi pocasnejse

prevajanje z optimizacijami, saj bomo aplikacijo vecino casa se vedno prevajali v nacinu

za razhroscevanje.

Uporaba optimizacije lahko razkrije dolocene napake v aplikaciji in tako povzroci, da

se le-ta zrusi. Ce se to zgodi, je ukrep, da onemogocimo optimizacijo, napacen. Opti-

mizacija namrec ne povzroca napak, temvec zgolj pripomore k razkritju le-teh v apli-

kaciji. Koncni uporabniki bodo uporabljali aplikacijo prevedeno z optimizacijo, zato je

kljucno, da je optimizirana aplikacija temeljito preverjena, preden jo objavimo.

Na velikost in hitrost izvajanja aplikacij vpliva tudi nastavitev imenovana Thumb,

uporabljena pri prevajanju aplikacije za arhitekturo ARM1. Prevajanje z omogoceno

nastavitvijo Thumb v splosnem ustvari manjso in hitrejso aplikacijo. To pa ne velja

za aplikacije, ki veliko racunajo s stevili s plavajoco vejico, saj so lahko pocasnejse

[58]. cocos2d priporoca, da naj bo Thumb nastavitev za procesorje tipa ARMv6 one-

mogocena, za ARMv7 pa omogocena. Predloge cocos2d so privzeto pripravljene tako,

da se prevajanje izvede za obe omenjeni arhitekturi, pri cemer je nastavitev Thumb ze

nastavljena optimalno [73].

Funkcije, ki so napisane v jeziku C in kot argument prejmejo kazalec, preko katerega

bomo samo brali podatke, vedno definirajmo kot konstanto. Primer definicije taksne

132 bitna RISC arhitektura procesorjev


7.4. ORODJE INSTRUMENTS Stran 63

funkcije prikazuje koda 7.1, kjer bomo komponente vektorja inVec samo brali, v vektor

result pa zapisali rezultat. Prevajalnik lahko s taksnim nacinom definiranja parame-

trov funkcije izvede dodatne optimizacije [58].

1 void NormalizeVector(const Vector3D *inVec , Vector3D *

result);

Izvorna koda 7.1: Definicija parametra kot konstante za dodatne optimizacije.

7.4 Orodje Instruments

Instrument je prirocno orodje za zbiranje podatkov o zmogljivosti in obnasanju apli-

kacije. Orodje zbira podatke o aplikaciji med njenim delovanjem in jih prikaze v

obliki grafa ter tabele. Hkrati lahko zbira podatke o razlicnih vidikih delovanja aplika-

cije. Nekateri izmed teh vidikov so: obremenjenost glavnega procesorja, obremenjenost

graficnega procesorja in poraba pomnilnika.

Orodje uporabimo neposredno iz razvojnega okolja Xcode. Ce smo izbrali spremljanje

zasedenosti pomnilnika, ki ni vec v uporabi (angl. memory leak), se nam bo na grafu

pojavil stolpec, ko se bodo taksni objekti pojavili. S klikom na stolpec bomo lahko

prisli do podrobnejsih informacij o tem objektu. Med temi podatki je tudi sklad klicev,

s pomocjo katerega bomo lahko prepoznali, kje se je problematicen objekt ustvaril [45].

7.4. ORODJE INSTRUMENTS Stran 63

Stran 64 POGLAVJE 8. IGRA TRAFFIC MASTER

Poglavje 8

Igra Traffic Master

Namen prakticnega dela diplomske naloge je bil razvoj igre z ogrodji, ki smo jih pred-

stavili v diplomskem delu. Poleg tega smo zeleli igro razviti v skladu s pristopom k

razvoju iger. Rezultat je bila igra Traffic Master.

8.1 Stopnje razvoja iger

Preden lahko z implementacijo pricnemo, se moramo seznaniti s pristopom k razvoju

iger. Razvoj vsake igre je sestavljen iz vec stopenj. Te lahko porazdelimo v obliki crke

v, kot prikazuje slika 8.1. Taksna razporeditev pomeni, da imamo na zacetku projekta

najvec moznosti za kreativnost in spreminjanje zasnove igre brez vecjih stroskov, kar

pri kasnejsih stopnjah razvoja ni vec mogoce. Se vedno pa je mogoce dodati kaksen

koncept ali lastnost. Proti koncu razvoja so kakrsnekoli spremembe zasnove igre, razen

tistih, ki smo jih namenoma podprli, izredno drage.


8.2. KONCEPTUALIZACIJA Stran 65

Slika 8.1: Graficna predstavitev stopenj razvoja iger [83].

8.2 Konceptualizacija

Snovanje nacrta igre se zacne z idejo v nasih mislih, kjer ni omejitev ali pravil. Upo-

rabljamo domisljijo, predstavljamo si razlicne lastnosti in opcije, ki bi jih igra lahko

imela. Inspiracijo lahko crpamo iz razlicnih dogodkov in konceptov, ki na videz ni-

majo nic skupnega z naso igro. Ideje se nam lahko porodijo kjerkoli in kadarkoli, zato

je smiselno, da imamo vedno pri sebi kaksen pripomocek, da jih lahko zapisemo ali

shranimo. Scasoma, ko se navadimo na neprestano iskanje novih idej, bodo te postale

vedno boljse in tudi vedno vec jih bo. Pomembno je se, da ideje niso prevec neposredno

povezane z igrami.

Pisatelj, igralec in filmski reziser Stephen King pravi: “izvirnost dosezemo tako, da

obicajne stvari zdruzimo na neobicajen nacin”[84]. Enako velja za iskanje dobrih idej

za igre. Veliko stevilo idej samo po sebi namrec ni dovolj. Ideje zato med sabo kombi-

niramo in poskusamo najti smiselno kombinacijo [84]. Ena izmed tehnik, ki izkorisca

taksen pristop je, da vsako idejo zapisemo na koscek papirja, jih premesamo, nato pa

8.2. KONCEPTUALIZACIJA Stran 65


izberemo dve ali vec idej ter jih poizkusamo smiselno zdruziti.

Po zakljucku zbiranja idej le-te ovrednotimo in izberemo najboljsih deset. Ce pri

vrednotenju idej sodeluje skupina ljudi, je priporocljivo, da uporabimo tehniko ustvar-

jalnega pretresa (angl. brainstorming). Seznam najboljsih idej sprva skrajsamo na

najboljse tri in sele kasneje, po ponovni seji ustvarjalnega pretresa, izberemo najboljso

idejo, ki jo opisemo na kratko, z enim odstavkom. Cilj taksnega postopnega nacina

iskanja najboljse ideje je, da se ne osredotocimo prehitro na eno samo in s tem spre-

gledamo se morebitne boljse [83].

Na tej stopnji smo za razvoj igre zbrali razlicne ideje, pri cemer smo poskusali

upostevati posebne lastnosti platforme iOS. Ena izmed teh lastnosti je zaslon obcutljiv

na dotik. Nekatere igre to lastnost izkoriscajo za poseben za nacin igranja, kjer ele-

mentom s prstom dolocimo pot za gibanje. Omenjeno idejo smo zdruzili z idejo voznje

avtomobilov skozi krozisce. Tako se je pojavila ideja o igri Traffic Master.

8.3 Prototipiranje

Prototipiranje je jedro zasnove dobre igre, ki nam omogoca testiranje mehanike igre

v najosnovnejsi obliki. Zaradi taksnega nacina testiranja mehanike, ne posvecamo

pozornosti problemom povezanim s produkcijo, hkrati pa graficna podoba ne odvraca

nase pozornosti.

Igre lahko prototipiramo na dva nacina, in sicer s fizicnim ali programskim prototipom.

Pri fizicnem prototipu obicajno uporabimo svincnik in papir, lahko pa tudi druge mate-

riale iz resnicnega sveta. Programski prototipi so analogni fizicnim, s to razliko, da jih

ustvarimo z orodji za programiranje. Podobno kot fizicni prototipi, sluzijo predstavitvi

koncepta, zato grafiki in zvokom ne posvecamo posebne pozornosti. To bi sicer lahko

upocasnilo izgradnjo prototipa. Poleg tega obstaja nevarnost, da se prevec navezemo

na nase delo in posledicno nasprotujemo spreminjanju prototipa, kar pa je ravno v

nasprotju z idejo prototipiranja [83].

Na stopnji prototipiranja smo izdelali zelo preprost programski prototip, katerega vme-

snik prikazuje slika 8.2. Ta prototip nam omogoca, da s pritiskom na avtomobil in

premikanjem prsta izrisemo pot, po kateri se avtomobil nato premika. V prototipu

sta na voljo dva avtomobila. Za implementacijo prototipa smo uporabili naslednje

tehnologije:


8.4. DOKUMENT ZASNOVE IGRE Stran 67

• UIKit, za prikaz modela avtomobila,

• Core Graphics, za izris krivulje,

• Core Animation, za animacijo premikanja avtomobila po krivulji s konstantno

hitrostjo.

Slika 8.2: Preprost programski prototip igre Traffic Master.

Pri uporabi prototipa so se pokazali nekateri problemi, ki bi, ce le-tega ne bi izde-

lali, ostali neopazeni. Eden taksnih problemov je bil, da bi morala krivulja, ki jo je

avtomobil ze prevozil, sproti izginiti. Omenjeno lastnost smo zeleli preizkusiti, zato

smo prototip popravili, da je izrisana krivulja s premikanjem avtomobila izginjala. Se

eden izmed problemov, ki smo ga spregledali je, da igralcu nic ne omejuje voznje izven

cestisca. To seveda ni sprejemljivo, saj se zdi, kot da je slika krozisca v ozadju brez

pomena.

Prototip smo nato testirali se na fizicni napravi. Izkazalo se je, da prototip ni deloval

dovolj gladko. V casu razvoja bi igri, narejeni na taksen nacin, dodali se vec elementov,

posledicno pa bi delovala se slabse. Zaradi omenjenih razlogov smo se odlocili, da za

implementacijo igre ne uporabimo tehnologij Core Graphics in Core Animation.

8.4 Dokument zasnove igre

Po stopnji prototipiranja ustvarimo dokument zasnove igre (angl. game design docu-

ment), ki vsebuje opis koncepta, vmesnika, poteka in druge lastnosti igre. Pomembno

je, da s pripravo dokumenta zasnove igre ne pricnemo, preden s prototipom ne pre-

verimo veljavnosti koncepta. Dokument sluzi tudi kot osnova za komunikacijo med

clani ekipe ali kot dokument, ki ga lahko clani ekipe uporabljajo za razumevanje svoje

8.4. DOKUMENT ZASNOVE IGRE Stran 67


vloge pri izdelavi igre in opravljanju dela. Namen dokumenta zasnove igre ni nado-

mestitev sestankov in medosebne komunikacije. Prav tako dokument zasnove igre ni

koncen. Neprestano ga je potrebno posodabljati s spremembami, ki jih naredimo v

casu razvojnega procesa [83].

V skladu s pridobljenim znanjem iz stopnje prototipiranja ustvarimo preprost doku-

ment zasnove igre, ki ga prikazuje tabela 8.1. Pri ustvarjanju dokumenta smo se

zgledovali po dokumentu zasnove igre, kakrsnega uporabljajo v podjetju PosiMotion

[58].

Naslov Traffic Master

Opis igre V igri se samodejno ustvarjajo novi avtomobili, ki jim je potrebno

dolociti pot do ustreznega izvoza. Med avtomobili ne sme priti do

trka, sicer se igra zakljuci.

Podrobnosti

igre

Avtomobili v igri se bodo ustvarjali vedno hitreje, s tem pa bo

rasla tudi tezavnost igre. Obstajali bodo razlicno hitri avtomobili,

s cimer lahko se dodatno otezimo igro. Voznja izven krozisca bo

kaznovana tako, da se bo igra zakljucila, ce bodo avtomobili dlje

casa na zelenici. Dovoljen cas voznje izven cestisca bo v igri vedno

krajsi, to pa bo se eden izmed nacinov povecanja tezavnosti igre.

Platforma in

pogon igre

iOS, cocos2d

Uporabniski

vmesnik igre

Avtomobilom bomo dolocili tako, da bomo nanj pritisnili in s pre-

mikanjem prsta risali krivuljo, kateri bo avtomobil nato sledil. Ob

pritisku na avtomobil se bo le-ta zaustavil.

Informacije in

naslovi

- prikaz zacetnega zaslona z imenom igre

- meni, ki poleg igre nudi se navodila, informacije o avtorju, seznam

najboljsih igralcev

- maska za pavzo in zakljucek igre

Zvocni ucinki - glasba v ozadju v menija in igre

- zvocni ucinek pri pritisku na avtomobil in uspesni dolocitvi izhoda

- zvocni ucinek, ko avtomobil zapusti izvoz

- zvocni ucinek ob koncu igre

Tabela 8.1: Preprost dokument zasnove igre.


8.5. MODEL RAZVOJA Stran 69

8.5 Model razvoja

V popolnem svetu bi pri razvoju programske opreme sledili klasicnemu slapovnemu

modelu (angl. waterfall model), kjer imamo definirane vse potrebne zahteve, na podlagi

katerih lahko nacrtujemo in nato implementiramo ter testiramo programsko kodo. Za

razvoj iger taksen model ni primeren, saj se koraki v razvoju mnogokrat prekrivajo.

Programerji lahko namrec pogosto pricnejo z implementacijo, se preden je zasnova igre

izoblikovana. Na nacrt igre pa vplivajo tudi graficni elementi, zato morajo oblikovalci

iger (angl. game designer) pogosto pocakati na graficne oblikovalce, preden lahko

dokoncajo zasnovo igre. Poleg tega ne smemo pozabiti na narocnike, ki zelijo spremljati

razvoj igre in vnasati dolocene nove elemente ali lastnosti [85].

Na model razvoja lahko gledamo tudi z vidika testiranja igralnosti, ki odlocilno vpliva

na smer razvoja igre. Pri testiranju igralnosti ne gre za rigorozno iskanje programskih

napak v vsakem elementu igre, temvec za testiranje, kjer se poskusa ugotoviti, kako

igralec dozivlja igranje. S testiranjem igralnosti ne smemo cakati na konec razvoja,

saj je takrat ze prepozno, da bi igro bistveno spreminjali, ce ni dovolj zabavna ali

zanimiva. V izogib taksnemu scenariju se priporoca iterativen proces testiranja igral-

nosti, ovrednotenja testiranja in vnasanja popravkov, kot prikazuje slika 8.3. Proces

testiranja igralnosti bomo izvajali skozi vse stopnje razvoja igre, pri cemer bodo spre-

membe scasoma vedno manjse in manjse. Na ta nacin se bomo izognili fundamentalnim

spremembam igre v kasnejsih stopnjah razvoja [83].

8.5. MODEL RAZVOJA Stran 69


Slika 8.3: Iterativen proces testiranja igralnosti, ovrednotenja testiranja in vnasanjapopravkov [83].

8.6 Prva iteracija implementacije

V prvi iteraciji razvoja bomo implementirali glavne znacilnosti igre v skladu z

zastavljenim dokumentom zasnove igre. Cilj prve iteracije je, da ustvarimo delujoco

igro, ki jo bomo lahko ponudili v testiranje in tako zbrali komentarje za popravke v

naslednji iteraciji.

Vstopna scena - Meni

Sceno, na kateri bomo prikazali menije, smo dolocili kot zacetno sceno pri zagonu

aplikacije. To smo storili v datoteki AppDelegate.mm, in sicer na koncu metode

applicationDidFinishLaunching na nacin, ki ga prikazuje izvorna koda 8.1. Pou-

darimo se, da cocos2d razrede vedno instanciramo oziroma dostopamo do njih preko

razrednih metod, kot je v tem primeru metoda node.


8.6. PRVA ITERACIJA IMPLEMENTACIJE Stran 71

1 [[ CCDirector sharedDirector] runWithScene: [SceneMenu node

]];

Izvorna koda 8.1: Dolocanje zacetne scene igre.

V sceni za meni smo nato ustvarili gumbe, s katerimi bomo dostopali do preostalih

scen. To smo storili na nacin, ki ga prikazuje izvorna koda 8.2. Niz @"newgame.png"

v tem primeru predstavlja privzeto sliko gumba, ki se ob pritisku nadomesti s sliko

newgame2.png. Zadnja dva parametra klica dolocata, katera metoda se bo izvedla ob

pritisku. Na podlagi vec gumbov smo nato ustvarili vertikalen meni, ki smo ga dodali

na sceno.

1 item1 = [CCMenuItemImage itemFromNormalImage:@"newgame.png"

selectedImage:@"newgame2.png" target:self selector:

@selector(newGame :)];

2 menu = [CCMenu menuWithItems:item1 ,item2 ,item3 ,item4 ,nil];

3 [self addChild:menu z:5];

Izvorna koda 8.2: Kreiranje gumbov glavnega menija.

V metodi newGame, ki se bo izvedla ob pritisku na gumb, smo implementirali zamenjavo

scene. To smo storili na nacin, kot ga prikazuje izvorna koda 8.3. Novo sceno za igro

smo se dodatno ogradili z objektom CCTransitionFlipAngular. S tem smo dosegli

poseben vizualni ucinek prehoda iz menija v igro.

1 [[ CCDirector sharedDirector] replaceScene :[

CCTransitionFlipAngular transitionWithDuration :0.6f

scene:[ SceneGame node ]]];

Izvorna koda 8.3: Prehod na sceno igre s posebnim ucinkom.

Scena igre

Sceno igre smo sestavili iz vec slojev, med katerimi so najpomembnejsi naslednji:

• dolocanje in izris poti ter prikaz avtomobilov,



• vizualni ucinki,

• sporocila, kot je pavza ali zakljucek igre.

Dolocanje in izris poti je med omenjenimi sloji najkompleksnejsi, zato smo si pri njegovi

predstavitvi pomagali z razrednim diagramom, ki ga prikazuje slika 8.4. Kljucen razred

za predstavitev poti je razred CarPathController, ki vzdrzuje sloje za izris poti in

avtomobilov ter prestreza dotike zaslona. Za vsak avtomobil ustvari primerek razreda

CarPath, ki je odgovoren za nadzor posamicnega para objektov Car ter Path. Razred

Path omogoca tako izracun poti kot njen izris.

Slika 8.4: Razredni diagram sloja za avtomobile in poti.

Poleg dolocitve strukture razredov, je bilo potrebno dolociti se nacin dolocitve poti,

po kateri se bo gibal avtomobil ter izvesti animiranje avtomobila po tej poti. Problem

smo razdelili v tri sklope, in sicer zaznavanje tock skozi katere mora nujno peljati

avtomobil, racunanje krivulj na podlagi zaznanih tock in animiranje avtomobila po

krivulji s konstantno hitrostjo.

Zaznavanje tock smo implementirali tako, da ob vsakem premiku prsta preverimo ali

zelimo dodati novo tocko. To storimo z izracunom razdalje od predzadnje tocke do tre-



nutne lokacije. Ce je ta lokacija znotraj dolocenega tolerancnega obmocja, posodobimo

koordinate zadnje, ze shranjene tocke. V nasprotnem primeru ne smemo enostavno

dodati nove tocke v seznam, temvec moramo pred tem preveriti razdaljo med zadnjima

dvema shranjenima tockama, ce sta res dovolj dalec narazen. Omenjen dodaten po-

goj se je izkazal za potrebnega, saj so pri testiranju nekatere tocke, pri hitrem potegu

prsta, bile preblizu skupaj, krivulja pa je bila zaradi tega popacena. Poenostavljeno

implementacijo dodajanja tock prikazuje izvorna koda 8.4.

1 CGPoint knot = [path getKnot :([ path knotsCount] - 2)];

2 float dist = distancePoints(point.x, point.y, knoth.x,

knoth.y);

3

4 if (dist < KNOTSTOLERANCE) {

5 [path updateLastKnot:point];

6 } else {

7 CGPoint knot2 = [path getKnot :([ path knotsCount ]-1)];

8 float dist2 = distancePoints(knot.x, knot.y, knot2.x,

knot2.y);

9

10 if (dist2 < KNOTSTOLERANCE) {

11 [path updateLastKnot:point];

12 }

13 else {

14 [path addKnot:point];

15 }

16 }

Izvorna koda 8.4: Postopek dodajanja novih tock za pot avtomobila.

Racunanje enacb krivulje, na podlagi shranjenih tock, smo izvedli z resitvijo avtorjev

O. V. Polikarpotchkin in P. Lee [86]. Resitev, s katero pridobimo enacbe Bezierovih

krivulj, je napisana v programskem jeziku C#, zato smo jo na novo implementirali v

programskem jeziku C.

cocos2d podpira animiranje po Bezierovi krivulji, vendar preprosta implementacija

po parametru krivulje, ki jo vsebuje, ne zadosca nasim potrebam, saj ne zagotavlja

gibanja s konstantno hitrostjo. V ta namen smo razsirili razred CCFiniteTimeAction



in implementirali metodo update:, v kateri je potrebno, glede na pretecen cas, izvesti

ustrezne spremembe na objektu, ki ga animiramo. Za iskanje ustrezne nove vrednosti

parametra krivulje glede na pretecen cas smo izvedli preprosto aproksimacijo, ki se

je izkazala dovolj dobra za delovanje igre. Omenjeno aproksimacijo prikazuje izvorna

koda 8.5. Aproksimacija v osnovi deluje tako, da z diferencialno majhnim korakom

povecuje shranjeno vrednost parametra krivulje. Ob vsakem povecanju parameter

vstavimo v funkcijo in tako dobimo novo tocko na krivulji. Glede na dobljeno tocko in

tisto iz prejsnjega koraka izracunamo razdaljo med njima in razdaljo dodamo sestevku

razdalj. Kadar je sestevek dovolj velik glede na pretecen cas oziroma zahtevano razdaljo

premika, izvedemo premik avtomobila in mu spremenimo kot.

1 float runningDistance = 0;

2 float step = 1.0 / STEPS; //STEPS 200

3 while (currentCurveIndex < [curvePath count]) {

4

5 BezierConfig cf = [curvePath getBezierAt:

currentCurveIndex ];

6 for ( i += step;i <= 1;i += step ) {

7 *currenti = i;

8 newx = bezierat(cf.start.x, cf.control1.x, cf.

control2.x, cf.end.x, i);

9 newy = bezierat(cf.start.y, cf.control1.y, cf.

control2.y, cf.end.y, i);

10 float dist = distancePoints(prevx , prevy , newx , newy)

;

11

12 runningDistance += dist;

13

14 if ( runningDistance > distanceNext ) {

15 float myLenInFinal = dist - (runningDistance -

distanceNext);

16 float percent = myLenInFinal / dist;

17

18 float finalt = (i - step) + (percent * step);

19 //finalt je iskan parameter krivulje cf

20 }



21 }

22

23 currentCurveIndex ++;

24 }

Izvorna koda 8.5: Postopek iskanja parametra krivulje za zahtevan premik avtomobila.

Zaznavanje trkov in odziv na trk

Zaznavanje trkov je eden izmed kljucnih delov igre, saj se mora igra koncati, ko pride

do trka dveh avtomobilov. Poleg tega je potrebno prepoznati tudi voznjo avtomobilov

izven cestisca, kjer gre prav tako za problem zaznavanja trkov.

Za sistem zaznavanja trkov smo izkoristili pogon za fiziko Box2D, ki ga dobimo skupaj

z ogrodjem cocos2d. Namen pogona Box2D je simulacija fizikalnih pojavov v dvodi-

menzionalnem prostoru, zato vkljucuje zanesljivo in ucinkovito zaznavanje trkov.

Box2D uporabimo tako, da ustvarimo navidezni svet oziroma objekt b2World. Vanj

dodamo objekte b2Body oziroma telesa, ki jih ustvarimo na podlagi definicije oblike

telesa. Ko koncamo z definicijo navideznega sveta, klicemo nad objektom b2World

metodo Step, ki preracuna premike teles, pri cemer uposteva tudi trke med telesi. Za

tem nove lokacije elementov obicajno priredimo konkretnim graficnim elementom v

igri. V nasem primeru bomo uporabili nekoliko drugacen pristop, in sicer bomo telesa

premikali sami in nato poklicali metodo Step z namenom, da zaznamo trke med telesi.

Box2D je napisan v jeziku C++, zato so tudi vsi objekti Box2D, ki jih bomo ustvarili,

C++ objekti in ne Objective-C objekti.

V igri smo ustvarili objekt b2World, nato smo mu dodali telo, ki doloca podrocje izven

cestisca. To telo smo sprva ustvarili na podlagi kroga, ki doloca osrednji del zelenih

povrsin, kar prikazuje izvorna koda 8.6.

1 b2BodyDef groundBodyDef;

2 groundBodyDef.position.Set(241, 159);

3 b2CircleShape circleDef;

4 circleDef.m_radius = 43.0f;

5 bodyGrass = world -> CreateBody (& groundBodyDef);

6 bodyGrass -> CreateFixture (&circleDef , 1.0f);

Izvorna koda 8.6: Ustvarjanje telesa za zelene povrsine.



Vsako telo je lahko doloceno z vec geometrijskimi liki, kar nam omogoca, da vse zelene

povrsine predstavlja eno samo telo. Izvorna koda 8.7 prikazuje, kako smo telesu, ki

predstavlja zelene povrsne, dodali se en del zelenice. convertY je v tem primeru

implicitna funkcija, ki izracuna odmik od desnega roba zaslona. Ne smemo pozabiti,

da je potrebno vektorje, ki dolocajo mnogokotnik, nanizati v nasprotni smeri urinega

kazalca.

1 b2PolygonShape b2Poly3;

2 b2Vec2 vec3 [5];

3 vec3 [0] = b2Vec2 (0 - centerPoint.x, convertY (40) -

centerPoint.y);


centerPoint.y);


centerPoint.y);

6 vec3 [3] = b2Vec2 (214 - centerPoint.x ,convertY (0) -

centerPoint.y);


centerPoint.y);

8 b2Poly3.Set(vec3 , 5);

9 b2Fixture* fixture3 = bodyGrass -> CreateFixture (&b2Poly3 ,

1.0f);

Izvorna koda 8.7: Dodajanje novih delov zelenih povrsin.

Avtomobile dodajamo v objekt b2World na enak nacin, kot smo to storili za zelene

povrsine. Ker avtomobile v igri tudi odstranjujemo, jih ne smemo pozabiti odstraniti

iz objekta b2World. To storimo s klicem metode DestroyBody nad objektom b2World.

Za odziv na trke je potrebno razsiriti C++ razred b2ContactListener in implemen-

tirati metodi BeginContact ter EndContact. Metoda BeginContact kot argument

prejme objekt tipa b2Contact, na podlagi katere lahko pridobimo telesi, ki sta trcili,

in tocko, kjer se je trk zgodil. Kako to storimo, prikazuje izvorna koda 8.8.

1 //telesa trka

2 b2Body* body1 = point -> GetFixtureA () -> GetBody ();

3 b2Body* body2 = point -> GetFixtureB () -> GetBody ();



4

5 //tocka trka

6 b2WorldManifold worldManifold;

7 point -> GetWorldManifold (& worldManifold);

8 b2Vec2 posCrash = worldManifold.points [0];

Izvorna koda 8.8: Nacin dostopa do teles in tocke trka iz objekta b2Contact.

Po tem, ko smo dobili telesa, ki so trcila, in tocko trka, lahko telesa primerjamo s shra-

njenimi telesi in ugotovimo, ali gre za voznjo po zelenici ali za trk med avtomobiloma.

Ce sta trcila avtomobila, nad avtomobili ustvarimo ucinek ognja in zaustavimo igro.

Za simulacijo ognja smo ustvarili sistem delcev, kot prikazuje izvorna koda 8.9. Izgled

simulacije ognja iz uporabniskega vidika prikazuje slika slika 8.5.

1 CCParticleSystemPoint* emitter = [[ CCParticleSystemPoint

alloc] initWithTotalParticles :30];

2

3 emitter.texture = [[ CCTextureCache sharedTextureCache]

addImage:@"fire.png"];

4 emitter.duration = -1;

5 emitter.gravity = ccp(0,0);

6 emitter.angle = 90;

7 emitter.angleVar = 20;

8 emitter.radialAccel = 0;

9 emitter.radialAccelVar = 0;

10 emitter.life = 1.5f;

11 emitter.lifeVar = 0.10f;

12 emitter.speed = 50;

13 emitter.speedVar = 20;

14 emitter.startSize = 50.0f;

15 emitter.startSizeVar = 10.0f;

16 emitter.endSize = kParticleStartSizeEqualToEndSize;

17 emitter.emissionRate = 30 / 1.5f;

18

19 ccColor4F c1 = {0.76f, 0.25f, 0.12f, 1.0f};

20 emitter.startColor = c1;



21 ccColor4F c2 = {0.2f, 0.2f, 0.0f, 0.0f};

22 emitter.startColorVar = c2;

23 ccColor4F c3 = {0.5f, 0.0f, 0.0f, 0.0f};

24 emitter.endColor = c3;

25 ccColor4F c4 = {0.0f, 0.0f, 0.0f, 0.0f};

26 emitter.endColorVar = c4;

Izvorna koda 8.9: Sistem delcev za simulacijo ognja.

Slika 8.5: Simulacija ognja s sistemom delcev.

Testiranje

Igro, katere vmesnik je ob koncu prve iteracije izgledal kot prikazuje slika 8.6, smo

ponudili v testiranje prijateljem. Namen je bil, da ugotovimo, kaksna je primerna

zacetna tezavnost igre ter s kaksno hitrostjo bi bilo smiselno stopnjevati tezavnost.

Rezultati so bili presenetljivi. Izkazalo se je, da igralci le s tezavo igrajo igro, saj

z lahkoto spregledajo dolocene pomembne informacije. Na podlagi komentarjev smo

prisli do naslednjih bistvenih ugotovitev:

• tezavno je prepoznati, v kateri izvoz je avtomobil potrebno peljati,

• ni razvidno, kateri premikajoci se avtomobili imajo ze dolocen cilj in kateri ne,

• pred trkom avtomobilov ni nobenega opozorila, kar igralca zmede,

• ni jasnih opozoril za voznjo izven cestisca, se posebej preden se igra zakljuci.


8.7. DRUGA ITERACIJA IMPLEMENTACIJE Stran 79

Slika 8.6: Igra ob koncu prve iteracije.

8.7 Druga iteracija implementacije

Osnova za drugo iteracijo bodo komentarji, ki smo jih pridobili na stopnji testiranja

v prejsnji iteraciji. Zatem bomo implementirali se dodatno funkcionalnost, in sicer

obravnavo v primeru prekinitve igre.

Cilj avtomobila

Problem, da igralci niso prepoznali izvoza, v katerega je potrebno peljati avtomobil,

smo resili na naslednji nacin. Ob dotiku avtomobila ali znaka stop se ustvari prosojna

rumena puscica, ki se nato z veliko hitrostjo animira proti ciljnemu izhodu ter postaja

vedno manj prosojna in vedno vecja, kar prikazujeta sliki 8.7. Na ta nacin se igralcu

sporoci, v kateri izvoz je dolzan usmeriti avtomobil.

Slika 8.7: Puscica, ki pomaga usmeriti avtomobil v izvoz.



Ni razvidno, ali je cilj avtomobila dolocen

Problem smo odpravili tako, da smo pot, kateri sledi avtomobil, obarvali z barvo izvoza

in jo odebelili. To smo storili z ukazoma OpenGL, ki ju prikazuje izvorna koda 8.10.

Prvi ukaz nastavi barvo in prosojnost, drugi pa debelino crte.

1 glColor4ub (199, 60, 173, 255);

2 glLineWidth (3.0f);

Izvorna koda 8.10: Ukaza za dolocitev barve in debeline crte.

Poleg poudarjene barvne crte smo dodali se dodaten vizualen ucinek, kadar uspesno

dolocimo izhod. Popravljeno razlicico risanja krivulj prikazuje slika 8.8.

Slika 8.8: Igra z urejenim izrisom krivulj.

Pomanjkanje opozoril pred trkom

Za odpravo te pomanjkljivosti je bilo potrebno vnaprej prepoznati nevarnost trka.

Odlocili smo se, da bomo za to ponovno izkoristili zaznavanje trkov, ki je vgrajeno v

Box2D. Poleg telesa, ki predstavlja avtomobil, smo ustvarili se nekoliko vecje navidezno

telo. To telo je za nekaj tock vecje od avtomobila, v smeri premikanja avtomobila

pa je podaljsano se za 20 tock. Taksen pristop ima eno resno pomanjkljivost. Do

sedaj so bili relevantni vsi trki, do katerih je prislo. Obravnavali smo tako trk med

avtomobiloma, kot tudi trk med avtomobilom in zelenico. Z novim navideznim telesom

mnogi trki, kot je trk novega telesa z zelenico ali avtomobilom, niso zazeleni. Poleg

omenjenih nezazelenih trkov, sta novo navidezno telo in pripadajoci avtomobil vedno

na isti lokaciji. To ima za posledico, da sta v neprestanem trku.



Opisane tezave smo resili s pomocjo strukture b2Filter, s katero lahko telesa razdelimo

v najvec 16 skupin. V nasem primeru smo telesa s pomocjo b2Filter razdelili v 3

tri skupine. Zelenicam smo dodelili skupino z vrednostjo 1, avtomobilom skupino z

vrednostjo 2, novim navideznim telesom pa smo dodelili skupino z vrednostjo 4. Poleg

skupin lahko v strukturah b2Filter dolocimo se maske. Te Box2D uporabi za bitno

primerjavo s skupinami in tako ugotovi, ali je trk med telesoma mogoc. Ker lahko

zelenica trci samo z avtomobilom, smo ji dodelili masko z vrednostjo 2. Avtomobilom

smo dodelili masko 3, saj lahko trcijo tako med sabo kot tudi z zelenico. Novim

navideznim telesom smo dodelili masko z vrednostjo 4, ker lahko trcijo samo z drugim

navideznim telesom.

Ob trku navideznih teles najprej poiscemo avtomobila, ki sta povezana z navideznima

telesoma. Nato izvedemo animacijo, ki povzroci rdece utripanje avtomobilov, za katera

obstaja nevarnost trka. Prikaz opozorila pred trkom prikazuje slika 8.9.

Slika 8.9: Opozorilo pred trkom.

Zvocni ucinki

Za predvajanje zvoka smo izkoristili razred SimpleAudioEngine, ki je zelo enostaven za

uporabo in je vgrajen v ogrodje cocos2d. Knjiznica omogoca enkratno ali ponavljajoce

se predvajanje. Izvorna koda 8.11 prikazuje, kako smo izvedli ponavljajoce predvajanje

zvoka v menijski sceni.

1 if (![[ SimpleAudioEngine sharedEngine]

isBackgroundMusicPlaying ]) {

2 [[ SimpleAudioEngine sharedEngine] playBackgroundMusic:@"

menuLoop3.wav" loop:YES];

3 }

4 [[ SimpleAudioEngine sharedEngine] setBackgroundMusicVolume

:1.0f];

Izvorna koda 8.11: Preprost nacin predvajanja ponavljajocega zvoka.



Obravnava prekinitve igre

Omenili smo ze, da se aplikacija preneha izvajati v primeru nekaterih dogodkov, kot je

telefonski klic na napravi iPhone. V tem primeru imamo na voljo samo nekaj sekund

casa, da shranimo celotno stanje igre, ki ga moramo biti sposobni obnoviti ob ponovnem

zagonu igre.

Za shranjevanje podatkov imamo na voljo razred NSUserDefaults. Ta omogoca shra-

njevanje nastavitev aplikacije v obliki razredov Objective-C glede na dolocen kljuc.

Vsak objekt, ki ga zelimo shraniti, moramo pretvoriti v ustrezen objekt Objective-C,

kar naredi kodo, v primeru velikega stevila spremenljivk, nepregledeno. Poleg tega je

lahko v igri Traffic Master vec avtomobilov hkrati, za opis njihovih stanj pa potrebu-

jemo veliko podatkov. To lahko upocasni proces shranjevanja. Omenjena problema

smo naslovili na nacin, da smo definirali vec struktur v jeziku C, ki sluzijo opisu sta-

nja igre. Ena izmed omenjenih struktur, kot prikazuje izvorna koda 8.12, je struktura

saveGameCar, ki je namenjena opisu stanja posameznega avtomobila. Vsak avtomobil

tako opisemo s spremenljivkami, ki dolocajo tip avtomobila, kje se nahaja na zaslonu,

proti kateremu izhodu se pelje, v katero smer je trenutno obrnjen, krivuljo kateri sledi,

itd.

1 typedef struct {

2 int carType;

3 int exit;

4 int startExit;

5 int startExitIndex;

6 bool firstTouchMade;

7 bool carCameOnScreen;

8 BezierConfig path[MAXBEZIERS ];

9 int splineCount;

10 int currentSpline;

11 float currentStepBezier;

12 float currentPosition_x;

13 float currentPosition_y;

14 float angle;

15 } saveGameCar;

Izvorna koda 8.12: Struktura za opis stanja avtomobila.



Preden strukturo z vsemi podatki o stanju igre shranimo, jo je potrebno pretvoriti v

Objective-C objekt. A. Fothergill, soavtor knjige iPhone Games Projects, priporoca

naslednjo pretvorbo, s katero strukturo pretvorimo v objekt NSData. Objekt NSData

lahko nato shranimo z razredom NSUserDefaults. Omenjen postopek prikazuje iz-

vorna koda 8.13 [58].

1 unsigned char * ptr;

2 unsigned char * save;

3 save = (unsigned char*) malloc(sizeof(saveData));

4

5 ptr = (unsigned char *)&saveData;

6 for(int a = 0; a < sizeof(saveData);a++) {

7 *(save + a) = *(ptr + a);

8 }

9 NSData *saveDataObject = [[ NSData alloc] initWithBytes:save

length:sizeof(saveData)];

10 [[ NSUserDefaults standardUserDefaults] setObject:

saveDataObject forKey:@"RASaveGame"];

11 [[ NSUserDefaults standardUserDefaults] setInteger:

CURRENTVERSION forKey:@"RAVersion"];

Izvorna koda 8.13: Postopek shranjevanja opisan s strukturo v jeziku C.

Pri shranjevanju strukture smo shranili se razlicico strukture za opis stanja, ki jo v

izvorni kodi 8.13 oznacuje konstanta CURRENTVERSION. To storimo zaradi morebitnih

popravkov in novejsih razlicic igre, ki bodo najverjetneje imele nekoliko spremenjeno

strukturo. Na podlagi razlicice strukture se bomo tako lahko odlocili, kako bomo

obravnavali morebitno strukturo starejse razlicice.

Objekt NSData in razlicico strukture ob ponovnem zagonu igre pridobimo na nacin, ki

ga prikazuje izvorna koda 8.14. V nasem primeru razvijamo prvo razlicico igre, zato

morebitne starejse razlicice strukture ni potrebno obravnavati.

1

2 NSData *saveData = [[ NSUserDefaults standardUserDefaults]

dataForKey:@"RASaveGame"];

3



4 int version = -1;

5 if ([[ NSUserDefaults standardUserDefaults] objectForKey:@"

RAVersion"] != nil) {

6 version =[[ NSUserDefaults standardUserDefaults]

integerForKey:@"RAVersion"];

7 }

8

9 if (savedata == NULL || version == -1) {

10 [self resetSaveData ]; //podatki ne obstajajo

11 } else {

12 [savedata getBytes :& saveData length:sizeof(saveData)];

13

14 if(version != CURRENTVERSION) {

15 //Napacna razlicica strukture

16 }

17 }

Izvorna koda 8.14: Postopek nalaganja shranjenih podatkov o stanju igre.

Testiranje

Igro smo ponovno ponudili prijateljem v testiranje. Z dodanimi izboljsavami druge

iteracije so bili zadovoljni in niso imeli pripomb glede igralnosti igre. Pri testiranju

smo ugotovili, da je primerna zacetna tezavnost igre, ustvarjanje avtomobila vsakih 15

sekund. Igra pa je postala prevec tezavna, ko so se avtomobili priceli ustvarjati vsakih

6 sekund.

8.8 Tretja iteracija implementacije

V tretji iteraciji smo ustvarili boljso podporo za nadzor tezavnosti in dodali moznost

shranjevanja dosezenih tock na streznik cocoslive.

Tezavnostne stopnje

Igra mora biti zanimiva tako za zacetnike kot tudi za bolj izkusene igralce. Zaradi tega

enostavno linearno narascanje tezavnost ni dovolj dobra resitev. Igra mora biti sprva


8.8. TRETJA ITERACIJA IMPLEMENTACIJE Stran 85

enostavna, tezavnost pa mora narascati hitro. Ko postane igra zelo tezavna, mora

tezavnost narascati zelo pocasi. Za implementacijo narascanja tezavnosti smo poiskali

funkcijo, ki bo dolocala frekvenco kreiranja novih avtomobilov, glede na pretecen cas

igranja. Pri tem smo upostevali, da zelimo na zacetku avtomobile ustvarjati na 15

sekund, po 300 sekundah igranja pa vsakih 6 sekund. Za ustvarjanje avtomobilov smo

tako uporabili funckcijo f(t) = 14.3 ∗ (t+ 0.7)−0.15, katere graf prikazuje slika 8.10.

Slika 8.10: Funkcija, ki glede na pretecen cas igranja doloca frekvenco kreiranja avto-mobilov.

Shranjevanje dosezenih tock in prikaz najboljsih igralcev

Ob zakljucku igre se nam prikaze vmesnik, kot ga prikazuje slika 8.11. Igralcu ponudimo

moznost, da se vrne v zacetni menu in ponovno poskusi ali pa svoj dosezek poslje

strezniku. Ce se odloci, da bo dosezene tocke poslal strezniku, se mu prikaze vnosno

polje za vnos imena. Po potrditvi imena in uspesnem posiljanju tock, se igralcu prikaze,

katero mesto zaseda v svetovnem in lokalnem merilu.

8.8. TRETJA ITERACIJA IMPLEMENTACIJE Stran 85


Slika 8.11: Vmesnik igre ob zakljucku igre.

Shranjevanje tock smo podprli s pomocjo brezplacne storitve cocoslive. Implementa-

cijo posiljanja tock prikazuje izvorna koda 8.15. Sprva ustvarimo objekt za posiljanje

dosezenih tock, nad katerim prozimo metodo updateScore. Tej metodi podamo objekt

NSMutableDictionary, ki vsebuje potrebne informacije o igralcu, dosezenih tockah in

kategoriji.

1

2 ScoreServerPost *server = [[ ScoreServerPost alloc]

initWithGameName:COCOSLIVE_GAME_NAME gameKey:

COCOSLIVE_GAME_HASH delegate:self];

3

4 NSMutableDictionary *dict = [NSMutableDictionary

dictionaryWithCapacity :3];

5 [dict setObject :[ NSNumber numberWithInt: points] forKey:@"

cc_score"];

6 [dict setObject :[[ GlobalData sharedGlobalData] getName]

forKey:@"cc_playername"];

7 [dict setObject:@"Classic" forKey:@"cc_category"];

8

9 [server updateScore:dict];

10 [server release ];

Izvorna koda 8.15: Shranjevanje dosezenih tock na streznik cocoslive.


8.9. OBJAVA IGRE V TRZNICI APPSTORE Stran 87

Implementirati je potrebno se metodi scorePostOk: ter scorePostFail:, s katerima

se odzovemo na uspesno oziroma morebiti neuspesno posiljanje.

Za identifikacijo igre smo pri posiljanju uporabili konstante, saj jih potrebujemo se na

sceni za prikaz najboljsih igralcev. Scena za prikaz najboljsih igralcev, kot jo prika-

zuje slika 8.12, je dostopna iz glavnega menija. Za pridobitev podatkov o shranjenih

dosezkih ustvarimo zahtevek, kot ga prikazuje izvorna koda 8.16. Pri zahtevku lahko

podamo razlicne omejitve in zastavice, kot je omejitev rezultatov na drzavo v kateri se

nahajamo.

Slika 8.12: Scena za prikaz najboljsih igralcev.

1 ScoreServerRequest *request = [[ ScoreServerRequest alloc]

initWithGameName:@"Traffic Master Testing" delegate:

self];

2 [request requestScores:kQueryAllTime limit:SCORESPERSCRENE

offset:currentOffset flags:flag category:@"Classic"];

Izvorna koda 8.16: Zahtevek za prenos seznama dosezkov igralcev s streznika cocoslive.

Zahtevek nam vrne objekt NSArray, ki vsebuje objekt NSDictionary za vsak posamicen

vnos.

8.9 Objava igre v trznici AppStore

Zadnja stopnja v razvoju igre je njena izdaja. V primeru igre za iOS mora ta potekati

preko trznice za mobilne aplikacije AppStore. Razlicne poslovne modele, ki jih lahko

8.9. OBJAVA IGRE V TRZNICI APPSTORE Stran 87


pri tem uporabimo, smo ze podali v tretjem poglavju, nismo pa se predstavili, kaksen

je postopek za objavo igre v trznici AppStore.

Prvi korak k oddaji aplikacije je, da smo registrirani kot razvijalci, za kar je potrebno

podjetju Apple vsako leto placati dolocen znesek. Z registracijo pridobimo dostop

do razvijalskega portala, kjer ustvarimo zahtevo za podpis certifikata. Po potrditvi

zahteve s strani administratorjev lahko certifikat prenesemo na racunalnik. Preden

aplikacijo objavimo, jo podpisemo s certifikatom. Prav tako pa nam certifikat omogoca

testiranje na napravi iOS. Poleg certifikata moramo v razvijalskem portalu ustvariti

identifikator aplikacije ter profil, ki doloca dovoljenja za namestitev aplikacij na naprave

(angl. provisioning profile). Profilu moramo za metodo distribucije dolociti AppStore

in na seznamu izbrati identifikator aplikacije, ki smo ga ustvarili pred tem. Profil

namestimo na racunalnik in ga izberemo v nastavitvah projekta v razvojnem okolju

Xcode. V nastavitvah vnesemo se ime aplikacije, ki smo ga dolocili pri ustvarjanju

identifikatorja aplikacije. Aplikacijo zgradimo in jo predlozimo na spletni strani https:

//itunesconnect.apple.com/, na kateri se avtenticiramo z razvijalskim racunom. Pri

tem moramo podati se nekaj informacij o aplikaciji, med katerimi so:

• unikatno ime aplikacije,

• opis aplikacije,

• kategorijo v katero spada,

• URL naslov za povratne informacije,

• ikona aplikacije v velikosti 512×512 tock,

• glavni zaslonski posnetek aplikacije in do stiri dodatne zaslonske posnetke [87].

Igra Traffic Master bo brezplacno dosegljiva na trznici AppStore v bliznji prihodnosti.


https://itunesconnect.apple.com/

https://itunesconnect.apple.com/

Stran 89

Poglavje 9

Sklep

Platforma iOS je ena izmed najpomembnejsih platform za mobilne naprave. Z novim

pristopom dostave aplikacije preko trznice AppStore je spremenila nacin razmisljanja

tako razvijalcev kot tudi uporabnikov aplikacij. Da je taksen pristop pravilen, lahko

sklepamo tako po stevilu aplikacij v trznici AppStore, ki jih je danes ze vec kot 400 tisoc,

kot tudi po konkurenci, ki je ubrala podoben pristop pri dostavi aplikacij na naprave.

Z novim nacinom distribucije aplikacij in zmogljivo strojno opremo, platforma iOS

ponuja veliko novih priloznosti na podrocju razvoja iger.

V diplomskem delu smo predstavili razvoj iger za platformo iOS. Najprej smo pred-

stavili glavne lastnosti platforme iOS, orodja, ki jih lahko uporabimo pri razvoju, ter

glavne omejitve pri razvoju za to platformo. Slednje so se posebej pomembne, saj se z

njimi ne bomo srecali pri razvoju za druge mobilne platforme ali osebne racunalnike.

Poleg predstavitve platforme smo ugotovili, da obstaja vec razlicnih nacinov za ustvar-

janje prihodkov pri razvoju aplikacij iOS. Najzanimivejsi med njimi so vsekakor razlicni

nacini oglasevanja v igrah ter nakupovanje znotraj aplikacij. Pri tem smo podali se

nekaj zanimivih ugotovitev, kako uporabniki uporabljajo naprave iOS.

Predstavili smo tudi mozne tehnologije za izgradnjo graficnega vmesnika ter tehnolo-

gije za zvok, kjer smo spoznali, da obstaja vec tehnologij, ki jih lahko uporabimo pri

implementaciji igre. Podrobneje smo predstavili odprtokodni pogon cocos2d za iPhone.

Spoznali smo, da gre za zmogljiv pogon, ki omogoca sirok nabor razlicnih nacinov za

prikaz in animiranje vsebin. Poleg tega smo podali se nekaj najboljsih praks in tehnik

za optimizacijo delovanja igre.

Na podlagi predstavljenih tehnologij smo v prakticnem delu diplomskega dela imple-

mentirali igro Traffic Master, pri cemer smo sledili korakom, ki veljajo za razvoj iger.

Stran 89

Stran 90 POGLAVJE 9. SKLEP

Prisli smo do spoznanj, da je prototipiranje ucinkovit nacin za preverjanje ideje igre, da

je iterativen pristop zelo primeren za razvoj iger ter da se koraki razvoja igre nekoliko

razlikujejo od razvoja druge programske opreme.

Resitev, ki smo jo razvili v prakticnem delu diplomskega dela, bi vsekakor bilo mogoce

izboljsati. Ena bistvenih izboljsav bi bila zagotovitev interoperabilnosti igre med

razlicnimi mobilnimi platformami. To bi bilo se posebej dobrodoslo, ce upostevamo, da

med mobilnimi platformami trzni delez naprav iOS ni najvisji. Poleg tega bi igro lahko

razsirili z vecjim stevilom razlicnih stopenj ter avtomobilov, ki bi jih lahko pripravili

v sodelovanju z oglasevalcem in jih ponudili brezplacno. V primeru avtomobilov, bi to

bili modeli, ki obstajajo v resnici in bi sluzili kot oglas.

Stran 90 POGLAVJE 9. SKLEP

LITERATURA Stran 91

Literatura

[1] iOS (Apple), http://en.wikipedia.org/wiki/IOS_%28Apple%29, 2010, obi-

skano 20. 4. 2010

[2] iOS Overview, http://developer.apple.com/library/ios/

#referencelibrary/GettingStarted/URL_iPhone_OS_Overview/, 2010,

obiskano 20. 10. 2010

[3] List of iOS devices, http://en.wikipedia.org/wiki/List_of_iOS_devices,

2010, obiskano 20. 10. 2010

[4] J. Nutting, D. Wooldridge, D. Mark, Beginning iPad Development for iPhone

Developers: Mastering the iPad SDK, Apress, 2010

[5] Getting Started with iOS, http://developer.apple.com/library/ios/

#referencelibrary/GettingStarted/GS_iPhoneGeneral/index.html, 2010,

obiskano 15. 2. 2011

[6] E. Sadun, The iPhoneTM Developer’s Cookbook, Addison-Wesley, 2009

[7] Mobile operating system, http://en.wikipedia.org/wiki/Mobile_operating_

system, obiskano 17. 2. 2011

[8] Open handset alliance, http://www.openhandsetalliance.com, 2010, obiskano

10. 4. 2010

[9] Android Developers, http://developer.android.com, 2010, obiskano 10. 4. 2010

[10] Android’s Rapid Growth Has Some Developers Worried, http://www.wired.com/

gadgetlab/2009/11/android-fragmentation/, 2009, obiskano 10. 4. 2010

[11] Nokia Kills Symbian, Teams Up With Microsoft For Win-

dows Phone 7, http://www.wired.com/gadgetlab/2011/02/

LITERATURA Stran 91

http://en.wikipedia.org/wiki/IOS_%28Apple%29

http://developer.apple.com/library/ios/#referencelibrary/GettingStarted/URL_iPhone_OS_Overview/

http://developer.apple.com/library/ios/#referencelibrary/GettingStarted/URL_iPhone_OS_Overview/

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

http://developer.apple.com/library/ios/#referencelibrary/GettingStarted/GS_iPhoneGeneral/index.html

http://developer.apple.com/library/ios/#referencelibrary/GettingStarted/GS_iPhoneGeneral/index.html

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

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

http://www.openhandsetalliance.com

http://developer.android.com

http://www.wired.com/gadgetlab/2009/11/android-fragmentation/

http://www.wired.com/gadgetlab/2009/11/android-fragmentation/

http://www.wired.com/gadgetlab/2011/02/microsoft-and-nokia-team-up-to-build-windows-phones/


Stran 92 LITERATURA

microsoft-and-nokia-team-up-to-build-windows-phones/, obiskano 17.

2. 2011

[12] Windows Mobile DirectX and Direct3D, http://msdn.microsoft.com/en-us/

library/bb677124.aspx, obiskano 18. 2. 2011

[13] Windows Phone 7, http://en.wikipedia.org/wiki/Windows_Phone_7, obi-

skano 18. 2. 2011

[14] Why BlackBerry?, http://us.blackberry.com/developers/whyblackberry.

jsp, obiskano 18. 2. 2011

[15] BlackBerry Smartphones that support OpenGL ES, http:

//supportforums.blackberry.com/t5/Java-Development/

BlackBerry-Smartphones-that-support-OpenGL-ES/ta-p/568859, obiskano

18. 2. 2011

[16] D. Mark, J. Lamarche, Beginning iPhone Development, Apress, 2009

[17] iOS Application Programming Guide https://developer.apple.com/library/

ios/#documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/, 2010,

obiskano 12. 10. 2010

[18] Sandbox: Think like Apple http://blogs.oreilly.com/iphone/2008/09/

sandbox-think-like-apple.html, 2008, obiskano 1. 10. 2010

[19] S. Bhat, iPhone Apps Will Work With The iPad, http://techie-buzz.com/

tech-news/iphone-apps-will-work-with-ipad.html, 2010, obiskano 18. 2.

2011

[20] Introducing Universal Applications for iPhone OS, http://devimages.apple.

com/iphone/resources/introductiontouniversalapps.pdf, 2010, obiskano

18. 2. 2011

[21] E. Welch, Developing iPhone Games for Longer Battery Life, http://www.

gamedev.net/reference/programming/features/iPhoneBatSave/, 2010, obi-

skano 13. 10. 2010

[22] Gartner Says Worldwide Mobile Application Store Revenue Forecast to Surpass

$15 Billion in 2011, http://www.gartner.com/it/page.jsp?id=1529214, obi-

skano 15. 2. 2011

Stran 92 LITERATURA




http://msdn.microsoft.com/en-us/library/bb677124.aspx

http://msdn.microsoft.com/en-us/library/bb677124.aspx

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

http://us.blackberry.com/developers/whyblackberry.jsp

http://us.blackberry.com/developers/whyblackberry.jsp

http://supportforums.blackberry.com/t5/Java-Development/BlackBerry-Smartphones-that-support-OpenGL-ES/ta-p/568859



https://developer.apple.com/library/ios/#documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/

https://developer.apple.com/library/ios/#documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/

http://blogs.oreilly.com/iphone/2008/09/sandbox-think-like-apple.html

http://blogs.oreilly.com/iphone/2008/09/sandbox-think-like-apple.html

http://techie-buzz.com/tech-news/iphone-apps-will-work-with-ipad.html

http://techie-buzz.com/tech-news/iphone-apps-will-work-with-ipad.html

http://devimages.apple.com/iphone/resources/introductiontouniversalapps.pdf

http://devimages.apple.com/iphone/resources/introductiontouniversalapps.pdf

http://www.gamedev.net/reference/programming/features/iPhoneBatSave/

http://www.gamedev.net/reference/programming/features/iPhoneBatSave/

http://www.gartner.com/it/page.jsp?id=1529214

LITERATURA Stran 93

[23] Gartner Executive Programs Worldwide Survey of More Than 2,000 CIOs Iden-

tifies Cloud Computing as Top Technology Priority for CIOs in 2011, http:

//www.gartner.com/it/page.jsp?id=1526414, obiskano 15. 2. 2011

[24] App Store, http://en.wikipedia.org/wiki/App_Store, 2011, obiskano 31. 1.

2011

[25] App Store Review Guidelines, http://developer.apple.com/appstore/

guidelines.html, 2010, obiskano 31. 1. 2011

[26] H. McCracken, Apple’s iPhone App Policy Revisions: The Good and The

Bad, http://www.pcworld.com/article/205175/apples_iphone_app_policy_

revisions_the_good_and_the_bad.html?tk=rss_news, 2010, obiskano 31. 1.

2011

[27] D. Wooldridge, M. Schneider, The Business of iPhone App Development: Making

and Marketing Apps that Succeed, Apress, 2010

[28] App Store Metrics, http://148apps.biz/app-store-metrics/, obiskano 21. 2.

2011

[29] Developer’s Guide to In-Application Advertising, http://www.

skyhookwireless.com/developers/developersguide.pdf, 2010

[30] Game Advertising, http://www.iab.net/media/file/IAB-Games-PSR-Update_

0913.pdf, 2010

[31] Rovio uses Google’s AdMob network to launch Angry Birds

across platforms, http://googlemobileads.blogspot.com/2010/10/

rovio-partners-with-googles-admob.html, obiskano 15. 2. 2011

[32] iAd Network, http://advertising.apple.com, obiskano 15. 2. 2011

[33] P. Fargo, The Awesome Potential of iPhone In-

App Purchases, http://blog.flurry.com/bid/22501/

The-Awesome-Potential-of-iPhone-In-App-Purchases, obiskano 15. 2.

2011

[34] App Store Quick Reference: Getting Started with In App Purchase on iPhone OS ,

http://developer.apple.com/news/ios/pdf/in_app_purchase.pdf, obiskano

14. 2. 2011

LITERATURA Stran 93



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

http://developer.apple.com/appstore/guidelines.html

http://developer.apple.com/appstore/guidelines.html

http://www.pcworld.com/article/205175/apples_iphone_app_policy_revisions_the_good_and_the_bad.html?tk=rss_news

http://www.pcworld.com/article/205175/apples_iphone_app_policy_revisions_the_good_and_the_bad.html?tk=rss_news

http://148apps.biz/app-store-metrics/

http://www.skyhookwireless.com/developers/developersguide.pdf

http://www.skyhookwireless.com/developers/developersguide.pdf

http://www.iab.net/media/file/IAB-Games-PSR-Update_0913.pdf

http://www.iab.net/media/file/IAB-Games-PSR-Update_0913.pdf

http://googlemobileads.blogspot.com/2010/10/rovio-partners-with-googles-admob.html

http://googlemobileads.blogspot.com/2010/10/rovio-partners-with-googles-admob.html

http://advertising.apple.com

http://blog.flurry.com/bid/22501/The-Awesome-Potential-of-iPhone-In-App-Purchases

http://blog.flurry.com/bid/22501/The-Awesome-Potential-of-iPhone-In-App-Purchases

http://developer.apple.com/news/ios/pdf/in_app_purchase.pdf

Stran 94 LITERATURA

[35] In App Purchase Programming Guide, http://developer.apple.com/library/

ios/documentation/NetworkingInternet/Conceptual/StoreKitGuide/

StoreKitGuide.pdf, obiskano 14. 2. 2011

[36] Angry Birds for iPhone, iPad updated with Mi-

ghty Eagle,http://www.intomobile.com/2010/12/23/

angry-birds-for-iphone-ipad-updated-with-mighty-eagle/, obiskano

14. 2. 2010

[37] Urban Airship, http://urbanairship.com/, obiskano 23. 3. 2011

[38] App Usage Survey, http://metrics.admob.com/wp-content/uploads/2010/

03/AdMob-Mobile-Metrics-Jan-10-Survey-Supplement.pdf, 2010, obiskano 5.

10. 2010

[39] iPhone data usage survey: the results, http://macformat.techradar.com/blog/

iphone-data-usage-survey-results-15-06-10, 2010, obiskano 8. 10. 2010

[40] iPhone Analytics Show Peak Mobile App Usage on Ni-

ghts & Weekends, http://www.localytics.com/blog/post/

iphone-analytics-show-peak-mobile-app-usage-on-nights-weekends/,

2010, obiskano 10. 10. 2010

[41] View Programming Guide for iOS,http://developer.apple.com/library/ios/

#documentation/WindowsViews/Conceptual/ViewPG_iPhoneOS, 2010, obiskano

5. 9. 2010

[42] Cocoa Fundamentals Guide, https://developer.apple.com/library/ios/

documentation/Cocoa/Conceptual/CocoaFundamentals, 2010, obiskano 5. 9.

2010

[43] P. Bakhirev, P. Cabrera, I. Marsh, S. Penberthy, B. B. Smith, E. Wing, Beginning

iPhone Games Development, Apress, 2010

[44] About Audio and Video, https://developer.apple.com/library/ios/

#documentation/AudioVideo/Conceptual/MultimediaPG/Introduction/

Introduction.html, 2010, obiskano 15. 3. 2011

[45] M. Daley, Learning iOS Game Programming, Addison-Wesley, 2010

Stran 94 LITERATURA

http://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StoreKitGuide/StoreKitGuide.pdf



http://www.intomobile.com/2010/12/23/angry-birds-for-iphone-ipad-updated-with-mighty-eagle/

http://www.intomobile.com/2010/12/23/angry-birds-for-iphone-ipad-updated-with-mighty-eagle/

http://urbanairship.com/

http://metrics.admob.com/wp-content/uploads/2010/03/AdMob-Mobile-Metrics-Jan-10-Survey-Supplement.pdf

http://metrics.admob.com/wp-content/uploads/2010/03/AdMob-Mobile-Metrics-Jan-10-Survey-Supplement.pdf

http://macformat.techradar.com/blog/iphone-data-usage-survey-results-15-06-10

http://macformat.techradar.com/blog/iphone-data-usage-survey-results-15-06-10

http://www.localytics.com/blog/post/iphone-analytics-show-peak-mobile-app-usage-on-nights-weekends/

http://www.localytics.com/blog/post/iphone-analytics-show-peak-mobile-app-usage-on-nights-weekends/

http://developer.apple.com/library/ios/#documentation/WindowsViews/Conceptual/ViewPG_iPhoneOS

http://developer.apple.com/library/ios/#documentation/WindowsViews/Conceptual/ViewPG_iPhoneOS

https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/CocoaFundamentals

https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/CocoaFundamentals

https://developer.apple.com/library/ios/#documentation/AudioVideo/Conceptual/MultimediaPG/Introduction/Introduction.html



LITERATURA Stran 95

[46] Getting Started with Graphics and Animation, https://developer.apple.com/

library/ios/#referencelibrary/GettingStarted/GS_Graphics_iPhone/,

2010, obiskano 8. 9. 2010

[47] Quartz 2D Programming Guide, https://developer.apple.com/library/ios/

documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/, 2010,

obiskano 8. 9. 2010

[48] Core Animation Programming Guide, http://developer.apple.com/library/

ios/#documentation/Cocoa/Conceptual/CoreAnimation_guide, 2010, obi-

skano 10. 9. 2010

[49] Animation Types and Timing Programming Guide, http://developer.apple.

com/library/ios/#documentation/Cocoa/Conceptual/Animation_Types_

Timing, 2010, obiskano 13. 9 .2010

[50] OpenGL ES Programming Guide for iOS, http://developer.apple.

com/library/ios/#documentation/3DDrawing/Conceptual/OpenGLES_

ProgrammingGuide/, 2010, obiskano 10. 1. 2011

[51] R. S. Wright, B. Lipchak. N. Haemel, OpenGL SuperBible, 4. izdaja, Pearson

Education, 2007

[52] B. Lipus, Graficni programski vmesnik, Diplomska naloga, Fakulteta za elektro-

tehniko, racunalnistvo in informatiko, Univerza v Mariboru, Maribor, 2000

[53] iTorque 2D, http://www.garagegames.com/products/torque-2d/iphone/,

2011, obiskano 14. 1. 2010

[54] cocos2d, http://www.cocos2d-iphone.org/, obiskano 14. 1. 2010

[55] Unity, http://unity3d.com/unity/, obiskano 14. 1. 2010

[56] SIO2 Engine, http://sio2interactive.com/, 2011, obiskano 14. 1. 2010

[57] Oolong Engine, http://code.google.com/p/oolongengine/, obiskano 14. 1.

2010

[58] P. Cabrera, J. Bondo, A. Fothergill, B. Greenstone, O. Hennessy, M. Kasprzak,

M. Lee, R. Zito, M. Aitken, C. Kane, iPhone Games Projects, Apress, 2009

LITERATURA Stran 95

https://developer.apple.com/library/ios/#referencelibrary/GettingStarted/GS_Graphics_iPhone/

https://developer.apple.com/library/ios/#referencelibrary/GettingStarted/GS_Graphics_iPhone/

https://developer.apple.com/library/ios/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/

https://developer.apple.com/library/ios/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/

http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/CoreAnimation_guide

http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/CoreAnimation_guide

http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/Animation_Types_Timing



http://developer.apple.com/library/ios/#documentation/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/



http://www.garagegames.com/products/torque-2d/iphone/

http://www.cocos2d-iphone.org/

http://unity3d.com/unity/

http://sio2interactive.com/

http://code.google.com/p/oolongengine/

Stran 96 LITERATURA

[59] Adobe Flash Player, http://www.adobe.com/products/flashplayer/, 2010,

obiskano 10. 11. 2010

[60] Adobe Gives Up on Flash for iPhone, iPad, http://www.wired.com/gadgetlab/

2010/04/adobe-flash-iphone/, 2010, obiskano 10. 11. 2010

[61] Packager for iPhone, http://labs.adobe.com/technologies/

packagerforiphone/, 2010, obiskano 10. 11. 2010

[62] S. Petersen, Optimizing content for Apple iOS devices, http://www.adobe.com/

devnet/flash/articles/optimize_content_ios.html, obiskano 1. 12. 2010

[63] Video game music, http://en.wikipedia.org/wiki/Video_game_music, obi-

skano 3. 3. 2011

[64] Core Audio Overview, https://developer.apple.com/library/ios/

#documentation/MusicAudio/Conceptual/CoreAudioOverview/, 2010, obi-

skano 22. 10. 2010

[65] cocos2d, http://www.cocos2d.org/, 2010, obiskano 23. 3. 2011

[66] cocos2d-x, http://www.cocos2d-x.org, obiskano 23. 3. 2011

[67] cocos2d-android, http://code.google.com/p/cocos2d-android-1/, obiskano

23. 3. 2011

[68] Cocos2D JavaScript, http://www.cocos2d-javascript.org, obiskano 20. 3.

2011

[69] cocos2d, http://www.cocos2d-iphone.org/games/, obiskano 20. 3. 2011

[70] Hiero, http://www.n4te.com/hiero/hiero.jnlp, obiskano 20. 3. 2011

[71] Bitmap Font Generator, http://www.angelcode.com/products/bmfont/, 2011,

obiskano 20. 3. 2011

[72] Zwoptex, http://zwoptexapp.com/flashversion, 2010, obiskano 12. 2. 2011

[73] cocos2d for iPhone wiki, http://www.cocos2d-iphone.org/wiki/doku.php/,

2010, obiskano 13. 1. 2011

[74] Particle Designer, http://particledesigner.71squared.com, 2010, obiskano

13. 1. 2011

Stran 96 LITERATURA

http://www.adobe.com/products/flashplayer/

http://www.wired.com/gadgetlab/2010/04/adobe-flash-iphone/

http://www.wired.com/gadgetlab/2010/04/adobe-flash-iphone/

http://labs.adobe.com/technologies/packagerforiphone/

http://labs.adobe.com/technologies/packagerforiphone/

http://www.adobe.com/devnet/flash/articles/optimize_content_ios.html

http://www.adobe.com/devnet/flash/articles/optimize_content_ios.html

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

https://developer.apple.com/library/ios/#documentation/MusicAudio/Conceptual/CoreAudioOverview/

https://developer.apple.com/library/ios/#documentation/MusicAudio/Conceptual/CoreAudioOverview/

http://www.cocos2d.org/

http://www.cocos2d-x.org

http://code.google.com/p/cocos2d-android-1/

http://www.cocos2d-javascript.org

http://www.cocos2d-iphone.org/games/

http://www.n4te.com/hiero/hiero.jnlp

http://www.angelcode.com/products/bmfont/

http://zwoptexapp.com/flashversion

http://www.cocos2d-iphone.org/wiki/doku.php/

http://particledesigner.71squared.com

LITERATURA Stran 97

[75] POWERVR Insider FAQ, http://www.imgtec.com/powervr/insider/

powervr-faq.asp, obiskano 9. 1. 2011

[76] TexturePacker, http://www.texturepacker.com/, 2010, obiskano 11. 2. 2011

[77] Box2D Physics Engine, http://www.box2d.org/, 2011, obiskano 13. 1. 2011

[78] Fast and lightweight 2D rigid body physics library in C, http://code.google.

com/p/chipmunk-physics/, 2010, obiskano 13. 1. 2011

[79] Chipmunk SpaceManager, http://code.google.com/p/

chipmunk-spacemanager/, 2010, obiskano 16. 1. 2011

[80] S. Itterheim, Learn iPhone and iPad cocos2d Game Development, Apress, 2010

[81] Box2D, http://en.wikipedia.org/wiki/Box2D, 2011, obiskano 10. 1. 2011

[82] Chipmunk physics engine, http://en.wikipedia.org/wiki/Chipmunk_

physics_engine, 2010, obiskano 10. 1. 2011

[83] T. Fullerton, C. Swain, S. Hoffman , Game Design Workshop: Designing, Proto-

typing, and Playtesting Games, CMP Books, 2004

[84] A. Rollings, D. Morris, Game Architecture and Design, New Riders Publishing,

2004

[85] B. Bates, Game Design, 2. izdaja, Course Technology PTR, 2004

[86] O. V. Polikarpotchkin, P. Lee, Draw a Smooth Curve through a Set of 2D

Points with Bezier Primitives, http://www.codeproject.com/KB/graphics/

BezierSpline.aspx, 2010, obiskano 16. 10. 2010

[87] Submitting iPhone Apps To The Apple App Store – A Step by Step Gu-

ide, http://www.edumobile.org/iphone/iphone-programming-tutorials/

submitting-iphone-apps-to-the-apple-app-store-a-step-by-step-guide/,

2010, obiskano 20. 3. 2011

LITERATURA Stran 97

http://www.imgtec.com/powervr/insider/powervr-faq.asp

http://www.imgtec.com/powervr/insider/powervr-faq.asp

http://www.texturepacker.com/

http://www.box2d.org/

http://code.google.com/p/chipmunk-physics/

http://code.google.com/p/chipmunk-physics/

http://code.google.com/p/chipmunk-spacemanager/

http://code.google.com/p/chipmunk-spacemanager/

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

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

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

http://www.codeproject.com/KB/graphics/BezierSpline.aspx

http://www.codeproject.com/KB/graphics/BezierSpline.aspx

http://www.edumobile.org/iphone/iphone-programming-tutorials/submitting-iphone-apps-to-the-apple-app-store-a-step-by-step-guide/

http://www.edumobile.org/iphone/iphone-programming-tutorials/submitting-iphone-apps-to-the-apple-app-store-a-step-by-step-guide/

rok pov se razvoj iger za ios diplomsko delokeywords: ios, iphone, ipad, ipod touch, game...

Documents