Licenta2015 Paduraru [628016]

UNIVERSITATEA “ALEXANDRU IOAN CUZA“ IA ȘI
FACULTATEA DE INFORMATIC Ă

LUCRARE DE LICEN ȚĂ
Tower defense – Augmented reality
propus ă de
Păduraru Bogdan-Mihai
Sesiunea : februarie, 2016
Coordonator știin țific
Conf. Dr. Iftene Adrian

1
UNIVERSITATEA ALEXANDRU IOAN CUZA IA ȘI
FACULTATEA DE INFORMATIC Ă

Tower defense – Augmented reality
Păduraru Bogdan-Mihai
Sesiunea : februarie, 2016
Coordonator știin țific
Conf. Dr. Iftene Adrian

2
DECLARA ȚIE PRIVIND ORIGINALITATE ȘI RESPECTAREA
DREPTURILOR DE AUTOR

Prin prezenta declar c ă Lucrarea de Licen ță cu titlul "Tower defense – Augmented
reality" este scris ă de mine și nu a mai fost prezentat ă niciodat ă la o alt ă facultate sau
institu ție de înv ăță mânt superior din țar ă sau din str ăin ătate. De asemenea, declar c ă toate
sursele utilizate, inclusiv cele preluate de pe Int ernet, sunt indicate în lucrare, cu respectarea
regulilor de evitare a plagiatului:
− toate fragmentele de text reproduse exact, chiar și în traducere proprie din alt ă
limb ă, sunt scrise între ghilimele și de țin referin ța precis ă a sursei;
− reformularea în cuvinte proprii a textelor scrise d e c ătre al ți autori de ține
referin ța precis ă;
− codul surs ă, imagini etc. preluate din proiecte open-source sa u alte surse sunt
utilizate cu respectarea drepturilor de autor și de țin referin țe precise;
− rezumarea ideilor altor autori precizeaz ă referința precis ă la textul original.

Ia și, Absolvent: [anonimizat]
_________________

3
DECLARA ȚIE DE CONSIM ȚĂ MÂNT

Prin prezenta declar c ă sunt de acord ca Lucrarea de licen ță cu titlul "Tower defense –
Augmented reality ", codul surs ă al programelor și celelalte con ținuturi (grafice, multimedia,
date de test etc) care înso țesc aceast ă lucrare s ă fie utilizate în cadrul Facult ății de
Informatic ă.
De asemenea, sunt de acord ca Facultatea de Informa tic ă de la Universitatea
Alexandru Ioan Cuza Ia și s ă utilizeze, modifice, reproduc ă și s ă distribuie în scopuri
necomerciale programele-calculator, format executab il și surs ă, realizate de mine în cadrul
prezentei lucr ări de licen ță .

Ia și, Absolvent: [anonimizat]
_________________

4
Acord privind proprietatea dreptului de autor

Facultatea de Informatic ă este de acord ca drepturile de autor asupra progra melelor-
calculator, format executabil și surs ă, s ă apar țin ă autorului prezentei lucr ări, Păduraru
Bogdan-Mihai .

Încheierea acestui acord este necesar ă din urm ătoarele motive:
În viitor, doresc continuarea dezvolt ării acestei aplica ții, publicarea ei în Google Play
Store și extinderea pe alte platforme.

Ia și,
Decan Adrian Iftene Absolvent P ăduraru Bogdan-Mihai
_________________ _________________ _

5
Cuprins
Introducere…………………………………. …………………………………………… ………………………. 6
Contribu ții ………………………………………… …………………………………………… ……………….. 7
Capitolul I: Aplica ții similare ………………………………… …………………………………………… ….8
I.1. AR Defender 2 ………………………….. …………………………………………… ……………….. 8
I.2. PulzAR ……………………………….. …………………………………………… …………………… 8
I.3. Toyota 86 ……………………………… …………………………………………… …………………… 9
Capitolul II: Tehnologii utilizate …………… …………………………………………… …………….. 11
II.1. Unity ………………………………… …………………………………………… …………………… 11
II.1.1.Mediul grafic de dezvoltare ……………. …………………………………………… …….. 12
II.1.2.Interfa ța cu utilizatorul …………………………… …………………………………………. 1 5
II.1.3.Depanare și compilare…………………………………. ……………………………………… 16
II.1.4.Libr ăria Mono……………………………………. …………………………………………… …. 16
II.2.Vuforia SDK ……………………………. ………………… Error! Bookmark not defined. 7
Capitolul III: Arhitectur ă și implementare ……………………………… ……………………………. 18
III.1. Clasa MonoBehaviour……….………………………………………………….. 18
III.1.1. Metode predefinite…………………………………………… ……………..19
III.1.2. Ordinea de execu ție a componentelor..……………………………………..22
III.2. Arhitectura general ă a sistemului ………………………………. ……………………………. 24
III.3. Detalii de implementare ……………….. …………………………………………… ………….. 28
III.3.1. Crearea matricii de joc ……………… …………………………………………… ……….. 28
III.3.2. Detectarea plan șei de joc ………………………………….. …………………………….. 31
III.3.3. Adaugarea obstacolelor ………………. …………………………………………… ……… 32
III.3.4. Gasirea drumului optim utilizand A* …… …………………………………………… . 32
III.3.5. Pornirea jocului și detalii despre mecanica acestuia ……………. ……………….. 35
Capitolul IV: Scenarii de utilizare …………… …………………………………………… ……………. 37
IV.1. Descrierea portalului Vuforia …………… …………………………………………… ………. 37
IV.2. Selectarea unei scene de joc: pa și preg ătitori …………………………………….. ……… 38

6
IV.3. Descrierea unui nivel și pa șii necesari finaliz ării acestuia ……………………………. 40
Concluzii ………………………………….. …………………………………………… ……………………… 43
Bibliografie ……………………………….. …………………………………………… ……………………… 44

Introducere
Lucrarea de fa țǎ prezint ǎ crearea unui joc care presupune interac țiunea atât cu
elementele standard de interac țiunea a unui calculator (mouse și tastatur ǎ) cât și cu elemente
reale precum plan șe ce vor reprezenta h ǎrțile de joc.
Ideea proiectului a pornit odat ǎ cu apari ția aplica țiilor de tip Augmented Reality pe
magazinele de aplica ții mobile, care combinate cu o idee de joc ofer ǎ o senza ție diferit ǎ fa țǎ
de standarde. În prezent, num ǎrul acestor tipuri de aplica ții este destul de redus, cea mai
cunoscut ǎ fiind aplica ția AR Defender2 1.
La ȋnceput, am pornit cu ideea dezvolt ǎrii unei astfel de aplica ții f ǎrǎ a include
posibilitatea de interac țiune cu mediul ȋnconjur ǎtor, dar ȋn timp am ajuns la concluzia c ǎ o
astfel de interac țiune ar oferi o alt ǎ viziune asupra jocului.
Am ales aceast ǎ tem ǎ, deoarece mi s-a p ǎrut un bun prilej de a pune in practic ǎ și de a-
mi extinde cuno știn țele dobândite ȋn timpul facult ǎții. Cu toate c ǎ nu este o idee nou ǎ,
abordarea pe care o vom prezenta este diferit ǎ de cele existente.
Lucrarea este structurat ǎ ȋn trei capitole mari care vor ajuta la ȋnțelegerea structurii
aplica ției, prezentarea detaliilor legate de implementare și introducerea ȋn tehnologiile
folosite.
În primul capitol sunt descrise tehnologiile și libr ǎriile utilizate la dezvoltarea acestui
proiect. Scopul principal este familiarizare utiliz atorului cu principalele idei ale proiectului și
explicarea tehnologiilor folosite. Acesta este ȋmp ǎrțit ȋn dou ǎ subcapitole, „Unity 2”, și
„Vuforia SDK 3”.
Capitolul num ǎrul doi are ca scop prezentarea arhitecturii aplica ției, oferind detalii
despre comunicarea ȋntre diferite module. Deasemenea exist ǎ și detalii despre implementare
care vor ar ǎta cum au fost realizate componentele de baz ǎ ȋn aceast ǎ aplica ție. Cu ajutorul

1 AR Defender2: https://play.google.com/store/apps/details?id=net.i nt13.ardefender&hl=en
2 Unity : https://unity3d.com/
3 Vuforia : https://developer.vuforia.com/

7
exemplelor de cod, diagramelor, imaginilor ajut ǎtoare și a unor informa ții suplimentare se va
ȋncerca ȋnțelegerea func ționalit ǎților aplica ției ȋntr-un mod cât mai corect.
Ultimul capitol are ca scop prezentarea tuturor fun c ționalit ǎților și serviciilor descrise
mai devreme prin diferite exemple și teste care dovedesc corectitudinea aplica ției.
În ȋncheiere se vor prezenta concluziile deduse ȋn urma lucrului la aceast ǎ aplica ție,
posibilele direc ții de dezvoltare pentru viitor, dar și ȋmbun ǎtǎțirea celor existente.

Contribu ții
Proiectul ȋmbin ǎ ideile personale cu cele ale domnului coordonator, pentru a realiza o
aplica ție-joc de tip Tower Defense diferit ǎ fa țǎ de standardele existente, prin ȋmbinarea unor
elemente standard cu obiecte din realitatea ce ne ȋnconjoar ǎ și interac țiunea cu acestea.
Arhitectura general ǎ a aplica ției este conceput ǎ ȋn cea mai mare parte de mine, având
ca repere anumite idei din aplica țiile de acest tip deja existente precum conceptul d e inamic,
drum optim, turnuri ajut ǎtoare pentru eliminarea inamicilor, conceptul de vi a țǎ pentru inamici
etc.
Toate elementele de grafic ǎ din acest proiect, ȋmpreun ǎ cu tehnologiile și libr ǎriile
folosite sunt open source, iar detaliile tehnice le gate de mecanica jocului au fost concepute și
testate de c ǎtre mine.

8
Capitolul I: Aplica ții similare
Capitolul de fa țǎ propune o analiz ǎ sumar ǎ a unor solu ții similare existente pe pia țǎ la
ora actual ǎ, sco țând ȋn eviden țǎ diferite abord ǎri pentru acest tip de aplica ție.
I.1. AR Defender 2 4

