CAPITOLUL 1. PREZENTARE GENERAL Ă 3 1.1. Jocuri platformer populare 4 1.1.1. Super Mario Bros. 5 1.1.2. BattleBlock Theater 5 1.1.3. Super Meat Boy [621833]

INTRODUCERE
2

CAPITOLUL 1. PREZENTARE GENERAL
Ă
3

1.1. Jocuri platformer populare
4

1.1.1. Super Mario Bros.
5

1.1.2. BattleBlock Theater
5

1.1.3. Super Meat Boy
6

1.2. Jocuri puzzle-platformer
7

1.2.1. Limbo
7

1.2.2. LittleBigPlanet
8

1.3. Motiva
ț
ia temei
9

CAPITOLUL 2. CERIN
Ț
E
Ș
I SPECIFICA
Ț
II
10

CAPITOLUL 3. ANALIZA PROBLEMEI
11

3.1. Jocul
11

3.2. Personajul
11

3.3. Inamicii
11

3.4. Obiectele de adunat
11

3.5. Obstacolele
11

3.6. Mecanismele
12

3.7. Tutoriale
12

CAPITOLUL 4. TEHNOLOGII FOLOSITE
13

4.1. Motorul grafic de dezvoltare „Unity”
13

4.1.1. Crearea unui proiect
13

4.1.2. Concepte
ș
i modul de realizare al unui joc
14

4.1.2.1. Ferestrele principale
15

4.1.2.2. Set
ă
rile camerei
15

4.1.2.3. Anima
ț
iile
16

4.1.2.4. Prefabricate
17

4.1.2.5. Materiale
17

4.1.2.6. Sprite-urile
18

4.1.2.7. Scripturile
18

4.1.2.8. PlayerPrefs
18

4.2. Mediul de dezvoltare Microsoft Visual Studio
18

4.3. Editorul de grafic
ă
vectorial
ă
Inkscape
19

CAPITOLUL 5. PROIECTAREA INTERFE
Ț
EI
20

5.1. Meniul jocului
20

5.2. Meniul în timpul pauzei
21

5.3. Elementele statice
21

5.4. Pozi
ț
ionarea per sonajului pe ecran
22

5.5. Meniul de final de joc
23

5.7. Ecranul dintre nivele
24

CAPITOLUL 6. IMPLEMENTAREA APLICA
Ț
IEI
25

6.1. Nivelele
25

6.2. Personajul
27

6.2.1. RigidBody 2D
27

6.2.2. Sprite Renderer
27

6.2.3. Polygon Collider 2D
27

6.2.4. Animator
28

6.2.5. Scriptul de control al personajului
28

6.3. Inamicii
28

6.3.1.
Ț
epii
29

6.3.2. Vârtejurile deasupra abisurilor
29

6.3.3. Pe
ș
tii balon
30

6.4. Punctele de control
31

6.5. Tutorialele
32

6.6. Cristalele
33

6.7. Poarta
33

6.8. Monedele
34

6.9. Sursele de oxigen
34

6.10. Obstacolele
35

6.11. Mecanismele
35

6.12. Texturile
36

6.13. Meniurile
36

6.14. Crearea unui program executabil
36

CAPITOLUL 7. TESTAREA APLICA
Ț
IEI
38

1

INTRODUCERE

Primul
joc
video
a
ap
ă
rut
la
începutul
anului
1947,
îns
ă
în
acea
perioad
ă
acestea
nu

aveau
aspect
comercial.
Odat
ă
cu
dezvoltarea
tehnicilor
de
calcul,
progresul
tehnologiei
ș
i

facilitarea
accesului
la
aceasta,
în
jurul
anilor
1970
a
fost
lansat
ă
o
serie
de
jocuri,

apar
ț
inând
unor
compa nii
diferite,
care
a
pus
bazele
pentru
ceea
ce
avea
s
ă
devin
ă
mai

târziu
industria
de
jocuri
video.
În
prezent,
aceasta
are
ca
obiectiv
dezvoltarea
ș
i

comercializarea
jocurilor
atât
în
form
ă
fizic
ă
,
adic
ă
CD-uri
sau
DVD-uri,
cât
ș
i
în
form
ă

electronic
ă
,
dar
ș
i
generarea
de
capital
prin
intermediul
acestora,
ulterior
vânz
ă
rii
lor

efective.

În
momentul
actual,
jocurile
video
pot
fi
accesate
cu
ajutorul
unei
variet
ă ț
i
de

dispozitive,
cele
mai
populare
fiind
telefoanele
mobile
datorit
ă
portabilit
ă ț
ii
ș
i
confortului

pe
care
acestea
le
ofer
ă
,
urmate
de
consolele
dedicate
ș
i
de
computerele
personale.
În
ceea

ce
le
prive
ș
te
pe
acestea
din
urm
ă
,
se
diferen
ț
iaz
ă
de
primele
clasate
prin
caracteristici
greu

de
egalat,
dintre
care
cea
mai
important
ă
este
fidelitatea
fa
ț ă
de
lumea
real
ă
pe
care
jocurile

video
destinate
acestei
platforme
o
ob
ț
in
prin
elemente
grafice
complexe.
Resursele
de

procesare
puse
la
dispozi
ț
ia
computerelor
sunt
mai
numeroase,
iar
componentele

hardware
de
calitate
superioar
ă
favorizeaz
ă
aceast
ă
caracteristic
ă
principal
ă
,
motiv
pentru

care
jocurile
dedicate
acestei
platforme
sus
ț
in
mai
mul
ț
i
juc
ă
tori,
simuleaz
ă
realitatea
mai

bine
ș
i beneficiaz
ă
de rezolu
ț
ii înalte
ș
i de un num
ă
r mai mare de cadre pe secund
ă
.

Un
alt
avantaj
al
jocurilor
pe
computer
îl
constituie
lipsa
unei
administr
ă
ri

centralizate
ceea
ce
conduce
la
costuri
reduse
ale
acestora,
sau
chiar
distribuirea
lor

gratuit
ă
ș
i
flexibilitate
între
sisteme,
un
joc
vechi
fiind
cu
u
ș
urin
ț ă
rulat
pe
un
calculator

nou,
cu
ajutorul
unor
emulatoare
software,
dac
ă
este
cazul
ș
i
viceversa,
un
joc
modern
este

compatibil cu un sistem dep
ă ș
it prin reducerea calit
ă ț
ii
ș
i fidelit
ă ț
ii fa
ț ă
de realitate.

Complexitatea
crescut
ă
pe
care
o
aduce
crearea
unui
joc
pentru
computer
se

reg
ă
se
ș
te
printre
dezavantajele
acestei
platforme.
Acest
inconvenient
este
cauzat
de

necesitatea
configur
ă
rii
corecte
ș
i
asigurarea
compatibilit
ă ț
ii
pe
un
num
ă
r
cât
mai
mare
de

sisteme
ceea
ce
duce
la
o
cre
ș
tere
a
resurselor
ce
trebuie
alocate
pentru
dezvoltare,
testare

ș
i
suport.
De
asemene a,
tot
în
aceast
ă
categorie
se
reg
ă
sesc
securitatea
redus
ă
,
care

favorizeaz
ă
apari
ț
ia
pirateriei
ș
i
a
tri
ș
orilor,
dar
ș
i
costul
crescut
al
componentelor

hardware pentru utilizator.

Aplica
ț
ia
se
încadreaz
ă
în
categoria
jocurilor
puzzle-platformer
2D
ș
i
ofer
ă

posibilitatea
de
a
controla
un
personaj
într-o
manier
ă
flexibil
ă
,
ale
c
ă
rui
mi
ș
c
ă
ri
le
reproduc

pe
cele
ale
unui
scafandru
aflat
în
explorare,
iar
cadrul
în
care
se
deplaseaz
ă
acesta

introduce componente fantastice armonios îmbinate cu realitatea.

Alegerea
acestei
teme
de
proiect
este
bazat
ă
pe
inexisten
ț
a
unui
joc
de
acest
gen

care
asociaz
ă
elemente le
de
puzzle
cu
cele
de
ac
ț
iune
într-un
mediu
subacvatic
pentru
a

crea
o
aplica
ț
ie
distracti v
ă
ș
i
cu
scop
recrea
ț
ional.
În
plus,
în
func
ț
ie
de
abilitatea
ș
i
agilitatea

utilizatorului
în
rezolvarea
nivelelor,
la
finalul
jocului
acesta
prime
ș
te
evaluarea
sa
sub

2

form
ă
de
punctaj,
ceea
ce
adaug
ă
o
not
ă
de
competitivitate
între
juc
ă
tori
ș
i
posibilitatea

vizualiz
ă
rii progresului între sesiunile de joc.

Fa
ț ă
de
aplica
ț
iile
asem
ă
n
ă
toare
existente
în
prezent,
aceasta
se
adreseaz
ă
unei

categorii
largi
de
juc
ă
tori
de
toate
vârstele
care
doresc
s
ă
se
destind
ă
activ,
se
bazeaz
ă
atât

pe
intui
ț
ie,
cât
ș
i
pe
logic
ă
pentru
solu
ț
ionarea
puzzle-urilor,
iar
aparenta
simplitate
confer
ă

utilizatorilor sentimentul de relaxare.

3

CAPITOLUL 1. PREZENTARE GENERAL
Ă

Jocurile
video
reprezint
ă
una
dintre
principalele
activit
ă ț
i
recrea
ț
ionale
ș
i
modalit
ă ț
i

de
petrecere
a
timpului
liber
în
rândul
tinerilor,
dar
ș
i
al
adul
ț
ilor,
datorit
ă
posibilit
ă ț
ii
de
a

le utiliza din confortul propriei locuin
ț
e.

Se
diferen
ț
iaz
ă
dou
ă
categorii
importante
ș
i
anume
cea
a
jocurilor
3D
ș
i
cea
a

jocurilor
2D,
fiecare
dintre
acestea
împ
ă
r
ț
indu-se
pe
subcateg orii
cunoscute
sub
denumirea

de genuri.

În
ceea
ce
prive
ș
te
cea
de-a
doua
categorie,
resursele
necesare
atât
dezvolt
ă
rii
cât
ș
i

utiliz
ă
rii
unei
astfel
de
aplica
ț
ii
sunt
cu
mult
reduse,
putând
realiza
un
joc
f
ă
r
ă
prea
multe

obstacole
din
punct
de
vedere
al
echipamentelor
hardware,
folosind
cuno
ș
tin
ț
e
ș
i
abilit
ă ț
i
la

