Elaborarea unui joc 3D cu ajutorul motorului Unirty3D.Proiec tarea intelegenței artificiale a unei [631415]

Universitatea Tehnică a Moldovei

ELABORAREA JOCULUI „UNUSUAL DERBY
RACIN G” CU AJUTORUL MOTORULUI UNITY 3D,
REALIZAREA INTERFEȚEI ȘI INTEGRAREA
MECANICII MAȘINII

CREATING THE GAME „U NUSUAL DERBY
RACING” WITH UNITY3D ENGINE, INTERFACE
IMPLEMENTATION AND M ECHANICAL
INTEGRATION OF THE C AR

Student: [anonimizat]: Lect.sup. Andrievschi – Bagrin Veronica

Chișinău 20 17

Ministerul Educației al Republicii Moldova
Universitatea Tehnică a Moldovei
Facultatea Calculatoare Informatică și Microelectronică
Departamentul Ingineri a Software și Automat ică

Admis la susținere
Șef de departament : dr. conf.univ. Ciorb ă D.
________________________________
„__”_____________ 2017

ELABORAREA JOCULUI „UNUSUAL DERBY
RACIN G” CU AJUTORUL MOTORULUI UNITY 3D,
REALIZAREA INTERFEȚEI ȘI INTEGRAREA
MECANICII MAȘINII

Proiect de licență

Student : _______________________________ __(Țurcanu Victor )
Conducător :____________ _____ __(Andrievschi – Bagrin Veronica )
Consultanți :____________________________ (Cojocaru Svetlana )
___________________ ______ ____ ____( Dodu Aliona )

Chișinău 20 17

Universitatea Tehnică a Moldovei
Facultatea Calculatoare, Informatică și Microelectronică
Departamentul Ingineri a Software și Automatică
Specialitatea Tehnologii Informaționale

Aprob
dr.conf.univ. Dumitru Ciorbă
șef de departament
___________________
„__”_____________ 2016

CAIET DE SARCINI
pentru proiectul de licență a l student: [anonimizat]

1. Tema proiectului de licență Elaborarea unui joc 3D cu ajutorul motorului
Unity3D. Proiectarea intelegen ței artificiale. “Unusual Derby Racing ” ____________
confirmată prin hotărârea Consiliului facultății de la „ 24” octombrie 2016
2. Termenul limită de prezentare a proiectului 31.05.2017

3. Date inițiale pentru elaborarea proiectului Sarcina pentru elaborarea proiectului de
diplomă .

4. Conținutul memoriului explicativ
Introducere
1 Analiza domeniului de studiu
2 Modelarea și p roiectarea sistemul informatic
3 Realizarea Sistemului
4 Documentarea produsului realizat
5 Evaluarea economică
Concluzii
5. Conținutul părții grafice a proiectului
Pornirea jocului, Evenimentele în joc, Posibilitățile unu -i user , Caracteristicile
inamicului , Acumularea unui scor , Afișarea scorului .

6. Lista consultanților:
Consultant Capitol Confirmarea realizării activității
Semnătura
consultantului (data) Semnătura
student: [anonimizat] , Controlul
calității

7. Data înmânării caietului de sarcini 01.09.2016

Conducător _________________________
semnătura

Sarcina a fost luată pentru a fi executată

de către student: [anonimizat] 01.09.2016
semnătura, data

PLAN CALENDARISTIC

Nr.
crt. Denumirea etapelor de proiectare Termenul de realizare a
etapelor Nota
1 Elaborarea sarcinii, primirea datelor pentru
sarcină 01.09.1 6– 30.09.1 6 10%
2 Studierea literaturii de domeniu 01.10.1 6– 30.11.1 6 20%
3 Alegerea și pregătirea de lucru a softului 01.12.1 6 – 25.12.1 6 20%
4 Realizarea programului 16.01.1 7 – 30.04.1 7 25%
5 Descrierea programului, diagramele UML 01.05.1 7– 15.05.1 7 10%
6 Testarea aplicației 16.05.1 7– 28.05.1 7 10%
7 Finisarea proiectului 29.05.1 7– 31.05.1 7 5%

Student Țurcanu Victor ( )

Conducăt or de proiect Andrievschi – Bagrin Veronica ( )

DECLARAȚIA STUDENTULUI

Subsemnatul(a) Țurcanu Victor , declar pe proprie răspundere că lucrarea de față este rezultatul
muncii mele, pe baza propriilor cercetări și pe baza informațiilor obținute din surse care au fost citate și
indicate, conform normelor etice, în note și în bibliografie. Decl ar că lucrarea nu a mai fost prezentată sub
această formă la nici o instituție de învățământ superior în vederea obținerii unui grad sau titlu științific ori
didactic.

Semnătura autorului
Semnatura conducătorului de licentă

Universitatea Tehnică a Moldovei
Facultatea Calculatoare, Informatică și Microelectronică
Departamentul Ingineria Software și Automatică
Specialitatea Tehnologii Informaționale

AVIZ
la proiectul de licență

Tema: Elaborarea unui joc 3D cu ajutorul motorului Unirty3D.Proiec tarea intelegenței artificiale a unei
mașini “Unusual Derby Racing ”
Studentul(a) Țurcanu Victor gr. TI -133
1. Actualitatea temei: Un joc video este un joc electronic în care se interacționează cu o interfață grafică
pentru a genera răspuns vizual pe un ecran. Jocurile video în general au un sistem de recompensare a
utilizatorului, de obicei se ține scorul, acest sistem depinzând de îndeplinirea unor anumite obiective în joc.
2. Caracteristica tezei de licență : Aplicația a fost creată pentru relaxarea per soanei în timpul său liber și
ridicarea dispoziției
3. Analiza aplicației: Analiza aplicației: Aplicația data este formată pentru efectuarea unui șir larg te
taskuri, pentru a arăta grafica, texturizarea, efectele și actualitatea intelegenței artificiale î n joc .
4. Estimarea rezultatelor obținute: Estimarea rezultatelor obținute: Acest program este creat pentru
relaxarea în timpul liber, prin joc cu inamici de gen Derby Racing, cu efecte diferite
5. Corectitudinea materialului expus: . Corectitudinea materi alului expus: Materialul expus este
prezentat prin referințe ale unor surse ce au fost scrise de persoane ce dețin experiența în domeniul
Tehnologiilor Informaționale și domeniul Game Development .
6. Calitatea materialului grafic: . Calitatea materialului grafic: Proiectul este prezentat prin: diagrame,
tabele, interfețe ale aplicației.
7. Valoarea practică a tezei: Valoarea practică a tezei Este destinat pentru utilizatorilor ce dețin
calculatoarele PC care rulează sistemul de operare Windows. Aceasta pr ogramă poate fi folosita de toate
vîrstele Windows.
8. Observații și recomandări: Observații și recomandări: Cerințele față de teza de licență au fost
îndeplinite în totalitate. Observații nu sunt. .
9. Caracteristica studentului și titlul conferit : Studentul Țurcanu Victor a dat dovadă de profesionalism
în elaborarea lucrării, a respectat cerințele impuse și a manifestat exigență în elaborarea și calitatea tezei de
licență. Din cele relatate, urmează că lucrarea de licență poate fi admisă spre susți nere.
Din cele relatate, urmează că lucrarea de licență poate fi admisă spre susținere, cu nota ______________

Conducătorul tezei de licență lector superior Andrievschi – Bagrin Veronica

Rezumat
Memoriul explicativ cu tema „Elaborarea jocului cu ajutorul mototului Unity3D ”, este o
documentație de descriere a aplicației . Partea principală la care s -a axat cea mai mare parte a atenției este
„Realizarea interfe ței și integrarea mecanicii mașinii ”. La general aplicația v -a fi denumită „ Unusual
Derby Racing ”.
Scopul aplicației create este deopotrivă o sursă de calm și relaxare în timpul liber, dar în același
timp este o sursă de stimulare a atenției și reacției.
Memoriul explicativ este descris în cinc i capitole în care putem observa proiectarea și realizarea
aplicației:
 Analiza domeniului de studiu, în care sunt descrise aspecte generale despre parțile împlicite în
dezvoltarea si utilizarea în domeniul jocurilor , abriviaturi obiective si descrierea
funcționalitaților ce trebuie împlinite;
 Modelarea și proiectarea sistemului informatic , în care sunt vizate elementele de modelare a
acestei aplicații ;
 Realizarea sistemului descrie instrumentele, mediul de dezvoltare și obiectivele;
 Documentarea produsul ui realizat conține informația despre cum utilizăm această aplicație ;
 Evaluarea economică a proiectului descrie evaluarea economică a programului, calculul costul
și beneficiul sistemului elaborat, descrierea situației curentă și situația după finisarea si stemului.
Efectuând acest proiect de curs am studiat un Editor nou, sub numele de Unity3D Editor care m -a ajutat
la crearea unui joc simplu 2D. El oferă un șir de funcționalități gata de utilizarea iar dacă acestea nu ne
convin, , putem implementa funcțion alitățile personale.
Pe lângă faptul că oferă un șir vast de funcționalități , mai are și o documentație bună și ușoară pentru
începătorii în industria dată.

Abstract
The explanatory memo with theme "Creating the game with Unity3D engine " is a description of
aplication . The main part which we focused the most of the attention is "Interface implementation and
mechanical integration of the car ". In general, the application is called " Unusual Derby Racing ".
The purpose of created application is a calm and relaxation source in leisure time, but also is a
source of stimulating attention, reaction.
The explanatory memo is described in five chapters where we can see the design and realization of the
application :
 Analysis of the field of study , that describes the general aspects of the parties involved in
development and deployment in gaming, abbreviations, objectives and description of
functionality has to perform;
 Information system design and design where are covered modeling elements of this appli cation ;
 Realization of the system , that describes the tools, environment and development targets;
 Documentation of the product , where we have information about how we use this application ;
 Economic evaluation of the project , that describes the economic eva luation of the program, the
calculation of cost and benefit system developed, the description of the current situation and the
situation after finishing system.
By doing this project , I studied a new Editor, named Unity3D Editor, whic h helped me to create
a simple 3 D game. It offers a number of functionalities ready for use, that can implement personal
functionalities.
In addition to offering a wide range of functionalities, it also has good and easy documentation
for beginners in the industry.

Cuprins
Introducere ………………………….. ………………………….. ………………………….. ………………………….. ………………………….. .. 10
1 Analiza domeniului de studiu ………………………….. ………………………….. ………………………….. ………………………….. .. 11
1.1 Comparația cu alte sisteme existente ………………………….. ………………………….. ………………………….. ……………….. 11
1.2 Cerințe funcționale ………………………….. ………………………….. ………………………….. ………………………….. …………… 13
2 Modelarea și proiectarea sistemul informatic ………………………….. ………………………….. ………………………….. ………. 15
2.1 Descrierea comportamentală a sistemului ………………………….. ………………………….. ………………………….. ………… 16
2.1.1 Imaginea generală asupra sistemului ………………………….. ………………………….. ………………………….. …………….. 16
2.1.2 Modelarea vizuală a fluxurilor ………………………….. ………………………….. ………………………….. …………………….. 20
2.1.3 Stările de tranzacție a sistemului ………………………….. ………………………….. ………………………….. ………………….. 22
2.1.4 Descrierea scenariilor de utilizare a aplicației ………………………….. ………………………….. ………………………….. … 25
2.1.5 Fluxurile de m esaje și legăturile dintre componentele sistemului ………………………….. ………………………….. ….. 27
2.2 Descrierea structural a sistemului ………………………….. ………………………….. ………………………….. ……………………. 29
2.2.1 Descrierea structurii statice a sistemului ………………………….. ………………………….. ………………………….. ……….. 29
2.2.2 Relațiile de dependență între componentele sistemului ………………………….. ………………………….. ……………….. 31
3 Realizarea sistemului ………………………….. ………………………….. ………………………….. ………………………….. …………… 34
3.1 Proiectarea bazei de date ………………………….. ………………………….. ………………………….. ………………………….. …… 35
3.2 Descrierea la nivel de cod ………………………….. ………………………….. ………………………….. ………………………….. …. 36
3.3 Testarea sistemului ………………………….. ………………………….. ………………………….. ………………………….. …………… 38
4 Documentarea produsului realizat ………………………….. ………………………….. ………………………….. …………………….. 40
4.1 Achiziționarea și folosirea aplicației ………………………….. ………………………….. ………………………….. ……………….. 40
4.2 Tastele de co ntrol a aplicației ………………………….. ………………………….. ………………………….. …………………………. 42
4.3 Componentele categoriei : Meniul utilizatorului ………………………….. ………………………….. ………………………….. … 42
4.4 Componentele categoriei Level Manager ………………………….. ………………………….. ………………………….. …………. 45
4.5 Componentele categoriei Mașină ………………………….. ………………………….. ………………………….. ……………………. 46
4.6 Componentele categoriei Obiecte secundare ………………………….. ………………………….. ………………………….. ……. 46
5 Evaluarea economică a proiectului ………………………….. ………………………….. ………………………….. …………………….. 48
5.2 Planul calendaristic în scopul optimizării volumui de timp și resurselor de muncă necesar pentru elaborare ….. 48
5.3 Analiza SWOT ………………………….. ………………………….. ………………………….. ………………………….. ………………… 52

UTM 526.2 .891 ME
Mod. Coala Nr. document Semnăt. Data
Elaborat Țurcanu V. Elaborarea jocului
„Unusual Derby Racing”
cu ajutorul motorului
Unity3D , realizarea
interfeței și integrarea
mecanicii mașinii Litera Coala Coli
Conducător Andrievschi
– Bagrin V. 8 86
Consultant S. Cojocaru UTM FCIM
TI– 133
Aprobat Ciorbă D .

5.4 Calculul indicatorilor economici ………………………….. ………………………….. ………………………….. …………………….. 53
5.5 Fișa de post ………………………….. ………………………….. ………………………….. ………………………….. ……………………… 59
Concluzii ………………………….. ………………………….. ………………………….. ………………………….. ………………………….. …. 62
Bibliografie ………………………….. ………………………….. ………………………….. ………………………….. ………………………….. . 63
Anexa A (CarEngine ) ………………………….. ………………………….. ………………………….. ………………………….. …………….. 64
Anexa B (CarControl ) ………………………….. ………………………….. ………………………….. ………………………….. ……………. 66
Anexa C (CameraControl ) ………………………….. ………………………….. ………………………….. ………………………….. ………. 68
Anexa D (PlayerCar ) ………………………….. ………………………….. ………………………….. ………………………….. ……………… 70
Anexa E (VehicleDamage ) ………………………….. ………………………….. ………………………….. ………………………….. ……… 72
Anexa F (VehicleWaypoint ) ………………………….. ………………………….. ………………………….. ………………………….. …… 74
Anexa G (GasMotor ) ………………………….. ………………………….. ………………………….. ………………………….. ……………… 75
Anexa H (VehicleParent ) ………………………….. ………………………….. ………………………….. ………………………….. ……….. 77
Anexa I (FollowAI ) ………………………….. ………………………….. ………………………….. ………………………….. ……………….. 79
Anexa J (FlipControl ) ………………………….. ………………………….. ………………………….. ………………………….. …………….. 81
Anexa K (Imagini adi ționale a proiectului ) ………………………….. ………………………….. ………………………….. ……………. 84

UTM 526.2 .891 ME Coala

9 Mod. Coala Nr. document Semnăt. Data