Aceast ǎ aplica ție este una din primele de acest tip ap ǎrute pe pia ța telefoanelor mobile,
fiind dezvoltat ǎ și publicat ǎ de c ǎtre compania Bulkypix 5 la ȋnceputul anului 2013. Prin
ȋmbinarea elementelor de realitate augmentat ǎ și a obiectelor 3D care reprezint ǎ diferite
structuri și caractere ȋn joc, aceast ǎ aplica ție a atras imediat aten ția utilizatorilor. Un element
de noutate adus de aceast ǎ aplica ție la momentul lans ǎrii a fost și op țiunea de a putea fi jucat ǎ
cu mai mul ți prieteni.
6

I.2. PulzAR 7

Fiind lansat ǎ ini țial ca un singur joc de c ǎtre dezvoltatorul Exient Ltd 8, aceast ǎ
aplica ție a fost transformat ǎ ȋntr-un pachet de jocuri, toate folosind tehnologia Augmented
Reality. Gradul de noutate al acestei aplica ții ȋl reprezint ǎ platforma pe care acestea pot fi

4 https://itunes.apple.com/en/app/ar-defender-2/id55 9729773?mt=8
5 https://bulkypix.com/
6 http://int13.net/wp-content/uploads/2012/07/ardefe nder2_beta.jpg
7 https://goo.gl/3FWM8n
8 https://www.exient.com/
Figura 1: Interac țiunea ȋntre doi utilizatori

9
jucate și anume PS Vita 9. Un alt lucru impresionant al acestei aplica ții ȋl reprezint ǎ data
apari ției, 12 iunie 2012, la numai patru luni de la lansa rea consolei PS Vita.
10

11

I.3. Toyota 86 AR 12

O alt ǎ aplica ție care folose ște tehnologia Augmented Reality, Toyota 86 AR a fos t
dezvoltat ǎ de c ǎtre cei de la Toyota pentru a prezenta publicului e xperien ța pe care o ofer ǎ
modelul lansat. Creat ǎ pentru platformele Android și IOS, aceast ǎ aplica ție con ține un singur
scenariu ȋn care odat ǎ ce una din plan șele puse la dispozi ție de c ǎtre Toyota este detectat ǎ,

9 https://www.playstation.com/en-us/explore/psvita/
10 Imagine preluat ǎ din filmul de prezentare a aplica ției: https://www.youtube.com/watch?v=BTbYd_hn-J8
11 Imagine preluat ǎ din filmul de prezentare a aplica ției: https://www.youtube.com/watch?v=BTbYd_hn-J8
12 http://www.toyota86ar.com/
Figura 2: Primul joc din pachetul PulzAR, ce implem enteaz ǎ elemente fizice precum reflexia
pentru interac țiune
Figura 3: Un joc de tip fotbal din pachetul PulzAR ce poate fi jucat odat ǎ ce utilizatorul
plaseaz ǎ plan șele ce vor reprezenta spa țiul de joc

10
utilizatorul poate prelua controlul ma șinii Toyota 86 ȋntr-un mediul virtual ce are drept scop
simularea tuturor caracteristicilor ma șinii precum form ǎ, componente, accelera ție, viraje, etc.
13

14

13 http://www.toyota86ar.com/info/
14 http://www.toyota86ar.com/info/
Figura 4: Controlarea ma șinii virtuale Toyota 86 prin intermediul unei table te iPad
Figura 5: Testarea virajelor

11

Capitolul II: Tehnologii utilizate
Pentru crearea acestei aplica ții, am folosit programul Unity pentru a realiza ele mentele
de baz ǎ ale jocului, iar pentru partea de integrare a real it ǎții augmentate am folosit
framework-ul celor de la Qualcomm Vuforia.
II.1. Unity
Pentru crearea aplica ției practice s-a ales programul Unity 15 , care prin complexitatea
sa, ofer ǎ o multitudine de posibilit ǎți pentru dezvoltarea a mai multor tipuri de aplica ții, ȋn
special jocuri.
Unity este un motor de jocuri(Eng: game engine ) ce are la baz ǎ un ȋntreg ecosistem de
servicii și unelte special concepute pentru crearea unui joc de succes cross-platform, reu șind
sǎ converteasc ǎ și s ǎ ruleze acea și aplica ție pe o gam ǎ variat ǎ de platforme și sisteme de
operare. Bine ȋnțeles aceast ǎ conversie presupune existen ța framework-urilor sau a SDK-urilor
aferente platformei respective. Acesta are un mediu de dezvoltare integrat, cu o interfa țǎ ușor
de folosit pentru orice tip de utilizator, prin afi șarea diferitelor câmpuri și propriet ǎți ale
obiectelor existente ȋn aplica ție.
Acest motor de jocuri a fost conceput de c ǎtre cei de la Unity Technologies. În prezent
acesta este cel mai folosit program disponibil c ǎtre public pentru crearea jocurilor pentru
plugin-uri web, platforme desktop, console și dispozitive mobile.
Pentru partea de programare ȋn Unity, ȋntâlnim trei limbaje disponibile și anume C#,
Javascript și Boo. Toate limbajele enumerate sunt asociate para digmei de programare
orientat ǎ obiect. A șadar acestea pun la dispozi ție programatorului posibilitatea de ȋncapsulare
și agregare a obiectelor, dar și posibilitatea de mo ștenire și polimorfism. Structura unei solu ții
realizat ǎ cu aceste limbaje este lizibil ǎ, bine organizat ǎ și u șor de ȋntre ținut, u șurând astfel ȋn
timp munca programatorilor.

15 Unity: https://unity3d.com/

12

Limbajul C# 16 este ȋn prezent cel mai folosit de c ǎtre comunitatea de dezvoltatori ai
programului Unity. Un prim motiv ar fi faptul c ǎ majoritatea documenta ției on-line oferit ǎ de
cǎtre departamentul de suport de la Unity Techonologi es este scris ǎ ȋn acest limbaj, ȋmpreun ǎ
cu multitudinea de tutoriale 17 realizate de acea și companie. Deasemenea, folosirea acestui
limbaj deschide accesul la diferite framework-uri și libr ǎrii deja existente și folosirea lor ȋn
limita caracteristicilor de compatibilitate cu plat forma pe care se dore ște finalizarea
proiectului. Pentru realizarea acestei aplica ții s-a ales acest limbaj datorit ǎ facilit ǎților
prezentate mai sus, dar și pentru simplul fapt c ǎ este un limbaj dezvoltat de c ǎtre cei de la
Microsoft, ȋnso țit de o multitudine de exemple, ȋntre ținut și ȋn continu ǎ dezvoltare.
Javascript 18 , ca și limbaj de programare, este bazat mai mult pe prin cipiul de
prototipizare. Predominant, acesta este folosit pen tru dezvoltarea func ționalit ǎților pentru
pagini web pentru partea de client, ȋns ǎ se pliaz ǎ cu succes și pentru scriptarea ȋn Unity
deoarece, precum limbajul C#, poate fi folosit pent ru acces la obiecte ȋncapsulate. Astfel se
pot construi cu u șurint ǎ prin intermediul lui diferite șabloane de proiectare necesare
dezvolt ǎrii unui joc.
Boo 19 a ap ǎrut ȋn anul 2003, este un limbaj de programare static, b azat pe sintaxa din
limbajul Python și a fost integrat ȋn Unity pentru a m ǎri gama de dezvoltatori Unity. În anul
2014, Unity Techonologies au anun țat ȋn mod oficial c ǎ nu vor mai oferi suport pentru
documenta ția limbajului de scriptare Boo ȋn Unity, ȋnsa ȋl p ǎstreaz ǎ ca limbaj de programare
pentru Unity ȋn mod special pentru cei care aveau deja proiecte e xistente ȋn acest limbaj.

II.1.1. Mediul grafic de dezvoltare
Similar programelor de randare de grafic ǎ tridimensional ǎ, programul Unity dispune
de un modul de interpretare a unei scene ȋn 2 perspective, și anume 2D/ 3D, modul pus la
dispozi ția dezvoltatorului pentru vizualizarea elementelor ce vor compune sistemul care se

16 https://msdn.microsoft.com/en-us/library/kx37x362.a spx
17 https://unity3d.com/learn/tutorials/topics/scriptin g
18 https://developer.mozilla.org/en-US/docs/Web/JavaSc ript/About_JavaScript
19 http://boo-language.github.io/
Figura 6: Cele trei limbaje de programare disponib ile in Unity

13
dore ște a fi creat. Pentru a putea ȋntelege mai bine no țiunea de „scen ǎ”, ȋntâi trebuie s ǎ
definim componenta de baz ǎ ȋn dezvoltarea unei aplica ții cu acest program, și anume
conceptul de GameObject 20 .
Un GameObject este componenta fundamental ǎ ȋn Unity, abstractizând orice tip de
participant, precum caractere, piese de decor, elem ente ce țin de logica jocului etc. În mod
implicit, aceasta con ține câteva câmpuri ce pot fi editate, ȋmpreun ǎ cu componenta de baz ǎ,
Transform. Printre câmpurile ce pot fi editate ȋntâlnim un checkbox ȋn col țul din stânga sus
care reprezint ǎ starea obiectului la un anumit moment (activ/inact iv), urmat imediat de un
TextField unde gasim și putem schimba numele obiectului. Câmpul ce indic ǎ daca un obiect
este static sau nu, reprezint ǎ detalii legate de optimizare ce nu vor fi discutat e in cadrul acestui
proiect. Tag-ul este folosit ȋn mod special pentru o identificare mai avansat ǎ, iar câmpul de
Layer ofer ǎ diferite op țiuni pentru afi șarea unui obiect. De cele mai multe ori, un GameObj ect
este folosit drept container pentru componentele in teractive din scen ǎ precum scripturile
create de dezvoltatori, componente pentru simul ǎri fizice și comportamentale, componente de
grafic ǎ (imagini/modele 3D), etc. O prim ǎ component ǎ pe care orice GameObject o are este
cea men ționat ǎ mai sus, și anume componenta Transform. Aceasta este alc ǎtuit ǎ din trei
vectori tridimensionali ce descriu pozi ția unui obiect, rota ția și dimensiunile. Cele trei valori
care apar ȋn imagine pentru fiecare tip de vector reprezint ǎ una din axele de coordonate dintr-
un sistem tridimensional.

Vectorul de pozi ționare, dup ǎ cum putem deduce din nume, ȋnregistreaz ǎ pozi ția unui
obiect pe cele trei axe de coordonate. Vectorul de rota ție stocheaz ǎ valori referitoare la rota ția
obiectului ȋn raport cu axele de coordonate (X,Y,Z), iar vector ul de scalare ofer ǎ informa ții
despre factorii de scalare ȋn raport cu acea și axa de coordonate men ționat ǎ mai devreme.
Fiecare obiect poate avea un p ǎrinte, fapt ce permite ca valorile celor trei vecto ri din