nivel
mediu,
ob
ț
inând
performan
ț
e
ridicate,
f
ă
r
ă
a
fi
nevoie
de
optimiz
ă
ri
ulterioare.
Cu

toate
c
ă
jocurile
3D
aduc
un
plus
prin
grafica
complex
ă
,
cele
2D
sunt
clasice,
primele
jocuri

ap
ă
rute fiind de acest tip , ofer
ă
simplitate
ș
i sunt foarte intuitive.

Categoria
din
care
face
parte
aplica
ț
ia
este
cea
2D,
genul
puzzle-platformer.
În

general,
acest
tip
de
joc
permite
utilizatorului
s
ă
controleze
un
personaj
cu
scopul
de
a
evita

obstacole
ș
i
de
a
aduna
diverse
obiecte.
Mediul
înconjur
ă
tor
este
alc
ă
tuit
din
teren

accidentat
pentru
a
favoriza
ac
ț
iunile
de
tip
s
ă
ritur
ă
care
sunt
caracteristice
acestui
gen,

îns
ă
în
prezent
ele
pot
fi
reprezentate
ș
i
de
alte
manevre
acrobatice
precum
leg
ă
natul
sau

ag
ă ț
atul.
La
un
moment
dat,
jocurile
de
tip
platformer
de
ț
ineau
suprema
ț
ia
în
ceea
ce

prive
ș
te
popularitatea
ș
i
de
asemenea
s-a
estimat
c
ă
în
acea
perioad
ă
ele
reprezentau
între

un sfert
ș
i o treime din t otalul jocurilor existente.

De
ș
i
încadrarea
în
acest
gen
era
discutabil
ă
,
primele
jocuri
care
au
adoptat
stilul

platformer
prezentau
un
ecran
static,
iar
utilizatorului
îi
era
oferit
ă
doar
posibilitatea
de
a

c
ă
dea,
f
ă
r
ă
abilitatea
de
a
s
ă
ri,
motiv
pentru
care
aceasta
era
înlocuit
ă
cu
obiecte
de
tip

scar
ă
pe
care
le
putea
folosi
pentru
a
evita
obstacolele.
Mai
târziu,
jocurile
au
început
s
ă

adopte
ecranul
în
stilul
„scrolling”,
adic
ă
mediul
înconjur
ă
tor
pare
c
ă
se
mi
ș
c
ă
în
acela
ș
i

timp
cu
personajul
ș
i
s-au
ad
ă
ugat
ac
ț
iuni
noi
acestuia
precum
lupta
cu
inamici.
În
prezent,

cu
toate
c
ă
nu
este
atât
de
vizibil,
stilul
a
fost
introdus
chiar
ș
i
în
categoria
3D,
platformele

fiind înlocuite de cl
ă
diri sau poduri.

1.1. Jocuri platformer populare

Fie
c
ă
vorbim
despre
perioada
jocurilor
8-bit
sau
16-bit,
sau
de
jocurile

contemporane,
acestea
atrag
prin
simplitate,
amuzament,
unele
prin
stilul
colorat,
altele

prin
povestea
fantastic
ă
sau
grafica
de
calitate.
În
continuare
vor
fi
prezentate
câteva

exemple de astfel de aplica
ț
ii.

4

1.1.1. Super Mario Bros.

Probabil
cel
mai
popular
joc
video
din
toate
timpurile,
„Super
Mario
Bros.”
s-a

vândut
în
peste
40
de
milioane
de
copii,
devenind
cel
mai
bine
vândut
joc
vreodat
ă
.
Creat

de
compania
„Nintendo”,
ca
succesor
al
„Mario
Bros.”
care
a
fost
un
real
succes
ca
joc

arcade,
aduce
ca
noutate
modul
multiplayer,
iar
nivelele
de
început
sunt
construite
astfel

încât s
ă
prezinte mecan icile de baz
ă
ale jocului într-un mod si mplu
ș
i extrem de intuitiv.

Scopul
final
este
acela
de
a
o
salva
pe
prin
ț
esa
Regatului
Ciupercilor
ț
inut
ă
captiv
ă

deoarece
este
singura
care
poate
rupe
vraja
pus
ă
asupra
ț
inutului,
vraj
ă
care
i-a

transformat
pe
locuitori
în
obiecte
statice.
Aceast
ă
misiune
poate
fi
îndeplinit
ă
doar
dup
ă

învingerea
personajului
negativ,
un
dragon
care
a
condus
invazia
asupra
regatului
ș
i
a

r
ă
pit-o pe prin
ț
es
ă
.

În
fiecare
nivel,
Mario,
sau
dup
ă
caz
ș
i
fratele
s
ă
u,
Luigi,
controlat
de
juc
ă
torul
al

doilea
în
modul
multiplayer,
trebuie
s
ă
evite
obstacole,
s
ă
omoare
inamicii,
s
ă
adune

obiecte
care
confer
ă
puteri
diferite,
dar
ș
i
monede
într-un
interval
de
timp
vizibil
pe
ecran.

Jocul
este
format
în
total
din
32
de
scenarii
de
parcurs,
mai
exact
din
opt
nivele
numite

„lumi”, fiecare având patru sub-nivele numite „stagii”.

P
ă
strându-
ș
i
suprema
ț
ia
de-a
lungul
timpului,
jocul
a
fost
prelucrat
ș
i
relansat
pe

aproape fiecare platform
ă
apar
ț
inând companiei „Nintendo”.

1.1.2. BattleBlock Theater

Dezvoltat
de
compania
„The
Behemoth”
ș
i
publicat
de
„Microsoft
Studios”
în
anul

2013,
jocul
se
încadreaz
ă
în
categoria
comic-platformer
2D
ș
i
este
disponibil
pe
toate

sistemele de operare pentru computer, dar
ș
i pe consola „Xbox 360”.

5

Ca
în
orice
alt
platformer,
ac
ț
iunile
pe
care
le
pot
executa
personajele
sunt
s
ă
riturile,

dar
la
acestea
se
adaug
ă
alergatul
ș
i
lovitul
cu
pumnii.
Acest
joc
permite
de
asemenea
ca
doi

juc
ă
tori
s
ă
coopereze
pentru
completarea
nivelelor.
Personaj ele
sunt
ni
ș
te
prizonieri
for
ț
a
ț
i

s
ă
joace
jocurile
pe
care
un
personaj
negativ
le-a
conceput.
Mediul
este
extrem
de
variat,

întâlnind
atât
platforme
de
tip
cub
de
ghea
ț ă
care
pun
în
dificu ltate
utilizatorii
prin
faptul
c
ă

sunt
alunecoase,
cât
ș
i
de
tip
roc
ă
vulcanic
ă
.
Juc
ă
torilor
li
se
ofer
ă
oportunitatea
s
ă
lucreze

în
echip
ă
pentru
a
trece
de
unele
obstacole
sau
de
a
se
sabota
reciproc,
astfel
contribuind
la

cre
ș
terea nivelului de co mpetitivitate
ș
i amuzament.

În
modul
„aventur
ă
”
sunt
dou
ă
niveluri
de
dificultate
din
care
se
poate
alege,
adic
ă

normal,
în
care
se
poate
salva
starea
intermediar
ă
a
jocului
prin
puncte
de
control,
sau

foarte
dificil,
unde
trebuie
reluat
întregul
nivel
în
eventualitatea
în
care
personajul
ș
i-a

pierdut
via
ț
a.
La
finalu l
fiec
ă
rui
stagiu,
format
din
mai
multe
nivele,
pentru
a
trece
mai

departe, trebuie învins un personaj negativ.

Fa
ț ă
de
alte
jocuri,
acesta
vine
ș
i
cu
modul
„aren
ă
”,
unde
dou
ă
echipe,
fie
formate
din

câte
un
juc
ă
tor,
fie
din
doi
juc
ă
tori,
se
lupt
ă
pentru
victorie.
Acest
mod
ofer
ă
mai
multe

tipuri de meciuri din care utilizatorii pot alege.

1.1.3. Super Meat Boy

Un
alt
joc
de
succes,
cu
peste
un
milion
de
copii
vândute
ș
i
având
un
num
ă
r

impresionant
de
nivele,
aplica
ț
ia
îl
are
ca
protagonist
pe
„Meat
Boy”,
un
cub
de
culoare

ro
ș
ie,
a
c
ă
rui
misiune
este
s
ă
–
ș
i
salveze
iubita
care
se
afl
ă
în
posesia
unui
personaj
negativ.

6

Pentru
a
putea
ajunge
la
aceasta,
trebuie
s
ă
dep
ă ș
easc
ă
obstacole
foarte
dificile,
atât

orizontale, cât
ș
i vertica le, care necesit
ă
agilitate, o bun
ă
coordonare
ș
i mult
ă
aten
ț
ie.

Utilizatorii
pot
debloca
nivele
speciale,
sau
unele
similare
cu
cel
jucat,
dar
cu
gradul

de
dificultate
sporit,
au
op
ț
iunea
de
a
selecta
un
alt
personaj
principal
pe
care
s
ă
îl

controleze, cu posibilitatea de a utiliza puterile acestora.

1.2. Jocuri puzzle-platformer

În
ceea
ce
prive
ș
te
jocurile
de
acest
tip,
caracteristica
lor
principal
ă
este
aceea
c
ă

personajul
trebuie
s
ă
apeleze
la
aten
ț
ia
la
detalii
ș
i
la
inteligen
ț ă
pentru
a
se
folosi
de

obiecte
ș
i
a
rezolva
puzzle-uri
ascunse
în
mediul
înconjur
ă
tor
care
sunt
obligatorii
pentru
a

putea completa nivelele.

1.2.1. Limbo

Ceea
ce
la
prima
vedere
ar
putea
fi
considerat
un
joc
de
groaz
ă
,
este
mai
degrab
ă

apropiat
de
o
form
ă
de
art
ă
.
Cu
o
grafic
ă
ce
se
folose
ș
te
doar
de
culorile
alb
ș
i
negru
ș
i
de

lumini,
pu
ț
ine
sunete
ș
i
o
atmosfer
ă
în
general
întunecat
ă
,
„Limbo”
face
uz
de
numeroase

mecanici
pentru
a
implementa
puzzle-uri
ce
necesit
ă
adesea
ca
personajul
s
ă
gre
ș
easc
ă

înainte de a descoperi solu
ț
ia.

Povestea
prezint
ă
un
b
ă
iat
c
ă
ruia
nu
îi
este
asociat
niciun
nume,
dar
care
se
treze
ș
te