10
Introducere
Jocurile de computer constituie o categorie de aplicații software care este destinată distracției, unele
din ele po t fi chiar și educaționale. Încă din copilărie, invățăm să comunicăm, să interacționăm cu lumea ce
ne inconjoară prin intermediul jocului . Începînd cu prima etapă de formare a modului de gîndire, întîlnim
noi modalități de a ne adopta l anțului de provocări pe care viața le pregătește . În primul rînd, atunci cînd
suntem puși în fața unor situații reale,co tidiene, metoda prin care mintea unui copil le ințelege este jocul.
Această practică este deopotrivă o sursă de calm și relaxare, dar și o sursă de stimulare a creierului
și a corpului. Jocul este descris adeseori ca modalitatea de petrecere a timpului cea mai vioaie, deși de multe
ori îl luăm în serios și putem uita în totalitate de el.
Un studiu similar, desfasurat la York University, a descoperit că jocurile pe calculator pregătesc
creierul pentru activități diverse ce presupun o coordonare mîini -ochi (o chii văd, mîinile execută).
Un studiu a demonstrat la dislexici îmbunătățirea înțelegerii de lectură în urma sesiunilor de jocuri
grele pe acțiune. Motivul, cercetătorii cred, este faptul că jocurile au schimbat în mod constant mediile care
necesita concen trare intensă.
În ziua de azi crearea jocurilor 2D -3D este facilitată datorită limbajelor de programare
superioare(C++,C#, Java) și motoarelor grafice (Unity3 D,Unreal Engine) care ușurează calea spre
dezvoltarea acestora.
Un motor grafic este un sistem co nceput pentru crearea și dezvoltarea de jocuri video. Există mai
multe motoare de joc, care sunt proiectate să funcționeze pe console de jocuri video și calculatoare
personale. Funcționalitatea de bază oferită de obicei de un motor grafic include un motor de randare
(engleză renderer) pentru grafică 2D sau 3D, un motor de fizică sau de detectare a coliziunilor (și răspunsul
la coliziune), sunet, scripting, animație, inteligență artificială, în rețea, streaming, memorie de management,
suport de localizare. D ezvoltatorul este predispus să aleagă motorul care îi convine pentru a dezvolta jocuri
de înaltă calitate.
Scopul aplicației create este deopotrivă o sursă de calm și relaxare în timpul liber, dar în același
timp este o sursă de stimulare a atenției, reacției.
Jocul a fost creat cu ajutorul motorului grafic Unity3D, și limbajului de programare orientat pe obiecte C#.

11
1 Analiza domeniului de studiu
Alegerea Unity3d engine pentru crearea proiectului meu, la moment un joc este o alegere foarte
buna.Uni ty ofera o gama mare de posibilitati pentru elaborarea prezentarilor, proiectelor intelectuale,
jocurilor etc.
Un joc video este un joc electronic în care se interacționează cu o interfață grafică pentru a genera
răspuns vizual pe un ecran. Jocurile video în general au un sistem de recompensare a utilizatorului, de
obicei se ține scorul, acest sistem depinzând de îndeplinirea unor anumite obiective în joc.
Jocurile au fost întotdeauna mai ușor de clasificat după genul lor, din cauza constrângerilor tehnice a
diferitelor platforme, cum ar fi cele legate de spațiul alocat jocurilor.
Odată cu trecerea anilor și creșterea banilor destinați producției jocurilor video, valoarea comercială a
crescut iar cererea de talent creativ a obligat companiile să aducă artișt i din af ara industrei de specialitate.
Refolosirea unor anumite genuri este cel mai bine observată în încercarea de a stabili "francize", care
de obicei folosesc aceleași caractere, situații, conflicte și teme de -a lungul continuărilor.
1.1 Compara ția cu alte sisteme existente
Jocurile pe timpul de azi sunt create pe baza a mai multor sisteme / motoare. În anii trecuți,
programatorii pentru a crea un joc de platforma, creau si inventau sistemele de la zero. Acum, este prezentă
o gamă largă de sisteme creat e, care oferă un mare ajutor pentru viitorul joc. În aceste sisteme poți ușor
manipula cu crearea mecanicii a proiectului, și ansamblarea grafică a lui. În timpul de față sunt create o
sumedie de texturi, obiecte, shaderuri, etc.
Sistemele folosite în ziu a de azi pentru crearea jocurilor sunt : Unreal Engine, Unity3D , Build
Engine, Boom, Flash, Construct2D, Cube și altele.

Figura 1.1 – Cele mai populare motoar e de crearea jocurilor în timpul de azi

12
Motoarele populare în ziua de azi:
– dx sudio – un motor de joc gratuit cu un set complet de instrumente pentru a dezvolta jocuri video ,
versiunea actualizată a sistemului de apărare antirachetă pentru a avea acces la caracteristici
suplimentare;
– game maker – un motor de joc gratuit orientate atât pentru începăt ori cât și cei care nu știu cum să
program , upgrade de plătit oferă sprijin direct pentru 3D, precum și capacitatea de a rula cod native;
– stencyl – versiune gratuită vă permite să creați Flash -jocuri;
– neo axis motor de joc – un motor 3D multi -scop pentru Windows și Mac OS X, cu posibilitatea de
a publica pe web, acesta este utilizat pentru simulare, vizualizare, și jocu ri, gratuit pentru uz
commercial;
– engine -ul Source SDK – pentru a crea modificări ale moto rului, Sursa , Valve freeware pe Steam
pentru toți jucătorii care au cumpărat orice sursă joc de la Valve , concomitent cu lansarea jocului
Alien Swarm Valve furnizat pentru a descărca SDK , inclusiv codul sursă colectat , acesta este gratuit
pentru toți utili zatorii de abur, în contrast cu SDK pentru alte jocuri pe motor, sursa , acest lucru
permite o conversie totală nu depinde de alte jocuri Va lve și să fie liber pentru toți;
– unity 5.3.3p – un motor de joc multi -platformă nu este conceput pentru un stil speci fic de jocuri
pentru Windows, Mac OS X și Linux, v ersiunea gratuită este oarecum limitat în comparație cu
PRO -versiune , suportă iOS, Android, Nintendo Wii, PlayStation 3, Play Station 4, Xbox 360 și
Xbox One;
– unreal engine 4 / UDK – UE3 este considerat în continuare cel mai popular motor de nivel superior
de joc, Epic Games a lansat o versiune gratuită numit UDK (eliberare binară a motorului), care vă
permite să folosiți motorul pentru crearea de jocuri non -profit și aplicații gratuite , comercial poate
fi, de ase menea, în anumite condiții;
– cryengine 3 SDK – CryEngine 3 – un motor de noua generatie dezvoltat de Crytek pentru a crea
jocul Crysis 2, Crysis 3 și Warface;
– blender motor de joc (BGE) – motor de joc gratuit, care este distribuit împreună cu pachetul de
Blender 3D -modelare.

Alegerea mea a fost Unity, deoarece este un motor, destul de u șor în utilizare,efectuarea unor
lucruri stabile și interesante și în comparație cu altele Unity este unul dintre cele mai utile și disponibile
motoare de proiectare ș i crearea jocurilor.
Drept urmare, deși multe jocuri sunt o combinație de mai multe genuri, există foarte puține cele care
nu se încadrează în tiparele obișnuite, care atunci când au succes de obicei definesc un nou gen.

13
Un joc care lansează un nou gen poate să nu fie primul de acel tip ci poate fi primul care are
îndeajuns de mult succes comercial pentru ca alte companii să încerce să reproducă acel succes. Exemple
ca Super Mario 64 care a lansat genul jocurilor video de platformă pentru console sau Doom care a lan sat
genul First-person shooter pentru PC. Există și combinații de genuri cum ar fi jocurile de genul Massively
multiplayer online role -playing game (MMORPG).În vârful piramidei industriei se află organizațiile
multinaționale care creează hardware -ul: Nintendo, Microsoft și Sony.
Nintendo este o companie care se ocupă numai de jocuri, iar consolele și dispozitivele portabile pe
care le creează (precum Wii și DS) reprezintă principala activitate a companiei.
În cazul companiilor Sony și Microsoft lucrurile stau cu totul altfel, con solele pe care acestea le
creează (PlayStation 2/PlayStation 3 și respectiv Xbox/Xbox 360) reprezentând doar o parte a gamei vaste
de produse de consum ale acestora.
Din ce în ce mai mulți operatori de telefonie mobilă încearcă de asemenea să furnizeze „p latforme”
hardware care să poată fi folosite pentru a fi jucate jocuri pe produsele lor .
Deși Nintendo, Microsoft și Sony își creează propriile jocuri sau au cumpărat studiouri de creație
pentru realizarea de jocuri pentru platformele lor specifice, acești a nu sunt singurii actori din industrie.
Producătorii terți cum ar fi Electronic Arts, Ubisoft și Capcom sunt companii producătoare externe care
vând jocurile create în studiourile de creație proprii sau independente.
Adevărații independenți reprezintă te renuri propice pentru industrie, deoarece ei pot crea pentru
orice producător.
Desi nu am prea avut ocazia sa folosesc Unity pentru prototyping la munca, este alegerea mea pentru
proiectele personale, atunci cand am timp pentru ele acasa.
Il folosesc in combinatie cu pluginul de visual scripting PlayMaker pentru a crea mici ‘jucarii’ care
au potentialul de a deveni ceva mai mult la un moment dat.
Unity Technologies, firma care a creat acest pachet software,lansat pe piata cu jocuri care sa le
popularizeze engine -ul si pachetul de development. Cu toate acestea, au reusit intr -un timp relativ scurt sa
revolutioneze domeniul prototyping -ului si dezvoltarii de jocuri cu Unity.
1.2 Cerințe funcționale
În timp ce unii dintre aceștia își concentrează atenția asupra jocurilor de consolă de mari dimensiuni,
care necesită un înalt nivel tehnologic, alții se concentrează pe jocuri dezvoltate rapid pentru dispozitive
portabile sau telefoane mobile.
Independenții pot fi echipe mici având în jur de 20 de persoane sa u companii mari cu mai mult de
200 de angajați în diferite locații din țară sau chiar din lume.

14
Cei care au avut cel mai mult succes au devenit companii puternice capabile să dispună de mai multe
echipe pentru a lucra simultan la mai multe proiecte.

Generalități :
– denumirea complet ă a sistemului și abrevierea – Derby Race;
– denumirea organizației executoare – Universitatea tehnică a Moldovei;
– beneficiarul aplicației – oricare utilizator care are în posesie dispozitv pe platforma android;
– lista documente lor în baza cărora este creat sistemul – servicii, insrtuemente, resusrse API, pentru
dezvoltarea aplicațiilor pe platforma Unity;
– infomații despre surse și modalitatatea de finațare – aplicația nu prevede cheltuieli financiare sau
intocminrea unui buget anumit;
– ordinea de perfectare și prezentare a rezultatelor creării SI, părților sistemului sau a unor module
separate -prezentarea rezultatelor efectuării sarcinilor propuse va avea loc săptămânal până la data
limită prestabilită la catedră.
Scopul aplicaț iei create este deopotrivă o sursă de calm și relaxare în timpul liber, dar în același
timp este o sursă de stimulare a atenției, reacției.
Jocul a fost creat cu ajutorul motorului grafic Unity3D, și limbajului de programare orientat pe
obiecte C#.
Scopul realizării acestei lucrări este de a implementa un mini joc 3D din categoria Action/Race Car
unde va fi prezentă o mașină care va trebui să omoară alte mașini care tot la randul lor o să se străduie să
ne nimicească.
Reeșind din documentarea Unity , unde este descris succind denumirea de intelegenț ă artificială ca
o modalitate de proiectare a acestui sistem în jocuri , deduce folosirea termenului dat la crearea proiectelor.
[1]
În cercetarea tradițională în domeniul AI a obiect ului este de a oferi o inteligență artificială . În
proiecte, cum ar fi Kismet Massachusetts Institute of Technology (MIT), este o încercare de a crea un AI
capabil de învățare și de interacțiune socială, la manifestarea emoțiilor.
În ceea ce privește jocurile adevărate AI -ul es te cu mult aparte de cerințele proiectului de software
de divertisment. În jocuri nu este nevoie de o astfel de putere. El nu are nevoie să învețe nimic dincolo de
domeniul de aplicare al jocului.
Scopul real al AI în jocuri este de a simula un comportament inteli gent și de a oferi jucătorului un
convingător sistem .
Deci o să fie o mașină cu ajutorul careia o să nimici alte mașini pentru a obține un scor cât mai mare.
Funcționalitatea inamicilor depinde de sistemul AI (Artificial Intelleigence), iar scopul lor va fi de a ne
nimici. Pentru a observa cel mai simplu mode l de intelegen ță artificială, vezi figura K.4 din anexă .

15
2 Modelarea și proiectarea sistemul informatic
Modelarea sistemelor constituie un principiu de bază în inginerie și în științe sociale .Un model (în
contextul studiului sistemelor) este definit ca o reprezentare conceptuală (abstractă) a unui sistem care
reproduce și descrie artificial sistemul original existent, care permite studierea sistemului, servind astf el
pentru cunoașterea proprietăților sistemului original și predicția comportării acestuia.
Enterprise Architect reprezintă un instrument CASE pentru proiectarea și modelarea produselor
soft. EA susține specificațiile UML 2.0, descris ca un limbaj vizual, prin intermediul căruia se pot defini
modelele proiectului.

Unele din principalele funcții ale Enterprise Architect sunt :

– crearea elementelor modelelor UML pentru uz general;
– utilizarea acestor elemente în diagrame și pachete;
– documentarea elementelor create;
– generarea codului;
– reverse -inginiering codului în diverse limbaje de programare;
– altele etc.
Din modelele create, se pot crea cu ușurință documentația în formatul rtf. Altă oportunitate este de a
importa documentația într -un document Microsoft Wo rd pentru editarea finală a acesteia, la fel este
disponibil generarea documentelor HTML.
EA susține toate modelele și diagramele UML 2.0. Cu ajutorul lui se permite modelarea unor procese
business, site -urilor web, interfețele de utilizare, rețele, mesa je etc., aprecierea volumul de timp pentru
lucrările de proiectare, fixarea și monitorizarea cerințelor, resurse, test -planuri, defecte și cereri de
modificare.
Arhitectural Enterprise EnterpriseArchitect este un instrument actual și multifuncțional de ana liză și
proiectarea sistemelor informaționale orientate pe obiecte. Comparativ cu sistemul Rational Rose,
funcționalitățile sau extins considerabil, ceia ce permite modelarea mai eficientă a sistemelor
informaționale.
EnterpriseArchitect este un mediu pri etenos de modelare, cu o interfață actuală nivelului de dezvoltare
a tehnologiilor informaționale. El permite proiectarea sistemelor informaționale anterior procesului de
realizare. La fel se susține și vizualizarea posibilităților funcționale ale sistemul ui.
Limbajul UML reprezintă limbajul de destinație generală al modelării vizuale, care este elaborat pentru
specificarea, vizualizarea, construirea și documentarea componentelor produsului soft, business -proceselor
și altor sisteme. Totodată limbajul UML este un mijloc de modelare simplu și puternic care poate fi utilizat
efectiv pentru construirea modelelor conceptuale, logice și grafice ale sistemelor complexe de diferită

16
destinație. Acest limbaj conține cele mai bune calități ale metodelor ingineriei de prog ram care au fost
utilizate cu succes pe parcursul ultimilor ani la modelarea sistemelor complexe.
2.1 Descrierea comportamentală a sistemului
Prin descrierea comportamentală se înțelege viziunea persoanei prin metoda schematică de a descrie
sitemul. Pentru a descrie comportamentul unui sistem sunt folosite diagramele UML.
Diagramele UML, oferă o gamă enormă de posibilități, pentru a descrie com portamentul
sistemului.În capitolul dat vor fi descrise succind prin reprezentarea diagramelor urm ătoarele
comportamente a sistemului :
– imaginea generală asupra sistemului;
– modelarea vizuală a fluxurilor;
– stările de tranzacție a sistemului;
– descrierea scenariilor de utilizare a aplicației ;
– fluxurile de mesaje și legăturile dintre componentele sistemului.
2.1.1 I maginea generală asupra sistemului
Imaginea generală a sistemului este descrisă de diagrama cazurilor de utilizare, care descrie
funcționalitatea oferită de sistem din perspectiva actorilor, a scopurilor lor reprezentate și cazuri de
utilizare și a oricăror dependente dintre aceste cazuri (în UML).
Modelarea vizuală în UML poate fi reprezentată ca un oarecare proces de lansare pe nivelu ri de la cel mai
general și abstract model conceptual al sistemului inițial către model logic și mai apoi fizic, ce corespunde
unui sistem de program.
Pentru atingerea acestui scop de la început se creează un model în formă de diagrama cazurilor de
utiliz are (use case diagram) care descrie destinațiafuncțională a sistemului sau cu alte cuvinte descrie ceea
ce sistemul va executa în procesul său de funcționare. Diagrama cazurilor de utilizare reprezintă un model
inițial conceptual al unui sistem în procesul de proiectare și exploatare.
Proiectarea a unei diagrame a cazurilor de utilizare urmărește scopurile următoare:
– determinarea limitelor comune și a contextului domeniului de modelare la etapele inițiale de
proiectare a unui sistem;
– formularea cerințelor c omune către comportare funcțională a sistemului proiectat;
– elaborarea modelului inițial conceptual al unui sistem pentru detalierea de mai târziu în forma
modelelor logice și fizice;
– pregătirea documentațieiinițiale pentru interacțiunea elaboratorilor unui sistem cu clienții și
utilizatorii.

17
În caz general, diagrama cazurilor de utilizare reprezintă un graf deosebit, care este o notație grafică
pentru prezentarea cazurilor de utilizare concrete, actorilor, poate și a unora interfețe și pentru prezentarea
legăturilor între aceste elemente.
Totodată componente aparte ale diagramei pot fi incluse într -un dreptunghi, care semnifică sistemul
proiectat în întregime. Trebuie de specificat că legăturile acestui graf pot fi de numai anumite tipuri de
interacțiuni între actori și cazuri de utilizare, ca re împreună descriu servicii și cerințefuncționale către
sistemul modelat.
În cadrul sistemul se poate evidenția următoarea diagramă din figura 2.1. Aici, se definesc
principalele funcționalități ale userului odată cu lansarea aplicației. Utilizatorul are posibilitatea de a starta
joaca, efectua oarecare op țiune și de a ieși din aplicație.

Figura 2.1 – Posibilitatile unu -i User
În figura nr 2.1 sunt descrise posibilitățile de bază a unui user. Din diagramă se observă că userul
principal, pînă la intrarea în joc, are la dispoziția sa o gamă largă de funcționalități.
În prima parte a diagramei este descris userul care are acces la cele 4 părți a meniului :
– Start – este partea cea mai principală care oferă userului o posibilitate de a intra în joc;
– Options – sunt setările jocului;
– Exit – ieșirea din joc.
Submeniul Start , după acce sarea lui, are la dispoziția sa 2 submeniuri ale sale, SinglePlayer și
MultiPlayer .
uc Actors
UserAccesarea Options
Accesarea ExitPornirea jocului

18
Diagrama următoare v -a arăta posibilitățile userului la pornirea aplicației , din modul SinglePlayer .
Așadar, userul după lansarea aplicației are posibilitatea de a distruge inamic i, de a acceler a, frîna, întoarce
dreapta, întoarce stînga și accesarea butonul ui de pauză a jocului
Pentru a înțelege caracteristicile ale unui inamic, vezi figura 2.2, care v -a descrie aceasta.

Figura 2.2 – Pornirea jocului

Figura 2.2 descrie oportunitățile userului la pornirea jocului. Acestea ajută la lupta cu inamicii săi.
Inamicii sunt dușmanii personajului principal cu care el interacționează în joc. Ceea ce este descris în
diagramă, sunt caracteristicile principale ale inamicului.
Aceste sunt :
– atacarea prin atingere;
– urmărirea pesrsonajului principal ;
– atacarea prin ating ere.
Inamicii sunt dușmanii, care datorit ă vitezei și puterei sale deteriorează personajul principal pînă la
destrugerea completă a lui.
uc UserCase 2
User
FrineazaPornirea Jocului Accesarea Pause Distruge inamic
Accelereaza
Intoarce dreaptaIntoarce stinga«include»«include»
«include»
«include»«include»«include»

19
Intelegența artificială în joc se înțelege prin mișcarea inamicului datorit ă nodurilor, dupa un ciclu
anumit.
Aceasta se presupune cel mai simplu model de intelegență artificială prin care noi formăm o clasă,
care va fi atașată inamicului și va lucra obiecte invizibile create în scen ă numite noduri. Aceste noduri vor
fi urmărite de catre inamic și va forma un cilcu de mi șcare.
Path este o cale unde sunt amplasate nodurile. Inamicul urmărește fiecare nod în parte, astfel creînd
un model de intelegență artificială ciclică, începînd de la puncul de start, pînă la punctul de destinație.
Jocul dat oferă ca exemplu două tipuri de intelegență artificială. Cel simplu este mișcarea ciclică în
scenă , iar celălalt, va oferi o posibilitate de a u rmări persojalul, pentru a îl destruge .
În figura următoare sunt descrise particularitațile principale ale jocului. Levelul este considerat
scena însuși prezentată în aplicație, unde se petrece toate evenimente. Totul ce este prezent în timpul jocului,
este încadrat în scenă sub nume de Level . Pentru a observa aceasta scena, vezi figura K.2 din anexă.
Între timp ce este rulată aplicația și jocu l este pornit, userul are posibilitate de a primi un oarecare
scor în joc, este prezentat un timer care indică timpul necesar a jocului și finisare jocului în cadrul care
acest timp este finisat sau userul a fost destrus de inamici.
Vezi figura 2.3 pentru a observa evenimentele jocului.

Figura 2.3 – Evenimentele jocului
uc UserCase 3
User
PrimireGameOv erRuleazaLev el ScadereTimpStartareaLev elPrimireScor
«include»«include»«include»
«include»

20
2.1.2 Modelarea vizuală a fluxurilor
Modelarea vizuală a fluxurilor este descrisă de diagrama de activități. Diagrama de activități
reprezintă o modalitate de modelare vizuală a fluxurilor. Cu ajutorul diagramelor de activități pot fi
modelate foarte bine use case -urile, dar, în aceeași măsură, aceste diagrame pot fi folosite pentru modelarea
proceselor de business (fără legătură cu sistemul informatic).
În privința notațiilor, acestea sunt fo arte asemănătoare cu cele din diagrama de stari. Elem entele
utilizate sunt descrise în continuare: activitate, acțiune, stare inițială, stare finală, tranziție, decizia, condiție,
bara de sincronizare și culoarea sau partițiile.
Pentru a începe rularea aplicației, userul trebuie sa utilizeze o serie de activități . Esența principală a
userului în timpul rulării aplicației este de a căuta inamicul și de al destruge . Așadar urmărim pașii principali
pînă la nimicirea inamicului de către user:
– accesarea start din meniul principal al aplicației ;
– pornirea jocului;
– manipularea mașinei;
– căutarea inamicului.
Vezi figura 2. 4, ce descrie autentificarea userului sau a personajului în scenă pentru a continua jocul
mai departe.

Figura 2. 4 – Căutarea inamicului
Pentru a începe orice joc, userul alege personajul sau obiectul pe care el îl va manipula în proiect .În
figura urmatoare se va de scrie schema generală pînă la intrarea în joc și după, unde se vor schimba
proprietațile mașinei. Vezi figura 2.5 pentru a observa sch imbarea propriet ăților mașinei, adică deteriorarea
ei.
act EnemySeach
Pornirea jocului Accesarea Start
CautareaInamicManipulareaMasinei

21

Figura 2. 5 – Deteriorarea mașinei
Figura 2.5 descrie modalitatea de schimb și alegerea a proprietăților mașinei. Pentru aplicarea sau
schimbarea proprientăților mașinei, sunt aplicate anumiți pași de efectuare. Acești pași de interacționare a
userului cu setările mașinei sunt, începînd de la selectarea submeniului principal SinglePlayer, continuînd
cu selectarea mașinei și manipularea ei . În timpul manipulării mașinei, user întîlnește obstacole și i namici
în calea sa, care pot deteriora automobilul pînă la întreaga destrugere a lui.
În joc, deasemenea este prezent și scorul, adică punctajul pe care îl acumulează userul într -un
moment de timp anumit. În diagrama următoare vor fi prezente două cazuri. Primul caz constă în
destrugerea inamicilor și acumularea scorului, iar cel de al doilea caz constă în deteriorarea mașinei userului
și pierderea în joc. Esența principală a aplicației este de a acumula cît mai multe puncte și de a rămîne cît
mai mult tim p în viață.
Vezi figura 2.6 pentru a vedea mai detaliat și schematic, primirea sau acumularea unui scor .

22

Figura 2. 6 – Primirea scorului
2.1.3 S tările de tranzacție a sistemului
Stările de tranzacție a sistemului sunt reprezentate de diagrama de stare, care descrie stareaa
sistemului. Diagrama de stare ( State Diagram , Statechart ) a unei clase reprezintă stările pe care obiectele
(instanțe) ale clasei le pot avea și tranzițiile înt re aceste stări. Diagrama de stare este utilă pentru descrierea
claselor care au unul sau mai multe atribute ale cărui valori au semnificații precise și modificarea acestor
valori implică diferențe de comportare a obiectelor.
Diagrama de stare folosește m ai multe elemente (simboluri) ale limbajului UML O stare a unui
obiect se reprezintă printr -un dreptunghi cu colțurile rotunjite în care se înscrie denumirea stării obiectului.
Starea inițială (Initial State) se reprezintă printr -un cerc plin. O tranziție între două stări se reprezintă printr –
o linie continuă care are o săgeată la capătul dinspre starea finală a tranziției. Lângă o linie de reprezentare
a unei tranziții se poate înscrie numele metodei care provoacă tranziția sau condițiile (în funcție de va lori
ale atributelor) care produc tranziția respectivă. Starea finală este reprezentata printr -un cerc plin inclus
act Activ ity
EnemyTouchingGettingCar
GettingScoreDestroyEnemy HP Decreasing
DestroyActor[ScoreGet][IsWinning] [IsLoosing]

23
intr-un alt cerc gol.Cu toate ca notatia pentru star ea iniți ală include numai cercul plin, in practica starea
initiala include si sageata car e pleca din ea si starea in care obiectul este creat.
La sfarsitul vietii sale (activitatii sale) obiectul atinge starea finala din care nu mai poate iesi. Starea
finala are toate proprietatile unei stari, cu o exceptie: nu poate avea tranzitii de iesire. Numele starii de iesire
este specificat langa simbolul grafic al starii finale.
Starea curenta a unui obiect este reflectata in valorile atributelor care descriu obiectul. Acestea
includ si legaturile existente intre obiect si alte obiecte.
Diagramele de stări modelează efectul acestor interacțiuni asupra stării interne a fiecărui obiect.
În figura 2.7 este reprezentată starea aplicției la general . Jocul dat, poate fi repartizat în 3 stări :
 startgamescreen, unde este este prezent momentul de acces al aplicației ;
 game play, momentul în care aplicația este rulată;
 game over, starea finală a jocului.
Vezi figura 2.7, pentru a observa mai detaliat detaliile.

Figura 2.7 – Starea aplica ției

În figura 2.7 este observat descrierea mișcării a inamicilor, pen tru a ataca. La momentul de start, inamicii
apar în scenă și sunt în momentul de mișcare sau InNeutral .
Următorul pas al inamicilor este căutarea sau urmărirea altor dușmani ceea ce înseamnă ca se află
în momentul de InAttack .
După ce dușmanul a fost găs it, urmează următorul pas, care la rîndul său este confruntarea dintre
două obiecte în scenă.
Pentru a observa mai detaliat detaliile userului vezi figura 2.8
stm Game
InceputStart GameScreen Game Play
GameOv ergame on

24

Figura 2. 8 – Stările userului
Următoarea diagramă constă în valorificarea momentului de confruntare a inamicilor. Figura
2.9 arată însăși procesul de confruntare la general, începînd cu momentul în care mașina este întreagă și
finisînd cu starea de destrugere completă a ei. Deteriorarea în joc are lor prin tamponarea sau confruntarea
prin împ ingere a mașinelor .
Pentru a vedea mai detali at și schematic momentele de viață a mașinei, vezi figura 2.9

Figura 2.9 – Primirea unui scor

Diagrama dată reprezint ă trei momente ale mașinei. P rimul moment Car Alive, care reprezintă
mașină fară nici o deteriorare și prezența maximă a punctelor de viață. Al doilea moment este caracterizat
datorită CarDamaged, care arată că userul a primit careva deteriorări datorită oponenților săi sau
obstacolelor întîlnite. În final este descris starea CarDestroyed, ca re indică deteroarea completă a mașinei.
stm UserState
InNeutral InAttack
LostOpponentsee opponent
[defeatable]
stm CarState
CarDamagedCarAliv e
CarDestroyed

25
2.1.4 Descrierea scenariilor de utilizare a aplicației
Descrierea scenariilor de utilizare a aplicației este reprezentată de diagrana de secvență. O diagramă
a secvențelor (Sequence Diagram ) este o diagramă de interacțiu ne în care se pune accentul pe ordinea
temporală a mesajelor schimbate între obiecte, ceea ce oferă o bună înțelegere a comportării sistemului.
În diagrama secvențelor pe axa verticală se reprezintă timpul, cu valori crescătoare în josul paginii,
iar pe a xa orizontală se reprezintă o listă de obiecte între care au loc transferuri de mesaje. Fiecare obiect
din lista de obiecte ale diagramei marchează o linie verticală de timp de viață ( Object Lifeline ), până la care
ajung mesajele destinate obiectului respe ctiv
Obiectele se reprezinta ca si în diagramele de obiecte și in diagramele de colaborare:
 complet – prin nume si numele clasei ;
 doar prin nume – fara a specifica tipul;
 “ano nime” – doar prin numele clasei.
În figura următoare noi vom descrie particularitațile principale de interacțiune a personajului cu
intelegența artificială, care ne va arăta cum ea lucreaza
Vezi figura 2. 10, schema generala a interacțiunii userului și inamicului(intelegenței artificiale) , care
la o distanță anumită în timpul căutarii personajului principal, încearcă să -l nimicească.
Figura dată este reprezentată prin legătura dintre cinci părți ale sale : user, mașină , control și inamic.

Figura 2. 10 – Interacțiun ea userului și inamicului
sd Settings
UserMeniu Masina Control Inamic
Accesarea
SinglePlayer()
Accesarea
Masinei()
Accesarea controlului
masinei()
Obtinerea miscarii()
Atacul asupra inamicului()
VerifyNearPlayer()
Primirea Damage()
*Intrarea in Joc()

26
Figura dată reprezintă interacțiunea dintre user și inamic. Userul accesînd modul de joacă
SinglePlayer prin meniu, intră în joc prin alegerea mașinei și începe interacțiunea cu el. Accesarea sau
utilizarea controlului mașinei, perm ite ca ea să se miște. Mișcarea mașinei permite mărirea vitezei ei, și
tamponarea cu alte mașini sau inamici. La rîndul său este arătat că pentru a găsi personajul, inamicului îi
este necesar sa verifice dacă personajul este aproape de el, pentru al nimici .
În figura următoare 2.11 este reprezentat metoda de accesarea a modului de joacă, GameMode care
userul poate să -l aleagă pînă a intra în joacă : SinglePlayer și MultiPlayer . SinglePlayer oferă jocul cu
calculatorul, sau contra intelegenței artificiale create(boți), iar MultiPlayer este modul de joacă între
pesoane online sau prin conexiunea LAN.
Vezi figura 2.11, pentru a vedea reprezentarea acestuia.

Figura 2.1 1 – Accesul la GameMode la prima intrare in joc

Următorul exemplu va reprezinta metoda personajului de a nimici inamicii s ăi în modul de joc
Single Player. Userul accesează modul de joc, apoi intrînd în joc el primește mașina pentru luptă și etapa
finală este confruntarea cu ina micii și obținerea unui scor.
Vezi figura 2. 12 pentru a observa acest pas .
sd GameMode
UserStart SinglePlayer MultiPlayer
Accesarea
Start()
*Intrarea in
GameMode()
SinglePlayer()
Intrarea in joc()
MultiPlayer()
VerifyAvaibleSlots()
Intrarea in joc()

27

Figura 2.12 – Atacarea inamicilor
2.1.5 F luxurile de mesaje și legăturile dintre componentele sistemului
Fluxurile de mesaje și legărurile dintre componentele sistemului sunt reprezentate de diagrama de
colaborare, care arată colaborarea dintre componentele sistemului. O diagramă de colaborare
(Collaboration Diagram ) reprezintă obiectele instanțiate la un moment dat în cursul execuției și mesajele
prin care acestea comunică înt re ele. Mesajele sunt marcate prin numele funcției apelate, iar obiectele sunt
identificate prin numele folosit în funcția de apel și clasa căreia aparțin. Mesajele pot fi numerotate în
ordinea în care sunt transmise, pentru a ușura înțelegerea modului de interacțiune între obiecte. Această
ordonare nu este foarte simplu de realizat în diagrama de colaborare, în schimb este conținută implicit în
diagramele secvențelor, care, de aceea, sunt mai frecvent utilizate decât diagramele de colaborare. Într -un
progr am, un obiect poate juca rol de client, server (furnizor) sau rol dual (agent). În programarea obiect –
orientată mesajele către obiecte server pot fi trimise de alte obiecte (de metode ale acestora) sau de funcții
globale (în C++, nu și în Java).
Diagrama de colaborare poate fi folosita pentru:
 a descrie un scenariu specific prin ilustrarea deplasarii mesajelor intre obiecte;
 a arata o organizare spatiala a obiectelor si interactiunilor.
Intrînd în joaca, sau în orice alt proiect, userul nevoie de a se verifica identitatea în proiect.Pentru
aceasta și este creată auntentificarea și validarea user -ului.
Vezi figura 2.13 , care descrie a utentificare și validarea personajului în scenă și doar apoi, jocul și
rularea mașinei poate avea un start.
sd BotAttack
UserSinglePlayer Masina Inamic
Accesarea
SiglePlayer() Accesarea
Masinei()
VerifyNearPlayer() *Intrarea in
Joc()
Atacarea inamicilor()
Obtinerea
Scorului()

28

Figura 2.13 – Autentificare și validarea personajului în scenă

În figura următoare este reprezentat colaborarea dintre erou si inamici, cu care interacționeaza și îi
poate distruge. Inamicii pe care îi avem sau mai corect AI (intelegeța artificială) , pot fi nimi ciți cu ajutorul
tamponării pînă la distrugerea completă a obiectului. Dar nu trebuie de uitat că, la interacțiunea mașinei
userului cu inamicii el la fel v -a primi o defectare oarecare a mașinei, chiar dacă mai mică.
Vezi figura 2.14 pentru a înțelege ma i detaliat cele descrise.

Figura 2.14 – Interacțiunea dintre erou și inamic

Exită și u n alt tip de colaborare . Ceea ce este descris în figura 2.15 reprezintă relația dintre inamic
și personaj. Aici este succind descris interacțiunea dușmanului cu person ajul. Personajul înainte de a capăta
oarecare scor, este nevoit să interacționeze între inamic . La început este inițiantă confruntarea dintre două
obiecte mobile pe scenă. Indifirent cine v -a ataca primul, ambele mașini vor primi oarecare d eteriorări, ceea
ce v-a duce la scăderea vieții pesonajului sau a inamicului. Scorul v -a fi obținut, dacă și numai dacă cineva
v-a fi învins. În figura următoare va fi descrisă afișarea scorului, datorită numărului de inamici destrămați.
Vezi figura 2.15, pentru a observa mai detaliat detaliile.
sd Authentification
User:Authentification:Connection1: Login(String username): bool2: ConnectiontoScene(String, int sessionId)
3: CheckUser(String, String)
4: UserValidation(:User)5: Logoff(int sessionId):bool
sd Collaboration 2
UserGameMode
Enemy1: StartTheGame()
2: DisplayUserCar()
3: CheckNumberOfCars()
4: KickEnemy()5: ReceiveDamage()

29

Figura 2.15 – Afișarea scorului
2.2 Descrierea structural a sistemului
Totodată pentru a descrie structura un ui sistem, la fel sunt folosite diagramele UML.
Diagramele UML, totodat ă oferă o gamă enormă de posibilități, pentru a descrie structura sistemului.
Fiecare sistem sau proiect, poate fi structurat atît prin caracteristicile sale hardware cît și software. În cazul
nostru este prezentă o aplicație pe care în capitotul dat, vor f i descrise caracteristicile softwa re, adică ceea
ce se referă la structura sistemu lui dat, și reprezentarea lui.
În capitolul dat vor fi descrise succind prin reprezentarea diagramelor urm ătoarele componente a
structurii sistemului :
 descrierea structu rii statice a sistemului;
 relatiile de dependență între componentele sistemului ;
 modelarea echipamentelor mediului de implementare.
2.2.1 Descrierea structurii statice a sistemului
Descrierea structurii statice a sistemului este reprezentat ă de diagramele de clase, care descriu clasa
fiecărui obiect din scenă. Diagrama claselor definește modelul structural al unui sistem prin intermediul
unui graf, ale cărui noduri (vârfuri) reprezintă clasele, iar arcele reprezintă legăturile dintre clase.
Se poate urmări diagrama claselor pentru un model de carti, exista elementul de baza Carte, care
este un caz generalizat al revistelor, jurnalelor, manualelor și care realizează interfața ICarte. Interfata a
sd Activ itiesNotifications
UserHPchecker
Game Score Display1: Kick()1.1: Calculate Damage()
1.2: Register the number of kill()
1.3: Adding point()

30
fost utilizată in scopul de a permite sa fie adăugate și alte tipuri de surse de informații pentru care se pot
defini metodele date pentru a fi folosite în mod similar.
O diagramă a obiectelor reprezintă structura statică a sistemului la un moment particular de timp,
folosind instanțe ale claselor (obiecte) și instan țe ale legăturilor dintre clase existente în acel moment,
folosind, de asemenea, un graf.
Diagrama obiectelor este mai puțin generală decât diagrama claselor și de aceea este mai puțin
utilizată. În plus, există și alte diagrame care reprezintă interacțiu ni sau evoluții ale obiectelor, care sunt
mai utile în proiectarea sistemelor (diagrame de colaborare, diagrame ale secvențelor, diagrame de stare).
Diagramele claselor și ale obiectelor se reprezintă folosind elemente structurale și elemente de
legătură .
În diagrama de clase din figurile de mai jos, e descrisa structura ierahica a claselor, mostenirea
proprietatilor si comportamentul claselor parinte, care la rindul lor a u proprietatile si comportamentul lor
propriu. Personajul are posibilitatea de a se m isca, Aici sunt reprezenta te cele mai importante acțiuni
realizate de către eroul principal.
În figura 2.16 vor fi afișate toate legăturile dintre principalele clase ale proiectului dat .

Figura 2.16 – Relațiile LevelManager și alte clase
class ClassDiagram
GameOv erScript
– Animation: anim
+ CountDown: countdown
+ Object: gameOverAnimation
+ Awake() : void
+ Update() : void
Lev el Manager
+ LoadScene()
+ QuitGame()
GlobalsVar
+ GameObject[] players
– GlobalsVar: Instance
+ GlobalsVar: static
– isadd:: bool
+ List<GameObject> : clones
+ Vector3: positions
– Awake()
+ Update()PauseScript
+ paused: bool
+ PauseMenu: GameObject
+ TimeScale:: bool
+ Resume()
+ Start()
+ Update()CarPlayer
+ Camera: cam
– CarEngine: controller
– lastSynchronizationTime:: float
– Quantemion: rot
– syncDelay: float
– syncEndPosition: Vector3
– syncStartPosition: Vector3
– syncTime: float
– Awake() : void
– OnSerializedNetworkView() : void
– SyncedMovement() : void
– Update() : void

31
Fiecare clasa depinde una de alta, pentru functionalitatea masinei.
Particularitatile masinei sunt: colisiunea ro ților care permite masinei sa nu cada in textura,clasa de miscare,
clasa audio care este intrebuintata pentru sunetul care il efectueaza la miecare miscare e tc.
Asadar diagrama de clasa din figura 2.17 , se înțelege cacteristica principal ă a ma șinei, unde sunt
prezentate o mulț ime de clase care permit ma șinei de a fi mobil ă si de a se mi șca.

Figura 2.17 – Particularitatile masinei.
2.2.2 Relaț iile de depende nță între componentele sistemului
În UML, termenul de componenta desemneaza un element software fizic din componenta unui
sistem. Astfel, o componenta poate fi: cod binar, document, fisier continand cod sursa sau date, tabela a
unei baze de date. O compone nta binara este o parte fizica si substituibila a unui sistem, care realizeaza si
este in conformitate cu un set de interfete.
Componentele binare sunt independente de limbajul de programare in care au fost codificate iar
utilizarea lor se bazeaza exclusi v pe interfete. Tehnologiile folosite in prezent pentru crearea de componente
binare sunt: COM+, DCOM,CORBA, Java Beans.
Diagramele de componente redau relatiile de dependenta intre diferite componente ale unui sistem:
class System
Wheel
+ CarController: car
+ Hub: Transform
+ MaxRpm: float
+ OnGround: bool
– particleRate: float
+ powered: bool
+ Rpm: float
+ skidTrailPrefab: Transform
– slideThreshold: float
+ WheelCollider
+ wheelModel: Transform
– FixedUpdate() : void
– Start() : void
CarManager
+ CarController: car
+ OnGround: bool
– startedSound: bool
– waitTime
+ WheelCollider
+ WriteMessage() : stringCarUserControl
– CarController: car
– Awake() : void
– FixedUpdate() : voidBrakeLight
+ CarController: car
+ Update()
CarController
+ GameObject[] players
+ GlobalsVar: static
– GlobalsVar: Instance
+ isadd:: bool
+ List<GameObject>: clones
+ Vector3: positions
– ApplyDownforce()
– Awake()
– CalculateGearFactor()
– CalculateRevs()
– CalculateSpeedValues()
– ConvertInputAccelerationAndBraking()
– CurveFactor()
– HandleGearChanging()
+ Immobilizer()
+ Move()
– OnDrawGizmozSelected()
– OnEnable()CarAIControl
+ Hub: Tranform
+ IoQualDist: float
+ MaxRpm: float
+ powered: bool
+ Rpm: float
+ SkidFactor: float
+ steerable: bool
+ WheelCollider
– FixedUpdate() : void
– Start() : voidCarSelfRighting
– lastOkTime: float
– velocityThreshold: float
– waitTime: float
– RightCar() : void
– Update() : voidCarAudio
+ lowPitchMax: float
+ LoginhightPitchMultiPlier: float
+ dopplerLevel: float
+ lowPitchMin: float
+ maxRollottoffDistance: float
+ pitchMultiplier: float
– startedSound:: boolean
+ useDoppler: boolean
– StartSound: void()
– StopAudio: void()
– UInverseLerp() : float
– ULerp() : float
– Update:() : void

32
Diagramele de componenete sunt import ante deoarece:
– modeleaza sistemul software real in mediul de implementare;
– evidentiaza probleme de configurare prin relatiile de dependenta;
– reprezinta o imagine a sistemului existent, inainte de a fi modificat;
– pot evidentia probleme de implementare fara a fi necesar sa se citeasca tot codul sursa .
Pentru realizarea funcționalităților de bază, aplicația interacționează cu o serie de componente care
sunt reprezentate în figura 2.18.
O particularitate importantă în cadrul aplicației este rularea acesteia, care nu va avea loc fără
interacțiunea cu fișierile de tip script , cu obiectele care le -am creat și cu care userul care va utilzia aplicația
va putea manipula, precum și scenele pentru trecerea de la un nivel la altul.

Figura 2.18 – Principalele componente ale sistemului

În figura următoarea diagramă este formată structura generală a scenei, unde se petrece toată
acțiunea a jocul dat care constă din: mecanică, elemente grafice, obstacole etc.
Principal compartiment al acestuia este LevelManager. Compartimentul dat, conține la general o
bună parte elementele sistemului. Mecanica este unul din cele mai importante compartimente al proiectului
dat. Ea conține baza mișcării și manipulării cu obiectele din cadrul scenei.
Vezi figura 2.19 pentru a vedea mai detaliat structura scenei sistemului dat .
cmp components
Lev el.Unity
{Meta Fisier}Objects.Prefab
{Meta Fisier}«executable»
Jocul.exe

33

Figura 2.19 – Structura generală a scenei sistemului

În figura următoare este descrisă schema generală structurii a intelegenței artificiale și componentele
de lucru a sistemului.
Figura dată redă momentele generale prin care inamicul care conține elemente de intelegență
artificială este învățat de a urmări nodurile în formă ciclică, de a evita obstacolele întîlnite în calea sa și de
a căuta personajul, adica mașina pentru a o urmări și nimici.

Figura 2.20 – Principalele componente ale sistemului de intelegență artificială
cmp components
Lev el Manager
InamiciMecanicaObstacole
MasinaElemente grafice
cmp components
Intelegenta Artificiala
MasinaObstacole
NoduriPath

34
3 Realizarea sistemului
Pentru elaborarea acestu -i proiect/joc 3D noi am folosit un nr, de elemente necesare.
Din elementele necesare fac parte :
 user interface;
 intelegența artificială;
 scena și figurile;
 animația, texturi și materiale;
 coliziunea si scripting.
Unity Technologies, firma care a creat acest pachet software,lansat pe piata cu jocuri care sa le
popularizeze engine -ul si pachetul de development. Cu toate acestea, au reusit in tr-un timp relativ scurt sa
revolutioneze domeniul prototyping -ului si dezvoltarii de jocuri cu Unity.
IDE-ul utilizat pentru crearea proiectului este Unity.
Scriptarea se face in JavaScript (sau C# si Boo, pentru cine prefera respectivele limbaje), ceea c e este
o abordare excelenta. Limbajul utilizat pentru realizare este C#.
El oferă o gamă enormă de posibilități pentru a realiza ceva frumos, util și interesant. Scenele conțin
obiecte ale jocului. Ele pot fi folosite pentru a crea un meniu principal, la n ivel individual, și orice altceva.
Fiecare fișier Scene este unic.
În fiecare scenă, plasăm mediile, obstacole, si decorațiuni, în esență, proiectarăm și construim jocul
pe bucăți. Proiectul în cauză conține 5 scen e : meniul și cele 4 nivele.
Meniul este format din 3 butoane : StartGame,Options,QuitGame. În proiect este reprezentată o scenă
a proiectului nostru.Este foarte important de reținut , că scenele sunt unice deci nu interacționeaza automat
între ele, atunci cînd sărim de la o scena la alta , nu u ităm de 2 parametri foarte importanți , numele Scenei
, și arhivarea acestora în submeniul Build Scene , unde fiecărei scene îi vom atribui un număr de
prioritate,pentruaface legătură între ele și ca Unity Editorul să cunoască care e scena principală. În proiectul
Unreal DerbyRace sunt afișate prioritățile fiecărei scene din Submeniul Build.
Obiectele sunt elementele pe care le creeăm pentru ca user -ul să interacționeze cu ele în cadrul jocului.
Masina este un obiect tip Prefab) , extras cu ajutorul Obiect elor si Scriptului, un editor de transformare a
imaginii în obiect Unity.
Pentru a extrage imaginea și a o serializa utilizăm drag&drop in scena , și atribuim nume obiectului
cu nou format .
Alte elemente utilizate în cadrul jocului sunt :
 inamicii;
 blocuri , terenul pe care se va deplasa;
 obiectele cu care va ataca ma șina.

35
3.1 Proiectarea bazei de date
O bază de date , reprezintă o modalitate de stocare a unor informații și date pe un suport extern (un
dispozitiv de stocare), cu posibilitatea extinderii ușoare și a regăsirii rapide a acestora. La prima vedere
sarcina poate părea banală.
Totuși, în condițiile în care este vorba de a lucra cu milioane de elemente, fiecare putând consta din
mari cantități de date care trebuie accesate simultan prin Internet de către mii de utilizatori răspândiți p e
întreg globul, și în condițiile când disponibilitatea aplicației și datelor trebuie să fie permanentă (de ex.
pentru a nu pierde ocazia de a încheia afaceri), soluțiile bune nu sunt de loc simple.
În proiectul nostru, noi folosim baza de date, pentru a a răta studiul structurii a aplicației noastre ce
va con ține:
– nr. de inamici destrămați;
– nume utilizator;
– scor-ul, adică punctajul pe care îl obține personajul principal;
– viața personajului;
– timpul de joc.
Bazele de date pot avea mărimi și complexități extrem de variate, de la câteva zeci de
înregistrări până la milioane de înregistrări .
Primul pas în realizarea unei aplicații de baze de date este analiza datelor și realizarea unei scheme
conceptuale (model conceptual) al aces tor date (figura 4.12). În această etapă sunt analizate natura și modul
de utilizare a datelor.

Figura 3.1 – Modelul logic al bazei de date aplicației

36
3.2 Descrierea la nivel de cod
Una din principalele particularități în aplicație este faptul cum sun t stocate datele și distribuite pentru
asigurarea principalelor servicii care propune aplicația.
In clasa CarController care este o clasă principala ne arata actiunea principala a personajului in acest
proiect .Personajul are posibilitatea de a se misca, A ici sunt reprezenta te cele mai importante acțiuni
realizate de către eroul principal [2].
private void OnEnable()
{
// set adjusted centre of mass.
GetComponent<Rigidbody>().centerOfMass = Vector3.up*adjustCentreOfMass;
}
void Start()
{
GMS = GameObject.Find("GameManager").GetComponent<GameManagerScript>();
}

public void Move(float steerInput, float accelBrakeInput)
{
PlayerHealth:
void decreasehealth()
{
if (!alive)
{
return;
}
if (cur_Health <= 0)
{
cur_Health = 0;
Death();

În timpul mișcărilor,personajul se poate pierde din limitele ecranului, pentru astfel de cazuri este
creată clasa AutoCam care îl va urmări pe erou pînă la fine , apelînd funcția targetForward() , și
transform.position() care va schimba poziția camerei pe axa X și Y [3 ].
var targetForward = target.forward;
var targetUp = target.up;

if (followVelocity && Application.isPlaying)
{
// in follow velocity mode, the camera's rotation is aligned towards the
object's velocity direction
// but only if the object is traveling faster than a given threshold.

if (target.GetComponent<Rigidbody>().velocity.magnitude >
targetVelocityLowerLimit)
{
// velocity is high enough, so we'll use the target's velocty
targetForward = t arget.GetComponent<Rigidbody>().velocity.normalized;
targetUp = Vector3.up;
}
else
{
targetUp = Vector3.up;
}

Inafara de „Camera si miscari” pe care personajul poate sa le faca, sunt prezenti si inamicii care te
urmaresc la o anumita desitanta si te omoar ă.

37
EnemyAIScript:

if (PlayerHealth.alive)
{
for (int i = 0; i <GlobalsVar.Instance.clones.Count; i++)
{
GameObject c = GlobalsVar.Instance.clones[i];
if (c.tag == "Player" &&c.active)
{
playerDistance = Vector 3.Distance(c.transform.position,
transform.position);
player = c.transform;
if (playerDistance < 15f)
{
GetComponent<CarEngine>().enabled = false;
lookAtPlayer();
}
if (playerDistance < 12f)
{
if (playerDistance > 4f)
{

chase();

}
Fiecare clasa depinde una de alta, pentru functionalitatea masinei.Particularitatile masinei sunt:
Colisiunea rotilor care permite masinei sa nu cada in textura,clasa de miscare,clasa audio care este
intrebuintata pentru sunetul care il efectueaza la miecare miscare etc.
using UnityEngine;
using UnitySampleAssets .CrossPlatformInput;

namespace UnitySampleAssets.Vehicles.Car
{
[RequireComponent(typeof (CarController))]
public class CarUserControl : MonoBehaviour
{
private CarController car; // the car controller we want to use

private void Awake()
{
// get the car controller
car = GetComponent<CarController>();
}

private void FixedUpdate()
{
// pass the input to the car!
float h = CrossPlat formInputManager.GetAxis("Horizontal");
float v = CrossPlatformInputManager.GetAxis("Vertical");
car.Move(h, v);
}
}
}

În cadrul proiectului nostru am utilizat Încapsularea pentru fiecare clasa declarată. Încapsularea
reprezintă ascunderea de informații: Asigură faptul că obiectele nu pot schimba starea internă a altor obiecte
în mod direct (ci doar prin metode puse la dis poziție de obiectul respectiv), doar metodele proprii ale
obiectului pot accesa starea acestuia. În codul de mai jos sunt declarate atributele clasei Enemy , utilizînd
încapsularea.

38
public class Enemy : MonoBehaviour
{
public float moveSpeed = 2f;
public int HP = 2;
public Sprite deadEnemy;
public Sprite damagedEnemy;
public AudioClip[] deathClips;
public GameObject hundredPointsUI;
public float deathSpinMin = -100f;
public float deathSpinMax = 100f;

În cadrul unui obiect, codul și datele pot fi private sau public. Cînd sunt private, ele sunt vizibile și accesibile
doar în interiorul obiectului. În cazul public, celelalte părți a le programului le pot utiliza [ 4].
3.3 Testarea sitemului
Testarea funcțională (black – box testi ng) este o strategie în care testarea este bazată numai pe
cerințe și specificații. Spre deosebire de complementara sa, testarea cutiei albe, testarea cutiei negre nu
necesită cunoașterea căilor și structurii interne, nici a implementării produsului soft t estat.
Procesul testării funcționale (black – box testing) constă î n:
– analiza cerințelor și specificațiilor;
– alegerea datelor valide de intrare bazată pe specificațiile spre a determina dacă produsul soft testat
le prelucrează corect ;
– sunt alese date de in trqare incorecte pentru a verifica dacă produsul soft testat le detectează si le
prelucrează corespunzător;
– determinarea datelor de eșire .
Metoda testtării funcționale,cutiei negre, poate fi aplicată la toate nive lele de dezvoltare a softului
dezvoltare de unități, de integrare, de sistem și de acceptare.
Trecând de la modul spre subsistem și apoi spre sistem, cutia devine mai mare, cu intrări și ieșiri tot
mai complexe, dar abordarea rămâne aceeași.
De asemenea, odată cu creșterea cantității, suntem forț ați spre abordarea cutiei negre, deoarece sunt
prea multe căi în cadrul produsului soft de testat pentru a efectua testarea cutiei albe.
C# oferă posibilități pentru testarea software extensivă. Testarea proiectelor îmbunătățește
robustețea, reduce erorile de sistem, accelerează acceptarea produselor pentru distribuție și vânzare.
Testarea poate ajuta, de asemenea să dezvolte aplicații mai rapid, cu mai puțin efort irosit, pot fi folosite
pentru a contribui la o dezvoltarea coordonată a proiectului [5].
O metodă de a evalua cât de bine e testat un program e de a măsura acoperirea codului prin teste.
Criteriile cele mai simple (acoperirea fiecărei linii și a fiecărei ramificații) sunt insuficient de puternice
pentru detectarea multor tipuri de erori. E necesa ră deci, folosirea folosirea unor criterii de acoperire mai
precise, care reflectă mai bine funcționalitatea codului analizat și generarea automată a unor teste cât mai
relevante, care să maximizeze acoperirea după criteriile selectate.

39
Modul Visual Studio pentru analiza acoperirii după fluxul de date ( dataflow coverage ) în programe
C#. Acest criteriu de acoperire corelează utilizările unei variabile cu locurile anterioare
de definiție (atribuire) care dau posibilele ei valori (vezi un articol care studiază problema). Scopul e de a
măsura calitatea acoperirii acestui criteriu, și, în pasul următor, a genera automat teste care acoperă căile
încă netestate. Un proiect de licență anterior a tratat această problemă pentru Java folosind sistemul de
verificare Java PathFinder . Alt proiect a măsurat acoperirea liniilor de cod și ramificațiilor folosind
infrastructura de ana liză Phoenix de la Microsoft.
Testare cu acoperire bazată pe predicate (limbaj la alegere: Java, C#, C, …)
O bună suită de teste parcurge programul testat pe toate ramurile. Însă ramificațiile unui pr ogram nu sunt
independente: comportamentul pe o ramură poate depinde de calea aleasă într -o porțiune anterioară a
codului (care a setat un fanion sau a făcut alte atribuiri relevante). Noțiunea de acoperire bazată pe predicate
(predicate coverage ) exprimă acest aspect, evaluând la fiecare punct în program corelarea dintre condiții
(predicate) considerate relevante. Proiectul va evalua acoperirea unei suite de teste, în raport cu p redicate
definite de utilizator sau selectate prin analiza codului, și va genera teste suplimentare pentru cazurile
neacoperite.Pentru programe și biblioteci orientate pe obiecte, testele conțin secvențe de apeluri de metode.
Cum numărul de secvențe posib ile crește exponențial cu numărul de apeluri, e important ca ele să
fie alese judicios. Similar cu acoperirea bazată pe flux de date, proiectul va defini criterii de generare a
testelor bazate pe corelarea între metode (de ex. combinarea apelurilor la meto de tip getter cu cele de tip
setter pentru aceiași membri de date; gruparea în teste a metodelor care interacționează, etc.Programele
orientate pe obiecte pot avea tipuri de erori specifice, datorate polimorfismului (apelul unei metode din altă
clasă decât se intenționează), sau cuplajului între metode care accesează aceiași membri de date. Pornind
de la modele de eroare cunoscute , proiectul va continua analiza lor și va genera suite de teste adaptate la
detectarea acestor tipuri de erori. Vezi figura 3.2 pentru a vedea rezultatele testării, unui debug din Unity
[6].

Figura 3.2 – Rezulatele testarii a proiectului

40
4 Documentarea produsului realizat
Documentarea produsului este realizată pentru a se descrie cerințele tehnice a aplicației, unde se
poate găsi această aplicație, cum se instalează și cum poate fi navigată.
Fiecare aplicație are modul său de instalare și navigare. Sunt aplicații care pot fi rulate direct pe web
sau online, sunt aplicații care au nevoie de instalare direct de pe CD sau flash și sunt aplicații pe care
utilizatorul le po ate instala direct din magazine online speciale de procurare a jocurilor ca exemplu : Uplay ,
AppleStore, Origin, PlayMarket, Steam etc. Aplicația sau proiectul realizat v -a fi găsit pe Steam . În
continuare vor fi descrise particularitățile principale de accesarea softului dat.
Descrierea aplicației va fi atât la nivel de administrator cât și la nivel de simplu utilizator.
Pentru a face această documentare utilă și funcționabil ă, va fi descrisă fiecare funcționalitate a
butoanelor din meniu și funcționalitățile proiectului dat.

4.1 Achiziționarea și folosirea aplicației
Aplicația dată va fi destribuită pe platforma Steam. Steam es te o aplicație aparte sau mai bine spus
o platformă globală de distribuție a jocurilor video. Platforma dată conține atît jocuri cu plată cît și gratis.
Această platformă o putem considera drept un magazin de procurare a jocurilor video și a altor aplicaț ii de
folos, create de programatori. Pe ntru utiliza rea aplicație i date este necesar de a o descărca, apoi instala.
Pentru utilizarea deplină a aplicației , este nevoie de efectuat o simplă înregistrare a userului, unde el își v –
a păstra și folosi aplicați ile sale procurate pe platforma dată. Vezi figura 4.1 pentru a observa procesul de
instalare.

Figura 4.1 – Instalarea aplicației Steam

41

Figura 4.1 prezintă instalarea aplicației Steam și extragerea fișierilor importante pentru lucrul cu
aplicația .
În figura următoare este reprezentată posibilitate userului de a se loga pe platforma Steam, sau de a
crea un cont nou .
Vezi figura 4.2 pentru a observa logarea sau crearea unui cont nou pe Steam.

Figura 4.2 – Autentificarea pe platforma Steam

Următoarea figură reprezintă interfața platformei Steam. După ce utilizatorul a fost logat cu succes
pe platformă, el poate o utiliza din plin. Utilizatorul are posibilitatea de a viziona noutățile noi, de a intra în
setările contului său și de a descărca jocurile s au aplicțiile sale preferate.
Vezi figura 4.3 pentru a obser va interfața aplicației Steam.

Figura 4.3 – Interfața a plicați ei Steam

42
După achiziționarea jocului Unusual Derby Racing pe platforma Steam, v-a fi posibilitatea de al
instala automat. În timpul instalării aplicației este nevoie doar de ales locul în care va fi instalat jocul, iar
apoi doar de al starta și utiliza.
Esența aplicației date este de a destruge cît mai mulți inamici și de a rămîne în viață pentru a acumula
scor. La startarea jocul ui, scorul userului este egal cu 0 . Mărirea lui depinde de numărul de inamici
destrămați de către utilizator. Cu cît sunt mai muți ina mici destrămați, scorul va cre ște mai mare .

4.2 Tastele de control a aplicației
Pentru rularea sau manipularea mașinei utilizatorul folosește tastatura, iar mousesul, pentru
accesarea opțiunilor sau butoanelor aplicației. Jocul dat conține o gamă largă de butoane pe care utilizatorul
le poate folosi la manipularea mașinei. În continuare, în tabelul de mai jos veți observa controalele de rulare
cu mașina.
Vezi Tabelul 4.1 pentru a observa tastele de control a mașinei.

Tabelul 4 .1 – Tastele de co ntrol a ma șinei
Acțiune Tastatură
Accelerare Săgeata sus
Frînă Săgeata jos
Steer / Manevră Săgețile dreapta și stînga
Frîna de mînă Space
Nitro Boost B
Rotirea camerei mașinei WASD
Restartarea jocului R
Resetare la poziția de bază X
Resetarea poziției mașinei la poziția de start Z

4.3 Componentele categoriei: Meniul utilizatorului
Orice aplicație cu o interfață grafică are un Meniu pentru utilizator. Acest meniu este un îndrumar
pentru ca aplicația să fie mai ușoară în folosință. De obicei un meniu oferă o mulțime de variante pentru a
manipula cu aplicația. În cele mai multe cazuri un meniu e format din mai multe pagini, care conține diferite
acțiuni. De exemplu proiectul dat are 3 elemente pe prima pagină.
Meniul principal:
– start g ame;
– options;
– quit game.

43
Start Game – butonul care trebuie folosit atunci când utilizatorul este gata să înceapă jocul.
Accesând acest buton u tilizatorul este dus la următoare pagină a meniului, care constă din alegerea modului
de joacă. Această pagină are numele GameMode Meniu.
Pagina GameMode Meniu, conține alte două butoane. Primul buton este modul Single Player, ce
înseamnă că utilizatorul se va lupta cu personajele manipulate de calculator, cu alte cuvinte inteligența
artificială a jocului dat. Al doilea buton MultiPlayer, constă din accesare internetului și de a juca cu alți
utilizatori reali. Din păcate acest buton va fi nefuncționabil di n cauza termenului scurt de timp. În termenul
acordat s -a tras atenție mai mult la mecanica mașinii și la inteligența artificială a ei.
La fiecare pagină nouă a meniului este un buton Back , pentru ca utilizatorul să fie capabil să se
întoarcă în orice moment la meniul principal, sau pagina anterioară.
Options – butonul care pe viitor trebuie să permită manipularea aplicației. Mnipularea constă în a
schimba luminozitatea, contrastul, mărimea ferestrei, setările audio și video etc. Acest buton nu va fi
funcționabil în versiunea Demo, doar în versiunea finală care va fi cu plată, când proiectul va fi gata
definitiv.
Quit Game – butonul care răspunde de ieșirea din aplicația dată. Acest buton este prezent atât în
meniul principal cât și în cel de pauză Paus e, care are rolul de a pune pe pauză jocul în timpul utilizării pe
un timp nelimitat pentru modul de Single Player și pentru un timp limitat pentru modul Multi Player.
Pentru a vedea dinamica creării a acestor meniuri, vezi figurile de mai jos, care reprez intă un set de
imagini a meniului a aplicației, care este compus din mai multe pagini pentru rulare.

Figura 4.4 – Meniul principal al jocului

44
În această imagine putem vedea butoanele din meniul principal. Fiecare din ele fiind accesate de
către utilizato r la nevoie. Butonul Start pentru a începe jocul, butonul Options pentru a manipula cu
aplicația, și butonul Quit Game pentru a ieși din aplicație. Proprietățile acestor butoane și utilizarea lor au
fost descrise mai sus.

Figura 4. 5 – GameMode Meniu

Acest Meniu poate fi văzut atunci când din meniul principal a fost selectat butonul Start Game . Aici
putem vedea alte trei butoane care pot fi folosite de către utilizator. Modul Single Player care permite
utilizatorului să înceapă joaca împotriva inteligen ței artificiale a aplicației. Modul Multiplayer permite
utilizatorul de a juca în timp real cu alți utilizatori a acestei aplicații. Și butonul Back To StartMeniu care
este folosit în cazul în care utilizatorul decide să se ducă înapoi la meniul principal al aplicației.

Figura 4. 6- Meniul de Pauză

45
Acest meniu poate fi accesat atunci când utilizatorul se află într -o sesiune care deja s -a început, și
la un moment are nevoie de a pune pe pauză jocul. Accesând proprietatea de pauză utilizatorul are la
dispoz iție trei butoane. Primul buton este Resume care are rolul de a continua sesiunea, butonul Options
permite utilizatorului de a manipula cu aplicația, și are același rol ca și butonul butonul Options din meniul
principal. Al treilea buton Exit to Menu perm ite utilizatorului de a se întoarce în meniul principal al
aplicației.
4.4 Componentele categoriei Level Manager
LevelManager este categoria de obiecte ata șate sc enei. În scena noastră sunt prezentate o mulțime
de obiecte care face jocul no stru mult mai dinamic . La fel , LevelManager oferă o posibilitate largă de
manipularea cu obiectele , adică schimbarea poziției lor, marimei, crearea coliziilor, etc.
Obiectele prezentate în scenă sunt :
 mașină;
 arenă;
 obstacole;
 intelegența artificială (Alte tipuri de mașini);
 coliziunea .
Mașina este personajul principal din joc, pe care utilizatorul o manipulează, efectuînd o bătălie cu
alte mașini pentru a fi pe primul loc.
Arena reprezintă locul petrecerii tuturor mișcarilor personajelor. Scenele conțin obiecte ale j ocului.
Ele pot fi folosite pentru a crea un meniu principal, la nivel individual, și orice altceva. Pentru a observa
modelul unei scene vezo figrua K.3 din anexă .
Fiecare fișier Scene este unic. În fiecare scenă, plasăm mediile, obstacole, si decorațiuni, în esență,
proiectarăm și construim jocul pe bucăți.
Obstacolele, sunt un gen de piedici în joacă pentru fiecare, care oferă mai mult timp de trecere, și
de a juca cu o mare atenție, fiindcă ca automobilul să nu să se răstoar ne, și la moment de a nu a fi nimicit
de boți (alte mașini).
Coliziunea reprezintă întîlnirea particulelor sau corpurilor în care fiecare exercită o forță asupra
celui -lalt, provocând schimbul de energie sau impuls . Unity3D dispune de obiecte Collider de diferite
forme ( Box Collider, Circle Collider, etc) . Cu o poziționare atentă și dimensionare, collider -urile
combinate pot ocupa obiectul în întregime.Atunci când au loc coliziuni, motorul numește funcții cu nume
specifice cu privire la orice script atașat la obiectele implicate.
Avem posibilitatea să plasăm orice cod pe care dorim în aceste funcții pentru a răspunde la
evenimentul de coliziune. De exemplu, să se distrugă un bloc, atunci cînd interacționăm cu sabia.

46
La prima actualizare a coliziunii,utilizăm funcția OnCollisionEnter . În timpul actualizărilor în care
contactul dintre obiecte se menține pe o perioada mai lungă folosim OnCollisionStay și în cele din urmă,
OnCollisionExit indică faptul că un contact a fost rupt.

4.5 Componentele categoriei Mașină
Mașina este componenta principală a acestei aplicație. Acest obiect mobil oferă posibilitatea de a fi
manipulat ușor în cadrul unei scene. Tipul jocului este “Derby”, de aici rezultă că scopul principal a jocului
este de a avea o bătălie cu alte mașini. În timpul rulării a acest ei aplicații, utilizatorul poate vedea pe ecran
elemente ca Speedometer care arată viteza cu care se deplasează automobilul, scala Nitro , și scala Drift ,
care funcționează doar atunci când utilizatorul cu ajutorul mașinii efectuează un drift.
Vezi figura 4.7 și figura K.1 din anexă, pentru a vedea cum arată mașina care poate fi folosită de
către utilizator. Aceasta fiind doar un model din cele disponibile. Utilizatorul având acces la orice model
din cele disponibile. Pentru început mașinile doar vizual vor fi diferite, funcționalitățile fiind la fel la toate
modelele.

Figura 4. 7 – Mașina propriu zisă

4.6 Componentele categoriei Obiecte secundare
Obiectele sunt elementele create pentru ca utilizatorul să interacționeze cu ele în cadrul jocului.
Mașina este un obiect de tip Prefab, care este extras cu ajutorul Obiectelor și a Scriptului, un editor de
transformare a imaginii în obiect Unity. Pentru a extrage imaginea și a o serializa utilizăm drag & drop în
scenă, și îi atribuim un nume obiectului nou cre at. În cazul nostru GeneralVehicle, a șa cum este afișat în
figura 4.8 .

47

Figura 4. 8 – Editor de Prefab

Alte elemente utilizate în cadrul acestui joc sunt:
– inamicii;
– blocuri, terenul pe care se va face deplasarea sau circuitul;
– arme, obiecte cu care se vo r ataca inamicii.
În figura 4. 9 de mai jos sunt atașate elementele secundare care vor fi folosite dea lungul jocului.

Figura 4. 9 – Elementele secundare ale jocului

În această figură putem observa diferite elemente care vor fi folosite în timpul jocului. Putem vedea
așa elemente ca cifrele care sunt utilizate până începe jocul sau când utilizatorul după ce a folosit butonul
de pauză continuă sesiunea. Mai putem observa imagini care sunt folosite ca imagine la diferite pagini a
Meniului, și desigur elemente care sunt folosite pentru obiectul mașină, Skin -uri pentru mașini.

48
5 Evaluarea economică a proiectului
Evaluarea economică a proiectului constă în calcularea bugetului planificat a proiectului,
prognozarea volumului de vînzări posibile și eficien ța economică privind implementarea în practică a
tuturor cercetărilor și mișcărilor efectuate în cadrul aplicației.
Pentru cercetarea proiectului sau aplicației curente, vor fi nevoie de anumite puncte de descriere.
Aceste puncte le puteți vedea mai jos.
Jocurile în timpul de față reprezintă o mare parte din softul calculatorului unde utilizatorul petrece
un timp al său acolo, fie el enorm, sau chiar puțin. Deobicei persoanele preferă jocurile pentru a se relaxa,
alții pentru a crește în joc. Actualitatea produsului dat constă ca userul v -a pătrunde într -o atmosferă destul
de veselă și fără conținerea elementelor de violență. De aici putem duce concluzii că, orice copil de la vîrsta
de 5 ani, poate juca în jocul dat. Fiecare, cît și copii atît și maturii iu besc mașinile, întrecerile și jocurile cu
obstacole, perepeții. De aici rezultă că nu depinde de vîrstă, ci de actualitate, unde fiecare utilizator poate
sa se relaxeze în această aplicație și de a primi plăcere.
Proiectul dat, în perceperea consumatorului reprezintă o scenă veselă, plină de mașini, obiecte și
posibilități enorme, pentru un joc simplu, sau relaxare în timpul liber după serviciu.
Scopul elaborării proiectului dat este de a reda o atmosferă plăcută pentru utilizator îm timpul
jocului. Scopul aplicației create este deopotrivă o sursă de calm și relaxare în timpul liber, dar în același
timp este o sursă de stimulare a atenției, reacției.
Deci o să fie o mașină cu ajutorul careia o să nimici alte mașini pentru a obține un scor cât mai mare.
Func ționalitatea inamicilor depinde de sistemul AI (Artificial Intelleigence), iar scopul lor va fi de a ne
nimici.
Proiectul dat aparține categoriei de comercializare. În acest scop vom efectua calculele proiectului
în care sunt incluse toate cheltuielile su portate pentru perioada de elaborare al proiectului.
Descrierea proiectului din punct de vedere a marketingului. Chiar dacă sunt proiecte destul de
similare față de aplicația dată, acesta este ceva unic. Pentru crearea proiectului a fost pus în evidență ca
scop, cercetarea a altor aplicații asemănătoare, adăugarea unor tehnici noi de proiectare a elementelor
grafice, mecanice și evidența unei intelegențe artificiale diferit de alte proiecte.
Un mare plus, al proiectului dat este concurența minimă în țară. E xistă un nr foarte mic de proiecte
similare care au posibilitatea de a crea obstacole pentru dezvoltarea lui.
5.2 Planul calendaristic în scopul optimizării volumului de timp și resurselor de
muncă necesar pentru elaborare

Un plan calendaristic al proiectului reprezintă distribuirea în timp a procesului de elaborare și
repartizare a sarcinilor și resurselor. Durata timpului pentru realizare a proiectului este de 3 luni, dar desigur

49
necesită mai mult timp pentru realizarea lui. Proiectele din domeniu l jocurilor, cele mai simple se creează
în jur de jumătate de an, durînd pînă la 2 -3 ani.
Etapele de planificare a timpului vor fi descrise după un algoritm anumit. Acest algoritm este
compus din anumite sarcini, după care trebuie sa fie îndeplinte [7].
Vezi figura 5.1, care arată etapele de planificare a timpului pentru realizarea aplicației.

Figura 5.1 – Etapele de planificare

Cum este observat în figura 5.1, că etapele de planificare a proiectului sunt reprezantate de :
obiective proiectului, volumu l lui de lucru ce va ar ăta valorificarea muncii realizate, timpul necesar care
arată durata lucrului asupra proiectului sau a aplicației și planul calendaristic unde v -a fi procesat pe date
și timp volumul de lucru de la începutul proiectării aplicației, p înă la prezentarea ei.
Obiective
Jocurile în timpul de azi sunt mai ușor realizabile decît în anii precedenți. Programatorii în domeniul
jocurilor aveau în anii precedenți, aveau nevoie de mai mult timp pentru a le realiza.Astăzi deja sunt create
o sumedenie de motoare pentru crearea lor în mod mult mai ușor fără a crea totul de la bun început.
Programiștii în domeniul jocurilor folosesc motoare, deja gata făcute și deja lucrul și perfecționarea
aplicației este mai ușoară în realizare.
Chiar dacă sun t prezente o mulține de motoare de creare a jocurilor, aceasta nu înseamnă că lucrul
asupra proiectului s -a micșorat din plin.Așadar, p entru realizarea proiectului dat, avem nevoie de obiective.
Fiecare proiect, chiar și aplicația dată, are nevoie de anumi ți pași, începînd cu apariția unei idei și
terminînd cu prezentarea aplicației gata, iar apoi vînzarea lui. Perioada creării prototipului de proiect este
de 3 luni. Dece prototip, dar nu aplicație gata, deoarece este nevoie de mult mai mult timp, pentru
implementare, valorificare și testare.
Totul se începe de la naștearea ideii de proiect, aprobarea ei, colectarea informației și numai deja la
sfîrșit startul de creare a aplicației. În cadrul aplicației date, au fost trecute prin mai multe etape, pînă la d e
a ajunge la un punct finit de lucru a prototipului.
Pe viitor, este planificat un set mare de posibilități a aplicației. Aplicația v -a deține un mod
suplimentar de joacă, care v -a permite de acționa nu numai cu calculatorul, dar și cu alte persoane, prie teni,
în mod Online.

50
Vor fi ad ăugate mari posibilități de interacționare în joc, începînd cu schimbarea grafică și ajungînd
la adăugarea mai multor posibilități interesante pentru un user. Așadar pentru toate modificările realizabile
a acestui proiect, v -a dura în timp un an și jumătate pe viitor, începînd cu inițierea lor, verificarea erorilor
și testarea însăși a programului.
Strategia de preț, valorificarea produsului dat, tot va fi efectuată după anumite calcule, acțiuni .
Acestea depind de, popularita tea aplicațielor asemănătoare pe piață, consumul și cheltuierile pentru
realizarea acestui proiect și profitul însăși pentru al folosi la crearea altor aplicații.
Nu trebuie sa uităm și de marketing, deoarece cît de bine și util va fi reclamat produsul, a tît de bine
și cu succes el va fi vîndut.
Volum ul de lucru
Volumul de lucru constă în divizarea tuturor acțiunelor din cadrul proiectului care trebuie să fie
realizate. Acțiunile pentru îndeplinirea proiectului sau aplicației sunt divizate și sistematizate în trei etape
mari.
Aceste etape sunt:
 etapa de preg ătire;
 etapa de evaluare ;
 etapa de finisare.
Etapa de pregătire asupra proiectului s -a început din data de 24 octom brie 2016. În această dată a fost
începută pregătirea către începerea proiectului și colectarea, studierea informației.
Începînd din februarie și pînă la data de 3 martie 2017, a fost întocmită practica de diplomă, unde la
instituția de întocmire a practic ii, în cadrul inginerilor, au fost primite sfaturi și sugestii asupra proiectului.
Apoi, pe data de 30 martie 2017, a fost evaluată prima parte a proiectului, de 30 % finisat.
Data de 30 aprilie este data în care trebuie sa fie prezentat 70% din proiectul gata, unde va fi arătat o
mare parte din partea practică. Și în sfîrșit pînă la data de 15 mai 2017, trebuie să fie prezentat proiectul
gata finisat ca apoi să fie evaluat în fața comisiei.
Timp ul necesar realizării proiectului
Cum s -a fost descris în sub capitolul precedent, pregătirea asupra proiectul a startat din data de 24
octombrie 2016.
Pentru a calcula timpul necesar pentru realizarea proiectului, este necesar de calculat timpul necesar
pentri executarea fiecărei acțiuni planificate.
Dar trebuie de ținut cont de timpul de rezervă pentru fiecare sarcină. Durata acțiunii este calculată
după o anumită formulă. Vezi formula de mai jos.

51
Durata acțiunii = data începerii – data finisării + rezerva de timp (zile).

Așadar datorită calculărilor s -a preconizat durata aproximativă a acțiunii executării proiectului, care
este timp de 16 5 de zile, ceea ce e aproximtaiv 5,8 luni de lucru, incluzînd zilele oficiale de sărbători și
odihnă ca zile libere, plus 2 zile de odihnă pe s ăptămînă. Calculul zilelor a fost efectuat de la data începerii,
pînă la data prezentării proiectului, 15 mai 2017.
Plan calendaristic
Planul calendaristic reprezintă un tabel cu o serie de informații, ce reprezintă fondul de timp necesar
pentru elaborar ea proiectului. Acest tabel este compus din : denumirea acțiunii, perioada de începere și
finisare, durata lui, executantul și resursele utilizate. La sfîrșitul tabelului se va calcula volumul de timp
care v -a fi necesa pentru elaborarea proiectului [8].
Vezi tabelul 5.1 pentru a observa timpul necesar pentru elaborarea proiectului

Tabelul 5.1 – Fondul de timp necesar elaborării proiectului
№
d/o Denumirea sarcinilor Perioada Durata
acțiunii Executant Resurse
utilizate
începerea finisarea
1 Stabilirea temei
scopurilor, și
obiectivelor aplicației 18.10.16 24.10.16 6 Inginer programator
internet
2 Analiza domeniului
de studiu și estimarea
costurilor de
implementare 25.10.16 10.11.16 26 Conducător proiect
internet
3 Elaborarea caietului
de sarcini 11.11.16 28.11.16 17 Conducător proiect indicații
metodice
4 Modelarea aplicației 29.11.16 28.12.16 29 Inginer programator internet / forum
5 Proiectarea aplicației 06.02.17 03.03.17 25 Inginer programator soft de creare
6 Proiectarea bazei de
date 04.03.17 14.03.17 10 Inginer programator internet
7 Implementarea
aplicației 15.03.17 15.04.17 31 Inginer programator soft de creare
8 Testarea aplicației 18.04.17 25.04.17 7 Inginer programator soft de creare
9 Verificarea și
corectarea erorilor
software 26.04.17 10.05.17 13 Inginer programator internet / forum
10 Prezentarea
proiectului 15.05.17 15.05.17 1 Inginer programator internet
Total 165

52
Analiza datelor calculate arată totalitatea zilelor lucrătoare a fiecărui executant asupra proiectului.
Așadar, din rezultatele obținute se deduce, că conducătorul proiectului are 43 de zile lucratoare, iar inginerul
programator, are 122 zile lucrătoare asupra proiectului dat.
5.3 Analiza SWOT
Analiza SWOT constă în identificarea raționalității proiectului, unde este analizat mediul intern și
extern al lui. Metoda generală de analiză SWOT constă în evaluarea și depistarea punctelor forte și cele
slabe ale mediului intern și extern al proiectului. Pentru a face anali za SWOT a aplica ției, este nevoie de a
evalua cele 4 obiective a ei : punctele forte, punctele sla be, oportunitățile și riscurile [9].
Punctele forte descriu atributele pozitive ale mediului intern, ce țin de organizație și proiect. Aceste
puncte sunt puncte tari, care descriu elemete intagibile, cunoștințe în domeniu, educație, experiență,
materiale cu un drept de autor etc.
Punctele slabe sunt ni ște factori ale mediului intern care sunt sub un control de participanții implicați
într-un mod direct în proiect care pot împiedica sau de a avea o relație rea asupra nivelului competitiv de
calitate a proiectului.
Vezi tabelul 5.2 pentru a observa mediul intern și extern a proiectului.

Tabelul 5.2 – Mediul intern al proiectului
MEDIU INTERN
Puncte forte :
 modalități noi de cîștig față de
concurenți;
 intelegență artificială bine –
programată;
 părtile obiectelor jocului la
ciocnire sunt destructibile;
 aspecte inovative pe viitor;
 persoane de încredere în cadrul
organizației;
 ingineri inovativi și creativi în
cadrul echipei;
 tema proiectului populară pe piață.

Puncte slabe :
 lipsa resurselor financiare;
 reputa ția slabă pe piața de vînzări;
 termen limit de timp;
 lipsa unei experiențe anterioare în
domeniu creării jocurilor;
 lipsa canalelor clare de
comunicare;
 lipsa teambuildingului;
 lipsa specialiștilor în domeniul
graficii pe calculator;

53
Continuare tabel ul 5.2
MEDIU EXTERN
Oportunități :
 dezvoltarea domeniului de
GameDevelopment în țară ;
 dezvoltarea tehnologiă;
 prezența slabă a concurenților
mari în domeniu;
 surse de finanțare de către
întreprinderile mari;
 arenda oficiilor cu un preț redus ;
 impozite mici pe venit pe
specialitate;
 dezvoltarea tehnologiilor
informaționale în țară;
 posibilitatea de a te dezvolta în
domeniu.

Riscuri (pericole) :
 efecte legislative;
 efecte politice;
 lipsa surselor de finan țare de către
întreprinderile mari;
 dezvoltarea economică;
 apariția a concurenților;
 dezvoltarea slabă în domeniu;
 majorarea prețurilor la produs
finit.

Oportunitățile sunt niște factori atractivi ale mediului extern, care reprezintă elementele de care
poate profită echipa sau organizația, care lucrează la proiectul dat.
Riscurile sunt factori a mediului extern ce pot impune implementarea proiectului într -o poziție de
risc. Acești factori pot fi contro lați numai dacă ar exista un plan de urgență care duce la soluționarea acestor
probleme.
5.4 Calculul indicatorilor economici
Efectuarea caclulelor a indicatorilor economici sunt necesare proiectului, indiferent de tipul care
este, comercial sau cercetare științifică.
Capitolul dat calculează suma necesară pentru lansarea și menținerea proiectului pînă cînd el atinge
momentul de rentabilitate.
Toate calculere sunt efectuate în valuta națională (MDL). Prețurile sunt necesare să fie actuale, fără
adausurile de TVA [10].
Inițial se efectuează calculele investițiilor în active materiale și nemateriale pe termen lung. Activele
materiale reprezintă o formă fizică naturală.
Durata de funcționare utilă, mai mare de un an. Este utilizată în activitatea întreprinderii sau se află
în procesul de creare, dar nu este destinată vînzării.

54
În tabelul următor, se va observa activele materiale pe termen lung de utilizare, în timpul rel izării
proiectului. La evaluarea activelor materiale s -a stabilit valoare de intrare totală de circa 28640 de lei.
Vezi tabelul 5.3 pentru a observa activele materiale pe termen lung.

Tabelul 5 .3 – Activele materiale pe termen lung

Nr.
d/o

Denumirea/
tipul activului
Un.
de
măs.

Preț
achiziție
pe unitate
MDL

Cantitatea
Valorare
de intrare,
MDL
1 AOC I2769Vm / 27inch bucată 6000 1 6000
2 Lenovo IdeaPad 300 17ISK bucată 20000 1 20000
3 Kingston HyperX 8GB RAM bucată 770 2 1540
4 1TB hard drive bucată 4000 1 4000
5 Canon Pixma IP7250 Printer 5in1 bucată 1200 1 1200
6 Zelotes T90 Mouse bucată 200 1 200
7 Logitech G710 Keyboard bucată 1100 1 1100
Total 28640

Activele nemateriale, sunt active nebănești. Aceste active, nu iau o formă materială și sunt controlate
de întreprindere.
Apoi ele sunt utilizate mai mult de un an în activitățile de producție, comercială sau în alt gen de
activitate. Software – sunt prog ramele și aplicațiile care sunt necesarew pentru crearea și realizarea
proiectului. În tabelul următor, se va observa activele nemateriale pe termen lung de utilizare, în timpul
relizării proiectului.
Vezi tabelul 5.4, pentru a observa activele nemateriale pe termen lung.

Tabelul 5.4 – Activele nemateriale pe termen lung

Nr.
d/o

Denumirea/
tipul activului
Un.
de
măs.

Preț
achiziție
pe unitate
MDL

Cantitatea
Valorare
de intrare,
MDL
1 Microsoft Office unitate 2913 1 2913
2 Sistem de operare Windows unitate 2320 1 2320
3 Unity3D unitate gratuit 1 gratuit
4 Enterprise Architect unitate 2700 1 2700
5 Visual Studio unitate 2500 1 2500
Total 10433

55
La următoarea etapă se stabilesc consumurile de materiale directe. Aceste consumuri, presupun
resursele necesare pentru a realiza sistemul cît și pentru prestarea serviciilor corespunzătoare.
În aceste calcule sunt indicare toare consumurile legate de materiale – materie primă, materiale
auzialiare și materiale de bază. Aceste consumuri includ prez ența a materialului în produsul final [11].
În tabelul 5.5, sunt indicate consumurile directe de materiale.

Tabelul 5 .5 – Consumuri directe de materiale
№
Denumirea
Unitate
de
măsură Preț de
unitate,
MDL
Cantitatea Valoarea
totală
MDL
1 USB Flash 32GB bucată 350 1 350
2 Hîrtie, formatul A4 pachet 60 1 60
3 Pix negru bucată 6 1 6
4 Copertare – 40 1 40
Total 456

În consumurile directe privind retribuirea muncii se includ, consumurile aferente a personalului
încadrat la proiect.
Este inclus salariile, fiecărui implicant, conform unui plan calendaristic care depinde pe constul
proiectului finit. La fel salarizarea depinde de timpul efectiv lucrat a implicanților.
Pentru efectuarea proiectului sau aplicației, sunt necesare persoane calificate în domeniu. Sunt
anumite cerințe, pentru elaborarea proiectului, care persoanele calificate, trebuie să le dețină [12].
Aceste cerințe sunt:
 studii superioare în domeniul IT;
 experiență în domeniul creării jocurilor;
 cunoștințe asupra softului de creare Un ity3D;
 abilități de creare a șabloanelor și diagramelor de utilizare ;
 spirit de echipă.
În tabelul 5. 6, este indict consumurile directe privind retribuirea muncii.

Tabelul 5.6 – Consumuri directe privind retribuirea muncii

Nr.
d/o
Funcția
angajatului
Volumul
de
lucru,
zile Salariul
contractual
pe unitate
de timp,
(lei / zi)
FRM,
lei
1 Conducător proiect 43 100 4300
2 Inginer programator 122 80 9760
Total 165 X 14060
Salariul pe perioada de dezvoltare a proiectului constituie = 14060 lei

56
Fondul social
FAS conducător proiect = FRM x Cfs(%) = 4300 x 23% = 989 lei
FAS inginer programator = FRM x Cfs(%) = 9760 x 23% = 2244.80 lei
FAS total = 14060 x 23% = 3233.80 lei
Cfs – Cota contribuțiilor de asigurări sociale de stat obligatorii 23% .

Asigurarea medicală obligatorie
FAM conducător proiect = FRM x Cam(%) = 4300 x 4.5% = 193.50 lei
FAM inginer programator = FRM x Cam(%) = 9760 x 4.5% = 439.20 lei
FAM total = 193.50 + 439.20 = 632.70 lei
Cam(%) – cota de asigurare obligatorie de asistență medicală.

Fondul de pensionare
FPconducător proiect = FRM x 6% = 4300 x 6% = 258 lei
FPinginer programator = FRM x 6% = 9760 x 6% = 585.60 lei
FRM total = FRM + FAS + FAM = 14060 + 3233.80 + 632.70 = 17926.50 lei

Venitul impozabil

Compartimentul dat, va calcula venitul net cu durata de 3 luni și suma impozitului pe venitul cu
durata de 3 luni al participantului inginer programator [13].
Participantul dat, reprezintă subiect de impozare. Astfel, în anul 2017 sunt date următoarele tax e și
scutiri la veniturile persoanei fizice inginer programator.
Salariul brut a unui inginer programator este în valoade de 9760 lei.

Pentru anul 2017 sunt stabilite următoarele cote de impozitare:
– 7% din venitul anual impozabil ce nu depășește suma de 3 1140 lei ;
– 18% din venitul anual impozabil ce depășește suma de 31 140 lei;
– fondul de pensionare – 6% din venit;
– fondul de asigurare medicală – 4.5% din venit;
– fiecare contribuabil are dreptula la o scutire anuală personală de 10620 lei;
– contribuabil are dre ptrul la o scutire anuală pentru fiecare persoană întreținută în sumă de 2340 lei;
– suma scutirii personale majore constituie anual 15840 lei.
Calculul venitului impozabil pentru 3 luni al proiectului :
VB3luni = VB x 3 : 7 = 4182.85 lei

57
FP3luni = FP x 3 : 7 = 250.97 lei
FAM 3luni = FAM x 3 : 7 = 188.22 lei
VI3luni = VB – FP – FAM = 4192.85 – 250.97 – 188.22 = 3746.66 lei
Calculul impozitului pe venit:
IV = VI – I (lei)
IV3luni = 3746.66 x 7% = 262.26lei
Venitul net pe durata de 3 luni:
VN = VB – IV3luni – FP – FAM = 4182.85 – 262.26 – 250.97 – 188.22 = 3481.40 lei

Pentru dezvoltarea proiectului, au fost efectuare consumuri indirecte. Consumurile indirecte
constituie consumurile, volumul c ărora nu depinde sau poate depinde neesențial de către volumul de
produție. Aici sunt incluse : consumurile pentru energie electric ă, serviciile internet și serviciile de transport.
În tabelul 5 .7, vor fi descrise consumurile indirecte antrenate în dezvoltarea proiectului.

Tabelul 5. 7 – Consumuri indirecte

Denumirea articolului
Unitatea de măsură
Cantitatea
Tarif / unitate, lei
Valoarea totală, lei
Energie electrică KW 55080 1.92 55.08
Servicii internet Abonament/lună 3 120 360
Servicii transport Abonament/lună 3 50 150
Total 565.08

O parte importantă a cheltuielilor indirecte o constituie uzura mijloacelor fixe și amortizarea
activelor nemateriale pe termen lung.
Aceasta reprezintă repartizarea sistematică a valorii uzurabile și a mijloacelor fixe, pe parcurs ul
duratei de funcționare utilă [14].
În funție de durata utilizării activului, poate fi calculată norma uzurii.
Pentru a calcula fondul de armotizare, este utilizată formula :
FA = (MFi : DFU) x T 1 (5.1)
Unde:
 FA – fondul armotiz ării, lei;
 Mfi – valoarea de intrare;
 T1 – durata proiectului;
 DFU – durata de funcționare utilă.
Calculul uzurei mijloacelor fixe:
U1 = (6000 : 60) x 3 = 300 lei

58
U2 = (20000 : 60) x 3 = 1000 lei
U4 = (4000 : 60) x 3 = 200 lei
U5 = (1200 : 60) x 3 = 60 lei
U7 = (1100 : 60) x 3 = 55 lei
Utotal = U1 + U2 + U4 + U5 + U 7 = 300 + 1000 + 200 + 60 + 55 = 1615 lei

Calculul fondului de amortizare conform formulei 5.1 :
FA3 = (770 : 12) x 3 = 192.50 lei
FA6 = (200 : 12) x 3 = 50 lei
FAtotal = FA 3 + FA 6 = 192.50 + 50 = 242.50 lei

Constul de producție reprezintă o totalitate de cheltuieli cerespunzătoare consumului de factori de
producție. Tabelul 5.8, v-a arăta toate chelt uielile pentru elaborarea unei copii.
Tabelul 5. 8 – Costul de producție

Articole de calculație Valoarea,
lei Ponderea,
%
Consumuri directe de materiale 456 2.19
Consumuri directe privind retribuirea, municii 14060 67.57
Contribuții de asigurări sociale de stat obligatorii (FAS) 3233.80 15.54
Prima de asigurare obligatorie de asistență medicală (FAM) 632.70 3.04
Consumuri indirecte 565.08 2.71
Uzura mijloacelor fixe (AMTL) 1615 7.76
Amortizarea activelor nemateriale pe termen lung 242.50 1.16
Total 20805.08 100

Calculul indicatorilor economico -financiari

Având la dispoziție costul de producție poate fi identificat prețul de realizare și profitul posibil. Metoda
“up-down” identifică prețul de realizare în comparație cu alte produse, similare, de pe piață [15].

𝑃𝑟𝑧=𝑃𝑙𝑣+𝑇𝑉𝐴 (5.2),
unde:
𝑃𝑟𝑧 – prețul de realizare;
𝑃𝑙𝑣 – prețul de livrare;
TVA – taxa pe valoarea adăugată de 20 %.

Conform formulei (5. 2), 𝑃𝑟𝑧= 80 + 16 = 96 𝑙𝑒𝑖
Calculăm venitul brut din vânzări:
𝑉𝑉𝐵 =𝑞×𝑃𝑟𝑧 (5.3),
unde:
q – numărul de copii planificate spre vânzare

59
Conform formul ei (5.3), 𝑉𝑉𝐵 = 96 × 10,000 = 960,000 𝑙𝑒𝑖
Profitul brut se calculează conform formulei:
𝑃𝑏=𝑉𝑉𝑁 −𝐶𝑇 (5.4),
unde:
𝑉𝑉𝑁 – suma netă a venitului din vânzări fără TVA;
CT – costul total de realizare a proiectului

Conform formulei (5.4), 𝑃𝑏= 96 × 10000 – 20805.08 = 939194.92
Profitul net se calculează prin deducerea taxelor și impozitelor în vigoare din suma impozabilă:

𝑃𝑛=𝑃𝑏−𝐼𝑣 (5.5),
unde:
𝐼𝑣 – impozitul pe venit conform legislației în vigoare de 15%
Conform formulei (5.5), 𝑃𝑛 = 939194.92 –140879.23 = 798,315.68
În final putem calcula rentabilitatea proiectului:
𝑅= (𝑃𝑛/𝐶𝑇) x 100% = (798315.68 : 20805.08) x 100 = 39%
5.5 Fișa de post
Denumirea Postului: inginer programator .
Relații ierarhice: e ste subordonat Managerului Dezvoltare Software .
Relații de colaborare: cu personalul de execuție al firmei .
Relații de prezentare: reprezintă firma în probleme de dezvoltare al aplicațiilor web și față de alte persoane
cu care intră în contact în interes de serviciu .
Scopul postului: t itularul postului are rolul de a elabora și implementa aplicațiile web
și de a oferi asistență de specialitate utlilizatorilor acestora.

Activități principale:
– elaborează aplicații în limbajul C#;
– oferă o asistență pentru utilizatorii a aplicațiilor Unity elaborate ;
– dezvolt ă o bază de cunoștințe ;
– redă o bună funcționare pentru baza de date și pentru proiectele create.
Atribuții principale :
a) elaborează aplicații în limbajul C#:
1) proiectează scheme logice și diagrame pentru structurarea cerințelor proiectului în secvențe logice ;
2) elaborează module de cod în limbaje de programare folosind medii de dezvoltare integrate ;
3) configurează aplicațiile necesare, testează aplicațiile și modifică programele ;
b) oferă o asistență pentru utilizatori la elaborarea aplicațiilor în Unity :

60
1) elaborează sarcinile necesare pentru utilizatori ;
2) asigură o asistență pentru utilizatori prin efectuarea unor lucrări practice sau prezentări ;
c) dezvoltă un bagaj de cunoștințe :
1) colectarea, structurarea și analizarea a informațiilor ;
2) asigură un acces pentru m embrii proiectului la sursele de informație ;
d) asigură echi pamentele la o bună funcționare:
1) respectarea instrucțiunilor de utilizare și raportarea la departamentul Service a tuturor defecțiunilor
apărute ;
2) asigură o bună funcționalitate o produselor software prin respectarea tehnicilor legate de protecția
contra virușilor și menținerea tehnicii de securitate.
Responsabilit ățile postului
Legat de activitățile specifice, răspunde de:
– buna funcționare a sistemului informatic de la locul său de muncă ;
– calitatea soluțiilor informatice oferite ;
– respectarea standardelor de calitate impuse prin specificațiile proiectelor .
Legat de disciplina muncii, răspunde de:
– îmbunătățirea a pregătirii sale de specialitate și profesionale ;
– păstrarea a informațiilor de confiden țialitate și a documentelor firmei;
– respectarea prevederile normativelor interne și procedurile de lucru;
– se implică la soluționarea situațiilor de criză care pot afecta firma ;
– utilizarea resurselor existente exclusiv în interesul firmei.