20 http://docs.unity3d.com/Manual/class-GameObject.htm l
Figura 7: Interfa ța GameObject

14
componenta de baz ǎ, Transform, s ǎ se raporteze la o scar ǎ local ǎ ȋn loc de una global ǎ. Se
poate observa astfel o dispunere ierarhic ǎ ȋntre obiectul p ǎrinte și copil, dispunere
reprezentat ǎ de altfel și ȋn fereastra ierarhiilor din interfa ța programului. Astfel conceptul de
pǎrinte poate fi definit recursiv ȋntrucât orice obiect poate fi la rândul s ǎu p ǎrinte pentru un
altul. Deasemenea, trebuie men ționat c ǎ schimb ǎrile efectuate pe componenta Transform a
unui obiect p ǎrinte sunt aplicate ȋn mod recursiv la toat ǎ ierarhia de copii, schimbându-le
astfel valorile de pozi ție, rota ție și scalare globale.

Odat ǎ ȋnțelese aceste principii, putem continua cu definirea unui termen important
mentionat mai sus, și anume cel de Scene 21 (scen ǎ). O scen ǎ reprezint ǎ o colec ție de obiecte
ce sunt salvate ȋntr-un fi șier cu extensia „ .scene”. Într-un joc, scenele po t avea diferite
reprezent ǎri, de la meniuri, pauze cinematice pân ǎ la nivelele propriu zise ale unui joc. Odat ǎ
deschis un astfel de fi șier ȋn programul Unity, dezvoltatorul dispune de toate o biectele care se
afl ǎ ȋn scen ǎ și poate ȋncepe editarea acestora, prin mutarea lor, ad ǎugarea de obiecte noi,
ștergerea unor obiecte etc. Un lucru important ȋn vizualizarea unei scene este perspectiva din
care aceasta este v ǎzut ǎ. Cât timp aceasta este pornit ǎ ȋn programul Unity, ea se afl ǎ ȋn modul
debug, ceea ce ofer ǎ anumite facilit ǎți pentru testarea acesteia, precum schimbarea unor
anumite valori de pe obiecte, butonul de pauz ǎ care poate opri ac țiunea la un moment dat ȋn
scena ǎ, consola aplica ției unde sunt afi șate eventualele erori netratate ȋn momentul rul ǎrii
aplica ției, etc. Al doilea mod ȋn care o scen ǎ poate fi deschis ǎ este modul release care
presupune crearea unui executabil pentru aplica ție și pornirea lui. În acest mod toate aspectele
men ționate mai sus nu mai sunt disponibile, iar acest m odul este folosit strict pentru testarea
elementelor de joc și grafic ǎ.
Aceast ǎ aplica ție folose ște patru scene diferite care vor fi descrise ȋn detaliu ȋn
capitolul urm ǎtor, și anume meniul principal și cele trei scene de joc.
Un ultim lucru ce trebuie men ționat la nivel de scene este conceptul de camer ǎ 22 . La
baz ă, aceasta este un GameObject ce are ata șat o component ǎ de tip „ Camera ”, implementat ǎ
de c ǎtre cei de la Unity Technologies. Rolul acestei com ponente este de a afi șa pe ecranul de
joc diferite elemente, ȋn func ție de parametrii seta ți din modulul de editarea al acesteia. Câ țiva
parametrii care merit ǎ mentiona ți ar fi cel de „Culling Mask” care permite selectar ea unui

21 http://docs.unity3d.com/Manual/CreatingScenes.html
22 http://docs.unity3d.com/Manual/class-Camera.html
Figura 8: Ierarhie obiecte

15
anumit set de layere pe care camera s ǎ le afi șeze (astfel dac ǎ un obiect se afl ǎ pe un layer
diferit fa țǎ de set-ul de layere pe care camera le va afi șa, acesta nu va fi prezent pe ecranul de
joc) și cel de Projection care ofer ǎ dou ǎ tipuri de afi șare, „Perspective” și „Ortographic”.
Diferen ța ȋntre cele dou ǎ tipuri este modul ȋn care se dore ște ca jocul s ǎ fie vizualizat. Astfel
proiec ția de tip ortografic ǎ face abstrac ție de axa Z la pozi ționare și ofer ǎ o perspectiv ǎ 2D a
jocului, pe când proiec ția de tip „Perspective” ofer ǎ o vizualizare complet ǎ a obiectelor pe
cele trei axe.
În aplica ția dezvoltat ǎ, proiec ția camerei a fost setata pe op țiunea de „Perspective”
pentru cele trei nivele de joc, ȋntrucât recunoa șterea obiectelor din mediul ȋnconjur ǎtor
presupune o vizualizare pe toate cele trei axe, iar pentru scena de meniu am ales op țiunea de
vizualizare ortografic ǎ deoarece am folosit doar elemente de grafic ǎ 2D.

II.1.2. Interfa ța cu utilizatorul
Unity pune la dispozi ția utilizatorului o serie de ferestre 23 care u șureaz ǎ lucrul cu
diferite obiecte. Principalele ferestre din interio rul programului sunt: ferestrele de Scene View
și Game View , fereastra de ierarhie, cea de vizualizare a eleme ntelor proiectului, cea de
debug și fereastra Inspector unde sunt prezente toate elem entele de pe un GameObject
selectat. Un mare plus const ǎ ȋn posibilitatea de rea șezare și eliminare a ferestrelor, dar și cel
de a construi o interfa țǎ proprie pentru afi șare ȋn fereastra de Inspector a unor anumite
componente, sau a diferitelor entit ǎți prezente ȋn scripturile create pe care ȋn mod normal
programul Unity nu știe s ǎ le ofere o vizualizare grafic ǎ, precum colec ții de date de tip
dic ționar.
Interfa ța acestui program este relativ u șor de ȋnteles, acesta reprezentând unul din
motivele pentru care a fost ales Unity. Totodat ǎ simplitatea cu care pot fi aranjate obiectele și
construite scenele a permis acordarea unei aten ții mai mari c ǎtre partea de func ționalitate a
aplica ției prin implementarea func țiilor și a algoritmilor propu și pentru rezolvare.

23 http://docs.unity3d.com/Manual/UsingTheEditor.html

16

II.1.3. Depanare și compilare
Fiind un motor de jocuri cross-platform, Unity perm ite depanare unui proiect pe mai
multe platforme cu un minim de efort. Dezvoltatorul trebuie s ǎ asigure existen ța SDK-urilor
necesare și a referin țelor acestora pe unitatea unde se efectueaz ǎ build-ul. Enumer ǎm
platformele suportate ȋn acest moment de ultima versiune de Unity existent ǎ: Windows,
MAC, Linux, Web Player, IOS, Android, BlackBerry 10 , Windows Phone 8, Windows Store
Apps, PlayStation 3, Xbox 360, PlayStation 4, PlayS tation Vita, PlayStation Mobile, Xbox
One, Wii U, Tizen.

II.1.4. Libr ǎria Mono
Scriptingul pentru acest motor de jocuri (game engi ne) este bazat pe Mono 24 .
Sponsorizat de Xamarin, Mono este o implementare de tip open-source a frameworkului
.NET bazat ǎ pe standardele ECMA pentru C# si CLR (common langu age runtime, ma șina
virtual ǎ a frameworkului .NET). Fiind o implementare open-s ource, exist ǎ o comunitate

24 http://www.mono-project.com/
Figura 9: Interfa țǎ Unity

17
numeroas ǎ de dezvoltatori care contribuie ȋn permanen țǎ la dezvoltarea și ȋmbun ǎtǎțirea
Mono-ului pentru a ajunge solu ția cea mai bun ǎ ȋn vederea implement ǎrii aplica țiilor cross
platform.
Unul din dezavantajele pe care programul Unity ȋl are este faptul c ǎ ruleaz ǎ pe o
versiune veche de Mono care suport ǎ doar frameworkul .NET 2.0 pentru majoritatea
platformelor, și versiuni mai noi pân ǎ la 3.5 doar pentru anumite platforme. Din acest mo tiv și
datorit ǎ num ǎrului de cereri foarte mari din partea comunit ǎții, cei de la Unity Technologie au
promis c ǎ ȋn viitorul apropiat vor face tot posibil s ǎ ajung ǎ la o versiune cât mai apropiat ǎ de
cea actual ǎ a frameworkului .NET.
Am men ționat mai devreme faptul c ǎ scripting-ul ȋn Unity se poate realiza ȋn trei
limbaje diferite, și anume C#, JavaScript și Boo. Acest lucru este posibil datorit ǎ librariei
Mono care are suport pentru o multitudine de limbaj e, prin intermediul diferitelor
compilatoare dezvoltate și integrate ȋn aceast ǎ libr ǎrie.

II.2. Vuforia SDK
Vuforia este un kit de dezvoltare software conceput special pentru dispozitive mobile,
care permite crearea de aplica ții ȋmbinate cu realitatea augmentat ǎ. Folose ște tehnologia
Computer Vision 25 pentru recunoa șterea imaginilor planare și a unor obiecte simple 3D ȋn
timp real. Cu ajutorul acesteia, dezvoltatorii pot a șeza și orienta diferite obiecte virtuale,
precum modele 3D, ȋn rela ție cu obiecte din lumea real ǎ vǎzute prin intermediul camerei
dispozitivului mobil. Dup ǎ aceea, obiectul virtual se orienteaz ǎ și pozi ționeaz ǎ ȋn func ție de
imaginea real ǎ care va fi recunoscut ǎ, astfel ȋncât din perspectiva persoanei care va testa
aplica ția va p ǎrea c ǎ acest obiect virtual face parte din lumea real ǎ. SDK-ul Vuforia suport ǎ o
varietate de imagini 2D și 3D care pot fi detectate, cel mai important tip f iind tipul Image
Target care a fost folosit ȋn acest proiect.
Vuforia ofer ǎ o interfa țǎ de programare (Application Programming Interface/A PI) ȋn
diferite limbaje precum C++, Java, Objective-C și limbaje din framework-ul .NET printr-o
extensie a programului Unity. În acest mod, SDK-ul suport ǎ ȋn mod nativ dezvoltarea pentru
platformele mobile IOS și Android, permi țând totodat ǎ și crearea de aplica ții de tip AR ȋn
Unity care pot fi portate u șor pe aceste platforme. La nivel de compatibilitate , aplica țiile de tip
AR folosind Vuforia includ o gam ǎ larg ǎ de dispozitive, incluzând Iphone-urile cu versiune a