în
mijlocul
unei
p
ă
duri
ș
i
porne
ș
te
în
c
ă
utarea
surorii
sale.
Pentru
a-
ș
i
atinge
ț
elul,

7

traverseaz
ă
medii
diver se
a
c
ă
ror
singur
ă
similaritate
este
atmosfera
post-apocaliptic
ă
care

le înconjoar
ă
.

Spre
deosebire
de
alte
jocuri
din
categoria
sa,
acesta
ofer
ă
posibilitatea
de
trage
sau

împinge
obiecte,
de
a
declan
ș
a
mecanisme
complexe
ș
i
de
a
utiliza
obiecte
adunate
anterior

pentru a rezolva puzzle-urile.

Pe
parcursul
pove
ș
tii,
singurele
fiin
ț
e
umane
pe
care
personajul
principal
le

întâlne
ș
te
sunt
fie
f
ă
r
ă
via
ț ă
,
întemni
ț
ate,
fie
ostile,
încercân d
s
ă
îl
omoare,
fie
speriate
de

acesta,
motiv
pentru
care
se
ascund,
iar
caracterul
nu
are
poate
interac
ț
iona
cu
ele,
ceea
ce

spore
ș
te atmosfera stra nie.

1.2.2. LittleBigPlanet

Seria
de
jocuri
lansat
ă
pe
parcursul
mai
multor
ani
de
compania
„Sony
Computer

Entertainment”,
de
ș
i
ini
ț
ial
bazat
ă
majoritar
pe
stilul
puzzle-platformer,
în
primele
dou
ă

jocuri,
a
introdus
o
colec
ț
ie
de
mini-jocuri
de
toate
genurile
ș
i
a
oferit
utilizatorilor

posibilitatea
de
a-
ș
i
crea
propriile
nivele
ș
i
de
a
le
înc
ă
rca
în
re
ț
ea
pentru
ca
to
ț
i
ceilal
ț
i

juc
ă
tori s
ă
le poat
ă
acces a.

Ac
ț
iunea
este
plasat
ă
pe
o
planet
ă
asem
ă
n
ă
toare
cu
P
ă
mântul,
divizat
ă
în
mai
multe

regiuni,
fiecare
având
un
conduc
ă
tor
ș
i
drept
personaj
principal
îl
are
pe
„Sackboy”,
un

umanoid
sub
forma
unei
p
ă
pu
ș
i
din
material
textil,
care
poate
fi
personalizat
în
func
ț
ie
de

alegerea
juc
ă
torilor.
Ace
ș
tia
pot
controla
ș
i
principalele
emo
ț
ii
pozitive
ș
i
negative
ale

creaturii: fericirea, triste
ț
ea, îngrijorarea
ș
i furia.

8

Misiunea
personajului
în
primul
joc
al
seriei
este
de
a-i
ajuta
pe
conduc
ă
torii

regiunilor
planetei
ș
i
de
a-l
opri
pe
„Colec
ț
ionar”,
unul
dintre
conduc
ă
tori,
care
trecând
de

partea
r
ă
ului,
fur
ă
crea
ț
iile
acelei
lumi.
În
a
doua
parte,
personajul
negativ,
„Negativitron”,

invadeaz
ă
planeta
ș
i
îi
r
ă
pe
ș
te
locuitorii,
motiv
pentru
care
trebuie
oprit
cu
orice
pre
ț
,
iar
în

partea
a
3-a,
„Sackboy”,
acum
aflat
pe
alt
ă
planet
ă
,
trebuie
s
ă
îi
readuc
ă
la
via
ț ă
pe
cei
trei

eroi disp
ă
ru
ț
i, „OddSock”, „Toggle”
ș
i „Swoop”.

1.3. Motiva
ț
ia tem ei

În
contextul
actual,
în
ceea
ce
prive
ș
te
jocurile
puzzle-platformer
2D,
mediul
în
care

este
plasat
ă
ac
ț
iunea
este
unul
fantastic,
îns
ă
segmentul
celor
care
trateaz
ă
tema

subacvatic
ă
este
redus ,
iar
unul
care
s
ă
–
ș
i
situeze
perso najul
principal
într-un
ora
ș

scufundat
este
ș
i
mai
restrâns.
Mecanicile
prezentate
p
ă
streaz
ă
o
oarecare
leg
ă
tura
cu

realitatea,
dar
ș
i
cu
legile
fizicii
în
aplica
ț
iile
prezentate
anterior,
iar
„Forgotten
City”
se

încadreaz
ă
de asemenea în aceast
ă
categorie.

Jocul
va
fi
implementat
în
prim
ă
faz
ă
pentru
computere,
cu
ajutorul
motorului
grafic

„Unity
2018.1.1f1”
punând
accent
pe
scenariul
mitic
ș
i
pe
o
combina
ț
ie
de
inamici
ș
i

mecanisme inspirate din realitate.

9

CAPITOLUL 2. CERIN
Ț
E
Ș
I SPECIFIC A
Ț
II

Aplica
ț
ia
î
ș
i
propune
s
ă
permit
ă
utilizatorilor
s
ă
î
ș
i
testeze
agilitatea,
inteligen
ț
a
ș
i

ingeniozitatea
în
rezolvarea
puzzle-urilor
incluse
în
nivelele
jocului,
pentru
care
este

necesar s
ă
fie capabil
ă
de urm
ă
toarele:

–
Explorarea nivelelor de joc în ordine

–
Oferirea de indica
ț
ii sau sugestii atunci când în joc apare un element nou

–
Afi
ș
area punc tajului curent al utilizatorului

–
Salvarea intermediar
ă
a punctajului ob
ț
inut de juc
ă
tor la fiecare nivel

–
Contorizarea num
ă
rului de vie
ț
i pierdute pe parcur sul jocului

–
Calcularea
punctajului
final
în
func
ț
ie
de
monedele
adunate
ș
i
num
ă
rul
de
vie
ț
i

pierdute

–
S
ă
nu
permi t
ă
trecerea
la
urm
ă
torul
stagiu
f
ă
r
ă
a
fi
completat
cel
curent
ș
i

adunate toate obiectele necesare

–
S
ă
afi
ș
eze stadiul colect
ă
rii obiectelor necesare complet
ă
rii nivelului curent

–
Afi
ș
area punc tajului final ob
ț
inut de juc
ă
tor

–
Afi
ș
area celui mai mare punctaj ob
ț
inut dintre toate sesiunile de joc

–
S
ă
permit
ă
juc
ă
torului
s
ă
reia
jocul
de
la
ultimul
nivel
necompletat
dup
ă
ie
ș
irea
ș
i

revenirea în aplica
ț
ie

–
S
ă
permit
ă
juc
ă
torului
s
ă
înceap
ă
o
sesiune
nou
ă
de
joc
care
o
va
suprascrie
pe

cea existent
ă

–
S
ă
permit
ă
juc
ă
torului s
ă
opreasc
ă
sau s
ă
reporneasc
ă
sunetele din joc

10

CAPITOLUL 3. ANALIZA PROBLEMEI

Un
rol
esen
ț
ial
în
dezvoltarea
oric
ă
rei
aplica
ț
ii
îl
constituie
analizarea
specifica
ț
iilor

ce
urmeaz
ă
a
fi
implem entate
pentru
asigurarea
unei
func
ț
ion
ă
ri
corecte,
de
durat
ă
ș
i

conforme cu cerin
ț
ele.

3.1. Jocul

Genul
corespunz
ă
tor
acestui
tip
de
joc
este
puzzle-platformer,
în
care
juc
ă
torul
are

încerc
ă
ri
nelimitate
de
a
rezolva
misiunile,
îns
ă
în
cazul
de
fa
ț ă
va
exista
ș
i
o
penalitate

pentru
moarte,
reluându-se
nivelul
de
la
început
dup
ă
un
num
ă
r
de
trei
vie
ț
i
pierdute
ș
i

sc
ă
derea punctajului fin al în func
ț
ie de num
ă
rul total al acestora.

3.2. Personajul

La
momentul
lans
ă
rii
primului
nivel
al
aplica
ț
iei
personajul
este
creat
automat

pentru
utilizator
ș
i
în
stadiul
curent
al
jocului,
acesta
nu
poate
fi
personalizat.

Caracteristicile
sale,
vizibile
pe
ecran,
sunt
via
ț
a
ș
i
oxigenul.
O
via
ț ă
este
pierdut
ă
la

coliziunea
cu
un
inamic
sau
c
ă
derea
în
abis.
Oxigenul
se
scurge
pe
m
ă
sur
ă
ce
trece
timpul
ș
i

produce
pierderea
unei
vie
ț
i
dac
ă
ajunge
la
valoarea
0.
Person ajul
se
poate
deplasa
pe
orice

ax
ă

ș
i în orice direc
ț
ie.

3.3. Inamicii

Se
diferen
ț
iaz
ă
dou
ă
categorii
de
inamici
pe
parcursul
jocului,
statici
ș
i
dinamici,
care

au
un
traseu
bine
stabilit
ș
i
eviden
ț
iat
în
cadrul
nivelului.
Singura
ac
ț
iune
pe
care
o
pot

efectua
este
cea
de
a
reduce
num
ă
rul
de
vie
ț
i
ale
juc
ă
torului
cu
una
la
coliziunea
dintre

ace
ș
tia
ș
i personaj.

3.4. Obiectele de adunat

Personajul
trebuie
s
ă
adune
în
fiecare
nivel
un
num
ă
r
de
obiecte
necesare
pentru
a

trece
la
urm
ă
torul
stagi u.
Stadiul
colect
ă
rii
acestora
este
vizibil
în
permanen
ț ă
pe
ecran.
Pe

lâng
ă
obiectele
obligato rii,
juc
ă
torul
are
posibilitatea
de
a
aduna
ș
i
puncte
sub
forma
unor

monede.
Scorul
utilizatorului
va
fi
afi
ș
at
pe
ecran
în
timp
real.
O
alt
ă
categorie
de
obiecte
ce

pot fi adunate sunt cele ce deblocheaz
ă
por
ț
iuni din nivelul curent.

3.5. Obstacolele

Sunt
obiecte
statice
ce
blocheaz
ă
drumul
pe
care
personajul
trebuie
s
ă
îl
parcurg
ă

pentru
terminarea
nivelului
ș
i
pot
fi
eliminate
cu
ajutorul
unei
categorii
de
obiecte
de

