Dezvoltarea școlii NRW - programare cu GLOOP - proiecte didactice - asociații

Zona de orientare (salt etichete)

  • OOP cu GLOOP
  • Pornire rapidă
  • Proiect de predare
    • introducere
    • Programare secvențială
    • Structuri de control
    • Cursuri proprii
    • Asociațiile
    • Moştenire
  • documentație
  • instalare
  • FAQ
  • Persoană de contact
  • Licență

CMS_VALUE [3]

În timp ce clasele proprii au fost deja introduse și prevăzute cu relații simple, următoarea secțiune tratează fluxul de date între mai multe obiecte. Până în prezent, obiectele au avut acces la alte obiecte numai dacă le-au creat singure. Acest lucru nu mai este suficient pentru probleme mai complexe. Dacă un obiect trebuie să aibă acces la unul care nu a fost creat el însuși, trebuie trimisă o referință corespunzătoare ca parametru în constructor sau într-o metodă. Aceasta înseamnă că același obiect poate fi accesat din locații diferite folosind identificatori diferiți. Acest lucru necesită studenților o înțelegere mai profundă a referinței, care urmează să fie dezvoltată în modulul următor.

materiale:

  • Faza introductivă UV IV.1 (Link)

Scena secvenței

Acest modul este pornit cu ajutorul unei idei de joc clasice. Un joc urmează să fie programat în care un OZN mic poate fi văzut în partea de jos a ecranului și poate fi mutat la stânga și la dreapta de către jucător folosind tastele săgeată.

Asteroizii vin acum de sus, ceea ce trebuie evitat. Dacă OZN-ul este lovit de un asteroid, jocul s-a terminat.

Inițial, jocul ar trebui implementat cu doar trei asteroizi. În plus, toate obiectele se află în planul XY, adică este modelat bidimensional.

Figura 1: Schiță de planificare pentru proiectul jocului OZN

O analiză a acestei probleme duce rapid la rezultatul că un OZN constă din mai multe obiecte GLO, care trebuie mutate sincron dacă OZN se sustrage. O astfel de compoziție este deja cunoscută.

Problema aici rezidă în detalii, dacă cineva întreabă cum ar trebui să se realizeze coliziunea dintre un OZN și un asteroid. O abordare posibilă este excluderea inițială a acestei probleme și implementarea controlului OZN și a mișcării asteroizilor. O modelare corespunzătoare fără o coliziune arată astfel:

Figura 2: Modelarea unui prototip simplu fără coliziune

Un program corespunzător poate fi dezvoltat de elevi înșiși sau în părți date ca prototip și analizate.

Este o idee bună să extindeți programul în așa fel încât un asteroid care a migrat în partea de jos a imaginii camerei să fie plasat într-o nouă poziție dincolo de marginea superioară a intervalului de detectare al camerei, astfel încât să poată zbura din nou către OZN . În acest fel, un flux constant de obstacole poate fi simulat cu doar trei obiecte.

Resetarea asteroidului poate fi externalizată către o metodă privată corespunzătoare.

În afară de aceasta, coliziunea mai trebuie realizată. Fiecare asteroid ar trebui să aibă acces la OZN, astfel încât să poată verifica o coliziune și, dacă este necesar, metoda exploda () de OZN poate apela. Pentru a face acest lucru, o trimitere la OZN este transmisă în constructorul asteroidului și salvată de acesta. Modelarea extinsă arată astfel:

Figura 3: Modelarea unui prototip simplu cu coliziune

Metodele resetare la valorile implicite() și întâlnit() sunt metode private ale clasei asteroid și sunt în Mișcare() de asteroid numit. Metoda întâlnit() testează o coliziune cu OZN și returnează valoarea Adevărat, dacă există una. Metoda Mișcare() de asteroid va exploda apoi OZN-ul.

Figura 4: Jocul OZN în două dimensiuni

Pentru a decide dacă există o coliziune, asteroidul folosește teorema lui Pitagora pentru a calcula distanța dintre acesta și OZN. Pentru aceasta, el trebuie să găsească poziția OZN cu ajutorul metodelor gibX () și gibY () poate întreba. Dacă distanța este sub o anumită valoare prag, se presupune o coliziune.

Trebuie remarcat în acest moment că obiectul de tip OZN acum pot fi accesate din două locații diferite. În plus, sunt utilizate două referințe, care pot avea chiar același identificator, deoarece se află în clase diferite.

