uporaba orodij unity3d in blender za … two conceptually different worlds and try to make our own...

Diplomsko delo univerzitetnega študija

Organizacija in management informacijskih sistemov

UPORABA ORODIJ UNITY3D IN BLENDER ZA RAZVOJ IGER NA

ANDROIDU

Mentor: doc. dr. Davorin Kofjač Kandidat: David Čeh

Kranj, september 2015

ZAHVALA

Zahvaljujem se mentorju doc. dr. Davorinu Kofjaču za pomoč in nasvete pri izdelavi

diplomskega dela kot tudi veliko količino potrpljenja.

Zahvaljujem se tudi staršem in nečakom za testiranje moje aplikacije.

POVZETEK

V diplomskem delu spoznavamo industrijo videoiger in kaj nas motivira da igramo

igre. Osnujemo načrt za razvoj igre, ki ga razdelimo na dva konceptuelno različna

načina in se po tem principu poskusimo lotiti lastnega projekta. Spoznavamo

delovanje orodij Unity3D in Blender ter osnovne tehnike modeliranja, teksturiranja

in pisanja skript, katerih končni produkt je igra za Android napravo.

KLJUČNE BESEDE

Blender

3D modeliranje,

Unity3D,

razvoj iger,

igralni pogon.

ABSTRACT

In this diploma thesis we get familliar with the videogame industry and what

motivates us to play games. We form a plan to develop a game, which we divide

into two conceptually different worlds and try to make our own project based on

that principle. We get to know how the Unity3D and Blender tools work and also get

acquainted with the basic techniques of modelling, texturing and writing of

behavioral scripts which all result in a finished game for an Android device.

KEYWORDS

Blender,

3D modelling,

Unity3D,

game development,

game engine.

KAZALO

1. UVOD ........................................................................................................ 1

1.1. Opredelitev problema ........................................................................... 1

1.2. Cilji naloge .......................................................................................... 1

1.3. Metodologija ....................................................................................... 1

2. INDUSTRIJA IGER ...................................................................................... 2

2.1. Predstavitev industrije .......................................................................... 2

2.2. Igralni pogon in igra............................................................................. 2

2.3. Licenčna vojna .................................................................................... 3

2.4. Stanje pri nas in v regiji ........................................................................ 3

2.5. Kaj dela igre zabavne ........................................................................... 3

2.6. Predstavitev ciljne platforme ................................................................. 6

3. NAČRTOVANJE IGRE .................................................................................. 7

3.1. Načrtovanje vizualnega stila .................................................................. 7

3.2. Perspektivna projekcija in ortografska projekcija ..................................... 8

3.3. Proces dela ......................................................................................... 9

3.4. Postavitev delovnega okolja .................................................................. 9

4. OBLIKOVANJE ........................................................................................... 11

4.1. Modeliranje ........................................................................................ 11

4.2. Teksture ............................................................................................ 15

4.3. Proces teksturiranja ............................................................................ 16

4.4. Prednosti in slabosti Blenderja ............................................................. 21

5. RAZVOJ IGRALNEGA OKOLJA ..................................................................... 22

5.1. Predstavitev Unitya ............................................................................. 22

5.2. GameObject in komponente ................................................................. 24

5.3. Prikaz objektov v Unityu ...................................................................... 26

5.4. Sistemi delcev .................................................................................... 29

5.5. Umetna inteligenca v igrah .................................................................. 30

5.6. Pisanje skript ...................................................................................... 31

5.7. Uporabniški vmesnik / HUD ................................................................. 34

5.8. Unity prednosti in slabosti.................................................................... 35

6. Zaključek .................................................................................................. 37

Literatura in viri ............................................................................................... 38

Kazalo slik ....................................................................................................... 40

Univerza v Mariboru – Fakulteta za organizacijske vede Diplomsko delo univerzitetnega študija

David Čeh: Uporaba orodij Unity3d in Blender za razvoj iger na Androidu stran 1

1. UVOD

1.1. Opredelitev problema

V industriji je opazen porast t.i. indie iger, ki jih ustvarjajo razvijalci, ki niso podprti s

strani založnika, a so jim zaradi tega pri kreiranju prepuščene proste roke, finančni

uspeh nekaterih njihovih proizvodov pa presega prodajne rezultate veliko večjih

projektov, ki so za seboj imeli zelo močan marketing.

S porastom neodvisnih razvijalcev indie-iger se je posledično razširilo število iger. Iz

tega je pričela izhajati potreba po igralnih pogonih, ki omogočajo razvoj kvalitetne

igre na hiter, preprost in intuitiven način. Razvoj lastnega igralnega pogona bi

namreč predstavljal prevelik zalogaj za manj izkušene razvijalce. Na voljo so

komercialni in odprtokodni igralni pogoni. V diplomskem delu se bomo osredotočili

na uporabo igralnega pogona Unity3D, ki ga bomo skupaj z orodjem Blender,

namenjemu za 3D modeliranje in animacijo, uporabili za razvoj preproste igre za

platformo Android. Pri razvoju indie-iger predstavljajo izziv predstavljajo tudi zvočni

efekti in drugi zvočni zapisi. Le-te je najlažje pridobiti na internetu, vendar pa se

lahko pojavijo težave z avtorskimi pravicami.

1.2. Cilji naloge

Cilj diplomskega dela je bil analizirati orodji Unity3D in Blender glede primernosti za

razvoj iger na Androidu. Analizirane so bile prednosti in slabosti obeh orodij in sicer

na primeru razvoja preproste igre za Android mobilne naprave.

1.3. Metodologija

Za izdelavo igre smo preučili primere dobrega in slabega dizajna v razširjenih

mobilnih igrah in izkušnje uporabili za izdelavo svojega. Preučili smo delovanje

Blenderja za izdelavo modelov, Unity3D za izdelavo stopenj v igri, menijev in skript,

ki smo jih pisali v povezavi z Microsoft Visual Studiem.



2. INDUSTRIJA IGER

2.1. Predstavitev industrije

Industrija videoiger se je od usmerjenega trga skozi leta preobrazila v »mainstream« industrijo, ki je po ocenah na spletni strani "vgsales.com" iz leta 2013 globalno težka 76 milijard dolarjev, in od leta 2007 stalno prekaša glasbeno in filmsko industrijo v Združenih državah Amerike (Videogame industry, 2015).

Spremenili so se trendi in način razmišljanja – ne govorimo več o »igricah,« ker si ta velikan zabavne industrije enostavno reže prevelik kos potice, da bi ga še naprej obravnavali le kot hecno zanimivost.

To je industrija, ki se je priplazila od namiznih računalnikov do dnevne sobe kot tudi v žepe svojih potrošnikov. Ni več industrija namenjena le otrokom, ampak je industrija, ki streže porabniku, ki je v povprečju star 34 let in porabi tekom tedna v povprečju 8 ur za igranje iger, kar počne v povprečju že zadnjih 12 let, posledično je delež gospodinjstev v ZDA, ki igra igre 67% (Videogame industry statistics, 2015).

Ker so za to industrijo potrebni tako veliki vnosi, ki so tudi tvegani – tudi dobre ideje, hvaljene s strani kritikov, lahko spodletijo, če ne dosežejo prodajnih rezultatov, ima ta industrija znotraj svojega jedra tog sistem založništva, ki v ogromno primerih ni pripravljen tvegati kapitala za idejo, ki se nekomu, ki ponavadi ne igra, niti ne ustvarja iger, zdi slaba, zato je na trgu zaradi dostopnosti programske opreme in novih možnosti digitalne distribucije, v industriji iger tudi opazen porast t. i. "indie" razvoja. Termin, ki se uporablja kot kontrast "triple A (AAA)" razvoju, terminu namenjenemu za projekte z večjim proračunom za produkcijske stroške in promocijo, ki tvegajo več, za večji dobiček – trenutni rekorder je igra Destiny, katere celotni stroški marketinga in produkcije so znašali kar 500 milijonov dolarjev (AAA videogame industry, 2015).

Indie razvijalci so neodvisni od založnika, zato imajo proste roke pri ustvarjanju

svojih iger. Nekateri med njimi so uspeli zaslužiti z zavrnjeno idejo, ali pa vsaj resno

premakniti splošno definicijo tega, kaj igra sploh je. S programerskega vidika je

razvoj lastnega igralnega pogona zahtevna, velikokrat pa tudi finančno tvegana

odločitev, zato pridejo za male, neodvisne razvijalce v poštev že obstoječi igralni

pogoni, katerih uporaba ima lahko neko fiksno ceno ali pa ceno v smislu deleža od

prodaje.

2.2. Igralni pogon in igra

Igralni pogoni ponujajo komponente za ponovno uporabo, s katerimi je možno upravljati na način, da ustvarimo igro. Komponente, ki lahko sestavljajo igralni



pogon, so animacija modelov, zaznavanje trkov med objekti, fizika, input (vnos), GUI, delci umetne inteligence, nalaganje in njihov prikaz. Po drugi strani pa igro sestavljajo vsebina, specifični modeli, teksture in namen, ki je za trki med temi objekti, način, na katerega delujejo med seboj (What is a game engine, 2015).

Trenutno so predstavniki najbolj popularnih igralnih pogonov Unity3D, Unreal Engine, Cry Engine 3, Havok, Vision Engine, GameMaker. Vsi imajo svoje prednosti in slabosti, omejitve in inovacije; nekatere med njimi je možno tudi razbiti na osebne preference. A na koncu je v središču pozornosti igra, ki je narejena s pogonom in ne zmogljivost orodja ali licenčni pogoji uporabe.

2.3. Licenčna vojna

V začetku marca 2015 je prišlo do velikega preobrata za razvijalce iger, saj so v istem tednu trije veliki igralni pogoni oznanili, da bo odtlej njihova uporaba zastonj. Med njimi Unreal Engine 4, Source 2 engine kot tudi Unity5, ki se je pred tem delil na zastonjsko in licenčno verzijo.

2.4. Stanje pri nas in v regiji