adunat descrise anterior.

11

3.6. Mecanismele

Alc
ă
tuite
din
mai
multe
tipuri
de
obiecte,
sau
constituite
din
un
singur
element,

mecanismele
reprezint
ă
por
ț
iuni
de
care
juc
ă
torul
poate
trece
doar
dup
ă
descoperirea

solu
ț
iei care le activeaz
ă
pe fiecare în parte.

3.7. Tutoriale

Obiectele
de
acest
tip
furnizeaz
ă
la
coliziunea
cu
ele
informa
ț
ii
utile
juc
ă
torului

pentru
controlarea
personajului,
completarea
nivelelor,
utilizarea
altor
tipuri
de
obiecte,

sau evitarea unor inamici.

12

CAPITOLUL 4. TEHNOLOGII FOLOSITE

4.1. Motorul grafic de dezvoltare „Unity”

Exist
ă
o
larg
ă
varietate
de
jocuri
deja
lansate,
dar
ș
i
în
curs
de
dezvoltare
ce
pot
fi

accesate
prin
intermediul
unui
computer,
indiferent
de
sistemul
de
operare
instalat
pe

acesta.
Num
ă
rul
lor
este
greu
de
estimat
cu
atât
mai
mult
cu
cât
în
prezent
motoarele

grafice
permit
atât
unei
echipe
de
programatori,
cât
ș
i
oric
ă
rui
pasionat
s
ă
creeze
propriul

joc.
Motoarele
precum
„Unity„
ș
i
„Unreal
Engine”
vin
în
ajutorul
produc
ă
torilor
de
jocuri
cu

numeroase
libr
ă
rii
ș
i
prin
asociere
cu
un
mediu
de
dezvoltar e
u
ș
or
de
folosit,
dar
totodat
ă

extrem
de
puternic,
formeaz
ă
o
structur
ă
complet
ă
ce
pune
la
dispozi
ț
ie
toate
resursele

necesare din punct de vedere software pentru crearea de jocuri video.

4.1.1. Crearea unui proiect

Unity
cere
dezvoltatorilor
la
crearea
unui
proiect
nou
s
ă
aleag
ă
între
op
ț
iunile
de

aplica
ț
ie
2D
sau
3D,
deoarece
în
func
ț
ie
de
tipul
ales
difer
ă
atât
structura
de
directoare
ș
i

con
ț
inutul acestora cât
ș
i modul în care motorul grafic interpr eteaz
ă
obiectele.

Limbajul
de
programare
în
care
vor
fi
scrise
clasele
ș
i
func
ț
iile
este
C#
ș
i
este

singurul acceptat
ș
i prom ovat în prezent, dup
ă
ce în anul 2017 JavaScript a fost depreciat.

13

4.1.2. Concepte
ș
i modul de realizare al unui joc

În
ceea
ce
prive
ș
te
jocurile
2D,
din
care
aceast
ă
aplica
ț
ie
face
parte,
Unity
ofer
ă

posibilitatea
de
a
importa
imagini,
scopul
lor
fiind
de
a
îmbr
ă
ca
obiectele
cu
design.
De

asemenea pune la dispozi
ț
ie un „renderer” avansat pentru acest tip de con
ț
inut.

Dup
ă
crearea
proiectului,
dezvoltatorul
are
implicit
mai
multe
ferestre
deschise
în

interiorul
motorului
grafic,
printre
care
ș
i
lista
de
directoare
aferente
aplica
ț
iei.
Pentru
o

mai
bun
ă
în
ț
elegere
a
elementelor
ce
vor
fi
necesare
ș
i
vor
trebui
ad
ă
ugate
este

recomandat
ă
importare a
pachetului
2D,
deoarece
pe
lâng
ă
faptul
c
ă
ofer
ă
o
privire
de

ansamblu
asupra
obiectelor
ș
i
repartiz
ă
rii
lor
pe
fi
ș
iere,
con
ț
ine
ș
i
un
exemplu
de
baz
ă
al

unui schelet de joc 2D.

14

4.1.2.1. Ferestrele principale

–
Project:
în
aceast
ă
fereastr
ă
este
vizibil
ă
ierarhia
de
fi
ș
iere
a
proiectului,
iar
la

selectarea fiec
ă
rui fi
ș
ier, în partea dreapt
ă
este afi
ș
at con
ț
inutul acestuia.

–
Hierarchy:
aici
sunt
listate
toate
obiectele
existente
în
scena
selectat
ă
.
Toate

obiectele
ce
vor
fi
ad
ă
ugate
pot
fi
trase
cu
ajutorul
mouse-ului
în
aceast
ă

zon
ă
.

–
Inspector:
probabil
cea
mai
important
ă
dintre
ferestrele
ajut
ă
toare
puse
la

dispozi
ț
ie
de
Unity.
Con
ț
ine
lista
elementelor
ata
ș
ate
obiectului
selectat.
Tot

aici
se
pot
activa
ș
i
inactiva
unele
componente,
se
pot
ș
terge
sau
ad
ă
uga
altele

noi, ba chiar se pot crea script-uri
ș
i ata
ș
a în acela
ș
i timp obiectului curent.

–
Scene:
permite
vizualizarea
tuturor
obiectelor
ad
ă
ugate
în
scena
selectat
ă
,

dar
mai
ales
permite
aranjarea
lor
în
spa
ț
iu
ș
i
ad
ă
ugarea
de
elemente
noi
sau

rotirea lor pe orice ax
ă

–
Game:
dup
ă
ap
ă
sarea
butonului
„play”,
aceast
ă
fereastr
ă
are
rolul
de
a
simula

jocul
creat
direct
din
motorul
grafic,
f
ă
r
ă
a
fi
necesar
ă
construirea
unui
fi
ș
ier

executabil spre a fi lansat

–
Console:
aici
vor
fi
vizibile
erorile
ap
ă
rute
la
compilare
ș
i
mesajele
pe
care

programatorul
dore
ș
te
s
ă
le
afi
ș
eze
cu
scop
de
test,
pe
parcursul
procesului

de dezvoltare a jocului.

–
Animator:
permite
crearea
tranzi
ț
iilor
dintre
anima
ț
ii
ș
i
setarea
valorilor

„prag” pentru declan
ș
area acestora

4.1.2.2. Set
ă
rile camerei

Pentru
a
putea
crea
un
nivel
este
nevoie
de
un
element
care
s
ă
fie
capabil
s
ă

interpreteze
ș
i
s
ă
ț
in
ă
toate
elementele
la
un
loc,
numit
scen
ă
.
Dup
ă
instan
ț
iere,
scena

con
ț
ine
doar
un
singur
obiect,
mai
exact
camera
video
virtual
ă
prin
intermediul
c
ă
reia

utilizatorii
vor
vizualiza
mediul
înconjur
ă
tor.
În
2D,
perspectiva
asupra
c
ă
reia
este

orientat
ă
aceast
ă
camer
ă
este
cea
lateral
ă
ș
i
pozi
ț
ia
ei
este
fix
ă
,
acest
lucru
însemnând
c
ă
în

momentul
în
care
personajul
se
deplaseaz
ă
,
camera
nu
îl
va
urm
ă
ri.
Modul
acesta
de

implementare
este
util
pentru
jocurile
2D
care
se
bazeaz
ă
pe
ecrane
statice
ș
i
schimb
ă

scena doar când juc
ă
torul a ajuns la finalul ecranului curent.

Dac
ă
se
dore
ș
te
o
camer
ă
mobil
ă
care
s
ă
urm
ă
reasc
ă
mi
ș
c
ă
rile
juc
ă
torului,
se
pot

modifica
set
ă
rile
aceste ia
cu
ajutorul
ferestrei
„inspector”
în
care
sunt
afi
ș
ate
componentele

ata
ș
ate pe obiect
ș
i propriet
ă ț
ile acestora.

15

4.1.2.3. Anima
ț
iile

Un
aspect
important
al
oric
ă
rui
joc
este
reprezentat
de
anima
ț
ii,
fie
ale
personajului,

fie
ale
altor
obiecte
ce
apar
pe
parcursul
nivelelor.
Motorul
grafic
Unity
pune
la
dispozi
ț
ie
o

component
ă
cu ajutorul c
ă
reia ele pot fi create într-un mod de stul de simplu.

Pentru
ca
anima
ț
iile
ș
i
tranzi
ț
iile
dintre
ele
s
ă
poat
ă
fi
manageriate,
trebuie
creat
un

controller
care
va
prelua
rolul
de
a
le
interpreta.
Acesta
se
ata
ș
eaz
ă
în
câmpul
specific
al

obiectului
c
ă
ruia
i
se
vor
adresa
anima
ț
iile
viitoare,
dup
ă
ce
în
prealabil
i
s-a
ad
ă
ugat
o

component
ă
de
tip
„Ani mator”.
Având
selectat
obiectul
asupra
c
ă
ruia
se
dore
ș
te
ad
ă
ugarea

unei
anima
ț
ii,
din
men iul
„Window”,
op
ț
iunea
„Animation„
se
creeaz
ă
un
nou
clip
având

denumirea tipului de mi
ș
care ce va fi executat
ă
, precum alergat sau s
ă
ritur
ă
.

Acestuia
i
se
ata
ș
eaz
ă
imaginile
individuale
ale
obiec tului,
în
diferite
ipostaze
ș
i
în

ordinea
corect
ă
a
afi
ș ă
rii
lor
dup
ă
care
se
pot
seta,
doar
dac
ă
se
dore
ș
te,
num
ă
rul
de
cadre

pe secund
ă

ș
i viteza anima
ț
iei.

Odat
ă
create
toate
anima
ț
iile
necesare
pentru
un
obiect,
motorul
grafic
permite

editarea
leg
ă
turilor
dint re
acestea
ș
i
asocierea
unor
condi
ț
ii
cu
trecerea
de
la
o
stare
la
alta

prin intermediul ferestrei „Animator”, op
ț
iunea „Make Transition”.

Aici
sunt
afi
ș
ate
sub
form
ă
de
dreptunghiuri
toate
clipurile
create
la
pasul
anterior.

Pentru
ca
Unity
s
ă
poat
ă
schimba
anima
ț
iile
corect
trebuie
definite
tranzi
ț
iile
dintre
acestea

16

sub
forma
unor
condi
ț
ii
ce
verific
ă
valoarea
sau
valorile
uneia
sau
mai
multor
variabile

special
definite
cu
scopul
de
a
fi
folosite
pe
post
de
„praguri”,
adic
ă
în
cazul
în
care
valoarea

