FUNDAȚIA PENTRU CULTURĂ ȘI ÎNVĂȚĂMÂNT IOAN SLAVICI [624045]

FUNDAȚIA PENTRU CULTURĂ ȘI ÎNVĂȚĂMÂNT “IOAN SLAVICI”
TIMIȘOARA
UNIVERSITATEA “IOAN SLAVICI” TIMIȘOARA
FACULTATEA DE INGINERIE
DOMENIUL CALCULATOARE ȘI TEHNOLOGIA INFORMAȚIEI
FORMA DE ÎNVĂȚĂMÂNT – ZI

„Bomber Man”

CONDUCĂTOR ȘTIINȚIFIC
prof./conf./ ing. dr . Mircea Vlăduțiu

ABSOLVENT: [anonimizat]

2018

2
Cuprins

1. Introducere ………………………….. ………………………….. ………………………….. ……………………… 3
1.1. Prefață ………………………….. ………………………….. ………………………….. ……………………….. 3
1.2. Scurt istor ic ………………………….. ………………………….. ………………………….. ……………….. 5
1.3. ActionScript 3 ………………………….. ………………………….. ………………………….. ……………. 6
2 Repere majore pentru proiect ………………………….. ………………………….. ………………………. 9
2.1 Concept ………………………….. ………………………….. ………………………….. ……………………… 9
2.2 Obiective / sc opul proiectului ………………………….. ………………………….. …………………… 9
2.2.1 Definiții, acronime și abrevieri ………………………….. ………………………….. …………… 9
2.2.2 Priorități ………………………….. ………………………….. ………………………….. ……………. 10
2.3 Cerințe / Requirements (RQC): ………………………….. ………………………….. ……………….. 10
2.4 Cerințe non funcționale ………………………….. ………………………….. ………………………….. 12
2.5 Arhitectura ………………………….. ………………………….. ………………………….. ……………….. 13
2.5.1 Class Diagram ………………………….. ………………………….. ………………………….. ……. 13
2.5.2 Activity Diagram ………………………….. ………………………….. ………………………….. .. 14
2.5.3 Sequence Diagram ………………………….. ………………………….. ………………………….. 15
2.6 Resurse ………………………….. ………………………….. ………………………….. ……………………. 16
2.7 Implementare ………………………….. ………………………….. ………………………….. ……………. 20
2.7.1 Biblio tecile ………………………….. ………………………….. ………………………….. ………… 20
2.7.2 TweenLite – GreenSock ………………………….. ………………………….. …………………… 25
2.7.3 AdMobBanner ………………………….. ………………………….. ………………………….. ……. 26
2.7.4 Main .as ………………………….. ………………………….. ………………………….. ……………… 27
2.7.5 Additional Adjustment.as ………………………….. ………………………….. ………………… 31
2.7.6 Level.as ………………………….. ………………………….. ………………………….. …………….. 32
2.7.7 Player.as ………………………….. ………………………….. ………………………….. ……………. 35
2.7.8 Bomb.a s ………………………….. ………………………….. ………………………….. ……………. 37
2.7.9 Enemy.as ………………………….. ………………………….. ………………………….. …………… 40
2.7.10 Reclaimer.as ………………………….. ………………………….. ………………………….. ……… 41
2.8 Testare ………………………….. ………………………….. ………………………….. …………………….. 43
3 Concluzii ………………………….. ………………………….. ………………………….. ……………………….. 47
4 Anexe ………………………….. ………………………….. ………………………….. ………………………….. … 48
4.1 Bibliografie ………………………….. ………………………….. ………………………….. ………………. 48
4.2 Index po ze, figure, tabele ………………………….. ………………………….. ……………………….. 49

3
1. Introducere
Pasiunea, dragostea pentru programare datează din copilărie de prin anii 1985 când am avut ocazia
să văd pentru prima dată un personal computer. Curiozitatea a ceea ce se întâmpla în „spatele
ecranului” s -a născut în acel moment și este de actualitate și în ziua de astăzi . Programâ nd, creăm
soluții la probleme iar l a sfârșitul zilei, am creat ceva care nu a existat în acea dimineață, și acest lucru
iți oferă satisfacție. Un alt aspect frumos al acestei branșe este că întotdeauna avem ceva nou de
învățat, întotdeauna vom avea o noua provocare. Aș îndrăzni s ă spun c ă programatorul este ca și un
artist. De exemplu în cazul aplicațiilor de timp „game” , programatorul se pune în fața calculatorului
și tot ceea ce are este „o foaie , pânză goală” (ecran alb). Va trebui s ă „picteze” așa încât la final s ă fie
un tablou frumos pentru a fi admirat. I deea comunicării cu hardware -ul, spunându -i ce să facă este
un alt sentiment frumos. Calculatorul este infinit de răbdător, inteligibil și total cinstit. Nu putem da
vina pe el dacă programul nu funcționează iar calculatorul nu va da vina pe noi. Este clar , exista și
momente mai puțin plăcute ca și în orice meserie dar la final de proiect când ceea ce a fost pe hârtie
ca și cerințe acum este un produs finit, funcțional iar aplicația este instalata de mulți utilizatori , atunci
ai un sentiment de răsplata. Unele c aracteristici pentru a fi un dezvoltator bun ar fi: c onștientizarea
că va exista întotdeauna un dezvoltator mai bun , ați asuma responsabilitatea pentru greșeli, precum
și de a învăța din greșeli , scrierea codului cât mai citibil și structurat , încerci să înțeleg i cum
funcționează lucrurile , comunică – colaborează bine cu ceilalți dintr -o echipă , deschis la critici și
abordări diferite , abilitatea de a ține pasul cu învățarea noilor tehnologii , îți place să rezolv i probleme.
A fi un programator bun nu are nimic de -a face cu vârsta, educa ția sau cât de mulți bani faci, este
modul în care acțion am și modul în care gândim.
1.1. Prefață
La început de drum un subiect de actualitate este: „ce limbaj de programare ar trebui să învăț? ”
Limb ajele de programare dinamice sunt, în general, mai ușor de învățat pentru începători, deoarece
sunt mai flexibile. Puteți construi rapid o aplicație de la zero, cu mai puține linii de cod, și nu există
nicio regulă greșită cu privire la modul de scriere, oferind posibilitate a programatorului s ă aloce mai
mult timp pentru învățarea conceptelor de programare. În aceasta categorie aș aminti JavaScript ,
ActionScript, Ruby, Python , Php etc. O altă categorie de limbaje de prog ramare este „Limbaje de
programare statice tipizate” care sunt cunoscute ca fiind mai scalabile, stabile și mentenanța acestora
este mai ușor de realizat, de obicei sunt mai stricte în ceea ce privește capturarea erorilor prin
verificarea tipului și este n evoie de mai mult cod pentru a construi un prototip. Exemple de limbaje

4
statice: Java, C, C++, Objective -C, Swift , etc . Anumite persoane odată ce aleg un limbaj de
programare au impresia c ă vor face pentru tot restul vieții cod în acest limbaj (este normal ). În timp
ce unii oameni au cariere de succes programând doar într-un singur limbaj de programare, majoritatea
dezvoltatorilor cunosc mai multe limb aje diferite – mulți vor schimb a, căuta, învăța alte limbaje până
când găsesc pe cea potrivită pentru ei. Indiferent de limba jul cu care începeți, fiți siguri că nu trebuie
să fie singura pe care o veți cunoaște vreodată. În calitate de dezvoltator, veți fi un cursant pe tot
parcursul vieții, deci așteptați să învățați multe limb aje de programare diferite în cariera dvs. În timp
ce limbajele de programare pot avea o sintaxă foarte diferită – sau reguli – și fiecare limb aj a fost
dezvoltată pentru a rezolva probleme specifice , vestea buna este că toate aceștia împărtășesc anumite
concepte comune, astfel că învăț area unui limbaj va face mai ușor să o învățam pe următoarea. Pe
măsură ce învățați următorul limbaj de programare, veți afla, descoperii mai multe despre limbajele
de programare anterioare , astfel încât învățarea dvs. este conectată! Realitatea este că unele limb aje
de programare sunt mai greu de învățat decât altele (mai ales dacă este prim ul). După ce învățați
conceptele de bază ale unei limb aj, puteți constata, de asemenea, că următoarele concepte sunt
asemănătoare . O întrebare foarte buna într-o asem enea situație este: „ce vrei să construiești? ” Știind
ceea ce vrei să construiești rezolvă repede întrebarea "ce limbă de programare trebuie să învăț mai
întâi" – pentru că limbajul este doar un instrument pentru a te duce acolo unde vrei să ajungi, este
unealta.
În ceea ce mă privește pe parcursul carierei mele de programator am învățat limbaje precum
ActionScript, C, C++, JavaScript , jQuery, AJAX, Php, Html, Lingo, MSQL, CDML( Claris Dynamic
Markup Language). Pentru că totul a plecat de la „hobby, self learning ” aplicații precum „Photoshop”,
„Dreamweaver”, „Director”, „Daz”, „Away3D”, „Corel”, „FreeHand”, etc, au fost obligatoriu de
studiat căci fără de ele interfețele grafice nu puteau fi realizate. Mai sunt aplicații ajutătoare ca și
„WampServer”, „Eclipse”,”FileMaker”, „Audacity” … Cum ziceam ideea realizării aplicaților de tip
„game” a fost una din provocările cu mine însumi de aceea în prezent am publicate pe platforma
„Google Play Store” sub ID -ul nickycsako, 12 jocuri cu aproximativ 150.000 de descărcări cu o rată
de feedback de 3.5 din 5 stele („Uno – Șeptică Americană” „Bomber Man”, „Scary Match Shooter”,
„Bee Playground”, „Joker – Don't Take It”, „Let's Draw – Christmas Time”, „Snakes and Ladders”,
„Bubble Trouble”, „Tic Tac Toe”, „Traffic Light”, „Traffic Light 3D”). Cu fiecare aplicație nouă
încercam să adaug în palmares o nouă abordare, un nou algoritm, eventual o noua tehnologie. Pentru
aceasta licența am ales aplicația „ Bomber Man ” deoarece …

5
1.2. Scurt istoric
În dorința de a crea, experimenta conținut multimedia interactiv, animație computerizată pe
„browser” cei de la compania de software Macromedia a achiziționat compania „FutureWava
Software” care a dezvoltat aplicația „FutureSplash Animator” pe care au redenumit -o „Flash”. In
aceea perioad ă a contat foarte mult că acele applet -uri erau de dimensiuni mici deci livrarea lor pe
internet se putea face în timp rezonabil. În perioada existentei lor 1992 – 2005 au distribuit în mod
gratuit plugin -ul „Flash Player” astfel în scurt timp conținutul „Flash” a acaparat aproape toate
paginile de internet ajungând să fie mai popular decât alte „Web media format” ca și Java,
QuickTime, RealNetworks etc [3]. La rândul lor, în plină ascensiune, au fost achiziționați de către cei
de la „Adobe” care a preluat portofoliul lor și l-au dus mai departe.
Formatul rezultat după compilare este „small web format .swf ” iar fișierul editabil,
fișierul sursă are extensia „.fla”. În februarie 2008 a fost lansat Adobe Integrated Runti me (AIR) ,
platforma care permite construirea aplicațiilor desktop (Windows, Apple OS X) și aplicațiilor mobile
(Android, Apple iOS si BlackBerry Tablet OS). Utilizând AIR, dezvoltatorii pot accesa
funcționalitatea completă Adobe Flash .
În decursul evolu ției, de la câmpuri text, grafic ă vectorial ă, animație, video games s -a ajuns
la aplicații web complexe – RIA (rich internet applications), jocuri multiplayer, e -commerce,
aplicații desktop, aplicații pentru telefoane mobile, tablete, streaming audio și video, grafic ă
și animație 3D. Astăzi , animațiile se pot publica pentru HTML5, WebGL, Scalabile Vector Graphics
(SVG), spritesheets, animații în format Graphics Interchange (GIFF)… În 2011, adăugarea Stage3D
în Flash Player a permis aplicațiilor Flash și A IR accesul la GPU -uri pentru accelerare hardware. În
noiembrie al aceluiași an Adobe a anunțat retragerea suportului pentru Flash Player pe dispozitive
mobile, dar au continu at să sprijine implementarea conținutului bazat pe Flash ca aplicații mobile prin
Adobe AIR (permite livrarea de aplicații independente care rulează în afara browser -ului, nefiind
necesară o conectivitate la net pentru a fi executate/rulate , oferind toate avantajele aplicațiilor
tradiționale, cum ar fi abilitatea de a rula în fundal pen tru „multitasking ” sau de a accesa o bază de
date locală ). Aplicațiile dezvoltate pentru AIR se execută în mai multe sisteme de operare, fără a mai
fi necesară o activitate suplimentară de către programator. În mai 2014, Adobe a susținut că peste
100.000 d e aplicații unice au fost construite cu AIR, iar peste 1 miliard de instalări ale acestora au
fost înregistrate de la utilizatori i din întreaga lume.
Printre marile companii care au folosit aceasta tehnologie se numără Nike, Hewlett -Packard,
Nokia, Gene ral Electric, World Wildlife Fund, HBO, Cartoon Network, Disney , YouTube și tot aici
putem aminti câteva titluri celebre a unor aplicații precum Angry Birds, Clash of Clans, FarmVille,
AdventureQuest, Machinarium, Hundreds, N, QWOP, Solipskier.

6
1.3. ActionScript 3
La început, interactivitatea conținutului se baza pe comenzi/acțiuni simple
precum "play", "stop", " gotoAndPlay" si "getURL” sintaxa și semantica lor au fost
foarte diferite de ECMAScript iar la versiune 5.0 in anul 2000 s -a introdus limba jul
de programare numit „ActionScript” care a permis o dezvoltare bazata pe design, programare
procedural ă completa și programare orientat ă pe obiecte fiind un limbaj bazat pe
standardul ECMAScript. Gary Grossman a fost dezvoltatorul principal al limbajul de programare
ActionScript continuând să participe activ la evoluția acestuia.
De la apariția primei versiuni în anul 2000 acest limbaj de programare a fost influențat de
către JavaScritp. Variabilele locale pot fi declarate cu instrucțiunea „var” și pot fi create și funcții
definite de utilizator cu valori de trecere și întoarcere a parametrilor. Următoarea versiune majoră al
limbajului de programare, ActionScript 2.0, a fost introdusă în septembrie 2003 prin lansarea Flash
MX 2004 și a playerului său co respunzător, Flash Player 7. Ca răspuns la cererea utilizatorilor pentru
un limbaj mai bine echipată pentru aplicații mai mari și mai complexe. În iunie 2006, ActionScript
3.0 a debutat cu playerul Flash Player 9. A fost o restructurare fundamentală a l imbajului, atât de mult
încât au fost nevoiți sa schimbe, folosească un ActionScript Virtual Machine (AVM) complet diferit .
Rezultatul a fost o mașină virtuală foarte optimizată, cunoscută sub numele de AVM2, împreună cu
o nouă versiune a limbajului ActionScript.
Motive pentru utilizarea ActionScript 3.0 :
 este un instrument de învățare excelent, vă ajuta să vă dezvoltați cun oștințele de programare
