Tehnici Web

Nu esti logat.

Proiect JavaScript

Acest proiect nu este de sine statator ci este o continuare a proiectului de html si css. Deci functionalitatile implementate trebuie sa fie in concordanta cu tema primului proiect.

Descrierea proiectului si cerintele minimale trebuie discutate cu mine pana pe 20 decembrie la laborator. Daca cineva nu reuseste sa vina la laborator, mai putem discuta pe messenger/mail despre tema proiectului, pana maxim pe 23 decembrie. O sa accept mesaje si dupa aceasta data, insa aceasta intarziere e pe raspunderea studentului, si daca imi trimite mesaj/mail cu foarte putine zile inainte de ziua prezentarii temei si poate, fiind ocupata atunci, nu raspund la vreme, consider ca nu este vina mea, avand in vedere ca data indicata a fost in mod oficial 20 decembrie (eventual extinsa pana pe 23), studentul avand de la aceasta data suficiente zile de lucru pana la prezentarea proiectului.

Mai jos este o lista cu cerintele eliminatorii. Acestea apar si in barem, uneori impartite pe mai multe cerinte mici.

Cerinte eliminatorii

  1. Discutarea la laborator sau pe messenger/mail in legatura cu tema de proiect. Exista doua variante:
    • fie studentul va formula o descriere a jocului (sau a altei aplicatii JS) sub forma unor cerinte minimale) aceste cerinte vor trebui trimise pe messenger/mail sau uploadate pe site. Cerintele proiectului date de student vor fi modificate partial de catre mine sau ii voi compune niste cerinte in plus (practic o parte din cerinte le stabileste studentul si o parte eu).
    • Studentul nu vine cu ideea lui (fie nu stie ce sa faca, fie nu are o preferinta anume), caz in care va primi de la mine o tema de proiect
    Cerintele care au fost date de mine (sau modificate de mine) si scrise si pe site nu pot fi modificate de catre student fara acordul meu (adica nu poate implementa altceva decat cerintele puse pe site). Daca studentul nu aplica exact cerintele minimale, proiectul sau nu va fi punctat. La aceste cerinte minimale, studentul insa poate sa adauge din barem oricate elemente doreste astfel incat sa aiba cerintele eliminatorii indeplinite dar si pana ajunge la punctajul dorit. Nu este permisa prezentarea proiectul in cazul in care studentul a facut altceva decat tema alocata.
  2. Script extern (intr-un fisier js). Impartirea resurselor in foldere (de exemplu, folder de imagini, folder de xml-uri, folder de txt-uri etc.) si impartirea jocului pe module js.
  3. Se vor prelua date (fara ajutorul unui form) din cel putin urmatoarele 7 tipuri de elemente html prin care utilizatorul poate introduce optiunile sale: input de tip text, input de tip range, input de tip radio, input de tip ceckbox, select simplu, select multiplu, textarea. Valorile introduse vor fi verificate cu ajutorul RegExp.
  4. Vor exista triggere pentru macar urmatoarele tipuri de evenimente: incarcarea paginii(sau a altui tip de element:imagini, fisiere media etc.), evenimente de mouse (cu preluarea coordonatelor), evenimente de tastatura
  5. Creare si stergere dinamica de elemente
  6. Folosirea a minim o proprietate/metoda din clasele predefinite: Date, String, Math, Array. Generare elemente random.
  7. Schimbarea dinamica a stilulul unui element
  8. Functiile setTimeout si setInterval
  9. Un namespace specific aplicatiei/jocului. Clase custom pentru diversele entitati ale jocului.
  10. Miscare independenta a elementelor. Miscare provocata de utilizator. Testarea coliziunii.
  11. localStorage

Uneori cerintele eliminatorii apar cu 0 puncte deoarece de fapt ele constau in alegerea unor sub-cerinte. Nu am gasit o metoda mai buna de a le ilustra in barem.

In cazul in care anumite chestiuni din barem nu pot fi folosite in cadrul jocului pentru ca structura acestuia nu o permite, este ok sa adaugati mici functionalitati de JS in restul proiectului de html si css.

Detalii de implementare

Pentru o structurare mai buna a jocului va propun urmatoarele idei de organizare si implementare.

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:

Fisier xml de resurse

<?xml version="1.0" encoding="utf-8" ?>
<resurse>
    <imagini>
        <imagine tip="adversar" w="10" h="10" id="fant_mica" aparitie="multipla">
            img/adversari/fantoma_mica.png
        </imagine>
        <imagine tip="adversar" w="20" h="40" id="fant_mare" aparitie="multipla">
            img/adversari/fantoma_mare.png
        </imagine>
        <imagine tip="adversar" w="20" h="20" id="fant_rea" aparitie="multipla">
            img/adversari/fantoma_rea.png
        </imagine>
        <imagine tip="jucator" w="20" h="20" id="jucator" aparitie="singulara">
            img/jucator/erou.png
        </imagine>
    </imagini>
    <sunete>
        <sunet id="strigat">
            audio/buhuhuhuahahahahaha.ogg
        </sunet>
        <sunet id="valeu">
            audio/jucator/valeu.ogg
        </sunet>
    </sunete>
    <fisiere_video>
        <video id="cutscene">
            video/bataie_fantome.ogv
        </video>
    </fisiere_video>
</resurse>

Pentru acest fisier, de exemplu, vom crea o propietate a Loader-ului numita imagini. Pentru fiecare set de informatii pentru cate o imagine vom crea un element DOM de tip imagine si vom adauga in obiectul imagini o proprietate cu id-ul resursei respective si avand ca valoare obiectul DOM asociat. La fel vom face si pentru audio si video.

Pentru fiecare tip de resursa vom avea si cate o functie de tip get care primeste id-ul resursei:

  • Loader.getImage(id_xml) - va intoarce elementul DOM asociat si penttru imaginile cu atributul aparitie="multipla" va crea un element nou de tip imagine (in asteptare). Facem acest lucru deoarece dorim sa avem aceeasi imagine de mai multe ori in pagina. Daca aparitie="singulara" inseamna ca stim ca imaginea o sa apara o singura data asa ca nu e nevoie sa creem mai multe elemente DOM de acelasi fel.
  • Loader.getAudio(id_xml) - va intoarce elementul audio asociat (fara a mai crea altul)
  • Loader.getVideo(id_xml) - va intoarce elementul video asociat (fara a mai crea altul, decat daca vreti sa rulati in paralel acelasi videoclip de mai multe ori)

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)

Fisier xml de mesaje

<?xml version="1.0" encoding="utf-8" ?>
<lang>
    <mesaje lang="ro">
        <mesaj id="fail">
            Ai dat-o-n bara.
        </mesaj>
        <mesaj id="castig">
            Yaaaaay ai castigat!
        </mesaj>
        <mesaj id="pierdut">
            Hopa, murisi, ma?!
        </mesaj>
    </mesaje>
    <mesaje lang="en">
        <mesaj id="fail">
            You failed.
        </mesaj>
        <mesaj id="castig">
            You somehow won....
        </mesaj>
        <mesaj id="pierdut">
            You died!
        </mesaj>
    </mesaje>
</lang>

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.