25 https://en.wikipedia.org/wiki/Computer_vision

18
minim ǎ 4, Ipad-urile, tabletele și telefoanele Android ce folosesc un Android OS cu versiunea
minim ǎ 2.2 sau care au un procesor cel pu țin la fel de bun ca modelul ARMv6.

Capitolul III: Arhitectur ă și implementare
Orice clas ǎ creat ǎ ȋn Unity mo ștene ște ȋn mod implicit clasa de baz ǎ MonoBehaviour.
Aceast ǎ clas ǎ con ține un set de propriet ǎți, func ții și evenimente care permit unui obiect s ǎ
interac ționeze cu celelalte obiecte existente. Un obiect di n Unity poate con ține mai multe
clase derivate din aceasta, ȋns ǎ nu poate con ține clase care nu respect ǎ aceast ǎ regul ǎ de
mo ștenire. Acest lucru nu ȋnseamn ǎ ȋn mod neap ǎrat c ǎ nu putem avea clase simple, precum
clasa Levels construit ǎ de mine și folosit ǎ cu scopul de a memora nivelele predefinite ale
aplica ției. ș
Implementarea final ǎ a aplica ției va consta din construirea unui set de clase și
gestionarea corect ǎ a acestora. În continuare se va prezenta arhitectu ra concret ǎ a aplica ției,
ȋntr-un mod generic deoarece cele trei scene de joc sunt construite pe acela și asamblu de
clase, cu mici modific ǎri a unor parametrii ce vor fi men ționa ți.

III.1. Clasa MonoBehaviour
MonoBehaviour 26 este clasa de baz ǎ din care deriv ǎ toate scripturile ce
interac ționeaz ǎ ȋntr-o scen ǎ. În cazul limbajului Javascript, orice clas ǎ deriv ǎ ȋn mod automat
din aceasta, pe când ȋn cazul limbajelor C# și Boo acest lucru este specificat ȋn mod explicit
prin operatorul de mo ștenire.
O regul ǎ important ǎ pentru aceast ǎ clas ǎ este faptul c ǎ crearea unei instan țe a acesteia
din interiorul unei instruc țiuni de cod va ridica o excep ție ȋntrucât orice instan țǎ de
MonoBehaviour trebuie s ǎ fie ata șat ǎ unui GameObject, cum am men ționat mai devreme.
Astfel de și utilizatorul nu are acces la o func ție constructor sau destructor, exist ǎ alternative
pentru acestea, care vor fi prezentate ȋn subcapitolul ce urmeaz ǎ.
Orice clas ǎ care derivat ǎ din aceasta are la dispozi ție un set de metode pe care le poate
suprascrie ȋn func ție de necesitate. Un obiect care are o serie de scr ipturi ata șate, dar care este
inactiv ȋn momentul rul ǎrii aplica ției, va preveni executarea func țiilor Awake, Start, Update,
OnGUI, etc. ce urmeaz ǎ a fi prezentate ȋn subcapitolul urm ǎtor.

26 http://docs.unity3d.com/ScriptReference/MonoBehavio ur.html

19
Un lucru important ce merit ǎ men ționat este faptul c ǎ Unity ruleaz ǎ toate scripturile ce
mo ștenesc MonoBehaviour pe un singur fir de execu ție, la o vitez ǎ egal ǎ cu num ǎrul de cadre
(frame-uri) per secund ǎ suportate de dispozitivul pe care ruleaz ǎ aplica ția ȋn acel moment.
Exist ǎ posibilitatea execut ǎrii unor func ții definite de dezvoltator ȋntr-un fir de execu ție
separat, cu condi ția de a nu folosi referin țe c ǎtre instan țe de obiecte din firul principal de
execu ție.
Acest concept de execu ție a unei aplica ții poate avea atât p ǎrți pozitive cât și negative.
Marele dezavantaj evident este pericolul de oprire a firului de execu ție principal, lucru ce
duce ȋn mod implicit la oprirea aplica ției. P ǎstrarea unui singur fir de execu ție poate
reprezenta ȋns ǎ și un avantaj, mai ales ȋn perioada de testare și analiz ǎ a modulelor proiectului,
când se poate observa execu ția secven țial ǎ a tuturor func țiilor.
În subcapitolul urm ǎtor vom detalia exact cum func ționeaz ǎ principalele metode din
Unity.

III.1.1. Metode predefinite
Principalele metode predefinite care au ȋn componen ța lor un comportament specific și
care se apeleaz ǎ automat ȋn func ție de anumite propriet ǎți ce trebuie s ǎ le ȋndeplineasc ǎ un
GameObject sunt cele care fac referin țǎ la anumite evenimente din durata de via țǎ a acestuia,
sau a aplica ției: evenimente de timp, interac țiuni fizice, evenimente de UI, etc.
Sunt prezentate ȋn continuare metodele care au fost folosite ȋn mod principal la
dezvoltarea aplica ției finale, ȋmpreun ǎ cu arhitectura lor. Toate aceste metode sunt
implementate de clasa MonoBehaviour și suprascrise de c ǎtre dezvoltator.
Metoda Awake 27 este apelat ǎ odat ǎ cu ȋnc ǎrcarea instan ței obiectului asociat ȋn
momentul rul ǎrii aplica ției. Aceasta metod ǎ este de regul ǎ folosit ǎ pentru ini țializarea
variabilelor și poate fi v ǎzut ǎ ca o alternativ ǎ la constructor cum am men ționat mai devreme,
ȋntrucât este apelat ǎ o singur ǎ dat ǎ pe ȋntreaga durat ǎ de via țǎ a scriptului.
Fiecare obiect poate con ține unul sau mai multe scripturi, fiecare dintre el e l ǎsând
posibilitatea de a suprascrie aceast ǎ metod ǎ. Ordinea execu ției acestor func ții ȋn acest caz va
fi aleatoare ȋn cazul ȋn care nu se specific ǎ implicit, lucru ce va fi discutat ȋn urm ǎtorul
subcapitol. Astfel se recomand ǎ folosirea acestei metode doar pentru ini țializare de variabile
când nu este specificat ǎ o ordine clar ǎ ȋntre scripturi, iar setarea referin țelor c ǎtre instan țe a
altor clase se face de obicei prin suprascrierea un ei alte func ții, și anume Start .

27 http://docs.unity3d.com/ScriptReference/MonoBehavio ur.Awake.html

20
Func ția Start 28 este apelat ǎ dup ǎ ce se execut ǎ metoda Awake la toate obiectele ce
con țin instan țe ale clasei MonoBehaviour, astfel ȋncât la momentul pornirii acesteia toate
referin țele c ǎtre celelalte instan țe de clasa MonoBehaviour exist ǎ și vor putea fi accesate f ǎrǎ
a ȋntâmpina probleme. La fel ca și func ția Awake, aceast ǎ func ție nu este apelat ǎ decât o
singur ǎ dat ǎ pe durata de via țǎ a obiectului.
Func ția Update 29 este apelat ǎ la fiecare frame, excep ție f ǎcând cazul când obiectul
este inactiv. Aceasta este una dintre cele mai folo site func ții ȋntrucât permite implementarea
comportamentului unui obiect. Echivalentul acestei func ții ar putea fi o bucl ǎ de tip while a
cǎrei execu ție este condi ționat ǎ de trecerea unui frame. Blocarea unei astfel de fu nc ții prin
diferite metode poate avea rezultate negative asupr a aplica ției, ȋntrucât a șa cum am men ționat
mai devreme, rularea scripturilor se face ȋntr-un mod sincron pe un singur fir de execu ție. În
general se evit ǎ pe cât de mult posibil folosirea acestei func ții, utilizând alternative precum
apelarea unor func ții bazate pe evenimente, ȋns ǎ o structurare și implementare corect ǎ a
anumitor func ționalit ǎți ar avea cam acela și efect.
Fa țǎ de Awake și Start, aceast ǎ metod ǎ se apeleaz ǎ ȋncotinuu, ȋns ǎ primul apel al
acesteia are loc abia dup ǎ finalizarea celor dou ǎ.
De și nu am specificat ȋn aceast ǎ aplica ție o limit ǎ pentru num ǎrul de frame-uri care s ǎ
se execute pe secund ǎ, acestea se limiteaz ǎ automat datorit ǎ SDK-ului Vuforia care are nevoie
de o camer ǎ Web pentru a putea face identificare obiectelor. D eoarece camera web integrat ǎ
calculatorului ruleaz ǎ doar la 30 frame-uri pe secund ǎ, aplica ția se va limita automat la
aceast ǎ valoare, ȋns ǎ pentru aplica ții care nu ȋntâlnesc astfel de limite, se recomand ǎ setarea la
60 de frame-uri. Aceast ǎ setare se poate face foarte u șor prin modificarea unui câmp public
din interiorul clasei Application 30 pus ǎ la dispozi ție de c ǎtre Unity. Deoarece este vorba de
ini țializarea unui variabile, a șa cum am men ționat mai sus, putem face acest lucru prin
plasarea urm ǎtoarei linii de cod ȋntr-o func ție Awake:
Application.targetFrameRate = 60;

În cadrul metodei OnGUI 31 se implementeaz ǎ set ǎrile și func ționalit ǎțile ce țin de
interfa ța cu utilizatorul. În aplica ția curent ǎ, partea de interfa țǎ este minimal construit ǎ
ȋntrucât accentul a fost pe implementarea func ționalit ǎților de baz ǎ, ȋns ǎ se merit ǎ men ționate
câteva aspecte generale legate de aceasta. Precum f unc ția Update, și func ția aceasta este
apelat ǎ la un num ǎr de frame-uri pe secund ǎ, ȋns ǎ detalii stricte nu sunt cunoscute, cei de la

28 http://docs.unity3d.com/ScriptReference/MonoBehavio ur.Start.html
29 http://docs.unity3d.com/ScriptReference/MonoBehavi our.Update.html
30 http://docs.unity3d.com/ScriptReference/Applicatio n.html
31 http://docs.unity3d.com/ScriptReference/MonoBehavi our.OnGUI.html

