Projekt

Ramcove zadanie projektu

Hra

Vytvorte hru v jazyku Java s používateľským rozhraním (GUI). Cieľom nie je zamerať sa na grafiku (2D alebo 3D) alebo multiplayer po sieti, ale na využitie (správne) objektovo orientovaného programovania a vlastností jazyku Java. Ako pomôcku pre premýšlaní použite napríklad zoznam žánrov hier (https://en.wikipedia.org/wiki/List_of_video_game_genres)

  • Vypracujte zamer projektu (maximalna dlzka 250 slov), je konkretnejsi popis toho co idete robit, ale NIE technicky opis toho co idete robit, predstavte si ze idete hru predstavit manazerovi herneho studia (t.j. nevie v zasade nic o programovani)
  • Vytvorte zjednodusene specifikaciu (poziadavky), co ma hra “robit”, priradte im prioritu (aspon 10 funcionalnych a 3 nefunkcionalne), podla tejto priority nasledne budete implementovat Vas projekt
  • Identifikujte najdolezitejsie triedy a ich najdolezitejsie metody, zakreslite ich do zjednoduseneho UML diagramu tried
  • Nezabudnite, ze studujete OOP, preto pri zamere projektu myslite na to, ze budete potrebovat vyuzit objektovo orientovanu paradigmu v samotnej implementacii
  • Konzultujte zamer s cviciacimi (3. a 4. tyzden semestra)
  • Pocas riesenia projektu je mozne sa mierne od zameru (a specifikacie) odklonit

Template

Odovzdajte do systemu AIS do vytvoreneho miesta odovzdania vo formate PDF.

Hodnotenie

Jasne definovany zamer 2b

Spravne definovane poziadavky 1b

Pridelenie priority k poziadavkam 1b

Korektny diagram tried 1b

Checkpoint

Pocas prace by mali vznikat viacere “verzie” (v kontexte Gitu – pull requesty, pripadne aspon commity) – je potrebne pracovat na projekte priebezne, cviciaci si kontroluju progres.

Je potrebne na najblizsom cviceni po termine odovzdania checkpointu odprezentovat vyznamnu a FUNKCNU cast zadania podla zameru projektu, je nutne aby bol kod prelozitelny a spustitelny, v opacnom pripade bude neakceptovany.

Odovzdava sa do GitHub classroom (info v podmienkach akceptovania), odovzdavajte vzdy do vetvy main (mozete pouzivat aj ine, ale nakoniec automaticky zozbieravame iba main). Nastavte si v GitHube meno a priezvisko v profile (potrebujeme Vas vediet identifikovat).

Hodnotenie

Priebezna praca na projekte (t.j. aspon 1 commit do tyzdna) 1b

Pokrytie jednotkovymi testami (podla finalneho odovzdania) 1b

Dodrziavanie priorit podla specifikacie 1b

Dodrziavanie principov OOP a konvencii jazyku Java 2b

V pripade ze vyznamne nebola dodrzana podmienka priebeznej prace na projekte (napriklad ze prvy zmysluplny push do repozitara bol az posledny tyzden), tak student nemoze dalej pokracovat v praci na projekte, t.j. hodnotenie predmetu je FX. Ak student pravidelne prezentoval progres na cviceniach, tak toto sa nemusi uplatnit (rozhodne cviciaci).

Finalne odovzdania

Ku programu je potrebne odovzdat (vypracovat) dokumentaciu:

  • Javadoc (generovany priamo z kodu)
  • Sprava o realizacii projektu (template )

Program musi splnat tieto podmienky (minimalne a zmysluplne pouzite) /NUTNE PODMIENKY akceptovania/ – 8b:

  • Byt fukcny, zodpovedat zadaniu a zameru
  • Odovzdany kod musi obsahovat vsetky potrebne subory (a nic ine!) a musi byt prelozitelny v JDK 21 a importovatelny do Intellij Idea CE (2024+)
  • Obsahovat dedenie a rozhrania
  • V pripade pouzitia inych externych zavislosti musi byt pouzity Maven (napr. jar subory nesmu byt v repozitari)
  • Pouzitie zakladnych OOP principov (enkapsulacia, dedenie, polymorfizmus, abstrakcia)
  • Musi obsahovat dostatok komentorov a anotacii (JavaDoc)
  • Musi byt jednotkovo otestovany (line coverage > 80% (bezne sa toto blizi k 100%)) – GUI nie je potrebne pre ucely odovzdania projektu jednotkovo otestovat. Gettery a settery ano. Toto sa moze pri naozajstnom vyvoji lisit. V pripade nesplnenia tejto podmienky je stale mozne za projekt ziskat “body”, avsak za tuto cast ziskava (v pripade splnenia ostatnych podmienok) 4b z 8b.
  • Musi splnat zakladne principy softveroveho vyvoja, vyvoja objektovo orientovaneho kodu a vyvoja v jazyku Java 21.

Pozor, primarne hodnotime vyuzitie principov OOP, v pripade ze program ich nebude dodrziavat, moze byt hodnotenie v extremnych pripadoch (aj pri funkcnych projektoch) 0 bodov.

Dalsie kriteria na projekt (vzdy sa hodnoti zmysluplne vyuzitie):

  • Pouzitie navrhovych/architektonickych vzorov (okrem trivialnych (Singleton)- pouzit ho mozete, ale nebude hodnoteny) – za kazdy vzor 1b (max 3b)
  • Logovanie zakladnych cinnosti (aspon na urovni info, warning, error) – 1b
  • Implementacia a pouzitie vlastnych vynimiek – 1b
  • Implementacia a vytvorenie GUI – 2b
  • Explicitne pouzitie viacvlaknovosti – 1b
  • Pouzitie generickovsti vo vlasnych triedach – 1b
  • Pouzitie reflexie – 1b
  • Pouzitie lambda vyrazov, referencii na metody – 1b
  • Pouzitie serializacie/IO – 1b
  • Vypracovanie dokumentacie (vzor nizsie) – 3b

Terminy

  • Zamer, specifikacia a navrh (zjednoduseny): 16.3.2025 20:00
    • odovzdava sa do ais miesta odovzdania
  • Checkpoint: 6.4.2025 20:00
    • odovzdava sa do GitHub classroom.
  • Finalne odovzdanie: 27.4.2025 20:00
  • Prezentovanie projektov:
    • na cviceniach
    • ~10.-12. tyzden (podla dohody s vyucujucim)

Podmienky akceptovania

  • Nie je povolené vytvarat Minecraft like hry (kvoli prednaskam a cviceniam).
  • Neodovzdanie casti projektu (pripadne odovzdanie na neakceptovatelnej urovni) ma za nasledok hodnotenie 0 CELEHO projektu
  • Terminy su striktne (ked su)
  • Defaultne nie je povolene pouzivat “game enginy/frameworky”, konzultujte s cviciacim, s konkretnym navrhom ako ste schopny ukazat ze ovladate OOP, aj ked budete pouzivat taketo frameworky/kniznice
  • Projekt musi byt vlastnou pracou studenta (vid studijny poriadok STU v BA)
  • Na správu kódu je povinné používanie GitHubu s registráciou do classroomu vytvoreného pre tento predmet (https://classroom.github.com/a/Q-troXqB) – deadline na pridanie sa je 19.3.2025 20:00. Pouzite login (podla moznosti vo forme priezviskomeno alebo ais login (t.j jurajpetrik alebo xpetrikj2).

Finalne hodnotenie projektu:

  • Musia byt splnene nutne podmienky akceptovania projektu.
  • Student musel pocas semestra pracovat priebezne na projekte (t.j. viditelny progres aspon raz tyzdenne v github classroome)
  • Za finalnu cast projektu je mozne ziskat maximalne 20b (okrem bonusu)
  • Z casti dalsie kriteria na projekt je mozne ziskat maximalne 12b (t.j. nie je potrebne splnit vsetky podmienky na ziskanie maximalneho poctu bodov za tuto cast, avsak odporucane je implementovanie aj “nieco navyse”)

Mozny bonus (doplna sa do max. poctu bodov projektu a potom preteka do celkoveho bonusu za cely predmet):

  • Jednotkove testy GUI (napr. pomocou Robot) – 2b
  • Bonusy mozu byt doplnene este neskor

WordPress Appliance - Powered by TurnKey Linux