dep
ă ș
e
ș
te
un
num
ă
r
prestabilit,
se
va
ac
ț
iona
tranzi
ț
ia
corespunz
ă
toare
ș
i
se
va
schimba

anima
ț
ia.

4.1.2.4. Prefabricate

Obiectele
prefabricate
sunt
esen
ț
iale
în
orice
proiect
„Unity”
care
are
ca
scop
crearea

unui joc în care unele elemente se repet
ă
pe parcursul nivelelor.

A
ș
a
cum
le
suge reaz
ă
ș
i
numele,
aceste
tipuri
de
obiecte
sunt
salvate
în
aplica
ț
ie

pentru
folosirea
lor
ulterioar
ă
împreun
ă
cu
toate
set
ă
rile
ș
i
componentele
ata
ș
ate
acestora.

Un
aspect
important
este
faptul
c
ă
dac
ă
se
dore
ș
te
aplicarea
unor
modific
ă
ri
asupra
unei

categorii
de
obiecte,
se
pot
efectua
pe
un
singur
obiect
apar
ț
inând
acelei
categorii,
iar
prin

ac
ț
ionarea
butonului
„aplic
ă
”,
transform
ă
rile
vor
fi
vizibile
pe
toate
instan
ț
ele
existente
în

scen
ă
ale acelui grup.

4.1.2.5. Materiale

Acestea
sunt
capabile
de
a
oferi
obiectelor
un
comportament
diferit
în
func
ț
ie
de

natura
materialului
selectat.
Se
pot
transforma
în
obiecte
lipicioase,
alunecoase,
tip

trambulin
ă
,
sau
orice
alte
propriet
ă ț
i
se
reg
ă
sesc
ș
i
în
lumea
real
ă
.
Materialele
se
pot
ata
ș
a,

prin intermediul inspectorului, doar unei anumite categorii de elemente.

17

4.1.2.6. Sprite-urile

Categoria
aceasta
include
imaginile
ce
vor
fi
folosite
pentru
a
îmbr
ă
ca
obiectele
din

scen
ă
.
În
general,
se
prefer
ă
formatul
„PNG.”
datorit
ă
transparen
ț
ei
ilustra
ț
iilor,
extrem
de

util
ă
în
construirea
nivelului.
Sprite-urile
se
ata
ș
eaz
ă
pe
elementul
corespunz
ă
tor
cu

ajutorul unei componente numite „Sprite Renderer” în câmpul destinat acestora.

4.1.2.7. Scripturile

Reprezint
ă
parte a
central
ă
ș
i
esen
ț
ial
ă
a
aplica
ț
iei,
f
ă
r
ă
de
care
toate
tipurile
de

elemente
prezentate
anterior
ar
fi
doar
ni
ș
te
componente
statice,
iar
jocul
nu
ar
avea
sens,

dat
fiind
faptul
c
ă
nive lele
ar
ap
ă
rea
ca
simple
imagini.
Prin
intermediul
scripturilor
se

adaug
ă
comportament
obiectelor,
dar
pot
fi
ș
i
manipulate
în
spa
ț
iu,
componentele
lor

inactivate,
modificate
acestea
în
sine,
sau
doar
unele
valori
ale
variabilelor
lor,
eliminate,

sau
ata
ș
ate
altui
obiec t.
De
asemenea,
ele
pot
controla
scenele,
permit
setarea
unor

variabile globale cu scopul de a re
ț
ine preferin
ț
ele fiec
ă
rui utilizator.

4.1.2.8. PlayerPrefs

Unity
pune
la
dispozi
ț
ie
o
modalitate
de
a
salva
local,
pe
dispozitivul
utilizatorului
o

serie
de
valori,
fie
numerice,
fie
ș
iruri
de
caractere,
fie
obiecte.
Ele
pot
fi
utilizate
pentru

setarea
preferin
ț
elor
de
sistem
ale
fiec
ă
rui
juc
ă
tor
în
parte,
cum
ar
fi
nivelul
sunetului,
dac
ă

acesta
este
pornit
sau
oprit,
a
tipului
de
grafic
ă
ales,
pentru
re
ț
inerea
scorului,
a
nivelului
în

curs
în
momentul
ie
ș
irii
din
aplica
ț
ie
sau
orice
alte
valori
necesare
pentru
o
func
ț
ionare

corect
ă
.

4.2. Mediul de dezvoltare Microsoft Visual Studio

Pentru
crearea
claselor,
a
func
ț
iilor
ș
i
editarea
scripturilor
s-a
utilizat
mediul
de

dezvoltare asociat cu Unity „Microsoft Visual Studio”
ș
i instalat odat
ă
cu motorul grafic.

Este
necesar
ă
importarea
pachetului
„UnityEngine”
la
începutul
fiec
ă
rei
clase
a

aplica
ț
iei
pentru
ca
programul
s
ă
recunoasc
ă
func
ț
iile
predefinite
specifice
dezvolt
ă
rii
de

jocuri
precum
„Start”,
„Update”,
„FixedUpdate”
obligatorii
pentru
clasele
în
care
se
dore
ș
te

executarea
unor
instruc
ț
iuni
repetitive.
Acestea
ofer
ă
posibilitatea
de
a
alege
dac
ă
seturile

de
instruc
ț
iuni
se
vor
repeta
la
un
interval
de
timp
fix,
caz
în
care
se
va
folosi

„FixedUpdate”,
sau
la
fiecare
cadru,
indiferent
de
durata
necesar
ă
proces
ă
rii
acestuia,

situa
ț
ie în care este util
ă
func
ț
ia „Update”.

Acest
produs
software
permite
de
asemenea
crearea
unor
clase
speciale,
ce
vor

trebui
scrise
de
c
ă
tre
programator,
cu
scopul
de
a
testa
automat
componentele
aplica
ț
iei

dezvoltate sau comportamentul corect sau incorect al acestora.

18

4.3. Editorul de grafic
ă
vectorial
ă
Inkscape

O
caracteristic
ă
fundamental
ă
datorit
ă
importan
ț
ei
impactului
vizual
asupra

utilizatorului
o
reprezint
ă
grafica.
Pentru
garan
ț
ia
c
ă
elementele
desenate
se
vor
adapta

oric
ă
rei
rezolu
ț
ii
ș
i
oric
ă
rei
dimensiuni,
p
ă
strându-
ș
i
calitate a,
ilustra
ț
iile
trebuie
realizate

cu
ajutorul
graficii
vectoriale.
Aceasta
se
bazeaz
ă
,
dup
ă
cum
sugereaz
ă
ș
i
numele,
pe

utilizarea de vectori pentru a reprezenta liniile.

Editorul
permite
manipularea
tuturor
elementelor
ad
ă
ugate,
fie
c
ă
este
vorba
de

mi
ș
c
ă
ri
de
transla
ț
ie,
rota
ț
ie,
oglindire,
alungire,
sau
chiar
de
aranjarea
obiectelor
sub
form
ă

de
ierarhie,
unele
deasupra
altora.
Sunt
posibile
de
asemenea
ș
i
transform
ă
ri
mai
complexe

precum uniunea, intersec
ț
ia sau diferen
ț
a dintre dou
ă
forme suprapuse.

Cu
ajutorul
func
ț
iilor
oferite
de
acest
produs
software
se
pot
crea
componente

grafice
extrem
de
detaliate
care
pot
fi
folosite
ulterior
ca
imagini
de
sine
st
ă
t
ă
toare
sau
ca

parte
a
unui
set
de
ilustra
ț
ii
ce
alc
ă
tuiesc
o
anima
ț
ie.
Desenele
astfel
realizate
se
pot
exporta

în formatul „PNG.”, ideal pentru integrarea lor ca sprite-uri în motorul grafic „Unity”.

19

CAPITOLUL 5. PROIECTAREA INTERFE
Ț
EI

În
ceea
ce
prive
ș
te
interfa
ț
a
grafic
ă
a
unui
joc,
majoritatea
elementelor
nu
au
o

pozi
ț
ie
fix
ă
deoarece
mediul
este
dinamic,
se
adaug
ă
constant
componente
noi,
peisajul
se

poate schimba, iar de la un nivel la altul cadrul poate suferi modific
ă
ri numeroase.

În
cazul
acestei
aplica
ț
ii
exist
ă
un
num
ă
r
restrâns
de
structuri
statice
care
î
ș
i

p
ă
streaz
ă
pozi
ț
ia
pe
ecran
indiferent
de
dimensiunile
ș
i
rezolu
ț
ia
acestuia.
Acestea
sunt

grupate
într-un
obiect
denumit
„Canvas”
care
are
proprietatea
c
ă
este
desenat
deasupra

tuturor celorlalte elemente.

5.1. Meniul jocului

La
deschiderea
aplica
ț
iei
utilizatorul
este
întâmpinat
de
un
meniu
din
care
poate

selecta una din urm
ă
toarele op
ț
iuni:

–
New Game pentru începerea unei noi sesiuni de joc

–
Continue Game pentru continuarea sesiunii de joc de la ultimul nivel necompletat

–
Quit Game pentru ie
ș
irea din joc

–
Music On / Music Off pentru pornirea
ș
i oprirea sunetului de fundal

20

5.2. Meniul în timpul pauzei

Prin
ap
ă
sarea
tastei
„Escape”
în
decursul
oric
ă
rui
nivel
utilizatorul
poate
activa

meniul
„Pauz
ă
”care
întrerupe
jocul
pân
ă
la
ac
ț
ionarea
butonului
„Resume
Game”
pentru
a

relua
nivelul
curent.
Acest
meniu
îi
pune
la
dispozi
ț
ie
juc
ă
torului
posibilitatea
de
a
executa

urm
ă
toarele ac
ț
iuni:

–
Resume Game pentru revenirea în joc

–
Quit To Main Menu pentru întoarcerea la meniul principal al jocului

–
Quit Game pentru închiderea aplica
ț
iei

–
Music On / Music Off pentru pornirea
ș
i oprirea sunetului de fundal

5.3. Elementele statice

Design-ul
este
unul
simplu,
aerisit
ș
i
intuitiv,
elementele
sunt
aranjate
astfel
încât
s
ă

fie
u
ș
or
vizibile
utilizat orului
ș
i
sunt
afi
ș
ate
permanent,
f
ă
r
ă
a
fi
necesar
ă
ap
ă
sarea
unor

butoane pentru vizualizarea acestor informa
ț
ii.