21
Unity Technologies afirmând c ǎ num ǎrul de frame-uri la care este apelat ǎ aceasta este adjustat
automat.
Deasemenea, ultima versiune lansat ǎ de Unity a primit un nou system de UI(user
interface) mult mai flexibil și optimizat decât cel vechi, ȋns ǎ ȋn momentul ȋn care am lucrat la
interfa ța acestei aplica ții, acest sistem era ȋnc ǎ ȋn perioada de beta, motiv pentru care nu a fost
utilizat ȋn ȋntregime ȋn cadrul acestui proiect.
Detalii legate de implementarea interfe ței ȋn cadrul acestei func ții vor fi oferite imediat
ȋn subcapitolul responsabil cu implementarea func ționalit ǎților.
Metodele ce vor fi prezentate ȋn continuare sunt metode care func ționeaz ǎ doar ȋn
cazul ȋn care un obiect con ține componente de fizic ǎ din pachetul de baz ǎ de la Unity, precum
Rigidbody 32 și componenta Collider 33 .
Metoda OnTriggerEnter 34 este apelat ǎ când dou ǎ obiecte ce con țin componentele de
fizic ǎ men ționate mai sus se intersecteaz ǎ, iar obiectul de pe care este apelat ǎ aceast ǎ metoda
are setat ǎ op țiunea IsTrigger de pe componenta sa de Collider. Aceast ǎ metod ǎ con ține un
parametru de tip Collider care indic ǎ o referin țǎ cǎtre obiectul cu care a avut loc interac țiunea.

Metoda OnTriggerExit 35 are o structur ǎ similar ǎ cu cea de mai sus, cu diferen ța cǎ
este apelat ǎ ȋn momentul ȋn care dou ǎ obiecte ce au fost intersectate se separ ǎ, sau mai bine
zis un obiect p ǎrǎse ște zona de coliziune a celuilalt obiect. Con ține tot un singur parametru de
tip Collider care indic ǎ o referin țǎ cǎtre obiectul care tocmai a p ǎrǎsit zona de coliziune.

32 http://docs.unity3d.com/ScriptReference/Rigidbody.h tml
33 http://docs.unity3d.com/ScriptReference/Collider.ht ml
34 http://docs.unity3d.com/ScriptReference/MonoBehavio ur.OnTriggerEnter.html
35 http://docs.unity3d.com/ScriptReference/MonoBehavio ur.OnTriggerExit.html
Figura 10: Reprezentare componente de fizic ǎ

22
Ambele metode au fost folosite ȋn crearea acestei aplica ții. Desi Unity ofer ǎ multe alte
evenimente legate de fizic ǎ ȋntre obiecte, ȋn aceast ǎ lucrare a fost suficient ǎ folosirea celor 2
men ționate.

III.2.1.2. Ordinea de execu ție a scripturilor
Așa cum a mai fost men ționat, ordinea de apel a scripturilor ȋn Unity poate fi setat ǎ
explicit de c ǎtre dezvoltator. A șa cum se poate vedea ȋn imaginea de mai jos, Unity pune la
dispozi ție o interfa țǎ ușor de folosit pentru modificarea ordinii de execu ție a scripturilor, prin
butoanele „+” si „-” care au rolul de ad ǎugare și ștergere a unui script, ȋmpreun ǎ cu un câmp
editabil care arat ǎ intervalul de timp ȋntre execu ții. De și este recomandat ca metoda Awake s ǎ
se ocupe doar de ini țializ ǎri de variabile, iar metoda Start de setarea referi n țelor c ǎtre anumite
obiecte, exist ǎ și excep ții de la aceast ǎ regul ǎ, lucru care face ca setarea ordinii de execu ție s ǎ
fie un lucru util. La ȋnceputul aplica ției a fost folosit ǎ aceast ǎ metod ǎ, ulterior ȋns ǎ a fost
restructurat ȋntregul sistem de clase și ȋn momentul de fa țǎ aceast ǎ tehnic ǎ nu este folosit ǎ ȋn
proiect.

Figura 11: Pa șii necesari deschiderii interfe ței

23

Figura 12: Prezentarea interfe ței „Script execution order”

24
III.2. Arhitectura general ă a sistemului

Figura 13: Arhitectura general ă a sistemului

25
Interac țiunea ȋntre scripturi și obiectele din interiorul unei scene se realizeaz ǎ ȋn mod
principal prin intermediul comportamentului clasei MonoBehaviour și a suitei de func ții puse
la dispozi ție de c ǎtre aceasta. Modulele de baz ǎ ale acestui proiect au ȋn vizor acest aspect
ȋntrucât schimbul de mesaje ȋntre acestea se realizeaz ǎ ȋn mare parte pe baza unor evenimente
ale clasei MonoBehavior și a unor module externe precum cele de la SDK-ul Vu foria. De și ȋn
diagrama de activitate de mai sus sunt prezentate o serie de activit ǎți ce descriu pas cu pas
evenimentele ce au loc ȋntr-o scen ǎ de joc, la baz ǎ se afl ǎ patru clase principale. Cum a mai
fost men ționat, metoda Awake oferit ǎ de clasa MonoBehaviour are rolul de a ini țializa
anumite variabile. În cadrul acestui proiect am fol osit acest prilej pentru a crea o instan țǎ
unic ǎ a acestor clase, pentru o accesare mai u șoar ǎ a acestora. Acest principiu este cunoscut
sub numele de Singleton, iar implementarea este foa rte similar ǎ indiferent de limbajul de
programare folosit. În cadrul programului Unity, ac esta reprezint ǎ o modalitate u șoar ǎ de
accesare a unor instan țe de scripturi importante de c ǎtre mai multe obiecte care sunt create
dup ǎ o anumit ǎ perioad ǎ.
Cele patru clase de baz ǎ care asigur ǎ func ționalitatea de baz ǎ și preg ǎtirea tutoror
pa șilor necesari pornirii unei scene de joc sunt:
1. MapCreator: ofer ǎ func ționalit ǎți legate de harta de joc și conversii de coordonate
din sistemul local ȋn cel global
2. Astar: ofer ǎ func ționalit ǎțile necesare g ǎsirii drumului optim
3. EnemyController: are rolul de a porni și gestiona inamicii pentru nivelul respectiv
4. CustomEventHandler: este pus ǎ la dispozi ție de c ǎtre dezvoltatorii celor de la
Vuforia, oferind diferite evenimente și informa ții legate de detectarea imaginilor
augmentabile
Pe lâng ǎ aceste clase de baz ǎ, mai sunt prezente și altele ȋns ǎ vor fi prezentate ȋn
subcapitolele ce urmeaz ǎ ȋntrucât au func ționalit ǎți mai stricte, specifice unor anumitor
scenarii.
Înainte de a trece la urm ǎtorul subcapitolul, vom mai prezenta structura gene ral ǎ a
SDK-ului de la Vuforia, printr-o descriere succint ǎ a ierarhiei de clase și a func ționalit ǎților
oferite.
Diagrama prezint ǎ o privire de asamblu a modului ȋn care procesul de dezvoltare a
unei aplica ții cu platforma Vuforia are loc. Platforma const ǎ din motorul Vuforia(Vuforia
Engine), care este g ǎsit ȋn interiorul SDK-ului, sistemul de Target Manageme nt, hostat pe
portalul de la Vuforia și serviciul op țional de Cloud Target Database.

26
36

Baza de date Device Target
Acest tip de baz ǎ de date este creat ǎ prin intermediul serviciului de Target Manager.
Un pachet creat cu ajutorul acestei baze de date și preluat de c ǎtre utilizator va con ține un set
de imagini selectate de c ǎtre acesta pentru a fi identificate ȋn proiect, un fi șier XML ȋn care se
gǎsesc diferite op țiuni de configurare și un fi șier binar ȋn care se reg ǎsesc diferite op țiuni
despre baza de date folosit ǎ. Toate acestea sunt compilate de c ǎtre aplica ția dezvoltatorului
Vuforia, dup ǎ care sunt ȋmpachetate și exportate sub forma unui fi șier cu extensia
„.unitypackage”, pachet ce va fi importat ȋn Unity și folosit de cǎtre SDK-ul de la Vuforia ȋn
timpul rul ǎrii aplica ției.

Baza de date Cloud
Baza de date Cloud poate fi creat ǎ prin intermediul serviciului de Target Manager sau
folosind serviciile Web de la Vuforia. Imaginile ce urmeaz ǎ a fi identificate sunt g ǎsite pe
baza unor interog ǎri ȋn timpul rul ǎrii aplica ției cu ajutorul functionalit ǎții de recunoa ștere
cloud . Aceasta realizeaz ǎ o scanare vizual ǎ ȋn baza de date cloud pe baza imaginilor
ȋnregistrate de c ǎtre camer ǎ. Pe lang ǎ acest lucru, imaginile ce urmeaz ǎ a fi identificate con țin
la nivel de baz ǎ de date metadate ce sunt returnate ȋn timpul interog ǎrilor.
De și SDK-ul Vuforia pune la dispozi ție o multitudine de clase, servicii și interfe țe
pentru realizarea diferitelor functionalit ǎți, putem realiza o mic ǎ structurare a acestora. Astfel

36 http://developer.vuforia.com/library/resources/api/ unity/index
Figura 14: Schema general ǎ a platformei Vuforia

27
ȋn imaginea de mai jos avem prezentat ǎ o structur ǎ pe nivele a câtorva functionalit ǎți de baz ǎ,
precum clasele QCARBehaviour și Tracker. Prima este responsabil ǎ cu lansarea
evenimentelor legate de detectarea a diferitor obie cte ȋn interiorul aplica ției. Pentru a putea
transmite astfel de mesaje ȋn interiorul proiectului aceasta deriv ǎ din clasa MonoBehaviour,
lucru ce poate fi dedus de altfel și din imaginea de mai jos ȋntrucât aceasta se situeaz ǎ ȋn
ambele nivele principale de programare și anume, Unity și Vuforia SDK.
Tracker reprezint ǎ clasa de baz ǎ pentru diferitele tipuri de imagini care pot fi
recunoscute cu SDK-ul Vuforia. De și exist ǎ mai multe tipuri, precum Virtual Button
Behaviour, Multi Target Behaviour, Word Target Beha viour, Cyllinder Target Behaviour și
Marker Behaviour, ȋn cadrul acestui proiect nu a fost folosit ǎ decat tipul de imagine Image
Target Behaviour. Totodat ǎ rolul acestei clase const ǎ și ȋn definirea unui set de algoritmi
pentru identificarea fiec ǎrui tip de imagine amintit mai sus.

37

Alte componente importante ce sunt g ǎsite ȋn SDK-ul de la Vuforia:

Camera
Aceast ǎ component ǎ este responsabil ǎ cu captarea și pasarea cadrelor jocului c ǎtre
componenta Tracker. În cadrul unui proiect Unity, i ni țializarea camerei se face ȋn mod
automat, la fel ca și setarea num ǎrului de cadre per secunda (FPS), acesta fiind calc ulat ȋn
func ție de fiecare dispozitiv, dimensiune și calitate.
Image Converter
Functionalit ǎțile puse la dispozi ție de c ǎtre aceast ǎ component ǎ nu sunt disponibile
dezvoltatorilor, acestea având rolul de a converti reprezentarea implicit ǎ a unei imagini ȋntr-

37 https://developer.vuforia.com/resources/api/main
Figura 15: O privire de asamblu asupra structurii V uforia SDK

28
un format potrivit pentru randarea OpenGL ES. Aceas t ǎ conversie include și men ținerea
ra ției(raportul dintre lungime și l ǎțime) unei imagini pentru diferite rezolu ții. În cadrul
diagramei aceaste functionalit ǎți sunt reprezentate de activitatea „Pixel Format Co nversion”.
De și arhitectura acestui SDK mai con ține și alte componente, ele nu au fost folosite ȋn
acest proiect, motiv pentru care prezentarea lor nu este facut ǎ.

38

III.3. Detalii de implementare
În acest subcapitol, principalele obiective vor ave a drept scop în țelegerea
evenimentelor petrecute în aplica ția curent ă, familializarea cu unele concepte folosite și
oferirea unor detalii legate de implementarea acest ora.

III.3.1. Creare matricii de joc
Primul lucru care trebuie preg ǎtit odat ǎ cu pornirea unui nivel este s ǎ construim harta
de joc, atât din punct de vedere vizual cât și din punct de vedere al reprezent ǎrii acesteia ȋn
memorie. Deoarece ȋn fiecare scen ǎ nu exist ǎ decât dou ǎ obiecte ce trebuie recunoscute de
cǎtre SDK-ul Vuforia, putem memora ȋn mod direct referin țe la acele obiecte. Odat ǎ ce

38 https://developer.vuforia.com/resources/dev-guide/v uforia-ar-architecture
Figura 1 6: Diagrama de interac țiune a sdk -ului Vuforia ȋntr -o aplica ție

29
cunoa ștem obiectul pe care se va construi harta, putem ac cesa dimensiunile acestuia prin
metoda GetSize , care returneaz ǎ un vector bidimensional ȋn care g ǎsim lungimea și l ǎțimea
acestuia. Un alt lucru important care trebuie s ǎ ȋl cunoa ștem este stabilirea dimensiunii unei
piese de 1×1 din matrice ȋn raport cu dimensiunea din joc. Am creat o structu ra de tip enum
pentru o configurarea cât mai u șoar ǎ a acestui detaliu, l ǎsând posibilitate utilizatorului de a
edita aceasta ȋnainte de a porni scena de joc.
public enum MapSize
{
//1×1
verBig,
//2×2
big,
//3×3
medium,
//4×4
small,
//5×5
verySmall
}

Odat ǎ cunoscut acest lucru, stabilim punctele de start ( c ǎsu ța „S” din imagine) și sfâr șit
(c ǎsu ța „F” din imagine) pentru axele X și Y ȋn care vom preg ǎti din punct de vedere vizual
harta. Consider ǎm obiectul dreptunghiular de mai jos ca fiind una d in plan șele pe care vom
construi o hart ǎ. Ne amintim c ǎ orice obiect ȋn Unity este definit prin vectorul de pozi ție, ce
descrie coordonatele centrului s ǎu.

Figura 17: Interfa ța grafic ǎ pentru setarea dimensiunii h ǎrții
Figura 1 8: Reprezentare general ǎ a hǎrții de joc

30

Astfel g ǎsirea coordonatelor celor dou ǎ puncte se va face astfel:
startingPointX = (planeTarget.transform.position.x –
planeTarget2.GetSize().x / 2) + increaseRatio / 2;

finalPointX = (planeTarget.gameObject.transform.pos ition.x +
planeTarget.GetSize().x / 2) – increaseRatio / 2;

startingPointY = (planeTarget.gameObject.transform. position.y +
planeTarget.GetSize().y / 2) – increaseRatio / 2;

finalPointY = (planeTarget.gameObject.transform.pos ition.y –
planeTarget.GetSize().y / 2) + increaseRatio / 2;

Odat ǎ cunoscute aceste coordonate, se incepe instan țierea vizual ǎ astfel:
for(float i = startingPointX; i <= finalPointX; i + = increaseRatio)
{
for(float j = startingPointY; j >= finalPoi ntY; j -= increaseRatio)
{
GameObject c = Instantiate(square, new Vector3(i, j, 0),
Quaternion.identity) as GameObject;
}
}

Singurul lucru r ǎmas este s ǎ creem matricea de joc corespunzatoare h ǎrții create.
Întrucât scriptul Astar con ține func ționalitatea de g ǎsirea a unui drum optim pe baza unei h ǎrți
date, acesta va fi responsabil cu creearea ei și memorarea tutoror detaliilor necesare. Crearea
are loc prin urm ǎtorul apel :

Astar.instance.CreateMatrix(finalPointX, startingPo intX, startingPointY,
finalPointY, (int)increaseRatio);

În urma execu ției acestui apel se vor stabili num ǎrul de linii și coloane
corespunzatoare h ǎrții create și crearea h ǎrții propriu zise.

maxX = _maxX;
minX = _minX;

maxY = _maxY;
minY = _minY;

numberOfColumns = ((int)(Mathf.Abs(_minX) + M athf.Abs(_maxX)) /
_squareSize) + 1;
numberOfLines = ((int)(Mathf.Abs(_minY) + Mat hf.Abs(_maxY)) /
_squareSize) + 1;

matrix = new int[numberOfLines, numberOfColum ns];

31

III.3.2. Detectarea plan șei de joc
Pentru detectarea plan șei de joc dintr-un nivel, m-am folosit de metoda
OnTrackingFound din cadrul clasei CustomEventHandle r, pus ǎ la dispozi ție de c ǎtre SDK-ul
Vuforia. Acest script este ata șat obiectului ce urmeaz ǎ a fi detectat și ofer ǎ detalii despre
numele obiectului g ǎsit prin intermediul unei instan țe a clasei TrackableBehaviour, numit ǎ
mTrackableBehaviour.

Transmiterea mesajului de g ǎsire a unui obiect augmentabil se face prin mesajul

MapCreator.instance.MapFound(mTrackableBehaviour.Tr ackableName);

Odat ǎ trimis acest mesaj, se continu ǎ cu ad ǎugarea obstacolelor pentru nivelul curent
și g ǎsirea drumului optim pentru inamicii ce vor urma a fi instan ția ți. Se recomand ǎ
consultarea schemei logice prezentate la ȋnceputul acestui capitol pentru o mai bun ǎ ȋnțelegere
a ȋntregului proces de construire a unui nivel.
Figura 1 9: Functionalit ǎțile plansei de joc

32
III.3.3. Ad ǎugarea obstacolelor pentru nivelul curent
Odat ǎ cu trimiterea mesajului cum c ǎ obiectul augmentat a fost g ǎsit, se stabile ște
indexul nivelului respectiv, dup ǎ care se ȋncepe instan țierea obstacolelor pe harta propriu zis ǎ.
Se va face o parcurgere a fiec ǎrui spa țiu din hart ǎ prin intermediul a dou ǎ bucle de tip
for, cu limita de la 0 la num ǎrul maxim de linii, respectiv num ǎrul maxim de coloane. Odat ǎ
cu aceast ǎ instan țiere este important s ǎ ȋnregistr ǎm obstacolele create pe harta jocului prin
urm ǎtorul apel:

Astar.instance.RegisterObstacle(i, j);

– unde i reprezint ǎ indexul liniei curente, iar j indexul coloanei cur ente. Pentru a putea
instan ția un obiect folosim func ția Instantiate pus ǎ la dispozi ție de clasa MonoBehaviour.

Vector2 pos = GetWoorldCoordsFromMatrixCoords(new V ector2(i,j));
GameObject c = Instantiate(obstacle, new Vector3(po s.x, pos.y, 0),
Quaternion.identity) as GameObject;

Fiind nivele prestabilite de c ǎtre mine, am folosit urm ǎtoarea conven ție ȋn
interpretarea unui nivel: 0 reprezint ǎ spa țiu liber, 1 reprezint ǎ spa țiu ocupat. Astfel, când se va
face parcurgea nivelului stabilit, ȋn interiorul celor 2 bucle de parcurgere se va veri fica dac ǎ
pozi ția curent ǎ are valoarea 1 pentru a putea instan ția obstacolul; dac ǎ valoarea este 0, spa țiul
respectiv este liber și nu este necesar s ǎ lu ǎm vreo decizie. Odat ǎ prezentate aceste detalii,
urmeaz ǎ prezentarea efectiv ǎ a func ției.

private void AddObstaclesForGivenLevel(int givenLev el)
{

for(int i=0;i<Astar.instance.numberOfLines; i++)
{
for(int j=0;j<Astar.instance.numberOfCo lumns;j++)
{
if(Levels.levels[givenLevel][i,j] = = 1)
{
//logica de instantiere prezent ata mai sus
}
}
}
}

III.3.4. Gǎsirea drumului optim utilizând algoritmul A*
A* este cea mai popular ǎ alegere când vine vorba de g ǎsirea unui drum ȋntre dou ǎ
puncte date, deoarece este destul de flexibil și poate fi folosit ȋn o gam ǎ larg ǎ de contexte,
motiv pentru care a fost și folosit ȋn acest proiect.

