Tehnici Web

Impartirea proiectului pe foldere

Fiecare tip de resursa ar trebui sa fie in folderul sau. Imaginile, de exemplu, in folderul "imagini", fisierele audio in folderul "audio", idem pentru fisierele video. De asemenea, fisierele de configurare in format xml ar putea fi puse intr-un folder numit "configurare" sau "xml". Daca exista si css-uri specifice jocului, acestea vor fi, de exemplu, in folderul css.

Fisiere de configurare xml si obiectul Loader

Un joc in general are nevoie de anumite resurse precum: imagini, fisiere video, fisiere audio etc. Aceste resurse trebuie incarcate inainte de incepe jocul efectiv, pentru ca altfel, cand e nevoie de ele s-ar putea sa nu fi fost inca downloadate de pe server. Un mod eficient de trata problema e sa aveti un obiect special, numit Loader, care are o metoda Loader.parseResources(fisierxml) care se ocupa de incarcarea resurselor din xml si afisarea unui loading screen. Loading screen-ul ar consta dintr-un element progress care creste in valoare la fiecare resursa incarcata. Mai jos aveti un exemplu de fisier xml:

In urma executiei functiei parseResources() obiectul Loader ar trebui sa aiba pentru fiecare tip de date cate un obiect in care proprietatile sunt egale cu id-urile elementelor iar valorile egale cu obiectele asociate.

De asemenea dorim sa avem stocate diverse date referitoare la joc; date pe care nu am dori sa le hardcodam (sa le scriem valorile efective in cod). Pentru acest lucru veti folosi fisiere xml.

Un exemplu de fisier de date e fisierul de mesaje. Putem avea mai multe cazuri in care vrem sa dam acelasi mesaj (de exemplu, mesajul care anunta jucatorul caa a pierdut jocul e dat si cand a ajuns cu sanatatea la zero dar si cand a atins marginea chenarului jocului). Am vrea sa nu il hardcodam"" pentru ca poate mai tarziu dorim sa il schimbam si ar trebui sa modificam fiecare aparitie a sa in cod. De asemenea, daca vrem sa putem seta jocul pentru diverse limbi, am vrea o metoda rapida si eficienta de a obtine mesajul potrivit pentru fiecare situatie (deci nu sa facem un set de if-uri care verifica limba setata, in cazul fiecarui mesaj de afisat)

Pentru a incarca mesajele Loader-ul va avea o metoda Loader.parseMessages(). Aceasta poate primi limba ca parametru sau limba e setata in functia Loader.init() (metoda de initializare a loaderului). Loaderul va incarca doar mesajele limbii setate. Va avea o metoda Loader.getMessage(id) care va returna mesajul.

Namespace-ul jocului

Jocul trebuie sa aiba propriul sau namespace, dar namespace-urile in Javascript sunt simbolizate prin obiecte. Deci cititi in laborator despre diversele moduri de definire a namespace-urilor si alegeti o metoda care sa se potriveasca bine cu ce aveti de facut.

Fisierul de constante

Ideal ar fi sa evitam hardcodarea valorilor. Daca scriem valorile direct, poate vrem apoi sa le modificam si trebuie sa cautam intr-un cod imens un numar (pe care poate nu-l mai tinem minte sau oricum si daca ni-l amintim, cu find mai fasim cateva pana dam de el). Astfel vom defini un fisier de constante, numit constante.js care va contine toate acele date care nu se potriveau prea bine in fisierele xml.

Cum fisierul de constante va fi folosit de catre modulul principal al jocului, va trebui inclus in html inaintea modulului principal. Deci fisierul de constante va fi cel care se va ocupa de crearea namespace-ului jocului in care va defini constantele.

Avem cel putin 2 variante de definire al lor. De mentionat este ca nu putem folosi const pentru ca nu putem creea proprietati constante ale unui obiect (cel putin nu in mod direct)