orientată pe obiecte.
 rapiditatea și ușurința de a obține rapid ceva pe ecran .
 crearea de aplicații extrem de complexe, cu seturi de date mari .
 performanță bună .
 depanarea codului ușor de făcut .
 compilatorul oferă opțiuni pentru verificarea mult mai strictă a erorilor .
 dezvoltarea de conținut pentru mai multe sisteme de operare .
 beneficiază de multe biblioteci .
 cuprinde sute de API -uri (Application Programming Interface)
 crearea de aplicații 2D, 3D.
 limbaj bazat pe standardul ECMA Script
 comunitate mare și materiale de tip „tutorial” în abundentă

7
 comunicații de tip „ Remote Services ”
Alte beneficii pentru platformele desktop/mobile (cu AIR):
 Menu bar – adăugarea unei bare de meniu native cu sub meniuri și elemente de meniu
personalizate.
 Window management – deschiderea mai multor ferestre, minimizarea, maximizarea și
redimensionarea ferestrelor.
 File management – crearea și ștergerea fișierelor, redenumirea, copierea și mutarea fișierelor.
 Touch -screen (inclusiv gesturi multi -touch).
 Multit hreading – gestionarea mai multor „threads” pentru a executa codul ActionScript 3 în
fundal fără a îngheța interfața cu utilizatorul .
 Web browser – vizualizați pagini web HTML cu suport complet CSS și JavaScript în
aplicațiile AIR.
 Networking de tip HTTP , TCP si UDP protocols.
 Clip board acces – copierea sau inserarea de texte, fișiere bitmaps sau fișiere în clipboard
sistem
 Drag -and-drop – permite utilizatorilor să tragă text, fișiere bitmaps sau fișiere în aplicațiile
de ei d ezvoltate.
 Acces la camera și microfonul dispozitivului (inclusiv codarea video pentru înregistrarea
video) .
 Acces la resurse hardware precum accelerometru și geo-locați e senzor (GPS), giroscop ,
baterie etc. al dispozitivului pe care rulează .
 Open source .
Adobe distribuie trei produse software comerciale pentru dezvoltarea aplicațiilor AIR în
ActionScrip: Adobe Flash Professional (redenumit Adobe Animate ), Adobe Flash Builder , Adobe
Scout . De asemenea mediile de dezvoltare terțe parte au participat la crearea de produse software:
FlashDevelop , Powerflasher FDT , CodeDrive, o extensie la Microsoft Visual Studio pentru
dezvoltarea și depanarea ActionScript 3.

8
ActionScript 3 Lexical Keywords :

as if return
break implements super
case import switch
catch in this
class instanceof throw
const interface to
default internal true
delete is try
do native typeof
else new use
extends null var
false package void
finally private while
for protected with
function public

Se poate controla accesul la variabile, clase, funcții și metode utilizând atributele de control.
Atributele de control al accesului ajută la realizarea încapsulării. Public (disponibil pentru orice
apelant), privat (disponibil numai pentru clasa care o definește), protejat (disponibil doar pentru clasa
care o definește și pentru orice subclase din acea clasă), intern (disponibil pentru orice apelant din
același pachet). Tipurile de date primitive sunt String, Number, int, uint, Boolean,Null si void iar
tipurile de date complexe sunt Object, MovieClip, Vector, Array, Date,Error, Function,
RegExp,XML si XMLList. Toate variabile din ActionScript 3 indiferent dacă sunt primitive sau
complexe, sunt obiecte. Obiectele se află în centrul limbajului ActionScript 3.0 – elementele sale
principale de construcție. Fiecare variabilă pe care o declarați, fiecare funcție pe care o scrieți și
fiecare instanță de clasă pe care o creați este un obiect. Vă puteți gândi la un program ActionScript
3.0 ca un grup de obiecte care efectuează sarcini, răspund la evenimente și comunică unul cu cel ălalt.
Administrarea memoriei a aplicației include instrucțiunile utilizate pentru a determina când să
aloce memoria, câtă memorie să aloce, când să pună lucrurile în coșul de gunoi și când să golești
coșul de gunoi. MMgc este managerul general de memorie utilizat de Flash Player/AIR pentru
aproape toate alocările de memorie. Memorie recuperată automat de către „ garbage collector” este
considerată "memorie gestionată". „Garbage collector” -ul determină când memoria nu mai este
utilizată de aplicație și o re cuperează. Tipuri de date Valoare
implicită
Boolean false
int 0
Number NaN
Object null
String null
uint 0
Tip nedeclarată * undefined
Toate celelalte clase,
inclusiv clasele definite de
utilizator. null

9
2 Repere majore pentru proiect
 Aprobarea conceptului
 Definirea cerințelor
 Definirea arhitecturii
 Definirea design -ului
 Implementarea
 Testarea
 Produsul este operațional
2.1 Concept
Un joc unde harta, labirintul acestuia să fie construită din imagini de tip patern și iterația
principală să se execute la o secunda au fost unele din principalele motive pentru care acest proiectul
„Bomber Man” a fost o provocare . Acest lucru duce la o îmbunătățire, optimizare a aplicației. Scopul
general este de a completa nivelele prin plasarea de bombe strategice pentru a ucide inamicii și a
distruge obstacolele , a găsi cheia ascunsa sub bambuși cu ajutorul căreia se va deschide ușa castelului.
De asemenea b ombe le care explodează po ate ucide și caracterul pr incipal. Din momentul în care o
bombă este plasată va exploda în mod automat după câteva secunde . Explozia acesteia va avea un
suflu +1 stânga, dreapta, sus jos din locul unde ea a fost plasata respectiv dacă personajul principal a
luat „fulgerul ” atunci acest suflu va fi +2. Acesta este un joc foarte palpitant, interesant, de acțiune și
strategie.
2.2 Obiective / scopul proiectului
Traversarea labirintului pentru a intra pe ușa castelului. Pentru a deschide ușa , trebuie găsit ă
și luat ă cheia ascunsa sub un bambus.
2.2.1 Definiții, acronime și abrevieri

AS3 = ActionScrip 3
RS = Cerințe specificații / Requirements Specifications
RFP = Cerințele pentru propuneri / Request for proposal
UDP = User Datagram Protocol
TCP = Transport Communication Protocol
IP = Internet Protocol
GSAP = GreenSock Animation Platform (suită de instrumente AS3 pentru animații de înaltă
performanță ).

10
2.2.2 Priorități

Cerințele din acest document sunt împărțite în următoarele categorii
Valori Priorități Descriere
1 Critical Această cerință este esențială pentru succesul proiectului. Proiectul nu va
fi posibil fără această cerință .
2 High Această cerință este o prioritate ridicată, însă proiectul poate fi pus în
aplicare la un nivel minim fără această cerință.
3 Medium Această cerință este oarecum importantă, deoarece oferă o anumită
valoare, dar proiectul poate continua fără ea.
4 Low Aceasta este o cerință de prioritate scăzută sau o caracteristică "plăcută"
dacă timpul și costul o permit.
5 Future Această cerință nu este relevantă pentru acest proiect și a fost inclusă aici
pentru o eventuală lansare ulterioară .

2.3 Cerințe / Requirements (RQC):
ID Requirement / Cerință Prioritate
RQC 1 Timpul de la lansarea jocului până când este redat va fi de maxim 5
secunde . 2
RQC 2 Primul ecran este ecranul cu meniu principal (coperta) . Acesta va avea
trei butoane: joc nou , despre aplicație ; și ieșirea din aplicația . 1
RQC 3 Ecranul „ About ” va conține informații precum cine a dezvoltat aplicația,
design -ul. De asemenea în acest ecran vor fi dou ă butoane care ne va
permite activarea și dezactivarea efectelor sonore cât și muzica de pe
fundalul fiecărui nivel. 1
RQC 4 Ecranul „ selectLevel ” (alege nivelul dorit să îl joci) va conține cele noua
butoane (castele) corespunzătoare celor noua nivele de joc. Primul nivel
întotdeauna va fi disponibil pe când celelalte nivele vor fi blocate pana
când nivelul lui inferior nu va fi finalizat cu succes. Memorarea nivelelor
terminate cu succes vor fi salvate pe plan local într -un fișier de tip text. De 1

11
asemenea acest ecran va conține un buton care permite revenirea la
ecranul principal.
RQC 5 Durata fiecărui nivel va fi intre 90 și 120 de secunde. 2
RQC 6 La fiecare început de nivel va exista o „fereastră informativă” unde se v or
afișa numărul total de bombe disponibile și cât timp avem la dispoziție
pentru a termina nivelul. 3
RQC 7 La fiecare început de nivel personajul principal va fi așezat în colțul
dreapta sus. 1
RQC 8 Ușa pe care trebuie s ă intre personajul pri ncipal pentru a finaliza cu succes
nivelul va fi așezat în partea dreapt ă jos. 1
RQC 9 Ecranul „ Level ” va afișa doua câmpuri text. Una pentru a afișa cate
bombe au mai rămas si cealaltă pentru a afișa timpul rămas la dispoziție
pentru a termina nivelul. 3
RQC 10 Personajul „Enemy” (monstrul – dinozaurul) se va deplasa la fiecare
secunda într-o direcție la întâmplare. 1
RQC 1 1 La epuizarea timpului alocat terminării nivelului se va auzi sound efectul
„Crowd” și se face tranzitare a către ecranul „selectLevel” . 1
RQC 1 2 Explozia bombei va avea un suflu +1 față de locul în care a fost așezată
bomba. Sus, jos, stânga dreapta. 1
RQC 1 3 Daca personajul principal „culege” simbolul trăsnet atunci suflul bombei
va fi +2 fata de locul în care a fost așezată bomba. 1
RQC 1 4 Dacă personajul principal atinge (se intersectează) cu personajul
“Enemy ”(monstrul – dinozaurul) acest nivel se va sfârși fără succes și se
face tranzitarea către ecranul „selectLevel” . 1
RQC 1 5 Dacă personajul principal atinge (se intersectează) cu săgeata “Arrow ”
acest nivel se va sfârși fără succes și se face tranzitarea către ecranul
„selectLevel” . 1
RQC 1 6 Pentru a debloca următorul nivel este obligatoriu terminarea cu succes al
nivelului inferior. 1
RQC 17 Controlul personajului principal se face cu ajutorul clasei c Atingerea
unuia dintre cele 4 direcții al „touchController ” va corespunde cu 1

12
deplasarea personajului principal în acea direcție. Atingerea icoanei cu
imaginea unei bombe va așeza pe locul unde se afla personajul principal o
bomba.
RQC 18 Explozia bombei se va declanșa după o durata de trei secunde din
momentul în care acesta a fost plasata. 2
RQC 19 Dacă personajul principal atinge (se intersectează) cu suflul exploziei
acest nivel se va sfârși fără succes și se face tranzitarea către ecranul
„selectLevel” . 1
RQC 20 Dacă personajul „Enemy ”(monstrul – dinozaurul) atinge, se intersectează
cu suflul exploziei acesta va murii, va dispărea de pe ecran. 1
RQC 21 Pe parcursul rulării unui nivel de joc daca opțiunea nu este dezactivată
atunci pe tot parcursul ei va fi acompaniata de o muzică de fundal. 4
RQC 22 „touchController ” instalat pe un alt dispozitiv care prin intermediul unui
server de tip UDP să comande jocul. 5

2.4 Cerințe non funcționale
ID Requirement / Cerință
NFR 1 Rata minimă de cadre trebuie să fie de cincisprezece de cadre pe secundă.
NFR 2 Rata recomandată de cadre trebuie să fie de treizeci de cadre pe secundă.
NFR 3 Timpul mediu de răspuns dintre clic și reacție trebuie să fie mai mic de 0,5 secunde.
NFR 4 Aplicația trebuie să utilizeze mai puțin de un douăzeci și cinci de mega de spațiu pe
hard disk .
NFR 5 Aplicația trebuie să poată rula cu minimum 100 MB de RAM.
NFR 6 Aplicația trebuie să ruleze în Windows, Apple OS X, Android, Apple iOS .
NFR 7 Aplicația trebuie să aibă nouă nivele.
NFR 8 Interfață de utilizare ușor de utilizat .
NFR 9 Software -ul va putea rula 99% din timp când a fost lansat .
NFR 10 Sistemul va menține securitatea rețelei .
NFR 11 Sistemul va putea fi actualizat după instalare .
NFR 12 Software -ul livrat va fi scris în AS3 .

13
2.5 Arhitectura
2.5.1 Class Diagram

14
2.5.2 Activity Diagram

15
2.5.3 Sequence Diagram

16
2.6 Resurse
O problemă de proiectare dată nu are un singur răspuns corect .
Acest proiect fiind unul „home made” rolul departamentele principale pentru crearea unui joc sunt
gândite și executate de către o singură persoană . Rolul producătorului , cel care planifică și
gestionează resursele, designer cel care proiectează modul de joc, conceperea și proiectarea regulilor
și structurii jocului, designerul de interfețe, programatorul, inginerul de sunet cat si cel care testează .
Figura 1 – „Librări a”
Designul este un termen destul de larg și vag. Rolurile legate de
proiectare există într -o serie de domenii, de la designul industrial
(autovehicule, mobilier) la imprimare (reviste, alte publicații) la
tehnologie (site -uri web, aplicații mobile). Responsabilitatea principala
a unui designer UX este să se asigure că produsul curge logic de la un
pas la altul. O modalitate este efectuarea de teste de utilizator pentru a
observa comportamentul acestuia. UI designer sunt responsabili de
proiectarea fiecărui ecran sau a paginii cu care interacționează
utilizatorul. Visual D esigner nu se preocupă de modul în care ecranele
se leagă unul de celălalt, nici de modul în care cineva interacționează cu
produsul. În schimb, accentul lor este pus pe realizarea de icoane,
controa le și elemente vizuale frumoase. Spre deosebire de designerii
vizuali care se ocupă de obic ei statice, designerii de mișcare creează
animație în interiorul unei aplicații. Ei se ocupă de ceea ce face interfața
după ce un utilizator o atinge. De exemplu, ei decid cum trebuie să se
alinieze un meniu, ce efecte de tranziție să utilizeze și cum treb uie să se
estompează un buton .
Unele din avantaj ele în folosirea aplicației Adobe Flash este că,
există posibilitatea de a se importa toate resursele. Imagini în diferite
formate (psd, jpeg, gif, bitmap), sunete (mp3, wav, aiff), video (mp4) și
chiar se poate încapsula tipuri de font. Toate vor fi în așa zisa librărie pe
care utilizatorul o poate organiza după bu nul lui pla c pe dosare, sub
dosare . În funcție de necesitate unele dintre ele se pot transforma in
„Clase” astfel încât să se poate instanția obiecte. Desigur ne ajuta foarte mult și multitudinea de
obținui pe care se pot seta din ferestrele corespunzătoare precum di mensiunea ecranului pe care se va
executa aplicația, culoarea de fundal, „frame rate ”, platforma pentru care construim aplicația . Cu
ajutorul instrumentului numit „TimeLine” se poate organiza și control a conținutul unui document în