Juc
ă
torul
poate
verifica
mereu
num
ă
rul
de
vie
ț
i
pe
care
le
are
la
dispozi
ț
ie
în
col
ț
ul

din
stânga
jos,
cât
ș
i
nivelul
oxigenului
r
ă
mas
din
valoarea
total
ă
,
tot
în
partea
stâng
ă
,
dar
în

extremitatea
de
sus.
De
asemenea,
are
posibilitatea
de
a
observa
câte
obiecte
mai
are
de

adunat pentru a trece nivelul
ș
i câte a colectat pân
ă
în prezent, dar
ș
i scorul realizat.

21

Un
alt
element,
disponibil
în
anumite
condi
ț
ii
pe
care
utilizatorul
îl
poate
declan
ș
a

este
un
panou
în
care
vor
fi
listate
instruc
ț
iuni
sau
informa
ț
ii
ajut
ă
toare
sub
forma
unui

scurt tutorial.

5.4. Pozi
ț
ionarea personajului pe ecran

Perspectiva
asupra
personajului
r
ă
mâne
aceea
ș
i
pe
parcursul
jocului,
camera

mi
ș
cându-se
odat
ă
cu
acesta
ș
i
p
ă
strându-i
pozi
ț
ia
pe
axa
orizontal
ă
la
o
treime
din

dimensiunea
acesteia,
iar
pe
axa
vertical
ă
pu
ț
in
sub
jum
ă
tatea
distan
ț
ei
dintre
marginea
de

sus
ș
i
cea
de
jos.
Acea st
ă
a
ș
ezare
a
fost
adoptat
ă
pentru
a
permite
o
vizualizare
optim
ă

asupra elementelor aflate în fa
ț
a juc
ă
torului, cât
ș
i a celor din partea superioar
ă
.

22

Referitor
la
proiectarea
nivelelor,
Unity
este
extrem
de
flexibil.
Orice
tip
de
obiect,

indiferent
de
form
ă
,
poate
constitui
solul
pe
care
se
deplaseaz
ă
personajul.
Mi
ș
c
ă
rile

acestuia
pot
fi
restrânse
la
un
spa
ț
iu
definit
de
programator
atât
în
lungime,
cât
ș
i
în

în
ă
l
ț
ime.
Obiectele
cu
care
acesta
poate
interac
ț
iona,
statice
sau
dinamice,
ș
i
design-ul,

pozi
ț
ia
ș
i
dimensiunile
lor
sunt
la
latitudinea
dezvoltatorulu i
întrucât
Unity
accept
ă
orice

imagine
ș
i
orice
form
ă
în
interiorul
nivelelor.
Prin
urmare,
interfa
ț
a
vizibil
ă
utilizatorului

este foarte variat
ă

ș
i în cazul acestei aplica
ț
ii.

5.5. Meniul de final de joc

Dup
ă
completare a
tuturor
nivelelor
utilizatorul
este
direc
ț
ionat
c
ă
tre
un
ecran
în

care
îi
este
afi
ș
at
un
alt
meniu
cu
dou
ă
op
ț
iuni
ș
i
dou
ă
informa
ț
ii
cu
privire
la
evolu
ț
ia
sa
pe

parcursul jocului:

–
Quit To Main Menu pentru revenirea la meniul principal

–
Quit Game pentru ie
ș
irea din aplica
ț
ie

–
HighScore actualizat în func
ț
ie de cel mai mare punctaj ob
ț
inut de utilizator

–
Score reprezentând punctajul ob
ț
inut în sesiunea curent
ă
de joc

23

5.7. Ecranul dintre nivele

Înainte
de
lansarea
fiec
ă
rui
nivel
pe
ecran
este
afi
ș
at
un
„Canvas”
prin
intermediul

c
ă
ruia
utilizatorul
este
informat
cu
privire
la
denumirea
ș
i
num
ă
rul
nivelului
ce
urmeaz
ă
s
ă

fie jucat.

24

CAPITOLUL 6. IMPLEMENTAREA APLICA
Ț
IEI

Aceast
ă
aplica
ț
ie
î
ș
i
propune
dezvoltarea
unui
joc
2D
puzzle-platformer,
cu
numele

„Forgotten
City”,
având
drept
cadru
de
desf
ă ș
urare
al
ac
ț
iunii
mediul
subacvatic
dintr-un

ora
ș
fictiv
scufundat.
Pentru
implementarea
acesteia,
s-a
utilizat
motorul
grafic
„Unity”

împreun
ă
cu
mediul
de
dezvoltare
„Microsoft
Visual
Studio”
pentru
redactarea
codului
ș
i

editorul de grafic
ă
vecto rial
ă
„Inkscape” pentru ad
ă
ugarea design-ului.

6.1. Nivelele

Dup
ă
desc
ă
rcarea
ș
i
instalarea
celor
trei
programe
men
ț
ionate
anterior
se
poate

începe
crearea
nivelelor.
Un
nivel,
în
Unity,
este
reprezentat
de
un
obiect
de
tip
„scen
ă
”
care

se
prezint
ă
sub
forma
unui
spa
ț
iu
infinit
pe
toate
cele
trei
axe
în
care
pot
fi
inserate

elemente.
În
cazul
acestei
aplica
ț
ii,
obiectele
vor
avea
doar
dou
ă
dimensiuni,
iar
nivelul
va

sem
ă
na
cu
o
pânz
ă
sub
ț
ire
dac
ă
este
privit
în
perspectiva
3D
ș
i
cu
un
desen
plat
în

perspectiva 2D. POZE

25

Elementul
cel
mai
important
ș
i
care
asigur
ă
faptul
ca
utilizatorii
vor
putea
vizualiza

cadrul
creat
este
camera
video.
Pentru
ca
personajul
s
ă
î
ș
i
p
ă
streze
constant
ă
pozi
ț
ia
pe

ecran
iar
camera
s
ă
se
deplaseze
odat
ă
cu
acesta,
a
fost
ad
ă
ugat
un
script
care
re
ț
ine
ș
i

actualizeaz
ă
a
ș
ezarea
în
spa
ț
iu
a
acestor
dou
ă
componente
bazându-se
pe
un
calcul
al

distan
ț
ei
ini
ț
iale
dintre
ele
pentru
a
o
putea
reproduce
ulterior
indiferent
de
amplasarea

acestora.

Pentru
ca
aceast
ă
clas
ă
s
ă
func
ț
ioneze
corect,
obiectul
personaj
trebuie
tras
în

câmpul specific al scriptului din fereastra „inspector”. POZE

26

6.2. Personajul

În ceea ce prive
ș
te personajul, acesta a fost construit executând urm
ă
torii pa
ș
i:

–
S-a creat un obiect gol de tip 2D

–
În fereastra „inspector” i s-a ad
ă
ugat o component
ă
de tip „RigidBody 2D”

–
S-a ad
ă
ugat o com ponent
ă
de tip „Sprite Renderer”

–
S-a ata
ș
at o comp onent
ă
de tip „Animator”

–
S-a ad
ă
ugat comp onenta „Polygon Collider 2D”

–
S-a
inserat
scriptul
ce
va
controla
comportamentul
acestui
tip
de
obiect
pe
parcursul

întregii aplica
ț
ii

6.2.1. RigidBody 2D

Aceast
ă
compone nt
ă
este
necesar
ă
pentru
ca
obiectul
c
ă
ruia
îi
este
ata
ș
at
ă
s
ă
poat
ă
fi

afectat
de
for
ț
ele
fizicii
simulate
de
motorul
grafic
„Unity”
precum
for
ț
a
de
frecare,
masa

sau
gravita
ț
ia.
Pentru
a
ob
ț
ine
acest
efect,
în
sec
ț
iunea
„Body
Type”
trebuie
selectat
ă

op
ț
iunea
„Dynamic”
care
permite
corpului
s
ă
simuleze
o
mi
ș
care
asem
ă
n
ă
toare
cu

realitatea.
Tot
prin
aceast
ă
component
ă
se
poate
seta
mas a,
for
ț
a
gravita
ț
ional
ă
care
va

ac
ț
iona
asupra
obiectul ui,
for
ț
ele
de
frecare,
tipul
de
detec
ț
ie
al
coliziunii
cu
alte
obiecte
ș
i

se pot vizualiza vitezele de deplasare pe axele vertical
ă

ș
i orizontal
ă
.

Un
alt
rol
al
acestei
componente
este
acela
de
a
deplasa
în
spa
ț
iu
toate
celelalte

structuri ata
ș
ate corpulu i.

6.2.2. Sprite Renderer

Scopul
acestuia
este
de
a
permite
afi
ș
area
imaginii
asociate
obiectului
ș
i
de
a

controla
ordinea
straturilor
în
care
aceste
ilustra
ț
ii
sunt
reprezentate
pentru
a
crea

impresia
c
ă
sunt
a
ș
ezate
unele
peste
altele.
Se
mai
poate
folosi
ș
i
la
oglindirea
design-ului

pe orice ax
ă
permis
ă
de joc.

6.2.3. Polygon Collider 2D

Este
util
pentru
a
trasa
conturul
fizic
al
obiectului
c
ă
ruia
îi
este
ata
ș
at,
care,
în
cazul

personajului,
este
o
figur
ă
neregulat
ă
,
caz
în
care
se
utilizeaz
ă
componenta
de
tip
poligon.

Pe
lâng
ă
acest
scop,
este
esen
ț
ial
pentru
simularea
coliziunilo r
dintre
caracterul
principal
al

jocului
ș
i
celelalte
elem ente,
inclusiv
solul.
Prin
urmare,
f
ă
r
ă
acesta,
obiectul
ar
c
ă
dea
la

infinit.

27

6.2.4. Animator

Este
necesar
pentru
ad
ă
ugarea
de
anima
ț
ii
ș
i
obligatoriu
trebuie
creat
ș
i
specificat

un
controller
în
spa
ț
iul
dedicat
al
componentei
curente,
care
va
coordona
tranzi
ț
iile
dintre

acestea.

6.2.5. Scriptul de control al personajului

Cel
mai
important
script
din
întreaga
aplica
ț
ie
este
cel
care
se
ocup
ă
de

comportamentul
personajului.
Acesta
trebuie
scris
de
c
ă
tre
programator.
Implicit,
Unity

ofer
ă
caracterului
posib ilitatea
de
deplasare
pe
axa
orizontal
ă
prin
intermediul
tastelor
„A”

pentru
înapoi
ș
i
„D”
pentru
înainte.
Dac
ă
se
dore
ș
te
ad
ă
ugarea
altor
taste
pentru
controlul