33
A* are la baz ǎ algoritmul lui Dijkstra deoarece poate fi folosit s ǎ g ǎseasc ǎ drumul cel
mai scurt, dar are elemente și din algoritmul Greedy deoarece se bazeaz ǎ pe o func ție de cost
minim pentru a se ghida ȋn gǎsirea drumului, numit ǎ și func ție euristic ǎ. Succesul acestui
algoritm const ǎ ȋn combinarea acestor dou ǎ informa ții din algoritmul lui Dijkstra ( care
favorizeaza nodurile mai apropiate de nodul de star t) și cel al algoritmului Greedy ( care
favorizeaza nodurile mai apropiate de nodul final). În terminologia standard, când vorbim
despre acest algoritm, g(n) reprezint ǎ func ția care calculeaz ǎ costul exact de la nodul de start
cǎtre orice nod, iar h(n) reprezint ǎ func ția euristic ǎ care estimeaz ǎ costul de la un nod n la
nodul final. Logica din spatele acestui algoritm es te de a balansa cele doua func ții pe m ǎsur ǎ
ce traverseaz ǎ c ǎtre nodul final. Astfel, la fiecare itera ție, acesta va alege acea solu ție care are
cea mai mic ǎ valoare asociat ǎ func ției f(n) = g(n) + h(n) .
Pe o hart ǎ reprezentat ǎ sub form ǎ de matrice exist ǎ numeroase func ții euristice pentru
mi șcare, ȋns ǎ voi men ționa doar dou ǎ dintre acestea, una din ele fiind folosit ǎ ȋn cadrul acestui
proiect.
Prima este distan ța Manhattan, care permite mi șcarea pe patru direc ții ȋn cadrul unei
hǎrți reprezentat ǎ ca o matrice: nord, sud, est, vest. Aceasta reprez int ǎ cea mai des folosit ǎ
metod ǎ, fiind u șor de calculat cu ajutorul urm ǎtoarei func ții:

function heuristic(node,goal)
{
dx = abs(node.x – goal.x);
dy = abs(node.y – goal.y);
return D * (dx + dy);
}
Un lucru important ce trebuie luat ȋn cosiderare este atribuirea unei valori pentru
variabila D. Pentru calculul celui mai scurt drum și p ǎstrarea unei func ții euristice
„admisibil ǎ”, se recomand ǎ atribuirea unei valori cât mai mici pentru aceasta . De altfel, exist ǎ
diferite propuneri legate de aceast ǎ variabil ǎ care iau ȋn considerare mai multe aspecte precum
prezen ța mai multor tipuri de teren care implic ǎ costuri diferite de traversare și num ǎrul de
obstacole prezent ȋn scen ǎ, ȋns ǎ de cele mai multe ori, variabila D este setat ǎ cu valoarea 1,
acesta reprezentând cel mai simplu caz, lucru de al tfel folosit și ȋn acest proiect.
Când se dore ște traversarea h ǎrții pe opt direc ții de mers, folosim func ția euristic ǎ de
calcul pe diagonal ǎ. Aceasta presupune cele patru tipuri de mi șcare amintite mai sus ȋmpreuna
cu alte patru, și anume: nord-est, nord-vest, sud-est, sud-vest. Fu nc ția care calculeaz ǎ distan ța
ȋntre dou ǎ noduri date cu acest tip de mi șcare este urm ǎtoarea:

34

function heuristic(node)
{
dx = abs(node.x – goal.x);
dy = abs(node.y – goal.y);
return D * (dx + dy) + (D2 – 2 * D) * min(dx, d y);
}