17
timp în straturi și cadr e. Da, exact ca și în aplicația sora „Photoshop” se poate dezvolta pe straturi
(layer) cu aproximativ toate opțiunile acestuia. Î mparte lungimile de timp în cadre precum o face un
editor de filme indicându -ne cu exactitate la ce cadru și ce secundă suntem. Controalele din secțiunea
straturi a liniei de timp ne permit e să ascunde m, să arătă m, să bloca m sau să debloca m straturile și să
afișă m conținutul stratului ca schiț ă. În mod implicit, cronologia apare sub fereastra principală a
documentului . Rezultatul folosirii acestei unealtă sunt animațiile .
Cum spuneam după ce am adus toate imaginile, sunetele și am setat cele doua tipuri de font –
uri pe care le voi folosi în cadrul aplicație (Arial Black și Edwardian Script ITC ) este timpul pentru
ecran ul de pornire. Pentru un impact cu un efect mare de la început am folosit „TimeLine”. In cele
doua secunde cât durează secvența de start al aplicației sunt 60 de cadre a paisprezece straturi. Pe
fundal am așezat imaginea unui castel reprezentând simbolul al jocului, de instrumentul

Figura 2 – Ecranul si „Time Line ”

18
asemenea „Dragonul” pe care trebuie evitat pentru a ajunge la ușa castelului, cele doua bombe
uneltele caracterului principal pentru a -si face drum până la castel și pentru găsirea cheii. La cadrul
al 16 -lea respectiv 20 își face apariția și exploziile celor doua bombe însoțite de sunetele
corespunzătoare. Pentru un efect cat mai convingător suflul exploziei pornește de la o dimensiune
mica și pentru câteva cadre ea se tot mărește. Pe cadrul 27 de undeva din afara ecranului pornește
într-o tranziție de la stânga spre dreapta cel ce va fi butonul „Play”. Același lucru pentru butonul
„About” la cadrul 29 și pentru cel „Exit” la cadrul 35, lăsând la fin al apariția personajului principal
pe frame -ul 40 într -o tranziție de jos in sus pe axa y și z. Rezultatul final al animației este clasa
denumita „Cover”.
Aproape într -un mod asemănător este și animația pentru a ajunge la ecranul , clasa „About” cu o
durată de o secundă și 30 de cadre cu 11 straturi . În momentul în care se pornește animația de fapt pe
ecran se vede imaginea al clasei „Cover” (deci în animația noastră la început este o transparenta de
100%). Pe cadrele 5, 8, 11 13 si 15 în mod similar ca și la animația precedentă își vor face apariția
exploziile celor cinci bombe însoțite de sunetele corespunzătoare. Sunetele vor fi activate via code de
aceasta dată și nu vor fi așezate pe „TimeLine”. Rezultatul este identic doar am vrut să arăt și această
posibilitate. Și în acest caz fiecare explozie apare în locuri diferite pe ecran pornind de la o dimensiune
mică și cu trecerea a câtorva cadre ele se vor mării oferind o senzație de suflu unei explozii. În cadrul
22 apare titlul acestui e cran „About” pe cadrul 24 un text care indică cine a făcut aplicația iar în
ultimul cadru 30 apar două icoane care vor avea rol de activare și dezactivare a efectelor sonore
respectiv muzica de pe fundalul fie cărui nivel. Tot în acest cadru va apărea simbo lul care va permite
reîntoarcerea la ecranul anterior.
Construirea animației care va deservi drept suflu exploziei a fost făcut cadru cu cadru , durata ei
fiind de aproximativ jumătate de secundă , la final ultimul cadru va fi unul total transparent, n u va
conține nimic . Cu o tehnică asemănătoare a fost construit și mișcările caracterului principal cât și al
dragonilor . Cu ajutorul unui obiect de tip mască se ascunde diferența de imagine pe care nu dorim să
o afișam în acel cadru. Pentru simularea deplasării într -o direcție a caracterului se afișează consecutiv
de la stânga la dreapta cadrele interesate iar la finalul căreia cu comanda stop se rămâne pe ultimul
cadru până la următoarea comandă .

Figura 3 – Explozia

19
În cazul clasei „Door” construcția s -a conține două cadre cu opțiunea „stop” pentru fiecare cadru.
Una afișând imagina cu ușa închisa iar cealaltă imagine cu ușa deschisă. Pentru clasa
„MedievalBanner” avem un singur cadru cu doua straturi. Imaginea de fundal este pe unul din straturi
iar pe celălalt obiectul de tip text care se modifică în funcție de ce nivel începe. Asemănător este și
clasa „SelectLevel” compus din imaginea de fundal și pe stratul superior sunt așezate toate cele nouă
castele reprezentând cele nouă nivele disponibile din joc acoperite cu simbol ul „X” dacă acel nivel
încă nu a fost accesat. Aș mai aminti de clasa „Pattern” care conține 3 cadre care nu au ca și destinație
vreo animație ci doar să conțină imaginile cu care se vor construi labirintul pentru fiecare nivel.
Celelalte clase care au și conținut de tip imagine au cate un
cadru eventual conțin mai multe imagini dar nu mai conțin
animații: „TouchController”, „Bow”, „Arrow”, „Bomb”,
„Key”, „Thunder”, „Trees”, „BackToMenu”.
Există o multitudine de motive pentru a crea muzică
și a face un des ign de sunet pentru jocuri video , de a o face
la modul c ât se poate de serios. Ca și în cazul design -ului
de imagini și animații, sunetul completează, înfrumusețează
totul. Un film cu o coloană sonoră și efecte audio potrivită
este pe bună dreptate conside rat un film mai bun
împotriva vreunui film fără aceste detalii, așa și în jocurile
video sunetul dă un plus de valoare. Te poate influența și manipula în direcția în care designerul
jocului vrea să mergi . Efectele pot fi folosite pe post de a informa , a atrage atenția utilizatorul de
apariția unor evenimente. De exemplu dacă un jucător e pe moarte, sunetul s -ar putea modifica pentru
a prevesti acest lucru sau când un jucător are o creștere temporară de puteri , este posibil ca sunetul să
se schimbe până câ nd această opțiune nu mai există , tot prin intermediul sunetului se poate aduce la
cunoștința jucătorul ui ca a atins un nou record, timpul la dispoziție este pe sfârșite, apariția în cadru
a unui personaj negativ . Este un instrument de „brand -ing” excelent pentru jocuri . Utilizatorul va
asimila muzica și sunetele cu jocul în sine p ermiț ându -ne să ne angaj ăm în ceva care nu este vizibil
Capacitatea de a transmite emoție unui jucător prin sunet este un concept nu foarte nou c hiar și
jocurile arcade vechi au reușit să manipuleze emoțional jucătorii . În timpul jocului, jucătorul devine
personajul principal , prin urmare, muzica pe care o creăm devine coloana sonoră care i se adresează
în mod direct jucătorului. Proiectantul de sunet se va asigura că efectele son ore respectă tonul muzicii,
astfel încât acestea să nu se ciocne ască unul de celălalt , sa nu existe distorsiuni , volumul să fie unul
potrivit . De asemenea, este esențial să pute m testa sunetele în joc cât mai curând posibil deoarece
sunt cazuri când muzica sau efect ele par cele potrivit e dar în contextul jocului să nu fie ceea ce ne
doream sau este prea lung, prea scurt pentru scena și momentul pentru care l -am gândit. În cazul
Figura 4 – „Enemy”

20
sunetelor repetitive trebuie să ne asiguram că ieșirea din iterație respectiv reintrarea în sound se face
fără zgomote de fond nedorite, o operație deloc ușoara. De reținut că toate aceste proceduri iți răpesc
o perioada de timp nu foarte mică. Așadar după perioada de căutare, achiziție, editare, potrivire
proiectul s -a ales cu o muzică de fundal pe perioada în care se joaca un nivelele „ BgSound ” și cinci
efecte sonore: „ ClickSound ” pentru a simula sunetul unui click atunci când revenim la un ecran
anterior, „ Crowd ” va fi folosit atunci când caracterul principal moare, „ NextLevSound ” când
personajul principal termină cu succes nivelul, „ ZombiePain ” pentru când personajul „Enemy” moare
și „ExplodeSound ” folosit în momentul exploziei al bombei .
2.7 Implementare
Această parte este cea mai îndrăgită de programatorii, este momentul în care toate
abstractizările vor fi transformate în code. Implementarea este realizarea, executarea punerea în
practic ă a unui plan . Ca atare, implementarea este acțiunea care trebuie să urmez e orice gândire
preliminară pentru ca ceva să se întâmple . Reprezintă, în mod inerent, o schimbare a arhitecturii a
design -ului în code.
2.7.1 Bibliotecile

Bibliotecile, în majoritatea limbajelor de programare , sunt resurse pe care le putem reutiliza.
Când cream o aplicație mare, codul este întotdeauna bun în interiorul bibliotecilor , astfel încât să îl
reutilizam mai târziu . Există biblioteci statice și dinamice. Static se va "îmbina" cu codul dvs. (mai
rapid, dar va folosi mai multă memorie) și dinamic (puțin mai lent, dar poate reutiliza biblioteca dacă
este deja în memorie) va face legătura cu aplicația dvs. când porniți pr ogramul. Cele statice sunt cel
mai frecvent tip de conectare la compilarea unei aplicații. Cu toate acestea, bibliotecile dinamic e ne
permite să obține m o reducere a dimensiunii finale a fișierului SWF , APK, EXE și, prin urmare, o
reducere a duratei de des cărcare a aplicației . Pentru a conecta în mod static definițiile unei biblioteci
în aplicația dvs., utilizați opțiunile compilatorului bibliotecă -cale și include -biblioteci pentru a
specifica locațiile fișierelor SWC . Un fișier SWC este un pachet de simbol uri Flash precomprimate
și un cod ActionScript care permite unui dezvoltator AS3 să distribuie clase pentru a evita
recompilarea simbolurilor și a codului care nu se va schimba. Fișierele SWC pot fi generate de
instrumentul de creație Adobe Flash Professio nal. Codurile bibliotecilor de tip SWC sunt de obicei
incluse într -un proiect ActionScript 3 și compilate în fișierul SWF final alături de programul
dezvoltatorului, de către compilatorul ActionScript 3 . Doar clasele care au fost utilizate de proiect (și
dependențele lor) sunt transferate în fișierul SWF rezultat . Un fișier SWC este comprimat prin
intermedi ul formatului de arhivă ZIP. Redenumirea extensiei unui fișier SWC la "zip" va permite
decomprimare acestui fișier și să afișeze conținutul ei. Folosirea bibliotecilor corespunzătoare poate

21
reduce cantitatea de cod care
trebuie scrisă. Acesta va tinde să
reducă numărul de linii de cod
pentru o aplicație va crește rata
de livrare a funcționalității. În
cele mai multe cazuri, este mai
bine să utilizați o rutină de
bibliotecă decât să scrieți
propriul cod .
În continuare vă voi
prezenta toate bibliotecile
folosite în acest proiect. Clasa
Stage reprezintă întreaga zonă în
care este afișat conținutul . Pentru
conținutul care rulează în AIR pe
sistemele de operare desktop,
fiecare obiect NativeWindow are
un obiect Stage corespunzător .
Clasa StageAlign oferă valori
constan te de utilizat pentru
proprietatea Stage.align (bottom ,
bottom _left, bottom _right , left,
right , top, top_left , top_right ).
Clasa StageScaleMode oferă
valori pentru proprietatea
Stage.scaleMode precum: exact fit – specifică faptul că întreaga aplicație este vizibilă în zona
specificată, fără a încerca să păstreze raportul de aspect original. NoBorder – specifică faptul că
întreaga aplicație umple zona specificată, fără distorsiuni, dar eventual cu o anumită decupare ,
menținând în același timp raportul origin al al aspectului aplicației. NoScale – specifică faptul că
dimensiunea aplicației trebuie fixată astfel încât să rămână neschimbată, chiar dacă dimensiunea
ferestrei playerului se modifică. ShowAll – specifică faptul că întreaga aplicație este vizibilă în zona
specificată fără distorsiuni, menținând în același timp raportul original al aspectului aplicației . Clasa
DisplayObject este clasa de bază pentru toate obiectele care pot fi plasate pe lista de afișare . Lista de
afișare gestionează toate obiectele afi șate în timpul de funcționare Flash /Air. Conține funcționalit ăți
de bază cum ar fi poziția x și y a unui obiect, precum și proprietățile mai avansate ale obiectului, cum import flash.display.Stage;
import flash.display.StageAlign ;
import flash.display.StageScaleMode ;
import flash.display.DisplayObject ;
import flash.display.MovieClip ;
import flash.display.Sprite;
import flash.events.Event;
import flash.events.EventDispatcher ;
import flash.events.MouseEvent ;
import flash.ui.Keyboard ;
import flash.events.KeyboardEvent ;
import flash.media.Sound;
import flash.media.SoundChannel ;
import flash.media.SoundTransform ;
import flash.net.FileReference ;
import flash.utils.Timer;
import flash.utils.setTimeout ;
import flash.events.TimerEvent ;
import flash.text.Font;
import flash.text.TextFormat ;
import flash.text.TextField ;
import flash.text.TextFormatAlign ;
import flash.filesystem .File;
import flash.filesystem .FileStream ;
import flash.filesystem .FileMode ;
import flash.utils.getDefinitionByName ;
import flash.desktop.NativeApplication ;
import flash.display.NativeWindow ;
import flash.display.NativeWindowInitOptions ;
import flash.display.NativeWindowSystemChrome ;
import flash.display.NativeWindowType ;

import AdditionalAdjustment ;

import gs.TweenLite ;

// Ane Extension Imports
import com.codealchemy .ane.admobane .AdMobBanner
import com.codealchemy .ane.admobane .AdMobEvent ;
import com.codealchemy .ane.admobane .AdMobManager ;
import com.codealchemy .ane.admobane .AdMobPosition ;
import com.codealchemy .ane.admobane .AdMobSize ;
import com.codealchemy .ane.admobane .AdMobFunctions ;