Autorita tea de post utilizeaz eazpă echipamentel e materiale și a calculatorului, care sunt puse la dispoziția
firmei.
Specificațiile postului

Nivelul de studii: superior (cu profil de Calculatoare, Informatică, Microelectronică)
Cursuri de pregătire: programare î n domeniu, bazele de date , analiza sistemelor de internet

Cunoștințe necesare:
 medii de programare Unity3D;
 baze de date și cunoșrințe;

61
 javascript, HTML, C#, PHP și CSS ;
 cunoștințe avansate în MS Office;
 limba engleză la nivel avansat (scris, citit).
Deprindirile și aptitudinile necesare:
 tehnica gîndire analitică;
 generala aptitudine de studiere;
 comunicare;
 planificarea și organizarea activităților;
 culegerea și interpretarea de informații;
 acordarea și transmiterea de informații.
Cerințele d e exercitare :
 rezistență la stres;
 inițiativă ;
 flexibilitate mentală;
 echilibru emoțional;
 bună capacitate de a corela cu oamenii;
 claritate și u șurință în exprimare.

Caracteristicile personalit ății: orientarea spre sarcină, muncă calitativă, concentrare în muncă, încrederea
în sine, interes pentru soluționarea problemelor, informare, spirit de echipă, tact, amabilitate, ambiție în
cadrul muncii .