mi
ș
c
ă
rilor,
ad
ă
ugarea
de
mi
ș
c
ă
ri
noi
pe
alte
axe,
sau
schimbarea
comportamentului

deplas
ă
rii
standard,
acest
lucru
trebuie
personalizat
prin
intermediul
scripturilor
care
mai

apoi se ata
ș
eaz
ă
pe obiectele c
ă
rora li se adreseaz
ă
.

În
cazul
acestei
aplica
ț
ii,
utilizatorul
se
poate
mi
ș
ca
folosind
tastele
„W”
sau
„s
ă
geat
ă

sus”
pentru
sus,
„S”
sau
„s
ă
geat
ă
jos”
pentru
jos,
„A”
sau
„s
ă
geat
ă
stânga”
pentru
înapoi
ș
i

„D” sau „s
ă
geat
ă
dreapta” pentru înainte.

Personajul are definit
ă
o serie de valori folosite în interiorul acestei clase precum:

–
Viteza maxim
ă
de deplasare

–
Valoarea maxim
ă
a oxigenului

–
For
ț
a aplicat
ă
la deplasarea în sus
ș
i în jos

–
O list
ă
de obiecte care sunt considerate „sol”

–
O
component
ă
creat
ă
de
programator
ș
i
numit
ă
„groundCheck”
care
verific
ă
dac
ă

personajul este pe sol sau s-a desprins de acesta

Tot
acest
script
se
ocup
ă
de
oglindirea
imaginii
în
momentul
în
care
personajul

schimb
ă
direc
ț
ia
de
mers,
de
reducerea
num
ă
rului
de
vie
ț
i
la
coliziunea
cu
inamicii,
de

sc
ă
derea
constant
ă
a
oxigenului
în
timp,
de
stadiul
în
care
se
afl
ă
juc
ă
torul
în
ceea
ce

prive
ș
te
colectarea
obie ctivelor
în
fiecare
nivel,
precum
ș
i
de
declan
ș
area
mecanismelor
ce

constituie puzzle-urile.

6.3. Inamicii

În
acest
joc
exist
ă
mai
multe
tipuri
de
inamici,
statici
ș
i
dinamici,
vizibili
sau
ascun
ș
i.

Indiferent
de
tipul
acestora,
similaritatea
dintre
ei
este
aceea
c
ă
omoar
ă
personajul
când

intr
ă
în
contact
direct .
Pentru
a
executa
aceast
ă
ac
ț
iune
a
fost
creat
un
script
care

transport
ă
personajul
la
un
punct
din
care
acesta
trebuie
s
ă
reia
jocul.
Punctul
poate
fi
ori

cel de început al nivelului, ori unul intermediar, denumit „punct de control”.

Tipurile de inamici ce apar în joc sunt:

28

–
Ț
epii

–
Vârtejurile deasupra abisurilor

–
Pe
ș
tii balon

6.3.1.
Ț
epii

Sunt
reprezenta
ț
i
de
o
grupare
de
linii
verticale
ascu
ț
ite,
plasa
ț
i
pe
sol,
pe
pere
ț
i
sau

pe
tavan.
Fiind
inamici
statici,
logica
lor
este
destul
de
simpl
ă
,
mai
exact
la
coliziunea
cu

personajul
declan
ș
eaz
ă
moartea
acestuia.
Pentru
o
implemen tare
clar
ă
ș
i
u
ș
or
accesibil
ă
,
li

s-a
asociat
o
etichet
ă
în
fereastra
„inspector”
dup
ă
care
vor
fi
identificate
toate
elementele

din aceast
ă
categorie.

6.3.2. Vârtejurile deasupra abisurilor

Acest
inamic
este
compus
din
dou
ă
structuri.
Vârtejul
are
rolul
de
a
m
ă
ri
for
ț
a

gravita
ț
ional
ă
exercitat
ă
asupra
personajului
pe
toat
ă
durata
travers
ă
rii
acestuia,
ceea
ce

produce
senza
ț
ia
de
suc
ț
iune,
iar
juc
ă
torul
este
tras
în
adâncuri
unde
se
afl
ă
cel
de-al
doilea

element.
Abisul
ac
ț
ione az
ă
la
fel
ca
ț
epii
la
contactul
cu
personajul,
diferen
ț
a
dintre
cei
doi

fiind
c
ă
celui
dintâi
nu
îi
este
asociat
ă
nicio
imagine,
acesta
sem
ă
nând
cu
o
groap
ă
.
Prin

29

bifarea
c
ă
su
ț
ei
„Is
Trigger”
a
componentei
„Box
Collider
2D”
ata
ș
at
ă
acestui
inamic
i
se

permite
juc
ă
torului
s
ă
cad
ă
prin
acesta
ș
i
se
va
folosi
o
func
ț
ie
special
ă
de
detectare
a

interac
ț
iunii
dintre
cele
dou
ă
obiecte.
Ș
i
acestui
tip
de
inamic
i-a
fost
asociat
ă
aceea
ș
i

etichet
ă
ca
ș
i în cazul
ț
epilor.

6.3.3. Pe
ș
tii balon

Singurii
inamici
dinamici
din
aplica
ț
ie,
pe
ș
tii
au
proprietatea
de
a
se
deplasa
pe
o

traiectorie
între
un
punct
de
start
ș
i
un
punct
de
final
ce
pot
fi
u
ș
or
modificate
prin
simpla

tragere a acestora cu mouse-ul în pozi
ț
ia dorit
ă
.

Pentru
implementarea
acestui
comportament
a
fost
creat
un
script
care
ia
ca

argumente
dimensiunea
unui
vector
care
în
cazul
de
fa
ț ă
va
fi
doi,
obiectul
ce
va
ac
ț
iona
ca

punct
de
început,
cel
care
va
ac
ț
iona
ca
punct
de
sfâr
ș
it
ș
i
viteza
de
deplasare
pe
traiectoria

descris
ă
de
aceste
dou
ă
puncte.
Pentru
a
putea
fi
vizibil
utilizatorului,
trebuie
precizat
ș
i

obiectul
c
ă
ruia
îi
este
ata
ș
at
ă
ilustra
ț
ia
pe
care
se
afl
ă
de
altfel
ș
i
logica
pentru
moartea

personajului,
dar
ș
i
com ponenta
de
tip
„Polygon
Collider
2D”
necesar
ă
pentru
detectarea

coliziunii
dintre
cei
doi.
Ca
to
ț
i
inamicii
prezenta
ț
i
anterior,
eticheta
pe
ș
tilor
balon
va
fi

identic
ă
cu a celorlal
ț
i.

30

6.4. Punctele de control

Pe
m
ă
sur
ă
ce
utilizatorul
avanseaz
ă
ș
i
nivelele
devin
mai
complicate
ș
i
bineîn
ț
eles

mai
lungi.
Prin
urmare,
apare
necesitatea
salv
ă
rii
unor
puncte
intermediare
pentru
ca

juc
ă
torul s
ă
nu fie nevoit s
ă
parcurg
ă
întregul stagiu în eventualitatea în care pierde o via
ț ă
.

Acest
lucru
s-a
realizat
prin
implementarea
unor
puncte
de
control
care,
la
trecerea

caracterului
prin
ele,
î
ș
i
transmit
coordonatele
c
ă
tre
un
obiect
de
tip
„manager”
ad
ă
ugat
în

scena
corespunz
ă
toare
nivelului.
„Managerul”
actualizeaz
ă
pozi
ț
ia
la
care
va
trebui

amplasat
personajul
dup
ă
ce
acesta
moare.
Datele
furnizate
de
„manager”
sunt
utilizate
de

c
ă
tre
scripturile
ata
ș
ate
inamicilor,
dar
ș
i
de
c
ă
tre
scriptul
ata
ș
at
juc
ă
torului,
pentru

„învierea” acestuia.

31

În
cazul
în
care
utilizatorul
a
pierdut
toate
vie
ț
ile
alocate
scena
se
va
reînc
ă
rca
ș
i
va

trebui reluat nivelul de la punctul de start ini
ț
ial
ș
i colectate din nou obiectele.

6.5. Tutorialele

Pe
parcursul
jocului
sunt
prezente
ni
ș
te
elemente
ajut
ă
toare
sub
forma
unor
semne

de
întrebare
ce
con
ț
in
informa
ț
ii
utile
sau
sugestii
în
ceea
ce
prive
ș
te
controlarea

personajului
sau
prezentare
unor
elemente
noi
introduse
în
acel
nivel
sau
a

comportamentului acestora.

Obiectele
responsabile
de
afi
ș
area
acestor
informa
ț
ii
vor
activa,
la
coliziunea
cu

juc
ă
torul,
un
panou
unde
acestea
vor
fi
listate.
Scriptul
care
intermediaz
ă
procesul
este

ata
ș
at pe fiecare compo nent
ă
de tip tutorial
ș
i în fiecare caz trebuie specificate urm
ă
toarele:

–
Fi
ș
ierul text ce co n
ț
ine detaliile ce trebuie prezentate

–
Panoul în care va fi inclus textul

–
Obiectul de tip „Text” care va lua pe rând câte o linie din fi
ș
ier
ș
i o va afi
ș
a pe ecran

–
Indexul liniei de la care începe citirea fi
ș
ierului

–
Indexul
ultimei
linii
la
care
se
opre
ș
te
citirea.
În
cazul
în
care
se
dore
ș
te
afi
ș
area

întregului con
ț
inut, se va completa cu valoarea „0”.

În
situa
ț
ia
în
care
într-un
nivel
apar
mai
multe
astfel
de
elemente,
este
necesar
un

obiect
de
tip
„manager”
care
re
ț
ine
elementul
curent
ce
trebuie
s
ă
fie
activ.
Acest
lucru
este

posibil
datorit
ă
faptului
c
ă
la
coliziunea
personajului
cu
un
tutorial,
acesta
din
urm
ă
anun
ț ă

„managerul”
c
ă
se
poat e
trece
la
urm
ă
torul
obiect
de
acest
tip.
La
primirea
noii
valori,
se

actualizeaz
ă
câmpul
corespunz
ă
tor,
se
activeaz
ă
componenta
de
c
ă
tre
„managerul
de

tutoriale”
ș
i se inactivea z
ă
toate celelalte care fac parte din ac east
ă
categorie.

32

6.6. Cristalele

Pentru
a
putea
completa
nivelul
ș
i
trece
la
urm
ă
torul
stagiu
juc
ă
torul
trebuie
s
ă