22
ar fi matricea sa de transformare . În Flash Professional, metodele pentru clasa MovieC lip oferă
aceleași funcționalități ca și acțiunile care vizează clipurile video. Spre deosebire de obiectul Sprite,
un obiect MovieClip are timeline. Câteva proprietăți pe care le putem aminti în acest caz ar fi: alpha ,
blendMode , filters , height , opaqueBackground , rotation , scaleX , scaleY, scale9Grid, scrollRect ,
transform , visible , width , x, y. Clasa Sprite este un element de bază al listei de afișare: un nod al listei
de afișare care poate afișa g rafice. Un obiect Sprite este similar cu un clip v ideo, dar nu are o
cronologie. Sprite este o clasă de bază adecvată pentru obiectele care nu necesită timeline . Spre
exemplu, Sprite ar fi o clasă de bază logică pentru componentele interfeței utilizator (UI) care de
obicei nu utilizează timeline. Clasa ev eniment este utilizată ca clasă de bază pentru crearea obiectelor
evenimentului, care sunt transmise ca parametri pentru evenimente de întreruperi atunci când are loc
un eveniment . Proprietățile clasei conțin informații de bază despre un eveniment, cum ar fi tipul
evenimentului sau dacă comportamentul implicit al evenimentului poate fi anulat . De exemplu
evenimentele asociate cu un click de mouse , trebuie să includă informații suplimentare despre locația
evenimentului de clic și dacă au fost apăsate orice t aste în timpul evenimentului de clic. Puteți
transmite astfel de informații suplimentare evenimentelor de întrerupere prin extinderea clasei
evenimentului . Unele evenimente au un comportament implicit asociat . Evenimentul doubleClick are
un comportament im plicit asociat care evidențiază indicatorul mouse -ului în momentul
evenimentului . Clasa EventDispatcher este clasa de bază pentru toate clasele care expediază
evenimente , permite oricărui obiect din lista de afișare să fie o țintă a evenimentului și ca atare . În
general, cel mai simplu mod pentru o clasă definită de utilizator de a capta capabilități de
dispecerizare a evenimentelor este extinderea EventDispatche r. Un obiect MouseEvent este expediat
în fluxul de evenimente ori de câte ori apare întrerupe rea din partea mouse -ului. Clasa de tastatură
este utilizată pentru a construi o interfață care poate fi controlată de un utilizator cu o tastatură
standard . Puteți utiliza metodele și proprietățile clasei tastatură fără a utiliza un constructor.
Proprietă țile clasei Tastatură sunt constante care reprezintă tastele care sunt cel mai frecvent utilizate
pentru controlul jocurilor . Un obiect KeyboardEvent este trimis ca răspuns la apăsarea utilizatorului
al unei tastaturi . Există două tipuri de evenimente de t astatură: KeyboardEvent.KEY_DOWN și
KeyboardEvent.KEY_UP . Clasa de sunet ne permite să lucrăm cu sunet e într-o aplicație , încărca rea
și reda rea un fișier MP3 extern în acel obiect, accesarea de date al sunetului, cum ar fi informații
despre numărul de octeți din flux . Sunetul este redat în timp ce acesta este preluat dintr -un obiect
ByteArray pe care îl ocupă cu date de sunet. Clasa SoundChannel controlează un sunet într -o
aplicație. Fiecare sunet este atribuit unui canal de sunet, iar aplicația poate a vea mai multe canale de
sunet care sunt amestecate împreună. Clasa SoundChannel conține o metodă stop (), proprietăți pentru
monitorizarea amplitudinii (volumului) canalului și o proprietate pentru atribuirea unui obiect
SoundTransform canalului. Clasa Sou ndTransform conține proprietăți pentru volum și panoramare .

23
Clasa FileReference oferă o modalitate de a încărca și descărca fișiere între computerul unui utilizator
și un server . O fereastră de dialog al sistemul de operare solicită utilizatorului să selec teze un fișier
pentru încărcare sau o locație pentru descărcare al acestuia. Fiecare obiect FileReference se referă la
un singur fișier de pe discul utilizatorului și are proprietăți care conțin informații despre dimensiunea,
tipul, numele, data creării, d ata modificării și tipul creatorului fișierului (numai pentru Macintosh).
În Adobe AIR, clasa File, care extinde clasa FileReference, oferă mai multe capabilități și are mai
puține restricții de securitate . Clasa Timer este interfața cu cronometrele, care permit să rulam codul
într-o secvență de ti mp specificată. Utilizând metoda start () se pornește un cronometru. Adăugâ nd un
eveniment de întrerupere pentru evenimentul temporizatorului vom seta codul care va fi rulat în
intervalul acesta de timp . Se poate crea obiecte Timer pentru a rula o singură dată codul sau să le
repet e la intervale specificate de timp. Un obiect Timer expediază obiecte TimerEvent ori de câte ori
obiectul Timer atinge intervalul specificat de proprietatea Timer.delay . Clasa Font este utilizată
pentru a gestiona fonturile încorporate în fișierele SWF. Fonturile încorporate sunt reprezentate ca o
subclasă a clasei Font , este utilă numai pentru a afla informații despre fonturile încorporate; nu puteți
modific a un font utilizând această clasă . Nu pute m utiliza clasa Font pentru a încărca fonturi externe
sau pentru a cre a o instanță a unui obiect Font. Clasa TextFormat reprezintă informații despre
formatarea caracterelor . Se poate folosi clasa TextFormat pentru a crea o formatare specifică a
textului pentru câmpurile text . Dacă dori m să afiș am un text bold sau italic cu un font încorporat,
trebuie să includeți variantele bold și italice ale acelui font . Trebuie să utiliz ăm new TextFormat ()
pentru a crea un obiect TextFormat înainte de a i seta proprietățile . Clasa TextField este utilizată
pentru a crea obiecte de afișare pentru afișarea și introducerea textului . Metodele din clasa TextField
ne permit e să setăm, să select ăm și să manipul ăm textul într -un câmp de tex t dinamic sau de
introducere pe care îl creăm în timpul redactării sau în timpul execuției . Flash Player acceptă un
subset de etichete HTML pe care le pute m utiliza pentru a formata textul . Clasa TextFormatAlign
oferă valori pentru alinierea textului în cl asa TextFormat . Un obiect File reprezintă o cale către un
fișier sau un director. Acesta poate fi un fișier sau un director existent sau poate fi unul care nu există
încă; de exemplu, poate reprezenta calea către un fișier sau un director pe care intențion ăm să îl cre ăm.
Are o serie de proprietăți și metode pentru a obține informații despre sistemul de fișiere și pentru a
efectua operații, cum ar fi copierea fișierelor și a directoarelor . Proprietăți le acestei clase au valori
semnificative în diferite siste me de operare. De exemplu, sistemul de operare Mac OS, Linux și
Windows au diferite căi native pentru directorul desktop al utilizatorului. Este indicat sa n u adăug ăm
sau să elimin ăm conținut din directorul aplicației (unde este instalată aplicația AIR). Î n acest caz,
putem întrerupe o aplicație AIR și pute m invalida semnătura aplicației . Ar trebui utilizat directorul
de stocare a aplicațiilor pentru a scrie fișierele de aplicații interne , respectiv utilizat directorul de
documente pentru a scrie fișiere p e care un utilizator se așteaptă să le utilizeze în afara aplicației, cum

24
ar fi imagini sau fișiere text editate. Un obiect FileStream este folosit pentru a citi și a scrie fișiere.
Fișierele pot fi deschi se sincron, apelând metoda open () sau asincron prin apelarea metodei
openAsync ().Avantajul deschiderii fișierelor în mod asincron este faptul că un alt cod poate executa
în timp ce Adobe AIR rulează procesele de citire și scriere în fundal. Când sunt deschise în mod
asincron, evenimentele de progres sunt e xpediate pe măsură ce operațiunile continuă . Clasa FileMode
definește constantele șir utilizate în parame trul fileMode al metodelor open () și openAsync() din clasa
FileStream. Parametrul fileMode al acestor metode determină capabilitățile disponibile pentr u
obiectul FileStream odată ce fișierul este deschis . Următoarele capabilități sunt disponibile, în diverse
combinații, pe baza valorii parametrului fileMode specificat în metoda deschisă:
 Citire – obiectul FileStream poate citi datele din fișier .
 Scriere – obiectul FileStream poate scrie date în fișier.
 Creare – Obiectul FileStream creează un fișier inexistent la deschidere .
 Trunchiere la deschidere – Datele din f ișier sunt șterse la deschidere.
 Adăugați date scrise – datele sunt întotdeauna scrise la sfâr șitul fișierului.
Pachetul flash.utils conține o varietate de funcții la nivel de pachet pentru execuția codului de
sincronizare, recuperarea informațiilor despre clase și obiecte . Clasa NativeApplication reprezintă
însăși această aplicație AIR. Oferă informații despre aplicații, funcții la nivel de aplicație și trimite
evenimente la nivel de aplicație. Obiectul NativeApplication este un obiect singleton, creat automat
la pornire . Clasa NativeWindow oferă o interfață pentru crearea și controlul ferestre lor native de pe
desktop . Această caracteristică este acceptată pe toate sistemele de operare desktop, dar nu este
acceptată pe dispozitive mobile sau AIR pentru dispozitive TV. Ave m posibilitatea să test ăm suportul
la ora de rulare pe dispozitivele deskto p utilizând proprietatea NativeWindow.isSupported .
Proprietățile unei instanțe NativeWindow pot fi accesate numai prin conținutul aplicației. În cazul în
care conținutul non -aplicație încearcă să acceseze obiectul NativeWindow, va fi lansată o eroare de
securitate . Conținutul poate fi adăugat la o fereastră utilizând metodele DisplayObjectContainer ale
obiec tului Stage, cum ar fi addChild (). Sistemul crom se referă la elementele specifice unui sistem de
operare dintr -o fereastră, cum ar fi bara de titlu, bu toanele de minimizare, maximizare și închidere .
Pentru fereastra inițială a aplicației creată automat de AIR, toate aceste proprietăți (cu excepția
tipului) sunt setate în descriptorul aplicației. Fereastra inițială este întotdeauna tip
NativeWindowType.NO RMAL.

25

2.7.2 TweenLite – GreenSock
Figura 5 – TweenLite – GreenSock
Animarea cu cod poate părea intimidant ă la
început. Platforma de animație GreenSock (GSAP) a
fost proiectată pentru a fi simpl u și intuitiv . Motorul de
bază este TweenLite apoi TweenMax, Ti melineLite,
TimelineMax etc. Fiecare „tween ” pe care creăm are
nevoie de o ținta (obiectul pe care dorim să îl adăugăm ),
durata (de obicei descris ă în secunde) și proprietățile pe
care dorim să le modificam , împreună cu valorile finale
corespunzătoare.
TweenLite este un motor de generarea a
cadrelor intermediare extrem de rapid, ușor și flexibil,
care servește drept fundamentul platformei de animație
GreenSock. O instanță TweenLite se ocupă de îmbunătățirea uneia sau mai multor proprietăți ale
oricărui obiect în timp, actualizându -le pe fiecare cadru. Sună simplu, dar există o mulțime de
capabilități și facilități la îndemână cu acesta tehnologie . Cu o mulțime de alte motoare de generarea
a cadrelor intermediare iată de ce am lua t în considerare TweenLite:
 viteza – TweenLite a fost optimizat pentru performanță maximă.
 ușurința setărilor – în plus față de adăugarea oricărei proprietăți numerice a oricărui obiect,
TweenLite poate filtra, culori, volum, nuanță, cadre și poate chiar să îmbunătățească aspectul.
TweenMax extinde TweenLite și adaugă chiar și mai multe ca pabilități cum ar fi repetarea ,
repetarea timpului, expedierea even imentului, actualizările și rotunjirea de valorilor la
destinație, și multe altele. Gestionarea suprascrierii este un aspect important al platform ei
GreenSock Tweening. Avem opțiuni pentru suprascrierea AUTO sau putem defini manual
modul în care fiecare tween va gestiona tween -urile suprapuse ale aceluiași obiect.
 extensibilitat e – cu arhitectura plugin -ului, se poate activa cât mai multe caracteristici pe care
le cere proiectul. Se poate scrie propriul plugin pentru a gestiona anumite proprietăți speciale
în moduri personalizate obținându -se o performanța mare .
 funcții de secvențiere, grupare și gestionare – TimelineLite și TimelineMax fac surprinzător
de simplu crearea de secvențe complexe sau grupuri de cadrelor intermediare pe care le putem
controla ca un întreg . play(), pause(), restart(), or reverse().
 ușurința în utilizare – designerii și dezvoltatorii deopotrivă vorbesc despre cât de intuitivă este
platforma .

26
Performanța este esențială, mai ales pe dispozitivele mobile cu procesoare lent e. Cea mai bună
animație dinamică este semnul distinctiv al ori cărui motor de generarea a cadrelor intermediare iar
GSAP depășește vechile "standarde industriale" cu literal mente 1000% + sub stres. Ceea ce era foarte
lent si sacadat este acum fluid. Este rezultatul nenumăratelor optimizări efectuate pentru a asigura că
proiectele dvs. interactive sunt receptive, eficiente și netede. Orice proprietate numerică a unui obiect
poate fi modificată, iar dacă proprietatea are nevoie de mani pulare specială (cum ar fi culori, filtre,
valori non -numerice etc.), există șanse să existe un plugin care să o facă. Dacă nu, se poate crea. O
proprietate specială este un cuvânt cheie rezervat, care TweenLite îl recunoaște și gestionează diferit
decât a r fi o proprietate obișnuită. Un exemplu este întârzierea care amână pornirea unui tween până
când un anumit număr de secunde a trecut . Posibilitățile sunt nesfârșite. TweenLite împachetează o
cantitate uimitoare de energie într -un pachet surprinzător de mic, sub 7kb . Control precis pentru a
crea animații expresive cu un cod minimal . Complet gratuit, cu excepția unui tip foarte specific de
utilizare comercială (revânzarea către mai mulți clienți), licența GreenSock este extre m de accesibilă
și prietenoasă. Web -ul este plin de proiecte abandonate "open source", dar GreenSock are o
experiență de zec e ani de angajament față de platformă.
2.7.3 AdMobBanner
Figura 6 – AdMob Banner
Fondată în 2006 în Mountain View – SUA,
AdMob ( advertising on mobile – publicitate pe
mobil) reunește cea mai bună tehnologie din branșa
într-o singură platformă, astfel încât să putem obține
informații despre utilizatorii noștri și permite
dezvoltatorilor să maximizeze veniturile din anunțuri astfel generând venituri prin publicitatea în
aplicații (inclusiv de la alți agenți de publicitate). Plată rapidă și fiabilă în monedă locală. Nu mai
trebuie să folosim o combinație de instrumente sau să utilizați resurse de dezvoltare contra cost pentru
a ne construi propria soluție. AdMob poate fi folosit cu toate platformele de top. Oferă soluții de
publicitate pentru multe platforme mobile, inclusiv Android, iOS, webOS, Flash Lite, Windows
Phone și toate browser -ele web standard mobile, cu suport pentru diverse limbaje de programar e. Este
capabila să furnizeze reclamele in peste 200 de țări într-o varietate de formate – de la text la animații
multimedia și chiar video. Este una dintre cele mai mari platforme de publicitate mobile din lume și
pretinde că furnizează mai mult de 40 de miliarde de bannere și anunțuri text pe lună pe site -urile web
mobile și aplicațiile pentru telefoane mobile. Se poate seta filtre pentru a ne asigura că anunțurile
afișate sunt relevante pentru utilizatorii noștri de aplicații. De asemenea, avem control a supra tipurilor
de formate de anunțuri pe care dorim sa le afișăm. Putem alege dintre anunțurile banner,
interconectările de pagini complete, anunțurile video și anunțurile native. Oferă, de asemenea, o

27
platformă cuprinzătoare de mediere, care permite dezv oltatorilor să gestioneze și să medieze cererile
de anunțuri către mai mult de 40 de rețele terțe. Acest lucru ne ajută să maximizați generarea de bani
pentru aplicații. Conectarea conturilor AdWords și AdMob ne permite să ne optimizam experiența de
public itate. Cu AdWords, putem crea campanii universale de aplicații pentru a ne promova aplicația
prin intermediul căutării Google și Google Play, YouTube, Rețeaua de display Google, AdMob și
multe altele. Odată ce am realizat mai multe instalări de aplicații, putem utiliza AdMob pentru a afișa
anunțuri în aplicație și pentru a genera bani prin intermediul utilizatorilor. Integrarea cu serviciile
Google Play impune îmbunătățiri automate ale performanței aplicațiilor Android fără modificări SDK
suplimentare. Ajut ă dezvoltatorii de aplicații care sunt gata să obțină bani în mod gratuit pentru
aplicațiile mobile în cadrul aplicațiilor proprii.
2.7.4 Main.as