20. 3. 2015 je v Kristalni Palači v BTC-ju potekala prva konferenca za razvoj iger, ki bi se lahko smatrala za prvo slovensko srečanje, ki smo jo iz radovednosti obiskali tudi sami.

Namen srečanja je bil, da bi organizatorji videli, kolikšno je zanimanje za združenje razvijalcev iger in koliko je sploh razvijalcev iger pri nas, predvsem tistih, ki še niso znani javnosti. S tem bi se lahko razvila socialna mreža za produciranje idej okoli trženja in distribucije iger.

S tem smo Slovenci napravili prvi korak, da bi sledili svojim sosedom Hrvatom z Reboot-om in Avstrijcem z Games Austria. Obe združenji sta namreč uradno priznani društvi, ki ciljata na to, da bi na GDC-ju (Games Developers Conference, ki poteka v San Franciscu) imeli skupen kiosk kot razvijalci Srednje Evrope.

2.5. Kaj dela igre zabavne

Igre so uganke, ki jih rešujemo, kot vse ostalo, s čimer se srečamo v življenju. So na podobnem nivoju kot uporabe računskih tabel, učenje igranja inštrumenta ali vožnje avtomobila (kar pa ne pomeni, da le s poznavanjem cestnih pravil in upravljanja z vozilom, usvojimo vse potrebno za vožnjo). Z njimi se učimo vzorcev in jih shranjujemo, da jih lahko po potrebi uporabimo. Glavna razlika med igro in resničnostjo je v tem, da v igrah ni eksistencialnega tveganja (Koster, 2004).

A igre trčijo tudi na svoje omejitve. Po eni strani jih njihove omejitve naredijo igre, po drugi pa je največja med njimi je njihova narava: so vaja za možgane in igre, ki jim spodleti razgibati možganene, so dolgočasne. To je tudi razlog, da igri križcev in krožcev sčasoma spodleti – so omejena vaja, saj za usvajanje vseh možnih stanj ni



treba zapravljati veliko časa. Ko se naučimo vzorcev, je potrebno več novosti, da postane igra zanimiva.

Skoraj vse igre so podvržene temu, zaradi omejenosti formalnega sistema svojega delovanja. V kolikor jih igramo, jih sčasoma dojamemo. Posledično je dolgčas neizogiben.

Izjemno formalne igre so bolj podvržene matematični analizi, ki je sama po sebi omejitev. Zelo formalne igre (kot na primer večina namiznih) ima zelo malo spremenljivk in navadno lahko ekstrapoliramo načine igranja iz že znanega seta pravil. Da je igra torej bolj obstojna mora vsebovati več nians (in še več nepredvidljivih ali težje predvidljivih), kot sta, denimo, fizika in človekova psihologija.

Vsakdanji izzivi življenja, na katere igre izključno pripravljajo, temeljijo na preračunavanju verjetnosti. Učijo nas predvideti dogodke. Veliko število iger simulira neke vrste bojevanj in celo igre, ki temeljijo na grajenju stvari, ker počnejo v okviru tekmovanja.

Če vzamemo v zakup to, da smo v bistvu zelo hierarhični in plemenski primati, ni nobeno presenečenje, da večina lekcij, ki jih dobimo v zgodnjem otroštvu z igro so o moči in statusu, ne glede na našo kulturo. Igre nas skoraj vedno učijo biti »glavna opica.«

Igre nas učijo kako opazovati okolje oziroma prostor okoli nas. Od iger, kjer skupaj povezujemo oblike, do iger, kjer se učimo opazovati nevidne linije projekcije moči vzdolž kvadratnega polja – kar v goli osnovi igra križci in krožci tudi je.

Razmerja znotraj prostora so za nas tudi pomembna. Nekatere živali se lahko usmerjajo z uporabo Zemljinega magnetnega polja, ampak mi uporabljamo zemljevide, s katerimi označujemo tudi različne stvari, ne samo prostora. Učenje interpretacij simbolov, ocena razdalje, ocena tveganja in pomnjenje lokacij lovišč so bili pomembni, ko smo bili nomadska ljudstva. Mapiramo stvari, kot so temperatura, socialna razmerja in časovne dogodke. Raziskovanje okolja ustreza naši naravi uporabe orodij. Učimo se, kako stvari sodijo skupaj, igramo igre, v katerih stvari dajemo skupaj, ne samo fizično ampak tudi konceptualno.

Drug tip raziskovalnih iger, so igre raziskovanja prostora verjetnosti. Igre na srečo so igre, v katerih raziskujemo prostore možnosti in nas učijo o verjetnosti.

Nekateri resnično pomembni deli raziskovanja vključujejo spomin. Veliko število iger temelji na pomnjenju in upravljanju dolgih in kompleksnih verig informacij (igranje kart ali tekmovalni domino). Veliko iger vključuje temeljito raziskovanje prostora verjetnosti kot del pogoja za zmago.

Na koncu ima velika večina iger nekaj opravka z močjo. Celo najbolj nedolžne igre iz otroštva imajo nasilje nekje globoko v svojem jedru. Tudi igranje »odraslih« se vrti okoli socialnega statusa, v katerih nekateri izvajajo avtoriteto nad ostalimi.

Če vzamemo v zakup igre, ki zadnje čase dobivajo veliko pozornosti: strelske, pretepaške in vojne igre, niso preveč subtilne okoli svoje ljubezni do moči. Razlika



med igranjem teh iger in igranjem policajev in roparjev, je, kar se tiče tistih, ki igrajo, majhna. Temeljijo na reakciji, taktični zavesti, ocenjevanju šibkosti nasprotnika in presojanju kdaj napasti.

Pozornost po navadi namenjamo jasno razvidni nasilni naravi teh iger in s tem zgrešimo subtilno lekcijo, ki jo dajejo pod svojo vrhnjo plastjo – naj bodo policisti ali roparji, ali videoigra Counter Strike (Slika 1), resnična lekcija, ki jo te igre prinašajo, ni učenje merjenja s pištolo, ampak skupinsko sodelovanje, ki je v videoigrah veliko bolj učinkovito kot ostrostrelstvo.

Slika 1: Posnetek iz igre Counter Strike (vir: lasten)

Veliko igram, predvsem tistim, ki so se razvile v klasične olimpijske športe, lahko sledimo vse do potreb naših prednikov, da preživijo v težkih pogojih. Veliko stvari, ki nas zabava nas uči biti boljši jamski človek. Učimo se veščin, katere uporabnost je zapadla – večini ljudem ni potrebno več loviti z lokom, da bi jedli in maratoni se tečejo samo še v dobrodelne namene. Ne glede na vse, se zabavamo s tem, ko se izboljšujemo, kot se s časom spreminjajo igre, ki jih igramo. Iger, v katerih kmetujemo, je zelo malo na trgu po drugi strani pa so se spreminjale tudi igre, ki jih še vedno igramo – šah je v zgodnjih verzijah imel veliko šibkejšo kraljico (op. v shatranj, predhodniku šaha se je figura imenovala vezir).

Igre se razvijajo. Četudi ne tako hitro, kot bi hoteli, saj je večina iger v svojem jedru skupek približno enakih aktivnosti, ki vključujejo različne sete veščin (od katerih so nekatere uporabne in nekatere ne).



Lekcije, ki nam jih igre prinesejo, bi torej lahko razdelili v naslednje skupine (Koster, 2004):

merjenje, časovno načrtovanje, lovljenje, projeciranje moči, ozemlje.

Po filozofiji avtorja tega besedila, ki trdi, da so igre zabavne, zato ker je učenje novih veščin zabavno, bomo zatorej poskušali napraviti igro, v kateri bo ključno:

projiciranje moči – salvo izstrelkov na neki višini bo lahko zagotovil glavnemu igralcu trenutek varnosti;

merjenje – cilj je potrebno zadeti, časovno načrtovanje – sovražnika je potrebno zadeti preden on zadane nas,

ali pa se njegovim izstrelkom izmakniti.

2.6. Predstavitev ciljne platforme

Android je mobilni operacijski sistem, ki bazira na jedru Linux in ga trenutno razvija Google. Android je z uporabniškim vmesnikom, ki temelji na direktnem upravljanju, primarno razvit za mobilne naprave z zaslonom na dotik kot so pametni telefoni in tablični računalniki, uporablja pa se ga tudi s specializiranimi uporabniškim vmesnikom za televizije (Android TV), avtomobile (Android Auto) in ure (Android Wear). Operacijski sistem uporablja vnose, ki temeljijo na gibih iz realnega sveta, kot so drsenje, tapkanje, ščipi navznoter in navzven, s katerimi upravljajo z elementi, ki so na ekranu (npr. ikone, virtualna tipkovnica…). Četudi je primarno razvit za vnos na napravah, ki imajo zaslon na dotik, se uporablja tudi pri igralnih konzolah, digitalnih kamerah, osebnih računalnikih in drugih elektronskih napravah (Android - operating system, 2015).