Variabila D a fost discutat ǎ mai sus, ȋns ǎ observ ǎm o nou ǎ variabil ǎ și anume D2.
Asignarea acesteia depinde ȋn mod implicit de variabila D, ob ținându-se prin formula D2 =
sqrt(2) * D.
Odat ǎ prezentate aceste detalii, putem trece la prezenta rea algoritmului propriu zis.
Exist ǎ dou ǎ mul țimi de date, OPEN și CLOSED. În prima mul țime vom ad ǎuga nodurile
posibile candidate. Ini țial, ȋn aceast ǎ mul țime avem un singur nod candidat și anume nodul de
start. Mul țimea CLOSED con ține nodurile care au fost deja examinate. Ini țial, aceasta este
mul țimea vid ǎ. Dac ǎ ar fi s ǎ ne imagin ǎm din punct de vedere grafic cum ar ar ǎta aceste dou ǎ
mul țimi, am putea spune c ǎ prima reprezint ǎ „frontiera”, iar a doua reprezint ǎ „interiorul”
zonelor vizitate. Deasemeanea fiecare nod va avea o referin țǎ cǎtre p ǎrintele sau mai bine zis
cǎtre nodul prin care sa ajuns la acesta pentru a put ea determina drumul parcurgând ȋn mod
recursiv p ǎrin ții fiec ǎrui nod odat ǎ ce am g ǎsit nodul final.
Algoritmul presupune existen ța unei bucle while care scoate ȋn mod repetat cel mai
bun nod din mul țimea OPEN (nodul care are cea mai mic ǎ valoare a func ției f asociat ǎ lui).
Dac ǎ acel nod n este nodul final, algoritmul se opre ște. Altfel, nodul g ǎsit este ster ș din
mul țimea OPEN și ad ǎugat ȋn CLOSED. Pe urm ǎ sunt examina ți vecinii acestuia. Dac ǎ unul
dintre vecini se afl ǎ ȋn mul țimea CLOSED, acesta nu va mai fi verificat. Deaseme nea dac ǎ
unul dintre vecini se afl ǎ deja ȋn mul țimea OPEN, acesta nu va mai fi adaugat din nou, evi tând
astfel o verificare dubl ǎ. Dac ǎ niciuna din aceste condi ții nu este ȋndeplinit ǎ, nodul vecin se va
ad ǎuga ȋn mul țimea OPEN, se va seta p ǎrintele lui cu nodul n și ȋi vom asigna costul ca fiind
egal cu g(n) + h(n,n') , unde n' reprezint ǎ nodul extras.

35

OPEN = priority queue containing START
CLOSED = empty set
while lowest rank in OPEN is not the GOAL:
current = remove lowest rank item from OPEN
add current to CLOSED
for neighbors of current:
cost = g(current) + movementcost(current, neigh bor)
if neighbor in OPEN and cost less than g(neighb or):
remove neighbor from OPEN, because new path i s better
if neighbor in CLOSED and cost less than g(neig hbor): **
remove neighbor from CLOSED
if neighbor not in OPEN and neighbor not in CLO SED:
set g(neighbor) to cost
add neighbor to OPEN
set priority queue rank to g(neighbor) + h(ne ighbor)
set neighbor's parent to current

reconstruct reverse path from goal to start
by following parent pointers

În acest proiect, mul țimile OPEN și CLOSED au fost reprezentate ca ni ște simple liste
generice ce con țin elemente de tip AstarNode, o structur ǎ de date creat ǎ de mine cu
urmatoarea form ǎ:

public int x;
public int y;
public AstarNode parrent;
public double g;
public double rank;
unde „x” si „y” reprezinta coordonate ȋn matrice a nodului, „rank” reprezint ǎ func ția f(n) =
g(n) + h(n) , restul fiind u șor de dedus din nume.

III.3.5. Pornirea jocului și detalii despre mecanica de joc
Odat ǎ ce primele șase activit ǎți prezentate ȋn diagrama de la ȋnceputul acestui capitol
s-au ȋncheiat cu succes, ȋn col țul din stânga-sus a ecranului va aparea un buton nu mit Start ce
are rolul de a porni scena de joc. Întrucât ultimel e activit ǎți prezentate presupun pornirea și
finalizarea jocului, lucru cunoscut doar prin inter mediul clasei EnemyController, aceasta va
avea rolul de a transmite mesaje clasei UIManager d e a reactualiza interfa ța ȋn func ție de
starea jocului. Odat ǎ pornit jocul, aceast ǎ clas ǎ se va ocupa de instan țierea și gestionarea
inamicilor. Odat ǎ creat un inamic, acesta va primi un mesaj de confi rmare de la aceast ǎ clas ǎ
prin care ȋș i va seta referin țele necesare, dup ǎ care se va ȋnregistra ȋntr-o list ǎ de obiecte
active, aflat ǎ ȋn clasa amintit ǎ și ȋș i va porni activitatea. Fiecare inamic con ține dou ǎ
componente de baza, UnitMovement și EnemyStats.

36

Rolul primei componente este de a face o cerere c ǎtre scriptul Astar prin care se cere
drumul optim de la punctul de start c ǎtre cel de sfâr șit, reprezentat printr-o list ǎ de noduri de
tip Vector2. Odat ǎ ob ținut ǎ aceast ǎ lista, obiectul respectiv se va ȋndrepta de la pozi ția sa
ini țial ǎ c ǎtre urm ǎtorul punct din list ǎ. Pentru mi șcarea obiectului am folosit o func ție pus ǎ la
dispozi ție de c ǎtre clasa MonoBehaviour, și anume Vector3.MoveTowards(). Semn ǎtura
acestei func ții este urm ǎtoarea:

public static Vector3 MoveTowards(Vector3 current, Vector3 target, float
maxDistanceDelta);

Primul parametru reprezint ǎ pozi ția curent ǎ de la care vrem s ǎ pornim, al doilea
reprezint ǎ pozi ția final ǎ la care vrem s ǎ ajungem, iar cel de al treilea parametru reprezint ǎ
unitatea de m ǎsur ǎ cu care obiectul se va deplasa la fiecare cadru tr ecut, sau pentru o mai
ușoar ǎ ȋnțelegere putem considera acesta ca fiind viteza de d eplasare. Pentru a putea mi șca un
obiect prin intermediul acestei func ții, trebuie s ǎ o folosim ȋn interiorul func ției de Update
(func ția care este apelat ǎ la ȋnceputul fiec ǎrui nou cadru din joc).
A doua component ǎ, EnemyStats, memoreaz ǎ detalii despre via ța acestui obiect. Când
un inamic este atacat acesta va pierde din punctele sale de via țǎ , iar odat ǎ ce acestea ajung sub
valoarea zero, el se va autodistruge și va ȋnștin ța scriptul responsabil cu gestionarea
inamicilor.
Odat ǎ ce un inamic și-a pornit activitatea, singura interac țiune pe care acesta o va avea
va fi cu componentele de tip turn și proiectil reprezentate prin clasele TowerLogic și
BulletLogic. La nivelul acestor clase ȋntâlnim func ționalit ǎți legate de interac țiunea fizic ǎ
ȋntre obiecte prin func țiile OnTriggerEnter și OnTriggerExit.
O alt ǎ activitate ce are loc dup ǎ pornirea jocului este plasarea turnurilor ȋntr-unul din
spa țiile libere ale h ǎrții. Pentru acest lucru folosim o alt ǎ func ție pus ǎ la dispozi ție de clasa
MonoBehavior, și anume func ția OnClick(). Aceasta este apelat ǎ de fiecare dat ǎ când ap ǎsǎm
butonul click de la mouse și cursorul se afl ǎ peste un obiect ce con ține o component ǎ de
coliziune, ȋn cazul nostru un BoxCollider. Astfel am construit un script separat numit
Figura 20 : Func ționalit ǎțile de baz ǎ ale unui inamic

37
AvailableSpot pe care l-am ata șat fiec ǎrui spa țiu al h ǎrții de joc. Odat ǎ ce obstacolele sunt
ad ǎugate și drumul inamicilor este aflat, se va dezactiva com ponenta de coliziune de pe acesta
pentru a nu mai putea interac ționa cu utilizatorul, ȋntrucat se consider ǎ cǎ acele spa ții sunt
ocupate. Observ ǎm ȋn figura de mai jos cum spa țiile marcate cu verde sunt cele disponibile
pentru construire, iar prin selectarea unui spa țiu ocupat ȋntâlnim componenta de coliziune
inactiv ǎ.

Odat ǎ ce unul din spa țiile disponibile pentru construire a unui turn a fo st selectat, se va
transmite un mesaj c ǎtre scriptul MapManager care ofer ǎ printr-un buton numit „Place on
selected spot” op țiunea de a construi un turn ȋn acel loc.

Capitolul IV: Scenarii de utilizare
IV.1. Descrierea portalului Vuforia
Asa cum a mai fost men ționat, Vuforia reprezinta kit-ul de dezvoltare soft ware
responsabil cu partea de realitate augmentat ǎ a aplica ției. În continuarea acestui subcapitol,
vom prezenta principalele caracteristici ale portal ului Vuforia, scopul fiind familiarizarea
cititorului cu modul ȋn care acesta lucreaz ǎ. Adresa la care putem g ǎsi acest portal este:
https://developer.vuforia.com
Înregistrarea unui utilizator nou presupune complet area unui formular obi șnuit de
ȋnregistrare, motiv pentru care vom s ǎri peste acest pas și vom trece direct la prezentarea
func ționalit ǎților. Pentru a putea ȋnc ǎrca o imagine ce urmeaz ǎ a fi augmentat ǎ, trebuie s ǎ
mergem la sec țiunea „Target Manager”, iar odat ǎ ajun și acolo se va crea o baz ǎ nou ǎ de date
Figura 21: Obiectul de spa țiu a hǎrții

38
de tip „Device Database”. Odat ǎ creat ǎ aceast ǎ baz ǎ de date, putem s ǎ ȋnc ǎrc ǎm pân ǎ la 100
de imagini pentru augmentarea lor ȋn aplica țiile dorite. Prin intermediul butonului „Add
Target”, va ap ǎrea o fereastr ǎ cu diferite op țiuni necesare ȋnc ǎrc ǎrii unei imagini.

Se va completa câmpul „Target Name” cu numele pe ca re imaginea ȋnc ǎrcat ǎ ȋl va avea, se
selecteaz ǎ tipul „Single Image”, pentru l ǎțimea imaginii se completeaz ǎ de obicei cu 512,
aceasta putând fi modificat ǎ ulterior ȋn cadrul proiectului, dup ǎ care se selecteaz ǎ imaginea
dorit ǎ și se finalizeaz ǎ procesul. În acest moment imaginea poate fi gasit ǎ ȋn baza de date,
având ȋn dreptul ei o „nota” care reprezint ǎ cât de u șor va putea fi recunoscut ǎ ȋn aplica ție
aceasta. Dac ǎ select ǎm o imagine și accesam op țiunea „Show features” putem observa
reperele dup ǎ care algoritmul celor de la Vuforia recunoa ște o imagine. Pentru o recunoa ștere
cât mai u șoar ǎ, recomandarea lor este de a ad ǎuga imagini cu un num ǎr de detalii vizuale cât
mai numeroase.
Odat ǎ ȋnc ǎrcate una sau mai multe imagini ȋn baza de date, observ ǎm un checkbox ȋn
dreptul fiecarei imagini. Select ǎm acele imagini care dorim s ǎ le intregr ǎm ȋn proiect, dup ǎ
care acces ǎm butonul „Download Selected Targets” și select ǎm op țiunea „Unity Editor”
pentru a ob ține un pachet cu toate datele necesare ad ǎug ǎrii imaginilor ȋntr-un proiect de
Unity.

IV.2. Selectarea unei scene de joc: pa și preg ǎtitori
Aplica ția curent ǎ const ǎ din patru scene de joc, dintre care una este folos it ǎ pentru
reprezentarea meniului principal. Pentru gestiunea acestor scene, clasa MonoBehaviour pune
Figura 22 : Interfa ța pentru ad ǎugarea unei imagini ȋn baza de date

39
la dispozi ție un set de func ții și propriet ǎți. În figura 18 se observ ă atribuirea scenelor la
executabilul (build-ul) aplica ției, platforma pentru care se realizeaz ă build-ul și ordinea de
indexare a acestora. Indexarea scenelor vine în aju torul programatorului în cazul în care
acesta dore ște s ă lanseze o scen ă din alt ă scen ă indiferent care este aceasta. Se u șureaz ă
volumul de munc ă pentru efectuarea unei astfel de opera ții și se faciliteaz ă accesul la acestea
prin intermediul mai multor metode.
Exemple de aceste metode sunt urmatoarele:
public static void LoadLevel (int index); – incarca un nivel pe baza indexului
sau
public static void LoadLevel (string name); – incarca un nivel pe baza numelui
sau
public static AsyncOperation LoadLevelAdditiveAsync (int index);
public static AsyncOperation LoadLevelAdditiveAsync (string levelName);

sau proprietăți:

public static int loadedLevel ; – intoarce indexul scenei incarcate
public static string loadedLevelName ; – intoarce numele scenei incarcate
Application.LoadedLevel – întoarce indexul scenei î nc ărcate.

Figura 23 : Înc ǎrcarea și afi șarea nivelelor aplica ției

40
Înainte de a porni un nivel, mai avem de configurat o op țiune pentru fiecare scen ǎ, și
anume num ǎrul de inamici care trebuie s ǎ apar ǎ. Se observ ǎ posibilitatea de editare a dou ǎ
câmpuri ȋn cadrul scriptului EnemyController ce descriu num ǎrul de grupuri de mon ștrii
lansat la un anumit moment (waves) și num ǎrul de inamici per grup(mobs per wave).

Odat ǎ ce op țiunile pentru fiecare nivel au fost setate, se poat e porni aplica ția. Dup ǎ
cum observ ǎm ȋn figura nr 18, prima scen ǎ ȋnc ǎrcat ǎ este cea de meniu. Prin intermediul
acestei scene putem alege una din scenele configura te prin apasarea butonului cu numele
scenei dorite. Odat ǎ ce un nivel a fost finalizat, se va reveni la acea st ǎ scen ǎ prin apasarea
tastei Escape sau a butonului de revenire la meniul principal care va aparea la finalizarea
nivelului current. Acest lucru este realizat prin u rm ǎtoarea secven țǎ de cod:

if(levelFinished)
{
if(Input.GetKeyDown(KeyCode.Escape))
{
Application.LoadLevel("Main Menu");
}
}

IV.3. Descrierea unui nivel și pa șii necesari finaliz ǎrii acestuia
În acest subcapitol vom prezenta unul din nivelele construite ȋmpreun ǎ cu pa șii
necesari termin ǎrii acestuia.
Figura 24 : Intefa ța pentru configurarea num ǎrului de inamici

41

Col țul din stânga-sus și cel din dreapta jos reprezint ǎ punctele de start, respectiv
finalizare a nivelului. Prin ap ǎsarea butonului de Start se va porni instan țierea inamicilor, care
vor avea principalul scop de a ajunge la punctul fi nal. Prin activarea butonului „Pause & Place
a tower”, jocul va intra intr-o stare de pauz ǎ ȋn care utilizatorul va putea selecta din locurile
disponibile, reprezentate prin culoarea verde, unde sǎ plaseze turnurile pentru a distruge
inamicii. Odat ǎ selectat un loc liber, va aparea un buton de confi rmare a locului selectat
pentru construirea turnului dup ǎ care se va reveni la starea anterioar ǎ ȋn care se poate adauga
un nou turn sau re ȋntoarcerea ȋn joc.
Figura 25: Prezentarea unei h ǎrți de joc complete

42

Odat ǎ ce to ți inamicii au fost elimina ți, se va afi șa un mesaj de confirmare dup ǎ care
se poate reveni la meniul principal al jocului prin apasarea tastei „Escape”.

Figura 26 : Afi șarea spa țiilor libere și a unui turn de atac
Fi gura 2 7: Finalizarea unui nivel

43
Concluzii
Așa cum am men ționat ȋn introducere, scopul acestui proiect a fost de a c reea un joc
care s ǎ includ ǎ și elemente de tip Augmented Reality. Cu ajutorul el ementele principale ale
programului Unity, cele ale sdk-ului Vuforia și ale algoritmilor elabora ți am reu șit sǎ dezvolt
o aplica ție care ofer ǎ posibilitatea de a transforma o partea din lumea r eal ǎ ȋn spa țiu de joc.
Astfel interesul utilizatorilor poate cre ște, deoarece interac țiunea cu tabla de joc real ǎ
reprezint ǎ un grad de noutate destinat atragerii juc ǎtorilor.
Aceast ǎ aplica ție poate fi extins ǎ spre alte platforme, dar se pot adaug ǎ și elemente
noi, precum conectarea mai multor participan ți ȋntr-o sesiune de joc, crearea unor noi
mecanici de joc precum modernizarea turnurilor, cre area mai multor tipuri de teren, fiecare cu
un cost diferit pentru a fi parcurs, ad ǎugarea unor noi modele pentru reprezentarea obiecte lor
ȋn scen ǎ și chiar posibilitatea de a adauga plan șe proprii cu o interfa țǎ ușor de folosit pentru
editarea obstacolelor.

44
Bibliografie
1. „Inteligen ță Artificial ă” – Dan Cristea, M ădălina Ioni ță , Ionu ț Cristian Pistol (2007)
2. „Artificial Intelligence – A Modern Approach” – Stu art J. Russell and Peter Norvig
3. INTRODUCTION TO ALGORITHMS, THIRD EDITION – THOMAS H.
CORMEN, CHARLES E. LEISERSON, RONALD L. RIVEST, CLI FFORD STEIN
4. http://developer.vuforia.com/library/tutorials
5. https://unity3d.com/learn/tutorials/topics/2d-game- creation
6. https://unity3d.com/learn/tutorials/topics/user-int erface-ui
7. http://docs.unity3d.com/ScriptReference/Vector3.htm l
8. https://unity3d.com/learn/tutorials/modules/interme diate/scripting/coroutines?playlist=
17117
9. http://www.redblobgames.com/pathfinding/a-star/intr oduction.html