Și am ajuns la faza î n care aminteam și la începutul acestei licenței în care avem „o scenă”
goala, o „foaie de hârtie” albă unde va trebui să punem, umplem cu actori, evenimente care
interacționează, spun o poveste etc. Bibliotecile de care avem nevoie sunt pregătite , resursele la fel
deci nu ne rămâne decât să începem. În această primă fază ne vom ocupa de secvența de început al
jocului. Așadar declarăm clasa care va conține coperta jocului, clasa care va conține informații despre
joc ( așa zisa pagina „about”) și clasa care ne va permite să alegem ce nivel dorim să jucăm. Desigur
avem nevoie și de alte variabile dar le voi aminti pe fiecare în momentul în care este necesară apariția
acestora. Următorul pas este să stabilim ca ecranul nostru sa fie pe orice dispozitiv cu diferite
dimensiuni și rezoluții nedistorsionat și redimensionat proporțional . Este o procedură, aș spune
obligatorie pentru orice aplicație scrisă în AS3 și destinată platformelor Android, IPhone. După
declararea claselor acum urmează instanțierea lor , creăm obiecte le și le așezăm pe scenă, ecran.
Deoare ce am creat toate cele trei obiecte deodată ,doar coperta jocului va fi așezat pe poziția x și y
egal cu 0 al ecranului utilizatorului iar celelalte două obiecte vor fi așezate în afara ecranului până în
momentul în care este nevoie de afișarea lor.
Clasa „Cover” este alcătuită din diverse imagini, sunet, tranziții pe aproximativ 15 straturi cu
un total de 60 de cadre (vezi figura 2). Procedura de asamblare este una aproape identică cu cea unui
montaj video cu diferența că există posibilitatea adăugării un or comenzi de tip cod. De exemplu pe
ultimul cadru din acest caz este adăugată comanda „stop() ” astfel nu se va repeta la nesfârșit
executarea și afișarea de la cadru 1 la 60. Aceast ă clasă conține la rândul ei 3 obiecte. Este vorba de
cele 3 butoane (Play , About, Exit) care ne vor direcționa către celelalte secvențe/ecrane. Pe parcursul
celor 2 secunde de animație chemăm funcția responsabilă cu publicitatea. Pregătim terenul pentru
momentul în care vom dorii să afișăm sau nu publicitate pe parcursul rulării aplicației noastre. După
declararea și instanțierea clasei AdMob verificăm dacă acesta este suportată pe dispozitivul pe care

28
rulează aplicația în acest moment introducem codul unic furnizat de Google pentru autorizarea acestei
proceduri pentru această aplicație și setăm modul de operație să fie cea de producție, adică să nu fie
cea de demonstrație . La final, funcția „ createBanner ()” prin parametrii ei va crea publicitatea noastră,
de dimensiunea dorită de noi , o va așeza în poziția dorită de noi cu un ID personalizat folosit pentru
a identifica bannerul atunci când sunt bannere multiple . În acest moment avem disponibilă
publicitatea și putem să o afișăm când dorim. Deci în momentul în care am deschis aplicația pe ecran
va fi afișat intro -ul, animația de doua secunde , pe fundal s -a pregătit reclamele . Este momentul să
apelam funcțiile de întrerupere pentru cele trei butoane de care aminteam. La atingerea (pe ecranele
tactile) sau când se va face clic cu mouse -ul se va apela funcția de întrerupere care ne va duce la
secvența dorită de noi. Deoarece cele trei butoane sunt în interiorul obiectului „mainCover” funcția
de întrerupere va arata ca și în tabelul de mai sus. Practic, spunem compilatorului că în interiorul
obiectului „mainCover” este obiectul „ playBtn ”,” aboutBtn ”, „exitBtn ”.
La declanșarea funcției de întrerupere apăsând butonul „aboutBtn” va fi apelată funcția
„about ()”. Pentru a evita declanșarea o a altei funcție de întrerupere prin apăsarea accidentală pe
perioada cât trat ăm secvența „about” primul lucru care trebuie să îl facem este să eliminăm, să
dezarm ăm apelurile/întreruperile create. Și în acest caz obiectul „aboutMC” nu este de tip „Sprite”
(fără an imație) ci este de tip „MovieClip”. Are 30 de cadre, 11 straturi conținând imagini, sunete,
tranziții, cod. În mod intenționat codul aferent acestei clase l -am scris pe ultimul cadru al „TimeLine –
ului” pentru a arata și această posibilitate oferită de apli cația „Adobe Flash”. Cadrul numărul unu este
un cadru cu nimic pe el astfel în momentul când îl așezăm pe coordonatele x, y egal cu zero al
ecranului, pe ecran se va afișa în continuare „mainCover”. Este momentul când dăm drumul
animației. Cum spuneam, dup ă o secunda, animația a luat sfârșit iar pe ecran ni se afișează un text
despre cine a creat aceasta aplicație si trei butoane. Una care ne permite întoarcerea la secvența de la
care am pornit, adică coperta principală, un buton care activează sau dezactiv ează efectele sonore pe
parcursul jocului și un al treilea buton care face același lucru pentru muzica de fundal pe perioada
când se rulează un nivel. Pentru acest lucru declaram doua variabile care pot fi văzute, interoga te în
toată aplicația, încapsularea lor va fi una publică. În funcție
de opțiunea aleasă icoanele în formă de difuzor vor avea
un „X” în fața lor sau „unde” reprezentând acordul nostru
pentru a executa fișierele audio. Pentru toate acestea
creăm doua funcții de întrerupere.
Figura 7 – Difuzoare // adding Mouse Event Listener for play, a bout, exit button
mainCover .playBtn.addEventListener (MouseEvent .CLICK, playSelectLevel );
mainCover .aboutBtn .addEventListener (MouseEvent .CLICK, about);
mainCover .exitBtn.addEventListener (MouseEvent .MOUSE_DOWN , exitApp);

29
O a treia funcție de întrerupere va permite reîntoarcerea la ecranul principal printr -o tranziție de tip
transparenta de la 100% la 0% într -o secundă, nu înainte de a elimina, dezarma întreruperile create,
interoga variabila mai sus menționată pentru a vedea dacă se va executa fișierul audio destinat
secvenței de clic. După terminarea tranziției, obiectul „aboutMC” va fi din nou poziționată în afara
razei ecranului dispozitivului și se apelează funcția „ returnToMainMenu(true) ” astfel controlul este
din nou în clasa „Cover”. Aceasta funcție a fost creată pentru revenirea în clasa principală ea fiind
apelată din clasa :About” cât și din clasa „ SelectLevel ” diferențiindu -se prin parametrul de tip
„Boolean ”. În cazul nostru aceasta funcție va reactiva întreruperile de la începutul aplicației.
La declanșarea funcției de întrerupere apăsând butonul „ exitBtn ” va fi apelată funcția
„exitApp ()”.Și de această dată pentru a evita declanșarea o a altei funcție de întrerupere prin apăsarea
accidentală pe perioada cât tratăm secvența „ exitApp ” eliminăm, dezarmăm întreruperile create,
verificăm dacă variabila răspunzătoare cu efectele de sunet ne permite executarea fișierului audio
destinat secvenței de clic iar după o întârziere de 800 de milisecunde apelam funcția nativă care va
închide aplicația noastră.
La declanșarea funcției de întrerupere apăsând butonul „ playBtn ” va fi apelată funcția
„playSelectLevel ()”. Repetăm secvența dezarmării întreruper ilor create și cea a sunetului pentru clic,
așezăm obiectul „ selectLevel ” pe axa X și Y egal cu 0 , setându -l la o transparență de 0% astfel pornind
aproape simultan două tranziții de transparență una pentru această clasă, de la 0 la 100% respectiv
pentru c lasa „Cover” exact invers în intervalul de timp de trei secunde. Mergând mai departe pe
această direcție „cu sens unic ” apelăm funcția „ checkWhichLevelisDisponible ()”. Aici se verifică

Figura 8 – Select Level

30
calea nativă din sistemul de operare pentru a vedea dacă există fișier ul responsabil cu stocarea
informațiilor privitoare la ce nivel maxim s -a ajuns. Dacă acest fișier nu există atunci va fi creat unul
și îl vom popula cu datele corespunzătoare nivelului unu iar dacă fișierul există în accesată locație îl
vom deschide , se va citi datele din el și îl închidem la loc. În ambele cazuri stocăm datele rezultate
într-o variabilă globală care ne va permite să afișăm sau nu nivele care au fost terminare cu succes și
crearea p entru ele funcții de întrerupere care va declanșa secvența de încărcare și jucare a nivelului
pe care îl dorim. Cu ajutorul unor iterații se va realiza toate acestea , unde numărul maxim de iterații
va fi indicată de variabila mai sus amintită. Pentru acele nivele care nu au fost încă accesate se va
așeza un „X” în fața lor și nu se vor crea funcții de întrerupere pentru ele. Din cauza tranzițiilor și a
calculelor amint ite mai sus, crearea funcțiilor de întrerupere vor fi întârziate cu 3500 milisecunde.
Pentru că această funcție este apelată și din clasa „Level” trebuie să ne asiguram că afișarea reclamelor
a fost eliminată.
Din această clasă se poate îndrepta jocul ori în direcția unde se creează clasa „Leve l” pentru
jucarea unui nivel, ori reîntoarcerea la coperta principala. În această ultimă variantă apăsând butonul
„backToMenu ” se declanșează întreruperea care apelează funcția „ returnToMainMenuCall ()” care la
rândul ei va apela” returnToMainMenu(false) ”. De această dată parametrul este fals ceea ce va
permite intrarea în starea unde se vor dezactiva toate întreruperile create cu ajutorul variabilei globale
unde este stocată numărul de nivele jucate cu succes , desigur și de această dată printr -o iterație . Tot
în această ramură se vor efectua tranzițiile de transparență „selectLevel ” de la 100 % la 0% și obiectul
„mainCover ” de la 0% la 100% în interva lul de trei secunde cu extinderea funcționalității fun cției de
tranziție cu argumentul că la finalizarea ei să mute aceasta clasă în afara ecranului dispozitivului și la
final ca de fiecare dată se va reactiva întreruperile de la începutul aplicației. În schimb dacă
utilizatorul a ales jucarea unui nivel se v a apela funcția „ playLevel ()” unde vor fi șterse toate funcțiile
create, se va executa fișierul audio corespunzător unui clic dacă acest lucru este permis, se va sustrage
din denumirea butonului /obiectului tocmai apăsat numărul aferent nivelului care a fost activat și
stocat într -o variabilă care va fi interogată din clasa „Level”. Cele dou ă ramuri sunt necesare deoarece
denumirea poate s ă fie compus ă din șase caractere sau șapte. Rezultatul extragerii va f i de tipul
// store the name of the object on that was clicked
var eventCurrentTargetName :String = e.target.name;

if (eventCurrentTargetName .length > 6) // for example "point10"
{
// extract the last two character from string and cast them into a uint
witchLevelIsPushed = uint(eventCurrentTargetName .substring (5,7));

}
else // for example "point3"
{
// extract the last character from string and cast him into a uint
witchLevelIsPushed = uint(eventCurrentTargetName .substring (5,6));
}

31
character motiv pentru care este necesar ă conversia în tip „uint”. Urmează crearea unui obiect de tip
„Level” adăugarea lui pe ecran. Pentru a menține trendul de până acum și de accesată dată , obiectul
creat îl setam la o transparența de 0% ca m ai apoi să pornim o tranziție de trei secunde și să îl
readucem la o transparență de 100% iar la final apelăm funcția pentru afișarea reclamelor.
2.7.5 Additional Adjustment.as