V času pisanja diplomske naloge se je po celem svetu dnevno aktiviralo milijon novih Android naprav vsak dan. Android je najhitreje rastoča mobilna platforma. Na Google Play-u se vsak mesec prenese 1,5 milijarde aplikacij. Kombinacija odprtokodnega sistema Linux in odprtosti za razvijalce programske opreme, kot tudi široka paleta proizvajalcev teh naprav, je to platformo utrdila kot trenutno najmočnejšo na trgu mobilnih telefonov, kakor tudi tabličnih računalnikov in temu trendu zaenkrat ni videti konca (Android, the world's most popular mobile platform, 2015). To je naša ciljna platforma, za katero bomo razvijali igro.



3. NAČRTOVANJE IGRE Ker uporabljamo zmogljiva orodja, katerih učenje uporabe je zahtevno (čas pa je omejen, kot tudi obseg znanja, ki ga posedujemo o razvoju iger) je ključno, da si zastavimo cilje, ki so dosegljivi. Namen je ustvariti igro, ki temelji na reakciji, v kateri:

definiramo svoj vizualni stil, ki obsega vse od razvoja modelov do uporabniškega vmesnika,

ustvarimo igralca, ki je vesoljsko plovilo in se premika in strelja na podlagi ukazov preko zaslona na dotik,

ustvariti nasprotnike, pri katerih bodo prisotni elementi naključnosti, narediti neskončno igro, ki jo je mogoče samo izgubiti.

Naš cilj je ustvariti igro brez pomoči, t.i. »Unity Asset store«. Avtor vseh elementov, tudi tistih najbolj generičnih, smo sami. Pravzaprav pa v osredju pozornosti ni vsebina igre, saj ta služi le kot primer učenja vzorcev, ki jih je potrebno usvojiti, da se ustvarjajo drugi tipi iger.

3.1. Načrtovanje vizualnega stila

Obstajajo 3 glavne grafične kategorije:

samo tekst (brez grafike), 2D grafika, 3D grafika.

Danes je večina komercialnih iger narejena s pomočjo 3D tehnologije, tudi če uporabljajo 2D pogled. Razlog za to je, da je lažje in hitreje modelirati objekte in okolja z uporabo današnjih 3D orodij. V osnovi je potem 2D igra kreirana s 3D orodji. Popolnoma možno je ustvariti dobre igre v 2D perspektivi, ampak verjetno je, da bo ustvarjena s 3D orodji.

Vidiki 2D grafike vključujejo (Perry, 2009):

Stranski pogled - pogost je v platformnih arkadnih igrah, katere zgodnje igre vključujejo Defender, Pitfall, Donkey Kong. Uporabljen je v miselnih igrah kot Tetris in Bubble Bobble. Obstajajo različice tega pogleda, kot je statični stranski pogled za dva igralca (Pong) ali premikajoči stranski pogled po eni sceni (Jordan vs. Bird: One on One).

Tlorisni pogled - s tem pogledom igralec gleda navzdol na dogajanje. Uporabljen je v igrah kot je Pac-Man, Ultima, The Legend of Zelda: Link's Awakening. Veliko namiznih iger, kot je Monopoly, in igre s kartami so bile (in še vedno so) prikazane iz perspektive zgoraj-dol.

Izometrični pogled - je rahlo nagnjena tlorisna perspektiva, ki daje vtis globine. Znane franšize primerov: Pokemon, Baldur's Gate.



Ponarejeni prvo-osebni pogled - pogled na svet s prve perspektive, ki uporablja izginjajočo grafiko za iluzijo globine v popolnoma 2D okolju. Pogosta je v zgodnjih labirintnih igrah, kot je na primer Wizardry. Včasih uporablja za to iluzijo polnjenje z barvo, včasih wireframe grafiko, da še bolj poglobi vtis 3D.

Ponarejeni tretje-osebni pogled - podobno kot ponarejeni prvo-osebni pogled, le da je mogoče videti tudi igralčev lik. Primer je arkadna strelska igra Tempest.

Pogled iz kabine – uporablja perspektivo iz vozila, naj bo to avto, letalo, tank, ladja, podmornica ali vesoljska ladja. Zgodnji primeri vključujejo Battlezone, Formula One, zgodnje verzije Microsoft Flight Simulatorja.

Naša igra bo narejena s pomočjo 3D modelirnega orodja, s fiksno 2D kamero iz enakih razlogov, kot je navedel avtor besedila – lažje in hitrejše ustvarjanje, a pri 3D izrisu grafike se pojavi še vprašanje projekcije slike.

3.2. Perspektivna projekcija in ortografska projekcija

Naše oči so navajene na perspektivno projekcijo, saj so bolj oddaljeni predmeti skozi njo manjši. Ortografska projekcija se na prvi pogled zdi nenavadna, sami objekti ostanejo iste velikosti, neodvisno od razdalje. Je kot gledanje na sceno z neskončno oddaljene točke. Ne glede na to je ortografski pogled zelo uporaben in je privzet pogled v večini 3D modelirnih programov, ker omogoča bolj tehničen vpogled na sceno, s katerim se lažje določa razmerja objektov (Slika 2) (3D View-Blenderwiki, 2015).

Slika 2: Primerjava perspektiv (vir: http://wiki.blender.org/index.php/Doc:2.4/Manual/3D_interaction/Navigating/3D_Vi

ew)



Omenjena pogleda sta nam na voljo v orodju Unity, kot pogleda iz glavne kamere na sceno. Cilj je namreč ustvariti igro, v kateri bomo naše ustvarjene tridimenzionalne objekte povezali v celoto, ki bo dajala pristnejši vtis dvodimenzionalne igre.

3.3. Proces dela

Na večjih in kompleksnejših projektih dela veliko ljudi, ki so strokovnjaki na različnih področjih. Tudi za ustvarjanje lastne igre potrebujemo določene spretnosti in znanja, ki jih lahko posplošeno razdelimo na dva med seboj konceptualno različne dela:

oblikovanje, razvoj igralnega okolja in programiranje.

Naš del oblikovanja bo zajemal ustvarjanje in oblikovanje tridimenzionalnih modelov v programu Blender 3D, v katerem bomo ustvarili, t.i. »UV layout«. S tem bomo lahko kasneje v Gimpu uredili teksture za te modele.

Delo za dizajn bi torej lahko razdelili na:

modeliranje, ustvarjanje tekstur,

apliciranje tekstur, ustvarjanje uporabniškega vmesnika.

Modeliranje mrež (mesh) in apliciranje tekstur bomo izvajali v Blenderju. Teksture bodo narejene v Gimpu, aplicirale se bodo v Blenderju, uporabniški vmesnik bo definiran z Inkscape, katerih format bo nato pretvorjen v .png obliko v Gimpu. Vsi ti elementi bodo na koncu uvoženi v Unity.

Naš del programiranja bo v glavnem obsegal pisanje skript. Te bodo poskrbele, da bomo z modeli lahko upravljali, definirale bodo njihovo delovanje in zapovedovala pravila igre.

Razvoj igralnega okolja bi v bistvu težko opredelili kot samostojen korak, ki sledi tema dvema konceptualnima svetovoma, po svoji naravi namreč predstavlja most med programiranjem in dizajnom in je proces, ki bo v celoti potekal v Unityu.

3.4. Postavitev delovnega okolja

Če hočemo začeti razvijati igre za platformo Android v Unityu, je najprej potrebna postavitev okolja z vsemi aplikacijami in orodji, ki jih bomo potrebovali. Orodja in aplikacije so sledeče:

Unity pri namestitvi ne zahteva ničesar posebnega in načeloma poteka brez težav. Pred tem je dobro preveriti, če ima nameščena verzija težave s t.i. »buildanjem« na platformo, na kateri želimo delati (za čas pisanja diplomske



smo uporabljali verzijo 4.6.1, pri kateri je bila namestitev na Android naprave zaradi napake nemogoča). Inštalacija Unitya vsebuje še IDE MonoDevelop;

namestitev programa Blender; Java Development kit je potreben za namestitev Android SDK; Android SDK – prenesemo in naložimo ustrezen API glede na napravo, na

kateri bi izgradili igro. Unityev minimalni API je 9 (torej za vse, kar je novejše od Androida 2.3 znanega tudi kot »GINGERBREAD«). V našem primeru smo se odločili za minimalni API 15 (ICE_CREAM_SANDWICH_MR1), zaradi operacijskega sistema naprave, na kateri smo testirali, t.i. »build«. V Unity-u dodamo lokacijo android SDK-ja pod Preferences> External Tools.

Namestitev Gimp-a in Inkscape-a:

Unity Remote je aplikacija, ki jo bomo naložili na testno napravo z Google Play-a. Na računalniku v SDK mapi pod platform-tools odpremo ukazno vrstico (command prompt), kjer bomo z ukazom »adb devices« preverili ali je uspel Windows najti USB gonilnike za testno napravo. V kolikor je testna naprava Googlova (npr. Nexus), dobimo Googlove USB gonilnike preko SDK managerja; ostali so odvisni od proizvajalca in jih moramo poiskati glede na model. Ne glede na naloženo, bomo morali na telefonu, na katerem bomo uporabljali Unity Remote, vklopiti USB razhroščevanje (USB debugging). To je opcija, ki se na večini telefonov in tabličnih računalnikih skriva pod nazivom »Developer options.« V project setting v Unity-ju bomo morali obkljukati tudi možnost »Any Android device«.

Uporabimo lahko tudi drug IDE, ki ni MonoDevelop. Zaradi osebnih preferenc sem jaz naložil Microsoft Visual Studio, ki se doda v Unity-u pod Edit>Preferences>External Tools.

Z adb testom v ukazni vrstici (zaznana naprava na sliki 3) bo postavitev našega okolja končana in lahko bomo začeli delom.

Slika 3: Končan adb test (vir: lasten)



4. OBLIKOVANJE

4.1. Modeliranje

Blender je neplačljiva in odprtokodna 3D animacijska programska rešitev. Podpira celoten 3D razvojni tok – modeliranje, ustvarjanje skeleta, animacijo, simulacijo, senčenje, kompozicijo, zaznavanje gibov in celo urejanje videoposnetkov in ustvarjanje iger. Napredni uporabniki uporabljajo Blenderjev API za pisanje skript in prilagajanje aplikacij po svojih potrebah. Nekatere te rešitve so podane v naslednji uradni verziji Blenderja, ki izide. Blender ustreza individualnim uporabnikom, kot tudi majhnim studijem in zaradi vmesnika, ki uporablja OpenGL, deluje na platformah Windows, Linux in OSx. To je skupni projekt široke skupnosti, saj je pod GNU General Public Licence, katere uporabniki stalno izdajajo manjše popravke v kodi in povečujejo njegovo uporabnost (About Blender, 2015).

Slika 4: Blenderjev uporabniški vmesnik (vir:lasten)

Mesh je kolekcija oglišč, robov in stranic, ki definirajo tridimenzionalni objekt (na zgornji sliki so denimo v osredju scene postavljen mesh kocke). Sicer mesh sam po sebi nima nobene barve, le obliko, a je zaradi uporabnikove vizualne reprezentacije v večini programov, ki se ukvarjajo s tridimenzionalnim modeliranjem prekrit z nekim materialom, ki je ponavadi bele barve (kot npr. krožnica pri krogu, ki služi vizualni predstavitvi, četudi točke, ki so enako oddaljene od središča, same po sebi nimajo nobene velikosti) (Blender3D What is a Mesh, 2015).



Blender ponuja več načinov upravljanja s predmetom (mode-i), ki si sledijo:

Object mode upravlja z objekti v sceni, kot so kamera, površine, meshi in luči. V tem načinu se lahko premikajo, vrtijo in se jim določa scale (merilo velikosti vzdolž x, y, z osi).

Edit mode vpliva na obliko samo enega izbranega objekta in ne vpliva na globalne lastnosti kot sta pozicija in usmerjenost.

Sculpt mode – podobno kot edit mode, le da tega ne počne z upravljanjem oglišč robov in stranic, ampak s čopičem.

Vertex paint je eden izmed načinov barvanja objekta, le da tega ne počne s teksturami, ampak z barvanjem oglišč. Preprost je za uporabo, a v večini primerov žal ni ustrezen, saj ne moremo določiti natančnosti barvanja (nastanejo namreč preveč kockasti robovi).

Weight paint je način, s katerim lahko označimo obteženost območij (npr. lasje) z relativnostno paleto barv, ki razvršča od temno modre, ki je po teži najlažja barva, do rdeče, ki je po teži najtežja.

Texture paint je način barvanja, ki se lahko aplicira tudi direktno na UV mapo in lahko pobarva tudi z izbrano teksturo (npr. barvo dlake konja).

V Blenderju se deli, ki imajo neko specifično funkcijo (npr. 3D view, Timeline, Node editor, UV image editor ...), imenujejo Editor.

Nekateri izmed teh editorjev pridejo še v sklopu z regijo, ki so vizualna reprezentacija stvari, ki jih urejajo.

Context button so gumbi, ki nam dajejo dostop do novih možnosti (object constraints, object data, material, render...).

V sklopu »context button« se nahajo paneli, ki so v bistvu le logično razvrščene nastavitve, s katerimi upravljamo ali s potrditvenimi polji (true/false) ali z drsniki vrednosti (nekateri od 0–100, nekateri od minus neskončno do neskončno).

Ko odpremo modelirni program Blender, se v novem projektu pojavijo trije elementi:

kamera, mesh kocke, luč.

Za naše potrebe so ti elementi edina stvar, ki jo potrebujemo (tudi kocka se lahko z razrezom in preoblikovanjem oglišč preobrazi v kroglo), saj je edini namen uporabe Blenderja izvoz modelov. Posledično ne potrebujemo niti kamere niti luči, ker sta to elementa, ki jih bomo dodali in upravljali v Unityu.

Blender je program, ki je zelo močno orientiran na uporabo bližnjic na tipkovnici, ki jih je potrebno usvojiti pred samo uporabo. Upravljanje vidikov kamere je preprosto in poteka na numerični tipkovnici. Ostale kontrole kamere potekajo s kombiniranjem sredinskega miškinega gumba ali držanjem shifta, druge kontrole so podvržene načinu, v katerem se nahajamo.

Tipka N odpre okno z lastnostmi, pri katerem lahko spreminjamo parametre od transformacije do tridimenzionalnega pogleda.



Za izziv smo se odločili, da bomo vse modele ladjic sestavili s preoblikovanjem kocke (slika 5). To smo dosegli z obročnim rezom, ki v obroču doda nove obrobe, in z nastavljanjem izrivanja (extrude) robov in ploskev. Ustvarjanje asteroidov je potekalo na podoben način, le da smo to dosegli na podlagi dodajanja že narejenega mesha ICO sphere in z nastavljanjem števila razbijanja na manjše dele (subdivizij). Razlika med UV sphere in ICO sphere je v tem, da je ICO sphere objekt, katerega ploskve so trikotniki, medtem ko se UV sphere definira preko obročev in segmentov, katerih ploskve so kvadrati. Izstrelki so v našem primeru podolgovato skalirane kocke, več dela z njimi zaradi hitrosti in njihove majhnosti ni potrebno.

Slika 5: Prvi zametki razvoja 3D objekta (vir: lasten)

Prvi korak ustvarjanja modelov je torej zaključen; lahko gremo k teksturiranju.

Mapiranje tekstur je v računalniški grafiki metoda, s katero dodajamo detajle na površino s pomočjo projiciranja slik in vzorcev. Projicirane slike in vzorce je možno nastaviti, ne samo tako, da vplivajo na barvo objektov, ampak tudi na njihovo prozornost, oddajanje svetlobe in odsevnost .

V Blenderju se teksture lahko (Blender – textures, 2015):

aplicirajo na material, aplicirajo na svetlobo (kot npr. svetilko), aplicirajo na oddaljeno ozadje (world background), aplicirajo na čopič, ki mu sami določamo obliko, aplicira na določilnike tekstur za delce in oceane.



Najbolj fleksibilna metoda mapiranja dvodimenzionalne slike na tridimenzionalni objekt je proces, ki se imenuje UV mapping. V tem procesu vzamemo tridimenzionalni (X, Y, Z) mesh in ga razvijemo na plosko dvodimenzionalno (U, V) sliko. Barve na sliki so zaradi tega mapirane na mesh in se prikažejo kot barve ploskev.

Najboljša primerjava za razumevanje UV mapiranja je rezanje kartonske škatle. Škatla je tridimenzionalni objekt (kot mesh kocke), ki se dodaja na sceno. Če bi vzeli par škarij in jo razrezali po pregibih, bi lahko njen plašč položili na ravno mizo. Lahko bi rekli, da je U njena nova X os (os, ki gre iz leve proti desni) in V njena nova Y os (os, ki gre od spodaj dol). Smernici U in V se torej uporabljata za koordinatni sistem tekstur (Slika 6).

Ko bi škatlo sestavili nazaj, bi se UV točke prenesle na XYZ točke. To naredi računalnik z dvodimenzionalno sliko, ko jo ovije okoli tridimenzionalnega objekta (Render - reference manual, 2015).

Način, na katerega bomo aplicirali teksturo, je znan, a preden sploh lahko apliciramo teksturo je treba le-to ustvariti. Tu nam bo v pomoč še en program z imenom Gimp.

Slika 6: Razrez škatle za prikaz UV mapiranja (vir: lasten)



4.2. Teksture

Gimp je okrajšava za GNU Image Manipulation Program. Je zastonjska distribucija programa, ki je kos nalogam, kot sta retuširanje fotografij in kompozicija slik. To je zmogljiv program, ki ga je možno uporabiti kot preprostega slikarja ali ekspertni program za retuširanje, kot tudi za masovno produkcijo slik ali samo kot converter formata le-teh.

GIMP je razširljiv in je bil razvit za to, da se uporablja z vtičniki (plugins), s katerimi lahko s sliko delamo praktično vse, kar hočemo. Napredni vmesnik za pisanje skript dovoljuje tako najbolj preproste kot tudi najbolj kompleksne nalog manipulacij s sliko.

Dela tako na MS Windows platformi kot tudi Mac OS X (Gimp-Introduction, 2015).

Naši cilji pri teksturiranju so bili sledeči:

ustvariti teksturo za ladjo, ki jo upravlja igralec, ustvariti teksturo za nasprotnikovo ladjo, ustvariti teksturo za asteroide, ustvariti teksturo za naše in sovražnikove izstrelke, ustvariti teksturo ozadja naše stopnje, ustvariti potrebno sliko, ki je služila kot ozadje glavnega menija in sliko, ki je

predstavljala ikono aplikacije, ki je vidna v meniju.

Pri teksturah sovražnikove ladje in igralčeve ladje je bilo zaradi umeščanja detajlov potrebno uporabiti tehniko UV mapping. Za igralčevo ladjo in za asteroide je bilo pa potrebno ustvariti tudi normal map. Kar se tiče samega ozadja in nekaterih določenih detajlov naših tekstur, je bilo potrebno uporabiti tehniko delanja navidezno neskončnih (seamless) tekstur.

Po vesolju bi premikanje z vesoljsko ladjo lahko dosegli na več načinov. Lahko bi ustvarjali dolge stopnje s statičnim ozadjem, ki bi se končale, ko bi igralec pozicijsko prišel do konca neke točke, ampak to ni bil nikoli naš cilj. Naš cilj je bil ustvariti neskončno igro, in če hočemo ustvariti takšno igro, obenem pa še vedno dodati občutek potovanja, je bila naloga ustvariti iluzijo potovanja skozi neskončno vesolje.

Igra deluje tako, da ima igralec na voljo le omejen prostor, po katerem se lahko giblje, v ozadju pa se počasi premika vesolje, bližje zvezde se premikajo kanček hitreje in dogajanje, ki je v ospredju (igralec in njegovi nasprotniki) z največjo hitrostjo (bolj oddaljeni objekti se premikajo počasneje kot objekti, ki so blizu). Ideja je podobna poteku vožnje z avtomobilom v starejših filmih, kjer se ni snemalo dejanske vožnje. Avto je miroval v studiu, v ozadju pa je bilo platno, ki je ustvarjalo iluzijo premikanja.

Zelo oddaljeno vesolje, ki se v našem primeru premika najpočasneje, je tekstura, katere sámo premikanje bo zajeto v sklopu pisanja skript. A za to, da potekajo prehodi med začetkom in koncem te teksture tekoče, brez rezov, se je potrebno poslužiti tehnike navidezne neskončnosti.



Zaradi prednastavljenega zaslonskega razmerja testnega telefona (16:10), smo v Gimpu s preizkušanjem filtrov in ostalih nastavitev ustvarili sliko velikosti 1024:512 (1024 in 512 zato ker se smatra za dobro prakso v Unityu, da so vse velikosti tekstur zaradi performančnih razlogov iz družine 2n), kateri smo po sredini potegnili črn vzorec, katerega edini namen je, da se poveže z vzorcem kopije iste slike, le da je ta obrnjena za 180 stopinj.

Ti dve sliki, ki sta povezani v eno samo, skupaj dosežeta to, da se ob premikanju po x osi lahko tekoče ponavlja v nedogled (Slika 7).

Na podoben princip so bile zgrajene tudi vse generične stvari v diplomskem delu, ki so se ponavljale (npr. kovina trupa ladje, steklo, celo izstrelki). Vzet je bil vzorec iz neke manjše slike, kateremu je bil dodan nek določen detajl. Slika je bila nato postavljena ob ogledalo vzdolž x,y osi (občasno celo obeh), združena skupaj do primerne velikosti in aplicirana tam, kjer je bilo potrebno, da se je nek določen vzorec ponavljal.

Slika 7: Prikaz seamless teksture (vir: lasten)

4.3. Proces teksturiranja

Proces UV mapiranja v Blenderju je potekal na sledeč način in je na slikah prikazan na primeru igralčeve vesoljske ladje (slike 8-12):

Ko smo imeli narejen mesh, v Blenderjevem pogledu, ki ga v tistem trenutku ne uporabljamo (npr. namenjen animaciji), odpremo pogled z imenom UV/Image Editor in ga zaradi preglednosti razširimo do polovice ekrana.

V tistem trenutku moramo imeti izbran objekt, kateremu hočemo narediti UV map v načinu edit. Tukaj smo določili projiciranje svojega XYZ 3D objekta na 2D UV mapo,



ampak preden smo to lahko storili, smo morali določiti pravila/način, na katerega je to potekalo (Slika 8).

Tega bi se lahko lotili na dva načina:

Predhodno bi razrezali stranice objektov s seam (robovi se označijo z rdečo črto), izbrali bi celoten objekt in ga s tipko U na tipkovnici v celoti projicirali na UV image view pogled. Posledica tega bi bil enoten dvodimenzionalni objekt (primer takega razreza je bil na sliki x kocke). Izbrali bi vsako ploskev posebej in jo preko tipke U projicirali na UV pogled. S tem načinom lahko ploskve razdelimo na različne otoke (isle), ki bi jim po potrebi določali lego.

V našem primeru delanja UV mape smo se odločili za metodo izbiranja in dodajanja ploskev ali skupine le-teh. Razrez preko seamov je potencialno lahko hitrejši, a je težaven, saj zahteva kar nekaj izkušenj, preko katerih je lahko končni produkt takega razreza predvidljiv. Za kaj takega bi morali tudi vnaprej načrtovati izgled svojega tridimenzionalnega objekta.

Slika 8: Prikaz UV pogleda v Blenderju (vir: lasten)

Zaradi umeščanja teh otočkov lahko na enem samem objektu določenim otokom (Slika 9 spodaj) dodamo različne detajle (poleg same teksture za kovino lahko s tem dodamo tudi steklo kabine in detajle za motor). Te otoke je možno po potrebi povečati ali pomanjšati, ključno pa je, da jih po velikosti nastavimo tako, da jih lahko spravimo na UV sliko. Z njihovo velikostjo lahko reguliramo, kako močno bo raztegnjena slika/tekstura, ki bo na njih aplicirana.



Naslednji korak je izvoz te UV slike, ki je prikazana v UV/Image pogledu, kar dosežemo s klikom na gumb UV's v meniju, kjer izberemo opcijo »Export UV layout«.

To razporeditev (layout) lahko izvozimo kot .png (Portable Network Graphic), .svg (Scalable Vector Graphic) ali .epc (Encapsulated PostScript). Od teh treh imamo izkušnje samo s .png in .svg, in ker razvijamo igro za telefon, kjer je velikost pomembna, izberemo .png, saj je manjša od teh dveh.

Slika 9: Prikaz islov za namen UV mapiranja v Blenderju (vir: lasten)

Izvoženo sliko odpremo v Gimpu, v svoji plasti nastavimo pripadajoče dele tekstur in izvozimo nazaj v UV/Image pogled (glej slika 10).



Slika 10: Prikaz uvožene teksture na UV layout (vir: lasten)

Naslednji korak je povezovanje materiala in UV razporeditve, ki se doseže v Blenderjevem pogledu z imenom Node editor, v katerem barvo povežemo z barvo (glej Slika 11).

Slika 11: Node editor in povezava barv (vir: lasten)



Po tem lahko mirno izbrišemo kamero in luč iz Blenderja in projekt izvozimo v .blend formatu v Unity (glej končan produkt, slika 12).

Slika 12: Prikaz dokončane teksture za igralčevo ladjo (vir: lasten)

Ko uvozimo naš model v Unity pride najprej do težave, ki je prej nismo predvideli. Privzete smernice prostora XYZ so v Blenderju in Unityu definirane drugače: Medtem ko talni smernici v Blenderju predstavljata osi X in Y, višino pa os Z, v Unity pravokotni talni smernici predstavljata osi X in Z, višinsko pa smernica Y (glej Slika 13).

Slika 13: Primerjava prednastavljenih koordinatnih osi obeh programov (vir: lasten)



Posledica tega je, da so pri uvozu vsi objekti/meshi orientirani v smeri iz Blenderja in v primeru, da v kodi določimo vektorsko transformacijo objekta vzdolž npr. y osi, bo upošteval y os iz Blenderja. Temu se izognemo tako, da uvožen objekt rotiramo, kot se nam zdi, da bi moral biti umeščen in ga določimo kot otroka (child) nekega praznega objekta gameObject, na katerega naprej vežemo vse ostale skripte. Ta objekt ni več podvržen Blenderjevi definiciji smernic, ampak Unityevi.

4.4. Prednosti in slabosti Blenderja

Prednosti Blenderja:

zmogljivo orodje za modeliranje, ki se kosa tudi s plačljivo konkurenco, široka skupnost, ki je vedno pripravljena pomagati, deluje na platformi Windows, Mac in Linux, zastonjski.

Slabosti Blenderja:

Za začetnika je mogoče težek za uporabo, saj mora tudi za najbolj osnovne transformacije usvojiti bližnjice na tipkovnici ali pa se izgubiti v meniju, ki ponuja široko paleto, ne nujno najbolj intuitivno razvrščenih možnosti.



5. RAZVOJ IGRALNEGA OKOLJA

5.1. Predstavitev Unitya

Unity je večplatformni sistem za ustvarjanje iger, ki ga razvija Unity Technologies. Vključuje igralni pogon in IDE. Uporablja se za razvoj videoiger za spletne strani, namizne platforme, igralne konzole in mobilne naprave. Najprej je bil oznanjen samo za MacOS, na Apple Worldwide Developers Conference leta 2005. Do današnjega dne je razširjen na več kot petnajst platform in je postal primarni SDK za Nintendo Wii U.

Unityeva posebnost je njegova možnost razvijanja iger za več platform. Trenutni nabor teh platform obsega Blackberry, Windows Phone, Windows OS, OS X, Linux (primarno Ubuntu), Android, iOS, Unity Web Player, Playstation 3, Playstation 4, Playstation Vita, Playstation Mobile Xbox 360, Xbox One, Wii in Wii U... Vključuje tudi strežnik s sredstvi (Unity Asset Store) in podporo za Nvidia PhysX (Unity - game engine, 2015).

Skripte v njem lahko pišemo v C#, Javascriptu ali Boo-ju.

Uporaba osnovne Unity verzije, imenovane Unity Free, je zastonj, v kolikor to uporablja uporabnik, ki ima letni bruto prihodek manjši od 100.000 dolarjev. V kolikor to ni tako, je potrebna nabava Unity Pro, ki ima še dodatne razsežnosti in nosi ceno 1500 dolarjev na enoto. (op. Ta podatek je uradno zastarel med pisanjem 5.3.2015 z najavo Unity5) (Unity FAQ, 2015).

Močan del Unitya predstavlja njegova tržnica s sredstvi (asset store), kjer lahko trgujemo s posamičnimi sredstvi, ki jih lahko uporabimo v svojem projektu. To obsega elemente od zvočnih detajlov do novih modelov.

Unity Remote je program, ki omogoča, da se uporabnikova Android naprava obnaša kot remote control za lasten projekt v Unity Editor-ju. To je uporabno za hiter razvoj, da ni potrebno vedno znova prevajati in kopirati projekta na Android napravo, da bi lahko testirali še najmanjše spremembe (Unity Remote, 2015).

Ko odpremo Unity in začnemo nov projekt, je najprej potrebno navesti lokacijo našega projekta. Vsa uvožena sredstva, kakor tudi vse, kar bomo naredili v okviru našega projekta, se bo tam tudi nahajalo.

Preden lahko začnemo z delom v Unityu je potrebno predstaviti njegov layout, saj je ključen za razlago poteka dela (glej Slika 14).



Slika 14: Prikaz osnovnega uporabniškega vmesnika od Unitya (vir: lasten)

Glavni elementi tega layouta so (Unity basics, 2015):

project browser, ki prikaže datotečno strukturo projekta z vsemi sredstvi, ki smo jih naredili ali uvozili in poseduje svoj brskalnik;

Dva pogleda na sceno: o Scene view je verjetno najpomembnejši vidik Unity-a, vsekakor pa je

vidik, v katerem vsak, ki Unity uporablja, preživi največ časa. V scenskem pogledu namreč upravljamo z gameObjecti.

o Game view je pogled, ki ga izriše primarna kamera, ki je prisotna v igri. Je reprezentacija pogleda na končno igro.

Hierarchy seznam, ki vsebuje vse gameObjecte, ki so postavljeni v scenskem vidiku. Nekateri so direktne instance sredstev kot so tridimenzionalni modeli, ostali pa so instance prefabov. V tem seznamu določamo tudi parenting objektov;

Inspector, ki prikazuje podrobne informacije o trenutno izbranih gameObjectih, vključno s priloženimi komponentami in njihovimi lastnostmi. V inspectorju se modificira namembnost gameObjectov v sceni. Vse lastnosti, ki so prikazane v inspectorju se lahko direktno spremenijo in celo vrednosti javnih spremenljivk (public variables), ki so uporabljene v skripti, se lahko spremenijo, brez modifikacije skripte same.

Scena je okolje, v katerega vstavljamo objekte, ki so v igri. Posamično sceno se lahko razume kot svojo stopnjo (level) ali kot mesto, kjer se nahaja glavni meni (naša igra je ustvarjena iz dveh scen – glavnega menija in ene stopnje). Če v



scenskem pogledu nastavimo objekte in zamenjamo sceno, ti izginejo in se pojavijo objekti, ki smo jih nastavili v drugi sceni. Zato Unity tudi ponuja možnost ali shranjevanje celotnega projekta ali pa samo izbrane scene.

Ob odprtju našega projekta, nismo torej uvozili nobenih vnaprej narejenih sredstev, v hierarchy pa smo dodali sledeče mape za urejanje lastnih sredstev:

CanvasElements, Materials,

Models, Particle systems, Prefab, Scenes, Scripts, Tekstures.

5.2. GameObject in komponente

Game objecti so najpomembnejši element v Unityu, saj predstavljajo like, rekvizite in scenografijo. Sami po sebi sicer nimajo pomembnega dela. Delujejo namreč kot zabojniki za komponente, ki implementirajo njihovo funkcionalnost (Slika 15).

GameObject torej sam po sebi ni nič, a je navkljub temu najpomembnejši element v Unityu, saj je zaradi svoje narave lahko karkoli (denimo luč v smislu nečesa, kar oddaja svetlobo; je objekt, ki se ga ustvari tako, da se na GameObject priloži Render Light komponenta). Na sebi ima vedno Transform komponento, ki predstavlja pozicijo in rotacijo, ki je ni mogoče odstraniti. Ostale komponente, ki dajejo objektu funkcionalnost, se dodajo preko inspectorjevega komponentnega menija (Unity Manual GameObject, 2015).

Vsak gameObject ima lahko v svoji strukturi podrejenih še več gameObjectov, ki se jih imenuje childi. Vsi objekti, ki smo jih uvozili iz Blenderja v Unity so childi objekti praznemu gameObjectu (zaradi pragmatične rešitve problema z rotacijo). V primeru vesoljske ladje igralca je njegov izpuh child (torej podrejen) gameObjectu. Namen tega je, da ne glede na njihovo trenutno lokacijo, v trenutku, ko postanejo child nekega drugega objekta, postanejo podrejeni transformaciji objekta, ki je hierarhično nad njimi in mu zato ob vsaki spremembi lokacije sledijo z isto spremembo (Slika 16).

Objekte, ki jih ustvarimo v sceni in jih nameravamo še kdaj uporabiti, lahko shranimo pod svoja sredstva v project browser. Tem objektom se reče prefab. Razlika med kopijo nekega gameObjecta in prefabom je v spremembi vrednosti neke lastnosti objekta. Pri gameObject moramo spremembo kopiji pri vsaki njeni instanci urediti posebej, medtem ko pri prefabu to spremembo nastavimo na njem samem in bo odtlej veljalo za vse njegove instance. Prefabi so torej priročni za generične stvari, ki morajo imeti nastavljene iste vrednosti in jih ustvarimo večkrat (kot v našem primeru izstrelki in nasprotniki).



Slika 15: Primerjava praznega GameObjecta z GameObjectom na katerem so komponente (vir: lasten)

Slika 16: Prikaz hierarhične podrejenosti objektov na igralcu (vir: lasten)

V komponentnem meniju gameObjecta bi izpostavili nekaj komponent, ki so bile uporabljene v igri:

Mesh renderer vzame geometrijo iz mesh filtra (njegova naloga je, da vzame mesh iz sredstev) in jo postavi na pozicijo, ki jo definira objektova transform komponenta (v našem primeru so to sredstva, ki smo jih uvozili iz Blenderja);

Particle system simulira spremenljivo entiteto, kot so tekočina, dim ali plamen, z generiranjem in animiranjem velikega števila dvodimenzionalnih slik na sceno (v našem primeru eksplozije, izpuhi, zvezde v ospredju);



Rigidbody objektu omogoča, da je podvržen vplivom zunanjih fizikalnih sprememb, kot sta gravitacija in navor;

Trkalnik (Collider) je komponenta, ki zavzame neko obliko objekta za namen fizičnih trkov;

Rendering camera objekt transformira v kamero. Skozi njega lahko potem opazujemo sceno. (V našem primeru je kamera samo ena, game kamera, ki ne spreminja lokacije, niti usmeritve);

Audio, čeprav zvok v tej igri ne bomo uporabljali; Rendering>Light: komponenta, ki predmet določi kot oddajnika svetlobe; Script component - vsaka skripta, ki jo dodamo nekemu gameObjectu se

smatra kot skriptna komponenta. (Tehnično gledano so lahko v skripti ustvarjene vse od zgoraj naštetih komponent, a v našem primeru definirajo samo obnašanje gameObjectov).

5.3. Prikaz objektov v Unityu

Prikazu objektov v Unityu služijo kamera in tri komponente, ki so povezane med seboj: luči, materiali in shaderji. Slednja naveza deluje sledeče: material definira barvo objekta, v katerem je naveden shader, ki definira odziv te barve glede na osvetlitev.

Kamera je komponenta, ki ujame in prikazuje svet igralcu. Ima dva vidika: ortografskega in perspektivnega (v našem projektu ortografskega). Perspektivni vidik zajema sliko v obliki štiristrane piramide z vrhom na poziciji kamere, ortografski pa v obliki kvadra.

Osvetlitev je pomemben del vsake scene. Medtem ko meshi in teksture vplivajo na obliko in pogled na sceno, luči definirajo občutek, ki ga tridimenzionalno okolje ustvarja skozi proces senčenja objektov, ki so na njem.

Pri osvetlitvi so za nas pomembni naslednji elementi: oblika izvora, razdalja in doseg osvetlitve.

Unity pozna štiri tipe luči, ki se med seboj ločijo glede na izvor svetlobe (Unity Lightning Overview, 2015):

usmerjena luč (Directional light), ki nima nobenega razvidnega izvora in jo je možno postaviti kamorkoli na sceno. Vsi objekti na sceni so podvrženi tej svetlobi, ki nikoli ne upade in je zato pomembna samo njena usmeritev (Slika 17);



Slika 17: Delovanje direkcijske luči (vir: http://docs.unity3d.com/Manual/Lighting.html)

točkovna luč (Spot light), ki je postavljena na neko točko v prostoru in pošilja svetlobo v vse smeri enakovredno. Intenzivnost osvetlitve je odvisna od oddaljenosti od luči, ki ima tudi svojo ničelno vrednost definirano z največjim dosegom (range), v kateri objekta ne osvetli več (Slika 18);

Slika 18: Delovanje točkovne luči (vir: http://docs.unity3d.com/Manual/Lighting.html);

žaromet (Spot light) je, podobno kot točkovna luč, postavljen na neko točko in pošilja svetlobo, ki upade po neki razdalji. Razlikuje se v tem, da pošlje luč naprej v obliki stožca (Slika 19);



Slika 19: Delovanje luči žarometa (vir: http://docs.unity3d.com/Manual/Lighting.html)

območna luč (Area light) – njen izvor je pravokotne oblike in upade po neki razdalji.

Material je sredstvo, ki ga lahko določimo nekemu GameObjectu, v kolikor imamo na njem komponento mesh renderer (v tem primeru je sredstvo, ki definira barvo tridimenzionalnih modelov). V kolikor ga pri tem ne določimo sami, ga za nas ustvari Unity z dodanim diffuse shaderjem. Uporablja se tudi pri sistemih delcev (Particle Systems) ter ostalih komponentah za senčenje. Možnosti, ki jih prikaže izbira materiala v inspectorju, se med seboj razlikujejo glede na izbrani shader.

Shaderji so sredstva, ki vsebujejo kodo in navodila za grafično kartico. Materiali referirajo shaderje in preko njih nastavljajo lastne parametre (teksture, barvo itd.). Pri njih nas načeloma zanima vpliv na izgled materiala in kakšen je njihov vpliv na hitrost delovanja igre.

Unity pozna tudi posebej prirejene shaderje za mobilne naprave, ki imajo manjši vpliv na strojno delovanje, med katerimi bi izpostavili tiste, ki smo jih uporabili v projektu:

Mobile/Unlit: upošteva se samo tekstura, na katero ne vpliva nobena osvetlitev. Je najmanj strojno zahteven shader (uporabljen je bil na ozadju in izstrelkih);

Mobile/VertexLit: vsa svetloba, ki se prikaže na objektih se izračuna na ogliščih (od tod tudi ime vertex, uporabljen je bil na ostankih razstreljenih sovražnikov);



Mobile/Bumped Diffuse izračuna preprost model osvetlitve. Svetloba na površini se spreminja s tem, ko se kot med njo in lučjo spreminja. Odvisna je samo od kota in se ne spreminja s premikanjem kamere. Zahteva tudi normal map teksturo, ki simulira majhne detajle na površini (uporabili smo ga na materialu igralca in asteroidov).

Slika 20: Prikazan vpliv shaderjev na material, najbolj osnoven med njimi je VertexLit (vir: http://docs.unity3d.com/Manual/Materials.html)

5.4. Sistemi delcev

Sistem delcev je v Unity-u komponenta, s katero so bile v projektu ustvarjene eksplozije, izpuhi in zvezde iz ospredja.

Slika 21: Sistem delcev – eksplozija (vir: lasten)



Razlika med enimi in drugimi je v nastavitvah njihovega delovanja.

Eksplozije so enkraten izbruh večjega števila delcev v zelo kratkem časovnem razmiku, kar je dogodek, ki se zgodi samo enkrat (zaradi tega jo je po poteku potrebno tudi uničiti, kar naredimo s skripto). Za dosego retro stila eksplozij (kockasta oblika), se kot njihov material nastavi sprite, spreminjanje velikosti delcev skozi čas in njihove barve od oranžne do rumene. Poteka v sferični obliki in navzven.

Izpuh je stalen izbruh delcev, ki se ponavlja; prednastavljenega materiala ne spreminjamo in je modre barve. Poteka v obliki usmerjenega stožca, kjer se delci zmanjšujejo skozi čas in imaj

o zelo kratko življenjsko dobo (s tem dosežemo efekt raketnega izpuha).

Prednje ozvezdje je stalen izbruh različno velikih delcev, kjer je določena le največja velikost delca (torej zvezde), njena velikost ob instanciranju pa je pogojena z naključno funkcijo njenega največjega obsega od 0 do 1. Generacija poteka v obliki usmerjene škatle. Njen material je prednastavljen material sistema delcev in je bele barve.

5.5. Umetna inteligenca v igrah

Skozi leta je igričarska industrija videla velike korake. Začenši s preprostimi igrami kot so Pong in Pac-Man, ki so igralcem ponujale kratek pobeg iz realnosti in so zrasle v veliko bolj zanimive igre, kot sta World of Warcraft ali Call of Duty (v smislu tega, da ga pritegnejo nekoga za dlje časa), ki so resni hobiji tistim, ki jih igrajo. Današnji igralci imajo po besedah ESA (Entertainment Software Association) v povprečju 13 let izkušenj in so se navadili, da je vsaka nova igra kompleksnejša, zato za razvijalce postane izziv konstantna izboljšava že obstoječih sistemov, da postanejo zanimivejši. Eden izmed načinov, na katerega to storijo, je skozi razvoj računalniško kontrolirane umetne inteligence. Ampak ustvariti adaptivno krinko, ki bo po eni strani sposobna biti enakovredna igralcu in ga po drugi ne popolnoma uničiti, da opogumlja njegovo rast, ni ravno lahka naloga.

V jedru se umetna inteligenca sestoji iz emulacije obnašanja drugih igralcev ali entitet (torej vseh elementev na katere se da vplivati z igralčeve strani – od raket do pobiranja točk), ki jih predstavlja. Z drugimi besedami, umetna inteligenca za igre je bolj umetna, kot inteligentna. Sistem je lahko tako preprost kot sistem, ki bazira na strogih pravilih (npr. namizne igre), ali tako kompleksen, da izziva igralca kot voditelj nasprotne vojske.

Za namembnost današnjih iger prava umetna inteligenca presega vse zahteve za programsko opremo, ki služi zabavi. Umetni inteligenci v igrah se ni potrebno zavedati lastnega obstoja (v bistvu je celo bolje, da se je ne) in se ji ni potrebno učiti ničesar, kar ni v sklopu igranja. Pravi cilj umetne inteligence v igrah je simulirati inteligentno obnašanje, ki igralcu da prepričljiv občutek izziva (Designing Artificial Intelligence for Games, 2015).



Cilj diplomske naloge je torej ustvariti umetno inteligenco, ki bo prepričljivo izzvala igralca, a ga po drugi strani ne bo pretirano dotolkla. Česar ne bodo sposobni storiti posamični objekti, bo lahko sposobna storiti njihova količina. Ta del bo zajet v pisanju skript obnašanja za sovražnike.

5.6. Pisanje skript

Naš projekt, kot tudi večino preprostih, starih iger, kjer je v središču pozornosti igralec, bi lahko v svojem bistvu razbili na premišljeno medsebojno delovanje naslednjih funkcij:

funkcija, ki nekaj ustvari (ustvari nasprotnika, eksplozijo, izstrelek, razbitino), funkcija, ki premika stvari (igralca, nasprotnike, izstrelke, razbitine), funkcija, ki nekaj uniči (nasprotnika, igralca, eksplozijo, izstrelke, da ne

potujejo v neskončnost).

Delovanje teh funkcij lahko reguliramo v Unity s pisanjem skript, ki jih ustvarimo v projektnem vidiku z desnim klikom > create > C# script. Vsem spremenljivkam, ki jih deklariramo znotraj skript kot public, je nastavljena privzeta vrednost 0 in jih lahko spreminjamo po želji v inspector (kar pride prav pri testiranju stvari). Za public lahko razglasimo tudi objekte, ki jih moramo potem spet ročno nastaviti v inspector. Če kliknemo na skripto samo, nam inspector ponudi vpogled v kodo.

Pri pisanju skript je pomembno tudi kdaj se koda izvaja zato bi izpostavil tri funkcije, ki so regulirale izvajanje v projektu:

Start – kliče se, ko objekt na katerem je ta skripta, vstopi v sceno, ponavadi ga uporabimo za vrednosti, ki se ne spreminjajo.

Update – kliče se enkrat na frame in ima zato zaradi različnih časov izrisov le-teh tudi različne intervale med posamičnimi klici. Ponavadi se uporablja za vnos ukazov, za spreminjanje in premikanje objektov na katere ne vpliva fizika.

FixedUpdate – Podobno kot Update, le da so razmiki med klici vedno enaki in je zato bolj primeren za premikanje objektov na katere vpliva fizika.

Funkcija, ki nekaj ustvari

Instantiate se najpogosteje uporablja pri instanciranju projektilov, nasprotnikov, eksplozij ali razbitin za uničene objekte (Unity Scripting API, 2015).

Pri uporabi funkcije instantiate, nas zanima kaj ustvariti, kje to ustvariti in kakšno rotacijo naj ima ustvarjen gameObject. Ko to skripto nataknemo kot komponento na gameObject, moramo navedeni gameObject še enkrat nasloviti v inspector, v kolikor smo ga razglasili kot public.



Slika 22: Prikaz public variabel v skripti kot jih vidi inspector (vir: lasten)

StartCoroutine – funkcija preko katere instanciramo nasprotnike na sceno v valovih. Pomembnejši parametri znotraj te funkcije obsegajo definirano razširljivo vrsto nasprotnikov, vektor, ki določa njihovo začetno pozicijo z naključno višino, število in čas med posamičnim instanciranjem ter parameter, s katerim funkcija preneha z izvajanjem same sebe (smrt igralca).

Vsak uničen nasprotnik v igri na poziciji uničenja napravi eksplozijo in razbitino, ki jo je možno znova uničiti za dodatne točke. Ob pritisku gumba za streljanje se instancirajo tudi izstrelki na poziciji BulletSpawnLocation, ki je gameObject podrejen transformaciji igralca, a je od njegove originalne pozicije oddaljen za nekaj enot vzdolž x osi. Namen tega je, da se izognemo nepotrebnemu prehajanju skozi mesh od igralca, ker to po nepotrebnem obremenjuje procesor.

Funkcija, ki premika stvari

Po vstavitvi objektov na sceno ti sami po sebi ponavadi nimajo nobene uporabne lastnosti, v kolikor jih ne začnemo premikati. Za to nam je pri razvoju iger v veliko pomoč poznavanje vektorjev, saj z njimi koordiniramo premike.

Vector3 v Unity služi reprezentaciji tridimenzionalnih vektorjev in točk, njegov kontejner obsega tri decimalne vrednosti skalarjev x, y in z. Vsi premiki z izjemo premika igralca in padanja, so narejeni s preprosto skripto poimenovano EnemyMover.



Slika 23: Preprosta skripta EnemyMover, ki jo lahko recikliramo (vir: lasten)

Prednost tako napisane skripte je v tem, da jo zaradi več public deklariranih spremenljivk lahko preko Unity inspector uporabimo za več različnih namenov. Z nastavitvijo yDol in yGor lahko določamo naključen interval za naklon premika, enemyHitrost pa v primeru negativne vrednosti spremeni smer premika iz leve strani proti desni. Tako določimo ali je nastali objekt izstrelek od igralca, od nasprotnika ali pa celo nasprotnik sam.

Drug del premikanja je rotacija, ki jo izvajamo s pomočjo Quaternion.Euler funkcije, katere poziv vrne rotacijo vzdolž z, x in y osi (v točno tem zaporedju). Uporabili smo jo pri premikanju določenih nasprotnikov in njihovih razbitinah kakor tudi pri rotaciji igralca ob premiku.

Še eno posebno vrsto premikanja smo uporabili tudi na ozadju preko metode, ki se ji reče Texture Offsetting. V grobem deluje tako, da teksturo (ki smo jo naredili navidezno neskončno točno s tem namenom) počasi premika vzdolž polja, na katerem je z neko določeno hitrostjo, in ustvarja iluzijo premikanja.

Funkcija, ki nekaj uniči

GameObject ali njegovo komponentno lahko uničimo s pozivom destroy takoj, skozi čas (uniči po določenem času) ali ob nekem dogodku z if stavkom. Ta dogodek je ponavadi trk. Za registracijo trkov potrebujemo trkalnike.

Trkalniku (collider) ni treba biti popolnoma enake oblike, kot je mesh objekta, na katerega je apliciran, zato je načeloma stvar dobre prakse, da samo na grobo obdaja naš predmet, in sicer zaradi manjše obremenitve procesorja. V Unity tridimenzionalni produkciji obstajajo naslednji osnovni tipi trkalnikov:

Box collider (škatlaste oblike, določi se mu osrednja pozicija in velikost),

Sphere collider (v obliki krogle, določi se ji osrednja pozicija in polmer), Capsule collider (v obliki kapsule, določi se ji orientacija, osrednja pozicija in

velikost).



Obstaja še mesh collider, ki je točno take oblike kot objekt, ki ga obdaja, a se mu ponavadi izognemo, kjer je to mogoče.

V kolikor imamo na trkalniku obkljukano možnost IsTrigger, lahko v kodi upravljamo s trkalnikom prek klicanja funkcij OnTriggerEnter (trkalnik je zadel ob trkalnik), OnTriggerStay (trkalnik je v konstantnem trku z drugim trkalnikom) in OnTriggerExit (trkalnik ni več v stiku z drugim trkalnikom).

Slika 24: Box collider, ki obdaja vidno igralno polje in uniči vse objekte, ki prehajajo izven njega (vir: lasten)

Vsi objekti v igri imajo kapsulni ali škatlast trkalnik za namen uničevanja ob trku, največji med njimi je poimenovan Playbox, ki uničuje objekte, ki prehajajo izven igralnega polja.

5.7. Uporabniški vmesnik / HUD

V videoigrah je HUD (heads-up-display) del uporabniškega vmesnika, s katerim grafično prikazujemo v tistem trenutku pomembne informacije igralcu (termin sam po sebi izvira iz HUD, ki se nahaja v vojaških lovcih). Zaradi majhnosti in preprostosti naše igre, se termina HUD in uporabniški vmesnik še globlje prepletata, ker je teh informacij malo (HUD - videogames, 2015).

Za izdelavo našega uporabniškega vmesnika smo uporabili elemente: Button, Text, Image, ki jih je ob dodajanju v projekt Unity avtomatsko določil kot hierarhično podrejene elementu Canvas. Ta se nahaja na svojem layerju, ki je rezerviran za uporabniški vmesnik.



Slika 25: Prikaz elementov uporabniškega vmesnika naše igre (vir: lasten)

Button – Iz Inkscape uvoženo sredstvo velikosti 256x256, na katerega so vezane različne skripte. Nekatere med njimi instancirajo projektil (gumb za streljanje), nekatere ponovno naložijo stopnjo ali končajo igro (gumbi uporabljeni za glavni meni).

Image – Predstavlja polje za premikanje, se pravi polje, po katerem lahko drsimo s prstom in s tem kontroliramo premike vesoljske ladje glavnega igralca. To smo uredili preko skripte za obnašanje, ki je vezana na ta element.

Text – Uporabljeni dve tekstovni polji: eno oznani konec igre in se prikaže ob uničenju igralca, drugo narašča ob uničevanju nasprotnikov.

5.8. Unity prednosti in slabosti

Unity ima veliko prednosti:

Ima močno skupnost ustvarjalcev sredstev in vtičnikov. Posledično je na voljo veliko zastonjske in sorazmerno ugodne vsebine.

Unity-eva vizualna in urejevalna orodja so zmogljiva in razširljiva. Podpira široko paleto sredstvenih formatov (assetov) in avtomatično

konvertira na optimalni format za ciljno platformo. Podpira široko paleto platform, mobilno, namizno, spletno in konzole.

Namestitev na več platform je preprosta.



Tridimenzionalni pogon napravlja visoko kvalitetne rezultate brez kakršnekoli kompleksne konfiguracije.

Je zastonjski.

Ima pa tudi slabosti, o katerih je potrebno razmisliti:

Sodelovanje je zahtevno. Strežnik s sredstvi je drag in deljenje kode in sredstev je lahko prevelik vložek, v kolikor se ga ne uporablja (popularna rešitev tega problema je zato med razvojnimi skupinami orodje Git).

Učinkovitost ni ravno najboljša. Do nedavnega je Unity tekel na izključno enem jedru in skoraj ni uporabljal dodatnih jeder na mobilnih napravah. To se izboljšuje z Unity 5.

Izvorna koda ni na voljo in v kolikor pride do problema v samem pogonu, je potrebno počakati na uradne popravke.



6. Zaključek

V diplomskem delu smo se seznanili z industrijo, ki postaja vse pomembnejša, in delom, ki je potrebno, da od začetka do konca izdelamo neko igro, ki bi jo lahko razširili in izboljšali z dodajanjem več vsebine. Seznanili smo se z igralnim pogonom Unity, modelirnim programom Blender in vsemi vmesnimi orodji, ki niso bila predvidena ob samem začetku.

Uspešno smo v igro dodali vzorce naključja, dodelali modele, teksture eksplozije, prištevanje točk in prehode med stopnjami.

Razvoj bi lahko potekal bistveno hitreje, v kolikor bi že od samega začetka poznali delovanje teh orodij, in imeli jasno razdelan potek dela. V ospredju diplomskega dela zatorej ni samo končni produkt, ampak tudi delo in tok procesov, ki so potrebni za izdelavo preprostih mobilnih iger.

Slika 26: Zaslonski posnetek igre (vir: lasten)



Literatura in viri

Perry D. (2009) David Perry on game Design: A Brainstorming Toolbox, chapter

5 Game POV and Game Genres , str. 34-50, Course Technology PTR

Koster R. (2004) A Theory of Fun for Game Design, What games teach us, What games are (22-65), Paraglyph Press.

Spletni viri:

Videogame industry: http://vgsales.wikia.com/wiki/Video_game_industry , [dostopano: 15.2.2015]

Videogame industry statistics : http://www.esrb.org/about/video-game-industry-statistics.jsp [dostopano 15.2.2015]

AAA (video game industry): http://en.wikipedia.org/wiki/AAA_%28game_industry%29 [dostopano 15.2.2015]

What is a game engine: http://www.gamecareerguide.com/features/529/what_is_a_game_.php [dostopano 15.2.2015]

Android (operating system): http://en.wikipedia.org/wiki/Android_(operating_system) [dostopano 15.2.2015]

Android, the world's most popular mobile platform: http://developer.android.com/about/index.html [dostopano 15.2.2015]

3DView-BlenderWiki: http://wiki.blender.org/index.php/Doc:2.4/Manual/3D_interaction/Navigating/3D_View [dostopano 15.2.2015]

About Blender: http://www.blender.org/about/ [dostopano 15.2.2015] Blender3D What is a Mesh?:

http://en.wikibooks.org/wiki/Blender_3D:_Noob_to_Pro/What_is_a_Mesh%3F [dostopano 15.2.2015]

Render- reference manual: http://wiki.blender.org/index.php/Doc:2.6/Manual/Textures/Mapping/UV [dostopano 15.2.2015]

Gimp-Introduction: http://www.gimp.org/abou t/introduction.html [dostopano 15.2.2015]

Unity(game engine): http://en.wikipedia.org/wiki/Unity_(game_engine) [dostopano 15.2.2015]

Unity-FAQ: http://unity3d.com/unity/faq , [15.2.2015] Unity Remote:

https://play.google.com/store/apps/details?id=com.unity3d.androidremote&hl=en, [dostopano 30.3.2015]

Unity- Unity basics: http://docs.unity3d.com/Manual/UnityBasics.html [dostopano 30.3.2015]

Unity Manual- GameObject: http://docs.unity3d.com/Manual/class-GameObject.html [dostopano: 30.3.2015]

Unity- Lightning Overview: http://docs.unity3d.com/Manual/Lighting.html [dostopano 30.3.2015]



Unity- Materials and Shaders: http://docs.unity3d.com/Manual/Materials.html, [dostopano 30.3.2015]

Designing artificial intelligence for Games (part 1): https://software.intel.com/en-us/articles/designing-artificial-intelligence-for-games-part-1 , [dostopano 13.3.2015]

Unity Scripting API: http://docs.unity3d.com/ScriptReference/Object.Instantiate.html [dostopano 30.3.2015]

HUD(videogaming): http://en.wikipedia.org/wiki/HUD_(video_gaming) [dostopano 3.3.2015]



Kazalo slik

Slika 1: Posnetek iz igre Counter Strike (vir: lasten) ............................................. 5

Slika 2: Primerjava perspektiv (vir:

http://wiki.blender.org/index.php/Doc:2.4/Manual/3D_interaction/Navigating/3D_Vi

ew) .................................................................................................................. 8

Slika 3: Končan adb test (vir: lasten) ................................................................. 10

Slika 4: Blenderjev uporabniški vmesnik (vir:lasten) ............................................ 11

Slika 5: Prvi zametki razvoja 3D objekta (vir: lasten) ........................................... 13

Slika 6: Razrez škatle za prikaz UV mapiranja (vir: lasten) ................................... 14

Slika 7: Prikaz seamless teksture (vir: lasten) ..................................................... 16

Slika 8: Prikaz UV pogleda v Blenderju (vir: lasten) ............................................. 17

Slika 9: Prikaz islov za namen UV mapiranja v Blenderju (vir: lasten) .................... 18

Slika 10: Prikaz uvožene teksture na UV layout (vir: lasten) ................................. 19

Slika 11: Node editor in povezava barv (vir: lasten) ............................................ 19

Slika 12: Prikaz dokončane teksture za igralčevo ladjo (vir: lasten) ...................... 20

Slika 13: Primerjava prednastavljenih koordinatnih osi obeh programov (vir: lasten)

...................................................................................................................... 20

Slika 14: Prikaz osnovnega uporabniškega vmesnika od Unitya (vir: lasten) .......... 23

Slika 15: Primerjava praznega GameObjecta z GameObjectom na katerem so

komponente (vir: lasten) .................................................................................. 25

Slika 16: Prikaz hierarhične podrejenosti objektov na igralcu (vir: lasten) .............. 25

Slika 17: Delovanje direkcijske luči (vir:

http://docs.unity3d.com/Manual/Lighting.html) .................................................. 27

Slika 18: Delovanje točkovne luči (vir:

http://docs.unity3d.com/Manual/Lighting.html); ................................................. 27

Slika 19: Delovanje luči žarometa (vir:

http://docs.unity3d.com/Manual/Lighting.html) .................................................. 28

Slika 20: Prikazan vpliv shaderjev na material, najbolj osnoven med njimi je

VertexLit (vir: http://docs.unity3d.com/Manual/Materials.html) ............................ 29

Slika 21: Sistem delcev – eksplozija (vir: lasten) ................................................. 29

Slika 22: Prikaz public variabel v skripti kot jih vidi inspector (vir: lasten) .............. 32

Slika 23: Preprosta skripta EnemyMover, ki jo lahko recikliramo (vir: lasten) ......... 33

Slika 24: Box collider, ki obdaja vidno igralno polje in uniči vse objekte, ki prehajajo

izven njega (vir: lasten) .................................................................................... 34

Slika 25: Prikaz elementov uporabniškega vmesnika naše igre (vir: lasten) ........... 35

Slika 26: Zaslonski posnetek igre (vir: lasten) ..................................................... 37

uporaba orodij unity3d in blender za … two conceptually different worlds and try to make our own...

Documents