adune
un
num
ă
r
de
obiecte,
în
cazul
de
fa
ț ă
cristale,
p
ă
r
ț
i
ale
unei
comori
pierdut
ă
în

adâncuri.
Cantitatea
ce
trebuie
colectat
ă
este
afi
ș
at
ă
pe
ecran
sub
form
ă
de
ilustra
ț
ii

transparente.
Când
utilizatorul
adun
ă
un
obiect,
imaginea
corespunz
ă
toare
acestuia
se

coloreaz
ă
pentru
a-l
în
ș
tiin
ț
a
în
permanen
ț ă
de
stadiul
în
care
se
afl
ă
în
ceea
ce
prive
ș
te

obiectivele r
ă
mase de cu les din nivel.

6.7. Poarta

Punctul
de
trecere
dintre
stagii
este
reprezentat
de
o
poart
ă
care
are
dou
ă
roluri,

fiecare compus din mai mul
ț
i pa
ș
i.

Primul
rol
este
acela
de
a
verifica
la
contactul
cu
personajul
dac
ă
acesta
a
adunat

toate
obiective
din
nivelul
curent,
mai
exact
cristalele,
prin
a
compara
num
ă
rul
celor

colorate cu num
ă
rul tota l ce trebuie adunat.

Al
doilea
rol
este
ca
în
cazul
ob
ț
inerii
unei
egalit
ă ț
i
între
cele
dou
ă
valori
s
ă
calculeze

punctajul
juc
ă
torului
în
func
ț
ie
de
scor
ș
i
de
num
ă
rul
de
vie
ț
i
pierdute
ș
i
s
ă
îl
salveze.
Dup
ă

aceast
ă
opera
ț
ie
trebuie
s
ă
deschid
ă
u
ș
a
prin
schimbarea
imaginii
asociate
acesteia
ș
i
s
ă

apeleze o func
ț
ie pentru trecerea la urm
ă
torul nivel.

33

6.8. Monedele

Scorul
ob
ț
inut
de
juc
ă
tor
este
actualizat
în
permane n
ț ă
în
func
ț
ie
de
num
ă
rul
de

monede
adunate,
fiecare
moned
ă
însumând
o
sut
ă
de
puncte.
Acestea
sunt
utilizate
în

prezent
pentru
calcularea
celui
mai
mare
scor
final
al
utilizatorului
între
sesiunile
de
joc.
În

ceea
ce
prive
ș
te
dezvolt area
ulterioar
ă
a
aplica
ț
iei,
ar
putea
fi
folosite
pentru
achizi
ț
ionarea,

dintr-un
magazin
online,
de
bunuri,
bonusuri
sau
a
ș
a
numitele
skinuri,
adic
ă
ilustra
ț
ii
noi
ș
i

mai
detaliate
ale
personajului
sau
ale
altor
elemente
din
joc.
Acest
aspect
poate
reprezenta

una din modalit
ă ț
ile de a produce capital prin intermediul pro gramului creat.

6.9. Sursele de oxigen

Deoarece
unele
nivele
sunt
mai
lungi
iar
personajului
i-ar
fi
imposibil
s
ă
le

completeze
din
cauza
rezervei
limitate
de
oxigen,
acesta
poate
întâlni
câteodat
ă
obiecte

care
fie
îi
vor
suplimenta
rezervorul
cu
o
cantitate
fix
ă
,
fie
îi
vor
permite
s
ă
îl
schimbe
cu

unul
nou
plin.
În
cazul
sursei
cu
volum
restrâns,
juc
ă
torul
trebuie
s
ă
se
a
ș
eze
pe
aceasta

pentru
a
beneficia
de
efectul
ei.
În
schimb,
în
ceea
ce
prive
ș
te
rezervorul,
acesta
se

colecteaz
ă
ca
orice
alt
obiect
din
aplica
ț
ie,
iar
la
coliziunea
cu
personajul
nivelul
oxigenului

este reini
ț
ializat la cel m axim.

34

6.10. Obstacolele

Pe
m
ă
sur
ă
ce
juc
ă
torul
avanseaz
ă
,
apar
puzzle-uri
cu
diferite
niveluri
de

complexitate.
Unul
dintre
acestea
este
reprezentat
sub
forma
unui
baraj.
Pentru
a
trece
de

partea
cealalt
ă
,
person ajul
trebuie
s
ă
îl
sparg
ă
cu
ajutorul
unui
obiect
din
interiorul

stagiului,
sub
forma
unui
explozibil,
care
uneori
este
vizibil,
iar
alteori
trebuie
c
ă
utat
pe
o

rut
ă
disponibil
ă
.

6.11. Mecanismele

Au
fost
implementate
dou
ă
tipuri
de
mecanisme
care
s
ă
îl
pun
ă
în
dificultate
pe

utilizator.

35

Primul
dintre
ele
este
o
reinterpretare
a
vârtejului
deasupra
unui
abis
prezentat

anterior.
În
acest
caz,
distan
ț
a
dintre
cele
dou
ă
margini
ale
solului
este
mult
prea
mare

pentru
ca
personajul
s
ă
poat
ă
traversa
f
ă
r
ă
s
ă
fie
absorbit
în
adâncuri.
Pentru
a
putea
trece

mai
departe,
juc
ă
torul
trebuie
s
ă
utilizeze
un
obiect
ajut
ă
tor.
Acest
obiect
este
reprezentat

de
o
platform
ă
care
poate
fi
împins
ă
peste
depresiune
iar
utilizatorul
poate
p
ă ș
i
peste

aceasta pân
ă
ajunge de c ealalt
ă
parte. POZE

Al
doilea
tip
de
mecanism
introdus
este
tot
unul
compus,
alc
ă
tuit
dintr-un
alt
tip
de

baraj,
o
platform
ă
care
îi
ac
ț
ioneaz
ă
deschiderea
la
a
ș
ezarea
unei
greut
ă ț
i
pe
aceasta
ș
i

greutatea
propriu-zis
ă
.
Platforma
poate
fi
activat
ă
ș
i
de
masa
personajului
atunci
când

acesta
se
plaseaz
ă
pe
ea,
îns
ă
barajul
se
închide
imediat
ce
greutatea
este
ridicat
ă
.
Astfel,

juc
ă
torul trebuie s
ă
se foloseasc
ă
de un obiect pentru a-l men
ț
ine deschis. POZE

6.12. Texturile

Implicit,
dup
ă
ad
ă
ugarea
în
scena
corespunz
ă
toare
unui
nivel
a
elementelor

necesare
din
punct
de
vedere
al
func
ț
ionalit
ă ț
ii,
aceasta
este
pustie
ș
i
lipsit
ă
de
con
ț
inut

deoarece
trebuie
îmbr
ă
cat
ă
cu
design.
Aceast
ă
etap
ă
presupune
utilizarea
unor
imagini
ce

poart
ă
denumirea
de
texturi.
Principala
lor
caracteristic
ă
este
aceea
c
ă
,
a
ș
ezate
unele
lâng
ă

altele,
în
orice
direc
ț
ie,
creeaz
ă
impresia
de
continuitat e
ș
i
nicidecum
de
elemente

individuale al
ă
turate.

6.13. Meniurile

Aplica
ț
ia
pune
la
dispozi
ț
ie
o
serie
de
meniuri
pentru
a
oferi
utilizatorului
mai
multe

posibilit
ă ț
i.
Printre
acestea
se
num
ă
r
ă
cea
de
a
pune
pauz
ă
,
de
a
relua
jocul
din
punctul
în

care
acesta
a
r
ă
mas
în
cazul
închiderii
programului,
de
a
reveni
la
meniul
principal
ș
i
de
a

opri sau porni sunetele de fundal din interiorul nivelelor.

Un
alt
meniu
este
afi
ș
at
dup
ă
finalizarea
jocului,
unde
sunt
afi
ș
ate
scorul
din

sesiunea
curent
ă
ș
i
cel
mai
mare
scor
ob
ț
inut
într-o
sesiune.
Pe
lâng
ă
acestea
se
ofer
ă
ș
i

dou
ă
butoane,
unul
pentru
ie
ș
irea
din
aplica
ț
ie
ș
i
un
altul
pentru
redirec
ț
ionarea
c
ă
tre

meniul principal. POZE – sunt deja ca wireframe

6.14. Crearea unui program executabil

Unity
furnizeaz
ă
dezvoltatorilor
op
ț
iunea
de
a
genera
un
program
care
s
ă
poat
ă
fi

lansat
pe
dispozitivele
utilizatorilor.
Aceast
ă
opera
ț
iune
presupune
selectarea
platformei

ț
int
ă
c
ă
reia
îi
este
adre sat
ă
aplica
ț
ia,
cu
posibilitatea
de
a
crea
fi
ș
iere
executabile
pe
rând

pentru
mai
multe
tipuri
de
platforme.
În
cazul
în
care
se
dore
ș
te
o
aplica
ț
ie
pentru
un

dispozitiv
mobil
sau
pentru
o
consol
ă
de
jocuri
video,
programatorul
trebuie
s
ă
se
asigure

c
ă
ofer
ă
celor
ce
vor
folosi
acest
produs
o
alternativ
ă
la
tastatura
computerelor
pentru

controlarea
personajului.
Dup
ă
acest
pas,
se
alege
dosarul
din
computer
unde
vor
fi
salvate

36

datele,
iar
motorul
grafic
export
ă
proiectul
ș
i
celelalte
componente
necesare
pentru
ca

aplica
ț
ia s
ă
poat
ă
fi lans at
ă
. POZ
Ă
?

37

CAPITOLUL 7. TESTAREA APLICA
Ț
IEI

Testarea
unei
aplica
ț
ii
înainte
de
lansare
este
o
etap
ă
esen
ț
ial
ă
pentru
orice
produs

software.

Pentru
a
putea
construi
o
clas
ă
de
teste
automate
cu
Unity,
în
zona
de
memorie
în

care
se
dore
ș
te
ad
ă
ugarea
ei,
trebuie
întâi
de
toate
creat
un
dosar
nou
ce
poart
ă
denumirea

de
„Tests
Assembly
Folder”.
Acesta
va
cuprinde
un
fi
ș
ier
inserat
automat,
„Tests
Import

Settings”,
cu
ajutorul
c
ă
ruia
se
pot
selecta
platformele
incluse
în
procesul
de
testare,
ș
i
toate

scripturile definite de c
ă
tre dezvoltator.

38