Această clasă a fost creată cu scopul de a nu fi nevoie să facem cate o clasă separată pentru
fiecare nivel. Așadar la începutul clasei „Level” vom apela „ Additional Adjustment ” pentru a ni se
înapoi a printr -un array toate acele valori care diferă de la un nivel de joc la altul. Singurul parametru
transmis va indica nivelul pentru care se dorește a se obține datele. Primu l element din array -ul pe
care îl va înapoia este o matrice cu ajutorul căruia se va construi harta nivelului corespunzător.
 0 – reprezintă iarba pe care jucătorul, monștrii se deplaseaza.
 1 – reprezintă cărămida/peretele. Jucătorii, monștrii nu pot trece prin ele.
 2 – reprezintă bambus -ul. Jucătorii, monștrii nu pot trece , dar bombele le pot distruge . public static function returnAllDataArray (witchLevelItis :uint):Array
{
var colectAllData :Array = new Array();
………….
switch(witchLevelItis )
{
case 1:
{
level = [[1,1,1,1,1,1,1,1,1,1,1,1,1,1],
[1,0,0,1,2,0,0,1,2,0,0,2,1,1],
[1,0,0,1,1,0,0,0,0,0,2,1,2,1],
[1,0,0,2,0,1,2,2,2,1,1,2,0,1],
[1,0,2,0,0,0,2,0,0,1,2,2,0,1],
[1,2,2,2,0,0,2,0,0,2,2,0,0,1],
[1,1,0,0,1,0,2,0,0,0,0,0,0,1],
[1,0,0,2,0,1,2,2,0,0,0,2,2,1],
[1,0,2,0,0,2,1,2,0,0,0,1,0,1],
[1,1,1,1,1,1,1,1,1,1,1,1,1,1],
];
colectAllData .push(level); // colectAllData[0]
countdown_number = 120;
colectAllData .push(countdown_number ); // colectAllData[1]
countBomb = 25;
colectAllData .push(countBomb ); // colectAllData[2]
enemyAisInTheGame = false;
colectAllData .push(enemyAisInTheGame ); // colectAllData[3]
enemyBisInTheGame = false;
colectAllData .push(enemyBisInTheGame ); // colectAllData[4]
enemyCisInTheGame = false;
colectAllData .push(enemyCisInTheGame ); // colectAllData[5]
reclaimerIsInTheGame = false;
colectAllData .push(reclaimerIsInTheGame ); // colectAllData[6]
break;
……………………….
return colectAllData ;

32
Al doilea element va indica secundele pe care jucătorul le are la dispoziție pentru a termina
nivelul, următorul element va indica câte bombe sunt disponib ile pentru acest nivel, următoarele trei
elemente va încapsula informația de tip Boolean care va informa dacă pentru acest nivel exista
„dragoni” iar în aceeași ordine de idei ultimul element va arata dacă acest nivel va conține arcul care
trage cu săgeți către personajul principal.
2.7.6 Level .as

Clasa responsabilă cu aducerea, controlarea, ștergerea claselor necesare pentru joc. Putem să
o denumim inima jocului, centrul de comandă. După ce ne asigurăm că adăugarea clasei s -a făcut cu
succes, procedura din prima funcție putem porni către funcția de inițializare a variabilelor și
instanțierea tuturor cl aselor. Precum se vede în cod sunt necesare multe variabile pentru a controla
jocul. De remarcat că, în această etapă aducem din clasa ajutătoare (bibliotecă) acele date de care
aminteam că sunt diferite pentru fiecare nivel în parte și le stocăm într -o variabilă locală denumită –
specificParametersForThisLevel . Formula pentru accesată operație este :
AdditionalAdjustment .returnAllDataArray (MovieClip (parent).witchLevelIsPushed );
Adică din clasa ajutătoare chemăm funcția și îi pasăm parametrul care se află în clasa care a adăugat
accesată clasă (Main). Acum pe plan local avem toate informațiile necesare construirii nivelului.
Tot în accesată etapă, intenționat , am construit și adăugat cele două câmpuri text responsabile
cu afișare timpului rămas și bom belor rămase la dispoziția jucătorului pentru a găsi cheia pentru a
intra pe ușa castelului , manevră necesară a finaliz a cu succes nivel ul. Acest lucru se putea face și cu
ajutorul aplicație „Abobe Flash” prin folosirea uneltelor puse la dispoziție. Printr -un simplu adaugă,
aplicația ar fi pus acest câmp text la care noi i -ar fi trebuit să îi dăm un nume pentru al folosi în cod.
Metoda aleasă de mine demonstrează că toate interfețele cu utilizatorul se poate coda de la zero. La
finalul aceste etape pentru o corectă afișare a timpului avem această condiție , dacă secundele rămase
sunt mai mic i decât zece se adaugă caracterul zero în caz contrar secundele sunt compuse din două
cifre nefiind nevoie de nici o cosmetizare.
Pe parcursul întregului nivel, pe fundal , este setat să se redea o piesă audio dacă nu cumva
această setare a fost dezactivată. Pe partea dreaptă a ecranului în partea de sus am așezat cele două
câmpuri text, acum așezăm butonul care va permite, în orice moment reîntoarcerea la ecranul anterior
și în partea de jos postam câțiva copaci puri decorativi.
Înainte de a construii întreaga hartă de joc trebuie să așezăm la întâmplare
„cheia ” și „fulgerul ”. Când spun la întâmplare mă refer la faptul că va trebui să calculam
în funcție de cate elemente de „bambus ” sunt să decidem sub care dintre ele în mod
aleatoriu să așezăm aceste două elemente. Acesta etapă se face acum deoarece după
acesta urmează constr uirea harții deci toate elementele din hartă vor fi așezate peste
„cheie ” și „fulger ”. Cunoaștem matricea cu ajutorul căreia se va construi harta acestui
Figura 9 –
Cheia, fulger

33
nivel deci într -un vector va trebui să extragem elementele care indică „bambus ” și în alți doi vectori
vom extrage poziția pe axa X si Y. Cu ajutorul a două iterații identificăm toate aceste date și le stocam.
Din vectorul nou creat care conține toate elementele „bambus” extragem acel număr aleatoriu iar cu
ajutorul celo r doi vectori vom obține poziția ace stui bambus extras. Din acest moment nu ne rămâne
doar să creăm obiectul „fulger” să îl așezăm în poziția calculată să îi atribuim o transparența de 0%
până în momentul în care harta va fi construită. Aceeași procedură va fi aplicată și în cazul „cheii”.
Construirea harții de joc se poate realiza acum. Cu ajutorul a două iterații trecem prin fiecare
element din matrice, creăm de fiecare dată câte un obiect de tipul „Patern” și îl poziționam în funcție
de element la plus 50 de pixeli la dreapta sau jos, î i atribuim un nume și îl adăugam pe ecran. Acest
obiect are trei cadre pe linia de timp. Dacă elementul din matrice este zero atunci obiectul se va o pri
în fata cadrului unu. Pe ace st cadru este șablonul cu imaginea ierbii. Pentru cadru doi este imaginea
cărămidă și pe cadrul trei imaginea cu bambușii . Introducem și poziționăm ușa pe harta creată,
„înghețăm” ecranul în momentul când adăugam pe mijlocul ei „bannerul” care va informa j ucătorul
care este misiunea lui și ce resurse are la dispoziție. Trecerea mai departe se va realiza în urma
atingerii ecranului, clic, în semn că utilizatorul a luat la cunoștința de aceste informații. Fereastra
informativă va ieși din cadru printr -o tranz iție pe axa Y în intervalul de timp de o secundă . La
finalizarea procesului de tranziție obiectul va fi eliminat. În ultima parte a construirii harții , după ce
anulăm funcția de întrerupere atașat ferestrei informative, creăm obiectul ce va reprezenta jucătorul ,
caracterul principal. Verificăm dacă pentru acest nivel sunt „dragoni” și dacă sunt verificăm câți. La
fel se va proceda și cu arcul, se va verif ica dacă pentru nivelul actual trebuie adăugat sau nu.
La final ceea ce a mai rămas de adăugat este așa numitul „ touchpad ” care ne va permite
controlarea jucătorului prin direcționarea sa, și „plantarea” de bombe. Atașam funcția de întrerupere for (var i:int = 0; i < mapLevel .length ; ++i)
{
for (var j:int = 0; j < mapLevel [i].length; ++j)
{
// if in the map = 0 => grass, map = 1 => brick, map = 2 => bamboo
var brick:Pattern = new Pattern();
brick.x = j * 50; // set the X position of this brick object
brick.y = i * 50; // set the Y position of this brick object

// set a name for this object
brick.name = "brick" + i + "" + j;

// add to stage the object
addChild (brick);

// set the frame of the tile according to the value in the 2D array
brick.gotoAndStop (mapLevel [i][j] + 1 );
}
}

34
pentru butonul care va permite reîntoarcerea la ecranul anterior și setăm și activăm o funcție de
întrerupere bazată pe timp. La fiecare secundă această funcție va fi apelată , tocmai de aceea funcție
apelată în momentul întreruperii , am numit -o „everySecond ()”. Această funcție va actualiza cele două
câmpuri text (timpul și bombele rămase ), verifică dacă nu cumva jucătorul nu a fost atins de vreun
„dragon” sau suflul vreunei explozii sau săgeata trasă de arc, caz în care se declanșează secvența în
care ne pregătim să terminăm nivelul . Același lucru, secvența de terminarea a nivelului se va declanșa
dacă această funcție constată că jucătorul a atins, intrat pe ușa castelului. Diferența dintre ele este
transmiterea parametrului de tip sound. De altfel în momentul în care se apelează funcția de
întrerupere care ne duce la ecranul anterior se setează timpul rămas la o secundă și în acest fel, prin
necâștigarea nivelului se activează procesul de pregătire de finalizare al nivelului
„preparesBeforeRemoveThisClass ()”. Dacă nivelul a fost terminat cu succes atunci înaintea aceste i
funcții trebuie să actualizam fișierul care este responsabil cu stocarea numărului corespunzător
nivelului maxim terminat de către utilizator. În cazul nostru aplicația având nouă nivele trebuie să ne
asigurăm că în momentul când jucătorul finalizează nivelul noua cu succes în fișierul amintit nu
putem actualiza cu un număr mai mare de nouă. Pentru a acoperi toate cazurile pentru actualizarea
fișierului avem nevoie de trei ramuri de cod. În cazul în care fișierul se găsește la locul stabilit (pentru
că există posibilitate ca în telefon, dispozitiv din anumite motive să fie stres acest fișier), deci dacă
există și nivelul terminat cu succes este mai mare decât numărul din fișier atunci act ualizăm acest
număr. A doua ramară este în cazul în care acest număr este mai mic sau egal cu numărul din fișier
acest lucru însemnând că utilizatorul a jucat un nivel pe care cel puțin odată la terminat cu succes deci
Figura 10 – „Level ”

35
nu mai este nevoie să actualizăm fiși erul. Și ultima ramură ar fi în cazul în care fișierul nu se găsește
la locul stabilit atunci vom crea un fișier nou și îl actualizăm cu numărul nivelului tocmai terminat.
Revenind la funcția pregătitoare terminării nivelului vom șterge funcțiile de întrer upere aferente
„touchpad -ului”, actualizăm starea personajului principal și al „dragonilor” într -o stare în care nu mai
răspund la nici o comandă, setaam vizibilitatea caracterului principal la invizibil, dacă la începutul
nivelului a fost redată muzica de fundal acum o vom închide, cu parametrul transmis (sunetul victoriei
sau sunetul când nu se termină cu succes nivelul) va fi redată în cazul în care acest lucru este permis,
se va actualiza câmpul text responsabil cu afișarea timpului la zero (00:00), se comandă încetarea
funcției de întreruperi „ everySecond ()” și după o secundă și jumătate timp lăsat pentru ca să fim siguri
că toate actualizările au fost făcute se va apela ultima funcție din acesată clasă unde se vor retrage
toate obiectele instalate pe p arcursul acestui nivel.
Funcția finală denumită „ removeAll() ” începe cu o tranziție de tip transparentă al acestui
obiect de la 100% la 0% în trei secunde iar la finalul tranziției vom șterge, elimina toate obiectele
adăugate la început și anume: cele dou ă câmpuri text, butonul cu care se permitea întoarcerea la
ecranul anterior, copacii decorativi din partea dreapta, ușa castelului, jucătorul principal și „ touchpad –
ul”. La fel ca și la început când am creat harta acum pentru a elimina obiectele de tipul „Patern” vom
folosi dubla iterație. După o verificare în care controlam dacă au fost sau nu luate „fulgerul” și „cheia”
se ia decizia de eliminare sau nu a acestor obiecte. Restul obiectelor rămase vor fi șterse dacă au fost
adăugate. Înainte ca accesată c lasă să fie ștearsă pregătim terenul pentru ecranul „ selectLevel ” și
anume îl poziționam pe axa X si Y egal cu zero, vizibilitate tot la zero și pornim o tranziție de
transparentă până la !00% în trei secunde și indicăm către funcția „ checkWhichLevelisDisp onible ()”.
2.7.7 Player .as
Clasa în care se realizează controlul personajului principal în funcție de comenzile date de
jucător prin intermediul „ touchpad -ului”. Așadar după ce ne asigurăm că adăugarea clasei s -a făcut
cu succes setăm variabi lele de tip boolean care indic ă dacă a fost activată una din funcțiile de
întrerupere care ne arată ce trebuie să facă caracterul principal, le setăm pe valoarea fals. Fiind l a
început, același lucru îl vom face și cu variabilele care indică dacă au
fost luate sau nu „fulgerul” și „cheia”. Pentru a cunoaște tot timpul
poziția caracterului principal ne definim o matrice iar pe poziția
elementului unde se afla caracterul nostru îi dăm valoarea noua (putea
să fie orice valoare).
Aplicația fiind destinată pentru multiple sisteme de operare,
jucătorul are posibilitate controlului caracterului principal prin
intermediul unei tastaturi sau atingerea ecranului dacă acesta este un
ecran tactil. Cu alte cuvinte avem nevoie să definim dou ă tipuri de
Figura 11 – Tastatura

36
întreruperi. Una care va acționa în momentul în care pe tastatură se apasă butoanele sus, jos, dreapta,
stânga și spațiu, respectiv o a doua întrerupere pentru când se atinge butoanele din obiectul
„touchpad ”.
Ambele funcții de întrerupere vo r prelua valoarea evenimentului și îl vor pasa unei funcții
ulterioare care le va interpreta „ readInterupt(String) ”. Aici primul lucru ce facem este să dezactivăm
întreruperile de pana acum pentru evitarea confuziilor ce se pot crea până la finalizarea șir urilor de
evenimente create în urma creări acestei întreruperi. În urma interpretări va rezulta setarea uneia din
variabilele booleene de care aminteam la început și în acest fel se poate trece la funcția unde se va
executa comanda. După ce verificăm faptu l că, caracterul principal nu s -a ciocnit cu nici un „dragon”
caz în care s -ar seta variabilele care funcția „ everySecond ()” le controlează în fiecare secundă pentru
a verifica starea întregului joc, ulterior verificăm noi de accesată dată dacă nu cumva a ceste variabile
globale au status -ul pentru care jocul trebuie oprit și dacă aceste precondiții nu se îndeplinesc se trece
la partea actualizării caracterului principal. Verificăm care din cele cinci posibilități a fost activată și
pornim animația pentru a cel caz, verificăm dacă pe acea direcție este setata „iarbă” pentru ca dacă pe
acea direcție este un „Patern” de tipul „cărămidă” sau „bambus” atunci pe acea direcție nu se poate
înainta dar dacă nu atunci cu ajutorul unei tranziții de tip „alunecare” pe a cea direcție în intervalul de
timp de 300 milisecunde se va actualiza poziția caracterului principal cu plus, minus 50 de pixeli.
Actualizăm matricea creată la începutul clasei înlocuind poziția de pe care caracterul principal a
început tranziția cu cifra zero și poziția unde este destinația acestuia se va actualiza cu cifra nouă (este
cifra pe care am ales -o să reprezinte jucătorul ).
Pentru a evita repetarea aceleiași cod pentru fiecare ramură am creat o funcție care este apelată
la fiecare caz pe care am denumit -o „checkTheOtherScenarios() ”. Aici avem trei cazuri de verificat
și acționat ca atare:
 dacă poziția actualizată a caracterului principal coincide cu poziția „fulgerului” și acesta nu a
fost luată până în acest moment, atunci eliminăm obiectul de tipul „ Thunder ”, actualizăm
variabila care indică că acesta a fost luată și se apelează funcția care pregătește repetarea
tuturor funcțiilor descrise până acum din acesta clasă .
 dacă poziția actualizată a caracterului principal coincide cu pozi ția „cheii” și acesta nu a fost
luată până în acest moment, atunci eliminăm obiectul de tipul „ Key”, actualizăm variabila
care indică că acesta a fost luată și se apelează funcția care pregătește repetarea tuturor
funcțiilor descrise până acum din acesta c lasă.
 dacă poziția actualizată a caracterului principal coincide cu poziția „uși” se setează variabila
de tip boolean care indică că acest nivel a fost terminat cu succes urmând ca după o mica
întârziere să activam o tranziție de tip scalar al caracterului principal de la 100% la 0% în
intervalul de timp de două secunde. Acest efect ar simula intrarea jucătorului pe ușa castelului.

37
La final pregătim terenul pentru funcția care controlează mișcarea „dragon ilor” în ideea să se
oprească din mișcare și să le facă invizibile până când vor fi eliminate.
A mai rămas de tratat situația în care s -a apăsat pe tasta spațiu sau icoana cu imaginea bombei
în cazul ecranelor tactile. În acest caz începem prin a controla dacă deja există o bombă plasată în
joc, ceea ce nu ar permite să plasăm o altă bombă. Dacă condiția este îndeplinită, adică nu avem altă
bombă plasată în acest moment atunci declarăm un obiect de tipul „ Bomb ” îl instanțiem , îl inițializăm
și îl plasăm pe ecran. Deoarece este ultimul obiect plasat pe ecran probabilitatea să ne acopere o
porțiune din obiectul „ touchController ” este destul de mare, așadar pentru a evita acest lucru spunem
obiectului „ touchController ” să fie cel mai în față obiect de pe ecran . Setăm variabila care nu va mai
permite să se „planteze” o alta bombă atâta timp cât cea actuala nu a explodat. Reamintesc faptul că
la începutul acestei funcții avem o verificare în care controlăm dacă variabila care tine minte câte
bombe avem la dispozi ție este egală cu zero atunci nu se ajunge pe această ramură. Pentru că toată
secvența în care explodează bomba durează trei secunde setăm un temporizator de durata a 3200 de
milisecunde la finalul căreia variabila care permite plasarea altei bombe să fie pe adevărat. Acest
temporizator nu va bloca, va permite în continuare orice mișcare al caracterului principal.
Funcția care pregătește totul pentru a rel ua ciclul acestei clase nu face altceva decât să reseteze
variabilele de tip boolean care indică dacă a fost activată una din funcțiile de întrerupere care ne arată
ce trebuie să facă caracterul principal setându -le toate pe fals și desigur să reactivăm funcțiile de
întrerupere pentru tastatură și pentru ecran e tactil e.
2.7.8 Bomb.as

Existența clasei, mă refer în timp este de aproximativ trei secunde și
un pic. Se naște, rămâne în așteptare trei secunde, execută codul aferent
situației date și se auto elimină. Pentru început ne asigurăm că obiectul a fost
plasat cu succes pe ecran după care interogăm clasa părinte adică „Player”
pentru a obține cu exactitate poziția caracterului principal pe axa X și Y în
momentul în care clasa „Bombă” a fost plasată pe ecran. Același lucru facem și cu poziția în matrice.
Lucru ce va determina, imediat după adăugarea acestui obiect să fie poziționat exact pe poziția în care
caracterul principal se află în acel moment. Caracterul principal are la dispoziție să se ascundă din
fața suflului exploziei care va urma, trei secunde, atât cât am setat temporizator ul care la finalul ei va
apela funcția principală al acestei clase.
Ca urmare începe secvența exploziei. Bomba se dezintegrează, adică dispare, tradus în cod ,
imaginea care conține bomba o facem invizibilă, î i setăm transparența la 0%. O vom șterge, elimina
de pe ecran în momentul când tot codul din această clasă se va executa. Pentru aceasta am declarat
un obiect de tipul „Bomb” care să conțină această clasă în sine. Dacă setar ea care permite redarea
Figura 12 – Bombă

38
sunetelor de tip efect e sonore este activată atunci va fi redată sunetul unei explozii. Dacă pe parcursul
a celor trei secunde de așteptare jocul s -a terminat, caracterul principal a fost atins de vreun „dragon”
sau de o „săgeată” atunci nu mai este nevoie de a executa restul codului din această clasă. Cu ajutorul
obiectul de tipul acestei clase care conține clasa în sine vom elimina acest obiect , și cum spuneam
oprim executarea codului pe mai departe. În condiția în care caracterul principal nu a pățit nimic
verificăm dacă până în acest moment s -a luat „fulgerul, deoarece în aceasta situație trebuie apelată
funcția care gestionează situația când suflul exploziei se extinde cu două „blocuri” de la locul
exploziei în sus, jos, dreapta și stânga, respectiv contrar, ar fi apelată funcția care gestionează suflul
exploziei doar pe un singur „bloc” distantă pe aceleași patru axe.
Funcția „ explozieSimpla ()” întotdeauna va adăuga pe ecran în exact aceeași poziț ie unde
caracterul principal a adăugat bomba care după trei secunde dispare și cum spuneam va apărea în
acest moment animația care sugerează suflul exploziei. Celelalte patru situații sunt condiționate de
blocul corespunzător (plus unu în sus, dreapta, jos , stânga) unde ar urma să fie așezată obiectul care
conține animația exploziei , să fie „iarba” ori „bambus”. Calea cea mai simplă pentru această condiție
este să ne asigurăm că acel bloc nu este de tipul „cărămidă”. Prin această procedură vom obține
indire ct pentru fiecare caz controlat dacă condiția se îndeplinește, ceea ce ne va ajuta să poziționăm
obiectul pe care îl vom crea. Trecând peste această condiție pentru fiecare caz în parte se va declara,
instanția și inițializa obiectul de tipul „ Poof ”, așa c um am denumit clasa care conține animația
exploziei. Pentru fiecare cele cinci cazuri, mai bine zis pentru fiecare caz din cele cinci pentru care
se va îndeplini condițiile pentru ca animația care sugerează suflul exploziei să fie redată se va face un
control unde se verifică dacă în raza suflului se află caracterul principal sau unul dintre „dragoni”.
Pentru a evita scrierea codului pentru fiecare caz creăm o singură funcție unde î i transmitem prin
parametrul funcției chiar obiectul suflul exploziei. Așa particularizam situația. Cazul în care suflul
exploziei atinge caracterul principal , acestuia îi atribuim o vizibilitate de 0%, îl mutăm pe axa X și Y
la coordonata zero , accesăm și setăm pe fals variabila care este controlată în clasa „Main” din secundă
în secundă care arată dacă jucătorul este în viată , practic declanșăm terminarea acestui nivel cu starea
fără succes. Cazul în care suflul exploziei atinge unul dintre „dragoni” (fiecare este cont rolat separat),
acesta ca și în cazul caracterului principal i se va atribui o transparenta de 0%, se va accesa variabila
care arată dacă acel „dragon este în viată sau nu setându -l pe fals și după o altă verificare unde
interogăm dacă efectele sonore sunt permise pentru redare și în funcție de răspuns redam fișierul
audio care exprima durerea „dragonului” care este atins de suflul exploziei și moare.
Cazul în care fulgerul a fost luat această clasă va avea un suflu de două „blocuri” distanta de
la locul u nde s -a plasat bomba. Denumită „ explozieDubla ()” această funcție este foarte asemănătoare
cu cea anterioară doar că toate verificările se vor face pentru „blocul” doi de la punctul de origine
pentru că la începutul ei include funcția „ explozieSimpla ()” așa dar nefiind nevoie de a controla, seta,

39
adăuga pentru cazurile puls unu de la locul de origine. Față de primul caz trebuie verificat dacă acest
al doilea suflu care ar trebui pus se află în interiorul matricei noaste, harta creata la început. De
exemplu da că caracterul principal se află în poziția matricei [1][1] suflul exploziei nu poate fi pe
poziția [ -1][1] sau [1][ -1]. În aceeași ordine de idei se fac verificările pentru celelalte cazuri [12][1] ,
[1][8] și [12][8] deși cazul acesta nu va fi niciodată de oarece ar însemna situația în care caracterul
principal a intrat pe ușa castelului și , deci nu mai poate să adauge bombe , dar pentru expandabilitatea
codulu i am verificat și cazul acesta.
A mai rămas de verificat în ambele cazuri situația în care suflul exploziei se intersectează cu
cu „bloc” de tipul „bambus” . Parametrul funcție va transmite de unde este apelată această funcție (din
„explozieDubla ()” sau „ exploz ieSimpla ()”) și ne ajută să stabilim poziția în cauză.. Unele verificări
se repetă aici deoarece tratăm ambele situați și avem nevoie de aceste controale . În primul caz ne
asigurăm că nu se iese din dimensiunea matricei ( în exemplu de mai sus este cazul un de nu avem voie
să depășim elementul 13). Al doilea filtru verifică existența suflului la distanța de plus unul de la
punctul de origine (adică să nu fie „bloc” de tip „cărămidă”). Situație în care nu există suflu , deci nu
există posibilitatea pentru care ar trebui să preschimbăm un „bloc” de tip „bambus” în „bloc” de tip
„iarba” nici pentru explozi a simplă nici cea dublă. Ajunși la cel de -al treilea filtru, în sfârșit controlăm
dacă acest „bloc” este de tip „bambus ”. După confirmare trecem la acțiune: acel element din matrice private function checkIfItIsBamboo (simpleOrDoubleExplosion :uint):void
{
var brickDimension :Number = 50;

// pozitia sa nu fie mai mare sau mai mica decât este board array
if (j_position + simpleOrDoubleExplosion <= 13)
{
if (MovieClip (parent).mapLevel [i_position ][j_position + 1] != 1) // verifică
dacă la explozieSimpla() a fost un perete de tip 1 nu mai pune explozia dubla
{
if ( MovieClip (parent).mapLevel [i_position ][j_position +
simpleOrDoubleExplosion ] == 2) // verifica daca este bamboo
{
MovieClip (parent).removeChild ( MovieClip (parent).getChildByName (
"brick" + i_position + "" + (j_position + simpleOrDoubleExplosion )) );

MovieClip (parent).mapLevel [i_position ][j_position +
simpleOrDoubleExplosion ] = 0;

var brickA:Pattern = new Pattern();
brickA.x = (j_position + simpleOrDoubleExplosion ) * brickDimension ;
brickA.y = i_position * brickDimension ;
brickA.name = "brick" + i_position + "" + (j_position +
simpleOrDoubleExplosion );

MovieClip (parent).addChild (brickA);
brickA.gotoAndStop (1);

MovieClip (parent).setChildIndex (MovieClip (parent).getChildByName (
"brick" + i_position + "" + (j_position + simpleOrDoubleExplosion )), 0);

******

40
îl ștergem localizându -l cu ajutorul variabilelor globale al clasei „ i_position ” și „ j_position ” precum
parametrul funcției. Modificăm valoarea elementului matricei cu care s -a construit harta jocului din
doi în valoarea zero (valoarea ce reprezintă „iarba”) asigurându -ne pe viitor că nu va mai intra în
această funcție în cazul unei explozii pe această locație. Se va declara, instanția și inițializa obiectul
de tipul „ Pattern ”, în exact aceeași poziție de unde s -a șters obiectul de tip „bambus”. Îi atribuim un
nume unicat pentru situațiile în care dorim să accesam un obiect după denumirea lui cu ajutorul
funcției „ getChildByName ()” cum se întâmplă și pe ultimul rând al exemplului de mai sus. Așad ar
așezăm obiectul pe ecran spunându -i să se oprească pe cadrul care conține imaginea cu „iarba”. La
final îl aranjăm în profunzime aliniindu -l cel mai în spate posibil.
2.7.9 Enemy.as
Gestionarea comportamentului fiecărui „dragon” este gândită și construită în această clasă.
Indiferent dacă va apărea unul doi sau trei „dragoni” în nivelul care se joacă în acest moment , poziția
de start va fi întotdeauna aceeași pentru fiecare „dragon”. La adăugarea lor pe ecran fiecare primește
un nume unic cu ajutorului căreia aici în această clasă verificăm și identificăm despre care „dragon”
este vorba și ne comportam ca atare. La fel ca și în cazul clasei „Player” după ce ne asigurăm că
adăugarea cla sei s-a făcut cu succes ne definim o matrice pentru a urmării evoluția pe harta creată la
început. Pentru a distinge „dragonii” de „player”, „bombe” în poziția matricei atribuim valoarea opt.
Cu variabile care indică ce direcție s -a decis să meargă „dragon ul” setate pe fals intrăm în următoarea
funcție unde avem un „ state machine ” format din patru ramuri. Pe prima ramură se verifică dacă
caracterul principal este în viată caci desigur dacă el nu ar fi este inutil să înaintăm în această funcție.
Pentru a dou a ramură controlăm situația în care caracterul principal s -a atins de acest „dragon” iar
dacă da primul lucru se transmite prin intermediul variabilelor răspunzătoare cu această informație
către clasa „Level” respectiv același lucru se face și pentru „drag onul” care a fost implicat în această
situație. În a treia ramură se intră în situația în care „dragonul” în cauză este în viată. Aici ne ajută
funcția „ liveThisEnemy(this.name) ” care returnează un boolean indicând dacă „dragonul” este viu
sau nu. Și în ac est caz controlul se face cu ajutorul numelui unic alocat și transmis prin parametrul
funcției. Stocăm rezultatul funcției care generează un număr aleatoriu de la zero la trei într -o variabilă
care ne va ajuta să facem toate setările necesare în urma rezul tatului aleatoriu și permite pornirea
secvenței în care „dragonul” se va deplasa în stânga sau dreapta sau sus sau jos. Odată ce decizia a
fost luată iar setările au fost făcute vom trece m direct la codul care gestionează situația pentru accesată
situație unde primul lucru care se face este să pornim animația corespunzătoarea. Animația va fi
redată indiferent dacă în acea direcție în care urmează să se deplaseze „dragonul” este zid sau nu.
Dacă este zid deplasarea nu va avea loc dar prin redarea animației s imulăm cum că „dragonul” a
încercat să meargă în acea direcție dar nu a putut. Contrar, deplasarea va avea loc printr -o tranziție de
tip alunecare pe una din cele patru axe in intervalul de timp de 800 de milisecunde. Pe parcursul

41
acestui interval de timp, cu ajutorul funcției denumire „ checkIfTheyCollide ()” se verifică în timp real
dacă între acest „dragon” și caracterul principal există vreo coliziune situație în care, din nou
avertizăm clasa „Level” de faptul că „player -ul” a murit. Urmează actualizarea poziției pe matrice a
noii poziții al „dragonului”. La final, cu ajutorul unui temporizator de o secundă rechemăm funcția
care controlează mișcarea. Ultima ramură este pentru situația în care pentru toate verificările făcute
până acum pe celelalte ramuri n u s-a încadrat, cu alte cuvinte „dragonul” este mort, de exemplu de
suflul vreunei explozii, situație în care acest „dragon” îl scoatem din joc.
2.7.10 Reclaimer .as

Singura clasă care .nu are o funcție de întrerupere bazată pe timp sau o
întrerupere de tip atingere ori taste. În cadrul unei iterații gen „while()” se fac
toate controalele necesare pentru d eciziile care trebuie luate . Un alt aspect
important este faptul că această iterație actualizează poziția săgeții în timp real.
Pentru acest caz nu ne folosim de nici o tranziție de tip alunecare de la
„GreenSock – TweenLite”
Pentru acele nivele de joc unde această clasă apare, obiectul „arc” va fi
în aceeași poziție întotdeauna. Deci după ce adăugam obiect ul de tip „arc” pe
ecran îi setăm poziția și dăm drumul iterației mai sus amintite dar nu înainte de a pregăti vectorul care
va conține săgețile de pe ecran. Intrăm în funcția „ onEnterFrameLoop ()” care este chemată
aproximativ de 30 d e ori pe secundă caci atâtea cadre pe secundă am setat să se redea pentru acesta
aplicație, primul lucru care se verifică, ca de obicei , este certitudinea faptului că nivelul nu s -a
terminat, adică caracterul principal este în viată, de asemenea verificăm dacă a terminat cu succes
nivelul iar ultima verificare se face asupra timpul ui pentru a ne asigura că nu a expirat timpul alocat
pentru acest nivel . În cazul în care una din aceste trei controale se confirmă pornim o iterație în cadrul
căreia se vor șterg e toate săgețile de pe ecran urmată de ștergerea, oprirea iterației principale al clasei.
Pentru cazul în care totul este bine, se vor chema două funcții. Una pentru crearea săgeții și
stabilirea unghiului, vitezei acesteia iar o a doua funcție unde se v a actualiza poziția săgeții pe ecran.
Prima funcție „ createArrow ()” are ca și parametrii două obiecte. Obiectul „arc” car ne va ajuta la
stabilirea poziției pe cele două axe a săgeții și obiectul „player”, adică caracterul principal folosit
pentru a stabili către ce direcție se va îndrepta săgeata. Așadar intrând în fu ncție controlăm dacă
numărul de săgeți pe ecran a atins numărul maxim stabilit prin constanta „ particlesTotal ” la începutul
clasei. Dacă pe ecran sunt atâtea săgeți cât permite acesta constantă, funcția va fi întreruptă. Dacă
numărul de săgeți este mai mic ă decât constanta atunci incrementăm variabila cu care am comparat
și se va declara, instanția și inițializa obiectul de tipul „arc”. Majoritatea obiectelor au ca și punct zero
stânga sus, adică acel punct de unde începe măsurarea lor în lățime sau înălțim e. Având în vedere

Figura 13 – Arc

42
acest aspect, pentru a stabili punctul de așezare al „săgeții” pe axa X plecăm de la punctul în care a
fost așezat „arcul”, scădem lățimea „săgeții” și adunăm lățimea „arcului”. Astfel capătul va fi pe
aceeași line cu firul arcului. Pent ru poziția pe axa Y este un pic mai simplu , fiind necesară doar
coborârea cu jumătatea din înălțimea „arcului” din punctul de origine al acestuia . Se va stabili unghiul
pe care „săgeata” îl va urma pe tot parcursul vieții lui. Presupunem că avem un punct c u coordonatele
(x, y) putem calcula unghiul în radiani între acel punct și axa pozitivă X cu ajutorul funcției
„Math.atan2 (x, y);”. În aceeași ordine de idei se va calcula viteza pe axa X și respectiv viteza pe axa
Y a „ săgeții ” deoarece aceste viteze sunt diferite în funcție de acele două coordonate pe care caracterul
principal îl are în momentul în care „ săgeata ” va fi așezată pe ecran. La finalul acestei funcții vom
împinge, adaugă acest obiect în vectorul care tine toate „săgețile” de pe ecran. Ne va ajuta la fiecare
accesare al acestuia .
A doua funcție chemată din iterația principală a clase se numește „ updateArrow ()”și are rolul
de a actualiza poziția „săgeții” pe ecran cât și gestionarea unor situații legate de ea. Pentru fiecare
săgeată de pe ecran, deși în cazul nostru poate fi zero sau cel mult o „săgeată” pe ecran , acest „for”
este pentru eventualitatea în care aplicația va fi dezvoltată în continuare și s -ar lua decizia ca pe ecran
să existe posibilitatea să apară mai multe săgeți simultan. Fiind vorba de mai multe „săgeți” declarăm
un obiect de tipul „ MovieClip ” care să reprezinte fiecare „săgeată” extrasă din vectorul mai sus
amintit „ particlesArray []” și cu ajutorul acestui obiect temporar actualizăm pozițiile pe axa X și Y a
„săgeții”. Urmează o verificare pentru situația în care „ săgeata ” ar atinge caracterul principal. Desigur
s-ar demara situatia pentru încheierea nivelul ui fără succes. În momentul în care „săgeata” ar ieși din
ecran, indiferent dacă ar fi pe axa X sau axa Y acesta trebuie ștearsă, eliminată astfel se poate adăuga
o alta. Această eliminare are ca și modalitate de gestionare ca și funcția precedentă , adică se definește
un obiect temporar care va reprezenta fiecare „săgeata” comparând cu parametrul funcției care la
rândul ei este „săgeata”. După etapa de comparație, scădem valoarea variabilei care ne indică câte
„săgeți” sunt pe ecran, eliminăm din vector ele mentul corespunzător „săgeții” noastre și executăm
eliminarea cu ajutorul funcției „ removeChild ()”.
private function destroyParticle (particle :MovieClip ):void
{
for (var i = 0; i < particlesArray .length; i++)
{
var tempArrow :MovieClip = particlesArray [i];
if (tempArrow == particle )
{
particlesCurrent –;
particlesArray .splice(i, 1);
removeChild (tempArrow );
}
}
} // END -> destroyParticle();

43
2.8 Testare
În procesul de dezvoltare de software, există pericole și riscuri de evita t, atât pentru
dezvoltatorii de aplicații, cât și pentru dezvoltatorii de jocuri . Testarea software -ului, este una dintre
etapele consumatoare de resurse ale ciclului de dezvoltare . Unii dezvoltatori consideră că este un
proces scurt pentru a găsi erori, un rău necesar sau o problemă secundară , de fapt este stadiul în care
trebuie găsită orice problemă al produsul ui. Testerii înșiși consideră adesea că etapa de testare este
grăbită sau insuficientă. Cea mai mare concepție greșită despre testarea software -ului este că orice
metodă de testare este mai bună decât alta . Testarea unui set strict de condiții sau efectuarea de teste
aparent aleatorii nu sunt suficiente, indiferent de cât de mare este procesul , rezultatul fiind de a găsi
cât mai multe „bug-uri” posibil, lăsând software -ul cât mai funcțional posibil .
Testarea „ad-hoc”, cunoscută și sub denumirea de testare gratuită, este un stil de testare care
se încadrează cu siguranță în partea artistică a spectrului . Această formă de testare este cea mai ade sea
folosită în testele de joc pentru a încerca un nou software cu obiective foarte largi. Ca și stil, este
foarte fluid și adesea pare aleatoriu; un tester de joc poate progresa de -a lungul a jumătate de nivel,
deoarece dezvoltatorul intenționa să încerce doar să sară printr -o fisură î n mediul înconjurător,
determinând caracterul lor să părăsească limitele mediului și să se blocheze, imposibilitatea de a
reveni la fluxul normal al jocului. Atunci când se testează o secvența de software, un tester poate
încerca să bucleze întreaga prezen tare de mai multe ori, fără a permite timpul necesar încărcării
imaginilor sau videoclipurilor, ceea ce ar putea afecta memoria disponibilă până la punctul în care
software -ul nu mai răspunde și se blochează . Cantitatea de creativitate necesară pentru acea stă formă
de testare poate uneori să pară uimitoare. Numărul de acțiuni neobișnuite pe care testele le vor încerca
atunci când sunt lăsate să ruleze pe dispozitive poate fi surprinzător și vor găsi adesea un număr destul
de mare de probleme care pot fi apo i corectate înainte de lansare.
În timp ce toate aceste lucru ri sună minunat, deseori se găsește unele probleme majore care
altfel ar fi fost neobservate dar există câteva probleme cu această metodă. Est e aproape imposibil să
acoperim toate funcțiile de software în acest fel . Există multe variabile aleatorii care trebuie luate în
considerare pentru cazurile de testare pentru a acoperi fiecare apariție posibilă. De asem enea, este
important să reținem că unii testeri pot fi plictisiți cu ușurință de protocoalele de testare stricte, care,
în cazuri rare, ar putea duce la o testare non corectă. Tehnicile de testare "blac k-box":
 Crearea de rapoarte rapide privind erorile
 Adoptarea mentalității : trebuie să fie „bug-uri”
 Nu testați doar " Happ y day scenario "
 Testați în condiții, situațiile reale
 Testați ca și cum sunteți un utilizator obișnuit

44
 Păstrați rapoarte scr ise pentru tehnicile de testare
 Căutați întotdeauna să obțineți noi cunoștințe
În testarea "black -box", există puține informații despre funcționarea internă a software -ului;
tot ceea ce un tester vede este ceea ce ar vedea utilizatorul final. Redarea unei versiuni beta a l unui
joc pe o consolă de testare este un bun exemplu în acest sens. Testarea „white -box” utilizează funcții
interne cu ajutorul unor suite de software (de obicei, un program de depanare) pentru a urmări ce se
întâmplă în timp ce software -ul rulează, transmiterea informațiilor către tester sau la un jurnal de
testare, dacă este necesar. Exemple bune ale acestor metod e de testare ar fi testarea unui software
construit într -un mediu de dezvoltare al platformei de programare sau utilizarea unui software de
automatizare pentru a testa variațiile minore ale unei acțiuni în mod repetat, cu un „debugger ” care
rulează în fund al. Este important să păstr ăm un echilibru între testarea „white -box” și "blac k-box"
pentru a ne asigura că software -ul în cauză este testat temeinic.
Tehnicile de testare „cutie neagră ”, cunoscute și ca un tip de testare comportamentală, oferă
echipelor de dezvoltare posibilitatea de a examina software -ul fără a fi nevoie de o înțelegere profundă
a codului folosit pentru a -l construi . Stilul de testare privește intrările și ieșirile software -ului testat,
dar nu examinează funcționarea internă a produsului . Codul în sine este tratat ca și cum ar fi fost
ascuns sub o cutie neagră. Prin separarea perspectivelor utilizatorilor și a dezvoltatorilor, testarea
cutiei negre permite testerelor să valideze mai eficient corpuri mari de coduri, cu o înțelegere
profund ă a modului în care au fost construite
Testerele bune pot fi identificate prin rata de rezoluție a acestora. Au cele mai multe rapoarte
de „bug-uri” rezolvate. Un raport de eroare bun este unul care ajută la rezolvarea unei probleme.
Trebuie să ne asigură m că rapoartele de erori pot fi reproduse cu ușurință, făcându -le cât mai clare și
mai concise. Iată câțiva pași pe care îi se poate urma pentru a îmbunătăți tehnicile de testare "black –
box" în ceea ce privește raportarea erorilor.
Reproductibilitatea – Informăm dezvoltatori cât de des apar „bug -urile”:
Reproductibilitatea Definiție
Întotdeauna Defectul apare întotdeauna.
Câteodată Defectul nu apare întotdeauna.
La întâmplare Defectele apar sporadic.
Nu este reproductibilă Defecțiunea nu poate fi reprodusă din nou.

Severitate – Identificați scala bug -ului:
Severitate Description

45
Block Când un bug întrerupe utilizatorul să lucreze cu un aspect al sistemului.
Aceste bug -uri au cea mai mare prioritate.
Crash Când apare o pagină de eroare. Uneori, acest lucru se întâmplă atunci
când dezvoltatorii uită instanțe ale sistemului.
Major Atunci când o eroare are un impact major asupra funcționalității unui
aspect important al software -ului.
Minor Atunci când un bug provoacă un prejudiciu major unei anumite părți de
funcționalitate, dar nu afectează multe aspecte ale software -ului.
Tweak Nu există nicio problemă cu caracteristica, dar modul în care
funcționează ar trebui să fie ușor modificat (ajustat).
Text O problemă cu textu l și / sau etichetele software -ului. De obicei
introduceți greșeli sau etichete care nu corespund specificațiilor.
Feature Aceasta este o caracteristică nouă care ar trebui implementată. În cele
mai multe cazuri, nu este un bug. Testerului i se poate soli cita să adauge
un astfel de raport pentru a informa dezvoltatorii despre o nouă
caracteristică care ar trebui adăugată software -ului.

Rezumat – Descrieți Bug într -o singură propoziție:
Utilizați acest a ca titlu pentru raport. Fiți descriptiv și concis . Ce face „bug-ul” să împiedice
utilizatorii ? Ce riscuri va prezenta dacă „bug-ul” nu este abordat? Este prezentarea bug -ului doar
pentru grupurile cu anumite nivele de permisiune? Acestea sunt tipurile de întrebări cerute de testeri
experimentați.
Descrie re detaliată a erorilor – mai multe detalii conduc la o rezoluție rapidă
Asigurați -vă că includeți i nformații despre eroare – aici trebuie să explicați datele de intrare
pe care le -ați folosit și succesiunea de pași pe care ați făcut -o pentru a provoca eroarea. Acest punct
este destul de important, asigurați -vă că instrucțiunile sunt clare și reproductibile. Asigurați -vă că
utilizați aceeași terminologie ca și dezvoltatorii. Screenshots , imagini cu comentarii și explicații.
Testerii sunt oameni special izați în „ruperea” de software. Fiecare dintre aceștia au metode
proprii, căi preferate de a face teste, dar majoritatea sunt competente cu o varietate de metode de
testare . Cantitatea de acces pe care le au la resursele necesare pentru a efectua teste ade cvate sunt
adesea determinate de nivelul lor de asociere cu un dezvoltator. Relațiile lor strânse cu dezvoltatorii,
permite adesea acces la instrumente mai avansate. Primul obiectiv ar fi stabilirea unei distribuții
adecvate a tehnicilor de testare, s ă se determine care testere este cel mai potrivit sarcinilor. După ce
sa stabilit acest lucru, testerele ar trebui să fie separate în echipele corespunzătoare pentru sarcinile
de testare necesare. Cereți opiniile testerelor din când în când; acestea pot avea un ele opinii care ar
dezvolt a, intensifica software -ul dvs. într -un mod pe care nu ați avut în vedere înainte. Cu toții dorim
ca proiectele noastre să reușească și, cu puțină muncă în echipă, putem lansa un titlu cu cât mai puține

46
erori și cât mai multă eleganță posibil.

47
3 Concluzii

48
4 Anexe

4.1 Bibliografie

[CSH07] Kimberly Graves – ActionScript® 3.0 Bible (Second Edition)
Published by Wiley Publishing, Inc
ISBN: 978 -0-470-52523 -4,
Indianapolis, Indiana

[CSH07] Joey Lott, Danny Patterson – Advanced ActionScript 3 with Design Patterns
Publisher: Adobe Press
Print ISBN -10: 0 -321-42656 -8
Print ISBN -13: 978 -0-321-42656 -7
Berkeley, CA 94710

[CSH07] Colin Moock – Essential ActionScript 3.0
Published by O’Reilly Media, Inc
ISBN -10: 0 -596-52694 -6
ISBN -13: 9 78-0-596-52694 -8
Gravenstein Highway North, Sebastopol, CA 95472

[CSH07] Rich Shupe with Zevan Rosser – Learning ActionScript 3.0 (A Beginner's Guide)
Published by O’Reilly Media, Inc
ISBN -10: 0 -596-52787 -X
ISBN -13: 978 -0-596-52787 -7
Gravenstein Highway North, Sebastopol, CA 95472

[WIK 01] https://en.wikipedia.org/wiki/SWF
[WIK02 ] https://en.wikipedia.org/wiki/Adobe_Animate
[WIK03 ] https://en.wikipedia.org/wiki/Adobe_AIR
[WIK04 ] https://en.wikipedia.org/wiki/Adobe_Flash
[WIK05 ] https://en.wikipedia.org/wiki/ActionScript
[ADB01 ] http://www.adobe.com/devnet/actionscript/articles/six_reasons _as3.html
[GRS01 ] https://greensock.com/tweenlite -as
[ADM01 ] https://www.google.com/admob

49
4.2 Index poze, figure, tabele

FIGURA 1 – „LIBRĂRIA” 16
FIGURA 2 – ECRANUL SI „TIME LIN E” 17
FIGURA 3 – EXPLOZIA 18
FIGURA 4 – „ENEMY” 19
FIGU RA 5 – TWEENLITE – GREENSOCK 25
FIGURA 6 – ADMOB BANNER 26
FIGURA 7 – DIFUZOARE 28
FIGURA 8 – SELECT LEVEL 29
FIGURA 9 – CHEIA, FULGER 32
FIGURA 10 – „LEVEL” 34
FIGURA 11 – TASTATURA 35
FIGURA 12 – BOMBĂ 37
FIGURA 13 – ARC 41