62
Concluzii

Această lucrare de practică mi -a oferit o gamă larga de posibilități și experiență în domeniu de
elaborare a jocurilor 3D cu o vastă și interesantă intelegneță artificială.
Jocurile de computer constituie o categorie de aplicații software care este destinată distracției, unele
din ele pot fi chiar și educaționale.
Încă din copilărie, invăță m să comunicăm, să interacționăm cu lumea ce ne inconjoară prin
intermediul jocului. Începînd cu prima etapă de formare a modului de gîndire, întîlnim noi modalități de a
ne adopta lanțului de provocări pe care viața le pregătește.
În primul rînd, atunci cînd suntem puși în fața unor situații reale,cotidiene, metoda prin care mintea
unui copil le ințelege este jocul.
Efectuând acest proiect de curs am studiat un Editor nou, sub numele de Unity3D Editor care m -a
ajutat la crearea unui joc simplu 2D. El ofer ă un șir de funcționalități gata de utilizare iar dacă acestea nu
ne convin, , putem implementa funcționalitățile personale.
Pe lângă faptul că oferă un șir vast de funcționalități , mai are și o documentație bună și ușoară
pentru începătorii în industria dată.
Chiar dacă am întîmpinat o mulțime de greutăți în proiectarea mașinei și logica a intelegenței
artificiale, am folosit o sumedenie de algoritmi, în formă de cod sau “Tutorial ”. Toate acestea sunt p entru
soluționarea problemelor, bagurilor și efectua rea un ui sistem de intelegență artificială destul de deștept și
pentru a crea o atmosferă interesantă și plăcută pentru jucator.
Desi nu am prea avut ocazia sa folosesc Unity pentru prototyping la munca, este alegerea mea pentru
proiectele personale, atunc i cand am timp pentru ele acasa. Il folosesc in combinatie cu pluginul de visual
scripting PlayMaker pentru a crea mici ‘jucarii’ care au potentialul de a deveni ceva mai mult la un moment
dat.
Fiecare proiect are un ciclu de viață a l său. Aceasta este car acterizată de popularitatea sa pe piață și
aducerea unui profit bun la companie . Ciclul de via ță arată durabilitiatea proiectului începînd cu lansarea
lui pe piață . Efectuînd calculul profitului din vînzări, am obținut că prețul de realizare a unei copii e ste de
96 de lei, ceea ce ne arată că este rentabil din punc de vedere economic, primind o dobîndă de 40% la
realizarea proiectului.