Fisier xml de setari
<?xml version="1.0" encoding="utf-8" ?>
<setari>
    <nivele>
        <incepator>
            <nr_adversari>10</nr_adversari>
            <viata_adversari>100</viata_adversari>
            <viteza_jucator>80</viteza_jucator>
        </incepator>
        <mediu>
            <nr_adversari>20</nr_adversari>
            <viata_adversari>200</viata_adversari>
            <viteza_jucator>70</viteza_jucator>
        </mediu>
        <avansat>
            <nr_adversari>30</nr_adversari>
            <viata_adversari>300</viata_adversari>
            <viteza_jucator>70</viteza_jucator>
        </avansat>
    </nivele>
    <gloante>
        <glont id="g0">
            <nume>glont de baza</nume>
            <imagine>im_g0</imagine><!-- id-ul imaginii corespunzatoare -->
            <putere>10</putere>
            <viteza>200</viteza>
        </glont>
        <glont id="g2">
            <nume>glont mega</nume>
            <imagine>im_g1</imagine><!-- id-ul imaginii corespunzatoare -->
            <putere>50</putere>
            <viteza>100</viteza>
        </glont>
        <glont id="g3">
            <nume>super glont</nume>
            <imagine>im_g2</imagine><!-- id-ul imaginii corespunzatoare -->
            <putere>100</putere>
            <viteza>300</viteza>
        </glont>
    </gloante>
    <harti>
        <jucator>j</jucator>
        <turn>t</turn>
        <zid>#</zid>
        <liber>0</liber>
        <harta id="h1">
            <linie>000000t000######000000t</linie>
            <linie>0000000000000##000##000</linie>
            <linie>000#####000000000#####0</linie>
            <linie>00000#000000t00000000#0</linie>
            <linie>0j000#000#####00t0000#0</linie>
            <linie>000000t0000000000#####0</linie>
            <linie>00##00000###00000000000</linie>
            <linie>00##0000000000t00000000</linie>
        </harta>
        <harta id="h2">
            <linie>00t0000####00000000000t</linie>
            <linie>0###00t000000##00000000</linie>
            <linie>00000##############0000</linie>
            <linie>00000#0000tttt0000#0000</linie>
            <linie>0t00t#0t00tttt00t0#0000</linie>
            <linie>0##00#t00000000000#0000</linie>
            <linie>00#00###0#####0####0t00</linie>
            <linie>j0#00000000000000000000</linie>
        </harta>
        ...
    </harti>     ...
</setari>

Fisierul de setari poate contine descrierile nivelelor, ale obiectelor din joc, pozitii initiale, harti predefinite.

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;
            }
            //...
        }
    })();

Ecranul de setari

Nu folositi trimiterea datelor prin submit pentru realizarea acestui task. Valorile se vor prelua direct din inputuri. Veti avea un container cu minim urmatoarele tipuri de inputuri:

  • input de tip range (de exemplu poate seta numarul de vieti, numarul de adversari, dimensiunea unui element pe ecran, numarul de secunde de game-play etc.)
  • input de tip text (de exemplu pentru numele utilizatorului sau pentru un motto, sau pentru a scrie ceva intr-un anume format, cum ar fi un cheatcode)
  • checkbox-uri (de exemplu pentru a seta daca sa apara ceva sau nu pe ecran, sau pentru cazul in care dorim sa avem valori multiple pentru o propritate, cum ar fi cazul in care avem mai multe tipuri de adversari din care putem alege oricate categorii)
  • grup de radiobuttons (de exemplu pentru a seta nivelul de joc, pentru a alege o culoare de background, pentru a alege o anume harta, un anume tip de adversari, limba jocului, modul de calculare al scorului etc.)
  • select simplu (idem radiobuttons)
  • select multiplu (pentru valori multiple ale unui camp; vezi exemplul de la checkbox)
  • textarea (poate fi folosit pentru ceva asemenator cu cazurile de la inputul de tip text, sau pentru selectarea unor valori multiple daca le separam printr-un caracter special, de exemplu, culorile adversarilor: "red;green;blue")

Tot in container va fi si un buton. La click pe acest buton se vor prelua datele din inputuri si jocul va porni cu setarile

Inputurile de tip text si textarea-urile vor avea si un placeholder care explica formatul datelor. Datele introduse de utilizator vor fi verificate cu ajutorul RegExp.

Clase custom pentru entitatile jocului

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. Ar mai putea veni cneva cu varianta de a 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.

Functia de update a jocului