Daca obiectul corespunzator jocului il construim cu functia constructor sau ii definim o clasa prin class, atunci cel mai sigur mod e sa ne definim "constantele" ca variabile locale cu valori date, pentru care definim niste getteri.

Mai jos aveti exemplu pentru functia constructor: function Joc(){
    var NR_MILISECUNDE_UPDATE=100;
    var DEBUG_MODE=true;//de exemplu o variabila care ne spune daca sa afisam anumite mesaje de debug
    //etc.
    
    this.getNrMilisUpdate=function()
    {
        return NR_MILISECUNDE_UPDATE;
    }
    this.getDebugMode()=function()
    {
        return DEBUG_MODE;
    }
}


Putem realiza acelasi lucru si in stilul ES6 (dar nu va functiona pe browsere vechi): class Joc{
    //...
    get NR_MILISECUNDE_UPDATE(){return 100;}
    get DEBUG_MODE(){return true;}
    //...
}


Sau putem defini obiectul cu object literal. Personal consider ca e mai buna aceasta varianta, deoarece clase definim pentru cazul in care dorim mai multe instante de acelasi tip. Dar in cazul nostru obiectul joc e unic. joc=(function(){
    var NR_MILISECUNDE_UPDATE=100;
    var DEBUG_MODE=true;
    //...
    return {
            getNrMilisUpdate:function()
            {
                return NR_MILISECUNDE_UPDATE;
            },
            getDebugMode:function()
            {
                return DEBUG_MODE;
            }
            //...
        }
    })();


Clase custom pentru entitatile aplicatiei

De exemplu, pentru o aplicatie-joc, sa ne imaginam ca avem pe ecran niste adversari cu care se lupta cu jucatorul. Fiecare adversar are niste caracteristici, de exemplu: viteza, viata etc. Fara sa grupam toate caractersticile intr-un obiect am ajunge sa avem vector de viteze, vector de vieti etc. Si sa recuperam caracteristicile cu ajutorul unui indice insa asta ar complica mult lucrurile. Cand vrem sa stergem un astfel de obiect, trebuie sa ii stergem proprietatile din toti acei vectori. Arm mai putea memora datele chiar in obiectul DOM asociat, creand proprietati noi. Insa daca faceti asta puteti avea probleme cu obiectele respective; puteti suprascrie din gresala o proprietate default sau browserul sa nu le trateze cum trebuie din cauza acelor proprietati in plus. Doar in dataset ar putea fi adaugate proprietati dar si aici suntem limitati de faptul ca dataset cuprinde doar proprietati cu valori String, deci nu am putea sa memoram referinte la obiecte, de exemplu. Asadar cea mai eleganta metoda si cea care ne ajuta sa evitam eventuale bug-uri este sa cream obiecte (fie prin clasa/functie constructor, fie prin object literal) pentru fiecare entitate a jocului: jucator, adversar, obstacol etc.

Daca insa pentru anumite elementele nu avem proprietati in plus fata de cele oricum oferite de interfata DOM, nu mai e necesar sa facem clase pentru ele. De exemplu daca un obstacol trebuie lovit de 3 ori ca sa dispara atunci avem proprietate in plus pentru ca trebuie sa stim de cte ori a fost lovit pana in momentul curent. Dar daca obstacolul doar exista pe ecran si jucatorul nu poate sa se deplaseze peste el, atunci singurele proprietati care ne intereseaza sunt pozitia si dimensiunea, iar aceastea oricum sunt memorate in stilul obiectului DOM, deci in acest caz nu ar mai fi necesara crearea unei clase pentru el.

Pentru o aplicatie de procesare a datelor din pagina, de exemplu una care proceseaza datele unor produse, am dori sa grupam toate acele date intr-un singur obiect.

Pentru aplicatii care schimba tema site-ului putem avea obiecte referitoare la datele afisate si setarile utilizatorului pentru tema respectiva.

Modularizare si organizare proiect