63
Bibliografie

1 Intelegența Artificială în Unity . [Resursa electronic ă]. – Regim de acces:
https://docs.unity3d.com/Manual/UpgradeGuide5 -AI.html
2 Unity eng. [Resursa electronică]. – Regim de acces:
https://unity3d.com/
3 How to start your Ga me Development . [Resursa electronică]. – Regim de acces:
https://unity3d.com/learn/tutorials/topics/developer -advice/how -start-your-game -development
4 UnityScriptingDocumentation . [Resursa electronică]. – Regim de acces:
https://docs.unity3d.com/ScriptReference/
5 Testarea functionala a m -aplicatiei. [Resursa electronică]. – Regim de acces:
http://revistaie.ase.ro/content/28/Pocatilu.pdf
6 Programare C# . [Resursa electronică]. – Regim de acces:
http://www.math.uaic.ro /~cgales/csharp/Curs1.pdf
7. Legea nr. 355 -XVI din 23.12.2005 cu privire la sistemul de salarizare în sectorul bugetar // Monitorul
Oficial al R.Moldova nr.35 -38/148 din 03.03.2006.
8. Legea Republicii Moldova cu privire la antreprenoriat și întreprinderi nr. 845 -XII din 3.01.1992.
9. Legea Republicii Moldova cu privire la înregistrarea de stat a persoanelor juridice și a întreprinzătorilor
individuali nr. 220 din 19.10.2007.
10. Legea Republicii Moldova privind societățile cu răspundere limitată nr. 135 din 14.06.2007.
11. Legea Republicii Moldova privind societățile pe acțiuni nr. 1134 -XIII din 2.04.1997.
12. Hotărîrea Guvernului nr. 473 din 11.06.2002 „Cu privire la salarizarea angajaților din unitățile cu
autonomie financiară” // Monitorul Oficial al Republicii Moldova nr. 79 din 2002.
13. Hotărîrea Guvernului nr.15 din 19 februarie 2009 „Privind stabilire a cuantumului salariului minim pe
țară”.
14. Dodu A., Gumeniuc I. Managementul întreprinderii. UTM, 2015.
15. Dodu A., Gumeniuc I. Managementul general. Editura „Tehnica -UTM”, 2016.