Uneori avem interactiuni intre elementele care se misca pe ecran. De exemplu vrem sa vedem coliziunea intre ele. Daca fiecare dintre ele are propria sa functie de miscare asociata (conform exemplului dat la laborator) atunci, daca verificam in cadrul functiei de miscare, detectam coliziunea de 2 ori pentru 2 obiecte care s-au intersectat. Cel mai simplu mod de a trata problema esta sa avem o functie joc.update(), care fi a fost apelata cu setInterval, fie se autopeleaza printr-un setTimeout si care se ocupa de toate calculele si repozitionarile obiectelor de pe pagina. Astfel ar putea verifica fara probleme coliziunile intr-un grup de n elemente (verificand intai primul cu cele de la al 2-lea incolo, apoi pe al doilea cu cele de la al 3-lea incolo si tot asa.

In plus uneori vrem sa avem si un cronometrru pentru joc (sa stim de cand a inceput jocul). Functia de update ar putea sa se ocupe usor si de aceasta functionalitate. Deci in general ar face toate calculele care tin de animatii si de trecerea timpului. Functia de update ar trebui apelata destul de des, daca se ocupa de animatii, de exemplu undeva intre 100-200 milisecunde. Daca in schimb se ocupa de elemente care nu trebuie actulizate foarte des, cum e cronometrul care s-ar actualiza oricum la fiecare secunda, e ok sa fie apelata si undeva intre 500-1000 milisecunde.

Folosirea sprite-urilor

Sprite-ul reprezinta o imagine mare cu mai multe sub-imagini in interiorul sau. In joc acestea se "decupeaza" (folosind proprietatea clip). Motivul folosirii unui sprite in locul mai multor imagini mici este ca un singur transfer cu imaginea mare poate dura mai putin decat toate transferurile imaginilor mici.

Un debugger live

Uneori vrem sa vedem cum se schimba valorile unor variabile in timp real, fara a pune breakpoints. Astfel am avea nevoie de un obiect MyDebugger cu metoda MyDebugger.setWatch(text,referinta). Iar cand avem in cod o variabila pe care vrem sa o urmarim, pur si simplu o transmitem ca parametru metodei setWatch() cu un text asociat care sa ne ajute sa identificam variabila in zona de afisare. Pentru variabilele urmarite ar trebui sa avem un tabel, sau macar un div cu randuri de forma text_setat=valoare in care sa urmarim cum se schimba valorile.

Resurse utile

Imagini gratuite:

Sprite-uri gratuite

Cursoare gratuite

Fisiere audio gratuite

Barem proiect

Baremul este extensibil, in sensul ca daca in urma discutiilor cu studentii decidem ca anumite elemente pe care oricum le-ar fi implemntat ar trebui punctate si ele, se pot adauga optiuni noi in barem. Baremul insa nu se va schimba in privinta elementelor deja existente.

In barem sunt trecute denumirile proprietatilor si metodelor din DOM, dar se puncteaza si daca ati folosit echivalentele din jQuery

Cand lucrati la joc, alegeti din barem elementele pe care doriti sa le implementati. Punctajul total depaseste cu mult punctul alocat deci aveti o mare libertate de alegere. Si evident, se puncteaza si se aduna la nota si elementele care depasesc punctajul alocat.

Elementele din categoria functionalitati sunt cele care se puncteaza cel mai mult si in rezolvarea acestora sigur vor fi cuprinse mai multe elemente de sintaxa javascript.

XML-uri

JSON-uri

Pentru cei care au preferat sa lucreze cu JSON in loc de xml.

Clase predefinite

Tot ce tine de crearea obiectelor custom

Obiecte custom

Tot ce tine de crearea obiectelor custom

DOM - general

Media

  • Observatiese puncteaza toate utilizarile distincte (daca intr-adevar difera suficient ca functionalitate).

Evenimente

  • Observatiese puncteaza toate utilizarile distincte (daca intr-adevar difera suficient ca functionalitate).

  • Observatiese puncteaza toate utilizarile distincte (daca intr-adevar difera suficient ca functionalitate).

Inputuri

Atentie, inputurile se vor puncta numai daca se preia valoarea lor in javascript (fara a folosi transmiterea de date a unui formular prin metoda get). Regula se aplica tuturor tipurilor de input, select, textarea, cu exceptia inputurilor de tip submit, reset si button.

Obiectul window

  • Observatiese puncteaza toate utilizarile distincte (daca intr-adevar difera suficient ca functionalitate).

  • Observatiese puncteaza toate utilizarile distincte (daca intr-adevar difera suficient ca functionalitate).

  • Observatiese puncteaza toate utilizarile distincte (daca intr-adevar difera suficient ca functionalitate).

Formulare

Storage

Diverse

  • Observatiese puncteaza toate utilizarile distincte (daca intr-adevar difera suficient ca functionalitate).

  • Observatiese puncteaza toate utilizarile distincte (daca intr-adevar difera suficient ca functionalitate).

  • Observatiese puncteaza toate utilizarile distincte (daca intr-adevar difera suficient ca functionalitate).

Functionalitati

  • Observatiese puncteaza toate utilizarile distincte (daca intr-adevar difera suficient ca functionalitate).

  • Observatiese puncteaza toate utilizarile distincte (daca intr-adevar difera suficient ca functionalitate).

  • Observatiese puncteaza toate utilizarile distincte (daca intr-adevar difera suficient ca functionalitate).

Punctaj calculat cu nota minima de complexitate:

Mod de prezentare si notare

Prezentarea se va face in saptamana a 13-a. Daca cineva e gata mai devreme poate prezenta si inainte. Daca la prezentare se observa greseli in proiect sau functionalitati marunte care pot fi adaugate usor, i se permite studentului sa corecteze si completeze proiectul (pana in 0.2 puncte) si sa prezinte modificarile in saptamana a 14-a in timpul testului de JavaScript.

Inainte de prezentare studentul trebuie sa bifeze in barem ceea ce a lucrat. Nu se va puncta nimic din ceea ce nu bifeaza in barem. In momentul prezentarii se vorb bloca checkboxurile pentru studentul respectiv. Aceasta regula e necesara pentru a rezolva urmatoarele probleme:

  • la prezentare ii va fi mai usor sa spuna ce a facut, fara sa caute in cod daca a folosit cutare sau cutare chestiune din barem. Timpul necesar prezentarii poate fi astfel redus.
  • studentul vede de acasa un punctaj estimativ pe care il poate obtine pe proiect. In casuta cu punctajul se aduna mereu punctele cu nota minima aplicata. Nota de complexitate e data la prezentare si, astfel, ii mai poate creste punctajul.
  • Poate studentul a folosit o portiune din exemplele de la curs/laborator insa nu se simte prea sigur sa prezinte acea bucata. In mod normal nu ar trebui sa se intample asa ceva, insa daca respectivul cod e vital ca sa mearga o anume portiune din proiect, studentul poate opta sa nu il adauge in cerintele realizate, si astfel sa nu fie punctat pentru codul respectiv dar nici sa nu primeasca intrebari de acolo care ar putea micsora nota sa de prezentare.

Punctajul scris in dreptul unei cerinte reprezinta un punctaj maxim. De exemplu, daca pentru scrierea mesajelor catre utilizator in urma unor evenimente in joc, avem 0.02 puncte, dar mesajele nu sunt bine stilizate, apar departe de containerul jocului, nu sunt relevante pentru joc, atunci se poate primi doar 0.01 sau chair 0.005 pe ele. Va puteti gandi ca primiti efectiv cate o nota pe fiecare element din barem (nu e vorba de nota de complexitate), si acea nota e transformata in puncte.

Atentie! Nota proiectului se va calcula astfel: grad_respectare_al enuntului_scris_pe_site*punctaj_proiect*nota_prezentare/10.. Deci daca ati luat chiar 1p pe proiect in urma notarii elementelor din barem insa la prezentare nu stiti sa explicati aproape nimic, si luati sa zicem nota 1 sau 2, veti primi doar 0.1-0.2 puncte. Motivul pentru aceasta restrictie este unul evident: prezentarea e dovada ca studentul respectiv a facut el insusi tot ceea ce exista in proiectul cu care a venit. De acee se poate lua chiar si 0 pe prezentare in cazul in care studentul nu poate explica absolut nimic din proiect (cu alte cuvinte anularea proiectului).

Pentru calcularea notei de prezentare, studentul va fi pus sa explice portiuni de cod sau sa raspunda la intrebari. Fiecare explicatie sau raspuns ar valora 0.5 din 10p ale notei de prezentare.

Prezentarea proiectului trebuie sa dureze intre 10-15 minute deci daca studentului ii ia mai mult de jumatate de minut sa se gandeasca pana a raspunde la o intrebare se va considera ca nu stie si se va trece la urmatoarea intrebare.

Sfat: este bine sa incercati sa obtineti un puncatj mai mare de 1p pentru a va asigura nota 10, deoarece mai pot sa apara depunctari.