Dacă jocul OZN este terminat în acest fel, un prim pas în expansiune ar putea fi extinderea acestuia la a treia dimensiune. Camera este înclinată cu 90 de grade și mișcarea OZN în jurul metodelor muta sus () și muta in jos () extins. Poziționarea asteroizilor va fi, de asemenea, extinsă cu o dimensiune, la fel cum calculul distanței dintre asteroizi și OZN trebuie convertit în trei dimensiuni.

Întrucât există acum mult mai mult spațiu de evitat, numărul de asteroizi ar trebui mărit folosind un câmp. Rezultatul ar putea fi o simulare precum Figura 5.

Figura 5: Jocul OZN în trei dimensiuni

Desigur, este, de asemenea, posibil să se încorporeze o schimbare a vitezei jocului, să permită mai multe ratări înainte de finalizarea jocului sau să se adauge un laser, cu ajutorul căruia asteroizii pot fi aruncați din orbita lor.

adâncirea

Pentru a aprofunda principiul referințării multiple a obiectelor, sunt disponibile mai multe idei de proiect care se bazează pe o modelare similară jocului OZN.
Proiectul de prindere a mingii este o alternativă: trei mingi se mișcă pe un teren de joc pătrat. Când ajung la marginea terenului, schimbați direcția, astfel încât să nu părăsească terenul. Jucătorul controlează o mică cutie de capcană de-a lungul terenului de joc și ar trebui să provoace o coliziune cu bilele și să le „prindă” în acest fel. Dacă un glonț este prins, acesta dispare. Când toate bilele sunt prinse, jocul s-a terminat.

Cutia de prindere este controlată de jucător în așa fel încât să poată specifica noua direcție de mișcare a cutiei cu tastatura. Cutia continuă apoi să ruleze singură în direcția corespunzătoare. Dacă amenință să părăsească terenul, ea își schimbă automat direcția.

Figura 6: Schiță de planificare pentru proiectul Kugelfangen

O modelare pentru acest proiect ar trebui să includă clasele Capcană cu glonț, Glonţ, cutie și teren de chibrit include. Modelarea în contextul bibliotecii Creioane și șoareci sau în Greenfoot face de obicei fără clasă teren de chibrit, deoarece interpretează ecranul ca pe un teren de joc. Deoarece biblioteca GLOOP nu are un ecran, aici trebuie dezvoltată o clasă separată. O posibilă modelare ar putea arăta astfel:

Figura 7: Modelarea proiectului de prindere a mingii

Prin crearea unui obiect al clasei Capcană cu glonț jocul începe. Creează toate celelalte obiecte și apelează metoda pentru casetă și cele trei bile într-o buclă de animație mișcare () pe. În funcție de o intrare pe tastatură, metoda setMovement () numită cutie. Noua direcție de mișcare a cutiei este transferată către aceasta cu ajutorul a doi parametri, prin care pVX este componenta mișcării în direcția X și pVZ componenta mișcării în direcția Z. Jocul este astfel modelat în planul XZ. Pe măsură ce se mișcă, atât caseta, cât și mingea verifică dacă au ajuns la marginea terenului de joc. Pentru a face acest lucru, ei pot accesa terenul de joc și pot interoga lățimea și adâncimea acestuia. Bilele verifică, de asemenea, dacă există o coliziune cu cutia și, eventual, devin inactive și invizibile.

Jocul se termină atunci când toate bilele sunt inactive.

Următorul cod sursă reprezintă metoda de mutare a mingii:

Metoda codului sursă de mutare a bilelor

Rezultatul final poate arăta așa cum se arată în Figura 8.

Figura 8: Soluție model pentru proiectul Kugelfangen

Desigur, mai mult de trei bile pot fi create cu ușurință cu ajutorul unui câmp. Regulile jocului pot fi, de asemenea, ajustate. De exemplu. caseta nu schimbă automat direcția la părăsirea terenului de joc, ci mai degrabă cade peste margine și astfel pune capăt jocului. Un contor de puncte ar putea fi, de asemenea, instalat. Jocul s-ar putea termina atunci când se atinge un anumit număr de puncte. Înainte ca acest număr de puncte să fie atins, bile noi continuă să apară.

În plus față de aceste două proiecte, există un număr mare de alte opțiuni pentru practicarea relațiilor de obiecte de acest tip. De exemplu. conduceți o mașină printr-o pădure sau umpleți o masă de biliard cu bile bifante.

Figura 9: Conducerea și biliardul ca opțiuni suplimentare pentru specializare

  • QUA-LiS NRW
  • Formare profesională
  • Backup standard
  • educație suplimentară
  • Protejarea datelor
  • imprima