64
Anexa A
CarEngine

public class CarEngine
{

public int maxRPM = 7000;
public int minRPM = 700;

public float currentRPM;
public float maxEngineBrake = 30f;

public CarControl m_Car;

//float avilableTorquePercent = 1f;

float tmpRPM;
//float speedRang;
public void updateCurrentRPM()
{
// avilableTorquePercent = 1f;
tmpRPM = (m_Car.speedInKmH * m_Car.car.transmission.getCurrentGearRatio() *
m_Car.car.transmission.differentialRatio *(1000/60))
/
(m_Car.car.motorWheels[0].wheelCollider.radius* 2*Mathf.PI);
currentRPM = Mathf.Lerp(currentRPM, tmpRPM, Time.deltaTime +0.1f);
/* speedRang = m_Car.car.transmission.getCurrentGearSpeedRang();
if (speedRang == 0)
{
currentRPM = minRPM;
return;
}
currentRPM = maxRPM * m_Car.speedInKmH / speedRang;
*/
if (currentRPM < minRPM)
currentRPM = minRPM;
if (currentRPM > maxRPM)
currentRPM = maxRPM;
}

public float getEngineTorque()
{
if (m_Car.car.hp > 0)
return getEngineTorque(currentRPM);
return m_Car.car.RPM_Curve.Evaluate(currentRPM);
}

public float getEngineTorque (float rpm)
{
if (rpm > maxRPM)
return 0;
return m_Car.car.hp * 5252 / rpm;
}
float avilableTorque;
public float wheelsTorque;
public void updateWheelsTorque()
{
avilableTorque= wheelsTorque = get EngineTorque() *
m_Car.car.transmission.getCurrentGearRatio() *
m_Car.car.transmission.differentialRatio;

}

public float getAvilableTorque(float percent)

65
{
float desiredTorque = wheelsTorque * percent;
if (desiredTorque > avilableTorque)
{
desiredTorque = avilableTorque;
}
avilableTorque -= desiredTorque;
return desiredTorque;
}

public float getEngineBrakeTorque()
{
return Mathf.Lerp(0,maxEngineBrake,currentRPM/maxRPM);
}

public float getEngineWheelsBrakeTorque()
{
return getEngineBrakeTorque() *
m_Car.car.transmission.getCurrentGear Ratio() *
m_Car.car.transmission.differentialRatio/ m_Car.car.motorWheelsCount;
}

66
Anexa B
CarControl
public class CarControl : MonoBehaviour
{
public event CarStatusChangeListner backwardListner;
public event CarStatusChangeListner forwardListner;
public event CarStatusChangeListner brakingListner;
public event CarStatusChangeListner stoppedListner;
public event CarStatusChang eListner neutralListner;

// public event CarStatusChangeListner toggleTCSListner;

public event OnFrontLightsTrigger frontLightsTrigger;

public Car car;

public Rigidbody m_Rigidbody;

public float BrakeInput;//{ get; private set; }
public float CurrentSteerAngle;// { get { return m_SteerAngle; } }

public Transform startPoint;

public CarStause statuse = CarStause.Stopped;

public float AccelInput;// { get; private s et; }
public float old_speed=0;

// void Awake()
void OnEnable()
{

car = GetComponent<Car>();

m_Rigidbody = GetComponent<Rigidbody>();
car.engine.m_Car = GetComponent<CarControl>();

car.handBrake.m _Car = GetComponent<CarControl>();
enableLights();
//car.accessories.OnEnabled();
}

void enableLights()
{
FrontLight[] frontLights = GetComponentsInChildren<FrontLight>();
BrakeLight[] brakeLights = GetComponentsInChildren<BrakeLight>();
RevLights[] revLights = GetComponentsInChildren<RevLights>();
loopLights(frontLights);
loopLights(brakeLights);
loopLights(revLights);
}
void loopLights(CarLight[] lights)
{
foreach (CarLight carLight in lights)
carLight.enabled = true;
}

void Start()
{

// optimizeCM();
foreach (Wheel wheel in car.wheels)
{
wheel.m_Car = GetComponent<CarControl>();
wheel.brake.m_Car= GetComponent<CarControl>();
}
car.transmission.onStart(GetComponent<CarControl>());

67
car.accessories.enableAtStart();

}
void optimizeCM()
{
Transform WheelColiders = car.transform.FindChild("WheelColiders");
Vector3 pos = WheelColiders.localPosition;
pos.y += car.centerOfMass.y;
pos.z += car.centerOfMass.z;
m_Rigidbody.centerOfMass = pos;

}
public void frontLightsOn()
{
frontLightsTrigger(true);
}
public void frontLightsOff()
{
frontLightsTrigger(false);
}
void Update()
{
for (int i = 0; i < 4; i++)
{
car.wheels[i].appl yLocalPositionToVisuals();
}

68
Anexa C
CameraControl
public class CameraControl : MonoBehaviour
{

public Transform car;
public float distance = 12.5f;
public float height = 3.7f;

public float rotaionDamping = 0.2f;
public float heightDamping = 0.4f;
public float zoomRation = 0.35f;
public float zRotaionDamping = 3f;
float oldZ = 0;
Vector3 rotaionVector;
CarControl m_Car;

Camera _camera;

public float defaultFOV = 50f;

void OnEnable()
{

}

void Start()
{
car = transform.root.GetComponentInChildren<Car>().transform;
oldZ = car.rotation.eulerAngles.y;
m_Car = car.GetComponent<CarControl>();
target = car.FindChild("camToLookAt");
_camera = GetComponent<Camera>();
}

void Update()
{

// inRaceMove();
}

Quaternion currentRotaion;
Transform target;
float wantedAngle;
float wantedHeight;
float wantedX;

float wantedZAngle;

float myAngle;
float myHeight;
float myX;
float myZAngle;

void inRaceMove()
{
wantedAngle = rotaionVector.y;
wantedHeight = car.position.y + height;
wantedX = car .position.x;

wantedZAngle = rotaionVector.z;

myAngle = transform.eulerAngles.y;
myHeight = transform.position.y;
myX = transform.position.x;
myZAngle = oldZ;

69
myAngle = Mathf.LerpAngle(myAngle, wantedAngle, rotaionDamping * Time.deltaTime);
myHeight = Mathf.Lerp(myHeight, wantedHeight, heightDamping * Time.deltaTime);
myX = Mathf.Lerp(myX, wantedX, heightDamping * Time.deltaTime);
myZAngle = Mathf.LerpAngle(myZAngle, wantedZAngle, zRotaionDamping * Time.deltaTime);

currentRotaion = Quaternion.Euler(0, myAngle, 0);
transform.position = car.position;
transform.position -= currentRotaion * Vector3.forward * di stance;
transform.position += height * Vector3.up;

transform.position.Set(myX, myHeight, transform.position.z);

transform.LookAt(target);
transform.Rotate(0, 0, myZAngle – oldZ * distance);
oldZ = myZAngle;
}

70
Anexa D
PlayerCar
public class PlayerCar : MonoBehaviour {
[SerializeField]
public Image tcs_off_texture;
[SerializeField]
public Image tcs_texture;
[SerializeField]
public Image abs_texture;

Car car;

public class BlinksWrapper
{
public bool isVisable;
public bool isRunning;
public bool stop;
public float duration = 1f;
public BlinksWrapper(bool isVisable) { th is.isVisable = isVisable; }
}
public BlinksWrapper is_abs = new BlinksWrapper(false);
public BlinksWrapper is_tcs = new BlinksWrapper(false);

void setupPlayer()
{

CarControl carControl = car.GetComponent<CarControl>() ;

// car.GetComponent<CarAudio>().enabled = true;
//car.GetComponent<CarEffects>().enabled = true;
car.GetComponent<TCSSystem>().enabled = true;

car.gameObject.AddComponent<UserInput>();

carControl.enabled = true;

SpeedoMeter speedoMeter = GameObject.FindObjectOfType<SpeedoMeter>();
if (speedoMeter != null)
{
speedoMeter.m_Car = carControl;
speedoMeter.enabled = true;
}
}

void Awake()
{

car = GetComponent<Car>();

setupPlayer();

tcs_off_texture = GameObject.Find("tcsOff").GetComponent<Image>();
tcs_off_texture.enabled = false;
tcs_texture = GameObject.Find("tcs").GetCompon ent<Image>();
tcs_texture.enabled = false;
abs_texture = GameObject.Find("abs").GetComponent<Image>();
abs_texture.enabled = false;

}
void OnGUI()
{
if (car.accessories.tcsSystem != null && car.accessories.tcsSystem.m_TractionControl
== 0)
tcs_off_texture.enabled = true;
else

71
{
if (car.accessories.tcsSystem != null)
tcs_off_texture.enabled = false;
if (is_tcs.isVisable)
tcs_texture.enabled = true;
else tcs_texture.enabled = false;
}

if (is_abs.isVisable)
abs_texture.enabled = true;
else abs_texture.enabled = false;

}

72
Anexa E
Vehicle Damage
public class VehicleDamage : MonoBehaviour
{
Transform tr;
Rigidbody rb;
VehicleParent vp;

[Range(0, 1)]
public float strength;
public float damageFactor = 1;

public float maxCollisionMagnitude = 100;

[Tooltip("Maximum collision points to use when deforming, has large effect on
performance")]
public int maxCollisionPoints = 2;

[Tooltip("Collisions underneath this local y -position will be ignored")]
public float collisionIgnoreHeight;

[Tooltip("If true, grounded wheels will not be damaged, but can still be displaced")]
public bool ignoreGroundedWheels;

[Tooltip("Minimum time in seconds between collisions")]
public float collisionTimeGap = 0.1f;
float hitTime;

[Tooltip("Whether the edges of adjacent deforming parts should match")]
public bool seamlessDeform;

[Tooltip("Add some perlin noise to deformation")]
public bool usePerlinNoise = true;

[Tooltip("Recalculate normals of deformed mesh es")]
public bool calculateNormals = true;

[Tooltip("Parts that are damaged")]
public Transform[] damageParts;

[Tooltip("Meshes that are deformed")]
public MeshFilter[] deformMeshes;
bool[] damagedMeshes;
Mesh[] tempMeshes;
meshVerts[] meshVertices;

[Tooltip("Mesh colliders that are deformed (Poor performance, must be convex)")]
public MeshCollider[] deformColliders;
bool[] damagedCols;
Mesh[] tempCols;
meshVerts[] colVertices;

[Tooltip("Parts that are displaced")]
public Transf orm[] displaceParts;
Vector3[] initialPartPositions;

ContactPoint nullContact = new ContactPoint();

void Start()
{
tr = transform;
rb = GetComponent<Rigidbody>();
vp = GetComponent<VehicleParent>();

//Tell VehicleParent not to play crashing sounds because this script takes care
of it
vp.playCrashSounds = false;
vp.playCrashSparks = false;

73

//Set up mesh data
tempMeshes = new Mesh[deformMeshes.Length];
damagedMeshes = new bool[deformMeshes.Length];
meshVertices = new meshVerts[deformMeshes.Length];
for (int i = 0; i < deformMeshes.Length; i++)
{
tempMeshes[i] = deformMeshes[i].mesh;
meshVertices[i] = new meshVerts();
meshVertices[i].verts = deformMeshes[i].mesh.vertices;
meshVertices[i].initialVerts = deformMeshes[i].mesh.vertices;
damagedMeshes[i] = false;
}

//Set up mesh collider data
tempCols = new Mesh[deformColliders.Length];
damagedCols = new bool[deformColliders.Length];
colVertices = new meshVerts[deformColliders.Length];
for (int i = 0; i < deformColliders.Length; i++)
{
tempCols[i] = (Mesh)Instantiate(deformColliders[i].sharedMesh);
colVertices[i] = new meshVerts();
colVertices[i].verts = deformColliders[i].sharedMesh.vertices;
colVertices[i].initialVerts = deformC olliders[i].sharedMesh.vertices;
damagedCols[i] = false;
}

//Set initial positions for displaced parts
initialPartPositions = new Vector3[displaceParts.Length];
for (int i = 0; i < displaceParts.Length; i++)
{
initialPartPositions[i] = displaceParts[i].localPosition;
}
}

74
Anexa F
VehicleWaypoint
public class VehicleWaypoint : MonoBehaviour
{
public VehicleWaypoint nextPoint;
public float radius = 10;

[Tooltip("Percentage of a vehicle's max speed to drive at")]
[Range(0, 1)]
public float speed = 1;

void OnDrawGizmos()
{
//Visualize waypoint
Gizmos.color = Color.yellow;
Gizmos.DrawWireSphere(transform.position, radius);

//Draw line to next point
if (nextPoint)
{
Gizmos.color = Color.magenta;
Gizmos.DrawLine(transform.position, nextPoint.transform.position);
}}}

75
Anexa G
GasMotor
//Motor subclass for internal combustion engines
public class GasMotor : Motor
{
[Header("Performance")]

[Tooltip("X -axis = RPM in thousands, y -axis = torque. The rightmost key represents the
maximum RPM")]
public AnimationCurve torqueCurve = AnimationCurve.EaseInOut(0, 0, 8, 1);

[Range(0, 0.99f)]
[Tooltip("How quickly the engine adjusts its RPMs")]
public float inertia;

[Tooltip("Can the engine turn backwards?")]
public bool canReverse;
DriveForce targetDrive;
[System.NonSerialized]
public float maxRPM;

public DriveForce[] outputDrives;

[Tooltip("Exponent for torque output on each wheel")]
public float driveDividePower = 3;
float actualAccel;

[Header("Transmission")]

public GearboxTransmission transmission;
[System.NonSerialized]
public bool shifting;

[Tooltip("Increase sound pitch between shifts")]
public bool pitchIncreaseBetweenShift;

public override void Start()
{
base.Start();
targetDrive = GetComponent<DriveForce>();
//Get maximum possible RPM
GetMaxRPM();
}

public override void FixedUpdate()
{
base.FixedUpdate();

//Calculate proper inpu t
actualAccel = Mathf.Lerp(vp.brakeIsReverse && vp.reversing && vp.accelInput <= 0
? vp.brakeInput : vp.accelInput, Mathf.Max(vp.accelInput, vp.burnout), vp.burnout);
float accelGet = canReverse ? actualAccel : Mathf.Clamp01(actualAccel);
actualInput = inputCurve.Evaluate(Mathf.Abs(accelGet)) * Mathf.Sign(accelGet);
targetDrive.curve = torqueCurve;

if (ignition)
{
float boostEval = boostPowerCurve.Evaluate(Mathf.Abs(vp.localVelocity.z));
//Set RPM
targetDrive.rpm = Mathf.Lerp(targetDrive.rpm, actualInput * maxRPM * 1000 *
(boosting ? 1 + boostEval : 1), (1 – inertia) * Time.timeScale);
//Set torque
if (targetDrive.feedbackRPM > targetDrive.rpm)
{
targetDrive.torque = 0;
}
else
{

76
targetDrive.torque = torqueCurve.Evaluate(targetDrive.feedbackRPM *
0.001f – (boosting ? boostEval : 0)) * Mathf.Lerp(targetDrive.torque, power *
Mathf.Abs(System.Math.Sign(actualInput)), (1 – inertia) * Time.timeScale) * (boosting ? 1 +
boostEval : 1) * health;
}

//Send RPM and torque through drivetrain
if (outputDrives.Length > 0)
{
float torqueFactor = Mathf.Pow(1f / outputDrives.Length,
driveDividePower);
float tempRPM = 0;

foreach (DriveForce curOutput in out putDrives)
{
tempRPM += curOutput.feedbackRPM;
curOutput.SetDrive(targetDrive, torqueFactor);
}

targetDrive.feedbackRPM = tempRPM / outputDrives.Length;
}

if (transmission)
{
shifting = transmission.shiftTime > 0;
}
else
{
shifting = false;
}
}
else
{
//If turned off, set RPM and torque to 0 and distribute it through
drivetrain
targetDrive.rpm = 0;
targetDrive.torque = 0;
targetDrive.feedbackRPM = 0;
shifting = false;

if (outputDrives.Length > 0)
{
foreach (DriveForce curOutput in outputDrives)
{
curOutput.SetDrive(targetDrive);
}
}
}
}

77
Anexa H
VehicleParent
void Start()
{
tr = transform;
rb = GetComponent<Rigidbody>();

//Create normal orientation object
GameObject normTemp = new GameObject(tr.name + "'s Normal Orientation");
norm = normTemp.transform;

SetCenterOfMass();

//Instantiate tow vehicle
if (towVehicle)
{
newTow = Instantiate(towVehicle, Vector3.zero, tr. rotation) as GameObject;
newTow.SetActive(false);
newTow.transform.position =
tr.TransformPoint(newTow.GetComponent<Joint>().connectedAnchor –
newTow.GetComponent<Joint>().anchor);
newTow.GetComponent<Joint>().connectedBody = rb;
newTow.SetActi ve(true);
newTow.GetComponent<VehicleParent>().inputInherit = this;
}

if (sparks)
{
sparks.transform.parent = null;
}

if (wheelGroups.Length > 0)
{
StartCoroutine(WheelCheckLoop());
}
}

void Update()
{
//Shift single frame pressing logic
if (stopUpshift)
{
upshiftPressed = false;
stopUpshift = false;
}

if (stopDownShift)
{
downshiftPressed = false;
stopDownShift = false;
}

if (upshiftPressed)
{
stopUpshift = true;
}

if (downshiftPressed)
{
stopDownShift = true;
}

if (inputInherit)
{
InheritInputOneShot();
}

//Norm orientation visualizing

78
//Debug.DrawRay(norm.position, norm.forward, Color.blue);
//Debug.DrawRay(norm.position, norm.up, Color.green);
//Debug.DrawRay (norm.position, norm.right, Color.red);
}

void FixedUpdate()
{
if (inputInherit)
{
InheritInput();
}

if (wheelLoopDone && wheelGroups.Length > 0)
{
wheelLoopDone = false;
StartCoroutine(WheelCheckLoop());
}

GetGroundedWheels();

if (groundedWheels > 0)
{
crashing = false;
}

localVelocity = tr.InverseTransformDirection(rb.velocity –
wheelContactsVelocity);
localAngularVel = tr.InverseTransformDirection(rb.angularVelocity);
velMag = rb.velocity.magnitude;
sqrVelMag = rb.velocity.sqrMagnitude;
forwardDir = tr.forward;
rightDir = tr.right;
upDir = tr.up;
forwardDot = Vector3.Dot(forwardDir, GlobalControl.worldUpDir);
rightDot = Vector3.Dot(rightDir, GlobalControl.worldUpDir);
upDot = Vector3.Dot(upDir, G lobalControl.worldUpDir);
norm.transform.position = tr.position;
norm.transform.rotation = Quaternion.LookRotation(groundedWheels == 0 ? upDir :
wheelNormalAverage, forwardDir);

//Check if performing a burnout
if (groundedWheels > 0 && !hover && ! accelAxisIsBrake && burnoutThreshold >= 0 &&
accelInput > burnoutThreshold && brakeInput > burnoutThreshold)
{
burnout = Mathf.Lerp(burnout, ((5 – Mathf.Min(5,
Mathf.Abs(localVelocity.z))) / 5) * Mathf.Abs(accelInput), Time.fixedDeltaTime * (1 –
burnoutSmoothness) * 10);
}
else if (burnout > 0.01f)
{
burnout = Mathf.Lerp(burnout, 0, Time.fixedDeltaTime * (1 –
burnoutSmoothness) * 10);
}
else
{
burnout = 0;
}

if (engine)
{
burnout *= engine.health;
}

//Check if reversing
if (brakeIsReverse && brakeInput > 0 && localVelocity.z < 1 && burnout == 0)
{
reversing = true;
}
else if (localVelocity.z >= 0 || burnout > 0)
{ reversing = false; }}

79
Anexa I
FollowAI
public class FollowAI : MonoBehaviour
{
Transform tr;
Rigidbody rb;
VehicleParent vp;
VehicleAssist va;
public Transform target;
Transform targetPrev;
Rigidbody targetBody;
Vector3 targetPoint;
bool targetVisible;
bool targetIsWaypoint;
VehicleWaypoint targetWaypoint;

public float fo llowDistance;
bool close;

[Tooltip("Percentage of maximum speed to drive at")]
[Range(0, 1)]
public float speed = 1;
float initialSpeed;
float prevSpeed;
public float targetVelocity = -1;
float speedLimit = 1;
float brakeTime;

[Tooltip("Mask for which objects can block the view of the target")]
public LayerMask viewBlockMask;
Vector3 dirToTarget;//Normalized direction to target
float lookDot;//Dot product of forward direction and dirToTarget
float steerDot;//Dot product of r ight direction and dirToTarget

float stoppedTime;
float reverseTime;

[Tooltip("Time limit in seconds which the vehicle is stuck before attempting to
reverse")]
public float stopTimeReverse = 1;

[Tooltip("Duration in seconds the vehicle will reverse after getting stuck")]
public float reverseAttemptTime = 1;

[Tooltip("How many times the vehicle will attempt reversing before resetting, -1 = no
reset")]
public int resetReverseCount = 1;
int reverseAttempts;

[Tooltip("Seconds a vehicle will be ro lled over before resetting, -1 = no reset")]
public float rollResetTime = 3;
float rolledOverTime;

void Start()
{
tr = transform;
rb = GetComponent<Rigidbody>();
vp = GetComponent<VehicleParent>();
va = GetComponent<VehicleAssist>();
initialSpeed = speed;

InitializeTarget();
}

void FixedUpdate()
{
if (target)
{

80
if (target != targetPrev)
{
InitializeTarget();
}

targetPrev = target;

//Is the target a waypoint?
targetIsWaypoint = target.GetComponent<VehicleWaypoint>();
//Can I see the target?
targetVisible = !Physics.Linecast(tr.position, target.position,
viewBlockMask);

if (targetVisible || targetIsWaypoint)
{
targetPoint = targetBody ? target.position + targetBod y.velocity :
target.position;
}

if (targetIsWaypoint)
{
//if vehicle is close enough to target waypoint, switch to the next
one
if ((tr.position – target.position).sqrMagnitude <=
targetWaypoint.radius * targetWaypoint.radius)
{
target = targetWaypoint.nextPoint.transform;
targetWaypoint = targetWaypoint.nextPoint;
prevSpeed = speed;
speed = Mathf.Clamp01(targetWaypoint.speed * initialSpeed);
brakeTime = prevSpeed / speed;

if (brakeTime <= 1)
{
brakeTime = 0;
}
}
}

81
Anexa J
FlipControl
//Class for in -air rotation of vehicles
public class FlipControl : MonoBehaviour
{
Transform tr;
Rigidbody rb;
VehicleParent vp;

public bool disableDuringCrash;
public Vector3 flipPower;

[Tooltip("Continue spinning if input is stopped")]
public bool freeSpinFlip;

[Tooltip("Stop spinning if input is stopped and vehicle is upright")]
public bool stopFlip;

[Tooltip("How quickly the vehicle will rotate upright in air")]
public Vector3 rotationCorrection;
Quaternion velDir;

[Tooltip("Distance to check for ground for reference normal for rotation correction")]
public float groundCheckDistance = 100;

[Tooltip("Minimum dot product between ground normal and global up direction for
rotation correction")]
public float groundSteepnessLimit = 0.5f;

[Tooltip("How quickly the vehicle will dive in the direction it's soaring")]
public float diveFactor;

void Start()
{
tr = transform;
rb = GetComponent<Rigidbody>();
vp = GetComponent<VehicleParent>();
}

void FixedUpdate()
{
if (vp.groundedWheels == 0 && (!vp.crashing || (vp.crashing &&
!disableDuringCrash)))
{
velDir = Quaternion.LookRotation(GlobalControl.worldUpDir, rb.velocity);

if (flipPower != Vec tor3.zero)
{
ApplyFlip();
}

if (stopFlip)
{
ApplyStopFlip();
}

if (rotationCorrection != Vector3.zero)
{
ApplyRotationCorrection();
}

if (diveFactor > 0)
{
Dive();
}
}
}

82
void ApplyFlip()
{
Vector3 flipTorque;

if (freeSpinFlip)
{
flipTorque = new Vector3(
vp.pitchInput * flipPower.x,
vp.yawInput * flipPower.y,
vp.rollInput * flipPower.z
);
}
else
{
flipTorque = new Vector3(
vp.pitchInput != 0 && Mathf.Abs(vp.localAngularVel.x) > 1 &&
System.Math.Sign(vp.pitchInput * Mathf.Sign(flipPower.x)) !=
System.Math.Sign(vp.localAngularVel.x) ? -vp.localAngularVel.x * Mathf.Abs(flipPower.x) :
vp.pitchInput * flipPower.x – vp.localAngularVel.x * (1 – Mathf.Ab s(vp.pitchInput)) *
Mathf.Abs(flipPower.x),
vp.yawInput != 0 && Mathf.Abs(vp.localAngularVel.y) > 1 &&
System.Math.Sign(vp.yawInput * Mathf.Sign(flipPower.y)) !=
System.Math.Sign(vp.localAngularVel.y) ? -vp.localAngularVel.y * Mathf.Abs(flipPower.y) :
vp.yawInput * flipPower.y – vp.localAngularVel.y * (1 – Mathf.Abs(vp.yawInput)) *
Mathf.Abs(flipPower.y),
vp.rollInput != 0 && Mathf.Abs(vp.localAngularVel.z) > 1 &&
System.Math.Sign(vp.rollInput * Mathf.Sign(flipPower.z)) !=
System.Math.Sign(vp.localA ngularVel.z) ? -vp.localAngularVel.z * Mathf.Abs(flipPower.z) :
vp.rollInput * flipPower.z – vp.localAngularVel.z * (1 – Mathf.Abs(vp.rollInput)) *
Mathf.Abs(flipPower.z)
);
}

rb.AddRelativeTorque(flipTorque, ForceMode.Acceleration);
}

void App lyStopFlip()
{
Vector3 stopFlipFactor = Vector3.zero;

stopFlipFactor.x = vp.pitchInput * flipPower.x == 0 ?
Mathf.Pow(Mathf.Clamp01(vp.upDot),Mathf.Clamp(10 – Mathf.Abs(vp.localAngularVel.x), 2, 10)) *
10 : 0;
stopFlipFactor.y = vp.yawInput * flipP ower.y == 0 && vp.sqrVelMag > 5 ?
Mathf.Pow(Mathf.Clamp01(Vector3.Dot(vp.forwardDir,velDir * Vector3.up)), Mathf.Clamp(10 –
Mathf.Abs(vp.localAngularVel.y), 2, 10)) * 10 : 0;
stopFlipFactor.z = vp.rollInput * flipPower.z == 0 ?
Mathf.Pow(Mathf.Clamp01(vp .upDot),Mathf.Clamp(10 – Mathf.Abs(vp.localAngularVel.z), 2, 10)) *
10 : 0;

rb.AddRelativeTorque(new Vector3( -vp.localAngularVel.x * stopFlipFactor.x, –
vp.localAngularVel.y * stopFlipFactor.y, -vp.localAngularVel.z * stopFlipFactor.z),
ForceMode.Acceler ation);
}

void ApplyRotationCorrection()
{
float actualForwardDot = vp.forwardDot;
float actualRightDot = vp.rightDot;
float actualUpDot = vp.upDot;

if (groundCheckDistance > 0)
{
RaycastHit groundHit;

if (Physics.Raycast(tr.position, (-GlobalControl.worldUpDir +
rb.velocity).normalized, out groundHit, groundCheckDistance, GlobalControl.groundMaskStatic))
{
if (Vector3.Dot(groundHit.normal, GlobalControl.worldUpDir) >=
groundSteepnessLimit)

83
{
actualForwardDot = Vector3. Dot(vp.forwardDir,
groundHit.normal);
actualRightDot = Vector3.Dot(vp.rightDir, groundHit.normal);
actualUpDot = Vector3.Dot(vp.upDir, groundHit.normal);
}
}
}

rb.AddRelativeTorque(new Vector3(
vp.pitchInput * flipPower.x == 0 ? ac tualForwardDot * (1 –
Mathf.Abs(actualRightDot)) * rotationCorrection.x – vp.localAngularVel.x *
Mathf.Pow(actualUpDot, 2) * 10 : 0,
vp.yawInput * flipPower.y == 0 && vp.sqrVelMag > 10 ?
Vector3.Dot(vp.forwardDir, velDir * Vector3.right) * Mathf.Abs(act ualUpDot) *
rotationCorrection.y – vp.localAngularVel.y * Mathf.Pow(actualUpDot, 2) * 10 : 0,
vp.rollInput * flipPower.z == 0 ? -actualRightDot * (1 –
Mathf.Abs(actualForwardDot)) * rotationCorrection.z – vp.localAngularVel.z *
Mathf.Pow(actualUpDot, 2) * 10 : 0
), ForceMode.Acceleration);
}

void Dive()
{
rb.AddTorque(velDir * Vector3.left * Mathf.Clamp01(vp.velMag * 0.01f) *
Mathf.Clamp01(vp.upDot) * diveFactor, ForceMode.Acceleration);
}
}

84
Anexa K
Imagini adi ționale a proiectului

Figura K.1 – Mașina propriu -zisă

Figura K.2 – Elementele vizuale în timpul conducerii mașinei

85

Figura K.3 – Scena propiu -zisă

Figura K.4 – Elemente de Intelegență artificială